cocone Teck Talk Vol.2 -EC2を用いたGitLab Runnerのオートスケーリング化

オートスケーリング化の説明/手順/ハマり/効果についてお話します。

Transcript

1. EC2を用いた
 GitLab Runnerの
 オートスケーリング化
 開発部
 谷澤駿一

2. 2 自己紹介
 谷澤 駿一 Tanizawa Shunnichi
 経歴：
 　インフラ 約5年 ( Sier / 事業会社 / 現在) 
 業務内容：
 　インフラの保守・運用
 最近の出来事：
 　会社まで徒歩15分になりました 
 

3. 3 ココネのインフラ
 運用
 基盤
 MW
 オンプレ
 
 約300 Server
 Biblia
 Billing等
 多くの
 プロジェクト
 ポケコロ等

4. 4 
 • GitLab CI/CD 目指す構成
 • 導入背景
 • 現状の確認
 • 導入パターン
 • オートスケーリングの導入
 • 性能評価
 目次 (20分)

5. 5 GitLab CI/CD 目指す構成 
 構成内容
 gitlab-ci.yml：CI/CDの定義を記載
 Config.toml：Runnerの設定を記載

6. 6 GitLab CI/CD 目指す構成 
 gitlab-ci.yml
 ・CI/CDの定義を記載
 ・ジョブ毎に処理を分けることが可能
 ・Autoscalingではジョブ毎に
 　 実行環境が割り当てられる
 ・便利なパラメータが多く存在
 stages：実行順序
 　 variables：変数
 　 when : 手動実行を要求等

7. 7 
 • GitLab CI/CD 目指す構成
 • 導入背景と現状の確認
 • 導入パターン
 • オートスケーリングの導入
 • 性能評価
 目次

8. 8 導入背景と現状の確認 
 きっかけ
 開発側からの相談。
 ・ジョブが同時に一つしか実行できない
 ・複数ジョブ/プロジェクトの同時実行で待ち時間が発生

9. 9 導入背景と現状の確認 
 Runnerを登録した際に発行される
 サイトのURL
 Config.toml
 concurrent：ジョブの同時実行数
 ジョブが同時に一つしか実行できない
 ➔ Runnerの設定によるものだった。
 
 これで問題解決？

10. 10 導入背景と現状の確認 
 スペックの増強が必要
 
 現状のインスタンス
 t3.small (cpu: 2/memory: 2G)
 　 
 ピーク
 ジョブの同時実行数: 1
 cpu使用率: 約45%
 メモリ使用率: 約85%

11. 11 
 • GitLab CI/CD 目指す構成
 • 導入背景と現状の確認
 • 導入パターン
 • オートスケーリングの導入
 • 性能評価
 目次

12. 12 導入パターン
 マシンスペックの
 増強
 対応案A
 オートスケーリングの実 装(GitLab公式)
 対応案B

13. 13 導入パターン
 マシンスペックの
 増強
 対応案A
 良い点
 ・対応や管理が簡単
 
 懸念点
 ・1台当たりのコストが増加
 ・利用していない時間帯のコスト
 ・複数プロジェクトの同時利用時の負荷

14. 14 導入パターン
 これに見合うスペックは？
 開発チームのジョブ実行結果を
 ざっくり観測 (1プロジェクト)
 e2eテストなので重め
 
 t3.small (cpu: 2/memory: 2G)
 
 6台合わせて
 CPU使用率: 約176%
 メモリ使用率：概算 4-6G
 (瞬間的な負荷は別)
 

15. 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. 16 導入パターン
 オートスケーリングの実 装
 対応案B
 良い点
 ・必要な時に必要な数で処理を実行
 ・リソースやコストの最適化
 
 懸念点
 ・設定方法
 ・運用実績

17. 17 
 • GitLab CI/CD 目指す構成
 • 導入背景と現状の確認
 • 導入パターン
 • オートスケーリングの導入
 • 性能評価
 目次

18. 18 オートスケーリングの導入 
 準備するもの
 ・GitLab Server
 ・Runner Server
 　 OS: ubuntu
 ミドルウェア：gitlab-runner / 
 Docker / Docker-machine
 ・Security Group (tcp 22,2376)
 ・AWS Credentials

19. 19 オートスケーリングの導入 
 Runnerの種類
 Shared: 全プロジェクト共通
 group: グループのプロジェクト用
 specific 特定のプロジェクト用
 今回はSharedとしてRunnerを登録する 
 Runnerの登録
 <ご自身のgitlab-url>/admin/runners

20. 20 オートスケーリングの導入 
 Runner URL
 先程確認したトークン 
 Runnerの名前
 Runnerの登録 コマンド: gitlab-runner register
 設定ファイルの生成
 　/etc/gitlab-runner配下にconfig.tomlが生成される。

21. dockerイメージ
 CI/CDの実行環境の中(オートスケーリングマシン)でもdockerコマンドを
 利用する場合はdind(docker in docker)イメージを指定する。
 21 オートスケーリングの導入 
 ！マークがついている場合
 コマンド: gitlab-runner verify
 gitlab-runner h でヘルプを確認可能

22. dockerイメージ
 CI/CDの実行環境の中(オートスケーリングマシン)でもdockerコマンドを
 利用する場合はdind(docker in docker)イメージを指定する。
 22 オートスケーリングの導入 
 ！マークがついている場合
 コマンド: gitlab-runner verify
 gitlab-runner h でヘルプを確認可能

23. 23 オートスケーリングの導入 
 ようやく
 config.tomlの説明
 
 公式のオートスケーリングに関しては、
 このファイルでほぼ全て定義しているため
 これを理解していればほぼゴールです。

24. 24 オートスケーリングの導入 
 concurrent
 ジョブの同時実行数
 
 limit
 インスタンスの最大数
 concurrent/limitで負荷とコストが決まってくるので 
 状況に応じて設定する。 
 config.tomlはそのままで反映されないので 
 systemctl gitlab-runner restartで設定反映 

25. 25 オートスケーリングの導入 
 privileged
 docker in dockerを利用する場合 true必須 
 disable_cache
 オートスケーリングを行う場合、
 他のインスタンスのローカルキャッシュ 
 が利用できないため、S3に分散キャッシュ 
 gitlab-ci.ymlでcacheパラメータを利用する 
 場合はtrue必須。
 pull_policy = “if-not-present”
 Dockerイメージがローカルに存在する場合は 
 ダウンロードせず、そのイメージを利用する 

26. 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. 27 オートスケーリングの導入 
 request-spot-instance=true or false 
 スポットインスタンスをオートスケーリングの 
 インスタンスに活用する場合はtrue 
 t3.smallの場合オンデマンドと比較し、約1/3の 
 コストで利用できる。
 spot-price
 スポットインスタンスのMAX入札額 
 ※以下のオプションを付与すると、インスタンス 
 　作成時にエラーが発生する。
 　"amazonec2-block-duration-minutes=xx" 
 ex) test-key 

28. 28 オートスケーリングの導入 
 request-spot-instance=true or false 
 スポットインスタンスをオートスケーリングの 
 インスタンスに活用する場合はtrue 
 t3.smallの場合オンデマンドと比較し、約1/3の 
 コストで利用できる。
 spot-price
 スポットインスタンスのMAX入札額 
 ※以下のオプションを付与すると、インスタンス 
 　作成時にエラーが発生する。
 　"amazonec2-block-duration-minutes=xx" 
 ex) test-key 

29. 29 オートスケーリングの導入 

30. 30 オートスケーリングの導入 
 gitlab-ci.yml
 
 stages:
 ジョブの依存関係
 cache:
 before_scriptの結果をpathsに保存 
 artifacts:
 ジョブの実行結果を保存

31. 31 オートスケーリングの導入 

32. 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. 33 オートスケーリングの導入 
 runner ログの確認
 var/log/syslog もしくは gitlab-runner --debug run
 
 https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3687
 spotインスタンスを利用した場合に発生するエラー
 実装上の問題らしく、エラーは吐くが処理に影響はない。(少しもやもや)
 

34. 34 
 • GitLab CI/CD 目指す構成
 • 導入背景と現状の確認
 • 導入パターン
 • オートスケーリングの導入
 • 性能評価
 目次

35. 35 性能評価(稼働状況) 
 稼働状況：
 ・1ヶ月運用した結果オートスケーリングのエラーによるジョブ失敗はなし。 
 　(受け付けたジョブ数は約3000程度) 
 ※Spotの特性により、特定のインスタンスプールがなくなることや 
 　　入札価格がスポット価格を下回ることによりインスタンスが中断する可能性 
 　　があります。入札は余裕を持って行うことでほぼ回避可能ですが、 
 　　インスタンスプールが気になる場合はスクリプト等でsubnet-id等を変更 
 　　する仕組みが必要になります。(とはいえプールも現在は結構安定しています) 
 ・ジョブが並列化され、複数プロジェクトや同一ステージ間で同時に 
 　実行できるように
 
 

36. 36 性能評価(コスト)

37. 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. 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. 39 終わりに
 本日お話させて頂いた内容は、特に難しい作業は必要なく、 
 性能やコストに多くのメリットをもたらすことができます。 
 
 気になった方はぜひ、お試しください。 
 
 
 
 
 ご清聴ありがとうございました！！