マイクロサービスの手法を使用してアプリケーションを構築する理由は何ですか。Why use a microservices approach to building applications?

ソフトウェア開発者にとって、アプリケーションを構成要素化することは何も新しいことではありません。For software developers, factoring an application into component parts is nothing new. 通常、バックエンド ストア、ミドル層ビジネス ロジック、フロントエンド ユーザー インターフェイス (UI) による階層型のアプローチが使用されています。Typically, a tiered approach is used, with a back-end store, middle-tier business logic, and a front-end user interface (UI). ここ数年で変化 した ことは、開発者がクラウドのために分散アプリケーションを構築しているということです。What has changed over the last few years is that developers are building distributed applications for the cloud.

変化するビジネス ニーズには次のようなものがあります。Here are some changing business needs:

  • 新しい地理的地域の顧客にアプローチできるように、大規模なサービスを構築して運用する。A service that's built and operated at scale to reach customers in new geographic regions.
  • 顧客の要望にアジャイルに応答する機能を短期間で届ける。Faster delivery of features and capabilities to respond to customer demands in an agile way.
  • リソース利用率を改善し、コストを下げる。Improved resource utilization to reduce costs.

これらのビジネス ニーズが、アプリケーションの構築 方法 に影響します。These business needs are affecting how we build applications.

マイクロサービスに対する Azure のアプローチの詳細については、「Microservices: An application revolution powered by the cloud. (マイクロサービス: クラウドによって実現されるアプリケーションの革命)」を参照してください。For more information about the Azure approach to microservices, see Microservices: An application revolution powered by the cloud.

モノリシックとマイクロサービスのデザイン アプローチの比較Monolithic vs. microservices design approach

アプリケーションは時間の経過に伴って進化します。Applications evolve over time. 成功したアプリケーションは便利であることで進化します。Successful applications evolve by being useful to people. 失敗したアプリケーションは進化せず、最終的には非推奨となります。Unsuccessful applications don't evolve and are eventually deprecated. 問題は、現在の要件についての知識と、その要件が将来どうなるかということです。Here's the question: how much do you know about your requirements today and what they'll be in the future? たとえば、企業のある部署のためにレポート アプリケーションを構築するとします。For example, let's say you're building a reporting application for a department in your company. そのアプリケーションは社内のみで使用され、レポートの保持期間は長くないことがわかっているとします。You're sure the application applies only within the scope of your company and that the reports won't be kept long. 選択する手法は、たとえば、数千万の顧客にビデオ コンテンツを配信するサービスを構築する場合とは異なります。Your approach will be different from that of, say, building a service that delivers video content to tens of millions of customers.

概念実証として何かを外に出すことが推進要因となる場合もあります。Sometimes, getting something out the door as a proof of concept is the driving factor. 後ほどアプリケーションを再設計できることはわかっています。You know the application can be redesigned later. 利用されることがない過剰なエンジニアリングには意味がありません。There's little point in over-engineering something that never gets used. 一方、企業がクラウドを構築する場合は、成長と利用が期待されます。On the other hand, when companies build for the cloud, the expectation is growth and usage. その成長と規模が予想できません。Growth and scale are unpredictable. 早期に試作品を作成し、同時に、将来の成功を操作できる道を歩んでいることを確認することが望まれます。We want to prototype quickly while also knowing that we're on a path that can handle future success. これが、構築、測定、学習、繰り返しからなるリーン スタートアップ手法です。This is the lean startup approach: build, measure, learn, and iterate.

クライアント/サーバーの時代には、各層で特定の技術を利用する階層型アプリケーションを構築する傾向にありました。During the client/server era, we tended to focus on building tiered applications by using specific technologies in each tier. このような手法を表現するために、モノリシック アプリケーションという言葉が登場しました。The term monolithic application has emerged to describe these approaches. インターフェイスが階層間に置かれ、各層内のコンポーネント間ではより密接に結合した設計が使用されるようになりました。The interfaces tended to be between the tiers, and a more tightly coupled design was used between components within each tier. 開発者はライブラリにコンパイルするクラスを設計して要素化し、リンクしていくつかの実行可能ファイルや dll を作成していました。Developers designed and factored classes that were compiled into libraries and linked together into a few executable files and DLLs.

モノリシック設計の手法には長所があります。There are benefits to a monolithic design approach. 多くの場合、モノリシック アプリケーションは設計がより単純になり、プロセス間通信 (IPC) 経由となるためコンポーネント間の呼び出しが速くなります。Monolithic applications are often simpler to design, and calls between components are faster because these calls are often over interprocess communication (IPC). また、各自が 1 つの製品をテストするため、人的リソースをより効率よく使用できます。Also, everyone tests a single product, which tends to be a more efficient use of human resources. 欠点は、階層化されたレイヤーが密接に結合されることになり、個々のコンポーネントを拡張できないことです。The downside is that there's a tight coupling between tiered layers, and you can't scale individual components. 修正やアップグレードを行う場合、他の開発者がテストを完了するのを待たなければなりません。If you need to do fixes or upgrades, you have to wait for others to finish their testing. アジャイルを実現するのは困難です。It's harder to be agile.

マイクロサービスはこのような欠点に対処しており、前述のビジネス要件に合わせて調整されています。Microservices address these downsides and more closely align with the preceding business requirements. しかし、利点と欠点の両方がある点は変わりません。But they also have both benefits and liabilities. マイクロサービスの利点は、通常は各マイクロサービスで単純なビジネス機能をカプセル化し、それぞれを独立して拡大縮小、試験、デプロイ、管理できることです。The benefits of microservices are that each one typically encapsulates simpler business functionality, which you can scale up or down, test, deploy, and manage independently. マイクロサービス手法の重要な利点の 1 つは、チームが技術主導ではなくビジネス シナリオ主導であることです。One important benefit of a microservices approach is that teams are driven more by business scenarios than by technology. 小規模のチームが好みの技術を利用し、顧客シナリオに基づいてマイクロサービスを開発します。Smaller teams develop a microservice based on a customer scenario and use any technologies that they want to use.

言い換えれば、組織はマイクロサービス アプリケーションを維持する目的で技術を標準化する必要がありません。In other words, the organization doesn’t need to standardize tech to maintain microservice applications. サービスを所有する個々のチームは、チームの専門知識に基づくチームに適したアクションや、解決する必要のある問題に最適なアクションを実行できます。Individual teams that own services can do what makes sense for them based on team expertise or what’s most appropriate to solve the problem. 実際には、特定の NoSQL ストアや Web アプリケーション フレームワークなど、一連の推奨技術を用意することが望ましくなります。In practice, a set of recommended technologies, like a particular NoSQL store or web application framework, is preferable.

マイクロサービスの欠点には、多数の個々のエンティティの管理、複雑化したデプロイの処理とバージョン管理などがあります。The downside of microservices is that you have to manage more separate entities and deal with more complex deployments and versioning. マイクロサービス間のネットワーク トラフィックや、対応するネットワークの待ち時間も増加します。Network traffic between the microservices increases, as do the corresponding network latencies. 煩雑で細かなサービスが多いことは、パフォーマンス上の悩みの種です。Lots of chatty, granular services can cause a performance nightmare. 依存関係を表示するための支援ツールがなければ、システム全体を見ることが困難になります。Without tools to help you view these dependencies, it's hard to see the whole system.

マイクロサービス手法を機能させるには、標準が必要です。標準では、通信方法を指定し、厳密なコントラクトではなく、サービスから必要となるものだけを許容します。Standards make the microservices approach work by specifying how to communicate and tolerating only the things you need from a service, rather than rigid contracts. サービスは互いに独立して更新されるため、設計でこうしたつながりをあらかじめ定義することが重要です。It's important to define these contracts up front in the design because services update independently of each other. マイクロサービス手法による設計を別の言葉で表現すると "詳細なサービス指向アーキテクチャ (SOA)" となります。Another description coined for designing with a microservices approach is “fine-grained service-oriented architecture (SOA).”

簡単に言うと、マイクロサービスの設計手法とは、サービスの切り離されたフェデレーションであり、各サービスの変更が独立して行われ、合意に基づく通信標準が使用されます。At its simplest, the microservices design approach is about a decoupled federation of services, with independent changes to each and agreed-upon standards for communication.

生成されるクラウド アプリケーションの数が増えるにつれ、アプリケーション全体を独立したシナリオ中心のサービスに分割するこの手法が、長期的には優れた手法であることが明らかになってきています。As more cloud applications are produced, people have discovered that this decomposition of the overall application into independent, scenario-focused services is a better long-term approach.

アプリケーション開発手法の比較Comparison between application development approaches

Service Fabric プラットフォーム アプリケーションの開発

  1. モノリシック アプリケーションにはドメイン固有の機能が含まれ、通常は、Web、ビジネス、データなどの、機能層で分割されます。A monolithic application contains domain-specific functionality and is normally divided into functional layers like web, business, and data.

  2. 複数のサーバー/仮想マシン/コンテナーでクローンを作成することで、モノリシック アプリケーションを拡張します。You scale a monolithic application by cloning it on multiple servers/virtual machines/containers.

  3. マイクロサービス アプリケーションは機能をより小規模の個別サービスに分割します。A microservice application separates functionality into separate smaller services.

  4. マイクロサービス手法では、各サービスを個別にデプロイすることで拡張し、サーバー/仮想マシン/コンテナーにわたってこれらのサービスのインスタンスを作成します。The microservices approach scales out by deploying each service independently, creating instances of these services across servers/virtual machines/containers.

マイクロサービス手法による設計はあらゆるプロジェクトに適しているわけではありませんが、前述のビジネスの目的により厳密に合わせることができます。Designing with a microservices approach isn't appropriate for all projects, but it does align more closely with the business objectives described earlier. 後でマイクロサービス設計用にコードを書き直す機会があることがわかっている場合は、モノリシック手法を最初から使用する方法が合理的かもしれません。Starting with a monolithic approach might make sense if you know you'll have the opportunity to rework the code later into a microservices design. 一般的には、モノリシック アプリケーションを作成し、それを段階的に徐々に分割します。その場合、スケーラビリティまたは迅速性を向上させる必要がある機能領域から始めます。More commonly, you begin with a monolithic application and slowly break it up in stages, starting with the functional areas that need to be more scalable or agile.

マイクロサービス手法を使用する場合、多数の小規模サービスでアプリケーションを構成します。When you use a microservices approach, you compose your application of many small services. これらのサービスは、マシンのクラスター全体にデプロイされたコンテナーで実行します。These services run in containers that are deployed across a cluster of machines. 小規模のチームが 1 つのシナリオに重点を置くサービスを開発し、個別にテスト、バージョン管理、デプロイ、拡張するため、アプリケーション全体を進化させることができます。Smaller teams develop a service that focuses on a scenario and independently test, version, deploy, and scale each service so the entire application can evolve.

マイクロサービスとは何か。What is a microservice?

マイクロ サービスにはさまざまな定義があります。There are different definitions of microservices. ただし、マイクロサービスの次の特性の多くは一般に受け入れられています。But most of these characteristics of microservices are widely accepted:

  • 顧客またはビジネス シナリオをカプセル化します。Encapsulate a customer or business scenario. 対処している問題の種類What problem are you solving?
  • 小規模のエンジニアリング チームが開発します。Developed by a small engineering team.
  • あらゆるプログラミング言語で記述し、あらゆるフレームワークを使用できます。Written in any programming language, using any framework.
  • 個別にバージョン管理、デプロイ、拡張されるコードとステート (任意) で構成されます。Consist of code, and optionally state, both of which are independently versioned, deployed, and scaled.
  • 適切に定義されたインターフェイスとプロトコルで他のマイクロサービスと通信します。Interact with other microservices over well-defined interfaces and protocols.
  • 場所の解決に使用される一意の名前 (URL) があります。Have unique names (URLs) that are used to resolve their location.
  • エラーが発生しても、一貫性を維持し、利用できます。Remain consistent and available in the presence of failures.

以上の内容をまとめます。To sum that up:

マイクロサービス アプリケーションは、適切に定義されたインターフェイスと標準プロトコルで互いに通信する、個別にバージョン管理され、拡張可能な小規模の顧客中心サービスから構成されます。Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces.

あらゆるプログラミング言語で記述し、あらゆるフレームワークを使用できます。Written in any programming language, using any framework

開発者は、技能と作成するサービスのニーズに合わせ、言語やフレームワークを自由に選択できなければなりません。As developers, we want to be free to choose a language or framework, depending on our skills and the needs of the service that we're creating. サービスによっては、C++ の持つパフォーマンス上の利点が他のすべてのものより重視されることがあります。For some services, you might value the performance benefits of C++ above anything else. C# や Java の持つ管理開発の容易さが重要になる場合もあります。For others, the ease of managed development that you get from C# or Java might be more important. 場合によっては、特定のパートナー ライブラリ、データ ストレージ技術、クライアントにサービスを公開する手法が必要になります。In some cases, you might need to use a specific partner library, data storage technology, or method for exposing the service to clients.

技術を選択したら、サービスの運用管理またはライフサイクル管理と拡張について検討する必要があります。After you choose a technology, you need to consider the operational or life-cycle management and scaling of the service.

コードとステートを個別にバージョン管理、デプロイ、および拡張できるようにするAllows code and state to be independently versioned, deployed, and scaled

どのようにマイクロサービスを記述するとしても、コードとステート (任意) を個別にデプロイ、アップグレード、スケーリングする必要があります。No matter how you write your microservices, the code, and optionally the state, should independently deploy, upgrade, and scale. これは、技術の選択に関わるため、解決が難しい問題です。This problem is hard to solve because it comes down to your choice of technologies. 拡張に関しては、コードとステートの両方のパーティショニング (またはシャーディング) 方法を理解するのは困難です。For scaling, understanding how to partition (or shard) both the code and the state is challenging. コードとステートで別々の技術が使用される場合 (今日、一般的になっています)、マイクロサービスのデプロイメント スクリプトは両方を拡張できるものでなければなりません。When the code and state use different technologies, which is common today, the deployment scripts for your microservice need to be able to scale them both. また、この違いはアジャイル性と柔軟性にも影響するため、一部のマイクロサービスをアップグレードする場合、それらをすべて一度にアップグレードする必要はありません。This separation is also about agility and flexibility, so you can upgrade some of the microservices without having to upgrade all of them at once.

ここで、モノリシックとマイクロサービスのアプローチの比較に戻ってみましょう。Let's return to our comparison of the monolithic and microservices approaches for a moment. 次の図は、ステートを格納するアプローチの違いを示しています。This diagram shows the differences in the approaches to storing state:

2 つのアプローチでのステートの格納State storage for the two approaches

Service Fabric プラットフォームのステート ストレージ

左は、1 つのデータベースと固有のテクノロジの層からなるモノリシック手法です。The monolithic approach, on the left, has a single database and tiers of specific technologies.

右はマイクロサービス手法であり、マイクロサービスが相互に接続されています。一般的にステートの対象はマイクロサービスであり、さまざまなテクノロジが利用されます。The microservices approach, on the right, has a graph of interconnected microservices where state is typically scoped to the microservice and various technologies are used.

モノリシック手法では、通常、1 つのデータベースがアプリケーションに利用されます。In a monolithic approach, the application typically uses a single database. 1 つのデータベースを使用する長所はこれが単一の場所であり、デプロイが簡単になることです。The advantage to using one database is that it's in a single location, which makes it easy to deploy. 各コンポーネントには、そのステートを格納するテーブルを 1 つ与えることができます。Each component can have a single table to store its state. 難点は、チームが厳密にステートを分離しなければならないことです。Teams need to strictly separate state, which is a challenge. そのため、必然的に、既存の顧客テーブルに列を追加し、テーブル間で結合を行い、ストレージ層で依存関係を作ってしまう傾向にあります。Inevitably, someone will be tempted to add a column to an existing customer table, do a join between tables, and create dependencies at the storage layer. このような場合、個々のコンポーネントを拡張することはできません。After this happens, you can't scale individual components.

マイクロサービス手法では、各サービスがそのステートを管理し、格納します。In the microservices approach, each service manages and stores its own state. 各サービスが、サービスの要求に応じてコードとステートの両方をまとめて拡張する役割を担います。Each service is responsible for scaling both code and state together to meet the demands of the service. 欠点は、アプリケーション データのビュー (またはクエリ) を作成する必要がある場合、複数のステート ストアにわたりクエリを実行しなければならないということです。A downside is that when you need to create views, or queries, of your application’s data, you need to query across multiple state stores. 通常、この問題は、マイクロサービスの集合全体でビューを構築する個別のマイクロサービスを用意することで解決されます。This problem is typically solved by a separate microservice that builds a view across a collection of microservices. データに対して複数の即席のクエリを実行する必要がある場合、各マイクロサービスでは、オフライン分析のためにデータ ウェアハウス サービスにそのデータを書き込むことを検討する必要があります。If you need to run multiple impromptu queries on the data, you should consider writing each microservice’s data to a data warehousing service for offline analytics.

マイクロサービスは、バージョン管理されます。Microservices are versioned. 異なるバージョンのマイクロサービスを組み合わせて実行することができます。It's possible for different versions of a microservice to run side by side. 新しいバージョンのマイクロサービスはアップグレード中にエラーを起こす可能性があるので、以前のバージョンにロールバックできるようにする必要があります。A newer version of a microservice could fail during an upgrade and need to be rolled back to an earlier version. バージョン管理は、異なるユーザーが異なるバージョンのサービスを試す場合の、A/B 試験にも役立ちます。Versioning is also helpful for A/B testing, where different users experience different versions of the service. たとえば、特定の集合の顧客に対してマイクロサービスをアップグレードし、新しい機能をテストしてからより広い範囲でロールアウトするのが一般的です。For example, it's common to upgrade a microservice for a specific set of customers to test new functionality before rolling it out more widely.

明確に定義されたインターフェイスとプロトコルで他のマイクロサービスと通信しますInteracts with other microservices over well-defined interfaces and protocols

この 10 年間で、サービス指向アーキテクチャの通信パターンに関する情報が数多く公開されています。Over the past 10 years, extensive information has been published describing communication patterns in service-oriented architectures. 一般的に、サービス通信には HTTP と TCP プロトコル、およびシリアル化形式として XML または JSON を適用する REST 手法を使用することになります。Generally, service communication uses a REST approach with HTTP and TCP protocols and XML or JSON as the serialization format. インターフェイスの観点では、Web 設計手法を採用することになります。From an interface perspective, it's about taking a web design approach. ただし、バイナリ プロトコルや独自のデータ形式を使用しても問題はありません。But nothing should stop you from using binary protocols or your own data formats. ただし、これらのプロトコルや形式が公開されないと、ユーザーがマイクロサービスを使用するのに苦労することになります。Just be aware that people will have a harder time using your microservices if these protocols and formats aren't openly available.

場所の解決に使用される一意の名前 (URL) が与えられるHas a unique name (URL) used to resolve its location

マイクロサービスは、実行される場所に関係なく、アドレス指定できるものでなければなりません。Your microservice needs to be addressable wherever it's running. どのマシンがどのマイクロサービスを実行しているのかわからないようであれば、事態はすぐに悪化する可能性があります。If you're thinking about machines and which one is running a particular microservice, things can go bad quickly.

DNS で特定の URL を特定のマシンに解決するのと同様に、マイクロサービスには、現在地を検出できるようにするための一意の名前が必要です。In the same way that DNS resolves a particular URL to a particular machine, your microservice needs a unique name so that its current location is discoverable. マイクロサービスには、実行されているインフラストラクチャから独立した、アドレス指定可能な名前が必要です。Microservices need addressable names that are independent of the infrastructure they're running on. これは、サービスのデプロイ方法と検出方法の間にやり取りがあることを暗示します。サービス レジストリが必要になるためです。This implies that there's an interaction between how your service is deployed and how it's discovered, because there needs to be a service registry. マシンでエラーが発生したときには、レジストリ サービスによってサービスの移動先がわかるようにする必要があります。When a machine fails, the registry service needs to tell you where the service was moved to.

エラーが発生しても、一貫性を維持し、利用できますRemains consistent and available in the presence of failures

予期しないエラーの対処は、特に分散システムにおいて、解決が最も難しい問題の 1 つです。Dealing with unexpected failures is one of the hardest problems to solve, especially in a distributed system. 開発者として記述するコードの多くは、例外を処理するものです。Much of the code that we write as developers is for handling exceptions. テストの実行中も、大半の時間を例外処理に費やします。During testing, we also spend the most time on exception handling. このプロセスは、エラーを処理するコードを記述する以上に複雑です。The process is more involved than writing code to handle failures. マイクロサービスが実行されているマシンでエラーが発生した場合、どうなるでしょうか。What happens when the machine on which the microservice is running fails? エラーを検出する必要がありますが、それ自体が難しい問題です。You need to detect the failure, which is a hard problem on its own. また、マイクロサービスを再起動する必要もあります。But you also need to restart your microservice.

可用性を維持する必要上、マイクロサービスは故障に強くなければならず、別のマシンで再起動できる必要があります。For availability, a microservice needs to be resilient to failures and able to restart on another machine. これらの回復性の要件だけでなく、データが失われてはならず、データの整合性も維持する必要があります。In addition to these resiliency requirements, data shouldn't be lost, and data needs to remain consistent.

アプリケーションのアップグレード中にエラーが発生した場合、回復性を達成するのは困難です。Resiliency is hard to achieve when failures happen during an application upgrade. マイクロサービスは、デプロイ システムと連動して、回復すればいいだけではありません。The microservice, working with the deployment system, doesn't need to recover. 継続的に新しいバージョンに移行するか、前のバージョンにロールバックして一貫性のある状態を維持できるようにするかを決定する必要があります。It needs to determine whether it can continue to move forward to the newer version or roll back to a previous version to maintain a consistent state. 継続的に移行できる十分なマシンがあるかどうかや、前のバージョンのマイクロサービスを復元する方法などの問題を考慮する必要があります。You need to consider a few questions, like whether enough machines are available to keep moving forward and how to recover previous versions of the microservice. このような決定を行うために、マイクロサービスは正常性情報を送信する必要があります。To make these decisions, you need the microservice to emit health information.

正常性と診断の報告Reports health and diagnostics

明白なようでいて見落とされることがよくありますが、マイクロサービスは正常性と診断について報告する必要があります。It might seem obvious, and it's often overlooked, but a microservice needs to report its health and diagnostics. それがなければ、運用の観点から正常性に関する洞察を得ることはほとんどできません。Otherwise, you have little insight into its health from an operations perspective. 一連の個別サービスで発生する診断イベントの関連付けを行い、マシンのクロック スキューを処理してイベントの発生順序を把握することは困難です。Correlating diagnostic events across a set of independent services, and dealing with machine clock skews to make sense of the event order, is challenging. 同意したプロトコルとデータ形式でマイクロサービスと対話するのと同様に、正常性と診断イベントのログ方法も標準化する必要があります。これにより、クエリや表示を行うためのイベント ストアが最終的に確保されます。In the same way that you interact with a microservice over agreed-upon protocols and data formats, you need to standardize how to log health and diagnostic events that will ultimately end up in an event store for querying and viewing. マイクロサービス手法では、各チームが 1 つのログ形式に同意することが必要です。With a microservices approach, different teams need to agree on a single logging format. アプリケーション全体の診断イベントを表示する場合に、一貫性のある手法が必要になるためです。There needs to be a consistent approach to viewing diagnostic events in the application as a whole.

正常性は診断とは異なります。Health is different from diagnostics. 適切な措置を講じる上でマイクロサービスがその現状を報告するのが正常性です。Health is about the microservice reporting its current state to take appropriate actions. 典型的な例としては、アップグレードとデプロイメントによる可用性の維持があります。A good example is working with upgrade and deployment mechanisms to maintain availability. プロセスのクラッシュやマシンの再起動が発生したため、現在、サービスの状態が正常でないとしても、サービスの動作は引き続き可能な場合があります。Though a service might be currently unhealthy because of a process crash or machine reboot, the service might still be operational. この場合、アップグレードを開始して事態を悪化させてはなりません。The last thing you need is to make the situation worse by starting an upgrade. 最初に調査するか、マイクロサービスに回復時間を与えることが最良の方法です。The best approach is to investigate first or allow time for the microservice to recover. マイクロサービスの正常性イベントにより、得られた十分な情報に基づいて判断することが可能になり、事実上、自己回復サービスを作成できます。Health events from a microservice help us make informed decisions and, in effect, help create self-healing services.

Azure でのマイクロサービスの設計指針Guidance for designing microservices on Azure

Azure でのマイクロサービスの設計と構築に関するガイダンスについては、Azure アーキテクチャ センターをご覧ください。Visit the Azure architecture center for guidance on designing and building microservices on Azure.

マイクロサービス プラットフォームとしての Service FabricService Fabric as a microservices platform

Azure Service Fabric は、Microsoft が箱入り製品 (通常、モノリシック) の提供からサービスの提供に移行する過程で生まれたものです。Azure Service Fabric emerged when Microsoft transitioned from delivering boxed products, which were typically monolithic, to delivering services. Service Fabric は、Azure SQL Database や Azure Cosmos DB などの大規模なサービスを構築し、運用した経験から形成されました。The experience of building and operating large services, like Azure SQL Database and Azure Cosmos DB, shaped Service Fabric. プラットフォームは、これを採用するサービスが増えるにつれ、時間の経過と共に発展してきました。The platform evolved over time as more services adopted it. Service Fabric は Azure だけではなく、スタンドアロン Windows Server デプロイメントでも実行できる必要があったということです。Service Fabric had to run not only in Azure but also in standalone Windows Server deployments.

Service Fabric の目的は、サービスの構築と実行に伴う課題を解決し、チームがマイクロサービス手法でビジネス上の問題を解決できるようにインフラストラクチャ リソースを効率的に使用することです。The aim of Service Fabric is to solve the hard problems of building and running a service and to use infrastructure resources efficiently, so teams can solve business problems by using a microservices approach.

Service Fabric では、マイクロサービス手法を使ったアプリケーションの構築を支援するために、以下のものが提供されます。Service Fabric helps you build applications that use a microservices approach by providing:

  • 障害が発生したサービスのデプロイ、アップグレード、検出、再起動、サービスの検出、メッセージのルーティング、状態の管理、正常性の監視などを行うシステム サービスを提供するプラットフォーム。A platform that provides system services to deploy, upgrade, detect, and restart failed services, discover services, route messages, manage state, and monitor health.
  • コンテナー内で実行するアプリケーションまたはプロセスとして実行されるアプリケーションをデプロイする機能。The ability to deploy applications either running in containers or as processes. Service Fabric は、コンテナーとプロセスのオーケストレーターです。Service Fabric is a container and process orchestrator.
  • マイクロサービスとしてのアプリケーションの構築を支援する高生産性プログラミング API:ASP.NET Core、Reliable Actors、Reliable ServicesProductive programming APIs to help you build applications as microservices: ASP.NET Core, Reliable Actors, and Reliable Services. たとえば、正常性や診断に関する情報が得ることができ、また、組み込みの高可用性を利用することができます。For example, you can get health and diagnostics information, or you can take advantage of built-in high availability.

Service Fabric はサービスの構築方法に依存しないため、任意のテクノロジを利用できます。しかし、マイクロサービスの構築を簡単にする組み込みのプログラミング API が提供されています。Service Fabric is agnostic about how you build your service, and you can use any technology. But it does provide built-in programming APIs that make it easier to build microservices.

既存アプリケーションの Service Fabric への移行Migrating existing applications to Service Fabric

Service Fabric では、既存のコードを再利用し、新しいマイクロサービスを使ってコードを最新化することができます。Service Fabric allows you to reuse existing code and modernize it with new microservices. アプリケーションの最新化には 5 つのステージがあり、どのステージから始めても、またはどのステージで終えてもかまいません。There are five stages to application modernization, and you can start and stop at any stage. 以下のステージがあります。The stages are:

  1. 従来のモノリシック アプリケーションから始めます。Start with a traditional monolithic application.
  2. 移行:Migrate. コンテナーまたはゲスト実行可能ファイルを使って、Service Fabric で既存のコードをホストします。Use containers or guest executables to host existing code in Service Fabric.
  3. 最新化:Modernize. 既存のコンテナー化コードに新しいマイクロサービスを追加します。Add new microservices alongside existing containerized code.
  4. イノベーション:Innovate. ニーズに応じてモノリシック アプリケーションをマイクロサービスに分解します。Break the monolithic application into microservices based on need.
  5. アプリケーションをマイクロサービスに変換します。Transform applications into microservices. 既存のモノリシック アプリケーションを変換するか、完全に新しいアプリケーションを構築します。Transform existing monolithic applications or build new greenfield applications.


これらのステージは、任意の場所で開始および停止できることを忘れないでください。Remember, you can start and stop at any of these stages. 次のステージに進む必要はありません。You don't have to progress to the next stage.

以下では各ステージの例を示します。Let's look at examples for each of these stages.

多くの企業が、2 つの理由で既存のモノリシック アプリケーションをコンテナーにリフト アンド シフトしています。For two reasons, many companies are migrating existing monolithic applications into containers:

  • 既存ハードウェアの統合と削除またはより高密度でアプリケーションを実行することによるコスト削減。Cost reduction, either due to consolidation and removal of existing hardware or due to running applications at higher density.
  • 開発と運用の間の一貫したデプロイ コントラクト。A consistent deployment contract between development and operations.

コストの削減は簡単です。Cost reductions are straightforward. Microsoft は多くの既存アプリケーションをコンテナー化しており、数百万ドルの節約につながっています。At Microsoft, many existing applications are being containerized, leading to millions of dollars in savings. 一貫性のあるデプロイは評価するのが困難ですが同じように重要です。Consistent deployment is harder to evaluate but equally important. 開発者は自分たちに合ったテクノロジを選択できますが、運用部門はアプリケーションのデプロイと管理に 1 つの手法しか受け入れないでしょう。It means that developers can choose the technologies that suit them, but operations will accept only a single method for deploying and managing the applications. これにより、運用部門は、開発者に特定の 1 つのテクノロジだけを選択するよう強制することなく、異なるテクノロジをサポートすることによってもたらされる複雑さを緩和できます。It alleviates operations from having to deal with the complexity of supporting different technologies without forcing developers to choose only certain ones. 基本的に、すべてのアプリケーションは自己完結型のデプロイ イメージにコンテナー化されます。Essentially, every application is containerized into self-contained deployment images.

多くの組織はここで終了します。Many organizations stop here. コンテナーの利点は既に得られており、Service Fabric はデプロイ、アップグレード、バージョン管理、ロールバック、正常性監視などの完全な管理エクスペリエンスを提供しています。They already have the benefits of containers, and Service Fabric provides the complete management experience, including deployment, upgrades, versioning, rollbacks, and health monitoring.

既存のコンテナー化コードに新しいサービスを追加します。Modernization is the addition of new services alongside existing containerized code. 新しいコードを記述する場合は、マイクロサービスのパスを少し戻ることをお勧めします。If you're going to write new code, it's best to take small steps down the microservices path. これにより、新しい REST API エンドポイントまたは新しいビジネス ロジックが追加することになるかもしれません。This could mean adding a new REST API endpoint or new business logic. このようにして、新しいマイクロサービスの構築を開始し、開発してデプロイします。In this way, you start the process of building new microservices and practice developing and deploying them.

マイクロサービス手法では、ビジネス ニーズの変化に対応することができます。A microservices approach accommodates changing business needs. このステージで決定するべきことは、モノリシック アプリケーションを複数のサービスに分割する、つまり革新を始める必要があるかどうかということです。At this stage, you need to decide whether to start splitting the monolithic application into services, or innovating. 従来の例として、ここではワークフロー キューとして使用されているデータベースが処理のボトルネックになっている場合を示します。A classic example here is when a database that you're using as a workflow queue becomes a processing bottleneck. ワークフロー要求の数が増えたら、スケーリングのために作業を分散する必要があります。As the number of workflow requests increases, the work needs to be distributed for scale. スケーリングしない特定のアプリケーションや、頻繁に更新する必要があるアプリケーションについては、マイクロサービスに分割して革新します。Take that particular piece of the application that's not scaling, or that needs to be updated more frequently, and split it out as a microservice and innovate.

アプリケーションをマイクロサービスに変換するTransform applications into microservices
このステージで、アプリケーションは完全なマイクロサービスで構成される、またはマイクロサービスに分割されるようになります。At this stage, your application is fully composed of (or split into) microservices. ここまで来れば、マイクロサービス化の目的は達成しています。To reach this point, you've made the microservices journey. ここから始めることもできますが、マイクロサービス プラットフォームなしで行うのは多大な投資です。You can start here, but to do so without a microservices platform to help you requires a significant investment.

私のアプリケーションにマイクロサービスは適しているでしょうか。Are microservices right for my application?

その可能性はあります。Maybe. Microsoft では、ビジネス上の理由からクラウドの構築を開始するチームが増えるにつれ、チームの多くがマイクロサービスと同様の手法を利用する利点を実感しています。At Microsoft, as more teams began to build for the cloud for business reasons, many of them realized the benefits of taking a microservice-like approach. たとえば、Bing では、長年にわたってマイクロサービスが使用されています。Bing, for example, has been using microservices for years. 他のチームにとって、マイクロサービス手法は新しいものでした。For other teams, the microservices approach was new. チームの主要な得意分野が及ばないところに、解決しなければならない難問があることがわかりました。Teams found that there were hard problems to solve outside of their core areas of strength. そこで Service Fabric がサービス構築技術として注目されました。This is why Service Fabric gained traction as the technology for building services.

Service Fabric の目的は、マイクロサービス アプリケーションの構築の複雑性を減らすことです。複雑性が減れば、多くのコストがかかる再設計を繰り返す必要がなくなります。The objective of Service Fabric is to reduce the complexities of building microservice applications so that you don't have to go through as many costly redesigns. そのため、小規模なものから始めて、必要に応じて拡張し、サービスを廃止したり、新しいサービスを追加したりしながら、お客様の利用状況に合わせて進化する手法がとられています。Start small, scale when needed, deprecate services, add new ones, and evolve with customer usage. 大部分の開発者にマイクロサービスをよりわかりやすくするために解決する必要がある問題がまだ多く残っていることもわかっています。We also know that there are many other problems yet to be solved to make microservices more approachable for most developers. その方向に向かう小さなステップとして、コンテナーとアクター プログラミング モデルの例があります。Containers and the actor programming model are examples of small steps in that direction. さらに多くのイノベーションが登場し、マイクロサービスのアプローチが簡単になることを確信しています。We're sure more innovations will emerge to make a microservices approach easier.

次の手順Next steps