Pinterest가 6명의 엔지니어로 1,100만 사용자까지 확장할 수 있었던 방법
(medium.com)Pinterest의 확장 여정
Pinterest의 확장 과정은 네 단계로 나뉩니다:
- 자아 발견의 시대: 소규모 엔지니어 팀이 신속한 프로토타입 제작과 진화하는 제품 요구 사항을 관리.
- 실험의 시대: 사용자 수의 급격한 증가로 빠른 확장이 필요했으나, 복잡하고 취약한 시스템을 초래.
- 성숙의 시대: MySQL, Memcache, Redis와 같은 성숙하고 확장 가능한 기술을 사용하여 아키텍처를 단순화.
- 회귀의 시대: 적절한 아키텍처를 갖춘 후, 수평적으로 확장하여 성장 지속.
핵심 기술
Pinterest는 신뢰성, 이해하기 쉬움, 확장성을 중시하는 기술을 우선시했습니다:
- MySQL: 안정적이고 유지보수 용이한 관계형 데이터베이스.
- Memcache: 자주 액세스되는 데이터를 메모리에 캐싱하여 데이터베이스 읽기를 오프로드.
- Redis: 다양한 데이터 구조를 처리할 수 있는 유연한 데이터 저장소.
- Solr: 빠르게 사용 가능한 검색 플랫폼.
데이터베이스 확장: 클러스터링 vs 샤딩
Pinterest는 데이터베이스를 분산 처리하기 위해 두 가지 접근 방식을 고려했습니다:
클러스터링
- 데이터가 도착하면 최적의 노드를 결정하고 데이터를 여러 노드에 복제.
- 자동 확장, 설정 용이, 데이터 가용성 보장 등의 장점이 있으나 복잡성, 성숙도 부족, 업그레이드 어려움 등의 단점 존재.
샤딩
- 데이터를 작은 청크로 나누어 각 청크를 독립된 서버에 배치.
- 단순한 아키텍처, 독립적인 확장, 명확한 데이터 소유권 등의 장점이 있으나 데이터베이스 수준의 조인과 트랜잭션이 불가능, 애플리케이션 복잡성 증가 등의 단점 존재.
Pinterest는 클러스터링에서의 부정적 경험으로 인해 샤딩을 선택했습니다.
샤딩 아키텍처로의 전환
Pinterest는 기능 동결 동안 단계적으로 샤딩으로 전환했습니다:
- 조인 제거: MySQL 조인을 모두 제거하고 데이터 비정규화 및 캐싱 활용.
- ID 기반 샤딩: 64비트 ID 기반으로 샤딩하여 데이터 라우팅 단순화.
샤딩의 단점 및 해결책
- 마이그레이션 스크립트: 데이터를 샤딩 인프라로 전송하는 과정에서 시간이 많이 소요.
- 애플리케이션 로직: 데이터베이스 수준의 조인과 트랜잭션 부재로 인해 데이터 일관성 유지 필요.
- 스키마 수정: 모든 샤드에 대해 스키마 변경을 계획하고 적용.
- 보고서 생성: 여러 샤드를 통합하여 보고서 생성.
교훈
Pinterest의 확장 여정에서 얻은 주요 교훈:
- 단순함이 중요: 이해하기 쉬운 기술 선택이 문제 해결과 위험 감소에 도움.
- 확장성 우선: 급속한 성장 환경에서는 데이터베이스 기능을 희생하더라도 확장성을 우선.
- 수평적 확장 설계: 사용자 기반이 확장됨에 따라 리소스를 추가할 수 있는 아키텍처 선택.