Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご覧ください。 info
2015 年 8 月から 9 月にかけて、Apigee Edge クラウド ルーターとロードバランサを NGINX（「エンジン エックス」と発音）に移行します。オープンソースのウェブサーバーである NGINX は、既存のロードバランサやルーターよりもパフォーマンスと同時実行性が優れています。
クラウドのお客様への影響
この変更はユーザーにとって透過的であり、システムが想定どおりに動作していることを確認する以外に、ユーザー側で必要な対応はありません。以下に、実施する手順の説明と、よくある質問への回答を示します。
ステップ 1 - ソフトウェアの更新
このアクティビティの結果としてサービスが影響を受けないように、段階的デプロイ モデルを活用して、すべてのルーターを新しい NGINX ベースのルーターにアップグレードします。
ステップ 2 - 非本番環境でロードバランサ階層を削除する
新しい NGINX ルーターがロード バランシング機能を処理するため、まず非本番環境で既存のロードバランサ階層を削除するプロセスを開始します。このステップでは、本番環境のロードバランサはそのまま変更されません。既存のロードバランサを削除する前に、トラフィックが想定どおりに動作していることを確認するための徹底的なアプローチを行います。この手順を完了するために、お客様側で必要な対応はございません。ただし、問題が発生した場合は Apigee に報告する必要があります。Google は、手順 3 に進む前に、お客様と協力して問題を解決します。
ステップ 3 - 本番環境でロードバランサ階層を削除する
ステップ 2 が正常に完了すると、ステップ 2 で説明したのと同じアプローチを使用して、本番環境のロードバランサ階層を削除するためのメンテナンス ウィンドウのセットが決定され、ランタイム API トラフィックが引き続き想定どおりに動作することが保証されます。
プロダクトの機能の変更
NGINX への切り替えに伴うプロダクトの機能の変更点は次のとおりです。
非推奨
ProxyEndpoint では、次のプロパティはサポートされなくなりました。
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
この非推奨を回避するには、コミュニティ記事の Proxy Endpoint HTTP allow method properties not working をご覧ください。
よくある質問
以下に、NGINX の移行に関するよくある質問とその回答を示します。
ステップ 1 では、既存のロードバランサには触れないため、トラフィックを処理する IP が直接変更されることはありません。したがって、答えは「いいえ」です。ただし、Amazon Web Services（AWS）ロード バランシング サービスの性質上、通常のスケーリング ルールが適用されます。つまり、スケーリング ロジック（既存の機能）の一部として IP が変更される可能性があります。そのため、Apigee Edge プロダクト スイートで Northbound の許可リスト構成を実装することはおすすめしません。手順 2 と 3 では、ロードバランサとその関連 IP アドレスを削除すると、許可リストに影響します。そのため、これらの手順では、アクセスを許可する新しい IP アドレスのセットを提供することで、スムーズな移行を確保するために、お客様と緊密に連携します。
オリジン サーバーがターゲット エンドポイント サーバー（プロキシ バンドルから呼び出されるサーバー）である場合、変更は必要ありません。この変更は、Apigee のノースバウンド側、つまり Apigee への上り（内向き）ポイントで行われます。
いいえ。既存の CNAME エントリは引き続き正常に機能します。
SSL を使用している場合、最初のステップは既存の SSL 構成に影響しません。ただし、ステップ 2 と 3 に進む前に、新しいルーターで SSL が正しく設定されていることを確認するため、お客様と緊密に連携する必要があります。
手順 2 と 3 は、SNI のサポートが確認されるまで遅延します。
ダウンタイムは想定していません。変更は、既存のリリース期間中に標準のデプロイモデルを使用して実装されます。