Canva는 어떻게 수억 건의 사용자 세션을 빠르고 안전하게 유지할까?

Canva는 초당 수십만 건의 요청이 쏟아지는 수억 명의 사용자 세션을 검증하면서, 배포 때마다 게이트웨이 수백 개가 MySQL에서 100만 건 이상의 취소 기록을 읽는 병목을 해결함 최근 12시간의 기록을 30분 단위 S3 객체로 나누고, 각 기록을 16바이트로 압축·정렬해 게이트웨이가 내려받은 바이트 배열에서 직접 이진 탐색하도록 설계함 비동기 워커가 신규 취소 기록을 배치로 반영하고, S3 조건부 PUT과 낙관적 동시성 제어로 여러 워커 사이의 갱신 유실을 방지함 게이트웨이는 시작할 때 필요한 청크만 내려받고 조건부 GET으로 변경된 최신 청크를 갱신해, MySQL이 전체 플릿에 10억 행 이상을 제공하던 부하를 S3의 압축 바이너리 다운로드로 전환함 전환 후 배포가 빨라지고 데이터베이스 읽기 복제본은 이중화용 2개만 남았으며, 메모리 사용량은 87.5% 감소하고 단일 워커도 초당 2,000건 이상의 쓰기 처리량을 달성함 기존 세션 취소 구조의 병목 Canva의 모든 백엔드 요청은 로그인 사용자를 식별해야 하며, 전체 규모에서는 이 검사를 초당 수십만 번 수행함 브라우저 쿠키에 사용자 ID, 권한, 역할 등의 세션 정보를 암호화해 저장하므로, 게이트웨이는 요청마다 네트워크 데이터 저장소를 조회하지 않고도 해당 정보를 신뢰할 수 있음 로그아웃이나 권한 변경이 발생하면 기존 쿠키를 거의 실시간으로 취소하거나 갱신해야 하므로, 각 게이트웨이가 취소된 세션 기록을 보유함 요청 경로에서는 네트워크 데이터 저장소보다 빠르고 안정적인 메모리 조회를 사용함 세션 쿠키가 주기적으로 갱신되므로 메모리에는 최근 12시간의 취소 기록만 저장함 갱신 대상 토큰은 항상 MySQL에서 확인하므로 메모리 캐시에만 의존하지 않음 게이트웨이 수백 개가 시작할 때 각각 100만 건 이상의 취소 기록을 MySQL에서 가져오면서 배포가 데이터베이스를 동시에 압박함 읽기 복제본을 대량 추가하면 일시적으로 완화할 수 있지만 지속 가능한 해법은 아니었음 배포 속도를 늦추지 않으면서 MySQL 부하와 메모리 캐시 크기를 함께 줄여야 했음 Redis 대신 S3를 선택한 이유 데이터베이스와 게이트웨이 사이에 Redis를 두는 방안을 검토함 각 게이트웨이가 시작할 때 Redis에서 전체 데이터셋을 받고 이후 신규 취소 기록을 주기적으로 폴링하는 구조였음 Redis는 일반적으로 완전한 내구성 구성으로 배포되지 않으며, 별도 클러스터 운영과 캐시 일관성 관리...