[회고] SaaS 플랫폼 운영 (1) - Observability
처음 입사했을 당시, 같은 본부의 개발팀에서는 하나의 서비스를 막바지 단계에서 개발하고 있었습니다. 이미 완성에 가까운 상태였기 때문에 개발팀 개발자분들은 서비스 출시를 앞두고 막바지 작업과 안정화를 위해 야근 작업을 이어가고 있엇고, 제 사수님 역시 배포와 각종 트러블슈팅을 담당하시며 바쁘게 업무를 수행하고 계셨습니다.
저는 입사 직후였기 때문에 해당 서비스의 초기 설계나 구축 과정에 직접 참여하지는 못했지만, 사수님께 업무를 배우는 과정에서 자연스럽게 플랫폼의 구조와 운영 방식에 대해 접할 수 있었습니다. 당시 팀 내 인프라 담당 인원은 사수님과 저, 단 두 명뿐이었기 때문에 사수님께서 부재 중이거나 다른 업무로 바쁘신 경우에는 장애 상황을 직접 확인하고, 해결 가능한 문제들은 스스로 원인을 분석하고 조치해야 했습니다.
입사 약 두 달 후, 해당 서비스는 정식으로 출시되었고, 이후 운영 단계에 접어들면서 저 역시 점차 플랫폼 운영 업무를 본격적으로 담당하게 되었습니다. 이를 계기로 단순한 보조 역할을 넘어, 서비스의 안정적인 운영을 위한 모니터링, 장애 대응, 그리고 운영 환경에 대한 이해를 지속적으로 넓혀갈 수 있었습니다.
그렇게 출시된 서비스가 다음과 같습니다.
플랫폼 운영 적응기 ① - Observability
운영 환경
플랫폼은 Naver Cloud Platform의 NKS를 사용중이었고, Kubernetes 위에서 다양한 애플리케이션이 동작하고 있었습니다. 그리고 모니터링과 Observability를 위해 클러스터 내부에 Loki, Prometheus, Grafana, Jaeger, 그리고 Opentelemetry 도입 이전까지는 여러 exporter들이 함께 구성되어 있었습니다. 그러나 각 구성요소들이 어떤 역할을 하는지, 장애가 발생했을 때 어디서부터 확인해야 하는지조차 명확히 알지 못해 막막함을 느꼈습니다.
장애 발생 시 원인 파악의 어려움
가장 어려웠던 점은 장애 발생 시 원인을 빠르게 특정하는 것이었습니다. 서비스 장애가 발생하면 로그, 메트릭, 트레이스 등 다양한 정보가 존재했지만, 어떤 정보를 우선적으로 확인해야 하는지 판단하기 어려웠습니다.
초기에는 단순히 Pod 상태나 로그만 확인하는 수준에 머물렀고, 문제가 인프라 문제인지, 애플리케이션 문제인지, 또는 리소스 문제인지 구분하는 데에도 많은 시간이 소요되었습니다. 특히 Kubernetes는 여러 컴포넌트가 유기적으로 연결되어 있기 때문에 단일 요소만 확인해서는 전체 상황을 이해하기 어려웠습니다.
이로 인해 장애 대응 과정에서 확신을 가지지 못하고 문제 해결까지 오랜 시간이 걸리는 경우도 있었습니다.
문제 해결을 위한 학습
장애 대응의 한계를 극복하기 위해 Kubernetes의 동작 원리와 Observability 도구들에 대해 체계적으로 학습하기 시작했습니다. 먼저 쿠버네티스의 기본 구조와 주요 리소스의 역할을 다시 정리했습니다. 그리고 장애 발생 시 다음과 같은 순서로 확인할 수 있도록 습관을 들였습니다.
1. Pod 상태 확인
2. 컨테이너 로그 확인
3. Node 상태 및 리소스 사용량 확인
4. Grafana를 통한 메트릭 확인 (CPU, Memory, Network 등)
5. Loki를 통한 로그 분석
6. Jaeger를 통한 서비스 호출 흐름 추적이런 과정을 반복하면서, 장애 원인을 단계적으로 좁혀나가는 방법을 익히게 되었습니다.
마무리
플랫폼 운영을 경험하면서 Observability의 중요성을 직접 체감할 수 있었습니다. 처음에는 단순히 모니터링 도구라고만 생각했지만, 실제로는 확인하는 데 유용했고, 메트릭은 시스템의 전반적인 상태 변화를 파악하는 데 도움이 되었으며, 트레이스는 서비스 간 호출 관계와 지연 구간을 파악하는 데 중요한 역할을 했습니다.
초기와는 달리 OpenTelemetry 도입 이후에는 데이터를 보다 일관된 방식으로 수집할 수 있게 되면서, 장애 분석 과정이 더욱 효율적으로 개선되었습니다.