Ari Hermawan イベントドリブン型になるには、その一環として、ロギングインフラストラクチャをイベント対応にして、そのメリットを最大限に活用できるようにする必要があります。Solace がロギングにどのように役立つか、Logstash を Solace と統合する方法についてのブログ記事をお読みください。これらの記事では、ロギングに Elastic Stack のようなものをまだ使用していないことを前提としています。しかし、もし使用しているとしたらどうでしょうか？その場合については、組み込みのログアグリゲーターと検索スタックを提供するコンテナプラットフォームにアプリケーションがデプロイされている例を提示することで、この記事の中で説明したいと思います。
コンテナプラットフォームがある場合
アプリケーションログが一元化されたログシステムにストリーミングされるアーキテクチャの具体例を見てみましょう。このサンプルでは、マイクロサービスはコンテナとしてデプロイされます。このようなコンテナには、Docker 環境または Red Hat OpenShift Container Platform（OCP）や Google Kubernetes エンジン（GKE）、その他の多くのディストリビューションなどの Kubernetes 環境が考えられます。
Kubernetes クラスターレベルロギング
Kubernetes プラットフォームの場合、一部のディストリビューションはクラスターレベルのロギング用のネイティブソリューションを提供しますが、そのような機能はいつでも自分で構築できます。すべてのノードで実行されるノードレベルのロギングエージェントを使用することも、アプリケーションごとにサイドカーポッドを使用することもできます。Kubernetes クラスターレベルのロギングの詳細については、Kubernetes ロギングドキュメントを参照してください。
図 1: Kubernetes クラスターレベルロギングの簡略図
上の図では、すべてのワーカーノードで実行され、それらのログを Elastic Stack に転送するロギングエージェントとして fluentd を使用しています。これらはログをストリーミングし、一元化されたログサーバーを使用していますが、これは本当にイベントドリブン型なのでしょうか？
欠けているもの
IT 管理者が、単一のウェブページから Kubernetes クラスター全体のログの完全なセットに対してクエリを実行できるのは素晴らしいことです。また、アプリケーション開発者が、統一された一元的な方法でログを書き込んだり送信したりするためのアプリケーションの開発について心配する必要がないのも嬉しいポイントです。ただ、ログデータにアクセスできるのは、ログダッシュボードからのみとなります。人には読みやすいですが、他のシステムにはリアルタイムではアクセスできません。
Elastic Stack は、技術者がログを掘り下げてエラーを見つけたり、インシデントを調査したりするための優れたログツールを提供します。また、顧客からのクレームがあったときに、特定のトランザクションを追跡するのにも非常に便利です。ただし、カスタマーサービス担当者は通常、このシステムにアクセスできません。アクセスできたとしても、ログに表示されるわかりづらい内容では、あまり役に立たないでしょう。
これらのログを、各受信者にとって役立つ方法で企業全体にリアルタイムでストリーミングできるとしたらどうでしょうか？カスタマーサービスなどの特定のシステムが、特定のタイプのイベントをサブスクライブできるとしたらどうでしょうか？今後開発される新しいシステムでは、ログのストリームを簡単にサブスクライブでき、アドホックアプリケーションなどの関連情報をリアルタイムで取得できます。さらに良いことに、多くの言語やオープン標準のプロトコルで行うことができます。
イベント対応の Kubernetes クラスターレベルのロギング
ついに、ロギングクラスターの一部として Elastic Stack を利用できるようになりました。私たちが考える、イベントに対応したロギングとは、Elasticsearch ログストアだけでなく、企業内の他のシステムからこれらのログイベントにアクセスできるようにすることです。そして、それを実現するには、ログイベントを Solace PubSub+ Event Broker に公開する以上に良い方法などないと思います。
Solace PubSub+ Event Broker へのイベントの公開は、サポートされている多くのネイティブでオープン標準のメッセージング API とプロトコル、さらに REST を使用して実行できます。Webhook のようなものをお考えの場合、Elasticsearch が提供している Webhook アクション機能があります。しかし、それは最良の方法ではありません。その理由は 2 つあります。
- 「公開」は Elasticsearch によって行われますが、イベントを直接持っているログコレクターとして、fluentd に公開を行わせる方が良いと思います。
- Elasticsearch アクションは、ウォッチャーに設定された所定の条件が満たされた場合にのみ実行されます。私の理解では、ウォッチャー機能は無料では利用できません。
では、より良い代替手段は何でしょう。イベントは、ログストアからではなく、ログコレクターから直接発行する必要があると思います。そのため、fluentd に注目しました。MQTT を使用してイベントを SolacePubSub+ に発行することにしました。このブログでは、MQTT プラグインを使用します。一部のディストリビューションのネイティブクラスターレベルのロギング機能では、ロギングコレクターコンポーネントへの変更をサポートしていない場合があります。
Kubernetes クラスターの外に、独自の専用 Elastic Stack を持つという考え方が私は良いと思います。これは通常、Elastic Stack のエンタープライズライセンスを購入したお客様、より大きな容量を必要とするお客様、または単に既存のスタックを持っているお客様が行います。その後、この単一の外部 fluentd から Solace PubSub+ にイベントを発行する必要があります。このアプローチについては、次の図を見てみましょう。
図 2: イベント対応の Kubernetes のクラスターレベルのロギング
イベントドリブン型アーキテクチャの中心となるトピックルーティング
トピックを語らずに、イベントドリブン型アーキテクチャについて話すことはできません。トピックルーティングは、Solace PubSub+ Event Broker が行っていることの中心です。これにより、システム間のイベントを効率的かつエレガントにルーティングすることが可能になり、Event Meshと呼ばれる動的ネットワークを構築するために必要な重要な機能も得られます。詳細については、資料「トピックを理解する」 を参照してください。
では、特定のトピックを持つ Solace PubSub+ Event Broker にログを発行します。Solace PubSub+ でトピックについて話すとき、私が「トピックへ」ではなく「トピックと共に」と言っていることに注意してください。これは、トピックがメタデータであり、ブローカーに送信するメッセージの一部であるためです。トピックは事前に作成する必要があるものではありません。これは柔軟性に優れた、パフォーマンスの高い Event Broker を持つために重要です。私の友人である、Aaron のビデオ「Solace トピックのすべて」をぜひご視聴ください。
To be able to publish to specific topic, we have options to set it up in the log collector itself or later in the MQTT output plugin. Or better yet, you can customize both to get your best fit solution. The idea here is to make sure we have a good design on the topic hierarchy to gain most benefit of these events. Take a look at this blog post for Solace’s best practices on topic architecture or these technical documents for a deeper dive.
Docker コンテナと Kubernetes プラットフォームについてお話ししましたが、 ここでは、Docker ログドライバーでタグをカスタマイズする方法を簡単に説明します。カスタマイズすると、静的トピック階層だけでなく、特定のコンテナ用の特別なテンプレートマークアップも指定できます。Kubernetes の場合は、配信のドキュメントを見る必要がありますが、Docker と非常によく似ていると思います。
このブログで使用している MQTT出力プラグインもリンクしました。ここでは、別の Docker コンテナとして実行されている Solace PubSub+ Event Broker に発行するように構成された MQTT 出力プラグインで fluentd を使用してコンテナを実行するプロジェクトの例を示します。別のトピックを発行する場合は、topic_rewrite_pattern オプションと topic_rewrite_replacement オプションに注意してカスタマイズしてください。
トピック階層を使用すると、イベントサブスクライバーは、ニーズに基づいてフィルタリングされた特定のイベントをサブスクライブできます。トピックルーティングを行うだけでよいため、サブスクライバー側でロジックやフィルタリングの手間が省けます。たとえば、複数のクラスタと複数のアプリケーションがある場合、サブスクライバーはクラスターの場所に関係なく、特定のクラスターのみをサブスクライブしたり、特定のアプリケーションのみをサブスクライブしたりできます。
プロジェクトの例では、acme/clusterx/appz/<container id> のサンプルタグを使用しています。この場合、サブスクライバーは acme/clusterx/> をサブスクライブして、クラスター X からすべてのログイベントを取得するか、acme/*/appz/> をサブスクライブして、任意のクラスターからのアプリケーション Z のログイベントをサブスクライブできます。トピック階層の一部である場合は、特定のログレベルをサブスクライブすることもできます。ブローカーでトピックを事前に定義する必要はありません。これを Event Mesh と共に使用すると、さらに効果的です。
イベントメッシュとは、分散型のアプリケーションや各種クラウドサービス、デバイス間でのイベント配信を実現する柔軟で動的なインフラストラクチャレイヤーです。これにより、イベント通信を、高い柔軟性と信頼性で、迅速に管理できます。イベントメッシュは、相互接続されたイベントブローカーのネットワークを介して作成および有効化されます。言い換えれば、1 つのアプリケーションからのイベントを、他のアプリケーションがデプロイ先（クラウド、プライベートクラウド、パブリッククラウド）に関係なく動的にルーティングおよび受信できるようにするアーキテクチャレイヤーです。このレイヤーは、イベントブローカーのネットワークで構成されています。
つまり、複数のサイト/環境をまたぎ、オンプレミスまたはクラウドで、および多くのスタックおよびオープン標準の API/プロトコルを使用して動的にトピックルーティングが行われます。
イベントメッシュ
イベントを Solace PubSub+ に公開して Kubernetes クラスターのロギングをイベント対応にすると、ログイベントは、企業全体に加え、クラウド環境全体の外部システムのイベントにもリアルタイムでアクセスできるようになります。
メリットを享受する最初のシステムは、カスタマーサービスアプリケーションです。このアプリケーションは、アプリケーション自体の容量内で確実にログイベントを消費できるようになります。ブローカーは、受信ログイベントのトラフィックが突然増加した際の緩衝材として機能し、アプリケーションがしばらくの間停止または切断された場合に、イベントを安全に保存します。
イベントメッシュでイベントが使用できるようになったので、拡張し、さらに多くのシステムにこれらのイベントをサブスクライブさせることができます。Solace ネイティブ API（SMF）、レガシー Java エンタープライズアプリ用の JMS、Webhook、さらには Kafka コネクタも使用できます。サブスクライブは同じデータセンター上、またはクラウド上の場所から行うことができます。
イベントメッシュを使用すれば、これらのシステムはどこからでも動的にイベントをサブスクライブでき、メッシュはイベントをルーティングします。固定されたポイントツーポイントのステッチングは必要ありません。また、誰もサブスクライブしていない場合に、マルチクラウド環境間でイベントを同期するための無駄な帯域幅も発生しません。
結論: Kubernetes クラスターレベルのロギングと Elastic Stack
Kubernetes クラスターレベルのロギングや Elastic Stack などの一元的なロギングシステムを持つことの短所、そしてイベント対応にしてエンタープライズログのさらなる可能性を実現する方法について説明しました。Solace PubSub+ によって提供される独自のイベントメッシュ機能は、これをさらに拡張します。このアイデアがお客様の興味と好奇心を刺激し、お客様が自身のシステムをイベント対応にし、イベントドリブン型アーキテクチャのメリットを享受できることを願っています。何をためらっているのですか？Solace 開発者に連絡し、Solace PubSub+ と Elastic Stack を使用して、自身のイベントドリブン型ロギングの作成を開始しましょう。