SAP-C02-028 · 理解確認
理解確認:Scale-upとScale-out
単一選択 15 / 複数選択 3 / 穴埋め 0 · 18問
この理解確認の目的
ボトルネック、ステートフル / ステートレス、伸縮性、障害影響からスケールアップ / スケールアウトを選択できるか確認します。
オンプレミスから移行した業務アプリケーションが1台のEC2インスタンス上で動作している。アプリケーションはローカル状態へ強く依存し、短期的には複数ノードへ分散する改修ができない。CPUとメモリがキャパシティ不足になっている。最初に評価すべきスケーリング戦略はどれか。
B. トラフィック量に関係なく常時インスタンス数を増減する
C. 現在のリソースをより大きいインスタンスタイプへスケールアップする
D. アプリケーション階層を変更せずデータベースだけを削除する
答えと解説
答え:C
要件はローカル状態依存が強く、現時点では複数ノードへ分散できないことです。この制約では、まずアプリケーション変更を伴いにくいスケールアップを評価します。ただし将来は単一リソースのキャパシティ上限も確認します。
ウェブアプリケーションはセッションをアプリケーションサーバー内へ保存しておらず、すべてのリクエストを任意のサーバーが処理できる。トラフィック増加への対応と単一サーバー障害の影響低減を同時に実現したい。最も適切な基本アーキテクチャはどれか。
B. アプリケーションサーバーを1台のより大きいインスタンスへ変更する
C. アプリケーションサーバーを1台に固定しストレージだけ増加する
D. ユーザーごとに固定サーバーへ永続的にルーティングする
答えと解説
答え:A
ステートレスワークロードでは任意レプリカがリクエストを処理できます。水平スケーリングで処理を複数リソースへ分散すれば合計キャパシティを増やしながら、1ノード障害の影響も小さくできます。
あるサービスは2台から20台までインスタンスを増やせる。しかしトラフィック増減に応じたインスタンス数変更は管理者が毎回手動で行っている。このアーキテクチャの説明として最も適切なのはどれか。
B. 垂直スケーリングだけで需要変動へ自動追従している
C. ステートフル構成なので水平スケーリングは利用できない
D. スケーラブルだが、需要連動の自動伸縮は実装されていない
答えと解説
答え:D
リソース数を増やせるためスケーラビリティはあります。一方、伸縮性では現在の需要へキャパシティを近づけるようリソースを動的に増減し、AWS アーキテクチャではその調整を自動化することが重要です。
3階層アプリケーションでレイテンシーが悪化している。ウェブ階層 CPUは25%、アプリケーション階層 CPUは35%、データベース CPUは96%でデータベース接続数も上限付近である。最も適切な対応はどれか。
B. アプリケーション階層だけを4倍へ増やし、データベースは変更しない
C. データベース階層をボトルネックとして評価し、そのキャパシティ改善を行う
D. 監視結果を使わず、すべての階層を同じ比率で一律に増やす
答えと解説
答え:C
システムキャパシティを制限しているのはデータベースです。余力のある階層を増やしてもボトルネックが残ればレイテンシーやスループットは改善しません。
水平スケーリングが適している条件を3つ選択してください。
B. 任意のレプリカが同じリクエストを処理できる
C. ワークロードを複数リソースへ分散できる
D. すべてのセッション状態を1台のローカルメモリだけに保存する必要がある
E. 単一ノード障害で失われるキャパシティの割合を小さくしたい
答えと解説
答え:B / C / E
水平スケーリングではレプリカへワークロードを分散できることが重要です。任意レプリカで処理できればリソースを増減しやすく、単一ノード障害の影響も分散できます。AとDはそのままではスケールアウトの制約です。
アプリケーションサーバーはユーザーセッションを各EC2インスタンスのメモリへ保存している。スケールインやインスタンス交換でユーザーセッションが失われることがある。水平スケーリングを成立させるため最も適切な設計変更はどれか。
B. セッション状態を共有可能な外部状態保管先へ分離する
C. すべてのインスタンスに異なるアプリケーションバージョンを配置する
D. スケールインするたびに全ユーザーをログアウトさせる
答えと解説
答え:B
ローカル状態がノード ライフサイクルへ結び付いていることがスケーリングの制約です。状態をアプリケーションノードから分離するとノードを追加・削除・交換しやすくなります。
アーキテクトが「このデータベースはステートフルなので水平スケーリングは一切できない」と説明した。最も適切な評価はどれか。
B. 正しい。水平スケーリングはウェブサーバー専用である
C. 誤り。ステートフルコンポーネントは必ずステートレスへ変換できる
D. 誤り。レプリケーションや読み取り分散、パーティショニングなどを利用できる場合がある
答えと解説
答え:D
ステートフルだから水平スケーリングが不可能という意味ではありません。データモデル、整合性要件、サービス機能に合ったスケーリング方式を選択します。
同一構成のアプリケーションサーバーを8台起動したが、ルーティング設定によりトラフィックは常に1台だけへ送られ、他の7台にはほぼリクエストがない。最も適切な改善はどれか。
B. トラフィックが集中する1台だけをさらにスケールアップする
C. インスタンス数だけを8台から16台へ増やす
D. ワークロードディストリビューションを変えずAuto Scalingだけを有効にする
答えと解説
答え:A
リソース数を増やすだけでは水平スケーリングは成立しません。追加したレプリカへ実際のワークロードをディストリビューションできるアーキテクチャが必要です。
ウェブアプリケーションを4台の小さいEC2インスタンスへ水平スケーリングした。単一インスタンス障害の影響は小さくなったが、4台すべてが同じ可用性ゾーンに配置されている。可用性ゾーン障害による影響も抑える必要がある。最も適切な設計はどれか。
B. 4台を1台の最大インスタンスへ集約する
C. 複数AZへ分散し、正常なリソースへトラフィックを振り分ける
D. すべてのインスタンスへ同じローカルセッション状態を手動コピーする
答えと解説
答え:C
水平スケーリングで単一ノード障害の影響は小さくできますが、すべてが同じ障害ドメインならAZ障害という共通障害点が残ります。信頼性目的では障害ドメインも分離します。
単一のAmazon EBSをルートボリュームに使用するEC2インスタンスのインスタンスタイプを変更してスケールアップする計画である。要件としてアプリケーションを停止できない。最も適切なアーキテクチャ判断はどれか。
B. ステートレス化されているかに関係なく必ずスケールダウンする
C. インスタンスタイプ変更は常に無停止なのでそのままスケールアップする
D. スケールアップ時の停止影響を確認し、必要なら水平スケーリングなど別方式を評価する
答えと解説
答え:D
Amazon EBSをルートボリュームに使用するEC2インスタンスのインスタンスタイプ変更には停止が必要です。キャパシティだけでなく、変更操作が可用性要件を満たすか確認します。
EC2ベースのウェブアプリケーションは通常4台で動作するが、キャンペーン開始時に数分以内でトラフィックが急増する。新しいインスタンスが起動しアプリケーションヘルスチェックに合格するまで数分必要で、キャンペーン終了後はトラフィックが通常水準へ戻る。伸縮可能なアーキテクチャとして適切な設計を3つ選択してください。
B. 新しいキャパシティが利用可能になるまでの時間を考慮し十分なキャパシティ余裕を持たせる
C. 年間最大トラフィックを処理できるインスタンス数を常時固定する
D. キャパシティが完全に枯渇してから初めてスケールアウトを開始する
E. 需要減少後は不要なキャパシティをスケールインできるようにする
答えと解説
答え:A / B / E
伸縮性では需要増に自動追従し、需要減では不要キャパシティを削減します。また追加リソースがオンラインになるまでの遅延を考慮し、トラフィックバーストを処理できる余裕が必要です。
ステートレスアプリケーション階層を2台から50台までスケールアウトした。しかしデータベース接続数の上限に到達し、アプリケーションエラーが増えた。次に行うべきことはどれか。
B. データベースを新しいボトルネックとして評価する
C. ロードバランサーを削除する
D. アプリケーションをすべてステートフル化する
答えと解説
答え:B
ある階層をスケールすると次のコンポーネントがボトルネックになる場合があります。エンドツーエンドでキャパシティを評価し、下流側の制約を確認します。
ウェブ階層はステートレスでトラフィック変動が大きい。一方データ階層は強い整合性要件を持ち、ウェブ階層とは異なるスケーリング方式が必要である。最も適切な設計思想はどれか。
B. アーキテクチャ全体で必ず同じスケーリング方式を使う
C. ステートフルコンポーネントが1つでもあれば全階層をスケールアップだけにする
D. ステートレスコンポーネントが1つでもあれば全階層をスケールアウトだけにする
答えと解説
答え:A
スケールアップ / スケールアウトはワークロード全体で二者択一にするものではありません。各コンポーネントの状態、ボトルネック、障害影響、サービス特性に合わせて選択します。
水平スケーリングのキャパシティ上限になり得るものを3つ選択してください。
B. ロードバランサーが下流リソースのキャパシティも必ず自動拡張すること
C. サブネットの利用可能IPアドレス
D. 下流データベースの処理キャパシティ
E. AWSサービスクォータ
答えと解説
答え:C / D / E
スケールアウトでもIPアドレス、サービスクォータ、下流データ保管先など別の制約があります。リソース数だけを見て無限のキャパシティと判断してはいけません。
ステートフルワークロードとステートフルファイアウォールの違いを正しく説明しているものはどれか。
B. ステートフルファイアウォールを使用するとアプリケーションは必ずステートレスになる
C. 前者はアプリケーション処理の状態依存、後者は接続状態を追跡するネットワーク処理を指す
D. ステートフルワークロードはネットワークACLと同じ意味である
答えと解説
答え:C
同じステートフルという単語でも責任が異なります。アプリケーション / セッション状態とネットワーク接続状態を混同しないことが重要です。
EC2 Auto Scalingグループがトラフィック増加に応じてインスタンス数を4台から12台へ増やし、トラフィック減少後に4台へ戻った。このキャパシティ変更の組み合わせとして正しいものはどれか。
B. スケールイン → スケールアップ
C. スケールダウン → スケールアウト
D. スケールアウト → スケールイン
答えと解説
答え:D
リソース数を増やすのがスケールアウト、減らすのがスケールインです。1リソース自体のサイズ変更であるスケールアップ / スケールダウンとは区別します。
EC2インスタンスのCPU使用率が高いためスケールアップが提案された。しかし負荷テストではストレージスループットが先に上限へ達し、CPUはストレージ待ちの影響も受けていた。最も適切な判断はどれか。
B. CPUメトリクスだけでスケーリング戦略を決定する
C. 必ず水平スケーリングへ変更する
D. 監視を行わず最大インスタンスタイプへ変更する
答えと解説
答え:A
スケーリングは単一メトリクスだけで決めません。負荷テストや監視でシステムキャパシティを実際に制限しているコンポーネントを特定してからアーキテクチャを選択します。
商用アプリケーションが1台のEC2インスタンスで動作している。ソフトウェアライセンスとアプリケーションアーキテクチャの制約により、現時点では複数ノードへの分散が難しく、需要増加にはスケールアップで対応している。しかし将来の需要予測では利用可能な最大インスタンスタイプでもキャパシティが不足する可能性がある。最も適切な判断はどれか。
B. 短期はスケールアップし、将来の上限に備えて分散可能な別方式も検討する
C. ソフトウェアライセンス制約があるためキャパシティ計画は不要である
D. 最大インスタンスタイプへ変更すれば下流リソースのキャパシティも自動的に増える
答えと解説
答え:B
スケールアウトしにくい制約がある場合、短期的にはスケールアップが現実的です。ただし垂直スケーリングには最大リソースサイズというキャパシティ上限があります。将来需要がそれを超えるならアーキテクチャ変更を含む別戦略が必要です。