Apache Igniteが優れたマイクロサービスプラットフォームである理由

ご注意 翻訳者。 この記事は、特に作業が大量のデータを扱う場合に、マイクロサービスに基づいてソリューションを構築することを計画している、または現在のソリューションを最適化する方法を探しているアーキテクトと開発者にとって興味深いものです。 この翻訳は、Apache Igniteのマイクロサービスに関する一連の記事のパート1とパート2に基づいています。 Javaエコシステムの一般的な知識があることを前提としています（Apache Igniteは.NET、C ++、RESTおよび他の言語でも動作しますが、記事の例はJavaにアピールします）。Springの基本的な知識が推奨されます。



今日、 マイクロサービスアーキテクチャは、多くの企業がソリューションを構築する上で最も一般的なアプローチの1つです。 このアプローチの主な利点の1つは、ソリューションを一連の疎結合コンポーネント（マイクロサービス）に分割することです。各コンポーネントには、独自のライフサイクルとリリースサイクル、開発チームなどがあります。 これらのコンポーネントには常に、マイクロサービスが相互にやり取りするための少なくとも1つのデータ交換メカニズムがあります。 さらに、特定のシステムモジュールに最適なさまざまな言語とテクノロジを使用して作成できます。



高負荷のあるマイクロサービスアーキテクチャに基づくソリューションを使用し、活発に成長するデータアレイで作業する必要がある場合、おそらく古典的なアプローチの問題に遭遇したか、または遭遇するでしょう。

• ディスクデータベースは、格納および処理する必要がある情報量の増大に対応できません。 データベースがボトルネックになり、決定が「残り」ます。
• かつて「ケーキの上のチェリー」だった高可用性の要件は、現在、市場で成功を収めたい製品にとって必要な最小要件です。

この記事の目的は、Apache Ignite（またはGridGain In-Memory Data Fabric）を使用して製品のこれらの問題を解決し、マイクロサービスパラダイムでフォールトトレラントでスケーラブルなソリューションを構築する方法を説明することです。

Apache Igniteに基づいたソリューションの解析

下の図に示すように、Apache Igniteを使用する典型的なマイクロサービスソリューションアーキテクチャを見てみましょう。

Apache Ignite Cluster Layer

Apache Igniteクラスターは、2つの目標を達成するために使用されます。



まず、これはメインデータウェアハウスであり、RAMに保存されます。 データはメモリ内にあるため、マイクロサービスはDBMSを介して間接的に多くの高価なディスクアクセスを実行する必要がなく、システム全体のパフォーマンスが大幅に向上します。



「 データノード 」は、データを保存する役割を担うクラスター内の特別なグループです。 これらは、データセクションを格納し、これらのセクションでのデータ取得および計算要求の実行を可能にする「サーバー」Apache Igniteノードです。 データおよび計算クラスをデプロイする必要はありません。ApacheIgniteは独自のクロスプラットフォームバイナリ形式に依存しており、クラスターノード間でロジックとクラスを交換するメカニズムも備えています（ピアクラスの読み込み）。



Apache Igniteバイナリ形式は、オブジェクトをシリアル化し、ノード間のクラスの動的な交換をサポートするために使用されます。 このようなクラスター内でのロジックの交換の可能性により、ビジネスロジックを含むサービスノードの別のレイヤーからオンデマンドで必要なコードをダウンロードすることにより、計算を柔軟に管理できます。



第二に、クラスターはマイクロサービスのライフサイクルを管理し、マイクロサービスとデータノード間の相互作用に必要なすべてのAPIを提供します。



このソリューションでは、Apache Igniteクラスターに基づいて、サービスノードが使用されます。 これらは、必要なビジネスロジックを含むマイクロサービスコードが展開されるノードです。 特定のソリューションの機能に応じて、1つのノードに1つ以上のマイクロサービスが含まれる場合があります。



各マイクロサービスはサービスインターフェースを実装し、Apache Igniteノードに登録します。その後、クラスターの内部メカニズムがフォールトトレランスを提供し、クラスターの他の部分からマイクロサービスを呼び出す便利なメカニズムを提供します。 Apache Igniteは、サービスノードにマイクロサービスの1つ以上のコピーをデプロイします。 クラスターの内部メカニズムは、負荷分散とフォールトトレランスも提供します。



上の図では、マイクロサービスはMS <N>（MS1、MS2など）としてマークされています。 サービスノードとデータノード間のロジックの分離により、MS1マイクロサービスを更新する必要がある場合、クラスター全体を再起動する必要がなくなります。 必要なのは、デプロイされているサービスノードでMS1クラスを更新することだけです。 さらに、ノードのサブセットのみを再起動する必要があり、システムへの潜在的な影響を最小限に抑えます。



すべてのノード（サービスとデータ）は単一のクラスターに相互接続されているため、あるノードに展開されたMS1は、別の（または同じ）ノードに展開された他のマイクロサービスとやり取りし、任意のノードにデータと計算を送受信できますデータ。

永続レイヤー

このレイヤーはオプションであり、次のようなシナリオで使用できます。

• 意味をなさないか、すべてのデータをメモリに保持することは不可能です。
• クラスターが完全にクラッシュした場合、またはクラスターを再起動する必要がある場合に備えて、ディスク上のコピーからデータを回復できる必要があります。

永続データレイヤーを使用するには、Apache IgniteのCacheStoreインターフェイスの実装を指定する必要があります。 デフォルトの実装の中には、MongoDB、CassandraなどのさまざまなリレーショナルDBMSがあります。

外部アプリケーションとの相互作用の層

これはマイクロサービスの「クライアント」層であり、1つ以上のマイクロサービスを呼び出すことにより、この層からさまざまな実行ブランチが開始されます。



この層は、特定のマイクロサービスに固有のプロトコルを使用して、マイクロサービスと通信できます。 同時に、このアーキテクチャソリューションのフレームワーク内で、マイクロサービスはApache Igniteメカニズムを使用して相互に通信します。



このアーキテクチャは、水平方向に拡張する機能を提供し、メモリにデータを保存できるようにし、マイクロサービスの高可用性を保証します。

実装例

以下は、Apache Igniteクラスターの最初のレイヤーの可能な実装です。 使用するコードは、 https ： //github.com/dmagda/MicroServicesExampleで表示できます 。



特に、次の方法が示されます。

• データノードのセットアップと実行
• Apache Ignite Service Grid APIを使用してサービスを実装します。
• サービスノードを構成して実行します。
• クラスターに接続し、サービスの実行を開始するアプリケーションを（最も単純な形式で）作成します。

データノード

上記のように、データノードはデータを含むApache Igniteサーバーノードであり、アプリケーションのビジネスロジックによって開始されたクエリと計算を実行できます。 データノードはビジネスロジックから解放され、データストレージと処理メカニズムのみをカプセル化し、外部からの特定のリクエストを受け入れます。



例を使用して、このようなノードの作成を見てみましょう。 これを行うには、前述のGitHubプロジェクトをダウンロードする必要があります。



プロジェクトでdata-node-config.xmlファイルを見つけます。 このファイルは、新しいデータノードを開始するために使用されます。 その中に、クラスターにデプロイする必要のあるキャッシュの定義、およびデータノードに固有の他の設定を見ることができます。 主なものを検討してください。



ご注意 翻訳者。 Apache IgniteのXML構成は、Springを使用してオブジェクトツリーを構築します。 読者がSpringの構成に慣れていない場合、必要な情報は、たとえば、 公式文書 （英語）またはトレーニング資料から入手できます。 当然、IgniteConfigurationを直接作成することも、Springメカニズムが使用されるため、注釈またはGroovyダイアレクトに基づいて構成を構築することもできます。



まず、この構成では、キャッシュごとに、どのApache Igniteノードに情報を含めるかを決定するフィルターがインストールされます。 このフィルターは、ノードがクラスターに参加するか、クラスターから離脱するときに、トポロジーが変更されるたびに適用されます。 フィルター実装は、データノードではないノードを含むクラスター内のすべてのノードのクラスパスにデプロイする必要があり、クラスパスでアクセスできる必要があります。

<bean class="org.apache.ignite.configuration.CacheConfiguration"> ... <property name="nodeFilter"> <bean class="common.filters.DataNodeFilter"/> </property> </bean>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、上で定義したフィルタークラスが実装されます。 この例では、ノードがデータの保存を担当するかどうかの基準がノード「data.node」の属性である場合、最も単純なアプローチの1つが使用されます。 この属性がtrueに設定されている場合、ノードはデータノードと見なされ、ネットワーク上のキャッシュが含まれます。 そうしないと、クラスター全体にデータを配布するときにノードが無視されます。

 public boolean apply(ClusterNode node) { Boolean dataNode = node.attribute("data.node"); return dataNode != null && dataNode; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

第三に、構成は、起動時にこの構成を使用する各ノードの「data.node」パラメーターの値を定義します。

 <property name="userAttributes"> <map key-type="java.lang.String" value-type="java.lang.Boolean"> <entry key="data.node" value="true"/> </map> </property>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DataNodeStartupクラスを使用してデータノードを起動するか、ignite.shまたはignite.batスクリプトを使用して、data-node-config.xmlで定義された構成を引数として渡します。 後者の場合、最初にjava / app / commonのクラスを含むJARファイルをアセンブルし、このJARファイルを各データノードのクラスパスに配置することを忘れないでください。

サービスノード

構成に関しては、サービスノードは前のセクションのデータノードとそれほど変わりません。 同様に、Apache Igniteノードのサブセットを割り当てる基準を決定する必要がありますが、このサブセットはデータストレージではなく、マイクロサービスの動作を担当します。



最初に、 Apache Ignite Service Grid APIを使用してマイクロサービスを定義する必要があります 。 記事の一部として、GitHubのリポジトリに適用されるMaintenanceServiceの例を検討します。



サービスインターフェイスは次のとおりです。

 public interface MaintenanceService extends Service { public Date scheduleVehicleMaintenance(int vehicleId); public List<Maintenance> getMaintenanceRecords(int vehicleId); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスでは、マシンのメンテナンスを計画したり、割り当てられたサービスのリストを受信したりできます。 実装には、ビジネスロジックに加えて、init（...）、execute（...）、cancel（...）などのService Grid固有のメソッドの定義が含まれています。



クラスタのサブセットでこのマイクロサービスを公開するには、いくつかの方法があります。 例の中で使用されるそれらの1つは、構成ファイルmaintenance-service-node-config.xmlを定義し、この構成ファイルとクラスパス上の必要なクラスでサービスノードを開始することです。 この場合、構成は次のようになります。



まず、サービスノードを他のサービスノードと区別するフィルターが定義されています。

 <bean class="org.apache.ignite.services.ServiceConfiguration"> <property name="nodeFilter"> <bean class="common.filters.MaintenanceServiceFilter"/> </property> </bean>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィルターの実装は次のとおりです。

 public boolean apply(ClusterNode node) { Boolean dataNode = node.attribute("maintenance.service.node"); return dataNode != null && dataNode; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この実装では、基準は、ノードの属性「maintenance.service.node」がtrueに設定されているかどうかです。



最後に、ノードは次のmaintenance-service-node-config.xml構成セクションを介してこの属性を受け取ります。

 <property name="userAttributes"> <map key-type="java.lang.String" value-type="java.lang.Boolean"> <entry key="maintenance.service.node" value="true"/> </map> </property>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご注意 翻訳者。 サービスを配置するという事実は、構成からの以下のコードによって設定されます。 serviceConfigurationには、このノードに理論的に展開できるサービスがリストされます。



サービスのnameプロパティは、クラスター内の一意の名前を担当します。たとえば、サービスプロキシを介してサービスにアクセスできます。サービスプロパティは、サービスロジックを実装するクラスを参照し、totalCountおよびmaxPerNodeCountプロパティは、サポートする必要のあるインスタンスの合計数を示し、それぞれ特定のノード上のインスタンスの最大許容数。 この場合、シングルトンクラスターが構成されます。セグメント化されていないクラスター内では、サービスのインスタンスは常に1つだけです。

 <property name="serviceConfiguration"> <list> <!--  MaintenanceService.          --> <bean class="org.apache.ignite.services.ServiceConfiguration"> <!--       --> <property name="name" value="MaintenanceService"/> <!-- ,   --> <property name="service"> <bean class="services.maintenance.MaintenanceServiceImpl"/> </property> <!--       --> <property name="totalCount" value="1"/> <!--   ,      --> <property name="maxPerNodeCount" value="1"/> … </bean> </list> </property>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MaintenanceServiceNodeStartupを使用してサービスノードの複数のインスタンスを起動するか、 maintenance-service-node-config.xmlをignite.shまたはignite.batに渡し、最初に各ノードのクラスパスにjava / app / commonおよびjava / services / maintenanceからすべての必要なクラスを配置します。



GitHubのリポジトリでVehicleServiceサービスの例を見つけることもできます。 VehicleServiceNodeStartupクラスを使用するか、最初にクラスパスにすべての必要なクラスを配置した後、 vehicle-service-node-config.xmlファイルをignite.shまたはignite.batに渡すことにより、このサービスのインスタンスを開始できます。

応用例

Maintenance ServiceおよびVehicleServiceサービスを含むサービスノードと同様にデータノードを構成し、起動する準備ができたら、分散マイクロサービスのインフラストラクチャを使用する最初のアプリケーションを起動できます。



これを行うには、GitHubリポジトリからTestAppStartupファイルを実行します。 アプリケーションはクラスターに参加し、キャッシュをデータで満たし、展開されたマイクロサービスで操作を実行します。



サービスで操作を実行するためのコードは次のとおりです。

 MaintenanceService maintenanceService = ignite.services().serviceProxy( MaintenanceService.SERVICE_NAME, MaintenanceService.class, false); int vehicleId = rand.nextInt(maxVehicles); Date date = maintenanceService.scheduleVehicleMaintenance(vehicleId);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、アプリケーションはサービスプロキシを使用してサービスで動作します。 このアプローチの利点は、クライアントの役割を果たしているノードが、クラスパスにローカルにデプロイされたサービス実装クラスを持っている必要がないことです-インターフェースクラスだけで十分です-そして、ローカルでサービスを実行する必要はありません：プロキシは、リモート実装との透過的な対話を提供します。

おわりに

この記事では、Apache Ignite上でのマイクロサービスの使用を含むアーキテクチャを検討し、このアーキテクチャを実装するサンプルアプリケーションも検討しました。 次の記事では、クラスターを永続データストレージのレイヤーに関連付ける方法、および外部アプリケーションとの対話のレイヤーを強調する方法について説明します。