精选文章

Photo by Philip Brown

動的トレース技術についての雑談

動的トレース技術についての雑談

バイナリ証拠駆動の脆弱性スキャン:OpenResty XRay によるバージョン推論からの脱却

バイナリ証拠駆動の脆弱性スキャン:OpenResty XRay によるバージョン推論からの脱却

バイナリ証拠駆動の脆弱性スキャン:OpenResty XRay によるバージョン推論からの脱却

OpenResty XRay 入門:コードを変更せずに、システム深層の「鼓動」を聴く

OpenResty XRay 入門:コードを変更せずに、システム深層の「鼓動」を聴く

OpenResty XRay 入門:コードを変更せずに、システム深層の「鼓動」を聴く

OpenResty XRay で 15 倍の QPS 差を解決した事例

OpenResty XRay で 15 倍の QPS 差を解決した事例

OpenResty XRay で 15 倍の QPS 差を解決した事例

OpenResty XRay Java 関数プローブ:非侵入型関数監視の実現

OpenResty XRay Java 関数プローブ:非侵入型関数監視の実現

OpenResty XRay Java 関数プローブ:非侵入型関数監視の実現

Photo by OpenResty Inc.

OpenResty XRay による ビリビリ動画の重大なオンライン障害の分析と解決

OpenResty XRay による ビリビリ動画の重大なオンライン障害の分析と解決

Photo by Jose G. Ortega Castro

OpenResty と Nginx の共有メモリ領域が物理メモリをどのように消費するか

OpenResty と Nginx の共有メモリ領域が物理メモリをどのように消費するか

Photo by Harrison Broadbent

OpenResty と Nginx のメモリ割り当てと管理方法

OpenResty と Nginx のメモリ割り当てと管理方法

OpenResty XRay で、パフォーマンスを大幅に向上し、CPU使用率を即座に削減  90%
OpenResty XRay で、パフォーマンスを大幅に向上し、CPU使用率を即座に削減 90%
無料トライアルを申し込む

最新記事

OpenResty Edge が提供する 4 階層の DDoS トラフィック制御と実測パフォーマンス

  • DDoS 防御の「不可能の三角」
  • OpenResty Edge の設計:三つの目標を同時に満たす
  • 性能はスローガンではなくエンジニアリング上の事実
  • 自動化は「おまけ」ではなく DDoS 防御の前提
  • 可観測性:透明性は信頼の基盤
  • 内蔵かつ適応型の防御体系の構築
  • DDoS 防御の「不可能の三角」
  • OpenResty Edge の設計:三つの目標を同時に満たす
  • 性能はスローガンではなくエンジニアリング上の事実
  • 自動化は「おまけ」ではなく DDoS 防御の前提
  • 可観測性:透明性は信頼の基盤
  • 内蔵かつ適応型の防御体系の構築

OpenResty Edge におけるデータ保護:定期バックアップから自動フェイルオーバーまで

  • 第一の防衛線:定期バックアップと異機間同期
  • 第二の防衛線:主系・従系ストリーミングレプリケーション
  • 第三の防衛線:自動フェイルオーバークラスター
  • 三層の比較と選定の指針
  • まとめ
  • 第一の防衛線:定期バックアップと異機間同期
  • 第二の防衛線:主系・従系ストリーミングレプリケーション
  • 第三の防衛線:自動フェイルオーバークラスター
  • 三層の比較と選定の指針
  • まとめ

OpenResty Edge × Kubernetes で実現する統合管理プレーン

  • K8s 時代のゲートウェイのジレンマ:静的な管理モデルとクラウドネイティブ環境のミスマッチ
  • 機能 1:真の弾力性を実現――ゲートウェイノードのライフサイクル管理の自動化 *機能 2:サイロ化から一元管理へ — マルチ K8s クラスタの戦略的価値
  • 機能 3:組織構造との適合——2層アップストリームシステムの設計思想
  • K8s 時代のゲートウェイのジレンマ:静的な管理モデルとクラウドネイティブ環境のミスマッチ
  • 機能 1:真の弾力性を実現――ゲートウェイノードのライフサイクル管理の自動化 *機能 2:サイロ化から一元管理へ — マルチ K8s クラスタの戦略的価値
  • 機能 3:組織構造との適合——2層アップストリームシステムの設計思想

OpenResty サービスにおける「見えないボトルネック」としての JSON

  • パフォーマンスの限界はどのレイヤーにあるのか
  • 一般的な「回避策」とその限界
  • なぜ「独自開発」や「独自カスタマイズ」は得策ではないのか
  • インフラストラクチャレベルの最適化:jit.cjson
  • なぜ公式(ベンダー)提供のソリューションが最適なのか
  • 極めて低い導入コスト
  • パフォーマンスの限界はどのレイヤーにあるのか
  • 一般的な「回避策」とその限界
  • なぜ「独自開発」や「独自カスタマイズ」は得策ではないのか
  • インフラストラクチャレベルの最適化:jit.cjson
  • なぜ公式(ベンダー)提供のソリューションが最適なのか
  • 極めて低い導入コスト

ビルド不要・Nginx ゲートウェイだけで実現する 120 MB/s のリアルタイム JS/CSS/HTML 圧縮

  • 従来の TLS Session Ticket Key 管理
  • 「運用の限界」をエンジニアリングで突破する
  • インフラ安定化がもたらす高い ROI
  • 従来の TLS Session Ticket Key 管理
  • 「運用の限界」をエンジニアリングで突破する
  • インフラ安定化がもたらす高い ROI

バイナリ証拠駆動の脆弱性スキャン:OpenResty XRay によるバージョン推論からの脱却

  • 従来スキャンの構造的欠陥:なぜバージョン番号は信頼できないのか
  • OpenResty XRay のアプローチ:バイナリ内部から真実を読む
  • 混在環境(Rocky Linux + OpenSSL 二重バージョン)での検証
  • 精度と運用コストのトレードオフ:導入判断のためのチェックリスト
  • 従来スキャンの構造的欠陥:なぜバージョン番号は信頼できないのか
  • OpenResty XRay のアプローチ:バイナリ内部から真実を読む
  • 混在環境(Rocky Linux + OpenSSL 二重バージョン)での検証
  • 精度と運用コストのトレードオフ:導入判断のためのチェックリスト

OpenResty XRay による D 言語製注文サービスの P99 レイテンシー異常変動の解明

  • フレームグラフから読み解くGCの罠と業務処理のホットスポット
  • 最適化ロードマップ:なぜ対策そのものより「順序」が重要なのか
  • まとめ:コードロジックから、ランタイムで起きている「真実」へ
  • フレームグラフから読み解くGCの罠と業務処理のホットスポット
  • 最適化ロードマップ:なぜ対策そのものより「順序」が重要なのか
  • まとめ:コードロジックから、ランタイムで起きている「真実」へ

コード変更・サービス再起動なし:OpenResty XRay による本番環境での動的トレーシング実践法

  • 既存の動的トレーシングフレームワークが本番環境で抱える限界と課題とは?
  • OpenResty XRay が動的トレーシングのアーキテクチャ設計で実現した技術的革新とは?
  • フルスタックフレームグラフとは何か?
  • OpenResty XRay の対応範囲はどのように継続的に広がっているか?
  • 既存の動的トレーシングフレームワークが本番環境で抱える限界と課題とは?
  • OpenResty XRay が動的トレーシングのアーキテクチャ設計で実現した技術的革新とは?
  • フルスタックフレームグラフとは何か?
  • OpenResty XRay の対応範囲はどのように継続的に広がっているか?

OpenResty Edge 徹底解説

  • OpenResty Edge が解決するビジネス課題
  • アーキテクチャ統合によるTCO最適化
  • 信頼を支える基盤
  • OpenResty Edge が解決するビジネス課題
  • アーキテクチャ統合によるTCO最適化
  • 信頼を支える基盤

OpenResty XRay 入門:コードを変更せずに、システム深層の「鼓動」を聴く

  • OpenResty XRay が実現する究極の可観測性基盤
  • シグナルからインサイトへ
  • 次世代のクラウドネイティブ・エンジニアリング
  • オープンなエコシステムと堅牢な技術基盤
  • OpenResty XRay が実現する究極の可観測性基盤
  • シグナルからインサイトへ
  • 次世代のクラウドネイティブ・エンジニアリング
  • オープンなエコシステムと堅牢な技術基盤

GSLB 設計手記:トラフィック制御を「アプリケーション層」から再考する

  • なぜ GSLB の「課題」は、いまだに解消されていないのか
  • トラフィック制御の「痛点」は本当に「設定の複雑さ」なのか
  • 「全体最適」と「障害影響の最小化」をどう両立するか
  • 受動的な応答から「フィードバックループに基づく」動的な状況把握へ
  • 「アラート対応」から「予測可能なトラフィック制御」へ
  • なぜ GSLB の「課題」は、いまだに解消されていないのか
  • トラフィック制御の「痛点」は本当に「設定の複雑さ」なのか
  • 「全体最適」と「障害影響の最小化」をどう両立するか
  • 受動的な応答から「フィードバックループに基づく」動的な状況把握へ
  • 「アラート対応」から「予測可能なトラフィック制御」へ

なぜ Kafka を API Gateway に統合するのは今でもこれほど難しいのか

  • 生産環境で頻繁に見られる 3 つの誤ったアーキテクチャパターン
  • 同期セマンティクスはブロッキング実行を意味しない
  • lua-resty-kafka-fast の設計思想
  • システムアーキテクチャにどのような変化をもたらすか
  • 生産環境で頻繁に見られる 3 つの誤ったアーキテクチャパターン
  • 同期セマンティクスはブロッキング実行を意味しない
  • lua-resty-kafka-fast の設計思想
  • システムアーキテクチャにどのような変化をもたらすか
お問い合わせ

OpenResty オープンソースコミュニティ

ぜひご参加いただき、アイデアや課題についてご意見をお聞かせください。皆様とお会いできることを心待ちにしております!


limited time offer

Request TRIAL today and receive a diagnostic REPORT
Learn more

ご意見・ご感想をお待ちしております 👋

メッセージを送信しました!

専門家チームが24時間以内にご連絡いたします。
x