菅野 明洋

社内でエンジニア読書会をやってみた!


はじめに

初めての人は初めまして!
前回の記事(第2回 Game Gatling LTに登壇してきました!)を見てくれてる人は、お久しぶりです!

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

今回は、読書会を開いてみましたので、その話をまとめました。

読書会について

読書会は、集団で読書や読書に関するコミュニケーションを図るイベントです。
弊社では興味がある話題や本ごとに幾つかの読書会が開かれております。

開催してみた読書会について

今回は、SQLアンチパターンと言う本を題材にしております。
この本の読書会をするキッカケとしては、弊社の若手のエンジニアが最近読み始めたと言うことで話題に上がったことと、他のエンジニアと意見交換出来たら面白いと言う事で開いてみました。

読書会のルールについて

基本的に参加自由

  • 参加者は8〜12人程

開催時間

  •  定時後の45〜60分
    • 子育てで忙しい人も参加しやすくするために短めに設定
    • 経験上、1ページ2分換算で調整
  • 時間内(15〜20分程度)に章の全てを読みきれない場合は2日に分ける
    • 2日に分ける場合の例
      • 1日目にアンチパターンの問題点を黙読し他班に説明
      • 2日目にアンチパターンの解決策を黙読し他班に説明

用意したもの(書籍以外)

  • 付箋、筆記用具
    • 質問や意見を記入
  • ホワイトボード
    • 書籍の内容の説明や上記の付箋を並べるのに使用
  • キッチンタイマー(スマホアプリ)
    • 時間調整に使用

やり方

読書会の流れ

事前にやること

  • 読書会の日時、場所を決める

ステップ1(班分け)

  • 参加者を2班に分ける
    • 現在の決め方は座った席を順で分ける

ステップ2(読書フェーズ:アンチパターンの確認)

  • 各自担当箇所の章を黙読
    • 最近は読む際に付箋を配り、気になった点や質問したい内容を記入
    • ページ数に応じて変更しますが、大体15〜20分を目安にしています

ステップ3(説明フェーズ)

  • 読んだ箇所を別の班に説明
    • 説明する際は、図説する際はホワイトボードも使用
    • 章ごとに10分程度(計20分)の説明する

ステップ4(質問・討論フェーズ)

  • 全体を通して質問、討論を行う
    • 気になる点、分からない点を確認し解消する
    • 討論時にはアンチパターンに対してどのようにアプローチすべきなのか、他に方法が無いのかなど参加者の想いや考えなどのやり取り
    • 過去の話とかで盛り上がることもあります

読書会の様子

弊社の藤野がSQLアンチパターンの5章EAVについて説明している様子

読書会中に書き留めた付箋を集めてホワイトボードに貼っている様子(5,6章)

読書会中に書き留めた付箋を集めてホワイトボードに貼っている様子(3,4章)

ものすごく盛り上がっている時はホワイトボードにびっしり文字や図説が書かれていることもあったのですが、写真を取っていなかったため、現在記事を書きながら後悔しております。

読書会での試みと効果(参加者のフィードバック)

課題1:短時間で効果的に理解を深めたい

  • 対応策
    • 黙読後、読んでいない人に説明する
  • 効果
    • 説明する際に一度情報を整理するため、理解を深めやすくなった

課題2:質疑応答の敷居を下げる。意見を拾い上げやすくする

  • 対応策
    • 付箋を配布し、記入してもらう
  • 効果
    • 気軽に質問しやすくなった
    • 付箋を並べることで、他の参加者の質問(悩み)が見えやすくなる
    • 類似する意見があることで、他の参加者も同じ疑問を思っている等の安心感を覚える
    • 最初から質問・意見の数がわかるため進行の調整が楽になった

最後に

読書会を通して他のエンジニアと意見が交換できたので、とても参考になりました。
技術的な話のみだけではなく読書会の運用方法なども含め様々な意見を頂き、とても勉強になりました。今回の読書会では、まだ未完成な部分もあり進行が安定していないため、ブラッシュアップをしていかなくてはいけないと考えております。
毎回試行錯誤の繰り返している状態ではありますが、今後もこのようなイベントを続けて、より完成度を高めていきたいです。


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のデータは時刻補正が必要です。