Jayendra’s Blog
この記事は自己学習用に「AWS Certification – Database Services – Cheat Sheet（Jayendra’s Blogより）」を日本語に訳した記事です。
RDS
- リレーショナルデータベースサービスを提供します。
- MySQL、MariaDB、PostgresSQL、Oracle,Microsoft SQL Server、および新しい MySQL 互換の Amazon Aurora DB エンジンをサポート。
- マネージサービスであるため、シェル (ルート ssh) アクセスは提供されません。
- バックアップ、ソフトウェア・パッチ、自動障害検出、リカバリを管理。
- 開始された手動バックアップとスナップショットの使用をサポート。
- データベーストランザクションログによる毎日の自動バックアップにより、データベース使用量の最後の5分までの時点でのリカバリが可能。
- スナップショットは、DB インスタンスのユーザーが開始するストレージ・ボリューム・スナップショットであり、独立した RDS インスタンスとしてリストア可能な個々のデータベースだけでなく、DB インスタンス全体をバックアップします。
- KMS を使用した REST での暗号化と、SSL エンドポイントを使用した転送中の暗号化のサポート。
- 暗号化されたデータベース。
- ログ、スナップショット、バックアップ、読み取りレプリカもすべて暗号化されています。
- リージョン間でクロスリージョンのレプリカとスナップショットが機能しない。
- Multi-AZ デプロイ
- 高可用性と自動フェイルオーバーのサポートを提供し、スケーリングソリューションではありません。
- 同期スタンバイレプリカを別の AZ で管理します。
- トランザクションの成功は、プライマリとスタンバイ DB の両方でコミットが成功した場合にのみ返されます。
- Oracle, PostgreSQL, MySQL、および MariaDB インスタンスは Amazon テクノロジを使用しますが、SQL Server DB インスタンスは SQL Server ミラーリングを使用します。
- スナップショットとバックアップはスタンバイから取得され、I/O のフリーズを排除。
- 自動フェイルオーバー時に、そのシームレスおよび RDS はスタンバイ・インスタンスに切り替わり、DNS レコードを更新してスタンバイ・ポイントにします。
- フェイルオーバー・オプションを使用して再起動を強制できます。
- リードレプリカ
- PostgreSQL、 MySQL 、および Maria DB エンジンの組み込みレプリケーション機能を使用して、個別の読み取り専用インスタンスを作成します。
- 更新は読み取りレプリカに非同期的にコピーされ、データが古い可能性があります。
- アプリケーションのスケーリングと読み取り専用負荷の軽減に役立ちます。
- 自動バックアップが有効になっている。
- ソース DB インスタンス内のすべてのデータベースをレプリケートします。
- 災害復旧のためには、本格的なデータベースに昇格することができます。
- 災害復旧、移行、リージョン間の低レイテンシのために、MySQL、PostgreSQL、MariaDB の別のリージョンで作成できます。
- RDS は、基になるデータベースのすべての機能をサポートしておらず、必要に応じて EC インスタンスでデータベースインスタンスを起動することができます。
- Oracle RMAN（Recovery Manager）は、EC2インスタンスで実行する場合、Oraclesのバックアップおよびリカバリに使用できます。
Dynamo DB
- 完全に管理された NoSQL データベースサービス。
- AWS リージョン内の3つの施設にわたってデータを同期的にレプリケートし、高可用性とデータの持続性を実現。
- SSD 上で排他的に動作し、高い I/O パフォーマンスを実現。
- プロビジョニングされたテーブルの読み取りと書き込みを提供。
- データを自動的にパーティション化、再割当て、再パーティション化し、追加のサーバー容量をデータまたはスループットの変更としてプロビジョニングします。
- 読み取り操作中に、最終的に一貫した (by Default)、または厳密に一貫性のあるオプションを指定します。
- テーブル内のデータに効率的にアクセスするための主キー属性のインデックスを作成および管理します。
- セカンダリインデックスをサポート。
- パフォーマンスに影響を与えることなく、属性を他の主キー属性にクエリできます。
- スパースオブジェクトとして自動的に維持される。
- ローカル vs グローバルセカンダリインデックス
- 共有パーティションキー + 異なるソートキー vs 別のパーティション + ソートキー
- 限定検索 vs すべてのパーティション間でパーティション
- 一意の属性 vs 非一意の属性
- ベーステーブル vs 独立した個別のインデックスとのリンク
- ベーステーブルの作成時にのみ作成 vs 後で作成できます。
- 作成後に削除することはできません vs 削除できる。
- ベーステーブルのプロビジョニングされたスループット容量 vs 独立したスループットの消費。
- アイテムすべての属性を返す vs 投影された属性のみ。
- 最終的にまたは強く vs 最終的に一貫した読み取りのみ。
- サイズは、パーティションごとに10Gb 制限 vs 無制限
- Kinesisi を利用した DynamoDB ストリームを使用したクロスリージョンレプリケーションをサポートし、時間順のアイテムレベルの変更を提供し、RPO の低減、RTO の低減に役立てることができます。
- EMR を使用したデータパイプラインジョブは、より高い RPO、RTO 要件の低い災害復旧に利用できます。
- アイテムレベルの更新に基づいてカスタムアクションまたは通知の実行を許可するトリガーをサポートします。
ElastiCache
- Memcached または Redis プロトコルに準拠したキャッシュクラスターを展開および実行するためのインメモリキャッシュを提供するマネージ Web サービス。
- Redis との ElastiCache
- RDS と同様に、Multi-AZ、リードレプリカ、スナップショットをサポート。
- Redis の非同期レプリケーションテクノロジを使用して、読み取りレプリカが同じリージョン内で AZ 全体で作成される。
- Multi-AZ は、スタンバイがないので RDS とは異なりますが、プライマリがダウンした場合、リードレプリカがプライマリとしてプロモートされます。
- RDS がサポートするため、リードレプリカはリージョン間をまたがることはできません。
- スケールアウトすることはできません。スケールアップしてもスケールダウンできない場合。
- バックアップ/リストア用のスナップショットを許可。
- AOF は、復旧シナリオで有効にして、ノードに障害が発生した場合やサービスがクラッシュした場合にデータを回復することができます。しかし、それは、基礎となるハードウェアが失敗した場合には役立ちません
- フォールトトレランスへのより良いアプローチとして Redis Multi-AZ を有効にする。
- ElastiCache と Memcached
- ノードを追加することでサイズを拡大し、スケールアウトすることでスケールアップできます。
- ノードは同じリージョン内の複数の AZ にまたがることができます。
- キャッシュされたデータはノード全体に分散し、ノード障害によってクラスタからデータが失われることがあります。
- 自動検出をサポート。
- すべてのノードは同種で、同じインスタンスタイプである必要があります。
- ElastiCache Redis vs Memcached
- 複雑なデータオブジェクト vs 単純なキー値ストレージ
- 永続的 vs 非永続的な、純粋なキャッシュ
- 自動フェイルオーバーと Multi-AZ vs Multi-AZ はサポートされていません
- リードレプリカを使用したスケーリング vs 複数ノードの使用
- バックアップと復元がサポート vs サポートされていない
- 状態管理を使用して、Web アプリケーションをステートレスに保つことができます。
Redshift
- 完全に管理され、高速かつパワフルなペタバイト規模のデータ・ウェアハウス・サービス。
- レプリケーションと連続バックアップを使用して可用性を高め、データの耐久性を向上させ、ノードとコンポーネントの障害から自動的に回復できる。
- 複数の物理リソースにまたがるクエリを分散 & 並列化することにより、大規模な並列処理 (MPP) を提供。
- カラムナデータストレージは、クエリのパフォーマンスを向上させ、事前圧縮技術を可能。
- AZ が Redshift クラスターをサポートしている場合にのみ、シングル AZ 展開をサポートし、同じ AZ 内でノードを使用できます。
- スポットインスタンスはオプションではありません。