おっさん社内SEエンジニアの勉強ブログ

勉強記録のブログとなります。

SAA学習-データベース-増大するデータ量への対応

今回のテーマ:増大するデータ量への対応

概要

ベストプラクティスの「⑦増大するデータ量の対応」で、
IoT/ビックデータが絶えず増加するデータの保持を効率的に実施する概念をおさらいとなります。

増大するデータ

WEBの発展によりビックデータ蓄積とIoTの発展によるIoTデータ蓄積によりデータ量が大きく増大しています。
事例は以下のようなものがあります。

  • WEBの発展によるデータ蓄積:ECサイト
  • IoTの発展によるデータ蓄積:Suica

データ量への対応

効率的なデータ蓄積とIoTなどの大量ストリームデータ処理や解析方法等が必要不可欠となります。
以下の図はAWSマネージドサービスの概要図となります。

f:id:In-houseSE:20210810072733p:plain

ビックデータに必要な技術

ビックデータに対応したデータ蓄積・処理技術が必要不可欠となります。
特徴は以下の項目があります。

Volume:大量データ

大量のデータを効率的に蓄積可能なデータベース技術

Variety:多様なデータ

多様な形式のデータを蓄積可能なデータベース技術

Velocity:速い速度

高速処理が可能なデータ処理ソフトウェア/ハードウェア

データレイクの活用

ビックデート活用の中心はデータレイク型のデータベースを採用されます。
以下はDWHとデータレイクの項目についておさらいします。

  • データウェアハウス中心:利用用途に応じてデータを貯めて活用。貯める前に変換を実施。
  • データレイク:できる限り生データをほぼ全データ保存する際に活用。貯めた後に変換を実施。

以下はDWH中心とデータレイク中心の比較表となります。

項目 データウェアハウス中心 データレイク中心
データ収集 ・目的別データ
→必要なデータのみ抽出/収集
・構造化データ中心
・生データ+目的別データ
・構造化/半構造化/非構造化データ
蓄積 ・必要なデータのみを抽出/蓄積 ・変換しないで生データ形式で保存
・エッジ処理したデータを保存
処理/加工 ・関連するデータ構造(スキーマ)に変換
SQLによる操作
・事前にスキーマ(データ構造)を定義しない
SQL/SAS/MapReduce/R/NoSQLなどで操作
可視化分析 ・利用者がデータ分析/レポート内容などで利用目的を事前に特定し構築 ・事前に目的を定義せず、ユーザーがデータ群から新たな価値を抽出しデータを解釈・活用

データウェアハウス型とデータレイク型のデータ処理基盤の概略図は以下のようになります。

  • データウェアハウス型のデータ処理基盤

f:id:In-houseSE:20210813151334p:plain

  • データレイク型のデータ処理基盤

f:id:In-houseSE:20210813153130p:plain

Apacheシリーズ

ビックデータ処理向けの2種があります。

  • ApatchHadoop:大量データバッチ向け
  • ApatchSpark:ストリーミング処理向け

AWSのデータレイク構造

AWSマネージドサービスをデータレイク型のデータ処理基盤に埋め込むと以下のような相関図となります。

f:id:In-houseSE:20210813153858p:plain

今回のテーマは以上です。

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の構成

クラスターというグループ単位で、複数ノードによってデータ処理を実行する構成となります。
概要図は以下になります。

f:id:In-houseSE:20210808150218p:plain

Redshiftの特徴的な機能など

Redshiftは列指向型のRDBであり、データを分散・高速処理が可能な仕組みとなります。
主な特徴としては以下のものがあげられます。

列指向型RDB

  • 列指向型ストレージにデータを格納するRDBのデータモデルを採用
  • 大容量のデータアクセスを容易にしディスクI/O効率化

データ圧縮

  • データ圧縮により一度に読み込めるデータ量が多くなることで処理を高速化
  • 分析ワークロードでブロック単位でデータを格納しディスクI/O効率化

ソート

  • データが格納されるブロックに対しメタデータを付与して検索値とする
  • リーダーノードのインメモリ上にメタデータを格納
  • データのソート順をテーブルごとにソートキーとして指定

データ分散

  • データ量とクエリ内容に応じてノードに対する分散処理を調整し効率的で高速な処理を実現
  • キャッシュによる高速化を実現

マテアライズドビュー

  • 頻繁に実行するクエリパターンを結合・フィルタ・集計・射影によって高速化する機能 公式資料は以下になります。

docs.aws.amazon.com

運用の自動化

自動的なメンテナンス機能と詳細モニタリングによる簡易な運用が可能です。
基本的にはRDSのメンテナンスと同一の対応となります。
項目して以下のものがあります。

CloudWatchとの連携

  • 初期設定でCloudWatchメトリクス取得が自動で実施されRedshiftコンソールないで確認可能

自動バックアップ

  • 自動でバックアップを定期取得可能
  • メンテナンスウィンドウでバックアップ実施時間を指定可能
  • スナップショットを手動で取得することも可能

自動メンテナンス

  • パッチ適用も自動で実施
  • メンテナンスウィンドウでパッチ適用時間を指定可能

スケジューリング機能

機械学習によるクエリ効率化

機械学習によりクエリ実行を調整し効率的な自動実行を補助機能があります。
以下は効率化の概要になります。

テーブルメンテナンスの自動化

  • テーブルの分散スタイルの自動最適化
  • 統計情報の自動更新
  • データの再編成の自動実行

自動ワークロード管理

  • 複数クエリの実行をワークロード管理で設定する際に、機械学習でクエリ実行の優先順位を決め自動化

ショートアクセルレーション

  • 機械学習アルゴリズムを使用し対象クエリを1つ1つ分析し、クエリの実行時間を予測し、実行時間の短いクエリを実行時間の長いクエリよりも優先し実行
  • WLMキューを削減可能

cf)WLM:手動ワークロードで使用する管理

docs.aws.amazon.com

設定のレコメンデーション

  • 自動でクラスターパフォーマンスなどを分析し、最適化やコスト削減に対するレコメンデーションを実施

ワークロード管理(WLM)

ワークロードに応じて複数のキューを設定し、クエリ割り当てルールに基づいてキューを設定後、優先順位を設定することが可能です。
ロングやショートは機械学習で実装します。
概略図は以下のようになります。

f:id:In-houseSE:20210808154837p:plain

クエリエディタ

マネージメントコンソール画面よりRedshiftのデータベースに接続しクエリ実行が可能です。

スケーリング

Redshiftのノードタイプ変更・追加とクラスターの追加によってスケーリングが可能です。

  • ノード追加
    コンピューティングノードを追加することでパフォーマンスを向上させます

  • クラスターの追加
    Concurrency Scalingにより急な同時実行リクエストに対応するため、一時的にクラスタを自動的に数秒で追加し高速なパフォーマンスを発揮させます。(追加クラスターは1~10個までとなります)

Redshift Spectrum

Redshift Spectrumはデータレイクを分析する際に使用されます。
また、ユーザーが管理するS3バケットに対し直接データ解析を実行が可能となります。
概略図は以下のようになります。

f:id:In-houseSE:20210808155913p:plain

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ユーザーまでが同時オープン接続可能
  • 何千もの同時アクセスが実現可能

制限事項

EFSのデータ保存

EFSのデータファイルは複数AZに分散し保存されます。

EFSの設定ステップ

以下のステップでEFSの設定を行います。

1.ファイルシステムを作成
2.接続先のマウントターゲットの作成
3.セキュリティグループの作成
4.パフォーマンスモードの選択

EFSのファイルシステム

EFSの管理単位でファイルやディレクトリの保管場所となります。
1つのAWSアカウントで複数のファイルシステムを作成できます。
構造は以下のようなものになります。

f:id:In-houseSE:20210808080320p:plain

EFSのマウントターゲット

EC2インスタンスからの接続先がマウントターゲットとなります。
概要は以下のようなものになります。

概略図は以下のようになります。

f:id:In-houseSE:20210808082300p:plain

EFSのパフォーマンスモード

汎用モードと最大I/Oモードから選択します。
概要は以下のようになります。

汎用モード

最大I/Oモード

  • 大規模な何十~何千というクライアントから同時アクセスが必要な際に利用
  • 合計スループットを優先しスケール
  • レイテンシーが多少長くなる

バースト機能

ファイルストレージの負荷に対しバースト機能によりスケーラブルに対応します。 確保する要因としては以下のものがあります。

  • NFSサーバー容量増大に応じたスループット性能の拡張が必要
  • 一時的なピーク時が増大する可能性

また、バースト機能により一時的に性能を向上させることが可能となります。
バーストやその他関連事項は以下となります。

バースト

  • 一時的な大量トラフィックの発生やそれに伴いサーバなどの処理性能が一時的に向上

バーストスループット

クレジットシステム

cf)EC2インスタンスのt系ファミリアーも利用状況に応じて同じような管理がされます。

以下はAmazon EFSのバースト機能の概要となります。

  • 容量に応じたバースト機能
    1TB以上の容量応じて性能が向上する
    最大で1GBまでバースト可能

  • 容量に応じてクレジットの累積量とスループット性能が向上

EFSクライアント

EFSをEC2インスタンスから操作する際、専用のクライアントソフトウェアを利用します。
利用するソフトウェアは以下となります。

  • Amazon-efs-utilsに含まれるEFSマウントヘルパー
  • Linux NFSv4クライアント

プロビジョンスループット

バーストのスループットと異なる機能でユースケースに応じて利用します。
バーストのスループットとの比較は以下となります。

バーストのスループット

  • ピーク時にクレジットを消費してバーストを実行し一時的に性能を向上
  • 最大スループットとバースト時間に制限あり
  • スループット性能向上にはストレージ容量の増大が必要

プロビジョンドスループット

ユースケース

複数のEC2インスタンスでデータを共有する際にEFSを利用します。
利用方針やシーンの概要については以下となります。

利用方針

  • EBSではできない複数インスタンスからの同時アクセスが必要
  • 数秒多淫いでデータ追記が必要
  • フルマネージドで運用し簡易に利用

利用シーン

  • アプリケーションの共有ディレクトリとして利用
  • ビックデータなど分散並列処理環境における共有データアクセスストレージとして利用
  • コンテンツの共有リポジトリとして利用

3つのファイルストレージ

EFS以外にもユースケースに応じたファイルストレージがあります。
種別について以下のものになります。

EFS

Amazon FSx For Windows File Server

  • Windows File Serverと互換性のあるストレージ
  • Windows上に構築されWindows AD 、OSやソフトウェアとの連携が豊富に可能j

Amazon FSx For Lustre

  • 分散型ファイルストレージであるオープンソースLustre」と互換性のある分散型高速ストレージ
  • 機械楽手など高速コンピューティングのデータレイヤーに利用する一時保存用の処理用ストレージ

Amazon FSx For Windows File Server

Windows File ServerをAWSクラウド上で利用したい場合に利用するストレージとなります。
特徴やユースケースなどは以下となります。

特徴・ユースケース

アーキテクチャ構成

  • ENI(AWS上で使用するNIC)経由でアクセス
  • VPCセキュリティグループで制御
  • 単一AZの単一サブネットを指定し構成
  • 複数インスタンスでの共有や他AZ内のインスタンスからアクセス可能
  • マルチAZ構成の実装可能

Amazon FSx For Lustre(ラスター)

高速コンピューティング処理を実施する分散・並列処理専用の超高性能ストレージとなります。
特徴やユースケースなどは以下となります。

特徴・ユースケース

アーキテクチャ構成

  • ENI/エンドポイント経由でアクセス
  • セキュリティグループで制御
  • 単一AZの単一サブネットを指定し構成
  • Amazon S3とシームレスな統合によりデータレイク型のビックデータ処理や解析ソリューションに組み込む(イメージ図は以下になります。)

f:id:In-houseSE:20210808100911p:plain

今回のテーマは以上です。

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%の高可用性・高耐久性

スケーラビリティ

  • 10GBから最大64TBを提供するSSDデータプレーンを利用してシームレスに拡張可能
  • Auto-Scaringなどクラウド独自のスケーラブルが可能
  • 最大15のリードレプリカを利用した高速読込が可能

DBクラスタの仮想ボリューム

Auroraは1つのDBインスタンスと1つのDBクラスタボリュームで構成されます。
また、3つのAZにコピーされたクラスタを単一として認識し管理します。

f:id:In-houseSE:20210802075927p:plain

DBクラスタ構成

AuroraはマスタとリードレプリカをまとめたDBクラスタ構成をとります。
概略図としては以下のような構成を取ります。

f:id:In-houseSE:20210802080948p:plain

EC2からDBクラスタへのアクセス方法はエンドポイントから接続します。
書き込み処理の場合は、Aurora Writerをエンドポイントから振り分けし使用します。
読み込み処理の場合は、Aurora Readerをエンドポイントから振り分けし使用します。

f:id:In-houseSE:20210806063053p:plain

マスターが障害などでF/Oした場合は、エンドポイントよりAurora Readerを参照します。

f:id:In-houseSE:20210806063711p:plain

マイグレーション

MySQLPostgreSQLのスナップショットからAuroraへマイグレーションが可能

Auroraマルチマスター

マスターデータベースを複数構築し、Write性能もスケーラブルに構築可能となります。
(2017年~より実装された機能)
概要としては下記の項目があります。

  • どのノードが落ちてもダウンタイムゼロ
  • どのAZが落ちてもダウンタイムがゼロ
  • Write性能のスケーリング

Auroraサーバレス

予測困難なアプリケーションワークロードに対応したAuroraのオンデマンド自動スケーリング構成となります。
概要としては以下の項目があります。

  • 自動的に起動/シャットダウン
  • 自動でスケールアップ/スケールダウン

AuroraグローバルDB

他リージョンに対する高性能なリードレプリカ作成機能となります。
概要としては以下の項目があります。

Auroraのユースケース

大規模なクエリ処理が派生するRDB環境などをAuroraへ移行することが検討材料とします。
検討する観点としては以下の項目があります。

大規模なクエリデータ処理

  • 書き込み量が多くトランザクション量も多い
  • クエリ平行度が高くデータサイズが大きいケースで効果を発揮
  • コネクション数やテーブル数が多いデータベース処理

運用の容易さを活用

  • スケーラビリティの高さやデータ容量が無制限に拡張
  • レプリケーションなどの性能の高さ

今回のテーマは以上です。

SAA学習-データベース-DynamoDBおよびNoSQLの概要

今回のテーマ:DynamoDBおよびNoSQLの概要

主要サービスの公式資料

DynamoDB:

docs.aws.amazon.com

AWS Black Belt Online Seminar:

www.youtube.com

www.youtube.com

概要

完全マネージド型の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の特徴で、大量データを高速処理するための機能となります。
パーティショニングの概要図は以下となります。

f:id:In-houseSE:20210801080331p:plain

ユースケース

ビックデータ処理向けか大量データ処理が必要なアプリケーション向けに利用します。
また、大量に発生するWEB行動データやログ管理などに利用します。

ビックデータ

  • 大量のデータを収集・蓄積・分析するためのデータベースとして利用
  • Hadoopと連携しビックデータ処理が可能

アプリケーション

  • 大規模サービスのデータ高速処理が必要なアプリケーション向けに利用
  • 多数のユーザーが一度にアクセスするようなアプリケーションのデータ処理に利用

ユーザー行動データ管理

  • ユーザー情報やゲーム、広告などユーザー行動データ向けDB
  • ユーザーIDごとに複数の行動履歴管理

バックエンドデータ処理

適用判断

トランザクションで発生しうるデータベース処理をチェックし検証します。
判断しうる項目例としては以下のようになります。

f:id:In-houseSE:20210801090132p:plain

テーブル設計

DynamoDBはテーブル利用が開始され以下のように設計していきます。

1.テーブル

DynamoDBのテーブルはデータのコレクションとなります。
他のDBと同様にテーブル単位でデータを保存します。

2.項目(アイテム)

各テーブルの中に項目を作成しデータ保持します。
項目間で一意に識別可能な属性をグループとします。
名前やIDなどの属性を付与する場合は、Personalという項目を作成が必要です。

3.属性

各項目は1つ以上の属性で構成されます。
属性はそれ以上分割する必要のない最小のデータ単位となります。

概略図としては以下のようになります。

f:id:In-houseSE:20210801091411p:plain

※属性はVALUE型やJSON型など不揃いでもDynamoDBならば問題ありません。

インデックス

DynamoDBは暗黙的にに設定するキーと明示的なキーがインデックスとして利用できます。

暗黙的なキー

データを一意に特定するために暗黙的なキー(ハッシュキーやレンジキー)として宣言し、
検索に利用するインデックスで、1テーブルに1つ宣言します。

宣言時に使用されるハッシュキーとレンジキーについては以下のようになります。

ハッシュキー
  • KVSにおけるキーに相当するデータを一意に特性するためのIDなどを示します
  • テーブル作成時に1つの属性を選びハッシュキーとして宣言します
  • ハッシュ関数によってパーティションを決定するためハッシュキーと呼ばれます
  • ハッシュキーは単独で重複不可となります
レンジキー
  • ハッシュキーにレンジを加えたものでレンジキーまたは複合キーと呼ばれます
  • テーブル作成時に2つの属性を選び1つをハッシュキーとし、もう一つをレンジキーで宣言します
  • 2つの値の組み合わせによって1つの項目を特定します
  • 複合キーは単独であれば重複が可能となります

ハッシュキー/レンジキー・複合キーとテーブルなどの相関概略図は以下のようになります。

f:id:In-houseSE:20210801093625p:plain

明示的なキー

ハッシュキーやレンジキーだけでは検索条件を満たせない場合、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つとなります。

実装する方法や用途の概略図は以下となります。

f:id:In-houseSE:20210801100813p:plain

DynamoDB Accelerator(DAX)

DAXはDynamoDBにインメモリキャッシュ型の機能を付与します。
概略図としては以下のようになります。

f:id:In-houseSE:20210801101324p:plain

特徴は以下のようなものがあります。

  • インメモリキャッシュとして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しないとデータをロールバックし保護します。
以下に例を記載します。

f:id:In-houseSE:20210621074554p:plain

トランザクション:整合性
同時に複数人がアクセスした場合、データの整合性を維持する必要があります。
データの整合性を保証するために。結果整合性と強い整合性の2つで維持を行います。
結果整合性は、変更中であっても更新前の古いデータを参照可とします。
強い整合性制は、変更中ならば更新時の該当データを参照負荷とします。

データモデル

データモデルは、データベースのデータの持ち方など構造や処理を定めるデータの論理的な表現方法となります。
データモデルを選定してから、データモデルに応じたトランザクション処理を決定します。
データモデルの利用用途に応じた以下のような使い分けをされます。

  • リレーショナルモデル(今回の学習主テーマ)
  • グラフモデル
  • キーバリューストア
  • オブジェクト
  • ドキュメント
  • ワイドカラム
  • 階層型
最適なデータベースを選択

ワークロードに応じた最適なデータベースサービスを利用します。
関連するデータベースサービスは以下となります。

  • RedShift
  • RDS
  • DynamoDB
  • Aurora
  • Elasticserch
データベース

データベースは大きくリレーショナルDBか非リレーショナルDBの2種に分かれます。

  • リレーショナルDB:これまでのDB(OraclePostgreSQLなど)
  • NoSQL:ビックデータ向けDB
リレーショナルDB

データベースの基本はリレーショナルDBシステム(RDBMS)です。
業務システム向けのDBの基本となります。
なお、以下のようなポイントとなります。

  • 概要

    • データ間の関係性が定義されたデータを取り扱う一般的なDBシステム
    • 列と行がいくつかのテーブルで定義されて、テーブル間のリレーションが設計
    • データ操作にSQLを利用
  • アーキテクチャ

    • テーブル間のリレーションが定義されたデータモデル
    • 行思考で1つの行をデータのかたまりとして取り扱う
  • 利用データ

    • 会計データ/顧客データといった構造化データ
NoSQL

NoSQLは、IoTと同様にビックデータ解析に利用します。
また、以下のようなポイントとなります。

  • 概要

    • リレーショナルデータ構造を持たずSQLを利用しないDBの総称
    • 操作しやすいように一部SQLSQLに似たクエリ処理を適用したモデルも存在
  • 利用データ

    • 構造化されていないKeyとValueのみ(ID番号に一列に全データを格納)のKVSデータ
    • 動画/画像/ドキュメントなど非構造化データ
    • XML/JSONなどの半構造化データ
  • 非構造化データ

    • テキスト、動画、音声など
  • 半構造化データ

NoSQLのタイプ

NoSQLのタイプは、キーに対するデータ形式の格納方法の違いで以下のようなタイプに分類されます。
また、以下のようなポイントとなります。

  • キーバリューストア

    • キーに対しバリュー(値)を入れる単純な構造
    • 高速なパフォーマンスと分散型拡張に優れている
    • データ読込が高速
  • ドキュメントデータベース

    • キーに対しバリューではなく、JSONXMLなどのデータを格納
    • 複雑なデータ構造を扱うアプリで生鮮性高く柔軟に開発する
  • ワイドカラムストア

    • 列指向とも呼ばれ、キーを利用するがデータはカラム(列)で管理
    • 非構造データを大規模に格納することを目的
    • 行ごとに任意の名前のカラムを無数に格納
  • グラフデータベース

    • グラフ理論に基づき、データ動詞の関係をグラフで相互に結びつけた要素で構成
    • RDBと比較し高速横断検索が可能
ビックデータの活用

ビックデータの活用で、データの特徴に応じて利用するデータベースを選択します。
例としては以下のような選定になります。

f:id:In-houseSE:20210623073225p:plain

データベースの全体像

データベースの全体像は、分散型、拡張型の軸とオペレーション向け、分析向けの2つの軸で分類できます。
分類した概念図は以下のようになります。

f:id:In-houseSE:20210623074304p:plain

データウェアハウス(DWH)

データウェアハウスは、BIツールなどと連携し、構造化データを利用した経営分析向けのデータベースとなります。
また、以下のようなポイントとなります。

  • 概要

    • データの抽出・集約に特化したBIデータ分析用のデータベース
    • 読み込むデータ構造を予め設計し、加工してから利用分のデータを蓄積
    • レスポンス重視でデータ抽出・集計が速いが、更新・トランザクションは遅い
  • アーキテクチャ

    • データをパーティショニングし、複数ディスクから読み込む
    • 列志向でデータを格納
  • 利用データ

    • 会計データなどの業務系構造化データを分析ように加工しBIで利用
    • KPI測定/競合分析/アクセス分析など
    • オンプレやソフトウェア:Oracle Exadata、TERADATA、VERTICA、Greenplum
    • AWSサービス:Redshift
分散型DB/データレイク

分散型DB/データレイクは、ビックデータやIoTを累積し高速処理を可能とするDBとストレージの組み合わせとなります。
また、以下のようなポイントとなります。

  • 概要

    • データ中抽出に特化したDB
    • 分散しデータを保存しており、ビックデータの高速処理向け
  • アーキテクチャ

    • SQLライクなクエリで操作可能
    • INSERT/UPDATE/DELETEはない
    • トランザクションはない
    • データ書き込みは一括ロードまた全件削除のみ
  • 利用データ

    • ビックデータ、IoT
    • オンプレやソフトウェア:Impala、LIVE、presto+HDFS
    • AWSサービス:S3
KVS(Key Value Store):キーバリュー型

KVSは、シンプルなデータ構造にすることで高速処理を可能にしたDBとなります。
また、以下のようなポイントとなります。

  • 概要

    • キー分散することで、シンプルなオペレーションを高速に実施できるDB
  • アーキテクチャ

    • 強い整合性を犠牲にし、結果的な整合性を採用
    • 分散向けデータモデル/クエリの採用
    • トランザクション/集計/JOINなど不可
  • 利用データ

    • 大規模WEBサイトのバックエンドデータ(ユーザーセッション/ユーザー属性/事前計算データのキャッシュ)
    • メッセージングシステムのデータ(Twitterなど)
    • 大規模書き込みが必要なIoTセンサーデータなど
    • オンプレやソフトウェア:redis、riak
    • AWSサービス:ElastiCache、DynamoDB
  • データ構造 リレーショナルDBのテーブルとキーバリュー型のテーブルに分かれ以下のような概要図になります。

リレーショナルDBのテーブル

部門 場所 役職 名前
人事 豊洲 部長 佐藤
製造 新宿 課長 上原
総務 三鷹 社員 村上

キーバリュー型DBのテーブル

キー バリュー
1 名前:佐藤、部門:総務、場所:豊洲、役職:部長
2 名前:上原、部門:人事、場所:新宿、役職:課長
3 名前:村上、部門:製造、場所:三鷹、役職:社員
ワイドカラム型

ワイドカラム型は、キーに対しカラムを大規模に登録できる形式となります。
また、以下のようなポイントとなります。

  • 概要

    • 分散しシンプルなオペレーションを高速に実施できるDB
    • データ取得する際にデータ結合しなくても済むように可能な限り多くのデータを同じ行に保持
  • アーキテクチャ

    • 結果整合型を採用
    • キースペース、カラムファミリ、ロウ、スーパーカラム、カラムの入れ子構造
    • SQLライクなデータ操作が可能
    • データ操作は挿入、削除、参照のみが可能で、更新は挿入による上書き処理
  • 利用データ

    • オンプレやソフトウェア:cassandra、APACHE HBASE
    • AWSサービス:DynamoDB
  • データ構造

f:id:In-houseSE:20210623083756p:plain

ドキュメントDB

ドキュメントDBは、キーに対しドキュメント思考でXMLなどのデータを格納します。
また、以下のようなポイントとなります。

  • 概要

    • ドキュメント思考データベースは、様々なデータ構造のドキュメントを混在し保存
  • アーキテクチャ

    • JSON/XMLをデータモデルに利用
    • 小規模データの同期集計処理が可能だが、バッチ処理は不向き
    • SQLライクなデータ操作が可能で、KVSよりもクエリが豊富なため操作しやすい
    • Shardingによるデータベース分散化
  • 利用データ

    • 半構造化データ(XMLJSON)
    • 大規模WEBのログ保管
    • オンラインゲーム
    • カタログ管理
    • オンプレやソフトウェア:mongoDB、MarkLogic、CouchDB relax、Couchbase
    • AWSサービス:Amazon DocumentDB、mongoDB
  • データ構造

f:id:In-houseSE:20210623084759p:plain

インメモリデータグリット

インメモリデータグリットKVSの仕組みをメモリを利用し高性能にしたDBとなります。
また、以下のようなポイントとなります。

  • 概要

    • 大量データを多数のサーバのメモリ上で分散し管理する技術
    • ミリ秒単位の高速応答処理が可能
  • アーキテクチャ

    • データをメモリ上に置くことで、高速なデータアクセスを実現
    • データを多数のサーバで分散し管理
  • 利用データ

    • 金融の取引処理データでミリ秒以下の応答時間を実現
全検索型エンジン×分散DB

データの全検索エンジンであるElasticsearchは分散データベースと連携しデータ全検索処理が可能となります。
また、以下のようなポイントとなります。

  • 概要

    • 全検索型のデータ検索エンジンで、分散データベースと連携し検索データベースを構築
    • 抽出条件との関係性/関連性が高いデータを抽出し返す
  • アーキテクチャ

    • Elastisearchは全文検索用のライブラリ Apache Luceneを利用したデータストア
    • 分析の柔軟性や速度が高く、分析/蓄積/可視化環境を容易に構築可能
  • 利用データ

    • 半構造化データ(XML/JSON)
    • 高可用な全検索エンジン
    • サイト内データの検索
    • バイス登録状況/配信状況のリアルタイム可視化などリアルタイムの検索要件/検索行動の可視化
    • オンプレやソフトウェア:elasticsearch、kibana
    • AWSサービス:Elasticsearch Service
グラフDB

グラフDBは、グラフ構造でデータ間のつながりを検索・可視化するDBとなります。
データ構造のイメージはマインドマップのような形態をとります。
また、以下のようなポイントとなります。

  • 概要

    • グラフ演算に特化したDBで、データ間のつながりを検索/可視化に利用
  • アーキテクチャ

    • グラフデータ構造を取るため、RDB以上にスケールアウトができない
    • レコード数が増えると検索にかかる時間と難易度が増大
    • ACID特性が担保されており、オブジェクト間の関連づけを簡単に表現する
  • 利用データ

    • オンプレやソフトウェア:neo4j
    • AWSサービス:Amazon Neptune
分散OLTP(RDB)

分散OLTPは、オンライントランザクション処理(Online Transaction Processing)を分散化する次世代DBとなります。
また、以下のようなポイントとなります。

  • 概要

    • グローバルに分散され強整合性を備えたデータベース
  • アーキテクチャ

    • リレーショナルデータベースの構造と非リレーショナルデータベースの分散スケーラビリティを兼ね備える
    • 高い可用性、構成のトランザクションと強整合性が実現
  • 利用データ

    • 大規模な業務データ処理

DB種別とデータモデル

データ構造がシンプルなデータベースが分散しやすくビックデータ処理に向いています。

f:id:In-houseSE:20210701083231p:plain

データベースとAWSサービスの相関図

データべースの概念とAWSサービスの相関は以下のような図になります。

f:id:In-houseSE:20210701084528p:plain

今回のテーマは以上です。

SAA学習-Route53-小テスト

今回のテーマ:Route53-小テスト

設問1: プライベートホストゾーンの説明で誤っているもの

回答:1つのプライベートホストゾーンで1つのVPCに対応させる必要がある

設問2:パブリックホストゾーンについて誤っているもの

回答:VPCが相互アクセス可能であれば複数リージョンのVPCでも同じホストゾーンを利用可能

設問3:A社はグローバルにサービス展開されるアプリケーションをAWSで構築しようとしています。
ユーザーにとって最も応答速度が速いサーバーからアクセスできるようにルーティングを実行する非機能要件を満たすためのルーティングポリシー、

回答:レイテンシールーティング

設問4:エイリアス(ALIAS)レコードについて間違っている内容を選択してください。

回答:DNSで独自のドメインレコードを設定する際に用いる汎用レコードである。

cf)ALIASレコードはAWS独自のレコード方式

設問5:Route53を利用して複雑なルーティングポリシーを設定する際の機能と使い方の組合せとして正しいものを選択してください。

回答:トラフィックフローを用いて順序を設定することでルーティングポリシーを設定する

今回のテーマは以上です。