第6回:データベースの負荷分散とまとめ (2/3)

まるごとperl!
事例編〜Web 2.0サービスの中を見せます

第6回:データベースの負荷分散とまとめ
著者:はてな  伊藤 直也   2006/11/1
前のページ  1  2   3  次のページ
アプリケーションの特性を考えたデータベース設計を

   ところで、はてなブックマークではMySQLのレプリケーション機能を素直に使った負荷分散を行っているわけですが、これはソーシャルブックマークというアプリケーションの特性を考慮してのことです。

   ソーシャルブックマークサービスはコンテンツとして閲覧されるページが非常に多く、発行されるSQLのクエリーの多くは参照系のクエリーになります。参照系と更新系のクエリーの割合は、だいたい80%〜90%が参照系という具合です。ソーシャルブックマークに限らず、掲示板やブログなど多くのWEB+DBアプリケーションでは参照系クエリーが多くなるかと思います。

   こういった場合は、レプリケーションによる負荷分散が効果的です。レプリケーションではマスター1台に対して複数のスレーブを持たせることができ、理論的にはスレーブは何台でも追加できます。先に述べたとおり、参照系クエリーはスレーブが担当するので、参照系クエリーを分散させるにはスレーブを追加すれば良く、スレーブの追加が容易なレプリケーションシステム下では分散にはそれほど困らない、というわけです。

   一方のマスターは、スレーブに比較すると台数を増やすことが難しく、データベースに保存されているデータを複数のサーバーで分割保持するなど、クラスタリングのノウハウを導入する必要があります。したがって、更新系処理が多いアプリケーションでの負荷分散は、そうでない場合に比べてはるかに難易度が高くなるでしょう。

   Webアプリケーションを構築するにあたって、いきあたりばったりで進めてはいけないポイントの一つが、このデータベースのクエリーの種類による負荷分散の計画です。更新系処理が多くなりがちなアプリケーションでは、あらかじめクラスタリングしやすいようにテーブルを設計しておくなどの注意が必要になります。アプリケーションの特性上、データベースにどのようなクエリーが集中するのかを考慮してデータベース設計を行っておきましょう。

tmpfsにMySQLのデータを展開してディスクI/O レスデータベース

   マスターとスレーブの2台にデータベースを増やしたおかげでクエリーの振り分けができました。しかし、参照系のクエリーが多いというサービスの特性もあり、このままではまだその参照系クエリーがスレーブサーバーに集中しているため、たいした分散はできていないことになります。

   そこで負荷を下げるために更に手を打ちます。スレーブをもっと増やす、という手段ももちろん使いますが、はてなではその前にもう一つ特殊なテクニックを利用しています。

   データベースサーバーで処理の大部分を占めるのがディスクへのアクセスです。データはディスクに保存されているため、MySQLはそこからデータを読み出します。ディスクI/Oはメモリへのアクセスなどに比べると遥かに遅いため、ディスクI/Oが頻発するとサーバーのパフォーマンスは劣化します。そこで高速なディスクを用意するのもいいのですが、保持しているデータがそれほど大きくなければ、そのデータをすべてメモリ上に展開してしまうという少々強引なテクニックを使うことができます。

   Linuxでは、メモリ上の一定の空間をファイルシステムとして利用することができる、tmpfsというファイルシステムが利用できます。いわゆるRAMディスクのようなものです。

   tmpfsで数GBのファイルシステムを作成し、その上にMySQLのデータを移動させます。tmpfsで作られたファイルシステムの実体はメモリですので、こうすることによりデータベースサーバーでのディスクI/Oを完全にカットし高速化できるのです。

   しかし、メモリ上にデータを展開するのは高速な反面、リスクも伴います。その主たるものはサーバークラッシュ時のデータ損失です。tmpfsはメモリなので、サーバーの電源が切れたところでそこに保存されたデータはすべて失われてしまいます。データベースに保存されるような貴重なデータが不意のハードの故障や停電などで消失してしまっては困ります。

   ただし、レプリケーション環境であれば、たとえスレーブのデータがすべて消失してしまったとしても、同期しているマスターにすべて残っているというところがミソです。マスターのデータは通常どおりディスク上で運用しつつ、スレーブはtmpfsによるメモリファイルシステムで運用するのです。万が一スレーブが故障してデータがなくなっても、マスターからまたスレーブを構築すればOK、というわけです。

前のページ  1  2   3  次のページ


株式会社はてな 伊藤 直也
著者プロフィール
株式会社はてな  伊藤 直也
取締役最高技術責任者
ブログサービスやソーシャルブックマークなど、はてなの各種サービスの企画、開発を行う。著書に「BlogHacks」(オライリージャパン刊)。「続・初めてのPerl」(オライリージャパン)、「Perl救命病棟」(翔泳社刊)では監訳を務めた。


INDEX
第6回:データベースの負荷分散とまとめ
 データベースの負荷分散
アプリケーションの特性を考えたデータベース設計を
 tmpfsにMySQLデータを移動する
事例編〜Web 2.0サービスの中を見せます
第1回Inside Hatena Bookmark
第2回はてなフレームワークとPerlとシステム負荷
第3回Backend Evolution(前編)
第4回Backend Evolution(後編)
第5回サーバの追加とロードバランシング
第6回データベースの負荷分散とまとめ

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30