【システム構成】キャッシュを爆速にする自然の法則！「局所性の原理」｜情報処理問題1000本ノック

コンピュータのメモリやキャッシュが驚異的なヒット率を叩き出せる理由。プログラムが持つデータの「偏り」の性質である「局所性」を攻略しましょう。

1. 【 問題 】：プログラムのアクセス特性と局所性

【 問題 】 コンピュータのCPUがメモリ上のデータや命令にアクセスする際、アクセスされる領域が時間的、または空間的に特定の部分に集中しやすいという性質を「局所性の原理（Principle of Locality）」と呼びます。このうち、「一度アクセスされたデータや命令は、近い将来（短い時間の間）に再びアクセスされる確率が非常に高い」という性質を表す言葉として、最も適切なものはどれでしょうか？

① 空間的局所性 (Spatial Locality)
② 時間的局所性 (Temporal Locality)
③ 順次局所性 (Sequential Locality)
④ 構造的局所性 (Structural Locality)

2. 正解：

正解： ② 時間的局所性（Temporal Locality）

3. 解説：「時間」の偏りと「場所」の偏りの2大巨頭

局所性の原理には、午前試験で対比されて出題される2つの重要な側面があります。今回の正解である時間的局所性と、もう1つの空間的局所性です。

【局所性の2大分類】

・② 時間的局所性（時間的な偏り）：「さっき使ったデータ（命令）は、すぐまた使う」という性質です。プログラムの『ループ処理（for文やwhile文）』の中で何度も繰り返し使われるカウンタ変数や、同じ命令の塊などがこれに該当します。 ← ココが問題の正解！

・① 空間的局所性（場所的な偏り）：「あるデータにアクセスしたら、そのすぐ近くの番地にあるデータも続けて使う」という性質です。配列データを先頭から順番に処理していく場合や、関連する命令がメモリ上に並んでいる（ステップ順に実行される）場合がこれに該当します。

[ キャッシュメモリやDBMSがこの性質をどう活かしているか ]
★ 時間的局所性の応用：一度読み込んだデータを高速なキャッシュメモリやデータベースバッファ（メモリ）に残しておけば、2回目以降のアクセスを劇的に速くできます。
★ 空間的局所性の応用：直前の問題で学んだDBMSの「ページ管理」のように、1箇所データが必要になったら、周辺のデータごと「塊（ページやブロック）」でまとめてメモリに持ってきておくことで、後からディスクを何度も読み直す無駄を省けます。

1. 理解のコツ: 「仕事のデスクワーク」に例えてみましょう。
・さっきまで使っていた「ハサミ」や「辞書」を、片付けずにデスクの特等席（キャッシュ）に置いておけば、数分後にまた使うとき（時間的局所性）に一瞬で手に取れますよね。これが時間的局所性です。
・また、本棚から「1巻」を取り出したなら、次は隣にある「2巻」や「3巻」を使う可能性が高い（空間的局所性）ため、あらかじめシリーズごとまとめて机に持ってきておく。これが空間的局所性です。
2. 試験対策の視点: 「最近利用したデータや命令を再度利用する確率が高い」＝時間的局所性、「一度アクセスしたデータの近くが使われやすい」＝空間的局所性、という2つの違いを正確にハサミと本棚のイメージで区別できるようにしてください。ITパスポートから基本情報、応用情報の午前試験において、キャッシュメモリのヒット率の計算問題や、OSの仮想記憶（ページング）、DBMSのパフォーマンス向上を説明するすべての「大前提の自然法則」として超頻出する重要理論です。

---

4. まとめ

「プログラムの動きには強い偏りがあり、最近触ったデータ（時間的局所性）や、その周辺のデータ（空間的局所性）が何度も集中して使われるという性質」。これが局所性の原理です。コンピュータが1秒間に何億回もの処理をこなせるのは、この局所性を見抜いた天才たちが、ハードウェアやDBMSの内部に「先回りしてデータを置いておく仕組み（キャッシュ）」を組み込んでくれたおかげです。

【システム構成】障害を検知して自動バトンタッチ！「フェイルオーバー」｜情報処理問題1000本ノック

24時間止まらないシステムを作るための鉄板技術。メイン機が倒れた瞬間に、予備機が自動でその座を引き継ぐ「フェイルオーバー」のメカニズムを攻略しましょう。

1. 【 問題 】：システムの冗長化と切り替え技術

【 問題 】 サーバーやネットワーク機器、データベースなどのシステム構成において、稼働中のメインシステム（現用系）に重大な異常や障害が発生した際、システムがそれを自動的に検知し、あらかじめ用意しておいた予備のシステム（待機系）へと処理や設定を自動で切り替えることで、サービスを中断せずに継続させる仕組みはどれでしょうか？

① フェイルバック (Failback)
② フェイルオーバー (Failover)
③ フェイルセーフ (Fail-safe)
④ フォールバック (Fallback / 縮退運転)

2. 正解：

正解： ② フェイルオーバー（Failover）

3. 解説：「自動切り替え」こそが可用性のカナメ

高信頼性システム（アクティブ・スタンバイ構成など）では、機材が壊れることを前提に同じものを2組用意します。このとき、障害発生時のバトンタッチを自動で行うのがフェイルオーバーです。

【フェイルオーバー（自動切り替え）の動作と対比】

・② フェイルオーバー（Failover）：メイン機（アクティブ）が心不全などで倒れた瞬間、裏で待機していた予備機（スタンバイ）が「あ、メイン機が死んだ！」と察知し、自動的にメイン機のIPアドレスやデータを引き継いで動き出します。利用者は、一瞬の瞬き程度の時間でそのままサービスを使い続けられます。 ← ココが問題の正解！

・① フェイルバック（Failback）：フェイルオーバーした後に、壊れたメイン機を修理して元通りに直し、「予備機から、元のメイン機へと処理を戻す（復旧させる）」作業のことです。

[ 選択肢のひっかけポイント（名前が似ている超頻出用語） ]
★ ③ フェイルセーフ：システムが故障した際、とにかく「安全な状態」に移行して止まる設計思想（例：赤信号にして止まる鉄道信号など）です。自動切り替えで運転を続けるものではありません。
★ ④ フォールバック（フェイルソフト）：予備機への切り替えではなく、壊れた部分を切り離し、残った正常な部分だけで「機能を落として（縮退して）でも動かし続ける」ことです。

1. 理解のコツ: 「劇の主役とアンダースタディ（代役）」に例えてみましょう。舞台の上で主役（メイン機）が突然倒れてしまったとき、スタッフが慌てて劇を止めるのではなく、舞台袖で衣装を着てスタンバイしていた代役（予備機）が自動的（即座）にスポットライトの下へ飛び出して、何事もなかったかのように劇（サービス）を続行する。この、裏方による見事なスイッチングがフェイルオーバーです。
2. 試験対策の視点: 「異常（障害）が発生したとき」「自動で冗長構成（予備系）へ切り替わる」というキーワードが出たらフェイルオーバーが一択です。基本情報や応用情報の「システム構成要素」の午前試験では、前述の「フェイルバック」や「フォールバック」と名前が非常に似ているため、それぞれの言葉が持つ「方向（行くのか、戻るのか、縮むのか）」を明確に区別しておくことが得点力を直結させるカギになります。

---

4. まとめ

「システム障害の瞬間に、人間がサーバー室に駆けつけることなく、システム自身の力で予備機へと自動でバトンタッチする仕組み」。これがフェイルオーバーです。クラウドサービスや24時間稼働のオンライン銀行など、私たちの生活インフラが「いつでも当たり前に動いている」裏側には、このフェイルオーバーの技術が網の目のように張り巡らされています。

【システム構成】起きてしまった衝撃から命とデータを守る！「パッシブセーフ」｜情報処理問題1000本ノック

安全設計の双璧をなす思想。どれだけ予防しても「事故や障害は100%発生する」という前提に立ち、発生した瞬間の被害を最小限に抑える設計を攻略しましょう。

1. 【 問題 】：システムの安全性と被害軽減思想

【 問題 】 システム構成や製品の安全設計（セーフティ設計）において、事故、衝突、機器の破壊といった危険な事象が「発生したとき」に、人体（乗員やオペレーターなど）への被害や致命的な損害を最小限に抑えることを目的とした、受動的な安全の考え方はどれでしょうか？

① アクティブセーフ（能動的安全）
② パッシブセーフ（受動的安全）
③ フェールセーフ（安全側への制御）
④ フォールトトレラント（耐障害性）

2. 正解：

正解： ② パッシブセーフ（受動的安全 / 衝突安全）

3. 解説：「もしも」の瞬間に働く最後の防護壁

安全設計の思想において、最も重要な対比が「事故を未然に防ぐアクティブセーフ」と、今回の正解である「起きた後の被害を最小にするパッシブセーフ」です。

【システム構成におけるパッシブセーフの具体例】

パッシブセーフは、主に「物理的な破壊や衝撃」が人や設備に及ぶのを防ぐために導入されます。

・製品・ハードウェアの例：自動車のエアバッグ、シートベルト、衝撃吸収ボディ、あるいは工場内でロボットの暴走時に作業員を守る物理的な防護フェンス（安全柵）など。 ← ココが問題の正解！
・ITインフラの例：落雷の超過電圧から内部基盤を身代わりとなって守る避雷器（サージプロテクタ）、データセンターが火災になった際に、ガスを噴射して機材へのダメージを最小限に抑えつつ消火する設備など。

[ 選択肢のひっかけポイント（混同しやすい安全思想） ]
★ ① アクティブセーフ：危険自体を「未然に防ぐ」能動的な設計（自動ブレーキやAIの障害予測など）です。
★ ③ フェールセーフ：装置が故障したときに、システム全体を「常に安全な状態（停止など）」に移行させる設計です。
★ ④ フォールトトレラント：部品が壊れても、予備の部品が即座にバックアップすることで、システム全体を一切止めずに動かし続ける設計です。

1. 理解のコツ: 「自転車のヘルメット」をイメージしてください。ヘルメットを被っていても、転倒（事故）そのものを防ぐことはできません。しかし、運悪く転んで頭を地面にぶつけてしまったその瞬間に、衝撃を吸収して**体（頭部）への被害を最小に抑えてくれます**。この「受動的（パッシブ）に衝撃を受け止めて守る」仕組みがパッシブセーフです。
2. 試験対策 the 視点: 「事故などの発生時」「体（人命）への被害を最小に抑える」というフレーズがあればパッシブセーフが正解です。情報処理技術者試験では、ITシステムそのものの可用性（フェールセーフやフォールトトレラント）だけでなく、工場を制御するシステム（OT分野）やIoT機器の安全性を問う問題として、このパッシブ/アクティブの概念がよく狙われます。

---

4. まとめ

「事故の発生を前提とし、激突や破壊が起きた瞬間に人体やコア設備への深刻なダメージを最小限に食い止める防衛システム」。これがパッシブセーフです。アクティブセーフ（予防）とパッシブセーフ（事後緩和）の両輪が揃うことで、初めて人間の命や社会インフラを預かる頑強なシステムが完成します。

【システム構成】サーバーも「コード」で書く時代！「IaC」｜情報処理問題1000本ノック

マウスでポチポチ設定するのではなく、テキストファイルに設計図を書いてコマンド一つでインフラを立ち上げる。効率化の極致「IaC」を攻略しましょう。

1. 【 問題 】：インフラ構成の自動化

【 問題 】 サーバーの構築やネットワーク設定などのインフラ構成を、手作業ではなく設定ファイル（コード）を用いて定義し、実行ツールによって自動的に構築・管理する手法を何と呼ぶでしょうか？

① SaaS (Software as a Service)
② IaC (Infrastructure as Code)
③ PaaS (Platform as a Service)
④ IaaS (Infrastructure as a Service)

2. 正解：

正解： ② IaC（Infrastructure as Code）

3. 解説：インフラを「ソフト」のように扱う

IaCは、その名の通り「インフラをコードとして管理する」ことです。これにより、プログラム開発と同じような恩恵をサーバー管理にも持ち込めます。

【IaCによって得られる4つのメリット】

■ 再現性
・同じコードを実行すれば、誰でも、何度でも、全く同じ環境が作れます。

■ 自動化・高速化
・100台のサーバーもコマンド一つで数分のうちに立ち上がります。

■ 履歴管理（バージョン管理）
・Gitなどのツールを使い、「いつ、誰が、どこを変えたか」の履歴がすべて残ります。

■ イミュータブル・アーキテクチャの実現
・「直すより作り直す」が簡単にできるのは、コードですぐに新品が作れるからです。

[ 代表的なツール例 ]
★ Terraform：クラウド全体の構成を定義する。
★ Ansible：OSの中身（ソフトのインストール等）を設定する。
★ CloudFormation：AWS専用のIaCサービス。

1. 理解のコツ: 料理で例えると、「自分の勘で味付け（手動設定）」するのではなく、「完璧なレシピ（コード）」を作っておくようなものです。レシピがあれば、誰が作っても、何度作っても、分店（別環境）を出しても同じ味を再現できます。
2. 試験対策の視点: 「設定ファイルで定義」「自動構築」「バージョン管理が可能」といった言葉が出たらIaCです。IaaS（サービスとしてのインフラ）という言葉と似ていますが、IaCは「やり方（手法）」、IaaSは「提供されるモノ」と区別しましょう。

---

4. まとめ

「インフラの構成をコード化し、自動で構築・管理する」。これがIaCです。開発と運用の壁をなくす「DevOps」を支える、現代ITインフラの土台となる考え方です。

【システム構成】使い捨てが生む安定性！「イミュータブル・アーキテクチャ」｜情報処理問題1000本ノック

「壊れたら直す」のではなく「新しいものに置き換える」。インフラ運用の常識を覆した、モダンな設計思想を攻略しましょう。

1. 【 問題 】：インフラ設計の新常識

【 問題 】 サーバーなどのインフラ構成を変更する際、稼働中のOSやソフトウェアを修正（更新）するのではなく、常に新しい環境を構築して丸ごと入れ替えるという設計手法を何と呼ぶでしょうか？

① モノリシック・アーキテクチャ
② サーバーレス・アーキテクチャ
③ イミュータブル・アーキテクチャ
④ マイクロサービス・アーキテクチャ

2. 正解：

正解： ③ イミュータブル・アーキテクチャ（Immutable Architecture）

3. 解説：「不変（Immutable）」という最強の防御

「イミュータブル」とは「不変（変わらない）」という意味です。一度動かしたサーバーには二度と手を加えない（変更しない）のがこの手法の核です。

【対比：これまでの運用 vs イミュータブル】

■ 従来の運用（ミュータブル / 可変）
・稼働中のサーバーにログインして設定変更やパッチ適用を行う。
・弱点：長年運用すると、設定が複雑に入り組み「秘伝のタレ」化して再現不能になる。

■ イミュータブル・アーキテクチャ（不変）
・変更が必要なら、新しい設定のサーバーを別に作り、古いものと交換して捨てる。
・利点：常に「新品」の状態で動くため、環境の不整合が起きず、復旧や複製が容易。

[ 関連キーワード ]
★ Blue-Green Deployment：新旧の環境を並行して作り、ロードバランサーで一気に切り替える手法。イミュータブルな運用の代表例。
★ IaC (Infrastructure as Code)：コードから同じ環境を何度でも作れる技術が、このアーキテクチャを支えています。

1. 理解のコツ: 昔のテレビ（ブラウン管）が壊れたら近所の電気屋さんが裏蓋を開けて修理していましたが、今のスマホは壊れたら「本体交換」で対応することが多いですよね。あの「直さず新品に替える」という発想がイミュータブル・アーキテクチャです。
2. 試験対策の視点: 「変更（更新）せずに作り直す」「不変」「構築済みのサーバーを破棄」という表現が出てきたらこの用語を選びましょう。Dockerなどのコンテナ技術の説明とセットで出ることが多いです。

---

4. まとめ

「一度作った環境には手を加えず、変更のたびに作り直す」。これがイミュータブル・アーキテクチャです。クラウド時代のインフラ運用において、再現性と信頼性を高めるための必須知識と言えます。

【システム構成】再開までのタイムリミット！「RTO」｜情報処理問題1000本ノック

システムが止まったとき、ビジネスを止めてもいい「制限時間」を定義する重要指標を攻略しましょう。

1. 【 問題 】：目標復旧時間（RTO）

【 問題 】 システム障害が発生した際、業務を再開するまでに要する時間の目標値を何と呼ぶでしょうか？

① RPO (Recovery Point Objective)
② RTO (Recovery Time Objective)
③ MTBF (Mean Time Between Failures)
④ SLA (Service Level Agreement)

2. 正解：

正解： ② RTO（Recovery Time Objective）

3. 解説：キーワードは「いつまでに直すか」

RTOは、障害発生から「業務再開」までの経過時間に関する目標です。この値が短いほど、高度な復旧体制が必要になります。

【図解：RTOの考え方】

■ RTO (Recovery Time Objective)
・焦点：サービス停止の「期間」。
・決まり方：予備機の準備状況や復旧手順の習熟度で決まる。

■ 混同しやすい RPO との違い
・RPO (目標復旧時点)：「いつのデータ」まで戻せるか。（過去への遡り）
・RTO (目標復旧時間)：「いつまでに」直せるか。（未来への所要時間）

[ 現場での考え方 ]
★ 「RTOを10分にする」：自動切り替えなどの高価な仕組み（ホットスタンバイ）が必要。
★ 「RTOを3日にする」：サーバーを新しく買ってきてセットアップする時間がある。

1. 理解のコツ: 料理で例えると、冷蔵庫が壊れてから「何時間以内に修理を終えて、再び冷やし始めるか」がRTOです。その間、中身の食材（ビジネス）が傷まないうちに再開しなければなりません。
2. 試験対策の視点: 「業務再開までの時間」「サービス停止の許容期間」という表現があればRTOが正解です。RPO（Point＝時点）とRTO（Time＝時間）の頭文字を絶対に入れ替えないよう注意しましょう。

---

4. まとめ

「障害発生からサービスを復旧させるまでの目標時間」。これがRTOです。RPOとともに、システムの冗長性（バックアップサイトをどこまで作り込むかなど）を決定する際の最も重要な基準となります。

【ネットワーク】システムの生存確認！「ハートビート」｜情報処理問題1000本ノック

心臓の鼓動（Heartbeat）のように、一定の間隔で信号を送ることで、相手が正常に動いているかを遠隔で監視する仕組みを攻略しましょう。

1. 問題：稼働状況の確認手法

【 問題 】 ネットワークに接続されたコンピュータやソフトウェアが、外部に対して「自分は正常に稼働している」ことを知らせるために、一定の間隔で送信する信号のことを何と呼ぶでしょうか？

ア、ハンドシェイク   イ、ハートビート   ウ、キープアライブ   エ、ポーリング

2. 正解：可用性管理に関する正解

正解： イ、ハートビート（Heartbeat）

3. 解説：沈黙は「異常」のサイン

ハートビートは、特に冗長化（二重化）されたシステムにおいて、相方の故障を検知するために非常に重要です。

【図解：ハートビートの役割と仕組み】

■ 生存確認の流れ
・稼働中のサーバーが、監視役の装置へ定期的に「トントン（生きてるよ）」と短いパケットを送ります。
・信号が途切れた（一定時間届かない）場合、監視役は「あいつは死んだ（故障した）」と判断します。

■ 活用例：フェイルオーバー
・メイン機からのハートビートが途絶えた瞬間、待機していたサブ機が「自分の出番だ！」と判断して処理を引き継ぎます。

[ 紛らわしい用語との違い ]
★ キープアライブ：通信セッションを維持するために送る信号。ほぼ同じ意味で使われることもありますが、ハートビートはより「システムの死活監視（OSやアプリが生きてるか）」の文脈で使われます。
★ ポーリング：監視側が「生きてる？」と毎回聞きに行くこと。ハートビートは基本、自分から「生きてるよ！」と発信するスタイルです。

1. 理解のコツ: 登山のパーティで、先頭の人が後ろの人に向かって「おーい！」と声を出し続けるようなものです。声（信号）が聞こえなくなったら、何かトラブルがあったとすぐにわかります。
2. 試験対策の視点: 「一定間隔で送信」「正常稼働の通知」「死活監視」という言葉がキーワードです。高可用性（HA）クラスター構成の話題とセットで登場することが多い用語です。

---

4. まとめ

「ネットワーク上で稼働状況を知らせるために送る信号」。これがハートビートです。システムが沈黙した瞬間に異常を検知し、素早く切り替える。そんな「止まらないシステム」を支える心臓の鼓動です。

【システム構成】サービスを止めずに進化させる！「ローリングアップデート」｜情報処理問題1000本ノック

システム全体を一時停止させる「計画停止」は、現代の24時間365日稼働するサービスでは許容されないことが増えています。無停止で新バージョンへ切り替える手法を攻略しましょう。

1. 問題：稼働継続とアップデートの両立

【 問題 】 複数のサーバーやノードで構成されるシステムにおいて、稼働中のノードを一つ、あるいは数個ずつ順番に新しいバージョンへと入れ替えていく手法を何と呼ぶでしょうか？

ア、一斉アップデート   イ、ブルーグリーンデプロイメント   ウ、ローリングアップデート   エ、カナリアリリース

2. 正解：リリース管理に関する正解

正解： ウ、ローリングアップデート（Rolling Update）

3. 解説：サービスを維持しながら「波」のように更新する

「Rolling」という名の通り、車輪が転がるように次々と対象をスライドさせて更新していきます。

【図解：ローリングアップデートの手順】

■ 手順
1. 全4台のうち、まず1台を切り離してアップデートし、復帰させる。
2. 残りの旧バージョンが動いている間に、次の1台をアップデートする。
3. これを繰り返し、最終的にすべてのノードを新バージョンに置き換える。

■ メリット
・システム停止が不要：常に一部のノードが稼働しているため、ユーザーはサービスを使い続けられます。
・リソース効率が良い：予備のサーバー群を丸ごと用意する必要がなく、既存のリソース内で完結できます。

[ 比較して覚えたい：ブルーグリーンデプロイメント ]
★ ブルーグリーン：現行環境（Blue）と同じ規模の新しい環境（Green）を丸ごと用意し、ロードバランサーの向きを一気に切り替える手法。瞬時に切り替わりますが、2倍のリソースが必要になります。

1. 理解のコツ: 4人組のアイドルグループが、一人ずつ順番に舞台裏で着替えてステージに戻るようなイメージです。常に誰かが歌っている（サービスが動いている）ため、ライブ（システム）を止める必要がありません。
2. 試験対策の視点: 「順番に」「一部ずつ」「システム停止を避ける」というフレーズが特徴です。クラウドやマイクロサービスの運用において、最も一般的なデプロイ方法の一つとして頻出します。

---

4. まとめ

「複数のノードを順番に更新し、サービスを維持する」。これがローリングアップデートです。ユーザーに不便を強いることなく、常に最新の機能やセキュリティパッチを適用し続けるための、止まらないシステム運営の基本技術です。

【システム構成】二度届いても動じない！「冪等性（べきとうせい）の担保」｜情報処理問題1000本ノック

ネットワークの不安定な環境では、同じリクエストが重複して届くことは珍しくありません。そんな時、システムが二重処理を防ぎ、常に正しい結果を保つための必須概念を攻略しましょう。

1. 問題：重複リクエストへの耐性

【 問題 】 ある操作を1回行っても、失敗したと思って複数回繰り返して行っても、結果が常に同じ（副作用が1回分しか発生しない）ようになる性質を何と呼ぶでしょうか？

ア、一貫性（Consistency）   イ、可用性（Availability）   ウ、冪等性（Idempotency）   エ、原子性（Atomicity）

2. 正解：システム設計・APIに関する正解

正解： ウ、冪等性（べきとうせい）

3. 解説：「何度やっても結果が同じ」という安心感

特に決済システムやメッセージキューを利用した分散システムにおいて、冪等性の担保は設計上の最優先事項の一つです。

【図解：冪等性がある場合とない場合】

■ 冪等性がない例（銀行振込）
・「1万円送金する」という命令を2回送ると、2万円引き落とされる。
・通信エラーで結果が分からない時に再送するのが怖くなる。

■ 冪等性を担保した例
・命令に「リクエストID：A100」を付与する。
・サーバー側で「A100は処理済み」と記録しておけば、2回目が届いても「既に完了しています」と安全に回答できる。

[ HTTPメソッドと冪等性 ]
★ GET, PUT, DELETE：原則として冪等であるべきとされています（何度消しても、無い状態は変わらない）。
★ POST：原則として冪等ではありません（送るたびに新しいデータが作られる可能性がある）。

1. 理解のコツ: エレベーターの「行先階ボタン」をイメージしてください。1回押しても、連打しても、結局その階に止まるという「結果」は変わりません。これが冪等性です。
2. 試験対策の視点: 「同じデータが複数回届いても正常に処理できる」「ある操作を何度繰り返しても結果が同一」という表現があれば冪等性です。分散システムにおける「リトライ処理」とセットで出題されることが多いです。

---

4. まとめ

「同じデータが複数回届いても、正常に処理できることを担保する」。これが冪等性（べきとうせい）です。ネットワークの「もしも」を想定し、二重実行によるデータの不整合を防ぐ、堅牢なシステム設計の要（かなめ）です。

【システム構成】止まらない仕組みの二大巨頭！「冗長化の構成方式」｜情報処理問題1000本ノック

システムを多重化する際、予備の機材をどう待機させておくかによって、コストや性能、切り替え時間が大きく変わります。現場でも頻出の2つの構成をマスターしましょう。

1. 問題：冗長化構成の分類

【 問題 】 クラスター構成において、複数のコンポーネントがすべて同時に稼働し、通常時から負荷を分散して処理を行う方式を［   A   ］、稼働系（Active）のみが処理を行い、待機系（Standby）は故障時に備えて待機する方式を［   B   ］と呼びます。空欄に入る適切な組み合わせはどれでしょうか？

ア、A：アクティブ・スタンバイ　B：アクティブ・アクティブ
イ、A：アクティブ・アクティブ　B：アクティブ・スタンバイ
ウ、A：ホットスタンバイ　　　　B：コールドスタンバイ
エ、A：デュプレックスシステム　B：デュアルシステム

2. 正解：高可用性設計に関する正解

正解： イ、A：アクティブ・アクティブ　B：アクティブ・スタンバイ

3. 解説：効率重視か、確実性重視か

それぞれの方式には、リソースの活用効率や障害発生時の挙動に明確な違いがあります。

【図解：2つの冗長化方式】

■ Active-Active（アクティブ・アクティブ） ★A
・状態：すべての機器が同時に稼働。
・メリット：複数台で処理を分担（負荷分散）するため、システム全体の性能が高まる。無駄なリソースがない。
・注意点：1台故障すると、残った方の負荷が急増し、性能が低下する可能性がある。

■ Active-Standby（アクティブ・スタンバイ） ★B
・状態：1台が本番用として働き、他方は予備として待機。
・メリット：構成がシンプルで、切り替え後の性能変化が予測しやすい。
・注意点：通常時は予備機が何も処理しないため、リソースのコストパフォーマンスは低い。

[ スタンバイ側の「温まり具合」による分類 ]
アクティブ・スタンバイは、待機状態によってさらに細分化されます。
★ ホットスタンバイ：予備機もOSを起動し、即座に切り替え可能。
★ ウォームスタンバイ：OSは起動しているが、アプリケーションは準備中。
★ コールドスタンバイ：予備機は電源オフ（または別の用途で使用）。

1. 理解のコツ: アクティブ・アクティブは「2人で協力して荷物を運ぶ」イメージ、アクティブ・スタンバイは「1人が運び、もう1人は後ろからついてくる（交代要員）」イメージです。
2. 試験対策の視点: 「負荷分散（ロードバランシング）」というキーワードがあればアクティブ・アクティブ、「切り替え（フェイルオーバー）」という言葉が強調されていればアクティブ・スタンバイを意識しましょう。また、デュアルシステム（同じ処理を2系統で行い結果を照合）との違いもよく問われます。

---

4. まとめ

「全員で働くか、予備を置いておくか」。これがActive-ActiveとActive-Standbyの違いです。システムの要求性能やコスト、許容されるダウンタイムに応じて、最適な構成を選択することが設計の鍵となります。