マイクロサービス アーキテクチャは、機敏性、スケーラビリティ、高可用性など、アプリケーションに多くの利点を提供できます。 これらの利点に加えて、このアーキテクチャには課題があります。 マイクロサービス ベースのアプリケーションを構築したり、既存のアプリケーションをマイクロサービス アーキテクチャに変換したりする場合は、現在の状況を分析して評価して、改善が必要な領域を特定する必要があります。
このガイドは、マイクロサービス アーキテクチャに移行するときに留意すべきいくつかの考慮事項を理解するのに役立ちます。 このガイドを使用して、アプリケーション、インフラストラクチャ、DevOps、開発モデルなどの成熟度を評価できます。
ビジネスの優先順位を理解する
マイクロサービス アーキテクチャの評価を開始するには、まず、ビジネスの主要な優先順位を理解する必要があります。 たとえば、主要な優先順位は、機敏性、変更の導入、迅速な開発などに関連している場合があります。 アーキテクチャが主要な優先順位に適しているかどうかを分析する必要があります。 ビジネスの優先順位は時間の経過と同時に変化する可能性があることに注意してください。 たとえば、イノベーションはスタートアップ企業にとって最優先事項ですが、数年後のコア優先度は信頼性と効率です。
考慮すべきいくつかの優先順位を次に示します。
- 革新
- 信頼性
- 効率性
評価のガイドとして機能する組織のコミットメントを確保するために、アプリケーションのさまざまな部分に合わせた SLA を文書化します。
アーキテクチャの決定を記録する
マイクロサービス アーキテクチャは、チームが自律的になるのに役立ちます。 たとえば、Teams はテクノロジ、方法論、インフラストラクチャ コンポーネントに関して独自の決定を行うことができます。 ただし、これらの選択は、共有ガバナンスと呼ばれる正式に合意された原則を尊重する必要があります。これは、マイクロサービスの広範な戦略に対処する方法に関するチーム間の合意を表します。
次の点を考慮します。
- 共有ガバナンスは実施されていますか?
- アーキテクチャジャーナルで意思決定とそのトレードオフを追跡していますか?
- チームはアーキテクチャ ジャーナルに簡単にアクセスできますか?
- ツール、テクノロジ、フレームワークを評価するプロセスはありますか?
チームの構成を評価する
チーム間の不要なコミュニケーションを回避するには、適切なチーム構造が必要です。 マイクロサービス アーキテクチャは、小規模で焦点を絞った部門間のチームの形成を促進し、考え方の変更を必要とします。そのためには、チームの再構築に先行する必要があります。
次の点を考慮します。
- ドメイン 駆動設計 (DDD) の原則に従って、チームはサブドメインに基づいて分割されますか?
- 関連するマイクロサービスを個別に構築して運用するのに十分な容量を備えた、チームは機能を横断していますか?
- プロジェクトに関連しないアドホック アクティビティとタスクに費やされる時間はどのくらいですか?
- チーム間コラボレーションにはどのくらいの時間が費やされますか?
- 技術的負債を特定して最小限に抑えるプロセスはありますか?
- チーム間で学習された教訓と経験はどのように伝えられますか?
Twelve-Factor 手法を使用する
マイクロサービス アーキテクチャを選択する基本的な目標は、アジャイル プラクティスに従って、より迅速に価値を提供し、変化に適応することです。 Twelve-Factor アプリの手法では、保守可能でスケーラブルなアプリケーションを構築するためのガイドラインが提供されます。 これらのガイドラインは、不変性、一時性、宣言型の構成、自動化などの属性を促進します。 これらのガイドラインを組み込み、一般的な落とし穴を回避することで、疎結合の自己完結型マイクロサービスを作成できます。
分解アプローチを理解する
モノリシック アプリケーションをマイクロサービス アーキテクチャに変換するには時間がかかります。 エッジ サービスから始めます。 エッジ サービスは、他のサービスへの依存関係が少なく、独立したサービスとしてシステムから簡単に分解できます。 すべてのサービスが個別のマイクロサービスに分解されるまでモノリシック アプリケーションを動作状態に保つために、 Strangler Fig や 破損防止レイヤー などのパターンを強くお勧めします。 分離中、DDD の原則は、チームがサブドメインに基づいてモノリシック アプリケーションからコンポーネントまたはサービスを選択するのに役立ちます。
たとえば、eコマース システムでは、カート、製品管理、注文管理、価格、請求書の生成、通知などのモジュールが用意されている場合があります。 通知モジュールを使用してアプリケーションの変換を開始することに決めたのは、他のモジュールへの依存関係がないためです。 ただし、他のモジュールはこのモジュールに依存して通知を送信する場合があります。 通知モジュールは別のマイクロサービスに簡単に分解できますが、新しい通知サービスを呼び出すにはモノリシック アプリケーションでいくつかの変更を行う必要があります。 次に請求書生成モジュールを変換することにします。 このモジュールは、注文が生成された後に呼び出されます。 ストラングラーや破損対策などのパターンを使用して、この変換をサポートできます。
データ同期、モノリシック インターフェイスとマイクロサービス インターフェイスの両方へのマルチ書き込み、データの所有権、スキーマ分解、結合、データの量、データの整合性により、データの内訳と移行が困難になる可能性があります。 マイクロサービス間での共有データベースの保持、ビジネス機能またはドメインに基づくサービスのグループからのデータベースの分離、サービスからのデータベースの分離など、いくつかの手法を使用できます。 推奨される解決策は、各データベースを各サービスで分解することです。 多くの状況では、これは実用的ではありません。 このような場合は、データベース ビュー パターンやデータベース ラッピング サービス パターンなどのパターンを使用できます。
DevOps の準備状況を評価する
マイクロサービス アーキテクチャに移行するときは、DevOps コンピテンシーを評価することが重要です。 マイクロサービス アーキテクチャは、組織の機敏性を高めるために、アプリケーションでのアジャイル開発を容易にすることを目的としています。 DevOps は、このコンピテンシーを実現するために実装する必要がある主要なプラクティスの 1 つです。
マイクロサービス アーキテクチャの DevOps 機能を評価するときは、次の点に注意してください。
- 組織内のユーザーは、DevOps の基本的なプラクティスと原則を知っていますか?
- チームはソース管理ツールと CI/CD パイプラインとの統合を理解していますか?
- DevOps プラクティスを適切に実装していますか?
- アジャイルプラクティスに従っていますか?
- 継続的インテグレーションは実装されていますか?
- 継続的デリバリーは実装されていますか?
- 継続的デプロイは実装されていますか?
- 継続的な監視は実装されていますか?
- コードとしてのインフラストラクチャ (IaC) は配置されていますか?
- CI/CD をサポートするために適切なツールを使用していますか?
- アプリケーションのステージング環境と運用環境の構成はどのように管理されますか?
- ツール チェーンにはコミュニティ サポートとサポート モデルがあり、適切なチャネルとドキュメントが提供されていますか?
頻繁に変化するビジネス領域を特定する
マイクロサービス アーキテクチャは柔軟性があり、適応性があります。 評価中に、組織内でディスカッションを行い、同僚が頻繁に変化すると考える領域を決定します。 マイクロサービスを構築することで、チームは顧客が要求する変更に迅速に対応し、回帰テストの作業を最小限に抑えることができます。 モノリシック アプリケーションでは、1 つのモジュールを変更するには、多数のレベルの回帰テストが必要であり、新しいバージョンのリリース時の機敏性が低下します。
次の点を考慮します。
- サービスは個別にデプロイできますか?
- サービスは DDD の原則に従っていますか?
- このサービスは SOLID の原則に従っていますか?
- データベースはサービスに対してプライベートですか?
- サポートされているマイクロサービス シャーシ パターンを使用してサービスを構築しましたか?
インフラストラクチャの準備状況を評価する
マイクロサービス アーキテクチャに移行する場合、インフラストラクチャの準備は考慮すべき重要なポイントです。 インフラストラクチャが適切に設定されていない場合、または適切なサービスまたはコンポーネントが使用されていない場合、アプリケーションのパフォーマンス、可用性、スケーラビリティが影響を受けます。 提案されたすべての手法と手順を使用してアプリケーションが作成される場合がありますが、インフラストラクチャは不十分です。 これにより、パフォーマンスとメンテナンスが低下します。
インフラストラクチャの準備状況を評価するときは、次の要因を考慮してください。
- インフラストラクチャによって、デプロイされたサービスのスケーラビリティが確保されますか?
- インフラストラクチャでは、CI/CD を使用して自動化できるスクリプトを使用したプロビジョニングがサポートされていますか?
- デプロイ インフラストラクチャは可用性の SLA を提供していますか?
- ディザスター リカバリー (DR) 計画と定期的な訓練スケジュールはありますか?
- データは DR 用に異なるリージョンにレプリケートされますか?
- データ バックアッププランはありますか?
- デプロイ オプションは文書化されていますか?
- デプロイ インフラストラクチャは監視されていますか?
- デプロイ インフラストラクチャは、サービスの自己復旧をサポートしていますか?
リリース サイクルを評価する
マイクロサービスは変化に適応し、アジャイル開発を利用してリリース サイクルを短縮し、顧客に価値をもたらす。 リリース サイクルを評価するときは、次の要因を考慮してください。
- アプリケーションをビルドしてリリースする頻度はどのくらいですか?
- デプロイ後にリリースが失敗する頻度はどのくらいですか?
- 停止後の問題の復旧または修復にはどのくらいの時間がかかりますか?
- アプリケーションにセマンティック バージョン管理を使用していますか?
- 異なる環境を維持し、同じリリースを順番に伝達しますか (たとえば、最初にステージングに、次に運用環境に)。
- API のバージョン管理を使用していますか?
- API の適切なバージョン管理ガイドラインに従っていますか?
- API バージョンを変更するタイミング
- API のバージョン管理を処理するためのアプローチは何ですか?
- URI パスのバージョン管理
- クエリ パラメーターのバージョン管理
- コンテンツ タイプのバージョン管理
- カスタム ヘッダーのバージョン管理
- イベントのバージョン管理の練習はありますか?
サービス間の通信を評価する
マイクロサービスは、ビジネス シナリオに対処するためにプロセス境界を越えて相互に通信する自己完結型サービスです。 信頼性と信頼性の高い通信を得るには、適切な通信プロトコルを選択する必要があります。
次の要素を考慮してください。
- API が一流の市民として扱われる API 優先のアプローチに従っていますか?
- 同期通信プロトコルを介して複数のサービスが順番に通信する、長いチェーン操作はありますか?
- システム内の任意の場所で非同期通信を検討しましたか?
- メッセージ ブローカーテクノロジとその機能を評価しましたか?
- サービスが受信して処理するメッセージのスループットを理解していますか?
- クライアントからサービスへの直接通信を使用していますか?
- メッセージ ブローカー レベルでメッセージを保持する必要がありますか?
- マテリアライズド ビュー パターンを使用して、マイクロサービスのおしゃべりな動作に対処していますか?
- 信頼性の高い通信のために、再試行、サーキット ブレーカー、指数バックオフ、ジッターを実装しましたか? これを処理する一般的な方法は、 アンバサダー パターンを使用することです。
- マイクロサービス間の通信を容易にするためにドメイン イベントを定義していますか?
サービスをクライアントに公開する方法を評価する
API ゲートウェイは、マイクロサービス アーキテクチャのコア コンポーネントの 1 つです。 サービスをクライアントに直接公開すると、管理容易性、制御性、信頼性の高い通信の観点から問題が発生します。 API ゲートウェイはプロキシ サーバーとして機能し、トラフィックをインターセプトしてバックエンド サービスにルーティングします。 IP アドレス、承認、モック応答などを使用してトラフィックをフィルター処理する必要がある場合は、サービスを変更せずに API ゲートウェイ レベルで行うことができます。
次の要素を考慮してください。
- サービスはクライアントによって直接使用されますか?
- すべてのサービスのファサードとして機能する API ゲートウェイはありますか?
- API ゲートウェイは、クォータ制限、モック応答、IP アドレスのフィルター処理などのポリシーを設定できますか?
- モバイル アプリ、Web アプリ、パートナーなど、さまざまな種類のクライアントのニーズに対応するために、複数の API ゲートウェイを使用していますか?
- API ゲートウェイには、 クライアントが Azure API Management の開発者ポータルなどのサービスを検出してサブスクライブできるポータルが用意されていますか?
- ソリューションでは、API ゲートウェイと共に L7 負荷分散または Web アプリケーション ファイアウォール (WAF) 機能が提供されますか?
トランザクション処理を評価する
分散トランザクションを使用すると、1 つの作業単位として複数の操作を簡単に実行できます。 マイクロサービス アーキテクチャでは、システムは多数のサービスに分解されます。 1 つのビジネス ユース ケースは、1 つの分散トランザクションの一部として複数のマイクロサービスによって対処されます。 分散トランザクションでは、コマンドはイベントが発生したときに開始される操作です。 イベントによってシステム内の操作がトリガーされます。 操作が成功すると、別のコマンドがトリガーされ、トランザクションが成功するかどうかに応じて、すべてのトランザクションが完了またはロールバックされるまで別のイベントをトリガーできます。
次の考慮事項を考慮してください。
- システム内の分散トランザクションの数はいくつですか?
- 分散トランザクションを処理する方法は何ですか? オーケストレーションまたは振り付けを使用して Saga パターン の使用を評価します。
- 複数のサービスにまたがるトランザクションの数
- データの整合性と整合性を実現するために ACID または BASE トランザクション モデルに従っていますか?
- 複数のサービスにまたがるトランザクションに対して、長鎖操作を使用していますか?
サービス開発モデルを評価する
マイクロサービス アーキテクチャの最大の利点の 1 つは、テクノロジの多様性です。 マイクロサービス ベースのシステムを使用すると、チームは選択したテクノロジを使用してサービスを開発できます。 従来のアプリケーション開発では、新しいコンポーネントをビルドするときに既存のコードを再利用したり、開発作業を減らすための内部開発フレームワークを作成したりできます。 複数のテクノロジを使用すると、コードの再利用を防ぐことができます。
次の点を考慮します。
- サービス テンプレートを使用して、新しいサービス開発を開始しますか?
- Twelve-Factor アプリの手法に従い、マイクロサービスに 1 つのコード ベースを使用し、依存関係を分離し、構成を外部化していますか?
- キー コンテナーに機密性の高い構成を保持していますか?
- サービスをコンテナー化しますか?
- データ整合性の要件を把握していますか?
デプロイ アプローチを評価する
デプロイ アプローチは、さまざまなデプロイ環境でアプリケーションのバージョンをリリースする方法です。 マイクロサービス ベースのシステムは、従来のアプリケーションよりも速くバージョンをリリースする機敏性を提供します。
デプロイ計画を評価するときは、次の要因を考慮してください。
- サービスをデプロイするための戦略はありますか?
- 最新のツールとテクノロジを使用してサービスをデプロイしていますか?
- サービスを展開するときにチーム間でどのようなコラボレーションが必要ですか?
- コードとしてのインフラストラクチャ (IaC) を使用してインフラストラクチャをプロビジョニングしますか?
- DevOps 機能を使用してデプロイを自動化していますか?
- Twelve-Factor アプリの手法で提案されているように、同じビルドを複数の環境に伝達しますか?
ホスティング プラットフォームを評価する
スケーラビリティは、マイクロサービス アーキテクチャの主な利点の 1 つです。 これは、マイクロサービスがビジネス ドメインにマップされるため、各サービスを個別にスケーリングできるためです。 モノリシック アプリケーションは、ホスティング プラットフォーム上に 1 つのユニットとしてデプロイされ、包括的にスケーリングする必要があります。 その結果、ダウンタイム、デプロイ リスク、メンテナンスが発生します。 モノリシック アプリケーションは、個々のビジネス ドメインに対応するコンポーネントで適切に設計されている場合があります。 しかし、プロセスの境界がないため、単一責任の原則に違反する可能性がより困難になります。 これは最終的にスパゲッティコードになります。 アプリケーションは 1 つのホスティング プロセスとして構成およびデプロイされるため、スケーラビリティは困難です。
マイクロサービスを使用すると、チームはスケーラビリティのニーズをサポートするために適切なホスティング プラットフォームを選択できます。 自動スケーリング、エラスティック プロビジョニング、高可用性、迅速なデプロイ、簡単な監視などの機能を提供することで、これらの課題に対処するために、さまざまなホスティング プラットフォームを利用できます。
次の点を考慮します。
- サービス (仮想マシン、コンテナー、サーバーレス) をデプロイするために使用するホスティング プラットフォームは何ですか?
- ホスティング プラットフォームはスケーラブルですか? 自動スケールはサポートされていますか?
- ホスティング プラットフォームのスケーリングにはどのくらいの時間がかかりますか?
- さまざまなホスティング プラットフォームが提供する SLA を理解していますか?
- ホスティング プラットフォームはディザスター リカバリーをサポートしていますか?
サービスの監視を評価する
監視は、マイクロサービス ベースのアプリケーションの重要な要素です。 アプリケーションは個別に実行される多数のサービスに分かれているため、エラーのトラブルシューティングは困難な場合があります。 適切なセマンティクスを使用してサービスを監視すると、チームは簡単に監視、調査、エラーへの対応を行うことができます。
次の点を考慮します。
- デプロイされたサービスを監視しますか?
- ログ記録メカニズムはありますか? どのようなツールを使用していますか?
- 分散トレース インフラストラクチャはありますか?
- 例外を記録しますか?
- 問題をすばやく特定するためにビジネス エラー コードを保持していますか?
- サービスにヘルスプローブを使いますか？
- セマンティック ログを使用しますか? 主要なメトリック、しきい値、インジケーターを実装しましたか?
- ログ記録中に機密データをマスクしますか?
相関トークンの割り当てを評価する
マイクロサービス アーキテクチャでは、アプリケーションは個別にホストされるさまざまなマイクロサービスで構成され、相互にやり取りしてさまざまなビジネス ユース ケースに対応します。 アプリケーションがバックエンド サービスと対話して操作を実行する場合は、関連付けトークンと呼ばれる一意の番号を要求に割り当てることができます。 関連付けトークンはエラーのトラブルシューティングに役立つ可能性があるため、使用することを検討することをお勧めします。 これらは、問題の根本原因の特定、影響の評価、問題を修復するためのアプローチの決定に役立ちます。
関連付けトークンを使用して、関連付けトークンが含まれているサービスと含まれないサービスを識別することで、要求証跡を取得できます。 その要求の関連付けトークンを持たないサービスが失敗しました。 エラーが発生した場合は、後でトランザクションを再試行できます。 べき等性を適用するために、関連付けトークンを持たないサービスのみが要求を処理します。
たとえば、多数のサービスを含む操作の長いチェーンがある場合、関連付けトークンをサービスに渡すと、トランザクション中にいずれかのサービスが失敗した場合に問題を簡単に調査できます。 通常、各サービスには独自のデータベースがあります。 関連付けトークンはデータベース レコードに保持されます。 トランザクションの再生の場合、データベース内に特定の関連付けトークンを持つサービスは要求を無視します。 トークンを持たないサービスのみが要求を処理します。
次の点を考慮します。
- 関連付けトークンはどの段階で割り当てますか?
- 関連付けトークンを割り当てるコンポーネントはどれですか?
- 関連付けトークンをサービスのデータベースに保存しますか?
- 関連付けトークンの形式は何ですか?
- 関連付けトークンとその他の要求情報をログに記録しますか?
マイクロサービス シャーシ フレームワークの必要性を評価する
マイクロサービス シャーシ フレームワークは、ログ記録、例外処理、分散トレース、セキュリティ、通信などの横断的な問題に対する機能を提供する基本フレームワークです。 シャーシ フレームワークを使用する場合は、インフラストラクチャの機能を操作するよりも、サービス境界の実装に重点を置きます。
たとえば、カート管理サービスを構築しているとします。 受信トークンを検証し、ログ データベースにログを書き込み、そのサービスのエンドポイントを呼び出して別のサービスと通信する必要があります。 マイクロサービス シャーシ フレームワークを使用する場合は、開発作業を減らすことができます。 Dapr は、横断的な懸念事項を実装するためのさまざまな構成要素を提供する 1 つのシステムです。
次の点を考慮します。
- マイクロサービス シャーシ フレームワークを使用していますか?
- Dapr を使用して横断的な懸念事項とやり取りしていますか?
- シャーシ フレームワークは言語にとらわれないですか?
- シャーシフレームワークは汎用なので、あらゆる種類のアプリケーションをサポートしていますか? シャーシ フレームワークには、アプリケーション固有のロジックを含めることはできません。
- シャーシ フレームワークには、必要に応じて選択したコンポーネントまたはサービスを使用するメカニズムが用意されていますか?
アプリケーション テストへのアプローチを評価する
従来、テストは開発が完了した後に行われ、アプリケーションはユーザー受け入れテスト (UAT) と運用環境にロールアウトする準備ができています。 現在、このアプローチには変化があり、アプリケーション開発ライフサイクルの早い段階 (左) にテストを移動します。 シフトレフト テストでは、設計、開発、開発後の各フェーズを含むアプリケーション開発ライフサイクルの各フェーズでテストが行われるため、アプリケーションの品質が向上します。
たとえば、アプリケーションをビルドするときは、まずアーキテクチャを設計します。 シフト左方向のアプローチを使用する場合は、 Microsoft Threat Modeling などのツールを使用して、脆弱性の設計をテストします。 開発を開始するときに、静的アプリケーション セキュリティ テスト (SAST) などのツールを実行し、他のアナライザーを使用して問題を明らかにすることで、ソース コードをスキャンできます。 アプリケーションをデプロイしたら、動的アプリケーション セキュリティ テスト (DAST) などのツールを使用して、ホストされている間にそれをテストできます。 機能テスト、カオス テスト、侵入テスト、その他の種類のテストは後で行われます。
次の点を考慮します。
- 開発ライフサイクル全体をカバーするテスト計画を作成していますか?
- 要件会議とアプリケーション開発ライフサイクル全体にテスト担当者を含めますか?
- テスト駆動設計または動作駆動設計を使用していますか?
- ユーザー ストーリーをテストしますか? ユーザー ストーリーに同意基準を含めますか?
- Microsoft Threat Modeling などのツールを使用して設計をテストしますか?
- 単体テストを記述していますか?
- 静的コード アナライザーまたはその他のツールを使用してコードの品質を測定しますか?
- 自動ツールを使用してアプリケーションをテストしますか?
- Secure DevOps プラクティスを実装していますか?
- 統合テスト、エンドツーエンドのアプリケーション テスト、ロード/パフォーマンス テスト、侵入テスト、カオス テストを行いますか?
マイクロサービスのセキュリティを評価する
サービス保護、セキュリティで保護されたアクセス、およびセキュリティで保護された通信は、マイクロサービス アーキテクチャの最も重要な考慮事項の 1 つです。 たとえば、複数のサービスにまたがるマイクロサービス ベースのシステムで、各サービスに対してトークン検証を使用することは、実行可能なソリューションではありません。 このシステムは、システム全体の機敏性と、サービス間で実装ドリフトを導入する可能性に影響します。
セキュリティの問題は、通常、API ゲートウェイとアプリケーション ファイアウォールによって処理されます。 ゲートウェイとファイアウォールは、受信要求を受け取り、トークンを検証し、トラフィックをインターセプトするための OWASP Top 10 原則の実装など、さまざまなフィルターとポリシーを適用します。 最後に、バックエンド マイクロサービスに要求を送信します。 この構成は、開発者がセキュリティに関する横断的な懸念ではなく、ビジネス ニーズに集中するのに役立ちます。
次の点を考慮します。
- サービスの認証と承認は必要ですか?
- API ゲートウェイを使用してトークンと受信要求を検証していますか?
- SSL または mTLS を使用してサービス通信のセキュリティを提供していますか?
- サービス間で必要な通信を許可するネットワーク セキュリティ ポリシーが設定されていますか?
- ファイアウォール (L4、L7) を使用して、内部および外部の通信のセキュリティを提供していますか?
- API Gateway でセキュリティ ポリシーを使用してトラフィックを制御していますか?
貢献者
この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。
主要な著者:
- オヴァイス・メフブブ・アーメッド・カーン |シニア クラウド ソリューション アーキテクト - エンジニアリング
- ナビル・シッディキ |クラウド ソリューション アーキテクト - デジタルとアプリケーションのイノベーション
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。