アシュリーデイビス
*この記事はもともとで公開されました TheNewStack
マイクロサービス上に構築されたアプリケーションは、複数の方法で拡張できます。大規模な開発チームによる開発をサポートするためにスケールアップすることも、パフォーマンスを向上させるためにスケールアップすることもできます。そうすれば、アプリケーションの容量を増やし、より大きなワークロードを処理できます。
マイクロサービスを使用すると、アプリケーションのパフォーマンスをきめ細かく制御できます。マイクロサービスのパフォーマンスを簡単に測定して、パフォーマンスが低い、過労、または需要のピーク時に過負荷になっているマイクロサービスを見つけることができます。図1は、 Kubernetesダッシュボード マイクロサービスのCPUとメモリの使用量を理解する。
ただし、モノリスを使用している場合、パフォーマンスの制御は制限されます。モノリスを垂直方向にスケーリングすることもできますが、基本的にはそれだけです。
モノリスを水平方向にスケーリングすることははるかに困難です。モノリスの「パーツ」を個別にスケーリングすることはできません。パフォーマンスの問題を引き起こすのはモノリスのごく一部である可能性があるため、これは理想的ではありません。それでも、それを修正するには、モノリス全体を垂直方向にスケーリングする必要があります。大きなモノリスを垂直方向にスケーリングすることは、費用のかかる提案になる可能性があります。
代わりに、マイクロサービスでは、スケーリングのための多数のオプションがあります。たとえば、システムの小さな部分のパフォーマンスを個別に微調整して、ボトルネックを排除し、パフォーマンス結果の適切な組み合わせを実現できます。
パフォーマンスの問題に取り組むための高度な方法もたくさんありますが、この投稿では、を使用してマイクロサービスをスケーリングするための比較的簡単なテクニックの概要を説明します。 Kubernetes:
- クラスター全体を垂直方向にスケーリング
- クラスター全体を水平方向にスケーリング
- 個々のマイクロサービスを水平方向にスケーリング
- クラスター全体を柔軟にスケーリングする
- 個々のマイクロサービスを柔軟にスケーリングする
スケーリングでは、多くの場合、クラスターにリスクのある構成変更が必要になります。このため、顧客やスタッフが依存している本番クラスターにこれらの変更を直接加えようとしないでください。
代わりに、新しいクラスターを作成して使用することをお勧めします 青緑色の展開、または同様の展開戦略。インフラストラクチャへの危険な変更からユーザーをバッファリングします。
クラスターの垂直方向のスケーリング
アプリケーションを拡張すると、通常、クラスターにアプリケーションを実行するのに十分なコンピューティング、メモリ、またはストレージがない場合があります。新しいマイクロサービスを追加する(または冗長性のために既存のマイクロサービスを複製する)と、最終的にはクラスター内のノードが最大になります。 (これは、クラウドベンダーまたはKubernetesダッシュボードから監視できます。)
この時点で、クラスターで使用可能なリソースの合計量を増やす必要があります。でマイクロサービスをスケーリングする場合 Kubernetesクラスター、垂直スケーリングまたは水平スケーリングのいずれかを同じように簡単に利用できます。図2は、Kubernetesの垂直スケーリングがどのように見えるかを示しています。
ノードプール内の仮想マシン(VM)のサイズを増やすことにより、クラスターをスケールアップします。この例では、3つの小さなサイズのVMのサイズを増やして、3つの大きなサイズのVMを作成しました。 VMの数は変更していません。サイズを大きくしました—VMを垂直方向にスケーリングします。
リスト1は、AzureでクラスターをプロビジョニングするTerraformコードからの抜粋です。 vm_sizeフィールドをStandard_B2msからStandard_B4msに変更します。これにより、Kubernetesノードプール内の各VMのサイズがアップグレードされます。 2つのCPUの代わりに、4つ(VMごとに1つ)になりました。この変更の一環として、VMのメモリとハードドライブも増加します。 AWSまたはGCPにデプロイする場合は、この手法を使用して垂直方向にスケーリングできますが、これらのクラウドプラットフォームでは、VMサイズを変えるためにさまざまなオプションが提供されます。
クラスタにはまだVMが1つしかありませんが、VMのサイズを増やしました。この例では、クラスターのスケーリングはコードの変更と同じくらい簡単です。これは、Infrastructure-as-Codeの力です。これは、インフラストラクチャ構成をコードとして保存し、継続的デリバリー(CD)パイプラインをトリガーするコード変更をコミットすることによってインフラストラクチャに変更を加える手法です。
クラスターの水平方向のスケーリング
クラスターを垂直方向にスケーリングするだけでなく、水平方向にもスケーリングできます。 VMは同じサイズのままにすることができますが、VMを追加するだけです。
クラスターにVMを追加することで、アプリケーションの負荷をより多くのコンピューターに分散します。図3は、3つのVMから最大6つのVMにクラスターを移行する方法を示しています。各VMのサイズは同じままですが、VMを増やすことで、より多くの計算能力を得ることができます。
リスト2は、ノードプールにVMを追加するためのTerraformコードの抜粋を示しています。リスト1に戻ると、node_countが1に設定されていましたが、ここでは6に変更しました。vm_sizeフィールドをStandard_B2msの小さいサイズに戻したことに注意してください。この例では、VMの数を増やしますが、サイズは増やしません。 VMの数とサイズの両方を増やすことを妨げるものは何もありませんが。
ただし、一般的には、垂直スケーリングよりも安価であるため、水平スケーリングを使用することをお勧めします。これは、多数の小さいVMを使用する方が、少数ではあるが大きくて高価格のVMを使用するよりも安価であるためです。
個々のマイクロサービスを水平方向にスケーリングする
クラスターが適切なサイズにスケーリングされて、すべてのマイクロサービスを良好なパフォーマンスでホストすると仮定すると、個々のマイクロサービスが過負荷になった場合はどうすればよいでしょうか。 (これはKubernetesダッシュボードで監視できます。)
マイクロサービスがパフォーマンスのボトルネックになるたびに、マイクロサービスを水平方向にスケーリングして、その負荷を複数のインスタンスに分散させることができます。これを図4に示します。
より大きなワークロードを処理できるように、この特定のマイクロサービスにより多くのコンピューティング、メモリ、およびストレージを効果的に提供しています。
ここでも、コードを使用してこの変更を行うことができます。これを行うには、リスト3に示すように、Kubernetesデプロイメントまたはポッドの仕様でレプリカフィールドを設定します。
パフォーマンスのために個々のマイクロサービスをスケーリングできるだけでなく、冗長性のためにマイクロサービスを水平方向にスケーリングして、よりフォールトトレラントなアプリケーションを作成することもできます。複数のインスタンスを持つことで、単一のインスタンスに障害が発生したときにいつでも負荷を引き受けることができる他のインスタンスがあります。これにより、マイクロサービスの障害が発生したインスタンスを再起動して、作業を再開できます。
クラスターのElasticScaling
より高度な領域に移動すると、弾性スケーリングについて考えることができます。これは、さまざまなレベルの需要を満たすためにクラスターを自動的かつ動的にスケーリングする手法です。
需要が少ないときはいつでも、 Kubernetes 不要なリソースの割り当てを自動的に解除できます。需要が高い期間には、増加するワークロードに対応するために新しいリソースが割り当てられます。これにより、いつでも、その時点でアプリケーションのワークロードを処理するために必要なリソースに対してのみ支払うため、大幅なコスト削減が実現します。
クラスターレベルでエラスティックスケーリングを使用して、リソース制限に近づいているクラスターを自動的に拡張できます。繰り返しになりますが、Terraformを使用する場合、これは単なるコード変更です。リスト4は、Kubernetesオートスケーラーを有効にして、ノードプールの最小サイズと最大サイズを設定する方法を示しています。
クラスターのエラスティックスケーリングはデフォルトで機能しますが、カスタマイズする方法もたくさんあります。で「auto_scaler_profile」を検索します Terraformのドキュメント 詳しく知ることができ。
個々のマイクロサービスのElasticScaling
また、個々のマイクロサービスのレベルでエラスティックスケーリングを有効にすることもできます。
リスト5は、マイクロサービスに「バースト可能な」機能を提供するTerraformコードのサンプルです。マイクロサービスのレプリカの数は、マイクロサービスのさまざまなワークロード(アクティビティのバースト)に対応するために動的に拡張および縮小されます。
スケーリングはデフォルトで機能しますが、他のメトリックを使用するようにカスタマイズできます。を参照してください Terraformドキュメント 詳しく知ることができ。 Kubernetesでのポッドの自動スケーリングの詳細については、 Kubernetesのドキュメントをご覧ください.
本について:マイクロサービスのブートストラップ
マイクロサービスを使用したアプリケーションの構築については、 マイクロサービスのブートストラップ.
マイクロサービスのブートストラップは、マイクロサービスを使用してアプリケーションを構築するための実用的でプロジェクトベースのガイドです。単一のマイクロサービスを構築することから、本番環境でマイクロサービスアプリケーションを実行することまで、すべての方法が必要です。 Kubernetes、自動化された継続的デリバリーパイプラインで終わり、 Infrastructure-as-Code 更新を本番環境にプッシュします。
その他のKubernetesリソース
この投稿はからの抜粋です マイクロサービスのブートストラップ また、Kubernetesでマイクロサービスを実行するときにマイクロサービスをスケーリングする方法の概要を説明しました。
Terraformを使用してインフラストラクチャの構成を指定します。この方法でコードを介してインフラストラクチャを作成および更新することは、 イントラストラクチャーアズコード、インフラストラクチャの操作をコーディングタスクに変え、DevOps革命への道を開いた手法として。
詳細については Kubernetes、 参照してください Kubernetesのドキュメント そして無料 Introduction to Kubernetes トレーニングコース。
Terraformを使用したKubernetesの操作の詳細については、を参照してください。 Terraformのドキュメント.