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

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

[高橋睦美，＠IT]

　サーバの故障対応やバックアップからの復旧……そんなほそぼそとした日々の作業、いわゆる「トイル」に追われ、根本的な改善策について考える余裕を持てずにいるインフラエンジニアは少なくない。

　サイバーエージェントの子会社であるサムザップは、幾つかの課題を解決するためにサイバーエージェントグループのプライベートクラウドに構築していた環境をAmazon Web Services（AWS）に移行し、柔軟なリソース増減やデプロイの自動化などを進めている。同社SRE（Site Reliability Engineer：サイト信頼性エンジニア）でTech Leadを務める石原裕之氏と吉岡賢氏が、2019年6月に開催された「AWS Summit Tokyo 2019」のセッション「あるSREチームの挑戦 運用6年目の大規模ゲームをAWS移設後に安定運用するための技術と今後の展望」で、その狙いといきさつを紹介した。

SREチーム本来の仕事「システム品質向上」に専念する時間を取り戻したい

　サムザップでは、2013年4月から「戦国炎舞 -KIZNA」というオンラインゲームを配信している。提供開始から6年がたち、累計ダウンロード数は560万件を突破した人気ゲームで、1日に3回「合戦」と呼ばれるイベントがある。この時のアクセス数は、通常時の10〜20倍に上るという。

　以前はこの基盤を、サイバーエージェントグループが構築したプライベートクラウドで運用していた。だが、一部のゾーンで提供が終了することを機に移設を検討。併せて、旧環境で直面していた幾つかの課題解決を図るため、2019年2月にAWSへ移行した。

サムザップの石原裕之氏

　石原氏によると、課題は主に3つあった。

1. 肥大化したデータとログを扱う運用負荷が高い
2. イベントのピークに合わせた柔軟なサーバ増減ができない
3. 自動化しにくいシステム構成と環境になっている

　なぜサムザップは、さまざまなパブリッククラウドがある中でAWSを選択したのか。石原氏は「サイバーエージェントグループでの導入実績があったことと、フルマネージドリレーショナルデータベースサービスの『Amazon Aurora』（以下、Aurora）が魅力的だったためです。旧環境では多数のデータベースサーバを自前で運用していましたが、その運用に時間を取られてしまい、本来SREチームとして取り組むべきシステム品質を上げるための活動になかなか時間が取れなくなっていました」と振り返った。

　ではサムザップが実施したそれぞれの課題の解決方法を紹介する。

78台のMySQLサーバを約6時間でAuroraに移行、ログも移行し現場のエンジニアが調査できる環境に

　1つ目の課題は「肥大化したデータとログ」だ。「オンプレミスではディスク容量が足りなくなるたびにサーバを増設して最終的に78台のサーバが稼働していました。それだけの数のサーバが動いていれば、故障する確率も上がります。故障のたびに復旧作業が発生し、時間を取られていました」（石原氏）

　この課題の解決に役立ったのがクラウドへの移行とAuroraの活用だ。「Auroraのディスク容量は1インスタンス当たり最大64TBまで増やせるため、これまでのようなペースでサーバを追加する必要がなく、障害が発生しても自動的にフェイルオーバーします。データ管理の運用負荷軽減には最適だと考えました」（石原氏）

　負荷試験によって、既存の78台のサーバは約10クラスタ（マスター／スレーブ構成で20インスタンス）に集約できる見通しは立ったが、大きな課題があった。6年の間たまり続けた膨大なデータの移行方法だ。

　ここで課題解決に利用したのがデータ移行サービス「Amazon Database Migration Service」（DMS）だ。同氏らはまず、プライベートクラウドのMySQLサーバと同数のMySQLインスタンスをAWSに構築してデータを複製（レプリケーション）した。その後、AWSのMySQLインスタンスを「ソースデータベース」としてDMSがデータを読み取って集約、Auroraにロードした。DMSはプライベートクラウドから直接Auroraにデータを移行、集約することも可能だが、プライベートクラウドを利用している別のサービスへの影響を抑えるため、いったんAWSにインスタンスを立て、コピーする方法にした。作業は約6時間で完了したという。

　もう一つ肥大化していたのがログだ。中でも、障害時の調査に必要なアプリケーションログは、移行前は全てプライベートクラウドのオブジェクトストレージに保存していたが、ユーザーから問い合わせがあると、そのストレージからダウンロードして解凍する必要があったという。「ダウンロード、解凍、調査といった一連の作業に数十分、範囲によっては数時間から数日かかることもありました」（石原氏）

　AWS移行後はアプリケーションログを「Amazon S3」（以下、S3）に全て保存し、Amazon Athenaで調査できる仕組みを整えた。これにより、何か問題があればアプリケーション開発現場のエンジニアがSQLで手軽に、すぐ調査できるようになり、好評だという。「今後、エンジニア以外も使えるような仕組みを整えていきます」（石原氏）

サーバレスの活用でピークに合わせた柔軟なサーバ増減を実現

　2つ目の課題は「ピークに合わせた柔軟なサーバ増減」だ。前述の通り戦国炎舞では1日に3回、合戦というイベントがあり、アクセスはその前後に大きく跳ね上がる。こうした環境の場合、一般的に、ピーク時に合わせてサーバを増減させる必要がある。だが、従来の環境ではそれができず「常にピーク時間帯をさばけるだけのサーバ台数を立てていました」と石原氏は言う。

　これを解決するため、AWSに移行してからは、モニタリング用トリガー作成機能「Amazon CloudWatch Events」（以下、CloudWatch Events）とサーバレスワークフロー構築サービス「AWS Step Functions」（以下、Step Functions）、そしてサーバレスコンピューティングサービスの「AWS Lambda」（以下、Lambda）を利用した。

ピークに合わせたインスタンス増減

　CloudWatch Eventsでイベント開始の40分前にLambdaを実行するように設定。このLambdaはインスタンス調整用Step Functionsを呼び出す。時間になると、LambdaがStep Functionsを呼び出し、リソース調整の処理を開始する流れだ。まず、リソース状況を確認し、「現在稼働中のインスタンス数」と「必要なインスタンス数」を比較する。もし差があればAmazon EC2（以下、EC2）の「Auto Scalingグループ」にインスタンスを追加（インスタンスを増設）し、リソースを拡張。そしてイベント終了とともに追加したインスタンスを削除（ターミネート）する。

　単純にAuto Scalingのスケジューリング機能を利用するのではなく、いったんStep Functionsを呼び出している理由は、合戦以外にもクエストなど数種類のイベントがあり、それぞれ必要な台数や時間帯が異なっているため、時間帯が異なる場合は異なる処理を行うようにしているためだという。

　こうして合戦前後のアクセス変動に合わせて柔軟にサーバを増減できるようになった。さらに、プライベートクラウドで6年前から使い続けてきたWebサーバから、EC2の「C5インスタンス」に変えたことで性能も向上し、合戦時の平均レスポンスタイムが大きく改善するという効果も得られた。「Auto Scaling グループの設定で柔軟にインスタンスのタイプを変えられるのがAWSの良いところです」（石原氏）

　今後はさらなるコスト最適化に向け、スポットインスタンスの導入を検討している。現在、検証を進めている段階で、2019年7月には導入が完了する予定だ。「さらに50％ほど安くなる見込みです」（石原氏）