Kubernetes × 可用性 -- cndjp第3回勉強会
•Download as PPTX, PDF•
9 likes•3,959 views
Cloud Native Developers JP(cndjp)第3回勉強会の発表資料です。 今回のテーマはKubernetes × 可用性
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Kubernetes × 可用性 -- cndjp第3回勉強会
Similar to Kubernetes × 可用性 -- cndjp第3回勉強会 (20)
More from Hiroshi Hayakawa
Kubernetes × 可用性 -- cndjp第3回勉強会
- 1. #cndjp3
- 3. 自己紹介 • 早川 博（はやかわ ひろし） • 日本オラクル所属 • Pre-Sales Engineer / Tech Evangelist • Java SE/EE, Microservices/DevOps @hhiroshell
- 4. Kubernetes×可用性 4箇条 • レイヤー分けして考えろ • マイクロサービス・アーキテクチャとKubernetesは好相性 • リリースの安定はサービスの安定 • インフラ選定はクラウドで決まり
- 11. マイクロサービス・アーキテクチャ • 大規模なシステムを小規模なサービスの組み合わせで実現する アーキテクチャ • 複数のサービス群をHTTP(s)、RPC、非同期メッセージング等 により疎結合に連携 • 変更の影響範囲をサービスに留めることで、頻繁なアップデー トを実現する
- 13. MSA on k8sで可用性を考えるときのポイント • 各サービス単体としての可用性にフォーカスする • 小規模な分だけやりやすい • 例えば古典的な3層アプリの構成なら、従来と同じプラクティスが使え る • Kubernetesの機能をうまく活用する • サービス境界（サービス同士の連携箇所）に対策を施す • MSAならではの考慮点 • Kubernetes + サービスメッシュをうまく活用する
- 15. DB AP Web 疎結合なサービス間で 起きる問題に対策する 疎結合なサービス間で 起きる問題に対策する疎結合なサービス間で 起きる問題に対策する 疎結合なサービス間で 起きる問題に対策する
- 16. サービス境界で起きる障害の例 • 例）サービス障害の連鎖 • シナリオ 1. サービスAから依存されるサービスBで障害が発生 2. サービスAでサービスBの応答待ちのスレッドが累積 3. スレッドが枯渇し、サービスAがリクエストに応答できない状態に（障害連 鎖） 4. サービスBへのアクセス集中が解消しないため、サービスBが復旧困難な状況 が継続 • 対策の例 • ヘルスチェック • サーキットブレーカー
- 17. ヘルスチェックとサーキットブレーカー • サーキットブレーカー • リクエストに対する応答状態が一定 の条件を満たした場合に、障害が発 生したものとみなして、そのサービ スへのリクエストを遮断する機構 • ヘルスチェック • サービスの稼動状態を他サービスか ら確認するためのインターフェース • ヘルスチェック応答の結果を見て サーキットブレーカーを開くなどの 判定をおこなう http://nununu.hatenablog.jp/entry/2016/09/22/220000
- 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. サービス・メッシュを使ったサービス 境界の障害対策 • サービス・メッシュを利用するとサービス境界の障害対策を簡 単に導入できる • 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. 各サービスの可用性にフォーカスする • 小規模な分だけやりやすくなっているはず • 従来型の障害対策を実装する • SPOFがないか • 障害時の回復性が十分か • Kubernetesの機能をうまく利用する • スケールアウト型／分散型アーキテクチャのMWを積極利用 • Podのスケーリングを活用して可用性構成を容易に実装
- 21. Web3層アーキテクチャの場合の例 • セッションステートの分離 • セッションを分離する。Redisクラスターにセッションを格納 • アプリケーション層をスケールアウト可能。B/GデプロイメントもOK • DBの可用性構成 • 例えばMySQLのマスター／スレーブ（リードレプリカ）構成 • https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful- application/
- 22. Web3層アーキテクチャの場合の例 • Kubernetesクラスター上の配置 APP APP APP APP セッションステートを アプリから分離 Redisなどで可用性を確保 R/W R R R マスター／スレーブ型の クラスタを構成 （StatefulSetを活用) 水平スケール
- 23. StatefulSet • Podに連番の名前が与えられる • 永続領域、ネットワーク上の名前がPodに紐付けて管理される • 障害復旧時、永続領域とネットワークの構成を保持したまま復 旧する
- 24. SMKACKスタックの場合 • SMACK • Spark • Mesos • （ここではk8s） • Akka • Cassandra • Kafka • 水平分散型アーキ テクチャが基本 https://mesosphere.com/blog/smack-stack-new-lamp-stack/
- 28. カオステストも検討する • 意図的に障害を起こして、システムの耐障害性や、運用の対応 などをテストする • 障害が発生する前提で設計／実装／運用することを定着させる • （当たり前ですが）障害に強いシステムにつながる • Chaos Monkey • chaoskube（ランダムにPodをおとすツール）
- 32. なぜリリースと可用性が関係するか • リリース→可用性に対するリスク • リリースは本番環境に変更を加えること • 変更は障害のリスク • MSAは頻繁にリリースされる • よいリリース • リリースするものがバグを含まない＝十分なテスト • lint、 単体テスト、結合テスト、e2e • ステージング（負荷、カオステストを含む）、カナリー • テスト、リリース作業でミスをしない＝自動化 • デプロイメント・パイプライン
- 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
- 37. Kubernetesの可用性構成 • マスターノードの冗長構成 を取ることで、 コントロールプレーンをす べて冗長化 • etcdのクラスタリング • apiserverのクラスタリング • … • 公式ドキュメントに可用性 構成の構築手順がある https://kubernetes.io/docs/admin/high-availability/
- 39. Multi Zone構成 • 主要クラウドベンダーが提供するマネージドKubernetesサービ スは、Multi Master構成をサポート • Azure Container Service • Google Kubernetes Engine • OpenShift Online • Zoneにまたがってマスター／ワーカーノードを配置してくれる ものも • Google Kubernetes Engine • OpenShift Online（たぶん） （プレビュー段階のサービスは載せてません） ※AWSとOracleもマネージドk8sサービスをリリース予定です
- 40. 障害時を忘れずにサイジング • Kafkaなどノード障害後にデータリバランスを行う場合は、そ のときの負荷を考慮したサイジングが必要 • CPUリソース • ネットワーク帯域 • ストレージ速度 • 障害復旧時間に影響するケースもある • クラウドサービスでは、性能が不安定なケースもあるので注意
- 42. 次回予告
- 43. 次回予告 • 「Kubernetes Network Deep Dive!」 • コンテンツ • 今回取り上げられなかった、k8sネットワーク周りを深掘り • サービス・メッシュでk8s上にインテリジェントなネットワークを構成 • 開発プロセスでの活用 • CI/CDとの組み合わせ。カナリーデプロイメント • サービス境界の障害ポイントへの対策
- 45. お疲れ様でした！ #cndjp3