Q1 — 単一選択既存のMySQL互換注文データベースでは、複数テーブルの結合とトランザクションを利用しています。キャンペーンによって負荷が大きく変動するため、運用担当者が事前にDB容量を増やし、終了後に縮小しています。
Relational要件を維持しながら、この容量調整の運用負荷を減らすモダナイゼーションとして最も適切なものはどれですか。
A. データベース全体をAmazon DynamoDBへ移し、既存の結合と複数テーブルのトランザクションを変更せず利用する
B. Aurora Serverlessを評価し、Relationalモデルを維持しながら需要に応じた容量調整を利用する
C. Amazon ElastiCacheを注文データの正規保存先にし、永続的なトランザクション処理もCacheだけで行う
D. ピーク時に必要な固定容量へ常時引き上げ、需要が低い期間も同じ容量を維持する
答えと解説
答え:B
結合やトランザクションなどのRelational要件を維持したまま、負荷変動に応じた容量調整の運用負荷を減らしたい場合はAurora Serverlessを評価できます。
Aurora Serverlessは指定した容量範囲で需要に応じて容量を自動調整するため、ピーク前後にDB容量を手動変更する責任を減らせます。
Q2 — 単一選択既存のリレーショナルデータベースでは、会員情報の参照自体はuser_idによる取得が中心です。
ただし購入処理では、注文行の作成と会員ポイント更新を同じデータベーストランザクションで原子的に確定しています。
会員情報をAmazon DynamoDBへ切り出す案を評価するとき、最も適切な判断はどれですか。
A. 会員情報を直ちにDynamoDBへ移し、注文DBとの原子的な更新関係は変更しなくても維持できるとみなす
B. 注文とのトランザクション境界を先に分離できるか確認し、独立したAccess Patternになった段階でDynamoDBを再評価する
C. 会員情報だけをElastiCacheへ移し、購入処理の整合性要件を確認せず同じトランザクションとして扱う
D. user_id参照があるため注文データも含めてDynamoDBへ移し、既存の結合とトランザクションをそのまま維持する
答えと解説
答え:B
キーによる取得が中心でも、他データと同一トランザクションに含まれているなら、その依存関係を無視して切り出すことはできません。現在のトランザクション境界を確認し、独立した責任へ分離できる状態になってからAmazon DynamoDBを再評価します。
Q3 — 単一選択既存の業務データベースには、注文処理とセッション状態が同居しています。
注文処理は複数テーブルの結合とトランザクションを必要とします。一方、セッション状態はsession_idによる取得・更新だけで完結し、注文データとの結合や同一トランザクションはありません。
モダナイゼーションとして最も適切なものはどれですか。
A. 一部にKey-value Access Patternがあるため、注文を含むデータベース全体をAmazon DynamoDBへ移行する
B. 注文処理はRelationalとして残し、独立したセッション責任だけをAmazon DynamoDBへ分離できるか評価する
C. 注文とセッションをAmazon ElastiCacheへ移し、正規データの保存先もCacheへ統一する
D. データベースを分割するとサービス数が増えるため、Access Patternに関係なく今後も必ず1つのRDBだけを利用する
答えと解説
答え:B
目的別データベースへのモダナイゼーションでは、データベース全体を1つのサービスへ置き換える必要はありません。Relational要件を持つ注文処理は残し、独立したKey-value Access Patternであるセッションだけを分離できるかを評価します。
Q4 — 単一選択既存の業務データベースでは、商品表示用の高負荷な反復読み取りと、低頻度で利用される管理用データが同居しています。
商品表示用の読み取りは正規データを変更せずCacheを追加できます。一方、管理用データを別データストアへ切り出すと、既存RDBとの同期処理、正規データの所有元の決定、障害時の整合性管理が新たに必要になります。
最も適切なモダナイゼーションはどれですか。
A. Purpose-built Databaseを利用するため、商品表示用読み取りと管理用データの両方を必ず別データストアへ分離する
B. 商品表示用読み取りへAmazon ElastiCacheを追加し、管理用データは分離効果が追加複雑性を上回るまで既存RDBに残す
C. 管理用データを最初にAmazon DynamoDBへ複製し、既存RDBとの二重書き込みを恒久的に行えば整合性設計は不要とみなす
D. 新しいデータストアを追加すると複雑になるため、商品表示用の高負荷な反復読み取りについてもCacheを利用しない
答えと解説
答え:B
Purpose-built Databaseへの分離は、利用できるサービスを増やすこと自体が目的ではありません。正規データの所有関係を変えずに効果を得やすいAmazon ElastiCacheから段階的に適用し、別データストアへの切り出しによって同期や整合性管理が必要になる処理は、その追加責任に見合う効果があるかを確認してから分離します。