Cloudflare スタックを駆使してQBハウスの待ち人数推移を眺める - Qiita
目的 QBハウスがもたらす「省時間」効果を最大限に享受するには、QBハウスでの「待ち時間」を最小限にする必要があります。 QB HOUSEとは? | QB Lab | QBハウス "10分の身だしなみ" QB HOUSE が考える「省時間」とは、同じ社会的・経済的効果や便益を、 より少ない時間で得られるヘアカットサービスを提供することです。 このクオリティを高めていくために、私たちは多様な取り組みをスタートしています。 そのため、公式サイトでは店舗ごとの待ち人数を確認することができます。 ご利用案内 | QBハウス "10分の身だしなみ" 渋谷南口店 | 店舗検索結果 | QBハウス "10分の身だしなみ" ただ、もったいないのは「現在の」待ち人数しか確認できません。 QB PREMIUM では、アプリ予約ができるようですが、始まったばかりのサービスのため、QBハウスで待ち時間なく対応して
Cloudflare で gRPC を通す (4. ロードバランシング) - Qiita
設定フロー 公式の設定ガイドに従います。 負荷分散ダッシュボードでは下記の項目が選択可能となっています。 ロードバランサーを作成する API モニターやプールを関連つけたロードバランサーの設定 モニターを管理する API サービスの死活監視を行う、ヘルスモニターの設定 (今回は TCP Port 443 に対する TCP コネクションでサービスの生死を確認) プールを管理する API gRPC オリジンサーバの集まりである、プールの設定 (今回は国ごとにプールを作成) 下記のようなウィザードに従い、作成します。 1. ホスト名 ホスト名を入力し、オレンジ雲に倒して HTTP Proxyとします。 グレー雲の場合は HTTP Proxy はせず、DNS によるロードバランシングとなります。 2. オリジンプール プール (オリジンサーバーのグループ) を指定します。 今回はプールが 3 つ、
Cloudflare D1 のチュートリアルをやってみる - Qiita
2022年に発表され話題となっている Cloudflare D1、未だアルファ版のようですがすでにいろいろと触ってみた方も多いかと思います。 自分はVantiqという会社で自社製品であるVantiq Platform 上のアプリケーション開発・アーキテクチャ設計を業務として行っているわけですが、様々なクラウドサービスと自社製品をどう組み合わせたら面白いことができるかなと日々考えたりもしています。 Cloudflare D1 も気になっていたところで、公式のチュートリアル をやってみて、実際に手を動かして概要を理解してみたいと思います。 Cloudflare D1 とは Cloudflareが提供する、エッジロケーションに配置されたSQLiteベースのリレーショナルデータベースです。 概要は公式ドキュメントや他に秀逸な記事があるので読んでいただくとして、個人的に興味深いのは 分散データベース
Cloudflare Zaraz の効果 - Qiita
Cloudflare Zaraz Cloudflare Zaraz は Web アプリケーションに組み込まれたサードパーティツールとの通信主体をブラウザから Cloudflare のエッジ Workers にオフロードし、セキュリティとパフォーマンス、プライバシーの向上に寄与します。 本投稿では Google Analytics を有効にした Web サイトを例に Zaraz の効果を簡単に紹介します。 Zaraz 導入前 テストするサイトを Request Map Generator で確認すると下記の状態です。 WebPageTest でブラウザの挙動を見ると、当該サイトの他に Google Tag Manager、Google Analytics へのリクエストが発生しています。 Google Analytics でのモニタリングもできています。 Zaraz 導入 この状態から Cl
2022年6月21日に発生したCloudflareの大規模障害の原因 - Qiita
概要 今回は、2022年6月21日に発生したCloudflareの大規模障害についての原因がまとめられた記事が公開されたため、その内容について翻訳およびサマライズしていきます。 何が起こったのか 2022年6月21日にCloudflareの19のデータセンターのトラフィックに影響を与える障害が発生したようです。 また、この19のデータセンターはどうやら世界中のトラフィックのかなりの割合を扱う拠点だったようです。 ではなぜ、大規模な障害が発生したのかというと、原因はどうやらこれらの重要な拠点の耐障害性を向上させるための変更(ネットワーク設定の変更)を行なったことが起因しているようです。 なので、今回の障害では悪意のある攻撃等ではなかったことになります。 障害が発生した時刻と復旧した時刻 障害が発生した時刻は、2022年06月22日 15:58ごろに発生し、2022年06月22日 16:42ご
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
