믿거나 말거나, 데이터 독이 data dog인 이유

 

데이터 독을 공부하게 된 계기는 애플리케이션의 인사이트를 얻기 위해서였습니다. 서킷 브레이커 적용시 서비스에 대한 이해도를 높이기 위해서 데이터 독을 공부해야겠다는 생각을 했습니다. 근데 맘 잡고 공부할려니까 참고 서적이 하나도 없었습니다.. 참고할 만한 포스팅 역시 찾질 못했습니다. 그냥 혼자 시간이 될 때마다 조금씩 살펴보는 방식으로 공부를 했는데, 포스팅 하나 나올 정도가 되어보여 정리해보려고 합니다. 

 

 

데이터 독에는 많은 기능이 있지만. 한 애플리케이션에 대한 이해도를 높이고자한다면 APM 페이지를 참조하면 충분합니다. APM 은 Application Performance Monitoring의 약자입니다. 길게 풀어 읽어보면 해당 페이지에서 어떤 정보를 제공하는지 감을 잡을 수 있습니다.


응답 시간, 에러율, 트랜잭션 처리율, 서버 사용률 등을 해당 페이지에서 확인할 수 있는데요. 이 페이지를 눈여겨서 하나씩 보다보면, 특별히 어려울 것도 없습니다. 

 

 

우선 Service Summary 만 봐도 건져갈 게 많습니다. 

 

• DEPOLYMENTS
• ERROR TRACKING
• SLOs
• INCIDENTS
• SECURITY
• PROFILES
• TRACE

 

하나씩 짚어보았습니다. 

 

 

DEPOLYMENTS  & ERROR TRACKING

DEPOLYMENTS 는 해당 애플리케이션의 배포된 버전 정보입니다. 이전 배포 버전에서의 에러와 현재 배포 버전에서의 에러를 비교하는 것도 가능해보입니다. 이때 ERROR TRACKING 을 이용해 볼 수 있는데요. 여기서는 애플리케이션에서 발생한 에러를 대시보드 형태로 살펴볼 수 있었습니다. 

 

 

한달 동안 발생한 에러 을 확인해보았습니다. 필터링을 통해 특정 에러의 발생 여부도 확인해볼 수 있고, 리소스 별 에러율도 파악할 수 있었습니다. 피트스탑 같은 기간동안 어디서 어떻게 손봐야할지 막막한 경우, 이 에러 트래킹을 통해 개선사항을 하나씩 뽑아볼 수 있겠다는 생각이 들었습니다.

 

 

 

유사한 오류를 그룹핑 해볼 수도 있고, Create Case 기능을 통해 특정 에러만 모니터링 하는 것도 가능합니다. 특이케이스라면 More.. > Save to notebook 메뉴를 통해 기록해두는 것도 해볼 수 있습니다. 특히 주시할만한 에러라면 dashboard 에 해당 에러 트래킹을 추가해놓을 수도 있습니다. 비슷한 오류들을 모아 대시보드에 그룹핑하는 것도 괜찮을 것 같네요. 예를 들면 회원가입 오류, 구독 요청시 발생하는 오류 등등

이렇게 필요 컨텍스트를 한 곳에 수집해놓으면 문제 해결을 보다 정확하고 용이하게 할 수 있지않을까요? 이슈를 따라가서 언제 시작되었고, 언제 종료되었고 얼마나 자주 발생하는지를 알게되면 이 문제가 우리 애플리케이션에, 우리 팀에 어느 정도의 영향을 끼치는지, 어느 정도의 중요성이 있는지 파악하고 또 피력할 수 있지않을까요? 문제를 문제라고 인식할 수 있도록 그를 뒷받침할 근거가 수치로서 보여지게되면 개선은 더 쉬워질지도 모르겠다는 생각을 했습니다.

 

 

SLOs

 

SLOs 메뉴에서는 서비스가 제공하는 기능이나 성능과 관련된 목표를 시각화할 수 있습니다. 여기서 SLO 란, "Service Level Objective(서비스 수준 목표)"의 약자로, 여러 서비스 레벨 지표(SLI, Service Level Indicator)를 포함합니다.
해당 메뉴는 보통 SRE 팀에서 고객과의 SLA(Service Level Agreement(서비스 수준 계약)) 를 지키기 위해 사용되는 것으로 이해했습니다.  SLO, SLI, SLA... 확 와닿지 않는다면 다음 대사로 이해해볼 수 있습니다.

 

 

SRE 팀 : "고객님 우리가 서비스 이용할 때 이 정도 수준은 보장해줄 수 있어요. 이를 위해 우리는 서비스의 여러 지표를 모니터링하며 목표치에 도달하고 있는지 체킹하고 있답니다."

 

요런 정도의 느낌이라고 이해했습니다. 더 자세한 설명은 아래 블로그를 통해 확인해볼 수 있습니다. 

https://newrelic.com/kr/blog/best-practices/what-are-slos-slis-slas

 

 

 

INCIDENTS

 

INCIDENTS 메뉴는 단어에서도 유추할 수 있다시피, '사고'에 대응할 수 있는 메뉴입니다. 보통 서비스 애플리케이션에서의 사고라고 하면 equals("장애") 가 아닐까요. 해당 메뉴는 메트릭, 트레이스, 로그에서 발견한 문제를 추적합니다. error tracking 이랑 뭐가 다른 거지? 하는 생각이 들 수 있습니다. 

 

해당 메뉴는 에러 트래킹에 더불어 에러 트래커들(다른 말로 하면 개발자, 번역하면 '나')간의 소통을 용이하게 하는 데에 초점이 맞추어져있습니다. 사고가 발생하면 사고의 크기, 중요도, 고객에게 미치는 영향을 파악하는 것도 중요한데요. 
slack 과의 연동을 통해 미리 리스팅 된 관련자들과의 채널이 생성되고, 해당 정보가 슬랙 채널에 딜리버리된답디다..

 

보통 장애 대응 채널이 만들어지기 전까지 사람이 하는 일을 해당 메뉴에서 자동화할 수 있는 것 같습니다. 자동화는 여기에 그치지않습니다. 사고를 요약하고, 타임라인을 설명하며, 사고의 원인 및 복구를 위한 설명 그리고 사후 처리까지를 포함합니다. 

 

실제 사용해본 적은 없어서 얼마나 정확한지 잘 모르겠지만, 장애에 더더더더더더 민감해야하고 더더더더더 돈이 많은 회사에서 시도해봄직 할 것 같습니다.
https://docs.datadoghq.com/ko/getting_started/incident_management/

 

 

SECURITY

 

보안 메뉴에서는 정확히 어떤 부분까지 커버하는지 파악을 못했습니다. 일단 저희 서비스를 예로들면 logBack 라이브러리의 버저닝을 감지하고 있었습니다. 코드 수준에서의 취약점을 미리 파악하여 관측하고 있는 것 같습니다. ASM (애플리케이션 시큐리티 매니징) 을 통해 더 전문적으로 보안사항을 다룰 수 있는 것으로 보입니다. 
https://kr.linkedin.com/posts/harrypark1119_gain-visibility-into-risks-vulnerabilities-activity-7029274894559322112-eGag?trk=public_profile_like_view

 

 

PROFILES

 

 

보통 프로필이라고하면, 어떤 대상에 대한 정보를 더욱 심층적으로 파악하고자 할 때 쓰이는데요. APM 집계에서 더 심층적인 정보를 얻고자 할 때도, 해당 메뉴를 이용할 수 있어보입니다. 공식 문서에 따르면 CPU 사용량, 메모리에 할당되는 개체의 양 또는 유형, 
잠금을 획득하기 위해 대기하는 시간, 네트워크 또는 파일 I/O 의 양 등 다양한 유형의 작업을 세세하게 파악할 수 있다고 합니다. 이 기능은 거대한 시스템에서 어디서 어떻게 최적화할지 잘 손에 잡히지 않을 때 사용하면 좋을 것 같다는 생각이 들었습니다. 
특히, Compare profiles 를 통해 시간대, cpu, 애플리케이션 등 다양한 기준으로 프로필을 비교하는 기능이 눈에 띄었습니다. 에러 트래킹 메뉴를 통해, 많이 발생하는 에러 중에서 최적화할만한 주제를 이 기능을 통해 찾을 수 있겠다라는 생각도 듭니다. 

 

 

 

TRACE

 

 

TRACE 제가 가장 잘 사용하는 메뉴입니다. 사실 대부분의 개발자들이 데이터독에서 가장 많이 보는 탭이 아닐까 생각합니다.

 

오류 발생시 span list 탭을 이용하면 트래킹하기 수월합니다. 각 개체에서 span 의 갯수와 평균 속도, 실행 시간 등을 확인해볼 수 있습니다.  제가 해당 탭에서 가장 많은 도움을 받았던 기능은 Dependencies 입니다. 

 

 

 

특정 리소스가 어디서 호출되고 어디까지 플로우를 타는지 한 눈에 파악할 수 있습니다. Upstream 은 해당 리소스를 호출하고 있는 부모 리소스들이고 Downstream 은 해당 리소스가 호출하는 자식 리소스들입니다. 그리고 각 리소스가 API 호출인지, DB 를 거치는지, 캐쉬인지 등의 유형별 span 도 확인할 수 있습니다. 저는 이미 제공하고 있는 api 를 변경할 때 해당 메뉴를 이용했었는데요. 변경 포인트 및 영향 범위를 파악하여 부모 리소스들도 함께 수정 작업을 진행하였습니다. 

 

 

 

사실 저는 불과 몇 개월 전만 하더라도 데이터독 로그만 볼 줄 아는 눈 먼 개발자였는데요.. 제가 배포 후 모니터링을 꼼꼼히 하지 못해 장애를 크게 불린 적이 있습니다. 그 때 이후를 계기로 모니터링에 대한 중요성도 실감하게 되고, 배포시 한 두 시간의 모니터링은 꼭 하고 있는데요. 백문이 불여일견이라고 이것저것 만지다보니 알게 된 것들이 꽤 있었습니다. 비록 국어는 아니지만, 데이터독 공식 문서도 아주 자세히 나와있습니다. chatGPT 를 이용해서 번역을 도움 받아보시길 바래요. 근데 chatGPT 에다가 데이터독 기능에 대해서 물어보니까 잘 모르더라고요.. 근데 이런 정보는 얻어낼 수 있었습니다. 

 

 

믿거나 말거나 암튼, 공식 문서에 비하면 게으른 설명이 되겠지만, 아무쪼록 도움 되시길 바랍니다. 그럼 20000.. 장애에 대응하는 우리 모두 화이팅..!