大小さまざまな企業が、クラウドコンピューティングを活用しています。ここ数年、クラウド・アプリケーションが爆発的な成長を遂げているのを、目の当たりにしてきました。これは、Office 365を活用したり、すべてのビジネスアプリケーションをデータセンターからクラウドに移行したりするような単純なものです。
企業がビジネスアプリケーションのクラウドへの移行を検討し始めると、セキュリティ、コンプライアンス、コスト、ディザスタリカバリなど、あらゆる面での多くの考慮事項が発生します。最終的には、どのシステムやアプリケーションを最初に移行すべきかという議論に発展していきます。
システムが特定され始めると、各システムがどのようなワークロードを持ち、それがクラウド上でどのように見えるかが議論されるようになります。ここでは、クラウドワークロードとは何か、そして知っておくべきさまざまなタイプのワークロードについて紹介します。また、現在のワークロードがクラウドに移行するのに適した候補であるかどうかを評価する際に、重要な考慮事項と成功するために必要なことについても紹介します。
クラウドコンピューティングにおけるワークロードとは何か？
クラウドワークロードとは一体何か？クラウドワークロードとは、基本的にクラウド上でコンピューティングパワーを消費するリソースやサービスのことを指します。ウェブサービス、アプリケーションサーバー、データベースサーバー、あるいはその他のビジネスプロセスなどがこれに該当します。
ユーザがクラウド移行に取り組む際、計画を深く練る前に、ユーザのワークロードの種類を評価すべきと常に考えられます。データベースのワークロードであっても、いくつかの異なるカテゴリーに分類することができます。
クラウドのワークロードの種類を説明
ワークロードの中には、一般的なコンピュート層に分類されるものもあります。データベースのワークロードの観点からすると、これを部門レベルのワークロードとして一般化できます。例えば、会計や人事など、より大きな組織内の特定部門を担当するアプリケーションなどがその例です。
データベースのワークロードの中には、より多くのCPUパワーを使用し、より多くのvCoreを必要とするものがあります。より多くのCPUを必要とするワークロードと同じように、より多くのメモリを必要とするワークロードがあります。SQL Server のようなリレーショナルデータベースシステムがデータをキャッシュするため、メモリ集約型のワークロードはデータベースのワークロードで非常によく見られます。従来は、メモリを増やすためには、CPUもスケールアップする必要がありました。Microsoft Azureでは、実際のコア数を提供することなく、より大きなサイズのVMのすべての利点を提供する「制約コア」VMを選択することができるようになりました。例えば、VMには8つのvCoreが必要ですが、16vCoreモデルでは利用可能な128GBのメモリが必要です。16vCoreのVMを8vCoreに減らした制約コアバージョンを選択することができます。メモリ、ストレージスループット、ネットワークスループットなど、16 vCoreモデルの他のすべてのリソースが利用可能です。
ほとんどのクラウドプロバイダーは、ストレージに最適化したバージョンのクラウドも提供しています。これは、大規模なデータウェアハウス、NoSQLデータベース、およびストレージに対して多くの要求を出すワークロードに典型的なものです。
ほとんどのクラウドプロバイダーが、GPUに最適化されたワークロードを提供していることも注目に値します。機械学習、人工知能、高度な分析との密接な統合により、これらのGPU最適化リソースが活躍する可能性があります。
Azureのような一部のクラウドプロバイダーは、定期的なワークロードのためのオプションを持っています。Azure SQL Databaseのようなある種のデータベースプラットフォームについては、サーバーレスティアを用意しています。サーバーレスでは、ワークロードの要求に応じてリソースを自動スケーリングすることができます。また、コンピュートリソースを一時停止するオートポーズ機能もあり、コンピュートコストを節約することができます。リソースの自動スケーリングは、ウェブサービスなどでは一般的ですが、データベースのワークロードにこの機能を持たせるのはユニークです。
予測不可能なワークロードに対して、クラウドプロバイダーは、さまざまなシステムが利用できるリソースのプールを提供することがあります。Azure SQL Databaseの場合、この機能はElastic Poolsと呼ばれています。これにより、組織は、シングルトン(注1)・データベースが利用できるvCoresまたはeDTUのプール上限を設定することができます。ワークロードが適切にバランスされていれば、短時間のリソース需要に対応するためにリソースを過剰に割り当てる必要がないため、企業のコストを大幅に削減することができます。
もう一つの一般的なシナリオは、ハイブリッド・ワークロードです。これは、クラウド機能を活用したい企業にとって非常に一般的になってきています。AzureのExpress Route、OracleのFast Connect、AWSのDirect ConnectといったVPNや高速専用接続を使えば、オンプレミスの拠点とプライベートクラウドやパブリッククラウドを接続したり拡張したり、場合によってはマルチクラウド環境を構築したりして、ハイブリッドクラウド環境を簡単に構築できるようになってきています。
データベースワークロードでの一般的なハイブリッドシナリオは、Power BIを活用してローカルデータセットに接続してレポートを作成したり、Azure Data Factoryを活用してローカルデータセットに接続してETLプロセスを実行したりすることです。また、バックアップファイルをクラウドに保存したり、可用性グループやログシッピングをVMに拡張したりすることで、ディザスタリカバリのためにクラウドを活用することも、よくあるシナリオのひとつです。
ワークロードを移行する際の留意点
ワークロードのクラウドへの移行を検討する場合、どのようなリソース仕様が必要かを判断する必要があります。オンプレミス環境では、将来の成長に対応するためにサイズが大きくなってしまうことがよくあります。クラウドの大きなメリットは、ビジネスやワークロードの成長に合わせてリソースを簡単にスケールアップできることです。このため、組織は、現在プロビジョニングされているものだけでなく、既存のワークロードが何を必要としているかに焦点を当てる必要があります。
CPU、メモリ、ストレージの容量については、簡単です。8つの論理コアを持つデータベースサーバがあり、通常の営業時間中に平均60～70％のCPU負荷がかかっているとしたら、クロックスピードが同じようなプロセッサーのVMを使用するようにし、少なくとも8つの論理コアを維持したいと考えるでしょう。メモリも同様に扱います。現在のメモリ・カウンターを確認し、データがバッファ・プールにどれくらいの時間留まっているかを確認し、新システムに十分なメモリがあることを確認するのです。以前にオンプレミスのサーバのプロビジョニングが著しく不足していたため、クラウドサーバーにメモリを追加して構築したプロジェクトや、プロビジョニングが大幅に過剰だったため、適正な量のサーバを選択したプロジェクトがありました。ストレージ容量は、現在使われているものと近い将来予測されるものをプロビジョニングする方法がわかりやすいです。
自動化でストレージのスループットを把握するメリット
常に見落とされがちなのが、ストレージのスループットです。これは、ディスクへのデータの読み書きの量である。多くの企業はディスクのレイテンシーを監視しており、これは重要なことですが、オンプレミスのローカルまたはネットワークストレージによってスロットルされていないため、全体的なスループットには注目していないかもしれません。
従来は、既存のストレージに対してベンチマークを実行し、その能力を確認することで、ストレージのスループットを測定していました。これはストレステストのベンチマークとしては最適な方法ですが、新しいクラウド環境で必要なものをサイジングする方法としては適しているとは言えません。重要なのは、ストレージのスループットについて既存のワークロードを把握することで、クラウド環境のサイズを適切に設定することができます。多くの場合、この作業は行われず、移行後にパフォーマンスの問題が発生し、最終的に評判を落とし、インフラストラクチャのサイズを変更しなければならないため、予期していなかった予算問題が発生する可能性があります。
SQL Serverデータベースのストレージスループットを把握するために、最も簡単な方法の1つは、パフォーマンスモニター「perfmon」を使用して「ディスク読み取りバイト/秒」と「ディスク書き込みバイト/秒」を把握することです。より頻繁に使用する別のオプションは、sys.dm_io_virtual_file_statsを利用することです。このDMVは、最後のSQL Serverサービス再起動以降のファイル統計情報を取得します。
自動化によってこのデータを長期的に取得するもう一つの利点は、使用量が多い時間帯を確認できることです。バックアップ、メンテナンス作業、または時間外のETL処理中に使用量がピークに達していないでしょうか？もしそうなら、ほとんどのユースケースでは、これらの値を除外して、実際のエンドユーザのアクティビティに必要なものを確認することができます。
これが非常に重要な理由は、クラウドリソースはリソースのサイズに基づいてI/Oとスループットを制限しているからです。Azureでは、Azure SQL Database、Azure SQL Managed Instance、Azure SQL VMがこれに当てはまります。ティアのサイズやvCoreの数が増えると、ストレージのIOPSやスループットなど、他の制限も増えていきます。
クラウドワークロードの監視とオンプレミスワークロードの監視
クラウドのワークロードを監視する方法は、いくつかの例外を除いて、オンプレミスの監視方法と非常に似ています。前述のように、ストレージのスループットは、ワークロードを処理できる環境を持つための重要な要素です。ストレージのスループットは、ワークロードを処理できる環境を構築する上で重要な要素です。環境によっては限界があり、容量に近づいている、または容量に達しているタイミングを知ることは非常に重要です。パフォーマンスモニターやsys.dm_os_virtual_file_stats DMVを使用して、上記で説明した同様のプロセスを実行すれば、消費量を知ることができます。しかし、Azure仮想マシンでは、ディスクまたはVMレベルの上限を監視するために、いくつかのメトリクスを利用することができます：
●ディスクレベルでは ：データディスクIOPS消費率、データディスク帯域幅消費率
●VMレベルでは ：VMキャッシュIOPS消費率、VMキャッシュ帯域幅消費率、VMアンキャッシュIOPS消費率、VMアンキャッシュ帯域幅消費率
適切な移行プランニングが成功の鍵
クラウドは、あらゆるワークロードに対応できるように準備されていますが、移行を成功させるためには、適切な計画が不可欠です。クラウドのリソースの制限、特にストレージのスループットを意識することで、適切なコンピュートリソースを利用できるようになり、移行を成功させることができるようになります。クラウドに移行した後は、リソース消費の監視にストレージのスループットも含める必要があります。
移行前、移行中、移行後のデータ環境の最適化とパフォーマンスの向上に役立つ深いレベルの洞察を提供するために、データベースソリューションがどのように構築されているかを確認する手法は、詳しくはこちらをご覧ください。
(注1)シングルトンとは、オブジェクト指向プログラミングにおけるクラスのデザインパターンの一つで、実行時にそのクラスのインスタンスが必ず単一になるよう設計すること。
クラウド型ディザスターリカバリー1つ目は、バックアップデータの保存先をクラウドにし、災害時にはクラウドからデータを復旧させる方法です。
クラウド・ディザスターリカバリークラウド・ディザスターリカバリーの第二のアプローチは、オンプレミスでデータをバックアップし、クラウドプラットフォーム上で動作する仮想マシンやデータベースにリカバリーする方法です。
クラウド・ディザスターリカバリーディザスターリカバリーリソースのどの部分をクラウドでホストするにしても、それらを実行するのに最適なクラウドプラットフォームを選択する必要があります。このトピックの詳細については、この記事の範囲外ですが、ベンダーの選択に関する記事で役立つ指針を見つけることができます。
クラウド・ディザスターリカバリー最後に、データをクラウドにバックアップしたり、いざという時にクラウドからデータを復旧させるバックアップとディザスターリカバリーソフトを選択します。
RSSフィードを取得する
