Cloud Native Days Tokyo 2021

1. © 2021 NTT DATA Corporation
Kubernetes Cost Optimization
（知っておきたいコンテナコスト最適化技術）
NTTデータ ＩＴサービス・ペイメント事業本部
SL事業部 メディア統括部
VD+チーム 目黒 翔一
2021年11月5日

2. 2
アジェンダ
1. 自己紹介
2. VisionData+開発の要件と課題
3. 要件を満たすための施策
3.1. 工夫①映像処理特性に合わせたマネージドサービスの選定
3.2. 工夫②KEDAによるPod立ち上げ時間の高速化

3. © 2021 NTT DATA Corporation 3
© 2021 NTT DATA Corporation
1. 自己紹介
• 氏名：目黒 翔一
• 所属
• NTTデータ ITSP事業本部 SL事業部 メディア統括部
• ミッション：クラウドとk8sを活用してサービス導入を推進しています
• 主な担当プロジェクト
• VisionData+開発を通じた技術検証
• スポーツ業界のお客様へ向けた視聴体験価値向上システム構築
• 放送業界のお客様へ向けた業務効率化システム構築

4. © 2021 NTT DATA Corporation 4
© 2021 NTT DATA Corporation
2. VisionData+開発の要件と課題
■スケーラブルなシステム
• VisionData+に求められる要件を満たすには、サーバのスペックを
上げる必要がありますが、単純にサーバのスペックをあげるとコストが
増大します
• そのため流量に応じたスケーラブルなシステムを構築しコストの最適
化を図る必要があります
■VisionData+とは
映像にメタ情報を付与することで映像の利活用の幅を広げたり、
放送業界の業務効率化を実現するシステムです
メタ情報とは
• 誰が映っているか
• 何をテーマに話しているか
• どんな文字が表示されているか・・・
VisionData+とは入力された映像からメタ情報を抽出する映像処理基盤です
処理負荷が高い映像をリアルタイムに扱う必要があり、コストを抑える難易度が高いシステムです
VisionData+の要件
映像 メタ情報
画像解析
音声認識 ✓ 処理負荷の高い映像を、映像時間と等倍程度の時間
で処理すること
✓ 事前に流入量が把握できない映像量を処理すること

5. © 2021 NTT DATA Corporation 5
© 2021 NTT DATA Corporation
3.1. 工夫①リアルタイム処理を実現するためのマネージドサービスの選定
Functions
映像処理開始 映像処理中 映像処理中
一定以上処理に時間がかかると
再実行になってしまう
映像処理完了
Functions使用時
AKS使用時
負荷が高い映像処理を確実に実行するため、FunctionsではなくAKSを採用しました
映像処理開始 映像処理中 映像処理中 AKS
処理時間に関係なく処理が実行される

6. © 2021 NTT DATA 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 NTT DATA 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 NTT DATA Corporation

9. Agenda
• Vision Data∔ の概要とシステム構成
• Kubernetes∔KEDAでのPod オートスケール ➠ 目黒さん
• Kubernetes Pod 配置の最適化 ➠ イマココ
• Kubernetes Node コストの最適化
• まとめ

10. KEDA ～Kubernetes-based Event-driven Autoscaling～
イベントをトリガーに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. Pod 配置の最適化

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. Node コストの最適化

18. アプリケーション実行環境ごとの Node のコスト比較
Availability
Set
Node0
Public IP
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 Node Node
アプリケーションノード
管理ノード
無課金
課金
※ アップタイム 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１ Node 2 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. リソース上限/ コストの管理
⚫ Resource limitsの監査
• 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 のサービス群 などを組み合わせて使うことで要件を
クリア
現在、絶賛開発検証中なので、次回の発表を乞うご期待！！