基幹システム（SAP）のバージョンアップで必要なこと（その２）

スコープの確認とは

スコープの確認とは具体的に何を決めればよいのかというと、何をどこまでバージョンアップさせるのかということを決めていきます。

ただし、闇雲に最新バージョンを選択すると検証時のテストケースが青天井に膨れ上がるので、まず最初にバージョンアップの目的を設定します。

例えば、バージョンアップの目的を「2025年12月末まで利用可能とする」と設定すると、2025年12月末までサポートされるバージョンを選定することができます。また、延命が目的になりますので、不要な機能追加や業務ロジックのバージョンアップはスコープから除外します。

SAPのバージョンアップでは選定するバージョンによってはBASISモジュールのみをバージョンアップし、FIやCO、SDといったモジュールはバージョンをあげないという選択も可能です。このようにすることで検証時のテストケースを減らすことができます。業務ロジックが変更になると、ホワイトボックステストも必要になってきますし、他システムとの連携時に出力されるデータのデータフォーマットや出力結果が変わってきますので、データ連携のプログラム改修が発生します。

また、ここが明確になっていないと、ベンダーさんに依頼した後で、「そこはスコープに含まれていない」など、もめる要素になりますので、慎重に抜けもれなくやりましょう。

HWリプレース

それでは早速、スコープを設定していきます。まずはHWリプレースを実施するかどうかです。ほとんどの基幹システムは導入時にHWの導入も行っており、およそ5年程度でHWメーカーのサポート切れが起こるタイミングかと思います。

HWリプレースはバージョンアッププロジェクトのスコープに含めた方がよいと考えます。

理由はHWリプレースだけを単独で実施してしまうと、現行環境と新環境の両方を並行稼働させるリソース（CPU、メモリなど）を確保するのが難しいからです。

バージョンアッププロジェクトはおよそ1年ぐらいかけて行われます。現行環境はこれまで通り本番稼働させた状態で、新環境を構築し、さらにテストを行う必要があります。さらに新環境のリソース量はだいたい現行環境と同等かそれ以上になりますので、瞬間的には現行環境の2倍のリソースが必要です。

HWリプレースのみを単独のプロジェクトで行うのであれば、余裕率も見て、現行環境の2.5倍のリソースは確保しておいた方がよいです。ただし、バージョンアップが完了すると現行環境で使用していたリソースは不要になるので、他システムへの転用など検討しておかないと、無駄に高いコストでHWを準備することになってしまいます。

HWリプレースのタイミングでAzureやAWS、GCPなどのクラウドへ移行するかどうか、検討することもあります。コスト観点、運用負荷観点、リソース調達までのリードタイム観点、新技術への適用の観点など、さまざまな観点で検討しますが、やはりコスト観点で比較する会社が多いのではないでしょうか。

結論から言うと、DR（Disaster Recovery）も構成に含めるのであれば、クラウドへ移行してもコスト観点でメリットが出ると思います。

なぜなら、DRの構成をオンプレで組もうとすると、DRサイトのデータセンターを準備する必要があり、さらに、あらかじめ、本番環境が稼働するリソースをDRサイト側で待機しておく必要があります。

DRサイト側のリソースは大規模障害時のみ稼働すればよいのですが、オンプレだとリソースを確保し、遊ばせておく必要があります。このようなDRサイトとクラウドの相性はばっちりですので、クラウドへの移行も採用しやすいかと思います。

ただし、気を付けないといけないのは、オンプレのデータセンターとクラウドをつなぐ回線の帯域が数百Mbps程度だと、移行時のダウンタイムが長くなってしまいます。

移行時のダウンタイムを短くする方法は別の機会に紹介したいと思います。

今回は「スコープの確認」の中の「HWリプレース」にて検討するポイントについて見てきました。

ポイントは