変更要約: Professional Cloud Developer 第2章を新規作成（ドメイン1「設計」後半: データの保存とアクセス＝Cloud SQL/AlloyDB/Spanner/Firestore/Bigtable/Cloud Storage/BigQuery・スキーマ/行キー・結果/強整合性・署名付き URL・BigQuery 書き込み、可用性/レジリエンス/コスト＝リージョン/ゾーン分散とレイテンシ・ゾーン/リージョンフェイルオーバー・リソース要件・サーバーレスのゼロスケール・冪等性/指数バックオフ）。
2.2可用性・レジリエンス・コストの設計
リージョン/ゾーンの地理的分散とレイテンシ、ゾーン/リージョンフェイルオーバーのためのデータレプリケーション、ワークロードのリソース要件定義、コストとリソース使用量の最適化、そして冪等性やリトライ（指数バックオフ）による信頼性の設計を理解します。
クラウドネイティブアプリは、落ちにくく・伸び縮みし・無駄なくコストを使うことが求められます。開発者は地理的分散・レジリエンス・コストを設計に織り込みます。
2.2.1地理的分散とフェイルオーバー
Google Cloud のサービスは リージョン（地理）と ゾーンで分散され、利用者の近くで動かすほど レイテンシが下がります。可用性のために データレプリケーションで冗長化し、ゾーンフェイルオーバー（リージョン内の別ゾーンへ）や リージョンフェイルオーバー（別リージョンへ）に備えます。リージョナル/マルチリージョナルなサービス（Spanner、Cloud Storage のマルチリージョンなど）を要件で選びます。「ゾーン障害に耐える＝ゾーン冗長/リージョナル」「地域障害に耐える＝リージョン冗長/マルチリージョン」と結びます。
2.2.2リソース・コスト・信頼性
ワークロードの リソース要件（CPU/メモリ/同時実行）を定義し、過不足なく割り当ててコストと性能を最適化します。サーバーレス（Cloud Run/Functions）は使った分だけ課金され、アイドル時にゼロスケールできます。信頼性のために、リトライしても安全な 冪等性を設計し、一時的な失敗には 指数バックオフで再試行します（一斉リトライによる過負荷を避ける）。「使った分だけ・ゼロスケール＝サーバーレス」「安全な再試行＝冪等性＋指数バックオフ」を押さえます。
「要件 → 設計」が頻出。例：「利用者に近くレイテンシを下げる」＝リージョン/エッジ配置、「ゾーン障害に耐える」＝ゾーン冗長、「アイドル時はコストゼロ」＝サーバーレスのゼロスケール、「一時エラーで再試行」＝指数バックオフ、「再試行しても重複しない」＝冪等性。
混同に注意：
①ゾーン冗長（ゾーン障害対応）とリージョン冗長（地域障害対応）を取り違えない。
②再試行は指数バックオフで（即時一斉リトライは過負荷を招く）。
③冪等性がないと再試行で重複処理が起きる。
2.2.3この節のまとめ
- リージョン/ゾーンで分散しレイテンシ低減、レプリケーションでゾーン/リージョンフェイルオーバー
- リソース要件を定義しコスト最適化、サーバーレスは使った分だけ・ゼロスケール
- 信頼性は冪等性＋指数バックオフ（安全な再試行）で設計
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. リージョン内の単一ゾーン障害に耐えられるようにしたい。最も適した方法はどれですか？
Q2. 一時的なエラーに対して、過負荷を避けつつ再試行したい。最適な方法はどれですか？
Q3. 再試行しても処理が重複しないようにしたい。設計に取り入れるべきものはどれですか？
Q4. アイドル時にコストをゼロにしたいワークロードに最適なのはどれですか？
Q5. 利用者に近い場所で動かしてレイテンシを下げたい。最も適した考え方はどれですか？
Q6. 地域全体の障害に耐えるために最も適した方法はどれですか？