Reliable Services の概要Reliable Services overview

Azure Service Fabric により、ステートレスおよびステートフルなサービスの作成と管理が簡素化されます。Azure Service Fabric simplifies writing and managing stateless and stateful services. このトピックの内容は次のとおりです。This topic covers:

  • ステートレス サービスおよびステートフル サービスの Reliable Services プログラミング モデル。The Reliable Services programming model for stateless and stateful services.
  • Reliable Service を作成するうえでの選択肢。The choices you have to make when writing a Reliable Service.
  • Reliable Service を使用するタイミングと作成方法のいくつかのシナリオと例。Some scenarios and examples of when to use Reliable Services and how they are written.

Reliable Services は、Service Fabric で使用できるプログラミング モデルの 1 つです。Reliable Services is one of the programming models available on Service Fabric. もう 1 つは、Reliable Actor プログラミング モデルで、Reliable Services モデルが基になっている仮想アクター アプリケーション フレームワークが提供されます。Another is the Reliable Actor programming model, which provides a Virtual Actor application framework on top of the Reliable Services model. Reliable Actors の詳細については、「Service Fabric Reliable Actors の概要」を参照してください。For more information on Reliable Actors, see Introduction to Service Fabric Reliable Actors.

Service Fabric では、プロビジョニングとデプロイからアップグレードと削除までのサービスの有効期間が Service Fabric のアプリケーション管理で管理されます。Service Fabric manages the lifetime of services, from provisioning and deployment through upgrade and deletion, via Service Fabric application management.

Reliable Services とはWhat are Reliable Services

Reliable Services は、重要な機能をアプリケーションに組み込むためのシンプルかつ強力な最上位レベルのプログラミング モデルを提供します。Reliable Services gives you a simple, powerful, top-level programming model to help you express what is important to your application. Reliable Services プログラミング モデルを使用すると、以下のことを実現できます。With the Reliable Services programming model, you get:

  • Service Fabric API へのアクセス。Access to Service Fabric APIs. ゲスト実行可能ファイルとしてモデル化された Service Fabric サービスとは異なり、Reliable Services では Service Fabric API を直接使用できます。Unlike Service Fabric services modeled as Guest Executables, Reliable Services can use Service Fabric APIs directly. これにより、サービスで次のことが可能になります。This allows services to:
    • システムのクエリを実行するQuery the system
    • クラスター内のエンティティに関する正常性をレポートするReport health about entities in the cluster
    • 構成とコードの変更に関する通知を受け取るReceive notifications about configuration and code changes
    • 他のサービスを検索し通信するFind and communicate with other services,
    • リライアブル コレクションを使用するUse the Reliable Collections
    • その他の多くの機能にアクセスする。これらの機能はすべて、複数のプログラミング言語の非常に優れたプログラミング モデルから提供されます。Access many other capabilities, all from a first-class programming model in several programming languages.
  • 他の使い慣れたプログラミング モデルに似た、独自のコードを実行するためのシンプルなモデル。A simple model for running your own code that feels like other familiar programming models. コードには、適切に定義されたエントリ ポイントと管理が簡単なライフサイクルが含まれます。Your code has a well-defined entry point and easily managed lifecycle.
  • プラグ可能な通信モデル。A pluggable communication model. HTTP と Web API、WebSocket、カスタム TCP プロトコルなど、あらゆるトランスポートを選んで使用できます。Use the transport of your choice, such as HTTP with Web API, WebSockets, custom TCP protocols, or anything else. Reliable Services には、すぐに使用できる優れたオプションも用意されていますが、独自のオプションを指定することもできます。Reliable Services provide some great out-of-the-box options you can use, or you can provide your own.
  • ステートフル サービスの場合、Reliable Services プログラミング モデルを使用すると、Reliable Collection によって状態がサービス内に一貫して確実に格納されます。For stateful services, the Reliable Services programming model allows you to consistently and reliably store your state right inside your service by using Reliable Collections. Reliable Collection は、C# コレクションを使用したことがあるユーザーには馴染みのある可用性が高く信頼できる一連のコレクション クラスです。Reliable Collections are a simple set of highly available and reliable collection classes that will be familiar to anyone who has used C# collections. これまでは、サービスにおいて確かな方法で状態を管理するには、外部システムが必要でした。Traditionally, services needed external systems for Reliable state management. Reliable Collection を使用するとユーザーのコンピューターの隣に状態を格納できるようになると同時に、高可用性の外部ストアと同じレベルの高い可用性と確実性を実現できます。With Reliable Collections, you can store your state next to your compute with the same high availability and reliability you've come to expect from highly available external stores. このモデルでは、機能に必要な計算と状態を併置できるため、待機時間も短縮します。This model also improves latency because you are co-locating the compute and state it needs to function.

Reliable Services の特長What makes Reliable Services different

Service Fabric では以下の機能が提供されるため、Reliable Services はこれまでに作成したサービスとは異なります。Reliable Services are different from services you may have written before, because Service Fabric provides:

  • 信頼性 - コンピューターがダウンしたりネットワークの問題が発生したりした場合や、サービスそのものでエラーが発生したりクラッシュしたり失敗したりした場合でも、サービスは起動した状態を保ちます。Reliability - Your service stays up even in unreliable environments where your machines fail or hit network issues, or in cases where the services themselves encounter errors and crash or fail. ステートフル サービスの場合、ネットワークまたはその他の障害が発生した場合でも、状態は保持されます。For stateful services, your state is preserved even in the presence of network or other failures.
  • 可用性 - サービスはアクセス可能で、高い応答性があります。Availability - Your service is reachable and responsive. Service Fabric では、実行中のコピーを任意の数保持します。Service Fabric maintains your desired number of running copies.
  • スケーラビリティ - 特定のハードウェアからサービスを分離し、必要に応じて、ハードウェア リソースまたはその他のリソースを追加または削除することで拡張または縮小できます。Scalability - Services are decoupled from specific hardware, and they can grow or shrink as necessary through the addition or removal of hardware or other resources. サービスは、サービスをスケーリングしたり部分的な障害に対応したりできるように簡単に分割できます (特にステートフル サービスの場合)。Services are easily partitioned (especially in the stateful case) to ensure that the service can scale and handle partial failures. コードを使用してサービスを動的に作成および削除できるので、顧客の要求に応答する場合など、必要に応じて多くのインスタンスをスピンアップできます。Services can be created and deleted dynamically via code, enabling more instances to be spun up as necessary, for example in response to customer requests. 最後に、Service Fabric では、サービスが軽量になる傾向があります。Finally, Service Fabric encourages services to be lightweight. Service Fabric では、数千単位のサービスを、すべての OS インスタンスやプロセスを単一のサービス インスタンスに使用するのではなく、1 つのプロセス内でプロビジョニングできます。Service Fabric allows thousands of services to be provisioned within a single process, rather than requiring or dedicating entire OS instances or processes to a single instance of a service.
  • 整合性 - リライアブル サービスに格納されているすべての情報の一貫性が保証されます。Consistency - Any information stored in a Reliable Service can be guaranteed to be consistent. これは、サービス内の複数のリライアブル コレクション間であっても当てはまります。This is true even across multiple Reliable Collections within a service. トランザクションによるアトミックな方法で、サービス内のコレクションに対して変更を行うことができます。Changes across collections within a service can be made in a transactionally atomic manner.

サービスのライフサイクルService lifecycle

サービスがステートフルかステートレスかにかかわらず、Reliable Services は、コードをすばやく追加して使用開始できるというシンプルなライフサイクルを提供します。Whether your service is stateful or stateless, Reliable Services provide a simple lifecycle that lets you quickly plug in your code and get started. 新しいサービスを稼働状態にするには、次の 2 つのメソッドを実装する必要があります。Getting a new service up and running requires you to implement two methods:

  • CreateServiceReplicaListeners/CreateServiceInstanceListeners : このメソッドでは、サービスで使用される通信スタックが定義されます。CreateServiceReplicaListeners/CreateServiceInstanceListeners - This method is where the service defines the communication stack(s) that it wants to use. この通信スタック (Web APIなど) によって、サービスをリッスンするエンドポイント (クライアントによるサービスのアクセス方法) が定義されます。The communication stack, such as Web API, is what defines the listening endpoint or endpoints for the service (how clients reach the service). また、表示されるメッセージがサービス コードの残りの部分とやり取りする方法も定義されます。It also defines how the messages that appear interact with the rest of the service code.
  • RunAsync - このメソッドでは、サービスがそのビジネス ロジックを実行し、サービスの有効期間中に実行する必要があるすべてのバックグラウンド タスクを開始します。RunAsync - This method is where your service runs its business logic, and where it would kick off any background tasks that should run for the lifetime of the service. ここで提供されているキャンセル トークンは、そのサービス実行を停止する信号となります。The cancellation token that is provided is a signal for when that work should stop. たとえば、サービスで Reliable Queue からメッセージを取得して処理する必要がある場合は、ここでサービスが実行されます。For example, if the service needs to pull messages out of a Reliable Queue and process them, this is where that work happens.

Reliable Services をはじめて学習している場合は、読み進めてください。If you're learning about reliable services for the first time, read on! Reliable Services のライフサイクルの詳細なチュートリアルを探している場合は、「Reliable Services のライフサイクルの概要」をご覧ください。If you're looking for a detailed walkthrough of the lifecycle of reliable services, check out Reliable Services lifecycle overview.

サービスの例Example services

ステートレス サービスとステートフル サービスの両方で Reliable Services モデルがどのように動作するかを詳しく説明します。Let's take a closer look how the Reliable Services model works with both stateless and stateful services.

ステートレス Reliable ServiceStateless Reliable Services

"ステートレス サービス" とは、複数の呼び出しにまたがるサービス内で状態が維持されないサービスです。A stateless service is one where there is no state maintained within the service across calls. 表示される任意の状態は、完全に破棄可能で、同期、レプリケーション、永続化、または高可用性を必要としません。Any state that is present is entirely disposable and doesn't require synchronization, replication, persistence, or high availability.

たとえば、メモリのない電卓が、同時に処理する必要があるすべての項と演算を受け取る場合を考えてみてください。For example, consider a calculator that has no memory and receives all terms and operations to perform at once.

この場合は、サービスの RunAsync() (C#) または runAsync() (Java) を空にしておくことができます。これは、サービスが実行する必要のあるバック グラウンドのタスク処理がないためです。In this case, the RunAsync() (C#) or runAsync() (Java) of the service can be empty, since there is no background task-processing that the service needs to do. 電卓サービスを作成すると、ICommunicationListener (C#) または CommunicationListener (Java) (たとえば Web API) が返され、このメソッドが任意のポートでリッスン エンドポイントを開始します。When the calculator service is created, it returns an ICommunicationListener (C#) or CommunicationListener (Java) (for example Web API) that opens up a listening endpoint on some port. このリッスン エンドポイントは、電卓のパブリック API を定義するさまざまな計算メソッド (例:"Add(n1, n2)") に接続します。This listening endpoint hooks up to the different calculation methods (example: "Add(n1, n2)") that define the calculator's public API.

クライアントから呼び出しが行われた場合は、適切なメソッドが呼び出され、電卓サービスは提供されたデータに対する演算を実行して、結果を返します。When a call is made from a client, the appropriate method is invoked, and the calculator service performs the operations on the data provided and returns the result. この処理では、状態はまったく保存されません。It doesn't store any state.

内部の状態がまったく保存されないため、この電卓の例はシンプルです。Not storing any internal state makes this example calculator simple. ただし、大半のサービスは実際にはステートレスではありません。But most services aren't truly stateless. 状態が外部ストアに格納されているためですInstead, they externalize their state to some other store. (たとえば、セッション状態をバッキング ストアまたはキャッシュに保持している任意の Web アプリはステートレスではありません)。(For example, any web app that relies on keeping session state in a backing store or cache is not stateless.)

Service Fabric でのステートレス サービスの使用方法を示す一般的な例は、Web アプリケーションの公開 API を公開するフロントエンド サービスです。A common example of how stateless services are used in Service Fabric is as a front-end that exposes the public-facing API for a web application. フロントエンド サービスは、ステートフル サービスと通信してユーザーの要求を完了します。The front-end service then talks to stateful services to complete a user request. この場合、クライアントからの呼び出しは、ポート 80 など、ステートレス サービスがリッスンしている既知のポートに送られます。In this case, calls from clients are directed to a known port, such as 80, where the stateless service is listening. このステートレス サービスは呼び出しを受信し、その呼び出しが信頼できる利用者からのものかどうかと、どのサービスに向けて送信されたのかを判断します。This stateless service receives the call and determines whether the call is from a trusted party and which service it's destined for. 次にステートレス サービスは、その呼び出しをステートフル サービスの正しいパーティションに転送して、応答を待ちます。Then, the stateless service forwards the call to the correct partition of the stateful service and waits for a response. ステートレス サービスは、応答を受信すると、元のクライアントに応答します。When the stateless service receives a response, it replies to the original client. リポジトリにある Service Fabric サンプルの 1 つである "Service Fabric 使用開始" サンプル (C# / Java) は、このようなサービスの例です。An example of such a service is the Service Fabric Getting Started sample (C# / Java), among other Service Fabric samples in that repo.

ステートフル Reliable ServiceStateful Reliable Services

"ステートフル サービス" は、サービス提供するために、状態の一部の整合性を維持して永続化しておかなければならないサービスです。A stateful service is one that must have some portion of state kept consistent and present in order for the service to function. 受け取る最新情報に基づいて値の移動平均を常に計算するサービスを考えてみてください。Consider a service that constantly computes a rolling average of some value based on updates it receives. このサービスを提供するには、最新の平均と、処理する必要がある一連の現在の受信要求が必要になります。To do this, it must have the current set of incoming requests it needs to process and the current average. 情報を取得、処理して、外部ストア (現時点では Azure BLOB やテーブル ストアなど) に格納するサービスはどれもステートフル サービスです。Any service that retrieves, processes, and stores information in an external store (such as an Azure blob or table store today) is stateful. その状態は外部の状態ストアに保持されます。It just keeps its state in the external state store.

現在のほとんどのサービスでは状態が外部ストアに格納されますが、その理由は、その状態の信頼性、可用性、スケーラビリティ、および整合性を提供できるのが外部ストアであるためです。Most services today store their state externally, since the external store is what provides reliability, availability, scalability, and consistency for that state. Service Fabric では、サービスが外部に状態を格納する必要はありません。In Service Fabric, services aren't required to store their state externally. サービス コードとサービス状態の両方の要件に Service Fabric が対応します。Service Fabric takes care of these requirements for both the service code and the service state.

たとえば、イメージを処理するサービスを記述するとします。Let's say we want to write a service that processes images. これを行うには、サービスはイメージを取り込んで、そのイメージに対して一連の変換を実行します。To do this, the service takes in an image and the series of conversions to perform on that image. このサービスは、ConvertImage(Image i, IList<Conversion> conversions) のような API を公開する通信リスナー (WebAPI と仮定しましょう) を返します。This service returns a communication listener (let's suppose it's a WebAPI) that exposes an API like ConvertImage(Image i, IList<Conversion> conversions). サービスは要求を受信すると、IReliableQueue に格納して、要求を追跡できるように、クライアントになんらかの ID を返します。When it receives a request, the service stores it in a IReliableQueue, and returns some ID to the client so it can track the request.

このサービスでは、RunAsync() がもっと複雑になる可能性があります。In this service, RunAsync() could be more complex. サービスの RunAsync() の中にループがあり、IReliableQueue から要求を取り出して、要求された変換を実行します。The service has a loop inside its RunAsync() that pulls requests out of IReliableQueue and performs the conversions requested. 結果は IReliableDictionary に格納されるので、クライアントは戻ったときに、変換されたイメージを取り出すことができます。The results get stored in an IReliableDictionary so that when the client comes back they can get their converted images. 何らかの障害が発生した場合でもイメージが失われないように、この Reliable Service では情報がキューから取得され、変換された後にすべての結果が 1 つのトランザクションに格納されます。To ensure that even if something fails the image isn't lost, this Reliable Service would pull out of the queue, perform the conversions, and store the result all in a single transaction. この場合、キューからメッセージが削除され、変換が完了したときにだけ結果が結果ディクショナリに格納されます。In this case, the message is removed from the queue and the results are stored in the result dictionary only when the conversions are complete. 代わりに、サービスが、イメージをキューから取り出して、すぐにリモートのストアに格納することもできます。Alternatively, the service could pull the image out of the queue and immediately store it in a remote store. こうすると、サービスが管理しなければならない状態の量は減りますが、リモート ストアを管理するために必要なメタデータをサービスが保持しなければならないため複雑さが増します。This reduces the amount of state the service has to manage, but increases complexity since the service has to keep the necessary metadata to manage the remote store. いずれの方法でも、途中で何かが失敗した場合は、要求は処理待ちの状態でキューに残ります。With either approach, if something failed in the middle the request remains in the queue waiting to be processed.

このサービスは一般的な .NET サービスのように見えますが、異なる点は、使用されているデータ構造 (IReliableQueue および IReliableDictionary) が Service Fabric によって提供されているため、信頼性、可用性、および整合性が高いということです。Although this service sounds like a typical .NET service, the difference is that the data structures being used (IReliableQueue and IReliableDictionary) are provided by Service Fabric, and are highly reliable, available, and consistent.

Reliable Services API を使用するタイミングWhen to use Reliable Services APIs

次のような場合は、Reliable Services API の使用を検討します。Consider Reliable Services APIs if:

  • サービスのコード (および必要に応じて状態) の可用性と信頼性を高めたい。You want your service's code (and optionally state) to be highly available and reliable.
  • 複数の状態にまたがるトランザクション上の保証が必要 (たとえば、注文や注文品目)。You need transactional guarantees across multiple units of state (for example, orders and order line items).
  • アプリケーションの状態を、Reliable Dictionary と Reliable Queue として自然にモデル化することができる。Your application’s state can be naturally modeled as Reliable Dictionaries and Queues.
  • アプリケーション コードまたは状態で、待機時間が短い読み取りと書き込みの可用性を高める必要がある。Your applications code or state needs to be highly available with low latency reads and writes.
  • アプリケーションでは、1 つ以上の Reliable Collection に対して、トランザクション操作のコンカレンシーまたは粒度を制御する必要がある。Your application needs to control the concurrency or granularity of transacted operations across one or more Reliable Collections.
  • サービスの通信を管理するか、パーティション構成を制御したい。You want to manage the communications or control the partitioning scheme for your service.
  • コードにはフリー スレッドの実行時環境が必要である。Your code needs a free-threaded runtime environment.
  • アプリケーションで、実行時に Reliable Dictionary または Reliable Queue またはサービス全体を動的に作成または破棄する必要がある。Your application needs to dynamically create or destroy Reliable Dictionaries or Queues or whole Services at runtime.
  • サービスの状態について、Service Fabric が提供するバックアップ機能および復元機能をプログラムによって制御する必要がある。You need to programmatically control Service Fabric-provided backup and restore features for your service’s state.
  • アプリケーションで、複数の状態に関する変更履歴を維持する必要がある。Your application needs to maintain change history for its units of state.
  • カスタム状態プロバイダーを開発するか、サード パーティが開発したカスタム状態プロバイダーを使用したい。You want to develop or consume third-party-developed, custom state providers.

次のステップNext steps