クラウド全般 — 仕組みから設計判断まで

前提: IPアドレス、HTTP、OS、DBという言葉を知っていること。不明点はインフラ基礎へ戻る。

到達目標

クラウドを使う理由と引き受ける責任を説明し、特定ベンダー名を使わずにWebシステムを設計できる。 各節の小さな例で理解を確認する。共通の例題は設計を比較したい場合に使う架空のもので、実際の業務情報とは関係ない。

1. クラウドとは何か

クラウドは、計算・保存・ネットワークなどのIT資源を、必要に応じてサービスとして利用する仕組み。 単に遠くのサーバーを借りるだけでなく、APIで調達・変更を自動化し、需要に合わせて増減できる点が設計を変える。 従量制で支出を利用量に結び付けられる一方、放置した資源や大量の通信も支出になる。

オンプレミスでは機器の調達・設置・保守から考える。クラウドではサービス選定、設定、利用量管理に仕事の比重が移る。 専用機器、既存設備との近さ、契約条件などからオンプレミスが適する場合もある。移行そのものを目的にしない。

提供範囲と利用形態

サーバーレスは、サーバーの調達・管理をサービス側へ任せる実行モデル。サーバーが消えるわけではなく、実行時間・同時実行・外部接続などの制約は残る。 マネージドDBでも、テーブル設計・アクセス権・バックアップ方針・復旧確認は利用者の仕事になる。

パブリッククラウドは広く利用者に提供される基盤、プライベートクラウドは特定組織向けの基盤。 ハイブリッドクラウドはオンプレミスなどとクラウドを組み合わせる構成、マルチクラウドは複数クラウドを利用する構成。 「複数社を使う」と「障害時に自動で代替できる」は別々に設計する必要がある。

2. 責任共有と権限

クラウド事業者と利用者は管理責任を分担する。たとえばAWSのEC2ではゲストOSの更新は利用者側、物理設備の管理はAWS側に属する。 利用するサービスによって分担が変わるため、サービス単位で確認する。AWS責任共有モデル

認証は「誰かを確かめる」、認可は「その主体に何を許すか」。管理者のログインと、アプリがDBへ接続する認証は分けて考える。 人には組織のIDと多要素認証、アプリには必要な権限だけを持つ実行用IDを割り当てる。 ネットワークで到達できても、認可がなければデータを読めない構成を目指す。

ミニ演習: ポータルをIaaSからPaaSへ移したとき、OS更新・アプリ修正・利用者の利用終了時の権限削除の担当がどう変わるか書く。 答えの要点: OSの運用負担は減るが、アプリ修正と利用者のライフサイクル管理は残る。

3. リージョン・ゾーン・障害範囲

リージョンは地理的な配置の単位、ゾーンはリージョン内で障害を分離する単位として考える。 名称、対応サービス、実際に複数ゾーンへ配置される設定は事業者やサービスによって異なる。 「リージョンを選んだ」だけでは、アプリもDBも冗長化されたことにはならない。

可用性は使いたいときに使える性質。耐久性は保存したデータを失いにくい性質。 ファイルが失われなくても認証基盤が停止すれば閲覧できないため、耐久性が高いストレージだけでシステムの可用性は決まらない。

SLAは提供者のサービス水準に関する契約上の条件。SLOは自分たちが設定する運用品質の目標。 30日を分母とする単純な時間ベースの計算では、99.9%の停止許容量は43.2分。実際の測定窓と除外条件は別途定義する。

4. ネットワークを一本の通信で追う

利用者端末 → DNSで名前解決 → HTTPS入口・認証 → アプリ → 進捗DB
                                         └→ 教材ストレージ
管理者 → 管理用認証・接続経路 → 管理API／運用対象

DNSは名前から接続先を調べる仕組み。TLSは通信の暗号化と接続相手の検証に使う。 ロードバランサーは複数の処理先へ通信を振り分ける。CDNは利用者に近い場所からコンテンツを配信し、オリジンの負荷を減らす。 CDNで利用者向け教材を配信するときは、認証の有無、キャッシュキー、認証後のコンテンツが他人へ配られない条件も設計する。

仮想ネットワークとサブネットはアドレスや配置を整理する単位。経路表は通信の次の行き先、ファイアウォールは許可する通信を決める。 プライベートという名前だけで安全性は決まらない。公開IP、経路、通信ルール、サービス側の公開設定を合わせて確認する。 NATはアドレスを変換する仕組みであり、認証や権限管理の代替にはならない。

通信できない場合は、名前解決 → 経路 → 通信許可 → TLS → アプリ認証 → DB接続の順に観測する。 タイムアウトと権限不足の応答を区別すると、調べる範囲を絞れる。

5. 実行基盤とデータを選ぶ

VMはOSを含めて制御したい場合に向く。コンテナはアプリと依存物をまとめて配布する単位で、実行基盤の管理責任は選択したサービス次第。 関数やマネージドコンテナは運用を任せやすいが、常駐処理・実行制約・接続数・課金モデルを確認する。 水平スケールは台数を増やすこと、垂直スケールは一台を大きくすること。台数を増やすにはセッションやファイルを一台だけに閉じ込めない工夫が要る。

キャッシュはDB負荷を減らす一方、更新の反映遅延と無効化が課題になる。 キューは処理を非同期にして突発負荷を受け止めるが、遅延、重複、再試行、失敗メッセージの扱いを追加で設計する。 サービスを増やすたびに、解決する課題と増える運用の両方を書く。

6. バックアップ・冗長化・災害復旧

冗長化は一部が壊れても継続しやすくすること。バックアップは過去の状態に戻す手段。 誤更新が複製先へ伝われば、二台あっても正しいデータは戻らない。

RTOは復旧までに許容する時間、RPOは失ってよいデータを時間で表した目標。 ポータルのRPO 24時間なら、復元できる有効なコピーの間隔が24時間を超えない設計が必要。 「毎日ジョブを設定した」だけでは成功と復元可能性は分からないので、失敗通知と復元訓練を含める。

復旧手順は、障害検知、担当者への連絡、復元先の用意、データ復元、接続先変更、アプリ確認、利用再開まで分ける。 DBの復元だけでRTO全体を測らない。教材と進捗の参照関係も確認する。

7. 監視とコストを設計に含める

メトリクスはエラー率や待ち時間などの数値、ログは個々の出来事、トレースは一つの要求が通った処理のつながり。 監視では「CPUが高い」だけでなく「利用者がログインできるか」「教材を開けるか」「進捗を保存できるか」を見る。 通知には担当者、緊急度、最初に見る情報、復旧手順へのリンクを添える。

机上の費用モデルは、実行基盤 + データ保存 + リクエスト処理 + データ転送 + 監視ログ + バックアップ + 接続設備 + サポート + 運用工数。 安いVMでも、外向き通信、NAT、LB、ログ、運用時間が支配的になる場合がある。 無料枠や予算通知を支出の強制上限とみなさず、契約と制御方法を個別に確認する。

8. 総合演習と解答例

まず解答例を隠して、次を一枚の設計メモにまとめる。

1. ポータルの通信経路を描き、利用者・管理者・アプリのIDを分ける。
2. 実行基盤、教材保存、進捗保存を選び、不採用案を一つずつ挙げる。
3. アプリ一台の停止と進捗の誤削除に、それぞれどう対応するか書く。
4. 月間費用を増やす変数を五つ挙げる。

解答例: 認証されたHTTPS入口からステートレスなアプリへ送り、教材をオブジェクトストレージ、進捗をRDBに保存する。 OS固有の要件がなければマネージド実行基盤を候補にする。利用者はアプリだけを使い、アプリの実行用IDに必要な保存先への権限を与える。 アプリ停止は別の実行先への振り分けと再作成、誤削除は隔離した復元先でデータを検証してから戻す。 費用の変数は同時実行数、保存量、外向き転送量、ログ量、バックアップ保持期間など。

理解度チェック

次: AWSの基礎から設計・運用へ