トレンド情報 / 記事を探すCOLUMN

サポート切れのJavaシステムの対策は? 運用し続けるリスクと技術的負債の返済

更新日|2019.11.26

Qbook編集部

サポート切れのJavaシステムの対策は? 運用し続けるリスクと技術的負債の返済

※本コラムは、2019年12月セミナー共催に当たり、株式会社スタイルズ様より提供されました。
株式会社スタイルズ|https://www.stylez.co.jp

2000年前後よりStruts(ストラッツ)を代表とするJava言語のための開発フレームワークが開発され、企業情報システムでデファクト・スタンダードとして、盛んに採用されてきました。その中には十数年を経過しても根本的な刷新がされず、今では古くなってしまったフレームワーク上でメンテナンスが継続されているものも少なくありません。その結果、情報システム部門は古いフレームワークで動作する既存システムの保守に資金や人材を割かれ、新たなデジタル技術を活用したIT投資にリソースを振り向けることができず、ますます維持・保守コストが高騰します(技術的負債の増大)。また、既存システムを維持・保守できる人材が枯渇し、セキュリティ上のリスクも高まるという、「2025年の崖」が叫ばれているというのも現状です。

 この記事では、StrutsやSeasar2などの保守切れとなったフレームワークを利用し続ける技術的リスク、そのリスクを解消するための大きな考え方をご説明していきます。

フレームワークとは?

 1990年台の終わり頃から、企業の基幹システムがWebアプリケーションとして開発されるようになっていきました。そして、開発体制は大規模になり、開発チームはより多くの技術者によって構成されるようになっていきます。そんな中で、アプリケーション開発をより標準化し、効率化するための全体的な枠組み(フレームワーク)が徐々に出現してきます。

 開発フレームワークの目的は、アプリケーションを開発する場合に必要となる部品や実装上の枠組み、そして同時に制約を提供するというものです。アプリケーションを開発するための枠組みが洗練された形でフレームワークとして提供されることで、開発担当者のプログラミングスキルに直接的に依存する部分の割合を大幅に減らすことができ、経験が浅いメンバーも含まれる大規模なチームでも一定の品質を担保できるようになり、生産性や保守性を維持できるようになるのです。

Strutsの登場

 1999年に登場した「J2EE」(Java 2 Platform, Enterprise Edition) 1.2サーバーサイドJavaによって、JavaでWebアプリケーションを開発するための基本的な機能であるServletと「JSP」(Java Server Pages)、「JDBC」(Java Database Connectivity)や「JTA」(Java Transaction API)といった基本的なAPI群がまとめて提供されました。これによって、Javaで企業システム向けWebアプリケーションを開発するための最低限の基盤が整いました。

 しかし、この時点ではWebアプリケーション開発のための素(す)の機能が提供されただけであり、こうしたシンプルなAPIを使って実際の開発をするには、それに携わるプログラマー一人ひとりに高度なスキルが必要でした。そこで、アプリケーションに一定の構造的な枠組みを与え、汎用的な機能を部品化することで設計とコーディングを簡単化する開発フレームワーク「Struts(ストラッツと発音)」が2001年に登場します。Jakarta Projectによって策定されたJava言語でのアプリケーション開発フレームワークです。

 Strutsは、Servlet+JSPといった素の機能だけでは難しかったWebアプリケーションの設計・開発を、一定のスキルレベルでも安定して実施できるようにすることで、Javaのエンタープライズ利用と大規模システム化への道を開いたと言えます。

Struts以前と以降

 Strutsの登場以前、Webアプリケーションは、サーバーからクライアントブラウザの要求に応じて、HTMLを返却する Common Gateway Interface(CGI)の仕組みの延長性で動作していて、開発もPerl、PHP、ASP、JSPなどのスクリプト言語で行われていました。しかし、2001年に登場したStrutsフレームワークの、
①デザインとロジックの分離
②美しいアーキテクチャーと統一性
という特徴によって、企業システムの基幹系等のシステム開発にまたたく間に広がり、大流行します。

図1:Strutsの動作フロー

図1:Strutsの動作フロー

 Struts のようなMVCフレームワークに続き、2003年~2006年ごろには、O/Rマッピング、DIコンテナなどのフレームワークも誕生し、それぞれデファクト化したいくつかの選択肢からプロダクトを選定し、組み合わせて利用することが一般的になりました。特にStruts+Spring+iBatis(またはHibernate)といった組み合わせが有名になりました。筆者の体感でいえば、2000年代の中頃には、MVCフレームワークとしてのStrutsのシェアは60~70%に達していたのではないかと感じます。

Struts1の開発終了

 その後、様々なフレームワークが登場する中で、2008年にはバージョン1.3を最後にStrutsの開発が終了し、2013年にはサポートも終了しました。その後継としてStruts2が生まれましたが、「Struts 2」はそもそも設計思想の異なる別物のフレームワーク「WebWork2」に多くを依存しており「Struts 1.x」系とは互換性もなかったため広く流行することはありませんでした。そのためStruts1を採用して開発されたシステムの多くがStruts2に移行することなく、そのままメンテナンスされ続けてきたのです。

図2:Javaフレームワークの私的シェアイメージ

図2:Javaフレームワークの私的シェアイメージ

Strutsの脆弱性とその被害

 2013年にサポートが切れたStruts1系ですが、2014年4月にClassLoader を操作される脆弱性(CVE-2014-0114)が発見されました。これは、まず、Apache Software Foundationにより、2014年3月5日にStruts2系の脆弱性として発表されましたが、2014年4月24日にはセキュリティベンダーよりStruts1系にも該当すると発表が行われたものです。

そして、この脆弱性が悪用された際の影響として、

  • Webサーバー内の情報を盗み取られる
  • 特定ファイルを操作される
  • Webアプリを一時的に使用不可状態にされる
  • 操作されるファイルにJavaコードが含まれる場合、任意のコードが実行される

が挙げられました。

任意のコード実行などの悪質な被害を受ける可能性が高く、かつ、Struts1がすでにサポート切れしていることから、IT業界では大きな話題になりました。
さらに2017年3月にはApache Struts 2における任意のコードが実行可能な脆弱性(CVE-2017-5638/S2-045)が公表され実際の攻撃によって、

  • クレジットカード支払いサイト
  • 生命保険サイト
  • 利用者登録ページ
  • チケットサイト

などから個人情報やクレジットカード情報が漏洩したことで、社会的にも大きくニュースで取り上げられました。

技術的負債と技術者不足

 「技術的負債」というワードは、1992年にウォード・カニンガム氏(世界初のウィキを開発したアメリカ合衆国のコンピュータ・プログラマー)が、技術者ではないステークホルダーにこの問題を伝えるために使ったと言われます。生産性の低い古い技術やフレームワークを、より新しく効率的なものに切り替える(負債を返済する)ことで、ソフトウェアをより素早く開発し、ビジネスを革新することができるはずだと主張しています。

 Strutsのような古い(古すぎる)フレームワークをメンテナンスせざるを得ない状況は「技術的負債」と呼ばれ、そのデメリットとして、下記が挙げられます。

  • メンテナンスコストの増加
  • 開発者のモチベーションの低下
  • 若手技術者の技術レベルの低下
  • 技術者採用力の低下や離職の増加

現在IT技術者不足はますます深刻さが叫ばれており、優秀な技術者はより新しい技術を扱える職場を求めて転職を志向することから、この負債の克服は企業にとって非常に重要な課題と言えます。

フレームワークのコンバートの困難さ

 Strutsを利用しているような古いシステムを大幅にリニューアルする、特に外部に委託することを困難にする一つの要因は「設計書がない」「ドキュメントがメンテナンスされていない」ことにあります。設計書が当てにならない以上、その作業はプログラムコードだけを根拠に進めなければなりません。そのためにはコンバート作業や動作テストをかなり機械的に進められるようにする必要があります。そういった作業を可能にするためには、コンバート先のフレームワーク選定が重要になります。具体的には、新旧のフレームワークの基本構造が同一であるものを選択することが大事になってくるのです。

 まとめると、古いフレームワークを利用したシステムを刷新する困難さは以下の3点が挙げられます。

  • 設計書や資料がない(プログラムコードだけが根拠)
  • 手動で書き換えると非常に大きな工数(コスト)が必要になる
  • 機械的にコンバートを進めようとすると、フレームワークについての深いノウハウが必要

 フレームワークのコンバートサービスを提供している株式会社スタイルズでは、StrutsやSeasar2からの移行先フレームワークとして、SpringFrameworkの最新バージョンを採用します。移行にあたっては、(フレームワークについての豊富な知見を反映した)変換ツールを利用し、一旦は機械的なコンバートを行い、その後、手動でのコンバートや動作確認を行うことで上記システム刷新における課題を軽減しています。

図3:コンバート作業の進め方

図3:Javaフレームワークのコンバート作業の進め方

株式会社スタイルズについて

logo

株式会社スタイルズでは、高品質のシステムインテグレーションサービス、アプリケーション保守・システム監視や運用保守・IT人材サービスまで、お客様のITによる問題解決・ビジネスの発展のためのアイデアとソリューションを提供し続けています。

https://www.stylez.co.jp

資料ダウンロード

ライター:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。