인프콘 2024

성실함

협업 지향

학습 지향

커뮤니케이션

문제 해결사

장재호

<h4>프로젝트 배경</h4><ol><li><p>로그 관리 부재로 인한 로그 추적의 어려움</p><ol><li><p>로그 추적을 위해 인스턴스에 접근<br></p></li></ol></li><li><p>초기 알림 체계의 한계</p><ol><li><p>모든 에러에 대한 알림 처리로 인해 알림의 신뢰도 저하</p></li></ol></li></ol><p>위의 두 가지 문제로 개발자가 사전에 장애를 감지하지 못하고 장애 대응 시간이 무기한 길어지는 문제를 해결하고자 두 번의 변경 과정을 통해 모니터링 인프라를 성공적으로 구축했습니다.</p><p></p><p></p><h4>Promtail, Loki, Grafana를 통한 로그 모니터링 시스템 구축</h4><p>운영 비용과 빠른 도입을 최우선적으로 생각하여 기술을 선택했습니다. 로그 수집 시 리소스가 비교적 적게 드는 Loki를 주축으로 무료 오픈소스인 Promtail, Grafana를 도커 컨테이너를 통해 빠르게 배포할 수 있었습니다.</p><p></p><p></p><h4>Promtail의 제거로 디스크 용량 확보 및 서비스별 라벨링 유연성 보장</h4><p>Promtail 제거 후 애플리케이션에서 직접 Loki로 로그를 전송하도록 변경하여 I/O 리소스를 제거하고 디스크 용량을 확보했습니다. 서비스별 라벨링 정책도 유연하게 보장하여 세분화된 로그 관리가 가능해졌습니다. 네트워크 부하 증가라는 트레이드오프를 최소화하기 위해 에러 로그는 실시간 전송하고, 일반 로그는 배치 전송 및 재전송 큐를 도입해 부하를 분산했습니다.</p><p></p><p></p><h4>Prometheus의 도입</h4><p>로그 중심의 모니터링을 확장하여 시스템 전반의 상태(CPU, 메모리, API 응답 시간 등)를 실시간으로 파악하고, 장애 발생 전 징후를 사전에 감지하기 위해 Prometheus를 도입하였습니다. 이를 통해 단순 로그로 서버 애플리케이션 동작만 확인하던 기존 방식을 개선하여, 시스템 전반의 메트릭을 통합적으로 분석하고 문제를 정확히 캐치하여 장애의 재발을 방지할 수 있는 체계를 구축했습니다. 또한, 활성 커넥션 수 및 슬로우 쿼리 등 데이터베이스까지 포함한 모니터링으로 서비스 안정성과 운영 효율성을 크게 향상시켰습니다.</p><p></p><p></p><h4><strong><span>주요 개선 사례 및 성과</span></strong></h4><ol><li><p>푸시 알림 장애 사전 감지 및 해결</p><ul><li><p>기존에는 감지하지 못했던 푸시 알림 발송 중 발생하는 간헐적 서비스 장애를 감지하여 데이터베이스 커넥션 풀 초과의 원인임을 확인하였습니다.</p></li><li><p>푸시 알림의 동시 발송 수를 줄여 부하를 분산하고, 데이터베이스 커넥션 사용량을 30% 감소시켜 동일 장애가 재발하지 않도록 서비스 안정성을 확보했습니다.</p><p></p></li></ul></li><li><p>장애 감지 및 대응 속도 개선</p><ul><li><p>고객 문의에 의존하전 장애 감지 상황을 개선하여 개발자의 사전 장애 감지율이 80%이상 증가하였습니다.</p></li><li><p>장애 원인 분석 시간을 5배 이상 대폭 단축하여 신속한 대응이 가능해졌습니다.</p></li><li><p>알림 발생율은 90%이상 축소되었지만 중요도 기반 알림 체계로 개발자가 중요한 장애에만 집중이 가능해졌습니다.</p></li></ul></li></ol>

<h3>프로젝트 배경</h3><p>MyISAM의 테이블 단위 락 매커니즘의 동시성 이슈로 인한 병목 현상이 발생하여 메세지가 유실되는 문제가 있었습니다. 더불어 채팅 입력 시 실시간 문자 메세지 발송, 백 오피스 연동 등의 작업 지연으로 메세지 수신까지 최대 2~3초가 걸리는 성능 이슈가 발생했습니다.</p><p></p><h3>캐싱 및 메세지 큐 활용</h3><p>채팅 메세지를 수신하면 즉시 캐싱하고, 메세지 큐를 활용하여 메세지 송수신과 DB 입력을 분리하여 메세지 수신 시간을 약 10배 단축시켰습니다. DB 입력 실패 시에도 송수신이 정상적으로 처리되도록 실패 큐에 저장하여 일정 주기마다 재시도를 통해 채팅과 관련된 부가적인 기능이 올바르게 동작하도록 보장하였습니다. 하루 2회 2~6만 건의 CRM 채팅 발송 시에도 안정성을 보장하기 위해 벌크 인서트와 동시 작업 개수를 최적화하였습니다.</p><p></p><h3>결과</h3><ol><li><p>채팅 메세지 송수신 시 기존 2~3초에서 0.2초 이내로 10배 이상 성능 개선</p></li><li><p>메세지 소실 문제를 메세지 큐와 실패 큐를 통해 송수신이 보장되도록 처리</p></li><li><p>CRM 문자 메세지 등의 2~6만건의 메세지 전송에도 안정적인 처리</p></li></ol>