GitLab-CIこんにちは、弓場と申します。前まではKubernetesのyamlファイルをたくさん書いておりましたが、最近はAnsibleのyamlをたくさん書いています。Scalingについてお話します。現在のRunnerとJobの設定まず、経緯をお話する前に弊社のRunner状況について説明します。Runnerは2種類用意されています。Imageを指定すればサービス独自のコンテナ上でテストをすることが出来ます。全てのリポジトリからこのRunnerを使用することが出来ます。--version2つ目は、データセンターのVMを使用したRunnerです。オンプレサーバーを使います。Executorで動いております。こちらはサービス独自のRunnerで、私たちのチームしか使えないRunnerになります。こちらにはDockerのようにImage等を使用することが出来ませんが、インストールしたソフトウェアやライブラリは消えずに残り続けるのでキャッシュを使わなくても早い処理が見込めます。最後にサービスのGitLabJobとGitブランチのRunnerは以下のような状況になっていました。Runner何が問題なのか上記のような状況で、開発ブランチのJobを何度か動かしているうちに以下のような問題が発生しました。RunnerはJobを動かすスペックが高くないため、ジョブが完了するまで時間がかかってしまう開発ブランチは複数人が同時別ブランチをPushすることがあるため、テストJobが6つ同時に動くこともある。Runner自体のメモリが足りずにエラーになってしまうということがあったまた、開発ブランチによるJob実行数は不安定であり急に増えることもあれば1日ずっとJobがこないこともあります。Runnerに頼り続けるわけにもいかず、かといって専用のオンプレサーバーを立てるとたまにしか使わないサーバーを専有してしまうことになってしまいます。Executorを用意しています。MachineとEC2の構成については日本語の紹介しているM3さんのテックブロク記事に詳しく書かれています。経過するとインスタンスが削除されます。削除される前に次のJobが実行されればインスタンスは削除されずに残り続けます。Instanceを使用するJobが呼ばれたタイミングでしか課金されませんが、それでもc5.largeであれば1時間に$0.085かかります。Instanceを使うことによってコストを最大4分の1まで下げることが出来ます。設定値の全体的なコードは公式の資料が参考になります。今回の改善によって実行時間を10分間短縮することが出来ました。どのくらいのスペックが良いかを調査ただ単にスペックの高いインスタンスを用意するのも良いですが、テストJobがスペックを全て使いきれるとも限らないため、いろいろなインスタンスを用意して一番良い環境がどのなのかを調査しましたが、スペックを上げていっても結果は変わりませんでした。6分Jobの実行時間が変わらなかった要因として考えられるのは、テスト自体が直列実行になっており、cpuとメモリを全て活用し切れていないのが要因なのではないかと思います。CIの実行速度が上がり開発をより早く回せるようになりました。次に行うべきアクションは以下のようなものが考えられます。テストを並列で動かせるようにするSTGブランチと本番ブランチも今回作成したRunnerに移行するこれらのアクションをすぐに実行したいですが、現状でも大きく改善出来ておりまた上記の改善はそこまで大きい改善が見込めないため、さらにJobの時間がかかるようになったりした場合に再度改善に取り組みたいと思います。ブログのタイトルで(Autoscal...2019-06-21AnsibleとShellでALBのTargetGroupのWebサーバのデーモンを再起動するこんにちは。