マイクロサービスとは

マイクロサービスとは

マイクロサービスとその関連アーキテクチャは、規模を問わずあらゆる企業の注目を集めています。しかし、ITの意思決定者の多くは、マイクロサービスが実際にはどういったものかや、現代の企業におけるITソリューションの開発にマイクロサービスフレームワークがどのような意味を持つかをまだよく理解していません。DevOpsでも、マイクロサービスが大きな影響力を持つようになりました。アジャイル開発サイクルにより、かつて分かれていた開発と運用の2つITエンティティが、共通で実行されるプロジェクトのイデオロギーに統合されてきているのです。

マイクロサービスは、企業のアプリケーションを作成するための新しい方法として、非常に高いレベルで概念化することができます。この方法では、アプリケーションがより小規模な独立したサービスに分割され、特定のコーディング言語に依存しません。つまり、開発チームは、最も使い慣れている言語ツールを使用しつつ、アプリケーション開発プロセスの相乗効果を実現することができるのです。マイクロサービスのイデオロギーを使用すると、大規模で複雑なアプリケーションを実行可能ファイルの小さなビルディングブロックに分割することができ、これを再構成することで、大規模で非常に複雑なアプリケーションのすべての機能が利用できます。

2016年のMuleSoftのCONNECTカンファレンスで、NetflixのKatharina Probst氏とMuleSoftのCTO、Uri Saridは、McDonalds、Under Armour、Amazon、Tesla、Netflixなどの現在最も成功している企業は、販売する商品やサービスだけでなく、そうした商品、サービス、体験を革新的な方法で大規模かつリアルタイムに顧客に提供できるデジタルプラットフォームとしての実力でも、優位に競争を展開していると述べています。こうした企業は、企業自体をプロセスに組み込んだ小規模なサービスを作り出すことにより、これを可能にしています。このサービスは独立して進化し、必要なときに迅速に構築できるだけでなく、変更と再利用のために最適化することができます。

マイクロサービスを採用することで、組織は、マイクロサービスの持つ本質的なきめ細やかさと再利用性により、俊敏性を高め、コストを削減することができます。多数のサポートテクノロジーとイデオロギーによって、かつて不可能と見られていた俊敏性と効率性がアプリケーションの開発とデプロイメントにもたらされたことで、あらゆる規模の企業がマイクロサービスベースのアーキテクチャのコンセプトを実現できるようになりました。

こうしたコンセプトとテクノロジーには、SOAベースのプロセスの達成を支援するコンテナ、ツール、およびプロセスの可用性の向上や、ドメイン駆動型の設計プロセスなどがあります。これらを組み合わせることで、コードのガバナンスよりもコラボレーションに重点を置いた開発環境を作り出し、生産性を向上させることができます。

マイクロサービスアーキテクチャの定義

マイクロサービスアーキテクチャのスタイルでは、単一のアプリケーションを、焦点を絞った、個別にデプロイ可能な小規模サービスのグループとして開発するイデオロギーが利用されています。各マイクロサービスは、独自のプロセスで実行され、HTTPリソースAPIなどの軽量なメカニズムと通信します。これらのサービスは、特定のビジネス機能を持つようにカプセル化され、完全に自動化されたメカニズムを使用して個別にデプロイされます。

マイクロサービスは、クラウドベースのサービスへの移行に合わせて実装することができます。クラウドベースのサービスでは、複数のアプリケーションを共有の一連のサービスによって駆動させることができます。マイクロサービスベースのアーキテクチャは、パブリック/プライベート/ハイブリッドクラウドの実装に有用であることが証明されています。これは、RESTful APIなどの軽量なインターフェースを使用して、小規模な独立したサービス一式を使用するというコンセプトを利用できるためです。

マイクロサービスベースのアーキテクチャのコンセプトは、初期のSOA(サービス指向アーキテクチャ)まで遡ると言われています。これは、UDDI(Universal Description, Discovery, and Integration)に基づいたサービスの検出と匿名サービスの使用に重点を置いたもので、この原則は今日でも有効です。しかし、マイクロサービスでは、これを数歩先へ進め、RESTful APIと仮想化されたプラットフォームとコンテナを使用してハイブリッドサービス統合を構築します。これは、モノリシックな単一のコードベースのアプリケーションに取って代わるものです。モノリシックアプリケーションに関連する体験を生み出すのは、こうした独立したサービスの集まりです。SOAは、当初考えられていたように、そのアプローチを実行するのに適切なビルディングブロックが簡単に利用できなかったために失敗しました。

しかし、SOAの原理に基づいて構築されたマイクロサービスは、マイクロサービスアーキテクチャの3つの主要なビルディングブロックを構成する新しい技術が導入されたことで現実のものとなりました。これらのビルディングブロックがすぐに利用可能で、確立されていることにより、以下のようなメリットがもたらされます。

  • コンテナ:基盤となるハードウェアから核となるOSのコードを抽象化することで、ソフトウェアコンテナによってすべてのサービスに標準化されたフレームが作成されました。コンテナによる標準化により、異種環境のインフラストラクチャの世界での、かつての苦痛な統合プロセスをなくすことができます。Dockerなどのベンダーの貢献により、コンテナは開発者のアプリケーションの構築とデプロイの方法に革命をもたらしました。
  • API:APIが普及し、その機能が向上したことで、アプリケーション、サービス、およびサーバー間の通信のための堅牢で標準化された形式が生まれました。特にREST(Representation State Transfer)APIは、マイクロサービスアーキテクチャの鍵となるものです。RESTful APIでは、トランザクションが一連の小さなモジュールに分割され、それぞれがトランザクションの基礎となる特定の部分に対応します。このモジュール性が、ブラウザベースのアプリケーションに適した軽量なAPIを開発するための、高い柔軟性を開発者にもたらします。
  • スケーラブルなクラウドインフラストラクチャ:パブリック/プライベート/ハイブリッドクラウドインフラストラクチャのすべてにおいて、負荷や関連するトラフィックにかかわらず、オンデマンドでのリソースの提供と、サービス提供のための効果的な拡張が可能になりました。これがマイクロサービスに弾力性をもたらし、順応性と効率性の向上につながります。

マイクロサービスアーキテクチャのリスク

新しいアーキテクチャのトレンドは、それがどのようなものであれ、IT問題の特効薬として見なされ、IT運用モデルやインフラ、開発者スキルセットのような前提条件を考慮せずに「最新のもの」として導入されてしまう危険がつきまといます。

マイクロサービスアーキテクチャの戦略では、最大限の成果を創出できるよう慎重で計画的なアプローチをとる必要があります。そのため、具体的なビジネスドメインに対する機能をカプセル化するようにマイクロサービスを設計、構築するのに加え、セキュリティを念頭に置くことが強く推奨されます。これを行わないと、開発者の単独の行動が原因で、マイクロサービスのモノリシックなグループを構築してしまうリスクがあります。つまり、モノリスのすべての問題点を持つ、共通点のない不規則なマイクロサービスを構築したり、ディストリビューションがさらに複雑になったり、その投資に対する総体的リターンが縮小したりといったことが起こりかねません。マイクロサービスの導入を検討している組織の開発チームは、取り組みを調整し、明確な計画に従う必要があるのです。 

また、継続的デリバリーのための厳格な規律を確立し、リリースパイプラインの自動化のために必要なツールを用意することも推奨されます。DevOpsスタイルのチームの協調と自動化が欠如していると、マイクロサービス戦略からはメリットよりも苦痛のほうが多くもたらされることになります。 

マイクロサービスアーキテクチャへのプラットフォームのアプローチ

マイクロサービスは明らかに、ソフトウェア開発において重要かつ歓迎すべきトレンドであり、これまでのアーキテクチャアプローチを超える多くのメリットがあります。しかし、自社にマイクロサービスを導入するにあたっては、知っておくべきさまざまなポイントがあります。企業がマイクロサービスを導入する際は、その開発のしやすさと迅速性がプラスになるように導入する必要があります。これを適切に管理できなれば、このアーキテクチャによって、かえって統制が崩れ、ガバナンスが低下することにもなりかねません。マイクロサービスアーキテクチャで開発された製品は、従来のテクノロジースタックと統合する必要もあります。これがうまくできなければ、IT部門では技術的な負担やオペレーションコストが拡大してしまうかもしれません。したがって、競争優位性を創出し、自社のイノベーションを促進できるようにマイクロサービスに着手することが大切で、これは単なる製品やソフトウェアの選択とは次元が異なります。また社内の人、プロセス、および文化的要素も考慮する必要があります。マイクロサービスに、API主導の接続性を中心とした包括的なプラットフォームアプローチが推奨される理由もそこにあります。API主導の接続性では、企業のテクノロジースタックの適切な活用に極めて重要な包括的コンポーネントが提供されますが、それだけでなく、中央のITチーム内外の開発者も、管理や再利用、および統制が可能な方法で新しいソリューションを作成できるため、組織でコントロールできないほどの大量のアプリケーションに対する懸念が払拭されます。MuleSoftのプラットフォームのアプローチには、新しいソリューションが社内のどこで必要とされようと、LOBおよびIT部門のいずれも、必要な可視性とガバナンスを維持しつつ、構築、導入および提供を可能にする独自の運用モデルがあります。競争が極めて激しい現代のビジネス環境では、傑出すること、そして顧客、従業員、パートナーに喜ばれる体験を提供することが重要になります。企業がこれを実現する鍵は、マイクロサービスにあります。このマイクロサービスを包括的かつ管理可能な形で実現することができれば、マイクロサービスアーキテクチャは企業の技術標準になるでしょう。

マイクロサービスアーキテクチャを実装するためのベストプラクティスについてのさらなるリソースは、こちらをご覧ください。