Copilot-cli(Fargate)で Railsアプリを運用するためのあれこれ SonicGarden 安達輝雄

日本上陸前の2007年頃？からAWS使ってます

SonicGardenメンバーが執筆（2023年5月、6月発刊） 2023/06/10(土)発売！ https://amzn.to/43Hp96G

Copilot-cli を知っていますか？ ref: https://aws.github.io/copilot-cli/

Railsアプリケーションを運用する構成パターン（例） ECS / EC2 ECS / Fargate AppRunner EKS / EC2 EKS / Fargate ElasticBeanstalk / Docker copilot-cli の対応範囲

copilot-cliとは

なぜ copilot-cli を採用することを考えたのか 約100サイト 開発してユーザに早く価値を提供すること 構築・運用コストを抑えつつ、サービスの成長 に追従できる実行基盤が必要

どちらを選ぶ？ AppRunner ● 管理コストが小さい 👍 ● VPCに対応 👍 ● websocket非対応 😢 https://github.com/aws/apprunner-roadmap/issues/13 ● 30秒制限 😑 Currently AppRunner enforces a 30 second timeout on HTTP requests. If the timeout is hit, a HTTP 503 response is returned. https://github.com/aws/apprunner-roadmap/issues/104 ECS / Fargate ● 管理コストはAppRunnerより大きい 😑

application copilot-cli の 5つの概念 applications Service と Environment（後述）を包括する概念 copilot-cliで管理するプロジェクト名の設定 environments ステージング環境や本番環境など必要になる環境を指す概念 VPC,Subnet,AZ,SecurityGroupなどの設定 services AWS 上で実行したいコードとそれに必要なインフラストラクチャリソースを指す概念 サービスのタイプを選択（ appRunner,webサービス,apiサービス,workerサービス） pipelines Gitなどのリポジトリにコードの変更を PUSHしたら Service をデプロイするリリースパイプラインを指す概念 jobs バッチ処理などイベントによって起動される ECS タスクを指す概念 environment service service job pipeline

copilot-cliのコマンド $ copilot app init hogehoge --resource-tags project-name=hogehoge $ copilot env init --name production $ copilot env deploy --name production $ copilot svc init --name rails --svc-type "Load Balanced Web Service" $ copilot svc deploy --name rails --env production $ copilot pipeline init --name rails --pipeline-type 'Workloads' $ copilot pipeline deploy --app world --name rails-production $ copilot init 対話型で一括で設定を作成 OR 概念毎にコマンド実行 applications environments services pipelines

copilot-cliが生成する設定ファイル application environment service service job pipeline copilot-cli が概念毎にyamlの設定ファイルを生成（applicationsを除く） yamlの設定を元に cloudformation が裏側で動き システム構築やビルド・デプロイを実行 cloudformationのスタックも分離して管理されている

copilot-cli が生成するyaml設定ファイルのカスタマイズ例 サンプル、マニュアルも充実 https://aws.github.io/copilot-cli/ja/docs/manifest/lb-web-service/

構築

railsアプリのリポジトリに設定を組み込む copilot-cli の設定がyamlである恩恵をフル活用 ● 設定を自動生成するライブラリを自作 ○ アプリ毎に異なるものをparameterとして渡すだけ ● railsをECS/Fargateで動かす際の初期設定をgem化 ○ gemを読み込むだけで基本設定が概ね完了 ● すぐに ECS/Fargate 環境を構築可能 ○ 実質60分程度・・・？ copilot-cli の設定をアプリのGitリポジトリに追加 ● githubでのmergeをトリガーにリリース/構成変更が可能 $ bin/rails g ecs-fargate-generator --application_name ‘hogehoge’ \ --production_fqdn ‘www.sg.com’ \ --staging_fqdn ‘test.sg.com’

システム構成の全体像 ※注意 この構成がサクッと構築できる訳ではありません

copilot-cli で管理するリソースの範囲 点線赤枠以外をcopilot-cliで構築 ※WAFについてはサイト毎に必ず WebACLを 　構築する設計ではないため データストアをcopilot-cliで構築しないのか？

copilot-cli の storege や addon 機能を利用して追加リソースの作成 $ copilot storage コマンドで S3/DynamoDB/Aurora を構築することは可能 yaml定義でCloudFormationの処理を追加する addon で構築することも可能 なぜデータストアをcopilot-cliで管理してないのか？

copilot-cli で管理するリソースの範囲 理由） ● 誤操作でデータが消失しないように $ copilot app delete ● yaml定義ファイルを誤編集してpush サービスのダウンは許容できても データが消失するとサービス再開は不可 「復元が可能なのか？」を判断軸に S3 ユーザがアップしたファイルなど RDS さまざまなデータ ElastiCache ユーザ情報、一時ステータスなど ※キャッシュとしての利用の場合は復元可能 SecretManager クレデンシャル、暗号化キーなど ※復元可能な場合もあり 復元が難しいリソース

copilot-cliで管理しないリソースの構築方法 データストアの構築は社内ツールでワンクリックで可能 copilot-cli はタグをうまく利用するようになっている（赤枠） copilot-cliでproject-nameのようなタグを追加することも可能 構築したデータストアのリソースにはproject-nameのタグをつけておく CostExplorerで費用の内訳、タグによるリソース検索が用意に

SecretManager / Parameter Storeを利用する際の注意点 copilot-cliが生成するTaskExecutionRoleの一部 SecretManagerのシークレットにタグを つけておかないとGetSecretValueができない

運用

FargateでのCPUarm64（Graviton2） ref: https://aws.amazon.com/jp/blogs/news/announcing-aws-graviton2-support-for-aws-fargate-get-up-to-40-better-price-performance-for-your-serverless-containers/ 積極的に Graviton2 を利用しましょう

Fargateはmanagedなので制限がある ref: https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definitions Fargateではprivilegedがfalse → Swap領域は利用できない Taskのメモリにはゆとりを持たせること EventBridgeで「OutOfMemory」でのTask停止は検知できるようにするのが得策

Taskの異常終了検知 Taskのメモリにはゆとりを持たせるべき EventBridgeで「OutOfMemory」でのTask停止は検知できるようにするのが得策 1つの項目に対して複数の条件をつけることが難しいため Lambda側で吸収する

定期実行処理（バッチ処理） copilot-cliのschedule job ● cronの数だけcopilot用のmanifest.ymlを作成する必要 = buildが増える 😑 ● TimeZoneを指定できない問題（ UTC-0のみ）😢 ● サービスとjob(cron)を切り分けて実行可能 👍 EventBridge Rule ● 処理開始までに1分くらいのラグが発生（コンテナ起動が遅い） 😑 ● TimeZoneを指定できない問題（ UTC-0のみ）😢 ● EventBridgeは稀に1つのイベントに対して複数回トリガーされることがある模様 😑 ● サービスとjob(cron)を切り分けて実行可能 👍 ● ECSの管理画面でスケジュールを確認可能 👍 EventBridge Scheduler ● 処理開始までに1分くらいのラグが発生（コンテナ起動が遅い） 😑 ● TimeZoneを指定できる 👍 ● EventBridgeは稀に1つのイベントに対して複数回トリガーされることがある模様 😑 ● サービスとjob(cron)を切り分けて実行可能 👍 railsのgemのgood_job ● railsの非同期処理(ActiveJob)としても利用可能 👍 ● 処理開始のラグはほとんど発生しない 👍 ● アプリケーションと同じ TimeZoneを利用可能 👍 ● 管理画面も充実しておりステータス確認、再実行処理を管理画面から可能 👍 ● コンテナ内でgood_jobのプロセスを起動して処理するためメモリを食う処理はパフォチューが必要 😑 その他 SQS利用、ecschedule、etc.. バッチ処理を実現する方法は複数存在

good_job の採用（EventBridge Scheduler も状況に応じて利用） 基本的には good_job を利用する ● 運用の複雑性をなくしたい ● 状況把握など簡単に行えるようにしたい ● メモリを圧迫するような処理を実施しない ○ swap領域がないため EventBridge Scheduler を併用するシーンも発生 ● 実行に長時間かかるバッチ処理 ● メモリを圧迫するようなバッチ処理 ● 例） ○ 月次で実施する解約テナントの削除など

good_jobの管理画面

rails consoleができるように $ copilot svc exec で可能ではあるが権限が強くなり過ぎる問題 ● 誰もができるとコマンドを間違え環境を壊してしまう可能性 ● サービスに影響を与える可能性があるため、基本利用しない ● コンテナ内部の状況確認が必要な場合のみ利用（特権管理者に制限） One-Off Taskの仕組みを整備 ● Herokuのone-offと同じ仕組み、サービスとは別で専用のTaskを起動 ● 踏み台サーバからしか接続できないように制限 ● 開発・運用担当のみがアクセスできるように制限

踏み台サーバ copilot-cli のレールに乗ることで踏み台サーバの運用レスを目論みるも・・・ ● 初回の $ copilot srv deploy で docker build は必須 ● arm64に揃えるためには arm64 環境が必須 ● one-off Taskの仕組みを実現するためにも必要 ● $ copilot コマンドをエンジニアの開発環境から行えるのは高リスク 　　　　　現時点では copilot-cli を活用する上で踏み台サーバは必須と言わざるを得ない

まとめ ● copilot-cli の活用で構築コストを下げることができる ○ 複数のサービスを運用していると効果絶大 ● copilot-cliでのAWSリソースの対象範囲を決めておくことが大事 ● 今後に期待 ○ バッチ処理周りの仕組み ○ サービスの更新は RollingUpdate のみ ○ yamlでの設定、発展途上中のため痒いところに手が届かない ■ CloudFront のカスタマイズ ○ Fargate で privileged 条件緩和