リニューアル後の運用から得られた情報によるシステム改善

リニューアル後の運用から得られた情報によるシステム改善

ここでは、システムリニューアル後に発生した問題と、それに対する対応について、紹介してみる。

DBサーバーへの接続障害

一部サービスにおいて、ときおり、WebサーバーからDBサーバーへの接続障害を検知することがあった。WebサーバーからDBサーバーへの接続は、すべてロードバランサーを経由するようにしていたため、調査はロードバランサーとDBサーバーの双方で実施した（図2）。

図2：DBサーバーへの接続障害調査：システム構成図

ロードバランサーのログを調査した結果、接続障害を検知したタイミングで、一部のDBサーバーがロードバランサーのヘルスチェックでエラーとなり、ロードバランサーから切り放されていたことが判明した。ロードバランサーのヘルスチェックがエラーとなったときのDBサーバーのリソース状況とデータベースへの処理内容を調査すると、アプリケーション側で特定の処理が実行されたタイミングで、DBサーバーの負荷が上昇していることが判明した。

このとき、ロードバランサーのヘルスチェック設定変更が難しいことと、アプリケーション側の改修に時間がかかることから、障害を検知しているサービスへのDBサーバーの割り当て数を増加させることで、DBサーバーの負荷を軽減することにした。ただし、DBサーバー全体の台数を増加させることはできないため、負荷の小さいサービスのDBインスタンスを統合することで、DBサーバーに空きをつくることにした。

DBインスタンスの統合作業

DBインスタンスの統合案は、次のことを考慮して作成した。

1. サービスごとのDBサーバーへの接続数（ロードバランサーで情報収集）
2. クエリーの実行数（各データベースインスタンスで収集）
3. サービス間の依存関係（インスタンスを統合することでサービス 間に依存関係が発生するため）

このDBインスタンスの統合作業は、MySQLのレプリケーション機能を利用して、サービスへの影響をアプリケーション側でDBサーバーを切り替える時のみに抑えた。

このようなDBインスタンス統合によって、空いたDBサーバーを別サービスに追加した後、ロードバランサーでのヘルスチェックエラーや、WebサーバーからDBサーバーへの接続障害の件数が、大幅に減少したことを確認した。