oguma

ハートビーツさんと懇親会でLTをしました ’17 06/16


どうも、こんにちわ。

SNS幽霊部員ビリティ高めなOgumaです。
AimingではインフラをAll layerで担当しています。

先日6/16に、そのインフラに関係するMSP (Management Service Provider) である
ハートビーツ さんに 数名で 遊び 懇親会に行かせていただきました。

その際に後輩の趙くんと共にLTをやらせていただきました!!!

国内 (海外は担当が異なる) の公式サイトや、それらと連動するゲーム内から呼び出されるwebView向けのサーバなどをCephFS上に載せてみた話をしました。

さすがハートビーツさんっっ!!
いつもブログ等で勉強させていただいてる高いスキルをもった方々がいらっしゃいますね。
いろんな貴重なお話をさせていただいて、大変嬉しかったです。

また、発表した資料にさすがプロと言える鋭い質問をいくつも頂けました。

例えば

  • なぜCephなのか、Glusterではなかったのか
    • Glusterの方が高速に動いたからGlusterの方を選択した前例があったとのこと

など。 (お酒が回ってて、これ以上は思い出せませんw)

資料には書かれていないことなので、ここで補足という形で
我々がCephFSを採用した理由をまとめますと以下になります。

  • 今回の場合、I/O速度を求めなくて良いようなところに使用した
    • そのように設計した & なっている (I/0が必要なところはDB関係のみ)
  • CephがOpenStackで実績が積まれていて大部分が枯れている (LTSの安定に期待が持てた)
  • CephFSを使ってみたかった
    • 使ってみたら安定していた
  •  (今回の資料には書けていないところもありますが)高速化方法が色々把握できた
  • Kubernetes のPersistent diskでも対応している
  • スケーラビリティの高い分散ストレージClusterが必要
    • webViewや、イベントのアクセスが大量に来ることがあるため
  •  我々のGluster Storage (Redhatに買収されてからRHGSになった)の利用経験、実績がない

といった点です。

その他弊社からは
アプリケーションエンジニアより、昨今注目されているPrometheus についてLTがありました。

好評の触ってみたシリーズで、最後の刺さる点を共有してくれたところも勉強になりました。

hbstudyというITインフラ業界では有名な勉強会を開催している憧れの会社/エンジニアさんがいる会社で、スキル高いなーと再認識しました。
(人気が凄くてなかなか参加できていませんが、かなり前に個人的にもhbstudyに参加したことあります)

とても貴重で楽しい体験をさせていただけたハートビーツさんに
この場を借りて、心から感謝と敬意を表させていただきます。


Webブラウザ版 『剣と魔法のログレス』のサーバーマシンリプレイスのお話し


はじめまして、大阪スタジオのサーバーエンジニアの太田と申します。

Webブラウザ版 『剣と魔法のログレス』(以下ログレス)は2011年にリリースして、おかげさまで今年で運営6年目になります。

そんなログレスも、そろそろマシンの老朽化やスペック不足が気になり始めたので、2017年3月にサーバーマシンのリプレイスを実施しました。

今回はそのお話しになります。

リプレイスの目的は?

  • 経年劣化によるハードウェアトラブルの回避
    • 全サーバーマシンを新しいハードに乗せ替える
  • 物理サーバーから仮想サーバーへ乗せ替え
    • サーバーの追加や削除が簡単に行える。
    • トラブル時の復旧も楽になる。
  • サーバーOSのバージョンアップ
    • OSのサポート期限が切れるため
  • 最新のクラウドサービスへ移行する
    • セキュリティの強化、保守性の向上
    • 構築や設定コストの削減

リプレイスに向けてのスケジュールと準備内容は?

  • 5か月前から準備開始
    • リプレイス内容の決定
    • タスクの洗い出し
    • スケジュールの決定
  • 4~3か月前
    • 物理サーバーと仮想サーバーでの各種ベンチマーク比較
    • 必要スペックの洗い出し、費用の見積もり
    • 動作検証用環境での各種動作チェック
  • 2か月前
    • 新クラウドサービス契約
    • OSのセットアップ、ネットワーク設定
  • 1か月前
    • ゲーム環境の構築
    • 各種動作チェック(課金認証等)
    • 本番当日のタイムスケジュールの作成
  • 1週間前
    • ステージング環境のリプレイス
  • 当日
    • 本番環境のリプレイス
    • DBとログの引っ越し
    • 本番環境での各種動作チェック

苦労したこと

  • バージョン違い問題
    旧環境で動作していた各種サーバープログラムが、OSバージョンやソフトウェアバージョンの違う新環境で同じように動作しませんでした。
    使用してるライブラリが新しいOSでサポートされておらず、対応に苦労しました。
  • 仮想化で発生した不具合
    仮想サーバーに乗せ替えてから、ゲームサーバー内の全てのスレッドがスリープ状態になる不具合が発生しました。
    調査するとスレッドをスリープする処理とウェイクアップする処理に問題があり、タイミングによっては今回の症状が発生する可能性があることが判明しました。
    物理サーバーではCPUのコンテキストスイッチの動作が安定していて問題が起こりませんでしたが、仮想サーバーにすることで不安定になって、問題が表面化しました。

良かったこと

  • 新たに契約した新クラウドサービスは、ネットワーク転送速度が10Gbpsなので、ファイルの転送速度が速くなり、メンテナンス作業が高速化しました。
  • マシンのスペックアップに伴い、必要マシン台数が減り、結果的に運用コストが軽減しました。
  • 利用できるメモリが増え、今後のゲームコンテンツの拡張がしやすくなりました。

まとめ

私にとってはサーバーのリプレイスは初めての経験でしたが、時間をかけて事前の動作検証や当日の作業準備などを行った結果、ログイン障害や課金障害等の大きな問題もなくリプレイスを終える事が出来ました。

今回の経験を通して、改めて事前の入念な準備と動作検証が重要だと思いました。

以上、ログレスのサーバーマシンリプレイスのお話でした。


久保 翔太

GCE Local SSD向けのチューニング


こんにちは、インフラエンジニアの久保です。

今回は、GCE(Google Compute Engine)のLocal SSDのチューニングとベンチマーク結果についてご紹介したいと思います。

Local SSDとは

GCEではPersistent Disk(ネットワーク ディスク)、Local SSD、Cloud Storage Bucket、RAM Diskの4種類のディスクサービスを提供しています。
今回利用したLocal SSD はPersistent Disk(ネットワーク ディスク)と異なり、仮想マシンインスタンスのホストとなるサーバーに搭載されているSSDに直接接続されているため、非常に高速です。
Persistent Diskに比べて低レイテンシかつ高IOPSであるため、非常に高い性能が求められている環境においては非常に有用かと思います。
また、今回の試験では利用していないのですが、RAM Diskはメモリ上にデータを格納するため、Local SSDより高い性能が期待できます。
続きを読む


神﨑 拓人

JenkinsとGitHubのWebhook連携の整理


Jenkins と GitHub を連携させる Webhook について

GitHub と Jenkins を連携させる機能のひとつに「Webhook」と呼ばれるものがあります。この Webhook をつかうことで、 GitHub 上で管理しているリポジトリにブランチを push したときや、新たに Pull Request を作成した時などに Jenkins のジョブを走らせるといったことができます。

しかしながら、 Jenkins や Jenkins の複数のプラグインが Webhook の機能を提供しており、どの機能がどのサービスを提供しているのかがわかりづらくなっているのが現状です。そこでこのエントリーでは、それぞれの機能でどのような特徴があり、どういった設定が必要なのかを、実際に設定を行いながら整理したいと思います。

なお使用している Jenkins のバージョンはこの記事執筆時点での Jenkins の最新バージョンの安定バージョン 2.32.3 LTS です(各プラグインのバージョンについては項目ごとに記述)。

続きを読む


oguma

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


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

インフラチームの小熊です。
前回(弊社インフラチームが参考にして実践しているITサービスフレームワークや利用しているOSS, Tool類の紹介をさせていただきました。)から大分空いてしまいましたが、今回は、そのツールやOSSのTips をいくつかご紹介したいと思います。

tl;dr

Ansible は、vim-ansible-yaml を入れて、CI に放り込みつつ Serverspec等で TDD / TDI すれば良い感じだと思います。
その他のAnsible tips やVagrant について書きました。
良さそうなところがあったら参考にしてみてください。

Ansible Tips

構成管理ツールは、主に Ansible が扱われています。
(AnsibleでContainer操作も可能ですが、今回Containerの話はしません)

そんなAnsible のTipsや、最近Version 2.2の注意点をいくつか紹介したいと思います。

ツールの紹介

素晴らしいツールの紹介です!
すでに世間でよく出回っている情報ですので、知っている人は読み飛ばしてください。

  • vim-ansible-yaml
    • これを入れておけば、早く書けます
    • はい、私はvimmerです
  • ansible-console
    • module の単体テスト、動作確認が出来ます
      • e.g.) 例えばvagrantの場合は以下でインタラクティブシェルが起動します
        ansible-console -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory
        
      • 上記でインタラクティブシェルに入ってから
        help

        もしくは

        ?

        と打つとhelpが参照出来ます

      • このhelpを使うことでも簡単なansible-doc のような役割も満せます
        koguma@all (1)[f:5]$ help datadog_event
        
        Posts events to DataDog service
        Parameters:
        date_happened POSIX timestamp of the event.
        alert_type Type of alert.
        title The event title.
        text The body of the event.
        tags Comma separated list of tags to apply to the event.
        app_key Your DataDog app key.
        priority The priority of the event.
        aggregation_key An arbitrary string to use for aggregation.
        api_key Your DataDog API key.
        validate_certs If C(no), SSL certificates will not be validated. This should only be used on personally controlled sites using self-signed certificates.
        
  • ansible-doc
    • AnsibleのdocumentがCLI上で開けます
      • 私はvimやatom上で利用しています
  • ansible-playbook-debugger
    • 私は使っていませんが、一応debuggerもあります

version 2の注意点

  • 最新2.2について
    • check mode の対応が変わりました
      • always_run は deprecation となり、無くなる予定だそうです
        [DEPRECATION WARNING]: always_run is deprecated. Use check_mode = no instead..

        と出ます

      • 変わりに check_mode: no を使うようにしましょう
    • group_vars/等の読み込みが変わりました
      • .yml or .yaml の拡張子が必要になりました
      • 全てのfileに拡張子をつけるようにした方が良いようです
    • service module
      • systemd の扱いが変わりました
        • SysVinit scriptのものが起動できなくなっていました
        • 2.2 からsystemd module ができていました
      • sleep option を受け付けなくなりました
    • include の扱いが変わりました
      • include を使う上で変数の扱い方によっては、それら変数を Dynamic に読み込ませるかStaticに読み込ませるか選択が必要になりました
      • 詳細は以下を確認してください

whenで、値をまとめたOR判定をする

when: ansible_env.TARGET_ENV == 'test' or ansible_env.TARGET_ENV == 'development'

と書くのは長いので、下記の様に in を使います。

例 (testとdevelopmentを環境変数 TARGET_ENVで、受け取って判定をする。)

environment:
  - TARGET_ENV: "{{ lookup('env','TARGET_ENV') }}"
tasks:
  - debug: var=ansible_env.TARGET_ENV
    when: ansible_env.TARGET_ENV in [ 'test', 'development' ]"

動作確認 (test, developmentそして、skip判定確認のためのhogeをそれぞれ順番に環境変数TARGET_ENVに入れてdebug)

% for ENV in test development hoge;do TARGET_ENV=${ENV} vagrant provision test | grep -A 4 'TASK \[debug\]';done
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
ok: [test] => {
    "ansible_env.TARGET_ENV": "test"
}
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
ok: [test] => {
    "ansible_env.TARGET_ENV": "development"
}
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
skipping: [test] => {
    "changed": false,
    "skip_reason": "Conditional check failed",

TARGET_ENV=hoge だけ

    "changed": false,
    "skip_reason": "Conditional check failed",

になったので正常に判定ができています。

Testについて

  • ansible-spec というtoolが用意されています
    しかし、Ansible 以外のtoolとも連動させたインフラテストを行っていきたいので Serverspec と Infrataster を利用するように絞りました

    • Serverspec
      • TDD / TDI全般 で利用
    • Infrataster
      • deploy後のBDD で利用

これらについて細かいことは次回投稿する予定です。

必ず、Ansible でServerspecが実行されるようにしている

  • playbookに書いています。
    • post_tasks を使うと毎回 Serverspec でテストしてくれます
      これで 半ば強制的に TDI を実現するようにしています

Ansible playbookからの強制Test実行の注意点としては
事前にsshでアクセスできるようにしておく必要があります。(vagrant sshではなく)

[補足] Vagrant 側で用意されている vagrant ssh-config をplaybook側で実行し、~/.ssh/configに書き込むことも考えました。

しかし vagrant ssh-config に初期化 = ~/.ssh/config をワイプしてくれる機能がないので、各環境で用意したり考慮していくのも面倒だと思えました。 (Jenkinsなどでvm を作ったり消したりしながらテストをバンバン回していく環境など)

そこで、環境構築手順の簡略化も考慮し、Vagrantfile にssh pub auth 登録の処理を書いてしまっています。

playbooksが煩雑になるのを避ける

通常のansibleはplaybooksを直下に横並びで置くため、多くなってくると見づらくなる問題があります。
我々のチームの特定Projectでは、良いか悪いかは別としてplaybooks が煩雑にならないように playbooks dir 配下におけるようにしています。

具体的には以下のような構成です。

├── playbooks
│   ├── addusr_ssh.yml
│   ├── disable_selinux.yml
│   ├── gce-instance-provision_and_init.yml
│   ├── gce-lb-provision.yml
│   ├── instance-provision_and_init.yml
│   ├── monitoring-tool.yml
│   ├── td-agent.yml
│   ├── test.yml
│   ├── vuls.yml
│   └── wordpress.yml
├── plugins
│   └── inventory
├── roles
│   ├── add_ssh_user

# ..<snip>

通常は以下の構成になります。
https://docs.ansible.com/ansible/playbooks_best_practices.html#directory-layout

どうやっているか

  • Custom role path という機能を使っている
    • ansible.cfg に以下の設定をしています
      [defaults]
      roles_path = roles
      
  • group_vars, host_varsを対応させる

    Ansible galaxy でも落とせるようにしてあります。

    ansible-galaxy install aim-oguma.init-for-integrated

1/30追記: ansible-init-for-integrated に一部不備があったので訂正しました。

Ansibleの小ネタ

普段の運用でも、ansibleをよく使っています。
その中でちょっとしたネタ的な使い方を紹介します。

クラスタオペレーションツールとしてリソースを監視する例 (CPU使用率を表示)

[devinfra@test-festa ansible]$ ansible -i inventory all -m shell -a "sar -u ALL | awk 'NR==6,p{if(m<\$4) m=\$4} END{print m}'"
test-festa-slave2 | SUCCESS | rc=0 <<
0.44
test-festa-master | SUCCESS | rc=0 <<
0.39

test-festa-slave1 | SUCCESS | rc=0 <<
0.37

Vagrant

下記に内容を示します
具体的なcodeは纏めて記載します。

For Ansible provision

引数で各playbook 名を指定して、それで動くようにしています。
各種playbookがそのまま同じVagrantfileで利用可能なようにしています。


@vm_name = ARGV[1]

playbook = {
  :disable_selinux => "playbooks/disable_selinux.yml",
  :target => "playbooks/#{@vm_name}.yml"
}

Vagrant の高速化

virtioを使うようにしたり


    vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
    vb.customize ["modifyvm", :id, "--nictype2", "virtio"]

local repositoryを使っています (ちなみにvagrant-cachierは問題起こすので現在利用停止中)

社内にLocal yum repositories を立てていて、社内いるときだけそれを使うように動的な処理を入れています。


Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

# ..

  # 社内の場合はLocal repositoryに向けて高速化する
  if Network.global_ipaddr.inhouse?
    config.vm.provision :shell, :inline => <<-EOT
      sudo sh -c "echo '#{MYCORP_LOCAL_REPO}' > #{MYCORP_LOCAL_REPOFILE}"
    EOT
  else
    config.vm.provision :shell, :inline => <<-EOT
      if [ -f #{MYCORP_LOCAL_REPOFILE} ];then
        rm -f #{MYCORP_LOCAL_REPOFILE}
        sudo yum clean all
        sudo yum repolist
      fi
    EOT
  end

Vagrantfile

Vagrant Cloud を利用しているので vagrant login はしておいてください。

このままでは動きませんが、playbookを用意したり、Vagrantfile に<>で書かれている部分を適宜設定していただければ利用出来るはずです。

最後に

こちらでのご紹介が、誰かのお役に立てれれば幸いです。

今回はここまでです。

次回は CI (Jenkins) や TDI tool (Serverspec), BDD tool (Infrataster)についてや、重要な脆弱性診断が行えるツール vuls について近日公開したいと思います。


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などをいくつかご紹介していきたいと思います。


菅野 明洋

第2回 Game Gatling LTに登壇してきました!


はじめに

初めての人は初めまして、前回の記事(まべ☆てっく vol.1に登壇してきました!)見てくれてる人こんにちは!
大阪スタジオ インフラチームの菅野明洋です。
業務では、大阪スタジオのサービスインフラを担当させていただいております。

今回は、2016年10月2日の日曜日に大阪で開催されました第2回 Game Gatling LTにて、スピーカーとして私と藤井が登壇させていただきましたので、レポートとしてまとめました。

GGLTとは

関西でゲーム開発に携わるエンジニア、デザイナー、プランナー等の人が集まり、ライトニングトークを行うイベントになります。

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

今回の発表は、剣と魔法のログレス いにしえの女神で使われている技術やノウハウの話になります。

■菅野明洋:スマホ版ログレスでグローバル展開を想定したサーバ構築をAnsibleで試してみた話

■藤井章暢:スマホ版ログレスにポストエフェクトを組み込んだ話


私の方ではAnsibleでの設定例を中心に発表しております。
Ansibleとなりますと、色んな書籍やブログ等でベストプラクティスや使用方法が記載されていると思いますが、今回の発表ではグローバル展開を想定した際に、どのように工夫をしたのかをまとめました。
グローバル展開を行ったとしても、サーバの構成が一切変わらないとなれば特に悩む必要はないのですが、現地のインフラ事情や新規実装を行うとなると日本版と全く同じサーバ構成と言うわけにはいかないケースもあると思います。
構成を国やデータセンター毎の差分を管理を行い、各地で行った改善内容を別の地域へ反映するなど相互的に良い事を取り込み合うことが出来たら良いかなと思いました。

藤井の発表では、クライアントにポストエフェクトを導入した話になります。
戦闘中のシーンに合わせて放射線状にブラー処理を入れ、従来の戦闘シーンをより迫力のあるシーンにしています。詳しくはスライドをご覧ください。

■発表中の様子

2016102402

発表中の菅野

2016102401

発表中の藤井

感想

LTとなりますと、「あれもこれも話したい。でも時間がない」といった葛藤があります。
ベースとなる発表資料は一週間から数日前には完成していたのですが、発表直前までスライドの編集したり脳内練習したり等、発表直前まで調整していました。

結果的には、一回目のドラがなったラスト1分前で私の喋りがスピードアップし、制限時間の終了を表すドラと同時に「ご静聴ありがとうございました」と言う形になりました(ギリギリセーフ?)。

最後に

GGLT運営の皆様、会場に来場した方々、登壇の機会を頂きありがとうございました。
とても貴重な経験をさせていただくことができました。


jenkins と ghprb,github commit status を使った仕事が楽になる 10 の設定


「ぐるぐるイーグル」チームでエンジニアをしている @takesato こと佐藤(たけ)です.

「ぐるぐるイーグル」では,エンジニアだけでなく企画もデザイナも github を使用して仕事をし,お互いレビューをするという環境ができあがっています.
see. 【GGG#4】Aiming『ぐるぐるイーグル』にみるゲーム性を左右する背景マップの作り方…職種を超えた挑戦が効率的なワークフローを生む | Social Game Info

プロジェクト開始当初から Jenkins も導入しており,Jenkins の結果を github に反映していました.
しかし,github の表示できるステータスは長い間1つのみだった為, 「ぐるぐるイーグル」 での Jenkins の Job は色々なチェックを全て一つの Job でおこなっていました.
Job の分割を行なうと色々なメリットがあるので,今回 Job の分割を行ないました.
いくつかその時に得た知見を紹介してみようと思います.

ちなみにメリットはこのようなものがあります.

  • 分割した Job 単位で成功失敗がわかる.
    • 1つの Job の場合,途中で失敗した場合,残りの処理が成功するのか失敗するのかがわからない.
  • 依存しない Job であれば,複数同時に実行する事ができ,時間の短縮にも繋る.
  • A(Unity), B(Ruby) のようなテストの場合, B を実行するサーバだけ Linux のサーバに移すといった事もやりやすくなる.
  • 失敗した Job だけを再開できる(要 rebuild plugin)

続きを読む


運用時の Ansible の使い方(一例)


こんにちは。15年度入社の新卒、大澤です。

私はインフラエンジニアとして Aiming に入社し、ほぼ毎日新しい技術やサービスに触れています( Git, Jenkins, Ansible, などなど… )。その中でも今回は、私が最近覚えた運用時に使う Ansible の一例を紹介したいと思います。

Ansible shell module を用いて、複数サーバへコマンドを実行

同じコマンドを実行したいサーバが複数台ある場合( Slave DB2台に “show slave status\G” とか、Web Server 5台のアクセスログを見るとか…)、私のような未熟者だと「一台ずつ入ってコマンドを実行しよう!」と考えがちですが、そのやり方だと非効率だと叱咤を受けます。そこで、 Ansible の shell module を使用します。

例えば、下記のような inventory file を用意して…

[web-server]
webserver01
webserver02
webserver03

[slave-server]
slave01
slave02

以下のコマンドを実行します。

ansible -i hosts web-server -m shell -s -a "tail -2 access.log" | less

(オプションの説明)
-i <inventory_file> <group>: inventory file を指定する。group 名を指定しないとエラー。
-m <module>: 実行する module を指定する。
-s: sudo で実行する。
-a <command>: 実行する command を書く。

すると、 web-server group に書かれている server(webserver01~ 03) 全てに “tail -2 access.log” が実行され、サーバごとの結果が less に渡されて表示されます。上記のコマンドだと、access.log の中身が末尾2行ずつ表示されます。結果をパイプで渡すことも出来ますし、実行するコマンド内でもパイプは使用できます。

↓ access.log を見ている様子(見えてはいけない部分は隠しています。)
https://gyazo.com/fe7b1c9cc5ce01e3a06c8b49920aec51

もちろん、for 文でも同じことができますが、inventory file の group 分けが便利だと感じます(上記の例でいうと、 web-server と slave-server )。-i hosts all とすると、inventory file に書かれている全てのサーバに実行されます(重複はしない)。もちろん1つのサーバを指定することもできます。

以上、私が最近覚えた運用時の Ansible の使い方の一例でした。
来年の新卒にきちんと教えられるよう今後も Aiming で頑張りたいと思います。


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