新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

IaaS、FaaS、PaaS、CaaS を使い分ける

クラウド・コンピューティングの新参者は、この分野で使われているかなりの数の頭字語にうんざりするかもしれません。しかも最近では、ほぼあらゆるものが「サービスとして (as a Service)」(aaS) 売られています。輸送業界にも TaaS が登場しているほどです。利用可能なオファリングの内容を区別できるよう、こうした aaS 頭字語のいくつかを見ていきましょう。具体的には、サービスとしてのインフラストラクチャー (IaaS)、サービスとしてのプラットフォーム (PaaS)、サービスとしてのコンテナー (CaaS)、そしてサービスとしての関数 (FaaS) とも呼ばれるサーバーレスを取り上げます。

どのオファリングが自分のニーズに最も適しているのかを判断する 1 つの基準は (抜群に役立つとは言えませんが) 、どれだけ費用をかけられるのかという点です。

デシジョン・ツリーを示す図

資金がたくさんある場合

最も費用がかかるソリューションから順に見ていきましょう。まず、限りない予算があるとしたら、そもそも aaS オファリングを利用する必要はないはずです。自社ビルを購入して何台ものラックをサーバーおよびネットワーキング・ギアで埋め尽くし、インストール、運用、保守を担当するスタッフを雇うことができます。また、当然必要となる相当な空調費も賄えます。

けれども、こうしたケースはありそうにありません。とてつもない予算を使える政府機関でさえも、データ・センターを運営するために外部の企業を雇っています。どうしてでしょうか?現実的に考えると、データ・センターの運営を何から何まで一手に引き受けるとなると、かなり苦労することになるからです。クラウド・コンピューティングが生まれた理由も、この苦労を軽減することにあります。まずは、データ・センターの代わりとなるオファリングに目を向けましょう。それは、サービスとしてのインフラストラクチャー (IaaS) です。

インフラストラクチャーを崩さない場合

IaaS は独自のデータ・センターを構えることに近いオファリングです。IaaS を利用する場合、必要なマシンの数とタイプ、マシンを接続 (または分離) するネットワーク、データを保管する形式を制御できます。実物のハードウェアをレンタルすることも、ハードウェアのように動作する仮想マシンを使用することもできます。これは、クラウド・オファリングの中で最も費用のかかる選択肢ですが、それと同時に最もきめ細かい制御が可能になります。

どのオファリングがニーズに最も適しているかを判断する基準として費用が役立つのはここまでです。費用は非常に重要な懸念事項ですが、通常は費用の他にも制約があります。費用だけではなく、有用性を決定する要素は何であるかを考えると、より良い意思決定につながるはずです。必要となる制御レベルについても、有用性を決定する要素の 1 つとして捉えることができます。

構造よりも関数を優先する場合

実現しようとしているアプリケーションを、短い複数のコードに分解することはできますか?そうだとしたら、サービスとしての関数 (FaaS) の実装が適しているでしょう。私が最近取り組んだプロジェクトの一例として、GitHub の問題に特定のラベルが付けられた時点で自動的に新しいリポジトリーが作成されるようにしました。

cloud-function-action

この例では、GitHub から Webhook が生成されるとアクションが実行されます。実行されるアクションは、検索対象のラベルが適用されているかどうかをチェックし、適用されている場合は GitHub に対して API 呼び出しを行って、必要なリポジトリーを作成するというものです。これはクラウド関数としてぴったりのアクションであり、この短いコードは、簡単に定義できるイベントを使用してトリガーできます。こうした仕組みによって、かなりの費用を節約できます。料金が請求されるのは、小さなコードを実行するためにかかった時間に対してだけです。コードが 1 日に数回しか実行されないとしたら、コードを実行した数秒に対してだけ料金が請求されることになります。

プラットフォーム・オファリングの場合

FaaS は小さなタスクに分割する場合は非常に役立ちますが、大規模または複雑なアプリケーションをデプロイする場合には、最適な選択肢とは言えません。その場合にふさわしいのは、サービスとしてのプラットフォーム (PaaS) でしょう。IBM Cloud Foundry などのプラットフォームを利用すると、アプリケーションを実行するために使われるハードウェアの種類を考えることなく、アプリケーションを公開、更新、スケーリングできます。PaaS オファリングでは、多少の制御も許されます。例えば、実行するアプリケーションのインスタンスの数、各インスタンスに割り当てるメモリー量などを指定できます。必要なときにだけコードが実行される FaaS とは対照的に、PaaS ではアプリケーションが常に実行されます。したがって、使用されるリソースが増えることから、料金が高くなります。

faas-decision-tree

PaaS を利用してデプロイするのに適したアプリケーションは、一般にフロントエンド と呼ばれるものです。フロントエンドは Web アプリケーションのユーザーに対応する部分であり、ユーザーが直接アクセスできない他のバックエンド・サービス (データ・ストアなど) に接続して、それらのサービスを利用します。

GitHub 上の Cloud Foundry リポジトリー内に格納された、最もよく使用されている spring-music というサンプル・アプリケーションがあります。これは、ユーザーがミュージック・コレクションを参照して編集するために使用する Java アプリです。このようなアプリは必要に応じてスケーリングできる一方、そのデータ・ストアについては独立して管理 (バックアップしたり、回復力を強化したりするなど) できるので、PaaS 内にデプロイするには最適です。

sample-deployment-of-spring-music

サービス・オファリングを選択する際は、デプロイメントで状態を保存する必要があるかどうかという点も重要な考慮事項になります。ステートフルなアプリケーションは相互作用とその進行状況を記録します。一方、ステートレスなアプリケーションはそのような記録を行わず、所定のリクエストに付随する情報に依存します。ステートレスなコードをプッシュし、プラットフォームのマネージド・サービスを利用してリクエストの履歴を処理するほうが、明らかに管理は楽になります。目的とするデプロイメントの状態を自分で管理する必要があるとしたら、コンテナーが役立つ可能性があります。

興奮の格納するコンテナー

PaaS オファリングと IaaS オファリングの中間に位置するのが、サービスとしてのコンテナー (CaaS) です。CaaS を利用する場合、アプリケーションを実行する環境について指定できる要素 (オペレーティング・システムなど) が幾分増えます。また、PaaS でデプロイするのはアプリケーションだけ ですが、CaaS ではその名が示唆するとおり、1 つ以上のコンテナーをデプロイします。コンテナーは完全な仮想マシンではありませんが、他のコンテナーとカーネルを共有することから、セキュリティーに関してコンテナーならではの副次的影響があります。CaaS の主な利点は、複数のコンテナーを同時にデプロイして、それらのコンテナーを連携させられることです。大規模なデプロイメントでは、アプリケーション、アプリケーションの基礎となるデータベース、検索機能、ログの保管と処理などのそれぞれを対象とした個別のコンテナーを使用できます。しかも、そのすべてのコンテナーを、クラスターと呼ばれる 1 つのグループとして管理することができます。

以下の図は、Guestbook という、コンテナー化されたアプリケーションを簡略化した例を示しています。

guestbook-flow

Kubernetes のドキュメントを辿っていくと、最初の演習として Guestbook アプリケーションをデプロイすることになります。このアプリケーションは、Guestbook エントリーを保管するシングル・インスタンスの Redis マスター、リードの役割を果たす複数のレプリケーションされた Redis インスタンス、複数の Web フロントエンド・インスタンスからなります。フロントエンドとバックエンドの両方を管理し、この 2 つが互いにやり取りする方法も制御したいとしたら、そのニーズを満たすには CaaS オファリングが最適です。

万能のソリューションというものはありません

ここまでの説明では意思決定プロセスを直線で表しましたが、これはかなり誤っています。その主な理由は、上述のオファリングのうち、相互排他的なものは 1 つもないからです。マイクロサービスが主流となっているこの時代、これらのオファリングのいくつか、あるいはすべてを組み合わせて、目的とするデプロイメントを効果的に実現するのは不可能なことではありません。コンテナーをクラウド関数として ホストすることさえ可能です。その場合、関数は常に実行されるわけではないためステートフルにはなりませんが、それでもこの方法は可能性の 1 つとして考えられます。こうした可能性は、デプロイに使用できるオファリングの頭字語の数とほぼ同じ数だけだけあります。

この記事を読んで、クラウドへの移行にどこから手をつけるべきか理解を深めていただけたことを願います!