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
940
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
370
Kubernetes だけじゃない!Amazon ECS で実現するクラウドネイティブな GitHub Actions セルフホストランナー / CNDW2024
ponkio_o
PRO
6
680
Renovate ではじめる運用レスなライブラリ更新 / 令和最新版 他人に自慢したいヤバいCI/CD LT会 @ yabaibuki.dev #2
ponkio_o
PRO
1
280
業務で使えるかもしれない…!?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
600
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
今日から始めるAWSセキュリティ対策 3ステップでわかる実践ガイド
yoshidatakeshi1994
0
120
Terraformで構築する セルフサービス型データプラットフォーム / terraform-self-service-data-platform
pei0804
1
200
AIエージェントで90秒の広告動画を制作!台本・音声・映像・編集をつなぐAWS最新アーキテクチャの実践
nasuvitz
3
360
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
450
「Linux」という言葉が指すもの
sat
PRO
4
140
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
320
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
oracle4engineer
PRO
4
10k
Rustから学ぶ 非同期処理の仕組み
skanehira
1
150
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
970
エンジニアリングマネージャーの成長の道筋とキャリア / Developers Summit 2025 KANSAI
daiksy
3
1.1k
AIがコード書きすぎ問題にはAIで立ち向かえ
jyoshise
1
210
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
2
1.2k
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
26
1.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Building Adaptive Systems
keathley
43
2.7k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
The Power of CSS Pseudo Elements
geoffreycrofte
77
6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
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