要件定義の不安をなくす。要件定義の不安をなくす。ユニファのバックエンド分割に学ぶイノベーションメタバース開発に必要な技術の基本知識をおさらい。Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。12:00デブサミイベントレポートアプリケーション開発ツイート多くの企業が今、DXに取り組んでいる。その際に課題になるのが、レガシーアプリケーションのモダナイズだ。巨大であればあるほど、立ちはだかる壁が多数あり、なかなか手をつけられず悩んでいる企業も多い。そんな企業に対して、レッドハットは、段階的にモダナイズへ移行することを提案。どんなテクノロジーやデザインパターンを使って、段階的移行を行っていくのか。レッドハットのソリューションアーキテクトである森和哉氏が解説した。段階的移行に必要なテクノロジーとデザインパターン「今、アプリケーションモダナイズへの関心は非常に高まっている」こう語り、森氏のセッションは始まった。アプリモダナイズへの関心が高まっている背景には、「データ量や利用者の増加に対応したい」「大幅に増えた保守コストを削減したい」「ブラックボックスを見える化したい」などさまざまな理由があるが、「強調したいのは柔軟かつ迅速に、変更対応が可能なシステムにしたいということ」と森氏は語る。ビジネスで優位に立つには、スピードとアジリティが非常に重要になるからだ。「アプリモダナイズに至る道は険しい」と森氏は言う。「密結合したモノリシックなシステムなので、簡単に分割できそうもない「組織も文化もウォーターフォール開発が前提となっており、そう簡単に変えられない」「モダンな技術や手法を取り入れるのが難しそう」など、アプリモダナイズに取り組みたくても、なかなか踏み切れない理由が多々あるという。モダナイズへの移行方式は「一括移行」と「段階的移行」の2種類ある。一括移行方式は一度にすべてを移行してしまうため、うまくいけばコストも時間もかからない。あれば、一括移行に比べてトータルコストは高く、工期も長くなるが、難易度やリスクも下がる。小さな効果を確認しつつ導入範囲を決定できるので、「現実的には段階的移行を選択することをお勧めする」と森氏は説明する。この段階的移行を実現するために森氏は、「マイクロサービス」「コンテナ」「ストラングラーパターン」「イベント駆動型アーキテクチャ」というテクノロジーとデザインパターンが必要になるという。1つ目の「マイクロサービス」。マイクロサービスが必要なのか。従来のアプリケーションはUI層、ビジネスロジック層、データアクセス層の3層で構成されたモノリシックなアーキテクチャを採用していた。このモノリシックなアーキテクチャのデメリットは、「密結合になっているため、小さな変更であっても層全体でのテストやデプロイのやり直しが必要になる。1つのデータベースを共有しているために、データが肥大化してボトルネックになりやすいという課題があった」と森氏は説明する。それに対してマイクロサービスは、UIやビジネスロジック、データアクセスという機能単位で小さなサービスとして定義する。それらの互いに独立した小さなサービス(機能)が連動することで、1つのアプリケーションとして動作するアーキテクチャである。「従来のモノリシックなアプリケーションとは異なり、サービスが小さく自律的であるため、素早く開発してデリバリーできるのがメリットです。ビジネスのアジリティを上げていくためには、マイクロサービスへと変えていくことが重要になると思います」(森氏)2つ目の「コンテナ」は、アプリケーションとその動作に必要なライブラリ、依存関係をすべてひとまとまりにパッケージングし、ホストOSの上で独立したアプリケーションとして実行されるものである。コンテナの価値について森氏は3つあるという。Architecture(アプリケーションの再現性)である。ここで森氏は「マイクロサービスとコンテナの親和性についても一つ触れておきたいことがある」と言う。ビッグバンではなく、段階的な移行という戦略を採用した場合、アプリケーションの視点において、目指す姿はシステムの透明性が高く改修しやすいアーキテクチャとなり、それを可能にする一つの解がマイクロサービスである。一方で、マイクロサービス化を進めようと、インフラ視点の課題に立ち戻ると、モノリシックなシステムに最適化された標準化が定着しているという現状がある。その結果テクノロジーの変化に適した開発・運用プロセスではないため、小さい単位で頻繁に改修できる基盤の確立を目指していくことになる。「これを実現するには自ずとコンテナ基盤を採用することになる」と森氏。このようにマイクロサービスとコンテナは非常に相性が良く、「マイクロサービスをコンテナ環境で運用すると、柔軟性などのメリットが得られる反面、動作するコンテナの数が多くなりその管理が複雑になることがある」と森氏。この問題を解決するため、レッドハットではKubernetesコンテナプラットフォーム「OpenShift」を提供している。3つ目の「ストラングラーパターン」とは、特定の機能を新しいアプリケーションやサービスに徐々に置き換えることで、レガシーシステムを段階的に移行するためのデザインパターンである。レガシーシステムとユーザーのフロントエンドの間に、データを振り分ける役割を担うストラングラーファサードを設置し、ステップごとに一部の機能を切り出してマイクロサービス化し、新しいシステムとして稼働させていくのである。このような仕組みにすることで、「新旧にデータを振り分けることで、ユーザーは新旧を意識することなくシステムが利用できるというメリットがある」と森氏は説明する。このような方法で段階的にすべてのシステムをマイクロサービス化したところで、ストラングファサードを撤去し、移行は完了するというわけだ。ストラングパターンでレガシーシステムを段階的に移行するここで「マイクロサービス化したアプリケーションのデータ連携方式について考えていたい」と森氏。REST(同期通信)のみで構成した場合、どこかのサービスで障害が起こると、機能不全のサービスが下流に向かって発生し、サービス全体が機能不全に陥ってしまう。「リトライ処理や巻き戻しなど、障害時の対応が複雑化してしまう欠点がある」と森氏は指摘する。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。趣味は読書、ドライブ、城探訪(日本の城)。3.12」の最初のベータ版がリリース新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。