Download to read offline
Dapr on Kubernetes
- 1. はじめてのDapr on Kubernetes ～分散システムでの一過性の障害に備える～ ShihoASA＠Microsoft
- 2. Agenda • 分散システムにおける一過性の障害 • Daprとは • Dapr のResiliency • まとめ
- 3. オンプレデータセンターでありがちだった課題 インフラ(ハードウエア)の管理 変動するリクエストに応じたシステム拡張が困難 既存システムに変更を加えるときは事前に関係各所と調整 業務アプリのバージョンアップは夜間休日 作業手順書 && チェックリスト による手作業メイン ➡ 直接的なビジネス価値を生まない作業の負荷が増大 ➡ クラウドを活用しよう！
- 4. クラウド導入の効果 インフラはクラウドベンダーが管理 メンテナンスもクラウドベンダーが実施 従量課金で必要なリソースを必要な時に調達可能 CI/CD 環境を整備して、リリース作業を自動化 ➡ インフラの運用負荷が下がった ➡ アプリの更新頻度が上がり、ビジネスニーズを取り込みやすくなった
- 5.
- 6.
- 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.
- 11. 一過性の障害に備えるためのアプリケーション実装例 アプリケーションでのリトライ処理を検討 • リトライの妥当性を判断 ➡ 障害が一過性であり、再試行すれば操作に成功する可能性がある場合に限定する ➡データベースに存在しない項目の更新、致命的なエラーが生じているサービスやリソースへ の要求などは再試行しても改善しない •リトライの試行回数と間隔を決める ➡ リトライの回数が不足していると、アプリケーションが操作を完了できず、エラーとなる ➡ リトライ回数が多すぎるか、試行間隔が短すぎると、スレッドや接続、メモリなどのリソー スをアプリケーションが長時間占有することになる https://learn.microsoft.com/ja-jp/azure/architecture/best-practices/transient-faults#general-guidelines
- 12.
- 13. 分散システムが本質的に持つ技術的課題 サービス間の呼び出し サービス間での状態共有 システムの監視 シークレットの管理 障害部分のみ切り離してサービスを継続させる
- 14. Dapr (Distributed ApplicationRuntime) とは クラウドネイティブなシステムにおいて分散処理を実装するアプリケーションランタイム Microsoftが開発を主導するOSSでCNCFに寄贈 ✓Dapr自身がコンテナと して実行 ✓サービスから HTTP/gRPC API経由 で呼び出して利用する ビルディングブロック
- 15. Dapr の提供機能 コンポーネント 説明 ServiceInvocation リトライ/分散トレースなどのマイクロサービスに必要な機能をサポートするサービス間通信機能 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 の ServiceInvocation Dapr がアプリケーション間で通信する機能 ✓ HTTP および gRPC でのサービス呼び出し ✓ サービス間のセキュリティ ✓ リクエストのタイムアウト/再試行/サーキットブレーカー ✓ 可観測性とトレースの実装 ✓ mDNS によるラウンド ロビン負荷分散
- 17. Dapr の ServiceInvocation サービス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を指定できる ✓exponentialback-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.
- 27.