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

by cocone

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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倍以上のコストが発生する。  ・ジョブの同時実行数を制御しない場合、リソースが枯渇する恐れ。 

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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 

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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 

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

36 性能評価(コスト) 

Slide 37

Slide 37 text

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割程のコスト削減が可能！ 

Slide 38

Slide 38 text

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/    

Slide 39

Slide 39 text

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