BP Study 第16回：Linuxシステムの物理制約と(web)システム監視のポイント

勉強会

株式会社ビープラウド
株式会社ハートビーツ｜サーバ構築、クラウド、セキュリティに強いMSP CTO 馬場俊彰さん
お仕事

  • 運用開始後にプロジェクトに参画することも多い
    • 「今更どうしようもない」ということも多い
    • 設計段階から考慮しておいてくれる方がいい

Linuxシステムの物理制約

LAMPシステムを例にしたおはなし
web+dbの1Uサーバ2台のスモールスタート

制約ポイントその1
  • ネットワークI/Oするところ
    • データの出入り口
    • コストかけないと根本的に解消出来ない
  • ネットワーク帯域
    • 回線がいっぱいいっぱいになると同時接続数が異常に増える
    • 対策→中身を減らす
      • 画像データの容量削減
      • データ圧縮
      • キャッシュ活用
      • 線を太くする・増やす
      • CDN(高い)
  • 同時接続数
    • 1台でどれくらい同時接続を受けられるか？
      • netstatのstateを見てTIME_WAITが1万を越えると実用上厳しくなってくる
    • 増えたらどうするか？→チューニングしる
      • カーネルパラメータを変更(日本語資料少ない)
        • サーバの種類によって事前にというのは難しい。運用開始後にチューニングする。
        • 今はリコンパイルする必要はない
        • 変更による副作用はあるにはあるが、メリット・デメリットを比較して判断。
      • Apacheやプログラムのチューニング(日本語資料多い)
      • あまり同時接続数が増えるとネットワーク機器がボトルネックになる
      • いい製品は高い
      • linuxでなんとかする
制約ポイントその2 Apache
  • PHPだとpreforkで実行することになる
  • 同時起動プロセス数を増やす
    • システムリソース制限を回避
      • ユーザ(Apache起動ユーザ)あたりのファイルディスクリプタを増やす
      • ユーザあたりの起動プロセス数を増やす
    • メモリを上手く使う
    • プロセスあたりのメモリ使用量を減らす
    • Apacheのロードモジュールの数を減らす
    • フレームワークを使うとロードするクラスの数が多くなりがち→どうすれば良いでしょうか？
  • CPUを上手く使う
    • コンパイルキャッシュを使う
    • 無駄なディスクIOをしない
      • 重いよ！！
      • アクセス数が多いサイトでは画像のアクセスログをとらないとか
    • LoadAverage=CPU(コア)数だったら過負荷ということはないのです。(実行待ちキューの登録数なので)
  • ディスクを上手く使う
    • 1ファイルのサイズに制限がある(32bit linuxで2GB)
    • ログはローテーションする
    • 1ディレクトリのファイル数は程々に
      • 多すぎるとオペレーション上辛い
制約ポイントその3 MySQL

(前提：参照多め、更新少なめ)

  • メモリもディスクも上手く使う
    • 参照が多いテーブルはできるだけオンメモリで
    • 更新が多いのであれば、対象テーブルの物理データファイルサイズは小さく保つ
      • ファイルの中身がスカスカになったらOPTIMIZE TABLEで縮小する。
    • MyISAMだと1テーブル=1ファイルなので32bit linuxだとファイルサイズの制限の問題が出てくる
    • 64bit linuxを使うデメリットはそんなにない(ただしテストも本番も両方64bitにしておかないとよろしくない)
  • CPUも上手く使う
    • サブクエリやJOINの時に一時テーブルがメモリに収まらないとディスクを利用してしまう
    • 単位時間あたり処理数を増やすためコネクトを高速か
      • localhosthenoTCP接続は、UNIXソケットより7.5%速い
      • 別サーバへのTCP接続はlocalhostへのTCP接続より11%遅い

→参照用スレーブDBをAPサーバと同じマシンに乗せるとか

(web)システム監視のポイント

  • インターネット越しの監視は結果のぶれが大きい
    • リトライは織り込み済み
  • 監視ポイントの最適化
    • 多すぎるのは駄目
一般ユーザ視点でのチェック
  • サイト表示、メール等の各種サービスの応答速度
    • 3秒以内：OK
    • 3〜5秒：Warning
    • 5秒以上：Critical
  • 文字列検知とか
  • リソース監視もやる
  • 遅くなりそうな状況を検知
  • toolとしてはNagios、Hinemosとかお勧め
ビジネス視点でのチェック
  • システムの稼働状況を実績データを元に判定
    • ログインユーザ数、売り上げ、メール配信数etc
    • システム個別の判定基準になるので、チェックプラグインは自作
      • 難しいよ！
障害を素早く検知して対応
  • 24時間誰か居る→対応可能
  • 障害の予兆を検知して大火事を予防(なってからじゃ遅い)
  • 継続は力なり！！
質疑応答とか座談会的な
  • うん億件の集計で死滅します
    • 集計用のスレーブを作ると良いのではないか？
  • 起動しないとか
  • SELinux使ってるとトラブル多い
    • 開発環境でオフ、本番でオンというのは絶対にやっちゃ駄目！
  • Apacheのモジュールでlogをメモリに溜めて一気にディスクに書き込むのとかある
  • 検証情報をIPAがまとめてる
  • 凄く大量のテキストを扱うテーブルを設計する上で気をつけること
    • 検索が必要であれば、分かち書きとかも別に持つ
    • あもりにも大きくなりすぎたら画像ファイルとかと一緒でファイルの在処をテーブルに突っ込む
      • インデックスは別に持つ
      • 今度はファイルのサイズじゃなくて数が問題になって来る