記事の目的
AWS Database Specialty で
自分がやってて試験に出そうだが、
間違えやすい、間違えた箇所をまとめました。
パッと知らない単語を探す程度にご活用ください。
あとは今はなき Database Specialty の思い出を振り返るくらいでも。
猛スピードで記載していたので、誤記はご愛嬌。
何かの役には立つはず…!
CloudTrail
DynamoDB のコントロールプレーンとデータプレーンを扱える。
コントロールプレーン
コントロールプレーンのオペレーションでは、DynamoDB テーブルを作成および管理できる
また、インデックス、ストリーム、およびテーブルに依存する他のオブジェクトを操作できる
CreateTable– 新しいテーブルを作成する。オプションで、1 つ以上のセカンダリインデックスを作成し、テーブルに対して DynamoDB Streams を有効にできる。DescribeTable– プライマリキーのスキーマ、スループット設定、インデックス情報など、テーブルに関する情報を返す。ListTables– リストのすべてのテーブルの名前を返す。UpdateTable– テーブルまたはそのインデックスの設定を変更、テーブルの新しいインデックスを作成または削除、またはテーブルの DynamoDB Streams 設定を変更する。DeleteTable– テーブルとそのすべての依存オブジェクトを DynamoDB から削除する。
Secrets Manager
RDS の Key の自動ローテーション機能なども提供する
Lambda がアクセスするときは Secrets Manager API を使用することで取得可能
ユーザー名やパスワード等
DevOps 関連
CloudFormation
CloudFormation スタックポリシーでスタック更新を防止する Delete Retain などがある。
Mappings
キーと名前付きの値が対応付けられたグループ化機能
UpdatePolicy
- UpdatePolicy
Update の際のポリシーで - AutoScalingReplacingUpdate
- AutoScalingRollingUpdate
- AutoScalingScheduledAction
がある
サポートしているのは以下
– AWS::AutoScaling::AutoScalingGroup
– AWS::ElastiCache::ReplicationGroup
– AWS::ElastiCache::Domain
– AWS::AppStream::Fleet
– AWS::Lambda::Alias
– AWS::OpenSearchService::Domain
- Deletion Protection
Deletion Protection を True に設定する
→Deletion Protection を True に設定すると、インスタンスが削除されるのを防ぐことができる
DeletionProtection
DB インスタンスで削除保護が有効になっているかどうかを示す値。削除保護が有効になっている 場合、データベースを削除することはできない。デフォルトでは、削除保護は無効になっている。
DeleteAutomatedBackups を False に設定すると、バックアップが保持され、データの損失を防ぐことができる
以下3つのポリシーがある
- CreationPolicy
- DeletionPolicy
- UpdatePolicy
Termination Protection ポリシー
スタック全体に適用されるポリシー
DBEngineVersion プロパティはない
EngineVersion プロパティはある
DB関連
DynamoDB
オンデマンドキャパシティーモード
オンデマンドキャパシティーモードの DynamoDB は予測不能なアクセスパターンに対応するもの
ホリデーシーズン中の予想される負荷増に最も低いコストで対応する場合は AutoScaling が望ましい
DynamoDB Accelerator (DAX)
キャッシュを使用できるので、繰り返しでの読み取りを行う場合はこれが有効
テーブルのスループット最適化モード
なんてない
DynamoDB のオンデマンドモード
では、使用量に基づいて自動的にスケールするため、別途 Auto Scaling を設定することはできない
DAX が結果整合性のある読み込みにのみ対応し、
強力な整合性のある読み込みを要求するリクエストは DAX を経由して直接 DynamoDB に渡される
これは queryCacheMiss に繋がる
DAX のアクセスコントロール
DAX はユーザーレベルの分離や属性レベルのアクセス制御をサポートしていない。
例えば従業員ロールの人の見れないものを作りたい場合は、
従業員 IAM ポリシーを更新し、DAX ではなく DynamoDB のみにアクセスできるようにする必要がある
バックアップ
DynamoDB のバックアップと復元は
IAM ポリシーと有効期限 「ポリシーと有効期限 (TTL) 」の設定は復元されない
IAM ポリシーと TTL は復元されず、グローバルセカンダリインデックスなどは復元される
セカンダリインデックス
ローカルセカンダリインデックスは、テーブルの作成と同時に作成される。ローカルセカンダリインデックスを既存のテーブルに追加したり、既存のローカルセカンダリインデックスを削除したりすることはできない
ローカルセカンダリインデックス
を持つテーブルの最大サイズ制限は10GB と決められている。この制限は、テーブル内の一つのパーティションに対して適用され、全体のテーブル容量ではない点を明確に理解することが重要
グローバルセカンダリインデックスの使い方
投影属性を絞ることで効率と費用を抑える
ユーザー ID をパーティションキーとして使用し、ディメンション属性をソートキーとして使用するグローバルセカンダリインデックス (GSI) は、投影された2つの属性で目的を果たすことができ、レポートジェネレータは、テーブルの代わりにインデックスをクエリするように変更する必要がある
グローバルセカンダリインデックスは強力な生合成がない
またローカルセカンダリインデックスは作成後にはつけられない
DynamoDB グローバルテーブル
DynamoDB Streams を有効にする必要がある
各リージョンにレプリカテーブルを作る方法
グローバルテーブルの DynamoDB Streams を有効にして、
各リージョンにレプリカテーブルを作る
そして各レプリカテーブルの PITR を設定する
Redshift
ユーザー名 フィルタリング Redshift
ユーザー名でフィルタリングしたビューを作れるらしい、でも検索してもあまり情報出なかった
ChatGPT に聞くと
アプリケーション側でユーザー名を取得し、それを使用して Redshift に対してクエリを実行することで、ログインしたユーザーに関連するレコードのみを表示することができる。
とのこと。
できはするっぽい
ConsistentRead
オペレーションを強力な整合性のある読み込みで行うために必要な ConsistentRead
拡張されたルーティング
DB のエンドポイントと組み合わせて使用すると、Redshift はインターネット経由での通信をしなくなる
Generate-db-auth-token
認証を持つユーザーがこの API を実行することで一次パスワードを取得できる
RDS
Performance Insights で MySQL をチューニングする
データベースに絞り込んだチェックも可能
events_statements_summary_by_digest テーブル
events_statements_summary_by_digest テーブルが使用されており、テーブルがいっぱいになると問題が発生する可能性がある（performance insights unable new queryなどと出る）
RDS イベント通知
RDS イベントサブスクリプションでは、選択した RDS イベントのみに通知を送信できるようになっている。通知は SNS に送信される
RDS イベントサブスクリプションは RDS の起動や停止を検知できる
しかし特定のデータがデータベースに挿入されたときの通知という、要件を満たすことはできない
イベントサブスクリプションは、インフラの検知はできるが、中身の検知はできない
自動バックアップ
自動で作られるが、最大保存期間は35日
パラメータグループ
DB インスタンスの再起動が新しいパラメータ グループの適用タイミングである
MySQL Stored プロシージャ
ざっくり言うと DBMS(ここではRDBMSのこと)内で動作するプログラムのこと。
SQL 文を連続で実行したり、変数・条件分岐・繰り返し構文を使っていわゆるプログラムちっくな処理をDBで実現することができる仕組み
AWS 上であれば Insert を検知して、Lambda を実行することも可能
DBInstanceClassMemory
ポイントインタイムリカバリ、バックトラックの違い
ポイントインタイムリカバリは、自動バックアップ保持期間内の特定時点の DB クラスターを別のクラスターとして再作成できる機能
バックトラックは、上記2つの機能とは異なり新しいクラスターを作成するのではなく、対象のクラスターそのものに対して「巻き戻し」を行う機能
DB のマスターパスワードのローテーション
Lambdaでするのが一般的 RotationRules AutomaticallyAfterDaysを使用する
↑ChatGPTに聞いてみた
1.Secrets Managerを使用する場合:
- Secrets Manager は、セキュアなマネージドサービスであり、パスワードや API キーなどの機密情報を安全に管理できる。
- Secrets Manager を使用すると、パスワードの自動ローテーションを設定できる。定期的にパスワードを変更し、関連するアプリケーションに新しいパスワードを提供することができる。
- ローテーションは、Secrets Manager の設定で定義されたスケジュールに基づいて自動的に行われる。
2.Lambda を使用する場合:
- Lambda は、イベント駆動型のコード実行サービスであり、特定のトリガーに応じて自動的にコードを実行できる。
- Lambda を使用してカスタムスクリプトを作成し、RDSのパスワードを定期的に変更するためのローテーションプロセスを実装できる。
- 例えば、Lambda を CloudWatch Events やスケジュールされたイベントと組み合わせて、定期的に実行することができる。
どちらを選択するかは、以下の要因によって決定される:
- 管理の簡易性:Secrets Manager を使用すると、パスワードのローテーションが AWS コンソールから直接設定できる、Lambda を使用するとカスタムスクリプトを作成する必要がある。
- 柔軟性: Lambda を使用すると、カスタムロジックを実装できる。このため、より高度なローテーションプロセスを実装する必要がある場合には Lambda が適している。
- コスト: Lambda を使用する場合、実行されるコードの実行時間に対して課金される。ローテーションが短時間で完了する場合には、Lambda のコストが考慮される必要がある。
一般的には、シンプルなケースでは Secrets Manager を使用することが推奨されるが、より複雑なローテーションプロセスが必要な場合やカスタマイズが必要な場合には、Lambda を使用することが適している。
PostgreSQL ユーザーとロールの管理
GRANT および REVOKE コマンドを使用したDCLは、きめ細かいアクセス制御を提供するのに役立つ。
リードレプリカ
リードレプリカがある DB インスタンスを停止することはできない。まずリードレプリカを削除してからソースインスタンスを停止する必要がある
リードレプリカを作成するためには、ソース DB インスタンスで自動バックアップを有効にする必要がある
RDS for SQL Server Enterprise Edition DB インスタンスのリードレプリカを作成するためには、自動バックアップが有効になっている必要があり、また、ソース DB インスタンスは Always On 可用性グループを使用したマルチ AZ 配置でなければならない
SQL Server エージェントジョブはレプリケートされず、フェイルオーバー後にセカンダリで作成する必要がある
Application load balancer から直接リードレプリカにトラフィック解決は難しい
通常、リードレプリカは読み出しのクエリのみをサポートするように設計されている。しかし、アクセスクエリの特定のタイプを高速化するために、リードレプリカにインデックスを追加するなどの更新が必要になるときもある
そのようなときのために、RDS ではリードレプリカへの書き込みもサポートしている
スナップショット
スナップショットから復元した DB は同様のサイズである必要がある
自動化したスナップショットは6時間ごとなどはできないので Lambda を使用するなどの必要がある
コピーされた RDS スナップショットを選択して共有すると、共有できる
移行先 AWS アカウント ID を入力して共有する
RDS の DB インスタンスが STORAGE_FULL 状態である、または、同じリージョン内の同じ DB に対して他のバックアッププロセスが進行中である場合、RDS 自動バックアップは開始しない
また、Amazon RDS では、同じリージョン内で同じ DB インスタンスに対して複数のバックアップ操作(スナップショットの作成や復元など)を同時に行うことはできない。そのため、もし同じ DB インスタンスに対して別のバックアッププロセスが進行中であれば、新たな自動バックアップは開始されない。
DBSnapshotIdentifier を用いて、snapshot の id を指定すれば、CloudFormation 配下でもスナップショットを活用できる
スナップショットから復元された時に、セキュリティグループは継承しない
自動で撮られたスナップショットは他アカウントと共有できないので、コピーなどを行う必要がある
ポイントインタイムリカバリ
RDS のポイントインタイムリカバリを実行すると、新しいデータベースインスタンスが作成されるため、アプリケーションの接続文字列を新しい DB インスタンスに変更する必要がある。
接続文字列とは、DB インスタンスのエンドポイントの DNS アドレスをホストパラメータとして指定するもの
バックアップ保持期間を0秒より上にしないといけない
暗号化
スナップショットは暗号化したもの出ないと、暗号化した DB インスタンスに復元できない
暗号化されていない RDS DB インスタンスを暗号化する最速手段
暗号化されていない RDS DB インスタンスのスナップショットを作成する。暗号化されていないスナップショットの暗号化されたコピーを作成する。暗号化されたスナップショットのコピーを復元する
ストレージ
CLI で簡単に増やせる
RDS では、ストレージ容量の変更は6時間ごとにしか行うことができないという制約がある
RDS ストレージの自動スケーリング
は、その需要に応じて自動的にストレージを拡張できるため、データベース専門家が手動でストレージを追加する必要がなくなる。これにより、ストレージ管理の労力が削減され、コスト対効果が高まる
AutoScaling はないが、ストレージの自動変更はできる
インスタンスはいけるが、ストレージはいけないってこと。
Oracle
LOB
- [制限付き LOB モード]は、すべてのLOB 値をユーザー指定のサイズ制限 (デフォルトは 32 KB) に移行する。サイズ制限を超える LOB値は、手動で移行する必要がある。[制限付き LOB モード]、すべての移行タスクのデフォルトで、通常最高のパフォーマンスが得られる。ただし、[最大LOB サイズ] パラメータ設定が正しいことの確認が必要。このパラメータを、すべてのテーブルの最大 LOB サイズに設定する。
- [完全 LOB モード]は、サイズに関係なくテーブル内のすべてのLOBデータを移行する。[ 完全 LOB モード]は、テーブル内のすべてのLOBデータを移動する際の利便性を提供するが、そのプロセスがパフォーマンスに重大な影響を与える可能性あり。
参考URL: ラージバイナリオブジェクト (LOB)の移行
RDS Proxy
MaxIdleConnections Percent
RDS Proxy の MaxIdleConnections Percent パラメータを変更することにより、アイドル 状態のデータベース接続数を効果的に制御できる
具体的には、RDS Proxy では MaxIdle Connections Percent パラメータを使用して、接続 プール内に保持できるアイドル状態のデータベース接続数を制御できる。
スロークエリログ (Slow query log) は、
MySQL で出力できるログの種類の1つ。 SQL の実行時間が指定した時間よりもかかってしまった SQL を全て出力することができる
スケジュールされたイベント
存在しない
msdb ストアドプロシージャ
RDS から S3 にアクセスできる仕組み
S3 のデータを読み込んでカスタムプロシージャに噛ませるなどもできる
Aurora
カスタムエンドポイント
アプリケーションごとに専用のレプリカに接続したい場合などに有効
BackTrack
DB を復元する仕組み
Aurora 障害挿入クエリ
ALTER SYSTEM SIMULATE READ REPLICA FAILURE
などを実行すると障害を発生させられる
データベースアクティビティストリーム
Aurora はデータベースアクティビティストリームをサポートして
「監査イベント」をリアル タイムで追跡し、Kinesis に供給して他のセキュリティツールで処理することができる
非同期モードのデータベースで Aurora データベースアクティビティストリーミングを有効化し、Kinesis Data Streams を Kinesis Data Firehose に接続することで、データベース管理者のアクティビティをキャプチャし、労力とパフォーマンスへの影響を最小限に抑えることができる。
Aurora データベースアクティビティストリーミングは、データベース管理者のアクティビティを リアルタイムで監視し、Kinesis Data Streams にストリーミングすることができる。これにより、データベースのアクセスとアクティビティログが提供され、監査に対応できる。
非同期モードでの実行がおすすめ
キャッシュ管理機能
Serverless v2 インスタンスでtier-0、1を設定すると、
Writer インスタンスのスケールアップに追従してスケールアップ
し、フェイルオーバー時にすぐ Writer に昇格できるよう備える
Serverless v2 インスタンスでtier-2 ～ 15を設定すると、
Writer インスタンスのスケールアップに
追従せずその時の利用状況に応じてスケーリングする
max allowed packet packet
特定のカラムに1KBを超える情報を INSERT しようとすると、Error を発生させることができる
パラメータグループで Aurora DB クラスターキャッシュ管理を編集して有効にする
クラスターキャッシュ管理により、フェイルオーバーが発生した場合でもアプリケーションのパ フォーマンスが維持されることを保証する
クローン作成
Aurora はデータベースのクローン作成をサポートしているため、最小限の管理作業で迅速かつ費用対効果の高いクローン作成が可能
Aurora Serverless はクローン作成できない
Aurora はクローン作成をサポートしており、これはスナップショットの復元より早い
高度な監査機能
CONNECT:成功した接続と失敗した接続の両方、および切断を記録する。このイベントにはユーザー情報が含まれている。
- QUERY: すべてのクエリをプレーンテキストで記録する (構文またはアクセス権限エラーで失 敗したエラーを含む)。
- QUERY_DCL: QUERY イベントと同様ですが、データ制御言語 (DCL) クエリ (GRANT、REV OKEなど)のみ返す。
- QUERY_DDL: QUERY イベントと同様ですが、データ定義言語 (DDL) クエリ (CREATE、ALT ERなど)のみ返す。
- QUERY_DML: QUERY イベントと同様ですが、データ操作言語 (DML) クエリ (INSERT、UP DATE などと、SELECT)のみ返す。
- TABLE: クエリ実行の影響を受けたテーブルを記録する。
汎用 SSD ストレージ
最大16000 IOPS
IAM データベース認証
IAM データベース認証
IAM データベース認証を使用して DB クラスターに対して認証できる。この認証方法では、DB クラスターに接続するときにパスワードを使用する必要はない。代わりに、作成後15分で有効期限が切れる認証トークンを使用する。
Aurora Global Database
プライマリリージョンでは読み取りおよび書き込みのエンドポイントを提供するが、他のリージョンでは読み取りのエンドポイントしか提供しない
つまり1リージョンに書き込みリージョンが集中することになるのが DynamoGlobalDB との違いの一つ
Comprehend
Aurora が Comprehend とネイティブに統合でき、感情分析を直接実行できるため。
DevOps Guru
具体的には、DevOps Guru は機械学習アルゴリズムを用いて、システムの異常な動作やパフォーマンスの問題を自動で特定し、適切な通知やレポートを提供する。Aurora PostgreSQL と連携させることで、データベースの性能に関する深い洞察を得ることができ、運用の効率化と問題解決の迅速化を図ることができる。
コネクション数
Aurora MySQL のコネクション数は、インスタンスサイズに依存する
ElasiticCache
バックアップウインドウ：
reserver_memory-percent
Sorted Set:
既存のElastiCacheクラスターに対しては、クラスターモードを有効にできない
ElastiCacheグローバルデータストア
「ElastiCache for Memcachedは、グローバルデータストアをサポートしていない」
グローバルデータストアを利用する必要がある場合は、ElastiCache for Redis の利用を検討する必要がある
パラメータ
- transit-encryption-enabled パラメータは、転送中のデータを暗号化するために使用される
これは、データがネットワークを介して移動する際のセキュリティを強化し、不正アクセスから保護するために重要
- at-rest-encryption-enabled パラメータは、保存時のデータを暗号化するために使用される
これにより、データが静的な状態でも保護され、権限のない者がデータにアクセスするリスクが減少する
Neptune
Gremin コンソールでログインできる
Neptune ストレージのベストプラクティス
Neputune クラスターはスケールダウンできないので、下げる場合は
小さいものにエクスポートするのが良い
Neptune Loader
Neptune Loader を使用すると、データの一括読み込みが速くなる
- 頂点とエッジが、適切なヘッダー列のフォーマットで異なる.csv ファイルに指定されていること
→Neptune が頂点とエッジを正しく解釈し、データの読み込みを効率化するため。 適切なフォーマットでデータが分割されていることで、データの取り扱いが容易になる。 - Neptune DB インスタンスの IAM ロールが、S3 バケット内のファイルへのアクセスを許可する適切なアクセス許可で構成されていること
→Neptune インスタンスが S3 バケット内のファイルにアクセスできるようにするため。適切なアクセス許可が設定されていれば、データの読み込みがスムーズに行われる。 - S3 VPC エンドポイントを作成し、データベースのローダーエンドポイントに HTTP POSTを発行する
→S3 VPC エンドポイントを使用することで、インターネットを経由せずに S3 と Neptune の間でデータを転送できる。これにより、データ転送の速度が向上し、 データの読み込みが高速化される。
※Neptune 一括ローダーを使用したデータの取り込み
Neptune は外部ファイルから Neptune DBLoader クラスターに直接データをロードするコマンドを提供する。多数の INSERT ステートメント、addV および addE ステップ、そ の他の API 呼び出しを実行する代わりに、このコマンドを使用できる。
Keyspaces
OpenSearch:
ファセット
ファセットとは、検索結果の絞り込みとフィルタ処理を行うために使用するカテゴリを表すインデックスフィールド。
ファセット検索（ファセットナビゲーション, faceted navigation）とは、あらかじめ Web サイト側が用意した検索条件をユーザーが選択することで、Webサイト内のコンテンツを絞り込めるナビゲーションの仕組み
DocumentDB
DocumentDB 読み取りの環境設定
DocumentDB は、アプリケーションを変更することなく、すべての読み取りリクエストをリードレプリカインスタンスに向けるための読み取り優先設定をサポートしている。
具体的には、DocumentDB の読み取り優先設定を使用すると、アプリケーションの変更を必要とせずに、自動的に読み取りリクエストをリードレプリカインスタンスにルーティングできる。この設定により、システムクエリの75%を占める読み取りリクエストの処理効率が向上し、同時に書き込みリクエストの増加に伴うパフォーマンスの低下を防ぐことができる。
QLDB
台帳保管用サービス
変更履歴を厳密に監視したい時便利
SQL で実行可能
メッセージングサービス
Database Migration Service
レプリケーションインスタンスがターゲットデータベース (この場合、Redshift) と同じリージョンおよびアカウントに存在することが必要。
これにより、データの転送速度やセキュリティを最適化し、データ移動がスムーズに行われる。
具体的には、DMS (Database Migration Service) を利用すれば、ソースとターゲットデータベース間でデータをレプリケーションし、これにより最小限のダウンタイムでデータ移行が可能となる。
また、レプリケーションが完了したらアプリケーションを一時停止し、データベースの接続文字列を変更した後、アプリケーションを再起動する。これにより、最大 5 分間のメンテナンスウィンドウに収まる効率的なデータベース移行が可能となる。
さらに、DMS は Oracle Database Standard Edition から RDS for Oracle DB へのデータ移行もサポートしている。
DMS は DynamoDB をソースとして持つことができない
なので、DynamoDB をバックアップするときは、EMR で、S3 においておくなどがよい
Trusted Advisor
非アクティブなインスタンスの特定が可能
監視関連：
CloudWatch
CloudWatch Application Insights
CloudWatch Application Insights は、メトリクスを分析し、アプリケーションの問題の兆候を識別するために機械学習分類アルゴリズムを使用する。
以上
