世界一のブロックチェーンゲーム『マイクリプトヒーローズ』を支える技術スタックとサーバ環境

日本発のRPGブロックチェーンゲーム『マイクリプトヒーローズ』

司会：ここまでで5社のピッチが終了しまして、残すところ、あと2社ですね。次は、 double jump.tokyo株式会社のエンジニアである満足さんにご登壇をいただきたいと思います。それでは、よろしくお願いします。

満足亮氏（以下、満足）：よろしくお願いします。さっそくですけど、ブロックチェーンを知っている方、手を挙げてください。

（会場挙手）

じゃあ、だいぶ飛ばしていきます。

我々は『マイクリプトヒーローズ』というゲームを作っております。「ゲームにかけた時間もお金も情熱も、あなたの資産となる世界」というキャッチフレーズでやっています。ブロックチェーンのEthereumを使っていまして、プラス、分散ストレージであるIPFSを利用して、ゲーム資産の非中央集権性を実現しています。

ただ、ブロックチェーンによくあるスケーラビリティやUXの課題に関しては、ゲームの機能としては、AWS上に従来どおりサーバで構築しております。

ゲーム画面としてはこんな感じですね。左から、バトルの画面であったり、マーケットの画面であったり、今出しているアセット（ゲーム内アイテムやキャラクターなどの資産）の図鑑ですね。

やっぱり「なぜブロックチェーンを使っているの？」という疑問があると思うんですけど、ブロックチェーンゲームにおいて、ゲーム資産の所有情報は、あくまでもユーザーのものです。つまり、自由に取引ができたり、ユーザー間の（アセットの）譲渡が可能です。

また、ゲームの枠と飛び越えて、我々が作っているアセットなんですけど、別に我々以外のところで使っていただいてもぜんぜん構わないという、ユーザーに対する期待があります。

また、開発者である我々の視点から見ると、認証であったり決済のプラットフォームが、Ethereum上のものを使うことによって、事実上ほぼ手数料なしで利用が可能になります。

具体的にどういう感じで作っているかというと、こういうかたちでEthereum上にゲーム資産の所有情報を持っていまして、ユーザーは自分の持っている端末の秘密鍵を用いてEthereumと通信していますし、我々のサーバともそのような認証情報を使ってアクセスしています。

世界一のブロックチェーンを支えるAWSのアーキテクチャ

具体的に、AWSの構成要素はこういう感じのグラフになります。ユーザーはCDNやNLBを通してWebサーバに接続して、リソースによってはS3やAuroraにデータを取りにいっています。我々のサーバとEthereum間のアクセスは、レガシーな感じですけど、バッチサーバでがんばっております。

使っている技術スタックとしては、フロントはSPAで、Nuxt.jsやweb3.js、gRPC-Webを採用しています。Webサーバに関しては、Nginxがかなりがんばっていまして、TLSのterminationをやったりだとか、gRPC-Webのproxyを行っていたり、L7のRoutingをガリガリやっています。

後ろ側には、gRPCで作っているものがCore-serviceとしてありまして、それ以外に認証やアップロードなど、マイクロサービス的に作ってあります。

このアーキテクチャを採用している理由としまして、ブロックチェーンとgRPCというエッジの利いた部分に飛び込むにあたり、それ以外は実績と信頼のあるAWSの機能を活用することで、新規領域に集中ができるようにと考えて、こういうアーキテクチャになっています。

また、SPAを採用していることによって、多様な処理を一元管理するために、Nginxをかなり最大活用しています。コンテナなどのバックエンドの通信に不安が出るようなものは採用せずに、同一インスタンスにsystemdで地味に立ち上げております。

Well Architectedなポイントとしては、課金はブロックチェーンで行っていますので、信頼性はありますし、セキュリティだと公開鍵の認証を使っています。サーバコストや運用上の理由になるんですけど、Auroraの自動拡張を非常に信頼して使っていますが、一部のデータはAuroraからS3にコピーすることで、コストの削減につながっているかなと思います。また、Protobufでフロントとバックエンドの開発コストも非常に小さくなっています。

パフォーマンス側はとくに推していまして、HTTP/2とgRPCで大量の並列アクセスを捌けたりだとか、データはJSONのままに保存していまして、インデックスのみカラムを作っているとか、JOINを使っていないとか、S3とLambdaを使って非同期処理を作ったりしています。

これがgRPS-Webの並列アクセスの様子です。

アクセスだったりDBのレイテンシーも安定して低くなっています。

このアーキテクチャによって、2ヶ月で構築ができています。今までの累計ユーザーだと5万人だったりとか、6,000DAU、3,000のオンチェーンのトランザクションが発行されていて、6ヶ月で1万2,000ETH超えの売上のある、世界一のブロックチェーンゲームになっています。

最後に、Managed Blockchainのやつが欲しいです。

司会者：はい、以上になります。満足さん、ありがとうございました。

（会場拍手）

ユーザーに安全かつ快適にゲームを楽しんでもらうための工夫

司会者：最後はご要望もいただき、ありがとうございます。1分間Q&Aになります。なにかコメントやご質問のある方、お願いします。

松本勇気氏（以下、松本）：EthereumとかIPFSって外部安定性にちょっと不安があるんですけど、ここらへんのread/writeなどはどういうふうに実装していますか？

満足：書き込み処理に関しては、もうユーザーから直接やらざるを得ないと思うんですけど、読み込み処理に関しては、かなりの部分proxyしてますし、IPFSのGETをできるようにはしていますが、事実上はS3からのみ取っています、という感じですね。あと、IPFSのアップロードに関しては、先ほどちょっと触れたように、Lambdaを使って非同期にやっています。

松本：あと、今サーバからトランザクションを発行していたじゃないですか。あそこはどういったトランザクションになっているんですか？

満足：例えば、ゲーム上で新しいアセットを購入できるようになっているので、その付与であったり、bitの情報などがメインです。

松本：そこの鍵の安全性とか、サービス内の工夫はありますか？

満足：それに関しては、スマートコントラクト上である程度絞っているので、なにか起きたらすぐに対応、という状況にはなっています。

松本：あと、鍵の安全性のほうは？

満足：鍵の安全性は、ある程度keystoreのようなかたちで、サーバで直に直しています。

竹内秀行氏（以下、竹内）：すいません。先ほどクライアントのアイコンアプリのほうにも鍵を持っていると言っておられましたが、あそこでトランザクションの署名をしているわけではないですよね。

満足：ユーザーが直接Ethereumにアクセスする場合の署名は、そこでやっています。

竹内：そこで署名して、そこから直接Ethereumのネットワークに。

満足：そうです。proxyはあくまでReadだけです。

竹内：わかりました。またあとでお話を。

満足：はい、よろしくお願いします。

司会者：では、満足さん、ありがとうございました。拍手をお願いいたします。

満足：ありがとうございました。

（会場拍手）

司会者：ありがとうございます。ちなみに、ブロックチェーン・イーサリアムの鍵管理をする場合、AWS CloudHSMというものが使えたりします。みなさん、よろしくお願いします。