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
970
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
KubeCon + CloudNativeCon Japan 2025 Recap by CA
ponkio_o
PRO
0
380
Kubernetes だけじゃない!Amazon ECS で実現するクラウドネイティブな GitHub Actions セルフホストランナー / CNDW2024
ponkio_o
PRO
6
690
Renovate ではじめる運用レスなライブラリ更新 / 令和最新版 他人に自慢したいヤバいCI/CD LT会 @ yabaibuki.dev #2
ponkio_o
PRO
1
290
業務で使えるかもしれない…!?GitHub Actions の Tips 集 / CI/CD Test Night #7
ponkio_o
PRO
42
20k
aqua で始める CI-Friendly なツール管理
ponkio_o
PRO
3
1.3k
set-terraform-matrix という Actions を作った / set-terraform-matrix-actions
ponkio_o
PRO
0
610
NGINX Ingress Controller を活用した Retty のサービス開発とモニタリング / NGINX ユーザー会 2022 春
ponkio_o
PRO
0
240
Retty における Signal Sciences の導入事例 / Fastly Yamagoya 2021
ponkio_o
PRO
0
4.7k
Amazon EKS を活用した個人開発環境の整備と自動化への取り組み / CNDT2021
ponkio_o
PRO
0
570
Other Decks in Technology
See All in Technology
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
180
自動テストのコストと向き合ってみた
qa
0
160
いま注目しているデータエンジニアリングの論点
ikkimiyazaki
0
590
ZOZOのAI活用実践〜社内基盤からサービス応用まで〜
zozotech
PRO
0
170
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
250
VCC 2025 Write-up
bata_24
0
180
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9k
非エンジニアのあなたもできる&もうやってる!コンテキストエンジニアリング
findy_eventslides
3
910
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
900
英語は話せません!それでも海外チームと信頼関係を作るため、対話を重ねた2ヶ月間のまなび
niioka_97
0
120
多野優介
tanoyusuke
1
440
BirdCLEF+2025 Noir 5位解法紹介
myso
0
200
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
How to Ace a Technical Interview
jacobian
280
24k
Being A Developer After 40
akosma
91
590k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
Fireside Chat
paigeccino
40
3.7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Writing Fast Ruby
sferik
629
62k
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