Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

polar3130
September 09, 2020

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

CloudNative Days Tokyo 2020 ( CNDT2020 )
Day 2, Track E「Dapr × Kubernetes ではじめるポータブルなマイクロサービス」のスライド資料です

polar3130

September 09, 2020
Tweet

More Decks by polar3130

Other Decks in Technology

Transcript

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

    View Slide

  2. 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. 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 に近いが、サービス化はしない

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  18. 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/

    View Slide

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

    View Slide

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

    View Slide

  21. 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 ...

    View Slide

  22. 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 つの統合サービスが展開される

    View Slide

  23. 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

    View Slide

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

    View Slide

  25. 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

    View Slide

  26. 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

    View Slide

  27. 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

    View Slide

  28. 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

    View Slide

  29. 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"

    View Slide

  30. 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

    View Slide

  31. 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

    View Slide

  32. 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"

    View Slide

  33. 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. 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)を決定

    View Slide

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

    View Slide

  39. 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

    View Slide

  40. 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.

    View Slide

  41. 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 発⾏

    View Slide

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

    View Slide

  43. ユースケースと実装事例

    View Slide

  44. 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

    View Slide

  45. 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 ▶

    View Slide

  46. 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 ▶

    View Slide

  47. 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 ▶

    View Slide

  48. 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

    View Slide

  49. 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

    View Slide

  50. 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

    View Slide

  51. 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

    View Slide

  52. 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

    View Slide

  53. 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

    View Slide

  54. 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

    View Slide

  55. 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

    View Slide

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

    View Slide

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

    View Slide

  58. 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

    View Slide

  59. 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/
    ・・・

    View Slide

  60. 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

    View Slide

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

    View Slide

  62. おわりに

    View Slide

  63. 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

    View Slide

  64. 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/

    View Slide

  65. 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

    View Slide

  66. 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

    View Slide

  67. 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/

    View Slide

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

    View Slide

  69. Thank you for your attention!

    View Slide