マイクロサービス アーキテクチャ: 長所と短所

マイクロサービスは、大規模なアプリケーションを、単純な API を通じて相互に通信する疎結合モジュールに分割する方法です。 最近、マイクロサービスについて話さないのは愚かな人だけです。これはますます人気が高まっています。モジュール式アーキテクチャ スタイルはクラウドベースの環境に特に適しているようで、人気が高まっています。詳細に入る前に、すべてを俯瞰してみましょう。したがって、マイクロサービスは、大規模なプロジェクトを、独立した疎結合の小さなモジュールに分割する方法です。独立したモジュールは、明確に定義された個別のタスクを担当し、シンプルでアクセス可能な API を通じて相互に通信します。言い換えれば、マイクロサービスは、複雑な、主に Web アプリケーションを設計するための異なるアーキテクチャ スタイルにすぎません。しかし、SOA (サービス指向アーキテクチャ) などの既存のアーキテクチャ ソリューションの何がそんなに悪いのでしょうか? SOA を使用して作成された最新のエンタープライズ ソリューションのほとんどは、非常にうまく動作するようです。これは、業界が最近直面しているいくつかの課題について話す絶好の機会かもしれません...簡単な例から始めましょう。Java で書かれた従来のアプリケーションを実行する必要があるとします。まずユーザー インターフェイスを開発し、次に UI と対話するいくつかのコンポーネントを含むビジネス ロジック層を開発し、最後に永続データベースにアクセスできるデータベース層を開発します。ここで、アプリケーションを実行したいという事実に従って、WAR/EAR/JAR を作成し、サーバー (JBoss、Tomcat、WebLogic など) にマウントします。これはオールインワンで行われるため、モノリシックなアプリケーションが得られます。これは、すべてのコンポーネントが 1 か所にあることを意味します。画像の例: おそらく、皆さんはすでにこのアプローチに精通しており、使用したことがあると思いますが、この例を使用して、このアーキテクチャ ソリューションを使用すると開発者がどのような課題に直面することになるかを示すことが目的です。 モノリシック アプリケーション:課題への挑戦

• アプリケーションが成長するにつれて、記述されるコードの量も増加し、アプリケーションを開くたびに開発環境に過負荷がかかる可能性があります。これは明らかに開発者の効率を低下させます。
• すべてを 1 か所にマウントする必要があるため、別のプログラミング言語への切り替えや他のテクノロジへの切り替えが大きな問題になります。たとえば、Java でアプリケーションを作成し、しばらくして Kotlin が登場し、Kotlin の方がクールで優れており、高速であると宣伝されたため、Kotlin に書き直そうとしたとします。モノリシック アプリケーションでは、プロセス自体は言うまでもなく、リファクタリングについて考えるだけでも大きな苦痛を伴うことになります。現在、この方法で作成されたアプリケーションが数多くあり、そのコード行数は信じられないほどです。
• いずれかのコンポーネントが何らかの理由で動作を停止すると、アプリケーション全体もクラッシュします。認証、支払い、履歴などのモジュールを備えた Web アプリケーションがあると想像してください。そして何らかの理由でそのうちの1つが壊れます。これはビジネスにとって、そして結果として開発者にとっては単なるショックです。
• モノリシック アプリケーションのスケーリングは、同じタイプの別のアプリケーションを起動することによってのみ実現できます。しかし、アプリケーション全体ではなく、1 つのコンポーネントのみをスケールする必要がある場合はどうなるでしょうか。どれだけの資源が無駄になるのでしょうか...
• これは、アプリケーションの開発プロセスとインストール プロセスに大きな影響を与える可能性があります。アプリケーションが大規模であればあるほど、開発者がアプリケーションをより小さな作業部分に分割できることがより重要になります。モノリシック アプリケーション内のすべてのモジュールは相互に接続されているため、開発者はこれらのモジュールを相互に独立して作業したりマウントしたりすることはできません。開発者は互いに依存しているため、開発時間が長くなります。

同時に、マイクロサービスの意味、つまり、SOA スタイルで失われた柔軟性を取り戻すためにマイクロサービスをどのように使用できるかを検討し、理解する準備ができています。 神のマイクロサービスが救いの手を差し伸べる アーキテクチャ ソリューションにおける最も重要な特性の 1 つはスケーラビリティです。初めてマイクロサービスを学んだとき、すべてが「The Art of Scalability」という本からの引用に非常に似ていることがわかりました。これは素晴らしい出発点であり、議論の場でもあります。この本では、3 次元のスケーラビリティ システムを説明する、いわゆる「スケーラビリティ キューブ」モデルを定義します。 ご覧のとおり、X 軸は「水平スケーリング」(モノリシック アーキテクチャでも利用可能であることがわかりました) を表し、Y 軸はさまざまなサービスコンポーネントを分離するという意味でのスケーリングを表します。Z 軸の概念は、データが分割され、アプリケーションがデータが存在する正確な場所にリクエストを送信するときに理解されます。つまり、それらはすべて 1 か所にあるわけではありません。Y 軸の考え方については、後で詳しく説明します。この軸は機能的分解を表します。この戦略では、さまざまな機能を独立したサービスとして考えることができます。したがって、すべてが完了した場合にのみアプリケーション全体をマウントすることで、開発者は個々のサービスを互いに独立してマウントでき、他のサービスがモジュールでの作業を完了するのを待たずに済みます。これにより、開発時間が短縮されるだけでなく、アプリケーション コンポーネントの残りの部分を気にすることなく、変更や再配線を行う柔軟性も得られます。この図を前のモノリシック図と比較してみましょう。 マイクロサービス: 利点 マイクロサービスの利点は、Amazon、Netflix、Ebay などのエンタープライズ開発者にこのアプローチの使用を開始させるのに十分であると思われます。モノリシック アーキテクチャ アプリケーションとは異なり、マイクロサービスは次のことを行います。

• コンポーネント障害の分離の向上: 単一のモジュールに障害が発生した場合でも、大規模なアプリケーションは効率的に実行し続けることができます。
• アプリケーションが 1 つのテクノロジー スタックにコミットする必要がなくなります。何らかのサービスで新しいテクノロジー スタックを試したい場合は、先に進んでください。依存関係はモノリシックなものよりもはるかに軽くなり、すべてをロールバックすることもはるかに簡単になります。1 つのアプリケーション内のコードが少ないほど、作業が簡単になります。
• 新入社員がサービスの機能を理解しやすくなります。

マイクロサービス: マウントと仮想化の機能 マイクロサービスとは何かを理解しました。そして最大の利点は、複数の WAR/EAR/JAR アーカイブによってマウントされることです。しかし、どのように設置されるのでしょうか？コンテナ内にマイクロサービスをマウントする最良の方法。コンテナーは、必要な環境が構成された完全に構成された仮想オペレーティング システムであり、コンテナーがインストールされているハードウェア システムのリソースへのアクセスを分離するのに役立ちます。市場で最も有名なソリューションは、もちろんDockerです。AWS などの IaaS (サービスとしてのインフラストラクチャ) の仮想マシンもマイクロサービスのマウントには問題なく機能しますが、比較的軽量なマイクロサービスは仮想マシン内のすべてのリソースを使用しない可能性があり、使用の収益性が低下する可能性があります。OSGI (Open Service Gateway Initiative) パッケージを使用してマイクロサービスをマウントすることもできます。この場合、すべてのマイクロサービスは単一の JVM で実行されますが、これには制御と分離の間のトレードオフの問題が伴います。 マイクロサービス: デメリット 「これはすばらしい」「これまで見たことがない」というだけで、デメリットがないわけではありません。以下は、マイクロサービス アーキテクチャによって引き起こされる可能性のある問題領域のリストです。

• 分散システムの開発は難しい場合があります。これは、すべてのコンポーネントが独立したサービスになったことを意味します。モジュール間で受け渡されるリクエストを非常に注意深く処理する必要があります。1 つのモジュールが応答せず、システムのクラッシュを避けるために追加のコードを作成する必要があるシナリオが考えられます。リモート呼び出しが遅延の影響を受けやすい場合、これはさらに困難になる可能性があります。
• 複数のデータベースとトランザクションの管理は非常に面倒な場合があります。
• マイクロサービス アプリケーションのテストは面倒な場合があります。モノリシック アプリケーションを使用すると、サーバー上で WAR/EAR/JAR アーカイブを実行し、それがデータベースに接続されていることを確認するだけで済みます。また、マイクロサービスでは、テストを開始する前に個々のサービスを開始する必要があります。
• アプリケーションのマウントは難しい場合があります。WAR コンテナほど簡単にマウントできない可能性がある複数のサービスに関する調整が必要になる場合があります。

.... もちろん、適切なツールとアプローチを使用すれば、これらの欠点は回避できます。しかし、それら自体にはサポートが必要であり、すべての問題を完全に解決するわけではありません。この記事はCloudAcademy Web サイトから翻訳されたものです。無料翻訳。誰もがコメントで自由に自分の考えを表現できます。間違いなく読まれるでしょう。 元の記事 私の Github アカウント