Aurora Architecture Night - Tokyo - 20181120
公式ページ
https://auroraarchitecturenighttokyo20.splashthat.com/
会場はAWSLoftTokyo（目黒）での開催でした。
Deep Dive on the Amazon Aurora PostgreSQL-compatible Edition
★Auroraとは
クラウド時代に再設計したデータベース
MySQL、PostgreSQLに互換性
構成要素：マスターインスタンスとストレージコンポーネントからなる
ストレージコンポーネントはAZにまたがって６つのコピーをもっている。
・書き込み時は複数AZに書き込み
・読み込み時はローカルAZが優先だが、他AZの場合もあり
リードレプリカは複数持てる、マスタがダウンした場合はレプリカが昇格、障害マスタはレプリカで自動復旧
ストレージがスケールするのでリーズナブル（サイジング不要で自動拡張、使った分だけ（MAX64TB））（RDBは確保領域で課金）
★PostgreSQL For Auroraとは
・PostgreSQL互換
PostgreSQL9.6,10との互換性あり。
SQL、Dump、プロシージャなど
RDSと同じ拡張モジュールが使える
GIS（地理情報）、暗号化、プロシージャなど
dblink、Postgres_fdwやRedShiftなどの他のPostgreSQLインターフェースを持つサービスと連携可能
Redshift→Aurora(PostgreSQL）の連携などをDBlink経由などで可能
分析した結果をAuroraに返すなど
・高いスループット
・スケーラブル、堅牢、セキュア
・RDSから数クリックでマイグレーション可能（スナップショット経由）
★PostgreSQLとの違い
・AuroraではLogBufferを排除している。
PostgreSQLでは大量更新時にLogBufferの処理待ちで待たされる場合もある
Auroraではキューを分割してストレージに直接書き込みを行うため待ちが少ない
→別途トランザクションをトラッキングする機構（durabilityTracking）がある
★Checkpoint処理
PostgreSQLはCheckpoint処理がおこるため遅くなる
AuroraではFullPageWriteがおこらないため、処理能力の低下が少ない
★リカバリ速度
PostgreSQLは容量に応じてリカバリ時間が比例してかかる
Auroraはredoを持たないため高速にリカバリ可能（容量比例なし）
★Vacuum（バキューム）
PostgreSQLは追記の仕組みになっているため、更新する場合も、既存を無効にして新たに作っている。
そのため不要領域が発生する。
Vacuum処理は不要領域を回収している。
更新を繰り返していくとVacuum処理をしない場合、TPSがさがってくる
Vacuum処理もAuroraの方が86%早い（コピーなどを考慮しても50%以下になる）
Amazon Aurora - Latest innovations and updates behind Aurora’s torrid growth
★Auroraのストレージクラスタが本体機能
3AZに6つのデータを保持
スケールアップ
S3へのストリーミングでバックアップ
MySQLよりAuroraの性能が5倍いい
エンジンで行っていたチェックポイント処理をストレージ側で行うことで
スパイクの対応を受けないようにしている。
クラッシュリカバリもエンジンではなくストレージクラスタ側で行っていることで高速化
クラッシュしても大体20秒以下でフェイルオーバーする。
★Auroraの最新機能
・BackTrack
メンテナンス時にミスったときなどに瞬時に戻す機能（やってはいけないクエリを投げてしまったなど）
数TBでも数分で戻る、行ったり来たりも可能
（裏側では）ログレコードにロジカルシーケンスを付与しているため、
戻す地点までの間の更新を見えなくしてしまう様な処理を行っている。
追加課金が必要（100万Changeレコードにつき$0.014）
保持期間は最大3日間だが書き込みが激しいと少なくなる。（CloudWatchのメトリクスで確認できる）
あくまでオペミスからのリカバリ機能
・AuroraServerless
あまり使用されていない環境用、負荷の少ない本番サーバー用
利用者からはNLBのエンドポイントのみがわかる
スケールアップには2,30秒程度応答にかかる（接続は切らない）
（アプリ側のタイムアウトは30秒以上に）
開発環境などで、夜インスタンスは停止、朝一発目のクエリは2,30秒かかるがインスタンスが上がってくるなどの使い方
スケールアップの範囲はMIN-MAXで設定可能
利用できるインスタンスタイプには制限あり
・パフォーマンスインサイト
DBに詳しい人がいなくても、監視の可視化が可能となる。
ほぼリアルタイムでどのクエリが実行されているかわかる（グラフも）
パフォーマンススキーマを有効化する必要があるため10-15%低下する。
・Parallelクエリ
ストレージクラスタ側はCPUが余っているので、利用しようと思って追加
PQのエンジンで分析クエリかどうかを判断して処理を分岐している
GAだが開発途上
・そのほかこれから出す機能
・MultiMaster（プレビュー、去年のReinventで発表）
コンフリクト解決
コンフリクトの場合、先にコミットしたもの勝ち
ロールバックをストレージからマスターに通知してロールバックさせる。
コンフリクトを最小化するためには
アプリケーション側である程度パーティショニングする必要あり
・GrobalReplication -physical-
リージョン間でも1，2秒程度の遅延で済む
→上記をあわせてMultiリージョン-Multiマスターを開発中
Amazon Aurora Under the Hood - Aurora の分散ストレージ
・既存のサービスの組み合わせでAuroraを構成している
EC2,VPC,DynamoDB,SWF,Route53他
・キャッシュレイヤの分離
キャッシュは通常DBプロセス内にあり、消えることがある。
AuroraはキャッシュをDBプロセス外に置くことで、保持される。
・Auroraのエンドポイントは4種類
プライマリ：クラスタエンドポイント
いずれかのレプリカ：リーダーエンドポイント
ユーザー指定：カスタムエンドポイント
インスタンス指定：インスタンスエンドポイント
★Aurora Under the Hood
・Auroraのクォーラムモデル
コピー数は６なので読み書きクォーラムを４に設定している。
RDSは書き込み完了まで待たないといけないが、
Auroraは4/6のストレージに書き込み完了すればコミット完了になる。
（調子が悪いストレージがいても影響を受けない）
２つのコピーに障害が起こっても読み書きOK
→自動検知、修復
・ストレージノードクラスタ
10GB単位のProtectionGroupで管理している。
障害等で書けなかった場合はストレージ側で補完
・デグレードモード
大地震等AZ障害の長期化への備えとして
3/4クォーラムに切り替えることも可能（AWS判断）