少人数でサービスをすばやく開発するためのRails活用事例 - Rails Developers Meetup 2019

Rails Developers Meetup 2019
https://railsdm.github.io/
SESSION: C-2 (ja) @tawachan

少人数でサービスをすばやく開発するためのRails活用事例
A case study on developing a web service quickly with less bugs using Ruby on Rails
ピクシブ株式会社 大多和 祐介
当セッションでは、弊社サービス「pixiv chatstory」が少人数ですばやく、しかしバグは少なく開発していくために採用していているアーキテクチャについてお話します。Ruby/RailsはAPIサーバーとしてHeroku上で使用しているので、このあたりの話を中心にしたいと思います。

This session mainly discusses the IT architecture that one of pixiv's products, pixiv chatstory adopts to enable us the small team (2-4 engineers) to develop the both web and native apps quickly but with less bugs, using Rails as an API server deployed onto Heroku.

Keywords: Rails, Heroku, Swagger, CloudFront, ImageFlux, Firebase, PWA, Angular, Ionic, ReactNative, Expo.io

【参考】フロント周りの話ができなかったので関連記事をよろしければ
pixiv chatstoryのiOSアプリをReact Native（Expo）でリニューアルしました！
https://inside.pixiv.blog/tawachan/6254
pixiv chatstory の
 PWA としての取り組み
https://speakerdeck.com/ikasoumen/pixiv-chatstory-false-pwa-tositefalsequ-rizu-mi

Transcript

1. 少人数でサービスをすばやく 開発するためのRails活用事例 @Rails Developers Meetup 2019 pixiv Inc. Yusuke Otawa @tawachan39 2019.3.22
2. 自己紹介 • 大多和祐介（tawachan / @tawachan39） • ピクシブ株式会社（福岡オフィス） • 東京出身だけれど転職を機に福岡へ Iターン ◦ 福岡Iターンとか興味ある人はお声がけ頂けると嬉し い！ 2 tawachan
3. • 少人数でフットワーク軽くサービスを開発する方法としての事例 • 弊社のサービス（pixiv chatstory）PJにおける知見がベース • 新しくサービスを始めるときのアーキテクチャ ◦ スピードを上げつつある程度コードの質が担保される開発 ◦ チームの構成とかではなくあくまでエンジニアリングの部分 ◦ サービス的な質はまた別の話...。 • サーバーサイド（Ruby on Rails）の話が中心 今回話すこと 3
4. のアーキテクチャ 4 API Server Web/PWA iOS CDN
5. 新規サービス開発において だいたいエンジニアが考える(た)こと • この処理なんか動いてない、どうにかしなきゃ ... • 仕様が変わるときにエンジニア間で共通認識を持つのが大変 ... • アクセスが集中してレスポンスが遅くなっている ... • 捌ききれなくなって500返してる... 5
6. なんかつらい 6
7. • ユーザーやUXのこと • 様々なデータの取得 • 取得したデータの解析 • サービスの改善や目指すべき状態 新規サービス開発において エンジニアが考えたいこと 7
8. どうにかしたい 8
9. どうにかしてみた！ 9
10. 目次 10 1. Railsアプリケーションの位置付け 2. 実行環境 3. 開発の工夫
11. Railsは APIサーバーに使用 11
12. クライアントは多種多様 • ウェブ ◦ 普通のウェブ ◦ PWA • スマホアプリ ◦ ネイティブ ◦ クロスプラットフォーム • スマートスピーカー • その他 ◦ Slack ◦ LINE… etc 12
13. • アプリを作っていたけれど、やっぱりウェブのほうがいいかも ... • クロスプラットフォームでのアプリは辛いからネイティブで書き換える ... • ウェブだけでなくアプリも必要になった ... サーバーサイドよりもクライアントサイドのほうがライフサイクルが速くなっている → クライアントサイドの変更にサーバーサイドが引きづられるのはよくない クライアントは書き換えるかも 13
14. • クライアントによって返すものが異なるのはそもそもどうなのか ◦ ウェブだったらHTML ◦ でも非同期でのリクエストだったら JSON ◦ アプリなら常にJSON • クライアントが増えてパターンが増えてくると見通し悪い ◦ DRYにしづらくなる • →　バックエンドはデータの登録、管理、取得が責務 バックエンドはデータが責務 14
15. • メリット ◦ ウェブ用とアプリ用の２種類のエンドポイントを用意する必要がなくなる ▪ →共通化できる ◦ その他のクライアントにも対応しやすい • デメリット ◦ セッション管理や認証周りがちょっと手間になる ◦ フロントの分リポジトリや用意する環境が増える RailsはAPIサーバーに使用 15
16. APIサーバーなら 別の言語でもよい...？ 16
17. 結局Railsが最強でした 17
18. なぜRailsなのか 18
19. • Migrationも含めてModel層はよしなに力が群を抜いて強い ◦ 他の言語に代案がない... ◦ Go言語のBeegoは良さそうだったけれど... • RDBを使うならRailsを使いたい Active Recordがどうしても一番便利 19
20. • 開発できる人が多い ◦ 社内でもキャッチアップしている人が多い ◦ 社内で情報共有もできる • エコシステムや知見が揃っている ◦ ググればすぐわかる、妙に詰まることがない ◦ 社内でも知見を得られる 開発スピードが出る 20
21. サーバーのデプロイ場所 21
22. • Herokuなら状況に合わせて融通がきく ◦ Dyno増やす／強くできる ◦ すぐにスケールできる ◦ プランによってはオートスケーリングもできる ◦ DBもアドオンなのでGUIでポチるだけで建てられる • PaaS最高！！！ Herokuに全部おまかせ 22
23. • Herokuでそれなりに環境を揃えても1ヶ月あたり数百ドル • エンジニアに換算したら数人日 ◦ 自前でやるならたった数人日で完結しないとペイしない ◦ そもそも人手があるわけでもない • 積極的にHerokuに任せていけば、人手も残るしコストも下がる！！ エンジニアが一番高い 23
24. でもレスポンスが遅い... 24 • US／EUリージョンのみ ◦ 物理的な距離で単純にレスポンスが遅い ◦ （エンタープライズ版で東京リージョンが出てはいる） • レスポンスの速さはユーザー体験に直接影響する • でもHerokuの便利さは捨てたくない...
25. CDNで解決！ 25
26. • APIサーバーが返すJSONをCDNでキャッシュ ◦ AWSのCloudFrontを使用 • 東京リージョンのCDNで処理できるものはかなり速い 東京でキャッシュすれば実質東京 26
27. でもキャッシュ事故は怖い... 27
28. CDNでのキャッシュ前提のAPI設計 • 誰でも見れる public なエンドポイント ◦ どのユーザーがAPI を叩いても値は同じ ◦ 処理内で current_user を使わない • 認証状態によってユーザー固有の情報を返すエンドポイント ◦ API を叩くユーザーによって値が変わる ◦ 処理内で current_user を使う 28
29. # examples_controller.rb before_action :require_api_key, only: [:create, :destroy, :update] before_action :optional_api_key, only: [:index, :show] before_action :cdn_cache_long, only: [:index, :show] def index @examples = Example.all end … def create @examples = current_user.examples.create!(example_params) end … キャッシュの機構の例 29
30. キャッシュの機構の例 # application_controller.rb def require_api_key raise StandardError, 'require_api_key not allowed after cdn_cache called' if @cdn_cache_called @require_api_key_called = true @current_user = User.find_by(api_key: api_key) unless api_key.blank? render json: { error: 'Api-Keyが有効ではありません ' }, status: :unauthorized unless @current_user end def cdn_cache(s_maxage) raise StandardError, 'cache not allowed' if @require_api_key_called @cdn_cache_called = true expires_in(0, 's-maxage': s_maxage, public: true, must_revalidate: true) end def current_user raise StandardError, 'current_user not allowed' unless @require_api_key_called @current_user end 30
31. ヒューマンエラーは どうしても起こる （”気をつける”だけでは解決しない） 31
32. 仕組みで 解決していくことが 重要 32
33. 手軽に速くデータを返せる APIサーバーになりました 33
34. でも、フロントからは まだ使いづらい 34
35. API のドキュメント 見るの面倒ですよね 35
36. データの管理が責務なら スマートに受け渡しまでしたい 36
37. Swaggerを導入 37
38. • API開発を補助してくれるオープンソースのツール群 • OpenAPI形式 • 様々なツールがある ◦ Swagger UI ◦ Swagger Codegen ◦ Swagger Editor Swaggerとは 38
39. swagger_path '/api/stories/{url_hash}' do operation :get do key :summary, 'url_hashを指定してストーリーを取得 ' parameter do key :name, :url_hash key :in, :path key :description, 'storyのurl_hash' key :required, true key :type, :string end response 200 do key :description, 'ok' schema do key :'$ref', :StoryResponse end end end swagger-blocksでRubyで記述 39
40. ブラウザで一覧が見れる (Swagger UI) 40
41. • 誰でも見れるAPIドキュメントになる • コードベースでドキュメントが管理できる ◦ ExcelとかSpreadsheetで書く必要なし • 実際にAPIも叩ける Swagger UIのいいところ 41
42. • クライアントが使うコードが生成できる ◦ 型情報 ◦ SDK（リクエストを飛ばす部分） • メジャーな言語には対応 ◦ Swift ◦ Kotlin ◦ Java ◦ TypeScript（Fetch, Angular… etc） ◦ … and more 42 Swagger Codegenでコード生成
43. • 型情報とリクエストを生成できる • 目測で型合わせをする必要がなくなる！！！！ • サーバー・クライアントで齟齬が生まれてこない ◦ インターフェースの不一致によるバグはここで完全に塞ぐ ◦ 変更もすぐに自動生成して反映できる • 各クライアント固有の処理の実装に多くの関心が払える 43 Swaggerのいいところ
44. • swagger-blocksでドキュメントを書いていくのが手間 • この手間を払ってもお釣りがくるありがたさ（チームメンバーの声） Swaggerの大変なところ 44
45. 手軽に速くデータを返せて クライアント開発者にも優しい APIサーバーになりました 45
46. 少人数でフットワーク軽く サービスを開発する方法としての事例 46
47. 少人数でもスピードを上げつつある程度のコードの質を担保したい 1. RailsをAPIサーバーに使う 2. インフラはHerokuにお任せ 3. CDNでレスポンスも爆速に 4. Swaggerでクライアント開発者にも優しく 今回のおさらい 47
48. 本質的なことに集中して ユーザーに価値を届けていきましょう 48
49. 49 • pixiv chatstoryのiOSアプリをReact Native（Expo）でリニューアルしました！ ◦ https://inside.pixiv.blog/tawachan/6254 • pixiv chatstory の PWA としての取り組み ◦ https://speakerdeck.com/ikasoumen/pixiv-chatstory-false-pwa-tositefalseq u-rizu-mi 【参考】フロント周りの話ができなかったので 関連記事をよろしければ