 |
||
|
|
|
| 注意： 本製品は既に生産⁄販売を終了しております。 |
|
インターネット・ニュース・サービスのスケーリング
| はじめに |
インターネット・ニュース・サービスは USENET ニュースとしても知られています。1980 年代の初頭に UNIX コンピュータのユーザに分散型の電子掲示板サービスを提供するために開発されました。任意のサイトに投稿された記事は、一連の UUCP（UNIX-to-UNIX Copy Program）リンクを経由して他のすべてのサーバにフラッドされます。各ホストではローカルのデータベースに記事が保存されるため、そのホストのユーザがメッセージを読むことができ、必要であれば同じメカニズムを使用して応答することができます。
インターネットで UUCP リンクの置き換えが進むに従って、サイト間で記事を交換する新しいプロトコルである NNTP（Network News Transport Protocol）が開発されました。NNTP では、サーバ・ホスト間でのニュース記事の転送に加え、クライアントサーバ・プロトコルが導入されたため、ユーザは UNIX ホストにアクセスして記事を読んだり記事に返信する必要がありません。図 1 は、インターネット上での新しい記事のフローを示しています。
ニュースに関与するインターネット・ホスト数およびクライアントであるリーダ数の両方の増加により、ニュース・サービスをサポートするホストには多くの負担がかかっています。現在、ある大規模なニュース・フィードでは 1 日当たり数十万の記事が配信され、総量にして 1 日当たり約 1 ギガバイトになります。さらに、ニュース・サービスの負荷の処理に加え、数千ユーザに及ぶクライアントへのサービスも頻繁に行われています。
ニュース・サーバのスケーリングとは、ほとんどのシステム管理者にとって、大容量のディスク・ストレージを備えた従来にない高速なマシンを調達する作業になっています。大規模なニュース・フィードおよびリーダ・クライアントの環境では、このアプローチは、必要な量のメモリ、ディスク・ストレージ、CPU キャパシティを備えた単一のホストを購入するという多額の支出に直ちに繋がります。そして、この単一サーバではシングル・ポイント障害が発生するため、冗長ネットワーク接続、冗長 CPU、および冗長ディスク・テクノロジー（RAID [Redundant Array of Independent Disks] など）に対する追加費用が必要です。
幸いにも、NNTP プロトコルでは、リーダ・クライアントへのサービスおよび外部ニュース・ピアへのサービスの両方に対し、複数の低価格サーバを使用してニュース・サービスを分散させる設定を行うことができます。複数のサーバを使用することで重大なシングル・ポイント障害を防ぎ、より多くのリーダ・クライアントや外部ニュース・ピアを環境に追加するようなサービスのスケールが可能になります。
| プラットフォームの仕様 |
問題は、リーダ・クライアントのスケーリングとピア・サーバのスケーリングに分類できます。リーダ・クライアント・サーバは対話型ユーザのサポートを目的とし、ピア・サーバは外部サイトとのニュース記事の交換を目的としています。
このソリューションは、Cisco LocalDirector をパブリック・ドメインの INND（InterNetNews daemon）と一緒に使用することで実現します。INND は NNTP プロトコルの一般的な実装であり、UNIX オペレーティング・システム上で稼働するニュース・サーバ管理ソフトウェアです。
通常、このようなソリューションでは、サーバの完全な複製を作成し、複製されたサーバにクライアントのスケーリングとピア・サーバの負荷を分散させます。したがって、各サーバでニュース記事データベースの完全な複製を保持する必要があります。必要とされるディスク・ストレージは、毎日受信される記事データの量や、記事を保存しておく日数などに直接関係します。
ディスク・ストレージ要求の必然的な増加（従来の例から見て、毎年倍増）のため、オペレーティング・システムの選択が重要です。そのオペレーション・システムでは、あるパーティションに対してパーティションを再構築することなくドライブを動的に追加できるようなファイル・システムをサポートしていることが必要です。この機能がない場合、ニュース・データのパーティションには大量のデータが存在するため、ディスク・ストレージのアップグレードに多くの時間を費やすことになります。
リーダ・クライアントにとってのニュース・サーバとはディスクをきわめて多用するものであり、ディスクへのアクセスはユーザが取得する記事によりランダムに分散される傾向があります。このため、物理的なディスク・ストレージの実装は、一連の比較的小容量のディスクを使う方法が最適です。このシナリオを実現する最も簡単な方法は、複数の物理ディスクを 1 つの論理パーティションとして扱えるオペレーティング・システムを使用することです。1 台または数台の大容量ディスクによる実装では、ディスクのコンテンションによりニュース・サーバのパフォーマンスが低下します。
ピア・ニュース・サービス用のニュース・サーバにも、クライアント・サービスと同様のディスク方式による利点があります。ただし、ピア・サーバでは、ディスク・キャッシング用の大容量のメモリを搭載することによっても利点が得られます。これは、記事が受信されてピア・ニュース・サーバに複製されるときには、ディスクの書き込みや同一データへの複数の読み取りがきわめて近接した場所で行われるためです。また、ピア・サーバでは、外部ピアに記事を配送するまでの間の保持だけに必要な、比較的小容量のディスクを備える場合があります。
リーダ・クライアントのスケーリングニュース・リーダ・ソフトウェア（たとえば、Netscape、Trumpet、rrn、およびその他の多数のソフトウェア）では、ユーザがローカルのニュース・サーバと NNTP を介して相互対話することができます。使用可能なニュースグループを一覧したり、特定のニュース・グループの記事を取得するなどの操作は、クライアントとサーバ間での最も一般的な相互対話です。高機能のリーダでは、NNTP の最新の拡張機能を使用して、特定のニュース・グループ内の全記事の一部分だけを取得できます（たとえば、全記事の「subject」ヘッダを取得するなど）。
図 1：インターネット上でのニュース記事の論理的なフロー
すべての取得操作では、各記事は現在のニュース・グループ内で一意のシーケンス番号で識別されます。このシーケンス番号は、リーダ・ソフトウェアでユーザに読まれた記事を識別するのに使用されます。
非分散サーバのトポロジでは、シーケンス番号はローカル・サーバに固有のインデックスです。このため、ユーザは他のニュース・サーバに切り替えて現在の位置の情報を維持することができません。任意のサーバ上のシーケンス番号は、他のサーバに対しては意味がありません。
したがって、1 人のユーザが多数のニュース・サーバの 1 つを使用できる分散環境に移行するには、サーバ間でシーケンス番号を同期させる必要があります。INND では、NNTP に XREPLIC という非標準のコマンドを追加することにより、この問題を解決しています。
XREPLIC では、ニュース・サーバに 2 つのレベルの階層を導入します。最上位の階層には 1 台のマスタ・サーバがあり、2 番目の階層には多数のスレーブ・サーバがあります。スレーブ・サーバではニュース記事をマスタ・サーバからのみ受信します。マスタ・サーバでは、スレーブ・サーバのグループ内ですべての記事にシーケンス番号を割り当てる責任を負います。シーケンス番号の一貫性はマスタおよびスレーブ・サーバ全体で確立されます。
同一のスレーブ・サーバの組では、LocalDirector を使用してニュース・リーダ・クライアントのサービスをスケールさせることが許可されています。LocalDirector では、発行される記事のシーケンス番号に関係なく、ユーザへの接続の度に最も負荷の低いスレーブ・サーバを選択します。また、LocalDirector では、応答のないサーバを使用可能なサーバの組から除外します。これにより、あるサーバがクラッシュした場合でも、強固なリーダ・クライアントのアクセスが提供されます。
図 2：全ユーザに対して 1 台の大規模ニュース・サーバ
図 3：複数の冗長ニュース・サーバへリーダ・クライアントの負荷を分散
スレーブ・サーバに接続されているユーザは、記事を投稿することもできます。記事のシーケンス番号の一貫性を維持するため、スレーブ・サーバに投稿された記事は単純にマスタ・サーバに渡されます。マスタ・サーバでは、記事にシーケンス番号を割り当て、その記事を自身のローカル・データベースに投稿し、次にすべてのスレーブ・サーバに記事を渡します。
INND のデフォルト設定では、記事をスレーブ・サーバに転送する処理は非デマンド型サイクリック・オペレーションであるため、かなり長い時間を必要とします。この方法は、投稿された記事が直ちにニュース・グループに表示されるのを見ることに慣れているユーザに混乱を与える場合があります。場合によっては、記事が正しく投稿されなかったとユーザが勘違いし、同一の投稿を複数回実行してしまう結果を招きます。この問題は、オプションのパブリック・ドメインである NNTPLINK パッケージを使用することで解決します。このパッケージでは、マスタ・サーバからスレーブ・サーバへのデマンドに基づいた記事の配信がサポートされています。
付録 B-1 では、マスタ・ニュース・サーバに対する INND の設定について詳細に説明しています。付録 B-4 および B-5 ではスレーブ・ニュース・サーバに対する INND の設定について詳細に説明しています。
| 外部ピアのスケーリング |
ユーザへニュース・サービスを提供する大規模サイトでは、そのサイトへのニュース・フィードを 1 つまたは 2 つ程度しか持たず、外部との同位セッションをスケールする必要がありません（図 4）。多くの外部ピアが必要とされる場合、外部サイトとのニュース交換タスク用のサーバを追加することでスケールすることが可能です。
前に説明した「マスタ・サーバ」のトポロジに基づいている場合、専用ニュース・ピア・ホストを容易に追加できます。各ピア・ホストは、マスタ・ホストとの同位セッションを、通常の外部ホストと同様に保持できます。つまり、フィード・ホストは複数の外部サイトとのピアを持つことになります（図 5）。
付録 B-2 および B-3 ではピア・ニュース・サーバに対する INND の設定について詳細に説明しています。
図 4：全外部ピアに対して 1 台の大規模ニュース・サーバ
図 5：外部ピアの負荷を複数のニュース・サーバへ分散
| 障害に関する問題 |
このニュース・サーバのトポロジの実装では、マスタ・サーバがこの分散システムにおいてのシングル・ポイント障害になることが明らかです。ただし、この問題の解決には複数のアプローチがあります。
最初のアプローチは、冗長 CPU および冗長ディスクをサポートしているコンピュータをマスタ・サーバとして選ぶことです。この選択肢は高価になりますが、マスタ・サーバは他のサーバとの相互対話のみを行うため、コンピュータの必要条件は限られたものであり、最大または最高性能のモデルを選ぶ必要はありません。
2 つ目の選択肢は、マスタ・サーバに障害が発生した場合にスレーブ・サーバの 1 台がマスタ・サーバになるように手動で設定する方法です。そのスレーブ・サーバがすでに記事データベースの完全なコピーを保持している場合、このタスクは非常に簡潔な方法となります。この機能に対する特別なプログラムは現在存在しませんが、再設定は完全に自動化されています。
3 つ目の選択肢は、障害期間が短い場合、マスタ・サーバが修復するのをただ待つことです。ニュースを読むユーザにとってマスタ・サーバは必要ないため、ほとんどのユーザはスレーブ・サーバにアクセスします。マスタ・サーバが稼働するまで新しいニュースは到着しません。またユーザが投稿したニュースはスレーブ・サーバに蓄積されます。ニュースの交換は高度な対話型環境ではないため、マスタ・サーバの障害による多少の遅延はユーザに許容されます。
ピア・サーバの障害はニュース・サービスに影響を与えますが、システム全体に対しては重大問題ではありません。ピア・サーバはバックエンドでの記事の転送処理だけに使用されているため、ユーザの相互対話に直接の影響を与えません。障害が起きたサーバで同位セッションが実行されていた場合は、すべてのサイトに明らかな影響が生じます。また、障害が起きたサーバ上で、着信記事のフローの主要な部分がサービスされていた場合、記事の受信にも影響を与えることがあります。ただし、このような場合でも、ニュースのフラッディング・アルゴリズムでは他の経路を介して記事は配信されるため、ニュース記事が失われることはありません。
したがって、ピア・サーバでの障害は、単一のニュース・フィードだけを持つ外部エンド・サイトにのみ影響を及ぼします。この場合、サーバがかなり長い時間にわたってダウンすると予想されると、影響を受けるニュース・フィードでは別のピア・サーバに対して再起動させることができます。
リーダ・クライアント・サーバに障害が発生した場合は、LocalDirector によってそのサーバがプールから除外され、ニュース・サービスの中で最も重要な箇所およびユーザの目に見える箇所を障害から守ります。障害時にユーザがクライアント・サーバを使用している場合、ニュース・サービスに短い中断が生じることがあります。ただし、既存の接続が途切れた場合でも、多くのニュース・リーダでは自動的にニュース・サーバへ再接続するため、LocalDirector によってサービスが障害から復旧されたことにユーザが気付くことはまずありません。
ニュース・サーバのアーキテクチャで、その他に考えられるシングル・ポイント障害は、Cisco LocalDirector です。この問題は、二重化による冗長機能を使用して 2 台の LocalDirector を配置することにより、容易に解決します。
| 要約 |
この文書で説明したアーキテクチャでは、実装が容易で実績のあるインターネット・ニュース・サービスのスケール方式を紹介しています。INND を LocalDirector テクノロジーと一緒に使用することにより、ニュース・サーバのカスタマに強固でハイパフォーマンスなソリューションが提供されます。
このアーキテクチャの下で Cisco LocalDirector を使用することにより、複数の小規模なニュース・サーバの配備や、サーバー間のリーダ・クライアントの負荷を均一に分散ができるようになり、安価なサーバをベースとする大規模なニュース・サービスを非常に費用有効な方法で実現できます。
付録 B-6 では、LocalDirector の設定について詳細に説明しています。
| 付録 A - ソースと参考資料 |
1997 年 5 月の時点での INN の最新バージョンは、バージョン 1.5.1 です。ソース・コードは次のサイトおよびインターネット上の多くのミラー・サイトで参照できます。
ftp.uu.net:networking/news/transport/inn-1.5.1.tar.gz
1997 年 5 月の時点での NNTPLINK の最新バージョンは、バージョン 3.3、パッチ・レベル 2 です。ソース・コードは次のサイトおよびインターネット上の多くのミラー・サイトで参照できます。
ftp.math.ohio-state.edu:pub/nntplink/3.3pl2.tar.gz
INN では、サーバでのコンパイルおよび設定について記述された大量のマニュアルが用意されています。編集には約 10 ファイル、INN をシステム上で稼働することを確認するには最低 15 ファイル以上が必要です。NNTPLINK では、コンパイルおよび INND と一緒に使用するための設定についての明解な説明書が用意されています。
以下の付録で示した設定ファイルの例は、INND と NNTPLINK の上記のバージョンでテストされています。
ニュース・サイトの管理についての大量の情報は、WWW 上で参照できます。FAQ やその他の情報へのアクセスの起点としては、次のサイトが使用できます。
http://sunsite.unc.edu/usenet-b/home.html
現在、ニュース・サーバのインストールと操作に関する参考図書はありません。近く公開される参考資料は、CQ4 '97 で参照できる予定です1。
| 付録 B - 実装例 |
図 6 では、マスタ・サーバ 1 台、スレーブ・サーバ 2 台、ピア・サーバ 2 台、Cisco LocalDirector 1 台、および、Cisco 2900 10/100 Ethernet スイッチ 1 台 での構成を示しています。論理的な記事のフローは、前節で説明したとおりです。
INND ニュース・サーバおよび NNTPLINK パッケージについては、それぞれの配布物の中で詳しく文書化されています。次の設定ファイルは、通常のインストールには含まれていません。
newsfeeds ファイルmaster.xyz.com の newsfeeds ファイルは、ピア・サーバおよびスレーブ・サーバへの記事のフローを制御します。この例では、2 台のピア・サーバ（peer1.xyz.com および peer2.xyz.com）と 2 台のスレーブ・サーバ（slave1.xyz.com および slave2.xyz.com）が設定されています。より多数のサーバも設定できます。
NNTPLINK は、ニュース記事を転送するアプリケーションとして、INND と一緒に提供される nntpsend アプリケーションの代わりに使用されています。これは、記事の転送の遅延を最小化するためです。
newsfeeds ファイルの位置に関係するフィールドは、コロン（：）で区切られています。バックスラッシュ文字（￥）は、継続行を意味します。
さまざまなフィールドにより、どのニュース・サーバがどのニュースグループ階層を受信するかが制御されます（「comp.＊」または「alt.＊」など）。最後のフィールドにより、選択されたニュースグループを他のサーバに配信するために使用するアプリケーションが制御されます。これらの各フィールドの詳細は、INDD のドキュメンテーションで説明されています。
図 6：実装例
次の例では、ホスト「ME」に関する最初の行で指定された振り分けに準じて、master.xyz.com から全ニュースグループが全サーバに伝搬されます。複製の設定は、INND の場合は「R」フラグ、NNTPLINK の場合は「-x」オプションで表されます。
ME\ :*,!xyz.*/world,usa,na,gnu,bionet,pubnet,u3b,eunet,hosts.nntp ファイル
vmsnet,inet,ddn,k12\ :: # Feed all postings to peer servers # peer1.xyz.com\ :*\ :Tc,Wnm:/news/bin/nntplink -k -q\ peer1.xyz.com peer2.xyz.com\ :*\ :Tc,Wnm:/news/bin/nntplink -k -q peer2.xyz.com # Feed all postings to slave servers # Note the R flag for innd and -x option for nntplink # slave1.xyz.com\ :*\ :Tc,WnR:/news/bin/nntplink -x -k -q\ slave1.xyz.com slave2.xyz.com\ :*\ :Tc,WnR:/news/bin/nntplink -x -k -q\ slave2.xyz.com
INND サーバは、接続しているホスト名に準じて、2 つのモードのいずれかで動作します。接続しているホストは、別のニュース・サーバまたはクライアント・ニュース・サーバのいずれかとして扱われます。その動作は、hosts.nntp ファイルの内容によって制御されます。
各ニュース・サーバは hosts.nntp ファイルにリストされる必要があり、オプションでパスワードも設定できます（この例では使用していません）。ホストがリストされていない場合、そのホストが接続されたときニュース・リーダとして扱われます。
peer1.xyz.com: peer2.xyz.com: slave1.xyz.com: slave2.xyz.com:
| B-2「peer1.xyz.com」での INND の設定 |
peer1.xyz.com および peer2.xyz.com という 2 台のホストにより、他のサイトにあるニュース・サーバとニュース記事の交換が行われています。これらのサーバは、master.xyz.com とも記事を交換しています。
peer1.xyz.com によって記事が受信されると、その記事は master.xyz.com に転送され、続いて master.xyz.com から peer2.xyz.com に転送されます。ある記事が peer2.xyz.com によって受信されると、逆方向の処理が行われ、最初に master.xyz.com へ、そして peer1.xyz.com へ転送されます。この設定により、各サーバで各記事のコピーが受信されます。
master.xyz.com と同様に、2 台のピア・サーバでは INND と NNTPLINK が実行されています。
次の例では、peer1.xyz.com に対する設定を示しています。このサーバでは 2 台の外部サーバ external.company-a.com および external. company-b.com との間でニュースの同位セッションを保持しています（実際には、命名規約により、おそらくこれらのホストは news.company-a.com および news.company-b.com と呼ばれます）。
newsfeeds ファイルでは、企業 A では「comp」および「alt」の新規階層だけを受信することを選択し、企業 B では「rec」、「linux」、「gnu」、および「misc」の階層だけを選択していることを示しています。これらの選択はそれぞれのサイトの管理者によって行われたもので、おそらくディスク・ストレージやネットワーク帯域幅に基づいて選択されています。
newsfeeds ファイルでは、送信されるものだけを制御し、受信されるものは制御しないことに注意してください。ピア・サーバ上の設定を調整し、希望する階層だけが外部サーバからピア・サーバへ送られるようにすることは、外部ホストの管理者の責任です。
newsfeeds ファイルME\ :*,!xyz.*/world,usa,na,gnu,bionet,pubnet,u3b,eunet,vmsnet,inet,ddn,k12\ :: # Feed selected postings to external servers # external.company-a.com\ :comp.*,alt.*\ :Tc,Wnm:/news/bin/nntplink -k -q\ external.company-a.com external.company-b.com\ :rec.*,linux.*,gnu.*,misc.*\ :Tc,Wnm:/news/bin/nntplink -k -q\ external.company-a.com # Feed all postings to master server # master.xyz.com\ :*\ :Tc,Wnm:/news/bin/nntplink -k -q\ master.xyz.comhosts.nntp ファイル
マスタ・サーバと同様に、peer1.xyz.com に接続するニュース・サーバ・ホストだけが hosts.nntp ファイルに記述されます。
master.xyz.com: external.company-a.com: external.company-b.com:
| B-3「peer2.xyz.com」での INND の設定 |
完全を期すために、peer2.xyz.com 上の newsfeeds ファイルおよび hosts.nntp ファイルは次のように取り込まれます。これらのファイルは、ホスト名と階層の選択を除いては、peer1.xyz.com のファイルと同じです。
newsfeeds ファイルME\ :*,!xyz.*/world,usa,na,gnu,bionet,pubnet,u3b,eunet,hosts.nntp ファイル
vmsnet,inet,ddn,k12\ :: # Feed selected postings to external servers # external.company-c.com\ :bit.*,misc.*\ :Tc,Wnm:/news/bin/nntplink -k -q\ external.company-c.com external.company-d.com\ :comp.*,humanities.*,misc.*,news.*,rec.*,\
sci.*,soc.*,talk.*,\ :Tc,Wnm:/news/bin/nntplink -k -q\ external.company-d.com # Feed all postings to master server # master.xyz.com\ :*\ :Tc,Wnm:/news/bin/nntplink -k -q\ master.xyz.com
master.xyz.com: external.company-c.com: external.company-d.com:
| B-4「slave1.xyz.com」での INND の設定 |
slave1.xyz.com および slave2.xyz.com の 2 台のスレーブ・サーバでは、すべてのクライアント・ニュース・リーダにサービスを行うタスクが実行されます。これらのサーバのデータベースは master.xyz.com のデータベースの完全な複製です。
スレーブ・モードの INND では、投稿された記事はユーザからマスタ・サーバへ遅延することなく直接リレーされるため、これらのサーバには、NNTPLINK をインストールする必要はありません。
これらのサーバは他のマスタ以外のニュース・サーバとは記事の交換をしないため、設定ファイルは非常に短いもので、マスタがすべての階層選択を制御します。
newsfeeds ファイルME\ :*\ :: # Entry for just us # slave1.xyz.com\ :!junk\ :Tf,Wnm:hosts.nntp ファイル
このスレーブ・サーバにニュース記事を送ることができるのはマスタ・サーバだけなので、この hosts ファイルには、マスタ・サーバの名前だけが書き込まれています。
master.xyz.com:rc.news ファイル
rc.news ファイルを経由して INND が起動される場合、各スレーブ・サーバがスレーブ・サーバとして振る舞うように特別に設定される必要があります。これを行うには、rc.news ファイルの「FLAGS=」行に「-S」オプションを追加し、そのオプションの後にマスタ・サーバの名前を記述します。
次の行を例にします。
FLAGS="-i0"
この行を次のように修正します。
FLAGS="-Smaster.xyz.com -i0"
（この振り分けにすでに指定されている「-i0」オプションは、接続されるクライアントの数に制限がないことを指定するものです。）
| B-5「slave2.xyz.com」での INND の設定 |
完全を期すために、slave2.xyz.com 上の newsfeeds ファイルおよび hosts.nntp ファイルは次のように取り込まれます。これらのファイルは、ホスト名を除いては、slave1.xyz.com のファイルと同じです。また、前述したように、rc.news ファイルも修正します。
newsfeeds ファイルME\ :*\ :: # Entry for just us # slave2.xyz.com\ :!junk\ :Tf,Wnm:hosts.nntp ファイル
master.xyz.com:
| B-6 LocalDirector の設定 |
LocalDirector では、クライアントのニュース・リーダの負荷をスレーブ・サーバ間に分散させる処理を行います。
この例では、LocalDirector により slave1.xyz.com（10.1.1.11）と slave2.xyz.com（10.1.1.12）との間で負荷が分散されています。仮想サーバには IP アドレス 10.1.1.99 が割り当てられており、さらにこのサーバは「news.xyz.com」のような適切なドメイン名に割り当てられています。次に、クライアントで「news.xyz.com」を使用できるようにクライアント・ソフトウェアを設定します。
syslog output 20.6 syslog host 10.1.1.2 enable password localdir hostname director ip address 10.1.1.254 255.255.255.0 real 10.1.1.11 is threshold 10.1.1.11 8 real 10.1.1.12 is threshold 10.1.1.12 8 virtual 10.1.1.99 is sticky 10.1.1.99 0 predictor 10.1.1.99 leastconns bind 10.1.1.99 10.1.1.11 10.1.1.12 interface ethernet 0 10baseT interface ethernet 1 10baseT ip route 0.0.0.0 0.0.0.0 10.1.1.1 0 no rip failover
1Lawrence, David and Henry Spencer. Managing USENET. O'Reilly Associates（www.ora.com）; 1997（est. August）; 1-56592-198-4, order number 1984, $32.95（est.）.
| 更新日：2001 年 8 月 27 日 |
