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