Amazon SAP-C02: データベースとアナリティクス — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

トランザクションデータベース、スケーリングパターン、およびキャッシング

Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server)、Amazon Aurora、Amazon DynamoDBの選択は、ワークロードのプロファイルから始まります。厳格なリレーショナルスキーマと複雑なトランザクションはRDS/Auroraが適しており、大規模なスケール、1桁ミリ秒のルックアップ、柔軟なスキーマはDynamoDBが適しています。Auroraは、分散ストレージによる高スループット、レプリカのオートスケーリング、高速なフェイルオーバー、クロスリージョン読み取りのためのGlobal Database、そしてより低レイテンシーのディザスタリカバリを提供します。RDS Multi-AZは可用性のための同期レプリケーションを提供しますが、読み取りスケーリングは提供しません。リードレプリカ（RDS/Aurora）は読み取り負荷の高いワークロードを処理します。キーバリューキャッシングとマイクロ秒レベルのレイテンシーのためには、ElastiCache (RedisまたはMemcached)がDBの負荷を軽減します。MemoryDB for Redisは、データの高可用性と回復性が必須の場合に、耐久性とRedis互換の永続性を追加します。よくある落とし穴には、接続数の上限（MySQLのmax connections）の過小評価、コネクションプーリングを使用しないこと（Lambda/コンテナが多数の接続を生成するケース）、不適切なキー設計によるDynamoDBのホットパーティション、キャッシュのエビクション/設計を軽視し、データの陳腐化を招くことなどが含まれます。意思決定のトレードオフは、多くの場合、コストとパフォーマンスおよび回復力の比較が中心となります。プロビジョニングされたAuroraや大規模なRDSインスタンスはコストがかかりますが、レイテンシーを削減し、トランザクションを簡素化します。一方、オンデマンドまたはオートスケーリングを使用するDynamoDBは運用を削減できますが、慎重なスキーマ設計とキャパシティ計画が必要です。暗号化、自動バックアップ、PITR、クロスリージョンレプリケーションのパターンは、RPO/RTOに従って選択する必要があります。

データレイク、ETL、および分析クエリエンジン

S3は、標準的で耐久性のあるデータレイクです。コスト効率の良いクエリを実現するために、パーティショニング、カラムナフォーマット（Parquet/ORC）、圧縮、コンパクションを中心に設計します。AWS GlueとAWS Glue Data Catalogは、サーバーレスETL、スキーマ検出、およびカタログ化を提供します。Lake Formationは、ガバナンスの効いたデータレイクのために、一元的なアクセスコントロール、きめ細かな権限設定、およびクロスアカウント共有を追加します。インタラクティブな分析には、Amazon AthenaがS3データを直接クエリします（サーバーレス、クエリごとの支払い）。一方、Amazon Redshift（RA3/Icebergサポート）は、複雑なBIや結合（join）のために、高性能なマネージドMPPウェアハウスを提供します。Redshift Spectrumを使用すると、すべてを取り込むことなくRedshiftからS3データをクエリできます。Kinesis Data Firehoseは、ストリーミングイベントをS3やRedshiftに取り込むためのマネージドなインジェストパスです。アーキテクトが陥りがちな罠には、Athena/Redshiftのオーバーヘッドを増大させる、過度に多くの小さなファイル、スキュー（偏り）を生じさせる、不適切なパーティションキーの選択、コンパクションやカラムナフォーマットへの変換を怠ることなどが含まれます。トレードオフはレイテンシーとコストの比較です。Athenaはアドホッククエリに対して運用コストが低い一方、Redshiftはより高いプロビジョニングコストで、より高い持続的パフォーマンスを提供します。Glue/Lake Formationによるデータガバナンスとリネージ（来歴）は、コンプライアンスと複数チームによる所有権のために不可欠です。

ストリーミング、リアルタイム処理、および検索

リアルタイムの取り込みと処理には、Kinesis Data Streams（シャードベースのスループットと順序保証）、Kinesis Data Firehose（シンクへのマネージド配信）、Kinesis Data Analytics（SQL/Apache Flink処理）、またはKafka互換のニーズに対応するAmazon MSKを使用します。AWSネイティブのシンプルなサーバーレス統合にはKinesisを選択し、クライアントがKafkaエコシステムのツールに依存している場合はMSKを選択します。at-least-once（少なくとも1回）の配信セマンティクス、シャード数の上限、コンシューマーの並列処理、および適切なシャード数のプロビジョニングは、一般的な運用上の落とし穴です。下流での高速な検索と可観測性のためには、Amazon OpenSearch Serviceがインデックス作成、ニアリアルタイム検索、および組み込みのKibanaダッシュボードを提供します。インデックスのライフサイクル管理とウォーム/コールドティアは、古いデータのコストを削減します。Kinesis + LambdaまたはKinesis + KDAを使用して、OpenSearchやS3に永続化する前にイベントをエンリッチ/変換します。リトライやリプレイは重複を引き起こすため、コンシューマーには冪等性（idempotency）と重複排除を設計に組み込みます。決定基準はスループットとレイテンシーのバランスです。多数のシャードを持つKinesisは高スループットをサポートしますが、コストと管理が増加します。一方、Firehoseはコンシューマーの負担を軽減しますが、提供される変換の柔軟性は低くなります。

移行、レプリケーション、ガバナンス、および運用上の回復性

Database Migration Service (AWS DMS) と Schema Conversion Tool (SCT) は、同種および異種間の移行における主要な移行ツールであり、継続的な変更データキャプチャ (CDC) を可能にします。移行パターンには、リホスト (リフト＆シフト)、リプラットフォーム (例: Aurora への移行)、および必要に応じた DynamoDB やサーバーレスへのリファクタリングが含まれます。DMS は、移行前後の検証、並列テーブルコピー、および慎重な LOB/LOBLOB の取り扱いと共に使用します。クロスアカウントおよびクロスリージョンでのレプリケーションには、KMS キーへのアクセス、VPC ピアリングまたは Transit Gateway、およびネットワーク帯域幅の計画が必要です。リージョン間で低レイテンシーの読み取りが必要な場合は、Global Databases とリードレプリカが代替手段となります。ガバナンスとセキュリティには、データ共有のための Lake Formation、IAM の最小権限、S3 および RDS スナップショットのリソースポリシー、そしてパブリックな egress を回避するための VPC エンドポイント/PrivateLink を含める必要があります。運用上の落とし穴には、不十分なモニタリング (レプリカラグの見逃し)、フェイルオーバー/ランブックのテスト不足、および一括転送中の隠れた egress コストなどがあります。バックアップ、PITR 戦略、および自動リカバリは、RTO/RPO のトレードオフに関わってきます。可用性のためのレプリケーションと、長期保存およびコンプライアンスのための定期的なバックアップを組み合わせます。

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

シナリオ: Acme Retail は、us-east-1 と europe-west-1 に本番ワークロードを持つマルチアカウントの AWS Organization で e コマースプラットフォームを運営しています。同社はクリックストリームとトランザクションイベントを S3 に保存しており、最小限のダウンタイムで AWS に移行する必要があるオンプレミスの OLTP DB を運用しています。

課題: OLTP データベースを、可用性が高く、クロスリージョンで読み取りがスケーラブルなターゲットに移行すると同時に、リアルタイムの取り込みとクエリ機能を備えた、ガバナンスの効いた分析レイクを S3 上に構築する。

推奨アプローチ:

AWS DMS と SCT を使用してスキーマを変換し、オンプレミス DB から us-east-1 の Amazon Aurora (Global Database) への継続的な CDC を設定します。さらに、europe-west-1 に Aurora リードレプリカを配置します。
Amazon Kinesis Data Streams と Firehose を介してクリックストリームとトランザクションイベントを取り込みます。生のイベントをバッファリングし、日付とリージョンでパーティション分割された Parquet 形式で S3 に配信します。
AWS Glue で S3 データをカタログ化し、Lake Formation を介してアクセス制御を適用し、Glue ジョブ (または Glue Studio) で ETL を実行してキュレーションされたデータセットを生成します。これらを Amazon Athena と Redshift Spectrum を介してアナリストに公開します。
ホットな製品データやセッションデータの高読み取りキャッシュのために ElastiCache (Redis) を追加します。CloudWatch でエンドツーエンドのモニタリングを実装し、Aurora で拡張モニタリングを有効にし、ランブックでフェイルオーバーを検証します。

論理的根拠: このアプローチは、DMS CDC を使用してダウンタイムを最小限に抑え、Aurora Global Database を介して低レイテンシーのグローバルな読み取りを提供し、分析のアジリティ向上のためにガバナンスの効いた S3 データレイクを確立します。さらに、エンタープライズの回復性とパフォーマンスのベストプラクティスに沿って、キャッシングと分離されたストリーミング取り込みにより OLTP システムへの負荷を軽減します。

← ストレージとデータ管理 · すべてのドメイン · 移行とモダナイゼーション →

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