NGINX のルーターとロードバランサへの移行

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動
情報

2015 年 8 月と 9 月、Google は Apigee Edge クラウド ルーターとロードバランサを NGINX(「Engine X」と発音)に移行します。オープンソースのウェブサーバーである NGINX は、既存のロードバランサやルーターよりも優れたパフォーマンスと高い同時実行性を実現します。

クラウドをご利用のお客様への影響

要するに、この変更はお客様にとって透明性があり、システムが想定どおりに動作していることを確認する以外に、お客様側で行う必要がある操作はありません。以下に、Google が講じている措置の説明と、よくある質問への回答をご紹介します。

ステップ 1 - ソフトウェアの更新

すべてのルーターを新しい NGINX ベースのルーターにアップグレードします。この作業は段階的なデプロイモデルを利用して行われるため、サービスが影響を受けないようにします。

ステップ 2 - 本番環境以外の環境でロードバランサ階層を削除する

新しい NGINX ルーターでロード バランシング機能を処理するため、まず非本番環境で既存のロードバランサ階層を削除するプロセスを開始します。このステップでは、本番環境のロードバランサはそのまま変更されません。既存のロードバランサを削除する前に、トラフィックが期待どおりに動作することを確認するための徹底的なアプローチを実施します。この手順を完了するために、お客様側で特別な対応をしていただく必要はありません。ただし、問題がある場合は Apigee に報告する必要があります。Google は、ステップ 3 に進む前に、問題の解決をサポートします。

ステップ 3 - 本番環境でロードバランサ ティアを削除する

ステップ 2 が正常に完了すると、Google は、ステップ 2 で説明したアプローチを使用して、本番環境のロードバランサ階層を削除するためのメンテナンス ウィンドウを決定し、ランタイム API トラフィックが引き続き想定どおりに機能するようにします。

サービスの機能の変更

NGINX への切り替えに伴うプロダクトの機能の変更は次のとおりです。

非推奨

ProxyEndpoints では、次のプロパティはサポートされなくなりました。

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

この非推奨を回避するには、次のコミュニティ記事(https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html)をご覧ください。

よくある質問

NGINX の移行に関するよくある質問とその回答を以下に示します。

パブリック IP が変更される可能性はありますか?一部の販売者は、既知の IP からのアクセスを明示的に許可しており、変更すると販売者のフローが中断します。
ステップ 1 では、既存のロードバランサに変更を加えないため、トラフィックを処理する IP が直接変更されることはありません。したがって、答えは「いいえ」です。ただし、アマゾン ウェブ サービス(AWS)ロード バランシング サービスの性質上、通常のスケーリング ルールが適用されます。つまり、スケーリング ロジック(既存の機能)の一部として IP が変更される可能性があります。そのため、Apigee Edge プロダクト スイートを使用してノースバウンド許可リスト構成を実装することはおすすめしません。手順 2 と 3 では、ロードバランサとそれに関連付けられた IP アドレスの削除に許可リストの影響があります。そのため、Google はこれらの手順においてお客様と緊密に連携し、アクセスを許可する新しい IP アドレスのセットを提供することによって、スムーズな移行を実現します。
この変更は、オリジン サーバーで設定されている IP 制限に影響しますか?
送信元サーバーがターゲット エンドポイント サーバー(プロキシ バンドルから呼び出されるサーバー)である場合、変更は必要ありません。この変更は、Apigee のノースバウンド側、または Apigee への上り(内向き)ポイントで行われます。
既存の CNAME を変更する必要がありますか?
いいえ。既存の CNAME エントリは引き続き正常に機能します。
SSL 証明書の移行は手間がかかります。どのように対処する予定ですか?
SSL を使用している場合、最初のステップは既存の SSL 構成に影響しません。ただし、ステップ 2 と 3 に進む前に、新しいルーターで SSL が正しく設定されていることを確認するため、お客様と緊密に連携する必要があります。
アプリやクライアントが SNI に対応していない場合はどうなりますか?
手順 2 と 3 は、SNI のサポートが確認されるまで延期されます。
ダウンタイムは発生しますか?
ダウンタイムは発生しない予定です。変更は、既存のリリース期間中に Google の標準デプロイ モデルを使用して実装されます。