業務アプリケーション移行を成功させるために「なすべきこと」は？：迫るWindows Server 2003終了の日

Windows Server 2003の延長サポートが「2015年7月15日」で終了する。Windows Server 2003の利用用途は多岐にわたるが、その中でも数が多く、かつ、移行に手間がかかるのはアプリケーションサーバーだ。そこで稼働する業務アプリの移行を考慮すれば、すでに“待ったなし”の状況と言える。もし今から着手するのであれば、作業範囲は最小限に絞り極力リスクを抑えるべき。そのためにはWindows Server、IIS、.NET Frameworkなどが持つ「後方互換性」をフルに活用してほしい。

[PR／＠IT]

待ったなし！ サポート終了まであと1年半弱

日本マイクロソフト株式会社 コンサルティングサービス統括本部 コンサルタント 稲葉歩 氏

　2003年5月のリリースから10年以上が経過したWindows Server 2003。すでにメインストリームのサポートは終了しており、現在は延長サポートのフェーズにある。その延長サポートもいよいよ「2015年7月15日（日本時間）」に終了する（Windows Server 2003 R2も同日に延長サポートが終了）。

　カレンダー上では1年半弱の期間があるように見えるが、サーバーOSの移行にはアプリケーションの移行も付き物。カスタム開発のアプリがある場合、場合によっては新規開発と同程度の移行期間を必要とするケースもある。

　一方で懸念されるのが、ソフトウェア開発エンジニアの払底だ。1年半後のサポート終了に向けて、企業や組織で利用されている多くの業務システムを同時期に移行することになるため、個々のアプリケーションの移行に時間とリソースをかけすぎると社内の要員だけでは対処が難しくなってくる。またこのような“移行”のサービスを得意とするシステムインテグレーターなどの外部デベロッパーに依頼しようとしても、同じ時期に需要が殺到することも予測される。このような状況に陥るとせっかく立てた移行計画もリソース不足が原因で予定通りに進められなくなってしまう。

　「2015年7月までは、人手も時間も足りない状態になることが予測されます。ですから今回の移行ではなるべく手間をかけない方策を選ぶべきだと考えています。まずはWindows Server 2003からWindows Server 2012 R2への移行を最優先し、機能を追加したりクラウドに載せ替えたりといった拡張は、その後のフェーズで実施することを検討してください」

　これからWindows Server 2003および業務アプリケーションの移行に取りかかろうとする企業に、日本マイクロソフトのコンサルタント、稲葉歩氏はこのように勧める。このような状況では移行方法も短期で工数が少ないものを選ぶべき、というのが同氏の指摘だ。

　Windows Server 2003で稼働していた業務アプリケーションを移行する方法は、大別すると3つある（図1）。

図1　業務アプリケーションの移行方針は、大きく分けて「新規開発・再構築」「後方互換性」「仮想化」の3種類になる（クリックで拡大します）

　第1は、業務アプリケーションにはまったく手を入れずに、現在稼働中のサーバーをP2V（物理−仮想）変換して仮想マシン上で動作させる方法。だが、「ハードウェアの保守切れ対策などでよく使われる方法ですが、今回はWindows Server 2003そのものがサポート切れになるので意味がありません」と、稲葉氏は言う。

　第2に、業務アプリケーションを再設計ないしは再実装することで、Windows Server 2012 R2に対応したアプリを新規開発する方法。稲葉氏は、「このアプローチはプロジェクト規模が大きくなりがちですし、スケジュールの遅れも懸念されます。もちろんもっと早い段階から計画されていた場合には様々なメリットがありますが、このような状況ではハイリスクと言えるでしょう」と評する。

　以上を踏まえると、第3の方法となる「後方互換性」（旧バージョン向けに開発された製品が、新バージョンでも使えること）を利用するのがベスト、というのが稲葉氏の考えだ。「仕様は現状のままで凍結、ソースコードの修正は極力抑えることを基本として、新しいインフラやランタイムで動かないものだけを書き換えるようにして、工数も期間も最小限に抑える工夫をするべきです」

調査、評価、計画、テストで確実な移行を

　業務アプリケーションを移行するプロセスは、他のOSやミドルウェアをアップグレードする場合とほぼ同じだ。大まかには、「1.インベントリ収集」→「2.移行の優先順位づけ」→「3.全体移行計画立案」→「4.パイロットテスト」→「5.個別の移行プロジェクトを実施」という流れになる（図2）。

図2　全体としては「1.インベントリ収集」→「2.優先順位づけ」→「3.全体移行計画立案」→「4.パイロットテスト」を実施したのち、「5.個別アプリの移行」というプロセスで進める（クリックで拡大します）

　「インベントリ収集」では、既存資産を棚卸し、どのようなアプリがあるか、そのユーザー数や利用部門、アーキテクチャ、サードパーティ製品の有無、Windows Server 2012 R2への対応状況、設計書やテストケースなどのドキュメンテーションの有無、といった情報を集めていく。

　そこで集めた情報を元に、非常に重要、必要、移行不要、といったように各アプリケーションをランク付けし、移行の「優先順位づけ」を行う。

　優先順位が決まったらそれを元に「全体移行計画」を立案する。“移行不要”となったものは移行計画から外し、全体として予算やリソースが厳しいようであれば優先順位の高いものから移行計画に組み込んでいく。また各アプリケーションの移行方針もここで検討する。

　ここまでは机上での計画なので、可能であればこの段階で「パイロットテスト」ができると望ましい。簡易構成で構わないので、とりあえず業務アプリをWindows Server 2012 R2にインストールして動作確認をする。この目的は移行そのものではなく、移行計画の見積もりや移行方針の妥当性の評価だ。企業内に多数のアプリケーションがあっても類似のアーキテクチャになっていると、このパイロットテストによって得られる知見は非常に効果が高い。

　パイロットテストの結果を元に移行計画を修正し、実際の個別アプリケーションの移行を実施していく。「個別移行プロジェクト」の大まかな流れは「1.新しいインフラ・ランタイムへの対応」作業を実施したのち、「2.テストとデバッグ」を繰り返し、一定の品質基準に達したことが確認されたら「3.リリース判定」が行われてリリース、移行プロジェクトは終了して「4.保守・運用」フェーズが始まることになる（図3）

図3　テスト工程で見つかった不具合をつぶす（デバッグ）作業を繰り返し、十分な品質が確保されたことが確認されたら本番環境に配備する（クリックで拡大します）

　前述の「3つの移行方針」はあくまでも「新しいインフラ・ランタイムへの対応」に関するものであり、移行プロジェクトにおいてはその後のテストが非常に大きな割合を占める。

　そもそもWindows Server 2003からWindows Server 2012 R2にアップグレードすることで、業務アプリケーションの動作基盤も一新される。仮にソースコードを全く書き換えなかったとしても、アプリケーションの品質評価としてテストは不可欠だ。

　移行計画を立案するにあたっては、通常の新規開発に比べると、設計・実装の比重が低くなる代わりに、テスト工程の比重が高くなることも考慮すべきだろう。もちろんここでは既存資産としてテスト計画やテストケースを再利用したい。しかしこれらの資産が残っていない、現状の仕様と乖離している、などといった理由から再利用できない場合には、再作成が必要になってくる。当然コストにもスケジュールにもインパクトが大きいため、前述の「インベントリ収集」段階でしっかりと確認しておきたい。

　採用した移行方式に関わらず、アプリケーションの構成が変わっている以上、原理原則論から言えば全てのテストケースに対して再検証を実施すべき。ただ現実問題としてスケジュールやコスト的な観点から、テストの内容には“濃淡”があってもよい、というのが稲葉氏の考え。

　「これは一部のテストケースを実施しない、すなわちバグが潜在化するリスクをどう見るかにもよりますので、一概にこうすべき、という指標を出すのは難しいです。しかし闇雲に新規開発とまったく同じレベルのテストを実施するのではなく、効率的にテストを進める、すなわち効率的にバグを発見する工夫をすべきでしょう。ただ重要度の高いテストケースは必ず実施するようにしてください。それ抜きでリリース判定をすべきではありません」

後方互換性は4レベル

　Windows Server 2003上で動作する業務アプリケーションのアーキテクチャは大別してWindows DNA（ASP）と.NET Framework（ASP.NET）の2パターンになる。これを踏まえると後方互換性は4つのレベルで考える必要がある（図4）。

図4　Windows Server、IIS、ASP.NET、Visual Studioの4つのソフトウェアが持つ「後方互換性」を利用し、最小工数／最短期間で移行を実施する（クリックで拡大します）

　まず今回の主題であるWindows Serverの本体。Windows Server 2003の時代はx86版（32ビット版）が主流だったが、Windows Server 2012 R2はx64版（64ビット版）しか存在しない。「ただし、Windows Server 2012 R2に搭載されている32ビットエミュレーターであるWOW64（Windows 32-bit on Windows 64b-bit）を利用することで、ほとんどの32ビットコードはそのまま実行できます。このため現状32ビットで動作しているものをわざわざ64ビットで動作させる必要はないでしょう」と、稲葉氏。

　WOW64による32ビットエミュレーションで問題が発生しやすいのは、アプリケーションがネイティブのCOM（Component Object Module）やDLL（Dynamic Link Library）を使用しているようなケースで、それらがOSのプロセッサアーキテクチャに強く依存しているようなケース、例えばデバイスドライバ、とのこと。

　次に、アプリケーションサーバーとしての「IIS」（インターネットインフォメーションサービス）がある。「Windows Server 2003ではIIS 6.0、Windows Server 2012 R2ではIIS 8.5と4世代も離れていますから、おそらくここが一番の問題となるでしょう」と、稲葉氏。

　特に大きな影響を受けるものとして、構成管理、インストールや運用管理のためのスクリプトなどが挙げられる。IIS 6.0までは構成設定が「XMLメタベース」（MetaBase.xmlファイル）で管理されていたのに対し、IIS 7.0以降は構成設定の一部がASP.NETの構成設定（Web.config）と統合されているからだ。

　3番目のASP.NETに関しては、パイプラインモードの設定が鍵となる。

　「IIS 6.0までは、アプリケーションの前処理／後処理を行うパイプラインがIISとASP.NETで別々に用意されていましたが、IIS 7.0から統合パイプラインが新設されました。しかし苦労してまで新しい統合パイプラインモードを使う必要はありません。IIS管理ツールで『マネージパイプラインモード』を『クラシック』と設定して、IIS 6.0と同じ仕組みのASP.NET独立パイプラインを利用するとよいでしょう」

　最後にアプリケーションレベルでの後方互換性は.NET Frameworkのバージョンとの対応がキモになる。

　「IIS 8.5はアンマネージドのASP（Active Server Pages）、マネージドのASP.NET 2.0と4.0の3種類のアプリケーションに対応しています。つまりIIS 6.0で対応していてIIS 8.5で対応していないのはASP.NET 1.1だけで、それ以外はこれまで通り動かすことができます」

　「CLR（Common Language Runtime：共通言語ランタイム）自体が後方互換性を持っているため、ASP.NET 1.1向けにコンパイルしたバイナリーコードをASP.NET 2.0／4.0で動作させることは技術的には可能です。しかしここでは最新のVisual Studio 2013で再コンパイルして、ASP.NET 4.0のアプリケーションとするべきです」

　ランタイムはASP.NET 2.0や4.0を使用しつつ、アプリケーションはASP.NET 1.1向けに開発する、という保守体制をとった場合、そこで利用する統合開発環境は Visual Studio.NET 2003になる。しかしこのVisual Studio.NET 2003の延長サポートは2013年10月に終了している。

　「ソフトウェアの保守は移行後も営々と続くものですから、サポート切れの製品を使用し続けることはお勧めできません。そもそも開発・保守環境とテスト・運用環境でソフトウェア構成に差異があるのは余計な手間を増やします。このタイミングで最新のVisual Studio 2013にアップグレードすることをお勧めします」

サーバー移行を機に開発／保守体制の再整備を

　Windows Server 2003用の業務アプリケーションをWindows Server 2012 R2環境に移行することは、大掛かりな作業となる。そして次のWindows Server 2012 R2のサポート切れのときにも同じような苦労をすることになるのだろうか。

　「今回の移行が無事に完了しても、保守とテストのサイクルは今後もずっと回り続けます。次回も後方互換性を利用した移行ができるかどうかは現段階で予測ができません。しかしそれとは別に、ソフトウェア資産管理をきちんと回していくための体制を整備しておく必要があることだけは確かです」

　またこの機会をアプリケーションのアップグレード戦略を見直すきっかけにしてほしい。一般的にアップグレード戦略は大きく分けて2つ（図5）。1つ目はインフラやランタイムのバージョンアップにタイムリーに追随していく、昨今流行りのラピッドリリース的な考え方だ。もう1つはインフラやランタイムのサポートが切れるぎりぎりまで塩漬けにしておき、一気に最新のインフラやランタイムに対応させる考え方だ。

図5　どちらのアップグレード戦略も一長一短だが、どちらの場合も計画的に進めることが重要（クリックで拡大します）

　「どちらも一長一短ですので、どちらかをお勧めするものではありません。今日お話しした内容は後者の戦略を採用していて、しかし対応が後手に回ってしまったため、移行の方針に制限がかかってしまったケースです。スケジュールに余裕があればリスクも取れますし、後方互換性を採用しつつ一部機能は新規開発、といったような柔軟な対応も可能だったでしょう」

　「一方で前者のラピッドリリース戦略であれば、どちらかといえば業務的な要求をきっかけにアプリケーションの機能をタイムリーに強化していくことになります。そのついでに最新版のインフラやランタイムに対応していくようにすれば、そもそもサポート切れを迫られる懸念自体がありません」

　「昨今はビジネスニーズや技術トレンドに柔軟かつ機敏に対応できる体制や組織を作ることも情報システム部門にとっての重要テーマになっています。こうなるとアジャイル開発プロセスやアプリケーションライフサイクル管理（ALM）といったテーマが上がってくることが多いですが、それ以前にソフトウェア資産管理がしっかりとできているか、環境変化のスピードに追随できるだけの組織や体制が整っているか、といった基本的なところが重要になってきます」