最近、「マイクロサービス」というキーワードがとても気になっている照山です。
かなり時間が経ってしまいましたが、de:code 2015のセッションレポートとマイクロサービスに関する内容を併せてまとめておきたいと思います。
Azure Service Fabricは、4/20に発表されたAzureの新しいPaaS技術ですが、
その前に、Azureを代表するPaaSと言えばCloud Serviceですね。
私がネクストスケープで開発したシステムの99%がCloud ServiceであるWebロールとWorkerロールで動いていると言っても過言ではありません。
クラウドの利点をより多く享受できるのがPaaSを使うことのメリットだと思います。
IaaSでは個々のシステムで、サーバやOS、ネットワークをクラウド上に設計・構築するため、オンプレミスと似たようなインフラの運用・管理が必要になります。
設計段階ではインフラの挙動を意識することはあっても、クラウドを使うからにはインフラの運用からは解放されたいですよね。言い換えると、その分サービスの開発に注力しましょうということです。
AzureのPaaSはCloud 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で他のマイクロサービスと相互作用
- ü 障害時でも論理的に整合性がある
- ü 汎用的なコンテナ内部にホストされる（コード＋構成）
- ü 任意の言語、フレームワークで作成可能
- ü 小規模な開発チームが開発
箇条書きだと、何だか分かりづらいですね・・・
マイクロサービスに関しては、以下の記事も参考になるかと思います。
- Service Fabricが提供する２つのプログラミングモデル
- ü Reliable Services： 複数のサービスとコミュニケーションしてタスクを実行するサービス
- ü Reliable Actors： 独立した小さな並列実行可能なロジック（データと振る舞い）をカプセル化する
Reliable Servicesは外部インターフェースとなるWebAPIをホストする場合などに使えるようです。
Reliable ActorsはCloud ServiceのWorkerロールのような使い方ができるものと理解しました。
それぞれのプログラミングモデルで、ステートレス版とステートフル版が用意されています。
ステートフル版では、クラスタ間でデータを共有して扱うことができます。
ノード障害が発生してもデータが失われません。これは今までに無かった素晴らしい機能ですね。
- Service Fabricを使用するには
現時点ではPreview版です。しかも、Azureにデプロイして実行することはできません。
Visual Studio 2015 RCにSDKを入れると必要なテンプレートが追加され、ローカルでのエミュレーション実行のみが試せます。開発環境のセットアップについては、こちらを参照してください。
以下の記事では、いち早くService Fabricを触った内容が詳しく紹介されています。
「マイクロソフトのMicroservice開発用PaaSが素敵だった件」
- Service FabricはAzureなどの基盤として使われています
Azure SQL Databases, Azure DocumentDB, Cortana, Power BI, Intune, Azure Event Hubsなどの基盤として使われており、既に5年以上の実績があるようです。
- Service Fabricの今後
現在はWindows Server上でのみ実行されるモデルとのことですが、Linux版も提供する予定があるようです。
- まとめ
マイクロサービスの概念は、システムを細粒度のサービスやロジックに分割し、それぞれを疎結合にすることで、開発やテスト、デプロイ、リリース後の変更を容易にする考え方です。
３層アーキテクチャとの違いは、UI/UX、アプリ、データのように、大きく横串に括ってしまわないため、開発チーム間のコミュニケーションロスが少なく、プログラム変更時の影響範囲やリリース対象が小さくなります。
SOAと同じ方向性ですが、クラウドが一般的になってきたことで、煩雑なインフラ運用から解放され、より理想的な形で小さなサービスを疎結合かつスケーラブルに組み合わせることが現実味を帯びてきました。そんなクラウド時代に即して提唱されたアーキテクチャモデルだと言えます。
一方で、１つのサービスが受け持つ範囲が小さくなる分、サービスの数は増加します。それぞれのサービスに対して、並列実行や監視と言ったことも考慮が必要になります。また、１つのサービスがAPIとロジック、データ層までを扱う場合、開発チームが技術的にカバーすべき領域が広がっていきます。
このように既存の組織やスキルだけでは対応しづらいと部分もありますが、スケーラブルなSaaS型アプリケーションや大きく成長するサービスの開発においては、非常に魅力的なアーキテクチャモデルだと思いました。
次世代のPaaS技術であるService Fabricに今後も注目していきます。
