yuemori

Rails Developers Meetup 2018に進行協力・登壇しました


こんにちは。大阪スタジオの植森です。

Ruby on Rails の “現場の知見”に触れる Meetup

Rails Developers Meetup 2018が3/24(土)、3/25(日)の二日間に渡り開催されました。

Rails Developers Meetup 2018: Day 1

Rails Developers Meetup 2018: Day 2

弊社Aimingからは黒木(が発表、私植森(@wakaba260yen)がDay2の司会進行とPRスポンサー発表として参加しました。

二人とも大阪スタジオ所属で、このために東京まで足を運びましたが、それだけの価値のあるイベントでした。こうしたイベントに発表・運営協力の両面で参加できて非常に良かったと思います。

大阪中継会場の提供

弊社大阪スタジオを会場提供し、大阪へのLive中継も行われました。

当日はYoutubeでのLive配信があったのですが、大阪中継にも人が集まり、このイベントへの関心の高さが伺えます。

今回はRails Developers Meetup通じて初めてのAトラック・Bトラック同時開催だったのですが、大阪でも2トラック同時中継を試みました。中継をどうするかについては相談していましたが、やはり2トラックどちらも中継することでLive感を大事にしたいという気持ちもあり、こういった形での会場提供とさせていただきました。

手を貸してくれた社員と、こちら側の要望に応えて中継の手配をしてくれたオーガナイザーの方々のおかげで実現できましたが、結果として大阪会場に来ていただいた参加者の皆様にもご満足いただけたなら嬉しいです。

冴えてるRailsエンジニアの育て方

黒木()による、弊社で行っているRailsエンジニアの採用・教育の取り組みについての発表でした。

当日は私が司会を担当しているBトラックでの発表だったのですが、他のセッションに比べてもなお盛況だった印象です。

大阪会場のスタッフから話を聞いたところ、大阪側もほぼ満席だったとのことで、教育・採用に対しての関心の高さが伝わってきました。

弊社では採用の際にゲームプレイヒアリングシートというものに今までプレイしたゲームとそれに対する簡単な感想を書いて提出してもらっています。そうした取組みを紹介しつつ、教育の際に考えていることなどをお話させていただきました。

twitterでも弊社のゲーム会社らしい採用の目線や、ペアプロ、教育の取り組みなどに良い反響を頂けたと思います。

 

サービスクラス、その前に

PRセッションは、私植森(@wakaba260yen)の方よりサービスクラスの前に知っておきたいことをテーマに話をさせていただきました。

会社の方から「最後にPRしてもらえればなんでもいいよ」と言われていたので、PRセッションというよりもLTに近い雰囲気で話をしようと思い、こういう話になりました。

Day2はチームビルディングの話が多く、他のセッションが心に響く内容ばかりで、自分の話が皆さんの心に届くだけのパワーがあったかどうかは自信がありませんが、少しでも感じるものがあったら嬉しいです。

仰っていることは完全に同意で、「オブジェクト指向実践ガイド」の話をしながらのRubyでオブジェクト指向や設計についての話も本当はしたかったのですが、今回はちょっとエモい話をしたかったのでカットしました。

いつか機会があったらそういう話もしたいと思っています。

Rails Developers Meetup2018の司会を通じて

私はいつもは大阪側で中継スタッフをしていますが、今回は司会というポジションで参加しました。

司会についての感想は同じ日に別トラックで司会をされていた、みんなのウェディングの櫻井さんが熱い記事を上げられているので是非そちらを見てください。

オーガナイザーである平野さん(@yoshi_hirano )は、以前フリーランスとして大阪スタジオで働かれていたことがあり、その時のご縁もあってRails Developers Meetupのスタッフの一人として参加させてもらっています。

平野さんは本当にパワーのある人で、Rails Developers Meetupの初回からずっと走り続けて、一年もしないうちにこんなに大きなイベントにされてしまうなんて想像もしていませんでした。

Day2のセッションでしなもんさん( )によるバス因子の素晴らしい発表があったのですが、Rails Developers Meetupのバス因子は平野さんだと思います。平野さんの代わりなんてとんでもない、とは思いますが、進行や準備の協力など少しでも平野さんの負担を減らせられたら良かったと思います。

まあ、司会が終わった今となっては「楽しかったので是非次回もやらせてください」という気持ちなのですが。

まとめ

発表者の方々、ボランティアスタッフの方々、オーガナイザーの平野さん・秒速さん、そして参加者の皆様。

皆様のお陰であの楽しい二日間があったと思います。ありがとうございました。

We Are Hiring!

Aimingではエンジニアを募集しています。

セッションやこの記事を見て興味をもっていただけたなら、是非エントリーください!

https://aiming-inc.com/ja/jobs/


s-kuroki

Code Review Meetup #2に会場を提供しました&発表しました #codereviewmeetup


大阪スタジオのwebエンジニアの黒木です。

3/9(金)に開催されたCode Review Meetup #2に大阪スタジオのセミナールームを提供しました。

その名の通りコードレビューの話をする勉強会で、前回(東京開催)と今回はコードレビュー自動化サービスのSideCIさんが主催されました。(誰が主催しても良いというスタンスだとおっしゃられてました)

SideCI 角さんの発表

最初に行われたのは、SideCIのFounderの角さんの発表です。

角さんがSideCIを立ち上げるに至った経緯から、コードレビューサービスを運営しているからこそ見える、いろんな企業さんのコードレビューのあり方についてのお話で、非常に興味深く聞かせてもらいました。

LT

LTでは、Aimingから3名に加えて、飛び入りで1名、計4名が発表しました。

伝わるコードレビューのために(黒木)

焼肉とレビューの関係 〜難しいコードレビューのコツ〜

Qiitaにスライドが上がっています

oznor

ダブルレビューをやってみて

oznor

飛び入りの @whosaysni さんの発表

発表内容は公開されないということでしたので具体的な内容は控えさせてもらいますが、職場でレビュー文化を根付かせようと奮闘されているお話で、いろんなあるあるに共感しつつ聞かせてもらいました。

パネルディスカッション

角さんとLTの参加者で短めのパネルディスカッションを行いました。
参加者の皆さんからいろんな質問が出ました。皆さん、コードレビューの勉強会に来られるだけあって、コードレビューをチームに導入しようとしていて悩まれていたりしていて、非常に温度の高い話になっていたかなと思います。

まとめ

コードレビューの勉強会と聞くとニッチな感じもしましたが、チームで開発をやっていくには欠かせない重要な要素ですし、いろんなところでチーム開発に奮闘されている方が参加されていた、良い勉強会だったと思います。
また、出席率が100%だったそうで、その高さにSideCIの皆さんも驚かれていました。それだけ皆さん温度が高かったのだと思います。

宣伝

Rails Developers Meeting 2018でも会場提供&発表します!

来る3/24,25に開催されるRails Developers Meeting 2018でも、Aiming大阪スタジオで中継を行います。
中継会場の参加枠(1日目2日目)にはまだ空きがありますので、興味のある方は是非ご参加いただければと思います。
私も2日目に「冴えてるRailsエンジニアの育て方」というタイトルでお話させてもらいます。

Aimingは各種勉強会への会場提供をしています

東京本社大阪スタジオで勉強会に会場を提供しています。お気軽にご連絡ください。


Unityのバージョンをなるべく最新にする試み


こんにちは。エンジニアの鈴木聡です。

現在開発中のプロジェクトでは、Unityの新機能をできるだけ使えるようにしています。そのためには、Unityのバージョンを最新のものにしていくことが重要です。

今回は、実際に使用を始めている機能や、苦労した点について書こうと思います。

新しい機能のプロジェクトでの使用

現在、プロジェクトにおいて、以下の新しい機能が使用されております。

Timeline(2017.1.0から)は演出の一部で使用が開始されていて、そのままリリースに取り込まれる方向で開発が進められています。

TestRunnerのPlayMode(5.6.0から)についても、EditModeと共にCIの流れに組み込まれており、全てのPullRequestに対してテストが走るようになっています。

最新を追い求めるが故の不具合との向き合い

Unity2017.3.0f3にバージョンアップを行なった際に、以下のような不具合が発生して、苦労することになりました。

  1. iOSでアプリを動作させると高確率でアプリがクラッシュしてしまう
  2. UnityUI(uGUI)でApplyした時にレイアウトが崩れてしまう
  3. TestRunnerが実行時に硬直を起こすようになった

これらについては、プロジェクト側での対応では難しいものについては、パッチリリースを待つことになります。

上記不具合については、Unity2017.3.1p1において1および2が解決された模様です。Unity開発チームの迅速な対応に感謝です。

(その後、RectTransformをスクリプトで更新した時の挙動が少し変わっていて少し苦労するのですが、それはまた別の話)

最新を追い求めるが故のAPI置き換えとの戦い

Unityのバージョンをアップデートすると、新しいAPIへの差し替えを促進するために、古いAPIにObsolete属性が置かれることがあります。

完全に古いAPIが消されるまでは、ある程度の時間的猶予があることが多いですが、それでも古いAPIを新しいものに置き換えていく作業もそれなりの手間がかかります。

プロジェクト内で使用しているAPIについては、その都度対応するという方向で問題ないのですが、外部アセットを使用している場合は、そのアップデートを待って忘れずに更新を入れる必要があります。

さらに、外部アセットがサポート終了になっている場合は、アセットの更新が行われませんので、プロジェクト内でアセットを解読してパッチを当てていくことになります。地道な戦いが続きます。

リリース後のアップデートはどうするのか?

リリース後のアプリについては、アプリの安定性がとても重要になります。アプリのクラッシュなどは確実に避けなければなりません。

バージョンアップについては、アプリ全体の動作について、品質保証チームの助力を仰ぐなど、十分な動作確認を行う必要があるでしょう。

最後に

Unityのバージョンを最新に保っていくことには、それなりの苦労が発生するとは思いますが、最新の機能が使えるようになるというメリットは大きいと思います。これからも可能な限り新バージョンを追い求めていければと思います。


DB負荷試験をやった話


こんにちは!インフラチームの川田です。

業務では社内ネットワーク構築・運用やツールの検証などしています。
本記事では、1月末から2月初頭にかけて行ったDB検証のベンチマーク結果をまとめたいと思います。

試験環境

今回は以下4つの環境を対象にMySQL 5.7互換のあるDBを構築し、ベンチマークを測りました。

  • Google Compute Engine (以下GCE)
  • Google CloudSQL
  • Amazon EC2
  • Amazon Aurora

サービス概要

GCE及びEC2は、仮想マシンを構築することができるサービスです。
CloudSQLとAuroraは、フルマネージド型DBサービスです。どちらも簡単なので、とりあえずDB構築してみたいという初心者にオススメです。
CloudSQLはチューニング項目はありませんが、AuroraではMySQLのmy.cnfで設定できる項目の一部を変更できます。

インスタンス概要

GCPで使用したマシンスペックは次の表の通りです。

GCEでのディスク容量は500GB SSD永続ディスク、CloudSQLは2TB SSDとしました。はじめにデフォルト要領で計測を行っていましたが、GCPではディスクサイズによってIOPSとスループットが向上するため、本記事ではディスク容量を多めに取った状態での結果を記載しています。
また、CloudSQLへの接続方法は外部IPアドレスを直接指定するか、proxyを経由するかの2通りがあります。2通りで検証を行ったところ、外部IPで接続した方が1.3倍ほど良い性能が得られました。本記事内の結果は外部IPで接続したときのものです。

AWSで使用したマシンスペックは次の表の通りです。

EC2のディスク容量はデフォルトの10GB 汎用SSDとしました。
RDSでは設定項目をパラメータグループとして扱います。
今回のAuroraでの検証パラメータグループはデフォルトを使用しています。

試験内容

使用したベンチマークツールはtpcc-mysqlとsysbenchです。
tpcc-mysqlはTPC-Cの仕様に沿ったベンチマークツールです。
今回のベンチマークで使用したパラメータは以下の通りです。

  • warehouse: 5
  • warmup time: 10
  • bench time: 180
  • connection: 64

試行回数は各環境で3回ずつ、結果は1分間に処理したトランザクション数です。
CPUが2,4,8コアのインスタンスを対象に検証を行いました。
tpcc-mysqlはGCEもしくは、EC2の8コアインスタンス上で実行しました。

sysbenchは、Luaスクリプトによってシナリオを変更することができます。
今回のベンチマークで使用したLuaスクリプトは以下の8つです

  • bulk_insert.lua
  • oltp_insert.lua
  • oltp_point_select.lua
  • oltp_read_write.lua
  • oltp_update_index.lua
  • oltp_write_only.lua
  • select_random_points.lua
  • select_random_ranges.lua

パラメータは次の通りです。

  • thread: 256
  • bench time: 180

試行回数は各環境1回ずつ、結果は1秒間に処理したトランザクション数です。
マシンスペックは全環境で8コアのインスタンスを使用しました。
sysbenchもGCEもしくは、EC2の8コアインスタンス上で実行しました。

また、今回の検証では2月7日に正式リリースされたばかりAurora MySQL 5.7互換を早速使ってみました。
tpcc-mysqlとsysbenchでの試験はMySQL5.7互換での結果を出していますが、最後にMySQL5.6互換のAuroraとの比較も行いました。
手順はこちらを参考に、ベンチマーク用AMIに同梱されているsysbenchを用いて検証を行いました。使用したシナリオは次の通りです。

  • oltp
  • readonly
  • readwrite
  • selectonly
  • writeonly

ベンチマーク結果

まずはtpcc-mysqlの結果です。
CPUのコア数が2, 4, 8のインスタンスで検証を行いました。
GCEとEC2上で構築したMySQLはチューニング前後共に計測しています。
チューニング前後ではinnodb_buffer_pool_sizeなどを変更しています。


続いて、sysbenchの結果です。








最後にAurora 5.6と5.7の比較です。





まとめ

tpcc-mysqlの結果から、GCE, EC2インスタンスのチューニング後の性能が非常に良いことがわかります。GCEとEC2ではチューニング前後共にGCEの方が性能が高くなっています。性能差が大きく開いているため今後機会があれば、もう少し調べてみたいと思います。
また、sysbenchのoltp_write_only.luaとoltp_read_write.luaの結果を見るとCloudSQLとAuroraのwrite性能が他よりも低いことがわかります。

Auroraはデフォルトのパラメータグループでベンチマークを取っているので、チューニング次第ではさらに良い性能が見込めるのではないでしょうか。また、Amazonが提供するAurora負荷テスト用AMIでのsysbench検証結果では、とても良い性能が出ています。32コアインスタンスを使用していることや専用sysbenchのため、他のsysbench結果と単純比較は出来ませんが、スケールアップすることで順当に性能向上が見込めます。そして、AuroraのMySQL5.6互換、5.7互換の比較については、readonlyとselectonlyの性能が圧倒的に高くなっています。

CloudSQLについては、tpcc-mysqlではスケールアップした場合に他と比べて性能向上しませんでした。しかし、sysbenchのbulk_insertの結果が他より高い値が計測できました。並行処理が少なく、一度の書き込み量が多い環境では良い性能が出ると考えられます。

これらの結果から、Auroraはread性能が強い傾向が現れていたので、Webサイトなどに向いていると思います。write性能が求められる環境では、素のMySQLをチューニングしていくと良いのではないかと思います。

最後に

本番環境を想定したシナリオで測定するのがベストですが、これらの計測結果が誰かのDB選定の参考になれば幸いです。

また、Aimingではインフラエンジニアを絶賛募集中です!
ご興味のある方がいましたら、是非ご応募ください!