taki

剣と魔法のログレスにおけるバックアップのお話


ご無沙汰しております、ソフトウェアエンジニアの滝です。
今回は、Webブラウザ版 『剣と魔法のログレス』 (以下ログレス)のデータバックアップのお話です。

1日あたり数GBという膨大なデータが出力されるため、どのようにしてバックアップを取りどのように保管しているかについてお話したいと思います。

何のバックアップを取っているか?

ログレスでは、お客様のサポートや動向調査のために、行動履歴データが含まれるログデータやデータベースのバックアップを行っています。

バックアップはいつとっているのか?

データベースは毎朝定期的にバックアップを出力しています。
所要時間は1時間程度ですが、1日につき数GBのダンプデータが出力されます。
ログデータは、ゲームサーバーが出力したものを取得します。
これらのバックアップファイルは、社内のログ管理サーバーにキャッシュされ、定期的に圧縮作業を行っています。

バックアップデータはどのように保管されているのか?

ログレスでは月に一度、LTO(磁気テープ)にバックアップデータを書き込みます。
バックアップするデータは毎月cronで月初に圧縮され、一時的に別のディスクスペースに置かれます。
バックアップが完了すればメールが届くので、内容を確認してLTOに書き込みます。
数年前のプロジェクトでは、当時DVD-Rを使ったバックアップを行っていましたが、技術が進歩し記録メディアの大容量化進んで単価が安くなったため
現在そのプロジェクトでは、ブルーレイディスクでのバックアップを取っています。
ログレスも2016年5月まではブルーレイディスクへバックアップをしておりました。
しかし、ログレスのバックアップデータは圧縮しても1月あたり約160GBありますので、ブルーレイディスクを複数枚に渡って書き込む必要があり、それらの作業を自動化するには難があったため、LTO化することになりました。

終わりに

簡単ではございますが、ログレスのバックアップのことについてお話させていただきました。
オンラインゲームを運営する上では、あまり表の話に出ないバックアップですが
バックアップは、データ復旧などのもしものことがあった時だけでなく
様々な調査や分析にも使われる大切なデータです。

今回は、現場の裏側のそのまた裏の話ということで、以上バックアップのお話でした。


菅野 明洋

まべ☆てっく vol.1に登壇してきました!


はじめに

初めまして。
大阪スタジオ インフラチームの菅野明洋です。
業務では、大阪スタジオのサービスインフラを担当させていただいております。

今回は、2016年9月8日 木曜日の東京にて開催された株式会社マーベラス様主催の「まべ☆てっく vol.1」にて、スピーカーとして登壇させていただきましたので、レポートとしてまとめました。

まべ☆てっくとは

株式会社マーベラス様が主催する勉強会です。
今後もゲームに関わらず色々な題材を取り扱った技術系の勉強会を開催していくそうです。

今回発表させていただいた内容について

発表資料は以下のとおりになります。


本発表は、昔、私が開発業務を行っていた際に、DB周辺の品質向上や機械的な設計レビューの省力化を行う目的で実装した物を成果物として発表させていただきました。

内部処理の話をすると時間オーバーする見積もりだったので、内部の話は入っていません。

発表内容は下記のとおりになります。

  1. どんなツールか?
    1. ツールコンセプト
    2. 実行環境
  2.  ツールが出来るまでの流れ
    1. その時起きた問題
  3. 考えた解決策
  4. 実装後の成果
  5. 将来の実装予定(願望)

参加してみて

超豪華な登壇者に囲まれながら、初めて勉強会で発表しましたので、とても緊張しました。

今回の勉強会はゲーム業界の人が少なかったので、もうちょっとゲーム開発に関わっていた時の内容を含めて背景を説明したほうが、参加者の反応が良くなったのでは無いのかな?と思いました。

次回の登壇では、その辺りも注意しようと思います。

最後に

主催者の皆様のご厚意で、とても貴重な経験をさせていただくことができました。
関係者の皆様、ありがとうございました。

次回以降も何かご協力できることがありましたら、お手伝いさせて頂きたいと思います。


MySQLからBigQueryへのデータロード


はじめまして、エンジニアの古堀です。

Aimingではログの分析ツールとしてGoogleのBigQueryを利用しています。
ゲームプレイのログを集計、分析して機能開発、改善の指針として活用しています。
実際に運用に乗せてみるとログだけでは情報が足りず、ユーザー情報やマスターデータなども必要であると気付きました。そこでMySQLのデータをBigQueryに反映させる試みに取り組んだので紹介したいと思います。

BigQueryの特長と言えば以下の2点ですが、実際に使用してみるとGoogleアカウントでの認証や権限設定なども便利だと感じますね。

  • クエリーの処理速度が速い(数十億件のテーブルでも数十秒で結果が返ってくる)
  • 費用が安い

Embulkの採用

MySQLのデータをBigQueryに反映するツールとして Embulk を利用しています。
以下の理由からEmbulkを採用しましたが、最新技術を使ってみて活用事例を増やしてみたいという個人的欲求もありました。

  • Java実装なのでどの環境でも動作する
  • 設定ファイルを追加するだけで動かせる
  • 社内の他のプロジェクトで動作検証済だった
  • 新しいツールだが今後の機能拡張に期待ができそう

事前準備

1. Embulkのインストール
2. 対象テーブル毎にBigQueryのスキーマ定義を作成する
3. 対象テーブル毎にEmbulkの設定ファイルを作成する

処理時間の都合で全テーブルではなく、20テーブルほどに対象を絞っています。
2、3のステップは対象テーブルが増える毎に作業が発生するのが難点です。
あとは設定ファイル毎(テーブル毎)にEmbulkのプロセスを起動しなければならず、テーブル数が増えてくると面倒になってきます。
そこで設定ファイル作成、Embulkの起動を簡単にするためのツールを作成して設定の手間を軽減しています。

実行

実際に動かしてみるとすんなり処理が完了して感動しました!Embulkは導入から実行までの敷居が低くて良いですね。ただ、オーバーヘッドが大きく、テーブルサイズによらず1テーブルあたり処理時間が1分ほどかかりました。レコード件数が2000万件を超えるとIOトラブルが起きやすいですね。

困ったこと、ハマったこと

以下の問題に直面しましたが1はMySQLのテーブル定義からBigQueryのスキーマを作成するツール、2・3はMySQLからデータをロードするSQLの生成ツールを作成して解決しました。

1.スキーマ変換

MySQLのカラムの型定義とBigQueryの型定義が異なるので互換性のある型を指定する必要があります。

2.Boolean型の変換

tinyint(1) で定義されたカラムの値がEmbulkで truefalse とし扱われてるのでBigQueryの integer 型のカラムにインサートできません。
対応としては signed に型キャストするSQLを書くか、BigQueryのカラムを boolean にする必要があります。

3.タイムゾーン

BigQueryのタイムゾーンはUTC固定なので、JSTなどの他のタイムゾーンのDBのデータは時刻補正が必要です。