ライブ HLS 配信の本質的な課題は帯域幅ではありません。それは、オリジンへの総トラフィックを「オブジェクトごとに全ネットワークで 1 回」まで厳密に収束させることです。OpenResty Edge は、これを 3 つのメカニズムで実現します。プレイリストとセグメントに対する別々のページルール（相反する TTL）、「Use stale proxy cache」アクション（期限切れリフレッシュ時のスタンピードを抑制し、オリジン障害時にフォールバックする）、そしてゲートウェイパーティションで構築するシールド層です。本記事で紹介する設定は、実際の本番環境から得られたものです。世界的に注目を集めたトップレベルのスポーツ中継において、複数の OpenResty Edge ゲートウェイノードがプライベート CDN を構成し、イベントのピーク時に膨大な同時接続視聴者を支えました。その背後にある計算コストの高い GPU トランスコーディングオリジンは、終始「オブジェクトごとに 1 回」のオリジンフェッチに対応するだけでよく、盤石そのものでした。また、従量課金であり、オリジン側の挙動がベンダーのブラックボックスになりがちなマネージド CDN とは異なり、この配信レイヤーは完全に自社インフラ上で動作し、オリジン保護の戦略は常に自らの管理下に置かれます。

OpenResty Edge の試用をすぐに申請する

HLS（HTTP Live Streaming）のキャッシュは一見すると単純です。.m3u8 プレイリストと .ts セグメントに対する HTTP リクエストにすぎません。しかしライブ HLS には、素朴なキャッシュ手法を突き破る特性が一つあります。プレイリストは数秒ごとに期限切れになり、その一回一回がオリジンを圧倒するリクエストの嵐（キャッシュスタンピード／サンダリングハード〔thundering herd〕）を引き起こしうるのです。さらに複数の CDN ノードが同一のオリジンにフェッチする場合、その負荷はノード数に比例して増幅されます。以下では、原理から設定まで順を追って、オリジンを本当に保護できる配信レイヤーを構築していきます。

なぜライブ HLS は素朴なキャッシュ構成を突き破るのか

1 本の HLS ライブストリームは、性質がまったく異なる 2 種類のオブジェクトで構成されます。

m3u8 プレイリストts セグメント
URL固定、内容は数秒ごとに更新セグメントごとに新しい URL
キャッシュ可能性極めて短い TTL（秒単位）長い TTL（書き込み後は不変）
障害モード期限切れの瞬間のオリジンの嵐コールドスタート取得時のオリジンの嵐

このうちプレイリストの期限切れリフレッシュこそ、最も見落とされやすいリスクです。nginx 式のキャッシュロックは「新規」キャッシュエントリの作成のみを重複排除し、「期限切れ」エントリのリフレッシュを直列化しません。 そしてライブプレイリストは、その設計上、数秒ごとに期限切れになります。膨大な視聴者の実際の同時接続下では、期限切れのたびに、本来数リクエストしか捌かないはずのオリジンへ数百のリクエストが同時に殺到しうるのです。

このリスクはマルチノードアーキテクチャで劇的に増幅されます。本番環境では通常、複数の CDN／エッジノードが同一のオリジンにフェッチします。N 個のエッジノードがそれぞれ期限切れの瞬間にオリジンフェッチの波を漏らせば、オリジンが受けるのは N 倍の嵐です。そしてオリジンのリンクがひとたび飽和すると、自己増幅の悪循環に陥ります。ランダムなパケットロス、フェッチの遅延、そしてタイムアウトがさらに多くのリクエストを解放し、最終的にはすべてのノード、すべての視聴者の配信が一斉に崩壊します。

言い換えれば、システムの生死を決めるのは、いずれか単一ノードの帯域幅の配分比ではなく、「オリジンへの総トラフィック」がオリジンの許容能力の範囲内に厳密に抑えられているかどうかです。キャッシュの重複排除が失われるほど、オリジンの負荷はノード数と視聴者数に比例して増大します。

したがって、設定の目標は次のとおりです。

  1. プレイリストのリフレッシュのたびに、視聴者が何人いようとも、各ノードにつきオリジンフェッチはちょうど 1 回のみ許可します。
  2. 新しいセグメントごとに、各ノードにつきオリジンフェッチはちょうど 1 回のみ許可します。
  3. オリジンが遅くなったりダウンしたりしたとき、集団的なオリジンフェッチやエラー応答ではなく、期限切れ（stale）コンテンツをフォールバックとして提供します。
  4. ノード数が多い場合、シールド（親）キャッシュを追加し、「ノードごとに 1 回」をさらに「全ネットワークで 1 回」まで収束させます。

これらを OpenResty Edge で一つずつ実装していきましょう。OpenResty Edge は、アプリケーション（Application）、アップストリーム（Upstream）、ページルール（Page Rule）といったすべてを Admin コンソールで管理し、設定変更はリロードや再起動なしでゲートウェイノードに配信されます。これはライブシステムをオンラインでチューニングする際に非常に便利です。

ステップ 1：HLS オリジンを指すアップストリームを作成する

アプリケーションの下に、HLS オリジン（パッケージャーまたはトランスコーダー）を指すアップストリームを定義します。バックアップオリジンがあれば、あわせて追加します。

アップストリームの設定

ここで、具体的な UI に依存しない、長期的に有効な容量に関するヒントを一つ挙げます。オリジンの許容能力を、全ネットワークで共有される厳格な予算として扱うことです。見積もりは単純です。オリジンのリンク帯域幅 ÷ セグメント 1 個あたりの取得速度 ≈ オリジンが耐えられる同時オリジンフェッチの上限、となります。この上限はすべてのエッジノードで共有される点に注意してください。10 個のノードがそれぞれ「数回余分にフェッチするだけ」でも、オリジンで集約されれば数十倍の負荷になります。全ネットワークで予想される同時オリジンフェッチの総数が、この上限を十分に下回るようにしてください。以下のキャッシュ戦略に従えば、定常状態のオリジントラフィックは「オブジェクトごと、ノードごとに 1 コピー」にすぎないはずです。

ステップ 2：プレイリストとセグメントに別々のページルールを作成する

プレイリストとセグメントは相反するキャッシュ戦略を必要とするため、それぞれに 1 つずつページルールを作成します。

ページルール一覧

ルール 1 ── プレイリスト。 条件（Enable when）：Variable に URI、Operator に Suffix matches、Value にプレイリストの拡張子を設定します（本記事のスクリーンショットではカスタム拡張子 .m38u を使用していますが、標準的な HLS の命名は .m3u8 です。実際のストリームの命名に合わせてください）。

ルール 2 ── セグメント。 条件：URI のサフィックスが .ts にマッチ（fMP4/CMAF を配信する場合は「Add more value」で .m4s、.mp4 を追加できます）。このルールにはアクションも一つ追加する必要があります。レスポンスヘッダー Access-Control-Allow-Origin: "*" を設定することです。これはブラウザ側のプレイヤー（hls.js など）がクロスオリジンでストリームを取得するために必須です。OpenResty Edge でレスポンスヘッダーのアクションを一つ追加するだけでよく、オリジンを変更する必要はありません。

両ルールとも同一のアップストリームを指し、Balancing policy は Round Robin とし、いずれも最下部の 「Skip any subsequent page rules when this rule matches」 にチェックを入れます。マッチしたら処理を止めることで、後続のルールがキャッシュ戦略を誤って上書きするのを防ぎます。

ステップ 3：プロキシとリトライの設定

ルール編集ページを開き、Proxy ブロックでアップストリームを選択します。本番設定における重要な項目は次のとおりです。

プロキシとリトライの設定

  • Proxy to upstream：ステップ 1 で作成したアップストリームを選択します。「Add a new backup upstream」でバックアップアップストリームを設定できます（すべての主アップストリームノードが失敗した場合にのみ起動します）。
  • Retry times：「Same as the number of upstream nodes」にチェックを入れ、リトライ回数をアップストリームのノード数に自動的に一致させます。
  • Retry condition：error, timeout, invalid header, http 500, http 502, http 503, http 504 ── 単一ノードの取得が失敗したら、エラーをそのままプレイヤーに投げるのではなく、直ちに別のノードでリトライします。
  • Connect / Send / Read timeout：それぞれ 6 秒。ライブ配信ではこれらの値は長すぎない方がよいです。タイムアウトが短いほどフェイルオーバーが速くなります。6 秒は無難な出発点であり、オリジンの応答が安定していれば、接続タイムアウトはさらに 2〜3 秒まで下げられます。

ステップ 4：キャッシュの設定

ルール編集ページで Cache スイッチをオンにし、各項目を設定します。

キャッシュキーの設定

Cache key components：URI + Query string。これはデフォルトの組み合わせです。Query string を残すかどうかは URL の形態によります。プレイヤーが視聴者ごとに異なるクエリパラメータ（認証トークン、セッション ID、タイムスタンプ）を付加する場合は、Query string コンポーネントを削除しなければなりません（コンポーネント右側の × をクリック）。さもないと視聴者ごとにキャッシュキーが分かれ、ヒット率が音もなくゼロに落ちます。1000 人の視聴者が同一のセグメントをリクエストすれば 1000 回のオリジンフェッチになるのです。認証は別途アクセスルールで行ってください。設定を誤った場合の症状はログに一目瞭然です。同一のファイルが、クエリ文字列だけ異なる形で繰り返し MISS するのです。本例のストリーム URL には揮発性のパラメータが含まれないため、デフォルトのままで問題ありません。

Caching by Default：ENABLED。オリジンが Cache-Control/Expires を送らない場合、ゲートウェイはデフォルトではキャッシュしません。この項目をオンにすると、そうした応答もキャッシュされます。

Always Cache：ENABLED ── オリジンのキャッシュ制御ヘッダーを無視し、ここで設定した有効期限に従って強制的にキャッシュします。これはライブ配信で推奨される手法で、TTL は完全にゲートウェイの管理下に置かれます。

  • プレイリストルール：Expiration Time 2 秒、Status Code は 200 のみ（セグメント長のおよそ半分。本例のセグメントは約 3〜4 秒）。
  • ts セグメントルール：Expiration Time 1 時間、Status Code は 200 のみ。セグメントは書き込み後は不変なので、理論上はさらに長くキャッシュできますが、ライブには 1 時間で十分すぎるほどです。

Status Code 欄には200 のみを入れる点に注意してください。5xx を決して加えないでください。さもないと一度のオリジン障害がキャッシュされ、オリジンが復旧した後もエラーページを全員に提供し続けてしまいます。

以下の 2 枚の図は、プレイリストルール（2 秒）と ts セグメントルール（1 時間）の実際の有効期限設定です。

プレイリストルールの有効期限

セグメントルールの有効期限

Cache scope：Domain（ドメインごとにキャッシュを分離）。

Browser Cache：ENABLED。有効期限はゲートウェイキャッシュに合わせ、プレイリストは 2 秒、セグメントは 1 時間とします。視聴者のブラウザにも短時間キャッシュさせることで、エッジノードへの重複リクエストをさらに削減します。

Convert request method HEAD to GET：ENABLED。HEAD の探索リクエストがキャッシュを迂回するのを防ぎます。

ステップ 5：「Use stale proxy cache」アクションを追加する ── 最も重要なステップ

これはライブ HLS において最も重要で、最も見落とされやすい設定です。OpenResty Edge では、これはページルール内の一つのアクションにすぎません。「Add a new action」をクリックし、**「Use stale proxy cache」**を選択して、「Use in the following cases」で以下にチェックを入れます。

Use stale proxy cache アクション

  • ✅ updating ── プレイリストの 2〜3 秒ごとの期限切れリフレッシュに対応します。1 つのリクエストがオリジンへリフレッシュしに行く間、他のすべてのリクエストは直ちにわずかに期限切れの旧コピーを受け取ります。
  • ✅ error、timeout ── オリジンへの接続が失敗またはタイムアウトしたとき、旧コンテンツでフォールバックします。
  • ✅ http 502、http 503 ── オリジンがエラーを返したときも、エラーをプレイヤーに透過せず、直前に成功した応答でフォールバックします。

なぜ updating がこれほど重要なのでしょうか。前述のとおり、キャッシュロックは新規キャッシュエントリの作成のみを重複排除し、期限切れエントリのリフレッシュは直列化しません。そしてライブプレイリストは設計上数秒ごとに期限切れになります。この項目がないと、期限切れのたびにオリジンの嵐が起こりうるうえ、ロックのスコープは単一ノードに限られるため、複数ノードの漏れがオリジン上で直接積み重なります。updating にチェックを入れると、リフレッシュサイクルごと、ノードごとにオリジンフェッチはちょうど 1 回になります。

有効にすれば、オリジン障害も優雅に縮退します。視聴者は最後のプレイリストを受け取り続け、プレイヤーはライブエッジで待機してポーリングを続け、オリジンが復旧すればシームレスに再生を継続します。すべてのプレイヤーが一斉にエラーで落ちる、ということがありません。

両方のルール（プレイリストとセグメント）にこのアクションを追加すべきです。セグメントは新しい URL であり、多くの場合フォールバックできる旧コピーはありませんが、繰り返しリクエストされるセグメントやオリジンの一時的な揺らぎに対しては、なおフォールバックの価値があります。セグメントを本当に下支えするのは、ステップ 3 のリトライ機構（retry condition ＋ バックアップアップストリーム）です。

ついでに、しばしば混同される 2 つの事柄を整理しておきましょう。

  • 5xx をキャッシュする（誤り）：Always Cache の Status Code にエラーコードを含めると、エラーページがキャッシュに保存され、提供され続けます。ステップ 4 ですでに 200 のみと強調したとおりです。
  • 5xx のときに期限切れキャッシュを提供する（正しい）：「Use stale proxy cache」で http 502/503 にチェックを入れると、オリジンがエラーを返したときに直前に成功した応答を提供します。

一つの暗黙の前提があります。期限切れキャッシュのフォールバックは、期限切れオブジェクトがまだディスク上にある間だけ機能します。キャッシュの期限切れは削除ではありません。期限切れファイルは、TTL が過ぎた瞬間に消えるのではなく、キャッシュゾーンの容量ポリシーによって退避されます。これこそが stale メカニズムが機能する理由です。

OpenResty Edge ですべてのアプリケーションを管理する

ステップ 6：マルチノードアーキテクチャ ── ゲートウェイパーティションでシールド層を構築する

ここまでのすべてのメカニズムのスコープは単一のゲートウェイノードです。キャッシュロックと期限切れキャッシュのフォールバックが、各ノードのオリジンフェッチを「オブジェクトごとに 1 回」まで収束させます。しかしエッジノードの数が増えると、オリジンが見るのは依然として「ノード数 × オブジェクトごとに 1 回」です。数秒ごとにリフレッシュされるプレイリストのようなオブジェクトでは、数十ノードの合計ポーリング負荷は依然として無視できず、しかもいずれか単一ノードの設定の後退（たとえばあるノードが期限切れキャッシュの再利用を設定し忘れる）が、オリジンに直接さらされてしまいます。

OpenResty Edge のゲートウェイパーティション機構は、これを自然に解決します。OpenResty Edge において、パーティションはゲートウェイクラスターのグループであり、各パーティションは異なるアプリケーション設定を独立して公開できます。これを利用すれば、2 段のキャッシュ（シールド／親）アーキテクチャを直接構築できます。これはプライベート CDN ネットワークを構築する際の一般的な手法でもあります。

視聴者 ──> エッジパーティション（edge partition、N 個のクラスター／ノード）
              ──> シールドパーティション（shield partition、オリジンに近い小さなクラスター 1 個）
                        ──> GPU トランスコーディングオリジン

具体的な手順は次のとおりです。

  1. シールドパーティションを作成する：Gateway Clusters ページで、オリジンと同一のデータセンター（または近接した場所）に配置する新しいゲートウェイクラスターを作成し、専用のパーティション（例：shield-partition）に組み入れます。
  2. シールドパーティションに「オリジン取得アプリケーション」を公開する：そのアップストリームは実際のオリジンを指し、ページルールは本記事の最初の 5 ステップとまったく同じように設定します（ルールの分割、キャッシュキー、TTL、期限切れキャッシュのフォールバック）。
  3. エッジパーティションのアップストリームを変更する：視聴者向けのエッジアプリケーションのアップストリームは、もはやオリジンではなく、シールドパーティションのノードを指すようにします。
  4. 両方のアプリケーション設定は、同一の OpenResty Edge の Admin コンソールで管理・公開され、ノードのリロードは一切不要です。

2 つのアプリケーションを別々のパーティションに公開する

こうすれば、エッジノードがいくつあろうと、オリジンが受けるのはオブジェクトごとに全ネットワークで 1 回のフェッチだけになります。シールド層は、天然の「設定の防波堤」でもあります。たとえあるエッジノードでスタンピードが発生しても、その嵐はシールドのキャッシュと重複排除に吸収され、脆弱なトランスコーディングオリジンには決して到達しません。さらに、ルール編集ページの Proxy ブロックには 「Use Multi-tier Network policy」 スイッチ（エンタープライズ機能）があり、多層ネットワークポリシーに従ってオリジン取得の経路を組織するもので、パーティションアーキテクチャと組み合わせて利用できます。

また、Cache ブロックには 「Gateway Cluster Level Cache Sharing」 スイッチがあります。有効にすると、一貫性ハッシュによって同一のリソースが常にクラスター内の同一ノードに落ち、そのノードがキャッシュを一元的に保持し、クラスター内の他ノードはオリジンにそれぞれ取得しに行くのではなく、そのノードからデータを取得します（利用前に Global Config General ページで Cluster Hash を有効にする必要があります）。これは単一クラスター内部でオリジントラフィックをさらに収束させるもので、パーティションレベルの親アーキテクチャと相補的な、もう一段の収束です。

設定の検証

変更を配信し（OpenResty Edge はリロードなしで設定をゲートウェイノードに伝播します）、クライアントからテストします。

# プレイリスト：最初のリクエストは MISS、その後約 2 秒以内に HIT。期限切れリフレッシュのたびに
# STALE/UPDATING が現れる ── MISS が連続することは決してあってはならない
curl -sI https://your-edge-domain/live/stream.m3u8 | grep -i cache

# セグメント：各セグメントはちょうど 1 回だけ MISS、その後 1 時間はすべて HIT
curl -sI https://your-edge-domain/live/seg-1001.ts | grep -i cache

本番投入の前に、srs-bench で実際の HLS プレイヤーの挙動（プレイリストのポーリング ＋ セグメントのダウンロード）をシミュレートし、一度負荷試験を行うことを推奨します。

# 2000 個の同時 HLS プレイヤーをシミュレート
docker run --rm -it --network=host ossrs/srs:sb \
  ./objs/sb_hls_load -c 2000 \
  -r https://your-edge-domain/live/test-channel.m3u8

試験中は、プレイリスト期限切れの瞬間のオリジンリクエスト数を観察し、パターンごとに問題を切り分けます。

  • 健全：視聴者数にかかわらず、オリジンはプレイリストのリフレッシュサイクルごとに約 1 リクエスト、新しいセグメントごとに約 1 リクエスト。
  • 期限切れスタンピード：プレイリストのサイクルごとにオリジンリクエストが噴出する → 「Use stale proxy cache」の updating が効いていない。
  • キャッシュキーの断片化：同一のオブジェクトが異なるクエリ文字列で繰り返し取得される → キャッシュキーを修正する。
  • タイムアウトの連鎖：オリジンが遅い間、オリジンリクエストが減るどころか増える → error/timeout ケースの期限切れキャッシュのフォールバックを確認し、接続タイムアウトを短くする。

最後に、配信中に意図的にオリジンを 30 秒間停止してみてください。プレイヤーはライブエッジで待機し、その後復帰するはずです ── エラーで落ちるのではなく。

まとめ

OpenResty Edge でライブ HLS を運用する際の思考モデルは次のとおりです。

  1. プレイリストとセグメントを別々のページルールにする ── 両者は相反する TTL を必要とし（本例：プレイリスト 2 秒、セグメント 1 時間）、「マッチしたら後続ルールをスキップ」にチェックを入れます。
  2. キャッシュキーを守る、揮発性のクエリ文字列に注意する ── キーの断片化は重複排除を音もなく破壊します。URL に揮発性のパラメータがなければ、デフォルトの URI + Query string で問題ありません。
  3. 「Use stale proxy cache」アクションこそが中核メカニズムであり、キャッシュロックではありません ── 必ず updating（期限切れリフレッシュの重複排除）と error/timeout/http_502/http_503（障害フォールバック）にチェックを入れてください。ロックはコールドスタートの取得しかカバーせず、プレイリストの期限切れスタンピードを止められるのは stale だけです。
  4. Always Cache のステータスコードには 200 のみを入れる ── オリジンがエラーを返したときは stale で旧コンテンツを提供しますが、エラーそのものは決してキャッシュしません。セグメント層にはさらにリトライ条件とバックアップアップストリームを組み合わせます。
  5. オリジンの許容能力を、全ネットワークで共有される厳格な予算として扱う ── 負荷試験で、各ノードがオブジェクトごとにちょうど 1 回だけオリジンフェッチすることを検証します。オリジンの負荷は単一ノードの漏れ量にノード数を掛けたものに等しく、重複排除の経路が失われることは単なる性能の低下ではなく、自己増幅する雪崩を引き起こします。
  6. ノードが増えたらパーティションでシールド層を構築する ── 「ノードごとに 1 回」を「全ネットワークで 1 回」に収束させます。クラスターレベルのキャッシュ共有（Gateway Cluster Level Cache Sharing）はクラスター内部でさらに一段収束させます。

これらを正しく行えば、計算コストの高いトランスコーディングオリジンが、大規模イベント級の視聴者数を余裕をもって支えられます。増加はエッジでのみ起こり、オリジンは常に「オブジェクトごとに 1 コピー」しか見ません。これこそが、ライブ配信のために OpenResty Edge でプライベート CDN を構築することの価値です。

よくある質問（FAQ）

ライブ HLS のプレイリストはどのくらいキャッシュすべきですか？

無難な経験則は、セグメント長のおよそ半分です。セグメントが 3〜4 秒なら、プレイリストの TTL は 2 秒に設定します。TTL が長すぎると視聴者は遅れたライブエッジを見ることになり、短すぎるとリフレッシュ頻度が増えます。「Use stale proxy cache」の updating オプション（リフレッシュサイクルごと、ノードごとに 1 回のオリジンフェッチ）と組み合わせれば、TTL の選択はライブ遅延にのみ影響し、オリジンの負荷にはもはや影響しません。

なぜキャッシュロックはライブシーンのスタンピードを防げないのですか？

キャッシュロック（proxy cache lock）は、新規キャッシュエントリに対する同時オリジンフェッチを直列化するだけで、期限切れエントリのリフレッシュには効きません。VOD のシーンではオブジェクトは一度書き込まれれば長期間有効なので、ロックで十分です。しかしライブプレイリストは数秒ごとに期限切れになり、その一回一回がロックの管理外にある同時リフレッシュであり、stale-while-updating メカニズムで重複排除しなければなりません。

fMP4/CMAF ストリーム（.m4s セグメント）を配信する場合、設定は異なりますか？

セグメントルールの URI サフィックスのマッチに .m4s、.mp4 を追加するだけです。キャッシュ戦略は .ts とまったく同じです（不変、長い TTL）。プレイリスト（.m3u8）の戦略も変わりません。

ライブ配信にはマネージド CDN と自社ホスティングのどちらを使うべきですか？

視聴者規模が小さい場合や単発のイベントであれば、マネージド CDN が最も手軽な選択肢です。しかし視聴者規模が拡大すると経済性は逆転します。マネージド CDN の転送料金は視聴者数に比例して増加する一方、自社ホスティングの配信レイヤーの容量コストはほぼ固定です。さらに、オリジン保護の挙動（stale 戦略、シールド層、キャッシュキー）を、ベンダーのブラックボックスに委ねるのではなく、完全に自らの管理下に置けます。なお、自社ホスティングはゼロから組み立てることを意味しません。OpenResty Edge は商用のセルフホスト型ソフトウェアであり、ゲートウェイノードは自社のマシン上で稼働し、すべてを一つのコンソールから管理できます。

エッジノードがどのくらいになればシールドパーティションを追加する価値がありますか？

厳密な閾値はなく、判断の拠り所はオリジンの予算です。オリジンが見る定常状態のフェッチ量は、おおよそ「ノード数 × オブジェクトごとに 1 回」です。プレイリストの合計ポーリング頻度（ノード数 ÷ TTL）がオリジンの余裕をもって捌ける範囲に近づき始めたとき、あるいは「設定の防波堤」という耐障害性の価値が欲しいときが、シールド層を追加する価値のあるときです。OpenResty Edge では、パーティションを一つと、オリジン取得アプリケーションを一つ追加するだけであり、コストはごくわずかです。

OpenResty Edge について

OpenResty Edge は、マイクロサービスと分散トラフィックアーキテクチャのために弊社が独自開発した、オールインワンのゲートウェイソフトウェア製品です。トラフィック管理、プライベート CDN の構築、API ゲートウェイ、セキュリティ保護を一つの製品に統合し、モダンなアプリケーションの構築、管理、保護を容易にします。OpenResty Edge は業界をリードする性能と拡張性を備え、高並行・高負荷シナリオの厳しい要求を満たします。K8s などのコンテナアプリケーションのトラフィックをスケジューリングでき、膨大な数のドメインを管理できるため、大規模なウェブサイトや複雑なアプリケーションのニーズにも容易に応えます。

OpenResty Edge の試用をすぐに申請する

このチュートリアルが気に入っていただけましたら、ぜひこのブログサイトおよび弊社の YouTube チャンネルをご購読ください。ありがとうございます！

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」 の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay（動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール）と OpenResty Edge（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

中国語版の原文をご用意しております。読者の皆様による他の言語への翻訳版も歓迎いたします。全文翻訳で省略がなければ、採用を検討させていただきます。心より感謝申し上げます！