【レポート】Aurora Architecture Night – Tokyo – 20181120

佐々木大輔

2018.11.20

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

はじめに

本記事は2018年11月20日に開催されたAurora Architecture Nightのレポートです。

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

会場はAWS Loft Tokyo。

レポート

Deep Dive on the Amazon Aurora PostgreSQL-compatible Edition

スピーカーはアマゾンウェブサービスジャパン株式会社の江川大地さん。

・Auroraの利用状況について
　・Auroraの話を初めて聴く人→若干名
　・Auroraを利用したことが無いがAuroraの話は聞いたことがある人→数名
　・Auroraを利用中の人→ほとんど
　　・MySQL compatibleの人→多数
　　・PostgreSQL Compatibleの人→少数

・Aurora Overview
　・AWSがクラウド時代に再設計したデータベース
　　・RDBMSをクラウドの利点を活用して再設計したもの
　・MySQL 5.6/5.7、PostgreSQL 9.6/10と互換性がある
　・Aurora Storage and Replicas
　　・アプリケーションからのアクセスを受け付けるマスターインスタンス
　　・SQLを解釈するエンジンとは独立してストレージを有する
　　・複数のAZに6つのコピーを持つ
　　・Log record(更新差分)のみを書き込み
　　・一つのBlockから読み込み
　　　・基本はローカルAZから読み込み、ケースによっては他AZから読み込む
　　・あるストレージがクラッシュしても他のコピーから復旧可能
　　・リードレプリカを持つことが出来る
　　　・アプリケーションの負荷に応じて複数のリードレプリカを持つことが出来る
　　　・マスターインスタンスに障害が発生した場合リードレプリカを昇格することで復旧可能
　　・ストレージは64TBまで自動的にシームレスにスケール
　　　・動的にスケールするためリーズナブル

・PostgreSQL Compatibility
　・2017年10月にGAリリース
　・2018年2月に東京リージョンでも利用可能に
　・PostgreSQL 9.6/10と互換性を持つエンジン。
　・強固なストレージによりスケーラブル、堅牢、セキュア。
　・スナップショット経由でRDS for PostgreSQLから簡単に移行可能。
　・低コスト。ライセンスコストが気になるお客様の受け皿になっている。

・Compatibility
　・SQLやクライアントアプリケーション、プロシージャがそのまま使える。
　・RDS for PostgreSQLで使える拡張モジュールはそのまま利用可能。
　・RDS for PostgreSQLのスナップショットから移行可能。

・最近のアップデート
　・バージョン10系をリリース。
　　・ネイティブ・パーティショニング、パラレルクエリ強化、e.t.c.
　・対応リージョンは一部のみ。東京はまだ使えない。
　・拡張モジュール。
　　・GIS、データ暗号化/復号、ストアドプロシージャ、サードパーティのモジュールなど。
　　・dblink
　　　・Auroraから外部のPostgreSQLにアクセス可能。
　　　・関数を使うので多少複雑な書き方になるのでViewでマスクをするケースも。
　　・postgres_fdw
　　　・関数を使わずに透過的に外部のPostgreSQLにアクセス可能。
　　　・開発効率的にはこちらのほうが今後よく使われるのでは？
　　・AWSの他サービスとの連携
　　　・dblinkやpostgres_fdwを使うことでRedshiftと連携することも可能
　　　・ユーザーはAuroraにSQLを投げるが、バックエンドでRedshiftと連携できる
　　　・postgres_fdwがリモートでのAggregationに対応したのはPostgreSQL 10以降。
　　　　・9.6系の場合はdblinkを使うこと。

・Architecture from PostgreSQL Perspective
　・Log Bufferの使い方の違い。
　　・PostgreSQLの場合、Log Bufferを大きめに持つことで書き込み性能の向上に寄与できる。
　　　・しかし、Bufferのデータがストレージに書き込まれるまで次の書き込みがQueueでストップするため、速度が上がらない。
　　・Auroraの場合、Log Bufferを持たずに即時ストレージに書き込み。
　　　・Durability Trackingによりストレージへの書き込みを監視し書き込みの確定を判断。
　　　・書き込み順を制御。
　　　・Log Bufferでの待ちが発生しないため速い。
　・ChekpointとFull-Page Writes。
　　・Auroraのストレージはチェックポイントが無い。
　　・通常、チェックポイントのあとの書き込みはFull Page Writeが発生する。
　　・Auroraはチェックポイントが無いのでFull Page Writeが発生しない。
　　・データベースが小さい場合は問題にならないが、大きい場合はFull Page Writeで遅くなる。
　　・ベンチマーク結果。Auroraはチェックポイントが発生せず性能低下が無い。
　・リカバリにかかる時間も短い。

・Vaccuming
　・無効化されたデータを削除しブロックを再利用可能にする
　　・Vaccumしないと不要領域を回収できず多くのブロックが使えなくなる。
　　・キャッシュミスの増加、HOT更新負荷、Full Page Writeの増加に繋がる。
　・ベンチマーク結果。Vaccumをしないとどんどん性能劣化する。
　・トランザクションID周回問題にも注意。
　　・CloudWatchにメトリクスがある(MaximumUsedTransactionsIDs)
　　・監視と通知が可能。
　・AuroraではVaccumをうまく工夫している。
　　・Freeze mapを観ることでnon frozen(Vacuumが必要な領域)を確認可能。
　　・一回のBatchでnon frozenだけを適切にVaccum。

Amazon Aurora - Latest innovations and updates behind Aurora’s torrid growth

スピーカーはアマゾンウェブサービスジャパン株式会社の星野豊さん。

・Auroraはサービス
　・MySQLやPostgreSQLのコンパチがコアコンポーネントではない。
　・本当のコアコンポーネントはストレージクラスタ。

・専用に作られたストレージ
　・3つのAZに分散。
　・10GBから64TBまでシームレスにスケール。
　・1個のデータブロックが書かれると3つのAZに6つのコピーを保持することで堅牢化を担保。
　・マスターとスレープが同じストレージを参照することで速い速度でレプリケーション。

・通常DBAが管理するバックアップやリカバリなどをサービスで自動化
　・本来するべきクエリの性能改善などに専念してほしい。

・MySQL 5.6/5.7より5倍以上速い
　・MySQLのパフォーマンスはギザギザになる
　・Auroraのパフォーマンスは平ら。

・クラッシュリカバリをエンジンではなくストレージで行っている
　・だいたい20秒以下でフェイルオーバーが完了

・Auroraの新機能
　・Backtrack
　　・ポイントインタイムリカバリではリカバリに時間がかかる
　　・Backtrackでは容量に依らずほぼ瞬時にクラスタの中身を戻すことが出来る
　　　・Backtrackを実行するとクラスタがオフラインになり、数分で指定された時間に巻き戻る。　
　　　・Backtrakされた時間から更に戻ったり進んだりすることも可能。
　　　　・戻ったあと書き込みが発生したら進むことはできない。
　　・Auroraはすべての変更をLog recordとしてストレージに保存。
　　　・エンジン側でLog recordについてのメタデータを保存。
　　　・Backtrackではメタデータ(ロジカルシーケンスナンバー)を指定することでその状態に戻る。
　　・Backtrack用のストレージが必要になるため、追加の課金が発生。
　　・Maxで72時間まで戻ることが可能。
　　　・Target backtrack windowsが設定した時間、Actual backtrack windowsが実際の戻せる時間。
　　・Backtrackは、指定された時間に最も近い、ストレージの中で堅牢なポイントに戻る。
　・Aurora Serverless
　　・Auroraのインスタンスをユーザーから隠蔽し、エンドポイントだけが見える。
　　　・エンドポイントに対してクエリを投げる。
　　　・あまり使用されていないシステムや負荷の低いシステム用。
　　・Provisioning
　　　・ストレージボリュームを作成。
　　　・プロキシエンドポイントを作成。
　　　・ユーザーからはプロキシのみが見える。
　　　・CPU、メモリ、接続の使用量によってスケール。
　　　・スケール中はアプリケーションを切断せずにインスタンスが変更される。
　　　・定義された非アクティブ時間が経過するとインスタンスが削除
　　　　・データベースが停止している間はストレージ料金のみ発生
　　　　・クエリが発生するとWarmPoolからインスタンスを持ってきて起動
　　　　・コスト最適化が可能
　　　・スケール範囲はMin/Maxの設定が可能
　　　・インスタンスはほぼ1台、キャパシティもr4.16xlargeまで。
　　　　・それ以上のRead/Write性能が必要な場合は通常のクラスタを利用することを推奨。
　・Performance Insights
　　・Aurora MySQL 1.17.3以上で対応
　　・performance_schemaが有効になる
　　・多少のスループット低下が発生する。
　・Parallel Query
　　・分析クエリを実行
　　・ETL処理を不要に
　　・Auroraストレージの余っているCPUを使って実行
　　・ヘッドノードで実行していたクエリをストレージ側で実行することで速度向上
　　・Optimizerがパラレリクエリプランを作成
　　・Executorが実行手段を判断
　　・各ストレージノードは最大16個のパラレリクエリを実行
　　・InnoDBのキャッシュをスキップするのでディスクI/Oが増える傾向にある。

・開発中の機能
　・Multi-Master
　　・AWS re:Invent 2017で発表
　　・現在Preview中
　　・チャレンジングな機能なので開発に時間がかかっている
　　・High AvailabilityとWrite Scalingの観点。
　　・マスターノードやAZに障害が発生しても読み書き障害が発生しない。
　　・コンフリクトの解決
　　　・ストレージで先にコミットしたものを優先、負けたトランザクションはロールバック。
　　　・コンフリクトが起こるとスループットが落ちる、アプリケーション側で意識が必要。
　・Global Replication - Physical
　　・任意のリージョン間で1秒以下でレプリケーション
　・Multi-Region Multi-Master
　　・Multi-MasterとGlobal Replicationの組み合わせで実現

Amazon Aurora Under the Hood - Aurora の分散ストレージ

スピーカーはアマゾンウェブサービスジャパン株式会社の柴田竜典さん。

・知らなくてもAurora使えるけど、知っていると夢が膨らむ話をします

・Service Oriented Architecture
　・エンジン部分とログ/ストレージを分離することでシームレスにスケール
　・管理コンポーネントはAWSの一般的なサービスを利用
　・Amazon S3に継続的にバックアップ
　　・キャッシュレイヤの分離
　　・データベースプロセス外にキャッシュを保持
　　・データベースプロセスが再起動してもキャッシュが消えない
　　・再起動直後でも性能が劣化しない
　・Auroraを構成するコンポーネント
　　・Master(ライター)とReader(リードレプリカ)
　　・AZをまたがって一つのクラスタを作ることが出来る
　　・論理的な一つのストレージが3つのAZにまたがって存在
　・Auroraエンドポイント
　　・クラスターエンドポイント→常にライターに繋がる。
　　・リーダーエンドポイント→いずれかのレプリカに繋がる。
　　・カスタムエンドポイント→ユーザーが指定したインスタンス群に接続。
　　　・アプリケーションごとにグルーピングすることでキャッシュを有効的に利用可能に。
　　・インスタンスエンドポイント→各インスタンスごとのエンドポイント。
　・セキュリティ
　　・データの暗号化
　　　・Auroraストレージ、バックアップ、全て暗号化されている。
　　・通信の暗号化→SSL。
　　・VPCを使った分離。
　　・ノードへの直接アクセスは不可。OSレイヤを意識する必要がない。

・Aurora under the hood
　・Auroraストレージ
　　・クォーラムシステムを使った分散ストレージ。
　　・分散ストレージの実現方法。
　　　・レプリケーション。
　　　　・同期→レイテンシが伸びてしまう。一番処理が遅いインスタンスがボトルネックになる。
　　　　・非同期→データ同期前に障害が発生するとデータロストが発生してしまう。
　　　・クォーラム
　　　　・3つのAZにあるストレージに同時に書き込み命令。
　　　　・6つの書き込みのうち4つから応答があれば書き込み完了。
　　　　・読み書きを完了させるためのクォーラムのルールがある。
　　　　　・6台のコピーの場合、書き込みは4台、読み取りは3台が完了すればOK。
　　　　　・2つのコピーに障害が起きても読み書きに影響なし。
　　　　　・3つのコピーに障害が起きたら書き込み不可、読み込みは可能。
　　　　　・障害を自動検知、自動復旧する。
　　　　・なぜ6つのコピーが必要なのか。
　　　　　・AZ障害は影響範囲が大きい。
　　　　　・AZ障害は長時間停止する可能性が高い。
　　　　　・AZ障害が発生した場合、他の環境で障害が発生すると二重障害になる。
　　　　　・AZ障害に加えてもう一つの障害が発生しても止まらないように6つのコピーを作成。
　　・MTTRの短縮。
　　　・セグメントを小さくすることで修復が短くなる。
　　　・Auroraは10GBのセグメントで管理。
　　　・障害が発生した場合10GBごとに復旧が可能。
　　・ストレージノードクラスタ
　　　・ストレージノードを10GBごとの論理ブロックに分割。
　　　・ストレージノード間でゴシッププロトコルを使い、不足した情報を補完し合う。
　　・ストレージノードクラスタの変更
　　　・クォーラムとエポックを使ってジッタとストールを防止。
　　　・疑わしいノードが発生したら現在のエポックとは別のエポック(クォーラムグループ)を作成。
　　　・ノードがUnhealtyだと確認出来たら新しいクォーラムグループがアクティブになる。
　　　・疑わしかったらすぐ次のグループを作り、Unhealtyだとわかったらすぐ切り替えを可能に。
　　・長期間のAZ障害が発生した場合
　　　・デグレードモードにより3/4クォーラムへ切り替えることで書き込みが止まらない。
　　・一般的なクォーラムにおける課題
　　　・読み取り/書き込みのコスト
　　　　・ネットワーク負荷、ストレージに対する読み込み、ストレージ容量
　　　　・Aurora
　　　　　・ログレコードのみをストレージノードに送信することでネットワーク負荷を軽減
　　　　　・クォーラムにより読み込み負荷を回避。
　　　　　　・どのノードが最新でレイテンシが低いのかの情報を保持。
　　・容量
　　　・6つのコピーは全て同一ではない。
　　　　・3つがフルセグメント、3つが差分のみ。
　　　　・6つのコピーが必要だが、必要な容量は3倍ちょっと。
　　　・ストレージ料金は実際に使った容量のみ、コピーについては意識する必要がない。