PakuReserve(パクレゼルヴ) R&D Laboratory

サロン系の服着てます。姜子牙です。そのせいか年齢相応に見られません。
若作りじゃないですよ？

システム運用って暇そうだなあ、そう考えていた時期が私にもありました。
しかし、それは最も理想的な形でありつつ、決して何もしていないわけではないというのが分かってきました。

運用者が忙しそうというのは、決して良いシステムではないのです。
定常的に行うような手作業が発生しているのは、それだけオペレーションミスの機会が多いということですし
「定型的な作業を自動化する」というシステム化そのものの目的を全う出来てない可能性もあるからです。

また、技術者のスキルという側面から見た場合、それは起こり得る障害に対して未然の防止が出来ていない可能性も高いのです。
（偉そうに言えるほど自分が出来ているわけでもないですが・・・）

とは言っても、全体をとても幅広く把握しつつ、且つその中で1つのミスを許されないなんて場合もあります。
物理面で言えば、サーバの機械部分、設置場所の温度などの環境、各種ケーブル類が抜けないようになっているかなど。
ソフト面では、OS・M/Wから開発されたアプリまで。それぞれが個々に不具合がないことと、組み合わせた場合にも
それぞれがかみ合わずに不具合にならないかなど、枚挙に暇がありません。
他にも外的要因としてセキュリティの甘さによるクラックとかとか。

一度全て想定しうる全てを書き起こそうとして、目次に当たる項目を列挙したことがあるのですが
項目だけで300行近くにまで達して断念したことがあります。
(仮に1システム用の運用資料として、1項目平均4ページとしたら1200ページに達する)
まあ、重複項目・不足項目がどれだけあるかは不明なため参考にすらならないかもしれませんが・・・。

これらを全ての対策を全て事前に施せば・・・と考えることはありますが
それをするほどの予算や時間があることはなく、またそんな想定を超えたことでシステムが止まることもあったりするのです。
聞いた話であればlsコマンドでサーバが停止したこともあるとのこと。（かなり特殊なケースだと思いますが）

大小様々なシステムが、社会インフラとして当然になりつつ・・・いや、もうなっているのかな。
それらの停止によるダメージは日に日に上がっていっているように思います。
しかし、それに対してシステムを止めずに動かし続けることを考えられる人が追いついていない、そんなことを感じます。

問題提起に留まってしまいますが、ほんの微力でもそれを改善できればなあ、と思い本エントリは書いてみました。

[姜子牙]（*’-') < 「まだまだ勉強が足りないですねっ。」

はい、行ってきます。

姜子牙 その他, 未分類

ガム食べ過ぎです。姜子牙です。700円くらいの大きいサイズのボトルガムが2,3日で無くなります。
ガムは無くなったらコンビニへ行き買って補充します。常にガムがあることが重要。

[Mr.マカー](#ﾟДﾟ) < 「業務時間中に行くんじゃない。」
[姜子牙]（;’-') < 「あ、すいません・・・。」

で、私のガムは我慢すればいいのですが、サーバは必要な物が無くなるとそれまでと同じ動きをしてくれなくなります。
車に使うガソリンほど目に見えて減る物は無いのですが、サーバでも消耗して放って置くと無くなってしまうものもあります。

一つは摩耗するハードウェアや物理媒体。バックアップメディアとして使用されるDAT・LTOであったり、定常的に使うようであればCD-Rやプリンタのインク・紙なんかが該当します。
無くなった際には速やかに補充できるように予備なんかを準備する必要がありますし、それらの発注や在庫管理なんかが必要になります。

[姜子牙]（*’▽’) < 「ガムもここに・・・」
[べきこ] (´ー｀) < 「入らないですね。」
[SELLCA](￣ o￣) < 「どんだけガム好きなんですか。」

もう一つは期限付きの申請・ライセンス。ウイルス対策ソフトのアップデートライセンスであったり、サーバ証明書、ドメインなんかが該当します。
こちらは補充というより更新手続きなのですが、良くあるのが構築時点と担当者が変わり必要な更新手続きがなされなかったり、期限切れで使用できなくなってても気づかなかったりすることがあります。特にドメインなんかは、下手をすると余所に使われたりしてしまうことがあるので、何の申請をいつまでにしなければならないのかを構築時点で明確にしておくと、いざその時になって慌てずに済みます。

[チョコボール](o・。・o) < 「SUICAの定期が切れてて、気づいたらチャージが減ってるとか。」
[姜子牙]（;’-') < 「定期切れてるのわかってるけど朝急いでると買えないんだよね・・・。」

期限切れなんてわかることじゃん、とは良く言われたりするのですが、申請スパンが年単位だったりするとその当時の担当者がいなくなっていて、わからなくなってしまうことが多いのですね。
(担当者が健在でも忘却の彼方になっていることもありますが・・・）

単にシステムを維持することは出来て当たり前ではあるのですが、その当たり前も案外大変だったりするのです。一つ一つは大した作業ではないものの、その全体に関連なく散らばっていることが多いため気づいたらあっちもこっちもなんてことが起こり得たりするのです。

[姜子牙]（*’▽’) < 「継続は力なり。」
[かーつん](#ﾟДﾟ) 　／ 「意味が
[のびーにょ](#ﾟДﾟ) ＼ 　　　　違う！」

はい、行ってきます。

姜子牙 Tips, その他

新規サービスオープンのため対応中。姜子牙です。
本体のネタ以上にこの冒頭のネタを練りこんでいたりすることがあります。

2/22のエントリでバックアップについて記載しましたが、今回はバックアップ第二弾を書きたいと思います。

さて本題、バックアップは何重に取るべきか？

バックアップの対象となるデータをマスタデータと呼んだ場合、それを一つコピーしてバックアップすると1重とします。
私は基本は2重に取るようにバックアップは設計しています。1重ではやや不安で、3重だと余剰だろうと考えています。
2重の場合、マスタデータ含めて3つ同じデータが存在することとなります。

ここでのポイントは「このバックアップでマスタデータが何個分存在することになるか」です。

よくあるのが、AというディレクトリのデータをBというディレクトリが常に同期していて同じデータが入っているのに
AもBもバックアップに含めてしまう、ということがあります。
これだとマスタデータはAのディレクトリのデータなのに、Bのディレクトリ、Aのバックアップ、Bのバックアップという形で
4つも存在してしまうことになるわけです。

多ければ多いほどデータの消失確率は減りますが、逆にその分ディスク容量を圧迫することになります。

なので、私の場合、上記A・Bのディレクトリがあった場合、Aはバックアップ対象としますが
Bはバックアップ対象から外すように設定をするわけです。
こうするとAディレクトリ、Bディレクトリ、Aのバックアップでマスタデータ3つ分というわけです。
まあ、他の同期していないデータとかと一纏めにする都合でAバックアップのコピーが生まれるので
データ4つになっちゃうんですけどね・・・。

もう少し具体的に言えば
更新系を司るマスタデータベースがあって
それのホットスタンバイであるスレイブデータベースがあって
マスタ・スレイブそれぞれでバックアップ取って
さらにそれぞれのバックアップを2重化したりすると
データ6つ分になっちゃったりするんですよ・・・。
いや、うん直さないといけないですけどね・・・。

やや余談になりますが、
サーバがRAID1の場合、その時点でマスタデータが2重だからバックアップ1個取れば3重と言えなくもないですが、
私個人の考えとしてRAID1でコピーされるデータはバックアップとみなしていません。
あくまで、HDD物理障害対策の機構であって明示的なバックアップではないと考えているからです。
|-’) HDDが無事でもRAIDのカードやチップが往生してしまうこともあるし・・・。

まあ後半はやや個人意見だらけなので、こんなんあるんだ程度としておいて頂いて
バックアップを設計する時は一度マスタデータが何個分になっているか意識してみると良いかもしれません。

[Mr.マカー](#ﾟДﾟ) < 「で、バックアップサーバどうすんの？」
[姜子牙]（;’-') < 「あ、えーと今のサーバのディスク枯渇するまでもうちょい時間あるので検討します・・・。」
[べきこ] (´ー｀) < 「時間経って忘れてると大変なことになりそうだね」
[姜子牙] ∑(；’-') < 「ドキッ」

はい、冗談にならないです。

姜子牙 Linux, Tips, その他

メールサーバと格闘中です。姜子牙です。
涙目です。

さて今回はMySQLのチューニングについて書きたいと思います。

チューニングと言ってもMySQLはコンフィグファイル(my.cnf)を変更する方法とは別に再構築（コンパイルし直す）という方法があります。不要なオプションを削ったり、逆に組み込んだりすることで機能を追加したり、処理速度を上げることができるのです。が、まだ再構築の方についてはお世辞にもここに書けるほど把握できてないのでここではmy.cnfの変更でできることでチューニングをしてみたいと思います。

まず、以下が現在DBサーバに施してあるチューニングに関わる設定部分です。

#For MyISAM Table Global Buffer
set-variable = key_buffer_size=256M
#For InnoDB Table Global Buffer
set-variable = innodb_buffer_pool_size=256M

set-variable = query_cache_size=64M
set-variable = table_cache=128

key_buffer_sizeとinnodb_buffer_pool_sizeはそれぞれMyISAMとInnoDBでのアクセスの際に使用されるキャッシュメモリになります。
現在DBにはそれぞれのDBエンジンを使用したDBが稼働しているため、両方にそれぞれキャッシュメモリ256MBを割り当てています。
もし、MyISAMやInnoDBどちらかだけであれば、設定はどちらかだけでOKです。
またクエリのキャッシュに64MB、テーブル(テーブル単位でのキャッシュ)に128個分のキャッシュを割り当てています。

テーブルのキャッシュはテーブル数単位で、明確に何MBなどは指定できないようです・・・。

今回はこれらの設定のみとしていますが、もしDBが参照系(Select文)が多いとか、逆に更新系(Insert文・Update文など)が多いなど
特徴がある場合には、read_buffer_sizeやsort_buffer_sizeなどにキャッシュを割り当てるとさらに速度向上が見込めます。
しかし、上記の設定は1クエリごとにいくつのメモリを割り当てるかの設定なので
平均のクエリの発生頻度などを考慮しないとメモリを食いつぶしてしまうのでご注意ください。
(key_buffer_sizeなどは全クエリ共通の領域として設定されるため、上記設定だと全体共通で256MBを使用するという設定です)

また、key_buffer_sizeとinnodb_buffer_pool_sizeについてはキャッシュのHIT率を測る方法があるため、それを今回は
チューニング効果の指標として使用しました。
MySQLのStatusで取得できるKey_readsとKey_read_requestsをKey_reads/Key_read_requests で求めるとキャッシュミス率が出ます。

弊社のDBサーバはチューニング前はHIT率が99.3%でしたが、チューニング後からは99.7%～99.8%になっています。
どこかのブログでは99.7以上が目安と書かれていたため、効果はまずまず・・・と言ったところでしょうか。

まだまだ設定できる項目は多く、その中をよく調査するともっと処理性能を向上させることは可能かもしれませんが今回はまずこのくらいで留めています。

3部に渡って書いたチューニング編ですが、サーバ側だけでできるチューニングには限界があります。
ApacheにはPerlやPHPのコード、MySQLにはSQL文によっても負荷が左右されます。以前にも少し書いたとおり、サーバ担当ですべて把握できれば良いのですが、規模が大きいほどそれは難しくなり少なからず開発のPGやSEと協力して行うことが重要になります。

自分の作業範囲で掘り下げられる部分は掘り下げ、範囲の外になってしまう部分はその範囲の担当に協力を仰ぎましょう。

サーバは乗っかるアプリ全部に影響を与えるため、担当者間調整だったり、コミュニケーションが重要になってきます。学生の卒業年度にやった性格診断で社交性が最低レベル(5段階評価の1)を記録した私がここまで出来ているためその重要性を意識していれば、コミュニケーション苦手っていう人でも苦手克服くらいはできるんじゃないかなと思います。

[かーつん](#ﾟДﾟ) < 「何キレイに〆てんだよ」
[姜子牙](*’▽’) < 「たまにはいいじゃないー」
[SELLCA](￣ o￣) < 「でも結構ダークですよね」
[姜子牙](；’-') < 「う、痛いところを・・・。」

ダークではないですよ。

姜子牙 MySQL, Tips, その他

ゴールデンウイークはどこが黄金なのか一度聞いてみたいです。姜子牙です。
休めるだけマシな方だと思ってます。

さて、サーバパフォーマンスチューニングApache編第二回となります。

今回は
2､待機プロセス数の変更について
です。

さて、今回の待機プロセス数の変更は以下より分身になぞらえて進めていきたいと思います。

待機プロセスとはなんだろう？と言うと、Apacheは実行ファイル自体は一つなのですが
実際に動き始めると、一人が親玉になって、分身を始めるのです。
その分身一人一人がアクセスしに来た人に対応して、データを返す処理をします。
(スレッドを使用すると一人が複数人の対応をしたりするのですが、ややこしくなるので割愛します）
ここで、アクセスに来るのを待ちつつ何もしていない分身を待機プロセスと呼びます。

まず仮に分身の数を極端に減らすとどうなるかと言うと、一度にたくさんのアクセスがあった場合に、Apacheはその段階で分身を始めます。でも分身には時間がかかるのです。アクセスしにきたユーザは、分身が完了して対応を開始してくれるまで「サーバからの応答を待っています」の状態で待たされることになります。つまり、アクセス数の増加に対応するためには(特に急激な増加は）、分身は常にたくさん居た方がいいわけです。

では逆に分身が多いとどうなるかと言うと、分身を維持するためのメモリが必要になります。もしサーバが持っているメモリ量を超えるほどApacheが分身を抱えてしまうと、SWAPが走り始めサーバ全体の処理が重くなります。もちろんアクセスしに来たユーザは遅いサーバの応答に待たされることになります。
メモリはApacheだけの物ではなく、その他のソフトも使用するため、Apacheだけを考えて分身の数を決めることはできません。

これらを踏まえて、実際のhttpd.confで設定する値を見ていきます。(今回はprefork.MPMの値に絞ります）

○StartServer
サーバ起動時の分身数。すぐに変更されるため、適当で良い。

○MinSpareServer
最少待機分身数。Apacheは常にこの数以上は待機している分身がいるように分身数を調整する。

○MaxSpareServer
最大待機分身数。Apacheは常にこの数以下の待機している分身になるように分身数を調整する。

○ServerLimit
最大稼働分身数。ユーザ対応をしている分身はこの数が上限になる。

※ServerLimit+MaxSpareServerが最大分身数になる。

○MaxRequestPerChild
分身一人がユーザ対応する件数。0だと無制限。ここで設定した回数のユーザ対応をするとその分身は消える。
（メモリリーク、徐々に使用可能メモリが減っていく場合、この周期を短くして対応する）

これらの値を調整しつつ、Microsoft Web Stress Toolを使用して、100人同時アクセスなどを再現し、
topコマンド等でサーバの状態を図り、再調整という流れでチューニングを行いました。

また、待機プロセス数の変更以外にDeflateモジュールを使用してコンテンツの圧縮転送も実施しています。(項目増えてるやん、という突っ込みはスルーの方向で）
プログラム側の変更を行わず、Apache側の変更のみでMINEタイプやUser-Agentを判定してコンテンツを圧縮して転送することができます。

Jpeg等の圧縮済み画像ファイルはDeflateモジュールを使用しても圧縮効果が薄いため今回Deflateの対象としているのは text/html text/planeのみとしています。
PHPとかどうなるんだろう？と思うかもしれないですが、サーバ側でPHPの処理が完了し、HTMLとして出力されたデータをこのモジュールが圧縮をかけるので、上記の指定でOKです。

ただ、圧縮処理なので回線への負荷は下げられるものの、CPU使用率は増えてしまいます。(回線の転送量は、圧縮レベル9で約1/3の転送量に下がった試験結果が出ています）

まだ、Apacheのチューニング方法はあるかと思いますが、今回はこのくらいで・・・。次回はMySQLの方に触れたいと思います。

[べきこ](´∀｀) < 「せんせー、テストケースの内容がわかりません」
[姜子牙](#ﾟДﾟ) < 「ググレカス」
[べきこ](´∀｀) < 「日本語としてわかんないですけどー」
[姜子牙](；’-') < 「え・・・ちょっとまってね・・・」

はい、言ってみたいです。

姜子牙 未分類