Y2Kが起こした事

10時間ほど前に世間で話題になっていた2000年の0時を迎えた。結局大した事は起きずにそのまま過ぎた。世間的には様々な情報が飛び交っていた。僕がそれについてどう考え、個人的にどう対応したのか、あるいはしなかったのかについてはここには書かない事にする。そうした事に付いて後から何か言っても価値が無い。言うなら前に言え、ということになる。
（コンビニエンスストアに乾パン、チキンラーメン10食パック、電池入り懐中電灯が売られていて驚いた事だけは記録のために書いておこう！売れたんだろうか？）

今回のY2Kトラブルで皆の目にはっきりした事は何だったろうか。人間が怠惰だと言う事だろうか。エンジニアは保守的だと言う事だろうか。設計者は近視眼的だと言う事だろうか。僕らの生活が技術に守られすぎていて、僕らが既に機械から自立する能力を無くしている事だろうか。コンピュータの反乱と言う古典的なSFのネタがいよいよ現実になったと実感した人も多かろう。
コンピュータ屋、ネットワーク屋から見て、Y2Kトラブルが示した事のうち重要度が高い点は、やはりネットワーク的なシステム、相互接続による結び付きの深いシステムはテストが難しくなったということだ。インターネット全体を相手にして稼働するシステムにとって、将来発生するかも知れない現象を実際にテストシステムで発生させて動作検証するということは非常に困難だ。

僕は何年かにわたって数回行なわれた日蝕インターネット動画中継のためのWWWミラーサイトの運用を試みた事がある。インターネット上に分散した WWW ミラーを作って、ある瞬間にやってくる大量のトラフィックを負荷分散して対応させるのである。アクセスは地球の裏側からもあり、そのようなサイトとのパケット伝送における latency は秒単位にもなる。ロスト率も高く、TCP のコネクション確立の途中で待ち状態に陥る場合も多い。それぞれのトラブルは次々とやってくるトランザクションによって、解決される以前に積み重ねられていく。
ネットやコンピュータの仕掛けを知っている人なら、それがシステムにとって大きな負荷になる、また急所に突き刺さる針になるということがわかるだろう。

こうした状況の中でも、確実に一定量のトラフィックを処理し、マシンがダウンせずにサービスを継続できる事がインターネットのサーバには要求される。しかしそのシステムが、本当に厳しい状況で正しく機能するのか、ダウンするとしたらどの程度までもつのか、事前に測る事はなかなか難しい。ベンチマークテストをしようにも、実験室の中で発生させる事が出来るようなトランザクションだけでは、先に示したような実際にシステムをダウンに導く要素を再現できているうちには入らない。

latencyやパケットロストも含めて、余りにも複雑な現実のインターネットでのトラフィックを再現することは非常に難しい。それと同様、ネットワークなどで結ばれたシステム同士の相互干渉を含むシステム全体を検証するのは非常に困難になっている。
Y2Kに限らず、何か全国のシステム全体に関わるようなトラブル要因について、完全に検証する事は果して可能なのだろうか？例えば JR を取り上げてみる。運航システムだけなら検証は楽かも知れないが、列車を仲介として発生するトラブル、例えば踏切の検証もある。踏切を渡る自動車を仲介とする問題なら道路の信号との連係か。乗車する人間を仲介とした問題は更に多い。駅の券売からはじまって次発の列車の案内システム、エスカレータまで含めた検証となると絶望的に見える。なに、電子ロックのカードキーに期限情報が含まれているかもしれないって？
いったいどうしたらいいんだろう。

Yutaka Yasuda

2000.01.01