楽になりたくてECS Fargate〜Cloud NativeとECS利用の現場〜

楽になりたくてECS Fargate
〜Cloud NativeとECS利用の現場〜
2021.06.17
Uzabase, Inc.
SaaS Product Div. SRE Team
Yuta Sakai

View Slide

2
自己紹介
酒井　優太
株式会社ユーザベース
SaaS Product Division
SRE Team所属
2018年より株式会社FORCAS（株式会社ユーザベース完全子会社、2021
年より株式会社ユーザベースに統合）に入社、サービスインフラの改善・
運用・情報セキュリティ等を担当。

View Slide

3
今日のお話1　
AWSを利用
+
取り敢えずEC2内でコンテナ起動する形でサービス稼働開始
+
JenkinsでAWS CLIを使ってB/Gデプロイ処理などを自作
+
役割コンテナが20くらいに育ってきた
=
色々と積み上がって大変な環境
これをなんとかしないと。。。

View Slide

4
今日のお話2　
Cloud Nativeな取り組みの基盤
Kubernetesが人気なイメージ（？）
AWSだとEKSが使えるのに、ECS選んだの？？

View Slide

5
今回のお話の舞台　
● B to B サービス
● 人のアクセスは主にビジネスタイム
● Salesforceから定期にAPIアクセス
あり

View Slide

6
EC2環境での課題概要　
EC2 
固定的なリソース制御サービス拡張・コンテナ増加つらい
x  = 

View Slide

7
課題１と２　
課題１
JenkinsパイプラインでB/Gデプロイなどを自作
aws-cliコマンドやその他コマンド類が色々と複雑化してメンテが辛い
課題２
デプロイが固定的なEC2リソース指定で動いている
サーバ変更・追加はスクリプトを随時変更しなくてはならず辛い

View Slide

8
課題３と４　
課題３
密結合でmutableなリソースの使い方をしているので、連携待ち
が発生してデプロイが遅い
課題４
サービスが成長してきて複数アプリケーション間の問題が特定
しづらい

View Slide

9
解決したいことはシンプル　
1. デプロイ設定をシンプルにしたい
2. 変化に対応しやすいリソース制御を可能にしたい
3. 疎な関係で早くデプロイできるようにしたい
4. コンテナ間の通信状態のモニタができるようにしたい

View Slide

10
EKS、ECSと選択肢があった話1　
CodeDeploy
CodePipeline
デファクトスタンダード
エコシステムが豊富・色々できる
シンプルな機能
マネージドシステムで管理が楽

View Slide

11
EKS、ECSと選択肢があった話2　
サービス構成はシンプル、解決したい事もシンプルな要件
結果、ECSの方が今回のシンプルな利用にマッチしていた
CodeDeploy
CodePipeline
採用
チーム課題を最短で解決して、
サービスの価値をユーザに届けたい！
+

View Slide

12
これもまたCloud Native　
1. 回復性 -> ECS Fargateは自動で複数AZへ分散起動・障害時に自動復帰する
2. 管理力 -> ECSは簡単に必要実行数を設定可能・immutableなコンテナ実行環境
3. 可観測性 -> Datadogでアプリケーションモニタリング・ログ分析を実施
4. 疎結合システム -> ALBでコンテナ間を疎結合に通信・1task1アプリ実行
5. 堅牢な自動化 -> CodePipeline/Deployを組み合わせたシンプルなデプロイ
Cloud Nativeの技術で実現すること
回復性、管理力、および可観測性のある疎結合システム
堅牢な自動化
＊「CNCF Cloud Native Deﬁnition v1.0」から抜粋
https://github.com/cncf/toc/blob/main/DEFINITION.md#日本語版

View Slide

13
課題はどうなったの？　
色々と解決しました！！

View Slide

14
デプロイ設定をシンプルにしたい
マネージドサービス
+
自作スクリプトの必要ない世界
＋
シンプルな使い方をする
=
人が気にするところが少ない（楽）

View Slide

15
変化に対応しやすいリソース制御を可能にしたい　
タスク定義のCPUとMemory値を
調整してデプロイすれば数分で
変更可能
コンテナの実行数はWebコン
ソールからも手軽に変更可能

View Slide

16
疎な関係で早くデプロイできるようにしたい　
密結合な旧環境ではデプロイに２０分ほど要していたが...
疎結合にした新環境では3分で完了する

View Slide

17
コンテナ間通信のモニタリングができるようにしたい　
DatadogのAPM Traceで、コンテナ間や各種システム間
(DB,Redis等)の通信がモニタリングできるように

View Slide

18
（補足）費用はどうなの？　
＊EC2 m5.xlarge相当オンデマンド / Tokyo Region / 4 vCPU / 16GB Mem / 20GB Storage ざっくり比較
単純なEC2とFargateの費用比較
EC2 < Fargate（$180.48 < $209.32）
Datadog(Infrastructure + APM)を含めた、EC2とFargateの費用比較
EC2 > Fargate（$226.48 > $212.32）
＊DatadogをFargateで動かす時のイニシャル費用が安い
（Fargate 1taskあたり Infrastructure $1/mo、APM $2/moとか。EC2だとそれぞれ $15/mo 、$31/mo）
トータルとして大きく膨らむ事はない費用感で使えている

View Slide

19
ECSで全て順調？？　
色々と問題あったよ！！

View Slide

20
トラブル事例1　CPUパラメーターが未設定で起動エラー
タスク定義のcontainerDefinitionsでcpuパラメーター(オプション扱い)が未設定だと起動エラー
＊1CPUより大きいリソースを期待する仕様の一部アプリで発生
＊ECS タスク定義ドキュメント
> Null、0、1 の CPU 値は Docker に 2 個の CPU 配分として渡されます。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/task_definition_parameters.html
{
"family": "front-api-task",
"cpu": "2048",
"memory": "12288",
"containerDefinitions": [
{
"name": "front-api",
"cpu": 0,
"cpu": 2048,
全体には十分なリソースがあるのに
起動エラーになるのは何故？
🤔 とハマってしまった
未設定で定義を登録すると「“cpu”: 0」として
登録される（この暗黙的な設定が敗因）
明示的に設定しないと制限に引っ張られてエラーになる
（内部的に「“cpu”: 0」は「“cpu”: 2」として扱わる）

View Slide

21
トラブル事例2　Fargate Platform Versionとサポートの循環にハマる
Fargate PV 1.4.0
Datadogモニタリングで一部のデータ関
連付けが抜ける問題が発生
AWS Support
PV 1.4はメトリクスの提供に問
題あり。AWS側の修正待ち。
PV 1.3を使って下さい。
PV 1.4で修正されています。
Fargate PV 1.3.0
ECS基盤が不安定な時にコンテナが停止す
ると検知しない問題が発生
Datadog Support
＊AWSの修正がされた後、Datadog側にも修正があり現在は解決  
https://github.com/DataDog/dd-trace-java/pull/2432  

View Slide

22
トラブル事例3　サイドカーが巻き込み事故を起こす
一定の負荷が掛かると「failed container health checks」エラーが頻発
サイドカーのDatadog Agentコンテナのヘルスチェックコマンドが失敗して停止
起動必須にしているためメインのアプリコンテナを巻き込んで再起動が発生
＊以下の変更前後で発生
Fargate PV 1.3.0 + Datadog Agent 7.24.0 から
Fargate PV 1.4.0 + Datadog Agent 7.26.0 へ
サイドカーのリソースきちんと見るの重要
＊DatadogドキュメントのECS Fargate定義例
"name": "datadog-agent",
"cpu": 10,
"memoryReservation": 256,
"essential": true,
"healthCheck": {
"command": [
"CMD-SHELL",
"agent health"
],
"interval": 30,
"retries": 3,
"startPeriod": 15,
"timeout": 5
},
Datadog Agentコンテナのリソース不足により
ヘルスチェックが時々失敗する状況が発生

View Slide

23
トラブル事例4　ヘルスチェックエラーを調査したい...
事例3の調査時「healthCheck」でどんなエラー出力しているか
残せれば原因特定が楽になるのだけど。。。
AWS Support
ヘルスチェックに設定したコマンドの結
果を出力する仕組みはございません
他の人たもエラー調査に困っているみたいで、リクエスト出されている
> [FARGATE] [request]: Print Container Healthchecks for Fargate #1114
https://github.com/aws/containers-roadmap/issues/1114

View Slide

24
ECSでの色々から感じること　
AWSに囲われている感は大いにある
不具合があった時に解決まで不透明でモヤモヤ
サイドカー（Datadogなど）が重要な役割を担うようになっている
結果として、一番トラブル引き当てているのがサイドカー絡み
GitHubにAWSコンテナサービス関連の機能とか不具合の情報が集まっている
ので、issueとかカンバンを眺めてみると理解が進む
https://github.com/aws/containers-roadmap
AWSのブログでドキュメントより深掘された記事が投稿されているので、眺め
てみると理解が進む
https://aws.amazon.com/blogs/containers/

View Slide

25
まとめ　
・ECS Fargateで楽になったの？
楽になった！（状況にマッチしているから）
次に行けばいい！（状況にマッチしなくなったら）
常に最適な環境を追い求める（王道）
・Cloud Nativeの取り組みって？
Cloud Nativeの定義に沿って課題を整理・検討してみる
「インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行
う」方法を考える（王道）

View Slide

26
We're Hiring！
最後に少しだけ

View Slide

27
ユーザベースはインフラからアプリケーション開発まで、様々なスキルを持ったエンジニア
たちが個々の強みを活かし、常に新しい技術に挑戦し信頼性を高める活動をしています。
SREチームでは様々な自社プロダクトを支える基盤の構築や運用を行ったり、パフォーマン
スや信頼性、スケーラビリティを高めるエンジニアを募集しています。
あなたが興味のある分野で、技術を駆使して共に最高のプロダクトを作りませんか？
＊興味がありましたら、よろしくお願いします
https://www.uzabase.com/jp/careers/
on-premise

View Slide

楽になりたくてECS Fargate〜Cloud NativeとECS利用の現場〜

楽になりたくてECS Fargate〜Cloud NativeとECS利用の現場〜

yuta sakai

Other Decks in Technology

Featured

Transcript