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

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

データベースとキャッシュは、SysOps管理者の中心的な運用責任です。これらはアプリケーションに永続的なストレージ、可用性、低レイテンシーの読み取りを提供します。このドメインでは、マネージドリレーショナルデータベース（RDSおよびAurora）の実行、読み取り/書き込みキャパシティのスケーリング、レプリケーションとフェイルオーバーの動作、およびDB負荷を軽減するためのElastiCacheの使用について扱います。バックアップ、パラメータグループ、モニタリング、キャッシュ無効化パターンを適切に設定することで、データ損失を防ぎ、運用上のインシデントを削減します。

RDSとAuroraの運用、バックアップ、Multi-AZ

RDS（MySQL、PostgreSQL、MariaDB、Oracle、SQL Server）とAmazon Aurora（MySQLおよびPostgreSQL互換）は、運用上の特性が異なるマネージドリレーショナルエンジンです。RDSのMulti-AZは、別のAZに同期スタンバイを作成します。これはAWSによって管理され、数分以内に自動フェイルオーバーが行われ、手動での昇格は不要で、スタンバイは読み取りアクセス不可です。Auroraはライターエンドポイントとリーダーエンドポイントを分離します。ライターはプライマリによってバックアップされるクラスターエンドポイントであり、AuroraはAZ間で自動的にレプリケートされる分散ストレージを使用し、ストレージが共有されているため通常RDSよりも高速にフェイルオーバーできます。

バックアップと保持期間の設定：

• 自動バックアップ：保持期間を指定して有効にします（例：modify-db-instance –backup-retention-period 7）。これにより、サポートされているエンジンでは保持期間内の任意の秒へのポイントインタイムリカバリ（PITR）が可能になります。
• 手動スナップショット：create-db-snapshot（Auroraの場合はcreate-db-cluster-snapshot）を実行して、保持されるスナップショットをキャプチャします。スナップショットは削除するまで永続します。
• PITRリストア：RDSの場合はaws rds restore-db-instance-to-point-in-time、Auroraの場合はrestore-db-cluster-from-snapshotを実行してからインスタンスを作成します。

判断基準：

• 書き込みの可用性が重要で、スタンバイでの読み取りが不要な場合は、高可用性と自動フェイルオーバーのためにMulti-AZを使用します。
• 高いIOPS、高速なフェイルオーバー、ストレージの自動スケーリングが必要な場合は、Aurora（クラスター化ストレージ）を使用します。
• 読み取りスケーリングとクロスリージョンでの災害復旧には、リードレプリカを使用します（これらは非同期であり、昇格可能です）。

運用CLIの例：

• Multi-AZの有効化：aws rds modify-db-instance –db-instance-identifier mydb –multi-az –apply-immediately
• 自動スナップショットの作成：aws rds create-db-snapshot –db-snapshot-identifier snap1 –db-instance-identifier mydb
• PITRリストア：aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –restore-time “YYYY-MM-DDTHH:MM:SSZ”

リードレプリカ、フェイルオーバー、レプリケーション戦略

リードレプリカは、主に読み取りトラフィックをスケールさせ、レポート作成をオフロードするために使用される非同期コピー（RDSまたはAuroraリーダー）です。レプリケーションラグ（ReplicaLagメトリクスを監視）が発生し、強力な整合性には適していません。リードレプリカは、災害復旧をサポートするためにスタンドアロンのDBインスタンスに昇格させることができます。

レプリケーション戦略と選択肢：

• 同期（RDS Multi-AZスタンバイ）— データドリフト（乖離）がないことを保証しますが、スタンバイに読み取りキャパシティはありません。
• 非同期リードレプリカ — 読み取りをスケールさせ、クロスリージョンコピーを可能にしますが、レプリカラグのリスクとフェイルオーバー時の潜在的なデータ損失があります。
• Auroraリーダー — クラスター化された読み取りエンドポイント、エンドポイントの再ルーティングによる低レイテンシーのフェイルオーバー、およびリーダーエンドポイントの自動バランシングを提供します。

運用パターン：

• リードレプリカの作成：aws rds create-db-instance-read-replica –db-instance-identifier read1 –source-db-instance-identifier primary
• レプリカの昇格：aws rds promote-read-replica –db-instance-identifier read1
• モニタリング：CloudWatchのDatabaseConnections、ReplicaLag、ReadIOPS、WriteIOPS、およびPerformance Insightsを使用して、レプリカを追加または削除するタイミングを判断します。

判断基準：

• 書き込みのHAが必要な場合はMulti-AZを選択します。読み取りスループットと分析のオフロードが必要な場合は、リードレプリカまたはAuroraリーダーを選択します。
• クロスリージョンDRには、ターゲットリージョンにリードレプリカを作成し、自動スナップショットコピーまたはDMSによる移行を検討します。

ElastiCacheによるキャッシュとキャッシュ無効化

ElastiCacheは、DBの負荷とレイテンシーを削減するためにRedisとMemcachedを提供します。永続性、レプリケーション、データ構造、およびMulti-AZと自動フェイルオーバーによる高可用性が必要な場合はRedisを選択します。シャーディングとマルチスレッド性能が優先されるシンプルな水平方向のキャッシングにはMemcachedを選択します。

主要な設定とパターン：

• レプリカとMulti-AZを備えたRedisクラスターの作成：aws elasticache create-replication-group –replication-group-id rg1 –replication-group-description “rg” –engine redis –num-cache-clusters 3 –automatic-failover-enabled
• Redisでシャードをスケールするにはクラスターモードを有効にして使用します。Memcachedはシャーディングのためにクライアントサイドハッシュが必要です。
• 削除ポリシー：volatile-lru、allkeys-lru、noeviction — メモリが満杯になったときに、期限切れのキーのみを削除するか、任意のキーを削除するか、好みに応じて調整します。
• CacheHitsとCacheMissesを監視してキャッシュヒット率を計算します：ヒット率 = CacheHits / (CacheHits + CacheMisses)。高いヒット率を目指してDBの読み取りを削減します。

キャッシュ無効化戦略：

• キャッシュアサイド：アプリケーションは最初にキャッシュを確認し、ミスした場合はDBを読み取り、キャッシュにデータを投入します。書き込み時にキャッシュを明示的に期限切れにするか削除します。
• ライトスルー/ライトビハインド：キャッシュへの書き込みがDBに伝播します。ライトビハインドはDBへの書き込みをバッチ処理します（複雑さが増します）。
• Time-to-live (TTL)：古くなっても許容されるデータには控えめなTTLを設定します。スキーマ変更や一括無効化のためにキャッシュのバージョニングや無効化キーを組み合わせます。
• 必要に応じて、Redisのpub/subまたはLambdaイベントを使用して、分散無効化のためにアプリケーションインスタンスに通知します。

データベースパラメータグループ、スケーリング、モニタリング

パラメータグループは、エンジン固有の設定 (例: max_connections, innodb_buffer_pool_size) を制御します。RDSはインスタンス用にDBパラメータグループを、Aurora用にDBクラスターパラメータグループを使用します。一部のパラメータの変更には再起動が必要 (pending-rebootを適用) ですが、その他は即座に適用されます。

管理パターン:

• パラメータグループの作成と変更:

undefined

; その後

undefined

• インスタンスクラスのスケーリング:

undefined

(またはメンテナンスウィンドウ中に実行して再起動を回避)。

• ストレージの自動スケーリング: サポートされているエンジンタイプで有効化します。Auroraはストレージを自動的にスケールします。

モニタリングとスケーリングのシグナル:

• CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) と Performance Insights を使用して、遅いSQLや上位の待機イベントを特定します。
• 拡張モニタリングを有効にし、粒度を設定します (例: トラブルシューティング用に1秒)。
• RDS Proxyを使用してコネクションプーリングを管理し、サーバーレスアプリケーションや高並行性アプリケーションでのコネクションストームを削減します。

バックアップ/リストア手順と移行に関する考慮事項

バックアップとリストアは明示的に実行し、テストする必要があります。自動バックアップは保持期間内のPITRを提供します。手動スナップショットは削除されるまで保持され、リージョン間や異なるKMSキーにコピーできます。リストアする際は、リージョンとタイムスタンプを明示的に指定してください。

一般的なリストアコマンド:

• ポイントインタイムへのリストア (RDS):

undefined

/ または

undefined

を指定

• スナップショットのリストア (クロスリージョン): まず

undefined

で宛先リージョンにコピーし、その後リストアします。

移行に関する考慮事項:

• 最小限のダウンタイムでの移行 (異種/同種) にはAWS DMSを使用します。DMSは継続的なレプリケーションをサポートします。ソースエンジンの設定 (MySQLの場合はbinlogが有効になっていること) が正しいことを確認してください。
• 単純なエクスポートには論理移行 (mysqldump, pg_dump) を、大規模なデータセットには物理的なスナップショットリストアを使用します。
• 文字セット、パラメータグループの違い、暗号化されたスナップショット用のKMSキーを検証します。

よくある落とし穴と判断基準

• 間違ったリージョンや時刻にバックアップをリストアする: リストア前に必ず

undefined

と

undefined

を確認します。コピーしたスナップショットをターゲットリージョンで使用し、ステージング環境でリストアをテストします。

• リードレプリカが高可用性を提供すると仮定する: レプリカは非同期であることを忘れないでください。書き込みのHAと同期レプリケーションには、Multi-AZまたはAuroraを使用します。
• キャッシュの無効化を見落とす: TTL、バージョン管理されたキー、またはイベント駆動の無効化を設計します。正確性のために短いTTLのみに依存することは避けてください。
• 自動バックアップや保持期間を適切に有効にしない:

undefined

を0より大きい値に設定し、テストリストアでPITRを検証します。スナップショットコピーのために、KMSキーがターゲットリージョンで利用可能であることを確認します。

• 再起動せずにパラメータグループを変更する:

undefined

を確認します。予期せぬダウンタイムを避けるため、再起動が必要なパラメータについてはメンテナンスウィンドウ中に再起動をスケジュールします。

• 接続管理なしでスケーリングする: RDS Proxyやコネクションプーリングを使用せずにインスタンスクラスを増やすだけでは、コネクションストームは解決しない場合があります。多数の短命な接続を管理するためにプーリングを実装します。

実践的な問題: ユースケースシナリオ

Acme Retail社は、読み取りトラフィックが多く、時折分析処理によるスパイクが発生するMySQL RDSプライマリインスタンスを運用しています。夜間のETL処理中にレプリカラグに直面し、接続のチャーン（頻繁な接続と切断）がCPUスパイクを引き起こしています。

1. アプリケーションのリーダーから分離された分析用の追加リードレプリカグループを有効にし、DRのために別のAZまたはリージョンに配置します。
2. レプリカのモニタリング (ReplicaLagメトリクス) を設定し、ラグやReadLatencyがしきい値を超えたときにリーダーを追加するオートスケーリングロジックを追加します。
3. アプリケーションの前にRDS Proxyをデプロイして接続を多重化し、接続のチャーンを削減します。パラメータグループのmax_connectionsを適切に調整します。
4. 分析ジョブが分析用レプリカを使用するように移行し、ElastiCache Redisを介したキャッシュアサイドパターンのキャッシングを適切なTTLで採用して、繰り返し実行されるクエリを削減します。
5. フェイルオーバーとリストアの手順をテストします。ステージングインスタンスでPITRリストアを実行し、レプリカの昇格手順を検証します。

このアプローチは、読み取りワークロードを分離し、プライマリインスタンスへの接続圧力を軽減し、キャッシングを使用してDBの読み取り量を削減します。リードスケーリング、コネクションプーリング、テスト済みのバックアップ/リストアプロセスを組み合わせることで、可用性と運用上の回復力を維持するというAWSのベストプラクティスに従っています。

← コンピューティングと Auto Scaling · すべてのドメイン · サーバーレスとアプリケーション統合 →

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

Amazonを閲覧 →