Elastic Stack의 알림 기능
알림은 Elastic 사용 사례의 기본입니다. Watcher(Elasticsearch를 위한 원래의 알림 기능 제품군)가 2015년에 도입된 이래, 수많은 피드백을 받았으며, 이 피드백은 알림 시스템이 어떠해야 하는지, 그리고 사용자 환경에 어떤 것들이 수반되어야 하는지를 보다 정교하게 이해하는 데 도움이 되었습니다. 이 포스팅의 목적은 우리가 알게 된 몇 가지 핵심 사항과 이것이 2019년에 우리 작업에 어떤 영향을 미쳤는지, 그리고 앞으로 Elastic Stack을 위한 알림을 어떻게 진행할 예정인지에 대해 요약해드리는 것입니다.
그동안 알게 된 사항들
Elastic의 알림은 4년 동안 알림 시스템에 대한 수많은 지식을 얻게 해주었습니다. 우리가 알게 된 사항들을 미래를 계획하는 다음 세 가지 관찰로 종합하려고 해보았습니다. 첫째, 우리는 모든 사용 사례에서 알림을 봅니다. 둘째, 우리는 여러 사용 사례에 걸쳐 알림을 이해하려고 해야 합니다. 셋째, 알림 탐색과 대응은 점점 더 정교해지고 있습니다. 이렇게 알게 된 사항들은 알림의 미래에 대한 생각으로 이어집니다.
어디서나 알림
알림은 우리의 모든 제품과 사용 사례에 걸쳐 영향을 미칩니다. 라이브 데이터가 있다면, 알림을 위한 사례가 있는 것입니다. 바로 이 때문에 우리는 Watcher를 구축했고, Watcher는 성공적이었습니다. 그러나 여러 사용 사례에 걸쳐 보자면, 모든 사용 사례에 다 맞는 알림은 없다는 것이 분명합니다.
Elastic Logs, SIEM, APM, Uptime, Infrastructure, Maps와 같은 제품에서부터 모니터링과 머신 러닝 같은 기능과 수많은 Kibana 대시보드에 이르기까지, 알림과 통지는 중요한 역할을 하지만, 상태 탐색, 상태 표현, 상황에 따른 상태 표시 등 각각 고유한 필요를 갖습니다. 효과적인 알림과 모니터링을 위해서는 제품과의 심도깊은 통합이 필요합니다. 스택과 그 사용이 진화함에 따라, Elasticsearch 알림이 각 사용 사례 내에서 견고하게 통합된, 풍부한 표현의 알림을 감안하는 보완이 필요하다는 것이 분명해졌습니다.
알림 이해하기
“어디서나 알림”의 당연한 귀결은 이러한 다른 사용 사례들이 알림을 생성하기 때문에, 알림은 그 자체의 데이터 소스가 되고 시스템과 그 상태를 이해하기 위한 기회를 만든다는 것입니다. 또는, 사이트 신뢰성 엔지니어링(SRE) 커뮤니티에서 말할 수도 있듯이, 전체적인 시스템의 가시성을 개선할 수 있는 기회가 있습니다.
각 사용 사례는 그 자체의 방식으로 데이터를 해석하고, 알림은 어떤 상황의 여러 다른 측면을 보여줍니다. 사고에 대한 올바른 대응은 전적으로 여러 소스에 달려 있으며, 여러 유형의 알림과 이벤트를 서로 연관시켜 그 상황을 이해하는 것이 중요합니다. SIEM 같은 일부 영역에서는 좀더 높은 수준의 알림이 좀더 낮은 수준의 알림의 패턴으로부터 트리거됩니다.
Elastic Stack이 점점 더 많은 사용 사례를 처리하게 되면서, 제대로 된 알림 시스템은 단지 알림을 생성할 뿐 아니라 모든 사용 사례에 걸쳐 알림을 이해하도록 도와줍니다. 예를 들어, Uptime 알림은 서비스 중단을 보여줄 수 있으며, APM 알림은 어느 트랜잭션이 그 원인이 되었는지 설명하며, 모니터링 알림은 왜 그런 일이 발생했는지를 정확히 짚어줍니다. 알림 시스템은 사람과 컴퓨터 모두에게 있어 문제에 대한 맥락을 제공하고, 상호연관성을 파악하며, 문제 인식을 개선할 수 있어야 합니다.
탐색 및 조치
“알림 이해하기”의 당연한 결과는 보다 가시성 있는 시스템으로, 한결 복잡한 상태를 탐색하고 훨씬 정교한 조치를 취할 수 있다는 것입니다. 이것은 점점 더 우리가 일반적으로 알림이라고 생각하고 있는 개념을 넘어서고 있습니다.
알림은 보통 어떤 상태를 탐색하여 사람의 주의를 끌게 하는 데 중점을 두며, 대부분 그것으로 목적을 달성하게 됩니다. 그러나 더 큰 그림을 보자면, 알림 시스템을 통제나 피드백 루프의 일환으로 생각할 수 있습니다. 관측하고, 상태를 탐색하고, 어떤 조치를 취하고, 다시 관측하는 것입니다.
현재 ‘조치’라고 하는 것은 보통 통지와 관련됩니다. 사람을 루프에 넣어서 시스템을 통제하고 문제를 정정하고자 하는 것입니다. 그러나 시스템 인사이트가 개선됨에 따라, ‘조치’는 대개 사람의 감독 하에서 훨씬 더 통제권을 가질 수 있습니다. 이것은 자동 확장, 자동 복구 및 자동 최적화 애플리케이션을 지향하는 추세에서 볼 수 있듯이, 양방향 대화(예를 들어, 챗봇)에 의해 처리되는 반 자율 시스템 또는 완전 자율 시스템일 수 있습니다.
알림 시스템은 ‘탐색’이 Elasticsearch에의 쿼리 이상이며 ‘조치’가 이메일을 보내거나 웹후크를 호출하는 이상이 되고 있음을 인정하며 정교한 탐색 및 조치를 지원해야 합니다.
알게 된 사항을 적용하기
우리는 지난 2018년 가을에 위의 세 가지 관찰을 지원하기 위해 알림이 필요하다는 결정을 내렸습니다.
또한 이렇게 하려면 Kibana에서 알림을 일급 객체로 취급하는 것이 가장 좋은 방법이 되리라는 결정도 내렸습니다.
- 어디서나 알림: 플러그인, API, UI 수준에서, 우리 전 제품에 걸쳐 풍부한 알림 통합
- 알림 이해하기: 모든 알림 유형에 걸쳐 직관적인 인터페이스 제공
- 탐색 및 조치: Kibana 플러그인을 통한 정교한 탐색 및 조치 메커니즘
우리는 또한 Watcher를 통해 알림이 프로덕션 알림 로드까지 확징되어야 하며, 고가용성과 안정성을 갖춰야 한다는 것을 알고 있습니다. 세 가지 관찰을 지원하기 위한 API, UI 및 플러그인/라이브러리 컨트랙트는 견고하고 확장 가능한 기반에서 구축되어야 합니다. 모두 종합해서 우리는 4개의 계층에 걸친 Elastic의 알림 시스템을 볼 수 있습니다.
2019년에 우리는 Kibana에서 새로운 알림 시스템의 기반을 마련해오고 있습니다.
1월에 우리는 6.7 릴리즈의 일환으로 Task Manager를 추가했습니다. 이를 통해 Kibana의 백그라운드 예약에 지속적인 작업을 부과했으며, 이 작업은 확장성과 가용성을 위해 여러 Kibana 인스턴스에 걸쳐 분산될 수 있습니다. Task Manager 같은 알림의 기본 계층 구성 요소는 단순한 알림 이상의 성능을 가질 수 있습니다. 예를 들어, Task Manager는 Kibana에서 보다 나은 예약 보고서 환경을 제공할 수 있습니다.
그리고 나서 6월에, 우리는 알림 API와 조치 API라는 새로운 두 세트의 API를 Kibana에 추가했습니다.
조치 API는 Kibana가 조치를 등록하고 작동시키게 하고, 자체적인 정의를 위한 간단한 컨트랙트를 제공하여 손쉽게 사용자 정의를 할 수 있게 합니다. 또한 초기 릴리즈에는 로깅, Slack, 이메일 통지를 위한 몇 가지 예제 조치도 포함되어 있었습니다.
알림 API는 Kibana가 ‘알림 유형’으로 탐색의 형식들을 등록한 다음, 작업 관리 시스템을 사용해 예약된 일정에 따라 이 확인을 실행하도록 할 수 있습니다. 조치처럼, 간단한 알림 컨트랙트가 있습니다. Kibana 서버에서 실행되는 JavaScript 함수에서 그것을 표현할 수 있는 경우, 알림을 지원할 수 있습니다.
Elastic Stack 7.4는 보다 낮은 수준의 알림 시스템을 작성하는 데 중점을 둡니다. 즉, 우리는 API를 강화하고, 보안 및 스페이스를 위한 지원을 추가하고, 색인, 웹후크 및 페이저 듀티 같은 몇 가지 기본 조치를 더 추가하고 있습니다.
이제 그 다음은?
Kibana의 알림 시스템 개발은 지난 몇 달 동안 한창 진행 중이며, 7.x 릴리즈 주기를 통해 계속될 예정입니다. 우리는 세 단계에 걸쳐 시스템을 배포할 계획입니다.
첫 단계는 2019년 대부분에 걸쳐 진행되며, 기반을 마련합니다. 확장 가능한 작업 관리와 일정 예약, 알림 및 조치를 위한 컨트랙트, API에 중점을 둡니다.
이제 두 번째 단계로 이동 중인데, API 및 라이브러리 수준에서 알림 시스템을 여러 다른 사용 사례가 통합할 수 있습니다. 또한 이것은 알림 이해하기와 특정한 사용 사례(예를 들어, 모니터링, 가동 시간, SIEM 등)로 이를 검증하는 일환으로 Kibana에서 UI를 설계하고 구축하는 것이 포함됩니다.
세 번째 단계는 템플릿화된 알림을 통해서든 Canvas 표현식 같은 것을 이용한 알림 기반의 표현식을 통해서든 Kibana 전체에 걸쳐 사용자 정의 알림을 가능하게 함으로써 “어디서나 알림”과 “탐색 및 조치” 주제를 확장하게 됩니다.
최종 목적은 다음과 같이 Elastic Stack에서 알림에 대한 우리의 비전을 만족시키는 시스템입니다.
- 어디서나 알림: 알림은 Kibana 내에서 일급의 공간 인식 객체입니다. 이것은 여러 그룹에 걸쳐 알림 생성 및 보기를 분할하는 것을 가능하게 하고, (몇 가지만 예를 들자면) SIEM, Monitoring, Uptime 같은 제품에서 풍부한 알림 통합을 할 수 있게 해줍니다. 알림은 Watcher를 보완하며 이와 더불어 작동하지만, 이를 대체하지는 않습니다.
- 알림 이해하기: 풍부한 알림 통합은 여러 알림 유형에 걸쳐 종합적인 보기를 제공하는 Kibana UI와 알림 기록을 상호 연관시켜 이해하기 위한 도구를 수반합니다.
- 탐색 및 조치: API와 플러그인은 Kibana 서버에서 실행되는 JavaScript에서 표현될 수 있는 경우, 탐색이나 조치 메커니즘이 무엇이나 될 수 있도록 설계됩니다. 이것은 SIEM 같은 제품이나 우리 가시성 솔루션을 통해 Kibana에서 나타나게 될 정교한 탐색과 조치를 위한 여지를 충분히 남겨줍니다.