Cloudflare の利用を徐々に減らして行くメモ
概要 Cloudflare の利用を徐々に減らし、Akamai Connected Cloud へ移行しているのでそれを記録していくことにする。 移行理由 ただのアンマッチで、自分のサービス選定ミス。 自社の商用サービスが期待するレベルのサポートを得るには、Cloudflare エンタープライズプランが必須な事をわかっておらず、費用面でアンマッチになった。 サポートが必要になった状況 WebSockets · Cloudflare Network settings docs 商用環境で WebSocket を利用する場合はサポート契約が必要 サポートに問い合わせ、年 2400 ドルのビジネスプランを契約を推奨されたので契約 Cloudflare LB で WebSocket が突然切断される問題 問題の報告から 6 ヶ月以上経過しても、連絡も無く問題も継続して発生 8 ヶ月目にやっと返信が
"Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例" の感想
AWS については利用していないのでよくわからない。あくまで Erlang/OTP で書かれたミドルウェアのリプレイス事例として感想を雑に書く。ちなみに、現地で発表を聞いている。 一般的な感想 自分のような AWS 素人が見てもわかりやすいシンプルなシステムになっていた HTTP/2 を利用した独自プロトコルでの双方向通信が気になる TCP/IP を利用した大量の常時接続は本当に大変だとおもう カーネルパラメーターチューニング！ 少ないリソースで、たくさんの接続を担う ゴールが素晴らしい デプロイの自動化を GitHub Actions でやってるのやっぱりいい 負荷試験にて1億台の接続を維持した状態で挙動が問題ないことを確認 最高 Graviton ベースの Fargate の活用 Go であれば arm64 向けバイナリがサクッと生成されるのは良い Erlang/OTP から Go へ
JSR Meetup に参加してきた
JSR Meetup JSR が気になっていたことや、Deno の中の人が主催というのも良いなと思って、ささっと参加してきました。自分用に雑にまとめておきます。 https://jsr.io/ https://github.com/jsr-io/jsr ハッシュタグ 自分のメモ Deno Land Inc. が開発、運用しているパッケージレジストリ プライベートは今のところ予定されていない TypeScript をそのまま登録できる ESM 対応 OSS で開発されている 自前の JSR を立てることもできる 積極的に改善されていきそう ドキュメントが生成される Web UI がモダン Deno が流行らないと苦しそう @std を Deno が持ってるのは他からはちょっとな ... って思われそう キレイな npm 雑感 印象としては使ってみても良さそうという感じです。ただ無理に npm
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
Vite でマルチページを Playwright でテストする
モチベーション ドキュメントに載せるサンプルコードを E2E テストできるようにしたい Vite でマルチページ使いたい index.html と main.ts の組み合わせ Playwright で E2E テストを実行したい 戦略 src/index.html でそれぞれのサンプルに飛べるようにしたい env.local で必要な設定を指定できるようにしたい VITE_ を使う src/spam や src/egg とサンプル毎に細かく index.html と main.ts を用意したい vite 時はいいが、vite build 時に困るので対応する必要がある vite.config.js で rollupOptions の input を設定をする必要がある エントリーポイントを src/ 以下にしたい root で設定する .env のパスは root を変更するとそこに影
サーバ転送料金まとめ
2023 年 9 月 25 日時点の 1 GB あたりの金額 1 ドル 150 円換算。 GCP 18 円 $0.12/GB 10 TB 以上利用 上り無料 AWS 12.6 円 $0.084/GB 150 TB 以上利用 上り無料 Azure 9 円 $0.06/GB 350 TB 以上利用 上り無料 Vultr 1.5 円 $0.01/GB 上り無料 Linode 0.75 円 $0.005/GB 上り無料 関連リンク S3 互換オブジェクトストレージまとめ サーバ転送料金まとめ 自社で開発している WebRTC SFU のような常時帯域を食べる。 そのため、いろいろなサービスの転送量の課金体系をまとめておくことにした。 条件 日本のリージョンがある VPS やクラウドやベアメタルなどは特に区別しない オンプレはなし GCP インターネット -> GCP は無料 Premium Tie
Meilisearch を利用して Sphinx で日本語全文検索を実現する
モチベーション ドキュメントツール Sphinx から出力した HTML オンラインドキュメントに日本語対応の全文検索機能を追加したい。 結果 オンラインドキュメントと日本語全文検索 前提 日本語全文検索に対応する OSS を利用する ドキュメントツールは Sphinx を利用する Sphinx の検索バーを置き換える サーバレスの検索は諦める サーバ運用を検討する 企業利用前提なので費用がかかっても良い 検索は難しいので検索部分は頑張らない 完璧は求めない reStructuredText を解析するのではなく HTML を解析して処理する Meilisearch を採用 いろいろ調べたりしていたが Meilisearch が良さそうと判断した。 Meilisearch 日本語検索に対応している Rust で書かれており性能がでそう Rust であれば問題が起きた際、会社でなんとかできる
k6 + Echo + go-sqlite3 + Litestream + Linode Object Storage 簡易負荷試験メモ
注意 とっても雑な検証なので参考などにはしないでください。ちょっとした興味で自分用に調べてるだけです。 結論 Echo を利用した秒 1 万リクエストを超えないウェブサービスで、かつ SQLite の機能で要件がみたせるのであれば、SQLite + Litestream 十分と判断出来る結果だった。 利用技術 Load testing for engineering teams | Grafana k6 Grafana に買収された Go で書かれた負荷試験ツール JS でシナリオが書ける Litestream - Streaming SQLite Replication SQLite リアルタイムバックアップツール mattn/go-sqlite3: sqlite3 driver for go using database/sql Litestream も使ってる 安心と信頼の matt
時雨堂クラウドサービスを支える技術 v1
v2 へ移行中です 円安の影響や、自社製品がスケールアウトに対応したこと、Cloudflare LB の WebSocket の挙動が残念だったことなどを踏まえ、サービス構成を変更を検討中です。 自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理 脱 Vultr Egress 料金が Linode だと Vultr の半額 Linode へ移行 脱 Cloudflare LB Linode の NodeBalancers へ移行 マルチリージョンでの利用は Linode の Akamai Global Load Balancer 公開待ち 脱 Cloudflare サポートに不安があるため Akamai へ移行 脱 TimescaledB 移行は Linode PostgreSQL の提供開始待ち OLAP は DuckDB + S3 互換オブジェクトス
Clubhouse リアルタイム配信の仕組みについて (解説編)
Cloubhouse はすでに OSS である Janus Gateway に切り替えており Agora は使用していないようです ライセンス Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0 前提 ざっくりと雑に解説。 どんな技術を使っていてこんな感じだろうという妄想は以下をどうぞ。 Clubhouse リアルタイム配信の仕組みについて (妄想編) 著者 商用 WebRTC SFU 開発者 WebRTC プロトコルスタック実装者 End to End Encryption プロトコルスタック実装者 Clubhouse の仕組みはとてもシンプルで配信者が N 人で、それを数千人が聞くという co-streaming と呼ばれる仕組みの一つ。この方式は今までは主に映像ありでパネルディスカッション的な使い方が主だっだ。それを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Litestream メモ
Webhook.site のまとめ