최근에 작업이 마무리되서 오랜만에 글 쓰네요.

이번 글은 시스템 설계에 대해 공부하다가 관련 좋은 논문을 봐서 가져왔습니다.

글의 주제는 "Facebook 에서 캐시 데이터의 일관성을 관리하는 방법' 이에요.

Facebook 의 시스템은 초당 수십억 개의 요청이 들어온다고 합니다.

이런 대규모 트래픽 상황에서는 일관성을 유지하는 것은 적은 트래픽일 때보다 훨씬 복잡할건데요.

본문에서는 Facebook이 이런 과도한 트래픽 상황에서 어떻게 캐시 데이터와 영속성 데이터의 일관성을 유지하는지 소개해볼게요.

본 글은 Facebook 에서 발표한 논문인 Scaling Memcache at Facebook 를 참고해서 많이 요약한 글입니다.

해당 논문에서는 캐시 서버를 페이스북 트래픽에 맞게 확장하는 방법도 상세히 소개하니, 궁금하시면 원문을 확인해 보는 걸 추천드립니다.

링크는 아래에 적어둘게요.

<1. High-Level Overview of Facebook's System>

시스템 구조는 그림으로 봐도 좋을 것 같은데요. 아래의 설명과 첨부한 이미지를 비교해보면서 보면 더 이해하기 쉬울 것 같습니다.

먼저, Facebook은 전 세계에 걸쳐 클러스터를 여러 지역(Region)으로 분산하여 관리하고 있구요, 각 지역은 다음과 같은 구성 요소로 이루어져 있습니다:
 * Front-End Clusters (웹 서버 + Memcached): 사용자의 요청을 처리하고 데이터를 캐싱하여 빠른 응답 시간을 보장하는 역할을 합니다.
 * Storage Cluster (MySQL 등): 실제 사용자 데이터와 시스템 정보를 저장하는 역할을 합니다.
 
Storage Cluster와 Front-End Cluster의 상호 작용:
 * Storage Cluster 에서 생성된 데이터는 Front-End Cluster 내의 Memcached 로 복제되어 사용자에게 빠른 데이터 접근을 제공하구요. 또한, Storage Cluster 는 캐시 무효화 요청을 통해 기본적으로 Memcached 에 최신 데이터를 유지하려고 합니다. 

다중 Region 과 데이터베이스 구성:
 * Facebook은 다수의 Region 을 사용하며, 각 Region 마다 데이터베이스 Master 와 Slave 로 구분합니다.

Front-End Clusters 의 다중화:
 * 하나의 지역 내에서도 Front-End Clusters 는 여러 개로 분리됩니다. 이렇게 분리된 이유는 다음과 같습니다:
   * Network Incast Congestion: 네트워크 내 많은 호스트가 동시에 소수의 수신자(예: Memcached)에 데이터를 전송할 때 발생하는 네트워크 혼잡 현상입니다. 이 현상은 네트워크 대역폭 병목 현상으로 이어져 패킷 손실과 지연 시간 증가의 문제를 일으킬 수 있습니다.
   * Fault Tolerance: 여러 개의 Cluster 로 분리함으로써, 하나의 Cluster 가 실패하더라도 다른 Cluster 들은 안전하게 운영될 수 있습니다.

캐시 스토어로 Memcached 선택:
 * 저지연 및 고성능 (Low Latency, High Performance) 과 제한된 엔지니어링 자원 및 시간 (Limited Engineering Resources and Time) 을 고려했을 때 Memcached 를 선택헀습니다. (개발팀에 익숙한 기술을 이유로 선택한 것 같습니다.)
 
<2. How Facebook Manages Cached Data>

Facebook에서는 Memcached에 두 가지 주요 유형의 데이터를 저장합니다:
 * Query Cache: 이는 주로 데이터베이스에서 직접 조회할 수 있는 데이터로 구성됩니다. 이 데이터 캐싱 목적은 데이터베이스의 부하를 분산시키는 것으로, 데이터베이스에 대한 직접적인 쿼리 수를 줄이기 위해 캐시에 저장합니다. 
 * Generic Cache: 이 데이터는 머신러닝과 같은 애플리케이션에서 사전 계산된(pre-computed) 결과들로 구성됩니다. 이러한 종류의 데이터는 사용자의 시청 이력과 선호도와 같이 다양한 애플리케이션에서 활용될 수 있는 데이터들을 말합니다.

Facebook은 데이터를 처리하는 두 가지 주요 경로, 즉 읽기 경로와 쓰기 경로에서 Memcached를 활용합니다:
 * Read Path: 'Look Aside' 패턴을 사용합니다. 즉 먼저 캐시에 데이터를 조회해보고, 캐시에 해당 데이터가 없을 경우엔 데이터베이스에서 조회한 후, 이를 캐시에 저장(Set)하는 방법입니다.
 * Write Path: 데이터베이스에 데이터를 쓴 후, 캐시에 해당 데이터를 무효화합니다. 데이터를 직접 업데이트하는 것도 가능하지만, 캐시 무효화 작업은 데이터의 일관성을 보장하는 멱등성 있는 연산이기 때문에 이걸 사용합니다. 

총 2가지의 캐시 무효화 과정:
 * 1) 웹 서버는 데이터를 Storage Cluster 에 있는 영속성 저장소에 업데이트된 후, 자신의 로컬 캐시인 Memcached 에 캐시 무효화 요청을 합니다. 이 과정은 완벽한 일관성을 보장하지는 않지만, 빠른 갱신과 기본적인 일관성은 보장할 수 있습니다.
 * 2) 'Invalidation Batch Processing' 을 통해 클러스터 전체에 캐시 무효화 요청을 전달합니다. 이는 데이터베이스에서 커밋된 로그를 바탕으로 모든 변경 사항을 감지하고, 해당 지역의 모든 Front-End Cluster 에 있는 Memcached 서버에 무효화 요청을 보내는 과정입니다. 중요한 건 이 요청들은 직접적으로 Memcached 로 요청이 전달되진 않습니다. 중간 라우터 계층인 mcrouter 를 통해 캐시 무효화 과정은 Memcached 로 전달됩니다.

mcrouter의 역할:
 * mcrouter는 이러한 캐시 무효화 요청을 관리하는 컴포넌트입니다. 배치 프로세스에서 Memcached 로 직접 캐시 무효화 요청을 전송하면 해당 시스템에 과부하가 발생할 수 있어, mcrouter를 사용하여 이를 방지하는 목적으로 사용합니다.
 * mcrouter 인스턴스는 배치 요청을 받아 적절한 Memcached 서버로 라우팅하는 역할을 합니다. 또한, Memcached 가 응답하지 않을 경우를 대비해 캐시 무효화 요청을 내부적으로 버퍼링하는 기능을 갖추고 있습니다.

<3. How Facebook Ensures Cache Data Consistency>

Facebook Design Goals:
 * Facebook의 설계 목표는 대규모 트래픽을 효과적으로 처리하는 것입니다. 이를 위해 일관성(Consistency)만을 고려할 수는 없으며, 일관성과 성능(Performance) 사이의 균형을 찾는 것이 중요합니다. 그래서 Facebook 은  Strong Consistency 를 보장하는 대신 Eventually Consistency를 채택합니다. 

근본적인 일관성 문제의 원인:
 * 캐시 데이터와 영속성 저장소 사이의 일관성 문제는 주로 데이터 복제 지연 때문에 발생합니다. 만약 복제 지연이 없다면 캐시 무효화를 통해 일관성을 유지할 수 있습니다. 하지만 복제 지연이 발생하는 상황에서 슬레이브 데이터베이스에서 오래된 데이터를 검색할 경우, 캐시 무효화 이후에도 캐시에 오래된 데이터가 설정될 위험이 있습니다.

Facebook 에서의 일관성 보장 전략:
 * 결론부터 말하자면 복제 지연이 생겼다고 판단되는 경우에 데이터 조회를 Slave 에서 하지 않고 Master 에서 할 수 있도록 라우팅 전략을 수립하는 것입니다.
 
일관성을 보장하는 매커니즘:
 * 1) 원격 마커 설정: 데이터 업데이트를 원하는 웹 서버는 먼저 해당 리전에 대한 원격 마커 rk 를 설정합니다. 이 마커는 Slave 데이터베이스의 데이터가 오래된 것 일 수 있음을 나타냅니다.
 * 2) Master 데이터베이스에 쓰기: 서버는 마스터 데이터베이스에 쓰기를 수행하면서, 해당 쓰기 작업이 무효화되어야 할 키 k 와 원격 마커 rk 를 SQL 문에 포함시킵니다. 이는 마스터에서의 변경 사항이 복제될 때까지 rk 를 유지하게 만들어, 복제가 완료된 후에만 rk를 무효화하도록 만드는 과정입니다. 
 * 3) 로컬 클러스터에서의 키 삭제: 서버는 로컬 클러스터에서 키 k를 삭제합니다. 이렇게 하면 후속 요청이 발생했을 때, 로컬 캐시에서 k 를 찾을 수 없게 되고, 웹 서버는 rk 의 존재 여부를 확인합니다. 
 * 4) 쿼리 리디렉션:  웹 서버는 rk의 존재 여부를 확인하고, rk가 존재한다면 쿼리를 마스터 리전으로, 그렇지 않다면 로컬 리전으로 리디렉션합니다.

rk 를 삭제하는 타이밍은?
 * 복제 작업이 완료될 때, 이전에 본 배치 프로세스에서 데이터베이스 로그를 보고 삭제해야 할 rk 를 판단해서, 캐시 무효화 요청을 전달하는 작업을 통해 삭제됩니다.

이 방법의 한계점:
 * rk 는 동시성 상황에서 Race Condition 으로 인해 여전히 존재할 수 있습니다. 그러나 Facebook은 이러한 상황이 매우 드물기 때문에 문제로 보지는 않습니다.
 * 복제 지연 상황에서는 마스터 데이터베이스로의 질의가 증가하는 것을 피할 수 없습니다.

운영 고려사항:
 * 복제를 위해 리전 간 통신은 비용이 많이 들고 네트워크 지연(latency)을 증가시키므로, 데이터베이스 복제와 삭제 스트림을 위한 전용 통신 채널을 구축하여 네트워크 효율성을 향상시킵니다.
 * Memcached가 응답하지 않을 때를 대비해야합니다. Facebook 은 캐시 무효화 요청을 버퍼링할 수 있도록 만들고, Memcached 가 다시 작동하게 되면 캐시 무효화 요청을 재생할 수 있도록 구축했습니다.
 
https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf

Facebook 이 캐시 데이터 일관성을 관리하는 방법

카카오의 AI 네이티브 전략과 그 구현 과정에 대한 깊은 통찰을 제공합니다. 카카오가 AI 기술을 단순한 기능 추가가 아닌, 조직 문화와 프로세스 전반에 깊이 통합시켜 새로운 사용자 경험을 창출하고자 하는 노력을 보여줍니다. 특히, AI 버디와 코드 버디와 같은 도구를 통해 업무 효율성을 높이고, 개발자가 더욱 나은 코드를 작성하도록 돕는 과정이 자세히 설명됩니다. 카카오는 AI 기술의 발전을 통해 일상에서의 혁신을 추구하며, 궁극적으로 모든 사용자가 더욱 편리한 일상으로 나아갈 수 있도록 하는 목표를 가지고 있습니다

⏲️ Time Stamps 
00:00 오프닝
01:08 카카오의 AI native
03:20 AI Native 성숙도 4단계
04:00 1단계 탐색
05:49 2단계 적용
06:26 AI Buddy, Code Buddy
22:17 KAP
25:15 AI 포인트 서비스
27:06 3단계 혁신
27:30 4단계 일상

유튜브에서 보기
https://youtu.be/fiD7XvBA_cs

카카오의 AI 전략 AI Native  소개

behavioral 질문할건데.. 경험이 20개정돈 아닌데.. 어떻게 해야할까요.

최소한 어느 질문에 대한 답을 원할까요?

ex)제가 들은 질문은 ~에요
저라면 ~는 최소한 물어볼 것 같아요

의 답변 주시면 최대한 제가 경험을 짜내볼텐데 어렵네요. 넋두리 들어주셔서 감사합니다.

경력이직 질문

people data analyst

정은하

Kakao krew

김준석

kakao crew

주영성

kakao 서비스디자이너

lexa.chic

kakao UX 디자이너

오다슬

kakao UI디자이너

김주리

kakao 매니저

corgi

Brand Thinking

Evan

kakao 프로젝트 매니저

김현정

kakao 서비스기획

bella

kakao business

스테파노

Kakao

굼굼

kakao 데이터 사이언스

김남윤_Ethan

kakao staff

owen.lee

kakao 개발자

milkyroad

kakao 서비스/데이터 기획자

최가영 (kyra)

kakao 팀원

정준모

kakao 기획

jaimie

kakao QA

TAEMI KIM

디자인

선종화_mark

kakao 백엔드 개발자

이동준 (jun.e)

김진우

kakao Story Planning Assistant

Isoo Chang

이다은

소프트웨어 엔지니어

안정수

kakao 학생

정지은

@kakao

Nesoy

kakao ux

은주serena

jayjun_류재준

프리

KAKAO 사업기획

김지희_chelsea.h

kakao 실장

oliver.han_한형진

kakao 마케팅

정고은_Jane

보안 엔지니어

김동영

kakao 서비스기획자

김성훈_sephi.sh

software engineer 

kakao 머신러닝 엔지니어

Kim Hyungjun

고려대 미디어대학원 광고

박진형

 ios 개발자

helloworld

박상오 sharky

kakao BX 디자이너

miranda

kakao 프론트엔드 개발자

박주현 carter

김성수 liter

kakao 데이터 엔지니어

채록

조현기

포항공과대학교 컴퓨터공학

신성열_Tomo

kakao fe

vercel

카카오 브랜드 마케터

위클리 파이브

카카오 브랜드마케터

조은송

카카오 프론트엔드/iOS 개발자

riky

프로덕트 매니저

한수희

카카오

밥은먹고다니니

베이스 인베스트먼트 / Founder&Partner

강준열

카카오 전사전략 파트너십 매니저

이상현

카카오 / 애자일 코치

백미진

카카오 서비스 기획

유현석

김윤태

윤정수

카카오 매니저

송승원

카카오 클라우드

양재영

카카오 프로덕트 매니저

원예림

디지털 헬스케어 사업 기획/프로덕트 메니저

이동훈

강종수

카카오 UX 디자인

쥬노

카카오 서비스기획

김준수

카카오 계정개발

전준호

카카오 운영

클레이드

브랜더

김키미

김아름

임승미

정주호

박성진

카카오 서비스PM

고성훈 

UI 디자이너

정지훈

카카오 스텝

카카오 aml

조은아

카카오 콘텐츠md

박소정

카카오 머신러닝 엔지니어

김창연

카카오 IP 콘텐츠 기획자

김경민

카카오 콘텐츠 기획

강초롱

카카오 부장

전기영

플랫폼사업 매니저 

이지현

카카오 없음

신다정

한홍연

카카오 pm

카카오 디자이너

choi.latte

이현지.selena

양지민

Co-founder

유한묵

임택근_Kyle(카일)

카카오 소프트웨어 엔지니어

김수웅

카카오 개발자

김준호

카카오 ux디자인

로건

카카오 팀원

이수민_turner

한솔

강기우_sans

카카오 PR팀 매니저

임철웅

언어

프론트엔드

백엔드

데이터베이스

데브옵스

javascript

Java

Kotlin

typescript

python

Scala

swift

Objective-C

Angular

ReactJS

Redux

Vuex

VueJS

Next.js

Recoil

Electron

GraphQL

ReactiveX

기술 스택

언어

javascript

Java

Kotlin

typescript

Go

python

Scala

C++

swift

Objective-C

R

프론트엔드

Angular

ReactJS

Redux

Vuex

VueJS

Next.js

Recoil

Electron

GraphQL

ReactiveX

Unity

OpenGL

Styled-Components

React Query

MobX

백엔드

NestJs

Spring

SpringBoot

Node.js

Flask

Hibernate

RabbitMQ

GRPC

Armeria

WebRTC

데이터베이스

PostgreSQL

Redis

mongodb

Elasticsearch

Memcached

CassandraDB

Greenplum

ArangoDB

Arcus

MySQL

데브옵스

Argo CD

Jenkins

OpenEBS

Kubernetes

Docker

Github

Jaeger

Github Action

Istio

Go CD

Rundeck

Vault

카카오