12월 4주 있었던 일 정리

오버 엔지니어링은 피하며 확장성 염두하기

내가 괜히 회사 운영 비용을 늘리는게 아닌지 조심하고 있어. 그러다 보니 Best practice 까지의 아키텍처를 구성하는 건 오버 엔지니어링이다 보니 어떤 걸 포기해야 할지 고민하게 되더라.

현재 상황

내가 해야 할 일 중 일부를 가져왔어.

서비스 로그 추가 업무 요청
서비스 로그 추적이 어려운 상황
서비스 로그 및 시스템 로그 개선 필요성 느낌

현재까지 적용된 서비스 로그 적재 방식은 (1)배치로 주기적으로 데이터를 정제하는 기능과 (2)아테나로 실시간으로 지표를 확인 하는 기능이 있어. 의사 결정 기간이 빠른 조직은 아니어서 아테나로 실시간 지표 확인 방법은 없애거나 개선이 필요해보였고, 실시간 지표 확인 기능을 유지하기 위해 발생하는 부가적인 비용도 아쉬웠어.

그래서 (1) 배치 시스템을 차용하고 있다가 의사 결정 주기가 빨라지면 (2) 실시간 조회할 수 있는 방법으로 변경하는 게 옳은 선택처럼 보였어. 즉, 분산 환경에서 로그 개선 작업에 채택됐던 elasticsearch를 함께 활용하면 이후 의사 결정 주기가 빨라지는 일에 즉각적으로 반응 할 수 있어.

분산 환경에서 추적 가능한 slueth(현재는 actuator)를 활용하고 zipkin과 elasticsearch, kibana로 적절하게 모니터링 해보려 해.

해야 할 일을 정리하면

분산 환경에서 요청 흐름을 추적할 수 있는 툴이 필요했어.

키바나를 활용하면 빠르게 검색 할 수 있지.

분산 환경 추적 시스템 아키텍처를 간단하게 고려해보면 다음과 같아. 가용성과 확장성을 고려하면 그에 맞게 시스템을 변화하면 될 듯 해.

있었던 이슈 1 - zipkin oom

토이 프로젝트로 진행해보고 있는데, oom이 발생했어. 기존 memory 저장소를 사용 할 때는 쌓이는 데이터가 적어 조회할 때 많은 메모리가 필요하지 않았지만, elasticsearch로 변경하게 되면서 데이터 조회에 많은 메모리가 필요하게 된게 원인으로 보였어.

elasticsearch로 저장소를 변경한 이후부터 발생하게 됐는데, 로그를 찍어보기로 했어.

zipkin:
    ...
    command: --logging.level.zipkin2=DEBUG

이것저것 시도해보다 성공해서 다시 실패했던 옵션을 확인하려는데 재연이 안되네,,, 잘 모르는 걸 여러개 사용하려니 원인 파악이 너무 어렵다~

그래도 문제로 보이는 건 zipkin 화면에서 데이터를 조회할 때 문제처럼 보였어. 로딩 시간이 엄청 오래걸리기도 했지. 데이터를 10,000 개 요청하는 경우 10초 가량이 걸리기도 했어.

있었던 이슈 2 - system vm max map count is too low

시스템 가상 메모리 공간이 부족할 수 있으니 늘릴 필요가 있다고 함. vm.max_map_count는 어떤 값을 의미할까?

ERROR: [1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.
bootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
ERROR: Elasticsearch did not exit normally - check the logs at /elasticsearch/logs/docker-cluster.log

이 문제는 할당 가능한 맵의 수를 늘리면 돼.

sysctl -w vm.max_map_count=262144

그런데 맵이 어떤 의미인지 궁금해서 찾아봤어. kernel.org 에 따르면 다음과 같이 설명하고 있어.

max_map_count:

This file contains the maximum number of memory map areas a process
may have. Memory map areas are used as a side-effect of calling
malloc, directly by mmap, mprotect, and madvise, and also when loading
shared libraries.

While most applications need less than a thousand maps, certain
programs, particularly malloc debuggers, may consume lots of them,
e.g., up to one or two maps per allocation.

The default value is 65536.

이 파일에는 프로세스가 가질 수 있는 최대 메모리 맵 영역 수가 포함되는데, 메모리 맵이 어떤 의미인지 파악할 필요가 있었지. 위키에 따르면 메모리 맵은 메모리가 배치되는 방식을 나타내는 데이터 단위라고 설명하며 상황에 맞게 의미가 변화한다고 해. 그 중 이 말이 제일 맞아보여.

In virtual memory implementations and memory management units,
a memory map refers to page tables or hardware registers,
which store the mapping between a certain process's virtual
memory layout and how that space relates to physical memory addresses.

메모리 맵은 특정 프로세스의 가상 메모리 레이아웃 간의 매핑된 페이지 테이블 또는 하드웨어 레지스터를 나타낸다고 해. 즉 할당 가능한 메모리 수를 늘려야 한다는 의미야. elasticsearch는 메모리 할당이 많이 필요한 시스템이라는 것을 알게 됐어.

마지막으로

서비스 로그 추가 업무 요청을 처음 받았을 때는 elasticsearch를 적용해서 화려하게 해결해봐야지 하고 접근했어. 그런데 학습하면서 이게 맞나?라는 생각이 들어서 하던 일을 잠시 멈추고 곰곰이 생각해봤지.

어려운 작업이 아닌데, 너무 많은 리소스를 들이는게 아닌가?, 계속해서 증가하는 관리 비용이 감당이 안될텐데? 라는 생각들이 머릿속을 지배했고 유사한 기능들을 찾는게 옳은 선택 같았어. 결국 elasticsearch를 적용하지 않기로 결정했어.

작업을 기획하는데, 분산 환경에서 시스템 로그를 파악하기가 너무 어려워 진행하기 어렵다는 느낌을 받게 됐어. 분산 환경 추적 시스템이 필요했고, zipkin 사용해야 함을 느꼈지. 그 과정에서 elasticsearch를 사용하는 게 적절해보였어.

그래서 기존에 있던 기능을 차용하고 이후 확장성을 고려하는 게 어떨까라는 생각을 하게 됐고, 위와 같은 토이 프로젝트를 진행하게 됐지. 다음주는 poc 과정에 적용한 분산 환경 추적 시스템을 선보이고 팀 내에 적용이 필요함을 공유해야겠어.