【ITニュース解説】Why I Used Kafka for a Small Incident Management Tool

OpsFlowは、小規模な運用チームのために設計されたウェブベースのインシデント管理システムである。このツールは、システム障害などのインシデントを記録し、その重要度を割り当て、対応の期限（SLA）を追跡し、関係者にリアルタイムで通知を届けることを主な機能としている。OpsFlowは、API、フロントエンド、そして通知サービスという複数の小さなプログラム（これらを「マイクロサービス」と呼ぶ）の組み合わせで構築されており、これらのサービス間の情報伝達には「Kafka」という技術が利用されている。

マイクロサービスとは、大きな一つのシステムを、それぞれが特定の機能を持つ小さな独立したサービスの集まりとして構築する手法である。OpsFlowのような、一見するとそれほど大規模ではないツールで、複数のマイクロサービスとKafkaのような分散システムを用いることは、過剰な設計に見えるかもしれない。しかし、この設計には明確な理由と、将来的なシステムの拡張性を高めるというメリットがある。

OpsFlowの具体的な機能は多岐にわたる。例えば、チームは発生したインシデントを記録し、「緊急」や「高」といった重要度レベルを割り当てることができる。そして、その重要度に基づいて定められたSLA（サービス品質保証）の期限に対する進捗を追跡する。各組織のデータは互いに完全に分離されており、ユーザーごとに役割に応じたアクセス権限（RBAC、Role-Based Access Control）が設定されているため、誰がどのインシデントを参照したり、変更したりできるかが細かく管理される。インシデントの状態が「確認済み」「エスカレート」「解決済み」などに変更された際には、ウェブページを再読み込みするのを待つことなく、関係者に即座に通知が届けられる仕組みになっている。

OpsFlowがマイクロサービス構成を採用した主な動機は、インシデントの「通知」機能にある。インシデントの作成、参照、更新、削除といった基本的な操作（CRUD）自体は、一般的なウェブAPI（REST API）で十分に対応できる。しかし、インシデントの状態が変化するたびに、その情報は複数のチャネル（例：チャットツール、メール、プッシュ通知など）を通じて、多数の関係者に同時に配信されなければならない。この通知処理は、一時的に大量に発生することもあり、もしインシデントを管理するAPI自体がこの処理を全て担当してしまうと、APIの応答が遅くなったり、処理が滞ったりする可能性がある。

この問題を解決するため、OpsFlowでは通知処理を専門に行う「通知サービス」が分離された。インシデントの状態が変更されると、インシデントを管理するAPIは、その変更内容を「イベント」という形でKafkaに送信する。すると、通知サービスがKafkaからそのイベントを読み取り、通知の配信処理を担当する。この仕組みにより、インシデントAPIは高速かつシンプルなまま維持され、ユーザーがインシデントを報告する際の待ち時間を短縮できる。一方、通知サービスは、たとえ通知の送信が一時的に失敗しても再試行したり、複数の通知をまとめて処理したり、システムの負荷が高い場合には処理速度を調整したりといった柔軟な対応が可能になる。ユーザーはインシデントを記録しただけで、背後で複雑な通知処理が滞りなく行われていることに気づくことはない。

ここで利用されているKafkaは、大量のデータをリアルタイムで処理し、永続的に保存する分散型メッセージングシステムである。データは「メッセージ」や「イベント」としてKafkaに送られ、それがログのように記録されるのが大きな特徴だ。開発者は、OpsFlowのような小規模なツールに対してKafkaを使うのは「オーバースペックではないか」という疑問も抱いたと述べている。実際のトラフィック量から考えると、よりシンプルなRedisを使ったジョブキューでも同様の負荷は十分に処理できたかもしれないと正直に語っている。

しかし、Kafkaを選んだ真の価値は、その「永続的なログ」機能にある。通知の配信が何らかの理由で失敗した場合でも、そのイベント自体はKafkaのログにしっかりと保存されているため、データが失われる心配がない。通知サービスは、もし途中で障害が発生しても、Kafkaの特定の時点（オフセットと呼ばれる）からイベントを読み直して処理を再開できる。これは、通知が「確実に届けられたか」が極めて重要なインシデント管理において、システムの信頼性を高める上で非常に大きな利点となる。さらに、もし将来的に「誰がいつインシデントの状態を変更したか」といった監査ログを記録する別のサービスを追加したい場合でも、インシデントAPI側で何か変更を加える必要がない。新しい監査ログサービスがKafkaから既存のイベントストリームを読み取るだけで、システムを柔軟に拡張できるのだ。イベントを発行する側（プロデューサー）と、イベントを処理する側（コンシューマー）が完全に分離されているため、日々のキューの深さがたとえ小さくても、「正しい人に情報が伝わったか」という製品の核心的な部分にとって、アーキテクチャ上の明確なメリットとなる。

OpsFlowでは、役割ベースのアクセス制御（RBAC）とSLA追跡も、このイベントストリームを活用して実現されている。ユーザーの役割に応じて、インシデントの表示、重要度の変更、解決といった操作の権限が決定される。SLAの期限追跡も同様で、インシデントに割り当てられた重要度に基づいて期限が設定され、通知サービスは、期限が近づいているイベントや期限を過ぎたイベントを、他の状態変更イベントと同じようにKafkaから監視する。これにより、定期的にシステムの状態を問い合わせて確認する「ポーリング」という非効率な方法ではなく、イベントが発生したときにだけ処理を行う「イベント駆動型」のアプローチで、SLAの管理をリアルタイムかつ効率的に行うことができる。

OpsFlowは、ウェブフロントエンドにReact、モバイルアプリにReact Nativeを使用し、バックエンドAPIにはExpress.jsとTypeScriptが使われている。データはPostgreSQLデータベースに保存され、メッセージングにはKafka、キャッシュや一時的なデータにはRedisが利用され、UIにはMUIというライブラリが使用されている。これらの技術を適切に組み合わせることで、堅牢で拡張性の高いシステムが構築されている。この事例は、適切な技術選定と設計により、小規模なプロジェクトでも高品質なサービスを実現できることを示している。