1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja"><head><!--
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>mod_proxy_balancer - Apache HTTP サーバ</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
<body>
<div id="page-header">
<p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/directives.html">ディレクティブ</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p>
<p class="apache">Apache HTTP サーバ バージョン 2.2</p>
<img alt="" src="../images/feather.gif" /></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP サーバ</a> > <a href="http://httpd.apache.org/docs/">ドキュメンテーション</a> > <a href="../">バージョン 2.2</a> > <a href="./">モジュール</a></div>
<div id="page-content">
<div id="preamble"><h1>Apache モジュール mod_proxy_balancer</h1>
<div class="toplang">
<p><span>翻訳済み言語: </span><a href="../en/mod/mod_proxy_balancer.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../ja/mod/mod_proxy_balancer.html" title="Japanese"> ja </a></p>
</div>
<table class="module"><tr><th><a href="module-dict.html#Description">説明:</a></th><td>負荷分散のための <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> 拡張</td></tr>
<tr><th><a href="module-dict.html#Status">ステータス:</a></th><td>Extension</td></tr>
<tr><th><a href="module-dict.html#ModuleIdentifier">モジュール識別子:</a></th><td>proxy_balancer_module</td></tr>
<tr><th><a href="module-dict.html#SourceFile">ソースファイル:</a></th><td>mod_proxy_balancer.c</td></tr>
<tr><th><a href="module-dict.html#Compatibility">互換性:</a></th><td>Apache 2.1 以降で使用可能</td></tr></table>
<h3>概要</h3>
<p>本モジュールには <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> が<em>必要です</em>。
本モジュールは <code>HTTP</code> と <code>FTP</code> と <code>AJP13</code>
プロトコルのロードバランス機能を持っています。</p>
<p>ですから、 ロードバランスを有効にする場合 <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code>
と <code class="module"><a href="../mod/mod_proxy_balancer.html">mod_proxy_balancer</a></code> がサーバに組み込まれて
いなければいけません。</p>
<div class="warning"><h3>警告</h3>
<p><a href="mod_proxy.html#access">
安全なサーバにする</a>までプロキシ機能は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
インターネット全体にとっても危険です。</p>
</div>
</div>
<div id="quickview"><h3 class="directives">ディレクティブ</h3>
<p>このモジュールにディレクティブはありません。</p>
<h3>トピック</h3>
<ul id="topics">
<li><img alt="" src="../images/down.gif" /> <a href="#scheduler">ロードバランサのスケジューラのアルゴリズム</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#stickyness">ロードバランサのスティッキネス</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#example">ロードバランサの設定例</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#requests">Request Counting アルゴリズム</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#traffic">Weighted Traffic Counting アルゴリズム</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#busyness">Pending Request Counting アルゴリズム</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#environment">エクスポートされる環境変数</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#balancer_manager">バランサマネージャのサポートを有効にする</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#stickyness_implementation">ロードバランサのスティッキネスの詳細</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#stickyness_troubleshooting">ロードバランサのスティッキネスのトラブルシューティング</a></li>
</ul><h3>参照</h3>
<ul class="seealso">
<li><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="scheduler" id="scheduler">ロードバランサのスケジューラのアルゴリズム</a></h2>
<p>現時点では 3 種類のロードバランサスケジューラアルゴリズムから選べます。
リクエスト回数によるもの <span class="transnote">(<em>訳注:</em> Request Counting)</span>
、トラフィック量によるもの <span class="transnote">(<em>訳注:</em> Weighted Traffic Counting)</span>
と、処理中リクエスト数によるもの <span class="transnote">(<em>訳注:</em> Pending Request Counting)</span>
とがあります。バランサの設定 <code>lbmethod</code> 値で、どれを使うか指定します。
詳細は <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> ディレクティブを
参照してください。</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="stickyness" id="stickyness">ロードバランサのスティッキネス</a></h2>
<p>バランサはスティッキネスをサポートします。リクエストがあるバックエンドに
プロキシされた時、続く同じユーザからのリクエストは、すべてその同じバックエンドに
プロキシされるべきです。多くのロードバランサはこの機能をクライアントの
IP アドレスとバックエンドの対応表を持つことで実現します。
この方法はクライアントにもバックエンドにも透過に動作しますが、
次に挙げるいくつかの問題があります。
もしクライアント自身がプロキシの背後にいる場合、負荷分散が不均一になります。
もし動的な IP アドレスを持つクライアントのアドレスがセッション中に変わると
スティッキネスは期待どおりに動作しません。
もし対応表があふれると、スティッキネスが失われます。</p>
<p><code class="module"><a href="../mod/mod_proxy_balancer.html">mod_proxy_balancer</a></code> はスティッキネスを
2 種類の別手法をもとに実装しています。クッキーと URL エンコーディングのふたつです。
クッキーはバックエンドもしくは Apache Web サーバ自身により提供されます。
URL エンコーディングは通常バックエンドにより行われます。</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="example" id="example">ロードバランサの設定例</a></h2>
<p>技術的な詳細に入る前に例を示します。以下は、2 台のバックエンドサーバを
ロードバランスするための <code class="module"><a href="../mod/mod_proxy_balancer.html">mod_proxy_balancer</a></code> の使い方の一例です:
</p>
<div class="example"><p><code>
<Proxy balancer://mycluster><br />
BalancerMember http://192.168.1.50:80<br />
BalancerMember http://192.168.1.51:80<br />
</Proxy><br />
ProxyPass /test balancer://mycluster
</code></p></div>
<p>別の例として、<code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> を使ってスティッキネス
を実現するロードバランサの設定例を示します。バックエンドのサーバが
適切なセッションクッキーをセットしなくても動作します。
</p>
<div class="example"><p><code>
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
env=BALANCER_ROUTE_CHANGED<br />
<Proxy balancer://mycluster><br />
BalancerMember http://192.168.1.50:80 route=1<br />
BalancerMember http://192.168.1.51:80 route=2<br />
ProxySet stickysession=ROUTEID<br />
</Proxy><br />
ProxyPass /test balancer://mycluster
</code></p></div>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="requests" id="requests">Request Counting アルゴリズム</a></h2>
<p><code>lbmethod=byrequests</code> で有効になります。
このスケジューラの背景にある考え方は、様々なワーカーがそれぞれ、
設定されている分担リクエスト数をきちんと受け取れるように、
リクエストを扱うという考え方です。次のように動作します:</p>
<p><dfn>lbfactor</dfn> は、<em>どの程度ワーカーに仕事を振るか</em>
つまり<em>ワーカーのクオータ</em>を指します。この値は "分担"
量を表す正規化された値です。</p>
<p><dfn>lbstatus</dfn> は、<em>ワーカーのクオータを満たすために
どのぐらい急ぎで働かなければならないか</em>を指します。</p>
<p><dfn>ワーカー</dfn>はロードバランサのメンバで、通常は、
サポートされるプロトコルのうちの一つを提供しているリモートホストです。
</p>
<p>まず個々のワーカーにワーカークオータを割り振り、どのワーカーが最も急ぎで
働かなければならないか (lbstatus が最大のもの) を調べます。
次に仕事をするようにこのワーカーを選択し、選択したワーカーの lbstatus
から全ワーカーに割り振ったクオータの合計を引きます。ですから、lbstatus の総量は
結果的に変化しません(*)し、リクエストは期待通りに分散されます。</p>
<p>あるワーカーが無効になっても、他のものは正常にスケジュールされ続けます。
</p>
<div class="example"><pre><code>for each worker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidate lbstatus -= total factor</code></pre></div>
<p>バランサを次のように設定した場合:</p>
<table><tr><th>worker</th>
<th class="data">a</th>
<th class="data">b</th>
<th class="data">c</th>
<th class="data">d</th></tr>
<tr><th>lbfactor</th>
<td class="data">25</td>
<td class="data">25</td>
<td class="data">25</td>
<td class="data">25</td></tr>
<tr><th>lbstatus</th>
<td class="data">0</td>
<td class="data">0</td>
<td class="data">0</td>
<td class="data">0</td></tr>
</table>
<p>そして <var>b</var> が無効になった場合、次のようなスケジュールが
行われます。</p>
<table><tr><th>worker</th>
<th class="data">a</th>
<th class="data">b</th>
<th class="data">c</th>
<th class="data">d</th></tr>
<tr><th>lbstatus</th>
<td class="data"><em>-50</em></td>
<td class="data">0</td>
<td class="data">25</td>
<td class="data">25</td></tr>
<tr><th>lbstatus</th>
<td class="data">-25</td>
<td class="data">0</td>
<td class="data"><em>-25</em></td>
<td class="data">50</td></tr>
<tr><th>lbstatus</th>
<td class="data">0</td>
<td class="data">0</td>
<td class="data">0</td>
<td class="data"><em>0</em></td></tr>
<tr><td class="data" colspan="5">(repeat)</td></tr>
</table>
<p>つまりこのようにスケジュールされます: <var>a</var> <var>c</var>
<var>d</var> <var>a</var> <var>c</var> <var>d</var> <var>a</var>
<var>c</var> <var>d</var> ... 次の点に注意してください:</p>
<table><tr><th>worker</th>
<th class="data">a</th>
<th class="data">b</th>
<th class="data">c</th>
<th class="data">d</th></tr>
<tr><th>lbfactor</th>
<td class="data">25</td>
<td class="data">25</td>
<td class="data">25</td>
<td class="data">25</td></tr>
</table>
<p>この挙動は、次の設定と全く同じになります:</p>
<table><tr><th>worker</th>
<th class="data">a</th>
<th class="data">b</th>
<th class="data">c</th>
<th class="data">d</th></tr>
<tr><th>lbfactor</th>
<td class="data">1</td>
<td class="data">1</td>
<td class="data">1</td>
<td class="data">1</td></tr>
</table>
<p>と言うのも、<dfn>lbfactor</dfn> の値は全て正規化されたもので、
他との相対値だからです。次の設定では:</p>
<table><tr><th>worker</th>
<th class="data">a</th>
<th class="data">b</th>
<th class="data">c</th></tr>
<tr><th>lbfactor</th>
<td class="data">1</td>
<td class="data">4</td>
<td class="data">1</td></tr>
</table>
<p>ワーカー <var>b</var> は、平均して、<var>a</var> と <var>c</var>
の 4 倍の数のリクエストを受け持つことになります。</p>
<p>次のような非対称な設定では、こうなると予想されるでしょう:</p>
<table><tr><th>worker</th>
<th class="data">a</th>
<th class="data">b</th></tr>
<tr><th>lbfactor</th>
<td class="data">70</td>
<td class="data">30</td></tr>
<tr><td class="data" colspan="2"> </td></tr>
<tr><th>lbstatus</th>
<td class="data"><em>-30</em></td>
<td class="data">30</td></tr>
<tr><th>lbstatus</th>
<td class="data">40</td>
<td class="data"><em>-40</em></td></tr>
<tr><th>lbstatus</th>
<td class="data"><em>10</em></td>
<td class="data">-10</td></tr>
<tr><th>lbstatus</th>
<td class="data"><em>-20</em></td>
<td class="data">20</td></tr>
<tr><th>lbstatus</th>
<td class="data"><em>-50</em></td>
<td class="data">50</td></tr>
<tr><th>lbstatus</th>
<td class="data">20</td>
<td class="data"><em>-20</em></td></tr>
<tr><th>lbstatus</th>
<td class="data"><em>-10</em></td>
<td class="data">10</td></tr>
<tr><th>lbstatus</th>
<td class="data"><em>-40</em></td>
<td class="data">40</td></tr>
<tr><th>lbstatus</th>
<td class="data">30</td>
<td class="data"><em>-30</em></td></tr>
<tr><th>lbstatus</th>
<td class="data"><em>0</em></td>
<td class="data">0</td></tr>
<tr><td class="data" colspan="3">(repeat)</td></tr>
</table>
<p>スケジュールは 10 スケジュール後に繰り返され、<var>a</var> 7 回と
<var>b</var> 3 回でまばらに選ばれます。</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="traffic" id="traffic">Weighted Traffic Counting アルゴリズム</a></h2>
<p><code>lbmethod=bytraffic</code> で有効になります。
このスケジューラの背景にある考え方は、Request Counting
と非常に似ていますが、次の違いがあります:</p>
<p><dfn>lbfactor</dfn> は <em>どれだけのバイト数のトラフィック量を、
このワーカーに処理してもらいたいか</em> を表します。
この値も同様に正規化された値で、ワーカー全体のうちでの "分担"
量を表現しています。リクエスト数を単純に数える代わりに、
どれだけの転送量を処理したかを数えます。</p>
<p>次のようにバランサを設定した場合:</p>
<table><tr><th>worker</th>
<th class="data">a</th>
<th class="data">b</th>
<th class="data">c</th></tr>
<tr><th>lbfactor</th>
<td class="data">1</td>
<td class="data">2</td>
<td class="data">1</td></tr>
</table>
<p><var>b</var> には <var>a</var> や <var>c</var> の 2 倍
処理してほしいということになります。
<var>b</var> は 2 倍の I/O を処理するという意味になり、
2 倍のリクエスト数を処理するということにはなりません。
ですからリクエストとレスポンスのサイズが、
重み付けと振り分けのアルゴリズムに効いています。</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="busyness" id="busyness">Pending Request Counting アルゴリズム</a></h2>
<p><code>lbmethod=bybusyness</code> で有効になります。このスケジューラは
現在どのぐらいのリクエストが個々のワーカーにアサインされているかを把握しています。
新しいリクエストは、最も処理途中のリクエスト数が少ないワーカーに
自動的に割り振られます。これは、ワーカーが Apache と無関係に入力リクエストを
キューに溜め込む場合に有効で、キューの長さを同程度に維持しつつも、
最も早く処理できそうなワーカーに常にリクエストを割り振ります。</p>
<p>複数のワーカーが最少の処理中リクエスト数で並んだ場合、Request Counting
アルゴリズムと同じ統計情報（と重み付け）を使って順番を決めます。
時間が経つと、割り振りの割合は <code>byrequests</code> と似たような
傾向を示すようになるでしょう。</p>
<p>このアルゴリズムは Apache HTTP サーバ 2.2.10以降で利用可能です。</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="environment" id="environment">エクスポートされる環境変数</a></h2>
<p>現在、6 つの環境変数がエクスポートされます:</p>
<dl>
<dt><var><a name="balancer_session_sticky" id="balancer_session_sticky">BALANCER_SESSION_STICKY</a></var></dt>
<dd>
<p>現在のリクエストに使われる <var>stickysession</var> 値になります。
スティッキーセッションのためのクッキー名もしくはリクエストパラメータ名です。</p>
</dd>
<dt><var><a name="balancer_session_route" id="balancer_session_route">BALANCER_SESSION_ROUTE</a></var></dt>
<dd>
<p>現在のリクエストをパースして得られる <var>route</var> 値です。</p>
</dd>
<dt><var><a name="balancer_name" id="balancer_name">BALANCER_NAME</a></var></dt>
<dd>
<p>現在のリクエストが使うバランサ名です。<code>balancer://foo</code>
のような値です。</p>
</dd>
<dt><var><a name="balancer_worker_name" id="balancer_worker_name">BALANCER_WORKER_NAME</a></var></dt>
<dd>
<p>現在のリクエストが使うワーカー名です。<code>http://hostA:1234</code>
のような値です。</p>
</dd>
<dt><var><a name="balancer_worker_route" id="balancer_worker_route">BALANCER_WORKER_ROUTE</a></var></dt>
<dd>
<p>現在のリクエストが使うワーカーの <var>route</var> 値です。</p>
</dd>
<dt><var><a name="balancer_route_changed" id="balancer_route_changed">BALANCER_ROUTE_CHANGED</a></var></dt>
<dd>
<p>セッションルートとワーカールートが一致しない時 (BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE)
あるいは、セッションがまだルートを確立していない時、値が 1 になります。
スティッキーセッションを使う時、ルートの更新をクライアントに送る必要があるかを
判断するためにこの環境変数を使えます。</p>
</dd>
</dl>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="balancer_manager" id="balancer_manager">バランサマネージャのサポートを有効にする</a></h2>
<p>このモジュールは <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> のサービスを
<em>必要とします</em>。
バランサマネージャを使うと、バランサのメンバーの動的な更新が
できます。バランサマネージャを使って、バランス係数 (lbfactor)
を変更したり、メンバーを変更したり、特定のメンバーを
オフラインモードにしたりできます。</p>
<p>ですから、ロードバランサ管理機能を使いたければ、
<code class="module"><a href="../mod/mod_status.html">mod_status</a></code> と <code class="module"><a href="../mod/mod_proxy_balancer.html">mod_proxy_balancer</a></code>
をサーバに組み込まなければなりません。</p>
<p>example.com ドメインのブラウザからロードバランサ管理機能を
使えるようにするには、次のようなコードを <code>httpd.conf</code>
に追加します。</p>
<div class="example"><p><code>
<Location /balancer-manager><br />
SetHandler balancer-manager<br />
<br />
Order Deny,Allow<br />
Deny from all<br />
Allow from .example.com<br />
</Location>
</code></p></div>
<p>こうすると、<code>http://your.server.name/balancer-manager</code>
のページ経由で、ウェブブラウザからロードバランサマネージャに
アクセスできるようになります。</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="stickyness_implementation" id="stickyness_implementation">ロードバランサのスティッキネスの詳細</a></h2>
<p>クッキーをもとにスティッキネスを使う場合、どのバックエンドに割り振るべきか
を決めるクッキーの名前を指定する必要があります。
クッキー名は <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> または
<code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code> のいずれか
に付与する <var>stickysession</var> 属性で設定します。
クッキー名は大文字小文字を区別します。
バランサはそのクッキーの値を取り出し、その値に一致する <var>route</var> 値の
ワーカーを探します。
<var>route</var> も <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code>
または <code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code>
のいずれかに設定しなければいけません。
クッキーはバックエンドによって設定されるか、あるいは
上記の <a href="#example">例</a> のように Apache Web サーバ自身
によって設定されます。</p>
<p>バックエンドの中の一部は少し異なる形式のスティッキネスクッキーを使います。
たとえば Apache Tomcat がそうです。Tomcat は自身のインスタンス名を
セッション ID のクッキーの最後に付け加えます。この時、セッション ID
との区切り文字にドット (<code>.</code>) を使います。
このため、Apache Web サーバがドットをスティッキネスクッキー値の中に見つけると、
route を探すためにドット以降の部分のみを使うようにします。
Tomcat 側で自身のインスタンス名を設定するには、Tomcat の設定ファイル
<code>conf/server.xml</code> の中の <code>jvmRoute</code> 属性に
指定する必要があります。値はそれぞれの Tomcat に接続するワーカーの
<var>route</var> 値と一致させます。
Tomcat およびサーブレットベースの Java Web アプリサーバが一般に使う
セッションクッキーの名前は <code>JSESSIONID</code> (すべて大文字) です。
この名前は設定により変更も可能です。</p>
<p>スティッキネスを実装するふたつめの手段は URL エンコーディングです。
Web サーバはリクエストの URL の中からクエリパラメータを探します。
探すパラメータ名は同じように <var>stickysession</var> 属性で指定します。
パラメータ値と一致する <var>route</var> 値のワーカーを探します。
レスポンスに含まれるすべての URL リンクを探しだし書き換えるのは簡単ではないので、
一般にそれぞれのリンクにクエリパラメータを付け加えるのは、
そのコンテンツを生成したバックエンドの仕事です。
時には、<code class="module"><a href="../mod/mod_substitute.html">mod_substitute</a></code> を使って Web サーバにこの書き換えを
させるのが可能な場合もあります。
ただし、パフォーマンスを落とす可能性があります。</p>
<p>Java 標準は URL エンコーディングを少し異なる形で実装します。
URL のパス情報をセミコロン (<code>;</code>) で区切って
セッション ID を付け加えます。
クッキーの場合と同じように、 Apache Tomcat はこのパス情報に
<code>jvmRoute</code> の設定値を含めます。
Apache にこの種のパス情報を見つけさせるには、
<code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> あるいは
<code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code> の
<code>scolonpathdelim</code> を <code>On</code> にします。</p>
<p>最後に、クッキーと URL エンコーディングの両方が指定できることを示します。
次の例のように、クッキー名と URL パラメータ名を垂直バー (<code>|</code>)
で区切って指定します:</p>
<div class="example"><p><code>
ProxyPass /test balancer://mycluster stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Proxy balancer://mycluster><br />
BalancerMember http://192.168.1.50:80 route=node1<br />
BalancerMember http://192.168.1.51:80 route=node2<br />
</Proxy><br />
</code></p></div>
<p>もし同じリクエストが、クッキーとリクエストパラメータの両方のルーティング情報を
提供した場合、リクエストパラメータのほうが使われます。</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="stickyness_troubleshooting" id="stickyness_troubleshooting">ロードバランサのスティッキネスのトラブルシューティング</a></h2>
<p>もしアプリのセッションが失われてユーザが再ログインしなければいけないなど
スティッキネス関連のエラーに遭遇したら、
この原因はバックエンドの応答に支障があったせいか、
あるいは設定ミスによるものかを最初に切り分けたいでしょう。
バックエンドの安定性に関して起きうる問題を見つけるには、
Apache のエラーログにプロキシエラーのメッセージがないか確認してください。</p>
<p>設定が正しいかを確認するには、最初にスティッキネスを
クッキーと URL エンコーディングのどちらで行っているかを確認してください。
次に、<code class="directive"><a href="../mod/mod_log_config.html#logformat">LogFormat</a></code> を変更して
アクセスログに適切なデータが残るようにするとよいでしょう。
次のフィールドが便利です:</p>
<dl>
<dt><code>%{MYCOOKIE}C</code></dt>
<dd><code>MYCOOKIE</code> という名前のクッキーの値。
この名前は <var>stickysession</var> 属性の指定値と同じはずです。</dd>
<dt><code>%{Set-Cookie}o</code></dt>
<dd>これによりバックエンドがセットするクッキーをログに出せます。
バックエンドが期待するセッションクッキーをセットしているかと、
どんな値がセットされているかを追跡できます。</dd>
<dt><code>%{BALANCER_SESSION_STICKY}e</code></dt>
<dd>ルーティング情報を決めるために使われたクッキー名もしくは
リクエストパラメータ名。</dd>
<dt><code>%{BALANCER_SESSION_ROUTE}e</code></dt>
<dd>リクエスト内に見つかった route 値の情報</dd>
<dt><code>%{BALANCER_WORKER_ROUTE}e</code></dt>
<dd>選択されたワーカーの route 値</dd>
<dt><code>%{BALANCER_ROUTE_CHANGED}e</code></dt>
<dd>リクエストの route 値がワーカーの route 値と異なる場合に
<code>1</code> になります。つまり、リクエストはスティッキーとして
処理されていません。</dd>
</dl>
<p>セッションが失われる原因でよくあるものは、セッションタイムアウトですが、
これは通常バックエンドのサーバで変更可能です。</p>
<p>ログレベルを <code>debug</code> 以上に設定すると、
バランサはスティッキネス動作の詳細な情報をエラーログに書き出します。
これはスティッキネスの問題のトラブルシューティングする簡単な手法ですが、
高負荷な本番サーバではログの分量が膨大になってしまうかもしれません。</p>
</div>
</div>
<div class="bottomlang">
<p><span>翻訳済み言語: </span><a href="../en/mod/mod_proxy_balancer.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../ja/mod/mod_proxy_balancer.html" title="Japanese"> ja </a></p>
</div><div id="footer">
<p class="apache">Copyright 2012 The Apache Software Foundation.<br />この文書は <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a> のライセンスで提供されています。.</p>
<p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/directives.html">ディレクティブ</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p></div>
</body></html>
|
