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
cocone Teck Talk Vol.2 -EC2を用いたGitLab Runnerのオー...
Search
cocone
August 17, 2021
Programming
0
1.2k
cocone Teck Talk Vol.2 -EC2を用いたGitLab Runnerのオートスケーリング化
オートスケーリング化の説明/手順/ハマり/効果についてお話します。
cocone
August 17, 2021
Tweet
Share
More Decks by cocone
See All by cocone
Cocone_Research_Center_2025.pdf
cocone
0
75
20240301_cocone_EMゆるミートアップvol6_LT資料
cocone
0
840
2024_cocone-avatarservice.pdf
cocone
0
2k
2024_cocone-wellbeing
cocone
0
4.7k
2023夏季合同企業説明会ココネ
cocone
0
340
cocone TECH TALK Vol.6 - リアルタイム対戦xバックエンドアーキテクチャ
cocone
0
580
cocone TECH TALK Vol.6 - ココネグループのブロックチェーン MOOI Network とのバックエンド連携
cocone
0
500
cocone TECH TALK Vol.6 - Kotlin バックエンドアーキテクチャ of アバターサービス
cocone
0
510
ココネ株式会社 会社紹介
cocone
0
130k
Other Decks in Programming
See All in Programming
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
510
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
180
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
290
RailsGirls IZUMO スポンサーLT
16bitidol
0
170
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
120
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
130
A2A プロトコルを試してみる
azukiazusa1
2
1.3k
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
2.3k
XP, Testing and ninja testing
m_seki
3
240
GraphRAGの仕組みまるわかり
tosuri13
8
530
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
1
15k
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
640
Featured
See All Featured
Side Projects
sachag
455
42k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
960
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Building an army of robots
kneath
306
45k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Site-Speed That Sticks
csswizardry
10
680
It's Worth the Effort
3n
185
28k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Code Reviewing Like a Champion
maltzj
524
40k
Transcript
EC2を用いた GitLab Runnerの オートスケーリング化 開発部 谷澤駿一
2 自己紹介 谷澤 駿一 Tanizawa Shunnichi 経歴: インフラ 約5年 (
Sier / 事業会社 / 現在) 業務内容: インフラの保守・運用 最近の出来事: 会社まで徒歩15分になりました
3 ココネのインフラ 運用 基盤 MW オンプレ 約300 Server Biblia
Billing等 多くの プロジェクト ポケコロ等
4 • GitLab CI/CD 目指す構成 • 導入背景 • 現状の確認
• 導入パターン • オートスケーリングの導入 • 性能評価 目次 (20分)
5 GitLab CI/CD 目指す構成 構成内容 gitlab-ci.yml:CI/CDの定義を記載 Config.toml:Runnerの設定を記載
6 GitLab CI/CD 目指す構成 gitlab-ci.yml ・CI/CDの定義を記載 ・ジョブ毎に処理を分けることが可能 ・Autoscalingではジョブ毎に
実行環境が割り当てられる ・便利なパラメータが多く存在 stages:実行順序 variables:変数 when : 手動実行を要求等
7 • GitLab CI/CD 目指す構成 • 導入背景と現状の確認 • 導入パターン
• オートスケーリングの導入 • 性能評価 目次
8 導入背景と現状の確認 きっかけ 開発側からの相談。 ・ジョブが同時に一つしか実行できない ・複数ジョブ/プロジェクトの同時実行で待ち時間が発生
9 導入背景と現状の確認 Runnerを登録した際に発行される サイトのURL Config.toml concurrent:ジョブの同時実行数 ジョブが同時に一つしか実行できない ➔ Runnerの設定によるものだった。
これで問題解決?
10 導入背景と現状の確認 スペックの増強が必要 現状のインスタンス t3.small (cpu: 2/memory: 2G)
ピーク ジョブの同時実行数: 1 cpu使用率: 約45% メモリ使用率: 約85%
11 • GitLab CI/CD 目指す構成 • 導入背景と現状の確認 • 導入パターン
• オートスケーリングの導入 • 性能評価 目次
12 導入パターン マシンスペックの 増強 対応案A オートスケーリングの実 装(GitLab公式) 対応案B
13 導入パターン マシンスペックの 増強 対応案A 良い点 ・対応や管理が簡単 懸念点 ・1台当たりのコストが増加
・利用していない時間帯のコスト ・複数プロジェクトの同時利用時の負荷
14 導入パターン これに見合うスペックは? 開発チームのジョブ実行結果を ざっくり観測 (1プロジェクト) e2eテストなので重め t3.small (cpu:
2/memory: 2G) 6台合わせて CPU使用率: 約176% メモリ使用率:概算 4-6G (瞬間的な負荷は別)
15 導入パターン CPU使用率: 約176% メモリ使用率:概算 4-6G インスタンスタイプ vCPU メモリ(GiB) 価格($)
/ 1h t3.small 2 2 0.0272(基準) t3.large 2 8 0.1088 (4倍) c5.large 2 4 0.107 (約3.9倍) m5.large 2 8 0.124 (約4.5倍) r5.large 2 16 0.152 (約5.6倍) c5.xlarge 4 8 0.214 (約7.8倍) m5.xlarge 4 16 0.248 (約9倍) (2021/07/02調べ) ・単純にコストだけを比較した場合、t3.smallの約7.8倍以上のコストが発生する。 ・ジョブの同時実行数を制御しない場合、リソースが枯渇する恐れ。
16 導入パターン オートスケーリングの実 装 対応案B 良い点 ・必要な時に必要な数で処理を実行 ・リソースやコストの最適化 懸念点
・設定方法 ・運用実績
17 • GitLab CI/CD 目指す構成 • 導入背景と現状の確認 • 導入パターン
• オートスケーリングの導入 • 性能評価 目次
18 オートスケーリングの導入 準備するもの ・GitLab Server ・Runner Server OS:
ubuntu ミドルウェア:gitlab-runner / Docker / Docker-machine ・Security Group (tcp 22,2376) ・AWS Credentials
19 オートスケーリングの導入 Runnerの種類 Shared: 全プロジェクト共通 group: グループのプロジェクト用 specific 特定のプロジェクト用
今回はSharedとしてRunnerを登録する Runnerの登録 <ご自身のgitlab-url>/admin/runners
20 オートスケーリングの導入 Runner URL 先程確認したトークン Runnerの名前 Runnerの登録 コマンド:
gitlab-runner register 設定ファイルの生成 /etc/gitlab-runner配下にconfig.tomlが生成される。
dockerイメージ CI/CDの実行環境の中(オートスケーリングマシン)でもdockerコマンドを 利用する場合はdind(docker in docker)イメージを指定する。 21 オートスケーリングの導入 !マークがついている場合 コマンド:
gitlab-runner verify gitlab-runner h でヘルプを確認可能
dockerイメージ CI/CDの実行環境の中(オートスケーリングマシン)でもdockerコマンドを 利用する場合はdind(docker in docker)イメージを指定する。 22 オートスケーリングの導入 !マークがついている場合 コマンド:
gitlab-runner verify gitlab-runner h でヘルプを確認可能
23 オートスケーリングの導入 ようやく config.tomlの説明 公式のオートスケーリングに関しては、 このファイルでほぼ全て定義しているため これを理解していればほぼゴールです。
24 オートスケーリングの導入 concurrent ジョブの同時実行数 limit インスタンスの最大数 concurrent/limitで負荷とコストが決まってくるので
状況に応じて設定する。 config.tomlはそのままで反映されないので systemctl gitlab-runner restartで設定反映
25 オートスケーリングの導入 privileged docker in dockerを利用する場合 true必須 disable_cache
オートスケーリングを行う場合、 他のインスタンスのローカルキャッシュ が利用できないため、S3に分散キャッシュ gitlab-ci.ymlでcacheパラメータを利用する 場合はtrue必須。 pull_policy = “if-not-present” Dockerイメージがローカルに存在する場合は ダウンロードせず、そのイメージを利用する
26 オートスケーリングの導入 IdleCount 最低起動台数(ジョブ実行時に即時受付可能) IdleTime ジョブ実行後にインスタンスが削除される までの時間
(再利用可能) use-private-address=true/false trueにした場合はprivate ipが通信に利用される ため、private subnetを利用する場合は外部 (Docker hub等)と通信するための フォワードプロキシ等が必要。 ※起動インスタンスにpublic ipが付与されて いるがそれで通信されている訳ではない ex) test-key ※MachineOptionsにもCredentialsの設定が 必要ですが、aws configureの設定を 利用できるのでそちらを使用しています。 ex) --amazonec2access-key= xxxxx
27 オートスケーリングの導入 request-spot-instance=true or false スポットインスタンスをオートスケーリングの インスタンスに活用する場合はtrue
t3.smallの場合オンデマンドと比較し、約1/3の コストで利用できる。 spot-price スポットインスタンスのMAX入札額 ※以下のオプションを付与すると、インスタンス 作成時にエラーが発生する。 "amazonec2-block-duration-minutes=xx" ex) test-key
28 オートスケーリングの導入 request-spot-instance=true or false スポットインスタンスをオートスケーリングの インスタンスに活用する場合はtrue
t3.smallの場合オンデマンドと比較し、約1/3の コストで利用できる。 spot-price スポットインスタンスのMAX入札額 ※以下のオプションを付与すると、インスタンス 作成時にエラーが発生する。 "amazonec2-block-duration-minutes=xx" ex) test-key
29 オートスケーリングの導入
30 オートスケーリングの導入 gitlab-ci.yml stages: ジョブの依存関係 cache: before_scriptの結果をpathsに保存
artifacts: ジョブの実行結果を保存
31 オートスケーリングの導入
32 オートスケーリングの導入 Idle Count 2 のうち1台が Job01を受付 Create
IdleCount = 2を維持するため 新たにdocker-machineが インスタンスを起動 Testステージでは2つのジョブが 並行稼動する。IdleCountを維持 するため、インスタンスが起動 ジョブ実行後はIdle timeで定められ た時間が過ぎた後にIdleCount で設定した数までインスタンスが 削除される。 Create ※Idleとして残るスポットインスタンスは定期的に更新されて いるようです。 これはスポットの有効期限までインスタンスが残り続けるのを 防ぐローテーションになっていると思います。 Idle Count = 2 Using Using Using Idle Count = 2
33 オートスケーリングの導入 runner ログの確認 var/log/syslog もしくは gitlab-runner --debug run
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3687 spotインスタンスを利用した場合に発生するエラー 実装上の問題らしく、エラーは吐くが処理に影響はない。(少しもやもや)
34 • GitLab CI/CD 目指す構成 • 導入背景と現状の確認 • 導入パターン
• オートスケーリングの導入 • 性能評価 目次
35 性能評価(稼働状況) 稼働状況: ・1ヶ月運用した結果オートスケーリングのエラーによるジョブ失敗はなし。 (受け付けたジョブ数は約3000程度) ※Spotの特性により、特定のインスタンスプールがなくなることや
入札価格がスポット価格を下回ることによりインスタンスが中断する可能性 があります。入札は余裕を持って行うことでほぼ回避可能ですが、 インスタンスプールが気になる場合はスクリプト等でsubnet-id等を変更 する仕組みが必要になります。(とはいえプールも現在は結構安定しています) ・ジョブが並列化され、複数プロジェクトや同一ステージ間で同時に 実行できるように
36 性能評価(コスト)
37 性能評価(稼働状況) コスト: スペックを上げる場合 0.214(c5.xlarge) * 24(hour) * 30(days)
= $154.08 オートスケーリングを行う場合 0.009(t3.small spot) * 24(hour) *30(days) * 平均起動台数(2-4) = 約$25 1ヶ月あたり、約8割程のコスト削減が可能!
38 参考文献 ▪Autoscaling GitLab Runner on AWS EC2 https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/
インストール手順や設定等も上記リンクやページ内リンクにございます。 ▪gitlab-ci.ymlリファレンス https://gitlab-docs.creationline.com/ee/ci/yaml/
39 終わりに 本日お話させて頂いた内容は、特に難しい作業は必要なく、 性能やコストに多くのメリットをもたらすことができます。 気になった方はぜひ、お試しください。
ご清聴ありがとうございました!!