-
분산 웹 캐시 (Wcache)의 개선과정 - Part 2
Overview Part 1: 분산 웹 캐시에서는 카카오의 트래픽을 처리하고 있는 Wcache에 대한 간략한 소개를 하였습니다. 이전 버전의 Wcache는 기본적으로 준수한 응답속도를 보이고 있었지만, metadata를 집중된 DB에 저장하는 방식 및 기타 구조상의 문제로 인한 성능 안정성 문제, 그리고 기능상의 문제들이 잠재되어 있었습니다. 본 포스트에서는 이전 버전의 Wcache에서 어떠한 구조적 문제가 있었는지, 또한 이를 어떻게 해결하였는지를 다룹니다. Part 2: Wcache 저장 구조 변경 저장 구조 변경 - 성능 안정화 기존 BigFile 저장방식의 문제점 이전 포스트에 나와있듯이 Wcache는...
-
분산 웹 캐시 (Wcache)의 개선과정 - Part 1
Overview 웹 서비스의 규모가 커지고 이용자의 수가 늘어날수록 서비스 제공자는 scalability 이슈에 직면합니다. 그중에서도 실제 ‘로딩 속도’의 차이를 느끼게 해 주고 트래픽의 대부분을 차지하는 정적 컨텐츠의 신속한 제공은 서비스 품질을 좌우하는 중요한 요소가 되곤 합니다. 이런 수많은 컨텐츠들(Javascript, css, image 등)을 빠르게 제공하기 위해 클라이언트와 서버 사이에 위치하며 컨텐츠를 임시로 저장하는 Middlebox를 웹 캐시(web cache)라고 합니다. 웹 캐시의 기능은 Apache Traffic Server, Nginx, Squid와 같은 어플리케이션에서 지원하고 있으며, 대량의 컨텐츠를 처리하기 위한 전용 하드웨어 형태의...
-
대규모 분산 스토리지(Kage)의 발전과정
Overview 대부분의 초기 스타트업은 컨텐츠를 저장할 저장소에 대한 별다른 고민을 하지 않습니다. 여유가 있다면 NAS 장비를 구매해서 사용하고, 아니라면 NFS와 RAID를 구성해서 사용하게 됩니다. 하지만 서비스가 점점 커짐에 따라 하루 동안 저장되는 컨텐츠의 용량이 커지고, 네트워크 트래픽과 디스크 I/O가 증가하면서 NFS, NAS로는 유지가 불가능한 상황에 처하게 됩니다. 구글(GFS, 2003)1과 페이스북(Haystack, 2011)2도 비슷한 상황을 겪었고 자체적으로 스토리지 시스템을 만들어 서비스를 유지시키는 데 성공하였습니다. 카카오 역시 초창기엔 카카오톡에서 주고받는 이미지와 동영상들을 모두 NAS에 저장하는 방식을 채택하였지만 이용자...