次世代サーバーレスプラットフォームKnativeの応用実践

事業紹介
1. 単一製品APIサービスは、Dangdang.comの技術プラットフォームのコア基本サービスの1つです。
2. 製品関連のAPIサービス群から構成される
3. 単一の製品APIにより、多数のバックグラウンドAPIのインターフェース集約が完了し、インターフェースのパフォーマンスが向上します。
4. 単一の製品 API により、関連するすべての上流サービスに対して効率的で信頼性の高い基盤サービス サポートが提供されます。
技術ステータス
1. 開発言語にはPHPとJAVAが含まれます。
2. K8S ネイティブ モードでデプロイして実行します。

動作環境
• ネイティブ: v0.8.0
• Istio: v1.3.0
• Kubernetes: v1.14.4
• ドッカー: v18.06.3
• Centos: v7.5
• プロメテウス v2.2.1
• グラファナ v5.0.3
• Tekton パイプライン: v0.8.0
• サーバー: 8コア / 32Gメモリ / 500GB HD

ユーザーコンテナの構築とオーケストレーション

1. ユーザーコンテナに対応するDockerfileを作成します。

ユーザーコンテナの構築とオーケストレーション
1. ユーザーコンテナに対応するDockerfileを作成します。
2. Tektonはコードをビルドし、ランタイムコンテナをパッケージ化してプライベートイメージリポジトリにプッシュします。

ユーザーコンテナの構築とオーケストレーション

1. ユーザーコンテナに対応するDockerfileを作成します。
2. Tektonはコードをビルドし、ランタイムコンテナをパッケージ化してプライベートイメージリポジトリにプッシュします。
3. knativeのservice.yaml設定ファイルを書く

ブルー/グリーンデプロイメント
…
トラフィック: - タグ: 現在
リビジョン名: productapi
-v1
パーセント: 100
- タグ: 候補者
リビジョン名: productapi
-v2
パーセント: 0
- タグ: 最新
最新リビジョン: true
パーセント: 0

パフォーマンステスト<br /> Knative プラットフォームがアプリケーション コードに及ぼすパフォーマンスへの影響を評価する同時リクエストの合計数: 200
Knative 環境における POD あたりの同時実行数: 40
Knative 環境で開始された Pod の数: 6
K8s 環境で有効化された POD の数: 6

問題点とその後の改善点<br /> パフォーマンスの問題:
• キュープロキシ
1. すべてのユーザーコンテナトラフィックの転送を担当
2. クライアントのメトリクスをオートスケーラーに報告する
• 問題点:
プロキシのレイヤーが呼び出しチェーンに追加されます。私たちのテスト シナリオでは、QueueProxy によって 27 ミリ秒のレイテンシと約 120 分の CPU が発生します。
リソースの消費。
• 将来的には、Istio のサイドカー (envoy) を直接使用して Queue Proxy を置き換えるという解決策が考えられますが、これによりサービス メッシュ レイヤーとの結合が発生する可能性があります。

運用および保守ツール
• ログセンター: EFK
• モニタリング: Promethues と Grafana
• サービスメッシュの可視化: Istio & Kiali、Jaeger (コールチェーンのトレース)

サービス可視化ツール<br /> サービス メッシュ可視化ツール - Kiali
1. サービストポロジー図
2. 健康チェック
3. 分散トレース
4. メトリクスの収集
5. 構成の検証

監視ツール

パフォーマンスの最適化（I）
コールドスタートの遅延を減らすソリューション
• コールドスタートの遅延を避けるために、サービスレプリカの数を最小限に抑える
autoscaling.knative.dev/minScale: "n" // n は 1 またはビジネスによって推定されるレプリカの最小数です
• マイクロサービスによりサービスの起動速度を最適化
A. ユーザーコンテナイメージのサイズを縮小して、簡単かつ迅速に配布できるようにする
B. ユーザーコンテナの起動時間を短縮する

パフォーマンスの最適化（II）
予測される高同時実行シナリオの解決策は、サービスに必要なレプリカの予想される最小数を事前に設定することです。例: autoscaling.knative.dev/minScale: "200"
リソースの過剰割り当てを避けるために、サービスに必要なレプリカの最大数を設定します。例: autoscaling.knative.dev/maxScale: "500"
ポッドの可用性を確保するために、サービスの各ポッドの同時リクエストの最大数を設定します。例: autoscaling.knative.dev/target: "100"

その後の開発と改善<br /> より弾力性のあるスケーリングインジケーターをサポート
• 現在サポートされている指標
HPA: CPU 使用率、0 へのスケールダウンはサポートされていません
KPA: 同時リクエスト数、0 までのスケールダウンをサポート
• 新しいバージョンでは新しいメトリックが追加されました:
KPA: RPS/QPS/OPS

結論は
• Knative は、サーバーレス プラットフォームの標準化にとって非常に重要です。
• Knative は現在徐々に成熟していますが、大規模なアプリケーションではさらなる改善が必要です。
• Knative は幅広い開発の見通しがあり、将来的には主流のサーバーレス アーキテクチャ管理プラットフォームになると期待されています。