GameWith Engineering Blog

GameWith のエンジニア、デザイナーが技術について日々発信していきます。

リリース前ゲームのレコメンドを検証してみた

GameWith エンジニアの @skagawa です。開発部の部長をしています。他には、騎空士、マスター、新人スタッフのお仕事もしています。

GameWithでは「リリース通知」というゲームがリリースされたことをユーザーにメールとおしらせ通知で知らせるサービスを提供しています。

ゲームタイトルは日々発表されているため、ユーザーが自分好みのゲームを見つけることが難しくなっています。
その課題を解決するため、GameWithでは「ゲームレビュー」でのゲーム情報の発信とは別に、

  • リリース通知対象タイトルのピックアップ
  • 登録数ランキング

というユーザーが新しいゲームを見つけられるためのコンテンツを用意しています。

ピックアップされるゲームタイトルは多腕バンディット(アルゴリズムはThompson sampling)を活用し、 新しく発表されたゲームタイトルの露出機会を設けつつ、ピックアップ枠経由での登録が多いゲームタイトルが最適に表示されるようにしています。

今後はよりユーザーが興味のあるであろうゲームタイトルをおすすめできるよう、レコメンド形式でのゲームピックアップの検証を進めています。
まだ実際のサービスとはなっていませんが、今回は検証中の仕組みを使ったゲームレコメンドを紹介します。

続きを読む

YAPC::Okinawa 2018 ONNASON にスポンサーとして協賛します

GameWith は YAPC::Okinawa 2018 ONNASON にゴールドスポンサーとして協賛します。

弊社では今のところ Perl 言語を多く使っていませんが(一部では使っています!)、弊社メイン言語である PHP と並んで、これまでインターネットの世界で多く採用され、その歴史を支えてきた言語であり、強くリスペクトしています。

イベント概要については、以下をご覧ください。

イベント概要

f:id:serimaryo:20180123120520p:plain

イベント名 : YAPC::Okinawa 2018 ONNASON

概要 : YAPCはYet Another Perl Conferenceの略で、一般社団法人 JPAが主催する、Perlを軸としたITに関わる全ての人のためのカンファレンスです。

日時 : 2018 年 3 月 3 日(土)

会場 : 沖縄科学技術大学院大学 OIST

公式 HP : http://yapcjapan.org/2018okinawa/

yapcjapan.org

Google オフィスで GCP ハンズオンを開催していただきました

こんにちは。エンジニア兼技術広報の @serima です。 GameWith では外部から講師をお招きして勉強会を行うということを定期的に行っています。

今回はなんと Google 様による GCP のハンズオン込みの勉強会でした。 GameWith のエンジニア陣が Google のオフィスに招待され、さらにランチまでご馳走になってしまうという展開になり、とてもありがたく、美味しい勉強会となりました。

同じビルにオフィスがあるため、すぐに到着できるだろうという目論見でしたが、思っていた入口から入れずタイムロスしてしまいました…申し訳ありません!

無事に合流し、早速会議室にご案内していただいたのですが、各所に遊び心が垣間見える素敵なオフィスでした。

Google Cloud Platform ガイダンス

まずは双方でご挨拶、簡単に自己紹介を済ませたあと、GCP の概要をご説明頂きました。

  • 開発者はインフラから解き放たれて、アプリケーションに集中できるようにする
  • 地球規模 (Planet Scale) のインフラを目指す
  • 2015 年頃から技術を公開して世界のエンジニアにイノベーションを起こしてもらうのを狙うようになった = Philosophyの 180 度変更
  • GCP のネットワークは AWS と大きく異なる
    • 自社でネットワークを持っているので、リージョンを跨いでの構築がしやすいのが AWS との違い
    • 後発のため、プライスリーダー戦略をとっているが、「個人開発者もエンタープライズも等しく Public Cloud を利用できるべき」という Philosophy でフラットに対応を行っている
  • プレウォーミング不要
  • 単一の IP Anycast で最適なリージョンに振り分けを行ってくれる
  • 全て自社の専用線を引いているため、遅くならない。YouTube は海外から配信している
  • GAE はデプロイからの立ち上がりが早い
    • Go はとにかく早い
    • 言語ごとの比較だと Go > Python, PHP >> Java
  • 他社事例
    • 導入するまではやり方に慣れるという意味で大変だったが、リリース後にインフラに関して何もしなくて良くなった
    • インフラのやり方を忘れてしまった by 中の人
  • ライブマイグレーション = 計画停止なし
    • IaaS の再起動祭りがなくなる
    • 切り替わりはあるが、ログを見ないと気づかないレベルで高速。
  • リザーブドインスタンスのようなものはあるが、インスタンス単位ではなくコアとメモリ単位で購入できる
    • x 年後に「このマシンじゃ非力で使えない」や「ビジネス要件的にそのときに必要なインスタンスタイプとマッチしない」ということがないように
    • マシンが利用状況に合ってないとアラートが出る(オーバースペックな場合など)
    • ユーザーから「これ出していいの?(Google さん損じゃない?)」と言われてしまう
  • 質問
    • ライブマイグレーションに関して、ハードウェア障害の時はどうなるか?
      • 計画停電と同様に、自動で対応されるが、計画停止時よりは長くなってしまう。

Google の内部で運用されていた環境をサービスという形で外に出していくという方針に切り替わったのはかなり大きいな、と感じました。 尋常ではないトラフィックをプラネットスケールで受けている実績が既にありますので、非常に安心感があります。 また、印象的だったのは、カスタマが何か能動的にアクションせずとも、請求時に自動で利用料金が割り引かれたり、オーバースペックだった場合にアラートを出してくれるなどの対応です。 リザーブドインスタンスなどの前払いでインスタンスタイプを予約する契約については、一定のリスクがあることについてこちらで言及しており、納得感があります。

午前の部はここで終了し、ランチにお誘いいただきました!

Break time

f:id:serimaryo:20171228132228j:plain

レストランに向かう途中のカフェスペースからの眺め。Google の次の渋谷オフィスが見えました!

f:id:serimaryo:20180105173116j:plain

Reserved のプレートに GameWith と入っており、おもてなし力の高さに感動しました…

f:id:serimaryo:20171228124013j:plain

いただきます!

弊社の開発チームやシステム構成、デプロイ体制をはじめ、Google 社での開発やオフィスについて、ざっくばらんにお話しました。 (カレーが美味しいという噂を耳にしたので頂いたのですが、本当に美味しかったです…!)

ランチのあとは、カフェスペースでコーヒーやお菓子をいただき、リラックスしたムードでハンズオン開始!

Google App Engine ハンズオン

シンプルな Python アプリケーションを各々構築し、App Engine を利用してインターネットに公開してみるという内容でした。

弊社のアーキテクチャにおいて、アプリケーションサーバのオートスケーリングをより最適化したいと常に考えており、折角の機会ということで GAE のスケーリングについて学びたいというリクエストをしておりました。

f:id:serimaryo:20180105172706j:plain

  • Google Cloud Shell
    • ブラウザから直接クラウドリソースにアクセスできるシェル
    • dashboard の右上のアイコンからログインできる
  • StackDriver
    • 監視、ログ、デバッグ、パフォーマンス、エラーレポート
  • リアルタイムデバッグ
    • 本番環境で stack trace を実現できる
  • バージョンコントロール
    • 任意のバージョンを 100% → 30%, 30%, 40% のような形で割合指定で露出できる
    • ファイアーウォール機能も最近つくようになった
      • ので、全世界に公開せず開発環境でバージョン切り替えて試したりもしやすくなった
      • この機能は以前から各方面から要望があったので、非常にホット
  • インスタンスのオートスケーリング
    • 完全オート、上限ありオート、マニュアルがある
    • automatic_scaling: 細かいトラフィックを大量にさばく
  • basic_scaling: 最大のインスタンス数を事前に設定
  • manual_scaling: 手動でインスタンスの数を決める
  • アクセスが落ち着いた後にどのくらいの速さでインスタンスを減らすかも設定で調整できる
    • 特に Go だと即時インスタンスが立ち上がるので、アクセスが少なくなったらすぐ台数を減らす設定にしておくとよい

エンドポイントに対して定期的に curl しながら、トラフィック分割設定で割合を切り替える瞬間の video です。

Hello World! が 100 %稼働している状態から、Hello Google! のバージョンを 30 %にしている場面。

Hello Google! が 30 %稼働している状態から、Hello Google! のバージョンを 100 %にしている場面。

GUI からワンクリックで、かつ瞬時に切り替わりを体感でき非常に興奮しました。ロールバックについても同様で、すぐに切り戻すことが可能です。

GUI から様々なことが簡単にでき、便利さを実感しました。 なかでも本番のコードに直接 Break point を設定して、ユーザが次にそこを通ったタイミングで stack trace を追えるというのは本当にすごいな…と思いました。

環境要因(主にデータ起因)で、なかなかローカル環境で再現が難しいバグなどもこれを使えれば特定がかなり容易にできるようになります。(現在は PHP は非対応とのことでした)

BigQuery のデモ

弊社ではすでに BigQuery を使用していますが、さらに使いこなしていきたいという思いから今回は事前にリクエストしていました。

  • Google は大量のデータがあったのでビッグデータは昔からやってた
  • Google が使ってよかったものが論文で外に出てオープンソースになったり GCP で提供されたりしてる
    • MapReduce + GFS => Apache Hadoop => Cloud DataProc
    • Dremel => Apache Drill => BigQuery
    • FlumeJava, MillWheel, Dataflow => Apache Beam / DataflowSDK => Cloud Dataflow
  • Dataflow = Apache Beam というプログラミングパラダイムのマネージドな実行環境
    • DataProc、AWS EMR と比較すると立ち上げが高速
  • データ分析系サービス一覧
    • BigQuery
    • DataProc
    • Dataflow
    • Datalab
    • Data Studio
    • Dataprep
  • BigQuery は DWH
  • fluentd から streaming insert で BigQuery に流せる
  • デモ
    • 生成したログを fluentd へ流して、BigQuery に streaming insert するデモ
    • ログ生成で使った gem パッケージ:
    • streaming insert したデータはリアルタイムで BigQuery の WebUI の preview には反映されない(少しラグがある)
    • streaming insert は有料なので、使い分けるのがベストプラクティス
      • 即時性を求められるデータ: streaming insert
      • 即時性を求められないデータ: 日次のバッチなどで対応
  • デモ 2
    • Dataprep
      • Dataflow の GUI コードビルダーのようなもの
      • 裏で使われる Dataflow に料金が発生し、Dataprep の使用自体は無料
      • 任意のデータソース(国が発行するフォーマットが揃っていない CSV など)を GUI で整形して BigQuery に流せる

Dataprep / Dataflow はとても革命的だな…と感じました。

今までだといったんデータソースをダウンロードしてきて、ローカルでデータを整形して再度 BigQuery に入れるということをしていましたが、その手間がゼロになると思うと胸熱です。

定形作業が一切不要になりますし、しかもそれが GUI で操作できるので、プログラマ以外の方にも使ってもらえるという点で、用途が一気に拡がりそうです。

デモをしていただいた後、社内のカフェにもご案内頂いたのですが、 レストランとはまた別の場所にあり、最早ここにないものはないのでは…と思いました。

自由にドリンクをオーダーして良いとのことで、弊社メンバー皆コーヒーを頂いてしまいました。ありがとうございます!

f:id:serimaryo:20180105173703j:plain

帰り際、Google カレンダーを模したリアルな Google カレンダーを頂いてしまいました!

非常に可愛く、早速愛用しています!

f:id:serimaryo:20171228152355j:plain

まとめ

Google の内部で培った知見を外部に公開し、社外でのイノベーションを狙っていくという Philosophy に感銘を受けました。 また、エンタープライズも個人開発者も等しく扱うというスタンスは、ある意味とても Google らしく、いちデベロッパとして好感でした。

「巨人の肩に乗る」というメタファがありますが、ユーザに対して真に価値を届けるために、ビジネスのコア以外を積極的にアウトソースしていく事は、限られたリソースを有効に活用する手段だと思います。

適切な箇所で GCP を利用することで、より早く、より良いサービスをユーザに提供することができるように、検討と実験を経てプロダクションで運用できるように推進していきたいと思います。

あらかじめリクエストしていた内容をハンズオンに盛り込んで頂いたことで、非常に身のある濃い時間となりました。 Google の皆様、本当にありがとうございました!

f:id:serimaryo:20180105172847j:plain

エンジニアブログ ブログプラットフォーム/CMS 別まとめ

エンジニア兼技術広報となりました @serima です。

GameWith では去年の 12 月から技術ブログを始めました。

その際、検討事項として

  • タイトルは何が良いか
  • URL は何が良いか
  • どこのブログプラットフォームを使うのがよいか

等が挙がりました。

他社のエンジニアブログとそのブログプラットフォームと CMS について調査したので、せっかくなので共有します。

ブログプラットフォーム観点でまとめられているものは、自分が探した限りでは見当たりませんでしたので、何かの参考になればと思います。

拾いきれていないものもありますが、他意はありませんのでご容赦ください!(こっそり教えてください…)

なお、すべて順不同です。

日本国内

はてなブログ

会社名 タイトル URL
ガイアックス Gaiax Engineers' Blog http://gaiax.hatenablog.com/
コネヒト コネヒト開発者ブログ http://tech.connehito.com/
クックパッド クックパッド開発者ブログ http://techlife.cookpad.com/
BASE BASE開発チームブログ http://devblog.thebase.in/
はてな Hatena Developer Blog http://developer.hatenastaff.com/
VASILY VASILY DEVELOPERS BLOG http://tech.vasily.jp/
メルカリ Mercari Engineering Blog http://tech.mercari.com/
Fablic inFablic | Fablic, inc. Developer's Blog. http://in.fablic.co.jp/
UZABASE UZABASE Tech Blog http://tech.uzabase.com/
KAYAC KAYAC engineers' blog http://techblog.kayac.com/
pixiv pixiv inside http://inside.pixiv.net/
Cybozu Cybozu Inside Out | サイボウズエンジニアのブログ http://blog.cybozu.io/
Gunosy Gunosy テックブログ http://tech.gunosy.io/
mixi mixi engineer blog http://alpha.mixi.co.jp/
クラウドワークス クラウドワークス エンジニアブログ http://engineer.crowdworks.jp/
dely dely engineering blog http://tech.dely.jp/
ぐるなび ぐるなびをちょっと良くするエンジニアブログ http://developers.gnavi.co.jp/
Chatwork ChatWork Creator's Note http://creators-note.chatwork.com/

WordPress

会社名 タイトル URL
Cygames Cygames Engineers' Blog http://tech.cygames.co.jp/
クラスメソッド Developers.IO http://dev.classmethod.jp/
MoneyForward Engineers' Blog | マネーフォワード エンジニアブログ https://moneyforward.com/engineers_blog/
GREE GREE Engineers' Blog http://labs.gree.jp/blog/
DMM.com ラボ ツチノコブログ http://tsuchinoko.dmmlabs.com/
VOYAGE GROUP VOYAGE GROUP techlog http://techlog.voyagegroup.com/
ランサーズ ランサーズ(Lancers)エンジニアブログ https://engineer.blog.lancers.jp/

Medium

会社名 タイトル URL
FiNC FiNC Engineering Blog https://medium.com/finc-engineering
Eureka Eureka Engineering https://medium.com/eureka-engineering

自前・不明

会社名 タイトル URL
CyberAgent CyberAgent Developers Blog | サイバーエージェント デベロッパーズブログ https://developers.cyberagent.co.jp/blog/
SmartNews SmartNews Engineering Blog https://developer.smartnews.com/blog/
Google Japan Google Developers Japan https://developers-jp.googleblog.com/
LINE LINE Engineering Blog https://engineering.linecorp.com/ja/blog
dwango dwango エンジニア ブロマガ http://ch.nicovideo.jp/dwango-engineer/blomaga
DeNA DeNA Engineers' Blog [ Technology of DeNA ] http://developers.mobage.jp/blog/
Yahoo! Japan Yahoo! JAPAN Tech Blog https://techblog.yahoo.co.jp/

海外

会社名 タイトル URL プラットフォーム
Slack Several People Are Coding https://slack.engineering/ Medium
Pinterest Pinterest Engineering https://medium.com/@Pinterest_Engineering Medium
Instagram Instagram Engineering https://engineering.instagram.com/ Medium
Spotify Spotify's Engineering and Technology Blog https://labs.spotify.com/ ワードプレス
Uber Uber Engineering Blog https://eng.uber.com/ ワードプレス
Facebook Engineering Blog https://code.facebook.com/posts/ 自前
Twitter Engineering https://blog.twitter.com/engineering 自前
GitHub GitHub Engineering | The Blog of the GitHub Engineering Team https://githubengineering.com/ 自前

(Slack のブログタイトルが「Several People Are Coding」というのが洒落がきいていて個人的にはとても好きです...)

まとめ

日本国内だとはてなブログ、海外だと Medium を利用している会社が多い印象です。

ちょうど調査をしている頃に、はてなブログの SSL 化へのマイルストーンが公開されたこともあり、弊社でははてなブログを利用することとしました。

エンジニアブログの界隈はすでに大いに盛り上がっておりますが、新参者の GameWith も引き続きコツコツと頑張ってまいりたいと思います。

PHPerKaigi 2018 にスポンサーとして協賛します

GameWith は PHPerKaigi 2018 にプラチナスポンサーとして協賛します。

PHP の大きなカンファレンスといえば、もちろん全国各所で開催される PHP カンファレンスが思い浮かびます。

しかし、今回の PHPerKaigi はチケット販売制いうことで、より質の高いイベントになるのではないかという期待と、PHP のコミュニティ発展に貢献したいという思いから協賛を決定いたしました。

弊社のエンジニアももちろん参加いたしますので、ぜひ会場でお会いしましょう!お気軽にお声がけください!

イベント概要については、以下をご覧ください。

イベント概要

f:id:serimaryo:20180115215750p:plain

イベント名 : PHPerKaigi 2018

概要 : PHPerKaigi(ペチパーカイギ)は、現在PHPを使用している、過去にPHPを使用していた、これからPHPを使いたいと思っているエンジニアが、技術的なノウハウを共有するためのカンファレンス(イベント)です。

日時 : 2018 年 3 月 9 日(木), 10 日(金)

会場 : 練馬区立区民・産業プラザ Coconeriホール

公式 HP : https://phperkaigi.jp/2018/

phperkaigi.jp

InVision謹製、DSMこと「DesignSystemManager」を使ってみて

 GameWith デザイナーの @guchitaka_ です。Web からアプリまで諸々デザインに携わらせていただいております。 inVision が2018年1月提供予定の DSMこと「DesignSystemManager」の EarlyAccess が出来るようになったので早速使ってみました。

www.invisionapp.com

InVision「DesignSystemManager」について

はじめに、そもそもデザインシステムとは

組織におけるデザインの共通言語となるものです。

従来はスタイルガイドやUIキットを作り、それを関係者が参照するような形で組織のデザインを制御していました。しかしながら少しでも更新が滞ったりすると参照する意味がなくなり、死んだガイドラインとなった経験をされた方も多いのではないでしょうか。メンテナンスにかけるコストも馬鹿にならなく、ガイドラインの整備に追われて作る時間がとれず本末転倒になる場合もありました。

デザインシステムはこれを解決するもので、それ自体が各プロダクトにエコシステムを提供するプロダクトとして運用されるというものです。

今回は InVisionDSM について言及するので詳しい説明は割愛します。

このあたりに詳しく書いてあります

InVision DSM で出来ること

  • スタイルやシンボルのバージョン管理
    • Color
    • Text Styles
    • Layer Styles(現在は項目だけ存在)
    • Icons
    • Components(Artboardも出来ます)
    • Fonts
  • Team 管理
  • DesignToken の出力

目次

  • 導入
  • 実践
  • バージョン管理
  • 出力
  • まとめ

導入

Early Access を申請されていた方はメールが届いているかと思いますので指示に従い導入します。 大まかな手順は以下の通りです。

  • 「CraftManger」をインストール(既にインストール済みの場合は一度アンインストール)
  • Organizations 作成
  • Libraries 作成

InVision DSMにアクセスすると以下のような画面が表示されます。

f:id:guchitakas:20171225183053p:plain

今回は適当な Library を作成します。

f:id:guchitakas:20171225183036p:plain

詳しくは以下を参照してください。

support.invisionapp.com

実践

Library の作成と CraftManager の準備が整ったところで実際にDSMを使ってみましょう。

まずは適当なアセットを用意します

Icons と Components は実際の運用を想定して Symbol 化しています。

f:id:guchitakas:20171225185804p:plain

次にDSMのパレットを開いて追加します。

CraftManager のツールバーに六角形のアイコンがあるのでクリックします。 まだ何も追加していないので No Hoge...と表示されるはずです。

f:id:guchitakas:20171225190042p:plain

次に、追加したいアセットを選択して「+」を押します

追加したいアセットを選択して、DSMのパレット右下にある「+」ボタンを押します。とても簡単でありがたいです。 パレットを見ると追加されているのが確認できます。

※ Layer Styles も表示されていますが、EarlyAccess版では未実装のようです。

追加したアセットのSketch 上での見え方

各アセット毎に分けられて表示されています。 階層を切れるので、役割ごとにグルーピングできるのは嬉しいですね。

Colors

f:id:guchitakas:20171225190505p:plain

Text styles

f:id:guchitakas:20171225190518p:plain

Icons

f:id:guchitakas:20171225190531p:plain

Components

f:id:guchitakas:20171225190543p:plain

Web上 での見え方

Colors

RBG/HEX/HSL/HSV が取得できるようです。

f:id:guchitakas:20171225190810p:plain

Text styles

Paragraph の設定は取得できないようです。 可能であれば TextColor も HEX などで見られると嬉しいですね。要望出しておきました。

f:id:guchitakas:20171225190857p:plain

Icons

Icon のダウンロードはここからは出来ません。後述する DesignToken から得られます。

f:id:guchitakas:20171225190907p:plain

Components

f:id:guchitakas:20171225190934p:plain

Fonts

f:id:guchitakas:20171225190945p:plain

アセットを利用する

使い方は簡単、Icon や Component の場合はパレットからドラッグ&ドロップで配置するだけ。 Color や TextStyle の場合は反映したいオブジェクトを選択してパレット内のスタイルをダブルクリックします。

f:id:guchitakas:20171225192306p:plain

アセットを更新する

オブジェクトを選択してパレット内の「+」ボタンを押すとアセットが更新できます。 変更点がダイアログで表示されますので、新規作成か更新を選んでください。 尚、Symbol Override も引き継ぐようですので、更新の際はご注意を。

f:id:guchitakas:20171225192604p:plain

アセットの更新を受け取る

異なるファイルで同じ Icon を DSM からドロップして配置しています。

f:id:guchitakas:20171225194041p:plain

DSM パレットの「↓」アイコンを押すと、ファイル内のアセットに変更内容が反映されます。とても楽ですね。

f:id:guchitakas:20171225194551p:plain f:id:guchitakas:20171225194107p:plain

バージョン管理

まずはバージョンをリリースします

Library 名 をクリックして「Release new version」を選びます。

f:id:guchitakas:20171225194632p:plain

Version 名と Description を求められるので入力して「Create Version」を選びます。 これで作成完了です。

f:id:guchitakas:20171225194644p:plain

バージョンを変更するには

先と同じように Library 名 をクリックして「Switch Version」を選びます。

f:id:guchitakas:20171225194655p:plain

バージョンの更新を共有するには

バージョンの更新だけでは不十分ですよね、それを関係者に共有する必要があります。 Web 版の DSM を開き画面右上の「Share」を押すとURLが出力されるので活用しましょう。

なお「Share」しなくてもDSMを開いた際には、更新された旨が通知される安心設計です。

f:id:guchitakas:20171225195202p:plain

出力

この機能が InVision DSM の真の価値ではないでしょうか、なんと DSM は Design Token の出力に対応しております。 DesignToken が唯一の正しいデザイン(Single source of truth)として機能し、各プロダクトで一貫性のあるデザインを提供できるようになります。

実際に出力する

Web 版の DSM 右上にあるアイコンをクリックします。

f:id:guchitakas:20171225195255p:plain

DesignToken が出力され、取得できるようになります。 対応形式は以下の通りです。

CSS/Sass/Less/Stylus/XML/JSON/YAML/Android/iOS

アイコンなども Resouces として取得できるようですが、余白として設定した透明ピクセルをカットされてしまうので現状はまだ使えません。

f:id:guchitakas:20171225195308p:plain

まとめ

スタイルガイドの作成やデザインのチーム内での共有、Artboardもシンボル化せずに登録できるため、画面単位での共有もできると、非常にありがたみを感じます。 そしてとどめの DesignToken ... SalesForce も採用していますが、これは可能性しか感じません。 ちょうど DesignSystem の構築を考えているところなので、GameWith でも導入を検討したいところです。

参考文献

www.invisionapp.com support.invisionapp.com Designing a Design System // Speaker Deck

CircleCI 2.0 の resource_class で CPU と RAM のリソースを変更してみる

メリークリスマス! @serima です。 いかがお過ごしでしょうか。皆さまのサンタクロースは価値をデリバリしてくれましたでしょうか?

さて、GameWith では CI のツールとして CircleCI を使用しています。 2017 年 7 月頃に CircleCI 2.0 が正式にリリースされ、GameWith でも 2.0 への移行を既に済ませています。(移行作業についてはまた別途記事を書くつもりです。)

移行作業時にドキュメントを読んでいると、resource_class という設定が新たに増えていることに気付きました。

今回は、 resource_class を利用するまでの流れと、参考までに行なったベンチマーク結果をお届けします。


2018/08/14 追記

以前は、サポートチケットを切ると暫定的に resource_class が有効になると書きましたが、2018 年 8 月現在、新たに Performance pricing plan という有料課金プランが用意されたようで、そちらに切り替えないと利用できないそうです。

こちらの記事に詳しく書かれておりますので、利用の際は参考にしてみてください。

qiita.com


resource_class とは?

下記、抜粋しましたが、詳細はこちらのドキュメントをご覧ください。

It is possible to configure CPU and RAM resources for each job as described in the following table. Note: Paid accounts must request to use this feature by opening a support ticket (or by contacting their Customer Success Manager when applicable) and non-paid users must request to use this feature by opening a ticket at https://support.circleci.com/hc/en-us/requests/new. If resource_class is not specified or an invalid class is specified, the default resource_class: medium will be used. The resource_class key is currently only available for use with the docker executor.

f:id:serimaryo:20171221132434p:plain

(現時点では)docker executor のみで使用できるリソースクラスを変更するための key で、カスタマーサクセスマネージャーにサポートチケットを切る形でリクエストしないと使用できないとのこと。 おそらくユーザ、オーガニゼーション単位でホワイトリストが存在し、そこに追加してもらうことで機能が利用できるようになるのだと思います。 また、デフォルトでは medium class として動作しているようです。

利用するための手続き

GameWith は Paid account なので、使ってみたい旨を簡単に記載して support@circleci.com にメールを送ってみました。

Hi.

Our Organization GameWith uses a CircleCI paid plan.
I found about resource_class in the document, can you add our team to the whitelist?
I hope to improve the build execution further.

Thanks.

しばらくすると、返信が来ました。

Hi Ryo,

I've enabled configurable resources for your org `GameWith'. Keep in mind this is a premium feature of CircleCI 2.0, while we aren't charging for this feature now, we do plan on doing so in the near term.

Best,

-Jia

これで、機能が利用できるようになりました。

しかし、

Keep in mind this is a premium feature of CircleCI 2.0, while we aren't charging for this feature now, we do plan on doing so in the near term.

利用される方は注意が必要です。 この機能は、CircleCI 2.0 のプレミアム機能で、近い将来課金する予定があるとのこと。

xlarge class を利用し続けていたら、気付いたら課金されていた。など、そういったことが発生するかもしれません。(無論、事前アナウンスはあると思いますが…)

また、ハイスペックなリソースを前提とした CI 周りを構築してしまうのもリスクではあると思いますので、各自で塩梅を確かめながらご利用いただけると良いのかなと思います。

実際に試してみる

.circleci/config.yml に下記一行を追加するだけです。

resource_class: large

今回は UnixBench を使用してお手軽にベンチマークをとってみたいと思います。 UnixBench のベンチマーク項目については、こちらが詳しいです。

blog.idcf.jp

今回はあくまでも各 resource_class での比較を行いたかったため、実際のスコアがいくつになったというよりもデフォルトの resource_class である medium よりもどの程度良いかの比較に意味があると考えています。

UnixBench のインストールと実行

普段 CI に使用している Docker image は Ubuntu 14.04 をベースにしたものをカスタムしており、その過程で apt-get install build-essential を行っているので、特に事前にインストールしておく必要があるパッケージやライブラリはありませんでした。(本来であれば、その手順が必要のはずです。)

$ git clone https://github.com/kdlucas/byte-unixbench.git
$ cd byte-unixbench/UnixBench
$ ./Run

ベンチマークの結果

CPU と RAM の増加によって、パフォーマンスの向上は見られますが、想定していたよりも比較的緩やかな傾きとなった印象です。 ベンチマーク自体は一度しか実行していないため、多少の誤差はあるかもしれませんが、グラフとしては綺麗に右肩上がりにはなりました。

f:id:serimaryo:20171225171950p:plain

なお、結果のログは以下 gist においておきましたのでご参考までにどうぞ。 (ホストマシンのコアの情報を後半コピーし忘れてしまいましたが、すべて同じ Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz の 32 core でした)

[CircleCI 2.0] resource_class ごとの UnixBench の結果 · GitHub

まとめ

上記の比較結果は、どの resource_class を利用するかで料金が変わるなどの場合に、コストパフォーマンス比較の参考としてご利用頂ければと思います。

GameWith では CI に限らず人の手が不要な所は、積極的に自動化・省力化を行なっています。

あらゆるプロセスにおいて、改善できる余地はないか考えつづけ、引き続き発信を行っていきます!