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

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

1 はじめに
2 RKSの可用性
3 EKSの可用性
4 AKSの可用性
5 調査結果の比較
6 あとがき

はじめに

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

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

RKSの可用性

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

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

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

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

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

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

EKSの可用性

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

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

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

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

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

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

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減少による可用性低下を軽減します。

調査結果の比較

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

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

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

あとがき

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

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

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

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