シナリオ読解法

このレッスンを終えると、シナリオ文を3ステップで分解し、要件語から構成へ翻訳して、惜しい選択肢を消せるようになります。このコースで一番大事な回です。

題材

解説

ある企業が、社内向けのレポート配信システムを EC2 の単一インスタンスで運用しています。毎月末にアクセスが平常時の10倍に跳ね上がり、応答が返らないことがあります。障害でインスタンスが1台落ちてもサービスを継続させたいと考えています。アプリケーションはステートレスで、運用の手間を最小にしたいという条件があります。この要件を満たす構成はどれですか。

長く見えますが、答えに効いている言葉は4つしかありません。どこを拾うかを手順にします。

手順は3ステップ

ステップ1 何を作るのか

まず主語と対象を1行にします。ここでは「社内向けレポート配信の Web システム」です。この段階では技術を考えません。データベースの話なのか、ネットワークの話なのか、配信の話なのかという当たりを付けるだけです。ここを飛ばすと、目に入った単語に引きずられて分野違いの選択肢を選びます。

ステップ2 制約は何か

次に動かせない条件を拾います。この文では「月末に10倍」「1台落ちても継続」「ステートレス」の3つです。制約は複数あるのが普通で、制約を1つでも満たさない選択肢は、他がどれだけ優れていても落ちます。ここが SAA の採点の考え方です。

ステップ3 何を最優先するのか

最後に優先順位を決める言葉を探します。この文では「運用の手間を最小に」です。これがあると、同じ要件を満たす複数の案のうち、自前で組む案が落ちて、マネージドの案が残ります。

3ステップを通すと、この問題は「ALB と Auto Scaling で複数アベイラビリティゾーンに分散する」が残ります。ステートレスと書いてあるのでスケールアウトが成立し、複数AZで1台落ちても継続でき、Auto Scaling は運用の手間が小さいからです。

制約の言い回しが答えを変える

同じシナリオでも、最後の一文が変わると答えが変わります。ここが SAA の本体です。

「アプリを改修せずに」の例で確かめます。読み取り負荷が高い RDS があるとき、アプリ側でキャッシュ層を実装して負荷を下げる案は、実務では正解になり得ます。しかし「改修せずに」と書かれた瞬間に落ちます。代わりにリードレプリカを足して参照先を向ける、あるいは前段に読み取り用の仕組みを置く案が残ります。技術的な良し悪しではなく、書かれた制約に照らして選びます。

要件語から構成への対応表

ここが以降の全章で参照する土台です。まずは目を通し、章が進むたびに戻ってきてください。

消去法の手順

選択肢が4つとも動きそうに見えたときは、次の順で消します。

1. 制約に反するものを消す。 「改修せずに」に対してコード変更が要るもの、「ダウンタイムなし」に対して停止が要るものは、その1点だけで落ちます
2. 要件より過剰なものを消す。 数分のダウンが許容されているのにアクティブ/アクティブを選ぶ案は、要件を満たしますが優先順位の言葉に反します。コストや運用の観点で必ず負けます
3. 要件に届かないものを消す。 単一 AZ 内で複数台にする案は、インスタンス障害には耐えますが AZ 障害には耐えません。「単一障害点を排除」に届いていません
4. 残った2つは、優先順位の一文で決める。 最後の「最も低コストで」「運用の手間を最小に」が、必ずどちらか片方に有利に働きます

よくある引っ掛け

1つ目は、過剰な構成を正解だと思ってしまうことです。より可用性が高い構成は一見よさそうに見えますが、要件が求めていない可用性に費用を払う案は誤答になります。SAA は「一番強い構成」ではなく「要件にちょうど合う構成」を選ぶ試験です。

2つ目は、知っているサービス名に飛びつくことです。設問に馴染みのある単語が出てくると、それを含む選択肢を選びたくなります。3ステップを踏んで制約を書き出してから選択肢を見る順序を守ると、この癖は消えます。

まとめ

• シナリオは「何を作るのか」「制約は何か」「何を最優先するのか」の3ステップで分解する
• 制約を1つでも満たさない選択肢は、他がどれだけ優れていても落ちる
• 「最も低コストで」「運用の手間を最小に」「アプリを改修せずに」「ダウンタイムなしで」は答えを変える言葉
• 消去法は、制約違反、過剰、不足の順に消し、残り2つを優先順位の一文で決める
• 要件語から構成への対応表を、章が進むたびに厚くしていく