ピグパーティ技術挑戦史

—まずはピグパーティリリース時の話を伺いたいと思います。リリース時点でCocos2d-xを利用することになったと思いますが、どういった経緯で意思決定したのでしょうか？

遠藤：そうですね、当時のUnityは4系で、エリアにピクセルパーフェクトにアバターを20体表示させることがパフォーマンス上現実的ではなく、Cocos2d-xによる実装を選択しました。Cocos2d-xはほぼレンダリングエンジンとしての利用にとどめ、OS毎の機能やネットワーク通信などはC++により直接実装しました。これは現在でも同様の方針のままです。

—通信に関しても、新しい技術を採用されたのですよね。

遠藤：背景としてはリリース2015年当時、スマホのスペックも現在ほど高くなく、通信量が多くなるとバッテリーの消費も激しくなる、という課題がありました。PC版アメーバピグではTCP上に独自プロトコルを設計し、データシリアライズも独自の形式を定義して実装、ピグライフではwebsocket + jsonを採用していたそうなのですが、先ほどの課題を解決するためにピグパーティではオーバーヘッドの少ないMQTT + messagepack を採用しました。

—その他、アバターを動かす仕組みの面でも工夫された点はありますか？

遠藤：アバターのパーツは何枚もの画像のパーツに分かれているのですが、これらを組み合わせた際の描画パフォーマンスを向上させるために、動的にそれらを1枚のテクスチャにパッキングする仕組みが必要と判断しました。そしてそれをバックエンドで行うべくorigamiというシステムを開発したのですが、バックエンドの負荷的に現実的ではないと判断し、クライアントサイドでリアルタイムにテクスチャアトラスを生成するdynatlasを開発しました。これも現在でも使われている仕組みです。

また、当時はまだPCピグと並行稼働しており、Adobe Flashを扱えるエンジニアが多数在籍していたため、インタラクション制作のオーガナイゼーションツールとしてAdobe Flashを活用するため、SWFランタイムを実装しました。

—ユーザー数の増加に応じてサーバー側で大きな変化があったと思います。サーバーサイドで行ったGCP移行について教えてください。

鬼塚：当時、アプリケーションサーバーにプライベートクラウド環境を使用していましたが、その環境の世代交代が必要となり、新たな環境への移設を検討することになりました。その際、コストやKubernetes関連のサービスの充実度、そして社内でのGCP運用経験を持つメンバーの存在といった点から、GCPへの移設が最適と判断し、移設しています。

プライベートクラウド環境では、環境の世代交代に伴う定期的な移設が発生するのですが、そこにコストを払うことが難しく、パブリッククラウドを選択肢に入れました。スケーラビリティや耐障害性を確保するためにKubernetesでの運用を検討しており、その当時はプライベートクラウド環境でKubernetesを手軽に利用することができなかったため、パブリッククラウドへの移設を決定しました。具体的な移設先としては、GCPとAWSが候補となりましたが、コスト見積もりの結果、GCPがより経済的であると判断しました。

また、社内にGCPの運用経験を持つメンバーが存在し、サポートを得やすい状態であったことも、GCP選択の大きな要因となりました。プライベートクラウドと比較してコストは上がるものの、事業やユーザー目線では、急激なユーザー数の増加に耐えられるようになりつつ、プライベートクラウドでは手動で行わざるを得なかった操作を肩代わりしてくれる、というメリットがあり、GCPへの移設が事業的に問題ないとの結論が出たため、最終的にGCPへの移行を決定しました。これらの要素が組み合わさり、私たちはアプリケーションサーバーをGCPへ移設し、より効率的な運用を実現しています。

—次にアバターの着用アイテムにSpineを使用して、よりリッチな表現ができるような仕組みを開発していきましたね。

遠藤：そうですね。この時の背景をまずお話しますと、当時の事業戦略がアバターのデコ要素を強化していくような内容の戦略をとっており、きせかえアイテムの制作数やバリエーションがどんどん増えていく見込みとなっていました。 

きせかえアイテムの数が増えていくと、その中でもさらに魅力のあるアイテムを作りたいとなった時に、わかりやすく違いが出せる要素が必要となるわけで、以前からアイデアとしてはすでにありましたが、アニメーション付きせかえアイテムが作れたら面白いよねという話に至ったわけです。

また、アニメーション制作ということに関していいますと、PC版アメーバピグの方で元々Adobe Flashの技術を利用してピグのアクション制作などが行われていた歴史もあり、チーム内にはFlashに関する知見や資産が溜まっているので、ピグパーティにおいてもFlashを利用していました。 しかしながら、Flash自体はAnimateとして残っていますが、Adobe Airの開発は終了しツールのアップデートも難しい状況になってきていました。そういったFlash自体の衰退によりFlashを扱えるエンジニア・アニメーターも減り続け、人材確保も難しい状況になってきました。

そのため、アニメーション制作に用いる技術としては、

・アニメーターが集めやすい

・アプリやランタイムの開発も活発

・ピグアニメーションとの親和性も高く資産活用もできそう

という点からSpineを採用する流れとなりました。

Spineで制作したアニメーションをアバターの多数あるレイヤー構造に組み込める形に設計をすることをはじめ、実際の運用を想定したアニメーション付きせかえアイテムの制作から本番公開するまでのワークフローの整備なども含めて技術的に挑戦できたとても良い機会となったと思います。

詳しくは「ピグパーティ」で数百に及ぶFlash製のモーションデータをSpineに変換した話をご覧ください。

—最近だとサーバーサイドで扱う言語をTypeScriptに変更されましたね。

鬼塚：はい、そうですね。私たちは、クエスト、パーティ、コミュ、人狼ゲームなど、仕様が非常に複雑かつ開発や修正の難易度の高い実装が含まれるシステムを、迅速な開発サイクルで長期間にわたって運用し続けています。その結果、ソースコードが肥大化し、機能やコードの属人化、複雑化、およびそれに伴う不必要な調査やバグの対応が大きなボトルネックになっています。

開発言語のNode.js (JavaScript)には、型がありません。既存実装に依存しない開発の場合は、（賛否両論あると思いますが）型がないことで自由にスピード感をもって開発することができます。しかし、依存のある複雑な実装の場合、既存実装を調査する際にJSDocのドキュメントやコメントや関連実装を確認して把握していくのですが、テストが不十分なため、誤ったプロパティへのアクセスや代入、数値を入れるはずの変数に文字列やオブジェクトが入っていることがあり、最悪オブジェクトの生成過程からたどることになるため、実装調査だけで時間が掛かる状態でした。

これらの問題を解決し、エンジニアが本質的なビジネスロジックの構築に集中できるようにするために、TypeScriptを活用するようにしました。システム全体をTypeScriptに書き換えるのは大きなハードルがあり、事業優先度的にも大きな工数をかけて取り組むことができない状況であったため、TypeScriptの型を使ってオブジェクトやコードをドキュメント化し、ソースコードのうち重要な部分だけを集中的にTypeScript化しています。その結果、TypeScript化したコア部分の実装まで辿り着けばデータ構造が把握できるようになったので、開発効率やソースコードの読解速度が大幅に向上しました。現在もコア部分の新規実装にはTypeScriptを積極的に採用しています。

詳しくは100万行の大規模なJavaScript製システムをTypeScriptに移行するためにやったことをご覧ください。

—では最後に、今後ピグパーティが、技術的にどのような方向へと進化するのかを伺いたいと思います。

遠藤：ピグパーティは、ありがたいことにリリースから８周年を迎えることができていますし、サービスの規模自体も成長を続けています。技術面においては、リリース当時は最適だと考えられて実装されているものの中に、時間が経過したことやエンジニア組織自体の変化も加わったことで、レガシー化してしまっているものもいくつか出てきています。それらをまずは見直し、新しいことに挑戦しやすい環境に整備していくことがまずは大事かなと考えてます。

また、その先でいうと、サービス規模が拡大するにつれて、同時オンラインになっているユーザ数も増え続けてきており、そうすると、同じエリア空間で多人数が集まれる可能性が高くなってきます。時代とともに、よりハイエンドなスマホもどんどん出てきているため、今の実装を見直して、多人数が集まってもパフォーマンス的にも体験的にも質が落ちないように改善できるのではないか、そもそもエリア人数やエリア空間に課していた制約を今より上げても問題ない設計にし、たくさんいるからこそ楽しめるコンテンツの提供などができるのではないか、などなど、今のピグパーティ規模だからこそやる価値のあることが実現できたらいいなと考えています。 

鬼塚：遠藤さんがおっしゃった通り、ピグパーティはリリースから8年が経過し、サービス規模、ユーザー数共に大きく成長しました。この成長の傍ら、サーバー・クライアントの両方で、どの組織でも同じことが言えるとは思いますが、時間の経過や組織の変化によりレガシー化してしまった部分が見受けられます。そのため、これらの部分の見直しと新しい技術への挑戦が必要と考えています。

具体例の一つとして、アプリケーションコードをcallbackからPromiseへリファクタリングし、コードをより今の時代のデファクトスタンダードに近づけるような動きを推進しています。これにより、開発効率とコードの可読性が向上し、より良いサービスを提供し続けるための土台を強化していきます。

さらに、AIや機械学習の技術を活用することで、サービスの運用面での効率化を図りつつ、ユーザーがアプリの中で人間とAIの垣根を感じずに交流が可能になるような未来の実現も視野に入れて、様々な技術検証を行っています。これにより、将来的にはユーザー一人一人に合わせたサービス提供が可能となるかもしれません。

ピグパーティがこれまで成長し続けられたのは、ひとえにユーザーの皆様の支えがあったからです。これからも、皆様の期待に応えるべく、私たちは新たな技術への挑戦を続け、サービスの改善を進めてまいります。今後とも、何卒よろしくお願い申し上げます。