『Rails Scales!』を読んだ

The Pragmatic Bookshelf (pragprog.com)から出ている『Rails Scales!』を読んだ。

Rails Scales! pragprog.com

Build Rails applications that scale. Discover the small changes that make a big difference in efficiency. Design applications for performance from the start.

概要

事業や扱うデータの大規模化に耐えうるRailsアプリケーションを作っていくための方法を解説している本。

主なトピックである性能改善に関する話題としては

• Active Recordのeager loadingやRDBのインデックスの適切な利用方法
• キャッシュの利用方法（アプリケーションレイヤのキャッシュ、HTTPキャッシュの両方）
• API（ここではバックエンドが提供するREST APIなどを想定）のページネーションや他リソース埋め込みに関する方法の比較
• DBのシャーディング、非同期処理の導入、イベント駆動などシステムのアーキテクチャ

について、Railsの機能を使った実現方法も踏まえて解説されている。

ユニークな点として、大規模化を考慮したアプリケーションの仕様設計についても触れられており、

• プロダクトの仕様や制限事項（悪用防止のためのレートリミットやデータ数の制限）に関する考慮事項
• アーカイブや削除など、データライフサイクルの終盤に関する考慮事項

について議論されている。

他にもRailsアプリケーションを開発する組織の規模拡大の方策として、コードオーナー導入やモジュラーモノリスへの移行¹についても触れられていた。

感想

「大規模化」というテーマのもと、Railsアプリケーションの性能改善の具体的な方法からシステムのアーキテクチャ、アプリケーションの仕様、さらには開発組織までと、話題が多岐にわたる本だった。その分、各論についての掘り下げはそこまで深くはないと感じた。

この本で解説されているような性能改善に関する知識は、ふつうだとWeb上の資料を渉猟しながら学ぶことが多いように思うので（そうでもない？）、Webアプリケーション開発をし始めた人には役立ちそうだと思った。また、キャッシュについての解説は、Railsのキャッシュの仕組みが複数あり（フラグメントキャッシュやRails.cacheによる独自のキャッシュロジック）、実装パターンも複数考えられるためか説明が詳しめだったので、わりと読み応えがあった。

個人的には仕様設計の時点で大規模化を見越しておく話が興味深く読めた。これは別にYAGNIではなく、むしろレートリミットにしてもデータ量の上限にしても、あとから入れるのはユーザー影響が大きく難しい状況になりやすいので、できるだけ最初から入れるべきだと考えている。また、データのライフサイクルにしても、アーカイブの仕様を早めに考えておかないと、あとからデータの参照に関する仕様に変更が入ってしまって、ユーザーに影響を与えうる。このあたりの課題は、やりすぎないようバランスを取りながら解決していくのが必要なんだろうと思う。

全体としては、性能改善の入門的内容についてはまとまっているので、そのあたりに詳しくない人は一読するのが良さそう。そのほかは気になる話題をつまみ食いする形で読むのがいい本かなと思った。