MUFG、スクウェア・エニックスなどが進める“着実な”システム基盤刷新：クラウドシフトで見据える未来

スクウェア・エニックスは、オンラインゲームのサブシステムをどう管理している？

　3社目の事例として登壇したのは、デジタルエンタテインメントのスクウェア・エニックスだ。同社は、ワークロードオーケストレーターである「Nomad」を社内システムに導入。オンラインゲームサブシステムとWebプラットフォームにおけるユースケースを2つ取り上げながら、社内での活用の様子を紹介した。

ユースケース 1. オンラインゲームのサブシステムが稼働するコンテナ管理

　同社内には、長年システムを運用するなかで構築されてきたDNS（Domain Name System）、メール、ログなどの細々としたサブシステムが多数存在する。これらは関係者のみアクセスが可能であるため小規模・低負荷ではあるものの、開発業務には必要不可欠だ。そのため、冗長性や可用性を確保する必要がある。また、オンプレミスで稼働させているためクラウドのように柔軟にスケールできず、「既存のリソースをいかに有効活用できるか」が課題となっていたと、情報システム部 オンラインサービス・インフラストラクチャー テクニカルスペシャリストの島田太郎氏は語る。

　Nomad導入前の運用環境については、物理サーバーからVMwareを経て、2024年からはコンテナで運用しているが、コンテナの配置や構成管理の労力が大きな課題となっていた。それを解決するためのコンテナ管理ツールには、以下のような要件が求められたという。

• 少人数で運用管理ができるシンプルなものであること
• 可用性を確保するために複数ノードへの自動的なコンテナ分散配置が可能であること
• 専任の作業員を必要としないようにコンテナ起動の設定ファイルが宣言的であること
• コンテナホスト障害時にはサービス自動復旧できるものであること

　一方で、オートスケーリングやRole-Based Access Control（RBAC）のような細かな権限管理については、前述のとおり低負荷なシステムだったため必要なかった。このような要件をすべて満たしたのが、Nomadだったというわけだ。導入時はリファレンスアーキテクチャに準拠し、Nomadサーバー3台、Nomadクライアント3台、Consulサーバー3台で構成した。

　導入効果としては、まず「運用効率の向上」が挙げられた。従来はサーバーに手動でログインしてから稼働状況を確認していたが、Nomad導入後はWeb UIで稼働ノードやコンテナを確認できるようになった。コンテナへのシェル接続もWeb UIから可能となり、ジョブファイルやDockerfileがGit管理されることで、設定確認も容易になったという。また、作業端末で本番相当の環境を再現できるようになり、事前確認が可能となった結果、設定変更作業時の精度が向上した。将来的には、サーバーログインが不要な運用体制を構築して、よりセキュアな環境の実現を目指すとしている。

　島田氏は、「Nomadは検証までのハードルが低い。ただし検証から本番運用までには、デフォルトの設定が非セキュアな部分もあるので注意が必要」と説明する。また、インターネット上には本運用に関する情報が少ないため、フルスクラッチで組み上げる必要があると指摘した。しかし、設定自体はシンプルであるため、公式ドキュメントを読めばほとんどの問題は解決できると補足した。

ユースケース 2. Webプラットフォームのコンテナ化にともなうNomadの導入

　続いて紹介されたのは、自社や親会社のWebサイト、各種ゲームのプロジェクトサイト、そしてこれらを更新する管理ツールなどをホスティングしているWebプラットフォームにNomadを導入したケースだ。この事例の裏側について、スクウェア・エニックス 情報システム部 オンラインサービス・インフラストラクチャー リードエンジニアの片柳勇人氏から詳細が語られた。

　このWebプラットフォームでは、サイト制作者がコンテンツをアップすると、インフラエンジニアがミドルウェアやOSでサイトごとの差異を吸収している。その際、サイトごとに投票や外部連携などの独自要件が発生するため、裏側で支えるエンジニアに負担がかかっていた。また、複数種類の仮想マシンをAnsibleで管理するレガシーな運用がなされていたほか、ミドルウェアやOSのアップデートでも労力がかかっており、効率化が求められていた。

　これらの課題に対し、「コンテナ化すればアップデートや管理・構築の課題が解決できる」と見込み、工数を減らすために軽量なオーケストレーションツールのNomadを導入することにしたという。

　構成のポイントは大きく3つに分けられる。1つ目は、CI/CD周辺の構成だ。コンテナのビルドからNomadへの展開をCI/CDでフロー化し、Nomad CLIをCI/CD Pipelineから実行、Nomad planのテストからデプロイまでの各種操作を実施している。NomadのデプロイはNomad Runで行い、基本的にはローリングアップデートを利用する。

　2つ目は、コンテナのオーケストレーションやサービスディスカバリーを実行するシステム構成について。サービスディスカバリーはHashiCorpのオープンソース「Consul」を利用し、KubernetesのPersistentVolume（永続ボリューム）に相当する機能はNomadで実装している。スケジューラー「Cron」の定期JobはNomadのスケジューラーに移植し、安定した稼働を実現しているとのことだ。

　3つ目のポイントは、インフラの構成だ。インフラに関しては、同社が従来活用していた既存のシステムを流用する形で運用されているという。

　「Nomad導入後は、運用や管理の工数は大幅に削減でき、CI/CDを整備することで、ビルド・テスト・デプロイを自動化できました。一方、NginxとApache連携やCI/CD連携の設計では苦労しました。『コンテナ化をスモールスタートで進めたい』などの要件にマッチすれば、Nomadは非常に軽量で便利です。シンプルゆえに運用しやすくトラブルも少なく、実際稼働してから半年経った現在、NomadとConsulで障害は発生していません」（片柳氏）

　将来的には、Nomadをステートレスな小規模ゲームサービスへの展開、大規模ゲームタイトルのサブシステム、オンプレミスとクラウドのハイブリッド化・マルチクラウド化などに活用することも検討しているそうだ。