マイクロサービスとは

Microservices and their related architectures are gaining traction in enterprises of all sizes. However, many IT decision makers are still in the dark as to what microservices actually are and what a microservices framework means to the development of IT solutions in today’s enterprises. For DevOps, Microservices are also having a major impact. The agile development cycle is bringing together what were two separate IT entities, development and operations, into a commonly executed project ideology.

At a very high level, microservices can be conceptualized as a new way to create corporate applications, where applications are broken down into smaller, independent services, that are not dependent upon a specific coding language. In other words, development teams are able to use the language tools they are most comfortable with and still achieve synergy in the application development process. Using the ideology of microservices, large complex applications can be divvied up into smaller building blocks of executables, that when recomposed offer all of the functionality of a large scale, highly complex application.

At MuleSoft’s Connect conference in 2016, Katharina Probst from Netflix and Uri Sarid, CTO of MuleSoft, made the point that the most successful businesses now, e.g. McDonalds, Under Armour, Amazon, Tesla, and Netflix, are not only competing on the goods and services they sell, but also on their ability to be digital platforms, providing innovative ways of getting those goods, services, and experiences to customers at scale and in real-time. They are able to do this by creating small services that compose themselves into processes, that evolve independently, can be built as quickly as they are needed, and are optimized for change and reuse.

Adopting microservices allows organizations to achieve greater agility and realize lower costs, thanks to the inherent granularity and reusability of what constitutes a microservice. A plethora of supporting technologies and ideologies  have made the concept of microservice-based architectures a reality to businesses of any size, bringing agility and efficiencies to application development and deployment once deemed impossible.

マイクロサービスのコンセプトやテクノロジーには、コンテナやツール、プロセスの可用性を向上させるための「SOAベースのプロセス」や「ドメイン駆動型の設計プロセス」が含まれています。（注：SOAとは、サービス指向アーキテクチャ（Service Oriented Architectureの略）

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

マイクロサービスアーキテクチャは、アプリケーションを「小さく」「狭く」「独立して」デプロイできるサービスの組み合わせとして開発する、という思想を現実化させたものです。各マイクロサービスは独自のプロセスで実行され、HTTPリソースAPIといった軽量なメカニズムで通信します。これらのサービスは、特定のビジネス機能を持つようにカプセル化され、完全に自動化されたメカニズムによって個別にデプロイされます。

マイクロサービスは、ITインフラのクラウドへの移行と並走させて実装することができます。そして、マイクロサービスベースのアーキテクチャの実装は、パブリッククラウド、プライベートクラウドおよびハイブリッドクラウドの全てにおいて有用であることが分かっています。これは「小さくて独立した（一連の）サービスを使用する」というマイクロサービスのコンセプトを、RESTful APIなどの軽量なインターフェースを用いて実現することが可能だからです。

マイクロサービスベースのアーキテクチャのコンセプトは、初期SOAに遡ると言われています。初期のSOAは、UDDI（Universal Description, Discovery, and Integration）に基づいた、サービスの検出と匿名でのサービス利用を原則としていました。もちろん、このコンセプトは、今日でもとても有効です。

さらにマイクロサービスでは、このコンセプトを数歩前進させています。具体的には、「RESTful API」と「仮想化プラットフォームやコンテナ」を使用して、単一コードで造られているモノリシックなアプリケーションに代わるハイブリッド・インテグレーション・サービスの構築を実現させています。独立したサービスを組み合わせることで、モノリシックなアプリケーションと同じ体験を、お客様や従業員に提供することができるのです。SOAが当初の期待に反して失敗したのは、その優れたコンセプトを実行するための適切な組み立てブロックの入手が簡単ではなかったからに他なりません。

上記のSOA原理に基づいたマイクロサービスが実現化できるようになったのは、組み立てブロックを構成するための3つの新技術（コンテナ、API、（拡張可能な）クラウドインフラストラクチャ）がマイクロサービスアーキテクチャに導入されたことが大きく影響しています。これら3つの新技術を、そのメリットと一緒に紹介します。

• コンテナ：コンテナによってアプリケーションの動作環境を、仮想的に構築することができます。アプリケーションと当該アプリケーションが一緒に動くために必要なミドルウェアとOSの一部（ファイルシステムやライブラリなど）がパッケージ化されています。コンテナを利用することにより、すべてのサービスに標準化されたフレームが作成されます。特筆すべきなのは、コンテナによる標準化によって、異機種混在のインフラ上で、かつては面倒だったインテグレーションプロセスが不要になりました。Dockerなどのサプライヤーの登場は、アプリケーション開発とデプロイに革命をもたらしたのです。
• API：APIの普及と大幅な機能向上により、アプリケーション、サービスおよびサーバ間の通信に、堅牢で標準化された形式が生まれました。特にREST　APIはマイクロサービスアーキテクチャの鍵となります。REST APIは、トランザクションが一連の小さなモジュールに分割され、それぞれがトランザクションの基礎となる特定の部分に対応します。このモジュール性により、開発者は高い柔軟性を得ることができます。また、その軽量性と柔軟性により、ブラウザで動くアプリケーションにとって最も適したAPIとなっています。
• （拡張可能な）クラウドインフラストラクチャ：すべてのクラウドインフラ（パブリッククラウド、プライベートクラウド、ハイブリッドクラウド）は、負荷やトラフィックに影響されず、オンデマンドによるリソースの提供が可能になるだけでなく、サービス提供のための拡張もできるようになりました。マイクロサービスアーキテクチャに『弾力性』がもたらされることで、『順応性』と『効率性』が向上しました。

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

新しいアーキテクチャのトレンドには、それがどのようなものであれ、IT問題の特効薬として見なされ、運用モデルやインフラ、開発のスキルセットのような前提条件が無視され、『最新のモノ』として導入されてしまうことがあります。

マイクロサービスアーキテクチャの戦略では、最大限の成果を出せるように慎重で計画的なアプローチをとる必要があります。MuleSoftでは、特定のビジネスドメインのための機能をカプセル化し、セキュリティを強化したマイクロサービスを設計・構築することを強く推奨しています。そうしないと、開発者の単独行動が原因でモノリシックなマイクロサービス群が構築されてしまうことになってしまうからです。つまり、他と共有できない不規則なマイクロサービスが構築されれば、モノリシックアプリケーションと変わらない（組織内外への）ディストリビューションが複雑なアーキテクチャが構築されてしまうのです。その結果、期待した投資効果が得られないというリスクが大きくなります。そこで、マイクロサービスの導入を検討している組織は、開発チームとの協議を経て、彼らに明確な導入計画を遵守してもらうことが必須となります。 

また、継続的なデリバリーのための厳格な規律を確立し、リリースパイプラインの自動化のためのツールを用意することを推奨します。DevOpsスタイルのチーム連携と自動化が欠如していると、マイクロサービスのイニシアティブは利益ではなくペイン（苦痛）を組織に与えることになってしまうのです。 

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

マイクロサービスは、これまでのアーキテクチャ・アプローチと比べても多くの利点を有し、ソフトウェア開発において重要かつ歓迎すべきトレンドであることは明らかでしょう。アプリケーション開発やその後のアップグレードの容易性と、アジャイルの導入からマイクロサービスアーキテクチャが必須条件となっている組織も増えつつあります。しかし、そのためには事前に知っておくべきポイントが複数あります。以下に代表的な例を示します。

マネジメントの設計とオペレーション：適切な管理とオペレーションが実施されなければ、アーキテクチャが無秩序となりガバナンスも欠如してしまいます。

既存のレガシーシステムとのインテグレーション：多くの組織が既存のレガシーシステムの継続利用を前提にマイクロサービスを採用することと思います。しかし、インテグレーションが適切に設計・実装されないと、後々、ITチームに技術的負債と追加の運用コストが発生する可能性があります。

イノベーションを加速させ、競争優位の獲得を目的にマイクロサービスを導入することは、単純な製品やソフトウェア、プラットフォームの選択とは次元が異なります。社内の人材やビジネスプロセス、文化も考慮しなければなりません。

MuleSoftが、『API主導の接続性』という包括的なプラットフォームアプローチを提唱している理由も、このマイクロサービスが提唱する網羅性にあります。API主導の接続性によって、テクノロジースタックを有効活用するために極めて重要な包括的コンポーネントの提供が可能になりました。また、セントラルIT部門内外の全開発者が、管理や再利用が可能で統制のとれた方法で新しいソリューションの構築も可能になります。そのため、組織ではコントロールできないほどの大量のアプリケーションが存在しているという心配を払拭することができるのです。MuleSoftのアプローチでは、事業部門とIT部門の両方にモニタリングとガバナンスを提供しつつ、新しいソリューションの構築、共有、運用（アップデート含む）を可能にするオペレーションモデルを実現します。

競争が激化する今日のビジネス環境では、顧客および従業員、パートナーに喜ばれる体験を提供することで、競合よりも傑出しなければなりません。これを実現する鍵は、マイクロサービスです。包括的かつ管理可能な形でマイクロサービスの実現ができれば、マイクロサービスアーキテクチャは企業の技術標準になることでしょう。

マイクロサービスの実装を考えている場合は、このホワイトペーパーをご覧ください。