【ITニュース解説】Your database is not elastic!

現代のウェブアプリケーション開発において、システムが将来的な利用者の増加や処理要求の増大に対応できる能力、つまりスケーラビリティは非常に重要な要素である。特にクラウドコンピューティングの普及により、必要に応じてサーバーの台数を増やしたり、性能を向上させたりすることで、システムを柔軟に拡張できることが一般的に期待されている。しかし、ウェブサーバーや非同期処理を行うワーカーのようなアプリケーション層は比較的容易にスケールできる一方で、データベース、特にリレーショナルデータベースは、その「弾力性」を持たず、スケーリングが難しいという根本的な問題が存在する。

ここで言う「弾力性がない」とは、負荷が増大した際にウェブサーバーのように瞬時にサーバーを増強したり、柔軟にサーバーの数を調整したりすることが難しいという意味である。ウェブサーバーであれば、アクセス集中時には新しいサーバーを数秒で起動し、システムに追加するだけで負荷を分散できる。しかし、データベースはこれほど単純ではない。

データベースがスケーリングを困難にする主な理由は、そこに格納されるデータの整合性と一貫性を厳密に保つ必要があるためである。例えば、銀行口座の残高やECサイトの在庫数といったデータは、常に正確で矛盾のない状態が求められる。複数のサーバーが同時に同じデータを変更しようとすると、データが壊れたり不正確になったりする可能性があるため、データベースは複雑な仕組みを用いてこれを防ぎ、データの一貫性を保証している。この厳格な制約が、複数のデータベースサーバー間で負荷を分散し、データを並行して処理することを非常に複雑にする要因となっている。

データベースのスケーリングにはいくつかの方法が検討されるが、それぞれに困難が伴う。一つは「水平スケーリング」という方法で、これは複数のデータベースサーバーを追加して処理を分担させることを指す。具体的には「リードレプリカ」と「シャーディング」がある。リードレプリカは、メインのデータベース（マスター）のデータを複製した、読み取り専用のデータベース（スレーブ）を複数用意し、主に読み込み処理の負荷を分散させる。多くのユーザーがデータを参照するようなシステムでは有効だが、データの書き込み処理は引き続きマスターデータベースに集中するため、書き込み負荷が高い場合には限界がある。また、設定や管理には専門知識が必要となり、クラウドのマネージドサービスを利用しても完全に手間がなくなるわけではない。

もう一つの水平スケーリングの選択肢である「シャーディング」は、データベース全体を複数の小さな断片（シャード）に分割し、それぞれのシャードを異なるデータベースサーバーで管理する方法だ。例えば、ユーザーIDの範囲でデータを分割し、特定のID範囲のデータはサーバーAに、別のID範囲のデータはサーバーBに格納するといった形である。シャーディングは非常に強力なスケーリング手法だが、その実装と運用は極めて複雑である。データの分割ルールの設計、シャード間でデータが移動する際の対応、そして特に難しいのが、複数のシャードにまたがる処理の実現である。これらはシステム設計を大きく複雑にし、開発・運用コストを増大させる要因となる。

水平スケーリングが難しい場合、しばしば「垂直スケーリング」が検討される。これは、現在のデータベースサーバーのCPU、メモリ、ストレージといった物理的なリソースを強化することで、一台あたりの処理能力を向上させる方法である。サーバーの性能向上は比較的容易であり、短期的には効果的な解決策となり得る。しかし、この方法には根本的な限界がある。サーバーの性能向上には物理的な上限があり、いずれは最高性能のサーバーでも対応できなくなる時が来る。また、高性能なサーバーは非常に高価であり、コスト面でも持続可能な解決策とは言えない。

かつての分散アプリケーション開発では、データベースこそが唯一スケール可能な部分であり、アプリケーションの性能はクライアント側のマシンの性能によって制限されることが多かった。しかし、現代では状況が逆転している。クラウドの普及により、ウェブサーバーやアプリケーションサーバーは容易に水平スケーリングできるようになり、アプリケーションの処理能力は飛躍的に向上した。その結果、アプリケーションがより多くの処理要求をデータベースに送るようになり、データベースがシステム全体のボトルネックとなるケースが増加しているのだ。

筆者の最近の実体験は、この現実を強く示している。数週間かけて慎重に計画・テストされた新しいウェブアプリケーションのデプロイメントが、本番環境で予想以上の負荷がかかったためにすぐに機能不全に陥った。問題の原因は、負荷テストが実際の運用状況を十分に反映していなかったことと、新しいAPIが想定よりもはるかに多く呼び出され、データベースに過剰な負担をかけてしまったことにあった。

この状況で、ウェブサーバーは増え続けるリクエストに対応しようと自動的に台数を増やした（スケールアウトした）。しかし、これは事態をさらに悪化させた。なぜなら、多くのウェブサーバーが同時にデータベースにアクセスすることで、唯一スケールできないデータベースへの負荷がますます増大したためである。結果として、データベースが処理能力の限界に達し、アプリケーション全体のパフォーマンスが著しく低下するという悪循環に陥ってしまったのだ。

最終的に、この問題は一時的にデータベースサーバーの性能を向上させる（スケールアップする）ことで解決された。クラウドのマネージドデータベースサービスを利用していたため、比較的容易にスケールアップできたものの、費用はかさみ、また自動的に性能を元に戻す（スケールダウンする）のが難しいという課題も残った。この緊急対応によって時間を稼ぎ、その間にアプリケーションの根本的な修正を行うことができた。幸いにも、データベースに集中的な負荷をかけていた機能は比較的独立していたため、その部分のアーキテクチャを再設計し、データベースへの依存度を低減させる改修を迅速に実施することができた。

この経験から得られる教訓は大きい。まず、負荷テストは本番環境の利用状況をできる限り正確にシミュレーションする必要があるということだ。そして最も重要なのは、データベースはシステムのボトルネックになりやすい部分であることを常に意識し、アプリケーションの設計段階からデータベースへの負荷を最小限に抑える工夫が不可欠であるということである。安易にデータベースに依存する設計を避け、キャッシュの活用、非同期処理の導入、あるいはデータの特性に応じた異なるデータベース（NoSQLデータベースなど）の利用を検討するなど、真にスケーラブルなシステムを構築するための視点が、システムエンジニアには強く求められる。