パブリッククラウド失敗談！よくあるトラブルと解決策(後編)

前回はコストにまつわる失敗談とその解決策を紹介しました。後編となる今回はパブリッククラウド利用における性能と可用性に関するよくある失敗談とその解決策を整理します。

ここはDell EMC商事IT企画部。今年からIT企画部に配属された英治くんが新芽先輩と会話をしています。

性能がでない

これからパブリッククラウドの利用を検討する際に、多くの方が気にする項目にオンプレ環境と比較した性能があるかと思います。

結論から言うと、パブリッククラウド環境においても、何百万ユーザーが利用するソーシャルゲームやショッピングサイトを稼働させている実績もあり、非常に高い性能を出すことは可能です。

それでもオンプレ環境とパブリッククラウドとでは当然性能特性が違う部分もありますので、現状のオンプレ環境での構成のままパブリッククラウドに移行して問題が無いかは事前検証が重要です。

(1) ディスクサイズの観点のみでのサイジング

パブリッククラウド環境利用時に性能面で最も注意が必要なものがディスクです。

オンプレ環境の場合、IOPSの制限をしなければ、小さいディスクサイズであっても高いIOPSが利用できます。近年のSSDの普及によりオンプレ環境でもSSDを搭載したストレージを利用することが増えていますが、SSDを搭載したストレージでは数万IOPS、ハイスペックなストレージを使用している場合は数十万IOPS以上のディスク性能が利用でき、このようなIOPS性能を環境によっては100GB程度の小さなディスクでも利用可能です。

一方でパブリッククラウド環境では、ディスクサイズに応じて利用可能なIOPS性能が設定されることが多く、小さいディスクサイズの場合は、利用できるIOPS性能も小さく設定されることがほどんとです(図1)。そのため、ディスクサイズにのみ着目してサイジングを行うとIOPSが足りず、性能が低下する可能性があり、オンプレ環境で利用しているIOPSを正しく把握し、必要なIOPSの観点でもサイジングの妥当性を確認する必要があります。

• 図1. ディスクサイズ別のIOPS性能

また、パブリッククラウドサービスによっては、サーバー側で利用可能なIOPSやスループット上限を設けている場合があり、選択したサーバーがディスク性能を利用できるか確認が必要です。

(2) ネットワーク遅延を考慮しない分散配置

オンプレ環境の同一データセンター内に閉じた通信であれば、一般的にはレイテンシーは1ms以内ですが、オンプレ環境とパブリッククラウド間の場合は利用するNW経路にもよりますが10ms程度のレイテンシーは見ておく必要があります(図2)。

そのため、頻繁に通信が発生するシステムをオンプレ環境とパブリッククラウドに分散配置してしまうと、ネットワーク遅延による性能低下が懸念されます。

• 図2. オンプレとパブリッククラウドのネットワーク遅延の違い

可用性が低下した

可用性については、オンプレ環境とパブリッククラウド環境で特に考え方の違いがあるため注意が必要です。

パブリッククラウドでは複数サーバーで分散することを前提として、システム全体としての可用性サービスレベルとして設定されている場合もあり、純粋に単一サーバーごとのサービスレベルを比較した場合、パブリッククラウド移行によりサービスレベルが低下する可能性があります。

また、メンテナンスもオンプレ環境とパブリッククラウド環境の違いを考慮していないと、急なメンテナンスによるシステム停止や想定以上のメンテナンス回数により、オンプレ環境よりも可用性が低下してしまう場合が考えられます。

(1) サーバー単位での可用性サービスレベルを求めている

オンプレ環境では可用性のサービスレベルはサーバー単位で設定されることが多いですが、パブリッククラウドのサービスレベルはサーバーが複数台で構成されていることを前提として定められていることがあり、高いサービスレベルが謳われていてもサーバー単体ではそのサービスレベルを受けられない場合があります。

近年はパブリッククラウド各社で単一サーバーに対するサービスレベルも提示していますが、それでも複数サーバーを前提としたサービスレベルと比較すると低いサービスレベルとなっています (図3)。

• 図3. 各社が提供するIaaSのサービスレベル

オンプレ環境で単一サーバー構成の場合、単一構成のままでパブリッククラウド移行してしまうとオンプレ環境よりも低いサービスレベルとなってしまいますが、パブリッククラウド移行時に複数サーバーの構成に見直しを行うことで、オンプレと同等の高いサービスレベルを受けることができるようになります(図4)。

• 図4. パブリッククラウド移行時の構成見直しによる可用性の違い

(2) メンテナンスをオンプレ基準で考えている

サービス停止が伴うメンテナンスを行う場合、オンプレ環境では何か月も前から日程調整を行ったり、メンテナンス日を年間計画として予め設けておくなど、事前に十分な業務調整を行った上で設定されることが多いのではないかと思います。パブリッククラウドサービスにおいては、メンテナンス時間の調整についてもオンプレ環境と同じレベルを求めることは現実的ではありません。

多くのパブリッククラウドにおいては、利用企業側でメンテナンスのタイミングを調整することは出来ず、ある程度の猶予は与えられるものの、通知された期間内でサーバーの再起動を行う必要があります。各社メンテナンスについては事前に通知されることは定められているものの、具体的にどの程度事前に通知されるかについては明記されておらず、従来通りの事前の業務調整は困難です。そのため、オンプレ環境からパブリッククラウド移行を行う場合は、急なメンテナンスにも対応できるようにメンテナンスの取り決めについて見直しを行う必要があります。

また、Azureの可用性セットのように、パブリッククラウドではメンテナンス時にシステムが全停止しないような仕組みも提供されているため、こういった仕組みを利用しシステム構成を見直すことも対策の一つです。(図5)

• 図5. メンテナンスのサービスレベル見直し例

今回のまとめ

後編の今回は性能と可用性にまつわる失敗談について紹介しました。

さて、クラウド活用ノウハウは今回で終了となります。これまで、クラウド活用にあたって以下の観点で連載をしてきました。

・クラウドの選択肢
・クラウド利用におけるガバナンス
・クラウドの活用で運用は楽になるのか？
・クラウドの失敗談

各回で見てきたようにクラウドを利用する際にはオンプレ環境の技術、運用、ルールからクラウドに適したものに継続的に見直しを行っていく必要があります。

今回の連載を通して、クラウド活用にあたっての検討、情報整理にお役立ちいただければ幸いです。

(※) 本連載に登場する企業名、人物名はすべて架空のものです。