久しぶりに AWS 認定試験を受験をしようと思い立ちました。
おそらく最近メンタルが健康だからだと思います。仕事にプライベートに。
マズローの欲求5段階説によると「①生理的欲求」「②安全の欲求」「③社会的欲求」「④承認欲求」が満たされて、最後に「⑤自己実現の欲求」が来るそうです。
「⑤自己実現の欲求」が勉強のモチベーションになるのかなと思います。
しかし、その前の「④承認欲求」は満たされていないような…
このページでは AWS Certified Database – Specialty（DBS-C01）の勉強履歴を追記していきます。
主に学んだことを備忘録的に追記していくので関連性のないトピックが並んでしまうかもしれません。
はじめに
ノートブックなので思いついたことを書きなぐっています。
体系化していませんし、順番も全く意識していません。
ただ見返して学習するためだけに特化しています。
RDS
RDS に関する学習履歴＆備忘録です。
RDS と Aurora は分けます。
RDS バックアップの保持期間
RDS 作成後にバックアップ保持期間を変更できます。
バックアップ保持期間は0～35日間で設定できます。
RDS 手動スナップショットの制限
RDS の手動スナップショットには制限があります。
1つのリージョンごとに100までの制限があります。
逆に手動スナップショットの場合は、保持期限はありません。
試験ではLambdaでスナップショットを取得する際に「手動によるスナップショット」と表現されます。
一見するとLambdaなので「自動スナップショット」と思われるかもしれませんが、あくまでも自動スナップショットは RDS の自動バックアップ機能を利用した場合のみに言います。
Lambdaでスナップショットは形式的には手動でスナップショットを取得していることになりますので注意です。
試験では勘違いしやすいです。
また、手動スナップショットは S3 バケットに保存されるので、手動スナップショットを取得後に再度別の S3 バケットに保存する必要はありません。
RDS への通信を暗号化する場合
以下のURLより RDS のルート証明書をダウンロードします。
https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem
Microsoft SQL Server on RDS にはレポート機能がない
Microsoft SQL Server on RDS にはレポート機能がないので EC2 インスタンスで構築します。
細かなアクセス権限の設定
RDS はマネジメントサービスなので pg_hba.conf は利用できません。
各 DB アカウントごとに細かくアクセス権限を設定する場合は、GRANT と REVOKE コマンドを利用します。
Aurora
Aurora に関する学習履歴＆備忘録です。
Aurora と RDS は細かな機能が異なるので分けました。
Aurora には高度な監査機能がある
Aurora には高度な監査機能があります。
以下のイベントを取得できます。
- CONNECT ← 成功した接続と失敗した接続。切断。ユーザー情報も含まれる。
- QUERY ← すべてのクエリの記録。
- QUERY_DCL ← データ制御言語（DCL）クエリ（GRANT、REVOKEなど）
- QUERY_DDL ← データ定義言語（DDL）クエリ（CREATE、ALTERなど）
- QUERY_DML ← データ操作言語（DML）クエリ（INSERT、UPDATEなど）
Aurora にはパブリック IP を付与できない
Aurora にはパブリック IP を付与できません。その為 Lambda と連携する際は プライベート VPC、プライベートサブネット経由での接続が必要になります。
カスタムエンドポイント
Aurora はカスタムエンドポイントを作成することができます。
複数のアプリがあり、1つは高速なレスポンスが必要なアプリ、もう1つは遅延しても問題ないようなアプリの場合、カスタムエンドポイントを利用して振り分けることができます。
Backtrack（バックトラック）機能で DELETE しても元に戻せる
Aurora には Backtrack 機能があるので間違って DELETE 分を実行して削除しても元に戻すことができます。
バックトラック機能は、Aurora だけで RDS では利用できません。
障害挿入クエリ
Aurora には障害挿入クエリの機能があり、様々な障害をシミュレートすることができます。
以下の障害をシミュレートすることができます。
- Aurora インスタンスの障害
- Aurora レプリカの障害
- ディスク障害
- ディスクの輻輳
※輻輳（ふくそう）とは何かが1か所に集中して混雑する様子を言います。
障害挿入クエリを使用した Amazon Aurora MySQL のテスト
クロスリージョンレプリカを作成する場合
クロスリージョンレプリカを作成するには、Aurora MySQL DB クラスターのバイナリログを有効にする必要があります。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Aurora グローバルデータベース
グローバルデータベースは、グローバル分散アプリケーション向けに設計されており、単一の Amazon Aurora データベースを複数の AWS リージョンにまたがって運用できます。
リージョン間（東京リージョンと米国東部（バージニア北部）など）のデータへの例レイテンシーアクセスを提供します。
Aurora から Lambda を実行する場合
Aurora から Lambda 関数を実行する場合は、Aurora にトリガーとストアドプロシージャを作成して Lambda 関数を呼び出します。
S3 から直接データをインポート可能
S3 バケットにある XML ファイルやテキストファイルを直接 Aurora へデータをロードすることが可能です。
LOAD DATA FROM S3 または LOAD XML FROM S3 ステートメントを使用して、Amazon S3 バケットに保存されているファイルからデータをロードできます。
Aurora Serverless
Aurora Serverless に関する学習履歴＆備忘録です。
Aurora Serverless にしかない機能をまとめるために分けました。
DataAPI
Aurora Serverless では DataAPI の機能があります。
この機能を使うことでサードパーティのアプリなどがセキュアに Aorora Serverless のデータにアクセスできるようになります。
Redshift
Redshift に関する学習履歴＆備忘録です。
Redshift 監査ログ
DBに個人情報など気密性の高い情報が含まれている場合、コンプライアンス要件を満たすために詳細なログの記録が必要になります。
ログには以下の情報が含まれている必要があります。
- データベース認証の試行
- 接続
- 切断
- クエリ内容
- クエリを実行したユーザー
Amazon Redshit の監査ログはデフォルトで有効ではありません。
監査ログを有効にするとログを作成して S3 バケットのアップロードします。
データベース監査ログ作成
https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/db-auditing.html
ワークロード管理（WLM）とは
Amazon Redshift のワークロード管理 (WLM) により、ユーザーはワークロード内の優先順位を柔軟に管理することが可能になります。
これにより、実行速度が高く処理時間の短いクエリが、処理時間の長いクエリの後に滞らないようにできます。
DynamoDB
DynamoDB に関する学習履歴＆備忘録です。
DynamoDB の問題は、特にパーティションキーとソートキーの設計、グローバルセカンダリインデックスとローカルセカンダリインデックスの違いなどが分かりづらいです。
パーティションキーとソートキー
- パーティションキー ← ユーザー ID、E メール、電話番号など、項目ごとに一意の値を持つ。
- ソートキー ← 関連情報をまとめたり範囲を指定して効率的にクエリを実行するために使う。
Amazon DynamoDB は、データをパーティションに保存します。
以下、AWS の公式サイトでパーティションキーとソートキーが分かりやすく解説されています。
パーティションとデータ分散
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html
プライマリキー、パーティションキー、ソートキー
パーティションキーの値は内部ハッシュ関数の入力で使用します。出力されたハッシュ値の値により保存されるパーティションが決まります。
同じパーティションキーを持つ項目は同じパーティションにまとめられることになります。
グローバルセカンダリインデックス（GSI）
パーティションキーとソートキーだけでは、短時間でサクッとデータを抽出できない場合（全く出来ないわけではないけど、ものすごく時間が掛かるとか）に、もう1セットパーティションキーとソートキーのセットを作って短時間でデータを抽出できるようにする目的で作ります。
試験でグローバルセカンダリインデックスの問題が出る場合は、データを検索しやすいようにもう1セット作るような問題になります。
■グローバルセカンダリインデックスの設計方法
https://aws.amazon.com/jp/blogs/news/how-to-design-amazon-dynamodb-global-secondary-indexes/
グローバルセカンダリインデックスとローカルセカンダリインデックスの違い
参考URL：https://qiita.com/uenohara/items/c52c2eef991fd6c8a405
参考URL：https://dev.classmethod.jp/articles/conceptual-learning-about-dynamodb-lsi/
後程詳細に説明しますが、ローカルセカンダリインデックス（LSI）の方が自由度が少ないため、「追加のスループットが課金されない」、「強力な整合性のある読み込み」という要件がなければ、各種制約が少ないグローバルセカンダリインデックス（GSI）の使用が推奨されています。
ローカルセカンダリインデックス（LSI）
同じテーブルの他の任意のカラムをソートキーにすることをローカルセカンダリインデックスと言います。
【例】
学生の期末試験のデータを保存するテーブル作成時に、
– パーティションキーを “student_id”
– ソートキーを “subject”
– テストの点数として “test_score”
上記カラム設定でテーブルを作成したとします。
この際、ローカルセカンダリインデックス（LSI）を設定していない場合にはパーティションキーでもソートキーでもない “test_score” カラムに対して直接検索をかけることができません。
このテーブルから、“test_score” が 80 点よりも高い生徒を見つけたい場合、直接検索が出来ないためデータを見つける手間が掛かります。（コストが掛かります。）
ローカルセカンダリインデックス（LSI）を使うと、任意のカラムをソートキーとして設定することができます。
“test_score” をソートキーとして設定し、“test_score” カラムに対して直接検索をかけることでテストスコアのデータを素早く見つけることが可能になります。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/LSI.html
ローカルセカンダリインデックス（LSI）の使い所
調べるとグローバルセカンダリインデックス（GIS）の方が制限が少なく柔軟性があるので、基本的にグローバルセカンダリインデックス（GIS）を使用する方が利便性が高いと思います。
ローカルセカンダリインデックス（LSI）を使用することが必須の要件でなければ、グローバルセカンダリインデックス（GSI）を使用することを考慮します。
グローバルセカンダリインデックス（GSI）と比べて、ローカルセカンダリインデックス（LSI）を使用するメリット
- ローカルセカンダリインデックス（LSI）では、追加のスループットが課金されない。
- ローカルセカンダリインデックス（LSI）では、グローバルセカンダリインデックス（GSI）ではサポートされていない「強力な整合性のある読み込み」が可能であるため、データ挿入後すぐにセカンダリインデックスのキーに対して正しいデータの読み取りをしたい場合はローカルセカンダリインデックス（LSI）を利用する。
グローバルセカンダリインデックス（GSI）と比べて、ローカルセカンダリインデックス（LSI）を使用するデメリット
- グローバルセカンダリインデックス（GSI）はパーティションキーとソートキーの両方を自由に設定できるが、ローカルセカンダリインデックス（LSI）はパーティションキーしか自由に設定できないため、セカンダリインデックス設計の柔軟性に欠ける。
- パーティションキー値ごとのサイズ制限が、グローバルセカンダリインデックス（GSI）は無制限だが、ローカルセカンダリインデックス（LSI）には合計 10GB という制限がある。各パーティションキー値毎に大容量データを格納することを想定したテーブルには不向きとなる。
- グローバルセカンダリインデックス（GSI）は 1つのテーブルにつき 20個まで作成ができ、上限緩和申請をすることも可能。ローカルセカンダリインデックス（LSI）は 5個が上限であり、緩和申請をすることができない。
- グローバルセカンダリインデックス（GSI）は Write/Read Capacity Unit を自由に設定できるためエラーが発生しにくい設計が可能。ローカルセカンダリインデックス（LSI）はテーブルに設定されたキャパシティーユニットから変更ができない。
- グローバルセカンダリインデックス（GSI）はテーブル作成後いつでも作成が可能だが、ローカルセカンダリインデックス（LSI）はテーブル作成時に同時に作成する必要がある。
結果整合性のある読み込み
DynamoDB テーブルからの読み込みオペレーションの応答には、最近の書き込みオペレーションの結果が反映されていないことがあります。
応答には古いデータが含まれる場合があります。
少し時間がたってから読み込みリクエストを繰り返すと、応答で最新のデータが返されます。
強力な整合性のある読み込み
強力な整合性のある読み込みをリクエストすると、DynamoDB は成功した以前のすべての書き込みオペレーションからの更新が反映された最新データの応答を返します。
Amazon DynamoDB Accelerator（DAX）
Amazon DynamoDB Accelerator（DAX）はフルマネージドのインメモリキャッシュです。
ElastiCacheとは異なり、DynamoDB 専用です。
DynamoDB の読み取り（ExecuteStatement、GetItem、Query、Scanなど）で最大10倍のパフォーマンスを実現します。
ElastiCache よりも DAX の方が DynamoDB 用に特化されているため読み取りのパフォーマンスを向上させる場合は DAX を選択します。
ElastiCache
ElastiCache に関する学習履歴＆備忘録です。
ElastiCache のリードレプリカを手動でプライマリにする場合
最初にクラスターモードを無効にしてからマルチ AZ のフェイルオーバー機能を無効にします。
予約メモリパーセントパラメータ（reserved-memory-percent）
ElastiCache for Redis に固有のパラメータです。
予約メモリパーセントパラメータ（reserved-memory-percent）の目的はすべてのクラスターに対して予約メモリ管理を簡易化することです。
デフォルト値は25%です。
この値を増やす（25%→40%など）ことで、バックアップ時のパフォーマンスが上がります。
ElastCache for Redis のバックアップ
複数のノードを設定しているノードグループでRedisを実行している場合は、プライマリノードもしくはリードレプリカからバックアップを作成できます。
プライマリノードではなくリードレプリカからバックアップを取得することが推奨されています。
ログ管理
データベーススペシャリストの試験でログ管理の問題も出題されます。
ログ管理の項目を別途設けました。
CloudWatch Logs サブスクリプション
- subscription → 購読予約
サブスクリプションを使用して CloudWatch Logs からのログイベントのリアルタイムフィードにアクセスし、カスタム処理、分析、他のシステムへのロードを行うために、Amazon Kinesis ストリーム、Amazon Kinesis Data Firehose ストリーム、AWS Lambda などの他のサービスに配信することができます。
ログイベントが宛先サービスに送信されると、base64 でエンコードされ、gzip 形式で圧縮されます。
CloudWatch Logsのフィルタ
CloudWatch Logsのフィルタは2種類あります。
- メトリクスフィルタ
- サブスクリプションフィルタ
CloudWatch Logs サブスクリプションフィルタ
サブスクリプションフィルタはロググループ単位に設定します。
リアルタイムでログを配信する場合
■リアルタイムでログを配信する場合
- Amazon Kinesis Streams
- Amazon Kinesis Data Firehose
- AWS Lambda
コメント