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 에서 보실 수 있습니다.

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 에 이슈 올리면 많은 경우 적극적으로 대응
– 기여를 위한 가이드라인이 잘 되어 있고, 개방적이며 친절하다는 인상

38. 38
We are Hiring!
https://careers.devsisters.com

39. 39
Thank You!