狠狠撸

Kubernetes × 可用性
高可用性のための設計と実装
#cndjp3

自己紹介
? 早川博（はやかわひろし）
? 日本オラクル所属
? Pre-Sales Engineer / Tech Evangelist
? Java SE/EE, Microservices/DevOps
@hhiroshell

Kubernetes×可用性 4箇条
? レイヤー分けして考えろ
? マイクロサービス?アーキテクチャとKubernetesは好相性
? リリースの安定はサービスの安定
? インフラ選定はクラウドで決まり

1. レイヤー分けして考えろ

Susan J. Fowlerの
「マイクロサービス?エコシステム」
マイクロサービス
通信
アプリケーション?プラットフォーム
ハードウェア
サービス間の通信
RPC、APIエンドポイント、
サービスディスカバリ、
サービスレジストリ…
マイクロサービス以外のツー
ルやサービス
CI/CD、ロギング、監視…
サービス本体

Kubernetesを含む場合の4層
マイクロサービス
通信
アプリケーション
?プラットフォーム
ハードウェアハードウェア
Kubernetes
マイクロ
サービス
k8sとの組み合わせで
高機能?高可用性を
実現していく領域

レイヤー毎に障害対策を考える
ハードウェア
Kubernetes
マイクロ
サービス
SPOFの除去
障害シナリオ
と対応計画リハーサル
それぞれの項目について優先度
を決めて処置を講じる

今日やりたいことやれること
マイクロサービス?アーキテクチャとKubernetesは好相性
リリースの安定はサービスの安定
インフラ選定はクラウドで決まり
ハードウェア
Kubernetes
マイクロ
サービス

2. マイクロサービス?アーキテクチャ
とKubernetesは好相性
サービスレイヤーの可用性

マイクロサービス?アーキテクチャ
? 大規模なシステムを小規模なサービスの組み合わせで実現する
アーキテクチャ
? 複数のサービス群をHTTP(s)、RPC、非同期メッセージング等
により疎結合に連携
? 変更の影響範囲をサービスに留めることで、頻繁なアップデー
トを実現する

参考）マイクロサービス?アーキテクチャの
トレードオフ
更新頻度
変更の影響範囲が把握しにくい
ため、頻繁に更新できない
影響範囲がサービスにとどまる
ため、高頻度で更新できる
耐障害性
障害の影響がシステム全体に及
びやすい
障害の影響範囲をサービスに留
めるように設計できる
特殊要件への対応
技術スタックを変えられないの
で、対応可能な要件に限界があ
る
要件に合わせて最適な技術を
サービスに採用することができ
る
パフォーマンス
通信のオーバーヘッドが無いた
め、従来通りのパフォーマンス
が出る
サービス間通信のオーバーヘッド
のため、パフォーマンスが落ちや
すい
データの一貫性
基本的にはデータベースがひと
つなので、データの一貫性を保
ち易い
サービスをまたぐトランザク
ションは実現困難
運用?管理性
管理対象が少ないための、運
用?管理が比較的シンプル
サービスが増える分だけ管理対
象が増加
必要なスキル従来のスキルで対処可能
非同期処理の取扱いが難しい。
障害時に原因箇所が見つけにく
い
Monolithic Microservices

MSA on k8sで可用性を考えるときのポイント
? 各サービス単体としての可用性にフォーカスする
? 小規模な分だけやりやすい
? 例えば古典的な3層アプリの構成なら、従来と同じプラクティスが使え
る
? Kubernetesの機能をうまく活用する
? サービス境界（サービス同士の連携箇所）に対策を施す
? MSAならではの考慮点
? Kubernetes + サービスメッシュをうまく活用する

DB
AP
Web
サービス単体とし
ての可用性
ての可用性
ての可用性
ての可用性
ての可用性

DB
AP
Web
疎結合なサービス間で
起きる問題に対策する
起きる問題に対策する疎結合なサービス間で

サービス境界で起きる障害の例
? 例）サービス障害の連鎖
? シナリオ
1. サービスAから依存されるサービスBで障害が発生
2. サービスAでサービスBの応答待ちのスレッドが累積
3. スレッドが枯渇し、サービスAがリクエストに応答できない状態に（障害連
鎖）
4. サービスBへのアクセス集中が解消しないため、サービスBが復旧困難な状況
が継続
? 対策の例
? ヘルスチェック
? サーキットブレーカー

ヘルスチェックとサーキットブレーカー
? サーキットブレーカー
? リクエストに対する応答状態が一定
の条件を満たした場合に、障害が発
生したものとみなして、そのサービ
スへのリクエストを遮断する機構
? ヘルスチェック
? サービスの稼動状態を他サービスか
ら確認するためのインターフェース
? ヘルスチェック応答の結果を見て
サーキットブレーカーを開くなどの
判定をおこなう
http://nununu.hatenablog.jp/entry/2016/09/22/220000

境界に適用する障害対策の例
? その他の例（代表的なもの）
? バルクヘッドパターン
? 補正トランザクションパターン
? 参考資料
? Building Fault Tolerant Microservices:
? https://www.youtube.com/watch?v=pKO33eMwXRs
? Azureアーキテクチャセンター > クラウドの設計パターン > 回復性の
パターン:
? https://docs.microsoft.com/ja-
jp/azure/architecture/patterns/category/resiliency

サービス?メッシュを使ったサービス
境界の障害対策
? サービス?メッシュを利用するとサービス境界の障害対策を簡
単に導入できる
? 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.
“
”

各サービスの可用性にフォーカスする
? 小規模な分だけやりやすくなっているはず
? 従来型の障害対策を実装する
? SPOFがないか
? 障害時の回復性が十分か
? Kubernetesの機能をうまく利用する
? スケールアウト型／分散型アーキテクチャのMWを積極利用
? Podのスケーリングを活用して可用性構成を容易に実装

Web3層アーキテクチャの場合の例
? セッションステートの分離
? セッションを分離する。Redisクラスターにセッションを格納
? アプリケーション層をスケールアウト可能。B/GデプロイメントもOK
? DBの可用性構成
? 例えばMySQLのマスター／スレーブ（リードレプリカ）構成
? https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-
application/

Web3層アーキテクチャの場合の例
? Kubernetesクラスター上の配置
APP
APP
APP
APP
セッションステートを
アプリから分離
Redisなどで可用性を確保
R/W
R R R
マスター／スレーブ型の
クラスタを構成
（StatefulSetを活用)
水平スケール

StatefulSet
? Podに連番の名前が与えられる
? 永続領域、ネットワーク上の名前がPodに紐付けて管理される
? 障害復旧時、永続領域とネットワークの構成を保持したまま復
旧する

SMKACKスタックの場合
? SMACK
? Spark
? Mesos
? （ここではk8s）
? Akka
? Cassandra
? Kafka
? 水平分散型アーキ
テクチャが基本
https://mesosphere.com/blog/smack-stack-new-lamp-stack/

? Kafkaクラスターの例
お互いのパーティションの
レプリカを持ち合うことで、対
障害性を確保
Kafka Broker
Producer
Consumer

? Kafkaクラスターの例
Kafka Broker
Producer
Consumer
クラスターノードが落ちたら
別ノードがパーティションを受
け持つ

? Kafkaのクラスターの例
Kubernetesの機能により、自動的
に再起動
永続層やネットワーク構成を維持
したまま復帰する(StatefulSet)
Kafka Broker
Producer
Consumer
パーティションの配分を
自律的に再調整

カオステストも検討する
? 意図的に障害を起こして、システムの耐障害性や、運用の対応
などをテストする
? 障害が発生する前提で設計／実装／運用することを定着させる
? （当たり前ですが）障害に強いシステムにつながる
? Chaos Monkey
? chaoskube（ランダムにPodをおとすツール）

ハンズオン (1)
KubernetesにKafkaクラスターをデプロイしてみよう

ハンズオンチュートリアルはこちら
?http://bit.ly/cndjp3-handson1

3. リリースの安定はサービスの安定
アプリケーション?プラットフォーム層と可用性

なぜリリースと可用性が関係するか
? リリース→可用性に対するリスク
? リリースは本番環境に変更を加えること
? 変更は障害のリスク
? MSAは頻繁にリリースされる
? よいリリース
? リリースするものがバグを含まない＝十分なテスト
? lint、単体テスト、結合テスト、e2e
? ステージング（負荷、カオステストを含む）、カナリー
? テスト、リリース作業でミスをしない＝自動化
? デプロイメント?パイプライン

デプロイメント?パイプラインと
ソースコードツリー
/Robert_McDermott/anatomy-of-a-continuous-integration-and-delivery-cicd-pipeline

デプロイメント?パイプラインの定义

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

4. インフラ選定はクラウドで
Kubernetes層、ハードウェア層と可用性

Kubernetesの可用性構成
? マスターノードの冗長構成
を取ることで、
コントロールプレーンをす
べて冗長化
? etcdのクラスタリング
? apiserverのクラスタリング
? …
? 公式ドキュメントに可用性
構成の構築手順がある
https://kubernetes.io/docs/admin/high-availability/

可用性構成の構成ガイド etcdのクラスタリングガイド
自分で組むのはやめた方がいい
（と思う）

Multi Zone構成
? 主要クラウドベンダーが提供するマネージドKubernetesサービ
スは、Multi Master構成をサポート
? Azure Container Service
? Google Kubernetes Engine
? OpenShift Online
? Zoneにまたがってマスター／ワーカーノードを配置してくれる
ものも
? Google Kubernetes Engine
? OpenShift Online（たぶん）
（プレビュー段階のサービスは載せてません）
※AWSとOracleもマネージドk8sサービスをリリース予定です

障害時を忘れずにサイジング
? Kafkaなどノード障害後にデータリバランスを行う場合は、そ
のときの負荷を考慮したサイジングが必要
? CPUリソース
? ネットワーク帯域
? ストレージ速度
? 障害復旧時間に影響するケースもある
? クラウドサービスでは、性能が不安定なケースもあるので注意

ハンズオン (2)
負荷テスト／カオステスト

次回予告
? 「Kubernetes Network Deep Dive!」
? コンテンツ
? 今回取り上げられなかった、k8sネットワーク周りを深掘り
? サービス?メッシュでk8s上にインテリジェントなネットワークを構成
? 開発プロセスでの活用
? CI/CDとの組み合わせ。カナリーデプロイメント
? サービス境界の障害ポイントへの対策

お知らせ
? Slackチャネルにぜひご参加ください
http://bit.ly/cndjp-slack-invite

お疲れ様でした！
#cndjp3

狠狠撸

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

More Related Content

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