無限ノック › SAP 練習問題一覧 › 問題
SAP既存のソリューションの継続的改善

ある金融系企業は、社内の与信審査アプリケーションを単一リージョンの Amazon RDS for PostgreSQL(シングル AZ、db.r6g.4xlarge)上で運用しています。日次バッチと業務時間中のオンライン処理が混在し、最近は読み取り負荷の増加でレポート生成が遅延しています。直近の AZ 障害で約 30 分の停止が発生したことを受け、信頼性向上のため次の要件が出されました。 ・計画外フェイルオーバー時間を約 35 秒以内に短縮する。 ・読み取りクエリを別ノードにオフロードして書き込みノードの負荷を下げる。 ・アプリケーションコードの変更は最小限にする。 ・PostgreSQL エンジンを維持する。 これらをすべて満たす最も適切な改善策はどれですか。

A
RDS for PostgreSQL をマルチ AZ DB クラスター配置(ライター 1 台+リーダブルスタンバイ 2 台)に変更し、アプリケーションは書き込みにクラスターエンドポイント、読み取りにリーダーエンドポイントを使用するよう接続先を切り替える
✓ 正解
マルチ AZ DB クラスター配置はライター+リーダブルスタンバイ 2 台構成で約 35 秒以内の自動フェイルオーバーを提供し、リーダーエンドポイントで読み取りをオフロードできる。PostgreSQL を維持しエンドポイント切り替えのみで済むため、全要件を最小変更で満たす。
B
RDS for PostgreSQL をマルチ AZ DB インスタンス配置(1 つのスタンバイ)に変更し、レポート用に同一リージョンのリードレプリカを 2 台追加して、読み取りクエリをリードレプリカのエンドポイントへ振り向ける
マルチ AZ DB インスタンス配置のスタンバイは読み取りに使えず、フェイルオーバーも通常 60〜120 秒程度を要するため 35 秒要件を満たせない。リードレプリカ追加で読み取りは分散できるが、フェイルオーバー時間の要件で失格となる。
C
RDS for PostgreSQL をシングル AZ のまま維持し、同一リージョンに非同期リードレプリカを 2 台追加して読み取りをオフロードし、障害時はいずれかのリードレプリカを手動でプライマリに昇格させる
シングル AZ のままでは AZ 障害に対する可用性が確保できず、リードレプリカの手動昇格は完了まで時間がかかる。計画外フェイルオーバーを約 35 秒以内に抑える要件を満たせず、信頼性向上の目的にも反する。
D
データベースを Amazon Aurora PostgreSQL 互換エディションに移行し、Aurora レプリカを 2 台構成してリーダーエンドポイントで読み取りを分散し、フェイルオーバーは Aurora の自動フェイルオーバーに任せる
Aurora PostgreSQL は高速フェイルオーバーと読み取り分散を提供できるが、RDS for PostgreSQL から Aurora へエンジン基盤を移行する作業が必要となる。エンジン維持と変更最小限という制約に反するため最適ではない。

解説

RDS for PostgreSQL のマルチ AZ DB クラスター配置は、1 台のライターと 2 台のリーダブルスタンバイを 3 つの AZ に配置する構成で、通常 35 秒以内(多くは 35 秒未満)の高速な自動フェイルオーバーを提供する。 リーダブルスタンバイは読み取りクエリを処理できるため、リーダーエンドポイント経由でレポートなどの読み取り負荷をライターからオフロードでき、要件の読み取り分散を満たす。 PostgreSQL エンジンをそのまま維持でき、アプリケーションはエンドポイントの切り替えのみで対応できるためコード変更も最小限となる。 これにより、フェイルオーバー時間短縮・読み取りオフロード・最小変更・エンジン維持のすべてを同時に満たせる。 選択肢Bのマルチ AZ DB インスタンス配置はスタンバイが読み取り不可で、フェイルオーバーも通常 60〜120 秒程度かかり 35 秒要件を満たせない。 選択肢Cのシングル AZ+手動昇格は、可用性が AZ 障害に耐えられず手動昇格に時間がかかるため 35 秒の計画外フェイルオーバー要件に反する。 選択肢Dの Aurora への移行は要件を技術的に満たせるが、エンジンを Aurora へ移行する変更が大きく「エンジン維持・変更最小限」の制約に反する。

ドメイン別正答率・予想スコアでリアルタイムに実力把握

無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。

無料で演習を始める →
← SAP の問題一覧に戻る