AWS認定資格 WEB問題集&徹底解説
CloudOpsエンジニア -アソシエイト
問題文と選択肢
これらのエラーを解決するために、CloudOps 管理者は何をすべきですか?
- データベースのリードレプリカを作成します。Amazon Route 53 を使用して、両方のデータベースを含む加重 DNS レコードを作成します。
- Amazon RDS Proxy を使用してプロキシを作成します。Lambda 関数の接続情報を更新します。
- データベースが使用するパラメータグループの max_connect_errors パラメータの値を増やします。
- Lambda 関数の予約済み同時実行数をより大きい値に更新します。
A. データベースのリードレプリカを作成します。Amazon Route 53 を使用して、両方のデータベースを含む加重 DNS レコードを作成します。
リードレプリカは読み取りクエリを分散する仕組みで、確かに読み取り接続の一部を逃がせますが、書き込みは引き続きプライマリに集中します。
さらに Route 53 の加重レコードで振り分ける構成は、アプリ側でエンドポイントを使い分けられず書き込みがレプリカへ飛ぶ危険があり、DNS キャッシュの影響も受ける不適切な設計です。接続数の急増という根本原因(コネクションプールの欠如)にも対処できていません。
B. Amazon RDS Proxy を使用してプロキシを作成します。Lambda 関数の接続情報を更新します。
Amazon RDS Proxy は RDS / Aurora の前段に立ち、データベース接続をプールして多数のクライアント間で再利用します。Lambda は同時実行のたびに新しい実行環境が接続を張るため接続数が爆発しますが、Proxy を挟めば実際の DB 接続数を大幅に抑制でき、「Too many connections」を解消できます。
Lambda 側は接続先を Proxy のエンドポイントに変更するだけで済み、フェイルオーバー時間の短縮や IAM 認証・Secrets Manager 連携といった利点も得られます。したがってこれが正解です。
C. データベースが使用するパラメータグループの max_connect_errors パラメータの値を増やします。
max_connect_errors は「1 つのホストからの接続エラーが連続した際に、そのホストをブロックするまでの回数」を制御する MySQL パラメータで、同時接続数の上限とは無関係です。
値を増やしても接続を張れる数は 1 本も増えず、「Too many connections」は解消しません。名前が似ているだけの典型的なダミーです。
D. Lambda 関数の予約済み同時実行数をより大きい値に更新します。
予約済み同時実行数を増やすと、同時に走る Lambda 実行環境が増え、その分だけ DB への接続本数も増えます。
つまりこの選択肢は問題を悪化させる方向です。(逆に同時実行数を絞れば接続数は抑えられますが、スロットリングでアプリの処理能力を犠牲にする対症療法にすぎず、RDS Proxy の方が適切です。)
Lambda × RDS で「Too many connections」なら RDS Proxy。接続を増やすのではなく、使い回す。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| エラーが「Too many connections(接続が多すぎます)」 | 原因は同時接続数の上限超過。接続の作られ方そのものを変える必要がある →選択肢(C)を消す |
| max_connections は既に最大値まで設定済み | DB 側のパラメータ調整では打ち手が尽きていると明示されている。パラメータ変更系は候補から外れる →選択肢(C)を消す |
| 呼び出し元が AWS Lambda(実行環境ごとに接続を張る) | 接続をプールして再利用する Amazon RDS Proxy がサーバーレス × RDS の定石 →選択肢(B)が正解 |
| 使用量は着実に増加している(今後もスケールする) | 同時実行数を増やせば接続も増えて悪化する。読み取りレプリカ + 加重 DNS も書き込み接続の集中を解決しない →選択肢(A・D)を消す |
ひっかけポイント
- max_connect_errors と max_connections は名前が酷似しているが別物。前者は接続エラー連続時のホストブロック閾値で、接続数の上限には一切関係しない
- 「予約済み同時実行数を高くする」は、Lambda の実行環境を増やして接続数をさらに増やすため逆効果。同じ論点で「低くする」なら緩和策にはなり得る点が引っかけどころ
- リードレプリカは「DB を増やす=接続も分散できそう」に見えるが、書き込みはプライマリ 1 台のまま。加重 DNS で振り分ける構成は書き込みがレプリカへ飛ぶ危険もある
- 問題文の「max_connections は最大値に設定済み」という一文が、パラメータ調整系の選択肢を消すために置かれている。この条件を読み飛ばすと C を選びやすい
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「読み取りクエリが重く、プライマリの CPU が逼迫している」 | リードレプリカ(+ Aurora のリーダーエンドポイント)が正解軸に。 |
| 「Lambda が DB を圧迫しないよう流量を制限したい」 | Lambda の予約済み同時実行数を「下げる」、または SQS でのバッファリングが正解軸に。 |
| 「DB 認証情報をコードに持たせず、安全に接続したい」 | RDS Proxy + IAM 認証 + Secrets Manager の組み合わせが問われる。 |
| 「フェイルオーバー時のダウンタイムを短縮したい」 | RDS Proxy が接続を保持したまま切り替えるため、やはり RDS Proxy が正解に。 |
これらのエラーを解決するために、CloudOps 管理者は何をすべきですか?
- データベースのリードレプリカを作成します。Amazon Route 53 を使用して、両方のデータベースを含む加重 DNS レコードを作成します。
- Amazon RDS Proxy を使用してプロキシを作成します。Lambda 関数の接続情報を更新します。
- データベースが使用するパラメータグループの max_connect_errors パラメータの値を増やします。
- Lambda 関数の予約済み同時実行数をより大きい値に更新します。