はじめに:QAテスト環境の課題
「テスト環境を準備してください」という依頼をプラットフォームチームに出してから、30〜45分待つ——日本のSIerやクラウドネイティブな開発現場では、よくある光景ではないでしょうか。特に複数のアプリケーションを同時にテストする必要がある場合、それぞれに専用のAmazon EKSクラスターを立ち上げる必要があり、ALB(Application Load Balancer)、Route 53レコード、モニタリングエージェントまで毎回重複して作成されるため、インフラコストと運用負荷が雪だるま式に増大します。
Deloitteも全く同じ課題を抱えていました。彼らが選んだ解決策は Amazon EKS + vCluster の組み合わせであり、その結果は驚くべきものでした。
- 環境プロビジョニング時間:45分 → 5分未満(89%削減)
- 年間削減時間:約500時間
- vCPU削減:ピーク時で50以上
- メモリ削減:200GB以上
- コスト最適化:Spot Instance活用で最大70%削減
本記事では、Deloitteが実際に使用したアーキテクチャと主要な設定コードを基に、どのようにしてこの成果を達成したのかをステップバイステップで解説します。(参考:Deloitteの原文記事でより詳細な背景を確認できます。)

コアアーキテクチャ:1つのEKSクラスターで複数の仮想クラスターを運用
Deloitteのソリューションは、大きく3つのレイヤーで構成されます。
- ホストクラスター:Amazon EKS Auto Modeが有効なベースクラスター。全てのコンピューティングとネットワーキングリソースを提供します。
- 仮想クラスター(vCluster):ホスト上で動作する軽量Kubernetesクラスター。それぞれが完全に分離されたテスト環境として機能します。
- 共有コントローラー:Load Balancer Controller、Storage Controllerなどがホストに一度だけデプロイされ、全ての仮想クラスターで共有されます。
vClusterのデプロイ(Helmチャート)
実際にvClusterをデプロイするコマンドは以下の通りです。各値はご自身の環境に合わせて修正してください。
export DOMAIN_NAME=<your-domain.com>
export ZONE_ID=<your-route53-zone-id>
export CERTIFICATE_ARN=$(aws acm request-certificate \
--domain-name $DOMAIN_NAME \
--validation-method DNS \
--output text)
# 証明書検証レコードの作成
CERT_NAME=$(aws acm describe-certificate \
--certificate-arn $CERTIFICATE_ARN \
--query 'Certificate.DomainValidationOptions[0].ResourceRecord.Name' \
--output text)
CERT_VALUE=$(aws acm describe-certificate \
--certificate-arn $CERTIFICATE_ARN \
--query 'Certificate.DomainValidationOptions[0].ResourceRecord.Value' \
--output text)
aws route53 change-resource-record-sets \
--hosted-zone-id $ZONE_ID \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "'"$CERT_NAME"'",
"Type": "CNAME",
"TTL": 300,
"ResourceRecords": [{"Value": "'"$CERT_VALUE"'"}]
}
}]
}'
vCluster Helmチャートのインストール
helm repo add loft https://charts.loft.sh
helm repo update
helm upgrade --install vcluster-pro loft/vcluster \
--namespace vcluster-platform \
--create-namespace \
--set admin.create=true \
--set admin.username=admin \
--set admin.password=<your-password> \
--set ingress.enabled=true \
--set ingress.name=loft-ingress \
--set ingress.annotations."alb\.ingress\.kubernetes\.io/subnets"="<subnet-1>,<subnet-2>" \
--set ingress.annotations."alb\.ingress\.kubernetes\.io/certificate-arn"=$CERTIFICATE_ARN \
--set ingress.annotations."alb\.ingress\.kubernetes\.io/scheme"=internet-facing \
--set ingress.annotations."alb\.ingress\.kubernetes\.io/load-balancer-name"=vcluster-alb \
--set ingress.host=$DOMAIN_NAME \
--set ingress.path="/*" \
--set ingress.ingressClass=alb \
--set ingress.tls.enabled=false
注意:
admin.passwordは必ず強力なパスワードに変更してください。デフォルト値のまま使用するとセキュリティ上危険です。

仮想クラスターの作成とアプリケーションのデプロイ
vClusterプラットフォームがデプロイされると、Web UIにアクセスして仮想クラスターを作成できます。各仮想クラスターは完全なKubernetes APIを提供するため、通常のkubectlコマンドで制御可能です。
仮想クラスターのYAML設定
# vcluster.yaml
sync:
fromHost:
ingressClasses:
enabled: true
storageClasses:
enabled: true
toHost:
ingresses:
enabled: true
controlPlane:
coredns:
enabled: true
embedded: true
この設定が重要な理由は以下の通りです。
fromHost.ingressClasses.enabled: ホストのIngressClassを仮想クラスターで使用可能にします。fromHost.storageClasses.enabled: ホストのStorageClassを仮想クラスターで使用可能にします。toHost.ingresses.enabled: 仮想クラスターで作成されたIngressリソースをホストに同期し、1つのALBで複数の仮想クラスターのトラフィックを受信できるようにします。
仮想クラスターへのアプリケーションデプロイ
# app-deployment.yaml
apiVersion: v1
kind: Namespace
metadata:
name: echoserver
---
apiVersion: v1
kind: Service
metadata:
name: echoserver
namespace: echoserver
spec:
ports:
- port: 80
targetPort: 8080
selector:
app: echoserver
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: echoserver
namespace: echoserver
spec:
replicas: 1
selector:
matchLabels:
app: echoserver
template:
metadata:
labels:
app: echoserver
spec:
containers:
- image: hashicorp/http-echo:latest
name: echoserver
args:
- "-text=Hello from App1"
ports:
- containerPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: echoserver
namespace: echoserver
annotations:
alb.ingress.kubernetes.io/certificate-arn: <your-cert-arn>
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/group.order: "-999"
spec:
ingressClassName: alb
rules:
- host: <your-domain.com>
http:
paths:
- path: /app1
pathType: ImplementationSpecific
backend:
service:
name: echoserver
port:
number: 80
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-claim
namespace: echoserver
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: auto-ebs-sc
ヒント:
alb.ingress.kubernetes.io/group.orderを調整することで、複数の仮想クラスターのIngressルールがALBに追加される際の優先順位を制御できます。デフォルト値は0で、負の値はより高い優先順位を持ちます。
2つ目の仮想クラスターにも同様にデプロイする場合は、path: /app2とargsのテキストを変更してください。

日本市場における適用コンテキストと注意点
日本のSI/スタートアップ環境でのメリット
- 開発環境の分離: 複数プロジェクトを同時進行するSI環境で、プロジェクトごとに完全に分離されたテスト環境を提供できます。
- コスト削減: 1つのEKSクラスターで複数の環境を運用するため、AWSコストを大幅に削減できます。特に日本の中小企業にとって魅力的なオプションです。
- セルフサービス: プラットフォームチームの介入なしにQAチームが直接環境を作成できるため、業務効率が最大化されます。
注意点と制限
- vClusterのオーバーヘッド: vClusterは完全な分離を提供しますが、ホストクラスターのリソースを共有するため、ホストに障害が発生すると全ての仮想クラスターに影響が及びます。したがって、ホストクラスターの安定性が非常に重要です。
- ネットワーク分離レベル: vClusterはネットワークレベルでの完全な分離を保証しません。セキュリティが重要な環境では、追加のNetworkPolicyを適用する必要があります。
- Auto Modeのコスト: Amazon EKS Auto Modeは便利ですが、ノードグループを直接管理するよりもコストが高くなる可能性があります。使用パターンに応じて検討が必要です。
- ライセンス: vCluster Community Editionは無料ですが、vCluster Platform(プロバージョン)は13日間のトライアル後に有料です。長期的に使用する場合はライセンス費用を考慮する必要があります。
次のステップとしての学習方向
- EKS Auto Modeの公式ドキュメントで詳細な設定を学びましょう。
- vClusterの公式ドキュメントで様々な同期オプションを確認してください。
- 実際のプロジェクトに適用する前に、簡単なPoC(Proof of Concept)を通じて、ご自身の環境でのパフォーマンスと安定性をテストすることをお勧めします。