2005年05月15日

これは大変!?:インテルのハイパースレッディングの脆弱性

なんとインテルのハイパースレッディングに脆弱性がという記事です。
マイクロプロセッサーのハードウェアレベルの根幹部分に脆弱性というのもすごい話ではあります。

記事からリンクされてる論文(英文)をちょこっと読んで見ました。
どうやら、"covert channel"(偽装通信)に関する脆弱性のようです。
"covert channel"とはセキュリティの用語で、裏技的な通信経路を使って本来認められていない情報の交換を、一見情報の交換とは見えないようにひそかに行なってしまえる脆弱性のことです。
たとえて言うならば、スパイが仲間に情報を密かに伝えるのに、窓のブラインドの開け閉めでモールス信号を送るようなものです。

インテルのハイパースレッディングでの"covert channel"ですが、各スレッドがキャッシュを共用していることを利用しています。
もちろん権限が異なる他のスレッドのキャッシュのデータを読むことはできないのですが、他のスレッドが使っているキャッシュのラインを意図的に上書きすることはできるようになってます(その時は、当然他のスレッドのキャッシュのラインの内容はメモリに書き戻されます)。
他のスレッドが次にそのキャッシュラインを読んだ時にはキャッシュの内容は無効になってますから、メモリまで読みにいくことになり、キャッシュにヒットした場合よりも時間がかかります。
この時間を計測して、キャッシュがミスしたかヒットしたかを判断することで、完全に隔離されているはずのスレッド間で密かに1ビットの情報をやり取りすることができるわけです。

ものすごく大変なように見えますが、論文中では簡単なサンプルプログラムが提示されており、クロック2.8Ghzのプロセッサであれば、毎秒400KBの"covert channel"での通信が可能であるとされています。

さらに、この手法を使ってOpenSSLのメモリアクセスパターンを別のスレッドから推定して秘密鍵を読みとる手法も公開されています。

対応策ですが、プロセッサないしOSレベルでの大幅な設計変更を要することになり、短期的にはハイパースレッディング機能をオフにすることくらいしかないようです。

うーむ、これはかなり本質的な問題のような気がしますね。
論文、まださらっと読んだだけなので、もっとちゃんと読んでからまた続報いたします。

投稿者 kurikiyo : 08:34 | コメント (0)

2005年04月20日

AzulのNAP受注開始

エンジニアリング的な興味もあって、このblogでしつこくフォローしているAzul Systems社のNAP(Network Attached Processor)ですが、いよいよ受注開始のようです(参照記事)。

実はAzul社CEOのStepehen Dewitt氏にもインタビューしてきました。
Dewitt氏はCobalt社のCEOをやっていた人です。
当然ながらテクノロジーや市場の方向性もよくわかっていますし、大変にエネルギッシュな人でありました。

彼らのテクノロジーの優位性を説明する時のロジックですが、やはりこのblogのエントリー「プロセッサアーキテクチャの世界に風は吹いているのか?」のような話になりました。
「15年前のRISC革命の時と同じような変曲点(Inflection Point)が今また来ているのでしょうか?」と聞くと、「まさにその通り!!」との回答が。

テクノロジー的なことはあまり聞けなかったのですが、ハードウェア・レベルでGCをやるので、アプリケーション・プログラムの停止なしでリアルタイムGCができるようです。
また、コスト的にも「最も安価なIntelベースのサーバ(要するにDell)よりも安い」し、「設置スペースや空調などの環境コストまで加味するとさらに安い」そうであります。

米国ではIBM、日本ではCTC等、パートナーシップも強力であり、結構化けそうな気はします。

後は、実際に大手顧客にシステムを導入して価格性能比上のメリットの実績を作ることが課題でしょうね。
しかし、意外に日本のメディアのカバレッジは薄いですね。

投稿者 kurikiyo : 23:25 | コメント (0)

2005年04月10日

ミッション・クリティカルという言葉

IT業界では、ミッション・クリティカル・システムという言葉が良く出てきます。
要するに企業の業務の根幹を成しており、停止すると企業の業績に直接的な被害をもたらすシステム、要するに止まったら非常に困るシステムと言うことです。
典型的には、銀行のオンライン・システムや飛行機の予約システムなどが相当します。
「基幹系システム」と意訳されることもあります。

ここで、どこからどこまでがミッション・クリティカル(基幹系)なのかという議論はあってしかるべきでしょう。
ちょっと前に、某インテル・サーバ・ベンダーのプレスリリースでLinuxサーバが某金融機関の基幹系で採用されたというプレスリリースが出たので、びっくりしてよく調査してみると、そのシステムとはリスク管理アプリケーションでした。
確かに、リスク管理システムは止まったら困るので基幹系といえなくもないですが、実際の処理の実態は計算処理中心で、ヘビーなデータベース処理が入るわけではないので、アプリケーションとしては結構シンプルです。

この例に限らず、ベンダーがミッション・クリティカルや基幹系と言ったときには、具体的にどのレベルのことを指しているのかを考えてみるべきでしょう。
たとえば、Linuxもカーネル2.6でミッション・クリティカル機能を強化したという触れ込みですが、もちろん、これはLinuxが今すぐに銀行のオンライン・システムに適用可能ということではありません。

ミッション・クリティカルを「止まったら困る」という風に定義してしまうと、たとえば、メール・サーバなどはかなりミッション・クリティカルですが、メール・サーバを基幹系と呼んでしまうのはちょっと違和感がないとは言えません。

たぶん、高要件トランザクション処理とか大容量データウェアハウス処理とかより具体的な言葉で、できれば定量的サービス・レベルで語ってくれると一番良い(たとえば「当サーバは毎秒1,000件のトランザクションを99.99%の可用性で処理した実績があります」という風に)のですが、ベンダーのマーケティング的にはそういうわけにもいかないでしょうね。

投稿者 kurikiyo : 11:20 | コメント (0)

2005年04月06日

富士通PrimeQuest発表

PrimeQuestとは、Itanium 2を使ったハイエンドサーバ(コード名:プレアデス)のこと。
Itanium 2の16ウェイ、32ウェイ(64ウェイはたぶん今年後半)、独自チップセット使用というのは既に報道されていたスクープのとおりでしたが、興味深いのはパッケージング技術。

ケーブルレス設計ということで、筐体内にケーブルがまったくといってよいほどありません(発表会場に実機があったので確認しました)。
これにより整備性が各段に向上したようです。
やはりこの辺の技術は国産メーカーの独壇場と言えますね。

また、チップセットレベルでメモリ、クロスバー、I/Oの二重化をサポートしており、ソフトウェアにとっては完全透過に障害時のフェールオーバーを実現できるようです。これは結構すごいかも。
したがって、Linuxも特に手を加えることなく、ハード・レベルの信頼性向上を享受できるわけであり、RHEL 4がそのままで稼動するようです(以前のエントリーに書いた、ベンダー独自の拡張機能をGPL規定にしたがって公開するのかしないのかという話は、このマシンにおいては関係なかったことになります。)

完全二重化やチェック機構の強化により、ハード的な信頼性はメインフレームと同等以上ということです。
ただ、心配なのはサポートOSがLinuxとWindowsということで、OSも含めたシステムレベルの信頼性でメインフレームを凌駕するのは難しいでしょう(メインフレームの枯れたOSはほとんどバグ抜けてますので)。
Windowsではどうしてもマイクロソフト頼みになってしまいますが、Linuxであれば、富士通がどんどんコミュニティに貢献することで信頼性向上できるわけであり、そのへんに期待するしかないでしょう(結果的に、コミュニティも利益を享受できますし)。

これで、NECも日立も富士通も自社独自の付加価値を加えたItaniumベースのハイエンドサーバを擁するという状況になりました。
米国系ではIBMがItaniumのサポート打ち切り、SunはAMDとの関係からItaniumをサポートする可能性はゼロに近い、デルはそもそもハイエンドはあまり興味なしということで、ItaniumをかついでいるのはHPじは当然として、後はユニシスくらいになってしまいました。
かつて思われていたようにItaniumがハイエンドの世界でもマジョリティになるかというとどうもそういう感じではなさそうですが、寡占状態になるよりも、PowerやSPARCと競い合っている今の状況の方が、市場構造としては健全と言えるでしょうね。

投稿者 kurikiyo : 22:47 | コメント (0)

2005年04月04日

プロセッサアーキテクチャの世界に風は吹いているのか?

以前のエントリーで書いたAzul社のVEGAですが、やはり自社開発の独自アーキテクチャのプロセッサのようです。

どの市場でもそうですが、プロセッサ市場は時の経過と共に寡占化が進んでいく傾向が強いです。
エンタープライズ向けの世界で言えば、Intel、SPARC、Power、そしてIBMメインフレームくらいしか選択肢がなくなってきました(組み込み系はまた別の話です)。

プロセッサは、
1.上位のソフトウェアが蓄積していったんエコシステムができてしまうとそれを突き崩すのは困難
2.設計・開発・製造には莫大な投資が必要なので小規模企業が既存勢力を打ち崩すのは困難
という特徴があるので、強いものがますます強くなっていくと言う傾向があるわけです。

最近の例ですと、Transmetaがプロセッサ製造事業から実質上撤退してしまいました。
インテルとのバイナリ互換により上記の1の問題は回避できても、2の問題は如何ともしがたかったということでしょう。

しかし、テクノロジー環境の激変という一陣の風が吹き、市場構造が変わってしまうこともあります。
1990年ころに起きたRISCテクノロジーの台頭はその例でしょう。
当時のVLSIテクノロジーによるプロセッサの1チップ化は複雑な命令セットよりも、1サイクルで実行可能でかつコンパイラの最適化もしやすいシンプルな命令セットに圧倒的に有利に働きました。
その結果として、当時主流であったVAXやMotorola 68000系等々のエレガントな命令セットを持ったプロセッサ・アーキテクチャが死に追いやられました(Intelは命令セットが貧弱だったことが逆に幸いして生き延びることができました)。

今、15年前のRISC革命の時と同じような風は吹いているのでしょうか?
1.JVMや.NET CLPのように、バイナリ依存でないアプリケーション実行環境が整いつつある
2.ネットワーク・エッジ部分ではシングルスレッドのパフォーマンスよりも並列度向上によるスループットの方が重要になっている
3.製造プロセスの向上によりクロック数を上げて性能を出すという方向性が発熱の問題により厳しくなってきている
4.Itaniumのように、シングルスレッドの並列性を向上するアプローチは限界があることが見えてきた
などを考え見ると、結構強風が吹いているような気もします。

VEGAのように、シングルスレッドの性能はそこそこにして発熱を抑え、マルチコアによる並列性を追求する、JVM専用にしてバイナリ互換は捨てるというのは結構うまく風に乗ったアプローチではと思います。

ただ、Intelもバカではないので上記の風きはわかっているはずです。
そして、自社テクノロジーを活用して同じようなソリューションを出してくる可能性は十分にあるはずです。
TransmetaがIntelに勝てなかったことからもわかるように、既存勢力に勝つためには「より優れている」だけではダメで「飛躍的に優れている」だけの差異化が必要でしょう。

Azulはどのくらい差異化できるのか?めちゃくちゃ興味わいてきました。

投稿者 kurikiyo : 16:38 | コメント (0)

2005年03月30日

今さら(?)の新CPUアーキテクチャ

NAP(Network Attached Processor)というJVM実行専用のサーバに関する記事(元記事(無料のユーザー登録必要))

複数のアプリケーションをまたがって動的に割り当て利用できるCPUプールを作っておこうという発想自体は新しいものではなく、ブレードサーバ等でプロビジョニングと呼ばれる機能として実装されています。
この製品のユニークなところは、こういう動的CPUプールの実現のために、専用のCPUアーキテクチャ(仮称VEGA)を作ってしまったところ。
コア単体の性能は控えめの24コアのマルチコアアーキテクチャで、SunのNiagraなどの同等の設計思想ですね。
最初にSunからコア単体の性能を抑えたマルチコア、マルチスレッド・アーキテクチャ(いわゆるスループット・コンピューティング)の話を聞いたときはマイクロアーキテクチャ面で遅れているSun SPARCの苦肉の策かという印象を持っていましたが、どうもネットワーク・エッジ部分ではこういうアーキテクチャの方が価格性能比が良いなのは確かなようです(エッジの処理は本質的に並列性が高いですから)。

エンジニアとしての視点から見ると興味津々なのですが、アナリスト的な視点から見ると、今更新しいCPUアーキテクチャを一から作って大丈夫なのかというのが正直なところです。
Intel系のブレードサーバをプロビジョニングする場合と比較して本当にメリットがあるのでしょうか?
この製品の製造元であるAzul Systems社のWebサイトを見ると、SunでHigh Performance Computingや競合分析などの要職を歴任したShahin Kahn氏の名前があるので、テクノロジー的には健全だと思うのですが。要チェックではあります。

投稿者 kurikiyo : 00:28 | コメント (0)

2005年03月12日

Itaniumの生きる道?

Itaniumについてちょっと前に書きました(記事1記事2記事3記事4(要無料ユーザー登録))。
結論としては、アーキテクチャ的には優れているがマーケット的にはちょっと厳しいだろうというもの。
(ただし、最近のマルチコア、マルチスレッドのトレンドを見ていると無理して命令セットレベルの並列性を追及してもあまり意味がなかったのかという気もします(そういう意味では参照記事の中身も既に古くなってしまったかも)。)

Itaniumの最大の誤算は言うまでもないですが、X86とのバイナリ互換性が実質上ないに等しいことでしょう。
AMDのOpteronの市場圧力にも負けて、IntelがEM64Tを出してしまったこと、要するにまったく新しいアーキテクチャを出さなくても既存X86の64ビット拡張でそんなに問題ないということをIntel自身が表明してしまったことも、Itaniumの市場での将来性に疑問を投げかける結果となっているのは改めて説明するまでもないでしょう。
IBMが実質的にItaniumサーバから撤退してしまったこと(関連記事)も逆風です。

もちろん、HPのハイエンド・サーバにおけるPA-RISC後継のチップとしてはItaniumは有望です。
そういう意味では、Itanium≒PA-RISCⅡみたいなポジションになってしまったと言えるかもしれません。

ただ、Itainiumの優位性としてもうひとつ忘れてならないのは、他プロセッサーのエミュレーションがやりやすいという点です。
やはり、汎用レジスタ数が多い(128個)というのは有利です(汎用レジスタの多いマシンで汎用レジスタの少ないマシンをエミュレーションするのはその逆の場合と比較してかなり楽です。)

たとえば、NECは、自社のハイエンドメインフレームのプロセッサをItaniumに置き換えてます(関連記事)。
カーネル部分はItanium向けに書き換えで、ユーザーコードはエミュレーションで動かすという、昔MacがCISC(68000)からRISC(PowerPC)に移行した時と同様な実装らしいですが、メインフレームのネイティブ・プロセッサの場合と遜色ない性能を出せているようです。

そんな中で、ちょっと注目なのが、米ベンチャーPlatform Solutions社の製品。
Itaniumベースのサーバで、IBMのメインフレームハード環境を完全エミュレーションする(IBM製のOSやミドルウェアを稼動する)というものです。
現在ではIBMメインフレームの互換機市場は存在しない(米国互換機メーカーは撤退、富士通・日立の製品ははIBM系ではあるけれどIBM互換ではない、NECはIBM系ですらない)のですが、思わぬところから伏兵が出てきたという感じです。
互換製品がないとユーザーとしてはベンダーとの価格交渉上著しく不利になりますので、米国のメインフレーム・ユーザーにとっては朗報かもしれません。
サポートの問題等はあるかもしれませが、日本でも販売されるとおもしろそうですけどね。

投稿者 kurikiyo : 23:25 | コメント (0)

2005年02月21日

サンのデータベース戦略の選択肢

当然ながらこのblogでは業務上知り得た秘密については書きませんが、Sunのデータベース戦略についてはもうメディアに載ってしまっている(「Sunのシュワルツ社長、データベース計画、SPARC、HPを語る」)ので、ここでもちょっと考えて見ましょう。

SunがSPARC/Solaris中心のハードウェアベンダーから総合システムベンダーへの脱皮を図っているのは言うまでもないですが、そこで重要となるのがミドルウェアスタックです。
Sunは、ミドルウェアのばら売りをやめてJES(Java Enterprise System)として一括提供すると共に、利用企業の社員一人当たり年間100ドルで無制限の使用が可能という斬新なライセンス体系によりソフトウェア分野での起死回生を狙っているわけです。
この戦略、一見すばらしく見えますが、最大の問題点はデータベース製品が欠如していることでしょう。
ユーザーは結局Oracle(場合によってはDB2)を使わざるを得ず、Sunの価値提案は中途半端なものとなっていました。

ということで、Sunが自社ブランドのデータベースを持つというのは必然的な流れとも言えます。

ただし、現実の道はそんなに簡単ではないでしょう。具体的なDBMS製品の計画については、Sunは完全ノーコメントなんですが、選択肢としては以下が考えられるでしょう。

0)独自DBMSを一から開発
 まあ、これは開発労力から考えてあり得ないと言ってよいでしょう

1)オープンソースDBMSの活用
 MySQLもPostgreSQLもまだまだエンタープライズ系にはしんどいと思っているので、結構な付加開発が必要でしょう。ただ、SAPはMySQLをベースにSAP専用DBMSを作ろうとしてます(MaxDB、旧称SAP DB)からこの流れに乗るのはありかもしれないですね。

2)SybaseからDBMSをOEM
 まあ、妥当なところかもしれません。

3)Sybase DBMS製品のみを買収
 Sybase的にはあまり魅力がないでしょうね。

3)Sybaseの企業買収
 Sunの財務体力的に大丈夫なのかと言う点と他のソフトウェア製品の重複が著しいのでちょっと厳しいか。

4)InformixをIBMから買収
 実現したらおもしろそうですが、まあ、これはないでしょうね。

5)Symfowareを富士通からOEM
 個人的にはこれがSunにとって理想的かと思ってます。SymfowareのSPARC/Solaris上のスケーラビリティは実証されてますし。富士通も自社DBMSをSunが米国で売ってくれれば市場が一気に拡大します。
 ただ、ハードもDBMSも富士通からOEMでは、Sunエンジニアからの反発が予測されますね。

以上、これはインサイダー情報なしで全くの推測で書いてみました。

追加情報(05-02-22)
トラックバック先でFirebird(Interbase)やIngressの可能性もあるのではと書かれていますが。うむ、確かにIngressは大穴かもしれないですね。

投稿者 kurikiyo : 17:58 | コメント (0)

2004年12月03日

グリッドの用語混乱はちょっとはましになったか

新しい概念が世の中に出てきた当初におこる現象のひとつに
用語の混乱があります。

特に、「グリッド」という言葉の混乱状態は著しいものがあります。

元々の「グリッド」の定義(アカデミアにおける定義)は、「複数の
組織をまたがって単一の問題を解決するための、コンピューティング
資源共用基盤」というようなものだったと思いますが、オラクルが
Oracle 10gにおいて、従来はRAC(リアルアプリケーションクラスタ)
と呼んでいたテクノロジーを「グリッド」と呼び始めたため、
「並列処理をしてれば何でもグリッドかい」という状況になってしまいました。
いわゆる希釈化(ダイリューション)という現象ですね。

で、サンもSolarisのコンテナ機能(1台のサーバをソフト的に分割し、
複数のOSを稼動する機能、要するにVM(バーチャルマシン))を、
N1 Grid Containerと呼んでいました。

「コンテナはいわば"Grid in a Box"だ」というのがその理由だったと思いますが、
「ちょっといくらなんでも無理があるのでは」と思っていました。

が、結局、Solaris 10の発表と同時に、Solaris Containerという真っ当なな名前
に変更したようです。

とは言え、グリッドに関する用語の混乱はまだまだ続きそうです。
グリッドについて議論する時はまず最初に「ここで『グリッド』はこういう意味で
使っています」と定義をしてから議論することをお勧めします。そうしないと
いつまでたっても議論が収束しないリスクがあるでしょう。

投稿者 kurikiyo : 09:59 | コメント (0)