コンテナアプリの80％はAWSで実行されているーーゼロから学べるAWSのコンテナサービス入門

コンテナを有効活用する方法、教えます

濱真一氏：お時間になりましたので、始めていきます。「コンテナを有効活用したいあなたへ AWS コンテナサービス入門 2020」というタイトルで、アマゾン ウェブ サービス ジャパン・ソリューションアーキテクトの濵が担当いたします。それでは始めていきます。

このセッションは、AWSが提供するコンテナサービスに入門していただくセッションとなっています。改めて自己紹介です。私、アマゾン ウェブ サービス ジャパンでソリューションアーキテクトとして、主に西日本のお客さまを担当しております、濵と申します。

得意な技術は本日取り上げるテーマでもあります、コンテナ関係のサービスになります。ゆえにコンテナに関連するサービスや機能について、お客さまとディスカッションする機会も多いという背景もあり、本セッションを担当させていただいております。

本セッションではこのような想定をしております。本日このセッションに参加していただくみなさまは、おそらく「docker runはしたことがある」「コンテナはだいたいこんな価値があるものだ、ということをなんとなくは知っている」「これからコンテナ化したアプリケーションを作っていこうと検討を始めたところだ」、それから「AWSでコンテナをやっていこうとなってるけど、一体いつどのサービスを使えばいいのか」というような疑問を持たれている。そういったみなさまを対象としています。

本セッションのゴールですが、コンテナに関連するサービスはたくさんあるなかで、それらが何を解決しようとしているのか、なぜ存在しているのか、それを知っていただきたいと思っています。それからAWS上でコンテナアプリケーションを動かそうとしたときに、じゃあどのサービスを使えばいいのかを、ご自身で選択できるようになっていただく。その第一歩としていただくためのセッションです。

そもそも「コンテナ」とはなにか？

アジェンダは以下の内容で進めていきます。

まず「コンテナってどういうものでしたっけ」「どう使うんでしたっけ」というところを一度振り返ります。このセッションを聞いている方の中にはご存知の方もたくさんいらっしゃると思いますが、みなさまが同じ前提のもとに今日のセッションを聞いているということを担保するために、まず最初に「コンテナとは」というところを振り返ります。それから「オーケストレーション」イメージレジストリ」「実行環境」というかたちで進めていきます。

ではまず「コンテナとは」という話をします。ここでは主にLinuxコンテナを前提に話を進めます。コンテナそのものの前に、アプリケーションがちゃんと動くためには何が必要か、というところから振り返りましょう。

一番わかりやすいのはこの右上の、アプリケーションコードの部分だと思います。ただコードだけがあっても、アプリケーションは動きませんね。JavaだったらJVMが必要ですし、Node.jsとかPHPであれば、そのコードを解釈する「ランタイム」自身が必要となります。

それから例えばロギングのように、みなさまアプリケーションの中になんらかの「ライブラリ」を組み込んで使っていると思います。こちらももちろん必要になるでしょう。

それからアプリケーション開発の現場では、複数の環境で開発とかオペレーションということが行われるのが一般的かと思います。開発環境があってステージング、本番環境があるというような。この複数の環境にわたってアプリケーションを動かす際に、環境情報というものを1個1個、環境ごとにコード自体を書き換えていたら非常にオペレーションの負荷は高いですし、ミスオペレーションが起きる可能性もありますので、多くの場合「設定」というかたちで外出しをします。

こういう4つの要素がそろってアプリケーションはちゃんと動きますよね、というのがまず前提です。

環境間の差異を吸収するコンテナ

今ここに3つの環境があります。コンテナに関係なく、アプリケーションをデプロイするとき、どういったかたちでデプロイされるかということを振り返ります。例えばランタイムはPythonとしましょう。これらの環境にはPythonがそれぞれインストールされていて、セットアップされた環境にコードを配置して実行し、サービスとして機能を提供する。すると、こんなことがあると思います。

ローカルだとPythonのv3.2を使っています。ステージングだとすでにv3.7になっていて、本番だとなぜかv2系を使っていました。これおそらくですね、一度本番環境もv3系に上げたけども、上げたらうまく動かなかった。元に戻そうと。で、そのままうやむやになって、開発環境・ステージング環境との差異が出てしまう。こういうことは普通に起こり得ることだと思います。

そうすると、ローカルでは動いたけど本番では動かない。こういうことが発生しますね。こういう環境間の差異からくるエラーなりなんなりを、みなさま一度は経験したことがあるんじゃないかなと思います。こういった環境間で差異が出てしまうことへの解決策の1つとして、コンテナがあります。

先ほどの環境でみなさんが運んでいたものは、アプリケーションと設定だけだったのではないでしょうか。ランタイムは各環境に直接インストールされていた結果、バラバラになっていた。それを、アプリケーションが依存するものすべてをコンテナの中に一つにまとめてしまって、これを運んでいけば環境に依存されずにちゃんと実行できるのでは……というのがコンテナの発想のスタートですね。

そしてここには4つの要素のうちの1つだった「設定」がありません。なぜか。コンテナは「コンテナイメージ」をベースに作られるんですが、コンテナイメージとは関係性で言うと、仮想マシンで言う「マシンイメージ」と同じ関係だと思ってください。EC2で言うAMIですね。

このコンテナイメージに対して、設定をイメージ内に含めてしまうと、開発環境用・ステージング環境用・本番環境用と、環境ごとにイメージを用意しないといけなくなります。これってさっきとまったく同じことをやってしまっていることになるんですね。なので環境に依存して変わる値というのはイメージの中に含めずに、コンテナの実行時に渡しましょう、という考え方を覚えておいてください。

Dockerエンジンの役割

では、このコンテナというものを使いやすくするためのデファクトと言えるのが、Dockerというソフトウェアですね。

このDockerというものをどう使うかというと、各サーバーやローカルのラップトップといった各環境に、Dockerエンジンを実行しておきます。Dockerエンジンを実行しておくと、Dockerは簡単なコマンドでコンテナイメージを作ったり、コンテナを実行することができます。

で、コンテナは中身に全部必要なものが入っていますよね。なのでDockerエンジンと、必要なものが全部入ったコンテナを用意しておけば、どこの環境でも同じように動きますよね、というのがDockerです。

このように、ローカルでもステージングでも本番でもPythonをインストールするのではなく、Dockerエンジンを各環境に入れます。その上でコンテナイメージを各環境に運んでいって実行してあげれば、環境間の差異を吸収できるわけですね。ローカルで動いていたものが、確実に本番環境でも動かすことができます。

では、Dockerを使うときの基本的なワークフローを少し見ていきます。

ここではちょっと時間の関係もあって省略をしますが、コンテナの元となるイメージはできていて、それを本番環境で実行する際ですが……まずサーバーにsshで入ります。その上でdocker pullをしていきます。docker pullが何かと言いますと、イメージレジストリからイメージをダウンロードしてくるコマンドですね。

で、コンテナイメージをダウンロードしてきたら、今度はdocker runでコンテナを実行していきます。もし複数サーバを持っている場合は、台数ぶん同じことをやることになります。ここまで聞いて「思っていたのと違う」と思った方、いらっしゃると思います。なにも自動化されてませんし、運用も大変だと思われた方もいます。

それもそのはずなんですね。Dockerというソフトウェアの責務の範囲は、単一のサーバー上でのコンテナのライフサイクル管理です。コンテナイメージをサーバーにダウンロードしてきて、コンテナを実行して、いらなくなったら止める。これがDockerの責務です。ですので本番環境のような複数サーバーで動いていたり、複数のコンテナを実行することが前提となっているという、そういった概念に対するオペレーションはDockerのスコープ外ということになります。

じゃあ何が必要かというと、コンテナオーケストレーションツールが必要になるわけですね。Dockerエンジンに対してdocker pullとかrunといったコマンドを、みなさんに代わって発行してくれる仕組み・ツールが必要になります。

人に代わってオペレーションを実行してくれるAmazon ECS

AWSでは、こういう図を使ってよく説明をします。仮想マシンが下に並んでいます。で、仮想マシンの中にある縦線の箱がコンテナです。

みなさんが手動で、仮想マシンに入ってコマンドを実行して、コンテナイメージのダウンロードとか実行をしていると、これそもそも非効率ですよね。

このセッションを聞いていただいているみなさまの中には、数百台、数千台の仮想マシンを抱えておられる方もいらっしゃるかもしれません。それだと非効率だし、なによりミスオペレーションが起きてしまいますね。違うイメージをダウンロードしてしまった、実行時のパラメータを間違えちゃったり。

ですのでAWSは、Amazon Elastic Container Service、通称「Amazon ECS」をリリースいたしました。何が変わったのか。それまでみなさんは、サーバーと直接接続した上でコンテナに関するオペレーションを行ってきました。それがECSのAPIを呼び出すように変わります。そうするとECSがみなさんに代わって、サーバー内のDockerに関連するオペレーションを実行してくれるんですね。

どうやって使うかというと、このEC2のクラスター・集合に対してです。ここで言うと、6台の集合に対してコンテナを実行したいとき、その上で「このコンテナを3つのアベイラビリティゾーンに対して分散させた上で、かつ同時に10個実行してください。実行できればロードバランサーにつないでください」。これを自動化するためのツールが、コンテナオーケストレーションツールです。そしてECSはその1つです。

AWSネイティブなコンテナオーケストレーションツール

このAmazon ECS、いくつかお伝えしておきたい特徴があります。まず発表されたのは2014年です。この当時、コンテナを本番環境で実行できるマネージドサービスというものは世の中に存在しませんでした。お客さまから「DockerというものをAWS上で使いたい」、それから「自身の手動でのオペレーションはしたくない」という声をいただいて、AWSが発表したのがこのECSです。

ECS最大の特徴は、AWSのネイティブなコンテナオーケストレーションのサービスという点です。ネイティブゆえに、AWSのその他のサービスとの高度な連携、インテグレーションがすでに実装されています。

それから基本的なリソース表現が非常にシンプルです。ECSを始めたいという時に、まず最初に勉強すべきリソース表現は2つだけです。「タスク」と「サービス」、この2つを学べばECSを始めていただくことはできると思います。

もちろんECSも進化を続けておりますので、概念も増えてきてはいますが、まずスタートしていただくぶんにはこの2つで大丈夫です。このシンプルさを、ECSの選択理由に挙げるお客さまもいらっしゃいます。

それからもう1つ。Linuxコンテナだけでなく、Windowsコンテナの実行も正式にサポートしている点も、大きな特徴として挙げられます。

先ほどECSの最大の特徴として「AWSネイティブなコンテナオーケストレーションツールゆえの、ほかのAWSサービスとの高度な連携がありますよ」というお話をしました。これらのサービスとの連携は、追加のツールとかソフトウェアのインストールなしにご利用いただくことができます。

AWSサービスのアイコン、こちらにたくさん並べていますけども、もちろんこれらは一部のアイコンでして、実際はもっと多くのサービスと連携でき、やはりこれこそがECSの大きなメリットと言えます。

運用難易度が高いKubernetesを使うための「Amazon EKS」

さて、次にいきます。Kubernetesというオープンソースのコンテナオーケストレーションツール、聞いたことある方も多いのではないでしょうか。

AWSでは2014年にECSを発表してからずっと機能追加を続けており、多くのお客さまにご利用いただいていました。一方で。オープンソースやそのエコシステムを好まれるお客さまは、仮想マシン、EC2上にこのKubernetesを自分たちでセットアップして、自分たちで運用して使うという時期が2年、3年と続いていました。

Kubernetesというのは、比較的運用難易度が高いと言われるオーケストレーションツールです。ゆえにご自身でEC2上にKubernetesをセットアップしているお客さまから「AWSのほうで管理・運用してくれないか」、「Kubernetesの管理そのものは俺たちのビジネスにとって本質じゃないんだ」と、そういう相談を多くいただくようになりました。

そこでAWSが提供を開始したのが、Amazon Elastic Kubernetes Service、通称「Amazon EKS」になります。ECS同様、EKSの特徴をここに挙げていきます。

まず先ほどお話したとおり、Kubernetesというソフトウェアは比較的運用難易度が高いです。どのような運用が必要かというところは、ここではちょっと詳細を触れませんが、興味ある方は一からセットアップして試してみていただくとよくわかると思います。

そしてこのEKS、オープンソースのKubernetesのコードには一切手をつけていません。アップストリームのコードをAWS上の環境にそのままデプロイして、それをお客さまに提供しています。実際にCNCF、これは「Cloud Native Computing Foundation」の略です。Kubernetesを管理しているLinux Foundation配下の組織ですが、このCNCFからEKSはプラットフォームとしてのサーティファイドを受けています。

どういうサーティファイドかというと、「ほかのKubernetesのサービスとの相互の移行容易性が担保されているサービスプラットフォームです」というものです。ゆえにKubernetesの周りには、多様なオープンソースのツールとかエコシステムがありますが、それらがちゃんとEKS上で動くというのも特徴となります。

オープンソースのKubernetesをAWSがサポートする意義

それからKubernetesそのものはECSと異なり、AWSのネイティブなサービスではありません。オープンソースのプロダクトですね。ですがお客さまが「KubernetesをAWS上で動かす」という選択をされる理由は、Kubernetesそのものの話だけではないんですね。

例えばAuroraというRDBのサービスがあったり、ALBというロードバランサーがあったり。そういったAWS全体のプラットフォームとしての価値を感じていらっしゃるからこそ、KubernetesをAWS上で動かすという選択をお客さまはされていらっしゃいます。

それに対してAWSは何に取り組んでいるかというと、EKSの開発チーム、それからオープンソースチームが積極的にKubernetesコミュニティにコントリビュートして、AWS上でKubernetesを動かすお客さまがより使いやすくなるように、オープンソースのプロダクトを追加で開発したり、Kubernetesの本体にコントリビュートしたりということをやっています。

それからもう1つ、これはEKSの特徴というよりKubernetesの特徴です。ECSでは、先ほど「タスクとサービスという2つの概念を学べばすぐに使えます」と言いました。Kubernetesはそれに対して、多様なリソースがあります。

というのも、ECSがAWSというプラットフォームの中のビルディングブロックとして存在しており、足りない機能はほかのサービスとの高度な連携で実現するのに対して、Kubernetesはオンプレミス上でも動作することを想定して作られており、そのリソースの表現力が非常に高いんですね。ここもEKS、Kubernetesの特徴としてあります。

Kubernetesはそれ単体でもたくさんの機能を有していますが、多くの場合お客さまは、なにかしらのOSSをKubernetesにインストールしていただくことが多いです。そして先ほどお伝えしたとおり、EKSでもこれらのOSSエコシステムをインストールしてご利用いただくことができます。

例えばモニタリングであればPrometheus、Grafana。CI／CDであればArgo CD、Spinnaker。サービスメッシュであればIstioとかLinkerd。ネットワーキングであればCNIの使用やCoreDNSといったものが挙げられます。またこれらのOSSを管理するのに便利な、HELMというKubernetesのパッケージマネージャーもございます。こちらを用いることで、各OSSのインストールやパッケージの展開を容易にすることもできます。

「コントロールプレーン」と「データプレーン」

Kubernetesのアーキテクチャは、大きく2つに分類されます。オレンジ色の枠に囲われているところが「コントロールプレーン」。青色の枠に囲まれているところが「データプレーン」と呼ばれます。EKSではマネージドなコントロールプレーンを提供しています。

コントロールプレーンというのは何かといいますと、オーケストレーションツールの脳みそにあたる部分ですね。どのサーバーにどれだけリソースが空いていて、今お客さまはどれだけのコンテナをデプロイしたいと言っていても、じゃあどこに配置すればいいのか。そういったところを判断してくれる部分がコントロールプレーンです。ここをフルマネージドで提供いたします。

そして下のデータプレーン、これはまさにコンテナが実行されるホストのことです。詳細は後ほどコンテナ実行環境の章で説明いたしますが、EKSをご利用いただく場合はデータプレーンとなる仮想マシン・EC2インスタンスを用意して、このクラスターに参加させるだけですね。

で、Kubernetesクラスターの操作は「キューブコントロール」というCLIコマンドを使って、コントロールプレーンに対し命令を発行します。キューブコントロールはもちろん、Amazone EKSでも変わらずにご利用いただけます。

このEKS、リリース以降まずはコントロールプレーンの完成度を高めていくことをゴールに、機能追加を進めてきました。プロダクション環境で利用いただけるようなKubernetes環境を提供するために、セキュリティや弾力性を高めていくことがEKSチームの最初の目標でした。

そして次のフェーズ2として今度は、EKSチームはデータプレーンについてもお客さまの運用・管理の負担を削減するための機能追加を行っております。そのためのアップデートの代表例の1つが、去年の「re:Invent」前の11月に発表された「EKS Managed Node Groups」でした。

具体的にどういうふうに変わったのか。もともとのEKSは、APIとして提供されていたのはコントロールプレーンに対する操作だけでした。ゆえにデータプレーンについては、お客さま自身でEC2インスタンスを用意して、コントロールプレーンに紐付ける必要がありました。

これがManaged Node Groupsの登場により、EKSのAPIだけでデータプレーンについてもコントロールいただけることができるようになります。これによりEKSクラスターのEC2インスタンスの、ノードのプロビジョニングとライフサイクル管理を自動化することができるようになり、お客さまのデータプレーンに対する管理・運用が行いやすくなりました。

Amazon ECRが持つイメージスキャン機能

さて、オーケストレーションツールを手に入れました。ではみなさま、最初の図を思い出してほしいのですが、まだ忘れているコンポーネントがありますね。そう、イメージレジストリです。イメージレジストリからコンテナイメージをダウンロードしてきて、コンテナを実行します。

このコンテナのイメージレジストリ、有名なものだとDocker Hubという、Dockerの公式のイメージレジストリサービスがありますね。

OSのオフィシャルイメージ、言語ランタイムやフレームワークのオフィシャルイメージなど、たくさんのイメージがホストされています。オンプレミスでコンテナを実行されている方は、自分たちで自前のプライベートレジストリを作って運用されているという方もいらっしゃるかもしれません。

そんな中、AWSではAmazon Elastic Container Registry、「Amazon ECR」というサービスを提供しています。

これは何かといいますと、完全にプライベートな、お客さまのAWSアカウント専用のコンテナイメージレジストリです。あとDocker Hubがアメリカにあるのに対して、ECRは例えば東京リージョンとかで展開することができますので、レイテンシーの面でも有利ですね。

それから、保管イメージは自動的に暗号化されます。あとIAM、AWSサービスにおけるアクセスや権限制御のサービスですね。そのIAMとこのECRは連携されております。「このイメージをダウンロードしていい」「このイメージは削除していい」というような細かな権限制御が可能になります。

それから例えば「100個のコンテナをデプロイしたいです」となりますと、同時に100個イメージレジストリからダウンロードが走るわけです。コンテナアプリケーションの使い方によっては、イメージレジストリというのは非常に高いスケーラビリティとか可用性が求められます。Amazon ECRは、そういった大規模な環境でもご利用いただけるサービスなっています。

それからDocker Hub同様、Amazon ECRも、いつものDockerコマンドからご利用いただけます。Docker pullとかDocker pushといったコマンドで、Amazon ECRをご利用いただけます。

さらにECS、EKS、Kubernetes on EC2といったAWS環境だけではなく、ほかの環境からでもECRはご利用いただけます。例えばローカルの開発者のラップトップでdocker pullコマンドを実行して、ECRからダウンロードいただくこともできます。こちらもECRの特徴と言えます。

コンテナのセキュリティに関わるところで、コンテナイメージに含まれるパッケージの脆弱性スキャンを行うことがあります。

また、ECRではECRネイティブな機能として、ECRイメージスキャン機能を提供しています。これはコンテナにインストールされたパッケージに対するCVEの静的スキャンに行います。

静的スキャンとは、例えばデプロイ前のフェーズで、イメージそのものに対して脆弱性スキャンを行うということを言います。ちなみに動的スキャンはランタイム環境にて実行されるスキャンのことを言います。

このECRのイメージスキャン機能ですが、オープンソースの中でも人気のあるプロジェクトであるCoreOSのClairを使ったスキャンを行っています。で、イメージスキャンはイメージのPush時に自動で行えるように設定することができ、いわゆるCI／CDのプロセスの中に組み込んで利用いただくこともできます。またスキャン自体は非同期での実行となります。そしてなにより、このイメージスキャンの機能に対してお客さまが支払っていただくコストは無料です。ぜひECRをご利用の際は、本機能もご活用ください。

コンテナの実行環境、内部にフォーカスしてみると…

次にいきます。コンテナ実行環境。コンテナ実行環境と言われても、いまいちピンとこないかもしれません。

これ、先ほどの図です。ここではAmazon ECSがオーケストレーションツールで、ECRがイメージレジストリです。コンテナ実行環境とは、ここのことです。

実際にコンテナが実行されている場所、ホストのことですね。このコンテナ実行環境は、この図ではEC2のインスタンス群となっています。

さて、このコンテナ実行環境のことを、もう少しフォーカスして中まで見ていこうと思います。仮想マシンの中にはOSがあります。それから最初に話しました、Dockerのエージェントもあります。それとオーケストレーションツール、先ほどの図で言うとECSのコントロールプレーン通信を行い、そしてDockerエージェントに対して指示を出すECSのエージェントが、EKSで言うとキューブレットというコンポーネントが動いています。

これらのコンポーネントに対して必要なオペレーションがありますね。例えばOSそのものや各種パッケージ・エージェント類のパッチ当てとか、更新・脆弱性が見つかった時とかです。それから実行中のコンテナの数に基づいて、仮想マシンのインスタンスタイプについて考えたり、また数をスケールアウト・スケールインしないといけません。

つまりコンテナのレイヤーと仮想マシンの、両方のレイヤーの管理が必要になるわけです。どうでしょうか。「コンテナは便利だけど実行環境の管理はしたくない。もっとコンテナを使ったアプリケーションの開発自体にフォーカスしたい」となってくるわけですね。

そこでAWSがローンチしたのが、AWS Fargateというサービスです。

めんどうくさいこと、すべてAWS Fargateがやります

先ほどの実行環境の仮想マシンの部分、EC2インスタンスはすべてAWSが管理・運用しています。例えばCVEが出た時のパッチ当て、これもAWSがやります。お客さまで意識していただく必要はありません。

仮想マシンのステータスがおかしくなった時の置き換え、これもAWSがやります。仮想マシンのスケールアウト・スケールイン、これもAWSがコントロールしますので意識いただく必要はありません。お客さまが考えるべきことは、コンテナのことだけなんですね。

AWS Fargateを使ったコンテナワークロードは、どういうイメージになるか。この図では仮想マシンがありますが、AWS Fargateをご利用いただくことでこれが、このように。お客さまから見えるものはコンテナのみで、仮想マシンを意識することなくコンテナオーケストレーションによるコンテナワークロードを展開することができるようになり、いわゆる仮想マシンの運用から解放されます。

またここでは、オーケストレーションツールはAmazon ECSとなっています。というのもですね、AWS Fargateが発表されたのが2017年で、その後はFargateはECSのみでサポートされてきました。EKSではご利用いただけなかったんですね。こちら、EKSでもFargateをご利用したいという要望、本当にたくさんいただいていました。

そして2019年12月、去年の「re:Invent」にですね、AWSはAmazon EKS on AWS Fargateをリリースし、EKSをご利用いただく際にもコンテナ実行環境としてAWS Fargateをご利用いただけるようになりました。またこちらの機能はすでに東京リージョンでご利用いただくこともできます。

4つのパターンから選べるコンテナ実行の選択肢

EKS on Fargateの登場により、AWS上でのコンテナ実行による選択肢を振り返りましょう。

まずはAmazon ECSがAWSでご利用いただけるようになり、お客さまはEC2インスタンス上でECSタスクを実行できるようになりました。これが2017年、AWS Fargateの登場で、お客さまはECSの実行環境であるEC2インスタンスのプロビジョニングや管理・運用を気にすることなく、コンテナが実行できるようになります。

次に2018年に、Amazon EKSが一般利用可能となり、これによりお客さまはマネージドなKubernetesコントロールプレーンを利用して、お客さまのEC2インスタンス上でKubernetesのポッドを実行できるようになりました。

そしてAWS FargateのEKSサポートが発表されました。お客さまはKubernetes環境においても、仮想マシンのプロビジョニング、管理・運用を気にせずコンテナの実行が可能となりました。

このように、現在オーケストレーションツールとしてECS・EKS、またコンテナを実行するデータプレーンにおいてもEC2・Fargateのそれぞれを選択でき、4つのパターンから選択いただけるようになっています。

AWS Fargateの購入オプションについてですが、FargateですがそもそもホストとなるEC2が見えませんので、実行するコンテナに割り当てたリソースに応じた、秒単位の従量課金となります。また2019年1月に50パーセントの値下げを実施しており、金額面でも選択していただきやすくなっています。

ただそれでもEC2と比較した際に、リザーブドインスタンスやスポットインスタンスというような購入オプションがFargateに今まで存在しなかったことで、金額面を理由にEC2を選択されるお客さまもいらっしゃいましたが、去年2019年に、「Compute Savings Plans」と「Fargate Spot」が登場したことで、さらにFargateの選択肢の幅が広がりました。

Fargate Spotですが、現在はECSのFargateでのみのサポートとなります。長期的なワークロードとか中断への耐性があるワークロードをコンテナで実行する際は、Savings PlansとかFargate Spotの選択肢も、ぜひご検討いただければと思います。

コンテナワークロード構築の考え方

ここまでAWSのコンテナ関連サービスを紹介いたしました。最後に、これからAWSのコンテナワークロードを構築していく方向けに、参考になりそうなエッセンスとか考え方を紹介しようと思います。

少しコンテナから視点を広げて、アプリケーションという単位から見たらいかがでしょうか。現実世界のアプリケーション、そのほとんどはきっと、本日紹介したコンテナサービスだけでは実現できませんね。

例えば先ほどの、コンテナイメージを作ってイメージレジストリにアップロードして、それをデプロイしてというCI／CDのパイプラインが必要だったり。アプリケーションのデータを保存する場所として、AuroraのようなRDBMSのサービスだったり、S3のようなオブジェクトストレージが必要になったり。

それから左下に小さく書いていますが、コンテナに渡す秘密情報。データベースのパスワードとか、外部のAPIのシークレットキーとか、そういうものを管理する場所も必要でしょう。設定値、例えばログレベルなどの管理のためのパラメータストアも必要となるでしょう。

ここまで、ご自身のコンテナワークロード構築にフィットするサービスを選ぶための軸となる情報を紹介してきました。また実際どのサービスを使えばいいのかは、実際のワークロードや運用設計次第ですし、正解はありません。ただこれからコンテナを本番で動かす上での、参考になる指針が欲しい。そういう方もいらっしゃるでしょう。そういった方向けに、AWS上のコンテナサービスを利用する上でのエッセンスをお伝えできればと思います。

まずFargateをご利用いただけないかを、コンテナ実行における最初の選択肢として考えましょう。少しでも運用にかかる負担を減らせるように、まずはFargateファーストで考えていただければと思います。

しかしもちろんEC2が最適なケースもあります。例えばFargateではGPUを使ったワークロードのサポートは現状されていませんので、この場合はEC2起動タイプをご利用いただくことになります。

ただ、AWSには現在170以上のサービスがあります。まずは該当するマネージドサービスがないかも確認しましょう。このGPUの例についても、仮にマシンラーニングのワークロードであれば、それに該当するマネージドサービスであるAmazon SageMakerがあるにも関わらず、考えなしでコンテナサービスで実現しようとするのはやめましょう。

そしてコンピューティングの選択肢としても、LambdaもあればEC2もあります。自分たちのワークロードやコンポーネントの特性に応じて、ビルディングブロックとしてサービスを使い分けていただくのが、うまいAWSの利用方法だと思います。

数字で見るAWSコンテナサービスの成長速度

さて最後に、AWSコンテナサービスを数字で見てみたいと思います。

まずクラウドで動いているコンテナアプリケーションの80パーセントはAWSで実行されています。AWSのコンテナサービス全体は、年比較で150パーセントの成長を見せました。EKSの使用量はこの1年で10倍になりましたし、Fargate起動タイプのコンテナ実行はこの1年で3倍になり、毎週1億タスクが実行されています。またECRからPullされるコンテナイメージの数は、1週間に20億以上です。この数字から、AWSコンテナサービスの成長の早さや、注目具合をご理解いただけると思います。

もう1つ。AWSのコンテナサービスでは、パブリックなコンテナロードマップというものをGitHubにて公開しています。こちらのロードマップ、一つひとつがGitHubのIssueで作られておりまして、みなさまのユースケースであったりとかご要望を自由に書いていただくことができます。ぜひこちらも一度、ご確認ください。

まとめます。AWSのコンテナ関連サービス、大きく3つのカテゴリーで紹介いたしました。

まずオーケストレーションツールでした。Amazon ECSというAWSネイティブなコンテナオーケストレーションツールと、OSSのデファクトであるKubernetesのマネージドサービスであるAmazon EKSの2つがあります。

それからイメージレジストリ、コンテナイメージの保存場所ですね。こちらのカテゴリーではAmazon ECRという、プライベートなレジストリを各リージョンに作成できるサービスがあります。それからホスティング、実行環境のサービスとして仮想マシンサービスであるAmazon EC2と、コンテナ実行環境をAWSマネージドにできるAWS Fargateがあります、とご紹介させていただきました。

このセッションの関連セッション、いくつかございます。本セッションでコンテナに興味が出た方は、ぜひこちらのセッションも一緒にご覧いただければと思います。

このセッションが、みなさまのAWS上のコンテナサービスの活用のきっかけになれば幸いです。それでは以上となります、ありがとうございました。