WEBサーバの移行のご依頼を頂く時に、ついつい見落としがちな事や注意する点を整理する為にまとめました。
アクセスと負荷を確認する
アクセスと負荷にあったスペックの見積もり、ボトルネックの特定を行います。何が原因なのかを診断します。それには、移行前のサーバにログインしサーバーのステータスを確認出来るとベスト。見積もり段階ではなかなかお客様のサーバへのログインの許可が下りませんが･･･＾＾；
負荷についてはプログラムの実装によるので、アクセス数だけでは正確に見積もる事が出来ません。有名なCMSであれば、アクセス数とスペック、構成だけで負荷が読めますが、オリジナルで開発されたWEBサービスではアクセス数だけのヒアリングでは負荷状況が読めないので困ります。アクセスが多くもプログラムの処理が軽ければ問題ないですが、どこかしらに問題があるからご相談を頂くわけで。
プログラムがメモリリークしていないか。
旧環境がApacheであるなら処理をApacheに合わせるのがベター。基本的にWEBはApacheで動く事が前提で作られていること、デザイナーさんでも.htaccessによって追加設定も簡単です。
しかし、Apache+mod系で構成した場合、プログラムミスにより、メモリリークしているプログラムが存在する場合死にます。そこで処理をFastCGI系に変更することで対処できます。一度納品してシステムを動かしてしまうと構成の変更は許可を取ったり、再検証などが必要になるので慎重に構成は考えなければいけない。
結局の所、Apacheの豊富なモジュールにシステムが依存しないのであれば、Nginx+FastCGI系で動かすのが運用上具合がいいのですが、殆どのお客さんは自分で管理出来なくなります。ただし、保守を弊社に委ねて貰えるならこれが１番。
プログラムにエラーがないか。
大量のエラーがある場合はシステムを組んだプログラマと相談の上対処して貰うようにしましょう。開発した担当プログラマがいない、手があかない場合は自分でちょこちょこ直す事も多いです。ただし、目先のエラーがなくせても、ロジックの検証が必要になるので、やはりプログラムを組んだ担当者に任せるのが無難。
数人程度のアクセスや負荷をかけるツールでは処理できていても、実際の運用によるアクセスでは複数ページの同時アクセスにより、検証では処理出来ていても特定の問題ページで処理落ちする事があります。万遍なく同時的に生き物のように巡るリアルなアクセスは再現する事が難しく、検証環境で動いても本番で動くかの判定は難しい。だから例外処理や初期化等をしっかり行い、エラーが発生しないコーディングを行う事が大切です。
旧環境とパスを合わせる。
絶対パスなど環境依存があるプログラム上の設定箇所があると、パスが異なると不具合が起こり動作しません。旧環境とパスを合わせる事が大切です。
また、相対パスと絶対パスを比較した場合、OS上でのディレクトリ検索処理のない絶対パスの方がパフォーマンス上とても有利です。何度もrequireする処理等では是非絶対パスを。
絶対パスの問題点
ディレクトリ構成が変わるとプログラムが動かなくなる。
そこで、環境依存のない絶対パスを実現したい場合には、dirname(__FILE__)関数等で補う事で解決します。
require( dirname( __FILE__ ) . ‘/wp-blog-header.php’ );
旧環境と設定やプログラムのバージョンを合わせる。
プログラムのバージョン、モジュール、php.iniなど各種設定を合わせる。
- short_open_tag
- mbstringの言語設定
- magic_quotes
- PEARの読み込み
など。php.iniだけでなく、.htaccessで追加設定されることも多いので注意しましょう。phpinfo()関数で設定表示させるのが確実です。
バグなどが修正されて軽くなっている最新のプログラムのバージョンで動くのがベストですが、機能の検証確認に工数がかかるので控えるのがベター。
キャッシュ
ハードのスペックを上げるだけではI/Oの問題等で処理量は頭打ちになります。結局のところ、どれだけキャッシュするか、ロードバランサ等を使い単純にサーバの数を増やす事で１秒間に処理出来るリクエスト数が上がります。ただし、ログインや管理画面関連などキャッシュしてはいけないところで、キャッシュしないように設定を行いましょう。
更新が多いサイトはキャッシュをあまり長くしない
デザイナーさんが更新出来なくなるので、キャッシュをWEB上で削除出来る仕組みや長くキャッシュしないように程々に設定。
トラブル防止
そもそも、顧客情報を扱うサイトはキャッシュしないのもベター。システムを見て細かくキャッシュの設定をチューニングしていきます。アクセスが少ない管理画面ではキャッシュ箇所やファイルを限定したり。
スロークエリの調査
数秒、中には１０秒以上かかるクエリが稀に潜んでいます。キーとなるカラムにインデックスをつけることで解決する場合が殆ど。解析の上クエリのチューニングを行います。他、ID単位での水平分割、どうしても厳しいならテーブル単位の垂直分割で対応。
トランザクション処理のチェック
DBでトランザクション処理を確認する。プログラムにロールバックやリトライの処理がない。トランザクションのあるシステムなのにテーブルエンジンがMyISAM(!)だったなんてことも。
検証の上、トランザクションサポートのあるテーブルエンジンに変更を行いプログラムの見直しを行いましょう。トランザクションのコミットはまとめて行うこと、特にDB分割している場合は不整合の原因になります。全てのDBに処理を行ってからコミットする。
また、トランザクション処理で失敗した場合はDB情報やクエリ、どこの部分で失敗したのかわかるようにログに必ず出すのが大事。増減処理は減らして増やすのがセオリー。
サービスダウンに備える
システムはダウンすることが前提として、冗長化や監視によるサービスの自動再起動を行う仕組みなどを備える。冗長化はコストがかかるのでお客さんと相談して設計。
チェックリストを作る
機能の動作・表示チェックした項目はエクセル等で管理すると、見落としが減るので必ず行います。
なんだか大変だなあと感じたら是非ご相談下さい。
WordPress以外のWEBサービスにも対応しております。
お気軽にご相談下さい。
