【OSS】第13回「IBM iの視点で見直すコンテナ、マイクロサービス及びオープンソース」

2021年8月19日　ニールス・リースバーグ

IBMチャンピオンのニールス・リースバーグ氏が、コンテナ及びマイクロサービステクノロジー、IBM i上のオープンソースについて語り、IBM iに堅牢なソリューションのための素晴らしい未来が待っている理由を説明します。

企業のソフトウエア開発に関わったことがあるなら、マイクロサービスやコンテナのような概念に出会ったことがあると思います。おそらく、KubernetesまたはOpenShiftを扱う仕事をしたことがあるでしょう。そして、もしかするとオープンソースのフレームワークであるSpring Bootを使ってJavaでマイクロサービスを既に開発しており、GraaIVMはとても素晴らしいと喜んでいるかも知れません。個人的に私は上記のものをGit、DevOps及びCI/CDパイプラインと共に日がな一日使用しています。また一方で、これらすべてのツール及び製品は、IT業界に何年も纏わり付いていた問題を解決することを意図しています。それは関心事の分離に関するものです。それは、分離、セキュリティ及び市場投入までの時間短縮のためです。それは、基本的にベストプラクティスを目的としています。

今日私達がどのようにこれらのテクノロジーを使用しているか、過去のアプローチはどのようなものだったか、IBM iが中心的な役割を演じた理由及びIBM iに堅牢なソリューションのための素晴らしい未来が待っている理由を対比してみたいと思います。

コンテナとIBM i アーキテクチャ

まずコンテナを見てみましょう。コンテナを巡る大騒ぎの理由は何でしょう？ 第一にコンテナは、PC上で起動できる共通のイメージ形式で、他のワークロードから分離され、会社のサーバーとクラウド上の複数のインスタンスとの間を容易に移動できます。これですべて語り尽くされていると思います！ そのような構成要素を使うことで、生活はとても便利になります。しかし、IBM iはコンテナをサポートしていますか？ 私達が期待するような形や程度ではサポートされていません。IBM i上でDockerがネイティブに動作すると期待しないでください（少なくともこの記事が書かれた時点では）。そして、確かにchrootを使ってある程度の手品を行うことはできますが、それは私の言いたいことではありません。むしろ私はIBM iアーキテクチャに対する一般的な期待に異議を申し立てたいと思います。

ロチェスターのチームは、1980年代にIBM iの青写真を作り上げたとき遥か先を行っていました。チームはオブジェクト（プログラム、データベース、セキュリティオブジェクト等）用のコンテナを作るアプローチを考え出しました。このコンテナは、開発環境からテスト環境、別システムまたはクラウドへ移送可能なイメージに変換できます。これと私達が今日知っているコンテナとの1つの大きな違いは名前です。IBM i上ではそれらはライブラリと呼ばれ、コンテナイメージは保管ファイルと呼ばれます。

IBM iには信頼できるDb2の実装が備わっています。Db2にデータベーススキーマを作成したとき、それはコンテナ（ライブラリとしても知られています）になります。デプロイとセキュリティは他のライブラリと同じ規則に従うので、IBM iライブラリの規範を扱うのは誰にとっても容易です。イメージを作成し、それをクラウドに移して仕事は完了です。データをオフロードしたり、再ロードしたりする必要はありません。

しかし、コンテナを調和的に統合することはどうでしょう？ OSそれ自身はコンテナ（ライブラリ）と同じ概念に近いところで構築されているので、QSYSという名前のコンテナに入れられて出荷されます。KubernetesまたはOpenShiftを探し求めるとき、代りにあなたはIBM i及び自分のライブラリ（コンテナ）からプロセスを起動するサブシステム概念を手にし、ジョブ記述内で上手に定義されたライブラリリスト概念を使ってこれらのコンテナ（ライブラリ）で機能を結合することさえできます。ジョブ記述は、プロセッサーのワークロード、ユーザーアクセスそしてその他重要なチューニング項目のようなシステム資源を統制する能力を与えてくれさえします。その概念は例えばComposeを使ってDockerファイルを書くのと同じですが、異なるものです。

Javaコミュニティの改善点

私の意見では、過去2年間にわたるJavaコミュニティの最も重要な改善点はGraalVMです。それは、JavaだけでなくPython、Node.js、Rそしてもっと多くの言語をサポートする共通VMを与えており、他の言語を統合するためのまったく疑う余地のないソリューションです。

過去に私は、JVMがその中でJavaScript及びPythonを実行できるようにしたNashorn、Rhino、Jythonを使ったことがありますが、それはJavaを中心としたものであったため業界であまり注目されず、現在は多かれ少なかれ衰退しています。今やGaarlVMを使って全ての言語が統合され、互いにコンポーネントを使用できるので、障壁は崩壊し、どんな言語でも自分のソリューション開発に最適な言語を使用できます。この機能すらもIBM iが何年も前にカバーしていたというのは大きな驚きかも知れません。

統合言語環境（Integrated Language Environment: ILE）は、その名前が暗示するように自分のニーズに最も適した言語を選択できるようにします。スクリプト言語のCLでさえILE言語ですから、プログラムとの対話やアプリケーション、スクリプト（CL）、OSコマンド間のパラメータ渡しをシームレスに行えます。IBM i上のGraaIVMを見たいものです。何故ならJava、Node.js、PythonはILEとは違う種類の言語であり、ライブラリ内から実行できないからです。ライブラリ内から実行できるのはILEだけです。

マイクロサービスとオープンソース

今日マイクロサービスは皆の関心事です。マイクロサービスは、要するに一般的にサーバーレスアーキテクチャにより駆動される関心事の分離です。私がJavaアプリケーションを構築する場合、Spring Bootを使うのが好みです。Pythonの場合にはFlaskまたはFastAPIを使います。Node.jsの場合はSenecaが好みです。

しかしILE環境に関してはどうでしょう？ さて、それはオープンソースが登場する領域です。私はILElasticというサーバーレスのオープンソースアーキテクチャに多くの時間と労力を費やしています。それにより単純なHTTPサーバーテクノロジーをアプリケーションに結合できます。また、JSON I/O概念を使ったILEマイクロサービスのために、noxDBプロジェクト（これはあなたによる使用と貢献を待っている、更にもう１つのオープンソースプロジェクトです）に大いに助けられるでしょう。これらのプロジェクトは、OpenShiftあるいはKongのようなAPIゲートウェイによって管理されている巨大なマイクロサービスアーキテクチャにおいてさえも開発時間を削減し、IBM iをシームレスに動かします。これらは最古のCOBOLやRPGプログラムでさえも異種のサービス内で重要な役割を果たすようにする実績のあるソリューションです。

進化するシステムとベストプラクティス

マイクロサービスアーキテクチャにおける中核の戦略 ― 関心事の分離 ― は、あなたが伝統的なIBM iのレガシーアプリケーションを公開するときに最初に考えるであろうこととは違います。これらのレガシーシステムが設計されたとき、統合がすべてでした。アーキテクトは（知ってか知らずか）データベースを正規化する際に関数依存性を使用しました。基本的に、共通のキー項目をもつすべての項目は同じ表に正規化されるべきです。

しかしドメイン駆動設計ではこれが劇的に変化し、ベストプラクティスは最悪の慣行になりました。その理由は人間の認知の限界を考えれば明らかです。小さなシステムでは、コードやデータベースにおける或る変更の影響や結果を概観することは容易です。しかし、時の経過と共にシステムが成長したとき、難しさは指数関数的に増大し、ほんの僅かな変更でさえ張り詰めたテストを必要とします。更に事態を悪くすることに、今日では回帰テスト及び単体テストは全員がやる気を出す仕事ではありません。このことはレガシーシステムを退役させ、それらをマイクロサービスで置き換えるべきだということを意味するのでしょうか？ 絶対に違います！ レガシーシステムの価値は膨大です。これらのレガシーシステムには何十年にも渡って何千時間もの時がつぎ込まれ、世界中でビジネスを駆動しています。レガシーシステムはそれを正しく前進させれば真の宝です。

モダナイゼーション対トランスフォーメーション

あなたは複数の人からモダナイゼーションを行うべきだと聞かされることでしょう。私はまったく同意できません。あなたの武器はトランスフォーメーションです。おそらくモダナイゼーションは第1段階ですが、旅はそこで終わる訳ではありません。共有データベースと一緒にマイクロサービスを使って一枚岩の構造のプログラムを分解するのはアンチパターンであり、そのことを念頭に置いてこそ来るべき将来への列車に乗り込むことができます。

その過程で、データベースをドメインに分割することに時間を割くのも価値のあることです。ドメイン分割は関心事の分離です。レガシーデータベースを、他のドメインとの間で依存関係が無くなる（または、できるだけ少なくなる）ように別々のコンテナ（ライブラリ）に分割します。これが進むべき道であり、いつの間にか自分たちのアプリケーション内で真のマイクロサービスを実装してしまっています。そこでは人間の認識の限界は最早問題にはなりません。マイクロサービスは特効薬ではなく、代償を伴います。すべてのコンテナ（ライブラリ）が１つに纏まって均質なサービス世界ができあがります。そして、これらを調和した形で統合することがそれ自身の１つの課題です。

この記事によって、あなたがIBM iに別な印象をもつことを祈ります。IBM iはIT業界のある人々があなたにそう思って欲しいと考えているのとは違い、古びていません。私はIBM社員ではありません。IBMが提供しきれないテクノロジーがとりわけオープンソースの領域にあり、これがあなたの生活を便利にすると私は恐れずに言います。しかし、私はIBM i及びIBM iがビジネスのために出来る事の大ファンでもあります。この地球上で見出せる最も進んだアーキテクチャの開発を推進できる青写真をIBMが作ったのは驚くべきことだと思います。

著者紹介

ニールス・リースバーグ氏はデンマークにあるSystem & Metode A/S社の首席ソフトウェアアーキテクトであり、PowerのIBMチャンピオンです。