ストリーミング領域におけるマイクロサービスとは

分散化を採用してサービスベースのシステムを開発し，ストリーム処理ツールを使って状態分散の問題にアタックせよ – 先日のQCon Londonカンファレンスで行ったプレゼンテーションの中で，Ben Stopford氏はこのように主張した。

ConfluentでKafkaを扱うStopford氏にとって，サービスベースシステムや疎結合，コンテキスト境界(bounded contexts)，スケーラビリティ，ease-of-scaleなどを使うべき理由はたくさんある – すべては時間とともに進化するシステム構築のためなのだ。しかしながらそれは，本質的には分散システムの構築でもあるので，レイテンシや故障などといった分散システム独特の複雑性も同時に抱えることになる。

分散システムの基本的なパターンとして，氏は以下の２つを挙げる。

• リクエスト–レスポンス サービスを分離する方法のひとつで，一般的にRESTが使用される。UIや問い合わせなどの処理と親和性が高い。
• イベント駆動 非同期ないし“ファイア・アンド・フォーゲット”メッセージングとして特徴付けられる。サービス間の複雑な依存性を構成する場合に有効である。

RESTインターフェースにはリクエスト–レスポンス，バックグラウンド処理にはイベントというように，これらを組み合わせることも可能だ。

キューを使用するようなイベントベースの非同期通信について，氏は，極めてシンプルなモデルだと説明している。一度にひとつのメッセージのみ取り出すのであれば，メッセージの順序を保証することも可能だ。このモデルでは，順序を保証しながら，ある程度まで拡張することは可能だが，氏の指摘によれば，ある時点に達すると可用性も順序の保証も失われてしまう。またメッセージがトランジェントであるがため，障害の発生時に時間的に前に戻って古いメッセージを読み返すことができない点についても，氏はもうひとつのデメリットとして指摘している。

Stopford氏は，Kafkaなどを導入して，サービスのバックボーンとして分散ログを用いるアプローチの方がより優れているのではないか，と考えている。Kafkaは，追加のみのデータ構造を持ったログの概念に基づいているため，読み込みと書き込みのいずれも効率的に行なうことができる。読み込みはある一点に位置決めしてシーケンシャルに読み込めばよいし，書き込みは単に追加するだけだ。

分散ログをマイクロサービスに採用するメリットとしては，次のようなものがある。

• 常にオンである – Kafkaなどのフォールトトレラントブローカが処理を行なう。
• ロードバランシング – ブローカから個々にデータ読み込みを行なうサービス間において。
• フォールトトレラント – サービスがフェールオーバしてもメッセージ順序は保持される。
• リワインドとリプレイ – 古いメッセージに戻ってリプレイすることが可能。例えばエラーを検出後に修正できる。

解決すべき問題のひとつは，サービスの一貫性の維持だ。フェール後などに発生するメッセージ(“少なくとも１回”配信される)の重複を回避することが困難なため，サービス側で受信したメッセージのべき等性(idempotence)を保証して，“正確に１回”という配信メカニズムを論理的に構築する必要がある。Stopford氏によると，これはまだKafkaでは実現できていない(作業進行中である)ということだ。

同じカンファレンスでMartin Kleppmann氏が，サービスの一貫性の問題を自身のプレゼンテーションで取り上げている。

Stopford氏のプレゼンテーションの内容は，QCon参加者にはすでに公開されており，InfoQの読者にも近日中に提供される予定である。プレゼンテーションで使用されたスライド資料も，氏自身によって公開されている。