SAA学習-データベース-増大するデータ量への対応
今回のテーマ:増大するデータ量への対応
概要
ベストプラクティスの「⑦増大するデータ量の対応」で、
IoT/ビックデータが絶えず増加するデータの保持を効率的に実施する概念をおさらいとなります。
増大するデータ
WEBの発展によりビックデータ蓄積とIoTの発展によるIoTデータ蓄積によりデータ量が大きく増大しています。
事例は以下のようなものがあります。
データ量への対応
効率的なデータ蓄積とIoTなどの大量ストリームデータ処理や解析方法等が必要不可欠となります。
以下の図はAWSマネージドサービスの概要図となります。
ビックデータに必要な技術
ビックデータに対応したデータ蓄積・処理技術が必要不可欠となります。
特徴は以下の項目があります。
Volume:大量データ
大量のデータを効率的に蓄積可能なデータベース技術
Variety:多様なデータ
多様な形式のデータを蓄積可能なデータベース技術
Velocity:速い速度
高速処理が可能なデータ処理ソフトウェア/ハードウェア
データレイクの活用
ビックデート活用の中心はデータレイク型のデータベースを採用されます。
以下はDWHとデータレイクの項目についておさらいします。
- データウェアハウス中心:利用用途に応じてデータを貯めて活用。貯める前に変換を実施。
- データレイク:できる限り生データをほぼ全データ保存する際に活用。貯めた後に変換を実施。
以下はDWH中心とデータレイク中心の比較表となります。
項目 | データウェアハウス中心 | データレイク中心 |
---|---|---|
データ収集 | ・目的別データ →必要なデータのみ抽出/収集 ・構造化データ中心 |
・生データ+目的別データ ・構造化/半構造化/非構造化データ |
蓄積 | ・必要なデータのみを抽出/蓄積 | ・変換しないで生データ形式で保存 ・エッジ処理したデータを保存 |
処理/加工 | ・関連するデータ構造(スキーマ)に変換 ・SQLによる操作 |
・事前にスキーマ(データ構造)を定義しない SQL/SAS/MapReduce/R/NoSQLなどで操作 |
可視化分析 | ・利用者がデータ分析/レポート内容などで利用目的を事前に特定し構築 | ・事前に目的を定義せず、ユーザーがデータ群から新たな価値を抽出しデータを解釈・活用 |
データウェアハウス型とデータレイク型のデータ処理基盤の概略図は以下のようになります。
- データウェアハウス型のデータ処理基盤
- データレイク型のデータ処理基盤
Apacheシリーズ
ビックデータ処理向けの2種があります。
- ApatchHadoop:大量データバッチ向け
- ApatchSpark:ストリーミング処理向け
AWSのデータレイク構造
AWSマネージドサービスをデータレイク型のデータ処理基盤に埋め込むと以下のような相関図となります。
今回のテーマは以上です。
SAA学習-データベース-Redshiftの概要
今回のテーマ:Redshiftの概要
主要サービスの公式資料
Amazon Redshift: docs.aws.amazon.com
概要
Redshiftは高速でスケーラブルな費用対効果の高いマネージド型DWH/データレイク分析サービスとなります。
要点は以下の項目があります。
- 数百ギガバイトのデータから開始し、ペタバイト以上まで拡張可能
- 1テラバイトあたり年間1000USD以下で利用可能
- 自動ワークロード管理や自動テーブルメンテナンス等が多くメンテナンスタスクやデータ配置が自動化されるフルマネージド型
- PostgreSQL互換の列指向データモデル
- 複数ノードをまとめたクラスター構成で単一AZで起動し、マルチAZ構成は不可
- RA3インスタンスが最大。他のクラウドデータウェアハウスの3倍に達するパフォーマンス
- AQUA(Advanced Query Accelerator)による分散キャッシュで、Redshiftが他のクラウドデータウェアハウスに比べて最大10倍の速度で動作
データウェアハウス(DWH)
データウェアハウス(DWH)は、構造化データを利用した経営思考分析型のデータベースになります。
概要
- データの抽出・集約に特化したBIデータ分析用データベース
- 読み込むデータ構造を予め設計し、加工してから利用分のデータを蓄積
- レスポンス重視でデータ抽出・集計が速いが、更新トランザクションは遅い
アーキテクチャ
- データをパーティショニングし複数ディスクから読み込む
- 列指向でデータを格納
利用ケース
- 会計データなどの業務系の構造化データを分析用に加工しBIで利用
- KPI測定/競合分析/アクセス分析など
インスタンスタイプ
利用するデータサイズと増加予測に応じて2つのインスタンスタイプから選択します。
RA3インスタンス
- コンピューティング性能とマネージドストレージのスケーリングと支払いを独立することで、DWHを最適化
- データ量の増大が予想される場合はRA3ノードの利用が推奨
- 最低2ノード必要
- 1時間の1ノード当たり、最安で約4UDS(3.836USD)
DC2インスタンス
- 固定ローカルSSDストレージを使用したDWH
- データサイズ増加に対しノードを追加しクラスターのストレージ容量増強
- 未圧縮で1TB未満のデータセットならばDC2ノードタイプの利用が推奨
- 最低1ノード必要
- 1時間の1ノード当たり、約0.3UDS(0.314USD)
Redshiftの構成
クラスターというグループ単位で、複数ノードによってデータ処理を実行する構成となります。
概要図は以下になります。
Redshiftの特徴的な機能など
Redshiftは列指向型のRDBであり、データを分散・高速処理が可能な仕組みとなります。
主な特徴としては以下のものがあげられます。
列指向型RDB
- 列指向型ストレージにデータを格納するRDBのデータモデルを採用
- 大容量のデータアクセスを容易にしディスクI/O効率化
データ圧縮
- データ圧縮により一度に読み込めるデータ量が多くなることで処理を高速化
- 分析ワークロードでブロック単位でデータを格納しディスクI/O効率化
ソート
データ分散
- データ量とクエリ内容に応じてノードに対する分散処理を調整し効率的で高速な処理を実現
- キャッシュによる高速化を実現
マテアライズドビュー
- 頻繁に実行するクエリパターンを結合・フィルタ・集計・射影によって高速化する機能 公式資料は以下になります。
運用の自動化
自動的なメンテナンス機能と詳細モニタリングによる簡易な運用が可能です。
基本的にはRDSのメンテナンスと同一の対応となります。
項目して以下のものがあります。
CloudWatchとの連携
- 初期設定でCloudWatchメトリクス取得が自動で実施されRedshiftコンソールないで確認可能
自動バックアップ
- 自動でバックアップを定期取得可能
- メンテナンスウィンドウでバックアップ実施時間を指定可能
- スナップショットを手動で取得することも可能
自動メンテナンス
- パッチ適用も自動で実施
- メンテナンスウィンドウでパッチ適用時間を指定可能
スケジューリング機能
機械学習によるクエリ効率化
機械学習によりクエリ実行を調整し効率的な自動実行を補助機能があります。
以下は効率化の概要になります。
テーブルメンテナンスの自動化
- テーブルの分散スタイルの自動最適化
- 統計情報の自動更新
- データの再編成の自動実行
自動ワークロード管理
- 複数クエリの実行をワークロード管理で設定する際に、機械学習でクエリ実行の優先順位を決め自動化
ショートアクセルレーション
cf)WLM:手動ワークロードで使用する管理
設定のレコメンデーション
- 自動でクラスターパフォーマンスなどを分析し、最適化やコスト削減に対するレコメンデーションを実施
ワークロード管理(WLM)
ワークロードに応じて複数のキューを設定し、クエリ割り当てルールに基づいてキューを設定後、優先順位を設定することが可能です。
ロングやショートは機械学習で実装します。
概略図は以下のようになります。
クエリエディタ
マネージメントコンソール画面よりRedshiftのデータベースに接続しクエリ実行が可能です。
スケーリング
Redshiftのノードタイプ変更・追加とクラスターの追加によってスケーリングが可能です。
ノード追加
コンピューティングノードを追加することでパフォーマンスを向上させますクラスターの追加
Concurrency Scalingにより急な同時実行リクエストに対応するため、一時的にクラスタを自動的に数秒で追加し高速なパフォーマンスを発揮させます。(追加クラスターは1~10個までとなります)
Redshift Spectrum
Redshift Spectrumはデータレイクを分析する際に使用されます。
また、ユーザーが管理するS3バケットに対し直接データ解析を実行が可能となります。
概略図は以下のようになります。
Redshiftへデータ連携
Redshiftへデータを移動させることで、DWHとして解析基盤の集約化をすることが重要となります。
以下はRedshiftへ連携するAWSサービスと概要になります。
S3
- 最も頻繁に使用されるデータ連携先
- S3からデータを取得しRedshiftで解析することが可能
- S3内部データ解析を直接実行も可能
Kinesis
- Kinesis data Firehoseを利用しストリーミングデータの格納先
- 解析に利用することが可能
RDS
- AWS Data PipelineやDMSを利用しデータの移行が可能
DynamoDB
- DynamoDBからRedshiftへデータコピーが可能
Amazon EMR
- EMRからRedshiftへデータコピーが可能
Redshiftからデータ連携
RedshiftからQuickSightを利用したデータ可視化に加えてS3とデータ抽出が可能です。 以下はRedshiftから連携するAWSサービスと概要になります。
Amazon QuickSight(BIツール)
- Redshiftに接続しデータの可視化を実行可能
S3
- UNLOADコマンドを実行し、RedshiftからS3にデータ抽出することが可能
Amazon Machine Learning
- Redshiftを機械学習の学習データとして設定し利用可能
RDS
- PostgreSQLの機能を利用しデータをRedshiftからRDSへ連携可能
Amazon QuickSight(BIツール)
AWSでBIツールを導入する際に使用します。
QuickSightはデータを可視化・解析するためのBIツールとなります。
また、Redshiftデータを開始可能となります。
AWS Glue
AWS Glueは、データを抽出、変換、ロード(ETL)を行う完全マネージド型サービスとなります。
AWS Lake Formation
AWS Lake Formationは、複雑な設定が必要なデータレイクの構成を簡単に素早く実現するサービスとなります。
AWS EMR
AWS EMRは、Apache Spark、Apache Hiveなどブックデータフレームワークを使用し、大量データを処理・分析します。
今回のテーマは以上です。
SAA学習-データベース-EFSの構築
今回のテーマ:EFSの概要
主要サービスの公式資料
EFS: docs.aws.amazon.com
Amazon FSx For Windows File Server: docs.aws.amazon.com
Amazon FSx For Lustre: docs.aws.amazon.com
概要
EFS(Elastic File System)は複数のEC2インスタンスからアクセス可能な共有ストレージとなります。
ストレージシステムの概要は以下となります。
S3
- オブジェクトストレージでリージョンに設置
- HTTPによるAPI経由でアクセス
- 大容量のデータを長期保存するためのもの
EBS
EFS
特徴
シンプルかつスケーラブルで柔軟に利用できるファイルストレージとなります。 要点は以下のような項目があります。
シンプル
スケーラブル
柔軟性
- ファイルの減少に合わせて自動で拡張・縮小が可能
- 事前に容量を設定する必要不要
- 使用した分の従量課金
基本性能
何千もの同時アクセスが実現可能となります。
概要と制限事項は以下のものになります。
概要
- 100MB(バースト込み)
- ファイル名は255バイトまで
- 1ファイルの最大容量は48TB
- インスタンス当たり128ユーザーまでが同時オープン接続可能
- 何千もの同時アクセスが実現可能
制限事項
- アカウント当たりのファイルシステム数:1000
- AZごとのファイルシステムあたりのマウントターゲット:1
- ファイルシステムあたりのタグ:50
- マウントターゲットあたりのSG:5
- ファイルシステムあたりVPC数:1
- 各VPCのマウントターゲット数:400
EFSのデータ保存
EFSのデータファイルは複数AZに分散し保存されます。
EFSの設定ステップ
以下のステップでEFSの設定を行います。
1.ファイルシステムを作成
2.接続先のマウントターゲットの作成
3.セキュリティグループの作成
4.パフォーマンスモードの選択
EFSのファイルシステム
EFSの管理単位でファイルやディレクトリの保管場所となります。
1つのAWSアカウントで複数のファイルシステムを作成できます。
構造は以下のようなものになります。
EFSのマウントターゲット
EC2インスタンスからの接続先がマウントターゲットとなります。
概要は以下のようなものになります。
- VPC内のAZにある接続先
- EC2インスタンスは同じAZ内にあるマウントターゲットから接続
- 固定DNS名とIPアドレスを有している
- ファイルシステムDNS名を使用し、マウントすることで自動でIPアドレスを付与
概略図は以下のようになります。
EFSのパフォーマンスモード
汎用モードと最大I/Oモードから選択します。
概要は以下のようになります。
汎用モード
最大I/Oモード
バースト機能
ファイルストレージの負荷に対しバースト機能によりスケーラブルに対応します。 確保する要因としては以下のものがあります。
また、バースト機能により一時的に性能を向上させることが可能となります。
バーストやその他関連事項は以下となります。
バースト
- 一時的な大量トラフィックの発生やそれに伴いサーバなどの処理性能が一時的に向上
バーストスループット
クレジットシステム
cf)EC2インスタンスのt系ファミリアーも利用状況に応じて同じような管理がされます。
以下はAmazon EFSのバースト機能の概要となります。
容量に応じたバースト機能
1TB以上の容量応じて性能が向上する
最大で1GBまでバースト可能容量に応じてクレジットの累積量とスループット性能が向上
EFSクライアント
EFSをEC2インスタンスから操作する際、専用のクライアントソフトウェアを利用します。
利用するソフトウェアは以下となります。
プロビジョンスループット
バーストのスループットと異なる機能でユースケースに応じて利用します。
バーストのスループットとの比較は以下となります。
バーストのスループット
プロビジョンドスループット
ユースケース
複数のEC2インスタンスでデータを共有する際にEFSを利用します。
利用方針やシーンの概要については以下となります。
利用方針
- EBSではできない複数インスタンスからの同時アクセスが必要
- 数秒多淫いでデータ追記が必要
- フルマネージドで運用し簡易に利用
利用シーン
3つのファイルストレージ
EFS以外にもユースケースに応じたファイルストレージがあります。
種別について以下のものになります。
EFS
Amazon FSx For Windows File Server
Amazon FSx For Lustre
Amazon FSx For Windows File Server
Windows File ServerをAWSクラウド上で利用したい場合に利用するストレージとなります。
特徴やユースケースなどは以下となります。
特徴・ユースケース
- Windows File Serverのクラウド移行
- Active Directory統合など幅広い管理機能
- SMBプロトコルによりAmazon EC2、VMware Cloud on AWS、Amazon WorkSpaces、Amazon AppStream2.0インスタンスなど接続可能
- 最大数千台のコンピューティングインスタンスからのアクセス可能
アーキテクチャ構成
- ENI(AWS上で使用するNIC)経由でアクセス
- VPCセキュリティグループで制御
- 単一AZの単一サブネットを指定し構成
- 複数インスタンスでの共有や他AZ内のインスタンスからアクセス可能
- マルチAZ構成の実装可能
Amazon FSx For Lustre(ラスター)
高速コンピューティング処理を実施する分散・並列処理専用の超高性能ストレージとなります。
特徴やユースケースなどは以下となります。
特徴・ユースケース
- 多くのスーパーコンピュータに利用される分散ファイルシステム
- フルマネージド型で安全委Lustreが利用可能
- 最適容量は3600GB
- 最大数百GB/秒のスループット
- 数百万IOPSまでスケール可能
アーキテクチャ構成
- ENI/エンドポイント経由でアクセス
- セキュリティグループで制御
- 単一AZの単一サブネットを指定し構成
- Amazon S3とシームレスな統合によりデータレイク型のビックデータ処理や解析ソリューションに組み込む(イメージ図は以下になります。)
今回のテーマは以上です。
SAA学習-データベース-Auroraの概要
今回のテーマ:Auroraの概要
概要
Auroraは、Amazonがクラウド時代の新しい分散型リレーショナルデータベースを考慮し提供した新RDSとなります。
特徴は、NoSQL型の分散高速処理とRDSのデータ操作性を両立させております。
また、既存のMySQLと比較し2.5~5倍の性能を保ちつつ商用データベースの1/10の価格で提供する高性能・低コストDBとなります。
例:TPC-Cをr3.8xlargeのAuroraと比較し性能約2.5~5倍
cf)RDSの選択する際Auroraにカーソルが合わされているのはAmazonとして使用することを推奨しているため
特徴
高い並列処理性能によって大量に読み書きをすることに適したDBとなります。
また、要点は以下のようなものがあります。
- 高い並列処理によるストレージアクセスによってクエリを高速処理することが可能
- Auroraは大量の書き込みや読込を同時に扱うことが可能
- データベースの集約やスループット向上が見込まれる
- すべてクエリが5倍で高速ではなく適用すべき領域を見つけて利用
- MySQL/PostgreSQLと互換性があり、同じ操作方法とそのコミュニティを利用することが可能
分散型で耐障害性と自己回復性を備えたスケーラブルな新しいタイプのフルマネージド型RDSとなります。
耐障害性/自己回復性とスケーラビリティについては以下のようなものがあります。
耐障害性/自己回復性
- 3つのAZに2つのコポーを設置可能で合計6つのコピーを保持
- 過去のデータがそのままS3に継続的にバックアップ
- リストアも差分適用なく高速
- どのタイミングでも安定したリストア時間を実現
- 99.99%の高可用性・高耐久性
スケーラビリティ
DBクラスタの仮想ボリューム
Auroraは1つのDBインスタンスと1つのDBクラスタボリュームで構成されます。
また、3つのAZにコピーされたクラスタを単一として認識し管理します。
DBクラスタ構成
AuroraはマスタとリードレプリカをまとめたDBクラスタ構成をとります。
概略図としては以下のような構成を取ります。
EC2からDBクラスタへのアクセス方法はエンドポイントから接続します。
書き込み処理の場合は、Aurora Writerをエンドポイントから振り分けし使用します。
読み込み処理の場合は、Aurora Readerをエンドポイントから振り分けし使用します。
マスターが障害などでF/Oした場合は、エンドポイントよりAurora Readerを参照します。
マイグレーション
MySQLとPostgreSQLのスナップショットからAuroraへマイグレーションが可能
Auroraマルチマスター
マスターデータベースを複数構築し、Write性能もスケーラブルに構築可能となります。
(2017年~より実装された機能)
概要としては下記の項目があります。
- どのノードが落ちてもダウンタイムゼロ
- どのAZが落ちてもダウンタイムがゼロ
- Write性能のスケーリング
Auroraサーバレス
予測困難なアプリケーションワークロードに対応したAuroraのオンデマンド自動スケーリング構成となります。
概要としては以下の項目があります。
- 自動的に起動/シャットダウン
- 自動でスケールアップ/スケールダウン
AuroraグローバルDB
他リージョンに対する高性能なリードレプリカ作成機能となります。
概要としては以下の項目があります。
Auroraのユースケース
大規模なクエリ処理が派生するRDB環境などをAuroraへ移行することが検討材料とします。
検討する観点としては以下の項目があります。
大規模なクエリデータ処理
- 書き込み量が多くトランザクション量も多い
- クエリ平行度が高くデータサイズが大きいケースで効果を発揮
- コネクション数やテーブル数が多いデータベース処理
運用の容易さを活用
- スケーラビリティの高さやデータ容量が無制限に拡張
- レプリケーションなどの性能の高さ
今回のテーマは以上です。
SAA学習-データベース-DynamoDBおよびNoSQLの概要
今回のテーマ:DynamoDBおよびNoSQLの概要
主要サービスの公式資料
DynamoDB:
AWS Black Belt Online Seminar:
概要
完全マネージド型のNoSQLデータベースで特徴は以下の項目があります。
- ハイスケーラブルで無制限に性能拡張が可能
- 負荷が高くなっても応答速度が低下しない低レイテンシー
- 高可用性(SPOFなしでデータは3か所のAZに保存)
- CloudWatchで運用
- プロビジョンスループットテーブルごとにRead/Writeに必要なキャパシティを割り当て
例) Read:100、Write:1000 - ストレージの容量制限がなくデータ容量の増加に応じたディスクやノードの増設は不要
DynamoDBが出来ること
キーバリューでデータを操作することが主要な役割
出来ること
- キーに対するバリューのCRUD操作
- 簡単なクエリオーダー
- 数万人以上が同時アクセス処理が必要になるアプリケーションのデータ処理
出来ないこと/向いていないこと
- JOIN/TRANSACTION/COMMIT/ROLLBACKは不可
- 詳細なクエリデータやオーダー
- 大量のデータ読み書き時のコスト増
DynamoDBの整合性モデル動作
結果整合性モデルで一部処理に強い整合性モデルを利用します。
Write
- 少なくとも2つのAZでの書き込み完了が取れた状態で完了
Read
デフォルト:結果整合性モデル
最新の書き込み結果が即時読み取り処理で反映されない可能性がありオプション:強い整合性モデル
GetItem/Query/Scanでは強い整合性のあるオプション指定が可能
パーティショニング
分散型のNoSQLの特徴で、大量データを高速処理するための機能となります。
パーティショニングの概要図は以下となります。
ユースケース
ビックデータ処理向けか大量データ処理が必要なアプリケーション向けに利用します。
また、大量に発生するWEB行動データやログ管理などに利用します。
ビックデータ
- 大量のデータを収集・蓄積・分析するためのデータベースとして利用
- Hadoopと連携しビックデータ処理が可能
アプリケーション
- 大規模サービスのデータ高速処理が必要なアプリケーション向けに利用
- 多数のユーザーが一度にアクセスするようなアプリケーションのデータ処理に利用
ユーザー行動データ管理
- ユーザー情報やゲーム、広告などユーザー行動データ向けDB
- ユーザーIDごとに複数の行動履歴管理
バックエンドデータ処理
適用判断
トランザクションで発生しうるデータベース処理をチェックし検証します。
判断しうる項目例としては以下のようになります。
テーブル設計
DynamoDBはテーブル利用が開始され以下のように設計していきます。
1.テーブル
DynamoDBのテーブルはデータのコレクションとなります。
他のDBと同様にテーブル単位でデータを保存します。
2.項目(アイテム)
各テーブルの中に項目を作成しデータ保持します。
項目間で一意に識別可能な属性をグループとします。
名前やIDなどの属性を付与する場合は、Personalという項目を作成が必要です。
3.属性
各項目は1つ以上の属性で構成されます。
属性はそれ以上分割する必要のない最小のデータ単位となります。
概略図としては以下のようになります。
※属性はVALUE型やJSON型など不揃いでもDynamoDBならば問題ありません。
インデックス
DynamoDBは暗黙的にに設定するキーと明示的なキーがインデックスとして利用できます。
暗黙的なキー
データを一意に特定するために暗黙的なキー(ハッシュキーやレンジキー)として宣言し、
検索に利用するインデックスで、1テーブルに1つ宣言します。
宣言時に使用されるハッシュキーとレンジキーについては以下のようになります。
ハッシュキー
- KVSにおけるキーに相当するデータを一意に特性するためのIDなどを示します
- テーブル作成時に1つの属性を選びハッシュキーとして宣言します
- ハッシュ関数によってパーティションを決定するためハッシュキーと呼ばれます
- ハッシュキーは単独で重複不可となります
レンジキー
- ハッシュキーにレンジを加えたものでレンジキーまたは複合キーと呼ばれます
- テーブル作成時に2つの属性を選び1つをハッシュキーとし、もう一つをレンジキーで宣言します
- 2つの値の組み合わせによって1つの項目を特定します
- 複合キーは単独であれば重複が可能となります
ハッシュキー/レンジキー・複合キーとテーブルなどの相関概略図は以下のようになります。
明示的なキー
ハッシュキーやレンジキーだけでは検索条件を満たせない場合、LSIとGSIを利用します。
LSIとGSIに対は以下のようになります。
なお、スループットやストレージ容量を追加で必要とするため、多様はするべきではありません。
ローカル・セカンダリ・インデックス(LSI)
プライマリーキータイプがハッシュやレンジキーの場合、追加で別のレンジキーを作成するイメージとなります
1テーブルに5つの作成が可能でテーブル作成時に作成します。
用途について以下のようになります。
- レンジキー以外で絞りこみ検索を行うインデックスで、複合キーテーブルに設定可能
- 複合キーによって整理されている項目に対し、別の規則でインデックス検索を可能
グローバル・セカンダリ・インデックス(GSI)
追加で別のハッシュキーを設定することが可能で、全データに対しグローバルに付与されます。
1テーブルに5つの作成が可能でテーブル作成時に作成します。
用途について以下のようになります。
- ハッシュキーの属性の代わりに代用
- ハッシュキーテーブルおよび複合キーテーブルどちらにも設定可能
- ハッシュキーを跨いで自由に検索可能
テーブル操作
テーブル操作を行う代表的なコマンドは以下となります。
コマンド | 概要 |
---|---|
GetItem | ハッシュキーを条件に一定の項目を取得 |
PutItem | 1件のアイテムを書き込む |
Update | 1件のアイテムを更新 |
Delete | 1件のアイテムを削除 |
Query | ハッシュキーとレンジキーにマッチする項目を取得(最大1MB) |
Scan | テーブル全件検索する(最大1MB) |
BatchGetitem | 複数のプライマリーキーに対しマッチする項目を取得 |
DynamoDB Streams
DynamoDBテーブルに保存された項目の追加・変更・削除が発生時に履歴をキャプチャする機能となります。 利用できる機能概要は以下となります。
データの保存
- 過去24時間以内のデータ更新履歴を保存し、24時間を経過すると消去
- データ容量はマネージド型で自動的に管理
データ保存の順番
- 操作が実施された順番に応じてデータをシリアライズ
- 特定のハッシュキーに基づいた変更は正しい順番で保存
- ハッシュキーが異なる場合、受信した順番が前後する可能性があり
DynamoDB Streamsのユースケース
データ更新をトリガーとしたアプリケーション機能やレプリケーションに活用可能です。
事例としてアプリケーションのプッシュ通知などがイメージとなります。
概略は以下の2つとなります。
データ更新をトリガーとしたアプリケーション
データ更新に応じた通知処理などのアプリケーション処理実行など
実装する方法や用途の概略図は以下となります。
DynamoDB Accelerator(DAX)
DAXはDynamoDBにインメモリキャッシュ型の機能を付与します。
概略図としては以下のようになります。
特徴は以下のようなものがあります。
- インメモリキャッシュとして1桁台のミリ秒単位からマイクロミリ秒単位まで結果整合性のある読込ワークロードの応答時間短縮(トレーディングシステムなど)
- マルチAZDAXクラスターは1秒間に数百万件のリクエスト処理が可能
- DAXはDynamoDBを使用するAPIと互換性を持つマネージド型サービスのため、メンテナンスなどの運用や導入が容易に可能
- スループットの強化やキャパシティユニットを必要以上にプロビジョンしないように設計・実装することで運用コストの節約が可能
グローバルテーブル
リージョン間で同期されるマルチリマスターテーブルを作成可能となります。
概要としては以下のようなものがあります。
- DynamoDBの性能のまま世界中で複数のリージョンにエンドポイントを持つことが可能
- 読み書きのキャパシティに加えクロスリージョンレプリケーションのデータ転送料金が課金
- オプションで実施で強い整合性は不可
オンデマンドバックアップ
パフォーマンスに影響なく数百TBのバックアップが実行可能です。
概要としては以下のようなものがあります。
- 任意のタイミングで利用可能な長期間データ保存用バックアップ
- データパイプラインという別サービス利用が必要だった
Read/Writeキャパシティオンデマンド
キャパシティ設定不要でリクエストに応じた課金設定により実装が可能となります。
概要としては以下のようなものがあります。
- トラフィック量の予測が困難な場合、リクエストの実績数に応じた課金が可能
- オンデマンドでRead/Write処理に自動スケーリングを実施
- プロビジョンドキャパシティ設定への変更は無制限
- オンデマンドへの変更は1日1回まで可能
今回のテーマは以上です。
補足:
既存のRDB中心の設計から、
DynamoDB/Lambdaなどの組み合わせで、
サーバレスでサービスが実装できないか初期段階で、
検討も一考の余地があるかと思います。
それに伴いコスト低減が実現することも視野入れつつ代用不可ならば、
RDSを活用する考え方を考慮してもよいかもしれません。
SAA学習-データベース-データベースの基礎
今回のテーマ:データベースの基礎
学習内容
単元 | 概要 |
---|---|
データベースの基礎 | 最適なデータベース選択を実施するため様々なデータベースのタイプと活用方法を概要的に学習 |
DynamoDBの概要 | DynamoDBの基本的な機能や仕組みについて学習 |
DynamoDBの構築 | 実際にDynamoDBを構築し、設定方法や操作方法を学習 |
Auroraの概要 | Auroraの基本的な機能や仕組みについて学習 |
Auroraの構築 | 実際にAuroraを構築し、設定方法や操作方法を学習 |
EFSの概要 | EFSの基本的な機能や仕組みについて学習 |
EFSの構築 | 実際にEFSを構築し、設定方法や操作方法を学習 |
増大するデータ量への対応 | IoTやビックデータなどの増大するデータ量に対応するため、基本技術などの知識を学習 |
Kinesisの概要 | AWSで大量データ処理をする仕組みのKinesisの基本的な機能や仕組みを学習 |
Kinesisの構築 | 実際にKinesisを構築し、設定方法や操作方法を学習(かなり高額) |
概要
データベース
- データベースは関連したデータの形式をそろえて収集・整理し、検索などの操作やデータ管理を実行するシステム
- データベースを実現したシステムをDBMS(Data Base Management System) と呼称
- 基本的にはテーブルという表形式でデータを格納してます。
- 追加・参照・更新。削除などのデータ操作を容易に実行するソフトウェアやデータモデルと一体となり、CRUDと呼称されます
- Create 追加:データを整理し保存
- Read 参照:必要なデータを参照または抽出
- Update 更新:データの変化に応じて変更
- Delete 削除:不要なデータを削除
データベースとストレージの違い
データベース
- データベース内のデータを保存する装置はストレージであるがデータベースではない
- ストレージ+データを管理・操作するデータベースソフトウェア
ストレージ
- コンピュータの主要な構成要素の一つで、データを永続的に記憶する装置
データベースの役割
データ操作を異常なく実行し、データを安全に保護ながら保存・操作ができる仕組みを提供してます。
- データ操作に関わる課題
- システムがクラッシュした際のデータが消えないか?
- データを誤って削除した場合の対処はできないか?
- データ抽出に誤りがないか?
- 2人以上が同時に同じデータにアクセスした際どうなるのか?
- 大量のデータをうまく検索できないか?
データベースの役割を支える仕組みは以下2点となります。
トランザクション
データベースを一環した状態から別の一環した状態へ変化する1つの処理の束になります。
ポイントは以下のようにものになります。
- 同時アクセスした場合、上手く処理する
- データ処理に失敗したらもとに戻す
- システムがクラッシュしてもデータを保護する
トランザクション:ACID
ACIDは信頼性のあるトランザクションシステムの持つべき性質のこと
Atomicity(原子性)
トランザクションが「すべて実行される」か「一つも実行されない」のどちらかの状態になる性質Consistency(整合性)
トランザクションの前後でデータ整合性が保たれ矛盾のない状態が継続される性能Isolation(独立性)
トランザクション実行中の処理過程が外部から隠匿され他の処理に影響を与えない性質Durability(耐久性)
トランザクションが完了したら、その結果は記録されクラッシュしても消失しない性質
トランザクション:耐久性
データを更新する際、COMMITとすると更新が反映されるが、COMMITしないとデータをロールバックし保護します。
以下に例を記載します。
トランザクション:整合性
同時に複数人がアクセスした場合、データの整合性を維持する必要があります。
データの整合性を保証するために。結果整合性と強い整合性の2つで維持を行います。
結果整合性は、変更中であっても更新前の古いデータを参照可とします。
強い整合性制は、変更中ならば更新時の該当データを参照負荷とします。
データモデル
データモデルは、データベースのデータの持ち方など構造や処理を定めるデータの論理的な表現方法となります。
データモデルを選定してから、データモデルに応じたトランザクション処理を決定します。
データモデルの利用用途に応じた以下のような使い分けをされます。
- リレーショナルモデル(今回の学習主テーマ)
- グラフモデル
- キーバリューストア
- オブジェクト
- ドキュメント
- ワイドカラム
- 階層型
最適なデータベースを選択
ワークロードに応じた最適なデータベースサービスを利用します。
関連するデータベースサービスは以下となります。
- RedShift
- RDS
- DynamoDB
- Aurora
- Elasticserch
データベース
データベースは大きくリレーショナルDBか非リレーショナルDBの2種に分かれます。
- リレーショナルDB:これまでのDB(Oracle、PostgreSQLなど)
- NoSQL:ビックデータ向けDB
リレーショナルDB
データベースの基本はリレーショナルDBシステム(RDBMS)です。
業務システム向けのDBの基本となります。
なお、以下のようなポイントとなります。
概要
- データ間の関係性が定義されたデータを取り扱う一般的なDBシステム
- 列と行がいくつかのテーブルで定義されて、テーブル間のリレーションが設計
- データ操作にSQLを利用
-
- テーブル間のリレーションが定義されたデータモデル
- 行思考で1つの行をデータのかたまりとして取り扱う
利用データ
- 会計データ/顧客データといった構造化データ
例
- オンプレやソフトウェア:Oracle、MySQL、SQLServer、PostgreSQLなど
- AWSサービス:RDS
NoSQL
NoSQLは、IoTと同様にビックデータ解析に利用します。
また、以下のようなポイントとなります。
概要
利用データ
非構造化データ
- テキスト、動画、音声など
半構造化データ
NoSQLのタイプ
NoSQLのタイプは、キーに対するデータ形式の格納方法の違いで以下のようなタイプに分類されます。
また、以下のようなポイントとなります。
キーバリューストア
- キーに対しバリュー(値)を入れる単純な構造
- 高速なパフォーマンスと分散型拡張に優れている
- データ読込が高速
ドキュメントデータベース
ワイドカラムストア
- 列指向とも呼ばれ、キーを利用するがデータはカラム(列)で管理
- 非構造データを大規模に格納することを目的
- 行ごとに任意の名前のカラムを無数に格納
グラフデータベース
ビックデータの活用
ビックデータの活用で、データの特徴に応じて利用するデータベースを選択します。
例としては以下のような選定になります。
データベースの全体像
データベースの全体像は、分散型、拡張型の軸とオペレーション向け、分析向けの2つの軸で分類できます。
分類した概念図は以下のようになります。
データウェアハウス(DWH)
データウェアハウスは、BIツールなどと連携し、構造化データを利用した経営分析向けのデータベースとなります。
また、以下のようなポイントとなります。
概要
- データの抽出・集約に特化したBIデータ分析用のデータベース
- 読み込むデータ構造を予め設計し、加工してから利用分のデータを蓄積
- レスポンス重視でデータ抽出・集計が速いが、更新・トランザクションは遅い
-
- データをパーティショニングし、複数ディスクから読み込む
- 列志向でデータを格納
利用データ
- 会計データなどの業務系構造化データを分析ように加工しBIで利用
- KPI測定/競合分析/アクセス分析など
例
分散型DB/データレイク
分散型DB/データレイクは、ビックデータやIoTを累積し高速処理を可能とするDBとストレージの組み合わせとなります。
また、以下のようなポイントとなります。
概要
- データ中抽出に特化したDB
- 分散しデータを保存しており、ビックデータの高速処理向け
利用データ
- ビックデータ、IoT
例
KVS(Key Value Store):キーバリュー型
KVSは、シンプルなデータ構造にすることで高速処理を可能にしたDBとなります。
また、以下のようなポイントとなります。
概要
- キー分散することで、シンプルなオペレーションを高速に実施できるDB
-
- 強い整合性を犠牲にし、結果的な整合性を採用
- 分散向けデータモデル/クエリの採用
- トランザクション/集計/JOINなど不可
利用データ
- 大規模WEBサイトのバックエンドデータ(ユーザーセッション/ユーザー属性/事前計算データのキャッシュ)
- メッセージングシステムのデータ(Twitterなど)
- 大規模書き込みが必要なIoTセンサーデータなど
例
- オンプレやソフトウェア:redis、riak
- AWSサービス:ElastiCache、DynamoDB
データ構造 リレーショナルDBのテーブルとキーバリュー型のテーブルに分かれ以下のような概要図になります。
リレーショナルDBのテーブル
部門 | 場所 | 役職 | 名前 |
---|---|---|---|
人事 | 豊洲 | 部長 | 佐藤 |
製造 | 新宿 | 課長 | 上原 |
総務 | 三鷹 | 社員 | 村上 |
キーバリュー型DBのテーブル
キー | バリュー |
---|---|
1 | 名前:佐藤、部門:総務、場所:豊洲、役職:部長 |
2 | 名前:上原、部門:人事、場所:新宿、役職:課長 |
3 | 名前:村上、部門:製造、場所:三鷹、役職:社員 |
ワイドカラム型
ワイドカラム型は、キーに対しカラムを大規模に登録できる形式となります。
また、以下のようなポイントとなります。
概要
- 分散しシンプルなオペレーションを高速に実施できるDB
- データ取得する際にデータ結合しなくても済むように可能な限り多くのデータを同じ行に保持
利用データ
例
データ構造
ドキュメントDB
ドキュメントDBは、キーに対しドキュメント思考でXMLなどのデータを格納します。
また、以下のようなポイントとなります。
概要
- ドキュメント思考データベースは、様々なデータ構造のドキュメントを混在し保存
利用データ
例
データ構造
インメモリデータグリット
インメモリデータグリットKVSの仕組みをメモリを利用し高性能にしたDBとなります。
また、以下のようなポイントとなります。
概要
- 大量データを多数のサーバのメモリ上で分散し管理する技術
- ミリ秒単位の高速応答処理が可能
-
- データをメモリ上に置くことで、高速なデータアクセスを実現
- データを多数のサーバで分散し管理
利用データ
- 金融の取引処理データでミリ秒以下の応答時間を実現
例
全検索型エンジン×分散DB
データの全検索エンジンであるElasticsearchは分散データベースと連携しデータ全検索処理が可能となります。
また、以下のようなポイントとなります。
概要
- 全検索型のデータ検索エンジンで、分散データベースと連携し検索データベースを構築
- 抽出条件との関係性/関連性が高いデータを抽出し返す
利用データ
例
- オンプレやソフトウェア:elasticsearch、kibana
- AWSサービス:Elasticsearch Service
グラフDB
グラフDBは、グラフ構造でデータ間のつながりを検索・可視化するDBとなります。
データ構造のイメージはマインドマップのような形態をとります。
また、以下のようなポイントとなります。
概要
- グラフ演算に特化したDBで、データ間のつながりを検索/可視化に利用
-
- グラフデータ構造を取るため、RDB以上にスケールアウトができない
- レコード数が増えると検索にかかる時間と難易度が増大
- ACID特性が担保されており、オブジェクト間の関連づけを簡単に表現する
利用データ
- 最短経路検索
- 金融取引の詐欺検出
- ソーシャルネットワークによるリレーション計算
例
分散OLTP(RDB)
分散OLTPは、オンライントランザクション処理(Online Transaction Processing)を分散化する次世代DBとなります。
また、以下のようなポイントとなります。
概要
- グローバルに分散され強整合性を備えたデータベース
-
- リレーショナルデータベースの構造と非リレーショナルデータベースの分散スケーラビリティを兼ね備える
- 高い可用性、構成のトランザクションと強整合性が実現
利用データ
- 大規模な業務データ処理
例
- オンプレやソフトウェア:なし
- AWSサービス:Amazon Aurora
DB種別とデータモデル
データ構造がシンプルなデータベースが分散しやすくビックデータ処理に向いています。
データベースとAWSサービスの相関図
データべースの概念とAWSサービスの相関は以下のような図になります。
今回のテーマは以上です。
SAA学習-Route53-小テスト
今回のテーマ:Route53-小テスト
設問1: プライベートホストゾーンの説明で誤っているもの
回答:1つのプライベートホストゾーンで1つのVPCに対応させる必要がある
設問2:パブリックホストゾーンについて誤っているもの
回答:VPCが相互アクセス可能であれば複数リージョンのVPCでも同じホストゾーンを利用可能
設問3:A社はグローバルにサービス展開されるアプリケーションをAWSで構築しようとしています。
ユーザーにとって最も応答速度が速いサーバーからアクセスできるようにルーティングを実行する非機能要件を満たすためのルーティングポリシー、
回答:レイテンシールーティング
設問4:エイリアス(ALIAS)レコードについて間違っている内容を選択してください。
回答:DNSで独自のドメインレコードを設定する際に用いる汎用レコードである。
cf)ALIASレコードはAWS独自のレコード方式
設問5:Route53を利用して複雑なルーティングポリシーを設定する際の機能と使い方の組合せとして正しいものを選択してください。
回答:トラフィックフローを用いて順序を設定することでルーティングポリシーを設定する
今回のテーマは以上です。