数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。 キャッシュが消えるのがはやいCDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通の CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。 これにより、 CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタ
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 奥氏はHTTP/3に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
ソフトウェアエンジニアの藤吾郎（@__gfx__）と申します。最近、IC（Individual Contributor / 個人貢献者†）という言葉でキャリアが語られることも増えてきたように思います。この記事では、ソフトウェアエンジニアにおけるICというキャリアパスについて、自分の認識と経験を交えて次の点から解説していきます。 ICというキャリアパスがあることを、ソフトウェアエンジニアに知ってもらいたい 私が39歳という年齢でIC一本でいくと決意するに至った経緯は？ 「IC」とはどういったキャリアなのか？ 管理職ではないキャリアとしてのIC これからICを定義する企業は増えるか 私がICというキャリアパスを選ぶことになるまで ソフトウェアエンジニアになるつもりはなかった 27歳で選択したソフトウェアエンジニアをウロウロする10年 Fastlyに入社して初めて明示的にICとなる ソフトウェア
2021年6月8日、fastlyのCDNサービスで障害が発生し、国内外複数のWebサイトやサービスに接続できないなどといった事象が発生しました。ここでは関連する情報をまとめます。 原因はソフトウェアの潜在的な不具合 fastlyより6月8日付で今回の障害の顛末が公開されている。 www.fastly.com 障害原因はソフトウェアの潜在的な不具合で特定状況下かつ顧客構成で発生する可能性があった。このソフトウェアは5月12日に展開が開始されていた。 6月8日早くにこの不具合を発生条件を満たす構成変更が顧客によって行われネットワークの85%がエラーを返す事態が発生した。サイバー攻撃の可能性は否定と報じられている。*1 障害は発生から1分後にfastlyに検知され、49分以内にネットワークの95%が復旧した。 今回の障害を受け、短期的には修正プログラムの早期適用、復旧時間の短縮、テスト時に不具合
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
いわくら君が書いてくれた通り 、トラベルブックではFastlyを導入しました。Fastlyについて初めて分かったことがたくさんありました。列挙してみたら30個もあったので、一個ずつ紹介してみることにします。 そもそもFastlyとは そもそもFastlyとはCDNのサービスです。現在では後述するCompute@Edgeを主力としたサーバーレス環境を推していますが、とにかくCDNです。今回は www.travelbook.co.jp ドメイン全てに対して適応し、全てのHTMLページをFastly経由にしました。 もともとVarnishでページをキャッシュしていた部分をFastlyに置き換えることで冗長化・安定化、また、パフォーマンスアップを図ります。 加えて、これまでキャッシュの対象外だったページも、この際TTL付きでキャッシュする、というのが今回やったことです。 詳しくはいわくら君の書いた
QUIC is now RFC 9000
Why FastlyProductsServicesSolutionsDevelopersPartnersResourcesPricing 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
［注意喚起］ブラウザ互換ライブラリ「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アプリケーションの開発を行うことができる便利なラ
現在標準化が進められている次世代HTTPの「HTTP/3」は、トランスポートプロトコルとして「QUIC」と呼ばれる新しいプロトコルを採用します。 現時点のHTTPはトランスポートプロトコルとして「TCP」が採用されています。その上で、可能な限り高速な通信が行えるようにさまざまな工夫や最適化が進められてきました。そしてもうこれ以上高速にしようとすると、TCPそのものを改善していくべきだろう、というところまできたのです。 それがHTTP/3で「QUIC」が採用される大きな理由といわれています。 TCPは内部で輻輳制御や再送などを自動的に行うことで通信が確実に行われることを保証してくれる便利なプロトコルですが、それゆえに、確実に通信が行われるまで待つ必要があるために通信環境によっては遅くなりがち、などの側面があります。 そこでQUICは、TCPのような通信の保証がない代わりにリアルタイム性の高い
#yamagoya2020 で 2020/11/25 に登壇させていただいたセッションの資料です。
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
嘘、大嘘、そして (Cloudflare の) 統計 : Cloudflare のパフォーマンステストの欠陥を証明
嘘、大嘘、そして (Cloudflare の) 統計 : Cloudflare のパフォーマンステストの欠陥を証明 数週間前、Fastly の競合企業の一つである Cloudflare が、自社のエッジ・コンピューティング・プラットフォームは Compute@Edge と比べて約3倍も高速であると 自社のブログ記事で断言しました。しかし Cloudflare によるこの見当違いな主張は、事実とは異なる印象を与えるために統計が利用されるリスクについて学ぶ良い機会でもありました。この記事では、Cloudflare のテスト手法を分析するとともに、より有用で科学的な比較による結果をご紹介します。 世の中には「嘘、大嘘、そして統計」の3種類の嘘が存在すると言われています。これは統計の説得力を皮肉った言葉であり、統計の中には信用できるものもありますが、今回 Cloudflare が公開した統計は明ら
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 の新しい next-compute-js ライブラリを使用することで、Compute@Edge プラットフォーム上で Next.js アプリケーションをホストできるようになりました。これにより、Next.js 開発者のエクスペリエンスが向上し、圧倒的なスピードを誇る Fastly のグローバルエッジネットワークのメリットが得られます。オリジンサーバーも必要ありません。 Next.js は広く普及している JavaScript ベースのサーバーフレームワークで、開発者に優れたエクスペリエンスを提供します。具体的には、フロントエンドのコードを React で作成できるほか、ごくわずかな設定で本番環境に必要な優れた機能 (ハイブリッドの静的レンダリングとサーバーレンダリング、スマートバンドル、ルートプリフェッチなど) を直感的にセットアップできる便利さを備えています。 Next.j
Fastlyを検討する - ゆーすけべー日記
Fastly の導入を検討している。検討しているだけで、導入していないので、参考にならないかもしれないし、間違っているかもしれないが、メモ。 動機 Varnish を使っていて、最初は Varnish の冗長化をしたい！だった。 まあそうなるよねえ。で、Fastly！となった。 ちなみに、Varnish を使ってる理由としては、以前も Jamstack を検討する - ゆーすけべー日記 Varnish で Stale-While-Revalidate を実現する - ゆーすけべー日記 で触れたとおり、 なるべく手間手前で、なるべく少ない箇所でキャッシュしたいからである。 Fastly でできること・したいこと Fastly でできることはたくさんあるので、その中でもしたいことを列挙。リバースプロキシ、ロードバランサの機能も含むのが便利。特に、パスごとに制御できる。なので、とあるパスはキャッ
WebAssemblyが目指していること。ナノプロセスモデルの実現、システムインターフェイス、実行時リンクの実装など Webブラウザ上でネイティブコードのように高速に実行できるバイナリフォーマット「WebAssembly」は、すでにChromeやFirefox、Edge、Safariなどの主要ブラウザでサポートされ、2019年12月にはW3Cの勧告にも到達しました。 参考：WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ このWebAssemblyをWebブラウザだけでなく、デスクトップPCやサーバ、IoTデバイスなどのあらゆる環境でセキュアに実行できるように、エコシステムの実現を推進しているのが、Mozilla
はじめに こんにちは。WEAR部フロントエンドブロックの藤井です。WEARでは現在、Webサイトのリプレイスを進めています。本記事では、リプレイスに至った背景や課題と、課題解決のために行ったリプレイスのアーキテクチャ選定についてご紹介します。 なぜリプレイスするのか WEARはサービスローンチしてから約10年が経ちます。これまでローンチ当時の技術スタックのまま開発を続け、サービスを成長させてきました。今後もより継続的にスピード感を持ってユーザーへ価値を届けていくにあたってさまざまな課題があったため、新たな技術スタックでリプレイスを開始することにしました。 リプレイス前の環境 リプレイス前の環境はオンプレミスの環境にロードバランサー、Windowsサーバー(IIS)があり、そこでVBScriptが動いています。VBScriptでテンプレートHTMLにデータを流し込み、ブラウザに表示する仕組み
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
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
Fastlyが開発者向けの無料プランを提供開始。CDNやDDoS対策、Wasm対応ランタイム、KVストアなど提供
開発者向けの無料プランでは、月50ドル相当のCDN、L3/4のDDoS対策、画像の最適化、Wasm対応のエッジランタイム、エッジでのキーバリューストア（1GB）、ログのリアルタイムストリーミングによる可観測性などを始めとする各種機能が提供されます。 すでに日本語版の価格表にも無料プランが表記されており、クレジットカード不要で申し込めるようになっています。
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でかつ
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
FastlyからStarleyに転職しました。Starleyは音声会話型おしゃべりAIアプリ「Cotomo」(コトモ)を開発している会社です。 cotomo.ai StarleyはFastlyとは打って変わってB2Cのスタートアップです。今回の転職ではせっかくなので生成AIに多少なりとも関わりたいと思っていて、Starleyはその点でがっつり生成AIを使ったサービスを開発していて、LLMの自前運用もしています。そして「生成AIで雑談」というのはおそらく技術的にはかなり難しい挑戦で、そこに「ときめき」がありました。 ところで、Fastlyはちょうど5年ほど勤めましたが、このたび大規模レイオフがあってその対象になってしまいました。レイオフの対象になった原因はおそらくこのところパフォーマンスが下がっていたせいです。去年の夏に新型コロナに掛かって以来ずっと体調が悪く*1、ついには2024年の3月か
PR TIMESのCDNをCloudFrontからFastlyに移行しました | PR TIMES 開発者ブログ
こんにちは、インフラチームテックリードの櫻井です。 今回はプレスリリース配信サービスの prtimes.jp で使用しているCDNをCloudFrontからFastlyに移行したことについて紹介します。 CDNの基本的な情報は割愛するので、もしCDNについて基本的なことを知りたいという方はググるなりChatGPTるなりしてください。 なぜ移行する必要があったのか まずCloudFrontからFastlyに移行した理由について説明します。 prtimes.jp のプレスリリース詳細ページは現在SmartyテンプレートとjQueryというレガシーな技術で構成されています。 今後このプレスリリース詳細ページをReact化することでフロントエンドの開発スピードを向上させることを予定しています。 しかしReact化を行うと、検索エンジンのクローラーがJavaScriptを実行できない場合にページの内
Layer0というJamstackプラットフォームを試してみた記事です。 Jamstackプラットフォームが何かは表現しにくいですが、Netlify、Vercel、Cloudflare PagesみたいなSPAなアプリケーションとかをホスティングしてくれるサービスです。 Cloudflare Pages・Vercel ・Netlify の違いや使い分けをまとめる Layer0はMoovweb XDNという名前のプロダクトでしたが、2021年4月にLayer0へリブランディングしています。 Moovweb is officially Layer0! 📝 XDN = Experience Delivery Network Layer0は、Netlify、Vercel、Cloudflare PagesのようにSPAアプリケーションをホスティングできるプラットフォームです。 他のプラットフォーム
※ Fastlyの公式イベント「Yamagoya 2021」で発表した内容を再編した記事です。 今回はFastly Image Optimizerを活用したnoteでの画像配信効率化についてお話します。よろしくお願いします。 note株式会社の和田と申します。 2019年4月にnoteに入社し、現在は法人向けサービスであるnote proの基盤システム開発のチームリーダーを担当しています。 Fastly導入前の画像配信における3つの課題noteでは画像配信に多くの課題を感じていましたが、エンジニアの人数が少ない時代もあり、なかなか手がつけられていないのが現状でした。 まずは、Fastly導入前にどのような問題があったのか、画像配信における3つの課題について説明していきます。 1つ目の課題は、アプリケーションサーバーへの負荷です。 noteはサーバーサイドをRailsで実装しており、Carr
メルカリ Shops の開発 vcl, python, golang, containers, typescript, etc. が入っている monorepo で開発が行われている。 なので、あまり専門性はあってもどの領域でも開発を行う。 メルカリアプリ上で動いているため、 webview がベースとなりパフォーマンスは普段以上に求められている。 技術スタックはこちらを参照 ユーザーへの UX を下げないために。。 First Meaningful Paint を速くするSkeleton などでフィードバックを適切に行う => とりあえず速く結果を返却すればよい 結果を速く返すために考えること 共通な結果はすべてキャッシュし、CDN などを使い近くに置く極力、ユーザーからのアクセスを origin まで到達させない常に新鮮な結果を近くに保持することにより、上記を満たせるようにする =>
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
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() がプロジェクト構造を解析してフレーム
HTTP/3は、HTTPの次のバージョンとしてIETF（Internet Engineering Task Force）が標準化を進めています。これまでのHTTPとの最大の違いは、トランスポートプロトコルとしてQUICを採用し、それに最適化することで、より高速で効率的な通信を実現するところです。 それにより、いまよりも高速なWebページの表示や高速に実行できるWebアプリケーションなどが期待できます。 HTTP/3は新たなトランスポートのQUICを利用 現在使われているHTTP/2 やHTTP/1.1などでは、トランスポートプロトコルとしてTCP（Transmission Control Protocol）が使われています。 TCPは内部で輻輳制御や再送などを自動的に行うことで通信が確実に行われることを保証してくれる便利なプロトコルですが、オーバーヘッドが大きく、確実に通信が行われるまで待
█ 月に ██████████████, ███████████, ███████ から誕生日を祝ってもらったのですが、そのときにマッチングアプリ代金を誕生日プレゼントとしてもらいました。とても生々しいですね。誕生日プレゼント何が欲しいか聞かれたときにふざけて「█████ が欲しい」とか言ってたらまさかこのような形でもらうことになって驚きました。今日は █ ヶ月マッチングアプリをしてみた結果をご報告しようと思います。 マッチングアプリにワクワクまずマッチングアプリに入ると女性がずらっと並んでいて「もしかして結婚相手と出会えるのかもしれない」という気持ちになって、ワクワクしました。とりあえずマッチングのためには魅力的な ███████████ が大事であるとのことで、その場に居合わせた ██████████████, ███████████, ███████ に書いてもらったり、登録する写真
Why FastlyProductsServicesSolutionsDevelopersPartnersResourcesPricing 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 Com
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
Why FastlyProductsServicesSolutionsDevelopersPartnersResourcesPricing QUIC matches TCP's efficiency, says our research. | FastlyWe’ve shared a lot about how much we love QUIC (and why we’re building our own implementation called quicly). It promises latency reduction, improved throughput, resilience to client mobility, and increased privacy and security. Excitingly, the QUIC working group at the I
2021 年 6 月 8 日に発生した障害について
2021 年 6 月 8 日に発生した障害について2021 年 6 月 8 日、未確認のソフトウェアバグが特定のお客様のサービス設定変更でトリガーされ、グローバル規模の障害が発生しました。当社は、事象発生から 1 分以内に障害を検知し、原因を特定して隔離し、該当の設定を無効化しました。49 分後には、ネットワークの 95％ が復旧しました。 今回の障害は広範囲かつ深刻なものであり、お客様にご迷惑をおかけしたことを深くお詫び申し上げます。 概要2021 年 5 月 12 日、Fastly が実装を開始したソフトウェアに、非常に特殊かつ例外的な状況下でトリガーされる可能性のあるバグが含まれていました。 2021 年 6 月 8 日、特定のお客様のサービス設定変更が有効であったにもかかわらず、その実行でトリガーされたバグにより、当社のネットワークの 85％ で障害が発生しました。 2021 年
Fastlyのパスベースルーティングで実現するWEARのゆるやかなクラウド移行 - ZOZO TECH BLOG
はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの長尾です。 WEARは2013年にリリースされ、現在8年目のサービスです。そして、2004年にリリースされた当時のZOZOTOWNと同じアーキテクチャを採用しているため、比較的古いシステム構成で稼働しています。本記事では、そのWEARのWebアプリケーション刷新とクラウド移行で実践している、Fastlyを活用したパスベースルーティングによる段階移行の取り組みを紹介します。 WEARをリプレイスする理由 WEARのWebアプリケーションは、データセンターでオンプレミス（以下、オンプレ）上で稼働しています。また、DBはSQL Serverを利用しています。長年このアーキテクチャで成長を続けてきましたが、今後さらに成長を加速させていくためには以下の3点を実現する必要があります。その実現に向け、2年前からリプレイスに
目次 はじめに Next.js × GraphQL のサーバー間通信 Fastly でのコンテンツ配信とキャッシュ方針 vanilla-extract の採用とスタイリングシステム Chromatic による UI テスト / UI レビュー Datadog でのサービスモニタリング ジャンプTOON の CI/CD リリース戦略とブランチ運用の工夫 おわりに はじめに ジャンプTOON の Web 版（以降、ジャンプTOON Web）の開発を担当している2024年度新卒入社の鏑木 俊樹（かぶらき としき） @tosssssy_ です。 5 月にサービスを開始した「ジャンプTOON」は、オリジナル縦読みマンガ作品や人気作品のタテカラー版を連載する、ジャンプグループ発の新サービスです。 ジャンプTOON Web では Next.js App Router （v14.2）を採用して開発をしてお
こんにちは、株式会社カウシェの Architect の伊藤です。 本稿では、カウシェが CDN の構築に利用している Fastly Compute@Edge について、「採用した理由」や「テストやデプロイの方法」などを実装例を混じえてご紹介します。 伊藤 雄貴 / @yuki.ito DeNA を経て 2018 年にメルペイにジョインし、Tech Lead や Architect としてマイクロサービスの開発や組織横断的な技術課題の解決に携わる。カウシェには立ち上げのタイミングから副業として参画し Backend 全般の実装を行う。2022 年 7 月より Architect としてカウシェに正式にジョインし、全社的な技術戦略の意思決定や技術基盤の構築に携わる。 Fastly Compute@Edge とはFastly Compute@Edge は Fastly が提供しているコンピューテ
ご指定の言語に対応しておりません
Fastly を試してみませんか ? アカウントを作成してすぐにご利用いただけます。また、いつでもお気軽にお問い合わせください。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fastlyについて知らないかもしれない30のこと – TravelBook Tech Blog
QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介
Fastly で Next.js アプリケーションを実行
FastlyがHTTP/3とQUICのサポートを発表
Fastly Launches Highly-Secure Serverless JavaScript
QUIC vs TCP: Which is Better? | Fastly