私たちが利用しているゲームやアプリ。そのほとんどは、24時間365日いつでも快適に使えることが当たり前です。しかしその裏には、“当たり前”を支えているプロフェッショナルがいます。インフラエンジニアです。
何らかのシステムを機能させるため、サーバーやミドルウェア、ネットワークなど統合的なアーキテクチャ基盤を構築・運用する。彼らがそうした業務に日々“フルスイング”し続けているからこそ、私たちはいつでもどこでもシステムを使うことができます。
システム＆デザイン本部IT基盤部第一グループ グループリーダーの漢 祐介（はた ゆうすけ）も、そんなインフラエンジニアの仕事の魅力にとりつかれ、自信の技術を磨き続けてきた1人です。
彼は、ライブ動画ストリーミングプラットフォーム「SHOWROOM（ショールーム）」やゲームやアプリの実況を生配信できるアプリ「Mirrativ（ミラティブ）」のインフラ基盤を担当。さらに、それらのノウハウを活かし、DeNA社内にライブストリーミングが簡単に構築できるような共通基盤を作り上げました。今回は、DeNAの縁の下の力持ちを務めてきた漢のインフラ構築術に迫ります！
目次 [隠す]
入社前から憧れていた、DeNAのインフラ
――漢さんは、DeNAにいつごろ入社を？
漢：2012年の4月で、約6年前ですね。僕はDeNAに入る前にITベンチャーで働いていたんですけど、当時からずっと「DeNAを支えているインフラ基盤ってすごいらしい」という情報は耳にしていました。それで、もっと自分の力を試してみたいと思い、DeNAを受けたんです。
――では最初から、インフラエンジニアとして仕事をしていたのですか？
漢：いえ。僕が最初に入ったときはまずゲーム開発を担当しました。当時の僕はインフラ周りのスキルが今ほどはなかったので、人事と話して「まずはゲーム開発をしながらインフラを経験し、その後にIT基盤部（DeNAのITインフラを担当する部署）に移ったらいいんじゃないか」という話になって。
システム＆デザイン本部IT基盤部第一グループ グループリーダー 漢祐介
都内ベンチャーから「もっと自分の力を試したい」という思いで2012年にDeNAに転職。モバイルゲームの開発・運用を経てIT基盤部に配属、開発からインフラまで身に付けフルスタックエンジニアを目指す。現在はIT基盤部第1Gのリーダーとして、様々な領域のインフラ業務に携わっている。
――インフラチームに移ってから、技術力のすごさは感じましたか？
漢：感じましたね。僕が最初入ったのはデータベースを担当しているDB基盤というチームだったんですが、何がすごいって運用ノウハウ。サービスを止めないためにシステムの各コンポーネントが必ず冗長化されていて、可用性を高めるために想定される負荷量をちゃんと見積もるとか、色んな指標をちゃんとチェックしていました。
それから、何かのトラブルを検知する監視の仕組みも整っていました。例えば、DBに対してインデックスが効いていないクエリが流れるとレスポンスが悪くなりお客様に影響が出てしまうので、「遅くなる可能性があるクエリを見つける仕組みとノウハウ」が設けられているんです。スロークエリの監視は多くの企業がやっていると思いますが、それよりもさらに一歩進んだ感じ。それらの情報をリアルタイムで取得できる仕組みが整備されていて、感動しましたね。
SHOWROOMのアーキテクチャは、どのように変遷した？
――動画配信のインフラ基盤を担当するようになったのはいつ頃からですか？
漢：2014年くらいです。その頃にチーム編成が変わって、DB基盤チームからエンターテインメント事業のインフラの担当になり、ちょうどサービス開始したばかりのSHOWROOMのインフラ基盤を担当することになりました。当時は動画配信についてのノウハウはほとんどなくて、自分自身で開拓しなければいけない時代でした。
どんなアーキテクチャが最善なのか、ずっと手探りで考え続ける毎日で。運用を積み重ねながら、「トラフィックがこれだけ来たら映像が止まってしまう」「配信サーバーにどれだけ負荷がかかると映像が遅延する」といった情報を学びつづけていきました。それに関連した話をすると、実はSHOWROOMってインフラ基盤のアーキテクチャが何回かモデルチェンジしてきたんです。
――どういった意図で、どのようなモデルチェンジをしてきたのですか？
漢：最初は、SHOWROOMってすべてのサーバーがクラウド上で動いていたんです。映像データが配信されるOriginサーバーも、映像をユーザーに届けるEdgeサーバーも。そして、すべてのEdgeサーバーがすべてのOriginサーバーに接続する「フルメッシュ」というネットワーク構成を取っていたんです。
でも、そのアーキテクチャのときに、ある問題にぶち当たりました。Edgeサーバーを増やしていくと映像がどんどん遅延してしまったんです。
何が原因かを調べたところ、人気のある配信が特定のOriginサーバーに偏った場合、すべてのEdgeサーバーの接続がそのOriginサーバーに集中してしまい、他のOriginサーバーにEdgeサーバーが向いてくれない（＝映像データの取得が遅延する）という事態が発生していました。
――その状態を解決するため、どんな施策を実施しましたか？
漢：OriginサーバーとEdgeサーバーを数台ごとにShardingすることで、特定の配信に人気が集中しても他の配信に影響が出ないようにしました。さらに第2弾のアーキテクチャ更改として、Originサーバーをクラウドからオンプレミスに持ってくる、ということを実施しました。なぜかというと、サーバーの可用性をさらに高くしたかったから。
クラウド上にあるサーバーって、自分たちのコントロール外の事象でインスタンスが落ちることがあるので、可用性を上げるため、オンプレミスに持ってくることで自分たちでメンテンナンスできるようにしました。
優れたインフラ基盤構築のカギは、“影響の局所化”と“自動化”にあり
――その後、漢さんはMirrativのインフラ基盤を担当し、これらの経験を活かして汎用的に使えるライブストリーミングの共通基盤を構築したそうですね。どういったノウハウが、その基盤には盛り込まれていますか？
漢：さまざまな技術が使われていますが、ここではいくつかピックアップして解説します。
Edge管理テーブルで、サーバーの「重みづけ」を管理する
漢：Edgeサーバーの情報は、Edge管理テーブルというものによって管理されています。このテーブルには、IPアドレスやホスト名などのサーバー情報を保持しているのですが、その中に「weight」というカラムがあります。
これは、サーバーへのアクセス量の「重みづけ」を管理するためのものです。どういうことかというと、例えば値が「100」の場合は通常のアクセス量、「200」ならその倍、「10」なら10分の1といった具合に、この値を書き換えることでサーバーへのトラフィック量をコントロールできます。
weightをコントロールすることで、shardの空き状況をみてedgeそれぞれのトラフィックを寄せたり外したりできるようにしています。こうすることで、必要以上のトラフィックにならないようにコントロールできる運用をしているんです。
これは、DB基盤時代に培ったノウハウを流用しています。DBサーバーを新規で構築したときって、サーバーのメモリが充分に温まっていない状態で大量アクセスを流すと処理が遅延してしまうケースがあるんです。そうした事態を防ぐため、まずはweightを小さな値からスタートし、徐々にアクセス量を大きくする、といった運用をしています。
重みづけのパラメーター調整は、自動化する
漢：さらに、weightのパラメーターチューニングも自動化しています。視聴者数や全体的なアクセス量などをリアルタイムで集計し続けているシステムがあり、それがweightの値を定期的に書き換えているんです。
Shardingにより、負荷量増加の影響を局所化する
漢：これは先ほど解説した内容とも重複しますが、予め高画質な配信をすることがわかっている場合は、Edgeサーバーを多めに用意した専用Shardで配信するようにしています。さらに、配信する番組とShardの紐づけもテーブルで管理しているため、運用コストがそれほどかからないようになっているんです。
サーバーメンテナンスのための仕組みを設ける
漢：ハードウェアの故障や脆弱性対応などによるサーバーのメンテナンスはいつでも起こりえます。だから、それを簡単に実現するための仕組みを設けています。Origin管理テーブルのカラムの中に（サーバーの）statusを持っていて、その値が「0（利用不可）」だった場合に新規の配信を受け付けないようにしているんです。こうすることで、安全にサービスアウトできるようになっています。
サーバーがオートスケールする仕組みを構築しておく
漢：人気のある配信があって、必要となるサーバーを大量に用意する必要がある場合、インフラエンジニアが毎回手動オペレーションで運用しては工数が膨大なものになってしまいます。そこで、各サーバーに一定以上の負荷量がかかった場合、自動的にスケールアウトする仕組み（オートスケール）を導入しています。
「サーバーの限界値になったときに何が起きているのか」を理解する
――オートスケールの仕組みを実現するため、サーバーに一定以上の負荷がかかっていることをどうやってチェックしているんですか？
漢：負荷量を監視する膨大な数のスクリプトを動かしており、それらがアクセス増加を検知しているんです。サーバーの20～30種類くらいの指標を常に取得していて、スケールアウトが必要と判断する閾値を超えたらオートスケールの仕組みが作動するようになっています。
――具体的に、どういった監視項目を設けていますか？
漢：例えば、トラフィック値。何Gbps（gigabits per second：ギガビット毎秒）くらいの流量が各サーバーに流れているのかを監視しています。それから、同時接続数。データのトラフィック量がそれほどでなくても、接続数が増えるとダメになるケースもあるので。
さらに、データセンター全体のトラフィック量。データセンター自体にもトラフィックの上限値があるので、その値に達しそうであれば別のデータセンターにトラフィックを流せるようにしています。他にも、数多くの項目を監視し、安定してオートスケールの仕組みが動作するように工夫しているんです。
――監視の仕組みを構築するには、サーバー1台ごとの性能上限を計測する「負荷試験」が欠かせないかと思います。負荷試験の実施にあたり、工夫していることはありますか？
漢：サーバーの性能限界を見つけること。そして、限界値になったときに「何が起きているのか」を理解することですね。
過去の事例を話すと、ライブ配信で僕たちが使っているプロトコルってRTMPとHLSというものがあるんです。負荷試験を実施した際に前者はCPUの中の%user（ユーザレベルのCPU使用率）という値が高くなり、後者は%irq（CPUの割り込み実行時間割合）が高くなりました。
「HLSの場合、どうして%irqが高くなるんだろう」と追加調査してみると、使用されているNIC（Network Interface Card：コンピューターなどの機器を通信ネットワークに接続するためのカード型拡張装置）の性能があまり良くない、ということがわかりました。NICを標準のものからより性能の良いものに切りかえたら、ちゃんとサーバーの性能限界まで出たんです。
――何がボトルネックになっているのかを徹底的に調べる姿勢が重要なんですね。
監視用の携帯端末が1度も鳴らなければ、僕らの勝ち
――漢さんの話を聞いていると、この仕事ってものすごくクリエイティブなんだという印象を受けました。仕事をしていて、どんなときにやりがいを感じますか？
漢：例えば、事業部サイドから「明日、このアプリで芸能人の○○さんが出演するからサーバー100台用意して！ 100台どころじゃ足りないかもしれない！」みたいなメッセージがたまに来るんですけど（笑）、そんなとき無事に配信が終わったときは何より嬉しいです。
僕らって、システムに何か異常があった場合に検知できるよう監視用の携帯端末を持っているんですけど、「これが1度も鳴らなければ僕らの勝ち」だと思って仕事をしています。何も起きないことがやりがい、というか。
――不思議なものですね。通常、エンジニアにとっては目に見えるものが成果だけど、逆にインフラを支えている人たちにとっては目に見えないものこそが成果というか。
漢：そうなんです。システムが当たり前に動く状態を当たり前に維持する。これが難しいんですけど、最高に面白くて。
――漢さんは、今後どんなエンジニアになりたいですか？
漢：ちょっと前に、フルスタックエンジニア（フロント、サーバー、インフラなど、複数領域のスキルを身につけたエンジニア）という単語が流行しましたよね。でも、あれって「まだまだ不十分」だと僕は思っているんです。僕は、真の意味でのフルスタックエンジニアを目指したくて。
――具体的には、どういうことですか？
漢：インフラもできるし開発もできるし、さらに“サービス”のこともちゃんとわかっているエンジニアになりたいです。「どうサービスを育てるか」という目線を常に持っておきたい。実は僕、自分がインフラ構築に携わったすべてのサービスを、自分のスマホにダウンロードして毎日使っているんです（笑）。
――サービスへの愛があるんですね。
漢：そうですね。もっと良いサービスに育てたいですし、視聴者にとって何が面白いのかきちんと理解しておきたい。完璧なものを届けてあげたいんです。いつもそう思いながら、仕事をしています。
