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

[梁取雅夫／矢吹豪，博報堂アイ・スタジオ]

失敗しないベンダー選び

7.RFPの策定　

　経営陣への説明も通って、いよいよ本格的に導入プロジェクトのスタートになるとペースは急に加速しました。賛否両論ありますが、私たちはRFPを自分たちで作りました。これを基にベンダー各社が提案書を考えてくれるので、できれば細かい所まで詰めておくのが良いと思います。

　私たちの場合、その辺りが少し甘かったこともあり、ベンダー各社へのRFP展開後は質問がたくさん来て対応が大変でした。また、誠意をもって各社に対応するためには、一ベンダーからの質問であっても、その回答は全ベンダーに展開するなどの配慮も必要です。RFPについては「受ける側」としての対応はそれなりの量を行っていると思っていましたが、受けるのと依頼するのでは大違いで、ベンダーには迷惑を掛けることもありましたし、私たち自身も勉強になりました。

8.ベンダー選定

　提案書の確認が一通り完了するとプレゼンの段取り、評価シートの作成も行わなくてはなりません。評価シート作成の際は特に慎重な作業が必要です。私たちも、スタッフ全員で「自分たちのクラウドの目指すものは何か、それに必要なものは何か、何を重視して決めるのか」ということを整理しておきました。

　もちろん、当初の想像を超えた考え方や提案は非常に参考になります。しかし「何を重視するのか」という中心におくべき項目が見えなくなってしまうのはとても危険です。選択基準が明確でなければ、各ベンダーのプレゼンターの話し方などによっても評価がブレがちになってしまうからです。こうしたことを回避する上でも、評価方法など「自分たちのサービスの中心にあるものは何か」を再度整理し、納得しておく必要があります。

弊社が使っていたベンダー別ポイント評価の概要

　私たちの場合、一般的なパブリッククラウドでは補えないカスタマイズができるかどうかが重要なポイントになりました。具体的には、将来的な運用コストも考えて、ゲートウェイ型のIDS機器、物理ファイアウォールの導入、メンテナンス用の閉域網との接続、バックアップ体制の強化、主回線の拡張性などが主なものです。

9.インフラとベンダーの決定

　そしていよいよインフラとベンダーの決定です。ベンダー名は明かせませんが、弊社の場合、最終的には「プライベートクラウドを導入する」という結論に至りました。理由としては2つあります。

　一つはセキュリティ面の懸念です。弊社の業務要件に照らすと、セキュリティを確実に担保するためには、何も手も加えないパブリッククラウドでの運用は難しく、カスタマイズは避けることができない状況でした。事業者側が運用する物理機器を含めて、カスタマイズに応じるパブリッククラウドの提供事業者を見つける必要がありましたが、当時はなかったのです。

　もう一つはトラブルの際の懸念です。トラブルが起きたことを想定した場合、パブリッククラウドだと問い合わせ窓口などに頼ることになり、タイムリーな状況把握が期待できません。また、共用機器にインスタンスが広く分布している状況では状況把握そのものも難しいと考えられました。プライベートクラウドのように独立した環境の方が、クラウド提供事業者側も私たちも的確に対応できると思われたためです（ただ、今後クラウドの信頼性がさらに向上し、クラウドを利用する場合のメリット、デメリットが、提供事業者と利用者側で共通の認識になってくると、こうした考え方も変わってくるかもしれません）。

　これらは前述した弊社サービスの要件を満たす上で、どうしてもクリアしなければならない課題だったのです。

10.仕様調整・構築

　ここまで進めばあと少しです。サービスの方向性とインフラはもう決まっていますから、あとは足りないものをどう足すかという具体的な話を進めることになります。特にプライベートクラウドの中では非常に多くの仮想マシンが動作しているので、主回線はいつでも10Gまでは拡張できるように準備しました。ベンダーとの定例会を開催して課題を一つ一つつぶしていくのとほぼ同時並行で、システムは着々と完成に近づいていきました。

11.勉強会やお披露目の準備

　構築を進める一方で、新しいインフラを使ったサービスの受注準備も進めなくてはいけないので、セールスシートや説明会の準備も始めました。提供時期の折り合いがつき次第、状況説明を行いながら販売も少しずつ始めていきました。

　一方、概要は分かってはいるものの、腰を据えて使ったことのない機器を使い始めることになるので、私たち自身が勉強して操作の理解を行わなければいけません。本番同様のプレ環境をベンダーに提供してもらい、擬似的に運用を行いながら、質問のやり取りなどを進めます。使ってみるといろいろな疑問や課題が結構出てきます。何度かベンダーの技術者の方を交えて勉強会も開催しました。

終わってみると半年程度

　導入を進める上で考えることや作業はたくさんありますが、振り返ってみると構築まで含めて約半年程度でした。特にパブリッククラウドも検討している場合、その調査には思う以上に時間が取られるので、ここは最初に片付けておいた方がよいかと思います。

◇

　以上が、ホステッドプライベートクラウドを導入するまでに、私たちが検討したこと、行ったことの全てです。

　博報堂アイ・スタジオはプライベートクラウドを導入してもうすぐ丸二年になります。今ではパブリッククラウドにもいろいろと機能が追加されてきていることもあり、パブリック／プライベートクラウドの選択について、一概にこうだとは言えません。

　しかし、少なくとも選定当時に思っていたことは、「弊社の要件に照らすと、パブリッククラウドを“そのままでは”使うことはできない」ということでした。これだけははっきりしていました。弊社の要件に照らすと、（当時は）求める機能が明らかに足りていなかったからです。前回、弊社の事業要件とインフラに求める要件を紹介しましたが、そちらをあらためて参照いただくとパブリックとプライベートの選択を考える一つの参考になるかと思います。

　繰り返しになりますが、弊社では当初、「カスタマイズができればパブリッククラウドでも問題はない」と考えていたので、プライベートクラウドを構築するのか、パブリッククラウドをカスタマイズするのかは、RFPを展開したタイミングになってもハッキリとは決めきれていませんでした。

　しかし、「一番重要なのは社の戦略に沿ったサービスを提供すること」という軸は常にスタッフみんなで共有していました。ですので、当時、仮にパブリッククラウドを選んでいたとしても、現在はプライベートクラウドと呼ばれるものになっていたと思います。このように振り返ると、コストの安さ、有している機能など、各パブリッククラウドのスペックではなく、自社がやりたいこと、やるべきことを基に最適なインフラを検討した点が、やはり一番のポイントだったように思います。

今回のまとめ 〜プライベートクラウドのメリット・デメリット〜

メリット

• リソースを他と共有せずに完全に独自で持てるので影響を受けない
• 必要ならカスタマイズができる
• アップデートのスケジュールを独自に管理できる
• パブリッククラウドと異なりトラブル時に状況を把握しやすい
• セキュリティやI/Oも必要な分だけカスタマイズで仕上げられる
• クラウドの裏側の仕組みが知見としてたまる
• 物理運用に比べて提供スピードは格段に上がる

デメリット

• 一定量のリソースを抱えることになるので計画は慎重に行わなくてはならない
• 一度始めたら途中でやめられない
• クラウドの特性や制約は受ける（I/Oなど）
• 拡張する単位がそれなりに大きいので、先が見えないと難しい

著者プロフィール

梁取雅夫（やなとり まさお）

博報堂アイ・スタジオ システム開発部 部長 テクニカルディレクター

2005年モバイルサイト制作会社の創業に参画、約7年間の会社経営を経て、2012年博報堂アイ・スタジオへ入社。技術部門の取りまとめを行う傍らプライベートクラウドの立ち上げに寄与する。

矢吹豪（やぶき たけし）

テクノロジーソリューション本部 シニアテクニカルディレクター

モバイルベンチャー企業を経て、2004年博報堂アイ・スタジオ入社。現在は企画全体を見据えた技術領域でのシニアテクニカルディレクターとして従事し、自らも、LAMP環境でのPHPプログラミングから、ミドルウェアチューニングまで行う。

博報堂アイ・スタジオ