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
770
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
540
Renovate ではじめる運用レスなライブラリ更新 / 令和最新版 他人に自慢したいヤバいCI/CD LT会 @ yabaibuki.dev #2
ponkio_o
PRO
1
230
業務で使えるかもしれない…!?GitHub Actions の Tips 集 / CI/CD Test Night #7
ponkio_o
PRO
43
18k
aqua で始める CI-Friendly なツール管理
ponkio_o
PRO
3
1.1k
set-terraform-matrix という Actions を作った / set-terraform-matrix-actions
ponkio_o
PRO
0
510
NGINX Ingress Controller を活用した Retty のサービス開発とモニタリング / NGINX ユーザー会 2022 春
ponkio_o
PRO
0
200
Retty における Signal Sciences の導入事例 / Fastly Yamagoya 2021
ponkio_o
PRO
0
4.4k
Amazon EKS を活用した個人開発環境の整備と自動化への取り組み / CNDT2021
ponkio_o
PRO
0
520
Terraform における秘匿情報管理 / Credentials management in Terraform
ponkio_o
PRO
0
370
Other Decks in Technology
See All in Technology
30分でわかる『アジャイルデータモデリング』
hanon52_
9
2.6k
Datadog APM におけるトレース収集の流れ及び Retention Filters のはなし / datadog-apm-trace-retention-filters
k6s4i53rx
0
330
2/18/25: Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
0
110
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
3
1.2k
マルチモーダル理解と生成の統合 DeepSeek Janus, etc... / Multimodal Understanding and Generation Integration
hiroga
0
380
MC906491 を見据えた Microsoft Entra Connect アップグレード対応
tamaiyutaro
1
530
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
950
AndroidXR 開発ツールごとの できることできないこと
donabe3
0
130
Building Products in the LLM Era
ymatsuwitter
10
5.3k
Culture Deck
optfit
0
410
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
150
Featured
See All Featured
Navigating Team Friction
lara
183
15k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
What's in a price? How to price your products and services
michaelherold
244
12k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Scaling GitHub
holman
459
140k
Building Adaptive Systems
keathley
40
2.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Documentation Writing (for coders)
carmenintech
67
4.6k
Building Your Own Lightsaber
phodgson
104
6.2k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Automating Front-end Workflow
addyosmani
1368
200k
YesSQL, Process and Tooling at Scale
rocio
172
14k
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