Articles by KENNETH

분산 웹 캐시 (Wcache)의 개선과정 – Part 1 Overview 웹 서비스의 규모가 커지고 이용자의 수가 늘어날수록 서비스 제공자는 scalability 이슈에 직면합니다. 그중에서도 실제 ‘로딩 속도’의 차이를 느끼게 해 주고 트래픽의 대부분을 차지하는 정적 컨텐츠의 신속한 제공은 서비스 품질을 좌우하는 중요한 요소가 되곤 합니다. 이런 수많은 컨텐츠들(Javascript, css, image 등)을 빠르게 제공하기 위해 클라이언트와 서버 사이에 위치하며 컨텐츠를 임시로 저장하는 Middlebox를 웹 캐시(web cache)라고 합니다. 웹 캐시의 기능은 Apache Traffic Server, Nginx, Squid와 같은 어플리케이션에서 지원하고 있으며, 대량의 컨텐츠를 처리하기 위한 전용 하드웨어 형태의 상용 솔루션도 있습니다. 본 포스트에서는 카카오에서 자체적으로 개발하여 운영 중인 웹 캐시, Wcache에 대한 간략한 소개를 진행하고 올해 상반기에 진행되었던 대대적인 구조 개편 내역을 다음 포스트에 설명하고자 합니다. Part 1: 분산 웹 캐시, Wcache 개발 배경 및 기본적인 기능 기존에 웹 캐시로 사용되던 상용 솔루션의 문제점은 아래와 같았습니다. 장비 대수가 증가함에 따라 늘어나는 라이센스 비용. 버그 수정 [ more… ]

분산 웹 캐시 (Wcache)의 개선과정 – Part 2 Overview Part 1: 분산 웹 캐시에서는 카카오의 트래픽을 처리하고 있는 Wcache에 대한 간략한 소개를 하였습니다. 이전 버전의 Wcache는 기본적으로 준수한 응답속도를 보이고 있었지만, metadata를 집중된 DB에 저장하는 방식 및 기타 구조상의 문제로 인한 성능 안정성 문제, 그리고 기능상의 문제들이 잠재되어 있었습니다. 본 포스트에서는 이전 버전의 Wcache에서 어떠한 구조적 문제가 있었는지, 또한 이를 어떻게 해결하였는지를 다룹니다. Part 2: Wcache 저장 구조 변경 저장 구조 변경 – 성능 안정화 기존 BigFile 저장방식의 문제점 이전 포스트에 나와있듯이 Wcache는 metadata 정보를 컨텐츠와는 별도로 DB에 저장해 두고 있었습니다. 메모리에 올라와 있는 LRU hashtable에 원하는 컨텐츠가 캐싱되어 있지 않다면, SQLite DB에 컨텐츠 키를 가지고 어떤 BigFile에 있는지, 헤더의 길이는 얼마나 되는지 등의 정보들을 조회를 해야 하는 것이죠. 위 과정은 평상시 읽는 과정에서는 문제가 없었지만, block 단위로 컨텐츠를 디스크에 저장할 때와 BigFile이 가득 차 오래된 BigFile block들을 replace 할 [ more… ]