【レポート】DAT202 – Getting started with Amazon Aurora #reinvent #DAT202

ベルリンの半瀬です。
re:Invent2017に,,,,,参加しておりません！が、各セッションがSlideShareやYouTubeにアップロードされてきているようです。

最近ますますクラスメソッドへのお問い合わせが増えてきているAuroraについて、理解を深めたいと思っていました。ちょうどいいセッションがあったので、そのご紹介をしたいと思います。そもそもAuroraって何がいいのか、もう一度知る機会となったかなと思います。。。

はじめに

本記事は、現在ラスベガスで開催されているre:Invent2017のセッションを紹介するものです。

原題: DAT202_Getting started with Amazon Aurora
登壇:

• Debanjan Saha, Genaral Manager - AWS
• Gurmit Singh Ghatore, Principal Database Engineer - Expedia
• Brandon O'brien, Principal Software Engineer - Expedia

以下、セッションの動画内容とスライドの抜粋を紹介していきます。

Amazon Aruroaとは

基本的にはこういうものですという情報。マネージドサービス

Tecnical Prospect

新しく認識したい技術的な展望が3つ
それぞれ紹介していく

Scale-out,destributed architechture

• 特殊なLog-Structured構造を持つSharedストレージレイヤ(画像：緑色のエリア)
• Sharedストレージボリュームの背後に配置された数百ものストレージノードによりスループットを得られる
• 3AZに2つずつレプリケーションを持つことにより、6つのコピーデータを持つことになる
• 通常のストレージ目的だけでなく、（DBプロセスが起動する）ヘッドノードからストレージノードに流されるREDOログの格納にも使うことにより、ヘッドーストレージのノード間ネットワークトラフィックを減らすことができる

これらにより、ハイパフォーマンス, 高可用性, 低レイテンシーを確保している

Service-oriented architecture leveraging AWS esrvices

当然ながらAuroraは既存のマネージドサービスにも対応している。

Automate administrative tasks - fully managed service

自動化された管理タスクによりオンプレミスで必要だったデータベース管理タスクから解放され、アプリやビジネスに集中できる。
例えば、自動フェイルオーバー処理、バックアップとリカバリ、コンプライアンスに基づくセキュリティの確保、モニタリングなどである。

カスタマーの選択

AurorはAWS顧客TOP100のうち、2/3が採用している。またAWS史上、最も早く成長しているサービスである

誰が選び、なぜ選ばれるのか、

Auroraを選ぶカスタマーは2通りの傾向がある

• MySQLユーザー: ハイパフォーマンスと、可用性、コスト削減（最も選ばれる理由）、移行の容易性
• 商用データベース: ライセンス費が不要であることにより1/10に削減されるコスト、同じレベルの性能、クラウドインテグレーション

Amazon Aurora is fast ... (5x faster than MySQL)

AuroraとMySQL5.6、5.7のベンチマーク比較。R3.8XL: 32cores / 244 GB RAM
また、スケールした時はより性能差が顕著に

↑コネクション数スケール時

↑テーブル数スケール時

↑データベースサイズのスケール時

などなど

これらを実現するには、、↓

DO LESS WORK: I/O Profile比較の例

Aurora と MySQL with ReplicaのI/O Profileの比較(30分間のsysbench)
比較のため、MySQL with Replicaにも6つのコピーを持つ構成とした。
Auroraは通常のストレージプロトコルと異なり、"変更差分の更新"によって、MySQL比35倍ものTransactionとI/O per Transcactionを大幅に削減することに成功している。
これがDO LESS WORK を示す一例であり、Auroraが高いスループットを実現できる理由である。

BE MORE EFFICIENT: ロックマネージャー

MySQLロックマネージャーの問題はlatchとmutexにあったがAuroraではロックマネージャーを見直して、latch-freeに複数のTransactionを"Lock-Chain"上で扱うことができるようになり、複数のLock-Chainでオペレーションを実行できるようになった。よりたくさんのコネクションを並行して扱えるようになり、スループット向上に寄与している。

Online DDLの比較

新しくパフォーマンス強化が進んでいるが、ここではOnline DDLのMySQLとの比較例からその効果を確認する。

• MySQLではテーブル構造スキーマ変更に全テーブルコピー、オペレーションのための空きスペース、オペレーションによるスループットの低下、テーブルロックなどが発生する。要する時間はデータサイズに依存し、膨大な時間を要することになることもある。
• 一方、Auroraではデータ側に何も行わず、メタデータの変更として異なるバージョンのスキーマを保持できる。コピーなどによりテーブル構造を残す必要がない。またスループットにも影響しない。

パフォーマンスの性能差は驚くべき結果となる

What about availabilty (on Amazon Aurora)

パフォーマンスは問題だが、パフォーマンスはDatabaseが起動中である時にのみ問題となる。

6-way replicated storage

3AZに2つずつ、計6つのデータコピーがあり、quorumを採用。1つのデータセンター（AZ）が落ちたとしても、完全なWrite&Read可用性が担保される（4/6）、1つのデータセンターと1つのコピーが落ちてしまった場合でもReadは完全な可用性が保たれる（3/6）

Up to 15 promotable read replicas

マスター昇格可能なリードレプリカをMulti-AZで15個持つことができる。また、直近の更新によりAurora レプリカを自動的に追加または削除できるようになった。クロスリージョンのRead Replicaも可能である。
なお、データベースのフェイルオーバータイムは以下のような実績がある。

• 0 ~ 5sec以内：全体の30％
• 5 ~ 10sec以内：全体の40％
• 10 ~ 20sec以内：全体の25％
• 20 ~ 30sec以内：全体の5％

Security and Monitoring

- AES-256によるデータ暗号化、キーマネージメントはKMSで可能 - クロスリージョンレプリケーションでも暗号化が可能 - パフォーマンス影響なしに、audit、loggingが可能 → 次項で説明 - Database activity monitoring

後半2つについて以下に解説。。↓

Aurora Auditing

「ロックマネージャー」の項でも説明したような、Lock-Freeなデータストラクチャーによりパフォーマンスに影響が少なく、監査が可能。MySQL5.7と比べるとAuditOn時のパフォーマンス差は明らか。

Database Actibitiy monitoring

CloudWatch LogsでAuditLogを取り込むことが可能となり、同時にS3上にアーカイブすることが可能となった。またそれらは、Athenaや、QuickSightで可視化することができる。

Aamzon Aurora is easy to use

簡易化されたストレージマネージメント、例えば継続的なS3へのバックアップやスナップショットの作成、最大64TBまでのデータベースサイズの自動スケーリング（パフォーマンス影響なし）

,
Fast database clonning。開発・テストや分析・ベンチマーク取得のために簡単にプロダクションDBのスナップショットを取得できる。また、ストレージコストはかからない。

ハイブリッドなオペレーションとマイグレーション。運用中のMySQL、PostgresSQLからシームレスに（かつ数分で）Auroraにレプリケーションが可能。Auroraに渡すことで、AWSインテグレーションを利用した分析が可能となる。

Amazon Aurora is saves you money

MySQLとAurora

MySQLでPrimary(R3.8XL+storage_6TB)とStanby(同), またReplica(同)を2機つけると、時間あたり13.62ドルかかる。

Auroraで同様の性能構成を準備すると上記のようになる。

• ReadReplicaがPrimary昇格可能であるため、スタンバイのインスタンスが不要
• 一つのShared Volumeで問題なし（Stanby, Replica分のストレージが不要）
• I/Oが発生しないため、支払いをする必要もない
• 全体のI/Oも低減される

結果的にAuroraだと9.29ドルが時間あたりの費用となる。これは31.8%も節約したこととなる。
さらに、Auroraのハイパフォーマンスによってより小さなインスタンスサイズでの構成を可能とすることがしばしばある。
先ほどの例で、R3.8XLからR3.4XLにスケールダウンして運用が可能であった場合、

時間あたりコストは、6.86ドルとなり結果的には49.6%の削減（ほぼ半分）となるのである

同様のシナリオでコスト削減ができた事例↑

Expedia - Journey to Amazon Aurora

Gurmit Singh Ghatore, Principal Database Engineer
Brandon O'brien, Principal Software Engineer
によるExpediaでのAurora採用事例の紹介

• より低いオペレーションコスト
• パフォーマンススケール
• スキーマ構成のフレキシビリティー

を実現するソリューションを探していた

現行サービスの要求指標。
- 1,000,000,000 rows - 4,000 writes/sec - 25,000 reads/sec

,
DetailとArchitecture
2つのリージョンにデプロイで、それぞれ独立したAuroraを起動している
(※ ちょっと聞き取れませんでした。。)

Requirementsを解決したAuroraの機能について

• 99％のReadResponseを100msec以内とする: Auroraリードレプリカで並行処理を可能とした
• リソース使用率の均一化する: AuroraのConnection LoadBarancing
• スキーマの変更: FastDDL

Clientリクエストとボリュームの増加に伴うレイテンシ増加に対応した際の一例。簡単に追加のReplicaを導入することができ、要求性能に戻ることができた。

従前（Cassandraを使用していた時）から10-15％のコスト効果が得られ、ダウンタイムを10分以内に抑えられるようになった。

さいごに

Auroraを導入することで、どういったビジネス上のメリットがあるか、実例を踏まえた紹介があり、非常に勉強になりました。
（最後の方は英語に息切れしてしまいましたが
AWS史上、最速で進化し、多くのAWSカスタマーに支えられるサービスであり、今後も楽しみなサービスです。

本セッションはコチラから視聴できます。

理解を助ける参考先：

• 最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった
• マルレク講義ノート：Amazon Auroraについて
• Apache Kafka ―入門からTrifectaを用いた可視化まで―

それではまた