1768911101
2026-01-20 12:00:00
セールスフォース もっている 段階的な移行を完了しました 1,000 以上の Amazon Elastic Kubernetes サービス (EKS) クラスターを Kubernetes クラスター オートスケーラーから カーペンターAWS のオープンソースのノードプロビジョニングおよび自動スケーリングソリューション。この大規模な移行の目的は、スケーリングの遅延を削減し、運用を簡素化し、コストを削減し、社内の開発者が社内の広範な Kubernetes フリート全体でより柔軟なセルフサービス インフラストラクチャを実現できるようにすることです。
Auto Scaling のグループベースの自動スケーリングとクラスター オートスケーラーでは、スケールアップ時間の遅さ、アベイラビリティ ゾーン全体の使用率の低下、数千のノード グループの急増などの制限に直面しているため、Salesforce のプラットフォーム チームは、移行を安全かつ確実に自動化および管理するためのカスタム ツールを構築しました。このアプローチでは、慎重に調整されたノード遷移と、考慮された自動化が組み合わされています。 ポッド中断の予算 (PDB)、サポートされているロールバック パス、および会社の CI/CD プロビジョニング パイプラインと統合されています。
移行の取り組みは、2025 年半ばにリスクの低い環境で始まり、テストと検証の段階を経て、2026 年初めに本番環境に導入されました。Salesforce のエンジニアは、社内の Karpenter 移行ツールと、ノードのローテーションを処理するパッチ適用チェックを開発しました。 Amazon マシンイメージ (AMI) 検証と適切なポッドの削除により、さまざまなノード プール構成にわたって反復可能で一貫した変換が可能になります。
この移行を通じて、チームはノードの交換を妨げる誤った PDB の構成などの運用上の課題を解決しました。 Kubernetes 自動化の失敗を引き起こすラベル長の制約、および単一レプリカ アプリケーションの中断を防ぐために Karpenter の効率的なビンパッキングを調整する必要があるワークロード パターン。これらの洞察は、プロアクティブなポリシー検証やワークロードを意識した中断戦略など、洗練された実践につながりました。
セールスフォース 報告されました 移行後の運用面とコストが目に見えて改善されました。 Karpenter の動的プロビジョニング モデルを採用することで、クラスターのスケーリング遅延が数分から数秒に短縮され、よりスマートなビンパッキングによってノード使用率が向上し、静的な Auto Scaling グループへの依存が大幅に軽減されました。
自動プロセスが手動のノード グループ管理に取って代わり、開発者自身がノード プール構成を宣言できるようになったことで、運用オーバーヘッドが約 80% 減少しました。このオンボーディングの加速により、中央プラットフォーム チームへの依存が軽減されました。さらに、初期の結果では、2026 年度に約 5% のコスト削減が示されており、Karpenter のビンパッキングとスポット インスタンスの利用によりリソースが最適化され続けるため、2027 年度にはさらに 5 ～ 10% の削減が見込まれます。
Salesforce の移行は、従来の自動スケーリング メカニズムが動的なワークロードや異種インフラストラクチャの需要に対応するのに苦労している、大規模な Kubernetes 運用における広範な傾向を浮き彫りにしています。 Karpenter のリアルタイムの意思決定、異種インスタンス タイプ (GPU や ARM を含む) のサポート、クラウド API との緊密な統合により、クラスター オートスケーラーと比較して、より高速な応答性とより効率的なノードの使用が可能になります。
従来の Kubernetes 自動スケーリングから Karpenter のようなより動的なソリューションへの大規模な移行に取り組んでいる他の組織も、Salesforce が文書化したものと同じ構造的な課題の多くに直面しています。例えば、 コインベース は、静的ノード グループによって引き起こされる運用上の摩擦を軽減しながら、スケールアップ レイテンシとリソース効率の改善を挙げて、変動する需要パターンを持つ複雑な混合ワークロード クラスターを処理するために Karpenter に向けた動きを公的に説明しました。同様に、 BMWグループ 自動車プラットフォーム全体で Karpenter を採用することで、スポット インスタンスとワークロードを考慮したスケジューリングをより適切に使用できるようになり、開発者のフィードバック ループが高速化され、インフラストラクチャのコストの変動が軽減されたことを共有しました。これらの事例は、Cluster Autoscaler が事前定義された Auto Scaling グループと低速の意思決定パスに依存しているため、多様でバースト性の高いワークロードがある環境での応答性が妨げられる可能性があるという Salesforce の観察を反映しています。
Salesforce の移行を際立たせているのは、そのスケールと自動化ツールです。1,000 を超える異なる EKS クラスターを移行するには、ポリシーの検証、ポッド中断予算の制約、Kubernetes のラベル制限、およびフリート レベルでの増分ロールアウトの自動化を処理するための特注のツールが必要でした。他の企業は、個々のクラスターまたは小規模なフリートで Karpenter の利点を報告していますが、Salesforce のアプローチは、統合されたロールバックとコンプライアンスの保護機能を備えた、エンタープライズ規模での反復可能な自動変換を重視しています。実際には、これは自動スケーリング ロジックを置き換えるだけでなく、グローバル プラットフォーム全体でワークロード パターン、ガバナンス制御、開発者のセルフサービスの期待を調和させることも意味しました。最終目標であるスケーリングの高速化、利用率の向上、手動オーバーヘッドの削減はこれらの移行全体で共有されていますが、Salesforce のブループリントでは、大規模で実稼働に不可欠な環境にそのようなメリットをもたらすために必要な運用規律とカスタム自動化が強調されています。
企業がミッションクリティカルなサービスに Kubernetes を採用するケースが増えている中、Salesforce の経験は、同様の移行を検討している他の組織に青写真を提供し、慎重な計画とツールのサポートが変化を支えている限り、自動化されたフェデレーテッド自動スケーリングがパフォーマンス、コスト効率、開発速度の大幅な向上につながる可能性があることを実証しています。
#Salesforce #が #以上の #EKS #クラスターを #Karpenter #に移行してスケーリング速度と効率を向上