Build on Fastly の17の新ソリューション

8月に開発者ライブラリである Build on Fastly をリリースして以来、ビーコンターミネーション、ジオフェンシング、多くの種類のロードバランシングなど、多くの新しいソリューションを密かに追加してきました。ここでは、Fastly を最大限に活用するための新しいアイデアが詰まった新しいソリューションをご紹介いたします。

Build on Fastly は、ソリューションレシピやテンプレートコードで構成された膨大なライブラリと、エッジでのプログラミングに関する専門知識を理解して深めるのに役立つ共通パターンの詳細なウォークスルーを組み合わせたものです。

ジオフェンシングとビーコンターミネーションの新しいパターン

とても多くの Fastly のお客様が、さまざまなエクスペリエンスを提供する特定の国をターゲットとした機能を活用しています。ライセンスや規制、ローカライズのためであったとしても、Fastly の位置情報データを使用して、適切なロケーションにいる適切なユーザーに適切なエクスペリエンスを届ける価値ある機能を提供できます。

ジオフェンシングのネットワークシーケンス図

Fastly の位置情報を対象とするソリューションパターンでは、Vary ヘッダーの正しい使用法、エッジでの直接アクセスのブロック、カスタムリージョン、グリッド計算など、ジオフェンシングを最大限に活用するためのベストプラクティスのテクニックを取り入れています。

位置情報ソリューションパターンを参照する

また、Fastly のエッジクラウドでビーコンを終了させ、データを変換してバッチ処理し、お好みの分析ツールに提供する機能についても長い間話し合ってきました。それは、Fastly のリアルタイムログシステムに非常に誇りを持っていて、それを使ってできることを実感してもらうソリューションが好きだからです。

ビーコンターミネーションのネットワークシーケンス

ビーコンターミネーションは、オリジンの負荷を軽減し、分析結果を収集するための非常に効率的な方法です。しかし、データを CSV、JSON、クエリ文字列、または構造化ヘッダーに変換する機能を利用したり、Fastly in VCL で利用できる豊富な情報でデータを充実させたりする開発者はそれほど多くありません。Web 標準の Navigator.sendBeacon も、OnUnload ハンドラーやトラッキングピクセルの代替手段として十分に活用されていません。

ビーコンターミネーションソリューションパターンを参照する

ビーコンターミネーションパターンを使用することで、リアルタイムロギングシステムからさらに多くの価値を引き出すことができます。

Directorロードバランシングの戦略

Fastly がロードバランシングをサポートしていることはすでにご存知かもしれませんが、標準化された4つの異なる Director 戦略をサポートしていることはご存知でしょうか。Director は、オリジンサーバーのグループです。リクエストにバックエンドを割り当てるために単一のオリジンサーバーのように見せかけることができ、指定された戦略を内部的に使用してプールから最も適切なオリジンを選択します。

Fastly は利用可能なすべての戦略について、新しいレシピを公開しました。

  • ランダム : オリジン間のトラフィックを重み付けして分散します。従来のロードバランシングに有効です。

  • 貫性のあるハッシュ : リクエストされたコンテンツに基づいてリクエストをマッピングします。オリジンが独自にキャッシュを持っている場合に常に同じオリジンから同じコンテンツをフェッチすることで、可能な限りキャッシュを効率的に使用したいときに有効です。

  • フォールバック : 最初に動作するオリジンを選択します。オリジンをアクティブ/スタンバイ構成で動作させる場合に有効です。

  • クライアント : ユーザー ID に基づいてリクエストをマッピングします。セッション中にユーザーを特定のオリジンサーバーに一貫してマッピングする、いわゆる「sticky」セッションに有効です。

もちろん、独自のロードバランシングロジックを記述することもできます。上記でリンクされているジオフェンシングソリューションは、ロードバランシング戦略の一例です。もう1つは、URL パスのフラグメントに基づいてオリジンにルーティングするもので、マイクロサービスと呼ばれています。マイクロサービスのレシピは以前から存在します。

Web アプリケーションファイアウォール (WAF)関するアイデア

WAF は必然的に複雑な製品であるため、多くのお客様が Fastly のソリューションチームに頼って、ニーズに合うように WAF の調整をしています。だからといって、ブラックボックスである必要はありません。ほとんどすべて Fastly プラットフォームと同様に、独自のコードを記述することによって WAF の動作の大部分をコントロールできます。

まず、どのような種類の脆弱性があるのかを理解する必要があります。私たちは、般的なエクスプロイトのタイプをすべてシミュレートするレシピを公開して、WAF によりそれらを捕捉してブロックする方法を示しました。

WAF ルールエンジン内で用意されている15,000ほどのルールに満足していない場合は、独自のルールを作成してみてはいかがでしょうか。標準の WAF ログメカニズムを利用することもできるので、違反は他のすべてのルールと同じように報告されます。さらに、同じスコアリングバケットを使用することもできます (ただし、WAF UI にはこれらのルールは表示されません)。

もし攻撃者を混乱させたいなら、ブロックしたときにランダムなレスポンスをするようにしてみてください。

また、すべてのリクエストに対して WAF を実行する必要はありません。通常は、オリジンへのリクエストでのみ実行することをお勧めします (つまり、キャッシュからコンテンツを提供する場合は実行する必要はありません)。しかし、GCS や S3 のような静的オブジェクトバックエンドへのリクエストには WAF は必要ないかもしれません。そのため、WAFトリガーするためのカスタム条件を用意することを検討したほうがよい可能性があります。

新機能 : セグメントキャッシュとバイナリ合成

2019年は、セグメントキャッシュの提供を開始した年でした。さらに、プラットフォームはバイナリレスポンスを設定アーティファクト内に直接エンコードする機能も獲得し、数マイクロ秒で配信できるようになったため、多くの場合、キャッシュ検索よりも高速になりました。

セグメントキャッシュの採用は、キャッシュを完全にパージする必要があるため、一部のお客様にとっては課題となっています。しかし、問題ありません。ここでは、セグメントキャッシュをコンテンツ全体で徐々に有効にするレシピを説明します。

ちなみに、その逆の機能として、毎日特定の時間にキャッシュを自動的にドロップするソリューションを作成するような依頼もあります。これは一般的にあまり良いアイデアではありませんが、他のプラットフォームから来たお客様は移行のためにそれを必要としているのです。そういうことで、スケジュールした無効化のレシピを示します。自己責任でご利用ください。

また、新しい VCL ステートメント、synthetic.base64 を追加しました。これは、base64 でエンコードされた文字列からレスポンスボディを作成します。これにより、バイナリオブジェクトをソースコードに直接エンコードすることができます。さあ、ファビコンを設定しましょう。

こんにちは、Azure GCS

オリジンとして AWS S3 プライベートバケットに接続するためのレシピは以前から存在します。最近、AzureGCS をこのリストに追加しました。パートナーシップのページには、Azure との連携Google Cloud Platform とのコラボレーションに関する詳細情報が記載されています。

高度な画像最適化

イメージオプティマイザーは使いたいけど、画像の URL に醜い最適化パラメーターを追加したくないのですか ? 画像変換クラスのレシピを試して、その /image.png?width=600&height=300/image/large.png に変えてみましょう。よくなりましたね (キャッシュフラグメントの可能性も大幅に減少します)。

プリフライトの新しいアイデア : 脅威インテリジェンス ?

オリジンを使用してリクエストをエンリッチ化し、その後エッジ処理を再開して別のオリジンにリクエストを送信するパターンはよく知られています。これを「プリフライト」と呼んでいます。ここでは、脅威インテリジェンスバックエンドを使用して、漏洩したパスワードを含むリクエストがオリジンに到達する前に、そのリクエストにフラグを立てるというクールなアイデアを紹介しています。

これらのソリューションのほとんどは、Fastly の新しい機能を活用してはいませんが、プログラム可能なプラットフォームでは、できることの範囲は事実上無限大です。この新しいアイデアの切れ端が役に立つことを願っています。開発者ライブラリで紹介できるクールなアイデアがあれば、ぜひお知らせください

Andrew Betts
Head of Developer Relations
投稿日

この記事は6分で読めます

興味がおありですか?
エキスパートへのお問い合わせ
この投稿を共有する
Andrew Betts
Head of Developer Relations

Andrew Betts は、Fastly の Head of Developer Relations として世界各地の開発者と協力し、Web の高速化やセキュリティ、信頼性、使いやすさの向上に取り組んでいます。Fastly 入社前は、Web コンサルティング会社 (後に Financial Times により買収) を設立し、Financial Times の先駆的な HTML5 ベースの Web アプリケーションの開発を統括したほか、同紙のラボ部門の設立にも携わりました。また、W3C Technical Architecture Group (World Wide Web の開発を導く9名で構成される委員会) の選出メンバーでもあります。

Fastly試してみませんか ?

アカウントを作成してすぐにご利用いただけます。また、いつでもお気軽にお問い合わせください。