🦜

【AWS】フロントエンドを支えるインフラの進展と将来予測

2023/07/31に公開

AWS

この記事は？

フロント技術の発展によってフロントエンドエンジニアの専らの関心は、SSR、サーバーサイドでHTMLを返す技術を追っていく流れになってきた。この記事では、SSRを使う理由とは何か？また、SSRを実現するためにインフラはどうなっているかを、AWSを例に解説したい。

筆者は？

ToCの事業会社でアプリの機能実装やAWSのインフラ構築などを担当しています。フロントに関心が強く追ってきた一方、SSRを実現する仕組みを理解するにはインフラ側も含めた横断的な理解も必要なので、インフラまで担当してきた知識から執筆することにしました。開発組織としても、SEOや速度最適の観点からフロントはSSRでの開発を進めていっており、重要度が高い印象です。

なぜMPA -> CSR -> SSRの流れが進んでいるのか？

従来、Webアプリケーションの作成では、Ruby on Rails/ Laravelなど多くのフレームワークがMVCと言ってモデル、ビュー、コントローラーの3層を取ってきた。MVCではDBアクセス及びビジネスロジックの責務、ビュー(HTML)を作って吐き出すというところまで一貫してサーバー側で行うことで実現される。ところが、MVCの難点として、M対Cの状態管理周りが複雑に絡み合い改修が大変になるなどの難点があった。そこで、フロントエンドをMVCから分離し、Viewの部分はJavaScriptでコードを書き、今までとは違ってサーバーではなくブラウザにユーザーがアクセス時にビュー(HTML)を作り吐き出させることで、SPAでは状態管理を疎結合に行うことができるため開発効率が高まった。一方クローラーがSEOをどう評価するか？などの懸念や、また事前にサーバーでビューを生成しておけるため表示速度的に有利なNext.jsによるSSRの技術が使われるようになってきた。

MPA(Multi Page Application)

Ruby on Railsを例に説明する。サイトにアクセスがくるとNginxやApacheといったWebサーバーがリクエストを受け、静的なコンテンツの場合はWebサーバーがそのままビューを配信を行い、動的コンテンツの場合はPumaやUnicornなど、アプリケーションサーバーにリクエストを転送します。アプリケーションサーバーはDBとの接続やアプリのビジネスロジックなどを担っており、一連の処理を終えてHTMLを生成すると、Webサーバーにリクエストを返して、HTMLが配信される。
AWSでは、アプリケーションサーバーを作り、別途Webサーバーを立ち上げるために、EC2またはECS on Fargateなどでサーバーを作り、ネットワークを連携して再現できます。

この方法では前述の通り、フロントエンドの状態管理周りが密結合になってしまうなどの難がありました。また、MPAではユーザーがサイトを移動するためにHTMLを全リロードをするため、動きがモサモサして見えるのはUXにとっては大きな難点になります。そういった面を解消すべく、続いて登場するのがフロントの処理を切り出したSPA(シングルページアプリケーション)です。

SPA(Clientside Rendering)

MPAではあったビューの部分は、SPAでは全てJavaScriptに置き換わります。そのために、AWS S3などの静的ホスティングサービスを活用します。SPAでは、ビューを生成するJavaScriptのファイルを事前にビルドしたブラウザが解釈できる単一ファイルを、そういったホスティングサービスが持つストレージに格納しておくことで、パソコンからアクセスが来たときにブラウザがHTMLを生成して、JavaScriptを実行させ、そのときにアプリケーションサーバーと通信することでそれをイベントごとにブラウザに投げて解釈させることによって、動的な動きを実現しています。

コンテンツを配信するWebサーバーの働きはS3やNetlifyといったホスティングサービスが担うことになり、従来まであったWebサーバーを置くことは必須ではなくなることに注意が必要です。ただし、負荷分散のためにリバースプロキシとして設置するなどの用途で、Webサーバーを配置することは要件によって必要であり、負荷が多い実際の現場ではそういったWebサーバーとともにCloudFrontなどのCDNをさらに配置し、より高速なコンテンツ配信を行うことは多いです。なおクライアントサイドでHTMLをレンダリングしていることから、CSRと呼ばれています。

SSR(Serverside Rendering)

SSRはNext.jsなどの技術で実現できます。Next.jsはNode.jsの環境で動くフレームワークで、Next.jsをサーバーに置くと、SPAとは違って事前に、ビルドやアクセスなどのタイミングでサーバー側でHTMLを生成しています。また、Next.js自身がWebサーバーとしても動くため、実質Next.jsはアプリケーションサーバーおよびWebサーバー双方の働きを実現しています。また、Next.js自体がAPI実装の機能をサポートしているため、APIを完結させることも可能ですが、一般にはAPIサーバーを別にたて、Next.jsのいるサーバーとで疎通を行なっている現場が多いように見受けられます。

SPAと同じように、Nginxを活用したリバースプロキシや、CloudFrontなどでCDNを行なったり、周辺技術は似通っていますがポイントはSPAでは資源がストレージに上げられ、HTMLがブラウザで生成される一方、SSRでは資源がサーバーにあげられ、HTMLがサーバーで生成されることです。また、Next.jsではページごとにCSR、SSR、SSG(静的サイト生成)を選んでの最適化もできることから、フロントエンド側のニーズに沿った要件にも対応しやすいことが挙げられます。

今後はどうなるのか？に関する予測

SSRを行うことによって、必要なサーバーの管理が増えてしまうのは上記で見た通りで、エンジニアの管理コストが増えてしまうのは事実です。一方で、ToCアプリであってもSPAを使う企業はあり、例えばautoreserveなどのサービスはSPAで出来たToCアプリですが、筆者が最近LightHouseでSEOを解析すると100点を叩き出しており、React Native for Webを用いて開発コードを共通化していることから、SEOと開発効率を両立している貴重な例であると言えます。

著者の考えとして、現状確証を持って言えないことですが、GoogleがSPAサイトであっても十分なクロールを行い、SPAであってもSEOとしても問題ないことがわかると、NextでSSRをするような流れは落ち着き、ToCであってもSPAで構築するような例は増えて来る可能性もあると見ています。

最後に:結局どれを使えばいいの？

私なら、以下のように使い分けます。サクサクとした動きを実現したい場合はSPAを使う。速度やSEOなどといった要件が強いサービスの場合はSSRを使う。スケールする予定がない、フロントエンドで求められる高い要件が特になく、動きがモサモサしていても良い場合はMPAを使う。

SSRを使わずMPAを使えば良いのではないか、という声を聞きますが、それでも筆者はなおSSRには以下2つのメリットがあると考えます。1つ目は、速度が最適化されることです。実際のサービスではSEOで求められる要件を高くキープする必要があるため、SEOに強く貢献する観点です。また、実際のToCサービスでは圧倒的にモバイルユーザーが多い傾向にある一方、一般にモバイルはデスクトップに比べてCPUなどの処理性能が劣るため、表示までの処理が重いサイトにアクセスすると多大な時間がかかり、またキャンペーンサイトなどで通信が集中しすぎると、輻輳が起きたりとネットワークが遅く、表示速度も遅くなるとユーザーのサイト離脱への要因になってしまいます。2つ目は、フロント開発の関心を分離できる点です。MPAのMVCにおいて、MとV同士が複雑に絡み合い、再改修が大変になってしまうことは前述の通りで、フロントエンドの関心をJavaScriptのレポジトリに切り出すことで、より状態管理をしやすくなり、また変更可用性を持って事業側の要求にもスピーディな開発ができることは大きなメリットだと感じています。