CLF / ドメイン1 クラウドの概念
重要な内容
クラウドの設計原理
クラウドの設計原理は、需要の変化や障害を前提に、システムを柔軟かつ安定して動かすための考え方です。 特定のAWSサービスを暗記するのではなく、「なぜ分離するのか」「なぜ自動で増減させるのか」を理解します。
CLFでは、、、障害を前提とした設計、自動化といった言葉を、クラウドの利点と結び付けて判断することが重要です。
概要
では、将来の最大需要を予測して機器を先に購入することがあります。クラウドでは、必要なときに必要な分だけリソースを用意し、需要が減れば縮小できます。
また、1つの部品の障害がシステム全体へ広がらないように部品同士を分離し、障害が起きても処理を継続または復旧できる構成にします。
主要技術
①疎結合
とは、システムの部品同士が強く依存しすぎない状態です。送信側が受信側の処理完了を常に待つ構成では、受信側の停止が全体へ波及しやすくなります。
キューやイベント通知を間に置くと、送信側と受信側を分離できます。片方を変更、拡張、復旧するときに、もう片方への影響を抑えやすくなります。
| 構成 | 特徴 | 判断ポイント |
|---|---|---|
| 密結合 | 部品同士が直接依存します。 | 1か所の遅延や障害が全体へ波及しやすいです。 |
| 疎結合 | キューやイベントなどを介して分離します。 | 部品ごとに変更、拡張、復旧しやすいです。 |
Point
- Loose Coupling は「疎結合」です。
- 部品間の依存を弱め、障害の影響範囲を小さくする考え方です。
- SQSは処理の待ち行列、SNSは複数宛先への通知、EventBridgeはイベントの振り分けに使います。
②弾力性とスケーラビリティ ⚠️ 頻出
は、需要の増加に合わせて処理能力を拡張できる性質です。は、実際の需要に合わせてリソースを増やし、需要が減れば戻す性質です。
| 用語 | 意味 | 問題文のキーワード |
|---|---|---|
| Scalability | 負荷の増加に対応できる能力です。 | 将来の成長、大量アクセスへの対応 |
| Elasticity | 需要に応じて増減する能力です。 | 急増時に追加、閑散時に削減、 |
| Vertical scaling | 1台のリソースをより大きくします。 | より大きいへ変更 |
| Horizontal scaling | 台数を増減します。 | 複数台、、 |
CLFでは、「ピークに備えて最大構成を常時維持」よりも、「需要に応じて自動で増減」がクラウドの弾力性を表します。
③障害を前提にした設計
クラウドでも障害を完全になくすことはできません。そのため、単一のリソースが停止してもサービス全体が停止しないように設計します。
- 複数のへ配置します。
- 正常なリソースへトラフィックを振り分けます。
- データを複製し、バックアップから復旧できるようにします。
- 障害を検知して自動的に置き換えます。
は「障害が起きないこと」ではなく、「障害が起きても利用を継続しやすいこと」です。
④自動化と測定
構築、変更、監視、復旧を自動化すると、人による作業ミスを減らし、同じ操作を再現しやすくなります。利用状況を測定し、そのデータに基づいて構成やコストを改善します。
| 目的 | クラウドでの考え方 |
|---|---|
| 同じ環境を再現する | テンプレートやコードから構築します。 |
| 需要へ追随する | を基に自動で増減します。 |
| 障害へ対応する | 監視、通知、自動復旧を組み合わせます。 |
| 無駄を減らす | 使用量を測定し、不要なリソースを縮小・削除します。 |
試験対策
| 問題文のキーワード | 優先する設計原理 | 理由 |
|---|---|---|
| 一部の障害を他の処理へ波及させない | 部品間の依存を弱め、障害を分離します。 | |
| アクセス急増時だけ能力を追加する | 需要に合わせてリソースを増減します。 | |
| 1台の停止後もサービスを継続する | 障害を前提にした設計 | 冗長化と自動復旧を使います。 |
| 手作業による設定ミスを減らす | 自動化 | 再現可能な手順で構築・変更します。 |
| 推測ではなく利用状況で改善する | 測定 | やログを判断材料にします。 |
「拡張できる」は、「需要に応じて元の規模へ戻せる」まで含む場合は弾力性です。また、冗長化だけでなく、障害検知、切り替え、復旧までを一連の設計として考えます。