logo

クラウドの落とし穴!トホホな失敗エピソードを一挙紹介!

CNET Japan Ad Special2012年03月07日 11時00分
  • このエントリーをはてなブックマークに追加
ニフティクラウドみんなのかわら版

コストを削減し、システムの可用性を高めるクラウドサービス。そうしたメリットが多いのにもかかわらず、見切り発車で導入し、失敗する残念なケースは多い。
ここではそんな『落とし穴』にハマってしまった失敗例を元に、正しいクラウドの知識を身につけ、最適なクラウド導入が実現できるヒントを紹介します。

落ちる前に押さえとけ・・・、意外と多いな 落とし穴、、、蔵宇道 守

コスト編

ケース1
「ページビューが急増!課金がバーストして死亡」・・・のケース

解説

 これは明らかに「課金の選び方」をミスったパターンですね。キャンペーンサイトなどを展開する広告系の企業などがよくハマる例です。ページビューがそんなに伸びないと見積もったんでしょうね。

 ソーシャルメディアを利用したキャンペーンサイト立ちあげなどの際に、スモールスタートが出来、短期利用が容易なクラウドを利用した選択は間違っていなかったかと思います。しかし、ソーシャルメディア経由のアクセスは見積もりが困難なのが現状。そして、アクセスが殺到しても、クラウドはパンクすることなくユーザーを受け入れ続けてしまいます。スモールスタートが特長のページビュー課金ビジネスですが、アクセス数に比例して売り上げも伸びるようなビジネスモデルにしない限り、この穴に落ちてしまいがちです。

解決のポイント

 クラウドの料金体系は「月額課金制」「従量課金制」「ページビュー課金制」など様々なタイプがあります。例えば、使った時間や容量分だけ請求される「従量課金制」はコストの最適化に向いていますが、大量アクセスが見込まれるサイトや、安定期に入ったサービスなどでは「月額制」が結果的に安くなるでしょう。サービス種類や時期によって、適切な料金体系を選ぶ事が重要です。また、利用するクラウドサービスにどういった料金体系のバリエーションがあるのかを把握しておく事もポイントでしょう。

ニフティクラウドなら従量課金と月額課金が選べる

▲失敗エピソード一覧へ

ケース2
「既存システムと同じスペックでクラウドサービスへ移行したら、今よりコストがあがってしまった」・・・のケース

解説

 入れ替え前のシステム稼働率を把握されていましたか?もともと移行前の稼働率が数%ではありませんでしたか? 普段からシステム稼働率をチェックしていないままクラウドに移行すると、この穴にハマってしまいます。

解決のポイント

 クラウドへ移行する前に、既存環境の稼働率や使用状況をモニタリングして、「システムの棚卸し」をしてみましょう。オンプレミス環境では予算や設置環境の都合などで容易に増設できないため、将来を見越して多めにシステム投資をしがち。

 しかしクラウドサービスは、「さしあたって必要な量」を借り、必要に応じて追加が簡単にできる事が利点です。

 それに……システムに関するコストはサーバー代だけ、と思い込んでいる方も多いようですが、システムの「トータルコスト」とは、サーバー代だけでなく、ラック代、電気代、インターネット側の接続費、ネットワーク機器費用、サーバーの保守費用、そして運用者の人件費など複合的なはず。こうしたトータルコストで比較する習慣をこの機会にぜひ意識してみてください。

 特に既存環境とクラウドをトータルコストで比較した時に、クラウドサービスの優位性が見えてくると思います。

▲失敗エピソード一覧へ

ケース3
「予想外にネットワーク転送料がかかった」「早い回線を作ってもらったのに、通信がものすごく遅く感じる」・・・のケース

解説

 クラウドへの通信料として、小額ながらネットワーク転送金が設定されていることは一般的。また、速度に関してはクラウドサービスまでのネットワーク的な距離や物理的な設備よって差が出ます。コンテンツ配信やアプリをダウンロードさせるサービスなど、大容量のコンテンツを多数のユーザーに配信するサービスや、BCP対策等で社内のファイルサーバーやデータベースサーバーといった、データサイズの大きなサーバーをクラウドへ移行した際はこの点に注意が必要です。

 使い方によっては、予想外のネットワーク転送料がかかったり、必要な速度が出ないなど問題が発生します。

解決のポイント

 クラウドサービスによって異なりますが、中にはネットワーク転送料が10テラバイトまで無料なクラウドサービスもあります。各サービスの特性をきちんと把握したうえで、利用予測を立て、コストを見積もれば、ネットワーク転送料のトラブルは回避できるはず。また、回線速度は、クラウドサービスや設定によって転送容量・速度が異なるので、事前確認をしておくことがおすすめです。

 特に、海外のデータセンターを使ってBCPを計画している場合、ただ単に海外に移せばよいと考えるのではなく、海底ケーブルの転送速度やトラブルの可能性、あるいはそのデータセンターが設置されている国の治安や政情なども考慮しておく必要があります。

ニフティクラウドならネットワークが最大10テラバイトまで無料!

▲失敗エピソード一覧へ

ケース4
「委託先の会社の倒産に伴いまして、我々が使用中のサービスも止まりました」・・・のケース

解説

 その委託会社はクラウドサービスをカード決済で契約していたのではありませんか?クラウドサービスに限った話ではありませんが、クレジットカードの与信が通らないことが判明すれば、契約は切られてしまい、サービスは停止されてしまいます。

解決のポイント

 信頼できるパートナー選びを心がけることはもちろん、言語が通じる国内事業者を選んでおくのもよい策です。そういった事業者は万が一の事態に陥っても、支払い主の変更手続きに直接対応し、解決してくれる可能性があります。こうしたリスクを回避するために、国内のクラウドサービス事業者を指定しておくことも対策だといえます。

 または、委託先に開発費や運営費とセットで丸投げせずに、「サーバーの借り主」だけは自社名義にしておくことなども防衛策でしょう。

▲失敗エピソード一覧へ

セキュリティ編

ケース5
「ファイアウォールって何?セキュリティはクラウドサービス側の仕事でしょ?」・・・のケース

解説

 そもそも、これまで自社でシステムを運用している中でセキュリティについて考え、対策してきましたか?クラウドサービスに移行しても、これまでと同様にセキュリティについては考えなければいけません。

 もちろん、多くのクラウドサービスはサービス自体のセキュリティの高さはユーザーが簡単に設定可能なファイアウォール機能や操作ログ管理といった機能搭載し、従来よりも簡単に、低コストかつ高度な対策手段を提供しています。

 しかし、クラウドサービスがいかに高度なセキュリティ対策を提供していても、ユーザー自身が無意識では意味がありません。

 ファイアウォールを全開にしている運営者がしばしば見られます。これは大量の現金を抱えて全裸で歩いているようなもの。非常に危険です。

解決のポイント

 ハードウェア自体が手元にないクラウドでの安全管理は、まず「意識改革」から。

 クラウドは機器やネットワーク設備などインフラを丸ごと借りるサービスを利用していると再認識しましょう。

 パブリッククラウドは文字通りオープンな場所です。社内の閉じたネットワークを管理する手法は通用しませんので、今一度セキュリティ対策を考えてみましょう。クラウドに取り組む事は、自社のセキュリティ対策を見直すいい機会になるかもしれません。

ファイアウォールやSSL証明書など、充実したセキュリティ機能

▲失敗エピソード一覧へ

ケース6
「コントロールパネルのアカウントを開発会社と共有した。後日、テスト用サーバーを勝手に消されていた」・・・のケース

解説

 開発・運用上の問題で、サーバーの作成・削除の権限をもったユーザーがたくさんいることは良くあります。複数の部署や開発会社にまたがって、ひとつのアカウントを利用していて、なおかつ役割に合わせて権限をコントロールしていなかったことが、操作ミスや管理トラブルを招いたようです。

解決のポイント

 担当者の役職や職権に合わせて柔軟に権限が設定できるクラウドサービスを選択することで回避できる問題です。

 たとえばニフティクラウドなら、「サーバー作成・削除ができる」権限など、権限設定をした状態のアカウントを複数作成する事が出来ます。また、各アカウントで実行した操作のログも全て記録されます。こうした機能の有無も、クラウドサービス選定の項目のひとつです。

充実したアカウント管理機能で利便性やセキュリティが向上

▲失敗エピソード一覧へ

ケース7
「SSHキーを紛失し、ログインできません。二度と入れない気がします。」・・・のケース

解説

 SSHキーを用いたサーバーへのログイン方法はクラウドサービスでは一般的。この方法は、高いセキュリティを誇る反面、管理や操作に失敗するとサーバーに誰一人としてログインできなくなる問題があります。管理不能のままサービスを継続している「開かずのサーバー」がクラウド上にはかなりの数があるようです。SSHキーの問題に限らず、ファイアウォールやネットワーク周りの設定など、OS内部の操作の失敗によってこの問題に陥るケースは企業規模や利用形態を問わず、多いようです。

解決のポイント

 クラウドサービスによっては、サーバー状態に影響されないリモートコンソール経由でのサーバーアクセス手段や、有償・無償サポートによる回復操作実行など、救済措置が用意されていることもあります。

 また、こういうもしもの場合にそなえて、きめ細かなサポートが用意されているクラウドサービスを選択することも安全です。

サーバーのコンソール画面をコントロールパネル上で確認・操作
運用監視から導入支援・運用代行

▲失敗エピソード一覧へ

サービスレベル/機能編

ケース8
「『クラウドはサービスが落ちない』と思っていた!」・・・のケース

解説

 オンプレミス環境で起こりうる故障や障害は、当然クラウドでも発生しています。違いは、クラウドサービスがユーザーに影響をできるだけ見せずに、故障や障害に対処してくれる事です。しかし100%ではありません。そこで、クラウドサービスはこうした故障や障害発生時に対応する機能をユーザーに提供しており、こうした機能をうまく使って可用性を高める事が出来ます。

 この問題はユーザーのクラウドに対する思い込みと、現実から来る、クラウドに対する「幻想」と言えます。

解決のポイント

 クラウドは、一般的なシステムと比べ、それ自体が遥かに高い可用性で設計されています。安定的なサービス継続こそがクラウドの生命線だから当然ですが、とはいえシステムを無防備にしておくことは禁物です。

 クラウドサービスが提供している、ロードバランサや複数ディスク分離、HA機能など、高い可用性を実現する機能を活用しましょう。

 また、クラウドサービス事業者ごとに保証サービス品質(SLA)や保証される範囲は異なります。

 事前に十分にチェックして、クラウド上のインフラが停止した場合に備える設計をしておきましょう。

信頼性への取り組み ~BCPを支える対応~

▲失敗エピソード一覧へ

ケース9
「実は、自分の使っているOSに対応していなかった」・・・のケース

解説

 実はUbuntuやDebianなどのユーザーはこのようなケース陥りがちなようです。たしかにこれらのOSに対応しているクラウドサービスはまだまだ少ないと言えます。

解決のポイント

 一方、UbuntuやDebianに対応したクラウドサービスも除々に増えつつあります。 一例をあげるとニフティクラウドは最近対応を完了しました。

 自社システムで各OSに最適化した運用ツール等を作り込んでいたりした場合、OSの変更は意外と大きなコスト増要因になります。きちんとOSに対応しているか確認しましょう。

ニフティクラウドならUbuntu 10.04にも対応

▲失敗エピソード一覧へ

ケース10
「クラウドと言えば伸張性だよね。だからスケールアウトも自動でやってくれるでしょ?」・・・のケース

解説

 たしかに柔軟な伸張や縮小はクラウドサービスの強みです。しかし原則としてスケールアップ・スケールアウトはユーザーが自ら判断して対処するか、適切なしきい値の設定などを経て自動化しておくことが必要です。

解決のポイント

 もちろんクラウドサービス事業者によっては、簡単にスケールアウトする仕組みを提供してくれています。クラウドサービスを選定する際に、そのサービスの特性や内容、仕様などを十分に確認しておくほか、クラウドへ移行しようとしているシステムやアプリケーションが、スケールアップやスケールアウトに対応しているのかどうか見直しておくことが重要です。

 クラウドは、管理効率の向上やコストの圧縮を実現する手段を提供してくれますが、有効に使えるかどうかはユーザー次第です。

オートスケール機能で自動的にサーバー生成・負荷分散

▲失敗エピソード一覧へ

まとめ

あなたの使ってるクラウドサービスは「クラウドもどき」じゃないですか?

 昨今、「クラウド」と呼ばれるサービスは多種多様に増えました。

 しかし、中には、サービスの担当スタッフが作業依頼のある度に必死に手動で対応していたり、機能や品質が要件を満たさないような、とても「クラウド」とは呼べないサービスもまだまだ散見されます。

 今回の記事で掲載されたノウハウを活用すれば、そうした「クラウドもどき」を避けることができるでしょう。

▲失敗エピソード一覧へ

都市伝説的な「クラウドへの幻想」を抱いていませんか?

 クラウドは間違いなくコスト削減に貢献します。しかし、システムの種類や規模、用途によっては向き不向きがあります。

 それに何でもかんでも代行してくれるわけではありません。

 効率化やコスト削減に有効な手段を多く提供してくれますが、適切に管理・運用するスキルは従来どおり必要とされます。

 クラウドを過剰に期待し過ぎる「クラウドへの幻想」を解消して、クラウドの本当のメリットを最大限に活用してください。

▲失敗エピソード一覧へ

-PR-企画特集