1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
4 <!-- English Revision: 420990:1657407 (outdated) -->
7 Licensed to the Apache Software Foundation (ASF) under one or more
8 contributor license agreements. See the NOTICE file distributed with
9 this work for additional information regarding copyright ownership.
10 The ASF licenses this file to You under the Apache License, Version 2.0
11 (the "License"); you may not use this file except in compliance with
12 the License. You may obtain a copy of the License at
14 http://www.apache.org/licenses/LICENSE-2.0
16 Unless required by applicable law or agreed to in writing, software
17 distributed under the License is distributed on an "AS IS" BASIS,
18 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
19 See the License for the specific language governing permissions and
20 limitations under the License.
23 <modulesynopsis metafile="mod_unique_id.xml.meta">
25 <name>mod_unique_id</name>
26 <description>それぞれのリクエストに対する一意な識別子の入った環境変数を
28 <status>Extension</status>
29 <sourcefile>mod_unique_id.c</sourcefile>
30 <identifier>unique_id_module</identifier>
34 <p>このモジュールは非常に制限された条件下で、
35 それぞれのリクエストに「すべて」のリクエストに対して
36 一意に決まることが保証されている魔法のトークンを提供します。
37 この一意な識別子は、適切に設定されたクラスタでは複数の
38 マシンの間でさえも一意になります。それぞれのリクエストに対して環境変数
39 <code>UNIQUE_ID</code> に識別子が設定されます。
40 一意な識別子が便利な理由はいろいろありますが、
41 このドキュメントの目的からは外れるため、ここでは説明しません。</p>
47 <p>まずはじめに、Apache サーバが Unix
48 マシンでどのように動作をするかを簡単に説明します。
49 この機能は現時点では Windows NT ではサポートされていません。
50 Unix マシンでは Apache はいくつかの子プロセスを作成し、
51 その子プロセスが一つずつリクエストを処理します。それぞれの子プロセスは、
52 生存期間中に複数のリクエストを扱うことができます。
53 この議論では子プロセス間では一切データを共有しないことにします。
54 以後、この子プロセスのことを <dfn>httpd プロセス</dfn> と呼びます。</p>
56 <p>あなたのウェブサイトにはあなたが管理するいくつかのマシンがあるとします。
57 それらをまとめてクラスタと呼ぶことにします。それぞれのマシンは複数の
59 これらすべてをまとめたものが「宇宙」であると考えられます。
60 いくつかの仮定の下で、クラスタのマシン間がたくさん通信をすることなく、
61 この宇宙の中でそれぞれのリクエストに一意な識別子を生成できることを示します。
64 <p>クラスタにあるマシンは以下の要求を見たさなければなりません。
65 (マシンが一つだけだとしても、NTP で時計を合わせる方が良いです。)</p>
68 <li>NTP や他のネットワーク上で時間を合わせるプロトコルによって
69 各マシンの時間の同期が取られていること。</li>
71 <li>モジュールがホスト名を引いて違う IP
73 クラスタのそれぞれのマシンのホスト名が違うこと。</li>
76 <p>オペレーティングシステムにおいては、pid (プロセス ID) が
77 32 ビットの範囲内であることを仮定します。オペレーティングシステムの
78 pid が 32 ビットを超える場合は、簡単な修正ではありますが、
81 <p>これらの仮定が満たされていると、ある時点において、
83 プロセスでも、一意に同定することができます。これはマシンの IP
84 アドレスと httpd プロセスの pid で十分に行なうことができます。
85 ですから、リクエストに一意な識別子を生成するためには、
88 <p>時刻を区別するために、Unix のタイムスタンプ (UTC の 1970 年
89 1 月 1 日からの秒数) と、16 ビットのカウンタを使います。
90 タイムスタンプの粒度は一秒ですので、一秒間の 65536
91 までの値を表現するためにカウンタを使用します。四つの値
92 <em>( ip_addr, pid, time_stamp, counter )</em> で各 httpd
93 プロセスで一秒の間に 65536 リクエストを数えあげることができます。
94 時間が経つと pid が再利用されるという問題がありますが、
95 この問題を解決するためにカウンタが使用されます。</p>
97 <p>httpd の子プロセスが作成されると、カウンタは
98 (その時点のマイクロ秒 ÷ 10) modulo 65536 で初期化されます
99 (この式はいくつかのシステムにある、マイクロ秒の
100 タイマの下位ビットが異なるという問題を解決するために選ばれました)。
101 一意な識別子が生成されたとき、使用されるタイムスタンプは
102 ウェブサーバにリクエストが到着した時刻になります。
103 カウンタは識別子が生成されるたびに増加します
104 (あふれた場合は 0 に戻ります)。</p>
106 <p>カーネルはプロセスをフォークすると、それぞれのプロセスのために
107 pid を生成します。pid は繰り返されることが許可されています
108 (pid の値は多くの Unix では 16 ビットですが、新しいシステムでは
110 ですから、ある程度の時間が経過すると同じ pid が再び使用されます。
112 四つの値の一意性は保たれます。つまり、我々はシステムが一秒間
113 に 65536 個のプロセスを起動しないと仮定しています (いくつかの Unix
114 では 32768 プロセスですが、それですらほとんどあり得ないでしょう)。</p>
116 <p>何らかの理由で、同じ時刻が繰り返されたとしましょう。
117 つまり、システムの時計が狂っていて、もう一度過去の時刻になってしまった
119 正しい時刻に戻したために再び将来の時刻になってしまった) とします。
120 この場合、pid とタイムスタンプが再使用されることが簡単に示されます。
121 カウンタ初期化用の関数は、この問題の回避を手助けしようと選択されています。
122 本当はカウンタの初期化をするためにランダムな数字を使いたいのですが、
123 ほとんどのシステムでは簡単に使用できる数は無いことに注意してください
124 (<em>すなわち</em>、rand ()は使えません。rand () には seed
125 を与える必要があり、seed には時刻を使えません。一秒単位では、
126 その時刻はすでに繰り返されているからです)。
127 これは、完璧な対策ではありません。</p>
129 <p>この対策はどのくらい効果があるでしょうか?
130 ここでは、マシン群の中の一つは最大で一秒に 500
131 リクエストを扱うと仮定します (これを書いている時点では妥当な上限です。
132 通常システムがすることは静的なファイルを取りだすだけではありませんから)。
133 それを行なうために、そのマシンは並行して来るクライアントの数に
135 しかしながら、悲観的に考えて、一つの子プロセスが一秒に 500
136 リクエストを扱えるとします。そうすると、(一秒の精度において)
137 時刻が同じ時を繰り返すと、この子プロセスがカウンタの値を再び使い、
138 一意性が壊れる可能性が 1.5% あります。
139 これは非常に悲観的な例で、実世界の値では、ほとんど起こりそうにありません。
140 それでもこれが起こる可能性のあるようなシステムなら、
142 カウンタを 32 ビットにするのが良いでしょう。
145 <p>サマータイムにより時計が「戻される」ことを気にしている人が
146 いるかもしれません。ここで使用される時間は UTC であり、
147 それは「常に」進むのでここでは問題になりません。x86 上の Unix
148 はこの条件を満たすために適切な設定が必要かもしれないことに
149 注意してください。マザーボードの時計は UTC になっていて、
150 他の時間はそこから適切に補正されることを仮定できるように
151 設定されなければなりません。そのような場合でさえ、NTP
152 を使っているならばリブート後にすぐ正しい UTC の時間になるでしょう。</p>
154 <p><code>UNIQUE_ID</code> 環境変数は 112 ビット (32 ビット IP
155 アドレス、32 ビット pid, 32 ビットタイムスタンプ、16
156 ビットカウンタの四つの組) をアルファベット <code>[A-Za-z0-9@-]</code>
157 を用いて MIME の base64 符号化と同様の方法により符号化し、19
158 の文字を生成することにより作成されます。MIME の base64
159 のアルファベットは実際は <code>[A-Za-z0-9+/]</code> ですが、
160 <code>+</code> と <code>/</code> とは URL
161 では特別な符号化が必要なので、あまり望ましくありません。
162 全ての値はネットワークバイトオーダで符号化されますので、
163 符号は違ったバイトオーダのアーキテクチャ間で比較可能です。
164 実際の符号化の順番は: タイムスタンプ、IP アドレス、pid,
165 カウンタです。この順には目的がありますが、
166 アプリケーションは符号を解析するべきではないことを強調しておきます。
167 アプリケーションは符号化された <code>UNIQUE_ID</code>
168 全体を透過的なトークンとして扱うべきです。
169 <code>UNIQUE_ID</code> は他の <code>UNIQUE_ID</code>
170 との等価性を調べるためだけにのみ使用できます。</p>
172 <p>この順番は将来、既存の <code>UNIQUE_ID</code>
173 のデータベースとの衝突を心配することなく符号を変更することが
175 新しい符号はタイムスタンプを最初の要素として残すのが望ましく、
176 それ以外は同じアルファベットとビット長を使うことができます。
177 タイムスタンプは本質的に増加系列ですので、
178 クラスタの全てのマシンがリクエストとサーバ機能を停止して、
179 古い符号化方式を使用するのをやめる<em>フラグ秒</em>があれば十分です。
181 新しい符号を発行することができるようになります。</p>
184 この問題に対する比較的移植性の高い解決法だと考えています。
185 Windows NT のようなマルチスレッドのシステムに拡張することができますし、
186 将来必要になればさらに増やすこともできます。
187 ID は必要に応じて長くすることができますので、生成された ID
188 は実質上、無限に有効です。また、クラスタのマシン間の通信も事実上必要なく
189 (NTP による同期のみが必要で、これはオーバヘッドはあまりありません)、httpd
190 プロセス間の通信も必要ありません (通信はカーネルにより割り当てられた
191 pid の値により暗黙の内に行なわています)。
192 さらに限られた状況下では、ID はさらに短くすることができますが、
193 より多くの情報を仮定する必要がでてきます (例えば、32 ビット
194 IP アドレスはどのサイトにおいても過剰な情報ですが、
195 それの代わりになる移植性のあるものはありません)。</p>