[レポート] CON318 – Running a High-Performance Kubernetes Cluster with Amazon EKS #reinvent

概要

How do you ensure that a containerized system can handle the needs of your application? Designing and testing for performance is a critical aspect of operating containerized architectures at scale. In this session, we cover best practices for designing perfomant containerized applications on AWS using Kubernetes. We also show you how State Street deployed a high-performance database at scale using Amazon Elastic Container Service for Kubernetes (Amazon EKS).

内容

Amazon EKSで構築したアプリケーションを高いパフォーマンスを発揮できるベストプラクティスを紹介。後半はStateStreetで運用している高可用性のDatabaseをEKSで動作させている上で、どういった工夫を行っているかをより具体的に紹介するセッションでした。

Container環境

• ローカルでContainerとWorker Nodeを使って開発
• Amazon EKSではControl Planeとetcd

コンテナの最適化

• Docker buildの際にMultistageを利用してImageを極力小さいサイズに抑える
• できるだけ最小のOSを選択する: Alpineとか
• もしくはOSを利用しない: Goバイナリを静的リンクするとか
• 世の中に出回ってるメジャーなImageは同じ目的を達するとしても膨大なサイズの幅がある

podsの最適化

• 1つのPodの中にいくつのSidecar Containerを配置するか
• Admission controller
• できるだけ軽量に

podの配置の最適化

• アプリケーションが必要とする平均リソースの基準をRequestしておく
• リソースの最大数に上限を課す

podの数を増やすかpodの性能を上げるか

• Podを増やしてCPU, memoryを下げるか
• CPUとメモリを増やしてPodを削除するか

Anti-Affinity

• 異なるホストで動作するPodはそれぞれ、高いCPU使用率のものに制約をかけられる
• ただし機能はまだBeta版

Worker nodeの最適化

• latest EC2 instanceを使うべし
• c5だとc4に比べて性能もコストパフォーマンスも25%近く向上している
• Primary pods resourceが必要とするものを基準にNodesのインスタンスタイプは選ぶべし
  • Compute重視なのかMemory重視なのか等。c5, m4, r4等々

Networkingの最適化

• AWS VPC CNI Pluginを使う。aws/amazon-vpc-cni-k8s
• Pod to Pod networking
  • EC2同士はVPC fabricで結ぶと良い

Performance envelope

どういった構成にするかによってどこを最適化するのが効果的なのかが変化します。

それぞれが最適化する要素を示します。

1. Heavy monolithic pods in a very large cluster

重量級のPodsを巨大クラスタの中へ配置した場合。

Clusterのノードをスケールしたりする方向で調整するとパフォーマンスが向上するようです。

2. Numerous densely bin packed microservice pods

めちゃくちゃ高密度に大量のバイナリを集めたMicroservice pods(?)の場合

Pod側を最適化する方向で調整するとパフォーマンスが向上するとのこと。

Orchestrationパターンを募集

EKSを使ったたくさんのOrchestratedのユースケースを集めているので、サポートチケットでバンバン投げてほしいとのことでした。

STATE STREET

• Transaction database (unlimited scale concurrency)
• 高可用性、低レイテンシー、クラウドネイティブなデータベースを構築

• Replication Architecture
  • Masterノードの下にSlaveノードが二台ぶら下がる(MySQL)　これが1シャード
  • RocksDB Engine (facebook)
  • MariaDB or Percona
  • Standard MySQL features
  • CloudNative
• スケールアウトのアーキテクチャ
  • ReadでScale-outする場合はSlaveノードが増えていく
  • WriteでScale-outする場合、Master * 1 - slave * 2を１まとまりとしてシャードが増えていく
• Kubernetes concept
  • Persistent Volumeを利用すること
  • Podの中にDatastoreを持ってしまう
  • No resiliency, Best performance
  • Node内にPodとPersistent Volumeを配置する
  • Med Resiliency, Best Perfmenace
  • Nodeの中にPod(pvc)。Nodeの外側にPersistent Volumeを配置
  • Best resiliency, Low performance
  • それぞれの手法でトレードオフ
  • K8sを最大限活用していく
    • Applet custom controll(kubelet?)

• Pod networking
  • Bottleneck @400k QPS
• Jumbo frameが効果的
• それぞれスケールの規模に応じて設定を重ねがけしていく
  • No replica, Overloaded, 1 subnet < +3 subnets < +placement group < +Jumbo frames < +4 Replicas
  • Scalingの規模に応じて必要なConfigurationを追加していく

高いパフォーマンスをKubernetesで発揮するためのベスト・プラクティス

デモ

実際のデータベースクラスタを稼働させ、多くのCluster node, Podで構成したデータベースシステムでデモを実施。ネットワークの設定やシャードの設定によってどのようにパフォーマンスが変わっていくかを実践。

最後はデータ数が膨大なのかGrafanaから反応がなくなってしまい。「Come on Grafana」

まとめ

KubernetesのClusterやPodを高いパフォーマンスで稼働するための様々なTIPSが紹介されました。Kubernetes自体が多様なComponentで構成されており、さらにClusterやPodの構成一つで様々なパラメータが影響し合うようです。こういった大規模なCluster構成等はなかなか見ることができないので、ギリギリまでチューニングする方法についてそれぞれの要素がどのように影響するかを見ることができたのはとても良かったです。Kubernetesを使いたい気持ちが高まってきました。