페이스북이 쿨하게 1조에 산 Instagram의 아키텍처

Instagram 에서 사용한 아키텍처에 대한 번역글이 있어서 옮겨봅니다.

Infra 는 Cloud 를 이용하고 핵심기술들은 대부분 Opensource 를 이용함으로써 빠르게 서비스를 안정적으로 가져가도록 구성하였네요.

국내 서비스는 Cloud 를 이용할 만큼 규모가 크지 않지만, 빠르게 서비스를 안정적으로 운영한다는 면에서는 좋은 approach 라고 생각합니다. 세계적인 추세이기도 하구요.

[발 번역] 페이스북이 쿨하게 1조에 산 Instagram의 아키텍처

해당 글은 http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html 을 발 번역한 것입니다. 오역에 주의하세요.( 10명 회사에 1조면 1인당  부럽네요.) 참고로, 읽고 나니, 전에 올렸던 내용들을 요약한 것입니다. 전에 껄 다 보신 분이면 그냥 요약으로 생각하세요.

비밀이 잘 지켜지긴 했지만, 페이스 북이 1조에 사진 공유 서비스인 인스타그램을 1조에 샀다는 이야기를 들어봤을 것이다.( Facebook will Buy Photo-Sharing Service Instagram for $1 Billion. ) 무엇이 페이스북으로 하여금 사게했을까?  1년도 전에 인스타그램에서 줬던 그들의 아키텍처에 대해서 간단하게 정리했다. 여기서 나는 인스타그램의 아키텍처를 “이 시대 초기 단계 스타트업의 표본” 이라고 불렀는데, 정말로 이렇게 될지는 몰랐다. 만약 인스타그램이 어떻게 했는지 알고 싶다면, 계속 읽기를 바란다.

Instagram 은  급속히 성장한 iphone을 위한 무료 사진 공유 및 소셜 네트워킹 서비스이다. (역자 주: 현재 안드로이드 앱도 출시가 되었고, 하루만에 100만명이 늘어났고 이를 어떻게 처리했는지에 대해서는 다음 사이트를  확인하시기 바랍니다.http://instagram-engineering.tumblr.com/post/20541814340/keeping-instagram-up-with-over-a-million-new-users-in ) 작년까지 1400만명으로 사용자가 늘어났고( 현재는 3천만명 정도) 작년 8월에 수 테라 바이트 이상의 용량을 가진 1억 5천만개의 사진을 저장했다. 모든 장비를 아마존에서 돌리면서, 단지 3명의 엔지니어로 이 모든 것을 처리했다.

인스타그램 개발팀은 이 시대에 초기 스타트업이 어떤것을 고려해야 하는지에 대해서 다음 글을 썼다.

What Powers Instagram: Hundreds of Instances, Dozens of Technologies.

(역자 주:  여기서 번연글을 보실 수 도 있습니다. http://charsyam.wordpress.com/2011/12/17/%EB%B0%9C-%EB%B2%88%EC%97%AD-%EC%88%98%EB%B0%B1%EB%8C%80%EC%9D%98-%EC%9E%A5%EB%B9%84%EC%99%80-%EC%88%98%EC%8B%AD%EA%B0%80%EC%A7%80%EC%9D%98-%EA%B8%B0%EC%88%A0-instagram%EC%9D%98-%ED%9E%98/ )

인스타그램은 여러가지 다른 기술과 전략을 혼합하여 사용합니다. 팀원 수는 여전히 작음, 소셜과 모바일의 물결에 올라타서 급속도로 성장한 경험이 있습니다. SQL과 NoSQL을 혼합하여 사용하고, 수 많은 오픈 소스를 사용하고 있습니다.  그들은 클라우드를 선택했고, 아마존 AWS 서비스는 그들이 직접 구축하는 것보다 높은 유연성을 제공했습니다. 이용할 수 있는 zone(역자 주: 아마존 aws는 서비스들이 존으로 나뉘어져 있고, 서버를 어디에 둘지 결정할 수 있습니다.) 으로 신뢰성이 높아졌고,  비동기 작업은 컴포넌트들을 통해서 스케줄링 되며, 시스템은  그들이구축할 수 없는 외부 서비스와 서비스를 가능하게 해주는 수많은 API로 구성되었습니다. 데이터는 메모리와 클라우드에 저장되고, 대부분의 코드는 다이내믹 랭귀지로 작성이 되었으며,  자기들만의 커스텀한 부분은 최대한 작게 유지되고 빨리 제거되었습니다. 아주 현대적인 구조입니다.

아래에 그 내용들이 있습니다. 매우 잘 쓰여졌고, 핵심을 잘 잡았습니다. 읽을 만한 가치가 있고, 그 중에 핵심만 뽑았습니다.

배울점 : 

• 1) 간결하게 유지해라. 2) 바퀴를 재 발명하지 말라. 3) 할 수 있고, 증명되고, 유연한 기술만 이용하라.(역자 주:  사람이 적으므로, 가장 최선의 방법을 항상 찾아야했겠죠?)
• 3명의 엔지니어 (현재는 13명으로 보고됨,  이걸 뒤에도 계속 기억하세요.)
• 아마존을 이용함. 수 많은 아마존 서비스를 이용하는데, 인원이 3명 뿐이었기때문에, 자체적으로 구축할 시간이 없었음.
• 총 100대 이상의 다양한 용도로 EC2 장비 사용
• 우분투 11.04 사용 다른 버전은 아마존에서 Freezing 현상 발견
• 아마존의 ELB를 사용하고 ELB 뒤에 3대의 nginx 가 있음.
• SSL terminates at the ELB, which lessens the CPU load on nginx.
• DNS를 위해서 아마존 Route53을 사용.
• High-CPU Extra-Large 장비 위에 25대의 Django 서버가 돌아감
• 트래픽은 메모리 보다 CPU의 영향을 받음 그래서 High-CPU Extra-Large 장비가 메모리와 CPU간의 조화가 더 좋았음.
• Gunicorn 을 WSGI 서버로 사용. apache가 더 설정하기 어렵고 CPU에 영향을 많이 받음.
• Fabric 을 모든 머신에서 명령을 동시에 실행하기 위해서 사용. 배포가 수초만에 끝남.
• 12 대의 Quadruple Extra-Large memory 장비에서 PostgreSQL(유저 정보, 사진 메타정보,태그, 기타 등등) 사용
• 12 대의 PostgreSQL 백업 장비가 다른 availabilty zone 에서 동작함
• PostgreSQL은 Streaming Replication 을 이용한 master-replica  형태로 동작함.  EBS는 잦은 백업을 위한 snapshot 목적으로 사용.
• EBS는 안정적인 IO를 위해 mdadm 을 이용해 소프트웨어 RAID 구성
• 모든 처리중인 데이터는 메모리에 저장됨 EBS는 충분한 속도를 제공하지 못함.
• Vmtouch (portable file system cache diagnostics) 은 어떤 데이터가 메모리에 있는지 관리하는 용도로 사용 한 장비에서 다른 장비로 Fail Over 할 경우, 이미 로드된 데이터가 없음.
• XFS 가 파일 시스템임. snapshot을 만들때 RAID Array 에 freezing, unfreezing을 통해서 일관성을 유지
• Pgbouncer 는 PostgreSQL의 pool connections 용도로 사용
• Amazon S3에 수 테라 바이트의 사진을 저장.
• CDN으로 아마존 CloudFront를 사용
• Redis는 main feed, active feed, session system 및 다른 서비스에 사용중.
• Redis 는 몇 대의 Quadruple Extra-Large Memory 장비에서 동작중. 샤딩되어 있음.
• Redis 는 master-replica ㄹ 동작중. Replica가 디스크로 백업함. EBS snapshot으로 백업된 애용 저장. master에서 저장하면 너무 비용이 비쌈.
•  geo-search API를 위해서 Apache Solr 이용, JSON interface 사용함
• 캐싱을 위해서 6대의 memcached 사용  pylibmc와 libmemcached 사용. 아마존 Elastic Cache는 아직 너무 비쌈.
• Gearman 은 비동기적으로 트위터, 페이스북 및 다른 곳으로 사진을 공유하거나, 실시간으로 사용자에게 새로운 사진을 알리기 위해서 사용
• 200 개의 python worker 가 Gearman 을 통해서 큐를 처리한다.
• Pyapns (Apple Push Notification Service) handles over a billion push notifications. Rock solid.
• 문제점을 알려주고, 시스템에 그래프로 표시해주는 Munin  ,Python-Munin 을 위해서 graph를 그려주고, 초당 포스트되는 사진 수, 분당 가입자 수등을 보여주는 많은 플러그인을 작성다.
• 서비스의 외부 모니터링을 위한 Pingdom
• 알람이나 장애을 처리를 위한 PagerDuty
• 에러 리포팅을 위한 Python Sentry

그리고 1조에 팔릴만한 비밀을 안다면, 당신 서비스의 아키텍처를 HighScalability에 올려주시기 바랍니다!

출처 : [발 번역] 페이스북이 쿨하게 1조에 산 Instagram의 아키텍처