Ari Hermawan 이벤트 중심의 이익을 최대한 누리려면 로깅 인프라가 이벤트를 허용하도록 만들어야 합니다. 로깅에 Solace 활용하는 방법과 Logstash를 Solace에 통합하는 방법에 대한 블로그 글을 썼습니다. 아직 로깅에 Elastic Stack와 같은 것을 사용하지 않는 분들을 염두에 두고 쓴 글입니다. 이미 사용하고 계신가요? 이 포스팅을 통해 답하고 싶은 질문이 바로 그것입니다. 내장형 로그 수집기와 검색 스택을 제공하는 컨테이너 플랫폼에서 어디에 애플리케이션이 배포되는지 사례를 보여 드리겠습니다.
컨테이너 플랫폼 사례
애플리케이션 로그가 중앙 집중형 로그 시스템과 이어져 있는 아키텍처 예를 구체적으로 살펴봅시다. 이 예시에서는 마이크로서비스가 컨테이너로 배포되어 있습니다. 이 컨테이너는 도커 환경, Red Hat OpenShift Container Platform(OCP) 같은 쿠버네티스 환경, Google Kubernetes Engine(GKE) 등 여러 가지 배포 서비스가 될 수 있습니다.
쿠버네티스 클러스터 수준 로깅
쿠버네티스 플랫폼을 위해 클러스터 수준 로깅을 위한 네이티브 솔루션을 제공하는 배포 서비스들도 있지만, 그런 기능을 직접 구축할 수도 있습니다. 모든 노드에서 작동하는 노드 수준의 로깅 에이전트를 사용하거나 각 애플리케이션에 사이드카 파드를 사용하시면 됩니다. 쿠버네티스 클러스터 수준 로깅에 대해 더 알아보려면 쿠버네티스 로깅 기록을 참고하세요.
위 일러스트는 Fluentd를 모든 워커 노드에서 작동하면서 그 로그들을 Elastic Stack에 전달하는 로깅 에이전트로 사용합니다. 따라서 이들이 로그를 스트리밍하고 중앙 집중형 로그 서버를 가지고 있는 것은 맞지만, 진정한 이벤트 중심 상태일까요?
빠져 있는 조각
IT 관리자 입장에서는 단일 웹페이지의 쿠바네티스 클러스터 전체에서 로그 전체 세트에 대해 질의를 할 수 있으면 좋습니다. 그리고 애플리케이션 개발자 입장에서는 통일되고 중앙 집중화된 방식으로 로그를 작성하고 전송하는 애플리케이션을 개발해야 하는 걱정을 하지 않으면 좋습니다. 하지만 지금은 로그 데이터에 접근하려면 로그 대시보드로 가야만 합니다. 사람들이 읽기는 쉽지만 다른 시스템에 실시간으로 접속하기는 어렵습니다.
Elastic Stack은 기술인들이 오류를 찾거나 사고를 조사하기 위해 로그를 분석할 때 유용한 로깅 도구를 제공합니다. 고객이 불만을 제기한 거래 건을 따로 추적할 때도 아주 유용합니다. 하지만 고객 서비스는 시스템에 접근할 수 없는 경우가 많고, 로그에는 복잡한 디테일이 가득해서 그다지 유용하지 못할 수도 있습니다.
그런 로그들을 전사적으로 실시간으로 스트리밍해서 데이터를 받는 사람들이 각각 유용하게 사용할 수 있게 하는 건 어떨까요? 고객 서비스 같은 특정 시스템이 특정 이벤트 유형을 구독할 수 있으면 어떨까요? 미래에 개발되는 새 시스템들에서는 로그 스트림을 쉽게 구독하고, 애드혹 애플리케이션을 비롯한 관련 정보를 식시간으로 볼 수 있을 것입니다. 심지어 여러 언어를 제공하고 표준 프로토콜을 열 수도 있습니다.
이벤트 허용 쿠버네티스 클러스트 수준 로깅
이제 로깅 클러스터에 Elastic Stack이 생겼습니다. 우리가 생각하는 이벤트 허용 로깅은 이러한 로그 이벤트들을 Elasticsearch 로그 스토어만이 아닌 사용자의 기업 내 다른 시스템들에서 접속 가능하게 만드는 것입니다. 그렇다면 Slace PubSub+ Event Broker에 로그 이벤트를 발행하는 것만큼 좋은 방법도 없을 것입니다.
Solace PubSub+ Event Broker에 이벤트를 발행하려면 네이티브 및 공개 방식으로 지원되는 다양한 표준 메시징 API와 프로토콜, REST를 이용할 수 있습니다. 웹후크 같은 것을 원하시면 Elasticsearch가 제공하는 웹후크 액션 기능도 있습니다. 하지만 이 방법은 두 가지 면에서 아쉽습니다.
- ‘발행’을 Elasticsearch가 하지만, 저는 이벤트를 직접 보유한 로그 수집가인 fluentd가 발행을 하는 편이 낫다고 생각합니다.
- Elasticsearch Actions은 Watchers에서 설정된 조건이 맞아야만 실행됩니다. 그런데 제가 알기로 Watcher 기능은 무료가 아닙니다.
그렇다면 더 좋은 대안은 무엇일까요? 저는 로그 스토어를 거치지 않고 로그 수집기에서 바로 이벤트를 발행하시기를 권하고 싶습니다. 그래서 fluentd를 눈여겨보고 있었습니다. 저는 Solace PubSub+에 이벤트를 발행할 때 MQTT를 사용하기로 했고, 이 블로그에는 이 MQTT 플러그인을 사용하려고 합니다. 네이티브 클러스터 수준의 로깅 기능에서 로깅 수집기 요소의 변경 사항을 지원하지 않는 배포 서비스도 있으니 유의하세요.
저는 쿠버네티스 클러스터 외부에 자체적으로 전용 Elastic Stack을 두시기를 추천합니다. 보통 Elastic Stack의 기업용 라이선스를 직접 구매하거나, 훨씬 큰 용량이 필요하거나, 기존 스택이 있는 고객사들이 이런 방식을 택합니다. 이렇게 되면 하나의 외부 fluentd에서 Solace PubSub+으로 이벤트를 발행하기만 하면 됩니다. 다음에 나오는 그림을 살펴봅시다.
이벤트 중심 아키텍처 중심에서의 토픽 라우팅
이벤트 중심 아키텍처를 이야기할 때 빠질 수 없는 것이 토픽입니다. 토픽 라우팅은 Solace PubSub+ Event Broker가 하는 역할의 중심에 있습니다. 시스템 간 이벤트 라우팅이 효율적으로 우아하게 이루어지게 해 주는 것은 물론, 이벤트 메쉬라고 부르는 역동적 네트워크를 구축할 때도 꼭 필요한 기능입니다. ’토픽 이해하기’ 문서에서 더 자세히 알아보세요.
이제 로그를 특정 토픽과 함께 Solace PubSub+ Event Broker에 발행해봅시다. Solace PubSub+에서는 토픽’에’ 올리는 것이 아니라 토픽’과 함께’ 올린다는 점을 기억하세요. 이 토픽들은 우리가 브로커에게 보내는 메시지의 일부인 메타데이터이기 때문입니다. 미리 만들어 놓을 필요가 없습니다. 이벤트 브로커의 유연성과 성능을 높이는 핵심이 바로 이것입니다. 저의 동료 Aaron의 ‘Solace 토픽에 대한 모든 것’이라는 동영상을 시청해 보세요.
특정 토픽에 발행하려면 로그 수집기에서나 이후 MQTT 출력 플러그인에서 설정할 수 있습니다. 아니면 둘 다 원하는 대로 설정해서 최적의 솔루션을 찾으실 수도 있습니다. 토픽 구조에서 적절한 설계를 통해 이벤트의 장점을 최대한 많이 끌어내기 위한 방식입니다. 더 자세한 내용이 궁금하시면 이 블로그에서 Solace의 토픽 아키텍처 관련 모범 실무와 기술 문서를 읽어 보세요.
지금까지 Docker 컨테이너와 쿠버네티스 플랫폼에 대해 이야기했습니다. 여기에서 기록된 Docker 로그 드라이버에서 태그를 맞춤 설정하는 방법도 빠르게 짚고 넘어가 보겠습니다. 태그를 설정하면, 고정된 토픽 구조를 명시하고 특정 컨테이너를 위한 특별 템플릿 마크업을 할 수 있습니다. 쿠버네티스의 경우 배포 문서를 보셔야 하지만, Docker와 굉장히 비슷하지 않을까 합니다.
제가 이 블로그에서 사용 중인 MQTT 출력 플러그인도 링크해 놓았고, 다른 도커 컨테이너로서 작동하는 Solace PubSub+ Event Broker에 발행하도록 설정된 MQTT 출력 플러그인과 함께 fluentd를 사용해서 컨테이너를 운영하는 프로젝트 예시도 소개합니다. 다른 토픽에 발행하려면 topic_rewrite_pattern 및 topic_rewrite_replacement 옵션에 신경 쓰세요.
토픽 구조가 있으면, 이벤트 구독자가 자신의 필요에 따라 특정하게 필터링된 이벤트를 구독할 수 있습니다. 구독자 측에서 논리를 적용하거나 필터링할 필요 없이 토픽 라우팅만으로 간단하게 수행할 수 있는 작업입니다. 예를 들어 클러스터와 애플리케이션이 여러 개인 경우, 구독자는 클러스터의 위치에 관계없이 하나의 클러스터나 특정 애플리케이션들만 구독할 수 있습니다.
프로젝트 예시에서는 acme/clusterx/appz/<container id>>를 예시 태그로 사용합니다. 이런 경우, 구독자는 acme/clusterx/>를 구독해서 X 클러스터에서 나온 모든 로그 이벤트를 얻거나, acme/*/appz/>를 구독해서 모든 클러스터에서 나온 앱 Z 로그 이벤트를 구독할 수 있습니다. 토픽 구조의 일부를 이루는 로그 수준이 있으면, 그 로그 수준을 구독할 수도 있습니다. 브로커에서 토픽을 미리 지정해 두지 않고도 가능합니다. 이벤트 메쉬까지 함께 사용하면 더 훌륭합니다.
이벤트 메쉬는 비결합 애플리케이션, 클라우드 서비스, 기기들 사이에서 이벤트를 배포하도록 설정할 수 있는 동적인 인프라 레이어입니다. 이벤트 메쉬를 이용하면 이벤트 통신이 유연하고 안정적인 상태가 되며 속도가 빨라지고 제어 가능해집니다. 이벤트 메쉬는 상호 연결된 이벤트 브로커들의 네트워크를 통해 생성되고 활성화됩니다. 다시 말하자면, 이벤트 메쉬는 애플리케이션의 위치에 관계없이(클라우드, 비공개 클라우드, 공개 클라우드) 하나의 애플리케이션에서 나온 이벤트를 다른 애플리케이션이 동적으로 라우팅하고 수신할 수 있게 해 주는 아키텍처 레이어입니다. 이 레이어는 이벤트 브로커들의 네트워크로 구성됩니다.
즉, 토핑 라우팅이 여러 스택 및 개방형 표준 API/프로토콜들과 함께 여러 사이트/환경, 온프레미스, 클라우드를 동적으로 가로지른다는 의미입니다.
이벤트 메쉬
Solace PubSub+에 이벤트를 발행해서 쿠버네티스 클러스트 로깅에 이벤트를 허용하고 나면 전사적으로, 그리고 클라우드 환경 전체의 외부 시스템 이벤트에서 로그 이벤트에 실시간으로 접속할 수 있습니다.
가장 먼저 이득을 보는 시스템은 고객 서비스 애플리케이션입니다. 자체 수용력 안에서 보장된 방식으로 로그 이벤트를 소비할 수 있기 되기 때문입니다. 로그 이벤트 트래픽 유입량이 급증하면 브로커가 충격 흡수 역할을 하고, 애플리케이션이 다운되거나 접속이 끊기더라도 이벤트를 안전하게 보관합니다.
이제 이벤트 메쉬에서 이벤트를 이용할 수 있으므로, 규모를 확장해서 더 많은 시스템이 해당 이벤트를 구독하게 할 수 있습니다. Solace 네이티브 API(SMF), 레거시 자바 엔터프라이즈 앱을 위한 JMS, 웹후크, Kafka 접속기 등을 사용할 수 있습니다. 그리고 동일한 데이터센터나 클라우드 상에서 바로 구독할 수 있습니다.
시스템에 이벤트 메쉬를 보유하면 어디서나 동적으로 이벤트를 구독할 수 있고 그러한 메쉬가 이벤트들을 라우팅합니다. 고정된 점대점 스티칭이 필요 없고, 구독자가 없을 때 여러 클라우드 환경에서 이벤트들을 동기화하느라 대역폭을 낭비하지 않아도 됩니다.
결론: 쿠버네티스 클러스터 수준 로깅과 Elastic Stack
이렇게 해서 쿠버네티스 클러스터 수준 로깅과 Elastic Stack 같은 중앙 집중형 로깅 시스템을 보유하는 것의 장단점, 이벤트 허용을 통해 대규모 로그의 잠재력을 높이는 방법을 알아보았습니다. Solace PubSub+만이 제공하는 이벤트 메쉬 수용력을 이용하면 효과가 더 커집니다. 이 글이 도움이 되었기를 바라며, 여러분도 시스템에 이벤트를 허용해서 이벤트 중심 아키텍처가 약속하는 성과를 거두시면 좋겠습니다. 더 이상 망설이지 마세요. Solace 개발자에서 Solace PubSub+ 및 Elastic Stack과 함께 자체적인 이벤트 중심 로깅 구축을 시작하세요.