過去5年間の運用情報を活かしたシステムリニューアルの事例
リニューアル後の運用から得られた情報によるシステム改善
ここでは、システムリニューアル後に発生した問題と、それに対する対応について、紹介してみる。
DBサーバーへの接続障害
一部サービスにおいて、ときおり、WebサーバーからDBサーバーへの接続障害を検知することがあった。WebサーバーからDBサーバーへの接続は、すべてロードバランサーを経由するようにしていたため、調査はロードバランサーとDBサーバーの双方で実施した（図2）。
ロードバランサーのログを調査した結果、接続障害を検知したタイミングで、一部のDBサーバーがロードバランサーのヘルスチェックでエラーとなり、ロードバランサーから切り放されていたことが判明した。ロードバランサーのヘルスチェックがエラーとなったときのDBサーバーのリソース状況とデータベースへの処理内容を調査すると、アプリケーション側で特定の処理が実行されたタイミングで、DBサーバーの負荷が上昇していることが判明した。
このとき、ロードバランサーのヘルスチェック設定変更が難しいことと、アプリケーション側の改修に時間がかかることから、障害を検知しているサービスへのDBサーバーの割り当て数を増加させることで、DBサーバーの負荷を軽減することにした。ただし、DBサーバー全体の台数を増加させることはできないため、負荷の小さいサービスのDBインスタンスを統合することで、DBサーバーに空きをつくることにした。
DBインスタンスの統合作業
DBインスタンスの統合案は、次のことを考慮して作成した。
- サービスごとのDBサーバーへの接続数（ロードバランサーで情報収集）
- クエリーの実行数（各データベースインスタンスで収集）
- サービス間の依存関係（インスタンスを統合することでサービス 間に依存関係が発生するため）
このDBインスタンスの統合作業は、MySQLのレプリケーション機能を利用して、サービスへの影響をアプリケーション側でDBサーバーを切り替える時のみに抑えた。
このようなDBインスタンス統合によって、空いたDBサーバーを別サービスに追加した後、ロードバランサーでのヘルスチェックエラーや、WebサーバーからDBサーバーへの接続障害の件数が、大幅に減少したことを確認した。
