Elastic Stack을 사용한 Prometheus 대규모 모니터링
도구. 엔지니어로서 우리는 모두 팀들이 생산적으로 작업하고, 더 빠르게 문제를 해결하며, 더욱 개선될 수 있도록 도와주는 훌륭한 도구를 사랑합니다. 그러나 도구는 숫자가 점점 더 많아지고, 추가적인 유지관리가 필요하며, 가장 중요하게는 눈에 보이지 않는 사일로를 만드는 경향이 있을 수 있습니다. 각 팀은 담당하는 특정한 책임이 있고, 가능한 가장 좋은 방법으로 특정 요구사항을 처리할 수 있는 도구를 끊임없이 찾고 있습니다. 결과적으로, 팀들은 단일한 단위로서 효율적이 되지만, 성능이 뛰어난 그러한 자율성의 부작용으로 조직의 다른 부분들에 대한 통찰이 부족해집니다. 팀의 수에 이것을 곱하면, 비즈니스가 어떻게 진행되고 있는지에 대한 전체론적인 보기를 할 수 없는 고립된 클러스터들을 금방 알게 됩니다.
Prometheus는 그러한 도구의 훌륭한 예입니다. Prometheus는 빠르게 성장하여 컨테이너 시스템 모니터링과 알림을 위해 즐겨찾는 도구가 되었습니다. 그 주요 강점은 효율적인 모니터링과 서버 쪽 메트릭의 저장 공간에 있습니다. Prometheus는 완전한 오픈 소스이며 내보내기의 형식으로 수많은 써드파티 시스템까지 적용 범위를 확장하는 활발한 커뮤니티를 보유하고 있습니다. 대부분의 전문화된 도구처럼, Prometheus는 간단하고 운영이 손쉽도록 고안되었습니다. 이러한 단순성은 대규모 배포와 팀들 간의 공동 작업의 경우 특히 중요한 장단점이 따릅니다. 이 블로그에서는 이러한 장단점 중 일부를 분석하고 Elastic Stack이 이를 해결하는 데 어떻게 도움이 될 수 있는지 보여드리겠습니다.
데이터 장기 보존
Prometheus는 인스턴스 내에 로컬로 데이터를 저장합니다. 하나의 노드에서 컴퓨팅과 데이터 저장 공간을 둘다 갖는 것은 운영을 더욱 손쉽게 할 수 있지만 또한 확장과 고가용성 확보를 더 어렵게 만듭니다. 결과적으로, Prometheus는 메트릭 장기 저장소가 되기 위해 최적화되지 않습니다. 환경의 규모에 따라, Prometheus에서 시계열에 대해 최적화된 보존율은 며칠 또는 몇 시간 정도로 짧을 수 있습니다.
확장성과 내구성이 있는 방식으로 확장 분석(시계열의 계절성 등)을 위해 Prometheus 데이터를 보존하려면, 장기 저장 솔루션으로 Prometheus를 보완해야 합니다. 그리고 기타 전문화된 TSDB나 시계열에 최적화된 열 기반 데이터베이스와 같이 수많은 솔루션 중에 선택할 수 있습니다. 이러한 솔루션은 메트릭을 저장하는 데는 효율적이지만 한 가지 단점을 공유하는데, 오직 한 가지 유형의 데이터, 바로 메트릭에 대해서만 전문화되었다는 것입니다. 메트릭은 시스템이 어떻게 작동하고 있는지를 이해하는 데 있어 엄청나게 중요합니다. 그러나 시스템이 관측 가능하도록 만드는 것의 오직 한 부분만을 표시합니다.
사용자가 가시성에 대해 생각할 때는 로그와 추적 같은 다른 유형의 운영 데이터를 메트릭과 결합시키려고 합니다. Elastic Stack에서의 가시성에 대한 블로그에서는 로그를 위해 Elastic Stack을 채택한 사용자들이 메트릭, 추적, 가동 시간 데이터도 Elasticsearch에 넣기 시작한 사용 사례의 수가 증가하고 있는 것에 대해 얘기합니다. 그리고 당연히 Elasticsearch는 이러한 모든 데이터 유형을 그저 또 하나의 인덱스로 취급하고, 사용자가 원하는 방식으로 모든 운영 데이터를 집계하고 서로 연관시켜 분석하고 시각화할 수 있게 해줍니다. Elastic에서 데이터 롤업 같은 기능을 통해 원시 데이터의 저장 비용의 극히 일부만으로 시계열 데이터 기록을 저장할 수 있습니다.
그럼 Prometheus를 위한 장기 저장 공간을 선택하는 데 있어 이것은 어떤 의미일까요? 전용 메트릭 저장소를 선택하여 Prometheus 메트릭에 대해 더 긴 보존율을 얻고 잠재적으로 또 다른 사일로를 만들 수 있습니다. 또는 Elastic Stack으로 두 세계의 가장 좋은 점을 결합할 수 있습니다. 즉, 에지에서 Prometheus를 실행하고 확장 가능한 중앙화된 Elasticsearch 배포에서 다른 운영 데이터와 더불어 원하는 기간 동안 메트릭을 보존합니다. 이것은 장기 저장 공간과 동시에 가시성 증가를 의미합니다.
Prometheus 데이터를 위한 중앙화된 전체 보기
프로덕션 설정에서 아마도 여러 개의 Kubernetes 클러스터를 관리하고 있으실 것입니다. 각 클러스터는 노드, pod, 서비스, 엔드포인트의 상태를 볼 수 있는 하나 이상의 Prometheus 인스턴스를 실행합니다. 무엇인가 빠졌나요?
하나의 Prometheus 인스턴스는 사용자의 환경에서 리소스의 하위 집합을 다룰 수 있습니다. 여러 개의 클러스터에서 메트릭을 쿼리해야 하는 질문을 하고자 하는 경우에는, Prometheus로 간단하게 그렇게 할 수 있는 방법이 없습니다.
Elastic을 중앙화된 저장소로 사용하면 Prometheus 인스턴스 수백 개의 데이터를 통합하고, 모든 리소스에서 들어오는 데이터를 전체적으로 파악하는 데 도움이 될 수 있습니다. Metricbeat를 위한 Prometheus 모듈은 Prometheus 인스턴스, 푸시 게이트웨이, 내보내기, 그리고 Prometheus 설명 형식을 지원하는 거의 모든 다른 서비스에서 자동으로 메트릭을 가져옵니다. 가장 좋은 점은 프로덕션 환경에서 아무 것도 변경할 필요가 없다는 것입니다. 순전히 플러그 앤 플레이 방식입니다.
카디널리티가 높은 측정 기준
“높은 카디널리티”가 왜 중요할까요? 높은 카디널리티는 메트릭에 태그나 레이블로 임의의 컨텍스트를 추가하게 해줍니다. 대부분의 경우, 서비스를 디버깅할 때 엄청나게 유용할 수 있기 때문에 이 메타데이터를 보존하면 좋습니다. 이 모든 추적 ID, 요청 ID, 컨테이너 ID, 버전 번호 등은 언제나 시스템에서 진행되는 상황에 대한 더 자세한 정보를 알려줍니다.
순수한 TSDB는 카디널리티가 낮은 측정 기준을 잘 처리합니다. 전문화된 TSDB가 Elasticsearch에 대해 갖는 요구된 저장소 효율성은 카디널리티가 낮은 측정 기준에 아주 많이 의존합니다. Prometheus 설명서는 카디널리티가 높은 데이터에 대해 다음을 강력히 권장합니다.
주의: 키-값 레이블 쌍의 모든 고유한 조합은 새로운 시계열을 나타낸다는 것을 기억해두세요. 이것은 저장된 데이터의 양을 극적으로 증가시킬 수 있습니다. 레이블을 사용하여 사용자 ID, 이메일 주소 또는 기타 제한 없는 값 세트와 같이 카디널리티가 높은 측정 기준(수많은 다른 레이블 값)을 저장하지 마세요.
이것이 정말 좋은 조언인가요? 분산 환경에서, 디버깅은 대단히 복잡한 작업입니다. 이전에는, 모놀리식으로 디버깅이 애플리케이션 코드를 통한 간단한 단계별 실행 프로세스였습니다. 몇 개의 대시보드를 살펴봄으로써 어느 모놀리식 모듈이 문제를 일으키는 원인이었는지 손쉽게 파악할 수 있었습니다. 더 이상 이렇게 할 필요가 없습니다. 인프라 소프트웨어는 패러다임 변환 중에 있습니다. 컨테이너, 오케스트레이터, 마이크로서비스, 서비스 메시, 서버리스, 람다, 이 모든 것이 우리가 소프트웨어를 빌드하고 운영하는 방식을 변화시키는 놀랄 만큼 유명한 기술입니다. 결과적으로 이것은 훨씬 더 분산적이 되고 그것을 디버깅하는 일이 시스템의 어디에 문제가 있는 코드가 있는지를 찾아내는 탐색 작업에 비교될 수 있습니다.
높은 카디널리티는 Elastic에게는 문제가 아닙니다. 사용자가 데이터에 관련 컨텍스트를 추가하는 데는 아무런 제한도 없어야 합니다. 색인 기능 덕분에, Elasticsearch는 가능한 한 단시간에 근본 원인을 파악하는 데 도움이 되도록 기여 요인을 찾는 것을 지원할 수 있는 모든 메타데이터로 사용자가 원하는 방식으로 메트릭에 주석을 달 수 있게 해줍니다.
보안. 어디에서나.
우리가 좋은 도구에서 기대했던 것들 중 하나는 최소한 우리 환경에 보안 위험을 도입하지는 않는 것입니다. 모든 분산 배포에서 보안을 위한 두 가지 기본 구성 요소는 암호화된 커뮤니케이션과 액세스 제어입니다.
이 글을 작성하는 시점에 Prometheus 서버, Alertmanager, 공식 내보내기는 HTTP 엔드포인트의 TLS 암호화를 지원하지 않습니다. 보안된 방식으로 이러한 구성 요소를 배포하기 위해, nginx 같은 역방향 프록시를 사용하고 프록시 계층에 TLS 암호화를 적용해야 할 것입니다. 메트릭에 대한 모든 역할 기반 액세스 제어(RBAC)는 또한 Prometheus 서버 그 자체에 의해서보다는 외부에서 처리되어야 합니다. 좋은 소식은 TLS와 RBAC를 둘다 제공하기 때문에 Kubernetes 내부에서 Prometheus를 실행 중인 경우 TLS와 RBAC가 문제가 되지 않는다는 것입니다. 모든 다른 사례에서(지리적으로 분산된 배포나 하이브리드 배포에서 수백 개의 Prometheus 서버를 실행하는 등) 써드파티 도구로 이러한 보안 우려사항을 처리하는 것은 사소한 작업이 아닙니다.
Elastic에서는 그러한 위험을 대단히 진지하게 여기고 있으며 보안을 우리 스택의 중요한 부분으로 만듭니다. 기본 보안 옵션은 무료 기본 배포의 일부이며, Elasticsearch는 클러스터에서 데이터에 대한 액세스 보안을 유지하고 아울러 클러스터와 데이터 수집기 간의 트래픽을 암호화하는 여러 가지 방법을 제공합니다. RBAC에 더하여, Elasticsearch는 미세 조정된 속성 기반 액세스 제어(ABAC) 메커니즘을 지원하며, 이것은 사용자가 검색 쿼리와 집계에서 문서에 대한 액세스를 제한할 수 있게 해줍니다. Metricbeat의 SSL 구성 설정으로, 환경이 얼마나 크고 얼마나 분산되어 있는지와 관계없이 운영 데이터가 안전하게 이동하도록 할 수 있습니다.
Prometheus 메트릭을 Elasticsearch로 스트리밍
이제 Metricbeat로 벌써 메트릭을 Prometheus에서 Elasticsearch로 스트리밍하기 시작할 수 있습니다. Prometheus 모듈을 사용하여 Prometheus 서버, 내보내기 또는 푸시 게이트웨이에서 다음과 같이 여러 가지 방법으로 메트릭을 가져올 수 있습니다.
- 이미 Prometheus 서버를 실행 중이고 이러한 메트릭을 직접 쿼리하고자 하는 경우, Prometheus 서버에 연결하고
/메트릭엔드포인트나 Prometheus Federation API 를 사용하여 이미 수집된 메트릭을 풀링함으로써 시작할 수 있습니다.
- Prometheus 서버를 갖추고 있지 않거나 여러 도구를 통해 병렬로 내보내기와 푸시 게이트웨이를 가져오는 것을 개의치 않는다면, 이에 직접 연결할 수도 있습니다.
Metricbeat을 가능한 한 Prometheus 서버에 가까이 실행하세요. Prometheus 및 오픈 표준 블로그에서 필요에 가장 적합한 구성을 선택하실 수 있습니다.
Prometheus 서버 상태 계속 지켜보기
Elastic Stack은 또한 모든 Prometheus 인스턴스의 상태를 계속 지켜볼 수 있는 방법을 제공합니다. Metricbeat를 사용해 사용자 환경의 각 Prometheus 서버로부터 성능 메트릭을 수집하고 저장할 수 있습니다. 기본으로 제공되는 미리 정의된 대시보드로, 엔드포인트당 HTTP 요청 수, 쿼리 지속 시간, 발견된 대상의 수와 같은 것들을 손쉽게 볼 수 있습니다.
모든 것을 고려
하루가 끝날 때, 목표는 사용자와 사용자의 팀, 그리고 사용자의 조직 전체가 성공하도록 하는 것입니다. 모든 도구는 이러한 목표를 위한 수단으로 보아야 합니다. 모든 팀은 그들의 잠재력을 충분히 발휘할 수 있도록 돕는 것이면 무엇이나 자유롭게 선택할 수 있어야 합니다. 그리고 운영 사일로 문제를 해결하는 것과 관련해, 우리는 Elastic Stack이 사용자 조직 내의 모두가 안전하게 운영 데이터에 액세스하고, 이 데이터와 상호작용하고, 다시 하나의 팀이 될 수 있는 궁극적인 가시성 플랫폼을 구축하도록 도울 수 있다고 믿습니다.
Elastic Metrics 웹페이지에서 시계열 데이터로 작업하는 방법에 대해 자세히 알아보실 수 있습니다. 메트릭을 Elasticsearch Service로 스트리밍해보세요. 가장 쉽고 빠르게 시작할 수 있습니다. 질문이 있으시면 토론 포럼에서 자유롭게 연락주세요.