2000年から続いている「どこよりも遅く、限りなく個人的な」シリーズをご存知ですか？

[Masazumi_Koga]

日本のHPEのLinux技術者が、2000年からWebサイトでお届けしている「どこよりも遅く、限りなく個人的な」シリーズ。知る人ぞ知るオープンソース界隈のコアな技術者の間では、結構有名なシリーズです。HPEは、日本においてオープンソースLinuxのWebサイトを1999年から開始しており、様々な隠れサイト（？）も存在します。その中でも、海外のオープンソース・Linux情報を知ることができる「どこよりも遅く、限りなく個人的な」シリーズは、パートナー企業やエンドユーザー様のコアな技術者の方々に知られており、お客様から「御社の『どこよりも遅く、限りなく個人的な』シリーズ、読んでます」と声をかけていただくこともたびたびあります。そこで、今回は、2000年から続くこの「どこよりも遅く、限りなく個人的な」シリーズの2000年に公開されたレポートをもとに、当時のITを振り返ることにしました。2000年当時の情報と2016年のオープンソース・Linux事情を比べると、新しい洞察が得られる（？）かもしれません。

どこよりも遅く、限りなく個人的なLinuxWorld Conference and Expoレポート：
http://h50146.www5.hp.com/products/software/oe/linux/mainstream/support/may/lwce00/index.html

上記URLの記事は、西暦2000年、弊社の本社ビルがまだ東京の天王洲アイルにあった頃に公開されたものです。この当時のイベントでは、現在当たり前のSCSI（スカジー）、ファイバーチャネルの機器などが展示されていました。そしてなんといっても、Alpha/Linux（アルファ・リナックス）です。 AlphaServer（アルファ・サーバー）という非Intelチップ搭載のUNIXサーバーをご存知ですか？旧DEC（現HPE）が誇る非Intelの64ビット高速CPUだった「Alphaプロセッサ」を搭載したマシンで、Digital UNIX（後のTru64 UNIX）が稼働したマシンです。そんな非IntelチップのUNIXマシン上でLinuxを高速計算のために動かすという、2000年当時というか、なぜか今でも前衛的に感じる展示がありました。

この頃のAlpha CPU搭載マシン、とくにAlphaServer ES40という4ソケットマシンが科学技術計算などを行う開発・研究機関のお客様に大変ご好評だったのですが、超高速処理のUNIXマシンをどのようにお客様にご紹介していたかというと、古賀は、KAP Fortran（カップフォートラン）というUNIXで動くSMPマシンのスレッド並列処理の高速化ソフトをご紹介していました。図は、古賀が新卒入社1年目のときにKAP Fortranのデモ付き演習の講習会講師をつとめたときの資料の1ページです。マルチスレッドで高速化できるというならば、普通のソフトウェアのご紹介になりますが、そのKAP Fortranは、なんと、１コア用に作った自作プログラムをロードすると、マルチスレッド化した実行ファイルだけでなく、ソースコードも自動生成することができるのです。このマルチスレッド化したソースコードの生成能力は、お客様にご好評頂き、そのソースコードの生成方法や実行方法のノウハウなどをご紹介していました。マルチスレッドのソースコードというと、あまりピンとこないかもしれませんが、スーパーコンピューターの世界では、「OpenMP」とよばれる複数のCPUコアを使うための記述（OpenMPディレクティブといいます）をソースコードに埋め込むことで、ループ処理などをマルチスレッド処理、すなわち、複数のCPUコアに分担して処理してくれるのです。このOpenMPは、スーパーコンピューターの世界では、現在でも利用されていますが、2000年当時のユーザーの皆さんも、どうにかOpenMPで効率良く計算させたい、OpenMP対応のソースコードを書きたいというニーズがありました。この頃、OpenMPは、LinuxもUNIXも両方対応していたのですが、KAP Fortranによるソースコードの生成機能は、Linuxに非対応で、UNIXのみが対応していたというのが当時です。ですので、今では考えられないかもしれませんが、2000年当時、スーパーコンピューターを使うユーザ（開発者）の世界において、「Linux」は、まだ「新参者」だったのです。

ちなみに、古賀は、2000年入社当時、名古屋のプリセールスのSEに配属だったのですが、「古賀は、学生のときからLinuxとDEC Alphaを触っていた人」ということで、まだ新卒入社まもないSEの「ひよこ」なのに、なぜか、お客様先に設置したAlphaマシンにLinuxをインストールしたりUNIXを設定したりと、高速計算機用に環境を作る構築業務（デリバリー）と並列計算機やスーパーコンピューターのプログラミングの講習会の講師をやっていたことがあります。名古屋地域だけでなく、金沢や富山のお客様にも出張デリバリー＆講習会をやっていました。お客様にプレゼンして、構築（デリバリー）して、ホテルで一泊して、お客様向けに高速マシンの使い方＋スーパーコンピューター用のプログラミング講習会も朝9時半から夕方16時半まで一人で講師をやるというAlphaマシン + UNIX/Linux三昧だった若き新卒SEの時代を思い出します。

2000年から16年の歴史を持つ管理ソフトがHPEにはある！

この「どこよりも遅く、限りなく個人的な」サイトのとおり、2000年当時は、業務用Alpha 64ビットマシンのCPUが600Mhz、メモリが1GB、IA-64プロセッサ（x86_64ではありません）の試作機では4GBメモリを突破！という感じでしたので、サーバーマシンのメモリは、PC（当時のノートPCはメモリが128MB～320MB程度）に比べ、非常に巨大に感じた記憶があります。この当時は、一般的な汎用の高速計算サーバーといえば、4ソケットCPUのSMPマシンが主流でした。4ソケットというと現在では、非常に少ないように思えますが、当時としてはかなり強力なマシンです。筐体の大きさは、いまでいうミニ冷蔵庫ぐらいです。これをずらずらと並べて、一つのクラスターとして稼働させてスーパーコンピューターにしたてあげるのが当時でした。

この頃から、日本でも高速計算用のSMPマシンと、スーパーコンピューターと同じように高速計算用途として、1Uサーバーや2Uサーバーを大量に並べてクラスター化する並列計算マシンがお客様の中で混在して利用し始める頃です。この並列計算マシンは、当時、Beowulf（ベオウルフ）クラスターと呼ばれていました。古賀も当時は、単語の響きがかっこいいので、やたらと「ベオウルフ、ベオウルフ」と声に出していましたが、今からすると、なんてことない単なる高速計算を行うための計算ライブラリと実行環境がインストールされた並列計算機です。が、当時としては、並列計算機の運用管理は、今でもそうですが、かなり煩雑になりやすく、旧DEC（現HPE）としては、CMU（Cluster Management Utility、通称シーエムユー）という複数ノードの一斉管理ツールを出していました。このCMUは、もともと非IntelチップであるAlpha 64ビットCPUを搭載したサーバーで並列計算機（スーパーコンピューター）を利用する高速並列計算ユーザー向けに提供されていた管理ソフトウェアなのですが、なんと2016年の今でもその管理インタフェースにおける主要な機能はほとんど変わっていません。しかも、CMUは、いまも進化しており、複数ノードの負荷状況だけでなく、過去に遡った負荷の履歴を3D表示で見ることができるようになっています（しかも実装がJavaに対応）。ちなみに、2016年現在、CMUは、HPE Insight CMU（インサイト・シーエムユー）という名前に変わり、スーパーコンピューターだけでなく、Hadoop＋Sparkのビッグデータ基盤のリファレンスアーキテクチャに管理ツールとして提供されています。CMUからInsight CMUへ。インサイト＝洞察です。16年たった2016年も、管理ツールを使った並列計算機のハードウェア監視やOS操作は全く無くなる気配がありませんが、今では、そんな並列計算機でビッグデータを処理し、洞察を得る時代になりました。次の2020年の洞察は、一体何が来るのか、楽しみです。

2000年当時、スーパーコンピューター、高速計算の世界では、非Intelチップが主流だった

このころ、IA-64（x86_64ではありません）がまだ試作機段階でしたが、スーパーコンピューターのユーザーの間では、非IntelチップであるDEC Alpha 64ビット搭載のマシンとIntel 32ビットCPUを搭載したProLiantサーバーG1世代が恐る恐る共存し始めることです。「恐る恐る」と表現したのには理由があります。スーパーコンピューター利用において、当時は、非Intelチップのマシンが主流であり、Intel 32ビットCPUマシンを使った並列計算機は、まだまだこれからという感じだったので、企業におけるR&D部門のスーパーコンピューターのユーザー側も恐る恐るテスト的に入れていたというのが当時の状況だったのです。

実は、2000年当時の非Intel系の高クロックのAlpha 64ビットCPUは、発熱がものすごく、Alpha CPU搭載の「AlphaServer DS10L」という高さ1Uのラックマウント型サーバー（写真）があったのですが、これをラックに密着させて設置すると、「CPUの熱で危険」という時代でした。実は空調、風の流れがキチンと計算されたデータセンターに設置しないといけなかったのです。当時は、そんなデータセンターでも冷房をMAXにしないとい けない状態でしたので、あのころから「マシンルーム　＝　寒い　＝　徹夜のときはダンボールを体に巻いて寝る」というスタイルが確立されたのは、 Alpha 64ビットCPUのおかげなのではないのかと思った次第です。2000年初頭当時は、「コン ピューターを知る　＝　プログラミングができる、ソフトがインストールできる」、ではなくて、「コンピューターを知る　＝　熱、電力、部屋の寒さと戦う」というのが当時の筆者なりの「IT」だったような気もします。

このように、当時は、環境によっては、1Uサーバーなのにラックに高密度に実装できないというお粗末なこともありましたが、そのころから、Intelチップを搭載した1Uサーバー、2Uサーバーが科学技術計算用途でも大量に導入されはじめます。ただし、当時のIntel CPUは、32ビットが主流でしたので、大容量メモリに対応したLinuxカーネルやシェル環境、ミドルウェア環境があまり整備されておらず、科学技術計算用途では、いろいろと苦労することがあったのも事実です。ちなみに、筆者が遭遇した当時の32ビット問題は、tcshというシェルのソフトウェアが、内部的にデータの取り扱いの上限が32ビットだったため、科学技術計算用途で利用していたお客様の4GBを超えるデータを取り扱えないという問題に遭遇したことがありました。そんな、「非Intel CPUは熱で危ない問題」「Intel CPUは、どこかに32ビットの罠がある」という時代も、今ではx86_64のLinux環境で、何も問題なく4GBを超えています。今では、ディスクパーティションを作成するfdiskコマンドが、2TBを超えられないという問題ぐらいでしょうか。筆者の世代は、Linuxのディスクパーティショニングツールというと「fdisk」なのですが、これも今では、partedというコマンドによって2TBを超えてパーティションを作成できるようになっています。

iPAQ（アイパック）という「西暦2000年のスマホ」
古賀個人として、非常に気になっていたのが、西暦2000年のスマホとも言うべき、「iPAQ」です。この頃から、弊社は、このスマホのような携帯型マシンにLinuxを入れようと格闘（？）していたのです。今では、Linuxが搭載されている携帯電話を「アンドロイド携帯」などと呼ばれますが、当時は、「Linuxが搭載された携帯電話」にスポットは当たっておらず、「携帯型のインターネット端末機をいかにしてLinuxで実現できるか」が勝負だったのです。その当時の携帯電話は、いまの安価な電卓のような液晶表示で、漢字など当然表示できず、カタカナ表示が精一杯のような感じでしたので、携帯電話よりも、インターネットが使える手の中に納まる携帯型のパソコンが重要だったのです。デスクトップのGUIが稼働し、アイコンがずらっと並ぶLinux OS環境が手の中に納まる携帯端末で動けば、それはもう、今で言うスマートウォッチを両腕に装着して闊歩するぐらいのレベルで自慢できる状態だったのです。この「自慢」というのは、当時、携帯型端末に限らず、オープンソース・Linux系のイベントでは非常に重要なファクターで、ハードもソフトもかなり前衛的なデモ展示が多く行われていました。非常に「ものめずらしいハードやソフト」の展示が多かったため、自慢大会みたいな雰囲気をかもし出していたのが当時のオープンソース・Linuxのイベントだったのです。筆者も2016年現在、オープンソースのコミュニティのイベントに出展することがあるのですが、2000年当時の前衛的なオープンソースイベントの雰囲気を忘れないよう、近未来型のITでワクワクできる展示を目指そうと常に心に刻んでいます。

 以上で、2000年当時に弊社のLinux技術情報サイトに公開された「どこよりも遅く、限りなく個人的な
LinuxWorld Conference and Expoレポート」の話題を元に、当時を振り返りました。またいつか、2000年以降の「どこよりも遅く、限りなく個人的なレポート」を振り返りたいと思います。

Masazumi Koga (Twitter: @masazumi_koga)