オートスケーリング化の説明/手順/ハマり/効果についてお話します。
EC2を用いた GitLab Runnerの オートスケーリング化 開発部 谷澤駿一
View Slide
2自己紹介 谷澤 駿一 Tanizawa Shunnichi 経歴： インフラ 約5年 ( Sier / 事業会社 / 現在) 業務内容： インフラの保守・運用 最近の出来事： 会社まで徒歩15分になりました
3ココネのインフラ 運用 基盤 MW オンプレ 約300 Server Biblia Billing等 多くの プロジェクト ポケコロ等
4 ● GitLab CI/CD 目指す構成 ● 導入背景 ● 現状の確認 ● 導入パターン ● オートスケーリングの導入 ● 性能評価 目次 (20分)
5GitLab CI/CD 目指す構成 構成内容 gitlab-ci.yml：CI/CDの定義を記載 Config.toml：Runnerの設定を記載
6GitLab 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の登録 /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終わりに 本日お話させて頂いた内容は、特に難しい作業は必要なく、 性能やコストに多くのメリットをもたらすことができます。 気になった方はぜひ、お試しください。 ご清聴ありがとうございました！！
cocone
shutooike
masahiro_nishimi
miso
nagworld
alli83
itohiro73
maroon1st
ogijun2018
mski_iksm
javiergs
aanrii
fishofprey
deanohume
cromwellryan
robhawkes
shpigford
ammeep
malarkey
jmmastey
searls
sstephenson
skipperchong
philhawksworth
marcelosomers