はじめに

近年のサービス・アプリケーションはネットワーク接続が必須となっており、ローンチして開発終了・・・なんてことはなく、ローンチ後も改修しながらサービスを続けていくスタイルがほとんどではないでしょうか。

弊社の主要業務であるゲームサーバーもご多分に漏れず、ローンチ後のシステムアップデートに追われる日々が続いています。

ローンチ後のシステムアップデートにおいて重要となるのが「メンテナンス」機能です。
主に機能追加や修正の際に、データの一貫性を保つために一時的にユーザーのサービス利用を見合わせていただき、安全にシステムアップデートを行う・・・ソーシャルゲームではお馴染みの機能になります。

サービス形態で動作は変わってきますが、

１．Webサービス
２．クライアント・サーバーアプリケーション

この２つのサービス形態を例に「メンテナンス」機能について解説したいと思います。

Webサービスの場合

Webサービスの場合、コンテンツをサーバーが管理しているのでメンテナンスページの表示内容もサーバーから返却する必要があります。
その為、アプリケーションサーバーとは別に、メンテナンスページを公開するメンテナンスサーバーを用意し、作業中はロードバランサーで接続を切り替える仕組みが利用されます。

メンテナンスの表示が静的なコンテンツであればメンテナンスサーバーは用意せず、CDNに固定ファイルを配置する手法もあります。

※
Webサービスであっても動的なコンテンツの場合、後述するクライアント・サーバーアプリケーションの仕組みを利用する場合もあります。

Webサービスの場合

クライアント・サーバーアプリケーションの場合

クライアント・サーバーアプリケーションの場合、サーバは運用状態に応じて「サービス中」「メンテナンス中」などの運用状況を返却し、それを受け取ったクライアントアプリが適宜画面表示や、提供機能の制限などを行います。

■クライアントアプリケーションにメンテナンス中を知らせる方法
サービス中・メンテナンス中などの運用状況を提供する方法としては以下のような手段があります

（１）運用状況APIによって返戻する　または　運用状況ファイルによって共有する
クライアントアプリケーションがセッション開始時など必ず最初に参照するファイルもしくはAPIに運用状況の情報を含める方法です。しかし、多くの場合、この手段は都度のサービスの開始時にしかアクセス制限をかけられないのでユーザーがすり抜けてきてしまう可能性があります

（２）各APIの実行結果によって返却する
既にセッションを開始して、サービスを利用中のユーザにおいても、メンテナンスの開始によってサービスからの追い出し・機能の利用制限をする必要があります。各APIを普段通りクライアントアプリケーションが叩きに来てしまった場合、そのAPIが「メンテナンスによって利用できなくなった」旨をアプリに返戻します

■APIがメンテナンス状態を知る手段
クライアントとサーバの連携はAPIを叩くことによってなされますが、サーバ上のAPIを提供しているサーバーアプリケーションはどうやって運用状況を共有しているのでしょうか？サービスとして共通の情報であるので、こうした情報はDBに格納しているのですが、いちいちRDBMSなどに毎回問い合わせてしまうと、今度はDBサーバの負荷となってしまうため、オンメモリ運用されているKVSなどに格納し、各サーバーアプリケーションから参照する構成にしています。

クライアント・サーバーアプリケーションの場合

最後に

以上、駆け足で「メンテナンス」機能を見てきましたが、
これらのパターンを組み合わせることでさまざまな形態のサービスに合った「メンテナンス」機能を構築しています。

「メンテナンス」機能は売上に直結した機能ではないので、「メンテにさえ入れられれば良い」と企画時には思われがちですが、後にこんなメンテモードは無いのか？と議論になることもあります。
たとえば、ソーシャルゲームでは「ガチャだけをメンテしたい」「有償通貨関連機能だけをメンテしたい」などのニーズが発生することも。

実際にはサービス固有の対応も必要になりますので、各種システム運用経験豊富な弊社までお気軽にご相談ください。