この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWSJ主催のWebinar「【AWS Startup fm】AWS Fargate で始める、らくらくコンテナ生活！ 〜運用/セキュリティを AWS に任せて、ビジネスにフォーカスしよう！」を聴講したのでレポートします。セッションとQ&Aの大きく2段構成でした。
Webiner概要
今回のテーマは「コンテナ」および「 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割のコスト削減
EKSではFargate spotがまだ未対応と理解していましたが、実装される予定は今のところありますでしょうか。
頑張ってます！お待ち下さい！
Fargate についてもっと詳しく知りたいです。ネクストステップはBlackbelt を観ればよいですか？
BlackBeltはいい方法だと思うが、何を知りたいかによる。触ったこと無いのであればまずは触ってみたほうが良い。
re:InventのDeep Diveセッションなどもおすすめ。
Beanstalk + DockerHubでコンテナをデプロイしています。Fargateへの移行は簡単にできますか?
そんなに難しくないと思う。すでにステートレス化はできているので。DockerHub→ECRへの移行がおすすめ。
ECS x Fargate で、想定されるアクセス数で必要なタスク数の見積もりをする場合、タスク定義のどこの値をみて計算したら良いのでしょうか？
この数字だけだと難しい。ECSタスクひとつあたりで安定してさばけるリクエスト数と、その時のCPU利用率を見積もってください。
感想
なぜコンテナなのかというところからなぜFargateなのかという部分まで、シンプルにわかりやすく説明されており理解しやすかったです。Slidoを使ってのアンケートやQ&Aもライブ感があってとても良かったです。Fargateをもっと活用していきたいと思います。
3
