Perl

2017年のPaaS/SaaS周りを振り返って - フルマネージドDBサービス発展の年

2017年も終わりを迎えようとしておりますが、2017年はPaaS/SaaSにとって非常にインパクトの大きい一年でした。

このエントリでは、PaaS/SaaS利用者の観点から、2017年を振り返ってみようと思います。

なお、私は主にMicrosoft Azureを利用しているため、内容の濃さなどの面でどうしてもMicrosoft Azure寄りとなりますことをあらかじめご了承ください。

フルマネージドDBサービス発展の年

2017年は、フルマネージドDBサービスの利便性が大変向上した一年だったと思います。

特に「DBインスタンス」という考え方から脱却したサービスが登場し、本格的に利用された年だったと言えるのではないでしょうか。

アプリケーション開発者からすると、インスタンスのことを気にするのは本質的ではありません。そのような本質的ではないことについて一切触れる必要なく、DBをサービスとして利用することは、2017年で一気に身近になってきたことだと思います。

また、料金体系的にも「トランザクションごとに課金」というパターンが浸透してきたのも2017年の特徴ではないでしょうか。これによって、真に「利用した分だけ支払う」ことが現実のものとなったと思えます。

Azure Cosmos DB

スキーマレスなNoSQL DBとして利用でき、各リージョン間でデータレプリケーションが可能なDBaaSです。

もともとAzure Cosmos DBの源流として、Azure DocumentDBというサービスが2010年から提供されていたのですが、Build 2017にて名称をAzure Cosmos DBとし、以下のようなAPIへと対応しました。

料金体系についてはRU(Request Unit)と呼ばれる単位で計上されることになっており、インスタンスベースの課金体系ではないことが非常に重要です。

Azure Database for MySQL/PostgreSQL (プレビュー)

Azure SQL Databaseで培われてきたフルマネージドDBサービスの堅牢性とスケーラビリティが、MySQLおよびPostgreSQLのインターフェースで利用できるようになったものです。これもBuild 2017で発表されました。

従来であればMySQL/PostgreSQLともにVMを立ち上げ（あるいはオンプレミスのリソースを用意して）そこにインストールし、パフォーマンスモニタリングに気を使いながら、自力で運用するものでした。

このサービスは現時点ではまだプレビューですので、手放しで本番に投入して良いものかどうかは微妙だと思いますが、上記のような運用から解放される道筋が示されていることについて、将来十分に考慮に値することだと思います。

こちらの料金体系は、時間課金のコンピューティングユニットとデータ容量課金のストレージの合算値となり、やはりインスタンスベースの料金体系ではありません。

Amazon DynamoDB

Amazon DynamoDBは、フルマネージドDBサービスの中でも元祖と言えるでしょう。2012年にサービス提供が開始され、2013年に東京リージョンで利用可能となりました。

リージョン間でのレプリケーション（クロスリージョンレプリケーション）にも対応しており、課金体系もデータ量とスループットに基づいたものとなっています。

これらのことは、近代的なフルマネージドDBサービスの基礎となっており、Amazon DynamoDBがサービスを通して示したビジョンは大変重要なものと言えるでしょう。

フルマネージドDBサービスは開発者をより開発に集中させる

上記で紹介したサービスはいずれも、開発者からDBの管理という手間をなくそうという方向性のサービスです。自力でDBの管理を行う場合にかかるコストと、上記サービスを利用した場合のコストは、性質的に全く異なるものです。

また、自力でDBの管理を行う場合は、どうしても人間そのものがボトルネックになってしまいます（腰痛や風邪などの体調不良、冠婚葬祭に伴う休暇など）。速く移動するという本質で見た時に馬車から自動車へと変遷していった歴史があるように、DBの管理やスケーリングについてもより利便性の高い手段を検討していくことが肝要なのではないでしょうか。

そして、開発者がより開発に集中できるようにし、生産性の向上に繋げていくことが、最終的な競争力に寄与するのだろうと私は思います。