SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 レポート(PR)

レガシーアプリケーションの段階的モダナイズに必要なテクノロジーとデザインパターン【デブサミ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(同期通信)のみで構成した場合、どこかのサービスで障害が起こると、機能不全のサービスが下流に向かって発生し、サービス全体が機能不全に陥ってしまう。「リトライ処理や巻き戻しなど、障害時の対応が複雑化してしまう欠点がある」と森氏は指摘する。

次のページ
イベント駆動型アーキテクチャの採用で、巨大な共有データベースを解体する

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
Developers Summit 2022 レポート連載記事一覧

もっと読む

この記事の著者

中村 仁美(ナカムラ ヒトミ)

 大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15733 2022/04/28 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング