Chapter 11無料公開

Edge Side Composition

okmttdhr
okmttdhr
2020.12.14に更新

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にコンピューティング環境という武器を付与した夢のあるアーキテクチャといえますが、よく理解して使用する必要があると思います。