Dapr × Kubernetes ではじめるポータブルなマイクロサービス / portable microservices with Dapr and Kubernetes

Slide 1

Slide 1 text

Dapr × Kubernetes ではじめるポータブルなマイクロサービス Masahiko Utsunomiya 2020/09/09 CloudNative Days Tokyo 2020

Slide 2

Slide 2 text

1 #CNDT2020 https://bit.ly/32uqZKc Whois ü ⾦融分野のお客様のクラウド導⼊⽀援 ü AWS Top Engineers 2020 & Well-Architected Lead ü Observability（Prometheus, Grafana, Loki, Jaeger, etc.）, Microservices, … polar3130 Masahiko Utsunomiya Infrastructure Engineer / Relationship Builder NTT DATA Corporation

Slide 3

Slide 3 text

2 #CNDT2020 https://bit.ly/32uqZKc 掲載内容は個⼈の⾒解であり、所属する企業や組織の⽴場、戦略、意⾒を代表するものではありません

Slide 4

Slide 4 text

3 #CNDT2020 https://bit.ly/32uqZKc Agenda • マイクロサービスとポータビリティ • Dapr ⼊⾨ • ユースケースと実装事例 • おわりに

Slide 5

Slide 5 text

マイクロサービスとポータビリティ

Slide 6

Slide 6 text

5 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスはクラウドネイティブの唯⼀解？流⾏っているから、で選ぶにはあまりに複雑なアーキテクチャ得られるメリットだけでなく、抱え込む複雑性を理解しておく必要がある他の選択肢（アーキテクチャ）と⽐較したうえで選んでいることも重要モノリスは密結合で低品質なアーキテクチャだ、マイクロサービスこそ唯⼀の解決策！

Slide 7

Slide 7 text

6 #CNDT2020 https://bit.ly/32uqZKc もう⼀度、モノリシックアーキテクチャから “モノリシック” とは、デプロイの単位が分割されていないという意味マイクロサービスとのデプロイ粒度の対⽐から⽣まれた⾔葉であり、両者の間にアーキテクチャの優劣があるわけではない https://www.youtube.com/watch?v=5OjqD-ow8GE “モノリス” のよくある誤解 ☓ 密結合「コンポーネント間が相互依存し、密結合になっている」という意味は含まれない ☓ 品質が低いシステム個々の問題であり、モノリシックアーキテクチャ⾃体は原因ではない

Slide 8

Slide 8 text

7 #CNDT2020 https://bit.ly/32uqZKc Modular Monolith ビジネスコンテキストに基づいて分割・構造化されたモジュールで構成 Shopify, Segment, Root Insurance などで採⽤されている https://medium.com/design-and-tech-co/modular-monoliths-a-gateway-to-microservices-946f2cbdf382 • 疎結合なモジュール • 明確に定義されたインターフェイス • カプセル化されたデータアクセス • インターフェイスの⼀貫性の維持これらはマイクロサービスでなくとも実現できるマイクロサービスのデザインパターンである Database per Service に近いが、サービス化はしない

Slide 9

Slide 9 text

8 #CNDT2020 https://bit.ly/32uqZKc Microservices 機能ごとに分割されたサービスの集合体でアプリケーションを構成する各サービスは限定された責任を持ち、⾃律的に管理される https://microservices.io/ üサービス別に独⽴したリリースサイクル他のサービスに依存することなく、サービスのアップデートが⾏える üサービス別に独⽴したスケーリング各サービスが個々の必要に応じてスケールでき、リソースを最適化できる üサービス別に独⽴した技術スタックサービスごとに最適なインフラストラクチャ、フレームワーク、開発⾔語を選択できる

Slide 10

Slide 10 text

9 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスを⽬指す判断指標分散システムの複雑性に対するコストを払ってでも、アプリケーション（ビジネス）のアジリティ向上が⾒込めるかどうかマイクロサービスの導⼊そのものを⽬的にしてはいけない、アジリティの向上につながらなければ持続的な開発はできない ...が、マイクロサービスに適しているか最初から⾒通せるとも限らないではどうやってマイクロサービスを導⼊してゆけば良いのか？ üサービス別に独⽴したリリースサイクル üサービス別に独⽴したスケーリング üサービス別に独⽴した技術スタック ☓ トランザクションやクエリの管理複雑化 ☓ 通信のレイテンシ増加 ☓ E2Eテストの複雑化

Slide 11

Slide 11 text

10 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスへの道のりモノリスから出発し、段階的なマイクロサービス化を推奨モジュールの分離と、サービスの分離を別々のタイミングで⾏うことで個々の変更の複雑さを抑制 Modular Monolith 分散システムの複雑性を持ち込む前に、モジュールの構造化を⾏う (Strangler pattern) Microservices 途中でモノリスに引き返す or 留まる判断も必要単⼀の⼩さいチームとモノリスから始めて、素早く市場に投⼊ Monolith Strangler facade ü 個別のリリースサイクル ü 個別のスケーリング ü 個別の技術スタック

Slide 12

Slide 12 text

11 #CNDT2020 https://bit.ly/32uqZKc 実⾏環境の変化とポータビリティ段階的なマイクロサービス化の過程で、フレームワークや環境の差分がアプリケーションに与える変更影響を極⼒減らしたい • 例えば、ローカルの開発環境とクラウドの本番環境でインフラストラクチャが異なっていても、アプリケーションコードを変更することなくどちらの環境でも稼働してほしい Cloud platform Localhost Secret State Store Message Broker Secret State Store Message Broker Application Application

Slide 13

Slide 13 text

12 #CNDT2020 https://bit.ly/32uqZKc 実⾏環境の変化とポータビリティ段階的なマイクロサービス化の過程で、フレームワークや環境の差分がアプリケーションに与える変更影響を極⼒減らしたい • 例えば、段階的に新しくサービスを追加してゆく過程で、これから構築するサービスの技術選定が既存の技術スタックに依存しないようにしたい Framework A Framework B

Slide 14

Slide 14 text

13 #CNDT2020 https://bit.ly/32uqZKc アプリケーションのポータビリティ異なる環境間で同じようにアプリケーションを実⾏できる性質（ポータビリティ）が段階的なマイクロサービス化に役⽴つ • ポータビリティはアプリケーションのコンテナ化だけでは完結しない（インフラストラクチャ, etc.） • コンテナの実⾏環境としては、Kubernetes が代表的な抽象化の⼿段 • アプリケーションが実⾏環境や開発⾔語に依存しなければ、より柔軟な開発・構成が可能に

Slide 15

Slide 15 text

14 #CNDT2020 https://bit.ly/32uqZKc ここまでのまとめシステムによって、適切なアーキテクチャは異なる • アーキテクチャの特性を理解し、アプリケーションに合ったアーキテクチャを選定することが⼤事 • モノリスとマイクロサービスのどちらが優れている、ということではない • アジリティ向上のために、サービス別に独⽴したリリースサイクル、スケーリング、技術スタックが必要ならば、マイクロサービスは有効な選択肢のひとつマイクロサービスへの道のり • 分散システムの複雑性とのトレードオフ、ビジネスのアジリティ向上が⾒込めるかが判断ポイント • モノリスから出発して早期に市場へ投⼊、段階的なマイクロサービス化を推奨 • その過程でプラットフォームや⾔語・フレームワークの差異を受け⽌めて抽象化してくれるレイヤがあれば、ビジネスロジックにより注⼒できる

Slide 16

Slide 16 text

15 #CNDT2020 https://bit.ly/32uqZKc 補⾜：マイクロサービス化にもうひとつ（あるいは最も）重要なものマイクロサービスに合った組織編成 • コンパクトで、開発と運⽤の双⽅に責任を持ち、適切に権限が移譲された、ビジネスコンテキストに基づく組織編成 • 技術的な問題よりも乗り越えるのが難しい、マイクロサービス導⼊の壁逆コンウェイ戦略 • マイクロサービス化を促進しやすくするように、組織構造や組織⽂化を変えていく • 旧来の縦割りの組織構造や⽂化のまま、マイクロサービスを実現するのは困難

Slide 17

Slide 17 text

Dapr ⼊⾨ポータブルなマイクロサービスのためのビルディングブロック

Slide 18

Slide 18 text

17 #CNDT2020 https://bit.ly/32uqZKc Dapr とはステートフルサービスに対応した、イベント駆動かつポータブルなオープンソースの分散アプリケーション向けランタイム https://github.com/dapr • Any language or framework 異種⾔語・異種実⾏環境が混在しても、⼀貫した⽅法で相互のサービス呼び出しができる • Any cloud or edge アプリケーションがロケーション（クラウドor エッジ）を問わず実⾏できる Github Star: 7100+ Latest: v0.10.0 https://dapr.io/

Slide 19

Slide 19 text

18 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスのビルディングブロック標準化された API, Pub/Sub, トレーシングなど、分散システムの実装を容易にするための機能を 7 つのカテゴリで提供フレームワークではなくビルディングブロックとして設計されており、⼀部からでも使い始められる https://github.com/dapr/docs/tree/master/overview

Slide 20

Slide 20 text

19 #CNDT2020 https://bit.ly/32uqZKc サイドカーアーキテクチャアプリケーションと独⽴したコンテナ/プロセスで稼働し、API を公開 • アプリケーションコードに Dapr のランタイムに関するコードが混⼊しない • Dapr の各機能は HTTP / gRPC で呼び出す • ローカル端末（Linux, Mac, Windows）、Kubernetes、エッジデバイスなど、任意の環境で実⾏できる https://github.com/dapr/docs/tree/master/overview

Slide 21

Slide 21 text

20 #CNDT2020 https://bit.ly/32uqZKc Dapr のアーキテクチャ（self-hosted mode）各コンポーネントはアプリケーションと独⽴したプロセスで起動 • Dapr がアプリケーションを登録するためのデータストアとして redis を利⽤（Statestore とは別） • Dapr が識別するアプリケーション間の分散トレースは zipkin で収集 * 後述するアクターモデルの利⽤時にのみ必要 https://github.com/dapr/docs/tree/master/overview daprd dapr init Dapr Placement* dapr run ...

Slide 22

Slide 22 text

21 #CNDT2020 https://bit.ly/32uqZKc Dapr のアーキテクチャ（Kubernetes mode） Dapr Actor Placement アクターパターンを実装する際に利⽤するアクターセット全体の状態管理、配置、操作 Dapr Sidecar Injector Deployment に付与された Annotations に基づき Admission Webhook により Dapr Sidecar を注⼊ Dapr Sentry 各 Pod の Dapr Sidecar 間で mTLS 通信を⾏う際の認証局として証明書を発⾏/管理 Dapr Operator kind: Component として外部リソースを抽象化ランタイムへ Component の変更を通知 https://github.com/dapr/docs/tree/master/overview 4 つの統合サービスが展開される

Slide 23

Slide 23 text

22 #CNDT2020 https://bit.ly/32uqZKc サービスメッシュとの違い⼀部重複する機能もあるが、フォーカスしている領域が異なる • サービスメッシュはネットワークの管理、Dapr は分散アプリケーション開発をより簡単にすること • Dapr は Istio, Linkerd などのサービスメッシュとの併⽤も可能 https://www.youtube.com/watch?v=xxU68ewRmz8 • アクターモデルの導⼊ • ワークロードの状態管理 • 外部リソースの抽象化 etc. • Network Policy • 負荷分散 • Fault Injection etc. • 分散トレーシング • mTLS • メトリクスサービスメッシュ Dapr

Slide 24

Slide 24 text

23 #CNDT2020 https://bit.ly/32uqZKc 他のマイクロサービスフレームワークとの違い Dapr は分散アプリケーションを任意の開発⾔語で実装できる例えば Java であれば Axon, Eventuate, MicroProfile LRA などのフレームワークが既にあるが、これらは連携する各サービスが同じフレームワークを使って実装されることを前提としている Dapr はサイドカーアーキテクチャによって⼀貫性のあるサービス呼び出しの API を提供することで、⾔語やフレームワークを問わない Polyglot なアプリケーション開発を可能にする Go Java & framework B Java & framework A C#

Slide 25

Slide 25 text

24 #CNDT2020 https://bit.ly/32uqZKc Dapr のコンポーネント分散アプリケーションの実装をサポートする各種機能を、モジュール型のコンポーネント群で提供特定のインフラストラクチャに依存せず、クラウドでもローカル端末でも同じような開発体験が得られることを⽬指している • Service discovery • State • Pub/Sub • Bindings • Middleware • Secret stores • Tracing exporters https://github.com/dapr/docs/tree/master/concepts

Slide 26

Slide 26 text

25 #CNDT2020 https://bit.ly/32uqZKc Service discovery コンポーネント Dapr がサービス呼び出しの API を標準化し、サービス検出を代⾏アプリケーションから分離して Dapr が代⾏することで、インフラに応じた名前解決の実装を抽象化 • Self-host mode: mDNS を利⽤して名前解決するため、ローカル DNS サーバは不要 • Kubernetes mode: Kubernetes の DNS-Based Service Discovery を利⽤して名前解決を⾏う https://github.com/dapr/docs/tree/master/concepts/service-invocation < component > nameresolution app "Order" app "Payment" Dapr に向けて Payment サービスを呼び出す http://localhost:3500/v1.0/invoke/payment/method/execute Payment サービスを検出＆呼び出し Dapr がリクエストをアプリケーションに転送 Dapr Sidecar Dapr Sidecar 1 2 3

Slide 27

Slide 27 text

26 #CNDT2020 https://bit.ly/32uqZKc ・・・ State コンポーネント状態管理⽤の KVS を提供、実装には様々なクラウドサービスをサポート同じアプリケーションの異なるインスタンス同⼠で状態を共有できる強整合性と結果整合性の両⽅をサポート、再試⾏ポリシーの設定、バルク操作なども可能 https://github.com/dapr/docs/tree/master/concepts/state-management app "myApp" Dapr Sidecar Post http://localhost:3500/v1.0/state/statestore "CNDT2020" [{ "key": "event", "value": "CNDT2020" }] Get http://localhost:3500/v1.0/state/statestore/event Key Value myApp-event "CNDT2020" statestore apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: statestate spec: type: state. ... metadata: ... statestore.yaml

Slide 28

Slide 28 text

27 #CNDT2020 https://bit.ly/32uqZKc Pub/Sub コンポーネントイベント駆動のための、At Least Once なメッセージ配信スケーラビリティとサービス間の疎結合性のために重要なコンポーネント同じアプリケーションのインスタンスが複数存在する場合は必ず 1 つのインスタンスにのみ配信トピックに送信されるメッセージのペイロードは Cloud Events 1.0 の仕様に準拠 https://github.com/dapr/docs/tree/master/concepts/publish-subscribe-messaging app "HogePublisher" Dapr Sidecar publish subscribe + ・・・ < component > pubsub Post http://localhost:3500/v1.0/publish/mypubsub/mytopic "mypubsub" app "HugaSubscriber" Dapr Sidecar app "PiyoSubscriber" Dapr Sidecar

Slide 29

Slide 29 text

28 #CNDT2020 https://bit.ly/32uqZKc Bindings コンポーネント外部リソースを抽象化し、イベントの受信や呼び出しを Dapr が仲介特定の SDK やライブラリのコードをアプリケーションを含めずともイベントを送受信できる環境に応じて外部リソースの実装が変更される場合でも、アプリケーションには変更影響が及ばない https://github.com/dapr/docs/tree/master/concepts/bindings app "Provider" Dapr Sidecar output binding Post http://localhost:3500/v1.0/binding/myresource app "Consumer" Dapr Sidecar input binding Post /myresource HTTP エンドポイントをリッスン・・・ < component > binding "myresource"

Slide 30

Slide 30 text

29 #CNDT2020 https://bit.ly/32uqZKc Middleware コンポーネントリクエストおよびレスポンス時の共通処理とその順序を制御レート制限、OAuth 2 認可のアクセストークン取得など複数の Middleware を定義した場合は、リクエストとレスポンスの適⽤順序が逆順になる https://github.com/dapr/docs/tree/master/concepts/middleware apiVersion: dapr.io/v1alpha1 kind: Configuration metadata: name: pipeline spec: httpPipeline: handlers: - name: oauth2 type: middleware.http.oauth2 middleware.yaml

Slide 31

Slide 31 text

30 #CNDT2020 https://bit.ly/32uqZKc Secret stores コンポーネント https://github.com/dapr/docs/tree/master/concepts/secrets アプリケーションが利⽤するシークレット情報の管理先を抽象化クラウドサービスや Kubernetes の Secret リソースなど、実⾏環境に応じて実装を使い分けられるシークレットの格納先が変更されても、アプリケーションには変更影響が及ばない・・・ "mysecret" app "myApp" Dapr Sidecar < component > secretstores Get http://localhost:3500/v1.0/secrets/vault/mysecret

Slide 32

Slide 32 text

31 #CNDT2020 https://bit.ly/32uqZKc Secret stores コンポーネント https://github.com/dapr/docs/tree/master/concepts/secrets app "myApp" Dapr Sidecar < component > secretstores Azure の場合は、Managed ID との併⽤で接続元の Pod を制限できる Get http://localhost:3500/v1.0/secrets/vault/mysecret Managed Identity "mysecret"

Slide 33

Slide 33 text

32 #CNDT2020 https://bit.ly/32uqZKc Tracing exporters コンポーネントマイクロサービス全体で⼀貫したトレースを構成可能 W3Cトレースコンテキスト標準に準拠し、コンテキスト情報は Dapr が⾃動⽣成異なるチームで作成され、異なる⾔語で作成されるサービス間でも⼀貫性が保たれる https://github.com/dapr/docs/blob/master/concepts/observability/traces.md application Dapr Sidecar OpenCensus ・・・ forwarding Kafka

Slide 34

Slide 34 text

33 #CNDT2020 https://bit.ly/32uqZKc Dapr の Observability Dapr Sidecar からサービスのメトリクス、ログ、トレースを収集コントロールプレーンのサービス（Dapr Placement, etc.）は現状メトリクスとログのみを提供以下は代表的な構成例 Observability : 制御⼯学由来の⾔葉で、モニタリングの⽂脈では動的に変化し続ける環境の信頼性を継続的に確保するための考え⽅を指す application Dapr Sidecar Metrics Tracing Logging Dashboard はテンプレートが提供されている

Slide 35

Slide 35 text

34 #CNDT2020 https://bit.ly/32uqZKc Dapr Dashboard Dapr が認識しているアプリケーションや、コンポーネントを確認可能接続先の app-id （Dapr のアプリケーション識別⼦）を確認することができるログも参照できるが、現状は⾮常に簡易的な機能 https://github.com/dapr/dashboard

Slide 36

Slide 36 text

35 #CNDT2020 https://bit.ly/32uqZKc SDK と、統合されたフレームワーク複数の⾔語で Dapr SDK が開発されている現在の SDK 提供⾔語は C++, Go, Java, JavaScript, .NET, Python, Rust (WIP) HTTP / gRPC の API を呼び出す代わりに、型指定の API を介して Dapr の各機能を利⽤できるアクターモデル（Virtual Actor）に基づく並⾏処理アプリケーションの開発を可能にする SDK の実装状況は⾔語によってばらつきがあり、Java, .NET, Python は⽐較的充実 • 例えば、 Java SDK の場合は Spring Boot とのインテグレーションが含まれており、Dapr API をハンドリングする SpringBoot Controller などが⽤意されている

Slide 37

Slide 37 text

36 #CNDT2020 https://bit.ly/32uqZKc アクターモデルとは⾮同期処理のためのメッセージ駆動な分散アプリケーションモデル • すべてのものをアクターとして扱う • メールボックスと振る舞いで構成され、外部との通信はメッセージの送受信のみで⾏う • すべてのメッセージは⾮同期に実⾏され、アクター間では状態を共有しない Erlang, Elixir, Pony などが⾔語レベルでサポートしているほか、ミドルウェアでは Akka が有名 DDD（ドメイン駆動設計）と相性が良いとされる* * https://www.infoq.com/articles/Reactive-Systems-Akka-Actors-DomainDrivenDesign Consumer Actor Provider Actor 取り出したメッセージに応じて振る舞い（Behavior）を決定

Slide 38

Slide 38 text

37 #CNDT2020 https://bit.ly/32uqZKc Virtual Actor とはより動的で変動性の⾼い環境に適応するために、抽象度を⾼めたアクターモデル • Perpetual existence : 実体の有無を問わず、アクターが常に仮想的に存在するものとして扱える • Automatic instantiation : 0 以上のアクターをリクエストに応じて⾃動⽣成 • Location transparency : アクターと対話するアプリケーションは透過的にアクターにコンタクトできるターンベースのアクセスの仕組みを導⼊することでアクターモデルのメールボックスを実現（タイマーなどのスケジュール実⾏の仕組みがオンデマンドリクエストに割り込まないための実⾏順序制御を⾏う） Orleans, Azure Service Fabric, Dapr など、Microsoft が分散システムへのアプローチに採⽤している

Slide 39

Slide 39 text

38 #CNDT2020 https://bit.ly/32uqZKc Dapr における Virtual Actor Dapr Placement サービスがアクターの登録と呼び出し先を制御アクタータイプの登録を受け付け、アクタータイプのリストを全ての Dapr Sidecar に通知 HTTP / gRPC エンドポイントを介して State コンポーネントを呼び出し、状態を管理できるタイマー&リマインダーの機能により定期実⾏のワークロードもサポート client Dapr Sidecar Dapr Placement actor service Actor Type: MyActor Dapr Sidecar Entry Actor Type: MyActor Call Actor ID : 123 for Actor Type: MyActor Where is "Actor ID : 123 for Actor Type: MyActor" ? (client call) MyActor ID: 123 is Created 1 0 2 3 4 https://github.com/dapr/docs/blob/master/concepts/actors

Slide 40

Slide 40 text

39 #CNDT2020 https://bit.ly/32uqZKc invoke workflow-a Dapr Workflows 分散アプリケーションでワークフローを実⾏するためのオプション機能 • Binding や State コンポーネントと連携し、イベント駆動、状態管理を含むワークフローを構成可能 • 現在はワークフローエンジンに Azure Logic Apps を利⽤、 State は Azure Blob Storage に限定 • 将来的には他のワークフローエンジンや State コンポーネントにも対応予定 https://github.com/dapr/workflows Dapr Sidecar Dapr Workflows gRPC input binding < component > binding gRPC server Logic Apps runtime .json Azure Blob Storage http://localhost:3500/v1.0/invoke/workflows/method/workflow-a workflow-a workflow-b Logic Apps Designer, etc.

Slide 41

Slide 41 text

40 #CNDT2020 https://bit.ly/32uqZKc Azure Functions との統合 Dapr の各種コンポーネントを Azure Functions から扱うための拡張機能 • C#, JavaScript / TypeScript, Python で書かれた Azure Functions に対応 • Kubernetes (および IoT Edge) で実⾏する Azure Functions ランタイムが対象 https://github.com/dapr/azure-functions-extension https://www.youtube.com/watch?v=_SlWp2s57rU Dapr Sidecar functional application < component > binding • Dapr Input Binding • サービス呼び出し • Pub/Sub Topic のサブスクライブ Function の起動⽅法 Input Binding： State や Secret の取得 Output Binding： State の保存、Topic 発⾏

Slide 42

Slide 42 text

41 #CNDT2020 https://bit.ly/32uqZKc 補⾜：類似のコンセプトをもつプロジェクトサーバレスにおけるステートフルワークロードのためのフレームワーク • Lightbend が開発を主導している OSS プロジェクト • Kubernetes + Knative + GraalVM 環境を前提とし、複数の⾔語をサポート、混在環境にも対応 • アクターモデルで設計され、状態管理のために Akka Cluster を利⽤している https://github.com/cloudstateio https://www.lightbend.com/cloudstate-by-lightbend

Slide 43

Slide 43 text

ユースケースと実装事例

Slide 44

Slide 44 text

43 #CNDT2020 https://bit.ly/32uqZKc Dapr を使ったマイクロサービスの実装商品の注⽂を受けて決済処理を⾏うユースケースを題材に Order, Payment, Inventory の 3 つのサービスが協調するシナリオを考える • Order は注⽂を受け付けてトランザクションを開始する • 注⽂の受け付けに成功した時点でリクエストを返し、ユーザは⾮同期に注⽂結果を受け取る • 決済と商品確保の両⽅に成功すれば注⽂の成⽴とする order accepted order succeeded/failed client Order Payment Inventory 参考: https://medium.com/@ijayakantha/microservices-the-saga-pattern-for-distributed-transactions-c489d0ac0247

Slide 45

Slide 45 text

44 #CNDT2020 https://bit.ly/32uqZKc ⼆層コミットの問題点 • コミット時にいずれかのサービスに障害が起きた場合に、トランザクションをロールバックする仕組みがない • 全体が、最も遅いサービスのレスポンスに依存する Order Payment Inventory Order Request prepared prepare Payment Phase1 : Prepare prepare → Payment prepare → Inventory ---------------------------- Phase2 : Commit commit → Payment commit → Inventory Transaction done ▶ done ▶ done ▶ done ▶

Slide 46

Slide 46 text

45 #CNDT2020 https://bit.ly/32uqZKc ⼆層コミットの問題点 • コミット時にいずれかのサービスに障害が起きた場合に、トランザクションをロールバックする仕組みがない • 全体が、最も遅いサービスのレスポンスに依存する Order Payment Inventory Order Request prepared commit done prepare Payment Phase1 : Prepare prepare → Payment prepare → Inventory ---------------------------- Phase2 : Commit commit → Payment commit → Inventory Transaction done ▶ done ▶ done ▶ done ▶

Slide 47

Slide 47 text

46 #CNDT2020 https://bit.ly/32uqZKc ⼆層コミットの問題点 • コミット時にいずれかのサービスに障害が起きた場合に、トランザクションをロールバックする仕組みがない • 全体が、最も遅いサービスのレスポンスに依存する Order Payment Inventory Order Request prepared commit done prepare done Payment Phase1 : Prepare prepare → Payment prepare → Inventory ---------------------------- Phase2 : Commit commit → Payment commit → Inventory Transaction done ▶ done ▶ done ▶ failed ▶

Slide 48

Slide 48 text

47 #CNDT2020 https://bit.ly/32uqZKc Saga パターン（オーケストレーション型）メッセージングによってローカルトランザクションの集合を構成する、マイクロサービスのデザインパターンのひとつ Order Inventory Payment Channel Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply PrepareOrderCommand RefundCommand ExecutePayment Command PaymentExecutedReply Order Request * Saga Execution Coordinator Order Service Order SEC* processing Execute Payment Prepare Order Refund cancelling succeeded failed Payment

Slide 49

Slide 49 text

48 #CNDT2020 https://bit.ly/32uqZKc Saga パターンの補償トランザクション Coordinator が期待する状態に遷移できなかった際に、⼀貫性を保つために発⾏する打ち消しのトランザクション決済と商品確保の両⽅に成功すれば注⽂は成⽴するが... Order Payment Inventory order_processing Command: execute_payment Command: prepare_order Reply: item_reserved Reply: payment executed order_succeeded Order Payment Inventory

Slide 50

Slide 50 text

49 #CNDT2020 https://bit.ly/32uqZKc Saga パターンの補償トランザクション Coordinator が期待する状態に遷移できなかった際に、⼀貫性を保つために発⾏する打ち消しのトランザクション商品確保に失敗した場合は⽀払い処理を取り消す Order Payment Inventory order_processing Command: execute_payment Command: prepare_order Reply: out_of_stock Reply: payment executed order_cancelled Command: refund Reply: payment executed order_cancelling Order Payment Inventory

Slide 51

Slide 51 text

50 #CNDT2020 https://bit.ly/32uqZKc AWS で実装する場合 • 1 対多の Pub/Sub に SNS + SQS、Saga の実⾏に Step Functions を利⽤する構成が考えられる • アプリケーションコードから直接呼び出す場合は、インフラストラクチャに依存する Order Inventory Payment Channel Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply PrepareOrderCommand RefundCommand ExecutePayment Command PaymentExecutedReply Order Request Order Service Order SEC* processing Execute Payment Prepare Order + Refund cancelling succeeded failed Amazon SNS + SQS AWS Step Functions Payment * Saga Execution Coordinator

Slide 52

Slide 52 text

51 #CNDT2020 https://bit.ly/32uqZKc AWS 上に実装した Dapr アプリケーション • 実⾏環境に EKS、1 対多の Pub/Sub に SNS + SQS、Saga の状態管理に redis を⽤いた • Dapr によって外部リソースは抽象化されるため、アプリケーションコードがインフラに依存しない Order Inventory Payment Channel Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply PrepareOrderCommand RefundCommand ExecutePayment Command PaymentExecutedReply Order Request Order Service Order SEC* * Saga Execution Coordinator processing succeeded cancelling failed + Amazon SNS + SQS Payment

Slide 53

Slide 53 text

52 #CNDT2020 https://bit.ly/32uqZKc AWS 上に実装した Dapr アプリケーション • Payment サービスが利⽤するシークレットを AWS Secrets Manager で管理、Dapr 経由で取得 Order Inventory Payment Channel Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply PrepareOrderCommand RefundCommand ExecutePayment Command PaymentExecutedReply Order Request Order Service Order SEC* * Saga Execution Coordinator processing succeeded cancelling failed + Amazon SNS + SQS AWS Secrets Manager Payment

Slide 54

Slide 54 text

53 #CNDT2020 https://bit.ly/32uqZKc Azure への展開 • Dapr が抽象化している各コンポーネントを Table Storage, Service Bus, KeyVault で再定義 • アプリケーションコードを変更することなく展開可能 Order Inventory Payment Channel Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply PrepareOrderCommand RefundCommand ExecutePayment Command PaymentExecutedReply Order Request Order Service Order SEC* * Saga Execution Coordinator processing succeeded cancelling failed Azure Kubernetes Service Azure Service Bus Azure Table Storage Payment Azure Key Vault

Slide 55

Slide 55 text

54 #CNDT2020 https://bit.ly/32uqZKc GCP への展開 • Dapr が抽象化している各コンポーネントを redis, Cloud Pub/Sub, Secret Managerで再定義 • アプリケーションコードを変更することなく展開可能 Order Inventory Payment Channel Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply PrepareOrderCommand RefundCommand ExecutePayment Command PaymentExecutedReply Order Request Order Service Order SEC* * Saga Execution Coordinator processing succeeded cancelling failed Google Kubernetes Engine Cloud Pub/Sub Secret Manager Payment

Slide 56

Slide 56 text

55 #CNDT2020 https://bit.ly/32uqZKc 異なる環境(e.g.ローカル/本番) の差異を吸収 Prod Dev ローカルで開発したアプリケーションのコードを、変更することなく本番環境に展開できる例えば、 • ローカルではセルフホストの Kubernetes と redis を使って開発 • 本番ではクラウドのマネージド Kubernetes と各種マネージドサービスを活⽤ • 環境間で変更するのは Dapr コンポーネントのみ、アプリケーションのコードは変更不要

Slide 57

Slide 57 text

56 #CNDT2020 https://bit.ly/32uqZKc 追加検討の候補（今回は未実装） • 商品の在庫確保を並列処理する場合に、アクターパターンを利⽤する • 複数の商品を⼀度に注⽂した際の商品確保を並⾏処理したい、などのユースケースに Inventory Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply Azure Service Bus Stock Search Actor

Slide 58

Slide 58 text

57 #CNDT2020 https://bit.ly/32uqZKc 追加検討の候補（今回は未実装） • Order Saga の実⾏管理を Dapr Workflows に置き換える • 最近のアップデートで、Azure Logic Apps はランタイムを任意の環境で実⾏可能になっている Payment Channel Inventory Channel Order Saga Reply Channel Message Broker PrepareOrderCommand RefundCommand ExecutePayment Command Order Request Order SEC* * Saga Execution Coordinator processing succeeded cancelling failed Azure Service Bus Azure Table Storage Order (Dapr Workflows) Azure Logic Apps

Slide 59

Slide 59 text

58 #CNDT2020 https://bit.ly/32uqZKc 追加検討の候補（今回は未実装） • KEDA を利⽤したイベント駆動のオートスケールを組み合わせる • イベントの流量に応じて 0 ~ N でスケールすることで、展開する Pod の数を最適化 Payment Payment Channel Payment KEDA (Kubernetes Event-driven Autoscaling) • Microsoft と Redhat が開発した、イベント駆動のオートスケーラー • CNCF Sandbox project のひとつ • 例えば、キューのメッセージ数に応じた Pod 増減制御が可能 https://keda.sh/ ・・・

Slide 60

Slide 60 text

59 #CNDT2020 https://bit.ly/32uqZKc 実装してみての所感、課題と感じるところ① • Pub/Sub コンポーネントの機能不⾜ • DeadLetterTopic をサポートしていない • メッセージのバッチ取得をサポートしていない Issue は以前からあり（https://github.com/dapr/dapr/issues/843）、現在も議論が進められている • Dapr Sidecar の起動に時間がかかる • 現状は、KEDA を組み合わせて使うにしても急速なスケーリングには向かない • Dapr Sidecar の起動までアプリケーションを待たせる必要がある Kubernetes の preStop ライフサイクルフックを使うなどのワークアラウンドが使える根本解決には、Kubernetes が Pod 内のコンテナの起動順序を制御できるようになる必要がある → https://github.com/kubernetes/enhancements/issues/753

Slide 61

Slide 61 text

60 #CNDT2020 https://bit.ly/32uqZKc 実装してみての所感、課題と感じるところ② • コントロールプレーンの可⽤性が低い • Virtual Actor を⽤いる場合、Dapr Placement がシステム全体の SPoF になってしまう • Dapr Operator は障害などで再起動すると外部リソースのイベント発⽕を⾒失うことがある • Saga パターンの実装を補助してほしい • Dapr Workflows が今後 Logic Apps 以外のワークフローエンジンに対応することも期待したい • あるいは Uber Cadence などのワークフローオーケストレータとの併⽤も選択肢と考えられる

Slide 62

Slide 62 text

おわりに

Slide 63

Slide 63 text

62 #CNDT2020 https://bit.ly/32uqZKc Dapr の直近のロードマップ GitHub リポジトリやコミュニティで議論されている主なトピック • 全ての SDK で Virtual Actor を実装可能にする • ロードマップに記載の当初予定からは遅れているものの、順次対応が進められている • Dapr コンポーネントの拡充 • 各クラウドにおける主要サービスを中⼼に対応が進む⾒込み • v1.0 到達（Generally Available） • 2020 年内（11⽉頃）に 1.0-rc を出す⾒込みがあるとのこと • 今後は商⽤導⼊の事例が出てくることも期待したい https://github.com/dapr/dapr/wiki/Roadmap

Slide 64

Slide 64 text

63 #CNDT2020 https://bit.ly/32uqZKc 公式リポジトリ以外のおすすめの情報源 Community Call https://www.youtube.com/channel/UCtpSQ9BLB_3EXdWAUQYwnRA/ Gitter https://gitter.im/Dapr/community/ Microsoft Open Source Blog https://cloudblogs.microsoft.com/opensource/

Slide 65

Slide 65 text

64 #CNDT2020 https://bit.ly/32uqZKc 参考URL① Microsoft Ignite 2019 in Orlando より Azure CTO, Mark Russinovich ⽒による Dapr の各機能の解説 & デモ https://www.youtube.com/watch?v=PpJhd-Jo4nM

Slide 66

Slide 66 text

65 #CNDT2020 https://bit.ly/32uqZKc 参考URL② Microsoft Build 2020 より Azure Cognitive Services と連携して、ツイートの感情分析を⾏うデモ • ローカルでの開発→クラウドサービスとの連携→Kubernetes への展開、という流れで、実際の開発をイメージした段階的なデモが取り上げられている • Go, C#, Node.js のそれぞれで作成されたサービスが強調してアプリケーションを構成 https://mybuild.microsoft.com/sessions/3f296b9a-7fe8-479b-b098-a1bfc7783476

Slide 67

Slide 67 text

66 #CNDT2020 https://bit.ly/32uqZKc オライリーから書籍が登場予定 Dapr の主要開発者の 2 ⼈が執筆した解説本が近⽇発売予定 • Amazon.co.jp では 2020/09/14 発売予定 • Early Release は無料で閲覧可能 https://www.oreilly.com/library/view/learning-dapr/9781492072416/

Slide 68

Slide 68 text

67 #CNDT2020 https://bit.ly/32uqZKc まとめマイクロサービスとポータビリティ • マイクロサービスの、独⽴したスケーリング、独⽴したリリースサイクル、独⽴した技術スタックを導⼊できるメリットは、分散システムの複雑性を持ち込むデメリットとのトレードオフになる • インフラストラクチャを抽象化するレイヤがあれば、段階的なマイクロサービス化が進めやすくなる Dapr はマイクロサービスのビルディングブロックを提供する • モジュール式のコンポーネント群がインフラを抽象化、マイクロサービスのポータビリティを⾼める • サイドカーアーキテクチャによりサービス間を仲介し、Polyglot なアプリケーション開発を可能にする • イベント駆動やステートフルなワークロードを実⾏するための⼀貫性のある API と、デザインパターンを適⽤できる

Slide 69

Slide 69 text

Thank you for your attention!