AWS Summit Tokyo

ニンテンドーアカウント刷新プロジェクトの裏側　27カ月にわたる試行錯誤、キーパーソンが語る（1/2 ページ）

公開 2023年05月11日 10時00分

[ITmedia]

印刷する Googleで優先するソースとして追加

　「スプラトゥーン3」「大乱闘スマッシュブラザーズSP」など、Nintendo Switch向けゲームのプレイには欠かせないサービス「ニンテンドーアカウント」。2015年のリリース以降、164カ国、約2億9000万人（22年9月時点）のユーザーに展開する大規模サービスだ。

　しかしニンテンドーアカウントが現在の形になるまでには、その裏側で27カ月にわたる努力があった。実は2018年5月以降のタイミングで、ニンテンドーアカウントには予測できないアクセス集中や運用工程の増大といった問題に直面。システム改修を迫られていた。

　「リリース以降も継続して機能開発を進めることができ、順風満帆だと思っていたが、そう甘くなかった」──システム改修を手掛けたニンテンドーシステムズの川原貴裕さんは当時をこう振り返る。ニンテンドーアカウントのシステム刷新の裏側を、川原さんや同社の府川幸太郎さん、桑原健さんが、クラウドサービス「Amazon Web Services」の技術展示イベント「AWS Summit Tokyo」（幕張メッセ、4月20～21日開催）で語った。

当初からEC2活用も、ユーザー増で状況一変

　ニンテンドーアカウントのシステムは当初、インフラ面にAWSの仮想サーバ「Amazon EC2」を、アプリケーション面はPerlを活用した構成だった。当時はPerl向けのライブラリも多く、オンプレミスの運用経験がある人も多かったことから、開発スピードや柔軟性を確保しやすかったという。

　しかしサービスの発展や時間の経過に伴い環境が変化。連携するサービス数やアカウント数が増え、トラフィックが増加した。予測できないアクセス集中も増えたという。インフラの運用工数が増加したことで人材も不足。「Perlの求心力が下がった」（川原さん）として、アプリ面でも人材が足りない状態に陥ったという。

ニンテンドーアカウントのシステムが直面した課題

　「これら課題の積み重ねが改善されないまま悪化すると開発者の負担は上がり、安定してシステムを運用できなくなる。また既存システムの運用で手いっぱいになり、新機能の開発に割く時間がなくなることで、成長が止まる可能性があった」（川原さん）

立ち上がった「リノベ」計画　チームが目指した2つの「止めない」

　一連の事態を問題視した同社は、システムの“リノベーション”プロジェクトを発足。プロジェクトの条件は2つ。新機能の開発と並行して進めることと、サービスを止めずにシステムを改修することだ。

　「リノベーションを進める間、新規開発を止められれば、やりやすくなることは明らかだったが、サービスの成長は止めたくなかった。また、グローバルにサービスを提供している都合上、サービスを停止し、ユーザーに迷惑を掛けることは避けたかった」（川原さん）

当初のシステム構成

　リノベーションプロジェクトは大きく2フェーズに分けて進行することになった。まずはEC2ベースだったインフラをコンテナ実行環境「Amazon ECS on AWS Fargate」やAWSのマネージドサービスを活用したものに移行。そしてPerlで書かれたアプリケーションを、Javaへ書き換える計画だ。

　インフラの移行においては、まずサービス開発のチームとは別にリノベーションの専門チームを発足。同じチームが「システム改修と新機能の開発を並行して行うのは難しいと判断した」ことから新チームの立ち上げに至った。ただし、特定の人員しか知見を持たないシステムになることを防ぐとして、リノベーションチームは、サービスチームへの引継ぎ後の解散を前提とした一時的な組織とした。

　リノベーションチームが移行したのはアプリケーションの基盤や、データベース管理システムの基盤など。例えばアプリケーションの基盤はAmazon ECS on AWS Fargateに、EC2上に構築していたデータベース管理システムはAWSが提供する「Amazon Aurora」に切り替えた。

リノベーションに当たって利用したサービス

　独自ツールからの脱却も進めるとして、自社開発したアラート用ツールも、AWSの監視ツール「CloudWatch」や通知機能「Amazon SNS」などを活用したものに置き換えた。実際の移行はMySQLなどのミドルウェアから開始。次にアプリケーション、最後に残りという形で少しずつ進め、27カ月かけて完了させたという。

次ページへ「システム開発運用に終わりはない」　次なるチームのミッションは