이번 포스팅에선 정의한 문제를 해결하기 위해 관찰 가능성 시스템을 구축하고 적용하기 위한 과정과 어떤 효과가 있었는지에 대해 공유하고자 합니다.

서론

일전엔 러프하게 Grafana 생태계를 고려한다고 했지만, 구체적으로 무엇을 어떻게 구현할지는 아직 정하지 않았으며 어떤 인프라를 이용해 구현할지도 아직 정하지 않았습니다. 구체적인 선택의 과정과 구현 과정을 공유하고자 합니다.

또한, 이 완성된 시스템이 조직의 논의를 통해 점진적으로 적용되는 과정도 공유하고자 합니다.

관찰 가능성 시스템 구축 - Grafana 생태계

Grafana 생태계에는 대시보드인 Grafana를 기반으로 연동할 수 있는 정말 다양한 도구들이 있습니다.

따라서, 도구를 정하기 전에 어떤 문제를 어떻게 해결할 것인지 정의하는 것 부터가 중요합니다.

문제 해결을 위한 현실적인 최소한의 해결 범위 지정

해결하고자 하는 문제는 다음과 같습니다.

  • 시스템이 보이지 않아 예외사항에 대응하기 어려웠음.
  • 문제가 보이지 않아 팀내 소통에 문제가 있었음.

이를 해결하기 위한 개념은 Tracing, Logging, Metrics 등 다양하지만,

기반이 전혀 없는 상황에서 모든 것을 한 번에 구현하는 것은 현실적이지 않았습니다.

그래서 “최소한 이것만은 충족해야 한다”는 기준을 세웠습니다.

  • 시스템이 지금 어떤 상태인지 최대한 빠르게 확인할 수 있어야 한다.

우선 로그 하나면 충분하다

개발이나 디버깅 과정에서 가장 기본적이고 강력한 도구는 콘솔 출력입니다.

적절한 지점에서 로그를 출력하고 에러를 명확히 throw 하는 것만으로도 대부분의 문제를 해결할 수 있었습니다.

따라서, 현 시점에서 가장 현실적이고 효과적인 해결책은 로그를 수집하는 것이라고 판단했습니다.

해결을 위한 Grafana 도구 선정

Grafana 생태계를 구축하기 위해선 다음 3가지를 선택해야 합니다.

  • Collector: 수집기
  • Backend & Store: 백엔드 및 저장소
  • Dashboard: 대시보드

대시보드는 당연히 Grafana이며, 이제 수집기와 저장소를 선택해야 합니다.

수집기

수집기로는 Promtail과 비교적 최근 출시된 Alloy가 있습니다.

Alloy는 oTel, metric, log, trace를 가리지 않고 받아들이는 all-in-one 수집기로, Log에 특화된 Promtail보다 훨씬 강력한 수집기입니다.

또한, Alloy는 batch 기능을 제공해 갑작스러운 로그 폭주 상황에서도 안정적인 처리가 가능했습니다.

확장성과 유연성을 고려해 최종적으로 Alloy를 선택했습니다.

백엔드 및 저장소

백엔드와 저장소는 Grafana 생태계의 Grafana Loki를 사용했습니다.

ElasticSearch 기반의 Logstash, Graylog 같은 도구도 고려했지만, 가볍고 단순하게 시작하는 현재 상황에는 Loki가 더 적합했습니다.

최종 선택

  • 수집기 : Grafana Alloy,
  • 저장소 : Grafana Loki,
  • 대시보드 : Grafana

어떻게 수집할 것인가?

로그 수집에는 크게 2가지 방법이 있습니다.

  • 컨테이너에 노출된 log들을 직접 polling하여 수집
  • API를 노출시켜 API에 도달한 로그들을 수집

우선은 API에 정제된 로그를 출력하는 방법으로 로그를 모으도록 했습니다.

의식적인 로그 정제

Google Analytics처럼 필요한 정보를 특정 API로 발송하는 방식을 채택했습니다.

애플리케이션 자체가 관찰 가능성을 고려한 구조가 아니었기 때문에 기존 로그는 노이즈가 심했습니다.

따라서 별도의 API를 두고, 정제된 로그를 직접 발송해 수집하도록 했습니다.

구현과 테스트의 편의성

API를 활용하면 서버 인스턴스가 기동될 때 바로 호출해 테스트할 수 있습니다.

반면, AWS 환경에서 컨테이너 간 통신을 검증하는 것은 복잡해 초기 단계에서는 부담이 컸습니다.

따라서 API 방식이 더 빠르고 단순한 방법이었습니다.

단점과 개선 방향

API 기반 수집의 단점은 추가 코드가 필요하고, 잘못 구현하면 코드가 지저분해질 수 있다는 점입니다.

이를 해결하기 위해 함수나 어노테이션을 통한 추상화를 도입할 계획입니다.

또한, 추후 애플리케이션 로그가 충분히 정제되면 컨테이너 로그 수집 방식으로 전환할 수 있을 것입니다.

관찰 가능성 시스템 구축 – 인프라

저희 팀은 이미 AWS를 사용하고 있었기 때문에 비용 효율성과 운영 편의성을 고려해 AWS를 최대한 활용하는 방향으로 결정했습니다.

가용성과 보안을 고려한 설계

  • ALB + SSL: 외부와의 통신은 ALB(Application Load Balancer)를 통해서만 이뤄지며, SSL 인증서를 적용해 안전한 HTTPS 통신을 보장합니다.
  • 프라이빗 서브넷 배치: 애플리케이션과 로그 수집기는 모두 프라이빗 서브넷에 위치시켜 외부에서 직접 접근할 수 없도록 했습니다.
  • 멀티 AZ 구성: 가용성을 높이기 위해 리소스는 2개 AZ에 분산 배치했습니다. 장애가 발생하더라도 서비스가 지속될 수 있도록 대비한 구조입니다.

외부에는 ALB만 노출하고, 그 외의 모든 서비스는 내부망에서 안전하게 동작하도록 설계했습니다.

서비스 선택

AWS 환경에서 애플리케이션을 배포하는 방법은 EC2, Lambda, ECS 등 다양합니다. 그중에서 ECS/Fargate가 현 상황에 가장 적절하다고 판단했습니다.

  • 항상 구동되어야 하는 서비스 특성상 지속적인 가용성 보장이 필요함
  • EC2 대비 운영 부담이 적고, 사용한 만큼 과금되는 serverless 모델을 제공
  • 필요 시 Fargate에서 EC2 기반으로 전환할 수 있어 유연성 확보
  • Service Discovery, Service Connect 등 ECS만의 컨테이너 간 네트워크 편의 기능 활용 가능

AWS Lambda도 고려했으나,

  • 실행 단위가 짧은 이벤트 기반 아키텍처에 적합하고
  • Cold Start로 인한 지연 문제가 있으며
  • 단위 사용량 당 비용이 더 비싸, 요청 양이 많은 관찰 가능성 시스템의 특성 상, 비용 이슈가 있을 수 있음

서비스 간 통신 – Service Discovery vs Service Connect

ECS Fargate는 물리적 인스턴스가 고정되지 않기 때문에 매번 실행 시 IP가 달라집니다.

이를 해결하기 위해 DNS 기반의 Service Discovery를 적용했습니다. 이 방식은 같은 VPC 내에서 안정적으로 통신할 수 있고, 비용이 상대적으로 저렴합니다.

비교 대상으로는 Service Connect가 있는데, 이는 AWS PrivateLink(VPC Lattice)를 기반으로 동작합니다. 장점은 다음과 같습니다.

  • 다른 VPC에 있는 서비스와도 쉽게 통신 가능
  • 자동으로 인스턴스 간 통신 로그가 기록되어 추적성이 강화됨

하지만 저희 환경은

  • 모든 인스턴스가 동일 VPC에 있고
  • 아직 내부 트래픽 로깅까지 필요한 단계는 아니었기 때문에

Service Discovery가 더 단순하고 합리적인 선택이었습니다.

완성된 클라우드 아키텍쳐

observability

프로덕션 적용

처음 구축된 관찰 가능성 시스템은 곧바로 복잡한 프로덕트에 적용하기에는 리스크가 컸습니다.

따라서 영향이 적으면서도 이해하기 쉽고, 반드시 관찰 가능성이 필요한 서비스를 대상으로 시범 적용을 진행했습니다.

그 대상이 바로 Collabmaker입니다.

Collabmaker란?

Collabmaker는 저희와 협업을 원하는 파트너들이 편리하게 지원서를 제출할 수 있는 Application Form 서비스입니다.

파트너가 입력한 정보는 내부적으로 Shopify와 연동되어 관리됩니다.

  • 협업 파트너들은 전 세계 다양한 국가에 분포
  • 네트워크 환경, 언어, 브라우저, 기기 환경 모두 다름
  • 그만큼 예상치 못한 오류나 데이터 전송 문제가 발생할 여지가 큼

즉, Collabmaker는 외부와 직접 연결된 첫 관문이자, 안정적인 협업을 위해 반드시 관찰 가능성이 확보되어야 하는 서비스였습니다.

시스템 문제 대응 개선

Collabmaker는 Google Place API, Shopify 등 다양한 외부 서비스와 연동되어 있어 문제가 발생하면 어느 지점에서 장애가 발생했는지 파악하기 어려운 구조였습니다.

이전에는 파트너가 연락을 주기 전까지 문제를 알 수 없었고, 평균적으로 30분 이상 지연이 발생했습니다.

하지만 관찰 가능성 시스템을 도입한 이후에는 3분 이내에 로그를 통해 문제를 인식하고 대응할 수 있게 되었습니다.

아직 팀 내 메신저를 이전하는 과정이라 알람 기능까지는 적용하지 못했지만, 곧 알람을 연동하면 더욱 빠른 대응이 가능해질 것입니다.

소통 문제 해결

관찰 가능성 시스템은 내부 팀원과 파트너 간의 소통 문제도 줄여주었습니다.

  • 이전 상황

    • 파트너가 Application Form을 제출하면, 곧바로 전화로 진행 상황을 물어보는 경우가 많았습니다.
    • 하지만 Shopify에 데이터가 반영되기까지 시간이 걸리다 보니, 실제 진행 상황과 파트너가 인식하는 상황 간에 Latency(지연) 차이가 발생했습니다.
    • 그 결과, 팀원들은 수시로 시스템을 직접 확인해야 했고, 확인하는 도중 Shopify에 반영이 끝나면 “문제가 없었다”는 식으로 사건이 종결되는 경우가 잦았습니다.

  • 지금 상황

    • 관찰 가능성 시스템에서 진행 현황을 한눈에 확인할 수 있게 되면서, 팀원들에게 View 권한을 부여해 실시간 상태를 공유했습니다.
    • 이제는 파트너와 팀원 간의 인식 차이가 사라졌고, 불필요한 확인 작업 없이도 투명한 소통이 가능해졌습니다.

정리

Collabmaker를 시작으로 관찰 가능성 시스템은 실제 프로덕션 환경에서 의미 있는 효과를 보여주었습니다.

앞으로는 이 시스템을 다른 프로덕트로 확장 적용하며, 추가적인 효과와 개선점을 검증해 나갈 계획입니다.