システムプラットフォームチームの id:rskmm0chang です。

この記事は、はてなエンジニア Advent Calendar 2025の22日目の記事であり、はてなのSREが毎月交代で書いているSRE連載の2025年12月号です。

また、下記の記事(SRE連載の2025年11月号)の続編の内容となります。

そのため、パフォーマンス比較を始めた経緯などは上記の記事をご確認ください。

また、先日発表されたGitHub-hosted runnersの料金改定、そして前回のCPU編の内容も踏まえたまとめを最後に記載しており、情報量の多い内容となっていますが、ぜひ最後までお付き合いください。

なお、CPUと同様に本記事におけるGitHub-hosted runnerの測定は、private repository上で実行しています。

Disk I/Oのパフォーマンス比較

前の記事において、

スポットインスタンスをやめて、オンデマンドに切り替えたことで、ローカルSSDを搭載しているEC2も候補になり、ローカルSSDを搭載しているEC2で、上記のようなジョブを実行したところ明らかにパフォーマンスが改善し、効果が確認できました。

と記載しました。したがって本記事では、GitHub-hosted runnerとの比較だけではなく、Self-hosted runner(EC2)でのEBSとローカルSSDの構成によるパフォーマンスの比較の結果を記載します。前の記事に記載を忘れておりましたが、ローカルSSDとはAWSの用語におけるインスタンスストア（Instance Store）と呼ばれる、インスタンスストレージ: NVMe SSD を指します

比較対象

CPUのアーキテクチャによるDisk I/Oのパフォーマンスの差は、通常では出ないのですが、GitHub-hosted runnerなどでは、AMD/ARMで顕著に差が出ていた時期があり(いつの間にか改善していました)、念の為比較しています。

Runner種別	Architecture	Disk Type	label	備考
GitHub-hosted	AMD64	Virtual Disk	`ubuntu-latest`	環境はVM
GitHub-hosted	ARM64	Virtual Disk	`ubuntu-24.04-arm-2x`	環境はVM
Self-hosted	AMD64	ローカルSSD	`Self-hosted (AMD/localSSD)`	環境はコンテナ、スペックは`CPU: 2 , Memory 8GB`、インスタンスタイプは`m6id`
Self-hosted	ARM64	ローカルSSD	`Self-hosted (ARM/localSSD)`	環境はコンテナ、`CPU: 2 , Memory 8GB`、インスタンスタイプは`m8gd`
Self-hosted	AMD64	EBS	`Self-hosted (AMD/EBS)`	環境はコンテナ、スペックは`CPU: 2 , Memory 8GB`、インスタンスタイプは`m6i`
Self-hosted	ARM64	EBS	`Self-hosted (ARM/EBS)`	環境はコンテナ、`CPU: 2 , Memory 8GB`、インスタンスタイプは`m8g`

GitHub-hosted runnerにおけるDisk Typeはfdiskの結果による推測です。

EBSは下記のstorageclassを作成して、利用しています(gp3を利用しており、IOPS、スループットをデフォルト値から上げています)。

apiVersion: storage.k8s.io/v1
allowVolumeExpansion: true
kind: StorageClass
metadata:
  name: gp3
parameters:
  encrypted: "true"
  fsType: xfs
  iops: "8000"
  throughput: "250"
  type: gp3
provisioner: ebs.csi.aws.com
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

また、ubuntu-slimのパフォーマンス比較も行いましたが、あまりに遅くて15分の制限内に同等のテストを実行することができなかったため、この記事では取り扱っておりません。

比較内容

Disk I/Oのパフォーマンス比較ツールとしてfioを利用し、各パラメータでいろいろな観点から比較を行いました。

具体的には下記の内容です。

# (1) 通常のI/O (ランダム)
- name: Random Read/Write(psync,iodepth=1,bs=16k)
  id: disk_io_task_random_psync_iodepth-1_bs-16k
  run: |
    # numjobs = core number
    fio --name=random-rw --direct=1 --sync=1 --bs=16k --size=2G --numjobs=2 \
      --rw=randrw --rwmixread=50 --rwmixwrite=50 --group_reporting \
      --filename=/tmp/test_random --ioengine=psync --iodepth=1

# (2) 通常のI/O (シーケンシャル)
- name: Sequential Read/Write(psync,iodepth=1,bs=16k)
  id: disk_io_task_sequential_psync_iodepth-1_bs-16k
  run: |
    # numjobs = core number
    fio --name=sequential-rw --direct=1 --sync=1 --bs=16k --size=2G --numjobs=2 \
      --rw=rw --rwmixread=50 --group_reporting \
      --filename=/tmp/test_sequential --ioengine=psync --iodepth=1

# (3) 最大IOPS
- name: Random Read/Write(libaio,iodepth=8,bs=4k)
  id: disk_io_task_random_libaio_iodepth-8_bs-4k
  run: |
    # numjobs = core number
    fio --name=random-rw --direct=1 --sync=1 --bs=4k --size=2G --numjobs=2 \
      --rw=randrw --rwmixread=50 --rwmixwrite=50 --group_reporting \
      --filename=/tmp/test_random --ioengine=libaio --iodepth=8

# (4) 最大スループット
- name: Sequential Read/Write(libaio,iodepth=8,bs=1m)
  id: disk_io_task_sequential_libaio_iodepth-8_bs-1m
  run: |
    # numjobs = core number
    fio --name=sequential-rw --direct=1 --sync=1 --bs=1m --size=2G --numjobs=2 \
      --rw=rw --rwmixread=50 --group_reporting \
      --filename=/tmp/test_sequential --ioengine=libaio --iodepth=8

# (5) 非同期I/O効果(4との比較)
- name: Sequential Read/Write(psync,iodepth=8,bs=1m)
  id: disk_io_task_sequential_psync_iodepth-8_bs-1m
  run: |
    # numjobs = core number
    fio --name=sequential-rw --direct=1 --sync=1 --bs=1m --size=2G --numjobs=2 \
      --rw=rw --rwmixread=50 --group_reporting \
      --filename=/tmp/test_sequential --ioengine=psync --iodepth=8

結果

3回の平均値を記載しています。

実行ステップ（ベンチマーク内容）	ubuntu-latest	ubuntu-24.04-arm-2x	Self-hosted (AMD/localSSD)	Self-hosted (ARM/localSSD)	Self-hosted (AMD/EBS)	Self-hosted (ARM/EBS)
(1) Random RW (psync, iodepth=1, bs=16k)	46.0s	48.7s	12.0s	12.7s	2m 5.0s	2m 2.7s
(2) Sequential RW (psync, iodepth=1, bs=16k)	44.3s	46.0s	13.0s	12.0s	2m 6.0s	2m 2.3s
(3) Random RW (libaio, iodepth=8, bs=4k)	1m 57.0s	1m 56.3s	7.0s	8.3s	2m 13.0s	2m 14.0s
(4) Sequential RW (libaio, iodepth=8, bs=1m)	20.3s	20.3s	1.7s	4.0s	16.0s	15.0s
(5) Sequential RW (psync, iodepth=8, bs=1m)	20.7s	21.0s	2.0s	4.0s	16.0s	17.0s

簡単な考察

ローカルSSDの圧倒的な速さ: 当たり前ではありますが、ローカルSSDはすべての試験において突出して速い結果となりました。特に(1)のような一般的なランダムアクセスにおいて、EBSと比較して10倍以上の差が出ています。
GitHub-hosted runnerのバランス: 突出して速いわけではありませんが、極端に遅くもなく、絶妙なパフォーマンスバランス（遅すぎず、早すぎない）が保たれています。
EBSの特性（レイテンシ vs スループット）:
- (1), (2)のような小さめのブロックサイズのI/Oでは、ネットワーク越しであることによるレイテンシ（応答遅延）の影響が大きく、GitHub-hosted runnerよりも遅い結果となりました。
- 一方で、(4), (5)のような大容量データの読み書き（スループット重視）では、Self-hosted(EBS)の方がGitHub-hosted runnerより速い結果となりました。これはプロビジョニングしたIOPS/スループット（8000 IOPS / 250 MiB/s）の効果が出ていると考えられます。
アーキテクチャ差: GitHub-hosted runnerはAMD/ARMともにディスク性能に大きな差は見られず、同じようなストレージ構成が採用されていると推測されます。
- 余談ですが、このパフォーマンス試験を始めた頃（2025年4月頃）は、ubuntu-latestで4分弱で終わるテストがARM版では40分かかることもありましたが、現在は同等の性能に改善されています。

Diskのパフォーマンスを最大化するためのPod設定

今回のベンチマークで高い数値を記録したSelf-hosted runnerですが、ホストの物理ディスク性能を最大限に引き出すために、Podの定義でいくつかの最適化を行っています。上記の結果には載せていませんが、マウント設定を入れない場合、Self-hosted(localSSD)のパフォーマンスが悪化しました(とはいえローカルSSD自体が速いのでそれほど悪い結果ではないです)。

具体的には、コンテナのルートファイルシステム（overlay2など）による書き込みオーバーヘッドを避けるため、actionsのディレクトリ(/home/runner/_work)や一時ディレクトリに emptyDir を割り当て、ホスト側のストレージを直接利用するようにマウントしています。

    .
    .
    .
    volumeMounts:
    - mountPath: /dev/shm
      name: devshm
    - mountPath: /var/lib/docker
      name: shared
      subPath: docker
    - mountPath: /home/runner/_work
      name: shared
      subPath: work
    - mountPath: /tmp
      name: shared
      subPath: tmp
    .
    .
    .
  volumes:
  - emptyDir:
      medium: Memory
      sizeLimit: 3584Mi # PodのMemory: 8Gi
    name: devshm
  - emptyDir:
      sizeLimit: 20Gi
    name: shared

2026年からのGitHub Actions料金体系の変更について

本記事の執筆中に、GitHubより2026年からの新しい料金体系に関するアナウンスがありました。runner選定の前提に関わる重要な変更が含まれているため、補足として紹介します。

github.blog

resources.github.com

GitHub-hosted runnersの大幅値下げ

2026年1月1日より、ubuntu-latest などのGitHubホストランナーの利用料金が最大39%値下げされる予定です。

docs.github.com

Self-hosted runnersへの課金導入と直後の延期発表

当初、2026年3月からSelf-hosted runnersに対しても「Actions cloud platform charge（1分あたり$0.002）」が課金される予定でしたが、コミュニティからのフィードバックを受けてこの変更は延期（再評価中）となりました。 Updates to GitHub Actions pricing · community · Discussion #182186 で、フィードバックを受け付けているので、興味のある方は覗いてみてください。

この変更がもたらす影響

今回の検証結果（Disk I/O性能）と合わせると、以下のような判断基準の変化が予想されます。

GitHub-hosted runnersの「コスパ」向上: 最大39%の値下げにより、これまで「コスト」を理由にEBS構成のSelf-hosted runnerを選択していたケースでは、標準ランナーに戻す方が運用・コスト両面で合理的になる可能性が高まります。
ローカルSSD構成の優位性は揺るがず: どれほど安くなっても、ローカルSSD（Instance Store）が提供する圧倒的な低レイテンシはハードウェアの特性によるものです。引き続き、「最高のパフォーマンス」を追求する場合には Self-hosted (localSSD) が唯一無二の選択肢となります。AWSのリソースにアクセスしたい、などセキュリティ的な要件でSelf-hosted runnerを利用している場合に、パフォーマンス観点からもこの構成を導入するとそれだけでジョブが速くなる可能性は高いです。

Self-hosted (localSSD)のコスト面に関する補足

パフォーマンスを追求して Self-hosted runnerを運用する場合、気になるのはコスト面ですが、はてなでの実績としては、2025年料金体系でのGitHub-hosted runnerと同程度か、それ以下のインフラコストで運用できています。

1つのノード（EC2インスタンス）に Pod を詰め込みすぎると、物理的なローカルSSDであっても I/O 待ちが発生しパフォーマンスが低下してしまいます。そのため、リソース割り当てに余裕を持たせるなど「パフォーマンスを優先した運用」を行っていますが、それでも現時点では投資対効果（タイパ・コスパ）が得られています。

スペックの大きなランナーほど GitHub-hosted よりも割安に運用できる傾向があり、「速いうえにコストメリットも出る」という状態を実現しています。ただし、これ以上大幅にコストを落とすことは難しいため、GitHub-hosted runners側の値下げにより、コストメリットの観点では旨味が出せない状況になっているのも確かです。

まとめ

圧倒的なパフォーマンスを求めるならローカルSSD (Instance Store): Self-hosted runnerをすでに利用している環境において、Disk I/Oが支配的なビルドやテストでパフォーマンスに課題を感じている場合には、ローカルSSDの採用が最も確実な解決策となります。GitHub-hosted runner や EBS構成と比較して、実行時間を数分単位で削減できる可能性があります。実際、はてなではGitHub-hosted runnerを採用していたジョブをSelf-hosted runner(ローカルSSD)に切り替えたところ、平均時間で3分30秒(12m 47s -> 9m 16s)ほど短縮できました。
コストと性能のバランスが取れた GitHub-hosted runner: GitHub-hosted runnerは、EBSよりも優れたDisk I/O性能を提供しています。導入コスト・維持コストはなく、今後の値下げを踏まえると、多くのプロジェクトにとって最適な選択肢であると言えると思います。
Self-hosted runner ではコンテナ設定もセットで最適化する: どれだけ高速なディスクを用意しても、コンテナレイヤーのオーバーヘッドや適切なマウント設定をしないと、ハードウェアのポテンシャルを活かしきれません。適切なvolumeMounts、volumesの設定が必要といえます。

CPU編とDisk I/O編を合わせた総括

前回のCPU編の結果、今回のDisk I/O編の結果、2026年からのGitHub-hosted runnerの料金体系を合わせると、GitHub Actionsにおけるrunner選択の最適解が見えてきたと思います。

コストパフォーマンス良すぎる「GitHub-hosted runner(ARM)」: CPU性能の検証では、GitHub-hosted runner(ARM)が高いコストパフォーマンスを示し、Disk I/Oにおいてもバランスの取れたパフォーマンスとなっており、2025年12月時点でも割安なARM runnerが2026年1月からさらに値下げされます。これらを踏まえるとアプリケーションがARMに対応していて、GitHub-hosted runnerの利用であればこれが最適解と言えます。
CIの高速化を決定づける「ローカルSSD」: 本記事で示した通り、ローカルSSDによりDisk I/Oのパフォーマンスを劇的に向上しました。CPUはジョブの内容によってパフォーマンス向上の恩恵を受ける幅が大きいですが、Disk I/Oでは安定したパフォーマンス向上が見込まれます。ただし、Self-hosted runnerを導入する必要があり、ランニングコストに関してもある程度構成・運用を安定させるまではそれなりに高いため、すでにSelf-hosted runnerを導入している、あるいは他の要件(セキュリティなど)も解決する必要があって、Self-hosted runnerを導入する場合にはとても良い解決策になると思います。

前回の記事から始まった一連の検証が、皆様のGitHub Actionsの最適化における一助となれば幸いです。

GitHub Actionsにおけるrunnerのパフォーマンス比較(Disk I/O編) - 2026年GitHub Actions料金改定を見据えた最適解を添えて -