Kymaによるアプリケーション拡張開発: Application Connectorを理解する（後編）

前半パートの振り返り

このBlog postはKymaの中心的な役割を担うApplication Connectorを少しだけ下のレイヤーから理解して頂くことを目的としています。そのため前半パートでは、

• Service Discovery
• Service Mesh
• Function as a Service

という概念がKymaの構成技術であるKubernates/Istio/Kymaによってどのように実現されているかを説明してきました。後半パートではこれら技術要素がどのようにApplication Connectorと関連しているかについて細かくみていきましょう。

前半パートはこちらから。

Kyma Functionとは

Application Connectorについて詳細な説明をする前に、Application Connectorで重要な役割を担うKymaのFunctionという機能についてまずは説明します。
KnativeのServingで説明したFunction as a ServiceはビジネスロジックをDocker imageにて作成する必要がありました。最終的にKnative Pod AutoscalerがKubernatesのPodに対してScale-in/outしていたのを思い出してください。Docker imageを運用するためにはSecureで軽量なContainerを保ち続けるインフラーレイヤーのタスクが必須です。こうした環境を保ち続けるためには開発以外のContainer技術に長けた技術者のアサインが一般的には必要になります。一方でSAP CPのServerless基盤であるFunctionsを思い浮かべて下さい。Functionsはブラウザ上でNode.jsベース/Pythonのアプリケーションを記述するだけでFunction as a Serviceが実現され、Containerレイヤーの心配は一切不要です。
Kymaでも同様の仕組みをFunction CRDを使用して実現します。Function CRDに直接ロジックを記述、もしくはブラウザベースのEditorでロジックを記述するだけでFunction as a Serviceが実現されます。またAPI RuleというCRDを使用してFanctionsで実装したビジネスロジックを簡単に外部公開することも可能です。Kyma FunctionとAPI RuleはAWSのLambdaとAPI GatewayをKubernates上で実現したものと思えば理解も容易いかと思います。尚、API GatewayはFunctionだけではなくKubernatesのPodを外部公開する際にも利用可能です。具体的なイメージは以下のようになります。

API Ruleのイメージ

ここでのポイントはKymaのFunction as a Service機能そのものはKnative Servingの機能を使用しているわけではない点です。それではKnativeはいったいどのようにApplication Connectorで使用されているのでしょうか？Knativeの使い所はApplication Connectorの詳細にて細かく説明するとして、Functionの説明の最後にKyma FunctionとKnative Servingの違いについて簡単にまとめておきます。

• Kyma FunctionはKnativeを使用せず独自のServeless機構をKubernatesのHorizontal Pods Autoscalerを使用して実現している
• Kyma FunctionはDocker imageを用意するのではなくLambda/SAP CP FunctionsのようにNode.js/PythonベースのアプリケーションをCRD内に宣言することでFunction as a Serviceを実現している

Application Connectorを理解する

Kubernates/Istio/Knative/Kyma Functionの説明を少々細かめにさせて頂き、やっと本題のApplication Connectorの詳細説明に入っていきます。再掲になりますがApplication Connectorを使用したアプリケーション拡張シナリオ以下図のように2つのシナリオが考えられます。

Application Connectorの役割イメージ

1. 外部アプリケーションからのEventにより呼び出されるEventドリブンシナリオ
2. 外部アプリケーションに対してAPI経由でやり取りを行うAPIコールシナリオ

それではApplication Connectorのこの2つのシナリオについてそれぞれ詳細に説明していきましょう。

1. Eventドリブンシナリオ

Eventドリブンシナリオを実施するためにKyma上で行う作業は大まかには以下の通りになります。

1. Applicationリソースを作成する
2. 作成されたApplicationにEventを登録する
3. 登録されたEventをEventドリブンシナリオを実行するNamespaceにBindする
4. 3の作業により作業Namespace上にEventがService brokserのサービスクラスとして登録されるのでインスタンス化する
5. Eventドリブンアプリケーションを実装する
6. 5のアプリケーションをKnative triggerを使用して紐付ける。
7. Application毎にEvent呼び出し用Endpointが生成されるので、外部アプリケーションからEvent都度コールしてEventドリブンシナリオを実行する

具体例をあげた方がイメージしやすいと思うので例えばSuccessFactorsのテナントより従業員情報変更都度、EventドリブンでKyma上のアプリケーションを動かしたい場合は以下のような作業が必要です。但しSAPのKymaを使用する場合下記のようなマニュアルでのイベント登録は行わず、Formationの機能を使用した自動登録手段を採ります。あくまでイメージしやすいようマニュアル登録例としている点ご注意下さい。尚、下記ステップの各番号は上記ステップ番号に対応しています。

1. ApplicationはSuccessFactorsのテナント毎に登録します。これはSuccessFactorsテナントを抽象化するリソースです。
2. 従業員情報変更EventをCloudEventに沿ったPayload情報と共に1で作成したSuccessFactorsアプリケーションに登録します。
3. 従業員情報変更Eventを作業NamespaceにBindします。
4. 従業員情報変更Eventが作業Namespace上のService brokerクラスとして登録されているのでインスタンス化します。この作業はCloud Foundry環境でcf create-serviceするのと同等の作業になります。
5. 後述します。
6. 5のアプリケーションを作業Namespace上にKnative triggerを使用して紐付けます。
7. SuccessFactorsの該当テナントにてIntegration Centerを使用してKyma上のApplication毎に作成されたEventコールEndpointを従業員情報変更Eventに紐付けます。

Kyma上の作業としては上記を行うわけですが、技術的にはどのような形でEventドリブンアプリケーションを実現しているのでしょうか？詳細なテクニカル処理フローは以下の図のようになっています。ここではApplication名をota-system-prd、API名をota-function-event-v1として登録している例になります。この図を使ってどのようにIstio/KnativeがKymaで使用されているのか見ていきましょう。

Application Connector – Eventドリブンシナリオの処理フロー

Applicationリソースを作成するとApplication毎のEventコールEndpointが生成される点は上記した通りです。Application CRDを適用する作業を終了した時点で処理フロー1から5までが全て準備される形となるのですが処理フロー毎に少し補足しておきます。

– 処理フロー1から3まで
まずは処理フロー1から3についてです。Istioについて主に2つの機能を前編パートで説明しました。1つがEast – West trafficの制御でもう1つがIstio Ingress Gatewayでした。外部に処理を公開する際、Istioを使用する場合L7相当の機能がIngress Istio Gatewayという仕組みを使用して実現しているという説明を覚えているでしょうか？処理フロー1から3はまさにIngress Istio Gatewayそのものです。Kymaを使用するとApplication CRDを適用するだけでいくつものCRDから成り立っているIngress Istio Gatewayが使用可能になります。

– 処理フロー4
EventコールEndpointはX.509のクライアント証明書を使用してのみアクセス可能です。処理フロー4ではクライアント証明書が妥当性のあるものかをチェックする役割を担います。

– 処理フロー5
Knativeの仕組みを使用したKnative channelに送信されます。KymaのDefault実装はNATS streaming serverです。Channelについて詳細な説明はしてきていませんが、ここではQueueのようなものとしてイメージして頂ければ良いかと思います。このChannelはKymaのグローバルNamespaceであるkyma-integrationに配置されます。即ちこの時点ではEventメッセージがグローバル領域にQueueingされている事を意味します。

– 処理フロー6
作業Namespaceに登録EventをBindし、Service Brokerクラスをインスタンス化します。この作業によりKnativeのDefault brokerが作業Namespaceに作成されます。

– 作業フロー7
KnativeのDefault brokerからEventメッセージングを取り出す際Trigger CRDを使用した事を覚えているでしょうか？Knative Trigger CRDでSourceを指定することで上記Default brokerにEvenrメッセージが格納され、また格納されたEventメッセージをSubscriber属性でビジネスロジックに紐付けることが可能になります。

– 作業フロー8
作業フロー7で指定するビジネスロジックはどのように実装すれば良いのでしょうか？後述するとしていたEventドリブンアプリケーションの実装方法の答えにもなります。
前半パートで説明したKnativeのTriggerが指定出来るリソースを思い出してください。Trigger CRDが指定出来るリソースはKubernatesのIP Clusterサービス、およびKnative serviceでした。Kyma環境でも当然これら２つの選択肢を採ることが出来ます。これが答えになります。但し、Kymaの場合もう一つ選択肢があります。それは上述したKyma functionです。Kyma functionは最終的にKubernatesの同名のIP Clusterサービスを生成します。従ってKyma内のTriggerではKymaのFunctionを選択することによりEvenドリブン拡張アプリケーションをFunction as a Serviceとして利用可能なのです。イメージ的には以下のようになります。

アプリケーション実装ポイントのイメージ

2. APIコールシナリオ

Application Connectorのもう一つのシナリオであるAPIコールシナリオを見ていきましょう。APIコールシナリオを実施するためにKyma上で行う作業は大まかには以下の通りになります。

1. Applicationリソースを作成する
2. 作成されたApplicationにAPIを登録する
3. 登録されたAPIをAPIコールを実装するアプリケーションが(Podとして)DeployされるNamespaceにBindする
4. 3の作業により作業Namespace上にAPIがService brokserのサービスクラスとして登録されるのでインスタンス化する
5. APIコールアプリケーションを実装する
6. 5のアプリケーションにService bindingを行う
7. Cloud Foundry同様Service bindingすると関連情報が環境変数より取得出来るので、その情報を利用してAPIコールを行う

それではEventドリブンシナリオと同様処理フローを元に上記作業がどのような形でAPIコールシナリオを技術的に実現しているかを見ていきましょう。尚、説明の都合上処理フロー番号が下からとなっている点に注意して下さい。

Application Connector – APIコールシナリオの処理フロー

Application CRDを適用するのはEventドリブンシナリオと同じなのでそれ以降の処理を補足説明していきます。APIコールシナリオもEventドリブンシナリオ同様に外部アプリケーションをS/4 HANA CloudやSuccessFactorsなどLoB SaaSを念頭に置いてに読み進めて下さい。

– 処理フロー1
EventドリブンシナリオでEventを登録するのと同様S/4 HANA CloudやSuccessFactorsのEndpoint APIの情報を登録します。Event登録と異なる点は認証情報も登録可能な点です。サポートされる認証方式は以下になります。

• 基本認証
• OAuth Client Credential
• X.509クライアント証明認証

– 処理フロー2
Endpoint API登録後、Eventを登録した時と同様に登録されたAPIをNamespaceにBindし、Serivce Brokerクラスをインスタンス化します。インスタンス化したサービスはKubernatesのDeployment，およびKyma functionにサービスバインドが可能になります。バインドされたサービスはCloud Foundry同様環境変数としてアプリケーション内から参照可能です。以下Kyma FuntionにBindした際のソースコードの抜粋です。

   const request = require('request');
    module.exports = { main: function (event, context) {
        return new Promise((resolve, reject) => {
            const url = \`http://\${process.env.GATEWAY_URL}/uuid\`;
            const options = {
                url: url,
            };
            sendReq(url, resolve, reject)
        })
    } }

環境変数GATEWAY_URLからターゲットとなるAPIをコールするApplication GatewayのFQDNを取得しているのが分かるかと思います。API呼び出し元のアプリケーションはこのように必ずサービスバインディングした結果取得可能なApplication Gateway経由で外部へAPIコールを行います。
その理由は処理フロー1で説明した認証関連設定です。上記ソースコードには認証関連情報の記述がありません。Application Gatewayが処理フロー1で付与した認証関連情報を基に認証処理を行なうのでアプリケーション側は認証処理を記述する必要がないのです。これはSAP CPのDestinationサービスの役割に近い仕組みです。以下図はKyma FunctionよりApplication Gateway経由で外部アプリケーションのAPIを呼び出しているイメージになります。

Application Gateway経由で外部APIコールをするイメージ

– 処理フロー3
上記したようにAPIサービスインスタンスはKubernatesのDeployment，およびKyma Functionにバインド可能です。従ってAPIコールシナリオアプリケーションは通常のPod、もしくはKyma Function上に実装することになります。API Ruleと組み合わせることで例えば外部からFunction as a Serviceアーキテクチャでアプリケーションを実装し、そのアプリケーションからさらにAPIコールシナリオを使用したAPI呼び出しすることが可能になります。具体的なイメージは以下のようになります。

アプリケーション実装ポイントのイメージ

まとめ

Application Connectorの2つのシナリオについて説明してきましたが以下の特徴について特にまとめとして最後に強調しておきます。

1. 外部からのルーティングはIstioを使用する
2. アプリケーションの実装ポイントとしてはKyma Function、Knative ServiceといったFunction as a Serviceを採ることが出来る
3. Application ConnectorとKyma Functionを採用した場合、Kubernates/Istio/Kymaといった下のレイヤーの技術について意識することなく高度なアプリケーション拡張が可能
4. (Option)IstioがBuild-inインストールされているのでApplication Connectorのビジネスロジックを実装する際にはEast – West traffic制御の仕組みをそのまま活用出来る。即ち実装アーキテクチャとしてService meshが実現可能

KymaはApplicaiton拡張基盤である事は何度も説明している通りです。しかしその設計思想にはまずはコンテナアプリケーションのプラットフォームであるという点、次いでService Discorvery/Service Mesh/Function as a Serviceという概念がKubernates/Istio/Knativeという技術基盤によって実現しているという点が根底にあることは忘れていはいけません。Application Connectorを使用する場合、低いレイヤーの技術を意識することなく拡張アプリケーションを実装可能であるのは間違いありません。但し、そうした低いレイヤーの技術や設計思想を良く知ることがKymaの使い所についての正しい理解、延いてはKyma上の拡張アプリケーションについての正しい設計に繋がるのではと思い本Blog postを書かせて頂きました。それでは楽しいSAP開発ライフを！