調子に乗ってもう一個認定試験受ける
無事にSolution Architect取れたのでこれで仕事探してもいいかなと思ったのですが、せっかく長年SQLで頑張ってるので、Database周りの資格も欲しくなっちゃいました。
なのでこちら受けます
DBS-C01 Database Specialty
Analyticsと迷ったのですが、どうやら廃止されて新しい資格できるみたいですね
こういう場合って、現在Analyticsの資格を持っている人は再認定など、資格を延長することはできないのでしょうか？
あとで調べてみたいと思います。
勉強方法
前回と同じでUdemyの講座にお世話になろうと思います。
追記
足りなかったのでこちらも購入しました。
あとKindleでこちらも購入しました。
個人的に
オンプレからクラウドへのマイグレーションにすごい興味があります。顧客によって状況が異なる中でどのような選択肢があるのか考えていく瞬間がとても楽しいと思っています。
以下勉強ログ
サービス別のログより、バックアップなどの機能別に見ていく方が今はいいのかもしれません
バックアップ
RDS
自動バックアップの日数に0が設定できる。最大値は35日。デフォルトは7日
0の場合はリードレプリカの設定不可(ソースにスナップショットを用いるため)。
バックアップは自動でスナップショットの作成として同じリージョン内で行われる。DRのために別リージョンに設定したい場合は、AWS BackUpを用いる。
それ以上の保持期間が必要な場合は、Lambda等を利用する必要があります。
スナップショットはS3に保管される
スナップショットの共有、復元
自動バックアップの物は共有不可。KMSキーへのアクセス許可が必要。
復元は新規のインスタンスを使用するため、エンドポイントが変更になる
ポイントインタイムリカバリ(PITR)
最短5分ごとにS3にトランザクションログを格納。復元の際はやはり新規インスタンス
DynamoDB
DynamoDBにスナップショットや自動バックアップ機能はないので、手動バックアップかポイントインタイムリカバリを設定するしかない
ポイントインタイムリカバリも最大35日までしか設定できない
ストリームの機能を使うことで過去24時間に削除されたItemを知ることができる。TTLで削除されたItemをバックアップする、などができる
Aurora
自動バックアップの日数に0が設定できない。最大値は35日。デフォルトは7日
バックトラック(MySQLのみ)
現在のインスタンスで、最大72時間変更トランザクションを遡ってDBクラスタをその時点に戻す。
テーブル単位で指定はできない。
クローニング
既存のAuroraクラスタを素早くコスト効率よく複製する機能です。スナップショットより速く作成できる。データベースのクローンではCopy-on-Writeプロトコルを使用しており、ソースデータベースかクローンデータベースで書き換えが発生した時にデータがコピーされます。
データのフルコピーは発生しないため、アドホックな分析用途などで使われる。そのためバックアップ用途ではなく、一時的なものとして考えた方が良い。
復元の速さ
速い順に
バックトラック(Aurora MySQLのみ) ＞ ポイントインタイムリカバリ ＞ スナップショットの復元
負荷分散
ElasticacheをRDSの前面に配置する方がリードレプリカやインスタンスサイズのスケールアップよりもコスト面では安い
Auroraは読み取りトラフィックの自動ロードバランシングを備えたエンドポイントをサポートしています
RDSのリードレプリカはAmazon Route 53 加重レコードセットを使用して、リクエストを複数のリードレプリカに分散させることができます。
削除保護機能
DynamoDBだけない
データローテーション
DynamoDBはTTL（TimeToLive）で有効期限を設定でき、不要なデータを自動で削除することができる。
監査
Aurora
高度な監査を有効化すると以下を記録できるようになり、CloudTrailにログをエクスポートできる
トラブルシュート
互換性のないパラメータのためMySQLを開始できませんでした
これはパラメータがRDSのエンジンまたはインスタンスクラスと互換性のない規定値以外の値に設定されているためです。この問題を解決するためにはカスタムパラメータをデフォルト値にリセットする必要があります(デフォルトパラメータは変更不可能)。
ItemCollectionSizeLimitExceededException
DynamoDBで起こるエラー。LSIを含んだテーブルは合計10GBまでなので、それを超えた際にこのエラーが出る
インデックス
DynamoDB
LSI(ローカルセカンダリインデックス)
ソートキー以外にパーティション内で絞り込みを使いたい場合に設定する。なのでパーティションキーのみでプライマリキーとしている場合は設定できない
また、このインデックスはテーブル作成時のみ設定可。後から設定や削除は不可
既存のLSIを変更したい場合はバックアップを取得し、復元の際に設定する。
GSI(グローバルセカンダリインデックス)
テーブル全体で絞り込みを使いたい場合に設定する。テーブルに対してスキャンではなくクエリになるので、消費読み込みユニットを抑える＝コストを抑えることもできる
このインデックスはテーブル作成時以外にも後から設定や削除が可能
カーディナリティ
パラメータ
デフォルトのDBパラメータは変更できないので新しくカスタムパラメータグループを作成して適用する。
動的パラメータの変更は、再起動せずに直ちに DB インスタンスに適用されます。静的パラメータの変更は、DB インスタンスの再起動後にのみ適用されます。
エンドユーザーはセッションを再接続しないと新しいパラメータが反映されない。
ストレージエンジン
RDS
MySQL
デフォルトのストレージエンジンはInnoDBとなっており、そしてMyISAMの利用は非推奨
MariaDB
MariaDB 10.2からデフォルトストレージエンジンはInnoDB、それ以前はXtraDB
Aurora
MySQL
MyISAMは使用できない
良記事
データ整合性
DynamoDB
書き込み
結果整合性のみ
読み込み
結果整合性(デフォルト)、強力な整合性の両方をサポート
ただし、強力な整合性を選択した場合はレイテンシーが高くなったりGSIがサポートされない、スループット容量の消費が多くなる＝コスト増などに注意する。
トランザクション
RDBのようなトランザクションまでは期待できないが、複数テーブルに対する操作をグループ化できます。これでDBにロールバック要件があってもDynamoDBを選択肢から除外する必要がない。
以下のような制限がある
トランザクションには、100件を超えるアクションを含めることはできない
トランザクションに 4MB を超えるデータを含めることはできない
同一テーブルに2つのアクションを実行できない
また、消費するユニットが通常の倍＝コスト2倍になる。
DynamoDBのユニット計算
読み込みが4KB以下の結果整合性で0.5,強い整合性で1,トランザクション読み込みで2ユニット
書き込みが1KB以下の結果整合性で1,トランザクション書き込みで2ユニット
Elastic Beanstalk
RDS DB インスタンスを Elastic Beanstalk 環境にアタッチすると、環境を終了した際にRDS DBインスタンスが環境によって削除されるため、データが失われます。
IAMデータベース認証
PostgreSQL、MySQL、MariaDBで利用可能
AWS Database Migration Service
RDBMS以外にも、S3やRedshift、Kinesis Data Streamsをターゲットとして使用することもできる。
障害テスト
DBインスタンスの再起動を使う。終了（Terminate）させるとDBはフェイルオーバーではなく削除されます。
ダウンタイム
OS/ハードウェアメンテナンスのダウンタイムはシングル AZ 配置は数分間、マルチAZはフェイルオーバーの数十秒程度。セカンダリからメンテナンスが始まり、メンテナンス後、フェイルオーバー(ダウンタイム)、元プライマリ(FOでセカンダリ)のメンテナンス
データベースエンジンレベルのアップグレードはプライマリとスタンバイ DB インスタンスの両方が同時にアップグレードされるので長時間のダウンタイムが必要。
セキュリティ
アクセス制御
VPC、ネットワークACL、セキュリティグループでアクセスを制御
暗号化
格納時の暗号化
AWS KMSを利用して暗号化
DBインスタンス作成時のみ設定可能。既存のものを暗号化したい場合はスナップショットを作成し、その際に設定、リストアすることで可能。
プライマリ/リード双方に同じ設定をしないといけない
Oracle、SQL Serverの場合はDB独自の暗号化(TDE)があるが、両方使用するとパフォーマンス低下する可能性があるので、どちらかのみにする。
通信時の暗号化
SSL/TLSを用いて暗号化を行う
IAMを利用したDB認証
MySQL、PostgreSQL、Aurora MySQL/Postgre SQLのみで利用可能
フェイルオーバー優先順位
Amazon Auroraでは、フェイルオーバーが発生した場合、最も高い優先度（最も低い番号）を持つRead Replicaを昇格させます。同じ優先度の場合、サイズが最も大きいレプリカを昇格させます。
レプリケーション
Amazon RDSは自動的に別のAZスタンバイインスタンスに同期的にレプリケートします。
リードレプリカは非同期的にレプリケートします。
DynamoDBテーブルの必要なパーティション数
例として、500のWCUと5000のRCU、50GBの容量を割り当てることを計画しています。
最大3,000RCUまたは1,000WCUを1パーティションとして割り当てます。
つまり、スループットをサポートするために必要なパーティション = (500WCU/1000WCU) + (5000RCU/3000RCU) = 2.3→3パーティション
一方で、1パーティションの最大サポートサイズは10GBなので、50GB/10GB = 5パーティション
3と5で大きい方は5なので、この例の計画の場合は5パーティションが必要。
Auroraカスタムエンドポイント
リードレプリカを専用にアサインできる。
分析用の重いクエリにサービス用の読み取りクエリが邪魔されない構成が実現できる
モニタリング
Aurora
データベースアクティビティストリーミング
アクティビティをCloudWatch Logsよりもリアルタイムで Amazon Kinesis データストリームにプッシュします。
これによりサードパーティの監視サービスにデータを連携する。
ElastiCache Redis/Memcachedの比較
Aurora DB クラスターの停止
まずレプリカインスタンスを停止し、次にプライマリインスタンスを停止して、フェイルオーバーメカニズムのアクティブ化を回避します
停止できないもの
Aurora グローバルデータベースの一部であるクラスター
クロスリージョンリードレプリカを持つクラスター
Aurora 並列クエリ機能を使用するクラスター
Aurora Serverless v1 クラスター(Serverless v2は可能)
スナップショットからの復元
新しいクラスターはデフォルトのパラメータグループを使用している可能性があります。元のクラスターにカスタム設定があった場合は、それらを新しいクラスターに適用する必要があります。
RDSのオプショングループとパラメータグループの違い
パラメータグループはデータベースに割り当てるメモリなどのリソースの量を指定できます。
オプショングループはバックアップや監査ログ、暗号化などのオプションを提供する。DBエンジンによってオプションはだいぶ異なる。
拡張モニタリングとPerformance Insightsの違い
拡張モニタリングは各種パフォーマンスメトリクス（CPU使用率、ディスクI/O、メモリ使用量など）を、細かいレベルで収集し、CloudWatchのメトリクスとして表示する
Performance InsightsはSQLクエリのパフォーマンスを分析するためのツールです。どのクエリがCPUを多く消費しているか、どのクエリが最も遅いか、どのクエリが最も多くのI/Oを発生させているかなどを確認
RDSインスタンスを停止する場合
リードレプリカをまずは削除しないといけない
Auroraの２種類のストレージ
永続データ用のストレージ (クラスターボリュームと呼ばれます)。このストレージタイプは、より多くのスペースが必要になると自動的に増加します。
ローカルストレージ。DBインスタンスの変更によってのみ変更できます。ログおよびInnoDB 以外の一時テーブルの保存にローカルストレージを使用します。
DynamoDBのCreateTable操作
CreateTable操作は非同期であり、テーブルのステータスがACTIVEになるまでDescribeTableを用いてステータスを定期的にチェックすることで、テーブルが使用可能になっていることを確認する必要があります。その後PutItem操作などが行えます
移行でLOBサイズが大きい場合
数メガバイトを超える LOB がある場合は、完全 LOB モードで別の AWS DMS タスクを作成します。
RDS for SQL Server DBのWindows認証
AWS Managed Microsoft AD を使用する。AD Connector の使用をサポートしていません。
RDS イベントサブスクリプション
RDSで発生する再起動、フェイルオーバー、メンテナンスの開始などの重要イベントをSNSに紐づけて通知機能を作成できる。
ElasticacheとDynamoDB DAXの選定
高速な通信がしたい、保存するデータは書き込みと読み込みが頻繁に発生するためコストが心配
->ElastiCache
データの永続化がしたい
->DynamoDB
RDSからAuroraへの移行
Aurora レプリカにデータ移行し、切り替え（カットオーバー）時にレプリカをプライマリに昇格させる
AWS DMSレプリケーションインスタンスの配置
ターゲットデータベースに非常に近いことで、最も速い書き込みパフォーマンスを実現でき、ネットワーク遅延が最小限に抑えられます。 なので同じVPCやAZにあるとより高速。
RDS Proxyの役割
多数のアプリケーションの接続管理
後方のDBインスタンスのフェイルオーバー時の接続の維持(RTO（Recovery Time Objective）目標の達成に重要
Neptuneの用途
グラフDBなので、以下のような方向性を確かめる要件に向いている。
・特定のコンポーネントに障害が発生した場合、影響を受けるネットワークとルート
・ネットワーク間に冗長なルートがあるネットワーク
・ネットワーク間に冗長なルートがないネットワーク
・2つのネットワーク間の最速パス