クラウドへのデータ移行の欠点のいくつかを理解していますか?

少し前に、顧客向けの XC ソリューションの準備に参加しました。リーダーは、XC 作業をクラウド移行と一体として実行し、XC を使用してクラウド移行の進行を加速する必要があることを要求しました。これにより、データベース XC の作業がより複雑になります。クラウドベンダーが提供する RDS を使用することは好まれますが、XC データベースは RDS として提供できません。クラウドベンダーは、これらのデータベースの RDS サポートの開発に対して高額な料金を請求します。しかし、XC データベースをベアメタル環境に導入し、それをクラウドで管理することは、同社のクラウド移行に関する基本的な IT ポリシーに準拠しておらず、経営陣にも認められませんでした。これにより、クラウド管理部門は大きな頭痛の種となりました。 XC データベースを ECS クラウド ホストにデプロイするだけでは動作しますが、それがうまく使用できるかどうかは誰にもわかりません。 XC データベース ベンダーは問題がないと断言しますが、重要な大規模アプリケーション システムに関しては、誰も保証をしません。

近年の IT 開発ではクラウドへの移行がトレンドとなっており、この一般的な方向性は常に正しいと言えます。しかし、どんなに優れたものでも限界や欠点はあります。そのため、ほとんどの企業は万能のアプローチを取らず、ある程度の余地を残します。クラウド コンピューティングは最終的な目標ではなく、ビジネスに対するより優れたサポートを確保することが IT 部門のクラウド コンピューティングの目的だからです。強制的にクラウドに移行しても業務システムを十分にサポートできない場合、このような画一的なアプローチを採用するのは適切ではありません。

データベースをクラウドに移行することは常にホットな話題です。すべての主要クラウドベンダーが RDS 製品を提供していますが、国内の RDS 製品は主に MySQL、PG、MongoDB、Redis などのオープンソース データベースに集中しています。企業が使用するデータベースはこのリストに含まれていない可能性があります。したがって、データベースを ECS クラウド ホストに配置して実行することが不可欠です。

RDS のデータベースはベアメタル サーバーで実行されるため、RDS と ECS で実行されているデータベースの間にはパフォーマンスにまだ多くの違いがあります。クラウド プラットフォームのクラウド ベースは、これらのベア メタル サーバーの管理をサポートします。これらのデータベースはローカル ディスクを使用するため、パフォーマンスが保証されます。高性能 SSD ディスクを備えた RDS を選択した場合、IO レイテンシと IO スループットは、従来のアーキテクチャを備えたデータベース システムと同等になります。唯一の制限は、単一のマシンの容量です。現在、クラウド プラットフォームの RDS には仕様があります。 RDS の各仕様では、CPU、メモリ、IOPS などが制限されるだけでなく、単一のデータベースのサイズも制限されます。

RDS とは異なり、ECS は弾力性に優れています。 CPU、メモリ、ストレージ容量を柔軟に拡張できます。ただし、ECS は完全にクラウドベースで実行され、そのストレージ メディアはクラウドベースの分散ストレージを使用することが多いため、IO スループットと IO レイテンシに一定の欠点があります。一部のクラウド ベンダーは、高性能ストレージ サポートを実現するために、ECS 集中ストレージ LUN をサポートしています。残念ながら、現在国内には SAN SWITCH に代わるソリューションはなく、このソリューションは一部のより厳格な XC プロジェクトでは使用できません。ストレージは、分散ストレージまたは IPSAN を通じてのみ提供できます。もちろん、これも文句を言う価値のある点です。 SAN SWITCH は用途が限定されており、耐用年数も非常に長いです。首を絞められるのが心配なら、今から多めに買っておいても高くはありません。このロットが使い果たされる頃には、国産品が追いつくでしょう。完全に自律的で制御可能なゲームプレイを一方的に追求することで、XC の作業もより困難になります。

実際、データベースのクラウド移行については依然として多くの苦情が寄せられています。少し前に、Oracle OCM が flashdba Web サイトで収集したデータベース クラウド移行に関する苦情のコレクションを見ましたが、私はそれに完全に同意しました。今日はここでそれを皆さんと共有したいと思います。実際、外国人が不満を言うことは、私たちが不満を言うことと似ています。ビジネスクリティカルなアプリケーション ワークロードの場合、その特性には、大規模、複雑、高い信頼性要件、ミッションクリティカル性、機密性、高パフォーマンス要件などがあります。ローカルに展開する場合は、専用のハイエンド インフラストラクチャ上で実行する必要があります。クラウドに移行すると、必ず問題が発生します。

クラウドは本質的に、オンデマンドでリソースとサービスの要求を満たすことができる個別のリソースとサービスの巨大なプールだからです。クラウド上で MySQL インスタンスを簡単にホストしたり、数百の ECS クラウド ホストをすぐに取得したりできます。予算があれば、クラウドはお金を有効に活用する方法を提供します。ただし、クラウド プロバイダーが提供する RDS データベースを使用する場合でも、ECS にデータベース ソフトウェアをインストールする場合でも、インフラストラクチャ、可用性、パフォーマンスを数百、数千の他のシステムと共有することになります。クラウドに問題が発生すると、すべての問題が影響を受けます。クラウドベンダーはクラウドの信頼性と安全性が非常に高いと主張していますが、近年パブリッククラウドの障害は孤立した事例ではありません。この問題に直面したときに、非常に無力なアプローチを選択したユーザーに出会いました。アプリケーション サーバーの半分をクラウド上に、残りの半分をクラウド外に展開し、データベースのプライマリ/バックアップ環境はそれぞれクラウド上とクラウド外に配置されました。このアプローチは実際にはシステムの複雑さを大幅に増大させ、運用と保守の難しさも増大させます。実際、システムが稼働した後、大きな問題は発生しなかったものの、小さな問題は頻繁に発生しました。

IOE 環境で完全に変換および移行できるシステムの場合、クラウドへの移行は比較的簡単です。当面完全に変革できないシステムの場合、唯一の選択肢はインフラストラクチャの移行です。しかし、この種の移行には大きな落とし穴がいくつかあることがよくあります。

まず第一に、IO において大きな課題に直面することになります。これまで、Oracle などの大規模データベース システムでは、安定した高性能なサービス提供を確保するために、集中型ストレージまたはローカルの高性能ハード ディスクの低 IO レイテンシに依存していました。これらすべてをクラウドで保証するのは難しいようです。クラウドでは、大量の計算能力を得るのは比較的簡単です。しかし、読み取りと書き込みを非常に高速に実行し、予測可能な応答時間内に完了する必要がある場合、クラウド プラットフォームでは適切なサポートを提供できない可能性があります。 IO レイテンシ、IOPS、またはスループットが重要な場合は、解決がより困難な問題になる可能性があります。

パブリッククラウドユーザーの中には、このように感じている人もいるでしょう。クラウドベンダーがこれらの機能を提供できないのではなく、これらの機能を購入するには資金が足りないのです。多くのパブリッククラウドユーザーは、パフォーマンスとコストは表裏一体であり、一目ですべてを把握するのは難しいと感じています。パブリッククラウドでは必要な料理をすべて選ぶことができますが、ほとんどのユーザーは、標準外の体型の人がシャツを買うときの恥ずかしさと同じように、料理を注文するときに恥ずかしさを感じたことがあります。私のように少し太り気味の人にとって、ぴったり合うシャツを買うのは非常に困難です。襟と胸囲が適切なシャツは袖が少し長すぎることが多く、袖が適切なシャツはきつすぎることがよくあります。

クラウド プラットフォームで食べ物を注文する場合も同様です。 S サイズのクラウド ホストは 40 ドル、M サイズのクラウド ホストは 120 ドル、L サイズのクラウド ホストは 160 ドルと最もコスト効率に優れています。しかし、これは私が必要としているものではありません。 XXLを着る必要があります。何？ XXL には 400 ドルを支払う必要があります。

これは実際に良いことです。お金に余裕があれば、必要なシャツをすぐに手に入れることができます。過剰な構成は限られた予算に負担をかけます。クラウドベンダーが提供する RDS や ECS は、レストランで提供される調理済み料理のようなものです。スパイシーチキンにもっと角切りチキンを入れたい、チリを減らしたい、そんな方法はない。 CPU、メモリ、IO 機能はセットで提供されることが多く、ニーズに応じて選択することはできません。 30,000 IOPS のストレージ システムが必要な場合、申し訳ありませんが、クラウド ベンダーのストレージ システムは GB ごとに構成されます。これだけの IOPS を購入するには、5 TB のクラウド ストレージを購入する必要があります。おそらく、そこに 500 GB のデータベースを展開するだけで済むでしょう。

Google と Amazon が、このような問題を回避するために IOPS に対して追加料金を支払うことができる、よりきめ細かい価格設定を提供しているのは良いことです。

これらすべてがパブリック クラウド上で発生する場合、ユーザーはそれを黙って受け入れることしかできません。実際、多くのプライベート クラウド環境で同様の状況を目にしてきました。管理を容易にするために、クラウド管理部門はパブリッククラウドと同様に一連の標準化された製品を立ち上げました。メニューから選択できるオプションは限られており、パブリック クラウド ユーザーとあまり変わりません。クラウド運用部門は、データベース アプリケーションのニーズと特性を理解していません。彼らは自らの意志でそれらを管理します。したがって、パブリック クラウドで発生した問題すべてが、自社構築のプライベート クラウドで解決されたわけではありません。