こんにちは。インフラエンジニアの永井(shnagai)です。
AWS re:Invent今年は大豊作ですごいですね。 特に待ちに待っていた、フルマネージドのコンテナサービスが発表されて、ECSでEC2の管理したくないなと思ってた勢としてはとても喜びを感じています。 EKSとの棲み分けも気になる所ですね。
AWS Fargateの紹介 – インフラストラクチャの管理不要でコンテナを起動 | Amazon Web Services ブログ
今回は、検証を兼ねてECS上で動かしているバッチ処理をFargateで動かしてみたのでそのレポートをお送りします。
この記事はコネヒト Advent Calendar 2017 3日目の記事です。
ゴール
既にECS環境で動いているDockerイメージとタスク定義をベースに、Fargateで一本バッチ処理を動かしてみて使用感を確かめてみる。
所感
検証メインの記事なので、はじめに所感から
Fargateいいですね!まさにこの願いが叶えられたといったトコロです!!
【良かったところ】
- クラスタマネジメントが不要になるので、運用コストは更に減るというかオートスケールをうまく組めればほぼECSクラスタを意識する必要はなくなりそう
- コスト面で見ても、ECSだと耐障害性を意識して、multiAZ構成で余分なリソース(EC2)を持っていたのが捨てられるのは大きいし、従量課金なので素晴らしい
- 既にECSを使っている人なら、既存のECS資産をかなり活かせるので移行コストはほぼかからないと実際に触ってみて思った。
【気になったところ】
- 起動がECSと比べると遅い ※バックエンドのEC2側でDokcerイメージのキャッシュが効かないから、起動が遅くなる気がする
- Fargateにバージョンの概念がありそうなので、そこは詳しく学びたい
検証手順
- タスク定義とdockerイメージをus-east-1に作る
- クラスタとタスクのワンタイム実行
- 感想
タスク定義とdockerイメージをus-east-1に作る
現状だと、Fargateはus-east-1でしか利用できないのでまずはap-northeast-1にあるDockerイメージとタスク定義をus-east-1に移動します。
ECRのリポジトリを作ってDockerイメージ を登録する
ECRで[test]というリポジトリを作ってそこにイメージを手元からpushします。
※aws cliのリージョン(~/.aws/config)をus-east-1に変更
※AWSIDはAWSアカウント毎に割り振られるIDを入れる。(ECRのリポジトリ画面で確認出来ます)
# ECRにログイン $ $(aws ecr get-login --region us-east-1 --no-include-email) # リポジトリの作成 $ aws ecr create-repository --repository-name test # dockerイメージのビルド $ docker build -t [AWSID].dkr.ecr.us-east-1.amazonaws.com/test:latest . # dockerイメージのpush $ docker push [AWSID].dkr.ecr.us-east-1.amazonaws.com/test:latest # イメージがpushされている事を確認 $ aws ecr list-images --repository-name test { "imageIds": [ { "imageTag": "latest", "imageDigest": "sha256:6cda52f3decf045bccce7e1161c6667f24958cc192fae48681014e0c8e9474f8" } ] }
タスク定義を登録する
[タスク定義]→[新しいタスク定義の作成]
早速Fargateの文字が!! どうやらタスク定義の時点で、EC2で動かすかFargateで動かすかを選択する必要があるようです。 ※既存のタスク定義を簡単に移行する方法が提供されるとWebinerで言っていたような気がするので東京リージョンに来る時にはそこら辺が整っていることに期待ですね。
続いて設定画面 Task execution IAM ロールという新しい概念がありますね! 「新しいロールの作成」にしておくと最適なロールが作られます。
メモリ,CPUリソースは関連性があり1Gだと0.25〜0.5vCPUしか使えません。
何となくバックエンドにいるEC2が感じられますね。
1コンテナあたりに使えるメモリは、0.5G〜6G
1コンテナあたりに使えるvCPUは、0.25vCPU〜4vCPU
メモリ、CPUリソースを入れるとこんな形で表記されます。
コンテナ設定の中身はほぼECSと同じですが、ログの部分だけAuto-configureがデフォルトでチェックされています。 おそらくFargateで動くコンテナは自動的にCloudWatch Logsに送られる作りになっているようです。
これまでは、CloudWatch Logsのロググループは手動で作成する必要があったのですが、勝手に作ってくれてちょっと便利になってます。
クラスタとタスクの実行
クラスタの作成
[クラスタ]→[クラスタの作成]
クラスタテンプレートという概念が生まれていますね。 ここでは、[Networking only]を選択します。
次の画面でクラスタ名を入れて、クラスタを作成します。
作成されたクラスタのUIはこれまでとほぼ同じですが、一部気になる所があったので抜粋します。
サービスとタスクのrunning数カウントに、FargateとEC2毎の数が出るようになっている
Fargateのクラスタを作ってもECSインスタンスのタブは出来るみたいです。(ココらへんは今後改善されていく予感)
タスクの実行
いよいよ本題のタスクの実行です。
[タスク]→[新しいタスクの実行]
ここでも新しい設定で気になったものだけピックアップしてみます。
- Launch typeにFARGATEが選択可能になっている
- タスク定義が選択方式になっていてこれまでの入力方式に比べるとかなりいいですね。(手動作業する時にリビジョン番号忘れがちだったので)
- Platform versionという概念が出来ている(Fargateのバージョンの話なのかな)
- タスク実行ボタンを教えてからの反応がちょっと悪くすこし待ちが必要です。
無事タスクが起動しました!!
CloudWatch Logsからも動いていることが確認出来ますね。
簡単にですが、FargateでECSで動かしていたタスクを実行してみました。 これからもう少しちゃんと検証してみて、あまりコストかからないと思っているので、ECS環境のFargate化に向けて動いていこうかなと思っています。
明日は、 リードエンジニア @yutmr さんによる記事をお送りします。
コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。