Amazon ECS で作るスケーラブルなセルフホストランナー / GitHub Actions Meetup Tokyo #4

https://gaugt.connpass.com/event/324715/

Transcript

1. © DeNA Co., Ltd. 1 Amazon ECS で作るスケーラブルな セルフホストランナー 幸田優哉 IT 本部品質管理部 SWET 第二グループ 株式会社ディー・エヌ・エー
2. © DeNA Co., Ltd. 2 Yuya Koda ・インフラが得意なエンジニア ・お仕事は全社向けに提供している GitHub Actions self-hosted runner をいい感じにすること ・お酒と海鮮料理が大好き。最近は立ち飲み屋さんを 巡るのがマイブーム IT 本部品質管理部 SWET 第二グループ ponkio_o © DeNA Co., Ltd. 自己紹介 koday.me
3. © DeNA Co., Ltd. 3 セルフホストランナーについて
4. © DeNA Co., Ltd. 4 1 セルフホストランナーについて • セルフホストランナーは GitHub Actions の Job を自前のインフラ上で実行する ための仕組み ◦ actions/runner というリポジトリで公開されている • DeNA では GitHub Enterprise Server (GHES) を利用している都合、マネージド なランナーを使うことができず、自前で構築する必要がある ◦ runs-on: ubuntu-latest できない ◦ その他セキュリティ的な理由でセルフホストランナーが必要なケースもある
5. © DeNA Co., Ltd. 5 システム全体像
6. © DeNA Co., Ltd. 6 1 全体像
7. © DeNA Co., Ltd. 7 概要 2 • 2023年の11月頃に全社提供を開始 • GitHub Enterprise Server 全体で共有可能な Enterprise Runner を利用 • ランナーは ECS (on EC2) で ECS タスクとして起動し1Job につき1タスクを利用する • 現在 OS は Linux のみで small, medium, large, xlarge の4つのスペックと arm64, amd64 の2つの CPU アーキテクチャを提供している
8. © DeNA Co., Ltd. 8 ランナーのオートスケール
9. © DeNA Co., Ltd. 9 1 ランナーの台数を最適化するのは難しい 「すぐに利用できるランナーを必要最低限の台数だけ動かしたい」が… • Job のリクエストが無ければ無駄になるので、待機させるランナー最低限にしたい • 一方リクエストごとに都度ランナーを立ち上げると、ランナーが利用できるまでに時間 がかかる (コンテナの起動時間 + GitHub への登録) ◦ 最短でも30秒程度かかるため Job を実行する度に待たされることになる ▪ 毎回必ず待たされるのは結構ストレス
10. © DeNA Co., Ltd. 10 2 全社用ランナーのオートスケール DeNA では以下2種類のスケーリング戦略を併用している • 時間ベースのスケールイン・アウト ◦ ECS Service + Application Auto Scaling で業務時間帯だけ一定台数のランナー を常駐させている • リクエストベースのスケールアウト ◦ Job リクエストの Webhook を起点にし、そのタイミングで空いているランナー が存在しない場合には新しく ECS タスクを立ち上げる ▪ 常駐ランナーも存在するので空きランナーが存在する場合には何もしない
11. © DeNA Co., Ltd. 11 3 時間ベースのスケールイン・アウト • 平日の営業時間帯は一定台数を常時稼働させることで待ち時間を減らしている ◦ 比較的軽い Job に使われるサイズのランナーは多めに確保 ▪ ランナー起動時間 ＞ Job 時間 になると「遅い」と感じる (気がする) ため ◦ xlarge などは数台のみ確保して、大半はリクエストが来たら都度立ち上げる • Application Auto Scaling の Scheduled Scaling を利用している • 土日や夜間帯は Job 開始までの待ち時間 (Provisioning Time) をあまり気にする必要が ないので、常時稼働させるランナーは0にしている ◦ 言い換えると土日の待ち時間は長くなるが、人間が Job の開始を待っていることが ほとんどないため問題になっていない
12. © DeNA Co., Ltd. 12 4 リクエストベースのスケールアウト ランナーの空き状況を確認して、空きランナーがなければ新しいランナーを立ち上げるための runner-controller というものを作っている。Go 製で2つのコンポーネントから成り立つ • runner-controller-webhook ◦ Webhook の情報を SQS に追加する Lambda • runner-controller-manager ◦ SQS のワーカーとなる Lambda
13. © DeNA Co., Ltd. 13 5 runner-controller のアーキテクチャ Lambda (Golang) + SQS で構成される ecs:RunTask を呼び出すだけのシンプルなもの • Webhook にある labels の情報をもとにして、必要なサイズのランナーを立ち上げる • controller-manager の設定は YAML 形式で記述し AWS AppConfig にデプロイしている runner-controller のシステム構成
14. © DeNA Co., Ltd. 14 ECS クラスタのスケールアウト
15. © DeNA Co., Ltd. 15 1 ECS クラスタのオートスケール • ランナー (ECS タスク) のスケールアウトは解決したがタスクを動かすためのクラスタ のスケールアウトも考慮する必要がある ◦ ECS では Capacity Provider (CP) と呼ばれる仕組みを使うと ECS タスクの需要 に合わせて ASG をよしなに操作してくれる ◦ さらにスケールイン時は ECS タスクを考慮して drain してくれる • キャパシティは 100％ 使い切りたいので、余っていたらスケールインして欲しいし、逆 に足りない場合はすぐにスケールアウトしてほしい
16. © DeNA Co., Ltd. 16 2 Capacity Provider によるクラスタのスケールアウト 残念なことに Capacity Provider による ASG のスケールアウトがそこそこ遅い😭 ASG のスケールアウトがトリガーされるまでに数分かかって、ここから初期化処理なども 加わって最終的に ECS インスタンスとして利用できるまでに5分以上かかることも… aws/container-roadmap のリクエスト
17. © DeNA Co., Ltd. 17 3 Capacity Provider によるクラスタのスケールアウト高速化 Capacity Provider はマネージドな CloudWatch Alarm をベースに動いており、設定を変更 することができないため、しきい値や送信するデータの粒度が変えられない Capacity Provider 作成時に作られる CloudWatch Alarm と DO NOT EDIT OR DELETE の文字
18. © DeNA Co., Ltd. 18 4 独自の Cluster Autoscaler によるスケールアウト Capacity Provider のスケールアウト速度を上げるのは現状難しいので、クラスタをスケール アウトさせるための Cluster Autoscaler を作って動かすことにした (まだ試験稼働中) • Provisioning 状態のタスクがあれば タスクの CP に紐づく ASG をスケールアウトさせる • 一度にスケールアウトさせる EC2 の台数は ECS タスクに付与するタグで制御する • スケールインは担わず、スケールアウトだけを行う ◦ スケールインは考慮事項が増えるのと Capacity Provider で満足しているため ◦ 方針としては「雑にスケールアウトさせて、スケールインは CP に任せる」 ▪ 最近の Capacity Provider はスケールインが早くて優秀 • Faster Scaling-in for Amazon ECS Cluster Auto Scaling - AWS Blog
19. © DeNA Co., Ltd. 19 課題と今後の展望
20. © DeNA Co., Ltd. 20 1 課題と今後の展望 • インスタンスのコンテナイメージキャッシュの暖機をいい感じにしたい ◦ 現在は EC2 ユーザデータで docker pull しているがイメージ肥大化に伴い 初期化処理が長くなっている ◦ 事前に AMI に焼けばおそらく解決できるが運用自動化までを考えると大変 • さらなる起動の高速化と常駐ランナーの台数最適化 ◦ ランナーが利用可能になるまで時間がかかっている時間帯があるのでなるべく 無くしていきたい ◦ 常駐ランナーの台数最適化は Provisioning 時間を SLO 的に利用できないか？
21. © DeNA Co., Ltd. 21