業務システムやWebサービスにおいて、データベースはシステムの要とも言える存在です。そして、その要であるために処理が集中し、システム全体のパフォーマンスに大きな影響を及ぼします。

システムのパフォーマンスは様々な要因によって変わりますが、データベースにその原因があることは少なくありません。そこで、データベースをボトルネックにしないための対策を幾つか解説します。

データベースがボトルネックになる要因

データ量の見積り不足

データベースに投入されるデータ量を読み間違えるケースはよくあります。データベースは徐々にデータ量が蓄積されていくものですが、それでも初期設計時点である程度の見積りは行うはずです。この見積りが甘いと、運用時に投入されるデータ量が桁違いに増えてしまって、データベースのパフォーマンスが低下します。

業務システムの場合はある程度読みやすいですが、コミュニケーションサービスなどユーザー数の増加に合わせて倍々に増えていく場合もあるでしょう。

データベースサーバーのスペック不足

CPUやメモリなど、データベースのスペックを読み間違えるとパンクしてしまう可能性があります。特に参照系が多い場合はキャッシュをメモリに載せたくなりますが、メモリが不足しているとそれも難しくなります。最悪、メモリ不足によってクラッシュしてしまう場合もあります。

ボトルネックの解消としてデータベースサーバーを強力にする（お金で解決する）ケースはよくあります。参照系であればレプリケーションで対応できるかも知れませんが、データの追加や更新が多い場合は難しいでしょう。データベースサーバーの空きリソースには日頃から注意が必要です。

クエリーの品質が悪い

最近はO/Rマッパーを使ってデータベースにアクセスすることが増えていますが、複雑なクエリーになると最適化されたものが生成されるとは限りません。ヒントを付けることで高速化されることもあるので、自動化しない方が良い場合もあります。

クエリーの品質についてはWebアプリケーション側で解決できる問題になります。参照回数を減らしたり、トランザクションを工夫することもできるでしょう。意外とWebアプリケーション側に原因があるケースは多いので、クエリーログを見直して遅いものはないのかチェックしましょう。

スキーマ設計の問題

正規化が正しく行われていない場合です。データを横（カラム）で持つのか、縦（行）で持つのかと言った問題もあります。データの取り出しやすさや、利用目的によって変わるでしょう。また、最近ではドキュメント型データベース（NoSQL）のように、あえて正規化しない方が良いものもあります。

スキーマ設計の問題は、選任のDB管理者が不在なプロジェクトや、スキーマ設計に不慣れなメンバーしかいない場合によく起こります。また、サービス運営中に頻繁にスキーマ変更が行われる場合、その歴史の中で徐々に正規化が崩れていきます。データベースはWebアプリケーションと比べると圧倒的にリファクタリングしづらいと思いますので、設計時点できちんと考えて作り込むのがお勧めです。

データベースのボトルネック化を防ぐには

上記のような課題を解決するのは当然として、さらにデータベースのボトルネック化を防ぐにはどうしたら良いでしょうか。

キャッシュを活用する

キャッシュすることでデータベースへのリクエスト数を減らし、負荷を減らせる可能性があります。キャッシュはWebアプリケーション、データベースどちらでも考えられるでしょう。Webアプリケーション側でキャッシュできれば、そもそもクエリーが発生しないので高速になります。

データベース側のキャッシュであればViewを使ったり、メモリ上にデータを載せることで高速化を期待できます。

スケールアウトする

レプリケーションを活用してスケールアウトさせることもできます。例えばMySQLなどはレプリケーション設定が豊富で、かなり複雑なレプリケーション構成が構築できます。

ただしスケールアウトのためにはデータの読み取りが多く、更新や削除が少ない場合にメリットがあるでしょう。システムの特性に合わせて選択する必要があります。

DBaaSの利用

負荷に応じたスケーラブルなデータベース提供を考えるならばマネージドサービスであったり、DBaaS（Database as a Service）の利用を選択しても良いでしょう。

PlanetScaleのようなデータベースサービスもあります。なお、DBaaSではデータベース互換としつつも、多少の違いがあるケースも見られるので注意してください。

BaaSの利用

データベースに直接接続するのではなく、BaaS（Backend as a Service）を利用する方法もあります。この場合、データベースにはRESTful APIやGraphQLなどを通して（HTTPS経由で）利用することになるでしょう。

データベースの運用を考えなくて良い反面、複雑なクエリーが実行できないのが難点です。また、多くのBaaSではトランザクションをサポートしていないケースが多いです。

お金で解決する

予算が十分にある場合には、よりハイスペックなデータベースサーバーに切り替える手があります。パブリッククラウドが提供するマネージドデータベースの場合はインスタンスサイズを変えることで、より強力なデータベースサーバーを選択できます。

まとめ

データベースは常時稼働が求められ、かつオンタイムでデータが投入され続けます。そのため、停止することも憚られることがあるでしょう。そうした中でデータベースのボトルネック化を防止するのは至難の業です。

私たちの提供するHexabaseでは複数のNoSQLデータベースを統合し、RDBMSのように使えるデータストレージを実現しています。BaaSを利用することで、バックエンドのパフォーマンス低下やボトルネック化を防ぐことができます。ぜひご覧ください。

データベースとAPI – Hexabase