Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 Seoul

elastic{on} 2019 Seoul 에서 발표한 데브시스터즈(Devsisters Corp.) 의 Elastic Stack 기반 게임 서비스 통합 로깅 플랫폼 소개 발표 자료입니다.
발표 영상은 https://www.elastic.co/kr/elasticon/tour/2019/seoul/devsisters-game-service-integration-logging-platform-using-elastic-stack 에서 보실 수 있습니다.

  • Be the first to comment

Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 Seoul

  1. 1. 1 Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 오 승 용 SeungYong Oh 데브시스터즈 데이터플랫폼그룹 Data Platform Group, Devsisters Corp. 2019. 2. 22
  2. 2. 2 DEVSISTERS & 팀 소개
  3. 3. 3 • 한국과 동남아를 휩쓴 CookieRun 시리즈의 개발사 • 전문 퍼블리싱 회사로 도약 앱 다운로드 수 1억 건+ 월간 활성 사용자 수 2백만 명+ *CookieRun 시리즈 전체 통합, 2018년 12월 기준
  4. 4. 4 Data Platform Group 데브시스터즈에서 서비스하는 모든 제품의 로그/데이터 파이프라인을 담당하는 조직
  5. 5. 5 로그란 무엇인가 로그 : “이벤트에 대한 기록”
  6. 6. 6 데브시스터즈 로깅 플랫폼에서 생산/수집하는 다양한 유형의 로그들 • 액세스 로그 ‒ 어떤 주체(ex. 유저, 다른 서버) 로부터의 접근/응답 기록 • 유저 CS 대응용 로그 ‒ 결제, 재화 지급 등 유저로부터의 CS 요청에 대응하기 위한 로그 • 분석 로그 ‒ 제품의 핵심 성과 지표 (KPI) 를 비롯해 제품의 분석을 위해 남기는 로그 • 어플리케이션 로그 ‒ 서버 또는 클라이언트에서 디버깅, 운영 등의 목적으로 남기는 로그 (ex. "server is running..", "db conn timeout") • 감사(audit) 로그 ‒ 운영툴, 인프라 작업 등 다양한 행동에 대한 감사 로그
  7. 7. 7 예시: 액세스 로그 { "timestamp": "2017-03-16T18:25:53.342+09:00", "logType": "access", "level": "info", "messageId": "E5620934-D1EF-4F5D-86EB-C8EB0F3CE6DE", "userId": "ABCDE1234", "requestMethod": "POST", "requestAPI": "/game/play/save", "request": { "stageId": "1-1", "character": { "id": 100100, "lv": 1 }, "score": 123456780, "playTime": 1000 }, "responseCode": "200" "response": { "responseType": "OK", "userInfo": { "coin": 52300, "exp": 20033 } } } • 유저 또는 다른 서버로부터의 요청 이벤트와, 이에 대한 응답을 기록 • 요청 URL, 응답코드 뿐만 아니라, 필요에 따라 요청과 응답을 세세히 기록
  8. 8. 8 로깅 플랫폼으로 수집되는 로그의 볼륨 일일 로그 건수 일일 로그 사이즈 로깅 플랫폼을 쓰는 프로덕션 서비스 3억 건+ 500GB+ 6
  9. 9. 9 로그를 어떻게 수집하고 적재하여 활용하나요? Web Frontend Game Client 3rd Party Services VM & Containers Kubernetes Cluster Filebeat Agent Log Collector Server Apache Kafka & Kafka Streams Logstash Elasticsearch Kibana Amazon S3 User Log Query Service Apache Spark 준실시간(<10초) ~최근 2주간의 로그 저장 장기 로그 적재 저장소 (일 단위 로그) 로그 메세지 큐 약 3일간의 로그 저장 하루 단위 배치 작업
  10. 10. 10 Elastic Stack @ DEVSISTERS Web Frontend Game Client 3rd Party Services VM & Containers Kubernetes Cluster Filebeat Agent Log Collector Server Apache Kafka & Kafka Streams Logstash Elasticsearch Kibana Amazon S3 User Log Query Service Apache Spark
  11. 11. 11 Beats를 통한 서버 로그 수집
  12. 12. 12 Beats: Lightweight Data Shippers • Logstash보다 기능이 한정적이지만, 기능별로 특화된 Data Shippers
  13. 13. 13 Filebeat • 로그 파일 수집을 위한 에이전트 • 지정한 로그 파일이 업데이트될 때마다, 지정된 목적지로 추가된 메세지 전송 ‒ Elasticsearch, Logstash, Kafka 등 • 간단한 설정만으로 Docker Container / Kubernetes 에서의 로그 수집도 가능 Game Server app: cookierun role: gameserver env: dev logging: enabled Instance Filebeat Agent {“timestamp”:..,”msg”:.} {“timestamp”:..,”msg”:.} {“timestamp”:..,”msg”:.} {“timestamp”:..,”msg”:.} {“timestamp”:..,”msg”:.} {“timestamp”:..,”msg”:.} {“timestamp”:..,”msg”:.} /var/lib/docker/../.jsonDocker json-file dirver stdout/stderr -> json files Elasticsearch OR
  14. 14. 14 filebeat.inputs: - type: docker containers.ids: - "*" processors: - add_docker_metadata: host: "unix:///var/run/docker.sock" - drop_event: when.not.equals: docker.container.labels.logging: "enabled" processors: - add_cloud_metadata: ~ output.kafka: hosts: ["..."] version: "..." topic: "beats" ... Filebeat를 이용한 컨테이너 로그 수집 Filebeat Agent Host / Container 관련 필드 추가 Docker Input 설정 수집 대상 이외 로그 제외 Kafka Output 설정
  15. 15. 15 하지만 Filebeat 에서의 로그 전처리는 제한적 Filebeat Agent {"msg":"hello, world!", "logtype":"accesslog"} { "@timestamp": "2018-02-12T01:57:32.549Z", "docker": { "container": { "labels": { "logging": "enabled", "app": "cookierun", "env": "prod" } } "message": "{"msg":"hello world","logtype":"accesslog"}", } Game Server app: cookierun role: gameserver env: dev logging: enabled
  16. 16. 16 하지만 Filebeat 에서의 로그 전처리는 제한적 • 전처리 기능이 제한적이고, 전처리를 할 수 있다고 하더라도 호스트에 부하를 유발함 • Filebeat에서 Elasticsearch로 바로 로그를 보내는 경우 Elasticsearch Ingest Node Pipeline을 사용하여 Elasticsearch 노드에서 전처리 진행 https://www.elastic.co/blog/new-way-to-ingest-part-2 참고: Elasticsearch를 주 로그 저장소로 사용한다면
  17. 17. 17 하지만 Filebeat 에서의 로그 전처리는 제한적 • 본 인프라에서는 Kafka로 로그를 보내므로, 다른 대안을 통하여 전처리 • Kafka Streams를 이용하여 전처리 진행 VM & Containers Kubernetes Cluster Filebeat Agent beats cookierun-prod- accesslog Kafka Streams 전처리된 로그를 적당한 토픽에 넣어줌
  18. 18. 18 { "@timestamp": "2018-02-12T01:57:32.549Z", "app": "cookierun", "env": "prod", "logtype": "accesslog", "msg": "hello world" } 하지만 Filebeat 에서의 로그 전처리는 제한적 Filebeat Agent { "@timestamp": "2018-02-12T01:57:32.549Z", "docker": { "container": { "labels": { "logging": "enabled", "app": "cookierun", "env": "prod" } } "message": "{"msg":"hello world","logtype":"accesslog"}", } Streams
  19. 19. 19 그래서 좋나요? • 성능적으로는 더할 나위 없는 수준 (Filebeat에서의 전처리를 최소화한다면) • 처음 도입했을 때는 다양한 버그 및 이슈들 존재 ‒ ex) 도커에서 16KB 가 넘는 로그 출력 시 로그를 두개로 나눠 출력하는 Breaking Change 발생 ➔ 해당 기능 filebeat 구현에 버그 ‒ Filebeat가 처리한 로그파일 offset과 실제 로그파일 offset 차이를 모니터링하여 대응 • 6개월 이상 프로덕션에서 이슈 없이 사용 중 • 꾸준히 개선되고 있으므로 가능한 최신 버전 사용을 권장
  20. 20. 20 ELK Infra @ DEVSISTERS
  21. 21. 21 ELK @ DEVSISTERS • 2013년부터 도입하여 현재까지 사용 중 • 현재 OSS version을 사용, Elastic Platinum으로 전환 작업 중 • Kafka 에서 실시간으로 로그를 가져와서 • 최근 로그 (약 2주) 들을 Elasticsearch에 인덱싱해 두고 • 실시간 로그 조회, 검색, 분석에 이용
  22. 22. 22 ELK @ DEVSISTERS Logstash Elasticsearch Kibana Logstash가 Kafka에서 로그를 가져와서 Logstash가 Elasticsearch로 로그를 보내주면 logstash-2019.02.22 Elasticsearch에 저장되고 Kibana에서 조회 (로그 생성 후 ~10초 이내) Curator 2주 이상 지난 로그 인덱스 삭제 참 쉽죠?
  23. 23. 23 그러나 현실은.. • Kibana에서 로그가 안보여요! ➔ 대부분 매핑 타입 충돌로 인덱싱 실패 • Schemaless Dynamic Typing • 타입이 충돌하는 다양한 경우 ‒ 같은 종류의 로그 (ex. 로그인 액세스 로그) 를 찍는데 서버를 패치하면서 일부 필드 타입이 바뀌었거나 ‒ 다른 종류의 로그를 찍는데 같은 이름의 필드로 다른 내용의 로그가 들어가거나 ‒ Date 포맷의 String 은 Date type으로 타입을 추정해서, 다른 형태의 String 타입 로그가 같은 필드에 설정되면 ‒ …. • 매핑을 통제하면 좋지만, 특히 플랫폼을 제공하는 입장에서 한계가 있음 로그의 형태가 제각각 – 스키마를 통제하기 어렵다 # 로그 1 { "@timestamp": "2018-02-12T01:57:32.549Z", "request": { "item": {"id": 1}, "receivedAt": "2019-02-22T01:11:11" } } # 로그 2 { "@timestamp": "2018-02-12T01:57:32.549Z", "request": { "item": "1", "receivedAt": "" } }
  24. 24. 24 그러나 현실은.. • 인덱스를 가능한 잘게 쪼갬: `{service_name}-{environment}-{logType}` ‒ 서비스별로 다른 로그 스키마 충돌 방지 ‒ 개발 환경과 프로덕션 환경 서버 로그 충돌 방지 • 타입 추정이 불필요하거나, 검색 또는 aggregation이 불필요한 필드는 인덱스 템플릿을 적절히 설정 로그의 형태가 제각각 – 스키마를 통제하기 어렵다 { "cookierun_tpl": { "template": "cookierun-*", "mappings": { "_doc": { "date_detection": false, "properties": { "@timestamp": { "type": "date" }, "statistics": { "enabled": false } } } } } }
  25. 25. 25 그러나 현실은.. • 사내의 다양한 직군, 사외(게임 개발사)에 Kibana 제공 필요 • 소속 회사별, 개인별로 특정 서비스에 대한 로그만 제공 필요 • Elastic Gold/Platinum 의 RBAC 기능을 쓰는 것이 바람직 Kibana 의 권한 관리 Elasticsearch NGINX Proxy (서비스 A 관련 요청만 프록시) Kibana for Service A OAuth2 Proxy
  26. 26. 26 그러나 현실은.. • 사내의 다양한 직군, 사외(게임 개발사)에 Kibana 제공 필요 • 다양한 개인정보성 로그 필드에 대한 redact 처리 필요 • Elastic Platinum을 사용한다면 Field-level Security 기능을 통하여 보다 손쉬운 대응 가능 로그에 있는 수많은 개인정보들 # logstash.conf input { ... } filter { mutate { update => { "device_id" => "<redacted>" } } } output { ... } }
  27. 27. 27 ELK Use Cases
  28. 28. 28 Use Case 1: 서버 모니터링과 운영 • Kibana를 통하여 모든 서버의 로그를 모아 볼 수 있음 • 각 서버에 일일이 들어가지 않아도 빠른 이슈 탐지와 대응 가능 • 서버 인프라 접근 권한이 제한적인 개발사 엔지니어도 Kibana 열람 가능
  29. 29. 29 Use Case 2: 실시간 게임 운영 대응 수단 • 게임 디자이너도 Kibana를 통하여 손쉽게 게임의 현황 모니터링 가능 • 어뷰저에 대한 신속한 대응, 패치 실수로 인한 인플레이션 등을 조기에 탐지 • 이슈에 대해 영향을 받은 유저나 분포도 몇 초 만에 쉽게 확인 • 필요한 경우, Elasticsearch에 직접 쿼리하여 로그 조회, 유저 데이터 롤백 등 대응도 가능
  30. 30. 30 Use Case 3: 실시간 지표 대시보드 • 동접자 수, 주요 서비스 현황 등을 로그 기반으로 실시간 분석 가능
  31. 31. 31 운영을 위한 사소한 팁들
  32. 32. 32 수많은 컴포넌트.. • 다수의 지역에 위치한, 다수의 서버들에서 돌아가는 다수의 컴포넌트 ‒ Filebeat가 깔린 모든 서버들 n백 대 ‒ 로그 수집 서버, Kafka Brokers, 로그 전처리 서버 (kafka streams), logstash, elasticsearch ‒ n개의 서비스 * (elasticsearch proxy + kibana + oauth2 proxy) ‒ 를 포함한 약 20개 상당의 컴포넌트들이 여러 대씩 존재 • 현재 2명이 로깅 플랫폼 전체의 구축과 운영을 담당 (각각 half-time) ‒ 2018년 기준 Elastic Stack 운영 및 개발에 투자한 시간 약 1 man-month ‒ 서비스 가용율 99.5% 이상, 유의미한 로그 유실 케이스 없음 (2015~) 그런데 운영자는 2명..?!
  33. 33. 33 자동화 • Terraform 을 이용한 Infrastructure as a Code ‒ ELK 인프라를 비롯한 모든 로깅 플랫폼 인프라는 코드로 관리 ‒ Custom Provider를 통해, Role, Role Mapping, Index Template 등도 자동화된 스크립트를 통하여 상태 관리 및 업데이트 사람이 할 수 있지만 기계가 잘하는 것은 기계에게
  34. 34. 34 자동화 • Vault 를 이용한 패스워드 및 인증서 관리 ‒ Vault: 시크릿 저장소, 적절한 권한을 가진 유저/머신에만 시크릿 제공 기능 ‒ Elasticsearch Built-In User 들의 패스워드를 모두 Vault 에서 관리 ‒ Vault 의 자체 CA 및 인증서 발급 기능을 통하여, Elasticsearch 노드나 Logstash와 같은 클라이언트들의 인증서를 Vault로 발급 사람이 할 수 있지만 기계가 잘하는 것은 기계에게
  35. 35. 35 고가용성 구조 / Fault-Tolerant • Elasticsearch, Logstash, Kibana 모두 (준) 고가용성 구조로 설정이 가능 – 서버 한대가 죽더라도 특별한 지장이 없음 – Self-Healing 되어 사람이 건드리지 않아도 복구되는 경우도 있음
  36. 36. 36 기타 사소한 의견 • Elastic을 프로덕션에서 쓰려면 Training 강력 추천! • 매니지드 솔루션도 좋은 옵션이 될 수 있다 • Elastic Stack 이 오픈소스 프로젝트임을 잘 활용하면 좋다 – GitHub 에 이슈 올리면 많은 경우 적극적으로 대응 – 기여를 위한 가이드라인이 잘 되어 있고, 개방적이며 친절하다는 인상
  37. 37. 37 기타 사소한 의견 • Elastic을 프로덕션에서 쓰려면 Training 강력 추천! • 매니지드 솔루션도 좋은 옵션이 될 수 있다 • Elastic Stack 이 오픈소스 프로젝트임을 잘 활용하면 좋다 – GitHub 에 이슈 올리면 많은 경우 적극적으로 대응 – 기여를 위한 가이드라인이 잘 되어 있고, 개방적이며 친절하다는 인상
  38. 38. 38 We are Hiring! https://careers.devsisters.com
  39. 39. 39 Thank You!

    Be the first to comment

  • faceboak

    Mar. 1, 2020
  • changunjung

    Mar. 1, 2021

elastic{on} 2019 Seoul 에서 발표한 데브시스터즈(Devsisters Corp.) 의 Elastic Stack 기반 게임 서비스 통합 로깅 플랫폼 소개 발표 자료입니다. 발표 영상은 https://www.elastic.co/kr/elasticon/tour/2019/seoul/devsisters-game-service-integration-logging-platform-using-elastic-stack 에서 보실 수 있습니다.

Views

Total views

939

On Slideshare

0

From embeds

0

Number of embeds

35

Actions

Downloads

21

Shares

0

Comments

0

Likes

2

×