AWS DBS勉強
YamahitsujiRDS
パラメータグループ・オプショングループ
パラメータグループ自体の変更、および静的パラメータの変更した場合は手動でインスタンスを再起動する必要がある。（メンテナンスウィンドウではだめ）
動的パラメータの変更の場合は、マネコンの場合は即時変更、CLIとAPIでは即時以外に再起動待ち（ApplyMethod=pending-reboot）を選択できる。
パラメータグループのパラメータを変更すると、そのパラメータグループを使用している全てのインスタンスが変更される。
パラメータグループはコピーを作成することもできる。
Auroraのクラスターパラメータグループとインスタンスパラメータグループはデフォルトではない値が優先される。どちらもデフォルトでない場合はインスタンスパラメータグループが優先される。
オプショングループはすぐに変更できる。（ポート設定を除き、メンテナンスウィンドウ中にすることも可能）
インスタンスの設定を変更する際は、即時変更とメンテナンスウィンドウ時を選べる。（ApplyImmediatelyパラメータ）。ダウンタイムが発生する可能性があるので注意。
バックアップ・スナップショット
バックアップはバックアップウィンドウ中に取得できる。ウィンドウ中に作成されたバックアップ（自動スナップショット）にトランザクションログを含めることで、PITRを実現している。
また、自動スナップショットをコピーすることで、（自動削除されない）手動スナップショットを作成することができる。
スナップショットからインスタンスを作成する際、パラメータグループ・オプショングループ、DBバージョン、インスタンスサイズは選択できる。
Oracle TDEを使用している場合は、復元の際にTDEが有効になっているオプショングループを選択しなければならない。
スナップショットからS3へparquet形式でエクスポート可能。自動・手動のどちらのスナップショットもエクスポートできる。また、DB,スキーマ,テーブル指定なども可能。
PITRが利用できるのは自動バックアップの期間内。期間であれば任意の時間のDBインスタンスを作成可能。
SQL ServerのWindows認証
SQL ServerではADを使って認証を行うことができる。この場合はマネージドADを使用する。オンプレのADを使う場合は信頼関係を確立する。Connectorは利用できない。RDSからADへのアクセス許可（AmazonRDSDirectoryServiceAccessポリシー）が必要。ネットワークも許可（SG）に注意。
リードレプリカ
リードレプリカからリードレプリカ（カスケードレプリカ）を作成することも可能。ただし、ソースDBの自動バックアップが有効になっている必要があり、レプリカの自動バックアップを有効にできるのはMySQL・MariaDB・PostgreSQL（14.1以降）のみ。 RDS for MySQL, MariaDBはレプリカに書き込みを行うことができる。他のDB（Auroraを含む）は書き込みができない。
パフォーマンスインサイト
いつでも変更可能。再起動の必要もなし。 無料枠（データ保持7日間、100万APIリクエスト）もある。
停止
リードレプリカインスタンスおよびレプリカを持つインスタンスは停止できない。停止したインスタンスの設定変更も不可。 セッション数や実行数、上位のクエリなどを検出可能。
ログ
RDSの各DBインスタンスでは、ログを発行できる。DBによるが、エラーログや監査ログはデフォルトで設定される一方、スローログ・一般ログはパラメータグループでの設定が必要。CWLogsに出力するにはRDSへの設定が必要。 ログファイルの保持期間は最大7日。それ以上はCWLogsに出力する必要がある。
ストレージ
ストレージを小さくするには新しいインスタンスの作成→DMSやツールでデータを転送する。スナップショット、リードレプリカは元のインスタンスとおなしストレージになる。
イベント通知
インスタンス、パラメータ、などの作成、変更、削除、フェイルオーバ、失敗などのさまざまなイベントが取得できる。イベント内容はjson形式で、SNSに送られる。
EBS最適化
EBS最適化インスタンスを利用することで、EBSスループットのボトルネックを解消できる。
EBS最適化インスタンスではRDSとEBS間の専用スループットを確保する。
拡張ネットワーキングを利用することで、レイテンシを抑えることも可能。
マルチAZオプション
2022/3のアップデートで、スタンバイかつリード可能なRDSが追加された。
クロスリージョンレプリカ
SQL Server以外では可能。
Aurora
リードレプリカのオートスケールが可能。CW Metricsを使用する。
PostgreSQLの場合はクラスターキャッシュ管理をすることで、フェイルオーバー後のパフォーマンスを改善できる。フェイルオーバーインスタンスのキャッシュをメインインスタンスと同期させることで、キャッシュをフェイルオーバー前と同じにする機能。
バイナリログは不要なので、binlog_format=OFFにすると、復旧時間が短くなる。反対に含んでいると、その分の復旧データが多くなるので、時間がかかる。
Aurora では、DB クラスター内でデータをレプリケートしたり、特定時点への復元 (PITR) を実行したりするために、バイナリログは不要です。
外部レプリケーション (または外部バイナリログストリーミング) にバイナリログが不要な場合は、binlog_format パラメータを OFF に設定して、バイナリログ記録を無効にすることをお勧めします。これにより、復旧時間が短くなります。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html#Aurora.Overview.Reliability
フェイルオーバーの優先順位は以下を参照。
データエクスポート方法はいくつかある。
PostgreSQLは拡張機能を入れて、SQLでデータを整形できる。S3へのアクセスにはネットワーク接続が必要。処理もDB内で行われるので、負荷に注意。CSVなどのフォーマットに指定できるみたい。
スナップショットからのデータエクスポートもできる。データはParquet形式。パフォーマンスには影響なし。手動・自動スナップショットどちらも可能。
つい先日リアルタイムのエクスポートが対応された。直近なので、試験には出ないと思う。こちらはParquet方式。
バックトラックは戻ったり進んだりできるらしいけど、戻った後に変更があった場合はどうなるのだろうか。
例えば、DB クラスターを 3 時間前までバックトラックし、そこから 1 時間後まで戻すことができます。
バックトラックの有効化は作成時のみ。それ以外の時はクラスターのクローンか、スナップショットからの復元で新しくクラスターを作成するしかない。
バックトラックは、バックトラック機能を有効にして作成した DB クラスターでのみ使用できます。バックトラック機能は、新しい DB クラスターの作成時または DB クラスターのスナップショットの復元時に有効化できます。バックトラック機能を有効化して作成された DB クラスターには、バックトラック機能を有効化してクローンの DB クラスターを作成することができます。現在、バックトラック機能を無効にして作成された DB クラスターでバックトラックを実行することはできません。
バックトラックに伴って DB インスタンスがわずかに中断します。バックトラックオペレーションをスタートする前にアプリケーションを停止または一時停止し、新しい読み取り/書き込みリクエストを阻止する必要があります。Aurora は、バックトラックオペレーション時に、データベースを一時停止し、開いている接続をすべて閉じて、コミットされていない読み取りや書き込みをすべて削除します。その後、バックトラックオペレーションが完了するまで待ちます。
クローンはクロスアカウントで作成できる。クロスリージョンは無理。（リージョンごとにストレージを持つのでそれはそう） クローンのバックトラックはクローン作成前までは遡れないが、ソースクラスターはクローン作成前まで遡れる。
データベースのクローンを、その作成時より前の時点までバックトラックすることはできません。ただし、元のデータベースを使用すると、クローン作成時より前の時点までバックトラックできます。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html
SQLによるインスタンスのクラッシュ、レプリカ障害、ディスク障害、ディスク輻輳のテストができる。
Lambda関数をAuroraから呼び出せる。RDSはできない模様。
RDS for PostgreSQLログ
パラメータでログの種類を選択できる。
log_statementにall（全てのログ）, ddl（ddlのみ）, mod（DDL, DMLのみ）, none（なし）を選択する。
暗号化
Auroraでは非暗号化スナップショットから暗号化インスタンスを立ち上げ可能。（RDSはできない）
Aurora MySQL パラレルクエリ
分析クエリに特化したユースケースに利用可能。（PostgreSQLのパラレルクエリとは関係ない）
パフォーマンスインサイト、バックトラック、IAM認証などはサポートしていない。
Serverless
サーバレスもクローン可能。サーバレス・プロビジョンド間のクローンも可能。
RDS on VMware
オンプレのVMware vSphere 環境にRDSをデプロイできる。
CWでの監視やオートヒーリング、バックアップやPITRが利用できる。
YamahitsujiDynamoDB
GSIで読み込みスロットリングが発生した場合、ベーステーブルは影響を受けない。書き込みでスロットリングが発生した場合、ベーステーブルでも書き込みは行えない。
アクセス頻度の高い項目は自動でパーティションが分割される可能性がある。これにより項目に対するスループットが最大1000WCU, 3000RCUになる可能性がある。ただし、LSIがある場合、分割は行われない。
アダプティブキャパシティでは、テーブルにローカルセカンダリインデックスがある場合、テーブルの複数のパーティション間で項目コレクションを分割しません。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-partition-key-design.html
グローバルテーブルはDynamoDBストリームの有効化が必須。
グローバルテーブルでインデックスを追加した場合、別リージョンのテーブルにも作成される。プロビジョンドキャパシティのオートスケーリング設定はリージョンごとに別に可能。
レプリカを先に削除しないと、ソーステーブルは削除できない。
バックアップからの復元時、以下の項目は変更できる。
- グローバルセカンダリインデックス (GSI)
- ローカルセカンダリインデックス (LSI)
- 請求モード
- プロビジョニングされた読み込みおよび書き込みキャパシティ
- 暗号化設定
手動設定が必要な項目は以下
- Auto Scaling ポリシー
- AWS Identity and Access Management (IAM) ポリシー
- Amazon CloudWatch メトリクスおよびアラーム
- タグ
- ストリーム設定
- 有効期限 (TTL) 設定
PITRでも設定可能な項目は同じ。PITRは新しいテーブルを作成する。
グローバルテーブルはリージョンごとにプロビジョンド、オンデマンド別々に設定可能。
また、それぞれのリージョンでPITRを設定可能。
YamahitsujiDAX
読み取りアクションの場合はキャッシュを行う。書き込みの場合はDynamoDBに書き込んだ後、キャッシュにも書き込みを行う。キャッシュはアイテム（GetItem, BatchGetItem）とクエリ（Query, Scan）それぞれがある。クエリキャッシュはパラメータごとに保存される。
クエリキャッシュは項目キャッシュには影響しない。
TTLは無効にできる。（その場合は古いものを削除するだけ。）
強い整合性読み込みはそのままDynamoDBにクエリを投げる。結果をDAXはキャッシュしない。
YamahitsujiRedshift
スーパーユーザだけCRITICAL優先度のキューを利用できる。
追加の優先度 CRITICAL は、HIGHEST よりも優先度が高く、スーパーユーザーが利用できます。
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/query-priority.html
自動スナップショットはデフォルトでは8時間、データ変更5GBごとの早い方ごとに作成される。
RA3では自動スナップショットは無効にできない。cron式で時間は変更可能。
手動・自動スナップショットは共に別リージョンに自動コピー可能。自動スナップショットはコピー先リージョンでの保持期間を設定できる。
コピー先リージョンでKMSキーを作成し、コピーGrantの名前を設定する。コピーGrant名はアカウント&リージョンで一意である必要がある。ソースリージョンでクロスリージョンコピーを有効にし、ターゲットリージョンで作成したGrantを指定する。
Redshift Spectrumでは認証にはIAMロールを使用する。バケットポリシーでVPCエンドポイント以外をDENYするようにしてはいけない。
COPYコマンドはクロスリージョン、クロスアカウントのS3にアクセス可能。Spectrumはクロスアカウントハ可能だが、同一リージョンでなければならない。
Amazon Redshift クラスターと Amazon S3 バケットは、同じ AWS リージョンに存在する必要があります。
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c-using-spectrum.html
YamahitsujiElastiCache
Redis
スナップショットを.rdbファイルとしてS3にエクスポートできる。S3はElastiCacheと同じリージョンでなければならない。 リードレプリカからもバックアップの取得が可能。パフォーマンス影響が少ない。 マルチAZの有効化をすることで、AZ障害時に別AZのレプリカが昇格する。 スローログとエンジンログをFirehoseまたはCWLogsに配信可能。 クラスターモードは後から変更できない。
Memocached
ノードの追加、削除時に再マップが走る。一時的にキャッシュミスが増える可能性あり。
ログはなさそう。
YamahitsujiNeptune
VPC内に作成する。プロビジョンド型。サーバレスは2022/10にGA。
S3にからデータの一括ロードをすることができる。IAM権限およびネットワークが必要。
RedshiftのCOPYコマンドに近い感覚。
IAM認証により、接続ユーザを制限することができる。
DynamoDBみたいにストリームが利用可能。Kinesisではなくて良い。
監査ログはCWlogsに転送可能。パラメータグループneptune_enable_audit_logでも有効化する必要あり。
PITR、スナップショットもあり。
YamahitsujiOpenSearch
ログは以下の4つ。
- エラーログ
- 検索スローログ
- インデックス作成スローログ
- 監査ログ
デフォルトでは無効。
リザーブドインスタンスがある。
自動スナップショットは最大14日で、無料で保存できる。
YamahitsujiTimestream
マネージド、サーバレス。
自動的にロールアップ、保持期間、ティアリング、圧縮ができる。
料金はDynamoDBに近い感じ。
オンデマンドのクエリキャパシティ。
ストレージはインメモリ→マグネティック→削除といったライフサイクルを設定する。
データベースに複数のテーブルを持ち、テーブルは複数のレコードを持つ。
レコードはタイムスタンプ、ディメンジョン、メジャーから構成される。
ディメンジョンは文字列であり、イミュータブル。128個まで指定できる。マスターデータなどを入れる。
メジャーは測定値のキーバリュー。最大1024まで。イミュータブル。同じ列名で違うからのフィールドを作成できる。
YamahitsujiQLDB
台帳DB。
ACIDトランザクションをサポート。
PartiQLを使用。
Amazon IONフォーマットを使用してデータを表現。
台帳は複数テーブルを持っている。テーブルはブロックになっている。
ジャーナルはログ。ドキュメントはレコードに該当。
ビューは以下3種類。
- ユーザビュー：最新ドキュメントのデータ
- コミットビュー：ユーザービュー＋ドキュメントのメタデータ。
_ql_committed_VehicleRegistrationのように、_ql_committed_がテーブルのプレフィックスにつく
SELECT * FROM _ql_committed_VehicleRegistration AS r
WHERE r.data.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
- ヒストリービュー：過去全ドキュメント。
history関数を使う。
SELECT * FROM history( table_name | 'table_id' [, `start-time` [, `end-time` ] ] ) AS h
[ WHERE h.metadata.id = 'id' ]
ハッシュを使ってデータ検証を行うことができる。
バックアップ、PITRはサポートされていない。
ジャーナルをS3にエクスポートすることができる。エクスポートジョブを作成する。フォーマットはIon,JSON。ジョブにロールを付与する必要がある。同時実行できるジョブは2つまで。
Kinesisにストリームできる。重複の可能性あり。順序保証はない。
CRRは対応していない。
KMSで暗号化が必須。転送中もTLSを使用。
YamahitsujiKeyspaces
PITRあり。
DDLはCloudTrailでロギングできる。
TTLでレコード作成から削除までの時間を決められる。
VPC外で動く。
CQL（Cassandra query language）エディタをコンソールから使用できる。
既存Cassandraからのマイグレーションはcqlshコマンドを使ってCSVファイルに落とし、Keyspacesにインポートする。
料金体系はDynamoDBとほぼ同じ。
権限もDynamoDBと同様にIAM。
読み取りの整合性は3種類。ONE、LOCAL_ONE、LOCAL_QUORUM
ONEとLOCAL_ONEは結果整合性。4KBの読み取り1回につき0.5RCU。
LOCAL_QUORUMは強い整合性。4KBの読み取り1回につき1RCU。
書き込み整合性はLOCAL_QUORUMのみ。1KBの書き込みにつき、1WCU。
テーブルごとにキャパシティモード（プロビジョンドorオンデマンド）が選択できる。
YamahitsujiDMS
DMSタスク評価レポートではタスク設定をもとに、タスク実行前に問題が発生しそうかどうか評価できる。サポートされていないデータ型の検出も可能。S3バケットに事前評価の結果を保存する設定が必要。
マイグレーションは並列実行されるため、外部キー制約を先に入れておくとエラーが発生する可能性がある。
マルチAZにより、フェイルオーバがサポートされている。
テーブルだけでなく、ビュー等も可能。
selectionルールとtrasformationルール、table-settingsルールをそれぞれ設定し、スキーマやテーブル、行ごとなどに変換、選択を行うことができる。
大きいテーブルは複数タスクを作成し、行フィルタリングで複数タスクでマイグレーションすることができる。
LOBを移行する場合、LOBデータ以外を先にマイグレートしてから、LOBをマイグレート、行を更新する。
LOBはオプションで移行しない、全て移行する（チャンクサイズを指定）、特定サイズに切り捨て、を選択できる。移行には十分な量のメモリが必要。全て移行の場合は複数タスクに分ける必要もある。インラインLOBモードでは最大LOBサイズを指定し、それより小さい場合はインラインで転送、大き場合はフルLOBモードを使用して移行してくるれる。
SNSへのイベント通知、CWによるモンタリング、ログ記録ができる。
データが正常に移行されたかどうか、検証を行うことができる。検証はデータの移行後に自動的に開始される。バリデーション設定はタスク作成時でも、作成後でも変更可能。内部的にはソースとターゲットテーブルにクエリを打って比較している。プライマリキーまたは一意のインデックスが必要。SCT exstractorsは検証をサポートしていない。テーブル統計画面からテーブルごとに再検証も可能。
バリデーションエラーはダーゲットエンドポイントのテーブルawsdms_validation_failures_v1に書き込まれる。
コントロールテーブルでタスクに関する情報を見ることができる。
DMSはKMSキーでの暗号化が必須。
ソースとタスク、ターゲットとタスクの間でSSL接続を設定できる。DMSに証明書をアップロードし、エンドポイントの作成時に指定する。
パフォーマンス向上のために、バックアップとトランザクションログを事前にオフにしておくと良い。
Kinesis、ESもターゲットとして設定可能。
ファンアウト型にもできる。
SCT
移行評価レポートを作成することで、事前に移行の複雑さを評価できる。
レポートはCSV、PDFとしてもエクスポートできる。
大きなデータ変換が必要な場合はSCT Extractorsを利用できる。SCTと統合されている拡張機能。DMSタスクを作成したりSnowballを利用して、並行にデータを変換、移行する。
Extractorsは自前のサーバにインストールする。
ログをCWLogsに出力できる。ログレベルを選択でき、LOGGER_SEVERITY_DETAILED_DEBUGが一番詳細なログ。
Yamahitsujiマイグレーション
MySQL
少量データにはmysqldump/mysqlimportユーティリティ。
次にダンプファイルをS3に保存。
ニアリアルタイムにはbinlogを使用。
PostgreSQL
少量データにはpg_dump / pg_restore。
それ以上はaws_s3拡張機能を使ってS3からロード。
RDS間ではpg_transport拡張機能を利用して、リアルタイムストリーミングが可能。
Oracle
小さいデータはOracle SQL Developerを使ってデータベースをインポート。
数百MB以上はOracle Data Pumpを使用。S3を統合していて、Data PumpファイルをDBインスタンスにダウンロードできる。
DMSではダウンタイムゼロで、他のDBからも移行ができる。
SQL Server
ネイティブバックアップファイル.bakを利用してS3から復元。
Microsoft SQL Server Management Studioも利用可能。GUIでの操作が可能。
Aurora
RDSスナップショットから復元可能。
同種RDSからはスナップショット+ Mysql binlog。
Auroraレプリカを作成し、昇格。
サーバレスへはRDS→Aurora Provisioned→Serverlessの段階が必要。
Redis
オフラインはバックアップ（.RDBファイル）を使用。S3にアップロードし、そのファイルからElastiCacheを作成。
オンラインはエンドポイントを使用。Redis on EC2への書き込みがElastiCacheに伝播する。ソースのRedisでは、Redis AUTHの無効、protected-modeの無効、bing設定が含まれいる場合はElastiCacheへのリクエストを許可する必要あり。ターゲットのRedisではクラスタモードの無効、マルチAZの有効、転送時・保管時の暗号化を無効にしなければならない。メモリが足りない場合は失敗する。
DocumentDB
mongodump / mongorestoreでバイナリ形式のダンプファイルでマイグレーションを行う。
mongoexport / mongoimportはJSONやCSV形式でマイグレーションが可能。
パフォーマンス的にはダンプファイルの方が良い。
DMSも利用可能。
YamahitsujiDocumentDB
ログはパラメータグループaudit_logsで有効化する必要がある。CWLogsに送信する。デフォルトでは何も発行されない。内容はDML,DDL。
DocumentDBはVPC内で実行する。
YamahitsujiQLDB
ログは現状のところ存在しない。
YamahitsujiCFn
CFnスタック全体、リソース、アウトプット、パラメータ単位でConditonを設定可能。
AWS::RDS::DBInstance
DeleteAutomatedBackupsはインスタンス削除時にすぐに自動バックアップを削除する設定。デフォルトは削除。Auroraの場合は適用されず、クラスターが削除されたときに全削除される。
DBClusterIdentifierは所属するAuroraクラスターを指定する。（必須でない）
DB更新の際、自動バックアップは削除時に削除されるが、手動スナップショットは残る。
スタックポリシーでリソースのアップデートを阻止することも可能。
DBのアップデート前にスナップショットの取得を推奨。DBSnapshotIdentifierでスナップショットからDBを作成可能。DBSnapshotIdentifierを指定した場合は、今後同じものを指定し続ける必要がある。（更新を行なっても、データはスナップショット時点に戻らない）
Deletion Policy
スタックの削除保護をしても、アップデートは可能。
DeletionポリシーでDelete, Retain, Snapshotが指定可能。Auroraクラスターでない（DBClusterIdentifierの指定なし）の場合、デフォルトはSnapshot。Auroraクラスターの場合（DBClusterIdentifierの指定あり）インスタンスはデフォルトはDelete。ただし、DBCluserリソースの方でSnapshotになっている。
ダイナミックパラメータ
SSMまたはSecretsManagerの値を参照できる。
以下のような形式。
'{{resolve:ssm:parameter-name:version}}''{{resolve:ssm-secure:parameter-name:version}}'{{resolve:secretsmanager:secret-id:secret-string:json-key:version-stage:version-id}}
パラメータ側を変更した場合、Cloudformation側では更新されない。その場合はバージョン指定する必要がある。
RDS + Secrets Manager
AWS::SecretsManager::SecretTargetAttachmentを使用することで、DBとSecrets Managerをリンクできる。パラメータの自動更新を行う場合には設定が必須。 AWS::SecretsManager::RotationScheduleでローテーションを設定する。これはLamda関数を作成する。アタッチメントの後に作成。
YamahitsujiVPC
VPCフローログはVPC、サブネット、ENI単位で指定可能。
配信先はS3またはCWLogs。
YamahitsujiAmazon CloudWatch Application Insights
サーバのログ、メトリクスを使用して、アプリケーションを監視する。問題が検出されると、EevntBridgeに発行可能。
SQL Serverや.NET、DynamoDBをサポート。