Fastlyの技術的な企業分析

投資家の興奮の多くは、Fastlyが現在提供しているコンテンツ配信ネットワーク（CDN）を大幅に拡張した「Compute@Edge」のリリースにも向けられている。この製品はベータ版なので、収益にどの程度の影響があるかは明らかではない。

吉田拓史

2020年9月25日 — 10 min read

要点

FastlyのエッジサーバーはAkamaiなどの競合他社よりも著しく少数。そのかわりエッジサーバーを徹底的にカスタマイズし、ネットワークの要所に配置
Fastlyでは、利用者がキャッシュコンテンツを入れ替えたいときには即時的に実行できる
従来のCDNでは、このために一定の待ち時間があり、顧客の痛点だった。Fastlyは柔軟性が高く、業界の重要顧客の支持を得ている

最近、Fastlyの株価は信じられないような動きを見せてきた。5月6日に第1四半期決算を発表して以来、株価は2倍以上に上昇した。これは主に、COVID-19に関連して第2四半期と今年の残りの業績見通しが大幅に向上したことに起因しているようだ。Amazon.comがコンテンツ配信にFastly POPを使用しているという観測など、他のサプライズもあった。

投資家の興奮の一部は、Fastlyが現在提供しているコンテンツ配信ネットワーク（CDN）を大幅に拡張した「Compute@Edge」のリリースにも向けられている。この製品はベータ版なので、収益にどの程度の影響があるかは明らかではない。

インターネットメディアに携わった私としては、Fastlyは近年非常に注目されていたCDNとして認知している。弊社のサービスがスケールしたら使う気まんまんである。日本でも日本経済新聞社がFastryを採用し、表示速度を2倍にした事例は業界内ではよく知られている。しかし、一般には余り知られていない。

ところが最近は投資家の関心を買っていることがわかった。このタイミングでFastryが過去にどのように新しい技術の構築にアプローチしてきたか、そしてこれが将来の「エッジコンピュート」の提供にどう影響するのかを調べる意味があるように思われた。それは投資家の人たちのためにもなるだろう。この「分かりやすい解説」は、難しい部分は読み飛ばして感じて頂けるとありがたい。

Fastlyのルーツと旧世代のCDN

Fastlyは2011年にArtur Bergmanによって設立されたが、これはウェブ百科事典のための人気ホスティングサービスであるWikiaのCTOとして、既存のCDNソリューションを使用していたことに不満を感じたことがきっかけだった。当時、CDNの提供は、Akamaiや Limelightなどの大手企業や、Amazon Cloudfrontのようなクラウドベンダーの新興CDN製品に支配されていた。

Arturは2010年頃、既存のCDNの機能に不満を感じるようになった。彼は、CDNの設定を調整するためにテクニカルサポートが必要であること、変更がデプロイされるまでに時間がかかることに不満を感じていた。既存のソリューションはプログラマビリティを欠いており、DevOpsによってアプリケーションのパフォーマンスと稼働時間についての議論に引き込まれることが増えていたエンジニアリングチームから厳しく評価されていた。実践的な技術的背景を持つArtur は、より良いソリューションを構築できると判断し、それを実現した。

Fastlyのチーフプロダクトアーキテクトは最近、「Fastlyは、第一原理から問題を見て、顧客の利益になると分かっていれば、難しいプロジェクトにも臆することなく取り組むという長い歴史を持っている」と述べている。このアプローチは、ZoomのEric Yuanと、より優れたビデオ会議ソリューションを構築するための挑戦を思い起こさせる。2011年当時、多くの人が主にコモディティ化した空間であると考える WebExやSkypeの既存のビデオ会議サービスを改善できるとEricが考えたのはなぜだろうか、と疑問を抱くのは簡単だったでしょう。しかし、Zoomの成功は、ユーザーにより良い体験を少しずつ提供することに集中したことに起因している。

ネットワーク設計への応用

Fastlyは当初、資金繰りが苦しいスタートアップ企業としてスタートしたが、コンテンツ配信ネットワークの設計にこのアプローチを適用した。ネットワークとサーバーのハードウェアを、世界中の多くの POP（Point of Presence: 通信を行うエンティティ間の人工的な境界点）に標準的な構成で配置するという共通の道を歩むことができた。

しかし、CDNに対する別のアプローチを設計した。現金を節約する必要があったこともあり、チームは、商用製品ではなく独自のカスタムソフトウェアモジュールを使用して共通の機能に取り組むことにした。このソフトウェア主導の設計は何度も成果を上げており、コンテンツ配信のユースケースの変化に応じてネットワーク設計を柔軟に進化させることができた。

最初の問題として、FastlyチームはPOPに出入りするネットワーキングトラフィックを処理するアプローチを検討した。標準的な構成は、インターネットのルーティングテーブル全体をメモリ空間に保存できるボーダールーターを購入することだった。スイッチは安価だったが、インターネット・ルーティングを完全に処理するために必要なメモリや計算能力はなかった。

2013年、Arista Networksは、ユーザーが独自のソフトウェアを実行できるスイッチの販売を開始した。これがFastlyチームにとって最適なソリューションとなった。そこでArista Networksは、独自の分散型ルーティング・エージェントであるSilvertonを開発し、Fastly POP内のルート設定をオーケストレーションすることにした（Silvertonは、Border Gateway Protocol DaemonであるBIRDとピアリングし、外部インターネットとのインターフェースを提供する）。

この組み合わせにより、Fastlyのカスタマイズされたスイッチは、より高価なボーダールーター（境界に位置するルーター）として機能するようになり、POPを導入するたびに何十万ドルものコストを節約することができました。また、外部ルーティングロジックをホストレベルにプッシュすることで、スイッチの負荷を軽減し、ユーザーの要求に応じてトラフィックルーティングをより細かく制御できるようになった。

Silvertonをカスタム設計することで、FastlyチームはPOP内のルーティング管理を完全に制御できるようになり、ネットワークパスの選択をアプリケーションレベルに押し上げ、ネットワークの動作をはるかに大きく制御できるようになった、とDirector EngineeringのJoão Taveira Araújoはブログで説明している。これはその後、特定のタイプのコンテンツやユースケースに対して選択的にルート選択をオーバーライドするために反復され、一般的にボーダールーターで単一のルーティングルールをすべてのケースに適用する既存のソリューションよりも優れたコンテンツ配信パフォーマンスを実現している。

**Figure 1:** ARP propagation using Silverton, Source: João Taveira Araújo. Building and scaling the Fastly network, part 1: Fighting the FIB.

次の問題として、Fastlyチームは、多くの小さなPOPを地理的に世界中に分散させることが、ユーザーコンテンツの全体的な配信時間の最適化につながるという仮説を疑った。これは、他のレガシーCDNが都市レベルにまで分散した数百、数千の小さなPOPに投資していることを正当化する説だった。この「数は力なり」の哲学は、レガシーCDNのプレイヤーによって今日でも優位性の証拠として提示されている。

実際には、各々の小さなPOPでキャッシュできるコンテンツの量は限られているため、必ずしもそうではない。ユーザーリクエストのかなりの割合をオリジンサーバーに送り返す必要があり、それらのリクエストのアクセス時間は10倍以上に増加する。例えば、キャッシュミスの割合がわずか10%増加した場合、全体の平均アクセス時間が50%以上増加する可能性がある。より多くのストレージ容量を持つPOPの数を減らすことが、実際には平均配信時間の高速化につながる、というのが、Fastlyチームの結論だった。

2016年のブログ記事では、Fastlyの共同創業者の一人が、コンビニとスーパーの類推をしている。コンビニエンスストアは一般的に人の家に近いが、売られている商品は限られている。もし人がスーパーまであと数マイル車を走らせれば、一度の旅行ですべての食料品を手に入れることができる。この場合、コンビニエンスストアは、多くのローカルPOPを持つレガシーCDNによって取られたアプローチを表しており、スーパーマーケットは、より少なく、より大きなものを持つFastlyのアプローチを表している。

これが、競合他社が何千ものPOPを宣伝しているのに対し、Fastlyは世界中に限られた数のPOPのみを保有する理由だ（2020年第1四半期現在、合計72個）。FastlyのPOPは、地理的な地域への近接性を提供しながらも、ユーザーリクエストのヒット率を大幅に向上させるためのストレージ容量を持つ、ネットワークの交差点に巧みに配置されている。

さらに、Fastlyはキャッシュされたデータを保存するために当時は比較的新しいSSDを利用することを選択した。SSDは標準的なディスクよりも高価だが、RAM と同等のはるかに高速な検索時間を提供する。Fastlyの調査によると、一般的なハードドライブは、読み込み時に約450 IOPS（Input/Output Per Second / I/O毎秒）、書き込み時に約300-400 IOPSを実行することができる（4kbのファイルを使用したテストの場合）。しかし、Fastlyが使用しているSSDは、読み込み時に75,000 IOPS、書き込み時に11,500 IOPSの範囲内で実行されている。

この設計選択は、POP内でのデータ検索を超高速にすることで、Fastlyの平均応答時間を短縮することに貢献した。当時、POP内の各サーバには384GBのRAMと6TBのSSDスペース（12x500GBのドライブで構成）があり、各CPUには25MBのL3キャッシュ（メインメモリから読み込んだ命令やデータを一時的に保管しておく領域の一つ）が搭載されていた。一般的なPOPでは32台のマシンがこのような仕様になっていた。

しかし、Fastlyはそれだけにとどまらなかった。彼らはまた、ファイルシステムをバイパスして、SSDからパフォーマンスの最後の一滴まで絞り出し、可能な限り多くのデータを詰め込むために、POPサーバー用のカスタムストレージエンジンを書いた。彼らは様々なアルゴリズムを採用して、一般的に使用されるデータを384GBのRAMに保持し、さらに高速化している。「いいね！」ボタンや「シェア」ボタンのように、変更されることがなく、1秒間に何百万回もリクエストされるようなアセットについては、プロセッサから直接L3キャッシュ（CPUとメインメモリの仲立ちをする役割のメモリ）を提供することで、さらに高速化を図っている。

既存のCDNの3番目の問題として、Fastlyは、アプリケーションの配信を担当する顧客組織内の開発者やエンジニアの経験を試験した。これらの人々は、配信するコンテンツの変更を管理するためのツールやコントロールが不足していることに不満を感じていた。一般的な不満は、レガシープロバイダが変更を展開するために技術サポート要員を必要とし、コンテンツのパージに何時間もかかることだった。

さらに、動的コンテンツをプログラムでキャッシュしたり、ユーザーのリクエストを評価するためにFastlyのエッジノードでカスタムロジックを実行したりする機能も限られていた。これに対応するため、FastlyはVarnish Configuration Language (VCL) を通じてコンテンツ制御にプログラマビリティを追加した。Varnishは、ハイパフォーマンス配信のために設計されたオープンソースのウェブアクセラレータだ。FastlyではVarnish 2.1のカスタマイズ版を使用しており、Fastlyのエンジニアは一般的なオープンソースプロジェクトに貢献し続けている。

FastlyのVarnishのカスタマイズにより、基本的な機能が拡張され、Fastlyのグローバルな配信ネットワーク上で動作するようになった。Varnishは、コンテンツの即時パージ（ダイナミックコンテンツのキャッシュを有効にするために必要）、リバースプロキシ、リアルタイムのパフォーマンス監視、カスタムキャッシュポリシー定義など、ユーザーにとって便利な機能を提供する。顧客は、独自のVCLスクリプトを作成し、FastlyのPOPにアップロードし、その場で有効化/無効化することができる。これにより、顧客はカスタムキャッシュルールの展開を細かく制御することができる。

Anna MacLachlanは「VarnishソフトウェアとFastlyのSSDサーバーを組み合わせることで、従来のキャッシュの最大12倍のパフォーマンスと容量を提供する」とブログ記事で説明している。

これは、間違いを迅速にロールバック（巻き戻し）する必要がある本番リリースでは特に重要だ。当時の競合他社の製品では、メンテナンスウィンドウと長いロールバック期間が必要だった。設定にバグが含まれていた場合、修正がロールアウトされるまでに何時間もかかることもあった。

私はDIGIDAY[日本版]で働いていた時、レガシーCDNでこの苦痛を経験した。インターネットメディアでは、多量の記事コンテンツを投下するが、それに修正が加えられることは少なくない。難しい修正というものが存在し、それがCDNに反映されるまでのタイムラグには常にやきもきさせられた。

Fastlyはコンテンツ配信ソリューションのほぼすべての側面をカスタマイズして、プログラム可能で、パフォーマンスが高く、コスト効率の良いものにした。このアプローチにより、Fastlyは当時の競合他社との差別化を図り、レガシーCDN業界を混乱させた。

この戦略はうまくいっている。Fastlyは、最も目の肥えた、急成長を遂げている顧客のリストを蓄積してきた。その中には、Shopify、Stripe、Spotify、Slack、Twitter、Pinterest、GitHubなどが含まれている。これらの企業では、ソフトウェアエンジニアがFastlyの担当者と密接に連携して、超高速配信のための最適なソリューションの限界を押し広げている。

分散型コンピューティングへの跳躍

数年前、Fastlyは、POPインフラストラクチャ内でフル機能の開発環境を可能にする別の機会を見つけた。これにより、開発者はコアアプリケーションを補完する自律的なロジックを作成することができるようになる、という方向性が立ち上がった。Fastly は顧客のインフラストラクチャへのユーザーリクエストのエントリーポイントとなることが多いため、Fastlyチームは、「エッジ」上のこれらのエントリーポイントでの処理能力を向上させ、集中型データセンターですべてのロジックを実行する必要性を減らすことができる可能性があると考えている。

一例として、カーン・アカデミーは2020年5月にエンジニアリング・ブログに投稿を掲載し、3月に2週間の期間で2.5倍の使用量に急速にスケールアップできた方法を説明している。著者は、パフォーマンスを向上させ、オリジンのデータセンターにあるバックエンドのGCP計算インフラに送られるトラフィックを減らすために、すべてのクライアントリクエストを最初にFastlyを通過させる方法を説明している。カーン・アカデミーは、Fastlyで静的なコンテンツをキャッシュするだけでなく、一般的なクエリ、ユーザー設定、およびセッション・データも広範囲にキャッシュしている。これはすべて、集中化されたサーバーに戻る往復の手間を省くことで、ユーザー・エクスペリエンスを高速化するために使用される。

Fastlyの賭けは、顧客の要求に基づいて、より多くのアプリケーションロジックをFastlyの分散POPで実行できるようにすることだ。これは、ユーザーとの距離が近く、レスポンスが良いという利点がある。また、場合によってはセキュリティ上のメリットもある。この傾向が進めば、データ処理のスライスが集中型データセンターからFastlyのような分散型コンピュートプラットフォームに移ることが多くなるでしょう。

Fastlyのこの分散コンピュートのためのソリューションは「Compute@Edge」と呼ばれ、2019年11月に発表された。Compute@Edgeは現在、一部の顧客のためののベータ版となっている。Artur Bergmanは、6月に行われたBairdのカンファレンスコールでCompute@Edgeのアップデートを行った。彼はベータ版の顧客からの多くのユースケースについて議論した。パーソナライゼーションは共通のテーマであり、ユーザー認証をエッジで実行し、承認されたコンテンツを迅速に組み立てて返すことができる。彼はまた、機械学習による推論処理、IoTデータストリームの要約、そして潜在的なゲームに関する他の機会についても強調した。

Bergmanは、Compute@Edgeをセキュリティのユースケースに適用する際の興味深いコンセプトについて言及したが、これらは顧客によって浮上したものであり、Fastlyは考慮していなかった。計画では、2020年までベータプログラムを継続し、来年にはGAに移行する予定である。

2017年10月に開催されたVelocity Conferenceでは、FastlyのCTOのTyler McMullenが「Edge Compute - The Missing Pieces」と題して基調講演を行った。彼は講演のなかで、エッジコンピュートの意味を、従来オリジンサーバーで実行されていたロジックをネットワークの「ブランチやリーフ」に押し出すことと定義している。具体的には、従来のクラウドベースのアプリケーションでは、ロジックをデータセンターに集中させている。これは、ユーザーが地理的にどこにいるかに関係なく、ユーザーのデバイスと直接通信する。もちろん、一部の静的コンテンツはCDNによってローカルに配信されるが、実際のビジネスロジックやキャッシュされたデータストレージは、一般的にデータセンターで実行される。データセンターとユーザーのデバイスの間には、多数のネットワーク・ホップが存在する。Fastlyは、アプリケーション・ロジックの一部をデータセンターから押し出して、ユーザーのデバイスの近くで処理することができると理論化している。

このビジョンを踏まえて、「エッジコンピュート」とは、大規模で協調性のない分散システムを実現するための開発環境を提供することだとMcMullenは述べている。これらのシステムは、オリジンの外のどこにいても自律的に実行することができる。このような分散コンピューティングを可能にする開発プラットフォームを提供することが、FastlyのCompute@Edgeのビジョンである。これは従来のCDNをはるかに超えたものだ。高速で安全な分散コンピューティングを世界中のどこでも大規模に実現する環境を構築することは、はるかに困難な問題だ。

参考文献

Sean Leach. Performance matters: why Compute@Edge does not yet support JavaScript. Fastly. June 29, 2020.
Nick Rockwell. Open Questions: A Conversation with Fastly CEO Artur Bergman. NYT Open. Sep 7, 2018.
João Taveira Araújo. Building and scaling the Fastly network, part 1: Fighting the FIB. Fastly. May 11, 2016.
João Taveira Araújo, Lorenzo Saino, Lennert Buytenhek. Building and scaling the Fastly network, part 2: balancing requests. Fastly. December 8, 2016.
Lucet: Safe WebAssembly Outside the Browser, Fastly CTO, Feb 2020
Stacey Higginbotham. Startup Fastly offers radical new CDN using flash memory. Gigaom. Oct 7, 2011.
Artur Bergman. Just use SSDs, really really. Jun 16, 2011.
Marta Kosarchyn. How Khan Academy Successfully Handled 2.5x Traffic in a Week. Khan Academy, MAY 9, 2020
高岡将，xcir. 第14回［キャリアアップ編⑤］varnishを使おう④─実践varnish. gihyo.jp, 2010年12月27日.
Peter Bourgon. Infinite Parallel Universes: State at the Edge, QCon, Fastly Tech Lead and author of Go kit, Infoq.com. April 2020.

Photo: "Oreilly Velocity Dev-Ops" by Orminternal is licensed under CC BY-NC 2.0.

分かりやすい解説シリーズ

Special thanks to supporters !

Shogo Otani, 林祐輔, 鈴木卓也, Mayumi Nakamura, Kinoco, Masatoshi Yokota, Yohei Onishi, Tomochika Hara, 秋元善次, Satoshi Takeda, Ken Manabe, Yasuhiro Hatabe, 4383, lostworld, ogawaa1218, txpyr12, shimon8470, tokyo_h, kkawakami, nakamatchy, wslash, TS, ikebukurou 太郎.