<div id="readability-page-1" class="page"><div id="skip-nav"><p><time>2019-04-25 에 작성하고, 2020-03-09 14:21:00 에 업데이트한 문서입니다. ✅</time> — <a href="/tags/conference">Conference</a> — <span>4 min read</span></p><section><p>발표자료는 올라올테지만, 가장 인상깊게 들었던 발표를 들으며 적었던 노트를 날것으로 (ㅋㅋ) 공유합니다. </p><h2>&lt;FIFA 온라인 4&gt; 서버 포스트모템</h2><p>김에스더님 From EA Korea</p><p>런칭 이전에 서버 준비과정부터 런칭 이후 운영 이슈까지 공유하고자 함</p><p>Microservices on Kubernetes(오케스트레이션 툴)</p><h3>서버 아키텍쳐</h3><ul><li><p>피파온라인4는 FIFA시리즈 바탕 온라인 게임</p></li><li><p>아시아 4개국, PC와 모바일로 서비스 중</p></li><li><p>전작 피파3은 <strong>Monolithic Architecture</strong></p><ul><li>하나의 애플리케이션에 모든 구현이 담겨있었음 (Db- Game Server - User Interface)</li><li>세가지 단점<ul><li>장애 → 전체 서비스 장애</li><li>작은 변경을 위해 전체 서버 빌드 및 배포 필요</li><li>비효율적인 서버 Scale out 비용 (휴일 등 트래픽 대응에 전체 서버를 스케일 아웃해야했음.)</li></ul></li></ul></li><li><p><strong>MicroService Architecture</strong></p><ul><li>여러개를 합쳐서 운영하는 방식</li><li>개발 속도가 빠르다</li><li>배포가 쉽다</li><li>서버 장애의 영향도가 일부 서비스에 국한된다</li><li>스케일링이 쉽고 효율적이다</li><li>백엔드는 RabbitMQ, MongoDB, Redis 등을 사용함.  (서비스 단의 메시지 통신을 위해 메시지 큐)</li><li>서비스 모니터링을 위한 Grafana 등으로 구성</li><li>대표적인 서비스 - GateWay, Auth, Session, API, Data, Log, Chat, Noti, Matchmaker</li><li>로그인 : Gateway가 받아서 처리할 수 있는 Authenticate 서비스에 보냄</li><li>전달하는 매개체는 RabbitMQ</li><li>훨씬 복잡한 구성이 있기때문에, hop이 길어지는 경우도 많음</li></ul></li></ul><h3>배포</h3><ul><li>배포해야 하는 대상이 너무 많음<ul><li>게이트웨이</li><li>인증</li><li>알림</li><li>로그</li><li>데이터</li><li>매치메이킹 등 .. 40가지 서버 부자가 되었다.</li></ul></li><li>이렇게 많은 종류의 서비스를 라이브 서버에 어떻게 배포하지?<ul><li>config 하나하나 작성해서 40번 올리면 되지 🙂</li><li>이걸 관리할 수 있는 오케스트레이션 툴</li><li>구동, 배포, 관리하기 위해서 <strong>Kubernetes를 사용</strong></li><li>구글이 개발, 선택하게 된 이유 중</li><li>라이브 서비스를 하기에 적합한 툴이라는 생각이 들음<ul><li>장애나 형상관리를 할 때 유용한 Feature 들</li><li>Rolling Update</li><li>Version Control</li><li>Auto Scaling</li><li>Resource Allocation 이 가능하다.</li></ul></li></ul></li></ul><h4>Kubernetes Cluster</h4><ul><li>Master - Node 의 단순한 구조</li><li>Master의 요소랑 일반 노드의 요소랑 다름</li><li>Master는 관리자 역할이 있으니까, 다양 - DNS 서버, API 서버, Scheduler, Controller Manager</li><li>클러스터 마스터에 명령을 내릴 때 실제 명령을 내리게 해주는 매개가 API 서버 (이를 통해 cluster 내에서, 그리고 관리자와 소통)</li><li>Node 내에는 Kubelet이라는 노드 agent가 뜸.</li><li>node 마다 role을 줄 수 있는데, role에 따라 어떤 서비스를 띄울 지 결정할 수 있음</li><li>e.g.) Backend node는 MQ들이 뜨고, Game node에는 API 서버, cronjobs, data server 가 뜨는 방식</li></ul><h4>서비스 배포 단계</h4><ol><li>서비스 빌드 &amp; 업로드</li><li><strong>Kubernetes Manifest 작성 ← 어려움</strong>, Kubernetes 적용 config<ul><li>작성하는 포맷이 복잡하여 작성 작업이 시간이 크게 소요됨</li><li>스키마가 다 다름</li><li>indentation 이 중요 ( yml 파일임 ㅠㅠ)</li><li>오타 등 실수가 감지하기 어려움</li><li>히스토리 관리와 공유가 어려움</li></ul></li></ol><blockquote><p>Helm이라는 패키지 매니저를 통해서 Manifest를 관리 및 배포 프로세스  구축 + Jenkins와 Herfos(?)</p></blockquote><ul><li><strong>Helm</strong></li><li>버전 컨트롤 뿐아니라 manifest respository 구성 가능 → 어떻게 manifest 작성할지 막막할때 helm 오피셜 repo에서 fetch 해올수 있음</li><li>방식이 좀 달라서, 지속적으로 변경이 일어나는 상수 부분을 대체할 수 있음.</li><li>40개의 서비스 manifest에 버전이나 서버 갯수를 바꿔야한다면..?!</li></ul><h4>배포 프로세스</h4><p>레포에 manifest 커밋 → 젠킨스 job CI → Jenkins가 helm repo에 manifest push → 서버에서 fetch 해감</p><ol start="3"><li>서버에 Manifest 적용하여 서비스 업데이트</li></ol><h5>장점</h5><ul><li>배포 히스토리 관리</li><li>Helm 기능으로 설정 오류 감소 , 오류 보정됨</li><li>팀내 sync up</li><li>작업시간 감소</li></ul><h3>Stability</h3><p>어떻게 서비스를 안정적으로 ?</p><blockquote><p>서비스 오픈날도 장애없이 4개 국 동시 운영</p></blockquote><blockquote><p>장애 대비와 대응을 어떻게 했나? 🤨</p></blockquote><ul><li><p>Microservice Architecture</p><p>  부하가 전체 서비스가 아닌 일부에만 영향을 준다!</p><p>  match maker라든지 일부 서비스만 다운되면 로그인해서, 거래 시장 이용, 채팅 등은 문제가 없는 부분!</p></li><li><p>단점일 때도 있었음..</p><ul><li>어떤 서비스에 얼마만큼의 영향을 주는지 파악하기 힘들다</li><li>물리서버 발주하는 시점에서(ㅋㅋㅋ) 서비스가 얼마나 리소스를 사용하는지 모름! 😢</li><li>매치 1판 할때 어떤 서비스에 얼마만큼 부하가 발생하는지 명확하게 알 수 있을까..?</li><li>Monolithic 이면 부하만 보면 단순히 계산이 되는데!</li><li>Micro 인 경우 - Gateway 부하가 얼마고, log에, match maker에 부하가 얼마나 들어가는지 계산이 어려움. 커뮤니케이터인 RabbitMQ인 경우 MQ의 부하도 생각해야하고, DB도 생각하고 ...</li><li><strong>대규모 로드테스트를 하게 됨</strong></li></ul></li></ul><h4>대규모 로드테스트</h4><p>CBT나 OBT말고 대규모(동접 30만 기준)</p><p>criteria를 정함 : <strong>서버가 초당 3만 건 요청을 처리할 수 있어야 부하를 견딜 수 있다!</strong> 라고 생각함</p><ol><li>유저 시나리오를 작성</li><li>AWS 로드 테스트 서버 구축<ul><li>라이브 서버와 똑같이 Kubernetes 구성,  HA 구성, LoadBalancer도 붙임</li></ul></li><li>로드 테스트 실행</li></ol><p><strong>기준(criteria)을 통과할 때까지 반복 실행</strong></p><h5>뭐가 좋아요?</h5><ul><li><strong>부하가 높을 때만 발생하는 문제를 확인할 수 있음</strong></li><li>e.g.) 부하가 높을 때 →  서비스의 메모리 100% 차는 현상</li><li>처음에 말한 목적처럼 <strong>리소스 측정해서 할당 할 수 있음</strong></li></ul><h5>미처 대비하지 못한 문제</h5><ul><li>패치 데이터 오류</li><li>발견하기 어려운 서버 코드 버그</li><li>CPU 나 메모리등의 서버 리소스 사용량 급증</li></ul><p>이런 문제가 발생했을 때 <strong>Kubernetes를 사용해서 해결</strong></p><h5><strong>Solution #1</strong></h5><p>Server Hotfix : Rolling Update</p><ul><li>유저 몰래 업데이트 😗</li><li>점검 없이 rolling update 가능</li><li>단. 라이브 서비스 중에 재시작되어도 트랜잭션 처리 등 서버 임팩트가 없도록 보장되어야 함</li><li>에러를 쓰루하는 등의 처리가 명확하지 않으면 CS 처리로 해야함.. 조심해..😭</li></ul><h5><strong>Solution #2</strong></h5><p>손쉬운 명령어로 빠른 Scale out</p><h5><strong>Solution #3</strong></h5><p>auto scaling으로 자동 리소스 관리</p><ul><li>미연에 장애를 관리할 수 있는 기능</li><li>"부하가 늘면 자동으로 늘어나네"</li><li>단, Scale in 이 될수도 있기때문에 이 경우를 고려해야한다</li></ul><h3>Monitoring</h3><p>모니터링 시스템을 구축안해도 Kubernetes Dashboard를 만들어준다 ! 🙂</p><blockquote><p>하지만.. 사실상 모니터링보다는 관리자 작업 페이지에 가까움</p></blockquote><ul><li>서비스 구성 요소</li><li>리소스 사용량 확인</li><li>콘솔 로그 확인</li><li>서비스 생성 및 삭제</li></ul><p>위와 같은 기능 제공!</p><ul><li>리얼 타임으로 이걸 보기엔 괜찮지만 시간을 조절해서 볼수도 없다!</li></ul><h5>필요한 데이터는 뭐지 🤔</h5><ul><li>물리/VM 서버 상태</li><li>리소스 사용량</li><li>Kubernetes 서비스 상태</li><li>CCU 증감 추이  (게임 서비스의 데이터)</li><li>서버 응답 지연 및 에러 발견</li></ul><p>위의 세개는  다음과 같이 해결할 수있는데</p><ul><li>Google Cloud Engine을 사용! (무료)</li><li>DataDog같은 솔루션을 사용 (유료)</li></ul><p>아래 두개는 다음과 같이 해결할 수있는데</p><ul><li>CCU API를 통해 감시</li><li>Sentry로 에러 감시</li></ul><blockquote><p>솔루션이 나눠져 있는데 통합해서 볼 수 없을까?</p></blockquote><ul><li>대시보드가 여러 개면</li><li>뭔가 문제가 있을 때 한번에 보고 파악하기가 어렵다 .</li></ul><h5><strong>Custom Monitoring Tool이 필요하다!</strong></h5><ul><li>Kubernetes + Game Server를 다 보자</li><li>Kubernetes API Sever (모니터링 통해서 가져올수있는걸 준다)</li><li>cAdvisor는 container 의 상태를 가져와서 Kublet에게 주고. API Server가 가져가고 싶은것만 Kublet에서 fetch해서 가져감</li></ul><p>API Server → 프로메테우스에 저장하고 → Grafana(대시보드)</p><p>대시보드가 없을때는 Manifest를 들어가서 확인해야했음 ㅠ.ㅠ</p><p>NEEDS</p><ul><li>gateway 서버 100개면 평균적인 inbound outbound 값을 보여주고싶은데 그런 툴이 없어서 아직 custom 사용중.</li><li>처리 건수가 줄어들면 병목 상황을 감지 가능</li><li>Slow API 가 초당 몇개 발생하고 있는지!</li></ul><h2>SUMMARY</h2><h3>MicroService 단점</h3><ul><li>nanoservice 가 될 수 있음 → 갯수가 너무 늘어남</li><li>서비스 개수만큼 관리비용이 크다</li><li>트랜잭션과 같은 로직 구현이 까다롭다<ul><li>서비스가 여러개인데 같은 document 에 접근하려고 할 때 로직 구현 어렵</li><li>lock 걸때 지연속도가 늘어나서 어려움</li></ul></li><li>서비스 간 통신 시간만큼의 서비스 처리 속도 증가 (hop 마다 속도가 늘어남)</li></ul><h3>Kubernetes 단점</h3><ul><li>기본 구성이 매우 복잡하다</li><li>초기 프로세스를 구축하기 위해 많은 노력</li><li>소규모에 적합하지 않다</li></ul><h4>장점</h4><ul><li>다양한 기능 제공</li><li>오토스케일링, 롤링 업데이트, Failover 기능으로 라이브 운영에 적합</li></ul><hr><p>개인적으로는 게임 서버 뿐 아니라 어떤 서버든 적용되는 내용을 꼼꼼하게 설명해주셔서 좋았다.
아는게 조금 늘어났다고 좀더 이해되는게 너무 신기하고 (그래서 후기도 쓸 수 있었고 ㅋㅋ),
좀더 개발 세션 들어야겠다.</p><p>위의 내용이 발표와 다르거나 틀린 점이 있는 경우 둥글게 댓글 부탁드립니다.</p></section></div></div>

Juneyr.dev RSS Feed

June Kim

발표자료는 올라올테지만, 가장 인상깊게 들었던 발표를 들으며 적었던 노트를 날것으로 (ㅋㅋ) 공유합니다.   서버 포스트모템 김에스더님 From EA Korea 런칭 이전에 서버 준비과정부터 런칭 이후 운영 이슈까지 공유하고자 함 Microservices on Kubernetes(오케스트레이션 툴) 서버 아키텍쳐 피파온라인4는 FIFA시리즈 바탕 온라인 게임 아시아 4개국, PC…

NDC(Nexon Developer Conference) 2019, <FIFA 온라인 4> 서버 포스트모템 후기

댓글