この記事は
YAMAP エンジニア Advent Calendar 2020 の 14 日目になる予定です。
頑張るぞ。
tl;dr
AWS を利用しているユーザーなら、多分、AWS Lambda (以後、Lambda と記載) でやってしまうようなことを Kubernetes (以後、GKE と記載) の Cronjob でやってみた感想を書いてみたいと思います。
尚、本記事で登場するツールのバージョンについては、以下の通りです。
$ sw_vers ProductName: Mac OS X ProductVersion: 10.15.7 BuildVersion: 19H15
尚、この記事で書くこと、書かないことは以下の通りです。
書くこと。
- Lambda で出来そうなことを Kubernetes でやってみた感想
書かないこと。
- 具体的な Lambda や Kubernetes の実装やアプリケーションの内容について
- Cronjob の使い方
筆者の Lambda 歴、Kubernetes 歴
永遠の初心者なので、歴 もへったくれもありませんが、Lambda は 2015 年 9 月からチマチマ触っていることが判りました。4 年以上は触っていることになりますが、初心者の域を脱しないまま今に至ります。
Kubernetes 歴 は、無しと言っても過言ではありませんが、一応、今年の年始くらいからはちょくちょく触り始めています。英検で言うと 8 級くらいでしょうか。とにかく、初心者です。
何をやったのか？
で、今回は何をやったのかと言うと、指定した時間に CloudWatch メトリクスの値を集約して Slack のチャンネルに送信する仕組みを実装しました。ざっくり、下図のような構成です。
よくあるやつですね。
Lambda で実装する場合には、コードを書いて、CloudWatch Events で定期的にコードが実行されるように仕込みます。今回、GKE での実装は、Cronjob 機能 を利用して実装しました。
感想
やることは殆ど変わらない
Lambda で実装する場合、Servreless Framework を使うことで、コードを書いて serverless.yml を書くことで簡単にデプロイすることが出来ます。
$ sls deploy --stage=dev
GKE へのデプロイについても、コードを書いて、マニフェストを書いて kubectl apply でデプロイ完了です。
$ kubectl apply -f cronjobs.yml
デプロイという作業で見ると、やることはほぼ同じです。
基本的には、動かす環境によってコードを変える必要がなければ、serverless.yml と Kubernetes マニフェストを両方用意しておけば、簡単に環境の移行が可能になるのかなと考えています。
運用コストとかアプリケーションの可用性ってどうなんだろう
今回作ったものは、仮に動かなくてもサービスや業務に影響が無いものなので、後から手動で実行してもリカバリ出来るものですが、その逆に可用性が求められるようなアプリケーションも動かすこともよくあると思います。ということで、Lambda と GKE の運用コストや可用性が担保されるのか考えてみました。
例えば、Slack の Webhook URL について。下図のように、Lambda を利用する場合には、コード内に直接記載せずに、KMS で暗号化した文字列を記載したり、AWS Systems Manager のパラメータストアに放り込んで、関数が実行する際に API コールで取得して展開するというのが定石だと思います。
今回、GKE 上に実装するにあたり、Slack の Webhook URL は、Kubernetes クラスタの Secret リソースに登録して利用しています。具体的には、sealed-secretsを利用して Secret のリソースを暗号化して管理しており、Pod が展開されると Webhook URL は環境変数にセットされるようになっています。
こうやって、並べてみると、Lambda で実装する場合には、Lambda の実行基盤をはじめ、パラメータストアや KMS 自体は AWS マネージドなリソースとなることが判ります。一方で、GKE 上に実装する場合、GCP 上の GCE インスタンス上に構築された Kubernetes クラスタ上にアプリケーションの実行基盤や Secret リソースが作られることになる為、ユーザーが管理しなければいけないリソースが Lambda 上で実装する場合よりも多くなる為、運用コストは上がると考えています。
ぶっちゃげ、どっちが良いんだろうか
適材、適所、でも、まだ、個人的には ECS や Lambda でも十分なんじゃないかな。。。
正直、今回のアプリケーションを動かすにあたり、GKE はオーバースペックだったのかなと考えています。たまたま、社内のサンドボックス的 (サンドボックス的とは言っていますが、一応、ちゃんと運用管理されています) に作った GKE クラスタが動いていたので、そのクラスタのリソースに余裕があったこともあり、GKE 上で動かす判断をしました。わざわざ、このアプリケーションを動かす為だけに GKE クラスタは構築することはないでしょう。
また、現在、各種アプリケーションを ECS クラスタで運用し、それなりに安定して運用している状況において、敢えて Kubernetes クラスタに移行する必要は無いと思った次第です。
しかし、既にクラスタが存在しているという前提で、コードとマニフェストだけ書けば、簡単にデプロイ出来るというメリットを活かして、シュッと新しいサービスや実験的なアプリケーションを動かす環境としてはとても魅力的だと思います。
また、なんと言っても 流行っているw 点、また、クラスタ構成する各システムや、関連するエコシステムはとても興味深いという意味では、避けては通れない技術であり、「エンジニアの嗜み」としては触っておきたい技術の一つであることは間違いありません。
以上
Lambda で出来ることを Kubernetes でやってみて思ったことをツラツラと書いてきました。もっと、突っ込んだことが書ければよかったんですが、ペラッペラな薄い内容になってしまいました。すいません。
