マイクロサービス統合に共通する落とし穴 - Bemd Rücker氏によるQCon Londonプレゼンテーションより

マイクロサービスアーキテクチャでは、すべてのマイクロサービスは独立したアプリケーションであり、独自のデータストレージを持ち、ネットワーク上で互いに通信するのが一般的だ。これは高度に分散化された環境を構築すると同時に課題も持ち合わせる — Bernd Rücker氏は、QCon London 2018で行ったプレゼンテーションでこのように説明し、マイクロサービス統合に共通する落とし穴と、その解決策として組込みあるいはサービスの形で利用可能なワークフローエンジンについて解説した。

通信

通信は複雑だが、この複雑さは隠蔽されるべきではなく、内部的に障害を処理可能なサービスを設計することが必要である。Camundaの設立者のひとりであるRücker氏は、航空機にチェックインして搭乗券を受け取ろうとした時の自身の経験を例として紹介した。その時に氏は､技術的な問題が発生したというメッセージと、後でやり直すように指示を受けた。氏の考えでは、これは悪い設計であり、サービスプロバイダの典型的な問題である。ユーザに再実行を求めるのではなく、自分自身でエラー処理を行なって、作成が完了した時点で搭乗券を送信するべきなのだ。

同じ振る舞いは、サービス対サービスの通信でも起こり得る。サービスが障害を内部的に解決できるならば、再試行して、結果が得られた時点で非同期に応答を返すべきである。これによってエラー処理がカプセル化され、APIはよりクリーンでシンプルなものになる。

Rücker氏はこれをステートフルなリトライと呼んでいる。氏の経験では、このパターンを採用しない一般的な理由は、複雑な状態管理が必要だという認識にある。このような状態は、永続化エンティティやドキュメントに保存されるのが通常だが、再試行のためにスケジューラなどのコンポーネントも必要になる。これらの詳細すべてを処理する方法として氏が推奨するのは、ワークフローエンジンを使うことだ。同時に氏は、再試行の必要性が頻繁に発生するような場合でも、エラー処理をクライアントに委ねるべきユースケースがドメイン内に存在する可能性も指摘している。

非同期性

Rücker氏によれば、非同期通信の利用には数多くのメリットがある。これはメッセージングを使用するべきだという理由でもある。その場合に発生する問題はタイムアウトだ。搭乗券の発行を待つ氏の例では、このプロセスはメッセージを使用して行われており、搭乗券のメッセージが生成されなかったり、あるいは何らかの理由で失われた場合には、障害の処理は再度ユーザに任せられることになる。サーバ側に必要なのは、メッセージの紛失や遅延を監視する何らかの方法だ。一般的にこれはメッセージングミドルウェアを使用して行われるが、Rücker氏の知る何人かの顧客は、これをワークフローエンジンを使って実装している。ただしこれには、プル原理を使用したメッセージキューのように動作するエンジンが必要だ。

分散トランザクション

分散システムでは、二相コミットを使用しない限りACIDトランザクションは機能しないが、一般的には複雑過ぎると見られているのが現状であると、Rücker氏はPat Helland氏の論文“Life Beyond Distributed Transactions: An Apostate’s Opinion”を取り上げて説明する。その代用としてRücker氏は、オール・オア・ナッシングのセマンティクスでいくつかのアクティビティを実行する必要がある場合に、長時間実行するビジネストランザクションを採用している。解決策のひとつは、複数のステップと結果整合性(eventual consistency)、障害に対する補償を使用するSagaパターンだ。

Sagaを使う場合、関係するすべてのサービスプロバイダが補償行為(compensation activities)を行うことが必要だ。さらにRücker氏は、それが冪等(idempotent)であることを強く推奨する。ネットワーク通信においては、区別することのできない3つの障害シナリオが存在する。

• 要求がサービスプロバイダに届かなかった
• 要求はプロバイダに届いたが、処理中に障害が発生した
• 要求は処理されたが、プロバイダからの応答が失われた

エラーが検出された場合の解決策のひとつは、サービスプロバイダにその要求について問い合わせることだが、そのためには、これが他の要求と区別できなくてはならない。一般的なアプローチは単に再試行することだが、そのためには要求が冪等でなくてはならない。氏は4つの冪等性に言及している。

• ニュートラル — 特定の状態を設定する場合など
• ビジネス — Eメールアドレスのようなビジネス識別子がある場合
• ユニークID — クライアントが生成する
• リクエストハッシュ — サービスがメッセージのハッシュで要求を認識する場合

Rücker氏は、ワークフローエンジンを組み込むことによってSagaパターンの実装が可能になることを述べた上で、マイクロサービスベースのシステムには一般的にはマイクロサービスごとに、それぞれのワークフローを処理する複数のエンジンが存在すると指摘している。さらに氏は、エンジンが組み込まれていることを強調する — すべてのワークフローが通過しなければならないような中央エンジンは存在しないのだ。

ワークフローエンジンとステートマシンの現状に目を転じると、いくつかのオープンソースフレームワークの存在に気付く。ここ1、2年の間でも、いくつかのフレームワークが新たに登場している。サーバレスの世界では、AWSがStep Functionsを開発しており、その他のクラウドベンダも少なくとも同じ方向で考えている。

Rücker氏は、自身のアイデアを実装したサンプルコードを公開している。このプレゼンテーションは含まれていないが、カンファレンスの大部分のプレゼンテーションは録画されており、今後数ヶ月にわたってInfoqQで公開される予定である。

次回のQConカンファレンスであるQCon.aiは、AIとマシンラーニングに重点を置くもので、2018年4月9～11日にサンフランシスコで開催される。QCon London 2019は、2019年3月4～8日に予定されている。