【レポート】クラウド時代に再設計されたRDBMS・Amazon Auroraの最新情報から内部アーキテクチャ、運用Tipsまで #AWSSummit

AWS Summit Tokyo 2019

#レポート

#Amazon Aurora

#イベントレポート

#Amazon RDS

#データベース

渡辺聖剛

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

水曜よりより開催されています AWS Summit Tokyo 2019。こちらで開催された技術セッション B3-06 をレポートします。

Going Deep on Amazon Aurora with MySQL Compatibility

スピーカー（敬称略）

桑野章弘
- アマゾンウェブサービスジャパン株式会社
- 技術統括本部
- ソリューションアーキテクト
- 好きなサービス : DocumentDB,Route53

Amazon Auroraは、クラウド時代にAmazonが再設計したRDBMSです。また、システムを構築する上でデータベースを切り離すことはできません。 Amazon Auroraの最新情報や、リリースされてから行ってきた機能追加や安定性向上に対する取り組みと、その内部アーキテクチャをご紹介し、実環境で運用する際に注意する点などの Tips もご紹介します。

内容

Amazon Aurora
- クラウド上で動作することに特化して構築されたMySQLとPostogreSQL互換のリレーショナルDB
- OSSのいいところを使用できる、1/10のコストで商用グレードのデータベース
特色 - AWSサービスとの連携
- Lambdaのイベントをストアドプロシジャやトリガーから実行
- CloudWatchへログやメトリクスをアップロード
- IAMロールでDBユーザ認証
- S3をつかったバックアップデータの保存・リストア
パフォーマンスカイゼン
- 4年間でWriteスループット二倍、Read42％
- 多くのパフォーマンス最適化に加えて、HWプラットフォームもアップグレード
「AuroraはAWSの歴史の中で一番早く成長しているサービス」
- 基調講演でも触れられていた

Amazon Aurora Internal

Auroraストレージ
- SSDを利用したシームレスにスケールするストレージ
- 10GB〜64TBまでシームレスに拡張可能（無停止
- peer-to-peerゴシップレプリケーション
- 標準で高可用性：3AZに6つのデータコピー
- S3 に継続的なバックアップ
- Log structured storage
  - redo logを複数の小さなセグメントに分割
  - Log pageによってData ぱげを作成
Aurora I/O profile
- ASYNC 4/6 QUORUM
- MySQLとの比較
  - I/Oが1/7.7 堅牢ながらI/Oをへらすアーキテクチャ
ストレージノードクラスタ
- Protection Groupごとに6つのストレージノードを仕様
- 各ログレコードはLog Sequence Number(LSM)をもっている
  - 不足・重複しているレコードを判別
  - 不足している場合はストレージノード間でゴシッププロトコルを利用し補完を行う（自己修復）
ディスク障害検知と修復
- 2つのコピーに障害が起こっても読み書きに影響はない
- 3つのコピーに障害が発生しても読み込みは可能
- 自動検知・修復
- 「QUORUM」という仕組み
  - Write = 4/6
  - Read = 3/6
クォーラムモデル
- レプリケーション管理のためのクォーラムモデル
- なぜ6つにしたのか
  - AWSは大規模環境
  - AZ障害は影響範囲が広域
  - AZ+1の障害（二重障害)を許容し、修復する必要がある
  - 3つのAZの場合6コピーが必要
  - 6以上（12など）にすればもっと堅牢になる、がコピーする量がその分増えてしまう = バランスを考えて6に
メンバーシップチェンジ
- プロテクショングループは数千〜とかになる
- ほとんどのシステムは、メンバーシップの変更にコンセンサスを使用する > ジッタとストールを引き起こす
- AuroraはクォーラムセットとEpochを使用
- 停止無しのAZ+1フォールトトレランス、積極的に障害を検出可能
  - Epoch 1 全てのノードがヘルシー
  - Epoch 2 疑わしい状態のノードが検出されると、新しいノードが作成される。両方がアクティブ（7ノード）
  - Epoch 3 あやしいノードは案ヘルシーにしてまた6ノードにする
クォーラムの効率化
- ほとんどのクォーラムベースのシステムでは読み込みのコストがかかる
- Auroraはどのノードが最新でレイテンシが少ないかの情報をもっている
  - 6ノードのうち4ノードからACKが返ってきたら「書き込み成功」とする
  - これら4ノードのいずれかから読み取ると最新
- リードクォーラムは修理やクラッシュリカバリに必要
コストを抑える工夫
- 6つもコピーは全て同一ではない
  - 3つはフルセグ面と：データページとログレコード
  - 3つはテールセグメント：ログレコードのみ
- 物理的な容量は6倍ではなく、3倍より少し多い程度
  - ※課金されるのは実データ容量について（3倍にはならない
レプリケーション
- MySQL read scaling
  - binlog
  - マスターへの負荷がかかる
  - レプリケーション遅延が増加する可能性がある
- Aurora read scaling
  - 同じストレージを見ているのでそこまで遅くならない
  - マスターへの負荷を最小限に15台までリードレプリカを作成
  - マスターからリードレプリカへ「パージ」情報が送られる = 遅延
- Lock management
  - ロックフリーデッドロック検出
  - 個々のロックチェーン内の複数のスキャナ
  - 多くの同時セッションをサポートする、高い更新スループット

新機能

Custom Endpoint
- Auroraクラスター内の、どのインスタンスを含めるかをユーザが指定可能なエンドポイントが作成可能
- オンラインクエリ用のリードレプリカと分析クエリ用のリードレプリカを分離することが可能になる
Global Dtabase
- リージョン間でレプリケーション
- binlogは使わない
- Auroraストレージレベルでクラスタ間のレプリケーションを行う
- レプリケーション先には書き込みはできない
  - DRや、各リージョンで高速に読み取りしたい場合など
Aurora Serverless
- 負荷の少ないアプリ向け
- 可変負荷のアプリ、予測困難なピーク
- Auroraはデータベースのアプリケーション負荷を監視
- Request Router
- スケーリングのしきい値に達すると、インスタンスが自動的にスケールアップ・ダウンする
- スケーリング操作はアプリケーションに透過的
- スケーリングの最小および最大を設定可能
  - 最小値をゼロにもできる
  - 夜はとめておいて、朝誰かが使った起動、など
- 負荷に応じたスケールアップ・ダウン
Amazon Aurora Serverless Queries Directory from the AWS management console
- マネコンから直接クエリを投げさせる
- IAMで制御可能
Aurora Serverless Database with the New Data API
- HTTPSエンドポイントやSDKからのクエリアクセス
- JDBCとかいらない
- 永続接続は不可能
- サーバレスアプリケーション、軽量アプリケーション(IoTなど)
Parallel Query
- OLTPワークロードの分析クエリ・リアルタイムデータの分析
- クエリをストレージノードの数千のCPUにプッシュダウン
  - ストレージフリートを使用して問い合わせ堀をプッシュ
  - 各ノード上でクエリを実行
  - データに近い位置で実行、ネットワークのトラフィックとレイテンシを軽減
Performance Insight
- もっとデータベースにドリルダウンしてみてみたい場合
- 例えば、重いクエリがどのロックで待っていたのか
  - ニアリアルタイムで確認可能
Backtrack
- データベースの状態を、容量に寄らず瞬時に特定の時点へ巻き戻す
  - オペミスなどをしてしまった場合に、作業実行前の状態にすぐに巻き戻す
Database Cloning
- ストレージコストを増やすことなくデータベースのコピーを作成
  - データのコピーをするわけではない
    - CoW
  - プロダクションデータを使用したテスト、DB再構築、プロダクションシステムに影響を及ぼさずにスナップショットを取得
AuditログをCWLogsで管理
- 特定ログでアラート発報などもできるように
- 事前にAuroraに対してIAMロールの設定が必要