k8sで画像PFを1年半運用してみた振り返り #yjbonfire

k8sで画像PFを1年半 運⽤してみた振り返り 2019年12⽉3⽇ ヤフー株式会社 ⼭⽥ 拓也 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

⾃⼰紹介 山田 拓也 (やまだ たくや) ヤフー株式会社 / 画像配信プラットフォーム 担当 @tak_ymd • 経歴 • Kubernetes経験 : 1年半くらい • その他 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. : 営業 -> Web系 -> インフラ保守 -> 今 : 3歳の娘がいてかわいい 2

テーマ • 画像PFのシステムリプレイスで Kubernetesに移⾏してから1年半 • ここまでで経験した成功、失敗談やノ ウハウを少々 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 3

結論 移⾏してよかった。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 4

注意事項 あくまで社内のマネージドKubernetesを利⽤した経験 談です • • コントロールプレーンの運⽤はしてないです すべてにおいて、実際に試してみることをおすすめしま す • • もしかしたら間違ってるかも。。。 • 軽めの話題なので気軽に聞き流してください • ⼈⽣初登壇です。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 5

まずは Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

移⾏に⾄るまでの経緯 古いシステム 新しいシステム • 社内VMで構築 • ⼀部オンプレ環境あり • リカバリは⼿動 • 秘伝のコード、⼝伝の構成… ？ • HVの障害でVMが⽌まると 夜でも起こされる Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 7

移⾏に⾄るまでの経緯 • リプレイスすることは決まってた • アプリケーション側は開発が始 まっていた • インフラ選定どうしようか・・・ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 8

移⾏に⾄るまでの経緯 • 社内イベントでKubernetesを知る • Cloud Native︖ • From pets to cattle…︕︖ • デプロイしたサーバーをメンテしない︕ • とにかくもうインフラに振り回されたくない︕ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 9

移⾏に⾄るまでの経緯 古いシステム 新しいシステム • 社内VMで構築 • Kubernetesで︕ • ⼀部オンプレ環境あり • CDN,NAT等は社内PFで • リカバリは⼿動 • 秘伝のコード、⼝伝の構成… • HVの障害でVMが⽌まると 夜でも起こされる Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. • 基本的に⾃動復旧を⽬指す • Infrastructure as Code • 夜は寝る︕ 10

からの… そうは問屋がおろさない Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 11

失敗体験 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

移⾏前のシステムを意識 してしまった① 構築編 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

移⾏前の構成をマネして持ってきた • まずどうやって構成考えたらいいの︖ • とりあえず移⾏前のサーバー構成を参 考にした • ⼀応、もともと1コンポーネントで やってたモノリシックな部分をマイク ロサービスっぽく分割 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 14

分割してみた 分割後の構成(例) 鍵更新サーバ LB キャッシュサーバ 画像ストレージ URL復号App 画像変換App 例です。実際の構成とは異なります。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 15

Podとコンテナの配置︖ • どんな⾵にPodとコンテナを配置すれ ばいいの︖ • もともと1コンポーネントだった Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 16

Podとコンテナの配置︖ • とりあえず全部まとめた Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 17

配置してみた こう？ Pod LB Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 鍵更新サーバ キャッシュサーバ URL復号App 画像変換App 画像ストレージ 18

動くけど • コレジャナイ感 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 19

問題だらけ • • • • • • Podの役割が多すぎる コンテナ多すぎで起動が遅い ヘルスチェックが複雑化 (回復⼒に影響) Yamlが肥⼤化、編集も管理も⼤変 Etc… できるだけ管理しやすい単位にまとめる べき Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 20

なおした たぶんこう Pod Pod Pod LB 画像ストレージ キャッシュサーバ URL復号App 鍵更新サーバ 画像変換App 例です。実際の構成とは異なります。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 21

反省① • 各コンテナはシンプルな機能に留める • PodはKubernetesの最⼩デプロイ単位 • 協調して稼働させる必要があるもののみ ⼀つのPodにまとめる • 迷うなら1コンテナ/1podもアリ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 22

移⾏前のシステムを意識 してしまった② 監視編 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

移⾏前の監視をマネして持ってきた • 新しいシステム、環境で⼀体なにをど うやって監視すればいいのか • Prometheusって何︖ • 移⾏前のシステムが参考になるかな︖ • とりあえず・・・ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 24

監視ルールを⼭程作った • 前のシステムでやってた監視項⽬を 洗い出して • Grafanaのダッシュボードテンプレを 参考に⼤量のprometheus監視ルール を⽣成 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 25

監視ルールを⼭程作った Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 26

監視ルールを⼭程作った Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 27

監視ルールを⼭程作った • まあPromQLの勉強にはなった • ただ、これならGrafanaでも監視できる (4.0以降) • 監視項⽬多すぎてアラートめっちゃくる • 結局、夜も起こされる⽇々 • そのアラートは本当に必要か︖ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 28

監視ルールを⼭程作った • そのアラートは本当に必要か︖ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 29

監視について • ⼤事なのは作ったシステムが「問題な く」仕事をしているか • 「問題」に気づかせてくれることが⼤事 • 別にツールにこだわる必要はない • E2Eを監視するだけでも問題に気づくことは できる • 監視は⽬的をはっきりさせる Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 30

監視の⽬的を⾒失わない • 例えば「Swap Out」の検知は本当に 必要︖ • • • • 低速なDiskのI/Oによる影響は⼼配 アプリケーションの応答速度が気になる 応答速度に問題がなければアラート不要 本質的にはLatency監視で事⾜りる︖ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 31

閾値が重要なんじゃない • よくある閾値ベースの監視 CPU、メモリ、NWトラフィックetc… • その閾値は誰がどういう意図で決めた︖ • 説明できないなら⾒直す必要あり Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 32

閾値が重要なんじゃない • 例えばリソース消費率って本当に⼤事︖ • • • Podのリソースをフルに使い切って何が悪い 特にKubernetesにおいてPod単位のリソース消費は そこまで重要ではない可能性がある Eviction Manager超優秀 • リソース使いすぎな⼦はこの⼈がなんとかしてくれ る。 (空いてるNodeに配置転換とか) Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 33

Kubernetesの監視はどうか︖ とはいえ、物理サーバーやIaas上のVMだとそうはいか ない • • • メンテナンスの必要があるので軽微な変化も⾒逃せなかっ たりする 特に物理。蓄積されたダメージが突然発⽕する でもKubernetesなら結構いい感じにやってくれる • • • • そもそも⾼い⾃⼰修復⼒を持っている アラートを出す前に⾃⼰修復を試みる やりたい監視を実現できるチャンスがある︕︕ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 34

Prometheusはどうか︖ • ツールにこだわる必要はないけれど… • (個⼈的に)理想に近い監視ができるイメージ • ⼤量のメトリクスで常に細かくデータを収集し てるので「後からでも」なんとかなる • Promqlも少し覚えればやりたいことができてく る • 学習コストに⾒合ったリターンはあると感じた • 例えばどういう監視ができるか︖ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 35

予測的に監視する • 例えばリソース監視 • 本質的には「今○％」より「△時間以内に100％」が重 要ではないか︖ • • Disk使⽤量みたいに消費ペースが重要なものは予測的に監 視するべき 「 predict_linear() 」を使う • • Range vectorから単純な線形回帰を利⽤して任意の時間後の値 を予測する ただしメトリクスタイプ「Guage」のみ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 36

予測的に監視する
- alert: 12時間以内にNodeのDiskがなくなるかも
expr:
predict_linear(node_filesystem_avail_bytes{device=~"^/dev/.*$"}[1h],
12 * 3600) <= 0

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

37

変化率を重視する • リクエスト数とかNetworkTrafficとか • 何Byte受けたらアラートって根拠がわかりにくい • リクエストのスパイクを検知したほうが良さそう • delta()とか使えばできそう • • • • Range vectorの最初と最後の値の差分を出してくれる これもGuageのみ http_requests_totalはCounterなので注意 いい案があれば誰か教えて…︕ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 38

Alertmanagerも便利 • かなり細かく通知の設定ができる • • • 似たようなアラートは通知しない instanceやseverityによってreceiverを変える などなど • 本当に⼤事なものだけ通知させられる • Silenceも便利 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 39

反省② • まずは何をしたくて監視するのか明確にする • 基本的に「アラートを鳴らさない」⼯夫をす る • ⾃⼰修復を試みる • Kubernetes、というかそもそも環境やアプリ ケーションに合わせた監視をする • Prometheusは後からでも結構なんとかなる Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 40

独⾃ツールを運⽤に 持ち込んだ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

独⾃ツールを運⽤に持ち込んだ • テンプレートから各環境にデプロイする Yaml⽣成ツールを⾃作した • 運⽤が回らなくなるレベルで⼤変 • ツールのメンテナンスまでやってられない • 使い⽅がわからず属⼈化しまくる • Yaml管理担当なんてだれがやりたい︖ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 42

反省③ • ⼀般的なツールを使おう • Kustomize、Helmなど • Secret以外は⽣成結果をGit管理しておく ことをオススメ • もしくは`apply diff`で差分をちゃんと 確認する Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 43

成功体験 というかやってよかったこと Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

⾼負荷環境での運⽤テストをやった • 実際の運⽤をシミュレーションして メンテナンスしてみる • No ApacheBench • 実際の運⽤に近いテスト計画作成と ⼤量のリクエストを複製できるツールが オススメ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 45

⾼負荷環境での運⽤テストをやった • やってみると結構なリクエストがエラーで落 ちる • ⾜りない設定が⾒つかる • PodDisruptionBudget • SIGTERMのハンドリング • 危険なメンテナンスがわかる • Ingressのルーティング変更とかは⾮常に低い 割合で502エラーが発⽣した Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 46

備考︓Node,Podを安全に終了させる SIGTERMのハンドリング • • • termination lifecycle GracePeriodSeconds内にコンテナを安全に落とす コンテナ単位のGraceful Shutdown • • JavaとかGraceやりにくい⾔語はSideCarでProxyサーバー⽴ててそっ ちでやってもいいかも PDBを設定する • • • Nodeを安全に停⽌するため Podの稼働状況をみながらkubectl drainを待機させる Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 47

1コンテナ1プロセスを意識した • コンテナの基本︖ • Kubernetesに管理させることで 運⽤状態の把握が楽になった • Node.js等のマルチプロセス化はちょっと厄介 • • • • clusterモジュールでプロセスをForkできるけど… ⼦プロセスのダウンをアプリケーション側で管理する必要 がある 1コンテナで複数プロセスを使⽤するときのNodeへの影響 を把握しきれなかった 迷ったらシンプルな⽅がいい Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 48

システムリプレイスだった • Kubenetesに合わせたシステム開発が できたのは幸運 • 旧システムごと移植するとなると厳し かった • P2Vみたいな単純な移⾏ではない Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 49

とりあえず使ってみた • 意外となんとかなる (と思う) • 何も知らない状態で始めたけど、調べながら リリースまでこぎつけた • 情報量は少ないようで多い • • • • アップデート多くて情報追いかけるのも⼤変 ネガティブなニュースも多い 使わずに情報だけを集めると億劫になるかも 批判だけして使わないのはもったいない Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 50

最初からベストなやり⽅を求めなかった • ⾃作ツールで⾯倒な運⽤をやっていた ⽇々も今となってはいい経験 • 失敗は成功のもと • 時間をかけるなら「後からどうにかで きる」状態にしておく Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 51

Kubernetesが楽しかった • 特に何も⼯夫していない状態でも便利 • ⽴ててしまえばオンプレ環境や VMよりも(気持ちが)楽 • どんどん便利にしたくなる • (僕でさえ) 学習意欲が湧く︕ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 52

たぶんここまで Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

もし時間があったら Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

KeepAlive切断事件 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

Keep Aliveが切断されてしまう︕ • Ingress直下に配置したPodのキャッシュ ⽤コンテナで60秒程度のKeep Aliveを設 定 • にもかかわらず数秒で接続元からKeep Aliveが切断されてしまう • Keep Aliveを無効にすると10msくらいパ フォーマンスが落ちる… Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 56

Keep Aliveが切断されてしまう︕ ここ Pod Ingress-lb キャッシュサーバ 例です。実際の構成とは異なります。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 57

Keep Aliveが切断されてしまう︕ • nghttpx-ingress-controllerの `backend-keep-alive-timeout`の設 定による • 切断されること⾃体は問題ではない • ログが⼤量に吐かれる場合はログレベ ルを調整する Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 58

メモリ解放されない事件 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

メモリが常に限界 • container_memory_usage_bytesを 監視していた (Grafanaからコピって きた) • アラートがバンバンなる︕ • メモリが右肩上がりで開放されない Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 60

図 • 右肩上がり Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 61

なぜか • container_memory_usage_bytes • キャッシュを含む全てのメモリ使⽤量 を対象にしている。 • 稼働時間に(ほぼ)⽐例してキャッシュ が蓄積されていく Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 62

メモリ使⽤状況の内訳 • Workingsetが減ってないのでプロセスのメモリ管理に問題があるっぽい • とはいえキャッシュを除くとほんのり余裕がある Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 63

メモリはなかなか開放されない • コンテナのリソース≒配置されたNode︖ • • • コンテナにログインしてリソース確認する とNodeのリソース量と同じ コンテナに対してはKubernetes上からリ ソースの制限をかけている︖ メモリにresouces.limitsを設定すると 閾値周辺でメモリ解放が⾛っているような Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 64

確認するべきなのは • container_memory_working_set_bytes • コンテナのワーキングセット使⽤量 • KubernetesのOOM Killerもこれを監視︖ • やたらPodのリスタートがかかる場合はここ がメモリ制限を超えている可能性あり • メモリのlimitsやrequestを⾒直す Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 65

Request/Limitを設定する • コンテナのリソース設定 • Requestで設定した分、そのコンテナ⽤にNode のリソースが確保される • 設定しなくても動くには動くが… • １つのPodが際限なくNodeのリソースを消費す る • Pod同⼠がリソースを奪い合う • 計画的なPodの配置に⽀障がでる • container_memory_~等の値が取れない Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 66

Resouce Limitを設定しないと • こうなる Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 67

Request/Limitを設定しよう • MemoryはLimitつけるべき • CPUはRequestだけでもいいかも Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 68

さらに時間があったら Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

Prometheusの基礎 データモデルについて • • • すべてのデータを時系列として保存 メトリクス名とラベル(キーバリューペア) ４種類のメトリクスタイプについて • • • • • Guage : 減ったり増えたりする値。温度計とか Counter : リセットしない限り積み重ねる値。ガスメーターとか Histgram : 予め設定したバケットに累積的にカウントする。難しい Summary: Histgramに似ている認識。詳しくは公式を。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 70

httpリクエストを取得する例 • HTTPリクエスト数を取得する例 rate( http_requests_total{status=~”2.."}[3m]) 12 @1574089523.732 12 @1574089583.732 13 @1574089643.732 • 5分間のRange Vectorの数値変化の平 均で「だいたいの」リクエスト数を取 得している Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 71

LivenessProbe / ReadinessProbe • らいぶねす、れでぃねす • これがちゃんと設計・設定できるかで 回復⼒が段違い • 疎結合になっているほど効果を発揮す る • Podの起動時間に影響する Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 72

HPAの注意点 すぐにはスケールされない • • • デフォルト30秒に1回のチェック --horizontal-pod-autoscaler-sync-period スケールイン/アウト後にはしばらく待機時間がある※ • • • スケールアウト: 最後の3分間にリスケーリングがなければ発⽣ スケールイン: 最後のリスケーリングから5分間待機 実際のサービスインにはHealcheckも影響 • • • initialDelaySeconds periodSeconds ※kubernetes/community Horizontal Pod Autoscalingより 原文ではScale-up、 Scale-downと記載されています。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 73

コンテナの軽量化 RUNをチェーンさせる • • 分けるとその分ステージが増えるのでレイヤを結合する ADD, COPYに注意 • • COPYのほうがシンプルな機能。ADDはtarの展開とかで使う。 不要なデータを消す • • Yumのキャッシュとかアーカイブファイルとか マルチステージビルド • • Docker17.05以上で。 ビルドするディレクトリを分ける • • Dockerfileのあるディレクトリをビルドの対象にしてしまうので Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 74

おすすめのツール Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

Kustomize • YAML管理ツール • 環境ごとの設定は差分のYAMLだけ書く • ConfigMap generationでイミュータブル なConfigmapを⽣成 • いずれkubectlに統合される • されました https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 76

• https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/

K9S • グラフィカルなCUIでkubectlみたいな操作ができる。 • 専⽤のシェルが起動するのでなんか安⼼。 • ClusterとかNamespaceとかも表⽰されてる • podのリソース消費がリアルタイムで⾒れる • Yamlの表⽰、編集、Podのログ表⽰、Describe、コンテナへのSSH… • 危ない操作(podのDelete)は⼀応Confirmがついてる • Vimライクなキーバインドが使える(︕) • これは便利︕ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 77

promtool • Prometheus のユーティリティコマンド • promtool test でPromehteus Ruleの Unitテストができる • Prometheusはメトリクス名がいつのまに か変わったりするのでこれでテストして おきたい Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 78

ご清聴 ありがとうございました Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.