オウンドメディアをGatsbyJS + S3 + CloudFront構成に切り替えた話

Rentioのカミヤです。当社では、カメラや家電製品全般をレンタルできるECサイトであるRentioに加え、そこで扱う製品を丁寧に解説するオウンドメディアのRentio PRESSを運営しています。

Rentio PRESS[レンティオプレス] - 家電レンタル「Rentio」が運営するメディア。カメラや家電の実機レビューや、初心者でも分かりやすい製品の使い方や選び方、おすすめモデルを専門ライターが詳しく解説していきます。

Rentio PRESSは創業直後から粛々と運営しているメディアサイトなのですが、少しずつ、かつ着実に規模を拡大し今では単体で月間ウン百万PVを超える規模にまで成長しました。

しかし、規模が大きくなるにつれこれまで先送りにしていた問題や今後のサイト運営における課題が顕在化するようになり、今回の構成リプレイスに至った次第です。

今回のリプレイスではGatsbyJSによる静的サイト化という方法を選んだのですが、折角なのでその判断の経緯と開発記録について残しておきたいと思います。

従来のサイト構成と課題

従来の構成は執筆にWordPressを使い、前段にCloudFrontを配置するという構成でした。これには次のような課題がありました。

- メンテや開発がしづらい
- CloudFrontにキャッシュできないコンテンツが遅い
- セキュリティ上の不安
- 負荷耐性がサーバーのスペックに大きく依存
- WordPressプラグインが常時20個以上稼働 🤔

WordPressは誰でもサイトが構成できる素晴らしいフレームワークである一方、エンジニア泣かせな部分もあります。

この辺りはネットにもたくさん情報があるので細かいことは割愛しますが、例えばローカルでの開発環境セットアップにもプラグインを入れてデータを投入して...という手順がありますが、データが大きくなるととても長い時間がかかったりデータのインポート中にエラーで止まったり...みたいなことが起こります。あとテーマ改修後のデプロイにFTPが必要なのが地味に辛いです。

またサイト構成や高速化、セキュリティと色々考えていくうちに稼働中のWordPressプラグインが（定期的に断捨離していたのですが）いつのまにか20個を超えてしまっていました。プラグインが増えてしまうのはWordPressの宿命でもありますが、プラグインが増加することでサイト速度の低下やセキュリティリスクが高まるのも大きな課題と考えていました。

WordPressでは自作テーマを作るのにPHPが必要ですが、当社の採用技術がRuby on RailsとReactということもあり、メンテや開発ができるメンバーが限られています。PDCAをより早く回すためにも、Developer Experianceの改善が急務と感じていました。

新構成に求められる要件

上記の課題を受けて、新構成に求められる要件は次の通りでした。

- 速い
- 安定している
- メンテ、開発がしやすい
- (新技術を採用する場合) 学習コストが高すぎない
- WordPressで執筆したい

最終的な構成と選定経緯

最終的には次の図のような構成としました。登場人物はWordPress + Gatsby + Gatsby Cloud + S3 + CloudFrontです。Gatsbyで静的サイト化することで、SPA（シングルページアプリケーション）化され高速なウェブサイトを比較的容易に実現できます。

JAMStackな構成を実現するうえで、CMSをContentfulやmicroCMS、StrapiといったHeadless CMSに載せ替えることも検討しましたが、執筆者側の負担を考慮するとWordPressで執筆できることが一番です。またGatsbyにはgatsby-source-wordpressというgatsbyプラグインがあり、WordPressでのサイト構築がスムーズに始められたのもポイントでした。

なお、当初ホスティングは運用工数を考えてNetlifyにする予定でしたが、Netlifyのエッジロケーションが日本にない点、前段に配置したCloudFrontとの相性問題が発生した点から断念。ビルドも速いGatsby Cloudを採用し、S3にファイルをホスティングする方針となりました。

なお、Gatsby CloudはGatsbyチームの運営する高速ビルドに特化したサービスのようです。2020年6月時点では比較的新しいサービスということもあり、Netlifyほど細かなチューニングは現状ではできませんでしたが、必要十分な機能は揃っている印象です。ちなみに現状ではインクリメンタルビルド（差分更新）ができるのはGatsby Cloudのみのようです。

The Best React-Based Framework | Gatsby

GatsbyJS以外の選定候補

Gatsby以外でもNext.jsやNuxt.jsといったフレームワークが候補としてあがっていました。そのうえで考慮したのは次の点です。

Reactでコーディングできる点、ドキュメントが豊富、プラグイン等のエコシステムが十分発達している、安定性。これらを考慮すると静的サイト化するのが良さそう、だったらSSGに特化したGatsbyにしようというのが今回の選定経緯です。

開発プロセスとその記録

構成を決めた後、2週間ほど空き時間を使って軽く動作検証してみました。問題ないと判断できた後、本格的な実装フェーズへ移行しました。

ひとまずサイトの見た目は変更せずに構成だけを変更するわけですが、やはりサイトをPHPからReactに丸ごとコーディングしなおす必要があったため一ヶ月くらいはかかってしまいました。

基本的なマークアップ以外で時間のかかった開発タスクとしてはこのあたりが挙げられます。

- 初期セットアップ(WordPressとGatsbyのつなぎこみ)
- 非レスポンシブからレスポンシブへの書き換え
- 記事ランキング（全体ランキング & ジャンル内ランキング）
- 記事検索（Algoliaを活用）
- OGPのマークアップ
- 構造化データのマークアップ
- 広告（AdsenseとSPAとの相性がイマイチ良くない...）
- AWS Lambdaによるキャッシュの操作

いくつかピックアップして補足しますと、

初期セットアップですが、WordPress用のGatsbyテンプレートを元に開発したのでとても楽でした。一点ネックだったのがビルド時間です。Gatsbyでは画像の最適化を図るため、CMS内の画像を全てダウンロード→最適化→ホスティングするといったビルド工程を取っているようでした（もしかしたらGatsby本体の挙動でなく、WordPressインテグレーションの特色かもしれないです）ここで画像数があまりに多く、ビルド時間が長すぎてタイムアウトするといった事態が起きたため、ひとまずは画像の最適化はOFFにして利用しています。既存の画像は全てCDN経由で配信していたためこの手段を取れましたが、中規模以上のサイトをGatsbyで構築する際には画像最適化によるビルド時間の長さがネックになりそうに思いました。

記事ランキングについては、Google AnalyticsのAPIを取得しGraphqlで抽出するという形を取りました。ジャンルごとのランキングについては、Google Analytics内で記事ジャンルをカスタムディメンションとして定義していたため、API経由でそれも同時に取得し、Graphqlでゴニョゴニョして表示しています。

また、S3 + CloudFrontという構成を取るにあたりGatsby Cloudの機能だけでは不十分な箇所がいくつかありました。そのためデプロイ後のいくつかの処理をLambdaで行っています。具体的には、S3のファイルが上書きされたときにCloudFrontのキャッシュをinvalidateする操作と、JavascriptやCSSといったアセットのメタデータ（cache-control）をセットする操作がLambdaにより行われています。

しばらく動かしてみての所感

SPAの恩恵もあり、体感速度はたしかに早くなりました。しかしながら、PageSpeedInsightのテスト結果はそこまで良い結果とはなりませんでした。原因ははっきりしており、大部分はサードパーティ製スクリプトの読み込みが遅いことに起因しています。これらは広告や計測関連なので外したり別の製品にリプレイスしようというの判断が難しいです...

あとは画像関連ではwebp形式での配信をはじめ最適化できる箇所がいくつか残っています。これを機にもう少しチューニングに取り組んでみるつもりです。

あと開発者としての感想ですが、開発環境のセットアップがとても楽になったと感じています。これまでWordPressの開発環境をローカルにセットアップしようとした場合、データダウンロードに数時間かかったりphpやmysqlのバージョン不一致でエラーを吐いたりします。Gatsby化したことで、開発環境の立ち上げの度に本番APIから数秒でコンテンツを取得してくるため、常に最新の本番データと同じものが開発環境でも使えるようになりました。デプロイもGatsby Cloudが勝手にやってくれるため、冒頭でも書いたDeveloper Experienceは確実に改善したという実感を持っています。

あとは、S3 + CloudFrontという使い慣れた構成でホスティングできることも大きいです。使い勝手の部分でもそうですが、アクセスが急増した際のインフラの心配から一切解放されたことへの安心感がすごい。

CMSとしてもWordPressは残るため、WordPress職人は今後も必要なのですがフロントエンド関連のプラグインを大幅に減らすことができることから管理コストは大幅に減るのではないかと思ってます。

今後の開発方針

ひとまずは、Gatsby化することで不要になったプラグインを外してゆき構成を小さくしてゆくことに努めるつもりです。

今回の構成変更で改修コストが大幅に下がったので、これまで見送っていた細かな改善にも取り組んでゆきたいと思います。

最後になりましたが、レンティオではサーバーサイド、フロントエンジニアを募集中です！

Rentio PRESS[レンティオプレス] - 家電レンタル「Rentio」が運営するメディア。カメラや家電の実機レビューや、初心者でも分かりやすい製品の使い方や選び方、おすすめモデルを専門ライターが詳しく解説していきます。