Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

interu (Teruo Adachi)

June 03, 2023
Tweet

Other Decks in Technology

Transcript

  1. Railsアプリケーションを運用する構成パターン(例) ECS / EC2 ECS / Fargate AppRunner EKS /

    EC2 EKS / Fargate ElasticBeanstalk / Docker copilot-cli の対応範囲
  2. どちらを選ぶ? 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より大きい 😑
  3. 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
  4. 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
  5. copilot-cliが生成する設定ファイル application environment service service job pipeline copilot-cli が概念毎にyamlの設定ファイルを生成(applicationsを除く) yamlの設定を元に

    cloudformation が裏側で動き システム構築やビルド・デプロイを実行 cloudformationのスタックも分離して管理されている
  6. 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’
  7. copilot-cli の storege や addon 機能を利用して追加リソースの作成 $ copilot storage コマンドで

    S3/DynamoDB/Aurora を構築することは可能 yaml定義でCloudFormationの処理を追加する addon で構築することも可能 なぜデータストアをcopilot-cliで管理してないのか?
  8. copilot-cli で管理するリソースの範囲 理由) • 誤操作でデータが消失しないように $ copilot app delete •

    yaml定義ファイルを誤編集してpush サービスのダウンは許容できても データが消失するとサービス再開は不可 「復元が可能なのか?」を判断軸に S3 ユーザがアップしたファイルなど RDS さまざまなデータ ElastiCache ユーザ情報、一時ステータスなど ※キャッシュとしての利用の場合は復元可能 SecretManager クレデンシャル、暗号化キーなど ※復元可能な場合もあり 復元が難しいリソース
  9. 定期実行処理(バッチ処理) 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.. バッチ処理を実現する方法は複数存在
  10. good_job の採用(EventBridge Scheduler も状況に応じて利用) 基本的には good_job を利用する • 運用の複雑性をなくしたい •

    状況把握など簡単に行えるようにしたい • メモリを圧迫するような処理を実施しない ◦ swap領域がないため EventBridge Scheduler を併用するシーンも発生 • 実行に長時間かかるバッチ処理 • メモリを圧迫するようなバッチ処理 • 例) ◦ 月次で実施する解約テナントの削除など
  11. rails consoleができるように $ copilot svc exec で可能ではあるが権限が強くなり過ぎる問題 • 誰もができるとコマンドを間違え環境を壊してしまう可能性 •

    サービスに影響を与える可能性があるため、基本利用しない • コンテナ内部の状況確認が必要な場合のみ利用(特権管理者に制限) One-Off Taskの仕組みを整備 • Herokuのone-offと同じ仕組み、サービスとは別で専用のTaskを起動 • 踏み台サーバからしか接続できないように制限 • 開発・運用担当のみがアクセスできるように制限
  12. 踏み台サーバ copilot-cli のレールに乗ることで踏み台サーバの運用レスを目論みるも・・・ • 初回の $ copilot srv deploy で

    docker build は必須 • arm64に揃えるためには arm64 環境が必須 • one-off Taskの仕組みを実現するためにも必要 • $ copilot コマンドをエンジニアの開発環境から行えるのは高リスク      現時点では copilot-cli を活用する上で踏み台サーバは必須と言わざるを得ない
  13. まとめ • copilot-cli の活用で構築コストを下げることができる ◦ 複数のサービスを運用していると効果絶大 • copilot-cliでのAWSリソースの対象範囲を決めておくことが大事 • 今後に期待

    ◦ バッチ処理周りの仕組み ◦ サービスの更新は RollingUpdate のみ ◦ yamlでの設定、発展途上中のため痒いところに手が届かない ▪ CloudFront のカスタマイズ ◦ Fargate で privileged 条件緩和