IBM i の35年：懐かしい思い出を辿る
このIBMミッドレンジ プラットフォームが今年で35年目を迎えようとしていることは、お聞き及びかもしれません。IBMでは、その節目を祝って数多くのイベントを予定しており、6月21日の盛大な誕生日パーティーで、クライマックスを迎えます。今週、デンバーで開催されているPOWERUpカンファレンスでは、IBMのエグゼクティブたちが、来たるべき祝宴について少し触れるとともに、このプラットフォームがここへ辿り着くまでの足跡について、技術的な面から振り返りを行っています。
1988年のAS/400の製品発表の日は、いくつかの理由で注目に値する日でした。IBM i CTOのSteve Will氏は、その時の非常にワクワクした雰囲気を思い起こします。IBMでの彼の傑出したエンジニアとしてのキャリアは、その頃はまだ始まったばかりでした。
「製品発表イベントには、TVドラマ『M*A*S*H』に出演していた俳優が何人か呼ばれていました」と、 COMMON POWERUp 2023カンファレンスでの月曜日の基調講演、「IBM i @ 35」でWill氏は述べています。「ずいぶん昔のことですが、楽しい1日でした。ただ、それまでの私の人生で1番というくらい暑い日だったことを憶えています。まるで近くに火山でもあるのかというほどでした。」
AS/400と呼ばれたこの新製品のTV広告に起用された関係で、強烈に暑い日となった1988年の夏至の日、俳優のアラン・アルダ（Alan Alda）はその場に居合わせることとなりました。ミネソタ州ロチェスターのIBMラボ屋外のイベント会場は、どれほど暑かったことでしょうか。
「アスファルト舗装の上は強烈な暑さでした」と、IBM iプロダクト マネージャーのAlison Butterill氏は述べています。「暑さのあまり、金属脚の椅子がアスファルトにめり込もうとしていたほどです。時折、椅子や脚が沈み込んでコケそうになる人もいたようです」 その日、アスファルトの悲運に見舞われたハリウッド俳優がいたかどうかは分かりませんが。
AS/400は即座に大成功を収めました。すぐに、大きな白いボックスはロチェスターの組立てラインから飛ぶように出荷されて行きました。AS/400の需要は、あのロチェスターの製品発表日と同じくらいの熱気を帯びていました。企業は、S/36やS/38から、ビジネス コンピューティングにおける次なる目玉へと、すぐにでも乗り換えたかったようです。
製品発表後すぐにAS/400を発注する企業が多かったため、新しいサーバーの納入がちょうど同じ時期になることが多かったようです。「納入されたAS/400が初回出荷品だったと言う人に何人会ったか知れません」とWill氏は述べています。「初回出荷品のAS/400を使っていたと言う人は、この聴衆の中に10人はいるでしょう。しかし、そうした話を聞くのは私も嫌いではありません。」
逸話はたくさんあります。IBMの異才のマーケター、Malcolm Haines氏は 20年ほど前に 、彼の「iSeries.mySeries」キャンペーンの一環で、そうした逸話のいくつかを記録に収めています。中には、キャンペーンと連動していたHaines氏の「Legends of iSeries（iSeriesの伝説）」動画シリーズに取り上げられ、都市伝説の雰囲気を帯びるものもありました。それらは「iSeries Nation」Webサイトにしばらく残されることになります（「iSeries Nation」サイトを覚えている方はいないでしょうか）。Will氏とButterill氏は、月曜日の基調講演の中で、そうした動画の1つを紹介しています。それは、2年間、室温60℃の小部屋に閉じ込められていても、稼働し続けているサーバーの動画でした。もしかすると、6月21日が近付いたら、さらに多くの動画が公開されるかもしれません。
しかし、AS/400から今日の最新のIBM iサーバーへの進化の過程は、楽しいことばかりではありませんでした。単一レベル記憶、オブジェクト指向アーキテクチャー、およびTIMI（Technology Independent Machine Interface）といった機能のおかげで、AS/400は当時としては先進的なものでしたが、IBM iは、AS/400の開発者たちの当初のビジョンをはるかに超える形に進化を遂げています。このマシンが35年という年月を掛けて進化してきた間には、ロチェスターの開発スタッフにとってストレスの溜まる瞬間もあったはずです。そしておそらくは、いくばくかの不安も抱えたことでしょう。
たとえば、初期のAS/400は、48ビットCISC（Complex Instruction Set Computing: 複雑命令セットコンピューティング）プロセッサーを搭載していました。しかし、IBMロチェスターは、CISCチップが引き起こすさらなる複雑性から一刻も早く逃れたいと思っていたとWill氏は述べています。
「私たちは、RISC（Reduced Instruction Set Computing: 縮小命令セット コンピューティング）プラットフォームへ移行する必要がありました」と彼は述べます。「しかしそれは、マシン インターフェースの下にあるコードはどれも、まったく役に立たなくなることを意味しました。移行を行うためには、それまでそこにあったすべてのものを書き直さなければなりません。」
IBMは、TIMIの下にあるすべてのものを取り払って書き直す必要がありました。当時（1990年頃）は、さらに厄介なことに、AS/400内部には垂直マシン コードと水平マシン コードがありました。結局のところ、マシン コードは劇的に単純化され、もはや垂直コードも水平コードもなくなりましたが、それは簡単な作業ではなかったようです。
「何百人ものスタッフが、長期間、ほぼ週7日ほぼ24時間ぶっ通しで作業していました。新リリースが世に出て、それが役に立ってくれることを願ってのことです」とWill氏は述べます。「それは過酷な日々でした。ようやく作業が完了し、次に進めるとなったときには、皆、大喜びでした。」
顧客からアプリケーション コードに関する問題の報告もありましたが、64ビットRISCプロセッサーへのマイグレーションは、想定通りに円滑に行われ、顧客のコードの大半は、それ以前と同じように稼働し続けました。「覚えておいていただきたいのは、実際に私たちを守ってくれていたのはこのアーキテクチャーだったのであり、そのおかげで技術を前進させることができたということです」とWill氏は述べています。
最初の10年が終わりを迎えた頃、このマシンの進化におけるもうひとつの大きな転機が訪れます。IBMは、OS/400 V4R4の発表とともに、PASE（Portable Application Solutions Environment: ポータブル アプリケーション ソリューション環境）を発表します。これにより、AS/400はAIXワークロードを稼働できるようになりました。PASEの導入は、IBM iの進化における1つの節目となったとWill氏は述べています。
「今日、私たちは実に様々なことを行えるようになっており、また、進化してきた結果として今ある姿になっているわけですが、そうした現状があるのは、マシン インターフェースへとコンパイルされるILEベースのものと、AIXに似た環境で同じプロセッサーで同じコントロールで稼働するものとを結び付けることができたからに他ならないのです」と彼は述べます。「それは極めて重要です。たとえば、SAP顧客がすべてそうした環境で稼働しているとしましょう。SAP顧客が1,000社ともなると、やはり非常に重要になります。」
IBM iサーバーは、統合されたDb2データベースがあることで知られています。しかし、ほとんどのIBMミッドレンジ顧客は、長い間、そのデータベースを最大限に活用することをしてきませんでしたし、リレーショナル データベースと最も関連の深い言語であるSQLを使用することもしてきませんでした。そのような状況が変わり始めたのは15年ほど前、現在、IBM i開発担当ディレクターを務めるDave Nelson氏が、SQLへの移行について本腰を入れるようになってからのことでした。
「初期のデータベースの内部は、いわば単純なエンジンのような作りでした」と、クラシック クエリー エンジン（CQE: Classic Query Engine）についてWill氏は述べています。「質問を尋ねれば、答えを返してくれました。複雑な質問は無理でしたし、答えが出るまでにしばらく時間は掛かりました。」
顧客がこのIBMミッドレンジ プラットフォームにより多くのデータを保管するようになり、より複雑な質問を尋ねるようになると、ほどなくロチェスターの開発リーダーたちも、CQEでは満足な結果が得られないことに気付くようになります。
「私たちは、徹底的に作り直すつもりでした」と、2005年の秋に、今で言うIBM iアーキテクトの職に就任したWill氏は述べています。「そうした経緯で、新たな照会エンジン、SQL Query Engine（SQE）を開発するに至ったということです。」
新SQEと呼ばれた新たな照会エンジンは、CQEが直接DDSエントリーの上で処理を行うのとは異なり、SQL表の上でSQL照会を実行しました。Will氏によれば、SQEを、今のような、まるでスポーツカーのように高速なものへと進化させるのにはかなり手間が掛かりましたし、それを使ってもらうようにするのは、簡単なことではなかったようです。
「このSQL Query Engineを、市場に出ている他のどのデータベースとも張り合えるような、可能な限り最善のものにするためには、リリースに次ぐリリースに次ぐリリースが必要でした」と彼は述べています。「にもかかわらず、クラシックな照会エンジンを完全になくしてしまうことは、まだできませんでした。スポーツカーよりも、クラシックカーの方がうまく処理できる照会がまだあるからです。」
同じように、マルチスレッド化の導入も、過去のAS/400の方式との決別と、明るく輝かしい（そして高速な）未来への旅立ちを示すものとなりました。
「長い年月の間に、業界全体が変貌を遂げました」とWill氏は述べています。「S/38やAS/400を開発していた時代には、アプリケーションをスレッド化するという概念はありませんでした。しかし、業界の他の企業は、プロセッサーがあまり多くの処理を行えない問題に対処する必要があったため、アプリケーションを実行する方式としてスレッド化に取り組み始めました。スレッド化は、様々なスタイルのアプリケーションにとって本当は行った方が良いことだったのです。そして私たちは、しばらくはそれを避け、しばらくは抵抗していましたが、最終的には、有能かつ強力なマルチスレッド化環境によって、問題を解決する必要がありました。」
Lotus Notesが、AS/400におけるマルチスレッド化のためのテストベッドの役割を果たしました。Lotus Notesが非常に効果的に機能したため、IBMは長年にわたってAS/400でそのメール システム全体を稼働していました。そして、インターネット革命が起こると、マルチスレッド化に対する投資が本当に報われるようになります。
「Lotus Notesのような、マルチスレッド化されたアプリケーションを稼働し始めようとしていたため、Web経由で入って来るマルチスレッド アプリケーションを処理できるようになっていました」とWill氏は述べています。
Webは、このアーキテクチャーの単一レベル記憶環境の進化における大きな節目となりました。単一レベル記憶は、革新的であり、従来のビジネス アプリケーションにとって有益でしたが、Webサーバーを通り抜けるデータに対してパフォーマンス上の余分な負荷を掛けていました。IBMは、システムの他の部分を犠牲にすることなく、そうしたパフォーマンス ヒットに対処する必要があることは承知していました。
「そこで、並列記憶モデル（テラスペース（Teraspace）と呼ばれました）を開発することが必要になりました。テラスペースによって、同じようなポインター長を使用するが、まったく異なるアドレス空間になることが可能になりました」とWill氏は述べています。「そのため、アーキテクチャーを変更して、単一レベル記憶になるというだけではなく、こうした単一レベル記憶とテラスペースの組み合わせにもなるようにする必要がありました。」
Will氏がチーフ アーキテクトの職に就任したのは、 2008年4月のiSeriesとpSeriesとの統合（このことから、IBM iとAIXがPowerで稼働することになります）の直前のことでした。ナッシュビルのCOMMONの聴衆に向けて重大発表を行う任務を任せられたとき、彼はまだ、なりたてほやほやの新米チーフ アーキテクトだったわけです。
「私がプラットフォームの統合を決定したわけではありませんでしたし、このプラットフォームを「i」と命名したことにも、もちろん関わっていませんでした」と彼は述べています。「しかし、皆の前に立って、「このプラットフォームの名前は「IBM i」です」と発表しなければなりませんでした。はっきりと覚えています。非常に光栄でした。」
次の大きな節目となったのは、2010年4月の IBM i 7.1の発表 でした。このリリースが重要であるのには、いくつか理由があります。まずは、今日に至るまで続いている、IBMのテクノロジー リフレッシュ（TR）が始まったことです。次いで、2つの異なるIBM iオペレーティング システムが同じマシンに共存できるようになったのはこれが初めてでした。
「リリースからリリースへのアップグレードのような基本的な操作のやり方が劇的に変わりました」とButterill氏は述べています。「新しいリリース（たとえば7.1）で新たな区画を起動しても、それまで業務を稼働し続けていた6.1リリースはまだホスティングされます。」
最後に、IBM i 7.1では、フリーフォームRPGがリリースされています。フリーフォームRPGは、その言語をモダナイズするとともに、新たな開発者にとってその言語をより魅力的なものにする一助となっています。また、フリーフォームRPGのリリースは、IBMがそれを実装する決断に至った経緯からも重要です。IBMは、COMMON Americas、COMMON Europe、Large User Group、ISVアドバイザリー カウンシル、およびパートナー グループなど、様々なアドバイザリー カウンシルに信頼を置いていました。ところが、最も重要な新機能とされていたものについて、彼らから同意を得ることができませんでした。しかし、7.1で、フリーフォームRPGは重要だということで最終的に合意が得られることとなり、IBMは堂々とすぐにそれを実装したということです。
「アドバイザリー カウンシルに、これを最優先にするよう迫ったわけではありません」とWill氏は述べています。「しかし、それが最重要事項だと最終的に彼らが判断してくれたとき、私たちが大喜びしたのは確かです。ご承知の通り、私たちがこの10～15年を掛けて取り組んできたことのほとんどは、オープン性（openness）への対応です。他の経歴を持つ人をIBM iに連れて来ることができるということが、このプラットフォームの将来にとって絶対的に極めて重要なのです。」
このプラットフォームの進歩における重大な出来事として、Will氏とButterill氏が基調講演で最後に取り上げたものがあります。IBM iの1番の大口顧客が長年にわたって求めてきた要件は、ダウンタイムなしでアップグレードできるということでした。しかし、そうした要件を満たすのに必要となるタイプのクラスタリングは、IBM iの単一レベル記憶アーキテクチャーの存在によって、実装が困難になっていました。
「それは、対処する方法が見つかるとは思えなかった要件でした」とWill氏は述べています。「しかし、継続的可用性を確保する術がないのなら、金融機関の看板を下ろさざるを得ないと、実に多くの金融機関からその要件の充足を求める声が上がります。銀行向けソリューションの中核を担い続けたいなら、継続的可用性を確保する術を見つけるしかありません。」
ロチェスターのブレーンたちが集まって、単一レベル記憶の指針に反することなく、その要件を満たすことができる解決策を模索しました。それは、数十年間、ロチェスターの最高の頭脳を悩ませてきた難問だったとWill氏は述べています。
「しかし、長年にわたりこのプラットフォームのデータベース アーキテクトを務めているMark Anderson氏やKris Whitney氏を始めとする、頭の切れるメンバーたちから成るチームが、これを実現する方法を見つけてくれたため、私たちは面目を保つことができただけでなく、検討していた案件にも柔軟かつ迅速に取り組むことができるようになりました」とWill氏は述べています。それがDb2 Mirrorです。これはIBM i 7.4で提供されました。
CISCからRISCへの移行、SQEやマルチスレッド化の導入、プラットフォームの統合、フリーフォームRPG、Db2 Mirror。これらの変化はすべて、ルーツから離れることなく、どのようにしてこのプラットフォームが技術的に前進してきたのかを示す良い実例です。
「このプラットフォームは、昔と比べてはるかに複雑になっています」とWill氏は述べます。「同じアーキテクチャーであって、同じアーキテクチャーではありません。中心にある考え方は同じです。つまり、私たちが常に持ち続けてきた多くの基本原理は同じなのです。」
