インフラ設計と運営チーム – 大規模トラフィックを支えるDMM.comのインフラとその文化
AWSやGCP、Azureなどのクラウドサーバの登場によりインフラ構築は誰でも気軽に行えるようになりました。物理サーバからクラウドに環境を移行した会社も数多くあり、クラウド全盛期の時代だと言っても過言ではないでしょう。
一見するとクラウドにすべて移行しても良いように思えるかもしれませんが、物理サーバから移行すべきでないケースも多々あります。このクラウド全盛期の時代に、オンプレ環境で開発をやる上でどのように物理サーバを運用しインフラを育てているのでしょうか。今回はDMM.comにどのような課題があり、それらをどう解決していったのかお伺いしました。
大久保：弊社はオンラインゲーム、動画配信、電子書籍をはじめ、通販ショッピングや競輪も楽しめる総合エンタメサイト「DMM.com」を運営しています。弊社は、現CTOである松本が2018年にジョインしてからテックカンパニーとしての指針「DMM TECH VISION」を公開しました。これは現在40以上のサービスを支える「当たり前」をアップデートし続けていくためのDMMのテックチームの「在り方」を示したものです。
40以上のサービスの中でも特に中心となっているオンラインゲームや動画配信。これらのサービスを支えるインフラチームで活躍している2人に弊社のインフラサービスについて語ってもらいたいと思います。それぞれのチームでどのように考え、インフラを構成しているのか、自分も聞くのがとても楽しみです。
目次
クラウドへの移行は進めるがすべてクラウドにはしない。物理サーバでなければならない役割とは
物理サーバは1000台超。クラウド移行はしても全体の7-8割はオンプレミス
日名川：弊社では物理サーバが1600台、VMの数が約5300台あり、それに加えてクラウドも利用してサービスを運用。ここ数年の新規サービスについてはクラウドでリリースされていますが、全体ではオンプレ環境が7〜8割ほどを占めています。
サーバ構成はシンプルでWebサーバ、キャッシュサーバ、DBサーバがありそれらの前にロードバランサーが立っている形。珍しいミドルウェアもほとんどインストールされておらず、memcached、Apache、nginxなどを使用しています。DBはすべてMySQLで、誰でも運用がしやすい環境であると言えます。
新規サービスが立ち上がったときのインフラは、クラウドが第一候補にはなりますが、適材適所で物理サーバを使用する場合もあります。サーバレスで開発したいのであればクラウドを利用し、VMを構築する必要があればオンプレを利用しますね。
また、物理サーバの台数が1000台を超えているためオンプレを使用する方がコストが低く抑えられます。物理とクラウドの両方を使用すれば単純計算で費用は2倍かかることになってしまいます。
動画サービスのデータ量は10ペタバイト超。コスト面でオンプレ環境の恩恵は大きい
菅野：動画配信サービスではデータ量の多さもありトラフィックが300Gbpsを超えることも。トラフィック量は年々増加しておりクラウドでこれをさばくのは困難なうえ、料金もオンプレより大幅にかかります。そのためコストの低さから動画配信サービスはオンプレ環境で運用していますね。動画配信サービスはデータ量も多く現状では10ペタバイトを超えています。大雑把な計算ですが、例えば2ペタバイトのデータをS3の東京リージョンに置くだけで500万円ほどかかり、映像配信を1日中安定して100Gbps提供したとすると月に3億円ほどかかります。圧倒的にオンプレの方がコストパフォーマンスに優れていますね。
ただし、動画配信サービスのすべてがオンプレで運用されているわけではありません。例えば動画のエンコードはクラウドで行い、オンプレではそれを配信しています。サーバレスにできる部分はクラウドに任せるべきです。たとえば動画配信における管理ツール。管理ツールであれば、オンプレ環境をわざわざ用意することなく環境を作れるため効率がよくなります。
オンプレからクラウドへの潮流に乗る。しかし、移行は簡単ではない
日名川：静的ページなどの単純なWebページは、動画配信のようにトラフィック量が多くないため大きな問題もなくクラウド化を進めています。なお、急激なスパイクが見込まれるページでは、ピーク帯のリクエストを処理できるリソースを常時用意していると費用が高くなるため、クラウド環境のオートスケール機能がメリットになるでしょう。
弊社では例えば会員ログイン画面ページはクラウド化しており、会員情報などのデータだけはオンプレにあります。同じように電子書籍サービスもデータ以外はクラウドに完全移行していますね。
また、トップページのヘッダーとフッターはAPI化。APIを叩くことによって表示されるようになっています。API化するまでは全事業部がそれぞれのページでヘッダーとフッターを持っていたため、更新があるとそれぞれの事業部で対応する必要がありました。それを一元的に管理できるようになったので、かなり楽になりましたね。
静的なWebページのクラウド移行だけでなく、決済やポイントなどの全サービスが共通利用する機能がまとまったAPI群のゲートウェイをGCPに移行する計画もあります。現状でも、物理サーバが何台か落ちても耐えられるように設計していますが、自動スケーラビリティのコストを考えるとAPIはクラウドに移行させるべきとの判断になりました。
オンプレからクラウドへの移行にはやはり苦労することが多々あります。例えば、全サービスで共通している部分のデータベースはクラウドに移行できない点。データ量の膨大さもありますし、数々のサービスと密に連携しているため全事業部で改修が必要に。共通データの移行ができないためオンプレのデータベースと、クラウドに移行させたデータベースの両方を繋ぐ必要があります。AWSへ移行させた場合はダイレクトコネクトを利用していますね。
さらに共通データベースに変更を加えてしまうと他サービスに影響があるため、改修がしづらいとの課題もあります。この点に関しては共通データベースをなくす話しもでていますので、いずれ改善されると思います。
通信量が多いのもクラウド移行ではネックになります。AWSに移行した会員ページからオンプレのAPIを叩くようになっているのですが、秒間のリクエスト数が多すぎて送信元グローバルIPのポートを使い切ってしまいポートが前のセッションと被ってしまう問題がありました。調べても他に実例がなかったので苦労しました。最終的にリクエスト時のkeep-aliveを有効にしポートが前のセッションと被っても問題無いように改修しました。API群のゲートウェイをGCPに移行する件でも、NAT用のIPを増やしてポート番号が被らないようにしています。
インフラを育てていく。DMMのインフラ設計と方針とは
インフラを育てるうえで外せない監視・バックアップ・セキュリティ。その中でも特に「監視」に注力
日名川：弊社ではクラウドに完全移行することはトラフィック量やコスト面なども含めて不可能に近いため、自社のインフラを育てていく必要があります。インフラを育てると聞くと難しく聞こえるかもしれませんが、「Apacheをnginxに変える」作業だけでもインフラを成長させたことになります。さばけるトラフィック量が全然変わってきますからね。
インフラを育てていく上で監視・バックアップ・セキュリティの3つが重要。これら3つが揃っていると安心感があります。その中でも個人的に特に力を入れたいのは監視。障害の再発防止はだいたい監視に集約されます。
菅野：異常系の監視だけでなく、悪意のあるアタックがあって急激にトラフィック量が増加したときに検知できるような監視も入れておくべきですね。アクセス数の急な増加は異常ではないためアラートは上がりませんし、ユーザから連絡が来るわけでもありません。ですが、その瞬間はサイトの応答速度が明らかに落ちてしまいます。これを把握できていないとユーザからするとただの重いサイトだと見なされてしまう。普段からどういった動きをサービスがしているかを把握しておくと改善しやすいでしょう。そもそもネットワークインターフェイスを10Gでなく25Gのものを入れてたら、アクセス増加に耐えられるかもしれません。
インフラの構築。物理サーバやストレージ製品を選ぶところから始まる
菅野：ネットワークインターフェイスのように自社インフラの場合は物理サーバやストレージ製品の選定があるため、クラウドとは違った考慮をする必要があります。例えば、キャッシュサーバを構築するときに、メモリでキャッシュするならメモリ増強をして、ストレージでキャッシュするならSSDを多く積めるようなサーバを選びます。最近だとNVM Express（NVMe）にするなどの選択肢もあります。また物理サーバのOSインストールをするため、各種パラメータをどうするかミドルウェアになにを入れるべきかなども知識として把握しておかなければなりません。
また、DMMのデータはスキャリティのソフトウェア・デファインド・ストレージに10ペタ以上入っているため、仮にスキャリティが潰れた場合はどうするのかという課題もあります。アプライアンスでストレージを入れた方がいいのではないか？など検討の余地はまだまだあります。
インフラチームの組織づくり。深夜対応をいかに削減させるか
日名川：どの企業でも同じだと思いますがインフラチームには深夜の輪番対応があります。当たり前ですが、深夜に何も起きないに越したことはありません。そのためにも「サーバが落ちたときにどうなるのか？」などは常に課題として考えておくべきですね。
ただ、弊社ではインフラチームが深夜対応することは体制上それほどありません。トラブルに対応する手順書を作成しておけば、障害が発生した際にMSP(Managed Service Provider)チームが24時間対応してくれます。手順書で対応できないときは、インフラチームにエスカレーションする仕組みになっているため安心ですね。
手順書は用意する。それでも対応できないケースもある
菅野：動画配信サービスでは物理サーバのディスクが壊れることはよくあるのですが、そちらに関しても手順書化し、専属のチームが24時間体制で対応しているので私たちが直接対応する必要はありません。ただ、「物理の破損はしてないけれど外部に通信ができない」「物理は壊れているけどWebサイトは稼働はしている」というような手順書では対応できないケースも多々あります。オンプレの一般的でない障害対応は手順書に落としづらいのでどうしても自分たちが対応せざるをえない部分もあります。
属人化をなくす。インフラの運用を円滑にするためには
障害対応。インフラ担当者が成長するチャンス
日名川：長く続いているサービスに属人化はつきものだと思います。弊社も長期的に続いているサービスが多くあり、障害が起きたときに初めて気づくような設定や仕組みがよくあります。属人化されていて、かつ当時のエンジニアが誰もいないためにインフラがブラックボックス化されてしまっている。
属人化されている一例で言うと、DNS関連で過去にバグがありました。基本的にキャッシュアクセスにはヘルスチェック機能がついていて障害時はDNSから自動的に外れるようになっているのですが、そのヘルスチェックが特定のサーバのみ設定されていないことがあったのです。歴史的経緯でそうせざるを得ない状況があるようでした。
こういった障害が見つかった際には同様の現象が起きないか、他サービスにも横展開で確認を行うことも大切。障害対応したシステムだけを改修しても、他システムで同じ障害がおきることは考えられます。
障害を一つずつ改善していくことがインフラの成長に繋がっていきます。インフラが属人化されているとリプレイスや改善をするときに調査から入らなければなりません。物理サーバやネットワーク構成だけでなく、連携が密になっていてるデータベースなども最初に調べますが、これがかなり骨が折れる作業。また、調べているとOSやミドルウェアのバージョンが古いという技術的な負債もいくつか見つかることもありますね。
3人体制で動き、細かくチケットを切る。属人化を防ぐ対策
日名川：私のチームでは属人化を避けるために3人で作業をするようにしています。良いことなのか悪いことなのかわかりませんが、誰が辞めてもいいような状態にしているのです。3人体制にするだけで属人化することはほとんどなくなりました。
また、数分単位の作業でもチケット化して視覚化しています。「hostsに〇〇を追加してください」「ミドルウェアのパラメータ変えてください」などの粒度が小さいレベルで証跡を残すようにしています。サーバの構成図もありますが、更新するのが大変なのでそこに工数をかけるようなことはあまりしていません。時間があれば作った方がいいのですが、そこはチームの方針によると思いますね。
開発方針を決める。その際には会社ではなくチームやサービスに合わせる
菅野：私のチームではチケットで細かく切るまではしていませんが、Slackでチームにメンションしてやった作業内容を伝えるようにしています。Slackにナレッジとして残すことであとで検索ができるようにしています。
弊社はチームごとにそれぞれ開発方針がありインフラチーム同士でもまったくやり方は異なります。チームごとでやり方が異なるのは悪いことではありません。弊社はサービス数が多いのですが、会社として方針を統一する必要はないと考えています。チームで自由にやり方を選択できるからこそ、サービスや事業部に合わせたやり方で開発が行なえる。ルールを作りすぎるとチームの動きが遅くなってしまうので、個人的にはあまり決め事は多くない方がやりやすく感じますね。
手作業を「コード化」して「自動化」する。属人化を防ぐ環境
菅野：属人化を減らすためにインフラの作業をコード化することも進めています。私が入社したときはサーバ構築は手作業で行っていました。自動化する動きはあったようでしたが、サーバが1000台以上あり設定ファイルを書くだけでも大変で誰も手をつけていない状況。しかし、やはり手作業ではなくコード化したほうがいいだろうと思い、1000台分のサーバのVM名とIP、用途などを元々用途確認用に管理されていたスプレッドシートを活用し、jsonにパースできる仕組みを作りAnsibleに落とし込み自動化しました。
同じような問題でhostsで名前解決を行っている部分でも自動化を行いました。データベースへの接続時の名前解決はhostsで行っていため、リプレイスなどをするときにIPを変えるとなると1000台分のhostsの変更を加える必要がありました。hosts自体も千行以上の書き込みがあり、変更を確認するのも一苦労。これもAnsibleで変更するように自動化し、さらに内部的にDNSを立てるようにし解決しました。
他にもサーバのミドルウェアの設定をするときにCI/CDで自動で回せるように、プルリクを送ってもらってインフラが確認したらすぐに反映できるようにもしました。現在ではインフラチーム全体の方針としてインフラ作業はできる限りAnsibleでコード化するようにしています。サーバ作業を手作業で行うことは減ってきていますね。自動化することによってコードとしてナレッジが残り、属人化している部分が減っていくのです。
デプロイなどのツールの選定。会社で統一しない
日名川：デプロイについても課題がありました。 以前までは内製のデプロイツールを全サービスで使用していました。全事業部が使用して1000台以上あるサーバにデプロイを行っていたため、デプロイのたびに関係ない事業部を巻き込む問題が生じていました。影響範囲が広いためにデプロイ回数が減ってしまう悪循環。
デプロイ方法は統一していた方が一見すると使いやすいようように思うかもしれませんが、弊社の現状を考えると各チームに合わせてツール選定したほうが効率よく行えます。ただし、まだどうしても内製デプロイツールを使用しなければならない場面も残っているため、いずれは改善していきたいですね。
改善すべき課題はまだまだある。今後の成長の余地とは
クラウドと併用してインフラを育てていく
日名川：トラフィック量やコスト面のメリットがあるため、オンプレ環境がなくなることはありません。しかし、クラウドへの移行はどんどん進めていますね。新規事業であればオンプレではなくクラウドが第一候補になります。クラウドの選定は事業部ごとに委ねられており、AWS、GCP、Azureを自由に選択可能。
弊社ではAWSのサポートを上位クラスで契約しているため、AWSのサポートスタッフが毎週来てくれるため直接質問をすることができます。直接質問できないときにはSlackでやりとりします。GCPも同じようにサポート担当がついていて、毎週オフィスアワーのような形で来てもらっています。
ただ、クラウドへの移行が増えるからといってインフラの改善が終わるわけではありません。オンプレ環境がなくなることは弊社ではほぼないので、これからも継続的にインフラは成長させていきます。改善すべき点はまだまだありますね。
新入社員のためにも物理サーバの選定はナレッジ化する
菅野：取り組むべき改善点の一つとして、物理サーバの選定方法をナレッジ化する課題があります。物理サーバはトラフィック量やデータ量などによって必要なハードウェアが変わるため、購入を慎重に行わなければなりません。この選定を現状ではエンジニアの肌勘でやってしまっているため、新入社員が入ってきたときに伝えにくい部分があります。物理サーバの選定はナレッジ化自体が難しいのですが、いずれは取り組まなければならないと思っています。
また、私が入社したときはOSインストールは口伝で属人化されていたので、そこを資料として落とし込むところから始めました。OSインストールもいずれはKickStartなどを利用して自動化したい。OSインストールさえできればそこから先はコード化してあるので、ほとんど自動で作業が終わるようになります。
オンプレがクラウドの足かせをなくしていく
日名川：課題で言えばドメインの問題もあります。弊社の長年続いているサービスはwww.dmm.comのドメインに対して動画サイトなら/digital/のパスで表示するようになっています。本来であればサブドメイン化したいのですが、変更してしまうと様々な課題が出てしまう。売上に直結することなので変えるのは難しいところです。
また、ドメインについてはロードバランサーの問題もあります。オンプレにあるWebサイトを表示させるにはロードバランサーを必ず通ります。このロードバランサーで/digital/などのパスを設定して振り分けています。仮にクラウドに移行させた静的サイトがあったとしても、ロードバランサーが落ちてしまうと通信できなくなる。クラウドがオンプレに引っ張られて、スケーラブルではなくなってしまうのです。
インフラはアプリケーションがあってこそだと認識する
菅野：動画配信に関しては年々トラフィック量も増加していくため、ストレージもどんどんと追加していく必要があります。この課題はサービスが続く限りは終わらない。そこを主軸にしつつ改善も行っていきたい。
インフラはインフラチームだけで新規サーバを構築することはありません。アプリケーションチームが新規サービスを始めるときに、インフラチームも新規に物理サーバを作る。アプリケーションチームが改善に向かうときに、インフラチームも改善に力を入れます。アプリケーションチームとは足並みが揃うように動かなければいけません。
サービスが育てばインフラも育つ
日名川：インフラチームはアプリケーションチームの開発の手間をいかに減らすかが仕事。そのためにはどこまでインフラチームが見るのかなどの切り分けが大切です。アプリケーションチームが働きやすくなれば開発が円滑に進み、より良いサービスが生まれていきます。サービスが伸びていけばインフラは改善が必要。インフラを育てるにはただ改善をすれば良いわけではなく、必然的にサービスが伸びることに繋がっていきます。
さいごに ーー歴史ある会社だからこそ面白いインフラ設計
大久保：ここまで2人の話を黙って聞いていたのですが、すごく面白いなと思いましたね。というのも、単にインフラに特化した話ではなく、IT企業、Webサイトをやってきた会社が持っている課題をどのように解決していくかとの話に聞こえたので。
弊社は21年目。同様に2000年前後にできた会社は、そもそもオンプレしか選択肢がなかった。そこから、弊社のようにここまで成長した会社ってそれほど多くない。それらの会社はどこも同じように、基本オンプレでクラウドに移行する部分で苦労しているはずです。
この辺りは自分たちの世代が残してきた課題を2人のような若い世代に苦労してもらっているような感じがします。もう本当にごめんなさいっていう感じです（笑）
ただ、ここら辺の歴史の話も含めて弊社のインフラに携われることは楽しいと思っています。当然ですが事業会社である以上どのようにしたら事業をスケールさせていけるのかを考えなければいけない。そのために、インフラはどうあるべきであるべき姿に対してどのように育てていくか。2人のようなサービスを一緒に考えていけるインフラの人にとって、やりがいのある会社だと思いますね。
左より、大久保氏、菅野氏、日名川氏
