RubyKaigi2017 速報!! (2日目)

ちょっと遅くなりましたが、2日目の速報をドラゴンズファンの西岡(@nisshiee)からお送りします!

広島カープさん、優勝おめでとうございます。でも僕は心からドラゴンズを愛しているので、ハイタッチは頑なに拒否していましたすみません。 2日目はドラゴンズ愛を表現するためにドラゴンズのユニフォームでRubyKaigiに出席しました(会場に向かって歩いてるとき、やたら視線を受けていた気がします)。

f:id:nisshiee:20170920091040j:plain

さて、今日は「Ran」会場で、Workshopが開催されたのでこちらをレポートしようと思います。

PyCall Lecture

まずは弊社R&Dグループより@mrknより、PyCallのワークショップを開きました。 ワークショップの内容はこちらにJupyter notebookで公開されていますので、ワークショップを見逃した方や復習したい方はぜひ。

f:id:nisshiee:20170920091548j:plain

PyCallはRubyプロセス内にPythonをbindingし、RubyコードからPythonのオブジェクトを操作できるようにするライブラリです。 ワークショップでは、実際にPyCallでPythonオブジェクトを操作しながらPyCallの仕組みを学び、最後にPythonで使われているデータサイエンスや機械学習のライブラリをRubyから使ってみました。

「PythonにはC APIがあるので、これをRubyからbindingしてやれば、RubyのコードからPythonを動かせる」とは言っても、Rubyでコーディングする「楽しさ」や「気持ちよさ」を損なうことなく、かつ実用に耐えうる言語間連携を実現するためには、大小様々な課題があったはずです。本ワークショップでは、そのような課題をどうやって解決してきたか、その一部を見ることができました。(しかし、あれは氷山の一角で、実際にはもっとたくさんいろんな苦労や工夫があるんだろうなぁ・・・)

ところで、このハンズオンでは「何を」やっていたの?

途中でirisデータなるものを使ってごにょごにょやっていた箇所がありました。もしみなさんが機械学習などの分野の知識や経験を既にお持ちであれば、あの手順で何をやっていたか把握できたかと思うのですが、そうでなければ、「確かにPython動いてそうだけど、何やってるかわからん」と思われたかもしれません。そこで、本記事で簡単に解説をしたいと思います。

「iris」は日本語で「アヤメ」のことです。そしてやりたいことは、アヤメの花を観測して、品種を当てることです。

今回使用したデータは、150の、既に品種がわかっている個体について、「花びらの長さ」「花びらの幅」など4箇所を事前に測ったデータになります。このデータを学習させることで識別モデルを作り、「品種が未知の個体も、同じ箇所を測って数値を識別モデルに投入すれば、計算機が品種を判定してくれるよ!」という状況を作りたいわけです。

今回はデータが予め用意されているけども・・・

もし実用の場面で、識別器をゼロから(データ集めから)作ろうと思ったら以下のような課題があります。

  1. どこを測れば、品種判定に有用なデータとなるかわからない(あなたが植物学者でない限り)
    • 特に伝統的な機械学習の手法では、結局のところ「どこを測るか」が最も精度に影響する部分だったりします
  2. 実際に、品種がわかってるアヤメの個体をたくさんあつめて1つずつ測ってデータを取るのは大変
  3. 通常、実用の世界ではもっと多くのデータを扱うので、「試しに学習させて識別モデルをつくってみる」のに数時間から数日といった長い計算時間がかかる

そこでまずは1の課題を解決したいのですが、2、3の事情があるので、「実際に学習させてみて精度をみてみる」というやり方は非効率的です。ですので、簡易的に「この計測ポイントは有用か」を判定できると嬉しいということになります。

そして、よく行われる「簡易的な判定」の手法が、「主成分分析(PCA)を行って、データの分布を目視してみる」という方法です。

PCAして、目視?

例えば今回のデータのように、4箇所の長さを計測したとすると、各々の個体について4つの数値が得られます。これを並べると4次元ベクトル(特徴ベクトルと呼びます)ができます。つまり、150の個体を観測すると、150の点が4次元座標空間(特徴空間)内に分布することになります。

f:id:nisshiee:20170920093248p:plain

特徴ベクトルが、左の図のように、同じ品種のものが近くに固まり、品種間で離れているような分布をしている場合、識別の精度が高くなります。逆に右の図のように、違う品種であっても分布が重なっているような場合は、品種を判定するのに必要な特徴を抽出できていないと言うことができます。

さて、上の図は模式的に4次元空間を表現しましたが、実際には4次元空間を紙やディスプレイに表示することはできません。そこで、「4次元空間上での分布の様子を極力維持したまま2次元に次元削減する」ことによって擬似的に4次元空間での分布の様子を目視できるようにしてやります。この手法が「主成分分析」と呼ばれる手法、ということになるわけです。

ワークショップのnotebookに戻って

というわけで、ワークショップでは、

  • 「アヤメの花の特定の部位の長さを計測して、アヤメの品種を特定する」ということをやりたいのだけど、その事前検証として、「本当にこの4箇所を測れば品種を特定できそうか」を、PCAで2次元に落として目視してやることによって確認する

ということをやっていたのです!

f:id:nisshiee:20170920091829p:plain

そしてこちらの結果をみると、色分けした3品種がほぼ重なることなく分布していますね。なので、今回の例では、「どうやら計測する箇所はこの4箇所で問題無さそうだ」ということが解って、めでたしめでたし、という結果になりました!

Getting started to Red Data Tools project

さて、PyCallによって、RubyからPythonオブジェクトを操作することができるようになったのですが、Pythonの肩に乗ってRubyでデータ分析を行うためにはもう一つ課題があります。それがデータ変換のコストです。

PyCallではRubyのFloatやArrayといったオブジェクトをPythonに持っていくときにPythonのfloatやlistに暗黙的に変換してくれますが、データが巨大になればその変換コストは膨大なものになります。この問題はRuby-Python間だけで起こっている問題ではなく、他言語間であったり、言語は同じでも複数のライブラリを連携させる場合にも発生します。

そこでこの課題に対する解決策として「そもそも言語やライブラリを超えても同じメモリ空間を参照し、そこに共通のフォーマットでデータを置けばいいじゃん」という案が提唱されています。そしてその仕様を定義しているのがApatch Arrowです。

ワークショップでは弊社エンジニアの畑中(@hatappi)より、Arrowの説明をし、実際にPythonプロセスとRubyプロセスの間で、データをJSON形式で受け渡しした場合と、Arrow形式で受け渡しした場合とで、速度比較を行いました。

f:id:nisshiee:20170920091748j:plain

実用のためにはまだまだ作らなければならないものがたくさんあるというのが現状のようですが、「だからこそみんなで作っていこうよ」という須藤さん(@ktou)のメッセージとともにワークショップの締めとなりました。Red Data Toolsのポリシーはぜひ一度読んでいただきたいです。

さいごに

というわけで、RubyKaigi2017も残り1日となってしまいました。
ラストは天野(@pataiji)よりお送りします!お楽しみに!

RubyKaigi2017 速報!! (1日目)

f:id:selmertsx:20170919020509j:plain

こんにちは。開発基盤部兼ヌリカエエンジニアの森岡です。

カープ優勝で沸き立つ広島から、RubyKaigi 2017の1日目の様子をお知らせさせて頂きます!

Money Forward さんによるスポンサーセッション

最初のセッションは Ruby Kaigiのスポンサーをされている Money Forwardさんから。 Money Forwardさんは、卜部さん、松田さん、金子さんと3人も Ruby Committerがおられることで有名な会社ですね! Money Forwardさんでは、そのような Ruby Committerの方々から Ruby を学ぶことができる環境を整えておられるようです。うらやましい!

明日、2017年9月19日に重大発表があるとのことなので、皆様楽しみにしていましょう! あと福岡に支社を作るとの発表も!採用も頑張っているとのことですので、福岡のRubyエンジニアの方、よかったらお話しを聞かれてみてはいかがでしょうか?

Keynote ゆるふわRuby生活

RubyKaigi 1日目のkeynoteは、salesforceでフルタイムRuby Committerをされている中田伸悦さんからでした!

発表では、Rubyの開発で使っているツールや、Ruby Committerのコミュニティ、Ruby の build方法から、直近見つけた面白いissueについてお話しされていました。 取り扱ったissueについては、下記の2点になります。

[ruby-list:50578] [質問] 変数pが定義されている時のabsの動作について Feature #13812: Refinements で定義した to_s を String interpolation が呼んでくれない - Ruby trunk - Ruby Issue Tracking System

上記 issueの原因や対処方法をRubyのコードベースで説明されていました。 ゆるふわというタイトルでしたが、Rubyの内部実装にまで踏み込んだ、見ごたえのあるセッションでした!

API Development in 2017

2つ目のセッションは、Drecomのonkさんから、Rubyでの Web Application開発におけるAPI開発のお話しでした! API開発におけるこれまでの歴史から、これからの未来のお話しを、自社でのAPI開発を交えてお話しをされていました。

ドリコムでは、ソーシャルゲームを開発しているため、Rubyを書いているServer Engineerと、 C++やC#を扱っている Client Engineerの方がおられます。 双方のエンジニアの認識を合わせるために、OpenAPIを利用して Schema First Development な REST APIの設計をしているとのことです。 JSON schemaを書くのは少々ツライところがありますが、ドリコムではYAMLを分割・mergeできるようなツールを作成したとのこと! ツールにはJSON referenceやJSON pointerの概念を利用しているようです。

そして OpenAPIを利用した現在の REST APIから、GraphQLに移行しつつある現在のトレンドをお話しされておりました。

How Close is Ruby 3x3 For Production Web Apps?

3つ目のセッションは、AppFolioよりNoah Gibbsさんから、Ruby on Railsのベンチマークについてのお話しでした。

Ruby 3×3では、Rubyの速度を3倍にする!ということを目標として掲げています。 しかしながら、何をもって3倍とするのかは難しい問題でして、この問題は昨年のRubyKaigiでもお話しがされていました。

Ruby3x3: How are we going to measure 3x? - RubyKaigi 2016

昨年の発表において、warming upが大切というお話しがされましたので、Noahさんはそこを踏まえたベンチマークソフトを作成したとのこと! そのベンチマークを利用して確認したところ、1000 requestのwarming upを行った状態において、ruby 2.0.0 から 2.4.1 で比較すると 150%の速度が見られたようです。また、warming upのために行うrequestの回数も速度に影響を与えるらしく、 十分にwarming upされた web applicationとそうでないものとの間では、同じバージョンのrubyでも5~7%程度の差がみられたようです。

発表資料やベンチマークに利用したコードはこちらで公開されておりますので、よろしかったらご確認ください! How Close Is Ruby 3x3 for Real Web Apps? - Google スライド GitHub - noahgibbs/rails_ruby_bench: A Rails-based benchmark for Ruby development

Gemification for Ruby 2.5/3.0

4つめのセッションは、GMO ペパボのhsbtさんから、Ruby 2.5 / 3.0 における Gemificationのお話しでした。 Gemification というのは、Rubyの Standard Library を、Default gems や Bundled Gemsのように出す取り組みのことです。詳細は下記のURLに書かれています。 StdlibGem - Ruby - Ruby Issue Tracking System

opensslの修正など、リリースサイクルがRubyとは異なる gem に対して、Rubyの開発とは切り分けることによって、下記のメリットを取りに行くことを目的として行っています。

  • openssl等の修正を迅速に行う
  • ruby interpreter developper が、rubyの開発にのみ集中できるようにする

rubyではこの取り組みを進めているとのことですが、fileutilsやfiddleなど、既にrubygemsに登録されているものがあるなどの苦労話や、 ruby 2.5.0における bundler の default gem対応などについて、お話しがありました!

発表資料はこちらになります! Gemification for Ruby 2.5/3.0 - SSSSLIDE

また事前にペパボさんの技術ブログにも投稿されているので、そちらも掲載させて頂きます。 RubyKaigi 2017 に登壇します & GMO ペパボがスポンサードします - ペパボテックブログ

How to optimize Ruby internal.

5つ目のセッションは Ruby Commiterのwatson1978さんから、Rubyの最適化についてのお話しでした。 Rubyの高速化には、速度を計測する、最適化のアイデアを考える、実装するの3つのステップがあるとのことで、それぞれのステップについて詳細にお話しがありました。

まず、速度の計測では、watsonさんは iprofilerとxcodeを利用しているようです。これらのツールはrubyで書いたコードをCレベルでパフォーマンスチェックができるらしくボトルネックの検出にものすごく便利そうな印象でした!

最適化のアイデアを考える方法については、watsonさんが実際に速度を改善した Hash#mergeのPRを例に説明されていました。シンプルな最適化において、基本的にメソッドを探す時間の短縮か、無駄なオブジェクトの生成を行わないようにするという2つの指針で行っていて、Hash#mergeについては、これまではobjectを生成していたものを、objectを生成せずに行うようにしたとのことです。これによって、なんと速度が1.5倍程度まで向上したとのこと!

watsonさんの他の活躍は、下記のURLにてご確認下さい。 https://github.com/ruby/ruby/pulls?page=1&q=is%3Apr+author%3AWatson1978

Development of Data Science Ecosystem for Ruby

f:id:selmertsx:20170918171313j:plain

このセッションは、弊社SpeeeのフルタイムRuby Committerである mrkn (頭に被っているのは弊社のヌリカエというサービスよりヌリカエルくんです)より、Ruby から Python インタープリタを呼び出す仕組みを提供するライブラリである PyCallについて、デモをはさみながらお話しをさせて頂きました! デモの中では、Pythonのライブラリであるseaborn、pandas、kerasをPyCallを使って呼び出すなどしておりました。

発表の中では、Apache Arrow を利用してRuby用のデータ処理ツールを提供するプロジェクトである Red Data Tools Project についても話されました。 Red Data Tools Project はクリアコードのkouさんが主催し、弊社のhatappiも参加しているプロジェクトです。9/19にて、ワークショップも開催しますので、よろしければ足を運んで頂ければ幸いです!

Ruby Committers vs the World

Cookpadの庄司 嘉織さんからの発表から、このセッションがスタートしました。 その中で、Ruby 3×3を強力に進めていくため、CookpadにRubyのCommitter である遠藤侑介さんがジョインされたことが発表されました!

クックパッド、フルタイムRubyコミッターとして遠藤侑介氏を採用 次世代バージョンの中心的機能となるRubyの堅牢性向上に貢献 | クックパッド株式会社

遠藤さんは、Ruby 3の中では型システムの検討を進めていくとのことです。 「Ruby以外に良い言語が出てきたら、Rubyをもっと強くする!」という庄司さんの一言が印象的なお話しでした。

その後、Ruby Committerに対する質問コーナーが始まり、Rubyにおける型注釈に関する Ruby Committerの方々の所感や、右代入など貴重な話を沢山聞ける内容となっていました。特に印象的だったのは Rubyを3倍早くするために、企業からして欲しいことは何か?といった質問に対して、ベンチマークを作って欲しいというお話しと、RubyKaigiを手伝って欲しいというお話しが出たことです。後者については、Ruby開発者がコーディングする時間を作るために、すごくありがたいサポートであるというお話しでした。

以上で、RubyKaigi 2017 の1日目のレポートを終わらせて頂きます! 次回のレポートは、弊社エンジニアの 西岡からお届けさせて頂きます!

RubyKaigi2017 前夜祭を開催しました!in広島

こんにちは、広報の生田です。
全社広報とエンジニア採用広報を担当しています。
RubyKaigi2017に参加するため、前々日から広島に来ていますが台風直撃で凄い雨が降っていました。

そんな台風をもろともせず、RubyKaigi2017前夜祭には多くの方がいらしてくれました!

SpeeeはPre Kaigi Sponsorとして、RubyKaigiのお手伝いをさせていただいています。
8月にはRejectkaigi2017も開催し、RubyKaigiのタイムテーブル徹底解説や、
懇親会でのkamipoさんRailsコミッター就任式など、とても楽しいイベントになりました。
tech.speee.jp 合わせてこちらもどうぞ♪ tech.speee.jp

RubyKaigi2017直前ということで行われたRubyKaigi前夜祭についてレポートします♪
今回の司会は@mrknさんが盛り上げてくれました!

f:id:mogmog2:20170917222331j:plain

広島観光親善大使が登場!!

歓談から始まったRubyKaigi2017前夜祭。
最初に登場して頂いたのは広島の観光親善大使である森田初実さん
f:id:mogmog2:20170920110825j:plain 目的はRubyKaigiですが、せっかく広島に来たので楽しんで帰って頂きたいという思いで、
親善大使から広島の歴史や、見どころ、おすすめの食べ物などご紹介いただきました!!
広島県の名前の由来が太田川の三角州にあったなど、目からうろこの情報が満載でした。

ライトニングトーク

f:id:mogmog2:20170917222439j:plain

「Rails Guides as an OSS Gate」 by @yasulab

speakerdeck.com

@yasulab さんによる発表でした。 OSSに貢献したいけどどうすればいいかわからない、という方は少なくないと思います。 そんなとっかかりとして、ドキュメントの翻訳からはじめてみることを勧められています。 実際にRails Guidesの翻訳からはじめてRubyコアコミッターになった人もいる、という話は、多くのプログラマーにとって鼓舞されますよね。

「How to be a poet and a programmer at the same time」 by @zverok

f:id:mogmog2:20170917222507j:plain @zverok さんによるプログラマーと詩人の関連性についての発表でした。 一見、プログラマーと詩人に共通性は無いと思うのですが、 たとえば、プログラマーは多くのコードを読む、詩人は多くの詩を読むなど、確かに、「うまくなる」ために研鑽することは酷似していることが多いなと感じました。 そして、なによりどちらも「説明書」がないこと、つまりこうすれば「うまくなる」といったことがないので個々人それぞれの裁量に委ねられおり、研鑽次第だと改めて気を引き締めました。

「Ruby と Ruby on Rails で Elasticsearch を使った機能の開発してます!」 by @LicaOka

f:id:mogmog2:20170917222411j:plain @LicaOka さんによるFiNC社が提供しているダイエットアプリの検索システムをSQLベースのものからElasticsearchに移行した、という発表でした。 昨今、多くのWebサービスではElasticsearchベースで検索システムを作られていると思います。 しかし、ユーザ辞書が対応していない、漢字をよみがなで検索できないなどの制約を解決するために、自身でgemを作成し、問題を解決していくところがエンジニアとして見習いたい取り組みだなと思います。

手土産にもみじ饅頭を♪

参加者のみなさまには最後まで楽しんで頂くため、
もみじ饅頭をオリジナルの袋に入れてご用意しました♪
喜んでいただけたようで、とても嬉しいです!

www.instagram.com

まとめ

f:id:mogmog2:20170917222533j:plain

今回は初めてPre Kaigi Sponsorをさせて頂くことになり、 どうやったらRubyKaigiを盛り上げる事が出来るか考えて試行錯誤の連続でした。(特にイベントPMをした中野を労いたい!)
しかし、思い返すとRejectkaigi2017もRubyKaigi2017前夜祭も、多くの方に支えられながら、 手前味噌ですが良いイベントになったと思います。 これらのイベントを通してで少しでも、RubyKaigi2017に向けてワクワク感が増したなら嬉しいなと思っています。

明日からは、いよいよRubyKaigi2017がはじまりますね!
Speeeは今年もブースを出展し、淹れたてコーヒーの提供やオリジナルノベルティの配布を行います。
また、もしかしたら、可愛い何かが居るかもしれません・・・ので、 ぜひお気軽にブースに遊びに来て下さい!! f:id:mogmog2:20170920111555j:plain

また、弊社エンジニアの村田(@mrkn)と畑中(@hatappi)が登壇やワークショップをしますので、 こちらもどうぞ、宜しくお願いいたします!!

rubykaigi.org

rubykaigi.org

Finally we can use Ruby in data science; I will talk about that in RubyKaigi 2017

I’m Kenta Murata, a researcher at Speee Inc.

I released the first stable version, 1.0, of PyCall library a few days ago *1. PyCall provides a mechanism to call Python interpreter from Ruby. Using PyCall, you can use Python’s famous tools for data science from Ruby in a generic way.

In RubyKaigi 2017, that is held on for 3 days from 18th in the next week, I will talk about the current situation of Ruby in data science, and what we should do currently for the future Ruby in data science in the session beginning at 16:40 on the 1st day. The former is mainly PyCall’s explanation, and the latter is mainly the introduction of Red Data Tools project.

Moreover, on the 2nd day, I will organize a workshop named RubyData Workshop in RubyKaigi 2017 in Room Ran at 13:50. This workshop consists of two parts. The 1st part is PyCall Lecture. In this part, I will describe PyCall’s internal and how to use PyCall. The 2nd part is Getting started to Red Data Tools project. This part is presented by Kouhei Sutou and Yusaku Hatanaka *2, which are two of active developers of Red Data Tools Project.

In PyCall Lecture part, you can execute code snippets in the lecture notebook, that is a Jupyter notebook file, step by step. If you want to do so, don’t forget to bring your laptop. The lecture note is a work-in-progress state at the following repository.

If you want to use the lecture note during the course, don’t forget to clone the repository and do rake docker:pull for preparation of the docker image for the lecture.

$ git clone https://github.com/rubydata/rubykaigi2017.git
$ cd rubykaigi2017
$ rake docker:pull

See you soon in Hiroshima!


ついに Ruby をデータサイエンスで使えるようになったので RubyKaigi 2017 で解説します

開発部 R&D グループで研究者をしている村田です。

私が業務で開発している PyCall が先日、安定版のバージョン 1.0 をリリースしました *3。PyCall は Ruby から Python インタープリタを呼び出す仕組みを提供するライブラリです。このライブラリを使えば Python のデータサイエンス用ツールを Ruby から普通に利用できます。

来週18日から3日間で開催される RubyKaigi 2017 では、1日目 16:40 開始の枠で、Ruby におけるデータサイエンスの現状についての解説、および、データサイエンス分野における Ruby の将来のために今何をすべきかを説明します。前者は主に PyCall の解説、後者は主に Red Data Tools プロジェクトの紹介です。

さらに2日目の 13:50 から Room Ran にて、RubyData Workshop in RubyKaigi 2017 を開催します。このワークショップは2つのコンテンツで構成されております。1つ目は、私が PyCall の仕組みと使いかたを細かく解説する PyCall Lecture です。2つ目は、Red Data Tools プロジェクトの中心人物である須藤さんと畑中さん *4 がこのプロジェクトについて紹介する Getting started to Red Data Tools project です。

PyCall Lecture の時間にコンピュータを持参していただければ、手元のコンピュータで Jupyter notebook を動かし、その場でコードを実行して動作を確認しながら講義を受けられます。講義資料は次のリポジトリで鋭意作成中です。

当日のネットワークトラフィックを最小限にするために、事前にリポジトリをクローンし rake docker:pull を実行しておいてください。

$ git clone https://github.com/rubydata/rubykaigi2017.git
$ cd rubykaigi2017
$ rake docker:pull

それでは、広島でお会いしましょう!

*1:The latest version was 1.0.2 when I wrote this entry

*2:Yusaku Hatanaka is a software engineer of Speee Inc.

*3:本記事執筆時点での最新バージョンは 1.0.2 です。

*4:畑中さんは株式会社 Speee のエンジニアです

プロジェクト推進室エンジニアで「Be Docker Day」を開催しました

こんにちは。最近Railsに浮気しているiOSエンジニアの飯田@iida-hayatoです。

先日プロジェクト推進室(以下PJD)*1エンジニアの新しい取り組みとして「Be Docker Day」を開催しましたので紹介させて頂きます。

f:id:tei1988:20170906101457j:plain

Be Docker Dayとは

Be Professional Dayに触発されて「とにかくシステムをDocker化する日」を開催しました。

  • 一日業務を忘れてDockerに取り組む
  • 通称「Dockerになる日」

背景

  • プロジェクト推進室エンジニアはそれぞれ複数のシステムを管理している状態
    • インフラ運用を共通化して引継ぎやすくしたい
  • 管理している中には物理サーバで動いているようなレガシーなシステムもある
    • とりあえず仮想化したい
    • その前にまずはインフラアズコードを実現したい
  • Docker化は優先度が低くなりがち
    • すぐに改善の影響が出ることでも無い
    • まとまった時間が無いと作業できない
    • インフラエンジニアでないととっつきにくい

以上のような諸々の理由でDocker化したいけれど中々時間が取れないですねーという雑談から出た

それならみんなで一緒に一日かけてやればいいんじゃね

という案を元にいろいろ業務調整して実現しました。

目標

  • メンバーが他のプロジェクトへ入った際に、既存システムのDocker化を議論、推進できるようになる
    • Docker化のメリット、デメリットを理解する
    • 作業のボリューム感をつかんで見積もりができるようになる

実施するにあたって何も目標が無いのも微妙なので、上記のような目標を立てて実施することにしました。

ゴール、マイルストーン

  • Docker,Kubernetesの基礎知識
  • 現行システムのKubernetesの設計をする
  • 現行システムのDockerImageを作成する
  • 作成したDockerImageからGCPでシステムを立ち上げてみる
  • Kubernetesで運用のシミュレーションをしてみる
    • インスタインスの追加、削除、Imageの更新

当日にシステム入れ替えまではとても無理なので、目標達成のための糸口を作るという方針です。

また、お互い仕事の机もすぐ近くなので、マイルストーンが最後まで終わらなくても持ち帰って後でフォローアップしていきましょう、という具合のゆるさにしました。

当日やらないこと

  • 実際に環境への適用

プロジェクト推進室のシステムは、各プロジェクトによって業務の繁忙期が違うので 実際の本番環境の入れ替えは個別に調整してやりましょうという方針で進めました。

一日の流れ

Docker,Kubernetesの基礎知識

実際にKubernetesを使ってシステムを構築しているメンバーから説明 f:id:tei1988:20170904141420j:plain 写真は、Dockerの仮想化の仕組みから、Kubernetesの仕組みまで、一通り説明してもらっている様子です。

現行システムのKubernetesの設計をする

実際に稼働しているシステムをどう再設計するかを議論しながら決めていきました。 f:id:tei1988:20170904141448j:plain 写真は、Container毎に複数のPodを作る場合や、複数のContainerを1つのPodにまとめる場合、GCPのCloudSQLを使う場合などの議論している様子です。

現行システムのDockerImageを作成する

設計方針が固まったので各自もくもくと作業。

当日は設計の議論が長引いてしまったので、今回はここで終了しました。

続きは持ち帰ってPull Requestや自席で相談しながら進めています。

効果、課題など

集中して時間を取ることで一気にキャッチアップすることが出来ました。

また、議論を通して自分の担当していないシステムのインフラ構成も知ること出来たので、Pull Requestでレビューできる範囲や深さが大きく改善しました。

本番への適用は徐々に進めていく予定ですが、現実的に実現可能な目処が出来て良かったと思います。

さいごに

株式会社 Speee は新しい技術を使って世の中を変えたい エンジニア やSpeeeKaigiのようなイベントを企画運営するエンジニア組織推進室メンバーを募集しております。ぜひ遊びに来てください。

(記事 @iida-hayato / 写真 @Tei1988)

*1:プロジェクト推進室:Speee内で直接業務に紐付かない全社的なシステム(勤怠、日報、経理支援等)の開発/運用を担っている部署です。