[AWS] ALB - 분산 환경에서의 로그 분석과 스티키 세션

AWS 서비스로 이것저것 해보다, ALB 환경에서 요청 1건 마다 EC2들을 번갈아 요청하는 것을 보며 이것도 나중에 에러나면 로그 찾기 힘들겠다는 생각이 들었다.

 

일반 Linux 환경 프로젝트에서는 L4를 앞에 두고 로드밸런싱을 했는데, 로그 집중화 서버까진 구축하지 않아서 그냥 Sticky Session 방식으로 처리했었다.

 

* Sticky Session : 사용자가 붙은 서버에서만 요청이 처리되도록 함. 사용자 액션에 따른 로그 분석 수월함. 단, 서버 간 부하 관리가 힘들 수 있음.

 

## AWS ALB 환경에서 사용자별 로그 추적 및 에러 디버깅 효율화를 위한 기술 대안 정리 ## 

(ALB도 sticky sesion 설정이 있지만 권장하지 않음)

1. 분산 추적 시스템 (AWS X-Ray)

• 요청 전 과정 시각화: ALB부터 백엔드, DB까지 이어지는 호출 경로를 트레이스(Trace) 단위로 파악함.
• 병목 지점 식별: 서비스 맵을 통해 에러가 발생한 구체적인 지점과 지연 시간을 직관적으로 확인 가능함.

2. 로그 중앙화 및 쿼리 분석 (CloudWatch Logs Insights)

• 실시간 필터링: S3에 저장되는 단순 텍스트 로그 대신, CloudWatch Logs Insights를 활용해 특정 사용자 IP나 상태 코드(5XX) 기반의 즉각적인 쿼리 분석을 수행함.
• 대시보드 구성: 주요 에러 지표를 시각화하여 상시 모니터링 체계를 구축함.

3. 구조화된 로깅 (Structured Logging) 도입

• X-Amzn-Trace-Id 연동: ALB가 부여하는 고유 헤더(X-Amzn-Trace-Id)를 애플리케이션 로그에 포함하여 인프라 로그와 앱 로그 간의 연관 관계를 확보함.
• JSON 포맷 채택: 로그 형식을 JSON으로 규격화하여 검색 엔진(ELK, CloudWatch)에서의 파싱 및 분석 속도를 극대화함.

4. 에러 모니터링 전용 도구 (Sentry 등)

• 상세 문맥(Context) 확보: 에러 발생 시점의 사용자 환경(OS, 브라우저), 입력값, 스택 트레이스를 즉시 리포팅함.
• 자동 알림 체계: 이슈 발생 시 슬랙(Slack) 등과 연동하여 실시간 대응력을 높임.