この記事は NTTコムウェア Advent Calender 2021 12日目の記事です。

はじめに

NTTコムウェアのtonomuraです。
本記事では、AWSのマネージドサービスであるAmazon EKSにおけるリソース使用料の節約を試みた内容を紹介します。

想定読者

・Amazon EKSをステージング環境で利用していて、利用料金に悩んでいる方
・平日日勤帯以外などの未使用時間にサーバを止めておきたい方
・コスト削減したいけどAWS Fargateへの移行に踏み切れない方

Amazon EKSとは

Amazon Elastic Kubernetes Service の略であり、AWS上でkubernetes環境を簡易に構築・運用できるマネージド・サービスです。

似たようなサービスにAmazon ECSやAmazon EKS on Fargateなどがあり、これらはサーバを意識することなくコンテナをデプロイできるサービスになります。

対して、Amazon EKSはワーカーノードと呼ばれる、コンテナがデプロイされるサーバ(EC2インスタンス)は自分たちで管理する必要があり、従量課金で使った分だけ課金されてしまいます。

本記事の内容

そこで、主にステージング環境用途で使用する場合において、少しでも利用料金を節約するために、使っていない間にEC2インスタンスを落としておく方法を紹介します。

また、EC2インスタンスの復旧までにどのくらい時間がかかるのか、kubernetesリソースの状態はどのように遷移するのか、コマンド実行結果と合わせて紹介します。

前提条件

・本記事で扱うアプリケーションは、コンテナ化されたWeb三層構造のサンプルアプリです
・複数のサービスを組み合わせている場合、Podの起動順序等の制約により、正しく動作しない場合があります
・EKSクラスター(eksctlを利用して構築)やAuto Scalingグループは予め設定済みの状態です

・使用するツールとワーカーノードの構成は以下のとおりです

$ aws --version
aws-cli/2.2.12 Python/3.8.8 Linux/4.14.77-70.59.amzn1.x86_64 exe/x86_64.amzn.2018 prompt/off

$ kubectl get nodes
NAME                                       STATUS   ROLES    AGE     VERSION
ip-10-**-**-**.region.compute.internal     Ready    <none>   38h   v1.20.7-eks-*****
ip-10-**-**-**.region.compute.internal     Ready    <none>   38h   v1.20.7-eks-*****
ip-10-**-**-**.region.compute.internal     Ready    <none>   38h   v1.20.7-eks-*****
ip-10-**-**-**.region.compute.internal     Ready    <none>   38h   v1.20.7-eks-*****

ノード名は伏せていますが、2つのノードグループで構成されており、各ノードグループに対してデプロイされるPodを振り分けています。

初期状態

まずはどのようなPodが立ち上がっているかを確認します。
今回の環境では、サンプルアプリ以外にもPodのログを収集するContainer Insights のリソースが動いています。

$ kubectl get pods -A
NAMESPACE           NAME                                      READY   STATUS    RESTARTS   AGE
amazon-cloudwatch   cloudwatch-agent-fjfdz                    1/1     Running   0          20m
amazon-cloudwatch   cloudwatch-agent-jz4wf                    1/1     Running   0          36m
amazon-cloudwatch   cloudwatch-agent-x28qt                    1/1     Running   0          27m
amazon-cloudwatch   cloudwatch-agent-z5c5j                    1/1     Running   0          27m
amazon-cloudwatch   fluentd-cloudwatch-dgt4x                  1/1     Running   0          20m
amazon-cloudwatch   fluentd-cloudwatch-gj9lf                  1/1     Running   0          27m
amazon-cloudwatch   fluentd-cloudwatch-jqtcz                  1/1     Running   0          36m
amazon-cloudwatch   fluentd-cloudwatch-xqdnk                  1/1     Running   0          27m
test-ap             test-ap-5ffc6fc4cc-29cmv                  1/1     Running   0          44d
test-ap             test-ap-5ffc6fc4cc-c4h9f                  1/1     Running   0          44d
test-ap             test-ap-5ffc6fc4cc-msrtp                  1/1     Running   0          44d
test-ap             test-ap-5ffc6fc4cc-v7cdx                  1/1     Running   0          44d
test-ap             nginx-8c489f6cf-968ps                     1/1     Running   0          29m
test-ap             nginx-8c489f6cf-cb26n                     1/1     Running   0          29m
test-ap             nginx-8c489f6cf-fzxc9                     1/1     Running   0          29m
test-ap             nginx-8c489f6cf-nsdph                     1/1     Running   0          29m
kube-system         alb-ingress-controller-68f5cb8b4b-rklj2   1/1     Running   0          29m
kube-system         aws-node-hj5gf                            1/1     Running   0          27m
kube-system         aws-node-jfqps                            1/1     Running   0          37m
kube-system         aws-node-w2sbs                            1/1     Running   0          27m
kube-system         aws-node-zxctr                            1/1     Running   0          21m
kube-system         coredns-5fd8748bdd-5jhct                  1/1     Running   0          29m
kube-system         coredns-5fd8748bdd-kkr2x                  1/1     Running   0          29m
kube-system         efs-csi-node-6kq4b                        3/3     Running   0          37m
kube-system         efs-csi-node-g9lss                        3/3     Running   0          27m
kube-system         efs-csi-node-jzbpf                        3/3     Running   0          27m
kube-system         efs-csi-node-v4p7w                        3/3     Running   0          21m
kube-system         kube-proxy-46xxl                          1/1     Running   0          21m
kube-system         kube-proxy-gbktt                          1/1     Running   0          27m
kube-system         kube-proxy-hbnff                          1/1     Running   0          37m
kube-system         kube-proxy-xq275                          1/1     Running   0          27m

※補足
マネージドサービスのため、etcdやapiserverなどのリソースは参照できないため登場しません。

ノードを落としてみる

早速、この状態からワーカーノードを落としてみます。
落とす方法としては、Auto Scalingグループの設定の内、「希望する容量」を変更し、ノードが強制的に0台になるようにします。

コマンドは以下のとおりです。

#ノードグループ1 の希望する容量を「0」にする
$ aws autoscaling set-desired-capacity --auto-scaling-group-name eksctl-test-ap-nodegroup-z1-nodeg-NodeGroup-1PXBUVII5GDBS \
  --desired-capacity 0

#ノードグループ2 の希望する容量を「0」にする
$ aws autoscaling set-desired-capacity --auto-scaling-group-name eksctl-test-ap-nodegroup-z2-nodeg-NodeGroup-1IHPM2OH5CEW9 \
  --desired-capacity 0

ノードの状態を確認してみます。

$ kubectl get nodes
No resources found in default namespace.

リソースが見つからない状態になりました。

この時点で、EC2インスタンスは停止状態のため、EC2料金は課金されなくなりました。

続いて、PodのSTATUS(状態)を確認してみます。

$ kubectl get pods -A
NAMESPACE     NAME                                      READY   STATUS    RESTARTS   AGE
test-ap       test-ap-5ffc6fc4cc-4lc8c                  0/1     Pending   0          2s
test-ap       test-ap-5ffc6fc4cc-d756p                  0/1     Pending   0          2s
test-ap       test-ap-5ffc6fc4cc-gjkt9                  0/1     Pending   0          2s
test-ap       test-ap-5ffc6fc4cc-ljmp7                  0/1     Pending   0          2s
test-ap       nginx-8c489f6cf-dthxl                     0/1     Pending   0          22s
test-ap       nginx-8c489f6cf-lsb8q                     0/1     Pending   0          23s
test-ap       nginx-8c489f6cf-p878k                     0/1     Pending   0          2s
test-ap       nginx-8c489f6cf-vdcg9                     0/1     Pending   0          2s
kube-system   alb-ingress-controller-68f5cb8b4b-mshkq   0/1     Pending   0          2s
kube-system   coredns-5fd8748bdd-cf584                  0/1     Pending   0          2s
kube-system   coredns-5fd8748bdd-zdzkm                  0/1     Pending   0          2s

一部のPodが見えなくなり、STATUS(状態)がPending(保留)に変わりました。

この状態で試しにアプリにアクセスしてみます。

$  curl -k https://xxxx/test-ap/login/ -o /dev/null -w '%{http_code}\n' -s
503

503エラーとなりアクセスできなくなりました。

ノードを復旧させる

復旧させる方法は、Auto Scalingグループの設定を同じコマンドでもとに戻すだけです。

#ノードグループ1 の希望する容量を「2」にする
$ aws autoscaling set-desired-capacity --auto-scaling-group-name eksctl-test-ap-nodegroup-z1-nodeg-NodeGroup-1PXBUVII5GDBS \
  --desired-capacity 2

#ノードグループ2 の希望する容量を「2」にする
$ aws autoscaling set-desired-capacity --auto-scaling-group-name eksctl-test-ap-nodegroup-z2-nodeg-NodeGroup-1IHPM2OH5CEW9 \
  --desired-capacity 2

ノードのSTATUS(状態)を確認します。

$ kubectl get nodes
No resources found in default namespace.

実行直後はまだノードの情報は出力されません。
しばらく-wオプションで待機すると、およそ2分ほどでノードの状態が確認できるようになりました。

$ kubectl get nodes -w
NAME                                     STATUS     ROLES    AGE   VERSION
ip-xx-xx-xx-xx.region.compute.internal   NotReady   <none>   0s    v1.20.7-eks-xxxxxx
ip-xx-xx-xx-xx.region.compute.internal   NotReady   <none>   0s    v1.20.7-eks-xxxxxx
ip-xx-xx-xx-xx.region.compute.internal   NotReady   <none>   0s    v1.20.7-eks-xxxxxx
ip-xx-xx-xx-xx.region.compute.internal   NotReady   <none>   0s    v1.20.7-eks-xxxxxx

この時点ではSTATUS(状態)はNotReadyですが、しばらくすると、

$ kubectl get nodes
NAME                                       STATUS   ROLES    AGE     VERSION
ip-xx-xx-xx-xx.region.compute.internal     Ready    <none>   45s   v1.20.7-eks-xxxxxx
ip-xx-xx-xx-xx.region.compute.internal     Ready    <none>   45s   v1.20.7-eks-xxxxxx
ip-xx-xx-xx-xx.region.compute.internal     Ready    <none>   45s   v1.20.7-eks-xxxxxx
ip-xx-xx-xx-xx.region.compute.internal     Ready    <none>   45s   v1.20.7-eks-xxxxxx

STATUS(状態)がReadyになりました。

その後、Podの状態を確認します。

$ kubectl get pods -A
NAMESPACE           NAME                                      READY   STATUS    RESTARTS   AGE
amazon-cloudwatch   cloudwatch-agent-79tfh                    1/1     Running   0          3m41s
amazon-cloudwatch   cloudwatch-agent-fqgzd                    1/1     Running   0          3m51s
amazon-cloudwatch   cloudwatch-agent-gbvbk                    1/1     Running   0          4m1s
amazon-cloudwatch   cloudwatch-agent-nprzt                    1/1     Running   0          4m11s
amazon-cloudwatch   fluentd-cloudwatch-4gfqf                  1/1     Running   0          3m51s
amazon-cloudwatch   fluentd-cloudwatch-5rxrk                  1/1     Running   0          4m11s
amazon-cloudwatch   fluentd-cloudwatch-cd52v                  1/1     Running   0          3m41s
amazon-cloudwatch   fluentd-cloudwatch-p7tx4                  1/1     Running   0          4m1s
test-ap             test-ap-5ffc6fc4cc-4lc8c                  1/1     Running   0          7m31s
test-ap             test-ap-5ffc6fc4cc-d756p                  1/1     Running   0          7m31s
test-ap             test-ap-5ffc6fc4cc-gjkt9                  1/1     Running   0          7m31s
test-ap             test-ap-5ffc6fc4cc-ljmp7                  1/1     Running   0          7m31s
test-ap             nginx-8c489f6cf-dthxl                     1/1     Running   0          7m51s
test-ap             nginx-8c489f6cf-lsb8q                     1/1     Running   0          7m52s
test-ap             nginx-8c489f6cf-p878k                     1/1     Running   0          7m31s
test-ap             nginx-8c489f6cf-vdcg9                     1/1     Running   0          7m31s
kube-system         alb-ingress-controller-68f5cb8b4b-mshkq   1/1     Running   0          7m31s
kube-system         aws-node-54975                            1/1     Running   0          4m31s
kube-system         aws-node-54gjt                            1/1     Running   0          4m31s
kube-system         aws-node-m4lwc                            1/1     Running   0          4m32s
kube-system         aws-node-xw6zn                            1/1     Running   0          4m31s
kube-system         coredns-5fd8748bdd-cf584                  1/1     Running   0          7m31s
kube-system         coredns-5fd8748bdd-zdzkm                  1/1     Running   0          7m31s
kube-system         efs-csi-node-4gvj4                        3/3     Running   0          4m32s
kube-system         efs-csi-node-5v556                        3/3     Running   0          4m31s
kube-system         efs-csi-node-8fln9                        3/3     Running   0          4m31s
kube-system         efs-csi-node-dzfqt                        3/3     Running   0          4m31s
kube-system         kube-proxy-4wdrm                          1/1     Running   0          4m31s
kube-system         kube-proxy-4xtr8                          1/1     Running   0          4m31s
kube-system         kube-proxy-zndfc                          1/1     Running   0          4m31s
kube-system         kube-proxy-zvvxs                          1/1     Running   0          4m31s

すべてのPodが元のRunningに戻りました。

再びアプリにアクセスしてみます。

$  curl -k https://xxxx/test-ap/login/ -o /dev/null -w '%{http_code}\n' -s
200

無事に元どおりアクセス可能な状態に戻りました。

復旧までにかかる時間はトータルで10分程度ではありますが、すべてのノードをコマンド一つで停止し、復旧することができました。

まとめ

Auto Scalingグループの設定を変更するだけで、Amazon EKS 上のEC2インスタンスを停止し、リソース使用料を節約できました。
一時的にPodはPendingになるものの、ノード復旧後も正常にアプリにアクセスすることができました。

その他の使い方

コマンドも簡易であるため、AWS Lambdaなどと組み合わせ、任意のイベントをトリガーとして活用できます。
例えば、チャットに「業務終了」と発言したタイミングでステージング環境を落としたり、定期的に自動実行させることも可能かと思います。