1. 초기 구조

• AWS에 호스팅되지도 않는 단일 서버 + Django 웹 프레임워크 + PostgreSQL 데이터베이스
• 인스타그램 공동창립자인 Kevin Systrom은 많은 스타트업들이 하는 실수가 “너무 일찍, 확장에 집중하고, 유저가 좋아하는 것에 집중하지 않는다”는 점이다.
  • “5만명이 언제 당신의 제품을 사용할지는 나중에 고민해도 된다.”
  • “왜냐면 그떄쯤이면 그 문제를 갖고있다는 자체에 행복할테니까”
• Docker, Kubernetes, AWS, 기타 등등을 마스터하는 것에 초점을 두어, 원하는 것을 만드려는 것을 미루곤 한다.
  • 하지만 일단 불완전한 무언가를 만드는 것이 아예 시작도 못하는 것보다 낫다.
  • 결국 인스타그램은 단일 서버에서 AWS로 마이그레이션함
• Kevin에 따르면 5,000만명의 유저가 사용하는 동안 “단일 서버 + Django 웹 프레임워크 + PostgreSQL 데이터베이스”가 계속 사용됐다.
  • 이게 가능한 이유는 서버가 그렇게 빠르지 않더라도, 모든 것이 더 빨라 보이도록 앱을 최적화시킴
  • 사진 업로드가 최대한 빠르게 이루어져야 하지만, 서버에 파일을 업로드하는데 시간이 걸리기 떄문에, 로딩 상태를 최대한 숨겼다.
  • 지연시간을 숨기기 위해, 사진을 찍은 후 ‘게시’ 버튼을 누르기 전에 사진이 백그라운드에서 인스타그램 서버에 미리 업로드되도록 했다.
  • 즉, 유저가 캡션과 해시태그 작성을 마쳤을 떄는, 이미 사진 파이링 서버에 업로드되어있으므로. 게시버튼을 누르면 이미 사진이 업로드되어있다.
  • 이렇게 업로드가 바로 된 것처럼 보이게 만들었다.
  • 또한 업로드를 취소하면, 나중에 사진이 삭제된다.
• 첫 해에 인스타그램 유저는 1400만명으로 증가하고, 단일 서버에서 AWS 마이그레이션은 3명의 개발자가 진행했음
• 1400만명 유저를 가진 인스타그램은 25개의 앱 서버를 병렬로 실행하고 있었고, 성능이 더 필요하면 서버를 그룹에 추가만 했음
  • 모든 데이터를 하나의 데이터베이스에 저장하는 대신, 샤딩을 이용해 여러 DB에 분산해서 저장함
• 키-값 데이터베이스인 Redis를 사용하여, 메인 피드, 활동 피드 및 세션 시스템을 구동함
  • Redis 역시 샤딩되어 있기ㅗ, PostgreSQL과 마찬가지로 복제본이 존재
  • 마스터-복제본(replica) 패턴을 사용
• Redis와 PostgreSQL은 모두 Amazon의 Elastic Block Store를 사용하여 백업되어 있음
• 좋아요 하는 사람이 너무 많아서 2개의 테이블로 분리한 사진 테이블과 좋아요 테이블을 비정규화를 통해 1개의 테이블로 만듬
  • 모든 사진에 대한 수십만 개의 좋아요 수를 세는 대신, 사진 테이블에 간단한 카운트만 유지했다.
• 인스타그램이 Facebook에 인수된 이후에는 알려진 바가 많이 없다.

현재는 AWS에서 Meta 데이터 센터로 이전했고, 현재 분당 46,000개 이상의 게시물을 처리하고 있다.

• 현재 Facebook에서 만든 소셜 그래프용 데이터베이스로 TAO(The Associations and Objects)라는 데이터베이스를 사용함
• 매초 10억 건 이상의 읽기 요청과 수백만 건의 쓰기 요청을 처리할 수 있다.