NS study8 DDD Microservices Azuer Service Fabric

2016/07/06株式会社ネクストスケープエバンジェリスト　上坂貴志

NSStudy No.8

www.nextscape.net 1

～ C# と Azure Service Fabric で最高の DDD 開発を～

ドメイン駆動設計＆ Azure で行うマイクロサービス開発

www.nextscape.net

アジェンダなぜ今 Microservices なのかMicroservices と DDDDomain-Driven DesignDDD 導入のハードルAzure Service Fabric最後に

2

自己紹介• 会社

株式会社ネクストスケープ

• 名前上坂貴志（うえさかたかし） Twitter:@takashiuesaka

• 年齢44 歳

• 好き・興味ありAzure(Microsoft MVP for Microsoft Azure) 、Scrum （認定スクラムマスター）DDD 、ソフトウェアアーキテクチャ、機械学習

• 講演活動• 2016 年

de:code 2016 DDD & Azure Service Fabric 登壇NS Study No.6 Azure IoTHub 紹介アプレッソ最新 IT 事例セミナー Azure Machine Learning セミナー登壇SANSAN DDD 勉強会発表

• 2015 年FEST2015 (Channel9 で動画公開 )MSxNextscape 合同 Azure Machine Learning セミナー開催Developers Summit 2015QCon 2015CloudDays2015 東京・大阪 3

• 執筆活動• 人工知能アプリケーション総覧寄稿（日経 BP 社、 2015 年 9 月 30 日発売）• ITPro ：クラウドで機械学習を手近に、 Azure Machine Learning の概要

www.nextscape.net 3

会社紹介

www.nextscape.net 4

　設立年月日 2002 年 4 月 10 日　資本金 1 億 5001 万円　主要株主株式会社豆蔵ホールディングス　（東証一部上場）

〒 163-0722東京都新宿区西新宿 2-7-1小田急第一生命ビル 22F03-5325-1301( 代表 )

　　　　　会社紹介

www.nextscape.net 5

　クラウド、デジタルマーケティング、システム構築に強み

（※ 2012 年～ 2014 年マイクロソフトパートナーズオブザイヤー）

2013 Microsoft Worldwide Partner Award において

Sitecore Of The Year Asia 2013 において

　 Cloud Partner of the Year ファイナリスト選出

　 Best Japanese Site を受賞

　 3 年連続 Microsoft Azure パートナーアワード受賞

　　　　　会社紹介

www.nextscape.net 6

タワーレコード様

「 NO MUSIC, NO LIFE. 」のキャッチフレーズでおなじみの、音楽エンタメ・小売り事業の大手。250 万点もの商品を取り扱うオンラインショップ「 TOWER RECORDS ONLINE 」の CMS を Sitecoreで構築。2010 年当時に 1 日当たり 100 万強だった PV は、 2014 年 4 月時点で 205 万強まで倍増。https://www.sitecore.net/ja-jp/customers/e-commerce/towerrecords.aspx

エイベックス通信放送様（　　ｄ TV powerd by BeeTV ）

「 d ビデオ powered by BeeTV 」は、スマートフォン利用者向けに映画、ドラマなどを視聴可能な国内最大規模の動画配信サイトとして注目を集めている。Microsoft Azure にて、高負荷・ハイパフォーマンスに耐えうるスケーラブルな配信インフラを構築。http://special.nikkeibp.co.jp/as/201207/mpncompetency/cs01.html

400 万会員を超える動画サイトの配信インフラを構築

EC 売上を 3 年間で 2 倍以上にしたタワーレコードの成長を支えた CMS 基盤を導入

なぜ今Microservices なのか

なぜ今 Microservices なのか

www.nextscape.net 8

サービス切り出し指針がなかったサービス間の連携について標準がなかった

可用性を担保が難しかった分散リソース実装が辛すぎた

初期 SOA の思想は素晴らしかっただが思想を実現する前に SOA の概念が拡大しすぎた

設計

設計・実装

インフラ

実装

初期 SOA の思想の実現ですら難しかった

Microservices と DDD

Microservices と DDD

www.nextscape.net 10

よく見かけるのが

というやり取り。

サービスをどうやって分割すればいい？DDD の「境界付けられたコンテキスト」が参考になります

折角 DDD に触れるのにそこだけ？勿体無い！

Domain-Driven Design

DDD の考える課題


戦略要件基本設計詳細設計実装

変換変換変換変換

この戦略はどの実装？この実装はどの戦略？

この変換が全ての元凶！

DDD の考える課題


顧客にとっては理不尽だらけの IT 業界機能追加して機能の改善してバグだ！すぐ修正して

工数とスケジュールの提示するけど・・・

でも工数の根拠は提示されない。提示できない。

DDD の考える課題小さな機能追加依頼• 以前と同じぐらいのボリュームだろう、と顧客は思っている

見積もり提示• 以前に比べて高額• でも根拠は提示されない（できない）

不信感• 高い！遅い！前と違う！• もっと早く、もっと安くできるでしょ？

スケジュール優先の対応•顧客の要望は品質よりスケジュール、予算よりスケジュール、と理解•ソースが肥大化（品質悪化）


不信感の負の連鎖

DDD の目指す世界業務をモデルで表す

モデルをそのまま実装するモデルから業務を改善する


業務と実装のギャップを埋める

余談：業務＝ドメインってこと？詳しくは後ほど

DDD のよくある誤解

そういう箇所も一部もありますが、それは DDD のメインではありません。ビジネスモデリングなどの要求開発工程から業務フローなどの要件定義工程などを含んでいます。


DDD とはデザインパターンのような設計技法である

モデリングから実装へのプロセス

ドメインをコンテキストで分割コンテキストごとにドメインをモデルとして表現する

モデルをそのまま実装する


最初はものすごくざっくりとした理解から

そもそもドメインとは何かもっとざっくりと具体的には、ドメインとは


システムを使う人にとっての関心事のことです。

DDD ではドメインエキスパート、という言葉出てきます。これは業務（ビジネス）に精通している人のことを指します。

業務業務の成果という感じで最初はいいんじゃないでしょうか

達成したいことエンドユーザー運用者

※異論は認めます！他にもステークホルダーはいっぱいいますよね

が

ではコンテキストとは何か誤解を恐れずに言えば、「環境」

特定のモデル達だけが意味を持つ「環境」モデルが特定の意味を持つための「前提条件」


そのモデルは、そのコンテキストだけでしか成立しない

もうちょっと言えばもっと正確に言うと

ではコンテキストとは何か

www.nextscape.net20

メンバー同士の会話特定の作業あるコードの範囲

そのモデルは、そのコンテキストだけでしか成立しないコンテキストの例

例：料金というモデル。ある時は送料を、ある時は発注代金を表す例：コンテンツを個人単位にブックマークする機能のことを、ある時はお気に入り機能、ある時はクリップボード機能

よくある混乱違うものを同じ言葉で表す同じものを違う言葉で表す

境界付けられたコンテキストとは

業務別• 在庫管理業務• 商品発送業務

顧客の組織別• パッケージング・発送• 経理• 経営• 広告

他システム• DDD 本の例だとレガシーシステムが良く出てくる


つまり粗い前提条件別にアプリを分割することよくある分割指針

コンテキスト（前提条件）が違うことが明確になった結果のこと

分割したコンテキストを明示化


順応者

図の参考：コンテキストマッピングによる戦略的ドメイン駆動設計https://www.infoq.com/jp/articles/ddd-contextmapping_jp

コンテキストマップ目的１．コンテキスト間の関係を明示化

コンテキスト間の情報の伝達には注意が必要他コンテキストのモデルで自分のモデルを侵食されないようにする腐敗防止層 (Anti Corruption Layer) の検討を

情報変更のトリガーとしてドメインイベントの検討を

Webユーザープロファイル

個人財務管理銀行システム

支払い追跡

オンライン銀行サービス(レガシーシステム )

腐敗防止層

パートナー

U

D D

U

分割したコンテキストを明示化


目的２．コンテキスト間のモデルのマッピング

図の参考： Modularity and Domain Driven Design; a killer combination?http://www.slideshare.net/aca_it/modularity-ddd

コンテキストマップ

車

オプションオーナー

保証

モデル

製造

車コンテキスト

輸送

場所輸送対象

輸送先顧客輸送依頼元

輸送コンテキスト

ビジネスパートナー担当窓口住所ビジネスパートナーコンテキスト

from

to

不信感の負の連鎖を断ち切るwww.nextscape.net 24

モデルを顧客と作るモデルを顧客と作る＝要件定義＋設計です


• モデルで使用されている名詞や動詞に、顧客が知らない言葉があってはならない。• モデルがそのままコードになる＝言葉がコードで使用される

顧客と同じ言葉でモデリングする。

業務の中身をモデリング• 顧客と一緒にモデリングすることが重要

開発者もモデリングに参加する意義• 業務を正確に把握できる

顧客もモデリングに参加する意義•複雑な業務がそのままコードになることからコスト感覚を持てる

重要なプラクティス、ユビキタス言語

おまけの話DDD のソフトウェアアーキテクチャ達成すべきこと

• ドメインレイヤー内でドメインモデル以外の余計なものを絶対に入れない• DDD 本ではレイヤーアーキテクチャが掲載されているが、特にこの構成を採用せよと規定されていない


図の参考： DDD and Hexagonal architecturehttp://tindaloscode.blogspot.jp/2013/11/ddd-and-hexagonal-architecture.html

「実践ドメイン駆動設計」ではPortAndAdapter （別名ヘキサゴナルアーキテクチャ）をお勧めしている

余計なものって？例えばデータ永続化ロジックトランザクション権限チェックロジック

ドメインLayer

Appl

icat

ion

Laye

r

Port

内部 Client Port

外部 Client Port

内部永続化 Port

外部サービス Port

HTMLWeb Gadget

RIAViewer

Web API

ESBinbound

RDBMS

In-memoryObject store

他システムESB

outbound

プレゼンLayer

インフラLayer

DDD 導入のハードル

DDD がなかなか採用されない理由DDD 本が難解すぎる

• とにかく分厚い• 前提とするスキルレベルがかなり高い（ PoEAA知ってるとか）• 章立てとプロセスが紐づいていないので混乱しやすい

設計・実装のイメージが沸かない• 結局どうすればいいのかわからない• どこから手を付ければいいのかわからない

モデリングできる人がいない• 大抵の場合、 ER図になる• もしくは、ただ構造を表しただけの静的なモデルとなる


小さななシステムには向かない手法小さく実験しても効果がわからない

むしろ煩雑なだけにしか感じない何がいいのかわからない

最大のハードル：試しにくい

ハードルを越えよう「実践ドメイン駆動設計」は読みやすいです• 本で登場するサンプルの著者による実装が Github にあります• https://github.com/VaughnVernon/IDDD_Samples

まずは社内システムから• そこそこ複雑なものを選ぶ• システム開発にあまり詳しくなく、モデリングに付き合ってくれる業務担当者に協力を依頼


https://github.com/VaughnVernon/IDDD_Samples

ハードルを越えよう


要件定義中からモデルを書きましょう• モデリングをする、ということは業務フロー＝モデル、となるはずです• 逆にいうと、基本設計以降のフェーズだけで DDD採用は見送った方が良いです（負担ばかりが多くて価値が出にくい）

コンテキストマップを書きましょう• これを軽視すると１つのコンテキストでモデリングしがちです。巨大なモデル群を作り上げてしまいます

最初からテーブル設計を絶対にしないこと• DDD を採用すると開発プロセスが変わります。• モデリングという作業が強要され、要件定義＝モデリングしつつ実装も進めます。• ER図の作成開始はモデリングが完了してからです。が、モデリングは要件定義なのでなかなか固まりません。• だから ER図の作成は後回しにするしかないはずなのです。• RDBMS で保存するなら最終的にテーブル設計は必要ですが、最初からやろうとしてはいけません。無駄になるだけならいいですが、最悪モデリングしないで工程が進んでいきます。（もはや DDD ではない）

私が感じた、実践したほうが良いプラクティス

大事！

Azure Service Fabric難解極まる MSDN を読み解こう！

Azure Service Fabric とは


スタンドアロンアプリのクラスタ化 PaaS です。• クラスタリングとは？多数の低廉なコンピュータを、特別なソフトウェア・ハードウェアを用いて、あたかも 1 つの大きなコンピュータとして利用できるように接続すること。（ Wikipedia ）

1. 負荷分散・・・複数のマシンで処理を分散• クラスタの特徴とは？

2. 高可用性・・・ 1台のマシンが停止しても、待機系マシンがすぐ立ち上がる

イメージ


Exe

Exe

Exe

Exe

Exe

Exe

Exe Exe処理リクエスト

• ５つの Exe で負荷分散• ３つの Exe が待機中

イメージ


Exe

Exe

Exe

Exe

Exe

Exe



Exe１つが停止してしまった

イメージ


Exe

Exe

Exe

Exe

Exe

Exe



Exe１つが停止してしまった

待機系が昇格

イメージ


Exe

Exe

Exe

Exe

Exe

Exe



再起動して待機系に

待機系が昇格

Azure Service Fabric とは


スタンドアロンアプリは 2種類に大別されます。1. Exe, Java アプリなどのスタンドアロンアプリをホスティング 2. ServiceFabric の SDK を使ったアプリをホスティング（実はこれもスタンドアロン

ゲスト実行可能ファイルステートレスサービスステートフルサービスという名称です。でも ServiceFabric は　　　　　　　　　として起動します。 2種類のタイプのサービスを作ることができます。ステートレスサービス

Azure Service Fabric とはMSDN を見るともう 1 つ Reliable Actor というものがあります。これは Exe単位ではなくオブジェクト単位のクラスタです。


実態はステートフルサービスです。つまり、 Service Fabric を理解する近道は

ステートレスサービスステートフルサービスを理解することです。

※もっと言うと、ステートレスサービスから理解するとわかりやすいです。ちなみに Service Fabric はオンプレでも Linux でも動きます！別に Azure 上だけで動くサービスじゃありません！

Azure Service Fabric でマイクロサービスとは


大きなシステム

小さなサービス小さなサービス

小さなサービス

分割

小さなサービス

独立した小さなサービスが協調して大きなシステムを構成

モノリスマイクロサービス

Azure Service Fabric でマイクロサービスとは


ステートレス、ステートレス、時にはAcitor も組み合わせて大きなシステムを構成します。

大きなシステム分割

モノリス Service Fabric

ステートフルサービスステートフルサービス

Microsoft Azure

ステートレスサービスステートレスサービス

これ１つずつについて・負荷分散・高可用性を担保することができる

Service Fabric SDk


Service Fabric SDK を使った実装


ServiceFabric の SDK を使って実装すると• 外部との通信が実現• 中止、開始、停止時のイベントをハンドルできる

プログラミングモデルの種類

Reliable Service Reliable Actor

ステートレス Service ステートフル Service

Exe等の実行ファイル単位のホスティング

Service Fabricの基本

オブジェクト単位のホスティングデータを保持しない StatelessService クラスを継承したクラスに実装していく

データを保持する StatefullService クラスを継承したクラスに実装していく

StatelessServiceから覚えましょう。


Stateless Service の仮想メソッド達


StatelessService

※StatefullService も同名の仮想メソッドを持っていて使い方も同じですが、クラス階層を辿っても、 StatelessService と StatefullService は関連がありません

自作クラスTask RunAsync(　 CancellationToken cancellationToken)

Task OnOpenAsync(　 CancellationToken cancellationToken)

Task OnCloseAsync(　 CancellationToken cancellationToken)

void OnAbort()

IEnumerable<ServiceInstanceListener>

CreateServiceInstanceListeners()

サービス起動イベントハンドラバッチ処理用サービス起動準備の最後にレイズするイベントのハンドラ。初期化処理用サービス停止イベントハンドラ

外部からの着信を待ち受けるリスナーを返却する

サービス中止イベントハンドラ

※全部仮想メソッドなので必要なメソッドだけ Override する上の４つのメソッドはイベントハンドラ

Service Fabric の外部と通信する


StatelessService

RunASync, OnOpenASync, OnCloseASync, OnAbort

MyService

ICommunicationListener

MyListener

protected override IEnumerable<ServiceInstanceListener>

CreateServiceInstanceListeners(){ return new ServiceInstanceListener[] { new ServiceInstanceListener(serviceContext => new MyListener ()) };}

Task<string> OpenAsync(　 CancellationToken cancellationToken)

Task CloseAsync(　 CancellationToken cancellationToken)

void Abort()

見ての通り、リスナーは複数返せるのでエンドポイントを複数用意できます。1 つは http で、もう 1 つも httpで Port 違い、 3 つ目は tcp でクラスタ内通信とかできます

あれ？こっちもOpen,Close,Abor

t じゃないか OpenASync メソッドの戻り値で返す文字列が重要。外部からの着信をリッスンする場所を返却する例： http://ホスト名 :port/ ほげほげ

Web で通信 IIS が動かないので、 OWIN で自己ホストします Visual Studio に用意されるテンプレートの Service Fabric WebAPI は MSDNで解説している内容の完全実装です


StatelessService

自作クラス

Startup

void ConfigureApp(IAppBuilder appBuilder)

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners(){ return new ServiceInstanceListener[] { new ServiceInstanceListener( serviceContext => new OwinCommunicationListener( Startup.ConfigureApp, serviceContext, ServiceEventSource.Current, "ServiceEndpoint")) };}

ICommunicationListener

OwinCommunicationListener

Task<string> OpenAsync(CancellationToken cancellationToken)

OpenASync でリッスンする URI を組み立てて、サーバースタートしているだけ

https://azure.microsoft.com/ja-jp/documentation/articles/service-fabric-reliable-services-communication-webapi/

MSDN 解説の URL



WCF で通信


なんと。 ICommunicationListener を実装済みのクラスが提供されています。Nuget で入れます

完全なサンプルが見当たらないので、実装のポイントをいくつかhttps://azure.microsoft.com/ja-jp/documentation/articles/service-fabric-reliable-services-communication-wcf/

MSDN 解説の URL

プロジェクト構成

※サンプルではクライアントも同じクラスタ内で稼働させる必要があるため、クライアントを StatelessService でプロジェクト追加します

プロジェクト参照します

https://azure.microsoft.com/ja-jp/documentation/articles/service-fabric-reliable-services-communication-wcf/

WCF で通信


WCFホスト側の実装Calculator の実装がサンプルに見当たりません。適当に作ってくださいclass Calculator : ICalculator{ public Task<int> Add(int value1, int value2) { return Task.FromResult(value1 + value2); }}

<Resources> <Endpoints> <Endpoint Name="WcfServiceEndpoint" Protocol="tcp" Port="8515"/> </Endpoints> </Resources>

リッスンする場所とプロトコルを定義して名前つけます

internal sealed class WcfHostStateless : StatelessService{ private ICalculator _calculator; public WcfHostStateless(StatelessServiceContext context) : base(context) { this._calculator = new Calculator(); }

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners(){ return new ServiceInstanceListener[] { new ServiceInstanceListener(serviceContext => new WcfCommunicationListener<ICalculator>( wcfServiceObject:this._calculator, serviceContext:base.Context, endpointResourceName: "WcfServiceEndpoint", listenerBinding: WcfUtility.CreateTcpListenerBinding() )) };}

WCF で通信


サンプルで ServiceUri というオブジェクトが説明なく出てきます。これは WCF を実装したホストの場所を保持した Uriオブジェクトです。例：” fabric:/ アプリ名 / サービス名 /”

WCF クライアント側の実装クライアント側にもライブラリをいれてください

private void CallWcf(StatelessServiceContext context, string endpointName){ var binding = WcfUtility.CreateTcpClientBinding();

IServicePartitionResolver partitionResolver = ServicePartitionResolver.GetDefault();

var wcfClientFactory = new WcfCommunicationClientFactory<ICalculator> (clientBinding: binding, servicePartitionResolver: partitionResolver);

var calculatorServiceCommunicationClient = new WcfCommunicationClient( wcfClientFactory, new Uri("fabric:/ServiceFabricWcf/WcfHostStateless"), ServicePartitionKey.Singleton);

var result = calculatorServiceCommunicationClient.InvokeWithRetryAsync( client => client.Channel.Add(2, 3)).Result;}サンプルそのままです

this.CallWcf(this.Context, "WcfServiceEndpoint");

RunAsync の中で CallWcf メソッドを呼びますWcfホストと同じ

Endpoint 設定を記載します

最後に

　　　　　で一緒に働きませんか！一次請け案件 100％SES やっていません。すべて自社開発（西新宿）


DDD プロジェクト２つ進行中 Scrum プロジェクト 3 つ進行中

裁量労働制コーヒー、ミネラルウォーター、お茶飲み放題デュアルディスプレイ支給技術書籍は全額会社負担各種社外研修も全額会社負担海外カンファレンスも積極的に行けます

募集中！• PM• PL• SE• スマホエンジニア

イラストはこちらを利用させていただきましたいらすとや： http://www.irasutoya.com/


ブースにも来てね！ NS Studyで待ってます！

NS study8 DDD Microservices Azuer Service Fabric

Software