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

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

Transcript

1. Dapr × Kubernetes ではじめる ポータブルなマイクロサービス Masahiko Utsunomiya 2020/09/09 CloudNative Days Tokyo 2020
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
3. 2 #CNDT2020 https://bit.ly/32uqZKc 掲載内容は個⼈の⾒解であり、 所属する企業や組織の⽴場、戦略、意⾒を 代表するものではありません
4. 3 #CNDT2020 https://bit.ly/32uqZKc Agenda • マイクロサービスとポータビリティ • Dapr ⼊⾨ • ユースケースと実装事例 • おわりに
5. マイクロサービスと ポータビリティ
6. 5 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスはクラウドネイティブの唯⼀解？ 流⾏っているから、で選ぶにはあまりに複雑なアーキテクチャ 得られるメリットだけでなく、抱え込む複雑性を理解しておく必要がある 他の選択肢（アーキテクチャ）と⽐較したうえで選んでいることも重要 モノリスは密結合で低品質なアーキテクチャだ、 マイクロサービスこそ唯⼀の解決策！
7. 6 #CNDT2020 https://bit.ly/32uqZKc もう⼀度、モノリシックアーキテクチャから “モノリシック” とは、デプロイの単位が分割されていないという意味 マイクロサービスとのデプロイ粒度の対⽐から⽣まれた⾔葉であり、両者の間にアーキテクチャの 優劣があるわけではない https://www.youtube.com/watch?v=5OjqD-ow8GE “モノリス” のよくある誤解 ☓ 密結合 「コンポーネント間が相互依存し、密結合 になっている」という意味は含まれない ☓ 品質が低い システム個々の問題であり、モノリシック アーキテクチャ⾃体は原因ではない
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 に近いが、サービス化はしない
9. 8 #CNDT2020 https://bit.ly/32uqZKc Microservices 機能ごとに分割されたサービスの集合体でアプリケーションを構成する 各サービスは限定された責任を持ち、⾃律的に管理される https://microservices.io/ üサービス別に独⽴したリリースサイクル 他のサービスに依存することなく、サービスの アップデートが⾏える üサービス別に独⽴したスケーリング 各サービスが個々の必要に応じてスケールでき、 リソースを最適化できる üサービス別に独⽴した技術スタック サービスごとに最適なインフラストラクチャ、 フレームワーク、開発⾔語を選択できる
10. 9 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスを⽬指す判断指標 分散システムの複雑性に対するコストを払ってでも、 アプリケーション（ビジネス）のアジリティ向上が⾒込めるかどうか マイクロサービスの導⼊そのものを⽬的にしてはいけない、 アジリティの向上につながらなければ持続的な開発はできない ...が、マイクロサービスに適しているか最初から⾒通せるとも限らない ではどうやってマイクロサービスを導⼊してゆけば良いのか？ üサービス別に独⽴したリリースサイクル üサービス別に独⽴したスケーリング üサービス別に独⽴した技術スタック ☓ トランザクションやクエリの管理複雑化 ☓ 通信のレイテンシ増加 ☓ E2Eテストの複雑化
11. 10 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスへの道のり モノリスから出発し、段階的なマイクロサービス化を推奨 モジュールの分離と、サービスの分離を別々のタイミングで⾏うことで個々の変更の複雑さを抑制 Modular Monolith 分散システムの複雑性を 持ち込む前に、 モジュールの構造化を⾏う (Strangler pattern) Microservices 途中でモノリスに引き返す or 留まる判断も必要 単⼀の⼩さいチームと モノリスから始めて、 素早く市場に投⼊ Monolith Strangler facade ü 個別のリリースサイクル ü 個別のスケーリング ü 個別の技術スタック
12. 11 #CNDT2020 https://bit.ly/32uqZKc 実⾏環境の変化とポータビリティ 段階的なマイクロサービス化の過程で、フレームワークや環境の差分が アプリケーションに与える変更影響を極⼒減らしたい • 例えば、ローカルの開発環境とクラウドの本番環境でインフラストラクチャが異なっていても、 アプリケーションコードを変更することなくどちらの環境でも稼働してほしい Cloud platform Localhost Secret State Store Message Broker Secret State Store Message Broker Application Application
13. 12 #CNDT2020 https://bit.ly/32uqZKc 実⾏環境の変化とポータビリティ 段階的なマイクロサービス化の過程で、フレームワークや環境の差分が アプリケーションに与える変更影響を極⼒減らしたい • 例えば、段階的に新しくサービスを追加してゆく過程で、これから構築するサービスの技術選定が 既存の技術スタックに依存しないようにしたい Framework A Framework B
14. 13 #CNDT2020 https://bit.ly/32uqZKc アプリケーションのポータビリティ 異なる環境間で同じようにアプリケーションを実⾏できる性質 （ポータビリティ）が段階的なマイクロサービス化に役⽴つ • ポータビリティはアプリケーションのコンテナ化だけでは完結しない（インフラストラクチャ, etc.） • コンテナの実⾏環境としては、Kubernetes が代表的な抽象化の⼿段 • アプリケーションが実⾏環境や開発⾔語に依存しなければ、より柔軟な開発・構成が可能に
15. 14 #CNDT2020 https://bit.ly/32uqZKc ここまでのまとめ システムによって、適切なアーキテクチャは異なる • アーキテクチャの特性を理解し、アプリケーションに合ったアーキテクチャを選定することが⼤事 • モノリスとマイクロサービスのどちらが優れている、ということではない • アジリティ向上のために、サービス別に独⽴したリリースサイクル、スケーリング、技術スタック が必要ならば、マイクロサービスは有効な選択肢のひとつ マイクロサービスへの道のり • 分散システムの複雑性とのトレードオフ、ビジネスのアジリティ向上が⾒込めるかが判断ポイント • モノリスから出発して早期に市場へ投⼊、段階的なマイクロサービス化を推奨 • その過程でプラットフォームや⾔語・フレームワークの差異を受け⽌めて抽象化してくれるレイヤ があれば、ビジネスロジックにより注⼒できる
16. 15 #CNDT2020 https://bit.ly/32uqZKc 補⾜： マイクロサービス化にもうひとつ（あるいは最も）重要なもの マイクロサービスに合った組織編成 • コンパクトで、開発と運⽤の双⽅に責任を持ち、適切に権限が移譲された、ビジネスコンテキスト に基づく組織編成 • 技術的な問題よりも乗り越えるのが難しい、マイクロサービス導⼊の壁 逆コンウェイ戦略 • マイクロサービス化を促進しやすくするように、組織構造や組織⽂化を変えていく • 旧来の縦割りの組織構造や⽂化のまま、マイクロサービスを実現するのは困難
17. Dapr ⼊⾨ ポータブルなマイクロサービスのためのビルディングブロック
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/
19. 18 #CNDT2020 https://bit.ly/32uqZKc マイクロサービスのビルディングブロック 標準化された API, Pub/Sub, トレーシングなど、分散システムの実装を 容易にするための機能を 7 つのカテゴリで提供 フレームワークではなくビルディングブロックとして設計されており、⼀部からでも使い始められる https://github.com/dapr/docs/tree/master/overview
20. 19 #CNDT2020 https://bit.ly/32uqZKc サイドカーアーキテクチャ アプリケーションと独⽴したコンテナ/プロセスで稼働し、API を公開 • アプリケーションコードに Dapr のランタイムに関するコードが混⼊しない • Dapr の各機能は HTTP / gRPC で呼び出す • ローカル端末（Linux, Mac, Windows）、Kubernetes、エッジデバイスなど、任意の環境で実⾏できる https://github.com/dapr/docs/tree/master/overview
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 ...
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 つの統合サービスが展開される
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
24. 23 #CNDT2020 https://bit.ly/32uqZKc 他のマイクロサービスフレームワークとの違い Dapr は分散アプリケーションを任意の開発⾔語で実装できる 例えば Java であれば Axon, Eventuate, MicroProfile LRA などのフレームワークが既にあるが、これらは 連携する各サービスが同じフレームワークを使って実装されることを前提としている Dapr はサイドカーアーキテクチャによって ⼀貫性のあるサービス呼び出しの API を提供することで、 ⾔語やフレームワークを問わない Polyglot なアプリケーション開発を可能にする Go Java & framework B Java & framework A C#
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
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
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
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
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"
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
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
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"
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
34. 33 #CNDT2020 https://bit.ly/32uqZKc Dapr の Observability Dapr Sidecar からサービスのメトリクス、ログ、トレースを収集 コントロールプレーンのサービス（Dapr Placement, etc.）は現状メトリクスとログのみを提供 以下は代表的な構成例 Observability : 制御⼯学由来の⾔葉で、モニタリングの⽂脈では動的に変化し続ける環境の信頼性を継続的に確保するための考え⽅を指す application Dapr Sidecar Metrics Tracing Logging Dashboard は テンプレートが 提供されている
35. 34 #CNDT2020 https://bit.ly/32uqZKc Dapr Dashboard Dapr が認識しているアプリケーションや、コンポーネントを確認可能 接続先の app-id （Dapr のアプリケーション識別⼦）を確認することができる ログも参照できるが、現状は⾮常に簡易的な機能 https://github.com/dapr/dashboard
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 などが⽤意されている
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）を決定
38. 37 #CNDT2020 https://bit.ly/32uqZKc Virtual Actor とは より動的で変動性の⾼い環境に適応するために、抽象度を⾼めた アクターモデル • Perpetual existence : 実体の有無を問わず、アクターが常に仮想的に存在するものとして扱える • Automatic instantiation : 0 以上のアクターをリクエストに応じて⾃動⽣成 • Location transparency : アクターと対話するアプリケーションは透過的にアクターにコンタクトできる ターンベースのアクセスの仕組みを導⼊することでアクターモデルのメールボックスを実現 （タイマーなどのスケジュール実⾏の仕組みがオンデマンドリクエストに割り込まないための実⾏順序制御を⾏う） Orleans, Azure Service Fabric, Dapr など、Microsoft が分散システムへのアプローチに採⽤している
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
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.
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 発⾏
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
43. ユースケースと実装事例
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
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 ▶
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 ▶
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 ▶
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
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
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
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
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
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
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
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
56. 55 #CNDT2020 https://bit.ly/32uqZKc 異なる環境(e.g.ローカル/本番) の差異を吸収 Prod Dev ローカルで開発したアプリケーションの コードを、変更することなく本番環境に 展開できる 例えば、 • ローカルではセルフホストの Kubernetes と redis を使って開発 • 本番ではクラウドのマネージド Kubernetes と 各種マネージドサービスを活⽤ • 環境間で変更するのは Dapr コンポーネントのみ、 アプリケーションのコードは変更不要
57. 56 #CNDT2020 https://bit.ly/32uqZKc 追加検討の候補（今回は未実装） • 商品の在庫確保を並列処理する場合に、アクターパターンを利⽤する • 複数の商品を⼀度に注⽂した際の商品確保を並⾏処理したい、などのユースケースに Inventory Inventory Channel Order Saga Reply Channel Message Broker OutOfStockReply Azure Service Bus Stock Search Actor
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
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/ ・・・
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
61. 60 #CNDT2020 https://bit.ly/32uqZKc 実装してみての所感、課題と感じるところ② • コントロールプレーンの可⽤性が低い • Virtual Actor を⽤いる場合、Dapr Placement がシステム全体の SPoF になってしまう • Dapr Operator は障害などで再起動すると外部リソースのイベント発⽕を⾒失うことがある • Saga パターンの実装を補助してほしい • Dapr Workflows が今後 Logic Apps 以外のワークフローエンジンに対応することも期待したい • あるいは Uber Cadence などのワークフローオーケストレータとの併⽤も選択肢と考えられる
62. おわりに
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
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/
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
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
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/
68. 67 #CNDT2020 https://bit.ly/32uqZKc まとめ マイクロサービスとポータビリティ • マイクロサービスの、独⽴したスケーリング、独⽴したリリースサイクル、独⽴した技術スタックを 導⼊できるメリットは、分散システムの複雑性を持ち込むデメリットとのトレードオフになる • インフラストラクチャを抽象化するレイヤがあれば、段階的なマイクロサービス化が進めやすくなる Dapr はマイクロサービスのビルディングブロックを提供する • モジュール式のコンポーネント群がインフラを抽象化、マイクロサービスのポータビリティを⾼める • サイドカーアーキテクチャによりサービス間を仲介し、Polyglot なアプリケーション開発を可能にする • イベント駆動やステートフルなワークロードを実⾏するための⼀貫性のある API と、 デザインパターンを適⽤できる
69. Thank you for your attention!