[レポート]ニンテンドーアカウント リノベーションプロジェクト　CUS-20 #AWSSummit

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

2023年4月20日〜21日に開催されているAWS Summit Tokyo 2023、皆さん参加してますか？

今回はそんな4年ぶりに開催されている最高のオフラインイベント、AWS Summit Tokyo 2023のセッションレポートを書いてみました。

さて皆さん、好きなゲームハードは何ですか？ゲームボーイ？ゲームボーイアドバンス？ゲームキューブ？

セッション概要

ニンテンドーアカウント リノベーションプロジェクト

ニンテンドーアカウントは 2015 年のリリース当初は Amazon EC2 を中心としたインフラ構成を採用していましたが、システム規模の拡大や時間の経過に伴い、徐々にシステムの継続性にリスクが生じるようになってきたため、リノベーション(システムの大規模な改修)を実施しました。
リノベーションではアプリケーションの実行基盤を Amazon EC2 から ECS on Fargate へ移行しつつミドルウェアについてもマネージドサービスを積極活用する方針で進めました。今回の発表では具体的にどのようにリノベーションを進めたのかをご紹介します。

登壇者

ニンテンドーシステムズ株式会社

ニンテンドーアカウント
府川 幸太郎 氏
川原 貴裕 氏
桑原 健 氏

レポート3行まとめ

• ニンテンドーアカウントはEC2を中心とした環境で構築され、2015年にサービス開始した
• 機能追加を続けていくにつれ、だんだん運用や管理が辛くなってきた
• 一時的専門の移行チームを立ち上げ、システム無停止&新機能開発は継続でECS on Fargateやその他マネージドなAWSサービスに環境を置き換えた

レポート

セッション前に用事があったため、セッション開始前3分前ぐらいに会場に着くと、なんと既に立ち見でいっぱい。。。

この時点で任天堂さんの人気ぶりが伝わりますね。熱気が違います。

アジェンダはこんな感じ↓でした。

• ニンテンドーシステムズ株式会社の紹介
• ニンテンドーアカウントの紹介
• リノベーションプロジェクトを発足した理由
• リノベーションプロジェクトの詳細
• まとめと展望

ニンテンドーシステムズ株式会社の紹介

ニンテンドーシステムズとは今回セッション登壇してくださった方々の会社で、任天堂とDeNAの合弁会社だそうです。

上記会社の設立自体は2023年ですが、もともと任天堂さんとDeNAさんは2015年に業務提携して「ニンテンドーアカウント」のバックエンド開発や運用を行っていたそう。

主な業務内容は「Nintendo Switch Online」や「どうぶつの森 ポケットキャンプ」などの任天堂のネットワークサービス全般の開発・運用だそうです。

ニンテンドーアカウントの紹介

そもそも皆さんニンテンドーアカウントというものをご存知でしょうか。

ニンテンドーアカウントとは任天堂のサービスを利用するための共通の認証・認可基盤です。スマホやPC、Switchから共通で利用することが可能です。

また、ニンテンドーアカウントに関する数字としては下記のようなものがあります。

• リリース
  • 2015年
• 対象の国・地域
  • 164
• アカウント数
  • 2.9億（2022年9月時点）

はい、めちゃくちゃ大規模なサービスですね。これがリノベーションプロジェクト発足の理由等に繋がります。。。

リノベーションプロジェクトを発足した理由

そもそも何故リノベーションプロジェクトが必要になったのでしょうか。

なんとこのニンテンドーアカウント、インフラ部分はAmazon EC2を中心に組まれていたそうです。

アプリケーションサーバーもEC2、DBもEC2、メール通知機能もEC2。。。

開発スピード（開発メンバーのスキル、ツールの存在）やコスト、柔軟性などの観点から、またリスクを下げて確実にリリースすることを重視してこのような構成に決まったそうです。ちなみにアプリケーションの開発言語はPerl。

そしてニンテンドーアカウントは2015年12月、この世に産声を上げます。

そして順調なリリースとともに成長を重ね、様々な機能の追加、多くの地域、ユーザーをサポートしていきます。（Switchに対応したのは2017年で、それより早い2016年にスマホゲームのスーパーマリオランでニンテンドーアカウントは使われたそうです。懐かしい。）

感のいい皆さんはもう嫌な予感がしてきましたね。そうです、次第に開発者は次のような課題にぶち当たります。

• 増え続けるトラフィック
• 予測できないスパイク
• 増大する運用工数
• IaaS熟練者不足
• 引き継がれないノウハウ
• Perlの求心力低下

辛いですね。。。サービスの成長にインフラが耐えられなくなってしまったのです。

そうです、これがリノベーションプロジェクト発足の理由です。

リノベーションプロジェクトの詳細

ということでニンテンドーアカウント リノベーションプロジェクトが発足します。

リノベーションの方針は下記

• インフラ
  • EC2→ECS on Fargateなどに置き換え
• アプリケーション
  • Perl→Javaで書き換え

さらに開発者の方々は下記のような目標を立てました。

• 継続性を高める
  • オープンな技術の採用による属人化の低下
  • 運用体制を考慮したIaCの構築
• 新規開発を継続する
  • 開発チームとリノベーションチームの分離
• 無停止で乗り換える
  • 各アプリケーションを段階的に移行

上述の通り、ニンテンドーアカウントは非常に多くのユーザーに利用される大規模サービスです。

もちろんサービスを停止することは出来ません。新規開発を継続するというのには私も驚きましたが、確かに元々リリース予定だった機能を延期し続けることは難しいですね。

※今回のセッションではインフラ部分のみの説明がありました。

リノベーションプロジェクトの体制

まずは体制から。

元々ニンテンドーアカウントのチームは各機能を開発する複数のサービスチームとインフラチームから成りました。

そこに新たに発足したのがリノベーションチームです。サービス開発は継続するため、各サービスチームとは別のチームが発足しました。

ここで私は面白いと思ったのが、このリノベーションチームが一時的なチームだということです。

ニンテンドーシステムズでは移行後の環境がリノベーションチームに属人化しないようにするために、このリノベーションチームを移行後解散する一時的な立ち位置のチームとしたのです。

リノベーションにて変化したもの

主にインフラ部分では以下のような移行を行ったそうです。

• アプリケーション基盤
  • 旧: Amazon EC2
  • 新: Amazon ECS on AWS Fargate
• データベース
  • 旧: Amazon EC2（MySQL）
  • 新: Amazon Aurora
• メール送信
  • 旧: Amazon EC2（Postfix）
  • 新: Amazon SES
• キューイングサービス
  • 旧: Amazon EC2（Q4M on MySQL）
  • 新: Amazon SQS

良い感じにコンテナ化&マネージド化出来ていますね。

また、下記については独自ツールを脱却してAWSサービスに置き換えたそうです。

• クレデンシャル管理
  • 移行後: AWS Secrets Manager
• ミドルウェア設定管理
  • 移行後: ECS Task, Amazon S3
• システムアラート
  • 移行後: Amazon CloudWatch, Amazon SNS

リノベーションの順序

今回の目標（マスト）はシステムの無停止です。

そのため、まずはSQSやDB系を置き換えたそうです。そして新旧環境を用意します。

その後、遂にFargateへの移行です。EC2→Fargateへの移行は、流入するトラフィックを1%→3％→5%のように本当に少しずつ段階的に切り替えていったそうです。

そして遂に無停止での移行に成功！！

その他

また、今回リノベーションしたのはインフラ環境の構成だけではありません。

ニンテンドーアカウントの環境は本番環境や各機能の開発環境など約20種類ほど存在し、更に必要なスペックが環境ごとに異なるそう。

しかもニンテンドーアカウントのサービス（機能）は全部で約10種類。。。

単純計算で20*10。。。あまり想像したくないですね。。私の頭の中ではウォーズマンが回転して謎計算を行っていました。

そこで開発者の方々はIaCの導入を検討し、結果的にAWS CDKを導入しました。Terraformなども検討したそうですが、下記を考慮しCDKに決めたそうです。

• 共通化・個別化のハンドリングの自由度
• テストコードで設定編集を安全に適用
• 全てのスタックでスナップショットテストを実行し、不要な設定変更を監視

また、CDKの導入にあたっては以下を意識したそうです。

• IAM Roleの厳密な管理
  • CDKで勝手に作られたIAM Roleを使用しないように、使用するIAM RoleはCDK外で作成
  • CDK側では作成したIAM Roleを指定して利用
• CDKの機能不足
  • CDKに欲しい機能が無かった場合、CDKのGitHubリポジトリにissueを立てたり修正することでコントリビュート
• 体制に合わせたCDKの分割
  • サービス全体のリソースを扱うCDK、各サービス用のCDK、というようにCDKを分割
• Fargateの管理
  • デプロイにはAWS CodeDeployを活用しており、デプロイの度に微妙な差分が出て困っていた。
  • そのため、Fargateはカヤック社のOSSであるecspressoで管理

また、今後サービスチームなどに環境を引き継ぐため、ナレッジギャップを埋めるための移行に関するチュートリアルドキュメントの整備も行なったそうです。最高ですね。

更にAWSから勉強会を実施してもらい、その録画を社内で誰でも見れるようにしたとか。

以上、試行錯誤を重ねながらも27ヶ月で無事にサービスの継続性を向上させることが出来たそうです。

まとめと展望

まとめは以下の通り

• ニンテンドーアカウントの継続性向上のため、リノベーション（大規模な改修）を実施
• インフラ面ではAmazon ECS on AWS Fargateへの移行を中心としたマネージドサービスを積極活用する方針とした
• 各種技術を比較検討した上で、試行錯誤を重ねながら進めることで運用体制も含めて継続性がある構成となった

今後やりたいこととしては下記があるそうです。

• データベースの運用改善
  • シャードが多く複雑
• アプリケーションのリノベーションは継続中
• システムの開発・運用に終わりはない。新しい技術の登場や環境の変化に合わせて柔軟に対応する

最後に（感想）

いかがだったでしょうか。

正直タイトルから既に面白そうなオーラが出まくっていた本セッションでしたが、個人的にはそのハードルを超えてきた非常に良いセッションだったと思います。

自分の業務と重なるところも多く、特に「属人化を防ぐために移行を行うのは一時的なチームとする」というコンセプトが非常に刺さりました。

本記事がどなたかのお役に立てれば幸いです。

以上、べこみんでした。