菅野 明洋

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


はじめに

初めての人は初めまして!
前回の記事(第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:質疑応答の敷居を下げる。意見を拾い上げやすくする

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

最後に

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


入社2週間の新卒エンジニアが紹介するAimingの新人研修


こんにちは。2017年度新卒エンジニアの後藤です。

今回は新卒入社して2週間経過した私の体験等をもとにAimingの新人研修の内容について紹介します。

現在就職活動をされている方や、入社後に新人がどのようなことを研修で学んでいるか気になる方に参考にしていただければと思います。

新人研修の流れについて

Aimingでは入社後1か月かけてオンラインゲーム開発にかかわる人材になるための研修を行っています。最初の数日間に社会人としてのビジネスマナーの研修やワークフローについて学び、その後はゲーム開発に関わる研修を行います。

新人研修の様子

オンラインゲーム開発に関するリテラシー研修

オンラインゲーム開発を行う上場企業の一員として知っておかなければいけない事柄として以下の項目を学びます。

  • オンラインゲームの歴史と仕組み
  • セキュリティポリシー
  • コンプライアンス

大学や専門学校では学生どうしが演習等でゲーム制作をする機会も多いですがセキュリティポリシーやコンプライアンスを意識することは無いのではないでしょうか。

研修を通して、プロジェクトの一員であるとともに企業の一員であることを認識させられます。

職種毎の紹介

デザイナー・プランナー・エンジニア等、現場で各役職に就いている方々を講師に招いて講師が実際にかかわったタイトルなどを例に以下の項目を学びます。

  • 各職種の業務内容
  • Aimingにおける職種毎の心構え
  • 他の職種とのやりとりで留意すべきこと

それぞれの職種に属する新人の意識を高めるのはもちろん、他の職種に属する新人にも業務内容を共有することで互いに連携を取りやすくします。

また、プランナーからエンジニアへ留意してほしいことなども共有し、各職種をまたいだコミュニケーションを円滑に行う方法なども学びます。

その他

新人研修の後半にはスクラム体験をはじめとするグループワークや、自己紹介LT大会を実施します。

自己紹介LTでは自分の経歴について語るもよし、好きなゲームやアニメなどと絡めながら自分を紹介するもよしと、社内の方々にとって新人との接点を知ってもらう機会になっています。

研修を受けての感想

まだ全研修内容の半分を終えた段階ですが、私が大学時代に体験したゲーム開発と比べると規模の大きさも制作する立場も違うので、研修を通して新しい知見を得る日々を送っています。

とはいえまだ「知っている」の段階なので、得られた知見を現場で活かせるように意識しつつ残りの研修にも臨みたいと思います。


rastam

敷居を下げる雑な工夫


Hello! エンジニアのラスタムです。

今回は社内コミュニケーションやチームワークを補う様々な工夫を、基盤チームの共同執筆で紹介させていただきます。キーワードは「雑」です。

〇〇という強い気持ち・〇〇という雑な気持ち

ホワイトボードの一角に「〇〇という強い気持ち」「〇〇という雑な気持ち」を書いて貼ることができるスペースがあります。

「〇〇という強い気持ち」

書く内容に制限はなくいつでも自由に書くことができます。
「『やせる!』という強い気持ち」のような個人的な雑談レベルのものや「『まず動かす』という強い気持ち」のような業務に寄ったものなど内容は様々です。

このスペースには次のようなメリットを感じています。

  • 宣言することで自分を追い込むことが出来る
  • 雑談のネタになる
  • 周りの人のことを知る、周りの人に知ってもらう機会になる

雑談レベルのものが多いのですが、そのハードルの低さのおかげで普段から書く習慣に繋がっています。
そしてその習慣があるため、たまに真面目な強い気持ちが生まれたときも気軽に書くことができます。

社内勉強会用のネタストック

チームの勉強会で発表や LT などを毎週何かしらやっているのですが、そのペースでやっていると常にネタ切れ気味になっていきます。
その対策として、ネタになりそうな話や興味があるけど調べてない技術などをストックしておくスペースがあります。(ふりかえりのタイミングでよく発生するので、ふりかえりの TRY の近く)

ネタストック

ネタがないときにそこから好きなネタを拾ったり、あるいは個人的な学習のきっかけにしたりと、勉強会を続けるための一つの工夫となっています。

GitHub 上の zatsu レポジトリー

何かをやる上でとりあえずやらないことにはやる気が出ないので
ハードルを下げるために zatsu repository が存在しています。
この記事自体もハードルを下げるためのそれです。

Issue

おやつ

色々登録されてますね。
おやつリクエストの結果、チョコ棒とここでは紹介しきれませんでしたがポテトフライ(大好き)が供給されて食いすぎて太ったので、とりあえずは今は zatsu に痩せたいと願ってます。

社内ブログ・Wiki

日々の業務で得た知見やノウハウを同僚と共有したいことがたまにあります。
しかしその中には、内容によって社外にまで公開し難いものもあります。

社内 Redmine は前から置いていますが、

  • 主にフォーマルな用途で使われていて、思いつきで書くのを遠慮してしまう
  • Textile 表記で書くという点で使い勝手があまり良くない

そこで Rendezvous という OSS ブログ兼 Wiki を社内サーバにて立ち上げました。大好きな Markdown で書けてうれしい!

Rendezvous

真面目な記事は多いですが、カジュアルなコンテンツも気軽に載せています。
そして個人日報の倉庫として使っている人もいます。

全社で使える CI サーバー(レビュー作業の自動化)

普段から GitHub でコードレビューをしていると、入力ミス・イディオムの統一などの機械的なレビューが面倒になっていきます。

文字通りですが、「機械的にできることは機械に任せよう」ということで、社内で開発した CI(継続的インテグレーション)サーバーを用いて、機械的なレビュー作業の自動化を行っています。

この取り組みによって、「本当に注力すべき箇所にレビューコストを割く」というプロダクトの品質向上の一助となっております。どうせ怒られるなら、人間からより機械だったらカドも立たなくてよいですよね ^^


Aiming飲み会 #5 を開催しました


こんにちは。エンジニアの栗本です。

先月の1月25日(水)に Aiming飲み会 #5 グラフィックエンジニア新年会 を開催いたしました。
たくさんの方にご参加いただきまして、おかげさまでLTも大変盛り上がり、大盛況のうちに開催することができました。
お忙しい中お越しくださった皆様ありがとうございます。

乾杯の様子

乾杯!

LTの様子(山納)

LTの様子(山納)

ご厚意にあずかりまして、今回の発表資料の一部を公開していただきました。以下のリンクから見ることができます。
弊社エンジニアの山納: Vertex Texture Fetchの活用について
notargs様: GLSL作曲入門
柿崎様: Luaを使ったキャラクタのスクリプティング

次回のAiming飲み会は3月ごろ、デザイナーにフォーカスしたものを予定しています。
今後の情報は Aiming – connpass で公開していきますので、ご興味のある方はぜひフォローをお願いします。
改めまして、登壇者の皆様、参加者の皆様ありがとうございました。


Aiming飲み会 #5 グラフィックエンジニア新年会 を開催します!


こんにちは。エンジニアの栗本と申します。

来る1月25日(水)に Aiming飲み会 #5 グラフィックエンジニア新年会 -ちょい先のスマホグラフィックについて語る会- を開催します!
Aiming飲み会 #5 グラフィックエンジニア新年会 – connpass

Aiming飲み会とは

Aiming飲み会と言うのは勉強会のような堅い雰囲気ではなく、お酒を飲みながら比較的ラフな雰囲気でLT(LightningTalk)大会を行おうという企画で、2015年夏から不定期で開催しています。
前回の第4回ではアクセルマークさんのご厚意により会場をお借りし、WonderPlanet 社 CTO の村田知常さんをお招きしてLT大会を開催することができ、大変盛況でした。

第1回の様子

第1回LT

第4回の様子

第4回LT

第5回Aiming飲み会

第5回になります今回は
「グラフィックエンジニア新年会 -ちょい先のスマホグラフィックについて語る会-」
というテーマで開催します。
LT 登壇者としては、 notargs さん、 rita さん、弊社エンジニアの山納に加えて、Cygames の方とアカツキの方をお招きすることになりました!

会場の都合上参加者を増やすことは難しいのですが、募集はまだ行っておりますので、興味のある方はconnpassイベントページからの参加登録をお願いいたします。
スマホグラフィックのこれからが気になる方、LTを聞きながらお酒を飲みたい方は是非お越し下さい!


oguma

Aimingインフラチームを支え(てくれてい)る技術と設計(1/3)


この記事を読むのに使用する時間の目安 = 15分

初めまして。
Aimingでインフラを担当している 小熊(oguma) と申します。

普段は、ウェブサイトの構築/運用管理や
東京と大阪のネットワーク設計/構築/運用管理、
backoffice toolなどのinfra/inhouse開発および
技術指導/教育やフレームワーク導入や運用設計を行なっています。

それと最近は機会が減りましたが、たまにゲームインフラ構築や
内部統制および情報システム管理や人事関連をやっています。

LLによる開発や、Infrastructure as Code、 Tuning、 Serverless、 Container、 システムの自律化関連にとても興味がある音楽と雪山が好きな酒好きです。

今日も元気に飲みにいきましょう!!

さて、本題に入りますが
今回は、その中でAiming インフラチームが
どのような業務スタイルで、どんなツールを使っているのかや、ちょっとしたTipsなどを少し紹介させていただきたいと思います。

それらを 計3回に分けて投稿します。

今回、このblogを読む上で得られる情報は以下になります。

  • この記事で得られる情報
    • AimingインフラチームのワーキングスタイルとITサービスフレームワーク
    • Aimingインフラチームの使用しているツール, OSSなどの各種情報
      • その中から一部のツールのTips
        • Ansible 2.x
        • Vagrant
        • Serverspec
        • Infrataster
        • vuls

今回は、Container や Serverless などの話はしませんが、
少しでも皆様のお役に立てる情報になれば幸いです。

利用しているツールやフレームワーク

さて、
我々は以下のようなツールやフレームワークを採用しています。

  • IT サービスフレームワーク
    • ITIL を参考にしています
      • 強いチーム、業務プロセス改善、ITサービス運用レベルの向上にはうってつけの教本ですね
  • 構成管理
    • Ansible
  • TDI (Test Driven Infrastructure)
    • TDD
      • Serverspec
    • BDD
      • Infrataster
  • 環境
    • Mac
    • Vagrant
    • Container
    • Docker (個人利用 & 一部Projectで本番環境も利用開始)
    • Kubernetes
    • AWS
    • GCP
    • GMOアプリクラウド
    • IDCF
  • コード管理/ CodeReview
    • Github
    • Gerrit
  • 監視 / 解析
    • Mackerel
    • NewRelic
    • Cacti
    • Nagios
    • Zabbix
    • Datadog
      • 最近導入を開始
  • 脆弱性検査
    • Vuls
    •  (app検査は別途やっています)
  • CI
    • Jenkins
  • Integration / ChatOps
    • Slack

検証や個人利用を含めますと他にもありますが、チーム内ではだいたい上記を利用させていただいています。
そして、この場を借りて作成者に心からの敬意を表します。

[DevOps] Infrastructure as Code / Configuration as Code と 品質管理 / TDI

弊社でも
CodeでInfraを管理する
という業務を主体としています。

インフラ自体の品質管理も考慮していて、
テスト = Test Driven Infrastructure (TDI: これについては後ほど説明をします。) も、行うようにしています。

以下の記事が大変参考になり、強く共感しました。

Ito naoyaさんの Infrastructure as Code
https://speakerdeck.com/naoya/infrastructure-as-code
あるべき姿をコードにする、自動化するだけではない まさに構成管理の本質を捉えた言葉だと思っています。

このインフラを定義/宣言するやり方/捉え方は、現在のDockerでもInfraKit でReleaseされているものが近い思想に見えます。(InfraKitは、Docker for AWS/Azule からの流れとのこと)
https://blog.docker.com/2016/10/introducing-infrakit-an-open-source-toolkit-for-declarative-infrastructure/
https://github.com/docker/infrakit/blob/master/README.md
http://qiita.com/yamamoto-febc/items/2cd260ba956e1a3da78e

ちなみに Consul 等のClusterでも同じことが行えます。(Infrakitほど楽にできるかどうかは別として)
このあたりは目指している方向が同じと言えそうです。 (システムの自律化, NoOps)
期待しています。

CodeReview

重ねますが、品質管理/変更管理/リリース管理 は常に意識していて
我々も日々CodeReviewを行っています。

_WIP__Ansible2_2_support_by_aim-oguma_·_Pull_Request__412_·_aiming_infra-ext

私たちは新卒1年目から積極的にDevOps, CodeReviewに参加させています。
CodeReviewは、本当に素晴らしいと思います。

Banners_and_Alerts_と__Ansible_severspecでカーネルパラメータをチェックするロールの作成_by_sycho21_·_Pull_Request__326_·_aiming_infra-ext

合理的かつ、安全性や品質が上がり、スキルも全体的に上がるなど
チーム全体どころか会社全体どころか社会的にも良いことだらけです。

他社のインフラ関連のエンジニアで
CodeReviewを取り入れている会社は多々ありますが、
もし まだCodeReview を取り入れていないインフラチームがありましたら、ぜひ Github-Flow で取り入れることを強くオススメします。

AimingInfraStudy__Ansible編_Vol-1_

今回はここまでです。

次回は少し技術よりの話にして
Ansible の Tips, 最新版2.2の注意点、
VagrantのTipsなどをいくつかご紹介していきたいと思います。


ヴァリアントレギオンで利用しているSlackBOTについて


こんにちは。エンジニアの山内です。

Aimingでは社内のチャットツールとして Slack を使用しており、ヴァリアントレギオン (以下ヴァリレギ) のチャンネルでも、いくつかのBOTが動作しています。

KPT入力を催促するBOT

ヴァリレギのチームでは、Trello に Keep, Problem, Try を思いついた時に入力しておき、スプリントのタイミングで入力された内容を見返してKPTを進行しています。
ついつい忘れがちなため、毎日特定の時間になると Trello へ KPT の入力を要求するBOTがいます。KPTをやかる(※)BOT と呼ばれています。

※やかる:方言。(強引な理由の)文句を言う。訳すなら「KPT入力(されてない事に)文句を言うBOT」。

レビューを催促するBOT

ヴァリレギのチームでは、レビュータイムを設けてレビューが溜まってしまう状況を低減しています。レビュータイムをBOTが通知します。

Pivotal確認を催促するBOT

ヴァリレギのチームでは、PivotalTrackerでストーリーの管理をしています。実装ができて Accept を行うのはプランナーチームになるため、完了しているストーリーが無いか確認を催促するBOTがいます。

bugbot

最近はTODOも通知するようになりました。

担当決めBOT

急ぎで見てほしいレビュー、調査依頼など、誰かに依頼したいけど誰に投げるか決めにくい。かといって、@誰か ではなかなか拾われない。ということで、担当をランダムに抽選するBOTがいます。

これは あなたのチームの「いい人」は機能していますか? というスライドで紹介されていた手法です。

エリス 担当 <人数>

と入力すると担当者をピックアップしてくれます(エリスはヴァリレギ内でプレイヤーに色々教えてくれるキャラクターです)

eris

なぜか作成者が抽選されにくい現象が発生しましたが、コードに不正はありませんでした。
コマンドが日本語で打ちにくいと言う意見があり、エリスの多言語化が要求されています。

これらのBOTのおかげでチーム内のコミュニケーションが円滑になっています。


mewlist

Redmine で技術仕様書を書こう


はじめまして!
株式会社 Aiming の土井です! エンジニアをやっております!

今回の開発者ブログでは、情報共有ツールとしての UML の活用方法について、現場での取り組みをご紹介させていただければと思います!

技術仕様書の“図” どうやって書いてますか?

株式会社 Aiming では、プロジェクトの Wiki やバグトラッキングに Redmine をメインに使っています。みなさんも既にご存知だったり、実際にバリバリ活用されていることとおもいます。

また、企画仕様書、技術仕様書などは Redmine の Wiki やエクセルに代表されるオフィススイート等を活用して作成しますが…
図の表現を求められるような仕様書を作る時に、どうやって作成しようか悩んだことはありませんか?

  • 標準ペイントソフトで頑張って作成
  • オフィススイートに含まれる、ドローツールを使って図を作成、画像吐き出し

というケースが一般的には多いようです。かくいう私も、Google スライドでの図表作成に明け暮れたものです(p_-)

そこで、今回は、技術仕様書で必要となる図の表現方法について、Aiming で行われている取り組みについて紹介したいと思います。

技術仕様書といえば、UML!

UML について詳細は割愛しますが、仕様を視覚的に見せなければならない時に用いられる、図の書き方に関する取り決めです。

例えばこんな感じです。

すごい戦闘システムのフロー

2366afd8450116b7157a68cbbd5f03b357ca53886bbe89633f17fcdf3e46642c

適当なプレイヤーモデルのクラス設計

e68f045825b59ced550524e65dcb848465a2d8260e931ae8b23f450ad58a62de

こんな感じで、要点をシンプルに図で見せられるとわかりやすいですよね?
でも、UML のルールにしたがって図を綺麗に書くのって、やってみると結構大変。

特にエンジニアは、絵心については自信がない方も多いのではないでしょうか?(絵心あるエンジニアの方すいません)

絵心がなくても大丈夫!

こういった図を描くために、「Windows の標準ペイントソフトと格闘して、気づけば日が暮れていた!」 みたいな経験、皆さんありますよね? この苦痛に耐え、その先に産みの苦しみを知るわけですが……ちょっと待って下さい。

実は、先ほどの例に上げた図、Redmine の Wiki に直接テキストで記述されているんです! (ここ、びっくりするところです)

すごい戦闘システム

{{plantuml
  title すごい戦闘システム
  
  (*) --> "コマンド?" as Wait
  Wait --> ["たたかう"] "敵のHPを減らす" as Damage
    --> if "敵は生きてる?" then
         --> [HP == 0] End
       else
         --> [HP > 0] Wait
       endif
  
  Wait -> ["にげる"] "戦闘終了" as End
  
  End -> (*)
}}

適当なプレイヤーモデルのクラス設計

{{plantuml
  abstract Abstract {
    HP
    MP
    瞑想する()
  }
  
  interface Interface {
    走る()
    投げる()
    飛ぶ()
  }
  
  class Player {
    名前
    運
    適当なことを言う()
  }
  
  Abstract <|-- Player
  Interface <|.. Player
}}

Redmine のプラグイン (PlantUML) を導入する

UML をテキストで記述する機能は、PlantUML Redmine plugin という Redmine のプラグインで提供されています。

PlantUML Redmine plugin

図をテキストで書くことのメリット

  • ペイントソフト・ドローツールの使い方に明るくなくても
    プログラムみたいに図が描ける
  • エンジニア間だけでなく、プランナーとの情報共有にも活用できる。図なので!
  • Redmine Wiki の履歴がテキストで残る。つまり、図の差分が把握できる
  • クラス図なんかは そのままソースコードの雛形として使える
    設計段階からコードの全体像を意識することができるので、設計と実装を分離して考えることにもつながる
  • 順番の入れ替え、追加削除が容易なので仕様変更に強い
    (仕様が変わって矢印をマウスで一つ一つ引き直すみたいな経験…ありますよね)

最後に

Redmine をお使いの方は、PlantUML Redmine plugin をインストールしてみてはいかがでしょうか。

UML はとても強力なツールですが、敷居が高い印象を持つ方も多いと思います。
まずは、PlantUML の公式サイトのサンプル画像をみて簡単な図から描いてみましょう!


『剣と魔法のログレス いにしえの女神』でのBigQueryの利用


Web開発チーム エンジニアの富田です。
「剣と魔法のログレス いにしえの女神」(以下ログレス)の管理ツールを開発しています。

先日、社内勉強会でBigQueryについてお話する機会があったので、その内容を元にしながら、ログレスでのBigQueryの利用や「管理ツール」開発について紹介したいと思います。

BigQueryの利用について

ログレスでは、ゲームサーバーから出力されるログをBigQueryにアップロードしています。
出力されるログは、膨大且つ様々な種類がありますので、その中から目的のデータを探し出すには、BigQueryの検索性能は非常に有用です。

AimingでのBigQueryの利用については、下記の記事に記載していますので、ご興味のある方はご覧頂ければと思います。
AimingでのGoogle Cloud Platformの利用事例について紹介しました

また、ログだけでは無くデータベース内のデータも一部、BigQueryにアップロードしています。
ログ内にはアイテム名やクエスト名のようなデータではなく各IDしか入っていませんので、データベース内の情報とJOINすることで、それらを取得できるようにしています。

他のメリットとしては、BigQueryにアップロードしておけば、本番環境の状態に関わりなく、各種集計処理を行うための負荷の高いクエリを投げることができます。

「管理ツール」でのBigQueryの利用について

ログレスの「管理ツール」では、お客様サポート用の機能、売上等のKPI、プッシュ通知などの運用ツールなどを提供しています。

「管理ツール」の機能例

これらの機能の一部で、BigQuery内のデータを利用しています。

例えば、アイテムデータ喪失のお問い合わせ用にアイテムの操作履歴の検索機能や、プランニングの参考のためにクエストの達成状況を一覧する等の機能があります。

これらの機能は、運営・制作スタッフの要望や新コンテンツの追加等によって、現在も次々と追加されています。

また、他の使用例としては、先日公開した ログレス国勢調査 の各項目の集計に利用しました。
掲載している各集計値は、全てBigQueryのデータを元にしています。

データ解析ツールとその利用

Aimingには各ゲームのKPIを横断的に閲覧できる解析ツールが有り、このツールではBigQuery内のデータを使用しています。

このツールに集計クエリを登録すると、簡単に時系列(時間単位/日次/週次/月次)でグラフ化することができます。

例えば、イベント用のクエストの達成率を一覧したり、ガチャ施策が想定通りの効果が得られなかった場合に、その要因となる指標を集計してグラフ化し、お客様によりご満足いただけるゲーム体験を提供するための改善に役立てるなどの利用用途があります。

Web開発チームでは、日頃より、この解析ツールについての社内勉強会・ワークショップを行い、エンジニア以外の利用も推進していく活動も行っています。

また、各種イベント施策の効果検証をデータ面から補強できるように、グラフ化やデータ抽出を行って、プランニングに役立てて頂いてます。


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