Ch7. データベース
RDS
RDSはマネージドサービスではあるものの、保存するストレージはEBSから選択することになる。(OracleやPostgresql等アプリケーションが実行されるコンピューティングをマネージドサービスとして提供してくれている。)
RDSでは各DBの全ての機能を利用できるわけではない。利用したいうDBの機能がRDSでは利用できない場合はEC2インスタンスにDBをインストールして利用する方法も検討出来る。
少し昔の記事になるが、RDSで利用できないDBの機能をClassmethodがまとめてくれている。 [2018年版] RDS for Oracle と Oracle on EC2 の比較 | DevelopersIO
マルチAZ
RDSではマルチAZを構成を簡単に実現する仕組みを提供してくれている。
その一方でDBそのものが複製されることになるので、書き込み速度は遅くなる。2つのDBに対するInsert/Updateが完了して初めてトランザクションが終了することになるので当然の現象である*1。
また片方のインスタンスに障害が発生した場合、もう片方のDBインスタンスが稼働する(フェイルオーバという)が、その時間は120秒程度であり、ダウンタイム0という訳にはいかない。
リードレプリカ
DBのロードバランシングのために、読み取り専用のDBを設ける。マスターのDBをメンテナンスのために利用不能にしても、リードレプリカだけは残しておき、読み取り専用のデータベースのみを提供し続けることが可能。
マルチAZと大きく異なる点として、DBのデータの同期は非同期で行われるという点である(非同期レプリケーション方式と呼ぶ)。つまりリードレプリカは読み取るタイミングによってはマスターDBの内容との間に差分が出るかもしれず、これが許容できないと、リードレプリカを使うことが出来ない。
バックアップとスナップショット
バックアップは指定した時間に自動で取得してくれる。DBスナップショットと呼ばれるもので、最大35日間保存できる(個人的には意外と短いと感じるが、S3等への移行にも対応しているようでDBスナップショットとして保存できる期間に過ぎない)。
Amazon S3 への DB スナップショットデータのエクスポート - Amazon Relational Database Service
手動にせよ自動にせよ、バックアップを取る際は数秒のIOダウンタイムが発生してしまう。マルチAZ構成であれば、バックアップはスタインバイ側のDBから取得してくれるため、ダウンタイムを気にする必要がない(これがマルチAZ構成が強く推奨される理由の一つでもある)。
スナップショットから直接稼働中のDBにデータを差し戻すことは出来ず、やるなら新規のDBインスタンスを立ち上げて、スナップショットを呼び出す形で復元する。
セキュリティ
RDSは(S3等と異なり)VPC内に設置するため、セキュリティグループやACLによる通信要件の設定が可能である。デフォルトでインターネットからの接続は不可となっていて、RDBのDBサーバを直接操作するようなオペレーションは想定されない。
またストレージ(保存内容)だけでなく、ログやリードレプリカ等も含めた暗号化が可能。途中から選択できない。
Amazon Aurora
Amazon AuroraではマルチAZという概念はなく、必ず3つのAZに対して各2つずつのストレージに内容が同期される(計6つ)。
この同期はトランザクション毎に行われる(非同期レプリケーションではない)。6つのDBに同時に書き込むトランザクションはパフォーマンスが低下しそうだが、並行で行われるので問題にはならないらしい。
3つAZのうちの1つのストレージがMasterと認定され、残りはリードレプリカとして多数決による読み取りリクエストに対応する。ファイルオーバーの際はこのうち一つがMasterに昇格する。
3つのAZへのレプリケーションは完全に自動で行われるが、Masterインスタンスとその他の各インスタンス・リードレプリカ全体のインスタンスに対してそれぞれにFQDNが与えられる。
各インスタンスに対応するエンドポイントには次のように名前が与えられている。
| インスタンス | エンドポイントFQDN |
|---|---|
| マスターインスタンス | クラスターエンドポイント |
| リードレプリカ全体 | 読み取りエンドポイント |
| 各リードレプリカ単体 | インスタンスエンドポイント |
「読み取りエンドポイント」にクエリを送った場合、各リードレプリカに対するロードバランシングを自動で実施してくれる。
通常のRDBと異なるのは「書き込みは4/6が、読み取りは3/6が成功した時点でトランザクション成功とみなされる」点である。各AZのストレージ間で読み取りや書き取りに失敗したストレージがあれば、他のストレージを参照しながら自動修復が行われる。
Redshift
Redshiftはデータウェアハウスである。
データウェアハウスとは、ビッグデータのような大量の情報の中から、各データの関連性を見つけ出すための分析システム。RDBのような継続的なデータのInputを苦手としている。むしろ大量のデータを一括で入力したのちに大量の計算資源を用いて分析を実施する目的で利用される。
Redshiftは列指向DBである。大量のデータの中から関連性を見つけ出すためには、1レコードのカラムを全て読み出す「行指向DB」よりも効率が良い。また太陽の計算を実施することを念頭に計算資源を有効に利用するため、並行処理を前提としている。
Redshiftの並行処理の仕組み
Redshiftは並行処理を実現するため、大量のコアを単位ごとにまとめている。
各コアのことをノードスライスと呼び、複数のノードと一つのストレージをまとめた各コンピュータのような塊をまとめてコンピュートノードと呼ぶ。
複数のコンピュートノード(≒一つのRedshiftサービスのことで特別にRedshiftクラスタと呼ぶ)をまとめてリーダーノードと呼ぶ。リーダーノードは(BIツール等から)リクエストを受け付け、最適な分散処理を検討して計算をコンピュートノードに指示している。
複数のコンピュートノードを跨ぐ計算を避け、各コンピュート内で完結する計算が実施出来れば、クリティカルパスが少なくなり効率的に大量の計算を処理できる。
データI/O削減の仕組み
大量の計算処理を実施する上でボトルネックになるのはデータI/Oである。
このデータI/Oを削減する、もしくはパフォーマンスを落とさない3つの仕組みを持っている。
圧縮エンコード
各カラムのデータを一定の圧縮形式で圧縮しておき、ストレージから読みだすときの負荷を軽減している。各カラムの入力値の性質毎に適切なデータ圧縮形式は異なる。
ゾーンマップ
Redshiftのストレージは1MBのブロックごとに分割されている。各ブロックに保存されているデータの最小値・最大値の索引を持っておくことで、コンピュートノードがそのブロックを読みに行く必要があるかどうか判断できる。読み出すブロックの数を小さくすることでI/Oを削減している。これをゾーンマップと呼ぶ。
MPPとshared-Nothing
リーダーノードが1つの集計処理に対して複数のコンピュートノードに分割して計算を実施し、一つの集計結果を得る仕組みをMassive Parallel Processingと呼ぶ。コンピュートノードを追加することで計算のパフォーマンスを向上させることが出来る仕組み。
仮にコンピュートノードが複数あったとしても、互いのコンピュートノードが一つのディスクを共有していればI/Oの効率が落ちてしまう。そのため、各コンピュートノードは独立したディスクを備えている。この仕組みを（互いのコンピュートノードが何も共有していないという意味で）shared-Nothingと呼ぶ。
Redshift Spectrum
S3に置かれたデータをRedshiftのテーブルに取り込むことなく、集計処理を行う仕組みのこと。
Amazon DynamoDB
AmazonのマネージドサービスのNoSQL。3つのAZに自動的にデータがコピーされ、フェイルオーバーも完全自動という高い可用性も持つ単一障害点の無いサービスである。
このNoSQLは小さなレイテンシ(数ミリ秒台)でデータを読み取る、書きとることに最適化されている。逆に一貫性や複雑なクエリを処理することを苦手としている。
Amazon DynamoDB（マネージド NoSQL データベース）| AWS
スループットキャパシティ
「数ミリ秒台」のI/Oを実現可能なDynamoDBであるが、そもそもそうした性能自体をスループットキャパシティとしてユーザーで定義してやる必要がある。
読み取りのキャパシティ（Read Capacity Unit【RCU】）と書き取りのキャパシティ(Write Capacity Unit【WCU】)に分かれている。
どちらのキャパシティユニットもダウンタイムなしで変更できる。またAutoScalingも利用できるが、スパイクが発生する場合は追いつかない場合があるため、スパイクの発生が予定されている場合は、手動でキャパシティユニットを事前調整しておくことが求められる。
プライマリーキーとインデックス
DynamoDBでは各データをパーティションごとに指定する。
各データには「パーティションキー」が与えられ、これがKey-ValueのKeyとして利用されるとともに、DynamoDB内でデータを一意にするための「プライマリーキー」としても利用される。
パーティションキーだけではデータを一意に出来ない場合、「パーティションキー」+「ソートキー」をプライマリーキーとして利用することも出来る。
【パーティションキー】+【ソートキー】(≒【プライマリーキー】)よりも更に高い検索パフォーマンスを実現するために、プライマリーキーに新しい項目（カラム）を追加して別のキーを作成できる。これを【セカンダリーインデックス】と呼ぶ。
【入門】私を苦しめたDynamoDB | フューチャー技術ブログ
TTL
DynamoDBのデータにはTTLを付与することが出来る。自動でメンテナンスして容量を削減できる。
DynamoDB Streams
データに対する変更履歴を保持する。データに対して行われた変更をトリガに処理を実施したいときはDynamo DB Streamsを監視することで実現できる。
一貫性を持った参照
基本的にDynamoDBでの参照に一貫性を求める設計は好まれない。ただし読み取り時に一貫性を実現する*2参照はオプションとして用意されている。注意すべきは、この参照では通常のRCUの2倍、つまりパフォーマンスが半分ほどになってしまう。
一貫性も持つ参照が頻繁に必要になる場合、RDBの利用を検討したい。
DynamoDB Accelerator
DynamoDBはもともと「数ミリ秒台」のレイテンシのI/Oを実現している。
キャッシュを利用することで、これを更に向上させ10倍程度のパフォーマンスを実現するのがDAX(DynamoDB Accelerator)である。
Amazon DynamoDB Accelerator (DAX) | AWS
ElasticCache
ElasticCacheはインメモリデータベースのマネージドサービスである。
インメモリデータベースとは、RDBへのI/Oが処理のボトルネックになってしまうのをふせぐため、RDBの結果をメモリに格納しておく仕組みである。RDBは保存されたデータを永続化するために、SSDやディスクに対して書き込みを行う。それに対してインメモリデータベースはメモリにデータを常駐させておくので、アクセスが非常に高速である。
第1回 memcachedの基本：memcachedを知り尽くす｜gihyo.jp … 技術評論社
インメモリデータベースは大きく分けて2種類あり、MemcachedとRedisである。
Memchaced
インメモリデータベースのデファクトスタンダードであり、シンプルに処理のパフォーマンス向上に特化している。データの永続化機能はないので、再起動するとデータは消えてしまう。
複数のホストかた単一のDBにアクセスしていた場合、各インスタンスのデータの参照先を通常のDBからMemchacedに変更することでキャッシュが有効になる。MemchacedはEC2のAutoScalingと同じようにスケーリングし、最大20のElastiCacheインスタンスが立ち上がって、各ホストからのリクエストをバランシングする。全てのインスタンスが同じデータを保存するのではなく、各インスタンスに分散してでキャッシュデータが保存される。
スケーリングして新しいElastiCacheインスタンスが立ち上がると、新しいElastCacheに
Redis
MemchacedではString型しか扱えなかったのに対し、Redisでは様々な型を扱える。キャッシュの内容は永続化することが出来るため、再起動してもキャッシュの内容は生き残る。また、マスター/スレーブ型でコンテンツを配信することが可能で、マスターがダウンした場合のフェイルオーバーが可能など極めて高機能なインメモリデータベースである。
その他のDB
Amazon Neptune
Amazon Neptuneはグラグデータベース
グラフデータベースとはノード間の関係性を表すためのデータベースでTwitterのようなソーシャルグラフや経路検索に用いられる。
その他世界中の各口座の入出金関係を辿るためにマネーロンダリングの調査に使われたりする。
Amazon DocumentDB
フルマネージドなMongoDB互換のドキュメントデータベース。MongoDBは触れたことがあるので割愛。
Amazon Keyspaces
フルマネージドなApache Cassandra互換のドキュメントデータベース。MongoDBとの違いは、MongoDBがjsonのようなドキュメントでデータを保存するのに対して、Cassandraがテーブル・カラムにデータを保存する点。
そのため、列指向・行指向のデータを扱うのが得意で、まとまったデータも取得しやすい。
Cassandra vs MongoDB: 知っておくべきポイント | Xplenty
Amazon Timestream
フルマネージドな時系列データベース。
Amazon QLDB
Amazonの台帳データベース。ブロックチェーン関係のマネージドサービスではAmazon Managed Blockchainというのも存在する。こちらは、一般的なオープンソースフレームワークであるEthereamなどを利用して中央機関なしのデータの管理を行う。
一方QLDBは、データをイミュータブルにするだけで、中央集権的である。全ての履歴を記録することに主眼があてられている。
Amazon QLDB は新しい種類のデータベースで、台帳のようなアプリケーションを自分で構築するという複雑な開発作業を行う必要がありません。QLDB を使用すると、データの変更履歴はイミュータブル (変更や削除が不可能) なものになり、かつアプリケーションデータに対する意図しない変更が発生していないことを暗号技術によって簡単に検証できます。
