コンテナ、マイクロサービス、オープンソース。新たなる視座からのIBM i | IBM i 総合情報サイト

コンテナ、マイクロサービス、オープンソース。新たなる視座からのIBM i


コンテナ、マイクロサービス、オープンソース。新たなる視座からのIBM i

IBM チャンピオン(編集部注:IBM系の情報発信をするインフルエンサー)の Niels Liisberg が、コンテナとマイクロサービス技術、IBM i におけるオープンソース、そして IBM i がその堅牢なソリューションが故に素晴らしい未来が待っている理由を語ります。

By Niels Liisberg
08/19/2021

企業のソフトウェア開発に携わる方であれば、マイクロサービスやコンテナといった概念に出会ったことがあるかと思います。おそらく、KubernetesやOpenShiftを使ったことがある人もいらっしゃるのではないでしょうか。また、オープンソースのフレームワークである Spring Boot を使って Java で既にマイクロサービスを開発し、GraalVM の素晴らしさに感激している人もいるかもしれません。個人的には、Git、DevOps、CI/CDパイプラインなど、上記のすべてを毎日のように使っています。しかし、これらのツールや製品はすべて、IT業界で古くからある問題を解決することを目指しています。それは、問題の分離(SoC : Separation of Concerns)です。分離、セキュリティ、そして市場投入までの時間の短縮です。基本的には、ベストプラクティスのことを指しているのです。

これらの技術を現在どのように使っているか、過去にどのようなアプローチがあったか、なぜIBM iが主要な役割を果たしたのか、なぜIBM iが堅牢なソリューションのために素晴らしい未来が待っているのかを比較検討したいと思います。

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

まず、コンテナについて見てみましょう。なぜコンテナが騒がれるのか?まず、コンテナとは、PC上でスピンアップできる一般的なイメージ形式で、他のワークロードから分離され、会社のサーバーとクラウド上の複数のインスタンス間で簡単に移動できるものです。これが全てを物語っているのではないでしょうか!?このようなビルディングブロックがあれば、生活はとても楽になります。しかし、IBM i はコンテナをサポートしているのでしょうか?残念ながら期待するような形やサイズではありません。DockerがIBM i上でネイティブに実行されるとは思わないでください(少なくともこの記事の時点では)。そして、そうです、あなたはchrootでいくつかの魔法を使うことができますが、それは今回の論旨からは外れます。私はむしろ、IBM i アーキテクチャに対する一般的な期待値に挑戦したいのです。

1980年代にIBM iの最初の設計図をつくったロチェスターのチームは、ずっと先を見据えていました。そのチームは、オブジェクト(プログラム、データベース、セキュリティ・オブジェクトなど)のコンテナを作成するアプローチを考え出しました。このコンテナは、開発環境からテスト環境、別のシステム、またはクラウドに移動できるイメージに変換するとこうなります;IBM i の世界ではライブラリと呼ばれ、コンテナ・イメージはSAVFと呼ばれています。

IBM i には、Db2 の強固な実装が備わっています。Db2 でデータベーススキーマを作成すると、それはコンテナ (ライブラリとも呼ばれる) になります。デプロイメントとセキュリティは他のライブラリーと同じルールに従うので、IBM i のライブラリー・パラダイムで作業する人なら誰でも簡単に利用できます。イメージを作成し、それをクラウドに移動すれば完了です。データのオフロードやリロードは必要ありません。

しかし、コンテナのオーケストレーションについてはどうでしょうか。OS自体も同じようにコンテナ(ライブラリ)の概念で作られているので、QSYSというコンテナで出荷されています。KubernetesやOpenShiftを探すと、代わりにIBM iと、自分のライブラリ(コンテナ)からプロセスをスピンアップするサブシステムの概念があり、このコンテナ(ライブラリ)による機能を、ジョブ記述でライブラリーリストの概念をうまく使って組み合わせることもできるのです。ジョブ記述では、プロセッサのワークロードやユーザーアクセスなど、重要なチューニング項目であるシステムリソースを制御する機能まであります。コンセプトとしては、例えばComposeでDockerファイルを書くといった作業と同じですが、異なるものです。

Javaコミュニティの改善

私が思うに、ここ数年のJavaコミュニティにとって最も重要な改善は、GraalVMです。Javaだけでなく、Python、Node.js、Rなどをサポートする共通のVMを提供し、他の言語を統合するための明白な解決策です。

過去には、JVMの中でJavaScriptやPythonを実行できるNashornやRhino、Jythonなどを使っていましたが、Java中心だったため、業界ではあまり注目されず、今ではすべてサンセットの道をたどっています。今、GraalVMでは、すべての言語が統合され、互いのコンポーネントを使用することができますので、障壁がなくなり、特定のソリューションを開発するために最適な言語を使用することができるのです。この機能でさえ、何年も前にIBM iのためにカバーされていたことは、大きな驚きかもしれません。

ILE(Integrated Language Environment)は、その名の通り、自分のニーズに最も適した言語を選択することができるのです。スクリプト言語であるCLもILE言語なので、アプリケーション、スクリプト(CL)、OSのコマンドの間でシームレスにプログラムをやり取りしたり、パラメータを渡したりすることが可能です。Java、Node.js、Pythonは、ILEとは異なる生き物であり、ILEの範疇であるライブラリ内から実行されないので、IBM iでGraalVMを見ることができたらと思います。

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

最近、マイクロサービスが注目されています。マイクロサービスとは、サーバーレスアーキテクチャによって推進される典型的な問題の分離(SoC)を意味します。私は、Javaアプリケーションを構築する場合、Spring Bootを好んで使っています。Pythonでは、FlaskやFastAPIを使用し、Node.jsでは、Senecaを愛用しています。

しかし、ILE環境はどうでしょうか?まあ、そこはオープンソースの出番といえるでしょう。私は現在ILElasticという、シンプルなHTTPサーバー技術をユーザー・アプリケーションに紐づける、サーバーレスアーキテクチャのオープンソースプロジェクトに多くの時間と労力を費やしています。また、JSON I/Oの概念を使ったILEマイクロサービスでは、noxDBプロジェクトに助けられることが多いでしょう。これらのプロジェクトは開発時間を短縮し、OpenShiftやKongのようなAPIゲートウェイによって管理される巨大なマイクロサービス・アーキテクチャにおいても、IBM iをシームレスに動作させることができます。これらは、最も古いCOBOLやRPGのプログラムであっても、異種サービスのランドスケープで重要な役割を果たすことができる、実績のあるソリューションなのです。

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

マイクロサービス・アーキテクチャの核となる戦略である問題の分離(SoC)は、従来のIBM iレガシー・アプリケーションを開いたときに最初に思いつくようなものではありません。これらのレガシー・システムが設計されたとき、それはすべて統合に関するものでした。アーキテクトはデータベースを正規化する際に(知ってか知らずか)機能依存性を使用しました。基本的に、共通のキーを持つものはすべて、同じテーブルに正規化されるべきでした。

しかし、ドメイン駆動設計では、これが一変し、ベストプラクティスがワーストプラクティスになりました。その理由は、人間の認知の限界について考えれば明らかです。小規模なシステムでは、コードやデータベースの特定の変更がもたらす影響や結果を概観することは容易です。しかし、システムが時間とともに大きくなると、その困難さはほぼ指数関数的に増し、最小の変更であっても膨大なテストが必要になります。さらに悪いことに、回帰テストや単体テストは、最近では誰も思いつかないものとなってしまっているのです。だからといって、レガシーシステムを廃棄して、マイクロサービスに置き換えるべきでしょうか?絶対にそんなことはありません。レガシーシステムの価値は膨大です。これらのレガシーシステムには何十年にもわたって何千時間もの時間が費やされ、今日も世界中のビジネスを動かしているのです。レガシーシステムは、正しく前進させれば、本当の宝物なのです。

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

複数の人から「近代化(モダナイゼーション)したほうがいい」という意見を聞くことがあります。私は全く反対です。あなたの武器は変革です。おそらくモダナイゼーションが最初のステップになるでしょうが、旅はそこで終わりではありません。
モノリスを共有データベースによるマイクロサービスで分解するのはアンチパターンであり、それを踏まえたうえで来るべき未来への列車に乗り込めばいいのです。

その過程で、データベースをドメインに分離することも時間をかけて行う価値があります。ドメイン分離とは、問題の分離(SoC:Separation of Concern)のことです。レガシーデータベースを、他のドメインに依存しない(あるいはできる限り依存しない)別々のコンテナ(ライブラリ)に分割するのです。この方法で、いつの間にかあなたのアプリケーションに本物のマイクロサービスを実装することができ、人間の認知の限界はもはや問題ではなくなります。マイクロサービスは銀の弾丸ではなく、代償を伴うものです。あなたのコンテナ(ライブラリ)をすべて合わせると、異種サービスの風景となり、これらのオーケストレーションはそれ自身の課題となるのです。

この記事で、IBM iに対する印象を改めてお持ちいただけたと思います。IT業界の一部の人が考えるように、このプラットフォームは時代遅れではありません。私はIBMerではありません。あえて言うなら、IBMが提供できる以上の技術、特にオープンソースの分野には、あなたの生活をより快適にしてくれるものがあります。
しかし、私はIBM iの大ファンであり、IBM iがあなたのビジネスに何をもたらしてくれるのかも知っています。IBMは、今日の地球上で見られる最も高度なアーキテクチャの開発を推進できる青写真を作ったことは、素晴らしいことだと思っているのです。

Copyright © IGUAZU