データベースの基礎
データベースは関連したデータの形式を揃えて収集、整理して検索などの操作やデータ管理を実行するシステム
データベースを実現したシステムをDBMS(データベースマネジメントシステム)という
基本的なデータベースはテーブルという形式でデータを格納している
データベースは追加・参照・更新・削除などのデータ操作を容易に実行するソフトウェアやデータモデルと一体
データベースとストレージ
ストレージはデータベースの記憶装置を構成する1つの要素
◾️ストレージ
・コンピュータの主要な構成要素の1つでデータを永続的に記憶する装置
◾️データベース
・データベース内のデータを保存する装置はストレージであるがデータベースそのものではない
・ストレージ+データを管理、操作するデータベースソフトウェア
データベースの役割
データベースはデータ操作を異常なく実行でき、データを安全に保護しつつ、保存、操作ができる仕組みを提供している
【データ操作にかかる様々な課題】
・システムがクラッシュした時にデータが消えないか
・データを誤って削除してしまった場合に対処できないか
・データ抽出に誤りが発生しないか
・2人が同時に同じデータにアクセスした際にどうするか
・大量のデータをうまく検索できないか
データベースの役割を支える仕組みを理解する
・トランザクション
データベースをある一貫した状態から別の一貫した状態へ変更する1つの処理の束のこと
・データモデル
実世界におけるデータの集合を、DBMS上で利用可能な形に落とし込むためのモデル
データベースをある一貫した状態から別の一貫した状態へ変更する1つの処理の束のこと
・同時アクセスした場合にうまく処理する
・データ処理に失敗したら元に戻してくれる
・システムがクラッシュしてもデータを保護する
ACIDは信頼性のあるトランザクションシステムの持つべき性質のこと
◾️Atomicity(原子性)
トランザクションが「全て実行される」か「1つも実行されない」のどちらかの状態になるという性質
◾️Consistency(整合性)
トランザクションの前後でデータの整合性が保たれ、矛盾のない状態が継続される性質
◾️Isolation(独立性)
トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質
◾️Durability(耐久性)
トランザクションが完了したら、その結果は記録されクラッシュしても失われることがないという性質
データを更新する際にCOMMITする更新が反映されるが、COMMITされないとデータがロールバックして保護する
同時に複数人がアクセスした場合などにデータ整合性を維持する必要がある
結果整合せや強い整合性など
データモデル
データベースには様々なデータモデルが存在し、利用目的に応じて使い分ける
・リレーショナルモデル
・グラフモデル
・キーバリューストア
・オブジェクト
・ドキュメント
・ワイドカラム
・階層型
データベースはリレーショナルDBか非リレーショナルDBかの大きく2種類ある
これまでのDB:リレーショナルDB
ビックデータ向けDB:NoSQL
リレーショナルDB
データベースの基本はリレーショナルDBシステム(RDBMS)
◾️概要
・データ間の関係性が定義されたデータを取り扱う一般的なDBシステム
・列と行がいくつかのテーブルで定義されていて、テーブル間のリレーションが設計される
・データ操作にSQLを利用
◾️利用データ
・会計データ / 顧客データといった構造化データ
NoSQL
IoTと同様にビックデータ解析にはNoSQLDBを利用する
◾️概要
・リレーショナルデータ構造を持たずSQLを利用しないDBの総称
・ただし、現在は似たクエリ処理を適用したモデルもある
◾️利用データ
・構造化されていないKeyとValueのみ(ID番号に1列に全データを格納)のKVSデータ
・動画 / 画像 / ドキュメントなどの非構造化データ
・XML / JSONなどの半構造化データ
キーに対するデータ形式の格納方式の違いで様々なタイプのNoSQLが存在する
◾️キーバリューストア
・キーに対してバリュー(値)を入れる単純な構造
・高速なパフォーマンスと分散型拡張に優れている
・データ読み込みが高速
◾️ドキュメントデータベース
・キーに対してバリューではなく、JSONやXMLなどのデータを格納
・複雑なデータ構造を扱うアプリで生産性高く柔軟に開発する
◾️ワイドカラムストア
・列指向とも呼ばれキーを利用するがデータはカラム(列)で管理する
・非構造データを大規模に格納することを目的にしている
・行ごとに任意の名前のカラムを無数に格納できる
◾️グラフデータベース
・グラフ理論に基づき、データ同士の関係をグラフで相互に結びついた要素で構成される
・RDBと比較して高速横断検索が可能
ビックデータ活用
データの特徴に応じて利用するデータベースを選択する
◾️DWH(構造化データ)
売上分析 / 財務分析など目的に沿った業務データ分析
◾️アーカイブ(構造化アーカイブデータ)
データウェアハウスだけでは不可能だった長期過去データを活用した業務データ分析
◾️半構造化DB(半構造化データ)
IoTデータなどの膨大なビックデータを活用した分析 / 人工知能構築
◾️非構造化DB(非構造化データ)
非構造化データを利用したデータ分析 / 人工知能構築
リレーショナルDB(RDB)
業務システム向けのDBの基本はリレーショナルデータベース
◾️概要
・業務システムなどで最も頻繁に利用されるオペレーション用のデータベース
・利用者はSQLなどのクエリ言語でデータ操作を実施
◾️アーキテクチャ
・テーブル間のリレーションが定義されたデータモデル
・行指向で1つの行をデータの塊として取り扱う
◾️利用データ
・会計データなどの業務系の構造化データ
データウェアハウス(DWH)
構造化データを利用した経営分析向けのデータベース
◾️概要
・データの抽出、集約に特化したBIデータ分析用のデータベース
・読み込みデータ構造を予め設計して、加工してから利用分のデータを蓄積
・レスポンス重視でデータ抽出、集計が早いが、更新、トランザクションは遅い
◾️アーキテクチャ
・データをパーティショニングして、複数ディスクから読み込む
・列指向でデータを格納
◾️利用データ
・会計データなどの業務系の構造化データを分析用に加工し、BIで利用
・KPI測定 / 競合分析 / アクセス分析など
分散型DB / データレイク
ビックデータやIoTデータを蓄積して高速処理を可能にするDBとストレージの組み合わせ
◾️概要
・データ抽出に特化したDB
・分散してデータを保存しており、ビックデータの高速処理向け
◾️アーキテクチャ
・SQLライクなクエリで操作可能
・INSERT / UPDATE / DELETEはない
・トランザクションはない
・データ書き込みは一括ロードまたは全件削除のみ
◾️利用データ
・ビックデータ
KVS:キーバリュー型
シンプルなデータ構造にすることで高速処理を可能にしたDB
◾️概要
・分散してシンプルなオペレーションを高速に実施できるDB
◾️アーキテクチャ
・強い整合性を犠牲にして結果的な整合性を採用
・分散向けのデータモデル / クエリの採用
・トランザクション / 集計 / JOINなど不可
◾️利用データ
・大規模WEBサイトのバックエンドデータ(ユーザーセッション / ユーザー属性 / 事前計算データのキャッシュ)
・メッセージングシステムのデータ
・大規模書き込みが必要なIoTセンターデータなど
ワイドカラム型
キーに対してカラムを大規模に登録できるのがワイドカラム型
◾️概要
・分散してシンプルなオペレーションを高速に実施できるDB
・データ取得する際にデータ結合しなくても済むように可能な限り多くのデータを同じ行に保持
◾️アーキテクチャ
・結果整合性を採用
・キースペース、カラムファミリ、ロウ(スーパーカラム)、カラムの入れ子構造
・SQLライクなデータ操作が可能
・データ操作は挿入、削除、参照のみでデータ更新は挿入による上書き
◾️利用データ
・Facebook / Twitterなどソーシャルデータの位置情報データストレージ / リアルタイム分析 / データマイニング処理
ドキュメントDB
キーに対してドキュメント指向でXMLなどのデータを格納する
◾️概要
・ドキュメント指向データベースでは、様々なデータ構造のドキュメントを混在して保存することができる
◾️アーキテクチャ
・JSON / XMLをデータモデルに利用
・小規模データの同期集計処理が可能だが、バッチは不向き
・SQLライクなデータ操作が可能でKVSよりもクエリが豊富なため操作しやすい
・Shardingによるデータベース分散化
◾️利用データ
・半構造化データ(XML / JSON)
・大規模WEBのログ保管など
・オンラインゲームデータ
・カタログ管理
インメモリデータグリッド
KVSの仕組みをメモリを利用してより高性能にしたDB
◾️概要
・大量のデータを多数のサーバーのメモリ上で分散して管理する技術
・ミリ秒単位の高速の応答処理が可能
◾️アーキテクチャ
・データをメモリ上に置くことで高速なデータアクセスを実現
・データを多数のサーバーで分散して管理
◾️利用データ
・金融の取引処理データでミリ秒以下の応答時間を実現
全検索型エンジン×分散DB
データの全検索エンジンであるElasticsearchは分散データベースと連携してデータ全検索処理が可能
◾️概要
・全検索型のデータ検索エンジンで分散データベースと連携して検索データベースを構築
・検索条件との関係性 / 関連性が高いデータを抽出して返す
◾️アーキテクチャ
・Elasticsearchは全文検索用のライブラリApache Luceneを利用したデータストア
・分析の柔軟性や速度が高く、分析 / 蓄積 / 可視化環境を容易に構築可能
◾️利用データ
・半構造化データ(XML / JSON)
・高可用な全文検索エンジンn
・サイト内データの検索
・デバイス登録状況、配信状況のリアルタイム可視化などリアルタイムの検索要件 / 検索行動の可視化
グラフDB
グラフ構造でデータ間のつながりを検索、可視化するDB
◾️概要
・グラフ演算に特化したDBでデータ間のつながり方を検索、可視化に利用
◾️アーキテクチャ
・グラフデータ構造を取るためRDB以上にスケールアウトができない
・レコード数が増えると検索にかかる時間と難易度が増大
・ACID特性が担保されており、オブジェクト間の関連付けを簡単に表現できる
◾️利用データ
・最短経路検索
・金融取引の詐欺検出
・ソーシャルネットワークによるリレーション計算
分散OLTP(RDB)
オンライントランザクション処理(Online Transaction Processing)を分散化する次世代DB
◾️概要
・グローバルに分散され、今日整合性を備えたデータベース
◾️アーキテクチャ
・リレーショナルデータベースの構造と非リレーショナルデータベースの分散スケーラビリティを兼ね備える
・高い可用性、高性能のトランザクションと強整合性が実現
◾️利用データ
・大規模な業務データ処理
DynamoDB
完全マネージド型のNoSQLデータベースサービス
・ハイスケーラブルで無制限に性能を拡張できる
・負荷が高くなっても応答時間が低下しない低レイテンシー
・高可用性(SPOFなしでデータは3箇所のAZに保存)
・マネージド型のためメンテナンスフリー:CloudWatchで運用
・プロビジョニングスループット
テーブルごとにReadとWriteに必要なスループットキャパシティを割り当てる
例:Read:100 / Wirte:1000
・ストレージの容量制限がない
データ容量の増加に応じたディスクやノードの増設は一切不要
DynamoDBのできること
キーバリュー(ワイドカラム型)でデータを容易に操作することが主要な役割
◾️できること
・キーに対するバリュー(値)のCRUD操作
・簡易なクエリやオーダー
・例えば、数万人以上が同時アクセスして処理が必要になるアプリケーションのデータ処理など
◾️できないこと
・JOIN / TRANSACTION / COMMIT / ROLLBACKは不可
・詳細なクエリやオーたー(データの検索や結合処理などには向いていない)
・大量のデータ読み書きにはコストがかかる
DynamoDBの整合性モデル
デフォルトで結果整合性モデルであり、一部処理に強い整合性モデルを利用している
◾️Write
少なくとも2つのAZでの書き込み完了が確認取れた時点で完了
◾️Read
・デフォルト:結果整合性モデル
最新の書き込み結果が即時読み取り処理に反映されない可能性がある
・オプション:強い整合性モデル
GetItem / Query / Scanでは強い整合性のある読み込みオプションが指定可能
パーティショニング
大量データを高速処理するためにパーティションニングによる分散処理を実施している
ビックデータ処理向けか大量データ処理が必要なアプリケーション向けに利用する
◾️ビックデータ
・大量のデータを収集、蓄積、分析するためのデータベースとして活用
・Hadoopと連携してビックデータ処理が可能
◾️アプリケーション
・大規模サービスでのデータ高速処理が必要なアプリケーション向けに活用
・多数のユーザーが一度にアクセスするようなアプリケーションのデータ処理など
例えば大量に発生しうるWEB行動データやログ管理など
◾️ユーザー行動データ管理
ユーザー情報やゲーム、広告などのユーザー行動データ向けDB
ユーザーIDごとに複数の行動履歴管理
◾️バックエンドデータ処理
モバイルアプリのバックエンド / バッチ処理のロック管理 / フラッシュマーケティング / ストレージのインデックス
テーブル設計
DynamoDBはテーブル単位から利用が開始され、テーブル→項目→属性と設計する
◾️テーブル
DynamoDBはテーブルはデータのコレクションのこと
他のDBと同様にテーブル単位にデータを保存する
◾️項目(アイテム)
各テーブルの中に項目を作ってデータを作成する
項目間で一意に識別可能な属性グループとなる
Personalという項目を作成すれば、名前やIDなどが属性として付属する
◾️属性
各項目は1つ以上の属性で構成される
属性はそれ以上分割する必要がない最小のデータ単位
例えばPersonal項目には、妙名といった名前の属性を設定する
インデックス
DynamoDBは暗黙的に設定するKVSにおけるKeyに値するものと、明示的に設定するキーがインデックスとして利用できる
◾️暗黙的なキー
データを一意に特定するために暗黙的にキー(ハッシュキーやレンジキー)として宣言して検索に利用するインデックスで、1テーブルに1つ宣言する
◾️明示的なキー
・ローカル、セカンダリ、インデックス(LSI)はプライマリキーのタイプがハッシュキーやレンジキーの場合に追加で別のレンジキーを増やすようなイメージ
1テーブルに5つ作成可能 / テーブル作成時に作成
・グローバル、セカンダリ、インデックス(GSI)は別のハッシュキーを設定することができる
全データに対してグローバルに付与
1テーブルに5つ作成可能 / テーブル作成後に作成
プライマリキー
DynamoDBはハッシュキーとレンジキーという2種類のプライマリキーを利用する
◾️ハッシュキー
・KVSにおけるキーに相当するデータを一意に特定するためのIDなどのこと
・テーブル作成時に1つの属性を選び、ハッシュキーとして宣言
・ハッシュ関数によってパーティションを決定するためハッシュキーと呼ぶ
・ハッシュキーは単独での重複を許さない
◾️レンジキー
・ハッシュキーにレンジを加えたものをレンジキーまたは複合キーと呼ぶ
・テーブル作成時に2つの属性を選び、1つをハッシュキーと呼ばれるキーとして宣言
・2つの値の組合せによって、1つの項目を特定
・複合キーは、単独であれば重複が許される
明示的に利用するインデックス
ハッシュキーやレンジキーだけでは検索要件が満たせない場合にLSIとGSIを利用する
◾️Local Secondary Index(LSI)
・レンジキー以外で絞り込み検索を行うインデックスで複合キーテーブルに設定できる
・複合キーによって整理されている項目に対して、別の規則でのインデックスを可能にする
◾️Global Secondary Index(GSI)
・ハッシュキーの属性の代わりになる
・ハッシュキーテーブルおよび複合キーテーブルどちらにでも設定可能
・ハッシュキーをまたいで自由に検索できるようにする
DynamoDB Streams
DynamoDBテーブルに保存された項目の追加、変更、削除の発生時のリレくをキャプチャできる機能
◾️データの保存
・過去24時間以内のデータ変更の履歴を保存し、24時間を経過すると消去される
・データ容量はマネージド型で自動的に管理
◾️データ保存の順番
・操作が実施された順番に応じてデータはシリアライズされる
・特定のハッシュキーに基づいた変更は正しい順番で保存されるが、ハッシュキーが異なる場合は受信した順番が前後される可能性がある
DynamoDB Streamsのユースケース
データ更新をトリガーとしたアプリケーション機能やレプリケーションに活用できる
◾️クロスリージョンレプリケーション
・ストリームによるキャプションをトリガーとしてクロスリージョンレプリケーションを実施することが可能
◾️データ更新をトリガーとしたアプリケーション機能
・データ更新に応じた通知書りなどのアプリケーション処理の実行など
DynamoDB Accelerator(DAX)
DAXはDynamoDBにインメモリキャッシュ型の機能を付加する
DynamoDBにおいて高速なインメモリパフォーマンスを可能に
・インメモリキャッシュとして1桁台のミリ秒単位からマイクロ秒単位まで結果整合性のある読み込みワークロードの応答時間を短縮
マルチAZDAXクラスターは1秒間に数100万件のリクエストを処理できる
・DAXはDynamoDBを使用するAPIと互換性をもつマネージド型サービスであり、運用上そしてアプリケーションの複雑性を減少させて容易に導入可能
・読み取りの多いワークロードや急激に増大するワークロードに対して、DAXはスループットを強化したり、読み込みキャパシティーユニットを必要以上にプロビジョニングしないよう設計することで運用コストの節約できる
グローバルテーブル
リージョン間で同期されるマルチマスターテーブル作成可能
・DynamoDBの性能のまま、世界中で複数のリージョンにエンドポイントを持つことができる
・読み書きのキャパシティに加えて、クロスリージョンレプリケーションのデータ転送料金に課金される
・オプションで実施できた強い整合性は不可
オンデマンドバックアップ
パフォーマンスに影響なく数百TBのバックアップを実行可能
・任意のタイミングで利用可能な長時間データ保存用バックアップ
・従来はデータパイプラインを利用して取得したバックアップを容易に実施できるようになった
Read / Writeiキャパシティオンデマンド
キャパシティ設定不要でリクエストに応じた課金設定を選択できるようになった
・トラフィック量の予測が困難な場合にリクエストの実績数に応じて課金
・オンデマンドでRead / Write処理に自動スケーリングを実施
・プロビジョンドキャパシティ設定への変更は無制限
・オンデマンドへの変更は1日1回まで
Auroraの概要
クラウド時代の新しい分散型のリレーショナルデータベースとして誕生
・Amazonがクラウド時代に適したリレーショナルDBを1から考えて構築された新RDB
・その特徴はNoSQL型の分散高速処理とRDBとしてのデータ操作性を両立させたこと
MySQLと2.5〜5倍の性能を商用データベースの10分の1の価格で提供する高性能・低コストDB
Auroraの特徴
高い並列処理性能によって大量の読み書きをするのに適したDB
・高い並列処理によるストレージアクセスによってクエリを高速処理することが可能
・Auroraは大量の書き込みや読み込みを同時に扱うことができる
・データベースの集約やスループット向上が見込まれる
・ただし、すべてが5倍高速という訳ではなく、適用すべき領域を見つけて利用する
MySQL / PostgreSQLと互換性があり、同じ操作方法とそのコミュニティを利用することが可能
分散型で耐障害性と自己回復性を備えたスケーラブルな新しいタイプのフルマネージド型RDB
◾️耐障害性 / 自己回復性
・3つのAZに2つのコピーを設置可能で合計6つのコピーを保持
・過去のデータがそのままS3に継続的にバックアップ
・リストアも差分適用がなく高速
・99.99%の高可能性、高耐久性
◾️スケーラビリティ
・10GBから最大64TBを提供するSSDデータプレーンを利用してシームレスに拡張可能
・Auto-Scalingなどのクラウド独自のスケーラブルが可能
・最大15のリードレプリカを利用した高速読み込みが可能
Auroraサーバレス
予測困難なアプリケーションワークロードに対応したAuroraのオンデマンド自動スケーリング構成
・自動に起動 / シャットダウン
・自動でスケールアップ / スケールダウン
AuroraグローバルDB
他リージョンに対する高性能なリードレプリカ作成機能
・ログ転送ではなく、ストレージレベルのレプリケーション機能を利用してレプリケーションを実施
・概ね1秒以下 / 最大でも5秒でレプリケーションを実行する低レイテンシーレプリケーションを実現
大規模なクエリ処理が発生するRDB環境などをAuroraへの移行を検討すべし
◾️大規模なクエリデータ処理
・書き込みが多くでトランザクション量が多い
・クエリ並行度が高い、データサイズが大きいケースで効果を発揮する
・コネクション数やテーブル数が多いデータベース処理
◾️運用の容易さを活用する
・スケーラビリティの高さやデータ容量が無制限に拡張できる
・レプリケーションなどの性能の高さ
EFSの概要
EFS(Elastic File System)
複数のEC2インスタンスからアクセス可能な共有ストレージ
◾️S3
・オブジェクトストレージでリージョンに設置
・HTTPによるAPI経由でアクセス
・大容量のデータを長期保存するためのもの
◾️EBS
・ブロックストレージでAZに設置
・EC2インスタンスのディスクボリュームとして利用する
・複数のEC2インスタンスにアタッチできない
◾️EFS
・NASに似たファイルストレージ
・ファイルシステムとして利用し、複数のEC2インスタンスでの共有アクセスが可能
その特徴はシンプルでスケーラブルで柔軟に利用できるファイルストレージであること
◾️シンプル
・フルマネージド型サービス
・ネットワークファイルシステムバージョン4(NFSv4)プロトコルを利用して、関連ツールや標準プロトコル / APIでアクセス可能
◾️スケーラブル
・ペタバイトまでスケーラブルにデータを蓄積
・スループット / IOPS性能は自動的にスケーリングし、低レイテンシーを維持
◾️柔軟性
・ファイルの減少に合わせて自動で拡張、縮小
・事前に容量を設定する必要なし
・使った分だけの従量課金
基本性能
何千もの同時アクセスが実現可能という性能が特徴的
◾️基本性能
・基本性能は100MB(バースト込み)
・ファイル名は255バイト
・1ファイルの最大容量48TB
・インスタンスあたり128ユーザーまでの同時オープンが可能
・何千もの同時アクセスが実現可能
◾️制限
・アカウントあたりのファイルシステム数:1000
・AZごとのファイルシステムあたりのマウントターゲット:1
・ファイルシステムあたりのタグ:50
・マウントターゲットあたりのセキュリティグループ:5
・ファイルシステムあたりのVPC数:1
・各VPCのマウントターゲット数:400
EFSのデータ保存
EFSのデータファイルは複数AZに分散して保存されている
マウントターゲット
EC2インスタンスからの接続先のマウントターゲットを設定
・VPC内のAZにある接続先
・EC2インスタンスは同じAZ内にあるマウントターゲットから接続する
・固定のDNS名とIPアドレスを有している
・ファイルシステムDNS名を使用してマウントすることで自動でIPアドレスを付与
パフォーマンスモード
汎用モードと最大I/Oモードから選択
基本は汎用モード
◾️汎用モード
・一般的な用途を想定したモード
・デフォルトでは汎用モードとなり推奨されている
・レイテンシーが最も低い
・1秒あたりのファイルシステム操作を7000に制限
◾️最大I/Oモード
・何十〜何千というクライアントからの同時アクセスが必要な大規模な構築に利用
・合計スループットを優先してスケールする
・レイテンシーが多少長くなる
バースト機能
ファイルストレージの負荷に応じてバースト機能によってスケーラブルに対応
◾️バースト
一時的な大量トラフィックの発生やそれに伴いサーバなどの処理性能が一時的に向上する
◾️バーストスループットモード
ファイルシステムが大きくなるに従ってAmazonEFSによってスループットが拡張
◾️クレジットシステム
クレジットシステムによりファイルシステムがバーストできる時期を判断する
各ファイルシステムは時間の経過とともにクレジットを蓄積していき、データを読み書きするたびにクレジットを使用する
・容量に応じたバースト性能
1TB以上の容量に応じて性能が向上する
最大で1GBまでバースト
・容量に応じてクレジットの蓄積量とスループット性能も向上する
EFSクライアント
EFSをEC2インスタンスから操作する際に専用のクライアントソフトウェアを利用する
Amazon-efs-utilsに含まれるEFSマウントヘルパー
Linux NFSv4クライアント
ユースケースに応じてプロビジョンドスループットも利用
◾️バーストのスループット
・ピーク時にクレジットを消費してバーストを実行して一時的な性能を向上させる方式
・最大スループットとバースト時間に制限がある
・スループット性能向上にはストレージ容量の増大が必要
◾️プロビジョンドスループット
・一貫したスループットを事前に設定する方式
・API / AWS CLI / マネージメントコンソールにより制御
・1日に1回だけスループット性能を減少できる
複数EC2インスタンスでデータ共有する際はEFSをファーストチョイスする
◾️利用方針
・EBSではできない複数インスタンスからの同時アクセスが必要
・数秒単位でのデータ追記が必要
・フルマネージドで運用して簡易に利用していきたい
◾️利用シーン
・アプリケーションの共有ディレクトリとして利用
・ビックデータなどの分散並列処理環境における共有データアクセスストレージとして利用
・コンテンツの共有リポジトリとして利用
3つのファイルストレージ
EFS以外にもユースケースに応じてFSxタイプのファイルストレージが2タイプ利用可能
◾️EFS
・NASに似たファイルストレージ
・ファイルシステムとして利用し、複数のEC2インスタンスでの共有アクセスが可能
・S3と異なりインターネットから直接アクセスできない
◾️Amazon FSx For Windouws File Server
・Windouws File Serverと互換性のあるストレージ
・Windouws上に構築され、Windouws AD、OSやソフトウェアとの連携が豊富に可能
◾️Amazon FSx For Lustre
・分散型ファイルストレージであるオープンソースLusterと互換性のある分散型の高速ストレージ
・機械学習などの高速コンピューティングのデータレイヤーに利用する一時保存用の処理用ストレージ
Amazon FSx For Windouws File Server
Amazon File ServerをAWSクラウド上で利用したい場合に利用するストレージ
◾️特徴・ユースケース
・Windouws File Serverのクラウド移行
・Active Directory(AD)統合などの幅広い管理機能
・SMBプロトコルによりAmazon EC2、VMware Cloud on AWS、Amazon WorkSpaces、Amazon AppStream2.0インスタンスなど幅広く接続可能
・最大数千台のコンピューてイングインスタンスからアクセス可能
◾️アーキテクチャ構成
・ENI経由でアクセス
・VPCセキュリティグループでの制御
・単一AZの単一サブネットを指定して構成する
・複数インスタンスでの共有や他AZ内のインスタンスからのアクセスも可能
・マルチAZ構成を実施することもできる
高速コンピューティング処理を実現する分散・並列処理専用の超高性能ストレージを提供
◾️特徴・ユースケース
・多くのスーパーコンピュータに利用される分散ファイルシステム
・フルマネージド型で安全にLusterを利用
・最適容量3600GB
・最大数百GB / 秒のスループット
・数百万IOPSまでスケール可能
◾️アーキテクチャ構成
・ENI / エンドポイント経由でアクセス
・セキュリティグループで制御
・単一AZの単一サブネットを指定して構成する
・Amazon S3とシームレスな統合によりデータレイク型のビックデータ処理や解析ソリューションに組み込む
増大するデータ量への対応
IoT / ビックデータなどで絶えず増加するデータの保持の効率的に実施する
◾️関連する主要サービス
・S3、Kinesis、Glacier、Glue、Athena、EMR、QuickSight、Redshift
増大するデータ
WEBの発展によるビックデータ蓄積とIoTの発展によるIoTデータ蓄積によりデータ量が大きく増大
データ量への対応
効率的なデータ蓄積とIoTなどの大量のストリームデータ処理や解析の方法が必要不可欠となる
AWSは大量なデータ処理への各段階において必要なサービスが提供されている
①効率的なデータ蓄積
S3、Glacier、Glue
②ストリームデータ処理
Kinesis
③大量データの解析手法
Athena、EMR、QuickSight、Redshift
ビックデータに必要な技術
ビックデータに対応したデータ蓄積・処理技術が必要不可欠
・大量のデータを効率的に蓄積可能なデータベース技術
・多様な形式のデータを蓄積可能なデータベース技術
・高速処理が可能なデータ処理ソフトウェア / ハードウェア
データレイクの活用
ビックデータ活用の中心はデータレイク型データベース
◾️データウェアハウス中心
利用用途に応じたデータをためて活用するデータウェアハウス
◾️データレイク中心
出来る限り生データをほぼ全データ保存するデータレイク
データレイクでは全データを生データのまま保存する
ビックデータ分散処理向けの代表的な仕組み(ミドルウェア)がApacheシリーズ
◾️大量データバッチ処理向け
Apache Hadoop
◾️ストリーミング処理向け
Apache Spark
ストリームデータを収集・処理するためのフルマネージド型サービスで主に3つのサービスで構成される
◾️Amazon Kinesis Data Streams
ストリームデータを処理するアプリケーションを構築
◾️Amazon Kinesis Data Firehose
ストリームデータをS3やRedshiftなどへ簡単に配信
◾️Amazon Kinesis Data Analytics
ストリームデータを標準的なSQLクエリでリアルタイムに可視化・分析
ストリームデータ処理用の分析システムやアプリケーションを構築するサービス
Iotデータ → Kinesis Streams → Spark Streaming → アプリケーション
ストリーミング処理をシャードに分けて分散させて実行するため高速処理が可能
Kinesis Streamsのデータ提供側(プロデューサー)とデータ利用側(コンシューマー)に様々なサービスが利用可能
Kinesis Streamsは次の関連機能を活用してストリーミング処理アプリケーションを構築する
◾️Amazon Kinesis Agent
Kinesisサービスにデータを簡単に収集して取り込むOSSのスタンドアロンJavaアプリケーション
◾️Amazon Kinesis Producer Library(KPL)
Kinesis Streamsにデータを送信するOSSの補助ライブラリ
◾️Fluent plugin for Amazon Generator(KDG)
Kinesis Data Generator(KDG)を利用してKinesis StreamsまたはKinesis Firehoseにテストデータを簡単に送信する
◾️Amazon Kinesis Client Library(KCL)
KCLを利用してKinesisアプリケーションを作成する
OSSのクライアントライブラリでEC2インスタンスなどにデプロイして利用する
各種DBに配信・蓄積するためのストリーム処理を実施する
Lambdaと連携するとETLとしても機能する
ストリームデータを標準的なSQLクエリでリアルタイムに分析
Redshiftの概要
高速でスケーラブルな費用対効果の高いマネージド型のDWH / データレイク分析サービス
・数百ギガバイトのデータから開始して、パタバイト以上まで拡張
・1テラバイトあたり年間1,000USD以下で利用可能
・自動ワークロード管理など自動テーブルメンテナンスなど多くのメンテナンススタンスやデータ配置が自動化されているフルマネージド型
・PostgreSQL互換の列指向データモデル
・複数ノードをまとめたクラスター構成
単一AZで起動し、マルチAZ構成は不可
・RA3インスタンスで最大で他のクラウドデータウエアハウスの3倍に達するパフォーマンス
・AQUAによる分散キャッシュでRedshiftが他のクラウドデータウェアハウスに比べて最大10倍の速度で動作
データウェアハウス(DWH)
構造化データを利用した経営分析向けのデータベース
◾️概要
・データ抽出、集約に特化したBIデータ分析用のデータベース
・読み込みデータ構造をあらかじめ設計して、加工してから利用分のデータを蓄積
・レスポンス重視でデータ抽出、集計が早いが更新、トランザクションは遅い
◾️アーキテクチャ
・データをパーティショニングして複数ディスクから読み込み
・列指向でデータを格納
◾️利用データ
・会計データなどの業務系の構造化データを分析用に加工し、BIで利用
・KPI測定 / 競合分析 / アクセス分析など
利用するデータサイズと増加予測に応じて2つのインスタンスタイプから選択
◾️RA3インスタンス
・コンピューティング性能とマネージドストレージのスケーリングと支払いを独立させることで、データウェアハウスを最適化
・データ量の増大が予測される場合は、RA3ノードのご利用を推奨
・最低2ノード必要
・最安で$3.836 / ノード /時
◾️DC2インスタンス
・固定ローカルSSDストレージを使用してデータウェアハウス
・データのサイズ増加に対し、ノードを追加して、クラスターのストレージ容量を増強
・未圧縮で1TB未満のデータセットではDC2ノードタイプの利用を推奨
・最低1ノード必要
・最安で$0.314/ ノード / 時
Redshiftとは
列指向型のリレーショナルデータベースであり、データを分散・高速処理が可能な仕組みとなっている
◾️列指向のRDB
・列指向型ストレージにデータを格納するリレーショナルデータベースのデータモデルを採用
・大容量のデータアクセスを容易にしてディスクI/O効率化
◾️データ圧縮
・データ圧縮によって一度に読み込めるデータ量が多くなることで処理を高速化
・分析ワークロードでブロック単位でデータを格納して、ディスクI/O効率化
◾️ソート
・データが格納されているブロックに対してメタデータを付与して検索値とする
・リーダーノードのインメモリ上にメタデータを格納
・データのソート順をテーブルごとにソートキーとして指定
◾️データ分散
・データ量とクエリ内容に応じてノードに対する分散処理を調整し、効率的で高速な処理を実現
・キャッシュによる高速化
頻繁に実行するクエリパターンを結合・フィルタ・集計・射影によって高速化する機能
運用の自動化
自動的なメンテナンス機能と詳細のモニタリングによる簡易な運用が可能
◾️CloudWatchとの連動
・初期設定でCloudWatchメトリクス取得が自動で実施され、RedShiftコンソール内で確認可能
◾️自動バックアップ
・自動でバックアップを定期取得する
・メンテナンスウィンドウでバックアップ実施時間を指定可能
・スナップショットを手動で取得することも可能
◾️自動メンテナンス
・パッチ適用も自動で実施
・メンテナンスウィンドウでパッチ適用時間を指定可能
◾️スケジューリング機能
・クラスターサイズの変更を設定
・クラスターの一時停止と再開を設定
機械学習によるクエリ効率化
機械学習によってクエリ実行を調整し効率的な自動実行を補助してくれる
◾️テーブルメンテナンスの自動化
・テーブル分散化スタイルの自動最適化
・統計情報の自動更新
・データの再編成の自動実行
◾️自動ワークロード管理
・複数クエリの実行をワークロード管理で設定する際に、機械学習でクエリ実行の優先順位決めを自動化する
◾️ショートアクセスレーション
・機械学習アルゴリズムを使用して対象のクエリを1つ1つ分析し、クエリの実行時間を予測し実行時間が短いクエリを実行時間が長いクエリよりも優先して実行
・WLMキューを削減可能
◾️設定のレコメンデーション
・自動でクラスターパフォーマンスなどを分析し、最適化やコスト削減に対するレコメンデーションを実施
ワークロード管理(WLM)
ワークロードに応じて複数のキューを設定し、クエリ割り当てルールに基づいてキューを設定し、優先順位を設定可能
クエリエディタ
マネジメントコンソール画面からRedShiftデータベース接続してクエリを実行可能
スケーリング
RedShiftはノードのタイプ変更、追加とクラスターの追加によってスケーリング可能
◾️ノードの追加
コンピューティングノードを追加することでパフォーマンスを向上
◾️クラスターの追加
ConcurrencyScalingにより急な同時実行リクエストに対応するために一時的なクラスタを自動的に数秒で追加し、一貫して高速なパフォーマンスを発揮(追加クラスターは1〜10)
Redshift Spectrum
Redshift Spectrumにより、ユーザーが管理するS3バケットに対して直接データ解析を実行可能
データ連携(To Redshift)
Redshiftへとデータ移動させることでDWHとしての解析基盤を集約化することが重要
◾️S3
・最も頻繁に使われるデータ連携先であり、S3からデータを取得してRedshiftで解析することも可能であるし、S3内部のデータ解析を直接実行することも可能
◾️Kinesis
・Kinesis data Firehoseを利用してストリーミングデータの格納先としてRedshiftを指定してデータを保存して、解析に利用することが可能
◾️RDS
・RDSとの直接接続はないが、AWS Data PipelineやDMSを利用してデータ移行を実施可能
◾️DynamoDB
・DynamoDBからRedshiftにデータコピーを実行可能
◾️Amazon EMR
・EMRからRedshiftにデータコピーを実行可能
データ連携(From Redshift)
RedshiftからはQuickSightを利用したデータ可視化に加え、S3へとデータ抽出も可能
◾️Amazon QuickSight
・Redshiftに接続して、データの可視化を実施可能
◾️S3
・UNLOADコマンドを実行することで、ReshiftからS3へとデータを抽出することが可能
◾️Amazon Machine Learning
・Redshiftを機械学習の学習データとして設定して利用可能
◾️RDS
・直接に連携はできないが、PostgreSQLの機能を利用してデータをRedshiftからRDSと連携可能
データを可視化・解析するためのBIツール
Redshiftデータを可視化可能
データを抽出、変換、ロード(ETL)を行う完全マネージド型のサービス
AWS Lake Formation
本来なら複雑な設定が必要なデータレイクの構成を簡単に素早く実現するサービス
Apache Spark、Apache Hive、Prestoなどのビックデータフレームワークを使用して大量データを処理・分析する