copilot-cli(Fargate)でRailsを運用するためのTips / JAWS-UG Okayama 2023

2023年6月3日 JAWS-UG Okayama 2023 - JAWS-UG 岡山支部 勉強会での登壇資料です。

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. copilot-cliとは
   

   View Slide

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

   View Slide

8. どちらを選ぶ？
   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より大きい 😑
   

   View Slide

9. 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
   

   View Slide

10. 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
    

    View Slide

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

    View Slide

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

    View Slide

13. 構築
    

    View Slide

14. 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’
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. 運用
    

    View Slide

22. 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 を利用しましょう
    

    View Slide

23. 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停止は検知できるようにするのが得策
    

    View Slide

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

    View Slide

25. 定期実行処理（バッチ処理）
    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..
    バッチ処理を実現する方法は複数存在
    

    View Slide

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

    View Slide

27. good_jobの管理画面
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide