マイクロサービスはサービスを細かい機能単位に分割して実装する設計・開発手法である。機能単位に分けておけば改修による影響範囲を小さくできる。ビジネスの変化に追随してシステムを頻繁に変更しなければならないDX(デジタルトランスフォーメーション)の実現にも有効だ。

 ただしマイクロサービスはアプリケーション全体から見てデータの整合を取るのが難しい。API(アプリケーション・プログラミング・インターフェース)によって他のサービスとデータをやり取りするため、サービス間で通信遅延が発生したり、エラーが発生したりする可能性を考慮した設計にしなければならないからだ。

 そこで冪等性と結果整合性が重要になる。冪等性は同じ処理を何度繰り返しても同じ結果を得られることだ。リトライ処理で2重送金などを防ぐために必要だ。一方の結果整合性は「最終的に整合が取れた状態にする」ことを指す。

 日立製作所 システム&サービスビジネス統括本部アプリケーションサービス事業部サービスソリューション本部アプリケーション共通技術統括部の須賀弓郎主任技師はマイクロサービスのような分散アーキテクチャーでは「どんな瞬間も必ず整合性が取れている状態を実現するのは難しい」と説明する。

 マイクロサービスはサービスごとにデータベースを保持し、小さなサービスが連携して処理を実現する。あるサービスのデータベースが更新されたら何らかの方法を使って他のデータベースを更新しなければならない。当然、全てのデータベースを更新・反映するには時間がかかり、一時的に不整合が発生してしまう。そこでマイクロサービスではリアルタイムにデータを更新できない代わりに、時間がたてば整合が取れた状態を保つことが重要になる。

結果整合性を保つ2つの設計パターン

 複数のマイクロサービスでデータベースの整合性を保つ場合は、障害発生やタイムアウト発生時に更新済みのデータを更新前のデータに戻すロールバックが必要だ。

 日本IBM グローバル・ビジネス・サービス事業部の前田幸一郎クラウド・アプリケーション開発担当部長は「マイクロサービスのような分散システムで結果整合性を確保するには主に2つの設計パターンがある」と説明する。1つは仮登録を行う「TCC(Try-Confirm/Cancel)パターン」。もう1つが更新済みのデータを元のデータに戻すトランザクションを用いる「Sagaパターン」である。

TCCパターンのイメージ
(日本IBMの資料を基に編集部で作成)
[画像のクリックで拡大表示]

 TCCパターンは2相コミットを利用する設計手法である。サービスを管理するオーケストレーターが各サービスに対して処理データを仮登録する。これをTryフェーズと呼ぶ。全てのサービスで仮登録が完了した後に正式登録を実行する。これがConfirm/Cancelフェーズである。何らかの理由で仮登録できなければ一連の仮登録処理はキャンセルする。

この先は日経クロステック Active会員の登録が必要です

日経クロステック Activeは、IT/製造/建設各分野にかかわる企業向け製品・サービスについて、選択や導入を支援する情報サイトです。製品・サービス情報、導入事例などのコンテンツを多数掲載しています。初めてご覧になる際には、会員登録(無料)をお願いいたします。