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