Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Kubernetes × 可用性 -- cndjp第3回勉強会

3,346 views

Published on

Cloud Native Developers JP(cndjp)第3回勉強会の発表資料です。
今回のテーマはKubernetes × 可用性

Published in: Technology
  • Login to see the comments

Kubernetes × 可用性 -- cndjp第3回勉強会

  1. 1. #cndjp3
  2. 2. Kubernetes × 可用性 高可用性のための設計と実装 #cndjp3
  3. 3. 自己紹介 • 早川 博(はやかわ ひろし) • 日本オラクル所属 • Pre-Sales Engineer / Tech Evangelist • Java SE/EE, Microservices/DevOps @hhiroshell
  4. 4. Kubernetes×可用性 4箇条 • レイヤー分けして考えろ • マイクロサービス・アーキテクチャとKubernetesは好相性 • リリースの安定はサービスの安定 • インフラ選定はクラウドで決まり
  5. 5. 1. レイヤー分けして考えろ
  6. 6. Susan J. Fowlerの 「マイクロサービス・エコシステム」 マイクロサービス 通信 アプリケーション・プラットフォーム ハードウェア サービス間の通信 RPC、APIエンドポイント、 サービスディスカバリ、 サービスレジストリ… マイクロサービス以外のツー ルやサービス CI/CD、ロギング、監視… サービス本体
  7. 7. Kubernetesを含む場合の4層 マイクロサービス 通信 アプリケーション ・プラットフォーム ハードウェア ハードウェア Kubernetes マイクロ サービス アプリケーション ・プラットフォーム k8sとの組み合わせで 高機能・高可用性を 実現していく領域
  8. 8. レイヤー毎に障害対策を考える ハードウェア Kubernetes マイクロ サービス アプリケーション ・プラットフォーム SPOFの除去 障害シナリオ と対応計画 リハーサル それぞれの項目について優先度 を決めて処置を講じる
  9. 9. 今日やりたいことやれること マイクロサービス・アーキテクチャとKubernetesは好相性 リリースの安定はサービスの安定 インフラ選定はクラウドで決まり ハードウェア Kubernetes マイクロ サービス アプリケーション ・プラットフォーム
  10. 10. 2. マイクロサービス・アーキテクチャ とKubernetesは好相性 サービスレイヤーの可用性
  11. 11. マイクロサービス・アーキテクチャ • 大規模なシステムを小規模なサービスの組み合わせで実現する アーキテクチャ • 複数のサービス群をHTTP(s)、RPC、非同期メッセージング等 により疎結合に連携 • 変更の影響範囲をサービスに留めることで、頻繁なアップデー トを実現する
  12. 12. 参考)マイクロサービス・アーキテクチャの トレードオフ 更新頻度 変更の影響範囲が把握しにくい ため、頻繁に更新できない 影響範囲がサービスにとどまる ため、高頻度で更新できる 耐障害性 障害の影響がシステム全体に及 びやすい 障害の影響範囲をサービスに留 めるように設計できる 特殊要件への対応 技術スタックを変えられないの で、対応可能な要件に限界があ る 要件に合わせて最適な技術を サービスに採用することができ る パフォーマンス 通信のオーバーヘッドが無いた め、従来通りのパフォーマンス が出る サービス間通信のオーバーヘッド のため、パフォーマンスが落ちや すい データの一貫性 基本的にはデータベースがひと つなので、データの一貫性を保 ち易い サービスをまたぐトランザク ションは実現困難 運用・管理性 管理対象が少ないための、運 用・管理が比較的シンプル サービスが増える分だけ管理対 象が増加 必要なスキル従来のスキルで対処可能 非同期処理の取扱いが難しい。 障害時に原因箇所が見つけにく い Monolithic Microservices
  13. 13. MSA on k8sで可用性を考えるときのポイント • 各サービス単体としての可用性にフォーカスする • 小規模な分だけやりやすい • 例えば古典的な3層アプリの構成なら、従来と同じプラクティスが使え る • Kubernetesの機能をうまく活用する • サービス境界(サービス同士の連携箇所)に対策を施す • MSAならではの考慮点 • Kubernetes + サービスメッシュをうまく活用する
  14. 14. DB AP Web サービス単体とし ての可用性 サービス単体とし ての可用性 サービス単体とし ての可用性 サービス単体とし ての可用性 サービス単体とし ての可用性
  15. 15. DB AP Web 疎結合なサービス間で 起きる問題に対策する 疎結合なサービス間で 起きる問題に対策する疎結合なサービス間で 起きる問題に対策する 疎結合なサービス間で 起きる問題に対策する
  16. 16. サービス境界で起きる障害の例 • 例)サービス障害の連鎖 • シナリオ 1. サービスAから依存されるサービスBで障害が発生 2. サービスAでサービスBの応答待ちのスレッドが累積 3. スレッドが枯渇し、サービスAがリクエストに応答できない状態に(障害連 鎖) 4. サービスBへのアクセス集中が解消しないため、サービスBが復旧困難な状況 が継続 • 対策の例 • ヘルスチェック • サーキットブレーカー
  17. 17. ヘルスチェックとサーキットブレーカー • サーキットブレーカー • リクエストに対する応答状態が一定 の条件を満たした場合に、障害が発 生したものとみなして、そのサービ スへのリクエストを遮断する機構 • ヘルスチェック • サービスの稼動状態を他サービスか ら確認するためのインターフェース • ヘルスチェック応答の結果を見て サーキットブレーカーを開くなどの 判定をおこなう http://nununu.hatenablog.jp/entry/2016/09/22/220000
  18. 18. 境界に適用する障害対策の例 • その他の例(代表的なもの) • バルクヘッドパターン • 補正トランザクションパターン • 参考資料 • Building Fault Tolerant Microservices: • https://www.youtube.com/watch?v=pKO33eMwXRs • Azureアーキテクチャセンター > クラウドの設計パターン > 回復性の パターン: • https://docs.microsoft.com/ja- jp/azure/architecture/patterns/category/resiliency
  19. 19. サービス・メッシュを使ったサービス 境界の障害対策 • サービス・メッシュを利用するとサービス境界の障害対策を簡 単に導入できる • Kubernetes + Istio/Linkerd • 次回詳しくやります(ハンズオンも作る予定) Istio provides a simple Domain-specific language (DSL)…. The DSL allows the operator to configure service-level properties such as circuit breakers, timeouts, retries, as well as set up common continuous deployment tasks such as canary rollouts, A/B testing, staged rollouts with %-based traffic splits, etc. “ ”
  20. 20. 各サービスの可用性にフォーカスする • 小規模な分だけやりやすくなっているはず • 従来型の障害対策を実装する • SPOFがないか • 障害時の回復性が十分か • Kubernetesの機能をうまく利用する • スケールアウト型/分散型アーキテクチャのMWを積極利用 • Podのスケーリングを活用して可用性構成を容易に実装
  21. 21. Web3層アーキテクチャの場合の例 • セッションステートの分離 • セッションを分離する。Redisクラスターにセッションを格納 • アプリケーション層をスケールアウト可能。B/GデプロイメントもOK • DBの可用性構成 • 例えばMySQLのマスター/スレーブ(リードレプリカ)構成 • https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful- application/
  22. 22. Web3層アーキテクチャの場合の例 • Kubernetesクラスター上の配置 APP APP APP APP セッションステートを アプリから分離 Redisなどで可用性を確保 R/W R R R マスター/スレーブ型の クラスタを構成 (StatefulSetを活用) 水平スケール
  23. 23. StatefulSet • Podに連番の名前が与えられる • 永続領域、ネットワーク上の名前がPodに紐付けて管理される • 障害復旧時、永続領域とネットワークの構成を保持したまま復 旧する
  24. 24. SMKACKスタックの場合 • SMACK • Spark • Mesos • (ここではk8s) • Akka • Cassandra • Kafka • 水平分散型アーキ テクチャが基本 https://mesosphere.com/blog/smack-stack-new-lamp-stack/
  25. 25. SMKACKスタックの場合 • Kafkaクラスターの例 お互いのパーティションの レプリカを持ち合うことで、対 障害性を確保 Kafka Broker Producer Consumer
  26. 26. SMKACKスタックの場合 • Kafkaクラスターの例 Kafka Broker Producer Consumer クラスターノードが落ちたら 別ノードがパーティションを受 け持つ
  27. 27. SMKACKスタックの場合 • Kafkaのクラスターの例 Kubernetesの機能により、自動的 に再起動 永続層やネットワーク構成を維持 したまま復帰する(StatefulSet) Kafka Broker Producer Consumer パーティションの配分を 自律的に再調整
  28. 28. カオステストも検討する • 意図的に障害を起こして、システムの耐障害性や、運用の対応 などをテストする • 障害が発生する前提で設計/実装/運用することを定着させる • (当たり前ですが)障害に強いシステムにつながる • Chaos Monkey • chaoskube(ランダムにPodをおとすツール)
  29. 29. ハンズオン (1) KubernetesにKafkaクラスターをデプロイしてみよう
  30. 30. ハンズオンチュートリアルはこちら •http://bit.ly/cndjp3-handson1
  31. 31. 3. リリースの安定はサービスの安定 アプリケーション・プラットフォーム層と可用性
  32. 32. なぜリリースと可用性が関係するか • リリース→可用性に対するリスク • リリースは本番環境に変更を加えること • 変更は障害のリスク • MSAは頻繁にリリースされる • よいリリース • リリースするものがバグを含まない=十分なテスト • lint、 単体テスト、結合テスト、e2e • ステージング(負荷、カオステストを含む)、カナリー • テスト、リリース作業でミスをしない=自動化 • デプロイメント・パイプライン
  33. 33. デプロイメント・パイプラインと ソースコードツリー https://www.slideshare.net/Robert_McDermott/anatomy-of-a-continuous-integration-and-delivery-cicd-pipeline
  34. 34. デプロイメント・パイプラインの定義
  35. 35. Istioを使ったカナリーデプロイメント • Istioを使うとリクエストの 流量を細かく設定可能 • カナリーのコンテナを増やさ ずに、流量だけを徐々に増や すなど apiVersion: config.istio.io/v1alpha2 kind: RouteRule metadata: name: reviews-v2-rollout spec: destination: name: reviews route: - labels: version: v2 weight: 25 - labels: version: v1 weight: 75
  36. 36. 4. インフラ選定はクラウドで Kubernetes層、ハードウェア層と可用性
  37. 37. Kubernetesの可用性構成 • マスターノードの冗長構成 を取ることで、 コントロールプレーンをす べて冗長化 • etcdのクラスタリング • apiserverのクラスタリング • … • 公式ドキュメントに可用性 構成の構築手順がある https://kubernetes.io/docs/admin/high-availability/
  38. 38. 可用性構成の構成ガイド etcdのクラスタリングガイド 自分で組むのはやめた方がいい (と思う)
  39. 39. Multi Zone構成 • 主要クラウドベンダーが提供するマネージドKubernetesサービ スは、Multi Master構成をサポート • Azure Container Service • Google Kubernetes Engine • OpenShift Online • Zoneにまたがってマスター/ワーカーノードを配置してくれる ものも • Google Kubernetes Engine • OpenShift Online(たぶん) (プレビュー段階のサービスは載せてません) ※AWSとOracleもマネージドk8sサービスをリリース予定です
  40. 40. 障害時を忘れずにサイジング • Kafkaなどノード障害後にデータリバランスを行う場合は、そ のときの負荷を考慮したサイジングが必要 • CPUリソース • ネットワーク帯域 • ストレージ速度 • 障害復旧時間に影響するケースもある • クラウドサービスでは、性能が不安定なケースもあるので注意
  41. 41. ハンズオン (2) 負荷テスト/カオステスト
  42. 42. 次回予告
  43. 43. 次回予告 • 「Kubernetes Network Deep Dive!」 • コンテンツ • 今回取り上げられなかった、k8sネットワーク周りを深掘り • サービス・メッシュでk8s上にインテリジェントなネットワークを構成 • 開発プロセスでの活用 • CI/CDとの組み合わせ。カナリーデプロイメント • サービス境界の障害ポイントへの対策
  44. 44. お知らせ • Slackチャネルにぜひご参加ください http://bit.ly/cndjp-slack-invite
  45. 45. お疲れ様でした! #cndjp3

×