マイクロサービス設計パターンとは

これらのアーキテクチャー・パターンは、サービス通信、データの一貫性、フォールト・トレランス、システムの拡張性など、分散型コンピューティング・システムの実装時に開発チームが直面する日常的な課題への標準ソリューションを提供します。

今日の世界が活用しているデジタル・エクスペリエンスの多くは、マイクロサービスの設計パターンによって実現され、現実世界の多くのユースケースに見出すことができます。たとえば、Netflixで番組をストリーミングしている場合、何百もの個別サービスが連携して、コンテンツを配信し、ユーザー・プロファイルを管理し、次に見るものを提案します。

同様に、Amazonは個別サービスを通じて在庫、支払い、配送を調整します。金融業界では、銀行などの機関もマイクロサービス設計パターンを利用してリスク管理とカスタマー・サービスを分離して、お金の安全性とアクセスしやすさを保っています。

IBMが実施した調査「Microservices in the Enterprise, 2021」によると、組織の88% がマイクロサービスが開発チームに多くのメリットをもたらすと報告しています。そのようなメリットには、コードの組織化、メンテナンスの簡素化、導入サイクルの短縮による開発者の生産性の20～50%向上が挙げられます。

マイクロサービス・アーキテクチャーはクラウドネイティブ手法であり、アプリケーションを疎結合の独立したサービスに分割します。それらのサービスは、Kubernetesなどのオーケストレーション・プラットフォームで管理されるコンテナに展開されます。

各サービスは、専用のデータベースやデータ管理モデルなど、独自の技術スタックを使用して独立して動作します。サービス間の通信は、REST API、Apache Kafkaなどのイベント・ストリーミング・プラットフォーム、およびメッセージ・ブローカーを介して行われ、チームは境界付きコンテキストと呼ばれる明確な境界を持つビジネス機能を中心にサービスを設計します。

ソフトウェア開発に対するこの最新アプローチは、 DevOpsの自動化とCI/CD パイプライン、クラウドへの移行、アプリケーションのモダナイゼーション、人工知能（AI）の統合など、最新のデジタル・トランスフォーメーション・イニシアチブに必要な運用上の柔軟性をサポートします。

マイクロサービスは最新のアプリケーションにとって大きな利点がありますが、このアーキテクチャーを選択するタイミングを理解するには、従来のモノリシックなアプローチと比較する必要があります。

モノリシック・アーキテクチャーでは、すべてのビジネス機能が統合され、同じコードベース、データベース、ランタイム環境を共有する単一の展開可能なユニットとしてアプリケーションが構築されます。マイクロサービス・アーキテクチャーは、明確に定義されたアプリケーション・プログラミング・インターフェース（API）を介して通信する、より小さな独立したサービスにアプリケーションを分割します。各サービスは、独自のデータベースと導入サイクルを持つ可能性があります。

これらの設計方法の主な違いは、結合、つまりシステムのさまざまな部分がどれだけ緊密に接続されているかです。モノリスは内部結合は高いですが導入は簡単です。一方、マイクロサービスはサービス間の結合が緩やかですが、ITインフラストラクチャーの要件はより複雑です。

ソフトウェア・エンジニアは、コストの管理と開発の迅速化を目指している中小企業やスタートアップ企業など、小規模でシンプルなアプリケーションにモノリシック・アーキテクチャーを選択することがよくあります。高い拡張性、レジリエンス、柔軟性が必要な複雑なシナリオ（ソーシャル・メディア・プラットフォーム、銀行アプリケーションなど）では、マイクロサービスが良い選択肢です。

組織は、どのアプローチを採用するかを決定する際に、チームの規模、アプリケーション、拡張性のニーズ、DevOps の成熟度レベルなどの特定の要件に照らして各アプローチを評価する必要があります。

モノリシック・アーキテクチャーとマイクロサービスの詳細については、こちらをご覧ください。

マイクロサービスの設計パターンは5つの主要な領域に分類され、これらは分散型アーキテクチャーの課題解決のためにチームを支援するテスト済みのソリューションを提供します。

1. サービスの通信と検出
2. データおよびトランザクション管理
3. レジリエンスと障害処理
4. アーキテクチャーと統合
5. イベントと通信

サービス・レジストリー・パターン

サービス・レジストリー・パターンは、サービスがエンドポイントと正常性ステータスを登録する中央ディレクトリーを作成するため、固定の拠点が不要になります。サービスが通信する必要がある場合、レジストリーにクエリーを実行して、利用可能なサーバー・インスタンスを検索します。たとえば、決済サービスがインベントリー・サービスに接続する必要がある場合、レジストリーをチェックして正常なインベントリー・インスタンスを見つけます。

APIゲートウェイ・パターン

APゲートウェイ・パターンは、クライアントと複数のバックエンド・マイクロサービス間に単一のエントリー・ポイントを作成します。クライアントがさまざまなサービスに個別に呼び出す代わりに、APIゲートウェイは１つのリクエストを受け取り、適切なマイクロサービスにルーティングし、応答を１つの成果にまとめます。

たとえば、製品ページを読み込むと、ゲートウェイはさまざまなサービスから、製品の詳細、料金体系、在庫、レビューを同時に取得できます。そして、これらすべての情報を1つにまとめた応答としてクライアントに返します。

サービス検出パターン

サービス検出パターンは、動的な環境でサービスが互いを見つけるという課題を解決します。マイクロサービスがスケールアップしたり新しいバージョンに更新されると、そのネットワークの場所は常に変化します。サービス検出パターンは、サービスが自身を登録し、通信する必要のある他のサービスを見つけるための自動化されたメカニズムを提供するので、ハードコードされたアドレスの必要性を排除します。

サービスごとのデータベース・パターン

サービスごとのデータベース・パターンにより、各マイクロサービスが独自のデータベースを所有および管理することが保証され、サービス間の共有データの依存関係が排除されます。このアプローチでは、サービス間の直接的なデータア・クセスを防ぎ、結合を減らしますが、他の情報ソースからの情報が必要な場合、サービスがAPIを介して通信する必要があります。たとえば、エンタープライズ・リソース・プランニング（ERP）システムでは、会計サービスは人事サービスの従業員データベースとは独立して財務データを管理します。

Sagaパターン

Sagaパターンは、複数のマイクロサービスにまたがるトランザクションを調整されたステップに分割して管理します。各サービスはローカル・トランザクションを完了し、チェーン内の次のステップをトリガーします。いずれかのステップが失敗した場合、パターンは自動的にアクションを実行し、前のステップを元に戻します。たとえば、オンライン注文を処理する際、在庫が引当された後に支払いが失敗した場合、Sagaは引当された品目を自動的に解放します。

CQRS（コマンド・クエリー責任分離パターン）

CQRSパターンは、それぞれに専用モデルを使用することで、データ変更（コマンド）とデータ取得（クエリー）を分割します。この分割により、システムは各パスを個別に最適化できるため、コマンド側での書き込み競合が最小限に抑えられ、読み取り側でのクエリーのレイテンシーが短縮されます。電子商取引システムでは、注文を行う際は書き込みに最適化されたコマンド モデルを使用し、販売レポートを生成する際は読み取りに最適化されたクエリー・モデルを活用します。

ブレーカー・パターン

ブレーカー・パターンは、下流サービスへの呼び出しを監視し、障害が検出された場合に要求を停止することで、1つのサービスの障害がシステム全体に広がるのを防ぎます。サービスが応答しなくなると、ブレーカーが「作動」してそれ以上の呼び出しをブロックして、リソースを保護し、連鎖的な障害を防ぎます。

たとえば、在庫サービスがダウンした場合、ブレーカーは、注文サービスが失敗した要求を繰すのを停止します。その結果、顧客にフォールバック応答を提供しながら、システムの残りの部分は引き続き機能できます。

バルクヘッド・パターン

バルクヘッド・パターンは、リソースを分離し、1つの領域での障害がシステム全体に影響を与えるのを防ぎます。船船の船隊のコンパートメントのように、バルクヘッドはさまざまな機能を分離させているため、1つが故障しても、他の機能が引き続き動作します。このパターンにより、同時リクエストの数や特定のサービスに割り当てられるリソースの数が制限されます。

Backend-for-frontend（BFF）プラットフォーム

フロントエンド専用のバックエンド（BFF）パターンは、それぞれのフロントエンド・インターフェースに合わせて調整された専用のバックエンド・サービスを作成します。モバイル・アプリケーションには、アプリケーションとは異なる要件（小型画面、制限された帯域幅、さまざまな性能機能など）があるため、BFFパターンを使用すると、開発者は特定のフロントエンドに合わせて各バックエンドを最適化できます。

エンティティーおよび集約パターン

エンティティーおよび集約パターンは、関連データをドメイン駆動設計（DDD）の概念に基づいた論理ユニットに編成します。エンティティーは、Eメールで識別される顧客アカウントなど、一意のIDを持つ個別のオブジェクトを表します。集約には、まとめて更新する必要がある関連エンティティーを1つの単位としてまとめます。

たとえば、電子商取引システムでは、注文の集計には注文の詳細、明細品目、配送情報が含まれ、変更が発生したときにこれらすべてを同期し続ける必要があります。

ストラングラー・パターン

ストラングラー・パターンは、モノリシック・アプリケーションをより保守しやすいマイクロサービス・アーキテクチャーにリファクタリングするプロセスの管理を支援します。新しいマイクロサービスは、既存のモノリスとともに徐々に構築され、古いシステムが完全に置き換えられるまで、徐々に機能を引き継ぎます。「絞殺魔」を意味するストラングラーという名前は、ブドウの木（マイクロサービス）がゆっくり成長して一本の木（モノリシック・アプリケーション）を飲み込んで絞め殺すことを表しています。

イベント駆動型パターン

イベント駆動型パターンにより、マイクロサービスは直接サービスを呼び出すのではなく、イベントを発行および消費することで非同期的に通信できるようになります。サービスがアクションを完了すると、他の関心あるサービスが待ち受けて適宜応答できるイベントをブロードキャストします。このアプローチにより、サービス間の疎結合が実現し、共有イベント・システムを通じてアクティビティーを調整しながら、独立して動作できるようになります。

サイドカー・パターン

サイドカー・パターンとは、同じ実行環境内でプライマリー・アプリケーションまたはサービスと並行してセカンダリー・コンテナ（「サイドカー」）を展開することです。このサイドカーは、横断的な問題（ロギング、監視、セキュリティー、オブザーバビリティーなど）を処理し、コードベースを変更せずにメイン・アプリケーションの機能を拡張します。

アダプター・マイクロサービス・パターン

アダプター・マイクロサービス・パターンにより、互換性のないシステムまたはインターフェース間の通信が可能になります。旅行用アダプターと同じように、デバイスを外部の電源に接続し、アダプターのパターンを異なるデータ形式、プロトコル、またはAPI間で変換します。このパターンは、異なる通信標準を使用するレガシー・システムやサードパーティのサービスと連携する場合に有益です。

マイクロサービス設計パターンは、高い拡張性、複雑なビジネス・ロジック、信頼性の高いシステム性能を必要とする業界では特に価値があります。主なユースケースには次のようなものがあります。

• 電子商取引プラットフォームは、販売イベント中の負荷分散を処理し、複数の倉庫にわたる複雑な在庫を管理するために、マイクロサービス設計パターンを利用します。また、さまざなシステム間で決済、出荷、カスタマー・サービス業務を調整し、ビジネス成果と顧客体験を向上させます。
• ストリーミング・サービスは、マイクロサービス・パターンを使ってユーザーの好みや推奨事項を管理しながらコンテンツをグローバルに配信し、最小限のバッファリングとパーソナライズされたエクスペリエンスで大規模なユーザーの同時負荷を処理可能にします。
• 金融サービスでは、これらのパターンを実行して、金融機関が要求する厳格な規制コンプライアンスとセキュリティー標準を維持しながら、取引、リスク管理、認証、運用を分離します。
• 医療システムはこれらのパターンを使ってHIPAAへの準拠を維持し、さまざまな医療従事者の各種医療機器APIと接続しながら、患者の記録、予約スケジュール設定、請求システムを連携させます。
• ソーシャルメディア・プラットフォームは、マイクロサービス設計パターンを使ってメッセージング、コンテンツ・フィード、メディア処理を独立して拡張し、すべての機能で応答性の高いパフォーマンスを維持しながら、毎日数十億のユーザー・インタラクションを処理できるようにします。

マイクロサービス設計パターンは、今日の複雑な分散型システムを管理するためのベスト・プラクティスを提供し、次のような幅広いメリットをもたらします。

• 複雑さの軽減：一般的な課題に対する標準化されテストされたアプローチにより、結果の予測可能性が高まり、トラブルシューティングが容易になり、チームのオンボーディングが迅速化します。
• 俊敏性と市場投入までの時間の短縮： チームは独立してサービスを開発、展開、拡張できるため、調整のボトルネックが減り、機能の提供が加速します。
• フォールト・トレランスの向上： 隔離技術により、システム全体に故障が連鎖するのを防ぎ、ダウンタイムを大幅に短縮し、システム全体の信頼性を向上させます。
• 拡張性と柔軟性の向上： 組織は、大規模なシステムを全面的に見直すことなく、必要な場所にリソースを正確に割り当て、変化するビジネス要件に迅速に適応できます。チームは、特定のニーズに基づいてJava™やPythonなどの各種プログラミング言語でサービスを開発できます。
• コスト効率： ターゲットを絞ったスケーリングとリソースの最適化に、特定のサービスに最適なテクノロジー・スタックを選択する機能を組み合わせることで、より経済的なシステムを実現できます。
• テクノロジーの多様性：チームは、各サービスの特定の要件に最適なツールとフレームワークを選択でき、より効率的で保守しやすいソリューションを実現できます。たとえば、データベース型サービス（DBaaS）用のエンタープライズ・マイクロサービスにはJava Spring Bootを選択し、データ分析にはPythonを選択できます。

適切なパターンの選択は、システム固有の要件と組織の機能によって異なります。体系的なアプローチを使用すると、これらのアーキテクチャー上で何を決定したらいいのかがわかります。

イベント・ソーシングやCQRSなどの複雑なパターンを実装する前に、APIゲートウェイとサービス検出から開始してください。これらのコア・パターンは、より高度な実装に必要な通信インフラストラクチャーを確立します。

分散型システム、運用の成熟度、DevOpsプラクティスに関する経験を考慮してください。マイクロサービスを初めて使用するチームには、最初はより単純なパターンが役に立ちますが、経験豊富なチームは、より深い運用知識を必要とする高度な調整パターンに取り組むことができます。

各パターンは、長期的な管理を必要とする複雑さをもたらします。サービスごとのデータベースには、データの同期戦略が必要です。イベント駆動型のパターンには、メッセージ・ブローカー・インフラストラクチャーが必要です。選択したパターンをサポートできることを確認します。

基本的なパターンを使用するいくつかのサービスから始めて経験を積み、専門知識の成長に応じて拡張していきます。この段階的なアプローチにより、オーバーエンジニアリングが防止され、早期の実装から学ぶことができます。