クラウドネイティブにおける技術進化の機会と課題

現在、クラウドネイティブはますます人気が高まっており、CNCFはクラウドネイティブを以下のように定義しています：

モダンでダイナミックな環境、つまりクラウド環境を基盤としている。
コンテナ化を基本技術とし、Service Mesh、不変インフラストラクチャ、宣言型APIなどを含む。
主な特徴として、自動スケーリング、管理性、可観測性、自動化、頻繁な変更などが挙げられる。

CNCFの2021年調査によると、Kubernetesコミュニティには非常に多くの貢献者（62,000人以上）がいます。現在の技術トレンドに従い、ますます多くの企業がクラウドネイティブにコストを投資し、早期にクラウド展開のトラックに参加しています。なぜ企業は開発中にクラウドネイティブを取り入れ、クラウドネイティブは彼らにとって何を意味するのでしょうか？

クラウドネイティブの技術的優位性

クラウドネイティブの人気は、技術レベルでの優位性に由来します。クラウドネイティブ技術には、Dockerが主導するコンテナ化と、Kubernetesが主導するコンテナオーケストレーションの2つの主要な側面があります。

Dockerは技術界にコンテナイメージを導入し、コンテナイメージを標準化された配信単位にしました。実際、Docker以前にもコンテナ化技術は存在していました。2008年のLXC（Linux Containers）について話しましょう。Dockerと比較して、LXCはあまり人気がありませんでした。なぜなら、Dockerはコンテナイメージを提供し、より標準化され、移行が容易になったからです。また、DockerはDockerHubというパブリックサービスを作り、世界最大のコンテナイメージリポジトリになりました。さらに、コンテナ化技術は一定のリソース分離も実現できます。CPUやメモリなどのリソース分離だけでなく、ネットワークスタックの分離も可能で、これにより同じマシン上でアプリケーションの複数のコピーを簡単にデプロイできます。

KubernetesはDockerの隆盛により人気を博しました。Kubernetesが主導するコンテナオーケストレーション技術は、障害自己修復、リソーススケジューリング、サービスオーケストレーションなど、いくつかの重要な機能を提供します。KubernetesにはDNSベースのサービスディスカバリメカニズムが組み込まれており、そのスケジューリングアーキテクチャのおかげで、サービスオーケストレーションを迅速に拡張できます。

現在、ますます多くの企業がKubernetesを積極的に採用し、アプリケーションを変換してKubernetesデプロイメントに乗り出しています。そして、私たちが話しているクラウドネイティブは、実際にはKubernetesを前提としたクラウドネイティブ技術の基盤です。

コンテナ化の利点

標準化された配信

コンテナイメージは現在、標準化された配信単位となっています。コンテナ化技術により、ユーザーはバイナリやソースコードではなく、コンテナイメージを通じて直接配信を完了できます。コンテナイメージのパッケージングメカニズムに依存することで、同じイメージを使用してサービスを起動し、どのコンテナランタイムでも同じ動作を生成できます。

ポータブルで軽量、コスト削減

コンテナ化技術はLinuxカーネルの機能によって一定の分離を実現し、それにより移行が容易になります。さらに、コンテナ化技術はアプリケーションを直接実行できるため、仮想化技術と比較して技術的実装が軽量で、仮想マシン内のOSを必要としません。

すべてのアプリケーションがカーネルを共有できるため、コストが削減されます。そして、アプリケーションが大きいほど、コスト削減の効果も大きくなります。

リソース管理の利便性

コンテナを起動する際に、コンテナサービスが使用できるCPU、メモリ、またはディスクIOのプロパティを設定できます。これにより、コンテナを通じてアプリケーションインスタンスを起動する際に、リソースの計画とデプロイがより容易になります。

コンテナオーケストレーションの利点

ワークフローの簡素化

Kubernetesでは、アプリケーションのデプロイがDockerよりも管理しやすくなります。なぜなら、Kubernetesは宣言型設定を使用しているからです。例えば、ユーザーは設定ファイルでアプリケーションが使用するコンテナイメージや公開するサービスポートを宣言するだけで、追加の管理は必要ありません。宣言型設定に対応する操作により、ワークフローが大幅に簡素化されます。

効率向上とコスト削減

Kubernetesのもう一つの優れた機能はフェイルオーバーです。Kubernetes内のノードがクラッシュした場合、Kubernetesは自動的にそのノード上のアプリケーションを他の正常なノードにスケジュールし、それらを起動して実行します。この回復プロセス全体に人的介入や操作は必要ないため、運用レベルの効率が向上するだけでなく、時間とコストも節約できます。

DockerとKubernetesの台頭により、アプリケーション配信に大きな革新と機会がもたらされたことがわかります。コンテナイメージは標準配信単位として、配信プロセスを短縮し、CI/CDシステムとの統合を容易にします。

アプリケーション配信がますます速くなっていることを考えると、アプリケーションアーキテクチャはクラウドネイティブのトレンドにどのように追随しているのでしょうか？

アプリケーションアーキテクチャの進化：モノリス、マイクロサービスからService Meshへ

アプリケーションアーキテクチャの進化の出発点は、依然としてモノリシックアーキテクチャです。アプリケーションの規模と要件が増大するにつれて、モノリシックアーキテクチャはチーム開発のニーズを満たさなくなり、分散アーキテクチャが徐々に導入されました。

分散アーキテクチャの中で最も人気があるのはマイクロサービスアーキテクチャです。マイクロサービスアーキテクチャはサービスを複数のモジュールに分割し、それらが互いに通信し、サービス登録とディスカバリを完了し、流量制限やサーキットブレーカーなどの共通機能を実現します。

さらに、マイクロサービスアーキテクチャにはさまざまなパターンが含まれています。例えば、サービスごとのデータベースパターンは、各マイクロサービスに個別のデータベースを割り当てることで、アプリケーションに対するデータベースレベルの影響を回避しますが、より多くのデータベースインスタンスを導入する可能性があります。

もう一つはAPI Gatewayパターンで、クラスタまたはマイクロサービスアーキテクチャ全体の入口トラフィックをゲートウェイで受け取り、APIを通じてトラフィックを分散します。これは最も使用されるパターンの一つで、Spring Cloud GatewayやApache APISIXなどのゲートウェイ製品が適用できます。

人気のあるアーキテクチャは徐々にクラウドネイティブアーキテクチャに拡張されています。クラウドネイティブの下でのマイクロサービスアーキテクチャは、元のマイクロサービスをコンテナイメージとして構築し、直接Kubernetesに移行できるのでしょうか？

理論的には可能に見えますが、実際にはいくつかの課題があります。クラウドネイティブのマイクロサービスアーキテクチャでは、これらのコンポーネントはコンテナ内で実行されるだけでなく、サービス登録、ディスカバリ、設定などの他の側面も含まれます。

移行プロセスにはビジネスレベルの変換と適応も含まれ、認証、認可、可観測性関連の機能（ロギング、モニタリングなど）をK8sに移行する必要があります。したがって、元の物理マシンデプロイメントからK8sプラットフォームへの移行は、それよりもはるかに複雑です。

この場合、Sidecarモデルを使用して上記のシナリオを抽象化し簡素化できます。

通常、SidecarモデルはSidecar Proxyの形で提供され、以下の図の左側から右側に進化し、いくつかの汎用機能（認証、認可、セキュリティなど）をSidecarにシンクします。図からわかるように、このモデルは複数のコンポーネントを維持する必要がある状態から、2つのもの（アプリケーション + Sidecar）を維持するだけで済むように適応されています。同時に、Sidecarモデル自体にはいくつかの共通コンポーネントが含まれているため、ビジネス側で維持する必要がなく、マイクロサービス間の通信の問題を簡単に解決できます。

sidecar

各マイクロサービスにSidecarを導入する際の個別設定や車輪の再発明を避けるために、コントロールプレーンを導入するか、コントロールプレーン注入によってプロセスを実装できます。これにより、現在のService Meshが徐々に形成されます。

Service Meshには通常、コントロールプレーンとデータプレーンの2つのコンポーネントが必要です。コントロールプレーンは設定の配布と関連ロジックの実行を完了します。例えば、現在最も人気のあるIstioがあります。データプレーンでは、Apache APISIXのようなAPIゲートウェイを選択して、トラフィック転送とサービス通信を行えます。APISIXの高性能と拡張性のおかげで、いくつかのカスタマイズ要件やカスタムロジックも実行できます。以下は、Istio+APISIXを使用したService Meshソリューションのアーキテクチャを示しています。

このソリューションの利点は、以前のマイクロサービスアーキテクチャからクラウドネイティブアーキテクチャに移行する際に、Service Meshソリューションを直接使用することで、ビジネス側での大規模な変更を回避できることです。

クラウドネイティブの技術的課題

前の記事では、現在のクラウドネイティブトレンドの技術面でのいくつかの利点について述べました。しかし、すべてのコインには両面があります。いくつかの新鮮な要素と機会がもたらされる一方で、特定の技術の参加により課題も生じます。

コンテナ化とK8sによる問題

記事の冒頭で、コンテナ化技術は共有カーネルを使用し、共有カーネルは軽量さをもたらすが、分離の欠如を引き起こすと述べました。もしコンテナエスケープが発生した場合、対応するホストが攻撃される可能性があります。したがって、これらのセキュリティ課題に対応するために、セキュアコンテナなどの技術が導入されています。

さらに、コンテナイメージは標準化された配信方法を提供しますが、サプライチェーン攻撃などの攻撃を受けやすいです。

同様に、K8sの導入もコンポーネントセキュリティの課題をもたらしました。コンポーネントの増加により攻撃面が増加し、基盤となるコンポーネントや依存関係レベルに関連する追加の脆弱性が生じます。インフラストラクチャレベルでは、従来の物理マシンや仮想マシンからK8sへの移行には、インフラストラクチャ変換コストと、クラスタデータのバックアップ、定期的なアップグレード、証明書の更新を行うための追加の人的コストがかかります。

また、Kubernetesアーキテクチャでは、apiserverはクラスタのコアコンポーネントであり、すべての内外のトラフィックを処理する必要があります。したがって、境界セキュリティの問題を回避するために、apiserverをどのように保護するかが重要な問題となります。例えば、Apache APISIXを使用して保護できます。

セキュリティ

新しい技術の使用には、セキュリティレベルでの追加の注意が必要です：

ネットワークセキュリティレベルでは、Network Policyを使用してトラフィックの細かい制御を実装するか、mTLSなどの他の接続暗号化方法を使用してゼロトラストネットワークを形成できます。
データセキュリティレベルでは、K8sは機密データを処理するためのsecretリソースを提供しますが、実際には安全ではありません。secretリソースの内容はBase64でエンコードされているため、Base64デコードを通じて内容にアクセスできます。特にetcdに配置されている場合、etcdにアクセスできれば直接読み取ることができます。
権限セキュリティレベルでは、RBAC設定が合理的でない場合、攻撃者が関連するTokenを使用してapiserverと通信し、攻撃の目的を達成する状況もあります。この種の権限設定は、コントローラやオペレータのシナリオで多く見られます。

可観測性

クラウドネイティブのシナリオのほとんどは、ロギング、モニタリングなどの可観測性関連の操作を含みます。

K8sでは、さまざまな方法でログを収集する場合、各K8sノードで直接集約して収集する必要があります。この方法でログを収集する場合、アプリケーションは標準出力または標準エラーにエクスポートする必要があります。

しかし、ビジネスが関連する変更を行わず、依然としてすべてのアプリケーションログをコンテナ内のファイルに書き込むことを選択した場合、各インスタンスでログ収集のためにSidecarが必要になるため、デプロイメントアーキテクチャが非常に複雑になります。

アーキテクチャガバナンスレベルに戻ると、クラウドネイティブ環境でのモニタリングソリューションの選択もいくつかの課題をもたらします。ソリューション選択が間違っていると、その後の使用コストが非常に高くなり、方向性が間違っていると損失が大きくなります。

また、モニタリングレベルでは容量の問題も関わります。K8sでアプリケーションをデプロイする際に、レートリミットを設定してアプリケーションが使用できるリソースの詳細を制限できます。しかし、K8s環境では、リソースの過剰販売、リソースの過剰使用、メモリのオーバーフローが発生しやすいです。

さらに、K8sクラスタ内でクラスタ全体またはノードのリソースが枯渇する状況も発生し、リソースの退避が行われます。これは、ノード上で実行されているリソースが他のノードに退避されることを意味します。クラスタのリソースが逼迫している場合、ノードストームが発生するとクラスタ全体がクラッシュする可能性があります。

アプリケーション進化とマルチクラスタパターン

アプリケーションアーキテクチャ進化レベルでは、コアの問題はサービスディスカバリです。

K8sはデフォルトでDNSベースのサービスディスカバリメカニズムを提供しますが、ビジネスにクラウドビジネスとストックビジネスの共存が含まれる場合、DNSサービスディスカバリメカニズムを使用して状況に対処するのはより複雑です。

一方、企業がクラウドネイティブ技術を選択すると、ビジネス規模の拡大に伴い、マルチノード処理の方向を徐々に検討し、それによりマルチクラスタの問題が関わります。

例えば、複数のクラスタを通じて顧客に高い可用性モデルを提供したい場合、この時には複数のクラスタ間のサービスオーケストレーション、マルチクラスタの負荷分散と同期設定、マルチクラウドとハイブリッドクラウドシナリオでのクラスタの処理とデプロイ戦略が関わります。これらは直面するいくつかの課題です。

APISIXがデジタルトランスフォーメーションを実現する方法

Apache APISIXはApache Software Foundationの下にあるクラウドネイティブAPIゲートウェイで、動的、リアルタイム、高性能であり、ロードバランシング、動的上流、カナリアリリース、サーキットブレーカー、認証、可観測性などの豊富なトラフィック管理機能を提供します。Apache APISIXを使用して、従来の南北トラフィックだけでなく、サービス間の東西トラフィックも処理できます。

現在、上記のアーキテクチャ進化とアプリケーション変更に基づいて、APISIXベースのIngressコントローラとService MeshソリューションもApache APISIXで派生し、企業がデジタルトランスフォーメーションをより良く実施するのを支援しています。

APISIX Ingressソリューション

Apache APISIX Ingress Controllerは、主にKubernetesの南北トラフィックを処理するトラフィックゲートウェイとして機能するKubernetes Ingress Controllerの実装です。

APISIX Ingress ControllerのアーキテクチャはAPISIXと同様に、コントロールプレーンとデータプレーンの分離されたアーキテクチャです。この場合、APISIXは実際のトラフィック処理のためのデータプレーンとして使用されます。

現在、APISIX Ingress Controllerは以下の3つの設定方法をサポートし、すべてのAPISIXプラグインと互換性があります：

K8sネイティブのIngressリソースをサポート。このアプローチにより、APISIX Ingress Controllerはより高いレベルの適応性を持ちます。これまで、APISIX Ingress Controllerはオープンソースで影響力のあるIngressコントローラ製品の中で最もサポートされているバージョンです。
カスタムリソースの使用をサポート。現在のAPISIX Ingress Controllerのカスタムリソースは、APISIXのセマンティクスに従って設計された一連のCRD仕様です。カスタムリソースを使用することで、APISIXとの統合が容易になり、よりネイティブになります。
Gateway APIをサポート。次世代のIngress標準として、APISIX Ingress ControllerはGateway API（ベータ段階）のサポートを開始しました。Gateway APIが進化するにつれ、K8sの組み込みリソースになる可能性があります。

APISIX Ingress ControllerはIngress NGINXと比較して以下の利点があります：

アーキテクチャの分離。APISIX Ingressでは、データプレーンとコントロールプレーンのアーキテクチャが分離されています。トラフィック処理の圧力が高く、容量を拡張したい場合、データプレーンの拡張を簡単に行うことができ、コントロールプレーンに何の調整も必要とせずに、より多くのデータプレーンを外部に提供できます。
高い拡張性とカスタムプラグインのサポート。
データプレーンとしての選択肢で、高性能で完全に動的な機能を持つ。APISIXの完全に動的な機能のおかげで、APISIX Ingressを使用してビジネストラフィックを可能な限り保護できます。

現在、APISIX Ingress Controllerは世界中の多くの企業で使用されています。例えば、China Mobile Cloud Open Platform（オープンAPIとクラウドIDE製品）、Upyun、Copernicus（Europe's Eyes on Earthの一部）などです。

APISIX Ingress Controllerはまだ継続的にイテレーションされており、以下の方法でより多くの機能を改善する予定です：

Gateway APIの完全サポートにより、より多くのシナリオ設定を可能にします。
外部サービスプロキシのサポート。
複数のレジストリのネイティブサポートにより、APISIX Ingress Controllerをより多目的にします。
アーキテクチャの更新により、新しいアーキテクチャモデルを作成します。
Argo CD/FluxなどのGitOpsツールと統合し、豊富なエコシステムを作成します。

APISIX Ingressソリューションに興味がある場合は、コミュニティの更新をフォローして、製品のイテレーションとコミュニティの動向を確認してください。

APISIX Service Meshソリューション

現在、APIゲートウェイとIngressソリューションに加えて、APISIXベースのService Meshソリューションも積極的にイテレーションされています。

APISIXベースのService Meshソリューションは、主にコントロールプレーンとデータプレーンの2つのコンポーネントで構成されています。コントロールプレーンにはIstioが選択されました。なぜなら、Istioは業界のリーダーであり、活発なコミュニティと複数のベンダーのサポートがあるからです。データサイドでは、Envoyを置き換えるためにAPISIXが選択され、APISIXの高性能と拡張性を発揮できます。

APISIXのService Meshはまだ積極的に追求されており、以下の方向で今後のイテレーションが計画されています：

eBPFアクセラレーションを実行し、全体の効果を向上させます。
プラグイン機能の統合を実行し、Service Meshアーキテクチャ内でAPISIX Ingressの機能をより良く活用できるようにします。
シームレスな移行ツールを作成し、ユーザーにとってプロセスを簡素化するためのより簡単なツールを提供します。

一般的に、クラウドネイティブ時代のアーキテクチャと技術の進化は、私たちに機会と課題の両方をもたらします。Apache APISIXはクラウドネイティブゲートウェイとして、クラウドネイティブトレンドに適応し、統合するための技術的適応と統合に取り組んでいます。APISIXベースのさまざまなソリューションも、企業ユーザーがデジタルトランスフォーメーションを実施し、クラウドネイティブトラックにスムーズに移行するのを支援し始めています。