Azureサービスファブリック
Azure Service Fabricマイクロサービスプラットフォームから始めましょう。 コンテナー内および外部コンテナー内の信頼性の高いスケーラブルなマイクロサービスの開発と管理、およびそれらの管理を可能にします。 Service Fabricプラットフォームには、BMWやSchneider Electricなどの企業を含む300人以上のユーザーがいます。
Service Fabricクラスターは、 Azureパブリック環境、オンプレミス環境、プライベートクラウド、または他のクラウドサービスプロバイダーのソリューションなど、ほぼすべての環境で使用するためにプロビジョニングできます。 Service FabricのパブリックバージョンはWindowsで実行されますが、プライベートプレビューに使用できるLinuxバージョンもあります。 Windows ServerまたはLinuxへのService Fabricの展開の詳細については、ここをクリックしてください。
プラットフォームの主な機能に加えて、サービスファブリック内のあらゆる種類のアプリケーション（Node.js、Javaなど）の迅速な展開、ホスティングサービス、高信頼性、高密度、ヘルスレポート、調整された更新およびサービスエンドポイントの検出が含まれます状態追跡の有無にかかわらずマイクロサービスを作成するためのプログラミングモデルがサポートされています。 現在、プログラミングモデルは、Windows上の.NETおよびLinux上のJavaで使用できます。
対照的に、状態ファブリックサービスファブリックマイクロサービスは、状態をコンピューティングインスタンスにローカルに保存します。 このため、移動するコンポーネントが少ないため、読み取りと書き込みの遅延が減少し、アーキテクチャ全体も簡素化されます。 Service Fabricの主要な目標の1つは、データの信頼性と一貫性を維持することです。 これにはレプリケーションが使用されます。
マイクロサービスの使用例
TalkTalkストリーミングおよびエンコーディングソリューションは、アプリケーション全体をクラウドに転送するのが最も簡単であったため、 Azure Infrastructure as a Serviceの一部としてLift and Shift方法論を使用して作成されました。 ただし、ビジネスが着実かつ急速に成長し、新しい要件が出現したため、TalkTalk開発者は、Azure Service Fabricをプラットフォームとして使用して、アプリケーションの一部にマイクロサービスアプローチを実装し始めました。
このため、サービスの展開を簡素化し、各サービスのより柔軟なスケーリングオプションを取得し、個々のサービスを更新する際のダウンタイムを排除することができました。 また、マイクロサービスアプリケーションは、Azure Media ServicesおよびAzure Batchとうまく統合されます。
この図は、マイクロサービスに基づいたアプリケーションの一般的なアーキテクチャと、そのようなアプリケーションでのエンコード要求の処理の進行状況を示しています。
以下は、リクエストの処理における各マイクロサービスの役割の説明です。
ステップ1 TalkTalkクライアントは
EncodeRequest
メソッドを呼び出します。
EncodeRequest
メソッドは、Azure Management APIを介してActivity Web APIで使用できます。
手順2.ステートレスアクティビティAPI APIは、.NET（OWIN）リスナー用のオープンWebインターフェイスです。 新しいエンコード要求を作成する機能を提供するAPIコントローラーをホストします。 Service Fabricの外部のサービスは、外部通信にこのAPIを使用します。 API管理サービスから呼び出しを受け取ります。
ステップ3.ステータス追跡マイクロサービスは、インバウンド作業のためにService Fabricの信頼できるキューAPIを使用します。 このマイクロサービスは、実行する必要があるコーディング作業を表すアクションサブジェクトを作成します。
ステップ4. ActivityActorマイクロサービスは、各ステップの進行状況を追跡し、各ステップのアクションサブジェクトを作成するための作業項目のリストを提供します。 作成されたサブジェクトは状態を監視するため、障害が発生した場合でも、複製によってデータが失われることはありません。
ステップ5. Microservice ActivityStepActorは、作業段階を調整します。 他のService Fabricアプリケーションで作業が行われます。 たとえば、暗号化ジョブ管理アプリケーションは、Azure Batchを使用して、TalkTalkセットトップボックスに必要なカスタム暗号化手順を完了します。 暗号化ジョブ管理アプリケーション自体には多くのマイクロサービスが含まれており、必要なAzure Batchインタラクションをカプセル化します。 アクションステップのサブジェクトは、Service Fabricプラットフォームが提供するサービスプロキシを使用して適切なサービスと通信します。
ステートレスActivityStepマイクロサービスはService Communication Listenerへのアクセスを提供するため、Azure Media Servicesジョブ管理アプリケーション（AMS）（ステップ6）や暗号化ジョブ管理アプリケーション（ステップ7）などの他のService Fabricサービスは、アクションステップと対話できます。 この動作原理はコールバックに似ています。たとえば、Batchサービスがシャットダウンした場合、ActivityStepActorに連絡して作業段階を完了または更新する必要があります。
このプロセス中に、各サブジェクトのリマインダーが使用されて、サブジェクトの状態が定期的にDocumentDBに保存されます。 これは2つの目的で行われます。1つ目は、任意のリクエストを実行する機能を提供すること、2つ目は、Service Fabricプラットフォーム外でデータの保護とバックアップを編成することです。
TalkTalkマイクロサービスアプリケーションの詳細な説明は、 ここで入手できます 。
Azure Container Service
Azure Container Service （ACS）は、マイクロサービスアプリケーションを展開して実行できる別のAzureサービスです。 ACSユーザーには、Avanade、ESRi、およびCloudBeesが含まれます。
ACSの主な機能により、 DC / OSまたはSWARMをオーケストラとして使用して、コンテナの負荷を管理するクラスターを作成できます。 マイクロサービスの観点からは、サービスの検出と登録、情報の交換、監視などの手段を選択する責任があります。 これはService Fabricプラットフォームとの主な違いでもあり、その機能はクラスターとオーケストレーターを超えて拡張され、サービスの登録と検出、プログラミングモデルなどの統合サービスが含まれます。
ACSの利点
明白なことから始めましょう：オープンソースソフトウェアテクノロジー（OSS）を使用します。 ACSがDocker SwarmとMesosphere DC / OSを使用していることを考えると、これら2つのテクノロジーで利用可能なすべてのOSSコミュニティリソースがサービスにあります。 これらの技術は長い間市場に出回っているので、ステップバイステップガイド、トレーニング資料、コードスニペット、およびほとんどすべてのシナリオのターンキーソリューションさえ簡単に見つけることができます。
もう1つの利点は、Azureを使用したクラスターの構成と管理の容易さです。 ベアメタルまたは仮想マシンでDC / OSまたはDocker Swarmクラスターをセットアップする必要がある人は、複数のマシンを相互に接続するだけでなく、それ以上のことが必要であることをよく知っています。 また、さまざまな追加のコンポーネントとサービスを構成し、エンドポイントへのアクセスを提供し、エージェントをロードバランサーに関連付ける必要があります。このようなクラスターの構成を自動化するには、かなり大量のスクリプトを記述する必要があります。 ACSは、テンプレートの使用とすべての構成手順の抽象化により、クラスター構成を簡素化します。
ただし、オーケストレーターで車のクラスターをセットアップすることは、戦いの半分にすぎません。 クラスターを構成して開始した後、このクラスター内のマシンにパッチをインストールするか、SWARMおよびDC / OSの新しいバージョンにアップグレードする必要がある場合があります。 通常、このようなタスクには慎重な計画が必要です。 将来、ACSは完全に管理されたインフラストラクチャをサポートするため、開発者はインフラストラクチャ管理タスクに時間を無駄にすることなく、クラスタ内のワークロードのみに集中できます。
クラスターをAzureポータルでの作業用に準備するか、Azure Resource Managerテンプレートをサービスとしてのインフラストラクチャの一部として自動的に使用できます。 以下の値のみを提供する必要があります。
- orchestratorProfile-使用するオーケストレーター（DCOSまたはSwarm）。
- masterProfile-メインノードの数とDNSプレフィックス。
- agentPoolProfiles-エージェントノードの数、ノードサイズ、DNSプレフィックス。
- linuxProfile-ホストに接続するためのユーザー名とSSHキー。
次のスニペットは、Azure Resource Manager for ACSテンプレートのJSONコードを示しています。
“resources”: [ { “apiVersion”: “2016–03–30”, “type”: “Microsoft.ContainerService/containerServices”, “location”: “[resourceGroup().location]”, “name”:”[concat('containerservice-',resourceGroup().name)]”, “properties”: { “orchestratorProfile”: { “orchestratorType”: “[variables('orchestratorType')]” }, “masterProfile”: { “count”: “[variables('masterCount')]”, “dnsPrefix”: “[variables('mastersEndpointDNSNamePrefix')]” }, “agentPoolProfiles”: [ { “name”: “agentpools”, “count”: “[variables('agentCount')]”, “vmSize”: “[variables('agentVMSize')]”, “dnsPrefix”: “[variables('agentsEndpointDNSNamePrefix')]” } ], “linuxProfile”: { “adminUsername”: “[variables('adminUsername')]”, “ssh”: { “publicKeys”: [ { “keyData”: “[variables('sshRSAPublicKey')]” } ] } } } }
その結果、アプリケーションをデプロイできる完全に構成されたDC / OSクラスターまたはDocker Swarmを取得します。 この図は、完全に構成されたDCS / ACSクラスターの出力を示しています。
ACSは展開に加えて、スケーラブルな仮想マシンセット（VMSS）と統合します。これにより、オーケストラ全体およびインフラストラクチャ全体の自動スケーリングとパッチインストールが簡単になります。 前述のように、ACSでは、マイクロサービスに基づいたあらゆるアプリケーションを展開して実行できます。 このため、ACSを使用した展開では、非常に高い柔軟性が実現されます。 マイクロサービスに基づいてアプリケーションを実行するには、他の環境で使用するDC / OSまたはDocker Swarmを実行するソリューションを使用できます。
オーケストレーターとしてAzureコンテナーサービスのDC / OSを使用するマイクロサービスベースのアプリケーションの例を考えてみましょう。 Flak.ioは、マイクロサービスの機能を実証するために特別に設計された電子商取引アプリケーションの例です。 このアプリ：
- さまざまなテクノロジーを使用
- 各サービスの異なる規模と可用性の要件に準拠している、
- サービスごとにデータを個別に保存します。
- DC / OSサービスの登録および検出機能を使用します。
ユーザーの観点から、このアプリケーションを使用すると、カタログ内の製品を表示して購入できます。
アプリケーションは、4つの主要なサービスとインターフェイスサービスで構成されています。
- AngularJS SPAとして実装されたインターフェイスは、 Flakioのランディングページを提供します。
- カタログサービスは、製品情報の管理を担当します。
- 注文サービスは注文の処理を担当します。 注文サービスで使用される製品モデルは、コンテキストが異なるため、カタログサービスの製品モデルとは異なることに注意してください。
- 推奨サービスは、履歴情報とリアルタイムデータを分析して推奨事項を準備します。
- 通知サービスは、電子メールによる通知の送信、および電子メールテンプレートの保存と管理を行います。
この図は、Flak.ioの一般的なアーキテクチャを示しています。
Flak.ioのソースコードはGitHubで入手できます 。
ご注意 Flak.ioプロジェクトはまだ完成していません。 イベントレコードの保存、推奨および通知サービスの作成に関する作業は継続されますが、一般にこのアプリケーションは、ACSのマイクロサービスに基づいたコンテナーアプリケーションの設計と展開の全体像を提供します。
まとめ
この出版物では、Service FabricとAzure Container Servicesの2つのマイクロサービスアーキテクチャの例を検討しました。 一般に、Service Fabricはマイクロサービスに基づいてアプリケーションを構築するためのターンキーソリューションと見なすことができます。AzureContainer Serviceは、DC / OSまたはSWARMを使用してクラスターをすばやくセットアップし、インフラストラクチャを管理するのに役立ち、開発者がコードの記述に完全に集中できるようにします。 ACSクラスターを準備した後、マイクロサービスアプリケーションに便利な任意のテクノロジーと、成長を続けるDockerおよびMesoshpereコミュニティの機能を使用できます。
有用な活動
記事がほとんどなく、Azureでマイクロサービスやその他のソリューションを作成するトピックについて、リモートまたは個人的に私や同僚とチャットしたい場合は、次のイベントに参加してください。
- 4月11日のウェビナーの記録 。 クラウドアーキテクチャの新しいアプローチ：コンテナーとマイクロサービス （登録が必要）
- 4月19日、モスクワ、metap Azureのマイクロサービス（meetup.comによる登録が必要）
- 4月21〜23日、モスクワ、DevConスクール 。 近代建築 （登録が必要です）
この時点まで読んで、 DevCon School：Modern architectureを読みたいが、プロモーションコードがない場合は、なぜそこに行きたいのかを説明するメッセージを書いてください。 いつものように、Habra読者向けのプロモーションコードがいくつかあります 。