3行要約
- 2017-01 〜 2018-04までの1年ちょい、Fablic社でFRIL開発してたよ
- そこでの体験は最高だったよ
- 来年Vancouverに戻るまでの間の予定は現時点で未定だよ
2017-01 〜 2018-04までのだいたい5四半期の期間、株式会社Fablic社でソフトウェアエンジニアとして働いていました。内容はFablicの運営する、数百万ユーザ規模のRailsサービスFRILの開発・運用です。
なお、Fablicで働く前はVancouver, CanadaにあるHootsuite Media Incでこれまた当時数百万ユーザ規模のPHPとScalaのサービスHootsuiteの開発・運用を行ってました。こちらは6年半と、ちょっと長居しすぎました。
FRILは複数のRuby on Railsアプリケーションを組み合わせたサービスです。Rails自体は2006年くらいから触っていたものの、2010年にHootsuiteに入ってからはほとんどRubyもRailsも本気で取り組んだことはなく、2017年はじめにFablicに入ったころはRailsエコシステムの習得が最初の急務でした。ruby 1.9から2.5までのすべてのchangelogを見たりも。&. を本番で動くコードに書いてもいいの気持ちいいですね。
最初にやった大きめの仕事は、FRILの複数のRailsアプリケーションそれぞれに独自に定義されていた、同じテーブルにアクセスするためのモデルのロジックを共通化することでした。FRILは 分断されたモノリスのわかりやすい一例でした。これを僕は当初Accidentally Microservicesと呼んでました。モノリスとマイクロサービスの両者の悪いとこ取りみたいなやつです。全員が問題を認識しているものの、それを解消するには腕力が多く必要だったので先延ばしになっていたものです。Userモデルが6種類定義されていて、全部微妙に生えてるメソッドが違ったりvalidationが違ったりしている感じです。
長期的には、(a) きちんとMicroservices化する。複数のRailsアプリケーションがRDBMSでもって連結する現状を徹底的に避ける、または (b) モノリスに再結合する のどちらかをやるべきと考えています。どちらに手を進めていくとしても、前述のライブラリをはさむ方法が実用上便利と判断しました。
既存の様々な解決方法を調査したのち、最終的にそれらのアプリケーション間で共通で使うRails Engineのgemを作って、モデルを共有化する、というものにしました。このgemはセマンティックバージョニングになるべく厳密に従ってバージョンつけてgemとして社内で配布し、各railsアプリケーションはそのバージョニングを信用してアップデートしていきました (例: これはminor version upだから他のさくっと入れちゃおう / これはmajor version upで怖いから、とりあえずライブラリアプデだけで他の変更は可能な限り小さくしよう)。移行期間中どうしても各アプリケーション側で共有モデルの挙動を上書きしたいときは、 ./app/reopen_models/fril/reopen_xxx.rb みたいな感じでファイルを配置しておくと、あとはgemのinitializerがそれを適切なタイミングで読み込んで必ず一回だけモンキーパッチしてくれる、みたいに作りました。他にもいろいろなやり方があると思いますが、ひとまずこれで安定して比較的楽しく開発ができる形にもっていけました。
なお、上記プロジェクトだけでなく、ほか様々なrailsプロジェクトのやり方で悩んだときは、ほぼ毎週参加しているasakusa.rbでの雑談にかなり助けられています。この場でもってコミュニティの皆様に感謝します。
Fablicでは他に以下のようなプロジェクトを進めていきました。一人でやったものもあるし、少人数チームを作ってリードしたものもあります。
- (前述の) Rails Engineを用いた、複数Railsアプリケーション間でのモデルの共通化
- apnoticを用いたiOS Pushの高速・安定化
- マルチスレッドsidekiqの安定化、モニタリング
- Fablic.vim主催 (詳しくは後述)
- ソフトウェアエンジニア新入社員のonboarding
- セキュリティ監査で見つけた脆弱性をがんがん対処
- ほかセキュリティ的にやばいあれをあれする
- Feature toggles (dark launchとかfeature flagsとかいわれてるあれ)
- Circuit Breaker
- Canary release
- ログ基盤
- 認証システムのやばいやつをあれする
やりたかったけど在籍期間内にやれなかったのは、
- Rails 4.2 -> 5.1へのアプデ
- これを安全にやるための仕込みとしてfeature toggles, circuit breaker, canary releaseなどを導入したけど、その後セキュリティ的にやばい部分をあれするのを優先するためrailsのアプデを後回しにしていた
- (なおそのセキュリティ問題はがんばって完全解決した)
- バッチをいい感じのスケジューラーに移行
- cron (whenever経由) でrakeのバッチを大量に走らせてる
- いろいろ問題でてる
- いい感じに可視化できていい感じに重複起動防止とかができる専用のスケジューラに任せたい
あともういっこ、大事な仕事として、リモートワークの制度を社内に導入するというのをやりました。
今回東京にきて、ラッシュアワーに通勤するというスポーツを体験できたのはすごくよかったのだけど、同時に実はこのスポーツは毎日やるには大変すぎて仕事にならないということも発見しました。僕は職場から結構遠いところに住んでいて、なんと通勤に一時間ぐらいかかってしまいます。これだとお昼にちょっと帰宅してなんか料理してランチして、みたいなことは気軽にはできません。
Fablicは基本的にみんながオフィスに集まってわいわいがやがやしながら開発するスタイルでこれまでやってきており、リモートワークをいきなり導入するのは障壁が大きそうでした。が、そのときちょうど家庭の事情でリモートワークせざるを得なくなっている方がいたことと、すでに社内の会話の大部分はslackでオンラインでなされていた状況から、段階的に導入していけばいけるやろと推測されました。
会社側(とくにマネージャの負担にならないように)のメリットと従業員側のメリット双方がいい感じになるように、持続可能なルールをこちらで考えて、それを草案として、期日を設けて試用してみました。いい感じにいけていたので、改めてプロの人事の方にそれを任せ、僕は継続して週一日でそのルールにのっとってリモートワークしていました。最高でした。
リモートワークについてはfablicのブログに詳しく書いてみました。後日、この記事を参考にして二社が似た制度を導入したと聞きました。
http://in.fablic.co.jp/entry/2017-12-the-art-of-wfh
音楽性の違い的な何かであれをあれするとあれになる的な感じです。余談ながら、音楽性の違いを英語でいうと、musical differenceというらしいです。そのまんまですね。
4月はひとまずのんびり休みつつ、これまでやれなかったことをやります。さっそく最終出社日の次の日は山梨県の岩殿山というところで登山してきました。花粉がないと思っていったら花粉で鼻と喉が完全にやられてそれが大変だったものの、登山自体は最高だったので、また行きたいです。
また、その次は鮮魚を捌くなどの活動をしました。以下、その様子の一部です。
- https://twitter.com/sandkatt/status/982065217088634880
- https://twitter.com/ujm/status/982111378155556865
- https://twitter.com/ujm/status/982111423307264001
- https://twitter.com/ujm/status/982111477422174208
- https://twitter.com/ujm/status/982111561253765121
- https://twitter.com/ujm/status/982111618342387712
来年の夏までにカナダのVancouverに戻る予定です。あちらにいま家はない状態なので、まずは物件探しですね。日本にくるときかなり苦労したので、今回も苦労する予定です。
んでそれまでの間は今は決まっていません。
謎の露骨なリンクです
リンク切れ？