クラウド コンピューティング環境における容量管理

グリーン氏は、多くの人と同様に、コロナウイルスの流行中は自宅からリモートでしか仕事をすることができないと語った。彼は IT チームを率いて、統合 VMware 環境でデータベース クラウド容量管理を実行しています。同氏は、パブリッククラウドプロバイダーが直面している容量管理の問題は、Greeneideas が解決しようとしている問題と似ていると述べた。その結果、同社の IT チーム メンバーはさまざまなオンライン ベンダー カンファレンスに出席し、オンライン トレーニングを受けて、クラウド コンピューティングの世界で同様の問題が発生しているかどうか、また分析とプロセスを改善するためにどのような手法や教訓を学べるかを理解しました。

[[373486]]

グリーン氏は、クラウド プロバイダーが顧客をどのように見ているかを理解し、自身の豊富な業務経験を組み合わせることで、容量管理の課題を特定し始めました。したがって、組織がプライベート クラウドを導入すると、特定のコンピューターの容量が不足している、またはパブリック クラウド環境でコストが増大していると見なされる可能性があります。

Greene がクラウド コンピューティング環境の容量管理に関して提供する主要なテーマは次のとおりです。

• すべての利害関係者がそれぞれの視点から理解できる容量モデルを構築する必要があります。
• アプリケーションを導入するチームは、容量を構成するときに何が必要なのかを実際には把握していない可能性があります。
• 要求の厳しいアプリケーションは別の方法で処理する必要があります。
• クリーニングは自然に行われず、容量が無駄になります。
• IaaS、PaaS、およびその他のアプリケーションが実際に提供するものについては、さまざまな視点があります。

以下では、これらの主要なトピックについてさらに詳しく説明します。

容量モデル

最初の主要テーマは、すべての関係者が理解できる容量モデルを開発する必要性でした。財務担当者であっても、アプリケーション システム管理者であっても、使用状況チェックのために 150 台のサーバーまたは 200 個のコンテナーのリストを提供するように求められても、有効な結果は得られません。これはなぜでしょうか?ホスト名やコンテナ名（またはサービスインスタンス）を理解している人はほとんどいないと思います。試行錯誤の末、Greene の IT チームは、サーバーおよびコンテナー リストから駆動される容量モデルを強化し、構成管理データベース (CMDB)、データベース、およびオペレーティング システム監視ツールからのデータを統合しました。 IT チームは、ネットワーク上のリソースを使用するすべての場所から情報を収集し、容量がどのように使用されているかを確認します。したがって、アプリケーション チームと話をするときは、それらのサーバー上のデータベースと、それらのデータベースのどのバージョンが使用されているか (リスク要件を満たすために移行されたレガシー データベースがどれであるかがわかる) を特定すると役立ちます。また、コストに関係する人々と話をするときは、請求書を生成するリソース (ディスク、CPU、メモリなど) から始めて、それを関係するさまざまなアプリケーション チームと使用中のバージョンにマッピングします。

こうした各ケースにおいて、IT チームは懸念事項を把握し、それをアプリケーションやユーザー コミュニティにマッピングできます。これにより、それらがまだ必要かどうかを評価し、Windows 2000 の旧バージョンからの移行など、変更が必要な箇所を把握できます。基本的に、使用されたリソースを説明する明細付きの請求書ではなく、所有しているリソースを理解するのに役立つカスタマイズされたレポート セットを提供するモデルになります。

ニーズの評価

グリーン氏は、次に発見したテーマは、アプリケーション チームが初めてクラウド環境に移行したり、新しいアプリケーションを構築したりするときに、自分たちが本当に望んでいるものが何なのかわかっていない可能性があるということだと述べました。彼らは通常、ユーザーを感動させるような優れた機能やアイデアを持っていますが、CPU の数やメモリの使用量などの質問に対しては、通常、ベンダーに問い合わせて、自社製品をより良く実行することを望んでいます。インフラストラクチャ部門はコストを節約し、利用率を向上させるプレッシャーにさらされていますが、最終的にはクラウド コンピューティング サービスの導入を選択します。彼らが直面している課題は、アプリがどの程度受け入れられるか、次にどのような機能を思いつくかについて、多くの仮定や推測があるということです。これにより、パフォーマンスのニーズを満たすために別の運用環境への移行が必要になる状況が発生することが多く、アプリケーション チームとインフラストラクチャ チームの両方で多大な時間と労力が必要になります。

多くのチームは、1 つのアーキテクチャを構築すればすべてのアプリケーションに適合できると想定していますが、大企業のほとんどは幅広いポートフォリオを持ち、80/20 ルールまたは 90/10 ルールに従うことがよくあります。通常、ビジネスを推進したり、大規模なユーザー ベースを保有したり、より高いパフォーマンスを必要とするアプリケーションは少数です。したがって、ほとんどのアプリケーションは、ユーザー向けに設計されたコスト効率の高い高密度環境に適応できますが、万能のソリューションを採用するのではなく、より高性能な環境や利用可能な選択肢を要求することが重要です。

掃除は自然には起こらない

もう 1 つのテーマは、クリーンアップが自然に行われず、容量が浪費されるということです。パブリック クラウドでは、これは通常コストの増加となりますが、プライベート クラウドでは、容量不足や予期しない増加として現れることがよくあります。ほとんどの場合、開発者はタスク用にシステムを自動的にプロビジョニングできますが、容量が不要になったときにクリーンアップする責任を負う人はいません。そのため、リソースを必要とする特別な開発プロジェクトを完了したとき、またはアーキテクチャやリスクの標準を満たすためにデータベース、Web サーバー、またはオペレーティング システムの次のバージョンに移行したとき、誰も古いリソースを放棄したくありません (おそらく、新しいリソースが実際に効果的であるかどうかを理解したいと思うでしょう)。これに注意を払わないと、組織がクラウドで運用する期間が長くなるにつれて、無駄なデータが蓄積されていきます。ここで重要なのは、料金の支払い責任者に対して、プライベート クラウド リソースを使用していることと、それに関連するものを示して正当化し、適切な決定を下せるようにすることです。

要求の厳しいアプリケーションに対応

最後に、多くの組織がクラウドへの移行を開始すると、従来のデータセンターが十分に活用されていないこと、および非効率的な IT 機器によって無駄が生じていることが理解されます。これに敏感に反応して、ローカル クラウド コンピューティング ベンダーは、同じリソース (CPU、メモリ、または IO 帯域幅) を複数のアプリケーションまたは仮想マシンに同時に割り当てる方法を見つけました。これらのリソースを共有するアプリケーションがそれらを同時に使用する可能性は低いと考えられます。

通常の状況では、これは、ユーザーが Web から送信されたリクエストに 1 日以内に迅速に応答できる Web サーバーなどに適したオプションです。ただし、データベース サーバーが一部のクエリを処理するのに数秒かかる場合があり、データベースのアプリケーション使用量が急増する傾向があるため、これはデータベース サーバーにとって好ましくない可能性があります。ここでの課題は、誰もがシステムに CPU またはメモリの要求を出すと、システムがスワップして、すべての時間をプロセスをメモリ内外に移動させることに費やしてしまうか、要求に追いつけないほどプロセスが積み重なってしまうことです。したがって、この例では、ベンダーのラボ環境に基づく一般的なガイドラインを使用する代わりに、各アプリケーションまたは製品を分析し (たとえば、データベースは起動時に大きなメモリ領域を割り当てて解放しないことが多く、過剰にコミットされるとスワップが発生する可能性があります)、このアプリケーションに対して適切な決定を下すことができます。

IaaS、PaaS、XaaS は実際に何を提供するのでしょうか?

最後のテーマは、IaaS、PaaS、XaaS が実際に何を意味するかについて、人によってさまざまな考えがあるということです。アプリケーション チームは、クラウド コンピューティングで何ができるのかについて多くの記事を読んでおり、クラウドに移行すると、何らかの形でより多くの機能とサービスが得られると考えています。グリーン氏は、組織はシステムに組み込まれ設計されたものを手に入れるだろうと述べた。組織の要件を満たすバックアップから、フェイルオーバーの自動化、ファイアウォールのセキュリティまで、これらはすべて固定されたものではないため、適切なベンダー ツールを使用して計画および実装する必要があります。ほとんどのクラウド コンピューティング プロバイダーは、オペレーティング システム、ディスク速度、サポートされるアプリケーション、さらには設定に関して、多くのオプションと可能性を提供しています。組織にとっての課題は、多数の選択肢を検討し、それを組織のニーズを満たし、ベンダーの環境とうまく連携する構成のリストに変換することです。

結論は

これらは、容量の観点からパブリック クラウドとプライベート クラウド全体に適用されるテーマの一部です。組織が分析を実行して容量の問題がどこにあるのかを確認できるようにするには、すべての運用環境を調査してモデル化する必要があると私は考えています。実際には、容量の問題には 2 種類あることに注意することが重要です。1 つ目はパフォーマンスです。組織が特定のアプリケーションが現在の場所には大きすぎると判断した場合 (より適切な運用環境に移行する必要がある) です。 2 つ目は、全体的な容量管理です (これにより、組織が特定のコンテナまたは VM に対して十分なリソースを確保できるようになります)。一つの問題が解決すると、また別の問題を解決しなければならないため、これは終わりのない分析になります。このモデルは、組織が問題を特定し、環境内のツール（コンテナの移動、新しいコンテナへの移行、または新しいアーキテクチャへの移行など）を使用して、運用環境が将来に備えられるようにするのに役立ちます。