皆さん、こんにちは。LogicMonitorのセールスエンジニアリング担当シニアマネージャー、ブランドン・マッカーチェンです。
本日はロン・ロン・ウェドル氏をお迎えしています。いくつかお話をさせていただきます。まずは簡単な自己紹介の後、4つの移行における統合型可観測性、そして可観測性によるVMwareのモダナイゼーションについてお話しし、その後、簡単なパネルディスカッションを行います。
本日は、VMware経由、VMwareからAWS、オンプレミスからクラウド、あるいはハイブリッド環境への移行など、移行プロセスにおける可観測性向上にLogic Monitorがどのように役立つかについて、より具体的にお話しします。LogicMonitorは、移行前、移行中、移行後のあらゆる段階で活用できるツール、あるいはプラットフォームです。
計画段階、段階、情報収集、そしてその過程は複雑で時間がかかります。見落としや見落としが生じ、そして何よりも重要なのは、負債によるテクノロジー負債が発覚してしまうことです。
当社では、NetScans やアクティブ検出などの機能を活用してこれらの取り組みを支援し、お客様が移行を進めながら、新旧の環境を検出できるようにしています。
移行の実行中は、ロジック モニター、すぐに使用可能なアラートしきい値を利用して既知の不良状態に注意を喚起するプロアクティブな呼び出しを実行できるほか、サービス インサイトを利用してそれらの根本原因を検出し、その手がかりを提供することもできます。
VMwareへの移行には、当然のことながら、移行を進める中で調整が必要な多くの要素が存在します。移行前と移行後の両方の状況を把握しておくことで、最短で移行を完了することができます。
先ほど申し上げたように、計画段階を進めていく中で、アクティブディスカバリを活用することで、旧環境と新環境のインフラストラクチャの同じ側面を監視し、維持できるようになります。移行後には、より明確な状況を把握し、それに応じた対策を講じることができます。
先ほども述べたように、ハイブリッドの全体像を把握するために、Resource ExplorerやLogicMonitorなどのツールを活用し、コスト使用率の側面から、LogicMonitorの優れたAWSサービスカバレッジを活用して、ハイブリッドの可観測性の全体像を把握できます。また、AWS環境とVMware環境を比較することも可能です。前後の比較、新旧のテクノロジーの比較など、非常に有益な情報が得られます。同じインフラストラクチャが稼働していて、以前の環境よりもパフォーマンスが向上している、あるいは向上していない場合でも、できれば向上していることを確認できます。LogicMonitorを活用して、その状況を把握し、前後の段階の両方を維持する必要があります。
これらは、LogicMonitor からリンクされている、または LogicMonitor から監視されているいくつかのサービスです。この後、Ron と話して、これらの移行に関する顧客との取り組みについていくつか質問します。
よし、ロン。質問の準備ができたら、早速始めましょう。
いいね。
わかりました。あなたの経験からすると、お客様がワークロードを VMware から AWS に移行する際に遭遇する最も一般的な課題は何でしょうか？
最大の課題の一つは、プラットフォームやテクノロジーが異なることだと思います。そうですよね？彼らはオンプレミスのワークロードから移行しており、そこでは長年同じインターフェースを使ってきました。そのため、AWSでは様々なものが異なる場所にあるのです。
お客様が抱える課題の一つは、可視性の欠如です。そうですよね？どこを見ればいいのか、どんな指標を取得すればいいのか分からないのです。
そのため、データが失われたり、パフォーマンスが低下したり、インスタンスが2つなどサイズが大きすぎたり小さすぎたりする可能性があり、結果としてコストも高くなります。ワークロードを適正化しないと、非常に高額になる可能性があります。Logic Monitorのような可視化ツールがなければ、私たちにとって非常にコストのかかる作業になる可能性があります。
そうですね。移行によってお客様が遭遇する可能性のある、一般的なビジネスへの悪影響にはどのようなものがありますか？
ええ。つまり、稼働時間と費用の問題ですね。テクノロジーの変化はあります。規模が大きすぎたり、費用がかかりすぎたり、あるいは規模が小さすぎたりして、オンプレミス環境で顧客が慣れ親しんでいた適切なパフォーマンスとエクスペリエンスを提供できなかったりすると、ビジネス、ひいては顧客に直接的な悪影響を与える可能性があります。
VMwareから移行するお客様にとって、どれだけの新しいテクノロジーが明らかになるのでしょうか？先ほど申し上げたように、初期段階では、お客様は「プラットフォームのこの部分には触れていなかったから改善されなかったんだ」と気づき、技術的負債に気づきます。そして、移行後には全く新しい方法で機能するのを目の当たりにします。あなたもそのような経験をしたことがありますか？
VMware環境がオーバーコミットでどのように動作するかを実際に目の当たりにしてきました。時には、ユーザーが気づいていないパフォーマンスの低下が発生することがあります。EC2に移行し、すべてが独立したEC2インスタンスとして実行されるようになると、パフォーマンスと安定性が向上し、スケールアップやスケールダウンもより迅速に行えるようになります。
恐ろしいです。
実際に、移行中および移行後に顧客が直面する苦痛を軽減するための最も一般的なソリューションや方法は何でしょうか?
そうですね、方法論的に言えば、移行の計画を立てることです。そうですね？一般的にAWSでは、評価、モビライズ、そして移行という流れで進めています。評価とは、オンプレミスのワークロードと環境をすべて把握し、お客様のクラウド導入準備状況を評価し、経営陣の承認を得て、すべてのチームの準備が整っていることを確認することです。もしそうでない場合は、モビライズに本格的に取り組みます。テクノロジーだけでなく、プロセスに関わる人材もモビライズし、移行へとつなげていくのです。
そうすることで、実際の移行作業がかなり楽になります。そうでしょう？事前に作業しておくこと。努力した分だけ成果が得られます。
適切な評価を行い、あらゆる可視性を確保する必要があります。そして、移行中に問題となるのは、何がどこにあるのかがわからないことです。オンプレミスからEC2にVMを移行する際に、そのフェンスの両側の可視性がないのです。何が残されるのでしょうか？
クラウド内のパフォーマンスにどのような影響があるのでしょうか？ すべてを確認するには複数のツールを使い分ける必要があります。
絶対に。
移行の準備プロセス、ドキュメント、要件、依存関係について教えてください。お客様は移行の準備にどれくらいの時間を費やしていますか？
そうですね、答えは「状況によって異なる」です。顧客の成熟度によって決まります。例えば、既にクラウドを導入していてハイブリッドなアプローチを採用しているのか、それとも全くの新規移行なのか、といった点です。
残念ながら具体的な時期をお伝えすることはできません。環境はそれぞれ異なるからです。数千台の仮想マシンを運用しながらも迅速に移行できるお客様もいれば、数百台の仮想マシンを運用しながらも、何らかの理由でアプリケーションの構築方法や業務システムとの連携方法に問題が生じ、処理速度が遅くなってしまうお客様もいらっしゃいます。
つまり、これらすべての要件と依存関係を収集するには膨大な作業が必要だと言えます。お客様によっては、既に準備が整っている場合もあれば、アプリケーションの依存関係マッピングのためのあらゆる検出作業、あるいは既存のワークロードに関する洞察を得るためのツールが必要な場合もあるでしょう。
思い切って飛び込んでみてどうなるか見てみたらダメだって？それは最善の策じゃないよね？
できます。ただ、必ずしも彼らが期待するようなビジネス成果が得られるとは思えません。
それがまさに私たちが求めているものです。ビジネスにプラスの影響を与える、良い結果をもたらすものですよね？では、顧客の移行シナリオ、そしてプロジェクトのタイムラインや技術的な詳細に関して、どのような違いがあるのか​​教えていただけますか？私の記憶が正しければ、これはあなたのお気に入りの質問だと思います。
移行シナリオについては、やはり状況次第という結論になりますね。プロジェクトのタイムラインや技術的な詳細に関しては、お客様ごとに状況が異なるため、具体的な回答を出すのは難しいかもしれません。既存のワークロードに関する洞察や知識のレベルもそれぞれ異なるからです。タイムラインについては、そうですね。正直、これについては明確な答えが思いつきません。
ええ。タイムラインというのは、ご存知の通り、準備にどれだけの時間を費やすか、あるいはシステムをどれだけ熟知しているかによって大きく左右されます。先ほども申し上げたように、そういった変数に大きく左右されると思いますし、あとは、どれだけ飛び込みたいかという気持ちも関係します。
と言うことをターゲットとするチームがあります。
そうですね、その時点で作業を先に進めないと、タイムラインが延びてしまう可能性があります。例えば、第2回ではAWSの「評価してから移行する」という手法について説明しましたよね？プロジェクトのその部分に十分な時間を費やさなければ、評価に時間をかけなかったために作業をやり直すことになり、移行にかかる時間は飛躍的に長くなります。
ええ。以前比較していただいたのが良かったと思います。小規模な環境で6ヶ月かかったのと、大規模な環境で3ヶ月かかったのと。分かりますか？そして、その違いは完全に、それぞれの準備の仕方によって決まるんです。
まさにその通りです。ええ。彼らは既に計画と対策を練っていましたし、実際、AWSをある程度活用していました。ですから、繰り返しになりますが、技術に慣れるためのレベルアップに費やす時間はそれほど多くありませんでした。
確かにそうです。分かりました。ではもう一つの質問ですが、移行の実行中に予期せぬ事態が発生した場合、通常はどのような対応をされるのでしょうか？
ええ、それは2つの方法があります。電源をそのまま投入するか、フェイルバックするかのどちらかです。そうですよね？
一般的に言えば、これは顧客の変更期間、移行のタイムライン、バックアップ プランに関係します。
評価と展開のフェーズで、例えば移行時に問題が発生しなかったり、DNS以外のIPアドレスの競合が発生したりした場合にどう対処するかについて、理解と事前計画を立てておくことが重要です。どのように解決するのでしょうか？事前に計画を立てておけば、こうした予期せぬ事態のリスクを回避できます。しかし、事前に時間をかけて準備しておかなければ、試行錯誤を繰り返してしまうことになります。そうですよね？
確かにそうですね。では、VMware から AWS サービスへの組織的な移行において、人的要因はどのように影響するのでしょうか？
おそらくこれが最大の要因でしょう。クラウドでの運用には、これまでとは異なる考え方がありますよね？必要な時にいつでもオンデマンドで容量を確保できます。特定のサービスをアプリケーションから切り離すことができるのです。
VMwareは豊富な実績を誇っています。そうですか？彼らはオンプレミスのハイパーバイザーのマーケットリーダーであり、何十年にもわたってその地位を維持してきました。そうですか？そうです。つまり、知識とトレーニングといった人的要因が重要であり、それが非常に大きいのです。
これは間違いなく移行の要因となり、それらの人々がレベルアップする間、AWS への移行が遅くなる可能性があります。
そして、それに加えて、本当にごめんなさい。
行く。
どうぞ。いいえ。大丈夫です。
先ほどおっしゃっていたように、VMware の定年退職したエンジニアが入社してくると、皆さんはおっしゃっていましたよね。皆さんには、彼らがリンクを学ぶためのプログラムがあるんですよね。
ええ、私たちはこれが問題だと認識したので、包括的な学習パスを用意しました。つまり、5年、10年、15年とvSphereを使っている人を、AWSで短期間でレベルアップさせるにはどうすればいいかということです。そこで、誰でも利用できる、vSphereで「こう」と呼ばれる機能、AWSで「こう」と呼ばれる機能を備えた、学習パスを作成しました。
vSphere ではこれがその方法です。AWS でもこれがその方法です。これにより、面倒な作業が軽減され、お客様が AWS に移行する際に、より迅速に、より優れたエクスペリエンスを提供できるようになります。
監視と非常に似ています。私たちは常に監視を行っており、他の監視ソリューションと同じ専門用語を使っているので、翻訳する必要があり、そのためのオンボーディングプロセスを提供しています。そう言っていただけると本当に嬉しいです。では、リソースのプロビジョニングやコストの最適化に関して、VMwareとAWSの主な違いは何でしょうか？
ええ。先ほど、適正化と、先ほども触れましたが、オンデマンドのキャパシティについて少し触れました。オンプレミスで運用する場合、重要な点の一つはキャパシティです。これを図にすると、階段状の曲線を描くことになりますよね？過剰プロビジョニング、不足プロビジョニング、過剰プロビジョニング、不足プロビジョニングの繰り返しです。また、コンピューターストレージやネットワークなど、物理的なハードウェアの購入と入手には時間がかかります。つまり、常に過剰プロビジョニングと不足プロビジョニングの間を行き来している状態なのです。
一方、クラウドでは、あらゆるものを適切なサイズに調整でき、キャパシティもオンデマンドで利用できます。そのため、グラフは階段状ではなく、より緩やかな曲線へと変化していきます。オンプレミスとAWSインフラストラクチャの最大の違いの一つは、必要な時に必要なものだけを利用できるという点です。一方、設備投資は、時間の経過とともに使い果たさざるを得なくなります。パフォーマンスの問題やハードウェア障害が発生した場合、必要な時にキャパシティが確保されるまで待たなければなりません。
そうですね？オンプレミスの高可用性インフラストラクチャを設計する際には、そうしたコストを考慮する必要があります。しかしAWSでは、そのコストは私たちが代わりに処理します。そのため、お客様はワークロードの最適化に集中でき、障害発生時に備えて余分なインフラストラクチャを用意する必要がありません。
はい。皆さんお時間をいただきありがとうございました。
ええ。そして、ここに呼んでいただいて、楽しい会話をさせていただき、ありがとうございます。」