Instagram이 10억 명의 사용자를 지원하기 위해 인프라를 확장한 방법

원본 출처

https://substack.com/home/post/p-157251513

아래는 번역 해놓은 내용입니다.

---

인스타그램의 초기 인프라 과제

인스타그램이 2010년에 처음 출시되었을 당시에는 엔지니어링 리소스가 제한적인 작은 회사였습니다.

하지만 시간이 지나면서 Instagram은 세계에서 가장 널리 사용되는 소셜 미디어 플랫폼 중 하나로 성장했습니다. 사용자 참여의 급속한 증가는 인프라에 엄청난 부담을 주었고, 지속적인 최적화와 확장 노력이 필요했습니다.

Instagram의 규모를 강조하는 몇 가지 주요 지표(2017~2018년)는 다음과 같습니다.

• 매일 여러 번 인스타그램을 열고 수십억 건의 상호작용을 생성하는 일일 활성 사용자는 4억 명입니다.
• 하루에 1억 개의 미디어 업로드. 모든 미디어 파일은 다양한 기기에 최적화되어야 하며, 대역폭 사용량을 최소화하면서 원활한 재생을 보장해야 합니다.
• 매일 40억 개의 좋아요가 생성되고 모든 좋아요가 데이터베이스 쓰기 작업을 생성하는데, 이는 스토리지 및 쿼리 시스템의 과부하를 방지하기 위해 효율적으로 관리되어야 합니다.

 

Instagram이 초창기에 직면했던 몇 가지 과제는 다음과 같습니다.

• 수동 서버 확장: 초기에 Instagram의 엔지니어링 팀은 주말 전에 수동으로 서버를 추가하여 시스템 장애를 방지했습니다. 금요일과 주말에는 소셜 활동이 증가하여 사용자 참여가 급증하는 경우가 많았습니다. 엔지니어는 CPU 부하를 모니터링하고 예상되는 부하를 처리하기 위해 추가 서버를 프로비저닝해야 하는지 여부를 결정했습니다.
• 제한된 인프라로 인한 신뢰할 수 없는 성능: Instagram은 처음에 소수의 가상 머신을 사용하여 Amazon Web Services(AWS)에서 운영되었습니다. 인프라는 트래픽 급증을 처리하도록 최적화되지 않아 응답 시간이 느리고 가끔 중단되었습니다. 백엔드 서비스는 요청을 효율적으로 처리하는 데 어려움을 겪었고, 이로 인해 콘텐츠 로딩과 상호 작용이 지연되었습니다.
• 데이터베이스 과부하: 사진을 게시하고, 콘텐츠를 좋아하고, 계정을 팔로우하는 사용자 수가 증가하면서 Instagram의 관계형 데이터베이스에 큰 부담이 가해졌습니다. 데이터 볼륨이 커지면서 데이터베이스의 읽기 및 쓰기 작업이 느려져 플랫폼의 전반적인 성능에 영향을 미쳤습니다. 엔지니어는 쿼리를 수동으로 최적화하고 여러 데이터베이스 복제본에 부하를 이동해야 했는데, 이는 시간이 많이 걸리는 프로세스였습니다.
• 자동화된 모니터링 부족: Instagram에는 소규모 엔지니어링 팀이 있었기 때문에 서버 성능 모니터링은 수동으로 이루어졌으며, 종종 시스템 장애를 피하기 위해 지속적인 주의가 필요했습니다. 엔지니어는 기본 대시보드와 알림을 사용하여 문제를 감지했지만 성능 문제에 자동으로 대응할 실시간 시스템은 없었습니다.
• 부하 분산 부족: 여러 서버 간의 부하 분산이 완전히 자동화되지 않아 트래픽이 고르지 않게 분산되고 병목 현상이 발생했습니다.
• 엔지니어링 병목 현상: 인프라 관리가 대부분 수동이었기 때문에 엔지니어는 제품 개발에 집중하는 대신 서버를 확장하고 유지하는 데 상당한 시간을 할애해야 했습니다. 팀이 작았기 때문에 확장 노력으로 인해 기능 릴리스가 지연되고 새로운 기능을 도입하기 어려웠습니다.

인스타그램의 확장의 세 가지 차원

Instagram의 사용자 기반이 기하급수적으로 증가함에 따라, 회사는 매일 수십억 건의 상호작용을 처리할 수 있는 확장 가능한 인프라를 개발해야 했습니다. 

확장은 단순히 하드웨어를 추가하는 것이 아닙니다. 리소스를 최적화하고 엔지니어링 팀이 효율적으로 운영할 수 있도록 하는 것도 포함됩니다. Instagram은 세 가지 핵심 차원에서 확장성에 접근했습니다.

 

1 - 확장: 더 많은 서버로 인프라 확장

확장은 증가한 트래픽을 처리하기 위해 더 많은 하드웨어(서버, 스토리지, 컴퓨팅 성능)를 추가하는 것을 말합니다. 

몇 가지 새로운 전략이 채택되었습니다.

• Instagram은 AWS에서 Facebook의 데이터 센터로 이전하여 여러 서버에 워크로드를 분산하여 수평적 확장을 가능하게 했습니다. 지리적으로 분산된 여러 데이터 센터로 확장하여 높은 가용성과 중복성을 보장했습니다.
• Instagram은 몇 대의 강력한 기계에 의존하지 않고 여러 서버와 데이터 센터에 작업 부하를 분산시켰습니다. 
• 여러 데이터 센터에 사용자 요청을 분산시키기 위해 부하 분산 시스템이 구현되었습니다. 
• Instagram은 단일의 모놀리식 데이터베이스 대신, 고가용성을 위해 PostgreSQL과 Cassandra를 사용하는 분산 데이터베이스 시스템을 채택했습니다.

Facebook의 데이터 센터로 마이그레이션함으로써 Instagram은 다음과 같은 Facebook의 기존 도구와 인프라를 활용할 수 있었습니다.

• TAO : 소셜 데이터를 위한 고효율 분산 데이터베이스 시스템.
• Scuba : 성능 문제 디버깅을 위한 실시간 분석 및 모니터링 도구입니다.
• 터퍼웨어 : 페이스북의 대규모 애플리케이션을 관리하기 위한 컨테이너화된 배포 시스템.

그러나 마이그레이션은 매우 어려웠습니다. Instagram은 AWS에서 Facebook의 데이터 센터로 페타바이트 규모의 미디어 파일, 사용자 데이터 및 메타데이터를 마이그레이션해야 했습니다. 단일 "빅뱅" 마이그레이션 대신, 일관성을 보장하기 위해 두 시스템에서 데이터를 점진적으로 복사하고 동기화했습니다. Facebook의 Haystack 스토리지 시스템을 사용하여 미디어 스토리지와 검색을 최적화했습니다.

Instagram의 백엔드 서비스는 원래 AWS의 Elastic Compute Cloud(EC2)에서 실행되도록 구축되었습니다. 성능을 최적화하기 위해 이러한 서비스는 Facebook의 Tupperware 컨테이너화 시스템에서 실행되도록 재설계되어 더 나은 리소스 활용과 자동 확장이 가능해졌습니다.

2 - 확장: 각 서버의 효율성 최적화

확장은 하드웨어를 추가하는 대신 기존 인프라의 성능을 개선하는 것을 의미합니다. 여기에는 CPU 부하를 줄이고, 쿼리를 최적화하고, 캐싱 메커니즘을 사용하여 서버 효율성을 극대화하는 것이 포함됩니다.

Instagram의 경우, 비용과 리소스 제한으로 인해 더 많은 서버를 추가하는 것은 지속 가능한 장기적 솔루션이 아니었습니다. 사용자의 각 요청(피드 로딩, 게시물 좋아요, 댓글 추가)은 여러 데이터베이스 쿼리를 발생시켜 응답 시간을 늦췄습니다. 비효율적인 메모리 사용과 최적화되지 않은 Python 코드로 인해 불필요한 리소스 소비가 발생했습니다.

Instagram 엔지니어링 팀은 이러한 문제를 해결하기 위해 몇 가지 솔루션을 구현했습니다.

• 중복된 작업과 일괄 처리 요청을 줄여 데이터베이스 쿼리를 최적화했습니다.
• Memcached와 Cassandra를 사용하여 자주 액세스하는 데이터를 캐시함으로써 직접적인 데이터베이스 쿼리를 줄였습니다.
• 비효율적인 기능을 식별하기 위해 Python 코드를 프로파일링하고 이를 C++ 구현으로 대체하여 성능을 향상시켰습니다.
• 개선된 서버 메모리 관리로 RAM을 보다 효율적으로 사용할 수 있습니다.

3 - 엔지니어링 팀 확장

엔지니어링 팀을 확장한다는 것은 회사가 성장함에 따라 개발자가 계속해서 효율적으로 작업할 수 있도록 보장하는 것을 의미합니다. 여기에는 더 나은 배포 전략, 자동화, 개발 프로세스의 병목 현상 최소화가 포함됩니다.

Instagram은 작은 스타트업에서 수백 명의 엔지니어를 보유한 회사로 성장하면서 코드 관리 및 배포에 어려움을 겪었습니다. 동일한 코드베이스에서 작업하는 엔지니어가 많아지면서 병합 충돌, 회귀 및 디버깅 복잡성이 증가했습니다.

이러한 문제를 처리하기 위해 Instagram 엔지니어링 팀은 지속적인 배포를 채택했습니다. 주기적인 대규모 업데이트 대신 롤링 릴리스 모델로 전환하여 하루에 40회 이상 코드 변경을 배포했습니다. 이를 통해 필요한 경우 작은 업데이트를 테스트하고 모니터링하고 신속하게 롤백할 수 있었습니다.

새로운 기능은 전 세계적으로 출시되기 전에 일부 사용자에게 점진적으로 배포되었습니다. 엔지니어는 성능 지표를 모니터링하고 버그를 조기에 감지하여 광범위한 실패를 방지할 수 있었습니다. 또한 성능 회귀를 감지하기 위해 실시간 모니터링 도구도 구현했습니다.

Instagram의 백엔드 아키텍처

Instagram이 매일 수십억 건의 상호작용을 처리하는 플랫폼으로 성장하면서, 견고하고 확장 가능하며 효율적인 백엔드 아키텍처가 필요했습니다. 

이 시스템은 높은 가용성과 낮은 지연 시간을 유지하면서 미디어 업로드, 좋아요, 댓글, 알림을 포함한 엄청난 수의 사용자 요청을 처리해야 했습니다. 백엔드 아키텍처의 주요 구성 요소는 다음과 같습니다.

 

 

1 - Django - 핵심 웹 프레임워크

Django는 고급 Python 웹 프레임워크로 Instagram 백엔드의 기반 역할을 합니다. HTTP 요청, 사용자 인증, 데이터베이스 상호작용 및 API 엔드포인트를 처리하기 위한 핵심 구조를 제공합니다.

Django의 주요 장점은 다음과 같습니다.

• 빠른 개발 : 사전 구축된 구성요소를 통해 엔지니어는 기능을 빠르게 반복할 수 있습니다.
• 확장성 : ORM(객체 관계 매핑)을 지원하여 효율적인 데이터베이스 쿼리가 가능합니다.
• 보안 : SQL 주입 및 크로스 사이트 스크립팅과 같은 일반적인 취약점에 대한 내장형 보호 기능이 있습니다.

2 - RabbitMQ - 메시지 브로커

RabbitMQ는 메시지 브로커 역할을 하며, 다양한 서비스 간의 통신을 용이하게 합니다. 단일 요청에서 모든 것을 처리하는 대신, RabbitMQ는 비동기 작업 실행을 가능하게 하여 성능과 안정성을 개선합니다.

Instagram은 RabbitMQ를 사용하여 구성 요소를 분리하고 서로 직접 의존하지 않고도 다양한 서비스가 상호 작용할 수 있도록 합니다. 트래픽 급증을 처리하고 시스템의 한 부분이 일시적으로 실패하더라도 메시지 지속성을 관리합니다.

3 - 비동기 작업 처리를 위한 셀러리

셀러리는 RabbitMQ와 함께 백그라운드 작업을 실행하는 분산 작업 대기열 시스템입니다. 장기 실행 프로세스가 실시간 사용자 상호 작용을 늦추지 않도록 보장합니다.

Instagram은 이메일 전송이나 대용량 미디어 파일 처리와 같은 비동기 작업을 처리하기 위해 Celery를 사용합니다. Celery는 또한 작업 실패로 인해 자동으로 재시도가 발생하는 내결함성을 가지고 있습니다. Celery 워커는 여러 서버에 분산되어 높은 작업 부하를 효율적으로 처리할 수 있습니다.

구성 요소들은 어떻게 함께 작동하는가?

Instagram의 백엔드 구성 요소는 조정된 방식으로 작동하여 효율성을 보장합니다. 사용자가 게시물을 좋아할 때의 프로세스를 이해해 보겠습니다.

• 사용자 작업 : 사용자가 게시물의 "좋아요" 버튼을 탭합니다.
• Django가 요청을 처리합니다. 요청은 Django의 웹 서버로 전송됩니다. Django는 PostgreSQL 데이터베이스에서 좋아요 수를 업데이트합니다.
• 캐싱 및 비동기 처리: 게시물이 이전에 좋아요를 받은 경우, 좋아요 수는 데이터베이스를 쿼리하는 대신 Memcached에서 검색됩니다. Django는 RabbitMQ에 작업을 보내 게시물 소유자에게 좋아요에 대해 알립니다.
• RabbitMQ는 알림 작업을 대기열에 넣습니다. RabbitMQ는 알림을 즉시 처리하지 않고 나중에 처리할 수 있도록 대기열에 넣습니다.
• Celery Worker가 알림을 보냅니다. Celery Worker는 RabbitMQ에서 작업을 검색하고, 알림을 생성하고, 수신자에게 보냅니다.

Instagram 아키텍처의 스토리지 서비스

저장 서비스는 사용자 데이터, 미디어 파일 및 메타데이터를 여러 분산 데이터베이스에 저장하는 역할을 합니다. 

Instagram은 다양한 유형의 데이터를 효율적으로 관리하기 위해 구조화되고 분산된 저장 솔루션을 결합하여 사용합니다.

• PostgreSQL: 사용자 프로필, 댓글, 관계 및 메타데이터와 같은 구조화된 데이터를 저장합니다. 마스터-레플리카 아키텍처를 따라 높은 가용성과 확장성을 보장합니다. PostgreSQL은 또한 ACID 준수를 지원합니다.
• Cassandra: 사용자 피드, 활동 로그, 분석 데이터와 같은 고도로 분산된 데이터를 저장하는 데 사용됩니다. PostgreSQL과 달리 Cassandra는 이벤트적 일관성 모델을 따르므로 데이터 업데이트가 여러 지역에 전파되는 데 시간이 걸릴 수 있습니다. 높은 쓰기 처리량을 제공하므로 로깅 및 실시간 분석과 같은 작업에 이상적입니다.
• Memcached: 자주 액세스하는 데이터를 캐싱하여 데이터베이스 부하를 줄이는 데 사용됩니다. PostgreSQL 또는 Cassandra에 대한 반복적인 쿼리를 방지하기 위해 사용자 프로필, 게시물 및 좋아요 수의 임시 사본을 저장합니다. 이를 통해 API 응답 시간을 최적화할 수 있습니다.
• Haystack: 이미지와 비디오를 효율적으로 저장하여 콘텐츠를 가져오는 데 필요한 파일 시스템 작업 수를 최소화합니다. CDN을 통해 파일의 캐시된 버전을 제공하여 미디어 로딩 시간을 개선합니다.

리더-팔로워 복제를 사용한 PostgreSQL 확장에 대한 아래 다이어그램을 참조하세요.

 

또한, 아래 다이어그램은 Cassandra 확장을 보여줍니다.

 

Instagram의 저장 서비스는 여러 데이터 센터와 지역에 분산되어 있기 때문에 데이터 일관성을 유지하는 것이 가장 큰 과제입니다.

주요 데이터 일관성 과제는 다음과 같습니다.

• 복제 지연: 분산 시스템에서 데이터베이스 복제본은 동기화하는 데 시간이 걸리므로 일시적인 불일치가 발생합니다. 예를 들어, 사용자가 게시물을 좋아하지만 다른 사용자는 데이터 복제가 완료되지 않았기 때문에 업데이트된 좋아요 수를 즉시 볼 수 없습니다.
• NoSQL 시스템의 이벤트적 일관성: Cassandra는 이벤트적 일관성 모델을 사용하는데, 이는 업데이트가 여러 데이터베이스 노드에 비동기적으로 전파됨을 의미합니다. 이는 확장성을 개선하지만, 다른 사용자가 동일한 데이터의 다른 버전을 보는 일시적인 불일치를 일으킬 수 있습니다.
• 캐시 무효화 문제: Memcached는 읽기 작업을 가속화하지만 데이터베이스에 업데이트가 이루어지면 최신 변경 사항을 반영하기 위해 캐시된 데이터를 무효화해야 합니다. 예를 들어, 사용자가 프로필 사진을 변경했지만 캐시된 버전이 즉시 업데이트되지 않으면 프로필의 오래된 버전이 표시될 수 있습니다.
• 지역 간 데이터 동기화: Instagram은 여러 데이터 센터를 운영하기 때문에 데이터는 서로 다른 지리적 위치에서 동기화되어야 합니다. 네트워크 장애 또는 복제 지연으로 인해 지역 간 불일치가 발생할 수 있습니다.

Instagram 엔지니어링 팀은 이러한 일관성 문제를 해결하기 위해 여러 가지 전략을 사용합니다. 

예를 들어, PostgreSQL은 강력한 일관성이 필요한 금융 거래, 사용자 인증, 콘텐츠 조정과 같은 중요한 거래에 사용됩니다. 반면 Cassandra는 일관성의 약간의 지연이 허용되는 활동 피드와 같은 확장성이 높은 워크로드에 사용됩니다. Memcached 항목은 새 데이터가 PostgreSQL 또는 Cassandra에 기록되면 자동으로 무효화되어 오래된 정보가 제공되지 않습니다.

캐시 무효화가 처리되는 방식을 보여주는 아래 다이어그램을 참조하세요.

 

Memcache 임대 메커니즘

Instagram은 매일 수십억 건의 상호작용을 처리할 수 있도록 확장하면서, '천둥치는 무리 문제'라고 알려진 큰 문제에 직면했습니다. 

이 문제는 자주 액세스하는 데이터(예: 카운트, 사용자 피드, 댓글)에서 발생하며, 이는 빠른 검색을 위해 Memcached에 저장됩니다. 캐시된 값이 만료되거나 업데이트로 인해 무효화되면 여러 웹 서버가 데이터베이스에서 동일한 데이터를 요청합니다. 수천 또는 수백만 명의 사용자가 동시에 동일한 데이터를 요청하면 데이터베이스가 중복된 쿼리로 과부하됩니다.

이를 완화하기 위해 Instagram은 Memcache Lease 메커니즘을 구현했습니다. 이 메커니즘은 캐시 미스가 처리되는 방식을 제어하여 중복된 여러 데이터베이스 쿼리를 방지하는 데 도움이 됩니다.

 

작동 원리는 다음과 같습니다.

• 사용자가 Instagram 피드를 요청합니다. 피드의 각 게시물에는 좋아요 수, 댓글, 미디어 메타데이터와 같은 관련 데이터가 있습니다.
• 애플리케이션은 먼저 Memcached를 확인하여 이 데이터를 검색합니다.
• 요청한 데이터가 Memcached에서 발견되지 않으면, 서버는 데이터베이스를 즉시 쿼리하는 대신 Memcached에 임대 요청을 보냅니다. 데이터를 요청한 첫 번째 서버는 임대 토큰을 부여받으며, 이는 데이터베이스에서 최신 데이터를 가져오는 것을 담당한다는 것을 의미합니다.
• 동일한 데이터를 요청하는 다른 서버는 데이터베이스를 쿼리하지 않습니다. 대신 Memcached에서 오래된 값을 받거나 기다리라는 메시지를 받습니다. 이렇게 하면 하나의 서버만 데이터베이스에서 업데이트된 데이터를 가져오고 나머지는 보류합니다.
• 임대 토큰을 보유한 서버는 데이터베이스를 쿼리하고 최신 데이터를 가져옵니다. 또한 Memcached 항목을 업데이트합니다.
• 첫 번째 서버는 사용자에게 최신 데이터를 반환하고 나머지는 캐시가 다시 채워질 때까지 기다려 데이터베이스에 직접 데이터가 전송되는 것을 방지합니다.

Instagram의 배포 모델

Instagram은 지속적인 배포 모델로 운영되며, 이는 새로운 코드가 하루에 여러 번 프로덕션에 푸시된다는 것을 의미합니다. 이러한 접근 방식을 통해 Instagram은 빠르게 반복하고, 문제를 즉시 해결하고, 큰 중단 없이 새로운 기능을 도입할 수 있습니다.

Instagram의 배포 파이프라인에는 코드 검토, 자동 테스트, 카나리아 테스트, 실시간 모니터링이 포함되어 있어 새로운 변경 사항으로 인해 성능 저하가 발생하지 않는지 확인합니다.

엔지니어는 품질과 유지관리성을 보장하기 위해 코드 검토를 통해 변경 사항을 제출합니다. 모든 코드 변경은 메인 브랜치에 병합되기 전에 단위 테스트, 통합 테스트 및 성능 벤치마크를 통과해야 합니다. 코드가 병합되면 기능 또는 보안 문제를 식별하기 위해 스테이징 환경에서 자동으로 테스트됩니다. 

또한 Instagram은 모든 사용자에게 한꺼번에 변경 사항을 배포하는 대신 먼저 프로덕션 서버(카나리아 서버)의 작은 하위 집합에 업데이트를 배포합니다. 엔지니어는 핵심 성능 지표(CPU 사용률, 메모리 소비, 오류율)를 모니터링하여 새 코드가 회귀를 일으키지 않도록 합니다.

마지막으로, Instagram은 CPU 사용량도 모니터링하고 최적화합니다.

Linux 기반 프로파일링 도구를 사용하여 기능 수준에서 CPU 사용량을 추적합니다. 엔지니어는 코드베이스의 어느 부분이 가장 많은 CPU 사이클을 소모하는지 분석하고 더 나은 효율성을 위해 최적화합니다. 또한 프로파일링 도구를 사용하고 CPU 집약적인 Python 함수를 더 나은 성능을 위해 최적화된 C++ 구현으로 대체합니다.

결론

Instagram이 높은 성능과 안정성을 유지하면서도 확장성을 확보할 수 있는 능력은 잘 설계된 인프라와 배포 전략의 증거입니다.

Django, RabbitMQ, Celery, PostgreSQL, Cassandra를 활용하여 Instagram은 수십억 건의 일일 상호작용을 원활하게 처리합니다. 효율적인 리소스 활용을 지원하고 데이터베이스 부하를 최소화하기 위해 컴퓨팅 및 스토리지 서비스를 분리했습니다. Memcache 임대와 같은 기술을 구현하면 천둥 무리 문제가 방지되어 중복 쿼리가 줄어들고 시스템 안정성이 향상됩니다. 

플랫폼의 지속적인 배포 모델은 카나리아 테스트, 기능 게이팅 및 자동 롤백을 통해 위험을 최소화하는 동시에 신속한 혁신을 가능하게 합니다. 또한 실시간 CPU 추적, 성능 회귀 테스트 및 자동 모니터링을 통해 엔지니어는 사용자에게 영향을 미치기 전에 비효율성을 감지하고 해결할 수 있습니다. 

이러한 전략을 통해 Instagram은 가장 탄력적이고 확장성이 뛰어난 소셜 미디어 플랫폼 중 하나로 자리매김했으며, 성능이나 안정성을 저하시키지 않고 수백만 명의 동시 사용자, 많은 트래픽 작업 부하, 빠른 기능 개발을 지원할 수 있게 되었습니다.

참고문헌:

• 인스타그램 인프라 확장
• 설치 2부: 여러 데이터 센터로 인프라 확장
• Instagram의 힘: 수백 개의 인스턴스, 수십 개의 기술
• 소규모 팀이 Instagram을 확장하는 방법