レガシーアプリケーションの段階的モダナイズに必要なテクノロジーとデザインパターン【デブサミ2022】

【17-E-7】レッドハットのミドルウェアでレガシーアプリケーションを段階的にモダナイズする話

　多くの企業が今、DXに取り組んでいる。その際に課題になるのが、レガシーアプリケーションのモダナイズだ。だが、巨大であればあるほど、立ちはだかる壁が多数あり、なかなか手をつけられず悩んでいる企業も多い。そんな企業に対して、レッドハットは、段階的にモダナイズへ移行することを提案。どんなテクノロジーやデザインパターンを使って、段階的移行を行っていくのか。レッドハットのソリューションアーキテクトである森和哉氏が解説した。

レッドハット株式会社 テクニカルセールス本部 ミドルウェアソリューションアーキテクト部／ソリューションアーキテクト 森 和哉氏

段階的移行に必要なテクノロジーとデザインパターン

　「今、アプリケーションモダナイズへの関心は非常に高まっている」

　こう語り、森氏のセッションは始まった。アプリモダナイズへの関心が高まっている背景には、「データ量や利用者の増加に対応したい」「大幅に増えた保守コストを削減したい」「ブラックボックスを見える化したい」などさまざまな理由があるが、「強調したいのは柔軟かつ迅速に、変更対応が可能なシステムにしたいということ」と森氏は語る。ビジネスで優位に立つには、スピードとアジリティが非常に重要になるからだ。

　だが「アプリモダナイズに至る道は険しい」と森氏は言う。「密結合したモノリシックなシステムなので、簡単に分割できそうもない「組織も文化もウォーターフォール開発が前提となっており、そう簡単に変えられない」「モダンな技術や手法を取り入れるのが難しそう」など、アプリモダナイズに取り組みたくても、なかなか踏み切れない理由が多々あるという。

　モダナイズへの移行方式は「一括移行」と「段階的移行」の2種類ある。一括移行方式は一度にすべてを移行してしまうため、うまくいけばコストも時間もかからない。だが、後工程でトラブルが発生すると、リカバリーにかかる時間は非常に大きくなる。一方、段階的移行方式であれば、一括移行に比べてトータルコストは高く、工期も長くなるが、難易度やリスクも下がる。しかも小さな効果を確認しつつ導入範囲を決定できるので、「現実的には段階的移行を選択することをお勧めする」と森氏は説明する。

　この段階的移行を実現するために森氏は、「マイクロサービス」「コンテナ」「ストラングラーパターン」「イベント駆動型アーキテクチャ」というテクノロジーとデザインパターンが必要になるという。

　まずは1つ目の「マイクロサービス」。なぜマイクロサービスが必要なのか。従来のアプリケーションはUI層、ビジネスロジック層、データアクセス層の3層で構成されたモノリシックなアーキテクチャを採用していた。このモノリシックなアーキテクチャのデメリットは、「密結合になっているため、小さな変更であっても層全体でのテストやデプロイのやり直しが必要になる。また1つのデータベースを共有しているために、データが肥大化してボトルネックになりやすいという課題があった」と森氏は説明する。

　それに対してマイクロサービスは、UIやビジネスロジック、データアクセスという機能単位で小さなサービスとして定義する。それらの互いに独立した小さなサービス（機能）が連動することで、1つのアプリケーションとして動作するアーキテクチャである。

　「従来のモノリシックなアプリケーションとは異なり、サービスが小さく自律的であるため、素早く開発してデリバリーできるのがメリットです。ビジネスのアジリティを上げていくためには、マイクロサービスへと変えていくことが重要になると思います」（森氏）

　2つ目の「コンテナ」は、アプリケーションとその動作に必要なライブラリ、依存関係をすべてひとまとまりにパッケージングし、ホストOSの上で独立したアプリケーションとして実行されるものである。コンテナの価値について森氏は3つあるという。1つ目はResource Isolation（リソースと責任の分離）、2つ目はRun Anywhere（環境を意識しない可搬性）、3つ目がImmutable Architecture（アプリケーションの再現性）である。

　ここで森氏は「マイクロサービスとコンテナの親和性についても一つ触れておきたいことがある」と言う。ビッグバンではなく、段階的な移行という戦略を採用した場合、アプリケーションの視点において、目指す姿はシステムの透明性が高く改修しやすいアーキテクチャとなり、それを可能にする一つの解がマイクロサービスである。一方で、マイクロサービス化を進めようと、インフラ視点の課題に立ち戻ると、モノリシックなシステムに最適化された標準化が定着しているという現状がある。その結果テクノロジーの変化に適した開発・運用プロセスではないため、小さい単位で頻繁に改修できる基盤の確立を目指していくことになる。

　「これを実現するには自ずとコンテナ基盤を採用することになる」と森氏。このようにマイクロサービスとコンテナは非常に相性が良く、「マイクロサービスをコンテナ環境で運用すると、柔軟性などのメリットが得られる反面、動作するコンテナの数が多くなりその管理が複雑になることがある」と森氏。この問題を解決するため、レッドハットではKubernetesコンテナプラットフォーム「OpenShift」を提供している。

　3つ目の「ストラングラーパターン」とは、特定の機能を新しいアプリケーションやサービスに徐々に置き換えることで、レガシーシステムを段階的に移行するためのデザインパターンである。レガシーシステムとユーザーのフロントエンドの間に、データを振り分ける役割を担うストラングラーファサードを設置し、ステップごとに一部の機能を切り出してマイクロサービス化し、新しいシステムとして稼働させていくのである。このような仕組みにすることで、「新旧にデータを振り分けることで、ユーザーは新旧を意識することなくシステムが利用できるというメリットがある」と森氏は説明する。このような方法で段階的にすべてのシステムをマイクロサービス化したところで、ストラングファサードを撤去し、移行は完了するというわけだ。

ストラングパターンでレガシーシステムを段階的に移行する

　ここで「マイクロサービス化したアプリケーションのデータ連携方式について考えていたい」と森氏。REST（同期通信）のみで構成した場合、どこかのサービスで障害が起こると、機能不全のサービスが下流に向かって発生し、サービス全体が機能不全に陥ってしまう。「リトライ処理や巻き戻しなど、障害時の対応が複雑化してしまう欠点がある」と森氏は指摘する。