スタートアップは Rails を使うべきか / Should Startups Ride on Rails?

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. 結論
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. Heroku はいいぞ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. まとめ
    

    View Slide

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

    View Slide

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

    View Slide