1월 1주 있었던 일 정리

Introduction

• 분산 환경 추적 시스템 구축하기
  • 요약
  • 요구사항
  • 다음은,,,
  • 중요하게 생각한 일들
  • 적용하기 위한 트러블 슈팅
    • 첫 번째 문제 - 추적이 불가능해요
    • 두 번째 문제 - 어라 왜 service map 이 정상적으로 동작하지 않지
  • 개발이란

분산 환경 추적 시스템 구축하기

요약

12m4w에서 이야기 했던 문제에 가설을 세우고 해결을 진행했다. 요약하자면 서비스와 함께 성장하는 모니터링 시스템이 필요해.다. 필요한 건 다음과 같다.

• 시스템 문제는 비용 파악이 어려운 상황, 문제 추적이 어려운 상황, 지연이 발생하는 시점을 파악하기 어려운 상황 이 존재한다.
• 서비스 로그는 사용자들의 동향을 파악할 수 있고 재진입성을 높일 수 있는 방법으로 보인다.

상황에 맞게 서비스와 함께 성장할 로그 관리 방법이 필요했다.

요구사항

기획 단계에서 얻고자 하는 지표가 자주 변경되는 이슈가 있었음. 로그 변경마다 서버 재시작하는 건 꽤나 까다로운 조건이다. 그래서 logstash 를 활용해 필터링 쉽게 수정할 수 있도록 구성했다.

여러 프로젝트를 자세히 찾아보니 이전 개발자 분이 logback-logstash 연동이 쉬운 라이브러리를 이미 적용했다. 그래서 logback에서 logstash 라이브러리 활용할 수 있도록 테스트 환경 구성중이다.

가장 중요한건 이해관계자들의 적극성을 유도하는 일이다. 쿼리를 날리는건 이해 관계자들에게 비싼 작업이었고, 그로 인해 데이터 기반 의사 결정의 진보가 더딜 수 있다 판단한다. 그래서 kibana 에서 통계 대시보드로 쉽게 시각화 할 수 있도록 구성한다.

분산 환경에서 추적하기 쉬운 툴로 elasticsearch apm 사용해보려 한다. zipkin을 사용하면 데이터 베이스 관리가 여간 힘든게 아니다. 차라리 zipkin이 db와 붙어 있었다면 사용했겠지만, db와의 트러블 슈팅을 고려하긴 걱정이 많았다. 그래서 db, apm을 같이 제공하는 elastic을 활용하기로 했다.

다음은,,,

성장하다보면 적은 사용자를 기준으로 설계한 시스템에 무리가 갈 수 있을거라고 판단해 적정 수준까지 개선해야 할 사항과 방법을 정리하기로 했다.

• fleet과 여러 서버에서 실행되는 apm 구축
• elasticsearch 클러스터 구축
• beats 구성

중요하게 생각한 일들

중요하게 생각한 건 다음과 같다. 조금 더 자세하게 쓰고 싶었는데, 이번 주는 apm 덕분에 많은 시간을 할애해서 시간이 얼마 남지 않았다.

• 이해 관계자와 협업하기 : 이해 관계자들의 퍼포먼스를 높이기 위해 데이터 접근에 어려운 과정 개선
• 오버 엔지니어링 피하기 : 초기 비용을 줄이고 점진적인 개선이 가능하도록 비용이 들지 않는 곳만 개선 및 개선 과정 문서화
• 현재 업무에 집중하기 : 시스템 모니터링은 현재 업무가 아님. 맡은 업무를 다하고 개선 할 것.
• elasticsearch에 집중하기 : elasticsearch 기능이 엄청 많음. 최대한 이해하고 사용해보기.

적용하기 위한 트러블 슈팅

업무에 적용하기 전에 분산 환경에 바로 녹여 낼 수 있도록 유사하지만 심플한 환경 구성 후 테스트 진행했다.

첫 번째 문제 - 추적이 불가능해요

trace id, span id, transaction id가 모두 할당되지만 추적이 안된다. 확인해보니 연결된 작업에도 trace id 가 달라서 시도가 불가능 했다. elastic apm은 traceparent 헤더를 사용해서 추적하고 있었다. 그래서 traceparent를 추적해봤다.

traceparent 는 version, trace id, parent id, trace-flags 가 포함된 정보다. 자세한 정보는 해당 링크에서 확인 가능하다.

확인해보니 traceparent정보에서 trace id는 동일하지만 서버 내부에서 변형되어서 발생하는 문제였다.

zipkin 사용을 위해 brave 라이브러리를 사용했는데, 동일한 컨텍스트에서 저장되어 덮어써지는 것이 원인으로 보였다. 즉, traceId, spanId 같은 프로퍼티를 사용하기 때문에 충돌이 발생했다. 제거 했더니 traceparent 정보와 일치하는 trace id, span id를 부여받았다.

이 문제의 원인을 쉽게 파악 할 수 없었는데, 해당 문서에서 헤더가 다르니 충돌이 발생하지 않을거야!라는 문장으로 충돌은 없어! 로 오해해서 그랬다. 전파되기 위해 서버에 저장되는 순간 충돌이 발생할 거란 상상하지도 못했다.

분산 추적, OpenTracing 및 Elastic APM

두 번째 문제 - 어라 왜 service map 이 정상적으로 동작하지 않지

본인이 elastic apm을 선택했던 이유 중 하나가 트래픽을 쉽게 시각화 할 수 있는 장점 덕분이었다.

그런데 정상적으로 동작하지 않음. 서비스 맵에서 게이트웨이가 추가되질 않는 거다.

원인을 파악해보니 서비스와 게이트웨이의 부모만 같지 그외의 연관성은 없어 보인다. parent가 같은 경우는 동일한 컨텍스트에서 실행됨을 보여주기 위해서라고 생각한다. 만약 게이트웨이와 서비스가 동일한 컨텍스트라고 생각하면 유지해도 되고 그렇지 않다면 분리가 필요해보인다.

elastic은 trace 컨텍스트에서 parent와 span으로 의존성을 유추하는 모습을 볼 수 있었다.

그래서 transaction 과 trace, parent의 컨텍스트가 어떻게 공유되는지 파악해봤다.

내 생각에는 동일한 traceparent가 변경되지 않고 전파되어서 발생하는 문제처럼 보인다. 즉, 게이트웨이에서는 traceparent 변경이 발생하지 않는다.

뭐 이런 링크도 확인해봤는데, 큰 진전은 없다. 코드 상으로 직접 새로운 span을 생성한 다음 전파하는 게 맞다고 생각한다.

새로운 span을 생성하면 변경된 parent로 traceparent로 변경해주겠지? 하는게 나의 희망사항이다. 이것저것한다고 시간이 너무 지체됐고, 이후 작업이 불가능해 다음주에 진행하기로 한다.

개발이란

이런 저런 문제들을 해결하면서 개발하려는 목표는 무엇일까 곰곰히 생각하게 된다. 개발 목표를 간단하게 두 가지로 분류했는데 재사용성을 높이거나, 세운 가설을 증명하거나 둘 중 하나로 보인다. 결국 관리냐 새로 만드냐 차이 같다.

결국 현재 상황에서 더 나은 방향을 선택하는 일이라 생각함. 아래와 같은 패턴으로 계속 수행하지 않을까.

가설을 세운다. -> 가설을 증면한다. -> 사용자 행동을 유도한다. or 불편함을 개선한다. -> 가설을 세운다....

위 문제를 해결하면서 이런 프로세스로 전반적인 흐름이 이어지지 않나 생각 드는 한 주였다.