From Kubernetes to Serverless

1. K8S が Serverless にもたらすもの

Kubernetes はコンテナベースのスケジューリングエンジンです。初期のコンテナベース技術には LXC、Cgroup などが含まれていました。2013 年の Docker プロジェクトのオープンソース化は、コンテナ技術の成熟とコンテナイメージ標準の誕生を象徴する出来事でした。

コンテナイメージ標準が誕生する以前、業界ではシステムを関心事ごとに分割するという考え方は浸透していませんでした。システムはインフラストラクチャ指向であると考えられていました。コンテナイメージ標準の誕生は、システムが二つの関心事に従って分割されることを意味します。一つはアプリケーション指向、もう一つはインフラストラクチャ指向です。アプリケーション指向がコンテナイメージであり、インフラストラクチャ指向がカーネルです。コンテナイメージの登場により、コンテナベースのデプロイメントエコロジーは継続的に改善できるようになりました。

2014 年に Kubernetes プロジェクトが誕生し、同年に Lambda がリリースされ、サーバーレスのさらなる商用化が進みました。2016 年の CNCF クラウドネイティブ財団の設立は、Kubernetes エコロジーの徐々に成熟していく過程を示しています。2018 年には Knative と Alibaba Serverless アプリケーションエンジンがリリースされ、Kubernetes ベースのサーバーレスの商用化が実現しました。

CNCF の枠組みの下、多くの Kubernetes エコロジープロジェクトが誕生し、急速に発展しています。

Kubernetes の独自性はその理念にあります。たとえば、不変インフラストラクチャ、ターミナル指向、宣言的 API といったサーバーレスに通じる理念に従っており、それが今日の Kubernetes エコシステムを形成しました。

初期の Linux オペレーティングシステムは単一のサーバーを対象としており、アプリケーションランタイムを基盤デバイスからデカップリングできました。アプリケーションはカーネルの API を通じて、異なるハードウェア上で適合し実行できます。その設計思想は「すべてはファイルである」であり、これが Linux エコロジーの繁栄をもたらしました。Kubernetes の宣言的 API もリソースファイルに対する CRUD インターフェイスと見なすことができ、分散インフラストラクチャとアプリケーションのデカップリングを実現しています。

Linux は単一マシンを対象とし、Kubernetes は分散システムを対象とします。クラスター内のすべてのノードはフラット化され、直接スケジューリングできます。不変インフラストラクチャの理念により、プロセスが障害を起こしても再構築でき、他のノードにスケジューリングできます。

Kubernetes は仮想分散オペレーティングシステムです。Linux システムで発生する問題は、Kubernetes でも同様に発生します。

2. 分散アプリケーション配信で直面する課題

Kubernetes の発展に伴い、エコロジーは継続的に充実してきました。一方、コンテナと Kubernetes のエコロジーは一連のアプリケーション配信形式を確立しましたが、同時に多くの複雑さを露呈し、選定、保守、管理の複雑性が大幅に増加しました。

現在、ユーザーの関心は左方にシフトしています。初期はインフラストラクチャやネットワークハードウェアなどに多くの注意が払われていましたが、現在はインフラストラクチャ層に注意を払う必要はなく、自社のビジネスに集中できます。

自建 Kubernetes には主に以下の三つの課題があります。

一つ目はリソース消費です。小規模および中規模のユーザーにとって、クラスターの保守は多くのコストをもたらします。たとえば、高可用性オペレーターには 3 つのレプリカが必要で、その 3 つのレプリカを中心にモニタリングとログ記録を構築する必要があります。さらに、クラスター自体もリソースを消費し、ビジネスが変動する際にはノードの利用率低下やリソースの無駄が発生しやすくなります。

二つ目は運用保守の複雑さです。Kubernetes クラスターのアーキテクチャを理解するだけでなく、アドオン（ログ記録とモニタリング）の技術選定を行い、本番環境で問題が発生した際の迅速なトラブルシューティングと原因特定を確保する必要があります。問題のトラブルシューティングは、運用保守エンジニアのワークロードをさらに増やします。

三つ目は使用上の学習コストです。Kubernetes の API には二つの側面があります。一方は実装指向で、オペレーターの動作基盤です。もう一方は使用指向で、kubectl、kustomize、ヘルプなどがあります。ベア Kubernetes には約 100 のリソースタイプがありますが、ユーザーが実際に使用するリソースは基本的に 10 以下です。

3. SAE のソリューション

サーバーレスアーキテクチャはトレンドとなり、多くの人に受け入れられ、ユーザーエクスペリエンスを向上させています。サーバーレスは関数コンピューティングだけでなく、コンピュートインフラストラクチャの供給、拡張、モニタリング、設定のすべてをプラットフォームに委ねる運用モデルを指します。

自分で Kubernetes を構築する場合、そのプロセスは自作 PC を組み立てるのに似ています。ビデオカード、CPU、メモリなど多くの選択が必要で、試行錯誤のコストが高くなります。ワンストップ配信プラットフォームを利用する場合、オールインワン PC を選ぶようなもので、細部に注意を払う必要がなく、すぐに使えます。ただし、ワンストップ配信プラットフォームには大規模な実績と蓄積が必要です。また、Alibaba は一部のオープンソースコンポーネントをカスタマイズし、サーバーレス体験を提供しています。

SAE は前述の「オールインワン PC」、すなわちワンストップアプリケーション配信プラットフォームです。

SAE プラットフォームは Kubernetes を基盤に実装されていますが、インフラストラクチャとの互換性、およびアプリケーション指向に係るアドオンの適合と互換性を考慮し、最終的に統合版としてユーザーに優れた体験を提供します。

SAE はサーバーレス体験を提供します。ユーザーはインフラストラクチャを気にする必要がなく、インフラストラクチャをクラウドプラットフォームに委ねることで、更大的な柔軟性とスケーリング能力を獲得します。さらに、SAE は迅速な弾性スケーリングと柔軟なポリシーを提供します。クラウドとの高い統合により、秒単位の弾性スケーリングや従量課金などのサーバーレス機能をサポートし、緊急時でもユーザー SLA を安定的に保証し、多様な弾性ポリシーをサポートします。

4. SAE の技術原理

まず、Kubernetes とセキュリティコンテナの統合です。通常のコンテナのカーネルはホストと共有されますが、セキュリティコンテナは各コンテナが独立したカーネルを持つのに相当し、カーネルの脆弱性や権限超過による異なるアプリケーション間のコンテナ越え侵入を防ぎます。

コミュニティのセキュリティコンテナソリューションには Kata、Firecracker、gVisor があります。セキュリティコンテナはセキュリティ分離だけでなく、パフォーマンス分離と障害分離も実現します。あるアプリケーションがカーネルの問題を引き起こしても、マシン上のすべてのアプリケーションが障害を起こすことはありません。

SAE はマイクロサービスのロスレスシャットダウン機能を提供します。

Kubernetes のすべてのインターフェースは非同期です。Pod が終了すると、サービスが登録ノードから削除されるため、トラフィックが切断されます。そこで、SAE は Kubernetes の機能を基盤に preStop によるアクティブな登録解除を実装しました。Pod の終了シグナルを受信すると、まず preStop を呼び出してレジストリからトラフィックを能動的に削除し、シャットダウン中にアプリケーションの接続が切断されないようにします。

モニタリングと診断の面では、ARMS などの Alibaba Cloud の内部製品が統合されています。アプリケーションのデプロイ後、モニタリング機能が自動的に統合され、インターフェース上でサービス呼び出しや関数呼び出しパスをワンクリックで確認できます。

SAE はエンドツーエンドのクラウド共同デバッグ機能を提供します。

ユーザーはローカル環境で Alibaba Cloud 上の IDE とプラグインを使用し、踏み台サーバーと組み合わせることで、ローカルとクラウド間の共同デバッグを実現し、ローカル開発の効率を向上できます。

SAE シナリオでは、ユーザーはクラスターを意識する必要がなく、名前空間を作成してその VPC と vSwitch を設定するだけです。アプリケーションが名前空間にデプロイされると、その配下の Pod も同じ VPC にデプロイされます。Kubernetes クラスターを構築する必要はなく、管理の粒度も名前空間レベルに達します。

サーバーレスが提供する運用フリー機能は、アプリケーションに直接フォーカスし、ワンクリックでデプロイでき、基盤となるインフラストラクチャリソースに注意を払う必要がありません。インスタンス単位で課金され、アプリケーション単位で各種運用保守操作を実行します。ECS 上で必要なログモニタリングシステムも既に統合されています。

サーバーレスの高い柔軟性により、ユーザーエクスペリエンスの向上とコスト削減が実現しました。トラフィックの急激な変動に直面しても、10 〜 15 秒で高速なスケーリングを実現できます。

従来の K8S のデプロイメント、再構築、アップグレード戦略は上図の通りです。SAE はインプレースアップグレード戦略を実装しました。イメージのみが更新される場合、コンテナを再スケジュールする必要がなく、その場で古いイメージを破棄して新しいイメージを起動できます。これにより高速起動が可能になり、デプロイメント効率が 42% 向上しました。

さらに、SAE はイメージウォームアップ戦略を実装しました。Pod の起動時、大部分の時間はイメージのプルに費やされます。しかし、ユーザーイメージのプルとスケジューリングシステムのプロセスは一部重複しています。そのため、ネットワークコンテナの確立後にイメージをプルするのではなく、事前にノード上にイメージをロードしてウォームアッププロセスを加速し、コンテナをより高速に起動できます。弾性効率が 30% 向上しました。

SAE はプログラミング言語ごとに起動高速化を実現しました。

Java を例に取ると、Dragonwell を最適化して SAE に統合し、AppCDS による起動高速化を強化しました。たとえば、複数インスタンスの場合、最初のインスタンスの起動時間は通常ですが、他のインスタンスが起動またはスケールアウトする際、AppCDS テクノロジーによりコールドスタート時間を大幅に短縮できます。

同時に、Dragonwell Wisp の機能により Java ランタイムの高速化を実現しました。通常のスレッドをコルーチンに変換してランタイムの高速化を実現し、実行効率が 20% 向上しました。

Q&A

Q: 関数コンピューティングではなぜ軽量コンテナを選択するのですか？

A: 関数コンピューティングの当初、単一インスタンス単一リクエストのモデルのみが存在しました。これは、ある時点でインスタンスが処理できるのは 1 つのリクエストのみを意味します。処理完了後、次のリクエストが同じインスタンスに到達すると、再度処理されます。現在、関数コンピューティングの基盤分離は Micro VM を使用しており、従来の Docker ではありません。多くの顧客は関数コンピューティングの柔軟性を評価していますが、コールドスタートを受け入れられないため、単一インスタンス・マルチリクエストによるコールドスタート回避を望んでいます。複数のリクエストは水位に基づいて弾性スケーリングを実現します。水位がアラート閾値に達していない場合、既存のインスタンス上で複数の並列インスタンスが動作し、複数のリクエストが 1 つの Micro VM 内に存在しますが、個別のリクエスト分離は行われません。

Python や Node.js は単一インスタンスのマルチコンカレンシーをサポートしていますが、これはコールドスタートを短縮するだけで、リクエスト処理プロセスは依然としてシングル処理モデルです。そのため、マルチリクエストにはなりません。一方、Java エコシステムや Go エコシステムでは、コスケジューリングやマルチスレッドにより複数リクエストを同時処理できます。ただし、ランタイムモデルでリクエストレベルの分離を追加すると、オーバーヘッドが非常に大きくなります。

さらに、単一インスタンスのマルチスレッドの場合、1 つのスレッドのパニックがインスタンス全体のパニックを引き起こす可能性があります。現在のところ、この問題に対する効果的な解決策はありません。