エンジニアのコスト意識が向上　ドワンゴがAWSを導入して変わったこと

AWSを使うことでエンジニアの意識が変わってきた

関剛氏：皆さんこんにちは。ドワンゴから参りました関と申します。「ドワンゴがAWSを使ってみた」というタイトルで、40分ほど講演させていただきたいと思います。正直、ここの場に立つのはおこがましいといまでも思っておりまして、内容的にはテクニカルなことは、あまり正直ないです。

ただ、「ドワンゴがAWSを使って開発の部隊、あと、インフラの部隊、企画営業、それぞれが意識が変わってきたよ」ということを皆さんに伝えられればいいかなと思って、ここに立たせていただいてます。

まず、そもそも自己紹介なんですが、私、関剛と申します。株式会社ドワンゴでインフラ担当しています。役目としては、いま申し上げたようにインフラエンジニアなんですが、あまりAWSを使ったことがありません。

なので、たぶんここにいらっしゃる皆さんのほうが、AWSのテクニカルなところ、設計、構築、運用に関してはお詳しいと思っています。

今日お話することは、まずAWSを使ってサービスを構築しました事実。AWS自体を使ったのが、ほぼ初めてになります。ほぼというのは、一部サービスで突発負荷を避けるために、AWSを利用したことは過去あったんですが、本格的なサービスとしては初めてになります。

話す内容としては、初心者というか、AWSを初めて使ってみた人から、AWSの運用まで、どうだったのかをいったん振り返ってみたいと思います。そして各論なんですが、AWSを使って変わったところ、組織も体制も変わったところがありますので、そこをご紹介したいと思っています。

まず皆さんにお聞きしたいんですが、「Live Dwango Reader」をご存知の方、手を挙げていただけますでしょうか。

（会場挙手）

あまりいないですかね。はい、ありがとうございます。Live Dwango Reader、このサービスをAWSに載せたのが、今日のお話になります。Live Dwango Reader、紆余曲折ありました。

LINEから譲渡されたlivedoor ReaderをAWSで運用

まず去年、10月1日にライブドア社が「livedoor Readerを終了しますよ」と発表しました。すごく長く利用いただいていたサービスなので、使っていたユーザーさんからは、「えっ、終わっちゃうの？」という声が聞こえてきました。

そのあとに、突然サービス終了を撤回しますと開発ブログで発表しました。この裏でいろいろ、我々が当然動いていたんですが、「営業譲渡しますよ、運営譲渡しますよ」と発表されました。

livedoor Readerから、Live Dwango Readerへ。LINEさんから、旧ライブドアさんから、ドワンゴが営業譲渡を受けまして、我々ドワンゴが運用することになりました。

同時に、ただ移しただけというところもあったので、スマートフォン版はログインしなくても皆さんいま使えますので、ぜひ使ってみていただきたいんですが、livedoor Reader、LDR。頭文字を取ってLDR Pocketというサービスを同時にリリースをしました。

ここまで、「livedoor Readerは終わります、我々ドワンゴが引き継ぎます、新サービスもくっつけてリリースします」というところで、すごく時間がなかったんですね。

なので、livedoor Readerを、もうAWSで作ると決めました。先ほどの五月雨式に書いたスライドをまとめると、livedoor Readerのサービス終了から、派生版スマートフォンアプリLDR Pocket、こちらを出すまでに5ヶ月間。ある意味、時間があったと言えば、時間がありました。

ただ、5か月間しかなかったという言い方もできると思っています。これは裏話というか、実際の話なんですが、リリース直前の3日間で、ほぼすべてのインスタンスを立ち上げて、デプロイをして、テストをして、実際にサービス提供までこぎつけています。

つぎはぎのまま9年間使われてきたサービスだった

私、インフラエンジニアとして、ほぼ初めてAWSを使う状態で、「関さん、インフラ設計して、AWSでやってよ」とお願いをされました。直感的に嫌な予感がしたんですね。

まず、livedoor Readerのサービスはそのまま継続したいと。形を変えずにユーザさんにも、そのままシームレスに移行してほしいという要件がありました。このサービス自体、9年間ずっと使われてきました。

裏方から見ると、改修、改修、データ領域の増強、あとサーバのリプレイスも含めて、つぎはぎ、つぎはぎ、9年間使われてきたものになります。

もともと開発したライブドアさんは、いまのLINEさんに買収をされていて、もともと開発した人がいるかいないか、サポートしている人もいるかいないかわからない状態。これは買収したサービスを作り直すより怖いところだと思うんですけど、嫌だなという予感はしていました。

我々の会社としてはLDR Pocketをもうこの日から出すのは決まっていました。なので、絶対に遅れることができない状況でいました。方針として考えたのは、もうそのまま。そのまま環境を移したい、移すしかないと決断しました。ソースコードはそのまま。ミドルウェアのバージョンも全部そのまま。データ、キャッシュに載っているもの、あとデータ、DBですね、MySQLに入ってるものも、そのまま持ってくると。

ここが結構、普通ではあり得ないと思うんですけど、サーバのホスト名であるとか、それこそIPアドレスですね、これもソースコードの中に、直書きされてる可能性があるみたいな話があってですね。

「関さん、このままIPアドレス変えずにやりたいんだよね」という話がありました。で、サーバの負荷見積なんですけども、当然、LINEさんから我々の環境に移設するにあたって、サーバの負荷見積もりをしないといけないんですけども。

LINEさんからは「こういうサーバ構成、ネットワーク構成、機器の諸元はこういう感じですよ」って聞いてはいたんですけども、若干、古い。サーバも数年前の構成のままだったので、同じものを合わせることはできないし、最新のものを持ってくると余ってしまう。

けどIPアドレス、インスタンスの数、サーバの数は変えられない、変えない方針なので、結果としてサーバリソースが余る、余剰が発生する可能性があるのを危惧していました。

「じゃあ、AWSを使いましょう」となりました。先ほど申し上げた、「そのまま」というキーワード。設計ポリシー、構築ポリシーなんですが、まずソースコードそのまま、これはOKですよと。ミドルウェアも持ってくればOKなので大丈夫でしょう。データは当然、サービス停止にともなって、更新系が走らないようにして、データをコピーしていきましょう。

サーバのホスト名、これもオンプレ環境に移設することを考えても、カチらなければOKでしょうと。ただ、サブドメインのいわゆる右側、FQDNで、ちゃんと合わせるのは、オンプレ環境だと非常に難しいんじゃないかなと思います。

AWSを使った感想は「革命的なスピード」

ただ、AWSを使えばそのまま移設ができます。IPアドレスに関しても、実はLINEさんで動いていたlivedoor Reader、こちらの環境のIPアドレスと、もともと弊社が持っていたオンプレ環境のIPアドレスはカチってました。なのでオンプレ環境には持ってこれないですね。なんですけども、AWSであれば、VPCを1個切って、同じものが作れると。独立環境を作れるので持ってこれると。

最後に、経営的なサーバの負荷見積もりなんですけども、インスタンスタイプを変更してあげれば、余剰はあとで修正できる。それに新しくライブドア、LDR Pocket、新しいサービスをリリースするにあたって、まだ負荷が見積もれていないんですね。

ここに対しては、たとえば負荷がすごくきて、ユーザーさんすごくたくさん使ってくれて、インスタンスが小さすぎるのであれば、大きなインスタンスに変えることができる安心感がありました。これはやっぱりAWSならではの考え方で、非常に構築する設計する上で安心感があったところであります。

次にすごく簡単なんですけども、構成。非常に単純で、使ったのはEC2とRoute53を使っただけです。一般的な構成と同じように、ELDがあって、その後ろにフロントエンドがあります。キャッシュを挟んで、MySQLのインスタンスを立てて、そこでデータベース、データを持っていたと。

後ろ側には小さいインスタンスで監視サーバ、デプロイ用のサーバですね。それと、ステージング開発も同じところに置きましたという簡単な構成になっています。素人ながら、AWSをほぼ初めて使ってみた感想なんですけども、Webコンソール、ポチポチで、数分でインスタンスができた。

私、ずっとデータセンターの構築とか、ラックにサーバをマウントするとか、業者さんを呼ぶとか、ずっとやってきたんですけど、あらためて革命的というか、こんなスピードでできちゃうんだねと感じました。

オンプレ環境だと、機材の手配とか含めて数週間。この規模だと開発の人には引き渡しまで1か月半ぐらいくださいって言っちゃう感じなんですけども、実際には3日間でインフラを作ることができました。ここは圧倒的なプロビジョニングスピードを発揮できたし、そこは我々が期待していた通り、期待していた以上のものを、成果を得られることができました。

オーバーヘッドなどの懸念点はすべて杞憂に終わった

もともと懸念だったことを3つ書いてあります。結果的には杞憂で終わったんですけども、仮想化。AWSって仮想化されてるよね。で、オーバーヘッドってやっぱりあるんじゃないのと思っていたんですけども。

そんなにがっつり負荷がかかるところでもないという理由もあるかもしれないですけども、仮想化のオーバーヘッドはいまのところ感じていません。オンプレ環境というか、ベアメタル環境とほぼ同じように、パフォーマンスが出ているかなと、モニタリングができています。

あとネットワーク、ストレージですね。こちらに関しても、ボトルネックは感じていません。サービスの特性上、記事をクローリングしてくる動作があって、比較的トラフィックが出るところは、ポイント絞って出るという環境にはなっているんですけども、そこのボトルネックは感じたことないですし、サービスも順調に動いていますね。

あと、これ知らなかったんですけど、ELBを使っていて突発負荷。実はELB暖機運転っていうアイドリングをしておかないと耐えられない場合があるのを、いろいろちょこちょこ教えてもらったり、ブログで見たりとかしていたんですけども。

ADSのソリューションアーキテクトの方といろいろ相談をして、大丈夫じゃないんですかねと、何もしないで本番サービスに移行して、お客様からアクセスしていただいたんですけども、特に問題なく、そのまま動きました。

結果的にAWSを使って、いくつか古いインフラエンジニアとしての考え方の中で懸念はあったんですけども、すべて問題なく、何事もなくサービスインすることができたところが素晴らしいと思いました。

アプリ開発エンジニアがインフラに関われるようになった

次に、AWSを使ってみて、オンプレミス環境、弊社、大きなデータセンターあるんですけども、そちらと比べて変わったところ、視点の高い話になりますが、書いてご紹介したいと思います。

どこの会社さんも、ある程度の規模になると、アプリ開発エンジニアさんとインフラエンジニアさんは組織が分かれていたり、ある程度、責任分界点があるのかなと思っています。私も、いくつかITの会社、Webサービス会社にいましたけど、そういう組織体系になっていました。ドワンゴも同じように、インフラの部署とアプリ開発の部署が分かれています。

悪い言い方をしてしまうと、インフラが社内請負、受託みたいな感じになってしまったり、なんか障害が起きるとインフラさんどうしたんですかっていう、こうセクショナリズム的な、悪い意味での分け隔てができてしまうのが、いままでの私の感じ方というか。組織ではだいたいあったりしました。

AWSを使ってみて変わったところは、アプリ開発エンジニア、これ実際そうなんですけども、実際にLDR Pocket、あとLive Dwango Reader、こちらのソースコードをメンテナンスしているアプリケーションエンジニアがインスタンスタイプを変更したりとか、モニタリングをしたり、あとDNS、Route53の設定を変えたりとか、ELBのインスタンスを入れたり、出したりとかもできるようになっています。

ここは逆説的になるんですけども、アプリ開発エンジニアがインフラをいじれることによって、アプリ開発エンジニアがサービス開発に集中できることが、変化として見受けられました。

アプリとインフラ、完全に分かれて協業して一緒にガッチャンコしてやったほうがいいんじゃないのと思うかもしないんですけども、アプリエンジニアとインフラエンジニアがすごく分け隔てがあると、お互い聞くのを待つとか、依頼するとか、そういう調整コストがかかってきます。

一番調整コストで大きいのは、たとえば「新しいサービスやりますよ」「移設しますよ」っていうときに、インフラエンジニアとしては「どれぐらいアクセス来るんですか。サーバ、どれぐらい増える予定があるんですか」と聞きたくなるんですね。

ただ、AWSに関しては、アプリエンジニア自身でインスタンスを立ち上げたり、減らしたり、変更したりできること、それと動的にサイジングを変えられることによって、綿密なサイジングが不要になったことによって、その調整コストが大幅に減りました。減ったというか、ほぼゼロになったと感じています。

アプリ側とインフラ側で業務のクロスオーバーが可能に

もう一点なんですけども、アプリ開発エンジニアとインフラエンジニアが、業務の分掌が違うところがあったんですけども、アプリの人がインフラを見たり、インフラの人が今度アプリのソースコードを見て、ここはボトルネックなんじゃないかなっていう業務のクロスオーバーができるようになりました。

これは調整コストとか、依頼を待ったりとか、そういう時間がなくなったことによって、時間的余裕、あと精神的余裕が生まれて、分野が違うエンジニアそれぞれ業務のクロスオーバーをして、すごく知らない視点から、お互い意見が言える、改善できる流れができたと思っています。

インフラの設計、構築についてですが、先ほど何度も申し上げたんですけども、AWSの場合、サイジングが不要になりました。

そのことによって、これは次のサービス、たとえば我々が、次に出していくサービスであるとか、今後のサービスにもつながっていく話にはなるんですけども、綿密なアクセス予想、あと負荷計測、それこそ負荷試験とか、時間をかけてシナリオ書いてやったりもしていたんですけども。

不要というのは書き過ぎかもしれないですけども、ある程度、そこの負荷が減ることによってまず動かす。インスタンス大きすぎたら、小さくする。足りなかったらオートスケールさせるという選択肢ができたことによって、「まず動かしてサービスを出してみようよ」っていう流れができたと思っています。

あと大きなところは、アプリエンジニアがインフラエンジニアに対して、サイジングとか、インスタンスタイプの指定とかを依頼して、やっぱりここは待ち時間とかあったんですけども。アプリエンジニアがもう直接、自分たちでインフラを設計、構築できるようなったのがスピードアップにつながってると思います。

このスライド、言ってることをまとめると一番下に書いてありますけども、お互いの業務をオーバーラップして柔軟に、気持ち的にも実務に取り組めるようになったのは、AWSを通じての大きな変化の1つだと感じています。

コスト的なボトルネックが可視化される

もう1つ、変わったことをお話したいんですけども、いままで、サービスごと、あとサービスを構成するコンポーネント、たとえばWebサーバ、データベースサーバ、キャッシュ、あとはログをとっておく蓄積用のサーバ、これに対して直接的なコストが、なかなか見えませんでした。

見えないながらも、何か儲かってるよねとか、会社全体では業績が上がってるよねっていうところはあったんですけども、サービスごと、もっと言うとコンポーネントごと、どこにボトルネックがあるのか、コスト的なボトルネックがあるのか、改善ポイントがあるのかが見えませんでした。

AWSを使ったことによってビリングの機能、一般的に機能というか普通に提供されているものですけども、ビリングのページを見ることによって、フロントエンド、アプリ、DBのどこにコストがどれだけかかっているかを把握できるようになりました。

これ当たり前のことなんですけども、非常に大きなことで、データセンターをオンプレで持っていると、直接、あるサービスのWebサーバが5台ありますというのは、いわゆる会計の言葉で言うと、直課という形で直接のコストとして見れるんですね。

ただ、全体がつながってるルーターとか、コアスイッチ、バックボーンのスイッチは、どう費用、配付するのかを考え始めると、実は難しかったり、実際そこまで踏み込んだ管理会計ができていないことが多いかなと思います。

それをAWSを使うことによって、どこに、どんな費用が、どれだけかかってるか、改善ポイントはどこにあるかを見えるようになりました。見えるようになったことで、結果的にエンジニアが担当サービスのコスト意識を持つようになりました。

これはまさしくいまうちの会社で、いまこの時間にたぶんやってるんですけども、データベースのインスタンスタイプって適切なんだっけというのがあって、もう少し小さくできるんじゃないかとか、集約できるんじゃないかとか、EBSのボリュームって、もう少しIOPSを下げても大丈夫なんじゃないかと議論をしていて、実際にいまコンソールをいじったり、APIを叩いて、書いているところです。

これをアプリエンジニアができるようになったのが非常に大きな変化です。あと、会計的な側面、経理的な側面から言うと、いままでデータセンターって、サーバを買ってしまうと、どうしても固定費になって、たとえばサービスが尻すぼみになってしまった時でも、固定費なので売り上げに対してコストが減るわけではないです。ずっとコストがかかり続ける。

それを、たとえば小さいインスタンスタイプに変えることで、変動費にすることができるので、経営者に対しても説明が非常に楽ですし、わかりやすいですし、サービスを運営してる自分たちでも、改善ポイントを見つけて改善をして評価するという、いいフローが回るようになってきたと思っています。

まだできていませんが、将来的には再分析とか、あと、エンジニアがちゃんとコストを気づいて、無駄なコストがあることに気づいて、うまく改善したところで、人事的な評価にもつなげたいなと思っています。

プロダクト担当者のオーナー意識が向上

次に、AWSを使ったことによって、プロダクト担当者、これはアプリ担当者も、企画の人もそうですけども、担当者がデータセンターを持てるという意識に変わったと思っています。

結果的に、プロダクトの担当者が、僕が、私が、このプロダクトを運営してるんだ、担当してるんだっていう意識がすごく高まったと思っています。それはコストであったり、障害に対するモニタリングであったり、障害時の対応を早く対応しなくちゃとか、コンソール見て、どこが悪いんだっけって、AWSサポートに問い合わせればいいっていうところを含めて、オーナー意識が向上したと思っています。

このスライドでまとめると、開発者が、いままでインフラの人であったり、購買の人に頼んでいたリソース調達を自ら実施をして、プロダクト、イコール、ただコードを書いたよとか、新しい技術を使ったよというところではなくて、事業として、お客様にいいものを使ってもらおうとか、もっとこういうものを作ったら喜んでもらえるという視点が生まれたかなと思っています。

いちエンジニア開発者だけではなくて、このプロダクトのオーナーという意識を持てるようになったのが変化かなと思っています。ここまででも、AWSを使って、オンプレ環境から、いろいろ変化というのを私自身感じてきました。

これはドワンゴという組織だけなのかもしれないですし、他の組織にも当てはまるかもしれないんですけども、さらに現場を変えていくためには、何ができるかな、どうしていけばいいのかを考えてみました。

当然、我々はオンプレ環境を持っています。AWSに全面移行したというプレスがたまに出てて、「おっ、すごいな」って思ったりするんですけど、正直、僕の感覚からいうと、今のドワンゴのサービスは、全部AWSに乗せるのは、コスト的に合わないんじゃないかなっていう感覚があります。

ちゃんと計算してないので、やってみる価値は十分あると思うんですけども、そういう意味で、オンプレ、既存のデータセンターとAWSを、どう使い分けていくのかという明確な指針、そして、その指針を柔軟に変えていける状況を作る必要があると思っています。

コスト減によりトライ＆エラーの文化が醸成される

AWSに関しては、先ほど申し上げたんですけども、とりあえず作って最小課金で止めてしまうことも、極端に言えばできるので、まずやってみる環境ができると、ここは非常に大きいですね。

いままでのインフラエンジニアの概念を覆すものになっています。機会費用の最小化で、もし失敗したとき、もし成功して跳ねたときの機会費用を、いい意味でも悪い意味でも、いいほうでも悪いほうでも最小化できるのがAWSの強みかなと思ってます。

当然、気持ちの上では、気軽にトライ＆エラー。エラーをしたときの影響を最小限にできる後ろ盾があれば、開発者とか企画の人が、まず「こんなのやってみました」とか「こんなの企画したので、作ってみません？」とかが芽生えてくるのかなと思っています。

オンプレとAWSの使い分けなんですけども、オンプレからのAWSに動かすこと。その逆、AWSから、やっぱりこれはオンプレだよねっていうものも両方あり得ると思っています。これは当然、もう何年も議論されていることだとは思うんですけども適材適所。その適材適所は、当然、時間であったり、外的環境によっても、内的環境によっても変化すると思っています。

ただ、変化したときに、変化についていけるオプションが1つ、AWSで増えたことは、非常に我々の大きな武器になっていると考えています。オンプレとAWSを比較するにあたっては、当然これも議論されていますけども、中期的、長期的、具体的に言っちゃうと、固定資産の耐用年数。TCOの観点で比較をしていかないといけないと思っています。

当然、TCOも、AWSの場合は変化させることができるので、計算は難しくなりますけども、ここは本当に武器だと思っているので、うまい計算式を作って、仕組みを作って、比較をして、オンプレからAWS、AWSからオンプレというスイッチングを簡単にできるようにするのが、大切なのかなと思っています。

あと、今回とりあえず使ってみたところもありまして、リザーブドインスタンスをまだ使っていません。なので、若干、コスト的には高いというか、もっと安くできるのかなと思っています。

あと、スポットインスタンスが非常にAWSの特徴的なものと注目をしていまして、一時環境として低価格で大きなインスタンス、大きなデータをコンピューティングできるところを、何かうまい使い方はないかなと探したりであるとか、見えてないところ、ここにフィットするねっていうのを社内で見つけて、ぜひ使ってみたいと思っています。

たとえば弊社でも当然、検証環境、サービスの動作検証とか、負荷検証を行っているんですけども、そちらの検証環境、あとは一時的な開発環境、これでスポットインスタンスがうまく活用できると、非常にコストとしてもいいですし、開発者としてもやりたいことができる。

ものすごいインスタンスを使いたかったんだけど、いままでデータセンターに機材発注する、そこまでではないけど、やってみたいということが、特にビッグデータとか解析系ではできるのかなと思っています。

今後の課題はAPIを用いた手順の高度化と自動化

続いて、さらに変えていくための続きなんですけども、現状、オンプレとAWSの環境、今回の要件としては、オンプレと完全に分けたいというIPアドレスの件がありましたので、完全に分けてはいるんですけども、やっぱり使っていくとAWSは便利なんですね。

なので、より便利に使っていくためには当然、オンプレ環境とシームレスに接続したいということで、VPC、VPNでまず小さく始めて、トラフィックが出るようであれば、Direct Connectでしっかり接続して、我々インフラの1つとしてAWSを考えるところまで持っていけたらなと思っています。

現状の運用についてなんですが、Webインタフェースでぽちぽちやっているんですけども、当然ミスもありますし、「これ何だっけ」っていうのがあるので、皆さん使われているとは思うんですけども、APIを使って、既存オンプレ環境と操作性を統一する。たとえば、chef、ansibleなりを使って手順を高度化する。そして自動化していくところで、もっと大きなシナジーが出てくるかなと考えています。

最後なんですけども、今回はEC2とRoute53しか使っていません。本当はデータベースはRDSを載せたほうがいいんじゃないとか、いろいろなことは当然あるとは思うんですけども、「そのまま」というキーワードがあって、そのままMySQLを持ってきたりしました。

なので今後はEC2以外、Route53、ELD以外の、たくさんのAWSの専用のサービスについて試して、知って、使いどころを判断して、自分たちで作り込むよりAWSさんにお任せしたほうがいいところは、ぜひ使っていきたいなと思っています。ほぼ毎週、AWSさんからいろいろなプレスが出たり、機能が出たりするんでキャッチアップが大変なんですけども、エンジニアとしては非常におもしろいところだと思っています。

AWSを使うことによって組織は変わる

スライドはこれが最後なんですけども、総括すると若干ここでプレゼンをしてるからというのもあるんですけど、「AWSを使ったからってそんなに組織変わるの？」ということですけど、答えは「イエス」だと思ってます。

ドワンゴのインフラとか組織が、若干長くて、組織体系が長くて、凝り固まっていた部分も理由の1つではあると思うんですけども、やっぱり大きかったのは、先ほどスライドでも説明したように、アプリとインフラ、上物と縁の下が、いままで明確に分かれていて、そこで時間であったり、コストであったり、調整が入っていて、スピード感がなかったことがあります。

そこをAWSを使うことによって、非常にスピードを上げられて、組織も変わった。組織が変わったのは、何から変わるかというと、やっぱりエンジニアのマインド、サービスに対するオーナーシップとか考え方から変わってきたのかなと思っています。

ドワンゴはこれからもいろいろなサービスを作り続けていくんですけども、先ほど申し上げたようにオンプレとAWSの比較をして、スピード感であったり、コストであったり、最適なところを検討して、柔軟性を持って、皆さんに楽しんでいただけるサービスを作っていきたいと思っています。

発表は以上となります。ありがとうございました。

（会場拍手）