← 2026-03-15 の一覧へ戻るホーム
Cloudflare で FFmpeg をオフロードする

2026/03/10 17:41

Cloudflare で FFmpeg をオフロードする

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary

チームは、FFmpeg ベースの音声処理を共有 Fly.io インスタンスから Cloudflare のサーバーレス スタックへ移行し、CPU ボトルネックを排除して Kent Cdodds のポッドキャストアップロードの信頼性を向上させました。

  • 重要性: 3 月 6 日のエピソードが主要マシンの CPU を 400–500 % に逼迫させ、スロットリングと共有インスタンスからパフォーマンス‑CPU Fly.io インスタンスへの緊急アップグレードを招きました。
  • 変更点: エピソードは現在、ドラフト ID と R2 キーでキューに入れられ → Cloudflare Queue → Worker → コンテナが R2 から音声を取得し FFmpeg を実行、結果を再び R2 にアップロードし署名付きコールバックを投稿します。アプリはエンキュー後すぐにレスポンスを返し、トランスクリプション/メタデータ処理はコールバック後に主要サーバーで実行されます。
  • 技術詳細:
    • Queue worker は 
      202 Accepted
      でメッセージを確認し、FFmpeg を非同期で起動して本当のキュー利点を回復します。
    • コンテナは短い 
      sleepAfter
      、ハートビート ping、および「終了」シグナルを使用してアイドルインスタンスを迅速に停止させます。
    • 失敗時にローカルで FFmpeg を実行していたフォールバックパスは削除され、アプリはエンキュー失敗時に例外を投げて隠れた障害を防止します。
  • 影響: 移行後の CPU 使用率は約 60–80 % に保たれ、ピーク負荷は約 85 % 削減されスロットリングは発生しません。 Cloudflare のコストモデル（操作ごとの Queue コスト、アクティブ時のみの Container コスト）は専用 Fly.io パフォーマンス‑1x マシン（$31/月）よりも安価です。
  • 今後の作業: トランスクリプションとメタデータ抽出を Cloudflare キューパイプラインに移動し、重いジョブをコアアプリから完全に分離することを検討します。

ユーザーはより滑らかで高速なエピソードアップロード体験ができ、開発者は音声集約ワークロードのスケールとインフラコスト削減の実証済み戦略を手に入れます。

本文

Call Kent Podcast – FFmpeg をプライマリサーバーから外す

226話目まで、私は 

kentcdodds.com
をホストしている Fly.io のインスタンス上で FFmpeg をインライン実行していました。
パイプラインはシンプルで問題なく動作していたのですが、2026年3月6日に 超長時間放送が発生し、アプリが極端な CPU スロット化に陥りました。

  • ロード平均が 400–500 % に急上昇（FFmpeg 実行全体で）。
  • マシンの CPU クォータ残量はスロットされており、割り当て済みバジェットを 消費したため scheduler が抑制しました。
  • サイトは劣化し、共有 CPU からパフォーマンス CPU にインスタンスをアップグレードせざるを得ませんでした。

この事象により、プライマリマシンで FFmpeg を走らせることができなくなりました。

まずインラインで FFmpeg を実行するのは悪い考えではない理由

  • 単純さ – エピソードごとにジョブを一つ、キュー構造は不要。
  • 安全性 – 私だけがトリガーし、アプリサーバーは既に Web トラフィック用に 適切なサイズであったため、FFmpeg はその容量を利用したのみ。
  • 競合なし – 音声長や CPU クォータが上限を超えるまで。

エピソードが十分に長くなると、共有 CPU クォータはプライマリインスタンス で応答性が求められる書き込み操作と衝突します。レプリカは読み取り専用で FFmpeg を走らせることができず、唯一実行可能なのはプライマリでした – しかしそれこそ最悪の場所です。

新しいアーキテクチャ

解決策は FFmpeg 作業をすべて Cloudflare にオフロードすることです。

[Call Kent 提出] → Cloudflare Queue にジョブ（draft ID + R2 キー）を enqueue
        ↓
Cloudflare Worker がキューを消費し、Cloudflare Container へ転送
        ↓
Container が R2 から音声を取得し FFmpeg パイプライン実行、
処理済み音声を R2 にアップロード、署名付きコールバックをアプリに POST
  • アプリは即座にレスポンスを返し、FFmpeg のブロッキングがありません。
  • 署名付きコールバックで draft 状態を更新します：
    GENERATING_AUDIO → TRANSCRIBING → GENERATING_METADATA → DONE
    。
  • 管理 UI に段階的進捗ラベルが表示されます。

文字起こしとメタデータ生成はまだプライマリサーバーで実行しており、 キュー化は将来の作業です。FFmpeg の即時課題は分離によって解決されました。

コア enqueue 呼び出し（アプリ側）

// app/utils/call-kent-audio-processor.server.ts
const res = await fetch(
  `${env.CALL_KENT_AUDIO_CF_API_BASE_URL}/accounts/${env.CLOUDFLARE_ACCOUNT_ID}/queues/${queueId}/messages`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${env.CLOUDFLARE_API_TOKEN}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      content_type: 'json',
      body: { draftId, callAudioKey, responseAudioKey },
    }),
    signal: AbortSignal.timeout(10_000),
  }
);

署名付きコールバックルート（アプリ側）

// app/routes/resources/calls/episode-audio-callback.ts
const signature = request.headers.get('X-Signature');
if (!verifyCallKentAudioProcessorCallbackSignature(signature, rawBody)) {
  return new Response('Invalid signature', { status: 401 });
}
const event = parseCallKentAudioProcessorEvent(rawBody);
await handleCallKentAudioProcessorEvent(event);
return Response.json({ ok: true });

署名は HMAC‑SHA256 を用い、タイミング安全な比較で検証します。

パフォーマンスへの影響

オフロード後：

  • ロード平均が 60–80 % までに抑えられました（400–500 % から）。
  • CPU スロットイベントはなく、メモリも安定。
  • プライマリマシンはジョブ全体を通じて健康状態を保ちました。

これはエピソード処理中のアプリサーバーにおけるピーク負荷が 約 85 % 低減したことを意味します。

コスト比較

サービス価格メモ
Fly.io performance‑1x約 $31/月 + ストレージ／出口。自動停止でコストは削減されますが、ライフサイクル管理とコールドスタートが必要です。
Cloudflare Queues1 メッセージあたり 3 操作（書き込み・読み取り・削除）。個人ポッドキャスト向けに無料で、月間 1 M オペレーションは含まれます。
Cloudflare ContainersCPU 時間・メモリ・ディスク使用量で課金。Standard‑1 インスタンス（約 ½ vCPU, 4 GiB）＋ Worker と Durable Object の追加料金。アイドル時はスケールダウンしてゼロになります。
Workers / Durable Objects小規模課金。ハートビート/停止ロジックに便利です。

ポッドキャストが月に数話程度の場合、Cloudflare は低頻度の ワークロードに対しゼロまでスケールダウンできるため、コンテナは 実際に転送・処理中のみ課金されます。専用 Fly.io マシンを使用するより もコスト効率が高くなります。

変更点・改善点

  • ローカルフォールバック – コンテナ失敗時にローカルで FFmpeg を実行していたものを削除。障害を隠さないようにしました。
  • コンテナライフサイクル – 
    sleepAfter
    の代わりに Worker / Durable Object から送られるハートビートと、明示的な “finished” 信号でアイドル時に即座に停止します。
  • キューワーカーのブロッキング削除 – 今は 
    202 Accepted
    を即時返し、FFmpeg はバックグラウンドで実行されます。ワーカーがジョブ全期間をブロックすることはありません。

まとめ

  • シンプルに始める。現実が要求すればキューへ移行します。
  • 運用上の分離（重い計算をプライマリサーバーから切り離す）は、わずかなコスト節約よりも優先されます。
  • Cloudflare Queues/Containers は低頻度で高負荷なタスク（ポッドキャスト転送など）に対し、 ゼロアイドルスケールモデルを提供します。

完全実装を見るには、公開リポジトリ 

kentcdodds.com
の PR #720 をご確認ください。
質問があればいつでもお問い合わせください！

同じ日のほかのニュース

一覧に戻る →

2026/03/15 7:10

**アゲルス・リナックス ― 時代を超えて使えるソフトウェア** このソフトウェアは、年齢や経験に関係なく「時代を越えた使いやすさ」と柔軟性を重視するユーザー向けに設計されています。

## Japanese Translation: --- ## Summary Ageless Linux は意図的にカリフォルニア州の AB 1043 年齢確認法を拒否し、監視への抗議として Debian ベースのディストリビューションを位置付けつつ、オペレーティングシステムプロバイダーであり続けます。プロジェクトは標準の `/etc/os-release` ファイルを Bash スクリプト経由で「Ageless Linux」に置き換え、通常モードでも **“flagrant” モード** でも年齢確認 API を提供しません。「flagrant」 モードでは `/etc/ageless/REFUSAL` ファイルをインストールし、§ 1798.501(a)(1)–(a)(2) に対する完全かつ意図的な非準拠を明示的に宣言し、執行措置を促します。 ウェブサイトには子供、学校、図書館、および USB ドライブや Raspberry Pi Pico デバイスを通じて OS を配布するための **詳細なガイダンス** が含まれており、これらはすべて AB 1043 の下でオペレーティングシステムプロバイダー活動に該当します。また、ディストリビューションが年齢データを収集しないため「影響を受ける子供」を特定できず、影響を受ける子供ごとの罰金を算出できないことも説明しています。 Ageless Linux は暗号的に不可能であることとプライバシー懸念を理由に年齢確認を決して実装しないと主張し、Apple、Google、Microsoft などの大手テック企業が最小限のコストで AB 1043 を満たすケースとは対照的です。プロジェクトの FAQ は法的問題、コンプライアンス状況、および州最高検事への罰金可能性に関する一般的な質問に対応しています。 最後に Ageless Linux は裁判記録を取得するために、Raspberry Pi または USB ドライブを子供へ配布したことによる **$7,500 の罰金** をカリフォルニア州最高検事に請求し、AB 1043 が小規模オープンソースプロジェクトにどのように適用されるかを明確にすることを目的としています。サイトには法的問い合わせや報道関係者向けの連絡先情報（John McCardle、BDFL、FFwF Robotics LLC）が掲載されています。 ---

2026/03/15 6:27

**Show HN：Han – Rustで書かれた韓国語プログラミング言語**

## Japanese Translation: ## 要約 ハンは静的型付けでコンパイルされるプログラミング言語で、キーワードはすべて韓国語で記述されています（例：**함수**、**만약**、**반복**、**변수**）。コンパイラはRustで実装され、LLVM IRを生成し、clangがそれをネイティブバイナリに変換します。ツリー走査型インタープリタ（`hgl interpret`）により、すぐに実行して迅速な試験が可能です。 ハンの型システムは静的で、5つのプリミティブ型を持ちます—정수 (int)、실수 (float)、문자열 (string)、불 (bool)、그리고 없음 (void)。また配列・構造体・クロージャ・パターンマッチング・エラーハンドリング・ファイルI/O・フォーマット文字列・モジュール・ジェネリクス、組み込み数学関数もサポートしています。現在、配列と構造体はインタープリタのみで扱われており、コンパイラの完全なサポートは計画中です。 開発者はハンを REPL（`hgl repl`）、LSP サーバー（`hgl lsp`）によるエディター上のホバー/補完、およびさまざまな CLI コマンド：`interpret`、`build`、`run`、`repl` で操作できます。VS Code 統合は `editors/vscode` ディレクトリにあります。インストールには Rust（≥1.70）と clang が必要で、他の外部コンパイラ依存はありません。 現在の制限としては、タプル・列挙型・非同期/並行処理・ネットワーキング・サブプロセス、および配列/構造体の完全なコンパイルサポートが欠如しています。これらのギャップは今後の開発優先事項を示しています。

2026/03/15 8:10

エアバスは無人戦闘機を二機開発中です。

## Japanese Translation: Airbus は、2029 年までにドイツ空軍へ運用可能な無人協調戦闘機（UCCA）を納入する予定であり、これは Kratos Defense & Security Solutions の Valkyrie プラットフォーム上に構築され、Airbus の Multiplatform Autonomous Reconfigurable and Secure (MARS) ミッションシステムと AI‑有効化された MindShare ソフトウェアを備えています。 MARS システムは、人有人機と無人機の全グループを動的および非動的ミッションで統合して調整することができます。 **主要技術仕様：** - 元の UCCA は長さ 9.1 m、翼幅 8.2 m、航続距離 >5,000 km、MTOW 約 3 t、最大高度 45,000 ft。初飛行は 2019 年に実施されました。 - ドイツ版の初飛行は 2026 年に予定されています。 このパートナーシップには、Airbus と Rafael が Eurofighter コマンド機上で Litening 5 Advanced Targeting Pod をアップグレードし、クロスプラットフォーム接続性と戦闘致死率を向上させる作業も含まれます。 Airbus のエグゼクティブ・マーコ・ガンブラッハトは、「信頼できる主権的な戦闘能力を手頃な価格で提供する」ことの重要性を強調し、Kratos のスティーブ・フェンドリーは「ミッション化された Valkyrie は単独でも、チームとしても、人有人機と無人機の協同作戦においても利用可能である」と述べています。 この取引はドイツにタイムリーかつ大量展開が可能なドローンソリューションを提供し、AI 主導型多プラットフォーム戦闘システムへのより広範な転換を示しています。