アプリケーション開発におけるマイクロサービス アーキテクチャ: 長所と短所

序章

現代の経済では、ソフトウェアの作成は産業全体です。一方で、企業がすべてのプロセスを自動化およびデジタル化するのに役立ち、他方では、利益を上げて仮想資産を作成します。現在、R&D はより複雑になり、プログラマーの数は増え続け、IT タスクはより複雑になっています。

これらの理由により、新しいソフトウェア開発方法論とアーキテクチャの種類が出現しました。

最新の Web アプリケーションは多機能であり、デジタル トランスフォーメーションによってソフトウェアの要件が増えています。アプリケーションは、簡単に拡張でき、柔軟でクロスプラットフォームであり、ユーザー タスクに合わせて変更できる必要があります。タスク マネージャーは、そのようなソフトウェアを開発する段階でこれらの要件を設定します。

まず、現代のビジネス向けのソフトウェアを作成するには、ソフトウェア開発プロセスを真剣に研究し、適切なアーキテクチャを選択する必要があります。

ソフトウェア開発におけるアーキテクチャの選択

原則として、以前はすべてのアプリケーションがモノリシック アーキテクチャに基づいて開発されていました。モノリス アプリケーションとは何かを見てみましょう。

モノリシック アプリは全体として開発されます。リクエストを処理するためのロジックは、単一のプロセス内に配置されます。

モノリス Web アプリは、モジュールとブロックの形式で構造化できます。使用するプログラミング言語に応じて、個別のクラス、関数などが使用されます。しかし、モジュール間の接続は非常に強力です。

これは、次の結論につながります。モジュールを変更すると、アプリケーション全体の動作に大きな影響を与えます。

たとえば、LMS (学習管理システム) の典型的な Web アプリを考えることができます。

このソフトウェアには、以下を含む 3 レベルのアーキテクチャがあります。

1. ユーザーインターフェース;
2. ソフトウェア ビジネス ロジックおよびデータ アクセス用のサーバー側コンポーネント。
3. データベース。

このようなアプリケーションのビジネス機能は大きく異なります。 「コースとトレーニング」、「コースカタログ」、「会社の組織構造」、「イベントカレンダー」、「レポート」、「メッセージ」、「ニュース」などのブロックが含まれています。

ただし、それらはすべて単一のモノリシック ブロックに結合され、1 つのサーバー上に配置されます。このようなアプリケーションのスケーリングと変更は非常に困難です。

モノリシック アーキテクチャの欠点を強調しましょう。

• Web アプリの小さな変更でさえ、ソフトウェア全体の新しいバージョンの組み立てと展開につながります。
• アプリケーション全体のみをスケーリングできます。個別のブロックをスケーリングすることはできません。
• いずれかのアプリケーション モジュールに障害が発生すると、その結果、アプリケーション全体の動作が中断される可能性があります。
• 開発ツールは常に、選択した技術スタックに限定されます。
• 資格のある開発者の大規模なチームを管理する不便さ。各開発者は、自分のモジュールだけでなく、アプリのすべての機能を理解する必要があります。
• 更新は、ソフトウェアの機能全体に影響します。アップデート後のアプリケーション障害のリスクにつながります。そのため、更新のまれなリリースのみが行われます。
• データベースの変更は、アプリケーション全体の動作に影響を与える可能性があり、コードの変更が必要になります。

これが普通のユーザーに個々のスキルを教えるための小さな無料プログラムであり、めったに更新されない場合でも、モノリシック アーキテクチャはそのような開発に非常に適しています。

企業ソフトウェア (LMS など) について話している場合、頻繁に更新される場合でも、マイクロサービス アーキテクチャを選択する必要があります。

マイクロサービス アーキテクチャは、ソフトウェア開発への最適なアプローチです。マイクロサービス アーキテクチャでは、Web アプリケーションは、特定のインターフェイスを備えた小規模で自律的なコンポーネント (マイクロサービス) に分割されます。このようなアーキテクチャは、クラウド コンピューティングの分野で応用されています。

マイクロサービスとモノリシック アーキテクチャの違いは何ですか?マイクロサービス アーキテクチャでは、Web アプリは、マイクロサービスと呼ばれる、相互接続が不十分な小さなコンポーネントのセットとして開発されます。マイクロサービスは、互いにほとんど独立して開発、デプロイ、および保守されます。

たとえば、LMS の Web アプリケーションです。各マイクロサービスは、特定のビジネス タスクのみを解決することを目的としており、データベースを持ち、API を介して他のマイクロサービスと接続します。したがって、LMS Web アプリ用に次のマイクロサービスを開発する必要があります。「コースとトレーニング」、「コース カタログ」、「会社の組織構造」、「イベント カレンダー」、「レポート」、「メッセージ」、 「ニュース」など

ただし、サービス指向アーキテクチャ (SOA) という別のタイプのアーキテクチャがあることに注意する必要があります。マイクロサービスと混同されることがあります。マイクロサービス アーキテクチャと SOA の違いはそれほど明白ではないようです。しかし、マイクロサービスと SOA には違いがあります。これは、エンタープライズ サービス バス (ESB) の役割に関係しています。

SOA は全社的なアーキテクチャです。その目標は、会社の Web サービスの対話と統合を標準化することです。マイクロサービス アーキテクチャの目的は、特定のアプリケーションを開発することです。次のテンプレートは SOA に関連しています: CORBA、Web サービス、メッセージ キュー、ESB など。

以下では、Web アプリケーションを開発するためのマイクロサービスの利点について詳しく説明します。

マイクロサービス アーキテクチャの主な利点

モノリシック アーキテクチャと比較して、マイクロサービスの利点を評価します。

• アプリケーション展開のシンプルさと独立性。マイクロサービスの場合、デプロイできるアプリケーション モジュールは 1 つだけです。たとえば、LMS の場合、1 つのモジュール (「イベント カレンダー」) のみを展開でき、残りのアプリケーション コンポーネントは変更されません。 「Reports」モジュールのコードを書き直す必要がある場合、多くの権限を取得する必要はありません。このコンポーネント (「レポート」) は、別個の独立したマイクロサービスです。
• スケーラビリティ: 精度と効率。まず、頻繁なスケーラビリティを必要とするマイクロサービスとそうでないマイクロサービスを判断する必要があります。頻繁にスケーリングする必要のないモジュールは、弱いサーバーに配置できます。多くの場合、スケーラブルなモジュールは、他のすべてのソフトウェアとは別にスケーリングできます。
• アプリケーションの回復力の向上。合理的なアプリ設計とモジュール間の独立した接続の構築には、次の利点があります。モジュールの 1 つに障害が発生しても、ソフトウェア全体に障害が発生することはありません。たとえば、「メッセージ」モジュールが失敗した場合、ユーザーはこのブロックが一時的に利用できないという通知を受け取ります。他のすべてのアプリケーション ブロックは機能します。
• テック スタックの選択。各マイクロサービスを開発することで、最適な技術スタックを選択できます。
• チーム管理の柔軟性。たとえば、チーム1は「コースカタログ」、チーム2は「イベントカレンダー」、チーム3は「ニュース」というサービスを開発しています。そのため、新しい専門家がより早く仕事に取り掛かることが容易になります。アプリケーション全体の機能を長時間学習する必要はありません。特定のマイクロサービスの技術スタックを学習するだけで十分です。
• 機能を再利用する機能 (さまざまな目的で、さまざまな方法で)。
• 不要なサービスの交換または削除は、迅速かつ簡単に解決されます。たとえば、特定の顧客が LMS の「ニュース」ブロックを使用しない場合、すべてのソフトウェアを全体的に変更することなく、このモジュールを簡単に削除できます。
• 各マイクロサービスは、そのデータベースを使用します。この事実は、データ モデルの独立性につながります。たとえば、ある特定のサービスでプログラマがデータ モデルを変更しても、他のサービスの動作には影響しません。

お分かりのように、マイクロサービス アーキテクチャには大きな利点があり、ますます多くの開発者を惹きつけています。ただし、ソフトウェア開発用のアーキテクチャを選択する前に、マイクロサービスの欠点を確認する必要があります。以下にそれらをリストします。

マイクロサービスの欠点

マイクロサービスのシステムは分散されています。一方で、これはソフトウェアの作業における利点です。一方、マイクロサービスが多すぎて、それぞれが他のサービスにリクエストを行うと、結果として応答時間が長くなり、「障害点」が発生します。

この問題を解決するには、次の 2 つの方法があります。

1. 通話の詳細を変更すると、番号が減少する可能性があります。
2. 非同期性の導入により、呼び出しが並行して実行されるため、最終的な応答時間はすべての遅延の合計時間ではなく、すべての時間の中で最も遅くなります。

開発プロセスの絶え間ない複雑さは、プログラマーの資格要件の増加につながります。マイクロサービス アーキテクチャでは、統合プロセスと継続的デリバリー プロセスの役割が大きくなります。

そのため、テストを自動化し、サービスを展開することなく、多くのプロセスを処理することは非常に困難です。これらの要因には、社内での DevOps の実装と、開発者とシステム エンジニア、テスター、テクニカル サポートなどとの緊密な協力が必要です。

マイクロサービス アーキテクチャの分散化により、マイクロサービスの一貫性に問題が生じます。たとえば、モノリシック アプリケーションでは、1 つのトランザクションで多くの変更を行うことができますが、データの一貫性を維持しながら、障害が発生した場合にロールバックすることもできます。

マイクロサービスを使用する場合、次のような状況が発生する可能性があります。サービスの 1 つに障害が発生した場合、他のマイクロサービスが応答を停止します。この場合、それは開発者の優先順位の問題です。コンポーネントの可用性を優先することができます (1 つのサービスに障害が発生した場合、他のサービスは引き続き機能します)。一般に、開発者はサービスの一貫性と可用性のバランスを見つける必要があり、これは非常に慎重に行う必要があります。

結論

Web アプリケーションを開発するためのマイクロサービス アーキテクチャを選択する前に、開発者はその長所と短所の両方を評価する必要があります。結局、アーキテクチャの選択を誤ると、将来のソフトウェアのパフォーマンスと機能に影響を与える可能性があります。

マイクロサービス アーキテクチャが正しく使用されていない場合、開発者は、マイクロサービスのすべての利点を無効にする大きな問題に直面する可能性があります。

この記事の次の部分では、ソフトウェア開発でマイクロサービス アーキテクチャを使用する予定の開発者が習得する必要がある技術ツールについて検討します。