トランザクション数の多いDBサーバーのディスク構成について

IOPSが高い値を維持でき、ある程度コストを抑えたDBサーバーのディスク構成を考えてみる。RAIDカードを全てのスレーブに置くというのは価格がかかりすぎること、SSDが安くかえるようになったことを考えると、以下のような構成が、そこそこの価格でIOPSを稼ぐための構成だと考える。

DBサーバーの構成

  • マスターDBのサーバー
    • DBミドルからのwriteがすぐに終わるように、RAID+BBWCを使いwriteのIOPSを高める
      • InnoDBログファイルやREDOログなどの同期書き込みのコストは極めて高いので、BBWCによりバッファリングすることで大幅にディスク負荷を減らすことができ、特にマスターDBではRAIDカードは使いたい
    • データファイルはランダムライト、ログファイルはシーケンシャルライトになることから、きわめてトランザクション量が多い場合には、データファイルとログファイルを分離し、I/Oパターンを分離する。ただし、運用の容易さを考えれば、データファイルとログファイルはディスクは分けずに、RAID1+0だけで管理してもよい。
      • データファイルをRAID1+0にして、SSDに配備
      • ログファイルをRAID1にして、HDDに配備
  • スレーブDBサーバー
    • スレーブは台数が多く必要になるので、SSDだけの構成にしてRAIDカード代を安く押さえる
    • ただし、スレーブについても、全てのサーバーにRAIDカードを配置できるだけコストをかけられる場合には、SSDのRAID1+0構成を組めばよい。

マスターについては、(RAID+BBWC) + SSD、(RAID+BBWC)+HDDで、ライトのIOPSと運用体制によっていずれかを選ぶ。また、トランザクション数が極端に大きくなく、定常的にトランザクション数が多いという状態でなければ、RAID+BBWCとHDDでの運用でよい。

SSDの運用について

SSDを使う場合には、HDDと違う運用の検討が必要になってくるので、その点注意が必要である。注意点だけでなく、それを考慮した運用が行える体制があるかが、導入上大きなポイントになる。

  • TrimのサポートがRHEL6からということを考えると、SSDで運用する場合には、ディスクの使用量が増えてきたときのことを事前に検討する必要ではある。
  • 性能劣化を前提に性能劣化の範囲を実ディスクで確かめた上でSSDを配備する必要があるという点で、HDDとは違う運用が必要になるので、その点についてはSSDの耐久テスト＋性能テストをした上で、ディスク使用率が上がってきたときの劣化時の性能を確認しておく必要がある

FusionIO/tachIOn の使用について

  • FusionIO, tachIOnが数万のIOPSが出ることを考えると、書き込みするデータ量が多くなければ、オーダーとして書き込み回数が10倍以上多くてもよいわけで、DBサーバーを最大1/10程度にできる可能性はあり、それを考えると十分に検討の余地はありそう。
  • トランザクション数が多く、導入しない場合に、台数が増えて、運用コストが初期のイニシャルコストを超える場合には、導入を検討する価値がある。ただし、本当の大規模サービスでなければ、それをペイできる環境ではないとは思う。

IOPS視点のディスクのプラニングについて

以下の2点を行い、IOPSの増加に対してどのようなプランをたてるかを検討することが重要。I/Oサブシステムの性能を意識しておくことで、どのくらいでI/Oが限界にくるかがわかるようになるからである。

  • I/OサブシステムにおけるI/Oの性能を把握しておくこと(bonnie++やIOMeter)
  • iostatのw/sとr/sの傾向を見て、IOPSの増加傾向を把握すること
    • 特に、データファイルとログファイルのディスクが分離されていると、IOパターン毎のIO回数が把握しやすくなり、どのI/Oパターンに対して強化をしていくかが検討しやすくなる。

ディスクへのIO（特に回数）はネックになりやすく、これはMySQLやOracleといったDBだけでなく、他のミドル全般にいえる。従って、ディスクの性能状況については特に注意深くモニタリングし、問題の発生を事前に予見できるようにしておく必要がある。