대표적인 비즈니스 네트워킹을 지원하는 소셜 네트워크인 Linkedin 이 규모가 커지면서 어떻게 대용량 트래픽을 처리하게 되었는지 정리해 보았습니다. 

 

이 글에서는  대규모 트래픽을 처리하기 위한 ‘확장성’ 을 지원하기 위한 방법들에 대해서 간략하게 소개할게요. 

 

Linkedin 이 어떠한 최신 기술들을 도입했는지, 개발자 경험은 어떻게 개선했는지 등의 내용은 원문을 통해 보시는 걸 추천드립니다~ 

 

Linkedin 의 트래픽 처리 기술

1. Monolithic Architecture 를 독립된 Microservice 로 전환: 

 

이 결정은 독립된 마이크로서비스로 변경함에 따라서 Scale-out 을 쉽게 하기 위함, 가용성 문제를 해결하기 위함, 그리고 새로운 기능을 쉽게 추가하기 위함이라고 합니다. 

 

초기에 Linkedin 은 모놀리식 서비스의 Scale-out 과 Database Replication 을 통해 부하를 분산하는 식으로 해결했지만, 시스템의 부분적인 실패가 전체 시스템에 영향을 미치지 않도록 하기 위해서, 그리고 서비스의 새로운 기능을 쉽게 릴리즈 하기 위해서 Microservice 로 전환 했다고 합니다. 

 

Linkedin 의 마이크로서비스 개수는 2015년 기준으로 750개 이상의 서비스를 구축했다고 합니다. 

 

 

2. 독립적인 Member Graph Service 서비스 도입

 

Linkedin 의 특성상 회원 간 연결이 중요한 만큼 회원들 간의 관계를 보여주는 건 단일 모노리식 서비스로는 감당이 안 되었기 때문에 독립적인 서비스로 분할했다고 합니다.

 

그래서 확장성이 있고, 초당 수십만 건의 쿼리를 처리할 수 있는 독립적인 그래프 서비스를 개발했다고 합니다. 

 

이 그래프 서비스를 위해서 높은 가용성과 내구성을 그리고 파티셔닝을 지원하는 GraphDB 를 선택했고, 회원과 네트워킹 정보를 저장하는 분산 캐시 서비스를 도입해서 적용했다고 합니다. 

 

3. 독립적인 Search Service 도입 

 

Member Graph Service 와 마찬가지로 LinkedIn 의 핵심 서비스 중 하나는 검색 서비스입니다. 

 

사람들은 이런 검색 서비스를 통해서 사람들을 찾고, Jobs 을 찾고, Companies 를 찾을 수 있습니다. 

 

그리고 개인화된 검색 기능까지 필요하다고 요구사항을 정의했기 때문에 Lucene 기반의 검색 서비스를 만들어야겠다고 판단했다고 합니다. 

 

4. Caching Service 도입 

 

더 나은 확장성을 도입하기 위해서 Linkedin 은 Caching 을 도입하기로 결정했는데요. 

 

Linkedin 이 택한 캐싱 전략은 다음과 같습니다: 

  • 미드 티어 캐싱: Memcached 및 Couchbase 와 같은 캐싱 솔루션을 어플리케이션과 데이터베이스 사이에 둬서 다양한 도메인과 파생된 데이터를 저장하도록 했습니다. 이 캐시의 목적은 데이터베이스에 대한 요청을 줄이고 응답 시간을 단축하기 위함이라고 합니다. 
  • 데이터 레이어 캐싱: Voldemort 라는 AWS 의 DynamoDB 와 같은 캐싱을 사용해서 데이터베이스에 저장된 데이터들을 사전 계산한 값을 저장해둬서 데이터베이스의 부하를 줄였다고 합니다. 그리고 데이터베이스에 가깝게 배치해서 데이터베이스와의 통신 지연을 최소화 했다고 합니다. 

 

하지만 시간이 지나면서 캐싱 솔루션의 대표적인 문제인 캐싱 데이터와 데이터베이스의 데이터가 일관성이 안 맞는 문제가 생겨서 결국 미드 티어 캐싱은 제거했다고 합니다. 

 

5. Kafka 도입 

 

Linkedin 이 성장하면서 데이터의 양도 급격하게 증가했다고 합니다. 이러한 데이터를 효율적으로 수집하고 분석하기 위해서 데이터를 데이터 웨어하우스에 적재하기로 했고, 이러한 솔루션으로 Kafka 를 도입했다고 합니다. 

 

Kafka 는 대량의 데이터를 스트리밍하고 큐잉하기 위해 적절하므로 이를 선택했다고 합니다. 

 

References:

 

+ Recent posts