スタートアップのためのコンテナ入門 – AWS Fargate 編

こんにちは、スタートアップソリューションアーキテクトの松田 (@mats16k) です。

前回「スタートアップのためのコンテナ入門 – 導入編」という記事を公開致しましたが、今回はスタートアップ企業に特におすすめな AWS Fargate についてご紹介します。

前回もお話しましたが、「そろそろコンテナやった方がいいか？」「なんとなく使い始めたけれどこれでいいのか？」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。

※ 本記事は Amazon ECS を前提に書かれております。（執筆時点では Amazon EKS に未対応であったためです。）Amazon EKS であっても大枠での考え方に変わりはありませんが予めご了承下さい。

コンテナ利用時のホストマシンの運用

前回、「誤解２：コンテナ化により仮想マシンの管理・運用が不要になる」でも触れましたが改めておさらいです。

コンテナ利用の際にコンテナ自体の運用に注視されているお客様がたまにいらっしゃいますが、実際はホストマシンそのものの管理・運用は依然として残ったままになります。コンテナが動くホストマシンでは当然 OS が動いていますし、Docker の利用には Docker Engine が動いている必要があります。オーケストレーションツール利用の際は ecs-agent (Amazon ECS) や kubelet (Kubernetes) 等も動いている必要があります。これらへのパッチ当てやバージョンアップも依然として必要です。また、コンテナをスケールさせ数を増やす際は、コンテナの実行環境となるホストマシンを増やす必要があります。

コンテナが動くホストマシンのイメージ図（シマシマの箱がコンテナ）

コンテナが解決する技術課題は多くありますが、その一方で「コンテナ」と「コンテナの実行環境となるホストマシン」の両方を管理・運用しなければならないことと向き合い、対応していく必要があります。

このような一般的なコンテナワークロードにおける二重管理の課題を解決するために、AWS では AWS Fargate という機能を提供しております。

と、いうのが前回までのお話だったかと思います。

AWS Fargate とは

AWS Fargate とは Amazon Elastic Container Services (Amazon ECS) でコンテナを実行する際の起動タイプのうちの1つです。お客様は EC2 起動タイプ（前述の様にホストマシン上でコンテナを実行する）と Fargate 起動タイプから自社のワークロードに合ったものをお選びいただくことが出来ます。

下記は Amazon ECS の EC2 起動タイプでコンテナを実行した際のイメージ図です。

EC2 起動タイプのイメージ図

「どのホストマシン」で「どのコンテナ」を「いくつ起動する」かなどのハンドリングは、オーケストレーションツールである Amazon ECS から行うことが可能ですが、各ホストマシンの管理・運用業務は依然として残ります。（Optimized AMI や AWS Systems Manager などサポートするツールもあります）

これを AWS Fargate に切り替えると下記のようになります。

Fargate 起動タイプのイメージ図

ホストマシンが見えなくなり、OS や Docker Engine, ecs-agent が抽象化され Fargate プラットフォームに隠蔽されていることが分かるかと思います。お客様はホストマシンを意識すること無くコンテナを実行することが出来ます。また、既に Amazon ECS on EC2 で動いている Service については起動タイプを切り替えるだけでほぼ変わりなく AWS Fargate に移行することも可能です。これによるメリットについて順に説明していきます。

AWS Fargate のメリット

AWS Fargate の最大のメリットは「ホストマシンの管理・運用が不要」という点です。お客様はコンテナについてのみ検討すればよく、アプリケーションの構築と運用に注力できます。

では、「ホストマシンの管理・運用が不要」とはどういったメリットがあるのでしょうか。一つ一つブレイクダウンしていきましょう。（この時点でなるほど、それは便利だ！と納得できる方は読み飛ばしていただいてOKです）

メリット１：クラスタの管理が不要（キャパシティ）

通常、EC2 等の仮想マシンでクラスタを構築し運用する際には様々なことを考慮する必要があります。全体でどの程度のリソースが必要かを見積もった上で、インスタンスタイプの選定、必要な総台数の計算などです。また、見積もりと実利用状況は乖離することは大いにあるため、リソースのモニタリングも重要です。

AWS Fargate を利用すると、こういったことを意識することなくコンテナを実行することが出来ます。お客様はコンテナ実行時に必要な CPU, メモリの組み合わせを選択するだけでよく、リソースの調達等は Fargate プラットフォーム側で行われます。

AWS Fargate で利用可能な CPU とメモリの組み合わせ

メリット２：シームレスなスケーリング

コンテナお使いになっているお客さまの多くが、負荷やジョブキューの数に応じてコンテナの数をオートスケールさせています。（なお、コンテナでなくてもオートスケールの実装は可能です）

コンテナをお客様が管理するクラスタ上で起動している場合、クラスタのキャパシティに気を配る必要があります。コンテナをスケールする際に実行に必要なリソースが無ければコンテナを新規に実行できないからです。クラスタ全体のキャパシティ状況を常にモニタリングし、コンテナと合わせてスケールさせる必要があり、多くのお客様が下記いずれかの戦略を取られます。

常に余裕を持ってクラスタのキャパシティをコントロールする
コンテナが新規に起動・配置できない状況を hook してホストマシンを追加する

それぞれコンテナの起動という面では問題ありませんが、課題もあります。１は常に余分にホストマシンを稼働する必要があるため、サーバーコストも余分にかかります。２はコンテナの起動時間にホストマシン起動のオーバーヘッドが乗るため、コンテナのアジリティが低下します。１と２はどちらかを選択しなければいけないわけでは無いので、実際には自社のワークロードに応じてバランスを取ることになりますが、どの程度バッファを見積もってキャパシティをコントロールすればいいのかや、突発的なスケールアウトをどの様にハンドリングするかなど、高度かつ戦略的な運用が求められます。

また、ホストマシンの停止時にも注意が必要です。実行しているコンテナの数が減少し、ホストマシンを集約し残りを停止したいという場合に、実行中のコンテナをサービス影響ないように移動させる必要があります。技術的には可能ではありますが、お客様はより多くのことを考慮する必要があります。

こうした運用に強みを持っているお客様もいらっしゃいますが、多くのお客様はそうではありません。AWS Fargate を利用することで上記のようなことを考慮せずに、コンテナをスケーリングさせることが可能になります。

メリット３：ホストマシンの管理が不要（セキュリティ等）

コンテナワークロードに限らず、通常 EC2 等の仮想マシンを運用する際は、 OS やミドルウェアのバージョンアップやセキュリティパッチの適用などをやらなければなりません。（耳が痛いスタートアップもいるかもしれませんが、、重要なことです。）

Fargate プラットフォームの管理運用は AWS にて行うため、お客様はコンテナについてのみ検討すればよく、アプリケーションの構築と運用に注力できます。前述の OS や Docker Engine, ecs-agent 等のバージョンアップやセキュリティパッチの適用もこの中に含まれるため、お客様が行う必要はありません。

また、その水準も高く、各種コンプライアンスプログラムに適合しています。詳しくは「よくある質問」や「AWS Fargate が ISO、PCI、SOC、HIPAA の規制対象であるコンテナワークロードをサポート」をご覧ください。

セキュリティは事業を守るため、そしてサービスのユーザーを守るため重要です。しかし、リソースが限られているスタートアップにおいては、事業の差別化やエンドユーザーへの価値提供に直接つながる機能開発が優先され、残念ながらセキュリティが後回しにされてしまうケースもあるのではないでしょうか。そんなとき、AWS Fargate を利用することは容易にセキュリティレベルを向上する手段の一つとなります。こういった “Undifferentiated Heavy Lifting” （差別化に繋がらない重労働）を積極的にオフロードしていくことが、リソースの少ないスタートアップにとって重要ではないでしょうか。

AWS Fargate に関するよくある質問

ここでは AWS Fargate を初めてお使いになるお客様からよく頂く質問を紹介いたします。

質問１：でもお高いんでしょう？

下のスライドでも紹介していますが、AWS Fargate の方が最適化されることが多いです。同等のコンピューティングリソースを単純に時間単価で比べると EC2 の方が安価に見えますが、実際には Fargate であれば必要なリソースをより細かく適切に利用することができるため、よりコスト効率の高い使い方にコントロールしやすいと言えます。

リソースを 100% アプリケーションで利用できることは、試算も楽になるので嬉しいのではないでしょうか。

Node.js や Golang の様なフットプリントの小さい言語の場合、より細かい単位でスケールさせることが出来るため、より負荷に対して Adaptive にスケールさせることも出来ます。

また、上記は純粋なサーバーコストについてですが、運用コストを大幅に削減できることについても考慮すべきかと思います。

質問２：コンテナの中に ssh や docker exec で入ることは出来ますか？

こちら現状サポートしておりませんが、コンテナワークロードでは「同一の環境でしっかりテストを行う」ことや「ログを外部に全て出す」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。

また、アプリケーションの実行環境（コンテナ）に入れないことをセキュアと捉え、採用頂いているケースも多くあります。直近では、メルペイ様にアンチマネーロンダリング (AML) の基盤に採用頂いた事例をお話し頂きました。（詳細なイベントレポートが後日出るのでお待ち下さい。）

merpay の AML 基盤における AWS Fargate 活用事例、その選定理由

質問3: 逆に EC2 上でコンテナを動かすケースは？

基本的には前述のメリットから AWS Fargate を 1st choice としておすすめしていますが、EC2 の方が適している場合もあります。

リザーブドインスタンス/スポットインスタンスを利用する場合

既に購入しいるリザーブドインスタンスを利用したい場合は EC2 を選択する必要があります。

また、スポットインスタンスを利用する場合も同様です。スポットインスタンスを利用する場合は前述のホストマシンの管理に加え、スポットインスタンスの購入戦略（どのインスタンスタイプを組み合わせるか）や退役処理を考慮する必要があります。スポットインスタンスによるインフラコストの削減幅と運用コストを天秤にかけ選択されることをおすすめします。（必然的に大規模でなければメリットは出にくいかと思います）

GPU を利用する場合

AWS Fargateでは現状、CPU リソースのみ利用可能です。機械学習ワークロードでの利用が予想されますが、AWS では Amazon SageMaker を代表とする AI/ML サービスも充実しています。全てを自前で実装しようとせず、マネージドサービスを活用されてはいかがでしょうか。

※ Amazon SageMaker はスポットトレーニングも発表されました。コストを理由に自前構築を検討されている場合は、魅力的な選択肢になるかと思います。

EKS/Kubernetes が使いたい場合

将来的な AWS Fargate の Amazon EKS 対応は既に発表済みですが、現状未リリースのためご自身でクラスタを運用頂く必要があります。

AWS Fargate のはじめかた

ここでは AWS Fargate を利用してサービスを構築して行く際の 1st step についてご紹介します。初めての場合は、いきなり自社のアプリケーションを動かそうとせず、まずは ECS のチュートリアルを動かし、後にコンテナを入れ替えるなどのアプローチのほうがスムーズに進められるでしょう。

※ 初めてではない方は AWS CloudFormation や Terraform などお好きなものをお使い下さい。

マネジメントコンソールから

最も簡単な方法はマネジメントコンソールからチュートリアルを開始することです。ログインしたら AWS Fargate のチュートリアル開始画面にアクセスしてください。

こちらの画面からサンプルアプリケーションを実行可能です。

チュートリアルを進めることで、サンプルのサービスを起動することが出来ます。これにより作成される Service や TaskDefinition を改変ししていくことで、自社のアプリケーションを実行することも出来ます。（Listen する Port 等の差異にご注意ください）

GUI で操作することに抵抗がある方には、後述の方法をおすすめします。

ecs-cli compose を利用する

AWS は ecs-cli というコマンドラインツールを提供しています。（インストール方法や詳細な使い方はドキュメントを参照）サブコマンドに ecs-cli compose というものがあり、docker-compose のように Amazon ECS 上でサービスを実行することが出来ます。

「チュートリアル: Amazon ECS CLI を使用して Fargate タスクのクラスターを作成する」を進めることで、docker-compose.yml を元に AWS Fargate 上でコンテナを動かすことが可能になります。まずはサンプルを動かし、その後 docker-compose.yml を自社用に改変していってはいかがでしょうか。

※ Amazon ECS 用の設定を ecs-params.yml に書く必要があるなど、docker-compose と一部仕様が異なる点があるのでご注意下さい。

AWS CLI を利用する

もちろん AWS CLI からコンテナを実行することも出来ます。「チュートリアル: AWS CLI を使用して Fargate タスクのクラスターを作成する」を進めることで、慣れ親しんだ AWS CLI から AWS Fargate を利用することが出来ます。（パラメーターの引き渡しに json ファイルの記述が必要なため、ファイルの扱いにはご注意下さい。）

まとめ

いかがでしょうか。AWS Fargate の魅力は伝わりましたか？

AWS Fargate を利用することにより、ホストマシンの管理やパッチ当てといった多くの “Undifferentiated Heavy Lifting” （差別化に繋がらない重労働）を AWS にオフロードすることが可能です。AWS Fargate に限った話ではありませんが、リソースに限りのあるスタートアップこそ、こうしたマネージドサービスを積極的に利用し、プロダクトの価値向上にフォーカスして頂ければと思います。

また、Kubernetes が気なっているスタートアップも多くいらっしゃいます。次回はそういったスタートアップ向けに Amazon EKS / Kubernetes についての記事をお送りする予定です。

このブログの著者

松田和樹 (Kazuki Matsuda) @mats16k

コンテナやビッグデータが得意分野なスタートアップソリューションアーキテクト。好きなサービスは AWS Fargate, AWS Chalice 。最近は AWS Amplify が好きです。

AWS Startup ブログ