統合APサーバーを活用してREST化する
IBM i上で稼働するアプリケーション資産をRESTサービス化やクラウド連携する方法は、多数考えられる（図表1）。以下に、その代表例を紹介する。
統合APサーバー機能を利用したREST化
統合APサーバーは、IBM i OS標準搭載のアプリケーションサーバーである。従来はIBM i 独自実装のAPサーバーであったが、最近のリリースではWebSphere Libertyベースに改められており、ポジティブな意味で独自性の排除、標準化が進んでいる。
統合APサーバーには従来から、IBM i上のRPGやCOBOLプログラムをSOAP／Webサービスとしてデプロイする機能があるが、IBM i 7.1以降でREST呼び出し対応に拡張された。ちなみにRESTサービス対応後の統合APサーバー機能は、「統合Webサービスサーバー」（Integrated Web Service Server）と呼ばれるが、簡略化のため本稿では統合APサーバーで統一する。
IBM i 7.1以降のシステムでは、この機能で簡単にREST化が可能である。統合APサーバーの設定は、IBM Navigator for iでHTTP ADMINサーバー（HTTP://（IBM iホスト名:2001））にアクセスし、インターネット構成→IBM Web Administration for i→Application Serverタブ→Web Serviceウィザード「新規サービスの配置」からアクセスできる（図表2）。
このサービス登録ウィザードに従ってプログラム名やパラメータを指定するだけで、IBM i上のRPGやCOBOLプログラムに対してREST呼び出しを行うサービスが統合APサーバー上にデプロイされる。
統合APサーバーはIBM i 7.4と7.3 TR6でさらに機能拡張され、図表3のようにRPG、COBOLなどのアプリケーションプログラム以外のIBM i 資産、具体的にはDb2、IBM i システムリソースのREST API化（サービス化）が可能となった。
たとえばIBM i 外部からDb2をRESTで呼び出す場合、IBM i 上の統合APサーバーに実行したいSQLステートメントを登録すれば利用可能となる。従来はIBM i 上でRPG、COBOL、Java、その他の言語でプログラムを書く必要があったが、この機能だとSQLが書ければよいので、オープン系技術者でも容易にDb2 for iを利用可能となる。
また呼び出しに必要なのはHTTP／RESTだけなので、ODBCドライバやJDBCドライバは不要となり、クライアント端末の制約を解放して、さまざまなクライアントからIBM iへのアクセスを可能とする。SQLはDDL、DML、DCLを使用可能である。
IBM iのシステムリソースへのアクセスは、IBM i サービスとして以下のように提供されている。これらはすべて統合APサーバーからRESTインターフェースにより、サービスとして外部から利用可能である。
◎Db2 for iへのSQLアクセス
DDL、DML、DCL
◎ルーチンプロシージャー、ファンクション
Create or Replace、Alter、GRANT/REVOKE execution、DROP
◎スペシャルレジスター
Currentの date、path、schema、server、time、timestamp、Time Zone、User、path、schemaのセット
◎ビルトイングローバルレジスター
クライアントのホスト名、IP、Port、パッケージ名、job name、スレッドID
クライアントのホスト名、IP、Port、パッケージ名、job name、スレッドID
IBM iサービスは近年大幅に拡充されているが、その目的は「プログラミングレスでIBM iのアプリケーション資産、IBM i システム機能（OSやDBその他）を利用可能にすること」「とくにクラウドや新しい種類のリクエスターからIBM iリソースを利用可能にすること」だと言える。
IBM i サービスを使えば、IBM i OSのスプールや印刷機能、Db2 for iの諸機能や管理をRESTサービスとして外部公開できる。また従来、CLPなどで手組みしていた運用・保守管理機能を、IBM iサービスを使って置き換えるだけでもシステム資産の標準化と俗人性の排除によって運用性を高められる（Column 7）。
統合APサーバーの
SOAPサービスアプリケーションをREST化
すでに統合APサーバーでSOAP呼び出しを利用している場合、呼び出しインターフェースをSOAPからRESTに変更することで、比較的容易にREST化に対応できる。
手順は、個々のSOAPサービスについて統合APサーバーの新規サービスの配置ウィザードでRESTを選択し、登録し直す作業となる。
統合APサーバーのアプリ呼び出しは
SOAPのままでREST化
前述した2つの方法は、SOAPからRESTへの変更作業を統合APサーバーに登録済みのサービス1つ1つに実施する必要があり、大規模システムでは作業工数が肥大するケースもあるだろう。また旧から新へのサービス移行局面で、煩雑な作業や運用が必要になるかもしれない。
このようなケースで有用なソリューションとして、IBMのサービスソリューションであるAIF（API Integration Framework）を紹介する。AIFを一言でいうなら、「WebSphre Liberty（もしくはWAS V9）上で稼働し、RESTサービスリクエスターとサービスプロバイダーの間に介在して、REST／SOAP（その他の）プロトコル変換をするもの」である（図表4）。
IBM i のSOAPサービスをRESTサービス化するケースでAIFを用いれば、基本的にはIBM i 側は一切手を入れずに、REST化したAPIインターフェースで外部サービスと接続することが可能となる。
また、AIFはそれぞれのAPIインターフェースに対するフロー制御や移行・バージョンアップ時などに適用可能なマイグレーション制御機能、コーディングレスでのREST API生成、複数サービスの統合機能など多彩な機能を備えており、既存の非REST環境を含む複数のサービス群の統合や大規模なREST移行がある場合など、さまざまなシーンで利用できる。
AIFは金融業向けなど大規模で高信頼性が必要な業務への適用も視野に開発されており、信頼性・拡張性・安定性の観点でも十分実績がある。
サービスとしてアプリ開発する際の
ベストプラクティス
マイクロサービスなど、アプリケーションをサービスとして実装する際のベストプラクティスは数多く提唱されている。ここではいくつかの代表例を紹介する。
◎The Twele-Factor App
これはWebアプリケーションをSaaSとして構築するためのメソドロジーとしてまとめられている（https://12factor.net/ja/）。
このドキュメントでは、IBM Cloud（旧Bluemix）と同様のPaaSプラットフォームであるHerokuでのアプリケーション開発のノウハウをまとめている（図表5）。
◎マイクロサービス構築上の重要な教訓とあるべき姿
IBM developerWorks上で公開されているいくつかのブログ記事のサマリーを紹介する（図表6）。マイクロサービスや分散環境でのプログラミングでの「べからず集」「あるべき姿」の定義としてシンプルにまとまっている。
IBM i アプリケーションの
マイクロサービス化ステップ
実際にIBM i アプリケーションをマイクロサービス化する進め方について、具体的な例を紹介する。
Step1 アプリケーションのリファクタリング
以下の手順で、アプリケーションのリファクタリングとサービス化に着手する（図表7）。
❶ EARを分割し、OPMプログラムのILE化と分割・サービスプログラム化する。
❷ 接続するオープン系システムについてサービスごとのDockerコンテナを構築する。
❸ 個別にビルド・デプロイ・マネージする。
Step2 アプリコードのリファクタリング
より細かい粒度にアプリコードをリファクタリングし、マイクロサービス化を志向する（図表8）。
下記の4点に着目する。
❶ 既存RESTまたはJMSサービスをさらに細かく分割する。
❷ 既存SOAPまたはEJBサービスについては、単一オブジェクトへのCRUD処理の場合、簡単にRESTfulインターフェースにマップできる。
❸ 単純なServlet／JSPについては、単純なDB操作のユーザーインターフェースの場合、新たにRESTfulサービスのドメインオブジェクトを作成して置換する。
❹ OSS、JavaScript、HTML5、CSS、またはネイティブモバイルアプリケーションを作成し置換する。
Step3 データのリファクタリング
以下の流れで、データのリファクタリングを進める（図表9）。
❶ データの孤島について切り出しを検討する。最適なデータストアへの移行、およびOSS、NoSQL、その他のデータストアも含めて最適なストアを検討する。
❷ バッチデータ更新について、リアルタイムでの同期が必要でないものを洗い出し、最適に配置する。
❸ テーブルの正規化解除について、多くのテーブルとリレーションをもつテーブルを非正規化し、リレーションを簡素化して、クエリーの高速化を図る。
RPG／COBOLアプリケーションの
リファクタリング考慮点
前述したリファクタリングのより具体的な方法については、本文末に記した参考情報で確認してほしい。これらの参考情報は主にJavaアプリケーションを前提に記述しているので、以下にRPG／COBOLを前提としたリファクタリングの進め方について例を挙げて説明する。
①OPMプログラムのILE化
マイクロサービス化対象のRPG ⅢコードはCVTRPGSRCコマンドでILE変換する。COBOLはシステム提供のILE変換コマンドがないので、何らかの形でILE化を検討する（ILE RPGかILE COBOLでREST呼び出しラッパープログラムを作る、ILE COBOLに手作業でソース移行する、など）。
②RPG／COBOLのソース分割、サービスプログラム化
複数プログラム間で類似の機能を実装している場合、それぞれから分離してサービスプログラム化を検討する。たとえば消費税率の計算ルーチン、在庫引き当てロジック、発注点など何らかの閾値を超えた際のトリガー処理などが考えられる。
共通機能でIBM iの外からサービスを呼び出す可能性がある場合、サービスプログラムにRESTサービス・インターフェースを付加する。IBM iローカル以外からの呼び出しを想定していない機能は、RESTインターフェースを付加する必要性は低い。REST化による処理パフォーマンスの低下と開発標準化・サービス化等のメリット／デメリットを比較検討して決定する。
1つのプログラム内で機能的にまったく別個なコードが混在している場合、プログラム分割を検討する。長大なRPG／COBOLのソースも保守性の観点から分割検討の対象となるが、DX、CI／CDの保守性、変更発生度の観点からメリットがあるかどうかで分割可否を決定する。
たとえば1本のRPG／COBOLプログラム内で、受注データのDB更新と受注結果の印刷指示ロジックが共存している場合、マイクロサービス的な基本形としてはプログラムを分割すべきである。
分割すると当然、受注ロジック側から印刷指示をキックするロジック実装が必要となるが、この印刷キックのロジックをサービス公開することでクラウドを含む外部サービスからの（基本はREST APIでのサービス）リクエストを共通化できたり、IBM i内の別プログラムからも印刷処理をキックできることがプログラム分割のメリットとなる。
印刷処理ロジックを共通化できれば、保守性の点でも効率化できる。マイクロサービス以前はプログラムの呼び出し方法は１つ、もしくは少数で固定的であったが、マイクロサービス環境では呼び出し方法は多様で、常に変化していくことを想定してプログラム配置を行うのが理にかなっている。類似するプログラムロジックを極力排除する、サービス連携する、という視点でプログラム資産のモダナイゼーションを進めていく。
③OSSなど別言語に置き換える必要性の検討
「CI／CDが必要か」と「プログラム実行基盤を、クラウドを含むIBM i以外に移動させたり、ダイナミックに変更できるとメリットがあるか」の2点で検討するのがよい。イエスであれば、OSSでRPG／COBOLのプログラムロジックを書き換える価値があるかもしれない。
④データの分散と連携を検討
アプリコードがクラウドなどIBM i以外での稼働に変更される場合、プログラムが更新するデータの生成・保管場所も再検討する。改修前は基本的にDb2 for i（かIFS上）にあるはずなので、「ロジックが動作するローカル環境上でのデータ生成・ストアが適するか」を検討する。
適する場合はNoSQLも含め、最適なデータストアを選定する。何らかの形でDb2 for iとのデータコピーや連携が必要になるので、データボリューム、動機タイミング（リアル・バッチ・ストリーミングなど）や同期サイクル（即時・x分・時間おき・日次など）とパフォーマンス要件を検討し、最適な同期方法を選択する。
またデータ連携用のミドルウェアやソリューションも検討する。もしパフォーマンスが問題にならないケースなど、ローカルIBM i のDb2 for iにストアしたほうがいい場合はDb2 for iにデータ生成する。
⑤アプリ層やミドルウェア層以外でのデータ連携を検討
データ複製や同期はアプリケーション層・ミドルウェア層以外に、ストレージレイヤ機能でも可能なので検討する（例、IBM Spectrum Virtualize）。
たとえば商品マスタ情報全件を常にローカル・オンプレミスで最新に同期するのでなく、参照頻度の低い商品情報についてはWeb側はリンクとし、アクセスがあったときにオンプレミスのマスタデータの最新情報を参照する、複製もリアルタイムをなるべく減らしてタイムラグを許容するアプリケーションデザインにする、などの実装が可能である。
⑥データベースの非正規化を検討
長らくデータベース正規化は一般に「絶対的な善」とされてきたが、昨今はあえて非正規化し、SQLの処理スピードを第一に考えることも一般化している。
⑦運用負荷を考慮して機能要求を下げる検討
CI／CD、アジャイルでは運用負荷を低く維持し続けることが重要である。高度化・複雑化するアプリケーションの機能要求だけを考えて実装を続けると、運用負荷も漸増し、結果的にCI／CDが回らなくなる懸念もある。
すべて機能要件優先ではなく、運用負荷漸増回避の観点から機能要求レベルを下げ、運用負荷が増えないように考慮することも非常に重要である。
［参考情報］
著者｜
佐々木 幹雄
日本アイ・ビー・エム株式会社
システム事業本部 Power Systemsテクニカル・サポート
コンサルタントITスペシャリスト
システム事業本部 Power Systemsテクニカル・サポート
コンサルタントITスペシャリスト
AS/400誕生とほぼ同時期からIT業界に関わる。IBM i やPC、ネットワーク機器など一般企業のIT基盤の提案・構築、アーキテクトなどを幅広く経験。IBM i エバンジェリストとしての活動もある。
････････
特集｜IBM iのマイクロサービス化
････････
Column 1 OpenShiftかKubernetesか
Column 2 どこでもKubernetes
Column 3 ミドルウェアのコンテナ化対応
Column 4 SCNは戦略策定のためのフレームワーク
Column 5 ハイブリッドクラウド移行（中期）計画を作る
Column 6 アジャイルはSoEだけのものか？
Column 7 IBM iサービスとDb2 for iサービス
Column 8 IBM iのクラウドサービス
Column 9 コンテナテクノロジーを導入しても、イノベーションは起きない
［i Magazine 2020 Spring掲載］
