第 2部
ライフラインとしてのインターネット に関
する考察

21

第 1章はじめに
ライフラインワーキンググループの活動は，1995 年の阪神淡路大震災を契機に，イン
ターネットの社会基盤としてのインターネットの役割，特に災害時のインターネットの役
割を中心に検討を行っている．
社会的なインターネットの関心は高くなっており，それにつれ，インターネットの社会的な役割も益々重要なものとなってきている．昨年に続き第２回「 インターネット災害訓練」を 1997 年 1 月 17 日に行った．インターネット災害訓練は被害をいくつか想定し，あらかじめ対策を検討し，さらに，実際に行動することの対策として訓練を行なうというものである．訓練の目的は，つぎの通り：

 訓練を通して経験をつみ，システムにその知識を反映することで，実用的なシステムを構築する．

 インターネットのオペレータが，ネットワーク障害時の復旧手順をトレーニングすることで，災害時の対応をよりスムーズに行なう．

 インターネットコミュニティに「 インターネットと災害」について，考えてもらう機
会をつくる．
第 2 回の「 インターネット災害訓練」では，第 1 回と同様に，生存者情報に関する訓練を中心に行った．今回は，この訓練を中心に報告する．
WIDE プロジェクトでは，引続き，社会情報基盤としてのインターネットを技術的，運用的側面から見直し，社会基盤としての可能性とそれを実現するための課題を整理し検討していく．また，災害時におけるインターネットの役割についての検討を進め，1997 年度
も，インターネット上での災害訓練を実施することで，問題意識のインターネットコミュ
ニティへの問題意識の喚起，実用的なシステムの研究・開発を進めていくつもりである．

23

第 2章
第 2 回訓練について
2.1

全体概要

昨年度 (1995 年度) の WIDE プロジェクト研究報告書で報告したように 1996 年 1 月 17日，18 日の 2 日間にわたって，第 1 回のインターネット災害訓練を実施した．その内容は「障害時の通信衛星によるインターネットバックボーンの迂回路の設定訓練」，および「生存者情報データベースへの登録および検索訓練」であった．
今年度 (1996 年度) は，訓練内容を「生存者情報データベースへの登録および検索訓練」に限定し，訓練期間も 1997 年 1 月 17 日の 1 日間としてインターネット災害訓練を行なった．本章では，この第 2 回インターネット災害訓練について述べる．

2.1.1

訓練の内容

生存者情報データベースは被災者の生存情報に関するデータベースである．これは，被災地で生存情報を登録し，名前などをキーにして被災地外部から生存情報を検索をするためのシステムである．
本システムでは，電子メール，または WWW で登録および検索ができることをめざした．これは，インターネットユーザが自ら被災者および，その関係者となったことを想定して，その状況の登録および検索を行なうといったものである．

2.1.2

第１回訓練との相違

基本的な訓練内容は第 1 回と，ほぼ同様だが，第 1 回の訓練で得られた経験を踏まえ，システムの改善，強化をおこなった．おもな改善点はつぎの通りである．

1. 通信衛星によるデータベースサーバ間通信「生存者情報データベース」はシステムの部分的な障害に対しても丈夫なように分散データベースによって構築されているが，今回はこれらサーバ間の通信の一部をマルチキャストを利用して，通信衛星を用いた．

24

第 2部

ライフラインとしてのインターネット に関する考察

25

2. サーバの選択方式の改善
サーバやサーバにいたる通信経路に障害があった場合，クライアントは他の通信可能なサーバに通信を切り替える機構が必要である．前回は DNS(ド メイン名システム)と呼ばれる機構を用いたが，今回はそれに加えて，インターネットプロトコルレベ
ルでのサーバ選択機構も導入した．より細かい負荷分散やサーバ選択の実現をめざした．

3. 入力インターフェースの改善

前回は問い合わせ結果を伝える手段として電子メイルを用意したが，今回は WWW
によるインタフェースも用意した．これにより，電子メイルや WWW による登録・検索を実現した．

4. 情報管理 (システムサポート ) 機構の改善登録された情報を適切なものに維持するためには，オペレータによる介入が不可欠である．前回の訓練では，このオペレータに大きな負荷がかかることが分かった．今回
は，このオペレータの作業効率を改善するためのサポート機構を用意した．

5. 特定地域の被災を想定しての情報入力
第 1 回の訓練では，その参加者をインターネットのユーザとし，ユーザが接続している環境からの情報の登録や検索を行なった．今回は，インターネット機器および衛星通信機器を搭載した「 インターネットカー」を，想定した被災地に出動させ，被災地からの情報発信および検索の訓練も合わせておこなった．
また，日本電信電話 (株) からは「 インターネットカー」，日本シスコシステムズ (株) からは 「 LocalDirector 」の提供，また，(株) 東京テレポートセンター (TTC)，日本電子計算 (株)，情報技術開発 (株) からは，機器や設置場所等の提供を頂いた．なお，衛星回線のバックアップには，(株) 日本サテライトシステムズ の JCSAT-1 衛星，および日本電信電話 (株) の N-STAR 衛星を利用させて頂いた．
IAA システムについて

2.2

第 2 回訓練において構成された IAA システムについての概略をここで述べる。IAA シ
ステムは，全国 6 ヶ所に配置された IAA サイトが協調して運営した．
2.2.1

IAA サイト

IAA サイトは，以下の理由から分散して配置された．

 負荷の分散

各 IAA サイトで高速な計算機を運用し，高速な IAA 情報の登録・検索を実現する．

26

1996 年度 WIDE 報告書

 ネットワーク分断・停電等の危険回避

災害発生時において IAA システムを一ヶ所の IAA サイトで運営すると，ネットワー
ク分断・停電等の不測に対するリスクが高い．それを回避するため，IAA システムはできる限り複数の地点で同じサービスが提供できるように構築した．

IAA サイトは，TTC(東京テレポートセンター)・東京工科大学・九州大学・WIDE プロ
ジェクト京都 NOC・北陸先端科学技術大学院大学 (JAIST)・奈良先端科学技術大学院大学(NAIST) の 6 ヶ所で運営した．
これらのサイトで，用意された計算機台数を表 2.1 示す．
IAA サイトTTC

計算機数
PC 3 台WS 6 台PC 2 台WS 2 台PC 3 台2
東京工科大学2
2
京都 NOC2
2
九州大学
WS 2 3 台
PC 2 2 台
JAIST
WS 2 31 台
PC 2 2 台NAISTWS 2 13 台
PC 2 2 台

WS: UNIX ワークステーション
PC: PC-UNIX パーソナルコンピュータ
表 2.1: 各 IAA サイトで用意された計算機数

2.2.2

IAA サービス

今回の訓練において，提供されたサービスは以下の通りである．

 WWW による IAA 訓練参加方法等の説明
 WWW による IAA 情報登録・検索
 電子メール による IAA 情報登録・検索第 2部

ライフラインとしてのインターネット に関する考察

27

これらのサービスをそれぞれのサイトで分担して提供した．分担内訳を，表 2.2 に示す．
分担内容に偏りがあるのは各サイトで用意した計算機の台数や，計算処理能力に応じて提供するサービスを変化させたからである．
また，各地の IAA サイトで登録された IAA 情報を，全国の IAA サイトに分配するため
NNTPlink を利用したネットワーク網と，衛星を利用したマルチキャスト網を構成した．衛星を利用したマルチキャスト網は 2.4で述べる．NNTPlink を利用したネットワーク網を，
図 2.1 に示す．今回は，衛星を利用したマルチキャスト網を活用するため，地上ネットワー
クは図に示すような変形スター型接続とした．

IAA サイト
TTC

IAA 情報入力法の説明 WWW 登録 WWW 検索 E-mail 登録 E-mail 検索
o
o
o
x
x
東京工科大学oooxx
京都 NOC
o
o
o
x
x
九州大学
o
x
x
x
x
JAIST
o
o
o
o
o
NAIST
o
o
o
x
x
表 2.2: 各 IAA サイトで提供されたサービス

KYUSYU

JAIST

KYOTO

TTC
NAIST
HACHIOJI

図 2.1: IAA サイト NNTPlink 構成

28

1996 年度 WIDE 報告書

2.2.3

IAA クラスタ

IAA システムを構成するプログラムのことを IAA クラスタと呼び，次のように 4 つの機能系がある．

 入力部
電子メールや WWW によって，IAA 情報が記入され登録要求・検索要求を受け付ける処理系．被災者から発信された情報を，蓄積部で受け付け可能なフォーマットに変
換する．

 配送部
ある IAA サイトで受け付けられた IAA 情報を他のサイトに配送する処理系．本シス
テムでは複数の IAA サイトで運営されている IAA 情報蓄積部のデータを一致させる必要がある．情報配送時には暗号処理をするなど，IAA 情報の漏洩防止に細心の注意が払われた．これは，IAA 情報に個人情報が含まれている可能性が高いからである．

 蓄積部
IAA 情報を効率良く検索できるよう蓄積する処理系．IAA 情報から検索用のインデッ
クス情報を作成してデータベース化する．今回の訓練では，2 種類のデータベースが利用された．

 検索部
検索者が入力した検索条件から，蓄積部に対して検索要求を出し，検索者に対して検索結果を提示する処理系．IAA 情報が悪用されないように，検索条件には被検索者を特定する条件（姓 または 名）が入力されていないと検索結果を返さない仕様とした．

2.3

データベース

データベースエンジンには，前回の訓練と同様，Oracle を用いたものと，C によってコー
ディングされた独自のデータベースを用いた 2 つの実装を用いた．両方のデータベースともに，TCP/IP 通信による共通のインターフェース仕様を持ち，これによって IAA の他のモジュールから登録・検索がおこなわれる．
データベースエンジンは，ふたつのポートをもち，一方は登録用ポート，他は検索用ポートである．
レコードを登録を行うには，登録用ポートに接続し，そのレコードを送る．各レコードには，データベースエンジンごとに固有のレコード ID が付与される．レコード を検索す
るには，登録用ポートに接続する．まず，検索キーをエンジンに送ると，該当レコード 数とそれぞれのレコード ID のリストが返送される．レコード の内容を知るには，レコード
ID を検索ポートに送ればよい．

第 2部

ライフラインとしてのインターネット に関する考察

29

以下にレコード 形式と各プロトコルの概略を述べる．ど ちらのプロトコルも FTP や
SMTP のようにテキストベースで，コマンドに対する反応も 3 桁の数字を用いたステータ
スコードを返す．
2.3.1

登録プロト コル
クライアントtag: value nntag: value nn
.nn

2.3.2

(データの流れ ) サーバ
connect 0!
0(if error)
500 cannot create db le nn

0!
0!
0!
0

status202 registration success nn
501 registration fail nn

検索プロト コル接続
クライアント(データの流れ ) サーバ(connect) 0!
0 (greeting) 200 IAA search engine nn

検索
クライアントSEARCH=IAAnn
TAG="VAL"nn
TAG="VAL"nn
TAG="VAL"nn( maxcount=数字 ).nn(データの流れ ) サーバ

0!
0
0!
0!
0!
0!
0!
0

300 search keys are required nn

status200 存在するレコード 数 今回返すレコード 数
500 0 0 nn

301996 年度 WIDE 報告書

レコード の取得
クライアント

get id id ... id nn

クライアントquit nn

2.3.3(データの流れ ) サーバ

0!
0
0
0
0

200 id nn
終了
TAG: VAL nn
TAG: VAL nn.nn(データの流れ ) サーバ0!
0

200 byeレコード 形式

登録レコード の形式を表 2.3に示す．

2.4

衛星を用いたデータ転送

2.4.1

アーキテクチャ

今回，通信衛星 (JCSAT，N-STAR) を用いて，生存情報の交換を行った．JCSAT は，その同報機能を活かして，データベース間の情報の交換に，N-STAR は，ポイント・ポイン
トの通信機能を活かして，情報データベースと端末装置間の通信として利用した．ここでは，通信衛星を用いたデータベース間の情報交換の機能について説明する．

IAA では，データベース間の情報の交換を行う，トランスポート機能としてニュースシ
ステムを利用していることは既に説明した．ニュースシステム間の情報は，ニュースシス
テム間に張られた疑似的なネットワークを NNTP(NetNews Transfer Protocol) を用いて疑似的にマルチキャスト通信を行うことより交換される． 通常，ニュースシステム間はインターネットを介して接続される．インターネットのほとんどは専用線 (地上網) によって，構成されており，災害時には特定地域の孤立化や，インターネットの極度の輻輳状態が予想される．
そこで，これらの問題を解決する方法として，ニュースシステム (innd) 間通信の衛星によるバックアップを今回実現した (図 2.2)．
これは，地上網の切断に対応するだけでなく，通信衛星のマルチキャスト機能を利用することにより，ニュースサーバ間の効率的な情報交換および地上網の負荷低減を図ることができる．
インターネットで衛星通信を利用する方式としては，WIDE プロジェクトの WISH のよ
うに，衛星通信と地上網を併用することによる方式があるが，今回の実験では，災害時の第 2部

ライフラインとしてのインターネット に関する考察

31

入力項目名

フィールド 名型

備考

(システムが付与)(システムが付与)(システムが付与)(システムが付与)(システムが付与)(システムが付与)

iaakey
iaaid
itype
score
rdate
optr
lname
lyomi
fname
fyomi
agel
ageu
sex
btype
zip
addr1
addr2
addr3
stat
sdate
splacehow
reptr
relatenote

number(10)char(128)char(128)
number(3)number(10)char(255)
char(128)char(128)char(128)char(128)
number(3)number(3)number(1)number(1)char(8)char(128)char(128)char(255)
number(1)number(10)char(128)
number(1)char(128)
number(1)varchar2(512)NOT NULL PRIMARY KEYNOT NULL UNIQUE
DEFAULT \"DEFAULT 0
DEFAULT 0
DEFAULT \"DEFAULT \"DEFAULT \"DEFAULT \"DEFAULT \"DEFAULT -1
DEFAULT 999
DEFAULT 3
DEFAULT 9
DEFAULT \"DEFAULT \"DEFAULT \"DEFAULT \"DEFAULT 3
DEFAULT 0
DEFAULT \"DEFAULT 2
DEFAULT \"DEFAULT 4
DEFAULT \"akeyidakey
iaakeynumber(12)char(255)
number(10)nickidnick
iaakeynumber(12)char(255)
number(10)NOT NULL UNIQUENOT NULLNOT NULLCONSTRAINT fk iaa97 akey REFERENCES iaa97
ON DELETE CASCADENOT NULL UNIQUENOT NULLNOT NULLCONSTRAINT fk iaa97 nick REFERENCES iaa97
ON DELETE CASCADE

名
名の読み
姓
姓の読み
年齢 (下)
年齢 (上)
性別
血液型
郵便番号
住所 1
住所 2
住所 3
状況
状況確認日時
状況確認場所
状況確認方法報告者
属柄備考

ANYKEYANYKEYANYKEYANYKEYANYKEYNICKNAMENICKNAMENICKNAMENICKNAMENICKNAME

表 2.3: IAA のデータベーススキーマ

321996 年度 WIDE 報告書

Communication
Satellite

Spool

Spool

Spool

innd

innd

innd

IaaDB

IaaDB

IaaDB

The Internet(Surface)ll-ss-fig0

図 2.2: 衛星によるバックアップ

第 2部

33

ライフラインとしてのインターネット に関する考察

地上網の切断を想定して，地上網を用いない方式を採用した．さらに，通信衛星に送信できない受信専用局が多く発生することも想定して，完全一方向通信・マルチキャスト通信によるファイル転送機能を新規に開発した．そのシステム構成は次の通りである (図 2.3)．
nntp

nntp
CS

innd

news2mc

udsendudrecv

mc2news

News
Spool

innd
News
Spool

ll-ss-fig1

図 2.3: システム構成
ここで，innd は ニュースサーバである．地上網によって到達した新規のデータは news2mc(newsto multicast) プログラムにより完全一方向ファイル転送プログラム udsend に送られる．udsend は 通信衛星を介して，対向する複数の受信プログラム udrecv に対して，マルチキャ
ストによってデータを配送する．受信したデータは mc2new(multicast to news) プログラ
ムにより，ニュースシステムに送られる．
udsend と udrecv 間は 一方向通信のため，途中でデータ一部に転送誤りがあっても，
udsend はそのことを知ることができない．そこで，

 ファイルを反復的に再送する．
 ファイルを小さなサイズに細分化して送る．受信側は細分化したデータを個別に記憶しておき，すべてがそろったところで受信完了とする．すなわち，一部のデータに転送誤りがあっても，そのデータだけが，再送さればよい．
という方式をとった．
2.4.2

評価・考察

以上のシステムを用いて訓練時に，どの程度の記事が衛星経由になったかを各 IAA クラス
タで測定した (表 2.4)．なお，今回衛星を使った IAA クラスタは NAIST(送信局)，JAIST，
京都 NOC，八王子 NOC，TTC である．
結果からわかるように，それほど多くの記事は衛星経由になっていないことがわかる．本
来は地上網での転送は少し時間をずらして (遅延配送)，衛星を優先させるはずであったが，ニュースシステムの設定の間違いにより，同時に配送を行ったためほとんどが地上網を経由してしまった．

34

1996 年度 WIDE 報告書

IAA クラスタ 割合 (%)
JAIST
0:30
京都
0:90
八王子
13
TTC
7:0
表 2.4: 衛星経由の記事の割合

八王子では他のサイトに比べ比較的多くの記事が衛星経由になっているが，これは地上網が混雑していたためと考えている．このことから考えて，正しい設定 (地上網側を遅延配送) であれば，さらに多くの記事が衛星経由になったと考えられる．
今後，機会があれば追試を行いたいところである．

2.5

ユーザインターフェース

IAA 情報の登録と検索のユーザインターフェースは，被災者自身，もしくは被災者の関係者など，不特定多数の人々が利用する．前回の第一回災害訓練のユーザインターフェース
は，一般の人々に使いやすいものではないという指摘や，パニック時に複雑な登録作業を行なうことができるのか，という疑問，グループや家族をまとめた登録の要望などがあった．これらをふまえ，今回はより多くの人が確実に利用できる環境を提供するために，つぎのような検討を行なった．
入出力手段
登録対象
ユーザのスキル
回線の太さ:

WWW, 電子メール, PDA, ゲーム機, InternetTV, 電話などの

:
:
:

利用
個人, 家族, 学校, 職場, 不特定多数の集団への対応
ユーザのスキル別のサービス
ユーザの利用する回線の太さ別のサービス

このうち今回の訓練で実現することができた IAA システムのユーザインターフェースについて述べる．

 WWW, 電子メール による登録/検索を実現した．登録と検索に主に利用されたアドレスをつぎに示す．

http://www.iaa.wide.ad.jp/touroku/
http://www.iaa.wide.ad.jp/kensaku/
touroku@iaa.wide.ad.jp

WWW 登録インターフェース
WWW 検索インターフェース
電子メール登録インターフェース

第 2部

ライフラインとしてのインターネット に関する考察

kensaku@iaa.wide.ad.jp

35

電子メール検索インターフェース 入出力手段では WWW を主なユーザインターフェースとした．前回と異なり，WWWで検索した結果をメールで受けとるのではなく，検索したその場ですぐに結果を見せるようにした．メールアドレスを持たないユーザも検索できるとともに，システムが動作しているという安心感をユーザに与え，ユーザの不要なアクセスを防ぐことができると考えた．

 ユーザのスキルにあわせて，複数のユーザインターフェースを提供した．ユーザをIAA システムのユーザインターフェース利用の習熟度によって三つのカテゴ リ (初級/一般/上級) に分類した．習熟している上級利用者は手早く，習熟していない初級

利用者は多少時間がかかっても間違いを少なくすることができると考えた．ユーザの分類と，それぞれにどのようなユーザインターフェースを提供するかを，表 2.5に示
す．今回は WWW は一般用と上級用，電子メール は初級用，一般用，上級用を提供
し，電子メール のフォーマットは WWW, 電子メール 経由で取得可能にした．
カテゴ リ

人物象

考慮する点

初級

普段計算機を使わない

一般

ある程度計算機を利用していてアンケート等に回答したことがある（前回の参加者）

何も知らなくても使えるよ
うにする，各項目の丁寧な説明と記入例が必要
一項目 2,3 行の説明と簡単な記入例が必要

上級

IAA システムをよく理解し， フォーマットは省略形，説何度か IAA 情報を入力した 明も少なくてよいことがある
表 2.5: IAA システムユーザの分類と UI で考慮する点

WWW による一般用の IAA 情報登録画面を，図 2.4 に示す．ユーザが効率よく説明を見ながら入力できるようにするために，各項目をクリックすると，それに関する説
明が画面下に表示される．入力例などは，画像データを使わずに作成されている．これは，災害時にネットワークの負荷をかけないように配慮したためである．また，検索結果に表示される項目は赤で表示し，この情報が公開される可能性があることを説明している．これはユーザが知らずに，プライバシー情報を公開してしまうことを防ぐためである．

36

1996 年度 WIDE 報告書

図 2.4: 一般用 IAA 情報登録画面

第 2部

ライフラインとしてのインターネット に関する考察

37

残念ながら今回の訓練には間に合わなかったが，つぎのようなユーザインターフェースを提供する試みも行なっていた．
電話による入力 入出力手段では，電話を用いた登録方式を実現した．これは，電話で音声ガイダンスにしたがって，数字キーを使って入力するもので，特別な装置を使わずに，
IAA 情報が登録できる．姓名など文字を入力する場合は，ページャで平仮名を出す
ときに一般的に使われている方法を使う．Phone-Shell WG の成果を利用している．
グループ登録 登録対象として，不特定多数の集団を扱うためのインターフェースの実現を試みた．これは表計算ソフトを使って IAA 情報の収集を行ない，一括して登録しようとするものである．この方法によれば，ボランティアが避難場所や地域で，携帯型計算機を片手に IAA 情報を聞き回って収集し，インターネットカーで一括登録を行
なう，という流れが可能である．災害時に様々な情報収集を行なうボランティアや学校などによって，有効に利用されることで，今まで IAA システムと接点のなかった，
多くの人々の IAA 情報の登録が可能になるであろう．ただし，学校などで組織的に登録する場合には，プライバシーを十分考慮する必要がある．データ形式としては
CSV 形式を用いる．これは多くの表計算ソフトで利用可能で，かつテキスト形式なので扱いやすい．
今回の訓練では，多様なユーザインターフェースの試みが出てきた．それぞれが，どの程度有効に使われたかは不明だが，末端ユーザに身近なユーザインターフェースを取り込
んでいくことは今後も必要であろう．FAX や InternetTV など ，機能が限られたユーザイ
ンターフェースで，いかに操作するかなども考える必要がある．そのためには，様々な人が，新しいユーザインターフェースを簡単に追加できる枠組が必要である．

2.6

広域負荷分散災害時に役立つ情報に代表されるような大多数の利用者から注目される情報を取り扱う
分散情報サービスを考える場合，規模拡大性 (scalability) の問題は避けて通れない重要な課題である．World Wide Web [?] をはじめとする分散情報サービスでは，規模拡大性を満足できない要因として，以下の二つが考えられている．

 情報を提供するサーバの処理能力の上限
 情報が伝送されるネットワークの帯域幅，伝送遅延
そこで規模拡大性の問題を解決する手段として，以下の技術が，これまでに提案・実装
されている．
サーバ複製 (serverreplication) 技術 同一の情報を扱うサーバをサーバ単位で複製する
ための技術

38

1996 年度 WIDE 報告書

サーバ選択 (server selection) 技術 同一の情報を提供する複数サーバ間から利用者にとり「最善」のサーバを選択する技術
サーバリダイレクト (server redirection) 技術 単一の IP アドレスや URL [?] を用いて同一の情報を扱うサーバ集合を単一の仮想サーバとして利用者に見せかける技術
キャッシュ (cache) 技術 繰り返し利用されると予想される情報を利用者に十分に身近な
ネットワーク近傍に一時的に複製，蓄積することによって，伝送遅延を見かけ上減少させる技術
こうした広域負荷分散の構築技術は，日常時に十分に役立つ技術である一方で，災害時においても重要な役割を担うと考えられる．
以下では第 2 回インターネット災害訓練において利用した広域負荷分散手法について述べる．さらに，その問題点および次回訓練に向けた広域負荷分散機構の課題に関して触れる．
2.6.1

設計

第 1 回訓練では DNS を用いて負荷分散をおこない，均等に負荷を分散した．これはすべてのクラスタが同一の構成 (性能) を持っていたため，正しく分散されたと言えるが，一般にすべてのクラスタが同一の性能を持っているとは考えられない．また，分散機構とは別に，各クラスタの性能不足が指摘された．
このような経験をもとに第 2 回 IAA システムの設計会議で示されたシステムの基本設
計方針は次のようなものとなった．

1. サーバ計算機を可能な限り数多くクラスタへ組み込む
2. 計算機はクラスタを構築するサイトが調達する
3. クラスタは IAA システムの提供する全てのサービスを提供する必要はない
このような方針が策定された背景として，第 1 回訓練時に利用されたサーバ計算機の処理能力の低さに対する強い改善要求や，ライフラインワーキンググループが提供可能な計算機数の限界，システム実装者ならびに運用者が少数である理由からシステムが提供する全サービスを地理的に分散配置された全てのクラスタで維持管理できないという理由がある．
そこで第 1 回訓練時とは異なり，第 2 回 IAA システムで必要とされる広域負荷分散機
構は，広域から同時多発的に発生するサーバアクセスをクラスタやサーバの処理能力と同比率で分散させる機能が求められることになった．
また，クラスタ内負荷分散を提供するクラスタと提供しないクラスタが混在する状況への対応も求められた．
上記の要求仕様を満足するように，特別な機材を利用しない形で広域負荷分散機構を実装することを考えて，第 1 回と同様に DNS を利用するアプローチを取ることにした．DNS
アプローチでは特に次のような点に留意して設計に取り組んだ．

第 2部

ライフラインとしてのインターネット に関する考察

39

 地理的に分散したサイトに設置されるクラスタの情報は，クラスタ管理者に DNS の
資源情報管理を任せる．

 クラスタ内負荷分散が実装されているクラスタでは，サービス一つにつき一つの仮想
IP アドレスを分散する宛先として利用する．クラスタ内負荷分散が実装されていな
いクラスタでは，サーバ計算機の IP アドレス全てを宛先として利用する．

 負荷分散処理のために均等に資源レコードを応答するラウンドロビン処理しか実装していない DNS サーバを用いて，均一な情報を持ち不均一な処理能力を持つサーバ群を対象に負荷分散する．

 負荷分散の対象となる全てのサーバのハードウェア構成情報ならびにオペレーティン
グシステムのバージョン情報は，広域負荷分散機構に予め知らせることができる．

 DNS の情報更新時における伝搬遅延を少しでも小さくするために，広域負荷分散に関係する DNS の資源レコード のキャッシュ有効期間は，比較的小さな値とする．

 IAA システムが提供するネットワークサービスごとに論理サービスホスト名を定義し，その論理サービスホスト名のみを訓練参加者側へ公開する．広域負荷分散機構は論理サービスホスト名に写像されるサーバの IP アドレスやサーバ名を負荷分散ポリシーにのっとって DNS の名前解決の手順を通じてシステムや利用者へ通知する．論
理サービスホスト名として次のものを用意する．

訓練ホームページ提供ホスト
登録サービス提供ホスト
検索サービス提供ホスト

www.iaa.wide.ad.jp
register.iaa.wide.ad.jp
query.iaa.wide.ad.jp

また，本機構の設計では，新たにバランス値とバランスパラメータという二つの概念を導入した．
バランス値とは，システムが提供する特定のサービスを支える全てのサーバ数を合計した数値を分母とし，個々のサーバ処理能力の相対的な値を分子とする数値である．
バランスパラメータとは，バランス値の分子を決定する際に考慮されるサーバ処理能力の目安の情報を指す．
本機構のアーキテクチャを図 2.5 に示す．広域負荷分散機構 (Wide-Area load-balancer)
は，クライアントから要求される論理サービスホスト名の名前解決時にバランスパラメー
タ (information of balance parameters) の情報にもとづいて実サービスホスト名を応答する．Query とラベルされた線は論理サービスホスト名の検索要求を意味している．また，
Response とラベルされた線は広域負荷分散機構がクライアントへ応答する実サービスホ
スト名である．この情報は広域負荷分散機構が定めるある一定時間の間，クライアントのネットワーク近傍にキャッシュ情報として記憶される．また Response とラベルされた線

40

1996 年度 WIDE 報告書が太いほど ，応答回数の多い実サービスホスト名であることを示している．あるクラスタ(Cluster) への Response の線が複数本数伸びている理由は，広域負荷分散機構によってクライアントへ通知される実サーバホスト名が一クラスタあたり複数提供されているためである．すなわち，広域負荷分散機構が応答する実サービスホストの対象は，「 Wide-Areabalanced objects 」でラベルされた 2 番目の層に属するものだけである．
C

DNS

Query
A

Information ofbalance parameters

DNS

Wide-Area load-balancer

C
DNS

H
Users
Wide-Areabalanced objects

DNS

E
Response
Cluster

Cluster

Response

Response
Cluster

Cluster internalbalanced objects

Cluster

ClusterContent-equivalent servers
Query: query with logical service nameResponse : response with real service address
Content-equivalent servers

Cluster internal load-balancer

図 2.5: IAA 広域負荷分散モデル

2.6.2

実装

広域負荷分散機構の実装は，IAA システムが所属する iaa.wide.ad.jp ゾーン情報を記述する際に， A レコードと CNAME レコード のエントリを複数記述することで実現した．
また，クラスタやサーバの追加削除のイベントが発生するたびに，連絡を受けた DNS 管
理者が DNS のゾーン情報を修正することで動的に負荷分散のバランス情報の更新をおこなった．ゾーン情報を記述するにあたって，注意した点は以下の通り:

1. DNS ゾーン情報の管理方式
iaa.wide.ad.jp ゾーンは広域負荷分散担当者が管理する．*.iaa.wide.ad.jp にマッチするゾーン情報は，クラスタを提供する個々のサイト管理者に管理を任せる．

2. バランス値の反映方式

レゾルバ側での制限または DNS パケット長の制限により、エントリ数の合計数が数十第 2部

ライフラインとしてのインターネット に関する考察

41

エントリを越えないように定量化されたクラスタ間のバランス値数と等しい CNAME
レコードを，クラスタに属するサーバ名で記述する．記述時には，同クラスタに属するサーバをできるだけ均等に列挙するように注意する．

3. クラスタ内負荷分散機構の反映方式
シスコシステムズ社の LocalDirector や横河電機の SuMiRe のような，NAT 機能をベースとしたクラスタ内負荷分散装置を利用しているクラスタの場合，クラスタ外
部からは，クラスタ内負荷分散装置が隠蔽するサーバ群の IP アドレスは指定しても意味がない．そのため，クラスタ内負荷分散装置を示す単一の IP アドレスを利用して，同クラスタの総合的なサーバ処理能力値を反映する．

4. キャッシュ有効時間の指定
DNS ゾーン情報の頻繁な更新が発生した場合，キャッシュされた情報の鮮度を適切に保つことを目的に 3600 秒に資源レコード の TTL 値を設定する．

2.6.3

結果と考察

結論として本機構は予定通り動作しなかった．その理由として，CNAME レコードが，訓練参加者の組織の DNS サーバにキャッシュされたため，キャッシュ内容が指すサーバへアクセスが集中してしまった．
この問題の原因は広域負荷分散機構の担当者が，訓練前に実装機能を検証する際に，キャッシュサーバを経由した DNS レコード の検索による検証実験を行なわなかったため，事前に問題を見抜けなかったことによる．
また，訓練システムの情報を提供していた DNS authorized primary と secondary サー
バの間は，SOA レコードに定義されたデータ更新用 TTL 値に基づいて情報の同期を取ろうとするが，訓練時に設定されていた TTL 値が 7200 秒 (2 時間) となっていたために，バ
ランス値の変更が正しく反映されるまで大幅な遅延が生じてしまった．

2.6.4

課題

次回のインターネット災害訓練では，次の点を広域負荷分散機構における課題として取り組みたい．

 クラスタ情報の迅速な更新処理 バランス情報の定量化
 クラスタ管理者による情報更新421996 年度 WIDE 報告書

 クラスタまたはサーバの参加・脱退の管理方式
 キャッシュ対象となる情報の更新
2.7

クラスタ内負荷分散方式

クラスタ内負荷分散は NAT [?] の機能を拡張したものを用い， 外部に見せている一つのグローバル・アドレスに対して内部の複数のローカル・アドレスを割り当てることで 実現している．
今回はシスコシステムズ社の製品である LocalDirector と横河電機の実装したプログラム (以下 SuMiRe と称する) をそれぞれ北陸先端大学院大学と奈良先端大学院大学に置いて訓練に使用した．この二者に基本的な機能の差はないので ここでは SuMiRe(奈良先端大学院大学で使用) について述べる．
クラスタ内負荷分散の動作を WWW による登録処理にそって説明する．
奈良に関連した WWW サーバの DNS の設定は次のようになっている．

register.iaa.wide.ad.jp.
w11.naist.iaa.wide.ad.jp.

IN CNAME
IN A

w11.naist.iaa.wide.ad.jp.
163.221.23.66

奈良での SuMiRe の設定は以下のようになっている．

Virtual163.221.23.66

Real
163.221.23.80
163.221.23.81
163.221.23.82

163.221.23.67
163.221.23.83
163.221.23.84
163.221.23.85

Virtual の欄がインターネット側に見えているアドレス，Real の欄が内部につながっているサーバのアドレスである．インターネット側から見ると 163.221.23.66 のアドレスがあたかもサーバのアドレスのように見える．
Web を使った登録用サーバとして外部に公開されていた URL は以下のものである．

http://www.iaa.wide.ad.jp/touroku/
この URL にアクセスするときのクライアントと SuMiRe の動きを次に示す1 ．
1 箇条書きの番号は図 2.6の中の番号に対応している．

第 2部

ライフラインとしてのインターネット に関する考察

43

1. この URL には register.iaa.wide.ad.jp. に対してリンクが張られている．そこでクラ
イアントは DNS に，このホストの IP アドレスを問い合わせる．
2. DNS に問い合わせると w11.naist.iaa.wide.ad.jp.[163.221.23.66] が得られるので，ク
ライアントは そこに HTTP のセッションを確立しようとする．
3. クライアントが DNS に問い合わせてアドレスは 実際には SuMiRe のアドレスで 下に実際のサーバが 3 台つながっている (図 2.6参照)．図中の Server A 〜 Server C は
WWW の登録画面を提供するサーバである． SuMiRe はその 3 台のうち 1 台を選ん
で HTTP のセッションをつなぐ．
4. 別のクライアントが register.iaa.wide.ad.jp に HTTP のセッションを確立しようとす
ると，SuMiRe は 3 台の サーバのうちの別の 1 台を選んで HTTP のセッションをつなぐ．
このようにして SuMiRe はインターネット側からのアクセスを内部の複数のサーバに振り分ける．インターネット側から見ると これはあたかも図 2.6 中に破線で書いたように仮想的なホストが一台いてサービスを提供しているように見える．
SuMiRe がサーバを選ぶ時の手法は単純なラウンドロビンを用いている2 ．上記の例でいうと，最初に 163.221.23.80 に振ると 次は 163.221.23.81 に振る という具合に順番に振り分ける．この方法だと実装は簡単であるがサーバの状態の急変には対応できないので，例
えばサービスを提供中にサーバーが落ちたりすると 手でサーバーを外したりする操作が必要になる．
訓練が終了した時点での SuMiRe のログを見ると次のようになっている．

%% Uptime:
3:00PM up 22:30, 2 users, load averages: 0.09, 0.09, 0.08%% Linkstat:(linkstat(time 853567200)(virtual 163.221.23.66 (in 15679) (out 17060)(real 163.221.23.80 (hit 572) (in 5297) (out 5968))(real 163.221.23.81 (hit 572) (in 5371) (out 5469))(real 163.221.23.82 (hit 572) (in 5011) (out 5623)))(virtual 163.221.23.67 (in 30897) (out 31112)(real 163.221.23.85 (hit 1231) (in 10239) (out 10395))(real 163.221.23.83 (hit 1232) (in 10290) (out 10278))
2シスコシステムズの LocalDirector は SDA と呼ぶ もっと複雑な手法を用いてサーバを選択している．シ

スコシステムズのマニュアルによるとサーバのレスポンスタイム，ネットワークの利用状況等を見ている と書いてある．

44

1996 年度 WIDE 報告書

Web Client(1)
http://www.iaa.wide.ad.jp/touroku/(2)

INTERNET(2)

w11.naist.iaa.wide.ad.jp(163.221.23.66)
SuMiReOutsideInside(3)(4)
Serber A

Serber B

Serber C

Virtual host163.221.23.80

163.221.23.81

163.221.23.82

163.221.23.66

図 2.6: クラスタ内負荷分散

第 2部

ライフラインとしてのインターネット に関する考察

45(real 163.221.23.84 (hit 1232) (in 10368) (out 10439))))これは cron で定期的に出力したログの一部である． この中で virtual/real の欄の数値
は IP アドレス，in/out の欄の数値はパケットの数，hit の欄の数は SuMiRe がそのサーバにセッションを割り当てた回数を示す．
hit の数と in/out の数が大きく違うのは，SuMiRe は一回 TCP のセッションをあるサーバに向けると セッションが終るまではそのセッションを維持している という理由による．
このログから次のことが判る．
・ 163.221.23.66，163.221.23.67 に対するサーバの割り当ては均等に行われている．
・ HTTP の一回のセッションでは だいたい 8 〜 9 パケット流れる．
この SuMiRe の機能を使うことの利点と欠点は次のようになる．
利点

 利用者に透過的なサービスを提供することができる．利用者には一つのグロー
バル・アドレスしか見えていないので，局所的なサーバの構成を利用者に意識させることなく変更できる．

 利用者側のプログラムの変更，ルータの設定変更等は不要である．
 同じような機能は ラウンドロビン DNS を使っても実現できるが，DNS の機能を使うと以下のような不都合が生じる．
{ ラウンドロビン DNS では、レゾルバ側での制限または DNS パケット長の制限により，数十程度のエントリしか持つことができない．
{ サーバの状態に見合ったセッションの分配ができない．したがって仮に あるサーバが 過負荷になっている，または，落ちている時でも DNS は 問い
合わせに対してそのサーバのアドレスを返すので，クライアントはそのサーバに向けてセッションを確立しようとする．
{ DNS のエントリを変更しても その変更はきわめてゆっくりと (何時間もかかって，場合によっては何日も) でしか伝播しない．これはサーバの状態の急変には対応できないことを意味する．

SuMiRe の機能を使う時は これらの欠点は無く，サーバの集合に対して DNS には ただ一つの A レコード を登録するだけでよい．実際に訓練中に奈良にある
サーバ 3 台のうち２台の調子が悪くなった時，SuMiRe の設定を変えるだけで調子の悪くなったサーバをサービスから切り離すことができた3 ．この時は残りの 1 台だけでサービスを継続していた．この変更は利用者側には一切見えない．

欠点

 この機能は TCP のセッションを見ているので，セッションの概念の無い ICMP，
UDP には対応できない．

3 上記のログの記述ではこの部分は表われていない．

46

1996 年度 WIDE 報告書

 複数サーバを用意すると，そのサーバのデータ構成 (例えば Web サーバだとコンテンツ) はすべてのサーバで同じに設定する必要がある．これは Web クライ
アントは 1 ページのデータをサーバから持ってくるのに複数のセッションを同時に張るためである．サーバ同士でデータ構成が違っているとクライアント側がうまくページの構成を作ることができなくなる．

 インターネット側からはサーバ群の構成がどのようになっているかを知ることができないためサーバを特定してセッションを確立できない．
今回の訓練で クラスタ内負荷分散機構が正しく機能することを確認できた．奈良でのサーバ群の構成は 同じ仕様のマシンを 3 台使ったためサーバ間での性能の差を考慮しなくてもよかったが， 実際に使う環境では能力の違うマシンを集めてサーバ群として利用する場合もあると考えられる．その時には SuMiRe を設定する時にサーバの重み付けができるようにして，サーバを選択する時にその重みを考慮して選択するようにする必要がある．
またサービスを提供している時に，サーバが落ちていることを検出しそのサーバにはセッ
ションを張りに行かないようにする機能も必要である4 ．
これらは今後の課題である．

2.8

オペレータ支援環境

IAA データベースは，WWW と電子メールのどちらからでも登録できる．WWW の場
合は CGI を用いて登録される．データはあらかじめ切り分けられているので，コンピュータを用いて自動登録が可能である．一方，メールの場合には，あらかじめ指定されたフォー
マットで記入してもらうことで，自動登録を可能にしている．ところが，メールは記入に自由があり，正しくないフォーマットで記入されると自動登録できなくなる．このような処理できないメールはオペレータ (人間) が修正し再登録する．
しかし，登録エラーのメールが大量に発生すると，オペレータが一人では全てのデータを修正するのに時間がかかってしまう．一人でデータを修正するよりも，複数の人で次々データを修正するほうが，より少ない時間で多くのデータを修正することができる．そこ
で，複数人のオペレータでエラーデータを修正できるようにし，エラーデータを管理できるように，オペレータ支援環境を開発した (図 2.7)．
オペレータ支援環境は，エラーとなったメールを管理するオペレータサーバ，および，オ
ペレータサーバからデータを取り寄せるオペレータ用のエージェントから成り立つ．オペ
レータはエージェントを用いてエラーデータの取得，修正，配送を行う．
登録メール受付のクラスタには，オペレータサーバが在中プロセスとして立ち上がっている．登録フォーマットがエラーとなったメールはオペレータサーバに配送される．以後，4 訓練の最中に SuMiRe が落ちたことがあったが，落ちてるのじゃないかと聞かれるまで気付かなかった

ことがあった．

第 2部

ライフラインとしてのインターネット に関する考察

47

オペレータ支援環境
登録
エラー
オペレータサーバ

入力部
修正情報

エージェントエージェント

オペレータ

オペレータ

図 2.7: オペレータ支援環境

配送されたエラーメールは，オペレータサーバによって管理される．
オペレータはサーバから登録エラーメールのデータを取り寄せ，登録可能なフォーマットに修正してから，データを IAA クラスタに配送する．エージェントとオペレータサーバとの通信は，HTTP に似た独自のプロトコルが用いられている．サーバにエラーデータの取得を要求すると，サーバから修正すべきデータが送られてくる．もし，修正すべきデー
タがないならば，エラーデータがないことが通知される．リクエストベースでサーバからエラーデータを取り寄せるので，オペレータは手の空いている時に作業することができる．
さらに配送の際，再登録のエラーとなることを避けるため，エージェントによってデータのフォーマットや中身が自動的にチェックされる．このとき，データにエラーがある場合は配送されず，オペレータはエラーがなくなるまで修正を継続して行う．修正不能な場合
は，そのデータを破棄でき，別の新たなエラーデータを取り寄せることができる．データを破棄すると，エージェントがその旨をオペレータサーバに報告する．
誰でも，サーバからエラーデータを取り寄せることができてしまうと，エラーとなった
データのプライバシを守ることができない．オペレータ以外からのアクセスは拒否しなけ
ればならない．そこで，オペレータサーバへのアクセスは，オペレータ個人しか知らない
パスワードを付加することで，認証を行っている．認証のプロトコルは，あらかじめサー
バ側には各オペレータの名前と暗号化されたパスワード を登録しておき，UNIX の login
時に利用されている crypt を利用した認証方式を用いている．
今回の訓練では，オペレータサーバは Perl，オペレータのエージェントは Mule で実装

48

1996 年度 WIDE 報告書

した．オペレータは Mule の Emacs Lisp 言語で記述された IAA 用のメジャーモードを使用して，エラーデータを処理する．配送前に，Emacs Lisp のフォーマットチェックが自動的に働くようになっていた．しかしながら，Emacs Lisp とクラスタ内でのフォーマットのチェックの内容に違いがあったため，オペレータが修正したデータが再びエラーとなってオペレータに配送されてしまう場合があった．送信する前のフォーマットチェックはさらに厳密に行わなければならない．

街頭登録・検索実験

2.9

前回の訓練の際に，多くの参加者から「被害によって既存の電力や通信手段が利用不可能となった被災地において，生存者情報をアクセスするにはど うするのか．
」と質問を受けた．
この問題を解決するために，第 2 回インターネット災害訓練では，訓練の共催者である
NTT の移動計算機環境搭載車 (インターネットカー) を利用し，特定地域が被災したという想定でインターネットへの接続を確保して IAA データベースへの登録および検索が行なえる出張 IAA データ登録・検索所を開設した．
ここでは，この訓練概要と訓練を通じての反省点と今後の課題について述べる．
2.9.1

概要

今回の訓練は，日比谷公園音楽堂の大噴水前 (図 2.8) に，インターネットカーと，その前に登録/検索のための端末を設置して，道ゆく一般の人に参加をお願いする形で行なった．
説明員は NTT 側から 5 名，ライフラインワーキンググループ 側から 2 名の計 7 名で，訓練目的や登録操作などを説明した．また，報道関係の取材の対応に 1 名が参加した．
ネットワーク接続は，図 2.9 に示すように，インターネットカーと北陸先端大を結び，WIDE インターネット上の衛星マルチキャスト網に接続する形をとった．

 NTT 移動計算機環境搭載車
衛星用パラボラアンテナは移動時は車の上に伏せた形で固定し，使用する際にはそのまま車上に取り付けても，地上に設置することも可能になっている．今回は車上に取り付け使用した．
衛星には N-STAR を利用し，仙台にある地上局との間で衛星回線を確立でき，仙台
地上局から ISDN 回線で他の場所との回線を確立することで，移動計算機環境搭載
車と地上の間で ISDN 回線を確立することができる．衛星のトランスポンダが利用可能であれば，停車時に ISDN 回線を最大 PRI (1.5 Mbps)1 回線と BRI 2 回線を使用することが可能であり，また，走行時は，NTT DoCoMo デジタル携帯電話による
9,600bps の回線を使用できる．
今回は INS ネット 64 2 回線 (BRI 4 回線) を用意し，そのうちの 1 回線 (128Kbps) を日比谷公園と北陸先端大の間で使用し，もう 1 回線を電話として利用した．

第 2部

ライフラインとしてのインターネット に関する考察

49

図 2.8: 日比谷公園のインターネットカー

また，今回は使用しなかったが電源が確保できない場合には車載のディーゼル発電器を用いることで，必要な電力が得られる．

 端末環境登録・検索端末として Macintosh 2 台，Window95 2 台の計 4 台の ラップトップ機を用意した．インターフェースは WWW のみとし，ブラウザには Netscape Navigatorを使用した．ブラウザの設定は，当初，ホームページを http://iaa.wide.ad.jp/ に設定し，プロキシは行なわないようにしたが，一度アクセスした DNS のエントリがキャッシュされてしまうために，うまく動作していない IAA クラスターの登録用ページに接続してしまうとそれ以降，別の正常に動作するページにアクセスできなくなってしまうことから，正常動作している IAA クラスターの登録用ページの URL を明
示的に IP address で指定した．

 端末および インターネットカーの配置

端末とインターネットカーの配置を図 2.10に示す．当初，インターネットカーに向かって登録操作をする配置にできればと考えたが，太陽の光が背後から射すような位置になり液晶ディスプレイが一切読めない状態になってしまうためにこのような配置
になった．

50

1996 年度 WIDE 報告書

図 2.9: ネットワーク構成

第 2部

ライフラインとしてのインターネット に関する考察

51

インター
ネットカー

登録/検索者
ラップトップ機

太陽光線
図 2.10: 各装置および インターネットカーの配置

2.9.2

訓練の経過と様子 経過と参加者数

10:00 に集合し インターネットカーの設定を始めた．設定は順調に終了し ，予定の12:00 より早い 11:00 には衛星回線が利用可能となっていた．IAA データ登録・検索
は，12:00〜15:00 の 3 時間にわたって行なわれた．その間，およそ 20〜30 名ほどの登録・検索への参加があり，それ以外にも説明を聞いていくだけの方が約 70 名ほど ，
お昼時の 12:00〜13:00 には，4 台の端末がふさがっていて実際に操作することができない状況 (図 2.11) もあった．延べ 100 名ほどの参加者であったが家からメールで登録した後日比谷公園まで出向き検索を行なった人や地方から出向いてきて参加した人など ，非常に関心を持った参加者もいた．
訓練の開始しばらくは，登録がうまくいったように見えて，実際にはうまくいっていない状況が発生してために，検索を行なってもうまく検索されず，参加者に対してのアピールがあまりできないことが多かったのは残念であった．

 説明資料と説明員

説明の際の資料として，図 2.9と 12 月に行なったプレスリリースを元にインターネッ
トカーでの訓練の記述を追加した文章をそれぞれ 100 部用意した．端末の前で説明をはじめると一人一人に対して結構時間を必要とした．約 3 時間の訓練中，説明員 7
名では，数多くの人に説明をできる状況ではなかった．やはり，説明用のパネルなどの準備が必要であった．

 報道機関52

1996 年度 WIDE 報告書

図 2.11: 登録・検索操作の様子

NHK をはじめとして，数社の雑誌社が取材に訪れた．実際の登録操作も経験してもらい，訓練全体の説明を行なった．NHK では翌日の朝の NHK 首都圏ニュースで取り上げられた．

2.9.3

気づいたこと・反省点

1. 報道機関

最初のプレスリリースは 12 月初旬に行なったが，もっと早く行なうべきであった．また，日比谷公園での訓練の情報のリリースは訓練直前になってしまい，参加者が少なくなってしまった．こういった一般に公開し参加者を募る訓練は，どれだけ多くの人に体験してもらったかも評価の一つである．事前のアナウンス等をしっかり行なうことが必要である．

2. 一般参加者からの反応
前回はネットワーク上からしか一般の人は参加できなかったために，ほとんどある程
度ネットワークやコンピュータなどになれている参加者であった．今回は，インターネットを全く触ったこともない人も含めて，さまざまな人の参加により，より一般向けに様々な点を見直さなくてはならないことがわかった．参加者からの反応には以下のようなものがあった．

 何をやっているのかが良く判らない，

第 2部

ライフラインとしてのインターネット に関する考察

53

何の看板もなく，コンピュータがたくさん並んでいるため，御協力といわれても何をやらされるかわからないから，近付きにくいとの感想が出ていた．立て
看板や説明用の大きなパネルなど ，何をやっているのか一目でわかるような工夫が必要であった．

 難しい専門的なことをしているように見える．
ネットワーク配線や電気のコンセント，電話回線等，色々なものが露出していて，さらにノートブックがあったので，難しいことを専門的な人向けにしているような印象を持つ人がいた．配線やその他目に触れる必要のないものはできるだけ見えないようにした方がよかった．

 参加しやすい配置への配慮

図 2.10の様な配置であったために．
「 端末入力の際に見学の人と向き合う形になり気恥ずかしい．
」との意見があった．より参加しやすい配置にすることが必要であった．

 インターネットやパソコン以外のアクセス手段が必要
参加してくれた人には普段インターネットやパソコンを利用していないという人が多くいた．それらの人たちからは，「 電話やＦＡＸで同じことが出来ればいい．
」と意見が多くいわれた．今回，実際の利用には間に合わなかったが，Phone-Shell
WG の成果を応用した電話による入力方法は非常に良いアプローチであろう．

3. ユーザインターフェース

ユーザインターフェースについては，前回に比べて WWW インターフェースを採り入れたりしていろいろ工夫を凝らしているが，一般の人にちゃんと問題なく使ってもらえるには不十分であると感じた．やはり，普段キーボードコンピュータに慣れ親しんでいるものが頭で考えて作るのではなく，実際に一般の人に使ってもらいながら改良や修正を加える地道な研究が必要であろう．参加者および説明員から次のような点が指摘された．

 キーボード 入力や慣れない環境は使いづらい
一般の人のほとんどがキーボードをうまく扱えないようであった．また，普段，コンピュータやワープロなどを利用していて，キーボードにある程度慣れている人であっても，{ Windows と Macintosh の操作性の違い{ デスクトップとラップトップのキーボード の違い{ 日本語入力方法の違い (ローマ字入力，ワープロ入力，Windows95 方式，

Macintosh 方式){ 日本語配列と英語配列の違い{ 変換キー，確定キーなど特殊用途のキーの有無

54

1996 年度 WIDE 報告書{ ポインティングデバイスの相違 (トラックボール，マウス）などの理由からかなり入力に手間取るようであった．
また，入力欄を移動する際にタブキーを使う必要があったが，多くの参加者が一つの項目を入力し終えると Enter キーを押してしまい，使いにくいようであった．一番馴染みのあるキーは Enter キーと矢印キーのようであった．

 キーボードとマウス (トラックボール) の切替を少なくする

入力を上から順番に行なうと，キーボード 操作とマウス操作が交互に行なわなければならないようになっていたために，戸惑う人が多かった．キーボード 入
力項目とマウスでの入力項目は各々まとめたほうがよい．

 ラップトップ機は戸外では使いづらい

訓練当日は晴天で非常に太陽の光が強く，登録/検索端末として用意したラップトップ機の液晶画面は太陽と反対向きにしていても，ほとんど 見えない状態であった．液晶以外のディスプレ イを用意するとか，テントなどを用意するなどの工夫が必要である．また，画面が小さく説明しながら入力するには不都合であった．

 入力した文章が見えなくなると不安である
メッセージ入力欄で長い文章を一度に入力すると，入力した時は見えても，確
定時には最初のほうが見えなくなる．また，年齢や郵便番号の項目欄は全角で入れると，全ての桁を見ることができなかった．画面上の欄内で可能な限り表示する工夫が必要である．
因みに，横にスクロールしてなくなるのは不安になるようであったが縦にスク
ロールには，あまり違和感がないようであった．

 入力方法説明の文章「登録ボタンに飛ぶ」という言い方に馴染みのない人が見受けられた．入力方法を解説する文書の表現にも一般向けによく考える必要がある．また，今回数名の外国人の方に登録操作に協力してもらったが，日本語以外で利用できるイン
ターフェースが必要である．

 任意検索キーは面白い．
あらかじめ打ち合せたり周知しておくのが大変そうであるが任意検索キーのようなものは，あると便利との意見があった．

4. プレゼンテーションとしての完成度

一般向けのプレゼンテーションとして見た場合，IAA データの登録/検索が出来ただ
けではあまりアピールしないと思われた．また，システムが不安定で思ったとおりに動作しないようでは，参加者にかえって悪い印象を与えることになる．説明を聞いてもらい訓練の主旨を理解してもらった後，実際に確実に動作するものを見せることが大切である．

第 2部

ライフラインとしてのインターネット に関する考察

55

5. 準備段階での問題
準備段階で関係各所とどのように連絡を取り合い，全ての情報がうまく流れるような体制がちゃんとできていなかったために，準備不足に陥ってしまった． 他の組織との調整にもっと配慮すべきであった．
2.9.4

今後の課題

 ユーザインターフェースの改善
ユーザへの見え方の部分は一人よがりではなく時間をかけて実際に数多くの人に使用してもらいながら改善する必要がある．ユーザインターフェイスをより良いものにするためにどのような活動をすべきか見直す必要があろう．

 多種多様なユーザインターフェース
ユーザインターフェースは多種多様のものが揃っていることが望ましいことは今回の訓練で明らかである．しかし，ライフラインワーキンググループだけで多種多様なものを揃えることは不可能であり，ライフラインワーキンググループ 以外の人が自由にユーザインターフェース部分を作成しシステムに接続できるように，IAA システ
ムへの API およびプロトコルを明確に定義し，公開していくことをしなければならないであろう．

 他組織との連係

今回の場合，NTT インターネットカーや日比谷公園の利用に際して，関係各所にお願いしていろいろ助けていただいた．今後も一般参加が必要な訓練の場合は，WIDE以外の組織との連係が必要であると思われるので，うまく調整を行なえるような体制を整えていかなければならない．

2.10

評価・展望

今回の訓練では，約 2,000 人の IAA 情報登録者と 10,000 人以上の IAA 情報検索者の参加があった．訓練を実施したことで以下のような知見及び問題点が明らかになった．

 IAA システムのインストールが複雑
今回の訓練で作成した IAA システムは，インストールする際の設定が複雑で完全に設定できたサイトと，できなかったサイトにわかれた．そのため，完全動作していな
いサイトで IAA 情報の登録を試みた訓練参加者には大変迷惑をかけた．

 計算機調達
本訓練では，各サイトにおいて計算機が独自で調達することが必要であった．そのため，各サイトで訓練期間だけ本システムを運用する計算機が用意された．結果とし

56

1996 年度 WIDE 報告書て，各サイトで普段利用している高速な計算機が大量に導入されることとなった．しかし，多種多様な計算機が導入されることとなり IAA システムの作成・保守・管理・運用が困難であった．また，第 2 回訓練で提供したサービスを訓練日以降維持することができないことを意味する．

 IAA システム管理
今回の訓練では，IAA システムのインストール及び設定が複雑であったため訓練開始直後に IAA サービスを提供できるサイトは，ごく一部であった．時間経過と供に，
IAA サービスを提供できるサイトが増えていったのだが，IAA システムの管理者が病気で長時間活動できる状態でなく，IAA システムに組み込まれるまで時間がかかった．

 広域負荷分散機構の必要性
本訓練で提供する IAA システムでは広域負荷分散が必要であると想定して，システ
ムへの組み込みが研究・開発された．しかし，訓練システムでは負荷分散機構が完全には動作しなかった．その結果，IAA システムの負荷が奈良先端に集中し IAA シス
テム全体の動作不良という結果となった．そのため，IAA システムを構築するに際して広域負荷分散機構が必要である可能性が高い．

 情報の共有方法
本訓練システムは，複数の人数で研究・開発が行なわれた．そのため，個々のプログ
ラム間での情報伝達方法の策定及び，完成したプログラム等は WWW をつかって実装者グループが全員容易に提案・実装できる環境を作成した．地理的に分断されている開発環境を効率良く運用するには，WWW は大変有用である．

 ネットワーク構築の失敗
IAA 情報配送関係も，衛星を使ったマルチキャストをメインに使用する予定であったが，設定の不具合により，ほとんどが地上ネットワークによって情報の共有が行なわれた．

 データベースプロトコル問題
データベースに関していえば，アプリケーションとしての完成度は個々に高かったが，2 種類のデータベースの仕様が一部違った．そのため，配送されてきた IAA 情報がデータベースに蓄積できないなどの問題が発生した．

 広報不足「第 2 回インターネット災害訓練」に関する広報活動が十分ではなく，参加人数は去年より下回る結果となった．

第 2部

ライフラインとしてのインターネット に関する考察

57

 運営・指揮系統
本システムを運営するにあたり，2 種類のメーリングリストが新設された．一つはプ
ログラム作成班用，もう一つは IAA システム構築用に各 IAA サイト間の連絡に使われた．そのため，各 IAA サイトで報告された IAA プログラムのインストール方法等の疑問等が，プログラム作成班に伝わらないなどの事態が発生した．
また，訓練システムの作成にあたり指揮系統が十分に機能しなかった結果「訓練システムの仕様策定」が大幅に遅れ，システムの作成に支障をきたした．
上記以外にも小さな誤算が積み重なった結果，残念ながら今回の訓練は成功したとは言い難い．
しかし，個々のプログラムに関しては，ほとんど完成しており次回の訓練において大幅な仕様変更にならない限り成功するであろう．また，今回の訓練を通じて得られた教訓は多く，災害発生時にも生じる可能性のある「時間の切迫した場合に発生するミス」が今回の訓練で多く見られた．
最後に，ライフラインワーキンググループ に対する関係者の情熱は大変大きなものであった．今後の 本ワーキンググループ による「 インターネットを利用した災害時の情報伝達方法の研究」は，今後大きく前進するものと確信している．
今後のライフラインワーキンググループ活動予定は，以下の通りである．

 定常運営を目指す
第 1 回及び第 2 回 IAA 訓練のように，常時動かしていないシステムを管理するということは大変困難であり，災害が発生してからシステムを運営していたのでは大きなミスが発生しやすく，またミスの発生が許されない．しかし，定常運営をしていれば，災害発生時に慌てることなく IAA システムを運営することが可能である．

 IAAng
現在のライフラインワーキンググループの活動状態は，lifeline=IAA という状態である．しかし，災害時にインターネットに求められる機能は多種多様に考えられる．そこで，今後は災害情報・被災地内生活情報の伝達方法の一手段として，インターネッ
トを活用する新システムの開発を目指す．また，ボランティア情報や，救援物資などの情報を効率よく伝達する手段も研究する．

 lifeline 活動の広報
災害時になってから，ライフラインワーキンググループの存在や活動成果ををアピールするのでは，万が一の災害発生に迅速な対応をとることができない．災害時に有効に活用してもらうためには，普段一般に知られているシステムである必要がある．
IAA 活動をきっかけにして，各メディアに対して存在をアピールする必要がある．

58

1996 年度 WIDE 報告書

 研究者・協力企業・協力機関を募る
さまざまなシステムが運営されることになれば，人・物・金 といった資源が大量に必要となる．現状でも，潤沢にあるとはいいがたいが，さまざまなシステムの開発をおこなうことにより，魅力ある研究・開発グループとして活動し，協力者・協力機関
等の発掘に努める．
今回の訓練に対して協力してくださった関係各企業・大学・関係者に深く感謝いたします．

第 3章
日常運用

3.1

常に動いているシステム

ライフラインワーキンググループで行なってきた第 1 回，第 2 回のインターネット災害
訓練では，その都度，新しい技術の導入などを行ってきた．そのため，現在，安定して動作している環境を構築しきれていない．
一度，ワーキンググループ発足当時に考えていた「日頃から利用していないものはいざという時に使えない」といった視点に立ち返り，IAA の様な "常に動いていて欲しいアプ
リケーション " を安定して稼動させるためのシステム構築をおこなっていく．
そういった意味においては，インターネット災害訓練で行った「 IAA 訓練」は，我々が提供するシステムの上のデータベースの一つとして捉え直す。そうすることによって，IAA以外のシステムにも応用できると考えられる．また，データベースの API を明らかにしておけば，利用するユーザ自らクライアントを作成することも可能になる．
3.1.1

開発環境の統一

第 1 回，第 2 回のインターネット災害訓練においては，クラスタにおける計算機の種類などが異なっており，開発を含めシステム構築に余計な時間を取られてしまっていた．この点についても改善していく．
当面利用するマシンの仕様は表 3.1のようにする．
CPUIntel Arch (Pentium 166MHz 以上 or Pentium Pro)

OS

BSDI 3.0 or 2.1

Disk

4GB (SCSI)

Memory128MB

DB

BSDI 3.0 付随商用 DB (?) (同時アクセス 2 のライセンスあり)

UPS

瞬電対策のため

表 3.1: 定常利用のための計算機スペック

59

第 4章
今後のスケジュール
これまでの内容を次に述べるようなスケジュールで推進する．特に定常運用できるシステムの構築や他アプリケーションが動作することのできる安定したシステムの構築を重点的に取り組む．
また，対象としている内容から他組織などとの連携が求められる場合もあるかもしれない
が，それらに対してはワーキンググループとしての体制なども見直しながら対応していく．

5月

6 月〜9 月10 月〜3 月

定常運転用マシンのセットアップ
担当割り振り仕様策定
月 1 回程度のミーティング (システム構築)
システム稼働60