2022/02/07

Fastlyを導入しました！

Masanori Iwakura

2021年11月9日、トラベルブック( www.travelbook.co.jp )ドメインに対してFastlyを適用しました。 トラベルブックでのFastlyの活用方法、設定、運用について記載します。

Fastlyとは？

CDN、画像の最適化、ビデオとストリーミング、クラウドセキュリティ、負荷分散などを提供してくれるサービスです。

Fastly公式

今回の記事ではCDNについて語ります。

Fastlyを導入した経緯

トラベルブックではバックエンドレスポンスの高速化、サーバー負荷を減らす目的で Varnish をEC2に入れて使用していました。

トラベルブック内のページ(記事やLP)は頻繁に内容が変わらないのでキャッシュと相性が良く、日に日に対象ページが増えてきました。

そしてふと思いました。 Varnishサーバーがダウンしたらサイトの大半がダウンするのでは？？

はい、そうです。1つのEC2で運用していたのでVarnishサーバーが単一障害点となってしまいました。

yusukebe さんに相談したところ、 Varnishの冗長化 = Fastlyが良さそう！！ との結論に至り、導入を検討しました。

Fastly導入

Fastlyにはトライアルがあるので、まずはトライアルでサイトをプロキシする形で検証を行いました。

参考: アカウントの種類と料金プラン

Fastlyはドキュメントがとても充実しているので、初期設定は こちら を参考に進めました。

元々Varnishを使用していため、 VCL(Varnish Configuration Language) を使用した設定はそこまで苦戦しませんでした。

また、FastlyのVCLは自動生成される部分と手動で設定する部分があるのでVarnishと異なり、必要最低限の設定を自分で行う対応で済みました。 (手動ルーティングやページごとのTTL設定などを手動設定)

トライアルアカウントでの検証後、Fastlyのサポートに問い合わせて契約となりました。

トラベルブックのFastly運用方針

トラベルブックではインフラリソースを主に Terraform で管理しています。 FastlyもTerraformに対応しているため、リソース管理はTerraformで管理することとしました。

Fastly Provider

例により、Fastlyのドキュメントは本当に充実しているので参考になる記事が豊富です。
(ありがたや)

Terraform を使った Fastly サービスの設定方法

リポジトリの構成は公式の こちら を参考に以下の構成としました。

.
├── modules
│   ├── service-compute
│   │   ├── main.tf
│   │   └── provider.tf
│   └── service-vcl
│       ├── main.tf
│       ├── provider.tf
│       ├── templates
│       │   └── datadog_logging.json
│       ├── variables.tf
│       └── vcl
│           └── main.vcl
├── production
│   ├── main.tf
│   ├── provider.tf
│   └── variables.tf
└── staging
    ├── main.tf
    ├── provider.tf
    └── variables.tf

現在はVCLで運用していますが、将来的に Compute@Edge を使用することも視野に入れて service-compute のディレクトリを切っています。

トラベルブックではDatadogを使用して監視を行なっているため、FastlyのログをDatadogに送る設定を行なっています。

Fastly導入後

Fastly導入後、以下の構成イメージとなりました。

  1. www.travelbook.co.jp ドメインにアクセス
  2. Route53からFastlyに転送
  3. FastlyでどちらのALBに飛ばすか振り分け
  4. EC2 or Fargateへルーティング

※トラベルブックのサービスはEC2とFargateが混在している関係でALBが2つ存在しています。

Fastlyは世界各地のデータセンターにキャッシュを配置するため、当初の目的であった冗長化を達成しました！！
(これで枕を高くして眠れるようになりました)

また、Fastlyには 失効済みコンテンツの配信 機能があるため、より障害に強くなると言うメリットもありました。

こちらの設定を適用することにより、バックエンドのサーバーで障害が発生した場合にFastlyが一定期間キャッシュを返却してくれるのでユーザーに障害を認識させないようにすることが可能です。

パフォーマンスの向上

Varnishのキャッシュ対象ページは数ページ程度でしたが、Fastlyではほぼ全ページをキャッシュする構成としました。
Varnish(EC2運用)の時はサーバーのメモリ次第では頻繁にLRUが発生する恐れがあったため、Fastlyにしてからはその恐怖ともおさらばできました。

結果、各ページのTTFBも飛躍的に改善しました。

こちらのグラフは主要ページと、より効果が高かったページのみ抽出した結果です。
まとめページは元からVarnishでキャッシュしていたので飛躍的な改善では無いですが、
高速バスやLPについてはかなりの速度改善に繋がりました。
(実は棒グラフは500ms以上あったので一部削れています)

技術的に攻めたポイント

Fastly導入に当り、折角なのでよりパフォーマンスを向上させようと以下の技術を採用しました。

  • Brotliを使用したページ圧縮
  • HTTP/3(QUIC)の導入

Brotliの設定

WEBページの圧縮形式として一般的なのは gzipのイメージですが、近年では Brotli と言う圧縮形式が発表されています。

2022年2月現在、Edge, Firefox, Chrome, Safariなどの主要ブラウザで対応しています。

参考: Can I use

Brotliの何が良いかと言いますと、圧縮率の高さです。 では実際に比較してみましょう。

# 圧縮無し
$ curl --head https://www.travelbook.co.jp/
HTTP/2 200
content-length: 129924

# gzip圧縮の場合
$ curl --head -H "Accept-Encoding: gzip" https://www.travelbook.co.jp/
HTTP/2 200
content-encoding: gzip
content-length: 19280

# Brotli圧縮の場合
$ curl --head -H "Accept-Encoding: br" https://www.travelbook.co.jp/
HTTP/2 200
content-encoding: br
content-length: 13001
圧縮形式 サイズ(bytes)
無し 129924
gzip 19280
Brotli 13001

トラベルブックのトップページでは表の通り、Brotliに軍配が上がりました。
※ページによって圧縮率の差が異なる場合があるのであくまでも参考です

HTTP/3(QUIC)の導入

HTTP/3は2019年9月26日に Cloudflare, Chrome でサポートされたHTTPの新バージョンです。

従来のHTTP/2はTCPでの通信ですが、HTTP/3はQUIC(UDPベース)を使用することでより速度を向上させています。

TCPは3ウェイハンドシェイクと呼ばれる接続手順を踏み、名称の通り3回のやり取りが発生しますが、HTTP/3(QUIC)はこのやり取りを短縮することで効率化しています。

ブラウザで確認すると、ご覧の通りトラベルブックではHTTP/3に対応しています！！

まとめ

今回はトラベルブックでのFastlyの導入について記載しました。
導入に当り、 BrotliやHTTP/3(QUIC)と言った新技術に触れる機会にもなりました！
これからもFastlyをフル活用して貪欲にサイトパフォーマンスの向上を目指して行きます。

エンジニア募集中！

最後に、トラベルブックではエンジニアを募集中です。
Fastlyに興味がある方、フロント、バックエンドの開発に関わりたい方は是非ご応募ください！

バックエンド