IaaS導入の失敗を招く6つの勘違い
目的設定やセキュリティやSLAなどの失敗例

IaaS導入の”勘違い”を防ぐ方法

IaaS導入が勘違いや思い込みによって失敗に終わるケースが多々見られる。コスト削減、伸縮性、高い可用性といったメリットが強調されているが、十分な検討無しに実現できるほどIaaSは単純なものでもない。IaaS導入の6つの失敗例から、その対策について考えたい。

「IaaSに移行すれば”必ず”コストが削減できると思ったのに、実際は費用が増えてしまった!」「 IaaSは”自動的に”スケールアウトしてくれると思ったのに、運用監視の手間がかかるじゃないか!」勘違いや思い込みによって、IaaS導入が残念な結果に終わるケースが散見される。企業内情報システム、特に基幹システムにおいてIaaSは新しい技術であるため、コスト削減や柔軟性に関するイメージが先行し、担当者レベルの運用において問題が発生するケースが存在する。過度な期待を煽るような営業文句を鵜呑みにせず、失敗例から学び、業務の実態に即したIaaS運用を確立しなければならない。IaaSの構築から運用に至る、いずれのフェーズにおいても”落とし穴”が存在するからだ。

IaaS導入には「企画」「移行」「運用」の3フェーズがあると考えられる。企画段階では、プロジェクト指針の策定・共有、ベンダー選定、コスト見積もり等を行うだろう。移行段階では業務プロセスと整合をとりながら、セキュリティ等の各種設定を行う。そして、運用段階では利用状況の監視やIaaS運用の改善活動を実施する。次章からは各段階での失敗例を2件ずつ紹介したい。

 

IaaS導入の”勘違い”を防ぐ方法

IaaS導入の”勘違い”を防ぐ方法

■企画1:目的が不明確

「これからはIaaSだ!」という上層部の鶴の一声で決まったプロジェクトには”落とし穴”が潜む。IaaSありきで話が進むため、メリット・デメリットが客観的に精査されず、IaaSへ移行する目的が各担当者に腹落ちしない可能性が高まるのだ。そのため、IaaSとオンプレミスの切り分けの判断ができなかったり、IaaS移行に必要な作業実施について業務部門を説得できなかったりといった問題が発生する。

IaaS導入において、他のプロジェクトと同様、その目的やゴールを明らかにし、全社が同じ方向を向くよう努める必要がある。

■企画2:コスト計算の甘さ

「削減」と「最適化」は意味が異なる。IaaSの実態はコストの「最適化」である。サーバー資源の稼働率が低く、ピーク時以外にコンピュータ環境が利用されていないのであれば、IaaSで必要なときに必要なだけ利用し「最適化」によるコスト削減の恩恵を受けられる。しかし、もともとサーバー資源をフル活用しており、利用率の増減がほとんどないのであれば「最適化」の余地が少ない。むしろ、IaaSの運用をベンダーに委託する分だけコストが増加する恐れもある。

また、ベンダーによっては「月額課金」「従量課金」といった複数のプランが提供されているので、IaaS上で稼働させるシステムによって正しくプランを選択しなければならない。例えば、Webサービスの運用で従量課金を選択していたときに、突然アクセスが急増してしまった場合、コストも跳ね上がる計算になる。

コスト削減はIaaS導入の大きなメリットの一つであるが、何も考えずに導入してコストが減るほど単純な話でもない。現在のサーバー資源の利用率やビジネスモデルを勘案し、IaaSの利用方法を正しく選択できるようにしたい。

■移行1:業務部門とのすり合わせ不足

既存システムの移行には業務部門とのすり合わせが欠かせない。IaaS移行プロジェクトの目的が業務部門に浸透していない場合、移行作業に抵抗を覚える可能性がある。実際、IaaSへの移行に伴い、ログインの仕組みが変更になり、業務部門の各ユーザーが端末の設定変更に時間をとられるケースは多々あるだろう。

業務部門の関心は、IT関連コストではなく、自身の業務が滞りなく遂行できるかという点にある。IaaS移行は単なるコスト削減ではなく、災害等に対する業務継続対策・リモートオフィス化・内部統制・法令順守などの長期的な経営戦略であると位置付ければ、業務部門との方向性を一致させることが期待できる。

■移行2:ずさんなセキュリティ

セキュリティ対策はハッカーとの”いたちごっこ”だ。どんなに対策をとっても終わりはない。そのため、最新のセキュリティ対策をベンダーに転嫁できるIaaSはセキュリティ関連のスキルやコストを補う手段として大きなメリットを提供する。ただし、IaaSが提供するのはセキュリティの「機能」であり、セキュリティ関連の設定を実施するのは運営者の責任だ。驚くべきことにファイアーウォールなどの基礎的な設定でさえ忘れてしまう場合もある。アカウント管理や権限設定についてもオンプレミスの運用と同様に、セキュリティポリシーを策定し、正しく運用しなければならない。

IaaSベンダーにとっても杜撰なセキュリティ設定を放置するのは喜ばしいものではない。ベンダーによっては豊富なセキュリティ機能やサポートサービスが充実してきているので、セキュリティに関する知見の少ない情報システム部でもIaaSの運用も容易になってきた。

■運用1:スケールアウトの基準が未検討

IaaSのメリットの一つに伸縮性がある。しかし、どのタイミングでスケールアウトを行い、どのような場合にスケールアップを行うかといった判断を行うのは運営者だ。伸縮の基準が検討されていなければ、IaaSの特徴を最大限に活かせず、結局オンプレミスの場合と同様、不必要なサーバー資源にお金を払ってしまったり、キャパシティ不足に陥ったりする懸念が残ってしまう。

IaaSベンダーによっては、ある閾値を設定しておくだけで、スケールアウト・スケールアップを自動で行ってくれる機能を提供している。伸縮性をベンダー任せにせず、コスト意識を保っておかなければならない。

■運用2:サービスレベルの誤解

IaaSは高い可用性が実現されるよう設計されているが、故障や障害が発生してしまうのは避けられないのが実状である。そのため、IaaSベンダーはSLA(サービス・レベル・アグリーメント)を締結し、どの程度の稼働率を許容するのか、運用者と合意している。よくある誤解はSLAを保証と勘違いすることだ。例えば「稼働率が99.99%」と謳っている場合でも、その稼働率を下回る場合がある。99.99%を下回った場合は返金などによる補償がある、という合意がSLAの意味するところである。

高い可用性を求めるシステムの場合、IaaS ベンダーが提示するSLAを見るだけでは十分ではない。これまでの稼働率の実績のように、できるだけ実態に合った指標を用いて、可用性の検討を行う必要がある。

最後に

IaaSは過度の期待が先行してきた面があるため、勘違いや思い込みによるIaaS企画・移行・運用の失敗が発生している。IaaSを宝の持ち腐れにせず、コスト削減や伸縮性といった特長を最大限に活用できるようにしたい。

 

編集:ビジネスon IT運営事務局(基幹特化型IaaS班)

メールマガジンを購読する

Pocket

コメント

「基幹特化型IaaS」のイベント・セミナー

開催
事例講演  ユーザーが語るSAP導入の決意