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

このBlog postの目的

このBlog postはKymaの中心的な役割を担うApplication Connectorを少しだけ下のレイヤーから理解して頂くことを目的としています。Application Connectorは複雑な技術基盤から成り立っており、少なくとも、

• Service Discovery
• Service Mesh
• Function as a Service

という概念を、実現手段である具体的な技術と合わせて理解しないとどのような利点があるプラットフォームか実感できません。そのため本Blog postではApplication Connectorを理解するためにKymaを構成する技術要素をService Discovery、Service Mesh、Serverless Architectureという基礎概念と絡めて説明していきます。

尚、内容が少しだけ膨らんでしまったので前後半にBlogを分けることにします。本Blog postは前半パートであり、主にKymaを構成する上記概念について、基盤技術と絡めて説明します。後半パートはKyma Application Connectorについて詳細を見ていきたいと思います。

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

Kyma Application Connectorとは

Kymaとはサーバレス、マイクロサービスを使用したアプリケーションの拡張開発を容易にするプラットフォームです。KymaはKubernatesを基盤としたプラットフォームであり非機能要件である分散ログ/トレース、認証/認可、Cloud Foundryを踏襲したOpen Service Brokerの実装など、アプリケーションの拡張開発を可能にする多岐に渡る機能を有しています。こうしたリッチなアプリケーション開発基盤であるKymaの中心的な役割を担う機能がApplication Connectorです。まずはApplication Connectorの役割を簡単に説明してから詳細な技術要素の説明をしていくことにしましょう。

Application Connectorを使用した拡張シナリオは以下の2つのシナリオが考えられます。

Application Connectorの役割イメージ

1つ目は外部アプリケーションからEventを受けて動作するサービスメッシュアプリケーションシナリオです。ちなみにKymaで言う”外部アプリケーション”とはSAPの場合SuccessFactorsやS/４HANA CloudなどのLoB SaaSを念頭において頂ければ理解しやすいかと思います。なので、この場合はSuccessFactorsで発生したビジネスイベント、例えば従業員情報の新規登録を契機に何らかの処理を実現したい場合、Application Connectorは拡張アプリケーション基盤としてそのフックポイントを提供します。

2つ目はKyma内でアプリケーションを実装し、そのアプリケーションより外部アプリケーションをAPIコールするようなシナリオです。こちらは従来のCloudFoundryを使用した拡張アプリケーションと同等の使用方法です。主たる処理をKyma上で行い、外部アプリケーションにて処理すべき振る舞いをAPIコールを使用して実現します。

これら拡張アプリケーションをService brokerが提供するサービスを使用しながら実現する、それがApplication Connectorの役割です。

Kymaを構成する技術

少しだけ話を脱線します。Kymaはどのような技術から構成されているのでしょうか。結論から先に述べるとKymaは以下技術を基盤としたプラットフォームとなっています。

1. Kubernates
2. Istio
3. Knative

Kubernatesはコンテナオーケストレーション基盤、IstioはService Mesh基盤、KnativeはFaaS基盤とざっくりと理解している方は多いのではないでしょうか？しかし、これら基盤技術がServce Discovdry/Service Mesh/Function as a Serviceを具体的にどのように実現し、最終的にApplication Connectorとどのようにつながっているのかという疑問に明確に答えれる方は、特にSAPに関連するタスクを主な生業としているこのBlog postの読者の中にはほとんどいないのではないでしょうか？Application Connectorについて説明する本Blog postの前半パートのゴールはまさにここになります。Kubernates/Istio/Knativeという技術要素がどのようにServce Discovdry/Service Mesh/Function as a Serviceという概念を実現しているかを理解すること。ここがゴールです。ここを理解することでApplication Connectorがぐっと理解しやすくなり、明確な使い所も見えてくるはずです。それでは各技術要素について詳細な説明をしていくことにしましょう。

1. KubernatesによるService Discoveryの実現

あるContainer内で動作するApplication/Middlewareが、他Container上で動作するApplication/Middlewareを呼ぶときのことを想像してみましょう。Containerはいつ破棄されるかも分からずIPによる呼び出しは堅牢ではありません。またContainerの持つフレキシブルな特性を活かすため負荷に応じてContainer数を随意変更する場合、L/B的な役割を担う何かが必要になります。KubernatesではClusterIPと呼ばれるServiceがその役割を担います。Kubernatesは一般的にCluster内にDNSを持ち、ClusterIP Serviceを生成する際にそのService名称をDNSにAレコードとして保存します。また実際にAレコードを使用し、Service名称による呼び出しを行った際にはそのサービス配下にあるContainerに対して完全ラウンドロビンでルーティングを実施します。ここでのポイントは完全ラウンドロビンという点です。後段で説明するIstioを何故使用しなければならないかという点に繋がる大切なポイントなので完全ラウンドロビンである点はしっかりと覚えておいて下さい。イメージ的には以下のような形になります。

Service Discoveryのイメージ

2. IstioによるService Meshの実現

Istioの大きな特徴はTraffic Managementです。Envoyという軽量なProxyを使用してアプリケーションレイヤーで実装レベルの意識をすること無く複雑なルーティングを可能にします。ここでは主要な2つの機能を紹介します。

East – West trafficの制御

East – West trafficとはまさにClusterIPサービスの項で説明したContainer to Containerの呼び出しについてのネットワークトピックです。あるContainer内のApplication/Middlewareが、他Container上で動作するApplication/Middlewareを呼ぶ際にKubernatesではClusterIPを使用してService Discoveryを実現する旨上記で説明したかと思います。ただしClusterIP Serviceを使用した場合単純ラウンドロビンのみ対応という点を強調していたのを思い出してください。Istioを使用すると下記のようなClusterIP Serviceでは実現できなかったContainer to Containerの呼び出しに複雑なルールを設定することができます。

– Traffic Steering
HTTP Headerに含まれる文字列でルーティングを制御できます。例えば複数のバージョンのContainerが存在する場合、とある文言が含まれているHTTP RequestのみV1ラベルの貼ってあるContainerにルーティングすることが可能になります。

– Fault Injection
意図的にトラフィックに問題を起こします。例えば50%の確率でHTTP Responseの500を返却したり、50%の確率でわざと5秒のDelayを発生させたりすることが可能です。

– Traffic Shifting
任意の値で振り分け割合を変更できます。例えばv1ラベルの貼ってあるContainerに20%、v2ラベルの貼ってあるContainerに80%などのルーティング条件を設定することが可能です。主にA/Bテストなどで使用します。

– Request Timeout
処理の長い問題のあるContainerを切り離すために、任意の値でTimeoutエラーを発生させます。呼び出し側のContainer内アプリケーションのThread/Processが待ち状態になるのを防ぎます。

– Circuit Breaker
待ちが発生しているContainer呼び出し条件を指定し、HTTP Responseの503を返却するように出来ます。この機能により例えば待機待ちRequestの数を指定し、その値以上待ちが発生している状況を回避することが可能です。

– Outlier Detection
問題が発生しいてるContainerを切り離します。例えばHTTP Responseで503を任意の数以上返却したアプリケーションが動作するContainerは切り離し、ルーティング対象から外します。

– Mirroring
正式なルーティングとは別にテスト的なトラフィックを実現する機能です。例えばリリース前のv2ラベルの貼ってあるContainerに裏でトラフィックを発生させ、問題が起きないかテストすることが可能です。

Istio Ingress Gateway

KubernatesにはIngressというL7のL/Bに相当するServiceが存在し、Kubernates内のContainerはIngress経由で公開することが可能です。IstioはL4のL/B ServiceとIstio Ingress Gatewayという仕組みを使用して、L/7相当のトラフィックルーティングを上述したような細やかな内部ルーティングルールと合わせて使用可能です。

IstioIngress Gatewayイメージ

マイクロサービス(=Container)が複雑に絡み合い、1つのビジネス的に意味のある処理を実現するアーキテクチャをService Meshと言います。複雑なマイクロサービスの連鎖は、一つの不適切なサービスの存在が全体の処理を停止させてしまう可能性があるため、East – West trafficの制御、およびIstio Ingress Gatewayの項で説明した複雑なルーティングのルールを設定することが必要条件となります。IstioはKubernatesでは実現不可能なこうした複雑なルーティングルールの設定を可能にし、Service Meshを実現する基盤となります。

3. KnativeによるFunction as a Serviceの実現

Knativeは大きく分けてServingとEventingという機能に分けられます。これら機能を利用してFunction as a Serviceがどのように実現されているかを説明していきます。

Serving

Function as a Serviceの一番のメリットは何でしょうか？それはフレキシブルなContainer構成が実現出来る点です。具体的な仕組みとしてはPaaS事業者が実際の負荷に応じて、全く負荷の無い時にはContainerを0に、負荷が増えてきたら最適なContainer数に調整する仕組みを提供します。負荷が無い場合Containerが0になるので、例えば必ず1つのContainerは動き続けるCloud FoundryのLRPと比べて大きなコストメリットがあります。
KubernatesにはHorizontal Pod AutoscalerというPod数を自動調整するリソースがありますが、0待機Containerの実現は出来ません。一方KnativeにはKnative Pod Autoscalerというリソースがあり、このリソースを使用することでHorizontal Pod Autoscalerでは実現負荷だった0待機Containerの実現が可能です。
またネットワークルーティングにIstioを使用しているため前述したIstio Ingress Gatewayの機能を享受することができます。これらの仕組みはKnative ServiceというCRDにて管理されます。（KubernatesのServiceとは別のリソースなので注意して下さい。Knative ServiceをApplyすると結果Kubernates Serviceが生成されますが詳細な説明についてはここでは省くことにします。）
こうしたFunction as a Serviceを実現するためのフレキシブルなContainer構成を実現するためのメカニズムがServingです。詳細には踏み込みませんが以下図のqueue-proxyで収集した情報を元にKnative ActivatorがScale-out/in命令をKnative Pod Autoscalerに送信します。この一連の仕組みをServingと呼びます。

Servingのイメージ

Eventing

Servingで実装したFunction as a Serviceの仕組みを呼ぶための機構です。下記図を使用して簡単に仕組みを説明します。

Eventingのイメージ

– Source CRD
Event自体を定義するCRDです。分かりやすいSource CRDはCron CRDで上記Servingで実装したFunction as a Serviceで実装した処理を呼ぶ時間/頻度をCron形式で指定します。Cron CRDの他にAWS SQS、Apache Camel、GitHubなどに対応したCRDが用意されており、各システムのEventに対応した処理が一旦Default Brokerという名前のQueueに格納されます。Broker自体はURLを持っており、Sourceとは別のルートとして直接HTTPベースのリクエストを発行することでEventをQueueに格納することが可能です。尚、Eventは全てCloudEventsに準拠した形で処理されます。

– Trigger CRD
TriggerはQueueに格納されたEventを誰が処理するかを指定するCRDです。Triggerが指定できるリソースとしてKubernatesのIP Clusterサービス、もしくはKnativeのServingの項で説明したKnative Serviceどちらかになります。

前半のまとめ

このBlog postではまずApplication Connectorの役割/振る舞いを理解する上で必要な、

• Service Discovery
• Service Mesh
• Function as a Service

についてKymaの技術基盤であるKubernates/Istio/Knativeと絡めて説明しました。後半では実際にApplication Connector内でこれらの仕組みが具体的にどのように使用されているか詳細な説明をする予定です。それでは楽しいSAP開発ライフを！