AWS Quantum/HPC Vol1｜Braket×ParallelCluster×Nitro

§1 なぜ Quantum/HPC Vol1 か — 第21軸目起点 + AWS先端アーキテクチャ階層 + ナビ

AWS本番運用シリーズは、ここまで20軸 (IAM / EKS / 復旧 / AI×3 / Security×3 / コスト / Multi-Account /
Observability×3 / Network×2 / DevOps×3 / Database×4 / Serverless×2 / Container×3 / Storage×2 /
Edge / Analytics / Migration / IoT×2 / Game-Media) の本番運用知見を蓄積してきた。
これらは「クラウド上で動く一般的なワークロード」の本番運用を扱うものであり、
そのほとんどは仮想化された EC2 / コンテナ / マネージドサービスの組み合わせで実装されてきた。

しかし、AWS が提供する計算リソースは「仮想化されたインスタンス」だけではない。
– 量子コンピューティング — 古典コンピュータでは時間がかかる問題を量子ビットで解く Amazon Braket
– HPC (高性能計算) — 数千〜数万コアを協調動作させる ParallelCluster / AWS Batch HPC
– Bare metal / Nitro System — 仮想化オーバーヘッドゼロの物理サーバ直接利用

この3領域は「先端領域」と呼ばれ、創薬・気候シミュレーション・金融リスク計算・
ゲーノム解析・量子化学・流体力学・暗号解析といった、
従来の一般的なクラウドワークロードでは扱えなかった計算問題を解くために利用される。

本記事 Quantum/HPC本番運用 Vol1 は、AWS本番運用シリーズの第21軸目として、
この先端領域 (Quantum + HPC + Bare metal) を1本に統合し、本番運用視点で体系化する。
– Amazon Braket — 量子ハードウェア4種 (IonQ / Rigetti / IQM / QuEra) を統一 API で扱う本番運用
– ParallelCluster — Slurm スケジューラ + EFA + FSx for Lustre による HPC クラスタの本番運用
– AWS Batch HPC — Compute environment + Multi-node parallel + GPU job による HPC バッチの本番運用
– Nitro System — Nitro Card / Hypervisor / Security Chip / Bare metal / Nitro Enclaves の本番運用

第21軸目を新たに設ける理由

既存20軸は「一般的なクラウドワークロード」を対象としてきた。具体的には、
– Web API / マイクロサービス (Container / Serverless / API Gateway)
– データ基盤 (Database / Analytics / Storage)
– 機械学習推論・学習 (SageMaker / Bedrock)
– 運用基盤 (Observability / Security / DevOps / Multi-Account)

これらは「仮想化された汎用 CPU」を前提とした構成であり、本記事の3領域は
「量子ビット」「数千コア協調」「物理サーバ直接アクセス」という質的に異なる計算リソースを扱う。
このため、既存軸への追加ではなく独立した第21軸目シリーズとして体系化する。

Vol1 (本記事) で「Braket / ParallelCluster / Batch HPC / Nitro」の4本柱を本番運用視点で
俯瞰した後、後続 Vol2/Vol3 では「量子アルゴリズム実装」「HPC ジョブ最適化」「Nitro Enclaves
セキュア計算」「Hybrid Jobs」を縦深化する予定である。

AWS先端アーキテクチャ階層 (4層モデル)

AWS の計算リソースを「仮想化からの距離」で階層化すると、以下の5層に整理できる。

コスト・レイテンシの読み方: L2/L1 は「コアあたりの計算速度」ではなく
「ノード間通信速度」がボトルネックになる。EFA を使った MPI ジョブは単桁 µs の
レイテンシで数千ノードを協調動作させる。L0 (量子) のコストは
「ショット単価 × 実行ショット数」であり、エラー訂正を考慮した実効コストは
単純なショット数計算より格段に高くなる点に注意が必要だ。

L0-L2 を選択する条件: 既存20軸 (L3/L4) で解決できない問題、すなわち
「古典コンピュータの指数時間問題 (量子)」「数千ノード協調 MPI (HPC)」
「ハイパーバイザー 1〜2% オーバーヘッドが許容できない (Bare metal)」のいずれかが
発生したときに初めてこの階層を検討する。むやみな L2/L1 採用はコスト増と
運用複雑性増大を招くアンチパターンである。

本 Vol1 は L0 (量子) / L2 (HPC) / L1 (Bare metal) の3層を横断的に扱う。
既存20軸が主に L3 / L4 を扱ってきたのに対し、本軸は L0-L2 の「下層・先端」を担当する。

想定読者

本記事は以下のいずれかに該当する読者を主な対象としている。

① 量子コンピューティング R&D / PoC 担当
AWS 上で量子回路を動かしたい、あるいは NISQ (Noisy Intermediate-Scale Quantum) デバイスを
使った組合せ最適化 (VQE / QAOA) を本番環境に投入したい研究者・エンジニア。
前提知識として「Python + Boto3 の基本操作」「量子ゲートの概念 (X/H/CNOT 程度)」があれば
本記事の実装例を即座に試せる。量子回路理論の深い知識は §2 範囲では不要である。

② HPC ワークロード移行エンジニア
オンプレミス HPC クラスタ (SGE / PBS / Slurm) を AWS に移行したい、あるいはクラウドネイティブな
HPC 環境を新規構築したいエンジニア。CFD (流体力学) / FEM (有限要素法) / 分子動力学 /
気候シミュレーション / 創薬スクリーニングなどのジョブを扱う担当が典型例だ。
前提知識は「Linux コマンド操作」「MPI の概念 (mpirun / mpiexec)」「EC2 の基本操作」。
Slurm の詳細設定や EFA ドライバの扱い方は §3 で解説する。

③ Bare metal / Nitro Enclaves が必要なアーキテクト
高頻度取引 (HFT) でマイクロ秒レイテンシが要件になる場合、
Oracle Database の raw デバイス I/O 要件がある場合、
VMware/Hyper-V のネスト仮想化が必要な場合、
あるいは機密データ処理 (決済トークン / 生体認証 / 鍵マテリアル) を
ホスト OS から完全隔離したい Security 担当が該当する。
前提知識は「EC2 インスタンスタイプの選定経験」「IAM / KMS の基本操作」。

④ AWS 本番運用シリーズの継続読者
本シリーズを Vol1 (IAM) から読み続けてきた SRE / 上級アーキテクトが
先端領域 (Quantum / HPC / Bare metal) へ知見を広げるための記事としても機能する。
既存20軸の基礎知識 (特に Container / Observability / Network) があると
§2〜§5 の実装例をより深く理解できる。

逆に、本記事は「クラウド入門者」「一般的な Web サービスのみ運用する担当者」は対象外だ。
そうした読者はまず既存20軸 (Container Vol1-3 / Serverless Vol1-2 / Observability Vol1-3) から
読み始め、インフラ基礎を固めることを強く推奨する。本記事はそれらの上位レイヤーとして
設計されており、基礎知識なしに読み進めても実装上の詰まりポイントが理解しにくい。

既存20軸からの移行導線 — どの軸から本軸へ進むべきか

本軸 Quantum/HPC Vol1 は「先端領域」に分類されるため、読者がどの既存軸から
本軸へ移行すべきかの判断が重要だ。以下の優先度順で参照されたい。

優先度A (最優先で移行を検討すべき軸)
– AI/ML 軸 (Vol1-3): SageMaker + Bedrock を使い込んだ後に「GPU 学習の限界突破」
「古典-量子ハイブリッドアルゴリズム」を検討するときに Braket + Hybrid Jobs (§2) が直接役立つ。
– Container 軸 (Vol1-3): EKS / Fargate の上位に「Nitro Bare metal × EKS 高密度ノード」
「i3.metal NVMe 直接マウント」を検討するときに §5 が参照ポイントになる。
– Observability 軸 (Vol1-3): HPC ジョブの可視化 (CloudWatch + Container Insights) や
Braket Task の実行メトリクス監視を Observability Vol3 の知識と組み合わせると §2/§6 が活きる。

優先度B (組み合わせ効果が高い軸)
– Network 軸 (Vol1-2): EFA の高速通信 (単桁 µs MPI) は VPC 設計・プレイスメントグループと
セットで学ぶと §3 の ParallelCluster 設計が深く理解できる。
– Storage 軸 (Vol1-2): FSx for Lustre の Scratch/Persistent 設計は §3 で扱う。
EBS gp3 チューニング知識があると Bare metal の NVMe 構成 (§5) への理解が速まる。
– Security 軸 (Vol1-3): Nitro Enclaves の KMS Attestation (§5) は
Security 軸の「KMS + IAM 最小権限」知識が前提になる。Security Vol3 読了後に §5 を読むと
PCR 値・Attestation Document の意味が腑に落ちる。

優先度C (背景知識として有効)
– DevOps 軸 (Vol1-3): CI/CD パイプラインと PCR0 更新の自動化 (§5 KMS Policy 連動) や
Braket Hybrid Jobs のジョブ管理に CodePipeline を組み合わせる場合に参照。
– コスト最適化軸: Braket の Task per shot 課金モデル / HPC Spot 活用 / Savings Plans との
組み合わせは コスト最適化軸の知識が直接応用できる場面だ (§2 Cost制御 / §3-§4 で言及)。

既存20軸を経由せずに本記事から読み始めることも可能だが、上記優先度Aの軸を
事前に把握しておくと実装上のつまずきが大幅に減る。

本記事の構成

§2 で Amazon Braket (量子) の本番運用を扱い、§3 / §4 で HPC (ParallelCluster + Batch HPC) を、
§5 で Nitro System (Bare metal + Enclaves) を扱う。
§6 で4領域の詰まりポイント7選を判断ツリー化し、§7 で5つのアンチパターン → 正解パターン
変換演習を行う。§8 で第21軸目 Quantum/HPC シリーズ起点宣言 + 51記事化達成告知 + 全21軸
クロスリンクで締めくくる。

§2 Amazon Braket 本番運用 — 量子ハードウェア4種 × Hybrid Jobs × Local Simulator × Cost制御 × Task Queue ★山場1

Amazon Braket 概要 — 古典 API ラッパ + 量子バックエンド統一抽象

Amazon Braket は、異なるベンダーの量子ハードウェアを統一 API で扱えるフルマネージドな
量子コンピューティングサービスである。2019 年にプレビュー公開、2020 年に GA となった。

Braket の設計思想は「量子バックエンドの差異を API レイヤーで吸収する」ことにある。
IonQ (Trapped ion) / Rigetti (Superconducting) / IQM (Superconducting) / QuEra (Neutral atom)
という4種類の異なる物理実装を持つ QPU を、同一の Braket SDK / API で呼び出せる。
加えて、コスト不要でローカル実行できる Simulator (SV1 / DM1 / TN1) も同じ API で利用できる。

Braket の主要コンポーネントは以下の4つだ。

Braket の処理フローは「回路定義 → Task 投入 → キュー待機 → QPU 実行 → S3 結果保存」の
5ステップだ。QPU は共有リソースであり、予約なしの場合はキュー待機時間が
数分〜数十分発生することを考慮した設計が必要だ。

量子ハードウェア4種 比較表 (2026年現役機種)

※ 提供状況・価格は変動するため常に公式ドキュメントで最終確認すること。
Braket コンソールの「Devices」ページに現在の稼働状況とアベイラビリティが表示される。

各デバイスの特性と使い分け:

• IonQ (Aria/Forte): Trapped ion 方式はゲートエラー率が最も低い。
  All-to-all 接続 (任意の Qubit 間で直接ゲート可能) のため回路の最適化が容易。
  ただし実行速度は Superconducting より遅い (µs/ゲート 対 ns/ゲート)。
  アルゴリズム検証・小規模量子化学シミュレーションに適している。

• Rigetti (Ankaa-2): Superconducting 方式は最高速だが近傍接続のみ。
  QPU キャリブレーションを週次で実施するため、実行タイミングによりエラー率が変動する。
  get_device で deviceCapabilities の最新キャリブレーション日時を確認してから投入すること。

• IQM (Garnet): Superconducting 方式 / 欧州 (eu-north-1) 拠点。
  GDPR 管轄内でデータを完結させたい欧州企業向け。20Q の小規模なため
  回路深度の浅いアルゴリズム (QAOA 浅層 / Grover 小規模) に適している。

• QuEra (Aquila): Neutral atom 方式は 256Q で現状最多 Qubit。
  ただしゲートベース量子回路ではなく「アナログモード」 (Rydberg ハミルトニアンの直接制御) のみ。
  組合せ最適化 (Maximum Independent Set / グラフ問題) に特化した使い方が基本となる。

Amazon Braket SDK — Bell State 回路を IonQ / SV1 両バックエンドに投入

import boto3
from braket.aws import AwsDevice, AwsQuantumTask
from braket.circuits import Circuit

# Bell state 回路定義
circuit = Circuit().h(0).cnot(0, 1)

# --- バックエンド1: IonQ Aria (QPU) ---
ionq_device = AwsDevice("arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1")
task_qpu = ionq_device.run(circuit, shots=100, s3_destination_folder=("my-braket-bucket", "results/ionq"))
print(f"QPU Task ARN: {task_qpu.id}")
# QPU はキュー待機があるため非同期で確認
# task_qpu.result() は COMPLETED になるまでブロックするため本番では非推奨
# 代わりに state ポーリングまたは EventBridge → Lambda 通知を使う

# --- バックエンド2: SV1 Simulator (クラウドシミュレーター / 課金あり) ---
sv1_device = AwsDevice("arn:aws:braket:::device/quantum-simulator/amazon/sv1")
task_sv1 = sv1_device.run(circuit, shots=1000, s3_destination_folder=("my-braket-bucket", "results/sv1"))
result = task_sv1.result()
print(result.measurement_counts)
# 出力例: Counter({'00': 503, '11': 497})

# --- バックエンド3: Local Simulator (課金なし / 開発時推奨) ---
from braket.devices import LocalSimulator
local_sim = LocalSimulator()
local_result = local_sim.run(circuit, shots=1000).result()
print(local_result.measurement_counts)

バックエンドの切り替えは AwsDevice の ARN を変えるだけでよい。
この API 統一性が Braket の最大の強みであり、「ローカルで開発 → SV1 で中規模検証 → QPU で本番投入」
というワークフローを同一コードで実現できる。

Local Simulator 使い分け — SV1 / DM1 / TN1

選択指針:
– 開発・デバッグ → Local Simulator (コストゼロ / ~25Q で十分)
– 実機投入前の動作確認 (エラーなし理想状態) → SV1 (34Q / 深層回路)
– 実機エラーモデルの検証 (ノイズ込みシミュレーション) → DM1 (17Q / デポラライズノイズ等)
– 50Q 超の疎構造回路 (QAOA / クラスタ状態) → TN1 (縮約可能な構造限定)

TN1 は「テンソルネットワーク縮約が有効な回路」にしか適用できない。
Dense な回路 (QFT 等) は TN1 では実行できないため、回路の構造を事前に確認すること。

Hybrid Jobs — 古典 (SageMaker/EC2) × 量子 (QPU) を1ジョブにバンドル

Hybrid Jobs は「古典最適化ループ + 量子回路評価」を1つのマネージドジョブとして実行する
機能だ。VQE (Variational Quantum Eigensolver) や QAOA (Quantum Approximate Optimization Algorithm)
のように「古典側がパラメータを更新 → 量子回路を評価 → 結果を古典側にフィードバック」という
反復的なハイブリッドワークフローに最適化されている。

Hybrid Jobs を使わずに Lambda / EC2 で独自にループを実装することもできるが、
以下の機能が組み込まれているためマネージドな Hybrid Jobs の利用を推奨する。

Hybrid Jobs 実装例 — VQE (変分量子固有値ソルバー)

from braket.jobs import hybrid_job, save_job_checkpoint, load_job_checkpoint
from braket.circuits import Circuit, FreeParameter
from braket.aws import AwsDevice
import numpy as np

@hybrid_job(device="arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1", wait_until_complete=False)
def run_vqe(n_iterations: int = 50, shots: int = 100):
 device = AwsDevice("arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1")

 # パラメータ付き ansatz 回路 (RY ゲート × 2 Qubit)
 theta = FreeParameter("theta")
 phi= FreeParameter("phi")
 circuit = Circuit().ry(0, theta).ry(1, phi).cnot(0, 1)

 # チェックポイントから再開 (再実行時の途中再開)
 try:
  checkpoint = load_job_checkpoint("vqe_checkpoint")
  params = checkpoint["params"]
  start_iter = checkpoint["iteration"]
 except Exception:
  params = np.array([0.1, 0.2])
  start_iter = 0

 for i in range(start_iter, n_iterations):
  param_dict = {"theta": params[0], "phi": params[1]}
  task = device.run(circuit, shots=shots, **param_dict)
  result = task.result()
  # エネルギー期待値計算 (Z0 Z1 オブザーバブル)
  counts = result.measurement_counts
  energy = (counts.get("00", 0) + counts.get("11", 0) - counts.get("01", 0) - counts.get("10", 0)) / shots
  # 勾配降下法でパラメータ更新 (パラメータシフトルール)
  params -= 0.1 * np.array([energy, energy])
  # チェックポイント保存
  save_job_checkpoint({"params": params.tolist(), "iteration": i + 1, "energy": energy})

 return {"final_energy": float(energy), "final_params": params.tolist()}

Hybrid Jobs InstanceConfig (YAML)

# Hybrid Jobs の古典側インスタンス設定 (job_definition.yaml)
instanceConfig:
  instanceType: ml.m5.large# 古典最適化ループ用 (必要に応じて GPU インスタンスに変更)
  volumeSizeInGb: 30
checkpointConfig:
  localPath: /opt/braket/checkpoints
  s3Uri: s3://my-braket-bucket/checkpoints/vqe-job/
outputDataConfig:
  s3Path: s3://my-braket-bucket/output/vqe-job/
stoppingCondition:
  maxRuntimeInSeconds: 86400# 最大24時間 (QPU キュー待ち込みの場合)

stoppingCondition.maxRuntimeInSeconds は QPU キュー待機時間を含めた総実行時間を
設定することを忘れずに。QPU が混雑している場合、1回の Task で数時間待機することもある。

Cost 制御 — Task per Shot 課金 / Reservation / Budget Alert / IAM 制限

Braket の課金は「Task per shot 課金」である。1 Task 投入するたびに基本料金が発生し、
そこに shots × ショット単価 が加算される。コスト暴走の典型例は
「デバッグコードが本番QPUに大量 shots を投入し続ける」シナリオだ。

コスト計算モデル

1 Task のコスト = Task 基本料金 + (shots × ショット単価)

例: IonQ Aria で shots=1000 実行した場合
  = $0.30 (Task 基本料) + (1000 × $0.01/shot)
  = $0.30 + $10.00
  = $10.30 / Task

1 Task で shots=1000 の IonQ 実行は $10 超となる。VQE の反復回数が 100 イテレーションなら
合計 $1,000 超になる計算だ。コスト制御の設計を最初から組み込まなければならない。

Reservation (時間帯予約)

Braket Reservation は特定の QPU を「専有スロット (分単位)」で予約する機能だ。
予約した時間帯は他のユーザーと共有せずに QPU を実行できるため、キュー待機ゼロで実行できる。

# Reservation 一覧確認
aws braket search-quantum-tasks \
  --filters "name=deviceArn,values=arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1" \
  --region us-east-1

# Reservation 作成 (IonQ Aria / 2時間予約)
aws braket create-quantum-task-reservation \
  --device-arn "arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1" \
  --duration-in-minutes 120 \
  --start-time "2026-06-01T10:00:00Z" \
  --region us-east-1

Reservation は時間単位で課金されるため、予約した時間内に実行するジョブ数を
事前に見積もっておくこと。予約時間を使い切らなかった場合も課金される。

Budget Alert + IAM 制限でコスト暴走防止

# AWS Budgets で Braket コストアラート設定
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
 "BudgetName": "Braket-Monthly",
 "BudgetLimit": {"Amount": "500", "Unit": "USD"},
 "TimeUnit": "MONTHLY",
 "BudgetType": "COST",
 "CostFilters": {"Service": ["Amazon Braket"]}
  }' \
  --notifications-with-subscribers '[{
 "Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 80.0,
"ThresholdType": "PERCENTAGE"
 },
 "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "ops@example.com"}]
  }]'

IAM Policy で shots 上限を強制する方法はない (Braket はリソースベース制限未対応) が、
SCP (Service Control Policy) で「Reservation なしの QPU 実行を禁止」することで
コスト暴走を組織レベルで防止できる。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyBraketQPUWithoutReservation",
"Effect": "Deny",
"Action": "braket:CreateQuantumTask",
"Resource": "arn:aws:braket:*::device/qpu/*",
"Condition": {
  "Null": {"braket:ReservationArn": "true"}
}
 }
  ]
}

このSCPを適用すると、Reservation ARN を指定しない QPU Task の投入が全アカウントで拒否される。
開発環境では SCP を外し、本番アカウントのみ適用するマルチアカウント設計が推奨だ。

Task Queue 設計 — 優先度 / Cancel / Retry / Timeout

Task ライフサイクルと状態遷移

Braket Task は以下の状態を遷移する。

CREATED → QUEUED → RUNNING → COMPLETED
  ↓
FAILED
  ↓
CANCELLED

状態確認と Cancel は以下のコマンドで行う。

# Task 状態確認
aws braket get-quantum-task \
  --quantum-task-id arn:aws:braket:us-east-1:123456789012:quantum-task/TASK-ID \
  --region us-east-1

# Task キャンセル (QUEUED または RUNNING 中のみ可能)
aws braket cancel-quantum-task \
  --quantum-task-id arn:aws:braket:us-east-1:123456789012:quantum-task/TASK-ID \
  --region us-east-1

Retry / Timeout 設計

QPU Task は FAILED になる可能性がある (デバイスキャリブレーション中 / 一時的なハードウェア障害)。
本番環境では以下のリトライ設計を組み込むこと。

import time
from braket.aws import AwsQuantumTask

def run_task_with_retry(circuit, device, shots: int, max_retries: int = 3, timeout_sec: int = 7200):
 for attempt in range(max_retries):
  task = device.run(circuit, shots=shots)
  deadline = time.time() + timeout_sec
  while time.time() < deadline:
state = task.state()
if state == "COMPLETED":
 return task.result()
if state in ("FAILED", "CANCELLED"):
 print(f"Attempt {attempt+1} failed with state={state}. Retrying...")
 break
time.sleep(30)  # 30秒ポーリング
  else:
task.cancel()
print(f"Attempt {attempt+1} timed out. Retrying...")
 raise RuntimeError(f"Task failed after {max_retries} attempts")

timeout_sec のデフォルト推奨は 2 時間 (7200 秒)。QPU が混雑している場合に
QUEUED 状態のまま長時間待機することがあるため、Timeout を設定せずに無限待機する
実装は本番環境では禁忌だ。

§3 ParallelCluster 本番運用 — Cluster Config × Slurm Scheduler × Auto-scaling × EFA × FSx for Lustre

3-1 ParallelCluster 概要 — CloudFormation バックエンド + pcluster CLI

Amazon ParallelCluster は AWS が提供するオープンソースの HPC クラスタ自動構築・管理ツールである。
内部的に AWS CloudFormation をバックエンドとして使用し、pcluster CLI から YAML 形式の設定ファイル1つで
Head node / Compute fleet / ストレージ (EFS / FSx for Lustre) / ネットワーク (EFA / Placement Group)
を一括デプロイする。v3 系 (2021〜現在) では設定ファイルが JSON から YAML に刷新され、可読性が大幅に向上した。

主なデプロイコマンド:

# クラスタ作成 (CloudFormation スタック展開 / 10〜20分)
pcluster create-cluster \
  --cluster-name hpc-prod \
  --cluster-configuration cluster-config.yaml

# クラスタ状態確認
pcluster describe-cluster --cluster-name hpc-prod

# Head node SSH 接続
pcluster ssh --cluster-name hpc-prod -i ~/.ssh/hpc-keypair.pem

# クラスタ削除
pcluster delete-cluster --cluster-name hpc-prod

クラスタ作成から Slurm 利用可能状態になるまでの典型的な所要時間は 10〜20 分である。
本番運用では CodePipeline + Lambda から pcluster コマンドを呼び出し、
「ジョブ投入 → クラスタ作成 → 実行 → 結果保存 → クラスタ削除」のライフサイクルを自動化する。

3-2 Cluster Config — Head node × Compute fleet × Queue 設計

クラスタ設定の核心は YAML 形式の cluster-config.yaml であり、以下の構成が本番の標準形となる。

Region: ap-northeast-1
Image:
  Os: alinux2023
HeadNode:
  InstanceType: m6i.xlarge
  Networking:
 SubnetId: subnet-0123456789abcdef0
  Ssh:
 KeyName: hpc-keypair
  LocalStorage:
 RootVolume:
Size: 500
Scheduling:
  Scheduler: slurm
  SlurmQueues:
 - Name: ondemand-q
ComputeResources:
  - Name: hpc6a-od
 InstanceType: hpc6a.48xlarge
 MinCount: 0
 MaxCount: 64
 Efa:
Enabled: true
Networking:
  SubnetIds:
 - subnet-0123456789abcdef0
  PlacementGroup:
 Enabled: true
 - Name: spot-q
ComputeResources:
  - Name: hpc6a-spot
 InstanceType: hpc6a.48xlarge
 MinCount: 0
 MaxCount: 256
 Efa:
Enabled: true
 CapacityType: SPOT
Networking:
  SubnetIds:
 - subnet-0123456789abcdef0
  PlacementGroup:
 Enabled: true
SharedStorage:
  - MountDir: /lustre
 Name: fsx-lustre-prod
 StorageType: FsxLustre
 FsxLustreSettings:
StorageCapacity: 4800
DeploymentType: SCRATCH_2
ImportPath: s3://my-hpc-bucket/input/
ExportPath: s3://my-hpc-bucket/output/

Head node 設計の重要事項:

Head node は Single-AZ 固定であり、Multi-AZ 構成はサポートされない (= SPOF)。
インスタンスタイプは m6i.xlarge 以上を推奨し、
512 ノードを超える大規模クラスタでは m6i.4xlarge 以上を選択する。
EBS ルートボリュームは最低 500 GB を確保し、Slurm accounting ログの肥大化に備える。

Compute fleet — HPC 専用インスタンス:

Queue は ondemand-q (SLA あり・長時間 MPI) と spot-q (コスト優先・中断耐性あり) の2本に分離する。
hpc6a / hpc7a はキャパシティが特定 AZ に集中するため、Placement Group + Cluster Placement で物理近接配置を指定する。

3-3 Slurm Scheduler Tuning — Partition × QoS × Priority

QoS + PreemptType の設定:

# QoS 追加 (Head node 上 sacctmgr で実行)
sacctmgr add qos high_priority MaxJobsPerUser=10 Priority=1000
sacctmgr add qos normal Priority=500
sacctmgr add qos low_priority Priority=100

# Partition への QoS バインド
scontrol update PartitionName=ondemand-q QoS=high_priority,normal
scontrol update PartitionName=spot-q QoS=normal,low_priority

PreemptType=preempt/qos を設定することで、high_priority QoS のジョブが low_priority のジョブを
REQUEUE (強制保留) してキャパシティを獲得できる。pcluster では CustomActions の post_install スクリプトで
slurm.conf への追記として実装する。

本番運用でよく使う Slurm コマンド:

# ジョブ投入 (4ノード × 96コア / EFA MPI / ondemand-q)
sbatch --nodes=4 --ntasks-per-node=96 \
  --partition=ondemand-q --time=12:00:00 \
  --qos=high_priority --output=/lustre/logs/%j.out \
  sample-mpi.slurm

# ジョブ状態確認
squeue -u $(whoami) --format="%.18i %.9P %.8j %.2t %.10M %.6D %R"

# ノード状態確認 (IDLE / ALLOC / DRAIN / DOWN)
sinfo -N -l

# ジョブ詳細 (割り当てノード / 終了コード)
scontrol show job <JOBID>

MPI ジョブの sbatch スクリプト例:

#!/bin/bash
#SBATCH --nodes=8
#SBATCH --ntasks-per-node=96
#SBATCH --partition=ondemand-q
#SBATCH --time=06:00:00
#SBATCH --qos=high_priority
#SBATCH --output=/lustre/logs/%j.out
#SBATCH --error=/lustre/logs/%j.err

module load openmpi
export FI_EFA_USE_DEVICE_RDMA=1
export OMPI_MCA_btl=^vader,tcp,openib
export OMPI_MCA_pml=^cm

mpirun -np 768 ./cfd_solver \
  --input /lustre/input/mesh.dat \
  --output /lustre/output/result.dat \
  --timesteps 10000

3-4 Auto-scaling — Idle Scale-down × Spot Integration

Idle Scale-down (デフォルト 10 分):

ParallelCluster の Slurm インテグレーションは、アイドル状態のコンピュートノードを自動シャットダウンする。
デフォルトの SuspendTimeout=600 (10 分) を短縮することでコスト削減効果が大きい。

# Head node の slurm.conf を確認
grep SuspendTimeout /opt/slurm/etc/slurm.conf

# アイドルタイムアウトを 3 分に短縮後、Slurm に反映
sudo sed -i 's/SuspendTimeout=600/SuspendTimeout=180/' \
  /opt/slurm/etc/slurm.conf
sudo scontrol reconfigure

p4d.24xlarge (約 $32/時) のような高コストインスタンスでは、3分短縮の効果が顕著である。

Spot Integration と自動 Re-queue:

Spot キューで実行中のジョブが Spot interruption (2分前通知) を受けた場合、
ParallelCluster の Slurm インテグレーションが以下を自動実行する。

1. IMDS から Spot interruption シグナルを検知
2. 対象ノードに scontrol update NodeName=<node> State=DRAIN を発行
3. ノード上のジョブに REQUEUE シグナルを送信 → ジョブがペンディング状態に戻る
4. 別の Spot ノードが起動後、ジョブが自動再開

長時間 MPI ジョブ (>2時間) は ondemand-q で実行し、Spot は中断耐性のある
パラメータスイープ・モンテカルロに限定することを強く推奨する。

3-5 EFA — Elastic Fabric Adapter × MPI 高速通信

EFA (Elastic Fabric Adapter) は AWS が独自開発した高速ネットワークインターフェースであり、
OS バイパスの RDMA (Remote Direct Memory Access) を実現する。libfabric ライブラリをバックエンドとし、
OpenMPI / Intel MPI / MPICH および NCCL から透過的に利用できる。

EFA 有効化の設定:

ComputeResources:
  - Name: hpc6a-efa
 InstanceType: hpc6a.48xlarge
 Efa:
Enabled: true
GdrSupport: false
Networking:
  PlacementGroup:
 Enabled: true

ENA + EFA driver 同居の罠 (Driver version mismatch):

カスタム AMI を使用する場合、ENA ドライバと EFA ドライバのバージョン整合を必ず確認する。
ENA が EFA より新しいバージョンだと、カーネルモジュール競合により EFA 通信が TCP fallback する事例がある。

# EFA driver バージョン確認
modinfo efa | grep version

# EFA インストール状態確認 (libfabric でプロバイダ認識)
fi_info -p efa

# EFA 帯域測定 (疎通確認)
fi_pingpong -p efa

# OpenMPI の EFA 設定 (ジョブスクリプトに追加)
export FI_PROVIDER=efa
export FI_EFA_USE_DEVICE_RDMA=1
export OMPI_MCA_btl=^vader,tcp,openib
export OMPI_MCA_pml=^cm

カスタム AMI では aws-efa-installer スクリプトを使って ENA/EFA 両ドライバを同時更新する。
EFA が利用可能なインスタンスは hpc6a / hpc7a / c5n / c6gn / p4d / p5 など限定されており、
汎用インスタンス (m6i / r6i 等) では EFA は利用できない。

3-6 FSx for Lustre — Scratch × Persistent × S3 連携 × HSM

Scratch vs Persistent の選択基準:

HPC ジョブが 48 時間以内なら SCRATCH_2、長期的にシミュレーション結果を蓄積するなら PERSISTENT_2 を選択する。

S3 連携 (DataRepositoryAssociation):

FsxLustreSettings:
  StorageCapacity: 4800
  DeploymentType: SCRATCH_2
  DataRepositoryAssociations:
 - BatchImportMetaDataOnCreate: true
DataRepositoryPath: s3://my-hpc-bucket/input/
FileSystemPath: /lustre/input
AutoImportPolicy:
  Events: [NEW, CHANGED, DELETED]
AutoExportPolicy:
  Events: [NEW, CHANGED, DELETED]

S3 バケットの変更が自動的に FSx for Lustre に反映 (AutoImport) され、
FSx for Lustre の変更が S3 に自動エクスポート (AutoExport) される。

HSM (Hierarchical Storage Management):

アクセス頻度の低いファイルを S3 にアーカイブし、アクセス時に透過的に復元する。

# ファイルの HSM 状態確認
lfs hsm_state /lustre/input/mesh.dat

# S3 への手動アーカイブ
lfs hsm_archive /lustre/output/result_20260524.dat

# S3 からの透過的復元
lfs hsm_restore /lustre/output/result_20260524.dat

§4 AWS Batch HPC 本番運用 — Compute Environment × Job Queue × Job Definition × Multi-node Parallel × GPU Job

4-1 概要 — ParallelCluster との使い分け基準

AWS Batch は、コンテナベースのジョブスケジューリングサービスであり、
Compute environment + Job queue + Job definition の3要素でジョブ実行を管理する。
HPC ワークロードにおける AWS Batch (Batch HPC) の位置付けは、
ParallelCluster (持続クラスタ) との対比で理解すると明確になる。

使い分け基準:
– ParallelCluster を選ぶ場合: 長時間 (>4時間) MPI ジョブが主体 / Slurm QoS 制御が必要 / 既存 HPC ソフトウェア資産
– AWS Batch HPC を選ぶ場合: 多数の小ジョブを並列実行 / コンテナで完結 / Spot を最大活用 / ジョブ駆動でクラスタ不要

4-2 Compute Environment — Managed × Spot × Allocation Strategy

Compute Environment の定義:

{
  "computeEnvironmentName": "hpc-ce-spot",
  "type": "MANAGED",
  "state": "ENABLED",
  "computeResources": {
 "type": "SPOT",
 "allocationStrategy": "SPOT_CAPACITY_OPTIMIZED",
 "minvCpus": 0,
 "maxvCpus": 4096,
 "instanceTypes": [
"hpc6a.48xlarge",
"c5n.18xlarge",
"p4d.24xlarge"
 ],
 "subnets": ["subnet-0123456789abcdef0"],
 "securityGroupIds": ["sg-0123456789abcdef0"],
 "instanceRole": "arn:aws:iam::123456789012:instance-profile/AmazonEC2ContainerServiceforEC2Role",
 "placementGroup": "hpc-placement-group"
  }
}

Allocation Strategy の選択:

Spot 使用時は SPOT_CAPACITY_OPTIMIZED を選択し、instanceTypes に複数タイプを列挙して中断リスクを分散させる。

4-3 Job Queue — 優先度 × Compute Environment 多重バインド

1つの Job queue に複数の Compute environment をバインドし、
Spot 枯渇時に自動的に On-demand にフォールバックする設計が本番の定石である。

{
  "jobQueueName": "hpc-queue-high",
  "state": "ENABLED",
  "priority": 1000,
  "computeEnvironmentOrder": [
 {
"order": 1,
"computeEnvironment": "hpc-ce-spot"
 },
 {
"order": 2,
"computeEnvironment": "hpc-ce-ondemand"
 }
  ]
}

優先度 (priority) が高い Job queue が先にジョブを取得する。
本番では high (priority=1000) / normal (priority=500) / low (priority=100) の3段階が標準的。

4-4 Job Definition — Container × Multi-node Parallel × Parameters 汎用化

{
  "jobDefinitionName": "hpc-mpi-job",
  "type": "multinode",
  "nodeProperties": {
 "numNodes": 8,
 "mainNode": 0,
 "nodeRangeProperties": [
{
  "targetNodes": "0:",
  "container": {
 "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/hpc-mpi:latest",
 "vcpus": 96,
 "memory": 196608,
 "privileged": false,
 "linuxParameters": {
"devices": [
  {
 "hostPath": "/dev/infiniband/uverbs0",
 "containerPath": "/dev/infiniband/uverbs0",
 "permissions": ["READ", "WRITE", "MKNOD"]
  }
],
"sharedMemorySize": 4096
 },
 "environment": [
{"name": "FI_PROVIDER", "value": "efa"},
{"name": "FI_EFA_USE_DEVICE_RDMA", "value": "1"},
{"name": "OMPI_MCA_btl", "value": "^vader,tcp,openib"}
 ],
 "mountPoints": [
{
  "containerPath": "/lustre",
  "readOnly": false,
  "sourceVolume": "lustre"
}
 ],
 "volumes": [
{"name": "lustre", "host": {"sourcePath": "/lustre"}}
 ]
  }
}
 ]
  },
  "parameters": {
 "inputPath": "/lustre/input/default.dat",
 "outputPath": "/lustre/output/result.dat",
 "timesteps": "10000"
  },
  "retryStrategy": {
 "attempts": 3,
 "evaluateOnExit": [
{"onExitCode": "0", "action": "EXIT"},
{"onExitCode": "1", "action": "EXIT"}
 ]
  }
}

parameters フィールドで Job definition を汎用化し、異なる入力データ・パラメータを持つジョブを
同一 Job definition から投入できる。

# パラメータ差し替えでジョブ投入
aws batch submit-job \
  --job-name "cfd-run-20260524" \
  --job-queue hpc-queue-high \
  --job-definition hpc-mpi-job \
  --parameters inputPath=/lustre/input/mesh-v2.dat,timesteps=20000

4-5 Multi-node Parallel Job — MPI × NCCL × EFA

AWS Batch の Multi-node parallel job は、複数のコンテナ (複数の EC2 インスタンス上の ECS タスク) を
協調動作させる仕組みである。mainNode (index=0) が MPI の master プロセスとして動作し、
残りのノード (index=1〜N-1) が worker プロセスとして協調する。

AWS Batch は起動時に以下の環境変数をコンテナに自動注入する。

MPI 起動スクリプト例 (entrypoint.sh):

#!/bin/bash
set -euo pipefail

NODE_INDEX="${AWS_BATCH_JOB_NODE_INDEX}"
NUM_NODES="${AWS_BATCH_JOB_NUM_NODES}"

if [ "${NODE_INDEX}" -eq 0 ]; then
  sleep 10
  for i in $(seq 0 $((NUM_NODES - 1))); do
 echo "worker-${i}" >> /tmp/hostfile
  done
  mpirun -np $((NUM_NODES * 96)) \
 --hostfile /tmp/hostfile \
 -x FI_PROVIDER=efa \
 -x FI_EFA_USE_DEVICE_RDMA=1 \
 /app/cfd_solver
else
  /usr/sbin/sshd -D
fi

4-6 GPU Job — Instance Type × NVIDIA Driver × DCGM 監視

GPU インスタンスの選択:

nvidia-smi によるジョブ前検証:

# GPU 認識確認
nvidia-smi --query-gpu=name,memory.total,driver_version \
  --format=csv,noheader

# プロセス確認 (他のジョブが GPU を占有していないか)
nvidia-smi --query-compute-apps=pid,used_memory --format=csv,noheader

DCGM (Data Center GPU Manager) によるヘルスチェック:

# DCGM ヘルスチェック (レベル1: 基本診断 / ジョブ前に必ず実行)
dcgmi diag -r 1

# GPU メモリエラー監視 (XID エラー)
dcgmi health -g 0 -j

# DCGM エクスポーター (Prometheus 連携)
dcgm-exporter \
  -f /etc/dcgm-exporter/dcp-metrics-included.csv &

Terraform で Batch Compute Environment + Job Queue を管理:

resource "aws_batch_compute_environment" "hpc_spot" {
  compute_environment_name = "hpc-ce-spot"
  type= "MANAGED"
  state  = "ENABLED"

  compute_resources {
 type = "SPOT"
 allocation_strategy = "SPOT_CAPACITY_OPTIMIZED"
 max_vcpus  = 4096
 min_vcpus  = 0
 instance_type = ["hpc6a.48xlarge", "c5n.18xlarge", "p4d.24xlarge"]
 spot_iam_fleet_role = aws_iam_role.spot_fleet.arn
 instance_role = aws_iam_instance_profile.batch.arn
 subnets = [aws_subnet.hpc.id]
 security_group_ids  = [aws_security_group.hpc.id]
 placement_group  = aws_placement_group.hpc.name
  }

  service_role = aws_iam_role.batch_service.arn
}

resource "aws_batch_job_queue" "hpc_high" {
  name  = "hpc-queue-high"
  state = "ENABLED"
  priority = 1000

  compute_environment_order {
 order= 1
 compute_environment = aws_batch_compute_environment.hpc_spot.arn
  }

  compute_environment_order {
 order= 2
 compute_environment = aws_batch_compute_environment.hpc_ondemand.arn
  }
}

§5 Nitro System 本番運用 — Nitro Card × Hypervisor × Security Chip × Bare Metal × Nitro Enclaves ★山場2

Nitro System 概要 — 仮想化の常識を覆すアーキテクチャ

AWS が 2017 年に導入した Nitro System は、EC2 の仮想化基盤を根本から刷新したアーキテクチャである。
従来の Xen ハイパーバイザーベース EC2 では「ホスト OS → ハイパーバイザー → ゲスト OS」という
3 層構造を経由するため、ネットワーク I/O やストレージ I/O において CPU サイクルが消費されていた。

Nitro System はこの問題を 専用 ASIC (Nitro Card) + 軽量 KVM ハイパーバイザー + Security Chip
の組み合わせで解決した。NW/Storage 処理を専用シリコンに offload することで、
ゲスト OS が利用できる vCPU と DRAM をほぼ 100% ワークロードに割り当てることが可能になった。

Nitro System は以下の3コンポーネントで構成される。

Nitro Card (専用 ASIC) — 3種の役割分担

Nitro Card の最大の特徴は処理がゲスト OS から完全に透過な点だ。
ゲスト OS は通常の NVMe/ENA デバイスとして認識するが、実際の処理は CPU を消費しない。
c7i.48xlarge (192 vCPU) で「ネットワーク 50 Gbps + CPU 100% 同時稼働」が実現できるのは
この offload アーキテクチャによる。

Nitro Hypervisor — 旧 Xen EC2 との比較

Nitro Security Chip — Root of Trust

Nitro Security Chip はマザーボードに直接実装された専用チップで、以下の機能を提供する。

• Secure Boot: ファームウェア → ブートローダー → カーネルの署名検証チェーン
• Measured Boot: 起動の各段階 (Bootloader / Kernel / initramfs / Enclave) をハッシュ値で測定し PCR に記録
• KMS Attestation の根拠: Nitro Enclaves が KMS に鍵取得をリクエストする際、PCR 値が根拠となる
• ファームウェア改竄検知: OS レベルから到達不可能なレイヤーで常時検証

Nitro System 公式ドキュメント — Nitro Enclaves User Guide (AWS)

Bare Metal インスタンス — ハイパーバイザーなし物理サーバ直接アクセス

Bare metal インスタンスはハイパーバイザーを完全にバイパスして物理サーバのリソースに直接アクセスできる。

i3.metal 起動 + Nitro CLI セットアップ

# Nitro Enclaves 有効化オプション付きで i3.metal 起動
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type i3.metal \
  --key-name my-keypair \
  --subnet-id subnet-12345678 \
  --security-group-ids sg-12345678 \
  --enclave-options 'Enabled=true' \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=nitro-bare-metal}]'

# nitro-cli インストール (Amazon Linux 2023)
sudo dnf install -y aws-nitro-enclaves-cli aws-nitro-enclaves-cli-devel
sudo usermod -aG ne ec2-user
sudo systemctl enable --now nitro-enclaves-allocator.service

# Enclave へ割り当てる CPU/メモリを設定 (/etc/nitro_enclaves/allocator.yaml)
# cpu_count: 2  ← 偶数必須
# memory_mib: 512
sudo systemctl restart nitro-enclaves-allocator.service

Bare metal が必須になるシナリオ:

Nitro Enclaves — Confidential Computing の実装

Nitro Enclaves は、親インスタンスの vCPU と DRAM の一部を切り出した完全隔離 VM である。

Nitro Enclaves ビルドと起動

# EIF (Enclave Image Format) ビルド — Dockerfile から変換
nitro-cli build-enclave \
  --docker-uri my-enclave-app:latest \
  --output-file my-enclave.eif
# 出力例:
# {
#"Measurements": {
#  "PCR0": "ab12cd34ef56...96文字hex",  <- イメージ全体ハッシュ (KMS Policy に登録必須)
#  "PCR1": "0000...0000",<- カーネル+ブートRAMfsのハッシュ
#  "PCR2": "ab12cd34ef56..."<- アプリのハッシュ
#}
# }

# Enclave 起動 (CID=16 を割当)
nitro-cli run-enclave \
  --cpu-count 2 \
  --memory 512 \
  --enclave-cid 16 \
  --eif-path my-enclave.eif

# 稼働状態確認
nitro-cli describe-enclaves
# [{"EnclaveID":"i-xxx:enc-xxx","EnclaveCID":16,"State":"RUNNING",...}]

# 停止
nitro-cli terminate-enclave --enclave-id i-xxx:enc-xxx

Nitro Enclaves 通信 — vsock (Virtual Socket)

vsock は VM 間通信専用のソケットで TCP/IP スタックを経由しないため VPC/Security Group に影響されない。

import socket
import json

# 親インスタンス側 — Enclave へリクエスト送信
def send_to_enclave(cid: int, port: int, payload: dict) -> dict:
 sock = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM)
 sock.connect((cid, port))
 message = json.dumps(payload).encode()
 sock.sendall(len(message).to_bytes(4, "big") + message)
 length = int.from_bytes(sock.recv(4), "big")
 response = sock.recv(length)
 sock.close()
 return json.loads(response)

result = send_to_enclave(cid=16, port=5000, payload={"operation": "decrypt", "ciphertext": "base64..."})

Nitro Enclaves KMS Attestation — Terraform 実装

# EC2 インスタンス (Nitro Enclaves 有効化)
resource "aws_instance" "nitro_enclave" {
  ami  = "ami-0abcdef1234567890"
  instance_type = "m6i.metal"

  enclave_options {
 enabled = true
  }

  iam_instance_profile= aws_iam_instance_profile.enclave.name
  subnet_id  = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.enclave.id]

  root_block_device {
 volume_type = "gp3"
 volume_size = 100
  }
}

# KMS Key — PCR0 attestation 条件付き
resource "aws_kms_key" "enclave" {
  description = "KMS key for Nitro Enclave attestation"
  deletion_window_in_days = 30
  policy= data.aws_iam_policy_document.enclave_kms.json
}

data "aws_iam_policy_document" "enclave_kms" {
  statement {
 sid = "KeyAdministration"
 effect = "Allow"
 principals {
type  = "AWS"
identifiers = ["arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"]
 }
 actions= ["kms:*"]
 resources = ["*"]
  }

  # Enclave のみが Decrypt 可 — PCR0 値が一致した場合のみ許可
  statement {
 sid = "EnclaveDecryptOnly"
 effect = "Allow"
 principals {
type  = "AWS"
identifiers = [aws_iam_role.enclave.arn]
 }
 actions= ["kms:Decrypt"]
 resources = ["*"]
 condition {
test  = "StringEqualsIgnoreCase"
variable = "kms:RecipientAttestation:ImageSha384"
values= ["PCR0_96CHAR_HEX_FROM_BUILD_OUTPUT"]
 }
  }
}

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "EnclaveDecryptWithAttestation",
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::123456789012:role/nitro-enclave-role"
},
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
  "StringEqualsIgnoreCase": {
 "kms:RecipientAttestation:ImageSha384": "ab12cd34ef5678901234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"
  }
}
 }
  ]
}

kms:RecipientAttestation:ImageSha384 は nitro-cli build-enclave 実行時に出力される PCR0 値と
完全一致しなければ KMS は Decrypt を拒否する。Enclave イメージを 1 行でも変更して再ビルドすると
PCR0 が変わるため、KMS Key Policy 更新を CI/CD パイプラインに必ず組み込むこと。

§6 詰まりポイント7選 図解 (Mermaid01 判断ツリー)

Braket / ParallelCluster / AWS Batch HPC / Nitro System の4領域で現場が実際に遭遇する
7つの詰まりポイントを体系化する。以下の判断ツリーで自分のトラブルを特定し、
各パターンの対処法を参照されたし。

graph TD
  A[トラブル発生] --> B{領域を特定}
  B --> C[Amazon Braket]
  B --> D[ParallelCluster]
  B --> E[AWS Batch HPC]
  B --> F[Nitro System]

  C --> C1{コスト急騰?}
  C1 -->|Yes| C1R[パターン1: Braket cost runaway]
  C --> C2{コスト高止まり?}

  D --> D1{クラスタ全停止?}
  D1 -->|Yes| D1R[パターン2: HeadNode failure]
  D --> D2{ジョブ滞留?}
  D2 -->|Yes| D2R[パターン3: Slurm tuning 不在]
  D --> D3{MPI速度低下?}
  D3 -->|Yes| D3R[パターン4: EFA driver mismatch]
  D --> D4{コスト最適化未着手?}

  E --> E1{ジョブ頻繁失敗?}
  E1 -->|Yes| E1R[パターン5: Batch Spot interruption]
  E --> E2{コスト最適化未着手?}

  F --> F1{KMS decrypt失敗?}
  F1 -->|Yes| F1R[パターン6: Nitro Enclaves attestation失敗]

  C2 & D4 & E2 --> G[パターン7: コスト最適化不在]

パターン1: Braket cost runaway — QPU 利用料金が想定の10倍

症状

Amazon Braket では QPU 利用料金が「タスク1件あたり固定料金 + Shot 単価」の2段階課金である。
Reservation や Budget alert を設定せずに本番ループで無制限実行すると、
Cost Explorer アラートが鳴るまで気づかず月次請求が想定の10倍になるケースがある。

原因

• Per-shot 課金モデルの理解不足 — IonQ Aria は $0.01/shot が基本単価
• 本番ループで shots=10000 を繰り返し実行 → Shot 単価 × ループ回数で急騰
• Reservation / Budget alert 未設定で費用上限ガードがない
• IAM 制限で shots 量を制御していない

対策

# Cost Explorer で Braket monthly budget alert を設定
aws budgets create-budget \
  --account-id "${AWS_ACCOUNT_ID}" \
  --budget '{
 "BudgetName": "braket-monthly",
 "BudgetLimit": {"Amount": "500", "Unit": "USD"},
 "BudgetType": "COST",
 "TimeUnit": "MONTHLY"
  }' \
  --notifications-with-subscribers '[{
 "Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 80
 },
 "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "ops@example.com"}]
  }]'

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Deny",
"Action": "braket:CreateQuantumTask",
"Resource": "*",
"Condition": {
  "NumericGreaterThan": {
 "braket:shots": "1000"
  }
}
 }
  ]
}

パターン2: ParallelCluster headnode failure — AZ 障害でクラスタ全停止

症状

ParallelCluster の Head node は単一 AZ に配置される。その AZ で障害が発生すると、
Slurm スケジューラごとダウンしクラスタ全体が停止する。
Compute fleet が他 AZ で稼働していても Head node が SPOF になるため全ジョブが失敗する。

原因

• Head node の Multi-AZ 配置はサポートされていない (設計上の SPOF)
• Custom AMI を作成していないため Head node の迅速な再作成ができない
• Hot standby cluster を別途用意していない

対策

# Head node の Custom AMI を定期作成 (週次)
pcluster export-image \
  --image-id aws-parallelcluster-3-headnode \
  --region ap-northeast-1 \
  --bucket my-hpc-backups \
  --bucket-key-prefix headnode-ami/

# Head node 障害時の迅速再作成
pcluster create-cluster \
  --cluster-name prod-hpc-standby \
  --cluster-configuration cluster-config-standby.yaml \
  --region ap-northeast-1

HeadNode:
  InstanceType: c5.2xlarge
  Networking:
 SubnetId: subnet-xxxxxxxx
  Ami:
 Id: ami-xxxxxxxxxx
  Iam:
 AdditionalIamPolicies:
- Policy: arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

パターン3: Slurm tuning 不在 — ジョブ滞留・優先度バッティング

症状

デフォルト設定の Slurm では全ジョブが同一 Partition で同一優先度で実行される。
対話型ジョブとバッチジョブが競合し、重要ジョブが何時間も待機するケースが発生する。

原因

• Partition 分離設計なし — interactive / batch / preemptible の3分類が未設定
• QoS 未定義 — ユーザー別・プロジェクト別の CPU/メモリ制限がない
• Priority weight 未設定 — FairShare が機能せず全ジョブが FIFO 実行

対策

# Slurm Partition を3分類に分離 (設定ファイル確認)
cat /opt/slurm/etc/slurm.conf.d/partitions.conf

PartitionName=interactive Nodes=compute-[001-010] MaxTime=4:00:00 Default=NO Priority=100
PartitionName=batch Nodes=compute-[001-100] MaxTime=7-00:00:00 Default=YES Priority=50
PartitionName=preemptible Nodes=compute-[001-200] MaxTime=12:00:00 Default=NO Priority=10 PreemptMode=requeue

# QoS 設定 (プロジェクト別 CPU 制限)
sacctmgr add qos normal-qos MaxCPUs=1000 MaxWall=7-00:00:00
sacctmgr add qos high-priority MaxCPUs=200 MaxWall=4:00:00 Priority=100

# Priority weight 設定確認
scontrol show config | grep PriorityWeight

パターン4: EFA driver mismatch — MPI ジョブが ENA 経由でフォールバック

症状

EFA 対応インスタンスで MPI ジョブを実行しているにもかかわらず、
通信が EFA ではなく ENA 経由になっている。
MPI 通信のレイテンシが EFA 時の100倍近くになり HPL や WRF が著しく遅くなる。

原因

• aws-efa-installer のバージョンが古い (EFA kernel module と libfabric のバージョン不一致)
• 対応インスタンスタイプ以外で EFA を試みている (hpc6a / hpc7a / c5n / c6gn / p4d のみ対応)
• Placement Group への配置が設定されていない
• FI_PROVIDER=efa 環境変数が未設定

対策

# EFA installer 最新版インストール
curl -O https://efa-installer.amazonaws.com/aws-efa-installer-latest.tar.gz
tar -xf aws-efa-installer-latest.tar.gz && cd aws-efa-installer
sudo ./efa_installer.sh -y

# EFA 疎通確認 (同一 Placement Group 内の2ノード間)
fi_info -p efa -t FI_EP_RDM

# MPI 実行時に EFA を明示指定
mpirun --hostfile hostfile \
  -x FI_PROVIDER=efa \
  -x FI_EFA_USE_HUGE_PAGE=1 \
  -np 128 ./hpl_benchmark

# ParallelCluster config: EFA + Placement Group の設定 (抜粋)
Networking:
  PlacementGroup:
 Enabled: true
  Efa:
 Enabled: true

パターン5: Batch Spot interruption — 長時間ジョブが頻繁に中断

症状

AWS Batch で Spot インスタンスを使用した長時間 HPC ジョブが Spot interruption により
頻繁に失敗する。再試行するとまた中断され、ジョブが永遠に完了しない。

原因

• Spot instance type が1種類のみ指定 → 特定 AZ で容量不足時に全停止
• チェックポイント機能がなく、中断時に進捗が全消失する
• Spot interruption notice (2分前通知) のハンドリングがない

対策

# AWS Batch Compute Environment: Mixed instance 設定
ComputeResources:
  Type: SPOT
  AllocationStrategy: SPOT_CAPACITY_OPTIMIZED
  InstanceTypes:
 - c5.4xlarge
 - c5.9xlarge
 - c5n.4xlarge
 - c5n.9xlarge
 - c6i.4xlarge
 - c6i.8xlarge
  MinvCpus: 0
  MaxvCpus: 2048
  SpotIamFleetRole: arn:aws:iam::ACCOUNT_ID:role/AmazonEC2SpotFleetRole

import json
import signal

def checkpoint_handler(signum, frame):
 save_checkpoint(current_state)
 upload_to_fsx(checkpoint_path)
 raise SystemExit(0)

signal.signal(signal.SIGTERM, checkpoint_handler)

def save_checkpoint(state):
 checkpoint = {"iteration": state.iteration, "results": state.results}
 with open("/fsx/checkpoints/job_checkpoint.json", "w") as f:
  json.dump(checkpoint, f)

パターン6: Nitro Enclaves attestation 失敗 — KMS Decrypt が AccessDenied

症状

Nitro Enclaves 内で KMS Decrypt を呼び出すと AccessDenied が返される。
KMS Key Policy に kms:RecipientAttestation 条件を設定しているが、
Enclave を再ビルドするたびに PCR 値が変化し条件と不一致になる。

原因

• Enclave を再ビルドするたびに PCR0/PCR1/PCR2 の SHA-384 ハッシュが変化する
• KMS Key Policy に古い PCR 値がハードコードされたまま更新されていない
• nitro-cli describe-eif による PCR 値確認が CI/CD に組み込まれていない

対策

# Enclave ビルド後に PCR 値を確認
nitro-cli build-enclave \
  --docker-uri my-enclave-app:latest \
  --output-file my-enclave.eif

nitro-cli describe-eif --eif-path my-enclave.eif | \
  python3 -c "
import json, sys
eif = json.load(sys.stdin)
print('PCR0:', eif['Measurements']['PCR0'])
print('PCR1:', eif['Measurements']['PCR1'])
print('PCR2:', eif['Measurements']['PCR2'])
"

{
  "Sid": "AllowEnclaveDecrypt",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::ACCOUNT_ID:role/enclave-role"},
  "Action": "kms:Decrypt",
  "Condition": {
 "StringEqualsIgnoreCase": {
"kms:RecipientAttestation:ImageSha384": "${PCR0_VALUE}"
 }
  }
}

パターン7: コスト最適化不在 — HPC ジョブ常時稼働 / Reservation 未活用

症状

HPC クラスタが常時稼働しており、ジョブがない時間帯も Compute fleet が起動したまま。
Spot 活用・Savings Plans・Reservation を検討していないため
オンデマンド料金をそのまま支払い続けている。

原因

• ParallelCluster の Idle scale-down が未設定 (ScaledownIdletime デフォルト値のまま)
• AWS Batch の Compute Environment が最小 vCPU > 0 に設定されている
• Spot instance を採用していない
• 長期確定ワークロードへの Savings Plans Compute / HPC Reservation 未検討

対策

# ParallelCluster config: アイドルスケールダウンを設定
Scheduling:
  Scheduler: slurm
  SlurmSettings:
 ScaledownIdletime: 10
  SlurmQueues:
 - Name: batch-queue
ComputeResources:
  - Name: spot-instances
 Instances:
- InstanceType: c5.18xlarge
 MinCount: 0
 MaxCount: 100
 Spot: true

# Savings Plans Compute の購入確認 (汎用型 HPC ワークロード向け)
aws savingsplans describe-savings-plans \
  --savings-plan-types ComputeSavingsPlans \
  --states active

# HPC 専用 Reservation の確認 (hpc6a / hpc7a)
aws ec2 describe-reserved-instances \
  --filters "Name=instance-type,Values=hpc6a.48xlarge"

§7 アンチパターン → 正解パターン変換演習 (5問)

Quantum/HPC 本番運用における代表的なアンチパターンを5問の演習形式で示す。
各問は「❌ アンチパターン」と「✅ 正解パターン」のコード対比で学習する。
コードを読んだ後に「なぜそれがアンチパターンなのか」を自分の言葉で説明できるようになることを目標とする。

Q1: 常時稼働 HPC → Auto-scaling + Spot (ParallelCluster)

月次で実行する CFD ジョブのために、EC2 Compute fleet を24時間常時起動している。

❌ アンチパターン

# EC2 Compute fleet を24h手動起動 (月額数十万円の無駄コスト)
aws ec2 run-instances \
  --image-id ami-xxxxxxxxxx \
  --instance-type hpc6a.48xlarge \
  --count 20 \
  --placement '{"GroupName":"hpc-pg","Tenancy":"dedicated"}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=hpc-compute}]'
# ジョブがない時間帯も20インスタンスが稼働し続ける
# hpc6a.48xlarge オンデマンド: 約$14.4/h × 20台 × 24h = $6,912/日

✅ 正解パターン

# ParallelCluster config: Idle scale-down + Spot integration
Scheduling:
  Scheduler: slurm
  SlurmSettings:
 ScaledownIdletime: 10
  SlurmQueues:
 - Name: cfd-queue
ComputeResources:
  - Name: hpc-spot
 Instances:
- InstanceType: hpc6a.48xlarge
- InstanceType: c5n.18xlarge
- InstanceType: c6gn.16xlarge
 MinCount: 0
 MaxCount: 50
 Spot: true

# ジョブ実行時のみ自動スケールアップ・完了後10分でアイドルノード自動削除
sbatch --partition=cfd-queue --nodes=20 --ntasks-per-node=96 cfd_job.sh

解説

ParallelCluster の ScaledownIdletime は Slurm が「このノードは10分間ジョブなし」と判定した
タイミングで EC2 インスタンスを自動終了する設定である。MinCount: 0 と組み合わせることで
アイドル時のコストをゼロにできる。Spot instance type を複数指定することで容量確保の安定性も向上する。

Q2: 単一 AZ HPC → Multi-AZ FSx for Lustre + S3 backed

HPC ジョブの作業ファイルを FSx for Lustre Scratch に保存しているが、AZ 障害でデータが消失した。

❌ アンチパターン

# FSx for Lustre Scratch を単一 AZ のみに配置 (AZ障害でデータ消失)
aws fsx create-file-system \
  --file-system-type LUSTRE \
  --storage-capacity 1200 \
  --subnet-ids subnet-xxxxxxxx \
  --lustre-configuration '{
 "DeploymentType": "SCRATCH_2",
 "PerUnitStorageThroughput": 200
  }'
# SCRATCH_2 は短期作業用: AZ 障害でデータが消えてもよい設計が前提
# 長期データや重要中間結果を SCRATCH に置いているのがアンチパターン

✅ 正解パターン

# FSx for Lustre Persistent + S3 backed で冗長化
aws fsx create-file-system \
  --file-system-type LUSTRE \
  --storage-capacity 2400 \
  --subnet-ids subnet-xxxxxxxx \
  --lustre-configuration '{
 "DeploymentType": "PERSISTENT_2",
 "PerUnitStorageThroughput": 500,
 "DataCompressionType": "LZ4",
 "AutoImportPolicy": "NEW_CHANGED_DELETED",
 "ImportPath": "s3://my-hpc-data/input/",
 "ExportPath": "s3://my-hpc-data/output/"
  }'

# ジョブ完了後に S3 へ自動エクスポート
aws fsx create-data-repository-task \
  --file-system-id fs-xxxxxxxxxx \
  --type EXPORT_TO_REPOSITORY \
  --paths / \
  --report '{"Enabled":true,"Path":"s3://my-hpc-logs/","Format":"REPORT_CSV_20191124"}'

解説

FSx for Lustre には SCRATCH_1/SCRATCH_2 (短期作業用・AZ 障害でデータ消失あり) と
PERSISTENT_1/PERSISTENT_2 (長期保存・高耐久・AZ 障害でも保護) の2系統がある。
重要な中間結果・最終出力は PERSISTENT_2 + S3 backed に配置し
S3 エクスポートタスクでバックアップを確保することで AZ 障害に対応する。

Q3: boto3 直接呼出 → Braket SDK + Hybrid Jobs

Amazon Braket での量子タスク実行を boto3.client(‘braket’) で直接記述していた。

❌ アンチパターン

import boto3
import json

braket = boto3.client('braket', region_name='us-east-1')

# boto3 直接呼出: 低レベルAPI・エラーハンドリング・タスク追跡が困難
response = braket.create_quantum_task(
 action=json.dumps({
  "braketSchemaHeader": {
"name": "braket.ir.openqasm.program",
"version": "1"
  },
  "source": "OPENQASM 3.0;\nqubit[2] q;\nh q[0];\ncnot q[0], q[1];",
  "inputs": {}
 }),
 deviceArn='arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1',
 shots=1000,
 outputS3Bucket='my-braket-output',
 outputS3KeyPrefix='results/'
)
# タスク追跡・結果取得・エラーリトライを全て手実装が必要

✅ 正解パターン

from braket.aws import AwsDevice
from braket.circuits import Circuit
from braket.devices import LocalSimulator
from braket.jobs import hybrid_job

# Braket SDK を使用した高レベル実装
circuit = Circuit()
circuit.h(0)
circuit.cnot(0, 1)
circuit.probability(target=[0, 1])

# Local Simulator で先に動作確認 (コスト不要)
local_sim = LocalSimulator()
result = local_sim.run(circuit, shots=1000).result()
print("Local Simulator:", result.measurement_probabilities)

# 本番 QPU 実行 (IonQ Aria) — SDK が自動でポーリング管理
device = AwsDevice("arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1")
task = device.run(
 circuit,
 shots=1000,
 s3_destination_folder=("my-braket-output", "results/")
)
result = task.result()
print("QPU Result:", result.measurement_probabilities)

# Hybrid Jobs: 古典最適化ループ + 量子実行の統合 (VQE/QAOA 向け)
@hybrid_job(device="arn:aws:braket:us-east-1::device/qpu/ionq/Aria-1")
def vqe_job(num_qubits=4, max_iterations=50):
 import numpy as np
 from braket.circuits import Circuit, FreeParameter

 theta = FreeParameter("theta")
 circuit = Circuit().ry(0, theta).cnot(0, 1)
 device = AwsDevice(get_job_device_arn())

 for i in range(max_iterations):
  angle = np.random.uniform(0, 2 * np.pi)
  result = device.run(circuit(theta=angle), shots=100).result()
  log_metric(metric_name="energy", value=compute_energy(result), iteration_number=i)

解説

boto3.client('braket') は低レベル API であり、タスク追跡・結果ポーリング・エラーリトライを
全て手実装する必要がある。Braket SDK の AwsDevice.run() は内部でポーリングと
タイムアウト管理を行い、Local Simulator との切り替えも1行で実現できる。
VQE / QAOA などの変分アルゴリズムには @hybrid_job デコレータを使用し
古典最適化ループと量子実行を統合して管理する。

Q4: EC2 手動構成 → ParallelCluster IaC (pcluster CLI)

HPC クラスタを EC2 手動起動 + SSH で Slurm を手動インストールして構築していた。

❌ アンチパターン

# EC2 手動起動 + Slurm 手動インストール (再現性・再構築性ゼロ)
aws ec2 run-instances \
  --image-id ami-xxxxxxxxxx \
  --instance-type c5.2xlarge \
  --key-name my-key \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Role,Value=headnode}]'

# SSH でログインして手動設定 (手順書が人間の記憶頼り)
# sudo yum install slurm ... && sudo vi /etc/slurm/slurm.conf

✅ 正解パターン

# cluster-config.yaml: 宣言型で全構成を定義
Region: ap-northeast-1
Image:
  Os: alinux2023
HeadNode:
  InstanceType: c5.2xlarge
  Networking:
 SubnetId: subnet-xxxxxxxx
  Ssh:
 KeyName: my-hpc-key
Scheduling:
  Scheduler: slurm
  SlurmQueues:
 - Name: compute
ComputeResources:
  - Name: c5-spot
 Instances:
- InstanceType: c5.18xlarge
 MinCount: 0
 MaxCount: 100
 Spot: true
Networking:
  SubnetIds:
 - subnet-xxxxxxxx
 - subnet-yyyyyyyy
SharedStorage:
  - Name: fsx-lustre
 StorageType: FsxLustre
 MountDir: /fsx
 FsxLustreSettings:
StorageCapacity: 1200
DeploymentType: PERSISTENT_2
PerUnitStorageThroughput: 200

# 一発でクラスタ作成 (10-15分で完全な HPC クラスタが構築される)
pcluster create-cluster \
  --cluster-name prod-hpc-cluster \
  --cluster-configuration cluster-config.yaml \
  --region ap-northeast-1

# クラスタ状態確認
pcluster describe-cluster --cluster-name prod-hpc-cluster

解説

ParallelCluster IaC (pcluster CLI + cluster-config.yaml) は CloudFormation をバックエンドとして、
Head node / Compute fleet / Slurm スケジューラ / EFA / FSx for Lustre の全構成を
宣言型で管理する。手動構成と違い cluster-config.yaml を git 管理することで
「誰でも同一クラスタを再現できる」状態になる。障害時の再作成も pcluster create-cluster 1コマンドで完結する。

Q5: 仮想化 EC2 + Hyper-V → Nitro Bare metal

Windows Server 上で Hyper-V を動かし、その上に VM を作成しようとしていたが
PCI パススルーが動作しなかった。

❌ アンチパターン

仮想化 EC2 上での Hyper-V (PCI パススルー不可)
  EC2 m6i.xlarge (仮想化)
 └── Nitro Hypervisor (AWS の仮想化レイヤー)
└── Windows Server (仮想化 EC2 インスタンス)
  └── Hyper-V (ネスト型仮想化)
 └── GPU デバイス (PCI パススルー) → 失敗

Nitro Hypervisor がハードウェアを仮想化しているため
その上の Hyper-V は物理デバイスに直接アクセスできない
→ PCI パススルー・SR-IOV・DPDK 等のハードウェア直接利用は全て不可

✅ 正解パターン

# Bare metal インスタンスを起動 (Nitro Hypervisor なし = 物理サーバ直接)
aws ec2 run-instances \
  --image-id ami-xxxxxxxxxx \
  --instance-type i3.metal \
  --placement '{"Tenancy":"host"}' \
  --key-name my-key

# Bare metal 確認: virt-what で仮想化レイヤーが存在しないことを確認
sudo virt-what
# (空出力 = 仮想化なし = Bare metal であることの確認)

# Nitro Enclaves も Bare metal で最大性能が得られる
nitro-cli run-enclave \
  --eif-path my-enclave.eif \
  --memory 4096 \
  --cpu-count 2 \
  --enclave-cid 16

# エンクレーブの状態確認
nitro-cli describe-enclaves

解説

通常の EC2 インスタンス (m6i.xlarge 等) は Nitro Hypervisor により仮想化されており、
ゲスト OS から物理ハードウェアへの直接アクセスはできない。Hyper-V でネスト型仮想化は動作するが、
PCI パススルー・SR-IOV・DPDK 等は物理レイヤーへのアクセスが必要なため動作しない。
Bare metal インスタンス (i3.metal / c5n.metal / m6i.metal 等) では Nitro Hypervisor が除去されており、
OS が物理ハードウェアに直接アクセスできる。HFT / Oracle DB ライセンス / Hyper-V + PCI パススルー /
Nitro Enclaves 最大性能などがこの特性を必要とする。

§8 まとめ + 第21軸目Quantum/HPCシリーズ起点告知 + 51記事化達成告知 + 全軸クロスリンク (Mermaid02)

§8-1 まとめ — 4領域横断の本番運用原則

本記事 Quantum/HPC本番運用 Vol1 では、AWS の先端領域計算サービス4本柱を
本番運用の視点で体系化してきた。各領域のポイントを改めて整理する。

Amazon Braket 本番運用のポイント

Amazon Braket は IonQ Aria / Rigetti Aspen-M / IQM Garnet / QuEra Aquila の4種類の
量子ハードウェアを統一 API で扱えるマネージドサービスである。
本番運用では「開発フェーズは Local Simulator (SV1/DM1/TN1) で徹底検証し、
最終検証のみ QPU 実行」という原則が重要である。
コスト管理では Budget alert + IAM の braket:shots 上限制限を必ず設定し、
Per-shot 課金モデルに起因するコスト急騰を防ぐ。
VQE / QAOA などの変分アルゴリズムは @hybrid_job デコレータを使用し、
古典最適化ループ (SageMaker) と量子実行 (QPU) を統合管理する。

ParallelCluster 本番運用のポイント

ParallelCluster は CloudFormation をバックエンドに、Slurm スケジューラ + EFA +
FSx for Lustre の HPC クラスタ全体を cluster-config.yaml で宣言的に管理する。
Slurm のチューニングは Partition 分離 (interactive/batch/preemptible) と
QoS 定義 と Priority weight の3点が核心である。
EFA を活用するには aws-efa-installer の最新版 + Placement Group + FI_PROVIDER=efa の
明示指定が必須であり、対応インスタンスタイプの確認も忘れてはならない。
Head node は SPOF であるため、Custom AMI の定期バックアップと
Hot standby cluster の維持が本番設計の前提となる。

AWS Batch HPC 本番運用のポイント

AWS Batch HPC は「自律型 HPC ジョブスケジューラ」として、
ParallelCluster (Slurm 手動管理) とは用途を使い分ける。
Compute environment の設計では SPOT_CAPACITY_OPTIMIZED + Mixed instance type が
安定した Spot 容量確保の鍵である。
Long-running ジョブには必ずアプリケーションレベルのチェックポイント機能を実装し、
SIGTERM ハンドラーで Spot interruption notice を捕捉して FSx for Lustre に保存する。
Multi-node parallel job (MPI / NCCL) では EFA 対応インスタンスと
Placement Group を組み合わせることで最大通信性能を引き出せる。

Nitro System 本番運用のポイント

Nitro System は「EC2 の仮想化基盤そのもの」であり、ほとんどの EC2 インスタンスが
Nitro Hypervisor + Nitro Card + Security Chip の上で動作している。
Bare metal インスタンス (i3.metal 等) は Nitro Hypervisor を除去した
物理サーバ直接アクセスを提供し、HFT / Oracle DB / Hyper-V + PCI パススルー /
Nitro Enclaves 最大性能が要求されるワークロードで採用する。
Nitro Enclaves は KMS attestation (PCR 値) が命綱であり、
Enclave 再ビルドのたびに nitro-cli describe-eif で PCR 値を確認し
KMS Key Policy を更新する CI/CD 自動化が必須である。

4領域横断の本番運用3原則

先端領域 (Quantum/HPC/Bare metal) は実験的ワークロードから始まりがちだが、
本番運用に持ち込む際には「コスト暴走防止」「障害設計」「IaC による再現性」の3原則を
一般的なクラウドワークロードと同様に徹底することが求められる。

§8-4 Mermaid02 — 第21軸目Quantum/HPCマップ + 全軸接続図

graph LR
  QH1["Quantum/HPC Vol1<br/>本記事"]

  QH2["Vol2: Hybrid Jobs<br/>VQE/QAOA"]
  QH3["Vol3: HPC最適化<br/>Slurm/NCCL/DCGM"]
  QH4["Vol4候補: Nitro Enclaves<br/>セキュア計算"]

  QH1 --> QH2
  QH1 --> QH3
  QH1 --> QH4

  OBS3["Observability Vol3<br/>App Signals / SLO"] --> QH1
  CTR3["Container Vol3<br/>EKS / Karpenter"] --> QH1
  SEC3["Security Vol3<br/>Macie / Detective"] --> QH1
  ML3["AI/ML Vol3<br/>SageMaker MLOps"] --> QH1
  STR2["Storage Vol2<br/>FSx / EBS"] --> QH1
  NET2["Network Vol2<br/>EFA / Placement"] --> QH1

本記事で Quantum/HPC 本番運用の4本柱 (Braket / ParallelCluster / Batch HPC / Nitro System) を
習得した読者が次に読むべき記事を紹介する。

Quantum/HPC × AWS の先端領域は、まだ本番運用事例が少ない開拓フロンティアである。
本記事を読んで「自社ワークロードへの適用方法」「特定の詰まりポイントの解決策」
「Vol2/Vol3 で深掘りすべきトピック」について、ぜひコメント欄でフィードバックをいただきたい。

特に以下の点について読者の声を聞かせてほしい。

• Amazon Braket で試したいアルゴリズムやユースケース (創薬 / 金融 / 物流最適化 など)
• ParallelCluster / AWS Batch HPC への移行を検討しているオンプレ HPC ワークロードの種類
• Nitro Enclaves を活用したいセキュアな計算要件 (医療データ / 金融リスク計算 など)
• Vol2 (Hybrid Jobs) / Vol3 (HPC ジョブ最適化) / Vol4 候補 (Nitro Enclaves) のどれを優先して欲しいか
• 本記事で扱いきれなかった先端領域トピック (FPGA F2 インスタンス / SageMaker HyperPod / Trainium クラスタ など) で深掘りを希望するもの
• 自社で既に本番運用している先端領域ワークロードの事例共有 (匿名希望含む)

フィードバックチャネル

本記事に関するフィードバックや質問は以下のいずれかでお寄せいただきたい。

• ページ末尾コメント欄: 公開コメントとしてやり取りしたい場合
• SNS シェア + メンション: X (Twitter) / Bluesky 等で #AWS本番運用シリーズ ハッシュタグを付けて投稿
• 個別問い合わせ: 機密性のある事例や具体的なアーキ相談はサイト問い合わせフォームから

読者アンケート — Vol2 の重点トピック投票

次の Vol2 で優先して扱うべきトピックを以下から選んで頂きたい (複数選択可)。

• A: VQE / QAOA の Python 完全実装例 (古典最適化ループ含む)
• B: Hybrid Jobs の SageMaker Pipelines 統合パターン (CI/CD 含む)
• C: Local Simulator 3種 (SV1 / DM1 / TN1) の選択ベンチマーク実測
• D: Braket Cost制御の本番事例 (Reservation / Budget自動制御)
• E: 量子化学アルゴリズム (Quantum Chemistry) の Braket 実装

量子コンピューティング・HPC・Bare metal は、今後5〜10年で「一般的なクラウドワークロード」に
なっていく可能性がある技術領域である。このシリーズが読者の先端領域への挑戦を支える
一助になれば幸いである。AWS が継続的に投入する先端計算サービス群を、本シリーズが
追随的に体系化していくことで、読者の本番投入意思決定を支える情報源となることを目指す。

次の Vol2 では Hybrid Jobs (VQE / QAOA) の実装を中心に、量子古典ハイブリッドアルゴリズムの
本番運用を深掘りする予定である。引き続きお楽しみいただきたい。
本記事がフロンティアに挑む読者の最初の足がかりとなることを願っている。