はじめに：品質特性とはなにか

クラウドシステムを設計・運用する際、「可用性（availability）」「耐久性（durability）」「レイテンシー（latency）」は必ずといってよいほど登場するキーワードです。
ただし、これらは「何となく言われているから使う」だけでは誤解を招きやすい性質があります。本記事では、Google Cloud のサービス文脈を踏まえつつ、これらの意味、相互関係、実践上の考え方を整理します。

可用性 (Availability)

定義と意味

可用性とは、「システムがユーザーの要求に応じられる状態である割合（％）」を指します。
つまり、ダウンタイム（停止時間や障害発生時間）を除いた稼働時間の比率です。
可用性 = (稼働時間) ÷ (総時間)

Google Cloud での考え方

Google Cloud の多くのマネージドサービス（Compute, Storage, Database など）は、SLA（サービス品質保証）として可用性パーセンテージを公式に提供しています。
例：Cloud Spanner は 99.999% の可用性を標榜していることがあります（構成やリージョンによる制限あり）。

ただし、実際の可用性は設計次第です。可用性を高める手法としてよく使われるものを以下に示します：

• マルチリージョン構成：複数の地理的リージョンにレプリカ配置し、リージョン障害への耐性を持たせる
• フェイルオーバー設計：障害発生時に別ノード／リージョンに即座に切り替える仕組み
• 冗長性の確保：複数インスタンス、複数ゾーンへの分散配置
• 健全性チェック・自動復旧：障害を自動検知して再起動や再構成を行う仕組み

可用性と耐久性の違い

同じくクラウド品質指標で語られる「耐久性」と混同されがちですが、可用性は「アクセス可能である時間の割合」、耐久性は「データが失われない性質・保証」を指します。
可用性が高くても、耐久性が低いとデータ損失リスクが残ります。逆もまた同様です。

耐久性 (Durability)

定義と意味

耐久性とは、「データ（または状態）が失われないこと」の性質・保証を指します。
たとえば「100 年後も変えず存在しうる」という意味で語られることもありますが、クラウドサービスでは通常「99.999999999 % の確率でデータが消失しない」といった数値で表されます（“11 9’s” や “12 9’s” など）。

Google Cloud での表現例

典型例として **Cloud Storage** では、オブジェクトを保存する際の耐久性保証が「11 9’s（99.999999999%）」という数値で提示されています。
これは、たとえ機器が壊れても別の装置に自動複製や修復を行う内部仕組みによって、データ消失確率を極めて小さく保つ設計がされているという意味です。

耐久性を確保する手法

耐久性を高めるには、データレプリケーションやバックアップの構成が契約要件に合致しているかを設計段階で検討すべきです。具体的な方法例を挙げます：

• マルチゾーン／マルチリージョンへの自動レプリケーション
• バージョン管理・オブジェクトの世代管理（世代保存、変更差分バックアップ）
• 定期バックアップ＋別リージョン保管
• 整合性チェック・データ検証（サルベージ手法、エラー検出と修復）

レイテンシー (Latency)

定義と意味

レイテンシーとは、処理・通信における「遅延時間」を指します。
具体的には「要求（リクエスト）を出してから応答（レスポンス）が返ってくるまでの時間」がこれに当たります。

Google Cloud におけるレイテンシー要因

クラウド環境では、レイテンシーに影響を与える主な要因がいくつかあります：

• 物理距離（ユーザー → リージョン／ゾーンへの距離）
• ネットワーク経路／ISP 遅延
• サービス内部の処理遅延（キューイング、ロードバランサ、ソフトウェアレイヤ）
• アイドル状態（ウォームアップ、キャッシュ生成）
• 負荷状況（ピーク時のリソース逼迫）

レイテンシーの最適化戦略

レイテンシーを抑えるためのアプローチとして、以下がよく使われます：

• エッジロケーション利用（Cloud CDN, Cloud Edge など）
• リージョン選定（ユーザーに近いリージョンを使う）
• キャッシュ活用（レスポンス結果のキャッシュ、メモリキャッシュ）
• 処理並列化・非同期化、水平スケール
• 最適なネットワーク構成（VPC、専用線、ピアリングなど）

可用性・耐久性・レイテンシーのトレードオフ関係

これらの品質指標は、往々にしてトレードオフ関係にあります。例えば：

• 可用性を高めるために複数リージョンを使う → 通信経路が複雑化し、レイテンシーが増す可能性あり
• 耐久性を最大にするために冗長レプリケーションを行う → コストや設計複雑性が上がる
• レイテンシーを極小化するために最寄りリージョン・エッジ処理を選ぶ → 可用性や耐久性設計が制限を受けることもある

設計時には、「どのレベルまで可用性／耐久性を確保すべきか」という要件定義が重要になります。SLA 要件、予算制約、ユーザー体験（レスポンス速度許容度）を整理した上で、最適なバランスを目指すべきです。

Google Cloud 固有の注意点・ベストプラクティス

Google Cloud における具体的な注意点をいくつか挙げておきます：

• SLA 条件をよく確認する：リージョン構成、構成制限、設定上のオプションにより可用性保証が変わることがある
• リージョン停止の可能性を前提に設計する：たとえば、あるリージョン全体が使えなくなるケースを想定してフェイルオーバーを含めておく
• データ転送コストを計算に入れる：リージョン間レプリケーションや通信が増えるとコストに影響する
• モニタリング・アラート設計を怠らない：障害発生時に即時検知・対応できる設計が不可欠
• 定期 DR（ディザスタリカバリ）訓練：実際にフェイルオーバーできるか定期検証すること

まとめ：設計への問いかけチェックリスト

以下はクラウド設計時に自問すべきチェックリストです。

• このサービスにはどのレベルの可用性が必要か？（例：99.99 %、99.999 %）
• データ損失はどこまで許容できるか？（耐久性要件）
• ユーザー体験で許される最大レイテンシーは？
• 可用性を上げる構成は、レイテンシーやコストにどの影響を与えるか？
• どの冗長設計／フェイルオーバー構成を採るか？
• 監視・アラート・障害対応体制は整っているか？
• 実障害シミュレーションを行ったことがあるか？

これらを意識して設計・レビューすることで、Google Cloud 環境で安定かつ高速なシステム構成を目指すことができます。