AWSの各DBの特徴が把握できる【Planning and Designing Databases on AWS】を受講してみた
皆さんこんにちは、AWS事業本部オペレーション部の清水です。
AWS における様々な DB サービスの特徴について学習するべく、「Planning and Designing Databases on AWS」を受講してきました！
本コースの受講をお考え中の方へ、お役に立てば幸いです。
AWS認定トレーニングとは？
以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。
私が今回受講したのは、以下の図の赤枠に入るコースになります。AWSを利用して、より高度なセキュリティマネジメントを実施する方法を学びたい方におススメのコースになります。
事前準備
知識レベル
- [Introduction to Building with AWS Databases (AWS データベースのビルド入門)」
- デジタルトレーニングと同等の AWS データベースサービスに関する知識
- リレーショナル / 非リレーショナルデータベースに対するデー タベースの設計コンセプトおよびデータモデリングの理解
- クラウドコンピューティングの概念に関する知識
- 一般的なネットワークと暗号化の概念に関する知識
事前受講推奨
１日目
モジュール１：AWS目的別データベース
Step１- ワークロードの要件の分析
アプリケーションの特徴を抑える
- データアクセスパターン
- NoSQL
- SQL
- データボリューム、速度、多様性
- 項目全部の合計サイズ
- 読み取り書き込みの速度（反比例する）
- スループットをあげると、レスポンスタイムが遅くなる
- レスポンスタイムをあげると、スループットがさがる
- 構造化、半構造化、非構造化データ
- 最初にデータの構造を決めれるかどうか
- トランザクション、参照整合性
- ACIDコンプライアンス
- BASEコンプライアンス
- 強い整合性（常に最新データを取得できる）
- 結果整合性（最新データが常に取得できるわけではない）
可用性、耐久性
- 可用性
- シングルAZ
- マルチAZ
- リージョン跨ぎ
- 耐久性
- レプリケーション
- リードレプリカ
- ダウンタイム
パフォーマンス
- 並列性（同じリクエストがどれくらい同時に実行できるか）
- ランダムアクセスが多いのか
- シーケンシャルアクセスが多いのか
- スループットが必要か ⇔ レスポンスタイムが必要か
容量とスケーラビリティ
- スケールアップ - 垂直スケーリング（インスタンス大きく）
- インスタンスのサイズ変更のため、停止して再起動する間ダウンタイムが発生
- スケールアウト - 水平スケーリング（インスタンス追加）
Step２ - データモデルの選択
- リレーショナル
- Key-value
- ドキュメント
- インメモリ
- グラフ
- 時系列
- 台帳
- ワイドカラム
Step 3 - 適切な目的別データベースの選択
- セルフマネージドデータベースサービスソリューション
- フルマネージドデータベースサービスソシューション
モジュール２：Amazon Relational Database Service
歴史と利点
- RDSが登場する前はEC2インスタンスを立てて、自前でDBをインストールして運用管理していた
- RDSの利点
- データベース管理のタスクを除去
- リレーショナルデータベースエンジンをクラウド or オンプレにデプロイ
- 自動バックアップ
- マルチAZ
- 支払いは使用した分だけ
サポートされるエンジン
- 商用
- オープンソース
- MySQL
- PostgreSQL
- MariaDB
- クラウド中心
- Aurora
- MySQL
- PostgreSQL
- ライセンスモデル
DBインスタンス
- インスタンスサイズの選択の考慮事項
- CPU
- メモリ
- I/O帯域幅
- ネットワーク容量
- インスタンスクラス
- バースト可能インスタンス
- 汎用インスタンス
- メモリ最適化インスタンス
- ストレージ
- EBSを利用
モニタリング
- CloudWatch
- RDS Perfomance Insights（DB内部の細かい情報をみたいとき）
- 拡張モニタリング（OSの中からしか見れないような情報を確認できる）
アクセスコントロール
- パスワード認証
- IAM データベース認証
- Kerberos認証
RDS Proxy
- データベース接続をプールして、共有。スケール機能を改善
- データベーストラフィック中の予測できない急増を処理
モジュール３：Amazon Aurora
利点
- 高いパフォーマンス、スケーラビリティ
- 高い可用性、耐久性
Aurora DB クラスター
- AZは別でも、ストレージはすべて共有で非同期で更新するのが特徴
- AZ１：ライター
- AZ２：リーダー
- AZ３：リーダー
Auroraレプリケーション
- AZ全体を通して、最大１５個のレプリカが分散される
- Auroraレプリカ数の動的調整
- インスタンスのAuto Scallingは、RDSでは出来ない
クロスリージョンリードレプリカ
- Binglogによるレプリケーション
- 最大５つのリージョン
BackTrack
- DBを７２時間以内の特定の時間に、巻き戻し出来る
- Log Structured Storageを利用している
Aurora Serverless
- Serverlessが可能なのは、Aurora
- RDSではできない
ラボ１：Amazon Aurora データベースの操作
- アプリケーションの要件を満たすために Aurora クラスタを設計
- 高可用性とスケーラビリティを実現するために Aurora 上でソリューションを構築
- Aurora を他の AWS サービス (Amazon S3 および Lambda) と統合
２日目
モジュール４：Amazon DynamoDB
key-value
- key-value型はNoSQL DBのデータ構造の１つ
- １つのKeyに１つのValue
利点
- リレーショナルDBは、スケールアウトがあまり得意ではない
- サーバーレスで自動スケーリング
- シンプルなアクセスで、同時に大量のデータをスケーラブルに保存できる
- スキーマレス
プライマリーキー
- パーティションキーのハッシュ値：パーテーションの場所を決定
- ソートキー：パーティション内部の順番を決める
データアクセス方法
- Scan
- パーティションキー＆ソートキー不要のため、検索の自由度が高い
- データ取得において最も遅い、最もコスト高
- マネージメントコンソール〇
- Query
- パーティションキー＆ソートキーの指定が必要
- データ取得において速い
- マネージメントコンソール〇
- GetItem
- 単一の項目を読み込む
- データ取得において最も速い、最も安い
- マネージメントコンソール×
- CLI,SDKで利用可能
ローカルセカンダリインデックス
- 元のテーブルと、同一のパーティションキーが必ず必要
- ソートキーは違っていい
- 同じパーティションキーのため、データ更新は同期
- 強い整合性になるので、この要件が必要な場合はこちらを使用
- 最大５つ迄作成可能
- テーブル作成時だけ、作成可能！
グローバルセカンダリインデックス
- 元のテーブルから、同じパーティションキーは不要
- ソートキーは違っていい
- パーティションキーが元と違うため、データ更新は非同期
- 非同期のため、結果整合性になる
- こちらの方が自由度が高いので、使われることが多い
- 最大２０個まで作成可能
- テーブル作成後に、追加可能！
キャパシティユニット
- １RCU：１秒間にどれだけ読み込みできるか
- １秒／４KB
- コスト
- 強力な整合性：１RCUを消費
- 結果整合性：0.5RCUを消費（半分のコストで済む）
- １WCU：１秒間にどれだけ書き込みできるか
- １秒／１KB
容量とスケーリング
- オンデマンド
- 読み取りと書き込みでリクエストごとの支払い
- 運用開始のときは、負荷予測できないのでコスト高でも、こちらを選択する
- プロビジョンド
- 最大RCU、WCUの設定
- 自動スケーリング
- こちらの方がオンデマンドより安い
DynamoDB Streams
- 時系列のデータをキャプチャできる
- Lambdaと連携して、トリガーとして処理を走らせることが可能
グローバルテーブル
- リージョンをまたいで、テーブルをレプリケーション出来る
- 他リージョンでUpdateされたデータでも、すべてのリージョンに反映（結果整合性）
- ローカルのテーブルで、Updateされた内容が読み書きできる
モジュール５：Amazon Keyspaces
ワイドカラムデータ
- 複数のKeyに対して、複数のValueを紐づけられる
- Keyの構成に対しては、DynamoDBより自由度が高い
利点
- Cassandra互換のフルマネージドデータベース
- パーティションキーに、２つの列の属性を指定も可能
- クラスタリングキーにも、２つの列の属性を指定も可能
- わざわざ２つの列を、１つの列に無理矢理つなげなくてもいいのが利点
キャパシティモード
※オンデマンドとプロビジョンドで、keyspacesは読み方が異なる
- １RRU（オンデマンドの場合の読み方）：１秒間にどれだけ読み込みできるか
- １秒／４KB（強力な整合性と同じ意味合い）
- １秒／２KB（結果整合性と同じ意味合い）
- １WRU（オンデマンドの場合の読み方）：１秒間にどれだけ書き込みできるか
- １秒／１KB
認証
- Cassandraと互換性のあるドライバーが利用できる
モジュール６：Amazon DocumentDB
ドキュメントデータモデル
- JSON形式で、物によって項目の数が増えたり減ったりしても、格納ができるもの（スキーマレス）
- DynamoDBよりさらに、柔軟性、複雑なアクセスパターンが可能
利点
- 柔軟性、複雑なアクセスパターンが可能なため、NoSQLでは一番シェアが多い！（2023年）
- 高速、スケーラブル、フルマネージド型、MongoDB互換
モジュール７：Amazon Quantum Ledger Database
台帳データベース
- 不変性
- 検証可能性
利点
- イミュータブル
- サーバーレス
特徴
- Amazon Ion
- ドキュメント内に、データ型を記述できる
- PartiQL クエリ
- ネストしたデータをクエリで検索できる
- ジャーナルエクスポート
モジュール８：Amazon Neptune
グラフモデル
- 点と線でつながってるデータ構造のこと
- 代表的な例だと、Facebookの「知り合いかも？」機能もこれと同じグラフモデル
- ノード（名前とか：実世界のオブジェクト）→ エッジ（友人とか：オブジェクト間の関係性を表す） → ノード
- ノード／エッジ両方：プロパティ・ラベルを追加できる
ユースケース
- SNS
- レコメンデーション
- 不正検出
- 電車の乗り換え案内
ラボ 2: Amazon DynamoDB の操作
- アプリケーションのデータアクセスパターンに基づいて、テーブルのパーティションとソートキーを決定
- データアクセスパターンをサポートするために必要なローカルおよびグローバルセカンダリインデックスの最適な選択を決定
- DynamoDB テーブルを作成
- ローカルセカンダリインデックス(LSI)
- グローバルセカンダリインデックス (GSI) を作成
3日目
モジュール９：Amazon Timestream
時系列データ
- 一定の時間間隔のデータ点として表現されるレコード
- タイムスタンプ
- ディメンジョン
- メジャー
- 値
特徴
- IoTアプリケーションからの書き込む先に、Timestreamにデータをためていける
- DevOps分析に使える
- 微分
- 積分
- 相関関係
- 補間
モジュール１０：Amazon ElastiCache
インメモリデータ
- メモリはSSDの５０倍の速度
- データの保存は、主にメモリに依存
- 全てのデータはメインメモリのみで、保存・管理
特徴
- ホットスポット
- キャッシュ
- サブミリ秒の応答時間
- スケールイン、スケールアウト、スケールアップ
- 他のデータベースエンジンと組み合わせて使う
エンジン
- 高速な2種類のエンジン
- Memcached
- 高速
- Redis
- 高機能
- データアクセスを高速化したいワークロードのキャッシュに使用
- 消えても良いデータを取り扱う
- Memcached
モジュール１１：Amazon MemoryDB for Redis
特徴
- キャッシュではない
- 耐久型のインメモリデータベース
- 超高速なパフォーマンス（読み込みはマイクロ秒、書き込みは１桁ミリ秒のため遅い）
- 耐久性のあるデータベースを必要としてるアプリケーションに使用
- データ損失のリスク回避が可能
ユースケース
- eコマース支払いプラットフォーム
- SQSでは実現が難しい、優先キューとして利用
モジュール１２：Amazon Redshift
データウェアハウス
- データソースから→データウェアハウスへデータ流し込み（ETL）
- 高性能なレポーティング（BIツール）
特徴
- フルマネージド
- 大量のデータ保存、スケールすればペタバイトまで保存可能
- RDSやAuroraは、128TBなので別物として考える
- 予測可能なコスト
- PostgreSQLがベースのため、BIツール（AWSだとQuickSight）に対応
- 超並列処理（MPP）
- シェアードナッシングアーキテクチャ
分散スタイル
- 選べる４つの分散スタイル
- KEY
- ALL
- EVEN
- AUTO（まずはAUTOを使うのがおすすめ、設定しないとこれになる）
ラボ 3: Amazon Redshift データウェアハウスを使った作業
- データウェアハウスソリューションとしての Amazon Redshift を確認
- Amazon Redshift クラスターを起動す
- 自動テーブル最適化を用いてテーブルを作成
- S3 バケットから Amazon Redshift クラスターにデータをロード
- ソートキーとして指定するテーブル列を特定
- Amazon Redshift が割り当てる列圧縮エンコーディングを特定
モジュール１３：AWSデータベースを扱うためのツール
移行の種類
- 同種間
- AWS DMS
- データベースとデータウェアハウス → 移行またはレプリケート
- 異種間
- AWS SCT
- データベースとデータウェアハウスのスキーマ → オープンソースエンジン、Aurora、Redshiftなどのサービスへ変換
- AWS SCT
Athena
- ユーザーがSQLを使用して、データを簡単に分析
- フェデレーションクエリ
- S3以外にあるデータ（RDS,DynamoDB,Redshiftなど）をSQLクエリ実行ができる
おわりに
AWSの各種DBの種類って、沢山ありますよね。
しかしそれの１つ１つをとってもそれぞれ特徴や利点があり、自分がユーザー側になった際に、どれが最適なサービスなのか判断に困ることが多々あるかと思います。このトレーニングでは、そういった皆さんのお悩みを深堀して学習ができますので、AWSのデータベース・データウェアハウスに関して学習したい方にはおススメのトレーニングです。
この記事がどなたかのお役に立てば幸いです。
