by shigemk2

当面は技術的なことしか書かない

サーバ/インフラを支える技術2 5 高速で軽量なストレージサーバの選択

前回
サーバ/インフラを支える技術2 4 MySQLのスレーブ+内部ロードバランサの活用例 - by shigemk2

ストレージサーバが膨大になってくると、以下の問題に直面する

  • 全webサーバにデプロイするのに時間がかかりすぎる
  • 全webサーバに大容量なハードディスクを搭載する必要がある
  • 全webサーバのデータに整合性が取れているか確認するのが非常に困難
  • webサーバの新規投入が困難

データをファイルとして扱ったほうが楽なので、
各webサーバは大容量ストレージサーバからNFSマウントして
データを取り出すのが一般的な構成である

しかしシステム管理者としてはストレージサーバは使いたくない。
理由として

  • ストレージサーバに障害が発生すると被害が広範囲に及ぶ
  • 万一データが消失すると復旧に多大な時間と労力がかかる
  • ストレージサーバはボトルネックになりがち(しかも単一故障点)
  • 商用の製品が高価

単一故障点になりやすい
特にNFSマウント中にストレージサーバが停止したら
ずっとNFSマウントの終了待ち状態でプロセスが一杯になり、大変なことにな

ボトルネックになりやすい
NFSサーバは他のサーバと違って、スケールできないため、ここがボトルネックになると
改善は非常に困難となる。
一応複数のNFSサーバを用意することで負荷分散は可能だが、
今度はデータの整合性が取れなくなる。

というわけで、理想的なストレージサーバは、

  • 大量のアクセスがきてもボトルネックにならないくらい速くしたい
  • 複数台のサーバにファイルを同期するのは避けたい
  • 単一故障点になるのは避けたい
  • できればオープンソースで実現したい

解決方法

  1. 高価なストレージサーバではなく、安価で軽量なWebサーバで十分
  2. NFSではなくHTTPをストレージプロトコルとして活用する

HDDへの書き込みはNFSサーバ経由で、
HDDからの読み込みはWebサーバを経由で行うこと(書き込みのみマウント)で、
わざわざ高価なストレージサーバを利用しなくても軽量な
ストレージサーバを実現できる。

また、webサーバはApacheでなくてもよく(CGIやSSIなどの動的生成は不要だか
ら)、thttpdでもよい。

ストレージからの読み込みのやりとりはHTTPで行われるが、
これにより、webアプリケーション側で自由にタイムアウトを設定できるので
便利であり、また異常を検出したときにメッセージを簡単に送ることも出来る。
これにより障害でサイトが全停止する危険性を減らすことが出来る。
webサーバがNFSマウントしてしまうとNFSサーバが停止したとき、Apache
再起動することもままならななくなる。



残る問題

  • 単一故障点を避ける
  • 複数台のサーバにファイルを同期させたくない

単一故障点を回避するためにはサーバを増やさなくてはならないが、
複数台のサーバにデータを同期するのはしんどいため、
互いに相反する問題であるため、より高度な対策が必要となる。


[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)