Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amazon ECS で作るスケーラブルなセルフホストランナー / GitHub Action...
Search
YuyaKoda
PRO
August 09, 2024
Technology
2
880
Amazon ECS で作るスケーラブルなセルフホストランナー / GitHub Actions Meetup Tokyo #4
Event
https://gaugt.connpass.com/event/324715/
Archive
https://youtu.be/OI27vWVcrDI?t=258
YuyaKoda
PRO
August 09, 2024
Tweet
Share
More Decks by YuyaKoda
See All by YuyaKoda
Kubernetes だけじゃない!Amazon ECS で実現するクラウドネイティブな GitHub Actions セルフホストランナー / CNDW2024
ponkio_o
PRO
6
640
Renovate ではじめる運用レスなライブラリ更新 / 令和最新版 他人に自慢したいヤバいCI/CD LT会 @ yabaibuki.dev #2
ponkio_o
PRO
1
260
業務で使えるかもしれない…!?GitHub Actions の Tips 集 / CI/CD Test Night #7
ponkio_o
PRO
42
20k
aqua で始める CI-Friendly なツール管理
ponkio_o
PRO
3
1.2k
set-terraform-matrix という Actions を作った / set-terraform-matrix-actions
ponkio_o
PRO
0
580
NGINX Ingress Controller を活用した Retty のサービス開発とモニタリング / NGINX ユーザー会 2022 春
ponkio_o
PRO
0
230
Retty における Signal Sciences の導入事例 / Fastly Yamagoya 2021
ponkio_o
PRO
0
4.6k
Amazon EKS を活用した個人開発環境の整備と自動化への取り組み / CNDT2021
ponkio_o
PRO
0
560
Terraform における秘匿情報管理 / Credentials management in Terraform
ponkio_o
PRO
0
400
Other Decks in Technology
See All in Technology
Understanding_Thread_Tuning_for_Inference_Servers_of_Deep_Models.pdf
lycorptech_jp
PRO
0
120
How Community Opened Global Doors
hiroramos4
PRO
1
120
GeminiとNotebookLMによる金融実務の業務革新
abenben
0
230
SalesforceArchitectGroupOsaka#20_CNX'25_Report
atomica7sei
0
170
解析の定理証明実践@Lean 4
dec9ue
0
180
OpenHands🤲にContributeしてみた
kotauchisunsun
1
440
セキュリティの民主化は何故必要なのか_AWS WAF 運用の 10 の苦悩から学ぶ
yoh
1
150
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
210
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
440
Welcome to the LLM Club
koic
0
170
Uniadex__公開版_20250617-AIxIoTビジネス共創ラボ_ツナガルチカラ_.pdf
iotcomjpadmin
0
160
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy
opelab
9
1.1k
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
The Cult of Friendly URLs
andyhume
79
6.5k
Site-Speed That Sticks
csswizardry
10
660
The Art of Programming - Codeland 2020
erikaheidi
54
13k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
A Tale of Four Properties
chriscoyier
160
23k
Transcript
© DeNA Co., Ltd. 1 Amazon ECS で作るスケーラブルな セルフホストランナー 幸田優哉
IT 本部品質管理部 SWET 第二グループ 株式会社ディー・エヌ・エー
© DeNA Co., Ltd. 2 Yuya Koda ・インフラが得意なエンジニア ・お仕事は全社向けに提供している GitHub
Actions self-hosted runner をいい感じにすること ・お酒と海鮮料理が大好き。最近は立ち飲み屋さんを 巡るのがマイブーム IT 本部品質管理部 SWET 第二グループ ponkio_o © DeNA Co., Ltd. 自己紹介 koday.me
© DeNA Co., Ltd. 3 セルフホストランナーについて
© DeNA Co., Ltd. 4 1 セルフホストランナーについて • セルフホストランナーは GitHub
Actions の Job を自前のインフラ上で実行する ための仕組み ◦ actions/runner というリポジトリで公開されている • DeNA では GitHub Enterprise Server (GHES) を利用している都合、マネージド なランナーを使うことができず、自前で構築する必要がある ◦ runs-on: ubuntu-latest できない ◦ その他セキュリティ的な理由でセルフホストランナーが必要なケースもある
© DeNA Co., Ltd. 5 システム全体像
© DeNA Co., Ltd. 6 1 全体像
© 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 アーキテクチャを提供している
© DeNA Co., Ltd. 8 ランナーのオートスケール
© DeNA Co., Ltd. 9 1 ランナーの台数を最適化するのは難しい 「すぐに利用できるランナーを必要最低限の台数だけ動かしたい」が… • Job
のリクエストが無ければ無駄になるので、待機させるランナー最低限にしたい • 一方リクエストごとに都度ランナーを立ち上げると、ランナーが利用できるまでに時間 がかかる (コンテナの起動時間 + GitHub への登録) ◦ 最短でも30秒程度かかるため Job を実行する度に待たされることになる ▪ 毎回必ず待たされるのは結構ストレス
© DeNA Co., Ltd. 10 2 全社用ランナーのオートスケール DeNA では以下2種類のスケーリング戦略を併用している •
時間ベースのスケールイン・アウト ◦ ECS Service + Application Auto Scaling で業務時間帯だけ一定台数のランナー を常駐させている • リクエストベースのスケールアウト ◦ Job リクエストの Webhook を起点にし、そのタイミングで空いているランナー が存在しない場合には新しく ECS タスクを立ち上げる ▪ 常駐ランナーも存在するので空きランナーが存在する場合には何もしない
© DeNA Co., Ltd. 11 3 時間ベースのスケールイン・アウト • 平日の営業時間帯は一定台数を常時稼働させることで待ち時間を減らしている ◦
比較的軽い Job に使われるサイズのランナーは多めに確保 ▪ ランナー起動時間 > Job 時間 になると「遅い」と感じる (気がする) ため ◦ xlarge などは数台のみ確保して、大半はリクエストが来たら都度立ち上げる • Application Auto Scaling の Scheduled Scaling を利用している • 土日や夜間帯は Job 開始までの待ち時間 (Provisioning Time) をあまり気にする必要が ないので、常時稼働させるランナーは0にしている ◦ 言い換えると土日の待ち時間は長くなるが、人間が Job の開始を待っていることが ほとんどないため問題になっていない
© DeNA Co., Ltd. 12 4 リクエストベースのスケールアウト ランナーの空き状況を確認して、空きランナーがなければ新しいランナーを立ち上げるための runner-controller というものを作っている。Go
製で2つのコンポーネントから成り立つ • runner-controller-webhook ◦ Webhook の情報を SQS に追加する Lambda • runner-controller-manager ◦ SQS のワーカーとなる Lambda
© DeNA Co., Ltd. 13 5 runner-controller のアーキテクチャ Lambda (Golang)
+ SQS で構成される ecs:RunTask を呼び出すだけのシンプルなもの • Webhook にある labels の情報をもとにして、必要なサイズのランナーを立ち上げる • controller-manager の設定は YAML 形式で記述し AWS AppConfig にデプロイしている runner-controller のシステム構成
© DeNA Co., Ltd. 14 ECS クラスタのスケールアウト
© DeNA Co., Ltd. 15 1 ECS クラスタのオートスケール • ランナー
(ECS タスク) のスケールアウトは解決したがタスクを動かすためのクラスタ のスケールアウトも考慮する必要がある ◦ ECS では Capacity Provider (CP) と呼ばれる仕組みを使うと ECS タスクの需要 に合わせて ASG をよしなに操作してくれる ◦ さらにスケールイン時は ECS タスクを考慮して drain してくれる • キャパシティは 100% 使い切りたいので、余っていたらスケールインして欲しいし、逆 に足りない場合はすぐにスケールアウトしてほしい
© DeNA Co., Ltd. 16 2 Capacity Provider によるクラスタのスケールアウト 残念なことに
Capacity Provider による ASG のスケールアウトがそこそこ遅い😭 ASG のスケールアウトがトリガーされるまでに数分かかって、ここから初期化処理なども 加わって最終的に ECS インスタンスとして利用できるまでに5分以上かかることも… aws/container-roadmap のリクエスト
© DeNA Co., Ltd. 17 3 Capacity Provider によるクラスタのスケールアウト高速化 Capacity
Provider はマネージドな CloudWatch Alarm をベースに動いており、設定を変更 することができないため、しきい値や送信するデータの粒度が変えられない Capacity Provider 作成時に作られる CloudWatch Alarm と DO NOT EDIT OR DELETE の文字
© 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
© DeNA Co., Ltd. 19 課題と今後の展望
© DeNA Co., Ltd. 20 1 課題と今後の展望 • インスタンスのコンテナイメージキャッシュの暖機をいい感じにしたい ◦
現在は EC2 ユーザデータで docker pull しているがイメージ肥大化に伴い 初期化処理が長くなっている ◦ 事前に AMI に焼けばおそらく解決できるが運用自動化までを考えると大変 • さらなる起動の高速化と常駐ランナーの台数最適化 ◦ ランナーが利用可能になるまで時間がかかっている時間帯があるのでなるべく 無くしていきたい ◦ 常駐ランナーの台数最適化は Provisioning 時間を SLO 的に利用できないか?
© DeNA Co., Ltd. 21