「膨大なサブシステム」と「数百のWebサイト」を少人数で運用できる"シンプルさ"が決め手

商用サービスを支えるサブシステムは、長年の運用のなかで細々としたものが増え続けてきました。DNSなら開発用、QA用、本番用、他にもメールやログ管理など多岐にわたります。関係者しかアクセスしないため小規模・低負荷であるものの、開発プロジェクト毎に準備する必要があるためシステム数が非常に多く、止まれば開発作業に影響が出るため冗長構成は欠かせません。稼働環境はオンプレミスで、当初は物理サーバー、後に仮想化へ移行するなど改善を続けてきましたが、2024年ごろからはOS資源の競合を解決すべくコンテナ化に着手。しかし依然としてコンテナの配置や構成管理で運用負荷が高く、設定の再現性が低かったため、コンテナ管理ツールの導入を検討することにしました。

同社のツール要件は「少人数で運用管理できるシンプルなもの」。複数ノードへ自動的にコンテナを分散配置して可用性を確保できること、コンテナ起動の設定ファイルを宣言的にするなど属人化を排除できること、コンテナホスト障害時にはサービスを自動復旧できることなどです。一方、オートスケーリングや負荷の動的リバランス、きめ細かな権限管理は不要としました。

スクウェア・エニックスの島田太郎氏は「チームの規模や管理対象を考えると、Kubernetesの多機能さは必要ありませんでした。それよりも学習コストが低く、少人数でも確実に運用を回せるシンプルさが私たちには合っていました。バイナリ1つ置けば動く軽快さは、オンプレミス環境を維持しつつモダナイズを進めたい私たちには大きな魅力でした」と言います。

比較検討の結果、要件をすべて満たしたのがHashiCorp Nomad（以下、Nomad）とHashiCorp Consul（以下、Consul）でした。導入時にはリファレンスアーキテクチャに準拠して、Nomadサーバー3台、Nomadクライアント3台以上、Consulサーバー3台で構成。島田氏は導入後の効果として「Nomadを導入してからは、物理故障が起きても、人間が気づく前にNomadが別ホストでコンテナを立ち上げてくれます。かつて（物理サーバー運用時）4時間かかっていた復旧が、今ではわずか数分。何よりも夜間や休日に連絡を待つ不安から解放された精神的な安心感が大きいです」と語ります。

小規模から始められる「Nomad」をコンテナ化のファーストステップに

2つのユースケースはどちらもNomadとConsulを採用することで運用効率を向上させています。特に、サブシステム群では障害時の自動復旧で可用性や信頼性、Webサイト群ではフロントエンド連携の自動化により生産性や俊敏性が改善されたといいます。今後はこのNomad基盤を、オンプレミスのみならずAWSやGoogle Cloudといったクラウド環境への展開にも活用していく方針です。

片柳氏は「NomadはKubernetesの下位互換ではなく、思想が異なるオーケストレーターです。Kubernetes未満、Docker Compose以上の領域にフィットするのが本質であり、適材適所で選ぶのが大事です」と強調します。

島田氏は「Nomadは、コンテナ化の“ファーストステップ”として非常に適したツールだと思います。コンテナを直接コマンドで立ち上げているような段階から、一歩進んでオーケストレーションを取り入れてみたいというチームにとって、導入コストも学習コストも低いNomadは有力な選択肢になります。小規模から始めて、少人数で確実に運用を回していきたい現場には、特にお勧めしたいですね」と締めくくります。