Elastic Observability로 인프라 및 마이크로서비스 모니터링

인프라 및 소프트웨어 분야의 트렌드는 소프트웨어를 구축하고 실행하는 방식을 바꾸어 놓았습니다. Elastic은 이에 부응하여 인프라를 코드로 처리하기 시작했으며(Infrastructure as Code), 이를 통해 비용을 낮추고 제품을 더 빠르게 출시할 수 있게 되었습니다. 그뿐만 아니라 이러한 새로운 아키텍처를 통해 프로덕션과 유사한 배포 환경에서 소프트웨어를 더 빠르게 테스트하고 일반적으로 더 안정적이고 재생산 가능한 배포를 제공할 수 있게 되었습니다. 하지만 동전의 양면처럼 개선과 함께 환경의 복잡성이 증가했습니다. 특히 새로운 인프라를 효과적으로 모니터링하는 일에는 그만큼 복잡성도 커졌습니다. 

이 블로그에서는 사용자 정의 애플리케이션, 서비스, 그 기반이 되는 인프라 등 전체 애플리케이션 스택을 모니터링하기 위한 “필수 요소”에 대해 설명합니다. 또한 Elastic Observability 솔루션과 Elastic Stack이 이러한 요구 사항을 해결하는 데 어떻게 도움이 되고, 통합 가시성을 향상하는 동시에 가동 중단 시간을 줄이는 궁극의 모니터링 플랫폼을 구축하는 데 어떻게 도움이 되는지 살펴봅니다. 준비되시면, Elastic Cloud 무료 체험판을 사용해 보거나 웹 사이트에서 최신 버전을 다운로드하여 시작하실 수 있습니다.

진화하는 아키텍처: 컨테이너와 마이크로서비스로의 여정

우리는 어떻게 여기까지 왔을까요? 인프라 소프트웨어 분야는 매우 빠른 속도로 진화하고 있습니다. 하드웨어 측면에서는 물리적 머신 사용에서 다양한 가상화 도구(또는 하이퍼바이저) 사용으로 전환되었고, 그런 다음 서버 및 네트워크의 유지 관리와 프로비저닝을 아웃소싱할 수 있는 방법을 제공하는 퍼블릭 클라우드 인프라가 등장하여 목표 달성까지 걸리는 시간을 단축할 수 있게 되었습니다. 저는 프로젝트를 진행하려면 새로운 서버를 프로비저닝하기 위해 몇 주씩 기다려야 했던 때가 아직도 기억납니다. 지금도 그렇게 기다리는 기업이 있을지도 모르지만, 이는 이미 해결된 문제입니다. 현재 많은 기업이 선택하고 있는 플랫폼은 Docker 및 Kubernetes와 같은 컨테이너 오케스트레이터인 컨테이너 플랫폼입니다. 물론 이러한 기업들 대다수가 베어 메탈 호스트 기반의 가상화도 사용합니다.

소프트웨어 측면을 보면 모놀리식 개발에서 모놀리식을 여러 계층(프레젠테이션, 애플리케이션, 데이터 등)으로 분리하는 방식의 개발로 전환되었습니다. 그런 다음 SOA(서비스 지향 아키텍처)가 지배적인 설계 패턴이 되었고, 웹 서비스, 이벤트 중심 아키텍처, 그리고 최신 트렌드인 마이크로서비스 등 다양한 방향으로 진화했습니다. 만약 지금 새로운 애플리케이션을 구축하려고 한다면 아마도 클라우드 어딘가에 있는 Kubernetes의 pod에서 실행되는 마이크로서비스를 기반으로 할 것입니다. 대부분의 조직에서는 오래된 모놀리식을 마이크로서비스로 분리하고 오케스트레이터를 사용하여 배포하는 이니셔티브를 하나 이상 진행하고 계실 것입니다.

그에 따라 이제 Elastic 스택에는 모니터링해야 할 구성 요소가 더 많아졌고, Elastic 모니터링 도구는 빠른 속도로 나타나거나 사라지는 컨테이너와 함께 지속적으로 이동하는 애플리케이션을 추적할 수 있어야 합니다. 현대적 환경을 모니터링하기 위해서는 완전히 새로운 접근 방식이 필요합니다.

인프라 모니터링: 현대적 환경의 복잡성으로 인한 요구 사항 

오늘날의 배포 환경에 대해 이야기할 때는 다음과 같은 몇 가지 사항을 고려해야 합니다. 먼저 온프레미스 데이터 센터, 퍼블릭 클라우드 인프라 또는 하이브리드 환경 등 실행의 기반이 되는 인프라가 있습니다. 그리고 오늘날 모든 일반적인 환경에는 애플리케이션의 배포와 확장을 자동화하는 오케스트레이션 계층(예: Kubernetes)이 있습니다. 컨테이너, VM 또는 베어 메탈과 같이 애플리케이션이 실행되는 환경도 있습니다. 애플리케이션을 개발하는 경우 외부 서비스, 데이터베이스 또는 조직의 다른 팀에서 작성한 구성 요소 등 서드파티 시스템에 대한 종속성이 발생합니다. 물론 애플리케이션 자체, 즉 내부 구성 요소와 최종 사용자 환경 모두 마찬가지입니다.

애플리케이션이 제대로 작동하도록 보장하려면 이러한 다양한 구성 요소를 모두 모니터링해야 하는데, 모든 구성 요소는 로그와 메트릭은 물론 APM과 가동 시간 데이터 등 수많은 모니터링 데이터를 생성합니다. 

배포 환경에 대한 완벽한 가시성을 확보하려면 모니터링 솔루션이 다음과 같은 기능을 갖추어야 합니다.

• 호스트부터 애플리케이션까지 전체 인프라 및 애플리케이션 스택을 지원해야 합니다.
• VM, 컨테이너, 오케스트레이터, 클라우드 플랫폼, 데이터베이스 등 다양한 소스에서 손쉽게 데이터를 수집해야 합니다(모니터링 솔루션에서 제공하는 다른 시스템과의 통합이 일반적인 특징임).
• 인프라 환경이 컨테이너식으로 전환됨에 따라 점점 더 동적으로 변하는 배포를 처리하는 동시에 기존의 오래된 인프라의 일부까지 처리해야 합니다.
• DevOps부터 제품 및 비즈니스 소유자에 이르기까지 조직 내 모든 사람에게 최적화된 보기를 구축하고 운영 데이터와 상호 작용할 수 있는 강력한 방법을 제공해야 합니다.
• 문제가 발생하면 알려주어야 합니다. 경보는 모든 모니터링 솔루션의 기본 구성 요소 중 하나이며 모든 인프라를 완벽하게 지원해야 합니다.
• 기록 분석 또는 규제 요구 사항을 위해 로그 및 메트릭을 장기간 안정적으로 저장할 수 있는 스토리지를 제공해야 합니다. 이 스토리지 솔루션은 세분화된 제어 기능과 보존 기간으로 데이터 수명 주기를 관리할 수 있는 기능을 제공해야 합니다.
• 전체 인프라 및 애플리케이션의 통합 가시성에 적합해야 합니다. 대부분의 모니터링 도구는 일반적으로 한 가지 데이터 유형에 특화되어 있습니다. 예를 들어 인기 있는 많은 시계열 데이터베이스(TSDB)에서는 메트릭이라는 한가지 유형만 파악할 수 있습니다. 하지만 일반적인 배포 환경에서는 로그, 메트릭, APM, 가용성 데이터 등 다양한 유형의 데이터가 생성됩니다. 이러한 데이터 스트림은 환경이 어떻게 운영되고 있는지에 대해 다양한 관점을 제공하므로 각 데이터를 분리해서 다루거나 학습 곡선, 라이선스 모델 또는 지원 수준이 서로 다른 도구로 유지 관리해서는 안될 것입니다.
• 이 모든 도구를 단일 모니터링 솔루션으로 통합해야 합니다.

위의 목록은 두 가지 핵심 요구 사항으로 요약할 수 있습니다. 인프라 모니터링 솔루션은 인프라의 모든 부분에서 운영 데이터를 가져올 수 있어야 하며 이러한 데이터는 실행 가능해야 한다는 것입니다.

인프라 모니터링을 위한 Elastic Stack(ELK Stack)

오늘날의 인프라를 효과적으로 관찰하기 위해서는 지속적인 진화와 향상된 모니터링 성능이 필요하며 이를 위해서는 빠르고 확장 가능하며 유연한 솔루션이 필요합니다. Elastic에서 이러한 요구 사항을 어떻게 해결하는지 살펴보겠습니다.

로그와 지표 수집

Elastic은 수백 개의 플랫폼과 서비스에서 로그 및 메트릭 데이터를 수집할 수 있도록 통합 기능을 제공합니다. 이러한 통합 기능을 사용하면 새로운 데이터 소스를 손쉽게 추가할 수 있을 뿐만 아니라 대시보드, 다중 시각화 및 미리 빌드된 파이프라인(예: 로그에서 특정 필드 추출)과 같이 기본 제공되는 자산도 바로 활용할 수 있습니다. Elastic에서는 로그 및 메트릭 데이터를 Elastic Stack으로 전송하기 위한 Metricbeat와 Filebeat를 제공합니다. Metricbeat 및 Filebeat에서 지원하는 모든 통합 기능에는 Kibana에서 바로 손쉽게 따라 할 수 있는 지침이 제공됩니다.

통합 가시성(및 보안)의 다른 영역으로 확장하다 보면 수집기와 에이전트가 훨씬 더 많이 늘어나게 됩니다. 에이전트 플릿을 구성하고 관리하는 작업이 복잡해질 수 있으며 특히 대기업 환경에서는 더욱 복잡해질 수 있습니다. 에이전트 배포를 관리하고, 구성 파일을 업데이트하고, 데이터를 관리해야 하며, 이는 오늘날 많은 팀이 이미 수행하고 있는 작업입니다. Elastic에서는 이를 개선하고자 했습니다. 이를 위해 릴리즈 7.8에서는 Elastic 에이전트와 Fleet이라는 두 가지 새로운 구성 요소를 도입하여 운영 데이터를 Elastic으로 전송하는 기능을 대폭 개선했습니다.

• Elastic 에이전트는 로그, 메트릭 및 다른 유형의 데이터를 수집하는 단일 에이전트입니다. 개별 통합을 수동으로 유지 관리하는 것보다 설치 및 관리가 훨씬 더 쉽습니다.
• Fleet은 원하는 플랫폼과 서비스를 신속하게 통합하고 전체 Elastic 에이전트 플릿을 중앙에서 관리하는 두 가지 기능을 제공하는 새로운 Kibana 앱입니다.

기존 모니터링 도구는 어떻게 되나요? Stackdriver, Azure Monitor와 같은 네이티브 클라우드 모니터링 서비스 또는 Prometheus, statsd와 같은 도구를 사용하고 있으며 메트릭을 로그 및 기타 데이터와 통합하기로 결정한 경우, Elastic은 이러한 고급 모니터링 도구를 위한 전용 통합 기능을 제공합니다. 따라서 사용자는 기존 계측 도구(예: Prometheus Exporter)를 유지하면서 메트릭을 다른 운영 데이터와 함께 저장하여 통합 가시성을 향상할 수 있습니다.

앞서 컨테이너식 배포로 전환하려면 일반적으로 시스템을 모니터링하는 방법을 재고해야 한다고 말씀드렸는데요. 특히 물리적 호스트 또는 가상 머신 및 정적 인프라를 처리하도록 설계된 기존 모니터링 도구의 경우 더욱더 그렇습니다. 컨테이너 환경에서는 이러한 접근 방식이 더 이상 충분하지 않습니다. 컨테이너 환경에서는 작업이 끊임없이 진행되고, 컨테이너가 가동 및 종료되고, 서비스가 더 자주 배포되고, IP 주소가 불안정하고 신뢰할 수 없는데, 대부분의 모니터링 도구가 이러한 상황을 맞게 설계되지 않았기 때문입니다. 컨테이너에서 애플리케이션을 실행하면 이러한 애플리케이션은 모니터링 시스템의 움직이는 대상이 됩니다. 따라서 새로 배포된 서비스, 확장된 인스턴스, 업그레이드 등과 같이 환경에서 이루어지는 변경 사항을 자동으로 탐색할 수 있어야 합니다. 다행히 Metricbeat 및 Filebeat에는 자동 탐색 기능이 있어 서비스가 실행되는 대로 배포를 추적하고, 변경 사항을 감지하고, 구성을 조정하여 서비스를 모니터링할 수 있습니다. 

Elastic의 통합 기능을 통해 수집된 모든 데이터는 Elastic Observability 및 Security 솔루션 전체에서 참조로 사용되는 ECS(Elastic Common Schema)를 준수합니다. ECS는 다른 데이터 모델과 어떻게 다른가요? 기본적으로 ECS는 Elasticsearch에서 사용하도록 최적화되어 있습니다. ECS는 오픈 소스이며 글로벌 커뮤니티의 기여에 힘입어 만들어졌습니다. 그리고 처음부터 인프라 메트릭 및 로그, APM, 보안 등 광범위한 사용 사례를 고려했습니다. ECS는 Elastic의 모든 솔루션에서 다양한 데이터 스트림을 통합된 방식으로 상호 연결, 시각화 및 분석하는 데 사용되는 결합 조직으로 생각하면 됩니다. 

ECS는 Elastic에서만 사용되고 있지는 않습니다. ECS를 도입한 후 고유한 사용 사례에 맞춰 도메인별 스키마로 ECS를 보강하는 기업이 점점 더 늘어나고 있습니다. 일부 기업은 팀 간 프로젝트에서 공통 데이터 모델로 ECS를 사용하기도 합니다. Elastic 솔루션이 조직의 사일로를 제거하고 효율적인 협업을 도모하는 데 사용되는 이러한 사례를 볼 수 있어 정말 기쁩니다.

로그와 지표 저장

데이터 저장에 관해서는 Elasticsearch가 로그 저장 시스템으로 가장 잘 알려져 있을 것입니다. Elasticsearch의 첫 번째 사용 사례가 로깅이었으므로 놀라운 일은 아닙니다. 하지만 시간이 지남에 따라 많은 사용자가 로그와 함께 시계열 데이터를 저장하고 있으며 이는 매우 당연한 결과입니다. 인프라 및 애플리케이션 로그를 저장하면서 언제 로그를 확인해야 하는지 알려주는 메트릭을 저장하지 않을 이유가 있을까요?

Elastic은 초기부터 열 형식 저장소를 도입하여 이러한 사용 사례를 가능하게 하는 시계열 데이터 저장소로서의 Elasticsearch에 투자했습니다. 그런 다음 메트릭을 다양한 차원으로 그룹화 및 필터링할 수 있게 지원하는 집계 프레임워크를 추가했습니다. 숫자 데이터 및 위치 정보 데이터를 처리하는 능력을 개선하기 위해 BKD 트리뿐만 아니라 시계열 데이터를 효율적으로 관리하기 위한 여러 가지 다른 기능, 즉 기록 데이터의 세분성(즉, 다운샘플링)을 줄일 수 있는 데이터 롤업, 각기 다른 데이터 단계(핫, 웜, 콜드, 삭제 등)에 맞게 보존 기간을 다양하게 제어할 수 있는 인덱스 수명 주기 관리와 같은 기능을 도입했습니다.

실행 가능한 모니터링 데이터로 전환

시각화

수집 기능이 정상적으로 작동하며 이제 로그 및 메트릭이 Elastic으로 스트리밍되고 있다고 가정해 보겠습니다. 가장 먼저 해야 할 일은 이 데이터를 의미 있는 방식으로 보는 것입니다. 일부 모니터링 도구는 데이터 시각화를 생성하거나 검색하는 작업을 사용자에게 맡기지만, Elastic에서는 이를 필수적인 부분으로 생각하므로 지원되는 모든 통합에 미리 구축된 시각화와 대시보드를 제공합니다. 다시 말해 로그 또는 메트릭 수집을 시작하자마자 대시보드를 신속하게 불러와서 시스템과 서비스에서 무슨 일이 일어나고 있는지 즉시 확인할 수 있습니다. 

미리 정의된 대시보드를 구성하는 모든 시각화는 재사용할 수 있습니다. 즉, 특히 유용하다고 생각되는 시각화를 선택하고 특정 요구 사항에 맞는 사용자 정의 대시보드를 만들어 다양한 통합에서 원하는 대로 조합함으로써 질문에 대한 답변을 얻을 수 있습니다. 필터링을 위한 사용자 정의 드롭다운을 만들거나 컨텍스트를 유지하면서 한 대시보드에서 다른 대시보드로 이동하기 위한 드릴다운을 만들 수도 있습니다. 문제 해결 워크플로우를 간소화하는 데 도움이 되므로 상당히 편리합니다.

대시보드 및 시각화 외에도 Elastic은 로그, 메트릭 및 가용성에 대한 큐레이션된 앱을 제공합니다. 이 앱들은 인프라에 대한 가시성을 높이도록 설계되었습니다.

Metrics 앱을 사용하면 전체 인프라를 한 곳에서 볼 수 있습니다. 지리적으로 분산된 데이터 센터가 있거나, 여러 클라우드에서 Kubernetes를 실행하고 있거나, 여러 환경을 조합하여 운영하고 있거나 상관없습니다. 모든 리소스에 대한 단일창을 제공하므로, 여기에서 인프라 제공업체별, 지리적 영역별 또는 스테이징 환경과 프로덕션 환경을 구분하는 데 사용하고 있는 거의 모든 사용자 정의 태그 필드별로 리소스를 그룹화할 수 있습니다. 이 보기를 통해 원하는 리소스에 대한 자세한 메트릭을 보고, 로그, 애플리케이션 또는 가동 시간 정보를 확인할 수 있습니다. 이는 Elastic이 모든 운영 데이터의 단일 데이터 저장소로 사용되기에 가능한 일입니다. 따라서 큐레이션된 보기를 구축하고, 간단하게 탐색할 수 있도록 함께 연결하고, 인프라 모니터링 환경을 간소화할 수 있습니다. 

Metrics 앱은 Metrics Explorer를 제공합니다. Metrics Explorer에서는 서로 다른 메트릭을 중첩하여 상관관계가 존재하는지 확인할 수 있으므로 문제 해결에 유용합니다. 여기에서 새로운 시각화 또는 임계값 알림을 생성할 수도 있습니다.

Logs 앱은 기본적으로 전체 인프라에 대한 tail -f입니다. 이 앱은 모든 로그 스트림을 통합하고 실시간 로그와 기록 로그를 하나의 보기에 표시합니다. 백그라운드에서는 로그가 메트릭과 상호 연관되어 있으므로 문제를 조사하면서 트레일을 추적하기가 훨씬 쉽습니다. 이 앱에서는 모든 로그 라인에 대한 세부 정보를 볼 수 있으며, 해당 로그 라인이 작성되기 전과 후에 발생한 일도 확인할 수 있습니다. Kibana의 다른 통합 가시성 앱과 마찬가지로 단순히 읽기 전용 보기를 넘어 경보 및 머신 러닝 기능을 활용하여 의심스러운 부분을 분석하고 조치를 취할 수 있게 해줍니다.

경보

전체 인프라에 걸쳐 문제를 탐색하고 대응하는 데 도움이 되는 경보는 모든 모니터링 사용 사례의 기본 구성 요소 중 하나입니다. Elastic은 새로운 경보 프레임워크 덕분에 이제 각기 다른 데이터 스트림에 최적화된 다양한 경보 유형을 제공할 수 있습니다. 

• 메트릭 경보는 물리적 또는 컨테이너식 배포 유형과 관계없이 모든 유형에 맞게 손쉽게 구성할 수 있습니다. 즉, 이러한 경보는 새로 생성된 리소스를 자동으로 처리할 수 있습니다. 필터를 사용하면 인프라의 어떤 부분에 경보를 적용할지 제어할 수 있습니다. 또한 경보를 한 번 구성한 후, 모든 호스트에 대해 경보 발생, 모든 호스트의 모든 디스크에 대해 경보 발생 등 원하는 필드별로 자동으로 분할할 수 있습니다.

• 로그 경보는 로그 데이터에 최적화되어 있으며 구문과 일치하는 필드 또는 특정 필드의 로그 빈도에 따라 경보를 생성할 수 있습니다.

모든 경보는 Kibana의 중앙 위치에서 생성하고 관리할 수 있지만, 각 앱에도 내장되어 있으므로 일상적인 작업에서 아주 쉽게 사용할 수 있습니다.

머신 러닝 및 이상 징후 탐색

오늘날 인프라는 많은 운영 데이터를 생성하며 그 수가 계속 증가하고 있으므로 다양한 데이터 스트림을 수동으로 분석하는 것은 사실상 불가능합니다. 실제로 이는 기업에 심각한 문제가 되고 있어 기업들은 문제 탐색을 자동화할 방법을 모색하고 있습니다. 따라서 최신 모니터링 솔루션에는 문제가 발생하기 전에 배포 환경에서 비정상적인 동작을 자동으로 탐색하는 기능이 중요합니다.

다행히 운영 데이터가 일단 Elasticsearch에 수집되면 바로 분석 가능한 상태가 됩니다. 이상 징후 탐색을 위해 미리 정의된 머신 러닝 작업이 이미 로그 및 메트릭에 최적화되어 있으며 필요한 Kibana 앱과 통합되어 있습니다. 예를 들어 인프라 로그가 생성되는 속도에 이상 징후가 있는지 자동으로 탐색하거나 로그에서 패턴을 찾아 자동으로 카테고리로 그룹화할 수 있습니다.

Elastic의 머신 러닝 기능은 이상 징후 탐색에만 국한되지 않습니다. 인프라 데이터와 관련된 광범위한 사용 사례에 걸쳐 분류, 이상값 탐색 등 다른 알고리즘을 사용할 수 있습니다.

Elastic Stack으로 가치 증대

Elastic에서는 모든 것이 또 하나의 인덱스이므로 어떤 Elastic 기능이든지 모니터링 데이터에 사용할 수 있습니다. Kibana에서 다양한 시각화를 사용하면 조직 내 모든 사람에게 의미 있는 보기를 만들 수 있습니다. 예를 들어 Lens와 TSVB(이전 명칭 시계열 비주얼 빌더, 주석을 달 수 있는 메트릭 및 히스토그램 시각화를 구축하기 위한 강력한 도구)로 구축한 유연하고 풍부한 대시보드는 엔지니어링 팀에 유용하며, Canvas를 사용해 복잡한 데이터를 트렌드로 바꾸는 라이브 인포그래픽은 비즈니스 소유자에게 가치가 있습니다. 

Elastic에 저장하는 모든 데이터는 SQL 또는 PromQL과 같이 익숙한 쿼리 언어를 사용해 API 또는 UI로 액세스할 수 있습니다. PromQL은 점점 더 널리 사용되고 있으며, Elastic이 Prometheus와 통합되므로 PromQL 쿼리 결과를 Elastic에 쓸 수 있습니다. 이는 원시 메트릭을 저장하길 원하지 않으며 이미 처리된 데이터에만 관심이 있는 경우 특히 유용합니다.

또한 인프라 모니터링을 보안과 결합할 수도 있습니다. 통합 가시성과 보안의 경계는 사라지고 있습니다. 본질적으로 인프라 모니터링에 사용하는 데이터와 인프라 보안에 사용하는 데이터가 동일하기 때문입니다. Observability와 같은 Elastic Security 솔루션은 Elastic Stack을 기반으로 구축되며 손쉽게 인프라에서 보안 위협을 탐색하고 방지할 수 있게 해줍니다.

결론

이 블로그에서는 최신 모니터링 솔루션의 필요성을 설명하고 Elastic이 어떻게 이를 해결할 수 있는지 보여드렸습니다. Elastic Observability 솔루션과 Elastic Stack을 사용하면 귀하와 귀하의 팀이 모든 운영 데이터를 안전하게 수집하고, 상호 작용하며, 비즈니스를 성공으로 이끌 수 있는 궁극의 모니터링 플랫폼을 구축할 수 있습니다.

자료를 읽는 데 그치지 말고 직접 체험해보세요.  Elastic Cloud 무료 체험판으로 클러스터를 가동하시거나 웹 사이트에서 최신 버전을 다운로드하신 후 의견을 들려주세요.