コンテナは場所を選ばない!「オンプレ or クラウド × コンテナ」(前編)

はじめに

本連載の第1回では「クラウドとはなにか」「クラウド時代がどのような時代であるか」を説明し、利用者の意識が所有から利用に変わっていくことや、代表的なプレイヤー達を紹介しました。今回は、これまでの流れを踏まえて、場所、つまりは「環境」に焦点を当てていきたいと思います。

まず、エンジニアはアプリケーションの動作する環境が利用者から近ければ「ローカル環境」、遠ければ「リモート環境」と呼んでいます。また、利用する目的ごとに環境の呼び名を変えています。利用者にアプリケーションを提供する「本番環境」、開発者がアプリケーションの動作を確認する「検証環境」、そして開発者がアプリケーションを作成する「開発環境」です。

コンテナは、このような環境の差をあまり意識せず、配置しやすい(可搬性が高い)こともこれまでに説明してきましたね。では、ここからはシステムの運営側目線で「環境」としてどのような場所があるのかを説明していきましょう。

オンプレミスとは

まず、システムの運営者が自前でITリソースを用意し、主体的に管理する環境を「オンプレミス」と呼んでいます。オンプレミスでは私達が家を買ったり借りたりするように、データセンター内にシステムを動かす場所を所有するところから始まります。そして、家に電気、水道、ガスを引き込むように、システム外部とのやり取りをするためにITインフラの基礎であるネットワークを敷いていきます。

パブリッククラウドとは

次に、利用者がインターネットを通してITリソースを利用するサービスのことを、クラウド特に「パブリッククラウド」と呼んでいます。自前ではないため、不特定多数の利用者が物理的に同じ場所の同じリソースを利用することになります。パブリッククラウドはオンプレミスと違い、場所を所有するのではなく、インターネット上のサービスを利用することから始まります。

パブリッククラウドの3つの形

パブリッククラウドでは、クラウドサービスプロバイダーが提供する領域で責任範囲が変わっていきます。クラウドサービスプロバイダーから利用者へ提供するパブリッククラウドのには3つの形があります。

• Infrastructure as a Service(IaaS)：
  利用者はクラウドサービスプロバイダーが提供する仮想マシン、ストレージ、ネットワークおよびその他の基本的なリソースをクラウド上に配置し、OSやアプリケーションを含む任意のソフトウェアを導入して利用できます。利用者はOS以上のリソースを管理し、仮想化基盤以下は管理しません。
• Platform as a Service(PaaS)：
  クラウドサービスプロバイダーがサポートするプログラミング言語、ライブラリ、サービスおよびツールを組み合わせて作られた実行環境に、利用者の作成したアプリケーションをデプロイします。また、利用者はデプロイしたアプリケーションや構成設定のみを管理し、実行環境以下の基盤部分は管理しません。
• Software as a Service(SaaS)：
  利用者はクラウド上で実行されているクラウドサービスプロバイダーのアプリケーションを使用します。利用者はアプリケーション自体を管理しません。

オンプレミスとクラウドサービスプロバイダーが提供する3つの形の責任範囲を図1に示します。この図は責任共有モデルと呼ばれることもあります(図1)。

オンプレミスとパブリッククラウドの違い

では、オンプレミスとパブリッククラウドではどのような違いがあるのでしょうか。大きく差が出るのは環境への初期コストと提供スピードです。オンプレミスは自前でITインフラのリソースすべてを導入するため、調達までに時間と費用がかさみます。一方、パブリッククラウドはクラウドサービスプロバイダーがリソースをサービスとして用意し運営者は所有しないため、調達までの時間と費用が格段に早く、安く済みます(図2)。

しかし、パブリッククラウドは運営者がリソースすべてを管理できるわけではなく、きめ細かな設定や自由な運用管理はできません。クラウドサービスプロバイダーが提供するサービス仕様の範囲内で組み合わせて使うため、カスタマイズ性は落ちるといえるでしょう。また、利用していないときに不必要なリソースを動かし続けていると、オンプレミスよりランニングコストが割高になることもあります。「必要なときに必要な分だけ使う」という、利用者が利用者自身を管理するのが良いといえそうですね。

パブリッククラウドが提供するコンテナ

以降では、メジャーな3つのクラウドサービス「Amazon Web Services(AWS)」「Microsoft Azure」「Google Cloud Platform(GCP)」に絞って説明していきます。これらのパブリッククラウドでは、各社ともコンテナにフォーカスしたサービスを提供しています。大きく分類するとプロバイダー独自のものと第4回～第6回で説明したKubernetesベースの2つに分けられます(図3)。

ここからは、クラウドサービスプロバイダーごとに詳しく見て行きましょう。

Amazon Web Services(AWS)

AWS上でのコンテナ環境

AWSはシェアNo.1を誇るクラウドサービスプロバイダーです。AWSでコンテナを使うにはどうすれば良いでしょうか。最も単純な例は、IaaSとして仮想サーバを提供するAmazon Elastic Compute Cloud(Amazon EC2)を使えば、OSより上位のレイヤーは自由に使用できるため、例えばこれまでに紹介してきたDockerやKubernetesをEC2インスタンス上に導入してコンテナ実行環境を実現できます(図4)。

しかし、この構成はDockerやKubernetesを動かしているサーバ自体が障害でダウンしてしまったときや、大きな負荷がかかってCPUやメモリが逼迫してきたときの対応などについては、他のAWSサービスを用いて一から自分たちで考え、構築する必要があります。

運用面を考えても、OSのセキュリティパッチ適用や監視の設定など考えることは盛りだくさんです(図5)。これでは、オンプレでコンテナを使う場合と比べて、物理機器の調達コスト以外のうまみがあまりありません。

AWSマネージドなコンテナサービス

AWSなどパブリッククラウドの大きな強みとして挙げられるのが数多くあるマネージドサービスです。マネージドサービスはAWS側で運用管理されるため、前述したようなサーバリソースの管理やセキュリティ上のリスクなどの考慮すべき点を少なくできます。コンテナ関連のAWSマネージドサービスには、以下の4つがあります(図6)。

• レジストリサービス－ECR
• コントロールプレーンサービス－EKS
• コントロールプレーンサービス－ECS
• データプレーンサービス－Fargate

それぞれに役割や特徴があり、組み合わせて利用することもできます。

・レジストリサービス－ECR

ECR(Elastic Container Registry)はDocker Imageファイルを格納するレジストリサービスをフルマネージドで提供します。Docker Imageを高い可用性で管理できるという点から、これまでに何度も登場したDocker Hubと同様のサービスと言えるでしょう。AWSのサービスとして提供されているため、後述する各コンテナサービスやIAM(AWSの認証・認可サービス)と容易に連携できるメリットがあります。

・コントロールプレーンサービス－EKS

EKS(Elastic Kubernetes Service)は、KubernetesをAWSマネージドで簡単に使用できるサービスです。コントロールプレーンとはコンテナの実行基盤とコンテナ自体を管理する機能のことで、Kubernetesで言うところのマスターノードと同様の意味です。EKSを使用するには、AWSのマネジメントコンソール画面上で名前とネットワークの設定などを入力し「作成」ボタンをクリックするだけです。これでEKSクラスタが作成され、AWS側で可用性を担保するように管理されます(図7)。

・コントロールプレーンサービス－ECS

AWSで簡単にKubernetesを実行できることが分かりました。読者の中には「AWSでコンテナ環境を使うときはEKS一択か」と考える方がいらっしゃるかも知れません。確かにEKSはとても強力なコントロールプレーンサービスですが、実はAmazonも独自にオーケストレーションシステムを開発しています。それがECS(Elastic Container Service)です。

ECSの特徴は、何と言っても「AWSがAWSでコンテナを使うために作ったコンテナオーケストレーションサービスである」という点にあります。そのためにあらゆるAWSサービスと統合されており、権限制御やログ出力、前回で紹介したCI/CDによるデプロイ自動化なども簡単に実装できます。ECSはAWS独自のオーケストレーションサービスであるため、その仕組みや概念もKubernetesとは大きく異なります。ここで、簡単にECSの仕組みを説明しましょう。

ECSは主にクラスタ、サービス、タスク定義といったコンポーネントで構成されています。まずは図8を見てください。

クラスタはECSを使う際に最初に作るコンポーネントです。ECSの他のコンポーネントはクラスタの中で定義・実行されていきます。また、コンテナを実行するサーバとなるクラスタリソースをグループ化し、どのVPC(AWS上のプライベートネットワーク)に所属するかなどを管理します。クラスタリソースにはECS専用に最適化されたEC2インスタンスを利用するか、後述するデータプレーンサービスのFargateを利用するか選択できます。

タスクはECSで実行されるコンテナの最小単位です。タスクには必要なCPUやメモリ量、ネットワーク設定などを定義します。タスク定義の中にコンテナを定義する項目があり、ここで実行したいコンテナイメージを設定します。1つのタスクに複数のコンテナを含めることもできます。

サービスはタスク定義と1対1で紐づきます。タスク定義にサービス定義を設定すると、そのタスクの必要数や負荷の上昇に伴いタスクを増やすオートスケーリングを設定できます。常に複数台稼動してユーザーアクセスを処理するWebサーバの役割を持つコンテナを起動する場合などは、サービスの設定が必須といえます。

この概念さえ押さえておけば、ECSを使用して非常に簡単にAWS上でコンテナを動かすことができます。

データプレーンサービス－Fargate

ここまでAWSマネージドなレジストリサービスとコントロールプレーンサービスを紹介してきました。マネージドサービスを使うと内部のインフラを意識することなく、簡単にコンテナを管理できるようになります。しかし、実際にDockerランタイムが稼動しコンテナが実行される環境(データプレーンと呼びます)については、IaaSのEC2インスタンスを使っている限りOSのセキュリティパッチ適用やサーバリソース管理からは逃れることができません。

そこで2017年に登場したのがデータプレーンのAWSマネージドサービスであるFargateです。Fargateではコンテナを実行するサーバ環境を全てAWSで管理するため、ユーザーは実行したいコンテナのことだけ考えれば良くなります。

Fargateがもたらすメリットはこれだけではありません。コンテナ実行環境をEC2インスタンスで構築する場合には、どんなに最適なリソース量にしようと思っても余剰リソースが出てきます。Fargateではコンテナのことだけを考えれば良いので、コンテナの実行に必要なリソースをコンテナ単位で割り当てるだけで済み、課金対象もコンテナに割り当てたリソースに対して課金されるため、より効率的にコンテナを実行できます。

どのサービスを組み合わせると良いのか

ここまで、AWSのコンテナ関連サービスを1つずつ紹介してきましたが、実際にはこれらを組み合わせて使用することになります。全てAWSマネージドサービスを用いていわゆるサーバレスな構成にもできますし、データプレーンのみEC2インスタンスでホストすることもできます。ここでは、コントロールプレーン(図10)とデータプレーンそれぞれのサービスの特徴をまとめます。

コントロールプレーンサービス

EKSの強みは、Kubernetesの様々な機能をサーバの管理なしで利用できることです。KubernetesはOSSであるため日々あらゆる機能が追加されており、それらを使いこなすことで様々なことを実現できます。しかし、その分複雑で覚えることが多く、習得にはそれなりの年月を要します。また、EKSはコンテナを実行していなくてもクラスタを立ち上げているだけで時間に応じた料金が発生するため、比較的高コストになります。

ECSはEKSと比べて比較的シンプルな構成となっており、AWSサービスとも簡単に連携できるのが強みです。ただ、KubernetesのようなOSSではなく、新機能も追加されず機能は少なめです。「AWSでコンテナを使うために最適化されたコントロールプレーン」であるため、元々AWSを使っていたがコンテナは触ったことがないという人うってつけのサービスと言えるでしょう。

データプレーンサービス

データプレーンサービスの選択肢としては、EC2インスタンス上に環境を構築するパターンとFargateを使用するパターンの2つがあります(図11)。

EC2を利用する場合は良くも悪くも自分で管理できる領域が広がります。OS層以上を自由に使えるため、障害発生時などあらゆる側面から状態を把握したいとときには、ホストOSから好きなだけコマンドを実行してトラブルシューティングができます。しかし、その分ホスト側で考慮しなければならない点が増えます。特に負荷増大時のオートスケーリング設定については、実行するコンテナだけでなくホストOS側についても設計する必要があるため、非常に複雑になります。

Fargateはそのような課題を一気に解決できます。OSの管理までAWSがやってくれるため、利用者は「どのコンテナをどれだけ動かすか」という点に集中できます。また、EC2はOS上でコンテナがいくつ動いていようとEC2インスタンスのスペックに応じた分だけ時間課金されていきますが、Fargateはコンテナの稼動のみ課金される仕組みとなっています。そのため、パブリッククラウドの「使った分だけ課金」という特徴を最大限に享受できるサービスと言えます。

選択肢が多くどれを使うべきか迷うかもしれませんが、エンジニアのスキルやお客様の要望を考慮して、それぞれのシステムに適する選択ができるように各サービスの特徴を把握しておくことが重要です。ぜひ、使い捨てが可能なパブリッククラウドの特性を活かして、色々なパターンを試してみてください。

おわりに

今回は、パブリッククラウドとAWSが提供するコンテナサービスについて学びました。次回はMicrosoft AzureとGoogle Cloud Platformのパブリッククラウドサービスについて見ていきます。お楽しみに！