kumashun

## プロジェクト概要 自社で運用しているサービスの多くはコンテナ化され、インフラであるkubernetesの実行環境としてはAmazon EKSを利用しています。主力サービスを、従来のEC2インスタンスにデプロイするスタイルからEKSに乗り換えるプロジェクトは成功しましたが、EC2時代に実現できていた仕組みが移行直後はデグレしていました。その一つが canary releaseです。 Canary relaseはデプロイ戦略の一つです。新規リリースの際、インスタンスの数台だけを新しいリリースにして一定期間様子見をしたのち、問題なければ全台を新しいリリースにデプロイ、問題があれば数台だけRollbackすることで、安定したデプロイを行うことができます。 Kubernetesでcanary releaseを実現する方法として、チームではOSSであるArgo Rolloutsを選定しました。EC2時代の仕組みでできた要件を満たすかどうか調べた上で、主力サービスに導入するまでがこのプロジェクトのゴールです。 https://argoproj.github.io/rollouts/ ## チーム情報 SREのうち、CI/CD周りを担当するチームで取り組みました。 プレイングマネージャー、エンジニアx2(自分含む)、インターンx1 ## Argo Rolloutsの機能調査 【概要】 Argo RolloutsがEC2時代のcanary releaseの仕組みでできた要件を満たすかを調査しました。 【どのような機能の開発・実装か】 調査のため実装などの成果物はありませんが、その後の開発方針を決める判断材料を作りました。 【課題・問題点】 EC2時代実施していたsticky sessionをどう実現するかが課題となりました。sticky sessionとはALBの機能で、一定のルールに基づき、1ユーザーからの全リクエストを特定のサーバーに流すことが可能です。canary releaseにおいて、例えば最初のリクエストはcanaryが返して、その後のリクエストでstableが返す、という状況が起きうるのですが、その場合の挙動が不安定になることを懸念して、canaryに当たったユーザーはずっとcanaryが当たり続けるようにするために導入されていました。 https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/sticky-sessions.html Argo Rollouts自体はsessionの管理ができないので、同じことをKubernetesでやるには別のコンポーネントが必要です。 【打ち手・使用した技術】 結論として、Argo Rollouts導入においてはsticky sessionの設定は行わない方針に決めました。sticky sessionの導入経緯は "canaryに当たったユーザーはずっとcanaryが当たり続けるようにするため" ですが、そもそもrolling updateを前提としている環境において、ユーザーごとに処理するサーバーが新旧入り混ざることは避けられません。アプリケーションのデプロイ方針としても、後方互換性を保った変更を行うべきなので、一度canaryに当たった場合リクエストを流し続ける仕組みはそもそも不要であると判断しました。 ## Argo Rolloutsを導入する仕組みの開発 【概要】 EKSにデプロイするkubenertes manifestはhelmfileで管理しています。Argo RolloutsはDeploymentの代わりにカスタムリソースRolloutsを使うことで機能が有効になるので、helmfileに手を加えて、Rolloutsを使用可能にしました。 【どのような機能の開発・実装か】 Deploymentを内包したhelm chartのバージョンを切って、enableRollouts = trueならRolloutsを使うように書き換えました。使いたいclusterに、事前にCRD(Custom Resource Definition)をinstallしておけば、あとはcanary戦略を書くだけで簡単に導入できるようにしました。 【課題・問題点】 仕組みとしては簡単に導入できますが、モニタリングツールでの可視化も必要でした。例えばエラーがcanaryによるものなのかstableによるものかは、デプロイ後監視で見たいものです。 【打ち手・使用した技術】 モニタリングツールであるDatadog、およびエラー管理ツールであるBugSnag向けに以下の対応を行いました。 - Argo Rolloutsには[Ephemeral Metadata](https://argoproj.github.io/argo-rollouts/features/ephemeral-metadata/)といって、canary Podに対してのみ割り当てられるlabelやmetadataを設定することができます。これらを用いてDatadog上でメトリクスを調べることで、canaryとstableで状態を見分けることができました - BugSnagはrelase_stageごとにバグを出し分けており、サービスからは環境変数を使ってrelease_stageを設定していました。Kubernetesの[Download API](https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)を使って上記のEphemeral Metadataを環境変数として渡すことで、Podのcanary/stableごとに動的に環境変数を設定することで出しわけに成功しました

## プロジェクト概要 自社開発サービスの多くはデータベースとしてMySQLを利用しており、その監視ツールとして古くからMonyogを利用しています。アプリケーション全体のパフォーマンス監視はDatadogを利用しているため、バックエンドとデータベースのパフォーマンスを数珠繋ぎに確認する際はDatadogが便利ですが、MySQLのロックの状況確認や問題のあるクエリのkillなどMonyogが有用な場面も依然多いです。 https://monyog.jp/ そのMonyogはサーバー上で直接バイナリを実行することで動かしており、そのサーバーは導入開始当初からアップデートされていません。メンテナンスを継続的に行い、かつインフラ全体の標準構成に揃えるためにも、Monyogをコンテナ化し、kubernetes環境にリプレースさせるのがこのプロジェクトの目的です。 ## チーム情報 リード: 1(自分) エンジニア: 2 MySQLの監視ツールということで、SREのDB周りの専門チームで着手しました。自分は以前SREのコアなチームにいたためkubernetesをはじめインフラに明るかったこともあり、設計から実装プランの計画まで行い、他エンジニアに作業を分担しながら進めました。 ## 監視機能がパフォーマンスを影響を与えないようなライフサイクルの設定 【概要】 Monyogのkubernetes移行で導入したのが、監視機能を定期的にリセットするようなコンテナのライフサイクルです。Monyogはweb画面から様々な機能を利用しますが、UIの操作を誤ると、画面からoffにできなくなった機能が仕様限界になるまで動き続け、監視対象のDBに高い負荷をかけてしまうことがわかりました。画面からoffにできなくなった機能は、Monyogのプロセス本体を停止し、再起動する必要があります。 【どのような機能の開発・実装か】 コンテナをPodとしてデプロイすることになったので、プロセス自体の再起動はPodをrotateすることで可能です。 【課題・問題点】 Podのrorateはkuectlによる手動実行は可能ですが、繰り返し手動で操作するのは大変だし、オペレーションミスを引き起こします。そのためこのrotateを自動で行う必要がありました。 【打ち手・使用した技術】 自動rotateの仕組みとしてdeschedulerを採用しました。名前の通り、設定したルールに基づきPodをevictすることができる仕組みです。このルールのうちpodLifeTimeを設定することで、1時間ごとにPodをevictする=Monyogプロセスを再起動させることができます。 https://github.com/kubernetes-sigs/descheduler?tab=readme-ov-file#podlifetime