LinkedIn에서 약 10억 명 가까운 사용자 프로필이 초당 400만 번 이상 조회된다고 한다. 이 큰 규모의 사용량을 견뎌내기 위해 LinkedIn 개발팀은 어떤 작업이 필요했을까? → 초기 LinkedIn은 Oracle Database와 Memcached을 사용한 캐쉬 레이어를 구축한 일반적인 서비스 스택을 구성했다. → 서비스가 커짐에 따라 Oracle Database의 단점들(라이선스 비용, 확장성 제한, 유지보수 어려움)이 드러나기 시작했고, Memcached 클러스터 역시 투자 대비 성능을 제대로 발휘하지 못했다. → LinkedIn 개발팀은 2010년 초에 유행한 NoSQL 흐름에따라 Expresso NoSQL Database를 자체 개발하여 LinkedIn 내부 서비스들의 DB로 사용하기 시작했다. Expresso는 Memcached와 같은 캐싱 레이어를 따로 구축하지 않아도 범위성과 성능 요구 사항을 모두 충족시킬 수 있었다. → 수년 동안 Expresso를 기반으로 한 프로필 조회 서비스는 LinkedIn과 함께 폭발적인 성장을 이뤄냈다. → 하지만 Expresso도 초당 100만 번을 넘어갈때 쯤 성능 문제가 생기기 시작했다. 개발팀은 다시 한 번 캐시 레이어를 고려해보기로 한다. → LinkedIn 개발팀은 Couchbase를 사용하여 성능을 개선하는 성공 사례가 이미 여러 개 있었다. 프로필 조회 서비스 개발팀은 Expresso 시스템에 Couchbase 기반의 캐싱 레이어를 포함한 시스템을 설계에 도전한다. → 이미 복잡한 시스템에 내포된 커스텀 캐싱 솔루션으로 인해 어려운 문제들을 해결해야 했다. Couchbase 시스템의 효과적인 모니터링이 필요했고, 무효한 캐쉬데이터를 재때 재거할 있도록 System Change Number (SCN)을 함께 저장하는 등 시스템에 많은 새로운 요소들이 필요했다. → 결과적으로 Expresso + Couchbase를 함께 사용한 서비스는 99백분위수 기준으로 60% 이상의 성능 개선이 있었고, 99% 이상의 캐시 히트 비율 덕분에 전체 서비스 비용을 10% 절감할 수 있었다. 무었보다 새로운 시스템은 앞으로 몇 년간의 성장을 충분히 견뎌낼 수 있을거라 개발팀은 예상한다고. https://engineering.linkedin.com/blog/2023/upscaling-profile-datastore-while-reducing-costs https://engineering.linkedin.com/espresso/introducing-espresso-linkedins-hot-new-distributed-document-store