2020/04/14に加筆しました。
はじめに
2019年序盤から、値下げ、機能追加連発でとても利用しやすくなったAWS Fargateについて
弊社でも取扱が急速に増えてきましたので、代表的なパターンとして紹介させて頂きます。
※こちらの記事ではコンテナ内部の設計/Fargate詳細については深く触れておりません。
なぜ/いつFargateを利用するか
Fargate登場前までは、AWS上でコンテナを利用するためには、コンテナを動かす場所としてEC2が必要でした。
つまり、コンテナだけを動かしたいのに、EC2インスタンスを管理する必要がありました。
この状況がFargateの登場により、大きく変化しUpdateを重ねた結果多くの方が本番環境での利用に非常に前向きでいらっしゃいます。
Fargateを利用する = コンテナ運用を理解して設計するという事になりますので、ノウハウは必要となってきますが
最近のアプリケーションフレームワークであれば、コンテナを利用した構成/開発環境が事実上標準というケースも多いため、障壁はどんどん取り払われていると考えております。
特に、処理能力/費用を x0 から x100まで大きく変えたいと言う要件や、CI/CDパイプラインと組み合わせてデプロイを何度も実施したい
実行時間制限があるためLambdaには移行出来ないというようなモノは検討する価値があります。
※ただしレガシーなWebアプリで、EC2からいきなりコンテナに移行したいという物はNGなケースが多いです。
ざっくり言うとステートレスなシステムであるという必要がございます。（Cache、SessionはRedis/memcache等へ、大きなファイルはS3へ等々)
Fargateにまつわる大きなニュース
- 2017年 re:Inventにてサービス発表 一部リージョンで利用可能に
- 2018年7月に東京リージョンサービス開始
- 2019年 年初に大幅値下げ
- 2019年2月にVPCPrivateLink対応
プライベートサブネットに属するFargateがECRからImagePullする際にインターネットを経由する必要がなくなった
NATGateway経由でコンテナのImageを毎回Pullすると、かなりの通信量となり、金額に跳ね返ってきていた。
追記:VPCPrivateLinkを利用しても費用はかかりますが、NATGateway利用と比べて処理データ費用がおよそ1/6に抑えられるようになりました。- AWS PrivateLink の料金
https://aws.amazon.com/jp/privatelink/pricing/ - Amazon VPC の料金 (NAT ゲートウェイ料金記載あり)
https://aws.amazon.com/jp/vpc/pricing/
- AWS PrivateLink の料金
- 2020年4月 EFSMountに対応
https://www.skyarch.net/blog/?p=18336
目次
代表的なパターン
パイプライン
CodeCommitにソースコードがPushされたら、新しいコンテナImageの作成、Fargateタスク定義の更新・デプロイ(Blue-Greenデプロイメントにてサービス無停止)までを自動化するパイプラインです。
このパイプラインのおかげで、何度もデプロイを実施出来ますので、個人的にこのFargate+Code***サービスの組み合わせは素晴らしいなぁと日々感じております。
追記
AWS Fargate with CI/CDパイプラインでデプロイ失敗する原因について まとめてみました。
https://www.skyarch.net/blog/?p=18353
運用に関して
サーバレスアーキテクチャでも同様の事が当てはまりますが下記のような点に気をつけます。
サービス監視について
サービス監視リクエストに応答するWebページ、API等を作成頂きLambdaにてアクセスを実施。
正常かどうかを判別し結果をCloudWatch MetricsへPutします。
CloudWatch Metricsへ値を登録しておく事で、いざ障害が起きた際に確認を行える事と、CloudWatch Alarmを設定しアラート発報を実施する事ができます。
また、Fargateならではとして、元々のメトリクスが少ないため、実行中のタスク数をPutするLambdaを利用し監視対象とする事があります。
(加筆)
Amazon CloudWatch Container Insightsがリリースされたため、こちらを有効化しましょう。
https://aws.amazon.com/jp/blogs/news/introducing-container-insights-for-amazon-ecs/
ログ保存について
ログ保管の観点からS3へのエクスポートを望まれるお客様が多いためこの形を取るケースが多いです。
上記サービス監視に加え、数秒に1回コンテナ内部でのヘルスチェックコマンドが実施されるため、ログ容量が大きくなりがちです。
SNSから発報されるメールが読みづらい & Unsubscribeされたら困る
弊社を含め、基本的にアラート件名でエスカレーション先を変える、インパクト・緊急度を判断する
というケースは多いと思います。
このため、下記のような構成で実現しています。
送信先Topicを複数用意しておき、件名に応じて変えたり色々使えますね。
Unsubscribe無効化については
昔からの話ではありますが、EC2主流の時代には別の監視ツールを利用していた等で問題にならなかったというケースもあるかもしれませんが
RDS/EC2インスタンスのメンテナンス通知等、AWSを利用する上で、CloudWatch、Alarm、SNS Topicからは逃れられないのですぐに設定しましょう！
【SSM Automation】Amazon SNS のサブスクリプション解除リンク無効化を楽に行う
https://www.skyarch.net/blog/?p=18175
Tips/気をつける事
Twelve-Factor Appを意識しコンテンツを開発する
The Twelve-Factor Appで考えるAWSのサービス開発
https://www.slideshare.net/AmazonWebServicesJapan/the-twelvefactor-appaws
コンテナ上のミドルウェアが吐き出したログと、アプリケーションログが混ざってしまう
LogをJsonフォーマットで吐き出し、CloudWatch Logs → Kinesis Stream (Lambda) にて分離し
LogGroupを分離する等で対応します。
AWS SystemManagerParameterStore の活用
コンテナ内部に固有値をもたせるのではなく、環境変数やSSMパラメータストアを活用しましょう。
バッチ/スケジューリング時に少し気になる起動速度について
X分毎に起動/Cron式にてFargateタスクの起動時間を制御する事が可能です。
EC2に比べると爆速ですが、ECRからのイメージPull等でそれなりに時間はかかります。
（実施する機会は無いと思いますが） 毎分実行というスケジュールを試してみた所意図した通りに動く/動かないばらつきがありました。
参考: AWS Fargate のイメージサイズ毎の起動時間の違い
https://qiita.com/kjm/items/a86c5a425c57439ecfa0
制限等
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_limits.html
Fargate 起動タイプを使用するタスクの数
Autoscaleだしどんとこい！としていると、デフォルトでは 50個制限となっているため気をつけましょう。
パブリックIPを利用する場合は、同様に パブリックIPアドレスの数制限、そもそもネットワーク設計も問題ないか要確認です。
サービスあたりのロードバランサーの数
変更できないAmazon ECS の制限として 1つと定められています。
複数のポートを1サービスで捌くことは出来ませんので、ポート毎にサービスを作る必要があります。
宣伝
弊社では、元々3年ほど前からサーバレスアーキテクチャに本腰を入れて取り組んでおりましたが
Fargateの度重なるUpdateで、ここ半年でご相談/事例がどんどん増えております。
サーバレス、Lambda、Fargate、CodeCommit、CodePipelineというキーワードが出てくるシステムの設計段階から、構築、開発、運用設計・実際の運用まで幅広くお手伝いさせて頂きますのでぜひお声がけ下さい。
投稿者プロフィール
