コンテナを動かすサービスは、どこまでクラウドが管理するのか

EC2 から Lambda まで、何が違うのか

EC2、ECS、App Runner、Lambda はどれも、利用者がコードを動かす場所を AWS が貸すサービスです。 違いは、利用者が引き受ける仕事の範囲にあります。

OS を含むマシンを借りるのか、アプリを動かす場所を借りるのか。 任せる範囲によって、サービスの分類名も変わります。 サービスとして借りる範囲に応じた呼び名の総称を XaaSXaaSエックスエーエーエスX as a Service。何をサービスとして借りるかで、IaaS、CaaS、PaaS、FaaS、SaaS などと呼び分ける総称。用語集で見る と言います。 続けて、コンテナを動かすサービスを指す CaaS を、ECS の 3 つの設定項目 (イメージ、ネットワーク、ボリューム) から説明します。 最後に、Docker を入れただけでは足りない仕事を示し、その仕事を担う部品の名前 (オーケストレーター) を定義します。

範囲を比べるために、コンピュートを物理、OS / VM、コンテナランタイム、オーケストレーション、アプリという層の積み重ねとして見ます。 EC2 では OS のパッチも Docker の更新も利用者の作業ですが、Lambda ではそれらを全部 AWS が行います。 どの層までをクラウドが引き受け、どこから上を利用者が持つか。 その分かれ目の高さが IaaS、CaaS、PaaS、FaaS、SaaS の違いです。

この分け方の元になっているのは、米国 NIST が 2011 年に出した定義 (SP 800-145) です。 そこにあるのは IaaS、PaaS、SaaS の 3 つで、どの形態でも「利用者は下にあるクラウドの基盤を管理も制御もしない」と書かれています。 違うのは、利用者が制御できる層の高さです。

• IaaS：CPU、ストレージ、ネットワークといった計算資源を借り、OS を含む任意のソフトウェアを動かせる形態。EC2、GCE。OS から上は全部利用者が持つ。
• PaaS：クラウドが用意した言語やツールで作ったアプリを、クラウドの基盤に置く形態。App Runner、Heroku、App Engine。利用者が持つのはアプリとその設定だけ。
• SaaS：クラウドが動かしているアプリケーションをそのまま使う形態。世の中のサービスの大半。

CaaS と FaaS は、IaaS と PaaS の間にあるサービスを指す業界の通称で、NIST の定義には出てきません。

• CaaS (Container as a Service)：コンテナを動かすホストに加えて、どのホストで何個動かすかを決める仕組み (オーケストレーション) までクラウドが提供する形態。ECS、EKS、GKE、AKS。
• FaaS：PaaS に近いが、コードを関数の単位で置き、関数が実際に動いた時間で課金される。Lambda、Cloud Run functions。

この 5 つのほかにも、Firebase や Cognito のような BaaS (Backend as a Service)、Aurora や Spanner のような DBaaS があり、切り口はいくらでも増やせます。 名前を暗記するより、「自分はどの層から上を持つのか」を即答できることのほうが役に立ちます。

選べることと、引き受けること

階段を左へ行くほど、利用者にできることが増えます。 AWS 自身の説明でも、IaaS は「最も高い柔軟性と管理の自由」を与える形態で、PaaS は「ハードウェアと OS の管理を利用者から取り除く」形態です。 EC2 なら好きなカーネルモジュールを入れられ、Lambda では実行時間やランタイムに制約があります。 その代わり、左へ行くほど OS のパッチ、ミドルウェアの更新、キャパシティの管理といった運用の仕事が利用者のものになります。

選べる範囲と引き受ける仕事が同じ層で増減するので、立つ位置は要件と組織の両方で決まります。 カーネルモジュールや GPU が要る、特定のカーネル設定が要る、といった要件があれば、その層を自分で持てる形態に降りるしかありません。 反対に、そうした要件が無いのに IaaS に立つと、OS のパッチとキャパシティ管理という仕事だけが手元に残ります。 どの層を自分で持つ理由があるのかを言葉にできれば、形態の選び方は決まります。

CaaS を支える 3 要素

ECS でタスクを動かすとき、task definition にはイメージのほかに、awsvpc モードのサブネットと Security Group、必要なら EFS のボリュームを書きます。 ECS の説明でも、task definition は「使うイメージ、開くポート、コンテナが使うデータボリューム」を書く設計図だとされています。 コンテナを動かすには、コンテナを動かすランタイム、コンテナを繋ぐネットワーク、データを残すボリュームの 3 つが要るからです。

この 3 つが要るのは、コンテナエンジンを載せるのが EC2 のような VM やベアメタルのサーバーだからです。 そのサーバーには、コンテナに IP アドレスを持たせる方法と、データを残すディスクの付け外しを、誰かが用意しなければなりません。 AWS では、IP アドレスと NIC を VPC と ENI が、ディスクを EBS と EFS が受け持ちます。

Part 4 で見た CRI / CNI / CSI は、この 3 要素について Kubernetes が「呼び出し方の取り決め」だけを定め、中身のプログラムを差し替えられるようにしたものです。 ランタイムなら containerd、ネットワークなら Cilium や Amazon VPC CNI、ボリュームなら EBS CSI driver がその中身です。 クラウドごとに中身 (ENI を使うか、EBS を使うか) は違っても、Kubernetes からの呼び出し方は同じです。 だから同じ YAML が EKS でも GKE でも動きます。

Docker を入れた後に残る仕事

ECS や Kubernetes を使う前の AWS では、Ansible で全ホストに Docker を入れ、ネットワークの設定を配り、セキュリティパッチを当て続ける運用がよく見られました。 この運用で用意できるのは「1 台の上でコンテナを起動する」ところまでです。

残るのは、ホストをまたいだ判断です。 Kubernetes のドキュメントが挙げる機能で言えば、ノードの空きに合わせてコンテナを詰める (bin packing)、落ちたコンテナを起動し直す (self-healing)、新しいイメージに段階的に入れ替える (rollout)、DNS 名や IP で見つけて負荷を分散する (service discovery と load balancing)、秘密情報と設定を配る、台数を増減する (horizontal scaling) がそれです。 ECS の service も同じ仕事をしていて、task が失敗したり止まったりすると、service scheduler が task definition をもとに別の task を起動して、指定した数を保ちます。 Docker 単体にはこれらを決める機能がありません。 このマシンとコンテナの間に広がる仕事をまるごと引き受ける部品を オーケストレーターオーケストレーターオーケストレーター複数のホストにまたがって、コンテナをどこで何個動かすか、落ちたらどうするかを決めて実行する仕組み。用語集で見る と呼びます。 ECS や Kubernetes、かつての Mesos や Marathon がそれに当たります。

ここまでを一文にすると、CaaS はオーケストレーターまでクラウドが動かし、利用者は動かしたいコンテナ (のイメージと設定) を渡すだけにするサービスです。 次の章では、オーケストレーターの各部品を各クラウドがどこまで引き受けているかを、EKS、GKE、AKS、ECS で比べます。

ふりかえり

参考

• The NIST Definition of Cloud Computing (NIST SP 800-145)
• Types of Cloud Computing (AWS)
• Architect your solution for Amazon ECS (Amazon ECS Developer Guide)
• Overview (Kubernetes Documentation, Concepts)