[Webinarレポート]AWS Startup fm AWS Fargate で始める、らくらくコンテナ生活！〜運用/セキュリティを AWS に任せて、ビジネスにフォーカスしよう！〜

かずえ

2020.10.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSJ主催のWebinar「【AWS Startup fm】AWS Fargate で始める、らくらくコンテナ生活！〜運用/セキュリティを AWS に任せて、ビジネスにフォーカスしよう！」を聴講したのでレポートします。セッションとQ&Aの大きく2段構成でした。

Webiner概要

【AWS Startup fm】AWS Fargate で始める、らくらくコンテナ生活！〜運用/セキュリティを AWS に任せて、ビジネスにフォーカスしよう！〜]

今回のテーマは「コンテナ」および「 AWS Fargate 」です。現在、多くのスタートアップ企業様がコンテナ技術を活用されていますが、まだまだ活用できていないといった企業様も多くいらっしゃいます。また、コンテナを活用している企業様も、その特性や利便性を上手く引き出せていないケースも多々あります。本セッションでは、プロダクトの価値向上において、どの様にコンテナ技術を利用するべきなのかという点についてフォーカスしてお話致します。また、OSS をサクッと AWS Fargate に展開するデモ/サンプルのご紹介や、コンテナの活用をすぐに始めるための魅力的なキャンペーンのご案内も予定しておりますので、ぜひご参加ください！

AWS Startup fm とは？

オンラインで、スタートアップ出身の AWS エンジニアが、1時間ほどテーマを決めて AWS のサービスや最新事例をご紹介するとともに、テーマに関連した視聴者の相談をカジュアルに回答していきます。

Sessionスピーカー兼Q&A回答者

AWSJ ソリューションアーキテクト matsさん

Session

アンケート

まず参加者の状況を知るためにSlidoでライブアンケートが行われました。

※以下画像はアンケート中にキャプチャしたものなので、最終結果とは少し異なるかもしれません。

以下がセッション内容です。

なぜコンテナか

アプリケーションを構成するコンポーネント

ランタイム/エンジン
アプリケーションコード
依存ライブラリ/ パッケージ
設定
※これらが互いに絡み合っている

ローカルでは動いたけど、本番では動かない？

↑のコンポーネントの一部に差分があってエラーが発生していた（例: Node.jsのバージョンが違う）

コンテナという解決策

コンテナイメージの中に上記コンポーネント群をまとめて格納するので、依存関係の問題が起こらない

コンテナ技術の標準となったDocker

オープンソースプロジェクト
Linux /macOS /Windowsなどで稼働
高まるDevとOps両方の需要に対応
すべての環境で同じコンテナを動かす

仮想マシンとコンテナ

コンテナはリソースが隔離されたプロセス = 仮想マシンではない

Dockerを利用した基本的ワークフロー

イメージ作成 2通りあるが多くは前者
- Dockerfile書く → それを基にイメージ作成
- コンテナを起動してコンテナ内で作業 → docker commitしてイメージ作成
イメージレジストリ（保管場所）に置く
仮想マシンに入る
docker pull でイメージレジストリからイメージダウンロード
docker run でコンテナ実行

思っていたよりも手作業

dockerの責務は同一サーバ上のコンテナライフサイクル管理のみ

コンテナオーケストレーション

手作業でのコンテナイメージダウンロードと実行は非効率かつミスオペレーションを招く→コンテナオーケストレーションツールを使う

AWSで利用できるコンテナオーケストレーション

ECS
kubernetes(k8s) → EKS(k8sのマネージドサービス)

コンテナ実行環境

コンテナが動く仮想マシンのこと。AWSだとEC2インスタンス

構成要素

OS
Docker Agent
ECS Agent or kubelet

以下のような作業が必要になる

EC2運用業務
OSやエージェント類へのパッチ当て、更新
EC2インスタンス数のスケーリング

→ なかなか大変。そこで　Fargateを使おう

AWS Fargateではじめる、らくらくコンテナ生活

Fargateプラットフォーム上でコンテナが動く

AWSが以下を管理してくれる

EC2インスタンスプロビジョニングや管理
状態異常が発生したインスタンスの再起動、入れ替え
ホストレベルのスケーリング管理

EC2上でコンテナを動かす場合でも、最近 ECS Cluster Auto Scaling / EKS Managed Node Groupなどで楽になっているが、管理責任はエンジニアにある

らくらくコンテナ生活

コンテナ(Task or Pod)を「AWS内でのファーストクラスオブジェクト」として扱うことができる、のがメリット
「コンテナだから」を考える必要がなくなる = 実装方法は異なるがやってることはこれまでと同じ

例 ALB - EC2 - Aurora の構成をECS Fargateに置き換えてみる

ものは変わるが構成は変わってない
- AMI → Docker Image(保管先がECR)
- EC2 Instance → ECS Task(コンテナ)
- Auto Scaling → ECS Service
変わらない部分
- Networkの考え方
- Security Groupの考え方
- IAM Roleの考え方
- CloudWatchによるモニタリング

らくらくじゃないところ

手作業で仮想マシンを運用したのと比べると‥

イメージ化しないとデプロイすることができない
ログ等を外出ししないと行けない
接続先などの情報を環境変数などから読むようにしなければならない

実はほとんどはコンテナだからではなく、生産性や信頼性の高いモダンアプリケーションを構築するために必要なこと(The Twelve-Factor App)であり、仮想マシンにも当てはまる

サンプルアプリケーション

WordPress

まずはこれをデプロイしてみて、タスク定義など設定を参考にしてもらえれば

始め方

CloudFormation スタックの作成ページに移動
テンプレートソースで「Amazon S3 URL」を選択、下のAmazon S3 URL欄にhttps://startup-fm.s3.ap-northeast-1.amazonaws.com/demo/wordpress-fargate.yamlと入力
あとは手順に沿って…

注意事項

本番利用を想定していません。本番利用する際は必ず要件に合わせて設定変更を

コンテナのオートスケール
Auroraインスタンスタイプ変更
CDN活用
など

まとめ

仮想マシンからの以降はECS+Fargateがおすすめ
- Security GroupやIAMの考え方は今まで通り
- コンテナ活用にフォーカスできる
コンテナ運用はFargateで楽になるが、コンテナ化は自社で頑張る必要がある
- Twelve-Factor Appが参考になる
- 検証段階であれば、コンテナが用意されているOSSを利用するのも手
すでにk8sをお使いの場合も、EKS x Fargateが利用できる

Q&A

これからAWS上でコンテナを利用する場合、ECS or EKSどちらを使うか迷っている場合、どちらを使うべきとかありますか？

敷居の低いのはECS on Fargate。ECSはAWSネイティブ。EKSはk8sの思想を学ぶ必要があるというか、k8sのやり方経由でAWSリソース(ALB等)を操作する必要がある。

すでにEC2 AutoScaling で動いているアプリケーションがある場合、Fargate に置き換えるかどうかはどのように判断したらよいでしょうか？

問題が無いならコンテナ化しなくてよいのでは？コンテナは仮想マシンの上位互換ではないので必ずしも移行する必要はない。コンテナのメリットがプラスになるのであればコンテナ化を検討すべき。

セキュリティを理由にFargateに移行されるお客様もいる。仮想マシンのセキュリティを自社で責任持つのが大変なので。

Fargateを使った場合、Fargate自体のコスト削減の方法って何かありますか？

２つある。

Savings Plans https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-savings-plans/
- Fargateだと15〜47%のコスト削減が見込める
Fargate Spot https://aws.amazon.com/jp/blogs/news/aws-fargate-spot-now-generally-available/
- 注意点: EC2 Spot Instanceと同様、AWS都合でタスクが終了してしまう
- オンデマンド価格より最大7割のコスト削減