概要
とあるサービスでは、Amazon Web Servicesをベースにインフラを組んでいる。データベースにおいてはRDSのMySQLのストレージエンジンを利用していたが、Amazon Auroraへと移行をした。それはAuroraがTokyoリージョンでの提供を開始した翌日のことで、中々勇気がいることであったが、結果「無難」に動いてそこそこ満足という評価。元々MySQLの時分ではインスタンス自体がオーバースペック気味だったので、今回のAurora導入でインスタンスサイズと構成を見直し、全体のパフォーマンスがWeb APIサーバーの平均レスポンスタイムを見ると10ミリ秒以上遅くなってしまったが、ユーザー体験とアプリケーションの性質上コストの兼ね合いで割り切ることとした。という事情があり、MySQLとAuroraの比較が環境やコストの差で非常にしにくいが、いくつかの点で移行してよかったと感じる。詳細を以下に書きます。
パフォーマンス
Amazon Auroraの公式ページでは「MySQLの5倍の性能」とあるが、これは「とある条件下」での最大計測値だと見た方が妥当という点で注意したい。まぁ、実際状況によってはそれほどパフォーマンスが出る場合もあるとのことです。
RDSにおいて、Auroraではディスクサイズを予め明示してからインスタンスを用意しなくとも、自動的にスケールでしてくれて大変助かる。一方、MySQLストレージエンジンの場合は当然、ディスクサイズを「100GB」使うとかCapacity Palanningする。その代わり、であるが、MySQLストレージエンジンではディスクサイズを大きくすればするほどディスクへのI/OアクセスであるIOPSが上がる。今回の件ではこのIOPSを「かなり」あげていた。かつ、クエリーによってはディスクアクセスが発生するものが存在した（CPU性能も加担しているかもしれない）。なので、パフォーマンスが出ていた状態であった。一方Auroraの場合、IOPSのコントロールはしにくい。
対象となるサービスではOAuth2認証とJSONRPCを喋るいわゆる「Web API」なのだが、結果前述した通り、全エンドポイントの平均レスポンスタイムが10ミリ秒上がった。つまり遅くなったってことだが、同時に、インスタンスサイズを見直すいい機会になり、また、MySQLの時にIOPSを「かなり」あげて富豪的解決をしていたのに改めて気付かされた。よってパフォーマンスへの施策として、サボリ気味だった、いくつかのクエリーチューニングやインデックスの調整なども行った。結果、コスト削減の効果が実際出始めていて、特に利用者の多いモバイルアプリでのユーザービリティにも影響はほとんど出ていない。
使い勝手
Auroraではひとつのインスタンスが必ず2つの「Availability Zone」にまたがるということになっている。またMySQLでの「Master-Replica」という文言は使わずに「Writer-Reader」という言葉を使う。基本的にはMasterにあたるWriterとRead ReplicaにあたるReaderを用意すれば冗長化は済んでしまう。また、レプリケーションの処理をストレージエンジン部分ではなく、確か、ディスクシステムレイヤーでやっちゃう、みたいな仕組みなんで、マスターとレプリカとのラグといった概念はほとんど存在しない。というかラグは0と考えて良い。その都合も含め、この場合、Masterとして利用しているWriterがコケた場合に、ReaderがMasterへ昇格する際のフェイルオーバーが速いといった特徴がある。
とはいえ、何よりも増え続けるデータのCapacity Planningという難しいことをせずとも、自動的にスケールしてくれるのが嬉しいところである。
導入
東京リージョンでの提供開始日の翌日に早速導入したわけだが、比較的すんなりいった。当然サービスはメンテ状態にしないといけないんだけれども、基本的にはMySQLのRDSからスナップショットをとり、そこから新たにAuroraを立ち上げる形になる。大きなテーブルでは2億ほどレコードがあるDBになるが、メンテ諸々の作業合わせて3時間ジャストくらいでイケた。Readerに関しては無停止でインスタンスを追加したり削除したり出来るので、一番負荷が高い「22時30分」頃のピーク時でのパフォーマンスをCloudWatch+Libratoで監視しつつサイズを合わせて行った。
同時にクエリーやインデックスのチューニングも後々行ったので「パフォーマンスが落ちた」とはいえ、最小限に留めるように努力出来る余地があった。
MySQLとの互換性
これはビックリするほど「MySQL 5.6」と互換性がある。例えば、懸念していた「Online DDL」も5.6相当のものだし「Percona Toolkit」のpt-online-schema-changeコマンドも問題無く動いた。これで「ある程度無停止」でスキーマを変更することが出来るので安心。
まとめ
正直「すっげーAuroraいいよ！」とは言えないが、MySQLとの互換性が今後保たれていくことが保証されるという前提で「特にAuroraじゃない理由はない」という具合でデフォルトで使う感じになる気がする。ポイントは
- スケーラブル
- MySQL互換（現状は5.6）
- 冗長性が高い
となるだろう。現段階ではAuroraとして導入出来るインスタンスタイプがdb.r3.largeからとミニマムスタートには少々お高い感じになっているので、状況によっては敷居が高いが、Amazonの気合が感じられるプロダクトであるので今後スタンダードになるというジャッジで使うのはアリだと思います。
Amazon Web Services実践入門 (WEB+DB PRESS plus)
- 作者: 舘岡守,今井智明,永淵恭子,間瀬哲也,三浦悟,柳瀬任章
- 出版社/メーカー: 技術評論社
- 発売日: 2015/11/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る