このメモは私自身の思考も入り混じって記載されています。話者の内容をそのまま記述したものではありませんのであしからずご了承ください。
話者：星野 豊さん
Amazon Aurora
- Amazonがクラウド時代にRDBを作るとどうなるかを1から考え構築したもの。
- 2015/05/20よりPreviewがプロダクションへ移行
- ライセンス料金不要
- ロックインもない（MySQL5.6と互換）
- 使った分だけ課金
特徴
- MySQL5.6互換
- MariaDB connectorsはAuroraとシームレスに動作
- 移行コストが抑えられる
- データをそのままインポートできる（ドライバも互換ってすごいな）
- MySQLのエコシステムにAuroraはフィットしている
- ストレージが10GBから64TBまでシームレスに拡張
- 3AZに2つずつ、計6つのコピーを持つ
- S3にストリーイングバックアップ
- VPC内に起動
- 99.99%の可用性
Aurora背景
- これまでのRDBMSは可用性・柔軟性で問題を抱えていた。モノリシック。
- AWSサービスを活かすこと、スケールアウトすること、セルフヒーリングすることを指向
アーキテクチャ
- Service Oriented Architecture
- 各コンポーネントが自分の責務だけを全うする。
- コンポーネント間のやりとりはAPIをベースに。
- Cacheレイヤは分離（リスタート時点にパージされずにすむ）。暖気する必要なさそう。
- SSDを利用したシームレスなストレージ。
- 容量に対して課金
- ログストラクチャードストレージ
Auroraのストレージ
- 6本中4本への書き込みが行われると、次の処理へ
- ホットスポットが起こったとしても、クエリの書き込み遅延などが起こらない自律的な制御
- 10GBのチャンク単位
- スレーブもマスタと同じディスクを参照
- 継続的なS3への増分バックアップ
ログストラクチャードストレージとは
- 追記型のストレージ・システム
- ディスクの先頭から追記していくだけの構築
- ひたすら後ろに新データを追加していくだけ
- シーケンシャルに読み出すことができる
- S3へのストリーミングバックアップ・高速リカバリを可能にしている
- GCのパフォーマンスインパクトは極小になるように制御
- ディスク障害が起こっても読み書きには影響ない
Auroraのレプリケーション
- Binlogを利用しない
- レプリケーション遅延がほぼない
- 15台のリードレプリカを作成可能
- リードレプリカはマスタサーバーとストレージを共有（レプリケーションが高速）
DBクラスタ
- AuroraはDBクラスタという概念をもっている
- マスター（Writer）とレプリカ（Reader）をひとまとめにしたもの
- クラスタエンドポイント（常にwriterノードを指し示す動作をする。有事に設定を書き換える必要がなくなる）
フェイルオーバーとリカバリー
- 1分程度でリカバリ可能（リードレプリカがあれば）
- 優先的にフェールオーバーさせるレプリカを指定することもできる
- 高速なデータ修復(10GBのチャンクごとに並列でリカバリ実施)
- PITR（Point In Time Recovery）で5分前から任意の位置に秒単位で復元可能・・まじか
- ストリーミングのバックアップはパフォーマンスインパクトはほとんどない
- SQLで障害をシミュレーション可能(!?) - 本番サービス前にテストできる
パフォーマンス
- MySQLと比べて5倍？
- クエリの並列度が高く、データサイズが大きい場合に効果が高い
- ロックが起こったとしても高速に開放するように構築されている
- MySQLに比べてCPU利用率が高い（効果的に利用している）
