GitHub は開発者がソフトウェアを共同開発するための最も容易な手段であり、世界中の1,200万以上のリポジトリにわたり、580万人の開発者によるコラボレーションへと拡大しています。GitHub は Fastly と協力して CDN のセットアップをカスタマイズし、コンテンツを高速かつ効率的に配信しています。Fastly は、GitHub.com、Pages (GitHub Webサイトのホスティングサービス)、raw.github.com の前面に配置され、すべての静的アセットを配信しています。

一晩での設定

GitHub は Fastly を使用して必要な新機能の構築に着手し、以前の CDN プロバイダーのネットワークがダウンした際には残りのコンテンツの多くを一晩で Fastly に移行しました。Fastly のサービスは完全なセルフプロビジョニング型で、非常に短時間でセットアップできるため、攻撃を受けている最中にも関わらず、GitHub はセールス担当者に頼らずに Fastly への切り換えやサービスの設定を迅速に行うことができました。

GitHub では、DoS 攻撃を頻繁に受けていた他のサービスの前面に Fastly を配置しました。Fastly のグレースモード機能を利用することでエラーではなくキャッシュから失効済みコンテンツを配信し、エンドユーザーへの攻撃の影響を制限することができています。

速度と信頼性の向上

Fastly に移行する以前、リクエストスパイクによりオリジンサーバーに過大な負荷がかかった際、GitHub Pages では継続的に高いパフォーマンス負荷が発生していました。このようなスパイクを均一化し Pages の急速に広まる性質を管理するため、Fastly は各データセンターに GitHub 専用の IP アドレスを割り当てました。これにより Pages で作成された何十万ものカスタムドメインが Fastly を通過できるようになりました。その結果、Pages の各 Webサイトのスピードが加速し、オリジンへのリクエストが最小限に抑えられ、Pages の速度と信頼性が向上しました。この比較では、サイトの読み込み速度において、Pages は Arvixe、Windows Azure、Amazon AWS を上回っています。

オリジンサーバーの負荷軽減

GitHub は Fastly を使って、GitHub リポジトリの未加工のレンダリング済みファイルなどの動的コンテンツもキャッシュしています。これらのファイルを Fastly でキャッシュする前は、数千台のマシンが自動アクションを実行するためにユーザー生成コンテンツをリクエストした際、Raw.GitHub では一定の間隔で大規模なリクエストスパイクが発生していました。Raw の前面に Fastly を配置することで、同一コンテンツへの複数のリクエストが単一のリクエストにまとめられ、オリジンへの負担が大幅に軽減されます。

成長に合わせてスケールアップ

GitHub にとって、今や Fastly は重要なパートナーです。GitHub は近年急速に成長を遂げており、インフラストラクチャの主要コンポーネントを再構築する際は Fastly を利用してサービスの拡張に役立てています。Fastly を利用することで GitHub はメインサイトの容量計画に集中できるようになり、同時に Raw や Pages といったその他人気サービスのサポートもパフォーマンスを犠牲にすることなく継続できています。