連載の最終回として、アマゾン ウェブ サービス（以下AWS）のエバンジェリスト 玉川憲氏をゲストに迎え、本連載執筆者である株式会社adingo取締役小澤昇歩氏と同社エンジニア岩川建彦氏の3名による鼎談を実施しました。

AWSを選んだ理由

玉川：まずはじめに、cosmiでAWSが提供するクラウドサービスを採用した理由を教えてください。

岩川：サービスを始めるにあたり、フラットな状況から検討し始めました。想定していたサービスは、すでに連載でも紹介している「オーディエンスデータプラットフォーム」と呼ばれるもので、ユーザの行動履歴を集計し、それを行動ターゲティングに活かすというものでした。ですから、膨大なトラフィックが発生することは想像でき、一方で、それがどのぐらいの規模なのかがまったく想像できなかったのです。

玉川：つまり、処理能力が固定されたシステムは考えられなかった？と。

岩川：はい。それと、やはり新規サービスであり、莫大な予算があるわけではないので、できるかぎりイニシャルコストは抑えたかったということもあります。そういった状況要因から選んだのがAWS（アマゾン ウェブ サービス）でした。

玉川：いわゆるスモールスタート、そしてリーンスタートアップ（Lean Startup）というスタイルですね。AWSはこのスタイルにマッチしていると言われていて、今、アメリカでもその動きがよく見られます。

エンジニア的な視点、経営的な視点からAWSはどのように映りましたか？ そして実際に使い始めてみて、いかがでしたか。

岩川：エンジニアの立場としては、やはりいざ起動した後、どのぐらいのトラフィックを捌けるのかが心配で怖いという思いがありました。実際に運用を始めてからは、ほぼ管理画面からの操作でスケールアップできるのは本当に楽でしたね。また、減らすのもの簡単なので、持っていても活かし切れないリソースは縮小できるというメリットもありました。

小澤：経営的な視点で見ると、やはりプロジェクトを始めようと思い立ってから実際はじめるまでのスピード感に対してのメリット、そして、イニシャルコストが小さく、経営資源を有効に使えるというのが大きな特徴だと思っています。従来の広告配信サービスの場合、まずラックを借りて、サーバを購入して……というのを繰り返すケースが多かったですから。

岩川とも話しているのですが、100単位でサーバを増減できるシステムってそうそうありませんし、そして何よりAmazonというブランドに対する安心感が大きいですね。

玉川：ありがとうございます。それはすごく良いポイントですね。

以前、AWSというと、EコマースのAmazonが使用して余ったサーバを使って事業をしていると思われていたのですが、2006年にAWSの事業が開始された時点から、AWSの事業用にAmazonが使用しているものとは完全に別のデータセンターが準備されていました。もともとAmazonはEコマース事業を行う上で物理データセンターを運用しクラウドの技術を活用していました。そのビジネスを発祥の起源としているAWSは、お客様への安心感、信頼性を担保できていると自負しています。ちなみに、AWSの最大の顧客企業の1つがAmazonだったりします。

余談ですが、AWSにとって一番怖い顧客企業の1つもAmazonで、リテールをやっている最中、絶対にサーバを落とせないうえに、ピークが激しいケースが頻繁に起きています。グループであるからこその緊張感みたいなものでしょうか（笑⁠）⁠。

運用面から見たAWSの特徴

玉川：実際にサービスをリリースした後、AWSでの運用している中で、何か改善要望などありましたでしょうか？

岩川：気になったところですと、私たちはAutoScalingを使っていて、それがすべてWeb上の管理画面（AWSマネジメントコンソール）で操作できないところが気になっています。

玉川：おっしゃるとおり、現在、運用管理についてはほぼAWSマネジメントコンソール上で操作できるようになっていますが、AutoScalingの部分はまだサポートしていませんね（※1。

岩川：ぜひ、今後はそこも対応していただけると嬉しいですね。

玉川：エンジニアの方たちにとって、プログラミングを行ったり、APIを操作するのは慣れていることでもあるので、AWSは常にAPIによるサービスのサポートに注力しています。一方、AWSマネジメントコンソールは、ここ1年で大幅に力を入れている部分の1つでした。幅広いお客様にもお使いいただけるよう、日常運用にあたっては、基本操作はAWSマネジメントコンソール上でできるべきと考え、その機能拡充に力を入れています。

今ご指摘いただいたAutoScalingについても、他のユーザの皆さんからのご要望もいただいていますので、順次対応していきたいと考えています。

AWSの料金体系について

玉川：Amazonの特徴の1つに従量課金があります。この点についてはどう思いますか？ 日本企業の場合、予算制を引いているところが多く、導入時点に課題になるケースもあるといったことを耳にします。

小澤：弊社はそういったことはなかったですね。予算は決めていますが、もともと予算を決めないと新規事業が始められないという方針ではなかったので。もちろん、実際に始めてみていきなり1,000万円かかりました、とかではマズイですが、AWSはそういった部分もコントロールできましたから。

玉川：なるほど。では、粗く見積もりをして、ある程度の増減については許容していたということでしょうか。たしかに、インターネット事業の場合、スケールの幅が読めませんから、そうすることが正しいのかもしれません。

小澤：ええ。それに見方を変えれば、売上に従ってインフラの使用量が増える事業モデルなので、経営的な観点ではとても利用しやすいサービスだと言えますよね。つまり、AWSを利用しているコストが上がっている＝売上が増えているという構造を作れば良いわけですから。

玉川：先日、Amazon全体を見ているCTOのWerner Vogelsが来日して、未踏のエンジニアたちとディスカッションする場がありました。そこで、未踏のエンジニア彼らから「どういうスキルを身に付けることが（エンジニアとしての）付加価値が高まりますか？」という質問が上がったのです。それに対してWernerは「日本のエンジニアの技術力は大変素晴らしいので技術面では従来から身に着けたものを磨くことで十分だと思っています。ただ、あえていうとするとコストに関する感覚、嗅覚が弱いと感じています。インターネット時代のようにユーザが指数関数的に増大するサービスを開発する上では、その（コストという）感覚を感じる力を身に付けてほしいです」とアドバイスしていました。

これは先ほどのコストと売上の価値・バランスを取るのと同じことだと思っていて、物理インフラではなく、クラウドインフラをどのように活用していくかということにも通ずるのではと思っています。

小澤：私もそう思います。自社インフラではないインフラを利用する場合、エンジニア自身がそのインフラコストを見積もれるか、予測できるかというのはますます求められていくのではないでしょうか。

玉川：あとは技術的な視点で見たときに、リザーブドインスタンスを活用することも大切です。通常、AWSでAmazon EC2（Elastic Computing Cloud）とかAmazon EMR（Elastic Map Reduce）を利用する際はオンデマンドインスタンスになります。これは、従量課金、つまり利用時間に応じて課金されていくわけです。AWSでは、EC2やEMRを使用する際ににリザーブドインスタンスという料金体系も用意しています。これは、先に予約金（リザーブド）を支払うことで、一定の割合で時間課金が下がるというものになります[2]⁠。

ですから、ある程度事業が動き始めて、運用のリズムが見えてきた場合、リザーブドインスタンスをうまく利用することで、年間トータルコストを下げることが可能になるわけです。

小澤：cosmiはどっち？

岩川：別の事業ではリザーブドインスタンスを使っているものもありますが、cosmiはまだオンデマンドインスタンスです。まずはオンデマンドインスタンスでのコストを見極めてからでしょうか。

玉川：なるほど。おっしゃるとおり、現状を常に見直して改善していくプロセスが大切です。また、オンデマンド、リザーブドに加えてスポットというタイプもあります。これらをうまく組み合わせることができると、インフラコストを抑えるだけではなく、効率的な運用にもつながり、事業収益が上がるはずです。

岩川：ちなみに、これら3つの切り分けのポイントを挙げるとどういったところになりますか。

玉川：一番のポイントは安定時とピーク時のサーバ容量のパターンの見極めです。どのタイミングで、どのぐらいのピーク値が上がるのか、また見込まれるのか。普段はどれくらいを安定して使っているのか。そこを基準にして、オンデマンド、リザーブド、スポットというのを切り分けると良いと思います。年間を通してかなりの確率で安定して使っているサーバ容量はリザーブドインスタンスで、ピーク時や変動があるある部分はオンデマンドインスタンスで。そして、今すぐ実行しなくてもよくてより安い料金で実行したいときはスポットインスタンス、というように使い分けることができます。

他にも、サービスによっては、オンプレミス型のサーバや物理サーバとクラウドをどうやって安定してつないでいくが重要になるケースもあります。AWS Direct Connectと呼ばれる専用線接続サービスも開始しましたので、ある程度のネットワーク流量が見込める場合は、こちらを利用すると、専用線接続を利用して、クラウドへの安定かつ低価格なネットワーク接続が利用できるでしょう。

今後に向けて

玉川：今後、事業を拡大させていく上で、AWSを用いてどのように設計したらよいかなど、気になる点はありますか？

岩川：私たちのビジネスはひたすらデータが貯まっていきます。ですから、その扱いを今後どうしていくのか、現状はAmazon Simple Storage Service（Amazon S3）を使って貯めていますがはたしてこのままで良いのかが気になっています。

玉川：それは非常に重要なポイントですね。Amazon S3にデータを保存すると、3ヵ所以上の物理的に離れた拠点のデータセンターにデータをコピーして耐久性を高めます。99.999999999％で設計された非常に耐久性の高いストレージサービスです。

ただ、御社のような場合、ログを蓄積している利用例なので、1つのファイルが欠落しても大きなエラーにはならないと思います。その場合、たとえば耐久性を下げて代わりにコストを30％ほど下げる料金体系（Reduced Redundancy Storage）を用意しているのでそちらの利用をお勧めします。

具体的には、ここ数年間のログは通常の Amazon S3、それ以前のログはReduced Redundancyというように、データの質を見極めて料金体型を選ぶのです。あと、ログデータの格納庫としてAmazon S3は良いと思いますが、今後ビジネスが拡大していくにあたって、そのデータをAPIから提供していくことも想定されると思います。ちなみに今はMongoDBを使っているとお聞きしましたが。

岩川：はい、そうです。

玉川：なるほど。実は先日Amazon DynamoDBという新しいNoSQLを発表しました。今はまだ東京リージョンでは利用できませんが、すでに米国東リージョンでは利用可能になっており、かなり注目を集めています。その理由の1つが、データ容量に制限がないことです。スケールアウトをどこまでもできる、今までのデータベースでは考えられなかった仕様になっているのです。

また、 SSDを利用しており非常に高速なデータベースです。さらにまた、DynamoDBの場合、ハードウェアのスペックを指定するのではなくてパフォーマンスを指定する形式になっています。パフォーマンス指定なので、必要に応じたパフォーマンスで動作をさせることができ、コスト面から見た使い勝手も非常に良くなります。

まだ米国の東側のリージョンのみですが日本からも使うことが可能です。無料試用枠もご用意しています。

そして、これからもさまざまな機能を追加していきます。私自身AWSに入って感じたのが「イノベーションのスピードが非常に速いこと⁠」⁠。ユーザのニーズを汲み上げ、それを形に変えていく、これがAWSの強みですから、これからもぜひいろいろとお使いいただければうれしいです。