https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million
- 2010/10 부터 2011/11 까지 약 1년간 0명에서 1400만명 사용자에 도달. 엔지니어는 단 3명
- 3가지 원칙을 따랐음
- 간단하게 유지할 것 (Keep things very simple.)
- 바퀴를 재발명하지 말 것 (Don’t re-invent the wheel.)
- 가능하면 입증된 견고한 기술을 사용할 것 (Use proven, solid technologies when possible.)
사용자 관점에서 간단하게 스택 살펴보기
- 초기 인프라는 AWS EC2에서 Ubuntu Linux
- 인스타그램 앱은 iOS만 먼저 나왔고, Swift 발표 전이라 Objective-C + UIKit 일 가능성이 높음
- 로드 밸런싱을 위해 Amazon의 Elastic Load Balancer와 3개의 NGINX 인스턴스를 사용하였음
- Application Server 에 도달하기 전 LB에 도달
- 어플리케이션 서버는 파이썬으로 개발되어서 Django 와 WSGI 서버로 Gunicorn
- Fabric 을 이용해서 여러 인스턴스에서 같은 명령을 동시 실행. 이를 통해 코드를 몇 초 안에 배포
- 25대의 고성능 CPU Extra-Large 머신을 구동. 모두 Stateless라서 필요하면 쉽게 더 추가 가능
- 일반 데이터 저장소
- 관련된 포토 ID, 해당 ID의 실제 사진, 사진에 대한 사용자 데이터
- 어플리케이션 서버가 PostgreSQL로 부터 데이터 가져오기
- Django 와 PostgreSQL 간에 pgbouncer로 풀링
- 왜 pgbouncer 가 좋은지도 살펴보면 좋겠다.
- DB sharding 적용, 수천개의 논리 샤딩과 소수의 물리 샤딩 (1초당 25장 이상 이미지, 90개 이상 좋아요를 기록을 감당하기 위해)
- 인스타그램은 시간으로 정렬가능한 ID를 이용함 : 41비트 밀리초 + 13비트 샤드ID + 10비트 자동 증가 시퀀스 샤딩 관련해서는 여기에 더 자세하게 나와있다
- 이 시간 순으로 정렬 가능한 ID를 통해, DB에서 id 기준으로 소팅하여 최신 이미지 ID들을 가져올 수 있었다.
- 사진 저장소 : S3와 Cloudfront
- 캐싱: Redis 와 Memcached
- 스마트한 해싱을 통해서 3억개의 키 매핑을 5GB 이하의 공간에 저장. 관련 내용
- 그리고 2년후에 페이스북은 Memcached를 스케일해서 초당 수십억건의 요청을 확장한 방법에 대한 논문을 발표
- Memcached는 Django에서 사용하기에 비교적 심플하였다
- Postgres와 Redis 모두 Master-Replica 모드로 실행. Amazon EBS 스냅샷으로 계속 백업
- Push Notification 과 Async Task : 알람(notification)은 pyapns. 비동기 작업 큐로는 Gearman
- 큐른 컨슈밍하는 worker는 대략 200개 정도
- 오류를 실시간으로 모니터링하기 위해 오픈 소스 Django 앱인 Sentry를 사용하였으며, 시스템 전체 메트릭스를 위해 Munin을 사용하였고, 외부 서비스 모니터링을 위해 Pingdom 과 PagerDuty를 사용
최종 아키텍쳐
는 다음과 같다.
