Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 Seoul
3 likes1,667 views
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 에서 보실 수 있습니다.
![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 설정](https://image.slidesharecdn.com/2019elasticondevsisters-2-190803233319/85/Elastic-Stack-elastic-on-2019-Seoul-14-320.jpg)
Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 Seoul
- 1. 1 Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 오 승 용 SeungYong Oh 데브시스터즈 데이터플랫폼그룹 Data Platform Group, Devsisters Corp. 2019. 2. 22
- 2. 2 DEVSISTERS & 팀 소개
- 3. 3 • 한국과 동남아를 휩쓴 CookieRun 시리즈의 개발사 • 전문 퍼블리싱 회사로 도약 앱 다운로드 수 1억 건+ 월간 활성 사용자 수 2백만 명+ *CookieRun 시리즈 전체 통합, 2018년 12월 기준
- 4. 4 Data Platform Group 데브시스터즈에서 서비스하는 모든 제품의 로그/데이터 파이프라인을 담당하는 조직
- 5. 5 로그란 무엇인가 로그 : “이벤트에 대한 기록”
- 6. 6 데브시스터즈 로깅 플랫폼에서 생산/수집하는 다양한 유형의 로그들 • 액세스 로그 ‒ 어떤 주체(ex. 유저, 다른 서버) 로부터의 접근/응답 기록 • 유저 CS 대응용 로그 ‒ 결제, 재화 지급 등 유저로부터의 CS 요청에 대응하기 위한 로그 • 분석 로그 ‒ 제품의 핵심 성과 지표 (KPI) 를 비롯해 제품의 분석을 위해 남기는 로그 • 어플리케이션 로그 ‒ 서버 또는 클라이언트에서 디버깅, 운영 등의 목적으로 남기는 로그 (ex. "server is running..", "db conn timeout") • 감사(audit) 로그 ‒ 운영툴, 인프라 작업 등 다양한 행동에 대한 감사 로그
- 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 로깅 플랫폼으로 수집되는 로그의 볼륨 일일 로그 건수 일일 로그 사이즈 로깅 플랫폼을 쓰는 프로덕션 서비스 3억 건+ 500GB+ 6
- 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 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 Beats를 통한 서버 로그 수집
- 12. 12 Beats: Lightweight Data Shippers • Logstash보다 기능이 한정적이지만, 기능별로 특화된 Data Shippers
- 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 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 하지만 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 하지만 Filebeat 에서의 로그 전처리는 제한적 • 전처리 기능이 제한적이고, 전처리를 할 수 있다고 하더라도 호스트에 부하를 유발함 • Filebeat에서 Elasticsearch로 바로 로그를 보내는 경우 Elasticsearch Ingest Node Pipeline을 사용하여 Elasticsearch 노드에서 전처리 진행 https://www.elastic.co/blog/new-way-to-ingest-part-2 참고: Elasticsearch를 주 로그 저장소로 사용한다면
- 17. 17 하지만 Filebeat 에서의 로그 전처리는 제한적 • 본 인프라에서는 Kafka로 로그를 보내므로, 다른 대안을 통하여 전처리 • Kafka Streams를 이용하여 전처리 진행 VM & Containers Kubernetes Cluster Filebeat Agent beats cookierun-prod- accesslog Kafka Streams 전처리된 로그를 적당한 토픽에 넣어줌
- 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 그래서 좋나요? • 성능적으로는 더할 나위 없는 수준 (Filebeat에서의 전처리를 최소화한다면) • 처음 도입했을 때는 다양한 버그 및 이슈들 존재 ‒ ex) 도커에서 16KB 가 넘는 로그 출력 시 로그를 두개로 나눠 출력하는 Breaking Change 발생 ➔ 해당 기능 filebeat 구현에 버그 ‒ Filebeat가 처리한 로그파일 offset과 실제 로그파일 offset 차이를 모니터링하여 대응 • 6개월 이상 프로덕션에서 이슈 없이 사용 중 • 꾸준히 개선되고 있으므로 가능한 최신 버전 사용을 권장
- 20. 20 ELK Infra @ DEVSISTERS
- 21. 21 ELK @ DEVSISTERS • 2013년부터 도입하여 현재까지 사용 중 • 현재 OSS version을 사용, Elastic Platinum으로 전환 작업 중 • Kafka 에서 실시간으로 로그를 가져와서 • 최근 로그 (약 2주) 들을 Elasticsearch에 인덱싱해 두고 • 실시간 로그 조회, 검색, 분석에 이용
- 22. 22 ELK @ DEVSISTERS Logstash Elasticsearch Kibana Logstash가 Kafka에서 로그를 가져와서 Logstash가 Elasticsearch로 로그를 보내주면 logstash-2019.02.22 Elasticsearch에 저장되고 Kibana에서 조회 (로그 생성 후 ~10초 이내) Curator 2주 이상 지난 로그 인덱스 삭제 참 쉽죠?
- 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 그러나 현실은.. • 인덱스를 가능한 잘게 쪼갬: `{service_name}-{environment}-{logType}` ‒ 서비스별로 다른 로그 스키마 충돌 방지 ‒ 개발 환경과 프로덕션 환경 서버 로그 충돌 방지 • 타입 추정이 불필요하거나, 검색 또는 aggregation이 불필요한 필드는 인덱스 템플릿을 적절히 설정 로그의 형태가 제각각 – 스키마를 통제하기 어렵다 { "cookierun_tpl": { "template": "cookierun-*", "mappings": { "_doc": { "date_detection": false, "properties": { "@timestamp": { "type": "date" }, "statistics": { "enabled": false } } } } } }
- 25. 25 그러나 현실은.. • 사내의 다양한 직군, 사외(게임 개발사)에 Kibana 제공 필요 • 소속 회사별, 개인별로 특정 서비스에 대한 로그만 제공 필요 • Elastic Gold/Platinum 의 RBAC 기능을 쓰는 것이 바람직 Kibana 의 권한 관리 Elasticsearch NGINX Proxy (서비스 A 관련 요청만 프록시) Kibana for Service A OAuth2 Proxy
- 26. 26 그러나 현실은.. • 사내의 다양한 직군, 사외(게임 개발사)에 Kibana 제공 필요 • 다양한 개인정보성 로그 필드에 대한 redact 처리 필요 • Elastic Platinum을 사용한다면 Field-level Security 기능을 통하여 보다 손쉬운 대응 가능 로그에 있는 수많은 개인정보들 # logstash.conf input { ... } filter { mutate { update => { "device_id" => "<redacted>" } } } output { ... } }
- 27. 27 ELK Use Cases
- 28. 28 Use Case 1: 서버 모니터링과 운영 • Kibana를 통하여 모든 서버의 로그를 모아 볼 수 있음 • 각 서버에 일일이 들어가지 않아도 빠른 이슈 탐지와 대응 가능 • 서버 인프라 접근 권한이 제한적인 개발사 엔지니어도 Kibana 열람 가능
- 29. 29 Use Case 2: 실시간 게임 운영 대응 수단 • 게임 디자이너도 Kibana를 통하여 손쉽게 게임의 현황 모니터링 가능 • 어뷰저에 대한 신속한 대응, 패치 실수로 인한 인플레이션 등을 조기에 탐지 • 이슈에 대해 영향을 받은 유저나 분포도 몇 초 만에 쉽게 확인 • 필요한 경우, Elasticsearch에 직접 쿼리하여 로그 조회, 유저 데이터 롤백 등 대응도 가능
- 30. 30 Use Case 3: 실시간 지표 대시보드 • 동접자 수, 주요 서비스 현황 등을 로그 기반으로 실시간 분석 가능
- 31. 31 운영을 위한 사소한 팁들
- 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 자동화 • Terraform 을 이용한 Infrastructure as a Code ‒ ELK 인프라를 비롯한 모든 로깅 플랫폼 인프라는 코드로 관리 ‒ Custom Provider를 통해, Role, Role Mapping, Index Template 등도 자동화된 스크립트를 통하여 상태 관리 및 업데이트 사람이 할 수 있지만 기계가 잘하는 것은 기계에게
- 34. 34 자동화 • Vault 를 이용한 패스워드 및 인증서 관리 ‒ Vault: 시크릿 저장소, 적절한 권한을 가진 유저/머신에만 시크릿 제공 기능 ‒ Elasticsearch Built-In User 들의 패스워드를 모두 Vault 에서 관리 ‒ Vault 의 자체 CA 및 인증서 발급 기능을 통하여, Elasticsearch 노드나 Logstash와 같은 클라이언트들의 인증서를 Vault로 발급 사람이 할 수 있지만 기계가 잘하는 것은 기계에게
- 35. 35 고가용성 구조 / Fault-Tolerant • Elasticsearch, Logstash, Kibana 모두 (준) 고가용성 구조로 설정이 가능 – 서버 한대가 죽더라도 특별한 지장이 없음 – Self-Healing 되어 사람이 건드리지 않아도 복구되는 경우도 있음
- 36. 36 기타 사소한 의견 • Elastic을 프로덕션에서 쓰려면 Training 강력 추천! • 매니지드 솔루션도 좋은 옵션이 될 수 있다 • Elastic Stack 이 오픈소스 프로젝트임을 잘 활용하면 좋다 – GitHub 에 이슈 올리면 많은 경우 적극적으로 대응 – 기여를 위한 가이드라인이 잘 되어 있고, 개방적이며 친절하다는 인상
- 37. 37 기타 사소한 의견 • Elastic을 프로덕션에서 쓰려면 Training 강력 추천! • 매니지드 솔루션도 좋은 옵션이 될 수 있다 • Elastic Stack 이 오픈소스 프로젝트임을 잘 활용하면 좋다 – GitHub 에 이슈 올리면 많은 경우 적극적으로 대응 – 기여를 위한 가이드라인이 잘 되어 있고, 개방적이며 친절하다는 인상
- 39. 39 Thank You!