こんにちは。ハートビーツ運用スタッフの山田です。

１１月１４日（土）、インフラエンジニアの技術交流の場として開催させて頂いておりますhbstudyが開催されました。 hbstudyは今回で５回目となり、40名近いみなさまにご参加頂きました！本当にありがとうございました。

　前半は永安悟さんより、「PostgreSQL安定運用のコツ２００９」と題してPostgreSQLの運用管理に関してお話し頂きました。後半は松信嘉範さんより、「DBサーバーのパフォーマンスチューニング」と題してMｙSQLを中心にデータベースのチューニングについてお話頂きました。

PostgreSQL安定運用のコツ2009　永安悟さん

（資料：http://www.slideshare.net/uptimejp/postgresql2009-hbstudy5）

永安さんからは、PostgreSQLのパフォーマンスに関わる初期設定からデータベースの監視の必要性、性能劣化要因とメンテナンスという内容で、PostgreSQLのしくみから運用テクニックまで分かりやすくご説明頂きました。

　まずPostgreSQLのパフォーマンス考える上で重要なポイントとして、各プロセスとデータファイル間のI/O処理をいかに適切にコントロールするかが挙げられます。 PostgreSQLのしくみとして、クライアントからのアクセスがあると、アクセスを待ち受けるリスナプロセス（postmaster）からフォークされたサーバプロセス（postgres）が処理を引き継ぎます。サーバプロセスは各データファイル（テーブルファイル、インデックスファイル等）にアクセスする際、共有バッファというメモリ領域を介して行います。この共有バッファのサイズを定めるshared_buffersという設定項目がPostgreSQLのデフォルトのインストール設定では小さく、ハードウェアのパフォーマンスを引き出せない可能性が高く、初期設定時には特に注意が必要です。（実際はデータベースの設計やアプリケーションの構造により適切な設定値は異なる）他にもパフォーマンスに影響する設定項目があり、デフォルト設定で動作させず適切な初期設定を行うことが重要とのことです。

　また、パフォーマンスを維持するためにデータベースの監視も重要です。監視項目としてはデータベースサイズ・テーブルサイズ、トランザクション量、ディスクI/Oなどが挙げられます。これらを測定し、可視化することでディスクのキャパシティがどれくらいかやパフォーマンスが低下する兆候を事前に把握し対策することが出来るため、データベース運用に監視は必須といえるでしょう。

また、PostgreSQLの特徴として、レコードが削除されても削除した領域が不要領域としてディスク上に残り、ディスク使用効率が落ちるという問題があります。この不要領域を再利用可能領域として回収するVACUUM処理が実際になされていないために性能劣化が起こることがあります。（エンジニアが性能劣化で呼び出されるとVACUUM処理をしていないだけだったということが過去には結構あったそうです。）VACUUM処理も自動化できるコマンドもあり、工数のかかるメンテナンスを省力化していくことも可能です。

　データベースの運用管理には初期設定段階から監視、そしてメンテナンスと一連の流れで運用することが重要ということで、実際の運用に役立つ内容をお聞きすることができとても参考になりました。

DBサーバーのパフォーマンスチューニング松信嘉範さん

（資料：http://www.mysql.gr.jp/frame/modules/bwiki/index.php?matsunobu）

松信さんからは、著書「Linux-DBシステム構築/運用入門」より、インデックスのチューニング、Linux上でデータベースを用いる際のチューニングテックニック、そしてストレージとしてSSDを用いるメリットと注意点という内容で、MySQLを中心にお話し頂きました。

　最初にデータベースのチューニングポイントということで、blogエントリ用のテーブルを例に紹介頂きました。まず、データベースチューニングの基本として、データサイズをいかに小さくするということが重要となります。そのためには、適切なデータ型を使うことでデータサイズを小さくすることが可能です。　　またパフォーマンスに大きく影響する項目として、ディスクI/Oをいかに減らすかということが重要となります。blogのテーブルがuserid（ユーザID）、postdate（投稿日）、title（タイトル）、body（本文）のような列を含む場合、通常はテーブルの大部分がbodyとなります。しかし実際は毎回bodyを参照するクエリは少なく、userid、postdateのみを参照するだけで完結してしまうクエリが多いため、bodyがメモリを占有しているので新たなアクセスに対し、新たなディスクI/Oが発生してしまうことになります。　このような場合、bodyのような巨大な列を別のテーブルに移す等もパフォーマンスには効果的とのことです。（この場合正規化が崩れるという問題もある）。また巨大な列の扱いを最適化してくれるストレージエンジンもあり、そちらを使うのも手です。　　またディスクI/Oを減らす方法として、Covering Indexも有効。Covering Indexとは、アクセスしている列が全てインデックスに含まれる場合、クエリがそのインデックスのみを読むだけで完結するため、レコードへのI/Oを減らせるというものです。

　次にお話し頂いたLinux上でのチューニングは下記がポイントとなります。

　・メモリを十分にとり、ダイレクトI/Oを使用する。（ファイルシステムキャッシュを迂回することで高速化。大容量のメモリが必要）

　・適切なファイルシステムを選択する。ext3、xfs、ex2、btrfs等からシステム要件に合ったものを使用する。（ジャーナルの有り無し等）

　最後にお話し頂いたのは、ストレージとしてHDDの代わりにフラッシュメモリを用いたSSDを使用することでI/Oを高速化するという興味深い話題です。HDDとSSDのI/O性能の差のベンチマークをするとHDDのI/Oが500回/秒くらいのところをSSDだと25000回/秒となるそうです！さすがSSDといった感じです。　HDDはシーケンシャルリード/ライトが得意、SSDはランダムリード/ライトが得意という特長を生かし、HDDとSSDを併用し適切にファイル配置で使用するこで安定性と価格面でメリットがありそうです。　しかしSSDを用いれば複雑なチューニングをせずとも簡単にパフォーマンスをよくすることは可能ですが、SSDはまだ安定性などに製品差があるため製品選択には注意が必要とのことです。

今回お話し頂いたデータベースのパフォーマンスチューニングは、実戦的で非常に興味深い内容でした。今やwebアプリケーションにってデータベース無くして語れないものとなっており、安定して高速な稼働が求められています。スケールアウトしなければ対応できない状況でも、適切なパフォーマンスチューニングを行うことで回避できる場合もあり、データベースを扱う上で必須の作業といえそうです。