Fastly で高速化した Kubernetes

スケーリングする必要がある場合、ほとんどの人が Kubernetes を利用します。しかし Kubernetes のチーム自身がスケーリングと効率を改善する必要に迫られた際、彼らは Fastly を選んだのです。同チームは、毎月 Kubernetes の公式バイナリサービスからダウンロードされる5ペタバイトを超えるデータを世界中のユーザーに配信するのに役立つ、より優れた新しいソリューションを求めていました。私たちはまず、Kubernetes のダウンロードの高速化とスケールアップに取り組み、さらに同チームが気づいていなかった問題の全体像を明らかにしました。

スピードにまず魅かれ、リアルタイムログに魅了

Kubernetes チームは Fastly を採用することで、ダウンロードの高速化とデータ通信コストの削減を実現し、サービスに悪影響を及ぼすことなくバックエンドで簡単に変更を実行できるようにしたいと考えました。しかし、Fastly にダウンロードトラフィックを移行したところ、Kubernetes チームを最も感動させたのは、ログ機能やメトリクスへのアクセスなど、Fastly の優れた可観測性でした。これらの機能を通じて同チームは、それまで見落としていた問題を特定することができたのです。Fastly を採用した理由など詳細については、Kubernetes チームによるこちらの記事をご覧ください。

トラフィックの移行時に関するこちらの動画では、実際に何が起きたのかをご確認いただけます。Fastly を通過するトラフィックの量が予想よりかなり少なかったことに私たちは非常に驚きました。それまで Kubernetes チームはトラフィックに対する可視性や優れたモニタリング機能を利用できず、リアルタイムでトラフィックデータにアクセスすることは不可能でした。DNS とネットワークのエンジニアリングは非常に複雑で不透明なケースがありますが、Kubernetes チームは Fastly によってトラフィックパターンを確認できるようになりました。トラフィックを Fastly に切り替えた瞬間から、チームは何らかの異常の存在に気づきました。Kubernetes チームと Fastly の Mission Control チームは、バイナリダウンロードの大量のリクエストが、本来ポイントされるべき抽象化された新しい URL (cdn.dl.k8s.io) ではなく、直接 Google Cloud Storage バケットにポイントされていることを迅速に突き止めたのです。調査の結果、プロジェクトの非常に初期の段階でオリジンのホストネームが一般公開されてしまい、プロジェクト内や、より広範なコミュニティで削除しようと努めたものの、ハードコードされた GCS バケットのホストネームのインスタンスが今でも多数存在します。Fastly への移行と、トラフィックデータに直接アクセスできるシンプルな Fastly の可観測性機能により、プロジェクトの開始以降初めてこの問題が目の前で明らかにされたのです。 

Kubernetes チームはこの情報をもとに、バイナリをダウンロードする世界中のユーザーからのリクエストが新しいドメインをポイントするようにする新たな取り組みを開始します。バイナリが Fastly から配信されるようになったことで、サービスに悪影響を及ぼすことなく、また K8s のダウンロードを試みるすべてのユーザーにこれ以上変更を求めることなく、Kubernetes チームは変更を加えたり、コミュニティが所有する GCS バケットへの将来的な移行に取り組んだりする余裕ができました。Fastly への移行の結果、すでにダウンロードは高速化し、データ送信コストも大幅に削減されました。Fastly の開発者向けサイトに組み込まれた Kubernetes のダッシュボードで、リアルタイムのメトリクスの一部をご覧いただけます。 

リアルタイムの可視性において Fastly が優れている理由

Fastly のコントロールパネルが提供するこのようなリアルタイムの可視性は、一見するとそれほど画期的な機能には見えないかもしれません。しかし、ほとんどの CDN はこのレベルの可視性を提供できず、ユーザーは大きく遅れて提供されるバッチ化されたログデータを利用するしかないのです。そのような CDN では、ダッシュボードでログを確認できず、ログを他のツールにエクスポートしたり、ストリーミングしたりすることも不可能です (Fastly では簡単にできます)。

Fastly のプラットフォームは完全にソフトウェア定義型であるため、ハードウェアスイッチに大きく依存し、調整可能なコンポーネントが少なく、一般的に先進的なテクノロジーがあまり採用されていない従来型のアーキテクチャでは不可能な幅広い種類のログを取得できます。私たちは、リアルタイムデータへのアクセスと可観測性の重要性を強く認識しています。そのため、トラフィックを Fastly のネットワークに切り替えた瞬間からログにアクセスし、Splunk や Datadog をはじめ、多くの開発者がすでに使用しているツールにログ機能を簡単に統合できるよう Fastly は設計されています。また、サードパーティの可観測性ダッシュボードを使用したいお客様向けに、さまざまなログエンドポイントがサポートされているので、それらにデータをリアルタイムでストリーミングできます。お客様のデータはお客様のものであり、常に自由自在に使える状態であるべきです。 

ネットワークエンジニアリング、最適化、DNS、コンテンツ配信、グローバルなキャッシュインフラ、これらはすべて管理が非常に複雑です。Kubernetes には素晴らしい Infrastructure Special Interest Group がありますが、ほどんどの開発チームやオープンソースプロジェクトには、このような作業を専門とするインハウスチームが存在しません。優れたデータへのアクセスと操作性を提供する Fastly は、データや設定機能にアクセスできない他の CDN とは一線を画しています。そのため、Fastly のお客様はプロフェッショナルサービスに多くのコストをかけずに必要な仕様に合わせて設定を細かく調整できます。Fastly では何が起きているかを確認し、必要な変更を自由に行い、本番環境にプッシュできます。お客様は必要に応じてワールドクラスのカスタマーサポートを Fastly から受けられますが、お客様がさまざまなことをセルフサービスで簡単にできるように Fastly は設計されており、この点においてもお客様から高い評価をいただいています。 

Kubernetes による Fastly のさらなる活用

新たな CDN エンドポイント (cdn.dl.k8s.io) の使用への切り替えに取り組むプロジェクトやチームを継続的に Fastly はサポートしています。Kubernetes を使って構築しているユーザーの多さを考えると、これは非常に大きな作業であり、今後しばらく続くことが予想されます。同時に Kubernetes チームは、バックエンドをコミュニティが所有する新たな GCS バケットに移行させることを楽しみにしています。新しい CDN エンドポイント (cdn.dl.k8s.io) の使用により、ユーザーのアクセスを妨げることなくバケットの移行を実現できます。 (インターネット上に溢れるその他の多くのコンテンツに比べて) Kubernetes のバイナリ自体にはそれほど変化がないため、Fastly のキャッシュで有効期限 (TTL) を最大化し、可能な限りオリジンへのトラフィックをオフロードすることをチームは計画しています。 

最終的に Kubernetes はユーザーやトラフィックパターンに関するデータへの新たなアクセスを活かし、Fastly のオリジンシールド機能を非常に興味深い形で活用する予定です。Kubernetes をインフラストラクチャに組み込んだユーザーは、特定のリリースバージョンを使い続ける傾向があります。また、バイナリダウンロードのほとんどが自動化ツール (特に GitHub Actions で実行されるスクリプト) によって行われています。GitHub Actions の実行は、いくつかの決められた特定の Microsoft Azure のリージョンに制限されるため、一部のリリースのダウンロードが特定の地理的位置に偏ることがあります。Kubernetes は Fastly 上で Fastly POP を GitHub Actions が実行される地域と Kubernetes のリリースがリクエストされる地域に一致させることで、オリジンシールド戦略の最適化に着手することができます。