現在、iBook 500を１台占有して稼働している、Facelessな「高速富士山」のシステムに対し、AppleScript StudioでGUIをつけた「高速富士山.app」から技術のフィードバックを行ってみた。
なんてことはない、ただ単にダウンロードを並列処理で行うように変更しただけだが、その影響たるやとてつもなく大きい。メイン処理がすぐにダウンロードから解放される（shellコマンドで並列処理する）ようになったため、いくらダウンロードに時間がかかってもおかまいなしである。
各ダウンロード処理は、60秒でタイムアウトするように指定してあり、それ以上処理が長引いて、未完の処理を山のように抱え込んで自滅するようなことはない（Mac OS Xに移行した当初にはそういうこともあった。どうしてクラッシュするのか、ひたすら苦悩した）。
たとえていうなら、「高速」高速富士山という状態になったというべきだろうか。かなりシステムが頑丈になったのだ。
開発中のGUI版の高速富士山.appに110か所ばかりライブカメラを登録し、ためしに巡回させてみたところ……さすがに並列処理モードでも、巡回数が増えた分だけパラメータの組み立てなどのオーバーヘッドが大幅に増加し（ダウンロードの処理要求部分は一瞬で終わる）、ひととおり処理するのに45秒ぐらいかかった。順次処理させた場合には３分ぐらいかかったので、並列処理のメリットが最大限に発揮されているのだが、驚きだ。
こんなに時間がかかるのか〜、という驚きに加え……110か所でも１分以内に処理できてしまうのか！ という驚きもある。
１分を切っているということは、110か所のライブカメラ巡回をそのまま通常運用できるというわけで……Mac OS 9の時代から比べてソフトウェアが単純に50倍程度のパワーアップを果たしたことになる。
昔は、２か所ぐらいでひーこら言っていたのだ。いまのノウハウをMac OS 9環境にフィードバックすれば、それなりに性能は向上しただろうが、やっぱりMac OS Xは足回りが強くてピーキーな処理でもめげないのがよい。Mac OS 9のときには、かなり厳密にシミュレーションを行って、「このぐらいの仕事量ならクラッシュしない」という確認を事前に行う必要が、どうしてもあったのだ。基本的にOSを信用していなかったともいえる。
ほとんど冗談のような110か所のライブカメラ巡回……そのまま、ムービーの生成までひととおり試験運用してみてもよいが、地球上の異なるタイムゾーンに位置するライブカメラを一括して管理するような機能は、まだ実装されていない。
最終的には、異なるタイムゾーンに所属するライブカメラの巡回を行うダウンロード用マシンと、ムービー圧縮をキューイング＆実行するコンプレッサー用マシン数台とでクラスタ構成にして、地球上のあらゆる場所のライブカメラを随時高速ムービー化するシステムにしてしまいたい。
地球上のありとあらゆる景色を高速ムービー化し、時間と空間を超えてムービーの中に地球上のあらゆる風景をタイムカプセルよろしく封じ込めてしまうのだ。こういうのにものすごく男のロマンを感じる。男のロマンというのは、基本的に非経済的かつ無駄で元のとれない話ばかりだが、これはその最たるものだろう。
採算面はともかく無視することにして、技術面ではどうだろうか。
Xserveを３台ぐらい＋Xserve RAIDを使えばすぐにできそうだ。この構成でパフォーマンスがどの程度出るか、実機で検証してみないと分からないが、ムービー圧縮を同時に複数プロセス走らせることができれば大丈夫だろう。最低構成で、ダウンロード用のXserveが１台に、圧縮用のXserveが２台。それぞれ、共通のディスクアレイにアクセスして、地球上のさまざまなタイムゾーンにあるライブカメラを攻略するのだ。
そうなったらなったで、新たな管理ツールが必要になる。
各ライブカメラがどのようなフェーズにあるかが一目見て分かるタイムゾーン別のタスクスケジューラや、処理分散の様子が分かるパフォーマンスメータ。そして、この調子で処理を行ったら、すべての計算機資源が能力オーバーを起こさないか事前に予測するオーバーフローチェッカなども必要になる。
ほとんど、宝くじにでも当たらないかぎり実現しそうにない構成なので、想像すること自体が無意味といえば無意味なことだが、いざやろうとした時に、最終的なイメージがあるのとないのとでは大きく異なる（なにが？）。
……なんの話だったか。そう、110か所もテストデータを登録してまわった（チェックしたライブカメラはその数倍）ので、かなり疲れたのだ。公開版の高速富士山.appには最初から100か所以上のライブカメラのデータを登録して出すつもりだ。とはいっても、それらをすべて巡回させた場合には、１日で0.5Gバイト程度……ワーク用を含めればGバイトオーダーのディスクスペースが必要になるし、ムービー圧縮にしても８時間程度で終了するかどうか……。
驚いた！ 冗談半分で試算してみたところ、１拠点あたり４分以内で画像の破損チェックと自動補完処理、さらにインポートと圧縮が行えれば、なんとか100か所程度を１台のマシンで処理できそうだ。G5のデュアル機でも使えば実現できてしまいそうな話である。
現在、すべての画像をダウンロードした後に画像の破損チェックと欠損フレームの補完処理を行っている。高速富士山用システムでは、ほとんどの時間、CPUはリアルタイムクロックを監視して、次の「分」になるまでの待ち合わせ処理を行っているだけだ。つまり、ほとんどの時間は遊んでいるのだ。
この間に画像の破損チェックを行えていたら、かなり時間の節約になるだろう。別プロセスで画像の破損チェックと自動フレーム補完を行う、バックグラウンド処理専用のツールを走らせておけばよいのだ。こういうものこそ、先日のNSTaskを用いてバックグラウンドで走らせておくべきか。
画像ダウンロード処理の、残り２時間程度になった時点で、このフレーム補完プロセスを別途立ち上げ、自己診断して異常フレームの破棄と欠損フレームの補完を行わせてみるとよいかもしれない。
16時間ダウンロードを行っているうちの14時間分だけでも処理しておければ、ずいぶんと時間の節約になる。残りは、すべてをダウンロードした後で処理すればよい。
なんだ、すごくできそうな気がしてきた。これで、自分がObjective-Cでも書ければ、Xserveなどと言わずに普通のマシンで、100か所の処理でもなんでもできてしまうのかもしれない。
そこまで言わないまでも、時間のかかる処理だけでもCやObjective-Cで書けると楽しいにちがいない。