【第8回】　サポート – Node.js / Java

前回は PHP を SoE (Systems of Engagement) を実現するための言語として紹介しました。IBM i は様々な外部システムとの連携およびクライアントの多様化に対応していかなければなりません。この要求にどのように答えていくかが IBM i におけるモダナイゼーションであり、この SoE の部分を PHP という言語が担ってくれるということは前回の記事でお話したことです。PHP の登場で、従来の RPG に代表される言語で構築されている SoR と IBM i 以外のシステムやクライアントがさまざまな形で容易に連結できるようになりました。このように PHP は他システムや多様化するクライアントと直接相対する表舞台の言語と言えます。 オープンソース系の言語を紹介する2回目の今回は、モーダナイゼーションを IBM i で実現するために必要な舞台裏にスポットをあて、それを支える言語について解説します。外部からの要求にいかに効率よく高速に応答していくのか、さらには SoR (Systems of Records) の部分の人材をどのように確保していくのか。この問題を解決することができる２つの言語、「Node.js」と「Java」が今回の主役、キーワードは「サポート」です。

Node.js の概要

Node.js は Chrome の V8 JavaScript エンジンで動作する JavaScript 環境（JavaScript ライブラリー）です。IBM i では 2014 年 10 月にライセンス 5733-OPS のオプションとして利用可能になりました。このライセンスはすでにご存知の通り、さまざまなオープンソース・プロダクトを IBM i 上で実行するために提供されたものであり、第6回で紹介した Orion / git や Python などもこのライセンスのオプションとして提供されています。Node.js はこのライセンスが最初にサポートした機能です。 先ほど、Node.js は「Chrome の V8 JavaScript エンジンで動作する JavaScript 環境」と言いました。このエンジンはもともとクライアントで動作する Google Chrome ブラウザに搭載されているものです。それと同じエンジンが IBM i でも実行できるということは、クライアントのコードからサーバーのコードまで、全てJavaScript 言語で作成することができるということなのです。 従来の Web システム開発の一般的なスタイルは、クライアントサイドの処理を JavaScript で、サーバーサイドは PHP や Java、もしくは RPG-CGI などでという、複数言語が必要との前提がありました。それが Node.js の登場によりサーバーサイドも JavaScript での開発が可能になったのです。JavaScript は多くの技術者（特に Web 系の技術者）には慣れ親しんだ言語なので、その技術者が IBM i のプロジェクトに参加する際の学習コストが圧倒的に少なくて済むのは大きな利点です。 また、Node.js および JavaScript 関連の情報は、書籍やインターネット上で入手することが簡単なので、これから学習を始めるという技術者にとっても習得のハードルはかなり低いと思います。

Node.js の特徴

ここから Node.js の詳細な特徴を見ていきましょう。まず、クライアントとサーバーで同じ JavaScript が使えると言いましたが、もちろん言語が同じというだけで実装すべき機能は当然ながら異なります。クライアントは Web ページを構成するオブジェクト（DOM：Document Object Model）を操作し、ユーザーの入力した値の妥当性検査をしたり、ページの一部だけを更新するためにサーバーと通信したりといったクライアント側の見た目や応答スピードなどの改善を実現します。本来であればサーバーサイドでおこなうべきことを JavaScript を使えばサーバーと通信することなくクライアントで完結できるようになり、応答スピードの改善などが実現するのですね。 では、この JavaScript がサーバー側で実現できる機能はどのようなものがあるのでしょうか。これを理解するには、Node.js が出てきた背景を知る必要があります。まず Node.js の特徴は以下の通りです。

• イベントループ
• ノンブロッキング

皆さんは C10K 問題というのを聞かれたことはあるでしょうか？これは「クライアント1万台接続問題」のことで、同時に 1 万クライアントがアクセスするとサーバーがパンクしてしまうことを言います。ここでいう「1 万」という数字は具体的な数字ではなく、「想定以上の」という意味と捉えてください。同時にアクセスするクライアントがあまりにも多くなると、ハードウェア的な処理能力としては問題がなくても、サーバーの要求に答えられなくなってしまうことを C10K 問題というのです。では、この問題を少し深く考えていきましょう。 代表的な Web サーバーである Apache はスレッドモデルで稼働しています。このモデルは、クライアントから要求があるとそれを処理する専用のスレッドが立ち上がり、その要求を処理します。多くのクライアントから別の要求が同時に発生した場合、スレッドは一つの要求しか処理しないので、その要求の数だけ新たなスレッドを立ち上げて後続の要求を処理します。要求が終わらないうちに同時に多くの要求があると、その要求の数だけスレッドを立ち上げなければならず、その分メモリーを消費していことになるのです。メモリーは有限ですから無制限にスレッドを立ち上げることはできません。そのため、通常は最大スレッド数をサーバー側で設定してそれ以上の要求は待機させ、空きがでるとその要求に答えるというのが一般的な動きです。 もちろんここのクライアントの要求は永遠に処理されるわけではないので、通常ではスレッドモデルでもあまり問題がないかもしれません。しかし、多くのリクエスト（C10K）が同時に発生した場合は結果的に応答スピードの低下に繋がります。 これを解決するために Node.js ではイベントループを採用しています。イベントループの場合は、要求を処理するスレッド（プロセス）は一つだけで、処理待ちのキューに要求を溜めておき、その要求をループを回して次々に処理していくという仕組みです。要求のたびにスレッドを立ち上げる必要がないので、メモリー消費がスレッドモデルに比べて少なく済むという利点があります。 しかしイベントループでも、ファイルの I/O や通信処理など処理が開始してから終了するまでに時間がかかる要求が発生すると、ループを回して次々に要求を処理する仕組みがあっても、実際の I/O 時間がボトルネックになってしまい、全体としての応答スピード低下が発生します。そこで、ノンブロッキングという方式が必要になってきます。 ブロッキング処理の場合は、時間がかかる処理は終了するまで次の処理を実行できないのですが、ノンブロッキングによりその処理の完了を待たずに次の処理を実行する仕組みが提供されます。もちろん、前の処理が完了したかどうかを確認する必要もあるのでその仕組みも提供されます。 もともと JavaScript はシングルスレッドモデルでイベントループの仕組みを持っていたため、Node.js は JavaScript のライブラリーで実現されることになったのです。 このことから分かるように、サーバーサイドの Node.js の目的は「一度に多量のアクセスがあった場合に、それを効率よくさばく」ことだということがおわかりいただけると思います。IBM i が SoE としての役目もになうようになった場合、この機能も必須になってくるであろうことは皆さんも良く理解していただけるのではないでしょうか。

Node.js は何を解決するのか

では、C10K 問題は現実的に IBM i で発生する問題なのでしょうか？ 例えば人気アーティストのコンサートのチケット販売システムを IBM i で構築しようとするとこの問題に確実に直面するのは理解できます。しかし、それ以外で1万ユーザーが同時にアクセスするシステムというのはなかなか想定できませんよね。ただこの要求というのは、同時に「購入ボタンを押す」ユーザー数に加えて、例えばリアルタイムな情報を Web ページに自動的に表示するための Ajax の要求なども含まれます。そう考えると、SoR の守備範囲である大量の過去のデータを保持し、刻一刻と新しいデータを蓄積している IBM i の RDB に、必要な時にリアルタイムにアクセスする仕組みを追求していくと、この大量な要求を効率よくさばく仕組みが、近い将来確実に必要になっていくことは容易に想像できます。 不特定多数のユーザーおよびプログラムからの要求をさばかなければならない SoE システムとして IBM i を捉えた場合、この「C10K 問題」への備えは必須であり、すでにそれも IBM i で解決策が提示されているのですね。 オープンソースライセンスとして IBM i でサポートされる Node.js は、IBM i の資源にアクセスできなれば IBM i 上で実行する意味がありません。そこで以下の IBM i 独自の機能拡張も提供されています。

• IBM DB2 for i access library →DB2 for i データベース・オブジェクトへのアクセス
• Node.js toolkit for IBM i →IBM i のデータベース以外の IBM i システム資源へのアクセス ・コマンド ・プログラム ・システム状況 ・ジョブ情報 ・ユーザー空間 ・データ待ち行列 ・オブジェクト情報 ・・・

PHP でも上記と同様、IBM i 資源へのアクセスのための機能が提供されています。SoE システム構築に PHP を利用し、アクセス要求がシビアな場合は Node.js で解決策を模索する、こういったアプローチは IBM i のシステム開発で今後一般的になってくることでしょう。 Node.js は WebSocket もサポートしています。WebSocket はサーバーとクライアント間の Web 上での双方向通信を可能とする仕組みで、サーバーからクライアントに情報をプッシュするなどの機能実装が可能になります。今まで SoE はクライアントからの要求がトリガーになって処理が進むというのが一般的で、情報が更新されているかどうかを定期的にサーバーに確認するなどの必要がありましたが、WebSocket を使えば、情報が更新されたことをサーバー側がクライアントに通知可能となり、よりリアルタイム性の高いアプリケーションを IBM i 上で構築可能となります。

Java の概要

では次に Java 言語を考えていきましょう。Java は Sun Microsystems 社が 1995年にリリースしたコンパイラ言語です。JVM（Java Virtual Machine）が理解可能な形に事前にコンパイルし、パッケージングした上で実行環境に配置（デプロイ）します。Java はもともとが OS に依存しない設計であるため、JVM が稼働するプラットフォームであれば理論上どこでも実行することが可能です。Sun Microsystems の Java のスローガンが「Write Once, Run Anywhere（一度プログラムを書けば、どこでも実行できる）」であったことからもそれを伺い知ることができます。実際には、プラットフォーム固有の仕組みは存在するため、そのスローガンが完全に実現されたとは言えない面もありますが、技術者の多い言語として皆さんも認識されていることと思います。 Java はコンパイル言語という点で RPG / COBOL と同じであり、JavaScript や PHP のようなスクリプト言語に比べると習得に時間がかかると言われています。 ちなみにプログラミング言語ランキングにはさまざまなものがありますが、どれも上位3位は、JavaScript / Java / PHP というものが多いようです。 Java は1999年に発表された OS/400 V4R4 から、AS/400 および IBM i でサポートされています。当初、eビジネス機能強化の目的で実装され、現在は他のオープン系と全く同一のものが IBM i 上で稼働しています。同一なのでプログラム動作上他のプラットフォームとの違いはなく、またIBM i 上で稼働することで、他のプラットフォームにはない IBM i 独自の恩恵（安定稼働、スケーラビリティの確保、パフォーマンス向上）をそのまま享受しています。Java の実行環境としては総合的な観点で最も優れたプラットフォームといっても過言ではないかもしれません。 一方で、Java は完全なオブジェクト指向（Object-Oriented、以下OO）でプログラミングする必要があります。OO の考え方は RPG にはない考え方なので、RPG 技術者が Java を習得してシステムを開発することはなかなかハードルが高いように思います。

なぜ IBM i で Java なのか

Java は他の言語でできることはだいたい実現することができます。特に Web 機能はそれを意識した言語仕様になっているため、Web システム開発時には真っ先に候補として取り上げられることでしょう。Java 開発の際のフレームワークも数多く存在し、大規模で高度なシステム開発には Java は欠かせません。 しかし、IBM i のシステム開発ではどうしても Java でなければならないというのはそう多くないというのも事実です。例えば、ソケット通信機能を実装する場合、Java が選択肢の最初に上がると思いますが、API プログラミングができれば RPG でも実装可能です。今後のメンテナンスに重点を置けば RPG で記述する方が現実的かもしれません。また、Web システムも Java の得意とするところですが、IBM i であれば前回の記事で紹介した PHP が最初の選択肢にあがってくるはずです。 この視点で考えると、IBM i における Java の登場機会はそうないのではと思えてきます。しかし、Java の利点をもう一度まとめた場合、別の視点からJava が必要になるところが見えて来ると思います。

• コンパイラ言語 →変数に型がある（スクリプト言語の変数は型がない）
• OO プログラミング
• プラットフォーム非依存（Write Once, Run Anywhere (JVM)）
• ガベージコレクション →C++はプログラマーがメモリー管理コードも書かなければならないのでそういった意味でプログラマーの負担が減る
• 充実したネットワーク・ライブラリ →TCP/IP プログラミングが簡単にできる
• Java 技術者の数が多い

IBM i における Java の役割

現在、他社メーカーの「オフコン」市場からの撤退が続いており、事実上この分野では IBM i のみが今後も存在していくことになります。他社オフコン・ユーザーで IBM i への移行を検討するユーザーは一定数いると思いますが、「IBM i は RPG や COBOL で開発されるプラットフォーム」という従来のオフコンのイメージだけだと、COBOL のコンバート以外の案件であれば、IBM i はその候補から外れるかもしれません。しかし、最も優れた Java プラットフォームとなってくると話は変わってきます。IBM i の SoR の分野で、RPG / COBOL と並んで Java を意識することにより、従来の IBM i ユーザーだけでなく、他社メーカーのオフコン・ユーザーにとってもこんなに魅力的なシステムはないのです。 おそらくその場合は、OO プログラミングのできる技術者に IBM i への移行プロジェクトに入ってもらい、IBM i の技術者と共同でシステム開発を進めていくことになるでしょう。Java 技術者は、RPG 技術者よりも多く存在します。システム管理および既存のデータベースを IBM i 技術者が担当し、システム開発部分を Java でおこなうということは、他社オフコン・ユーザーの IBM i 移行への現実的な解決策になるはずです。 もちろん既存の IBM i ユーザーにとっても、Java 言語は魅力的なはずです。今後も使い続けられるシステムとしての IBM i で、SoR の領域の開発言語が RPG / COBOL にプラス Java という選択肢は、技術者不足問題が実質なくなることを意味します。先ほど触れたプログラミング言語ランキングの上位がすべて IBM i で利用可能であることの意味はとても大きいのではないでしょうか。

おわりに

キーワードとして色んな所で目にし、また聞く機会が多くなった「クラウド」や「ビッグデータ」。SoR の視点では考えられなかった多くのユーザーやプログラムからのアクセス、そして大量のデータ処理の負荷が、これからの IBM i に否応なしに押し寄せてきます。ハードウェア的には今後も POWER9 から POWER10 へと充分すぎるぐらいのものが提供される予定ですが、言語やシステム設計などでそれに対応できなければ意味がありません。今後発生するであろう桁違いのクライアントからの要求に答えるための Node.js と、Web 処理から SoR まで守備範囲の Java 言語とその技術者との連携を今からしっかりイメージして準備をしていきましょう。 IBM i のユーザーにとっても開発会社にとっても、これから必要になると思われるさまざまな機能はこれからもどんどん提供されてくるはずです。これは今までの IBM i の歴史が証明していることです。さまざまな観点から提供される「サポート」をきちんと理解して活用していきましょう。

著者プロフィール