AP 科目A #10 — クラウド・仮想化・分散処理

0. 試験基準

• 対象：2026年 応用情報技術者試験（AP）科目A
• シラバス：IPA 応用情報技術者試験（レベル3）シラバス Ver.7.2
• 改訂日：2026-10-21
• 出典確認日：2026-10-21

1. 免責事項

• 本稿は非公式の学習ノートです。IPA（独立行政法人情報処理推進機構）とは無関係であり、IPAによるレビューや推奨を受けていません。
• 試験範囲・形式・シラバスは変更される可能性があります。受験前に必ずIPAの最新の公式発表を確認してください。
• 本回の5問はすべてオリジナル問題です。 過去問題の使用・引用・改変は行っていません。
• ベンダーの製品名や変動しうるサービス仕様は意図的に除外しています。すべての数値例は、明示した前提の下でのみ成立します。

2. 学習目次

1. 試験基準
2. 免責事項
3. 公式シラバスとの対応
4. 用語対照表
5. VMとコンテナ
6. IaaS/PaaS/SaaSの責任共有
7. スケールアップとスケールアウト
8. 負荷分散と分散処理
9. 障害条件と落とし穴
10. 例題A–D
11. 関連回（AP8/AP9）
12. 要点シート
13. よくある誤り
14. 演習問題
15. 解答と解説
16. セルフチェック
17. 1/3/7日復習計画
18. 出典

3. 公式シラバスとの対応（Ver.7.2）

シラバス上の位置	項目	本回の該当箇所
大分類2 コンピュータシステム／中分類4 システム構成要素／1.（1）②	分散処理システム（分散アーキテクチャ，機能配分，水平機能分散，水平負荷分散，垂直機能分散）	§8，§9，例題D
大分類2／中分類4／1.（2）	システム構成（クラスタ，ロードシェアリング，シェアードエブリシング，シェアードナッシング，密結合／疎結合，仮想化：ホスト型／ハイパーバイザー型／コンテナ型，VM，クラウドコンピューティング，SaaS，PaaS，IaaS）	§5，§6，§8
大分類2／中分類4／2.（1）②	キャパシティプランニング（負荷，サイジング，スケールアウト，スケールアップ，プロビジョニング）	§7，例題A
大分類2／中分類5 ソフトウェア／2.（3）①	仮想化・クラウド向けOSS	§5（概念のみ，製品仕様は扱わない）
大分類3 技術要素／情報セキュリティ管理	クラウドサービスの責任共有モデル，アカウント管理，利用者アクセス権の管理	§6
大分類7／中分類17 システム戦略／（2）①	クラウドサービス（SaaS，PaaS，IaaS，オンデマンド，クラウドネイティブ）	§6

4. 用語対照表

한국어	日本語	English
가상 머신	仮想マシン（VM）	virtual machine (VM)
하이퍼바이저	ハイパーバイザー	hypervisor
게스트 OS	ゲストOS	guest OS
컨테이너	コンテナ	container
호스트 커널	ホストカーネル	host kernel
책임 공유 모델	責任共有モデル	shared responsibility model
스케일업	スケールアップ	scale-up
스케일아웃	スケールアウト	scale-out
로드밸런서	ロードバランサ（負荷分散装置）	load balancer
헬스 체크	ヘルスチェック	health check
단일 장애점	単一障害点（SPOF）	single point of failure (SPOF)
스티키 세션	スティッキーセッション	sticky session
멱등성	冪等性	idempotency
멱등 키	冪等キー	idempotency key
부분 장애	部分障害	partial failure
네트워크 분단	ネットワーク分断	network partition
스트래글러(지연 작업)	ストラグラー（遅延タスク）	straggler
데이터 편중	データの偏り（スキュー）	data skew

5. VMとコンテナ

• VM：ハイパーバイザーが仮想ハードウェアを提供し，その上でVMごとに独自のゲストOS（独自のカーネルを含む）が動作します。
• コンテナ：コンテナはホストOSのカーネルを共有します。カーネルがプロセスと資源（プロセスの見え方，ファイルシステム，ネットワーク，CPU／メモリ制限）を隔離し，コンテナイメージはアプリケーションとユーザ空間の依存関係（ライブラリ，ランタイム，設定）をまとめてパッケージ化します。
• コンテナは小さなVMではありません。 独自のゲストOSカーネルを持たないため，ホストカーネルとの互換性に依存します。

観点	VM	コンテナ
カーネル	VMごとにゲストカーネル1つ	ホストカーネルを共有
一般的な起動	遅い傾向（ゲストOSの起動）	速い傾向（プロセスの開始）
一般的な集約度	低い傾向（VMごとのゲストOSオーバヘッド）	高い傾向
一般的な隔離境界	強い傾向（カーネルが分離）	弱い傾向（カーネルを共有）

これらは一般的な傾向であり，絶対的なものではありません。実際の結果は構成とワークロードによって異なります。

6. IaaS/PaaS/SaaSの責任共有の境界

P＝主に事業者（提供者），C＝主に顧客（利用者）。オンプレミス列は参考です。

層	オンプレミス	IaaS	PaaS	SaaS
物理設備／物理ネットワーク	C	P	P	P
仮想化層	C	P	P	P
ゲストOS	C	C	P	P
ミドルウェア／ランタイム	C	C	P	P
アプリケーション	C	C	C	P
データ／アイデンティティ／アクセス／設定	C	C	C	C

• IaaS → PaaS → SaaS と進むほど，事業者が管理する層が増えます。
• どのモデルでも，顧客は自らのデータ，アカウント，アクセス権，および自らが制御する設定に対する責任を負います（例：SaaSの共有設定，IaaSの仮想ネットワーク／ファイアウォール設定）。
• 注意：これは標準的な概念モデルです。正確な境界は事業者，製品，契約によって異なります。 必ず利用規約と契約で確認してください。

7. スケールアップとスケールアウト

観点	スケールアップ（垂直）	スケールアウト（水平）
方法	1台の機器にCPU／メモリなどを増設	機器（ノード）の台数を増やす
利点	アプリケーションの変更が通常少ないか不要，ノード間の調整が不要	段階的に容量を増やせる，1台が故障しても残りが動作し続けられる
限界	ハードウェアの上限，コストが急増，停止が必要な場合が多い	負荷分散・状態共有・調整が必要，オーバヘッドが増える
状態／調整	状態は1か所にある	状態の外部化・共有が必要で，調整が必要
ボトルネック	単一機器そのもの	共有DB／ストレージ，ロードバランサ，調整通信
障害の影響範囲	単一機器がSPOF	ノード単位の影響は小さいが，共有構成要素は依然としてSPOF

スケーリングは高可用性（HA）と同じではありません。 容量を増やすだけでは，SPOFが除去されたりフェールオーバが提供されたりはしません。

8. 負荷分散と分散処理

• 負荷分散（ロードバランシング）：互いに独立したリクエストを同等のノードに振り分けます。
  • ラウンドロビン：リクエストをノードに順番に割り当てます。
  • 最小コネクション（least connections）：アクティブな接続数が最も少ないノードに割り当てます。
  • ヘルスチェック：定期的にノードを確認し，障害ノードを振り分け対象から外します。
• 分散処理：1つの処理を複数のノードに分割して実行します。
  • タスク分割（機能／段階による分割）とデータ分割（データ範囲による分割）。
  • 並列化は，各部分が独立している範囲でのみ時間を短縮します。
  • 調整のオーバヘッド（通信，同期，結果の統合）が加わります。
  • 部分障害：一部のノードが故障し残りは動作し続けるため，処理は失敗した部分を検知・再試行・再割当てする必要があります。

9. 障害条件と落とし穴

条件	問題となる理由
単一のロードバランサ	冗長化しなければLB自体がSPOF
共有DB／ストレージ	アプリノードをスケールアウトしても，ボトルネックかつSPOFになる
古い（stale）ヘルスチェック	次の確認で検知されるまで，障害ノードにリクエストが送られうる
ローカルのセッション状態／スティッキーセッション	そのノードが故障するとセッションが失われる。スティッキーなルーティングはフェールオーバではない
冪等でない処理の再試行	処理が重複しうる（例：二重注文）
タイムアウトの曖昧さ	タイムアウトは失敗の証拠ではない。サーバが既に処理を完了している可能性がある
データの偏り／ストラグラー	最も遅い部分が全体の完了時間を決める
ネットワーク分断	ノードは相手の故障と到達不能を区別できない。不整合のリスク
メッセージの重複／順序の入れ替わり	受信側に重複排除と順序制御が必要
一貫性／調整の要件	調整は遅延を加え，スループットを制限しうる

分散すれば信頼性や速度が自動的に向上するわけではありません。 構成要素が増えれば，障害点と調整コストも増えうるのです。

10. 例題

例題A：容量とN+1

前提：持続負荷 900リクエスト／秒，同一の各アプリケーションノードの目標レイテンシにおける検証済み利用可能容量 250リクエスト／秒，完全かつ均等な振り分け，LBや共有バックエンドのボトルネックなし，容量の低下やオーバヘッドなし。

• 平常時の最小：⌈900 / 250⌉ = ⌈3.6⌉ = 4台
• 任意の1台の喪失に耐えるには：(N − 1) × 250 ≥ 900 → N − 1 ≥ 3.6 → N − 1 ≥ 4 → N ≥ 5
• 確認：4台で1台を失うと 3 × 250 = 750 < 900（150不足）。5台で1台を失うと 4 × 250 = 1000 ≥ 900。

この計算は上記の前提の下でのみ成立します。実際の設計には余裕（ヘッドルーム）と測定（負荷テスト，監視）が必要であり，LBと共有バックエンドの容量も考慮しなければなりません。

例題B：セッションとフェールオーバ

状況：ステートレスに見えるWebノード3台（W1，W2，W3）がロードバランサの背後にありますが，セッションは各ノードのメモリにのみ保存されています。スティッキーセッションが有効です。

1. 利用者Uはスティッキーセッションによって W2 に固定され，Uのセッションは W2 のメモリにのみ存在します。
2. W2 が故障します。LBは（ヘルスチェックで検知した後）Uを W1 または W3 に送ります。
3. W1／W3 にはUのセッションがありません → Uはログアウトされるか，処理途中の状態を失います。

スティッキーセッションは同じノードへルーティングし続けるだけで，フェールオーバを提供しません。必要なもの：外部化／複製されたセッション状態（例：冗長化されたセッションストア），または安全に再構築できる状態（例：再ログイン，再取得）。

例題C：再試行と冪等性

状況：クライアントが注文（決済に類する）リクエストを送り，応答を待つ間にタイムアウトします。サーバは既に注文をコミットしている可能性があります。

• タイムアウトは失敗の証拠ではありません。 リクエストは失敗したかもしれないし，成功したが応答が失われたかもしれないし，まだ処理中かもしれません。
• 無条件の再試行は重複注文を生む可能性があります。
• 対策：クライアントはリクエストに一意の冪等キーを付け，再試行時には同じキーを再利用します。サーバは処理済みのキーを記録し，同じキーが再び来たら再処理せず最初の結果を返します（重複排除）。

例題D：並列化の上限

前提：互いに独立で，それぞれちょうど1秒かかるタスク100個，ワーカ5個，オーバヘッドゼロ，完全な均衡。

• 理想的な下限：100 × 1秒 ÷ 5 = 20秒
• この前提の下では，実際の時間は20秒以上です。調整，偏り／ストラグラー，障害は時間を増やすことしかできないためです。

現実の環境で一般にちょうど5倍速くなると主張してはいけません。20秒は上記の前提の下での下限です。

11. 関連回

• AP8（信頼性）：可用性，MTBF／MTTR，直列／並列の可用性の式はAP8で扱い，本回では繰り返しません。
• AP9（OS）：プロセス，スケジューリング，メモリ管理の内部構造はAP9で扱い，本回ではVM／コンテナ比較のためにカーネルにのみ触れます。

12. 要点シート

• VM＝仮想ハードウェア＋VMごとのゲストOS。コンテナ＝ホストカーネル共有＋プロセス／資源の隔離＋ユーザ空間のパッケージ化。
• IaaS → PaaS → SaaS：事業者が管理する層が増える。データ・アイデンティティ・アクセス・設定は常に顧客の責任。正確な境界は事業者・製品・契約によって異なる。
• スケールアップ＝より大きな機器，スケールアウト＝より多くの機器。スケーリング ≠ HA。
• 負荷分散＝独立したリクエストを振り分け，分散処理＝1つの処理を分割。
• N+1：(N − 1) × 容量 ≥ 負荷。例題A → 5台（その前提の下でのみ）。
• スティッキーセッション ≠ フェールオーバ。タイムアウト ≠ 失敗。再試行には冪等性が必要。
• 並列処理時間 ≥ 総作業量 ÷ ワーカ数（オーバヘッドゼロ・完全な均衡が理想の場合）。

13. よくある誤り

• 「コンテナは独自のOSを持つ軽量VMである」→ 誤り。ホストカーネルを共有します。
• 「SaaSなら利用者にセキュリティ責任はない」→ 誤り。データ・アカウント・アクセス・設定は利用者の責任として残ります。
• 「スケールアウトすれば高可用性になる」→ それだけではならない。LBや共有DBが依然としてSPOFでありえます。
• 「ヘルスチェックがあれば障害は見えなくなる」→ 検知遅延があり，LB自体も冗長化が必要です。
• 「スティッキーセッションがノード障害からセッションを守る」→ 守らない。ルーティングを固定するだけです。
• 「タイムアウト＝リクエスト失敗なので，そのまま再送すればよい」→ 重複が発生しえます。
• 「ワーカ5個ならちょうど5倍速くなる」→ 速度向上の理想的な上限にすぎません。

14. 演習問題（オリジナル）

問1

仮想マシン（VM）とコンテナに関する記述として，最も適切なものはどれか。

• ア：コンテナは独自のゲストOSカーネルを含む軽量なVMなので，ホストに関係なく任意のOSカーネルを実行できる。
• イ：ハイパーバイザー型の仮想化では，すべてのVMがホストOSのカーネルを共有するので，ゲストOSは不要である。
• ウ：各VMはハイパーバイザーが提供する仮想ハードウェア上でゲストOSを実行するのに対し，コンテナはホストOSのカーネルを共有しながらプロセスと資源を隔離し，アプリケーションをユーザ空間の依存関係とともにパッケージ化する。
• エ：コンテナはカーネルを共有するので，常にVMより強い隔離を提供し，したがってテナントの分離には常により良い選択である。

問2

IaaS，PaaS，SaaSの責任共有モデルに関する記述として，最も適切なものはどれか。

• ア：IaaSでは，利用者が構築した仮想マシンのゲストOSへのパッチ適用は，一般に事業者の責任である。
• イ：PaaSでは，一般に事業者がOSとランタイムまでの層を管理し，利用者はアプリケーション，データ，アクセス設定を管理する。ただし，正確な境界は事業者の規約と契約で確認する必要がある。
• ウ：SaaSでは事業者がすべてを管理するので，利用者はデータ，アカウント管理，アクセス設定に対して責任を負わない。
• エ：同じサービスモデルであれば，すべての事業者と契約で責任の境界は同一なので，契約を確認する必要はない。

問3

次の前提の下で，任意のノード1台が故障しても900リクエスト／秒を処理し続けるために必要な最小ノード数はいくつか。

前提：持続負荷 900リクエスト／秒，同一の各ノードの目標レイテンシにおける検証済み利用可能容量 250リクエスト／秒，完全かつ均等な振り分け，LBや共有バックエンドのボトルネックなし，容量の低下やオーバヘッドなし。

• ア：3
• イ：4
• ウ：8
• エ：5

問4

ロードバランサの背後にWebノードが3台ある。セッション情報は各ノードのメモリにのみ保存され，スティッキーセッションが有効である。最も適切な記述はどれか。

• ア：ノードが故障すると，そのノードのメモリにのみあったセッションは失われる。スティッキーセッションは利用者を同じノードへルーティングするだけでフェールオーバを提供しないので，セッション状態を外部化又は複製するか，安全に再構築できるようにする必要がある。
• イ：スティッキーセッションはセッションデータを他のノードに複製するので，ノードが故障してもセッションは失われない。
• ウ：振り分け方式をラウンドロビンから最小コネクションに変更すれば，ノード故障時にセッションが自動的に正常なノードへ移動する。
• エ：ヘルスチェックを設定すれば，ロードバランサは障害ノードにリクエストを決して送らず，ロードバランサ自体も単一障害点にならない。

問5

クライアントが注文リクエストを送り，応答を待つ間にタイムアウトした。サーバは既に注文をコミットしている可能性がある。最も適切な記述はどれか。

• ア：タイムアウトはサーバがリクエストを処理しなかった証拠なので，クライアントは識別子なしで同じリクエストを直ちに再送すべきである。
• イ：再試行の回数を無制限に増やせば，注文がちょうど1回処理されることが保証される。
• ウ：タイムアウトは失敗の証拠ではないので，クライアントはリクエストに冪等キーを付け，サーバは同じキーのリクエストを重複排除して最初の結果を返す。したがって，再試行しても重複注文は生じない。
• エ：注文処理をより多くのサーバに分散すれば，メッセージの重複や順序の入れ替わりが自動的になくなるので，冪等性は不要である。

15. 解答と解説

問	正解
問1	ウ
問2	イ
問3	エ
問4	ア
問5	ウ

問1 — 正解：ウ

• ア：誤り。コンテナは独自のゲストOSカーネルを持たず，ホストカーネルを共有するので，小さなVMではありません。
• イ：誤り。ハイパーバイザー型の仮想化では，各VMが仮想ハードウェア上で独自のゲストOSを実行します。
• ウ：正解。 VM（仮想ハードウェア＋ゲストOS）とコンテナ（ホストカーネル共有＋隔離＋ユーザ空間のパッケージ化）の違いを正確に述べています。
• エ：誤り。カーネルの共有は一般に隔離境界を強くするのではなく弱くし，「常に」という絶対的表現は成立しません。

問2 — 正解：イ

• ア：誤り。IaaSでは，ゲストOSは一般に利用者の責任です。
• イ：正解。 標準的なPaaSの境界と一致し，正確な境界は事業者と契約によって異なるという留保も含んでいます。
• ウ：誤り。SaaSでも，データ，アカウント，アクセス権，設定は利用者の責任として残ります。
• エ：誤り。正確な境界は事業者，製品，契約によって異なります。

問3 — 正解：エ（5）

• ア：誤り。3 × 250 = 750 < 900 なので，3台では平常時の負荷も処理できません。
• イ：誤り。4は平常時の最小（⌈900/250⌉ = 4）ですが，1台を失うと 3 × 250 = 750 < 900 です。
• ウ：誤り。8（4の2倍）は要件を満たしますが，最小ではありません。
• エ：正解。 (N − 1) × 250 ≥ 900 → N ≥ 5。1台を失っても 4 × 250 = 1000 ≥ 900。明示した前提の下でのみ有効です。

問4 — 正解：ア

• ア：正解。 ローカルメモリのセッションはノード故障時に失われ，スティッキーセッションはフェールオーバを提供しません。
• イ：誤り。スティッキーセッションはルーティングを固定するだけで，セッションデータを複製しません。
• ウ：誤り。振り分けアルゴリズムは新しいリクエストの送り先を決めるだけで，セッション状態を移動しません。
• エ：誤り。ヘルスチェックには検知遅延（古い状態）があり，ロードバランサは冗長化しなければSPOFです。

問5 — 正解：ウ

• ア：誤り。タイムアウトは失敗の証拠ではなく，識別子なしで再送すると注文が重複しえます。
• イ：誤り。無制限の再試行は重複と負荷のリスクを高めるだけで，ちょうど1回の処理を保証しません。
• ウ：正解。 冪等キーとサーバ側の重複排除によって，再試行を安全にします。
• エ：誤り。分散はメッセージの重複／順序の入れ替わりをなくさず，むしろ増やしえます。

16. セルフチェック

• コンテナが小さなVMではない理由を1文で説明できる。
• IaaS/PaaS/SaaSの責任マトリクスを埋め，契約に関する留保を述べられる。
• スケールアップとスケールアウトのボトルネック・障害の影響範囲の違いと，スケーリング ≠ HA である理由を述べられる。
• 負荷分散と分散処理を区別し，部分障害の問題を3つ挙げられる。
• 例題Aで N ≥ 5 を導出し，その前提を述べられる。
• スティッキーセッションがフェールオーバではない理由を説明できる。
• タイムアウト後の無条件の再試行で注文が重複しうる理由と，冪等キーがそれを防ぐ方法を説明できる。
• 例題Dの20秒が下限である理由を説明できる。

17. 1/3/7日復習計画

時点	やること
1日目	要点シートを読み直し，責任マトリクスとスケールアップ／アウトの表を記憶から描き直し，問1–5を解き直す。
3日目	例題AとDを見ずに導出し直し，例題BとCを声に出して説明し，よくある誤りを復習する。
7日目	問1–5を解き直して各誤答選択肢が誤りである理由を説明し，セルフチェックを完了し，AP8／AP9の関連回を簡単に見直す。

18. 出典

• IPA，応用情報技術者試験（レベル3）シラバス Ver.7.2（公式PDF，印刷ページ 20–21，32，56，107）：https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kq5-att/syllabus_ap_ver7_2.pdf （確認日 2026-10-21）