リモート・ディポの使用が適切である場合と適切でない場合
問題
どのような場合にリモート・ディポを使用するべきでしょうか。
解決策
リモート・サイトのユーザをサポートする
PERFORCE の新規のお客様は、ユーザが地理的に分散されている場合、別の PERFORCE インストールを
リモート・ディポ・サポートで接続してセットアップする必要があると考えるかもしれません。
しかし、分散された開発組織であっても単一の PERFORCE インストールを使用することで生産性が
向上する場合も多くあります。
ここでいう「インストール」とは、任意の数のディポおよびクライアント・ワークスペースを
管理する PERFORCE サーバです。 PERFORCE サーバにより管理されるディポは、PERFORCE サーバが
稼働するマシンのローカルにあります。それらのディポにあるファイルは、その PERFORCE サーバにより
管理されるクライアント・ワークスペースを持つどのユーザからもアクセスが可能です。PERFORCE は
大規模なネットワークの待ち時間に対処するように設計されているため、本質的にリモート・サイトの
クライアント・ワークスペースを持つユーザをサポートします。したがって、1つの PERFORCE インストール
により、近いサイトと遠いサイトで作業するメンバーを有する共用開発プロジェクトに対応することができます。
一方リモート・ディポは、共用開発ではなく共用コードをサポートするように設計されています。
それらは、独自のPERFORCEサーバを有する独立した組織が、他のインストールにあるファイルを
参照したり、ディポから変更を反映したりすることを可能にします。リモート・ディポはロード・
バランシングやネットワーク・アクセス障害への対応策ではありませんが、それらの領域で克服不可能な
問題に、リモート・ディポを使用して対処することもできます。
このテクニカルノートでは、以下に示すような分散開発組織に関する問題について記述します。
- リモート・サイトのユーザをサポートする
- リモート・ディポはどのように機能するか
- リモート・ディポの制限
- 結論および推奨事項
1つのPERFORCEサーバがあり、リモート・サイトがない場合
1つ以上のソフトウェア・プロジェクトの開発を分担する分散された組織には、
1つのPERFORCEサーバ、1つ以上のPERFORCEディポ、多数のPERFORCEクライアント・ワークスペースが
あることが最適です。ワークスペースの地理的な位置はPERFORCE サーバとは無関係です。
図1: 1つのPERFORCEインストールでリモート・ユーザをサポートする
サポートされるユーザの数
リモート対応は、PERFORCEサーバのユーザをサポートする機能の一要素ではありません。
しかし、全体のユーザ数はその要素に数えられるかもしれません。
また、PERFORCEサーバとユーザのリモート・サイトとの間のネットワーク回線の速度と品質は
明らかにその要素に挙げられます。
リモート・サイトでは、生産的に作業することができるユーザの数はサイトのネットワーク接続に依存します。
PERFORCE 99.1およびそれ以降で利用可能なデータ圧縮機能を使用することにより、
低速なモデム回線では1-3ユーザ、64KB回線では20-30ユーザ、T1回線(1MB/秒)では100人以上のユーザを
サポートすることが予測されます。ローカルのイーサネット(10MB/秒)は企業全体をサポートするでしょう。
もちろん、これらの予測はユーザが行う作業に依存します。プレーンテキストのソースファイルで40人のユーザが
作業する場合は、おそらく64KBの回線で十分でしょう。しかし、圧縮されていない場合には特に、絶えず
大きいGIF画像を更新しているユーザが2人いるとその回線が飽和状態となり、他のすべてのユーザが不便を
強いられることになります。
単一のPERFORCEインストールで近くまたは遠くのサイトにいる多数のユーザをサポートしている場合、
制限的なクライアント・ビューおよびアクセス権限を使用して、各ユーザが自分の作業中のディポおよび
サブディレクトリにのみアクセスするよう設定することにより、PERFORCEサーバの負荷を減少させることができます
ネットワーク接続されたサイトのWindowsユーザは、P4WinよりもPERFORCEコマンドライン・クライアントであるp4を
使用するとより効率よく作業できます。それは、P4Winの現在のリリースではPERFORCEサーバからの舞台裏での
データ更新要求を頻繁に起こさせるためです。
ネットワーク・セキュリティ
接続の両端でのファイアウォールの通過に、SSH（セキュア・シェル）パッケージを使用することをお勧めします。
公開鍵暗号方式により一方の端にあるホストのIDを検証した後、通常の暗号方式によりデータ・ストリームを安全に
保つことで、安全が確実に保たれるように設定することができます。さらに、SSHは暗号化する間に圧縮を行うため、
低速なモデム回線で有効です。SSHについてより詳しくは、
テクニカルノート022：ファイアウォール経由で PERFORCE にアクセスする方法 を参照してください。
リモート・ディポを持つ複数のPERFORCEサーバ
リモート・ディポ・サポートがない場合、クライアント・ワークスペースはそれが属するインストールにある
ディポにのみアクセスできます。リモート・ディポ・サポートの目的は、クライアントが他のインストールにある
ディポにアクセスできるようにすることです:
図2: 他のインストールにあるディポにアクセスするためのリモート・ディポ・サポート
上の図は、サーバ・ポート・アドレスに "mars:1666" を使用しているPERFORCEインストールを示しています。
mars:1666のPERFORCEサーバが稼動しているマシンが物理的に当該ユーザの近くにあるか否かに関係なく、
P4PORTをmars:1666に設定していれば、これがP4またはP4Winを使用する際の「ローカルの」PERFORCEサーバになります。
mars:1666のPERFORCEサーバは、自身のディポにあるファイルを管理し、チェンジリスト、反映履歴、
クライアント・ワークスペース、およびその他のメタデータからなるデータベースを保持します。
ユーザが適切なアクセス権限を持っている限り、そのPERFORCEサーバにあるすべてのメタデータを使用でき、
PERFORCEサーバのディポにあるファイルに変更をサブミットすることができます。
mars:1666によって管理されているディポが、「ローカルの」ディポになります。
それでは、 "venus:1666" の PERFORCEサーバによって管理されるディポのファイルにアクセスしたい場合を考えます。
P4PORTをvenus:1666に設定したとすると、venus:1666がローカルのPERFORCEサーバとなります。
これでP4コマンドおよびP4Winコマンドは、そのPERFORCEサーバと通信するようになります。
しかし、venus:1666の PERFORCEサーバは、mars:1666がローカルのPERFORCEサーバであったときに使用されていた
クライアント・ワークスペースを認識しないので、新しいクライアント・ワークスペースを設定しなければなりません。
実際、venus:1666のPERFORCEサーバはユーザとmars:1666のPERFORCEサーバとの関係について、
ユーザがどのようなアクセス権を持っているか、クライアント･ビューはどうなっているか、
ワークスペースで作業状態にしているファイルはどれかなど何も認識していません。
そのため、venus:1666のディポからのファイルを、mars:1666ワークスペース内のファイルと比較または
マージしたい場合、ローカルのPERFORCEサーバとしてvenus:1666 に接続しても役に立ちません。
PERFORCEのリモート・ディポ・サポートにより、ユーザはローカルPERFORCEサーバとしてmars:1666に
接続しているときにも、venus:1666ディポのファイルにアクセスすることができます。
例えば、"//venus" というリモート・ディポを、venus:1666の "//depot2" パスにマッピングして
定義することができます。これを行った後は、p4コマンドを使用して//venusパスにあるファイルを
参照することができます。例えば、
p4 diff2 //venus/elm2.1/... //depot/elm2.1/...
とすると、"venus:1666" の "//depot2/elm2.1" パスにあるすべてのファイルが、"mars:1666" の
"//depot/elm2.1" パスにあるファイルと比較されます。
また、自分のワークスペースを "//venus" のファイルと同期させ、"//venus" の
ファイルをローカル・ディポにブランチし、"//venus" の変更をローカル・ディポに反映することができます。
"//venus" パスにあるファイルにアクセスする際、p4は "venus:1666" のPERFORCEサーバとは直接通信していません。
その代わり、p4（またはP4Win）プログラムが "mars:1666" のPERFORCEサーバと通信し、
そのサーバが今度は "venus:1666" のPERFORCEサーバに通信しています。
リモート・ディポの制限
アクセスは読み取り専用です。リモート・ディポ・アクセスは、読み取り専用の操作に制限されます。
ファイルをリモート・ディポにサブミットすることはできません。リモート・ディポのファイルを
編集することもできません。しかし、リモート・ディポにあるファイルからローカル・ディポに
ブランチを作成した後、リモート・ディポの変更をローカルのブランチに反映することは可能です。
このことは、サードパーティの開発者と共同で作業するときなど、コードの変更箇所および変更時期を
管理したい場合には有益です。
サーバのバージョンがリモート・ディポの動作を決定します。サーバ・バージョンが99.2以降である場合、
リモート・ディポはUNIXとWindowsとの間での相互運用が可能です。バージョンが98.2以降である場合、
リモート・ディポは（98.2以降の）リリース間での相互運用が可能です。バージョンが98.1以前の場合は、
リモート・ディポは同じリリースの別のPERFORCEサーバに対してのみ動作します。
ライセンス認証の必要条件：リモート・ディポにアクセスするために新たなライセンスは必要ありません。
メタデータ・アクセス非対応：PERFORCEサーバのメタデータ（クライアント・ワークスペース、チェンジリスト、
ラベルなどの情報）には、リモート・ディポを使用してアクセスできません。p4 client などのコマンドは常に、
ローカルのPERFORCEサーバのメタデータに定義されたエンティティの仕様を返します。またこのことは、
サードパーティとコードを共有する際に便利であり、企業の内部情報が見られることを防止します。
ファイル・リビジョンの参照：リモート・ディポにあるファイルはリビジョン番号またはチェンジリスト番号に
よって指定が可能ですが、チェンジリスト番号で指定されると、ローカルPERFORCEサーバではなくリモート
PERFORCEサーバのチェンジリスト番号が使用されます。リモート・ディポのファイルへはラベル名または
クライアント名によってアクセス可能ですが、これらの場合にはローカルPERFORCEサーバのラベルと
クライアント仕様が使用されます。
片側だけの反映レコード：PERFORCEサーバはそれぞれ独自のメタデータのみを参照するため、
別のインストールにあるディポ間の反映に関する知識は非常に限定的です。例を示します。
- "mars:1666" ディポのどこかにある "m_foo.c#15" ファイルが、"venus:1666" ディポの
どこかにある "v_foo.c#1" にブランチされている。
- ローカル・ユーザが "venus:1666" ファイルを変更し、それが "v_foo.c#2" になっている。
- "mars:1666" のユーザが "v_foo.c" から "m_foo.c" へと反映を行った。
これで "m_foo.c#16" には "v_foo.c#2" のデルタが含まれている。
- "venus:1666" の別のユーザが "m_foo.c" から "v_foo.c" へと反映を行った。
しかし、"venus:1666" PERFORCEサーバは "mars:1666" のめたデータを見ることができないため、
"m_foo.c#16" デルタが "v_foo.c#2" から来ていることを認識しない。認識しているのは、
最後の反映が "m_foo.c#15" から実行されていることのみである。
そのため、"m_foo.c#16" から "v_foo.c" への不必要な反映を計画してしまった。
パフォーマンス：リモート・アクセスによって、ローカルのパフォーマンスが極度に低下することがあります。
リモートPERFORCEサーバへのアクセス速度が非常に遅い場合、ローカル・ユーザは接続が確立されデータが
戻されるまで停止状態になります。p4 protect コマンドを使用して一般ユーザからリモート・ディポを保護し、
減速が起きる場合があることを理解している特定のユーザだけがアクセスできるよう制限することが最善の策です。
結論および推奨事項
可能な限り、分散された開発プロジェクトには単一のPERFORCEインストールを使用してください。
PERFORCEはリモート・ユーザをサポートするように設計されています。地理的に離れた場所にいるユーザが
実際に同じ開発プロジェクトに従事している場合、彼らのコードはすべて、1つのPERFORCEサーバによって
管理されているディポの中に置くべきです。共同開発プロジェクトを別々のPERFORCEインストールに分割しようと
すると、スループットが改善されず、通常は管理が複雑になるだけです。さらに、ネットワークが非常に遅いために、
敏捷で受動的なクライアント／サーバ・アプリケーションであるPERFORCEによってさえ共同開発における問題が
解決できないのであれば、いかなるリモートまたは複数サイトの実装をもってしても、単にネットワークを
アップグレードしたとき以上に生産性を向上させることはできないでしょう。
リモート・ディポを使用して、進行中の作業を他の組織からインポートしてください。
グループBがグループAのプロジェクトの開発に貢献していない場合でも、グループBがグループAの最新の
コードにアクセスする必要があることがあります。このような場合も想定して、組織と組織との間において、
開発ではなくコードを共有するために、リモート・ディポ・サポートは設計されています。
クライアント・ビューおよびアクセス権限を制限してください。インストールに多くのユーザおよび／または
多くのディポ・ファイルがある場合、接続している各ユーザのファイル・ビューを制限することによって、
PERFORCE サーバの応答時間を最適化できます。リモート・ディポを使用する場合は、制限されたディポ・ビューと
共に制限されたクライアント・ビューおよびアクセス権限を使用して、リモート・ディポ検索のローカル・ユーザへの
影響を減少させてください。ユーザは、実際に作業しているディポ・ファイルにビューを制限するように、
自分のクライアント仕様を調整することができます。PERFORCEスーパーユーザは、プロテクションを使用して、
ディポ・ファイルへのユーザ・アクセスを制限することができます。
|
製品情報
戻る