Amazon SAA-C03: データベースとキャッシング — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

Amazon RDS: マネージドリレーショナルエンジン

Amazon RDSは、MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、そしてAmazon Aurora（MySQLおよびPostgreSQL互換）の6つのマネージドエンジンを提供し、パッチ適用、バックアップ、レプリケーション構成、フェイルオーバーなどを抽象化します。エンジンの選択によって、ライセンス、バックアップのセマンティクス、利用可能な機能が決まります。例えば、OracleとSQL ServerにはBYOL（ライセンス持ち込み）とライセンス込みの区別があり、SQL Serverはネイティブレプリケーションを介して最大5つのリードレプリカをサポートし、OracleのリードレプリカにはEnterprise EditionとActive Data Guardが必要です。

可用性とスケールのために最も活用され、そして最も混同されやすい2つのRDS機能が、マルチAZ配置とリードレプリカです。これらは直交的かつ補完的な関係にあり、互換性はありません。

マルチAZは、2つ目のアベイラビリティーゾーンに同期スタンバイレプリカをプロビジョニングします。すべての書き込みは、確認応答の前にプライマリとスタンバイの両方にコミットされるため、RPOは実質的にゼロとなり、自動フェイルオーバー中のRTOは60～120秒です。スタンバイはトラフィックを受け付けません。その存在理由はフェイルオーバーのためだけです。プライマリに障害が発生した場合、AZが機能不全に陥った場合、またはメンテナンスで再起動が必要な場合に、RDSはDNS CNAMEをスタンバイに切り替え、アプリケーションは同じエンドポイントを通じて透過的に再接続します。マルチAZは、単一AZの単一障害点に対する最も手軽な修正方法です。設定を切り替えるだけで、スキーマやアプリケーションの変更は不要で、エンドポイントも維持されます。より新しいマルチAZクラスター配置は、3ノード構成（1つのライター、2つの読み取り可能なスタンバイ）で、約1秒のコミットレイテンシーを持つ準同期レプリケーションを使用し、HAに加えて限定的な読み取りオフロードを提供します。

リードレプリカは、エンジンのネイティブな非同期レプリケーション（MySQLのバイナリログ、PostgreSQLのWALストリーミング）を使用します。これらは、プライマリのOLTPを逼迫させるような分析クエリ、レポート用ダッシュボード、アドホックなSELECT文といった、読み取りスケーリングのための正しいツールです。典型的なシナリオは、従業員が月末に時間のかかるレポートを実行するため、注文処理データベースがタイムアウトするというものです。リードレプリカを追加し、レポートツールをそのエンドポイントに向けることで、プライマリをスケールアップすることなく分析負荷を分離できます。リードレプリカはクロスリージョンに配置でき、手動でスタンドアロンデータベースに昇格させることもできますが、昇格は決して自動ではなく、障害発生時にまだレプリケーションされていなかったトランザクションは失われます。

この分野では、2つのよくある落とし穴があります。第一に、リードレプリカをHAソリューションとして扱うことは、複数の理由から間違いです。レプリカは非同期（データ損失の可能性あり）、自動昇格機能がない、昇格時にエンドポイントが変わる、そしてインフライトトランザクションが消滅します。もし設計が「ゼロデータ損失」を約束し、フェイルオーバーターゲットとしてリードレプリカを指しているなら、その約束は偽りです。第二に、読み取りトラフィックを処理するためにマルチAZをプロビジョニングすることは、標準的な構成ではスタンバイが読み取り可能でないため、費用の無駄です。マルチAZは可用性を解決し、リードレプリカは読み取りスケールを解決します。多くの場合、両方が必要になります。

また、リードレプリカは書き込みスケーリングには何の効果もありません。すべての書き込みは依然としてプライマリにヒットし、レプリカはそれをリプレイする必要があります。書き込みスケールのためには、シャーディングするか、Aurora（分離されたストレージ）に移行するか、DynamoDBへの再設計を検討します。

リードレプリカの適切なサイジング

レプリカは、プライマリのインスタンスクラスと一致させる必要はありません。プライマリは完全な書き込み負荷と読み取りを処理しますが、レプリカは自身にヒットする読み取りのみを処理します。夜間のレポートジョブのためにdb.r6i.4xlargeのプライマリとdb.r6i.largeのレプリカを組み合わせることは、レプリカがレプリケーションI/Oに追いつける限り、全く合理的です。その方法論は、レプリカの実際のCPU、メモリ、レプリカラグを測定し、そのワークロードに合わせてサイジングすることです。唯一の注意点は、DR中にレプリカをプライマリに昇格させるつもりなら、書き込み負荷を処理できるサイズにする必要があるということです。アンダーサイズのレプリカは昇格ターゲットにはなりません。

Blue/Greenデプロイメントとストレージ

RDS Blue/Greenデプロイメントは、本番環境（グリーン）の完全なステージングコピーを作成し、論理レプリケーションを介して同期を保ちます。グリーン上でエンジンバージョンのアップグレード、パラメータグループの変更、スキーマの変更を行い、テストした後、エンドポイントの自動名前変更により1分未満で切り替えることができます。これにより、メジャーバージョンアップグレードの失敗がスナップショットからのロールバックを強制するような、従来のインプレースアップグレードのリスクを排除します。

書き込み負荷の高いOLTPでは、ストレージの選択がインスタンスクラスと同じくらい重要です。gp3/io2の分類は以下の通りです。

gp2に対するgp3の改善点は、IOPSがサイズから分離されたことです。これにより、パフォーマンスのために容量を過剰にプロビジョニングする必要がなくなりました。持続的なIOPSがgp3の上限を超える場合や、99.999%の耐久性が必要な場合はio2を選択します。Multi-Attachは、単一のio2ボリュームを最大16のNitroインスタンスにアタッチできますが、ファイルシステムやアプリケーションがクラスター対応である必要があります。これはレプリケーションの代替にはなりません。潜在的な障害の罠は、ストレージの自動スケーリングを有効にせず、またはFreeStorageSpaceに対するCloudWatchアラームを設定せずに固定ストレージをプロビジョニングすることです。空き容量がゼロになると、RDSはstorage-full状態になり、書き込みを拒否します。

Amazon Aurora: アーキテクチャとエンドポイント

Auroraは、MySQLとPostgreSQLの基盤となるストレージレイヤーを、3つのAZにまたがる分散型、ログ構造、6重にレプリケートされたボリュームとして再実装しています。コンピュートノードはストレージに対してステートレスであるため、Auroraレプリカはログを再生するのではなく、ライターと同じ基盤となるボリュームから読み取ります。レプリケーションラグは通常10～20ミリ秒であり、標準的なRDSレプリカの数秒と比較して大幅に短縮されています。また、クラスターは最大15個のレプリカをサポートし、約30秒でライターに昇格させることができます。

Auroraは4種類のエンドポイントを公開しています。

カスタムエンドポイントは、レプリカが不均一である場合に重要です。6つのレプリカのうち3つが分析レポート用のdb.r6g.8xlargeで、残りがOLTPの読み取り処理を担っている場合、汎用のリーダーエンドポイントは時折、レポート処理をより小さなノードにルーティングしてしまい、予測可能性を損ないます。大規模なレプリカのみを対象とするカスタムエンドポイントを使用することで、決定論的なワークロードの分離が実現します。

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

AuroraエンドポイントのDNS TTLは5秒であることに注意してください。接続文字列をそれより長くキャッシュすると、フェイルオーバーの動作が妨げられます。

Aurora Auto Scalingは、ターゲットCPU使用率や接続数のメトリクスに基づいてリーダーを追加・削除します。これは、予測不可能で読み取り負荷が高く、高可用性を維持する必要があるワークロードに対する標準的な解決策です。

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

RDS MySQLのリードレプリカがピーク時にレプリケーションラグを1秒未満に維持できない場合、コードの変更が少ない解決策はAurora MySQLへの移行です。接続文字列はほとんど変わらず、ストレージレベルのレプリケーションがラグを解消します。

Aurora Serverless v2とクローニング

Aurora Serverless v2は、セッションを切断することなく、きめ細かいAurora Capacity Unit（ACU、各2GiBメモリ）単位でコンピュートを約0.5秒で垂直にスケーリングします。これは、ベースラインのメモリフットプリントが既知の変動するワークロードに適しています。例えば、常に最低2GiBを消費するオンプレミスのMySQL移行などが該当します。最小を1 ACU、最大を32 ACUに設定すると、クラスターは管理なしで柔軟に伸縮します。負荷が安定して予測可能な場合は、Serverless v2にはACUあたりの追加料金がかかるため、プロビジョニングされたAuroraの方が依然として望ましいです。

Auroraクローニングは、コピーオンライト方式でソースのストレージページを共有する新しいクラスターを作成します。クローンは数秒で作成され、データが分岐するまでコストはかかりません。そのため、ステージング環境、リスクの高い移行、またはアナリストが本番環境のコピーに負荷をかける場合に最適です。スナップショットの復元は物理的にデータを再構築するため数時間かかることがありますが、速度が重要な場合はクローニングが優れています。

Aurora Global Database

Aurora Global Databaseは、binlog転送ではなく、専用のストレージレイヤーレプリケーションインフラストラクチャを使用して、クラスターを最大5つのセカンダリリージョンに拡張します。一般的なレプリケーションラグは1秒未満、RPOも1秒未満で、マネージドフェイルオーバーにより1分未満でセカンダリを昇格させることができます。

2つの重要なセマンティクスがあります。通常運用時、セカンダリリージョンは読み取り専用であること、そしてGlobal Databaseはアクティブ-アクティブのマルチマスターではなく、低RPOのDRと低レイテンシーのリモート読み取り用に設計されていることです。グローバルDBが「セカンダリリージョンでの書き込みを自動的に処理する」と考えるのは間違いです。そこでの書き込みには、明示的なマネージドフェイルオーバーまたはデタッチとプロモートが必要です。リージョン間で5分のRPO / 20分のRTOという要件が最小限の運用オーバーヘッドで求められる場合、Global Databaseが標準的な解決策です。

RDS Proxyと接続管理

サーバーレスや高並行性のワークロードは、コネクションストーム（接続の嵐）という古典的な問題を悪化させます。3,000の同時実行にスケールしたLambda関数は3,000のソケットを開き、max_connectionsを使い果たし、まさにシステムに負荷がかかっているときに連鎖的な障害を引き起こします。各同時実行環境は分離されているため、関数内のプールは役に立ちません。

RDS Proxyはクライアントとデータベースの間に位置し、温かい接続プールを維持し、クライアントセッションをそれらに多重化します。これにより2つの問題が解決します。

1. コネクションストーム。 数千のクライアントセッションが、少数のバックエンドプールに多重化されます。
2. フェイルオーバー時間。 プロキシはバックエンドリンクを再確立する間、クライアント接続を開いたまま保持し、体感的なフェイルオーバー時間を最大66%短縮し、クライアント側のTCP/TLS再確立やDNS再解決を不要にします。

RDS Proxyは認証情報の処理のためにIAMやSecrets Managerと統合されており、アプリケーションコードからハードコードされたシークレットを排除します。

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

アプリケーションはクラスターエンドポイントではなく、プロキシエンドポイントに接続します。LambdaからRDSへの接続や、高いファンアウトを持つアーキテクチャでは、特別な理由がない限りRDS Proxyを使用すべきです。独自のプーラー（PgBouncer, ProxySQL）をEC2で実行することも可能ですが、プロキシが排除するために存在する運用オーバーヘッドが追加されます。

DynamoDB: キャパシティモード

DynamoDBは、マネージド型のキーバリュー/ドキュメントストアであり、あらゆる規模で1桁ミリ秒のレイテンシーを実現し、ハッシュキーによって水平にパーティショニングされます。2つのキャパシティモードを提供しています。

オンデマンドは劇的にシンプルですが、リクエストあたりのコストは、うまく活用されたプロビジョニング済みキャパシティよりも約6～7倍高くなります。500 WCUで毎晩4時間のバッチ処理を行う場合、オンデマンドでは大幅に過払いになります。スケジュールされたスケーリングやリザーブドキャパシティを利用したプロビジョニング済みモードの方がはるかに安価です。逆に、予測不可能な公開ローンチのワークロードにプロビジョニング済みモードを使用すると、スロットリングが発生します。中程度の変動がある安定したワークロードの場合、使用率70%前後を目標とするターゲット追跡オートスケールを設定したプロビジョニング済みモードは、オンデマンドよりも大幅に安価です（多くの場合50～70%安価になります）。

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

キャパシティモードは24時間に1回切り替えることができます。オンデマンドが常に安価であると考えるのは高くつく間違いです。同様に、プロビジョニング済みがスパイク状のトラフィックに常に適していると考えるのも間違いです。

DynamoDB: 整合性、Streams、グローバルテーブル

読み込みはデフォルトで結果整合性（約1秒以内の古いデータを返す可能性があり、コストは0.5 RCU）です。ConsistentRead=true を設定すると、2倍のコストで最新のコミット済み値を返します。強力な整合性のある読み込みは、グローバルセカンダリインデックスやDAX経由ではサポートされていません。これらのパスは常に結果整合性のあるデータを返します。

DynamoDB Streamsは、アイテムレベルの変更を順序付けられたログとしてキャプチャし、24時間保持します。これにより、ポーリングすることなく、後続処理（検索インデックス作成、通知、テーブル間の非正規化など）のためにLambdaをトリガーします。

グローバルテーブルはStreamsを基盤として構築され、最終書き込み者優先（last-writer-wins）の競合解決方式を持つマルチアクティブ・マルチリージョンレプリケーションを提供します。複数のリージョンで読み書きをローカルに実行する必要がある場合に最適なソリューションです。しかし、ストレージと書き込みのコストがほぼ2倍になり（すべての書き込みが各レプリカリージョンでWCUを消費するため）、リージョン間の一貫性は弱まります。単一リージョンで可用性要件を満たせるにもかかわらずグローバルテーブルを有効にすることは、よくある落とし穴です。単一リージョンのDynamoDBは、すでに3つのAZにまたがってレプリケートされており、99.99%の可用性を実現しています。コスト効率の高い単一リージョンでの高可用性（HA）構成は、PITRを有効にし、必要に応じてオートスケール付きのプロビジョニング済みキャパシティを設定した単一リージョンテーブルです。

**ポイントインタイムリカバリ (PITR)**は、過去35日間の継続的なバックアップを秒単位の復元粒度で、無視できるほどのオーバーヘッドで提供します。本番環境のテーブルでは有効にすべきです。これにより、時間単位ではなく分単位という一般的なRPO要件を満たすことができます。より長期間の保持（規制上の保持要件など）が必要な場合は、AWS Backupを統合して、スケジュール化され、ライフサイクル管理され、リージョン間でコピー可能なバックアップを取得します。

TTLを使用すると、Unixエポック形式の有効期限を含む属性を指定できます。DynamoDBは期限切れのアイテムをコストなしで非同期に削除するため、セッションストア、一時的なトークン、イベントキャッシュなどに最適です。TTLによる削除はStreamsを通過するため、後続のアーカイブ処理に利用できます。

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

分析用途には、S3へのエクスポート機能を使用します。これにより、テーブルのキャパシティを消費することなく、Athena、Redshift Spectrum、またはEMRで読み取り可能なポイントインタイムスナップショットが生成されます。これはテーブルをスキャンするよりもはるかに優れたパターンです。

DAX: DynamoDB Accelerator

DAXは、DynamoDB専用のフルマネージド型インメモリ・ライトスルーキャッシュであり、DynamoDBのベースラインである1桁ミリ秒のレイテンシーに対し、マイクロ秒単位の読み取りレイテンシーを実現します。その際立った特徴はAPI互換性です。DAXクライアントはDynamoDB SDKクライアントのドロップインリプレースメントであるため、アプリケーションはクエリロジックを書き換えるのではなく、エンドポイント設定を変更するだけでDAXを導入できます。

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAXは2種類のキャッシュを維持します。GetItem/BatchGetItemの結果を格納するアイテムキャッシュと、Query/Scanの結果を格納するクエリキャッシュです。書き込みはライトスルー方式です。DAXはDynamoDBへの書き込みをプロキシし、成功時に自身のアイテムキャッシュを更新します。しかし、クエリキャッシュはTTLに依存するため、新しく書き込まれたアイテムに対してもクエリ結果が古くなる可能性があります。

2つの制約が重要です。第一に、DAXは結果整合性のある読み込みのみを高速化します。強力な整合性のある読み込みはキャッシュをバイパスします。第二に、DAXをバイパスする他のライターが存在すると、キャッシュの陳腐化が発生します。1日に何百万回もアクセスされる製品詳細ページのようなユースケースでは、DAXは運用オーバーヘッドが最も少ないアクセラレーターです。キャッシュ無効化コードや、個別のクラスター管理は不要です。DynamoDBの前にElastiCacheを配置することも可能ですが、その場合はDAXが不要にするキャッシュアサイドロジックの実装が必要になります。

ElastiCache: RedisとMemcached

ElastiCacheは、RedisまたはMemcachedを実行するマネージドサービスとして、サブミリ秒のインメモリデータアクセスを提供します。エンジンの選択は機能に基づいて行います。

• Memcached — 水平シャーディングを備えた純粋なマルチスレッドのキーバリューキャッシュで、永続化、レプリケーション、Pub/Subはありません。キャッシュ全体が失われても許容できる、一時的なキャッシングにのみ使用します。
• Redis — レプリケーション、自動フェイルオーバーを伴うマルチAZ、シャーディングのためのクラスターモード、永続化、Pub/Sub、ソート済みセット、トランザクション、転送中および保存時の暗号化をサポートします。耐久性や複雑なデータ型が要求されるあらゆる用途に必要です。

2つの典型的なパターンが主流です。

セッションストアの一元化。 ALBがステートレスなEC2やECSインスタンスにトラフィックを分散させる場合、ローカルのセッションストレージではスティッキーセッションが必須となり、負荷が不均衡になったり、スケールイン、デプロイ、AZ障害時に機能しなくなったりします。セッションをRedisに外部化することで、どのインスタンスでも任意のリクエストを処理できるようになり、セッションはホスト障害を乗り越えることができます。

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

負荷の高いクエリの読み取りオフロード — リーダーボード（Redisのソート済みセットをZADD/ZREVRANGEで実現）、カタログ検索、集計など。キャッシング戦略は、一貫性の要件に合わせる必要があります。

• 遅延読み込み（キャッシュアサイド）: アプリはキャッシュを読み込みます。キャッシュミスの場合、DBを読み込んでTTL（Time To Live）付きでキャッシュにデータを格納します。シンプルですが、コールドスタート時のキャッシュミスはパフォーマンスに影響し、データが古くなる可能性があります。
• ライトスルー: アプリは単一の操作でキャッシュとDBの両方に書き込みます。キャッシュは最新に保たれますが、書き込みは遅くなり、未使用のデータもメモリを占有し続けます。
• ライトバック（ライトビハインド）: 書き込みはまずキャッシュに行われ、非同期でDBにフラッシュされます。書き込みは最速ですが、キャッシュに障害が発生するとデータが失われます。

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

TTL、更新時の明示的なDEL、ライトスルーといった無効化戦略なしにキャッシングレイヤーに依存すると、古いデータを読み込む（stale read）原因となります。この障害モードはサイレントです。つまり、ユーザーがデータの不一致に気づくまで、アプリケーションは正常に動作しているように見えます。また、キャッシングは、リードレプリカが快適にサポートできる範囲を超えて読み取りをスケールさせる最も安価な方法であることが多く、トラフィック急増時にはプライマリDBを保護する役割も果たします。

DAXとは異なり、ElastiCacheはエンジンに依存しません。つまり、無効化ロジックはユーザー自身が管理します。これが、バックエンドストアがDynamoDBの場合に、運用上のシンプルさでDAXが優れている理由です。

移行: DMSとSCT

**AWS Database Migration Service (DMS)**は、同種エンジン間（Oracle→Oracle、MySQL→Aurora MySQL）または異種エンジン間（Oracle→Aurora PostgreSQL、SQL Server→RDS MySQL、オンプレミス→DynamoDB）でデータをレプリケートします。DMSタスクには3つのフェーズがあります。

1. フルロード — 既存の行をバルクコピーします。
2. CDC（変更データキャプチャ） — ソースのトランザクションログを追跡し、継続的な変更を適用します。
3. フルロード + CDC — ダウンタイムを最小化する一般的なパターンです。ソースはオンラインのままでDMSがターゲットを同期し続け、カットオーバーは短いDNSの切り替えで完了します。

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverlessは、レプリケーションインスタンスのサイジングと管理の必要性をなくします。容量はワークロードに合わせて自動プロビジョニングされるため、変動のある、または長期間実行されるCDCに適しています。ソースエンジンでは、補足ロギング（Oracle）またはROW形式のバイナリロギング（MySQL）を有効にする必要があります。非常に大規模な初期データロードの場合、DMSはオフラインロードのためにSnowball Edgeと統合できます。

DMSはスキーマではなくデータを移行します。異種エンジン間の移行では、**AWS Schema Conversion Tool (SCT)**と組み合わせて使用します。SCTは、ストアドプロシージャ、ビュー、トリガー、シーケンス、方言固有の型（例: Oracle PL/SQLからPostgreSQL PL/pgSQLへ、T-SQLからAurora MySQLへ）を変換します。SCTは、手動での修正が必要なオブジェクトを指摘する評価レポートを生成します（複雑なコードベースでは通常5〜20%）。エンジン間の移行でDMSのみを使用するのはよくある間違いです。DMSは基本的なターゲットテーブルを作成できますが、プロシージャや独自の型を正しく変換することはできません。同種エンジン間の移行ではSCTは不要で、ネイティブツール（mysqldump、pg_dump、RMAN）とDMS CDCで十分です。

エンジン間移行の完全なパターンは次のとおりです。

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

バックアップとポイントインタイムリカバリ

RDSの自動バックアップは、毎日のスナップショットと5分ごとのトランザクションログバックアップを組み合わせることで、保持期間（1〜35日、デフォルトは7日）内の任意の秒へのポイントインタイムリカバリ（PITR）を可能にします。復元時には新しいインスタンスが作成されるため（インプレースでの復元はできません）、アプリケーションのエンドポイントやCNAMEを更新する必要があります。手動スナップショットは保持期間を超えて永続し、インスタンスを削除しても（最終スナップショットの設定によりますが）残り、DRのためにクロスリージョンでコピーしたり、アカウント間で共有したりできます。

EBSベースのスナップショット用の**高速スナップショット復元（FSR）**は、遅延読み込みのペナルティをなくし、復元されたボリュームが即座に完全なパフォーマンスを発揮できるようにします。これは、時間的制約がある中で1つのスナップショットから複数の環境を立ち上げる際に便利です。Auroraのクローニングは、同一リージョン内のコピーではスナップショットを完全にバイパスします。DynamoDBのPITRは並行する機能であり、テーブルごとに有効にする必要があり、復元時には新しいテーブルが生成されます。

特定目的向けデータベース

アクセスパターンがそれを要求する場合に特定目的向けエンジンを選択することで、高コストな再設計を防ぐことができます。Amazon Neptuneは、Gremlin、openCypher、SPARQLをサポートするマネージドグラフデータベースです。リレーショナルエンジンでは再帰的なJOINのコストが非常に高くなるような、関係性をたどるクエリ（不正利用のネットワーク、ソーシャルグラフ、ナレッジグラフ）に適しています。Amazon QLDBは、追記専用のジャーナルを持つ、不変で暗号的に検証可能な台帳データベースです。改ざん検出可能な監査を必要とする記録システム（サプライチェーンの来歴、金融取引、自動車登録記録など）に適しています。DynamoDBは、シングルテーブル設計、階層アクセス用の複合ソートキー、代替アクセスパス用のGSIといったパターンを使用し、あらゆる規模で1桁ミリ秒のキーバリューまたはドキュメントアクセスが必要な場合のデフォルトの選択肢です。これらのワークロードを無理にRDSに押し込むと、ロック競合（台帳の書き込み）、クエリの複雑さ（グラフの走査）、またはスケーリングの上限（高スループットのキーバリューアクセス）といった問題が生じます。これらはそれぞれ、設計時に正しく選択しなかった場合、後で修正する方がはるかにコストがかかります。

よくある落とし穴のまとめ

• リードレプリカをHA構成として利用する。 非同期レプリケーションであり、自動プロモーション（昇格）はなく、プロモーション時にエンドポイントが変更され、実行中のトランザクションは失われます。HAの答えはMulti-AZです。
• 読み取りスケーリングのためにMulti-AZを利用する。 標準のRDS Multi-AZでは、スタンバイインスタンスは読み取り不可です。リードレプリカまたはAuroraレプリカを使用してください。
• 本番環境でSingle-AZ構成を利用する。 フェイルオーバー先がなく、AZのイベントやインスタンスの再起動で可用性が失われます。Multi-AZは約2倍のコストがかかりますが、可用性が質的に大きく向上します。
• デフォルトでレプリカをプライマリと同じサイズにする。 レプリカは多くの場合、より小さいサイズで十分です。プロモーションのターゲットでない限り、計測されたワークロードに合わせてサイジングしてください。
• DynamoDBのオンデマンドモードが常に安いと考える。 リクエストあたりのコストは約6〜7倍です。安定したワークロードでは、プロビジョニング＋Auto Scalingの方が有利です。
• 単一リージョンの要件でGlobal Tablesを使用する。 マルチリージョンでのユーザー近接性やDRが不要な場合、メリットなくコストが2倍になり、一貫性が低下します。
• Aurora Global Databaseのセカンダリが書き込みを処理できると考える。 マネージドフェイルオーバーでプロモート（昇格）されるまで、読み取り専用です。
• RDS ProxyなしでLambdaからRDSに接続する。 コネクションストームがmax_connectionsを枯渇させます。関数内のプールは、同時実行環境をまたいでは機能しません。
• 異種データベース移行にDMSのみを使用する。 データは移行しますが、スキーマは移行しません。SCTと組み合わせて使用してください。
• RDSストレージを固定サイズで、自動スケーリングやFreeStorageSpaceアラームなしで運用する。 潜在的な障害につながります。storage-full状態になると書き込みが拒否されます。
• キャッシュの無効化戦略なしでキャッシングを行う。 気づかないうちにデータが陳腐化します。TTL、ライトスルー、または明示的な無効化は必須です。
• DAXやGSI経由で強い整合性のある読み取りができると考える。 どちらのパスも結果整合性のあるデータしか提供しません。

← コンテンツ配信、エッジ、パフォーマンス最適化 · すべてのドメイン · アナリティクス、データレイク、ML、特殊なワークロード →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →