このトピックでは、Cloud Foundryでのルートとドメインの動作、および開発者と管理者がCloud Foundryコマンドラインインターフェイス（CLI）を使用してアプリケーションのルートとドメインを構成する方法について説明します。

Cloud Foundry のルーティング機能に関する詳しい説明は、HTTP Routeing トピックを参照ください。

注意事項: この記事は、Cloud Foundry Documentaion Routes and Domains (last updated: June 22, 2017) の独自の翻訳とコメントです。内容を保証するものではありません。

セッション・アフィニティ

gorouterは、互換性のあるアプリケーションへの着信HTTP要求に対して、セッション・アフィニティまたはスティッキ・セッションをサポートします。

スティッキ・セッションでは、CF上で複数のアプリケーション・インスタンスが実行されている場合、特定のクライアントからの要求は常に同じアプリケーション・インスタンスに届きます。これにより、アプリケーションはユーザーセッションに固有のセッションデータを保存することができます。

スティッキ・セッションをサポートするには、応答で JSESSIONID Cookie を返すようにアプリを設定します。このアプリケーションは JSESSIONID を次の形式の長いハッシュとして生成します。

1A530637289A03B07199A44E8D531427

アプリケーションが JSESSIONID クッキーをクライアント要求に返すと、CFルーティング層は、そのGUIDに基づいて、次の形式でアプリインスタンスの一意のVCAP_IDを生成します。

323f211e-fea3-4161-9bd1-615392327913

その後の要求では、クライアントは JSESSIONID と VCAP_ID の両方のCookieを提供する必要があります。

CFルーティング層は VCAP_ID クッキーを使用して、毎回同じアプリインスタンスにクライアント要求を転送します。 JSESSIONID Cookieは、セッションの連続性を有効にするためにappインスタンスに転送されます。 VCAP_IDで識別されるアプリインスタンスがクラッシュした場合、gorouterは要求をアプリの別のインスタンスにルーティングしようとします。 Gorouterがアプリケーションの健全なインスタンスを検出すると、新しいスティッキセッションが開始されます。

注：CFは、アプリケーションインスタンス間でHTTPセッションデータを永続化または複製しません。アプリインスタンスがクラッシュまたは停止した場合、そのインスタンスのセッションデータは失われます。クラッシュまたは停止したインスタンス間でセッションデータを保持する必要がある場合や、アプリケーションのすべてのインスタンスで共有する必要がある場合は、データ永続性を提供するCFマーケットプレイスサービスにセッションデータを保存します。

HTTPヘッダー

Gorouterからアプリに渡されるHTTPトラフィックには、次のHTTPヘッダーが含まれます。

X-Forwarded-Proto は、クライアントからのHTTP要求のスキームを提供します。このスキームは、クライアントが安全でない要求を出した場合はHTTP、クライアントがセキュアな要求を行った場合はHTTPSです。開発者は、着信トラフィックのHTTPヘッダーを検査し、X-Forwarded-Proto を含むトラフィックをHTTPのスキームで拒否することで、安全でない要求を拒否するようにアプリケーションを構成できます。
X-Forwarded-For は、要求を送信したクライアントのIPアドレスを返します。

ロードバランサが gorouterからTLS上流を終了する場合、Gorouterに転送された要求にこれらのヘッダーを追加する必要があります。詳細については、「クラウドファウンドリへのトラフィックの保護」を参照してください。

HTTPヘッダーでのZipkinトレース

Zipkinは、アプリケーション開発者が障害や待ち時間の問題のトラブルシューティングを可能にするトレースシステムです。 Zipkinは、分散システム全体で要求と応答をトレースする機能を提供します。詳細については、Zipkin.ioを参照してください。

Cloud FoundryでZipkin機能が有効になっている場合、GorouterはHTTPリクエストヘッダーを調べ、次の処理を実行します。

要求に X-B3-TraceId および X-B3-SpanId HTTPヘッダーが存在しない場合、Gorouterはこれらの値を生成し、ヘッダーをアプリケーションに転送された要求に挿入します。これらの値は、要求のGorouterアクセスログメッセージ（x_b3_traceid および x_b3_spanid）にもあります。
要求にX-B3-TraceId と X-B3-SpanId HTTPヘッダーの両方が存在する場合、GorouterはX-B3-TraceIdと同じ値を転送し、X-B3-SpanIdの新しい値を生成し、 B3-ParentSpanヘッダーを返し、要求内のスパンIDの値を設定します。これらのトレースおよびスパンIDに加えて、要求のGorouterアクセスログメッセージにはx_b3_parentspanidが含まれています。

開発者は、ZipkinのトレースIDをアプリケーションログに追加して、Cloud Foundryでアプリのリクエストと応答をトレースできます。

アプリケーションログにZipkin HTTPヘッダーを追加した後、開発者はcf logs myappを使用して、Gorouterによって記録されたトレースとスパンIDを、アプリケーションによって記録されたトレースIDと相関させることができます。要求のトレースIDを複数のアプリケーションで相互に関連付けるには、各アプリケーションが、要求とともにヘッダーに適切な値を他のアプリケーションに転送する必要があります。

HTTPヘッダーでのアプリケーションインスタンスルーティング

アプリケーションの特定のインスタンスのデバッグデータを取得したい開発者は、HTTPヘッダ X-CF-APP-INSTANCE を使用してアプリケーションインスタンスに要求を行うことができます。

特定のアプリケーションインスタンスへのHTTPリクエストを作成するには、次の手順を実行します。

あなたのアプリのGUIDを取得する：

$ cf app YOUR-APP --guid

アプリケーションインスタンスをリストし、デバッグするインスタンスのインデックス番号を取得します。

$ cf app YOUR-APP

アプリケーションのGUIDとインスタンスインデックスを連結した値に設定されたHTTPヘッダー X-CF-APP-INSTANCE を使用して、アプリケーションルートにリクエストを行います。

$ curl app.example.com -H "X-CF-APP-INSTANCE":"YOUR-APP-GUID:YOUR-INSTANCE-INDEX"

SSL / TLS ターミネーション

必要に応じて、Gorouter、ロードバランサ、またはロードバランサでSSL / TLSをターミネーションするようにデプロイメントを設定できます。詳細については、「Cloud Foundryへのトラフィックの保護」を参照してください。

透過的な再試行

Gorouterが選択されたアプリケーション・インスタンスとのTCP接続を確立できない場合、Gorouterはそのインスタンスを30秒間要求の対象外と見なし、Gorouterは透過的に別のアプリケーション・インスタンスに接続しようとします。 Gorouterがアプリケーション・インスタンスとのTCP接続を確立すると、GorouterはHTTP要求を転送します。

Gorouterが要求をアプリケーション・インスタンスに転送する方法の詳細については、以下のラウンドロビン・ロードバランシングのセクションを参照してください。

ラウンドロビン負荷分散

Gorouterは、着信要求をアプリケーション・インスタンスにロード・バランシングするためにラウンドロビン・アルゴリズムを使用します。 Gorouterは、各ルートのアプリケーション・インスタンスの動的に更新されたリストを保持し、指定されたルートの各要求をリスト内の次のアプリケーション・インスタンスに転送します。

WebSockets

WebSocketsは、Webクライアントとサーバーによって一般的に実装される単一の長期間のTCP接続で双方向通信を提供するプロトコルです。 WebSocketは、HTTP経由でアップグレード要求として開始されます。 Gorouterはこのアップグレード・ハンドシェイクをサポートし、選択したアプリケーションインスタンスでTCP接続を開いたままにします。 WebSocketをサポートするには、オペレータはロードバランサを正しく設定する必要があります。構成によっては、クライアントはWebSocket接続（ポート4443など）や別のドメイン名で別のポートを使用する必要があります。詳細については、「WebSocketのサポート」トピックを参照してください。

キープアライブ接続

フロントエンド・クライアントから

Gorouterは、クライアントからのキープアライブ接続をサポートします。 HTTP応答を返した直後にクライアントとのTCP接続を終了しません。これらの接続を閉じるのはクライアントの責任です。

バックエンドサーバー

デフォルトでは、GorouterはHTTPレスポンスを受け取った後、アプリケーション・インスタンスまたはシステムコンポーネントとのTCP接続を閉じます。

キープアライブ接続を有効にすると、Gorouterはバックエンドとの確立されたTCP接続を維持し、各Gorouterからの合計アイドル接続数を制限する設定可能な最大値を維持します。 Gorouterは、選択されたバックエンドに対して存在する場合、後続の要求のルーティングにアイドル接続を再利用し、遅延を低減し、スループットを向上させます。アイドル接続が存在しない場合、新しい接続が確立され、Gorouterの制限に達していない場合、その接続は維持されます。各Gorouterから個々のバックエンドへのアイドル接続の数は100に制限されています。オペレータは、詳細については、ルータアイドルキープアライブ接続を参照する必要があります。