マルチクラウド運用におけるKubernetes GKEとプライベートクラウドの特性を 活用した成功事例

Transcript

1. 1 マルチクラウド運⽤におけるKubernetes GKEとプライベートクラウドの特性を 活⽤した成功事例 柴⽥ 巧平 GMOペパボ株式会社 技術部プラットフォームグループ
2. 0.Introdctuion 2
3. Introduction 3 • 今Kubernetesを運⽤している⽅や設計している⽅に向 けて、マルチクラウド環境での設計、運⽤において⼯ 夫したことや知⾒をお伝えします • 何かしら業務に活かしていただけることがあったら嬉 しいです 伝えたいこと
4. Introduction 4 • SUZURIというサービスでは、プライベートクラウド上の Kubernetes環境(NKE)とGoogle Kubernetes Engine(GKE)を併 ⽤している。 • 普段はNKEでほぼリクエストを処理していて、セールなどでリ クエストが増えた場合はGKEにもオフロードすることで、コス トを抑えた上で⾼可⽤性を実現している。 • 運⽤を楽にするために⾃動化を積極的に取り⼊れている。 • 各クラウド環境の特性を理解しつつ構成の差を最低限にする。 認知負荷を⼩さくすることが肝要。 はじめにざっくり結論
5. 5 ⾃⼰紹介 技術部 プラットフォームグループ 2018年 中途⼊社 柴⽥ 巧平 Shibata Kohei • Platform Engineer + SRE • 2021年10⽉〜 SUZURI プラットフォームの 設計、運⽤ • 技術志向: Kubernetes / AWS • 𝕏(twitter) : @hokatabi
6. 6 アジェンダ 1. SUZURIとは 2. 構成をシンプルに、無駄をなくした話 3. リクエストの振り分け変更を⾃動化した話 4. マルチクラウド化の苦労話 4.1. TLS証明書取得仕様の差分 4.2. Redisをつくる 4.3. Ingress Controllerの仕様差分による障害 5. マルチクラウド化してよかったこと 6. まとめ
7. 1.SUZURIとは 7
8. SUZURIとは 8 • GMOペパボが提供しているプリントオンデマンドサービス • オリジナルグッズを作成‧販売‧購⼊できる(Tシャツ/スマホケース/⽇⽤品etc...) • 画像をアップロードし、それをTシャツなどに即合成して表⽰する   SUZURIとは
9. SUZURIとは 9 今回の主役、Lens/Lens2について • ユーザーの画像をTシャツなどに合成する際に使っている • S3から画像を取得、合成して返答する • Lensは2つのKubernetes環境をRoute53の重み付きラウンド ロビンでリクエストを振り分けている ◦ パブリッククラウドのGKE ◦ プライベートクラウドのNKE • LensはCoffeeScript製 • Rust製のLens2へ徐々に移⾏中 • Lens2はGKEだけで、NKEは使っていない
10. 2.構成をシンプルに、無駄を無くした話 10
11. 構成をシンプルに、無駄を無くした話 11 SUZURIのKubernetes(Lens/Lens2)環境
12. 構成をシンプルに、無駄を無くした話 12 SUZURIのKubernetes環境 Lens/Lens2で分かれ ているノードプール 余りがちなNKEのリ ソース
13. 構成をシンプルに、無駄を無くした話 13 シンプルに、効率よく、無駄をなくす GKEのノードプールを Lens/Lens2で統一 GKE/NKEでノードのリ ソースを統一 NKEのノードをスケー ルアウト NKEにリクエストを寄せ る
14. 構成をシンプルに、無駄を無くした話 14 • GKE/NKEで同じ値にする(CPU/メモリ) • アプリケーションごとの専⽤ノードは避ける ◦ そのためにはアプリが必要なリソースを計測することが必要 ◦ VPA(垂直オートスケール)を利⽤してPodのリソースを計測 • 環境の共通化による認知負荷の削減 ◦ 障害発⽣時やレイテンシの悪化などの解析の際変数が少なくてすむ ◦ 学習コストの低い環境にしよう ノードのリソースを統⼀する
15. 構成をシンプルに、無駄を無くした話 15 • クラウドには個性がある ◦ GKE…ノードのオートスケールが容易、コストは割と⾼い ◦ NKE…ノードのオートスケールはできない、コストが低い • 普段はNKEで、リクエスト数増加時はGKEを併⽤して ◦ コストを抑えつつ、突発的なリクエスト数の増加にも楽に対応できる ▪ コストを抑えつつ運⽤できているのは社の基盤チームのおかげ ◦ 普段はどの程度のリクエスト数なのかを計測しておく ◦ ⼀応GKEにも普段から少しだけリクエストは流しておく プライベートクラウドをメインで使う
16. 16 ところで…
17. 構成をシンプルに、無駄を無くした話 17 • マルチクラウドでのリクエスト数の振り分けはRoute53の重 み付きラウンドロビンで設定している 「急に」リクエスト数が増えたら？
18. 18 • 「普段はNKEで、セール時はGKEを併⽤して」 • 事前にアクセス数の増加がわかるならこれでも良いが • 突発的なアクセス増加でNKEで処理しきれなくなった ら、⼿動で設定変更が必要 • ⾃動でGKEにオフロードしてほしい 「急に」リクエスト数が増えたら？
19. 3.リクエストの振り分け変更を ⾃動化した話 19
20. リクエストの振り分け変更を⾃動化した話 20 Route53での重み付けを⾃動制御する ココを自動制御する！ 

21. リクエストの振り分け変更を⾃動化した話 21 AWSマネージドサービスをフル活⽤
22. リクエストの振り分け変更を⾃動化した話 22 • CloudFrontからキャッシュヒット率をCloudWatchに 送信 • CloudWatchでキャッシュミスの量(=Lensへのリクエス ト数)を集計し、Lambdaで取得、Route53のレコード を書き換え AWSマネージドサービスをフル活⽤
23. リクエストの振り分け変更を⾃動化した話 23 • ⾃動でクラウド間のリクエストの配分を調整してくれ るので、突発的なリクエスト数の増加に強くなった AWSマネージドサービスをフル活⽤
24. リクエストの振り分け変更を⾃動化した話 24 詳細は⾃社テックブログに書きました！ https://tech.pepabo.com/2022/08/04/auto-multicloud-routing/
25. 4.マルチクラウド化の苦労話 25
26. 26 ここまでの話はLens →ここからはLensから移⾏中の Lens2の話
27. マルチクラウド化の苦労話 27 Lens2はGKEだけで運⽤していた
28. マルチクラウド化の苦労話 28 Lens→Lens2へのトラフィック移⾏を⾒据え、マルチクラウド化する
29. マルチクラウド化の苦労話 29 • 前例踏襲ならかんたんにできるだろうという⽬論⾒ • この予想は半分当たり🙆、半分はずれる󰢄 Lensの前例を踏襲しマルチクラウド化する
30. マルチクラウド化の苦労話 30 • かんたんにできたこと • Route53を⽤いて重み付きラウンドロビンを使う仕 組み • NKE/GKEで同⼀のコンテナイメージを⽤いること Lensの前例を踏襲しマルチクラウド化する
31. マルチクラウド化の苦労話 31 • 解決に苦労したこと • アプリのレイヤーでは共通化できた反⾯、インフラ のレイヤーでは考えることが多くなった • GKE/NKEの差分を吸収する仕組みづくり Lensの前例を踏襲しマルチクラウド化する
32. マルチクラウド化の苦労話 32 1. TLS証明書取得仕様の差分 2. Redisの構築 3. Ingress Controllerの仕様差分 マルチクラウド化の苦労話
33. マルチクラウド化の苦労話 33 1. TLS証明書取得仕様の差分 2. Redisの構築 3. Ingress Controllerの仕様差分 マルチクラウド化の苦労話
34. マルチクラウド化の苦労話 - TLS証明書取得仕様の差分 34 • GKEではTLS証明書取得するためにGCPのManaged Certificateを使っている • ドメイン保有確認のためにAレコードを確認する仕様 • 普段はNKEを使う運⽤であるため、NKE側のIPアドレスを引いてしまう TLS証明書取得仕様の差分
35. マルチクラウド化の苦労話 - TLS証明書取得仕様の差分 35 • GKEのTLS証明書取得を Managed CertificateからNKEと 同じcert-managerに変更した • cert-managerはIAMのアクセス キーでRoute53にドメインを問 い合わせる • GKE/NKEで統⼀した構成になる ので認知負荷を下げる効果も TLS証明書取得仕様の差分
36. マルチクラウド化の苦労話 36 1. TLS証明書取得仕様の差分 2. Redisの構築 3. Ingress Controllerの仕様差分 マルチクラウド化の苦労話
37. マルチクラウド化の苦労話 - Redisの構築 37 • Lens2ではRedisを利⽤している • GKEではマネージドサービスであるMemorystore for Redisを使い、 Deploymentでアクセス先のターゲットを設定している • NKEにはマネージドなRedisはないのでアクセス⼿段の検討が必要 Redisの構築 - name: REDIS_URL value: redis://10.0.0.75:6379
38. マルチクラウド化の苦労話 - Redisの構築 38 Deploymentで設定してるアクセス先ターゲットは運⽤中変わらないことが条件 • GKEが使っているRedisにNKEからもアクセスする → 没 ◦ 基本的には同じネットワーク内からの利⽤を想定している • Redis Sentinel → 没 ◦ フェイルオーバーは即時だがVIPを切り替えることを求めると時間がかかる • Redis Cluster → 微妙 ◦ Lens2で改修が必要 → そこまでやる？ • どうしよう Redisをどう構成するか
39. マルチクラウド化の苦労話 - Redisの構築 39 基本に⽴ち返り、「何のためにRedisを使っているか」を調査する • 速度改善のためのデータの⼀時置き場 • セッションデータのような消えるとサービス影響のあるデータではない • データは永続化されていると嬉しい • 当然、可⽤性は担保していてほしい Lens2がRedisに求めているものは？
40. マルチクラウド化の苦労話 - Redisの構築 40 基本に⽴ち返り、「何のためにRedisを使っているか」を調査する • 速度改善のためのデータの⼀時置き場 • セッションデータのような消えるとサービス影響のあるデータではない • データは永続化されていると嬉しい • 当然、可⽤性は担保していてほしい Lens2がRedisに求めているものは？ 冗長化さえできていれば各Redisはレプリケーションされてなくていい
41. マルチクラウド化の苦労話 - Redisの構築 41 NKEではシンプルな構成に - name: REDIS_URL value: redis://redis-svc.redis.svc.cluster.local:6379 • StatefulSetが並列に並んでいるだけ • RedisのURLにServiceを指定する 必要な機能を満たしてさえいれば無理に GCPと同じ機能にしなくて良い (特にマネージドサービスを補う場合は)
42. マルチクラウド化の苦労話 42 1. TLS証明書取得仕様の差分 2. Redisの構築 3. Ingress Controllerの仕様差分 マルチクラウド化の苦労話
43. マルチクラウド化の苦労話 - Ingress Controllerの仕様差分 43 • GKE/NKEではIngressコントローラに差分がある ◦ GKE … GKE Ingress ◦ NKE… Ingress NGINX Controller • Ingress NGINX Controllerではデフォルトのアップロードサイズ制限があった • Ingressにアノテーションで設定を追加した 画像のアップロードができない！ annotations: cert-manager.io/issuer: lens2-letsencrypt + nginx.ingress.kubernetes.io/proxy-body-size: 8m
44. マルチクラウド化の苦労話 44 • マネージドな部分をどう補う設計するのか？が肝⼼ • マネージドな機能すべてを満たす必要はない • ただし、差分には障害が潜在化しやすい • ちょうど良いバランスを模索していきましょう マルチクラウド苦労話まとめ
45. 5.マルチクラウド化してよかったこと 45
46. マルチクラウド化してよかったこと 46 • GKEがあることでメンテナンスが楽 ◦ 特にKubernetesアップデート ◦ アップデート前にリクエストをすべて⽚⽅に寄せれ ばサービス影響がない マルチクラウド化してよかったこと
47. マルチクラウド化してよかったこと 47 • NKEメインにすることでコストが削減 ◦ GKEのコストが50%以下に削減された ◦ サービスのKPI達成に⼗分寄与するレベル マルチクラウド化してよかったこと
48. 6.まとめ 48
49. Introduction 49 • SUZURIでは、プライベートクラウド上のKubernetes環境 (NKE)とGoogle Kubernetes Engine(GKE)を併⽤している。 • 普段はNKEでほぼリクエストを処理していて、セールなどでリ クエストが増えた場合はGKEにもオフロードすることで、コス トを抑えた上で⾼可⽤性を実現している。 • 運⽤を楽にするために⾃動化を積極的に取り⼊れている。 • 各クラウド環境の特性を理解しつつ構成の差を最低限にする。 認知負荷を⼩さくすることが肝要。 • マネージドサービスすべてを再構成する必要はない。バランス が⼤事。 まとめ
50. 50 Thank you!