2021.05.26

RKSを知る! 連載第23回目 :マネージドKubernetesサービス比較調査 –可用性編

文:

各マネージドkubernetesサービスの可用性について調査・比較を行い、RKSのユニークな点に迫りたいと思います。

CONTENTS

この記事をシェア:

Facebook Twitter LINE

はじめに

「RKSを知る!」の連載第23回目の記事としまして、各マネージドkubernetesサービスの可用性について調査・比較し、内容について解説したいと思います。

本連載についてはリンクページを用意していますため、概要や連載記事は下記URLからご確認ください。
RKSを知る! 概要&連載リンク集

RKSの可用性

RKSはRidgeCloudは24時間体制でクラスタの状態を監視しており、クラスタ上のNodeに何かしら異常が検知された場合、自動的に再作成を行うよう設定されています。

そのため、Node異常により縮退運転になることが無く、Kubernetesの機能も合わさって、常に規定台数、構成通りのアプリケーション実行を実現しています。

何かしら障害により可用性が低下するといった事態はRidgeCloudの機能により、防止されており、クラスタの可用性はRidgeによって担保されていると言えます。

RKSにてクラスタを構築する際にコントロールプレーンとなるMasterNodeもマルチ構成で構築できるため、MasterNodeが異常終了により、復旧までの間、疎通が取れないといった障害によるダウンタイムは事前に対応することも可能です。

しかしながら、RKSでは負荷状態によりNodeを自動的にスケールイン・スケールアウトする機能はサポートしていないため、高負荷状態が発生した場合、クラスタ上のアプリケーションの可用性は低下する可能性があります。

また、Nodeを他のデータセンターに分散して構成することは仕様上、サポートしていないため、データセンターそのものが障害等で使用できなくなった場合、クラスタも同じく使用できなくなる可能性があります。

RKS対応内容一覧

EKSの可用性

EKSでは高可用性を実現するために複数のアベイラビリティゾーンにて各Nodeを実行し、スケーリングしています。

そのため、アベイラビリティゾーンが障害により使用できなくなったとしても、EKS側で使用可能なアベイラビリティゾーンにMasterNode、およびWorkerNodeを再構成することでダウンタイムの軽減を行っています。

また、EKSでは負荷に応じてMasterNodeの自動スケーリングを実行しており、異常検知時の自動復旧等もAWS側にて対応しており、クラスタの可用性を向上させています。

WorkerNodeについてはClusterAutoScalerという負荷状態を監視し、自動的にスケールアウトさせる機能にて外部からの攻撃やアクセス集中によるクラスタ性能超過に対応しています。

ClusterAutoScalerはクラスタの稼働状況を24時間体制で監視しており、例えば夜間に外部からの攻撃が発生し、クラスタの負荷が異常に上昇した場合でもClusterAutoScalerが負荷状態を検知し、一時的にWorkerNode数を増加させることで可用性の担保を自動的に行う事が出来ます。

各Nodeの死活監視もEKS側にて対応しており、Master、およびWorkerに異常が発生した場合、自動的にNodeの再構成を行い、安全にPodの再稼働をサポートするため、Node障害が発生したとしてもアプリケーションの動作に影響を与えることはありません。

EKS対応内容一覧

AKSの可用性

AKSでは高可用性を実現させるため、1つのリージョン内から複数のゾーンにノードを分散させる高可用性ゾーン機能が存在します。

ノードやストレージなどのリソースを、基になるAzureインフラストラクチャの複数の論理セクションに分散させることで、特定のゾーンに対する依存度が減り、クラスターの可用性を向上させることが出来ます。

AKSにもEKSと同じく、クラスターオートスケール機能を実装しています。
AKSのクラスターオートスケーラーは指定したNodeリソース制限を超えた場合、自動的にNodeのスケーリングを行います。
クラスターオートスケーラーにより、リソース使用量が想定外の値になったとしても、定義したNode性能にて自動的にNodeを増加させることができ、パフォーマンス不足による可用性低下を防止することが可能となります。

引用元 : https://docs.microsoft.com/ja-jp/azure/aks/cluster-autoscaler

各Nodeの死活監視についてもAKSは対応しており、24時間体制でAKSクラスタをAzureにて監視を行い、WorkerNodeのStatusが10分間以上、NotReady状態となった場合にNodeの再起動を行います。

Node再起動にてStatusが改善されなかった場合はNodeの再作成をAzureにて行い、Node減少による可用性低下を軽減します。

EKS対応内容一覧

調査結果の比較

可用性について調査した結果、各マネージドKuberneteサービスを比較したところ、

  • 全てのマネージドKuberneteサービスにてクラスタの稼働・死活監視は行っており、Nodeに異常が発見された場合はクラウドサービス側で復旧を行ってくれる。
  • マルチコントロールプレーンは全てのマネージドKuberneteサービスにて対応しており、MasterNodeの負荷分散、およびダウンした際の縮退運転に対応することが出来る。
  • RKSではクラスタオートスケールに対応していないため、アクセス増加や外部からの攻撃等にてクラスタ全体のリソース使用量が超過した際に自動的にNodeを増加させることが出来ないため、パフォーマンス減少による可用性低下の可能性がある。
  • RKSはNodeの地理的分散に対応することが出来ないため、利用しているデータセンター自体に障害が発生した場合、クラスタの稼働が停止する可能性がある。

といったところが分かりました。

あとがき

今回は連載第23回目としまして、各マネージドkubernetesサービスの可用性について調査し、比較・解説をしました!
EKS、AKSはやはり差はなかったのですが、RKSですと自動スケーリングや地理的分散構成などに対応できていないため、実運用時に大規模障害や深夜帯のアクセス超過などに対応できないかもしれないことが分かりました。

しかしながら、クラスタの死活監視は全てのマネージドKuberneteサービスにて行っているため、Nodeの異常終了にはすべてのサービスがきちんと対応できていることも分かりました!

次回更新ではこれまで比較してきた内容からRKSの強み・弱みの分析を行い、どのようなサービスに向いているのか考察した内容を記事にしたいと思います!


ここまでお読みいただき、ありがとうございました!

今解決したいDXの
お困りごとなんですか?

DXの知識、導入事例を知りたい DXの知識、導入事例を知りたい セミナーに参加する

今取り組むべき事業のDX推進や、本当に活用できるコンテナ製品の導入プランをご紹介しています。お気軽に無料ウェビナーにご参加ください。

何から手をつけていいか分からない 何から手をつけていいか分からない サービスソリューションをみる

DX推進に取り組みたいが詳しい人材がいない。
まずどこから始めればいいのか、どういう方法があるのかイメージが掴め切れていない。

自社の具体的な導入を検討している 自社の具体的な導入を検討している 各種お問い合わせへ

コンテナ製品のご提案や人材育成支援も行います。事業のDX推進でお困りの方は、こちらからお問い合わせください。