Amazon Aurora東京ローンチ記念セミナー参加レポート

11/10(火)、目黒で開催されたAmazon Aurora東京ローンチ記念セミナーに参加してきたので、レポートをまとめておく。なお、数値などは聞き間違いがあるかもしれないので、詳しくは発表者の資料や公式のドキュメントを参照してほしい。

セミナーの感想

セミナーを通してAmazon Auroraはエンタープライズレベルの要件に耐えうるスケーラブルなRDBMSであると、自分なりに咀嚼して理解できたのがよかった。
Auroraの特徴のうち、特に衝撃だったのは次の3点だった。

MySQLの5倍の性能
- 更新系処理の性能向上が著しく、UPDATEの処理性能がMySQLの5倍、INSERTの処理性能が2倍という事例がある。MySQLの5倍というのは、単なるカタログスペックというわけではないらしい。またリードレプリカを並べて参照系処理が速くなったことをもって、性能向上と言っているわけじゃない。更新系処理の性能が向上している。
秒オーダでのフェイルオーバ
- Auroraはマスタは1つなので、マスタ障害時にはフェイルオーバが発生する。リードレプリカがある場合、フェイルオーバ時間は30秒ほど。MariaDB Connectorと組み合わせたら1～2秒になったという事例がある。
お手軽マイグレーション
- MySQL5.6と互換性があるので、現行がMySQL5.6ならアプリの修正必要なし。さらにMySQLからAuroraへのレプリケーションができる。

セミナー後調べたこととか考えたこと

Auroraの資料見たところ、なんとAuroraはPostgreSQLと同じ追記型らしい。
これによりバックアップなどの運用性向上、書込性能の向上が実現されているとのこと。
Auroraは可用性99.99％で設計されていて、SLAは99.95％とのこと。この数字が今後向上したら世の中のシステムはどうなるんだろう。
NoSQLが出てきたとき、「NoSQLがRDBMSに取って代わることはなくて、適材適所で使われるようになる」という話があったと思う。
これに対してAuroraは、「Oracle, SQL Server並みの性能を、MySQL, PostgreSQL並みのコスト、運用性で」というセミナーでの発言が示すとおり、これから全てのRDBMSの領域を置き換えていく可能性のあるサービスだと思った。
これからもたくさん事例が出てくると思うので、そのあたりウォッチしていこうと思う。

以降はセミナー中に取った聴講メモなど。

はじめのあいさつ

最初はAWSJ安田さんの挨拶。
Talend、DataSpiderといったデータ連携のツールが既にAuroraに対応。
ウイングアーク1st株式会社は自社製品の中でAuroraを使っているとのこと。

Using Amazon Aurora for Enterprise Workloads

AuroraのGMのDebanjan Sahaさんのお話。

聴講メモ

Auroraはエンタープライズ利用を想定して設計してある。
MySQLに完全互換。MySQL向けアプリはそのままAuroraで使える。
性能はOracle, SQL Server並、運用のしやすさ、コスト効果はMySQL, PostgreSQLというところを狙っている。
Master障害時のフェイルオーバ時間は30秒以内。
MySQLでは数分かかるようなクラッシュリカバリがほぼ即時に実行される。
最大50万回/秒の読込、10万回/秒の書込性能。これはMySQLの5倍。
ストレージ自体がDB用に設計されている。
これらがフルマネージドサービスになっている。すぐ使えるし、パッチも自動で当たる。
AWS史上最速で成長しているサービス。
国連でも使っている。公開事例になっていなくても、多くの会社がAuroraを使っている。
事例1: Expedia
- リアルタイムでのBIと分析が要件。現行はSQL Serverベースのアーキテクチャだったが、高価だった。またスケールしなかった。そこでCassandraとSolrを組み合わせてインデックスを作成したが、これは大きなメモリー空間が必要で、結局コストが高くなってしまった。
事例2: Pacific Gas and Electric Company
- この顧客特有の事情として、停電時にバーストトラフィックが来るので、これを捌かなければならないという事情があった。
事例3: ISCS
- 現行ではOracleとSQL Serverを通常業務とDWH用途で使用。これらのコストがIT費用の中で最も大きな支出になっていた。
- Auroraの利用により、70％安価なシステムを実現。
事例4: Alfresco
- Auroraの利用により、現行の10倍の高速化を実現。10倍というのはAWSの言うMySQLの5倍を越える性能。顧客はたいそう喜んだ。
事例5: Earth Networks
- 25TB/日で増えるデータの処理をする必要があった。(IoT関連の事業をやっている会社なのかな？)
事例6: threat stack
- これもCassandraからの移行事例。
高可用性を支える技術
- 3つのAZにまたがり6つの複製を保持。
- Peer-to-pper gossipレプリケーション
- 6つのうち2つを失っても性能は落ちない。6つのうち3つを失っても読み込みは可能。
- 高速なクラッシュリカバリ
  - 普通はチェックポイントが5分間隔とかで、ログをシーケンシャルに適用する。時間がかかる。
  - Auroraは、Disk readの一環として、オンデマンドでredo logの適用を行う。そのため、リカバリ時にredo logを当てる必要がなく、1秒以内でのリカバリが実現できる。
  - AuroraとMariaDB Connectorにより、さらに短時間でのフェイルオーバが可能。
- バックアップについて
  - 各DBのスナップショットを定期的かつ並列で取得し、REDOログをAmazon $3へ転送する。
- 適用型スレッドプール
  - この辺りはMySQLの実装とかなり違う。(詳細聞き逃した。)
- 非同期グループコミット
  - 6つのうち4つのDBでコミットがされた時点で、データの書込みが成功する。
- Advanced monitoring(開発中)
  - 顧客からの要望のあった、OS関連メトリクスを取得できるようになる。
  - Cloud watchは1分間隔だが、Advanced monitoringは1秒間隔でメトリクスの取得ができる。
AuroraはMySQLと比べてもコスト効果があることがある。

Q&A

Q MySQLの場合、データサイズが大きくなるとDDL変更が時間がかかるが、Auroraはそのあたり改善しているのか？
- A いくつかは改善しているが、全てではない。オンラインでのDDL変更については、現在開発中。
Q モバイルSDKから直接使えるか？
- A 使える。
Q インスタンスタイプR3しかないが、今後の展開は？
- A 現時点では、T2タイプを今後サポートしたいと考えている。M, CあたりはAuroraのアーキテクチャを活かせないので、考えていない。
Q メモリに載らない大きなテーブルのalter tableしないほうがいいという話があるが、現在は？
- A おおよそ修正済み。ただ超巨大なテーブルをalter tableするのであれば、大きなインスタンスタイプを利用することをオススメする。
Q MySQLのMHA(数秒でのインスタンスタイプ変更)のような機能は提供されているか？
- A MHAはサポートしていない。そのような場合の対応方法としては、大きなインスタンスにリードレプリカを作っておいて、そこにフェイルオーバするのを推奨している。

Nice to meet you, Aurora! ～RDS for MySQLからAuroraへの移行～

株式会社Grani @guitarrapc_techさんの発表。発表前に資料公開されていて、ありがたかった。

資料

聴講メモ

性能改善について
- NewRelicでざっくり見る。個々のクエリはBigQueryで見る。
- 参照は変わらなかった。
- 更新が5倍速くなった。5倍というアナウンスどおりの結果が出た。
- インサートも速くなった。
- 削除は若干遅くなった。
移行について
- ドキュメント見よ、話はそれからだ。これで99％いける。
- 移行は2シナリオある
  - スナップショット移行
    - オススメ
  - レプリケーション移行
  - レプリカの作成は、データサイズによらず必ず6分で終わる。これ嬉しい。
    - スナップショット移行よりサービスのダウンタイムを局所化できるが、大変。
    - Graniの場合、スナップショット移行だと11時間かかるところが、レプリケーション移行のおかげで、アプリの動作確認含めて30分で移行できた。動作確認なければ5分でいける。
MySQLだと高負荷時にダウンしてしまうことがあった。Auroraはスローダウンすることはあっても、動き続ける。
年間2200万円のコスト削減効果。

ドワンゴがAurora使ってみた(仮)

株式会社ドワンゴ細川さんの発表。

聴講メモ

これまでのはなし
- サーバはハードから作る！最近はデータセンターから作る！という気概を持った会社。
- 最近はAWSも積極的に導入し始めていて、AWS Summitでも発表した。
  - Amazon Lambdaは6/29に東京でローンチされて、10/17に商用利用。
  - API Gatewayは10/8に東京でローンチされて、10/17に商用利用。これらは電王戦のなかで使われた。
  - Auroraは現在検証中。
Aurora適用プロジェクト
- LDR
  - 国産RSSリーダーで、約9年間続いたサービス。いろいろ古くなってしまっていたので、これをAuroraに移行した。
  - Auroraの紹介動画が、You Tubeにアップされていて、この動画が的を射ている。
  - 現行はEC2上のMySQLで動いていた。サーバ15台、10TB。
検証結果・パフォーマンスなど
- 古いコードベースということもあり、MySQLとのクエリレベルでの互換性というのは安心感があった。
- 現在移行に向けて検証実施中だが、現時点ではクリティカルな問題はない。
- レコード削除してもいったん増えた使用領域はシュリンクされない。課金対象になってしまう。
  ただ再利用可能で、再利用は効率よく行われていることが、検証から分かっている。
- 5系統で並列していたリクエストが1系統に集中するが、パフォーマンスは大丈夫か？という懸念があった。過去実績では、最大となる並列数は800ほど。
  - 問題なく捌けた！
- 商用利用に向けて順調に検証している。導入後の運用負荷の軽減に期待している。

Amazon Aurora 評価・検証結果発表

アイレット株式会社 cloudpack 新谷さんの発表。
実データを用いたAurora検証結果の報告。

Amazon Auroraはこう使おう！

～基幹業務をフルクラウド化するポイント～

ウルシステムズ株式会社漆原さんのお話。

聴講メモ

これまでRDBMSとNoSQLという極端な2択しかなかった。基幹業務系やっていて、ずっとクラウド型のRDBMSが欲しいと思っていた。
オンプレをそのままクラウドに持っていくと、インフラコストの削減にはなるけど、それしかない。その先へ。
モノリシックな業務APが、今、すべてを邪魔している。このままAuroraにいっても、それからどうしようもなくなる。
モノリシックなものをマイクロサービスへ。APIで綺麗に切りなおして、そこからしかアクセスさせないようにする。
オーバヘッドはあるが、その代わりスケーラビリティが得られる。こうすることで、Auroraの特性をフル活用できる。

New Cloud Design Pattern using Amazon Aurora

クラスメソッド株式会社大栗さんのお話。

聴講メモ

Develpers.IO移行事例
- Developers.IOをAuroraに移行した。性能向上した。
- もともとdb.m3.mediumだったので、db.r3.largeになって、コストは1.5倍になった。
某SNS移行事例
- これ以上DBのスレーブ増やせない状態。移行検討中。
高速なフェイルオーバ
- MariaDB Connectorにより、30秒のフェイルオーバ時間が1～2秒になった。(Linux環境)
  Windowsだと5秒くらいだった。
OSS DBと比較して低価格の場合もある。インスタンス台数が削減できる場合があるので。

Amazon Aurora＋ScaleArcによる Amazon Aurora のデータベース分散処理技術の最大活用

株式会社システムサポート山口さんのお話。タイトル違うかも。
ScaleArcという製品の紹介。

エンタープライズシステムにおける Amazon RDS for Aurora 活用ノウハウ

株式会社野村総合研究所西岡さんのお話。

聴講メモ

Auroraは可用性99.99％で設計されていて、SLAは99.95％。
Auroraは現状参照しかスケールしない。

その他

Amazon Aurora TシャツとAurora利用クーポンの抽選があったけど、外れた。Tシャツ欲しかったな。残念。
アマゾンのセミナールーム、発表者の立つところに神棚があって、意外と日本ぽいんだなーと思った。けどよく見たらドアだった。しかもセミナールーム中にいっぱいあった。どういうことなの。