にゃんこ大戦争は2012年にサービスを開始したスマートフォン向けゲームアプリケーションで、2025年11月に13周年を迎える。「2025年現在は約800種類の『キモかわにゃんこ』を育成、出撃させて敵を倒す駆け引きを楽しんでいただいています」とポノスでプロジェクトマネジャーを務める門脇幹宏氏は紹介する。

　2025年6月現在、ポノスは世界各国において全9言語で利用できるにゃんこ大戦争のアプリケーションをリリースしており、累計ダウンロード数は1億件を超えている。

　サービスの特徴の一つが、ユーザーの利用体験が中断するメンテナンス作業や強制アップデートを避けていることだ。「にゃんこ大戦争では強制アップデートを実行するスタイルを取っていません。古いバージョンのままでも基本的には遊んでいただけるよう、これまでの全バージョンを利用できるようにしています」。ポノスでサーバエンジニアチームのリーダーを務める白井 亨氏はそう話す。

　なぜメンテナンスをしないのか。「ポノスでは、『ユーザーが遊びたいと思ったときにいつでもプレイできる』ことが当たり前という文化が醸成されています」と門脇氏は話す。

　にゃんこ大戦争はスマートフォン向けアプリケーションの前に、2010年から携帯電話（いわゆる「ガラケー」）向けに、月額課金制のサービスでアプリケーションを提供しており、当時からメンテナンスなしで遊べるものだった。スマートフォン向けに提供するときも、それまでメンテナンスがないアプリケーションを遊んでいたユーザーも快適に遊べるようにすることを重視した。

ITインフラが複雑化

　ポノスでは2023年夏からにゃんこ大戦争のITインフラを移行するプロジェクトが立ち上がった。背景には、運用保守の作業を削減することを含め、ITインフラ全体を効率化する目標があった。当時の経緯について、「アプリケーション層のアップデートが一段落したタイミングで、手を出しにくいインフラに本腰を入れて検討しました」と白井氏は話す。「ゲーム開発者として、保守作業よりも新しいものを作る開発に時間を使いたいという思いがありました」（同氏）

　当時のにゃんこ大戦争のITインフラ構成は、基本的にはAWSで運用していた。運用時に特に問題となっていたのが、ログの保存場所だ。ログをAWSのマネージドリレーショナルデータベースサービス「Amazon Aurora」（以下、Aurora）またはストレージサービスの「Amazon Simple Storage Service」（Amazon S3。以下、S3）に保存していたが、「AuroraやS3にデータが分散していて頻繁に検索する必要があったり、データ分析用のデータがGoogleのデータウェアハウス『BigQuery』に保存されていたりするなど、複雑化していました」（白井氏）

　特にAuroraは、AWS都合のメンテナンスにより、年に数回のサービス停止（ダウンタイム）が避けられなかった。1回当たりのAuroraのダウンタイムは約数秒だったが、そのたびにAuroraが停止してもにゃんこ大戦争のサービスが終了しないようにする作業が発生していた。「年に数回とは言え、非常に手間と精神的負担が大きかった」と白井氏は明かす。

　一方、Google Cloudのフルマネージドリレーショナルデータベースサービス「Cloud Spanner」（以下、Spanner）はメンテナンスによるダウンタイムが発生しないという特徴を持つ。Spannerはいわゆる「NewSQL」のサービスで、リレーショナルデータベースが備える「ACID特性」（注）の保証と、RDBMS（リレーショナルデータベース管理システム）ではないDBMS（データベース管理システム）「NoSQL」のスケーラビリティ（拡張性）を両立している。

注：原子性（Atomicity）、一貫性（Consistency）独立性（Isolation）、永続性（Durability）

　ポノスではユーザー環境のアプリケーションが収集したデータや、AuroraのデータをBigQueryに保存して、時間帯ごとのユーザー数などを分析していた。データベースをAuroraからSpannerに移行することで、データが同じGoogle Cloud内に収まり、転送料金を削減できるメリットも見込んだ。

　同社はGoogleが提供する移行支援ワークショップ「Google Cloud Tech Acceleration Program」（TAP）を2023年夏から利用。各製品やサービスの特徴やITインフラ構成についてGoogleの担当者からアドバイスを受けつつ技術調査と実現性の検討を重ねた結果、2024年2月に移行プロジェクトが社内承認を得た。

　同社は無停止での移行作業のために「引っ越しサービス」と名付けたAPI（アプリケーションプログラミングインタフェース）を開発した。このAPIの主な動作は次の通りだ。

1. ユーザーからのアクセス
   • ユーザーがゲームをプレイすると、アプリケーションが新しいGoogle Cloud環境に通信リクエストを送る。
2. データの有無を確認
   • サーバは、そのユーザーのデータがGoogle Cloudに存在するかどうかを確認する。
3. データがない場合
   • データが存在しない場合（まだ移行されていないユーザーの場合）、サーバは「引っ越しサービス」のAPIを呼び出す。
4. 旧環境（AWS）からデータを取得
   • 引っ越しサービスが旧環境であるAWSのデータベースにアクセスし、該当ユーザーのデータを取得する。
5. 新環境（Google Cloud）へデータを格納
   • 取得したデータを新しいGoogle Cloud環境に格納し、ユーザーに返す。

　ポノスは引っ越しサービスを利用して、2024年7月に第1回の移行の本番作業を実施したが、これは失敗に終わってしまう。Spannerの設定に不備があったことに加えて、引っ越しサービスの通信経路設定に誤りがあり、意図しない経路へ通信が流れた。「テスト内容に考慮漏れがあった」（白井氏）。幸いにも異常は即座に見つかり、リリース後10分程度でロールバックしたことでサービスへの深刻な影響は免れた。

　「原因の究明や引っ越しサービスの改修自体は約3週間でできた」（白井氏）とのことだったが、にゃんこ大戦争のイベントや繁忙期などが重なり、失敗した際の影響を考慮してスケジュールは延期。2回目の移行作業を2025年1月に実施して、無事に移行した。

移行とIaC化で可視性も向上

　移行後の感想について、「まずは正常に動作して安心しました」と白井氏。「エンジニアチームで実際に触ってみたところ、コンソール画面のデザインなどユーザーインタフェース（UI）の統一感も感じられてGoogle Cloudは好印象でした」とポノスのサーバエンジニアである橋詰翔健氏は話す。

　Googleのフルマネージドのインメモリデータストアサービス「Cloud Memorystore for Redis」に「コンソールから直接データを閲覧する機能が欲しい」（橋詰氏）などの要望はあるものの、「どれもクリティカルな不満ではなく、基本的には満足しています」と白井氏は語る。

　コストについて、現在はAWS環境に一部のサービスや機能が残っているため、「想定よりは削減できなかったものの、同じGoogle Cloud内に各機能やサービスを配置して転送料金を抑えられたため、全体では以前より抑えられています」と白井氏は語る。今後、AWS環境のサービスや機能をGoogle Cloudに完全移行してさらなるコスト削減を計画している。

　特にSpannerへの移行により、当初の課題であったデータベースメンテナンス起因のサービス停止がなくなったため、運用の負荷を削減できている。

　AWSからGoogle Cloudへの移行プロジェクトと並行して、さまざまなサービスの処理をコードによって管理する「Infrastructure as Code」（IaC：コードによるインフラの構成管理）も実施。これによって、ITインフラ全体の可視性が高まり、機能が重複していたサービスの排除にもつながっている。

ITインフラの移行で得たもの

　門脇氏は今回の移行プロジェクトの成果を「『移行が完了した』という事実以上に、『将来、他のプラットフォームにも移れる状態になった』点が大きいです」と総括する。

　クラウドベンダーはさまざまなサービスを日々開発および提供している。だが、気になる機能があっても「稼働中のサービスを移行するリスク」や「技術的な難易度」などを理由に容易に移行できないのが実情だ。実際に、Spannerについて調査する中では「Spannerに興味はあるけどインフラ全体を移行できない、という状況の企業が珍しくなかった」と白井氏は明かす。

　「移行できない理由の大半は結局、技術的負債がITインフラに絡みついているか、『よく分からないけど動いている』ために誰も手を付けられない状態にあることです」と橋詰氏は指摘する。「今回の移行では、そうした状況を解消してITインフラ全体の可視性を高められたため、いつでも次の選択肢を採れるという自信につながりました」（橋詰氏）

　システムやアプリケーションを長年運用していれば、技術的負債や不透明な領域は積み重なっていくものだ。ポノスが今回の移行プロジェクトを通じて得た最大の成果は、個別の機能や運用効率の改善ではなくITインフラ全体の可視性を獲得し、いつでもまた移行できるという自信をチームが獲得したことだったようだ。