マイクロサービスとサービス・メッシュ（Istioが求められる背景）

クラウド・ネイティブ・コンピューティング

かつてICT（Information and Communication Technology）は、企業のバックオフィスを担うツールでした。銀行のATMを例に取るまでもなく、ICTが社会基盤の重要な構成要素であったことは確かですが、商談、契約、納期調整、検収、アフターサービスといったビジネスの主要な局面を担うのは、あくまでも「人」であり、ICTはビジネスの各局面を効率的に運営する脇役でした。しかしインターネットの登場で、「人が主役でICTは脇役」というビジネス上の役割分担に変化が生じます。企業と消費者を直結するインターネットは、マーケットの構造を根本的に変えました。対面型の商談のような時間を要するビジネス・プロセスを排除し、ユビキタス、スピード、リーズナブル、柔軟性といったこれまでになかった付加価値を、いかに迅速に提供するか。そこが勝負のポイントになっています。UberやAirbnb、そしてFintechに見られるように、消費者が対価を支払うのはICTシステムのサービスに変化しつつあるのです。

すなわち私たちは、ビジネスの主体が人からICTシステムに代わるデジタル・ビジネス時代の草創期を生きていると言って良いでしょう。消費者の嗜好は多様であり、その消費傾向を予測するのは難題です。ビジネスで成果を挙げるには、まずは素早くマーケットに投入し、消費者からのフィードバックに合わせて柔軟に改善する、というルーチンを運用することになります。つまりデジタル・ビジネスの成功には、スピードとメンテナンスに対する柔軟性を兼ね備えたICTシステムが必要なのです。

クラウド・コンピューティングは、ICTの基盤の観点より、スピードと柔軟性という2つの要件に応えてきました。かつて数週間～数ヶ月を要した基盤構築は、クラウド・プラットフォームの提供する仮想化や自動化の技術革新によって、今や数秒～数時間のオーダーで実現できます。一方、アプリケーション開発はどうでしょう？　アプリケーションがスピーディにリリースされないことには、いくら基盤が早く構築できても意味がありません。このような背景の下で、アプリケーションの作り方もクラウド基盤の性質に見合ったものにトランスフォーメーションするという発想が生まれました。リーン・スタートアップや、アジャイル開発、SOAやオブジェクト指向で培ったサービスを単位としたコンポーネント化（これが「マイクロサービス・アーキテクチャー」の出発点となります）等、すでにある手法や技術を組み合わせて、場合によっては新たな手法を加えつつアプリケーション・アーキテクチャーや開発手法のモダナイゼーションの試みが現在進行中です。こうした試みを経てクラウド基盤に最適化されたアプリケーションを、クラウド・ネイティブ・アプリケーション、そしてクラウド・ネイティブ・アプリケーションとクラウド基盤をあわせたICTのトレンドをクラウド・ネイティブ・コンピューティングと呼びます。

ICT業界には、クラウド・ネイティブ・コンピューティングを主要なテーマに取り上げ、クラウドの普及促進をコミットしている業界団体があります。それがCloud Native Computing Foundation（CNCF）です。CNCFは2015年より活動をはじめ、今やAmazon、Google、IBM、Microsoftといったクラウドビジネスの大手ベンダーも参加する一大業界団体に成長しました。CNCFは、クラウド・ネイティブ・コンピューティングについて、「オープン・ソース・ソフトウェアを用いた、コンテナ化、動的なオーケストレーション、マイクロサービス指向」としています。このCNCFの言及もあって、マイクロサービスはクラウド・ネイティブ・コンピューティングを構成する重要な技術的要素として見なされています。

マイクロサービス

マイクロサービスとは、クラウド・ネイティブ・アプリケーションを開発し、運用するためのベスト・プラクティス集です。その適用範囲は、マイクロサービス・アーキテクチャー（Microservice Architecture 以下、MSA）と呼ばれるソフトウェア・アーキテクチャーに始まり、チーム・フォーメーション、システムのライフサイクル、開発と運用のノウハウ等、多岐に渡ります。2010年代の初頭にはその原型があったそうですが、2014年3月のマーティン・ファウラー氏とジェームズ・ルイス氏によるWebサイトへの投稿を機に、世に広まりました。

Microservices

この投稿で、米国ThoughtWorks社の著名なアーキテクト／コンサルタントである両氏が、ICTシステムの開発運用の現場からのフィードバックをマイクロサービスとしてまとめています。両氏による投稿記事を紐解きながら、マイクロサービスのエッセンスについて解説していきましょう。

従来型のアプリケーションは、ユーザー・インターフェース、ビジネス・ロジック、リソース・アクセスといったレイヤー構造に分割されて実装されますが、各レイヤーに属するプログラムは密接に連携しており、多くの場合一つのアプリケーション・モジュールにパッケージングされます（図1）。

図1：モノリシックなアプリケーション構造

従来型スタイルで開発されたJava EEのEARファイル、WARファイルがこの一例です。これをモノリス（Monolith、一枚岩）あるいはモノリシック・アプリケーションと呼びます。モノリスを構成するソフトウェア・コンポーネントを変更（追加、修正、削除）する場合、各コンポーネントが密結合されているため、アプリケーション・モジュール全体のテストが必要となります。またサーバーを一旦停止して、アプリケーション・モジュール単位での再デプロイも求められます。これでは素早い柔軟なメンテナンスとは言えません。ソフトウェア・コンポーネント変更の影響範囲はあくまで変更対象のコンポーネントに留め、他のコンポーネントの稼動を妨げることなく変更部分のみを速やかにリリースできるのが理想です。マイクロサービスの動機は、このような柔軟なアプリケーション・メンテナンスの実現にあります。

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

柔軟なアプリケーション・メンテナンスを実現するために、次のコンセプトに基づいて、ソフトウェア・コンポーネントの疎結合と独立性を徹底するのがMSAの本質です。

• 小さなサービスを組み合わせて、1つのアプリケーションを開発する
• 各サービスは、独立したプロセス(コンテナ)で動作する　^※1
• 各サービスは、RESTやメッセージングのような軽量な仕組みで通信する
• 各サービスは、完全に自動化された仕組みで、それぞれ個別にデプロイされる
• 各サービスは、それぞれ異なるプログラミング言語で実装できるし、異なるデータ・ストレージを利用できる

図1で示した従来型のモノリスの構造と比較できるように、図2にMSAの構造をモデル化してみました^※2。役割ごとにソフトウェア・コンポーネントをレイヤー構造に分類する点に関しては、MSAとモノリスの間に違いはありません。図2で確認できる両者の違いは2点、ソフトウェア・コンポーネントのパッケージングと稼働環境です。MSAにおいては、あるまとまったビジネス要件を実装するソフトウェア・コンポーネントを「サービス」と呼び、サービス単位でパッケージングされます。そして各サービスは、それぞれ個別のコンテナにデプロイされ稼動します。コンテナは独立したサーバーあるいはサーバー・プロセスに相当し、各コンテナの開始や停止は、他のコンテナの運用に影響を与えません。サービスをそれぞれ個別の稼働環境にデプロイすることで、より小さな粒度ごとのアプリケーションの変更、すなわち柔軟なメンテナンスが可能になるのです。

図2：MSAの構造の例

※1　ファウラー氏とルイス氏は前述の投稿において、「サービスは独立したプロセスで動作する」としています。この「プロセス」については、「独立した稼働環境」といった程度の意味合いです。2014年3月当時、コンテナ技術は今ほどポピュラーではありませんでしたのでこのような表現になっていますが、コンテナが広く知られるようになった現在は、「サービスは独立したコンテナで動作する」と言ったほうがしっくりくるでしょう。

※2　ファウラー氏のWebサイトにおいて、MSAのレイヤー構造について図3に示すモデルが提示されています。図2は図3を基にした上で、一つの派生系、実装例として示したものです。

図3：MSAのレイヤー構造

マイクロサービスを支える仕組み

マイクロサービス・アーキテクチャーに基づいた開発と運用を推進するためには、それに見合った仕組みを作り、活用した方が効率的です。そのようなマイクロサービス化を推進する試みの一つとして、開発と運用を担うチーム編成の工夫があります。マイクロサービスにおいては、コンウェイの法則を活かしたチーム作りを推奨しています。メルヴィン・コンウェイ氏の論文に由来するコンウェイの法則とは、「ICTシステム構造は、その開発プロジェクトの体制を反映する」というものです（図4）。

図4：コンウェイの法則に基づいた開発・運用チーム体制

従来型のモノリシック・アプリケーションの開発プロジェクトにおいては、ユーザー・インターフェース（UI）チーム、アプリケーション・チーム、DBチームといった具合に組織編制され、結果としてそれぞれが密結合されたUI層、アプリケーション層、DB層からなるICTシステムがリリースされます。一方マイクロサービスではコンウェイの法則を逆手に取って、成果物として期待するサービスごとに、チームを編成します。サービスは、細分化されたビジネス要件を実装したソフトウェア・コンポーネントであり、独立して稼動するに足るインターフェースとビジネス・ロジック、そしてビジネス・データ・アクセスを実装しています。従って、サービスの開発チームは小規模でありながらも、UIスペシャリスト、アプリケーション開発スペシャリスト、DBスペシャリストから編成するのです。こうすることで、各チームは独力でサービスを実装できるようになります。

また、マイクロサービスでは、ICTシステムの開発と運用を「プロジェクト」ではなく「製品」として捉え、一つのチームがサービスの開発と運用に責務を負うことを推奨しています。その背景として、アジャイル開発の影響があります。マイクロサービスの様々なプラクティスはアジャイル開発をベースに組み立てられており、それぞれのサービスの開発は反復型開発の中で機能が追加され、あるいは洗練化されることを想定しています。よって、日本の請負型SIプロジェクトでしばしば見られるように、予め決められた成果物を納入してプロジェクトが解散するのではなく、チームは長期に渡る開発とメンテナンスの繰り返しを担うのです。

アジャイル開発がマイクロサービスのベースになっている理由はいくつか考えられますが、その一つがスピーディなアプリケーションのリリースです。勘の良い方は気づかれていると思いますが、マイクロサービスの考え方そのものにはアプリケーション開発をスピード・アップする要素は希薄です。それどころか、アプリケーションを複数のサービスに分割し構成する分散システムのための仕組み作りで手間がかかり、むしろ最初のリリースまでにそれなりに時間を要してしまう恐れさえあります。このような懸念を払拭し、素早いシステム・リリースを促すために、アジャイル開発プロセスが必要なのです。

加えて言えば、サービス粒度の洗練化のために、アジャイル開発は有効なアプローチであるという側面もあります。サービス指向のシステム開発と言えば、2000年台にService Oriented Architecture（SOA）が流行しましたが、その時に大きな議論となったのが「サービスの粒度」です。いかにサービスを切り出し洗練化させるのか、その手法について有識者による長い議論を経て導き出された教訓の一つが「ドメイン・スペシャリストであっても一回の分析でサービスを最適化することは難しい」というものでした。一回の分析でサービス設計を最適化できないならばどうするかというと、反復型開発によって段階的にサービス化を進める、すなわちアジャイル開発の実践ということになります。このような背景の下で、「ドメイン駆動設計（Domain Driven Design、DDD）」の考え方が登場し、DDDはマイクロサービスにおいてもサービス化の手法の一つとして捉えられています。

マイクロサービス・スタイルの開発・運用をスピード・アップするための仕組みとして、アジャイル開発を基盤面から支えるのが継続的デリバリー（Continuous Delivery、CD）です（図5）。CDとは、アプリケーション開発、基盤のデプロイ、そしてアプリケーションのデプロイを自動化することで、開発と運用をスピード・アップするソリューションです。具体的には、アプリケーション開発におけるコンパイル／ビルド／単体テストは継続的インテグレーション（Contiuous Integration、CI）ツールを利用して自動化し、クラウド・プラットフォームとして自動デプロイされた基盤に、クラウドの機能を利用してアプリケーションを自動デプロイするものです。アジャイル開発はプロセスの観点で開発・運用のスピード・アップを図りますが、CDはICTソリューションとしてスピード・アップを支援します。

図5：継続的デリバリー

クラウド・プラットフォームの運用面のイノベーションとして知られるのが、サイト・リライアビリティ・エンジニアリング（Site Reliability Engineering、SRE）です。元々大規模クラウド・システムを安定的に運用するための手法として考案されたSREは、その価値が認められてAmazon、Microsoft、IBM等他のクラウド・ベンダーにも採用されています。SREは従来のシステム運用と同じようにシステム基盤の監視や管理、障害時の緊急対応を主要な責務とする一方で、バックアップ等の定型業務の自動化を進め、運用のスピードアップと品質向上を目指します。自動化を進めるにはプログラミングが不可欠なので、SREを担うSite Reliabilityエンジニアは、基盤スキルに加えてソフトウェア・エンジニアとしての素養も求められます。Site Reliabilityエンジニアは、アプリケーション開発チーム内に属し、運用の自動化によって生じた余剰の時間をビジネス貢献に繋がる知的な作業に費やすことを求められます。アプリケーション開発と運用が同じチームで協業するという観点で、SREはDevOps実践例の一つと言えるでしょう。

マイクロサービス化を進める手法として紹介したアジャイル開発、CD、CI、DDD、SREを含め、マイクロサービスの開発と運用の流れを俯瞰したのが図6になります。ドメイン分析局面でビジネスに責任を持つドメイン・スペシャリストを巻き込んで、ビジネスの観点でサービス化を進めつつ、必要に応じて反復するのがポイントです。

図6：マイクロサービスの開発と運用の流れ