k8s Operatorで運用負担減&ハイブリッドクラウドのコスト最適化をした話

GMOペパボが提供する多くのサービスはハイブリッドクラウドで動作しています。
プライベートクラウドは安価であるメリットがある一方でスケーリングに制約があり、それを補うためにパブリッククラウドへリクエストをオフロードする運用を行っていました。
これまで職人技で調整していたパブリッククラウドへのリクエストのオフロード操作をk8s operatorを開発し自動で行うようにしました。
この経験から得られたoperatorで運用自動化を行うメリットについて解説します。

Transcript

1. 1 k8s Operatorで運用負担減& ハイブリッドクラウドのコスト 最適化をした話 菅原 千晶 / GMO Pepabo, Inc. Cloud Native Days Tokyo 2022 (2022-11-21)
2. 2 自己紹介 菅原 千晶 / akichan GMOペパボ 技術部プラットフォームグループ シニアエンジニア/SRE • 2018年3月中途入社 • カラーミーショップへのk8s導入、GitOps推進 を経験 • 現在は minne に注力して活動 ◦ Argo Rollouts導入によるプログレッシブデ リバリーの実現 ◦ CDNコストの削減 ◦ RailsアプリのN+1改善 2 @ch1aki @ch11aki
3. 3 3 • minneのインフラ構成と運用課題 • k8s Operatorによる運用課題解決のメリッ ト 今日話すこと
4. 4 minneのインフラ構成 Section 1 4
5. 5 minne とは ハンドメイド作品をインターネット上で販売・購入できる、 国内最大級のハンドメイドマーケット • 作家・ブランド数: 80万件超 • 作品数: 1500万点超 • アプリDL数: 1300万件超 5
6. 6 インフラ構成 • それぞれの環境でk8sクラスタ を運用し、同じAPPが稼働 • AWS Direct Connectにより透 過的に相互利用可能 • ステートフルなコンポーネント （DB, Cache）はマネージド サービスを利用 • AWSだけでサービス継続可能な ように設計 6 AWSとプライベートクラウド（Nyah）のハイブリットクラウド self-hosted EKS App App AWS Nyah 専用線 接続 マネージド サービス
7. 7 長所: 安価 同程度のスペックのEC2 instance と比較して利用コストが数分の一 プライベートクラウド（Nyah） インフラ構成 7 短所: スケーラビリティに制約 ある程度の余剰はあるがパブリッ ククラウドには劣る
8. 8 • プライベートクラウド障害への対策 • プライベートクラウドのコストメリットを享受しつつ、マネージドサービ スによる運用負荷軽減 • プライベートクラウド内の余剰リソースでは間に合わないような急激なリ クエスト増加への対策 ◦ Route53の加重レコードでそれぞれの環境へのトラフィックを制御 ◦ プライベートクラウドで足りないときは、AWSの加重を増やす ハイブリッドクラウドでk8sを利用している理由 インフラ構成 8
9. 9 Section2 運用上の課題 9
10. 10 AWSへのリクエストオフロードの調整が人力 運用課題 キャンペーンやTV放映があるたび に次を実施 1. 予想されるリクエスト量を 導き出す 2. 過去の実績と照らし合わせ リクエストオフロード判断 3. 加重調整 4. リクエストが落ち着いたら 加重設定を戻す 10 ピーク時に Nyah側が許容 リクエスト数 以下になるよ うに
11. 11 AWSへのリクエストオフロードの調整が人力なことによる問題 運用課題 • 専門性が高く運用がスケールしない • 無駄にAWSリソースを利用している ◦ 実際より需要を多く見積もってしまっている場合 ◦ 翌日や休み明けに加重設定を戻すまでの期間 • 需要を誤って少なく見積もってしまうと、リソースが足りず正常にリクエ ストを処理できなくなりサービス障害になる 11
12. 12 理想: 自動でリクエスト数に応じた最適な加重が設定される 先行事例 : 「アクセス数に連動してDNSの重み付けを自動制御する仕 組みをAWSで作った話」※ • 弊社SUZURI事業部でLambda/CloudWatch等を用いた例 • 同じようなハイブリッドクラウド構成の他事業部で、個々にこれら の仕組みを運用していくのは非効率になると考えた 12 ※ https://tech.pepabo.com/2022/08/04/auto-multicloud-routing/ 全社統一の汎用的な仕組みで 解決するのが望ましい
13. 13 Section3 k8s Operatorによる 自動リクエストオフロード の実現 13
14. 14 k8s Operatorによる自動リクエストオフロードの実現 k8s Operatorとは • カスタムリソースを用いてk8sを拡張するコンセプト • Deployment Resourceに対するDeployment ControllerがReplicaSetを管 理するように、独自に定義したCustom Resourceに対するCustom Controllerとして振る舞う • Operatorの例 ◦ Prometheus Operator ◦ AWS Controllers for Kubernetes • k8sのコア・コンセプトのReconciliation Loopに準拠して動作 14
15. 15 Reconciliation Loop k8s Operatorによる自動リクエストオフロードの実現 次を繰り返す 1. 現在の状態を観察 2. 理想の状態と比較 3. 現在の状態が理想の状態と一致 するように変更 15 現在の 状態 理想の 状態 YAML 定義 観察 変更
16. 16 Operatorを用いた理由 k8s Operatorによる自動リクエストオフロードの実現 • 自動化の際におこなう「リク エスト数の確認、最適な加重 の計算、加重設定の更新」の 操作が、Reconciliation Loop にマッチしそう • クラウドベンダ依存を減らし た実装になることで活用の幅 が広がりそう 16 (現在の状態) 現在のNyah側 のリクエスト数 (理想の状態) Nyah側が一定以 下のリクエスト 数である （観察） リクエスト数の確認 （変更） 最適な加重の設定
17. 17 Operator実装 k8s Operatorによる自動リクエストオフロードの実現 • kubebuilderというフレームワークが提供されており、実装の型がある程度 決まっている • 実装は大きく分け「Custom Resourceの設計」と「Reconcile処理実装」 ◦ 自動化したい作業を分解しReconcile処理に必要な要素の整理を行い、 Custom Resourceを決定 ◦ Custom Resourceで定義された状態を維持するようなReconcile処理 を実装 • 既存の多種多様なカスタムコントローラーが参考になる 17
18. 18 Rebalancer Operator k8s Operatorによる自動リクエストオフロードの実現 • 指定したポリシーに基づき、外部 のメトリクスを参照して加重を調 整する • 現在はTargetとしてRoute53、 MetricsとしてPrometheus、 Policyはターゲット追従のみに対 応 • その他Target,Metrics,Policyに対 応予定 18
19. 19 Rebalanceカスタムリソース サンプル k8s Operatorによる自動リクエストオフロードの実現 19 プライベートクラウドへのリクエスト数が 一定以下になるように、AWS環境に向く加 重レコードのweightを調整する。 • 定期的にprometheusからリクエスト 数を取得 (metrics) • metricsが1000以下になる最適な weightを計算 (policy) • 算出した最適なweightを設定 (target) 2,000リクエストが来たら Nyah:AWS = 10:10に、3,000リクエストなら 10:20 に調 整。 apiVersion: rebalancer.ch1aki.github.io/v1 kind: Rebalance metadata: name: example spec: policy: targettracking: targetValue: 1000 # 維持してほしいmetrics値 baseValue: 10 # ベースとなるPrivate Cloudのweight target: # 操作対象のAWS側の加重レコード route53: hostedZoneID: <YOUR HOSTEDZONE ID> resource: name: example.com type: A identifier: aws metrics: prometheus: address: http://prometheus:9090 query: |- sum(irate( istio_requests_total{destination_service_name=~"example"}[5m]))
20. 20 得られた効果 • 月に複数回発生していたリクエストオフロードの運用作 業が0件に • アイドルタイムに無駄に利用していたAWS側のリソース が20%削減 • 全社統一の仕組みで自動リクエストオフロード機能を提 供可能に k8s Operatorによる自動リクエストオフロードの実現 20
21. 21 21 • k8s上であれば動作するため、クラウドベンダー依存が少なく可搬 性が高い • カスタムリソースのバリデーションは、kubebuilderで簡単に実装 でき独自にゼロから実装する必要がないためロジックに集中できる • 設定はCustom Resourceのmanifestになるため、管理やデプロイ は既存のk8s manifestsと管理方法を同じにできる • kubebuilderを用いることで実装の型がある程度決まるため、チー ムメンバーがキャッチアップしやすい k8s Operatorによる運用課題解決のメリット
22. 22 Section4 まとめ 22
23. 23 まとめ • 繰り返し発生する運用作業の削減とプライベートクラウドのメリットを活 かすため、自動でAWSにトラフィックをオフロードしたい課題があった • オフロードの自動化の実現のため、k8s Operatorを作成する方法を選んだ • 自動化により月数回発生していた運用を0件に、アイドルタイムに無駄に 利用していたAWS側のリソースを20%削減できた • k8s Operatorで運用自動化を実現する様々なメリットがわかった 23
24. 24 参考 • 「つくって学ぶKubebuilder」. https://zoetrope.github.io/kubebuilder-training • 磯 賢大. 『実践入門 Kubernetesカスタムコントローラーへの道』. インプレスR&D, 2020/02/28, 147p 24