社内にサーバーが設置されているサーバールームがあったり、データセンターを借りていてサーバーをオンプレミスで設置している企業もまだまだ少なくないでしょう。
しかし、近年ではAWSやAzure、gcpといったクラウドサービスの利用が増えており、オンプレミスからクラウドへ移行する企業も増加しています。
リプレースを検討するタイミングとしては、オンプレミスで設置しているサーバーのハードウェア保守の期間切れの時期に検討する企業が多いでしょう。
では、サーバーのリプレイスとは具体的にはどのようなことなのでしょうか、なぜまだ動くのに入れ替えることが必要なのか疑問がありますよね、この記事で詳しく解説します。
IT業務のお悩みやお困りごと、コスト削減をお考えなら、解決手段があるはず！まずはITボランチへご相談（無料）ください。お問い合わせはこちらから
Contents
サーバリプレースとは？なぜ必要なの？
サーバリプレースとは、今まで利用していたシステム環境を刷新し、新たな環境で動作させることです。
ここでは、サーバリプレースの発生するタイミングや、リプレースが必要な理由について確認していきたいと思います。
ハードウェアの保守切れに伴うリプレース
サーバの購入当初は、故障したとしても部品の調達には不自由することはないでしょう。当然、故障があった場合は契約している保守の範囲で部品交換を行なってもらえます。
しかし、発売から年数が経ち新機種が発売されるようになると、旧機種の部品の調達が徐々に難しくなってきます。
部品の調達ができないと、故障に伴う部品交換ができなくなります。
ハードウェアメーカも過去に発売した機種すべての部品をストックしておくことはできないため、やがて旧機種については部品の調達を保証しなくなる時が来ます。
部品の調達ができないということは、部品故障が起きてもそのハードウェアは修理することができません。
場合によっては、そのハードウェア上で動作するシステムはもう使えなくなってしまいます。
故障が原因で、ある日突然業務システムが使えなくなってしまったら、企業運営への影響は計り知れません。
そのような事態を防ぐために、保守切れを迎える前にリプレースが必要になるのです。
保守切れまでの期間はメーカや機種によって異なりますが、大体システム導入から５年を目安にリプレース計画を立てておくのが良いでしょう。
製品のライフサイクル（EOL）についての詳細は「EOLとは？EOSとの違いは？放置するとリスクが増加する」の記事で紹介しています。
ソフトウェアの保守切れに伴うリプレース
ソフトウェアの場合は、OSやミドルウェア(アプリケーションサーバやデータベース製品など)のサポート期間切れが挙げられます。
ソフトウェアの更新のように、バージョンアップで対応できる場合はリプレースの必要はありませんが、サポートが終了する場合はそうはいきません。
ソフトウェアのサポートが終了するということは、例えば、新しくバグやセキュリティホールが発見された場合でも、パッチプログラムの提供が行われなくなります。
重要なシステムであればあるほど、バグやセキュリティホールを放置したまま利用することはシステムリスクが高まります。
いよいよ「Windows Server 2012/2012 R2」が、2023年10月にサポート期限が終了します。間近に迫っていることもあり多くの企業がアップデートを実施している状況です。
ハードウェアの保守切れとは違い、部品故障によりサーバ自体が動かなくなるということはありませんが、セキュリティホールを放置したことにより情報流失やシステムダウンが発生する事態になれば、企業経営への大きなダメージになります。
そのため、ソフトウェアについても、保守切れを迎える前にリプレースが必要になります。
Windows Server 2012/2012 R2のサポート期限終了についての詳細は「Windows Server 2012/2012 R2のサポート期限が終了する？企業が取るべき対応とは」の記事で紹介しています。
参考：マイクロソフト「ライフサイクル Windows Server 2012 R2」
サーバのスペック不足
ハードウェア・ソフトウェア共に保守切れの期限は来ていなくても、サーバのスペック不足が問題となりリプレースする場合もあります。
導入した当時は良くとも、利用を続けるにつれて想定したスペックでは性能が不足し、システムが十分に動作しなくなるというケースです。
部品やリソースの追加ができれば良いのですが、例えば、追加部品が入手できない場合や、CPUの追加によりライセンス費用や保守費用が大幅に増加するので手が出せないなどの理由から、リプレースを検討せざるを得なくなります。
スペック不足により性能が低下する程度であれば、しばらく我慢して使い続けることも考えられますが、突然のシステムダウンが頻発する等、業務への影響が大きくなる前に対処が必要になってきます。
サーバリプレースの種類
システム基盤ごとサーバリプレースを行うケースには、いくつかの種類が存在します。
ここでは、サーバリプレースにはどんな種類があるのかを確認していきましょう。
単純リプレース
単純リプレースとは、ハードウェアやミドルウェアなどのシステム基盤を新しくしますが、そこで動作するアプリケーションプログラムの仕様変更は行わず、単純に保守切れ対応を行うことを指します。
サーバ機器やミドルウェアは新しいバージョンになりますが、製品自体は以前と同じものを使う形式です。
車や携帯電話で言えば、今までと同じ種類の後継機種に乗り換えるイメージです。
システム基盤について大きな変更がないため、多くの場合アプリケーションプログラムについても修正の必要がありません。そのため、システム全体で見た場合、大きな仕様の変更はないことになります。
業務システムの利用者や、システム運用者からすれば使用感が変わらないことがメリットである反面、
せっかく費用をかけてサーバリプレースを行っているのにシステムが変わり映えしないというデメリットもあります。
クラウドサービス(IaaS/PaaS)を利用したリプレース
単純リプレースが単に保守切れ対応のみを目的としているのに対し、システム基盤を今までとは異なる製品に変更するリプレースもあります。
特に近年では、クラウド上のシステム基盤に移行するケースが多くなっています。システム基盤が大きく変わるため、「リプレース 」ではなく「マイグレーション」と表現することもあります。
クラウドの場合は、ハードウェアへの投資が必要ないため、初期費用が大幅に削減できるのが強みです。
クラウドにてOS基盤を利用するサービスをIaaS、アプリケーションサーバやDBなどのミドルウェア基盤を利用するサービスをPaaSと呼びます。
クラウドサービスでは、IaaSやPaaS共に、OSやミドルウェアが何種類も用意されています。
クラウド基盤でオンプレミスで使用していたOSやミドルウェアと同種の製品を選択できれば、今まで使っていたアプリケーションプログラムを流用することもできます。
もしPaaSとして提供されているクラウドサービスに、目当ての製品がなかったとしても、IaaSにて仮想サーバを構築すれば、好きなミドルウェア製品をインストールすることができますので、特殊なシステムでない限り、従来のオンプレミスに近い環境を構築することが可能です。
アプリケーションの刷新も含めたリプレース
なお、基盤上で動作するアプリケーションも含めてリプレースを行う方法も存在します。
アプリケーションプログラムの改修も行うため、業務システムの仕様や振る舞いも大きな変更があります。
モダナイゼーションとして、元々動作していたアプリケーションプログラムをリビルドやリライトなどの手法で改修する場合もありますし、近年ではクラウドのSaaSを利用してまったく新しいサービスに移行してしまうのもトレンドです。
いずれにせよ、アプリケーションの動作が大幅に変わりますので、システム運用者だけではなく、システムの利用ユーザへの影響も大きくなります。
リプレイスのみではなく、ユーザへのアナウンスやトレーニングなども含めて検討を進めていく必要があるでしょう。
サーバリプレースを行う際の注意点
ハードウェア調達のリードタイムを考慮する
オンプレミス環境でサーバリプレースを行う場合、ハードウェアの調達が必要になってきます。
多くの場合、ハードウェアの調達には時間がかかります。メーカによっては、海外からサーバ機器を輸送する場合もありますし、部品を取り寄せて国内で組み立てを行う場合もあります。
戦争や経済などの世界情勢が、半導体の不足などIT分野に直接影響してくるケースも多くなっています。
世界情勢まで予測することは難しいのですが、海外から機器や部品を調達することが想定される場合には、その分余裕を持ったスケジュールを組んでおくことが重要です。
また、クラウドに移行する場合、サーバ機器の調達は不要ですが、ネットワーク機器は新たに調達する必要があるケースもあります。
VPNを含むインターネット接続ではなく、専用線接続の場合は機器調達だけではなく、ネットワーク敷設にも時間がかかることは考慮しておくべきでしょう。
事前にPoCを実施する
単純リプレースであれば、移行リスクはそれほど大きくありませんが、クラウド基盤に移行する場合など、システム基盤が大きく変更される場合は、想定外の事態に遭遇する可能性が高くなります。
リスクを軽減するためには、いきなりプロジェクトを開始するのではなく、事前にPoC(Proof Of Concept：概念実証)を行うことが大切です。
PoCとは、新しい手法の実現可能性をあらかじめ検証を行うことです。
システム基盤の変更だけと思っていても、想定外のプログラム改修が必要になることもあります。
例えば、DBの製品やバージョンが変わると、DB固有のライブラリが使えなくなり、SQLの改修が必要になることもあります。
PoCにより検証を行い、プロジェクトを進める上のリスクをあぶり出しておくのです。
それにより、事前にリスクを回避したり対応策を考えられますので、プロジェクトを円滑に進めることができるでしょう。
まとめ
ハードウェアの老朽化や、ハードウェアやOSの保守切れに伴いサーバリプレースを検討する企業が大半です。
保守切れが近づいてから慌てて検討を開始すると、時間的な制約から単純リプレース以外の選択肢がなくなったり、最悪の場合は保守切れの期限に間に合わない、といったことも起こります。
安定稼働している状態であっても、システムライフサイクルを見据えてリプレースを検討しておくことは重要です。
これを機会に、現在のサーバ環境を見直してみてはいかがでしょうか。
