リリース時点で秒間1万リクエスト に耐えられるシステムが、いつか「ゲームの安定リリースを支える技術」となり得る

― サイバーエージェントのゲーム事業において、PHPはどのように活用されてきたのでしょうか。

私は2010年3月にサイバーエージェントグループに中途採用で入社しました。その前はゲーム開発を行うベンチャー企業に在籍していたのですが、当時からフィーチャーフォン向けのWebサイトやゲームアプリにPHPが使われていました。

フィーチャーフォンは絵文字をはじめとして機種依存やキャリア依存する傾向が強く、PHPにはそういった特徴をカバーするライブラリーが豊富だったのが導入の理由だと思います。

その後、スマートフォンが普及し、サイバーエージェントのゲーム事業も2012年に急拡大していきました。2013年にリリースした株式会社サムザップの「戦国炎舞 -KIZNA-」は、その当時でも1日1億リクエストを処理していましたが、サーバーサイドはPHPで開発していました。

― ゲーム開発における技術選定で大事なポイントは何でしょうか？

近年のゲーム開発で重要なのは「リリース日にユーザーが安心してゲームをプレイできること」です。

作り手がどれほど熱意をもって面白いゲームを開発したとしても「リリース直後に即メンテで、再開の目処は未定」となってしまっては、リリース日を楽しみにしてくれたユーザーの皆様をがっかりさせてしまいます。ゲーム事業としても大きな機会損失となってしまいます。

リリース日は、初めてゲームが世に出る大切な日です。心待ちにしていたユーザーの皆様に快適にゲームを楽しんでもらうために、今ある環境で最善を尽くすのがエンジニアの役割。選定する言語はあくまで手段でしかないと考えています。

ー サイバーエージェントのゲーム事業部では、PHPが引き続き選定されていますね。

技術選定で重視しているのが負荷対策で、それまでの経験やノウハウの積み重ねがある言語のほうが安全という判断です。

ゲームの負荷対策は、無数に落とし穴があるようなものです。PHPに関してはその落とし穴を一通り経験してきたので、社内に膨大な「成功と失敗の歴史」が蓄積されています。言語の中でPHPが特に負荷対策をしやすいというわけではありませんが、ゲーム事業としてノウハウが蓄積されているため、ゲーム開発のスピードを重視する上で、PHPが選定されています。

その一方、定期的にNode.jsやGoなど別の言語を採用する議論もしていますし、機能的に切り出している部分では、PHP以外の言語も選定して導入しています。
 

― ゲームの負荷対策とは、具体的にはどのぐらいの規模を想定していますか？

例えば、新規でゲーム開発する際は「リリース時点で秒間1万リクエスト をさばけるように対策を講じる」ことを最低ラインにしています。サーバー負荷は「読み込み」よりも「書き込み」のコストが高く、ゲームではキャラクターの体力を減らしたり、バトルのアイテム報酬を記録する書き込み処理が頻繁に発生します。

ユーザーからのリクエストは1回でも、データベースに対しては5倍の問い合わせ処理が発生するケースも多く、秒間1万リクエストに対して5万回のクエリが発生する事もあります。わかりやすい比較例だと、「天空の城ラピュタ」がTVで放送される時のTwitterの「バルス」祭りは有名ですが、それに近い要件です(笑)

※：2017年の「バルス」Tweet数は秒間48,445件、分間237,295件とされる。

同時に、クエリの発行数も極力減らす必要があります。フレームワークの高度化に伴い、開発者にとっては便利になる反面、カプセル化が推奨されていて、例えば「ユーザーのアイテムを取得する」というような処理もカプセル化されます。

「ユーザーのアイテムを取得する」という処理は、フレームワーク内部ではSQL文が1個発行されています。その際、データベースからの取得処理が非効率だったり、意図せぬバグで大量にループを発生させてしまうという事例も実際に起きました。

1つ1つは些細なミスかもしれませんが、リリース時やイベント時の大規模アクセスでは、致命的な障害に膨れ上がりかねません。その1つ1つをつぶしたり、丁寧にチューニングしていく必要があるので、泥臭い作業ではあります。

ゲーム事業部で蓄積しているノウハウは、新規ゲーム開発の成功と失敗の積み重ねの賜であり、リリースにまつわる膨大なノウハウが資産となり、短期間でクオリティの高いゲーム開発を実現できていると言えます。

ー 最初から秒間1万リクエストもさばかなくても良いのではないでしょうか？

実は以前に若手からも「秒間1万リクエストもさばかなくても良いんじゃないですか？」と言われたことがあります(笑)。しかし今の事業規模で言うと、事前登録に100万人ぐらい登録してもらう事ができた場合、その規模のリクエストが来る可能性は十分あり得ます。

実際、その若手が携わったプロジェクトでリリース日に8,000から9,000リクエストぐらいまで到達した事がありました。

その時は「いやー、やっておいて良かったね」とお互い称え合いました（笑）。
 

― ゲーム事業部のCTOや技術責任者としてマネジメントをしながらも、PHPカンファレンスなどで発表もしています。どのようなバランスを考えていますか？

ゲーム事業部のCTOに就任した際「CTOとはどういう存在なのか」を改めて考えました。その時、意識したのは「どういうCTOならエンジニアから信頼してもらえるのか」です。

CTOなので、技術者として信頼されるためには、何かしらの技術的なアドバンテージが必要です。とはいえプログラムを書くスピードで言えば、圧倒的に若手のほうが速いですよね。

自分が技術的にアドバンテージをもてる分野は何か。それはPHPの新技術やゲーム運用に関するノウハウについて誰よりも早く調査、検証することです。その結果をカンファレンスなどで登壇して発表しています。

特に、新技術に関する泥臭い検証やパフォーマンス調査など、ともすると誰もやりたがらないような事を調べて発表するようにしています。

新しい分野は若手もベテランもスタートラインは同じなので、がんばりやすい(笑)。「こういう思想で作られたシステムだからこういう使い方が推奨される」「こういう用途で使えばきっと効果的だ」等を理解することは、経験がものを言う部分が少なくありません。

もちろん私の場合は「開発中のゲームで使えるかどうか」という観点になります。ゲームで使うならこういう要件だからこういう使い方ならマッチする、だからゲームでもこの技術は活かせそうだ、という視点で深掘りしていって発表しています。

今はもう業務ではほとんどコードは書いていないので「カンファレンスの登壇を締切にして、そこに向けて検証コードを書いてプログラミングをする」というようにコードを書いています。勝手に「登壇駆動学習」と呼んでいます。

ー Kubernetesについての発表も2016年の頃にしていましたね。

2016年のPHPカンファレンスの時ですね。「そのうち流行りそう」と思ったのでゲームで使えるのかを詳しく調べました。その結果「こういう使い方ならゲームでも使えそうです」というのを一通りまとめたのが、その当時の発表です。

4年経った今では、コンテナ技術はスタンダードになりつつありますし、ゲーム事業でも少し遅れてはいますがコンテナ化が進んできています。

ー Developer Expertsとしてエンジニア組織にどんな役割を果たしたいと考えていますか？

エンジニア一人一人が自分の技術領域や役割にとらわれることなく、当事者意識や愛着をもって、自社のサービス開発に向き合える組織にしていきたいと考えています。

例えば、ゲーム事業にコンテナを導入するメリットはポータビリティが上がる点だけでなく、「アプリケーションエンジニアがインフラも管理できるようになる」点が、最大のメリットだと思っています。

ともすると「ここから先はインフラ担当者の仕事だから」と線を引いてしまいがちですが、コンテナ化によってコンテナの管理はアプリケーションエンジニアが見るのがスマートになります。つまりアプリケーションエンジニアがコントロールできる領域が広がる。これは大きなメリットだと思います。それに、分からない領域が多かったり、コアの部分をプラットフォーム任せにしてしまうと、障害が起きた時に解決に時間がかかってしまいます。

ゲーム事業部では、子会社のゲームに障害が起きた際、他の子会社のエンジニアたちも集まってきて、所属や職種を問わずに知見やノウハウを出し合って解決するカルチャーがあります。

今は他の新規ゲームの開発に携わっているエンジニアもいれば、同じような障害で苦しんだ経験があるエンジニアなど。声もかけていないのに、いつの間にか集まってきてくれるんですよね。

結束力の高い組織において、それぞれが高い解決能力をもっていれば、その知見を集めて最短で解決に向かうことができる。

そんなエンジニア組織を作りたいと考えています。