アプリケーション開発事例

Amazon EKSサイジング方法

佐藤慎哉

読み込み中...

投稿日 2025/03/28

更新日 2026/05/26

Amazon EKSサイジング方法

はじめに

Amazon EKS(以後EKS)のEC2サイジングをプロジェクトの中で進めており、そのノウハウの展開となります。

インスタンスタイプ選定において、EKSでは制約があることが後に発覚し再見直しになったなどの気づきも記載していますので、

これからサイジングを進めようとしている人の参考になれば幸いです。

※本記事はEKSやKubernetesをある程度知っている方向けの記事となります。

概要

以下の流れでEKSで利用するEC2コンテナホストのサイジングと台数算出を説明していきます。

・サイジングの対象/方法

・EKSのシステム領域リソース検討

・EKSの業務領域リソース検討

・コンテナホストのサイジング

サイジングの対象/方法

サイジング対象

今回のコンテナサイジング対象は以下をEKSに変更した際のサイジングとしています。

EKS変更後に何のインスタンスタイプで何台のコンテナホストを用意すべきかを検討していきます。

・対象：EC2 m6i.xlarge(4vCPU 16GB) 2台のWebサーバ

導入ソフトウェアApache Tomcat

・その他要件：ログ出力、CloudWatchメトリクス出力

サイジング方法

EKSに必要な「システム領域」とWebサーバの「業務領域」でそれぞれ必要CPUやメモリのリソース量を算出して、適切なコンテナホスト(EC2のインスタンスタイプ)のスペックと台数を算出します。

システム領域及び業務領域を求めるため、以下の3点のリソースを算出していきます。

・コンテナホスト毎に必要なシステム領域(A)

・コンテナホストのいずれかで稼働が必要なシステム領域(B)

・業務領域の必要リソース(C)

EKSのシステム領域リソース検討

EKSを動かすために必要なKubernetes管理エージェントやコントローラーのスペックを積み上げます。

以下の図の通り、(A)と(B)について必要なCPU及びメモリを算出します。

コンテナホスト毎に必要なシステム領域(A)

コンテナホスト1台毎に必要なシステム領域として「kubelet」とコントロールプレーンの「DaemonSet」が動作します。

対象	用途	使用数	CPUタイムスライス(ms)※2	メモリ(MB)※2
kubelet ※1	Kubernetes管理	ノード単位	500	1024
コントロールプレーン(DaemonSet) 　※3
kube-proxy	ネットワーク管理	ノード単位	100	100
aws-node	VPC内通信用	ノード単位	25	100
ebs-csi	EBS接続用	ノード単位	50	500
fluent-bit	ログ出力用	ノード単位	100	200
cloudwatch-agent	CloudWatch連携用	ノード単位	100	200
最低コンテナホスト1台のリソースの合計			0.88vCPU	2124MB

※1 kubeletのリソースは以下のサイトから算出しています。

Chapter 6. Working with nodes | Red Hat Product Documentation

※2 記載のCPUやメモリは実際に適用したコンテナ環境で出力したデフォルト値となります。

※3 今回EBSの利用やログ出力やCloudWatchのAgentなどを導入していますが、インフラ領域において必要なプラグインなどがあれば追加してください。

コンテナホストのいずれかで稼働が必要なシステム領域(B)

システム領域として以下が動作するコントロールプレーンのDeploymentを用意する必要があります。

台数に依存せずいずれかのコンテナホスト内で動作させる必要があります。

	用途	使用数	CPUタイムスライス(ms)※2	メモリ(MB)※1
コントロールプレーン(Deployment)　※2
CoreDNS	DNS機能	2Pod	100	70
Metrics server	クラスター性能管理	1Pod	100	200
ebs-csi-controller	EBS管理用	2Pod	60	240
alb-controller	ALB管理用	2Pod	50	100
コンテナホストに追加で必要なリソースの合計			0.31vCPU	610MB

※1 　記載のCPUやメモリは実際に適用したコンテナ環境で出力したデフォルト値となります。

※2 今回Metrics server、EBS、ALBのコントローラーを入れていますが、必須ではありません。インフラ領域において必要なプラグインなどがあれば追加してください。

EKSの業務領域リソース検討

今回はWebサーバとなるためWebサーバに必要なミドルウェアのCPUとメモリを算出します。

業務領域メモリ算出

メモリを算出するために、移行元システムのメモリ使用量を鑑みて、必要なサイズを算出しています。

※現行のピークメモリ使用率から算出してもよいですが、SWAP領域は設定しないと利用できないことから多少の余力を持たせた方がよい可能性があります。

以下の計算よりWebサーバ1台に最低14GBで余力を見て16GBのメモリを用意します。

■Apache HTTP Server

・Apacheのプロセスのメモリ使用量を確認し、MaxClients数/ServerLimit数から必要メモリ数を計算

例：Apache HTTP Server ：1GB(ServerLimit × プロセスメモリ利用量)

– ServerLimit：35

– 1プロセス :25MB

■Apache Tomcat

・ヒープサイズはApache TomcatのJAVAオプションのXmx(最大ヒープサイズ)確認して算出

・ノンヒープサイズはMaxMetaSpaceSize、ReservedCodeCacheSize、Xss、ThreadStackSizeなどの設定値を確認して算出

例：Apache Tomcat：13GB(Xmx+MaxMetaSpaceSize+ReservedCodeCacheSize)

– Xmx：12GB

– MaxMetaSpaceSize：0.5GB

– ReservedCodeCacheSize：0.5GB

移行元メモリ使用量が不明な場合はApache Tomcat やApache HTTP Server推奨スペックから算出します。

業務領域CPU算出

移行元のシステムがある場合は過去の業務負荷が最も高い時期のCPU使用率を基に算出しましょう。

過去のCPU使用率の最大は4vCPUの60%迄利用していたので、余裕をもって75%としてCPUサイズ(3vCPU)とします。

移行元の使用率が不明な場合はApache Tomcat やApache HTTP Serverの推奨スペックから算出します。

業務領域に必要なリソース(C)

上記のメモリCPUよりWebサーバ1台分に必要なリソースは3vCPU 16GBメモリと定義します。

コンテナホストのサイジング

各リソースの使用状況を合計して最適なインスタンスタイプを選んでいきます。

今回は2AZでの冗長構成となるため、コンテナホスト1台に全てのリソースを稼働させることは考慮に含めておりません。

注意点として業務用のリソースやノード単位で必須リソースが必ず動作できる必要があるため、以下のスペックを最低限満たすインスタンスタイプである必要があります。

・最低メモリ：18GB以上のインスタンスタイプ(コンテナホスト毎に必要なシステム領域(A)のメモリ 2GB+Webサーバ1台業務領域(C)のメモリ 16GB)

・最低CPU：3.9vCPU以上のインスタンスタイプ(コンテナホスト毎に必要なシステム領域(A)のCPU 0.9vCPU+Webサーバ1台業務領域(C)の 3vCPU)

今回は比較対象として4vCPU以上、メモリ32GB以上のインスタンスタイプを3つ選択しています。

※インスタンスタイプ選定において、EKSではいくつか制約があります。「その他の考慮点」をご覧ください。特にt系のインスタンスタイプを選定の際にはPodにセキュリティグループがアタッチできないなどの制約もありますので、ご留意ください。選定後に作り直したPJも実際にありました。)

インスタンススペック「①」からシステム領域(A)「②、③」、(B)「④」、業務領域(C)「⑤」を差し引いて⑥の余剰リソースがマイナスにならなく、

且つWebサーバが3台になるなど将来的なCPUやメモリ拡張余地を鑑みて選定します。

その上で⑦のコストメリットを鑑みた結果、最適なインスタンスタイプ及び台数として「m6g.2xlarge 2台」が妥当だと判断できました。

※お客様がコスト重視の場合には「r6g.xlarge 3台」でも問題ございません。

インスタンスタイプ	台数	①インスタンススペック (台数に比例)		②kubelet (台数に比例)		③DaemonSet (台数に比例)		④Deployment		⑤業務用 Webサーバ2台		⑥余剰リソース ※計算式 ① – (②+③+④+⑤)		⑦インスタンス料金
		–		システム領域(A)		システム領域(A)		システム領域(B)		業務領域(C)		–		–
		vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	1h利用料
r6g.xlarge	1	4	32	0.5	0.1	0.88	2.12	0.31	0.61	6	32	-3.69	-2.83	0.24
	2	8	64	1	0.2	1.76	4.25	0.31	0.61	6	32	-1.05	26.94	0.49
	3	12	96	1.5	0.2	2.64	6.37	0.31	0.61	6	32	1.56	56.82	0.73
r6g.2xlarge	1	8	64	0.5	0.1	0.88	2.12	0.31	0.61	6	32	0.32	29.17	0.49
	2	16	128	1	0.2	1.76	4.25	0.31	0.61	6	32	6.93	90.94	0.97
	3	24	192	1.5	0.2	2.64	6.37	0.31	0.61	6	32	13.56	152.8	1.46
m6g.2xlarge	1	8	32	0.5	0.1	0.88	2.12	0.31	0.61	6	32	0.32	-2.83	0.40
	2	16	64	1	0.2	1.76	4.25	0.31	0.61	6	32	6.93	26.94	0.79
	3	24	96	1.5	0.2	2.64	6.37	0.31	0.61	6	32	13.56	56.82	1.19

適切なインスタンスタイプを決めた後、上記のサイジングで出したものを各インスタンスに実際に割り当てが可能かどうか、1台ずつ並べてシミュレーションしてみます。

今回のようなシンプルな構成ではなく、「⑤業務用」の複数の機能(コンテナ)が動く場合や「④Deployment」のシステム領域(B)が偏った場合でも、問題なく稼働可能することを確認する必要があります。
起動するコンテナが偏ることによって、台数やスペックが不足する可能性があるためです。

以下の表でシミュレーションしてみた結果、コンテナを偏らせた場合でもそれぞれのEC2インスタンスに余剰リソースがあるため、問題ないと判断できます。

インスタンスタイプ	台数	①インスタンススペック (台数に比例)		②kubelet (台数に比例)		③DaemonSet (台数に比例)		④Deployment (1台に偏った場合)		⑤業務用 Webサーバ 1台毎に配置		⑥余剰リソース ※計算式 ① – (②+③+④+⑤)
		–		システム領域(A)		システム領域(A)		システム領域(B)		業務領域(C)		–
		vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)	vCPU (個)	メモリ (GB)
m6g.2xlarge	1台目	8	32	0.5	0.1	0.88	2.12	0.31	0.61	3	16	3.31	13.17
m6g.2xlarge	2台目	8	32	0.5	0.1	0.88	2.12	–	–	3	16	3.62	13.78

構成イメージ

その他考慮点

Podに直接セキュリティグループをアタッチする際のインスタンスタイプ制限

Podに直接セキュリティグループをアタッチする際EC2インスタンスタイプに縛りがあります。

t系のEC2ではこれが上手く出来なくて困ったことがありました。

EKSではよく使う機能なので注意が必要です。

セキュリティグループを個別の Pod に割り当てる – Amazon EKS

可用性の向上

現在はコンテナホスト2台としていますが、EKSの場合コンテナホスト起動とコンテナ(Pod)起動の時間を加味する必要があり、通常EC2より時間がかかることがあります。

RTOが厳しい場合にはサイジングで算出した台数に対して「＋1台」とすることで、コンテナ(Pod)の起動だけで済み、RTOを短縮することができます。

また、SWAP領域はデフォルト設定されていないため、本当に必要となる場合にはコンテナホストのSWAP領域を割り当てることで、メモリあふれによる停止を抑止することができます。

選択可能なインスタンスタイプの留意点

以下のサイトが参考になります。選択可能なインスタンスタイプ、利用可能なPod最大数など見ておくことを推奨します。

最適な Amazon EC2 ノードインスタンスタイプを選択する – Amazon EKS

強化されたオブザービリティの利用

2023年に強化されたオブザービリティが利用可能となりました。

従来のEKSで設定可能なContainer Insightsよりも強化されたオブザービリティの方が見られる要素が多く且つコストも安価となり、

オブザービリティSaaSと同等レベルでダッシュボードが見られることになるため、利用を推奨します。

ただし、2025年2月時点でEKS(AWS Fargate)はまだ未対応のため、EKS(EC2)とする必要があることが注意点となります。

Amazon EKS 向けにオブザーバビリティが強化された Container Insights – Amazon CloudWatch

EKSクラスターの分離検討

EKSクラスターは分離せずに必要な業務に合わせて名前空間を分離したほうがシステム領域リソースを共有化できてコストメリットが大きくなります。

ただし、本番環境、ステージング環境(準本番環境)など業務データが入るような環境ではセキュリティの観点から、独立したセキュリティ境界を定めて開発環境とは別でクラスターを組んだ方が望ましいです。

また、可用性の面でもKubernetesのアップデートやシステム領域のアップデートなどを行う際にも環境分離をすることで影響を最小限にできるため、本番環境、開発環境はまとめてクラスターとしないことを推奨いたします。

参考記事