Amazon Aurora

Shinpei Ohtani
6 min readFeb 19, 2016

Amazon Auroraというクラウド上のRDBMSサービスがある。2015年の7月末にGAロウンチしたばかりのサービスだが、世界各国のユーザに非常に好評のようだ。

https://aws.amazon.com/rds/aurora/

Auroraをどう見るか、でクラウドの受け入れ度合いや現状の把握に使えると個人的には感じている。個人としてはAuroraほど画期的なサービスはDBでは今までなかったし、RDBMSの歴史の新しい1歩として認識している。ただあまりのシームレスさ、移行容易性、利用の簡便さに凄さに逆に気づきにくい状況がおきている。結果としてマーケティング的なムーブメントにはなりにくい状況で、個人としてはむしろそれが望ましいとも思っている。静かに深く世の中を変えていく、そんなサービスだ。ちなみにグローバルではOracleやSQL Serverからの移行が後を絶たない。理由の多くは、1)顧客がほしいのはプロダクトとしてのRDBMSではなく、サービスとしてのRDBMSのメリットである点、2)非常に高額かつ合理性の低いライセンスビジネスからの脱却、の2点で、RDBMS含めたサービスへの転化は止まらないと思っている。

RDBMSの枠組みの中でAuroraはかなり異質なので通常のRDBMS製品を使っている人からすると最初はメリットを理解し難いかもしれない。理由として、1)RDBMSというと一般の人はプロダクトをイメージするがAuroraはRDBMS部分+ストレージ部分も独自開発したサービスである点、2)今までのNoSQLのように独自性(開発、運用含めて)を打ち出すのではなく、内部の仕組みが画期的である反面、利用者には今までどおりのSQLを利用したアプリケーションを可能にしている点、が起因するかもしれない。

Auroraは大きく分けてMySQL 5.6 かつInnoDBベースで自前で開発したRDBMS部分と、RDBMSに特化した形で新たに開発したLog structure storage部分からなる。特にこのログストレージ部分はマルチテナント型かつシェアードストレージサービスになっており、耐障害性の獲得・非常に高速なフェイルオーバや、粒度の細かいスナップショットの獲得によるデータの安全性確保とリカバリ、そして10GBごとの従量課金制を実現するコアになっている。RDBMSを時代の要求に応えるためにフィットさせていくのは容易ではない。その一つの形としてクラウド上で展開するには、ラック含むハードウェアやネットワーク構成の統一・ストレージ部分含むソフトウェアの独自開発・各コンポーネントのサービス化によるレジリエンスの向上・RDBMS部分の疎結合化を目的とした再開発など莫大な投資が必要でAmazonはそれを成し遂げた。もともとワンボックスで利用することを前提にしていたRDBMSを、安定的に高可用・高スケールで誰にも利用できるようにするにはソフトウェア部分だけでは全く不十分で、トータルで考えていかなければいけないという一つの良い例と見ている。ひとえに顧客の要求に応えて、形にした結果といって良い。

逆に既存のRDBMSベンダーはなぜ出せなかったのか、と個人的には突き詰めたくなる。先にRDBMSベンダー各社がRDBMS をサービスとして出しても全くおかしくはないが(むしろそうあるべき)、自社のカニバリゼーションをおこす等の理由でイノベーションをおこせていないようにも見える。本当のところは定かではないが、ライセンスビジネスの弊害にも思える。RDBMSサービスの選択肢が増えていくことを願っているし、単に仮想マシン上にRDBMSをのせただけ、利用者のメリットを考えていない・クラウドの特性を考えていない、そういったまがい物は早々に市場から消えてほしいと思っている。もう少しレベルの高い競争や議論を期待したい。少なくともほとんどのクラウドベンダーで現状のAWS MySQL RDSまでも到達出来ていない、そういう認識だ。最近色々調べているが、冷静な目でみたときに大体3年から5年くらいの遅れに感じている。猛烈なキャッチアップを期待したい。

一方で(もちろんだが)Auroraにも改善点もある(as of 2016/02/20)。良い点の裏返しになるが、マルチテナント型のLog Storageによってディスク部分がシェアード型になっているため、現状バッチ処理だけをレプリケーション先の別個のストレージで行わせるような事ができない。通常のMySQL RDSだとレプリケーション遅延の可能性はありつつも分離しておいてそれぞれ別個のディスクで処理できるがそれが課題の一つ目。二つ目は、独立したキャッシュ部分の状況確認の方法。現状のキャッシュ部分はMySQLから独立しているものの、状況確認があまりできないはず。三つ目は、一つ目とも関連するがより堅牢なbin log生成機能によりMySQL(またはストレージ部分が独立したmini Auroraのようなもの)へのレプリケーションを強固にする事。そうすることで、バッチ処理には別個のストレージを利用することができる。他にもあるが、早々に改善はしていけるだろうと思っている。ただ、機能追加より可用性や安定稼働のための取り組みをぜひ重視して欲しいと思っている。全体通して、アーキテクチャとしてはRDBMSサービスとして適切だと思っているし筋が良いとも思っているので、このまま改善を繰り返してもらいたい。

また、Auroraは最初のマーケティングメッセージがあまりよくなかったように思う。パフォーマンスが数倍というのも利用者には嬉しいが、正直全く本質的ではない。むしろRDBMSサービスの歴史の新しい1ページとして、ここまで来た、逆にここまでやらないと時代のニーズが満たせなくなりつつあるという点を丁寧に伝える方が良かったように思う。機能やイノベーションは素晴らしいので、利用者に正しい理解をしてもらう・本質的なフィードバックをもらうのが何よりも大事だと感じる。そのためにも今後内部の仕組みがよりオープンに語られる事を願っているし、そうすることで開発者がより使いやすい状況になっていくと思う。

日本には幸いなことにAuroraを担当している素晴らしいSA(ソリューションアーキテクト)とBD(Business Development)のチームがいるので、利用にあたって世界的にみても非常に恵まれた環境だと思う。利用者として、これを利用しない手はないと思っている。

--

--