tencent cloud

Tencent Cloud EdgeOne

EdgeOneによるクライアントIPアドレスベースのセッション維持の実現

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-16 10:46:25
AI翻訳
このドキュメントの学習には約10分かかります。このドキュメントを学習することで、以下を理解できます:
1. クライアントIPアドレスに基づくセッション維持とは何か、またなぜ必要なのかについて説明します。
2. クライアントIPアドレスに基づくセッション維持の適用シナリオ。
3. クライアントIPアドレスに基づく技術アーキテクチャおよび原理の説明。
4. EdgeOneエッジ関数とルールエンジンを使用してクライアントIPアドレスに基づくセッション維持を実現する具体的な手順。

背景紹介

インターネットの急速な発展に伴い、企業ビジネスは継続的に拡大し、ユーザー体験を深めています。単一のオリジンサーバーでは、大量の同時リクエストを処理するニーズを徐々に満たせなくなっています。サービスの可用性と拡張性を向上させるため、企業はCLB技術を採用し始め、ユーザーリクエストを複数のバックエンドオリジンサーバーに分散して処理しています。しかし、ビジネス発展の初期段階では、ユーザー数が比較的少なく、セッション管理も比較的シンプルなため、通常はクライアントIPアドレスに基づくセッション維持の問題に直面することはありません。ですが、ビジネスがさらに発展するにつれて、特に以下のシナリオでは、クライアントIPアドレスに基づくセッション維持のニーズが特に切実になります:
ユーザーログイン状態の維持:ユーザーログインが必要な一部のアプリケーション、例えば電子商取引サイトやオンラインバンキングなどでは、ユーザーがログインした後、オリジンサーバー上でセッション(Session)が生成され、ユーザーのログイン状態、ショッピングカート情報、注文詳細などを記録します。もしユーザーが閲覧中に異なるバックエンドオリジンサーバーに割り当てられた場合、セッション情報の消失により再ログインが必要になる可能性があり、ユーザー体験に深刻な影響を与えます。
データ整合性の要求が高いビジネス:金融取引やオンライン決済など、データ整合性に極めて高い要求があるビジネスでは、セッションが異なるオリジンサーバーに割り当てられた場合、データの不整合や消失が発生する可能性があり、ユーザーと企業に深刻な損失をもたらします。
EdgeOneは上記の背景を踏まえ、クライアントIPアドレスに基づくセッション維持を提供します。これは、EdgeOneのエッジ関数とルールエンジンにより、同一クライアントIPアドレスからのリクエストが常に同一のバックエンドオリジンサーバーへ転送されることを実現し、セッションの継続性とデータの一貫性を維持します。

適用シーン

クライアントのIPアドレスを識別することにより、同じクライアントからのリクエストが同じオリジンサーバーへ振り向けられることを確保します。以下のビジネスシナリオに適用されます:
金融サービス:オンラインバンキング、株式取引などのアプリケーションでは、ユーザーが取引プロセス全体においてすべてのリクエストを同一のオリジンサーバーで処理することを確保し、取引の安全性と一貫性を維持する必要があります。
電子商取引サイト:ユーザーがログインした後、そのすべてのリクエストが同一のオリジンサーバーへルーティングされることを確保し、ショッピングカート情報、ユーザー設定、ログイン状態を維持します。

技術アーキテクチャ


クライアントIPアドレスに基づくセッション維持の具体的な原理は、エッジ関数がクライアントのIPアドレス(上の図のIP:192.168.1.108)に基づき、ハッシュアルゴリズムによってクライアントを異なるオリジンサーバーにマッピングします。ルールエンジンはエッジ関数でカスタマイズされたオリジンリクエストヘッダーを取得し、リクエストヘッダーの値に基づいて、同じクライアントが常に同じオリジンサーバーへオリジン要求を行うことを実現します。これにより、クライアントから特定のオリジンサーバーへの一貫性を実現します。このソリューションはユーザー体験を向上させるだけでなく、ビジネスデータの正確性も確保できます。

プリセットシナリオ

あなたがグローバルアプリケーションサービスの技術責任者であり、サイトドメイン example.com をEdgeOneに接続していると仮定します。ユーザーのIPアドレスのハッシュ値に基づいて、リクエストを常に対応するオリジンサーバーへルーティングすることを期待します。ユーザーがどこにいても、同じユーザーのリクエストが常に同じオリジンサーバーへルーティングされることを確保し、キャッシュ効率の最適化、セッション管理の簡素化、CLBの実現、パーソナライズされたサービスの提供に役立ち、データ処理の法令遵守を確保します。
このシナリオでは、あなたは数百万の異なるユーザーに対応しています。これらのユーザーのリクエストは、中国本土のオリジンサーバーとシンガポールのオリジンサーバーに均等に分散される必要があります。同時に、同じIPアドレスからのリクエストが常に同じオリジンサーバーへルーティングされることを期待します。これにより、一貫性のあるユーザー体験と効率的なリソース利用を実現します。この例では、中国本土のオリジンサーバーへ転送する必要があるIPに対して、エッジ関数を通じてオリジンリクエストヘッダーを追加します:X-Forwarded-For-Origin:originGroup1。シンガポールのオリジンサーバーへ転送する必要があるIPに対して、エッジ関数を通じてオリジンリクエストヘッダーを追加します:X-Forwarded-For-Origin:originGroup2。

操作手順

ステップ1:EdgeOneへの接続

ゼロからEdgeOneへの迅速な接続開始を参照して、サイト接続とドメイン接続を完了します。

ステップ2:エッジ関数の作成と設定

1. EdgeOneコンソールにログインし、左側のメニューバーで「サービス概要」に入り、「Webサイト安全な加速」内で設定が必要なサイトをクリックします。
2. 左側のナビゲーションバーで、エッジ関数 > 関数管理をクリックします。
3. 関数管理ページで、新規関数をクリックします。
4. テンプレートを選択して作成するページで、Hello Worldを作成を選択した後、次へをクリックします。
5. 新しい関数を作成するページで、関数名、関数の説明、関数コードを入力します。以下はクライアントIPアドレスに基づくセッション維持のサンプルコードです:
// クライアントIPアドレスに基づいて、異なるオリジンサーバーグループへ戻ります。つまり、IPアドレスが変わらない場合、同じクライアントは同じオリジンサーバーへ戻ります。
const ORIGIN_GROUPS = ["originGroup1", "originGroup2"];

// 仮想ノード数を定義します。オリジンサーバーグループ(ORIGIN_GROUPS)が多い場合は、仮想ノード数を低く調整することをお勧めします。
const VIRTUAL_NODES_PER_GROUP = 15;
const ORIGIN_HEADER_NAME = 'X-Forwarded-For-Origin';
let virtualNodesHashesCache = null;

// 関数の呼び出し回数を追跡するためにグローバル変数を定義します。
addEventListener("fetch", (event) => {
handleRequest(event.request);
});

async function handleRequest(request) {
// EO-Client-IPヘッダーを使用してクライアントIPを取得します。
const ip = request.headers.get("EO-Client-IP") || "";
// キャッシュに仮想ノードハッシュ値がない場合は、仮想ノードハッシュ値を生成します。
if (!virtualNodesHashesCache) {
virtualNodesHashesCache = await generateVirtualNodesHashes();
}
const group = await findSourceGroupForIp(
ip,
virtualNodesHashesCache.hashes,
virtualNodesHashesCache.mapping
);
console.log(`Group: ${group}`);
request.headers.set(ORIGIN_HEADER_NAME, group)

return;
}
// 仮想ノードのハッシュ値を生成します。
async function generateVirtualNodesHashes() {
const virtualNodesHashes = {};
for (let group in ORIGIN_GROUPS) {
for (let i = 0; i < VIRTUAL_NODES_PER_GROUP; i++) {
const virtualNodeIdentifier = `${group}-VN${i}`;
const hash = await md5(virtualNodeIdentifier);
if (!virtualNodesHashes[hash]) {
virtualNodesHashes[hash] = group;
}
}
}

const hashes = Object.keys(virtualNodesHashes).sort();
return { hashes, mapping: virtualNodesHashes }; // ソート済みのハッシュ値配列とマッピングを返します。
}

// クライアントIPを仮想ノードにマッピングし、対応するオリジンサーバーグループを見つけます。
async function findSourceGroupForIp(ip, hashes, mapping) {
// md5関数を使用してIPのハッシュ値を計算します。
const ipHash = await md5(ip);
let closestHash = hashes.find((hash) => hash > ipHash) || hashes[0];
// 見つかった仮想ノードハッシュ値に基づいて、仮想ノードハッシュテーブルから対応するオリジンサーバーグループ名を取得します。
const selectedGroupName = mapping[closestHash];
const selectedGroupIPs = ORIGIN_GROUPS[selectedGroupName];
// クライアントIP、ハッシュ値、最も近い仮想ノードハッシュ値、選択されたオリジンサーバーグループ名を表示するログを出力します。
console.log(
`IP: ${ip}, Hash: ${ipHash}, Closest Hash: ${closestHash}, Selected Group: ${selectedGroupName}`
);
// 選択されたオリジンサーバーグループ名を返します。
return selectedGroupIPs;
}

function bufferToHex(arr) {
return Array.prototype.map
.call(arr, (x) => (x >= 16 ? x.toString(16) : "0" + x.toString(16)))
.join("");
}

async function md5(text) {
const buffer = await crypto.subtle.digest("MD5", TextEncoder().encode(text));
return bufferToHex(new Uint8Array(buffer));
}

ステップ3:エッジ関数のトリガールールの設定とデプロイ

1. 関数の編集が完了したら、作成してデプロイをクリックします。関数のデプロイ後、直接トリガールールを追加をクリックして、この関数のトリガールールを設定できます。



2. 関数のトリガールールで、この関数のトリガー条件を設定します。現在のシナリオ要件に応じて、複数のトリガー条件を設定し、And ロジックでトリガーできます。
ここでは、このリクエストのHOSTがexample.comと等しい場合のみ設定します。
リクエストURLが上記の条件をすべて満たすと、ステップ1のエッジ関数がトリガーされ、クライアントIPアドレスに基づくセッション維持機能を実現します。

3. OKをクリックすると、トリガールールがすぐに有効になります。

ステップ4:ルールエンジンの設定

1. EdgeOneコンソールにログインし、左側のメニューバーで「サービス概要」に入り、「Webサイト安全な加速」内で設定が必要なサイトをクリックします。
2. 左側のナビゲーションバーで「サイト加速」をクリックし、サイト全体設定ページに入り、「ルールエンジン」タブをクリックします。
3. ルールエンジンページで「ルールを作成」をクリックし、「新しい空白のルールを追加」を選択します。
4. ルール編集ページで、指定されたドメインのリクエストをマッチングするためにHOSTマッチングタイプを選択します。
ここでは、このリクエストのHOSTがexample.comと等しい場合のみ設定します。
5. 規則編集ページで、「クライアントIPヘッダー」を有効にし、 クライアントIPの取得を参照してください。
ここでは、ヘッダー名をEO-Client-IPのみ設定します。
6. ルール編集ページで、+IFをクリックし、エッジ関数の関数コード内のリクエストヘッダーの値に基づいて、異なるオリジンサーバーグループを設定します。
ここでは、条件がHTTPリクエストヘッダーX-Forwarded-For-OriginがoriginGroup1と等しい場合にのみ、リクエストは中国本土のオリジンサーバーグループに転送されて処理されます。条件がHTTPリクエストヘッダーX-Forwarded-For-OriginがoriginGroup2と等しい場合、リクエストはシンガポールのオリジンサーバーグループに転送されて処理されます。

7. 保存して公開をクリックすると、ルールエンジンがすぐに有効になります。

ステップ5:デプロイ効果の検証

テストの結果、本サンプルは優れた負荷分散能力を示し、負荷分散の割合は50%前後で変動し、かつユーザーセッションの一貫性を効果的に維持できることが確認でき、デプロイ効果が期待通りであることを証明しました。

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック