新機能

プラット・フォーム管理

• ロールベースのアクセス制御バージョン 2 ( RBACv2 ) によるカスタムロールとアクセス許可 （パブリック プレビュー）：このリリースでは、ロールベースのアクセス制御機能を強化する「 RBACv2 」が導入されました。 これにより、カスタムロールの作成や権限の範囲設定が可能になり、 Turbonomic のリソースに対してよりきめ細かなアクセス管理を実現します。 詳細については、 「カスタムロールの作成と権限」 を参照してください。

コンテナプラットフォームのリソース管理

• Kubernetes サービス向けSLO Guard ：SLO Guardは、 Kubernetes アプリケーションサービスを自動的に水平方向にスケールアウトし、ビジネストランザクションにおけるユーザー定義の応答時間サービスレベル目標（SLO）の維持を支援します。 このシステムは、エンドツーエンドのトランザクション応答時間を継続的に追跡し、基盤となる Kubernetes ワークロードのレプリカ数を自動的に調整します。 SLO Guardによって管理されるトランザクションについては、応答時間の目標を一貫して達成できるよう、関連するサービスのすべてのワークロードにわたってスケーリングの決定が調整されます。 この機能を利用するには、トランザクションメトリクスの取得に Instana、スケーリング操作の実行にKubeturboが必要です。 詳細については、 「SLO Guard」 をご覧ください。

• 「ゲスト仮想マシン」の名称が「コンテナ型仮想マシン」に変更されました ： OpenShift の仮想化エンティティのうち、従来「 ゲスト仮想マシン 」と呼ばれていたものが、「 コンテナ型仮想マシン 」に名称変更されました。 この変更は、 Turbonomic のサプライチェーンにおける「 OpenShift Virtualization」仮想マシンエンティティへの参照にのみ適用されます。

  この更新された用語は、コンテナ化された環境で動作する従来の仮想マシンをより正確に反映しています。 この変更は、ドキュメントおよびユーザーインターフェース全体に適用されます。 これは名称の変更のみであり、機能や動作には影響しません。

• コンテナ仕様ポリシーにおけるホットプラグ設定（一般提供開始） ：コンテナ仕様ポリシー内の「 vCPU 」および「 vMem 」のホットプラグ設定が、一般提供開始となりました。 これらの設定が有効になっている場合、 Turbonomic は、 Red Hat OpenShift Virtualizationのコンテナ化された仮想マシンに対して、 vCPU および vMem のサイズを、仮想マシンを再起動することなく拡大しようとします。

クラウドリソース管理

• Azure Databricks のサポート ：このリリースでは、「データ、アナリティクス、AI」カテゴリに Databricks Workspace ターゲットが追加されました。 このターゲットは、 Azure Databricks の汎用コンピューティングクラスタ、およびそのドライバーノードとワーカーノードを検出します。 Turbonomic ドライバーノードおよびワーカーノード向けのスケーリングアクションを生成し、可能な限り低いコストでパフォーマンスを最適化します。 現時点では、スケール操作は手動モードで生成され、Databricks上で実行する必要があります。

  サプライチェーンにおいて：

  • クラスターは、データレイクハウスエンティティとして表示されます。

  • ドライバーノードとワーカーノードは、仮想マシンの仕様エンティティとして表現されます。

  アクションセンターでは、「 クラウド 」または「 すべて 」タブからスケール操作を確認できます。 [スケールの拡大] > [仮想マシンの仕様] > [Databricks] の順に展開して、操作を表示します。

  詳細については、 Databricks をご覧ください。

• 使用されていない AWS および Google Cloud のVMと、それらにアタッチされたボリュームの削除操作 ： Turbonomic では、使用されていない AWS または Google Cloud VM とそのアタッチされたボリュームを削除するための単一のアクションを推奨できるようになりました。これにより、コスト削減と運用効率の向上が図れます。 これらのアクションを表示するには、[アクションセンター] に移動し、[ クラウド ] タブをクリックして、 [削除] を展開し、 [仮想マシン ] をクリックします。 詳細については、 「アイドル状態のクラウドVMおよびアタッチされたボリュームの削除操作」 を参照してください。

  この機能を使用可能にするには、以下のようにします。

  • AWS ： Turbonomic に対して、IAM ユーザーまたはロールに以下の権限を追加します。

    • ec2:TerminateInstances

    • ec2:DeleteVolume

  • Google Cloud ： Turbonomic のサービスアカウントに、以下の権限を追加してください：

    • compute.instances.delete

    • compute.disks.delete

• クラウドワークロード向けのスケーリング制約の強化 ：このリリースでは、以下の機能強化が導入されています

  • 最大監視期間 ：クラウド仮想マシンの仕様、データベース、およびデータベースサーバーに関する自動化ポリシーにおいて、最大監視期間の設定に、従来の最大30日から90日がオプションとして追加されました。 この機能強化により、スケーリング操作が、長期的かつ予測可能なワークロードのパターンをより的確に反映できるようになります。

  • 積極性 ：クラウドデータベースおよびデータベースサーバーの自動化ポリシーにおいて、積極性の設定に、従来の最大値であった99パーセンタイルから、100パーセンタイルまでのよりきめ細かなパーセンタイルオプション（ 99.1th、 99.5th、 99.9th、および100th）が追加されました。 この機能強化により、一貫して高いパフォーマンスが求められるワークロードに対して、よりきめ細かな制御が可能になります。

• AWS Auto Scaling グループの請求済みコストの取得 ： Turbonomic では、 AWS Auto Scaling グループの現在および過去の請求済みコストを取得できるようになりました。 これらのグループは、 Turbonomic において、 仮想マシンの仕様エンティティとして表示されます。

  特定のオートスケーリンググループのコストデータを表示するには：

  • Turbonomic のサプライチェーンまたは検索ページで、スコープを対応する仮想マシン仕様エンティティに設定し、「コスト内訳」グラフを確認してください。

  • 「割引適用範囲」の表で、適用範囲を同じエンティティに設定してください。

• Apache Parquet AWS の課金データに対するファイル形式のサポート ： Turbonomic は、以下の課金データ配信方式において、 Apache Parquet ファイル形式のサポートを開始しました。これにより、従来の CSV や非圧縮形式に加え、対応範囲が拡大されました。

  • AWS コストおよび使用状況レポート（CUR） 2.0

  • AWS レガシー CUR エクスポート

  Apache Parquet データ処理のパフォーマンスを向上させ、ストレージおよび演算のオーバーヘッドを低減します。 Parquetファイル形式に切り替えると、既存の AWS 課金対象は、自動的にこの形式で課金データを取得するようになります。 追加の構成は不要です。

オンプレミスリソースの管理

• VM インフラストラクチャの供給制約を考慮したリサイズ操作 ： Turbonomic では、リソース競合が発生しているオンプレミスVMに対して、基盤となるホストやクラスターに十分な容量がない場合でも、リサイズアップ操作を生成するようになりました。 これらの措置には、インフラの制約を明確に記述した前提条件が含まれており、リソース要件の可視性を高め、キャパシティ計画の意思決定を支援するものです。 これまでは、このような状況では何のアクションも生成されませんでした。 重要なワークロードについては、要件を確認し、手動でアクションを実行するかどうかを選択できるようになりました。 詳細については、 「 VM ：インフラストラクチャの供給制約を伴うリサイズアクション」 を参照してください。

• vCenter のキャッシュメモリに関する制約 VM 縮小操作 ： Turbonomic では、 VMware Toolsがインストールされた vCenter VMに対して、 vMem の縮小操作を推奨する際、キャッシュメモリを考慮するようになりました。 これにより、キャッシュされたメモリがディスクにページアウトされるのを防ぎ、サイズ変更時のパフォーマンス低下を回避するのに役立ちます。 詳細については、 「 vMem のサイズ縮小時にキャッシュメモリを考慮する 」を参照してください。

インフラストラクチャ・アズ・コード（ IaC ）によるリソース管理

IaC 統合機能（一般提供開始） ： IaC の統合機能が一般提供開始されました。これにより、 Turbonomic は、ソースコードリポジトリやリモートステートバックエンドに保存されたTerraformで定義されたインフラストラクチャを検出して管理できるようになりました。 Turbonomic は、Terraformの設定ファイルとリモート状態を読み込むことで、リソースエンティティやアクションの詳細にコードコンテキストを追加し、バージョン管理システム（VCS）のリポジトリへのディープリンクも提供します。 このコンテキストにより、アクションの実行や下流の自動化が加速されます。

ご利用の環境によっては、特定の連携機能が必要となります：

• VCS ：Terraform Cloud または Terraform Enterprise で VCS 以外のワークスペースを使用する場合、あるいは Terraform Community Edition を使用する場合に必要です。 Turbonomic 以下のVCSプラットフォームに接続し、リポジトリに保存されているTerraformの設定にアクセスできます。

  • Azure DevOps ：Terraformの設定が含まれるプロジェクトやリポジトリを連携させます。 この統合機能では、パーソナルアクセストークン（PAT）を使用した認証に対応しています。 詳細については、 Azure DevOps をご覧ください。

  • GitHub ：Terraform 設定を含むリポジトリを接続します。 この統合機能では、パブリックおよびプライベートリポジトリへのアクセスにおいて、 GitHub AppsおよびPATsを使用した認証がサポートされています。 詳細については、 GitHub をご覧ください。

  • GitLab ：Terraform 設定を含むプロジェクトやグループを連携させます。 この統合機能では、 GitLab.comおよびセルフホスト型インスタンスにおいて、PATおよび OAuth を使用した認証がサポートされています。 詳細については、 GitLab をご覧ください。

• リモート状態バックエンド ：Terraformの Community Edition を使用する場合に必要です。 Turbonomic 以下のリモート・ステート・バックエンドからTerraformのステートデータにアクセスできます。

  • AWS S3 ： Amazon S3 のバケットに保存されたstateファイルから、Terraformで定義されたインフラストラクチャを検出します。 この統合では、 AWS の標準的な認証およびアクセス制御の仕組みが使用されています。 詳細については、 「 S3 のリモート状態ファイルにアクセスするための AWS IAMユーザーの設定」 を参照してください。

  • Azure Blob Storage ：サービスプリンシパル認証を使用して、 Azure Blob Storage に保存されているstateファイルから、Terraformで定義されたインフラストラクチャを検出します。 詳細については、 「 Azure Blob Storage のリモート状態ファイルにアクセスするための Azure サービスプリンシパルの設定」 を参照してください。

  • Google Cloud Storage (GCS) ：サービスアカウントによる認証を使用して、GCSバケットに保存されているstateファイルから、Terraformで定義されたインフラストラクチャを検出します。 詳細については、 「GCSのリモート状態ファイルにアクセスするための Google Cloud サービスアカウントの設定」 を参照してください。

Oracle （OCI）クラウドインフラストラクチャのサポート ：本リリースでは、OCIワークロードの監視と最適化を行うための新しい「 Oracle Cloud」ターゲットが導入されました。 サポートされるワークロードには、コンピュートインスタンス（VM）およびブロック/ブートボリュームが含まれます。 Turbonomic 計算インスタンスとボリュームをスケーリングして、可能な限り低いコストでパフォーマンスを最適化できるほか、アタッチされていないボリュームを削除してコストを削減できます。

OCIへの接続要件および設定については、 「OCIへの接続」 を参照してください。

使用されていない Azure VMおよびアタッチされたボリュームの削除操作 ： Turbonomic では、使用されていない Azure VM およびそのアタッチされたボリュームを削除するための単一の操作を推奨できるようになりました。これにより、コスト削減と運用効率の向上が図れます。 アクションを確認するには、アクション センターに移動し、「 クラウド 」タブをクリックして、 「削除」 を展開し、 「仮想マシン 」をクリックします。 詳細については、 「アイドル状態のクラウドVMおよびアタッチされたボリュームの削除操作」 を参照してください。

この機能を有効にするには、 Turbonomic の「 Azure 」サービスプリンシパルに対して、以下の権限を追加してください：

• Microsoft.Compute/virtualMachines/delete

• Microsoft.Compute/disks/delete

Azure のターゲットに対する証明書ベースの認証 ： Turbonomic では、既存のシークレットベースの認証に加え、 Azure のサービスプリンシパルおよび課金対象に対する証明書ベースの認証がサポートされるようになりました。 この機能強化により、証明書ベースの Azure APIアクセスに関する企業のセキュリティ要件を満たしつつ、完全な下位互換性を維持しています。 詳細については、 「証明書の作成」 を参照してください。

Azure 仮想マシンの仕様に追加されたアクションのサブカテゴリ ：アクションセンターの「 クラウド 」および「 すべて 」タブでは、 Azure 仮想マシンの仕様に関するアクションが専用のサブカテゴリに分類されるようになり、スケールや削除などのアクションの確認と実行が効率化されました。

• スケール > 仮想マシンの仕様 ： Azure VM の「スケールセット」のサブカテゴリは「 スケーリンググループ 」ですが、 Azure App Service の「プラン」のサブカテゴリは 「App Services」 です。

• 削除 > 仮想マシンの仕様 ： Azure および App Service プランのサブカテゴリは 「App Services」 です。

Google Cloud のマネージドインスタンスグループ（MIG）の請求済みコストの取得 ： Turbonomic では、 Google Cloud のMIGについて、現在および過去の請求済みコストを取得できるようになりました。 これらのグループは、 Turbonomic において「仮想マシン仕様」エンティティとして表示されます。

特定のMIGのコストデータを表示するには：

• Turbonomic のサプライチェーンまたは検索ページで、スコープを該当する「仮想マシン仕様」エンティティに設定し、「コスト内訳」チャートを確認してください。

• 「割引適用範囲」の表で、適用範囲を同じエンティティに設定してください。

アプリケーション・パフォーマンス管理

• APMターゲット向けの VM およびホスト検出機能の強化 ： Turbonomic は、 AppDynamics,、 Datadog、 Dynatrace、 Instana、および New Relic の各ターゲットについて、 VM およびホストデータを一貫して検出・収集するようになりました。これにより、機能フラグの設定にかかわらず、エンティティの確実な結合が保証されます。 基となるデータを失うことなく、表示設定を制御できます。 詳細については、 AppDynamics、 Datadog、 Dynatrace、 Instana、および New Relic をご覧ください。

コンテナプラットフォームのリソース管理

Turbonomic コンテナプラットフォームの管理機能を拡張し、コスト可視化のためのKubecostとの連携、OOM（メモリ不足）の自動修復、ノードポリシーの改善、応答のないPodの強制終了に加え、運用を簡素化する新しい Prometheus セットアップウィザードを提供します。 また、 Turbonomic Admission Controller および改良された Kubeturbo の権限設定を通じて、ガバナンスとセキュリティの強化も図られています。 Red Hat OpenShift のターゲット環境において、 Turbonomic は、 Red Hat OpenShift の仮想化統合機能を強化し、コンテナ化された VM の可視化と容量予約を実現します。

• Kubecostとの連携 ：Kubecostとの連携機能が一般提供開始されました。これにより、 Turbonomic は、 Kubernetes のリソース最適化が財務に与える影響を可視化できるようになります。 ワークロード・コントローラーのサイズ変更に伴う潜在的なコスト削減効果や必要な投資額を確認できるため、プラットフォーム上で直接、コストを意識した最適化の判断を下すことができます。 詳細については、 「 Kubernetes 向けの Kubecost の設定 」および「 Red Hat OpenShift 」を参照してください。

• Prometheus ターゲット用の設定ウィザード ： Turbonomic では、 Prometheus ターゲットを追加するための新しいガイド付き操作機能が導入され、 Kubernetes クラスタ上でのPrometurboの設定とデプロイが簡素化されました。 ウィザードが所定の手順を案内し、必要な PromQL クエリを自動的に設定し、クラスタ内で実行されるスクリプトを生成してセットアップを完了させます。 詳細については、 「 Turbonomic 」ユーザーインターフェースを使用した Kubernetes クラスターへのPrometurboのデプロイを参照してください。

• コンテナノードポリシーにおける最大ノード使用率の設定 ：ターゲット使用率のしきい値を設定して、ノードのプロビジョニングアクションが生成されるタイミングを指定できるようになりました。 リソース使用量に基づくものであれ、リクエスト駆動型の利用状況に基づくものであれ、これらの制御機能は、クラスタの健全性を維持し、コストを最適化し、ノードの停止やその他の障害発生時にも十分な容量を確保するのに役立ちます。 バージョン 8.17.6 では無効化されていたこの機能が、機能面での改善を経て再び有効になりました。 詳細については、 「コンテナノードのポリシー」 を参照してください。

• コンテナプラットフォームノードにおける強制ポッド強制終了 : Turbonomic は、コンテナプラットフォームノード上で停止状態、不健全状態、または応答不能状態となったポッドを自動的に強制終了するポリシーをサポートするようになりました。 この機能により、ノード停止操作が確実に完了し、より信頼性の高いコスト最適化と運用オーバーヘッドの削減が実現されます。 また、手動でのポッドとノードのクリーンアップの必要性を排除します。 詳細については、 コンテナプラットフォームノードでのポッド強制削除を参照してください。

• メモリ不足イベントの自動検出と修復 ： Turbonomic は、 Kubernetes のワークロードにおけるメモリ不足（OOM）イベントを検出し、影響を受けたワークロードを自動的に修復してポッドの健全性を回復するようになりました。 この機能強化により、予期せぬメモリ使用量の急増が発生した際に、メモリの適正なサイズ設定を修正することで、ワークロードの耐障害性が向上します。

  OOMリカバリは完全に自動化されており、常に自動モードで実行されます。 ワークロードコントローラーのリサイズ操作が手動モードに設定されている場合でも、 Turbonomic はOOMイベントを検出すると、ユーザーの介入なしに自動的にワークロードを回復します。 必要に応じてこの機能を無効にすることができます。 詳細については、 「自動化されたメモリ不足イベントの検出と修復」 を参照してください。

• Turbonomic Admission Controller ： Turbonomic Admission Controller（TAC）が一般提供開始されました。これにより、 GitOps およびInfrastructure-as-Code（ IaC ）環境において、実行時の Kubernetes リソース最適化を維持するという課題が解決されます。 一般的なワークフローでは、CI/CDパイプラインやArgo CDなどのツールが、 Turbonomic の最適化されたリソース設定を検出し、 Git に保存されている静的構成に合わせて元に戻すことがよくあります。

  TACは、 Kubernetes のAPIレベルにおけるゲートキーパーとして機能し、 Turbonomic の最適化されたリソース設定がこれらの環境全体で維持されるようにします。 これにより、チームは Git の設定を手動で変更したり、CI/CDパイプラインを修正したりすることなく、最適なパフォーマンスとコスト効率を維持できます。 詳細については、 「 Turbonomic Admission Controller 」および 「 Turbonomic 」ユーザーインターフェースを使用した Kubernetes クラスターへのKubeturboのデプロイを参照してください。

• Kubeturbo Operator ClusterRole の権限 ：Kubeturbo Operator は、既存の機能を維持 ClusterRole しつつ、最小権限の原則に従うよう更新されました。 クラスタ全体のシークレット読み取り権限が削除され、オペレーターはネームスペースをまたいでシークレットを読み取ることができなくなりました。 その結果、この git-secret-namespace 引数は非推奨となり、無視されます。 Kubeturboは、自身がデプロイされているネームスペース内の Git シークレットのみを読み込むようになりました。 さらに、動詞が escalate 削除されるため ClusterRole 、オペレーターは自身が保有していない権限をKubeturboサービスアカウントに付与できなくなります。 詳細については、 Kubeturbo オペレーター「 ClusterRole 」の「必要な最小限の権限」 を参照してください。

• Red Hat OpenShift 仮想化向けのコンテナ化された仮想マシンエンティティ ： Turbonomic では、 Red Hat OpenShift 仮想化を通じて管理される Linux およびWindows VMを、サプライチェーン内のコンテナ化された仮想マシンエンティティとして表示するようになりました。 これにより、コンテナ化された VM レベルでのパフォーマンスの監視と最適化が可能になります。 詳細については、 「コンテナ化された仮想マシン」 を参照してください。

• Red Hat OpenShift および VM の予約機能のサポート ： Turbonomic では、テンプレートと配置ポリシーを使用して、 Red Hat OpenShift 仮想マシンのリソースを予約できるようになりました。 Turbonomic クラスタの容量を分析し、リソース要件、ネームスペースのクォータ、および配置制約に基づいて、 VM のデプロイに適したノードを選択します。 これにより、組織のポリシーに準拠しつつ、十分なCPUおよびメモリ容量を備えたノードにVMを配置することができます。 詳細については、 「 OpenShift の仮想マシン・テンプレートの設定」 を参照してください。

クラウドリソース管理

Turbonomic AWS、 Azure、および Google Cloud のワークロードに対する最適化機能を拡張し、新たなスケーリングおよびパーキング操作を追加します。 また、 AWS および Azure のワークロードに対する効果的なコスト追跡機能を追加し、より正確なレポートとコスト分析を提供します。

• Azure 仮想マシン スケール セットのスケール操作 : Turbonomic は、 Uniform Orchestration を使用する Azure 仮想マシン スケール セットのスケール操作を生成するようになりました。 これらのアクションにより、可能な限り低いコストでパフォーマンスが最適化されます。

  このリリースでは、仮想マシン スケール セット内のすべての VM インスタンスのサイズを変更する垂直スケーリング操作が導入されました。 保留中のスケールアクションを確認する際、 Turbonomic は関連するオンデマンドコストを表示し、そのコスト影響を理解するのに役立ちます。 仮想マシン スケール セットが Azure の予約または節約プランの対象となっている場合、オンデマンド料金から実効料金に切り替えることで、請求内容に沿ったより正確なコスト表示が可能になります。 詳細については、 「仮想マシン スケール セットのスケール操作」 を参照してください。

  仮想マシン スケール セットのスケール操作を有効にするには、 Turbonomic の Azure サービス プリンシパルに以下の権限が含まれていることを確認してください。

  • Microsoft.Network/networkSecurityGroups/join/action

  • Microsoft.Network/virtualNetworks/subnets/join/action

  仮想マシン スケール セットに Azure Load Balancer が接続されている場合にのみ、これらの権限を追加してください。

  • Microsoft.Network/loadBalancers/read

  • Microsoft.Network/loadBalancers/backendAddressPools/join/action

  Azure Application Gateway が仮想マシン スケール セットとペアリングされている場合にのみ、この権限を追加してください。

  • Microsoft.Network/applicationGateways/backendAddressPools/join/action

  注:

  これらの権限は、仮想マシン スケール セットを駐車するためにも必要です。 以前のリリースでパーキングアクションを有効にした場合、サービスプリンシパルには既に権限が含まれている可能性があります。 サービスプリンシパルを確認し、必要に応じて更新してください。

• Azure ワークロードのパーキング機能のサポート ： Turbonomic は、以下の Azure ワークロードに対するパーキング操作をサポートするようになりました：

  • Azure MySQL 用データベース - Flexible Server インスタンス

    これらのインスタンスでパーキングを有効にするには、 Turbonomic の「 Azure 」サービスプリンシパルに対して、以下の権限を追加してください。

    • Microsoft.DBforMySQL/flexibleServers/read

    • Microsoft.DBforMySQL/flexibleServers/start/action

    • Microsoft.DBforMySQL/flexibleServers/stop/action

    詳細については、 「 MySQL - Flexible Server 向け Azure データベースの駐車機能」 を参照してください。

  • vCore または DTU 購入モデルを採用するSQLデータベース

    これらのデータベースは、 ソフトストップ機能を使用して一時停止されています。この機能により、データベースの稼働を維持しつつ、リソースを最小限に抑えてコストを削減します。 パフォーマンス重視のスケーリング操作は、データベースが再起動されるまで延期されます。

    これらのデータベースのパーキングを有効にするには、まだ追加されていない場合は、 Turbonomic の「 Azure 」サービスプリンシパルに以下の権限を追加してください。

    • Microsoft.Sql/servers/databases/transparentDataEncryption/read

    • Microsoft.Sql/servers/databases/write

    詳細については、 「 Azure SQL データベースの Parking サポート」 を参照してください。

• Azure のgzip形式によるコストエクスポートのサポート ：本リリースでは、gzip圧縮形式を使用した Azure のコストエクスポートのサポートが追加されました。 以前のリリースでは、非圧縮形式のみがサポートされていました。

  非圧縮形式のコストエクスポートからgzip形式に切り替えるには：

  1. Azure ポータルで、コストエクスポートを作成または更新し、圧縮形式として gzip を選択します。

  2. Turbonomic のユーザーインターフェースで、既存の「 Azure 」課金ターゲットを削除し、新しいものを追加します。 「 コスト詳細」データセットの設定ステップで、 「コストのエクスポート」 を選択し、gzip形式のコストエクスポートファイルの名前を指定します。

• AWS および Azure のワークロードにおける効果的なコスト追跡 ：本リリースでは、以下の機能が導入されました：

  • AWS EC2 VM、 AWS RDS データベースサーバー、および Azure VM に対するスケーリング操作について、 Turbonomic では、「潜在的な節約額」および「必要な投資額」のグラフに、推定実効コストが表示されるようになりました。

  • これらのスケール操作を実行すると、 Turbonomic では、「累積実現節約額」、「実現節約額」、「累積実現投資額」、「実現投資額」において実効コストが追跡されるようになりました。 これらの見解は、割引を反映した実質コストを示しており、割引対象となるワークロード全体における実現されたコスト削減額や投資額を、より正確に測定することを可能にします。

  • AWS および Azure のすべてのワークロードについて、 Turbonomic では「上位アカウント」および「コスト内訳」のチャートで実効コストを追跡できるようになりました。

  これらのグラフで費用を効果的に追跡するには、以下の手順を実行してください：

  1. AWS を使用する場合、標準のコストおよび使用状況レポート（CUR 2.0 ）を利用する際は、データエクスポート設定に以下の列を追加してください：

     • reservation_effective_cost

     • reservation_net_effective_cost

     • savings_plan_net_savings_plan_effective_cost

     • savings_plan_savings_plan_effective_cost

       CUR 2.0 の設定に関する詳細については、 「標準データエクスポートの設定 (CUR 2.0 )」 を参照してください。

     注:

     従来のCUR（CUR 1.0 ）をご利用の場合は、特に何もする必要はありません。 必要な列は、エクスポート処理の一環として自動的に追加されます。

     Azure 向け：

     1. Azure ポータルで、 FinOps のOpen Cost and Usage Specification（ FOCUS ）コストエクスポートを作成します。 FOCUSのコスト削減ソリューションは、データ処理のパフォーマンスを向上させ、ストレージおよび演算コストを削減します。 詳細については、 「コストエクスポートの使用」 を参照してください。

     2. Turbonomic のユーザーインターフェースで、既存の「 Azure 」課金先を削除し、新しい課金先を追加してください。 「コスト詳細」データセットステップで、 「コストのエクスポート」 を選択し、FOCUSコストエクスポートの名前を指定します。 詳細については、 「 Azure の請求先を追加する」 を参照してください。

  2. 「設定」＞「請求と費用」 に移動し、 「費用基準 」タブを開いて、「 実費」 を選択してください。 詳細については、 「取得原価」を参照してください。

• AWS RDS データベースサーバーのスケーリング機能の強化 ：本リリースでは、以下の機能強化が導入されています：

  • Turbonomic 現在、 CloudWatch のメトリクスを使用して、 AWS RDS データベースサーバーのI/Oスループット容量と使用率を監視しています。 パーセンタイルに基づく利用状況データを用いてパフォーマンスを分析し、最小限のコストでパフォーマンスを最適化するためのスケーリング対策を策定します。 データベースサーバーポリシーを作成することで、I/Oスループットの使用率に関するしきい値や、パーセンタイル分析に使用する観測期間をカスタマイズできます。 詳細については、 「 AWS RDS データベース サーバーのスケーリング操作」 を参照してください。

  • Turbonomic RDS データベースサーバーのスケールアクションを生成する際、 RDS の予約インスタンス（RI）の適用範囲が考慮されるようになりました。 この機能強化により、実際のコストカバー率やコスト影響評価を反映した、より正確なスケールアクションが生成されます。

    注:

    この機能を有効にするには、「 AWS 」の課金先を追加してください。

• AWS および Google Cloud におけるクラウド VM インスタンスのサポートを拡充 ： Turbonomic は、以下のクラウドVMを検出・最適化できるようになりました：

  • Google Cloud 「machine N4 」シリーズを実行しているVM

  • AWS EC2 インスタンスタイプ C8g X8g および を実行しているVM

  Turbonomic これらのVMをスケーリングして、最小限のコストでパフォーマンスを最適化したり、利用率が低いVMを一時停止してコストを削減したりできます。

• AWS および Google Cloud ボリュームのディスク役割 : ディスク役割フィルターが、検索ページでのボリューム検索時やグループページでのボリュームグループ作成時に利用可能になりました。 このフィルターは、データディスク、OSディスク、一時ディスク、または不明な役割を持つボリュームを識別します。 ディスクの役割情報は、各ボリュームのエンティティ情報チャートにも表示されます。

  注:

  Azure ボリュームについては、 ディスク役割フィルターおよびエンティティ情報チャート内のディスク役割情報が以前のリリースで導入されました。

• AWS および Google Cloud VM 向けのメモリ可用性グループ : Turbonomic は、 AWS および Google Cloud VM 向けに、 メモリ監視可用グループとメモリ監視不可用グループを自動的に作成するようになりました。 これらのグループは、メモリメトリックを報告する仮想マシンと報告しない仮想マシンを識別するのに役立ちます。 メモリメトリクスを報告しない仮想マシンについては、メトリクス収集を有効にしてください。これにより、 Turbonomic がメモリ使用量を最適化するための適切なスケールアクションを生成できるようになります。

  これらのグループは、 AWS および Google Cloud の対象について、発見サイクルごとに更新されます。 それらを表示するには、検索ページを開き、 グループを選択し、 AWS メモリ監視または GCP メモリ監視を検索してください。 詳細については、 「 AWS VM のメモリ可用性グループ」 および 「 Google Cloud VM のメモリ可用性グループ 」を参照してください。

  注:

  Azure 仮想マシン向けに、 メモリ監視利用可能グループ（ {source_name} ）およびメモリ監視利用不可グループ（Memory Monitoring Unavailable）が以前のリリースで導入されました。 それらを表示するには、 Azure のメモリ監視を検索してください。

• Google Cloud のHyperdisk Balanced High Availabilityボリュームのサポート ： Turbonomic は、Hyperdisk Balanced High Availability ボリュームを検出できるようになりました。 このガイドラインでは、可能な限り低いコストでパフォーマンスを最適化するために、既存のティア内でアタッチされたボリュームをスケーリングし、コスト削減のためにアタッチされていないボリュームを削除することを推奨しています。

• クラウドボリュームの一貫したスケーリング ：同一クラウドプロバイダーのボリュームに対して均一なスケーリングを強制するボリュームポリシーを作成できるようになりました。 有効にすると、グループ内のすべてのボリュームが自動的に同じサイズにスケーリングされ、一貫したパフォーマンスと予測可能な動作が保証されます。 詳細については、 「一貫したスケーリング」 を参照してください。

• コスト内訳チャートにおけるティアカテゴリ :クラウドワークロードのコスト内訳チャートでティアカテゴリが利用可能になりました。 このカテゴリを選択すると、総コストに最も大きく寄与しているコンピューティングまたはストレージの階層を特定できます。 この情報は、コスト要因をより深く理解し、支出を最適化するのに役立ちます。 詳細については、 階層別のコスト内訳を参照してください。

オンプレミス／ハイパーコンバージド環境のリソース管理

Turbonomic Red Hat および OpenStack Platform 17への対応を追加し、 Nutanix との連携を強化しました。具体的には、業務を中断することなく行える VM のサイズ変更操作、カテゴリの可視性の拡大、および v4 REST APIへの対応が実現されています。

• Red Hat のサポート OpenStack Platform 17 ： Red Hat OpenStack をターゲットとして設定すると、 Turbonomic は、 Red Hat OpenStack 環境内のVMおよびホスト（エンタープライズおよび通信事業者のワークロード）を検出し、最適化アクションを推奨します。 詳細については、 Red Hat OpenStack Platform をご覧ください。

• Nutanix 仮想マシン向けの、サービス停止を伴わない vCPU および vMem による容量拡大操作 （パブリックプレビュー）： Turbonomic では、 Nutanix 仮想マシンに対して、 vCPU および vMem リソースをホットプラグするための、サービス停止を伴わない容量拡大操作がサポートされるようになりました。 ポリシーを作成し、ホットプラグ機能を有効にすることで、容量拡張操作を行う際に VM の電源を切る必要がなくなり、 VM の稼働中に実行できるようになります。 詳細については、 「 Nutanix VM のダウンタイムなしでのサイズ変更」 を参照してください。

• Nutanix の VM カテゴリのサポートが拡張されました ： Turbonomic は、 Nutanix でシステム定義、内部、およびカスタム VM カテゴリを検出して表示するようになりました。 これらのカテゴリラベルを使用して、運用や組織のワークフローに合わせてVMをフィルタリング、マッピング、グループ化してください。 詳細については、 Nutanix および VM categories のサポート情報をご覧ください。

• Nutanix バージョン 4 の REST API のサポート ： Turbonomic では、 Nutanix および v4 の REST API がサポートされるようになり、これらはデフォルトで有効になっています。 ターゲットがPrism Elementの場合、 Turbonomic は引き続き v2 のAPIを使用します。 詳細については、『 Nutanix 』ドキュメントの 「API リファレンス： v4 概要」 を参照してください。

  v4 APIの導入により、ストレージプールはクラスタと1対1の関係を持つようになりました。 その結果、 Turbonomic のサプライチェーンにおけるディスクアレイエンティティ名とUUIDは、クラスタ名と整合するようになり、 「pool-」 というプレフィックスが使用されるようになりました。 ディスクアレイリソースの容量および使用率の値も、クラスタレベルのメトリクスを反映しています。

プラットフォームおよびユーザーインターフェースの管理

Turbonomic watsonx.ai を搭載した新しい AI アシスタントを導入するとともに、 VM のメンバーシップ状況の可視化や、対象を絞った診断情報の収集など、使い勝手を向上させる機能も追加しました。 また、新しいインストールオプション、 SaaS レポート接続のプロキシサポート、およびプラットフォームデータベースの機能強化により、プラットフォームと導入の柔軟性がさらに向上します。

• Turbonomic AIアシスタント : Turbonomic AIアシスタントが、 SaaS インスタンス向けに一般提供開始されました。 このチャットベースの機能は、 IBM watsonx.ai によって提供され、ユーザーが公開されている IBM ドキュメントや記事から素早く回答を見つけられるよう支援します。 高度なAIモデルを用いて関連性の高い回答を提供し、情報源へのリンクを含み、体験向上のためにチャットインターフェースから直接フィードバックを送信するオプションを提供します。 詳細については、 Turbonomic AIアシスタントをご覧ください。

• VM用の関連グループ情報チャート ： Turbonomic では、概要ページにVM用の新しい関連グループ情報チャートが追加されました。 このチャートには、選択した VM を含むすべてのグループが、グループ名とメンバー数とともに表示されます。これにより、グループ間の関連性を一目で把握でき、関連するグループへ簡単に移動することができます。 詳細については、 「基本情報チャート」 をご覧ください。

• コンポーネント単位での選択による診断機能の強化 ： Turbonomic では、メンテナンスページから診断データをアップロードまたはダウンロードする際に、特定のコンポーネントを選択できるようになりました。 この機能強化により、診断データの収集と取得がより的確に行えるようになり、トラブルシューティングや分析の効率化につながります。 詳細については、 「診断」 を参照してください。

• Turbonomic 新たにサポートされたプラットフォームへのインストール ： Turbonomic は、以下のプラットフォームへのインストールをサポートするようになりました：

  • Nutanix プリズム

    このインストールでは、 VMware vSphere の展開に使用されるものと同じ OVA イメージが使用されます。 詳細については、 「OVAイメージを使用した Nutanix Prismへの Turbonomic のインストール」 を参照してください。

  • OKE クラスター

    詳細については、 「OKEクラスターへの Turbonomic のインストール」 を参照してください。

• Turbonomic のセルフホスト型インスタンスから SaaS レポート機能への接続におけるプロキシサポート ： Turbonomic のセルフホスト型インスタンスは、プロキシサーバーを経由して SaaS レポート機能に接続し、データを送信できるようになりました。これにより、制限のあるネットワーク環境やセキュリティが強化されたネットワーク環境での導入が可能になります。

  この機能を有効にするには、以下の手順を実行してください：

  1. ケースを開くTurbonomic サポートページにアクセスし、をクリックして、プロキシサーバー経由でレポート機能に SaaS 接続し、データを送信できるよう、セルフホスト型インスタンスの認証をリクエストしてください。

  2. 認証が完了したら、インスタンスにログインし、 「設定」>「メンテナンス 」に移動して、 「 HTTP 」のプロキシセクションでプロキシ設定を行ってください。

  詳細については、 「 Turbonomic のセルフホスト型インスタンスで SaaS レポートを有効にする」 を参照してください。

• IPアドレス制限付きデータベースユーザーのサポート ： Turbonomic では、ワイルドカードホスト権限に依存するのではなく、特定のIPアドレスに制限されたプラットフォームデータベースユーザーの作成および管理が可能になりました。 この機能強化により、データベースへのアクセスを既知の送信元IPアドレスに限定する必要がある、厳重なセキュリティ環境での導入が可能になります。

• Ed25519 認証機能のサポート ： Turbonomic では、より強力で安全なデータベース認証を実現するため、 MariaDB Ed25519 認証プラグインのサポートが追加されました。 このプラグインは最新の楕円曲線暗号を採用しており、従来の mysql_native_password 方式に比べてセキュリティが向上しています。 詳細については、 「 Ed25519 の認証サポート」 を参照してください。