de:code「Microsoft Azure Service Fabric によるレジリエントなマイクロサービスの構築」セッションレポート

最近、「マイクロサービス」というキーワードがとても気になっている照山です。


かなり時間が経ってしまいましたが、de:code 2015のセッションレポートとマイクロサービスに関する内容を併せてまとめておきたいと思います。


Azure Service Fabricは、4/20に発表されたAzureの新しいPaaS技術ですが、

その前に、Azureを代表するPaaSと言えばCloud Serviceですね。

私がネクストスケープで開発したシステムの99%Cloud ServiceであるWebロールとWorkerロールで動いていると言っても過言ではありません。


クラウドの利点をより多く享受できるのがPaaSを使うことのメリットだと思います。

IaaSでは個々のシステムで、サーバやOS、ネットワークをクラウド上に設計・構築するため、オンプレミスと似たようなインフラの運用・管理が必要になります。

設計段階ではインフラの挙動を意識することはあっても、クラウドを使うからにはインフラの運用からは解放されたいですよね。言い換えると、その分サービスの開発に注力しましょうということです。

 

AzurePaaSCloud Serviceだけではありません。

3月には従来のWeb Sitesを含むApp Serviceが発表され、4月にService Fabricが発表されました。

Cloud Serviceでは、サーバインスタンスをほとんど意識することなく、パッケージ化された制御をAzureが行ってくれていましたが、実際の動作単位はサーバインスタンスであり、そのライフサイクルを考慮した実装が求められます。

App Serviceは、Cloud Serviceと同じ動作単位ですが、より上位のレイヤまでAzure側が制御していて、WebサイトWeb APIモバイルサービスロジック・ワークフローにそれぞれ特化した役割のアプリケーション基盤を提供してくれます。

 

前置きが長くなってしまいましたが、新しいPaaS技術であるService Fabricについて、セッションで説明されていた内容をまとめていきたいと思います。

 

Service Fabricとは

ü  マイクロサービスの考え方に則り、より粒度の小さいUI, Logic, Dataに分割されたサービスを配置するプラットフォーム

ü  クラスタ化された信頼性の高いハイパースケールのプラットフォーム

 

Service Fabricの機能

ü  クラスタ環境へのアプリケーションのデプロイ

ü  ローリングアップデート、ロールバック

ü  バージョニング、複数バージョンの並列動作

ü  サイドバイサイド(並列・独立動作)

ü  リーダーの選出(全体をコーディネートするプロセスが自動決定するという意味かな。)

ü  アプリ発見のためのネーミングサービス

ü  パーティション分割のサポート

等々

 

Service Fabricの仕組み

ü  クラスタを形成する一連のノードから成る

ü  クラスタは数千台にスケール可能

ü  リージョンを跨いだクラスタも可能

ü  FaultDomain / UpdateDomainの考え方はCloud Serviceと同じ

ü  各ノードは隣同士を知っていてリング状態になっている

ü  障害ノードを検出するとリングが再形成される

 

マイクロサービスとは

James Lewis氏、Martin Fowler氏によって提案された概念です。日本語訳されたブログがあります。一言でいうと、「アプリケーションを独立して配置可能なサービスの組み合わせとして設計する特定の方法」と書かれています。

 

マイクロサービスの特徴

ü  データの分散制御

ü  小さなサービス群の組み合わせ

ü  自身のプロセス上で動作

ü  独立してバージョニング、デプロイ、スケールされるロジックと状態

ü  名前解決できる固有の名前を持つ

ü  定義されたIFで他のマイクロサービスと相互作用

ü  障害時でも論理的に整合性がある

ü  汎用的なコンテナ内部にホストされる(コード+構成)

ü  任意の言語、フレームワークで作成可能

ü  小規模な開発チームが開発

 

箇条書きだと、何だか分かりづらいですね・・・

 

マイクロサービスに関しては、以下の記事も参考になるかと思います。

マイクロサービス対モノシリックアプリケーション

マイクロサービス

マイクロサービス移行代償

マイクロサービスとSOA

 

Service Fabricが提供する2つのプログラミングモデル

ü  Reliable Services: 複数のサービスとコミュニケーションしてタスクを実行するサービス

ü  Reliable Actors: 独立した小さな並列実行可能なロジック(データと振る舞い)をカプセル化する

 

Reliable Servicesは外部インターフェースとなるWebAPIをホストする場合などに使えるようです。

Reliable ActorsCloud ServiceWorkerロールのような使い方ができるものと理解しました。

 

それぞれのプログラミングモデルで、ステートレス版とステートフル版が用意されています。

ステートフル版では、クラスタ間でデータを共有して扱うことができます。

ノード障害が発生してもデータが失われません。これは今までに無かった素晴らしい機能ですね。

 

Service Fabricを使用するには

現時点ではPreview版です。しかも、Azureにデプロイして実行することはできません。

Visual Studio 2015 RCSDKを入れると必要なテンプレートが追加され、ローカルでのエミュレーション実行のみが試せます。開発環境のセットアップについては、を参照してください。

 

以下の記事では、いち早くService Fabricを触った内容が詳しく紹介されています。

マイクロソフトのMicroservice開発用PaaSが素敵だった件

 

Service FabricAzureなどの基盤として使われています

Azure SQL Databases, Azure DocumentDB, Cortana, Power BI, Intune, Azure Event Hubsなどの基盤として使われており、既に5年以上の実績があるようです。

 

Service Fabricの今後

現在はWindows Server上でのみ実行されるモデルとのことですが、Linux版も提供する予定があるようです。

 

まとめ

マイクロサービスの概念は、システムを細粒度のサービスやロジックに分割し、それぞれを疎結合にすることで、開発やテスト、デプロイ、リリース後の変更を容易にする考え方です。

 

3層アーキテクチャとの違いは、UI/UX、アプリ、データのように、大きく横串に括ってしまわないため、開発チーム間のコミュニケーションロスが少なく、プログラム変更時の影響範囲やリリース対象が小さくなります。

SOAと同じ方向性ですが、クラウドが一般的になってきたことで、煩雑なインフラ運用から解放され、より理想的な形で小さなサービスを疎結合かつスケーラブルに組み合わせることが現実味を帯びてきました。そんなクラウド時代に即して提唱されたアーキテクチャモデルだと言えます。

 

一方で、1つのサービスが受け持つ範囲が小さくなる分、サービスの数は増加します。それぞれのサービスに対して、並列実行や監視と言ったことも考慮が必要になります。また、1つのサービスがAPIとロジック、データ層までを扱う場合、開発チームが技術的にカバーすべき領域が広がっていきます。


このように既存の組織やスキルだけでは対応しづらいと部分もありますが、スケーラブルなSaaS型アプリケーションや大きく成長するサービスの開発においては、非常に魅力的なアーキテクチャモデルだと思いました。

次世代のPaaS技術であるService Fabricに今後も注目していきます。


ネクストスケープ企業サイトへ

NEXTSCAPE

検索する

タグ

メタデータ

投稿のRSS

著者