日次のアクセスが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で、デフォルト設定 + 稚拙なレプリケーション。
• データベースのインデックスがされてなかった。
• １時間に１回、それと夜間に急激に負荷があがって、サイトがレスポンスができない状況であった。
  • PostgreSQLの自動バキューム機能が誤ってセットされていて、毎時活躍してしまっていた。
  • 夜間の原因は、Linuxカーネルのエレベータソートが3parに影響していた。キューのスケジューラをnoopにして解決。
• リクエストの都度、ディスクに大量のログがコピーされていた。デバッグ用だったため無効にすることで改善。
• 運悪く高価なハードウェアに故障が頻発。

2014 Topアクセスランキング