Tweet
Tweet

Slide 1

Slide 1 text

スタートアップは Rails を使うべきか @yuya-takeyama SRE at Quipper

Slide 2

Slide 2 text

今日話すこと ● スタートアップ期をとっくに終えた今も Rails を 使い続ける会社にいて感じていること ● 副業含めてスタートアップやベンチャーの人から の相談に対して話してきたこと ● そういった中から感じた「魅力的な会社」と「働 き方」について

Slide 3

Slide 3 text

自己紹介 ● @yuya-takeyama ● 2015 年 9 月 ~ Web Developer at Quipper ○ Rails, React, React Native など ● 2018 年 4 月 ~ SRE at Quipper ○ Kubernetes を使ったプラットフォームの構 築、移行

Slide 4

Slide 4 text

自己紹介 ● 副業 at 株式会社オクタウェル ○ ヘルスケア系スタートアップ ○ PHP, Laravel, AWS Lambda (TypeScript), CircleCI 等

Slide 5

Slide 5 text

スタートアップは Rails を使うべきか

Slide 6

Slide 6 text

結論

Slide 7

Slide 7 text

好きなフレームワークを 使えばいいと思う

Slide 8

Slide 8 text

2018 年における Web アプリケーション ● フロントエンドも含めて作り込まれていて当たり 前 ○ SPA, SSR, PWA... ● フレームワークにはフロントエンドの開発も含め た機能セットが求められる ● 一方でサーバサイドでは API だけで十分、とい う領域も増えてきた

Slide 9

Slide 9 text

そんな時代における Rails ● 時代に合わせて進化を重ねている ○ Asset Pipeline (Rails 3.1~) ○ Webpacker (Rails 5.1~) ○ API モード (Rails 5~) ● 基本的にはフロントエンド・サーバサイドともに いい感じのデフォルトが提供されている ○ Rails is omakasae (2012)

Slide 10

Slide 10 text

Rails is omakase の逆の側面 ● Rails のやり方が気に入らなければ Rails を使わ なければ良い ○ フロントエンドは Babel, Webpack, TypeScript のビルド環境を自分で整えて ○ サーバサイドは Go の net/http で手書きの Middleware と共に ● 自分で選んで自分で作っていく (大変ですね...)

Slide 11

Slide 11 text

2018 年における Rails ● 相対的には Rails を使い続ける理由は減ってきて いると言える ○ 単純にその他の選択肢が増えて、意味を持っ てきた、という意味で ● でも絶対的に Rails の価値が下がったとは言えな い (たぶん)

Slide 12

Slide 12 text

Quipper と Rails ● 2012 には Rails を使い始めている (今年で 7 年 目) ● MongoDB (というか MongoMapper) が足かせと なって 4.2 で止まっている... ● Heroku, Deis を経て Kubernetes に ● マイクロサービス化がまさに始まろうとしている ところ

Slide 13

Slide 13 text

Web アプリケーションの構成要素と寿命 ● アプリケーションコード ● インフラ・クラウド ● 言語・フレームワーク・ライブラリ ● データ

Slide 14

Slide 14 text

Web アプリケーションの構成要素と寿命 ● アプリケーションコード ● インフラ・クラウド ● 言語・フレームワーク・ライブラリ ● データ <- たぶんこれが一番長生き

Slide 15

Slide 15 text

データさえちゃんとしていればなんとかなる ● 枯れたデータストアをちゃんと選んで使う ● ちゃんとメンテされる ORM を選ぶ ○ または ORM を使わず抽象化を必要最小限にと どめる ● データのモデリングはしっかり考える

Slide 16

Slide 16 text

データさえちゃんとしていればなんとかなる ● という前提を踏まえれば、極論好きなフレーム ワークを使えばいいと思う ● 特に好みや技術的に特殊な条件がなければ Rails 自体は決して悪い選択肢ではない ○ 本当にダメそうならその時方向転換すれば良 い

Slide 17

Slide 17 text

スタートアップが 選ぶべきインフラとは

Slide 18

Slide 18 text

Heroku はいいぞ

Slide 19

Slide 19 text

複数のスタートアップの人と話して感じたこと ● AWS 利用率の高さ ○ EC2 を手動で立てて git pull でデプロイしてい たり ○ ECS でデプロイの仕組みをめっちゃ頑張って 構築しようとしていたり ● イケてなかった選定理由「投資家に言われたか ら」「知り合いの起業家が使っていたから」

Slide 20

Slide 20 text

複数のスタートアップの人と話して感じたこと ● Heroku 利用率の低さ ○ AWS に比べると Heroku を偉い人に通しづら い？ ○ ここを通せる腕力、または会社側に柔軟性が あると色々と良くなる ● レイテンシをネックとしてあげるケースもある ● プロダクトの構築・改善を最優先にすべきでは？

Slide 21

Slide 21 text

Heroku の良いところ ● とにかくアプリケーションを立ち上げるまでが早 い！ ● 金でスケールできる ● インフラとかコンテナのことを意識しなくて良い ○ コンテナの偏りを直したりとか... ● Review Apps, Add-on

Slide 22

Slide 22 text

Heroku の良いところ ● 12 Factor App！ ○ サーバサイドアプリケーションにおけるアー キテクチャの養成ギプス ○ これだけ守れてれば将来的にコンテナ化した り Kubernetes に載せること自体は全然難しく ない

Slide 23

Slide 23 text

おまけ: Heroku のレイテンシに関して ● CDN を利用すればある程度改善できる (キャッ シュしない動的コンテンツでも) ○ Edge TLS Termination, Route Optimization, Dynamic Site Acceleration… ○ Sinatra で 800 msec 程度が 500 msec 程度に ○ 速くはないがそんなに悪くもない? (B2B サー ビスなら特に)

Slide 24

Slide 24 text

まとめ

Slide 25

Slide 25 text

スタートアップ期の会社にオススメしたいこと ● フレームワークに何を使うかは些細な問題 ○ データやモデルにこそ目を向けるべき ● プロダクトの開発に集中するためにコストを使う ○ Heroku はいいぞ, Kubernetes は多分まだいい ○ 他の PaaS でも楽できるならなんでもよし ● 何をやる・やらないにしても理由づけを明確に ○ 枯れた技術でもプロダクトをしっかり作れている会 社はそれだけで十分魅力的

Slide 26

Slide 26 text

エンジニアとスタートアップの関係性 ● 働くならプロダクトに向き合えている企業 ○ その分技術的負債を抱えていたとしても、自 分の知見で一気にレバレッジがかけられるか も ○ 短期間・高単価で働けるチャンスもあるかも ● そういったことがあちこちで起これば業界全体の レベルアップにも繋がりそう