この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
re:Invent 2016に参加してきた大栗です。
re:Invent 2016で DAT303 - Deep Dive on Amazon Aurora というセッションに参加してきましたのでレポートします。Auroraの内部については、今までも情報が公開されているため新機能に注目してみます。
DAT303 - Deep Dive on Amazon Aurora
Anurag Gupta, VP Databases Services
アジェンダ
- Auroraとは？
- Auroraの性能のレビュー
- 新しい性能の強化
- Auroraの可用性のレビュー
- 新しい可用性の強化
- その他の今後の機能拡張
Auroraとは？
オープンソース互換のリレーショナルデータベース
商用データベース並の性能と可用性
オープンソースデータベース並の使いやすさとコスト効果
Auroraの性能のレビュー
Auroraはインスタンスサイズに対してREAD/WRITE共にスケールします。
どうやって達成したのか？
より減らす
- I/Oを少なく
- ネットワークパケットを最小化する
- キャッシュを効果的に
- DBエンジンをオフロード
より効果的に
- 非同期処理
- レイテンシのパスを減らす
- ロックフリーなデータ構造を使う
- バッチ処理を一緒に行う
新しい性能の強化
キャッシュされたデータの読み込み性能
2015年から性能が向上しています。
- カタログの並列度
- NUMAを意識したスケジューラ
- ビューの読み込み
キャッシュされていないデータの読み込み性能
2015年から性能が向上しています。
- スマートなスケジューラ
- スマートなセレクタ
- 並列先読み
ホットな行の競合
バージョン1.9で導入された機能でCPU使用率を低減して多数の接続時にスループットが向上します。Percona TPC-C 100のスループットで29倍向上。
Percona TPC-Cの10GBと100GBは以下の通り
その他の強化
- バッチインサート性能
- インデックス構築の高速化
- 空間インデックス
Auroraの可用性のレビュー
ストレージの耐久性
継続的なS3へのバックアップ(99.999999999%の耐久性)など
Auroraのレプリカ
1台のプライマリノードに対して15台のレプリカを作成できる
継続的バックアップ
各セグメントでスナップショットが定期的に並列で行われて、ストリームで継続的にREDOログをS3へ送る。
継続的バックアップでパフォーマンスや可用性の影響は無い。
高速なクラッシュリカバリ
既存データベースでは最後のチェックポイントからログを適用していく。しかしMySQLはシングルスレッドなので完了まで時間がかかる。 Auroraではディスク読み込みの一環として7オンデマンドのREDOログ適用を行う。並列、分散、非同期で行う。
生き残るキャッシュ
キャッシュはデータプロセスの外にあるので、データベースプロセスが再起動してもキャッシュが残った状態を維持する。
より速いフェイルオーバー
障害判定とリカバリが高速に行われる。
新しい可用性の強化
可用性の低下は、以下の時に起こります。
- データベースのパッチ適用
- データベーススキーマの変更
- 大規模なデータベース再編成を行う
- ユーザの間違いの後のデータベースリストア
ダウンタイム無しパッチ適用
ネットワークの状態やアプリケーションのコネクションを引き継いだ状態で、DBエンジンを旧DBプロセスを死んDBプロセスへ引継ぎます。
データベース・クローン
ストレージの複製コスト無しにデータベースのコピーを作成する
- クローンの作成はほぼ即時（データコピーが無い）
- 書き込みでのみデータコピーを行う（元データとクローンボリュームのデータが異なる場合）
オンラインDDL
- Auroraでは、エントリーされた時にメタデータテーブルを追加して、スキーマのバージョン管理を使用してブロックをデコードする
- 変更時にブロックを最新のスキーマへアップグレードするための書き込み変更時プリミティブを追加した
- 現在テーブルの最後にNULLを入力可能なカラム追加をサポート
- 優先順位は絡む追加のサポート、ドロップ/並べ替え、データタイプの変更
オンライン ポイントインタイム リストア
オンライン ポイントインタイム リストアはバックアップからのリストアをせずに、特定の時点にデータベースを素早く戻す方法です。
| オンラインPiTR | オフラインPiTR |
|---|---|
| オンラインPiTRの操作は現在のDBの状態を変更する | PiTRは希望する時刻の現在DBのバックアップから新しいDBを作成する |
| 現在のDBは数秒で利用可能、数TBのDBでも | 新しいDBインスタンスは数TBのリストアに数時間かかる |
| 既存DBから追加のストレージコスト無しに前の時点に戻る | それぞれリストアされたDBのストレージに課金される |
| 複数のオンラインPiTRは実用的 | 複数のオフラインPiTRは時間がかかる |
| 戻しは購入した期間に基づいた戻し期間内で許可される | オフラインPiTRは設定したバックアップウィンドウかスナップショットでなければならない。 |
| クロスリージョンのオンラインPiTRはサポートされていない | AuroraはクロスリージョンのPiTRをサポートしている |
その他の今後の機能拡張
PostgreSQL互換Aurora
PostgreSQL互換AuroraがPreviewになった。
小さいインスタンスサイズ
db.t2.mediumがリリースされており、t2.smallが2017年Q1に出る。
第三者認証
PCI/DSSとHIPAAの認定
監査ログ
MariaDBのAudit Pluginより高速に動作する。
AWSエコシステム
- AuroraのストアドプロシージャからAWS Lambdaのイベントを起動できる
- Amazon S3からデータをロードしたり、S3にあるスナップショットやバックアップからリストア
- IAMRoleによるDBのアクセスコントロール NEW
- システムメトリクスと監査ログをCloudWatchへアップロード 2017 Q1
MySQL互換
MySQL 5.7互換で動作
タイムライン
| 現在利用可能（1.9） | 12月に利用可能（1.10） | 来年Q1に利用可能 | |
|---|---|---|---|
| パフォーマンス | ロック圧縮 スピンロックをブロッキングfutexへ置き換える インデックス構築の高速化 |
空間インデックス | コピーオンライトボリューム |
| 可用性 | 高速なオンラインスキーマ変更 マネージドなMySQLからAuroraへのレプリケーション |
クリスリージョンスナップショットコピー オンラインPiTR データベース・クローン ダウンタイム無しパッチ適用 |
|
| セキュリティ | PCI/DSS HIPAA/BAA |
監査ログ | |
| エコシステム | t2.medium | IAM統合 | t2.small メトリクス、監査のCloudWatch連携 |
さいごに
個人的にAuroraは好きなサービスなのですが、まだまだ進化は止まらないようです。今後のアップデートが目白押しですが、高速化だけでなく監査ログ、IAM統合、ダウンタイム無しパッチ適用などの安定運用に関するアップデートが多数見受けられます。今まで以上にエンタープライズな環境での利用を想定しているのでしょう。PostgreSQL互換という大きなアップデートもあったため、今後AWSでRDBMSを使用する場合は基本的にAuroraという事になっていきそうです。
14
