🏄‍♂️

「noteのEKS移設、ゼンブ見せます」CNDT2023に登壇しました

2023/12/12に公開

AWS

はじめに

こんにちは、note株式会社でSREをやっています、varu3です。

この記事では、昨日行われた、CloudNative Days Tokyo 2023　の1日目でスピーカーとして発表した内容をざっくりまとめて、noteのコンテナ基盤について紹介するものです。

なお、本記事は「note株式会社 Advent Calendar 2023」の 12日目の記事です。

CNDTめちゃくちゃ楽しかったな〜

noteのEKS移設、ゼンブ見せます

スライド全体は、こちらからアクセスができます

Phase0: 移行の背景と目的

noteは2014年4月からAWS上で動いているコンテンツプラットフォームです、Kubernetesへの移行に取り組む前の2020年時点ではこのような問題を抱えていました。

noteは長年つづく（来年10周年！）サービスなので、インフラ構成は今となってはレガシーなものとなっていました。IaC化されていなかったり、手動運用が多くある状態でした。また設計したエンジニアが不在のリソースや設定が多く、それらが適切に継承されていないというのが大きな問題の一つでした。さらに、現代のベストプラクティスとは言えないネットワーク構成やAWSアカウント、過剰に付与されたIAM権限などセキュリティ面の課題がありました。

このような課題を多く抱える中で、私たちはソフトウェアの式年遷宮という考え方に出会いました。
「式年遷宮」というのは伊勢神宮のような1000年以上続く神社では建物を20年に一度、作り直すという儀式があり、ただ単に建物を補強するだけではなく、それを通じて必要な技術を職人に継承させたり、建物の構造がどうなっているかを知る機会となるものです。

これはソフトウェアでも同じことがいえます。

単にアプリケーションを移設するだけではなくレガシーなインフラ構成全般を見直すため、長年の課題の解決と技術継承をしながら中長期にプロジェクトを進めていくことに注力をしました。メンテナンス性の向上、技術の継承、セキュリティという3つの観点で取り組むべき課題を定めて、それぞれこのような方針で課題に取り組んでいきました。

参考文献

よく言われるのが「なぜKubernetesにしたの？」という質問です。私たちはこの技術選定について３つの観点で考察を行いました。

結果的に「SREメンバーのほぼ全員がKubernetesの開発経験を持っていた」ことが決め手になって、noteのアプリケーション基盤にはKubernetes (EKS)を利用することになりました。

後述しますが、この特性を踏まえて、一部のアプリケーションではECSも採用しています。

Phase1: 移設計画と準備

移設はこのように計画しました。 2020年には note社の別サービスだった cakes をEKSへ移設し、そこで運用の知見やノウハウを貯めて、その後 2021年9月にnoteの移設プロジェクトをキックオフしました。

EKSクラスタを構築する際にこのような構成となりました。　アプリケーションごとにnamespaceとNodeGroupを分けるようにしています。CloudFrontや LBからリクエストを受けて、アプリケーションがそれを処理します。DBにはAurora、KVSにRedisを利用しています。

社内にはさまざまなエンジニアがいるので、Kubernetesの操作する方法を複数用意して、エンジニアなら誰でも簡単に Kubernetesの操作を行うことができるようにしました。

CI/CDにはGithub Actionsを採用して、イベント契機にECS上でセルフホストランナーが起動する tornade（トルネード） という仕組みを作りました。

noteに　(オートスケールするGitHub Actionsセルフホストランナー環境 tornadeの紹介) を書いたので、気になる方はチェックしてみてください。

モニタリング環境はこのようになっています。歴史的経緯もありますが、結果的には DatadogとGraphana + Prometheus を使い分けることで落ち着きました。

特にDatadogは Database Monitoring機能とAPMが大変便利でパフォーマンスの改善に積極的に活用しています。

アラートの整理も必要最小限ではありますが、レベル分けを行って対応方針を明確化しました。

Phase2: 定時のバッチ処理を移設する

ようやくKubernetesへアプリケーションを移設していくのですが、まずは定時バッチ処理です。

バッチ処理も以前はほぼモニタリングがされていないものもあったので、Sentryを導入してアラートを改善しました。

バッチ処理をEC2のcrontabで管理されていたものから、CronJobへ移行していきます。そのためには、このような手順を繰り返しました。

noteのバッチの数はおよそ　２５０つあったので、これを一つ一つ中身を確認して移設作業を進めていきました。

通常の手順だと cronjob を 250つ手動で作らなくちゃいけないのですが、それがあまりにも大変そうだったのでCronjobのデプロイには CronjobManager というカスタムリソースを作りました。

結果、たった３行をYAMLファイルに追加すれば、移植することができるようにしました。

Phase3: 各機能をKubernetes上で動作させる

バッチ処理の移植が終わったので、noteで動いているサブシステムをEKSへ移植していくことにしました。

インポート・エクスポート機能にはArgo workflowsを採用しています。一番の便利ポイントはワークフロー内のPod数を制御できることと、Karpenterと組み合わせることでNodeの待機数を０にできることです。利用されていないときはほぼコストが掛からなくなりました。

note proが提供している独自ドメイン機能には cert-manager を利用して、証明書の発行・管理を行うようにしました。

Phase4: アプリケーションを移設する

それじゃあ、アプリケーションを移設しましょうとはならないですよね。ちゃんとEKSのワークロード上でも性能が出るのか負荷試験を実施して確認します。

負荷試験の心得の３つ目の「細かなパラメータを追いすぎない」というのは、負荷試験はやろうと思えばいくらでもやり続けられるものです。期日の中で性能に直結しやすいパラメータを追うようにして、細かすぎず・深くまではやりすぎないようにしようというのを意識していました。

これは要件によっても変わると思います。深くまでおった方がいいケースとそうでないケースというのが存在すると思います、今回はサービス全体の移設のためこの方針を定めました。

そして、いよいよEC2環境からEKS環境への切り替えです。

CloudFront ContinusDeploymentを利用して、リクエストを振り分けるようにしました。

AWSのドキュメントには

状況に応じて、CloudFront は継続的デプロイポリシーで指定されている内容に関係なく、すべてのリクエストをプライマリディストリビューションに送信する場合があります。

CloudFront の継続的デプロイを使用して CDN 設定の変更を安全にテストする

と記載があるんですよね。

なぜか何も設定をいじっていないのに、EKS側へ振り分けたリクエストが増減する時間があって、なんだろうなとAWSサポートに問い合わせたら、上記のようなことがあるという回答でした。

Phase5: 実運用

元々はEKSのManaged NodeGroupを使っていたのですが、EKSへ切り替えた後に Karpenter というOSSツールを採用して切り替えることにしました。

Cluster Autoscalerの後継に当たるものではあるので本来はNodeのスケールイン・アウトに利用するものです。ところが、思わぬ副次的な効果もありました。それは、Managed NodeGroupのようにNodeのバージョンを管理しなくてもよくなるということでした。

これによって、Kubernetesのコントロールプレーンのバージョンアップ方針を見直して従来よりも工数が少なくバージョンアップ作業を実施することができるようになりました。

Kubernetesになったことで、開発環境を即座に作ることができるようになりました。アプリケーションのブランチだけ指定してワークフローを実行することで、エンドポイントが払い出されてそのブランチのアプリケーションが立ち上がるという仕組みです。

先述のKarpenterと組み合わせることで制限なく開発環境を増やしたり減らしたりすることができるようになりました。

またKubernetesになったことで可観測性が上がりメトリクスやアラートが整理されました。インシデントや障害が発生時のレポートラインや対応をまとめて、社内で何が起こっているのかを逐一共有する仕組みを作っていきました。

というわけで、EKS移設が終わったわけですが、まだ noteはCloudNative Daysのスタートラインに立ったばかりだと思っています。これからもまだまだ改善していきますので、引き続き頑張ります！！

まとめ

レガシーなインフラ構成だったnoteを「ソフトウェア式年遷宮」することで、それを脱却し自分たちが完全に管理できる構成にすることができた。
AWSのマネージドサービスを駆使することで、大きな事故なく EC2 -> EKSへの切り替えを行うことができた。
Karpenterの導入のおかげで、WorkerNodeの管理から解放されアップデート作業などの運用負荷を大幅に下げることができた。
「Kubernetesは難しい」と言われていたが、近年のマネージドサービスの機能の充実によって運用の負担は他のECS等のマネージドサービスと比べてもそこまで高くない。

発表を終えて

CNDTは2019年に一般参加として行って以来の2回目の参加ですが、まさか自分がスピーカーとして参加できるとは思ってもいませんでした。ここ3年ほど note社でやってきたことを全てぶつけた講演ができて感無量です。めっちゃやりきった。

こうやって定期的にアウトプットする機会がめちゃくちゃ大事だなってしみじみと感じました。

CNDTのチェアマン、運営スタッフ・ボランティアの皆さん、スピーカーの皆さん、本当にお疲れ様でした！！

次回もまた登壇ネタが出せるように頑張りたい。

GopherくんとArgoのタコ(?)のぬいぐるみ、めちゃくちゃかわいい、どこで手に入るんだろう…！