Azure でのマイクロサービス事情～ Azure Service Fabric が必要な理由 ～サイオステクノロジー株式会社

アプリケーションコンサルティンググループ
水倉 良明© SIOS Technology, Inc. All rights Reserved.

2018/2/22

自己紹介
サイオステクノロジー株式会社
技術部

アプリケーションコンサルティンググループ

シニアアーキテクト

水倉 良明

••

クラウド基盤中心にインフラ構築からアプリ開発まで•

データ分析基盤構築•

Webアプリ開発•

API Management

Powered by https://wordart.com/

片道２時間通勤のため、週２～３日のリモートワークに助けられてます© SIOS Technology, Inc. All rights Reserved.

2

Agenda•マイクロサービスのおさらい• メリット• マイクロサービスの難しさ•

Azure Service Fabricとは？
• 概念•
••
•

アーキテクチャ
プログラミングモデル
注意点
クラスタ作成イメージ• デモ•まとめ© SIOS Technology, Inc. All rights Reserved.

3

マイクロサービスのおさらい4マイクロサービスのはじまり• Martin Fowler氏らが2014年に発表した記事により広まったと言われる• “Microservices”~a definition of this new architectural term
• https://martinfowler.com/articles/microservices.html• 小回りの利かないモノリシック（一枚岩）なシステムから疎結合なサービスの集合体へ© SIOS Technology, Inc. All rights Reserved.

5

マイクロサービスが注目されている背景• 目まぐるしい環境変化に即対応することが求められている

Agilityを実現するためのアーキテクチャとして注目
影響範囲の最小化、より細かい粒度でのリリースサイクルを実現して、迅速な開発・運用を実現する© SIOS Technology, Inc. All rights Reserved.

6

マイクロサービスのメリット•

サービス毎に独立した開発・リリースサイクルで迅速な機能改修•

性能とコストの最適化••

サービス（機能）単位でのスケールアップ/アウト•「１VM１アプリ」から「１VM複数サービス」による高密度なコンピューティング

テクノロジーの多様性••

小規模なチームによるスピード感のある開発・運用の実現••

サービス毎に最適な言語、テクノロジーの採用

DevOpsとの相性の良さ

障害の分離
•

機能・リソースの分離による障害影響範囲の最小化© SIOS Technology, Inc. All rights Reserved.

7

理想と現実のギャップ
巨大なモノリスが小さく単純なサービスになる一方・・・
1. マイクロサービス化することが難しい
2. マイクロサービス化できたとしても運用が難しい© SIOS Technology, Inc. All rights Reserved.

8

マイクロサービスの難しさ•

まず、マイクロサービス化することが難しい•

適切なサービス単位、データ単位の見極め• ドメイン分析スキルが必要（Domain-Driven Designなアプローチ）•

疎結合とはいえ、サービス間の依存関係をゼロにできるわけではない• 依存関係を踏まえた設計が必要•

マイクロサービス 化することが目的にならないように・・・• マイクロサービス化によって得られるもの、失うものの見極めが必要• 何のために取り組むのかを見失ってはいけない• アプリケーションによってはデメリットになることも• “Enough with the microservices”
https://aadrake.com/posts/2017-05-20-enough-with-the-microservices.html© SIOS Technology, Inc. All rights Reserved.

9

マイクロサービスの難しさ• マイクロサービス化できたとしても運用が難しい• 分散システムはそもそも複雑なもの• 大量のサービス管理• １つのデプロイではなく、数十、数百ものサービスのデプロイへ• 各サービスのビルド、テスト、デプロイ、シームレスな連携• 各サービスのリソース確保• ネットワークの輻輳と遅延• モノリスではインプロセスの高速な処理• マイクロサービスではアプリへの１つのリクエストがサービスを連鎖的に呼び出す多数の内部リクエストになるケースがある© SIOS Technology, Inc. All rights Reserved.

10マイクロサービスの難しさ• データの整合性• モノリス• 全てのデータが単一のデータベースに格納される• 参照整合性の確保。厳格なトランザクション制御が可能• マイクロサービス• 複数のデータベースに分散• サービス間のデータの完全性を担保することの難しさ• レプリケーションのタイムラグへの対処© SIOS Technology, Inc. All rights Reserved.

11

マイクロサービスの難しさ• テスト• サービスの依存関係によりテストが複雑になる• 複数のサービスが異なるペースでバージョンアップされる中で、一貫した環境を再現することの難しさ• これまで以上に環境への考慮や、自動化への投資が必要• ブルーグリーンデプロイメント• カナリアリリース• ダークカナリアリリース• A/Bテスト• 組織文化• DevOpsが定着していないと安定した運用が困難© SIOS Technology, Inc. All rights Reserved.

12

マイクロサービスの難しさ• 乱立するミドルウェア、周辺ツール群© SIOS Technology, Inc. All rights Reserved.

13

マイクロサービスの難しさにどう挑むか© SIOS Technology, Inc. All rights Reserved.

14

Azure Service Fabricとは？

15

Azure Service Fabric

マイクロサービス時代のPaaS
分散システムの複雑さを高度に抽象化© SIOS Technology, Inc. All rights Reserved.

16

Azure Service Fabricとは？
•

GA開始は2016年3月だが、７年以上のサービス稼働実績• Azureコアインフラ• Azure SQL Database• Azure DocumentDB••••

Azure Event Hubs
CortanaBing
Skype for Business• Power BI

Microsoft社がAzureで培った分散システム技術をサービスとして一般提供したものと言える© SIOS Technology, Inc. All rights Reserved.

17

Azure Service Fabricとは？
•フルマネージドでフルスタックなマイクロサービスフレームワーク••

クラスタ上でサービスを実行、管理するための分散システム基盤
アプリケーションレイヤの各種プログラミングモデルも提供

インフラ
サービスライフ
サイクル管理

デプロ
イ

無停止
アップ
グレー

可用性

アプリケーションスケー
ラビリ

信頼性

各種プログラミングモデル

ティ

冗長化

負荷分
散ド© SIOS Technology, Inc. All rights Reserved.

フェイルオーバ

診断

バックアップ/リスト
ア

柔軟な手動/自動ス
ケーリン
グ

Reliable
ServiceReliable
Actor

ASP.NET Coreコンテ
ナ

実行可
能ファイル
18

Azure Service Fabricアーキテクチャ
Azure Service FabricAzure Container Service

・正常性管理と診断
・テスト容易性フレームワーク

アプリケーションプログラミングモデル
・Stateless/Stateful Service
・Reliable Actor
・正常性モニタリング

通信サブシステム・サービス間通信
・セッション/ストリーム

ホスティング・コンテナーのアクティベーションと監視
・分散とスケジューリング
・リソースの分散と配置

Marathon/Docker Compose

フェデレーションと信頼性

ZooKeeper, Consulなど

・フェイルオーバ管理
・イメージストアサービス
・クラスタ管理

Mesos/Doker Swarm/Kubernetes

・リーダー選出
・ネーミングサービス

コンテナ/サービス管理

クラスタ管理VM拡張機能Azure Virtual Machines, Azure Virtual Machine Scale Sets
Azure Stack (Azure互換のプライベートクラウド)© SIOS Technology, Inc. All rights Reserved.

Azure
出典：「マイクロサービス with Docker on Azure」Boris Scholl他 (著)19

Azure Service Fabricクラスタはどこでも動く• Azure• Azure以外のパブリッククラウド• オンプレミス• OSはWindows Server、Linuxのどちらでも動作• ローカルでも動作。開発環境構築も容易• Azure Service Fabric SDK (※) がローカルクラスタを提供(※) 2017年3月にOSS化© SIOS Technology, Inc. All rights Reserved.

20

Azure Service Fabricアプリの論理構造•

各サービスはどのホストに配置されるかを原則意識しない（※あえて意識することも可能。後述）

Service Fabric Application

NodeService

Service

Service

Code

Node

構成
データ

デプロイ

Node

ServiceService

ServiceServiceService

Code

Code構成

構成

Node

Node

データ

データ

ServiceServiceServiceService© SIOS Technology, Inc. All rights Reserved.

Azure
Service Fabric Cluster

21障害/更新ドメインを考慮したサービス分散• 障害ドメイン• 物理的な障害単位。電源、冷却装置、ネットワークインフラを共有したサーバーリソースの集まり• 更新ドメイン• 論理的な更新単位• 同じ更新ドメインに所属しているサービスインスタンスは同時に停止・更新される• 更新ドメインが別であれば同時に停止・更新されることがない© SIOS Technology, Inc. All rights Reserved.

22

障害/更新ドメインを考慮したノード配置•

最低３つ以上の障害ドメインに分散される•

既定では５ノードのクラスタは５つの障害ドメインと5つの更新ドメインに分散される

障害ドメイン0

障害ドメイン1

障害ドメイン2

障害ドメイン3

障害ドメイン4

更新ドメイン0

更新ドメイン1

更新ドメイン2

更新ドメイン3

更新ドメイン4

Node 0Node 1

Node 2

Node 3

Node 4© SIOS Technology, Inc. All rights Reserved.

23

障害/更新ドメインを考慮したノード配置••

障害ドメインと更新ドメインが一意な組合せになるようにノードが配置されていく
配置条件を指定することも可能（他よりもリソースを必要とするサービスは一定のスペック以上のノードに配置など）

障害ドメイン
0障害ドメイン1障害ドメイン2障害ドメイン3障害ドメイン
4更新ドメイン0

更新ドメイン1更新ドメイン2更新ドメイン3更新ドメイン4

Node 0Node 1

Node 2

Node 3

Node 4

更新ドメイン4更新ドメイン3更新ドメイン1更新ドメイン2

更新ドメイン0

Node 5

Node 6

Node 7

Node 8Node 9

更新ドメイン3
Node 10© SIOS Technology, Inc. All rights Reserved.

24

Azure Service FabricでサポートされるService• Stateless Service• ローカルに状態を保持しない• 状態保持不要、または外部に状態を保持• 分散システムで扱いやすい• Stateful Service• ローカルに状態を保持する• データの同期制御、データ完全性を保証することの難しさがある→ ASFがカバーしてくれる© SIOS Technology, Inc. All rights Reserved.

25

Azure Service Fabricプログラミングモデル• Reliable Service• Reliable Actor• ASP.NET Core
• コンテナ• ゲスト実行可能ファイル© SIOS Technology, Inc. All rights Reserved.

26

PGモデル：Reliable Service – Stateless Serviceメリット•

ASFの全機能の恩恵を受けることができる•

Pluggableな通信プロトコル。複数の通信プロト

デメリット
•

状態を外部へ永続化している場合、状態へのアクセスがステートフルサービスよりも遅くなる

コルでListenすることも可能。
••

HTTPWebSocket

•
•

WCF
カスタムTCPプロトコル© SIOS Technology, Inc. All rights Reserved.

27

PGモデル：Reliable Service – Stateful Service•

状態はレプリケートされ、強い整合性が保証される（トランザクションサポート）••

開発者はサービスに保持したい情報をReliableColletionに保存するだけで自動制御される

Primary Replicaダウン時はSecondaryがPrimaryに昇格する（自動フェイルオーバ）
Node 1Service A(SecondaryReplica)

Node 0Service A(PrimaryReplica)
State

State

Node 2Service A(SecondaryReplica)
State© SIOS Technology, Inc. All rights Reserved.

28

PGモデル：Reliable Service – Stateful Service•

レプリケーションするデータを区切るパーティションもサポート•

Primary Replicaをパーティション毎に保持できることで、Primaryがボトルネックにならない
Node 0Node 1Service A(Primary)

Service A(Secondary)
State

Node 4Service A(Primary)

State

State

<Partition 0><Partition 1>

Service A(Secondary)
State<Partition 1><Partition 0>© SIOS Technology, Inc. All rights Reserved.

Node 2

Node 3Service A(Secondary)

Service A(Secondary)

State

State

<Partition 0><Partition 1>

29

PGモデル：Reliable Service – Stateful Serviceメリット••

Stateless Serviceと同様のメリット
状態をローカルに保持するため、低レイテンシ

デメリット
••

パーティション数を変更することができない
ノード数に対してパーティション数が少ない場で動作

合、ノード数を増やしても性能メリットが得ら•

開発者は状態のレプリケーション制御を意識しれないので注意

•

ないでよい
パーティション機能によって、ステートフルでありながらも容易にスケールアウト可能•例）パーティション数が1000個で、ノード数が10の場合、→ 1ノード当たり100個のパーティションノード数を10から100個に増やした場合、→ 1ノード当たり10個のパーティション（性能メリット有り）※パーティション数が10個の場合、ノードを増やしてもスケールアウトされない© SIOS Technology, Inc. All rights Reserved.

30

PGモデル：ASP.NET Core• OSSクラスプラットフォームなWebフレームワーク• Web アプリ

• IoT アプリ
• モバイル バックエンド• Reliable Service、ゲスト実行可能ファイルの２パターンのホスティングが可能© SIOS Technology, Inc. All rights Reserved.

31

PGモデル：ASP.NET Core
メリット

デメリット

•

Reliable Serviceと同様のメリット•

ゲスト実行可能ファイルとしてデプロイした場可能だが、それぞれ考慮すべきことがあること

合、ASF機能は限定的になるものの、既存のと、Listenerの実装コードに違いが生じるのでASP.NET Coreをコード変更することなく利用注意••

Webサーバ機能にIIS (HttpSys) とKestrelが利用可能•

HttpSysはステートフルでは非推奨

ASP.NET経験者はスキルを活用できる•Kestrelでは複数プロセスでのポート共有はサポートされない※外部公開 or 内部専用、ステートレス or
ステートフルで適切な選択をする
https://docs.microsoft.com/ja-jp/azure/service-fabric/service-fabricreliable-services-communication-aspnetcore© SIOS Technology, Inc. All rights Reserved.

32

PGモデル：Reliable Actor• Reliable Service上でActorモデルを実装可能なフレームワーク• Actorモデル：「すべてはActorである」ととらえて、Actor間のメッセージングを非同期とすることで並行処理を実現する。複雑な分散システムを抽象化できる。

• ASFでは非同期シングルスレッドで動作する• ターンベースの並行性• 単一のActorインスタンスは同時にメソッドが呼び出されない• 複数のActorインスタンスは並行して実行される• マルチスレッドプログラミングの複雑さを抑えつつ、並行性を確保© SIOS Technology, Inc. All rights Reserved.

33

PGモデル：Reliable Actorメリット••

ターンベースの並行性により、非同期並行処理

デメリット
•

高度に抽象化されているとはいえ、デバッグやを非常に容易に実装できる

パフォーマンスチューニングをするには内部のReliable Serviceがベースなため、Stateless/ful仕組みを把握する必要がある（これに限った話共に対応。ASF提供機能を全て利用できるではありませんが・・・）© SIOS Technology, Inc. All rights Reserved.

34

プログラミングモデル：コンテナ• コンテナ• 各種プログラミングモデルをコンテナ内のサービスとしてデプロイ• 既存アプリ（ゲスト実行可能ファイル）• Stateless/Stateful Reliable Service• Reliable Actor• Linux/Windowsコンテナのデプロイをサポート• プロセス内のサービス（＝コンテナ以外のASFサービス）とコンテナ内のサービスを同じアプリケーション内で共存可能© SIOS Technology, Inc. All rights Reserved.

35

PGモデル：コンテナメリット

デメリット

•

既存のASP.NET MVCアプリをASP.NET Coreに移行せずに使い続けることができる••

既存のコンテナイメージを活用できる•

高速な軽量コンテナではあるが、ASFデフォル
トのプロセス実行されるサービスよりはアクティブ化やI/Oが若干ボトルネックになる

例）より多くのバックエンド処理に対応するためにWebフロントエンドにNGINXコンテナを配置する•

同一ノード内の他サービスの影響を軽減できる••コンテナのリソース制限機能を活用することで｀「Noisy Neighbours」問題へ対処

同一アプリケーション内で他ASFサービスとコンテナ内のサービスを共存できる© SIOS Technology, Inc. All rights Reserved.

36

コンテナの種類とサポートされる環境•

Windowsは分離レベルの異なる２つのコンテナを提供•

コンテナ以外のプログラミングモデルではサービスはプロセスとして実行されるクォータ・制限

Linux

仮想マシン
(Xen, KVM)

Dockerコンテナ

プロセスカーネル
WindowsOS

クラス
タ

カーネルを共有しない分離レベル

Windows Serverコンテナ

プロセス

Hyper-V
コンテナ

Hyper-V
仮想マシン

カーネル
より高い性能・効率

より高い分離レベル・セキュリティ

https://docs.microsoft.com/ja-jp/azure/service-fabric/service-fabric-containers-overview#container-types-and-supported-environments© SIOS Technology, Inc. All rights Reserved.

37

PGモデル：ゲスト実行可能ファイル•

既存の任意言語実装のプログラムをサービスとして実行する••

C++, Java, Node.js, PHP, etc.

コードレベルでASFのバイナリを一切参照しないカスタムアプリケーション

メリット

デメリット

••

幅広い言語に対応しているため、既存資産が活用できる恩恵を受けられるASF PaaS機能が限られている••

可用性の向上正常性の監視••ライフサイクル管理
高密度なコンピューティング•

クラスタ内の他サービスへのアクセス（※ASF
REST API呼出が必要）•

ステートフルサービスに対応していない•

既存アプリがステートを保持している場合、手当てが必要© SIOS Technology, Inc. All rights Reserved.

38

PGモデルとStateless/Statefulの対応状況
プログラミングモデル

StatelessStateful

Reliable Service●●

Reliable Actor●●.NET Core●●

ゲスト実行可能ファイルとして配置
した時はそちらに準ずる

コンテナ

--

コンテナ内のPGモデルに準ずる

ゲスト実行可能ファイル●

X© SIOS Technology, Inc. All rights Reserved.

備考39クラスタOSと言語
クラスタOS

ゲスト実行可能 Reliable Service
ファイル
Reliable Actor

コンテナWindowsWindows.NET CoreWindows

LinuxLinux.NET CoreJavaLinux© SIOS Technology, Inc. All rights Reserved.

40Azure Service Fabric開発ツール
開発ツール

OSWindows

Visual StudioPowerShell

LinuxEclipse
Yoeman© SIOS Technology, Inc. All rights Reserved.

41

Azure Service Fabricサービスの監視• Azureサービスと統合されている
レイヤ

監視手段

クラスタ

Azure Monitor
Log Analytics

アプリケーション© SIOS Technology, Inc. All rights Reserved.

Application Insights

42

Azure Service Fabric注意点（2018/2/19時点）• ASFフル機能を利用できるReliable Service/ActorのJavaはWindowsに対応していない（Linux版Eclipseのみ対応）• 特定OSでは未サポートであったり、プレビュー段階のものがあるので、対応状況は要確認• Windows 10での Service Fabricクラスターへのコンテナのデプロ
イは未サポート• プレビュー段階• Docker Compose• Windows Server バージョン 1709はプレビュー版。Open ネットワー
クおよび Service FabricのDNS サービスは機能しない。
© SIOS Technology, Inc. All rights Reserved.

43

Azure Service Fabricクラスターの作成イメージ© SIOS Technology, Inc. All rights Reserved.

44

Azure Service Fabricクラスターの作成イメージ© SIOS Technology, Inc. All rights Reserved.

45

Azure Service Fabricクラスターの作成イメージ© SIOS Technology, Inc. All rights Reserved.

46

Azure Service Fabricクラスターの作成イメージ© SIOS Technology, Inc. All rights Reserved.

47

Azure Service Fabricクラスターの作成イメージ© SIOS Technology, Inc. All rights Reserved.

48

デモ
Backend Services
Stateful Service(Primary)State

Front Web API(ASP.NET Core)Java
ScriptStatelessServiceStateful Service(Primary)
State・・・・・

https://github.com/djzeka/VSTS-AzureServiceFabric© SIOS Technology, Inc. All rights Reserved.

Stateful Service(Primary)
State

Stateful Service(Secondary)
State
Stateful Service(Secondary)
State

Stateful Service(Secondary)
State
Stateful Service(Secondary)State・・・・

Stateful Service(Secondary)
State
Stateful Service(Secondary)
State

49

まとめ
• マイクロサービスは難しい• Azure Service Fabricは、マイクロサービスで考慮すべき“複雑さ”を一定レベルに抑えてくれる• マイクロサービスのハードルを下げて、迅速な開発・運用サイクルのメリットを享受できる• ビジネスの差別化へリソースを集中できる• 適切なドメイン分析による適切なサービス単位の見極めは必要© SIOS Technology, Inc. All rights Reserved.

50

参考資料
•

Azure Service Fabric概要• https://www.slideshare.net/dahatake/azure-service-fabric-69314586•「マイクロサービス with Docker on Azure」• Boris Scholl他 (著) / 佐藤 直生 (監訳) / クイープ (訳)• ISBN：978-4822298845•「プログラミングAzure Service Fabric」• Haishi Bai (著) / 佐藤 直生 (監訳) / クイープ (訳)• ISBN：978-4822298852•

デモ用サンプルコード• https://github.com/djzeka/VSTS-AzureServiceFabric© SIOS Technology, Inc. All rights Reserved.

51

最後に・・・

52

OSS on Azure技術ブログやっていますazure.sios.jp

ビギナー向けの基本情報から現場エンジニアによるディープな技術トピックスまで。
技術を愛する全ての人に。
© SIOS Technology, Inc. All rights Reserved.

53

ビール片手にDB最新情報を！
3月13日（火）19:00 ～ 品川テラスホール

Azure DB for PostgreSQL/MySQL 開発マネージャと話そう！
主催：
OSS on Azure 非公式コミュニティ• Microsoft Azure上におけるOSS利活用推進のためのビジネス＆技術情報共有コミュニティ、Facebook 公開グループです。
• 非公式というのはマイクロソフトさん主導でのコミュニティじゃないよ！という意味合いですが、イベントの度に飲食費用をご支援いただいたりでアレです。

© SIOS Technology, Inc. All rights Reserved.

 来日中の米国マイクロソフト Azure DB for
PostgreSQL/MySQL 開発マネージャへの質問大会
 日本のPostgreSQL/MySQL ユーザ会やその周辺の方々からの最新情報
 当然ですが、ビール＆軽食ありです。（参加費無料）
https://ossonazure.connpass.com/event/80145/

54

ケーキ片手に誕生日パーティを！
2月27日（火）サイオステクノロジーコラボレーションラウンジ

Japan OSS Promotion Forum 2018 + 20th Party for OSS
主催：日本 OSS 推進フォーラム
OSS活用の課題や普及促進をオープンに推進し、産業界全体の発展に寄与することを目的として2004年に発足した民間団体。市場における新たなトレンドなど、最新トピックをテーマとして活動に取り入れ、業界における共通認識の形成・認知の共有、政府提言のとりまとめなどを推進しています。

日本OSS推進フォーラムの年一イベント、来賓講演として経済産業省、基調講演としてプロダクトマネジメント第一人者、AIビジネスの先駆者、各技術部会からの年間活動報
告など、そんな真面目なイベントの情報交換会（要参加費）にて・・・

OSS20歳の誕生日パーティ開催！
東京ガス

スペシャルケーキも鋭意制作中！

https://ossforum.connpass.com/event/77003© SIOS Technology, Inc. All rights Reserved.

55