Linuxシステムの物理制約と(web)システム監視のポイント

1. Linux システムの物理制約と (web) システム監視のポイント 馬場 俊彰 toshiaki@netmark.jp 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 サーバ MySQL PHP + フレームワークなどなど インターネット

6. 制約ポイントその１ ポイント：ネットワーク I/O するところ ネットワーク帯域 同時接続数 グローバル IP アドレス web サーバ Apache db サーバ MySQL PHP + フレームワークなどなど インターネット このあたり

7. 制約ポイントその１ ネットワーク I/O するところ データの出入り口 ここが詰まるとどうしようもない コストをかけないでも段階的な解消はある程度できる (= 時間稼ぎはできる ) けど、根本解決は厳しいことが多いです 「物理的に無理です」

8. 制約ポイントその１ ネットワーク帯域 (1/2)‏ Ｑ．インターネット回線はどのくらい使えるのかな？ Ａ．回線業者によって違います 100Mbps 回線なら、だいたい 100Mbps まで出ます ※あまり帯域使いすぎると別料金になることがあるのでご注意ください Ｑ．回線がいっぱいいっぱいになるとどうなるの？ Ａ．同時接続数が異常に増えます よくあるパターン： 帯域圧迫->コネクションあたりの転送速度低下->同時接続数増加->。。。

9. 制約ポイントその１ ネットワーク帯域 (2/2)‏ Ｑ．回線がいっぱいいっぱいになったらどうしよう？ Ａ．中身を減らしましょう 画像データの容量削減 データ圧縮 (mod_deflate など )‏ キャッシュを活用 ( 特に動的サイト )‏ 線を太くする もう 1 回線引いてみる いっそ外に出す⇒ CDN( 値は張ります )‏

10. 制約ポイントその１ 同時接続数 (1/3)‏ Ｑ． 1 台でどのくらい同時に接続を受け付けられますか？ Ａ． netstat コマンドの state を見て、 TIME_WAIT が 10000 個に差し掛かると実用上厳しくなってきます (20 ～ 30 万円クラスの IA サーバの事例 )‏ このくらいの数になると、 netstat コマンドの出力が終わりません。。

11. 制約ポイントその１ 同時接続数 (2/3)‏ Ｑ．同時接続が増えてきたらどうしよう？ Ａ．チューニングしましょう Linux のカーネルパラメーターを変更して、ネットワークソケットの再利用をはやめます このあたりの話になると途端に日本語の資料が少なくなります Apache やプログラムのチューニングも並行してやりましょう 日本語の資料も多いのでがんばりましょう

12. 制約ポイントその１ 同時接続数 (3/3)‏ Ｑ．同時接続が増えてきたらどうしよう？ ( つづき )‏ あまり同時接続数が増えると、ファイアウォール・ロードバランサーなどのネットワーク機器がボトルネックになります いい製品は初期費用がとてもとても高いです Linux でなんとかする方法もあります ファイアウォール⇒ iptables ロードバランサー⇒ LVS(L4)‏ ※ 製品を買ったほうが幸せになることもありますよ

13. 制約ポイントその１ グローバル IP アドレス Ｑ．やっぱり IPv ６ですか？ Ａ．そういう話ではありません グローバル IP アドレスの割り当てを後から増やすのは大変なんです！ ( ネットワーク割り当てなので )‏ 無停止・設定変更なしだと大変。無理な場合も多々あり 停止・設定変更アリであれば大丈夫 1 本の上流回線あたりの IP アドレス数は限りがあるので、みんなが拡縮->移転を繰り返すと。。。。 ⇒ラック内・ラック間の LAN ケーブルがスパゲッテイになります。テプラやファイバタグを駆使して回避してます ⇒時代は仮想化でしょうか

14. 制約ポイントその２ ポイント： Apache 同時起動プロセスを増やす ハードウェアリソースをうまく使う メモリ、 CPU 、ディスク web サーバ Apache db サーバ MySQL PHP + フレームワークなどなど インターネット このあたり

15. 制約ポイントその２ Apache PHP だと prefork( プロセスモデル ) で実行することに 世間に事例も情報も豊富です そしてなぜか事欠かない失敗事例

16. 制約ポイントその２ 同時起動プロセスを増やす Ｑ．どれだけ同時に起動できますか？ Ａ．がんばって増やしてみましょう システムリソース制限を回避 ユーザあたりのファイルディスクリプタの割り当てを増やす ファイルオープン、 Socket オープン、標準入力、標準出力、標準エラー出力などで個別に消費します Too many open files を回避します ユーザあたりの起動プロセス数を増やす 最近は無制限になってたりしますが念のため 設定を変えるだけです

17. 制約ポイントその２ ハードウェアリソースをうまく使う (1/3)‏ メモリをうまく使う 安くなったとはいえ、いっぱい載せると高いです PHP である以上、 prefork での起動になるので個々のプロセスのサイズが並列数に直結します プロセスあたりのメモリ使用量を減らすのがポイント Apache のロードモジュールの数を減らしてある程度対応できます フレームワークを使ってたりすると、ロードするクラスの数が多くなりがちみたいですね ⇒個々のプロセスサイズが大きくなりがち ⇒なんかうまい方法はないもんでしょうか？

18. 制約ポイントその２ ハードウェアリソースをうまく使う (2/3)‏ CPU をうまく使う コンパイルキャッシュ (APC などのアクセラレータ ) を使う OpenX( オープンソースの広告配信ソフト ) では絶大な効果がありました ロードアベレージ 60->0.6 無駄なディスク I/O をしない ご存じの方も多いと思いますが、ディスク I/O って重いんです ディスク I/O が重いので、アクセスが多いサイトでは画像のアクセスログはとらないようにします ちなみに、 LoadAverage=CPU( コア ) 数だったら過負荷ではないです 実行待ちキューの登録数なので、 LoadAverage30 でも余裕で動いている時もあります ( ヤバイ時もあります )‏

19. 制約ポイントその２ ハードウェアリソースをうまく使う (3/3)‏ ディスクをうまく使う 1 ファイルのサイズには制限があります (32bit Linux ではだいたい 2GB)‏ ログはローテーションしてくださいね daily + size のローテーションが嬉しいです 1 ディレクトリのファイル数はほどほどにしてくださいね オペレーション上、 3 桁くらいまでにしてもらえると嬉しいです

20. 制約ポイントその３ ポイント： MySQL ハードウェアリソースをうまく使う メモリ、 CPU 、ディスク web サーバ Apache db サーバ MySQL PHP + フレームワークなどなど インターネット このあたり

21. 制約ポイントその３ MySQL SQL の最適化をしてください！ インフラチューニングでは限界があります 基本的にスケールアウトする方向になります、スケールアウトできる設計にしておいてくださいね 更新トランザクションと参照トランザクションの分離、データソースも分離 遅延レプリケーションを考慮に入れた画面遷移、コーディング

22. 制約ポイントその３ も ハードウェアリソースをうまく使う (1/2)‏ メモリもディスクもうまく使う 参照が多いテーブルはできるだけオンメモリで動作するようにしましょう 32bit Linux ではプロセスサイズの上限が小さいので、足りなくなりそうであれば 64bit Linux を使いましょう 更新が多いのであれば、対象テーブルの物理データファイルサイズは小さく保つのがポイントです MySQL は追記型ではないですが、データファイルが大きいと中身スカスカでも insert が重くなります 中身がスカスカになったら OPTIMIZE TABLE で縮小できます 1 テーブル =1 ファイルな MyISAM だと、 32bit Linux では 1 ファイルあたりのファイルサイズが ( 以下略

23. 制約ポイントその３ も ハードウェアリソースをうまく使う (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 サーバ MySQL PHP + フレームワークなどなど インターネット

25. システムを監視する ちょっとしたコツ インターネット越しの監視は、結果のブレが大きいです 何度かのリトライは折り込み済み。 2 回リトライが一般的？ 監視ポイントの最適化が、システム安定化のカギです

26. システムを監視する 一般ユーザ視点でのチェック サイト表示、メールなどの各種サービスの応答速度を監視します 例えば、サイトのトップページの応答が 3 秒以内 ⇒ OK 3 ～ 5 秒 ⇒ Warning 5 秒～ ⇒ Critical 文字列検知なんかもやってます 他にも、リソース監視もやってます LoadAverage 、総プロセス数、ログインユーザ数、ゾンビプロセス数、プロセス有無・・・

27. システムを監視する ビジネス視点でのチェック システムの稼働状況を、実績データを元に判定します 現在のログインユーザ数、直近の売上、メール配信数などを元に、システムの稼働状況を判定します システム個別の判定基準になるので、チェックプラグインは全て自作です

28. システムを監視する 障害を素早く検知 ( して、対応 )‏ ハートビーツの事務所では、 24 時間誰かが働いています アラートが発生したら「人が」すぐに対応します 「最近リトライが多いな～」など、障害の予兆を素早く察知することで、大火事を予防します 「継続は力なり」ということで、何よりも続けることが大事です

29. ご静聴ありがとうございました 馬場 俊彰 toshiaki@netmark.jp http://netmark.jp from heartbeats (http://heartbeats.jp)‏