神﨑 拓人

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


保泉 高広

TGSフォーラム2015で「これまでのオンラインゲーム、これからのオンラインゲーム」について講演させていただきました


こんにちは。リードソフトウェアエンジニアの保泉です。
2015年9月18日(金)にTGSフォーラム2015にて「これまでのオンラインゲーム、これからのオンラインゲーム」というセッションタイトルで、
弊社ゲームディレクター/ゲームデザイナーの水島と対談形式で講演をさせていただきました。

IMG_0517

セッションで使用したスライドを公開しましたのでお知らせいたします。


セッションでは、インターネットの普及とともに、「誰とでも遊べる」オンラインゲームが脚光をあびるようになり、現在はスマートフォンの普及により、「誰もが遊べる」オンラインゲームへとなった今、オンラインゲームの歴史を振り返りながら、今のオンラインゲームの開発が昔の開発と比べどう変化してきたのか、これからのオンラインゲームの開発に何が必要なのか、を企画・開発の目線から対談形式でお話させていただきました。
あまり企画・開発で対談する事が無かったので、この年代の日本のオンラインゲームってこうだったよね、今の日本のオンラインゲームってこうだよね、という事を振り返りながら対談できたのは非常に良い経験になりました。

対談の内容としては、日本のオンラインゲーム黎明期(2000年頃)から現在までを
・当時、ゲームデザインはどう考えていたか
・当時、ゲーム開発環境はどうだったか
・当時、ゲーム運用環境はどうだったか
にフォーカスをあてて対談をしました。

今回のセッションでは30分という短い時間という事もあり、予定していた内容を詳細に伝える事が出来なかったのですが、また別の機会があればもう少し詳細に話をさせていただければと思います。

最後に、東京ゲームショーにて今年もこういった機会をくださった FUSION Cloud 様、本当にありがとうございました!


芝尾 幸一郎

AimingでのGoogle Cloud Platformの利用事例について紹介しました。


こんにちは。リードソフトウェアエンジニアの芝尾です。Aimingでは、タイトルのデータ分析・データ分析基盤の作成を行っております。

先日、Googleがモバイル・アプリ開発者向けに主催した「Google for モバイル・アプリ」というイベントでAiming社のGoogle Cloud Platfrom利用事例について発表する機会を得ました。

noshita

Google社の許可を頂き、その際に利用したスライドを公開させていただきます。

発表内容は、Aimingインフラでの、Compute Engine利用事例、データ分析でのBigQuery利用事例になります。
データ分析に関してはなかなか社外に公開する機会は無いのですが、データ分析基盤について公表できて良かったです。

このような機会を作っていただいたGoogle様、関係者の皆様、有難うございました。

スライドにも書きましたが、Aimingでは一緒に働いてくれるエンジニアを募集しています。
Google Cloud Platformや先端技術を使ったインフラ構築やデータ分析に興味がある人には面白い職場だと思います。

詳しくはこちらまで。


保泉 高広

TGSフォーラム2014で「Aimingのクラウド採用基準」について講演させていただきました


こんにちは。リードソフトウェアエンジニアの保泉です。
2014年9月19日(金)にTGSフォーラム2014にて「Aimingのクラウド採用基準」というセッションタイトルで講演をさせていただきました。
IMG_8938

セッションで使用したスライドを公開しましたのでお知らせいたします。


セッションでは、オンラインゲームの企画・開発・運営を行う Aiming だからこそ話せるオンラインゲームでのサーバ採用基準を、「ソード オブ ナイツ」「スマホでゴルフ! ぐるぐるイーグル」等の採用実例を交えながらお話させていただきました。
なかなか企画・開発・運営の話を織り交ぜながら話をする機会もないので、オンラインゲームの企画・開発・運営はこういう事を考えているんだ、という事が伝われば幸いです。
今回のセッションでは30分という短い時間という事もあり、具体例をあまり伝える事が出来なかったのですが、また別の機会があればもう少し掘り下げた話をさせていただければと思います。

最後に、東京ゲームショーにてこういった機会をくださった FUSION Cloud 様、本当にありがとうございました!