スケーラビリティの概念
スケーリング ソリューションを調べる前に、スケーラビリティとはどのようなことで、それが Kubernetes アプリケーションにどのように適用されるのかを、理解しておく必要があります。
このユニットでは、スケーラビリティのいくつかの概念を確認します。
スケーラビリティ
"スケーラビリティ" とは、リソースを追加することで作業量の増加に対処する、アプリケーションまたはシステムの機能についての説明です。
この例のシナリオで増加している作業量は、顧客の要求の数です。 追加されるリソースの量は、"垂直スケーラビリティ" と "水平スケーラビリティ" という 2 つの方法で表すことができます。
垂直スケーラビリティ
垂直スケーラビリティ( "スケールアップ") とは、メモリや CPU パワーのような物理リソースを追加することによってシステムをスケーリングすることを意味します。 たとえば、会社の Web サイトで消費されるメモリが多すぎる場合は、基になるアプリケーションはそのまま変えずに、VM インスタンスを更新してメモリを増やすことができます。
つまり、垂直方向のスケーリングでは、アプリケーションの数は同じままにして、VM のサイズを増やします。 この方法は、"大量のコンピューティング能力を必要とするものの、小さな部分に分割するのはコストがかかりすぎるモノリシック アプリケーション" に役立ちます。 通常、このようなアプリケーションは、分散システムとは対照的に、VM でホストされます。
コストの管理はいっそう容易ですが、非常に大きな VM は非常に高価になる可能性があります。 コンピューティング能力を追加するコストは、小さな VM を複製するコストより高くなります。 1 つの VM に追加できるリソースの数には上限があります。つまり、上限に達したら、最終的には VM を複製する必要があります。
水平スケーラビリティ
水平スケーラビリティ ("スケールアウト") とは、アプリケーションを複製し、アプリケーション インスタンス間に負荷を分散させてシステムをスケーリングすることを意味します。
水平方向のスケーリングは、"同じアプリケーションを含む複数のコンテナーを 1 つの VM で起動できるため、AKS にデプロイされるもののような分散アプリケーションとステートレス システム" で役に立ちます。 スケールアウトを使うと、支払いは 1 台の VM のまま、リソースを最大限まで活用できます。
このシナリオの例では、会社のサイトはステートレスです。 これは、スケールアウトが最善のアクションであることを意味します。 Kubernetes が備える HorizontalPodAutoscaler (HPA) と呼ばれるすぐに使用できるリソースを使って、デプロイをスケールアウトできます。
Kubernetes での手動のスケーラビリティ
HPA について説明する前に、Kubernetes アプリケーションを手動でスケーリングする方法を確認しましょう。
すべてのデプロイは、ReplicaSet と呼ばれる別のリソースにバインドされています。 ReplicaSet の役割は、"望ましいレプリカの状態" を維持し、望ましい状態と実際の状態が同じになるように、実際のアプリケーションをスケールインまたはスケールアウトすることです。 デプロイ内のレプリカの数は、デプロイの指定の spec.replicas キーを使って制御できます。 このキーにより、基になる ReplicaSet 内で必要なレプリカの数が設定され、レプリケーション コントローラーはこの数のレプリカを常に保持するよう強制されます。
また、kubectl scale deploy/contoso-website --replicas <number> コマンドを使って、デプロイ内のレプリカの数を制御することもできます。 このコマンドでは、デプロイ内の必要なレプリカの数が動的に変更され、アプリケーションがスケールインまたはスケールアウトされます。
HorizontalPodAutoscaler (HPA)
HPA は、クラスター内のポッドの水平スケーラビリティを提供するネイティブの Kubernetes 1.8 + リソースです。 目的のレプリカ数に変化がないか、メトリック API を 30 秒ごとに監視します。 必要なレプリカの数が現在のレプリカの数と異なる場合、HPA オブジェクトを管理するコントローラー マネージャーは、デプロイをスケールインまたはスケールアウトします。
HPA では Kubernetes の autoscaling API グループが使用されます。 この API グループには、v1 と v2 の 2 つのバージョンがあります。 v1 バージョンを使うと、CPU のメトリックのみに基づいてデプロイをスケーリングできます。 v2 バージョンを使うと、CPU とメモリの両方をネイティブに監視できます。 このモジュールでは、v2 バージョンを使います。
すべての HPA は、HPA マニフェストの spec.scaleTargetRef キーで定義されている "スケール参照" にアタッチされます。 このスケール参照では、スケーリングする基になるポッドが必要です。そうでない場合、HPA は機能しません。これは、DaemonSets のように、スケーリングできないオブジェクトにスケーリングを適用できないためです。
各ポッドには、その仕様にリソース要求が設定されていることが重要です。この設定がされていないと、HPA アルゴリズムでメトリックを正しく計算できず、リソース使用率を確認できません。 次の例で示すように、配置マニフェストの spec.template.spec.containers[].resources キーを使ってこの制限を設定できます。
spec:
template:
spec:
containers:
- resources:
requests:
cpu: 250m
memory: 256M
limits:
cpu: 500m
memory: 512M
HPA マニフェストの例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50