OpenShift 운영

7장. 고급 모니터링 및통합 가시성 전략

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

릭 라코우

6장에서는 OpenShift의 모니터링 스택과 모니터링, 알림 및 통합 가시성의 기본 사항에 대해 알아봤습니다. 이 장에서는 이 주제를 더 자세히 살펴보고 서비스를 모니터링하기 위한 고급 전략을 다룹니다.

서비스 지향 모니터링

시간이 지남에 따라 인프라와 서비스가 변화함에 따라 모니터링에 대한 접근 방식도 변화해 왔으며, Betsy Beyer와 동료들이 ' 사이트 안정성 엔지니어링 '을 출간한 이후 엔지니어들은 스택을 모니터링하는 더 나은 방법을 모색해 왔습니다. 특히 컨테이너화된 워크로드로의 전환으로 인해 움직이는 인프라가 훨씬 더 많아졌고, 각각의 인프라를 세심하게 관리하는 것은 불가능해졌습니다. 가축과 애완동물을 생각해보세요. 애완동물은 각각 이름이 있고, 그 동물의 상태와 필요한 것이 무엇인지 정확히 알고 있습니다. 가축의 경우, 각 동물은 무리의 일부이며 주인에게는 단순한 숫자 이상의 존재입니다. 그러나 중요한 것은 개별 동물의 느낌보다는 소가 하루에 섭취하는 우유 양과 같은 결과를 합산하는 것입니다. 즉, 기본 노드 또는 개별 컨테이너의 상태를 확인하는 대신 서비스의 상태에 초점을 맞추는 것입니다. 처음에는 이상하게 느껴질 수 있지만, 인프라와 서비스 환경이 커질수록 그 이점은 더욱 분명해집니다.

마스터 노드 3개와 워커 노드 3개가 있는 기본 OpenShift 설치를 고려한다면, 각각 여러 개의 컨테이너가 있는 수백 개의 파드를 해당 클러스터에 쉽게 배포할 수 있습니다. 이러한 컨테이너 각각에 신경을 쓰시나요, 아니면 컨테이너가 제공하는 서비스의 상태에 신경을 쓰시나요? 대부분 후자일 가능성이 높으며, 여기서 서비스 수준 목표(SLO)가 중요한 역할을 합니다. 서비스 수준 목표는 특정 서비스의 사용자에게 무엇이 중요하고 어떤 수준의 성능과 안정성이 필요한지에 대한 기술적 추상화를 제공합니다.

서비스 수준 지표

실제 예제를 살펴보겠습니다. 6장의 예제 애플리케이션과 유사한 golang 애플리케이션을 OpenShift 클러스터에 배포하고 단일 인스턴스, 즉 단일 컨테이너가 있는 단일 포드로 시작한다고 가정해 보겠습니다. 이 애플리케이션은 매번 합리적인 시간 내에 200 응답 상태 코드를 계속 전송할 것으로 예상됩니다. 이 서비스 구현을 모니터링할 때, CPU 사용량이 높거나 메모리 사용량이 비정상적으로 높으면 파드에 문제가 있고 서비스가 예상대로 응답하지 않는다고 가정할 수 있습니다. 그러나 여기에는 두 가지 큰 문제가 있습니다. 리소스를 더 많이 소비하는 경우 서비스가 응답하지 않는다는 보장이 없다는 점과 확장하면 어떻게 될까요?

스케일아웃 시나리오는 그림 7-1과 같이 경로를 통해 노출되는 서비스 뒤에 5개의 파드가 있는 경우입니다.

그림 7-1. 로드 밸런싱된 포드

단일 파드와 동일한 방식으로 모니터링하려고 하면 문제가 빠르게 ...