モノリスをマイクロサービスにリファクタリングする

編集者– この 7 部構成の記事シリーズはこれで完了です。

1. マイクロサービス入門
2. マイクロサービスの構築: APIゲートウェイの使用
3. マイクロサービスの構築: マイクロサービス アーキテクチャにおけるプロセス間通信
4. マイクロサービス アーキテクチャにおけるサービス検出
5. マイクロサービス向けイベント駆動型データ管理
6. マイクロサービス導入戦略の選択
7. モノリスをマイクロサービスにリファクタリングする (この記事)

また、記事の完全なセットと、NGINX Plus を使用したマイクロサービスの実装に関する情報を電子書籍「マイクロサービス」としてダウンロードすることもできます。 設計から展開まで。 また、マイクロサービス リファレンス アーキテクチャとマイクロサービス ソリューション ページに関するシリーズもご覧ください。

これは、マイクロサービスを使用したアプリケーションの構築に関するシリーズの 7 番目で最後の記事です。 最初の記事では、マイクロサービス アーキテクチャ パターンを紹介し、マイクロサービスを使用する利点と欠点について説明します。 以下の記事では、API ゲートウェイの使用、プロセス間通信、サービス検出、イベント駆動型データ管理、マイクロサービスのデプロイなど、マイクロサービス アーキテクチャのさまざまな側面について説明します。 この記事では、モノリシック アプリケーションをマイクロサービスに移行するための戦略について説明します。

この一連の記事を通じて、マイクロサービス アーキテクチャ、その利点と欠点、そしていつ使用するかについて理解を深めていただけたら幸いです。 おそらく、マイクロサービス アーキテクチャはあなたの組織に適しているでしょう。

ただし、大規模で複雑なモノリシック アプリケーションに取り組んでいる可能性はかなり高いです。 アプリケーションの開発と展開の日々の作業は時間がかかり、苦痛です。 マイクロサービスは遠い涅槃のように思えます。 幸いなことに、この巨大な地獄から脱出するために使える戦略が存在します。 この記事では、モノリシック アプリケーションを段階的にマイクロサービスのセットにリファクタリングする方法について説明します。

マイクロサービスへのリファクタリングの概要

モノリシック アプリケーションをマイクロサービスに変換するプロセスは、アプリケーションのモダナイゼーションの一形態です。 それは開発者が何十年も行ってきたことです。 その結果、アプリケーションをマイクロサービスにリファクタリングするときに再利用できるアイデアがいくつかあります。

使用しない戦略の 1 つは、「ビッグバン」の書き換えです。 それは、すべての開発努力を、マイクロサービス ベースの新しいアプリケーションをゼロから構築することに集中する場合です。 魅力的に聞こえますが、非常にリスクが高く、失敗に終わる可能性が高いです。 伝えられるところによると、マーティン・ファウラーは「ビッグバンの書き換えで保証されるのはビッグバンだけだ！」と言ったそうです。

ビッグバンによる書き換えではなく、モノリシック アプリケーションを段階的にリファクタリングする必要があります。 マイクロサービスで構成される新しいアプリケーションを徐々に構築し、モノリシック アプリケーションと組み合わせて実行します。 時間が経つにつれて、モノリシック アプリケーションによって実装される機能の量は減少し、最終的には完全に消滅するか、単なる別のマイクロサービスになります。 この戦略は、高速道路を時速 70 マイルで走行しながら車の整備を行うのに似ています。困難ではありますが、ビッグバンの書き換えを試みるよりははるかにリスクが低くなります。

Martin Fowler は、このアプリケーション モダナイゼーション戦略をStrangler アプリケーションと呼んでいます。 名前は熱帯雨林に生息する絞め殺しのつる植物（別名絞め殺しのイチジク）に由来しています。 絞め殺しのつる植物は、森林の樹冠の上の日光に届くように、木の周囲に成長します。 時々、木が枯れて、木の形をした蔓が残ることがあります。 アプリケーションの最新化も同じパターンに従います。 最終的には廃止されるレガシー アプリケーションを中心に、マイクロサービスで構成された新しいアプリケーションを構築します。

これを実現するためのさまざまな戦略を見てみましょう。

戦略1 – 掘るのをやめる

穴の法則によれば、穴に落ちたときは掘るのをやめるべきです。 これは、モノリシック アプリケーションが管理不能になったときに従うべき優れたアドバイスです。 言い換えれば、モノリスを大きくするのをやめるべきです。 つまり、新しい機能を実装するときには、モノリスにコードを追加しないでください。 代わりに、この戦略の大きなアイデアは、新しいコードをスタンドアロンのマイクロサービスに配置することです。 次の図は、このアプローチを適用した後のシステム アーキテクチャを示しています。

新しいサービスとレガシー モノリスの他に、他に 2 つのコンポーネントがあります。 1 つ目は、着信 (HTTP) リクエストを処理するリクエスト ルーターです。 これは、以前の記事<.htmla>で説明した API ゲートウェイに似ています。 ルータは、新しい機能に対応する要求を新しいサービスに送信します。 レガシー リクエストをモノリスにルーティングします。

もう 1 つのコンポーネントは、サービスをモノリスと統合するグルー コードです。 サービスは孤立して存在することはほとんどなく、モノリスが所有するデータにアクセスする必要があることがよくあります。 モノリス、サービス、またはその両方に存在するグルー コードは、データ統合を担当します。 サービスはグルーコードを使用して、モノリスが所有するデータを読み書きします。

サービスがモノリスのデータにアクセスするために使用できる戦略は 3 つあります。

• モノリスが提供するリモートAPIを呼び出す
• モノリスのデータベースに直接アクセスする
• モノリスのデータベースと同期されたデータの独自のコピーを維持する

グルー コードは、破損防止レイヤーと呼ばれることもあります。 これは、グルー コードによって、独自の純粋なドメイン モデルを持つサービスが、従来のモノリスのドメイン モデルの概念によって汚染されるのを防ぐためです。 グルーコードは 2 つの異なるモデル間で変換を行います。 破損防止レイヤーという用語は、Eric Evans の必読書「ドメイン駆動設計」で初めて登場し、その後ホワイト ペーパーで改良されました。 腐敗防止層の開発は、決して簡単な作業ではありません。 しかし、モノリス地獄から抜け出して成長したいのであれば、それを作成することが不可欠です。

新しい機能を軽量サービスとして実装することには、いくつかの利点があります。 モノリスがさらに管理不能になることを防ぎます。 サービスはモノリスから独立して開発、展開、拡張できます。 新しいサービスを作成するたびに、マイクロサービス アーキテクチャの利点を実感できます。

ただし、このアプローチではモノリスの問題は解決されません。 これらの問題を解決するには、モノリスを分割する必要があります。 そのための戦略を見てみましょう。

戦略2 – フロントエンドとバックエンドを分割する

モノリシック アプリケーションを縮小する戦略は、プレゼンテーション層をビジネス ロジック層およびデータ アクセス層から分離することです。 一般的なエンタープライズ アプリケーションは、少なくとも 3 種類のコンポーネントで構成されます。

• プレゼンテーション層 – HTTP リクエストを処理し、(REST) API または HTML ベースの Web UI のいずれかを実装するコンポーネント。高度なユーザー インターフェイスを持つアプリケーションでは、プレゼンテーション層は多くの場合、大量のコードで構成されます。
• ビジネス ロジック レイヤー – アプリケーションの中核となり、ビジネス ルールを実装するコンポーネント。
• データ アクセス レイヤー – データベースやメッセージ ブローカーなどのインフラストラクチャ コンポーネントにアクセスするコンポーネント。

通常、一方のプレゼンテーション ロジックと、もう一方のビジネス ロジックおよびデータ アクセス ロジックの間には明確な分離があります。 ビジネス層には、ビジネス ロジック コンポーネントをカプセル化する 1 つ以上のファサードで構成される粗粒度の API があります。 この API は、モノリスを 2 つの小さなアプリケーションに分割できる自然な継ぎ目です。 1 つのアプリケーションにはプレゼンテーション層が含まれます。 もう一方のアプリケーションには、ビジネス ロジックとデータ アクセス ロジックが含まれています。 分割後、プレゼンテーション ロジック アプリケーションはビジネス ロジック アプリケーションに対してリモート呼び出しを実行します。 次の図は、リファクタリング前とリファクタリング後のアーキテクチャを示しています。

このようにモノリスを分割すると、主に 2 つの利点があります。 これにより、2 つのアプリケーションを互いに独立して開発、展開、拡張できるようになります。 特に、プレゼンテーション層の開発者は、ユーザー インターフェイスを迅速に反復し、A/B テストなどを簡単に実行できるようになります。 このアプローチのもう 1 つの利点は、開発したマイクロサービスから呼び出すことができるリモート API を公開することです。

しかし、この戦略は部分的な解決策にすぎません。 アプリケーションの 1 つまたは両方が管理不能なモノリスになる可能性が非常に高くなります。 残りのモノリスを削除するには、3 番目の戦略を使用する必要があります。

戦略3 – サービスの抽出

3 番目のリファクタリング戦略は、モノリス内の既存のモジュールをスタンドアロンのマイクロサービスに変換することです。 モジュールを抽出してサービスに変換するたびに、モノリスは縮小されます。 十分な数のモジュールを変換すると、モノリスは問題ではなくなります。 完全に消滅するか、あるいは小さくなって単なる別のサービスになってしまうかのどちらかです。

どのモジュールをサービスに変換するかの優先順位付け

大規模で複雑なモノリシック アプリケーションは数十または数百のモジュールで構成されており、そのすべてが抽出の候補となります。 どのモジュールを最初に変換するかを判断するのは、多くの場合困難です。 良いアプローチとしては、抽出しやすいいくつかのモジュールから始めることです。 これにより、マイクロサービス全般、特に抽出プロセスに関する経験が得られます。 その後、最大のメリットをもたらすモジュールを抽出する必要があります。

モジュールをサービスに変換するには、通常、時間がかかります。 得られるメリットに応じてモジュールをランク付けします。 通常、頻繁に変更されるモジュールを抽出すると有益です。 モジュールをサービスに変換すると、モノリスから独立して開発およびデプロイできるため、開発が加速します。

また、モノリスの残りの部分とはリソース要件が大きく異なるモジュールを抽出することも有益です。 たとえば、メモリ内データベースを持つモジュールをサービスに変換し、大量のメモリを搭載したホストにデプロイできるようにすると便利です。 同様に、計算コストの高いアルゴリズムを実装するモジュールを抽出すると、多数の CPU を搭載したホストにサービスを展開できるため、価値があります。 特定のリソース要件を持つモジュールをサービスに変換することで、アプリケーションのスケーリングがはるかに簡単になります。

どのモジュールを抽出するかを判断するときは、既存の粗粒度の境界 (別名、継ぎ目) を探すと便利です。 モジュールをサービスに変換することがより簡単かつ安価になります。 このような境界の例としては、非同期メッセージを介してのみアプリケーションの残りの部分と通信するモジュールが挙げられます。 そのモジュールをマイクロサービスに変換するのは比較的安価で簡単です。

モジュールの抽出方法

モジュールを抽出する最初のステップは、モジュールとモノリス間の粗粒度のインターフェースを定義することです。 モノリスはサービスが所有するデータを必要とし、その逆も同様であるため、これは双方向 API になる可能性が高くなります。 モジュールとアプリケーションの残りの部分との間の依存関係が複雑で、相互作用パターンが細かいため、このような API を実装するのは困難な場合がよくあります。 ドメイン モデル パターンを使用して実装されたビジネス ロジックは、ドメイン モデル クラス間の関連付けが多数あるため、リファクタリングが特に困難です。 多くの場合、これらの依存関係を解消するには、大幅なコード変更が必要になります。 次の図はリファクタリングを示しています。

粗粒度のインターフェースを実装したら、モジュールを独立したサービスに変換します。 そのためには、モノリスとサービスがプロセス間通信(IPC) メカニズムを使用する API を介して通信できるようにするコードを記述する必要があります。 次の図は、リファクタリング前、リファクタリング中、リファクタリング後のアーキテクチャを示しています。

この例では、モジュール Z が抽出する候補モジュールです。 そのコンポーネントはモジュール X によって使用され、モジュール Y が使用されます。最初のリファクタリング手順は、粗粒度の API のペアを定義することです。 最初のインターフェースは、モジュール X がモジュール Z を呼び出すために使用するインバウンド インターフェースです。2 番目は、モジュール Z がモジュール Y を呼び出すために使用するアウトバウンド インターフェースです。

2 番目のリファクタリング手順では、モジュールをスタンドアロン サービスに変換します。 インバウンドおよびアウトバウンド インターフェイスは、IPC メカニズムを使用するコードによって実装されます。 おそらく、モジュール Z と、サービス検出などの横断的な問題を処理するマイクロサービス シャーシ フレームワークを組み合わせてサービスを構築する必要があるでしょう。

モジュールを抽出すると、モノリスや他のサービスとは独立して開発、デプロイ、スケーリングできる別のサービスが手に入ります。 サービスを最初から書き直すこともできます。この場合、サービスをモノリスと統合する API コードは、2 つのドメイン モデル間の変換を行う破損防止レイヤーになります。 サービスを抽出するたびに、マイクロサービスに向けて新たな一歩を踏み出します。 時間が経つにつれて、モノリスは縮小し、マイクロサービスの数は増加します。

まとめ

既存のアプリケーションをマイクロサービスに移行するプロセスは、アプリケーションのモダナイゼーションの一形態です。 アプリケーションを最初から書き直してマイクロサービスに移行すべきではありません。 代わりに、アプリケーションを段階的にリファクタリングしてマイクロサービスのセットにする必要があります。 使用できる戦略は 3 つあります。新しい機能をマイクロサービスとして実装する、プレゼンテーション コンポーネントをビジネス コンポーネントおよびデータ アクセス コンポーネントから分割する、モノリス内の既存のモジュールをサービスに変換する、です。 時間が経つにつれてマイクロサービスの数が増え、開発チームの俊敏性と速度が向上します。

編集者– この 7 部構成の記事シリーズはこれで完了です。

1. マイクロサービス入門
2. マイクロサービスの構築: APIゲートウェイの使用
3. マイクロサービスの構築: マイクロサービス アーキテクチャにおけるプロセス間通信
4. マイクロサービス アーキテクチャにおけるサービス検出
5. マイクロサービス向けイベント駆動型データ管理
6. マイクロサービス導入戦略の選択
7. モノリスをマイクロサービスにリファクタリングする (この記事)

また、記事の完全なセットと、NGINX Plus を使用したマイクロサービスの実装に関する情報を電子書籍「マイクロサービス」としてダウンロードすることもできます。 設計から展開まで。 また、マイクロサービス リファレンス アーキテクチャとマイクロサービス ソリューション ページに関するシリーズもご覧ください。

ゲストブロガーの Chris Richardson 氏は、Amazon EC2 向けの初期の Java PaaS (Platform as a Service) であるオリジナルのCloudFoundry.comの創設者です。 彼は現在、アプリケーションの開発および展開方法の改善について組織にコンサルティングを行っています。 彼はまた、 https://microservices.ioでマイクロサービスに関するブログを定期的に書いています。