初めてのクラウド導入、パブリック／プライベートクラウドの失敗しない選び方：事例：博報堂アイ・スタジオの高付加価値クラウドへの挑戦（2）（2/3 ページ）

徐々に見えてきたパブリッククラウドの限界

5.初期の確保リソース量検討

　機能の検討も必要ですが、量の問題もあります。機能要望のまとめを進めていくにつれて、パブリッククラウドでできること／できないことも見えてきます。また、サイジングを試行錯誤でき、調整がしやすい点がIaaSのメリットといわれていますが、クラウド提供事業者（以下、ベンダー）に話を聞いていると、初期の段階ではある程度のリソースを確保する必要があることなども分かってきます。

　なお、この時点で弊社では二つの方向を考えていました。一つは「パブリッククラウドのリソースを一定量確保することでカスタマイズを行ってもらえないか」という方向性。もう一つが「プライベートクラウドを作る」ことです。弊社が検討したのは、パブリッククラウド提供事業者のデータセンター内に占有リソースを確保し、そこに自社の要件に応じてカスタマイズしたプライベートクラウド環境を築く、いわゆる「ホステッドプライベートクラウド」です。

　ただ、いずれにしても選定当時（※）、IaaSのカスタマイズについては100〜300台規模のリソースを運用しないと交渉できないことも分かりました。そこで弊社では、従来の物理環境でのホスティング実績などを基に考慮して、サーバー約200台程度のリソース量を初期リソースと想定することにしました。ただ、この時点では、まだパブリッククラウドとプライベートクラウドのどちらかにするか、決断することはできませんでした。

※同社が選定検討していたのは約2年前

6.収益シミュレーション

　インフラを刷新した場合の収益シミュレーションを考える上では、前述のようなサービスの基本スタンスを決める必要がありました。提供価格を決めるには、どのサービスが競合になるのかを考えなくてはいけません。

　その点、サービス提供基盤としてパブリッククラウドを選ぶと、コストは抑えられますが、より高品質なサービスを提供する上では、インフラを運用するエンジニアが必ず必要になります。サーバーは“止まらないサービス”である以上、エンジニアもシフトを組んで対応することが必要です。特に弊社は、前述のように、広告からの誘導を受け止めるWebサイトの構築・運用をサービスとして提供しているわけですから、高負荷、高トラフィックの中での可用性を何としても担保しなければならないわけです。

　弊社のクライアントはエンジニア部隊を持っている会社も、そうでない会社もあります。その点、クライアント側がエンジニア部隊を持っており、「サービスの運用管理は自社で行うのでインフラだけが欲しい」ということであれば、そもそも弊社を選ばず、自社でパブリッククラウドを導入するでしょうから、そうしたクライアントはターゲットから外しました。

　では、どういうクライアントが弊社の顧客になるのかといえば、高品質な運用管理がもたらす弊社ならではの高付加価値を求めるクライアントです。従って、弊社としては、「物理環境でホスティングサービスを提供してきた今までの使い心地を全く損なわずに、インフラの仕組みだけをクラウドに置き換えるというサービスを作るべきだ」と考えました。「従来と変わらぬ付加価値を提供しながら、インフラをクラウドに置き換えることで、圧縮したコストをクライアントとアイ・スタジオの双方に還元できればよいのではないか」という考え方です。

　サービスの方向性をそう決めてしまえば、「広告業界のビジネス事情を知り抜いた運用」という付加価値を担保するために、必要な予算を確保しやすくなります。人件費はもちろん、必要となれば、一般的なパブリッククラウドには設置されていないような高価な機器の導入・運用予算なども、社の戦略として確保可能となります。

　しかし、だからといって、「例えば1社で3カ月のキャンペーンを行うために、1000万もの機器を入れるという非現実的ことはしないし、リスクを孕んだまま運用するということもしない」――社の戦略実現に最適なインフラを選ぶ軸を得るために、まずはこうした「提供するサービスの方針」を明確化したのです。