1
Linuxシステムの物理制約と(web)システム監視のポイント
馬場 俊彰[email protected] http://netmark.jp
from heartbeats (http://heartbeats.jp)
2
誰?
株式会社ハートビーツの CTOですたまに JPUGのお手伝いもしています
MSP(Management Service Provider)してます
24時間有人監視サービスフルマネージドサービス (ハウジング、ホスティング )
今:サーバエンジニア+ネットワークエンジニア前職: JavaでWebシステム開発前々職:サーバエンジニア+ネットワークエンジニア
OS(主に Linux(CentOS))、ネットワーク機器、ミドルウェア (Apacheとか RDBMSとか )の設定やチューニング、 DNS設定などなどをしてます
3
お仕事のご紹介
システムの運用開始後にプロジェクトに参画することが多いです
でも「いまさらどうしようもナイよ。。。」ということもしばし
…設計段階で考慮しておいてもらえれば…設計段階で声をかけてもらえれば
と思うこともしばし
“ ”監視したいけど予算がない ということもしばし
要件定義 設計 開発 テスト 移行 運用
4
今日のお題
Linuxシステムの物理制約
Linuxシステムを運用していく上で問題になるポイント・問題になったことがあるポイントをご紹介します
…設計段階で活かしてもらえれば
(web)システム監視のポイント
我々が、普段何を気にしているかをご紹介します
…監視設計に活かしてもらえれば
5
今日は LAMPシステムを例にします
こんな感じの、web+db 1Uサーバ 2台の構成を想定します
スモールスタート。って感じです
ほんとにスモールスタートだと 1台構成ですが、説明の都合上 2台にします
VPSもいいんですが、それなり性能でハードウェアを使い倒そうと思ったら現物のほうがお勧め
webサーバ
Apache
dbサーバ
MySQLPHP
+
フレームワークなどなど
インターネット
6
制約ポイントその1
ポイント:ネットワーク I/Oするところ
ネットワーク帯域
同時接続数
グローバル IPアドレス
webサーバ
Apache
dbサーバ
MySQLPHP
+
フレームワークなどなど
インターネット
このあたり
7
制約ポイントその1
ネットワーク I/Oするところ
データの出入り口
ここが詰まるとどうしようもない
コストをかけないでも段階的な解消はある程度できる(=時間稼ぎはできる )けど、根本解決は厳しいことが多いです
「物理的に無理です」
8
制約ポイントその1ネットワーク帯域 (1/2)
Q.インターネット回線はどのくらい使えるのかな?
A.回線業者によって違います
100Mbps回線なら、だいたい 100Mbpsまで出ます※あまり帯域使いすぎると別料金になることがあるのでご注意ください
Q.回線がいっぱいいっぱいになるとどうなるの?
A.同時接続数が異常に増えます
よくあるパターン:→ →帯域圧迫 コネクションあたりの転送速度低下 同時→接続数増加 。。。
9
制約ポイントその1ネットワーク帯域 (2/2)
Q.回線がいっぱいいっぱいになったらどうしよう?
A.中身を減らしましょう
画像データの容量削減
データ圧縮 (mod_deflateなど )
キャッシュを活用 (特に動的サイト )
線を太くする
もう 1回線引いてみる
⇒いっそ外に出す CDN(値は張ります )
10
制約ポイントその1同時接続数 (1/3)
Q. 1台でどのくらい同時に接続を受け付けられますか?
A. netstatコマンドの stateを見て、 TIME_WAITが10000個に差し掛かると実用上厳しくなってきます(20~ 30万円クラスの IAサーバの事例 )
このくらいの数になると、 netstatコマンドの出力が終わりません。。
11
制約ポイントその1同時接続数 (2/3)
Q.同時接続が増えてきたらどうしよう?
A.チューニングしましょう
Linuxのカーネルパラメーターを変更して、ネットワークソケットの再利用をはやめます
このあたりの話になると途端に日本語の資料が少なくなります
Apacheやプログラムのチューニングも並行してやりましょう
日本語の資料も多いのでがんばりましょう
12
制約ポイントその1同時接続数 (3/3)
Q.同時接続が増えてきたらどうしよう? (つづき )
あまり同時接続数が増えると、ファイアウォール・ロードバランサーなどのネットワーク機器がボトルネックになります
いい製品は初期費用がとてもとても高いです
Linuxでなんとかする方法もあります
⇒ファイアウォール iptables
⇒ロードバランサー LVS(L4)
※製品を買ったほうが幸せになることもありますよ
13
制約ポイントその1グローバル IPアドレス
Q.やっぱり IPv6ですか?A.そういう話ではありません
グローバル IPアドレスの割り当てを後から増やすのは大変なんです! (ネットワーク割り当てなので )
無停止・設定変更なしだと大変。無理な場合も多々あり
停止・設定変更アリであれば大丈夫
1本の上流回線あたりの IPアドレス数は限りがあるの→で、みんなが拡縮 移転を繰り返すと。。。。
⇒ラック内・ラック間の LANケーブルがスパゲッテイになります。テプラやファイバタグを駆使して回避してます⇒時代は仮想化でしょうか
14
制約ポイントその2
ポイント: Apache
同時起動プロセスを増やす
ハードウェアリソースをうまく使う
メモリ、 CPU、ディスク
webサーバ
Apache
dbサーバ
MySQLPHP
+
フレームワークなどなど
インターネット
このあたり
15
制約ポイントその2
Apache
PHPだと prefork(プロセスモデル )で実行することに
世間に事例も情報も豊富です
そしてなぜか事欠かない失敗事例
16
制約ポイントその2同時起動プロセスを増やす
Q.どれだけ同時に起動できますか?A.がんばって増やしてみましょう
システムリソース制限を回避
ユーザあたりのファイルディスクリプタの割り当てを増やす
ファイルオープン、 Socketオープン、標準入力、標準出力、標準エラー出力などで個別に消費します
Too many open files を回避します
ユーザあたりの起動プロセス数を増やす
最近は無制限になってたりしますが念のため
設定を変えるだけです
17
制約ポイントその2ハードウェアリソースをうまく使う (1/3)
メモリをうまく使う安くなったとはいえ、いっぱい載せると高いです
PHPである以上、 preforkでの起動になるので個々のプロセスのサイズが並列数に直結します
プロセスあたりのメモリ使用量を減らすのがポイント
Apacheのロードモジュールの数を減らしてある程度対応できます
フレームワークを使ってたりすると、ロードするクラスの数が多くなりがちみたいですね⇒個々のプロセスサイズが大きくなりがち
⇒なんかうまい方法はないもんでしょうか?
18
制約ポイントその2ハードウェアリソースをうまく使う (2/3)
CPUをうまく使う
コンパイルキャッシュ (APCなどのアクセラレータ )を使う
OpenX(オープンソースの広告配信ソフト )では絶大な効果がありました
ロードアベレージ 60→0.6
無駄なディスク I/Oをしない
ご存じの方も多いと思いますが、ディスク I/Oって重いんです
ディスク I/Oが重いので、アクセスが多いサイトでは画像のアクセスログはとらないようにします
ちなみに、 LoadAverage=CPU(コア )数だったら過負荷ではないです
実行待ちキューの登録数なので、 LoadAverage30でも余裕で動いている時もあります (ヤバイ時もあります )
19
制約ポイントその2ハードウェアリソースをうまく使う (3/3)
ディスクをうまく使う
1ファイルのサイズには制限があります(32bit Linuxではだいたい 2GB)
ログはローテーションしてくださいね
daily + sizeのローテーションが嬉しいです
1ディレクトリのファイル数はほどほどにしてくださいね
オペレーション上、 3桁くらいまでにしてもらえると嬉しいです
20
制約ポイントその3
ポイント:MySQL
ハードウェアリソースをうまく使う
メモリ、 CPU、ディスク
webサーバ
Apache
dbサーバ
MySQLPHP
+
フレームワークなどなど
インターネット
このあたり
21
制約ポイントその3
MySQL
SQLの最適化をしてください!インフラチューニングでは限界があります
基本的にスケールアウトする方向になります、スケールアウトできる設計にしておいてくださいね
更新トランザクションと参照トランザクションの分離、データソースも分離
遅延レプリケーションを考慮に入れた画面遷移、コーディング
22
制約ポイントその3 もハードウェアリソースをうまく使う (1/2)
メモリもディスクもうまく使う
参照が多いテーブルはできるだけオンメモリで動作するようにしましょう
32bit Linuxではプロセスサイズの上限が小さいので、足りなくなりそうであれば 64bit Linuxを使いましょう
更新が多いのであれば、対象テーブルの物理データファイルサイズは小さく保つのがポイントです
MySQLは追記型ではないですが、データファイルが大きいと中身スカスカでも insertが重くなります
中身がスカスカになったら OPTIMIZE TABLEで縮小できます
1テーブル=1ファイルなMyISAMだと、 32bit Linuxでは 1ファイルあたりのファイルサイズが (以下略
23
制約ポイントその3 もハードウェアリソースをうまく使う (2/2)
CPUもうまく使う
サブクエリや、 JOINの時に一時テーブルがメモリに収まらないサイズだとディスクを利用します。ディスク I/Oは重いので (以下略
一時テーブルのサイズは設定で変更できます
単位時間の処理数を増やすためにコネクトを高速化しましょう
localhostへの TCP接続は、 UNIXソケットより 7.5%遅い
別サーバへの TCP接続は、 localhostへの TCP接続より8~ 11%遅い (100Mイーサの場合 )
http://dev.mysql.com/doc/refman/5.1/ja/compile-and-link-options.html
⇒コネクションプールがあると素晴らしい
24
システムを監視する
一般ユーザ視点でのチェック
ビジネス視点でのチェック
障害を素早く検知 (して、対応 )←会社のお仕事
webサーバ
Apache
dbサーバ
MySQLPHP
+
フレームワークなどなど
インターネット
25
システムを監視する
ちょっとしたコツ
インターネット越しの監視は、結果のブレが大きいです
何度かのリトライは折り込み済み。2回リトライが一般的?
監視ポイントの最適化が、システム安定化のカギです
26
システムを監視する一般ユーザ視点でのチェック
サイト表示、メールなどの各種サービスの応答速度を監視します
例えば、サイトのトップページの応答が
3秒以内 ⇒OK
3~ 5秒 ⇒Warning
5秒~ ⇒ Critical
文字列検知なんかもやってます
他にも、リソース監視もやってます
LoadAverage、総プロセス数、ログインユーザ数、ゾンビプロセス数、プロセス有無・・・
27
システムを監視するビジネス視点でのチェック
システムの稼働状況を、実績データを元に判定します
現在のログインユーザ数、直近の売上、メール配信数などを元に、システムの稼働状況を判定します
システム個別の判定基準になるので、チェックプラグインは全て自作です
28
システムを監視する障害を素早く検知 (して、対応 )
ハートビーツの事務所では、 24時間誰かが働いています
アラートが発生したら「人が」すぐに対応します
「最近リトライが多いな~」など、障害の予兆を素早く察知することで、大火事を予防します
「継続は力なり」ということで、何よりも続けることが大事です
Top Related