エンタープライズプライベートクラウド構築の実践: 製品 + エコシステムモデル

クラウド コンピューティング テクノロジーが徐々に成熟し、プラットフォーム サービスの標準化が進むにつれて、ビジネスをクラウドに移行している企業や移行を進めている企業がますます増えています。

1. プライベートクラウド市場の発展の概要

クラウド コンピューティング テクノロジーが徐々に成熟し、プラットフォーム サービスの標準化が進むにつれて、ビジネスをクラウドに移行している企業や移行を進めている企業がますます増えています。その中には、インターネットに敏感な業務をパブリッククラウドに移行している企業もあれば、データ資産のセキュリティや規制遵守の要件から、セキュリティと制御性を考慮し、既存のITリソースを最大限に活用しながらプライベートクラウドを構築することを好む中堅・大規模企業もあります。

実際のところ、デジタルトランスフォーメーションとインターネット+のプロセスにおいて、多くの企業のビジネスはそれぞれパブリッククラウドとプライベートクラウドの両方によって担われることになります。これは一定期間変更できず、業界のコンセンサスでもあります。

2017年、中国のプライベートクラウド市場規模は426.8億元に達し、2016年より23.8%増加しました。中国のプライベートクラウド市場の成長率は2018年から2021年にかけて安定し、2021年には市場規模が955.7億元に達すると予想されています。

このような巨大な市場機会に直面して、国内大手企業によるプライベートクラウド製品の展開はますます効果的になっています。 Huawei、H3C、Inspurなどの一流メーカー、China Telecom、China Unicom、Lenovoなどの二流、三流メーカー、そしてあらゆる規模の革新的企業が主導する、製品競争の壮大なパターンが基本的に形成されています。

2. プライベートクラウド構築の正しい「姿勢」

エンタープライズ プライベート クラウド プラットフォームを構築する前に、まずユーザーが本当に望んでいるクラウド プラットフォームの種類を慎重に検討しましょう。クラウド コンピューティングの活発な発展と企業の IT デジタル構築のますます完璧な化に伴い、適切なクラウド プラットフォームは次の基本条件を満たす必要があります。

1) 仮想化またはコンテナ技術を通じて、コンピューティング リソース、ストレージ リソース、ネットワークなどの同種または異種の IT インフラストラクチャをプールし、企業の既存の IT リソースを最大限に活用することが、クラウド プラットフォームの基本的な機能です。

2) クラウド プラットフォーム リソース管理レイヤーは、仮想化リソース プール内のリソースの作成、配信、使用からリサイクルまでのライフ サイクル全体を管理し、リソースの柔軟なスケーリングと再利用を実現します。基礎資源の統一的な監視と管理を実現する。クラウド プラットフォームのカスタマイズされた統合とオンデマンド拡張のニーズを満たすために、オープンな機能コンポーネントと完全なノースバウンド API インターフェイスを提供します。

3) 企業ユーザーのニーズに合わせたサービスカタログ、運用・保守サポートシステム、ユーザーポータルと管理ポータルをそれぞれ通じてサービスと管理の入り口を提供します。さらに、クラウドベースのポータルは、企業の既存の IT エコシステムとの完全な統合を実現できます。

プライベート クラウドの構築、提供、運用、保守は複雑なプロセスです。システムインテグレータであれ、クラウドコンピューティングベンダーであれ、ユーザーへのサービス提供時の「姿勢」が間違っていると、顧客に不快感を与え、信頼を失わせることになりかねません。プライベート クラウド構築におけるトップダウン計画とボトムアップ構築の一般原則は理解できますが、計画プロセス中に信頼性が高く使いやすいクラウド プラットフォーム コンポーネントを選択することが非常に重要です。この問題を理解するために、次の図を見てみましょう。

下から順に、インフラ層、製品層、生態構築層です。

下から上へ見てみましょう。クラウド プラットフォームは基盤となるハードウェアとの互換性が優れているため、既存の経験やルーチンに基づいて基盤となるハードウェアを選択しても基本的に問題はありません。

中間層は、IaaS をベースとしたインフラストラクチャ管理層です。このレイヤーは、基盤となるコンピューティング リソースのプーリング、リソースのスケジュール設定、および管理を担当します。これはクラウド プラットフォームの非常に重要なレイヤーであり、メーカーが多額の投資を行っているレイヤーでもあります。このレイヤーの安定性は、上位レベルのサービス カタログの可用性と有効性に直接関係しています。リスクとその後の運用および保守コストを削減するために、このレイヤーには成熟した商用製品を使用することを強くお勧めします。このレイヤーが openstack/cloudstack などのオープンソース コンポーネントを通じて直接構築されると、大きなリスクが生じます。

最上位層は、「UCMP (Unified Cloud Management Portal) または CMP2.0」と呼ばれます。従来の CMP の一部の機能が含まれているだけでなく、CMP の拡張バージョンまたはカスタマイズバージョンでもあります。また、クラウド プラットフォーム ユーザー (IT 管理者、リソース ユーザー、プラットフォーム管理者、運用保守担当者など) 向けのサービスおよび管理ポータルでもあります。このレイヤーは、クラウド プラットフォームの実装における重要なリンクです。インフラストラクチャ層と中間層を自動車のシャシー、サスペンション、エンジンに例えると、この層は中央制御の計器パネルとギアボックスであり、ユーザーエクスペリエンスに直接関係します。業界によって IT エコシステムが異なるため、顧客の使用習慣や統合要件も異なります。このレイヤーを企業ユーザーが簡単に使用できるようになるには、多くの統合カスタマイズとカスタマイズされたサービスが必要になることがよくあります。クラウドプラットフォーム構築の実装における最後のリンクです。最高のコストパフォーマンスを維持するために、経験豊富なシステム インテグレーターまたはカスタマイズされたサービス チームを持つメーカーの支援を受けて、継続的な構築と最適化を実行することをお勧めします。

まとめると、クラウド プラットフォームをボトムアップで構築するプロセスにおいて、標準インフラストラクチャ+製品プラットフォームサポート +上位ポータル構築がベスト プラクティスのセットになりました。これは、リスクが最小限で、総コスト (TCO) が最高で、スケーラビリティが最高の「製品 + エコロジー」構築モデルです。

3. 製品＋エコシステム構築のメリットと重要性

クラウド プラットフォームの構築プロセスには、主に 2 つの誤解があります。

1) 製品のみの理論: この場合、従来の IT アーキテクチャからクラウド コンピューティング アーキテクチャへの移行は、クラウド コンピューティング製品を導入することで完全に実現できると考えられています。

2) フレームワークのみの理論: この見解では、中規模の技術チームを編成し、オープンソース フレームワークを改良し、少しパッケージ化することでクラウド プラットフォームを構築できると考えられています。

上記の誤解は、クラウド プラットフォーム構築の初期段階に過ぎません。せいぜい、いくつかの単純なインフラストラクチャ管理機能を使用して、従来の IT アーキテクチャからリソース プーリングまでのプロセスを完了します。しかし、実際の構築プロセスでは、クラウド コンピューティング製品メーカーは、自社の製品機能があらゆる分野のユーザーのニーズを満たせないことに気付くことがよくあります。標準化された製品のみを提供し、ユーザーの最終的なニーズを満たすことができない場合は、クラウド プラットフォームの構築を最終的に実装するために、一定量のカスタマイズされた開発作業に継続的に投資する必要があります。製品メーカーの位置づけは、製品の研究開発に重点を置くことです。ユーザー向けにカスタマイズするために多くのリソースを消費するのは賢明ではなく、入出力比率は非常に低くなります。そのため、大手クラウドプラットフォーム製品メーカーは、自社製品＋オープンプラットフォームを徐々に改善し、エコロジカルな協力計画に依拠し、各分野のパートナーと深く協力して、標準製品とオープンプラットフォームAPIを提供しています。彼らは自社製品の販売に集中し、カスタマイズの部分はインテグレーターやパートナーに任せています。この分業と協力を通じて、「win-win」の状況が実現されます。

2 番目の誤解は、クラウド プラットフォームを構築する最もリスクの高い方法です。事実は、十分な人的資源と資金がなければ、それを商業化することは不可能であることを証明しています。業界には失敗例が多すぎるので、ここでは詳しく述べません。

私たちは、さまざまなチャネルを通じて、数多くのクラウドプラットフォーム構築事例を分析してきました。実際の多くのケースでは、カスタマイズされた UCMP が不足しているため、クラウド プラットフォームは実装中に役に立たなくなっています。一部のユーザーからは、「仮想化プラットフォームを直接使用するのとあまり変わらない」「クラウド プラットフォーム製品は実際のビジネス ニーズに合わせてカスタマイズできず、使い勝手が悪い」といった不満の声が上がっています。

第 2 セクションで述べたように、クラウド プラットフォームが構築された後は、それは独立したシステムではありません。企業の既存の IT エコシステムと統合するには、多くの既存のビジネス プロセスやシステムと統合または統合して、IT リソース、データとビジネス プロセス、セキュリティ仕様の統一管理を実現する必要があります。このステップは不可欠であり、クラウド プラットフォーム構築の最終目標です。これは、クラウド プラットフォーム構築において、ビルダーが見落としがちなリンクでもあります。このステップが欠けていると、企業がクラウド プラットフォームを構築する意味は何でしょうか?仮想化プラットフォームはユーザーのニーズを完全に満たします。

生態学的建設の考え方によれば、この部分の作業を生態学的パートナーに完了させることが間違いなく最も適切な選択です。製品メーカーとエコパートナーはそれぞれの義務を果たし、クラウド プラットフォームの構築において最も効果的な相乗効果を生み出します。したがって、上記の分析によれば、「製品＋エコロジー」構築モデルに基づいて、上記のような構築上の誤解を可能な限り回避することができ、クラウドプラットフォームの実装を完璧にすることができます。