Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Canva는 수억 명의 사용자 세션을 검증하는 과정에서 발생하는 MySQL 병목 현상을 S3 기반의 바이너리 청크 방식으로 해결했습니다. 12시간의 취소 기록을 30분 단위의 압축된 바이너리 객체로 관리하여 데이터베이스 부하를 줄이고 메모리 사용량을 87.5% 절감했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Canva의 모든 백엔드 요청은 로그인 사용자를 식별해야 하며, 전체 규모에서는 이 검사를
초당 수십만 번 수행함
브라우저 쿠키에 사용자 ID, 권한, 역할 등의 세션 정보를 암호화해 저장하므로, 게이트웨이는 요청마다 네트워크 데이터 저장소를 조회하지 않고도 해당 정보를 신뢰할 수 있음
로그아웃이나 권한 변경이 발생하면 기존 쿠키를 거의 실시간으로 취소하거나 갱신해야 하므로, 각 게이트웨이가
취소된 세션 기록을 보유함
요청 경로에서는 네트워크 데이터 저장소보다 빠르고 안정적인 메모리 조회를 사용함
세션 쿠키가 주기적으로 갱신되므로 메모리에는 최근
12시간의 취소 기록만 저장함
갱신 대상 토큰은 항상 MySQL에서 확인하므로 메모리 캐시에만 의존하지 않음
게이트웨이 수백 개가 시작할 때 각각 100만 건 이상의 취소 기록을 MySQL에서 가져오면서 배포가 데이터베이스를 동시에 압박함
읽기 복제본을 대량 추가하면 일시적으로 완화할 수 있지만 지속 가능한 해법은 아니었음
배포 속도를 늦추지 않으면서 MySQL 부하와 메모리 캐시 크기를 함께 줄여야 했음
데이터베이스와 게이트웨이 사이에 Redis를 두는 방안을 검토함
각 게이트웨이가 시작할 때 Redis에서 전체 데이터셋을 받고 이후 신규 취소 기록을 주기적으로 폴링하는 구조였음
Redis는 일반적으로 완전한 내구성 구성으로 배포되지 않으며, 별도 클러스터 운영과 캐시 일관성 관리가 필요함
데이터 저장소 문제를 다른 저장소로 옮기면서 복잡성까지 늘어나는 선택이었음
필요한 조건은
강한 내구성 보장과 대량 데이터의 효율적인 읽기였으며, 크고 내구성 있게 저장된 파일을 저비용으로 내려주는 S3가 이에 부합함
세션 취소 데이터는 정적 바이너리 객체가 아니라 시간이 흐르면서 범위가 이동하는
슬라이딩 윈도우이므로, 객체 저장소에 맞는 변환이 필요했음
12시간 슬라이딩 윈도우를
30분 구간으로 나누고 각 구간을 하나의 S3 객체로 저장함
게이트웨이는 최신 청크만 가져오므로 오래된 취소 기록을 S3에서 개별 삭제할 필요가 없음
전체 다시간 윈도우 대신 작은 30분 블록만 갱신할 수 있음
다만 취소 기록 하나를 추가하려면 수십만 건이 담긴 청크를 내려받아 다시 올릴 수 있음
각 취소 기록은 적용 대상인
principal과 취소가 적용되는 로그인 시각의 상한을 포함함
일반적으로 특정 시각 이전에 시작된 모든 세션을 취소하는 방식임
비트 단위 조작으로 두 정보를 16바이트에 담음
청크는 16바이트 원소로 구성된 평면 배열이며, principal 기준으로 정렬해 특정 대상의 취소 기록을
이진 탐색할 수 있음
게이트웨이는 청크를 다른 표현으로 변환하지 않고 내려받은 바이트에서 직접 검색함
캐시 적재 비용은 사실상 S3 다운로드뿐임
기록마다 여러 Java 객체를 만들던 방식보다 메모리 사용량이 8분의 1로 줄어듦
단순 로그아웃 외에도 여러 취소 유형을 지원함
로그아웃 없이 쿠키에 캐시된 일부 정보만 무효화할 수 있음
단일 사용자가 아니라 전체 브랜드를 대상으로 지정할 수 있음
일부 비트를 플래그로 예약하되 principal 순서를 유지해 여러 취소 유형을 같은 평면 배열에 저장함
취소 기록이 생길 때마다 S3 청크를 다시 쓰는 비용을 피하도록
비동기 워커가 갱신을 담당함
데이터베이스를 계속 스캔해 아직 S3에 업로드되지 않은 취소 기록을 큰 배치로 가져옴
최신 청크를 내려받거나 충분한 시간이 지났다면 새 청크를 생성함
신규 기록을 정렬 배열에 삽입한 뒤 청크를 다시 업로드함
고가용성과 배포 편의를 위해 워커를 여러 개 실행하지만, 단순 구현에서는 서로의 변경을 덮어써 취소 기록이 사라질 수 있음
S3
조건부 PUT으로 낙관적 동시성 제어를 구현함
청크를 처음 읽은 뒤 변경되지 않았다는 사전 조건을 모든 갱신에 적용함
새 청크를 만들 때도 다른 프로세스가 같은 객체를 먼저 생성하지 않았는지 검사함
각 읽기-수정-쓰기 작업이 S3의 취소 기록 집합에 항목을 추가하기만 하도록 보장해, 실행 순서가 섞여도 데이터를 잃지 않음
N개로 청크를 구성하는 시간은 대략 O(N²)
임
각 청크에는 특정 30분 동안 생성된 모든 취소 기록이 들어 있음
모든 토큰이 12시간 안에 갱신되므로 게이트웨이 시작 시 최근
12시간에 해당하는 청크만 내려받음
객체 이름에 30분 구간의 시작 시각을 인코딩해, 기준 시각 이후의 키를 정렬 순서로 효율적으로 찾음
배포 때만 신규 기록을 받는 상황을 피하도록 S3
조건부 GET으로 실제 변경된 최신 청크만 다시 내려받음
30분 구간에 취소 기록이 100만 건이어도 청크 크기는 16MB임
이를 분당 몇 차례 전송해도 게이트웨이가 중계하는 전체 요청·응답 데이터에 비하면 작은 규모임
청크 구간의 종료 시점이 12시간보다 오래되면 메모리 캐시에서 바로 제거함
게이트웨이마다 여전히 같은 수의 취소 기록을 받지만, MySQL이 전체 플릿에 10억 행 이상을 제공하는 대신 S3에서 압축 바이너리를 내려받음
게이트웨이 하나에는 수십 MB지만 전체 플릿에서는 수십 GB에 해당함
새 시스템으로 이전한 뒤
배포 속도가 개선됐고, 세션 취소 데이터베이스의 읽기 복제본은 이중화를 위한 2개만 유지함
Java 힙에 취소 기록마다 여러 객체를 만들지 않으면서 캐시 메모리 사용량이
87.5% 감소함
이전 데이터베이스 부하는 지난 수시간의 쓰기 수와 동시에 캐시를 받는 게이트웨이 수에 좌우됐지만, 새 구조에서는 쓰기 처리량과 전체 사이트 트래픽에 따라 예측 가능하게 증가함
단일 워커가 수십만 건을 계속 정렬하는 구조도 실제 요구량을 충족했으며, 조밀한 배열을 처리하는 현대 시스템에서는 상수 계수가 크게 작용함
수십만 건이 한 배열에 있어도 워커의 병목은 계산보다
네트워크 지연 시간이었음
여러 분산 시스템 설계의 모의 구현을 실제 클라우드 인프라와 예상 규모에서 시험해 확장성 요구를 충족하는 방식을 선택함
개념 증명 이후 광범위한 종단 간 테스트와 신중한
사람의 검토를 거쳐 프로덕션 버전의 사용자 안전성을 확인함