扱う内容
・RDS
・Aurora
・DynamoDB
・ElastiCashe
【RDS】
リードレプリカ
参照専用のデータベース
データベースの参照時の負荷が高い場合は、もう１台レプリカを作って参照はそっちに任せればいいじゃん、という機能
・マルチAZを利用してリードレプリカを複数のAZに分散したり、異なるリージョンに置くこともできる
・データベースのインスタンスクラス(EC2のインスタンスタイプみたいなもの)を選択できる
・ストレージタイプを選択できる
RDSの暗号化
RDSは、データベースインスタンスを暗号化することができる
・暗号化すると、バックアップやスナップショット、ログ、リードレプリカも暗号化される
・暗号化するかしないかはデータベース作成前に指定する
・作成後に暗号化したい場合は、暗号化したいインスタンスの暗号化スナップショットを作成し、そこから複製する
パラメータグループとオプショングループ
RDSにおいて、、タイムゾーンや最大接続数、監査ログの有効化などの設定を変更したい場合は、DBパラメータグループやオプショングループで定義する
【Aurora】
Auroraの特徴
・データベースインスタンスだけを必要に応じて増減できる
・データベースインスタンスとストレージが分離されている
・デフォルトで3つのAZに、2つずつのデータコピーが作成され、破損データの検出と修復を実施する
・データベースのクローン(複製)を、データコピーせずに高速で作成できる
Auroraでの接続先(エンドポイント)
Auroraにおいて、データベースへの接続は**エンドポイント(接続先)**によって制御される
クラスターエンドポイント
更新、参照、データベースの定義変更など、データベースへのすべてのアクセスを行う
接続先はプライマリインスタンス
読み取り(リーダー)エンドポイント
データベースの参照のみ行う
接続先はレプリカインスタンス
インスタンスエンドポイント
インスタンスへの直接アクセスを行う
Aurora Global Databaseとは
Auroraデータベースを複数のリージョンにまたがって運用できるサービス
・データベースアクセスを世界中から高速で行える
・災害対策になる
・1つのプライマリリージョンと、複数のセカンダリリージョンを指定できる
・障害発生時は、停止1秒前までのデータを復旧し(RPO)、サービスを止める時間を1分未満にして復旧する(RTO)
Aurora Serverless
DBインスタンスの負荷状況に応じて、自動的にDBインスタンスの起動、停止、スケールアップ/ダウンを実施してくれる機能
通常のAuroraではDBインスタンス作成時にインスタンスタイプを指定するが、Serverlessではデータベースの負荷状況に応じて稼働する
【Redshift】
データウェアハウスとは
複数のシステムからデータを収集、統合、蓄積し、分析に使用するデータベース
Redshiftの構造
・Leaderノード
司令塔の役割
アプリケーションからのリクエストを受けてComputeノードに指示を出し、Computeノードが提出した結果をまとめてアプリケーションに返す
・Computeノード
Leaderノードからの命令を処理するノード
こいつが多ければ多いほど処理性能が上がる
Redshift Spectrum
S3上のデータを、Redshiftの外部テーブルとして参照できるようにした機能
S3のデータをわざわざRedshiftに取り込む必要がなくなる
【DynamoDB】
DynamoDBの特徴
・ストレージの容量制限なし
・Key-Value型のNoSQLサービス
・JSONなどの階層構造のデータ(ドキュメント型)も格納できる
・構造がシンプルなので、データアクセスのパフォーマンスが高い
・主キー以外の属性については、データ追加時のスキーマ変更が必要ない
・インデックスを作れる
・自動的に3つのAZにデータが保存される
DAX(DynamoDB Accelerator)
DynamoDBのインメモリキャッシュクラスタのこと
ようはただでさえ早いレスポンス速度をさらに上げるためのもの
グローバルテーブル
DynamoDBテーブルを複数のリージョンにまたがって運用できるサービス
世界各地のユーザーの読み取りと書き込みを高速化できる
DynamoDB Streams
テーブルに対して行われた直近24時間の変更(追加、更新、削除)をログとして保存する機能
DynamoDBの読み込みモード
DynamoDBでは、3つのAZにデータが保存される
この書き込み時に、3つあるAZのテーブルのうち2つのテーブルに書き込まれた時点で完了扱いになり、残りのテーブルにはあとからレプリケートされる
そのため、レプリケートされるまでは、書き込み前の結果と書き込み後の結果が混在するため、ミスって古い方のデータを読み込む可能性がある
そのため、以下の読み込みモードのどちらかを使うとよい
結果整合性のある読み込み
一時的には読み込んだデータが最新じゃないかもしれないけど、最終的には最新のデータが取得できる
強力な整合性のある読み込み
必ず最新のデータを取り出せる
ただし金がかかるのと、レイテンシが高くなる
DynamoDBの利用料金
DynamoDBでは、テーブルに対する書き込みと読み取り量で、料金が変わる
オンデマンドモード
どれだけ読み取りと書き込みしたかで料金が決定するモード
プロビジョニングモード
あらかじめ読み取りと書き込み量を予約して料金を決定するモード
プロビジョニングモードにおける読み取りと書き込みの単位は、キャパシティユニットという単位で管理されている
キャパシティユニットは自動スケールに対応している
大規模に使いたい場合はリザーブドキャパシティを使う
DynamoDBの2つのバックアップ方法
オンデマンドバックアップ
ユーザーが任意のタイミングで作成するバックアップ
ポイントタイムリカバリ
差分バックアップが定期的に自動で作成されるタイプのバックアップ
どちらも、バックアップ作成中はパフォーマンスに影響を与えない
【ElastiCache】
ElastiCacheのデータベースエンジン
Memcached
高パフォーマンスなだけのエンジン
シンプルなキャッシュとして利用する
Redis
高パフォーマンスに加えて、高可用性や機密性まで備えたエンジン
自動フェイルオーバーやバックアップ、リストア、データ暗号化まで備えている
キャッシュにおけるデータの保存方法
ライトスルー戦略
データベースへのデータの書き込みが行われると同時に、キャッシュにも書き込む
常に最新のデータと整合性が維持されるが、書き込み性能が若干低下する恐れがあるのと、アクセスされないデータがキャッシュに蓄積する恐れがある
遅延読み込み戦略
データベースへの書き込みを優先し、キャッシュは必要な時だけ書き込む
アプリがデータ要求した場合、まずキャッシュを確認し、データが存在すれば返す。
キャッシュにない場合、データベースからデータを取得して返した後、キャッシュに書き込む
要求されたデータのみキャッシュするので、リソース節約になる
ただし、データベースとキャッシュで一時的なデータの不一致が生じる恐れがある
また、キャッシュにデータがなかった場合はデータベースに取りに行くので時間がかかってしまう
