6年間の大規模オンラインゲーム運用によるトイルをなくしたい――AWS移行でサムザップのSREはNoOpsを実現できたのか：特集：百花繚乱。令和のクラウド移行（4）（2/2 ページ）

2013年から6年にわたって配信してきたオンラインゲーム「戦国炎舞 -KIZNA」では、それまで基盤としてきたプライベートクラウドで、一部ゾーンでのサービスが終了するのをきっかけにAWSに移行し、複数の課題を解決した。

[高橋睦美，＠IT]

6年間の運用でたまったトイルをなくし、NoOpsを実現させたい

　3つ目の課題が「自動化しにくいシステム構成と環境」だ。

サムザップの吉岡賢氏

　吉岡氏は自動化に向けた取り組みを次のように語った。「なぜ自動化したかったかというと、システム運用も6年目となると、人間がやるべきではない作業、いわゆる『トイル』がけっこうたまっていました。それをなくし、『NoOps』を実現するのが大きな目的でした」という。

　旧環境はGitHubといった外部サービスとの連携がしにくいクローズドな環境であり、その上「デプロイ対象管理」などに手作業が割り込んでいた。さらに分析基盤の運用も職人技で支えられている状況だった。このため吉岡氏らは「安定稼働のための改善に使う時間を確保する」目的から自動化に向けた取り組みを進めた。

　AWS移行と並行して「デプロイの自動化」「接続管理の自動化」「分析基盤運用の効率化」という3つの施策によってこの課題を解消したという。本稿は特にデプロイの自動化と分析基盤運用の効率化に注目する。

アセットバンドル、画像、ソースコードに関するデプロイ作業を自動化

デプロイの自動化といっても対象とすべきファイルには、さまざまな種類がある。サムザップが取り組んだのは「アセットバンドル」「画像」「アプリケーションのソースコード」の3種類のファイルだ。

• Jenkinsの導入でアセットバンドルの管理だけに注力できるように

　サムザップが提供する戦国炎舞のようなカード配信型ゲームは、一般的に「アセットバンドル」という仕組みを利用する。アプリケーションに全てのデータを組み込むのではなく、モデルやテクスチャといったデータを1つのまとまりにして配布する。このまとまりがアセットバンドルだ。こうすることで、後からでもカードの追加や拡張ができる。

　注意すべきは「どのバージョンにどのアセットバンドルが対応しているか」というバージョン管理だ。適切なバージョン管理ができないと「予定にないカードを配信してしまう」といった不具合が起こり得る。サムザップの旧環境は、このバージョン情報をソースコードに書いており「バージョンアップのたびにソースコードのデプロイも必要になっていました」（吉岡氏）という。

　そのためAWS移行をきっかけに、ビルド管理として「Jenkins」を導入。アセットバンドルをS3にアップロードすると、Jenkinsと連携したLambdaが、アセットバンドルとアプリケーションのバージョン情報をAuroraに自動的に追加する仕組みを構築した。

【補足：2019年7月17日14時15分　JenkinsはAWS移行前からビルド管理に利用しており、バージョン管理にもJenkinsを導入した形】

アセットバンドルのバージョン管理を自動化

　「アプリケーションは起動時に自動的にAPIサーバに問い合わせて必要なアセットバンドルバージョンを取りにいくため、特に何か作業する必要はありません。人間はアセットバンドルの管理だけすればいい状態になり、ソースコードとの依存から脱却できました」（吉岡氏）

【補足：2019年7月17日14時15分　「アプリケーションは起動時に自動的にAPIサーバに問い合わせて必要なアセットバンドルバージョンを取りにいく」の仕組み自体はアセットバンドルの機能となり、今回のAWS移行ではバージョン情報を自動的に書き込む処理を追加した】

• 画像パスのハッシュ化を自動化し、運用対象を削減

　カード配信型ゲームで重要なのは「画像パスのハッシュ化」だ。これはサーバ内の画像データをのぞき見されることを防ぐため。これまでサムザップでは、アプリケーションから画像へのリクエストがあるたびに「画像パスを非ハッシュ化（アンハッシュ）する」「スタティックサーバからファイルを探す」「画像パスをハッシュ化し配信する」という手順にしていた。だが、この仕組みは、画像のあるスタティックサーバが常に稼働している必要があり、サーバの保守が負担になっていた。

　この問題を解決するため、コンテンツ配信機能の「Amazon CloudFront」を導入した。画像関連情報をGitからプッシュすると、一時置き場であるS3（ソースコード保管用S3）にデータを配置する。次にLambdaがソース用S3の画像ファイルを読み込み、ハッシュ化して名前を書き換えた上で配信用S3に配置する仕組みを構築した。

ハッシュ、アンハッシュをするのではなく、ハッシュ化した画像パスをそのまま使える仕組みを構築

　「今までは人間が意識してデプロイを行い、スタティックサーバを運用保守していかなければならなかったのが、自動化することで管理対象が大幅に減り、運用しやすくなりました」（吉岡氏）

• 並列プル型でソースコードのデプロイ時間を最大で9分の1程度に短縮

　従来は6年前から続けてきた「手動でデプロイ対象を管理」というレガシーな方法でアプリケーションのソースコードを管理していた。配信も1台ずつ直列に実行していたため、台数が増加すればするほど実行時間も増えていた。

　これに対し、インスタンスをロールで管理し、タグを用いてデプロイ対象を自動判別する方式に変更。Gitから最新のソースコードをプルすると、ソースコード圧縮用S3にアップロードする。圧縮されたソースコードは各アプリケーションに一斉配信され、各サーバで解凍されると同時にリリースされる仕組みを構築した。

【補足：2019年7月17日14時15分　ソースコードの配布はデプロイサーバがソースコードを圧縮して配布用S3にアップロードする仕組み。圧縮用S3はない】

Gitからプルすれば全サーバに一斉配信する

　「Webサーバが合戦に合わせて増減しても対象管理の必要がない上、台数が増えても並列プル型で一斉に降りていくため、実行時間は1台分とほとんど変わらない。この結果、デプロイの実行時間は最大で9分の1程度に短縮できた」（吉岡氏）

サーバレスを活用し、数時間かけていた運用が15分程度で済むように

　これまで職人技に頼っていた分析基盤の運用も効率化した。従来は、数十億レコードもあるデータを毎日数時間かけてコピーしていた。さらにコピーの順序に分析処理が依存していたため「エラーがあればもう一度やり直す」状況だったという。

　この課題に対してCloudWatch Eventsとバッチ処理機能「AWS Batch」を活用し、さらにサーバレス構成を取り入れることで、フルコピーではなく必要なテーブルだけコピーできる仕組みにした。

必要なテーブルだけコピーすることで処理を効率化

　「一番大きいのは、ほとんどのシステムをサーバレスで構成したこと。管理運用コストがほとんどかからなくなったことも重要です。分析処理にまつわる複雑な処理や依存性を排除できたため、これまで数時間かけていた処理が15分程度で済むようになりました」（吉岡氏）

「エラーバジェット」を取り入れたリスク管理も視野に

　このようにサムザップでは、オンプレミスからAWSへの移設によって、平均レスポンス速度の向上やデータベースサーバの集約、Webサーバのコスト削減といった効果を得ることができた。随所で自動化を取り入れてトイルをつぶし、運用効率の改善も実現したという。

　今後はスポットインスタンスの本番導入に加え、DNS「Amazon Route 53」の本格導入や復旧高速化などに取り組み、より「落ちないシステム」を目指していくという。さらに今後の視野に入れているのが「エラーバジェット」の管理だ。エラーバジェットとは「ある程度のリスクを見越して、ITの運用改善に必要な予算（時間）を確保する」という考え方だ。どこまでのリスクを許容するかをあらかじめ決めることで、リスクを許容できる範囲内でSREチームとして取り組むべき「安定稼働のための改善に使う時間」を確保できる。

　「そもそも安定稼働というものをどのように捉え、どのように目標管理していけばいいのかは難しい課題です。ようやく、そのための情報を集める準備ができた段階なので、今後は指標を適切に立て、うまくいかなかった場合の対処を考えていきたい」（吉岡氏）

　AWS移設で、さまざまなサーバのお守りから解放されて本当に楽になった分、開発チームとの間のコミュニケーションが密になる効果も得られたというサムザップ。引き続き開発チームとSREが連携し、サービスのさらなる安定稼働に取り組んでいく。

この移行事例のポイント

• 膨大なデータをクラウド移行する上で、ネットワーク負荷やプライベートクラウドの他サービスへの影響が懸念された。しかし、一時インスタンスを中継してデータを移行することでこれを解決した。
• オンラインゲーム特有のアクセスピークに合わせたインスタンスを運用していたが、単純にAutoScalingのスケジューリング機能を利用するのではなく、各種イベントに合わせたインスタンス数の調査を自動化。不足分だけを増設する仕組みとして、無駄のないインスタンス増減を実現。
• これらの仕組みの多くをサーバレス環境で構築し、トイルを抑制。
• エラーバジェットの管理と合わせることで、安定運用を保証するだけではなく、「開発者やエンドユーザーの期待に迅速に応えられる仕組み」に向けた継続的改善も重視。

特集：百花繚乱。令和のクラウド移行〜事例で分かる移行の神髄〜

時は令和。クラウド移行は企業の“花”。雲の上で咲き乱れる花は何色か？どんな実を結ぶのか？　徒花としないためにすべきことは？　多数の事例取材から企業ごとの移行プロジェクトの特色、移行の普遍的なポイントを抽出します。

特集：百花繚乱。令和のクラウド移行〜事例で分かる移行の神髄〜