マイクロサービスとは
マイクロサービスが注目されてから数年が経過しました。その特性から中規模以上の企業が、マイクロサービスを導入しているように見受けられます。しかし多くのIT意思決定者にとって、マイクロサービスの本質的な理解や、ITアーキテクチャやソリューション開発のためにマイクロサービスとそのフレームワークが組織にもたらすベネフィットの把握が少し曖昧になっているのではないでしょうか。
マイクロサービスの基本的な考え方は、特定の開発言語に依存することなく、アプリケーションをその機能毎に小さく独立したサービスに分解することで、（より大きな）アプリケーションを作成することです。開発チームは、最も使い慣れている言語を使用できるだけでなく、アプリケーション開発プロセスに柔軟性や迅速性、拡張性を持たせることが可能です。マイクロサービスの考え方をベースに、大規模かつ複雑なアプリケーションを設計するならば、そのアプリケーションが持つべき複数の機能を、それぞれ小さな『組み立てブロック』に分割させます。その『組み立てブロック』を再び組み合わせることで、そのアプリケーションの全機能を搭載させることが可能になります。
そのためDevOpsも、マイクロサービスから大きな影響を受けています。アジャイルの開発サイクルは、「開発」と「運用」という別々のITエンティティであったものを1つのプロジェクトとして包括的に捉えています。
2016年の「MuleSoft Connectカンファレンス」で、NetflixのKatharina Probst氏とMuleSoftのUri Sarid（当時CTO）は、現在最も成功している企業（例えばマクドナルド、アンダーアーマー、Amazon、Tesla、Netflix、他）は、販売している商品とサービスだけではなく、商品とサービスそして体験をリアルタイムにお客様に提供するためのデジタルプラットフォームの構築能力を競っていると指摘しています。こうした企業は、一連の小規模なサービス群によりプロセスが構成されていることで、①他のプロセスやアプリケーションからの影響の回避、②お客様や従業員からの要望やニーズへの迅速な対応（機能追加や改善）、③機能の再利用や変更の最適化が可能になります。
マイクロサービスの採用により、組織はマイクロサービス特有の「きめ細かさ」と「利用性」を得られ、高い俊敏性の獲得とコスト削減を実現できます。ITアーキテクチャ構築のためのマイクロサービスのコンセプトは、優れたサポートテクノロジーや明確なコンセプトによって、多くの企業で実現されており、かつて不可能とされていたアプリケーション開発とデプロイに迅速性と効率性をもたらしてくれています。
マイクロサービスのコンセプトやテクノロジーには、コンテナやツール、プロセスの可用性を向上させるための「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部門の両方にモニタリングとガバナンスを提供しつつ、新しいソリューションの構築、共有、運用（アップデート含む）を可能にするオペレーションモデルを実現します。
競争が激化する今日のビジネス環境では、顧客および従業員、パートナーに喜ばれる体験を提供することで、競合よりも傑出しなければなりません。これを実現する鍵は、マイクロサービスです。包括的かつ管理可能な形でマイクロサービスの実現ができれば、マイクロサービスアーキテクチャは企業の技術標準になることでしょう。
マイクロサービスの実装を考えている場合は、このホワイトペーパーをご覧ください。