立て直しのケーススタディ

http://jacquesmattheij.com/saving-a-project-and-a-company

1 comment | 1 point | by WazanovaNews 約2年前 edited


Jshiike 約2年前 edited | ▲upvoteする | link

日次のアクセスが1万人以下なのにサイトパフォーマンスが悪いシステムの立て直しを頼まれたJacques Mattheijjが、5週間で行った対応を紹介してくれているケーススタディです。

システム構成

  • Rails + PostgreSQL + Redis + AnguarJS + Symfony2
  • CentOS / HPブレード8台 (128G RAMと複数のVMware)、大型HPストレージアレー、Windowsマシン、Javaアプリ専用マシン

全体所見

  • アプリは概ね問題なし。システムレベルで非効率が散見され、開発の期限が近づいた時点で、雑な仕事がされたとみられる。
  • なぜか高額なハードウェアが先に選定されていて、それに合わせた調整手間が発生してしまっていた。

個別の対策

  • VMが130個。これを取除くことでシステムの複雑さが大幅に改善できた。
    • 取るに足らないシステム機能にもVMとバックアップVMが複数。バックアップは別のデータセンタにあると誤って認識されていただ、実は同じサーバで実行されていた。
    • 更に、分散システム用のMTBFの大型システムもセットアップされていたが、活用されていなかった。適切に使われると仮想化には強力なツールだが、効果なく無駄にCPUとメモリを消費していた。
    • プロセス全てにVMがアサインされると、ゲストOSが優先付けやスケジュールをできなくなる。リソースを最も静的に分割するかたちで、VMアーキテクチャ(つまりは自分自身に)に完全に頼っていることになる。VMを立ち上げたままにするオーバーヘッドは、物理的なサーバを稼働させるのと同じことになる。仮想化は、利用することのメリット(高い可用性、分離化、スナップショット)とコスト(金銭、パフォーマンス)をよく検討してから使うこと。
  • アプリケーションレベルのドキュメントが皆無。
  • 準備ができてないのにスケールアウトしている。
    • まずはスケールアップ。つまり、日次のアクセスが10万人以下であれば、サーバのチューニングもしくは高い性能のものに変えて対応できる。必要になれば、静的画像やDBを別サーバに移せばよい。
    • 64コア / 256G RAMのマシンでどうしても対応できなくなってから、スケールアウトさせる。
  • まったくキャッシュされてなかったので、オーバーヘッドが肥大化。
    • SymfonyのPHPコードのopcodeキャッシュ
    • 非ログインユーザ全てに共通なページのフルページキャッシュ
    • Varnish等を利用したフロントエンドキャッシュ
    • 頻繁に使うDBクエリやその結果のキャッシュ
  • セッションがディスクに保管されるかたちになっていた。
    • HP 3parは適切に使うと能力が高いが、くるくる回っている記録メディアの域を出ない使い方であった。セッションをRAMに移して、リクエストに要する時間を短縮。
    • 最終的にはRedisにマイグレートする。
  • VMのチューニングがされてなかった。
    • デフォルトの設定のまま、オープンファイルがmax。
    • インスタンスのためのデータベースVMは全て3G相当のRAMで、デフォルト設定 + 稚拙なレプリケーション。
  • データベースのインデックスがされてなかった。
  • 1時間に1回、それと夜間に急激に負荷があがって、サイトがレスポンスができない状況であった。
    • PostgreSQLの自動バキューム機能が誤ってセットされていて、毎時活躍してしまっていた。
    • 夜間の原因は、Linuxカーネルのエレベータソートが3parに影響していた。キューのスケジューラをnoopにして解決。
  • リクエストの都度、ディスクに大量のログがコピーされていた。デバッグ用だったため無効にすることで改善。
  • 運悪く高価なハードウェアに故障が頻発。

2014 Topアクセスランキング


Back