Aurora使っていますでしょうか。
当初はMySQL互換DBとして、少々コスト高ではありながらもその設計思想の秀逸さに非常に魅力的だったRDBMSですが、現在ではもはやRBDMSの一大勢力といっても過言ではないのかもしれません。
しかしながら、やはりまだまだ一般には理解されにくいのかもしれませんが…。
Auroraはデータを格納するストレージとクエリを実行するコンピューティングリソースを完全分離したデータベースです。
このため、従来のDBでよく行われていたレプリケーションなどの処理は、すべてストレージ領域の仕事となっております。
実行エンジンとストレージが分離している、ということは、実行エンジン部分さえ作ってしまえば、ストレージは自動的にそのデータを分散保持し続けるため、理論上はどんなDBでもAuroraクラスタ内で高度な分散クラスタを構成可能である、ということになります。
RedisやMongoDBのようなKVSでのリーダー選出といった動作もほとんどなく、だれでもいいから優先度に応じてマスタになってしまうことができ、また、保持データはダウンしたマスタが最後に処理したトランザクションまでが確実にストレージに存在する、となれば、もはやこれはDBの可用性だので頭を悩ませていた時代は軽く終わりを告げるわけなのですが、そんなAuroraにRe:Inventでも発表されていた新機能が満を持して登場しました。
Aurora Serverlessです。
注意書きにもありますが、LambdaなどのServerless専用のRDBMSではありません！ 実態は、インスタンスを事前に策定することなく動作させるスケーリングを組み込んだサーバレスマネージドRDBMSということになります。
FARGATEの展開とだいたい一緒に来ているので、基盤はいつも通りDockerベースなのでしょう。
使用されないときは実行エンジンをゼロまでスケールし、コストをゼロにし、使用がリクエストされるとスケールする、という仕組みですが、初発の起動には少し時間がかかっているようです。
プロダクト環境には特性を合わせないとむつかしいですが、開発系などにはてきめんに効果が高いでしょう。
開発環境のためにコスト高のAuroraを動かし続ける、というのは少々気が引けますし。
とはいえ制約事項も多いので、Lambdaを中心にしたServerlessの方々からは少々とっつきにくいかもしれません。
VPC外から接続できない、というのはServerlessシステムからはちょっと足かせでしょう。Public IPも持てませんし、当然IAM認証もできません。
しかし、スパイクアクセスなどに対して自動的にスケールアウトし、勝手にスケールインするDBというのは今までも作れないことはなかったのですが、ノーメンテでそれが行えるというのは大変魅力的です。
EC2インスタンスベースの環境や、FARGATE環境などであれば、できるだけ取り込んでいきたいところですね。
さて、もう一つ予告されているのがAurora Multi-Masterです。
そうです！ 念願のマルチマスタです！ ここまでくればもう下手なエンタープライズクラスのDBと全く遜色ありませんね。単一エンドポイントなのは変わらないまま、Writeノードを増やして書き込みスループットを向上させるもの、と認識していますが、まだプレビューなのでリリースが楽しみでなりません。
従来のマルチマスタはレプリケーション方向だのトランザクションIDだのをいろいろと気にする必要がありました（GTIDが導入されたことでそこまで今はひどくないです）が、AuroraはMySQL5.6系でそれができる、というのは素晴らしいですね。
GTIDなどを使うことなく、ということになるとエンドポイントの先がトランザクションを管理できるL7ロードバランサーなのだろう、というのは容易に想像つくのですが、いざ手で作れと言われたら全力でめんどくさい話なので相当に腰を据えないといけないような仕掛けが、ボタン一発でできてしまう、というのはもうインフラにとっては革命的です。
Infrabbitでは、極力こういった先進的な仕掛けを提案し、運用の負荷を下げていきたいと考えています。
サービスが何の異常も見せずに正常に動いてさえいるなら、バックエンドで何台故障しようが、自動的に回復していればそれでいいと思うのです。
クラウド時代の運用や監視の考え方は、オンプレミス時代からどんどん変わっていっています。
クライアントがCPU負荷率だのメモリ消費量だのを気にしないでいい運用を目指したいものですね。
