イベント駆動マイクロサービスを構築する

第16章. イベント駆動マイクロサービスをデプロイする

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

イベント駆動型マイクロサービスのデプロイは困難である。組織内のマイクロサービスの数が増えれば増えるほど、標準化されたデプロイプロセスを持つことの重要性も増す。数十のサービスしか管理していない組織では、いくつかのカスタムデプロイプロセスで済ませることができるが、マイクロサービスに真剣に投資している組織であれば、イベントドリブンであろうとなかろうと、デプロイプロセスの標準化と合理化に投資しなければならない。

マイクロサービスデプロイの原則

デプロイプロセスを推進する原則はいくつかある：

チームにデプロイの自律性を与える。

チームは、自分たちでテストとデプロイのプロセスをコントロールし、マイクロサービスを自分たちの裁量でデプロイする自律性を持つべきだ。

標準化されたデプロイプロセスを実装する。

デプロイプロセスはサービス間で一貫していなければならない。新しいマイクロサービスでは、デプロイプロセスがすでに利用可能な状態で作成されるべきである。これは一般的に継続的インテグレーションフレームワークで実現される。

必要なサポートツールを提供する

デプロイでは、コンシューマグループのオフセットのリセット、ステートストアのパージ、スキーマの進化のチェックと更新、内部イベントストリームの削除などが必要になる場合がある。支援ツールは、デプロイのさらなる自動化を可能にし、チームの自律性をサポートするために、これらの関数を提供する。

イベントストリームの再処理の影響を考慮する

入力イベントストリームの再利用には時間がかかり、下流のコンシューマにとって結果が古くなる。さらに、別のマイクロサービスが大量の出力イベントを生成し、下流コンシューマに高負荷をかける可能性がある。非常に大規模なイベントストリームや、大量のコンシューマを持つイベントストリームでは、必要な処理能力が自明でないほど急増する可能性がある。また、副作用、特に顧客を混乱させるような副作用（例えば、複数年分の販促メールの再送など）も考慮しなければならない。

サービス・レベル・アグリーメント（SLA）を遵守する。

デプロイは、他のサービスを混乱させる可能性がある。たとえば、状態ストアを再構築すると、大量の停止時間が発生する可能性があり、入力イベントストリームを再処理すると、大量のイベントが発生する可能性がある。デプロイプロセス中に、すべてのSLAが遵守されるようにする。

依存サービスの変更を最小限に抑える

デプロイでは、REST APIとのやり取りやドメインスキーマの変更を導入する場合など、他のサービスがAPIやデータモデルを変更する必要があるかもしれない。このような変更は、ビジネス要件の変化に応じて必要なときだけサービスをデプロイするという他のチームの自律性を侵害するため、可能な限り最小限に抑えるべきである。

川下コンシューマとの破壊的変更の交渉

破壊的なスキーマ変更は、状況によっては避けられないかもしれず、新しいイベントストリームの作成とダウンストリームコンシューマとのデータ契約の再交渉を必要とする。デプロイ前にこのような話し合いが行われ、コンシューマに対する移行計画が策定されていることを確認する。

警告

マイクロサービスは独立デプロイ可能であるべきであり、そうでない場合はアンチパターンである。特定のマイクロサービスのデプロイが、他のマイクロサービスにデプロイの同期を定期的に要求する場合、それは境界づけられたコンテキストが定義されていないことを示す指標であり、見直すべきである。 ...