Edge Side Compositionは、CDNなどのエッジレイヤーでコンテンツを結合する技術のことです。
ここでのEdge Side Compositionは、Edge SideでFragmentsを結合したり、レンダリングをするような処理を想定しています。
Edge Side Includes
先ほど紹介したESIもEdge Side Compositionの一種と捉えることができます。
Edge Side Rendering
ここでは、Edge Sideで動くFaaS等を使ったSSRをEdge Side Renderingと呼んでいます。例えば、Lambda@EdgeとServerless Frameworkを使い、Next.jsをEdge Side Renderingする手法、Flareactというフレームワークを使ってCloudflare WorkersでEdge Side Renderingする手法などがあります。
これまでサーバーが担当していたような動的な処理はEdge Side FaaSで受け持ち、静的なコンテンツは配信するだけ、というアーキテクチャが実現できます。
メリット・デメリット
メリット
Edge Side Compositionはその名の通り、Compositionに関してサーバーのリソースを用意する必要がない点が大きな特徴です。すべてがEdge Sideで完結するため、シンプルなレンダリングサーバーのために、大げさなコンピューティング環境を用意し、管理する必要はありません。また、レイテンシの観点では、Edge Sideで処理が行われるため、単純なNodeサーバーに対して優位となるでしょう。
スケーリングに関してもメリットがあります。例えば、ReactなどでSSRをする場合、Node.jsの性質がCPU-boundを起こすケースがあります。Edge Side Compositionでは、サーバーレスコンピューティング環境を使用することを想定しているため、インフラのスケーリングに関しての考慮を減らすことができます。また、例えば、AWS Lambdaなどでは基本的にリクエストごとの水平スケーリングとなるため、そういう意味でも、CPU-boundの可能性は削減できます。
デメリット
実際のレンダリングなどのロジックは、なんらかのFaaSを利用することが多いと思います。マネージドであるが故に、そのクォータはデメリットになり得るでしょう。例えば、AWS Lambdaでは、以下のような制限が存在します。
- タイムアウト - 15分, Lambda EdgeではViewer 5秒、Origin 30秒
- レスポンスサイズ - 6MB, Lambda EdgeではViewer 40KB、Origin 1MB
- 関数自体のサイズ - 50MB, Lambda EdgeではViewer 1MB、Origin 50MB
例えば、関数のサイズに関しては、レンダリングに関するモジュールをコンパクトにパッケージングするなどの工夫が必要です。また、CloudFormationなどの構成管理ツールを使用する場合、リソース数の上限や、そのIaCの設計なども考慮する必要があります。コールドスタートなども検討余地のあるポイントです。このように、Faasを使う場合、実際のアプリケーション要件を満たすものなのかは事前に調査、合意しておく必要があるでしょう。
上記のような制限に悩みたくないのであれば、Fargateなどのマネージドなコンピューティング環境 + CDNのようなアーキテクチャ、または、そもそもECSやEKSでのスケーリングを検討したほうが良いのではとも思います(この章の話からは逸脱しますが)。
まとめ
Edge Side CompositionはJAMstackにコンピューティング環境という武器を付与した夢のあるアーキテクチャといえますが、よく理解して使用する必要があると思います。