建築家の視点から見た新しいプライベートクラウド

この投稿は当初 に掲載されました。 数年前から、「プライベートクラウド」という言葉には否定的な意味合いがありました。しかし、ご存知のように、テクノロジーは矢印よりも車輪であり、まさにその通り、プライベートクラウドは大きな注目を集めており、そのすべてが肯定的です。統計は明確で、Forresterの2023年インフラストラクチャクラウド調査では、回答した1,300人の企業の意思決定者のうち79％がプライベートクラウドを導入していると答えています。 、IT リーダーの 94% が、データの本国への移送に携わっていました。由緒ある IDC の調査によると、企業の 80% が、データをクラウドに移行してから 1 年以内に、データの一部またはすべてを本国に送還しています。クラウド産業複合体の「何も見るべきものはありません...」という主張は、これで終わりです。 The New Stack 英国におけるCitrixレポート 理由はさまざまで、詳しく説明しますが、より重要なのは、どのアーキテクチャに回帰するのが適切か、プライベート クラウドのエンジニアリングの第一原則は何か、そして最後に、AI のデータ インフラストラクチャ要件に合わせてどのように設計するかということです。 プライベートクラウドへの回帰の理由 企業が本国回帰する主な理由はコストです。本国回帰により最大70%のコスト削減が実現します。これは、次のようなさまざまな企業によって公に証明されています。 、 そして 。 37 シグナル バツ アーレフス 関連はあるものの、同じではないのが予測可能性です。プライベート クラウドは弾力性は劣りますが、予測可能性は高くなります (以下で弾力性に関するハックをいくつか取り上げます)。ワークロードを理解しているほとんどの CIO にとって、このトレードオフは十分に価値があります。CFO にとっては、さらに簡単な選択です。 セキュリティの問題は 3 番目です。これは、パブリック クラウドが本質的に安全でないと言っているわけではありません。実際そうではありません。これは、CISO がパブリック クラウド パートナーをこの点で完全に信頼していないことを示しています (実際、ほとんどのクラウド プロバイダーはバケットを調べる権利を保持しています)。AI の時代では、リスクは高まるばかりです。 関連して、制御はすべての CIO のリストに含まれています。コスト削減、予測可能性、セキュリティに加えて、AI データ インフラストラクチャを完全に制御できるだけでなく、そのデータはすべてのアプリケーションで消費しやすいため、AI データ インフラストラクチャでモデルをホストし、独自のセキュリティ要件 (物理アクセスも含む) に合わせてセキュリティ標準をユーザーとチームが設定できるようになります。 成熟度も重要です。現代のクラウドは運用モデルであり、場所ではありません。かつては主要なパブリック クラウドの独占的提供物であったこのモデルは、今ではエッジからコアまであらゆる場所で使用されています。コンテナ化、オーケストレーション、マイクロサービス、ソフトウェア定義インフラストラクチャ、RESTful API は、標準的な運用手順です。どこで実行するかは問題ではありません。問題でないなら、なぜ 2 ～ 3 倍のコストを支払うのでしょうか。 規制も、特に進化するにつれて役割を果たします。一部のアーキテクチャ、一部の地域、一部の展開シナリオ (軍事/諜報) では、当初はプライベート クラウドが必要ではありませんでしたが、現在は必要です。 理由は異なりますが、効果は同じです。プライベート クラウドが再び流行しています。問題は、過去数年間で何が変わったかということです。 プライベートクラウドのお気に入りのデザインパターンは、最新のデータレイクです 前述のように、プライベート クラウドはパブリック クラウドと同様にクラウド運用モデルで実行されます。エッジ クラウドはクラウド運用モデルで実行されます。コロケーションはクラウド運用モデルで実行されます。 この運用モデルは特定のアーキテクチャを定義し、そのアーキテクチャが最新のデータ レイクを実現することを繰り返し可能にしています。もちろん他のアーキテクチャもありますが、プライベート クラウドを使用して最新のデータ レイクを構築することで、組織は必要なものだけを支払うことができます。ビジネスが拡大しても、クラスターにリソースを追加するだけで簡単に拡張できます。再設計は必要ありません。 サポートされています。 —サポートされています。 ログ分析/脅威分析 —サポートされています。 — サポートされています。 AI/機械学習 高度な分析 HDFSの置き換え/移行 現代のデータレイクは、半分がデータウェアハウス、半分がデータレイクで、すべてにオブジェクトストレージを使用します。オブジェクトストレージ層はソフトウェア定義で、スケーラブル、クラウドネイティブで高性能です。パフォーマンスは、 これらは、Supermicro、Dell、HPE などのベンダーからすぐに入手でき、便利です。 ハードウェア（NVMe）とネットワーク（100 GbE以上） オブジェクトストレージをデータレイクで使用するのは標準的ですが、データウェアハウスで使用するのは新しいもので、Apache Iceberg、Apache Hudi、Delta Lakeなどのオープンテーブルフォーマット（OTF）によって可能になりました。このアーキテクチャーについては、この記事の範囲を超える詳細があります。そのため、Keith Pijanowskiの完全な記事を読むことをお勧めします。 アーキテクチャは次のとおりです。 現代のデータレイクに関する記事 このアーキテクチャは、以下のものを実現するように設計されています。これらはすべて、クラウドのコア運用原則であり、ひいてはプライベート クラウドのコア原則です。 プライベート クラウドは容量重視で設計できますが、最新のプライベート クラウドは大規模なパフォーマンスの提供を目指しています。このアーキテクチャでは、速度と効率性を重視したツールが優先されます。ジェフ ベゾスが言うように、高額な料金を支払って、より長い時間待つことを望む人がいるでしょうか? ここでも同じ原則が当てはまります。より遅いことを望む人がいるでしょうか? 高性能: これらのコンポーネントのリンクを解除すると、柔軟性とスケーラビリティが向上し、選択したインフラストラクチャ、サービス、ツールがそれぞれの専門分野で優れた成果を上げることができます。 分離されたコンピューティングとストレージ: オープン スタンダードは相互運用性を促進するだけでなく、投資の将来性も保証します。これには、オープン ソース ソリューションだけでなく、これから説明するオープン テーブル形式も含まれます。これらの理由 (および、それらがクラウド ネイティブになることは決してないという事実) から、ストレージ アプライアンスを使用してプライベート クラウドを構築しないでください。 オープン スタンダード: 相互接続性は必須です。ツールは共通言語を共有し、S3 をクラウド ストレージの共通言語として利用する必要があります。このため、S3 をサポートしていると主張している場合でも、POSIX 中心のソリューションでプライベート クラウドを構築しないでください。本物のソリューションを使用してください。 RESTful API との互換性: インフラストラクチャのオーケストレーションを自動化し、Kubernetes に任せることで、手動管理の複雑さを抽象化し、迅速かつ効率的なスケーラビリティを実現します。 ソフトウェア駆動型/コードとしてのインフラストラクチャ: プライベート クラウドは専用のインフラストラクチャを提供するため、データに対する制御が強化され、セキュリティ対策が強化されます。これは、金融や医療など、機密情報を扱う業界にとって特に有益です。 セキュリティとコンプライアンスの強化: このアーキテクチャは、特定の業界標準を満たすカスタマイズ可能なセキュリティ設定と監査制御を提供することで、規制コンプライアンスをサポートできます。 規制コンプライアンス: プライベートクラウドを活用する プライベート クラウドを活性化させるには、さまざまなアプローチがあります。どれも機能する可能性がありますが、企業と使用事例によって異なります。 一部のデータとアプリケーションはパブリック クラウドに残り、プライベート クラウドがハイドレーションされる、時間制限のあるハイブリッド モデル。 パブリック クラウドからプライベート クラウドへの完全な復帰。 プライベート クラウドのグリーンフィールド構築。これは、企業が AI 実験を本番環境に導入する際に特に人気があります。 ブラウンフィールドの回帰では、パブリック クラウドのデータとインフラストラクチャを既存のプライベート クラウド デプロイメントに戻します。経済的ではありますが、このアプローチにはいくつかの欠点があります。 「その他」カテゴリ (バーストおよび外部テーブル)。 時間制限付きハイブリッド アプローチは、基本的にパブリック クラウドをコールド ストレージに変え、一定期間 (数年ではなく、数か月/四半期) にわたってプライベート クラウドのフットプリントを構築します。これには、プライベート クラウド上のインフラストラクチャとソフトウェア スタックを購入して構成することが含まれます。次に、データ パイプラインをパブリック クラウドではなくプライベート クラウドに向けます。両方を行う期間がある場合もあります。ただし、目標は、パブリック クラウドを階層型コールド ストレージとして使用し、プライベート クラウドをホット ストレージとして使用することです。時間の経過とともに、パブリック クラウドはコールドからフリーズに変わり、プライベート クラウドが主要な主要なストレージ タイプになります。 時間制限付きハイブリッド アプローチ: これは、大手サイバーセキュリティ企業が行ったことです。同社は、MinIO および Equinix と連携してプライベート クラウドを設定することから始め、次に 1 日 250 テビバイト (TiB) のデータ ファイアホースをその方向に転換しました。ログ分析は運用上の価値の点で減衰率が高いため、新しいプライベート クラウドが脅威ハンティング データの主なソースになるのにそれほど時間はかかりませんでした。このプライベート クラウドはほぼ 1 エクサバイトにまで成長し (まもなくそのしきい値を超えるでしょう)、これらのワークロード (実質的にコア ビジネス) をプライベート クラウド (設備投資ではなく運用コスト) に移行するという決定により、ビジネスの粗利益が 2% 以上向上しました。その結果、この企業は同業他社が羨むような評価倍率を獲得しました。 : アプリケーションとデータをパブリック クラウドとプライベート クラウドの両方に保持することが選択肢にならない場合があります。このような場合は、クラウド プロバイダーと別れる必要があります。これは困難であり、退出料が不要になったとしても、苦痛です (細則には基本的に、退出料の軽減を受けるにはすべてを手放さなければならないと書かれています)。これは非常に実行可能です。もう少し計画し、ビジネス上の摩擦が少し増えるだけです。この場合は、コロケーションまたはプライベート クラウドとアプリケーション スタックをプロビジョニングします。次に、データ トラックをバックアップするか、ネットワークをリースして、データをプライベート クラウド データ インフラストラクチャにファイアホースで送り出します。この時点では自由ですが、万全を期すタイプであれば、1 か月か 2 か月は 2 倍の料金を支払うことを覚悟してください。大手ストリーミング会社の 1 社は、パブリック クラウドを離れる際にこのアプローチを採用しました。映画、番組、ドキュメンタリーなどすべてを含む 0.5 エクサバイトを新しいプライベート クラウドにフォークリフトしました。このプロセスには約 4 分の 3 かかりました。ただし、見返りは大きく、サービスを管理するチームの複雑さは大幅に軽減されました。彼らはまた、「 「」は、この分野における重要な指標です。 完全な本国への回帰 最初のバイトまでの時間 グリーンフィールドプライベートクラウド: これはかなり単純な提案で、一般的にすべてが新しいものになります。プロジェクトは新しく、プロジェクトに関するデータは新しい（または比較的新しい）か、オンラインになるソース（巨大な製造工場や新しいクラウド ビデオ オンデマンド サービスなど）から生成されます。ここでワークロードのサイズを決定します。パブリック クラウドでテストする場合もありますが、最初からプライベート クラウドで実行するという考え方です。AI データ インフラストラクチャでは、これを頻繁に目にします。初期の実験はパブリック クラウドで行われています。データはそれほど重要ではありません。GPU の可用性はかなり良好です。それでも、企業は、スケールだけでなく、セキュリティ、プライバシー、制御のためにも、ワークロードを本番環境でプライベート クラウドに配置する必要があることを認識しています。世界有数の自動車会社の 1 社は最近、完全な自動運転イニシアチブをルールベースのシステムから実際のドライバーの行動に基づくシステムに転換しました。 その行動は、同社の車両から得られる何百万ものビデオやログ ファイルから「学習」されます。良いドライバー、悪いドライバー、平均的なドライバー。ビデオだけでなく、ブレーキ、加速、ステアリング トルクなどの自動車テレメトリの他の要素からも学習されます。ルールベースの ML アプローチはペタバイト規模で、ビデオはエクサバイト規模です。同社はそのデータを誰とも共有していません (実際、パブリック クラウドの 2 つには競合する取り組みがあります)。その AI ワークロード (300 台以上のサーバーすべてに相当) は、常にプライベート クラウドの取り組みでした。 ブラウンフィールドプライベートクラウド: 正直に言うと、私たちはこれを目にしていますが、あまり好きではありません。これには、ハードディスクドライブで高性能のワークロードを実行してMinIOを重ねることも含まれます。 (ストレージ エリア ネットワーク/ネットワーク接続ストレージ)。 SAN/NASのトップ これは機能しますが、最適なソリューションになることはほとんどありません。経済的 (ハードウェアを再利用)、低摩擦 (調達不要) ですが、パフォーマンスが優れていることはほとんどありません。それでも、包括的にするためにここに含めています。重要な点を提起しています。プライベート クラウドを設計する場合、どのシナリオでも、異種混合を計画してください。これは保証であり、率直に言って計画の一部である必要があります。上記のシナリオの 1 つでは、ハードウェアの半分は Supermicro 製です。残りの半分は Dell 製です。世界が変化し、新しいテクノロジーが利用可能になっても、ソフトウェアは気にする必要はありません。 その他: 他に、頻度は低いものの検討すべきシナリオが 2 つあります。1 つはハイブリッド バースト アプローチ、もう 1 つは外部テーブル アプローチです。どちらもハイブリッド オプションに関連していますが、期限が定められていない可能性があります。ハイブリッド バースト アプローチでは、プライベート クラウドを維持しながら、柔軟性を高めるためにパブリック クラウドにシームレスに拡張 (つまり「バースト」) するように設計します。この戦略は、追加の GPU 容量を活用したり、特定のクラウド サービスを使用したりするためによく採用されます。このモデルでは、特定のタスクが一時的にパブリック クラウドに転送されて処理されます。分析が完了すると、結果がプライベート クラウドに送り返され、パブリック クラウドのリソースは廃止されます。大手金融サービス カスタマーが信用リスクと市場リスクの計算でこれを行っています。このカスタマーは、一部のコンピューティング操作にパブリック クラウドを使用し、それを MinIO と Dremio を使用するプライベート クラウド データ レイクと組み合わせています。クラウド運用モデルの優れた点は、アーキテクチャが両方の場所での運用をサポートできることです。これは事実上、双方向の道です。 かつては一方通行でしたが、世界は変わり、企業には選択肢があります。外部テーブル オプションを使用すると、組織は、既存のクラウド データ ウェアハウス (Snowflake や SQL Server など) をプライベート クラウド上に構築されたデータ レイクと統合することで、クラウド運用モデルの原則のメリットを享受できます。このハイブリッド セットアップにより、企業は最新のデータ レイクのパフォーマンス、データ セキュリティ、オープン標準設計のメリットを享受しながら、クラウド インフラストラクチャへの既存の投資を活用できます。現在、すべての主要データベース ベンダーが外部テーブルのサポートを提供しています。この機能により、ユーザーは、移行の手間をかけずに、オブジェクト ストレージ内のデータがどこにあっても、データベース内の通常のテーブルであるかのようにデータを照会できます。データはプライベート クラウド内に残りますが、必要なときにいつでも利用できます。 最終的な考えとアドバイス 私たちは長年にわたり、こうしたプライベート クラウドの回帰/新規構築に数多く関わってきました。チームにとって驚きの 1 つは、ハードウェアの管理が再び必要になることです。クラウドでは、ハードウェアは透過的です。DevOps およびサイト信頼性エンジニアは、API レベルでのみインフラストラクチャとやり取りします。VM が動作しない場合は、終了して代わりに新しい VM を起動します。残念ながら、新しいプライベート クラウドでは、ハードウェアを廃棄して新しいものを購入するだけでなく、既存のハードウェアを機能させる必要があります。 インフラストラクチャ管理は、業務の一部です。恐ろしいことではありませんが、計画する必要があります。ソフトウェア エンジニアリング/DevOps 側とデータ センター エンジニアの責任を明確にする必要があります。データ センターの SME (主題専門家) は、すべてのハードウェアの詳細を把握している必要があります。障害、交換、メンテナンスなど、ハードウェアに関連するあらゆることに責任を負います。 ここではソフトウェアが重要です。MinIO がグローバル コンソールに可観測性を組み込んだのはそのためです。プライベート クラウドの世界では、スマート ソフトウェアとダム ハードウェアを実行する必要があります。ただし、そのソフトウェアは、この経済的恩恵の運用上の負担を負わなければなりません。ハードウェア担当者は、可観測性レイヤーを構築することができませんでしたが、MinIO がそれを行う必要がありました。 週に 1 回デプロイする組織の場合、各デプロイはおそらく大変な作業です。これは、デプロイの頻度が低いと、バグを予測して修正することが難しいためです。デプロイが計画どおりに進まない場合は、全員が協力する必要があります。一般的なフローは次のようになります。 分散設定でアプリケーションを展開するための設計 ローカル環境でテストする 開発およびステージ環境でさらに検証する 監視、メトリクス、トレース、変更を追加する オンプレミス、ハイブリッド、クラウド環境を展開 これらの CI/CD 原則を実際に適用すると、1 人の優秀なデータ センター エンジニアがもう 1 人の優秀な DevOps/SRE エンジニアと緊密に連携して、プライベート クラウドまたはコロケーション施設で 5,000 を超えるノードを簡単に管理できます。まさにこれを実行しているお客様がいます。CI/CD ベースライン原則に従えば、ほぼすべての作業を自動化でき、自動化する必要があり、データ センターと DevOps エンジニアは自動化できないタスクのみに集中できます。最後に、見逃した方のために言っておきますが、コロケーションはプライベート クラウドの定義と同義です。 コロケーションは、完全なオンプレミスのインフラストラクチャとパブリッククラウドの中間に位置し、両方のメリットを提供します。トップレベルのネットワークへのアクセスとパブリッククラウドプロバイダーへの近接性により、コロケーションは低遅延接続とハイブリッドクラウドのセットアップを促進し、効率的なデータ転送と処理を可能にします。この柔軟性とハイブリッドクラウドの導入を成功させる可能性は、業務を最適化し、競争力を維持したい企業にとって非常に重要です。この仕組みの詳細については、当社の 。 MinIO と Equinix ページ