AWSマネージドデータベースとは？利点と気をつけたいことまとめ

クラウドサービスが流行りだして久しいです。PLAN-Bでは主にAWSを使っているのですが、積極的にマネージドサービスを使うようにしています。今回はその中でもAWSでのデータベースやマネージドデータベースについて、どういうものなのか、利用時に気をつけたいことなどをまとめました。

クラウドを検討している方、マネージドデータベースを使いこなせてない、またはこれから使ってみようと思っている方の参考になれば幸いです。

マネージドデータベースとは？

データベースを構築するとなった場合、下記の3つの方法があります。

AWSサービス説明で使われている図をお借りして、それぞれを比較してみましょう。ここからは、データベースとして一般的なリレーショナルデータベースマネージメントシステム（RDBMS）に絞ってお話しします。

引用：SlideShare

データベースをオンプレミスで構築した場合

私たちは、図の水色の箇所の作業を行わなければなりません。筐体の購入やOSの設定といったサーバー自体の設定、データベース用ミドルウェアのインストールと冗長化といった作業が必要になり、実際にデータを入れて使うまでに時間がかかります。

データベースの運用が始まれば、負荷状況に合わせたスケーリングやデータのバックアップ作業も必要です。データを使ってサービスを構築するまでに必要なことがたくさんあり、またサービスを維持していくのにもエンジニアによる運用コストがかかります。

データベースをEC2の上に構築した場合

EC2はサーバーサービスなので、サーバー自体の管理はAWSが行なってくれます。しかし、上記で説明したミドルウェアインストール以降の作業は私たち自身で行う必要があります。

私たちの作業が必要なのは同じく図の水色の箇所で、サーバーの管理が不要なぶん、オンプレミスで構築するよりは作業が減り、運用コストが下がります。

データベースとして「使う」よりは、特殊な機能や高性能を実現するために「自作する」ような必要がある場合に向いています。

マネージドサービスのRDSを使った場合

RDSはマネージドサービスなので、上記で説明したサーバーの管理やミドルウェアの管理、スケーリングやバックアップは全てサービスとして提供されています。私たちが行う水色の箇所はだいぶ減りました。

データベースを使うために必要だった時間は、データ設計やシステムの性能アップ、提供するサービスのコンテンツを考えるなど他のことに使えるようになります。

Webサイトなど、データベースとは別のところに提供するサービスの価値があり、データベースは「使う」だけでよければRDSを使うのが向いています。

Aurora Serverless

さらに2018年にはAurora Serverlessというサービスがリリースされました。

EC2もRDSも、インスタンスという単位でサーバーを利用していたのですが、Aurora Serverlessではついにサーバーという概念がなくなりました。

私たちはAurora Capacity Unit(ACU)という処理の単位と、保存されているデータ量、読み書き(I/O)の量のみを気にすれば良いことになります。そして、これらは必要に応じ、AWS内部で調整されます。

Aurora Serverlessはあまり利用される機会が無いようなアプリケーションや、日々ワークロードの変動が激しい場合、または、ワークロードが予測不可能な場合に非常に強力に機能します。

必要なときに必要なぶんだけ課金されるので、今まではキャパシティを考慮しなくてはいけなかった設計段階の手間すらも削減してくれます。さらに他のことに時間を使えますね。

マネージドサービスを使うことで、エンジニアのインフラ運用コストが大幅に削減され、他サービスとの差を生み出したり、さらなる価値を生み出したりといったことに時間が使えるようになります。ぜひ使ってみたいですね。

マネージドデータベースで気をつけること

ユーザーにとってメリットが大きいマネージドデータベースですが、使ってみて気をつけるべきことをまとめました。

01：クラウドサービスとコストに注意！

マネージドだからという訳ではないのですが、クラウドサービスを使うにあたっての注意点です。

AWSには複数のマネージドデータベースサービスがあり、それぞれに特徴があります。一旦サービスがリリースされデータがある程度溜まったところで見直し、となると移行するのは大変です。

データの構造や容量、アクセス頻度、求められる性能などを考え、適切なマネージドデータベースサービスを選択しましょう。課金体系も異なるので、非機能要件とコストのバランスが取れたものを選択すると良いでしょう。

AWSのマネージドデータベースサービスとその特徴は、2018年11月時点で以下です。

引用：AWSでのデータベース

各サービスの特徴や選定ポイントについてはサービスのブログに書かれているので参考にしてください。

02：オートスケーリング頼りすぎに注意！

オートスケーリングとは、あるトリガー（サーバーの負荷が80％以上になったら、夜1時になったら、など特定の条件）でサーバーの台数を増やすことです。RDS・AuroraといったAWSのマネージドデータベースでも、この条件を指定して同じデータベースを追加することができます。

ところが、このオートスケーリング条件を適切にしておかないとサーバーが増えるタイミングが遅くて結局処理が遅延してしまったり、逆に不要な時にサーバーが複数台立ち上がっていてコストを使ってしまったりすることがあります。

自動でインスタンスが増えるとはいえ、使える状態になるまで時間がかかるので、スケーリング条件は余裕を持たせておくことをオススメします。一時的なアクセス増が予想されるのなら、時間を指定することもできます。もちろん、台数を増やすだけではなくて減らすことも考えておきたいです。

03：オペミスに注意！

マネージドデータベースは、基本的にコンソール画面でなんでもできます。インスタンスの作成・起動・停止・削除・設定変更といった作業が、簡単に、かつオンプレミスやEC2でデータベースを立てるよりもはるかに早い時間（数分）でできます。

画面を操作するだけで全てできて便利な反面、コンソール画面で間違えるとそのまま処理されます。インスタンスの停止や削除といった、重要なオペレーションを行う際には以下のことが必須になっており、AWSがオペミスを防ぐように工夫をしてくれています。

ちなみに、AWSコンソール画面はどのアカウントでも同じ見た目なので、アカウントを間違えてしまう可能性もあります。アカウントによってヘッダーの色を変更するプラグインをブラウザに導入するなどして、視覚的に気づけるようにしておくのも効果的です。

まとめ

マネージドデータベースは、エンジニアによる運用コストをかなり下げることができて便利な反面、気をつけるべき点もあります。

また、マネージドデータベースはあくまでもデータベースそのものの運用負荷を下げるものであり、データ設計や容量管理、負荷監視などはオンプレミスの環境と同様しっかりと行う必要があります。

とはいえ、これまで数日間かかっていた作業が数分〜数時間で完了し、システムの価値を作り出すために時間を使えるようになるのは大きな利点です。

データベース以外にも、AWSからは各種マネージドサービスが提供されています。システムに求められる要件に合わせて、マネージドサービスを組み合わせることで、エンジニアのシステム運用コストを下げることができます。

本来私たちが提供するサービスの価値を生み出す時間をたくさん作れるよう、効率的にサービス開発と運用を行なっていきましょう。