2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
Startup Architecture Of The Year 2019 #6-7 double jump.tokyo株式会社(全1記事)
提供:アマゾン ウェブ サービス ジャパン株式会社
リンクをコピー
記事をブックマーク
司会:ここまでで5社のピッチが終了しまして、残すところ、あと2社ですね。次は、 double jump.tokyo株式会社のエンジニアである満足さんにご登壇をいただきたいと思います。それでは、よろしくお願いします。
満足亮氏(以下、満足):よろしくお願いします。さっそくですけど、ブロックチェーンを知っている方、手を挙げてください。
(会場挙手)
じゃあ、だいぶ飛ばしていきます。
我々は『マイクリプトヒーローズ』というゲームを作っております。「ゲームにかけた時間もお金も情熱も、あなたの資産となる世界」というキャッチフレーズでやっています。ブロックチェーンのEthereumを使っていまして、プラス、分散ストレージであるIPFSを利用して、ゲーム資産の非中央集権性を実現しています。
ただ、ブロックチェーンによくあるスケーラビリティやUXの課題に関しては、ゲームの機能としては、AWS上に従来どおりサーバで構築しております。
ゲーム画面としてはこんな感じですね。左から、バトルの画面であったり、マーケットの画面であったり、今出しているアセット(ゲーム内アイテムやキャラクターなどの資産)の図鑑ですね。
やっぱり「なぜブロックチェーンを使っているの?」という疑問があると思うんですけど、ブロックチェーンゲームにおいて、ゲーム資産の所有情報は、あくまでもユーザーのものです。つまり、自由に取引ができたり、ユーザー間の(アセットの)譲渡が可能です。
また、ゲームの枠と飛び越えて、我々が作っているアセットなんですけど、別に我々以外のところで使っていただいてもぜんぜん構わないという、ユーザーに対する期待があります。
また、開発者である我々の視点から見ると、認証であったり決済のプラットフォームが、Ethereum上のものを使うことによって、事実上ほぼ手数料なしで利用が可能になります。
具体的にどういう感じで作っているかというと、こういうかたちでEthereum上にゲーム資産の所有情報を持っていまして、ユーザーは自分の持っている端末の秘密鍵を用いてEthereumと通信していますし、我々のサーバともそのような認証情報を使ってアクセスしています。
具体的に、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というものが使えたりします。みなさん、よろしくお願いします。
アマゾン ウェブ サービス ジャパン株式会社
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには