CAP定理の「A」はインフラの「可用性」と全くの別物である

それぞれの概念が何を「前提」としているかを整理する。

インフラの可用性：物理的な生存

「サーバーが動いているか」「電源が入っているか」「ユーザーのパケットが届くか」という物理的な生存を指す。

インフラエンジニアが「可用性を上げる」と言うとき、それは二重化や冗長構成によって、物理的な無反応（タイムアウト）を防ぐことを意味する。

CAPの可用性：論理的な振る舞い

インフラの可用性が前提として満たされている世界の話である。

• すべての物理サーバーは正常稼働している
• ユーザーから各サーバーへのパケットは届く
• しかし、サーバー同士はパケットをやり取りできない（ネットワーク分断）

CAPが問うのはこの状態、つまり外からは繋がっているが、内側でノード間の通信が途絶えた状態における振る舞いである。リクエストを受けたノードが何らかのレスポンスを返せるか、を問う。

可用性という言葉の定義が違えば、「可用性がない」が意味する状態も変わる。

インフラの可用性がない：pingが通らない

サーバーが落ちている、ネットワークが切れている。pingが届かない、telnetが繋がらない。ユーザーはタイムアウトを受け取り、接続自体が成立しない。物理的な断絶の問題である。

CAPの可用性がない：500番台エラーが返る

サーバーは生きており、ユーザーからのパケットも届いている。しかし、一貫性を守るために応答を「拒否」する。実務上は500番台のエラーが返ってくる状態がこれにあたる。

物理的な断絶ではなく、論理的な仕様の選択である。

「可用性を上げる」という言葉の意味も、文脈によって全く異なる。

インフラの可用性を上げる

「サーバーが止まらないようにする」ことが目的であり、そのための手段が物理的な障害点の排除である。ハードウェアとインフラ構成で対処する問題である。

• 冗長化・マルチAZ構成
• ハードウェアの信頼性向上
• ロードバランサーの導入

CAPの可用性を上げる

CAP定理では、ネットワーク分断が発生した場合、一貫性（全ノードが同じデータを返すか）と可用性（必ずレスポンスを返すか）のどちらかしか保証できない。「CAPの可用性を上げる」とは、この二択において可用性を優先する設計判断である。つまり、古いデータを返してでもレスポンスを返すことを選ぶ。ビジネス上「古いデータを見せても許容できるか」という問いへの答えがそのまま設計になる。

• 結果整合性（Eventual Consistency）の採用
• 分断時でも古いデータを返す、という仕様の明示的な定義

インフラの問題はハードウェアで解決できる。CAPの問題はアルゴリズムとビジネス判断でしか解決できない。

• インフラの可用性 = 「サーバーが物理的に動いているか」（停止・タイムアウトの防止）
• CAPの可用性 = 「分断時に、一貫性を犠牲にしてでもレスポンスを返すか」（論理的なトレードオフ）