はじめに
学習の一環として、公式トレーニングコース「信頼性に優れた Google Cloud インフラストラクチャ: 設計とプロセス」を受講したのですが、インフラ設計の土台となる「要件定義」や「SLI / SLO / SLA」の考え方が非常に実践的で、実務にもそのまま活かせる内容でした。
今回は備忘録も兼ねて、クラウドアーキテクトがシステム設計を始める前に考えるべきことと、PCA試験でも頻出となる「SLO設計のベストプラクティス」についてまとめます。
1. いきなり構成図を描かない！インフラ設計の土台となる「要件定義」
クラウドアーキテクトは、要件を聞いてすぐに「じゃあデータベースはSpannerで…」と技術選定に入るべきではありません。まずはビジネス要件とユーザー要件を正確に整理・分析することが求められます。
要件を浮き彫りにする「5つの問い」
適切な設計のスタートラインとして、以下の5点を確認します。
- 誰が (Who): ユーザー、開発者、連携する外部システムなど、関わるすべての「アクター」
- 何を (What): システムに必須となる機能の主な領域
- なぜ (Why): 解決したい課題（無駄な要件を削り、のちのSLOなどを決める基準になる）
- いつ (When): スケジュールと開発範囲（スコープ）
- どのように (How): 同時ユーザー数、データサイズ、レイテンシーなどの「非機能要件」
ペルソナとユーザーストーリー（INVEST基準）
要件を具体化するため、システムの利用目的（ユーザーロール）を深掘りし、「ペルソナ（仮想の人物像）」を設定します。これにより「このユーザーならどう使うか？」という開発チーム内のブレを防ぎます。
そして、要件を 「[役割] として、[目的] のために、[何か] をしたい」 というシンプルな「ユーザーストーリー」に落とし込みます。良いストーリーかどうかは、以下の 「INVEST基準」 で評価します。
- I (Independent): 独立している
- N (Negotiable): 交渉可能である（ガチガチの契約ではない）
- V (Valuable): ユーザーに価値をもたらす
- E (Estimatable): 見積もり可能である
- S (Small): 範囲が小さく簡潔である
- T (Testable): テスト（検証）可能である
💡 PCA試験のポイント 試験問題は、まさにこの「ユーザーストーリー」の形式で出題されます。「カレンはスマホで直前に旅行を予約したい」というストーリーから、「モバイル向けAPIと、Firestoreのような高速なNoSQLが必要だ」と連想するトレーニングが非常に有効です。
2. 運用を見据えたインフラ思考「SLI / SLO / SLA」
要件が固まりシステムが稼働したあと、それが「本当に目標を満たしているか」を測定するための3大指標です。SRE（サイト信頼性エンジニアリング）の文脈でも非常に重要です。
3つの指標の違い
- SLI（サービスレベル指標 / Indicator）
- 何（割合や時間）を測るかという定量的尺度。
- ⭕ 良い例：「月単位で測定した、HTTPレスポンスコード200と500の比率」
- ❌ 悪い例：「システムがエラーなく動いていること」（曖昧すぎる）
- SLO（サービスレベル目標 / Objective）
- SLIに対する目標数値。
- ⭕ 良い例：「リクエストの 95% が 200ミリ秒未満 で完了すること」
- SLA（サービスレベル契約 / Agreement）
- 顧客とのビジネス上の契約（コミットメント）。未達時のペナルティ（返金など）も含まれる。
【超重要】SLOとSLAのしきい値の関係
アーキテクトとして絶対に押さえておくべき原則があります。それは、「SLAのしきい値は、SLOよりも必ず緩く設定する」 ということです。
例えば、運用の目標（SLO）を「200ms以内」とした場合、顧客との契約（SLA）は「300msを超えたら補償」と設定します。この差分がバッファ（猶予）となり、目標を少し下回ったからといって即座に契約違反・大損害になるリスクを回避できます。
モニタリングの罠：「平均値」は使わない
ユーザーの本当の体験（UX）を監視する際、「レイテンシの平均値（Average）」を見てはいけません。一部のユーザーが体験している極端な遅延や、一瞬のスパイクが薄まって見えなくなってしまうからです。 必ず 「99%パーセンタイル（上位1%の最悪のケース）」 などの統計手法を使用します。
3. 実践：優れたアーキテクトの「割り切り」思考
ケーススタディ（オンライン旅行ポータル）の模範解答から見えてきた、クラウドアーキテクトとしての「コストとパフォーマンスの最適化思考」をまとめます。
①「100%の可用性」は誰も幸せにしない
全てのシステムを 99.999% (ファイブナイン) で動かそうとすると、インフラコストが天文学的に跳ね上がります。
- 一般ユーザーの検索機能： 売上に直結するため
99.95%と厳しく。 - パートナー企業の在庫登録： 1日のうちに処理が終わればよいため
99.9%と少し緩めに。
このように、アクター（誰が使うか）に合わせて目標にメリハリをつけるのが正解です。
② 用途に合わせた「現実的なスピード感」
- ユーザーが操作する検索画面：ストレスを感じない 「ミリ秒」 単位の目標（例：200ms未満）。
- 社内管理者がBigQueryで回す販売実績の分析：大量データを扱うため 「秒」 単位の目標（例：10秒未満）。
要件に対して「常に最高速」を求めるのではなく、現実的なアーキテクチャを選択します。
おわりに：PCA試験で正解を見抜く「鉄則」
以上の学びから、PCA試験の選択肢を選ぶ際の明確な基準が見えてきました。
- 「100%の可用性を目指す」「常に最高速にする」選択肢はトラップ（誤答）
- SLI/SLOが「エラーを少なくする」など曖昧な表現になっているものは除外（期間・分母分子が明確なものを選ぶ）
- 社内向け・分析システムに対して、過剰な高可用性（99.99%など）やミリ秒のレスポンスを構成する選択肢は除外
- モニタリング指標でユーザー体験を測るなら「平均値」ではなく「パーセンタイル」を選ぶ
インフラ設計の根幹は「ビジネスの現実とコストのバランスを取ること」だと改めて実感しました。同じようにPCA取得を目指している方の参考になれば幸いです！
Tags: GoogleCloud, GCP, PCA, インフラ設計, SRE, SLO