平成 14 年度
修士学位論文PICKLES OS のコンセプトに基づいた
定点観測システムの運用保守の効率化手法
A Maintenance Method for Fixed Point Observation
System based on the Concept of PICKLES OS

1055103

田渕 理恵

指導教員

菊池 豊

2003 年 2 月 24 日
高知工科大学大学院 工学研究科 基盤工学専攻
情報システム工学コース

要 旨

PICKLES OS のコンセプトに基づいた
定点観測システムの運用保守の効率化手法
田渕 理恵

本論文では、定点観測システムの運用保守の効率を上げるために、PICKLES [1] の概念を用いたアーキテクチャを提案する。
定点観測システムとは、特定の地点における気象や景観データをインターネットを介して教育教材として提供するシステムである [8][6]。現在、定点観測システムが稼働してから 2年が経ち、運用保守のコストが増大するという問題が生じてきている。

PICKLES OS とは公衆情報端末用に構築された OS である。この OS の特徴である、「共通の利用者環境の提供」と「ホストに依存した情報と全ホストで共有できる情報との明確な分離」を導入することにより、定点観測システムの運用・保守面での問題を解決できると考える。
この考察に基づき、プロトタイプを作成し、運用保守にかかるコストの比較検討を行った。シュミレーションの結果より、提案したアーキテクチャの方が保守性が上がることが分
かった。
キーワード

PICKLES OS，定点観測システム，運用・保守，効率化–i–Abstract
A Maintenance Method for Fixed Point Observation System
based on the Concept of PICKLES OS
Rie TABUCHI

This paper proposes a maintenance method for fixed point observation system basedon the concept of PICKLES OS.
The fixed point observation system provides weather reports and landscape image
data through the Internet for education subjects.
The system has worked for two years. The administrators have been faced many
problems. It is important to reduce the cost of the maintenance.
The proposed architecture by using the concept of PICKLES will reduce the costof the maintenance of the system.
key words

PICKLES OS，Fixed Point Observation System，Maintenance Method– ii –

目次
第1章

はじめに

1

第2章

背景

3

2.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

初等中等教育におけるネットワークの活用 . . . . . . . . . . . . . .

3

2.1.2

定点観測システムの概要. . . . . . . . . . . . . . . . . . . . . . .

4システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

観測機器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

活動団体 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

活用例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

PICKLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.2.1

PICKLES の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.2.2

PICKLES SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.2.3

システム構成. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.4

特徴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

定点観測システム

観測ポイント

2.1.3
2.2

第3章

3.1

3.2
第4章

4.1

定点観測システムの管理上の問題点

19

定点観測システムの現状 . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.1.1

トラブルの分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

トラブル内容とその原因の整理 . . . . . . . . . . . . . . . . . . . . . . .

21

システムアーキテクチャ

24

提案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1.1

24

PICKLES と定点観測システムの共通点 . . . . . . . . . . . . . . .

– iii –

目次

4.2

アーキテクチャの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3

プロトタイプの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3.1

プロトタイプの実装環境. . . . . . . . . . . . . . . . . . . . . . .

27

4.3.2

PICKLES-like FreeBSD . . . . . . . . . . . . . . . . . . . . . . .

28

4.4

運用技法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.5

提案するアーキテクチャの利点 . . . . . . . . . . . . . . . . . . . . . . .

32

評価

33

5.1

用語説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.2

計算に使う仮定条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.3

従来の対処方法の整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.3.1

セキュリティホール発見の場合 . . . . . . . . . . . . . . . . . . . .

36

5.3.2

WWW が更新されない場合 . . . . . . . . . . . . . . . . . . . . .

37

5.3.3

プログラムバグ発見の場合 . . . . . . . . . . . . . . . . . . . . . .

38

5.3.4

クラッキング対処の場合. . . . . . . . . . . . . . . . . . . . . . .

39

5.3.5

ハードディスクに異常発見の場合 . . . . . . . . . . . . . . . . . . .

41

5.3.6

ウィルス対処の場合 . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.3.7

マザーボードが故障した場合 . . . . . . . . . . . . . . . . . . . . .

42

5.3.8

HUB が故障した場合 . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.4

提案する手法に基づく対処方法 . . . . . . . . . . . . . . . . . . . . . . .

42

5.5

実際の金額計算 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.5.1

従来の対処方法の試算 . . . . . . . . . . . . . . . . . . . . . . . . .

45

結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.6.1

45

第5章

5.6

第6章

6.1

コスト比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

考察48

ハードディスクの容量 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48– iv –

目次

6.2

データディスクが破損した場合の復旧方法 . . . . . . . . . . . . . . . . .

49

6.3

複数台ディスクコピーを取る場合 . . . . . . . . . . . . . . . . . . . . . .

49

6.3.1

dd を使う場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

6.3.2

dump-restore を使う場合 . . . . . . . . . . . . . . . . . . . . . . .

50

6.3.3

ハードディスクデュプリケータを使う場合 . . . . . . . . . . . . . .

50

複数箇所を対処した場合のコスト . . . . . . . . . . . . . . . . . . . . . .

52

むすび

54

今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

7.1.1

ネットワークを用いた実証実験 . . . . . . . . . . . . . . . . . . . .

54

7.1.2

マニュアルの必要性 . . . . . . . . . . . . . . . . . . . . . . . . . .

55

7.1.3

ネットワーク監視の必要性 . . . . . . . . . . . . . . . . . . . . . .

55

7.1.4

ユーザディスクの使い方. . . . . . . . . . . . . . . . . . . . . . .

55

6.4
第7章

7.1

謝辞

57

参考文献

59

付録 A

広域定点観測網実証コンソーシアムの活動

60

www.teiten2000.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

試算

62

B.1

従来の対処方法の試算 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

B.2

提案に基づいた対処方法の試算 . . . . . . . . . . . . . . . . . . . . . . .

64

A.1
付録 B

–v–

図目次
2.1

定点観測システムの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62.2

定点観測システム (センサー部分) . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

定点観測システム (景観カメラ部分). . . . . . . . . . . . . . . . . . . . .

92.4

定点観測システム設置ポイント (地図) . . . . . . . . . . . . . . . . . . . .

13

2.5

ハードディスクの再利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.1

PICKLES と定点観測システムの構成の比較 . . . . . . . . . . . . . . . . .

25

4.2

定点観測システムのディレクトリ構成. . . . . . . . . . . . . . . . . . . .

26

4.3

着脱可能な ハードディスク . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.4

提案するシステム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.5

実装に用いた PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.6

PICKLES のファイルシステム . . . . . . . . . . . . . . . . . . . . . . . .

32

5.1

宅急便：荷物の大きさ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

A.1 www.teiten2000.org(ホームページ トップページ) . . . . . . . . . . . . . .

60

A.2 www.teiten2000.org(ホームページ 学習教材のページ) . . . . . . . . . . .

61

A.3 www.teiten2000.org(ホームページ 現在のページ) . . . . . . . . . . . . . .

61– vi –

表目次
2.1

学校のコンピュータ設備及びインターネット接続状況 . . . . . . . . . . . .

42.2

気象センサの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3

景観カメラの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4

ローカルサーバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.5

その他 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.6

観測ポイント情報 (平成 12 年度設置) . . . . . . . . . . . . . . . . . . . . .

11

2.7

観測ポイント情報 (平成 13 年度設置) . . . . . . . . . . . . . . . . . . . . .

12

2.8

PICKLES のハードディスク . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.1

トラブル内容の分類分け . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.2

トラブル内容の原因と分類分け . . . . . . . . . . . . . . . . . . . . . . . .

23

4.1

プロトタイプに用いた PC のスペック . . . . . . . . . . . . . . . . . . . .

28

4.2

PICKLES like FreeBSD のシステム構成 . . . . . . . . . . . . . . . . . .

30

4.3

プロトタイプの fstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.1

説明に使う用語集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.2

大阪 - 高知間 移動料金 (空路の場合) . . . . . . . . . . . . . . . . . . . . .

35

5.3

小包の地帯区分 (高知県発着の場合). . . . . . . . . . . . . . . . . . . . .

36

5.4

小包の料金表 (高知県発着の場合) . . . . . . . . . . . . . . . . . . . . . . .

37

5.5

宅急便サイズ表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.6

パソコン宅急便料金表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.7

従来の対処方法：セキュリティホール発見の場合. . . . . . . . . . . . . .

38

5.8

従来の対処方法：WWW が更新されない場合 . . . . . . . . . . . . . . . .

39

5.9

従来の対処方法：プログラムバグ発見の場合 . . . . . . . . . . . . . . . . .

40– vii –

表目次

5.10 従来の対処方法：クラッキング対処の場合 . . . . . . . . . . . . . . . . . .

41

5.11 従来の対処方法：ハードディスクに異常発見の場合 . . . . . . . . . . . . .

41

5.12 従来の対処方法：ウィルス対処の場合 . . . . . . . . . . . . . . . . . . . .

42

5.13 従来の対処方法：マザーボードが故障した場合 . . . . . . . . . . . . . . . .

43

5.14 従来の対処方法：HUB が故障した場合 . . . . . . . . . . . . . . . . . . . .

43

5.15 提案する手法に基づく対処方法 (1 箇所対処を行う場合) . . . . . . . . . . .

44

5.16 結果 (1 箇所当たりのコストの比較) . . . . . . . . . . . . . . . . . . . . . .

45

5.17 結果 (コストの比較) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

6.1

ハードディスクを dd でコピーした時の時間 . . . . . . . . . . . . . . . . .

50

6.2

ハードディスクをデュプリケータでコピーした時の時間 . . . . . . . . . . .

51

6.3

提案する手法に基づく対処方法にデュプリケータを用いた場合 . . . . . . .

51

6.4

提案する手法に基づく対処方法にデュプリケータを使用した場合の結果 (コストの比較) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

B.1 従来の対処法のコスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62– viii –

第1章

はじめに
インターネットが教育の現場に普及することにより、離れた地域間での交流活動や共同学習が可能となってきた。全国では多くの学校においてコンピュータを用いた多種多様な教育実践が行われている。
平成 12 (2000) 年度に文部省 (現 文部科学省) 初等中等教育局中学校課による「教育用コンテンツ開発事業」が実施された。この事業の一つに「広域定点観測網実証プロジェクト」がある。本論文ではこのプロジェクトが行った事業について焦点を当てる。
このプロジェクトでは「電子百葉箱」「カメラ」および「パーソナルコンピュータ」を 1ユニットとする観測装置 (以下、定点観測システムとする) と、学習インタフェイスの開発を実施してきた。現在は定点観測システムのサーバ OS に Linux を用いた商品版と OS にFreeBSD を用いたプロトタイプ版が存在する。
現在、定点観測システムが稼働してから 2 年が経ち、プロトタイプ版において運用・保守の面でコストが増大するという問題が起きている。全国各地に設置してあるシステムを管理する上で重要なことは、管理コストを下げることだと考えた。
本稿では、まず第 2 章で技術的背景である定点観測システムと PICKLES の紹介をする。
第 3 章では、既存システムの問題点を挙げる。第 4 章では、今回提案するシステムアーキテ
クチャについて述べ、そのアーキテクチャに沿ったプロトタイプ版の実装について述べる。
他に、実装したシステムの運用技法も提案する。第 5 章では、提案したアーキテクチャの評価を行う。運用保守にかかるコストを計算することで、本提案の有用性を示す。第 6 章では考察をし、最後に、第 7 章で今後の課題とまとめを述べる。
付録 A には、定点観測網実証コンソーシアムの活動として、ホームページを紹介する。付–1–

録 B には評価で用いた計算の途中経過を記載する。

–2–

第2章

背景
本章では技術的背景となる定点観測システムと PICKLES について簡単に述べたあと、それぞれの概要や特徴について詳しく述べる。
定点観測システムとは、インターネットを介して気象情報を教育教材として提供するシ
ステムである。日本全国に観測ポイントを設け、定点観測システムを設置する。同一時間、長期的にデータを採取することにより、観測ポイント同士のデータの比較を行うことができる。

PICKLES とは 公衆情報端末である。これは公衆電話のように、「どこでも」「だれでも」「場所に制約なく」インターネットを使えるようにという意向から開発された。

2.1

定点観測システム

本節では 1 つ目の技術的背景である定点観測システムについて述べる。
初めに、初等中等教育におけるネットワークの活用についての動向を述べ、定点観測シス
テムの概要を説明する。

2.1.1

初等中等教育におけるネットワークの活用

インターネットの普及と共に、学習スタイルも刻々と変化している。特にコンピュータが普及したことにより、従来の「文字と写真」の教材ではできなかった教育方法が容易に可能となっている。
日本では、既に平成 3 (1991) 年の学習指導要領改訂において、情報教育の重量性が認識–3–2.1 定点観測システム

され、文部省の調査研究協力者会議のメンバーによる「情報に関する手引き」が出版された。さらに、小中高等学校にコンピュータ導入が精力的に推進された [10]。
文部科学省では、平成 17 (2005) 年度までに、すべての小中高等学校等が各学級の授業においてコンピュータを活用できるように施策を推進している∗1 。平成 15 (2003) 年 3 月 31
日現在の整備状況を表 2.1 に示す∗2 。
表 2.1
学校種

学校のコンピュータ設備及びインターネット接続状況

学校数

教育用

1 学校

教育用

イ

ン

学校の

D

A (校)

コ

ン

当たり

コ

タ

ー

イ

ン

うち高

室

ピュー

の教育

ピュー

ネット

タ

ー

速イン

LAN

タ総台

用コン

タ 1 台

接続学

ネット

タ

ー

設備率

B

ピュー

当たり

校数 D

接続率

ネット

F (%)

タ平均

の児童

(%)

D/A

接続率

設

置

生徒数

(%)

E (%)

台

数

C (人

数

(台)

B/A

ン

の

普通教
の

／台)

(台)
小学校

中学校

高等学校

中等教育学校盲・ろう・養護学校

合計

2.1.2

(23,506)(377,797)(16.1)(19.2)(17,828)(75.8)(11.7)(6.5)

23,251

480,322

20.7

15.0

22,594

97.2

35.8

15.7

(10,407)(371,305)(35.7)(10.3)(9,292)(89.3)(15.9)(7.1)

10,357400,582

38.7

9.3

10,271

99.2

40.2

16.8

(4,151)(304,142)(73.3)(10.0)(3,761)(90.6)(11.5)(14.6)

4,139

355,720

85.9

8.4

4,103

99.1

45.5

40.0

(1)

(43)

(43.0)(5.5)(1)(100.0)

(0.0)

(0)

1

42

42.0

5.7

1

100.0

0.0

0.0

(930)

(12.030)(12.9)

(7.0)

(756)

(81.3)(10.4)(12.0)

930

16,841

18.1

5.1

912

98.1

36.6

35.4

(38,995)(1,065,317)(27.3)(13.3)(31,638)(81.1)(12.9)(8.3)

38,6781,253,517

32.4

11.1

37,881

97.9

38.0

21.1

定点観測システムの概要

平成 12 (2000) 年度、文部省 (現 文部科学省) 初等中等教育局中学校課による「教育用コンテンツ開発事業」が実施された。この事業の一つに「広域定点観測網実証プロジェクト」がある。環境の異なる地域間での学習を支援するためには、ある程度標準化された情報提供∗1 http://www.mext.go.jp/∗2 http://www.mext.go.jp/a menu/shotou/zyouhou/020801.pdf–4–

2.1 定点観測システム

システムが必要である。そのために、このプロジェクトでは各地の風景や気象などの定点観
測情報を学習素材として活用するため、定点観測に係る共通のデータフォーマットの枠組みを提案をし、さらに「電子百葉箱」「カメラ」および「パーソナルコンピュータ」を 1 ユニットとする観測装置と、学習インタフェイスの開発を実施してきた。そして、このシステムを同一緯度・経度等の意味を持った多地点 (以下、観測ポイント) に設置し、各地点における気
象観測、景観撮影を長期的連続的に行なっている。
教育分野における定点観測は、100 校プロジェクト∗3 などにおいて、先鞭されている。このプロジェクトでは、技術的・人的資産の維持・発展を図ると共に、地球規模の定点観測の拡大を視野に入れたプラットフォームの技術開発及び観測データ等の標準化、学習用インタフェィス開発を行っている。

システム
日本各地の風景や気象などの定点観測情報を学習素材として活用するため、定点観測に関わる共通のデータフォーマットを提案している。OS は FreeBSD を使用している。データ
フォーマットは XML で作成されており、CGI で呼び出すことができる。XML のデータ仕様はホームページに公開されている ∗4 。
また、広域かつ複数の観測ポイントから定点観測データを自動集約、データベースを自動構築するシステムを開発したことにより、学習に活用できるリアルタイムでのデータ提供が可能なシステムを構築している。定点観測システムの構成を図 2.1 に示す。定点観測システ
ムの観測機器は同一緯度・経度に設置されている。
ここで、図 2.1 の説明をする。観測機器設置校とは小学校などの教育機関である。設置物
はデータ収集を行うローカルサーバ、気象観測を行う気象ユニット、景観写真を写すデジタ
ルカメラ (以下、景観カメラとする) である。データは 10 分毎に自動収集される。インター
ネットを通じてデータのやりとりを行うため、ローカルサーバはネットワーク接続が可能で∗3 定点観測システムの原型は、福島県葛尾村立葛尾中学校で作成された。http://www.jhs.katsurao.org/∗4 http://www.teiten2000.org/xml.txt–5–

2.1 定点観測システム

あることが条件である。
セントラルサーバは教育センターや教育研究所に設置され、ローカルサーバで収集されたデータを集め、WWW で公開する。現在、セントラルサーバが福島県に設置されている。
未設置校とは、観測機器を設置していない学校などである。未設置校ではインターネット
を通じて、各地域の観測データを閲覧したり、比較して学習に役立てることができる。

● 教育センター
教育研究所 等
セントラルサーバ衛星地域 WAN 等

XMLによるデータ交換
ローカルサーバ(データ収集サーバ)

ファイアウォール

● 未設置校

気象ユニット

カメラユニット

クライアント● 観測機器設置校
図 2.1

定点観測システムの構成–6–

2.1 定点観測システム

観測機器
観測機器は、気温、湿度、降水量、気圧、風向、風速などの気象情報を収集するセンサー
部分 (図 2.2) と景観を撮影する景観カメラ (図 2.3) の 2 種類に分けられる。設置機器の説明を表 2.2 表 2.3 表 2.4 表 2.5 に示す [8]。表 2.2 は気象センサの機能、表 2.3 は景観カメラの機能、表 2.4 はローカルサーバ、表 2.5 はその他のケーブルの名称と機能の説明である。

図 2.2

定点観測システム (センサー部分)

観測データは以下で、長期的に観測を続けることで、平均値も提供する。

• 気温
• 湿度
• 降水量
• 気圧
• 風向

–7–

2.1 定点観測システム

表 2.2

名称

気象センサの機能

機能
各種気象センサを装備し、野外に設置される。センサ

1の種類は、気温／湿度センサ (小形百葉箱内に格納) ／気象センサ部
風向・風速計／太陽放射線センサ／雨量計／地中温度
センサ (オプション) である。
気象センサ部で検知したデータはケーブルを通して、

2コンソール (GroWeather)

このコンソール送られ、常にその変化を表示する。ここに集まるデータは、同一機器内のデータロガーを介してコンピュータに送信される。

表 2.3

名称

景観カメラの機能

機能
デジタルカメラを装備したハウジング部である。屋外また

1

は室内に設置され、景観画像を定点観測データとして 10 分
カメラユニット

間隔 (夜中は 60 分間隔) に 1 回の頻度で自動撮影を行う。
夏場、冬場の為の温度制御機能を有している。
コンピュータからカメラの電源制御をする装置です。また2

デジタルカメラにおける不具合発生時に、カメラ本体の電シリアル制御電源装置

源 ON/OFF (ハードリセット) を実施する。この装置を使用することにより、電源供給をサーバから制御できる。

–8–

2.1 定点観測システム

図 2.3

定点観測システム (景観カメラ部分)• 風速
定点観測によって得られたデータによって、地域間の気象の異なりや地理的な条件による気象がさまざまに変化することが視覚的に比較可能になる。それに加え、地域の気候のデータが蓄積されることにより時代を示相する記録となる。その成果を、2000 年 12 月よりホームページ上で teitenn2000.org として公開している∗5 。

観測ポイント

2003 年 1 月 31 日現在、観測ポイントは 18 地点ある。図 2.4 に観測ポイントの地図、表
2.6、表 2.7 に観測地のポイント情報を示す。
定点観測システムが広域に配備されることにより、各地点における定点観測データがイン∗5 http://www.teiten2000.org/–9–2.1 定点観測システム

表 2.4

名称

ローカルサーバ

機能
システムの中核となるコンピュータ (サーバ) である。以
下の主な機能をはたす。

• 気象機器とカメラの制御と保存
1

コンピュータ• 気象データの取得と保存• デジタルカメラの画像データの取得と蓄積• セントラルサーバとデータ交換 (送出)• クライアントの要求に対するデータサービス処理

不意な停電等で AC 電源が切れたとき 5 分間程度給電し、2

無停電電源装置 (UPS)

その間にサーバを正常に終了するための装置である。復電するとサーバを自動的に起動し、測定を開始する。

表 2.5

その他

名称

機能

1

USB ハブ

サーバとデジタルカメラ間の接続に使用する。

2

USB リピータケーブル

サーバとデジタルカメラ間の接続距離を延長している。

ターネットを用いてリアルタイムに配信される。そして、地域間の気象の異なりや地理的な条件による気象の様々な変かすることが視覚的に比較可能となることで、集積されるコンテ
ンツは様々は学習の場において利用できるという汎用性も兼ね備えている [6]。

– 10 –

2.1 定点観測システム

表 2.6

観測ポイント北海道函館市(公立はこだて未来大学)

観測ポイント情報 (平成 12 年度設置)

高さ (m)

緯度

経度

カメラ方向

北緯：41 ゜50 ′東経：140 ゜46 ′

153.6

南

北緯：40 ゜47 ′東経：140 ゜46 ′32

南

北緯：39 ゜27 ′東経：141 ゜05 ′

175

東北東

北緯：38 ゜09 ′東経：140 ゜52 ′

24

北北西

北緯：37 ゜55 ′東経：139 ゜48 ′

27.5

西北西

北緯：37 ゜34 ′東経：139 ゜48 ′233

東

北緯：37 ゜23 ′東経：140 ゜17 ′303.43南東

北緯：37 ゜07 ′東経：140 ゜59 ′

71.5

東

北緯：37 ゜47 ′東経：140 ゜29 ′

71.6

南

北緯：34 ゜58 ′東経：135 ゜55 ′108

西青森県青森市(青 森 県 総 合 学 校 教 育 セ ン
ター)
岩手県花巻市(岩手県立総合教育センター)
宮城県名取市(国立宮城工業高等専門学校)
新潟県新潟市(新潟青陵大学)
福島県河沼郡会津坂下町(財団法人福島県自然の家会
津自然の家)
福島県郡山市(財団法人福島県自然の家郡
山自然の家)
福島県いわき市(財団法人福島県自然の家いわき海浜自然の家)
福島県福島市(福島学院短期大学)
滋賀県大津市(大津市立瀬田小学校)– 11 –

2.1 定点観測システム

表 2.7

観測ポイント
富山県富山市(県立富山大学)
長野県松本市(松本市教育文化センター)

観測ポイント情報 (平成 13 年度設置)

高さ (m)

緯度

経度

カメラ方向

北緯：36 ゜41 ′東経：137 ゜13 ′-北緯：36 ゜13 ′東経：138 ゜0 ′661.5

北緯：34 ゜43 ′東経：137 ゜43 ′--北緯：34 ゜21 ′東経：133 ゜13 ′-南南西

北緯：33 ゜37 ′東経：133 ゜43 ′

112.3

南西

北緯：35 ゜28 ′東経：133 ゜03 ′--北緯：32 ゜45 ′東経：129 ゜52 ′--北緯：26 ゜14 ′東経：127 ゜45 ′

-

-

-

西南西

静岡県浜松市(県立静岡大学浜松キャンパ
ス)
広島県御調郡(広島大学大学院理学研究科
附属臨海実験所)
高知県香美郡(高知工科大学)
島根県松江市(島根県松江教育センター)
長崎県長崎市(長崎市立長崎中学校)
沖縄県中頭郡(琉球大学教育学部附属小学校)– 12 –

2.1 定点観測システム

●：平成
▲：平成

図 2.4

12年度設置場所
13年度設置場所

定点観測システム設置ポイント (地図)

活動団体
これらの活動をしている団体を「広域定点観測網実証コンソーシアム」(以下、コンソー
シアム) と呼ぶ。このコンソーシアムは教育関係者と企業人の研究共同体で形成されている。
以下の活動を行っている。

1. 各地域での定点観測コンテンツ利用促進のあり方の検討
2. 地域コミュニティ形成のための検討– 13 –

2.1 定点観測システム

3. 定点観測シンポジウム実行委員会の設置
これからのシステムのあり方やノウハウ共有の場として協力者会議を持ち、メーリング
リストでコミュニケーションをとっている。また、さらなる教科教育の情報化普及を図って
いる。

2.1.3

活用例

以下に、教育現場で期待される活用例を示す∗6 。

• 小学校「生活」や「理科」での地球と宇宙の生きた教育素材利用• 小学校「社会」日本の気候の特徴、日本列島、地域を知るなどへの活用• 中学校「理科」天気とその変化での活用• 高等学校「理科基礎」「地学」「家庭科」「情報 A」等での活用• 国際交流活動や国内での他校との交流のテーマ素材への活用• 総合的な学習の教育素材として利用∗6 http://www.teiten2000.org より抜粋

– 14 –

2.2 PICKLES

2.2

PICKLES

本節では 2 つ目の技術的背景である PICKLES について述べる。
初めに、PICKLES の概要を述べ、PICKLES の OS 部分である PICKLES SYSTEMについて説明する。そして、システム構成や PICKLES の特徴などを述べる。

2.2.1

PICKLES の概要

PICKLES (Public/Personal Information Catering Kiosk and Literacy Education System) の略である ∗7 [1]。これは元東京工業大学大野研究室 ∗8 で研究開発された公衆情報端
末である。
インターネットの普及はとても著しいが、誰もが場所の制約を受けることなくサービスを利用できる環境は整っていない。大野・木本らは「どこでも」「だれでも」インターネットにアクセスできる環境を構築するために、公衆端末を街角の随所に設置することを提案し、

PICKLES プロジェクトを発足させた。PICKLES プロジェクトでは多くの人が場所に依存せずインターネットを利用できる環境を構築するために公衆端末の開発と設置を行っている。ここで言う公衆端末とは、街角などあらゆるところに設置され誰もが使える、インター
ネットを利用するための端末である。さらに、環境構築だけに留まらず、OS、公衆端末の管理手法、利用者教育など広範囲を視野に入れて全体のシステム設計を行っている。

2.2.2

PICKLES SYSTEMPICKLES SYSTEM とは PICKLES 端末で用いられている OS である。商用である
BSD/OS ∗9 をベースに構築されたシステムであるため、使用するにはライセンスが必要になる。PICKLES 端末は OS やアプリケーションなど通常コンピュータを利用して行う作業に必要な情報を内蔵のディスクに記録している。この方法では内蔵ハードディスクの内容∗7 http://www.ohnolab.org/researches/pickles/∗8 http://www.ohnolab.org/∗9 http://www.bsdi.com/– 15 –

2.2 PICKLESの保守の負担が大きくなる。しかし、PICKLES 端末では利用者と管理者の双方にとっての利便性を向上させるため、様々な工夫を導入している。この工夫を実現するのが PICKLESSYSTEM である。

2.2.3

システム構成工夫の一つに、ハードディスク (以下、HDD) の分離がある。PICKLES SYSTEM では

HDD に記録されている情報を、端末間で共有できるものとホスト固有のものとに分離している。以下はその分類である。

• 端末間で共有できる– 共通の情報∗ すべての端末で共有可能な情報である OS やアプリケーションプログラムなど• ホスト固有– 端末ハードウェア固有の情報∗ イーサネットインタフェイス、ビデオボードの種類など– ホスト固有の情報∗ IP アドレスやホスト名など、ホストを識別するための情報など– 端末所有者が管理する情報∗ ホームディレクトリ、スプールディレクトリなど– 利用者の情報∗ 公衆端末を利用する利用者の個人情報など
PICKLES では、以上の情報を HDD 2 台に分離して格納している。2 台それぞれを「システムディスク」「ユーザディスク」と呼ぶ。表 2.8 に各ディスクに格納してある情報を示す。これら 2 台の HDD は PC 本体から着脱可能である。

– 16 –

2.2 PICKLES

表 2.8 PICKLES のハードディスク

システムディスク

ユーザディスク

共通の情報

端末ハードウェア固有の情報
ホスト固有の情報
端末所有者が管理する情報
利用者の情報2.2.4

特徴

PICKLES の技術的ポイントとしては以下の 2 点に集約される [4][7]。
• 統一されたアプリケーション環境• 全ホスト共通領域 (システムディスク) とホスト固有領域 (ユーザディスク) との明確な分離
これらより、多くの利点がある。例えば、端末の故障時に HDD だけを取り出して代替機に移し換えることで再起動すれば復旧までの時間短縮につながる。他に、OS のバージョン
アップやアプリケーションのバージョンアップの場合は、新しいディスクと古いディスクを交換し、再起動するだけでバージョンアップが完了する。以上により、保守性を向上するこ
1 は PICKLES プロジェクトである。°
2 でとができる。図 2.5 では、その概念図を示す。°
3
は HDD に OS やアプリケーションをインストールする、PICKLES の生産工場である。°
4 では古い HDD とは OS のバージョンアップにより、生産された新しい HDD である。°
5 は古い
新しい HDD を交換し、再起動をする。すると、バージョンアップが完了する。°
2 で再利用される。
HDD を PICKLES の生産工場へ戻し、°

PICKLES の運用技法によると、管理者は HDD のコピー (生産) を行わない [3]。誰がHDD のコピーを行うかというと、HDD は PICKLES 生産工場で生産するものとして考えられている。管理者の仕事としては導入時にネットワークや機器の設定を行い、システム– 17 –

2.2 PICKLES

ディスクとユーザディスクを送付することと、バージョンアップに伴い、新しいディスクを1 と°2 が統合された形になっており、PICKLES
送付するだけである。しかし、現状では°プロジェクトが 管理者と PICKLES の生産工場の役割を担っている。

システムディスク

ユーザディスクPICKLESの生産工場

1

PICKLES Project

3
NEW

4

再利用

5

2 OSのバージョンアップなど

OLD

図 2.5

ハードディスクの再利用

他に、所有者の情報がユーザディスクという形で明確に分離されているため、バックアップ作業は容易に行うことができるという利点がある。その量もシステム全体のバックアップと比べると小さくなる。

PICKLES の利点をまとめると以下のようになる [2]。
• システムディスクが破損した時は交換するだけで修理ができる• 災害などの非常時にはユーザディスクだけを退避させればよい• PICKLES 端末本体を修理する時にはユーザディスクを手元で管理することができる– 18 –

第3章

定点観測システムの管理上の問題点
本章では、初めに既存システムである定点観測システムの現状を述べ、問題点を示す。次に、その問題点を明確にするために、管理者やその他関係者で構成されているメーリングリ
ストを分析する。分析の結果、作業量を増大させている原因はトラブルの対処にあることが
分かった。

3.1

定点観測システムの現状

定点観測システムの運営はコンソーシアムのボランティアによって行われている。メンテ
ナンスについては、[8] によると、「システム保守に関してはリモートメンテナンスにて対応
する、ハードウェア保守に関してはコンソーシアムより、最寄りのプロジェクト参加会社に保守依頼をする」と記載されている。設置当初は観測地点も少なく、管理にかかるコストもボランティアで賄える範囲だった。しかし、定点観測システムが稼働してから 2 年が経ち、運用保守の作業量が増大するという問題が生じてきている。また、運用保守に伴うコストが明らかではないという問題もある。全国各地に設置してあるシステムを管理する上で運用保守に関わるコストを下げることが重要と考える。

3.1.1

トラブルの分析

作業量を増大させている原因を調べるために、コンソーシアム内のメーリングリスト (以下、ML) を調べた。これは定点観測システム設置についての検討や運用上のトラブルなど、全てが記録として残っているためである。

– 19 –

3.1 定点観測システムの現状

2003 年 1 月 31 日現在、5924 通のメールが存在する。そのうち、定点観測システムが稼働し始めてからのメールは 2246 通ある。メーリングリストのログを分析し、トラブル内容を抽出した。
主なトラブル内容とその件数を表 3.1 にまとめた。
表 3.1

トラブル内容の分類分け

件数 (メールで話題になった件数)

対象サーバ

プログラムバグ発見

14

全ローカル

WWW が更新されない

46

全ローカル

HDD に異常発見

13

ローカル

セキュリティホール発見

138

全サーバ

クラッキング対処

14

全サーバ

ウィルス対処4

全サーバ

マザーボード故障

2

ローカル

トラブル内容その原因を抽出し、対処方法による分類を表 3.2 にまとめた。

ML によると、システム関係においてのトラブルは、リモートログインで作業を行い、コンソーシアムのメンバーのシステム担当者が主に一人で対処している。設置場所に行ってする作業は委託された会社から担当者が 1 人ないしは 2 人が設置場所へ出向いて作業する。
リモートログインで作業する内容では各観測ポイントのシステム全てに対して行う作業であり、観測ポイントが増大するにしたがって、作業量は比例して多くなる。設置場所に出向
いて作業については、 ML によると全ての観測ポイントにおいてではない。いずれにおいても、観測ポイントが増えるに従って、定点観測システムの運用・保守における作業量は増大することは明らかである。

– 20 –

3.2 トラブル内容とその原因の整理

3.2

トラブル内容とその原因の整理

ML では様々なトラブルの存在が明らかになった。これらのトラブルの原因を明確にする。
プログラムのバグが発見された場合 まず、プログラムのバグが発見されたことについてのメールは、システムの運用が始まってから多くあり、運用期間が長くなる程少なくなってきている。これより、システムの開発段階で取り去れなかったプログラムのバグが運用を始めてから発見され、バグを除去していっている。バグを除去することによって、システムは安定して稼働しているが、バグは開発中に除去されるべきものである。

WWW が更新されない場合 WWW が更新されないというトラブルは、2 年間の運用期間において常に起こっているトラブルである。観測データを公開しているホームページ
を見ても、調整中 (データが何らかの原因で取得されておらず、更新できない) となっている場合が多く、実際にはもっと件数が多い可能性がある。
この原因は大きく 2 種類に分けられる。自然によるものと、物理的な問題がある場合とである。自然によるものには、落雷によるネットワークダウン、停電によるネットワー
クダウン、停電期間が長く自動復旧できなかったという原因などがある。物理的な問題によるものには、設置場所の LAN に予想外な負荷がかかった、 HDD が容量を越えた、異常停止、HUB が故障したなどという原因がある。
セキュリティホールが発見された場合 セキュリティホール発見については、管理者が常に使用されている FreeBSD のセキュリティ勧告∗1 に注意を払い、そのセキュリティ勧告に基づき、対処を行っている。よって、運用期間中に最も多い仕事量となっており、これはシステム運用をしていく上では必要な仕事だと言える。しかし、現状では OS のバージョンアップを行っていない。OS のバージョンアップを行うことによって無くな
るセキュリティホールもある。
クラッキング対処の場合 クラッキング対処においての作業は 2 種類存在する。1 つ目は、
実際にクラッキングされたサーバの対処である。クラッキングの内容としては、/home∗1 http://www.jp.freebsd.org/www.FreeBSD.org/ja/security/– 21 –

3.2 トラブル内容とその原因の整理と /usr の下にディレクトリを作成し、クラッキングツールを起動していたというものである。この事実が見付かった原因が、関係者がサーバに ftp をしようとした時、パスワードが変更されていたということからである。サーバのログによると、約 1ヵ月前からクラッキングツールが起動していたと報告がある。このまま誰も気付かなければ全サーバに被害が広がっていたことが予想できる。

2 つ目は、クラッキングされたサーバを踏台として他のサーバがクラッキングされていないかチェックを行うことである。チェックには chkrootkit ∗2 を用いている。
システムをクラックする手段として「rootkit」というツールが存在する。ほとんどの

rootkit はインストーラー形式となっており、簡単かつ短時間で改ざん作業を完了できるようになっている ∗3 。rootkit は侵入の隠蔽をするためにログを改ざんしたり、バッ
クドアを仕掛ける。また、管理者に侵入を気付かれないようにするためにシステムコマ
ンドの改ざんを行うなど、侵入に利用するための各種ツールが満載されている。
このトラブルの対処として、侵入に利用されたセキュリティホールに対して patch を当て、各種設定を変更している。この作業には実質 19 日間を要しており、管理者の作業量の多さが伺える。
ウィルスの対処の場合 ウィスル対処は、NIMDA か code red によるアクセスログ残っており、判明した。これについてもセキュリティの甘さが挙げられる。HDD を交換とマ
ザーボードを交換することで復旧している。

HUB の故障の場合 これは観測データが取得できていないことから判明した。設置場所
担当者がトラブルに気付き、HUB を交換することで対処した。
マザーボード故障の場合 マザーボード故障においては、OS が勝手にリブートされるという現象から判明した。ML によると、OS が勝手にリブートされる時の原因の一つにマ
ザーボードの初期不良が挙げられると記載されている。

∗2 http://www.chkrootkit.org/∗3 http://www.zdnet.co.jp/enterprise/0301/15/epn06.html– 22 –

3.2 トラブル内容とその原因の整理

表 3.2

トラブル内容の原因と分類分け

トラブル
内容

リモートログイン
理由

対処内容

での作業
可能

プログラムバプログラムにバグが含

リモートログインで訂

グ発見

まれていた

正

WWW が 更停電の後の自動復旧が設置場所で機材の電源

不可

○

新されない

できていなかった

OFF/ON

落雷によるネットワーク

設置場所のネットワーク

ダウン

復旧を待つ

停電によるネットワーク

設置場所のネットワーク

ダウン

復旧を待つ

HDD が容量オーバー

HDD を交換

異常停止

設置場所で機材の電源

○

○

○

OFF/ON
HUB が故障

リモートログインで訂○○

HUB を交換○

正HDD に異常OS が起動しなくなった

HDD を交換
○発見
クラッキングクラッキングされた

リモートログインで対○対処
ウィルス対処応

NIMDA, code red によリモートログインで対

る被害

応

初期不良

マザーボードを交換○

マザーボード○故障– 23 –

第4章

システムアーキテクチャ
本章では、前章で明確になった問題点を解決するために、定点観測システムのアーキテク
チャを提案する。提案するアーキテクチャには PICKLES の技術概念を用いた。さらに、提案するアーキテクチャを用いたシステムの運用技法も提案する。そして、提案に基づいたプ
ロトタイプの実装について述べる。

4.1

提案

3.1.1 節より、作業量の増大をさせていた原因はトラブルの増大によるものだと判明した。
作業量を下げるために、以下の提案を行う。

4.1.1

PICKLES と定点観測システムの共通点

定点観測システムは、設置場所全てにおいて同じアプリケーションが存在し、その地点固有の観測データを持つという点が PICKLES OS の構成に似ている (図 4.1)。定点観測シス
テムを全ホストで共有できる情報である「定点観測システムのアプリケーション」と、ホストに依存した情報である「観測データ」とに分離することにより、保守・運用面での問題を解決すると考える。

– 24 –

4.2 アーキテクチャの概要

定点観測システムPICKLES

システムディスク
全ホストで共有できる情報

定点観測システムのアプリケーション

ユーザディスク
ホストに依存した情報

各観測地で得られる
その場所固有の観測データ

図 4.1 PICKLES と定点観測システムの構成の比較

4.2

アーキテクチャの概要

PICKLES の大きな特徴は「共有できる情報」と「ホストに依存した情報」の分離である。現在の定点観測システムのディレクトリ構成は図 4.2 のようになっている。図 4.2 より
アプリケーション部分と観測データが蓄積される部分が分かれていることが分かる。

4.1.1 節の共通点より、定点観測システムに PICKLES の概念を導入した。定点観測シス
テムに概念を当てはめると、共有できる情報は「定点観測システムのアプリケーション」、
ホストに依存した情報は「観測データ」となる。
定点観測システムのアプリケーション部分と観測データを分離したアーキテクチャを提案
する。

4.3

プロトタイプの実装

本研究では、4.2 節のアーキテクチャに基づき、プロトタイプを実装した。実装は以下の手順で行った。

– 25 –

4.3 プロトタイプの実装/home / teiten / app┓│┼ mail / msg.ini

│

│

│

┼ cmdstarter┃│┼ getwe┃定点観測システム

│

┼ mip

┃アプリケーション部分

│

┼ op

┃

│

┼ weather┃┼ config / config┛┃┼ sendmail.pl┃┼ data /┓┼ camera / YYYYMM / oYYYYMMDDHHMMSS.jpg ┃┼ tYYYYMMDDFFMMSS.jpg ┃│┼ weather / YYYYMM.cvs┼ weather.cvs│┃観測データ┃部分┼ original.jpg@┃┼ thumbnail.jpg@┃┼ weather.cvs@

┛

図 4.2

定点観測システムのディレクトリ構成

1. 着脱可能な HDD(図 4.3) を 4 台搭載したマシンを用意する
2. 4 台のうち 2 台に、PICKLES の概念を用いたシステムディスクとユーザディスクを作成し、OS をインストールする

3. システムディスクとユーザディスクの動作確認をする
4. 環境の設定をする
5.「定点観測システムのアプリケーション」と「観測データ」を別の HDD 2 台に分離し– 26 –

4.3 プロトタイプの実装て格納する

6. 動作確認をする
実装に用いる OS に FreeBSD を採用し、PICKLES の概念である「全ホスト共通領域(システムディスク) とホスト固有領域 (ユーザディスク) との明確な分離」を適用した。この適用した端末を PICKLES-like FreeBSD と呼ぶ。図 4.4 に提案するシステム構成を示す。
図 4.4 に示すように、提案するシステムのハードディスクは 4 台搭載されている。それぞれの名称を上から、「システムディスク」「ユーザディスク」「アプリケーションディスク」「データディスク」と呼ぶ。

図 4.3

4.3.1

着脱可能な ハードディスク

プロトタイプの実装環境

ここではプロトタイプ作成に用いた機材の説明をする。表 4.1 に使用した PC のスペックを示す。

– 27 –

4.3 プロトタイプの実装

OS
システムディスク

ローカルサーバ(データ収集サーバ

ユーザディスク)

研究室内 LAN

定点観測システム
アプリケーションディスク
観測データ
データディスク

気象ユニット

カメラユニット

クライアント
図 4.4

表 4.1

提案するシステム構成

プロトタイプに用いた PC のスペック

CPU

Celeron1.2GHz

Memory256MB

HardDisk

8.4GB × 2 台, 40GB × 2 台

OS

FreeBSD 4.4-RELEASE

PC はハードディスクが 4 台搭載できるマシンを用いた (図 4.5)。今回、準備できた観測
機器は景観カメラだけである。

4.3.2

PICKLES-like FreeBSD

ここでは PICKLES-like FreeBSD について説明する。PICKLES は OS に BSD/OS を使用しているが、 PICKLES-like FreeBSD は OS に FreeBSD を使用している。これはPICKLES の技術的概念を用いて FreeBSD で環境を構築したものである。

– 28 –

4.3 プロトタイプの実装

図 4.5

実装に用いた PC

まず、2.2.3 節で示した PICKLES のシステム構成を応用し、システムディスクとユーザ
ディスクの切り分けを行った。さらに、HDD を 2 台増設し、認識させた。定点観測システ
ムのアプリケーションをインストールするアプリケーションディスクと観測データを蓄積す
るデータディスクの切り分けも行った (表 4.2)。
ここで、/etc のうちホスト固有の情報と全ホスト共通の情報について説明する。UNIXはディレクトリ毎にある程度情報が分類されている [5][9]。/etc は起動設定情報が格納されている。PICKLES では図 4.6 のように、/etc の中のホスト毎に異なる情報を抜きだして格納した /etc3 と、可変な情報が含まれる /var を異なるパーティションに分離し、ユーザディスクに格納している。また、所有者が保持する情報も同じように /local としてユーザディスクに格納している。/etc のうちホスト固有のものについてだけ、symbolic link を用
いてユーザディスクの内容が参照されるようにしている (図 4.6)。同じユーザディスクを使えば、システムディスクを交換しても利用者から見て違いはない [3]。

– 29 –

4.3 プロトタイプの実装

表 4.2 PICKLES like FreeBSD のシステム構成

ディレクトリ

用途

ディスク名

/

ルートパーティション (全ホス

システムディスク

トで共通)

/usr

アプリケーションなど (全ホス

システムディスク

トで共通)/etc の一部/etc のうちホスト固有の情報

システムディスク

/var

スプールなど (ホスト毎に異なユーザディスクる)/local

ホームディレクトリなど (ホスユーザディスク

ト毎に異なる)/usr/home/teiten

定点観測システムのアプリケー

アプリケーションディスク

ション/usr/home/teiten/data

観測データ

データディスク

しかし、この方法ではユーザが誤って /etc 以下のファイルを編集してしまい、symbolic

link が壊れるということがある。
PICKLES-like FreeBSD では union file system を利用してこの問題点を解決している。
まず、/u というディレクトリを作成する。次に、/u/etc に union mount する。こうする
ことにより、/etc 内のファイルを編集すると。更新したファイルだけが /u/etc に置かれることになる。
上記のように分離した情報を別のパーティションに置く。表 4.3 に プロトタイプの fstabを示す。

– 30 –

4.4 運用技法

表 4.3

プロトタイプの fstab# Device

Mountpoint

FStypeOptions

Dump

Pass#

/dev/ad0s1b

none

swap

sw

0

0

/dev/ad0s1a

/

ufs

rw

1

1

/dev/ad1s1g/local

ufs

rw

2

2

/dev/ad1s1e

/u

ufs

rw

2

2

/dev/ad0s1e

/usr

ufs

rw

2

2

/dev/ad1s1f

/var

ufs

rw

2

2

/dev/ad2s1e/usr/home/teiten

ufs

rw

2

2

/dev/ad3s1e/usr/home/teiten/data

ufs

rw

2

2

/dev/cd1c/cdromcd9660ro,noauto

0

0

proc

/proc

procfsrw

00/u/etc

/etc

union

rw

0

0

4.4

運用技法

定点観測システムの設置場所には、その場所のシステムの担当者が存在する。担当者は必
ずしも、コンピュータやネットワークに詳しい人とは言えない。
そこで、「ディスク交換方式」 [3] を用いる。これは、OS とアプリケーションを内蔵ディスクに持ち、バージョンアップ時にはディスク自体を交換する方法である。端末が故障してネットワークを利用できない時の保守作業も、同様の手段で行うことができる。
管理者は、各アプリケーションのバージョンアップに伴い、最新の状態のシステムディス
クとアプリケーションディスクを作成する。トラブル発生時には該当ディスクを設置場所へ送付し、設置場所担当者が交換する。管理者はリモートにて動作確認をする。
交換作業を設置場所担当者に委ねることで、コスト削減が図れると考えた。

– 31 –

4.5 提案するアーキテクチャの利点

システムディスク

/(root)

/usr

/etc

/etc3

passwdpasswd/var/local/home

ユーザディスク

図 4.6 PICKLES のファイルシステム

4.5

提案するアーキテクチャの利点

提案するアーキテクチャは PICKLES の技術的コンセプトを導入し、定点観測システム
をアプリケーション部とデータ部に分離した。これにより、いくつかの利点が発生する。

• システムトラブルの際、ディスク交換の作業で済む。
• HDD の交換作業を設置場所担当者に委ねることで、コスト削減につながる。
• アプリケーションにトラブルが生じた時でも、異なった HDD に存在する観測データに影響は出ない。

– 32 –

第5章

評価
本章では、既存システムと提案に基づいたシステムにおいて、トラブルが発生した場合の対処方法を作業量を算出することにより、コスト比較を行う。コスト比較により、提案したアーキテクチャの評価を行い、本提案の有用性を示す。
はじめに、本章で用いる用語の説明をし、コストを計算するにあたっての条件を示す。次に、既存システムでトラブルが起こった場合の一連の流れを ML を元に確認する。そして、
既存システムのメンテナンスコストを算出することで、今まで不明確だったメンテナンス費用を明らかにする。さらに、提案するシステムのメンテナンスコストを算出し、従来のシス
テムとコストの比較検討を行う。最後に結果をまとめる。

5.1

用語説明

まず、表 5.1 では説明に使う用語を説明する。
ここで、トラブルが起こったときの従来の対処方法を大まかに説明する。

1. 発見者は ML にトラブル内容を報告する。
2. 管理者はそのトラブル内容の調査を行う。
3. リモートでトラブルが解決する時は、管理者がリモートで作業を行う。もし、物理的なトラブルが起こった場合、保守業者が設置場所へ向かい作業を行う。

4. トラブルの対処が終われば、管理者は動作確認を行い、 ML に作業終了報告をする。

– 33 –

5.2 計算に使う仮定条件

表 5.1

説明に使う用語集

用語

説明

管理者

定点観測システムの管理者。

設置場所担当者

ローカルサーバを設置してある場所に属する担当者。
トラブルを発見した人。プロジェクトに属する人は全員発見者になり

発見者

うる。
プロジェクトがシステムの保守のために委託している業者。委託して保守業者いる業者のうち、ローカルサーバの設置場所から近い場所にある支店が担当する。

ML

5.2

プロジェクトのメーリングリスト。

計算に使う仮定条件

運用保守にかかるコストの比較をするに当たり、以下の仮定を用いて算出を行う。

• トラブル発見から対処終了後の動作確認までのコストを計算する。
• 運用・保守を行う管理者と保守業者の仕事量は人月計算を行う (ここでは人時で計算している)。

• トラブルの発見者は管理者とする。
• 管理者は東京、保守業者は大阪に居るとする。
• 定点観測システム設置場所は高知とする。
• システム管理に伴う出張費は移動に伴う拘束時間に対する費用を含む。
• 保守業者 が大阪から高知 (高知から大阪) に移動する場合、空路で交通費は表 5.2 より
片道 11,500 円かかり、移動時間は 40 分とする。交通機関までと駅から設置場所までの移動費と移動時間は無視する。

• ハードディスクを送付する場合、ハードディスクの重量は 1 台 900g とし、梱包の重さは無視する。

– 34 –

5.3 従来の対処方法の整理• ハードディスクを送付する場合、郵便小包を用い、料金は表 5.3 と表 5.4 より計算する∗1 。1 台郵送する場合は 820 円である。

• ハードディスクを送付する場合、梱包する時間と郵便局へ持って行く時間は合計 20 分とする。

• PC を送付する場合は 140 サイズ (140cm 以内、20Kg 以内) のパソコン宅急便を用いる (図 5.1 は荷物の大きさ, 表 5.5 は宅急便のサイズ表, 表 5.6 はパソコン宅急便の料金
表 ∗2 )。

• 送付するためのハードディスクを作成する際は、マスターディスクを作り、それをコピーする。

• ハードディスクのコピーにかかる時間は 1 時間 50 分とする。
• FreeBSD をインストールする場合の所用時間は 1.5 時間とする。
• コストの金額は小数点以下四捨五入とする。

表 5.2

大阪 - 高知間 移動料金 (空路の場合)

料金

空港名

時間

↑

大阪国際空港

↑

空路

40 分

高知空港

↓

11,500 円↓

5.3

従来の対処方法の整理

ML を元に既存システムでトラブルが起こった場合の対処方法を場合分けして整理し、対処に必要なおおよその対処時間を仮定する。なお、対処時間は 1 箇所当たりの作業時間とする。
∗1 http://www.post.yusei.go.jp/∗2 http://kuronekoyamato.co.jp/– 35 –

5.3 従来の対処方法の整理

表 5.3

小包の地帯区分 (高知県発着の場合)

第一地帯
第二地帯

第三地帯

第四地帯

市内

その他

同一市町村

静岡県、愛知県、 富山県、石川県、 茨城県、栃木県、 北海道、青森県、内、同一郵

岐阜県、三重県、 福井県、福岡県、 群馬県、埼玉県、 岩手県、秋田県、

便区内

滋賀県、京都府、 佐賀県、熊本県、 千葉県、東京都、 山県県、宮城県、大阪府、兵庫県、 長崎県、宮崎県、 神 奈 川 県 、山 梨
奈 良 県 、和 歌 山

鹿児島県、沖縄県

県、鳥取県、岡山

福島県

県、新潟県、長野
県

県、島根県、広島県、山口県、香川県、徳島県、愛媛県、高知県、大分県

5.3.1

セキュリティホール発見の場合

表 5.7 にセキュリティホールが発見された場合についての対処法を示し、対処時間を仮定
する。

C
A

A+B+C=荷物の大きさ

B
図 5.1

宅急便：荷物の大きさ– 36 –

5.3 従来の対処方法の整理

表 5.4

小包の料金表 (高知県発着の場合)

第一地帯
重さ

第二地帯

第三地帯

第四地帯

610 円

710 円

820 円

1,020 円

630 円

770 円

870 円

980 円

1,180 円

750 円
..
.

930 円
..
.

1,030 円..
.

1,140 円..
.

1,340 円
..
.

表 5.5

宅急便サイズ表市内

その他

2kg まで510 円

4kg まで6kg まで..
.

サイズ名

荷物の大きさ重さ

60 サイズ60cm 以内

2Kg まで80 サイズ80cm 以内

5Kg まで100 サイズ100cm 以内

10Kg まで

120 サイズ

120cm 以内

15Kg まで

140 サイズ

140cm 以内

20Kg まで

160 サイズ

160cm 以内

25Kg まで

ML によると、この作業は全設置場所に対して行ったものであり、並列して作業を行っている。作業時間は、 ML に「丸一日作業でした。」という言葉が存在したため、8 時間と仮
定する。

5.3.2

WWW が更新されない場合

表 5.8 に WWW が更新されない場合についての対処法を示し、対処時間を仮定する。表5.8 のように、ネットワークの復旧を待つ場合、設置場所依存となりうることが多い。作業時間は 1 時間と仮定する。

– 37 –

5.3 従来の対処方法の整理

表 5.6

資材名称

パソコン宅急便料金表

主な対応機種宅急便サイズ

内寸 (cm)

耐重量

ノートパソコン

100 サイズ31 × 34 × 9

5Kg まで本体・液晶モニタ

140 サイズ42 × 42 × 25

12Kg まで

プリンタ

160 サイズ41 × 66 × 20

12Kg まで

160 サイズ43 × 43 × 46

20Kg まで

料金

パソコン宅急便

BOX A(ノートタイプ)

600 円＋宅急便運賃パソコン宅急便

BOX B(本体タイプ)
パソコン宅急便

BOX C(プリンタタイプ)
パソコン宅急便

BOX D(モニタタイプ)

5.3.3

モニタ

(15・17 インチ)

1200 円＋宅急便運賃プログラムバグ発見の場合

表 5.9 にプログラムバグ発見の場合についての対処法を示し、対処時間を仮定する。

表 5.7

従来の対処方法：セキュリティホール発見の場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 管理者はセキュリティ勧告の内容に従い、リモートで作業する

8 時間

3. 管理者は ML に作業完了の連絡をする

5分

4. 管理者は動作確認をする

10 分

コスト

8 13 人時– 38 –

5.3 従来の対処方法の整理

表 5.8

従来の対処方法：WWW が更新されない場合

対処方法

時間
データが取得されていなく、原因がネットワーク不調の場合

1. 発見者が ML に連絡する

5分

2. ネットワークの復旧を待つ

1 時間

3. ネットワークが復旧したなら、設置場所担当者は ML に報告する

5分

4. 管理者は動作確認をする

10 分

合計時間

1 13 時間
データが取得されていなく、原因が設置機器にある場合

1 発見者が ML に連絡する°

5分

2 管理者が設置場所担当者に連絡する°

5分

3 設置場所担当者は PC を再起動する°

10 分

4 管理者は ML に作業完了の連絡をする°

5分

5 管理者は動作確認をする
°

10 分

コスト

7
12 人時

5.3.4

クラッキング対処の場合

ML より、ローカルサーバがクラッキングされたことが判明してから、chkrootkit ∗3 という検索ツールを用いて各サーバのチェックをし、そのサーバが踏台となって他のサーバがク
ラッキングされていないかの調査している。それに伴う、バージョンアップなどの対処全て終了するまで、19 日を要している。
そのため、対処にかかった時間を特定できない。よって、以下の仮定に基づき計算すると
式 5.4 のようになり、1 箇所当たり 13 時間かかったとする。

∗3 http://www.chkrootkit.org/– 39 –

5.3 従来の対処方法の整理

表 5.9

従来の対処方法：プログラムバグ発見の場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 管理者は内容を調査し、訂正する。

1 時間

3. 管理者は ML に作業完了の連絡をする

5分

4. 管理者は動作確認をする

10 分

コスト

1 13 人時• 19 日間終日働いたとする。
• クラッキングの対処とは、クラッキングされたところの対処と他のサーバへの被害がな
いか調査し、クラッキングされないように対処することを作業に含める。

• 19 日間の総合計を作業箇所数で割り、1 箇所当たりにかかった時間とする。

1 箇所当たりの時間= 総作業時間 ÷ 作業箇所数(5.1)= (8 × 19) ÷ 12

(5.2)

= 152 ÷ 12

(5.3)

; 13

(5.4)

表 5.10 にクラッキング対処の場合についての対処法と対処時間を整理した。

– 40 –

5.3 従来の対処方法の整理

表 5.10 従来の対処方法：クラッキング対処の場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 管理者は調査し、処置を行う。また、クラッキングされたところが踏台

13 時間になっていないか調査し、処置を行う。

3. 管理者は ML に作業完了の連絡をする

5分

4. 管理者は動作確認をする

10 分

コスト

13 13 人時

5.3.5

ハードディスクに異常発見の場合

表 5.11 に、HDD に異常が発見され、 OS が起動しなくなった場合についての対処法と対処時間を整理した。
表 5.11

従来の対処方法：ハードディスクに異常発見の場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 保守業者は PC を外しに行く

40 分

3. 保守業者は PC を管理者に発送する費用

11,500 円
2,880 円

4. 管理者は HDD を交換後、再インストールする

3 時間

5. 管理者は PC を設置場所へ発送する

2,880 円6. 保守業者は設置場所へ行き、PC を設置する

40 分

7. 保守業者は ML に作業完了の連絡をする

5分

8. 管理者は動作確認をする

10 分

コスト

4 23 人時– 41 –

11,500 円

28,760 円

5.4 提案する手法に基づく対処方法

5.3.6

ウィルス対処の場合

ML によると、FreeBSD のセキュリティ勧告に従いセキュリティ patch をあてている。
表 5.12 にウィルス対処場合についての対処法と対処時間を仮定する。
表 5.12 従来の対処方法：ウィルス対処の場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 管理者は調査をする

1 時間

3. 管理者はウィルスチェックとセキュリティ勧告に基づいた作業をする

3 時間

3. 管理者は動作確認をする

10 分

4. 管理者は ML に作業完了の連絡をする

5分

コスト

4 13 人時

5.3.7

マザーボードが故障した場合

このトラブルは別のトラブルから派生した作業となったものである。このトラブルが単独で起きたことを想定して、表 5.13 に マザーボード故障した場合についての対処法と対処時間を仮定する。

5.3.8

HUB が故障した場合

表 5.14 に HUB が故障した場合についての対処法と対処時間を仮定する。

5.4

提案する手法に基づく対処方法

ここでは提案するシステムを用いた場合の対処方法を示す。管理者がマスターディスクをコピーする時間は 1 時間 50 分と仮定している。これは、コピーをする方法に依存するため、– 42 –

5.4 提案する手法に基づく対処方法

表 5.13

従来の対処方法：マザーボードが故障した場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 保守業者が PC を外しに行く

40 分

3. 保守業者が PC を管理者に発送する

11,500 円
2,880 円

4. 管理者がマザーボードを交換する。

1.5 時間5. 管理者が PC を設置場所へ発送する

2,880 円6. 保守業者が設置場所へ行き、PC を設置する

40 分

7. 保守業者は ML に作業完了の連絡をする

5分

8. 管理者は動作確認をする

10 分

コスト

3 16 人時

表 5.14

費用

11,500 円

28,760 円

従来の対処方法：HUB が故障した場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 設置場所担当者は HUB を交換する

30 分

3. 設置場所担当者は ML に作業完了の連絡をする

5分

4. 管理者は動作確認をする

10 分

コスト

5
6 人時

ML 内で HDD をコピーした時の時間を参考にしている。

– 43 –

5.5 実際の金額計算

表 5.15 提案する手法に基づく対処方法 (1 箇所対処を行う場合)

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 管理者はマスターディスクをコピーする

1 時 間 50

費用分

3. 管理者はコピーされた HDD を設置場所担当者に郵送す

20 分

820 円

る

4. 設置場所担当者は PC の電源を落し、HDD を新旧交換

20 分

後、再起動する

5. 設置場所担当者は ML に作業完了の連絡をする

5分

6. 設置場所担当者は古い HDD を管理者に郵送する

20 分

7. 管理者は動作確認をする

10 分

コスト

3 16 人時

5.5

820 円

1,640 円

実際の金額計算

本節では 5.2 節で算出された仕事量を用いて実際の金額を計算した。費用は経済状況に応じて変動するため、一人月 100 万円で計算を行う。
まず、5.2 節の仮定を用いて一人時を求める。この金額を用いて、各トラブルの対処費用を求める。

1, 000, 000 円
20 日= 50, 000 円

1 日当たりの人件費=

1 日当たりの人件費
1 日の労働時間
50, 000 円=
8 時間= 6, 250 円

1 時間当たりの人件費=– 44 –

(5.5)
(5.6)
(5.7)
(5.8)
(5.9)

5.6 結果

5.5.1

従来の対処方法の試算

ここでは、従来の対処方法について試算する。途中計算は、付録 B で示す。
表 5.16

結果 (1 箇所当たりのコストの比較)

従来の対処方法

提案する手法に基づく対処方法

費用 (円)

費用 (円)

セキュリティホール発見

52,083

21,953

WWW が更新されない (設置機器)

3,646

2,604

WWW が更新されない (NW 不調)

8,333

8,333

プログラムバグ発見

8,333

21,953

クラッキング対処

83,333

21,953

HDD に異常発見

55,047

21,953

ウィルス対処27,083

21,953

マザーボード故障

47,75247,752

HUB が故障

5,208

5,208

トラブル内容5.6

結果

本節では既存システムと提案に基づいたシステムのトラブル対処方法のコスト比較の結果をまとめる。

5.6.1

コスト比較

作業コストを算出し、表 5.17 にまとめた。
表 5.17 より、総額が約 3 分の 1 に削減することができた。

– 45 –

5.6 結果

表 5.17 より、セキュリティホール発見、クラッキング対処、 HDD に異常発見、ウィルス対処の場合において、コスト比較の結果より対処できることが判明した。

WWW が更新されない、マザーボードが故障、 HUB が故障のトラブルについては、提案に基づく手法でも、同じコストとなる。
他に郵送の場合では、荷物は早くて翌日、遅くとも 2 日後に到着する∗4 。よって、提案する手法に基づく対処方法では、最短で 2 日で作業が終了する。

∗4 http://www.post.yusei.go.jp/– 46 –

5.6 結果

表 5.17
トラブル

件

内容

数

結果 (コストの比較)

従来の対処方法
作業量

費用

(人時)

(円)

提案する手法に基づく対処方法
合計

(人時)

(円)

作業量

費用

合計

(人時)

(円)

(人時)

(円)

1640

4,370

2,263,200

セキュリ
ティホー

138

8 13

11,500

3 16

41

7
12

23 11
12

7
12

23 11
12

4

1 13

5 31

1 13

5 13

14

1 13

186 233 161640

443 1322,96014

13 311866 32

3 16

1640

443 1322,960

13

4 23

3 16

1640

41 16

21,320

4

4 13

3 16

1640

126 2365,600

2

3 16

3 16

27,9606 1355,920

1

5
6

ル発見

WWW
が更新さ
れ な い

(設 置 機
器)

WWW
が更新さ
れ な い

(NW 不
調)
プログラ
ムバグ発
見
クラッキ
ング対処

HDD に
異常発見
ウィルス
対処

25,88060 23

336,440173 13

マ ザ ー
ボード故

27,9606 31

55,920

障

HUB が
故障
合計
総額 (円)–

5
6–13822 1112

5
6392,360
86,790,797– 47 ––

5
6–

5460 1920

2,451,360
26,971,316

第6章

考察
本章では、前章で作成したプロトタイプの実装と評価の結果をもとに考察を行う。

6.1

ハードディスクの容量

5.2 節で示したように、HDD の交換により管理コストを削減することができた。しかし、トラブル以外にも HDD の容量を越えた時にも HDD の交換作業が必要となり、管理コス
トを増大させてしまう恐れがある。
定点観測システムで、増え続けるデータはデータディスクに蓄積される観測データである。観測データは毎時 10 分毎に更新され、24 時間稼働し続けている。そこで、ML に記載されていた景観画像の容量より、データディスクが容量を越える目安を算出する。
まず、ML に存在した画像データを以下に整理する。

• 1 月 1 日から 9 月 24 日までのファイル容量は、約 3,663MB (Windows2000 の NTFS
フォーマット)• 1 月 1 日から 9 月 24 日までの日数は、267 日

一日当たりのデータ量= 3, 663(M B) ÷ 267(日); 13.72(M B/日)
一年間当たりのデータ量= 3, 663(M B) ÷ 267(日) × 365(日); 5007.47(M B)– 48 –

(6.1)
(6.2)
(6.3)
(6.4)

6.2 データディスクが破損した場合の復旧方法

これより、1 年間で約 5GB の画像情報を HDD に蓄積することになる。この目安を用いて、データディスクの容量を選ぶことができる。

6.2

データディスクが破損した場合の復旧方法

本提案では「システムディスク」「アプリケーションディスク」に異常が発見された時には有用であることが示せた。
しかし、観測地点に依存した観測データを蓄積した「データディスク」が破損する場合も当然起こりうる。ここではデータディスクが破損した場合の復旧方法について検討する。
ローカルサーバのデータは 10 分毎にセントラルサーバのデータベースに登録されている。
つまり、ローカルサーバのデータはセントラルサーバにコピーされていることになる。デー
タディスクが破損した場合、新しいディスクと交換して、セントラルサーバのデータを取得することで復旧できると考える。
他にユーザディスクにバックアップを取るという方法もある。この場合は、ユーザディス
クの内容をデータディスクにコピーするだけで復旧できる。

6.3

複数台ディスクコピーを取る場合

本研究で用いた PICKLES では、システム管理者の労力を軽減することも重要な課題となっている。

2.2.4 節で示したように、PICKLES の運用技法では管理者は HDD のコピーを行わず、
PICKLES 生産工場で行われる。しかし、現実には工場から出荷されるということはなく、今回提案したシステムの運用面でもディスクコピーの手間という問題がある。5.4 節ではディ
スクコピーに 2 時間要すると仮定した。しかし、所用時間はコピーする方法に依存する。

HDD をコピーする方法は何種類か存在する。HDD をコピーする時間が長くなり、コストを増大してしまっては意味が無い。コピーの方法によって、所用時間が事なるため、コ
ピーの方法について議論する必要がある。以下では HDD のコピーをする方法について紹介– 49 –

6.3 複数台ディスクコピーを取る場合

する。

6.3.1

dd を使う場合

dd はファイルのコンバートおよびコピーを行うコマンドである。dd は標準入力を標準出力にコピーする。入力データはブロック単位で読み書きするため、コピー時間はコピー元のHDD の容量の大きさに比例する。実際に 8.4GB と 40GB の HDD のコピーを行った (表
6.1)。
表 6.1

6.3.2

ハードディスクを dd でコピーした時の時間

容量

所用時間

8.4GB

約 1 時間 50 分

40GB

約 6 時間 10 分

dump-restore を使う場合

dump はファイルシステムのバックアップを行うコマンドである。restore は dump コマ
ンドで作ったバックアップからファイルやファイルシステムを元に戻すコマンドである。両方とも、コピーにかかる時間はファイルのサイズに依存する。よって、HDD の使用領域が大きければ大きい程、コピーにかかる時間は長くなる。

6.3.3

ハードディスクデュプリケータを使う場合

HDD デュプリケータとは HDD のコピー機である。一度に複数の HDD をコピーできるので、コピーにかかる時間が短縮できる。デュプリケータは通常高価な物が多いので、導入するには初期投資が必要となるが、I 社のもののように安価なものも市場には存在する。I
社の製品は一度に 2 台、T 社の製品は一度に 3 台のコピーが可能である。
製品情報を元に、8.4GB と 40GB の HDD のコピーを 1 台ずつ行った際の所用時間を計– 50 –

6.3 複数台ディスクコピーを取る場合

算した (表 6.2)。
表 6.2

メーカー

ハードディスクをデュプリケータでコピーした時の時間

所用時間

1G 当たりの所用時間

価格

8.4GB

40GB

I社

9,800 円

約1分

約 8 分 20 秒

約 40 分

T社

105,700 円

約 44 秒

約6分

約 30 分

次に、5.4 節で計算した提案に基づく対処方法に I 社の製品を利用した場合、表 6.3 のようになった。ここでコピーした HDD の容量は 40GB とする。
表 6.3

提案する手法に基づく対処方法にデュプリケータを用いた場合

対処方法

時間

1. 発見者が ML に連絡する

5分

2. 管理者はマスターディスクをコピーする

40 分

3. 管理者はコピーされた HDD を設置場所担当者に郵送する

20 分

4. 設置場所担当者は PC の電源を落し、HDD を新旧交換後、再起

20 分

費用

820 円

動する

5. 設置場所担当者は ML に作業完了の連絡をする

5分

6. 設置場所担当者は古い HDD を管理者に郵送する

20 分

7. 管理者は動作確認をする

10 分

コスト

2 人時

820 円

1,640 円デュプリケータを利用した場合のコストの比較を表 6.4 に示す。これより、コストは仮定を用いて計算した値の約 60%になる。

– 51 –

6.4 複数箇所を対処した場合のコスト

表 6.4

提案する手法に基づく対処方法にデュプリケータを使用した場合の結果 (コストの比較)

トラブル内容セキュリティホール発

件数

1 回あたりのコスト

合計

作業量 (人時)費用 (円)

作業量 (人時)費用 (円)

138

2

1640

276

226,320

41

7
12

見

WWW が更新されない(設置機器)

23 11
12

5 13

WWW が更新されない(NW 不調)4

1 13

プログラムバグ発見

14

2

1640

48

22,960クラッキング対処

14

2

1640

48

22,960HDD に異常発見

13

2

1640

26

21,320

ウィルス対処

4

2

1640

8

6,560

マザーボード故障

2

3 16

27,9606 1355,920

HUB が故障

1

5
6

6.4

5
6

総コスト

–

–

5
442 12

総額 (円)––

2, 765, 104

356,040

複数箇所を対処した場合のコスト

5.4 節で示したように、提案に基づく対処方法では 1 箇所当たり 3 61 人時と費用は 1640 円と試算された。セキュリティホールの発見など複数箇所を対処すべき原因の場合、マスター
ディスクのコピーやコピーした HDD を発送するところなどで、コストを削減することができる。コピーの方法については 6.3 節で説明し、デュプリケータを用いて複数台コピーした
場合にもコストダウンできることが分かった。また、HDD の発送については、1 回で発送

– 52 –

6.4 複数箇所を対処した場合のコスト作業完了することになる。よって、複数箇所を対処する場合でも、提案は有用であることが言える。

– 53 –

第7章

むすび
本論文では、既存システムである定点観測システムの運用・保守の効率を挙げるために、

PICKLES の概念を用いたシステムアーキテクチャを提案した。また、そのプロトタイプを実装し、運用保守の効率が上がることをコスト比較をすることにより実証した。
その結果、物理的なトラブルが起こった場合は、提案したアーキテクチャの方が少ない作業量で復旧させることができ、保守性が上がることが分かった。

7.1

今後の課題

本研究で提案したアーキテクチャには、残された課題が多々ある。本節では今後の課題について示す。

7.1.1

ネットワークを用いた実証実験

本研究ではスタンドアローン型でプロトタイプの実装を行った。実際のシステムでは、複数の観測地点に設置されたローカルサーバと、ローカルサーバの観測データを収集してWeb で公開するセントラルサーバで構成されている。既存システムと同じように複数のサーバと連携した場合に起こるトラブルが発見される可能性がある。そこで、複数台を繋げた形で運用する必要がある。

– 54 –

7.1 今後の課題

7.1.2

マニュアルの必要性

本研究では、管理者・設置場所担当者・その他関係者で構成される ML を利用し、作業量を増大させる原因を調べた。
そこでトラブルが発生した時のマニュアルが整備されていないことが分かった。2 年間で多くのトラブルが発生している。このトラブル内容を元に、対処方法や連絡方法などドキュメントとしてまとめることが必要だということが判明した。

7.1.3

ネットワーク監視の必要性

今回抽出されたトラブルの中に、ネットワークの不調を伴うものも多かった。日本全国に設置したサーバの連携なだけに、ネットワーク管理が重要だと感じた。ネットワーク管理
で有用なツールに MRTG (Multi Router Traffic Grapher)∗1 や RRDTool (Round Robin

Database Tool)∗2 がある。これらを活用するすることで、ネットワーク運用・管理の面で役立つと考える。

7.1.4

ユーザディスクの使い方

本提案では PICKLES の技術的概念を用いて OS 部分もシステムディスクとユーザディ
スクに分割している。実装では、システムディスクとユーザディスクに付け足す形で、アプ
リケーションディスクとデータディスクを追加した。

PICKLES 本来であれば、ユーザディスクの部分には利用者のホームディレクトリなどが存在する。しかし、定点観測システムでは各観測地点に設置し、データ収集に用いるため、ユーザのホームディレクトリは必要ない。そこで、ユーザディスクの使い道について検討する必要がある。
ここで、常に更新し続けられているデータディスクの予備、又はバックアップに用いるこ∗1 http://people.ee.ethz.ch/∼oetiker/webtools/mrtg/, http://www.mrtg.jp/∗2 http://people.ee.ethz.ch/∼oetiker/webtools/rrdtool/– 55 –

7.1 今後の課題とが適切ではないかと考えた。データディスクの予備として使う場合、データディスクの容量を常にチェックし続けて、ある一定量を越えた時に、保存先をユーザディスクに変更するというものである。しかし、ユーザディスクの容量を越えた場合やユーザディスクが破損した場合などについても議論が必要になる。
既存システムでは、何らかのトラブルで HDD を交換した場合、今までの観測データを

HDD に戻す方法として、セントラルサーバに蓄積されているデータをコピーするという方法で対処している。同じ PC 内にバックアップデータが存在した場合、ネットワーク経由でデータを復旧させるより短時間で復旧できるという利点がある。

– 56 –

謝辞
この研究をするに当たって、多くの方々の協力を得ました。深く感謝致します。
広域定点観測網実証コンソーシアムリーダーである、福島学院短期大学 情報ビジネスコ
ミュニケーション科 酒井 創 助教授には研究を始めるにあたり、助言をいただきました。また、定点観測システムを題材に使わせていただき、とても感謝しています。
株式会社 内田洋行 伊藤 博康さんと松井 聡さんには研究を始めるときの打合せに高知までご足労をおかけしました。その上、定点観測システムの機材、プログラム、多くの資料を提供していただき、質問にもたくさんお答えいただきました。深く感謝いたしております。
広域定点観測網実証コンソーシアムの皆さんには、メーリングリストの内容を活用させていただきました。メールで名前を見ているだけですが、その人の人柄や性格がうかがえました。
東京工業大学大学院 情報理工学研究科 数理・計算科学専攻 研究生 木本 雅彦さんには、
学部生の頃より、PICKLES に関することを色々と御指導いただきました。本研究で使用した、PC のインストール作業をお手伝いしていただきました。とても、感謝しています。
パソコン工房の山崎さんには、年末年始の忙しい時に PC を注文した上に、とても急かしてしまいました。挙げ句の果てには、納入後に「欲しい物と違う。」とまで言い出し、血管が切れるような思いをさせてしまいました。しかし、山崎さんのお力でプロトタイプの実装を完成させることができました。本当にありがとうございました。

6 年間通い続けたアルバイト先の皆さんには、一人暮らしの私にたくさんの食糧を分けていただきました。特に、経営者の先生には私の勝手から多大な迷惑をお掛けしてしまいました。週 2 回のお茶会は忘れないです。また、アルバイト先で出会った土佐山田町界隈に住んでいる生徒の皆さんは、いつも元気な挨拶や姿で接してくれ、私の活力源になりました。
菊池研究室の M2 の皆さんとは 6 年間の想い出を作ることができました。西内くんには日頃から BGM をたくさん貸してもらったり、お茶菓子を分けてもらいました。広瀬くんに– 57 –

謝辞

は行き詰まっているときに、違った方向からのアプローチ方法やアイデアを出してくれました。研究室に配属したての頃、舟橋くんには FreeBSD のインストール方法を手取り足取り
教えてもらいました。正岡くんはソフトからハードまで幅広く知識を持った人で、私のつまらない質問にもたくさん答えてくれました。豊島くんは研究室内唯一の M1 だったので、一番圧力を感じていたかもしれません。そんな中でも、相変わらずどこか抜けている性格がほのぼのとさせてくれました。学部生のメンバーには、短い間でしたが研究室活動において、ただならぬ努力をみせつけられました。このような、楽しい環境で研究活動をできたことは、私の成長にもつながったことと思います。
副指導教員である清水 明弘 教授、および情報システム工学科の先生方にも感謝いたします。
指導教員である菊池 豊 助教授には、研究について多くの御助言、御指導を頂きました。
ここに感謝の意を表します。
最後に、高知での生活を支えて下さった皆様、そして出会った皆様に感謝いたします。

– 58 –

参考文献[1] 木本雅彦, 大野浩之. 街角公衆情報端末計画 〜PICKLES の概要〜. 情報処理学会第 52
回 (平成 8 年前期) 全国大会 大会論文集 (6), pp. 381–382. 情報処理学会, March 1996.
講演番号 3Y-2.

[2] 木本雅彦, 大野浩之. 公衆情報端末計画 (PICKLES) におけるシステム設計と管理技法.
情報処理学会分散システム運用技術研究会. 情報処理学会, July 1996.

[3] 木本雅彦, 大野浩之. 自律型ネットワーク端末 (PICKLES) を用いたシステム運用技法.
情報処理学会 分散システム運用技術シンポジウム. 情報処理学会, February 1998.

[4] 木本雅彦, 大野浩之. POPS：FreeBSD における統一された利用者環境の構築. 情報処
理学会 DSM 研究会. 情報処理学会, June 2002.

[5] Jerry Peek, Grace Todino, and John Strang. 入門 UNIX オペレーティングシステ
ム. O’REILLY, July 1998.

[6] 渡部昌邦, 酒井創. 「インターネット時代の定点観測システム」〜地球環境を結ぶネッ
トワーク創りプロジェクトレポート. E スクエア・プロジェクト成果発表会, 2001.

[7] 木本雅彦. POPS：Package Of th PackageS 〜誰でも簡単マイパッケージ集〜. FreeBSD
PRESS NO.10, pp. 96–99, May 2002.
[8] 広域定点観測網実証コンソーシアム. 平成 12 年度 文部科学省教育用コンテンツ開発事
業広域定点観測網実証プロジェクト・納入報告書.

[9] 衛藤敏寿, のだまさひで, 細川達己, 内川善章, 天川修平, 三田吉郎, ゆっぴぃ. 改訂版
FreeBSD 徹底入門. 株式会社 翔泳社, September 2002.
[10] 岡本敏雄. インターネット時代の教育情報工学 1 ニュー・パラダイム編. 森北出版,
April 2000.

– 59 –

付録 A

広域定点観測網実証コンソーシアム
の活動

A.1

www.teiten2000.org

ここでは定点観測システムのホームページを紹介する。図 A.1 は、広域定点観測網実証コンソーシアムが提供しているホームページである。図 A.2 は、観測データを用いて学習に役立てるページへのリンクページである。学習に用いるページもコンソーシアムが提供している。

図 A.1 www.teiten2000.org(ホームページ トップページ)– 60 –

A.1 www.teiten2000.org

図 A.2 www.teiten2000.org(ホームページ 学習教材のページ)

図 A.3 www.teiten2000.org(ホームページ 現在のページ)– 61 –

付録 B

試算
本章では 5.5 節で算出された金額の計算の途中計算を示す。

B.1

従来の対処方法の試算

ここでは、従来の対処方法 (1 件当たり) について試算する。一人時は 6,250 円である。表B.1 は、従来の対処方法とそのコストである。
表 B.1

従来の対処法のコストトラブル内容件数

作業量 (人時)

セキュリティホール発見

138

8 13

従

WWW が更新されない (設置機器)

41

7
12

来

WWW が更新されない (NW 不調)

4

1 13

の

プログラムバグ発見

14

1 13

対

クラッキング対処

14

13 13

処

HDD に異常発見

13

4 23

方

ウィルス対処44 13

法

マザーボード故障

2

3 16

HUB が故障

1

5
6– 62 –

費用 (円)

25,88027,960B.1 従来の対処方法の試算

セキュリティホール発見
コスト= 作業時間 × 一人時

1= 8 × 6, 250
3156, 250=3; 52, 083 円

(B.1)
(B.2)
(B.3)
(B.4)

WWW が更新されない (設置機器)
コスト= 作業時間 × 一人時

7
× 6, 25012
43, 750=12; 3, 646 円
=

(B.5)
(B.6)
(B.7)
(B.8)

WWW が更新されない (ネットワーク不調)
コスト= 作業時間 × 一人時

1= 1 × 6, 250
325, 000=
3; 8, 333 円(B.9)(B.10)(B.11)(B.12)

プログラムにバグ発見
コスト= 作業時間 × 一人時

1= 1 × 6, 250
325, 000=
3; 8, 333 円(B.13)(B.14)(B.15)(B.16)

クラッキング対処
コスト= 作業時間 × 一人時

1= 13 × 6, 250
3250, 000=
3; 83, 333 円– 63 –(B.17)(B.18)(B.19)(B.20)

B.2 提案に基づいた対処方法の試算

HDD に異常発見
コスト= 作業時間 × 一人時 + 費用

2
= 4 × 6, 250 + 25, 880
31165, 140=3
; 55, 047 円(B.21)(B.22)(B.23)(B.24)

ウィルス対処コスト= 作業時間 × 一人時

1= 4 × 6, 250
381, 250=3; 27, 083 円(B.25)(B.26)(B.27)(B.28)

マザーボード故障
コスト= 作業時間 × 一人時 + 費用

(B.29)

1= 3 × 6, 250 + 27, 960
659, 375=+ 27, 960
3
; 47, 752 円(B.32)

コスト= 作業時間 × 一人時(B.33)(B.30)(B.31)

HUB が故障
5
× 6, 250
6
15, 624=3; 5, 208 円=

B.2(B.34)(B.35)(B.36)

提案に基づいた対処方法の試算

表 5.15 より、コストは 3 14 人時、費用は 1,640 円である。

コスト= 作業時間 × 一人時 + 費用

– 64 –(B.37)

B.2 提案に基づいた対処方法の試算
1= 3 × 6, 250 + 1, 640
487, 810=4; 21, 953 円– 65 –(B.38)(B.39)(B.40)