해당 글은 http://highscalability.com/process/CreateJournalEntryComment?moduleId=4867632&entryId=14142508&finalize=true 을 발 번역한 글입니다. 오역에 주의하세요.(개인적으로 Grizzard 에 대한 내용이 대부분이라서, 이부분을 추가로 보시는게 좋을듯 합니다. 그리고, 마지막에 오픈소스에 대한 생각이 좋은데, 그 쪽은 영어가 어려워서 정말 번역이 개판입니다. T.T 누가 좀 그 부분좀 바꿔주세요. 감사합니다.)
트위터의 DBA 팀 리더이자 데이터베이스 아키텍트인 Jeremy Cole 은 O’Relly MySQL 컨퍼런스: Big and Small Data at @Twitter 라는 주제로 데이터 관점에서 바라본 트위터의 생각에 대해 정말 좋은 얘기들을 해 주었습니다.
흥미로웠던 것 중에 하나는, 예전에는 트윗을 저장하기 위해서 temporal sharding(역자 주: 트위터는 이전에, 시간으로 데이터를 구분해서 올드 데이터와 현재의 데이터를 샤딩처리했습니다.) 을 이용했는데, MySQL을 이용하는 Gizzard 위에 구축된 T-bird 라고 불리는 시스템에 트윗을 저장하고 있다는 것입니다.
트위터의 이전 Tweet 저장(Twitter’s Original Tweet Store):
- Temporally shard 된 트윗은 그 시기에는 좋은 아키텍처였다. Temporal sharding을 간단히 얘기하면, 같은 시간대의 데이터는 같은 샤드에 저장하는 것이다.
- 한 머신이 트윗으로 가득차야만, 다음머신으로, 다음머신으로, 결국 차례대로 채워지게 되는 문제가 있다.
- 몇가지 상황에 대한 일반적인 접근 방법은 다음과 같다.
- Load balancing. 트위터 사용자들은 거의 현재 일어지는 일에만 관심이 있기 때문에, 대부분의 이전 장비들은 더이상의 트래픽을 받지 않는다.
- Expensive. 매 3주마다 한 대의 장비가 replication 장비와 함께 가득차며, 이것을 처리하는 것은 꽤 비싼 셋업입니다.,
- Logistically complicated. 매 3주마다 새로운 클러스터를 구축하기 위해서 DBA 팀이 고생했습니다.
새로운 Tweet 저장(Twitter’s New Tweet Store):
- 트윗이 Gizzard로 구성된 T-bird라는 내부 시스템에 저장될 때, T-flock 이라는 개별 시스템에 Secondary Index 가 저장된다. T-flock 역시 Gizzard base 다.
- 트윗의 Unique IDs는 샤드된 클러스터에 균등하게 Snowflake 에서 생성되며 FlockDB는 ID 와 ID의 매핑과, IDs 간의 관계들을 저장합니다.(역시 Gizzard를 이용합니다.)
- Gizzard 는 Mysql(InnoDB)위에 구성된 분산 데이터 저장소입니다.
- InnoDB는 데이터가 깨지지 않기 때문에 선택했습니다.( 역자 주: innoDB 라고 해서 절대로 안깨지는 것 아닙니다. 다른 engine에 비해서 Transaction이나 데이터 보관에 안전성을 더 보장해줍니다. ) Gizzard 는 단순한 데이터 저장소입니다. 데이터를 넣었다가 다시 뺄 수 있습니다.
- 높은 성능을 위해서 개별 노드의 많은 기능들을(바이너리 로그, 리플리케이션) 꺼버렸습니다. Gizzard 는 샤딩과 N개의 복제를 위한 데이터 카피, 잡 스케줄링만 처리합니다.
- Gizzard는 트위터에서 다른 스토리지 시스템을 위한 구성 요소로 사용됩니다.
- 트윗 저장에 대한 Gizzard 구현은 load balancing 상황에서 완벽하지 않습니다만 다음과 같은 것이 가능합니다.
- Growing slowly 급속도로 데이터가 시스템을 가득 채우지 않기 때문에, 정확한 시간에 새로운 클러스터를 만들어줄 필요가 없습니다.(역자 주: 이전 시스템의 문제가 매 3주마다 새로운 클러스터를 만들어야 했던 것 기억나시죠?)
- DBAs can get some sleep. (DBA가 잠을 잘 수 있다. ) DBA들이 빈번하게 비용 효과가 떨어지는 Scale 결정을 할 필요가 없어졌습니다.
- MySQL은 사용할 만한 가치가 있고, 대부분 잘 동작합니다. 트위터는 기능보다 안전성을 소중히 여겨서 이전 버전을 이용합니다.(역자 주: MySQL 최신 버전을 사용하지 않는다는 말인 것 같습니다. 대부분의 기업들은 최신 버전이 나와도 바로 사용하지 않고 일정 시간이 지나야만 사용합니다. 앞에서 말한 안전성 때문입니다. )
- MySQL은 ID 생성과 graph 저장소로 동작하지 않습니다.
- MySQL은 Raid Array의 하나 처럼 큰 데이터셋의 백업 스토어로 1.5TB 이하의 작은 데이터셋만 저장합니다.
- 일반적인 서버는 HP DL380, 72GB RAM, 24 disk RAID10. 메모리와 디스크의 균형이 좋습니다.(역자 주: 코멘트 중에 DL380은 24disk를 못가진다. 16개가 최고다라는 얘기가 있네요. 그런데, 개별 데이터는 1.5TB만 저장하는 데 디스크는 24개면 뭐가 들어가는 걸까요 흐음. )
Mysql 을 모든 곳에 사용하지 않는다.(MySQL Isn’t Used For Everything):
- Cassandra 는 높은 쓰기 성능과 좀 낮은 읽기 성능이 필요한 곳에 사용한다. 카산드라의 장점은 MySQL 모다 싼 장비에서 돌릴 수 있고, 확장하기 쉽고, schemaless 한 디자인이다.(역자 주: 개인적으로 DB장비는 Raid 구성이 리플리케이션을 하더라도 안전성을 위해서 꼭, 필요합니다. 카산드라는 그런걸 안해도 된다라는 의미로 보입니다. 확장하기 쉽긴 한데, N대가 있으면 한번에 확장할 수 있는 한계가 N입니다. 그리고 추가된 장비로 인해서 데이터 복제가 발생해서, 서비스가 안되는 사태도 벌어질 수 있습니다.)
- Hadoop 은 비구조적 데이터(로그?) 와 수조 개 이상의 로우를 가진 큰 데이터에 이용합니다.
- Vertica 는 MapReduce 잡으로 할 수 없는 조인, 큰 집합, 분석에 사용됩니다.
그 외의 아이디어(Some Other Ideas):
- Loose coupling. 무언가가 깨질때마다, 그것이 충분히 느슨하게 결합되지 않았다는 것을 알게 된다. 그리고 그것을 되돌리는 것도 힘들다.
- Soft launches. 새로운 기능들은 릴리즈시에 서로 영향이 없도록 분리시켜라. 각 기능별로 동작시키거나 멈출 수 있어야 한다.
- Open source. 트위터는 자신의 인프라스트럭처를 오픈 소싱하는 것으로 유명합니다. Jeremy 는 오픈 소싱에 대한 내가 전에 한번도 듣지 못한 이야기를 해주었습니다. 개발자로서 그의 생각은 코드를 오픈 소싱한 것은 개별 기업의 블랙홀 안에 던져지는 것이 아니라 해당 소프트웨어가 사라지지 않는 것을 의미합니다. 그것은 기업의 개발에 대해 좀 더 지속적인 방법, 좀 더 의미 있는 방법을 생각하도록 해줍니다.
감사해요 Jeremy!
Charsyam's Blog 