BP Study #16

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

制約ポイントその１

ポイント：ネットワーク I/Oするところ

ネットワーク帯域

同時接続数

グローバル IPアドレス

webサーバ

Apache

dbサーバ

MySQLPHP

+



このあたり

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


Ｑ．同時接続が増えてきたらどうしよう？

Ａ．チューニングしましょう

Linuxのカーネルパラメーターを変更して、ネットワークソケットの再利用をはやめます

このあたりの話になると途端に日本語の資料が少なくなります

Apacheやプログラムのチューニングも並行してやりましょう

日本語の資料も多いのでがんばりましょう

12


Ｑ．同時接続が増えてきたらどうしよう？ (つづき )

あまり同時接続数が増えると、ファイアウォール・ロードバランサーなどのネットワーク機器がボトルネックになります

いい製品は初期費用がとてもとても高いです

Linuxでなんとかする方法もあります

⇒ファイアウォール iptables

⇒ロードバランサー LVS(L4)

※製品を買ったほうが幸せになることもありますよ

13

制約ポイントその１グローバル IPアドレス

Ｑ．やっぱり IPv６ですか？Ａ．そういう話ではありません

グローバル IPアドレスの割り当てを後から増やすのは大変なんです！ (ネットワーク割り当てなので )

無停止・設定変更なしだと大変。無理な場合も多々あり

停止・設定変更アリであれば大丈夫

1本の上流回線あたりの IPアドレス数は限りがあるの→で、みんなが拡縮移転を繰り返すと。。。。

⇒ラック内・ラック間の LANケーブルがスパゲッテイになります。テプラやファイバタグを駆使して回避してます⇒時代は仮想化でしょうか

14

制約ポイントその２

ポイント： Apache

同時起動プロセスを増やす

ハードウェアリソースをうまく使う

メモリ、 CPU、ディスク

webサーバ

Apache

dbサーバ

MySQLPHP

+



このあたり

15

制約ポイントその２

Apache

PHPだと prefork(プロセスモデル )で実行することに

世間に事例も情報も豊富です

そしてなぜか事欠かない失敗事例

16

制約ポイントその２同時起動プロセスを増やす

Ｑ．どれだけ同時に起動できますか？Ａ．がんばって増やしてみましょう

システムリソース制限を回避

ユーザあたりのファイルディスクリプタの割り当てを増やす

ファイルオープン、 Socketオープン、標準入力、標準出力、標準エラー出力などで個別に消費します

Too　many　open　files　を回避します

ユーザあたりの起動プロセス数を増やす

最近は無制限になってたりしますが念のため

設定を変えるだけです

17

制約ポイントその２ハードウェアリソースをうまく使う (1/3)

メモリをうまく使う安くなったとはいえ、いっぱい載せると高いです

PHPである以上、 preforkでの起動になるので個々のプロセスのサイズが並列数に直結します

プロセスあたりのメモリ使用量を減らすのがポイント

Apacheのロードモジュールの数を減らしてある程度対応できます

フレームワークを使ってたりすると、ロードするクラスの数が多くなりがちみたいですね⇒個々のプロセスサイズが大きくなりがち

　 ⇒なんかうまい方法はないもんでしょうか？

18


CPUをうまく使う

コンパイルキャッシュ (APCなどのアクセラレータ )を使う

OpenX(オープンソースの広告配信ソフト )では絶大な効果がありました

ロードアベレージ 60→0.6

無駄なディスク I/Oをしない

ご存じの方も多いと思いますが、ディスク I/Oって重いんです

ディスク I/Oが重いので、アクセスが多いサイトでは画像のアクセスログはとらないようにします

ちなみに、 LoadAverage=CPU(コア )数だったら過負荷ではないです

実行待ちキューの登録数なので、 LoadAverage30でも余裕で動いている時もあります (ヤバイ時もあります )

19


ディスクをうまく使う

1ファイルのサイズには制限があります(32bit　Linuxではだいたい 2GB)

ログはローテーションしてくださいね

daily　+　sizeのローテーションが嬉しいです

1ディレクトリのファイル数はほどほどにしてくださいね

オペレーション上、 3桁くらいまでにしてもらえると嬉しいです

20

制約ポイントその３

ポイント：MySQL

ハードウェアリソースをうまく使う

メモリ、 CPU、ディスク

webサーバ

Apache

dbサーバ

MySQLPHP

+



このあたり

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サーバ

MySQLPHP

+



25

システムを監視する

ちょっとしたコツ

インターネット越しの監視は、結果のブレが大きいです

何度かのリトライは折り込み済み。2回リトライが一般的？

監視ポイントの最適化が、システム安定化のカギです

26

システムを監視する一般ユーザ視点でのチェック

サイト表示、メールなどの各種サービスの応答速度を監視します

例えば、サイトのトップページの応答が

3秒以内 ⇒OK

3～ 5秒 ⇒Warning

5秒～ ⇒ Critical

文字列検知なんかもやってます

他にも、リソース監視もやってます

LoadAverage、総プロセス数、ログインユーザ数、ゾンビプロセス数、プロセス有無・・・

27

システムを監視するビジネス視点でのチェック

システムの稼働状況を、実績データを元に判定します

現在のログインユーザ数、直近の売上、メール配信数などを元に、システムの稼働状況を判定します

システム個別の判定基準になるので、チェックプラグインは全て自作です

28

システムを監視する障害を素早く検知 (して、対応 )

ハートビーツの事務所では、 24時間誰かが働いています

アラートが発生したら「人が」すぐに対応します

「最近リトライが多いな～」など、障害の予兆を素早く察知することで、大火事を予防します

「継続は力なり」ということで、何よりも続けることが大事です

29

ご静聴ありがとうございました

　馬場俊彰[email protected] http://netmark.jp

from heartbeats (http://heartbeats.jp)

BP Study #16

Technology

Transcript of BP Study #16