これだけは押さえたい！オンプレリプレース前に検討・実施すべきこと

オンプレミスのシステムをリプレースするには考慮しなくてはならない点がいくつもあります。今回はリプレース時に検討・実施すべき内容について、様々な角度から考察してしていきます。

リプレースの時期

まずリプレースを考えなくてはならないタイミングはいつなのかについて考えていきましょう。一般的にオンプレミスの機器は、法定耐用年数に基づき5年に1度のリプレースを実施する企業が多い傾向にあります。

リプレースを行う主な要因としては以下のようなものがあります。

• ハードウェアの老朽化
• OSのアップデート未対応
• システム管理コストの削減・効率化
• 保守・サポート期限切れによるセキュリティリスク対応

長年インフラを運用していると、ハードウェアの老朽化による障害発生リスクが高くなり運用コストの増加にもつながります。また、保守サポートの期限切れやOSアップデートに未対応となるとセキュリティリスクが高くなり、不正侵入やウィルス感染でデータが漏洩してしまった場合には社会的信用を失いかねません。そういったリスクが顕在化して悪影響を及ぼす前に、リプレースを検討・実施する必要があります。

対象機器の使用状況を把握

リプレースをする時期が近づいてきたら、対象機器でどれだけのリソースを使用しているかを把握しなくてはなりません。オンプレミスのサーバといっても、1筐体にOSが1つだけの物もあれば、vmwareやhyper-vなどで仮想化していて1筐体で複数のguestOSが稼働している場合もあるので、利用している全てのリソースが対象になります。

主にcpu(core数)、memory、disk使用量、traffic量(※1)、OSの種類、ソフトウェア(※2) 等を算出します。

算出した使用量をもとにリプレース先のスペックを決めていかなければなりません。これはオンプレミスの場合でもクラウドの場合でも共通していて、ここでのサイジングによってイニシャル・ランニングでかかるコストが変わってきます。

※1 主にクラウド利用の場合に影響します。
※2 ライセンス方式によってライセンス料が変わる場合があります。

移行方式・方法の決定

リプレース対象の機器の使用状況を把握したあとは、移行方式や具体的な移行方法を検討していきます。

移行コストの計算

規模によりますが、移行にかかるコストも大きくなる場合があるので念頭に入れておかないといけません。要件定義・移行計画・環境定義・テスト仕様書などのドキュメント作成から移行実施までの人件費など、計算してみると思いのほか費用・時間ともにかかってくることがあります。

既存システムの移行要件

またコストの他に、既存システムの移行要件についても把握しておく必要があります。具体的には、以下のように考えなくてはならない点がいくつかあります。

• 停止する事ができないシステムなのか
• 短い時間の停止であれば許容できるのか
• バッチ処理の合間など決まった時間の間でしか移行できないのか
• 冗長化されたシステムなのか

上記の他にもありますが、既存システムの要件によって停止リスクや移行時の冗長化などを加味した上で、どういった移行方式を選択するかを考えていく必要があります。

移行方式の検討

移行方式は主に以下の３つが挙げられます。

• 長いメンテナンス時間取って一括で移行する方式
  →かかる時間が短く手間が少ないので移行コストが低いが、移行後の確認項目が多く不具合が発生した場合の切り戻しも難しいため、リスクが大きい。
• 短時間のメンテナンス時間で複数回に分けて移行する方式
  →かかる時間は比較的長く手間も多いので移行コストも高くなるが、リスクは比較的小さい。
• 冗長構成を増やし、平行稼働したのち移行する方式
  →かかる時間は長く手間もかなり多いので移行コストは高い。リスクは一番小さい。

この中で既存システム要件やコスト的に見合う方式を検討・選択し、実施に向けて準備を進めていきます。

移行方法の決定

移行方式を考えたあとは具体的な移行方法も考えなくてはいけません。移行方法は以下のような内容を検討します。

• バックアップからのリストア
• 移行ツールを利用してのカットオーバー
• レプリケーションを作成しての切り替え

リプレース先を決めるうえでは、guestOS単位で移行できるのかどうかや、移行の難易度なども考慮した方が良いと言えます。

オンプレミスなのかクラウドなのか

最後にオンプレミスorクラウドどちらにリプレースするかの検討が入ります。ここでは、オンプレミスとパブリッククラウドのメリット・デメリットをそれぞれ考えてみましょう。

オンプレミス

コスト	・高額な物理機器やソフトウェアライセンスを一括購入する必要がある ・電気代や保守費用などがかかる ・次回リプレースまでに予想したリソースが埋まらない or ビジネスがシュリンクした際は割高となる
調達	・発注してから数週間～数ヵ月かかる事がある ・設置/設定に関わる確認/調整や人的リソースの消費
カスタマイズ	技術力があれば自社の利用要件に合わせたカスタマイズが可能
既存システムとの連携	同一のネットワーク内に用意すればシステム連携や統合など自由度は高い
ネットワークセキュリティ	閉じた環境下でシステム運用できるので安全
運用保守	・機器の障害監視やリソース使用量のグラフ化など自由に作れる ・障害対応手順書や運用マニュアルを用意して監視体制を整備する必要がある
障害対応	自社で全て復旧対応する必要がある
オンプレ環境からの移行	既存システムをそのまま移行可能

クラウド

コスト	・物理機器購入の必要がないため初期費用は抑えられる ・従量課金のため利用した分だけ利用料がかかる ・スモールスタート可能だが計画的に利用しないとオンプレミスよりコストが高くなる
調達	・アカウント作成、支払い登録が済めばすぐに利用開始できる ・容易にVMの増減やスペック変更ができる
カスタマイズ	柔軟性はオンプレミスより低いがある程度は可能
既存システムとの連携	VPNなどの接続サービスがあれば可能だが連携不可の場合もある
ネットワークセキュリティ	オンプレミスには劣るがプライベートネットワークを利用できるので安全
運用保守	・リソース使用量のグラフなど用意されている事が多い ・新たに運用マニュアルを用意する必要がある
障害対応	クラウド事業者が復旧対応を行う
オンプレ環境からの移行	既存システムとの要件が一致しない場合に移行が難しい

完全コスト見合い、導入の容易さ、スケールの容易さ、障害対応の煩わしさ、固定資産を持つのか、自由度の高いシステム構築、ネットワークセキュリティの堅牢なシステム、リプレースサイクルからの解放など、オンプレミスなのかクラウドなのかは何を重要視するかによって変わってきます。

もちろんハイブリッドで構成を組むのも選択肢としてはありですが、ハイブリッドになるとどちらか一方よりもさらに複雑で膨大な調査や検討項目が発生し、なかなか次へ進まなくなってしまう事もあります。
コストメリットや運用方針、事業継続性などをトータル的に判断し決めていきましょう。

第3の選択肢

上記では「オンプレミス or クラウド」の２択でご紹介しましたが、弊社クララではオンプレミスの良さとクラウドの良さを兼ね備えた第3の選択肢として、「Clara Cloud」というサービスを提供しています。Clara CloudはHCI（ハイパーコンバージドインフラ）のリーディング製品であるNutanixを基盤にしたオンプレミスを、月額固定料金でご利用いただけるサービスです。

参考までに、Clara Cloudの特徴もこちらに載せておきますので、オンプレミス / クラウドとともにご検討ください。

Clara Cloudの特徴

コスト	・物理機器購入の必要がないため初期費用は抑えられる ・月額サブスクリプション＆定額課金のためコスト計画が立てやすい
調達	・利用できる状態で提供されるため、設置・設定に関わる確認・調整や人的リソースの消費が不要 ・容易にVMの増減やスペック変更ができる
カスタマイズ	オンプレミスと同等のカスタマイズが可能
既存システムとの連携	既存のネットワークと接続すればシステム連携や統合など自由度は高い
ネットワークセキュリティ	オンプレミスには劣るがプライベートネットワークを利用できるので安全
運用保守	・クララにて対応 ・機器の障害監視やリソース使用量のグラフ化など自由に作れる
障害対応	クララにて復旧対応を行う
オンプレ環境からの移行	オンプレミスと同様に既存システムの要件を維持したまま移行がしやすい

以下のページから実際にClara Cloudを利用して運用負荷を劇的に下げた事例や、既存のシステム要件をクリアしつつコスト削減につなげた事例などがダウンロード可能です。興味のある方はご覧ください。

>> Clara Cloud導入事例(1) | Nutanixの月額利用ならClara Cloud

まとめ

オンプレ/クラウド/Clara Cloud(第3の選択肢)それぞれにメリット/デメリットがあります。一概に、「どのプラットフォームを選択すべきか」と言うことはできません。大切なのは移行対象のシステム・アプリケーションの特性や自社リソースに応じて、どのプラットフォームが適切か判断することが大事です。

クララでは様々なプラットフォームの選択肢をご用意しておりますので、もし判断に迷った際はお気軽にご相談ください。