こんにちは。サーバーエンジニアの佐藤です。
2022年6月16日、ゲームバックエンドを支えるノーメンテナンス運用という題目でサーバーエンジニア・インフラエンジニア向けの発表を行いました。
当日の放送内容は YouTube でご覧いただけます。
勉強会の内容
コロプラでは「ユーザが遊べないシステム停止をなるべく行わない」という「ノーメンテナンス運用」をポリシーとしています。
今回の勉強会では、そのノーメンテナンス運用を実現するための工夫に関して次の項目でお話させていただきました。
- オンラインでのサーバー切替事例紹介
- ノーメンテナンス運用実現のためのノウハウ
前半では、データベースを別のデータベースに切り替える方法とゲームの動いているバックエンドをクラウド間で切り替える方法 の2 点に関してメンテナンスなく実施する工夫と手順をご紹介しました。
後半では、ゲームの運用において必要となる機能リリースやデータの追加といった更新作業をメンテナンスなしで実現する方法、緊急的なメンテナンスの要因となる不具合の発生予防とその対処などについてお話させていただきました。
資料はこちらになります。
勉強会を終えて
オンラインでのサーバー切替事例紹介
レプリケーションのタイムラグで旧に書き込んだ直後に新にアクセスする場合の挙動についてご質問をいただきましたのでこちらで回答します。
基本的に、データが存在せずにデータベースからエラーを返す場合はクライアント側でリトライします。
ただし、サーバー側では DB replica にデータが存在しない場合に DB source に確認するという遅延を前提とした処理があり、 1 リクエスト内で参照している DB source はそのリクエストが終わるまで切り替わらない仕組みのため、エラーを極力抑えられる実装をしています。
レプリケーションのラグがあった場合に DB replica 側でデータの存在を 100% 保証しない楽観的な構成ですが、パフォーマンスとのトレードオフでこちらの方式を採用しており運用においてもデータが存在しない可能性を考慮した開発が行われています。
ノーメンテナンス運用実現のためのノウハウ
実務におけるリリース方式の選択
今回、３種類のリリース方式について説明させていただきました。
- アプリトリガー方式
- フラグトリガー方式
- データトリガー方式
アプリトリガー方式はアプリのリリースと同時に機能が解放されるものでした。メリットはクライアントが機能リリース前後の２状態の切り替えを実装する必要がないことです。ユースケースは、便利な機能やバグ修正、クライアント実装が複雑になるものです。
フラグトリガー方式は全ユーザ一斉に機能解放されるものでした。メリットはユーザ間で盛り上がっていただけることや解放タイミングの一致により不平等が起きないことです。
データトリガー方式はバージョン付きデータで解放する既存機構を利用するものでした。メリットは、サーバー、クライアントの両者が機能のリリースをコントロールするために処理を新規で実装する必要がないことです。また、特定バージョン以降でないと機能の処理に入ることがないため古いバージョンを意識する必要もありません。
実際の運用上では、データトリガー方式、フラグトリガー方式、アプリトリガー方式の順で使用することが多くなります。
データトリガー方式は、サーバー、クライアントの負荷も少なく、指定の時間に出せる方が運営の都合に合致するため、使えるのであれば積極的に使っていきたい選択肢になります。
データトリガー方式でリリースできない場合には、フラグトリガー方式を検討します。多くの場合、この段階でフラグトリガー方式になりますが、クライアントの実装が難しくリスクを伴う場合にはアプリトリガー方式になります。
これはよく発生する検討例ではありますが、機能によって事情は異なり、全てこのフローでリリース方式を選ぶわけではないため注意が必要です。
推奨アプデ、強制アプデによるバージョンコントロール
発表の中で、サーバーが複数バージョンのアプリに対応することについてお話させていただきました。
実際に複数のバージョンに対応しているのですが、全てのバージョンに対応しているわけではなく、最新バージョンに近い数種類のバージョンに対して対応するようになっています。
対象とするバージョンの範囲を絞るためには、推奨アップデートと強制アップデートと呼ばれる機能を使います。
推奨アップデートとは、指定バージョン以下のアプリを使っているユーザに、アップデートをしないと後にゲームが遊べなくなってしまう旨を表示する機能です。この推奨アップデートにより、新バージョンのアップデートへ誘導します。
強制アップデートとは、特定バージョン以下のアプリで遊べなくする機能です。こちらにより環境に特定バージョン以下のアプリが存在しない状態を作ります。
この２つの機能は無闇矢鱈に使ってしまいますと、ユーザがアプリを更新しないと遊べない状態が頻繁に発生してしまうため、バージョンごとのユーザ分布を見ながらスムーズに移行できるように注意して利用しています。
実際のツールを用いた設定に関してはこちらの記事をご確認ください。
質問の補足
「ノーメンテ運用を実現するために、設計や実装時に特に気をつけている点などありますか？」とご質問いただきました。
最もリスクが高いことがリリース方式の見誤りになります。担当者のサーバーエンジニアが「データリリース方式だからイベント直前までデプロイしなくて大丈夫」と思っていたところ、アプリの申請時に対応が本番に反映されていないといけないことが発覚するケース（実際はアプリリリース方式だった）といったことを運用をしていて何度も目にしてきました。
十数営業日の余裕があると思ったら、既にデットラインを過ぎているという状況ですので、詰んでいる局面になります（アプリの実装を伴う開発のデッドはアプリの申請時ですので、その認識のズレが原因でもあります）。
クライアント、サーバー間でリリース方式について同意を取り、実際にアプリとサーバーの取りうる状態の組み合わせを試し、問題がないことを早期に確認することが重要です。
また、「ノーメンテ運用の中での失敗はありましたでしょうか？もしあれば、そのときの対処法やその後の対策はどのようにしたか教えてほしいです」という質問もいただきました。
こちらもリリース方式の見誤りになります。
この場合にはリリースを遅らせるか、メンバーを加えてカバーしてどうにか間に合わせるといった選択を迫られます。
自身の担当しているプロジェクトでは、ミスの予防として、そのバージョンのアプリに入る機能を管理しているスプレッドシートにリリース方式の記載を行い、確認しています。かなり原始的なやり方ですが、ミスはかなり減っています。
ゲームにおいては、機能を作ってみた段階で仕様に欠陥が存在することが発覚するケースが多々存在します。何度も手を加えていった結果、当初想定していたリリース方式ではリリースできなくなっていることも珍しくありません。
リリース方式の正当性の論理的な確認、テストによる証明の両方を行う必要があります。
まとめ
詰まるところ、ノーメンテナンス運用における難しさは「状態と状態の組み合わせの増加」だと感じています。
これを説明するのに「データベースのテーブルにカラムを追加し、サーバーでそのカラムを使用する」といった対応におけるメンテナンス有り、無しでの作業について考えてみます。
メンテナンスを行う場合には、メンテナンスに入れた後にデータベースとサーバーの両方をアップデートすれば良いだけです。
この場合、サーバー、データベースともに更新前後の２状態になり、状態の組み合わせは「両方更新前」、「両方更新後」の２つになります。そして、テストすべき状態は「両方更新後」のみです。
メンテナンスが無い場合には、データベースにカラム追加などの更新をかけたあとで、サーバーに対して更新をかける必要があります。
この場合には、状態の組み合わせは「両方更新前」、「データベース更新後、サーバー更新前」、「両方更新後」の３つになります。つまり、メンテ無しの場合と比べて「データベース更新後、サーバー更新前」が増えており、この組み合わせを余分にテストする必要があります。
また、メンテ有りのアップデートの場合には、一足飛びで理想とする状態へ更新できます。しかし、メンテ無しの場合ではより細かくステップを踏まなくてはなくてはなりません。
簡単な例として、テーブルのカラム名を変更したいケースを考えましょう。この場合、「①変更後のカラム追加と既存カラムからのデータコピー」、「②サーバーの参照カラム変更」、「③変更前のカラム削除」の手順が必要となります。つまり、データベースの状態数が３つに増えてしまっています。
今回は簡単な例ですので、この程度のステップ数で済んでいますが、実際の運用における更新はより複雑で、目的とする理想形まで導く不具合を起こさないステップを考えるのは、さながら詰将棋のような難しい作業になります。
状態が増えれば、状態の組み合わせも増え、テストをしなくてはならないことも増えてしまいます。
今回は例としてサーバーとデータベースの組み合わせでお話させていただきましたが、アプリやインフラ、その組み合わせにおいても同じことが言えます。
これらを考慮し、コントロールすることがノーメンテナンス運用における難しさだと考えております。
最後に
始めに音声トラブルがあり、大変申し訳ございませんでした。
5回目の勉強会となり、多くの方々にご視聴いただき大変感謝しております。
今後も勉強会や技術ブログを通じて、エンジニアの方々に役立つコロプラの取り組みや技術情報を幅広く発信していきます。
次回はこちらの勉強会を計画しております。ご興味を持っていただけましたらご参加よろしくお願いいたします。
