Elastic Stack을 통한 가관측성

Elastic에서 가관측성을 담당하는제품 책임자로서 저는 '가관측성'이라는 용어를 사용할 때 몇 가지 다른 반응을 접합니다. 오늘날까지 가장 일반적인 반응은 다음과 같습니다. "’가관측성’이 뭔가요?" 하지만 이런 말을 듣는 경우도 늘었습니다. "최근에 '가관측성 이니셔티브'를 시작했지만, 여전히 정확히 어떻게 해야 하는지 고민하고 있습니다." 그리고 마침내, 다행히도 함께 일할 수 있었던 몇몇 단체들은 이미 '가관측성'을 제품과 서비스를 디자인하는 방식의 필수적인 부분으로 여깁니다.

이 용어가 여전히 인기를 끌고 있다는 점을 감안할 때, Elastic 뷰의 '가관측성'에서, 아이디어를 선도하는 여러 고객으로부터 무엇을 배웠는지, 그리고 운영 사용 사례에 대한 스택을 진화시키면서 제품 관점에서 이를 어떻게 생각하는지를 이해하게 설명하는 것이 유용할 것이라고 생각했습니다.

'가관측성'이란 무엇입니까?

분명, '가관측성'이라는 단어를 우리가 만들어낸 것은 아닙니다. 우리는 주로 SRE(Site Reliability Engineering) 커뮤니티 내의 여러 사용자로부터 이에 대해 알게 되었습니다. 이 용어의 여러 출처는 Twitter와 같은 실리콘 밸리 대기업에서 SRE 조직으로 거슬러 올라갑니다. 그리고 큰 영향을 미치는 Google SRE Book에서는 이 용어를 언급하지는 않지만, 오늘날 '가관측성'과 관련된 많은 원칙을 제시하고 있습니다.

'가관측성'은 업체가 상자에 담아 제공하는 것이 아니라, 사용자가 구축하는 시스템의 속성이며, 사용성, 고가용성 및 안정성과 유사합니다. '관측 가능한' 시스템을 설계하고 구축하는 목적은 운영자가 운영 환경에서 실행할 때 바람직하지 않은 동작(예: 서비스 중단, 오류, 느린 응답)을 탐지하고 근본 원인을 효과적으로 파악할 수 있도록 하는 것입니다(예: 상세 이벤트 로그, 세분화된 리소스 사용 정보 및 애플리케이션 추적). 조직이 이러한 명백한 목표를 달성하지 못하게 하는 일반적인 문제에는 충분한 정보를 수집하지 않는 것, 너무 많은 정보를 수집하지만 실행 가능하도록 하지 않는 것, 이 정보에 대한 액세스를 세분화하는 것이 포함됩니다.

첫 번째 측면인 바람직하지 않은 동작 감지는 대개 SLI(Service Level Indicators) 및 SLO(Objectives) 설정으로 시작합니다. 이것은 생산 시스템이 가관측성을 고려하는 조직에서 평가되는 성공의 내부 척도입니다. 이러한 목적을 이행해야 하는 계약상의 의무가 있는 경우, SLI/SLO는 SLA(서비스 수준 계약)로도 해석될 수 있습니다. SLI의 가장 일반적인 예는 시스템 가동 시간이며, 이 경우 SLO를 99.9999%로 설정할 수 있습니다. 시스템 가동 시간은 외부 고객에게 가장 많이 노출되는 SLA이기도 합니다. 그러나 SLI/SLO는 내부적으로 훨씬 더 세분화될 수 있으며, 이러한 가장 중요한 생산 시스템 동작에 대한 모니터링 및 알림은 가관측성 이니셔티브라면 기본입니다. 이러한 가관측성의 측면은 ‘모니터링’이라는 용어로도 알려져 있습니다.

두 번째 측면은 운영자에게 생산 문제를 신속하고 효율적으로 디버그할 수 있는 세분화된 정보를 제공하는 것입니다. 이 영역에서는 많은 움직임과 혁신을 볼 수 있습니다. ‘가관측성의 3가지 기둥’ 즉, 메트릭, 로그 및 애플리케이션 추적에 대해 꽤 많은 논의가 이루어지고 있습니다. 또한 패치워크 도구를 사용하여 이러한 모든 세분화된 데이터를 수집하는 것이 꼭 실행 가능하지는 않으며 많은 경우 비용 효율적이지도 않다는 점도 알려져 있습니다. 

가관측성의 '기둥'

이러한 데이터 수집 측면을 좀 더 자세히 살펴보겠습니다. 오늘날 일반적으로 발생하는 현상으로는 메트릭을 하나의 시스템(보통 리소스 모니터링을 위한 시계열 데이터베이스 또는 SaaS 서비스)으로 수집하고, 로그를 두 번째 시스템(예상되듯이, 대화에 ELK 스택이 많음)으로 수집하며, 세 번째 도구를 사용하여 애플리케이션에서 요청 수준 추적을 제공하는 것입니다. 알림이 발생할 때 서비스 수준의 위반이 나타나면, 운영자는 자신의 시스템으로 달려 들어가 할 수 있는 최선의 ‘회전 의자 통합’(swivel chair integration)을 수행합니다. 즉, 하나의 브라우저 창에서 메트릭을 검토하고, 이를 다른 창에서 수동으로 로그에 연결시키고, 세 번째 창에서(해당하는 경우) 그 흔적을 추적합니다.

이러한 접근법에는 몇 가지 단점이 있습니다. 첫째, 서로 다른 데이터 소스를 수동으로 연결시키는 것은 모두 동일한 사례를 통해 서비스 저하 또는 운영 중단 시 귀중한 시간을 낭비하게 합니다. 둘째, 3개의 서로 다른 운영 데이터 저장소를 유지 관리하는 데 드는 운영 비용이 상당한 부담이 됩니다. 라이선스 비용, 각각의 운영 도구를 담당하는 별도의 관리자 인원, 각 데이터 저장소의 일관되지 않은 머신 러닝 기능, 경고를 위해 서로 다른 의미 체계를 고려해야 하는 ‘헤드스페이스’ 등이 이에 해당됩니다. 제가 이야기를 나눈 모든 기업이 이러한 문제로 어려움을 겪고 있습니다.

이 모든 정보를 단일 운영 저장소에 저장하고 직관적인 사용자 인터페이스에서 이러한 데이터를 자동으로 상호 연관시킬 수 있는 기능을 갖추는 것이 얼마나 중요한지에 대한 인식이 높아지고 있습니다. 우리가 이야기를 나눈 사용자들은 애플리케이션에서 내보낸 로그 줄, 계측 도구에서 생성된 추적 데이터, 시계열 메트릭으로 표시된 리소스 사용률 등 지원하고 있는 서비스와 관련된 데이터의 모든 요소를 운영자가 통합된 방식으로 볼 수 있기를 원합니다. 우리에게 쏟아지는 요청 사항은 검색 및 필터링부터 집계, 시각화에 이르기까지 소스와 관계없이 이러한 데이터에 대한 일관된 임의 액세스를 강조하고 있습니다. 메트릭으로 시작하여 컨텍스트를 전환하지 않고 클릭 몇 번으로 로그 및 추적으로 드릴다운할 수 있다면 조사를 가속화할 수 있습니다. 마찬가지로, 정형 로그에서 숫자 값을 추출하는 것은 메트릭과 놀라운 정도로 비슷하며, 이 둘을 나란히 시각화하는 것은 운영 측면에서 엄청난 가치를 제공합니다.

앞서 언급한 바와 같이 단순한 데이터 수집은 디스크에 너무 많은 정보가 쌓이는 결과를 가져오며 문제 발생 시 실행 가능한 인텔리전스는 정작 부족한 상황이 됩니다. 운영 데이터를 수집하는 시스템이 시계열 패턴에서 ‘관심 있는’ 이벤트, 추적 및 이상 징후를 자동 탐지하는 기능을 제공할 것이라는 기대가 점점 더 커지고 있습니다. 이는 문제를 조사하는 운영자가 근본 원인을 신속하게 파악하는 데 도움이 됩니다. 이러한 이상 징후 탐색 기능을 ‘가관측성의 4번째 기둥’이라고 부르기도 합니다. 가동 시간 데이터, 리소스 사용률 및 로깅 패턴에서 이상 징후를 탐지하고 가장 관련성이 높은 추적을 탐지하는 기능이 가관측성 팀에서 제시하는 새로운 요구 사항입니다.

가관측성...그리고 ELK Stack?

그렇다면 가관측성은 Elastic Stack(또는 운영 분야에서 부르는 애칭인 ELK Stack)과 어떤 관계가 있을까요?

ELS Stack은 운영 시스템의 로그를 중앙 집중화하는 실질적인 방법으로 널리 알려져 있습니다. 이는 Elasticsearch가 자유 텍스트 검색을 위해 텍스트 기반 로그를 저장하기에 좋은 시스템이라는 가정을 기반으로 합니다. 그리고 실제로, 간단하게 ‘오류’라는 단어로 텍스트 기반 로그를 검색하거나 잘 알려진 태그 세트를 기반으로 로그를 필터링할 수 있다는 것은 매우 강력한 기능이며 대부분 사용자가 처음 시작할 때 사용하는 기능이기도 합니다.

그러나 대부분의 ELS Stack 사용자가 알고 있듯이 데이터 저장소로서의 Elasticsearch는 효율적인 전체 텍스트 검색 및 간단한 필터링 기능을 위한 역색인 그 이상의 기능을 제공합니다. 또한, Elasticsearch에는 고밀도 숫자 시계열을 저장 및 운영하는 데 최적화된 열 기반 저장소가 포함되어 있습니다. 이 열 기반 저장소는 구문 분석된 로그에서 추출된 정형 데이터(스트링과 숫자 모두)를 저장하는 데 사용됩니다. 사실, 우리가 숫자의 효율적인 저장 및 검색을 위해 Elasticsearch를 최적화하도록 동기를 부여한 것이 로그를 메트릭으로 변환하는 사용 사례입니다.

시간이 지나면서 사용자들은 숫자 시계열을 기존 시계열 데이터베이스 대신 Elasticsearch에 직접 저장하기 시작했습니다. 이러한 요구에 부응하여 Elastic에서는 최근에 데이터 저장소와 UI에서 메트릭 자동 수집, 자동 롤업 개념, 기타 메트릭별 기능을 제공하는 Metricbeat를 출시했습니다. 그 결과, 로그용으로 ELS Stack을 도입한 사용자 중에서 리소스 사용률과 같은 메트릭 데이터를 Elastic Stack에 저장하는 사용자가 점점 더 증가하고 있습니다. 위에 이미 언급한 운영 비용 절감 외에도, Elasticsearch가 숫자 집계가 가능한 필드의 카디널리티에 제약(기존 시계열 데이터베이스를 논의할 때 흔히 제기되는 불만)을 많이 두지 않는다는 것이 사용이 증가한 매력적인 이유의 하나입니다.

메트릭과 마찬가지로, 가동 시간 데이터는 로그와 더불어 매우 중요한 데이터 유형으로, 활성 모니터에서 SLO/SLI 경고의 중요한 소스를 나타냅니다. 가동 시간 데이터는 종종 사용자가 그 영향을 느끼기 전에 서비스, API 및 웹 사이트의 성능 저하에 대한 정보를 제공할 수 있습니다. 그뿐만 아니라 가동 시간 데이터는 스토리지 요구 사항 측면에서 용량이 미미하기 때문에 아주 약간의 비용 추가로 상당한 가치를 확보할 수 있습니다.

또한, Elastic은 작년에 Elastic APM을 출시하여 스택에 애플리케이션 추적 및 분산 추적 기능을 추가했습니다. 여러 오픈 소스 프로젝트와 주요 APN 공급업체에서 이미 Elasticsearch를 사용하여 추적 데이터를 저장 및 검색하고 있었기 때문에 이는 우리에게 당연한 결과였습니다. APN 추적 데이터를 로그 및 메트릭과 별도로 유지하여 운영 데이터 사일로를 지속시키는 것이 기존 APM 도구의 현재 상태입니다. Elastic APM은 지원되는 언어 및 프레임워크에서 추적 데이터를 수집하고 OpenTracing을 지원하는 일련의 에이전트를 제공하며, 이러한 추적 데이터를 자동으로 메트릭 및 로그와 상호 연관시킵니다.

이러한 모든 데이터 입력 전체에서 공통 스레드는 각각이 Elasticsearch의 또 다른 인덱스라는 것입니다. 이러한 데이터에서 실행되는 집계, Kibana에서 이를 시각화하는 방법, 경고와 머신 러닝이 각 데이터 소스에 적용되는 방법에는 어떠한 제약도 없습니다. 실제 작동하는 모습을 보려면 이 동영상을 확인하십시오.

관측 가능한 Kubernetes 및 Elastic Stack

가관측성 개념이 매우 활발하게 논의되는 커뮤니티 중 하나가 컨테이너 오케스트레이션을 위해 Kubernetes를 도입한 사용자 그룹입니다. CNCF(Cloud Native Computing Foundation)에 의해 대중화된 용어인 ‘클라우드 네이티브’ 사용자는 고유한 문제에 직면해 있습니다. 즉, 모놀리식 앱을 ‘마이크로서비스’로 분리하는 추세와 더불어 Kubernetes 기반 컨테이너 오케스트레이션 플랫폼에 구축되거나 마이그레이션된 애플리케이션 및 서비스의 대규모 중앙 집중화에 직면해 있습니다. 지금까지 이러한 인프라에서 실행되는 애플리케이션에 대해 필요한 가시성을 제공해주던 도구와 방법이 더는 그 성능을 발휘하지 못합니다.

Kubernetes 가관측성은 그 자체로 별도의 게시물에서 다뤄야 하므로 지금은 관측 가능한 Kubernetes 웨비나와 Elastic APM을 사용한 분산 추적 블로그 게시물에서추가 정보를 확인하십시오.

이제 그다음은?

이런 게시물에서는 독자에게 살펴볼 수 있는 리소스를 몇 가지 남겨두는 것이 적절할 것 같네요.

가관측성 모범 사레에 대해 자세히 알아보려면 위에 언급한 Google SRE Book으로 시작하는 것이 좋습니다. 중요한 앱을 프로덕션에서 원활하게 운영하는 것이 생존을 좌우하는 기업의 블로그 게시물 또한 시사하는 바가 큽니다. 예를 들어 Salesforce Engineering의 이 최근 게시물은 가관측성 상태를 반복적으로 개선하는 데 도움이 되는 실용적이고 실질적인 안내서라고 생각합니다.

가관측성 이니셔티브를 위해 Elastic Stack 기능을 사용해 보려면 Elastic Cloud 샌드박스(궁극적으로 자가 관리형을 배포하는 경우에도 매우 훌륭한 샌드박스)의 Elasticsearch Service에서 최신 버전의 스택을 구동하거나, Elastic Stack 구성 요소를 로컬에 다운로드하여 설치하십시오. 일반적인 가관측성 워크플로우에 맞춰 특별히 구축된 Kibana의 새로운 로그, 인프라 모니터링, APM 및 가동 시간(6.7에서 제공 예정) UI를 확인하시기 바랍니다. 그리고 질문이 있으시면 언제든 토론 포럼에 글을 남겨주십시오. 저희가 도와드리겠습니다!