AWS Container HeroのVlad Ionescu氏は、4月初旬にバッチ処理またはバックグラウンドジョブ用にAmazon Fargateをスケーリングした検証について報告した。
Amazon Web Servicesは2017年にFargateをリリースした。クラウドでKubernetesアプリケーションを実行するために、顧客がEC2インスタンスのクラスタにパッチを適用、スケーリング、または保護する必要がなくなる。
Fargateは、AWS Elastic Container Service (ECS) またはElastic Kubernetes Service (EKS) リソースの提供を自動化する。顧客は、Podレベルでリソースを定義して払い出すことができる。
Ionescu氏は、コンテナスペースが急速に変化していると説明している。組織の場合、コンテナのスケーリングに使用するAWSサービスについては不確実性がある。そのため、スケーリング用のカスタムメトリックを特定することは、推奨されるオプションになりつつある。
Ionescu氏の検証から、EKSのスケーリングが速いことが明らかになった。AWSがすべてを管理しているため、AMIのアップグレードやホストOSの更新について心配することなく、さまざまな方法でパイプラインを構成できると述べている。アベイラビリティーゾーンは、AZ間のコストのオーバーシュートを最小限に抑えるために、単一のアベイラビリティーゾーンでタスクを起動することを提案している。
AWSは、KubernetesとEKSのメンテナンスを排除し、Fargate SpotとコンピューティングのSavingプランも提供しているため、それぞれのニーズに合わせてFargateを簡単に選択できる。
InfoQ: コンテナのスケーリングに適切なAWSサービスを選択する際に、組織が直面する典型的な課題は何ですか ?
Vlad Ionescu氏: 私が目にするほとんどの課題は情報に関連しています。コンテナスペースは広大で常に変化しており、規模の問題によりさらに複雑になっています。
使用するサービスについての不確実性がリストの一番上にあります。AWSにはEKSがあり、ECSは廃れたため、使用できないと理解した人がいます。ECSは優れたサービスであるため、真実からかけ離れたものはありません。AWSと緊密に統合されたソリューションは、ECSに最適です。反対に、Kubernetesはあまり安定していないか、特有の問題があると理解する人がいます。景色が非常に速く動いているので、Kubernetes 1.7以降は有効ではなかったバグを人々は引用しました。すべてについていくのは簡単ではありません。
私が見る2番目に一般的な要求は、リフトアンドシフトしたい、何の作業もせずにコンテナに移動したいという願望です。1つの例は、EC2で正常に実行されている特定のサービスですが、コスト/スケーリング/速度を向上させるためにコンテナに移動する必要があります。レガシーJava 8アプリケーションをコンテナで実行することは、多くの場合、得るものがありません。
私が目にする最後の大きなパターンは、コンテナにはあまり適していないエキゾチックなワークロードです。たとえば、ディスクを大量に消費するワークロード — NVMe SSDに支えられたEC2インスタンスは非常に高速ですが、EKSからの管理はそれほど簡単ではありません。Windowsのみのワークロードも別の例です。これは驚くほどありますが、解決策はまだありません。FargateはWindowsをまったくサポートしておらず、EC2上のECSのみを残し、EC2上のEKSも昨年秋にはオプションになりました。
特にスケーリングに対処するために、スケーリングする適切なメトリックを選択する際に多くの混乱が見られます。CPUまたはRAMに基づくスケーリングは最適ではありません、カスタムメトリックの使用が増加しています。
InfoQ: アベイラビリティーゾーンの観点から、ECSを使用したAWS Fargateの最適な構成を提案できますか ?
Ionescu氏: 信頼性とスケーリングの観点から、AWSの推奨事項に従って、すべてのアベイラビリティーゾーンを使用する必要があります。すべてのアベイラビリティーゾーンを使用すると、アベイラビリティーゾーンに技術的な問題がある場合、または容量が不足している可能性が高い場合に、影響を最小限に抑えることができます。
もちろん、これは特定のユースケースによって異なります。EC2上のECSとは異なり、Fargateはタスク配置をサポートしていません。選択したサブネットによって決定されるように、すべてのタスクは利用可能なすべてのアベイラビリティーゾーンに分散されます。大きなクロスAZネットワーキングコストの驚きを回避するために、単一のアベイラビリティーゾーンでタスクを起動することが理にかなっている場合があります。高度に関連付けられているサービスを単一のAZリソースとすることは、一般的なルールに対抗する完璧な例となります。
InfoQ: スタンドアロンEKSと比較して、構成の単純さの観点からどのような側面が影響を受けますか ?
Ionescu氏: EKSとKubernetes自体は、多くのノブとダイヤルを備えた2つの魅力的なツールです。強力ですが、複雑さの影響が現れるまでに時間がかかる場合があります。「Day 2」の操作と問題は、概念実証では見えない場合があります。
スタンドアロンEKSはEC2ワーカを使用しています。これらのワーカには、AMIのアップグレードから最新のセキュリティ構成の確保まで、メンテナンスが必要です。現在LTSサポートが不足している基本的なKubernetesバージョンのアップグレードも、ベロシティが高くない企業にとって問題になる可能性があります。Fargateでは、ECSでもEKSでも、AWSがこれらの問題のほとんどを処理します。AMIの更新とホストOSの心配がなくなり、エンジニアは他のタスクに集中できます。
EKSは独自の抽象化も実装しています。SQSキュー内のメッセージ数などをスケーリングするには、Metrics ServerとCloudWatchアダプタの2つのツールが必要です。これらのツールは両方とも、構成、アップグレード、および保守する必要があります。
Fargateでは、SQSキューでのスケーリングがネイティブサービスとして提供されるスケーリングポリシーを使用できます。
EKSのカスタムメトリックをスケーリングしたいですか ? さらに、PrometheusとPrometheus Adapterが必要になります。どちらも、大規模に機能するように広い範囲に構成する必要があります。
明らかに「難しい」特別な側面はありません。千切りによって死にます。構成する必要のある、さらに重要なことに理解する必要のある小さなツールが数多くあります。クラスタオートスケーラ、HPA、Metrics Server、および1つのことをうまく行う他の多くのプロジェクトに精通する必要があるため、時間がかかり、問題が発生したり、大規模なシステムにボトルネックが発生したりする可能性のある場所が多数作成されます。
とはいえ、私のブログ投稿の結果からわかるように、EKSはスケーリングが高速です。スケーリングパイプラインは、優れたパフォーマンスを得るために、最適に無限に構成することもできます。それはトレードオフのゲームです。
InfoQ: 組織がFargateの使用を選択した場合、総所有コストにどのような影響がありますか ?
Ionescu氏: ローンチされた時、Fargateは非常に高価なサービスでした。その時点で行われたコスト分析は、まったく利点がありませんでした。幸い、AWSによる新しいリリースにより、これらの計算は廃れました:
- 2019年11月初旬に、コンピューティングの節約プランが導入され、コミットされた使用と引き換えに最大66％のコスト削減が提供されました。
- さらに、2019年12月初旬、AWSはFargate Spotを発表し、最大70％のコスト削減を実現しました。
2020年5月の時点で、純ドルコストの差は決定を強制するほど大きくはありません。議論は、インフラストラクチャと運用コストから総所有コストに移ります。
簡潔にするために、遅延やコストのかかるミスを回避するのに十分なKubernetesの経験を持つ高コストのコンサルタントや従業員はスキップしましょう。それらは重要な部分であり、面倒な採用と保有がありますが、それはまったく別の主題です。言及する必要があるのは、運用上の負担が少ないため、DevOpsの実装も簡単であるということです。一部のエンジニアは、頭字語「k8s」の背後に隠されている知識と黒魔術の膨大な規模に当然のことながら懸念し、恐れています。領域が小さいほど、エンジニアをDevOpsプラクティスにスキルアップするのは簡単です。
私が見る最も重要な影響は、速度に関するものです。チームは、EKSやKubernetesのメンテナンスではなく、他のビジネスに影響を与えるプロジェクトに集中できます。差別化されていない重労働が排除されます。人々が物理データセンタからクラウドに、またはEC2からサーバレスに移行するのと同じ理由: その努力をAWSにオフロードすることは非常に良い提案です。使用料を支払うだけで、簡単に0にスケーリングできます。
内部インフラストラクチャチーム (数人のエンジニア) にかかる労力のレベルを過小評価するのは簡単です。それだけではありません ! Kubernetesの使用には、すべての新しいリリースの最新情報を入手することが含まれます。これには、インフラストラクチャとアプリケーション開発者の両方のスキルアップとトレーニングが含まれます。これには、より拡張されたオンボーディングおよびデプロイメントプロセスが含まれます。
構築が容易な基盤により、チームはより優れた輝くものに集中できます。つまり、デプロイメントの迅速化と市場投入までの時間の短縮、システムの理解とビジネスのサポートのための可観測性、さらにはロードマップを4分の2より上に移動することです。それはかなり簡単に売りになります !