0. はじめに
この記事は Cisco Systems Japan の有志による Advent Calendar 2022 のカレンダー1の記事です。
< 過去の記事 >
2017年: https://qiita.com/advent-calendar/2017/cisco
2018年: https://qiita.com/advent-calendar/2018/cisco
2019年: https://qiita.com/advent-calendar/2019/cisco
2020年(1枚目): https://qiita.com/advent-calendar/2020/cisco
2020年(2枚目): https://qiita.com/advent-calendar/2020/cisco2
2021年(1枚目):https://qiita.com/advent-calendar/2021/cisco
2021年(2枚目)https://qiita.com/advent-calendar/2021/cisco2
2022年: https://qiita.com/advent-calendar/2022/cisco
今年もCisco Intersightについて紹介します。
1. Intersight Wokrload Optimizer概要
Cisco Intersightで提供しているサービスIntersight Workload Optimizerについてご紹介します。
Intersight Workload Optimzierで提供できることして、オンプレミス・クラウド環境をリソース管理および最適化を行うことができます。
クラウド対象はAWS、Azure、GCPなどでオンプレ対象はVMware、HyperVなどを対象しております。SaaSプラットフォームとなっているために、このソフトウェアを利用するための管理は不要になっている点もポイントです。
下記の図ではAWS環境における具体的リソース改善ポイントをサプライチェーンの図で示したものです。
クラウドインスタンスタイプを変更することでコスト削減に寄与したり、最適なストレージタイプに変更にすることで性能に対応したり様々なユースケースで利用していただくことが可能です。
また、オンプレミスからクラウドにインフラを移行したい方向けには、現状の仮想マシンのリソースを確認し、最適なクラウドインスタンスを選択してくれます。
クラウドに対しての理解があればクラウドオプションを選択することは容易ですが、専門家でない方がオンプレ環境の仮想マシンからクラウドマイグレーションする際に具体的にどのインスタンスでマイグレーションをすればよいのかを選択することは容易ではありません。その点、ツールでその部分をアシストすることができれば、インフラ管理者にとっては非常に容易となります。
下記図で示している２つのカラムを説明すると、"LIFT＆SHIFT"、”OPITMIZED"という２つのカラムがあります。
- LIFT＆SHIFT：オンプレミス環境で動作している仮想マシンをそのままクラウドにマイグレーションした場合のコストを示しています。
- OPTIMIZED: Intersightで生成されたリソースの推奨アクションを適用し、クラウドマイグレーションした場合のコストを示しています。
結果としては、２つのケースを比較すると、推奨アクションを適用してクラウドマイグレーションをした場合、より安いコストでAWSインスタンスを用意できることがわかります。
上表は、左側はオンプレミスの仮想マシン環境をしめしており、LIFT&SHIFTでのAWS EC2インスタンスとのマッピング、その左のOPTIMIZEDでのAWS EC2インスタンスのマッピングを示しております。
現行のオンプレミス仮想マシンのインスタンスのリソースから判断すると、具体的にどの仮想マシンを利用すればよいかを確認することもできます。
本稿では、様々なユースケースがある中で、Intersight Workload Optimzierを利用するユースケースとして、「Kubernetesのリソース最適化・見える化」を中心にご紹介いたします。
- コンテナリソースのサイジング
- コンテナ配置の最適化
- コンテナリソースの拡張
Intersight Workload Optimizerの対象となるKubenetesサービスは、クラウド環境にホストしているkubernetesサービスやオンプレミス上に展開しているKubernetsも対象になります。
クラウドであれば、Kubernetesのリソースを最適化しつつ、コスト削減の提案を含め行ってくれるサービスとなっております。
2. リソースの可視化
Intersight workload Optimizerでできるリソースの可視化をKubernetesに対して適用するとどのように見える化できるかを確認していきます。
下記の図では、Azure環境のKubernetes環境を可視化しております。
サプライチェーンというリソースを確認する依存関係では、４つのリソースの状態を確認することができます。
特に余剰なリソースを示すノードと、リソースが足りていない危険を示すノードを確認することで、Kubernetesの性能とリソース最適化を促すための
アクションを生成することができることを示しております。
ここで注意したいのは、ユーザの指定によって中心にあるリソースを変更することが可能です。
例えば、クラスタ単位、特定のノード単位、特定のPod単体、特定のworkload controller単位など様々視点でリソース内容を確認できる点に注意したい。
視点を変更して、そのリソースの依存関係を示して表示することも可能です。Kubernetes視点でもリソース確認できますし、アプリケーション視点でのリソース依存関係も示すことができます。
ハイブリッドクラウド構成またはマルチクラウド構成で提供されているKubernetes環境をアプリケーション視点で見ることで、オンプレミス・クラウド環境に依存しないリソース同士の依存関係確認することができるので、どのリソースを改善すべきか表示することが可能です。
3. コンテナリソースのサイジング
Kuberenetesのリソースを管理するためのサイジング機能についての課題や性能管理の難しさをご紹介しつつ、どのようにIntersight workload Optimizerで解決できるかを紹介していきます。
コンテナリソース管理の複雑さ
通常、Kubernetes管理者であればコンテナリソースまたはKubernetesにおけるコンテナ配置のルールなどを利用することでKubernetes管理者がリソース制御を行っています。
そのリソース管理者はAPM製品または独自にOSSを活用して日々リソース確認を行っていると考えます。一方で、コンテナサイジングという点では、モニタリング製品では具体的なサイジングに関連した推奨を示してくれる製品は少ないのと、その製品を使いこなすのに、専門的なスキルを必要するのは言うまでもないでしょう。
コンテナなリソース管理での課題として４つあげられます。
- コンテナのリソースを管理するのはインフラ管理者ではなくアプリケーション担当者。
- コンテナノードは利用可能なリソースを超えると削除されてしまう
- コンテナはメモリ制限を超えると強制終了してしまう。
- リソース設定の制限値を考慮していないケースもあり、オーバープロビジョニングしてしまう。
CPUスロットリングの課題
リソース管理の課題として、CPUスロットリングがあげれます。このCPUスロットリングはリソース制限がかかるから起こる制限となります。
適切にサイジングできていれば、CPUスロットリングが起こることなく、コンテナ性能しっかりと確保することができるでしょう。
一方で、CPU制限がかかりすぎると、性能にどのようなインパクトがあるのかを確認すのは難しいです。Intersight wokload Optimizerでは、このCPUスロットリングをモニタリングして、このスロットリングを解消するための推奨アクションを示します。
上図の例ではコンテンナのvCPUのリソース値を500mから1200mに変更することで、CPUスロットリングを87.5% → 15.2%に削減可能な提案を行ってくれます。この機能を利用することで、現行のCPUスロットリングの課題を解決することが可能となります。
4.コンテナ再配置によるKubernetesリソース最適化
続いてコンテナ配置の最適化についてみていきましょう。通常のkubernetesのコンテナ配置はPODを動的に最適化する機能ようなものは提供されておりません。
Intersight Workload Optimizerでは３つの視点でコンテナの再配置によるKuberneリソース最適化を行うことが可能です。
1.Noisy Neighbor削減
Node1のコンテナリソースを最適化する場合、あるコンテナが非常に多くのリソースを確保しようとすると、他のコンテナに性能影響を与える可能性があるというものです。
2.性能劣化の削減
あるノードのノードリソースが枯渇している場合に、コンテナを再配置することで、コンテナの性能劣化を回避することができます。
3.保留中のPODの回避
ノードリソースを最適化することで、より空きのリソースを確保し、新しいPODの展開に役立ちます。
下記図ではノードあたりでコンテナリソースを最適化するためのアクションを適用した結果を示しています。多くのリソースを必要するコンテナを他のノードに再配置することで、Kubernetesリソース全体の最適化に寄与することが可能であることを示しています。
5.コンテナリソースの拡張
コンテナリソース配置の自動拡張の課題として、適切なSLOベースでスケールできないという課題があります。Kubernetesではアプリケーションが示す
サービスメトリックを把握することはできません。一方で、それらのSLOをレスポンスタイムやトランザクション数という観点でコンテナを自動拡張する仕組み
をIntersight workload Optimzierはもっており、コンテナ拡張を支援することができます。このSLOのメトリック情報は、AppDynamicsなどのAPM製品を用いたり、Prometheusなどのオープンソースから取得することも可能です。
6.さいごに
本稿では代表的なIntersight workload Optimizerの機能を紹介しつつKubernetesのリソース最適化に関して、ご紹介いたしました。
Intersight Workload Optimizerは45日フリートライアルを実施しております。クラウド環境のkubernetes環境で簡単に試すことができるため、ぜひ一度試してみていただければと思います。
免責事項
本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、私の所属する組織の意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、私の所属する組織や他の関係者による推奨や表明を目的としたものではありません。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Web サイトの利用に関するあらゆる責任から私の所属する組織を免責することに同意したものとします。