レガシーシステムのモダナイゼーションとマイグレーションはどうあるべきなのか：基幹業務のSoRはどこまでクラウド化できるのか（終）（2/2 ページ）

基幹業務がメインフレーム上で稼働している企業は多くあり、レガシーシステムとクラウドを組み合わせた「ハイブリッドIT」の実現が必要です。今回は、その課題と対応について考察します。

[皆川元, 徳山衛，日本アイ・ビー・エム株式会社]

レガシーマイグレーションの進め方

　表1-1のテクノロジー課題T1「ベンダー製品（ハードウェア、ソフトウェア）の継続使用に伴うリスクが、時間の経過とともに高くなる」に対して、アプリケーション資産を継承、維持しつつ、プラットフォームを刷新するアプローチである、レガシーマイグレーションが有効だと考えられます。

　レガシーマイグレーションの一般的なフェーズの考え方を表2に示します。

表2　レガシーマイグレーションのフェーズ

フェーズ	調査、分析	パイロット	変換実施	現新照合テスト	システムテスト	サービスイン
終了時の目標	プログラムやデータの稼働状況／依存関係の解析結果に基づいて、移行対象資源を特定する	・本システムの実体に即して、ツールおよび手作業によるプログラムとデータの変換方法を確立する ・新システムのパフォーマンスについて、実測値に基づく指標を得る	移行対象の全プログラムの変換を完了する	現新照合テストなどにより、新システムの機能検証を完了する	・運用面なども含めてシステムの本稼働可否を判断する ・プログラムとデータの変換、移行を完了する

　レガシーマイグレーションでは、プログラムとデータの変換に関心が行きがちですが、基盤も重要です。メインフレーム上のシステムは、バッチが大量のリソースを消費する傾向にありますが、入出力専用のサブシステムをハードウェアで持つことで、CPUへの負荷の集中を回避しています。サーバは入出力でもCPUを使うため、メインフレームとは異なるパフォーマンス特性を示す場合があります。プロジェクトの終盤になって性能目標が達成できないと判明して慌てることにならないよう、表3のようにパフォーマンスエンジニアリングの活動を初期から計画的に実施することをお勧めします。

表3　レガシーマイグレーションにおけるパフォーマンスエンジニアリング実施例

フェーズ	調査、分析	パイロット	変換実施	現新照合テスト	システムテスト	サービスイン
パフォーマンスエンジニアリングの活動例	・夜間バッチのクリティカルパス上にある各ジョブのCPU時間と経過時間を分析する ・オンラインの統計情報から重いトランザクションを特定し、分析する	・バッチとオンラインそれぞれ性能面で重要な処理をパイロット候補として、アプリケーション側と調整する ・パイロット用に変換したプログラムとデータを使って開発機上で性能測定を実施する	本番機上で本番並みのデータを使い、パイロットの性能測定を実施する	パイロット対象以外で、性能上重要な処理の性能測定を実施する	機能検証が完了したプログラムとデータを使い、システムテストの一環でパフォーマンステストを実施する	アプリケーションの性能指標とシステム負荷を継続的にモニタリングする

レガシーマイグレーションの留意点

　レガシーマイグレーションを実施するときの一般的な注意点を以下に示します。

• スケーラビリティに関する特性の違い：メインフレームはスケールアップ可能であるのに対し、分散系サーバはスケールアウトが基本
• 可用性や信頼性要件に関する違い：メインフレームはハードウェアとOSのレベルで高可用性、高信頼性の実現を図るのに対して、分散系サーバでは冗長化と運用の工夫により高可用性／高信頼性の実現を図る
• 文字コードの違い：データ長の変化、ソート順の変化、外字の取り扱いなど
• データアクセス方式の違い：キー順アクセス（VSAM-KSDS）、ネットワーク型DB、階層型DBなどの移行先と移行方法
• データ変換ツール
• 外部インタフェース：連携先と連携方法（データセット共有、テープ媒体、ファイル転送、MQ）、データフォーマット、連携のタイミングと頻度、暗号化の有無と暗号化方式など
• 帳票：センタープリントのフォームオーバーレイ、オンラインの端末プリント、ロール紙や特殊伝票への印刷など
• セキュリティ：端末IDによる制御など
• 実行形態のバリエーション：オンラインバッチ、エミュレーターのファイル転送など

　1点目が意外な盲点となる場合があるので、ソリューション選定時にご注意ください。レガシーマイグレーション後のシステムが、OSおよびミドルウェアの構成や運用も含めて、構造上、メインフレームを踏襲したモノリシックなアーキテクチャになる場合があります。すると、本稼働後にリソース（CPUやメモリ）が切迫してもスケールアップもスケールアウトもできず、お手上げになる危険性があります。

　そのため、ビジネス上の課題解決を目的に、スケーラビリティの特性に適したシステム構築を行うべきです。「メインフレーム撤廃」を目的としてはいけません。

レガシーシステムを含むハイブリッドITの構成

　表1に示した課題の多くは、情報システム部門にとっては切実な問題です。しかし、これらの課題を改善しても、売上増や収益増、シェアゲインのいずれにも直結しないため、経営上の戦略的な投資として説明するのが難しい場合があります。一方で、ビジネスの成長に向けたIT投資を行うには、レガシーシステム固有の技術的負債の返済が前提になりますが、このようなジレンマを解くための一般解はありません。

　個々のレガシーシステムは、それぞれ固有の問題を抱えており、またテクノロジーと要員など、複数の問題が相互に絡み合っている場合があります。それぞれのレガシーシステムの特性に応じて、ハイブリッドITに組み込んでいく現実的なアプローチが求められます。本連載第1回でも紹介しましたが、要件レベルに応じて最適なインフラを見極め、システムを移行させる準備をするのです。

　例えば、ハイブリッドITに組み込むべきレガシーシステムのとして、「テクノロジー上の課題を抱えているものの、業務量やデータ量の伸びは見込まれず、従ってスケーラビリティの要件が厳しくない」システムを考えてみましょう。このようなシステムの場合、アプリケーションとデータに対する投資を保護するため、Lift＆Shiftによるクラウド化が候補になり得ます。その準備として、クローズドなハードウェアの制約から解放すべく、分散環境への移行を検討するのです（図3参照）。

図3　Lift＆Shiftの準備としてのメインフレームから分散環境への移行

　価値ある資産でもあるレガシーシステムは、安定稼働を優先してメインフレーム上での稼働を継続するのも現実解の1つです。その場合も、メインフレームから負荷のオフロードを図り、戦略的なアプリケーション開発を促進する工夫が望まれます。具体的には、本連載第2回で述べたように、SoEアプリケーションをクラウドネイティブ（Cloud Native）で実装し、API化したレガシーシステムと連携するアプローチが考えられます（図4参照）。

図4　レガシーシステムのAPI化

　いずれのアプローチを取る場合も、ハイブリッドIT化した後のアプリケーションの運用保守まで視野に入れた検討が望まれます。メインフレーム上のアプリケーションは、データの授受と共有によって連携しているプログラムが多数あるため、小規模な改修でも影響範囲が大きくなりがちです。そのため、影響調査とテストに時間を要することになり、修正〜リリースに1カ月かかることも珍しくありません。このような状態でAPI化すると、連携先のSoEの開発サイクルと足並みをそろえられず、魅力あるアプリや新機能のタイムリーなリリースを阻害することになりかねません。

　なお、アプリケーションの改修時に、変更やテストの対象範囲の特定に多くの時間と労力を要するケースが多いようです。メインフレーム上のアプリケーションの影響調査は、ソースコードの静的解析で効率化できる場合があります。COPY句やプログラムの使用箇所の調査だけではなく、データの波及分析や来歴分析を行うツールも使われ始めています。Javaなどの分散環境で使われるプログラミング言語の場合、フレームワークがレイヤー間の連携を実現するため、そのメカニズムを踏まえた専用の分析ツールを個別に開発するケースも見受けられます。

今後の方向性

　破壊的イノベーションの例として、UberやAirbnbがよく引き合いに出されます。これらは業態が従来型のビジネスとは異なるため、基幹系システムとは一見無縁のことのように感じられます。

　一方で、FinTechの領域では2017年5月26日に改正銀行法が成立し、早ければ2018年春以後、銀行や信用金庫に対してオープンAPIの努力義務が課されます。この動きは、クラウド上のサービスが基幹系システムと一斉につながり始める契機となるだけでなく、法規制の存在が保守的に作用しがちなところ、市場の圧力が法規制の改定に影響を与えた象徴的な出来事とも捉えられます。同様のことが他の業種で起こっても不思議ではなく、多くの企業にとって基幹系システムのモダナイゼーションが必要になると考えられます。その検討の際に、本稿に示した視点が少しでもお役に立てればうれしく思います。

---

　「基幹系もいよいよクラウドの時代へ」と題して4回の連載をしてきましたが、今般、本稿のレガシーマイグレーションの領域、特に基幹系の代表とも言えるメインフレームアプリケーションの刷新に関しては、雑誌などでも特集が組まれるほど、その機運は高まってきています。

　その背景の1つとして、第1回で取り上げたIaaSクラウドのマルチテナント型、仮想占有型、ハードウェア占有型（ベアメタル型）などのサービス多様化により、基幹系が求める非機能要件の実現性が高まっていることが挙げられます。また、IaaS以外では、財務会計や給与、人事などのノンコア業務のSaaS活用が進んでいる状況も、機運の高まりに寄与していると考えられます。

　基幹系を含んだ既存業務のクラウド化を検討する際は、第2回で取り上げた基盤の刷新という観点にとどまらず、全体最適視点、アプリケーション視点、ROI視点などを取り入れて多面的にクラウド化の検討をする事が肝要です。また、第3回で取り上げたクラウド化時代の運用を考慮した全体アーキテクチャを同時に考えることも重要な要素となります。

　さらにクラウド領域では、今後も新しい技術やサービスが次々に登場し、日々進化していきます。技術やサービスの革新スピードは速く、現時点でクラウド化に適さないシステムも、近い将来にはクラウド化のメリットを享受できる状況になっているかもしれません。クラウドに関連する技術やサービスの今後の動向に注目しつつ、第2回で紹介したクラウド化検討を定期的に実施することをお勧めします。

　最後に一言。この連載は、「基幹系をクラウド化していいのか？」という疑問から企画されました。執筆を通して確認できたのは、基幹系業務でのクラウド活用は環境や条件が既に整っているということです。この連載記事が基幹系をクラウド化するときの一助になれば幸いです。