Copyright (c) 2003 Digital Infra, Inc. All rights reserved.
<<BACK
Copyright (c) 2003 Digital Infra, Inc. All rights reserved.
|
|
|
|
・EveryWhere to GO ・Reset to GO ・dize ・dime ・2万9800円PC ・HAHA - High Availability High Acceleration ・michitsuna Powered by HAHA |
|
| 弊社が今後10年間かけて追求していきたい次世代コンピュータシステム。どこまでできるかはわからないけど。 |
| Everywhere to GO 技術領域 | Everywhere to GO 全体概念図 | |||||
 |
 |
|||||
|
|
・Remote GUI ・Remote Print ・Remote File ・MultiHoming Virtual Private Network (MHVPN) |
 ・MultiHoming Virtual Private Network (MHVPN) |
|
通信回線において、NTTの専用線をこえる信頼性を、はるかに低コストで実現する技術。コストパフォーマンスは10倍以上。それでいて今の専用線より信頼性も高い。高度に暗号化された通信内容を複数の回線に分散することにより実現。 NTTの専用線は、信頼性以外はろくなものではない。まず、高い遅い。コストパフォーマンスはADSLの100分の一以下。さらに、営業（に限らず従業員の99％）があまりにも無能すぎる。カタログに書いてあることもしらない。ビットとバイトの区別すらつかないし、だからといって勉強する意欲なんてまったくない。いいよなぁ、あれで食えるんだから。ようは信頼性以外はすべて最悪なのだが、いまだに使われている理由はビジネス用途に耐える信頼性。 |
|
MHVPNは、まず暗号化により、第一種電気通信事業者の従業員（ようはNTTの回線メンテのオヤジ）にもデータの盗聴や改竄を不可能にする。つぎに、MHVPNは複数回線へデータを分散し、故障した回線は自動的に切り離すことにより、安価な回線（＝信頼性が低い）を使った場合でも全滅するリスクを回避する。99.99%故障しない回線を一本契約するより、99%故障しない回線を3本契約するほうが全滅するリスクは低い。 （なお、3本を選ぶとき、同じ業者の回線ではだめ。かならず、いろいろな業者を混ぜて選ぶこと。さらに、このとき、一見別の業者に見えるが、実は違うのは名前だけ、という業者が結構あるので注意） |
|
この二つの技術により、NTTの専用線を越える信頼性をはるかに低コストで実現できる。これによって、銀行以外のすべてのデータ通信回線からNTTの専用線を追放できるんじゃないかな。 こうやって一連の技術を説明すると凄い技術に思えるが、YAMAHAのRTシリーズなら実は設定さえすれば全機種可能。ただ、設定が非常に理解しがたい。この辺を参照。 ここ ここ ここ ・・・・など。 やってみればわかるんだけど、われわれのようにそれで食っている連中でも、設定方法を理解するのになんだかんだ数日かかった。そして、一通り理解したいまでも設定に毎回数時間かけて大騒ぎ。結局、設定方法の定型化、設定サービスの体系化がポイント。やり方はいっぱいあるけど、多分、VPNルータにリモート設定機能をつけて、設定センターみたいなの作って、そこからリモート設定することになるだろう。ただ、これとかも、ネットワーク構成図とかがセンター側に正確に告知されないとどうしようもないので、ネットワーク構成図の書式（誰でも書き込めるようなの）、書き込みマニュアルの作成、営業なり現場作業員なりにたいする書き込み方の教育・・・といろいろ考えるべきところはある。あと、この場合、認証(ハッカーがまぎれ込ませた偽ルータがVPNに入り込まないようにする機能)の関係で、公開鍵のインストールってやつをやる必要があるんだけど、このセキュリティも悩ましいところ。問題が起こる可能性は極めてわずかなはずだけど、ここでなにかあると、セキュリティが根本から崩れるから。 |
 |
|
ようは、Citrix の Metaframe やWindowsXPの remote desktop と同じ機能。VNCとかNorton PC AnyWhere っていったほうがわかりやすいならそれでもOK。 この機能に関しては、弊社（というか、JeyJokar)はかなーり前から研究してて（かれこれ10年ぐらい）、ひとつ理解したのは、データ転送量の削減も重要だが、レイテンシも重要だな、ってこと。転送量の削減には、圧縮やキャッシュといったお約束のテクを駆使すればいいし、極端な話、速い回線を契約する（つまり、カネで解決する）という必殺技もできる。実は、単にsshでgzip圧縮をするだけでもかなり効果がある。しかし、レイテンシに関しては、「速い回線を買うことはできても、少ない遅延を買うことはできない」ってわけで、金で解決することがかならずしも常にできるとは限らないし、それ以前に、この問題の重要性の大きさを認識してる人がいないのもびっくり。LBXの作者も、「つくってみたらレイテンシの影響がすごくて驚いた」とかいってたぞ。作ってみたら、ってのがポイントですかね。 |
|
結局、この問題の解決の唯一の方策は、端末側にアプレット（のようなもの）を乗せる。これしかない。 |
|
端末側によるショートカット: |
 |
|
別の言い方をすれば、サーバクライアント型オープンオフィスを作る。イメージとしては、Solaris + オラクルをホストにした業務用受発注システムの端末をWin2k + VisualBasicでつくるのとおなじ。べつに、こんなの新しい発想でもなんでもなく、X vs NEWS(ソニーのコンピュータではなく、サンのGUI)のときと同じなんですけど。やっぱゴスリンってことですかね。 目標としては、エアエッジ32kでオープンオフィスが実用的に使えること、なんだけど、どうなることだか。しかし、近い未来に、EV-DO + BREW + VGA(640*480) Display 搭載携帯電話、なんか出てきて、december 上に作られた仮想マシンを日本中どこからでも使えたら、とか考えると、夢があるよね（おい、夢かよ）。今現在(2003/4)えらそうなことを書いた割にはなんにも作ってないので、どうなることやら。 |
|
いまんところ決まってることを紹介します。端末にアプレットを乗せるわけですが、アプレットというとJavaというのが通り相場（というか、アプレットという用語自身、サンがJavaで使い出した用語）なのですが、これをJavaではなく、BREWみたいなネイティブコードにするつもりです。ごめんねゴスリン。優れた製品とは、実用性に優れているかが一番大切であって数学的に優れているかどうかはどうでもいいんだ。もちろん、ActiveXみたいなDLLそのまんまではセキュリティ上問題がありすぎるので、VMに閉じ込めますが（そういう意味でも、BREWそっくり）、Write Once Run Anywhere とかはある程度犠牲にします。理由なんですが、端末側ですと、どうしても細かいユーザインタフェースの作りこみが必要で、そうなると、Write Once Run Anywhere とかはあきらめざるを得ないんですね。やっぱりごめんねゴスリンです。eclipse が swing を使わず SWT を作ってしまった（そして、それが評判のひとつになっている）ことが、ひとつの答えでしょう。 |
 Remote print |
|
リモートプリント・はじめに |
|
モバイルで困るのが、紙へのアウトプット（プリントアウト）と、紙からのインプット（スキャニング）。まさかプリンタとスキャナ（と用紙（とインクカートリッジ））を常時持ち歩くわけにもいかないし。この解決法は結局、コンビニとかにあるコピー機（いま、コンビニにあるコピー機は、ほぼすべてのチェーンで、実態は高性能カラースキャナ＋カラーレーザープリンタ＋PC+通信回線）でプリントアウトとスキャンができるようにすること。具体的な事例は
ここ
や
ここ
で見てください。
私個人（JeyJokar)としては、このようなプリントとスキャンのアウトソースに関し、モバイルに限定しない方向性を考えています。これは弊社としての見解ではないですが、いわゆる「デジタルコンビニ」的な展開において、家庭用プリンタの代替を狙う、といった展開を考えています。「デジタルコンビニ」ともいえる存在については、最近たまに見る主にプロユースを想定した店、といった展開もあるのですが、それよりも、家庭用プリンタ（エプソンのカラリオとかね）の代替、といった用途を狙ってます。 いまの家庭用プリンタに満足してますか？。たしかに、画質はすごいし、値段も安い。この点に関しては、エプソンやキャノンの技術者の努力を素直に賞賛したいです。つーか、よくあんな値段で出せるよね。インクジェットだけじゃなく、レーザーの低価格化もすばらしいです。2万円でレーザー買えるんだよ！2万円だぜ！！！信じられるか！。あと、インクジェットで注目しているのが、用紙の豊富さ。アイロンで転写するとTシャツが作れる、とか、実にいろいろな用紙があります。とりあえずお遊びで手作りアルバムとか作るならいいかも。でも、実用性は・・・。まず、紙送り機構がダメすぎ。コストを考えればしょうがないんでしょうが、やはりだめなものはだめ。あと、ドライバがダメ。圧倒的な販売台数から来るスケールメリットを考えればもっとまともなドライバができるはずなのに、こちらは、正直やる気を疑います。結局、一枚一枚手差しして、「ちゃんと吸い込んでくれるかなぁ」「詰まったらいやだなぁ」「印刷ずれないかなぁ」「文字が化けないかな」とか見張ってないとダメなのが現状です。さらに、これはインクジェット特有の問題点ですが、ノズルが詰まる。レーザーはレーザーでブレーカーが飛ぶ。結局、PCじゃないですが、ドライバの相性問題なども含め、管理コスト、運用コストがかかりすぎ、ってのがプリンタの現状です。じゃあどうするか。 根本的な問題は、メカというものはプリンタに限らず定期的なメンテが必須なのに、家庭用では不可能、という点だと思います。整備の技術を持った人員が定期的に巡回し、部品の交換や内部の清掃などを行うことは精密機械には必須だと思うのですが、それを家庭用プリンターに対して実施するのは不可能です。その解決策は、やはり、「デジタルコンビニ」的存在を使うことでしょう。ここなら、定期的に整備員が巡回することが可能です。 |
|
リモートプリント・技術編 |
|
問題はデータフォーマット。あとは技術的には何とでもなる。むしろ、引っかかりそうなのはコンビニ会社やプリンタメーカの利害の衝突といった政治面。 唐突ですが、PDFに満足してますか？。規格自体はさすがアドビって感じの完成度の高さですが、それでもズレる。バケる。ズレないバケない、とかいう伝説は業界人すら信じてますが、所詮はハッタリだったようです。もちろん、アドビに言わせれば、それはPDFのせいではなく、フォントがどうのこうの、アクロバットリーダのバージョンがどうのこうの、プリンタドライバがどうのこうの、ってことになるのでしょうが、そんな難しいことわっかりっませーーーん。とにかく結果としてズレるバケるってのは事実。ってゆうか、細部まで完璧に設定すればズレない、っつーなら、MSワードだってズレないよ。 さらに、これは誰もが指摘しているけど、とにかくビュワー（アクロバットリーダ）がダメ。とにかく使いづらい。異様に遅いし、使いづらい。遅いし使いづらい。遅いし使いづらい。遅いし使いづらい。しかも、いつまでたっても改良されない。ディスティラ（PDFを作る側のソフト）は結構よくできてるのに・・・。なんかポリシーでもあるのかな。 PDFは、規格としては成功でも、企画としては失敗でしょう。 じゃあどうするか。PDFを改良することも考えたのですが、アドビとモメるとなにかと面倒な上、あれだけ複雑かつ高度な技術となると、よほど気合を入れないと手が出せません。つーわけで、勝手な新技術を開発しました。 |
|
リモートプリント ビットマップは効率悪いか？ |
|
答えはノー。 限界効率としては、テキストもベクトルもビットマップも同じなはず。すべて、意味的なエントロピーに収束するはず。あくまで「はず」だけど。ビットマップの欠点としては、データが大きい、編集ができない、検索ができない、拡大するとギザギザが出る、だけど、データ圧縮技術とパターン認識技術と画像処理技術をつかえば、なんとかなるはず。非常に困難だけど。逆に、ベクトルの欠点であるズレるバケるってのは、完璧なシステムという、理論上はともかく現実的には存在し得ないものを前提としない限り解決できない。 そんなわけで開発中の新フォーマットがこれよ。 OTTT(One To Ten Thousand)（ 1:1万の圧縮比、ってことね）。 ズレない、バケない、しかも簡単（なプログラミング）で、っつーのをテーマに開発中です。具体的には、1200DPI*24Bitのべたべたなビットマップ（無圧縮時、A4で400メガバイトぐらい）を、異様に高度な圧縮技術で圧縮し、普通のテキスト主体の文書の場合、A4で100キロバイト/ページぐらいにできるといいなぁ、って感じです。これでも、べたテキストにくらべれば100倍ぐらいの容量ですが、ブロードバンドがここまで普及した今、許していただけるのではないかと。 んなこと不可能だろう、とおもうでしょうが、たとえば、白黒2階調のデータなら、24bitフルカラーのビットマップデータを24:1に何も考えずに圧縮できます。さらに、ビットマップデータの冗長性からして、そっからさらに10:1ぐらいにはgzipでも圧縮できます。そうやって考えていけば、400メガバイトのデータを1メガバイトぐらいにするのは非常に簡単なことはわかると思います。現実問題として、プリンタ出力をトラップして作ったBMPをPNG圧縮するだけで、400:1ぐらいの圧縮効率がたたきだせることはあります。なお、PNG圧縮は、二次元差分をとってることをのぞけば、その実態は単なるLZ77（というか、もろgzip)です。よって、それをさらに改良すれば、1200DPIのA4画像を、100kバイトぐらいに圧縮することが可能なことを理解していただけると思います。というか、いまいろいろやってる基礎実験のデータからも、実現できる可能性は大です。もちろん、繰り返しますが、テキスト主体の場合です。 もうひとつ、ビュワーはとにかく賢く作ります。こっちのほうはまだぜんぜん手がけてませんが、徹底的にチューニングするつもりです。もともと、圧縮フォーマット自体が超高速ビュワーの実現を考慮して作ってあるのですが、さらにビュワーのコードレベルのチューニングも入れますので、いわゆる「紙をぱらぱらやる」感覚、パラパラ感とでもいうのかな、が実現できます。ページ描画を1INT、つまり1/60でVSYNCに同期してやるつもりです。PCでどこまでできるかわかりませんが。つーか、Acrobat Reader があまりにも遅すぎるので、どう作ってもアクロバットリーダを使った後なら凄く速く感じますがね。 |
 Remote File |
|
コンピュータセンターにファイルの実体を作り、インターネットさえあれば世界中どこからでも参照できるようにする技術。もちろん、暗号化やセキュリティはバリバリ。メリットは三つある。 |
|
１、場所を選ばない。 |
|
あー、あのファイル、会社のパソコンの中だぁ、とかいう悲鳴は、出張先や自宅などで毎晩聞かれているが、それが解決する。もちろん、悲鳴を上げてる場所にネットがなければどうしようもないけど、電話と同じ率でネットがある日もそのうちくるでしょ。多分。 |
|
２、災害に強い |
|
ファイルは、地理的に分散された複数のバックアップセンターに常時バックアップされる。HDDのクラッシュといった（社会全体から見れば）ショボいトラブルから、関東大震災のような（社会全体から見れば）とんでもないトラブルまで、まさに「災害は忘れたころにやってくる」が、そんな場合も問題なし。銀行の勘定元帳ならともかく、たかが文書ファイルごときに、地理的分散（たとえば、データを東京・大阪・札幌、3箇所のバックアップセンターに3重化して保管する）まで取り入れるのは大げさだと思うだろうが、「備えあれば憂いなし」だ。 |
|
３、共有できる |
|
あなたが明示的に許可すれば、ですが、自分のファイルを他人から読み書き可能に設定できる。当然、そこにはセキュリティバリバリなんで、他人が読める読めないはすべてあなたの許可に基づいており、だれがどのファイルを読み書きできるかは意図どおりに制御可能。 |
|
それと、将来的には、バージョニング（何世代もさかのぼって変更前のファイルが取り出せる機能）も取り入れます。 具体的な技術としては、いまのところ、実用性と機能性のバランスを考え、InterMezzoを中心に考えているが、別にそれにとらわれるつもりはない。もっと複雑な技術（だけど実用性には疑問）も論文レベルではいろいろあるし、逆に、単純（だけど実用的）な方向性では、単なる rsync や cvs といった技術でも何とかなるかもしれない。 |
 Reset to Go DIZE DIME 2万9800円PC |
|
リセット一発。 プレステ感覚のPC。 |
|
|
いままでも、ある程度いろいろなところで発表されてきた
（
ここ
とか)ブータブルCDを使ったLinuxディストリですが、有限会社デジタルインフラから、
その決定打を(われわれとしては）目指すディストリの技術がでます（2003/4）。 コンセプトは、とにかく管理コストの削減です。いまのPCに満足してますか？。いろんな本をよむと、「使い方が難しすぎる」とあります。はてまた、だから中高年のリストラの原因になって・・・とか。死ねって感じですね。ちょっとその気になれば誰でも覚えられるぐらいに今のGUIは進化してますよ。覚えられないのは、その気がないだけでしょう。べつにPCを自分で使わなければ仕事が不可能なわけじゃないし。PCが苦手なら使わないのもアリでしょう。その代わりPC以外の分野できっちり結果を出す。どうしてもPC操作が必要なら、それは得意な人にお願いする。これでもいいでしょう。文句タレてる人は、PCもだめ。PC以外の分野もだめ。そんな人だけでしょう。 しかし、PCにはものすごく問題があります。使い方が難しいとは思わないですが、しかし生産性の向上に結びつくとは思えないですね。企業にとって大切なのはOA化の推進ではなく生産性の向上なのですが。所詮、パソコンオタクのおもちゃに過ぎないんじゃないでしょうか。PCやネットによって生産性の向上を・・・とか唱えてる経営者もコンサルタントも政治家も、まったくもって見識を疑う、というよりか単なるバカでしょう。 問題は、管理コストが高すぎること。それウイルスだ、それバックアップだ・・・インストール、相性問題、デバイスドライバ・・・・もう面倒すぎ。それで食ってるわれわれですら面倒すぎるこの作業を、素人にやらせるとは言語道断でしょう。10年ぐらい前、SUNやIntelが TCO! TCO! とか叫びだして、Zero Administration PC だの Network Computer だの言い出したときは筆者(JeyJokar) としてはこれでようやくPCが生産性向上に結びつくのかな、とずいぶん期待してたのですが、結果としてはまったく流行らず。なんとかしてくれよぉ。 というわけで、弊社で何とか・・・できるといいなぁ。 なお、DIZEとReset to GO(RTG)の違いですが、ブータブルCDによるリセット一発Linuxを実現する技術がRTG。この場合、どんなH/Wでも確実に認識するわけじゃないので、その辺の保証や検証を行うのがDIZEです。この場合、DIZEとは狭義にはサービスなのですが、DIZEサービスで作られたCD（もしくはディストリビューション）までもDIZEと呼んでしまってOKです。あと、DIMEってのがあります。これは、サーバ系ディストロです。クライアントにも使えますが、主な用途は、サーバです。特徴は、自社（自宅）サーバと専用（または仮想専用）サーバとの間をシームレスに移行できることです。2万9800円PCは、DIZEを使い、リセット一発でOpenOfficeとMozillaが動くマシンです。これにより管理コストの削減をするというのが、一連の開発の最大の目的となっています。少し前までは、これをXboxでやろうと思っていたのですが、PCの価格の下落が予想以上に早かったので、最近はXbox Linuxにはいまいち関心をなくしています。逆に言うと、当社がXbox Linuxに関心を持っていたのは、リセット一発の即席情報家電を作るためだったのですが、あまり意味がなくなったと思います。いや〜、PCの世界の変化は早いですな。 ライセンス形態ですが、DIZEは基本が動作検証と動作保証というサービスにあるので、当然有料です。RTGはようはその中核はHDDキャッシュドライバなのですが、そのあたりはLinuxカーネルと同様、GPLで勝手に使えます。細かいことは決まってませんが、ようは、自分で検証、保証、サポートなどをやる（または最初からそのようなものを必要としない）ならば無料。そうじゃないなら有料となるでしょう。カネを払うか汗をかくか、ってことですな。これは、個人としてネットからダウンロードして頑張る！というのに限定せず、業者としてネットからダウンロードしてCDを自費でプレスして再販して儲ける、というのも含んでいます。DIZEのCD（むかし、LASER5というCD屋で売ってたようなもの）とか、DIZEプレインストールPC！などは勝手に作って儲けてください。ただし、サポートもご自分で。 あと、RTGとknoppixなどのそのほかのブータブルCD Linux技術との違いですが、Windows環境との共存に真剣に取り組んでいるかどうかが違いでしょう。RTGはDIZEなどの弊社の（有償）サービスと併用するのが前提なので、H/Wの認識問題などはせいぜいknoppixと同程度でしょう。かなりの率（多分knoppixと同じぐらいの率）で自動認識できるようにしますが、knoppix 同様、何らかの問題点は常に発生するでしょうし、それをゼロにする気は毛頭ないですし、さらにいえばそれは不可能です。問題があればDIZEサービスへようこそ、という対応です。逆に、DIZEサービスを使ってもらうためにも、Windowsとの共存や、ブート時間の短縮など、実用性と営業的訴求点の向上には力を入れていきます。 |
|
リセット一発パソコンは、有限会社デジタルインフラ （ www.digitalinfra.co.jp ） の DIZE サービスによりプロデュースされたパソコンで、Linux技術を隠し味に使い、プレステ感覚で使えるパソコンを実現しました。特色は、ソフトの動かし方にあります。事前の設定は一切不要です。CDを入れてリセットするとソフトが動きます。プレイステーションなどの家庭用ゲーム機とおなじ方式です。 |
|
その他の特徴として、信頼性の高さがあります。リセットすればCDから常に同じソフトウェアが読み込まれるので、ウイルス感染、ハッキング被害などからの回復はリセットするだけです。ハードウェアの故障の場合も、別のマシンにCDを入れてリセットすれば業務は継続できます。ソフトウェアが改良された場合は、新しいCDを入れてリセットしてください。 従来製品との比較 : 従来も、ほぼ同様の製品は存在していましたが、以下のような欠点がありました。DIZEでは、これらすべてに対策を施してあります。
|
| |||||||||||||||||||||||||
DIME
同一ディスクイメージを複数プラットフォームで動かすことを目的としたLinuxの新しいサーバ用ディストリビューション。
|
| DIZE 技術領域 | Reset to GO 技術領域 | DIME 技術領域 | DIME ディスクイメージの共有 | |||||
 |
 |
|
|
|||||
| バージョンアップ : | Version Up(和製英語) / 現在使用中のソフトの改良版が出た場合、それをインストールする作業 | |
| バックアップ : | Back Up / 故障や操作ミスに備え、データの予備を作る作業 | |
| リカバリ : | Recovery / 故障、ウイルス、ハッキングなどにより正常に動作しなくなったコンピュータシステムを復旧させる作業。 工場出荷時そのままの姿に戻す場合と、障害発生直前の状態に復旧させる場合がある | |
| TCO : | Total Cost of Ownership. 決まった訳語はないが、所有にかかる総費用と訳すのが普通。ようは、パソコンを買うときは、購入代金だけでなく、使いこなすのにかかるテマ・ヒマ・カネまですべて考えてから買いましょう、ということ。パソコン本体の価格が下落した今、パソコン本体の購入代金より、使いこなすのに必要なテマ・ヒマ・カネのほうが何倍も高い、とのデータも多い。 | |
| ブート : | boot. コンピュータを始動させる、という意味のコンピュータ業界の俗語。同義語としては、やはりすべて俗語だが「立ち上げる」「始動する」など。一般的な英語ではブーツ/長靴のこと。俗語として動詞もあるが、追い出す、クビにする、という意味になる。 | |
| CDブート : | CD boot. CD に入ったソフトウェアを電源ON時に実行させること。通常は、HDDに入ったソフトウェアが電源ON時に実行される。 | |
| ブータブルCD : | bootable CD. CDブート可能な形式のソフトウェアが入ったCDROM。 |
|
・ゼロ学習 これが最大のポイントです。CD入れてリセットするだけです。 これが学習時間ゼロで使えない人は、プレイステーションでゲームするときも「超図解！できるわかったプレステの使い方・ソフト起動編（イソプレス出版刊）」を読んでちゃんと学習してください（ねーよ、そんな本）。 ・信頼性 IT革命だ！（ウィンドウズ）パソコンで生産性の向上だ！と叫んでるコンサル連中は多いです。それを尻目に現実を直視すれば、実際に生産性が向上してるのか、すら疑問なのですが、それ以前に、パソコンって、現状でまともなビジネスツールたりえてますかね。個人的には疑問です。しょっちゅうクラッシュするし、トラブルも多いし、、、、。生産性向上という結果が現れてるかどうかを議論する以前に、手段としてまともに使えるかどうかを議論しなければいけないのは情けない。DIZEは、限りなくトラブルをゼロに近づけ、ビジネスツールとして使用に足りうる信頼性を提供します。 まず、インストールや設定の手間がありません。ウイルスにも非常に安全です。HDDクラッシュについてあれこれ考える必要性はありません。バックアップもネットワーク経由で勝手に行われます。ハードの故障の際も、別のPCにCDを入れてリセットすれば業務は続行できますし、PCの買い替えの際も、新しいPCにCDを入れてリセットするだけで移行できます。 ・互換性 今のPCにウィンドウズが入っていようといまいと、いずれにせよ、何も変更する必要はなく、CDを入れてリセットすれば動きます。ハードウェアに関する条件もかなり甘いので、あまり考えなくてもよいかと。さらに、ウィンドウズ環境との共存も考えていますので、やはりなにもかんがえなくてもよいかと。ウィンドウズ環境と共存させる場合、パーティションのきりなおしは一切不要です。また、NTFSの認識の問題でディスクが消える可能性もほぼゼロにしてあります。過去、マイクロソフト純正ソフトでもディスクが消える（可能性がある）ソフトはあったので、それを考えれば非常に互換性は高いでしょう。 つーか、パーティションの切り直し、デュアルブートの設定、ってのが、一般人にとってどれだけ高いハードルだったか、理解できないんでしょうかね。こんな（一般人にとっての）凄まじい恐怖を強要するだけでも、Linuxが流行るとは思えなかったです。ここらへんの、しょうもないことへの配慮が一般人に売るためには非常に大切なのですが。 |
|
必要システム： 一番のポイントはメモリ。各OSプレインストールモデルの標準搭載メモリ量から考えて、対Win98SEプレインストールモデルだと、メモリが一番ポイントになる。対Win2kでは問題ない。
|
|
その他動作環境： ウィンドウズはまったく不要。ウインドウズと共存できる、ってこととウィンドウズが必要ってのはまったく違う。ウィンドウズとの共存は可能だがウィンドウズは必要ではない。ウィンドウズが必要に思える瞬間はHDDにパーティションを切るときとNTFSでパーティションをフォーマットするときだけだが、実際にはこれもLinuxから可能 ( # /usr /sbin/ mkntfs /dev/hda1 )。 必須ではないけど、ADSL（じゃなくてもFTTHでもいいけど）は強くお勧めする。業者はフレッツでもヤフーでも何でもいい。なくても動くが、これがないと、オンラインバックアップもオンラインフォルダもバージョニングもなんにもできなくなってしまい、価値が半減する。 |
|
NTFSにしている理由： DIZE Linux プレインストール（というのも変な表現だけど）モデルのPCを買ったとき、あとでWindowsに移行するのを簡単にするため。っていうか、 「これ、便利ですよ。リセット一発でオフィスが使えて」「しかも、お安いんです」 「で、ウインドウズはどうなるの？」 という会話があったとき、「いやー、それはパーティションをきりなおして、、、」とかなるのと、「単にウィンドウズのマスターディスクを入れてリセットするだけっすよ。あとは勝手にインストールは進みます」とかなるのでは、売りやすさがまったく違う。 あと、当然、FAT32とかもサポートの予定。これは、Win98SEがいつまで生き残るかに依存するけど、一応。 |
|
HDDキャッシュファイルの構造： HDDキャッシュは、NTFS上の c:\ dize.***\***.bin (ちなみに、ドライブ名は任意。ディレクトリ名も、ルートにあってdize.*ならOK。さらに、自動検索がある。たとえば、なんかのつごうでC:にどーしてもキャッシュが作れず、D:につくっても、それはそれで勝手に発見される。）という馬鹿でかいファイルの中に作られる。この馬鹿でかいファイルは、Ext2FSパーティションのフォーマットを持っており、Linuxからループバックマウントをすることにより、あたかもそこにExt2FSのパーティションがあるように見える。 基本的には、Linuxから見た1パーティション＝NTFSからみた1ファイルだが、Linuxからみた1パーティションをNTFSからみた複数ファイルに分散させる機能も計画している。LVMみたいなものかな。これは、FAT32が1ファイル最大4Gバイトまでの制約があることが主な理由。 キャッシュファイルの内部構造だが、これをマウントしてLinuxからみたばあい、いまのところ、cloopのブロックを1ブロック1ファイルでext2上に浮かんでいるだけである。Ext2なので、ひとつのディレクトリに集中させると遅いので、多数のディレクトリに分けて入れてるけど、それを除けば、数万個のファイルがだだだだぁーと出てくるだけ（qmailのメールスプールの構造と同じ）（ウィンドウズから見れば、あくまでひとつの馬鹿でかいファイルであることに留意）。大笑いな構造だけど、問題なし。キャッシュデータの追い出しも、単に時刻でソートして古いものから追い出すだけ。やはり大笑いな手法だけど問題なし。Simple is the Best っすな。ただし、若干追い出しの際のソート（というか、その前処理）が遅いんで（そりゃブートごとにfind | sort してりゃ遅いよ）、時刻をキーにしてB-Treeでファイル名を引っ張るdbmを使う予定。 |
|
キャッシュファイルの構造、その１ インスタントパーティションはこのようにしてNTFSパーティション内につくられる。NTFSからみれば一本の巨大なファイルに過ぎないので、ウィンドウズ環境との共存にはまったく問題ない。 |
NTFS上につくる：
|
|
キャッシュファイルの構造、その２ インスタントパーティションの中身はこれ。 ようは、64kバイトのブロックに分割してパーティションごとCDROMに圧縮して記録する。で、それをブロック単位でHDDにキャッシュする。それと、CDROMの読み出し高速化のために、ブロックの並べ替えを行っている（フラットリードファイルシステム）。 それと、キャッシュデータはロックできる。あと、CDの空読みもできる。一度、CDを空読みしてそのキャッシュデータをロックしておけば、次からはCDがなくても動く。ただし、NTFS上にうかべたインスタントパーティションのなかのデータは普通のブートローダからは認識されないので、特別なブートディスクをつかうか、それとも特別なブートローダをMBRとか（別の場所でも何とかなるけど）に入れる必要性がある。だったら意味ないじゃーん。そんなことするなら、毎回CDを入れるほうがましじゃん、と思うだろうが、ポイントは故障時の対応。HDDにすべてのデータをキャッシュすることにより、CDROMドライブが壊れても業務が続行できる。 |
インスタントパーティション：
|
|
|
キャッシュファイルの構造、その３ Knoppix の cloop と違い、CDに書き込める（ようにみえる）。また、ネットワーク経由でバックアップ可能で、さらにスナップショットバックアップ。当然、スナップショット中も書き込みを含めたすべての機能は可能。なお、描画の関係でブロックのサイズが均等だが、実際には圧縮がかかるので均等ではない。 |
レイヤー構成：
|
|
CDの中身： 基本的には、すべてが入った馬鹿でかいファイル（ディスクイメージ）がバーンと寝そべっているだけ。その他に必須なものとして、ブートセクタがあるけど、それは普通の方法では見えない領域にあるし、これは el torito の問題なのでDIZEとは無関係。これ以外だと、まず、ボーナスデータ領域に、jpg や mp3 とかのどーでもいいファイルが山ほどある。これらは、Windowsからも参照できるように、普通のファイルになっている。あと、別項の「ユーティリティ法」のところで説明したCMOS書き換えユーティリティが入っている。それと、等価法のところで説明したブートフロッピーなどを作るユーティリティも入っている。あと、インスタントパーティションの大きさを増減するユーティリティとか。それと、WindowsからH/W情報を吸い上げて表示するユーティリティ、そのほかトラブルシューティング用ユーティリティ、など、とにかくいろんなユーティリティ（全部Windows)が入っている。で、これらを立ち上げるラウンチャ（超簡単なものでOK)があって、それがAUTORUN.INFで立ち上がり、、とか考えてるけど詳細は未定。 |
|
CD読み込みの高速化 その１： CDROMからの読み込みの高速化のため、フラットリードファイルシステムを採用している。PCに詳しい人は、昔の標準速時代の名残とかを引きずってて、CD = 死ぬほど遅い、というイメージを持っているが、最近の32倍速タイプとかなら、現実は連続リードならそこまで遅くない。ためしに、100Mバイトぐらいの巨大なファイルを空読みしてみてください。$ time cat /mnt/ cdrom/ bigfile.mp3 > /dev/null とか。40倍速タイプで外周にデータを入れていれば（一部のCDROM焼きこみソフトで可能）、普通 3Mバイト/秒ぐらい叩きだします。OSやドライバのオーバーヘッド込みでもここまでいけます。カタログスペック的には、40倍速ですと、最外周で6MB/secのはずです。しかし問題はランダムアクセス。これは確かにいまだに遅い。これを解決する一番簡単な方法は、連続アクセスで問題なくアクセスできるようなデータの配置にすること。具体的には、読み込まれそうな順番にデータを並べておく。 それ以外にも、いろいろと高速化テクニックはある。どこまで採用するかはわからないが、一通り書いておく。まず、よくあるのが、同じデータ（今回はブロック）を複数箇所に書くこと。A→Bという読み込みとD→Bという読み込み、二つがよく起きる場合、AとDの隣にBをそれぞれ重複して記録(ABとDBというデータを記録）する。これにより、ディスク容量は損をするがシークが減る。ただ、DIZEの場合、キャッシュ効果を考えると、とりあえず先に読まれる組み合わせのほうを書いておけばそれでいいような気も。 もうひとつよくやるのが先読み。こちらは、キャッシュ効果を考えるとDIZEでは非常に効果的だと思うので、実装可能性大。ようは、次に読み込みそうなところを先に読んでおく。実際には、フラットリードファイルシステムにおいては次に読み込みそうなところ＝ディスクイメージの次のブロック、なので、ようはこの巨大なファイルをずるずるっと読んでいけばいい。読み込まれた部分は適当にキャッシュされていく。これにより、うまくチューニングすれば、かなり連続リードの理論最高値に近い性能を引き出せるかもしれない。一番おいしいのは、ピックアップのセクタ待ち（データがあるトラックにはシークしているのだが、ピックアップ直下にまだセクタが来ていない状態）がなくなること。ずるずるっと読んでいけば、つねにピックアップ直下にデータがある状態が維持できる、かも。このあたりのCD読み込みの高速化テクニックは、プレイステーションとか、とにかくCDの読み込みがおそいハードでソフトを作ってた連中が詳しいんで、興味があればその辺に聞いてほしい。 |
|
CD読み込みの高速化 その２： あと、CDに書くときは、外周（セクタ番号が大きい方）に書くことも検討している。CDの連続読み込みは、じつは外周のほうが速い。理由は、最近のドライブはCAV(角速度一定。ようは回転数一定）なので、一周にかかる読み込み時間が一定。よって、一周が長い外周のほうが単位時間あたりデータ読み込み量は多くなる。さらに、すべてのデータを最外周に書くことは当然できないので、どんなデータをより外周にもってくるかの検討が必要。基本的には毎回読むデータをより外周に持ってくるべきだが、あまり配置をいじくるとシークが増えるかもしれない。 ただし、ここでも問題点があって、CDとISO9660のルール上、管理領域は最内周にとる必要性がある。また、別項にも書いたように、最内周のほうがすりへったドライブでは読みやすい。さらに、内周と外周にデータを分散させると、この二つの間のシークに時間がかかる。というわけで、単純に外周に集中させればいいというわけでもない。しかし、ちょこちょこと実験（3時間程度だけど）した感じでは、外周への集中は効果がありそうな気がする。ここに、最近登場した800MバイトCD（標準の640Mバイトの外にも無理やりデータを書く。無理やり書いた部分はドライブによっては読めたり読めなかったりする）とかの存在を考慮して、とりあえず以下のような配置にするつもり。 ボーナスデータとは、読めても読めなくてもいいデータ。読めたほうがいいけど。多分、市販ソフトのサンプル版とか、あとは壁紙とかが入ると思う。ボーナスデータが一部標準領域に食い込んでいるのは、基本ディスクイメージをあまりぎりぎり隅っこに作ると、隅っこが読めない可能性があるから少しゆとりを持たせてある。 |
CDへのデータ記録位置：
|
|
暗号化： HDDキャッシュは暗号化できる。この部分はまだ完成してない(2003/5）のであれですが、アルゴリズムは（いまのところ）単なる128bitRC4。これでも十分でしょ。これは、DIZEが業務用端末に使用される場合を想定してのこと。リースバック品っぽいジャンクのPCのHDDを解析したらヤバげなデータがぞろぞろ・・・という事態を防ぐため。別に暗号キーを忘れても、キャッシュが読めなくなるだけ（＝一定期間動作が遅くなる）なので、気にしなくてもOK。逆に、廃棄するとき（またはリース返納時）は、なにもしなくてもOK。暗号化のキーがわからなければ解読しようがない。もちろん、HDDをちゃんと消去してからのほうがより好ましくはあるが。石橋を叩いて渡るタイプの人はそこまでやろう。 |
|
代替セクタ処理： このあたり、まだ詳細は作ってないばかりか決まってもないけど、リードエラーを起こしたブロックに関しては、代替処理をかける。ただし、リードエラーを起こした場合そこにあったデータは失われる。行われるのは失われたデータの回復処理ではなく、次回からのエラーを防止する策。でも実際にはキャッシュだから問題なし。ただ、ユーザが書き込んだデータについてはこれでは困る。ネットワークバックアップが前提なので、そちらに期待してもいいのだけど、そもそも信頼性を非常に重視しているDIZEなので、さらに何か策を考えるつもり。多分、一台のIDEドライブの中でのミラーリング（一人ミラーリングともいおうか？）でもやろうか、とおもうけど、なんかむなしい気もする。とりあえず、同一ドライブの中でもミラーしておけば、速度は大幅に低下するし、ドライブごと壊れた場合も救済できないけど、セクタエラーには保険になる。 |
|
パフォーマンス： こんな複雑なループバックやレイヤーを作ってると遅いだろ！という人がいると思います。まだまだまったく開発途上でぜんぜん断定的なことはいえませんが、はい、遅いです。ベンチマークとってどうのこうの、という話になれば、単純に遅いです。単に cp するだけでも遅さが実感できます。ただし、それがシステム全体の体感速度にどれだけ響くか、となれば話はまったく別。いまのところまったく問題ありません。GNOMEでオープンオフィスを使ってる限り、遅いのはまずオープンオフィスのCPU処理時間です。その次にGNOMEのCPU処理時間です。Win2k+MSOffice2kと同一マシンで比較したとき、当社比3倍、って感じですかね（いまのところ（2003/5)、OpenOffice1.0xでは、CPU処理時間の最適化にものすごく問題がある。）。この二つの影響があまりにも大きいので、あとはどうでもいいです。今後、計画中の機能の実装を進める（＝さらに遅くなる）と同時にチューニング（＝速くなる）も考えていきます。結局いまより速くなるのか遅くなるのかは不明ですが、いづれにせよ体感速度としては問題ないでしょう。もちろん、ファイルI/O性能が顕著な影響を及ぼす分野、たとえばデータマイニングとかやりたいならDIZEは使わないほうがいいと思いますがね。 |
|
キャッシュファイルの増減： 可能だが今のところ少々面倒（または少々危険）。これが非常にショボい仕様であることは理解してるので、そのうち何とかするつもり。細かいことは省略しますが、ようは、LinuxからNTFSをいじくるとヤバい可能性があるので、馬鹿でかいファイル自体の増減は安全策をとるならNT上からしかできない。しかし、Ext2FSのリサイズはLinux上からしかできない。てなわけで、何度かリセットしてOSを切り替えながら作業することになる。ああ面倒。LinuxのNTFSドライバが完璧になれば問題ないのだが、いつのことになるやら。その開発の進行状況を見守りつつ、そのうちなんとかするつもり。 |
|
(将来的に）RedHat ベースにするつもりな理由： メジャーだから。技術的な利点は感じてない。Dont Reinvent the Wheel が一番大切。debianのredhatにたいする確固たる優位が立証できてない以上、RedHatを採用する。弊社がもっとも大切だと考えているのは、決定的な（破壊的な）技術的優位の追求ですが、そのつぎに最優先するのが互換性であるのが、弊社の基本理念です。どーしても debian したい人は、(DIMEとは無関係な一般的な意味で）RedHatに対するDebianの決定的優位を立証するWebサイトでも立ち上げてください。そこに対する支持が大きいようなら検討します。 なお、いまんところはdebianです。これは、knoppixがdebian だからです。こちらもまた、べつの Dont Reinvent the Wheel であって互換性重視です。あーあ、悩ましい。どっちかにLinuxが統一されれば便利なのにな。 |
|
信頼性： DIZEは、業務用端末（レンタルビデオ屋などにあるようなものを想像してください）とかの用途を結構重視しているので、信頼性は非常に大切。いろいろな対策を考えてます。 |
|
CDROMドライブの信頼性： CDROMドライブって結構壊れるでしょ。もともとメカなうえに、光学機器の持病、ピックアップの汚れ。あと、ローディングもトラブルの種。トレイなんているんですかね。筆者(JeyJokar)はトラブルが少ないうえ、電源オフのときでも出し入れできるキャディタイプのほうが好きだったのに。だからといって、CDROMドライブ故障につき今日は業務ができません。突然閉店です・・・。そんなんじゃ実用にならない。よって、CDROMドライブが故障しても業務が続行できる体制が望ましい。そのひとつとして、CDがHDDにすべて（じゃなくても必要な部分すべて）キャッシュされている場合、CDがなくても使えるようにする。ブートの方法ですが、HDDからのブート（要MBR書き換え）と、ブートフロッピーからのブート（ブートフロッピーに入っているブートローダがLinuxカーネル本体（ブートフロッピーにある場合とHDDにある場合、双方が考えられる）を立ち上げ、そのあとはHDD上のキャッシュを使ってブートプロセスの残りを遂行する）、場合によってはUSBメモリとかからのブート（原理はフロッピーからのブートとほぼ同じだが、こちらは容量の関係上、ブートローダやカーネル以外も入れてもいいし、IDやパスワード、そして公開鍵などが記憶できる利点もある）・・・とかをサポート。また、たとえ、CDROMからブートさせる場合でも、CDROMの最内周（CDは、内から外に記録する。レコードと逆）にブートローダやLinuxカーネルなど、ブートに最低限必要なものを書き込んである。これは、CDROMの故障のひとつに、ピックアップ（ヘッド）移動用のガイドレールやギアが磨り減って、外周へ行けなくなるトラブルがあるから。この場合でも、内周には行けることがある。よって最内周にブートに必須なデータを書くことにより、このような磨り減ったドライブでもだましだまし使える可能性がある。 |
|
HDDの信頼性： 所詮キャッシュなんで、少々なにかあっても大丈夫です。さらに、HDDが完全に死んだら死んだで、そのときは、HDDがなくてもCDオンリーでも動かないことはないので、一応その場しのぎにはなります。クソ遅いですけど。この場合、むしろ問題点はBIOSのハードウェアチェックで、セットアップでHDDをdisableしない限り先に進めないBIOSもあり、困った問題です。随所で繰り返してますが、「そんなの簡単じゃん」というのはPCオタクの意見であり、素人には無理です。 また、HDD(IDE)のミラーもいいでしょう。RAID5となると大げさすぎますが、ミラーなら費用対効果としてペイするでしょう。シリアルATAの登場で、よりいっそうミラー化はしやすくなるでしょうし。あと、いわゆる「IDEリムーバブルキット」の導入も意味があります。IDEのバルクのドライブを交換するのは素人には少し難しいですが、カートリッジ型であれば可能でしょう。シリアルATAでリムーバブルキットはよりいっそう導入しやすくなったわけですし。この場合、HDDキャッシュのおいしいところは、HDDを交換しても、再インストールの必要性がないことです。HDDをカートリッジ（いわゆる「ガワ」）ごと交換し、CDを入れてリセットすれば業務は継続できます。残る問題点は、異常点の検出 → 交換ガイダンスの表示 → 代替カートリッジの発送 → （場合によっては）元のカートリッジの回収 → （場合によっては）故障原因の特定(当然、調査結果のフィードバックによる品質改善策の策定を含む） → カートリッジの再生（中身のIDEドライブだけを交換） → カートリッジの再使用 とかの「HDDサイクル」を体系化することでしょう。 それ以外に考えてるのが、代替セクタ処理です。これは、インスタントパーティション上で行うやり方と、NTFSレベルで行うやり方、そしてHDDのハードレベルで行うやり方、三つ考えられますが、とりあえず一番簡単なのは、エラーができたセクタ（というか、リードエラーを起こしたブロック）をインスタントパーティションの中で代替処理することです。ただ、この場合、NTFSとExt2の管理領域が無傷で生き残ってることが条件なので、そのあたりを考えた場合は、NTFSレベルで代替セクタ処理をしたほうがいいんですが、ただでさえ複雑なNTFSでごちゃごちゃやるのもどうかと。ハードレベルでやる場合は、SCSIはともかくIDEではまともに動くかが心配。 |
|
H/W(HDD/CDROM以外)の信頼性： ようは、この場合は、電源とコネクタとSMTの半田付けね。半導体が飛ぶことはまずないから。このときは、迷わず代替機。一台しかPCがない事務所とかの場合、あらかじめもう一台用意しておくと安心です。なんせ、2万9800円ですから。複数台PCがあるばあいは、ほかのPCにCDを入れてリセットすればOKでしょう。将来的には、代替機貸し出しサービス、代替機急送サービスとかも考えてます。将来的には、ですが。 |
|
恒久的データ： ようは、ユーザ設定と文書ファイルってやつですな。これに関しては、キャッシュ用巨大ファイルのなかに、恒久的に作られます。といっても、いまんとこ、単にADSLのID/PASSと/etc/rc.localを記録してるだけですけど。将来的には、マシン固有プロファイル、ユーザ固有プロファイル、ユーザ共通プロファイル、CD固有プロファイル・・・とかいろいろ作るつもりなのでよろしく。これらは、どのCDからブートしても見えます（CD固有プロファイルを除く）。実際には、/etc/config*/*が/loop/config/へのシンボリックリンクになってるだけですけど。でも動くからいいんだよ！！！！。ユーザ作成データ（文書ファイル）もHDD上に恒久的に保存できます。/home/*が/loop/home/*へのシンボリックリンクになってるだけですが動作には問題ないです。 |
|
オンラインバックアップ： 恒久的データ(ユーザ設定と文書ファイル）は、両方ともオンラインでバックアップ可能です。というか、デフォルトでは勝手にバックアップします。あと、いまのところ、単に rsync を cron してるだけですが、InterMezzoの導入も考えています。とうぜん、すべてはバリバリに暗号化されてるので、セキュリティはばっちりです。 |
|
オンラインバックアップの暗号化： 弊社のバックアップセンターなんて信用できるか！という御尤もな意見にお答えして、バックアップデータをそちら側で自動的に暗号化し、暗号化されたファイルをオンラインバックアップできるようにします。このメリットは、たとえ弊社の従業員が悪さをしても、流出するのは暗号化されたバックアップデータであって無意味なことです。 ただし、この場合、圧縮転送やバージョニングやrsync などがどこまでうまくいくかは検討事項でしょう。さらに、根本的な問題点として、パスワード（とかICカードとか）が失われた場合、二度とデータは読めません。弊社としても、利用者に対し、パスワード管理のマニュアルを作ったり、方法を指導したり、なども考えていますが、所詮は本人の自覚でしょう。弊社の従業員管理を信用しないのは自由ですが、その場合、かなり気合をいれて自社のパスワード管理をしてください。 |
|
バージョニング： センター側によるバックアップの付録として、バージョニング（CVSみたいな機能。バージョン管理機能。修正前のファイルを過去何世代にもわたって保管している機能）もつけます。当然、将来的には変更点をグラフィカルに視覚化する機能もつけますが、いつになることやら。 バックアップの付録というよりは、個人的には、むしろバージョニングのほうがメインになりそうです。 |
|
立ち上がり時間： PCの立ち上がり、時間かかりすぎてませんか？。このあたりは、各メーカも認識しているようで、マイクロソフトもWinCEでは瞬間的な立ち上がりのために各種技術を投入していますし、WinXPでも若干チューニングを入れてます。が、しかし。それでも遅い。 てなわけで、DIZEでは立ち上がりの高速化のためにいろいろな技術を考えています。いまのところ、一番効果的なんだろうな、と考えているのがダンプ。emacs を使っている人にはおなじみの技術です。実装するのが少々面倒ですが、linux の周辺機器の認識のタイミングからして、非常な高速化が可能だと思います。きっちりHDDキャッシュが決まってれば、5秒以内に立ち上げることは可能でしょう。この場合、BIOSがCDROMを読みに行くまでの時間（なんて言うんだ？）のほうが問題だと思います。 二つ目の方法は、ハイバネーションです。linux2.6で（なぜかサスペンドと呼ばれてますが）ハイバネーションが一応入るので、これを利用しようか、とも考えてますが、単にメモリ丸ごとセーブするだけ、という泣けてくる仕様なので、まともに動くとは考えづらい点がアレですな。 ・・・といろいろ偉そうに書いたけど、ブートの高速化に関してはまだ(2003/5)ぜんぜんめどもついていなければコードも書いてない。どうなるかはまったくわかんないんだよな。 |
|
プリンター： Linuxのプリンタ業界に、Alan Cox のプログラミング能力 と Eric Raymond の「大人」さ加減をもったリーダーでも現れれば別ですが、そうでない限り、Linux におけるプリンタの対応には限界があるでしょう。プリンタの場合、認識すればいい、印刷できればいい、ってものじゃないからね。今みたいに「写真高画質」とかになってくれば、ちょっとした微妙な色合いとかまで再現したいでしょ。現実問題として、Windowsの純正ドライバで印刷するときは、用紙やインクの種類によって微妙な補正をいれてるでしょ。そこまでとなるとLinuxではまず無理。よって、DIZEでは、プリンタのPnPによる完璧な認識はずばり捨ててます。プリントアウトは、コンビニ（弁当やジュースを売ってるところね）か、いわゆるデジタルコンビニ（出力サービス店、とかとも呼ぶ）でやってください。もうひとつ、DIZEで切り捨てているのは、完璧な認識です。下書き程度の粗い出力であれば、ズレたりバケたり・・・といった問題点はあるでしょうが、ローカル（というか社内）のプリンタ（パラレル//USB/イーサネット経由を問わず）もサポートしていきます。出力フォーマットですが、オープンオフィスが1.0x系列ですでにPDF直接出力への対応を進めているので、いまのところ(2003/5)PDFオンリーで考えていますが、別項にもあるよう、独自フォーマットも考えています。 出力サービス業者側の対応ですが、セブンイレブン（＝ゼロックス）に関しては、今のところ、法人オンリー、MSオフィス文書オンリー・・・・であって、原則として、生命保険の営業が見積もりを出先で印刷する用途に特化しているようですが、今後は、PDFにも対応させ、個人用途も開拓するつもりらしいので、期待したいです。つーか、開拓してくれ！！！！！期待してるぞ。出力サービスとしては、（一応）大手として キンコーズ という店（一応、世界的チェーンらしい。少なくともアメリカにはある。日本では、 住友金属鉱山との共同出資・・・って、何で非鉄がこんなことやってんの？）があるのですが、PDF出力への体制を尋ねたら、「PDF出力ですか？だめじゃないですけど、ネット入稿はだめです。メール添付もだめです。CD-Rに焼いて持ってきてください」だってさ。やる気があるのかないのかわからない運営です。（というかどう考えてもやる気ない）。なんとかしてくれぇ。プリンタ（というか、それにまつわるトラブル）大嫌いのJeyJokar としては、プリントアウトの（まともな）アウトソーシング業者を常に求めてます。 |
|
ネットアカウント問題 ADSL最高。安くて速くて最高。これなら光なんかいらないよね。個人がWebとメールで使うだけならこれ以上必要ないでしょ。アメリカより安いADSL。アメリカより速いADSL。最高。でも、当然細かな問題点もある。それを検討しよう。 DIZEなら、やっぱ、ADSLもPnPにつなげたい。PC買ってきて電源ONすれば即ブロードバンド。配線すら不要。みたいにね。でも、現実は、それ入会申し込み、それパスワード、と結構めんどくさい。一般ユーザには、スプリッタとかの配線ですら頭パニックなのに。それと、路線長、回線握り、光収容、と、申し込みすらも考えることがいろいろあって結構難しい。このあたりを何とかしないと、所詮はマニア向けにとどまるなー、と思うのだが、どうだろう。 一番ポイントは、結局政治問題。それぞれ業界習慣や常識の違ういろんな業界のいろいろな業者のいろいろな利害が絡み合い、その調整が非常に大変。回線握り問題なんかは、まさにそれ。技術的、法律的には解決はそんなに難しくないんだけど、解約しやすくするサービス、なんて奇妙な話に積極的な業者はいないから、結局不毛な非難合戦に終始してしまい、解決が難しい。 それ以外だと、機材の使いまわし。ちょっとした変更のために機材を入れ替えていてはコストがかかってかなわない。たとえば、プロバイダの申し込みとパスワードの問題は、ヤフーBBみたいな方式（つまり、収容局から自宅まで引く業者と収容局からバックボーンまでの業者が同じ）であれば問題ない。それ以外にも、フレッツみたいな方式でも、ゼロベースでサービス内容を再構築する気なら解決策はいろいろある。たとえば、所詮は表面的な見た目の問題だけど、ACCAのほうがフレッツよりも素人にはわかりやすい。で、これを改善すること自身は簡単。全部作り直せばできる。しかし、いまのNTTのフレッツの構造そのままでわかりやすくするには、一工夫必要。ここらへんを、ゼロベースで再構築するんじゃなく、従来のやりかたを小手先でちょいちょいと改善するだけでなんとかならないかな。これ以外でも、ゼロベースでの再構築でなく、いままでの機材の使いまわしをベースとして微調整をいろいろとしたい部分はある。 「はぁ？フレッツで何が問題なの？」と思うかもしれないけど、NTTと(たとえば)Nifty、両方に申し込みが必要です、とか、実は、Niftyではフレッツ経由とACCA経由と、二つADSLがあります、とか、トラブった時は適切に切り分けてNiftyとNTT、それぞれに適切な苦情を言ってください・・・・・どうたらこうたら。こんなこと、素人にわかると思うかな。街頭勧誘の兄ちゃんでも混乱してて、奇妙な説明を聞かせてくれることが多いけど。これを改善するに、NTT法がどうこう、郵政省電気通信審議会がうんぬん、なんて次元にいかなくても、パンフの書き方や営業トークの改善、受付窓口の応対マニュアルの改善・・・といった、表面的な努力だけでも、ずいぶん素人にはわかりやすくなると思うぞ。もちろん、各業者もそれぞれ努力はしてるだろうけど、あんなNTT内部資料丸出しの営業トークで素人が理解できるとは思えないね。 もうひとつ、深刻な問題で、「引越し先で使えるの？」というのがある。一度使い出せば覚醒剤並みの依存性があるブロードバンド。いざ入居してみたらリンクせず、というのでは話にならない。いまさらダイアルアップに戻れるわけないよね。かといって、入居前に根掘り葉掘り大家に聞いてもまともな返事が返るとも思えない。理論的には解決策はいろいろある。たとえば、「日本ブロードバンド不動産協会」とかわけのわからない団体を作って、新しい物好きの不動産屋を集めてセミナーなどをやって・・・（その経費は、ADSL業者の勧誘費用からださせる）・・・。とか。「弊社仲介物件はすべてリンクアップ確認をしてからお引渡し。ブロードバンド対応仲介サービス。契約するかどうかは別。いまならもれなくヤフーBBモデム＋VoIP＋3ヶ月無料体験ついてきます！入居即ブロードバンド保証付」みたいになれば、それはそれで解決なんだけど・・・。うーん。この問題のポイントは、「実際にやる」ってことですね。机上の空論ならいくらでもアイディアは出るんですが、実際にはいろいろな業界のいろいろな人々の利害が複雑に錯綜するので、一筋縄じゃいかないです。 で、以上は（すごく長かったけど）ADSL業界の一般的問題をPnPという観点から概説したものですが、DIZE特有の問題をすこし。ID/PASSをどうすんだ？ 一番ありきたりで素直な発想はID/PASSをHDDのどっかに記録しておいて、それでADSLをアクセスすればいいんだけど、CD一枚で・・・というコンセプトからすると、HDDの記録との連携が必須な方式はしょぼい。かといって、ADSLへ接続するたびにID/PASSを入力させるのも面倒すぎる。うーん。どうしたものか。タンパープルーフで秘密鍵を閉じ込めたUSB機器（いわゆるUSBキー）を使うとか、方法はいろいろ考えられるんだけど、どれをとっても一長一短なんだよな。 |
|
ADSL（というかプロバイダ）申し込み問題： PC買ってきてなにしますか。インターネットにつなぎますね。それはいいんですが、プロバイダの申し込み、どうしますか？。クレジットカード持ってればオンラインサインアップで一発？わかってないなぁ。それが一般人にとっては凄まじく困難な壁。たとえば、住所氏名入れさせるとするでしょ。だったら、FEPの使い方がわかってなきゃダメ。ようは、初心者にとっては凄まじく難しい。オンラインサインアップは、もうすでにパソコンをやってる人がプロバイダを変更するときとかはいいかもしれないけど、初めての人にとっては論外。 まず第一にやるべきは、店頭販売時点で、ダイアルアップ100時間無料お試し権とかつけちゃうこと。それだけじゃなくダイアルアップの設定も行って、線つないでIEのアイコンをクリックすればあとは勝手に行くようにする。最近、一部の販売店でバックマージン欲しさにPC購入時にプロバイダ同時入会とかやってるけど、あれじゃだめ。お試し入会じゃないとだめ。理由は、ただでさえ考えることが多いPC購入時にさらに考えることを増やさないため。「液晶にしますか？ブラウン管にしますか？Pen3ですか？Pen4ですか？セレロンですか？あ、一部のセレロンはPen4ですがね。アスロンってのもあって、でもデュロンが」なんて意味不明の話に苦しめられている人に追い討ちをかけるように「プロバイダどこにしますか？ニフティー？ビグローブ？コースどうします？定額ですか？従量ですか？」なんてわけのわかんない話はしないこと。あと、線のつなぎかたも、初心者にはわかんないんで、つないだ状態の写真をつける。PCのマニュアルに載ってる配線方法って、マニュアル版下作成時にはモデムの機種が特定できないんで、実際についてるモデムと微妙に違ってることがよくあるでしょ。そこで初心者は固まってしまう。100時間無料キャンペーン終了後は、カネ払ってこのまま会員であり続けるのか、それともその時点でやめるのか選べる。間違っても、ほっておくと自動的に有料会員になるようなシステムを入れてはいけない。この手の商売が好きな会社はいろいろありますが、あまりにも詐欺的な商法であって一般人相手に許されるものではありません。なお、この100時間無料お試し権ですが、その費用は店が負担するわけじゃないので心配なし。プロバイダに頼めば心配しなくてもホイホイ無料権だしますからOK。無料期間終了後に有料会員になってくれる率を考えれば、プロバイダにとっても美味しい話です。つーか、うまく立ち回れば販売店はバックマージン取れると思います。 ・・・と以上は、ダイアルアップ中心時代の名残をとどめた解説でしたが、いまは、一般人でもADSLが当たり前（これを書いている2003/5現在、ADSL回線数600万！！！）なのですが、悩みは増えます。ADSLの場合、局内工事がある関係上、どうしても申し込みから開通まである程度時間はいるし、回線ノイズの問題を考えると、モジュラージャックからADSLモデムまでの距離を短く配線しないとダメだし、そんなこんなでアナログモデムによるダイアルアップより複雑なんだよな。いろいろアイディアはあるんですが、どうしよかな。 |
|
（どーでもいいけど）ADSLはUSBだろ！！！ もうまったくDIZEと離れて、単なるADSL問題なんですが、「リセット一発でお手軽に」というDIZEのコンセプトからすれば、ここまでこだわります。なんでADSLってイーサなんですかね。最近は、初心者にとってはイーサポート＝ADSLポート＝ブロードバンドポートみたいですし、イーサのNICもADSL用のインターフェースカード扱いみたいです。が、しかし。なんでイーサなんですかね。USBで十分なのに。とくに、USB2.0が出た今、USBで問題なる点は原理的にはまったくないんですが。逆に、利点はいろいろあって、まず給電ができる。ADSLモデムには、イーサの場合、イーサケーブルとACアダプタケーブル、2本がいる。たいしたことないじゃん、とおもうだろうが、ノイズ対策と電話との共存の関係上、結構設置場所が限定されるので、1本で済むか二本で済むかは、結構重要。もうひとつ、USBのほうがケーブルが細い。これも非常に大切。PCと電話が離れたりすると、その二つの間に延々とケーブルが延びる。それが美観上イヤ！ってのが一般人の考え方。ただ、PCのおいてある部屋と電話のある部屋が別でドアの隙間を通すために、ケーブルを「ほぐす」場合は、イーサのほうがやりやすい場合もある。場合によるけど。いずれにせよ、USBという選択肢が存在することが初心者にとってありがたいのは間違いない。さらに、イーサカードが不要。そして、これはドライバを入れれば、だけどPnPでTCP/IPの設定までできる。イーサでもPnPはないことはなくて、DHCPとかMacOS X のランデブーとかないことはないけどいまいち成熟していない・・・というか、PPPoEの設定まで含めればDHCPではちょっときついでしょ。PnPという観点では、USBのほうが圧倒的に完成度は高い。これなんかも、TCP/IPのコンパネの設定とかなんとなくやっちゃう人種にはまったく関係ないけど、一般人にとっては凄まじく重要なこと。 |
|
（もっとどーでもいいけど）ADSL、エラー表示が不親切 ADSL（じゃなくてもプロバイダ全部）って、エラー表示が不親切すぎないか？ あれ、つながらない。認証けられてる。パスワード間違えたか？料金不払いで停められてるのか？ とか大騒ぎしてみたら、結局プロバイダがメンテ中だったとか。 自分たちがいかにインターネットに依存した生活をしているかを 理解する一瞬でもあるけど、ネットから切り離されるのってつらいよね。 さらに、ネットにつながらないのでトラブルの原因も調べられない。たとえプロバイダのWebサイトに掲示が出てても読めないし、パソコン側の問題なのかな？と思っても切り分けのヒントを探すこともできない。 こんなとき、フレッツスクウェア（または同じようなサービス）とか、とにかくフレッツさえ契約していればプロバイダと関係なくアクセスできるところにプロバイダの障害情報、メンテ情報や障害対処のノウハウ、各種ドライバとか置いておいてほしいのよ。 あと、業界で金を出し合って（というか、フレッツならNTTが金を出して）障害告知および対処法案内専門の無料プロバイダを作るのも一案。原理はフレッツスクウェアと同じ。うまくやれば、広告モデルで運営は不可能じゃないかも。ここでポイントは、設定とかをひどくわかりやすくすること。筆者（菊池）は、障害原因の切り分けのためにフレッツスクウェアに接続するたびに、どうやって接続するんだ？とマニュアルを探すのに何十分も大騒ぎしています。ネットで調べようにも、もともとネットに接続できないから障害原因の切り分けがしたいわけだし。 また、Web経由での案内以外の方法もほしい。PCの不良ということもあるし、Webオンリーではやはりきつい。たとえば、どっかに電話すると録音テープで「はい、○×プロバイダです。ただいま、すべての回線は正常に稼動しております。」「本日早朝4時から1時間、メンテナンスのためサービスを休止します」・・・とかぐらいはやってくれ。あと、同じことをファックスサービスでも。 これ以外にも、PPPoEって、エラー表示がダメすぎ。 たとえば、突然の切断で二重ログイン防止機構のせい？でログインできなくなっていても、ID/パスワードが違います。だもんね。「こちら、＊＊プロバイダです。大変申し訳ありませんが、二重ログインの可能性があり、現在ログインを一時停止しております。数分後にはログイン可能になります。なお、この点について疑問等ありましたらユーザサポートダイアル 0120-xx-yyyy にお電話の上、アクセスポイント番号 3455 において 問題番号 2144 が発生しているとお伝えください。」ぐらいやれよな！！！。 そんなテキスト文どっから引っ張ってくるんだ！と思うだろうが、 適当なプロトコル（というか、実際にはPPPの認証の拡張）として PPPoEサーバなり、Radius サーバなりが送ればいい。技術的には簡単なんだからさ、これぐらい対応してくれ。 Nifty の FENIC ROAD3 とかは、メンテ中にアクセスすると、 「ただいまメンテ中です。午後＊＊時頃復旧予定」とか表示されてたのに、 インターネットではそれが出ていない。 これじゃ退化だよ。 |
|
（どーでもいいけど）ADSLモデムのエラー表示もわかんねえぞ！ 隠しコマンドを使えば、スペクトル別のノイズレベルなんかも表示できるけど、 そんなマニアックでわけのわかんない機能よりも、 初心者にとってわかりやすい機能を強化してほしい。 「あれ、つながんないや」と大騒ぎした挙句、 単にケーブルが抜けてただけ、とかは実に多いんだけど、 そのときに、「ケーブルが抜けてると思いますけど」とモデムが表示してくれると 実にありがたい。 |
|
（もっともっとどーでもいいけど）ADSL二重ログイン規制をなんとかしろ！ ADSLで、突然の切断がおきると、そのあと数分間ログインできなくなるよね。 詳しい原理はウラが取れてないのであれだが、これってたぶん、二重ログインをハネるためのチェックの関係上、ログインしてるかもしれないししてないかもしれない、という中途半端な時期は一切のログインをハネてるんだとおもう。PPPoEの構造上、数分間でKeepAliveが途切れるのでそこでログアウトが確認されて再びログインができるようになる。 が、これ、あまりにも不便なのよ。突然切れたときとか、何分も接続できなくなる。さらに、別項にも書いたけど、エラーメッセージが不親切で、「認証に蹴られた」としか出ない。二重ログインの可能性があるので確認のため数分間おまちください、ぐらいはだせよ。というか、根本的な問題として、どう考えても、（二重ログインによるプロバイダのデメリット）＜＜＜＜＜＜＜（数分間接続できなくなるユーザのデメリット）だとおもうのに、あくまでも自分の都合を押し付けるわがままプロバイダ。何とかなりませんかね。 NTTのフレッツ網の認証システムの詳細とかぜんぜん知らないのであれだが、二重ログインをある程度は許容することにより、このイライラをなくせるはず。 具体的には、ひとつの例だけど以下のようにすればOK。 結局、二重ログインで問題になるのは、大学のサークル単位とかでひとつのIDを使いまわすような、計画的継続的にIDを共有してるやつらだけ。それ以外は、たとえ一時的に二重ログインをしていても、（プロバイダの損害という意味では）それはそれでたいした問題ではない。むしろ、ハッキングの可能性というユーザ側の損害のほうが深刻な問題。それを考え、計画的継続的な場合だけを検出する。やり方は簡単で、たとえば週一とかでログを検査するだけ。Perlのスクリプトで10行もあればOK。これを流せば、激しく二重ログインをしまくっているユーザが抽出できるはず。あとは、そのユーザに個別に対処する。心配しなくても、ひとつのIDを共有してプロバ代を浮かすようなセコいやつらは全体から見ればごく一部だから、個別対処で問題なし。 |
|
ファイアウォール問題： ファイアウォールをどう越させるかも大きな問題。IEの「インターネットオプション」のコンパネのプロキシの設定のところね。そんなの適当に・・・じゃやっぱりだめ。ようは、必要なのはプロキシのアドレス（http://proxy.local:8080 みたいなの）と ID/PASS（プロキシの！）なんだけど、これをどうユーザに設定させて、どこに記録しておくか。たとえば、ADSLのパスワードとプロキシのパスワードとNetBIOSのパスワード・・・というだけで、管理が面倒なだけではなく初心者にはその区別がわからない。 |
|
プロキシ問題： ファイアウォールというだけなら、外から中のポートを全部閉じて、中から外のポートに関して、http(s)/ ftp/ smtp/ pop3/ telnet/ ssh を NATすればよい。つまり、いわゆるブロードバンドルータでやってることと同じね。が、しかし。企業のばあい、エロサイトや自社に不都合なサイトへのアクセスを遮断するため、L4じゃなくL7でフィルタリングしている場合が多い。メールサーバは社内のDMZに立てたやつしか見えない。つまり、HTTPのプロキシを越えるしか一切外とつながってない。PingもTracerouteも社外とは一切無理。と、なると、なんでもかんでもHTTPトンネリングするしかないわけ。で、ここで問題が。なんでもかんでもHTTPに重畳させてくと、よほどよくできたレイヤ７のファイアウォールを使わない限りセキュリティが甘くなる。しかし、そんなファイアウォールの開発は困難だし、設定や運用も困難。じゃあどうするか。 ざまーみろ、ほっとけ、ってのが正解かも。XMLとか.net とかで騒がれてるSOAPってあるじゃん。これ、HTTPをトランスポート（トンネリング）させてRPCのパケット（のようなもの）をつくり、その中にXMLのオブジェクトを入れてバンバン送ってくる。そして、わざわざRPCをHTTPでトンネリングする理由は、ずばり「ファイアウォール越え」。おいおい。RPC(SOAPの実態はデータ形式がXMLでデータ転送プロトコルがHTTPなだけで、あとはまったくRPCと同じ）のパケットを中身ノーチェックでファイアウォール越えさせていいのか？チェックするならチェックするで、XMLのパーサまで全部ファイアウォールに積むのか？。だったら、EDIとかでよくある専用で勝手でバイナリなデータ形式のほうがよくないか？案外、ASICのXMLパーサチップとか出てきたら怖いけど。なまじ汎用性があるデータだけに怖いんです。さらに、最近はSMTPをトランスポートにSOAPを送って、そこにMQ（当然IBMの！）を絡ませて・・・なんて意味不明の技術まで「次世代有力候補」とか真顔でささやかれている。おいおい。利点は大きいから気持ちはわかるが、そんなのまともに動くのか？SMTPで電子商取引に耐えうる信頼性なんてたたき出せるのか？おいおい。 てなわけで、そんなのが外→内ですらなんとかなる（とされている）今日この頃、すくなくとも内→外に関しては、なんでもHTTPに重畳させてもいいように思う。 |
|
設定ファイル問題： ネットアカウントのところでもちょこっと述べたけど、 結局、さまざまなID/PASSなどの設定をどこに記録するか。 それ以外でも、たとえばDNSサーバのアドレスであるとか、スタートページのURLであるとか、「お気に入り」のURLであるとか、はてまた壁紙の色であるとか、とにかく記録しておきたい設定はいろいろある。で、これをどこに記録するか。記録する場所はいろいろ考えられる。
さらに、別にすべての設定をなんらかの不揮発性メディアに書く必要はなく、ネット上に書いておいて、そこに拾いに行くことも可能。この場合、ネットにつながるだけの情報（プロバイダのID/PASSなど）は必須だし、ネットが落ちると何もできなくなるけど、ネットに拾いにいく場合、世界中どこにいても同じ環境を再現できる利点がある。さらに、HDDキャッシュの存在を考えれば、たとえネットが落ちても(最新のものと同期している保障がなくなるけど）なんとかなる。で、長々と書いたけど、結局、ADSLのID/PASSと、オンラインフォルダのID/PASSを除けば、あとは全部ネット上に置くのが正解だと思う。細かく言うとオンラインフォルダのIPを入手するためにDNSサーバのIPがいるんだけど、PPPのリンクのときに多分取れるでしょ。取れなければルートサーバから順に叩いてもいいし（ルートサーバのIPは変わらないものとする）、オンラインフォルダのIPが変わらないと仮定してもいいし、オンラインフォルダのIPを返すだけのいんちきDNSサーバを立てて、そこのIPを固定してもいい。まあ、何とかなるでしょう。 で、この異様に長い話の結論は、多分USBメモリかUSBキーを使いましょう、となると思う。理由は、どのPCにも付くから。前面端子がすべてのPCにあるわけじゃないのが残念だけど、まあしょうがないでしょう。延長ケーブルを使ってください。もうひとつの理由は、わかりやすいから。ID/PASSの管理がいい加減なユーザにキレてるネット管理者は多いと思う。でも、これはユーザがバカだから、とかで済ませられる問題ではない。たとえば、ネット管理者は来客の席順とか詳しいかな？営業なら絶対完璧でしょ。ようは、知ってる知識の範囲が違うだけ。で、営業はこれを新人研修とかで学んでるんだから、情報システムに関してもセミナーとかやってパスワード管理を教えればそれで解決する。それでも解決しないならそれこそユーザがバカ。ただ、これを経営側の視点から考えてほしい。たとえ1時間のセミナーでも、それを全社員に受けさせればいくらかかると思う？そうやって考えていくと、たとえば3000円のICカードを導入すれば1時間のセミナーが省略できる、っていうなら経営的にはペイするし、逆にこれはTCOの範囲に入るのだろうけど、そのようなコストまで考えてもペイする場合のみ情報システムは導入するんであって、「ユーザがバカだから」うまく動かない情報システムなんて、経営的には動かない情報システムとまったく同じ。で、USBキーのいいところはわかりやすいこと。この「棒」にID/PASSが入ってます。各自厳重に管理のこと。とかいえばわかりやすいでしょう。これなら、（本物の）鍵の管理ができるやつならID/PASSの管理もできるでしょう。 なお、絶対ありそうな文句に、USBキー（ゼロ知識証明をしてくれるやつ）なら安全だけど、USBメモリ（ID/PASSがいきなり書いてあるやつ）は危なすぎてだめ、とかいうやつがいるけど、あほくさ〜って感じですかね。技術的にはたしかに危険なんだけど、問題は実際的なこと。CRTの上にポストイットでID/PASSが書いてあって・・といった事態が日常茶飯事な現状を考えれば、USBメモリでも問題なし。たとえ政府関係とかでも、いまのあまりにもいい加減な情報管理体制を考えれば、べつにいいんじゃない？とおもうよ。道端に札束がおかれているような現状に比べれば、たとえ南京錠でも十分有効。まず、南京錠でもいいから鍵をかけよう。銀行の貸し金庫のような体制が理想なのは論を待たないが、とりあえず南京錠でいいから鍵をかけよう。 ごちゃごちゃ書いたけど、ようは、USBメモリ（またはUSBキー）にID/PASSを入れておいて、あとの設定はネット上に置く。これが一番便利だしわかりやすい。 もうひとつ、USBメモリ（またはUSBメモリ内蔵USBキー）を使うときは、BIOSがUSBメモリからのブートをサポートしているととてもいい。最近はこれを可能にしたBIOSもあるし。 この方式の利点は、USBキーを挿せばDIZEが。挿さないとWindowsが、という風に、OSの選択を非常にわかりやすくできること。もちろん、ブートシーケンスが USB → HDD になってれば、だけど。なお、USBメモリにシステムを入れてはいけない。USBメモリに入れるのは、CDを読みにいくブートローダだけ。システムまで入れてしまうと、バージョンアップのとき、USBキーの中身まで更新しないといけなくなって面倒。 もうひとつ、USBキー方式のいいところは、マシンの転売やリース品の返納のさい、キーが流出する可能性が低いことだが、これは当然、USBキーそのものは「買い切り」であるのが前提。キーそのものまでリースし、それごと返納するなら意味がない。USBキーなんて量産すれば1000円を切るから、うだうだケチな算段しないでさっさと買うこと。こんなことどうでもいいように映るが、現実問題としては結構大切。 |
|
USBキーについて： コストは少々かかるが、結局、最終的に正解なのはUSBキー（ゼロ知識証明タイプ。USBメモリ（フラッシュメモリ）付き）だとおもう。もちろん、問題点もいろいろあって、たとえばどれだけ量産が進んでも1000円ぐらいは原価がするだろうし、今の時点ではそんなのではとてもきかない。さらに、後面まで含めればUSB端子がないPCはまずないけど、すべてのPCに前面USB端子があるわけじゃない。 しかし、このような欠点すべてを差し引いても、USBキーには利点がある。まず、USB端子がないPCはまずない。よって、付くか付かないか、という観点からはほとんどのPCに付く。さらに、USBキーならゼロ知識証明できるのでセキュリティ的にばっちり。そして、USBメモリ機能をつければ、BIOSによるけどブートも可能。それ以外にも、いろんなデータがUSBメモリに記録できる。少々コストはかかるが、利点は大きい。なお、USBキーは、どうゆう方法でもいいけど、これはDIZEのキーなんだよ。ということがPCからわかるようにするべき。実際には、USBメモリのブートセクタの特定の位置の値を固定する、とかだろうけど、方法はどうでもいい。で、もし将来DIZE対応BIOSとかでれば、これを見て適切な処理をする。具体的には、たとえば、HDDもCDROMもないPC(CPUだけ）の場合は、CDROMを読みにいかず、ネットからブートする。また、CDROMとHDDがある場合でも、HDD上にきっちりキャッシュされている場合は、CDROMを読まない・・・など、それなりに「賢い」動作が可能。 USBキーは、つけっぱなしが前提ではなく、必要なとき（ブートのとき、認証のとき）につければOKなようにするつもり。つけっぱなしを前提にすると、席をはずすときなど非常に困るし、USBコネクタのある場所によっては、手で支えてないとだめだったりしてつけっぱなしが不可能な場合もある。 さらに、もうひとつ、USBキーにはブートセレクトスイッチをつける。これを切り替えることにより、どこからブートするか決定できる。これが使えるのは、HDDにディスクイメージがきっちりキャッシュされた状態で、BIOSが対応してるPCを使うとき。USBキーのスイッチを「HDDブート」にあわせてリセットすると、CDROMを読みにいかない。CDを入れる手間が省ける上、一瞬だけどブートが速くなる。さらに、CDROMがぶっ壊れてても平気。この方法のおいしいのはわかりやすさと安全性。同様のことはMBRを書き換えてもできるんだけど、それはわかりにくい上に安全性に問題がある。USBキーを使うと、普通にUSBキーを入れればCDブート。スイッチを切り替えてUSBキーを入れればHDDからDIZEをブート。USBキーを抜けば（インストールされていれば）Windowsをブート、とわかりやすい。 |
USBキーの抜き差しによるDIZEとWindowsのブート切り替え：
|
|
CMOSへの記録について： PCの内部に、ID/PASSはどこまで記録できるか、って話。当然、いまのPCそのままで。なにかPCに手を加えるなら非常に簡単だが、そのままで、となると一工夫必要。というか、そのままのPCで何か記録可能な領域はHDDを除けばCMOSしかない。記録したい情報は、ADSLのID/PASS、オンラインストレージのID/PASSが必須で、それ以外だとDNSサーバのIPやデフォルトゲートウェイのIPなどもあるけど、ここまで記録しなくてもなんとかなる。 IBM-PCのCMOSは標準で128バイトなのだが、実は、すべてびっしり使っているわけではなく、BIOSにもよるが10バイトぐらいはあいていることがある。よって、この領域を有効に使えば、何とかできなくもない。問題は、ここでも機材の使いまわし。技術的には、極端な話、ADSLの場合、ID/PASSなど省略しても問題ないし（現実にヤフーBBはID/PASS不要）、ADSL業者側から認証情報をもらえれば、オンラインストレージ側のID/PASSもなくても何とかなる。ここまですれば、そもそもID/PASSの記録自体が不要。しかし、そこまでするのはかなーーり現実問題としては困難。ADSL業者の認証システム一式をすべて取り替えるなら技術的には簡単なのだが、そんなことをしたらコストがかかりすぎる。かといって、いまの認証システムでは、どの業者の場合を見ても、いろいろな問題点がある。ただ、それでも、10バイトあればいまの認証システムの使いまわしでも何とかなるんじゃないかな。たとえば、1バイトを方式（業者）コード。8バイト（64ビット）を認証コード。1バイトを予備。これでも何とかなる。8バイトの認証コードは、ID32ビット PASS32ビット、とかで切り分ける必要はない。分けてもいいけど。64ビットの空間上に離散的に認証コードを作っても同じ。意味わかんないかもしれないけど、認証サーバは64ビットのキーをPCから受け取り、認証DBをたたく。認証DBはキーからユーザIDとそれに付随するいろんなユーザ情報を取ってくる。で、ここでそのキーがDBに登録されてれば認証成功。登録されてなければ認証失敗。キーを40億通り（32ビット）作るとして、それを64ビット空間に分散させれば、偶然そのキーが存在する確立は40億分の一。認証一回につきわざと3秒かけるとして（当然、同じADSL回線から並列で複数の認証を同時に行うことはできないようにする）、24時間連続してクラックしてもそれが偶然ヒットする率なんてわずかなもの。捕まるリスクのほうが遥かに高いでしょ（当然、このようなブルートフォースアタックは監視し、IDの一時停止など、適切に処理すること！）。 ただし、以上のような手段を使っても、いまのフレッツADSL、いまのプロバイダ（たとえばニフティー）まったくそのまま、とはいかないので、ID/PASSの振り方ひとつとってもいろいろと検討事項がある。ただ、認証システム総取替え、といったことをせず、小手先の修正で何とかする道はあるんじゃないかな。 |
|
ブートシーケンス問題（概論） LinuxのCDを入れたのにWindowsが立ち上がるときは、BIOSセットアップの設定をチェックしましょう。CDROMをHDDより優先して読むように設定してね、って話。くだらないと思うだろうが、実際問題としては実に重要な問題。以下、延々と議論するが、ことの重大性にかんがみ「長い」とか文句言わないこと。 「そんなの、適当にやればいいじゃん」と思う人が多いだろうが、わかってない。まさに専門バカ的発想。世の中の99.9%の人にとって、その「適当」というのが、果てしなく高い壁。「「あわーど」のロゴが見えてメモリチェックが終わったあたりで、テキトーなタイミングで「でる」（パソコン会社ではない！）をおしてぇ」なんて聞いて、はいはいそうですね、と理解できれば苦労はしない。壁が100枚あろうと1枚であろうと、越えられない壁が一枚でもあれば目的地にはつけない。だから、このくだらない問題も必ず解決しなければいけない。そうしないと、「壁を100枚から1枚に削減しましたぁ！って、その最後の1枚がどーせお前には越えられないからムダだけどね」という実に意味のない商品になってしまう。あと、多分、このページを見てるような人だと、Award の BIOSで DELキーでセットアップに移行、という仕様のマシンが多いでしょうが、 ここを見ればわかるように、そんなに甘くない。PCの世界は実にいろいろ。中には、Ctrl-Alt-なんとか、みたいな驚くべき組み合わせを要求するマシンもある。多分、偶然初心者がセットアップメニューに移行して驚くことがないように、という配慮なんだろうけど、だったらパスワードをかけとけばいいじゃん。小さな親切大きなお世話の典型・・・というか、ヒマな社員が仕事を作るために変な要件定義をしたんでしょうな。 もうひとつ厄介なのは、われわれがインテルでもなければデルでもないこと。こんなのは、インテルがひとこと、「やりなさい」といえば解決なんだけど、うちらはそうはいかない。マザーやBIOSを特注したらコストが高すぎる。逆に言えば、大量ロットで発注すれば特注費用は問題にならないけど、そんなロットで発注して在庫がさばけるほどDIZEをヒットさせることはすくなくとも初期段階では不可能。もちろん、最終的には、「国際DIZE検討委員会」（なんか農林水産省系統の団体みたいだ！）とかつくって、そこで決めたことが世界のPCメーカ間の合意事項とかなって・・・とかなればうれしいけど、問題はとりあえずどうするか。 |
|
ブートシーケンス問題（各論） 結論としては確実な解はない。しかし、アプローチは主に三つある。ひとつは、ブートフロッピーをつかうなど、CDブート以外の方法で結局はCDブートと等価なことを行うやりかた。仮に、これを等価法と名づけよう。次に、ハードウェアなりファームウェア（BIOS)なり工場出荷時の設定なり、なにかを改造、または特殊な設定を指定する方法。これをハードウェア法と名づける。もちろん、ファームウェアはハードではないのだが、便宜的な命名として認めてほしい。三つ目に考えられるのが、ユーティリティでCMOSの内容を書き換えるやり方だ。これを仮にユーティリティ法と呼ぶ。 等価法 内容： ブートフロッピー、LOADLIN、USBメモリなどをつかい、CDブートとほぼ同様のことをCDブート以外の手段で行う。 利点： 副作用なし。 問題点： ブートローダーを読みにいかせることが必ずしもできない。たとえば、ブートフロッピーならブートシーケンスがFDD＞HDDであるのが条件だし、FDDがついてるマシンであることも必須。LOADLINならWindowsが正常に動いてないとダメ。USBメモリにいたっては、それが読まれるようにBIOSセットアップが変更できるユーザならもともとブートシーケンス問題など生じない。 さらに、LOADLINの場合、Windowsを立ち上げる時間が無駄。どうせ会社についてすぐ制服に着替えるのに通勤ファッションに命をかけてるOLみたいな感じ。また、LOADLINのばあい、LOADLIN for 95系列はあるんだけど、LOADLIN for NT系列はない。これもすごい問題点。だれかLOADLIN XP とかつくってぇ！（←なら自分で作れよ！）。 ここなんか利用できるかも。 結論： 無害であるので、採用はすべきだが、欠点がかなりあるので、あくまで補助的な手段に限定すべき。 ハードウェア法 内容： ハードウェアなりファームウェア（BIOS)なり工場出荷時の設定なり、なにかを改造、または特殊な設定を指定する。 なお、この方法の詳細は別項で論ずる。 利点： ユーザから見て手軽。業者から見て低コスト。 欠点： いくら低コストに限定しているといえど、何らかの対処が業者側で必要。また、ユーザ側にとっても、手法にもよるが確実性を出すのが難しい。「ユーザ側で○○をするとCDブートしなくなるので、その場合はユーザサポートで○○を案内して・・・」といった対応が結局必要になることが多い。ただし、オールクリアとかの特別なリセットスイッチをCMOSにつけた場合だけは別。普通のリセットスイッチよりさらに上のオールクリアのリセットスイッチをつける。で、なにかあったらオールクリアのリセットスイッチを押す。そのリセットスイッチは本体の背面の押しづらい場所にあって・・・というパターンは一般人にも理解しやすい。 ユーティリティ法： 内容： ユーティリティでCMOSの内容を書き換えるやり方 利点： ほぼ副作用なし。 欠点： どーやってそのユーティリティを動かすか、が一番問題。Windows のユーティリティなら、ウィンドウズが正常に起動しないと使えない。ブータブルLinuxなら、それをブートさせないと使えない。なお、CMOSのデータ形式はBIOSによって違うが、その辺の対応はそんなに難しくない。それでも、PCのBIOSなんて無数にありうるので、どんなPCでも対応、というユーティリティは作れない。しかし、これも、どうせDIZEは特定のハードウェア構成しか認識できないので、気にしなくてもいいかもしれない。賢いブートマネージャー（これ)とかは利用できるかも。 |
|
ハードウェア法 比較検討： ハードウェア法の詳細についていろいろ検討してみる。
・・・・とまあ、またまた延々と議論してきたけど、結局、決定的な方法がない以上、これらの方法を場合によって使い分けていくしかない。基本的には、まず、等価法とユーティリティ法はサブとして常に使う。で、メインをどうするか、だけど、普通のPCでは、ユーティリティ法がいいとおもう。もちろん、BIOSの対応の問題はあるけど、これが一番わかりやすくトラブルが少ないと思う。逆に、DIZE対応PCでは、ハードウェア法を使う。具体的にハードウェア法の中でどの方法を使うかは、コストや手間を考えると、当面は、せいぜいBIOSのデフォルトを変えるだけでいいと思う。数がまとまるなら、独自BIOSを作ってUSBキーを使って・・・とかいろいろアイディアはあるけどね。なお、DIZE対応PCでは、たとえ普通のAWARDのBIOSを使った場合でも、ブートシーケンスの変更がやりやすくなるはず。理由は、マニュアルをめちゃくちゃ親切にできるから。その部分だけでフルカラー10ページぐらい使えば、いくらなんでもできる。。。。。といいなぁ。 |
|
将来計画： DIZE専用マシンを作る！！！！ ・・・なんて大それたことができるかどうかはともかく、とりあえず備忘録がわりにこんなのをつくろうかな、ってなことを書いておこう。基本的には、量産効果とバイナリ互換性を考えればIBM-PC。いまならmini-ITXとかになるのかな。Geode みたいなのでもいいし。とにかくPC。ARMとか使った非PCが意味を持つのは、年間出荷台数1000万台、ロット100万台、とかの発注ができるようになってからだと思う。問題は、CD(DVD)ROMドライブ、HDD、FDD、拡張スロットをどうするか。FDDはナシが当たり前としよう。拡張スロットも、USB2.0を前提とすればなしでいいや。PCIバスの転送能力は標準で1Gbps ぐらいで、USB2.0は480Mbps。拡張スロットなしでもなんとかなるんじゃないでしょうか。大体、初心者にとってはフタあけてPCIのカードを刺すなんて不可能だから、実際にはスロットなんてあってもなくてもどうでもいいんだよね。ホワイトボックス系のショップにとってはスロットがあったほうがいいけど。ただ、CDROMドライブとHDDだけは通常は必要。 が、しかし。この二つは、デザインの自由度、コスト、信頼性、発熱、騒音、消費電力、大きさ、重さ、・・・・すべての面において、今のPCにおける多大な律速段階となっている。よって、この二つ（あるいはどちらか）がないPCの可能性については、十分検討の価値がある。なお、このとき、CDROMドライブとHDDをなくすことにより、単にその二つの負担が消えるだけでなく、ケース、電源、ファン、放熱などを大幅に簡略化できることに注意。CDROMドライブとHDDとFDDと拡張スロットがない、ってことは本体に必要なものはマザーとCPUとメモリだけなんだけど、この場合、ケースはプラスチックケースでもいいし、たとえ鉄製にするにしても、大幅に強度を下げれる。放熱も、ケースに逃がすようにすればファンレスが可能。さらに、消費電力が減るので、（Pen4のような異様な消費電力のCPUを使わない限りは）電源も大幅に簡略化できる。ACアダプタで可。これは、ケースの簡略化およびファンレスに非常に貢献する・・・と、まあ、CDROMドライブとHDD（とFDDと拡張スロット）をなくすことは、いまのPCの形態をかなり変える。具体的には、ACアダプタ駆動のスイッチングハブのような大きさのPCができる。一般人にわかりやすく伝えるときは、大きさ重さはVHSのカセット程度、がいいかも。 |
|
DIZE専用PCの検討：
|
|
もうひとつ検討課題は、キーボード。いまのIBM-PCのキーボードって、キーが多すぎないか？。もちろん、互換性を考えればある程度しょうがないんだろうけど、それでもねぇ。Scroll Lockキーなんて何に使うの？。もっと突き詰めれば、テンキーもいらないし記号も要らない。大体、106と101で記号の位置が無意味にずれてるのがあまりにも腹が立つ。だれなんだ？あんなアホなことをしたのは。決めたやつは万死に値するね。結局、筆者(JeyJokar)の個人的意見ですが、A-ZとリターンさえあればOKだと思う。足りない分は、ソフトウェアキーボードと入力予測。入力予測ってのは、昔 emacs であったでしょ。while と打つと、while(){とか勝手に入力されてるやつ。これを、初心者の日本語入力に特化した形に改良し、FEPに積めばいい。０−９の10個のキーしかない端末（つまり携帯電話）で日本語入力が可能な今、いまのキーは数が多すぎると思うけど。なお、このキーボードは当然初心者用であって、プロはプロで Happy Hacking Keyboard (HHK)でもIBMの機械式でも、好きなの買ってください。 |
|
|
三つ目に気にしてるのは、USBとイーサ、似たようなコネクタが二種類もあること。ぜんぜん違うだろ、イーサでマウスがつながるんかよ、と思うだろうが、技術的には可能。イーサでつながるHDD（NAS)があってイーサでつながるプリンタがあってイーサでつながるスキャナがあってイーサでつながるCDROMドライブ（CDジュークサーバ）があってイーサでつながるTVカメラがあって・・・なぜマウスがつながらないと言い切れる？つなげりゃつながるんだよ、マウスも。もちろん課題もあって、PnPの規格がぜんぜんだし、給電の問題があるし、ケーブルの太さの問題もあるけど、どれをとっても解決可能。 逆もありうる。USBでLANをすることもできる。ちょっと特殊なスイッチングハブで、アップリンクのポートが100Mのイーサで普通のポート（なんていうんだ？）がUSB2.0、ってスイッチングハブを作って、USBのコネクタしかないPCでも問題なく通信ができるようにする。個人的(JeyJokar)としてはこっちのほうがいいと思う。理由は、インテルがチップセットに載せまくったせいで、USBポートがないPCってもう全滅状態でしょ。でも、イーサポートは必ずしもついているわけじゃない。最近はADSLのせいで装備率は非常に上がってるけど。一般人にとっては、イーサポート＝ADSLポートだもんね。あと、イーサには給電の問題も残ってる。コネクタも大きい。伝送距離（とLANでのほぼ100％のシェア）を除けば、イーサの利点ってないんだよね。 |
|
|
HAHAは、FTTH(家庭用光ファイバ)環境が世界一整備されている日本の現状を利用し、高速・高信頼性・低価格なCDNサービスを実現するための技術です。すべてを徹底的に多重化することにより、家庭用PC、家庭用光ファイバなどを使用した場合も非常に高度な信頼性を確保できます。これにより、高速、高信頼性・低価格を実現しています。 |
| FTTH : | Fiber To The Home / 家庭用光ファイバ。通常、上り下りともに100Mbps。 |
| CDN : | Contents Delivery Network / コンテンツ デリバリ ネットワーク。 デジタルコンテンツの配送を行うための高速通信網。 |
| 静的コンテンツ : | Static Contents / スタティック コンテンツ。ウェブデザイナーがデザインした画面そのままのこと。その発信に関する処理は比較的容易。 |
| 動的コンテンツ : | Dynamic Contents / ダイナミック コンテンツ。デザイナーのデザインを元にプログラマーが画面生成のルールをプログラミングしておき、ユーザごと、アクセスごとに異なる画面を表示する。代表的な動的コンテンツに「掲示板」がある。動的コンテンツ実現の技術手段としてCGIがある。処理負担が比較的重いので、各種高速化技術、処理分散技術などが望まれる。 |
| CGI : | Common Gateway Interface。本義は ウェブサーバソフト最大シェアの Apache にある機能拡張手法。これにより、静的コンテンツだけでなく、動的コンテンツも使えるようになった。いまは、Apacheに限らず、すべてのウェブサーバソフトで動的コンテンツ生成プログラムのことをCGIと呼ぶようになっている。 |
| キャッシュ : | cache / 一時貯蔵庫、という意味。語源はフランス語だが、英語として使用可能。コンピュータ業界では、1度目の処理結果を一時貯蔵庫に記憶しておき、2度目以降は記憶内容を使い処理を省略することにより高速化を図る技術。現金(cash)と混同しないこと。 |
| リバースプロキシ : | reverse proxy。proxy は「代理人」。HAHAでは、多重化されたサーバ群と複数のキャッシュノード間の相互接続を行っている。リバースプロキシを使わない場合、あくまで通常の構成の亜種としてHAHAを実装するか、それともこのような変則的な構成をを直接認識できるサーバソフトを開発する必要性がある。リバースプロキシによる相互接続が開発工数的に最良と判断。 |
|
michitsuna は HAHAを技術基盤として採用した超低価格高信頼性CDNサービスです。スタンダードコースにおいては、月々3万円で1テラバイトの転送量を提供しています。 標準コースにおける各種スペック：
|
|
|
HAHA は、世界で最も整備されている(2003/5現在）日本のFTTH（家庭用超高速光ファイバ）環境を利用し、複数のFTTH回線にアクセスを分散させることにより、超低価格・超高速を実現します。ブラウザからのアクセスはラウンドロビンDNSにより自動的に分散され、適切なキャッシュノードに誘導されます。ラウンドロビンDNSを外部から見た場合、通常のDNSと互換性のある挙動を示すため、ブラウザを選びません。 |
ラウンドロビンDNSにより、ユーザはなにも設定しなくても
FTTH網上のキャッシュノードに自動的にアクセスが分散される。
|
|
キャッシュノードへコンテンツをキャッシュすることは、単にFTTHによる高速転送が可能になるだけではなく、サーバ処理時間の高速化、サーバ負担の軽減にも貢献します。一度転送されたコンテンツは一定条件（有効期限など）の元、キャッシュノードにキャッシュ（一時貯蔵）されます。キャッシュされてる限りは、コンテンツ配送はブラウザとキャッシュノードの間で自動的に行われ、ウェブサーバ側への負担はありません。また、キャッシュノードは、キャッシュデータの配送に特化した構造を持っており、非常に高速なCPU処理を行います。 この構造は、とりわけ動的コンテンツに有効に働きます。たとえば掲示板などが典型なのですが、たしかにユーザの「書き込み」などにより、動的（ダイナミック）に内容が変更されていき、それらはWebデザイナの手を煩わすことなくCGIプログラムにより自動的に処理されています。しかし、動的に変更されていくといっても、短い時間で観察すれば、同一の画面を繰り返し表示していることがよくあります。この場合、画面生成を動的に毎回ゼロから行うのはCPU処理時間の無駄であって、何らかの折り畳みが望まれるのですが、そこまで手が回ってないCGIコードが多々あります。HAHAでは、この折り畳みがほぼ自動的に行われます。 |
一度ソースサーバが発信したコンテンツは、途中のキャッシュノードに
一時保管（キャッシュ）されている。
同一コンテンツへのアクセスは、キャッシュデータを返すので、非常に高速。
|
|
HAHAにおけるWebサーバ（ソースサーバ）は、特定iDCにある特定のドメインネームを持つサーバに限定されません。下図に示すように、たとえば社内に設置されたWebサーバに特定のドメインネームに関する情報発信機能を割り当てることも可能ですし、ファイアウォール越えとセキュリティを考え、SSH（https/SSLとほぼ同じ）で中から外にファイアウォールを開けることも可能です。iDCにおいたサーバ、専用線接続で社内に置いたサーバ、ADSLで自宅に置いたサーバ、、、などを複数組み合わせることも問題ありません。 また、それらが静的（スタティック、固定）IPアドレスを持つ必要がないのも現実問題としては利点があります。動的（ダイナミック）IPアドレスでも問題なく動作します。 |
自社サーバなど、弊社のiDC以外の場所のサーバを
ソースサーバとして指定することが可能。
|
|
キャッシュデータの有効性の判断は、現状でも少なくとも以下の3条件が使用できます。なお、２と３は両立できます。12時間以内かつ今日の3時まで、という指定は可能です。 １、毎回Webサーバに確認する Webサーバへの負担は大きくなりますが、確実です。なお、他の条件が指定されない（または成立しない）場合のデフォルトはこれになります。 ２、一定時間有効 秒単位で任意の有効期間が設定できます ３、特定日時まで有効 各キャッシュノードの内蔵時計はNTP(Network Time Protocol/インターネット上で原子時計に同期する技術)により数千分の一秒程度の誤差で原子時計に同期します。この精度で指定時刻を認識し、キャッシュデータの有効性を判断します。 |
| HAHA の特色は、徹底的な多重化による高信頼性です。 たとえば、キャッシュノードが故障した場合、その故障は自動的に検出され、故障したキャッシュノードは自動的に切り離されます。正常なキャッシュノードによりCDNサービスは問題なく継続されます。故障したキャッシュノードの障害が解決した場合、そのキャッシュノードは自動的に復帰します。（下図に解説。クリックで拡大） |
HAHA 障害からの復帰 （クリックで拡大）
|
| ラウンドロビンDNS自体も多重化されています。（下図に解説。クリックで拡大） |
HAHA DNS(ドメイン名)の管理 （クリックで拡大）
|
|
以上の技術により、圧倒的な信頼性と高速性を実現しました。反応時間（レスポンスタイム）（クリックしてから次の画面が表示されるまでの時間）は大幅に向上しています。具体的な成果は状況に依存しますが、10倍以上も十分ありえます。 |
HAHA 高速化の内訳 (クリックで全部表示）
|
|
キャッシュノードのうちいくつかが故障したとき： → 処理能力が（正常なキャッシュノード／（正常なキャッシュノード＋故障したキャッシュノード））に低下するだけで、処理自体は問題なく継続する。 |
|
キャッシュノードのすべてが故障したとき： → 前提として、数十箇所はあるキャッシュノードのすべてが故障することはまずない。たとえば、おのおののキャッシュノードの可用性が99%だったとしよう。これは、1年間365日でいえば、362日稼動し、3日故障していることになる。つまり、数十人社員がいる職場で、各社員が一年に3日休むとして、全員が休む日が果たしてあるか、という問題とほぼ同様となる。なお、キャッシュノードのトラブルの原因に相互の依存関係はほとんどないので、いわゆる「集団感染」「学級閉鎖」のようなことはまずない。各自、ばらばらに休みを取る。このような状況において、数十人の社員が一人も出社しない日がそうそう想像できるだろうか。さらに、万が一の場合も、メインサーバ、バックアップサーバにアクセスが自動的に分散されるので、非常に遅くなるが処理自体は不可能ではない。ただし、メインサーバによる直接処理では、速度などを考えれば実用性には非常に疑問がある上、処理能力オーバーでサーバがパンクし、処理が停止してしまうかもしれない。 |
|
メインサーバが故障したとき： → CGI機能は停止するので動的コンテンツは発信できなくなる。静的コンテンツに関しては、バックアップサーバが処理を継続する。当然、この場合、バックアップサーバの処理はキャッシュノードに分散されるので、速度的にも問題はない。 |
|
ブラウザについて： HAHAはDNSをいじってすべてのアクセスを特段の設定なしに キャッシュノードへ誘導している。 で、これでなぜ普通のブラウザそのままでアクセスができるか、 だけど、 いわゆる透過型プロキシをいれた LANを考えてほしい。ファイアウォールの内側ではDNSをいじって 外へのアクセスはすべてプロキシを指すようにしている場合があるけど、 HAHAはそれと同じ原理を使っている。 Host: ヘッダを見て適当に処理すれば、dest IPがどうだろうと、 DNSがどうだろうと、あとはL7で処理が進む。 別の言い方をすれば、http パケットの dest IP は 常にキャッシュノードを指すので、 Host: ヘッダを吐けないブラウザではアクセスできない。 といっても、そんなブラウザでは、 name based virtual hosting には対応できないので 今のほとんどの独自ドメインサイトへのアクセスは不可能だし、 第一、1994年以降そんなブラウザがリリースされたという話も聞かないし、 自分の知っているブラウザでそんなのはネットスケープの バージョン1.0 だけであって、IEでは全バージョンでHost:を吐き出すし、 ネットスケープも2.0以降は吐き出すし・・・・と、 考える必要性はないはずだが一応。 どーしてもこだわりたい。古いブラウザもどーしてもサポートしたい、 10年前のブラウザだってサポートしろ！ ほとんどのウェブサイトが見れないようなブラウザでもサポートしろ！ サポートしてくれなければ死ぬ！ という人のために、たとえば、 oldbrowser.digitalinfra.co.jp/URL でアクセスできるようなサービスも考えている。たとえば、 www.aaa.com/bbb.html なら、 oldbrowser.digitalinfra.co.jp/www.aaa.com/bbb.html で見れるとかね。 |
|
https(SSL)について： HAHA は、FTTH上のキャッシュノードに分散しているって点を除けば、 透過型プロキシでありname based virtual hosting であり、、、 といった世界とほぼ同じ技術。 よって、それらの欠点もそっくり継承している。 よって、SSLは無理。 意味わかんなければ、Virtual Hosting / name based / IP based / SSL / Host: あたりで 検索してください。 といっても、HAHAでは static なコンテンツしか CDNできないわけだが、 static なコンテンツでSSLしたい場合などほとんどゼロなんで、 問題はない。 いま、まともな用途でSSLしているのって、クレジットカードを つかったインターネット通販の決済でしょ？ で、ここはモロCGIの動的ページだから、どうせHAHAは対応しないんだよな。 なお、HAHA は HAHAで、なんかの決済手段を 提供することは考えている。詳細は未定だけど。 |
|
コンテンツが更新されたとき： HAHAは、処理を軽くするため、キャッシュ期限がくるまでは一切自動的なキャッシュ更新をしない。よって、コンテンツを更新したときは、 （すごくキャッシュ期限を短く切っていれば別だが） 手動でCDN全体のキャッシュデータを更新しなければならない。 やり方自体は簡単で、CDN参加者からすればWebのコンパネ（要認証）で一発。 内部的には、すべてのノードに対し、 キャッシュの無効化操作を行う。 非常に特別な場合（犯罪がらみのコンテンツとか）を除き、 各ノードに対して行うことは、キャッシュデータの削除ではなく、キャッシュの無効化である。次回、一般ユーザからアクセスがあったときは、ソースサーバへキャッシュの有効性の確認はするが、データの転送の必要性はない。これにより、変更のないデータの 無駄な転送が削減できる。 逆に、どうしても即座に本当に削除をしなければならないような特別な場合は、undelete してキャッシュから復元する行為を防ぐためにも、ランダムデータを上書きしてからファイルの削除をしようかとおもうが、細かいところは検討中。 検討中だが、キャッシュ無効化プロトコルには、権限の認証をしないつもり。 つまり、一般ユーザでもだれでもノード単位ならキャッシュの無効化ができる。ヒマなやつがすべてのノードに対しキャッシュの無効化をすれば、コンパネをいじったのと同じことになる。 これがどのような利点があるかというと、まずひとつは、間抜けなサーバ管理者が、自分のところのコンテンツが更新されているのに、それをCDNに反映してない場合。一般ユーザの立場でもキャッシュの無効化ができるので、「おーい、いつまでたっても古いコンテンツしか見れないぞ」ということがなくなる。 もうひとつは、ニュースや掲示板のように、即時性が重要なデータを配信するとき。たとえ、ソースサーバの管理者がちゃんとやることをやって、キャッシュ期限の設定といい、更新告知といい、きっちりやったところで、どうしてもキャッシュ上から旧データが一掃されるのにあるていど時間はかかる。これは、広域分散キャッシュであるHAHAの特性上、いたしかたない。この一瞬がイラつくんだよ、との声にお答えして、ユーザレベルの無効化を許可しようと思う。 ユーザレベルで無効化できることの問題点は、ヒマなやつが無効化をしまくると、ある種のDoSになること。一応法律的には威力業務妨害に該当するが、現実問題としてどう対処するかは悩ましいところ。とりあえずのアイディアとしては、ユーザレベルで無効化できるコンテンツとできないコンテンツを分けること。 |
|
キャッシュ無効化プロトコル： いまのところ、こんな感じの超いい加減な方式を考えてる・・・というか、一応squidで実装（もどき）をしたら動いてるっぽいので、このまま採用するつもり。 たとえば、sample.com/aaa/bbb.html を無効化したいなら、 そこの aaa/bbb.html_HahA_invalid_this をアクセスする。aaa/bbb.html_HahA_it でも同じ。 「HahA」の両端が大文字、真ん中が小文字なのは必須条件。 これだけで無効化される。パスワードも何も要らない。 ここで、完全HTTPベースの単純すぎる方法を採用した理由ですが、ユーザレベルでの無効化の場合に、プロキシの中からでも簡単に無効化できるように、という配慮です。 |
| コマンド(省略形式） | 解説 | |
| invalid_this(it) | 指定URLのデータのみを無効化する。/aaa/index.html_HahA_it など。認証は原則として不要。 | |
| invalid_all(ia) | 指定URLと同一ディレクトリのデータすべてを無効化する。/aaa/_HahA_ia など。認証必要。 | |
| invalid_recursive(iR) | 指定URL以下のすべてのデータをディレクトリを再帰的にたどって無効化する。domain.com/_HahA_iRとすると、そのドメインのデータすべてが無効になる。また、サブドメインもクリアする。つまり、*.yourdomain.com/* すべてをクリアする。省略時、打ち間違い防止のためiは小文字Rは大文字。認証は絶対必須。 | |
|
CGI機能をメインサーバに制約した理由： → フェイルオーバーまで作りこむと、信頼性、機能性、ともに非常に有益だが、複雑になりすぎ、費用対効果に疑問がある。フェイルオーバーなしならバックアップサーバにもCGI機能を入れることは可能だが、フェイルオーバーなしのCGI機能の冗長化には、信頼性向上には有効だが、機能性に疑問があり、やはり費用対効果上疑問がある。たとえば、アクセスカウンタひとつとっても、トラブル時にアクセス数を引き継げず、ゼロにリセットされてしまうカウンタでは、たとえ動き続けても意味がない。しかし、たかがカウンタでも、カウンタの値をフェイルオーバーさせるのはあまりにプログラミングが複雑になる。たかがカウンタでも複雑なのだから、もっとまともなアプリであればなおのこと。（通常、フェイルオーバーは、OSやミドル、DBなどのレベルで統一的に処理することは困難であり、個々のアプリごとに作りこむ必要性がある） |
|
ログの処理について： キャッシュノードへのアクセスに関しては、多少タイムラグはあるが、最終的にはメインサーバのログへ統合される。また、この際、時間軸でソートしているので、入れ違いもない。（キャッシュノードの内部時計は、NTPで0.0001秒程度の誤差に常に同期している） |
|
パスワードつきサイト： サポートの予定は今のところない。理由は、技術的なものではなく商業的なもの。いまパスワードつきサイトで、CGIなしで高トラフィック、なおかつ小予算のサイトのほとんどが猥褻サイトである。これが理由。商業的に、猥褻サイト以外の需要が高まれば検討する。 |
|
squid にした理由： Apacheのmod_proxyとかでも可能だったけど、やっぱり「もちは餅屋」。 |
|
合法的猥褻コンテンツは規制するのか： まず、HAHA と michitsuna の違いを理解すること。 HAHA を利用してCDNを作る場合に、どのような方針をとるかは、そのCDNの問題。自分の責任で勝手に決めること。Linuxをつかった仮想ホスティング業をやる場合に、猥褻コンテンツに対する規制をどうするのかは各業者が自分の責任で決めることであって、リーナス トーバルズさんやレッドハットがきめることではない。それと同様。 michitsuna においてどのような方針を採るのかは検討中。弊社の根本的な考え方としては、小学館や講談社（またはその系列）などの大手出版社が出版しているような内容も含め、一切の猥褻コンテンツは好ましくないというのが基本。たとえ、芸術、などと言い訳しても例外は認めない。よって、弊社でそのようなコンテンツを作成することは決してない。ただ、他人がそのようなコンテンツを配布することを規制できるか、となると微妙。別の言い方をすると、小学館や講談社の立場に弊社が立ったときは、ずばり一切の猥褻コンテンツはノー。しかし、大日本印刷（印刷最大手）やトーハン・日販（ともに、書籍卸大手）の立場に立ったときに出版社に対して、「ノー。うちでは流通させません」と言えるかどうかは難しい問題。 なお、HAHAにおいて、猥褻コンテンツに特化した機能の実装の予定はまったくない。機能の実装の判断基準は、通常コンテンツに対する必要性のみ。もちろん、これを使って無理やり猥褻コンテンツを配布することも可能だが、それは仕方がない。「写真集・奈良の大仏のすべて」を刷るための印刷機で「女子大生全裸」も刷れるが、それはそれで仕方ないのと同じ。 |
|
非合法コンテンツに対する規制： 合法的猥褻コンテンツと基本的に同様。HAHAをつかって勝手なCDNを作るときは、自分が正しいと信じる道を勝手に歩いてください。高い塀に囲まれた素敵な世界にたどり着けるでしょう。michitsuna では、合法的であっても猥褻物は認めないのであって、非合法であればどのようなコンテンツも認めないのは当然。 ただ問題は、CDNの場合、原理上、すべてのコンテンツを事前に検査するのが困難なこと。 michitsuna においては、原則として事後検査によって非合法コンテンツに対処するつもり。第三者から見て公知の状態になっているコンテンツをこちらが検査し、非合法であれば積極的に削除していく。いままでは、このような「事後」でもOKだった。しかし・・・。 最近の判決によれば、意図していなくても、結果として悪用された場合、「幇助」と認定されている。これは、あまりに従来の基準を逸脱した判決なのだが（トヨタ自動車はひき逃げの「幇助犯」なのか？）、ここでそれを議論するつもりはない。ただ、そのような判決が出た現状を考え、法律的、技術的両面より安全策を検討中。 |
|
michitsuna は december 専用？ ちがう。michitsunaは CDN。decemberは CGI+CDN。それぞれ目指すところが違うサービス。michitsuna は、december 以外のコンテンツも転送する予定。 |
|
michitsuna とAKAMAIなどのほかのCDNの比較： 料金を無視し、どちらがいいかといわれれば、当然AKAMAIのほうがいい。技術的に弊社が勝るところはひとつもない。何百億円もの投資でマイクロソフトやヤフーとの大型契約を勝ち取っている業者と、所詮は家庭用FTTHを間借りしている業者では結果は見えている。ただ、速度、信頼性とも、差はあるといってもわずか。ほとんど同水準ではある。違いは料金。こと料金に関しては、100:1というレベルで圧倒的な安さ。100倍とられても最高のものを。差はわずかでも最高のもを。わずかな差でもこだわりたい。費用は無視、ってならAKAMAIへどうぞ。そんなお金持ちなあなたにはズバリお勧めです。 |
|
michitsuna の命名の由来： HAHA → 母 → 藤原道綱母。「母」「網」（結局は、それに似た字になったけど）が入っていればなんでもよかった。なお、彼女は、現代風にわかりやすく説明すると、結婚後数日で夫に朝帰りされ、「悲しすぎます」という詩を作って有名になった人。っていってもわかんなければ、国文学の先生にでも聞いてください。 |
|
HAHAの命名の由来： High Availability (HA)(高可用性・こうかようせい・ノンストップという意味のコンピュータ用語）を入れることは、コンセプト上決まっていた。HA-Linuxというのはあるので、あとはそれとかぶらない命名なら何でもよかった。採用決定理由はロゴデザイン上の理由。ためしにやってみたらそれっぽいロゴをあっさり作れたのが決め手。「はぁはぁ」、とか 「あははは！」とかじゃなくてハハと発音してくれ。 |
|
ノードの募集（実験期間中）： decemberのほうがのびのびなんで、そちらが片付いてからですが、HAHAの公開実験をいつか（っていつだ？）やるんで、そのときは希望者大募集でしょう。条件としては、FTTHと腐ったPCがあればなんでもいいです。ウイルス防止の観点もあってHAHAのシステムはブータブルCDになってますので、それを入れてリセットすればすべて自動的に立ち上がります（HDDへのインストールも可能）。ラウンドロビンDNSはダイナミックDNS機能をもっているので、固定IPは不要です。ダイナミックIPでお気軽にどうぞ。ただし、無償ボランティアです。CDNのノウハウが学べるのがメリットでしょう。HAHA自身はフリーなんで、勝手にパクって自分たちで儲けてくれ。 あと、これはあくまで予定なんで本当にどうなるかまったくわかりませんが、ブータブルCDの中に、ホームサーバ＋ブロードバンドルータ＋ファイアウォール機能を焼き込んだ製品を考えてます。で、これを無料でHAHAのCDにつけてしまう構想があります。構想があるだけだけど。この構想が実行された場合、HAHAを使えば自動的にホームサーバとブロードバンドルータとファイアウォールも手に入ります。 |
|
ノードの募集（商用展開にむけ）： HAHAの技術を michitsuna という形でサービスとして商用展開するときは、ノードに対して協力費を払います。月々1万円程度を予定してますが、やることはPCの電源を入れておくだけなので、十分ペイするのではないでしょうか。ちなみに、電気代がどーのこーのとか言い出すやつがいそうですが、Celeron1Ghz + HDD100G (5400rpm)ぐらいのシステムで、平均消費電力なんてせいぜい50Wぐらいです。気になるなら電源電圧ダウン＋クロックダウンでもやりましょう。多分、20Wぐらいまで追い込めると思います。この場合、月々の電気代は500円を切ります。さらに、それでもこだわる人にはクランプメータ無料貸し出しも検討してます（笑い）。むしろ、問題は廃熱処理と空調でしょう。たとえ30W平均の廃熱でも、真夏に冷えた部屋を保ちたいなら20Wぐらいは冷房が電気を食います。いまの廃車費用みたいなもので、捨てるのにもお金がかかるってわけですね。 |
|
技術的に何が凄いんだ？： → 技術的に凄いところはないです。単に、ラウンドロビンDNSとリバースプロキシを組み合わせているだけです。現実問題として、キャッシュ無効化処理を除けば、社内実験では squid と djbdns の組み合わせで無改造で動いています。設定は若干通常とは違うものですが、それでもソースレベルでいじる必要性はありませんでした。 HAHAのポイントは、技術どうこうではなく、FTTHという日本が世界最先端を切っている環境の有効利用であって、つまり、技術ではなく現実こそHAHAの真価です。 |
|
squidの設定とか： → これはdjbdns の設定にも絡みますが、 ポイントは、オリジン（ソース）サーバに関して、 ユーザに見せるIPアドレスと、squid が認識するIPアドレスを変えることです。 squid は本物のオリジンサーバを正しく認識できる必要性がありますが、 ユーザにはキャッシュノードをソースサーバと誤認してもらう必要性があります。いまのところ、squid ではなく djbdns側に細工をしていますが、それはsquidのほうが経験が少なかったので、面倒を避けたかったからです。理論的にはどちらを細工してもなんとかなるでしょうし、インターネットの哲学からいえば、正しい答えを出すのが前提であるDNSを細工するより、その動作が設定によりいろいろ変わりうるのが前提の squid を細工するほうがより美しい、という発想もありうるでしょう。 |
|
HAHAの最大の技術的問題点は、データをどこから引っ張るかの決定法です。 「データは探索しない。キャッシュノードは常にオリジンサーバからデータを引っ張ってくる」。このようなルールをつくればどこから引っ張るかの決定は簡単ですが、転送量が増大する上、可用性も減ります。 逆に、周りのキャッシュノードから適当に引っ張ってくると、「どのキャッシュノードにデータがあるか」を探索する必要性があります。 squid 開発陣はこのあたりのことを認識しており、ICPというUDPベースのプロトコルにより、「このデータ、持ってる？」といった問い合わせが送れるようになっているのですが、このプロトコルのオーバーヘッドが無視できません。 とくに、遅延への影響が大です。 たとえば、デフォルトだと、周りのキャッシュノードにパケットを送り、最大2秒間待つ。二秒以内に返答がないか、それとも二秒以内に誰もデータを持っていないことが判明すればオリジンサーバを叩く。二秒以内に誰かが持っていると返事をすればそこから引っ張る。というのがデフォルトの方式なのですが、二秒って・・・・遅くないですかね。もちろん、このタイムアウトの値を短くすることは可能なのですが、そうしたらそうしたで、周りが持っているデータをオリジンサーバから引っ張る率が高まるわけですし。 さらに、この方式は、網の中をつねに大量のICPパケットが飛び交うので、その転送量も馬鹿にならない。で、どうするか。以下のようにとりあえず決定。思いつきでちょっと作ってみたけど、なんとなく動いてるっぽいような感触もあるかな。
どのドメインに対しどのIPを割り当てるか、いくつ割り当てるか、だが、要因はいくつか考えられる。 ・ユーザのネットワーク的トポロジー ・回線の込み具合 ・サーバの負荷 ・ドメインのアクセス数 ・ドメインのデータ量 ・１コンテンツあたりのデータ量 基本的に、データ1個がでかく（市販ソフトのサンプル版など）、データの数が少なく、さらに、それのアクセス数が多く、、、といった サイト（ようは、市販ソフトのサンプル版や人気映画の予告編のビデオファイルとか）に関しては、大目のIPアドレス（というかキャッシュノード）を割り当てればOK。 で、あとは、この複数のIPアドレス（というかキャッシュノード）のなかから、ユーザにトポロジ的に近く、なおかつ速度に余裕のありそうなキャッシュノードのIPアドレスをDNSが返す。DNSのキャッシュ期限はめちゃくちゃ短く切ってあるので、網状態に急激な変化があってもまったくOK。 逆に、個人サイトとかでアクセスが少なく、しかし細かなデータがぱらぱらとたくさんあって・・・といった場合は、そのサイトのキャッシュはひとつのノードにしか割り当てない。冗長性は、そのノードが死んだらほかのノードに割り当てることによってのみ実現（当然、DNSは何らかのkeep alive なり status check の polling なりをキャッシュノードにかけている）。 さらに、DNSのキャッシュ期限を短く切ることにより、 |
| 作成(パワーポイント版＆HTML版）開始： | 2003/4 |
| 一般公開（HTML版）開始： | 2003/5 |
<<BACK
Copyright (c) 2003 Digital Infra, Inc. All rights reserved.
