並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 68件

新着順 人気順

Fastlyの検索結果1 - 40 件 / 68件

  • [注意喚起]ブラウザ互換ライブラリ「Polyfill.io」がドメイン名ごと中国企業に売却、CloudflareとFastlyが代替となる配信を開始

    [注意喚起]ブラウザ互換ライブラリ「Polyfill.io」がドメイン名ごと中国企業に売却、CloudflareとFastlyが代替となる配信を開始 開発者がブラウザの互換性を気にすることなくWebアプリケーションを開発するためのJavaScriptライブラリ「Polyfill.io」が、ドメイン名ごと中国企業に売却されたことを受けて、CloudflareとFastlyが急きょライブラリをフォークし、安全が確認されているコードの配信を開始しました(Cloudflareの発表、Fastlyの発表)。 Polyfill.ioをドメインごと中国企業に売却 Polyfill.ioはAndrew Betts氏が開発したオープンソースのJavaScriptライブラリです。Polyfill.ioを組み込むことで、ブラウザのバージョンを気にすることなくWebアプリケーションの開発を行うことができる便利なラ

      [注意喚起]ブラウザ互換ライブラリ「Polyfill.io」がドメイン名ごと中国企業に売却、CloudflareとFastlyが代替となる配信を開始
    • HTTPが全てを飲み込む(前編)~HTTPの2層構造と、HTTP Semanticsとは何か?

      Webを構成する重要な要素の1つであるHTTPは、その最新仕様で2層構造となり、バージョンに関係なく使えるSemanticsと、特徴の異なる通信仕様を定めたHTTP/1.1、2、3に分割されました。 さらに現在では、HTTPの上にあらためてUDPやIP、イーサネットなどのプロトコルを実装する提案が行われており、まさにHTTPは通信の全てを飲み込む勢いで進化しつつあります。 こうしたHTTPの最新動向の解説が、大手CDNベンダでエッジクラウドなども展開するFastlyが2023年11月8日開催したイベント「Yamagoya 2023」で同社シニアプリンシパルエンジニアの奥一穂氏が行ったセッション「HTTPが全てを飲み込む」にて行われました。 本記事ではこのセッションをダイジェストで紹介していきます。記事は以下の3つに分かれています。 HTTPが全てを飲み込む(前編)~HTTPの2層構造と、H

        HTTPが全てを飲み込む(前編)~HTTPの2層構造と、HTTP Semanticsとは何か?
      • 行動ログ収集 API サーバの Fastly Compute 移行〜高スケーラビリティ、高信頼性、高メンテナンス性を目指して 〜

        Fastly 基幹イベント Yamagoya 2023 の登壇資料です。 https://www.fastly.com/jp/press/press-releases/yamagoya-2023

          行動ログ収集 API サーバの Fastly Compute 移行〜高スケーラビリティ、高信頼性、高メンテナンス性を目指して 〜
        • 初心者が Fastly の基本を理解してみる | DevelopersIO

          こんにちは、AWS事業本部の平木です! Fastly 初心者が、Fastly に関して調べる機会があったため今回のブログを執筆しました。 Fastly とは Fastly(ファストリー)は、インターネットのパフォーマンスとセキュリティを向上させるエッジクラウドプラットフォームです。 ユーザーは、 Fastly を使用することで一般的なサーバーよりも高速にコンテンツを配信できます。 また、エッジコンピューティングを活用することで、データやサービスをユーザーの近くのエッジに配置し、 その結果ウェブサイトやアプリケーションのパフォーマンスが大幅に向上させることもできます。 さらに、Fastly はセキュリティ機能も提供しているため、ユーザーはデータの安全性も確保できます。 基本的な用語 Fastly で使用される基本的な用語を簡単に解説します。 Edge(エッジ) 世界中に配置されたサーバーの集

            初心者が Fastly の基本を理解してみる | DevelopersIO
          • PR TIMESのCDNをCloudFrontからFastlyに移行しました | PR TIMES 開発者ブログ

            こんにちは、インフラチームテックリードの櫻井です。 今回はプレスリリース配信サービスの prtimes.jp で使用しているCDNをCloudFrontからFastlyに移行したことについて紹介します。 CDNの基本的な情報は割愛するので、もしCDNについて基本的なことを知りたいという方はググるなりChatGPTるなりしてください。 なぜ移行する必要があったのか まずCloudFrontからFastlyに移行した理由について説明します。 prtimes.jp のプレスリリース詳細ページは現在SmartyテンプレートとjQueryというレガシーな技術で構成されています。 今後このプレスリリース詳細ページをReact化することでフロントエンドの開発スピードを向上させることを予定しています。 しかしReact化を行うと、検索エンジンのクローラーがJavaScriptを実行できない場合にページの内

            • Announcing Certainly: Fastly’s own TLS Certification Authority

              Announcing Certainly: Fastly’s own TLS Certification Authority Update! As of August 16th, 2023 we're excited to announce the general availability of Certainly, Fastly’s publicly trusted Certification Authority. Certainly can now be used by all Fastly customers. We know that it takes resources to maintain and monitor the certificate lifecycle, and errors in this lifecycle can cause service downtime

                Announcing Certainly: Fastly’s own TLS Certification Authority
              • Yuta Saitoさん「RubyはWebAssemblyと出会った」 〜RubyKaigi 2022 1日目キーノート | gihyo.jp

                RubyKaigi 2022 キーノートレポート Yuta Saitoさん「RubyはWebAssemblyと出会った」 〜RubyKaigi 2022 1日目キーノート 9月8日から9月10日までの3日間RubyKaigi 2022が三重県津市で開催されました。今年はRubyKaigi 2019以来、3年ぶりの現地開催で非常に盛り上がったカンファレンスとなりました。 初日のキーノートではRubyコミッターのYuta Saitoさんが「Ruby meets WebAssembly」というタイトルで発表しました。 Saitoさんはインターネット上では主に@kateinoigakukunという名前で活動しており、Swiftコミッターとしてもよく知られたエンジニアです。CRubyのWebAssembly移植を進め、2022年1月にRubyコミッターとなっています。今回のキーノートはCRubyのW

                  Yuta Saitoさん「RubyはWebAssemblyと出会った」 〜RubyKaigi 2022 1日目キーノート | gihyo.jp
                • Fastly で Next.js アプリケーションを実行

                  Fastly の新しい next-compute-js ライブラリを使用することで、Compute@Edge プラットフォーム上で Next.js アプリケーションをホストできるようになりました。これにより、Next.js 開発者のエクスペリエンスが向上し、圧倒的なスピードを誇る Fastly のグローバルエッジネットワークのメリットが得られます。オリジンサーバーも必要ありません。 Next.js は広く普及している JavaScript ベースのサーバーフレームワークで、開発者に優れたエクスペリエンスを提供します。具体的には、フロントエンドのコードを React で作成できるほか、ごくわずかな設定で本番環境に必要な優れた機能 (ハイブリッドの静的レンダリングとサーバーレンダリング、スマートバンドル、ルートプリフェッチなど) を直感的にセットアップできる便利さを備えています。 Next.j

                    Fastly で Next.js アプリケーションを実行
                  • Fastlyを導入してよかったこと

                    先日とあるサービスのCDNをFastlyに切り替えました。 導入体験が非常に良かったので、紹介していきます。 早い 当たり前ですが、レスポンスはもちろん速かったです。 おおよそ20ms前後で応答できていました。 またCDN設定変更の反映も非常に早かったです。 体感ですが1分もかからず反映されていたと思います。 安い データ転送量 最初の10TB$0.19/1GB毎(2022年9月現在、アジアリージョン) リクエスト数 $0.0090/1万リクエスト毎(2022年9月現在、アジアリージョン) 従量課金の場合、上記の費用がかかります。 このあと紹介していく機能などを考慮した費用対効果の面で考えると安いと思っています。 機能が豊富 Fastlyにはさまざまな便利機能があります。 そのうち実際に使用してよかったサービスを紹介します。 VCL Fastlyは管理画面から設定もできるのですが、Varn

                      Fastlyを導入してよかったこと
                    • ご指定の言語に対応しておりません

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

                        ご指定の言語に対応しておりません
                      • Firebase CLIのNext.jsデプロイ対応について調べる

                        Firebase HostingがNext.jsのデプロイに対応した[1] と聞きつけ、Next.jsビルドツール好き[2] [3] なので様子を見てきました。 のリポジトリを中心に調べてみます。 Firebase CLI framework-awareness とは フレームワークサポートを付与するためのFirebase CLI のアドオン。 Firebaseプロジェクトの構成に応じて、Google Cloudのリソースを構築する。 現在Next, Nuxt2/3, AngularをサポートしていてCloud Functionsにこれからのフレームワーク機能をサポートするエンドポイントを自動でデプロイしてくれる。 内部アーキテクチャ next export で .next/ ディレクトリができる firebase-frameworks.build() がプロジェクト構造を解析してフレーム

                          Firebase CLIのNext.jsデプロイ対応について調べる
                        • ご指定の言語に対応しておりません

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

                            ご指定の言語に対応しておりません
                          • CloudflareでもFastlyでもVercelでもDenoでもBunでもService Workerでも動く

                            HonoというWebフレームワークを作っています。 当初はCloudflare Workers向けに作っていたのですが、同じCDNであるFastlyのエッジランタイム、Compute@Edgeでも動くことが分かりました。また、Next.jsのEdge MiddlewareもしくはEdge API RoutesとしてVercelの環境でも動きます。そして、少々手を加えるとDenoでも動きました。もちろんDeno Deployにもデプロイできます。さらに、先程レポジトリが一般公開されたYet AnotherなJavaScriptランタイムのBunでも手を加えず動きました。 この「CloudflareでもFastlyでもVercelでもDenoでもBunでも動いた件」が、なかなか面白かったのでそれについて書きます。 Web標準のAPI これらの環境で同じように動くのは、JavaScriptでかつ

                              CloudflareでもFastlyでもVercelでもDenoでもBunでもService Workerでも動く
                            • Fastly Compute@Edge を用いた CDN の構築|株式会社カウシェ

                              こんにちは、株式会社カウシェの Architect の伊藤です。 本稿では、カウシェが CDN の構築に利用している Fastly Compute@Edge について、「採用した理由」や「テストやデプロイの方法」などを実装例を混じえてご紹介します。 伊藤 雄貴 / @yuki.ito DeNA を経て 2018 年にメルペイにジョインし、Tech Lead や Architect としてマイクロサービスの開発や組織横断的な技術課題の解決に携わる。カウシェには立ち上げのタイミングから副業として参画し Backend 全般の実装を行う。2022 年 7 月より Architect としてカウシェに正式にジョインし、全社的な技術戦略の意思決定や技術基盤の構築に携わる。 Fastly Compute@Edge とはFastly Compute@Edge は Fastly が提供しているコンピューテ

                                Fastly Compute@Edge を用いた CDN の構築|株式会社カウシェ
                              • ご報告

                                █ 月に ██████████████, ███████████, ███████ から誕生日を祝ってもらったのですが、そのときにマッチングアプリ代金を誕生日プレゼントとしてもらいました。とても生々しいですね。誕生日プレゼント何が欲しいか聞かれたときにふざけて「█████ が欲しい」とか言ってたらまさかこのような形でもらうことになって驚きました。今日は █ ヶ月マッチングアプリをしてみた結果をご報告しようと思います。 マッチングアプリにワクワクまずマッチングアプリに入ると女性がずらっと並んでいて「もしかして結婚相手と出会えるのかもしれない」という気持ちになって、ワクワクしました。とりあえずマッチングのためには魅力的な ███████████ が大事であるとのことで、その場に居合わせた ██████████████, ███████████, ███████ に書いてもらったり、登録する写真

                                • WEAR Webフロントエンドリプレイスのアーキテクチャ選定とNext.jsへの移行 - ZOZO TECH BLOG

                                  はじめに こんにちは。WEAR部フロントエンドブロックの藤井です。WEARでは現在、Webサイトのリプレイスを進めています。本記事では、リプレイスに至った背景や課題と、課題解決のために行ったリプレイスのアーキテクチャ選定についてご紹介します。 なぜリプレイスするのか WEARはサービスローンチしてから約10年が経ちます。これまでローンチ当時の技術スタックのまま開発を続け、サービスを成長させてきました。今後もより継続的にスピード感を持ってユーザーへ価値を届けていくにあたってさまざまな課題があったため、新たな技術スタックでリプレイスを開始することにしました。 リプレイス前の環境 リプレイス前の環境はオンプレミスの環境にロードバランサー、Windowsサーバー(IIS)があり、そこでVBScriptが動いています。VBScriptでテンプレートHTMLにデータを流し込み、ブラウザに表示する仕組み

                                    WEAR Webフロントエンドリプレイスのアーキテクチャ選定とNext.jsへの移行 - ZOZO TECH BLOG
                                  • Fastly Terrarium | Docs

                                    Terrarium is a multi-language, browser-based editor and deployment platform where you can experiment with the technology that will power Fastly at the edge. This project pushes edge computing beyond the limitations of serverless implementations, and removes the need for specific languages, APIs, or add-ons that can impede your innovation or cause vendor lock-in. About With Terrarium, you can write

                                    • Fastlyについて知らないかもしれない30のこと – TravelBook Tech Blog

                                      いわくら君が書いてくれた通り 、トラベルブックではFastlyを導入しました。Fastlyについて初めて分かったことがたくさんありました。列挙してみたら30個もあったので、一個ずつ紹介してみることにします。 そもそもFastlyとは そもそもFastlyとはCDNのサービスです。現在では後述するCompute@Edgeを主力としたサーバーレス環境を推していますが、とにかくCDNです。今回は www.travelbook.co.jp ドメイン全てに対して適応し、全てのHTMLページをFastly経由にしました。 もともとVarnishでページをキャッシュしていた部分をFastlyに置き換えることで冗長化・安定化、また、パフォーマンスアップを図ります。 加えて、これまでキャッシュの対象外だったページも、この際TTL付きでキャッシュする、というのが今回やったことです。 詳しくはいわくら君の書いた

                                        Fastlyについて知らないかもしれない30のこと – TravelBook Tech Blog
                                      • 嘘、大嘘、そして (Cloudflare の) 統計 : Cloudflare のパフォーマンステストの欠陥を証明

                                        嘘、大嘘、そして (Cloudflare の) 統計 : Cloudflare のパフォーマンステストの欠陥を証明 数週間前、Fastly の競合企業の一つである Cloudflare が、自社のエッジ・コンピューティング・プラットフォームは Compute@Edge と比べて約3倍も高速であると 自社のブログ記事で断言しました。しかし Cloudflare によるこの見当違いな主張は、事実とは異なる印象を与えるために統計が利用されるリスクについて学ぶ良い機会でもありました。この記事では、Cloudflare のテスト手法を分析するとともに、より有用で科学的な比較による結果をご紹介します。 世の中には「嘘、大嘘、そして統計」の3種類の嘘が存在すると言われています。これは統計の説得力を皮肉った言葉であり、統計の中には信用できるものもありますが、今回 Cloudflare が公開した統計は明ら

                                          嘘、大嘘、そして (Cloudflare の) 統計 : Cloudflare のパフォーマンステストの欠陥を証明
                                        • Fastly Compute@Edgeについて分かったこと – TravelBook Tech Blog

                                          トラベルブックでは CDN に Fastly を使っています。 その Fastly が提供する Compute@Edge が一般でも使えるようになりました。今回は Compute@Edge とはなにか、といった概要と、実際に「Slack スラッシュコマンド echo 」を作ってみた件、それで分かったことを紹介してみたいと思います。 Compute@Edge とは? Compute@Edge とは、Fastly の CDN エッジでスクリプトを実行できる環境のことを言います。 去年の 11 月に一般ユーザーに開放されました。 誰もが無料で Compute@Edge を試せるチャンス | Fastly Compute@Edge は一般的に「エッジコンピューティング」と呼ばれるもので、同様には以下があります。 Cloudflare Workers Vercel Edge Functions AW

                                            Fastly Compute@Edgeについて分かったこと – TravelBook Tech Blog
                                          • Fastlyを活用したnoteの画像配信効率化 #yamagoya2021|note株式会社

                                            ※ Fastlyの公式イベント「Yamagoya 2021」で発表した内容を再編した記事です。 今回はFastly Image Optimizerを活用したnoteでの画像配信効率化についてお話します。よろしくお願いします。 note株式会社の和田と申します。 2019年4月にnoteに入社し、現在は法人向けサービスであるnote proの基盤システム開発のチームリーダーを担当しています。 Fastly導入前の画像配信における3つの課題noteでは画像配信に多くの課題を感じていましたが、エンジニアの人数が少ない時代もあり、なかなか手がつけられていないのが現状でした。 まずは、Fastly導入前にどのような問題があったのか、画像配信における3つの課題について説明していきます。 1つ目の課題は、アプリケーションサーバーへの負荷です。 noteはサーバーサイドをRailsで実装しており、Carr

                                              Fastlyを活用したnoteの画像配信効率化 #yamagoya2021|note株式会社
                                            • Compute@Edge は GraphQL Server の夢を見るか — HACK The Nikkei

                                              この記事はNikkei Advent Calendar 2021の6日目の記事です。 こんにちは、長期インターン生の林(Shinyaigeek)です。 fastly の提供する Compute@Edge という Edge Computing 基盤があります。 まだベータという形でですが、このランタイムで JavaScript の対応が始まったことをうけ、 Compute@Edge で何ができるのか、そのために何が必要なのか、というのを実際に Compute@Edge で Apollo Server を用いて GraphQL Server を建てることを通して考察します。 Compute@Edge とは 本題に入る前に Compute@Edge とはどのような技術なのか、何ができるのか、という説明から入りたいと思います。 Compute@Edge とは fastly が提供している Edge

                                                Compute@Edge は GraphQL Server の夢を見るか — HACK The Nikkei
                                              • Fastly Compute@Edge 使い方ガイド

                                                Fastly の Compute@Edge についてユースケース別に実装例を書いていきます。

                                                  Fastly Compute@Edge 使い方ガイド
                                                • nginx 移行を通じて学んだ Fastly のはじめかた - Retty Tech Blog

                                                  今年もはじまりました Retty Advent Calendar 2021 ! 初日を担当いたします技術部の西村です。 ※ 2021/12/03 更新 共通関数の設定 にて戻り値が設定できない旨記載してましたが、実はできるようになったとのご連絡をいただきましたので修正しております。 Subroutines | Fastly Developer Hub 今年はパート 2 までありますので、みなさまぜひご覧くださいませ。 Retty Part1 Advent Calendar 2021 Retty Part2 Advent Calendar 2021 今年の内容は「nginx 移行を通じて学んだ Fastly のはじめかた」ということで記事を書かせていただきます。 掲題の通り Fastly に関してはこれからはじめようと思っている方向けに記載しております。 弊社は昔から画像変換サービスやアセッ

                                                    nginx 移行を通じて学んだ Fastly のはじめかた - Retty Tech Blog
                                                  • 生涯現役のソフトウェアエンジニアでありたい。IC(Individual Contributor)のキャリアパスがあると自覚するまで10年の軌跡 - Findy Engineer Lab

                                                    ソフトウェアエンジニアの藤吾郎(@__gfx__)と申します。最近、IC(Individual Contributor / 個人貢献者†)という言葉でキャリアが語られることも増えてきたように思います。この記事では、ソフトウェアエンジニアにおけるICというキャリアパスについて、自分の認識と経験を交えて次の点から解説していきます。 ICというキャリアパスがあることを、ソフトウェアエンジニアに知ってもらいたい 私が39歳という年齢でIC一本でいくと決意するに至った経緯は? 「IC」とはどういったキャリアなのか? 管理職ではないキャリアとしてのIC これからICを定義する企業は増えるか 私がICというキャリアパスを選ぶことになるまで ソフトウェアエンジニアになるつもりはなかった 27歳で選択したソフトウェアエンジニアをウロウロする10年 Fastlyに入社して初めて明示的にICとなる ソフトウェア

                                                      生涯現役のソフトウェアエンジニアでありたい。IC(Individual Contributor)のキャリアパスがあると自覚するまで10年の軌跡 - Findy Engineer Lab
                                                    • Fastlyを検討する - ゆーすけべー日記

                                                      Fastly の導入を検討している。検討しているだけで、導入していないので、参考にならないかもしれないし、間違っているかもしれないが、メモ。 動機 Varnish を使っていて、最初は Varnish の冗長化をしたい!だった。 まあそうなるよねえ。で、Fastly!となった。 ちなみに、Varnish を使ってる理由としては、以前も Jamstack を検討する - ゆーすけべー日記 Varnish で Stale-While-Revalidate を実現する - ゆーすけべー日記 で触れたとおり、 なるべく手間手前で、なるべく少ない箇所でキャッシュしたいからである。 Fastly でできること・したいこと Fastly でできることはたくさんあるので、その中でもしたいことを列挙。リバースプロキシ、ロードバランサの機能も含むのが便利。特に、パスごとに制御できる。なので、とあるパスはキャッ

                                                        Fastlyを検討する - ゆーすけべー日記
                                                      • メルカリShopsのキャッシュ戦略

                                                        メルカリ Shops の開発 vcl, python, golang, containers, typescript, etc. が入っている monorepo で開発が行われている。 なので、あまり専門性はあってもどの領域でも開発を行う。 メルカリアプリ上で動いているため、 webview がベースとなりパフォーマンスは普段以上に求められている。 技術スタックはこちらを参照 ユーザーへの UX を下げないために。。 First Meaningful Paint を速くするSkeleton などでフィードバックを適切に行う => とりあえず速く結果を返却すればよい 結果を速く返すために考えること 共通な結果はすべてキャッシュし、CDN などを使い近くに置く極力、ユーザーからのアクセスを origin まで到達させない常に新鮮な結果を近くに保持することにより、上記を満たせるようにする =>

                                                          メルカリShopsのキャッシュ戦略
                                                        • Compute | Fastly

                                                          高速かつ安全で魅力的なエクスペリエンスを エッジで実現Fastly Compute オープンスタンダードで構築された最先端のサーバーレスプラットフォーム「Compute」では、任意の言語を使用して Fastly のグローバルエッジネットワークでコードを実行できます。非常に安全性が高く、マイクロ秒単位の超高速コールドスタートが可能なエッジ環境でコードを大規模に実行できるので、先進的なアプリケーション開発のニーズに応えられます。 エッジでイノベーションと配信を加速Compute を活用することで、レイテンシを抑えながらエッジでより高速かつパーソナライズされたエクスペリエンスの提供とイノベーションの加速が可能になります。また、業界での評価が高い Fastly の開発者向けポータルでは、プロジェクトの開始に役立つユースケースやスターターキット、チュートリアル、コードサンプルなどをご用意しています。

                                                            Compute | Fastly
                                                          • Fastly、JavaScriptエンジンをWebAssemblyで実装。CDNエッジのサーバレス環境「Compute@Edge」でJavaScriptサポート発表(訂正済み)

                                                            Fastly、JavaScriptエンジンをWebAssemblyで実装。CDNエッジのサーバレス環境「Compute@Edge」でJavaScriptサポート発表(訂正済み) (お詫びとお知らせ:本記事はFastlyの発表と同社へのメールでの取材に基づいて執筆いたしましたが、記事公開後に同社より、回答を間違えたとの申し出がありました。そのため改めて同社から提供された情報を基に、タイトルと本文を訂正しました。訂正前の記事内容は本文最後にHTMLでコメントアウトされています。) 大手CDNベンダのFastlyは、CDNエッジで提供しているサーバレスコンピューティング環境「Compute@Edge」で、JavaScriptのサポートを発表しました。 JavaScript on Compute@Edge is here. https://t.co/wSHiJfPdvf pic.twitter.c

                                                              Fastly、JavaScriptエンジンをWebAssemblyで実装。CDNエッジのサーバレス環境「Compute@Edge」でJavaScriptサポート発表(訂正済み)
                                                            • Fastly Launches Highly-Secure Serverless JavaScript

                                                              Compute@Edge’s unique isolation sandbox technology enables a fast, secure JavaScript experience as developers continue to enter into the growing serverless computing landscape. SAN FRANCISCO -- JULY 21, 2021 -- Fastly, Inc. (NYSE: FSLY), a global edge cloud platform provider, today announced the availability of JavaScript in Compute@Edge, allowing developers to build with even more flexibility in

                                                                Fastly Launches Highly-Secure Serverless JavaScript
                                                              • Fastlyの障害から学ぶエラーメッセージの書き方

                                                                この記事は、著者の許可を得て配信しています。 What the Fastly outage can teach us about writing error messages 知らない方もいると思いますが、2021年6月8日の約15分間、FastlyのCDNにシステム障害が発生し、インターネット上のウェブサイトが大規模に停止しました(BBC、英国政府、Reddit、New York Timesでも不具合が生じ、Amazon.comにおいてはCSSの読み込みに失敗しました)。 Fastlyの停止中にこれらのウェブサイトにアクセスした方は、以下のような意味のないエラーメッセージを目にしたことでしょう。 フロントエンドの開発者である私は、このようなエラーメッセージを見て、そのエラーが自分のせいではないことを示す数字(この場合は「503」という数字)を探し、安心しました。 残念ながら、大多数のイン

                                                                  Fastlyの障害から学ぶエラーメッセージの書き方
                                                                • 【特集】 ネットの大規模障害が起きた「CDN」って何?実際にアクセスして確かめてみた

                                                                    【特集】 ネットの大規模障害が起きた「CDN」って何?実際にアクセスして確かめてみた
                                                                  • 2021 年 6 月 8 日に発生した障害について

                                                                    2021 年 6 月 8 日に発生した障害について2021 年 6 月 8 日、未確認のソフトウェアバグが特定のお客様のサービス設定変更でトリガーされ、グローバル規模の障害が発生しました。当社は、事象発生から 1 分以内に障害を検知し、原因を特定して隔離し、該当の設定を無効化しました。49 分後には、ネットワークの 95% が復旧しました。 今回の障害は広範囲かつ深刻なものであり、お客様にご迷惑をおかけしたことを深くお詫び申し上げます。 概要2021 年 5 月 12 日、Fastly が実装を開始したソフトウェアに、非常に特殊かつ例外的な状況下でトリガーされる可能性のあるバグが含まれていました。 2021 年 6 月 8 日、特定のお客様のサービス設定変更が有効であったにもかかわらず、その実行でトリガーされたバグにより、当社のネットワークの 85% で障害が発生しました。 2021 年

                                                                      2021 年 6 月 8 日に発生した障害について
                                                                    • Fastlyが大規模障害の経緯を公開、原因はソフトウェアのバグ。障害を1分以内に検知し、49分でおおむね復旧させたと報告

                                                                      Fastlyが大規模障害の経緯を公開、原因はソフトウェアのバグ。障害を1分以内に検知し、49分でおおむね復旧させたと報告 CDNベンダ大手のFastlyが日本時間6月8日夕方に障害を発生、その影響は国内にもおよび、メルカリや楽天市場、Amazon.co.jp、Twitter、ABEMAなど多くのサービスに接続できないなどの障害が発生しました。 We identified a service configuration that triggered disruptions across our POPs globally and have disabled that configuration. Our global network is coming back online. Continued status is available at https://t.co/RIQWX0LWwl

                                                                        Fastlyが大規模障害の経緯を公開、原因はソフトウェアのバグ。障害を1分以内に検知し、49分でおおむね復旧させたと報告
                                                                      • fastlyのCDNで発生したシステム障害についてまとめてみた - piyolog

                                                                        2021年6月8日、fastlyのCDNサービスで障害が発生し、国内外複数のWebサイトやサービスに接続できないなどといった事象が発生しました。ここでは関連する情報をまとめます。 原因はソフトウェアの潜在的な不具合 fastlyより6月8日付で今回の障害の顛末が公開されている。 www.fastly.com 障害原因はソフトウェアの潜在的な不具合で特定状況下かつ顧客構成で発生する可能性があった。このソフトウェアは5月12日に展開が開始されていた。 6月8日早くにこの不具合を発生条件を満たす構成変更が顧客によって行われネットワークの85%がエラーを返す事態が発生した。サイバー攻撃の可能性は否定と報じられている。*1 障害は発生から1分後にfastlyに検知され、49分以内にネットワークの95%が復旧した。 今回の障害を受け、短期的には修正プログラムの早期適用、復旧時間の短縮、テスト時に不具合

                                                                          fastlyのCDNで発生したシステム障害についてまとめてみた - piyolog
                                                                        • Summary of June 8 outage

                                                                          Summary of June 8 outageWe experienced a global outage due to an undiscovered software bug that surfaced on June 8 when it was triggered by a valid customer configuration change. We detected the disruption within one minute, then identified and isolated the cause, and disabled the configuration. Within 49 minutes, 95% of our network was operating as normal. This outage was broad and severe, and we

                                                                            Summary of June 8 outage
                                                                          • 何故 Fastly を使うのか

                                                                            数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。 キャッシュが消えるのがはやいCDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通の CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。 これにより、 CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタ

                                                                              何故 Fastly を使うのか
                                                                            • Status page hosting with StatusCast

                                                                              To ensure the highest security and best performance for our customers, Fastly’s network has built-in redundancies and automatic failover routing. We continuously monitor the status of our global network and all related services, but in the event of scheduled maintenance or an unplanned performance impact, we think our customers deserve clear, transparent communication so they can maintain trust in

                                                                              • Fastlyのパスベースルーティングで実現するWEARのゆるやかなクラウド移行 - ZOZO TECH BLOG

                                                                                はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの長尾です。 WEARは2013年にリリースされ、現在8年目のサービスです。そして、2004年にリリースされた当時のZOZOTOWNと同じアーキテクチャを採用しているため、比較的古いシステム構成で稼働しています。本記事では、そのWEARのWebアプリケーション刷新とクラウド移行で実践している、Fastlyを活用したパスベースルーティングによる段階移行の取り組みを紹介します。 WEARをリプレイスする理由 WEARのWebアプリケーションは、データセンターでオンプレミス(以下、オンプレ)上で稼働しています。また、DBはSQL Serverを利用しています。長年このアーキテクチャで成長を続けてきましたが、今後さらに成長を加速させていくためには以下の3点を実現する必要があります。その実現に向け、2年前からリプレイスに

                                                                                  Fastlyのパスベースルーティングで実現するWEARのゆるやかなクラウド移行 - ZOZO TECH BLOG
                                                                                • QUIC is now RFC 9000

                                                                                  QUIC is now RFC 9000QUIC is a new latency-reducing, reliable, and secure internet transport protocol that is slated to replace TCP, the most commonly used transport today. We’ve talked before about how we love QUIC and are deeply invested in making it a success because it aligns with our mission to build a faster, more resilient, and more trusted internet. In fact, we believe so much in the promis

                                                                                    QUIC is now RFC 9000