안녕하세요. 데브시스터즈 데이터플랫폼그룹의 박기범, 서혜인입니다.여러분은 사업 지표를 얼마나 신속하고 정확하게 확인하고 싶으신가요? 아마 대부분 가능한 빠른 시점에 정확한 지표를 확인하고 싶어 하실 겁니다. 하지만, 데이터팀 입장에서는 사용자가 원하는 수준으로 정확하고 신속한 지표 서비스를 제공하기 위해 기술적으로 해결해야 하는 많은 문제들에 직면하게 됩니다. 이번 글에서는 데브시스터즈가 지난 수개월간 준실시간 지표 서비스를 도입하는 과정에서 마주하게 된 여러 기술적 도전 과제들과 해결 과정에 대해 소개해드리고자 합니다.게임 런칭 당일에 어떤 지표를 볼 수 있나요?신규 게임이 출시되는 날, 모든 구성원의 관심은 게임 지표에 집중됩니다.출시 직후 촌각을 다투는 상황에서는, 게임팀에서 유저의 접속 현황과 매출 성과에 따라 빠르게 의사결정을 내릴 수 있도록 “정확하고 신속하게” 지표를 확인할 수 있어야 합니다. 정확하지 않은 지표는 자칫하면 잘못된 의사결정을 초래할 수 있으며, 지표 조회가 지연되면 중요한 순간에 빠른 결정을 내리기 어려워지기 때문입니다.이런 이유로 대부분의 데이터 조직은 짧은 지연 시간으로 주요 지표를 확인할 수 있는 준실시간(near real-time) 지표 서비스 도입을 고려하게 됩니다. 하지만, 왜 많은 회 사들이 준실시간 지표 서비스 도입에 어려움을 겪고 있을까요?각 회사마다 마주한 상황은 다르겠지만, 데브시스터즈에서 그동안 준실시간 지표 서비스를 도입하지 못한 데는 다양한 이유들이 있었습니다.데브시스터즈에서는 2015년부터 Spark 과 Elastic Stack 기반의 빅데이터 플랫폼을 운영해 왔습니다.2021년에는 Databricks를 도입하여 Lakehouse Architecture와 Medallion Architecture 기반의 데이터 환경을 구축했습니다. 이를 통해, DB와 로그 등 게임 서비스와 여러 플랫폼에서 발생하는 다양한 데이터를 가공 및 집계하여 지표 서비스에 활용 중이었습니다.해당 환경에서 지표를 서비스하는 방법은 크게 세 가지로 구성되어 있었습니다.• 게임 서버에 연결된 세션 수를 기반으로 동시 접속자 (이하 '동접') 지표를 집계합니다.• 시간별 배치로 운영계 DB 테이블을, 일별 배치로 로그를 ETL하여 Data Warehouse와 Data Mart에 적재합니다.• Elasticsearch 에 적재된 로그 원장을 기반으로 Kibana 에서 준실시간으로 갱신과 조회가 가능한 대시보드를 구성하여 활용합니다.이처럼 기존 지표 환경에서도 게임 런칭 당일 제공할 수 있는 지표들이 존재하였지만, 사용자 요구를 완전히 충족시키기엔 한계가 있었습니다.기존 동접 지표는 서버 입장에서의 세션 수만 수집했기 때문에 국가별, 스토어별 세부 동접 지표는 확인할 수 없었습니다. 특히 게임 런칭 초기에는 특정 국가의 반응, 스토어 및 OS별 접속 현황, 10분 단위의 접속자 추이를 빠르게 파악할 필요가 있었지만, 이를 확인할 수 있는 방법이 없어 불편했습니다. 반면 DB 기반의 시간별 지표에서는 여러 차원에서 지표를

bread.young ELK 환경에서 로그를 어떻게 쌓고, 보여주는지 쉽게 설명된 글입니다. 이슈 트래킹을 쉽게 하는 방법은 개발자라면 누구나 고민하는 부분인데 어떻게 풀어내었는지 궁금하네요🧐!!rain.drop ELK 환경에서의 로깅 방식과 Sentry를 이용한 이슈 트래킹 전략을 쉽게 풀어쓴 글입니다. ELK 환경을 구축하려는 분, 혹은 동일한 문제에 고민을 갖고 계신 분들께 추천드립니다~!안녕하세요. 해외결제서비스유닛에서 서버 개발 업무를 맡고 있는 포도입니다.지난 포스팅인, Part1 - 이슈 트래킹 기반 마련하기에서는 ELK를 활용한 Request 요청 로깅과 Sentry를 적용한 이슈 트래킹 전략의 기반을 구성하는 내용을 설명하였습니다. 그리고 서비스를 운영하면서 Part1의 전략만으로 겪은 몇 가지 문제점도 설명하였습니다.이번 포스팅인, Part2에서는 Part1의 문제점을 개선하기 위해서 Thread Context를 적극 활용하여 이슈 트래킹을 발전시킨 과정을 설명드립니다. 좀 더 빠르게 Request 요청 로그를 확인하는 방법과, 로그에는 담을 수 없었던 필요로 하는 정보들을 Thread Context를 활용하여 확보한 방법을 공유합니다.Part2의 내용은 Part1의 내용과 예시를 기반으로 작성되었습니다. Part2의 읽기에 앞서, Part1의 내용을 복기하고 읽는 것을 권장드립니다.본문에 앞서 Part1의 문제점을 간단하게 복기하면 다음과 같습니다.첫 번째 문제점은 수많은 로그에서 예외 발생 로그를 찾기가 쉽지 않다는 점입니다. 예외가 발생하면 이슈 원인 분석을 위해 Kibana에 접근해 로그를 확인해야 하지만, 빠르게 대응해야 하는 상황에서 이 과정은 큰 방해 요소가 될 수 있습니다.두 번째 문제점은 Request 요청 로그가 이슈 원인을 분석하기에는 충분하지 않다는 점입니다. Request 요청 로그에는 요청, 응답에 대한 정보를 포함하고 있지만 이 정보만으로 이슈 원인을 분석하기에는 어려운 경우가 발생합니다. Part2에서는 위의 문제점을 Thread Context를 적극 활용하여 개선하는 전략을 공유합니다.Spring Boot, 그중에서도 Spring MVC는 일반적으로 Tomcat을 WAS로 사용하고 있습니다. 따라서 본 포스팅에서의 의 명시는 Tomcat을 WAS로 사용하는 것을 가정합니다.Tomcat은 Thread Per Request 모델을 사용합니다. 말 그대로 Thread Pool에서 하나의 Request 요청 당 하나의 Thread를 할당하는 메커니즘입니다. 이 해석은 Request 요청에 대한 로직을 처리하는 비즈니스 흐름에 별도의 비동기 로직이 없다면 할당받은 Thread를 계속 사용하는 것을 의미합니다. 이번 이슈 트래킹 전략은 위의 해석을 적극적으로 활용해보려고 합니다.이슈 발생 시, 로그까지의 지름길Part1에서는 Servlet Filter인 를 정의하여 ELK 환경에서 Request 요청에 대한 로깅을 남기는 전략을 사용하였습니다. 이번 일반편에서는 를 고도화하려고 합니다.먼저 의 시작

bread.young ELK 환경에서 로그를 어떻게 쌓고, 보여주는지 쉽게 설명된 글입니다. 이슈 트래킹을 쉽게 하는 방법은 개발자라면 누구나 고민하는 부분인데 어떻게 풀어내었는지 궁금하네요🧐!!rain.drop ELK 환경에서의 로깅 방식과 Sentry를 이용한 이슈 트래킹 전략을 쉽게 풀어쓴 글입니다. ELK 환경을 구축하려는 분, 혹은 동일한 문제에 고민을 갖고 계신 분들께 추천드립니다~!안녕하세요. 해외결제서비스유닛에서 서버 개발 업무를 맡고 있는 포도입니다.지난 포스팅인 Kotlin으로 Spring AOP 극복하기!에 이어 이번 글에서는, Spring 기반의 서비스를 운영하는 개발자를 대상으로 이슈 트래킹 전략을 다룹니다. 복잡한 비즈니스 로직과 트랜잭션을 처리하는 환경에서 효과적인 이슈 트래킹을 고민하는 개발자에게 유용할 것입니다.이번에 다루게 될 내용은, 이슈 트래킹 전략을 단계적으로 발전시키는 과정을 3개의 Part로 나누어 설명하려고 합니다. 또한, 앞으로 소개될 내용의 전반적인 코드는 hello-elk-thread에서 확인하실 수 있습니다.• 먼저 이번 포스팅인 Part1에서는, ELK 환경에서의 Request 요청 로깅과 Sentry를 사용한 이슈 트래킹 전략의 기반을 마련합니다. 그리고 몇 가지 문제점을 설명하려고 합니다.• Part2에서는, Part1에서 설명한 문제점을 해결하기 위해 ThreadContext를 활용하여 이슈 트래킹 전략을 발전시킨 과정을 설명하려고 합니다.• 마지막인 Part3에서는, Part2에서 다루지 못하는 배치성 API, 비동기 상황에서의 극복을 위해 Multi Thread Context를 활용하여 발전시킨 과정을 설명하려고 합니다.만약에 ELK, Sentry를 사용한 이슈 트래킹 전략을 이미 사용하고 있다면, Part2부터 읽기를 시작하는 것을 추천드립니다.ELK 환경에서 로그 기반 마련하기이슈 발생 시 원인을 분석하기 위해서는 로그 정보를 확인하는 과정은 필수적일 것입니다. 하지만 로그를 분석하기 위한 별도의 환경이 구성되어 있지 않다면, 파일로 쌓아둔 로그 파일들을 하나하나 찾아가며 원인 분석을 해야 할 것입니다.ELK 스택은 애플리케이션에서 출력한 로그를 ElasticSearch에 저장하고, Kibana 대시보드를 통해서 로그 데이터의 가시성을 확보할 수 있는 환경을 제공합니다. 예를 들어 본 포스팅에서 설명할 내용처럼 Request 요청에 대한 로그 정보를 Kibana 대시보드를 통해 정보를 획득하는 것입니다.따라서 이슈 발생 시 쌓아둔 로그 파일에 접근하는 것이 아닌, Kibana 대시보드에 접근하여 로그 데이터를 빠르게 획득하여 보다 기민한 원인 분석을 할 수 있을 것입니다. 만약에 로그 분석을 하기 위한 별도의 환경이 구성되어 있지 않다면, ELK 스택을 활용한 본 포스팅의 내용이 도움이 될 것입니다.RequestLoggingFilter를 사용한 Request 요청 로깅Java Servlet의 기술 중 Servlet Filter는 클라이언트의 요청과 서버의 응답 사이에 위치하

이 번에는 AKS(Azure Kubernetes Service) 상용 서비스에 적용한 후기 다섯 번째 내용으로, k8s 환경에서 로그를 통합 관리하게 해주는 EFK 기술에 대해 소개드리려고 합니다.우선 EFK는 ElasticSearch, Fluentd, Kibana의 줄임말인데요. 이 세 가지 기술을 사용하는 아키텍처는 여러가지가 있습니다.그 중에서 서비스에 맞는 아키텍처를 선정하여 진행하면 됩니다.Use Case #1: 각 Node에 Fluentd를 데몬셋으로 설치하고 개별적으로 ElasticSearch로 전송Use Case #2: 각 Pod에 Fluentbit을 Sidecar로 설치하고 Fluentd에서 통합 수집하여 ElasticSearch로 전송 Use Case #3: 각 Pod에 Fluentbit을 Sidecar로 설치하고 Kafka를 Fluentd와의 중간에 배치하여 Log손실을 방지 Use Case #4: 각 Application Server에 쉐어드 볼륨을 마운트하고 Fluentd에서 Log적재 파일을 직접 읽어 드림그 중에서 일반적으로 Use Case 1번과 Use Case 2번을 많이 적용하는데요. Fluentd를 데몬셋으로 설치하는 방안(1번 케이스)의 장단점에 대해 알아보겠습니다.• None• None 개별 Pod에 Sidecar로 설치하는 것 보다 리소스 경량화 가능 (Pod 마다 Sidecar를 설치하는데 소요되는 자원 절약)• None fluentbit은 경량이긴 하나 fluentd에서 제공하는 다양한 필터링 기능 사용 불가 (특정 namespace 혹은 pod 로그만 수집 등)• None• None 콘솔에 출력되는 stdout/stderr를 container 로그로 저장하므로 콘솔 로그를 수집에 맞게 Json 형식으로 출력해야 함• None Daemonset resource 관리가 어려움. (Log생성이 많은 Pod가 특정 노드에 몰릴경우 발생.)각 아키텍처의 장단점을 비교 분석한 결과, 저희 서비스는 아래와 같이 "Fluentd를 데몬셋으로 설치"하는 아키텍처를 구성하게 되었습니다.저희는 ElasticSearch와 kubernetes에 맞춤형 image인 "fluentd-kubernetes-daemonset-debian-elasticsearch"를 사용하여 쿠버네티스에 데몬셋으로 설치하였습니다.설치하는 방법은 아래와 같습니다.• None• None namespace : kube-system으로 설정 필요• None• None data 하위에 key로 적은 문자열 (예 : fluent.conf) : 파일명• None | 이후 내용 : txt 형태로 파일의 내용이 됨• None 설정 : filter란 이벤트 처리를 위한 중간 pipeline으로서, 생성할 경우 정의한 문자열 규칙과 동일하게 tag를 지정한 이벤트가 들어오면 로직을 처리 (예 : kubernetes.var.log.containers.**이면 tag로 kubernetes.*로 지정할 경우 filter에 걸림)• None key_name을 log로