みなさんこんにちは！ エンジニアリングチームリーダー兼SREの杉山です。
今回は「マイクロサービスプラットフォームとしての Amazon EKS 導入」について投稿します！ 第一弾は導入にいたった経緯などをご紹介、以降は細かいところもご紹介できたらな・・・と思っています。
Amazon EKS とは？
みなさん大好きな AWS が提供するマネージド Kubernetes サービスです。Kubernetes コントロールプレーンノードの可用性とスケーラビリティを AWS が自動的に管理することで、チームの運用負荷を大幅に削減してくれる素晴らしいサービスです。私自身、Kubernetes を勉強して Certified Kubernetes Administrator を取得するまでは、実はマネージド Kubernetes サービスのありがたみをイマイチ理解しきれていませんでした。しかし勉強していく中で「コントロールプレーンのコンポーネント管理つらくない・・・？」「 etcd のバックアップを含めた管理まで考えるのか・・・」といったことをひしひしと感じ、改めてクラウドベンダーが提供してくれる価値に気付き、今では毎日感謝しながら過ごしています。
導入のモチベーション
どんな技術もそうかと思いますが、私たちは事業およびプロダクトをグロースさせるためにソフトウェアエンジニアとして活動しています。今回は、サービス変更の柔軟性が損なわれる現在のアーキテクチャをなんとかするために、マイクロサービスへのチャレンジを決断しました。そしてマイクロサービスのプラットフォームとして、コンテナありきのアプリケーションチームの期待に応えるためには、コンテナオーケストレーションが必要となります。すでに myTOKYOGAS のフロントエンドは Azure 上で稼働していますが、これは色々な事情があったがゆえ、当時の私に選択権はありませんでした。
しかし、今回のマイクロサービスプラットフォームは、ゼロからのチャレンジが出来るということで、私はもちろん、チームのメンバーも慣れ親しんでいる AWS を採用することとしました。そのため、純粋に Kubernetes のマネージドサービス同士を比較したわけではなく、ユーザーグループなどのコミュニティが活性であること、ナレッジの多さ、なにより SA (Solutions Architect) の方々自身がユーザーにとっての Trusted Advisor であることから、AWS を選択したという背景があります。もちろん、AWS の他サービス群も素晴らしいものが多いので、そこで不自由することは無いだろうと思っていますし、AWS の機能アップデートは9割がお客さまの声から実現されていますので、そのあたりも AWS の強みであると考えています。
ただ、AWS であれば ECS もありますので、EKS はオーバースペックかもしれない・・・何度かそのように考えました。しかし最終的には継続的に学習するチームの選択として Kubernetes をやっていこう！となったため、 EKS の導入に至りました。
このあたりは JAWS の LT でもお話をさせていただきましたので、以下スライドもご覧いただけたらと思います！
AmazonEKSやっていくことを宣言して自らを追い込むLT
どんな感じで使っているのか？
EKS 導入にあたって、まずは小さく始めています。すでに多くのマイクロサービスが存在し、それらを移行するわけではありませんので、小さく始めて運用しながら、将来的に待ち受けるビッグイベントも早めに検証し、チームのナレッジをためておきたいと考えています（特にクラスターアップグレードは・・・今から緊張します・・・！）
当初は運用負荷を少しでも削減するため Fargate の利用を考えてもいたのですが、 Istio のサイドカーが上手く機能しなかったり、色々あった末にマネージドノードグループの利用となりました。
AWS や Kubernetes 周りのエコシステムとして主に採用しているものは以下のとおりです。
- AWS Load Balancer Controller
- Istio
- Argo CD
- Kustomize
まだまだ少ないですね、今後どんどん検証を進めて導入していきたいです！上記については、それぞれ別途記事にできたらなとも思っています。 その他にも、以下のように現在進行系で進めているものもあります。
監視ツール
専用ツールの導入も考えているのですが、 Container Insights with enhanced observability for Amazon EKS を試行し始めたところでして、この評価結果をもって決めていきたいと思っています。23年11月に発表されたばかりですが、割といい感じです。どうしてもログの二重課金が発生してしまいますし、小さく始める今のフェーズでは充分かなと感じています。
Karpenter
また、EKS ではマネージドノードグループを利用しているものの、こちらも並行して Karpenter を検証しています。提供するサービス・今後提供していくサービスは、一日を通して負荷の見込みが立たないため、Karpenter は上手くハマれば絶大な効果を生み出せるものと考えています。
Bottlerocket
その他にも、プラットフォームチームが利用するマネージドノードグループの AMI として Bottlerocket を採用しています。
Bottlerocket はコンテナを実行するために不可欠なソフトウェアのみが含まれており、アタックサーフェスや管理負荷の削減が可能です。一方、ユーザーデータを設定して渡すようなことができないため、必要となった場合にワークロード用ワーカーノードの AMI が統一できなくなってしまいます。そのため、プラットフォームチームが利用するマネージドノードグループの AMI に限定している次第です。今は主に GitHub Actions の Self-hosted Runner 向けのノードグループの OS として利用・検証しており、ここは別途、メンバーから投稿してもらおうと思っています！
Kubernetes は大変？
大変だと思います。 ただ、それはどんな技術であっても突き詰めれば同じだと思っていますし、チームで納得した上で選択したのであれば、それが最適な選択だと考えています。前述のスライドでも触れていますが、プロダクトはチームで作り上げていくものですので、そこで合意を取って進めていけるのであれば、大変さも楽しみながら進めていけるのかな、と。 また、今は Kubernetes が最適であっても、数年後、また新たな技術トレンドが出てくると思っています。よく振り子のように例えられますが、Kubernetes に Bet するというよりも、そのときのプロダクトやチーム状況に応じて、数年後も同じ軸で判断出来るようにしていきたいです。
さいごに
まずは Amazon EKS 導入の経緯・背景などについてご紹介しました！まだまだ胸を張って「マイクロサービスやってます！Kubernetes やってます！」と言うには程遠いかもしれませんが、この小さな一歩を着実に進めていきたいと思っています！次回の投稿は、AWS Load Balancer Controller + Istio Ingress あたりを書こうかなと思っています（予定）GitHub Actions, Bottlerocket はメンバーが書いてくれる…はずです！
ともに働く仲間を募集しています！
私たちのチームは現在、積極的な採用活動を行っています！ご興味のある方は、ぜひ以下をご覧ください。
Application Developers
www.wantedly.com
SRE
www.wantedly.com
それでは、最後までお読みいただき、ありがとうございました！また次回の投稿でお会いしましょう！
