自然界では、大きいほど良いとは限りません。ホホジロザメは海の王者とも呼ばれますが、小さな魚の群れは集団で行動することで、どの単一生物よりも生存して繁栄する能力があります。事実、コラボレーションによる成功は、動物界に共通するテーマでもあります。たとえば、アリの巣や蜂の巣、オオカミの群れなどは、緩やかに結合したシステムで行動することで制御を分散させ、共通の目標を達成できます。また、コロニーや巣箱、群れのメンバーが死んでも、残りのメンバーが機能を継続し、損失を補うことができます。
マイクロサービスは、このようなアプローチをソフトウェア開発やシステム構築に応用したものです。これは、多くの場合、多数のコンポーネント機能やサービスを個別に構築する方が、自己完結型で完全に相互接続されたシステムに同じ機能をインストールするよりも、短時間で済み、簡単で安全、効率的であるという考え方です。ここでは、マイクロサービスの特徴、メリット、課題などについて詳しく説明します。
おそらく、マイクロサービスとは何かを理解するための最良のアプローチは、まずマイクロサービスで「ないもの」を確認することでしょう。マイクロサービスと他の組織的アプローチとの間には、いくつかの違いがあります。ここでは、マイクロサービスと従来のモノリスアーキテクチャ、さらには最新の「サービス指向アーキテクチャ」(SOA) とを比較します。
「モノリス」とは、その名が示すように、各コンポーネントが相互接続され、隣接するコンポーネントに依存する大規模で統一されたアプリケーションのことです。モノリスは、すべての機能を一元的に管理して提供し、すべてを単一のコードベースで構築する、伝統的な開発手法です。モノリス構造に変更を実装する場合は、必然的にスタック全体を変更することになります。テストなどのアクティビティは、スタック全体にも適用されるため、変更は大規模なリリースにまとめられ、開始から終了までに比較的長い時間がかかることがあります。マイクロサービスは、モノリスとは異なり、自己完結型で緩やかに結合した多数の小さなコンポーネントで構成されています。そのため、アプリケーション内の他のサービスに影響を与えることなく、個々のコンポーネントで変更を実装できます。
マイクロサービスと SOA の違いは、さほど大きなものではありません。どちらも異なるアプリケーションにモジュール式に適用できる、再利用可能なコンポーネントに依存していますが、SOA はそれほど粒度が大きくはありません。マイクロサービスは、各サービスが単一機能のみを実行する程度までコンテナ化されているのに対し、SOA コンポーネントは、さまざまなビジネス機能に対応する完全なサブシステムにできます。さらに、SOA ではコンポーネントの共有や依存関係が最適化されますが、マイクロサービスではこれらを可能な限り最小限に抑えようとするだけです。
一般的に、マイクロサービスには以下のような特徴があります。
マイクロサービスは、個々の独立したサービスの集合体として設計されているため、独立したコンポーネントとして簡単にテストできます。コンポーネント内の問題を迅速に切り分けられるため、システム全体やアプリケーションをテストしてから、膨大な時間をかけて特定の障害を切り分ける必要がありません。
マイクロサービスが連動して機能するには、マイクロサービス相互の通信を維持する必要があります。ただし、この場合の相互接続は「緩やかな」接続であり、1 つのサービス内で変更が実装されても、別のサービスには直接影響しません。
サービス間でデータストアを共有するのではなく、構成するコンポーネントごとにデータストアを維持します。こうすることで、異なるサービスの偶発的な結合を防ぎ、変更が意図せず他の独立したサービスに影響を与えないようにできます。
他のサービスを採用することなく、個々のサービスを変更し、本番環境に展開できます。システム内のすべての展開がこのような方法で管理されているので、マイクロサービスの拡張を非常に迅速に実行できます。
マイクロサービスでは、1 つのビジネス目的のために組織された部門横断型のチームを利用します。これらのチームは、開発者、データベースエンジニア、テスター、インフラストラクチャエンジニアなどで構成されることが多く、複数の独立したサービスをベースに特定の製品を開発することを目的としています。
マイクロサービスでは、独立したそれぞれのサービスで、要求の受信、処理、応答ができます。そのため、複雑なルーティングやビジネスルールのアプリケーションレイヤーが原因でプロセスが遅くなるような従来型システムの多くに比べて、非常に簡素化されています。
マイクロサービスシステムが完全に機能しなくなるのは、基本的にその独立したサービスのすべてが同時に機能しない場合です。緩やかに接続されたサービスに依存することで、システムのいずれかのサービスに障害が発生しても、最適に近いキャパシティで運用を継続できます。サービスが分散化しているため、1 つのサービスがなくなっても、隣接するサービスにはほとんど影響がありません。
マイクロサービスは、本来、モジュール化されているので、必要に応じて新しいサービスを追加することが比較的容易です。そのため、企業は現在のシステムを新しい用途に適応させ、デマンドの変化に応じてシステムをスケールアップまたはスケールダウンできます。
新しいサービスを開発する場合、企業はさまざまなテクノロジースタックを自由に選択できます。同時に、既存のサービスを変更する場合も、新しいテクノロジースタックが採用されることがあります。
マイクロサービスが相互に直接通信することも可能ですが、多くの企業は API ゲートウェイを統合することで中間レイヤーとして機能させ、要求のルーティングや追加認証の提供、セキュリティの強化を実現したいと考えています。API 通信は、マイクロサービスが最初に状態を確立するときに、特に効果的かもしれません。
マイクロサービスは、従来の開発アーキテクチャからの転換を意味し、従来の組織的なアプローチより多くのメリットをもたらします。以下にそのメリットを示します。
マイクロサービスは、小規模で独立したチームが、明確に定義された状況に応じて活動できるようにします。その結果、より多くのことをより短時間で達成できるようになり、予期せぬ変化に対応できるアジリティが向上します。
マイクロサービスは、複雑なアプリケーションやシステムを、より小規模でシンプルな構成要素に分解します。開発者はサービス間の違いを理解しやすくなり、必要な更新や改善もしやすくなります。
開発者は、単一の言語やテクノロジースタックに縛られずに、サービス間の通信に及ぼす影響を気にすることなく、個々の機能に応じて最適なソリューション、ツール、リソースを自由に選択できます。
マイクロサービスベースのアプリケーションは、高度にモジュール化されているため、開発や展開が比較的簡単です。チーム間で連携して、個々の小さなコンポーネントで同時に作業し、それぞれのコンポーネントを独立して展開できます。
従来のアプリケーションアーキテクチャでは多くの場合、変化する需要に対応するためにアプリケーション全体を拡張する必要がありました。マイクロサービスの場合、開発者は対象となるサービスやコンポーネントに限定した拡張にリソースを割り当て直すことができるため、拡張が高速化され、関連コストを削減できます。
1 つのマイクロサービスで障害が発生しても、隣接するマイクロサービスには影響が及びません。マイクロサービスベースのアプリケーションは、クラッシュしにくいため、1 つまたは複数のコンポーネントに障害が発生しても、影響を受けたサービスが修復されるまで、アプリケーション自体は機能を制限しながら動作し続けることができます。
各サービスは自己完結型で、特定の機能を独立して実行するように設計されているため、開発者はサービスを再利用して、多くの異なるアプリケーションに使用できます。コンポーネントは「構成要素」として機能するため、新しいプロジェクトのたびにゼロから新しいコードを作成する必要性が大幅に減ります。
アジリティの向上、再利用性の向上、展開の簡素化により、開発サイクルと商品化までの期間が短縮されます。これが、ビジネスリターンの向上と、より満足度の高いユーザーエクスペリエンスの提供につながります。
マイクロサービスのメリットは、同時に困難も伴います。ここでは、マイクロサービスアプローチを導入する際に、企業が直面する可能性のある課題について詳しく説明します。
マイクロサービスへの移行には、サービス間のあらゆる依存関係を特定し、カタログ化することが必要です。1 つのビルドを完了した後に、依存関係が原因で他の多くのビルドの実装が必要になる可能性があります。このため、ストレスや作業時間が増える場合があります。
マイクロサービスの重要な要素は、各コンポーネントがそれぞれ独立したデータベースを持つことですが、新しいデータベースができるたびに、管理は複雑化します。導入されるサービスやデータベースの数が増えれば増えるほど、データ自体の管理が不便になります。
マイクロサービスを使用してアプリケーションを新しいバージョンに更新する場合、後方互換性に影響を及ぼす可能性があります。条件付きロジックを組み込んだり、異なるクライアント向けに複数のライブバージョンを立ち上げたりするソリューションは、メンテナンスや管理の面で過度に複雑になる場合があります。
マイクロサービスは、展開の簡素化を目的に設計されていますが、多数の独立したコンポーネントの連携には複雑化が伴い、手に負えなくなることがあります。この問題は、自動化で解決できる場合があります。
各サービスで独自のデータベースを使用する場合は、ログ記録が困難になることがあります。そのため、一元的なログ記録ソリューションの確立が必要になる場合があります。同様に、各サービスの監視と管理も、一元的なビューと単一の信頼できる唯一の情報源がなければ、実現が不可能になる場合があります。
1 つのアプリケーションに多数のマイクロサービスが組み込まれている場合、従来のデバッグでは対応できません。
マイクロサービスアーキテクチャを導入することで、チームにはかなりの独立性が生まれますが、アプリケーション内の複数サービスにまたがる問題を解決するには、チーム間の詳細なコミュニケーションと調整が必要になります。
マイクロサービスアプリケーションは分散システムであるため、チームが知らないうちにタスクが重複していることがよくあります。その結果、無駄な労力や非効率なアプリケーションを生み出すことになりかねません。
上記の課題に加えて、マイクロサービスアーキテクチャの導入を検討する場合は、以下の落とし穴に注意する必要があります。
マイクロサービスは、開発アーキテクチャのアプローチとして非常によく知られていますが、一般的には、過度に複雑化して維持が難しくなった既存のアプリケーションの修復や訂正に最適です。出発点としてマイクロサービスを使用しても、さほど効果的ではありません。従来のアプローチが手に負えないレベルに達していなければ、実際には再構築が必要なモノリスではありません。
他の場合と同様、サービスはいつでも小さな部分に分割できます。マイクロサービスは、全体的なサポートを目的として設計された限定的な機能で構成され、細分化する必要がありますが、細分化し過ぎることがあります。それを回避するには、大規模なサービスから始めて、展開に時間がかかる場合や管理が複雑化し過ぎた場合にのみ、マイクロサービスに分解することで、ソリューションのメリットが損なわれないようにする必要があります。
大規模な分散システムは、すぐに手に負えなくなることがあります。マイクロサービスの有効性を確保するには、高度な展開と監視の自動化、さらにはマネージドクラウドサービスを取り入れる必要があります。その結果、マイクロサービスへの移行に伴う負担を大幅に軽減できます。
ServiceNow は、マイクロサービスを活用して構築されたサービスの管理面の支援だけでなく、CI/CD やその他の DevOps ソリューションなど、構築フェーズで使用される手法やツールとの連携による支援も提供できます。
ServiceNow は、大量の潜在的マイクロサービスとその過渡的性質を考慮し、関係を追跡してサービスの定義を維持するのに役立つ、CMDB と Service Graph への自動入力オプションを提供しています。これは、より広範なクラウド管理機能も提供する IT Operations Management 製品の一部です。
DevOps プラクティスで開発されたコードと同様、マイクロサービスのメンテナンスに共通する目標は、開発者と本番システムの間に最速パスを提供するといった迅速さです。ただし、大企業や規制対象の組織は、強力な変更管理体制を維持する必要があります。そのため、IT Service Management Professional には、CI/CD パイプラインに接続し、開発プロセスで情報を収集し、事前定義されたポリシーと併用して変更管理プロセスを自動化する、DevOps Change Velocity 機能が含まれています。
最後に、ServiceNow は、ServiceNow ワークフローの一部として外部のマイクロサービスとの統合をサポートするだけでなく、マイクロサービスのような方法で内部と外部のアプリケーションで利用できる豊富な機能も提供しています。
ServiceNow AI Platform には、ワークフローを迅速、効率的にデジタル化して大規模に実行できるコア機能が含まれています。