スマートフォン一台で配信を楽しめる、ゲーム配信プラットフォーム『Mirrativ』。その安定したサービスを支える基盤について、インフラチームの漢 裕介が語ります。前職で多くのライブ配信プラットフォームの立ち上げを経験した漢から見た『Mirrativ』の魅力や、多くのユーザーさんがアクセスするライブ配信プラットフォームのインフラ構成に迫ります。
（語り手：漢 裕介、聞き手：横手良太）
※2021年12月9日時点のインタビューです

インフラ・ストリーミング グループマネージャー 漢 裕介（はた ゆうすけ）@octu0
クライアント・サーバ・インフラ領域のフルスタックエンジニア。OSS活動・スタートアップを経て、DeNA。ゲーム開発・運営・インフラマネージャ。ゲームの大規模トラフィックやSHOWROOM等のライブ配信サービスの基盤を設計運用。ミラティブではライブ配信基盤・インフラ基盤を担当

CTO 横手 良太（よこて りょうた）@n0mimono
早稲田大学大学院修了。機械学習の分野で博士号取得後、助手として研究活動、論文執筆を行う。2014年に株式会社Donutsに入社し、スマートフォンゲーム開発に従事。2017年より技術部部長。2018年7月ミラティブ参画し、ミラティブのアバター機能「エモモ」の開発をリード。2021年4月にCTOに就任。

目次

1. ユーザーさん自身が工夫できるライブ配信サービスに惹かれて
2. 柔軟に時代に対応できる仕組みづくりを――Mirrativのインフラ構成
3. 運用ポリシーと想いの先に描く、ミラティブの未来

ユーザーさん自身が工夫できるライブ配信サービスに惹かれて

――ミラティブ入社前のキャリアについて教えてください。
漢「はじめはスタートアップに入社し、オープンソース活動に携わりつつ、プログラミングに関わる本や記事などを執筆していました。そこから高トラフィックなサービスのインフラに携わりたいという思いから、DeNAに転職しました。

僕が感動したのは、DeNAが当時の最新技術を駆使して人気の高いサービスの高トラフィックを捌いていると思っていたのですが、DeNAではその当時ある技術でカリカリにチューニングして磨き上げた上で最大のパフォーマンスを出していました。既存の技術でも愚直に磨き上げれば、他には真似できないような最高のパフォーマンスが発揮できるということを肌で感じたんです」

――そうした経験後、ミラティブへの転職を選んだのはなぜですか？
漢「DeNA内で新規事業のインフラを担当することになり、SHOWROOMやPocochaなどのライブ配信系の基盤を作る機会が多くありました。その中のひとつが、DeNA内で生まれた配信サービス、Mirrativです。

ライブストリーミングサービスが今後伸びてくるだろうな、次に働くならライブ配信事業に携われるところがいいな、と思っていた矢先、赤川さんがMirrativの配信を見せてくれたんです。そのときの衝撃が、転職のきっかけになりました。

当時のライブ配信は、自分自身を映しながら話すスタイルが一般的でした。一方Mirrativでは、ユーザーさんが簡単な無料アプリゲームを画面に映しつつ、自分たちで遊び方を見つけて楽しんでいて……。その配信を見たときに、ユーザーさんが自ら工夫することで、楽しみ方にバリエーションが生まれるサービスはおもしろい、配信を自分で作れるってすごい、と感じたんです」

（語り手：漢 裕介）

――ミラティブ入社後の役割について教えてください。
漢「インフラ・ストリーミングチームでMirrativのインフラとストリーミング基盤を支えています。一般的にインフラ部門は運用保守とSREのようなシステムに近い側の部門に区別されますが、ミラティブのインフラチームが担う役割は広く、その両者を包括しています。またミラティブではインフラチームと基盤開発を行うチームがとても近くで働いています。

基盤開発については、例えばPerlからGoへの移行を推進したり、PerlとGoのパスルーティングを動的に切り替える仕組みとしてEnvoyを導入したり、他にも自動デプロイの仕組みを作ったりといろいろありますが、わかりやすいところで言うとそんなところで、アプリケーションとインフラを繋ぐ基盤となる開発をする部門です」

柔軟に時代に対応できる仕組みづくりを――Mirrativのインフラ構成

――Mirrativのインフラ構成について教えてください。
漢「Mirrativはマルチクラウド構成を採用しており、AWSやGCP、IDCFを用途に応じて使い分けています。インフラ構成は、アプリ起動後の通信先はGCP、動画配信の動画データはIDCFに飛ぶという形です。また、ほぼすべてのサーバの構成はIaaSで行っており、自前のVMの起動・管理、その上で動くミドルウェアの管理も含め、すべてミラティブのインフラエンジニアが担っています」

――ミラティブのインフラエンジニアは、コードを書く機会はあるのでしょうか？
漢「ゴリゴリ書きます。ミラティブは、設定ファイルを使ってインフラを構成するだけでなく、動的に作って、増やして、対策して、というスタイルです。基本的にはダウンタイムゼロで運用していますから、コードを書かざるを得ない環境ともいえるかもしれません。あるメンバーは入社した当時Goのコードを書けなかったけれど、そこから2年弱くらいでGoを習得して、ミドルウェアを自分で書けるレベルになりましたね」

――開発言語としてGoを選んだ理由は？
漢「シングルバイナリであることが大きいです。PerlやPythonでもシステム構成はできたのですが、テストの確実性が高いことや、開発環境/本番環境で同じバイナリを使える安心感という点でGoを選びました。以前はTerraformやItamaeを使っていましたが、現在はほぼすべてをGoで書き直し、OSもCentOSからCoreOS系のOSへ移行しコンテナベースで管理するようにしています」

――昨今トレンドであるKubernetesなどを利用せず、あえて自前で作るのはなぜですか？
漢「新規の場合や細かなところを見なくてもいい仕組みであれば、Kubernetesを利用しても問題ないと思います。ただ、Mirrativの場合は、コストやインスタンスの性能劣化などをしっかり管理しますし、エラーレートも秒単位で見ています。それをKubernetesでやろうとすると、できなくはないですがKubernetesの旨味を失い、逆に難しいんです。加えてバージョンアップのことなども鑑みた運用工数を考えると、既存の仕組みからKubernetesを利用するメリットをあまり感じませんでした。自動化できるように作ってしまえば、結果的には自前でも大きく変わりません。

また、基本的に技術は5年経てば廃れるものだと考えています。今いいとされている最新の技術に移行しても、また5年後には新しいものが普及してくる。であれば、小さな単位で管理して、乗り換えやすいようにしておくほうがいいかな、と。この考え方に則った運用は、ベンダーロックインを防ぐ観点でも効果的です」

運用ポリシーと想いの先に描く、ミラティブの未来

――インフラチームの運用ポリシーについて教えてください。
漢「『N-1』、『All or Nothing』、『Dont guess, Measure』の3原則を掲げています。それぞれ簡単に話しますね。

『N-1』とは、冗長化・冗長度についての考え方です。コンポーネントを冗長化しようとした場合、冗長化したコンポーネントがN冗長化されている場合に、Nが1つ減った状態、つまりN-1個でもN個と同じ正常にパフォーマンスを提供できるようにするための考え方です。

また、冗長度は際限なく上げてしまうこともできますがそうならないようにN-1個の冗長度を守っていくという考え方でもあります。冗長度を上げることは管理するコンポーネントの数を増やすことになり、運用コストを含め、メンテナンスコストも増え続けてしまいます。こういった設計は避けなければなりません。

自動車に例えるならば、タイヤが1個欠けても走れる状態にするためにスペアタイヤを準備することは大切ですが、そのスペアタイヤが壊れたときのことまでを考慮してさらにもう1個、2個と別のスペアタイヤを用意することはしない、というイメージでしょうか。同時に2個以上のタイヤが欠ける事故（多重障害）が起こることは考えづらいですから、シンプルな構成を維持しつつ、冗長化処置ができる設計を目指そう、という方針です。

続いて『All or Nothing』は、インフラ以外のプログラミング領域でも共通しますね。1箇所だけリファクタリングするならば全体をリファクタリングする、あるいはやらないという意味です。その場しのぎで部分的な修正をしていくと、その積み重ねは往々にして煩雑な状態につながります。手をつけるならば全部片付ける、という考え方です。

最後の『Don’t guess, Measure（憶測するな、計測せよ）』は、コンピューターサイエンスを学んだことがある方にはなじみ深い言葉ではないでしょうか。これはサービス運用に関わるうえで、とても重要な考え方です。例えば、エンジニアがチューニングしたらレスポンスが速くなりました、というのはよくある話だと思いますが、そのチューニングによって何％のユーザーさんが救われたのかは計測していなければわかりません。ちゃんとユーザーさんにとって意味のある部分を改善しましょうね、という心構えを表しています。レスポンスタイム以外のインフラ領域でもきちんと計測し、もし計測できていないのであれば計測できるようにしながら、パラメータや構成を変えてチューニングすることはとても重要なことです」

（聞き手：横手良太）

――同様に重視している、コストについての考えも教えてください。
漢「MirrativはtoCのエンタメサービスかつ映像のストリーミングを扱う性質上、インフラコストが固定費に占める割合の多い特徴があります。この割合を減らすためには、コスト管理が極めて重要です。

もしもユーザーさんの数が100倍になったら、それを支えるために100倍お金をかけるのか、というところですよね。スケーラビリティを保ちつつ、事業がどうなっても受け切れるような仕組みを作ることがインフラ領域のコスト管理の肝です。抑えられるところをちゃんと抑えれば、体力を温存しながら持久走をできる基盤が整います。これは、そのまま会社としての強さにもつながっていきます。コストについてはそんなふうに考えていますね」

――漢さんが仕事に取り組むうえで大切にしている考え方はありますか？
漢「エンジニアは職業柄最新技術が大好きなのですが、手段が目的化してしまっては本末転倒です。目前の課題を解決するためにはどんな技術が最適なのか、常に考えるようにしています。愚直に課題に向き合うほうが、最新技術を使うよりも近道であることも多いです」

――インフラに関わっていてモチベーションが上がるのは、どんなときですか？
漢「やっぱりMirrativが安定して動いていることでしょうか。例えば、元旦の『あけおめ配信』のようにユーザーさんが一斉に配信を楽しむとき、インフラ関連のアラートがゼロだと『勝利した！』と思います」

――では最後に、候補者さんにメッセージをお願いします。
漢「ミラティブはインフラのあらゆる部分で自分で計測したり直したり置き換えたり、そのために何を導入するのか自分で選んだりと、一般的なインフラエンジニアよりも自由度が高い仕事ができると思います。また、開発チームのメンバーとの距離も近く、インフラエンジニアだけれどものづくりがしてみたい、という人には向いている環境です。

僕はいつか、ミラティブ自体が自前のデータセンターをもつところまでもっていけたらいいな、と考えています。言葉がいいかわかりませんが、社会インフラのようなイメージでしょうか。パブリッククラウドではなかなかできないことも、自前で持ってしまえばもっとやれることが増える。そしてそこまで自由度が高くなると、もっと大きく物事を動かすことができるようになる。そんな未来を目指して、ともに歩める方をお待ちしています」

安定したライブ配信の基盤を支え、ユーザーさんの体験向上に資する改善を続けるインフラチーム。その背景には、ポリシーを軸として選びぬいた技術と、コスト管理への視座、そして愚直に良きものを作るという意志があります。ミラティブのインフラチームに興味を抱いた方は、ぜひお気軽に「話を聞きに行きたい」を押してください。

▼ミラティブエンジニア向け会社紹介資料/Engineer's Handbook