クラウド時代の本格的な拡がりと共に、ビジネスにおけるIT用語にも次々に新しいキーワードが登場している。AIやディープラーニングのような「情報分析・活用系」の大きな潮流の一方では、「クラウドサービス系」とでも呼ぶべき一大勢力がある。今回はその中でも特に注目度の高い「マイクロサービス」に焦点をあてて、最先端のクラウド活用に関する「いまさら聞けない」基礎知識を押さえよう。

「マイクロサービス」の正体はさまざまなシステムの集合体

 新しいIT用語の中でもクラウドの分野には、「パッと見て具体的に想像できない」ものが少なくない。とりわけクラウドサービスは、ネットワークを通じてさまざまなITサービスがつなぎ合わされ、それらの複雑で高度な連係プレーによって1つの「サービス=機能」を提供している。それを一言で表現するのも、イメージするのも容易ではない。

 そもそもITで言うところの「サービス」とは、どんなものか。例えばAmazon.comや楽天のようなネット通販を思い浮かべてみよう。この「ネットで買い物」という一つのまとまった機能の背後には、商品データベースやクレジット決済、購入履歴をもとにおすすめ商品を提案するデータ分析など複数のシステムが動いており、ユーザーの挙動に合わせてリアルタイムで連携している。今回採り上げる「マイクロサービス」も、まさにそうした多種多様なシステムの機能の集合体を指すキーワードだ。

サービスをモジュール単位で構成するので開発も変更も簡単

 ではなぜ、現代のサービスがマイクロサービスに向かっているのか。アプリケーション開発の面から見てみよう。ネット通販に限らず、いまどきのアプリケーションは、市場やユーザーの要望に応じて常に改良や変更が加えられ、変化していくことが求められている。当然アプリケーションの構造も、頻繁な変更や機能追加にすばやく対応できるものでなくてはならない。

 そこで注目されるのが、アジャイル型開発だ。これはプログラムの開発→利用→問題点のフィードバック→改良を繰り返しながら、システムを練り上げていく。つまりアプリケーション開発におけるPDCAサイクルを高速に回しながら、改良を進めていく手法であり、市場の変化が激しい時代のビジネスドリブンな開発手法として急速に拡がっている。

 アジャイル型開発では、アプリケーションをモジュール型構造にする必要がある。というのも、巨大なひと固まりのプログラムでは、開発→利用→問題点のフィードバック→改良の各ステップに時間がかかり、ビジネスの変化に即応できないからだ。プログラムを機能ごとのモジュールとして完結させ、それらを独立したプロセスとして動かし、APIでつなぎ合わせて連携させる。そうして、一つの大きなサービスを構成する手法がマイクロサービスである。

 マイクロサービスには、サービスを堅牢でセキュアにしやすいというメリットもある。単機能なモジュールは、構造がシンプルになり、バグが入り込みにくい。また、独立したプロセスとして動かすので、あるモジュールに不具合があっても、それが他に影響しにくく、対処が容易である。一部の機能を変更する場合にもそこだけを変えれば済む。APIさえ変えなければ、モジュール内の実装がどうなっていても構わない。

 例えばネット通販ならば、決済の手続き方法が変更になった場合も、決済機能のモジュールだけを入れ替えれば、他の商品検索や購入履歴などのモジュールには手を加える必要がない。また、商品検索に時間がかかり、ユーザー満足度に影響が出ている場合、商品検索モジュールだけで問題を解決すればよい。コードを最適化することもできるし、それに時間がかかるならプロセスを増やして負荷分散してもよいだろう。

構造がシンプルで優れた処理性能を可能にする実装技術「コンテナ」

 ちなみにマイクロサービスは、開発の手法の呼び名であって、どんな実装技術を使うかは問われない。小さなモジュールで構成されたメンテナンス性の高いサービスが開発できれば、言語やプラットフォームは何を使っても構わないのだ。

 とはいえ、クラウド環境上で稼動するマイクロサービスの基盤技術として、現在は「コンテナ」が主流になりつつある。コンテナとは、OS上に個々のアプリケーションごとの専用区画を作り出す技術であり、仮想化技術の1つである。コンテナに関する技術自体は古くからあり、FreeBSDの「Jail」やSolarisの「Zone」などが知られているが、現在はLinux由来のDockerが主流になっている。

 コンテナ・ベースのマイクロサービスでは、個々のモジュール(プロセス)ごとにコンテナを用意し、プロセス間の連携はAPIを介して行う。お互いのコンテナ内部に直接アクセスしたり中身を変更したりできないので運用上も安心だ。もちろん機能変更の際は、コンテナ単位で迅速に入れ替えできる。

 同じようなことは仮想マシンでも行えるが、仮想化マシンではホストOSとアプリケーションの間に、ゲストOSやハイパーバイザーなどが介在するるため、オーバーヘッドが大きく、環境構築にも手間がかかる。目的はアプリケーションを動かすことなのに、仮想化マシンを利用する場合は、ゲストOSやミドルウェアのセットアップが必ずついて回る。マイクロサービス化でプロセスが増えるので、その手間がますます増える。コンテナなら、アプリケーションとそれが依存するライブラリなど、必要最小限のものを入れるだけでよいので、マイクロサービスには非常に都合がよろしい。

マイクロサービスを支えるREST API

 上では軽く流したが、API(Application Programming Interface)とは、プログラムから他のプログラムの機能を利用するための、呼び出し手続き仕様のことである。

 APIにはいろいろなタイプのものがあるが、クラウド環境上のマイクロサービスに適したものが、REST APIである。REST APIの最大の特長は、Web標準技術に準拠していて、構造が極めてシンプルなことである。例えば、REST APIではリクエストをURLのかたちで表現する。ここで、証券コードを指定すると現在の株価を応答するサービスがあるとしよう。そのリクエストは以下のようなURLで表現できるだろう。

https://example.com/getkabuka?q=XXXX

 ここでは、example.comが問い合わせ先で、getkabukaがサービス、XXXXが証券コードだ。ご覧のようにとてもシンプルである。問い合わせ元のプログラムは、サービスを提供するサーバーがどこにあるかなどは関知しない。つまり、物理的に離れた位置にある小さなサービスを連携させて、大きなサービスを作ることもできる。これは、プライベートクラウドとパブリッククラウドを連携させるハイブリッドクラウド環境や、複数のパブリッククラウドを混在して使うマルチクラウド環境にとても都合がよい。他社が提供するサービスを自社のサービスに組み込むのも容易である。

インフラを気にしないサーバーレスアーキテクチャ

 上述のように、現在はコンテナがマイクロサービス化の基盤技術として広く使われているが、マイクロサービスとコンテナはイコールではない。コンテナ以外のアプローチもある。そして、現在注目を集めているのが、AWS LambdaやGoogle Cloud Functions、Azure Functionsといった、新世代のクラウド・サービスを活用した「サーバーレスアーキテクチャ」である。

 コンテナは、開発者がアプリケーションに注力しやすい環境を提供してくれるが、それでもコンテナの入れ物としてのサーバーは依然としてなくならない。それが物理サーバーであれ、仮想サーバーであれ、メモリやストレージが足りなければ追加しなくてはならないし、処理能力の強化も必要だ。サーバーレスアーキテクチャとは、そうしたサーバーを意識せずに済むアプリケーション・プラットフォームを指す。

 サーバーレスアーキテクチャでは、開発者はプラットフォームが提供する開発環境を使ってアプリケーションを開発して展開するだけでよい。メモリやCPUリソースなどは必要な分だけ自動的に割り当てられる(もちろん上限を設定することはできる)。開発者はインフラを意識・管理する必要がなく、完全にアプリケーションに注力できる。この結果、ビジネスドリブンなサービス開発が可能になるというわけだ。

 ただし、サーバーレスアーキテクチャにも課題はある。それは、AWS LambdaやGoogle Cloud Functions、Azure Functionsなどのプラットフォームごとに、使えるプログラミング言語やライブラリの種類、提供されるプラットフォーム機能が異なることである。つまり、あるプラットフォーム向けに作成したアプリケーションは、他のプラットフォームでは動かない。サーバーレスアーキテクチャを検討する際は、このロックインの問題を慎重に検討すべきである。

 かなり駆け足で見てきたが、話題のマイクロサービスがどんなものか、大まかなイメージはつかんでいただけただろうか。迅速なアプリケーション開発を可能にするマイクロサービス化は、避けて通れない潮流となっているが、その開発・構築の手法はこれからも急速に進化していくことが予想される。それらのメリットとデメリットをよく理解した上で、自社のビジネスや実現したいサービスに合っているものを的確に選ぶことが必要だ。