AWS導入のメリットは？　食わず嫌いの先にあるコスト・業務スピードの改善点

システム停止時の保証への懸念

中山順博氏（以下、中山）：次の質問にいきたいと思います。こちらも山下さんにお願いしてよろしいでしょうか。

山下光洋氏（以下、山下）：実際に言われたのが、例えば極端な話、システムが停止したときにAWSが使えなくなったら、それはオンプレミスで動くのかという質問をされました。

なので、使えなくなることはまずないという前提でいきました。そのうえで、そこに乗っけてるものを止まらないようにどう工夫してやるかというところが、結局システムをやっていく人間の役割なんじゃないかなと。それをいろんなパターンを示して納得してもらったというようなことをしました。

中山：ありがとうございます。どういう構成だったら落ちにくいシステムか、業務に影響が出にくいかを示すにあたって、どういう情報を参考にされたのかを教えていただいてよろしいいでしょうか。

山下：ここまでの話ほとんどそうなんですけど、だいたい勉強会で教えてもらったようなことがもとになってます。なんだったら、ほぼすべて受け売りなんですね。

自分でいろいろ調べもするんですけれども。勉強会で知り合った人やFacebookでつながって、SlideShareとかを見てると、そういう人たちの書いたスライドがあがってくるんですね。AWSの勉強に行って友達を増やしてると、勝手にどんどんAWSの情報が入ってきます。

こういった同じところを超えてきた人たちがたくさんいるので、そういう人たちが登壇した内容というか、資料をまとめている内容をそのまま書いているという状態でしたね。

本当に中身を試してみると理にかなっていて、それが正解だったなというところです。だから情報源としてそういう感じで入ってきました。

中山：ありがとうございます。私もユーザーグループとかで登壇すると、いろんな方にFacebookで友達申請をいただいて。実は今日も2人（友達に）なったんですけれども。本当にすごい参考になりますからね。みなさんもぜひユーザーコミュニティを利用されてはどうかなと思います。

物理サーバーとの性能スピードの違い

これは私が聞かれたことなんですけれども、お話したいと思います。「やはり物理サーバーより遅いんじゃないか」と最初言われました（笑）。

やはり当然、複合的にスペックを最高に組めば、それは物理サーバのほうが早いでしょうという話ではあるんですけれども。

一般的な業務サーバでそれだけの性能が必要なケースは稀で、AWSのリソースの性能でも必要十分な性能は得られると回答しました。

実際、根拠としていろんなベンチマークの情報ですとか、そういった情報がありますので、そういったものを示したり、事前に検証したりして、非常にリスクを低く抑えるができますといったことを説明いたしました。

山下さんにお聞きしたいんですけれども、実際に性能検証の懸念というのは、御社ではとくになかったんでしょうか？

山下：うちの場合はそのへんの懸念はなかったです。

中山：そこは実際に試して問題なかったので、問題ないですということで進められたと？

山下：そうですね。なにかあればそのときに対応します、というかたちで言ってます。

中山：まずはやってみるということですかね。

山下：はい。

中山：ありがとうございます。 私のほうでもう1個聞かれたのが、「ソフトウェアのライセンスを持ちこめますか？」と聞かれました。

例えば、仮想コア数とか仮想サーバ台数にもとづくライセンス体系があれば、基本的にはそれで踏襲といいますか、その考え方が適用できるんですけれども。一部の製品で「クラウドに持ち込むときは必ずこうしてください」みたいなルールがちゃんと定められているものがあったりします。

なので、基本的に「持ち込める」と回答するんですけれども、「ちゃんとルールがあるので確認する必要があります」といった回答をいたしました。

ちなみに山下さんのところでは、なにかライセンス周りで困ったことはありましたでしょうか？

山下：たぶんこれからの話にはなるかと思います。基本的には、うちの場合はそのまま持っていくことはあまり考えていないので、そこはあまり引っかかってこないかなと思います。

中山：なるほど。ありがとうございます。

従量課金による予算オーバーのリスク

では次になります。これも私の話なんですけれども。やはり従量課金なので「予算オーバーするリスクがあるんじゃないか？」ということも言われました。ここにいらっしゃる方は、ネットワーク転送量のところですとか、ご存知かと思うんですけれども。

完全に予算ぴったりにするというのはなかなか難しいものですので、ちゃんと監視をしたりですとか。実際のコストの分析ツールもありますので、そういったツールを使うですとか。

あとは例えば、サーバーを夜止める運用をするのであれば、ちゃんとそれを自動化するとか、そういった手段がたくさん用意されているので、そういったところをちゃんと使えば大丈夫ですという回答をいたしました。

山下さんのところでは、このあたりの料金周りの制御や監視はなにかなさってるんでしょうか？

山下：AWSさんの見積もりツールを使って、作るサービスが求める要件、それのゴールの最大要件に対してのスペックでのソフト見積もりをします。

なので、そこに満たなければ到底その予算には達さないというような状態です。先ほどレコチョクさんもおっしゃってたんですけど。スペックどおりの見積もりをした結果、だいたい30パーセントを切って回ってると。うちも今のところは40パーセントぐらいです。だいたいそのぐらいでいくような予算感でやってます。

中山：ありがとうございます。これで最後になるんですけれども。こちらもう一度教えていただいてよろしいでしょうか？

山下：今みたいな話をずっと経営会議でプレゼンというか説明をしていって。「そこまで言うんでしたらメリットはわかりましたよ」「じゃあ、デメリットはあるんですか？」と言われたときに、そこはなにも考えず「ありません」とひと言答えて。逆に、会議の場があっけにとられているような状態で終わるというところなんですけど。

ここで、「デメリットとしては……」とか、「ドルだから」とかさっきの「従量課金だから」とか、「予算がもしかしたらオーバーするんじゃないか」とか。「自分がぜんぜん知らない知識のなかで起こる例外に対応できないんじゃないか」とか、不安なことを言ったところでたぶん仕方がないと思ってます。

なので、そこはもう腹を決めるというか、自信を持って、自分がいい、やりたいと思ってることをとにかく言うというところで、「（デメリットは）ありません」と言って、そのまますっといったという状態でした。

中山：なるほど。自信を持って回答することが大事だということですね。ありがとうございます。

プロトタイプについては「NO稟議」でいい

この議題の最後になるんですけれども、 AWS上でやることなすこと全部なにか稟議を書いているのかと言われると、そんなことはないということで。非常に重要な話かと思いますので、ここについて教えていただいてよろしいでしょうか？

山下：最初にお断りしておきますが、もちろん必要な稟議は通してます。あくまでも「NO稟議でよい」というのはプロトタイプの場合で、かつオープンソース等を使ったシステムを構築する場合なんですけれども。

ただ、自分がほかの部門に押し付けるわけではなくて、ほかの部門が「やりたい」と、「どうしてもこれ1回使ってみたい」と。「こういったことって実際できないのか？」とか。

そういった話があって、例えば会社では1週間に1回、1ヶ月に1回しか稟議を通す仕組みがありませんとなったときに、1週間待つ、1ヶ月待つというのは、スピード的にはすごくナンセンスな話だと思うんですね。

なのでそこは稟議等じゃなくて、それをプロトタイプとしてまずはやってみる、使ってみる。それをかたちにして表すことで、さらなる「こうやりたい」という要望ですね。確実な要件という裏にあるものが出てくる、というところを回してます。

もう1つは、決裁したからといって、じゃあ自分には責任ありませんよと。決裁した人がいるから「いいって言いましたやん？」みたいな考え方は絶対したくないと思ってます。

なので、「なんかあったら、全部自分で責任とりますよ」ぐらいの感じではもちろん考えてはいます。

うちの会社はユーザー会社、事業会社なので、非システム部門の人にそれを一生懸命説明することにそんなに大きな意味はないんじゃないかと。説明すべきは、出る効果とそれによってなにができるかというところだけでいいんじゃないかと。

じゃあ、そこの仕組みをどうやるか。例えば、情報漏えいのリスクやセキュリティをどうしていくか。そういったところは、ともに作るメンバーと責任を共有して、どうやればリスクを下げられるのかということを話し合って、実際に手を動かして試していく。

そういう時間にあてていくべきなんじゃないかと考えてまして、語弊のある言い方かもしれないんですけど、プロトタイプについてはNO稟議でいいんじゃないかということでやってます。

中山：ありがとうございます。やっぱりこういうやり方じゃないと、なかなかAWSのよさも活きないかと私もすごく思いますので、見習ってやっていきたいと思います。ありがとうございます。

AWSの料金の見積もりはどうしてる？

3つ目の議題に移りたいと思います。次に「料金について」です。みなさん、ここにいらっしゃる方であれば、AWSの料金の見積りはやられたことがあるかと思うんですけれども。

「どこまで細かくやればいいのか」「実際に、どういうやり方が適切なのか」というのは、悩まれてる方がけっこう多いんじゃないかなと思います。なので、このあたりを実際にどうやってるのかというのをお話ししたいと思います。まずは、山下さんの事例をご説明いただいてよろしいでしょうか？

山下：さっきの話の続きなんですけど。必要なスペックや設計を見積もりツールでそのまま落としてます。今のところ、実際に超えたことはなく、だいたい5割以下で支払い請求が続けられてるかなというところです。

中山：私のところでも為替のレートはちょっと高めでとか、バッファを積んで予算を申請するとか、そのへんは同じようにやっているところです。

齊藤さんところでは、AWSの運用管理を生業としていらっしゃると思うんですけれども.そういったたくさんのリソースの料金、社内で使われてるものも含めて、アイレットさんではこのへんのコストの管理はどのようになさってるんでしょうか？

齊藤愼仁氏（以下、齊藤）：自社製のツールがあって、そいつが全部勝手にやってくれるんです。

中山：なるほど。

齊藤：今、売ろうと思ってるんですけどね。あまりにも便利なので……ほしいですよね？（笑）。アカウント登録すると、勝手に全部見積もってやってくれるんですよ。

転送量もあらかた出してくれて、「お前使いすぎだぞ」とか教えてくれるので、「ごめんなさい」とか言いながらできるようにやってますね。

うちはやっぱりアカウント数が桁違いなので、そういうのをやらざるをえないんですけど、そんなにアカウントがないお客さんのほうが多いじゃないですか。自社でやると5アカウントとか10アカウントとか、多くても100とかじゃないですか。

100アカウントあったら、どうやって管理するかといったら、なかなか自社ツール作るというのもしんどいので、買ってくれって感じですね（笑）。

中山：ネットワーク転送量のアラートが出るのは、すごい便利ですよね。やはりそこを不安に思っていらっしゃる方も多いと思うので。ちなみにどれぐらいのアカウント数を管理されてるんですか？

齊藤：4桁はいかないと思います。

中山：さすがにそれぐらいの桁になると、ツールがないと厳しいですよね。わかりました。ありがとうございます。

運用にあたってプロのアドバイスが必要なとき

次の議題にいきたいと思います。「パートナーの利用」というところです。これから導入を検討されるにあたって、いろんなセッションを聞いたり、あとハンズオンのトラックなんかもあったと思うんですけれども。

やろうと思えば自分たちでもできるかと思うんですけれども。すぐに導入したいとか、そういった場合にはやっぱりプロの力を借りたいと思ったりもされると思うんですが、どっちを取るかですね。

このへん悩まれてる方もいらっしゃるんじゃないかなと思いますので、これも実際に私たちがどのようにやっているかを紹介したいと思います。まず山下さん、お願いできますでしょうか。

山下：あらためて説明しますと、私も本当に去年ぐらいからAWSを使い始めたところです。ここに書いてあるとおり、まだ本番で運用しているところで言いますと、本当に知れた規模なんですね。なので、これぐらいはとりあえず自分たちで十分対応して、勉強しながらやっていこうというところでやってます。

ただ、全面移行も予定しているので、3人しかいないなかで、人手が足りない、技術も足りない、スキルも足りないというところを、どうパートナーさんと共用していくかというところでやっていきたいなと。丸投げでもなく、ベンダーロックみたいなかたちでもなく、どう一緒にやっていくかというところを考えていきたいなと思ってます。

それで、気になってるのは請求代行ですよね。これはただただ得しそうな気しかしないので、気にはなっています。

中山：私のほうの話もさせていただきますと、結論から言いますと、今のところは弊社でも社内の要員だけで運用を行っています。

実際、運用のところでバックアップの自動化というのは、スクリプト、コードを書けばできますし、そのへんは自力でやりましたので、今の時点でどこかパートナーさんのお力を借りるというところまでは大丈夫かなと思ってます。

そしてなにより、先ほどから何度も申し上げているコミュニティの勉強ですね。これもすごくためになっていますし、あとは某社のすごく詳しい情報がたくさん載っているブログですとか、このへんを活用させていただいています。

もし今後、単純にAmazon EC2ですとかAmazon RDSといったところ以外にも、もっとクラウドネイティブなサービスを使ったなにかを開発をしたりといったときになったら、どこかプロに相談したいかなと。あとは24/365の運用監視が必要なケースになると、これは弊社でも体制があまりないので力を借りたいなと思います。ちなみに今、山下さんのところではどんなサービスを使われてますか？

山下：Amazon EC2とAmazon RDSとAWS LambdaとAmazon API GatewayとAmazon S3です。

中山：AWS LambdaですとかAmazon API Gatewayってけっこう難しんじゃないかなと思うんですけれども。そのへんはやっぱりコミュニティでいろいろ情報を仕入れてやってみたという感じでしょうか？

山下：そうですね。もう先人がというか、人がやってくれたやつをそのままトレースしたらできたんですね。

中山：なるほど。ありがとうございます。最後の議題に移りたいと思います。

実際にAWSを使って感じたメリット

次に、「実際にAWSを使ってみてどうだったか」といったところです。実際にAWSを使ってなにが改善したかとか、設計の構築・運用がどれぐらい難しかったかといったところのお話をさせていただきたいと思います。

こちらも山下さんからいただいているものがございますので、こちらのご説明をお願いしてよろしいでしょうか。

山下：普通ファイヤーウォールとか、書くのがけっこう面倒くさいというか、特化した技術が必要なのかもしれないんですけれども、そういったところをセキュリティグループでできるとか。設定がすごく楽になりましたよね。可用性と運用は、RDSもほぼ手をかけずにやっています。

「サービスのリリース頻度」と書いてるんですけど。先ほど申し上げましたように、新しいインスタンスを立てたいと思ったときに立てられるので、そこの調達する手間はまったくかかってないというところが本当に変わったことじゃないかなと思います。

中山：ありがとうございます。引き続きなんですけれども、コスト周りのところはいかがでしたでしょうか？　コストが削減されたとか、そのへんのお話はなにかありますでしょうか？

山下：もちろん新しいものを買うよりかは削減されてます。今の時点ではということなんですけど。ただ、既存の資産はまだあと1〜2年ぐらい使えるものもあるので、それを使わずに「とにかくAWSだ」というふうにやると、あまりコスト削減にならないと思ってますので、そこはそこでうまく使えればいいかなと思ってます。

中山：最後に、ここはすごく重要なところかなと思いましたので。「事業部門との関係性」というところです。ここがかなり変化されたということなんですが、解説いただいてよろしいですか。

山下：以前は、「できるか・できないか？」というおうかがいが情報システム部に立てられる文化というか会社の流れだったんですね。「これできますか？」「これしたんですけど、できなさそうですか？」とか。

私は気づいて「なんでこんなやり方してるんですか？」聞いたら、「いや、『できない』って言われたから」とかなんですね。もうそうじゃないと思うんです。やるか・やらないかというところを考えて仕事するようにしていきたいなと。なるべく動くものとか、実際にできれば「やってみましたよ」というかたちで出していくとか。

そういうことを少しずつ繰り返していくことで、本当にみんながやるべきか・やらないべきかと考えるようになったんじゃないかなと思いました。

うれしかったのは、うちの副社長がひと言、「ちゃんと成果をどう出すのか、なにが成果なのかというのを明確にして、『こういうのをしたい』と山下に言えば、1週間ぐらいでなんとかしてくれるよ」とおっしゃっていただいたんですね。

自分が「こういうやり方が正しいんじゃないかな」と思ってるところに同調していただけたというところが非常にうれしかったです。

中山：ありがとうございます。齊藤さんにもおうかがいしたいんですけれども。実際にアイレットのお客様への導入にも関わっていらっしゃったとおうかがいしていて、実際にAWSを導入することで、どういったタイプのお客さんだと、今日あげていただいたようなメリットをAWSで受けることができるということをおうかがいしたいと思います。

齊藤：サービスを新規で立ち上げなきゃいけないシチュエーションでは、クラウドの速さは圧倒的なので、そこはかなり喜ばれますね。

構築から実際の運用に入るまでのスピード感が、今までだと、オンプレで用意する、じゃあデータセンターに行こう、サーバは何台調達して……とかやって、3ヶ月・半年・1年とかかかるんですけど。

そういうスピード感じゃなくて、数日とか1週間以内にサービスが立ち上がるので、そのへんはわりと喜ばれるんじゃないですかね。

あとは基幹系だと、年単位で移行したりということもありますけど、やっぱりトータルでコストがだいぶ落ちるのがわかってるので、そういったところでも喜ばれますね。

AWSの導入に求められるスキル・考え方

中山：ありがとうございます。では最後に、実際に導入するにあたって、求められるスキルや考え方・マインドをおうかがいしていきたいと思います。まずは山下さん、お願いできますか？

山下：まあ、「やらないほうがいいかな？」みたいに思っちゃうときっとできないし、「できるかな？」と思ってもたぶんそれもできないと思うんですね。なので、とにかくやってみるというところを、自分を鼓舞してやっていっているところはあります。

とにかくなにか調べながらやればなんとかなっているので、この先もなんとかなるんじゃないかと思ってます。

中山：ありがとうございます。次に齊藤さん、お願いできますでしょうか？

齊藤：僕は逆で、自分でやりたくないんですよ。面倒くさくて。

中山：なるほど。

齊藤：そうなんですよ。周りにわかるやつらがいっぱいいるので「やっといて」て言ってお願いしちゃう（笑）。

それはコミュニケーションスキルと言ってるんですけど。一般の会社さんでAWSを……リテラシーが高い社員さんを抱えられてるなんてなかなかないでしょうから、ベンダーとかパートナーを含めて、「こういったことがやりたいんだけどどうしたらいい？」というコミュニケーションスキルは非常に重要なんですよね。

JAWS-UGに参加するときもきちんと目的をもって、「こういったものを得たい」という意思表示をしたほうが得られるものも大きいと思うので、基本的にコミュニケーションスキルは非常に大事だなと思いますね。

中山：ありがとうございます。私や山下さんもそうなんですけど、やっぱりコミュニティで得ているものがすごく多いので、そのへんはすごく重要かなと思います。私としましては、現状のやり方が最適なのかどうかを常に考える続けるということで。

AWSのサービスリリースってすごく早くて。そのときは一番ベストなやり方だったとしても、新しいサービスがリリースされることで、それがぜんぜんイケてないやり方になるというのはよくあることです。

ですので、いいやり方があるんじゃないかということを常に考えながらウォッチしていって、必要に応じて変えていくというところはすごく必要かなと思います。

大事なデータほどクラウドに預けたほうが安全

もうすぐお時間ですので、最後にまとめさせていただきたいと思います。今後AWSをどのように活用しようとしているのか、あとはその狙いということで、パネラーのお二人におうかがいしていきたいと思います。まずは、山下さん。

山下：おかげ様で「あれやってくれ」「これやってくれ」「これをどう考えたらいいか」と相談を多々受けるようになりまして。そうなっていくと、今度は仕事が溜まってきて、どんどんさばけなくなってくるんですね。

そこでだんだん開発効率が悪いというか、あまりよくない状態に陥っていくので、もっとクラウドネイティブな使い方を学んでどんどんやっていくことで、そのスピードを上げていこうと考えています。

先ほどLambdaとかAPI Gatewayの話があったんですけれども。例えばLambdaなんてアプリケーションサーバを作る必要がまったくないと。そこにコードさえ書けばもうそれで動いてくれる。そういった使い方ができるんですね。

なのでそういったところを知って、便利なところは便利に使っていくということで、本当にどんどんスピード上げていかないといけないと考えております。

中山：ありがとうございます。では、次に齊藤さんお願いできますでしょうか。

齊藤：さっきもちょっと言ったんですけど、AWSのアカウント管理とかコスト管理とか、いろいろ課題があるとは思うんですけれども。

基本的にはそういったものをある程度クリアし続けているので、情シスとしてそういったものをいろんな人に提供したいなと思っているんですね。「売上が立つ情シス」を目指していきたいなと思ってます。

あとは考え方なんですけど。基本的にAWSでできることはもう全部AWSでやるという基本的な理念があります。

オンプレでできるかどうかはもう一切検討はしません。AWSでできるかどうか。AWSでできないかどうかを考える。これだけですね。

実際にできないケースはなにかというと、それは自分たちで実装しなきゃいけないアプリケーションがたくさんあったり、いろんなことを考えると、これはAWSでは厳しいなと。

それは全部SaaSに投げればいいんですね。例えば、ファイルサーバだとしたら、Windowsファイルサーバ、AWSでやるとしたらけっこうしんどいなとかいろいろ考えると、Dropboxがあるじゃないかとか。そういうふうにSaaSに投げていくんですね。要するにフルクラウドで考えていくと。

「フルクラウド化」と書いてありますけど、使い方次第だけれども、基本的には安全と考えています。というのは、みなさんお金を銀行に預けるのは基本だとは思うんですよね。銀行に預けるお金ってすごい大事じゃないですか。自分にとって大事なお金をほかのところに預けちゃうんですよ。考え方はそれと同じなんですね。

自分の大事なものほどクラウドに預けちゃったほうが安全なんですね。なので、信頼できる場所、信用したい場所にそういったものを預けるという考え方でやるということですね。

そうすると、どんどんセキュアで、かつ利便性がどんどん上がって、情シスとしての評判も非常によくなると考えています。

中山：ありがとうございます。 私としましては、今やっている業務やビジネスのやり方というのをAWSを通して再構築したいと思っています。

従来のやり方を変えることで得られそうなメリットってけっこうたくさんあるなと、ふだん見てても思うことが多々あるので、このへんをやっていきたいなと思っています。

やっぱりクラウドですので失敗しても……失敗って言ったらあれですけど、やり直しですとか、そのへんのリスクを抑えることが非常にやりやすいなと思っていますので、このへんをもっと活用したいと思っています。

少しでもそういった活動を通して自社の価値を向上させたりとか、そういったことを考えていきたいなと思っております。

ということで、本日は以上になるんですけれども 、我々はコミュニティで今後も活動していくと思いますので、もしなにか聞きたいこととかございましたら、ぜひお声がけいただければと思います。本日はどうもありがとうございました。

（会場拍手）