Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）

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

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

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

Agenda
• マイクロサービスとポータビリティ
• Dapr ⼊⾨
• ユースケースと実装事例
• おわりに

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

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

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

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

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

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

マイクロサービスへの道のり
モノリスから出発し、段階的なマイクロサービス化を推奨
サービスを分離するために、先にモジュールの分離・構造化をしておくことが有効
Modular Monolith であれば予め分割しておいたモジュールがサービス境界の指針になる
Modular Monolith
分散システムの複雑性を
持ち込む前に、
モジュールの構造化を⾏う
(Strangler pattern) Microservices
途中でモノリスに引き返す
or 留まる判断も必要
モノリスから始めて
素早く市場に投⼊
Monolith
Strangler facade
ü 個別のリリースサイクル
ü 個別のスケーリング
ü 個別の技術スタック

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

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

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

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

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

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

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

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

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

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 の変更を通知
4 つの統合サービスが展開される

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

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

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

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"
1. Dapr に向けて Payment
サービスを呼び出す
http://localhost:3500/v1.0/invoke/payment/method/execute
2. Dapr が Payment
サービスを検出＆呼び出し
3. Dapr がリクエストを
アプリケーションに転送
Dapr Sidecar Dapr Sidecar

・・・
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

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

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"

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

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

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"

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

Dapr の Observability
Dapr Sidecar からサービスのメトリクス、ロギング、トレースを収集
コントロールプレーンのサービス（Injector, etc.）は現状メトリクスとログのみを提供
将来的には全てのテレメトリを Open Telemetry 準拠とする⽅針
以下は代表的な構成例
Observability : 制御⼯学由来の⾔葉で、クラウドネイティブなモニタリングの⽂脈では動的に変化し続ける環境の信頼性を継続的に確保するための考え⽅を指す
application Dapr Sidecar
Metrics
Tracing
Logging
Dashboard は
テンプレートが
提供されている

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

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 などが⽤意されている

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

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

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
02
3
4
https://github.com/dapr/docs/blob/master/concepts/actors

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.

Azure Function との統合
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 発⾏

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

ユースケースと実装事例

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

⼆層コミットの問題点
• コミット時にいずれかのサービスに障害が起きた場合に、
他のトランザクションをロールバックする仕組みがない
• 全体が、最も遅いサービスのレスポンスに依存する
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 ▶

Order
Payment
Inventory
Order Request
prepared
commit
done
prepare
Payment
Phase1 : Prepare
prepare → Payment
----------------------------
Phase2 : Commit
commit → Payment
Transaction
done ▶
done ▶
done ▶
done ▶

Order
Payment
Inventory
Order Request
prepared
commit
done
prepare
done
Payment
Phase1 : Prepare
prepare → Payment
----------------------------
Phase2 : Commit
commit → Payment
Transaction
done ▶
done ▶
done ▶
failed ▶

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

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

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 executedorder_cancelling
Order
Payment
Inventory

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
Order RequestOrder Service
Order SEC*
processing
Execute Payment Prepare Order
+
Refund
cancelling
succeeded
failed
Amazon SNS + SQS
AWS
Step Functions
Payment

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
Order Request
Order Service
Order SEC*
processing
succeeded
cancelling
failed
+
Amazon SNS + SQS
Payment

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

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

GCP への展開
• Dapr が抽象化している各コンポーネントを AKS, Table Storage, Service Bus, KeyVault で再定義
• アプリケーションコードを変更することなく展開可能
Order
Inventory
Payment Channel
Inventory Channel
Order Saga
Reply Channel
Message Broker
OutOfStockReply
PrepareOrderCommand
RefundCommand
ExecutePayment
Command
Order Request
Order Service
Order SEC*
processing
succeeded
cancelling
failed
Google
Kubernetes
Engine
Cloud
Pub/Sub
Secret
Manager
Payment

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

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

• 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*
processing
succeeded
cancelling
failed
Azure
Service Bus
Azure
Table Storage
Order
(Dapr Workflows)
Azure Logic Apps

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

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

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

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

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

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

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

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

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

Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）

More Related Content

What's hot

Similar to Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）

More from NTT DATA Technology & Innovation

Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）