システム安定化が課題

最初に勢いでサービスを作ったものの、気がつけば全機能のチューニングやアルゴリズム見直しを行うこととなった。
現在、実現したい機能は沢山あるが、現状システムで発生するトラブル対応に追われ新機能にまで手が回らない。
毎日、なにかしら機能やサーバで問題が発生し対応に追われいる状態が続いている。

ここで今日までに発生した障害と対応内容を記録しておく

障害１

【内容】ページ送りのリンクURL不具合

【原因】テンプレート共有化しているが、ページ送り部分に機能別切り分け設定漏れ

障害２

【内容】検索が遅い

【原因】データ量増加に伴いSQL SELECTのレスポンスの低下

【対応】DBの対象フィールドにインデックス設定

障害３

【内容】最新twitterデータが取り込めない

【原因】データ量増加とインデックス設定により、データ登録処理が１分以上かかりレンタルサーバ上制限によりプロセスが強制終了されてしまった。

【対応】DBへのインサート処理を１レコードづつではなく1000レコードづつ処理するように変更し１分以内に処理が完了するようにした。MySQLのマルチブルINSERTを利用

【メモ】MySQLのLOAD DATAがデータ投入では最速と思うが、レンタルサーバで発行されているアカウントでは実行権限がなく断念。

障害４

【内容】最新twitterデータが取り込めない

【原因】データ取り込みバッチのDB接続・切断のプログラムに問題があり、切断しないで処理を終える場合があり、DBサーバへの接続数が最大数まで到達してしまってDBに接続できないでいた。

【対応】全バッチのDB処理チェックと、確実に切断するように修正

障害５

【内容】最新twitterデータが取り込めない

【原因】レンタルサーバにデータを物理ファイルでアップし、レンタルサーバ側で取り込み処理が実行されるのだが、レンタルサーバのディスク空き容量が0になり、データアップできず。プログラムのログファイルがサーバ容量の８割をしまていた。

【対応】ログ出力項目見直しによりログの量を減らした。

障害６

【内容】最新twitterデータが取り込めない

【原因】データ取り込みを行っているマシンのDBサイズが大きくなりディスク空き容量が0になり、データ追加できず。

【対応】全データ一旦削除。MySQL再インストールと、テーブルタイプをInnoDBからMyISAMに変更。トランザクションログを保存しない。

総括

反省

監視者の不在：システム状況を監視する仕組みや監視＆復旧プランがないことが、実際に障害がおきるまで発見が送れる状態になった
インフラの弱さ：レンタルサーバ（HDD容量１G）＆自宅ノートPC（HDD容量30G）というインフラ構成により、ディスク容量の問題がすぐ発生する。

対応

監視プラン／復旧プランの設定
インフラの強化
新機能追加より現機能の安定化