マイクロ サービス アーキテクチャとは?Eコマースの最良なソリューションなのか?

マイクロ サービス 、または マイクロ サービス アーキテクチャ とも呼ばれ、この近年中小規模のブランドからUberやNetflixAmazon, Karmaなど大手企業のEコマースプラットフォームで利用されてきました。では、マイクロ サービス とはなんだろう。なぜクラウドが普及されている現在ではEコマースの最良なソリューションとして呼ばれているのだろうか。今回 ディエスソリューション はそれを解明していきます。

1. マイクロ サービス アーキテクチャとは ?

マイクロ サービス と は 、サービスを構成する各要素を Microservice と呼ばれら独立した小さなコンポネントとして実装するという アーキテクチャスタイルです。マイクロ サービス アーキテクチャでは、アプリケーションが以下の特徴を持っているサービスセットにより構成されます:

・高度で保守とテスト可能

・緩く結合

・独自的にデプロイ可能

・ビジネス機能を中心に編成される

・小規模のチームにより実装される

マイクロ サービス アーキテクチャ は モノリシック によく比べられています。モノリシック スタイル は、マイクロサービスとは逆でアプリケーションを単位でビルドするアーキテクチャのことです。

2. モノリシック と マイクロ サービス

エンタープライズアプリケーションは、クライアントサイドのインターフェース(ユーザーのマシンで実行されているHTMLページとJavascriptを含む)、データベース(共通の、通常はリレーショナルなデータベース管理システムに挿入された多くのテーブルで構成される)とサーバーサイドアプリケーションといった3つのパートに分けられます。そのサーバーサイドアプリケーションは、単一の論理実行可能ファイルモノリシックであり。HTTPリクエストの処理、ドメインロジックの実行、データベースからのデータの取得と更新、ブラウザに送信するHTMLビューの選択と入力を行います。システムへの変更は、すべてサーバー側でアプリケーションの新しいバージョンの構築とデプロイが含まれます。

それこそのため、モノリシックでは変更サイクルが相互に関連し、アプリケーションのごく一部に変更を加えるには、モノリシック全体の再構築やデプロイにつながります。時間の経過とともに、適切なモジュラー構造を維持することが難しくなることが多いです。それでスケーリングには、アプリケーションの一部だけではなく、アプリケーションの全体のスケールが要求され、大変大きいリソースがかかるでしょう。

モノリシックデータベースとマイクロ サービス データベース

Microservice  はモノリシックアーキテクチャのデメリットを回復するために誕生されました。モノリシックアプリケーションはすべての機能を単一のシングルプロセスに入れ込み、複数のサーバーでモノリシックを複製することによりアプリケーションをスケールします。その一方、マイクロ サービス アーキテクチャ は機能の各要素を個別のサービスに配置し、これらのサービスをサーバー間で分散し、必要に応じて複製します。

モノリシック と マイクロ サービス

3. マイクロ サービス メリット

3.1. 大規模で複雑なアプリケーションの継続的デリバリーとデプロイメントを可能化

・より良い保守:サービスごとは小さく、変更しやすい。

・改善のテスト可能性:テスト作業は短時間で終了できる。

・改善のデプロイメント:各サービスは個別でデプロイできる。

・複数の自律的なチームを中心に開発作業を整理することができます。各チームは1以上のプロジェクトを担当し、独立してサービスを開発、テスト、展開及び拡張することができます。

3.2. 各マイクロ サービスは比較的に小さい

・開発者が理解しやすい

・IDEが高速で、開発作業の生産性を高める

3.3. エラーによる影響を減らす

一つのサービスでエラーが発生しても他のサービスに影響を与えることはあります。例えば、メモリーリークは一つのサービスで発生しても、他のサービスは普通にリクエストを処理することが可能です。一方、モノリシックアーキテクチャの場合、一つの誤動作コンポーネントは、システム全体をダウンさせる可能性があります。

3.4. 複数のテクノロジースタックを利用可能

各サービスは自律的にデプロイされるため、サービスごとに特別なテクノロジーを利用することが可能です。新サービスを開発する度、新しいテクノロジーを導入しても構いません。それに、既存サービスのコアを変更する時、新しいテクノロジーでリライトしては可能です。

4. マイクロ サービス デメリット

4.1. 分散システムを作成する際の複雑な問題を処理する必要がある:

・サービス間通信メカニズムを実装し、部分的な障害を処理しないとはいけません。

・複数のサービスにまたがるリクエストの実装はチームのコーディネーションが必要で、より難しいです。

・サービス間の相互作用のテストもより困難であります。

・開発者ツール/IDEは、モノリシックアプリケーションの構築を目的としており、分散アプロケーションの開発を明示的にサポートしています。

4.2. メモリー消費量の増加

マイクロ サービス アプリケーション は、N個のモノリシックアプリケーションインスタンスをNxMサービスインスタンスに置き換えます。各サービスが独自のJVM(または同等のもの)で実行される場合(通常はインスタンスを分離するために必要)、JVMランタイムのM倍のオーバーヘッドが発生します。さらに、Netflixの場合のように、各サービスが独自のVM(EC2インスタンスなど)で実行されている場合、オーバーヘッドになる可能性はさらに高くなります。

5. マイクロ サービス アーキテクチャ はどんなアプリケーションに最適なのか?

クラウドの進化に従い、マイクロサービスアーキテクチャはほぼすべてのアプリケーションに適用されるようになっています。アプリケーションの最初のバージョンを開発するとき、このアプローチで解決できる問題がないと感じることが多いです。さらに、マイクロサービスアーキテクチャの複雑性こそから精巧な分散アーキテクチャを使用すると、開発が遅くなる恐れがあります。これは、ビジネスモデルとそれに付随するアプリケーションをどのように迅速に進化させるかが最大の課題となることが多いスタートアップにとって大きな問題になる可能性があります。

しかし、長期的かつ将来的に、課題がスケーリングの方法となり、機能分散を使用する必要がある場合、モノリシックアプリケーションを一連のサービスに分解することが困難になる恐れがあります。

まとめ

マイクロ サービス アーキテクチャ はスケーラビリティ性と独立性が高いという特徴があり、変更が多く、アプリケーションの安定性と良いパフォーマンスが必要なEコマースに限らず、クラウドネイティブのアプリケーションに最善のアーキテクチャとも言えます。マイクロサービス アーキテクチャ に関するお問い合わせがございましたら、 DS Solution にご連絡ください。