こんにちは、SWETの川口 ( @yamoyamoto ) です。SWETではCI/CDチームの一員として、GitHub Actionsセルフホストランナー基盤の開発・運用に取り組んでいます。
今回は、私たちのチームがDocker Hubのレートリミット回避とコスト削減のためにミラーサーバーを導入した事例を共有したいと思います。
目次
はじめに
近年、多くの組織でGitHub Actionsを始めCI/CDの活用が進み、その中でDockerコンテナの利用も当たり前のものとなっています。私たちの組織でも、さまざまなチームがCI/CD基盤 （CircleCI Server・GitHub Actionsのセルフホストランナー等） 上でDocker Hubのイメージを利用していますが、規模が大きくなるにつれて2つの重要な課題が顕在化してきました。
第一に、深刻な問題としてDocker Hubのレートリミットがあります。2024/12からは未認証時のpull数の制限が「10 pull/時間」 1 となっており、全社で共有利用しているCI/CD基盤ではこの制限だとすぐにレートリミットに達してしまいます。2
第二に、インターネット通信に関わるコストの問題です。私たちのCI/CD基盤はAWS上のプライベートサブネットに配置されているため、Docker HubからのイメージpullはNAT Gateway経由での通信となり、転送料金が発生します。一見少額に見える料金も、イメージが何度もpullされるCI/CD基盤では無視できない額となります。
本稿では、これらの課題に対してDocker Hubのミラーサーバーを構築することでどのように解決したのか、その検討過程から実装、運用結果までを共有したいと思います。
課題解決に向けた検討
先述した課題に対する解決策についてまず始めに思いついたのは、CI/CD基盤側にてあらかじめ用意したDockerアカウントでdocker loginしておくことで、認証のstepを入れていないユーザーも認証済みの状態でDocker Hubからpullできるようにする方法でした。しかし、この方法ではDocker Hubのレートリミット問題は解決できますが、通信コストの問題には対応できません。
次に考えたのは、Docker Hubのミラーサーバーを利用する方法でした。ミラーサーバーはクラウドサービスとして提供されているものを利用するか、自前で構築するかの2つの選択肢があります。今回は比較検討した結果、Distributionというツールを使って自前でミラーサーバーを構築する方法を選択しました。先に結論として今回構築したミラーサーバーの構成を次に示します。
以降では、この選択に至るまでの検討および検証プロセスについて紹介します。
既存ソリューションの検討
まず初めに、Google Cloud・AWSで提供されている既存のソリューションを調査しました。結論としては、これらのソリューションでもレートリミットは解消できそうでしたが、通信コストの問題やイメージの指定方法に癖があったりと、十分な解決策にはならなさそうということで採用を見送りました。
Google Cloud - Artifact Registry （mirror.gcr.io）
Google Cloud が提供する mirror.gcr.io は、Docker Hubのレートリミット問題を解決できる魅力的な選択肢でした。しかし、私たちのCI/CD基盤はAWS上で運用されているため、Google Cloudへのアクセスによる新たな通信コストが発生するため、今回課題としてあげている通信コストの問題には対応できません。
AWS - Amazon ECR Public
同じくDocker Hubのミラーサーバーとして機能する Amazon ECR Public も検討しました。AWS環境との親和性は高いものの、イメージURLをたとえば nginx:latest であれば public.ecr.aws/nginx/nginx:latest のようにPrefixがついた形に変更する必要があります。これには次の2つの課題がありました。
- Dockerfileなどで利用するイメージのURLは
nginx:latestのようなDocker Hubから取得する形式であることが一般的なこともあり、組織全体でのURL形式の変更は大きな手間となる - GitHub Actionsのサードパーティ製Docker actionでは、Dockerfileへの対応（forkなど）を必要とすることがあり、これは管理・運用コストの増加につながる
Distribution を利用したミラーサーバーの構築
これらの検討を経て、私たちは CNCF が提供する Distribution を利用した独自のミラーサーバーの構築を選択しました。
Distributionは OCI Distribution Spec を実装したコンテナレジストリサーバーです。このDistributionを Pull Through Cache として構成し、Dockerライセンスを割り当てます。そしてクライアント（docker daemon, buildkit）からDistribution経由でイメージをpullするように設定することで、CI/CD環境からのDocker Hubへのpullレートリミットの制限を緩和します。
この選択には次のような利点があります。
- CI/CDジョブからイメージ取得時のURL形式において、Docker Hubとの完全な互換性を保つことができる
- つまり、ミラーサーバーの場合でもDocker Hubと同じURLでイメージをpullできるため、既存のCI/CDジョブの変更が不要
- ネットワーク転送コストの削減が期待できる
- キャッシュヒット時はDocker Hubへの通信が発生しないため、通信コストを削減できる
他にも、OCI Distribution Specを実装した有名なコンテナレジストリサーバーとして Harbor というツールもあります。しかしこのツールは多機能なため、運用コストは高くなる可能性がありました。後述しますが、その点Distributionはシンプルながら私たちの求める機能を備えており、パフォーマンスについても問題なかったため、今回はDistributionを選択することにしました。
Distribution について
リクエストの処理フロー
Distributionをミラーサーバーとして構成する場合、その挙動はシンプルです。クライアント（今回でいえばCI/CDジョブ上のdockerdやbuildkitなど）からのイメージのpullは次のように処理されます。
- ミラーサーバーのストレージにキャッシュが存在するか確認
- キャッシュが存在する場合はキャッシュから返却
- キャッシュが存在しない場合は、Docker Hubからイメージを取得してストレージにキャッシュした上で返却
この仕組みにより、2回目以降の同一イメージへのリクエストは、Docker Hubにアクセスすることなく処理できます。
検討が必要だったポイント
Distribution導入やその後の運用に関して、特に次の点について検討が必要でした。
- ストレージ選定（S3 vs filesystem）
- コストとスケーラビリティ観点でS3を利用したいが、実際のワークロードで十分なパフォーマンスが出せるか確認が必要
- 運用に必要なメトリクスの確保
- キャッシュヒット率やDocker Hubとの通信量など、運用に必要なメトリクスが取得できるか確認が必要
- 利用されていないイメージの削除について
- キャッシュの容量が増加し続けるとストレージコストが増大するため、不要なイメージを削除する仕組みが必要
先に結論を述べます。
1についてはミラーサーバーの台数を増加させてS3への書き込みを並列化することで十分なパフォーマンスが出せることを確認しました。
2についてはAWSリソースの標準メトリクスと、Distributionが提供するPrometheusメトリクスを合わせることで運用上問題がないことを確認しました。
3については、Distributionの提供する機能で十分対応できることを確認しました。
以降では、これらの調査結果について詳しく解説していきます。
ストレージの選定とパフォーマンス検証
DistributionではストレージバックエンドとしてS3またはfilesystemを選択できます。先述したとおり、S3はコストとスケーラビリティの観点で魅力的ですが、CI/CD基盤から利用する上での実際のパフォーマンスはどうなのか検証が必要でした。
そこで、実際の利用パターンを想定した次のような観点でベンチマークを実施しました。
- 複数個の並列ジョブからのdocker pull（5並列と50並列）
- 5個のジョブの並列実行は、CI/CD基盤の通常時の想定
- 50個のジョブの並列実行は、CI/CD基盤のピーク時の想定
- キャッシュヒット時とミス時のそれぞれのケースでの測定
- キャッシュヒット時はストレージからの読み込み、キャッシュミス時はストレージへの書き込みとなりワークロードの性質が異なるため、それぞれでパフォーマンスを検証する必要がある
このベンチマークでは、主要なコンテナイメージ（nginx, python, node, mysqlなど）約100個を対象に測定しました。実際のCI/CDジョブ環境に近づけるため、本番環境で利用している構成と同一のGitHub Actionsのセルフホストランナー上でジョブを実行し、docker pullを行うstepが完了するまでの時間を計測しました。また、現状のCI/CD基盤の構成（ミラーサーバーなし）でも計測してパフォーマンスを比較しています。
計測に利用したジョブの定義
name: Benchmark Image Pull with Pull Through Cache on: workflow_dispatch: inputs: parallel: description: "Number of parallel jobs" required: true type: number jobs: pull_images: runs-on: group: swet labels: - swet-test strategy: max-parallel: ${{ fromJson(github.event.inputs.parallel) }} matrix: image: - nginx:1.25.3 - python:3.12.0 - node:20.9.0 (省略) steps: - name: Pull Image run: docker pull ${{ matrix.image }} - name: Image Details run: docker image inspect ${{ matrix.image }}
まず結論としては、S3 は十分なパフォーマンスを発揮できることがわかったため、本番環境では S3 をストレージバックエンドとして採用することにしました。
以降では、ベンチマークの結果を詳しく解説します。
S3、filesystemの構成
ベンチマークするにあたって、S3とfilesystemの構成は次のようにしました。
- S3
- バケットはミラーサーバーと同じリージョンに配置して、VPC Endpoint(Gateway)経由で接続
- ストレージクラスはスタンダードを利用
- filesystem
Distributionのストレージ設定については、以下の環境変数を設定することで切り替えが可能です。詳細はドキュメントを参照してください。
S3の場合
REGISTRY_STORAGE=s3 REGISTRY_STORAGE_S3_BUCKET=sample-bucket # S3バケット名 REGISTRY_STORAGE_S3_REGION=ap-northeast-1 # S3リージョン
filesystemの場合
REGISTRY_STORAGE=filesystem REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/var/lib/registry # イメージを保存するディレクトリパス (EBSのマウントパスと合わせる必要がある)
ミラーサーバーなしの場合の結果
まずは既存と同じ状況である、直接Docker Hubからpullする場合のパフォーマンスをベースラインとして計測しました。次に計測結果を示します。
| ケース | ジョブ並列数 | docker pull にかかった時間の平均値 |
|---|---|---|
| ミラーサーバー経由なし | 5 | 37.28 s |
| ミラーサーバー経由なし | 50 | 43.16 s |
以降では、このベースラインと比較してS3、filesystemをストレージとしたミラーサーバーのパフォーマンスを検証します。
ミラーサーバーありの場合の結果
キャッシュヒット時の結果
キャッシュヒット時の結果は良好でした。次に計測結果を示します。
| ケース | ジョブ並列数 | docker pull にかかった時間の平均値 |
|---|---|---|
| S3 | 5 | 37.3 s |
| filesystem | 5 | 36.7 s |
| S3 | 50 | 42.8 s |
| filesystem | 50 | 42.1 s |
S3、filesystemともに、ミラーサーバーなしの場合とほぼ同等のパフォーマンスを示し、特に並列数が増えた場合でも大きな劣化は見られませんでした。
ストレージにS3を使用した場合、Distributionはキャッシュヒット時にS3へ保存されているイメージ（blob）への署名付きURLに307でリダイレクトします。次にイメージ図を示します。
図の通り、リダイレクトによってミラーサーバーを経由せずにクライアントが直接S3からデータを取得できる仕組みとなっています。これにより、DistributionはS3にファイルが存在するかどうかと署名付きURLの発行のみを行えばよく、それにより大きなサイズのイメージをDistributionが直接返す必要はなくなります。結果、処理が比較的軽く、50個程度のジョブの並列実行であればパフォーマンスの劣化がほとんど見られないと考えられます。
キャッシュミス時の結果
一方、キャッシュミス時には興味深い結果となりました。次に計測結果を示します。
| ケース | ジョブ並列数 | docker pull にかかった時間の平均値 |
|---|---|---|
| S3 | 5 | 37.2 s |
| filesystem | 5 | 37.4 s |
| S3 | 50 | 109.1 s |
| filesystem | 50 | 44.3 s |
50個のジョブの並列実行の際にS3が109.1秒と、大幅なパフォーマンス低下が見られました。原因にあたりをつけるために、まずはキャッシュミスした時の処理フローを確認します。次にイメージ図を示します。
図のとおり、キャッシュミスしたときは次のような流れで処理が行われます。
- DistributionがDocker Hubからイメージを取得（②・③）
- 取得したイメージをキャッシュとしてS3に保存（④・⑤）
- クライアントにイメージを返却（⑥）
この流れにおいて、キャッシュヒットした時との違いはS3への書き込みが発生することです。 それを踏まえて、キャッシュミス時のパフォーマンス低下に対して以下2つの仮説が立ちました。
- Distribution（ミラーサーバー）側の問題で、マシン1台あたりのS3への並列書き込みがボトルネックとなっている
- Fargateのネットワーク帯域制限がボトルネックとなっている
- FargateにはvCPU数に応じたネットワーク帯域制限があり、今回は2vCPUのFargateインスタンスを使用しているため帯域は360 Mbps程度となっており、これがボトルネックとなっていた可能性
1については、S3は巨大な分散システムであり、書き込みの並列度を上げることでパフォーマンスを向上できるためFargateのスケールアウトで対応できそうです。3 2については、帯域を増やすためにFargateのスケールアップかスケールアウトのどちらかで対応できそうです。
そこで、両仮説に対して効果がありそうなスケールアウト、つまりFargateの台数を増やすことで再検証しました。次に計測結果を示します。
| ケース | ジョブ並列数 | docker pull にかかった時間の平均値 |
|---|---|---|
| Fargate 1 台 （S3） | 50 | 109.1 s |
| Fargate 2 台 （S3） | 50 | 65.1 s |
| Fargate 5 台 （S3） | 50 | 42.3 s |
| Fargate 10 台 （S3） | 50 | 41.7 s |
結果より、スケールアウトによってキャッシュミス時のパフォーマンスの問題を解消できることが確認できました。4 50個のジョブの並列実行という状況では5台程度にスケールアウトすることで、ミラーサーバーなしの場合と同等のパフォーマンスを実現できています。
仮にミラーサーバーへのアクセスが集中してきたとしても適切にスケーリング設定をすれば、S3 はストレージバックエンドとして十分に実用的であるという結論に至りました。
Distribution が提供するメトリクスの調査
運用面では、必要なメトリクスを取得できるかどうかが重要なポイントです。ミラーサーバーはAWSで構成する予定であったため、AWSリソース（ALB, ECS, S3）の標準メトリクスも利用できますが、それを踏まえてもミラーサーバーレベルで次のようなメトリクスを取得できることが望ましいと考えていました。
- キャッシュヒット数/率
- ミラーサーバーのキャッシュ効果を評価するために必要
- Docker Hubとの通信量
- キャッシュヒット率と組み合わせて通信量の削減効果を評価するために必要
Distributionは標準で Prometheus メトリクスを HTTP で公開する機能を備えていますが、具体的にどのようなメトリクスが取得できるかはドキュメントに詳しい記載がありませんでした。
そこで、ドキュメントにしたがって次のように環境変数を設定してDistributionを起動し、取得できるメトリクスを調査しました。
REGISTRY_HTTP_DEBUG_PROMETHEUS_ENABLED=true REGISTRY_HTTP_DEBUG_PROMETHEUS_PATH=/metrics
この設定によって出力されたメトリクスの中から、次のメトリクスが運用において特に有用と判断しました。
- キャッシュヒット数・キャッシュミス数：
registry_proxy_hits_total,registry_proxy_misses_total- これらからミラーサーバーのキャッシュヒット率が算出できる
- Docker Hubからpullしたデータ量：
registry_proxy_pulled_bytes_total- これとキャッシュヒット率から通信量の削減効果を評価できる
- ストレージの操作パフォーマンス：
registry_storage_action_seconds- ストレージへの書き込みや読み込みのパフォーマンスを把握して適切なスケーリング設定に活用できる
参考：Prometheusメトリクスの出力結果
※ 主要なメトリクスを抜粋
$ curl 'http://<Host>:<port>/metrics'
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
...
go_gc_duration_seconds{quantile="0.5"} 5.2463e-05
go_gc_duration_seconds_sum 0.019355264
go_gc_duration_seconds_count 32
...
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 49
...
# HELP go_threads Number of OS threads created.
# TYPE go_threads gauge
go_threads 5
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 44.92
...
# HELP registry_proxy_hits_total The number of total proxy request hits
# TYPE registry_proxy_hits_total counter
registry_proxy_hits_total{type="blob"} 0
registry_proxy_hits_total{type="manifest"} 36
# HELP registry_proxy_misses_total The number of total proxy request misses
# TYPE registry_proxy_misses_total counter
registry_proxy_misses_total{type="blob"} 260
registry_proxy_misses_total{type="manifest"} 65
# HELP registry_proxy_pulled_bytes_total The size of total bytes pulled from the upstream
# TYPE registry_proxy_pulled_bytes_total counter
registry_proxy_pulled_bytes_total{type="blob"} 5.956054585e+09
registry_proxy_pulled_bytes_total{type="manifest"} 186051
...
# HELP registry_storage_action_seconds The number of seconds that the storage action takes
# TYPE registry_storage_action_seconds histogram
registry_storage_action_seconds_bucket{action="Delete",driver="s3aws",le="0.005"} 0
...
registry_storage_action_seconds_sum{action="Delete",driver="s3aws"} 0.800432593
registry_storage_action_seconds_count{action="Delete",driver="s3aws"} 22
...
Telegraf でのメトリクス収集
先ほど示したPrometheusメトリクスは、Telegraf というエージェントツールを利用することで収集し、CloudWatchへ送信できます。Telegrafの設定の際には次のようなポイントがあります。
- Input Pluginとして inputs.prometheus を利用する際、
metric_versionは1に設定する （v1.31.3時点）metrics_versionをより新しい2に設定するとnamepassで指定したメトリクスがCloudWatchに出力されない （v1.31.3時点）
- 多くのメトリクスは累積値（_totalサフィックスがついているもの）となっているため、そのままではメトリクスから直感的なインサイトを得るのが難しい
- Telegrafの aggregators.basicstats を利用して差分を取得することで特定期間ごとの増分を取得できる
- 複数インスタンスで運用する場合の、hostごとのメトリクスと全体のメトリクスの区別について
- デフォルトではメトリクスにhostタグ （CloudWatchメトリクスにはこれがDimensionとして出力される） が付与されるため、これをそのまま利用すると全hostを集約したメトリクスを得るのが難しい
- Telegrafの processors.clone でhostごとのメトリクスを複製したのち、processors.override でhost Tagをexcludeすることで、hostごとのメトリクスと全体のメトリクスを分離できる
これらのポイントを踏まえたTelegrafの設定例を参考までに記載しておきます。
Telegraf の設定例
[agent] interval = "60s" skip_processors_after_aggregators=true [[ inputs.prometheus ]] urls = ["http://<host>:<port>/metrics"] # ここに取得したいメトリック名を指定する namepass = [ "registry_proxy_hits_total", "registry_proxy_misses_total", "registry_proxy_pulled_bytes_total", "registry_storage_action_seconds" ] # 2 だと namepass を指定した時に CloudWatch Metrics に吐かれなくなってしまう metric_version = 1 # host ごとのメトリックとは別に全 host で集約されたメトリックを CloudWatch に吐くために clone して、後続の processor.override で host タグを除外する [[ processors.clone ]] name_suffix = "_all" [[processors.override]] namepass = ["*_all"] tagexclude = ["host"] # registry から提供されるメトリック値は全て累積値であるため、ひとつ前のメトリック値との差分を取ったものを出力する [[aggregators.basicstats]] period = "5m" stats = ["diff"] # 累積値はさほど有用でないため、Cloudwatch に出力しない drop_original = true [[ outputs.cloudwatch ]] region = "ap-northeast-1" namespace = "container-registry-mirror"
ここまでの調査で、Distributionが提供するメトリクスとAWSリソースの標準メトリクスを組み合わせることでミラーサーバーの状態を適切に観測できると判断しました。
利用されていないイメージの削除について
ミラーサーバーはさまざまなイメージをキャッシュしますが、利用されないイメージがキャッシュとして溜まっていくとストレージコストが増大するため、利用されていないイメージは定期的に削除する仕組みが必要です。
調査したところ、Distributionではキャッシュの TTL（Time To Live）を設定することで、一定期間利用されていないイメージの自動削除が可能となっています。
そこでドキュメントにしたがって次の環境変数を設定してDistributionを起動したところ、期待どおりキャッシュされてから10分後にイメージがストレージから削除されていることを確認しました。
# TTL を 10 分に設定 REGISTRY_PROXY_TTL=10m
また、細かいところですが次のようなポイントも確認し、運用上の問題は少ないことを確認しました。
- キャッシュヒットが起こった場合、TTLがリセットされるため、頻繁に利用されているイメージは削除されない
- ここですでに古いキャッシュエントリがある場合は、新しく削除をトリガーするタイマーを起動し、古いタイマーは無効化している
- キャッシュエントリはストレージに永続化されているので、Distributionの再起動後もキャッシュエントリは有効
- そのため、インスタンスが入れ替わったとしてもキャッシュエントリは維持される
本番環境での構成
ここまでの調査を踏まえ、本番環境での構成を決定しました。冒頭で示した構成を再掲します。
図にあるとおり、Distributionをコンテナで動作させる環境としてECS on Fargateを採用しました。以下がEC2ではなくFargateを採用した理由になります。
- 運用の簡素化のため
- ストレージにS3を利用してもパフォーマンス的に問題ないことがわかったため
- ストレージにfilesystemを使う前提だと、ベンチマークで行ったようなFargateにEBSをアタッチする形式の場合はECS Taskの終了と合わせてEBSも削除されるため、Taskの入れ替わりによってキャッシュが全て消えてしまうという懸念があった
- この懸念を解消するためには、ECS on EC2にしてEC2インスタンスからECS Taskにボリュームをマウントする必要がある
- しかし、ストレージにS3を採用できることがわかったことで対応の必要はなくなった
また前段にALBを配置し、ストレージはベンチマークで十分な性能が確認できたS3を採用しています。併せて、ECS Task上ではDistributionに加えてメトリクス収集用のTelegrafをサイドカーとして配置して適宜CloudWatch Metricsへ出力させています。
スケーリング
スケーリングについては、App Autoscalingの Target tracking policy を利用して自動化を図っています。具体的には、ベンチマークで計測したFargate 1台あたりの適正リクエスト数を基準として設定し、ECS Serviceのdesired countを自動的に増減させる設定としました。
このスケーリング設定について、ミラーサーバーは比較的サイズの大きなコンテンツをやり取りするサービスなので、ネットワーク通信の負荷が支配的という特性をもつことが推測されます。S3をストレージに採用した場合、キャッシュヒット時は307リダイレクトによってクライアントが直接S3からデータを取得する仕組みとなっていることから、Fargateインスタンス自体はネットワーク通信の負荷はさほど高くない可能性が高いと考え、今はリクエスト数ベースでのスケーリングを採用しています。
セキュリティ
ミラーサーバーはDocker Hubのパブリックなイメージのみをミラーしており、クリティカルなデータをもつことはないため、セキュリティ面ではできるだけシンプルな構成を目指しました。Distributionが提供するOAuth2やJWT認証の機能は使用せず、代わりにVPC内のプライベートサブネットへの配置とセキュリティグループによる制御を採用しました。これにより、社内のCI/CD基盤からの安全なアクセスを、運用負荷を増やすことなく実現できています。
メトリクスの可視化
運用面では、ミラーサーバーの稼働状況をいつでも一目で確認できるように、主要なメトリクスを集めたCloudWatchダッシュボードを構築しました。
このダッシュボードには運用時に有用なリクエスト数、エラーレート、キャッシュヒット率、upstreamからのpullしたバイト数、リソース使用率、ストレージ使用量などのメトリクスを表示しています。ここでは主要なグラフを抜粋して示します。
上記のグラフでは、高いパーセンタイル値で度々レイテンシが高くなっていますが、リクエスト数のピークとはズレた時間帯に突発的に発生しているため、これは恐らくサイズの大きいイメージをpullしたときのものと考えられます。
導入による効果
2024年11月現在、導入から数週間が経過していますが特にエラーもなく効率的に運用できています。主要なメトリクスについては、前のセクションに載せているグラフを参照ください。
まず注目すべき点としては、約97%という非常に高いキャッシュヒット率を達成できていることです。これは、CI/CD環境における同一イメージの再利用が多いという特性をうまく活かせた結果だと考えています。
処理性能の面では、週間約14万件のリクエストを安定して捌けており、ピーク時には1分間あたり600リクエストほどのアクセスがありましたが、1 vCPU, 2GB MemoryというコンパクトなFargateインスタンスで問題なく対応できています。この結果は、事前のベンチマークで得られた結果が実環境でも有効であることを示しています。
ミラーサーバー導入によりコスト面での効果も得られています。Docker Hub（upstream）への通信量を週50GB程度まで削減できており、これはキャッシュヒット率から推測すると、ミラーサーバーがないときと比べて週あたり1600GB以上の通信量削減を実現できていることになります。また、S3のストレージ使用量も60GB程度で安定しており、97%という高いキャッシュヒット率を維持しながらも、ストレージコストを適度な範囲に抑えることができています。
まとめと今後の展望
Docker Hubのミラーサーバーにより、コストとレートリミットの問題を効果的に解決できました。
今後の課題としては以下を検討しています。
- Fargateのスケーリング設定の最適化
- リクエスト数ベースのスケールよりも適切なスケーリング戦略があるか検討
- Docker Hubからのpull残数についてのモニタリング強化
- 万が一にもミラーサーバー側でレートリミットが発生してしまわないように、pull数の残量とその消費傾向の把握をしたい
- この情報を元にして、必要に応じてライセンスのローテーションの仕組みを入れるなどの判断を行えるようにしたい
本事例が、同様の課題に直面している方々の参考になれば幸いです。質問やコメントがありましたら、ぜひXなどでお気軽にご連絡ください。
また、DeNA公式Xアカウント @DeNAxTechでは、このようなブログ記事や勉強会での登壇資料を発信しています。ぜひフォローをお願いします！
- https://www.docker.com/ja-jp/blog/november-2024-updated-plans-announcement/↩
- 今回はGitHub Actionsのセルフホストランナー環境へミラーサーバーを導入しましたが、CircleCI Serverではすでにミラーサーバーを導入しており、レートリミット問題を解決していました。ただし既存のCircleCI側のミラーサーバーの構成そのままではGitHub Actionsのセルフホストランナーから利用することが難しかったため、今回は新しく統一的に利用できるミラーサーバーを構築することで運用・インフラコストを削減を目指しました。↩
- https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-guidelines.html#optimizing-performance-guidelines-scale↩
- 立てた2つの仮説のうち、実際にはどちらがボトルネックだったのかまでは検証できていません↩
