【てくさぽBLOG】InstanaとTurbonomicを連携したリソース最適化検証

こんにちは、てくさぽBLOGメンバーの和田です。昨今、システムの複雑化やハイブリッドクラウドなど複数環境の運用などで運用にかかる負荷が増加しております。しかし従来の運用管理ツールだけで解決するのは難しくなってきています。そんな中、運用の高度化・効率化のため、アプリケーションパフォーマンス管理、アプリケーション・リソース管理、そしてAIの技術を採用した「AIOps」製品が注目を集めています。弊社はIBMのAIOps製品の拡販に注力しており、かつ、私たち自身で製品のことを知りパートナー様に商材をご紹介したいと考えていることより、IBMのAIOps製品を組み合わせて社内検証を実施しましたので、今回から3回にわけてご紹介したいと思います。まず1回目はInstanaとTurbonomicを組み合わせてリソース最適化の検証を実施しましたので、その内容と結果、苦労した点などをご紹介します。

InstanaとTurbonomicの概要と連携させることで可能になること

Instanaは、アプリケーションモニタリングの分野で高い評価を得ているツールです。アプリケーション呼び出し時のコールリスエストのトレーシングやCPU、メモリといったメトリクス情報収集を通じて、アプリケーション・インフラの状況をリアルタイムで可視化します。特に自動化された監視設定や障害発生した際の関連情報を分析し一目で原因を特定できます。 Turbonomicは、インフラリソースおよびアプリケーションの効率的な配置・利用を最適化するプラットフォームです。リソースの過剰利用や不足をリアルタイムで把握し、必要な改善アクションを推奨または自動実行します。詳細な機能についてはそれぞれBLOGで紹介しておりますので下記をご確認ください。

連携させることで得られる効果

InstanaとTurbonomicを連携させることで、以下の効果が得られます。

リアルタイムモニタリングの強化: Instanaを通して詳細なリソース使用状況を把握し、Turbonomicがそれを基に適切なリソース割当を推奨。
自動リソース最適化: 必要に応じてTurbonomicが推奨するアクションをInstanaから直接実行可能。
アプリケーションとインフラの統合可視化: 両製品の連携により、アプリケーションのパフォーマンスだけでなく、それを支えるインフラ（仮想マシン、コンテナ、クラウド）の状態までを統合的に可視化できます。

検証内容

今回の検証では、以下の環境・シナリオを設定しました。

環境構成

Turbonomic： IBM Cloudのベアメタルサーバ（Hyper-V）上にデプロイ。本環境で使用するAWSアカウントをターゲット追加。
Instana： SaaS形式で利用。
監視対象： AWS EC2インスタンスA（instana03、インスタンスタイプ：m7a.medium）にInstana agent導入。
アプリケーション： AWS EC2インスタンスAにサンプルwebアプリケーションのRobot Shopを導入。 Instana上ではInstana03_robot-shopとして登録。

【参照】GitHub

負荷ツール： AWS EC2インスタンスBにJMeterを導入。構成については下記の通り。

検証内容

EC2インスタンスBのJmeterからEC2インスタンスA上のアプリケーションへ同時多発webアクセスを行いリソース使用率の負荷をかける。負荷は下記図の通りスレッド数5000、ramp-up期間は1秒、持続時間は3600で設定

Turbonomicがリソース使用率を検知し、インスタンスタイプ変更のアクションが推奨されることを確認する。
Instanaで推奨されるアクションを実行し、実際にEC2インスタンスAのリソースが拡張されるかを確認をする。
インスタンスタイプ変更後も同量の負荷をかけ続けリソース使用率が問題ないか確認する。

検証結果

検証開始前のTurbonomicの状況です。左側の仮想マシンの箇所は緑となっておりインスタンスタイプは赤枠で囲われているm7a.mediumとなっています。

また、Instana上ではインスタンスタイプ変更のアクションは表示されていません。

この状態から負荷を掛けていきます。負荷を掛けていくことで、下記図の通り、検証開始前は安定したリソース使用率でしたが、負荷をかけることで仮想CPUや仮想メモリへの負荷を確認できます。また、点線で囲んでいる部分についてはTurbonomicが推測する今後のリソース使用率になります。左側の仮想マシンという部分についても赤くなっております。

Turbonomicが不足するリソースを検出し、最適なインスタンスへの変更を推奨しています。

Turbonomicで推奨されたアクションがInstanaで推奨アクションとして表示されます。

Instana上でアクションを実行します。

実行後Turbonomic上でインスタンスタイプが変更されていることを確認できます。

また、インスタンスタイプ変更後も負荷を掛け続けた結果、インスタンスタイプ変更後にリソース使用率が低下していることを確認できました。 ※★のタイミングでインスタンスタイプを変更しています。

この結果、リソースの過不足を迅速に解消し、安定したアプリケーション運用が可能であることを確認しました。検証の結果以下を確認することができました。

負荷シミュレーション時、EC2インスタンスAのCPU使用率やメモリ使用率の上昇を可視化。
InstanaにTurbonomicの推奨アクションが表示され、Instana上でアクションを実行することでインスタンスタイプが変更され、負荷が下がる過程を可視化。
インスタンスタイプ変更後も同量の負荷をかけつづけリソース使用率が問題ないことを確認。

苦労した点

今回の検証を進める中で以下のような課題に直面しました。

TurbonomicがデプロイされているISOイメージから仮想サーバを作成する方式なのですが、Hyper-V用ISOイメージがなく、VMware用のISOイメージから作成しようとしても失敗したためIBMサポートへ問い合わせを行いました。
仮想サーバをデプロイしたあとTurbonomicコンソールへアクセスしようとしたところ、Hyper-V内のネットワーク設定が誤っておりインターネットからアクセスができませんでした。
TurbonomicからAWSアカウントのターゲット追加する際にDNS設定が正しく設定されていなかったため、正常に追加登録が完了しませんでした。
InstanaとTurbonomicをスムーズに連携させるための設定確認とチューニングに時間を要しました。特にInstana側からTurbonomic側への設定追加の際に、設定項目がドキュメントからは読み取れず、設定内容が間違っていたためサポートへ問い合わせを行い解決しました。
負荷テストを行う際に最初はWebアプリケーションに付随するスクリプトで実施していましたが、インスタンスタイプ変更に伴う再起動が発生するためJMeterで実行するワークロード設計に工夫が必要でした。
Turbonomic上で推奨アクションがあらかじめ表示されている場合、負荷をかけることで推奨アクションが更新されると想定していましたが、更新されなかったため想定していた挙動となりませんでした。
インスタンスAに負荷を与えても推奨アクションが表示されなかったため、ポリシーの設定変更に時間を要した。特に観測期間を短くし、積極性をあげることで短い期間内での負荷に敏感になるように設定しました。
観測期間の最低値が7日間のため、一度推奨アクションが表示されるまで負荷を掛け続けインスタンスタイプを変更しないでおくと、推奨アクションが継続して表示されてしまい、推奨アクションが表示されなくなるまで時間がかかってしまいました。

さいごに

InstanaとTurbonomicを連携させ、AWS EC2インスタンスのリソース最適化の自動化を検証しました。今回の検証ではTurbonomicをオンプレミスに導入しましたが、SaaSでの提供もありますので今回の検証で苦労したTurbonomicの構築といった手間を省略することも可能です。 InstanaとTurbonomicを連携させることで、操作時にコンソールを移動せずとも実行は一つのコンソールで実施できるようになります。リソース不足の解消やアプリケーション性能の安定化とともに、現場での手動作業を削減できによる運用の高度化・効率化が期待されます。