3分で読める「コンテナの現在（いま）」 #3クラウドネイティブ・アプリケーションを支えるOSS群

本シリーズ第3回目はコンテナ化のその先にあるクラウドネイティブなアプリケーションを実現するためのOSS（Open Source Software）群を紹介していきます。

クラウドネイティブなアプリケーションを志向する時には業務ロジックの作り方だけではなくインフラ、ミドルウェアを含めた全体的な設計が必要となります。例えばAWS上でアプリケーションを設計する時などをイメージすると分かりやすいとは思いますが、EC2（Elastic Compute Cloud）のようなIaaS（Infrastructure as a Service）だけではなく、API Gateway、Cognito、 Kinesis、 SQS（Simple Queue Service）などなど様々なSaaSを組み合わせてアプリケーションを構築していくことになるでしょう。

ハイブリッドクラウドの実現とOSS

このように、クライドネイティブなアプリケーションを構築するために特定のクラウドが提供する様々なSaaSを活用することは非常に合理的なアプローチと言えますが、複数のクラウド、オンプレミスを組み合わせて活用するハイブリットクラウドを志向する場合にはもうひと工夫必要となってきます。特定クラウドのSaaSでクラウドネイティブなアプリケーションを構築すると当然ながらそのアプリケーションは特定クラウドにロックインされたアプリケーションとなります。前述した通り、特定クラウドにターゲットして構築していくこれらのアプローチを意識的に行なっている場合は非常に合理的なアプローチですが、そうではない場合に他のクラウドへ移行するとなった時に相応のコストがかかることになります。

これらの特定クラウドへのロックインを避けるためにOSSを活用してハイブリッドクラウドを志向していくことが必要となります。
クラウドネイティブなアプリケーション構築に活用できるOSSを機能単位に紹介していきます。

クラウドネイティブ・アプリケーションを支えるOSS

クラウドネイティブ・アプリケーションといっても意味するところは様々ですが、主に以下のような機能が求められることが比較的多いのではないでしょうか。

• API管理

せっかくAPIを作ったとしてもそれを乱立させていては有効に活用することはできません。APIをカタログ化して自社の情報資産としてしっかりと管理することが重要です。またAPIを利用させる際も無計画に利用させるのではなく流量制御や利用状況のモニタリング、そして第三者組織にAPIを公開する場合は課金なども考える必要があります。これらを行うためにはAPI管理機能が必要になります。OSSとしては3scaleという製品があります。

• 認証制御

認証の仕組みはマイクロサービス・アーキテクチャーを実現するためにはより重要性を増してきており、単一の認証方式を単一のシステムが利用する時代はすでに終焉を迎えています。複数の認証方式を複数のシステムが利用者の属性ごとに使い分ける時代になっています。これを可能にする認証制御機能が必要になります。OSSとしてはKeycloakという製品があります。

• イベントバス/データ・ストリーミング, CDC（チェンジ・データ・キャプチャー）

複数のシステムが生成するデータをシステム間でやりとりする方法は数多くありますが、ファイル連携では連携頻度に限界があるためデータ鮮度が問題となり、APIでは大容量のデータを扱うことに限界があるため、少量のデータを扱うことしかできない場合が多いでしょう。特定システムのデータ変更を検知してそれを吸いあげ（チェンジ・データ・キャプチャー）、ストリーミングで順次他のシステムに流すといったことが実現できるとシステム間の情報連携スピードはリアルタイム、ないしは準リアルタイムにまで高めることが可能となります。

またシステムが生成するデータを特定のイベントとみなし、イベントをトリガーに他のシステムで処理を実行する、といったイベント・バスとしての機能させるとイベント・ドリブンな処理が実現できます。OSSとしては、イベント・バス/データ・ストリーミングとしてはApache Kafka、CDCではDebeziumという製品があります。

• データ変換/プロトコル変換

複数のシステム間のデータ連携処理が実現できたとしても連携されたデータをそのまま自システム（自身の担当するシステム）で活用できることは稀です。データはシステムごとに最適な形で保存されていることがほとんどなので他システムのデータを自システムで活用するためには自システムに最適な形にデータ変換する必要があります。

またシステムごとにデータ連携の手法（プロトコル）は様々であるためシステム間でこれを合わせるためにプロトコル変換が必要なケースも多いでしょう。これらの処理は現状ではESB製品が担うことがほとんどだと思いますが、ESB自体が全てのシステムを仲介することになるので非常に高可用性の求められるミッション・クリティカル・システムに位置付けられることが多かったのではないでしょうか。

これらのデータ変換/プロトコル変換といった機能を実現するOSSとしてはApache Camelという製品があり、従来のESB製品とは異なり、ライブラリー・ベースの非常に軽量かつ機能ごとに細かく分離可能であるため、集約して一つの基盤として稼働させるのではなく特定機能単位に連携処理を分散配置の可能なことが特徴です。

なお、Apache Camelは前述したApache Kafkaと一緒に利用されることが多く、データ連携処理の強力な組み合わせとなります。

• アプリケーション・フレームワーク

アプリケーションを実装する時にアプリケーション・フレームワークを利用しないケースは現在ではほとんどないでしょう。JavaのフレームワークであればJava EE（Jakarta EE）やSpring Bootを利用することが多いのではないかと思います。

昨今ではこれに加えてQuarkusと呼ばれるOSSのアプリケーション・フレームワークが公開されています。これは低フットプリント、高速起動を売りにしておりコンテナで動作するアプリケーションに最適なフレームワークとなっています。

これまでご紹介してきたこれらの製品の関係性を概念図にまとめると以下のようになります。

そして、図の赤枠の製品は、実はRed Hat社が提供する『Red Hat Application Foundations』という単一サブスクリプションとして全部入りでサービスとして提供されて利用することが可能になっています。これらはオンプレミスまたはクラウドで実行されるアプリケーションで使用できるためハイブリッドクラウドを推進する強力なプロダクトです。

また、Red Hat OpenShiftと組み合わせると、アプリケーションのライフサイクル全体で実行を効率化するプラットフォームとして構成することもできるのです。言い換えれば、どのクラウドでもオンプレミスであってもAWS相当の機能を統一的なオペレーションで利用が可能になるということを意味しています。

このようにRed Hat OpenShiftとRed Hat Application Foundationsを組み合わせることで、ハイブリットクラウドを実現しながらクラウドネイティブ・アプリケーションを展開できるようになるのです。

まとめ

コンテナ技術（Red Hat OpenShift）は、それ単体でもお客様のビジネスの敏捷性に寄与する柔軟なワークロードや優れた標準化を提供します。しかしながら、そのさらに先に進むためにはクラウドネイティブなアプリケーションを実装し、よりビジネス価値を高めて競争優位性を確保していく必要があります。今回紹介したOSS群とそれを包括的にサポートするRed Hat Application Foundationsはこれらを強力に後押しする有効な選択肢と言えるでしょう。

どのように活用すべきか？それぞれを組み合わせてどのようなユースケースが出来るか？といったことにお悩みのお客様はぜひIBMにお声がけください。