GKE の共有コアマシンタイプの利用について理解を深める

はじめに

こんにちは、京セラコミュニケーションシステム 金井(@kccs_natsuki-kanai)です。
Google Cloud、IaC、CI/CD に関する内容を中心に発信していきたいと思います！

さて今回は...

最近業務で多数のシステムの GKE クラスタを触る機会があったのですが、クラスタを構築する際、どんなスペックを要するワークロードを動かすかまできちんと決まっていることは少なく、ベストな構成は難しいなと感じています。
(Autopilot があるやんとも思うのですが、諸々の事情で Standard にするしかない場合も多い...)

そんな中で、初期構築時に選びがちな 共有コア のマシンタイプについて理解を深めていきたいと思います。

この記事は2026年6月時点の情報をもとに作成しています。

この記事の要約

共有コアのマシンタイプを GKE で使うときは...

• カタログスペックで 2 vCPU とあるが、通常はその半分以下の性能しかない。(e2-medium だと 50% = 1 vCPU 相当)
• CPUバースト 機能で一時的に 2 vCPU の 100% に近い性能を出すことが可能。
• 一概に安いわけではない。スモールスタート時には安く済ませやすいけど、水平スケールするにつれてコスト効率が悪くなる。
  • CPUバースト を上手く使うことでお得に使える。

共有コアのマシンタイプとは

e2-micro, e2-small, e2-medium といったマシンタイプを指します。

Google のドキュメントによると、次のように説明されています。

E2 シリーズと N1 シリーズには、共有コア マシンタイプが含まれています。このようなマシンタイプでは物理的なコアを時分割で使用します。この方法は、小規模でリソース消費量がそれほど多くないアプリを実行する場合に費用対効果に優れていることがあります。

E2 共有コア マシンタイプは費用対効果が高く、virtio メモリバルーン デバイスを備え、小さなワークロードに最適です。E2 マシンシリーズの共有コア マシンタイプは、マルチタスクにコンテキスト切り替えを使用し、特定の時間、単一の物理コアをタイムシェアします。共有コアマシンのタイプによって物理コアの継続時間は異なります。

• e2-micro は 2 つの vCPU を維持し、それぞれが CPU 時間の 12.5%、合計 25% の CPU 時間を占めます。
• e2-small は 2 つの vCPU を維持し、それぞれが CPU 時間の 25%、合計 50% の CPU 時間を占めます。
• e2-medium は 2 つの vCPU を維持し、それぞれが CPU 時間の 50%、合計 100% の CPU 時間を占めます。

すごく大雑把に言うと「比較的安価で、ちょっと使ってみたいときに最適」というかんじなんですが、2 つの vCPU を維持し、それぞれが CPU 時間の XX%、合計 XX% の CPU 時間を占めます。 の記述が理解しづらいかもしれません。

e2-medium は 2 vCPU だけど、CPU性能が 50% に抑えられていて基本的には実質 1 vCPU 分の性能となります。e2-standard-2 (専用コアで 2 vCPU, 4GiB Memory)の半分の性能です。
(こちらの料金ページでは 2 vCPU としか書いてないので勘違いしやすい...)

じゃあ最初から 1 vCPU にしておけば...？ と思ってしまうんですが、ここで CPUバースト という機能の存在があります。

CPUバーストとは

上記のページの続きで説明されていますが、一時的にオーバーコミット（過剰割り当て）が許される機能です。とくに明示的に有効化する必要はなく自動的に行われます。

2 vCPU それぞれが 100% の性能を出せるということですね。なんとも厨二病をくすぐる響きです

e2-micro、e2-small、e2-medium 共有コア VM は数十秒間バーストできます。CPU の使用率が 100% の場合、バーストは次の時間継続します。

• e2-micro: 30 秒
• e2-small: 60 秒
• e2-medium: 120 秒

ここで記されている時間はあくまでも CPU 使用率 100% を継続 した場合であり、正確な時間はトークンバケットにより決まると説明されているため、実際にはもっと長く継続できるケースのほうが多いです。
例えば、CPU 使用率 75% を継続した場合であれば上記の倍の時間(e2-medium であれば 240秒)バーストを継続可能、ということになります。

GKE ノードでのバーストの利用イメージ

あくまで単純計算ですが、次のような例を考えてみます。

• ノードプールのマシンタイプ: e2-medium
  • 1ノードあたりの割り当て可能 CPU は 1000 mCPU (実際には後述のリソース予約により 940 mCPUですが)
• 一日一回だけ動くバッチ(CronJob)
• 実行時間: 3分(180秒)
• 実行中は 1500 mCPU 程度を使用

1500 mCPU = CPU使用率 75% なので、バースト可能な時間は 240秒 となり、このワークロードを完了することができる、ということになります。

実際にこのような使い方をすることはないと思いますが、挙動を理解して適度にバーストを使うことで共有コアの真価を引き出せます。(逆に、バーストを全く考慮しない使い方だと単純に損しやすい)

• これは理論上の計算のため、実際にこのような使い方をすると他の Pod への影響(CPU スロットリング等)が出るため非推奨です。

• k8d マニフェストの CPU Requests は実際に使用する CPU より低い値(リソース予約や kube-system の Pod などがあるので、実際には 600m くらいまで)を指定しておかないと Pod が起動できません。CPU Requests は Pod 起動時にコミットしておくための値なので、起動してしまえばノードに余裕がある限り CPU Requests 以上の CPU を使用することが可能です。

GKE のリソース予約の考慮

VM を GKE のノードで使用する場合、実際に使用できる CPU・メモリはカタログスペックの容量よりも少し少なくなります。これは GKE のリソース予約 によるものです。

CPU リソースについては、GKE が次のように予約します。

• 最初のコアの 6%
• 次のコアの 1%（最大 2 コア）
• 次の 2 コアの 0.5%（最大 4 コア）
• 4 コアを超えるコアの 0.25%

共有コア E2 マシンタイプの場合、GKE は合計 1,060 ミリコアを予約します。

e2-medium の場合は最後の行に書かれている通り 1060 ミリコアが予約されるので、割り当て可能な vCPU は

2,000 m (2 vCPU) - 1,060 m = 940 mCPU

となるわけですね。この 1,060 という数字は、ベースラインとして差し引かれている 50% + 最初のコアの 6% という理解です。

他のマシンタイプでも少し計算してみると...

• e2-standard-2 (2 vCPU) の場合
  • 2,000 m - 60 m(最初のコアの 6%) - 10 m(次のコアの 1%) = 1,930 mCPU
• e2-standard-4 (4 vCPU) の場合
  • 4,000 m - 60 m(最初のコアの 6%) - 10 m(次のコアの 1%) - 5 m(次の 2 コアの 0.5%) - 5 m(次の 2 コアの 0.5%) = 3,920 mCPU

これはノード単位で同じように計算されるので、ノード数に比例して使えない容量も増えていくということです。
コア数の大きいマシンタイプではほとんど無視できそうなんですが、共有コアマシンタイプだと結構響いてきます。

コストについて考えてみる

いくつかの専用コアマシンタイプの場合と比較してみます。

前提条件

• リージョン: Tokyo(asia-northeast1)
• 割引オプションは考慮しない

単価

Machine Type	vCPU	Memory(GiB)	Price /hour
e2-medium	実質 1	4	$0.04298286
e2-standard-2	2	8	$0.08596572
e2-standard-4	4	16	$0.17193144
e2-highcpu-2	2	2	$0.06353106
e2-highcpu-4	4	4	$0.12706212

同系統では単純に vCPU,Memory に比例した価格になっていそうですね。

e2-medium を e2-standard-2 と比べると、実質のスペックが半分で単価も丁度半分になっています。バーストが使える分、お得に見えます。

ランニングコスト

総 vCPU 数を揃えて、定常稼働させる場合で比較してみます。バーストやメモリは一旦無視します。

Estimated Cost は Google Cloud 料金計算ツール で計算しています。Boot Disk (バランス 10 GiB)、Standard クラスタの管理手数料($0.10/hour)を含みます。

Machine Type	Node Count	Total vCPU	Allocatable CPU(m)	Total Memory(GiB)	Estimated Cost /month
e2-medium	2	2	1,880	8	$138.35
e2-standard-2	1	2	1,930	8	$137.05
e2-highcpu-2	1	2	1,930	2	$120.68

e2-medium は割り当て可能 CPU(Allocatable CPU) が少ない&コストが高いという、イマイチに見えます...

ただ、ノードが複数であればゾーン分散できるので、耐障害性の面ではメリットになり得ます。

では、ワークロード増加等でリソース上限を超え、ノードが一つ追加されるケースを見てみます。

Machine Type	Node Count	Total vCPU	Allocatable CPU(m)	Total Memory(GiB)	Estimated Cost /month
e2-medium	3	3	2,820	12	$171.03
e2-standard-2	2	4	3,860	16	$201.11
e2-highcpu-2	2	4	3,860	4	$168.36

スペックが高いので当たり前ですが、e2-standard-2 はガツンとコストが増えてしまいます。共有コアは細かくスケールできるというところもメリットですね。

総 vCPU 数が 8 となる場合も見てみます。

Machine Type	Node Count	Total vCPU	Allocatable CPU(m)	Total Memory(GiB)	Estimated Cost /month
e2-medium	8	8	7,520	32	$334.42
e2-standard-2	4	8	7,720	32	$329.22
e2-standard-4	2	8	7,840	32	$326.62
e2-highcpu-2	4	8	7,720	8	$263.71
e2-highcpu-4	2	8	7,840	8	$261.11

これくらいのノード数になると、流石に割り当て可能 CPU の差が無視できないですね。e2-medium(7,520m) と e2-standard-4(7,840m) では 320m もの差が生まれるので、かなりもったいない気がします。追加で 2,3個 Pod が動かせる量です。

また、CPU が多く必要でもメモリはそんなに使わないのであれば、highcpu 系を採用することで20%程度コストを抑えられることがわかります。

結局、共有コアマシンタイプはどういうときに採用するのが良いか

※あくまで個人の見解です。実際にはもっと様々な要素が絡んでくるので、ご自身の環境と照らし合わせてご検討ください。

Good

• 開発・検証環境など、常時使わない環境。
• スモールスタートのプロジェクト。まだワークロードが具体的に決まっていなくて柔軟にスケールを考えたいとき。(将来的には専用コアに変更することを視野に入れておく)
• 軽量 API サーバー。(リクエスト時に一瞬だけ多くの CPU を使う)

ちなみに私は GitLab CI の Kubernetes Runner で使っていたりします。そこまで頻繁に CI を動かす環境ではないんですが、可用性のために最低3ノードを3ゾーンに分散させておきたい、CI ジョブの種類が多数ありそれぞれ必要な容量はまちまち、といった理由で選定しています。

Bad

• 24時間稼働する監視ツール・ログ収集ツール等を稼働させる場合。
• その他、定常的に起動するワークロードが多い場合。

最初に共有コアのノードプールを採用していて、定常的に稼働するリソース追加されるたびノードをどんどん追加(水平スケール)して対処していく、というのは無駄が多くなってしまうので避けたほうが良さそうです。

終わりに

今回は GKE で共有コアマシンタイプのノードを使う場合、とくに CPU に焦点を当てて調べてみました。

「なんとなく共有コアを使っている」「とりあえず GKE を使ってみたいけどマシンタイプ何がいいかわからん」といった方々の参考になれば幸いです。(昨今は AI に聞けば大抵のことは教えてくれますけどね...)