リージョン・アベイラビリティゾーン・エッジロケーションのシナリオ判断

配置図の読み違い、片側停止時の不足、キャッシュの更新遅れを事例で整理し、何を追加確認すればよいかを判断します。

この単元で学ぶこと

1. 配置禁止と近さを比べる候補Aは利用者に近いがデータ配置条件に合わず、候補Bは条件を満たすとします。近さだけでAを選ばず、必須条件を満たすB等を検討します。必要なら配信の近接化を別に考えますが、キャッシュ側のデータ配置条件も確認します。

2. 提供機能が足りない場合候補地域の料金が低くても、必要な機能が未提供ならそのまま同等の業務はできません。候補地域、サービス構成、必要機能を照合します。過去に別地域で利用できた事実だけで、全地域で利用できると推測しません。

3. 同じ場所の複数台二台あるのに一つのAZで両方が停止する可能性がある構成は、台数の複数化だけを行っています。AZを分けて一か所の障害を分離する方針と区別します。大きい一台へまとめる案も同じ場所への依存を残すため、目的が性能か可用性かを読みます。

4. 障害時の計算三つのAZが各40の処理能力を持ち、全需要が90とします。通常は120で足りますが、一つ失うと80で10不足します。余剰のある合計だけで安心せず、想定した故障後に何が残るかを計算します。この値はAWSの性能保証ではなく、考え方を学ぶ仮例です。

5. あるのに使えない復旧先別リージョンにアプリだけ作っても、DBや秘密情報、接続設定等が揃わないと復旧できません。資源・データ・権限を用意し、要求を切り替えて必要な業務ができるか確認します。単なる地域選択を復旧準備の完了とみなしません。

6. 画像更新後も古い表示 CloudFrontのオリジンを更新しても、古い項目が有効なキャッシュに残ることがあります。TTLや無効化、ファイル名の版管理等の更新方法を確認します。データを永久保存するバックアップとは違い、配信の鮮度を制御する話です。

7. 配信と個別処理公開画像は多くの利用者が同じ項目を利用できますが、個人ごとに内容が変わるページは共有方法に注意が必要です。利用者の認可とキャッシュキー・方針を合わせ、他人の内容を配らないようにします。近くにあることだけで安全性が決まるわけではありません。

8. 現行情報で最後に確認候補が決まったら、地域の有効化、サービス提供、料金、必要な識別子の対応を現行公式で確認します。リージョンとAZを足して一つの地域数と数えたり、自分の有効化地域だけで世界全体を判断したりしません。構成の目的と単位が合っていることを確かめます。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。