<div id="readability-page-1" class="page"><div><p><a href="https://jhyeok.com/mongodb-day-seoul-2022/" target="_blank" rel="nofollow noopener noreferrer">작년</a>에 이어 이번에도 MongoDB.local Seoul 2023을 다녀왔습니다.</p>
<h2>DevOps Engineer의 저녁이 있는 삶, MongoDB Atlas 도입기 (임성빈 프로, 삼성전자 DA사업부 AI Solution 그룹)</h2>
<ul>
<li>스마트홈 서비스 MongoDB Atlas 도입, 샤딩까지 어떻게 했는지</li>
<li>MongoDB Atlas를 도입하고 DB 장애건수 0건</li>
</ul>
<p>사용자 기기를 등록하는 서버 DB를 MySQL로 2014년에 처음 시작 (개발 및 운영 시작)</p>
<ul>
<li>2015년에 스마트홈에 실제 기기에서 발생하는 실시간 이벤트 데이터를 수집하고 이 수집된 데이터를 전처리해서 외부에 공유하는 API를 오픈</li>
<li>실제 가전의 데이터가 JSON 포맷</li>
</ul>
<p>NoSQL 도입 결정</p>
<ul>
<li>2015년에 EC2에 MongoDB 커뮤니티 버전을 사용해서 자체 구축해서 사용</li>
<li>초기에는 문제가 없었음</li>
<li>트래픽이 적었기 때문, 트래픽이 늘어나면서 점점 병목이 발생</li>
<li>MongoDB DBA 인력 없음</li>
<li>커뮤니티 버전 오픈소스에 대한 기술 지원을 받기 어려웠음</li>
<li>가용성 보장을 위해 MongoDB 기술적인 백그라운드가 기반이 되어야지 잘 구성을 할 수 있는데 좀 부족했음</li>
<li>모니터링을 하는데 어려움을 느꼈음</li>
<li>Max IOPS 30k (peak season)</li>
</ul>
<p>마이그레이션</p>
<ul>
<li>MongoDB Cluster(EC2)에서 MongoDB Atlas로 마이그레이션</li>
<li>Mongomirror 유틸리티를 사용하는 방식으로 결정</li>
</ul>
<p>아키텍처</p>
<ul>
<li>Producer(WAS) - RabbitMQ Cluster - Consumer(Warker) - MongoDB 컬력센에 데이터 Write</li>
</ul>
<p>마이그레이션 이후 아키텍처</p>
<ul>
<li>Smart Home VPC / MongoDB Atlas VPC를 분리시킴</li>
</ul>
<p>마이그레이션 이후 효과</p>
<ul>
<li>평균 응답속도 개선: 8ms -&gt; 3ms</li>
<li>Disk read lateny 감소: 최대3s/평균25ms -&gt; 최대18ms/평균1ms</li>
<li>이슈가 19건에서 0건으로 감소</li>
</ul>
<p>Replica Set to Sharded Cluster</p>
<ul>
<li>주로 기기 상태 이벤트에 대한 updates</li>
<li>에어컨 등 가전제품 사용이 많은여름 성수기에 workload 트래픽 급증</li>
<li>Replica Set 기반 스케일업 전략으로 peak 시즌의 워크로드를 다루는데 한계 직면, shard 환경 기반 스케일업/아웃 전략 추진</li>
<li>아키텍처가 샤드 라우팅 엔드포인트로 변경 (커녁센스트링의 변경이 없었기 때문에 애플리케이션 코드 배포 없이 진행)</li>
</ul>
<p>마이그레이션 이후 결과</p>
<ul>
<li>업데이트 오퍼레이션이 25k에서 2샤드가 균등하게 10k-15k씩 분배</li>
<li>커넥션 수도 샤드별로 균등하게 밸런싱</li>
<li>Disk IOPS, Disk Queue Depth 등 샤드 전환후에 2분의 1로 감소</li>
</ul>
<p>결론</p>
<ul>
<li>장애 관련 이슈 0건 (2022년 5월 - NOW)</li>
<li>High Availability 확보</li>
<li>Workload Throughput 향상</li>
<li>MongoDB 관리 overhead를 줄이고, Biz logic 및 Application 개발에 집중</li>
</ul>
<h2>What’s New in MongoDB 7.0 (김준 전무, MongoDB Korea)</h2>
<p>개선된 개발자 경험</p>
<ul>
<li>New in Query: operators, variables and indexes</li>
<li>Wildcard indexes 지원</li>
<li>Bitwise 연산자, 백분위수 연산자</li>
<li>시스템 변수 $$USER_ROLES 추가</li>
<li>시계열 컬렉션에 대한 Update/Delete 지원</li>
<li>임의의 도큐먼트에 대한 단일, 다중 삭제 지원</li>
<li>확장성 향상</li>
<li>성능 최적화</li>
<li>부분적인 TTL 인덱싱 지원</li>
<li>쿼리 수행 속도 향상</li>
<li>체인지스트림</li>
<li>대규모 이벤트 처리에 대한 확장</li>
<li>Shard Key advisor commands 지원</li>
<li>sk를 제공하지 않고도 UpdateOne 사용</li>
</ul>
<p>성능</p>
<ul>
<li>Big Routing Table로 인한 성능 저하</li>
<li>auto-merger</li>
<li>동일한 샤드 내 연속되어져 있는 청크를 병합 빠른실행, 조각모음 절차사항 많은 부분을 차지함, 마이그레이션 실행하지 않음</li>
<li>향상된 쿼리 성능</li>
<li>$group, $project, $match, $sort, $lookup</li>
<li>7.0에서 쿼리 엔진이 변경됨</li>
</ul>
<p>보안</p>
<ul>
<li>데이터베이스 엑세스를 위한 OpenID Connect 지원</li>
</ul>
<p>마이그레이션</p>
<ul>
<li>Cluster-to-Cluster Sync (mongosync)</li>
<li>동일하거나 다른 환경에 있는 두 MongoDB Cluster간에 지속적인 데이터 동기화(단방향)</li>
<li>한 클러스가 망가지면 다른 클러스터 사용 가능</li>
<li>워크로드를 나눠서 처리할 수 있다는 의미</li>
<li>다른 클러스터에서 분석 작업 가능</li>
<li>데이터가 싱크되어 있기 때문</li>
<li>Atlas Live Migrate 활용</li>
</ul>
<h2>Streaming Processing을 활용한 실시간 이벤트 처리 (김규동 상무, MongoDB Korea)</h2>
<p>Schema 변경에 빠른 대응 (이벤트들은 페이로드 변경이 있음)</p>
<ul>
<li>발생하는 이벤트들을 확인하려면 배치 형태의 애플리케이션이 늘어날 수 밖에 없음</li>
<li>이벤트에 대한 양도 늘어남</li>
</ul>
<p>MongoDB는 연속되는 데이터에 대한 강력한 연산 (어그리게이션 파이프라인을 가지고 있음)</p>
<ul>
<li>Stage 1번 연산 - Stage 2번 연산 같은 형태로 쿼리를 작성</li>
<li>파이프라인이라는 형태로 여러가지 Stage를 조합해서 그 안에서 원하는 데이터를 찾게 하는 핵심이 있음</li>
</ul>
<p>Streaming Processing</p>
<ul>
<li>무한 반복 쿼리 수행, 강력한 Pipeline 연산</li>
<li>Aggregate, Filter, Route, Alert, Emit</li>
</ul>
<p>서비스의 이름은 Atlas Streaming Processing</p>
<ul>
<li>도큐먼트 모델을 이용한 유연한 스키마</li>
<li>유효성 검사 및 상태 저장 Window Processing</li>
<li>MongoDB Atlas를 활용하여 실시간 생성되는 데이터와 기존 데이터를 결합</li>
<li>별도의 애플리케이션을 만들지 않아도 됨</li>
<li>개발자가 신경을 덜 쓸 수 있음</li>
<li>이벤트에 대한 데이터가 만들어질 때 마다 유효성 검사, 개발자분들이 개발하지 않고</li>
<li>서비스가 서버리스로 제공되기 때문에 쿼리가 실행될 때마다 필요한 자원들이 유기적으로 할당되기 때문에 신경을 덜 쓸 수 있음</li>
<li>개발에 대한 생산성에 대해서 중요하게 생각하는데 그 부분을 제공함 (가장 큰 장점이자 지향점)</li>
</ul>
<p>Connection Registry (Key Store) / Steam Instance<br>
Steam에 대한 그룹 - Window (TumblingWindow, HoppingWindow)</p>
<ul>
<li>1 분이라는 시간 동안에 데이터를 계산할거야</li>
<li>주식 같은 경우에 30분 평균, 10분 평균, 1분에 한 번씩 10분동안의 평균 주가 지수를 계산하는 부분들 이런 범위 인터벌에 대한 레인지에 대한 평균을 계산하겠다.</li>
<li>시간동안의 평균을 움직이는 형태로 가져가기 위한 Window 제공</li>
</ul>
<p>Pipeline</p>
<ul>
<li>다양한 연산 제공</li>
<li>Life Cycle Management 제공</li>
<li>서버리스한 형태로 작동</li>
<li>이벤트 스트리밍 100만 건이 들어왔을 때, 일시적으로 많은 리소스를 할당받는 형태와 같은 것이 정의가 가능함</li>
</ul>
<h2>Relational Migrator를 활용한 애플리케이션 현대화 (조건호 상무, MongoDB Korea)</h2>
<ul>
<li>해당 발표는 조금 재미있게 풀어가셨으며 아래 내용을 진지하게 생각하지 않아도 됨</li>
</ul>
<p>Relational Migrator 이번에 GA</p>
<ul>
<li>SQL DB를 MongoDB로 전환 (스키마 변환, 데이터 복제)</li>
</ul>
<p>Why NoSQL?</p>
<ul>
<li>SQL을 사용하지 말자가 아니라 여러가지 DB를 사용하자</li>
</ul>
<p>현재의 애플리케이션 변화</p>
<ul>
<li>데이터 증가 속도가 가파르다</li>
<li>우리 애플리케이션이 처리할 데이터 양은 점점 늘어난다</li>
<li>SQL은 JOIN을 기반으로 한 DB
<ul>
<li>성능을 포기하던가, 엄청난 비용을 들여서 하드웨어 스펙 보안</li>
</ul>
</li>
<li>사업 환경의 변화
<ul>
<li>변화에 대한 신속한 대응/혁신 -&gt; 유연한 스키마가 필요</li>
</ul>
</li>
<li>개발 주기의 단축</li>
<li>전체적인 개발 프로세스의 시간이 줄어듬</li>
<li>도메인에서부터 Top-Down을 시작하자가 요즘의 추세인데 이것을 DB에도 적용
<ul>
<li>SQL, NoSQL</li>
<li>SQL은 row-col table 부터 시작</li>
<li>NoSQL은 애플리케이션이 사용할 데이터를 그냥 스토리지에 저장</li>
</ul>
</li>
</ul>
<p>MSA가 어려운 이유</p>
<ul>
<li>데이터 이동</li>
<li>언어장벽</li>
</ul>
<p>MSA로 가는 새로운 길</p>
<ul>
<li>MongoDB 하나를 선택</li>
<li>하나의 기종이기 때문에 거기에 따른 ETL을 줄여나갈 수 있음</li>
</ul>
<p>SQL로 부터 빠르고 안정적으로 MongoDB로의 전환</p>
<ul>
<li>데모 시청</li>
<li>Relational Migrator 다운로드</li>
<li>샘플데이터가 있기 때문에 연습 가능</li>
<li>기존 워크로드에서 가벼운 것부터 연습</li>
<li>그 이후에 직접적으로 마이그레이션 (파트너 지원도 해줌)</li>
</ul>
<h2>더욱 안전한 MongoDB Atlas on AWS 사용 방법 (윤기원 파트너 솔루션 아키텍트, AWS)</h2>
<p>AWS PrivateLink를 활용한 사용자 VPC - Atlas간 보안 접속</p>
<ul>
<li>1 WAY 단방향 통신</li>
<li>보통 전통적인 IP 필터링 방식 사용</li>
</ul>
<p>AWS KMS, IAM을 이용한 데이터 암호화</p>
<ul>
<li>데모 시청</li>
</ul>
<h2>Riot Games Korea: Why MongoDB? Why Atlas? (김동인 소프트웨어 엔지니어, RiotGames)</h2>
<p>Riot Games Korea 개발팀에서 하는 일</p>
<ul>
<li>PC방 비즈니스</li>
<li>모바일 상점(store.leagueoflegends.co.kr)</li>
<li>한국 게임 퍼블리싱(계정, Player Behavior)</li>
<li>이스포츠 데이터(LCK)</li>
</ul>
<p>한국 PC방에서 Riot의 게임</p>
<ul>
<li>게임 동시접속 최대 약 80만</li>
<li>PC방 동시접속 최대 약 20만</li>
<li>PC 방 세션 1년 약 40억 건</li>
<li>이를 서포트해줄 엔진, 서비스가 필요</li>
</ul>
<p>플레이어에게 올챔프 혜택, 업주분들에게 과금 및 서비스 제공</p>
<ul>
<li>업주분들에게는 그 플레이어가 얼마나 게임을 했는지 측정해서 과금 필요</li>
<li>엔지니어 2-6명의 작은 팀</li>
<li>데이터 저장소로 MongoDB를 선택</li>
</ul>
<p>DB 요구사항</p>
<ul>
<li>잦은 스키마 변화에도 큰 문제 없이 서비스 개발/운영</li>
<li>필요할 경우 데이터베이스의 수평적 확장 용이</li>
<li>(5년전) 처음에는 EC2에 MongoDB 커뮤니티 버전을 설치해서 구성</li>
<li>version 3.6.0</li>
<li>IOPS 3000</li>
</ul>
<p>쿼리 성능</p>
<ul>
<li>1년마다 약 40억개의 세션 관련 도큐먼트가 쌓임</li>
<li>2년 반이 지나고 보니 컬렉션 내 도큐먼트가 무려 100억개에 달함</li>
</ul>
<p>운영의 부담</p>
<ul>
<li>매일 크론 잡을 통해 백업 저장</li>
<li>복구 작업이 필요하다면</li>
<li>서비스 중단, 데이터 손실 없이 진행되기 위해 과정이 복잡하고 실수 가능성이 높음</li>
<li>AWS 점검</li>
<li>AWS EC2의 scheduled maintenance</li>
<li>수동으로 EC2를 껐다 켜고 다시 DB 구동</li>
<li>그동안의 서비스는?</li>
<li>버전 업그레이드</li>
<li>다가오는 현 버전의 EOL</li>
<li>게임 다운타임동안 버전 업그레이드를 무사히 마치고 테스트까지 끝낼 수 있을까?</li>
<li>major 버전업이라면?</li>
</ul>
<p>필요했던 추가 기능</p>
<ul>
<li>데이터를 보고 싶어하는 stakeholder들이 많은 수 늘어남</li>
<li>Chart, Metric 등의 필요성</li>
</ul>
<p>MongoDB Atlas로의 마이그레이션</p>
<ul>
<li>클러스터 생성</li>
<li>Web UI로 쉽게 가능</li>
<li>mongomirror 사용</li>
<li>100억건 기준 sync 10시간</li>
<li>성능 테스트 및 데이터 검증</li>
<li>컷오버</li>
<li>게임서비스 정기점검 때 진행</li>
<li>미러 테일링의 log이 0임을 확인</li>
<li>새로운 DB에 연결된 코드를 배포</li>
<li>테일링은 종료</li>
</ul>
<p>마이그레이션 그 이후</p>
<ul>
<li>운영 부담 경감</li>
<li>자동 백업</li>
<li>모니터링</li>
<li>Slow query 발생 시 빠르게 모니터링 가능</li>
<li>Performance Advisor</li>
<li>DB 성능에 도움되는 제안들을 볼 수 있음</li>
<li>주로 인덱스 추가/제거에 참고</li>
<li>차트</li>
<li>모니터링, 인사이트를 위해서 주로 사용</li>
<li>동향 파악</li>
<li>Online Archive</li>
</ul></div></div>

JHyeok

작년에 이어 이번에도 MongoDB.local Seoul 2023을 다녀왔습니다.
DevOps Engineer의 저녁이 있는 삶, MongoDB Atlas 도입기 (임성빈 프로, 삼성전자 DA사업부 AI Solution 그룹)
스마트홈 서비스 MongoDB Atlas 도입, 샤딩까지 어떻게 했는지
MongoDB Atlas를 도입하고 DB 장애건수 0건
사용자 기기를 등록하는 서버 DB를 MySQL로 2014년에 처음 시작 (개발 및 운영 시작)
2015년에 스마트홈에 실제 기기에서 발생하는 실시간 이벤트 데이터를 수집하고 이 수집된 데이터를 전처리해서 외부에 공유하는 API를 오픈
실제 가전의 데이터가 JSON 포맷
NoSQL 도입 결정
2015년에 EC2에 MongoDB 커뮤니티 버전을 사용해서 자체 구축해서 사용
초기에는 문제가 없었음
트래픽이 적었기 때문, 트래픽이 늘어나면서 점점 병목이 발생
MongoDB DBA 인력 없음
커뮤니티 버전 오픈소스에 대한 기술 지원을 받기 어려웠음
가용성 보장을 위해 MongoDB 기술적인 백그라운드가 기반이 되어야지 잘 구성을 할 수 있는데 좀 부족했음
모니터링을 하는데 어려움을 느꼈음
Max IOPS 30k (peak season)
마이그레이션
MongoDB Cluster(EC2)에서 MongoDB Atlas로 마이그레이션
Mongomirror 유틸리티를 사용하는 방식으로 결정
아키텍처
Producer(WAS) - RabbitMQ Cluster - Consumer(Warker) - MongoDB 컬력센에 데이터 Write
마이그레이션 이후 아키텍처
Smart Home VPC / MongoDB Atlas VPC를 분리시킴
마이그레이션 이후 효과
평균 응답속도 개선: 8ms -> 3ms
Disk read lateny 감소: 최대3s/평균25ms -> 최대18ms/평균1ms
이슈가 19건에서 0건으로 감소
Replica Set to Sharded Cluster
주로 기기 상태 이벤트에 대한 updates
에어컨 등 가전제품 사용이 많은여름 성수기에 workload 트래픽 급증
Replica Set 기반 스케일업 전략으로 peak 시즌의 워크로드를 다루는데 한계 직면, shard 환경 기반 스케일업/아웃 전략 추진
아키텍처가 샤드 라우팅 엔드포인트로 변경 (커녁센스트링의 변경이 없었기 때문에 애플리케이션 코드 배포 없이 진행)
마이그레이션 이후 결과
업데이트 오퍼레이션이 25k에서 2샤드가 균등하게 10k-15k씩 분배
커넥션 수도 샤드별로 균등하게 밸런싱
Disk IOPS, Disk Queue Depth 등 샤드 전환후에 2분의 1로 감소
결론
장애 관련 이슈 0건 (2022년 5월 - NOW)
High Availability 확보
Workload Throughput 향상
MongoDB 관리 overhead를 줄이고, Biz logic 및 Application 개발에 집중
What’s New in MongoDB 7.0 (김준 전무, MongoDB Korea)
개선된 개발자 경험
New in Query: operators, variables and indexes
Wildcard indexes 지원
Bitwise 연산자, 백분위수 연산자
시스템 변수 $$USER_ROLES 추가
시계열 컬렉션에 대한 Update/Delete 지원
임의의 도큐먼트에 대한 단일, 다중 삭제 지원
확장성 향상
성능 최적화
부분적인 TTL 인덱싱 지원
쿼리 수행 속도 향상
체인지스트림
대규모 이벤트 처리에 대한 확장
Shard Key advisor commands 지원
sk를 제공하지 않고도 UpdateOne 사용
성능
Big Routing Table로 인한 성능 저하
auto-merger
동일한 샤드 내 연속되어져 있는 청크를 병합 빠른실행, 조각모음 절차사항 많은 부분을 차지함, 마이그레이션 실행하지 않음
향상된 쿼리 성능
$group, $project, $match, $sort, $lookup
7.0에서 쿼리 엔진이 변경됨
보안
데이터베이스 엑세스를 위한 OpenID Connect 지원
마이그레이션
Cluster-to-Cluster Sync (mongosync)
동일하거나 다른 환경에 있는 두 MongoDB Cluster간에 지속적인 데이터 동기화(단방향)
한 클러스가 망가지면 다른 클러스터 사용 가능
워크로드를 나눠서 처리할 수 있다는 의미
다른 클러스터에서 분석 작업 가능
데이터가 싱크되어 있기 때문
Atlas Live Migrate 활용
Streaming Processing을 활용한 실시간 이벤트 처리 (김규동 상무, MongoDB Korea)
Schema 변경에 빠른 대응 (이벤트들은 페이로드 변경이 있음)
발생하는 이벤트들을 확인하려면 배치 형태의 애플리케이션이 늘어날 수 밖에 없음
이벤트에 대한 양도 늘어남
MongoDB는 연속되는 데이터에 대한 강력한 연산 (어그리게이션 파이프라인을 가지고 있음)
Stage 1번 연산 - Stage 2번 연산 같은 형태로 쿼리를 작성
파이프라인이라는 형태로 여러가지 Stage를 조합해서 그 안에서 원하는 데이터를 찾게 하는 핵심이 있음
Streaming Processing
무한 반복 쿼리 수행, 강력한 Pipeline 연산
Aggregate, Filter, Route, Alert, Emit
서비스의 이름은 Atlas Streaming Processing
도큐먼트 모델을 이용한 유연한 스키마
유효성 검사 및 상태 저장 Window Processing
MongoDB Atlas를 활용하여 실시간 생성되는 데이터와 기존 데이터를 결합
별도의 애플리케이션을 만들지 않아도 됨
개발자가 신경을 덜 쓸 수 있음
이벤트에 대한 데이터가 만들어질 때 마다 유효성 검사, 개발자분들이 개발하지 않고
서비스가 서버리스로 제공되기 때문에 쿼리가 실행될 때마다 필요한 자원들이 유기적으로 할당되기 때문에 신경을 덜 쓸 수 있음
개발에 대한 생산성에 대해서 중요하게 생각하는데 그 부분을 제공함 (가장 큰 장점이자 지향점)
Connection Registry (Key Store) / Steam Instance
1 분이라는 시간 동안에 데이터를 계산할거야
주식 같은 경우에 30분 평균, 10분 평균, 1분에 한 번씩 10분동안의 평균 주가 지수를 계산하는 부분들 이런 범위 인터벌에 대한 레인지에 대한 평균을 계산하겠다.
시간동안의 평균을 움직이는 형태로 가져가기 위한 Window 제공
Pipeline
다양한 연산 제공
Life Cycle Management 제공
서버리스한 형태로 작동
이벤트 스트리밍 100만 건이 들어왔을 때, 일시적으로 많은 리소스를 할당받는 형태와 같은 것이 정의가 가능함
Relational Migrator를 활용한 애플리케이션 현대화 (조건호 상무, MongoDB Korea)
해당 발표는 조금 재미있게 풀어가셨으며 아래 내용을 진지하게 생각하지 않아도 됨
Relational Migrator 이번에 GA
SQL DB를 MongoDB로 전환 (스키마 변환, 데이터 복제)
Why NoSQL?
SQL을 사용하지 말자가 아니라 여러가지 DB를 사용하자
현재의 애플리케이션 변화
데이터 증가 속도가 가파르다
우리 애플리케이션이 처리할 데이터 양은 점점 늘어난다
SQL은 JOIN을 기반으로 한 DB
성능을 포기하던가, 엄청난 비용을 들여서 하드웨어 스펙 보안
사업 환경의 변화
변화에 대한 신속한 대응/혁신 -> 유연한 스키마가 필요
개발 주기의 단축
전체적인 개발 프로세스의 시간이 줄어듬
도메인에서부터 Top-Down을 시작하자가 요즘의 추세인데 이것을 DB에도 적용
SQL, NoSQL
SQL은 row-col table 부터 시작
NoSQL은 애플리케이션이 사용할 데이터를 그냥 스토리지에 저장
MSA가 어려운 이유
데이터 이동
언어장벽
MSA로 가는 새로운 길
MongoDB 하나를 선택
하나의 기종이기 때문에 거기에 따른 ETL을 줄여나갈 수 있음
SQL로 부터 빠르고 안정적으로 MongoDB로의 전환
데모 시청
Relational Migrator 다운로드
샘플데이터가 있기 때문에 연습 가능
기존 워크로드에서 가벼운 것부터 연습
그 이후에 직접적으로 마이그레이션 (파트너 지원도 해줌)
더욱 안전한 MongoDB Atlas on AWS 사용 방법 (윤기원 파트너 솔루션 아키텍트, AWS)
AWS PrivateLink를 활용한 사용자 VPC - Atlas간 보안 접속
1 WAY 단방향 통신
보통 전통적인 IP 필터링 방식 사용
AWS KMS, IAM을 이용한 데이터 암호화
데모 시청
Riot Games Korea: Why MongoDB? Why Atlas? (김동인 소프트웨어 엔지니어, RiotGames)
Riot Games Korea 개발팀에서 하는 일
PC방 비즈니스
모바일 상점(store.leagueoflegends.co.kr)
한국 게임 퍼블리싱(계정, Player Behavior)
이스포츠 데이터(LCK)
한국 PC방에서 Riot의 게임
게임 동시접속 최대 약 80만
PC방 동시접속 최대 약 20만
PC 방 세션 1년 약 40억 건
이를 서포트해줄 엔진, 서비스가 필요
플레이어에게 올챔프 혜택, 업주분들에게 과금 및 서비스 제공
업주분들에게는 그 플레이어가 얼마나 게임을 했는지 측정해서 과금 필요
엔지니어 2-6명의 작은 팀
데이터 저장소로 MongoDB를 선택
DB 요구사항
잦은 스키마 변화에도 큰 문제 없이 서비스 개발/운영
필요할 경우 데이터베이스의 수평적 확장 용이
(5년전) 처음에는 EC2에 MongoDB 커뮤니티 버전을 설치해서 구성
version 3.6.0
IOPS 3000
쿼리 성능
1년마다 약 40억개의 세션 관련 도큐먼트가 쌓임
2년 반이 지나고 보니 컬렉션 내 도큐먼트가 무려 100억개에 달함
운영의 부담
매일 크론 잡을 통해 백업 저장
복구 작업이 필요하다면
서비스 중단, 데이터 손실 없이 진행되기 위해 과정이 복잡하고 실수 가능성이 높음
AWS 점검
AWS EC2의 scheduled maintenance
수동으로 EC2를 껐다 켜고 다시 DB 구동
그동안의 서비스는?
버전 업그레이드
다가오는 현 버전의 EOL
게임 다운타임동안 버전 업그레이드를 무사히 마치고 테스트까지 끝낼 수 있을까?
major 버전업이라면?
필요했던 추가 기능
데이터를 보고 싶어하는 stakeholder들이 많은 수 늘어남
Chart, Metric 등의 필요성
MongoDB Atlas로의 마이그레이션
클러스터 생성
Web UI로 쉽게 가능
mongomirror 사용
100억건 기준 sync 10시간
성능 테스트 및 데이터 검증
컷오버
게임서비스 정기점검 때 진행
미러 테일링의 log이 0임을 확인
새로운 DB에 연결된 코드를 배포
테일링은 종료
마이그레이션 그 이후
운영 부담 경감
자동 백업
모니터링
Slow query 발생 시 빠르게 모니터링 가능
Performance Advisor
DB 성능에 도움되는 제안들을 볼 수 있음
주로 인덱스 추가/제거에 참고
차트
모니터링, 인사이트를 위해서 주로 사용
동향 파악
Online Archive

MongoDB.local Seoul 2023

댓글