Fall in IT.

전통적인 모놀리식(Monolithic) 아키텍처에서 마이크로소프트 아키텍처(MSA)로의 전환은 이제 거스를 수 없는 흐름이 되었다. MSA는 서비스의 독립적인 개발과 배포를 가능하게 하여 조직의 생산성을 극대화하는 강력한 장점을 가지고 있다. 하지만 서비스가 잘게 쪼개지고, 하나의 요청이 여러 서비스 간의 복잡한 네트워크 호출로 이어지면서 새로운 문제가 발생했다. 바로 시스템의 동작을 이해하고 추적하기가 극도로 어려워졌다는 점이다.과거 모놀리식 환경에서는 CPU, Memory 사용률과 같은 시스템 매트릭과 로그 파일만 잘 확인해도 장애의 원인을 비교적 쉽게 파악할 수 있었다. 그러나 MSA 환경에서는 문제가 발생했을 때, 수많은 서비스 중 어느 곳에서 문제가 시작되었고, 그 여파가 어디까지 미쳤는지 파악..

현재 필자의 시스템은 MSA로 구성되어있다. 그리고 각 마이크로서비스의 로그 기록은 Elasticsearch에 기록되고 있는데 그 방식이 조금 특이(?)하다.전통적인 EFK 시스템을 통해서 기록되는 것이 아니라 로그라이브러리를 통해 기록되고 있기 때문이다. 왜 로그라이브러리를 통해서 로그 데이터를 기록하게 됐는지, 각각의 장단점은 무엇인지 간략하게 설명하고자한다. 로깅 라이브러리를 통해서 Elasticsearch로 전송하는 방식장점구조 단순성Fluentd, Logstash와 같은 추가적인 로그 수집 레이어를 생략할 수 있다.애플리케이션과 Elasticsearch 사이의 연동만 설정하면 되므로 관리할 구성요소가 줄어든다.로그 장애 포인트는 Elasticsearch 하나로 줄어듬.유연성데이터 포맷을 애플리케..

로그 라이브러리 개선현재 나의 프로젝트에서 다양한 서버에서 로그를 기록하기 위해 로그 라이브러리를 사용하여 엘라스틱서치에 직접 데이터를 전송하고 있다.이 과정에서 동기적으로 동작하는 훅(Hook)을 통해 Elasticsearch에 로그를 기록하고 있었는데, 이로 인해 문제가 발생했다. Elasticsearch에 장애가 발생하거나 응답이 지연되는 상황에서, 로그 전송 작업이 API의 주요 처리 흐름을 가로막는 문제가 나타난 것이다.  결과적으로, 로그 라이브러리를 사용하는 모든 API에서 문제가 발생했고, 로그 전송이 API 응답 시간 초과를 유발하면서 시스템 전반에 장애가 발생했다.문제 요약로그 전송이 동기적으로 처리됨.엘라스틱서치 장애 시 로그 훅이 블로킹되어 API의 정상적인 동작을 방해.모든 API..

최근 연차를 보내던 중 QA 팀으로부터 서비스의 로그인 오류 문의를 받았다.문제의 원인을 조사하고 해결한 과정을 기록한다. 문제 상황QA 팀에서는 서비스 로그인이 되지 않는다고 보고했다.로그를 확인해 보니 API 타임아웃이 발생하고 있었다.원인 분석로그 기록 방식API 에러가 발생한 서비스는 로그를 로그 라이브러리를 통해 Elasticsearch에 기록하고 있었는데 동기적으로 기록하고 있었다.이 방식은 Elasticsearch에 문제가 생기면 API 요청이 지연되거나 실패할 수 있는 구조적 문제를 내포하고 있었다.Elasticsearch 상태 점검Elasticsearch는 실행 중이었으나 에러 로그가 기록되고 있었다.스토리지 상태를 확인한 결과, /usr/share/elasticsearch/data 디렉..