あなたの目の前にレガシーなWebアプリケーションがあるとします。あなたはそのせいで、いつもびくびくしてます。なぜなら、元々の開発者は、なんのドキュメントも残さずにもう何年も前に辞めており、開発者のチームはあるものの、誰もあえてそのプロジェクトに触ろうとはしません。誰もが、自分の目の前でセキュリティの侵害やパフォーマンスの崩壊が起こらないことを、ただ祈っているだけです。
セキュリティの侵害によって企業が打撃を受けたというニュースが毎日のように報じられています。Beaming社のレポートによると、2016年には半分以上（52%）のイギリスの企業がサイバー犯罪の被害に遭っており、その被害総額は約3000万ポンドにのぼります。こんな状況にも関わらず、あなたはそのレガシーアプリがダウンしてしまった場合に、どうやったら復旧して元のように稼働させられるのか、まったくわからないままでいるのです。
こういったシナリオは、あなたの身近にもあるのではないでしょうか？
この問題をいつまでも無視し続けることはできないとわかってはいても、どこから手を付ければいいのかわからないかもしれません。中には、まったく新しいものを最初からつくりたいという人もいるかもしれませんが、既存のアプリケーションにはすでに多額の投資が注ぎ込まれていますし、新たにつくり直すにはこれまで以上の多くの時間とお金がかかるでしょう。
もっともよいアプローチは、既存のアプリケーションを時間をかけて理解した上で、モダンな構成にアップデートしていくことに注力することです。
システムの検証から始める
まずは、アプリケーションをネットワーク構成やストレージ構成、デプロイ設定、サーバーといった構成要素に分けて考えることから始めましょう。これらの構成要素同士の相互の関係を図式化することによって、モノリス化したアプリケーションをいくつかの構成要素に分解して、それぞれの部分がどのように連携して動いているかを理解できるようになります。
そして同じくらい重要なのが、アプリケーションを管理するために必要なツールについて理解することです。これらの中には、VMWareなどのインフラ用のツールや、SAPなどのアプリケーション用のツールもあるでしょう。そしてこれらのツールそれぞれにベンダーとの契約があり、リリーススケジュールがあり、また考慮すべき他の要素もあるでしょう。
システムの検証は、そのプロジェクトのドキュメントを整備する絶好の機会にもなります。そうすれば、新しい開発者が加わった場合に、利用されているすべての技術スタックを自分で調べる必要がなくなり、素早くキャッチアップすることができます。また彼らが、重大な問題に繋がりうる重要な構成要素を見落としてしまうリスクも低減されます。
多くのレガシーアプリはモノリスとしてデザインされており、コードはその土台にあるインフラと密接に結びつけられています。当然のことながら、このような状況では、１つ１つの構成要素を改修することが困難になってきます。改修を行うたびに、改修対象の構成要素以外にはまったく影響がないことを確認するために、広範囲に渡るリグレッションテストが必要になるからです。
さらに、規模の大きいレガシーアプリでは、縦割りで使われていることも多いようです。たとえば、１つの会社内で同じアプリケーションが部署によって異なるインフラの上で動いているという場合もあります。また、アプリケーションをリファクタリングしようとする上で解消すべき問題である、ベンダーロックインについても考慮が必要かもしれません。
これらのレガシーアプリをモダンな構成にアップデートするということは、そのベースにあるインフラとの依存関係を断ち切るということです。これらの構成を抽象化することによって、アプリケーションの各構成要素をずっと柔軟に運用できるようになり、アプリケーションのホスティング先からストレージの費用に至るさまざまな要素についてコントロールできるようになります。
コードをモジュール化してリファクタリングする
インフラからの切り離しの次のステップは、コードをモジュール化していきます。モジュール化によってコードの移植やメンテナンスが一層やりやすくなります。たとえば、関連するデータと関数をカプセル化してAPIで使えるマイクロサービスをつくるのもよいでしょう。こうしたマイクロサービスは、実装の詳細が隠され、インターフェイスだけが見える形になるため、ずっと理解しやすいものになります。
アプリケーションをモノリスのままにしていたとしても、コード全体をより読みやすく、拡張しやすくリファクタリングすることは可能です。コードが簡潔でモジュール化されたものになれば、時間の経過と共に現れるバグや脆弱性の余地を減らすこともできます。
テストのカバーする範囲の広さもモダンなアプリケーションにとって不可欠な要件です。もしレガシーアプリが十分なテストを行っていないのであれば、コードの些細な変化が、原因を追跡するのが非常に難しい破壊的な変化を引き起こす可能性があります。テストが十分な範囲をカバーするのであれば、変更を恐れる必要がなくなり、アプリケーション全体のセキュリティとパフォーマンスに自信を持つことができます。
DevOpsのワークフローをつくる
レガシーアプリが厄介なのは、ひとたび変更を加えようとすると多くの不確実性を起こするからです。アプリケーションをインフラから切り離した後は、複雑なリグレッションテストをモダンなUIでマウスの簡単操作に変えてしまうような、DevOpsのワークフローをつくり始めることができます。
モダンなDevOpsのプロセスは、スケーラビリティを高めるという効果もあります。より多くのコンピューターパワーが必要になれば、素早くクラウド環境に新たなインスタンスを生成して、パフォーマンスを維持することができます。より多くのストレージが必要になればその場ですぐに適切に調整することできるので、インフラに対して過剰な費用をかけずに済みます。
最後に、DevOpsのプロセスがあれば、プロジェクトに開発者を引き込みやすくなります。コードはずっと理解しやすいものになり、破壊的な変更をデプロイしてしまうリスクも少なくなります。システム自体が理解しやすくなるので、新たな開発者を参加させやすくなりますし、外部のチームに開発を委託するといったことも容易になります。
セキュリティを最優先に考える
レガシーアプリは、期限が切れた依存性や元々のコードベースに潜む脆弱性のために、しばしばセキュアでないケースが多くあります。たとえば、あなたのアプリケーションは、もはやメンテナンスされていない古いバージョンのJavaやPHPによって動作しているかもしれませんし、SQLインジェクションに対して脆弱なコードを含んでいるかもしれません。
多くのサイバー犯罪者は、こうした脆弱性を探し出すことに特化してつくられたツールを使っています。彼らにかかれば、侵入してデータを盗んだり、スパムを送るための踏み台にしたり、その他あなたのビジネスにダメージを与えることを、いとも簡単に行うことができます。だからこそ、セキュリティをアプリケーションの中心課題に置くべきなのです。
アプリケーションを構成するすべての構成要素が最新の状態にアップデートされていることを確認するためのプロセスが必要です。さらに、コード全体から脆弱性をみつけ出すためには、自動化されたテストそのためのツールの利用が欠かせません。そしてもちろん、攻撃を防ぐためには、インフラレベルのセキュリティの確立も必要です。
メンテナンスを怠らない
ここまでに紹介してきた変更を行なっていれば、メンテナンスはずっと簡単になるでしょう。しかし、誰かが責任を持って、すべての要素が最新の状態を保っていることを確認する必要があります。メンテナンスが遅れてしまったら、アプリケーションのモダン化に取り組む前にあった問題点をまた経験することになるでしょう。
すでにメンテナンスを実施することができるIT部署があったとしても、反応が悪かったり、新たなプロジェクトを引き受けることを嫌がるかもしれません。Webチームもまた、こうしたタスクを引き受けるのを嫌がるでしょう。なぜなら新たな機能を開発したり新規のプロジェクトに参画したりするほうがずっと刺激的だからです。
もしこれらのタスクを社内で実施できないようであれば、これをアウトソースするための予算を確保すべきかもしれません。メンテナンスのための予算を経営層に認めてもらうことは難しいかもしれませんが、アプリケーションをモダン化することによって節約できる費用や、もしセキュリティ侵害を受けた場合の潜在的な費用とさまざまなリスクを説明すれば、きっと納得してもらえるでしょう。
まとめ
レガシーアプリについて考えると不愉快になりますし、夜も眠れなくなるかもしれません。もしこれらの問題に取り組もうとしているなら、シンプルなステップを踏んでいくことで、アプリケーションをモダン化すること、セキュリティリスクを低減することに取り組んでいくことができます。まずはシステムを検証することから始めれば、きっと正しい方向に向かっていくでしょう。もし社内のリソースが使えないのなら、こうしたプロジェクトを外部に委託することも重要な選択肢です。
