(57)【特許請求の範囲】
【請求項１】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムであって、
前記負荷分散装置は、
前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたＩＤ（IDentifier）、および、前記分散処理システムへの参加日時を記憶する記憶部と、
前記クライアントマシンから、処理対象のデータの生成日時と当該データのＩＤとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのＩＤと前記リクエストにおけるデータのＩＤとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、
前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ＩＤ空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、
前記選定したサーバに、前記リクエスト送信する処理部と、
を有することを特徴とする分散処理システム。
【請求項２】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける分散処理方法であって、
前記負荷分散装置は、
前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたＩＤ（IDentifier）、および、前記分散処理システムへの参加日時を記憶する記憶部と、処理部と、を有しており、
前記処理部は、
前記クライアントマシンから、処理対象のデータの生成日時と当該データのＩＤとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのＩＤと前記リクエストにおけるデータのＩＤとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、
前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ＩＤ空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、
前記選定したサーバに、前記リクエスト送信する
ことを特徴とする分散処理方法。
【請求項３】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置であって、
前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたＩＤ（IDentifier）、および、前記分散処理システムへの参加日時を記憶する記憶部と、
前記クライアントマシンから、処理対象のデータの生成日時と当該データのＩＤとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのＩＤと前記リクエストにおけるデータのＩＤとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、
前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ＩＤ空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、
前記選定したサーバに、前記リクエスト送信する処理部と、
を有することを特徴とする負荷分散装置。
【請求項４】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置による負荷分散方法であって、
前記負荷分散装置は、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたＩＤ（IDentifier）、および、前記分散処理システムへの参加日時を記憶する記憶部と、処理部と、を有しており、
前記処理部は、
前記クライアントマシンから、処理対象のデータの生成日時と当該データのＩＤとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのＩＤと前記リクエストにおけるデータのＩＤとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、
前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ＩＤ空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、
前記選定したサーバに、前記リクエスト送信する
ことを特徴とする負荷分散方法。
【請求項５】
コンピュータを請求項３に記載の負荷分散装置として機能させるための負荷分散プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のマシン（サーバ等のコンピュータ）が協調してデータ処理を行うクラスタ構成の分散処理システムにおける技術に関する。
【背景技術】
【０００２】
近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のマシンを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。
【０００３】
分散処理を行う際には、処理対象のデータを、クラスタを構成する各マシン（以下、「クラスタメンバ」とも称する。）に振り分けておく必要がある。このとき、クラスタ全体での処理能力を高めるためには、各クラスタメンバが担当するデータ数は平均化されていることが望ましい。
【０００４】
代表的なデータの振り分け手法として、各データのｋｅｙをハッシュ関数にかけた値（以下、「ｈａｓｈ（ｋｅｙ）」と称する。）をクラスタメンバ数Ｎで割った余り、即ち「ｈａｓｈ（ｋｅｙ）  ｍｏｄ  Ｎ」を番号として持つクラスタメンバにデータを振り分ける手法がある。この場合、各クラスタメンバに事前に０からＮ−１までの番号を割り当てていることが前提となる。このような振り分け手法を用いた場合、クラスタメンバを追加すると、Ｎの値が変化して、多くのデータについて、担当するクラスタメンバが変更になるため、担当するデータの再配置が必要になる。
【０００５】
そこで、クラスタメンバの追加に伴い担当するクラスタメンバが変更になるデータ数を約１／Ｎに抑える方法として、コンシステント・ハッシュ［Consistent Hashing］（非特許文献１参照）を用いた振り分け手法があり、Amazon Dynamo（非特許文献２参照）等で用いられている。このコンシステント・ハッシュ法を用いたデータ振り分け手法では、クラスタメンバとデータの双方にＩＤ（IDentifier）を割り当て、データのＩＤからＩＤ空間を時計回りに回った場合に最初に出合ったクラスタメンバを担当とする。また、クラスタメンバに対するＩＤの与え方の例としては、ＩＰ（Internet Protocol）アドレスをハッシュ関数にかけた値（以下、「ｈａｓｈ（ＩＰアドレス）」と称する。）が挙げられる。
【０００６】
ここで、図７を参照して、コンシステント・ハッシュ法についてさらに説明する。図７はＩＤ空間を表し、黒丸（●）がサーバのＩＤを示し、線分（｜）がデータのＩＤを示す。各データは、ＩＤ空間内を時計回りに回った場合に最初に出合うサーバによって担当される。このようにすることで、各サーバに対して確率的に平等な負荷分散を行うことが可能になる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】David Karger et al., “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”, [online], 1997, ACM, [平成23年7月1日検索], インターネット<ＵＲＬ：http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf>
【非特許文献２】Giuseppe DeCandia et al., “Dynamo: Amazon’s Highly Available Key-value Store”, [online], 2007, ACM, [平成23年7月1日検索], インターネット<ＵＲＬ：http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf >
【発明の概要】
【発明が解決しようとする課題】
【０００８】
コンシステント・ハッシュ法を用いたデータ振り分けを実施した場合、クラスタメンバの追加や削除に伴い担当が変更となるデータ数を抑えることができ、追加や削除に伴うクラスタ全体に対する負荷を軽減することが可能である。しかし、クラスタメンバを追加する場合、追加されたクラスタメンバに着目して考えると、ＩＤ空間上で担当する領域にあるデータを他のクラスタメンバから移動する必要が生じるため、追加直後に高い負荷が生じることになる。即ち、クラスタメンバを追加したにも関わらず、追加直後にはクラスタ全体での性能が向上しないことが考えられる。
【０００９】
そこで、本発明は、前記した事情に鑑みて創作されたものであり、コンシステント・ハッシュ法を用いた分散処理システムにおいて、クラスタメンバを追加した場合に、既存データの移行を行わないことで、システム全体に対する負担の増加を抑制することを課題とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するために、本発明は、コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムであって、前記負荷分散装置は、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたＩＤ、および、前記分散処理システムへの参加日時を記憶する記憶部と、前記クライアントマシンから、処理対象のデータの生成日時と当該データのＩＤとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのＩＤと前記リクエストにおけるデータのＩＤとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ＩＤ空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信する処理部と、を有することを特徴とする。
【００１１】
これによれば、コンシステント・ハッシュ法を用いた分散処理システムにおいて、負荷分散装置は、データの生成日時が候補のサーバの参加日時よりも古いときは、前記したようにして候補のサーバを選定し直すことで、クラスタメンバ（サーバ）を追加した場合でも、既存データの移行を行う必要がなく、システム全体に対する負担の増加を抑制することができる。
【００１２】
また、本発明は、コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置であって、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたＩＤ、および、前記分散処理システムへの参加日時を記憶する記憶部と、前記クライアントマシンから、処理対象のデータの生成日時と当該データのＩＤとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのＩＤと前記リクエストにおけるデータのＩＤとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ＩＤ空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信する処理部と、を有することを特徴とする。
【００１３】
これによれば、コンシステント・ハッシュ法を用いた分散処理システムにおける負荷分散装置は、データの生成日時が候補のサーバの参加日時よりも古いときは、前記したようにして候補のサーバを選定し直すことで、クラスタメンバ（サーバ）を追加した場合でも、既存データの移行を行う必要がなく、システム全体に対する負担の増加を抑制することができる。
【００１４】
また、本発明は、コンピュータを前記負荷分散装置として機能させるためのプログラムである。
【００１５】
これによれば、このようなプログラムを実装したコンピュータを負荷分散装置として機能させることができる。
【発明の効果】
【００１６】
本発明によれば、コンシステント・ハッシュ法を用いた分散処理システムにおいて、クラスタメンバを追加した場合に、既存データの移行を行わないことで、システム全体に対する負担の増加を抑制することができる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態の分散処理システムを含む全体構成図である。
【図２】本実施形態のサーバ管理テーブルの構成図で、サーバ追加前の状態を示す図である。
【図３】本実施形態のＩＤ空間の概念図で、サーバ追加前の状態を示す図である。
【図４】本実施形態のサーバ管理テーブルの構成図で、サーバ追加後の状態を示す図である。
【図５】本実施形態のＩＤ空間の概念図で、サーバ追加後の状態を示す図である。
【図６】本実施形態のロードバランサによる処理の流れを示すフローチャートである。
【図７】従来のコンシステント・ハッシュ法を説明するためのＩＤ空間の概念図である。
【発明を実施するための形態】
【００１８】
以下、本発明を実施するための形態（以下、実施形態と称する。）について、図面を参照（言及図以外の図も適宜参照）しながら説明する。図１に示すように、本実施形態の分散処理システム１０００は、クライアントマシン１からのリクエスト（「メッセージ」とも称する。）をネットワーク２経由で受け取るロードバランサ３（負荷分散装置）と、ロードバランサ３によって振り分けられたリクエストを受け取ってデータ処理を行う複数のサーバ４（４ａ，４ｂ，４ｃ，４ｄ）とを備えて構成される。なお、複数のサーバ４について、特に区別しないときは「サーバ４」と表記し、区別するときは「サーバ４ａ」などと表記する。また、本実施形態では、まず、サーバ４ａ，４ｂ，４ｃの３台が稼動していて、途中でサーバ４ｄが追加されるものとする。
【００１９】
ロードバランサ３は、コンピュータであり、処理部３１、記憶部３２、入力部３３、表示部３４および通信部３５を備える。
処理部３１は、記憶部３２に記憶された情報に基づいて各種演算処理を行う手段であり、例えば、ＣＰＵ（Central Processing Unit）とメモリによって実現される。
【００２０】
記憶部３２は、各種情報を記憶する手段であり、例えば、ＲＯＭ（Read Only Memory）やＨＤＤ（Hard Disk Drive）などによって実現される。また、記憶部３２はサーバ管理テーブル３２１を格納する（詳細は後記）。
【００２１】
入力部３３は、ロードバランサ３のユーザが情報を入力する手段であり、例えば、キーボードやマウスによって実現される。
表示部３４は、情報を表示する手段であり、例えば、ＬＣＤ（Liquid Crystal Display）によって実現される。
通信部３５は、外部装置との通信に用いられる通信インタフェースである。
【００２２】
サーバ４は、例えば、セッション制御サーバである。複数のサーバ４がクラスタ構成で協調して動作する。また、セッションの確立に用いられる通信プロトコルはＳＩＰ（Session Initiation Protocol）（「J.Rosenberg, et.al, “SIP: Session Initiation Protocol”, RFC3261, IETF, 2002.6」参照）であるものとする。また、クラスタを構成する各サーバ４で管理しているデータは、呼状態データであるものとする。
【００２３】
ここで、分散処理システム１０００における動作の概要について説明する。クラスタにサーバ４ｄが追加された後、ロードバランサ３は、クライアントマシン１からのリクエストを、コンシステント・ハッシュ法と、リクエストの対象となるデータの生成日時（ＩＮＶＩＴＥの処理日時）およびサーバ４の分散処理システム１０００への参加日時に基づき決定する（振り分け先の決定方法は後記）。そして、追加されたサーバ４ｄには新規データへのリクエスト（サーバ４ｄの追加以降にＩＮＶＩＴＥがロードバランサ３に到着したリクエスト）のみが割り当てられ、残りのサーバ４ａ，４ｂ，４ｃには、既存データへのリクエスト（サーバ４ｄの追加以前にＩＮＶＩＴＥがロードバランサ３に到着したリクエスト）と新規リクエストが割り当てられる。
【００２４】
次に、図２を参照して、ロードバランサ３の記憶部３２に格納されるサーバ管理テーブル３２１について説明する。図２に示すように、サーバ管理テーブル３２１ａ（３２１）は、サーバ４のＩＤ、サーバ名、および、分散処理システム１０００への参加日時のカラムを含んで構成され、サーバ４のＩＤの昇順でソートされている。なお、サーバ管理テーブル３２１ａは、サーバ４ｄが追加される前のものであるので、サーバ４ａ，４ｂ，４ｃに関する情報のみが格納されている。また、サーバ４のＩＤの作成方法例としては、ＩＰアドレスをハッシュ値変換したものが挙げられる。
【００２５】
分散処理システム１０００にサーバ４ｄが追加された場合には、そのサーバ４ｄからロードバランサ３に通知を行い、それを受けてロードバランサ３がサーバ管理テーブル３２１を更新する。なお、サーバ管理テーブル３２１に格納される参加日時としては、ロードバランサ３がサーバ管理テーブル３２１を更新したときのタイムスタンプを使用すればよい。また、ハッシュ値変換する対象は、ＩＰアドレスに限らず、その他、ＭＡＣ（Media Access Control）アドレスや、あらかじめ決めた名前など、そのサーバ４を特定できるものであれば何でもよい。
【００２６】
次に、呼状態データへのＩＤ付与方法の例について説明する。呼状態データのＩＤは、例えば、ＳＩＰメッセージのリクエストヘッダのＣａｌｌ−ＩＤとＶｉａヘッダのｂｒａｎｃｈを組み合わせた値をハッシュ値変換したものとすればよい。また、ＩＤをＩＮＶＩＴＥ受信時に計算してＳＩＰメッセージのＴｏヘッダのＴａｇ等に書き込むことで、ロードバランサ３でＴｏヘッダのＴａｇに書き込みがあるかで新規呼（Ｉｎｉｔｉａｌ  ＩＮＶＩＴＥ）と既存呼（非Ｉｎｉｔｉａｌ  ＩＮＶＩＴＥ）を判別することも可能である。ロードバランサ３は、ＳＩＰメッセージからＩＤと呼状態データの生成日時を取得し、振り分けアルゴリズム（後記）に従ってＳＩＰメッセージを各サーバ４に振り分ける。振り分けられたサーバ４ではＳＩＰメッセージの処理を行い、呼状態データを保持する。
【００２７】
次に、図３を参照して、データの振り分けについて概念的に説明する。図３は、コンシステント・ハッシュ法のＩＤ空間を示した図であり、サーバ４ｄの追加前の状態を示す図である。つまり、図３は図２に対応している。図３のＩＤ空間では、図７と同様、黒丸（●）がサーバ４のＩＤを示し、線分（｜）がデータのＩＤを示している。そして、各データＡ〜Ｅは、ＩＤ空間内を時計回りに回った場合に最初に出合うサーバ４によって担当される。具体的には、データＡ、Ｂはサーバ４ｃに担当され、データＣ、Ｄはサーバ４ａに担当され、データＥはサーバ４ｂに担当される。
【００２８】
次に、図４，５を参照して、分散処理システム１０００にサーバ４ｄが追加された場合のサーバ管理テーブルの構成とデータの振り分けについて説明する。図４は図２に対応し、図５は図３に対応している。
図４に示すように、サーバ４ｄが追加された場合のサーバ管理テーブル３２１ｂ（３２１）は、サーバ４ｂの行の下にサーバ４ｄの行が追加されている。つまり、ここでは、サーバ４ｄについて算出したＩＤの数値が、サーバ４ｂのＩＤの数値よりも大きく、サーバ４ｃのＩＤの数値よりも小さかったものとする。
【００２９】
この場合、図５に示すように、ＩＤ空間では、サーバ４ｂから時計回りに少し移動した位置にサーバ４ｄが配置される。そして、その後に処理対象となったデータ（サーバ４ｄの参加日時より新しいデータ）のＩＤをα、β、γ、δとし、図５のように配置されたものとする。この場合、各データのうち、データＡ以外は、ＩＤ空間内を時計回りに回った場合に最初に出合うサーバ４によって担当される。そして、データＡは、ＩＤ空間内を時計回りに回った場合に最初に出合うサーバ４ｄではなく、その次に出合うサーバ４ｃによって担当される。これらを実現するためのアルゴリズムに基づく処理の流れについて、以下で説明を行う。
【００３０】
図６に示すように、ロードバランサ３の処理部３１は、クライアントマシン１からネットワーク２経由でメッセージを受け取ると、そのメッセージから呼状態データのＩＤを取得する（ステップＳ１）。
【００３１】
次に、処理部３１は、コンシステント・ハッシュ法に基づき、メッセージを振り分けるサーバ４の候補を選定する（ステップＳ２）。
次に、処理部３１は、そのメッセージから呼状態データの生成日時を取得し、その呼状態データの生成日時が、該当するサーバ４（ステップＳ２で選定したサーバ４）の参加日時（記憶部３２のサーバ管理テーブル３２１から取得）よりも新しいか否かを判断し（ステップＳ３）、Ｙｅｓの場合はステップＳ４に進み、Ｎｏの場合はステップＳ５に進む。
【００３２】
つまり、サーバ４の参加日時の方が古い場合（ステップＳ３でＹｅｓ）、当該データはその選定したサーバ４が管理していることになるので、ステップＳ４に進む。一方、データの生成日時の方が古い場合（ステップＳ３でＮｏ）、当該データが生成された日時にはその選定したサーバ４が存在していなかったことになるため、ステップＳ５に進んで異なるサーバ４を選定する。なお、コンシステント・ハッシュ法の性質上、次に当該データを管理している可能性の高いサーバ４は、サーバ管理テーブル３２１における次の（１行下の）サーバ４なので、ステップＳ５でそのサーバ４を選定する。
【００３３】
ステップＳ５において、処理部３１は、ステップＳ２で選定したサーバ４を基準にＩＤ空間を時計回りに回って次に出合うサーバ４を新たに選定し、その新たに選定したサーバ４の参加日時を、記憶部３２のサーバ管理テーブル３２１を参照することで確認し、ステップＳ３に戻る。
【００３４】
ステップＳ４において、処理部３１は、そのメッセージをそのサーバ４（ステップＳ２またはステップＳ５で選定したサーバ４）に送信し、処理を終了する。そのメッセージを受信したそのサーバ４は、メッセージに基づいたデータ処理を行う。
なお、ロードバランサ３は、クライアントマシン１からメッセージを受け取るたびに、この図６に示す処理を行う。
【００３５】
このようにして、本実施形態によれば、コンシステント・ハッシュ法を用いた分散処理システム１０００において、クラスタメンバ（サーバ４ｄ）を追加した場合に、既存データの移行を行わないことで、システム全体に対する負担の増加を抑制することができる。
【００３６】
つまり、各データについて担当するサーバ４を決定するロードバランサ３は、データの再配置を行わなくてもいいように、リクエストが既存データに対するものであるかを判別し、既存データに対するリクエストの場合には、データを保持しているサーバ４にリクエストを割り当てる。
【００３７】
そして、ロードバランサ３は、追加されたサーバ４ｄに対しては既存データを割り当てず、そのサーバ４ｄの追加以降にクラスタで管理することになった新規データについてのみ割り当てを行う。なお、新規データは、追加されたサーバ４ｄを含むすべてのサーバ４に振り分けられる。これらの処理により、追加されたサーバ４ｄに既存データを移行する必要がないため、追加直後に高い負荷が生じることはない。
【００３８】
なお、本実施形態による手法は、特に、ＳＩＰの呼状態のように、データの更新頻度が高く、既存データより新規データの処理の方が多い場合に有効である。
【００３９】
以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、本発明は、コンピュータをロードバランサ３として機能させるためのプログラムとしても具現化可能である。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００４０】
１      クライアントマシン
２      ネットワーク
３      ロードバランサ
４，４ａ，４ｂ，４ｃ，４ｄ  サーバ
３１    処理部
３２    記憶部
３３    入力部
３４    表示部
３５    通信部
３２１，３２１ａ，３２１ｂ  サーバ管理テーブル
１０００  分散処理システム
【図１】
0005544523.tif 000002
【図２】
0005544523.tif 000003
【図３】
0005544523.tif 000004
【図４】
0005544523.tif 000005
【図５】
0005544523.tif 000006
【図６】
0005544523.tif 000007
【図７】
0005544523.tif 000008