「マイクロサービスはクール」という罠に陥らず、モノリスに固執すべきタイミングを知る

モノリスとマイクロサービスは、アプリケーションを構築するための 2 つの基本的なアプローチです。それぞれをレガシーとモダンと考える人もいます。しかし、これは正確ではありません。どちらを選択するかは非常に複雑な問題であり、どちらにも長所と短所があります。

新しいアプリケーションのほとんどは、最初からマイクロサービスである必要はありません。モノリスとして開始し、メリットが見つかれば後でマイクロサービスに切り替える方が、より速く、より簡単で、安価です。

時間が経つにつれて、モノリス アプリケーションの保守性はどんどん低下し、一部のチームは、問題を解決する唯一の方法は、アプリケーションをマイクロサービスに分割してリファクタリングを開始することだと判断します。他のチームは、単に「マイクロサービスがクール」という理由でこの決定を下します。このプロセスには多くの時間がかかり、場合によっては保守のオーバーヘッドがさらに増えます。これに取り組む前に、すべての長所と短所を慎重に検討し、現在のモノリス アーキテクチャの限界に達していることを確認することが重要です。また、構築するよりも破壊する方が簡単であることを覚えておいてください。

この記事では、モノリスとマイクロサービスを比較するのではなく、次の点に役立つ考慮事項、パターン、原則について説明します。

• 現在のモノリスを最大限に活用し、マイクロサービスへの移行に備えます。
• モノリスからマイクロサービスへのシームレスな移行を実現します。
• マイクロサービス移行によって他に何が変わる可能性があるかを理解します。

モジュラーモノリス

最初にすべきことは、プロジェクト構造を確認することです。モジュールがない場合は、モジュールを検討することを強くお勧めします。モジュールはアーキテクチャをマイクロサービスに変更する必要はありませんが (関連するメンテナンスをすべて回避したいので、これは良いことです)、多くの利点があります。

プロジェクト ビルド自動化ツール (Maven、Gradle など) に応じて、プロジェクトを個別の独立したモジュールに分割できます。一部のモジュールは他のモジュールと共通である一方、他のモジュールは特定のドメイン領域をカプセル化したり機能固有のものであったりして、アプリケーションに独立した機能をもたらします。

次のようなメリットが得られます。

1. アプリケーションの分離された部分。
2. 機能は独立して開発できるため、競合が最小限に抑えられます。
3. 新しいメンバーはプロジェクト全体を深く掘り下げる必要がなく、個別の部分から始めることができるため、オンボーディングがはるかに簡単になります。
4. 各モジュールを個別にテストできるようになり、テストが改善されました。
5. 最終的にマイクロサービスに移行する必要がある場合、そのための非常に強力な基盤が得られます。

ご覧のとおり、モジュール式モノリスは両方の長所を活かす方法です。これは、単一のモノリス内で独立したマイクロサービスを実行するようなものですが、付随的なマイクロサービスのオーバーヘッドは回避されます。制約の 1 つは、異なるモジュールを個別に拡張できないことです。最も負荷の高いモジュールに必要な数のモノリス インスタンスが存在するため、リソースの消費が過剰になる可能性があります。もう 1 つの欠点は、異なるテクノロジを使用することによる制約です。たとえば、モジュール式モノリスで Java、Golang、Python を混在させることはできないため、1 つのテクノロジに固執せざるを得ません (通常は問題にはなりません)。

絞め殺しのイチジクのパターン

ストラングラー・フィグ・パターンについて考えてみましょう。これは、ホストを包み込み、最終的にホストを置き換える木にちなんで名付けられました。同様に、このパターンは、レガシー アプリケーションの一部を新しいサービスに 1 つずつ置き換え、大きな混乱を引き起こすことなく古いシステムを最新化することを提案しています。

リスクの高い、一度にすべてをオーバーホールする代わりに、システムを少しずつ更新します。この方法は、1 回の作業で置き換えるには扱いにくい、大規模で複雑なモノリスを扱う場合に役立ちます。ストラングラー フィグ パターンを採用することで、チームは古いシステムを段階的に廃止しながら、新しいシステムの成長を促進し、リスクを最小限に抑え、価値を継続的に提供することができます。

ストラングラー・フィグ・パターンを実装するには、次の 3 つの手順に従う必要があります。

1. 変換。ここでは、モノリスから抽出する部分を特定し、それを別のマイクロサービスとして実装します。この部分を最新のテクノロジーを使用して書き直し、以前の実装の問題に対処します。より良いものにするチャンスをつかみましょう。
2. 共存。新しいマイクロサービスが本番環境の準備ができたら、レガシー実装を維持しながら、インフラストラクチャでそれを実行します。トラフィックを一定の割合で分散し、徐々に多くのトラフィックを新しい実装に移動しますが、以前のバージョンは常にロールバックとして保持されます。
3. 排除します。しばらくして、新しいマイクロサービスが十分に信頼できると判断されたら、すべてのトラフィックを新しいマイクロサービスに移動し、レガシーを削除します。

これら 3 つの手順を実行することで、モノリスを徐々にマイクロサービスに分割します。

ストラングラー・フィグ・パターンを使用する主な利点は次のとおりです。

• 段階的な移行。このパターンでは、問題が発生して、タイムリーで圧倒的かつリスクの高い完全なシステム オーバーホールを開始するのではなく、段階的に移行できます。システムをゆっくりと更新し、この変換を機能開発計画と同期させることができます。たとえば、機能開発によって重大な影響を受けるモノリスの部分を見つけて、それをマイクロサービス移行の候補として選択できます。
• 継続的デリバリー。この利点は、前の説明から来ています。モダナイゼーション プロセスは、チームが新しい機能を継続的に提供することを妨げるものではありません。あるチームが新しい機能を開発している間、別のチームが独立したモジュールをリファクタリングします。
• リスクの軽減。ストラングラー フィグ パターンは、チームがシステムの特定の部分の最新化に集中するのに役立ちます。この集中により、チームは特定の領域の詳細に細心の注意を払い、潜在的な問題を早期に発見し、アプリケーションへの全体的な影響を最小限に抑えることができます。

問題点と検討事項

ストラングラー フィグ パターンを適用する場合は、移行戦略を慎重に計画する必要があります。これには、最初に交換するコンポーネントの特定、古い部分と新しい部分の適切な統合の確保、一貫性のあるデータ モデルの維持などが含まれます。また、チームは、各交換の進行状況と影響を追跡するための明確なコミュニケーション チャネルと監視システムを確立する必要があります。

マイクロサービス移行の影響

先ほど説明したように、マイクロサービスへの移行にはメリットがあります。しかし、他の多くのことがより困難になり、コストも高くなります。

たとえば、QA チームと開発チームは、複数のマイクロサービスをローカルで実行する機能が制限されているため、ローカル マシンでテストできなくなる状況に直面する可能性があります。または、1 つのサービスが 1 つのフローを処理するのではなく、複数のサービスがフローを処理するようになったため、ログの洞察力が低下する可能性があります。その結果、完全なログ シーケンスを表示するには、適切なインストルメンテーションとトレースを実装する必要があります。

マイクロサービス変革を開始する前に考慮し、計画する必要があるいくつかの重要な側面について説明しましょう。

展開とインフラストラクチャ

モノリスとマイクロサービスでは、最小限のインフラストラクチャ要件が異なります。

モノリス アプリケーションを実行する場合、通常はよりシンプルなインフラストラクチャを維持できます。仮想マシンや PaaS ソリューション (AWS EC2 など) などのオプションで十分です。また、スケーリング、構成、アップグレード、監視の多くを手動またはシンプルなツールで処理できます。その結果、複雑なインフラストラクチャのセットアップを回避し、DevOps の専門知識を必要とせずに開発者やサポート エンジニアに頼ることができます。

しかし、マイクロサービス アーキテクチャを採用すると、この状況は変わります。サービスの数が増えると、手動の実践的なアプローチはすぐに非現実的になります。複数のサービスを効果的にオーケストレーション、拡張、管理するには、Kubernetes などの専用プラットフォーム、または少なくともマネージド コンテナ サービスが必要になり、新たな複雑さと運用上の要求が生じます。

プラットフォーム層

モノリス アプリケーションの保守は比較的簡単です。CVE が発生した場合は、影響を受ける依存関係を 1 か所で更新します。外部サービス通信を標準化する必要がありますか? 単一のラッパーを実装し、コードベース全体で再利用します。

マイクロサービス環境では、これらの単純なタスクがはるかに複雑になります。以前は簡単だった作業が、今ではライフサイクルと依存関係を持つ複数の独立したサービス間での変更の調整を必要とします。複雑さが増すと、時間とリソースの両方のコストが増加します。そして、多くのチームと多くの異なるサービスがある場合、状況はさらに悪化します。

そのため、多くの組織では専用のプラットフォーム レイヤーを導入しており、通常はプラットフォーム チームによって管理されます。目標は、共通の依存関係の管理、標準化されたパターンの実装、既製のラッパーの提供など、すべてのマイクロサービスが継承できる基盤を作成することです。これらの要素をプラットフォーム レベルで統合することで、メンテナンスが大幅に簡素化され、システム全体の一貫性が促進されます。

結論

モノリスをマイクロサービスに分割することは、慎重な検討と計画を必要とする重要なアーキテクチャ変革です。

この記事では、準備してプロセスをスムーズに進めるための手順について説明しました。ストラングラー フィグ パターンに従うことで、増分プロセスが提供され、変換全体を通じてシステムの安定性が確保されます。また、モジュール モノリスは、準備手順として役立つだけでなく、マイクロサービス変換の決定を再検討し、それに伴う運用の複雑さを回避するきっかけとなるメリットももたらします。