世界のやまさ

SEKAI NO YAMASA

Build 2015 落ち穂拾い - Azure Service Fabric -

まとめ

Azure Service Fabric のセッションを聞きました。アーキテクチャーは相当素晴らしいと思いますが、いかんせん WCF っぽかったり、この実装がスタンダードになるにはちょっと難しいかなという感じはしました。

スライドを見たコメントをつけていますが、私の英語力の限界もあり、そうとう間違った解釈もしていると思いますのでご容赦ください。

このボリュームは落ち穂拾いどころじゃないので、別にまとめるべきだったなぁ。。。

セッション感想

channel9.msdn.com

f:id:nnasaki:20150503144813p:plain

f:id:nnasaki:20150503145044p:plain

f:id:nnasaki:20150503145106p:plain

マイクロサービスのステートレスとステートフル

f:id:nnasaki:20150503145518p:plain

ステートレスのデモ

f:id:nnasaki:20150503145737p:plain

うーん。ここまで見てきたけど、イマイチピンと来ないのと英語がよく聞き取れないのでここまで。

channel9.msdn.com

f:id:nnasaki:20150503152027p:plain

前半は同じような話なので飛ばす。

f:id:nnasaki:20150503152211p:plain

デモの英語がインド系だけどコードがまだ何とかわかるので、こっちを見てみる

Actor を使ったデモ。 インクリメンタルするカウンターがプリミティブなフィールド。

f:id:nnasaki:20150503152339p:plain

こんな感じで無限ループでカウントアップさせていくよう

f:id:nnasaki:20150503152511p:plain

実行するとカウントアップする

f:id:nnasaki:20150503152736p:plain

ノードをリスタートすると。。。

f:id:nnasaki:20150503152852p:plain

カウンターがリセットされる

f:id:nnasaki:20150503152930p:plain

ではどうすればステートが保持されるか? シリアライザブルなクラスを追加し、Actorのジェネリクスに追加する

f:id:nnasaki:20150503153226p:plain

this.value ではなく、 this.State.value の値を使う。Actor が持っているっぽい。

f:id:nnasaki:20150503153416p:plain

デプロイしてブレイクポイントにも止まります。

f:id:nnasaki:20150503153632p:plain

先ほどのノードが1つだったのが3つに増えている。プライマリーとセカンダリーが2つ。特に設定はしておらず、自動的になった。

f:id:nnasaki:20150503153748p:plain

先ほどと同じように Node4 にリスタートをかけるとプライマリーノードがダウン。即セカンダリーにフェールオーバー。また、Node4 がセカンダリノードとして復活。

f:id:nnasaki:20150503153936p:plain f:id:nnasaki:20150503154057p:plain f:id:nnasaki:20150503154347p:plain

カウンターが途切れること無く続行(拍手) 。フェールオーバーまで3秒もかかっておらず、素晴らしい。

f:id:nnasaki:20150503154516p:plain

oh... Deep Dive ...

f:id:nnasaki:20150503154725p:plain

channel9.msdn.com

DeepDive をチラ見した感じだと、 Actor の歴史とかどうして使うかが説明されてて、もやもやがちょっと紐解けそうな感じがしました。

f:id:nnasaki:20150503201941p:plain f:id:nnasaki:20150503202010p:plain

ここでやめようかと思ったけど、もうちょっとだけがんばって、次はアプリケーションのデプロイの話。

Code と Config をサービスごとにパッケージングする

f:id:nnasaki:20150503192943p:plain f:id:nnasaki:20150503193038p:plain

各サービスをアプリケーションパッケージにまとめる。アプリケーションタイプにはサービスタイプとWebアプリケーションタイプに分かれる

f:id:nnasaki:20150503193207p:plain

サービスタイプ、アプリケーションタイプと分かれる。それぞれユニークな名前を持つようだけど、ちょっと理解出来ず。

f:id:nnasaki:20150503193453p:plain

サービス API は ステートレスかステートフルで選べる。

f:id:nnasaki:20150503193720p:plain

Reliable Collections 最強の図。複数のマシンでレプリケート可能で永続化可能で非同期でトランザクション制御もできる。

f:id:nnasaki:20150503193909p:plain

IReliableDictionary<K, V> のハッシュと、 IReliableQueue のキューの2種類がある。

f:id:nnasaki:20150503194015p:plain

コード例。 [ServiceContract]って めっちゃWCF臭がする。。。

f:id:nnasaki:20150503194256p:plain

てか、Namespace にめっちゃ WCF ってかいてるじゃん。。。

f:id:nnasaki:20150503194345p:plain

Actor と同じように、ステートレスのデモ。サービスをリスタートさせるとカウントが戻る

f:id:nnasaki:20150503194526p:plain f:id:nnasaki:20150503194547p:plain f:id:nnasaki:20150503194604p:plain

従来の Could Service と Stateful Service Fabric で作る場合の対比図。Service Fabric で作れば、 Reliable Collections で済んでしまうので、 Azure Queue も Table も不要になる。 従来のクラウドデザインパターンを覆すぐらいのインパクトありますね。

f:id:nnasaki:20150503194703p:plain

次はステートフルの例。やはり3パーティションできる。Actor と同じようにリスタートをかけても、大丈夫。Actor の時よりサービスが重いためか、なかなか Down から上がってこないが、残り二つのパーティションで頑張っている。

f:id:nnasaki:20150503195324p:plain f:id:nnasaki:20150503195441p:plain

スケールアップの話。パーティションを増やすことでスケールアップできる。 RAID5とかと同じイメージ。 Node には複数のパーティションがあり、パーティションは必ず3つのレプリカを各 Node に作成する。

f:id:nnasaki:20150503195615p:plain

ロードバランサーでリクエストを受けて、各パーティションにリクエストを振り分ける。ところでこのパーティションを分割するとデータは垂直分割なんだろうか水平分割なんだろうか。

f:id:nnasaki:20150503195900p:plain

パーティション増やすのも ApplicationManifest.xml に書けば良いだけかな?

f:id:nnasaki:20150503200350p:plain

さっきよりグラフィカルな監視画面。例えばノード単位で落としても、フェールオーバーしてアプリケーションは継続して動く。

f:id:nnasaki:20150503200602p:plain

Chaos Test Service。ランダムでノードとパーティションを落として、耐久テストを行う。

f:id:nnasaki:20150503200822p:plain

ランダムで落としてもゾンビのように立ち上がってくるパーティション達。カウントはその間止まること無く増え続ける(拍手)

f:id:nnasaki:20150503201111p:plain

質疑応答も大人気。その間も止まること無くテストは続く。

f:id:nnasaki:20150503201140p:plain

次のセッションの準備中まで質問は続くよ。質問ではクラウドサービスからの移行はどうかとか、デプロイはどうかとか言ってました。移行はドキュメントを用意するのと、デプロイはリソースマネージャーで出来るよと言ってた気がする。

なるほど、この規模のデプロイは単純にいかないから、リソースマネージャーが結構フューチャーされていたのかなぁと感じがしました。

f:id:nnasaki:20150503201252p:plain