ドキュメントに関する現在のご利用体験についてお聞かせください。アンケートにご協力ください。

ジョブの実行を高速化する

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

ジョブのパフォーマンスは、イメージと依存関係をキャッシュすることで改善できます。

コンテナにプロキシを使用する

Dockerイメージのダウンロードにかかる時間を短縮するには、次を使用します:

GitLab依存プロキシ、または
Docker Hubレジストリのミラー
その他のオープンソースソリューション

GitLab依存プロキシ

コンテナイメージにすばやくアクセスするには、依存プロキシを使用してコンテナイメージをプロキシできます。

Docker Hubレジストリミラー

Docker Hubをミラーリングすることで、ジョブがコンテナイメージにアクセスするのにかかる時間を短縮することもできます。これにより、プルスルーキャッシュとしてのレジストリが実現します。ジョブの実行を高速化するだけでなく、ミラーはDocker Hubの停止やDocker Hubのレート制限に対するインフラストラクチャの回復力を高めることができます。

Dockerデーモンがミラーを使用するように設定されている場合、実行中のミラーのインスタンスでイメージが自動的にチェックされます。利用できない場合は、パブリックなDockerレジストリからイメージをプルし、ローカルに保存してから返されます。

同じイメージに対する次回のリクエストは、ローカルレジストリからプルされます。

動作の詳細については、Dockerデーモンの設定ドキュメントを参照してください。

Docker Hubレジストリミラーを使用する

Docker Hubレジストリミラーを作成するには:

プロキシコンテナレジストリが実行される専用マシンにログインします。
そのマシンにDocker Engineがインストールされていることを確認してください。
新しいコンテナレジストリを作成します:
```
docker run -d -p 6000:5000 \
    -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
    --restart always \
    --name registry registry:2
```
レジストリを別のポートで公開するために、ポート番号（6000）を変更できます。これにより、httpでサーバーが起動します。TLS（https）をオンにする場合は、公式ドキュメントに従ってください。
サーバーのIPアドレスを確認します:
```
hostname --ip-address
```
プライベートネットワークのIPアドレスを選択する必要があります。プライベートネットワークは、DigitalOcean、AWS、Azureなどの単一のプロバイダー上のマシン間の内部通信にとって、通常は最速のソリューションです。通常、プライベートネットワークで転送されるデータは、月間帯域幅制限に適用されません。

Docker HubレジストリはMY_REGISTRY_IP:6000でアクセスできます。

これで、新しいレジストリサーバーを使用するようにconfig.tomlを設定できます。

その他のオープンソースソリューション

rpardini/docker-registry-proxyは、GitLabコンテナレジストリを含むほとんどのコンテナレジストリをローカルでプロキシできます。

分散キャッシュを使用する

分散キャッシュを使用することで、言語の依存関係をダウンロードするのにかかる時間を短縮できます。

分散キャッシュを指定するには、キャッシュサーバーをセットアップし、次にそのキャッシュサーバーを使用するようにRunnerを設定します。

オートスケールを使用している場合は、分散Runnerのキャッシュ機能について詳しく学んでください。

次のキャッシュサーバーがサポートされています:

AWS S3
MinIOまたはその他のS3互換キャッシュサーバー
Google Cloud Storage
Azure Blob Storage

GitLab CI/CDのキャッシュの依存関係とベストプラクティスについて詳しく学んでください。

AWS S3を使用する

分散キャッシュとしてAWS S3を使用するには、Runnerのconfig.toml設定ファイルを編集してS3の場所を指定し、接続用の認証情報を提供します。RunnerがS3エンドポイントへのネットワークパスを持っていることを確認してください。

NATゲートウェイを持つプライベートサブネットを使用している場合、データ転送コストを削減するためにS3 VPCエンドポイントを有効にできます。

MinIOを使用する

AWS S3を使用する代わりに、独自のキャッシュストレージを作成できます。

キャッシュサーバーが実行される専用マシンにログインします。
そのマシンにDocker Engineがインストールされていることを確認してください。

Goで書かれたシンプルなS3互換サーバーであるMinIOを起動します:

docker run -d --restart always -p 9005:9000 \
        -v /.minio:/root/.minio -v /export:/export \
        -e "MINIO_ROOT_USER=<minio_root_username>" \
        -e "MINIO_ROOT_PASSWORD=<minio_root_password>" \
        --name minio \
        minio/minio:latest server /export

キャッシュサーバーを別のポートで公開するために、ポート9005を変更できます。

サーバーのIPアドレスを確認します:
```
hostname --ip-address
```
キャッシュサーバーはMY_CACHE_IP:9005で利用可能です。
Runnerが使用するバケットを作成します:
```
sudo mkdir /export/runner
```
この場合、runnerがバケットの名前です。別のバケットを選択すると、その名前は異なります。すべてのキャッシュは/exportディレクトリに保存されます。
Runnerを設定する際に、上記のMINIO_ROOT_USERとMINIO_ROOT_PASSWORDの値をアクセスキーとシークレットキーとして使用します。

これで、新しいキャッシュサーバーを使用するようにconfig.tomlを設定できます。

Google Cloud Storageを使用する

分散キャッシュとしてGoogle Cloud Platformを使用するには、Runnerのconfig.toml設定ファイルを編集してGCPの場所を指定し、接続用の認証情報を提供します。RunnerがGCSエンドポイントへのネットワークパスを持っていることを確認してください。

Azure Blobストレージを使用する

分散キャッシュとしてAzure Blobストレージを使用するには、Runnerのconfig.toml設定ファイルを編集してAzureの場所を指定し、接続用の認証情報を提供します。RunnerがAzureエンドポイントへのネットワークパスを持っていることを確認してください。

キャッシュとアーティファクトの転送を高速化する

次のオプションを使用すると、キャッシュとアーティファクトのアップロードおよびダウンロードのパフォーマンスを向上させることができます。

バックエンド固有のRunner設定

各キャッシュバックエンドには独自のconfig.tomlセクションがあります。バックエンドを最適化します:

S3設定): BucketLocationをRunnerと同じリージョンに設定します。5 GBを超えるアーカイブにはRoleARNを使用して、マルチパートアップロードを有効にします。デフォルトのS3 v2アダプターを使用します（FF_USE_LEGACY_S3_CACHE_ADAPTER=trueは設定しないでください）。Runnerがバケットリージョンから離れている場合に、AWS S3 Transfer AccelerationのためにオプションでAccelerate = trueを有効にできます。同じリージョンにあるS3 VPCエンドポイントは、レイテンシーとコストを削減できます。
Google Cloud Storage設定): Runnerと同じか最も近いリージョンにあるバケットを使用します。
Azure Blob設定): Runnerと同じか最も近いリージョンにあるストレージアカウントを使用します。

キャッシュ圧縮

より高速な圧縮を使用して、キャッシュのアーカイブとダウンロードを高速化します。これにより、より大きなアーカイブが作成されます。ジョブまたはCI/CD変数で圧縮オプションを設定します:

変数	速度が推奨される場合	説明
`CACHE_COMPRESSION_LEVEL`	`fastest`または`fast`	CPU使用率が低く、アップロードまたはダウンロードが高速になります。アーカイブは大きくなります。デフォルトは`default`です。
`CACHE_COMPRESSION_FORMAT`	`zip`	`zip`は作成が高速なことが多いです。`tarzstd`はより良い圧縮率を提供しますが、遅くなる可能性があります。

.gitlab-ci.ymlでの設定例:

variables:
  CACHE_COMPRESSION_LEVEL: fastest
  CACHE_COMPRESSION_FORMAT: zip

キャッシュリクエストタイムアウト

大量のキャッシュがタイムアウトになる場合は、CACHE_REQUEST_TIMEOUT CI/CD変数で制限（分単位）を増やしてください。デフォルトは10です。この設定は転送を高速化しませんが、遅いまたは大容量のアップロードおよびダウンロードでの失敗を防ぎます。

キャッシュ転送バッファサイズ（スループット）

キャッシュのダウンロードとアップロードには、単一のストリーミングバッファを使用します。バッファが大きいほどシステムコールが減少し、特に転送が20～30 MB/秒付近で頭打ちになる場合は、スループットが向上することがよくあります。

CACHE_TRANSFER_BUFFER_SIZE（バイト単位）をジョブ環境またはCI/CD変数で設定します。デフォルトは4 MiB（4194304）です。

8 MiBの設定例:

variables:
  CACHE_TRANSFER_BUFFER_SIZE: "8388608"

キャッシュチャンクサイズと並行処理

チャンクサイズとは、並列アップロード（GoCloud）または並列ダウンロード（プリサイン済みまたはGoCloud）の各部分またはチャンクのバイト単位のサイズです。並行処理とは、並列で実行されるチャンクの数です。メモリ使用量は、約チャンクサイズ x 並行処理です。

変数	説明	デフォルト
`CACHE_CHUNK_SIZE`	チャンクサイズ（バイト単位）。アップロード（GoCloudバックエンド）の場合: 制限はバックエンドに依存します（例えば、S3ではパーツごとに5 MiBから5 GiB、最大10,000パーツ。AzureとGCSには独自の制限があります）。ダウンロードの場合: 0 = レガシー順次。並行処理 > 1の場合、設定されていなければ16 MiBが使用されます。	アップロード: 16 MiB（16777216）。ダウンロード: 0（レガシー）
`CACHE_CONCURRENCY`	並行処理チャンクの数。アップロード: GoCloudバックエンドのみ（RoleARN付きS3、Azure、GCS）。ダウンロード: 0または1 = レガシー順次モード。1より大きい値 = 並列モード（プリサイン済みまたはGoCloud）。	アップロード: 16。ダウンロード: 0（レガシー）

カスタムチューニングの設定例（例えば、32 MiBチャンク、32並行処理）:

variables:
  CACHE_CHUNK_SIZE: "33554432"
  CACHE_CONCURRENCY: "32"

GitLabへのアーティファクトのアップロード

GitLabはアーティファクトをGitLabコーディネーターに送信し、それはオブジェクトストレージに保存される可能性があります。Runnerからのアップロードを高速化するには:

変数	速度が推奨される場合	説明
`ARTIFACT_COMPRESSION_LEVEL`	`fastest`または`fast`	アップロード前のCPU使用率と圧縮にかかる時間を削減します。

ジョブまたはCI/CD変数で圧縮オプションを設定します。例:

variables:
  ARTIFACT_COMPRESSION_LEVEL: fastest

オブジェクトストレージからのアーティファクトのダウンロード

コーディネーターがアーティファクトのダウンロードをオブジェクトストレージ（direct_download）にリダイレクトする場合、FF_USE_PARALLEL_ARTIFACT_TRANSFER 機能フラグを使用して並列範囲ダウンロードを有効にできます。これは並列キャッシュ転送（FF_USE_PARALLEL_CACHE_TRANSFER）とは別です。並列アーティファクトダウンロード（直接ダウンロード）を参照してください。