Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報
Google では、2015 年 8 月から 9 月にかけて、Apigee Edge のクラウド ルーターとロードバランサを NGINX（「エンジン X」と発音）に移行します。オープンソースのウェブサーバーである NGINX は、既存のロードバランサやルーターよりもパフォーマンスと同時実行性に優れています。
Google Cloud のお客様への影響
つまり、この変更は透過的であり、システムが想定どおり動作していることを確認する以外、お客様による操作は必要ありません。以下に、Google が実施する手順と、よくある質問への回答を示します。
ステップ 1 - ソフトウェア アップデート
Google の段階的なデプロイモデルを活用して、すべてのルーターを新しい NGINX ベースのルーターにアップグレードし、このアクティビティによるサービスへの影響を防ぎます。
ステップ 2 - 非本番環境でロードバランサの階層を削除する
ロード バランシング機能を処理する新しい NGINX ルーターでは、まず非本番環境で既存のロードバランサ階層を削除するプロセスを開始します。 本番環境のロードバランサは、このステップ中、そのまま維持されます。Google では、既存のロードバランサを削除する前に、トラフィックが想定どおりに動作していることを徹底するためのアプローチを取ります。このステップに必要なご対応は特にありません。ただし、問題が発生した場合は Apigee に報告してください。ステップ 3 に進む前に、Google が問題の解決をお手伝いします。
ステップ 3 - 本番環境でロードバランサのティアを削除する
ステップ 2 が正常に完了したら、ランタイム API トラフィックが引き続き想定どおりに機能するように、ステップ 2 で説明したのと同じ方法を使用して、本番環境でロードバランサ階層を削除するための一連のメンテナンス時間枠を決定します。
サービスの機能の変更
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 の移行に関するよくある質問とその回答を紹介します。
ステップ 1 の回答は「いいえ」です。既存のロードバランサにはアクセスしておらず、トラフィックを処理する IP は直接変更されません。ただし、アマゾン ウェブ サービス（AWS）ロード バランシング サービスの性質上、通常のスケーリング ルールが適用されます。つまり、IP がそのスケーリング ロジック（既存の機能）の一部として変更される可能性があります。このため、Apigee Edge プロダクト スイートでノースバウンド許可リスト構成を実装することはおすすめしません。ステップ 2 と 3 では、ロードバランサとそれに関連付けられた IP アドレスの削除に伴う許可リストの影響があります。そこで Google は、移行がスムーズに行われるように、アクセスを許可する新しい IP アドレスのセットをご提供するなど、お客様との緊密な連携を図ります。
送信元サーバーがターゲット エンドポイント サーバー（プロキシ バンドルから呼び出されるサーバー）である場合、変更は必要ありません。この変更は、Apigee のノースバウンド側または Apigee への上り（内向き）ポイントで行われます。
いいえ。既存の CNAME エントリは引き続き正常に機能します。
SSL を使用している場合、この最初のステップは既存の SSL 構成には影響しません。ただし、ステップ 2 と 3 に進む前に、お客様と緊密に連携して新しいルーターで SSL を適切に設定する必要があります。
ステップ 2 と 3 は、SNI のサポートが確認されるまで遅延します。
ダウンタイムは発生しません。変更は、既存のリリース期間中に標準のデプロイモデルを使用して実装されます。