[レポート] JAWS-UG コンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念！ にオンラインで参加しました #jawsug_ct
2020-06-24オンラインで開催された「JAWS-UG コンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念！」のレポ (メモ) です。私のコンテナに対するレベル感は、 最近少しずつ Docker 触り始めてコンテナ系の情報も追っているもののよくわからん という状態です。よくわからんなりにも話を聴いてみようということで参加しました。
ちなみにコンテナ支部のイベントは初参加でした。
目次
タイムテーブル
| 時間 | 内容 | 登壇者 (敬称略) |
|---|---|---|
| 17:55 - 19:00 | Black Belt Webinar “AWS コンテナサービスアップデート” の裏つぶやき | コンテナ支部運営のみなさん |
| 19:00 - 19:10 | 休憩 | — |
| 19:10 - 19:15 | 支部案内など | コンテナ支部運営 |
| 19:15 - 19:40 | コンテナとコンテナのつなぎかた on ECS | Masatoshi Hayashi / AWSJ |
| 19:40 - 20:05 | 金融系サービスでECS/Fargateを設計するということ | Masaya ARAI |
| 20:05 - 20:15 | 休憩 | — |
| 20:15 - 20:40 | FargateでService、Cron、RunTask基盤を運用する | Shohei Koyama |
| 20:40 - 21:05 | ホスティングサービスのインフラ環境を再構築！〜AWS Fargateのおかげで幸せになれた話〜 | Takayuki Yoshioka |
| 21:05 - 21:10 | 締めのご挨拶 | コンテナ支部運営 |
※ Black Belt Webinar “AWS コンテナサービスアップデート” の裏つぶやき については配信ではなく、 Twitter 上でたくさんツイートされていました。 #jawsug_ct
セッション
各セッションの聴講メモです。発表資料も、公開されているものに関しては随時追加していきます。
コンテナとコンテナのつなぎかた on ECS
- 三種類のコンテナ連携方法
- タスク内接続
- サービス関連系
- イベント駆動連携
- 時間経過、コンテナが発行したイベントなど
タスク内コンテナ接続
- サイドカー、アンバサダー、アダプターとか呼ばれる
- ユースケース
- ログ関連機能をサイドカーにする
- ドメインと関係のないログのルーティング処理をアプリコンテナの外に出す
- ログ関連機能をサイドカーにする
サービス間接続
-
マイクロサービスの必要性とは
- 高度なモジュール化という選択肢
- あえてサービスに分けるのは、インテグレーション時に問題が発生してくるタイミング (調整に時間がかかる)
- 一つのライブラリを更新したら壊れた
- Fargate に移行したい
-
サービス間の接続とは、インテグレーション問題の解決
-
接続のあまり良くないパターン
- コンテナ内部の実装に暗黙的に依存
- DB スキーマの共有など
- これはインテグレーションの範囲が絞れていない、サービス間接続のモチベーションを満たさない
- コンテナ内部の実装に暗黙的に依存
-
一般的なサービス間の接続
- ドキュメント化された API で接続
- サービス内の実装に依存しない
- どこでコンテナが動いているかを管理するためにサービスディスカバリ
-
ECS Service Discovery
- サービス同士を API でつなぐ
- ヘルスチェックが通ったらサービス登録
- Cloud Map にサービス IP 登録 -> Route 53 に DNS レコード登録
-
独立性の高いサービス同士を統一した方法でつなぎたい
- いろんな状況 (EC2, EKS, ECS, Python, Go, Java…)
- サービスメッシュ (App Mesh) で解決する
-
App Mesh
- サービス間通信の標準化
- サービスが独立しても接続しやすい
-
同期的なつなぎ方ばかりしていると、一つのサービスに負担が集中する
- サービス間に Event Bus を挟む
イベント駆動連携
-
EventBridge & SQS
- マネージドな Event Bus
- スキーマを定義してコードを生成、サービス接続しやすい
- SQS と連携することで、ピークが読めないワークロードに対応
-
SNS & SQS
- スキーマの定義などはできないが、シンプルに高スループットな連携が可能
-
Kinesis Data Stream
- イベントのリプレイがしやすい
-
依存関係が課題になりやすい
- どのキューがどのサービスで、どういう目的で
- タイムアウトの整合性
- エラー時にどうなるか
- サービス間の処理の流れが明示的でないのでわかりにくい
- サービスを追加するときに、他のサービスへの影響が発生
- Step Functions で依存関係を整理
- 依存関係の管理を Step Functions に移譲することで各サービスの独立性が高まる
- あるステップを他の実装に差し替えるということがやりやすい
まとめ
- なるべくシンプルに
- 必要に応じて様々なパターンを検討
- サービスの独立性を保つことを意識する
質疑
- Cloud Map だけでは要件が達成できない場合に App Mesh を使う
- Blue/Green デプロイ
金融系サービスでECS/Fargateを設計するということ
金融サービスでの ECS/Fargate を利用した事例と設計ポイント
金融サービスの変化
-
安定性 x セキュリティ x ガバナンス
- 社会インフラ
- 対サイバー攻撃
- 伝統的な統制ルール, FISC
-
法改正や FinTech 企業の登場による金融サービスの拡張が進んでいる
ECS/Fargate という選択
- FinTech 領域ではユーザファーストな対応が必要
- ユーザ価値の向上にリソースを集中
- 頻繁な改良 (変更) をしたい
- 運用保守作業をなるべく減らしたい
- 品質を維持したい
- -> コンテナによる解決
- データプレーンとして EC2, Fargate の選択肢
- コントロールプレーンとして ECS, EKS の選択肢
- EC2 だと運用負荷が大きい -> Fargate
- Fargate は価格改定や Savings Plans によって料金もおさえられる
設計に必要な視点の整理
- 何を拠り所にして設計をすればよいか
- 安定性 x セキュリティ x ガバナンス については Fargate でも意識的に満たさないといけない
- FISC 安全対策基準への遵守
- Well-Architected Framework
- 特定のワークロードに特化した W-A Lens
- 金融に特化した Lens を FISC に次ぐ 2 つめのベースラインとして設計
ECS/Fargate 設計の要所
- FISC の安全対策基準
- W-A FSI Lens
- ネットワーク
- トラフィックを可能な限りプライベートに保つ
- ECR, S3, CloudWatch には VPC エンドポイントでアクセス
- トラフィックを可能な限りプライベートに保つ
- アプリケーション
- クレデンシャル情報の保護
- Secret Manager, パラメータストアのシークレットに保存
- タスク定義内で環境変数に
- クレデンシャル情報の保護
- コンテナイメージ、タスク定義の書き方
- ベースイメージはどこから？テスト済み？
- 必要最低限のパッケージのみのコンテナを作成
- CI/CD パイプラインの整備
- 脆弱性スキャンの有効可
- ベースイメージはどこから？テスト済み？
- データの保存場所
- CI/CD で使う中間ファイルをもつ S3 へのアクセス制御
まとめ
- ECS/Fargate を安全に金融サービスで扱うための設計
- FISC, W-A FSI Lens
質疑
- VPC エンドポイントに対応してないサービスの辛さ
- 現状は特にない。ECR も最近対応して、 ECS まわりはほぼほぼ閉じたネットワークで動かせるようになった
FargateでService、Cron、RunTask基盤を運用する
- ECS, Fargate で十分
- Service : サーバー
- RunTask : 任意のタイミングで実行。ワンショット
- Cron : 定期実行
- Fargate のタスク開始方法
- Service
- RunTask
- Cron は EventBrige から Fargate の RunTask API
- Terraform
- 基盤の共通化
- シンプルな設計
- スケーラブル
- スパイクを予想している場合はオートスケールの値を
- アーキテクチャ図は draw.io で作成 (
.draw.io,.pngを Git 管理) - Terraform module で共通化
- 変化が多いところは別ソリューションを考える
- 新規サービスを追加する際でも Dockerfile があれば小一時間で作れる
- ecs-deploy という内製ツール (Go)
- Slack でデプロイ
- メンテナンスの ON/OFF も Slack で
- ログ
- リアルタイムは Datadog, 長期保存 (監査用) は S3
- モニタリング
- ecs-update-notify (Go)
- タスクが切り替わったとき、切り替わらなかったときに通知
- sioncojp/ecs-update-notify | GitHub
- Fargate になったからと言って簡単になるわけではない。センスが必要
ホスティングサービスのインフラ環境を再構築！〜AWS Fargateのおかげで幸せになれた話〜
- インフラ環境の再構築
構築
- RedMica : Redmine の次期バージョンの新機能を先行して利用可能
- Before
- EC2 メイン
- After
- メインの Web サーバを Fargate on ECS
- 踏み台サーバ (EC2)
- 設定ファイルは S3 に保持
- 再構築のポイント
- データの永続化
- DB, ログ, 添付ファイル
- S3 と EFS が候補
- S3 はアプリの変更が必要、 EFS は変更不要
- ランニングコストは S3 のほうが安い
- そもそも開発当時は Fargate の EFS 連携ができなかった (最近のアップデートで連携可能に)
- redmica/redmica_s3: Uses Amazon S3 for storing attachments | GitHub
- データの永続化
- ユーザごとに ECS Service 起動
- コストメリットがない
- ユーザごとにタスク定義するのが煩雑
- -> 却下
- Apartment (Gem) の利用
- メンテナンス問題
- migration 関連でつらそう
- -> 却下
- Apache + Passenger
- プロセスごとにポート切り替え
- Apache の設定情報は S3 に保存
- なぜ ECS ?
- 当時 EKS が東京リージョンになかった
- クラスターの料金が高かった
- なぜ Fargata ?
- EC2 の管理が面倒、リソースの計算も面倒
- 管理コストが低い
- EC2 と比較してランニングコストが高い、サーバに入れない
- サーバに入れないことは、調査範囲を限定できるという意味ではメリット
- ECS になれるまでは EC2 タイプも立てておく
運用
- CodePipeline
- GitLab から CodeCommit にミラーリング
- CodeBuild (build)
- CodeBuild (test)
- Dockerfile
- ENTORYPOINT に DB 設定系のコマンドを仕込んでおく
- Step Functions
- サービスアカウントの新規登録
- サービスアカウントの変更
- サービス停止、データ削除
- Migration 問題
rails db:migrateをどうやって実行するか- 当初はパイプラインに migration フローを入れていた
- S3 からサイトごとの設定情報を取得、Step Functions の並列処理でサイトの数だけ migration を実行
全体の感想
「JAWS-UG コンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念！」のレポ (メモ) でした。
冒頭に書いた通り、コンテナほんとになんもわからん状態でしたが、わからないなりに追っていた AWS におけるコンテナに関する情報が、なんとなく自分の中で少し繋がったかなという印象です。今回はコンテナ支部のイベントだったんですが、セッションの中で何度も Step Functions の話題が出てきていたので、重い腰を上げて使ってみたいなと思いました。
Fargate, ECS に関しては先日レビューを書いた「みんなの AWS」内でハンズオンをやったので、今回のイベントを受けてもう一度試してみるとなにか発見がありそうな気がしています。
あと印象的だったのが、金融系のサービスで Fargate を使う話です。 FISC と AWS Well-Architected Framework の FSI Lens に沿った設計をしていくことで、自ずと適切な設計・構成になっていくんだなと感じました。金融系は安全性・セキュリティ・ガバナンスに関して厳しい規定がありますが、その他の Web アプリケーションでも Well-Architected Framework に沿った設計をしていくことはとても大事だなと感じました。
オンライン開催だと全然わからない分野のイベントでも気軽に参加できるので良いなと思ってます。運営のみなさま、オンラインでの開催ありがとうございました！
その他の資料
connpass のイベントページにて登壇資料、動画、および参加レポートがまとめられています。
comments powered by Disqus