プライベート クラウド 101: ビジネスのスピードに合わせて動く

クラウドによってapplicationの開発と展開が変革され、組織の柔軟性の向上、プロセスの自動化、市場投入までの時間の短縮が可能になりましたが、いくつかの大きな疑問が残っています。 組織が取り組むべき最も重要な課題の 1 つは、クラウドが提供するよりスマートなツールと無制限のスケールを最大限に活用する方法です。 企業がクラウドのメリットを活用する方法の 1 つは、独自のプライベート クラウドを導入することです。プライベート クラウドは、俊敏性を促進しながら組織がインフラストラクチャの制御を維持し、applicationsとデータをより安全に保護できるコンピューティング モデルです。

プライベート クラウドを導入する主な利点としては、インフラストラクチャのセルフサービス、スケーラビリティ、マルチテナントなどが挙げられます。 プライベート クラウドの仕組みと、それがビジネスにどのようなメリットをもたらすかを詳しく説明する前に、それぞれを簡単に見てみましょう。

セルフサービスの概念は、プライベート クラウドの導入を推進する重要な要因の 1 つです。 セルフサービスにより、組織は追加の物理ハードウェアをインストールすることなく、現在利用可能なインフラストラクチャを使用してapplicationsを展開できます。 代わりに、チームはリソースをリクエストし、手動による介入なしにすぐにプロビジョニングすることができます。

プライベート クラウド インフラストラクチャのもう 1 つの中核機能は、スケーラビリティの向上です。 つまり、コンピューティングやストレージなどの追加リソースが必要になったときに、それらのリソースがすぐに（多​​くの場合は自動的に）利用可能になり、applicationの容量を増やすことができるようにapplicationを設計できるということです。

最後に、マルチテナントとは、applicationが、使用するリソース上で唯一のテナントであるかのように動作できることを意味します。 言い換えれば、他のapplication開発チームとリソースの変更を調整する必要はありません。 これらのリソースにアクセスすることで、application開発チームは互いに独立して、またインフラストラクチャ チームからも独立して、反復して変更を加えることができます。

プライベート クラウドの中心にあるセルフサービス プロビジョニングの概念は、インフラストラクチャ リソースが抽象化または仮想化されているため、オンデマンドで利用できることを意味します。 開発チームが GUI と API を通じて独自のコンピューティング、ストレージ、ネットワークをプロビジョニングできる場合、物理インフラストラクチャのプロビジョニングのペースに左右されずに、より迅速に革新と開発を進めることができます。 自動化ツールは、仮想リソースを物理リソースから抽象化することで、開発チームの俊敏性を高めます。

このアプローチを、従来のデータ センターでの典型的な時間と労力を要する展開プロセスと比較してください (図 1 を参照)。 application所有者は要件を把握し、IT アナリストと協力して既存のapplicationを変更したり、新しいアプリケーションを導入したりします。 開発とテストが完了したら、アナリストはインフラストラクチャに導入するための一連の変更を準備します。 ほとんどの変更には、共有サーバー、OS インスタンス、applicationインスタンス、ファイアウォール、ストレージなどの共有リソースが関係します。 変更による意図しない影響を軽減するために、インフラストラクチャに対するすべての変更を管理および承認する変更諮問委員会 (CAB) が存在します。 承認されると、運用チームが変更を加えます。

ただし、多くの IT 運用では、数百または数千の保留中の変更要求が同時に発生しており、CAB はこれを管理して悪影響が生じないようにする必要があります。 たとえば、ファイアウォールのセットが寿命に近づいており、サポートが終了する前に新しいモデルに交換する必要があるとします。 同時に、外部ベンダーが既存のプロトコルのサポートを削除し、ファイアウォール構成の変更が必要になるため、別のグループがapplicationを別のプロトコル セットに変更しています。 同時に、ビジネス カスタマーは IP アドレスを変更しており、ファイアウォール構成の変更が必要になります。 安全のため、これら 3 つの変更 (ファイアウォールの置き換え、applicationプロトコルの変更、顧客の IP アドレスの変更) は同時に実装しないでください。 CAB は、このような変更を調整し、変更が安全かつ効果的であることを保証する責任を負います。 組織のセキュリティを確保するために取り組んでいる一方で、CAB は変更を促進する際のボトルネックになることもあります。

プライベート クラウド環境では、コンピューティング、ネットワーク、ストレージを仮想化することで、この変更プロセスを改善できます。 すべてのコンポーネントが仮想化されると、変更を行うには物理コンポーネントではなく、仮想コンポーネントを更新するだけで済みます。 コンポーネントは仮想化され、分離されているため、他のapplicationsに影響を与えることなく、 1 つのapplicationを変更または追加できます。 プロビジョニング コンポーネントでは物理的な介入は必要なくなり、仮想リソースのみを変更する必要があります。 自動化ツールを使用すると、開発チームはインフラストラクチャ チームの関与なしに独自のリソースをプロビジョニングすることもできます。

セルフサービス (ま​​たはソフト) プロビジョニングにより、applicationインスタンスだけでなく、application配信コントローラ (ADC) によって提供されるすべてのセキュリティおよびapplication配信サービスも、インフラストラクチャ チームの介入なしに作成および削除できるようになります (図 2 を参照)。 各チームは独立して作業できるため、CAB を通じて変更を調整する必要はありません。 代わりに、ポリシーによって展開方法が推進され、チームは運用から独自の仮想インフラストラクチャを取得し、独自の速度で展開します。

セルフサービス プロビジョニングのプロセスをさらに自動化するために、コンピューティング、ネットワーク、ストレージ、ADC 設定などのリソースのコレクション全体を、ソース コードリポジトリに保存できるテキスト ファイル内のテンプレートとして指定できます。 テンプレートには、スタックと呼ばれるリソースのコレクションとその構成の定義が含まれています。 この「コードとしてのインフラストラクチャ」アプローチにより、あらゆる展開を簡単に繰り返すことができます。 テンプレートを使用すると、展開が高速化され、エラーが削減されるだけでなく、スタックをテスト環境内のユニットとして評価できるため、テストも簡素化されます。

自動化を促進する次のステップは、弾力性、つまり人間の介入なしにリソースを自動的にソフトプロビジョニングすることに重点を置きます。 applicationが複数のインスタンスにまたがってスケーラブルな場合は、負荷に応じてインスタンス数を自動的に増減できます (下の図 3 を参照)。 弾力性により、ソフト プロビジョニングは、API を使用してリソースを自動的にプロビジョニングおよび削除できるレベルにまで引き上げられます。 弾性素材が着用者のニーズに合わせて伸びたり縮んだりするのと同様に、弾性リソースはapplicationのニーズに合わせて拡張したり収縮したりします。 この柔軟性により運用効率が向上し、applicationsを過剰にプロビジョニングすることなく、常に最高レベルで実行できるようになります。  

プライベート クラウドの利点は、他のチームから独立して、迅速に変更を加えることができることです。 従来のデータ センター環境には、多くのコンポーネントとリソースの相互依存関係があります。 ただし、プライベート クラウドでは、すべてのリソースを 1 つのapplication専用にすることができるため、applicationチームは他のapplicationsに影響を与えることを心配することなく、完全な制御を行うことができます。

仮想化されたコンピューティング、ネットワーク、ストレージ、および ADC リソースによってこれが可能になります。 クラウド環境では、リソースがすぐに利用可能で、application専用であるかのような錯覚が生じます。 CAB は必要なく、他のチームやapplicationsと構成を調整する必要もありません。 マルチテナントにより、各applicationチームは、他のapplicationチームの速度や取り組みから切り離されて、ビジネスに適した速度で独自のapplicationとリソースを管理できます。

applicationを展開すると、application開発者が必ずしも対処していないいくつかの懸念事項が発生するため、ADC はあらゆるスタックの重要なコンポーネントです。 これらの分野横断的な質問には次のものが含まれます。

• エンドユーザーと期待されるセキュリティ体制に適した TLS プロトコル スイートはどれですか?
• DDoS 攻撃はどのように識別され、軽減されるのでしょうか?
• どの負荷分散戦略が最適ですか?
• クライアント側のマルウェアはどのように管理されますか?
• SQL インジェクションやクロスサイトスクリプティング攻撃を防ぐ最善の方法は何ですか?
• ユーザーはどのように識別され、認証されるのでしょうか?

これらの質問に答えるには、多くの場合、applicationコードを開発するチーム以外のドメインの専門知識が必要になります。 テンプレートを使用すると、ADC の専門知識を活用できる従来の IT NetOps チームのメンバーなどのドメイン エキスパートが ADC リソース定義を作成できるため、application開発者はアプリケーションの構築に集中できます。 作成されたテンプレートは、各application開発チームが各applicationの一部としてスタックをデプロイするために使用できます。

純粋なオープンソースから独自のシステムまで、さまざまなプライベート クラウド環境があります。 組織にとってどれが適切な選択であるかは、予算、プライベート クラウド環境の管理に関する社内の専門知識、統合に関する懸念、メンテナンスの問題、変更に対する快適度など、いくつかの要因によって決まります。

純粋なオープンソース製品は、その名前が示すように、ハードウェアと人件費（時間）以外の初期取得ライセンス費用をまったくかけずに導入できます。 OpenStack は、無料でダウンロードしてインストールできる、主要なオープンソースのプライベート クラウド環境です。 もちろん、課題は、それをインストールして保守するグループが、急速に成熟しているものの、導入がまだ複雑な OpenStack に関する専門知識を習得して維持する必要があることです。 これは純粋なオープンソース製品すべてに当てはまります。組織は、その技術を最も効果的に使用するには、その技術の専門家になる必要があります。

社内に専門知識を維持する負担（およびその専門知識がないリスク）を軽減するために、オープンソース プロジェクトのサポートを提供する企業もあります。 これらの商用製品には金銭的なコストがかかりますが、ベンダーが統合、テスト、検証の問題に対処し、問題が発生した場合に連絡できる人がいることを保証することで、コストを相殺できる可能性があります。

あるいは、独自のプライベート クラウド プラットフォームを提供する企業もいくつかあります。 これらは、専用のサポートを備えた完全に統合されテストされたスタックを提供しますが、通常、OpenStack でサポートされるソリューションよりもコストがかかります。 ただし、組織がすでにベンダーのテクノロジーとインターフェースに精通している場合は、これらの独自の製品のいずれかを使用すると、学習曲線が短縮される可能性があります。

そして最後に、一部のベンダーはホスト型サービスを提供しており、組織はハードウェアやデータセンターのスペースを必要とせずにオープンソースのプライベートクラウド (または独自のサービス) を活用できます。 これらのサービスは通常、価格が最も高くなりますが、必要な社内リソースは最も少なくなります。

組織は、適切な機能を備えたプライベート クラウド ソリューションを見つけることに加えて、適切なレベルのサポートを備えたソリューションを探す必要があります。 組織がコストの連続体のどこに位置しているかを把握し、社内の専門知識を活用することで、ニーズに最適なサービスを選択することができます。

プライベート クラウドを使用すると、開発チームはインフラストラクチャのプロビジョニング速度に関係なく反復処理を実行し、ビジネス要件に適切に対応できるようになります。 マルチテナントと仮想リソースのソフトプロビジョニングにより、チーム間の依存関係を軽減できます。 テンプレートを使用すると、コンピューティング、ネットワーク、ストレージ、ADC を含むapplicationスタック全体を、完全かつ繰り返し可能なパッケージとして展開できます。 つまり、プライベート クラウドにより、組織のチームはビジネスのスピードに合わせて行動できるようになります。

プライベート クラウドには、さまざまなコストと必要な社内専門知識のレベルに応じたさまざまなサービスがあります。 どのようなクラウドを導入する場合でも、適切なサービスを備え、コストと専門知識の適切なバランスを見つけることが最優先事項の 1 つになるはずです。

プライベート クラウド アーキテクチャが、インフラストラクチャの制御を維持しながら組織の俊敏性と効率性を高めるのにどのように役立つかについては、「クラウド ソリューション | プライベート クラウド」で詳細をご覧ください。