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

ここはDell EMC商事IT企画部。今年からIT企画部に配属された英治くんが頭を抱えています。

さて、パブリッククラウドを使い始めたはいいが効果が得られていない、もしくは利用を検討しているが冒頭のような懸念があり、いまだに利用に踏み切れていない読者もいるのではないでしょうか。新芽先輩が指摘するように、パブリッククラウドに従来のオンプレの思想を持込むことで「本来パブリッククラウドで期待される効果が十分に得られていない」といった事例が見受けられます。今回はパブリッククラウド利用においてよくある失敗談とその解決策を前後編2回で整理します。

コストが下がらない

パブリッククラウド利用で良く聞く声として、思ったほど安くない、むしろ高くなったといった意見があります。

連載第3回でも述べたように、パブリッククラウドを新規に利用することで、新たなスキルの習得が必要、パブリッククラウドの技術に精通した要員の追加といった、運用コストが増加する要因があります。

また、環境自体の利用料においても、VMwareやHyper-Vを利用した仮想化集約を行うことが当たり前になった昨今ではオンプレ環境もコストが下がりきっており、実際に筆者が担当したお客様企業においても『オンプレと同様の使い方』でパブリッククラウドの方が安価となるケースは極めて限定的です。

厳しい見方をすると、コストを期待してパブリッククラウドを使うこと自体がある意味失敗とも言えますが、しかしながら、多くの企業において、ITの活用計画や社内の稟議を通すうえで、コスト効果の言及なしではパブリッククラウドの活用は無い、という事実もあるかと思います。

先ほど『オンプレと同様の使い方』という表現をしましたが、パブリッククラウドではオンプレ環境とは異なるパブリッククラウドならではのコスト削減の手法をとることができます。

今回はパブリッククラウドでコストが下がらないケースにおける、4つの原因とその解決策を紹介します。

(1) 高負荷を想定した過剰なサイジング

オンプレ環境では将来的に見込まれる業務増や、一時的な高負荷を考慮した、余裕をもったサイジングを行うことが多いと思いますが、パブリッククラウドにおいて同様の考えで過剰なサイジングを行うことでコストが高止まりしてしまう可能性があります。

オンプレ環境では一度用意したCPU・メモリ・ディスクは使わなくなったとしてもその分お金が返ってくることはありませんが、パブリッククラウドではCPU・メモリのスペックや、ディスクサイズに応じた料金体系となっているため、業務の増減に応じてサイジングの見直し、最適化を行うことで、不要なコストを抑えることが期待できます。

またパブリッククラウドでは、負荷に応じてサーバー台数を動的に増減させるオートスケール機能が提供されており、必要な時に必要な分のリソースを適切に利用することでコストの削減が期待できます。(図1)

• 図1. 業務量に応じた柔軟なサイジング

(2) 使っていない時間帯もサーバーを起動

パブリッククラウドではサーバーリソースについて、起動時間に応じた従量課金での料金体系を使用することができます。オンプレ環境ではサーバーを起動しても停止してもさほどコストに影響がないことから、夜間含め24時間365日起動させたままで運用するシステムが多いですが、パブリッククラウドでは使っていない時間帯にサーバーを起動することは、コストが高止まりする一因となります。

24時間365日起動させたままの運用と比較し、夜間のみ停止する場合は25%削減、平日日中帯のみ起動させる場合は55%削減が期待でき、また、月末処理のバッチサーバー等で常時起動させる必要が無いサーバーの場合は、さらに削減効果が期待できます。(図2)

また、パブリッククラウドでは従量課金の他に、事前予約(リザーブド)の料金体系を利用することができ、従量課金で24時間365日運用を行った場合と比較し、40～60%程度のコスト削減が期待できます。

• 図2. 起動時間ごとの削減効果

(3) 大量のデータ通信量

パブリッククラウドで注意すべきコストとして、データ通信量に応じた課金があります。 多くのパブリッククラウドで主にクラウドからの外向き方向の通信についてデータ通信量に応じた課金を設定していることが多く、1日あたり100GB程度の通信が発生する場合は、月あたり3～4万程度の費用が発生します。

通信量はCPU、メモリ、ディスクサイズと比較し使用量が見えづらい部分ではありますが、クラウド移行を検討する際は業務の特性やシステム間連携を考慮し、オンプレ、パブリッククラウド間で特にダウンロード方向に大量のデータ通信量が想定される場合はいずれかの環境に片寄し、環境跨ぎの通信が発生しないようにシステムの配置を考慮する必要があります。

またシステム間連携については、後編で紹介する性能の観点でもトラブルになるケースがあるため注意が必要です。

(4) IaaSのみで構成

IaaSのみでシステムを構成していることによりコストが高止まりしているケースもあります。

オンプレの構成をそのまま、IaaSベースでクラウド上に再構築する場合、移行コスト・アプリケーション改修コストを最小限に抑えられる反面、構成はオンプレ時と基本的に変わらないため、パブリッククラウド移行によるコスト削減効果はほとんど無いという実態があります。

パブリッククラウドでコスト効果が期待できる方法として、オンプレ環境では利用者側で実施が必要なミドルウェア導入、可用性、スケーラビリティ、バックアップ、パッチ適用といった作業をクラウドサービス側でサービスとして提供するPaaSを始めとした各種マネージドサービスの利用が挙げられます。(図3)

例えば、冗長化されたデータベースサーバーを構築する場合、IaaSベースではデータベースソフトウェアのほか、冗長化のためのクラスターソフトウェアの導入、バックアップの設定といった作業が必要となりますが、例えばAWSではAmazon RDS、AzureではAzure SQL Databaseといったあらかじめ可用性やバックアップが考慮されたデータベースのマネージドサービスが提供されており、これらを利用することでオンプレと同様の機能を利用者側はコストをかけずに導入することができます。

• 図3. マネージドサービス料時の役割分担

今回のまとめ

今回はコストにまつわる失敗談について紹介しました。 後編ではパブリッククラウド利用時における性能と可用性に関する失敗談と解決策を紹介します。

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