データベース編です。正直苦手分野だけど頑張って覚えていきたいと思う。
まず、こんなような違いがある
表をここに作る…
トランザクション処理は、一連の処理ってこと。（〇〇をして△△をしてワンセット的な）
RDS
Amazon Relational Database Serviceのこと。よーするにメジャーなmySQLとかMariaDBとか使える。
異なるAZでデータを複製する、multi-AZ構成な可能。よーするにデータの複製をほかのAZに置ける。稼働系をプライマリ、待機系をスタンバイという。
プライマリが障害などで死んだら、待機系に自動フェイルオーバーしてくれる。
OSのパッチ適用の場合、待機系からやってくれる。
リードレプリカ
書き込み用ロードワーク（DBに変更が起こるもの）はプライマリDBへ。読み取り用ロードワーク（DBに変更が起こらないもの）はリードレプリカを参照することによって、負荷が軽減できて効率がいい。
最大5台つくれる。Auroraなら15台。
ストレージタイプ
汎用、プロビジョンドIOPS、マグネティックの3種類がある。どっかで聞いたなこれ。
EBSと同じで汎用が普通の、プロビジョンドIOPSが優秀の、マグネティックはちょっと古いのだ。
というかログやデータベースの保存先はEBSなのでまんまEBSやんこれ。
ストレージ容量は稼働中に増やすことができるが、減らすことはできない。新しく作ってそっちに移行しなきゃだめ。
ちなみにプロビジョンドIOPSだけキャパシティ課金がある。早いから代償か。
マグネティックは取り出すときにもお金かかるよってやつ。
バックアップ
自動でバックアップ作成、保存してくれる。バックアップの時間を指定すれば、事前に設定したバックアップ保持期間の期間だけ保持してくれる。7日間保持に設定すれば7日前のバックアップまでは戻れる。
手動でもバックアップ可能。
DBを削除するとき、自動バックアップは消えるが手動バックアップは消えない。
multi-AZにしていない場合、プライマリDBで障害が発生した場合、自動のバックアップからリストアしてくれる。そして、アプリとかの接続先をリストアされた新しい方に向けてくれる。有能。
メンテナンスウィンドウ
RDSのメンテをするには、オフラインにする必要がある。
セキュリティパッチやインスタンスの信頼性に関するパッチだけは必須として自動的にスケジュールされる。
また、すべてのDBインスタンスには週次のメンテナンスウィンドウがある。変更やソフトウェアのパッチ適用が来た際に、タイミングを指定できる。
例えば、来週の何時から何時って指定したらその間にやってくれる。スケジューリング。
DBがmulti-AZの場合、まずはスタンバイDBから。（前述）
そのあと、スタンバイがプライマリになって（切り替え）、スタンバイになったDBにメンテナンス実行される。（自動切り戻しされない）
Aurora
名前が好き。
AWSが提供してるDBエンジン。
特徴は、高度なmulti-AZ、自動復旧、大容量ストレージのサポート、高いスループット。
普通のRDSなら2つのAZに一台ずつのレプリケーションだが、Auroraなら3つのAZに2台ずつ。つまり最低6台。
ストレージも通常32TiBのところ、64TiB。
リードレプリカも前述のとおり3倍の15台。
データ損失がないうえ、自動フェイルオーバーもしてくれる。
しかしレプリケーションは非同期的。ミリ秒単位。
Auroraのデータはクラスターボリュームというとこに保存される。
3つのAZにそれぞれ2つずつクラスターボリュームが作られる。要するに、上記レプリケーションとは別に、6つのクラスターボリュームがある。データコピー。
インスタンスが6この、データコピーが6こって感じ。
フェイルオーバーの際は、使用可能なリードレプリカに自動的にフェイルオーバーしてくれる。
クラスターエンドポイントというものがあるため、フェイルオーバーが発生しても参照先を変える必要はない。クラスターエンドポイントが自動的に参照先切り替えしてくれる。
まあこのへんはRDS使ってるから同じって考えれば。
DynamoDB
マルチリージョンの高速なNoSQL。
リクエストされた大量の連続したデータを高速にデータベースに蓄積できる。
たとえばログとか。SNSアクセス情報とか。IoTとか。
テーブルを自動的にスケールアップ、スケールダウンして、容量を調整して、パフォーマンスを維持してくれる。
データ容量の制限はない。テーブル内の各項目が400KBという制限はあるが。
3つのAZで書き込みをしている。しかし、2つ書き込まれたら書き込み完了の判定になる。残り一個は時間が経ったら同期される。
つまり、S3と同じ。結果整合性モデル。読み込みタイミング悪いと更新前のデータが帰ってくる場合がある。
これがいやなら、強力な整合性のある読み込みオプションを指定すれば最新のデータを受け取れる。しかし、読み取り速度は遅くなるしコストもかかる。
ElastiCache
セッション情報やアプリケーションの一時データに高速アクセスできる。
しかし利用できるデータ量に制限がある。パフォーマンス重視の場合は、ElastiCacheに一時的にデータ格納して処理すると早い。
エンジンは2種類ある。
- Memcached用ElastiCache
扱うデータ型、暗号化、高可用性構成、コンプライアンスなどの対応が不要なシンプルなやつ。マルチスレッド対応。並行処理できる。
- Redis用elastiCache 複雑なデータ型、暗号化、高可用性、コンプライアンスへの対応ができる。しかしマルチスレッドはなし。
要するに細かい書き込みめっちゃ早くてでかいのがDynamoDB。容量制限あるが取り出しめちゃくちゃ早いのがElastiCache。
Redshift
データウェアハウス。たくさんの量のデータを入れておいて集計とかできる。
アプリケーションからのリクエストを1つ以上のノードで分散処理することで、高速なデータ処理ができる。
また、列指向型（普通行で横に処理していくが、列なら縦に処理する。）で大容量データへのI/Oを削減してる。
同じ分類のデータの集計や分析が早い。
適したワークロードは、ペタバイト級のデータを扱う時や、一つのSQLが複雑で同時実行が少ないときや、データを一括で更新するとき。
同じ大容量のDynamoDBは細かいデータを処理するのが得意だったけど、Redshiftは大きいデータを一括でやりたいタイプ。
適したシナリオはBIツールによるデータ分析、データウェアハウス、データ集計など。
Redshiftのアーキテクチャ
クラスターで構成され、1つのリーダーノードと複数のコンピューティングノードで構成。
リーダーノードはリーダーなのでコンピューティングノードに指示を出す役割。
コンピューティングノードはリーダーからもらった指示の実行や、実行後の中間結果を返送したりする。
アプリケーションはリーダーとやり取りなので、コンピューティングノードを気にしない形になってる。
コンピューティングノードではメモリ、CPU、ディスクストレージが分割され、データも分散して格納される。その分割（スライス）毎にデータの並列処理ができるため、高速なデータ処理ができる。
メモリなどはノードタイプによって決まる。
ノードタイプ
Dense Compute
DC。SSDで高パフォーマンス。500GBまではこっちがコスパいい。
Dense Storage
DS。HDD。コスト削減やスケール拡大がありそうならこっち。
バックアップ
S3へ自動バックアップ。最大35日まで保持できる。任意のタイミングの手動バックアップもできる。手動は自分で消すまで消されない。
クラスター削除するときに、スナップショットとっておくか聞かれる。復元したいならそれを使えばいい。
ノード障害
クラスター内で障害発生した場合、障害ノードを自動的に検知して障害ノードを新しいノードに交換してくれる。
交換完了するまで更新不可。交換完了したらよく使うデータをS3から持ってきて速やかな更新が行えるようにする。
ノードが一つしかない場合、ノード障害が起きてしまったらスナップショットから復元しなきゃいけなくなるので、最低2つ以上のノードを使っておくと安心。
Redshift Spectrum
データウェアハウスとして使ってると、容量大きくなり、ロードに時間がかかったりする。
そのためこいつの出番。S3にあるファイルを外部テーブルとして定義し、アクセス可能になる。普通ならコピーしなきゃいけなかったものが、こいつを間に噛ませることによって直接参照できるようになる。
以上！表は後で追加する！