ポイント: マイクロサービスアーキテクチャは、迅速な納品とソフトウェア品質の向上の利点を提供しますが、複雑さの増加やセキュリティリスクなどの課題も引き起こします。組織は、特に小規模アプリケーションや未定義のドメインに対してマイクロサービスを採用するタイミングを評価するべきです。
- 設計とテストプロセスは、マイクロサービスによってより複雑になります。
- セキュリティ上の脆弱性と運用の複雑さは重要な課題です。
マイクロサービスアーキテクチャは、サービス指向アーキテクチャ (SOA) のバリエーションであり、ドメイン駆動設計の世界から進化した開発アプローチです。このアプローチは、次のことを可能にします。
- 効率的なコンピューティング
- レジリエントアプリケーションの構築を助ける
しかし、アプリケーション開発のアプローチには、それぞれ独自の課題があります。マイクロサービスフレームワークを用いたアプリケーション開発において、企業が複雑さと努力の増加に気づく場合もあります。この記事では、これらの課題について、いつマイクロサービスを使用すべきでないかも含めて説明します。
マイクロサービスの概要
マイクロサービスアプローチとは、アプリケーションを緩やかに結合されたサービスのグループとして設計・開発し、それぞれがビジネス目標を達成するために相互に通信することを意味します。広範な採用率 の上昇パターンは、企業がマイクロサービスを使用してアプリケーションを開発・展開する利点を享受している多くのユースケースがあることを確認しています。結局のところ、マイクロサービスはしばしばDevOps文化の受け入れへの第一歩と見なされます。これは次を可能にします。
- 自動化
- スケーラビリティの向上
- 管理性
- アジリティ
- 迅速な納品とデプロイメント
そのため、マイクロサービスアーキテクチャは従来のアプリケーションを最新のプログラミング言語とテクノロジースタックを使用して書き直すことを望む企業にとって通常の第一選択肢です。これらの利点を考慮すると、どのような課題が考えられるか疑問に思うかもしれません。
マイクロサービスアーキテクチャの課題
さて、マイクロサービスを採用する企業や製品チームからの最も一般的な課題に目を向けてみましょう。
設計
モノリシックアプリと比較して、組織はマイクロサービスを設計する際に複雑さが増します。初めてマイクロサービスを使用する際には、次の点を判断するのに苦労するかもしれません。
- 各マイクロサービスのサイズ
- 各マイクロサービス間の最適な境界と接続ポイント
- サービスを統合するためのフレームワーク
マイクロサービスの設計には、境界されたコンテキスト内でそれらを作成することが必要です。したがって、各マイクロサービスは特定の責任を明確にし、カプセル化し、定義するべきです。この責任/機能のために、開発者は通常、ドメインをモデル化する際にデータ中心の視点を使用します。このアプローチには独自の課題があります。ロジックがなければ、データは無意味です。
セキュリティ
マイクロサービスはしばしばマルチクラウド環境に展開され、アプリケーションコンポーネントのリスクと制御・可視性の喪失が増加します。これによって追加の脆弱なポイントが生じます。この課題を悪化させるのは、各マイクロサービスがさまざまなインフラストラクチャ層を介して他のサービスと通信するため、これらの脆弱性をテストすることがさらに困難になることです。
データセキュリティは、マイクロサービスベースのフレームワーク内でも重要な懸念事項です。このため、そのようなフレームワーク内のデータは分散しているため、ユーザーデータの機密性、整合性、プライバシーを維持することは難しい作業となります。分散フレームワークにより、アクセス制御を設定し、個々のサービスに対して安全な認証を管理することは、技術的な課題だけでなく、攻撃対象面も大幅に増加させます。
テスト
マイクロサービスベースのアプリケーションのソフトウェア開発ライフサイクル（SDLC）のテストフェーズはますます複雑になります。各マイクロサービスの独立した性質を考慮すると、各サービスを独立してテストしなければなりません。この複雑さをさらに悪化させるのは、開発チームもテストプランにサービスの統合や相互依存関係を考慮しなければならないことです。
運用の複雑さの増加
各マイクロサービスのチームは通常、使用する技術を決定し、それを管理する責任を負います。各サービスは独立して展開され、運用されるべきであるため、運用の維持は準備ができていない人にとっては難しい問題を引き起こす可能性があります。以下はその課題です。
- 従来の監視手法は、マイクロサービスベースのアプリケーションには効果がないかもしれません。 ユーザーインターフェースからのリクエストが複数のサービスを経由して、リクエストを満たすことができるサービスに到達するシナリオを考えてみてください。この経路の結果は、サービスの混乱したパスであり、適切な監視ツールがないと、問題の根本原因を特定することは難しいだけでなく、しばしば不可能です。
- スケーラビリティは、マイクロサービスアーキテクチャに関連するもう一つの運用上の課題です。 マイクロサービスのスケーラビリティはしばしば利点として称賛されますが、マイクロサービスベースのアプリケーションを成功裏にスケールさせることは挑戦的です。
- 最適化とスケーリングには、より複雑な調整が必要です。 典型的なマイクロサービスフレームワークでは、アプリケーションは小さな独立したサービスに分解され、別々のサーバーにホストされ、展開されます。このアーキテクチャでは、個々のコンポーネントを調整する必要があり、特にアプリケーションの使用が突然増加する場合にはもう一つの課題です。
- すべてのサービスには耐障害性が必要です。 企業は、マイクロサービスが内部および外部の障害に耐えられるほどのレジリエンスを必要としています。マイクロサービスベースのアプリケーションでは、1つのコンポーネントの故障がシステム全体に影響を与える可能性があります。したがって、使用するフレームワークは、個々のサービスのダウンタイムの際にアプリケーション全体の故障を防ぐ設計を考慮すべきです。
コミュニケーション
独立して展開されたマイクロサービスは、相互に通信するミニチュアのスタンドアロンアプリケーションとして機能します。これを達成するには、サービス間でリソースを共有するためのインフラストラクチャ層を構成する必要があります。設定が不適切であると、次のようなことが生じる可能性があります。
- レイテンシの増加
- 異なるサービス間の呼び出し速度の低下
この状況では、最適化されていないアプリケーションが遅い応答時間を持つことになります。
マイクロサービスを使用しないべき時
新しいフレームワークに移行するすべての組織は、それが適切かどうかを確認するために徹底的なデューデリジェンスを行う必要があります。マイクロサービスを検討する際には、次の3つの状況が、マイクロサービスアーキテクチャを選ばないべき時を判断するのに役立ちます。
定義されたドメインが不明確/不確実
マイクロサービスは境界されたコンテキスト内で作成されることを思い出してください。したがって、ビジネス要件を特定のドメインに分解することが論理的に複雑であれば、適切なサイズのマイクロサービスを作成することも同様に困難です。さらに、異なるサービス間の適切な通信手段を設計することの課題も考慮すると、この複雑さはマイクロサービスの最大の利点を実現するには過剰な可能性があります。また、未来も考慮してください。今後数年間、アプリケーションのドメインが変わらないことを確信していない場合は、マイクロサービス指向のアプローチを使用しない方が賢明です。
効率の向上は保証されていない
繰り返しになりますが、マイクロサービスを採用するという考えは、DevOps文化を受け入れることであり、それによって：
- 自動化を利用する
- コストと努力を削減する
- 運用効率をもたらす
マイクロサービスフレームワークへの移行が実際にこれらの目標を達成するのに役立つかどうかを確認するために、デューデリジェンスを行ってください。どの組織も、改善された効率を得ることなく文化を採用するために複雑さと努力を追加したくはありません。
アプリケーションのサイズが小さいまたは単純
アプリケーションのサイズが多数の小さなコンポーネントに分割する必要性を正当化しない場合、マイクロサービスフレームワークを使用することは理想的ではないかもしれません。すでに小さすぎるアプリケーションをさらに分解する必要はありません。マイクロサービスフレームワークを使用するという考えは、複雑なアプリケーションを異なる小さなサービスの束に分解することです。アプリケーションコードがすでに十分に小さく、単純である場合、マイクロサービスフレームワークへの移行は複雑さを追加するだけになります。
マイクロサービスは私に合っていますか？
マイクロサービスアーキテクチャを採用することで迅速な納品とソフトウェア品質の向上が得られる一方で、このアプローチを選択するかどうかを慎重に検討する必要があります。モノリシックからマイクロサービスモデルへの移行の利点は数多くありますが、考慮すべき課題もあります。マイクロサービスを選択するための一般的な目安は：
マイクロサービスを使用することの欠点が利点を上回り、または利点がかけた労力とお金に比べて微々たるものである場合、マイクロサービスはおそらくアプリケーションにとって適切なアプローチではありません。.
関連する読書
これらの投稿は私自身の見解であり、BMCの立場、戦略、意見を必ずしも代表するものではありません。