AWS Fargate ことはじめ

 Amazon Web Services Advent Calendar 2017 - Qiita の17日目です:D

 AWS Fargate 触ってみました!re:Invent 2017 の発表の中で、個人的にアツかったアップデートNo.1が DynamoDB まわりの改善、その次が Cloud9 かこの Fargate です。が、先輩と話している中で、Fargate の旨味をうまく説明できなかったので、まずは触ってみて良さを腹落ちさせていこうと考えています。

AWS Fargate?

 AWS には ECS というコンテナサービスがあります。少し前(re:Invent の前あたり?)までは EC2 Container Service だったのですが、あるときから Elastic Container Service に変わっていました。以前の ECS は、Docker コンテナを EC2 上で管理できるサービスでした。Docker 環境入りの EC2 が立ち上がり、その上で独自のコンテナを動かせますよ、という私の感覚では「Hadoop 入りの EC2 作ってあげるから後はよしなに使ってね」という EMR に近い思想のサービスだと思っていました。

 これはこれでありがたいと思うのですが、EC2 インスタンスを意識する必要がありました。過去の AWS Webiner の中でも、常に稼働している EC2 は RI 当てましょう、スケール分については Spot Fleet を使いましょう、というような説明があり、素の EC2 を用いるときと同レベルで EC2 インスタンスの存在を意識しないといけなそうな機運を感じていました。

 AWS Fargate は re:Invent 2017 の中で発表されたサービスです。Fargate を用いることで EC2 インスタンスなしでもコンテナを動かすことができるようになりました。パッチ当てなどの運用作業をしなくて済むので、いわゆるサーバレスな世界に近づいたのかなと思っています。ただ、実際に使ってみないとイマイチ感覚がわからん。。というわけでまずは使っていきましょうということで、第一弾としてチュートリアルを触ってみました。

 チュートリアルを進めるにあたり、下記の記事を参考にさせていただきました

AWS FargateでNginxを動かしてみる

AWS Fargateとは?

チュートリアルをやってみました

 apache 上で静的なコンテンツを動かすアプリを動かしてみました。下記の URL から行えますので、ぜひ試してみてください。(めっちゃ簡単です。)

https://console.aws.amazon.com/ecs/home?region=us-east-1#/firstRun

コンテナ定義とタスク定義

f:id:ketancho_jp:20171215053421p:plain

 まずはコンテナの定義です。ここでは sample-app を選択します。将来的に自身の環境を作る場合はここで custom を選び、独自のコンテナイメージを利用したり、ポートマッピングを定義していくことになりそうです。

f:id:ketancho_jp:20171215053502p:plain

 次に、クラスタの上で稼働するタスク定義をしていきます。ここもデフォルトのままで問題ありませんが、CPU/メモリの割り当て設定や、各タスクに割り当てる IAM ロールの設定はここで行うことができます。

f:id:ketancho_jp:20171215053800p:plain

サービス定義

f:id:ketancho_jp:20171215054048p:plain

 次にサービスを定義していきます。ここでは、 Load balancer type として ALB を選択してください。同時稼働するサービスの数を増やしてスケールさせたい時に、ALB に紐付けてくれます。ここではこれ以外の設定はそのままでいいのですが、セキュリティグループの設定などもここで行うことができます。

f:id:ketancho_jp:20171215054133p:plain

クラスタ定義

f:id:ketancho_jp:20171215054349p:plain

 最後にクラスタに名前をつけてあげてください。VPC や Subnet を選択できるのかなと思ったのですが、 Automatically create new と表示されており、変更することはできませんでした。

f:id:ketancho_jp:20171215054451p:plain

 ここまでで設定が終わりです。にょきにょきリソースが作られていきます。

f:id:ketancho_jp:20171215054711p:plain

動作確認

 「詳細」タブから、ALBのページに飛んでください。 f:id:ketancho_jp:20171215055112p:plain

続いて、ロードバランサを選択してください。 f:id:ketancho_jp:20171215055341p:plain

DNS名をコピーしてブラウザで開くと、、、 f:id:ketancho_jp:20171215055502p:plain

こんな画面になったと思います。うまくいきましたでしょうか? f:id:ketancho_jp:20171215055534p:plain

アプリを修正する

 下記の画面のタスク定義をクリックします。 f:id:ketancho_jp:20171215055819p:plain

新しいリビジョンを作成してください。 f:id:ketancho_jp:20171215055911p:plain

途中にあるコンテナ名をクリックすると、コンテナの設定を変更することができます。 f:id:ketancho_jp:20171215060056p:plain

コマンドを少し変えてみてください。 f:id:ketancho_jp:20171215060234p:plain

「サービスの更新」を実行します。 f:id:ketancho_jp:20171215060346p:plain

どのようにデプロイするかを選択することができます。特に変更はしませんが、下記の設定の場合はタスク数は最低でも現状(1つ)を維持しつつ、一時的にタスクを増やして(この場合は200%なので2台)デプロイすることになります。 f:id:ketancho_jp:20171215060422p:plain

リリースが始まると、一時的に二つ目のタスクが立ち上がってきます。 f:id:ketancho_jp:20171215060742p:plain

暫く待つとアプリが更新されました!(英語変だ、、お許しを。) f:id:ketancho_jp:20171215061030p:plain

このときALBの状態を見てみると、古いタスクが draining 状態になります。これは、新規のリクエスト受付を止め、現在処理中のリクエストがなくなったタイミングで切り離されるよ、という状態です。

f:id:ketancho_jp:20171215061102p:plain

少し待つとタスクがひとつに戻ることが分かると思います。 f:id:ketancho_jp:20171215061528p:plain

検証が終わったらクラスターの削除を忘れずにしておきましょう。作成したリソースをまとめて削除してくれます。

まとめと今後

 簡単ではありますが、実際に触ってみたことでサービスのイメージがつきました。こういうシーンだと使えそうだ!というのを思いついたので、次はそれを実現できるかを試してみたいと思います。いいサービスですね :D