OpenResty 1.29.2.4 正式版リリース
- 主な変更点
- 完全な変更履歴
- 主な変更点
- 完全な変更履歴
精选文章
OpenResty XRay で、パフォーマンスを大幅に向上し、CPU使用率を即座に削減
90%
OpenResty XRay で、パフォーマンスを大幅に向上し、CPU使用率を即座に削減 90%
最新記事
OpenResty XRay バージョン 26.5.11 正式リリース
- 主なハイライト
- その他の重要な更新
- 主なハイライト
- その他の重要な更新
OpenResty Edge バージョン 26.6.8 を正式リリース
- 主な強化点
- 機能強化と柔軟性の向上
- 使いやすさと可観測性の最適化
- 重要な修正と安定性の強化
- 主な強化点
- 機能強化と柔軟性の向上
- 使いやすさと可観測性の最適化
- 重要な修正と安定性の強化
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層アップストリームシステムの設計思想
YAML ファイルで OpenResty Edge を設定する：`edge2yaml` によるエクスポート・インポート入門
edge2yamlとは- 主なユースケース
edge2yamlと OpenResty Edge Admin のネイティブ機能との関係
edge2yamlとは- 主なユースケース
edge2yamlと OpenResty Edge Admin のネイティブ機能との関係
OpenResty サービスにおける「見えないボトルネック」としての JSON
- パフォーマンスの限界はどのレイヤーにあるのか
- 一般的な「回避策」とその限界
- なぜ「独自開発」や「独自カスタマイズ」は得策ではないのか
- インフラストラクチャレベルの最適化：
jit.cjson - なぜ公式（ベンダー）提供のソリューションが最適なのか
- 極めて低い導入コスト
- パフォーマンスの限界はどのレイヤーにあるのか
- 一般的な「回避策」とその限界
- なぜ「独自開発」や「独自カスタマイズ」は得策ではないのか
- インフラストラクチャレベルの最適化：
jit.cjson - なぜ公式（ベンダー）提供のソリューションが最適なのか
- 極めて低い導入コスト
ビルド不要・Nginx ゲートウェイだけで実現する 120 MB/s のリアルタイム JS/CSS/HTML 圧縮
- 従来の TLS Session Ticket Key 管理
- 「運用の限界」をエンジニアリングで突破する
- インフラ安定化がもたらす高い ROI
- 従来の TLS Session Ticket Key 管理
- 「運用の限界」をエンジニアリングで突破する
- インフラ安定化がもたらす高い ROI
OpenResty 1.29.2.3 正式リリース
- 主な変更点
- 完全な変更ログ
- フィードバック
- 主な変更点
- 完全な変更ログ
- フィードバック
バイナリ証拠駆動の脆弱性スキャン：OpenResty XRay によるバージョン推論からの脱却
- 従来スキャンの構造的欠陥：なぜバージョン番号は信頼できないのか
- OpenResty XRay のアプローチ：バイナリ内部から真実を読む
- 混在環境（Rocky Linux + OpenSSL 二重バージョン）での検証
- 精度と運用コストのトレードオフ：導入判断のためのチェックリスト
- 従来スキャンの構造的欠陥：なぜバージョン番号は信頼できないのか
- OpenResty XRay のアプローチ：バイナリ内部から真実を読む
- 混在環境（Rocky Linux + OpenSSL 二重バージョン）での検証
- 精度と運用コストのトレードオフ：導入判断のためのチェックリスト
OpenResty XRay による D 言語製注文サービスの P99 レイテンシー異常変動の解明
- フレームグラフから読み解くGCの罠と業務処理のホットスポット
- 最適化ロードマップ：なぜ対策そのものより「順序」が重要なのか
- まとめ：コードロジックから、ランタイムで起きている「真実」へ
- フレームグラフから読み解くGCの罠と業務処理のホットスポット
- 最適化ロードマップ：なぜ対策そのものより「順序」が重要なのか
- まとめ：コードロジックから、ランタイムで起きている「真実」へ
OpenResty XRay バージョン 26.2.1 正式リリース
- 主なハイライト
- 安定性と使いやすさの最適化
- 主なハイライト
- 安定性と使いやすさの最適化
OpenResty Edge クライアント実 IP フルチェーン転送ガイド
- OpenResty Edge が解決するビジネス課題
- アーキテクチャ統合によるTCO最適化
- 信頼を支える基盤
- OpenResty Edge が解決するビジネス課題
- アーキテクチャ統合によるTCO最適化
- 信頼を支える基盤
OpenResty 1.29.2.1 正式リリース
- 主な変更点
- 完全な変更ログ
- フィードバック
- 主な変更点
- 完全な変更ログ
- フィードバック
コード変更・サービス再起動なし：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の設計思想- システムアーキテクチャにどのような変化をもたらすか
