Download as PDF, PPTX
組み込みポリシーの例](https://image.slidesharecdn.com/cloudntivedayskubernetescost-211028045657/85/Kubernetes-Cost-Optimization-28-320.jpg)
![[GKE & Spanner 勉強会] GKE 入門](https://cdn.slidesharecdn.com/ss_thumbnails/gke01-200121090059-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Microsoft Tech Summit] Linux/Java にも対応! Azure Service Fabric を使ったマイクロサービス開発](https://cdn.slidesharecdn.com/ss_thumbnails/20161101techsummitservicefabric-161104062136-thumbnail.jpg?width=640&height=640&fit=bounds)
![[GCC18] 世界中のプレイヤーを３つの「S」で支える Google Cloud Platform (GCP) 〜スピード・スケール・スタビリティ〜](https://cdn.slidesharecdn.com/ss_thumbnails/2018-180402005027-thumbnail.jpg?width=640&height=640&fit=bounds)
Kubernetes Cost Optimization
- 1. © 2021 NTTDATA Corporation Kubernetes Cost Optimization （知っておきたいコンテナコスト最適化技術） NTTデータ ＩＴサービス・ペイメント事業本部 SL事業部 メディア統括部 VD+チーム 目黒 翔一 2021年11月5日
- 2. 2 アジェンダ 1. 自己紹介 2. VisionData+開発の要件と課題 3.要件を満たすための施策 3.1. 工夫①映像処理特性に合わせたマネージドサービスの選定 3.2. 工夫②KEDAによるPod立ち上げ時間の高速化
- 3. © 2021 NTTDATA Corporation 3 © 2021 NTT DATA Corporation 1. 自己紹介 • 氏名：目黒 翔一 • 所属 • NTTデータ ITSP事業本部 SL事業部 メディア統括部 • ミッション：クラウドとk8sを活用してサービス導入を推進しています • 主な担当プロジェクト • VisionData+開発を通じた技術検証 • スポーツ業界のお客様へ向けた視聴体験価値向上システム構築 • 放送業界のお客様へ向けた業務効率化システム構築
- 4. © 2021 NTTDATA Corporation 4 © 2021 NTT DATA Corporation 2. VisionData+開発の要件と課題 ■スケーラブルなシステム • VisionData+に求められる要件を満たすには、サーバのスペックを 上げる必要がありますが、単純にサーバのスペックをあげるとコストが 増大します • そのため流量に応じたスケーラブルなシステムを構築しコストの最適 化を図る必要があります ■VisionData+とは 映像にメタ情報を付与することで映像の利活用の幅を広げたり、 放送業界の業務効率化を実現するシステムです メタ情報とは • 誰が映っているか • 何をテーマに話しているか • どんな文字が表示されているか・・・ VisionData+とは入力された映像からメタ情報を抽出する映像処理基盤です 処理負荷が高い映像をリアルタイムに扱う必要があり、コストを抑える難易度が高いシステムです VisionData+の要件 映像 メタ情報 画像解析 音声認識 ✓ 処理負荷の高い映像を、映像時間と等倍程度の時間 で処理すること ✓ 事前に流入量が把握できない映像量を処理すること
- 5. © 2021 NTTDATA Corporation 5 © 2021 NTT DATA Corporation 3.1. 工夫①リアルタイム処理を実現するためのマネージドサービスの選定 Functions 映像処理開始 映像処理中 映像処理中 一定以上処理に時間がかかると 再実行になってしまう 映像処理完了 Functions使用時 AKS使用時 負荷が高い映像処理を確実に実行するため、FunctionsではなくAKSを採用しました 映像処理開始 映像処理中 映像処理中 AKS 処理時間に関係なく処理が実行される
- 6. © 2021 NTTDATA Corporation 6 © 2021 NTT DATA Corporation 3.2. 工夫②KEDAによるPod立ち上げ時間の高速化（1/2） CPUの使用率をトリガーにPodをスケールした場合、Podの立ち上げ処理が間に合わない場合があります KEDAを採用することで急激な負荷の上昇に対しても素早くスケールできます 画像解析 ■スケールの流れ ① 画像処理の要求が来る ② CPU使用率をモニターし、CPUの不足を検知 ③ Podを立ち上げる ■方法①CPU使用率をトリガーにスケール • CPU使用率をモニターし、CPU使用率をトリガーにPodを立ち上げます • CPU使用率を基に順次Podを立ち上げるので一度にスケールすることができません • そのため大量に画像処理の要求が来た場合CPU使用率モニターではスケールが間に合わない可能性があります 静止画化後 大量にくる処理のリクエストに Podのスケールが追い付かない 静止画パス取得
- 7. © 2021 NTTDATA Corporation 7 © 2021 NTT DATA Corporation 3.2. 工夫②KEDAによるPod立ち上げ時間の高速化（2/2） Podをスケール ServiceBusにメッセージ が貯まるのを確認 ■方法②KEDAを利用してスケール • ServiceBusのメッセージをKEDAがモニターしPodを立ち上げます • メッセージの量に応じて立ち上げるPod数を調整するため、処理量に応じた素早いスケールが可能になります CPUのリソース使用率をトリガーにPodをスケールした場合、Podの立ち上げ処理が間に合わない場合があります KEDAを採用することで急激な負荷の上昇に対しても素早くスケールできます 画像解析 静止画化後 静止画パス取得 ■スケールの流れ ① ServiceBusにメッセージが来る ② KEDAがメッセージがたまっているのを検知 ③ 貯まっているメッセージ量に応じたPodを立ち上げる
- 8. © 2021 NTTDATA Corporation
- 9. Agenda • Vision Data∔の概要とシステム構成 • Kubernetes∔KEDAでのPod オートスケール ➠ 目黒さん • Kubernetes Pod 配置の最適化 ➠ イマココ • Kubernetes Node コストの最適化 • まとめ
- 10. KEDA ～Kubernetes-based Event-drivenAutoscaling～ イベントをトリガーにPod をスケーリングさせるオープンソースプロジェクト 対応している主なイベント •Apache Kafka •AWS CloudWatch •AWS Kinesis Stream •AWS SQS Queue •Azure Blob Storage •Azure Event Hubs •Azure Log Analytics •Azure Monitor •Azure Pipelines •Azure Service Bus •Google Cloud Platform Pub/Sub https://keda.sh/ •Azure Storage Queue •Azure Pipelines •Azure Service Bus •IBM MQ •Prometheus •Rabit MQ Queue
- 11. KEDA のしくみ https://github.com/kedacore/keda Metric • キューの長さやストリームの遅延などの イベント関連データを通知 Agent •イベントをトリガーに 0<1 または １＞０ の スケールアップとスケールダウンを行う apiVersion: keda.sh/v1alpha1 kind: ScaledObject spec: scaleTargetRef: deploymentName: visiondata triggers: - type: azure-servicebus metadata: queueName: functions-sbqueue subscriptionName: sbtopic-sub1 queueLength: "5"
- 12. Horizontal Pod Autoscaler(HPA) ⚫ 負荷に応じてPod の数をオートスケールするリソース • 指定したscaled resource object によって管理 されているpod のメトリックを取得 • 定義されたターゲット値になるにはいくつのpod がを必要かを計算して、scaled resource object のreplicas fieldを更新 Vision Data∔ では映像処理の流量が一定でなく、急 に大量のリクエストが来た場合、CPU トリガーだけでは Pod の起動に間に合わないため、KEDA / HPA を利用 してオートスケール apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: frontend namespace: magalix spec: maxReplicas: 20 minReplicas: 4 scaleTargetRef: apiVersion: apps/v1 kind: Deployment Name: frontend targetCPUUtilizationPercentage: 75 例: CPU の使用が75%になるよう、Pod の数を4～20の間で調整
- 13.
- 14. コンテナが使用するCPU／メモリの設定 • Resource Limits •Resource Requests コンテナ Resource Limits 実際の使用量が ・ CPU 500m ・ メモリ 2Gi を超えたらプロセス停止 Resource Requests デプロイするときに ・ CPU 400m ・ メモリ 1Gi を確保
- 15. CPU のResource Requestsの場合 • コンテナが使用するCPU リソースの指定 • CPU のコア単位で指定 • Kubernetes の内部コンポーネントも 共有しているのて、理論値いっぱいは 使用できないことに注意 spec: containers: - image: contoso name: contoso-web resources: requests: cpu: 500m 0 1000ｍ 2000ｍ Node2 Standard_DS2_v2 Node１ Standard_DS2_v2 700ｍ kube-system kube-system 800m 500m 500ｍ ｖCPU 500m Pending Resource Requests によるスケジューリング
- 16. スケジューリングのアルゴリズム • Node フィルタリング •Node の優先度 https://github.com/kubernetes/community/blob/master/contributors/devel/sig-scheduling/scheduler_algorithm.md Scheduler Algorithm in Kubernetes
- 17.
- 18. アプリケーション実行環境ごとの Node のコスト比較 Availability Set Node0 PublicIP LB LB LB Gateway node1 node2 node3 node4 node5 node6 node7 node8 node9 Public IP VNET ILB Availability Set APP1 LB Availability Set WEB1 WEB2 APP2 Master0 Master1 Master2 インフラレイヤーを抽象化し管理をソフトウエアで自動化 コストのチューニングが可能 物理サーバを意識したアーキテクチャ 固定コストが発生 従量課金 ワークロードによっては割高 Serverless
- 19. AKS のインフラコスト構造 Master Master Master Node NodeNode アプリケーションノード 管理ノード 無課金 課金 ※ アップタイム SLA を追加するオプション Azure 可用性ゾーンを使用するクラスターに対してKubernetes API サーバーの 99.95% のアップタイムを保証し、Azure 可用性ゾーン を使用しないクラスターに対して 99.9% のアップタイムを保証する、返金保証付きのサービス レベル アグリーメント (SLA) 従量制課金 料金 SLA で保証される稼働率 1 クラスターあたり、1 時間あたり ¥11.200（月額: 約¥8,000） + 従量課金 • 仮想マシン • ネットワーク • IPアドレス • ストレージ Kubernetes クラスタ 料金計算ツール https://azure.microsoft.com/ja-jp/pricing/calculator/?service=kubernetes-service
- 20. ノード のコスト最適化 長期利用割引やスポットインスタンスでノードのコストダウンを行う 注意事項 : •Azure Spot を使うと、非常に低コストで未使用の容量を利用できます。 バッチ処理ジョブ、開発/テスト環境、大規模なコンピュー ティング ワークロードなど、中断してもかまわないワークロードに最適 • 利用可能な容量は、サイズ、リージョン、時刻などによって異なります。 スポット インスタンスを展開すると、Azure は利用可能な容 量がある場合のみインスタンスを割り当てますが、これらのインスタンスには SLA はありません。
- 21. ノードプール の活用 Master Master Master 汎用VM 管理ノード •同じ構成のワーカーノード(VM)をグループ化する機能 • デフォルトで作成されるシステムノードプールは、クラスタ 稼働に必要なコンポーネント群(CoreDNS や tunnelfront など) が動作する • コンピューティングまたは記憶域の要件が異なるアプリ ケーションをサポートするには、追加の ユーザー ノード プールを作成 • コンピューティング集約型のアプリケーションに GPU を提 供したり、高パフォーマンスな SSD ストレージにアクセス を提供したりなど、ワークロードに応じて利用 • ノードプール単位でオートスケール設定可能 Standard DS2 v3 ￥7,849×n Standard DS2 v3 Standard DS2 v3 Standard F16s_v2 Standard F16s_v2 Standard F16s_v2 ￥55,352 ×n Standard NC12s_v2 Standard NC12s_v2 Standard NC12s_v2 GPU ￥338,486 ×n https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/linux/ コンピューティング 最適化
- 22. スケジューリングのしくみ API Server Scheduler Master etcd クラスタ 構成情報 Node１ Node2 Node N $ kubectl apply ↩ ① コマンド 実行 Pod を1つ ② Pod の構成 情報を更新 ③ Pod を割り当てる Node の選定 kubelet docker kubelet docker kubelet docker ⑤ Podを 生成 Node2 に 配置 ④ Node 情報を更新
- 23. Node Selector ⚫ Podを実行できるNode を指定する目的で利用 ⚫ 簡単に利用できる ⚫ Equality-based 条件を使用するため詳細な条件 設定ができない ハードルールではないため、nodeSelector を指定していな いPod も該当Node にデプロイされるケースがある label a node: $ kubectl lable node aks-nodepool1 hardware:gpu apiVersion: v1 kind: Pod metadata: name: visiondata labels: env: prod spec: containers: - name: visiondata image: visiondata:v1 nodeSelector: hardware: gpu 例: hardware: gpu が設定されたNodeにPodをスケジュール
- 24. Node Affinity ⚫ nodeSelectorより詳細に制御できるセレクター ⚫ 2種類のNode Affinity ◼ requiredDuringSchedulingIgnoredDuringExecution NodeにスケジュールされるPod が条件を満たすことが必須 ◼ preferredDuringSchedulingIgnoredDuringExecution 指定した条件が保証されるわけではなく、優先的に考慮 利用シーンと制約 意図的に特定のNodeで動かしたいPodがあるとき Node Selector より柔軟に設定したいときに すでに動いているPod を強制的に追い出すことができない apiVersion: v1 kind: Pod metadata: name: with-node-affinity spec: affinity: nodeAffinity: required…Execution: nodeSelectorTerms: - matchExpressions: - key: hardware operator: In values: gpu containers: - name: with-node-affinity image: nginx 例: Node Affinity が設定されたPodをスケジュール https://docs.microsoft.com/ja-jp/azure/aks/operator-best-practices-advanced-scheduler
- 25. Taints / Tolerations ⚫toleration はPodに適用され、一致するtaintが付与 されたNode へ Podがスケジューリングされることを認め るもの ⚫ taintとtoleration は組になって機能し、Podが不適切 なNodeへスケジューリングされないことを保証 Effectの設定 NoSchedule (hard) PreferNoSchedule (Soft) NoExecute (Evict – Hard^) Taint a node: $ kubectl taint node aks-nodepool1 gpu:NoSchedule A pod with a toleration tolerations: key: "gpu" operator: "Equal" value: "value" effect: "NoSchedule" https://docs.microsoft.com/ja-jp/azure/aks/operator-best-practices-advanced-scheduler https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
- 26. Pod Disruption Budget apiVersion:policy/v1 kind: PodDisruptionBudget metadata: name: vd-pdb spec: minAvailable: 60% selector: matchLabels: app: visiondata ⚫ クラスタのバージョンアップ時などでNode から Pod を排出させるときにPod の停止を許容する 数を制限するリソース minAvailable = Pod の最小起動数 maxUnAvailable = Pod の最大停止数 ⚫ 多数のノードを起動している状態でダウンタイムな くノードのメンテナンスができる ⚫ minAvailable とmaxUnAvailable は同時に指 定できない ⚫ minAvailable とmaxUnAvailable はパーセン テージで指定することを推奨
- 27.
- 28. リソース上限/ コストの管理 ⚫ Resourcelimitsの監査 • AKS - Azure Policy 連携アドオン =>Azure Policy はAzure のガバナンス機能 • アクションとして、監査のみ/拒否/リソースの展開などが 可能 • リソース作成時/定期的なトリガーでポリシー適用 • Open Policy Agent (OPA) による Gatekeeper v3 で 実装 • 制約テンプレートは Rego によって記述 ⚫ コスト監視 • Azure Cost Management の利用 • アラートを設定することで利用超過を防ぐ • ビューをカスタマイズできるのでコスト分析が可能 [Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits](Kubernetes クラスター コンテナーの CPU およびメモ リ リソースの制限が指定された制限を超えないようにする) 組み込みポリシーの例
- 29. まとめ • Vision Data∔はコンピューティングリソースを多く要する映像処理ソリューションで 以下の要件があり、アプリケーション実行基盤の細かいチューニングが必要 ✓ 映像量と同程度の時間で処理を完了 ✓ 流量が事前に把握できない処理の実行 • なるべくコストを最適化し、かつスケーラブルな構成で運用するにはKubernetes の活用 が最適 • Kubernetes の機能/KEDA/Azure のサービス群 などを組み合わせて使うことで要件を クリア 現在、絶賛開発検証中なので、次回の発表を乞うご期待！！