「触るな」と書かれたあの恐ろしい古いシステム？上司はどうしても触らせたがります。さて、どうしますか？

分析レガシー システムは数十年にわたってサーバー ルームに放置されており、徐々に設計が複雑になり、運用コストが高くなり、管理者にとって理解しにくくなり、所有者にとって不可欠なものになってきています。

もし勇者が機械の内部を覗き込もうとしたら、機械が製造、給与計算、在庫管理などのミッションクリティカルな機能の全部または一部を実行していることに気づき、顔が真っ青になり、変更を加えることは、なんと言えばいいのか、些細なことではないことが分かります。

そして、これらのシステムがWebベースの注文やモバイルアプリといった新しいものにさらされるようになる前の比較的最近までは、それは問題ありませんでした。そのため、アプリケーションのモダナイゼーションが「流行」となり、数十年にわたって静かに機能してきたこれらのシステムは、更新または置き換えを迫られるようになりました。

しかし、移転は複雑で費用も非常にかかります。これらのシステムを構築した人々はすでに去っている可能性があり、彼らの不在時に役立ったであろうドキュメントは存在しないか、たとえあったとしてもひどく不十分です。また、交換用のハードウェアを入手できるのはeBayだけかもしれません。

「移住」という概念は、一見するとそれほど単純な選択肢ではありません。様々な選択肢があります。未知の世界へと旅立つ前に、考慮すべき点や検討すべき点について、分かりやすく解説したガイドをご用意しました。

人々を第一に

封筒の裏に鉛筆で印をつけたり、Excelやピボットテーブルを取り出したりする前に、移行を推進しているのは誰で、何を望んでいるのかを理解することが大切です。これは非常に重要です。なぜなら、これを把握することで、移行の最終目標と、採用する移行モデルが決まるからです。

一部の移行、特に「デジタル化」はビジネス主導です。ITサービスおよびソフトウェア企業Automation Consultantsのディレクター、フランシス・ミアーズ氏は、もしこれが事実であれば、企業はこれまで以上に迅速にサービスを市場に提供しなければならないというプレッシャーにさらされる可能性が高いと述べています。「常に競合他社に遅れずについていき、最新の機能をすべて備えなければならないというプレッシャーがあります。これはIT部門にとって、一連のプロジェクトとして捉えられることになります」と彼は述べています。

移行は技術部門主導で行われるケースもあります。より大きな問題に対する技術的な解決策を模索するのです。ITサービス企業ECSのコンサルタント、デス・トランドル氏によると、このような技術主導の移行も問題を引き起こす可能性があります。「技術チームが主導する場合、初日から苦戦を強いられることになります。なぜなら、彼らが低リスクの選択肢と見なすリフト＆シフトについてすぐに議論することになるからです」とトランドル氏は言います。多くの場合、これは最もコストのかかる方法であるにもかかわらず、投資収益率は最も低くなります。

この空白を埋めるようにAmazon Web Servicesが登場しました。同社は「6つのR」を発表しました。これは、データをクラウドに移行することに重点を置いていますが、移行を検討する際にも役立ちます。そのRとは一体何でしょうか？Retain（保持）、Retire（廃止）、Rehost（再ホスト）、Replatform（再プラットフォーム化）、Refactor（リファクタリング）、Rearchitect（再設計）です。移行においてよく使われる手法の一つであるLift and Shift（リフト＆シフト）も、AWSの6つのRに含まれています。

AWSの6つの選択肢の中で最も簡単なのは「維持」です。つまり、アプリケーションと既存のシステムを現状のまま維持するということです。Linuxベンダー兼クラウドベンダーのRed Hatのソリューションアーキテクトであるムスタファ・ムサジ氏によると、統合こそが救世主です。「データやアプリケーションサービスへのアクセスなど、グリーンフィールドアプリケーションの動作に必要な機能の多くは、ブラウンフィールドにあります。最新の統合ミドルウェアは、新旧のギャップを埋めると同時に、拡張性も提供します」とムサジ氏は言います。

「グリーンフィールドにマイクロサービス アーキテクチャを導入することで、開発者や新しいアプリケーションが最新のテクノロジー、ビルド ツール、フレームワーク、方法論を使用して、ビジネスの迅速な革新と適応を支援できます。」

乗せてもらえますか？

しかし、古いApolloサーバーがゴムバンドで固定されていて、不快なキーキー音を立てているかもしれません。代替案として、トランドル氏が「リフト＆シフト」と呼ぶリホスティングがあります。このシナリオでは、ターゲットシステムに同等のアプリケーションを移行します。

理論上は、アーキテクチャの変更は最小限で済みます。企業はクラウド環境への移行時に、安価で手軽な選択肢としてこれをしばしば採用しますが、環境が古くなるほど危険性は増すとトランドル氏は警告します。「アプリケーションの移行だけを扱っているのではありません。レガシーコードは、OSIスタック全体に奇妙な点をもたらす可能性があるのです」と彼は言います。

彼はデータ移行を例に挙げました。一部の企業は、アプリケーションのストレージ層をSANインフラストラクチャに移行しようとするかもしれません。「OSからミドルウェアへとスタックを上っていくと、デバイスドライバーがメンテナンスしていたOSのバージョンでは動作しなくなることに突然気づくまでは、全く問題ありません」と彼は言いました。

さらに、ネットワークの問題もあります。「レガシーマシンはおそらくトークンリングの時代に構築されたもので、独立したスイッチが搭載されています。ハードコードされたアドレスを持つ1万台のクライアントがあり、IPモビリティを備えた新しい環境に移行したいと考えているのです」とトランドル氏は言います。「リフト＆シフトはあっという間に爆発的に増加します。」

ここで、Amazonの6つのポイントモデルにおける次の2つの要素、すなわちリプラットフォームとリファクタリングが登場します。これらは、移行をサポートするために、アプリケーションとその基盤となるテクノロジーに様々なレベルの構造的変更を加えることを意味します。古いアプリケーションを新しいインフラストラクチャに無理やり組み込むために必要な変更が増えるほど、これらのオプションはより複雑でコストも高くなります。