はじめに

2021年6月現在の話。
DynamoDBについてUdemyの講座ではTRANSACTIONが不可と紹介されていたが、実際は2018年頃に可能になっていたようだ。
Amazon DynamoDB Transactions: 仕組み

講義のスライドは載せられないが、はっきりと不可と書いてあり、講師によるとDynamoDBはNoSQLなので複雑な処理を伴うユースケースではそもそも向いていない意図で不可と書いたそうだが、それならTRANSACTIONを伴う処理には不向きと書くべきで、適切ではないと感じた。

トランザクションってなんだっけ？

よくもやもやするので整理をしておく。
データベースをある一貫した状態から別の一貫した状態へと変更する一連の処理を1つの束として見るという手法。
データベースを扱う上で

同時アクセスした場合の処理(整合性の問題)
処理中のエラーやデータベース依存ではない障害に対しての処理の中断と復元、及び保護の問題

という以上の2点の問題はつきものであるということは私のような初心者でもわかる。
なので、ある程度語弊を覚悟でざっくり言ってしまうとこのトランザクションという仕組みがあることで

同時アクセスに対してはAとBどちらの束を優先させるかを決定して一貫性と整合性を保つ
一連の処理を束とみているからこそ、処理のどこかでエラーや障害が起きた場合はその処理は実行されずロールバックされることで元のデータは保護される

という対策を取れることになる。
ただし、これは反面処理に遅延をかけていることにもなるので逆にトランザクションを保証しないことで高速処理を担保するという仕組みのDB程度も存在する。

ACID

ACID(Atomicity Consistency Isolation Durability)は信頼性のあるトランザクションシステムの持つべき性質の頭文字をあわせたもの。

Atomicity(原子性)……トランザクションの状態は「処理がすべて実行される」か「処理が一つも実行されない」のどちらかにしかならないという性質
Consistency(整合性)……トランザクションの前後でデータの整合性が保たれ、矛盾のない状態が継続されるという性質
Isolation(独立性)……トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質
Durability(耐久性)……トランザクションが完了したら、その結果は記録され、クラッシュしても失われることがないという性質

整合性の話

整合性はレベルがあって色々と良し悪しがある。
例えば結果整合性であれば

変更中のデータが完了していない状態でも、当該データの変更前の状態は確認できる
ただし、上記のケースではデータの整合性という意味では弱い
けれどもDBの処理の負荷は整合性を強くした場合よりは低い

ここから整合性を強くすると以下のケースが考えられる。

変更中のデータに対して、完了するまでは参照はできない。DBの処理負荷も高くなる。
ただし、データの整合性は高くなる

データベースのタイプについて

なんとなくは知っているけれどおさらいしておく。

リレーショナルDB

その名の通りデータ間の関係性を定義していくことでデータを構造化して取り扱うDBシステム
各列(カラム)のデータが集まった1行のレコードを集めたテーブルを構成し、そのテーブル間で関係性(リレーション)を設計していく
SQLで操作する
行指向(データをカラムで表現してその集合を1行として取り扱う)
会計データ、顧客データといったものに向いてる
ORACLE、MySQL、PostgreSQL、SQL Server、RDS等が該当

NoSQL

リレーショナルデータ構造を持たず、SQLを利用しない(SQLに似たクエリ処理を使う感じ)
大きな特徴として非構造化(テキスト・動画・音声・画像)・半構造化(XML・JSON・文書)という2パターンでデータを格納する
KVSデータ(Key(ID)に対してValue(データ)のみというデータ方式)、非構造化データ、半構造化データを扱う場合に利用する。
ビッグデータ解析に用いることができる

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

データの抽出・集約に特化したBIデータ(ビジネスインテリジェンスデータ、ビジネスの意思決定に関わるデータの総称らしい)分析用のデータベース
読み込むデータ構造を予め設計・加工してから利用するデータの蓄積を開始する
レスポンス重視でデータ抽出・集計は早いが、更新・トランザクションは遅い
データはパーティショニングされ、複数のディスクから読み込まれる
RDBの一種であるが、分析に特化するために敢えて列指向でデータが格納している
構造化データを利用した経営分析向けのデータベースである
会計データなどの業務系の構造化データを分析用に加工し、BIとして利用する
利用例としてはKPI(Key Performance Indicator、重要業績評価指標)測定、競合分析、アクセス分析など
ORACLE Exadata、VERTICA、TERADATA、Greenplum、Redshiftなどが該当

分散型DB/データレイク

ビッグデータ、IoTデータの蓄積と高速処理を可能にするDB及びストレージの組み合わせである
データ抽出に特化していて、ビッグデータの高速処理を必要とする場合に適している
分散してデータを保存している
SQLライクな操作感
INSERT、DELETE、UPDATEはない
トランザクションもない
データ書き込みは一括ロードまたは全件削除のみ
Impala、HIVE、prestoなどのオンプレにHDFSというソフトウェアの組み合わせやS3などがこれに該当する

全検索型エンジンと分散DBの利用

分散型DBと連携することで検索データベースを構築して、データ全検索処理を可能にすることが目的
検索条件との関係性、関連性が高いデータを抽出して返してくれる
Elastic Searchは全文検索用のライブラリでApache Luceneを利用したデータストア
分析の柔軟性や速度が高く、分析・蓄積・可視化環境を容易に構築することができる
半構造化データ、高可用が必要な全検索エンジン、サイト内データ検索、リアルタイム検索要件・検索行動の可視化(ex. デバイスの登録状況や配信状況)に適している
Elastic Search、kibana、Elasticsearch Serviceがこれに該当する

分散OLTP

RDBの一種でオンライントランザクション処理を分散化する次世代DB
RDBであるのにグローバルに分散されたDBであるのが大きな特徴
強整合性を採用している
リレーショナルデータベースの構造と非リレーショナルデータベースの分散スケーラビリティを兼ね備える
高い可用性、高性能なトランザクションと強整合性を実現している
大規模な業務データ処理
Amazon Auroraがこれに該当する

NoSQLのタイプ

KVS(キーバリューストア)

Keyに対してValueを入れる
高速なパフォーマンスと分散型拡張に優れている
データ読み込みが高速
シンプルなオペレーションを高速実施したい場合に適している
結果整合性を採用
分散向けのデータモデル及びクエリを採用
トランザクション、集計、JOIN等は利用できない
大規模WEBサイトのバックエンドデータ(ex. ユーザーセッション、ユーザー属性、事前計算データのキャッシュ)、メッセージングシステムのデータ、大規模書き込みが必要となるIOTセンサーで用いるデータ等に利用する
redis、riakというオンプレDBやElastiCache、DynamoDBがこれに該当する

WCS(ワイドカラムストア)

列指向とも呼ばれ、キーを利用するがデータは列(Column)で管理する
非構造データを大規模に格納することを目的としている
行ごとに任意の名前のカラムを無数に格納できる
KVSの亜種になるので同じく分散させて、シンプルなオペレーションを高速実施したい場合に適している
データ取得の際にデータ結合しなくて済むように、可能な限り多くのデータを同じ行に保持する
結果整合性を採用
キースペース、カラムファミリ、ロウ(スーパーカラム)、カラムの入れ子構造
SQLライクな操作感
データ操作は挿入、削除、参照のみ
データの更新は挿入による上書きのみ
FacebookやTwitterなどのソーシャルデータの位置情報データストレージやリアルタイム分析、データマイニング処理に適している
cassndra Apache HBASS、DynamoDBがこれに該当する

DDB(ドキュメントデータベース)

Keyに対してValueではなく、直接JSONやXMLを入れる
複雑なデータ構造を扱うアプリで高い生産性と柔軟性を持たせることができる
様々なデータ構造のドキュメントを混在して保存することができる
JSON/XMLをデータモデルとして利用する
小規模データの同期集計処理が可能であるが、バッチ処理には不向き
SQLな操作感、KVSと比べるとクエリも豊富
シャーディングによるデータベース分散化を実現
半構造化データ、大規模WEBのログ保管、オンラインゲームデータ、カタログ管理に適している
monogoDB、MarkLogic、CouchDB relax、Couchbase、Amazon DocumentDBがこれに該当する

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

KVSをインメモリで行う仕組みのDB
大量のデータを多数のサーバーのメモリ上で分散して管理する技術
ミリ秒単位の高速の応答処理が可能
データはメモリに置かれ、多数のサーバーで分散して管理される
ミリ秒以下の応答時間を必要とする金融取引処理データなどに適している
Apache GEODE、Apache Ignite、ORALCE Coherence、hazelcast、InfinisonやRedis ElactiCache、Memcahes ElastiCacheなどがこれに該当する

GDB(グラフデータベース)

グラフ理論に基づきデータ同士の関係をグラフで相互に結びつけた要素で構成されるDB
マインドマップのようにデータの関連性をグラフ表示するようなデータ構造を形成する
高速横断検索が可能である
グラフ演算に特化していて、データ間のつながり方を検索・可視化したい場合に利用する
グラフデータ構造を取るため、RDB以上にスケールアウトができない
レコード数が増えると、検索にかかる時間と難易度が増大する
ACID特性が担保されていて、オブジェクト間の関連付けを簡単に表現できる
最短経路探索、金融取引の詐欺検出、ソーシャルネットワークによるリレーション計算に適している
neo4j、Amazon Neptuneがこれに該当する

AWSにおけるデータベース関連のサービスの立ち位置

Well-Architected FrameWorkでいうなら

信頼性
パフォーマンス効率

ベストプラクティスで言うなら

スケーラビリティの確保
キャッシュの利用
増大するデータへの対応
最適なデータベースの選択
サーバーではなくサービス
使い捨てリソースの利用

がAWSにおけるデータベース関連のサービスの主な立ち位置となる。

最適なデータベースの選択

データの特徴に応じて利用するDBを選択するというのがベストプラクティスであるが、単なるアプリケーションであればMySQLやMarinaDB、PostgreSQL等で大体事が足り、モバイルアプリでFireStoreのようなNoSQLを選択する場合があるだろう……という話でおしまいになる。
しかし、現在はビッグデータを活用することが当たり前になりだからこそAWSやGCPを利用する……なんてことにも繋がるわけである。
つまり、最適なDBの選択というのは旧来のそれは

既存の構造化データの保存・管理
上記のアーカイブデータの保存・管理

という観点加えて、それを分析して業務に活かすという目的のために最適な選択をするという意味になり、新たなに

IoTデータから得られた音声・動画等々の非構造化かつ膨大なビッグデータの保存・管理・分析
同じく半構造化データの保存・管理・分析

という目的のために最適なDBを選択するという意味を持つということになる。
当然、この分野は特にリアルタイム性(ストリームデータを扱う)、AI・人工知能構築というところにも大きく関わる。

DBの分類

分散型(複数のDBを並列で繋げる形でスケーラビリティを実現するタイプ)か拡張型(1つのDBをスケーラビリティするタイプ)か
業務用アプリケーション向けか分析用途向けか

以上の2軸に分かれる。
個別に列挙すると

分散型かつ業務・分析中道……KVS、DDB、Elastic Search
分散型かつオペレーション向け(業務用向け)……インメモリデータグリッド、分散OLTP(OnLine Transaction Processing、トランザクション処理を端末からの要求に対して即座に実行する方式のこと)
分散型かつ分析向け……データレイク(Hadoop HDFS等)
拡張型かつオペレーション向け……RDB(RDBにおけるOLTPも含む)、グラフDB
拡張型かつ分析向け……データウェアハウス

DynamoDB

完全マネージド型のNoSQLデータベースサービスである。

ハイスケーラブルで無制限に性能を拡張できる
負荷が高くなっても応答速度が低下しない低レイテンシー
高可用性(SPOF(Single Point Of Failure、つまり単一障害点のこと)なしでデータは3箇所のAZに保存される)
マネージド型のためメンテナンスフリーで利用できる(CloudWatchで運用を監視・分析する)
プロビジョンドスループットを採用し、テーブルごとにReadとWriteに必要なスループットキャパシティを割り当てることができる
→ つまり、テーブルごとに読み出しに強くするのか書き込みに強くするのか設定できる
ストレージの容量制限がないのでデータ容量の増加に応じたディスクやノードの増設が一切不要
ワイドカラム型を採用、つまりデータ操作を簡易にする代わりに複雑なクエリやオーダーには対応できない
結果整合性を採用、ただしReadに対しては整合性を強くすることができる(GetItem、Query、Scanのアクションに対して設定できる)
パーティショニングよる分散並列処理を実施(ex. 1つのテーブルを3つにパーティションする)

できることは

Key-ValueのCRUD操作
簡易なクエリ、オーダー
数万人以上が同時にアクセスして、それに対して処理を実行しなければならないようなアプリケーションデータ処理

逆に不向きなことは

JOIN・TRANSACTION・COMMIT・ROLLBACK処理(そもそもできない)
詳細なクエリやオーダー、つまり複雑なデータ検索及びデータ結合は不可
大量のデータの読み書き(コストが膨大にかかってしまうので)

となる。

ユースケース

大規模データを扱う場合は結果的にRDSよりコストパフォーマンスがよくなることがあることに注意。
トランザクションで発生しうるデータベース処理を検討または監視・分析することで採用、あるいはRDS等からの移行を検証する。
例えば銀行の振り込み処理に関してはTRANSACTION・COMMITMENT・ROLLBACKいずれも必要不可欠なのでRDSを採用……となる。
逆にいうとそれらのいずれも必要ではなく、大規模・大容量のデータを高速で処理することが想定されるならDynamoDBを検討する……という話。
基本的にはサーバレス等を鑑みてDynamoDBファーストで検討し、適さない場合は順次RDS等で代替えを行う方向でアーキテクチャを検討する。

ビッグデータ

大量のデータを収集・蓄積・分析するためのデータベースとして活用
Hadoopと連携することでビックデータ処理も可能になる

アプリケーション

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

ユーザー行動に対してのデータ管理

ユーザー情報やゲーム、広告などのユーザー行動データ向けDB
ユーザーIDごとに複数の行動履歴を管理したいときに利用

バックエンドデータ処理

主にモバイルアプリケーションに対しての

バックエンド
バッチ処理のロック管理
フラッシュマーケティング
ストレージのインデックス

に利用。

DynamoDBのテーブル設計

テーブル・項目・属性で構成される。

テーブル……データのコレクションを指す、まあRDBにおけるテーブルと役割は変わらない
項目……属性の集合、つまりRDBにおける行のような役割。ただし、項目間は一意に識別できないといけない
属性……項目を構成する要素、つまりDynamoDBにおける最小のデータ単位

ex.

テーブル(人事管理部)
項目(Personal1、Personal2……n)
属性(姓名、性別……etc)

なお、属性に入るデータ型は不揃いであっても構わない。

DynamoDBにおけるインデックス

PK及びLSI、GSIと呼ばれるものをインデックスとする。

1テーブルにつき1つ、データを一意に特定するためのハッシュキーやレンジキー(これらはPKとなる)を宣言してインデックスとする。これは暗黙的なキーと言われる
LSI(Local Secondary Index)はプライマリキーのタイプがハッシュキーやレンジキーの場合の追加レンジキーの役割となるインデックス
LSIは1テーブルに5つ作成可能で、テーブル作成時にのみ作成できる明示的なキーとなる
LSIはレンジキー(複合キー)によって整理されている項目に対して設定でき、さらに別の規則でのインデックスを可能にする
GSI(Global Secondary Index)は別のハッシュキーとして設定できる全データに対してグローバルに付与されるキー
GSIは1テーブルにつき5つ作成可能で、LSIとは違いテーブル作成後に追加で作成する明示的なキーとなる
GSIはハッシュキーの属性の代わりとなり、ハッシュキーテーブル及び複合キーテーブルどちらにでも設定可能
GSIを使ってハッシュキーをまたいで自由に検索ができるようにする
LSIやGSIはスループットやストレージ容量に負担をかけ、書き込みも増大するために多様はできない

DynamoDBにおけるPK

ハッシュキー

KVSにおけるキーに相当するデータを一意に特定するためのIDなどのこと
テーブル作成時に属性を1つ選んでハッシュキーとする
ハッシュキーは単独での重複は許されていない

レンジキー

ハッシュキーにレンジを加えたものをレンジキーまたは複合キーと呼ぶ
テーブル作成時に2つの属性を選び、1つをハッシュキーとして、もう1つをレンジキーと呼ばれるキーとして宣言する
2つの値の組み合わせによって、1つの項目を特定する
複合キーは単独であれば重複が許される

DynamoDBにおけるテーブル操作

GetItem……ハッシュキーをキーにして一定の項目を取得する
PutItem……項目を書き込む
Update……項目を更新する
Delete……項目を削除する
Query……ハッシュキー及びレンジキー(つまりPK)にマッチする項目を取得する(1MBまで)
Scan……テーブルを全件検索する(1MBまで)
BatchGetitem……複数のPKに対してマッチする項目を取得する

DynamoDB Streams

DynamoDBテーブルに保存された項目の追加・変更・削除の発生時にその履歴をキャプチャできる機能。

過去24時間以内のデータ変更の履歴を保存し、24時間を経過すると消去される
データ容量はマネージド型で自動的に管理される
操作が実施された順番に応じてデータがシリアライズされる
特定のハッシュキーに基づいた変更は正しい順番で保存されるが、ハッシュキーが異なる場合は受信した順番が前後される可能性がある
DynamoDBのクロスリージョンレプリケーションにおいて、ストリームによるキャプションをトリガーとしてそれを実施できる
データ更新に応じた通知処理などのアプリケーション処理の実行のトリガーとして使える

例えばこの機能でキャプチャした履歴を元にLambda関数によって

DynamoDBの別テーブルを自動更新
S3にログを保存
SNS等でプッシュ通知

などの処理を自動化して行うことができる。

DynamoDB Accelerator(DAX)

DAXはDynamoDBにインメモリキャッシュ型の機能を付加することができる機能。
DynamoDBに対してのアクセスに対し、キャッシュがあればそちらを優先させる。

インメモリキャッシュとして1桁台のミリ秒単位からマイクロ秒単位まで、結果整合性のある読み込みワークロードの応答時間を短縮する
マルチAZでDAXクラスターを用いると、1秒間に数百万件のリクエストを処理できる
DAXはDynamoDBを使用するAPIと互換性を持つマネージド型サービスであり、運用上そしてアプリケーションの複雑性を減少させて容易に導入可能である
読み取りの多いワークロードや急激に増大するワークロードに対して、スループットを強化したり、読み取りキャパシティユニットを必要以上にプロビジョニングしないように設計することで運用コストの節約ができる

グローバルテーブル

DynamoDBはリージョン間で同期されるマルチマスターテーブルを作成することができる。
同期されるマルチマスターテーブルつまり、クロスリージョンレプリケーションを取るのでその性質上DynamoDB Streamの設定が必須となる。
(レプリケーション先に変更があったことと、その履歴を通知しないとレプリケートできないため)

DynamoDBの性能のまま、世界中で複数のリージョンにエンドポイントを持つことができる
読み書きのキャパシティに加えて、クロスリージョンレプリケーションのデータ転送料金に課金される
本来オプションで実施できた強い整合性は不可
DynamoDB Streamでキャプチャされたデータの変更履歴を元にレプリケーションを行う

オンデマンドバックアップ

パフォーマンスに影響なく、数百TBでバックアップができる。

任意のタイミングで利用可能な長期間データ保存用バックアップ
従来はデータパイプラインを利用して取得したバックアップを容易に実施できるようになった

Read/Writeキャパシティオンデマンド

キャパシティ設定不要でリクエストに応じた課金設定を選択できる。

トラフィック量の予測が困難な場合にリクエストの実績数に応じて課金できる
オンデマンドRead/Write処理に自動スケーリングを実施できる
プロビジョンドキャパシティ設定への変更は無制限
オンデマンドへの変更は1日1回まで

Amazon Aurora

RDBではあるが、分散型のDBであるAmazon独自の仕様のDB。
高い並列処理によるストレージアクセスでクエリを高速で処理することが可能であり、大量の読み書きを同時に扱うことができるのが特徴。

分散型リレーショナルDBという新しい規格
NoSQL型の分散高速処理とRDBとしてのデータ操作性の両立を目指す
MySQL相当の商用DBと比べて価格は1/10で性能は2.5~5倍(公称)
高い並列処理性能によって大量の読み書きをするのに適したDB
DBの集約及びスループットの向上が期待できる
高性能はあくまでも公称なので、有効となるべき領域を判断して使うことが肝要
MySQL5.6及びPostgreSQLと互換性がある
MySQL5.6及びPostgreSQLのSnapshotからマイグレーションすることでAuroraへと移行することもできる
EFSをEC2インスタンスから操作する際には専用のクライアントソフトウェアを利用する

また、フルマネージド型であり耐障害性と自己回復性を兼ね備えているのも特徴である。

3つのAZに2つのコピー、つまり計6つのコピーを設置可能
過去のデータがそのままS3へと継続的にバックアップされる
リストアも差分適用がなく高速である
どのタイミングでも安定したリストア時間を実現
99.99%の高可用性・高耐久性
10GBから最大64TBを提供するSSDデータプレーンを利用してシームレスに拡張ができる
Auto-Scalingなどのクラウド独自のスケーラブルが可能
最大15のリードレプリカを利用した高速読み込みが可能
マスターDB自体をリードレプリカのように複数構築することも可能(Write機能のスケーラブル可)
リードレプリカ、クロスリージョンリードレプリカの他にAuroraのDBクラスタ構成自体をクローンを作成することもできる
DBクラスタクローンの機能によって、同一の環境を容易に複製することができる

以下のように大規模なクエリ処理が発生するRDB環境(特に中規模以上)などを扱っている、または扱う予定の場合はAuroraの採用・移行を検討する。

書き込み量が多く、トランザクション量が多い
クエリ並行度が高い、データサイズが大きい
コネクション数やテーブル数が多いデータベース処理である
上記のようなユースケースに合わせて、スケーラビリティの高さやデータ容量を無制限に拡張できるメリットを享受できる場合
レプリケーションなどの性能の高さを活かせる場合

Auroraの構成

基本的には1つのDBインスタンスと1つの仮想クラスタボリュームで構成される。
仮想クラスタボリュームは前述の通りAZあたり2つ、合計6つのコピーが作成できるがこれらを単一のボリュームとしてみなしたものが仮想クラスタボリュームである。
次にDBクラスタという構成を見てみる。
AuroraはマスターとそのリードレプリカをまとめてDBクラスタとして構成することができる。
この場合、例えばマルチAZでELBを使って分散処理をするようなVPC構成をしている場合、書き込み処理はエンドポイントからWriterが指定されることになる。
つまり、マスターがあるAZに処理が振られる。
同じように読み込み処理はエンドポイントからReaderが指定される。
この場合の処理フローは

マスターがあるAZのEC2から読込処理のアクションが行われる
エンドポイントへパスされる
エンドポイントが適切なReader(つまりリードレプリカ)へ処理をパスする

ということになる。
さらにマスターに障害が起きた場合はエンドポイントが自動的にReaderのいずれかへとフェイルオーバーする仕組みになる。

Auroraサーバレス

予測困難なアプリケーションワークロードに対応したAuroraのオンデマンド自動スケーリング構成。
アプリケーションのニーズに応じて自動的に起動やシャットダウン、スケールアップやスケールダウンを行う。

AuroraグローバルDB

より高性能なリードレプリカを作成することもできる。

ログ転送ではなく、ストレージレベルのレプリケーション機能を利用してのレプリケーション
より低レイテンシーなレプリケーションを行える

EFS

EFSはEBS(ブロックストレージ)・S3(オブジェクトストレージ)と並ぶAWSのストレージサービスでNASに似たファイルストレージサービスである。
ストレージにアタッチするのではなく、マウントターゲットをAZに作成し、EC2インスタンスはそれを経由することでアクセスを可能にすることで、複数のEC2インスタンスの共有ストレージとして利用できる。

フルマネージド型サービスである
NFSv4プロトコルを利用して、関連ツールや標準プロトコル/APIでアクセスすることができる
ペタパイトまでスケーラブルにデータを蓄積することができる
スループット/IOPS性能は自動的にスケーリングすることで低レイテンシーを維持する
ファイルの減少に合わせて自動で拡張・縮小を行う
事前に容量を設定する必要はなく、従量課金となる
データファイルは複数AZに分散して保存される
ファイルシステムと呼ばれる管理単位を取る、これにディレクトリを作っていく
マウントターゲットは固定のDNS名とIPアドレスを有していて、DNS名を使用してマウントすることで自動でIPアドレスが付与されるという仕組みになる

性能に関しては

バースト込みで基本性能は100MB
ファイル名は255バイト
1ファイルの最大容量は48TB
インスタンスあたり128ユーザーまでの同時オープンが可能
何千もの同時アクセスが実現可能
1アカウントあたり1000まで
AZあたりのマウントターゲットは1つまで
マウントターゲットごとのSGは5まで
ファイルシステムあたりのVPC数は1まで
各VPCのマウントターゲット数は400まで

ユースケースは以下のように複数EC2インスタンスでデータを共有する必要がある案件となる。

EBSではできない、複数インスタンスからのストレージへの同時アクセスが必要である
数秒単位でのデータ追記が必要である
フルマネージドで運用して簡易に利用したい
アプリケーションの共有ディレクトリがほしい
ビックデータなどの分散並列処理環境における共有データアクセスストレージとして利用したい
コンテンツの共有リポジトリとして利用したい

パフォーマンスモード

その名の通りEFSのパフォーマンスを決める設定。

基本は汎用モードで、秒あたりのファイルシステム操作を7000に制限している
レイテンシーは汎用モードのが低い
対して、最大I/Oモードは大量のクライアントからの同時アクセスが必要な大規模構築を行う際に利用する
最大I/Oモードは合計スループットを優先してスケールするようになるが、レイテンシーは長くなる

バースト機能

ファイルストレージの負荷に対してスケーラブルに対応する機能。
以下のようなケースが例。

NFSサーバーの容量の増大によるスループット性能の低下が見込まれるとき
一時的なピーク時の負荷が増大する可能性があるとき

バースト性能は以下の点から成り立つ。

バーストとは一時的な大量トラフィックの発生やそれに伴いサーバーなどの処理性能が一時的に向上することを指す
バーストスループットモードにより、EFS側でファイルシステムの増大に伴ってスループットを自動的に拡張する
クレジットシステムにより、ファイルシステムはバーストするタイミングを判断する
各ファイルシステムは、非アクティブであるかスループットが標準以下であるときにクレジットを蓄積することができる。
クレジットは通常ファイルシステムにおける読み書き処理の度に消費されるものであるが、蓄積されている場合はさらにそれを消費してバーストすることでスループットを拡張することができる
容量に応じたバースト性能となり、1TB以上の容量に応じて性能が向上する
最大で1GB(通常の性能は100MB)までバーストする
容量に応じてクレジットの蓄積量とスループット性能も向上する

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

バーストが予期せぬ負荷に対してのスループット拡張出会ったのに対して、
こちらは一貫したスループットを事前に設定する方式で、API/AWS CLI/マネジメントコンソールから制御する。
1日1回だけ設定したスループット性能を減少させることができる。

EFS以外のファイルストレージ

FSxタイプのファイルストレージをユースケースに応じてEFSに代わって選択することができる。

Amazon FSx For Windows File Server

WindowsFile Serverと互換性のあるストレージでそのクラウド版といった感じ
Windows上に構築され、Windows AD、OSやソフトウェアとの連携が豊富に可能なのが特徴
Active Directory統合などの幅広い管理機能を持つ
SMBプロトコルによりEC2、VMware Cloud on AWS、Amazon WorkSpace、Amazon AppStream2.0等のインスタンスに幅広く接続可能である
最大数千台のコンピューティングインスタンスからアクセスが可能である
ENI経由でアクセスし、VPCセキュリティーグループで制御を行う
単一AZの単一サブネットを指定して構成する
複数インスタンスでの共有や他AZ内のインスタンスからのアクセスも可能である
マルチAZ構成を実施することもできる

Amazon FSx For Lustre

分散型ファイルストレージであるLustreと互換性のある分散型の高速ストレージ
機械学習や高速コンピューティングのデータレイヤーに利用する一時的保存用の処理用ストレージとして利用できる
スパコンに利用されているシステムであり、つまるところ高速コンピューティング処理を実現する分散・並列処理専用の超高性能なストレージである
Lustreをフルマネージドで利用できる
最適容量3600GB、最大数百GB/秒のスループット、数百万IOPSまでスケールが可能である
ENI/エンドポイント経由でアクセスする
セキュリティグループで制御する
単一AZ、単一サブネットを指定して構成する
S3とのシームレスな統合により、データレイク型のビックデータ処理や解析ソリューションに組み込む

増大するデータへの対応

ベストプラクティスの考え方のうちの1つ。
昨今はもうビッグデータとIoTから得られる大量のデータをどうこうすることが当たり前になってきているなか、インフラもそれに対応しないと行けないという話。
ビッグデータには様々なWebリソースから得られるものと、IoT機器から集められるものとがあり、それらを利用するためには解析・分析が必要でそのためには統計学的な話を抜きにしても収集したデータを蓄積しなければならない。

具体的には以下の通り。

効率的にデータを蓄積する(AWSサービスの例だと、S3・Glacier・Glue)
蓄積したデータをストリームデータとして処理する(Kinesis)
ストリームデータを解析する(Athena、EMR、QuickSight、Redshift)

こうしたビッグデータの蓄積にはDBの種類でもやったように、データウェアハウスとデータレイクという手法がある。
データウェアハウスは利用用途に応じてデータをETLで変換して蓄積するのに対して、データレイクは生のデータを出来得る限り用途によらず集められるだけ集めておくというスタイルになる。
以下にまとめておく。

DWH

データ収集……構造化データを中心に、目的別データで必要なデータのみを抽出・収集する
蓄積……必要なデータのみ抽出・収集
処理・加工……事前に関連するデータ構造(スキーマ)に変換・蓄積、SQLで操作する
可視化分析……利用者がデータ分析やレポート内容などの利用目的を事前に特定して構築する

フローは以下の通り。

目的別にデータを収集……販売データ、顧客データ、会計データ……etc
ETLで目的やレポート形式に応じてデータを変換する
ETLで変換したデータをデータウェアハウス型のDB等に蓄積
OLAP(Online Analytical Processing)やデータマートで活用される

みそなのはETLで事前にデータを変換してから蓄積すること。
つまり、目的やレポート形式を明らかにしてそれに応じてETLを設定しないことには始まらないので詳細な設計等が必要であったりと構築に時間がかかる。

DL

データ収集……生データ及び目的別データを構造化・非構造化・半構造化問わず収集する
蓄積……変換しないで生データ形式で保存するか、またはエッジ処理して保存する
処理・加工……事前にスキーマ定義(データ構造の定義)をしない。SQL・SAS・MapReduce・R・NoSQLなどで操作する
可視化分析……事前に目的を定義せず、ユーザがデータ郡から新たな価値を抽出し、データを解釈して活用する

フローは以下の通り。

あらゆるデータを出来得る限り収集する
構造化データのみはETLでDWHへと蓄積し、それ以外の非構造化・半構造化データは適切なDB程度に蓄積する(こちらがデータレイクとなる)
データマート・OLAP・ETL(Glue)・EMRを用いてApache Hadoop(大量データバッチ処理)、Apache Spark(ストリーミング処理)等で処理・加工される

みそなのはDWHとは違って、構造化データ以外は生データのまま集めて、データの加工はあとからになるということ。
つまり、活用を目的として蓄積するのではなく、蓄積した結果必要に応じて加工して活用しようという発想なのだ。

Kinesis

ストリームデータを収集・処理するためのフルマネージド型サービスで主に3つのサービスで構成されることになる。

Amazon Kinesis Data Streams……ストリームデータを処理するアプリケーションを構築する
Amazon Kinesis Data Firehose……ストリームデータをS3やRedshiftなどへ簡単に配信できる
Amazon Kinesis Data Analytics……ストリームデータを標準的なSQLクエリでリアルタイムに可視化・分析する

Amazon Kinesis Data Streams

ストリームデータ処理用の分析システムやアプリケーションを構築する。
実際にデータをどうストリームデータとして処理をするかというと、データ処理をシャーディング、つまり分散させて高速処理させることで行っている。
サンプルフローとしては

IoT機器からデータを収集する
Kinesis Streamsでストリーミングデータに加工する
Spark Streamingで分析・加工する
アプリケーションへデータが渡る

というものになる。
で、このサービスはプロデューサー及びコンシューマという関係性を仲介する形で存在しているところが肝となる。
つまり、データを提供するサービスとそれを利用するサービスとを連携させ、ストリームデータを扱うということは大抵の場合それをリアルタイムで処理したいという目的があるので、それを助けるというのがこのサービスの主たる目的ということになる。

プロデューサー側の代表的なサービスや機能は

Kinesis Appender
Kinesis Producer
Kinesis Agent……Kinesisサービスにデータを簡単に収集して取り込むOSSのスタンドアロンJavaアプリケーション
AWS SDK
Cloud Watch
Fluentd……(個々のシステム毎の大量のログファイルの収集・解析・集約・保存を行うことができるデータコレクタ)
AWS IoT

となり、コンシューマーは

Kinesis Firehose
Kinesis Client
Kinesis Analytics
Lambda
EMR
Apache Storm

となる。
またKinesisのその他関連機能としては

Amazon Kinesis Producer Library(KPL)……Kinesis Streamsにデータを送信するOSS補助アプリ
Eluent Plugin for Amazon Kinesis……イベント送信のプラグイン、これがないとStreamsやFirehoseによるデータの更新がうまく行かない
Amazon Kinesis Data Generator(KDG)……こちらはテストデータを送信するためのプラグイン
Amazon Kinesis Data Client Library(KCL)……Kinesisアプリケーションの作成を行う。OSSのクライアントライブラリでEC2インスタンスなどにデプロイすｒ

Amazon Kinesis Data Firehose

各種DBに配信・蓄積するためのストリーム処理を実際に行うのがこちらの機能。
Lambdaと連携することによってETLとしても使うことができる。

Amazon Kinesis Data Analytics

こちらはストリームデータを標準的なSQLクエリでリアルタイムに分析・解析を行うことができる機能。
FirehoseやStreamsからパスされた来たものをこちらで分析・解析を行い、再度FirehoseやStreamsへとパスするということもできる。

Redshift

高速でスケーラブルな費用対効果の高いマネージド型のDWH及びDL分析サービス。
概要は以下の通り。

数百ギガバイトのデータから開始して、ペタバイト以上まで拡張できる
1テラバイトあたり年間1000USD以下で利用できる
自動ワークロード管理など自動テーブルメンテナンスなど多くのメンテナンスタスクやデータ配置が自動化されている
PostgreSQL五感の列指向データモデル
複数ノードをまとめたクラスター構成である
単一AZで起動し、マルチAZ構成は不可である
RA3インスタンスで最大で他のクラウドデータウェアハウスの3倍に達するパフォーマンスがある
AQUAによる分散キャッシュで、Redshiftが他のクラウドデータウェアハウスに比べて最大10倍の速度で動作する
コンソールでクエリ実行ができる(クエリエディタ機能)

構成としては1~32個のノードにリーダーとコンピュートの役割を持たせ、クエリを実行し、ストレージへデータを保存するという形式になる。

リーダーノード……クエリのエンドポイントとなり、SQLコードの生成・実行を行う
コンピューティングノード……リーダーからクエリを受け取り、複数ノードで並行して実行する。高速ローカルSSDキャッシュを持ち、同じクエリの場合はキャッシュを利用する。
マネージストレージ……クエリの実行の結果できたデータを保存しておく場所。クエリ実行時に必要なら取り出されることもある。永続データであり、専用のS3が作られる。

マネージストレージにはRedShift Spectrumという機能によって、自前のS3バケットを使ってそれを直接解析することもできる。
ただしこれには予め解析・分析目的をもったS3バケットを作っておく必要がある。
DBとしては以下の特徴がある。

列指向のRDBであり、大容量のデータアクセスを容易にしてディスクI/Oを効率化する
データ圧縮によって読み込みデータ量を多くすることで処理を高速化する
分析ワークロードでブロック単位でデータを格納して、ディスクI/Oを効率化する
データが格納されているブロックに対して、メタデータを付与して検索値とする
リーダノードのインメモリ上にメタデータを格納する
データのソート順をテーブルごとにソートキーとして指定する
データ量とクエリ内容に応じてノードに対する分散処理を調整し、効率的で高速な処理を実現する
キャッシュにより高速化を図る
頻繁に実行するクエリパターンは結合・フィルタ・集計・射影によって高速化する(マテリアライズドビュー)

Redshiftのインスタンスタイプ

利用するデータサイズ及び増加予測に応じて2つのインスタンスタイプから選択する。

RA3インスタンス

コンピューティング性能・マネージドストレージのスケーリング・支払いを独立させることでDWHを最適化する
データ量の増大が想定される場合はRA3ノードの利用が推奨される
最低2ノードの利用が必要となる

DC2インスタンス

固定ローカルSSDストレージを利用しているDWH
データのサイズ増加に対してノードを追加し、クラスターのストレージ容量を増強する
未圧縮で1TB未満のデータセットの場合はDC2ノードタイプの利用が推奨される
最低1ノードの利用が必要となる

WLM(ワークロード管理)

ワークロード(システム処理に対する処理量や負荷のこと)に応じて複数のキューを設定し、クエリ割当ルールに基づいてキューを設定して、その優先順位を設定する。
キューはロングクエリ・ショートクエリと機械学習で自動的に区別され、設定されたキューにスロットを設置して、CPUとメモリを割り当てて実行する。
スロットが増えると並列度は向上するが、割当メモリ量は減少する。

Redshift運用の自動化

初期設定においてすでにCloudWatchのメトリクス取得が自動で実施され、コンソールで確認ができる
自動でバックアップは定期取得され、バックアップの実施時間も指定できる
スナップショットはS3やRDSと同じく手動で取得可能
バッチの適用も自動で行われ、実施時間も指定可能
クラスターサイズの変更・一時停止・再開等のスケジュールも設定できる

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

クエリ実行は機械学習により効率化され、自動実行の補助もしてくれる。

テーブルの分散スタイルの自動最適化、統計情報の自動更新、データの再編成の自動実行等テーブルメンテナンスの自動化を図る
複数クエリの実行をワークロード管理で設定する際に、優先順位を自動で設定してくれる
機械学習アルゴリズムを使用して対象のクエリを1つ1つ分析し、クエリの実行時間を予測し、実行時間が短いクエリは優先して実行される
WLMキューを削減可能
自動でクラスタパフォーマンスを分析し、最適化やコスト削減に対するレコメンデーションを実施する

RedShiftのスケーリング

RedShiftはノードのタイプ変更及び追加とクラスターの追加の2パターンでのスケーリングが可能。

ノードでのスケーリングはコンピューティングノードを追加することによってパフォーマンスの向上を図る
クラスターの追加はConcurrency Scalingと呼ばれる機能によって、同時に複数のユーザー及びクエリからのリクエストに対し、クラスタを自動的に追加することで数倍の並行処理パフォーマンスを一時的に実現することができる
クラスタの追加は10個まで

RedShiftのデータ連携

他のAWSサービスとRedShiftの連携について。
連携する目的としては、RedShiftへデータを移動することで、DWHとしての解析基盤を集約化させるところにある。
まずはRedShiftが他のサービスからデータを取得する場合。

S3……1番使われる連携先。S3からデータを取得して解析するも、連携を前提にしてS3バケットを作って内部を直接解析してもよし
Kinesis……Firehoseを利用して、ストリートデータの格納先としてRedShiftを指定することで、保存・解析に利用することが可能
RDS……直接の連携はないものの、PipelineやDMSを利用してデータ移行ができる
DynamoDB……DynamoDBからRedShiftにデータコピーを実行できる
Amazon EMR……EMRからRedShiftにデータコピーを実行できる

次に他のサービスへとデータを抽出する場合。

S3……UNLOADコマンドによって、S3にデータを抽出する
QuickSight……データを可視化・解析してくれるBIツール、RedShiftに接続することで、データの可視化を実行可能
Machine Learning……RedShiftを機械学習のデータとして利用する
RDS……PostgreSQL経由でデータを連携する

AWS Glue

データ抽出・変換・ロード(ETL)を行う完全マネージド型のサービス
AWSサービスでETLを行いたいときはこちら。

Amazon EMR

Apache Spark、Apache Hive、Prestoなどのビッグデータフレームワークを利用して、大量データを処理・分析するサービス。

AWS Lake Formation

ここまでのサービスの中からデータレイク構成を構築するための補助ツール。
ベストプラクティスに従って構築していくことができる。

ハンズオン

今回はどれも高額だったので実際には構築はしなかった(万が一消し忘れたら20万は下らない)。

DynamoDB

Aurora

EFS

マウントターゲットはAZに設置する。

ポリシーの設定。

このようにウィザード形式でチェックボックスを入れるとエディタにも反映される。
なので、予めウィザードでポリシーを作り、細かいところを自分でエディタで書き込むといったことも可能。

確認画面。

EFSはアクセスポイントを設定する必要があるので適宜設定をする。

セキュリティグループの設定も必要。
NFSへのトラフィックを許可するように設定する。

EFSの操作はクライアントツール等を使わないといけない。
下記のように立ち上げたEC2インスタンス内にパッケージをインストールするのが基本。

RedShift

1番性能が高いであろうRA3インスタンス。
月20万強は個人には高すぎる。

じゃあ1番安いDC2インスタンスならと思っても、月2万強。
うっかり気軽に作成して消し忘れようものなら怖い……

ちなみにノードを増設するとDC2でもさらに恐ろしい値段となる。

作成するにはいつものようにウィザードで。
デフォルトで勝手に作ってもらうこともできるし、VPCやサブネットグループを利用して自分で設定することもできる。
自分で作成する場合は利用するVPCにサブネットグループが存在していないと作成できないことに注意。