過去5年間の運用情報を活かしたシステムリニューアルの事例
リニューアル前のシステムの問題点
それでは、リニューアル前のシステムには、どのような問題があったのだろうか。調査すると、次のような問題点があった。
- 特定サービス専用のサービス系サーバーと共有しているサービス系サーバーでの負荷不均衡
ピーク時の負荷を考慮して、特定サービスに専用サーバーを割り当ていたため、ピーク時以外は非常に負荷が低い（サーバーリソースが余っている）状態となっていた。一方、全サービス共有のサービス系サーバーでは、複数のサービスが稼働しているため、常に一定以上の負荷がかかっている状態であった。
- 複数サービスでのデータベースサーバー共有
複数サービスのデータベースが、同一DBサーバー上に配置されていたため、特定のサービスでの負荷上昇や障害によって、他のサービスに影響が及んでいた。
- 特定のサーバーへの負荷偏り
サービス導入時に処理分散を考慮していなかったため、各サーバー群のうち特定の1台にのみ、処理が集中する状態となっていた。
- パッケージ管理の煩雑化
各サーバーにインストールするソフトウェアは、パッケージシス テムによって管理していたが、専用サーバーにインストールされるソフトウェアはそのサービスに特化した設定でパッケージを作成していたため、同一ソフトウェアでも、共有サーバーと専用サーバーとで別パッケージとなっていた。
次期システムの構成を提案
次期システムでは、リニューアル前のシステムにおける問題点を解決するため、以下のような構成にすることを提案した。
- サービス系サーバーの共有
サービス系各サーバーは全サービスで共有し、サービスを稼働さ せるサーバーの増減を容易にする。これにより、各サーバーのミドルウェアなども統一され、パッケージ管理の負荷が減少する。
- 拡張性
サーバーの追加やサービス投入までの時間を短縮するため、ネットワークインストールおよび キックスタート※4を利用して、サーバーをネットワークに接続した後に起動させるだけで、OSとミドルウェアのインストールが完了するようにした。
- OSおよびミドルウェア
OSには、その時点での最新版であった「RedHat Enterprise Linux 5」を選択した。またミドルウェアには、その時点での安定版の最新のものを選択した。ミドルウェアの管理には、パッケージシステム（rpm）を利用し、全サーバーで同一のパッケージを使用することとした。なお、このパッケージはOS付属のも のではなく、各サービスの要求を満たすよう、独自に作成した（前出の表4-5を参照）。
※4 Red Hat Enterprise Linuxなどで、OSを自動インストールするための仕組み。
なお、システムリニューアルまでの時間が限られていたことから、アプリケーションに関しては、構成の大きな変更は行わないことになっていた。
提案したシステム構成に基づいたサーバー台数の算出
このように、提案したシステム構成に基づいて、必要なサーバー台数を算出してみた。
まず、既存のシステムにおいて、直近1年間の各サービスにおける負荷状況である、「アクセス数」「DBのコネクション数」「LBのセッション数」などを調査した。
この情報と、これまでの実績および顧客の事業計画などから、システムが提供するサービス数の変動を予測し、次期システムの末期（リニューアル時）における負荷状況を推測した。
一方、ハードウェアについては、リニューアル前のシステムで使用中のハードウェアと、次期システムで導入を予定しているハードウェアのCPU性能やディスクI/Oなどを比較して、サーバー1台あたりの性能比を算出した。このとき、リニューアル前後における、単位サーバーリソースあたりのアプリケーションのアクセス処理能力は、同一としておいた。
以上の情報をもとに、次期システムの末期(リニューアル時)の負荷状況をまかなうのに必要なサーバー台数を、機械的に算出した。
次に、各サービスに割り当てるサーバー台数を、
- 各サービスには必ず複数台（二重化を実現するため）のサーバーを割り当てる。
- 負荷が低いと予測される管理系サーバーの機能を同一サーバー群にまとめる。
- サービス系サーバーの割り当て優先度は、後々のサーバー追加の容易さを考慮して、「コンテンツ生成サーバー」⇒「DBサーバー」⇒「Webサーバー」とする。
といった条件を出し、これをもとに算出し、必要なサーバー台数を再計算した。
最後に、システムリニューアルの予算や新システムの設置場所による制約から、導入可能なサーバー台数と、算出された必要なサーバー台数を比較し、不足する分については、別サービスの余剰サーバーを流用するなどして、最終的な台数を確定した。
各サービスへのサーバー割り当て検討
各サービスへのサーバー割り当て台数の妥当性を検証するため、一部サーバーを先行して手配し、いくつかのサービスを新システム上でテスト稼働させた。
サーバー台数算出時に推測した負荷状況と、新システム上で稼働させた結果で得られた負荷状況を比較し、各サービスの負荷状況を再計算した後、各サービスへのサーバー割り当てを確定した。
