「計算リソース（Computing Power）」が抽象に感じるのは自然です。本記事は、Azure を例に“会話しながら腑に落とす”学び方を軸に、概念を数値・操作・料金に結びつけて理解するための実践ガイドです。Learning Rooms を活用した問答のコツ、最短で手を動かすミニラボ、スケーリングと課金の勘所、GPU/IOPS などつまずきやすい要素まで一気通貫で解説します。
クラウドの「計算リソース」を一言でいうと
“どれだけ速く・同時に・安定して処理できるか”を決める力の総体です。単なる CPU 数ではなく、vCPU・メモリ・GPU・ディスク IOPS/スループット・ネットワーク帯域・スケーリング手段などの組み合わせで成立します。Azure では仮想マシン（VM）、仮想マシン スケール セット（VMSS）、Azure Kubernetes Service（AKS）、App Service、Functions、Batch/HPC などのサービスがこの力を提供します。
まず押さえる 4 つの観点（要点表）
| 観点 | 概要 | 具体例・学習方法 |
|---|---|---|
| 単位と種類 | vCPU、RAM、GPU、ディスク IOPS/MBps、ネットワーク帯域 | Azure VM の SKU 比較やメトリクス（CPU/メモリ/ディスク）を実数で確認する |
| スケーリング | 垂直（サイズ変更）と水平（台数増減）、自動/手動 | VMSS の自動スケール ルール（CPU 使用率など）を試す |
| 課金モデル | 従量課金、予約/貯蓄プラン、スポットなど | 料金の主要ドライバー（サイズ・時間・ディスク種別・転送量）を分解して見積もる |
| 演習環境 | 学びは“見る→触る→測る”を短サイクルで | Microsoft Learn サンドボックスや無料枠でミニラボを回す |
会話で学ぶ：Microsoft Learn の「Learning Rooms」の使い方
Learning Rooms は、講師や学習者とリアルタイムに質疑・ディスカッションできる公式コミュニティ機能です。無料アカウントで参加でき、初学者向けから認定試験対策（AZ-900 など）までテーマ別ルームがあります。特に抽象概念の理解には、“自分の言葉で説明→フィードバック→再説明”の循環が効果的です。
活用の流れ
- 目的を明確化：「計算リソースの全体像を掴みたい」「VMSS の自動スケールの仕組みを確認したい」など。
- 事前インプット：用語（vCPU、IOPS、スケールアウト/アップ）を 10 分で流し読み。
- 短く質問：「Web API を 1,000 req/s 捌くには CPU/メモリ/スケールはどう設計しますか？」のように具体化。
- 回答を“再表現”：得た説明を自分のユースケースに言い換え、勘違いがないか再確認。
- ミニラボで検証：後述の手順で数値を取って確かめる。
質問テンプレート（コピペ用）
【前提】アプリ：API（.NET 8）、平均 200 req/s、ピーク 1000 req/s
【現状】Standard_D2s_v5 ×1、CPU 70% ピーク、P30 ディスク
【課題】ピーク時にレイテンシ増（p95=800ms）
【質問】横に 3 台へスケールアウトと、縦に D4s_v5 へサイズアップはどちらが合理的？
【補足】将来 AKS 移行検討、コストは +30% 以内に抑えたいAzure における「計算リソース」の具体像
| サービス | 計算の単位 | スケーリング | 主な用途 | 課金の軸 |
|---|---|---|---|---|
| Virtual Machines (VM) | サイズ（vCPU/RAM/GPU）、ディスク・帯域 | 垂直：サイズ変更／水平：台数増 | 汎用サーバ、DB、レガシー移行 | 台数×時間、ディスク、転送量 |
| Virtual Machine Scale Sets (VMSS) | VM の集合（同一 SKU） | 自動スケール（CPU/QPS等） | Web/API、バッチ処理 | VM と同様 |
| Azure Kubernetes Service (AKS) | ノード（VM）と Pod（コンテナ） | Cluster/Node/Pod の多層スケール | マイクロサービス、可搬性 | ノード×時間、周辺機能 |
| App Service | プランのインスタンス | プラン単位で水平 | Web/関数アプリ簡易運用 | プラン×時間 |
| Functions | 実行時間・メモリ（消費型等） | イベントドリブンで自動 | イベント駆動処理 | 実行回数・時間 |
| HPC/BATCH | CPU フリート、GPU ノード | 大規模水平 | 数値計算、機械学習学習 | ノード×時間 |
VM シリーズで“性格”を掴む（目安表）
| シリーズ | 特徴 | 向いている用途 |
|---|---|---|
| B | バースト型、平常時低コスト | 開発/検証、小負荷の常時稼働 |
| D/E | 汎用/メモリ最適、最新 CPU 世代を含む | Web/API、アプリサーバ、DB（E） |
| F | コンピュート最適（高 vCPU/GB） | CPU バウンドなワークロード |
| L | 高速ローカル NVMe | キャッシュ/一時領域重視、OLTP |
| HB/HC | HPC 向け、メモリ・帯域強力 | 数値解析、CFD、EDA |
| NC/ND | GPU（NVIDIA） | 機械学習、推論/学習、可視化 |
同じ vCPU 数でも世代・クロック・キャッシュ・メモリ帯域・ディスク/ネット構成で体感性能は変わります。“vCPU=性能”ではない点に注意してください。
スケーリングの設計：縦か横か、自動か手動か
判断の考え方
- スケールアップ：単純・即効、上限に頭打ち（1 台の限界）。ライセンス/キャッシュ局所性が効くケースに有利。
- スケールアウト：冗長性・ピーク吸収に強い。状態管理（セッション/ロック）と起動時間を設計に反映。
自動スケールの典型ルール
| 指標 | 条件例 | アクション | 注意点 |
|---|---|---|---|
| CPU 使用率 | 70% 超が 10 分継続 | 1 台追加（最大 10 台） | 短期スパイクに振り回されない期間設定 |
| キュー長 | キュー > 100 件が 5 分継続 | 2 台追加 | 処理時間×到着率でスループット試算 |
| HTTP レイテンシ p95 | > 500ms が 5 分継続 | 1 台追加 | 外部依存（DB/外部 API）ボトルネック切り分け |
| スケジュール | 平日 9–18 時は最小 3 台 | 事前ウォームアップ | 予測需要と組み合わせる |
料金の見方：何に対して“お金がかかる”のか
| サービス | 主要コスト要素 | 最適化の打ち手 |
|---|---|---|
| VM/VMSS/AKS ノード | サイズ×稼働時間、ディスク種別/容量、転送量 | リザーブド/貯蓄プラン、スポット、スケジュール停止、ライトサイジング |
| Functions（消費型） | 実行回数、実行時間、メモリ | ホットスタート、コード最適化、結合バッチ |
| App Service | プランの台数・サイズ | 用途別プラン分離、オートスケール、段階的スロット |
| GPU | ノード時間、ストレージ/転送 | 学習/推論の分離、スポット活用、チェックポイント保存 |
目安式：総コスト ≒ Σ（インスタンス単価 × 稼働時間）＋ ストレージ（容量・IOPS/スループット）＋ ネットワーク転送（特に外向き）。まずは 1 台の単価と台数の関係を見える化しましょう。
観測可能性（Observability）：数値で理解する
メトリクスを見て初めて「計算リソース」が手触りになります。Azure Monitor では VM/VMSS/AKS/App Service/Functions それぞれに標準メトリクスがあります。
| 指標 | 意味 | 解釈のコツ | 対処 |
|---|---|---|---|
| CPU 使用率 | vCPU の忙しさ | 70–80% を超え続けるのは余裕不足 | スケールアウト/アップ、コード最適化 |
| メモリ使用量/コミット | 常駐データの大きさ | スワップ発生は危険信号 | メモリ増設、GC/キャッシュ調整 |
| ディスク IOPS/MBps | ディスク処理の速さ | 上限張り付き＝ストレージが瓶頸 | Premium v2/Ultra などに変更、設計見直し |
| ネットワーク送受信 | 帯域利用 | 帯域上限超過は再送/遅延 | SKU/構成変更、CDN/キャッシュ |
| HTTP レイテンシ/エラー率 | ユーザー体験 | p95/p99 を追う | スケーリング、依存先の最適化 |
最短で“腑に落とす”ミニラボ：VM を立てて負荷をかけ、計測する
以下は無料枠やサンドボックスで 30–60 分程度で回せる簡易シナリオです（料金が発生しうるため、作成資源は必ず削除してください）。
1) リソース作成（Azure CLI）
# 変数
LOCATION=japaneast
RG=rg-compute-lab
VMNAME=vm-compute-lab
# リソースグループ
az group create -n $RG -l $LOCATION
# VM（汎用 D2s v5）
az vm create
-g $RG -n $VMNAME
--image Ubuntu2204
--size Standard_D2s_v5
--admin-username azureuser
--generate-ssh-keys
# ネットワーク許可（HTTP 80）
az vm open-port -g $RG -n $VMNAME --port 80 2) 負荷ツール準備と簡易 Web
ssh azureuser@<パブリックIP>
sudo apt-get update
sudo apt-get install -y nginx stress-ng fio
# Nginx が 80 番で起動していることを確認
systemctl status nginx 3) CPU を意図的に使って挙動を見る
# vCPU 2 個を 120 秒全力で回す
stress-ng --cpu 2 --timeout 120s --metrics-brief
同時に Azure Portal/CLI で CPU 使用率メトリクスを観察します。「負荷 → 指標が動く → 応答が遅くなる」の因果を体で理解します。
4) ディスク IOPS/スループットの体感
# ランダム 4K 読み書き
sudo fio --name=randrw --filename=/mnt/testfile --size=512M \
--rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --runtime=60 --time_based
結果の IOPS/MBps とレイテンシ（clat）を確認し、ディスク SKU（Standard/Premium v2/Ultra）で上限が異なることを意識化します。
5) 片付け
az group delete -n $RG --yes --no-waitVMSS で“横に増やす”を体験：自動スケールの最小セット
# 変数
RG=rg-scale-lab
LOCATION=japaneast
VMSS=vmss-lab
az group create -n $RG -l $LOCATION
# VMSS 作成（D2s v5、インスタンス 2 から）
az vmss create -g $RG -n $VMSS --image Ubuntu2204
--instance-count 2 --vm-sku Standard_D2s_v5
--admin-username azureuser --generate-ssh-keys
# 自動スケール ルール（CPU 70% 超で 1 台追加、20% 未満で 1 台削減）
az monitor autoscale create --resource-group $RG --name autoscale-$VMSS
--resource /subscriptions//resourceGroups/$RG/providers/Microsoft.Compute/virtualMachineScaleSets/$VMSS
--min-count 2 --max-count 6 --count 2
az monitor autoscale rule create --resource-group $RG --autoscale-name autoscale-$VMSS
--condition "Percentage CPU > 70 avg 10m" --scale out 1
az monitor autoscale rule create --resource-group $RG --autoscale-name autoscale-$VMSS
--condition "Percentage CPU < 20 avg 15m" --scale in 1 負荷をかけてインスタンス数が増減する様子を可視化します。“待ち時間（ウォームアップ）”がユーザー体験に与える影響も議論してみましょう。
GPU と CPU：どちらの計算力が効くのか
GPU は“多数の簡単な計算を同時に回す”のが得意です。行列演算や並列性の高い処理（機械学習の学習/推論、画像/動画処理）は GPU が効きます。一方、分岐が多く逐次性の高い処理は CPU が得意です。選定では以下を比較します。
| 観点 | CPU | GPU |
|---|---|---|
| 得意領域 | 複雑な分岐、低遅延処理 | 行列演算、大量並列 |
| スケーリング | 台数を増やしやすい | ノード単価が高く分散/スケジューリング設計が重要 |
| コスト | 単価低め、数で伸びる | 単価高め、稼働効率が鍵（ジョブ集約/スポット） |
学習/推論ジョブはチェックポイント保存とスポット VM の活用でコストを抑えられます。推論は CPU 混在や低精度化（FP16/INT8）で更に最適化できます。
IOPS とスループット：数字の読み方
- IOPS：1 秒あたりの I/O 回数（小さなランダム I/O に効く）。
- スループット（MBps）：単位時間のデータ量（大きなシーケンシャル I/O に効く）。
- レイテンシ：1 回の I/O にかかる時間（ユーザー体験直結）。
ワークロードが小さなランダムアクセス中心か、大きな連続読み書き中心かで、ディスク選定とチューニングが変わります。DB/OLTP は IOPS、データレイク/ETL はスループットが効きます。
“数で語る”学び方：要求から必要計算力を逆算する
例：平均 200 req/s、ピーク 1000 req/s の API。1 リクエストの CPU 時間が 20ms、平均同時処理 50。
- 必要 CPU 時間/秒：1000 req/s × 0.02s = 20 CPU 秒/秒（= 20 vCPU 相当）。
- 安全率 1.3 倍：26 vCPU。
- 構成案：D2s v5 × 13 台（水平） or D8s v5 × 4 台（混合）。
- レイテンシ要件：p95 < 300ms を満たすようキュー/接続プールを最適化。
このように、単位時間あたりの仕事量を vCPU 秒で見積もると、スケール設計が会話しやすくなります。
学習フロー（モデルケース）
- 用語整理（1 日）：vCPU、RAM、GPU、IOPS、スケールアウト/アップ、従量/予約/スポット。
- 動画で視覚化（1–2 日）：Azure サービスのデモを視聴。
- Learning Rooms 参加（並行）：疑問を都度投げる。
- ミニラボ実践（2–3 日）：VM 作成→負荷→メトリクス観察→片付け。
- ふりかえり（半日）：使ったリソース量と料金を計算、次の最適化案を言語化。
| 週 | ゴール | 到達基準（チェック） |
|---|---|---|
| 1 週目 | 用語・SKU と観測指標を説明できる | 「vCPU/IOPS/スループット差分」を 3 行で説明 |
| 2 週目 | VM/VMSS で負荷をかけて数値が読める | CPU/IOPS のグラフと要因メモを残せる |
| 3 週目 | スケール戦略を比較提示できる | 縦横/自動手動/コスト比較表を作れる |
| 4 週目 | GPU/AKS/Functions の構成を概説できる | 3 つの構成案の利点欠点を述べられる |
Learning Rooms を最大化する会話スキル
- “状態＋問い＋制約”で聞く：状態（現状の数値）→問い（判断したいこと）→制約（予算/納期）。
- メトリクスを貼る：CPU70%/p95=800ms のように、数字を会話の共通言語に。
- 再説明：相手の回答を 1 分で自分の言葉に言い換え、ズレを潰す。
- 実験計画：「次の 30 分で試すこと」を締めに決める。
メンター：「ピーク時の遅延は CPU 起因か I/O 起因か、どちらが強い？」
あなた：「CPU70%/IOPS 上限 90% なので I/O が強いです。P30 → Premium v2 に替え、ブロックサイズ最適化を試します。」
よくある誤解と対策
- 誤解：「vCPU を増やせば必ず速くなる」
対策：ロック/同期、DB、外部 API が瓶頸なら CPU だけでは改善しない。プロファイルでボトルネック特定。 - 誤解：「最新世代にすれば最安」
対策：性能/価格の最適点はワークロード依存。バースト型やスポットも比較。 - 誤解：「自動スケールを ON にすれば勝手に最適」
対策：ウォームアップ時間、ステートフル性、クールダウンを設計に組み込む。
コスト最適化の型（実務で効くチェックリスト）
- 常時稼働資源に 予約/貯蓄プラン、突発/検証に スポット。
- 自動停止スケジュールで夜間/休日を止める（開発/検証）。
- ライトサイジング：1 か月の平均 CPU 30% 未満なら 1 サイズ下げる検討。
- ディスク選定：IOPS が上限の 80% 超が常時なら SKU 見直し。逆に余裕があれば下げる。
- データ転送：外向き帯域を CDN/キャッシュ/圧縮で削減。
追加の無料学習リソース（リンクなしのガイド）
- Azure Fundamentals（AZ‑900）ラーニングパス：計算・ネットワーク・ストレージ・セキュリティの基礎を体系化。
- Microsoft Learn サンドボックス：クレジットカード不要で短時間の実機操作。
- GitHub Labs（Azure Cloud Labs など）：スクリプトで反復演習。
Learning Rooms では、これらの教材の「どのモジュールをどの順で？」「演習の詰まりどころは？」をメンターに相談すると最短で進められます。
用語ミニ辞典
| 用語 | 定義 | ひとことで |
|---|---|---|
| vCPU | 仮想 CPU。一般に物理コアのスレッド単位 | “考える頭の数” |
| RAM | 主記憶。プロセス/データを置く場所 | “作業机の大きさ” |
| IOPS | 1 秒あたりの I/O 回数 | “手の速さ（回数）” |
| スループット | 単位時間あたりのデータ量 | “一度に運べる荷物量” |
| スケールアウト | 台数を増やす | “人手を増やす” |
| スケールアップ | 1 台を強化 | “一人を鍛える” |
学びを“会話 × 体験 × 数値化”で閉じる
抽象概念の「計算リソース」を掴む近道は、（1）言葉で説明する（Learning Rooms で対話）、（2）手を動かす（VM/VMSS/AKS/Functions を触る）、（3）数字で語る（メトリクスと料金を記録）の三点セットです。小さく作って測り、会話でズレを即修正する。このサイクルを 1–2 週間回すだけで、設計判断の精度とスピードは目に見えて向上します。
実務に持ち帰るための最終チェック
- 要件を vCPU 秒・IOPS・帯域に翻訳できる。
- 縦/横スケールの比較表を 10 分で作れる。
- 自動スケールの 指標・閾値・クールダウンを説明できる。
- 1 日の稼働コストを ±10% 精度で見積もれる。
- Learning Rooms での質問テンプレートが手元にある。
ここまで来れば、「計算リソース」はもう“雲の上の話”ではありません。Azure 上の設計・運用判断を、会話と数値で自信を持って進められるはずです。
コメント