Cloud Native Days Tokyo 2022 Dapr on Kubernetes

1. はじめてのDapr on Kubernetes
～分散システムでの一過性の障害に備える～
Shiho ASA＠Microsoft

2. Agenda
• 分散システムにおける一過性の障害
• Dapr とは
• Dapr のResiliency
• まとめ

3. オンプレデータセンターでありがちだった課題
 インフラ(ハードウエア)の管理
 変動するリクエストに応じたシステム拡張が困難
 既存システムに変更を加えるときは事前に関係各所と調整
 業務アプリのバージョンアップは夜間休日
 作業手順書 && チェックリスト による手作業メイン
➡ 直接的なビジネス価値を生まない作業の負荷が増大
➡ クラウドを活用しよう！

4. クラウド導入の効果
 インフラはクラウドベンダーが管理
 メンテナンスもクラウドベンダーが実施
 従量課金で必要なリソースを必要な時に調達可能
 CI/CD 環境を整備して、リリース作業を自動化
➡ インフラの運用負荷が下がった
➡ アプリの更新頻度が上がり、ビジネスニーズを取り込みやすくなった

5. が、、、、、ごくまれにある悲劇
御社クラウドで動かしているうちの
基幹システムがエラーが発生して
業務影響が出ていたようです。
クラウドでメンテを
していませんでしたか？
はい。その時間帯に
メンテナンスを実施しています

6. 一過性の障害
ユーザ影響の少ない夜間
に対応してもらわないと
困る！！
弊社側のタイミングで
SLAを下回らないよう
調整しながら自動で
基盤メンテします
いやいや、うちは海外利用
するシステムなので日本
時間の日中にして！！

7. クラウドで一過性の障害が起こる理由
• クラウドは、複数の計算ユニットやインフラに負荷を動的に配分することでパフォーマンスを実
現し、コンポーネントを自動的にリサイクル (交換) することで信頼性を確保している
• クラウドリソースは多くのユーザ共有されており、それらのリソースを保護するために使用量が
調整されることがある
• クラウド環境では、ハードウェア コンポーネント (ルーター、ロード バランサーなどのネットワーク
インフラストラクチャ) の構成要素が多い
• クライアントとサーバー間のネットワーク (特にインターネットを経由する通信)では断続的な接
続障害が発生しやすい
https://learn.microsoft.com/ja-jp/azure/architecture/best-practices/transient-faults

8. インフラ構成の違い
Public IP
ILB
Availability
Set
APP1
LB
Availability
Set
WEB1 WEB2
APP2
 物理サーバを意識したアーキテクチャ
 システム管理者が運用保守
計画メンテ
バックアップ
パッチ適用
ストレージ管理
ネットワーク管理
アプリリリース
Availability
Set
node0
Public IP
LB LB LB
Gateway
node1 node2 node3 node4
node5 node6 node7 node8 node9
Master0 Master1 Master2
複数ノードの管理
コンテナアプリの配置
オートスケーリング
死活監視
障害時自己復旧
負荷分散
ストレージ管理
サービスディスカバリー
 インフラレイヤーを抽象化しシステム管理をソフトウエアで自動化
 従来の方式設計に加えて、考慮すべきポイントが発生する

9. システムメンテナンスの考え方の違い
Public IP
ILB
Availability
Set
APP1
LB
Availability
Set
WEB1 WEB2
APP2
システム管理者が実施
○○基幹システムメンテ
6/5 夜間実施
担当: xx
＜作業手順書＞
1. サーバーの起動
2. DBの起動
3. 動作確認
4. バックエンドサーバの起動
5. 動作確認
6. フロントサーバの起動
7. 動作確認
8. ロードバランサの起動
9. 外部疎通性確認
・ ・ ・
Availability
Set
node0
Public IP
LB LB LB
Gateway
node1 node2 node3 node4
node5 node6 node7 node8 node9
Master0 Master1 Master2
• メンテナンス対象ノードで動
いているアプリに退避要求
• 複数あるノードプールを順
次バージョンアップ(系全体
系としては無停止)
• メンテナンス終了したノード
に新たにアプリがデプロイさ
れる
• 新しくデプロイされたアプリ
ケーションに対し、LBがリク
エストを転送
ソフトウエアで自動化

10. 大規模基幹システムにおける方式設計の例
非機能要件を満たすハー
ドウエア構成/ソフトウエア
アーキテクチャを設計
機能要件を満たすアプリ
ケーションの処理方式や
画面・業務プロセス・デー
タなどを設計
セキュリティ
性能・信頼性設計
運用方式設計
移行方式設計
他システム連携
etc
・ ・ ・
クラウドのメリットを活かしたシステム構築やアプリケーション開発をするために
検討しておくポイントがある

11. 一過性の障害に備えるためのアプリケーション実装例
アプリケーションでのリトライ処理を検討
• リトライの妥当性を判断
➡ 障害が一過性であり、再試行すれば操作に成功する可能性がある場合に限定する
➡データベースに存在しない項目の更新、致命的なエラーが生じているサービスやリソースへ
の要求などは再試行しても改善しない
• リトライの試行回数と間隔を決める
➡ リトライの回数が不足していると、アプリケーションが操作を完了できず、エラーとなる
➡ リトライ回数が多すぎるか、試行間隔が短すぎると、スレッドや接続、メモリなどのリソー
スをアプリケーションが長時間占有することになる
https://learn.microsoft.com/ja-jp/azure/architecture/best-practices/transient-faults#general-guidelines

12. Dapr on Kubernetes 101

13. 分散システムが本質的に持つ技術的課題
 サービス間の呼び出し
 サービス間での状態共有
 システムの監視
 シークレットの管理
 障害部分のみ切り離してサービスを継続させる

14. Dapr (Distributed Application Runtime) とは
 クラウドネイティブなシステムにおいて分散処理を実装するアプリケーションランタイム
 Microsoftが開発を主導するOSSでCNCFに寄贈
✓Dapr自身がコンテナと
して実行
✓サービスから
HTTP/gRPC API経由
で呼び出して利用する
ビルディングブロック

15. Dapr の提供機能
コンポーネント 説明
Service Invocation リトライ/分散トレースなどのマイクロサービスに必要な機能をサポートするサービス間通信機能
State management キー/バリュー形式の状態管理 状態を保管するコンポーネントとしてRedis/MySQLなどがある
Publish & subscribe
messaging
Publish/Subscribe形式のメッセージング機能
Bindings データベースやキュー、ファイルシステムなどにイベントを送受信する機能
Actors アクターズパターンに関連する機能
Observability 各種メトリックス、ログ、トレース機能
Secrets management 秘匿情報の管理機能 AWS Secrets Manager/GCP Secrets Manager/Azure Key Vaultなどと連携可能
Configuration アプリケーションの構成管理

16. Dapr の Service Invocation
Dapr がアプリケーション間で通信する機能
✓ HTTP および gRPC でのサービス呼び出し
✓ サービス間のセキュリティ
✓ リクエストのタイムアウト/再試行/サーキットブレーカー
✓ 可観測性とトレースの実装
✓ mDNS によるラウンド ロビン負荷分散

17. Dapr の Service Invocation
サービスAからサービスBを呼び出す場合
① サービスAからDaprサイドカーにリクエスト
② DaprがサービスBの名前解決
③ DaprがサービスBのDaprサイドカーに転送
④ サービスB の Daprサイドカーは、サービスB
のエンドポイントにリクエストを転送し
サービスBはビジネスロジックを実行
⑤ サービスBからDaprサイドカーにレスポンス
⑥ DaprがサービスAのDaprサイドカーに転送
⑦ サービスAがレスポンスを受信
React
Java
Spring Boot
Dapr
フロントエンド
localhost
サービスB
サービスA
name
resolution
component
❶
❸
Node.js Dapr
localhost
➍
❺
➏
➐
❷

18. Dapr on Kubernetes ～セットアップ～
$ dapr init --kubernetes --wait
https://github.com/dapr/quickstarts/tree/master/tutorials/hello-kubernetes
$ kubectl get deploy,svc,statefulset -n dapr-system
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/dapr-dashboard 1/1 1 1 7d23h
deployment.apps/dapr-operator 3/3 3 3 7d23h
deployment.apps/dapr-sentry 3/3 3 3 7d23h
deployment.apps/dapr-sidecar-injector 3/3 3 3 7d23h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
AGE
service/dapr-api ClusterIP 10.0.106.48 <none> 80/TCP
service/dapr-dashboard ClusterIP 10.0.246.148 <none> 8080/TCP
service/dapr-placement-server ClusterIP None <none>
50005/TCP,8201/TCP service/dapr-sentry ClusterIP 10.0.54.111 <none>
80/TCP service/dapr-sidecar-injector ClusterIP 10.0.133.83 <none>
443/TCP service/dapr-webhook ClusterIP 10.0.158.32 <none>
443/TCP
NAME READY AGE
statefulset.apps/dapr-placement-server 3/3 7d23h
✓ Dapr CLIでKubernetesにデプロイ
✓ DaprはOperatorとして動作
✓ Dapr-sidecar-injectorはDaprが
Enableなアプリに対してサイドカーを動
かすデプロイメント
✓ Dashboardも用意されている

19. Dapr on Kubernetes ～アプリケーションのデプロイ～
https://github.com/dapr/quickstarts/tree/master/tutorials/hello-kubernetes
kind: Deployment
apiVersion: apps/v1
metadata:
name: backend
...
spec:
...
template:
metadata:
...
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "backend"
dapr.io/app-port: "8080"
dapr.io/config: "featureconfig"
spec:
containers:
✓ Daprを有効にするには、アノテーションを設定
✓ dapr.io/config アノテーションは、Daprでリトラ
イ処理などを行うために必要な設定
アノテーション 説明
dapr.io/enabled Daprを有効にするかどうか
dapr.io/app-id Dapr ID(クラスタ内で一意になるよう
に設定)
dapr.io/app-port アプリのポート番号
dapr.io/config Configファイルの読み込み

20. Dapr on Kubernetes ～サービスの呼び出し～
import io.dapr.client.DaprClient;
import io.dapr.client.DaprClientBuilder;
import io.dapr.client.domain.HttpExtension;
...
@SpringBootApplication
public class SampleServiceApplication {
...
DaprClient daprClient = new DaprClientBuilder().build();
var result = daprClient.invokeMethod(
“serviceb",
“todos/" + id,
null,
HttpExtension.GET,
String.class
);
...
}
✓ 提供されているDapr SDKを利用
.NET/Java/Python/Go/Javascript
✓ HTTP/gRPC での呼び出し
dapr-app-id ヘッダにサービス名を指定
✓ Dapr CLI での呼び出し
✓ エンドポイントにGETリクエスト送信
(次のページ)
https://docs.dapr.io/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services/
$ dapr invoke
--app-id serviceb
--method todos/100

21. Dapr on Kubernetes ～サービスの呼び出し～
http://localhost:3500/v1.0/invoke/serviceb/method/todos
React
Java
Spring
Boot
Dapr
フロントエンド
Pod
サービスB Pod
サービスA Pod
Node.js Dapr
http://localhost:8080/todos
8080
3500
呼び出し先サービス名 呼び出し先パス
Daprポート
アプリのポート
dapr-app-id: serviceb

22. Dapr の Resiliency
✓ Daprでは次のResiliency機能を提供
⚫ タイムアウト
⚫ リトライ
⚫ サーキットブレーカ
✓Resiliency 機能を有効にするには、Pod 側で
dapr.io/config: “featureconfig” アノテーショ
ンを設定する必要がある
https://docs.dapr.io/operations/resiliency/resiliency-overview/
apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
name: todo-resiliency
...
spec:
policies:
# タイムアウトの設定
timeouts:
general: 5s
important: 60s
largeResponse: 10s

23. Dapr の Resiliency
リトライのポリシー
✓exponential/constantを指定できる
✓exponential back-off の場合は次の式で評価
✓constantの場合は、リトライ間隔(duration)を指定で
きる
✓maxRetriesで再試行回数を指定
https://docs.dapr.io/operations/resiliency/resiliency-overview/
apiVersion: dapr.io/v1alpha1
kind: Resiliency
...
spec:
policies:
# リトライの設定
retries:
retryForever:
policy: exponential
maxInterval: 15s
maxRetries: -1
important:
policy: constant
duration: 5s
maxRetries: 30
someOperation:
policy: exponential
maxInterval: 15s
BackOffDuration = PreviousBackOffDuration *
(Random value from 0.5 to 1.5) * 1.5
if BackOffDuration > maxInterval {
BackoffDuration = maxInterval
}

24. Dapr の Resiliency
サーキットブレーカーのポリシー
⚫ maxRequests: ハーフオープン(障害からの回復)時に通
過できるリクエストの最大数を指定
⚫ trip: サーキットブレーカーで評価されるステートメント
⚫ timeout: サーキットブレーカーがハーフオープンに切り替
わるまでの期間。デフォルトは60s
⚫ Interval: サーキットブレーカーがカウントをクリアするた
めの間隔
✓サーキットブレーカーは、Daprサイドカーが動作している限
り、カウンターを維持するが永続化されないので注意
apiVersion: dapr.io/v1alpha1
kind: Resiliency
...
spec:
# サーキットブレーカーの設定
circuitBreakers:
simpleCB:
maxRequests: 1
timeout: 30s
trip: consecutiveFailures >= 5
pubsubCB:
maxRequests: 1
interval: 8s
timeout: 45s
trip: consecutiveFailures > 8
https://docs.dapr.io/operations/resiliency/policies/#circuit-breakers

25. apiVersion: dapr.io/v1alpha1
kind: Resiliency
...
spec:
policies:
# タイムアウトの設定
timeouts:
general: 5s
important: 60s
largeResponse: 10s
# リトライ/CBの設定
retries:
retryForever:
...
circuitBreakers:
simpleCB:
...
targets:
apps:
serviceb: # Dapr IDを設定
timeout: general
retry: retryForever
circuitBreaker: simpleCB
Dapr の Resiliency
✓定義したポリシーをどのターゲット(アプリ)に適用する
かを指定
✓スコープを設定して適用を限定させることも可能
✓ 組み込みのデフォルトポリシーがあるがユーザ定義ポリシー
のほうが優先度が高い
⚫ DefaultRetryPolicy
⚫ DefaultTimeoutPolicy
⚫ DefaultCircuitBreakerPolicy
どういうふるまいをするかを検証してから本番適用へ！

26. まとめ
✓クラウドに限らず分散システムでは一過性の障害は起こりえる
✓分散システムの特性を知ったうえでアプリケーションで回避できるかを検討
すると良い
✓分散アプリケーションランタイム「Dapr」にはResiliency の機能がある
✓Dapr サイドカーがタイムアウト/リトライ/サーキットブレーカー
✓リトライの妥当性判断や試行回数・間隔はアプリやシステムに依存する
➡用法用量を守って正しくお使いください

27. thanks