IBM i のウンチクを語ろう
～ その77：IBM i の発展はIntegration（統合）の歴史
皆さん、こんにちは。IBM i の「i」は統合を意味する「Integration」の頭文字であることは多くの方がご存知のことと思います。従来からオールインワン（All in One）という言葉で表現されている製品の特性であり、このブログでも第5回目にテーマとして取り上げています。「オールインワン」という言葉自体は実際にはIBM i の「専売特許」ではないけれども、他社製品のそれとは意味するところが実際には違っている、という点を説明いたしました。IBM i の場合は設計・開発段階から統合が意識されているのに対して、他の場合は個別の製品を最終段階で統合している、という違いです。今回はその「統合」をかつてのAS/400登場期の頃から、歴史的に捉えてみようという試みです。
おおよそ現代に連なるコンピュータと呼ばれる機器が登場したのは1940年代とされています。市場規模が急拡大する時期においては製品バリエーションが拡大し、落ち着く頃になるとサバイバル・ゲームさながらに統合・縮小される、というサイクルを繰り返してきました。このことはコンピュータに限らず、規模の大小の違いこそあれ、あらゆる製品について言えるのではないかと思います。
IBM一社のみを取り上げても、拡大した製品全ラインアップを統合しようという野心的なプロジェクトが1970年代初頭にあり、その後は中小規模のシステムだけでも統合しようという再度の試みがあったと、AS/400産みの親とされるF.Soltis博士はその著書「Fortress Rochester」の中で述べています。動機は製品、特にマイクロコードやオペレーティング・システムなど、プログラミング関連コストの削減です。IBM一社とは言え、それぞれの開発部門がそれぞれの狙いをもって開発したシステムですので、アーキテクチャに互換性はありません。複数の国、複数の開発部門をまたがったプロジェクトは困難を極め、日の目を見ることはありませんでした。そして三度目の正直さながらに、IBMロチェスターが維持していた二つのラインアップ、すなわちSystem38とSystem36の統合プロジェクトが1988年にAS/400に結実した、というわけです。もう少し正確に表現するならば、より大きなアーキテクチャを持つSystem38の中に、比較的小振りなSystem36環境を埋め込むことで作り上げられたシステムがAS/400です。
AS/400は基幹業務アプリケーション用マシン、今の言葉で表現するならばレガシー・システムであったわけですが、1990年代以降になるとクライアント・サーバーという新たなコンピューティング・モデルが市場に浸透します。当初はUNIX、その後Windowsも包含するように膨張しつつあったオープン・システムがブームの中核にあり、AS/400はそこにどのように関わるのかが課題になります。エミュレータとホストという関係で成り立っていた企業用システムに対して、新たなシステムは全く異質でありながら低価格とオープン性を武器に市場のシェアを伸ばします。旧来ホストに取って代わろうという動きには対抗したいところですが、GUIなど新たなメリットをユーザーにもたらす点はうまく活用したいものです。AS/400にとってのオープン・システムには、競合と共存の両側面があるというわけです。
AS/400におけるオープン性の統合は、このようなオープン・システムとの共存の必要性から実現されました。内部の実装方法は独自アーキテクチャに基づくものであったとしても、オープン・システムが標準的に備えるインターフェースを同様に利用可能にする必要があります。それまで独立したソフトウェア製品だったTCP/IPが高速化のために全面的に書き換えられると共に、OSの標準機能として組み入れられるようになります。それまでのIBMのネットワークは、独自のSNAと呼ばれる体系が主力であって、TCP/IPはオプションの位置付けにありました。Windowsクライアントからデータベースにアクセスするための標準的なインターフェースであるODBCも、Db2 for i 向けに追加されました。また、複数のクライアント端末に対するファイル・サーバー、プリント・サーバーとして機能するためには、互換性あるファイルシステムをサポートしなければなりません。現在IFS（Integrated File System : 統合ファイルシステム）と呼ばれる機能は、この頃に実装されました。
オープンなインターフェースの統合は、AS/400の生き残りにおいて決定的に重要でした。当時の日本の市場において、IBMは二大オフコン・メーカーの後塵を拝する立場からなかなか抜け出すことができずにおりましたが、オープン性の実装のスピード感に違いがあったために、徐々に様相が変わってゆきます。オープン・システムのカテゴリには属さないことから、オフコン全般に対する逆風は相変わらずであり、否定的な印象も芽生えつつあったのは事実でしょう。一方AS/400コミュニティの間では、オープン性の実装は歓迎するべきことでした。市場における印象・評価と、実際の機能との間に乖離が生じ始めたのはこの頃であり、残念ながらそれは今日に至っても解決できておりません。私自身もあらゆる機会を捉えてIBM i のオープン性を訴求しているつもりではあるのですが、感情の要素が色濃く反映される世間の印象を覆すには、力量不足を感じます。
新機能の実装において柔軟性・迅速性を保てたのは、TIMI（Technology Independent Machine Interface）と呼ばれる独自の仮想マシンのお陰だと考えています。ソフトウェア的に定義されているマシンですから、ハードウェアの増強を伴わなくても、如何様にも機能を追加・改善できます。例えばアプリケーションとしてインストールするのではなく、最初からデータベース機能を備えたマシンに仕立て上げることもできるわけです。各種のミドルウェア的な機能も統合されていることから、AS/400登場間もない頃は、マイクロコードを含んだOSのサイズが大き過ぎるというクレームがお客様から寄せられたこともあります。開発部門にスリム化してもらえないかと要望を投げ掛けたこともあるのですが、統合という製品ポリシーに反しているためか、検討してもらえることはありませんでした。
2000年が近づく頃になると、IBM i のオープン性を追加実装するにも更なるスピード感が求められるようになります。インターネットの時代が到来し、ビジネスシーンにおいても、Apache HTTPサーバーやJava言語が利用されるケースが徐々に増えてきます。当然のことながら、それらのバージョンも随時アップグレードされますので、追随しなければなりません。オープンなインターフェースを備えるけれども内部実装は独自、という従来の方法に頼るだけでは、開発部門における負荷は大きくなる一方です。オープン・システム用の基幹業務パッケージを、そのままAS/400上で稼働させたいという市場の要求もありました。そこでIBMのUNIXであるAIX用のアプリケーションをIBM i 上で直接稼働させるための仕組み、PASE（Portable Application Solution Environment）のサポートが始まります。IBM i とAIXが前提とするPowerプロセッサは共通ですが、ファイルシステムは異なります。そこでIBM i が備える単一レベル記憶の広大な仮想記憶域の一部に、AIX用の「区画」を設けます。すなわちPASEは単一レベル記憶の上にあるAIXバイナリ実行環境、というちょっと風変わりな代物です。
例えば最新のIBM i 7.5におけるPASEはAIX 7.2 TL5、IBM i 7.4のそれはAIX 7.2 TL2に相当するアプリケーション実行環境です。念のためですがPASEはAIX用のシェル、ライブラリ、ユーティリティを備え、AIXバイナリを実行できますが、カーネルは別物ですのでAIXそのものではありません。
PASEの役割は実装当初から大きく拡大されています。当初はパッケージ・ベンダーやユーザーが持つAIXアプリケーションを移行するための環境、といった利用方法が目立ちましたが、製品側が積極的に活用するようになってきたようです。例えばIBM i 独自に実装されていたJVMは、AIX版と同じバイナリ・コードがPASE上で稼働するように変更されました。そして2000年代半ばを過ぎる頃になると、数多くのオープンソース製品がPASE上で続々と利用可能になります。先駆けとなったのは2006年のPHP、その後Node.js、Ruby、R、Pythonなどのスクリプト言語群、さらにC言語コンパイラのgcc、軽量HTTPサーバーのnginxなど、インストール可能なモジュールを数えてみると今では500を超えています。これだけ増えてくるとモジュールやその依存関係を手作業で管理できなくなるので、やはりオープンソースのyumが用意されています。
ここまではIBM i 一台で実現される統合がテーマでしたが、DXの時代になるとクラウド・サービスの統合も視野に入れなければなりません。全てを自社で賄うのではなく、適宜外部のサービスを利用する、または自社のアプリケーションをサービスとして外部に公開する必要があります。業務変革を進めるために、新たな機能をより一層迅速に実装しようという取り組みだとも言えます。旧来の自社内にある、いわゆるオンプレミスにあるシステムは、クラウドと統合されることでハイブリッドなシステムへと変貌します。インターネットの向こうにあるアプリケーションとの統合という新たな要件に対して、業界標準のインターフェースとしてRESTが利用されます。前回コラムでも述べたように、IBM i がRESTをサポートするようになったのはバージョン7.1においてであり、現在においてもDX推進の要となっています。RESTのままでは使い辛いと感じられるお客様に向けては、ベル・データはサービス・ソリューションをもってDX推進をサポートしています。
今回はIBM i の統合の歴史をごく簡単に見てまいりました。二つのシステムの統合によって誕生し、その後オープン・システムと共存するためのオープンなインターフェース、さらにAIXアプリケーション実行環境、DX推進に役立つクラウドの統合、と進化している様子がおわかりいただけたのではないでしょうか。製品戦略の柱の一つに据えられていることもあり、IBM i は今後も統合を軸に成長してゆくものと思います。
ではまた。
