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
機械学習を扱うプラットフォーム開発と運用事例
lycorptech_jp
PRO
0
200
ここ一年のCCoEとしてのAWSコスト最適化を振り返る / CCoE AWS Cost Optimization devio2025
masahirokawahara
1
1.5k
Agile PBL at New Grads Trainings
kawaguti
PRO
1
310
生成AI時代のデータ基盤
shibuiwilliam
6
3.8k
今!ソフトウェアエンジニアがハードウェアに手を出すには
mackee
9
4.4k
Nstockの一人目エンジニアが 3年間かけて向き合ってきた セキュリティのこととこれから〜あれから半年〜
yo41sawada
0
210
まだ間に合う! StrandsとBedrock AgentCoreでAIエージェント構築に入門しよう
minorun365
PRO
11
1k
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
460
「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう
kawabeaver
0
220
「魔法少女まどか☆マギカ Magia Exedra」の必殺技演出を徹底解剖! -キャラクターの魅力を最大限にファンに届けるためのこだわり-
gree_tech
PRO
0
590
下手な強制、ダメ!絶対! 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは?
tsukaman
2
370
生成AI時代のデータ基盤設計〜ペースレイヤリングで実現する高速開発と持続性〜 / Levtech Meetup_Session_2
sansan_randd
1
140
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Unsuck your backbone
ammeep
671
58k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Being A Developer After 40
akosma
90
590k
How to train your dragon (web standard)
notwaldorf
96
6.2k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Become a Pro
speakerdeck
PRO
29
5.5k
Into the Great Unknown - MozCon
thekraken
40
2k
Fireside Chat
paigeccino
39
3.6k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
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