スペシャル
「ビジネスの、ビジネスによる、ビジネスのための」コンピューター IBM iの変わらない哲学が生み出したメリットとは

2016年8月22日


img_rmerit01_02

昨今、AIやロボットのような代表的なものも含め大小新しいテクノロジーが次々と生まれ、コンピューターの世界は劇的に進化を遂げています。特に、スマートフォン革命とすら言われる、iPhoneやAndroid端末が一気に普及していった2010年以降におけるコンピューター周辺の進化は目覚ましいものがあり、人々の生活の在り方すら変えつつあります。しかし一方で、10年以上昔のアプリケーションも連綿と動き続けており、IBM iはそのプログラムを安定的に稼働させるための基盤 として、ビジネス用システムの分野でこれまで高い評価を受けてきました。
IBM iが選ばれ続けているのには大きな理由があります。1988 年にAS/400として誕生してからさらなる成長を遂げつつあるIBM i。その背景には「ビジネスのために、どうあるべきか?」という、ビジネスでの利用を一貫して考え抜いてきた「哲学」がテクノロジー要件に落とし込まれ、さらにそれがIBM iにおいて体現されています。本記事ではその「哲学」を振り返りながら4つの特徴を解説していきたいと思います。

1.【TIMI】 アプリケーション資産の継承を見据えた技術

長くビジネスを行ってきている企業のなかには、急速に進化するテクノロジーに対応すべきかどうか、ジレンマに陥っている、というケースが少なくありません。なぜなら、自社システムのテクノロジーを積極的に刷新してビジネスに活かしたい、という思いとは裏腹に、企業にとって資産であるはずのプログラムが、新しいテクノロジーに移行すると動作しない、という場合がありえるからです。

ここで注意したいのは、アプリケーション・プログラムはビジネス・プロセスを直接的に支えるものである、という点です。すでに開発し、稼働させているプログラムが新しい環境で動かないのでは、ビジネスが成り立ちません。また、ビジネスの必要性が無いにも関わらず、テクノロジーの事情からアプリケーションを作り直すというのは本末転倒です。
とはいえ、いつまでも古いシステムに依存していたのでは、新しいテクノロジーがもたらす恩恵を受けることはできません。これは競争において遅れをとることであり、ビジネスにおいては回避するべき大きなリスクだと言えます。ビジネスを支えるシステムであるためには、テクノロジーの進歩を実現しながらもアプリケーションの作り直しが不要である必要があります。

IBM iは将来的に予測が難しいテクノロジーに対し、ハイレベルなマシンインタフェース、TIMI(Technology Independent Machine Interface)を実装することでこの課題に対処しています。TIMIとはアプリケーションとテクノロジーの間に位置している仮想マシンのようなものであり、JVMを想像してみるとわかりやすいかもしれません。そのため、アプリケーションの階層とテクノロジーの階層が分離され、テクノロジーの変化の影響を受けることなくアプリケーションが利用可能となります。

RPGやCOBOLで記述されたプログラムはTIMI用にコンパイルされて中間コードが生成され(JVMのバイト・コードのようなものです)、さらにプロセッサ・テクノロジーに合わせて実行コード生成がされる、という二段階のプロセスを経て、最終的にこれらコードが一つに統合されます。このコンパイル済みモジュールを実行する際は、通常は内部の実行コードが利用されます。
互換性のないテクノロジー上では、内部の中間コードに基づいて再度新しい実行コードを生成し直し、元からあった実行コードを置き換えた後に、この生成したての実行コードに基づいた処理が行われます。JVMバイト・コードとの違いは、パフォーマンスを維持するために、プログラムを一文一文取り出しながら翻訳・実行するような、インタープリタ方式を採用していないことにあります。

これまで見てきたように、IBM iのアプリケーション資産継承性は、テクノロジーに依存した実行コードではなく、TIMI上の中間コードの上位互換性によって実現されています。そしてTIMIは常に上位互換性を保つよう注意深く設計・開発されており、その実態はソフトウェア的に作られたマシンですので、ハードウェアの制約を受けない柔軟な機能強化も可能となっています。すなわちTIMIはIBM i にとっての最も重要なシステム資産となっているわけです。

2. 【オールインワン】 必要機能をまとめて提供することで効率化を実現

多くの企業にとって、コンピューターを維持・管理することは「本業」ではありません。システム部門に何人もの人員を割き、管理体制を取らなければいけないのは、経営負担を増大させるだけであり、できれば新しいテクノロジーへの対応なども含め最小の人員で対処できることがベストと言えるでしょう。

IBM iが唱えるオールインワンは、ユーザーがシステム構築やシステム運用管理に割く作業量を最小にすることを狙いとしています。市場に目を向ければ、すぐに使えるシステムを目指した、「オールインワン」を標榜する製品はいくつか存在します。その本質は、複数のベンダーによる複数の製品・機能を、組み上げてテストを行った後にお客様に出荷することであり、言い換えるならばパッケージングです。IBM i においては、ユーザー向けにシステム資源を効率的に配分するという、オペレーティングシステムとして必要最低限の機能に加えて、データベースやセキュリティなど主要なミドルウェア機能を同時に開発し、統合テストを行った後に出荷しています。すなわち統合作業(インテグレーション)はユーザーへの出荷直前ではなく、設計・開発・製造のすべての段階にて行われているのです。

パッケージングとインテグレーションとでは、表面的には同じ「オールインワン」と表現できるのかもしれませんが、どちらがより安定したシステムをユーザーに届けることができるのかという点において、歴然とした違いがあります。パッケージングでは、各機能の開発者は誰がどのようにその機能を使うのかを意識しません。また出荷前テストにおいて、どれだけ徹底的にバグを排除できるのかという点において、システム設計・開発者としての視点は入ってきません。インテグレーションにおいてはこのような懸念が生じることはありません。

トラブル発生時に最初に取り組むべきことは問題の切り分けです。原因を特定するにあたって、複数ベンダー製品の組み合わせによる複雑なシステムでは、責任所在を明確にするのに時間を要することも多いだけでなく、悪くするとベンダー間でのたらい回しにあうことすらあり得ます。しかし、IBM iはオールインワンで提供しているため、そのような不明瞭な状態にはならず、IBMが問題個所の早期発見と解決を目指します。

またパッケージング型システムでは、構成要素である各製品のライフサイクルは同期していないと考える必要があります。そしてある製品のバージョンをアップグレードする必要が生じた時に、それが他の製品と互換性があるのか、あらためて確認しテストしなければなりません。このような作業を回避するために、ベンダーによるサポートがもはや提供されなくなったにも関わらず、古いバージョンのままシステムを利用し続けるケースも多く見られます。これはビジネス用のシステムとして、決して健全な姿ではありません。

IBM i の設計から製造に至るまでのインテグレーションによるオールインワンにおいては、ユーザーはシステムの安定性維持のために人手とコストをかけず、ビジネスに集中できる環境を享受できます。

3. 【オブジェクト指向】 誤動作の防止とセキュリティレベルを向上

ビジネスにおいては、複数のユーザーが、ひとつのシステム上にある複数のアプリケーションを同時に並行して利用します。たとえば販売管理における在庫管理というごく限定された環境を想定したとしても入庫処理、出庫処理、各種の在庫調整などさまざまなプログラムがそれぞれの業務処理を担っており、干渉してしまうことは許されません。そのため、ひとつひとつのプログラムが安定した稼働を担保することはビジネスでの利用における重要なポイントとなります。

ここでコンピュータの持つ、内部的な危うさについて考えてみたいと思います。例えば商品マスターには商品番号とか価格といったデータが含まれています。商品番号は検索したり参照したりすることはあっても、計算の対象になることはありません。一方価格は計算の対象になり得ます。我々はこのようなことを常識として理解しますが、コンピュータにはこのような常識はありません。内部のデータはすべて単なる「0」と「1」の羅列に過ぎず、命令さえ与えられればどのような非常識な処理も行ってしまいます。データには意味があることをコンピュータに「理解」させればこのようなことは起こりません。

IBM i におけるオブジェクト・アーキテクチャーとは、データを中心に明確な属性付けを行い、それに基づいた演算のみを実行可能とするものです。データを中心として実行可能な演算(メソッド)を定義する、オブジェクト指向プログラミングと同様の考え方です。かつてIBM i が登場した時には「オブジェクト指向」という言葉すら存在しなかったので、このシステムの先進性を表現する手段がなかったのは惜しまれるところです。

さてこのオブジェクトは前述のTIMI上に存在します。そしてその属性情報を強制的に書き換えることはできないような仕組みになっています。簡単に書き換え可能なファイル拡張子によって属性が定まるシステムとは、ガードの固さが全く異なります。

セキュリティに関するレポートを出しているアメリカの「Secunia」がまとめた、OSごとのセキュリティ脆弱件数の報告件数の年間推移を見ていくと、Windows2013の2011年が293件、2012年が128件だったのに対し、IBM iは14件、ゼロ件です。しかも、この14件の内訳をみていくと、SSLやJava、Apacheなどのオープン系のものばかりで、IBM iの基幹部分に関係するものは一件もありません。

4.【単一レベル記憶】 ビジネスで「使える」パフォーマンスを追及

おおよそコンピュータである以上は、パフォーマンスを追求する必要があります。多くのユーザーが同時にアクセスするビジネス用システムにおいては、ひとつひとつのプロセスの処理を短く終わらせることも重要ですが、プロセス切り替え(コンテキスト・スイッチ)のスピード向上も重要なポイントです。そしてプロセス切り替えのネックとなるのは、システムの作業領域としてのメモリ空間の切り替えであり、そのためにディスクへのアクセスと多くのプログラム・ステップ数を必要とします。
最近ではスレッドプログラミングというテクニックを用いることでこの問題を回避するケースも多いですが、既存の基幹業務アプリケーションをこのテクニックを利用して書き換えるのは、膨大なワークロードがかかるので現実的な対応策ではありません。
そこで出てきたのが「メモリ空間の切り替えを発生させない」という考えでした。

一方でシステムはプロセッサ、メモリ、ディスク、といったコンポーネントを中心に稼動しているわけですが、この中で圧倒的にスピードが遅いのはディスクです。すなわちディスクのアクセス・スピードがシステムのボトルネックになる傾向があります。できる限りディスクI/Oを行わずにシステムを稼動させられることが、パフォーマンス以上の面から望ましいと言えます。

ディスクを不要とするほどの広大なメモリ空間を用意できるのが理想ではありますが、容量あたりコストを考えると現実的ではありません。そこでディスク空間もすべてメモリ空間の延長であるとみなしてしまおう、という発想が産まれます。すなわち前述のTIMIのレベルでは、IBM i には広大なメモリ空間しか存在しないように見せかけてしまう、でも物理的にはメモリもディスクも存在する、というシステムです。これが単一レベル記憶の基本的な考え方です。

ディスク上のデータにアクセスする際には、通常のシステムであればファイル・オープンというプロセスを必要とします。これはディスク・アクセスにあたって必要となる情報、例えばある特定のファイルがどのディスクのどのトラックのどのセクタに配置してあるのか、を今後のアクセスに備えてまとめるようなプロセスです。IBM i においてはこのような作業が発生しません。また一度ディスクからメモリにデータが移動するとそのまま常駐しますので、以降はディスクよりもはるかに高速はメモリを対象にアクセスが行われます。容量さえ十分であれば、意図的にデータをメモリに配置することもできますので、最近流行のインメモリ・データベースも古くから実現されていました。

しかしながらメモリ容量がディスク以上であることはありませんので、アプリケーションを稼動させていれば、いずれはディスクからデータを移動する(ページ・イン)だけの空き領域が無い状態になります。すると最も長い期間アクセスされていないデータが選別されて、ディスクに書き戻して空き領域を作ります。(ページ・アウト)この時にシステムは最も利用されていないディスクを選定しますので、長期的に見ると全てのディスク・ドライブの利用率は自動的に平準化されます。単一レベル記憶においては、ディスク周辺の管理の手間がかからない、というのはこのような仕組みがあることによります。

今回、ご紹介してきた、「TIMI」、「オールインワン」、「オブジェクト指向」、「単一レベル記憶」といったアーキテクチャーが産み出された背景には、IBM iにおける哲学とも言えるものが存在します。それは「ビジネスのためのシステムとしてどうあるべきか?」、という視点での理想の追及であり、アーキテクチャーは結果的にテクノロジーとして具現化されたものに過ぎません。この哲学はIBM i が今後どのように進化する事があったとしても、その根底において絶えず生き続けていくはずです。


この記事のあとにはこちらの記事もおススメです。

関連キーワード