Azure Service Fabric とは

7 分

まず、いくつかの定義と、Azure Service Fabric のクイックツアーを見ていきましょう。この概要は、Service Fabric がご自身の分散コンピューティングソリューションに適しているかどうかを判断するのに役立ちます。

コンテナーとは何ですか?

"コンテナー" は、アプリケーションとそのすべての依存関係 (ライブラリや構成ファイルなど) を、その環境でソフトウェアを実行するために必要なすべてのものを含む独自の分離環境にラップするソフトウェアのアトミック単位です。コンテナーはカーネル上で直接動作し、ファイルシステムやその他のリソースの分離されたビューを備えています。コンテナーの内部のアプリケーションは、コンテナーの外のアプリケーションやプロセスを認識しません。

コンテナーを使用する理由

コンテナーモデルには、次の利点があります。

小さい: コンテナーは 1 つのストレージ領域を使用し、複数のバージョンと更新プログラムを階層化することで効率を高めています。
高速:コンテナーはオペレーティングシステム全体を再起動する必要がないため、より高速に (通常は秒単位で) 起動できます。
移植性: コンテナー化されたアプリケーションのイメージを、クラウドまたはオンプレミスで実行されるように移植することができます。仮想マシンへの移植または物理マシン上への直接の移植が可能です。
リソースガバナンス: コンテナーは、ホスト上で利用できる物理リソースを制限できます。

コンテナーが管理される方法

"コンテナーオーケストレーション" は、管理者がコンテナーを使用して環境を管理するのに役立つソフトウェアの一部を表す一般的な用語です。管理者は、環境の望ましい状態 (特定のサービスの 5 つのコピーが実行されているなど) を入力します。すると、オーケストレーターで、環境を望ましい状態に一致させようとする試みが行われます。その望ましい状態が実現すると、オーケストレーターでその状態の維持が試みられます。いずれかのサービスが失敗した場合、オーケストレーターで新しいコピーのデプロイが試みられます。

ほとんどのオーケストレーターで、初期デプロイと失敗のケースの処理以上のことが行われます。アップグレードを処理し、リソースの利用とガバナンスに対処することもできます。

コンテナーオーケストレーションとは、基本的に、環境内で必要な構成の状態を実現し、維持することです。

"Cluster Resource Manager" は、Azure Service Fabric のオーケストレーションを処理するシステムコンポーネントです。

マイクロサービスとは

"マイクロサービスアプリケーション" と "マイクロサービスアーキテクチャ" は、結果を実現するために連携して動作する、小さい独立した疎結合サービスのことです。

サービスは、異なるテクノロジスタック、ライブラリ、フレームワークを使用して、互いに完全に独立して開発できます。サービスは個別にデプロイできるため、アプリケーション全体を再デプロイしなくてもアーキテクチャのコンポーネントを更新できます。サービスは、独自のデータを保持する役割を担います。サービスは明確に定義された API を使用して通信し、互いの内部実装に依存しません。

マイクロサービスを使用する理由

マイクロサービスモデルには、次の利点があります。

機敏性: マイクロサービスは独立してデプロイされるため、機能のリリースの複雑さが軽減されます。アプリケーション全体を再デプロイしなくてもサービスを更新できます。
障害の分離:個々のマイクロサービスが使用できなくなっても、上流マイクロサービスが障害を正しく処理するように設計されていれば、アプリケーション全体が中断されることはありません。
スケーラビリティ: サービスは独立してスケーリングできるため、アプリケーション全体をスケールアウトせずに、追加のリソースが必要なサブシステムを拡大できます。これがコンテナーとコンテナーのオーケストレーションモデルにどれだけ適合しているかを確認できます。
データの分離: 影響を受けるのは 1 つのマイクロサービスのみであるため、スキーマの更新が簡単になります。

ステートレスとステートフルのサービスとは

"ステートレス" サービスは、それぞれの要求と応答を分離して理解できるサービスです。実行する計算 (たとえば、2 + 2) を送信し、1 つの答え (4) を受け取る、単純な電卓サービスを想像してみてください。その結果に対して別の計算 (たとえば、4 x 2) を実行する場合は、4 x 2 を計算する要求を手動で送信し、8 を受け取ります。ただし、最初の計算の結果を使用していることはサービスで認識されません。

"ステートフル" サービスは、それぞれの要求と応答が、サービスによって認識されて参照できるトランザクション履歴に対応したサービスです。電卓サービスの例をもう一度使いましょう。ただし、今回はステートフルバージョンを使用します。 2 +2 という計算の実行を要求すると、4 を受け取ります。今回は、前の結果を取得して 2 で乗算するようにサービスに要求します (構文は、解答 x 2 のようになります)。最初の例と同様に、応答として 8 を受け取ります。しかし、今回は、電卓サービスで前回のトランザクションの結果 (解答) が 4 であることが認識されていました。

ステートレスとステートフルのサービスを使用する理由

ご自身のソリューションでは、ステートレスサービス、ステートフルサービス、またはその両方を利用できます。

選択は、アプリケーションのニーズによって異なります。セッション間でサービスの状態を保持する必要がある場合は、ステートフルサービスが必要です。サービスで状態を保持する必要がない場合、または状態を保持するために外部ストレージに依存できる場合は、ステートレスサービスを使用できます。

マイクロサービスアーキテクチャを使用すると、ステートレスとステートフルのサービスを混在させることができます。マイクロサービスは独立しており、まったく異なるテクノロジスタックを利用できるため、永続化された状態が必要なサービスと必要でないサービスを設計できます。