Amazon Web Services ブログ

大規模台数のたまごっちへ AWS IoT Jobs で高速かつ高効率にファームウェアを配信する方法

1996 年の誕生から全世界で累計 9,100 万個以上が販売され、世代を超えて愛される携帯型育成玩具「たまごっち」シリーズ。そのシリーズ初の Wi-Fi 搭載機種『Tamagotchi Uni(たまごっちユニ)』が発売されます。Wi-Fi 搭載により、たまごっち単体で直接インターネットに接続できるようになり、世界中の個性的なたまごっちと出会えるようになりました。

本製品を開発・販売する 株式会社バンダイ は、世界中のたまごっちが交流するというコンセプトの実現に向けて AWS IoT を採用。AWS と共に構成の検討やプロトタイピングに取り組み、最終的に AWS IoT をフル活用したサーバーレス構成にすることで、サービスの迅速な立ち上げに成功されました。

本記事では、「たまごっち」シリーズの最新機種を AWS のサービスがどのように支えているのかについて、株式会社バンダイとクラウド開発パートナーである株式会社フェニシスにご紹介いただきます。特に、たまごっちのファームウェア配信のために採用した AWS IoT Jobs をお客様をお待たせせずにアップデート完了する必要がありました。そこで動的グループを活用しそのクエリを工夫することで、高速かつ効率良くジョブを配信できるようにされています。本記事ではその具体的な工夫と設計方法をご説明いただきます。

『Tamagotchi Uni』とは

株式会社バンダイは、『Tamagotchi Uni(たまごっちユニ)』を国内では 2023 年 6 月 8 日(木)に予約を開始し、2023 年 7 月 15 日(土)に世界同時発売します。

Tamagotchi Uni

たまごっちは 1996 年に発売した携帯型育成玩具で、誕生からこれまでに全世界累計 9,100 万個以上を販売しています(2023 年 3 月時点)。『Tamagotchi Uni』は世界中のたまごっちユーザーが同じ『Tamagotchi Uni』でお楽しみいだける、デザインや遊びの内容を統一した世界同一機種です。“自分が育てた自分だけのたまごっちで世界中のたまごっちファンとコミュニケーションをとれる世界をつくりたい”という思いから本商品を開発しました。

『Tamagotchi Uni』の進化ポイント

「たまごっち」史上初! Wi-Fi 搭載で世界中のユーザーが育てたたまごっちと出会える

たまごっちユーザーは『Tamagotchi Uni』に内蔵している Wi-Fi を使って、たまごっちたちのメタバース「Tamaverse(たまバース)」へおでかけし、世界中のユーザーが育てた、たまごっちに出会うことができます。また、『Tamagotchi Uni』は直接クラウドに繋がることで、常に新しいイベントやアイテムの配信コンテンツをダウンロードすることができるほか、世界中のたまごっちと競ったり、協力したりするイベントを世界同時に開催することが可能となりました。本機能は AWS IoT を活かして実現し、全世界に向けて信頼性の高いサービスを提供していきます。

Tamaverseたまごっちがクラウドに接続

本商品の世界観・商品 PV を公式 YouTube チャンネルで公開中です。
公式YouTubeチャンネル:https://www.youtube.com/@tamagotchi_official_jp

AWS IoT を中心とするサーバレス構成によるセキュアな IoT 化

『Tamagotchi Uni』を IoT 化するにあたり、以下の 3 つを重要な目標として設定しました。

  • 『Tamagotchi Uni』のセキュアな接続を保証できること
  • 全世界で、かつ 100 万台以上の接続のためのリソースのスケーリングや負荷分散ができること
  • 運用コストを最適化できること

この目標を達成するために、AWS IoT をフル活用したサーバーレス構成を構築しました。次の図は『Tamagotchi Uni』とクラウドアプリケーションのアーキテクチャ概要図です。

Tamagotchi Uni の AWS 構成

Tamagotchi Uni の AWS 構成

このセクションでは、構成の中で AWS サービスをどのように活用しているかを簡単に説明します。

AWS IoT Core

AWS IoT Core

AWS IoT Core は、何十億もの IoT 機器を接続し、何兆ものメッセージをサーバーを管理することなく、AWS のサービスに転送可能な IoT ユースケース向けのサービスです。

『Tamagotchi Uni』では、本体の認証、接続、メッセージングに使用しています。また AWS IoT Core の Device Shadow サービスを各『Tamagotchi Uni』本体のステート管理に使用し、『Tamagotchi Uni』は Shadow の delta をフラグとして、配布アイテムやコンテンツの取得を行います。これにより本体と AWS 間の効率的な通信が実現されています。

AWS IoT Device ManagementAWS IoT Device Management

AWS IoT Device Management は、IoT 機器を大規模に登録、監視およびリモート管理する際に役立ちます。AWS IoT Core と統合して、クラウド上で機器を簡単に接続および管理できます。

『Tamagotchi Uni』では、本体の供給量が増えるにつれてその管理が難しくなることが予想されました。AWS IoT Device Management を使用することで、大規模な『Tamagotchi Uni』に対して、フリートインデックス作成と各本体のステートに基づいた動的なグループを作成し、効率的に OTA(Over-the-Air)アップデートを行っています。これにより、大量の『Tamagotchi Uni』を迅速かつ効率的に管理できます。

FreeRTOS

FreeRTOS

FreeRTOS は、オープンソースのクラウド Ready なリアルタイム OS であり、高速で信頼性が高く、応答性の高いカーネルを提供します。開発者に幅広いソフトウェアライブラリを提供します。

AWS IoT に接続する『Tamagotchi Uni』側のソフトウェアは FreeRTOS 上で動作します。AWS との通信機能を本体側で実装する際に、必要なリソースやコード量の最小化のために使用しました。これにより効率的なシステムの開発が可能となりました。

AWS LambdaAWS Lambda

AWS Lambda は、サーバーレスでイベント駆動型のコンピューティングサービスであり、サーバーのプロビジョニングや管理をすることなくあらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。

『Tamagotchi Uni』では、IoT ルールエンジンから先の処理や、新規お知らせやアセットの登録時の処理に AWS Lambda を使用しています。

Amazon DynamoDB

Amazon DynamoDB

Amazon DynamoDB は、ハイパフォーマンスなアプリケーションをあらゆる規模で実行するために設計された、フルマネージドでサーバーレスの Key-Value NoSQL データベースです。

Amazon S3Amazon S3

Amazon S3 は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。

これらのデータストアは、それぞれ『Tamagotchi Uni』の各種リソースの管理に使用しています。

Amazon TimestreamAmazon Timestream

Amazon Timestream は、高速かつスケーラブルなサーバーレス時系列データベースサービスです。1 日あたり数兆件規模のイベントを最大 1,000 倍の速度でより簡単に保存および分析できます。

『Tamagotchi Uni』では、配布アイテムや追加コンテンツの取得などの履歴データの蓄積に使用します。

これらの AWS サービスを組み合わせることで、『Tamagotchi Uni』の開発、運用、管理における信頼性とコスト効率を高められました。

ファームウェア配信の実現手段とその課題

『Tamagotchi Uni』はリリース後も定期的な本体のファームウェア更新により、新しい遊びやコンテンツの追加を予定しています。それらのファームウェアの配信には、AWS IoT Jobs を使用しています。

AWS IoT Jobs(ジョブ)とは

AWS IoT Jobs

AWS IoT に接続された機器に対し、クラウドからファームウェアの更新や再起動などの作業を配信し監視できる機能です。個々の機器や機器群全体も配信管理可能です。配信の速度を制御 (例えば 1 秒毎に 10 の機器に配信) し、さらに各機器に配信されたジョブの状態をリアルタイムに確認できます。

全台への配信完了が長時間化

ジョブは簡単にセキュアなアップデート配信が出来るメリットがある反面、時間あたりに配信できるジョブ実行最大数のデフォルト値(1,000 台/分)では、大規模台数になる『Tamagotchi Uni』全台への配信開始から完了までに長時間を要することが判明しました。

これにより、お客様間に不公平感が生まれる可能性があります。「他のユーザーはアップデートが完了して新しいコンテンツで遊んでいるのに、自分の本体にはまだ配信されていない」という状況が長時間発生する可能性があります。お客様はすぐに追加コンテンツで遊びたいのに、アップデート配信待ちで長時間待たされると大きなストレスにつながってしまいます。

一方、1 分あたりに配信できるジョブ実行の最大数のクォータは調整可能な項目ですが、無制限に調整が出来るわけではありません。そのため、お客様全員に同時に配信開始することが不可能であると分かりました。

一度に全台へ配信する方針の見直し

そこでお客様を待たせることのないよう、まずファームウェア更新の流れを見直しました。

本体更新はお客様が本体更新に同意をしたら実行されます。人間が介在する操作によって実行される以上、全台が同時に実行することはありません。お客様のプレイ環境や時差によってある程度サーバー問い合わせのタイミングに時間差が生まれることを考慮し、全台に一度に配信する必要はないと考えました。

そこで、更新の問い合わせを実行したお客様から順に配信されるよう優先順位を設定する方針に切り替えました。更新の有無の問合せのあったお客様から順に迅速に配信を行うことで、お客様不満の軽減が期待できます。

動的グループを採用した高速かつ高効率なジョブ配信

上記の方針を技術的に実現するため、図のようにジョブ配信を連続ジョブとして作成し、ジョブのターゲットをモノではなく動的グループとしました。この場合、ジョブ作成後に動的グループに追加されたモノに対しては、追加された直後にジョブが配信されます。このため設定した条件に該当した機器から順に無駄なく高効率で、かつ高速にジョブ配信できます。

今回のファームウェア配信の仕組みと工夫

今回のファームウェア配信の仕組みと工夫

また動的グループとは、グループ作成時に AWS IoT に登録されたモノの検索条件を設定しておくことで、AWS IoT Device Management のフリートインデックスが条件に該当するモノを自動で検索し、モノのグループに動的に追加してくれる AWS IoT Device Management の 1 機能です。

今回は動的グループのクエリ条件を以下の 4 つに構成しました。

  1. shadow.reported のファームウェアバージョンが初期バージョン以上である
  2. shadow.reported のファームウェアバージョンが配信対象の最新バージョンではない
  3. shadow.desired のファームウェアバージョンが配信対象の最新バージョンである
  4. connectivity.timestamp が特定 UNIX エポックミリ秒より大きい

これら 4 つ全ての条件を AND しています。

接続中機器の検索

上記のクエリ条件の中でも注目すべきは、 4 つ目の機器の接続タイムスタンプ(connectivity.timestamp)を検索条件とすることです。これにより、接続実績がある機器のみをジョブのターゲットとすることができます。クエリでは接続状態(connectivity.connected:true)も設定可能ですが、接続状態を条件とすると『Tamagotchi Uni』のアップデート後の再起動により該当機器が動的グループから外れてしまい、ファームウェアイメージとジョブ情報の検証が出来なくなってしまいます。そのため今回は、接続状態ではなく接続されたタイミングを条件としました。

さらに、特定 UNIX エポックミリ秒には動的グループ作成タイミングの -1 時間を設定しています。ジョブ配信タイミングの少し前から接続している機器もターゲットとすることで、可能な限りリアルタイムで遊んでいただいているお客様に対しても、迅速な配信を目指しました。

これにより、アップデートの有無の問合せがあったお客様から順に動的グループに追加し、迅速にアップデートを配信することが出来ました。

ファームウェアバージョンを Device Shadow で管理

検索条件の 1~3 つ目では Device Shadow の情報を設定しています。

今回『Tamagotchi Uni』で工夫した仕組みとして、アップデートや追加コンテンツなど全てのアセットの更新フラグを Shadow で管理している点があります。ファームウェアバージョンも同様に Shadow で管理し、機器は Shadow に更新がある場合のみデータ取得することで、通信頻度の抑制を図っています。しかしこの仕組みには課題がありました。動的グループクエリの 1~3 にて Shadow の情報を検索条件にしており、アップデートを機器に通知するためには、各機器の Shadow を 1 つずつ更新する必要があります。しかし全台分の更新には長時間を要し、配信速度に影響を与えていました。

そのため以下の手順と構成により、目標の大規模台数の更新時間を大幅に短縮しました。

  1. 動的グループの作成実行後に動的グループの作成進行状態を監視する SQS キューを作成
  2. クエリ条件を更新した動的グループのリビルド進行状態をポーリング監視
  3. ターゲットのモノが全台メンバーとなり、リビルドの完了を検知すると、動的グループのメンバーとなったモノを一度に取得できる最大値の 250 台ずつ取り出し、Shadow の更新を依頼する SQS キューへメッセージを発行
  4. SQS キューへのメッセージ発行を検知したら、Shadow を更新する Lambda を並列で呼び出す

以上が、『Tamagotchi Uni』が採用しているアップデート配信の流れです。これにより、お客様からアップデートの問合せがあった順に効率的かつ迅速にアップデートを配信することで、ユーザー体験の向上ができました。

動作と性能の確認

最後に負荷試験として、『Tamagotchi Uni』と同様のアクセス挙動をする仮想機器を大量に作成し、上記のアップデートの動作と性能に問題がないことを検証しました。よって大規模なアクセスがあった場合においても安定したパフォーマンスを維持できることが期待できます。

まとめ

たまごっちシリーズ初の Wi-Fi 搭載機種『Tamagotchi Uni』は、たまごっちファンが性別や年齢を問わず、国境を超えて、つながりを感じることが出来る世界を実現しました。 本記事では、この『Tamagotchi Uni』がどのように AWS のサービスを活用し、安心して安全に繋がれる機能を実現したのかを詳しくご紹介しました。特にファームウェア配信のために採用した AWS IoT Jobs はお客様をお待たせせずに配信完了する必要があり、動的グループを活用しそのクエリを工夫することで、高速かつ効率良くジョブを配信できるようにしました。


著者

坂本 大祐坂本 大祐

株式会社バンダイ

グローバルトイ企画部 テクニカルデザインチーム

四柳 嘉之四柳 嘉之

株式会社フェニシス

開発グループ

飯塚 将太 飯塚 将太

アマゾン ウェブ サービス ジャパン合同会社

IoT Specialist Solutions Architect