OpenResty Edge FAQ：分散ゲートウェイ、CDN、WAF、ロードバランシングに関する回答

OpenResty Edge Frequently Asked Questions

🔗 OpenResty Edge インストールに関するよくあるご質問

🔗 システム要件とアーキテクチャ

🔗 OpenResty Edge にはどのような主要コンポーネントが含まれていますか？それぞれの役割は何ですか？

OpenResty Edge は主に 3 つのコアコンポーネントで構成されています：Edge Admin（管理コンソール）、Edge Log Server（ログおよびメトリクスサーバー）、および Edge Node（ゲートウェイノード）。さらに、2 つのデータストレージコンポーネントがあります：Edge Admin Database と Edge Log Server Database。

🔗 OpenResty Edge をインストールするために必要なハードウェア構成は何ですか？

本番環境には少なくとも 3 台のマシンが必要で、それぞれに Edge Admin + Admin DB、Log Server + Log Server DB、および Edge Node をインストールします。10 ノード以内のクラスターの場合、Edge Admin と Log Server には少なくとも 4 コア、16GB RAM、200GB SSD が推奨されます。Edge Node の構成はトラフィック量に依存し、通常は 1 コアに対して 2GB RAM が目安となります。

🔗 ネットワーク環境にファイアウォールの制限がある場合、どのポートとドメインを開放する必要がありますか？

openresty.com、openresty.org、pkg.openresty.com、api.openresty.com の 443 ポートをホワイトリストに追加する必要があります。コンポーネント間でも特定のポートを開放する必要があります：Edge Admin には 443 および 12345 ポートが必要で、Log Server には 12346 および 8089 ポートが必要です。

🔗 インストールプロセス

🔗 OpenResty Edge のインストールパッケージはどこから入手できますか？

OpenResty のダウンロードセンター (https://openresty.com/en/dashboard/downloads) から、オンラインインストール用の構成パッケージ (openresty-edge-VERSION.tar.gz) と完全なオフラインインストールパッケージ (openresty-edge-bundle-VERSION.tar.gz) を入手できます。

🔗 インストール後、Edge Admin 管理インターフェースのログインアカウントとパスワードをどのように取得しますか？

インストーラーの「Get Default Info」機能を使用してデフォルトのログイン情報を取得するか、テクニカルサポートにご連絡いただきパスワードのリセットを依頼してください。

🔗 インストール後、各コンポーネントが正常に動作しているかどうかを確認するにはどうすればよいですか？

systemctl status コマンドを使用して各サービスの状態を確認できます。例えば、sudo systemctl status oredge-admin などです。また、各コンポーネントのログディレクトリ（例：/usr/local/oredge-admin/logs）に異常情報がないかを確認することもできます。

🔗 設定と高可用性

🔗 Edge Admin と Log Server の可用性を向上させるにはどうすればよいですか？

2 つの Edge Admin サービスをデュアルマスターモードに設定するか、複数の Log Server インスタンスを展開することができます。Edge Admin の場合は config.ini の clone_admin 設定を変更する必要があり、Edge Node の場合は admin セクションの host2 フィールドを設定する必要があります。複数の Log Server インスタンスを使用する場合は、Edge Admin と Edge Node の両方の設定に endpoints を追加する必要があります。

🔗 データの安全性を確保するにはどうすればよいですか？データバックアップのソリューションにはどのようなものがありますか？

定期的にデータベースをバックアップすることをお勧めします。詳細については、ドキュメントのデータベースバックアップセクションをご参照ください。また、データベースクラスターを構築して自動マスター/スレーブ切り替えを実現し、データベースの可用性を向上させることも可能です。

🔗 インストール後、Edge Admin の SSL 証明書を更新するにはどうすればよいですか？

/usr/local/oredge-admin/conf/ssl/ssl.crt と /usr/local/oredge-admin/conf/ssl/ssl.key ファイルを手動で置き換えるか、インストール時に -s および -k パラメータを使用して証明書パスを指定します。あるいは、Edge Node を使用して Edge Admin のトラフィックをプロキシし、Edge Admin 用の SSL 証明書を発行することも可能です。

🔗 トラブルシューティング

🔗 Edge Node のインストール後に「not yet approved」エラーが表示された場合はどうすればよいですか？

これは正常な現象です。Edge Node が Edge Admin に正常に接続されたことを示しており、Edge Admin 管理コンソールでノードを承認する必要があります。詳細な操作方法についてはゲートウェイクラスターのドキュメントをご参照ください。

🔗 OpenResty Edge™ SDK に関するよくあるご質問

🔗 SDK を使用する際、最も重要な認証情報（アドレス、ポート、ユーザー名、パスワード）はどこから取得しますか？

これらの情報は、Edge Admin Web コンソールにログインする際の情報と完全に一致します。Edge2Client の初期化に必要なパラメータは、バックエンドのアクセスアドレスとログイン認証情報です。Admin が標準以外の HTTPS ポートを使用している場合は、アドレスにポート番号を明示的に指定してください。

🔗 開発環境で自己署名証明書を使用しており、SDK 接続時に SSL エラーが発生します。どのように対処しますか？

これは非常によくあるケースです。client.login() を呼び出す前に client.set_ssl_verify(False) を実行するだけで証明書検証をスキップできます。ただし、本番環境では、信頼できる認証局（CA）によって発行された有効な証明書を設定することを強くお勧めします。

🔗 API を呼び出して設定を変更しましたが、反映されません。正しいリリースプロセスはどのようなものですか？

SDK のすべての設定変更はトランザクション形式であり、自動的に公開されることはありません。これは、誤操作がオンラインサービスに影響を与えるのを防ぐための安全設計です。正しいプロセスは「変更 -> 公開 -> 検証」の流れになります：

  1. 変更：new_rule(), put_app() などのインターフェースを呼び出して変更を実行します。
  2. 公開：client.new_release() を呼び出して、すべての保留中の変更を新しいバージョンとして作成し、有効にします。
  3. 検証：（オプションですが推奨）client.sync_status() を呼び出して、設定がすべてのノードに同期されているかどうかを確認します。

🔗 SDK を使用して自動化操作（ルールの一括更新、IP リストなど）を行う際のベストプラクティスは何ですか？

  1. 冪等性：作成操作を実行する前に、対象が既に存在するかどうかを確認し、重複作成を避けます。更新を実行する際は、スクリプトが繰り返し実行できることを確認します。
  2. 堅牢性：すべての API 呼び出しの外層で try...except を使用して例外をキャッチし、詳細なログを記録します。
  3. パフォーマンス考慮：大規模な一括操作（例：一度に数千の IP を更新する場合）では、データをバッチ処理し、バッチ間に短い遅延（例：1 秒）を追加して、リクエスト頻度が高すぎて Admin の保護機能が作動しないようにすることをお勧めします。

🔗 SDK を CI/CD パイプライン（Jenkins、GitLab CI など）に統合して、コードとしての構成（Configuration as Code）を実現するにはどうすればよいですか？

これは SDK の最も価値のあるアプリケーションシナリオの一つです。一般的なアプローチは次のとおりです：

  1. コード化された構成：Edge アプリケーションの構成（アップストリーム、ルールなど）を特定の形式（YAML、JSON など）でコードリポジトリに保存します。
  2. 同期スクリプトの作成：コード化された構成ファイルを読み取り、SDK インターフェースを呼び出して構成を Edge Admin に適用する Python スクリプトを開発します。
  3. CI/CD への統合：CI/CD パイプラインにステージを追加し、構成コードが変更されたときに自動的に Python スクリプトを実行して、Edge への構成変更とリリースを完了します。
  4. 認証情報管理：Edge Admin にログインするための高権限パスワードを CI/CD システムのシークレット管理ツールに保存し、スクリプトに安全に渡して、平文での保存を避けます。

🔗 OpenResty Edge 動的メトリクスに関するよくあるご質問

🔗 「動的メトリクス」機能の主な価値は何ですか？どのようなシナリオで使用すべきですか？

その主な価値は、標準のダッシュボードでは得られない、深くカスタマイズされたビジネスおよびセキュリティの洞察を提供することです。次のようなシナリオで使用することをお勧めします：

🔗 クエリを作成する前に、利用可能なデータテーブルとフィールドを知るにはどうすればよいですか？データディクショナリはありますか？

これは最も重要な最初のステップです。利用できる主なデータソースは reqs（リクエストログ）と waf_hits（WAF ログ）という 2 つの仮想テーブルです。これらに含まれる正確な利用可能なフィールド（例：client_ip、status、uri、resp_header('Content-Type') など）を知るための最も信頼できる方法は、OpenResty Edge 公式ドキュメントの動的メトリクスセクションをご参照ください。

🔗 ビジネスメトリクスを集計したいのですが、例えば「JWT の user_id フィールドに基づいてリクエスト量が最も多い Top 10 のユーザーを特定する」ことは可能ですか？

はい、これは動的メトリクスの強みです。user_id が X-Jwt-Claim-User-Id というリクエストヘッダーにあると仮定すると、クエリは次のように記述できます：

-- user_idがリクエストヘッダー'X-Jwt-Claim-User-Id'にあると仮定
SELECT ngx_var('http_x_jwt_claim_user_id') as user_id, count(*) as count
FROM reqs
WHERE ngx_var('http_x_jwt_claim_user_id') != ''
GROUP BY user_id
ORDER BY count DESC
LIMIT 10;

重要なポイントは、ngx_var() 関数を利用してカスタムリクエストヘッダー（http_ プレフィックス付き）や他の Nginx 変数を取得し、ビジネスロジックとログデータを関連付けることです。

🔗 動的メトリクスのクエリはどこで実行されますか？オンラインゲートウェイのパフォーマンスに影響しますか？

これは非常に重要なセキュリティに関する質問です。動的メトリクスのクエリは、Edge Log Server（ログサーバー）上で実行され、ゲートウェイノードから副次的に収集されたログデータを処理します。そのため、クエリがどれだけ複雑であっても、リアルタイムのビジネストラフィックを処理する Edge Node（ゲートウェイノード）のパフォーマンスには影響を与えません。この機能を安心して使用し、複雑なデータ分析を行うことができます。

🔗 OpenResty Edge Edgelang に関するよくあるご質問

🔗 標準のページルール UI ではなく、どのようなシナリオで Edgelang を使用すべきですか？

これは最も重要な判断ポイントです。標準の UI ルールでは対応できない、複雑で動的、または極めて高いパフォーマンスが要求されるシナリオで Edgelang の使用を検討すべきです。

🔗 Edgelang の最も強力な応用シナリオは何ですか？例を挙げていただけますか？

Edgelang の最も強力な特長は、リクエストとレスポンスに対する高度なプログラミングと制御能力です。最も代表的な「キラー」アプリケーションシナリオは、A/B テストとカナリアリリース（段階的リリース）です。

例：ユーザー ID に基づくカナリアリリースの実装 ユーザー ID が「7」で終わるユーザーに新しいアップストリームサービス new-backend-upstream へのアクセスを許可し、他のユーザーには旧バージョンを提供したいとします。

# ルール：カナリアリリース
# リクエストのCookieにuseridが含まれ、useridが'7'で終わる場合
req-cookie("userid"), req-cookie("userid") suffix "7" =>
  set-upstream-name("new-backend-upstream");

このロジックは標準の UI ルールでも実装可能ですが、Edgelang を使用するとより簡潔で効率的になります。

🔗 Edgelang コードを作成した後、どのようにデプロイして実行しますか？

Edgelang コードは独立してデプロイされるのではなく、ページルールのアクションとして実行されます。プロセスは次のとおりです：

  1. コードの作成：コードエディタで Edgelang ルールを作成します。
  2. ページルールの作成：Edge Admin のアプリケーション下で新しいページルールを作成します。
  3. 条件の設定：（オプション）Edgelang を実行したいリクエストのトリガー条件を設定します。例えば、「URI パスのプレフィックスが /api/ である」など。
  4. アクションの選択：ルールの「アクション」セクションで「Edgelang を実行」を選択します。
  5. コードの貼り付け：作成した Edgelang コードをアクション入力ボックスに貼り付けます。
  6. 保存と公開：このページルールを保存して公開します。

その後、設定した条件に一致するリクエストがあると、埋め込まれた Edgelang コードが実行されます。

🔗 Edgelang の実行順序はどのようになっていますか？WAF やキャッシュなどの他のルールとどのように連携しますか？

ページルールの一部として、Edgelang の実行は Nginx の処理フェーズとページルールの優先順位に従います。簡略化されたリクエスト処理フローは次のとおりです：

  1. ページルール（Edgelang または WAF を含む）：リクエストはページルールの処理ロジックに入ります。この時点で、Edgelang または WAF を含むルールは、その優先順位（UI でドラッグして並べ替え可能）とトリガー条件に従って実行されます。
  2. キャッシュ：Edgelang は後続の動作を制御できます。例えば、Edgelang ルールで enable-proxy-cache() アクションを呼び出して、特定のリクエストに対してキャッシュを有効にするかどうかを決定できます。

🔗 Edgelang のパフォーマンスとセキュリティはどのようになっていますか？問題のあるコードを書いた場合はどうすればよいですか？

お問い合わせ