毎度、ググっても出てこない小ネタを取り扱っております。
本記事は個人的な見解であり、筆者の所属するいかなる団体にも関係ございません。

0. はじめに

社内のGitLab Runnerを爆速化したくて禁断の技に手を出したという話になります。
(※なぜ禁断かというと、オンメモリーストレージというのは再起動すると消えてしまいますし、大きい容量を用意するのも難しく、気をつけないと容量を使い尽くしてしまってジョブが実行できなくなってしまうからです。)

1. 何が問題だったか

事の元凶は、GitLab Code Quality です。

GitLab Code Qualityは、ソースコードを読み込んで問題点をチェックしてくれるGitLab組み込みツールです(注：2020年6月12日の時点で使えるのはStarter Edition以上、今後Community Editionでも利用できるようになるとアナウンスされている)。

Code Quality | GitLab
https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html

https://about.gitlab.com/2017/06/22/gitlab-9-3-released/

このCode Qualityの実行が遅いのです。。。

2. なぜ遅い？

Code Qualityは、ソースコードを解析するためにCode Quality用のDockerイメージをダウンロードして、Docker-in-Docker workflowという方式で動いています。以下のように動作します。

Code QualityのDockerイメージのダウンロード
Dockerイメージの展開
ソースコードの解析

この中で1と2に時間がかかっており、Diskの書き込みに待ちが発生していることが分かりました。

3. 改善

2でDiskへの書き込みが遅いことは分かりました。しかし、Diskのパフォーマンスをおいそれとは上げることができません。RAID-6で組んだHDDストレージではありましたが、4世代ぐらい前のRAIDコントローラーに4世代ぐらい前の2．5インチHDDです。これ以上はパフォーマンスが出そうにありません。

3-1. 対策 1. HDDをSSDに交換する

この方法は確かにいくらかはスピードアップするでしょう。
しかし、安くなっているとはいえ、いまさら先の見えているSATA SSDを6本も買う気にはなれませんでした。また、RAIDコントローラーがオンボロな為SSDに交換してもどこまでスピードアップするかは未知数でした。

3-2. 対策 2. Dockerに必要なファイルをオンメモリーのファイルシステムで動かす

マシンのメモリーが余っているならば、一番手軽ですぐにできて絶対に早くなる保証があります。
(いくらSSDが速いとはいえ、オンメモリーには敵わないでしょう)

さらにGitLab Runner(Code Qualityは特に)はコンテナで実行されていて、ステートフルではありません。コンテナイメージがローカルにあれば、それはそれでいいのですが、無くても最悪、自動的にダウンロードされるので問題になることはありません。それを考えるとオンメモリーで動かす事ができるワークロードと言えるでしょう。

4. 対応

対応は簡単です。
仮想環境でVMマシンにメモリーを追加して(20GBにしました)、fstabに以下のように書くだけです。
OS用に2GBとしました。

/etc/fstab

tmpfs     /var/lib/docker         tmpfs   defaults,size=18g,nofail 0       0

※メモリーを増やす場合には仮想環境のメモリー利用状況に注意しましょう。

5. 結果

どうなったか、どうだったか。

5分30秒かかっていたCode Qualityの実行が4分まで短縮されました。

残りの4分は何に使われているか。

残りの4分は以下のことに使われていました。

Code QualityのDockerイメージダウンロード(約1分)
Dockerイメージの展開(2分30秒)
Code Qualityの実行(30秒)

1については、ローカルにリポジトリーを作成するなどすればもう少し短くできるでしょう。
(キャッシュされると最高なのですが、DinDからのDockerコンテナ実行ではDockerイメージキャッシュが効きません)
2については、Dockerイメージをひたすらuntarしている状況でこれ以上早くはなりそうにありません。(CPUもtmpfsへの書き込みも余裕があるのでoverfay2の課題なのだと思います。)
3については、Code QualityはRubyのようなのでDocker内でRubyの実行スピードが上がればもう少し短くなるかも知れません。

6. `注意`

注意ポイントは、Code QualityのDockerイメージが7GBほどあることです。

tmpfsの残り容量が7GBを下回るとCode Qualityの実行に失敗します。

1日に1回チェックして、Dockerイメージを削除しましょう。