Monitoring

 

운영하는 서비스가 장애가 발생한 적이 있습니다.

이를 뒤늦게 알았고 어떠한 알림도 개발자에게 전달되지 않았습니다.

 

원인은 서버의 동작문제가 아닌 로드밸런서의 인증서가 만료되어 발생한 문제였고,

이는 다른 회사의 서버 개발자의 실수로 발생했지만 이에 대해 너무 늦은 대처로 서비스가 장시간 장애 상태로 유지되었다는 것과 장애를 제가 인지하지 못했다는 것을 자책하게 되었습니다.

 

환경 탓을 하지 않고 내 잘못이라고 생각하니 이를 어떻게 해결해야할지 고민이 되었고 이를 해결하기 위한 여러 가지 해결 방법을 찾기 시작했습니다.

 

그래서 찾은 답은 모니터링을 도입해보는 것이었습니다.

 

저는 모니터링을 도입해 본 적은 없습니다.

모니터링이 어떠한 수치를 제공해 주는지도 모릅니다.

모니터링이 주는 이점에 대해 모릅니다.

어떠한 모니터링 툴이 있는지 모릅니다.

어떻게 적용하는지도 모릅니다.

그럼 알면 됩니다.

검토 사항은 다음과 같습니다.

 

리소스 사용량을 확인해야 합니다.

 

모니터링을 직접 구현하지는 않고 상용 오픈 소스를 도입할 것입니다. 혹은 현재 타회사에서 사용하고 있는 방식을 살펴봅니다.

리소스라는 것은 시간과 금전적인 부분, 인력, 서버의 스펙 등등이 포함됩니다. 이러한 리소스 사용량보다 모니터링을 도입했을 때 얻는 이점이 더 커야 합니다.

 

모니터링으로 얻을 수 있는 이점이 리소스 사용하는 것보다 커야 합니다.

 

말했듯이 어떠한 기술을 도입할 때 트레이드오프를 적절한 게 판단해야 한다고 생각합니다.

그렇다면 모니터링으로 어떠한 이점이 있는지 정리가 필요합니다.

 

 

어떠한 모니터링 도구들이 있고 현재 상황에 가장 적합한 도구인지 판별해야 합니다.

 

모니터링이라는 keyword로 검색 시 다양한 기술들의 조합이 추천됩니다.

타 회사에서는 다양한 방식으로 애플리케이션을 모니터링하고 있습니다.

이러한 여러 가지 기술을 확인한 이후 현재 우리에게 적합한 모니터링 툴을 찾아야 합니다.

 

 

모니터링 도구를 정했다면 이를 적용하는 방법을 알아야 합니다.

 

적용할 때 발생할 수 있는 이슈와 현재 필요한 수치를 제공하는 모니터링 툴을 파악했다면 가장 적합한 모니터링 툴을 애플리케이션에 적용할 수 있는 방법을 알아야 합니다.

 

저는 다음의 방법으로 자료를 찾으려고 합니다.

1. 타 회사의 기술블로그를 참고할 것입니다.타 회사의 기술블로그는 저의 사수가 될 수 있습니다. 좋은 글은 도입 이유와 장점, 단점, 방법까지 나와있을 것이기 때문에 기술블로그를 찾아봅니다.

1. 모니터링 도구가 정해졌다면 그를 도입하기 위한 강의나 책이 존재할 것입니다. 이를 빠르게 필요한 부분만 읽거나 수강하여 지식을 쌓습니다.
2. 가장 중요한건 공식문서를 보는 것입니다. 모니터링 툴에 대한 공식문서를 보면서 최종적으로 자료를 정리합니다.

 

 

우선 모니터링 툴을 필터링하기 위해 현재 서비스를 조금 확인하고 내가 원하는 요구사항을 정리해야 합니다.

스프링 부트를 사용하고 있습니다.

 

스프링에서 제공해 주는 모니터링 도구가 있다면 통합적인 부분에서 상당히 많은 이점을 얻을 수 있을 것 같고 자료도 많을 것이고 예상됩니다.

 

AWS EC2 인스턴스로 서비스를 제공하며 서버는 한 개입니다. 앞단에 L7 로드 밸런서가 위치하고 있고 로드밸런서 서비스 IP로 사용자 요청을 받습니다. 

 

만약 모니터링 툴을 도입한다면 현재 다음과 같은 요구사항이 만족되면 좋을 것 같습니다.

 

메모리 사용량을 확인할 수 있으면 좋겠습니다. 실제 서버에 할당된 메모리가 적기 때문에 대용량 트래픽 유입 시 장애가 발생할 수 있고 이는 scale up 혹은 scale out이 필요한 시점이라고 판단할 수 있는 근거가 될 수 있습니다.

 

하드디스크 용량을 일단위로 확인하고 싶습니다. 인스턴스 하드디스크의 기본 용량은 30GB로 매우 적은 편입니다. 애플리케이션이 남기는 로그는 쌓이다 보면 30GB는 금방 가득 차버립니다.

 

로드 밸런스의 장애를 탐지하는 방법도 필요합니다.

로드 밸런스의 서비스 IP를 확인하는 부가적인 기능도 있었으면 좋겠습니다.

그런데 서비스 IP가 변경될 수도 있으니까 도메인으로 확인할 수 있어야 합니다.

 

모니터링이 주는 이점과 단점

 

모니터링이라는 것은 애플리케이션의 동작 상태를 실시간으로 모니터링하고 분석하는 것입니다.

 

이점은 사실 명확합니다.

 

장애 대응 속도가 향상됩니다.

실시간으로 모니터링하기 때문에 장애게 발생했을 때 즉시 대응할 수 있습니다. 이는 장애 대응 속도를 높여 업무의 지연을 최소화하고 사용자가 느끼는 서비스 품질을 향상합니다.

 

성능 최적화

모니터링은 애플리케이션의 성능을 측정하고 분석할 수 있습니다. 이는 TPS나 처리량까지도 모니터링하여 성능 개선 지표로 사용될 수 있습니다.

 

장애 원인 분석

애플리케이션 모니터링은 애플리케이션의 동작 상태를 모니터링하므로 장애 발생 시 해당 원인을 분석할 수 있습니다. 이를 통해 장애가 발생한 원인을 파악하고 다시 발생하지 않도록 예방할 수 있습니다.

가장 중요한 부분으로 장애 원인을 분석하여 추후 해당 장애가 다시 발생하는 것을 방지하는 것이 가장 큰 목표입니다.

 

용량 계획

애플리케이션 모니터링은 애플리케이션의 성능을 측정하고 분석할 수 있습니다. 이를 통해 애플리케이션 용량을 계획할 수 있으며, 이는 서비스의 안정성을 보장하고 서버의 자원을 최적화할 수 있습니다.

 

단점은 무엇이 있을까요?

 

추가 비용 발생

애플리케이션 모니터링을 도입하면 추가적인 비용이 발생합니다. 이는 모니터링 도구를 구입하거나 클라우드 서비스를 사용하는 데 발생하는 비용 등을 포함합니다.

오픈 소스로 이루어진 도구를 조합하여 사용해도 클라우드 기반의 서비스를 사용하기 때문에 리소스 사용량에 대해서는 지불해야 할 것 같습니다.

혹은 AWS가 제공하는 모니터링을 검토해 보아도 될 것 같습니다.

 

복잡한 설정

애플리케이션 모니터링을 도입하면 설정이 복잡해집니다. 모니터링 도구를 설치하고 설정하는 과정에서 시간과 비용이 소요될 수 있습니다.

Spring Boot 기준 조합은 Actuator, Prometheus, grafana 조합을 사용하는 것 같습니다. 이 기준은 자료양입니다.

 

데이터 처리 복잡성

애플리케이션 모니터링을 도입하면 수집된 데이터를 처리하는데 시간과 노력이 필요합니다. 이를 효율적으로 처리하기 위해서는 데이터 처리 및 저장을 위한 시스템이 필요할 수 있습니다.

수집된 데이터를 시각적으로 보는 것이 가장 좋다고 생각되고 그렇게 사용되는 것으로 보입니다.

 

보안 문제

애플리케이션 모니터링은 보안 문제를 야기할 수 있습니다. 모니터링 도구에 접근하는 권한이 없는 사람이 데이터를 탈취하거나 조작할 가능성이 있으므로, 보안 정책을 엄격히 시행해야 합니다.

어떠한 보안 정책이 필요할까요. 가장 안전한 것은 Trust 영역에 배치하고 권한을 통해 접근할 수 있도록 구성하도록 네트워크 대역을 분리하는 것이 가장 좋아 보입니다.

같은 대역을 사용해도 DMZ 영역이 L7 로드밸런서이기 때문에 로드밸런서에서도 어느 정도 보안을 챙길 수 있을 것이라 생각하고 있습니다.

 

정보 과부하

애플리케이션 모니터링은 많은 양의 데이터를 생성하므로, 모니터링 대시보드에서 모든 정보를 한눈에 볼 수 없을 수 있습니다. 이를 해결하기 위해서는 필요한 정보를 필터링하거나 요약하는 기능이 필요합니다.

총체적으로 애플리케이션 모니터링은 비용이 발생하고, 설정과 데이터 처리가 복잡하며, 보안 문제와 정보 과부하가 발생할 수 있지만, 이를 극복하고 이점을 끌어내는 것이 중요합니다.

이를 위해서는 효율적인 모니터링 전략과 보안 정책을 수립하고, 모니터링 데이터를 분석하여 서비스 품질 향상에 활용하는 것이 필요해 보입니다.

 

1번과 2번에 대한 질문에 대한 대답이 되었습니다.

모니터링이란 단점을 극복하고 이점을 끌어내는 것이 중요하기 때문에 단점을 어떻게 완화시키는지가 중요할 것 같습니다.

 

어떠한 모니터링 도구들이 있을까?

 

Spring Boot Actuator

 

Spring Boot Actuator는 Spring Boot 프로젝트에서 모니터링과 관리를 위한 강력한 도구입니다. Actuator는 애플리케이션의 상태를 검사하고 모니터링하기 위한 다양한 엔드포인트를 제공합니다. Actuator는 엔드포인트를 통해 애플리케이션의 상태를 확인하고 관리하기 위한 기능을 제공합니다. 예를 들어, Actuator를 사용하여 메모리 사용량, CPU 사용량, 스레드 수 등을 확인할 수 있습니다.

 

Prometheus

 

Prometheus는 오픈 소스 모니터링 시스템으로, 서버, 컨테이너, 애플리케이션, 서비스 등을 모니터링할 수 있습니다. Prometheus는 다양한 데이터 모델을 지원하고, HTTP 또는 메트릭 프로토콜을 통해 데이터를 수집할 수 있습니다. 또한, Grafana와 함께 사용하면 시각화된 대시보드를 통해 데이터를 쉽게 볼 수 있습니다.

 

ELK Stack

 

ELK Stack은 Elasticsearch, Logstash, Kibana를 결합한 로그 분석 플랫폼입니다. ELK Stack을 사용하면 로그 데이터를 수집, 분석 및 시각화할 수 있습니다. Logstash는 로그 데이터를 수집하고 처리하며, Elasticsearch는 로그 데이터를 검색 및 저장하며, Kibana는 검색 결과를 시각화합니다.

 

Zipkin

 

Zipkin은 분산 시스템에서의 트랜잭션 추적 및 문제 해결을 위한 도구입니다. Zipkin은 여러 서비스를 사용하는 분산 시스템에서 각 서비스 간의 연결을 추적하고, 각 연결에서 발생하는 에러 및 지연 시간 등을 추적할 수 있습니다.

 

추가적으로 알아보아야 할 것은 AWS의 CloudWatch입니다.

 

CloudWatch는 AWS에서 제공하는 모니터링 서비스로, EC2 인스턴스 및 AWS 서비스에서 발생하는 메트릭 및 로그 데이터를 모니터링할 수 있습니다. CloudWatch는 다음과 같은 기능을 제공합니다.

 

1. 리소스 모니터링 EC2 인스턴스 및 로드밸런서와 같은 AWS 리소스의 메트릭 데이터를 수집하여 모니터링할 수 있습니다. CPU 사용률, 네트워크 트래픽, 디스크 사용률 등과 같은 지표를 모니터링할 수 있습니다.
2. 로그 모니터링 EC2 인스턴스에서 발생하는 로그 데이터를 모니터링할 수 있습니다. 로그 데이터는 CloudWatch Logs에 수집되며, CloudWatch Logs Insights를 사용하여 로그 데이터를 검색하고 분석할 수 있습니다.
3. 이벤트 모니터링 AWS 리소스에서 발생하는 이벤트를 모니터링할 수 있습니다. 예를 들어, EC2 인스턴스에서 이벤트가 발생하면 CloudWatch Events를 사용하여 해당 이벤트에 대한 대응 작업을 수행할 수 있습니다.
4. 대시보드 CloudWatch 대시보드를 사용하여 모니터링 데이터를 시각적으로 표현할 수 있습니다. 대시보드를 사용하여 다양한 메트릭을 한눈에 확인할 수 있습니다.

CloudWatch는 Spring Boot 애플리케이션의 상태를 모니터링하고, 성능 문제를 해결할 수 있습니다.

 

CloudWatch는 EC2 인스턴스와 로드밸런서와 같은 AWS 리소스에서 발생하는 다양한 데이터를 모니터링할 수 있으므로, 이러한 구조에서 모니터링에 적합한 도구입니다.

 

AWS의 서비스를 도입하려면 상당히 많은 문서를 꼼꼼히 읽어야 합니다.

기본적으로 AWS 모니터링에서 메모리 사용량에 대한 모니터링을 제공하지 않습니다. 또한 클라우드 와치는 월 사용량에 따라 비용이 발생하는 것으로 보입니다.

이를 가장 적게 낼 수 있는 방법과 월별 얼마의 비용이 발생하는지 예측하기 위해 문서를 읽는 시간이 필요할 것으로 보입니다.

 

생각해 보면 제가 메모리 사용량에 대해 모니터링을 한다면 Heap Memory 사용량과 Grabage Collection Time이 관심사이지 않을까 해서 각 모니터링 도구를 알아보는 과정에서 클라우드 와치는 제외하려고 합니다.

 

 

 

 

2023.02.16 - [Spring|Spring-boot] - Spring Boot Actuator

Spring Boot Actuator

 

 

prometheus[진행중]

 

grafana[예정]