Fall in IT.

현재 필자의 시스템은 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 디렉..

프론트엔드에서 발생한 HTTP 413 상태 코드 이슈 해결하기회사에서 일을 하던 중, 프론트엔드 개발자로부터 데이터를 생성하는 API를 호출할 때 HTTP 상태 코드 413 에러가 응답으로 반환된다는 이야기를 들었습니다. 이 상태 코드는 클라이언트가 서버에 보낸 요청의 body 크기가 서버가 허용하는 최대 크기를 초과했을 때 나타나는 HTTP 413 Payload Too Large 에러입니다.개발자로부터 받은 요청을 확인해 보니, 설정된 body size 제한보다 적은 크기의 요청이었고 서버 로그에도 해당 요청이 남아있지 않았습니다. 로컬 환경에서 같은 입력으로 테스트했을 때는 정상적으로 동작하는 것이 확인되었습니다. 그렇다면 문제는 서버가 아니라 클라이언트와 서버 사이의 다른 요소일 가능성이 있었습니다..

이 문서는 필자의 프로젝트에서 사용 중인 배포 파이프라인에 대해 설명합니다.배포 파이프라인은 Kubernetes, ArgoCD, AWS ECR 등의 클라우드 및 컨테이너 기술을 활용하여 애플리케이션을 효율적으로 배포하고 관리하기 위해 구성되었습니다.사전 지식ArgoCD란?ArgoCD는 Kubernetes 애플리케이션을 GitOps 방식으로 배포하고 관리하는 도구입니다. 애플리케이션의 선언적 설정 파일을 Git 리포지토리(혹은 OCI 레지스트리)에서 가져와서 Kubernetes 클러스터에 동기화하며, Git 상태와 클러스터 상태 간의 차이를 모니터링하여 자동화된 배포를 수행합니다.GitOps란?GitOps는 애플리케이션 배포 및 인프라 관리를 Git을 중심으로 수행하는 방법론입니다. 즉, 애플리케이션의 선..