kumashun

## 背景 社内で運用するサービスが増え、新しい機能を実現するためにサービス間連携が頻繁に起きるようになりました。サービス間連携で課題になるのはサービス同士の依存関係で、APIを利用する側は利用される側に依存することになります。この関係が1対1ならシンプルですが、1対多や多対多になることがほとんどです。依存関係が複雑になると、APIの仕様変更がどこまで影響するのかが把握しにくくなり、不意に広報互換性が壊れる変更が入って、連携が破綻してしまう可能性もあります。 こうした複雑化する依存関係を改善し、サービス間連携をスムーズにする社内基盤としてPub/Sub基盤を開発した というのが本プロジェクトです。構想自体はTLが既に考えていたので、その実装を行いつつ、追加で考慮すべき要件が上がった際はその解決策の設計から開発まで通しで行うこともありました。 また新規サービス間連携機能の開発で、実際にPub/Sub基盤の導入までサポートしました。一時的に開発チームにjoinして、基盤のユーザー=アプリ開発者に近い立場で導入サポートやトラブルシュートを行うことで、スムーズに導入を進めることができました。機能開発自体もオンスケで進み、シームレスなサービス間連携を社内でアピールする良い成功事例になったと思います。 https://corp.freee.co.jp/news/20231221freee_card_accounting.html ## やったこと ### GoによるPub/Sub基盤のクライアント実装 1stケースとしてAmazon KinesisをStreamとしてPub/Subが設計されていたので、AWS APIをラップする形で、Publisher, Subscriber両々のクライアントをGoの社内ライブラリに実装。元々Rubyでの仮実装が存在していたので、まずそのリプレースから行いました。 実装のコアになる部分はTLの方にリードしてもらい、徐々に1から実装するコンポーネントを増やしていきました。例を挙げると以下。 - Publish, Subscribe双方のlogを収集し、適切にEventが消化されたを定期的に確認するlogmatcher機構 - AWSがサポートするJavaのKCL(Kinesis Client Library)が持つ、KinesisのResharding対応の実装 ### TerraformによるPub/Sub基盤のAWSインフラ構築(Amazon Kinesisなど) インフラ構築は基本AWSで行うため、社内標準であるTerraformを使ってコードベースでKinesisなどを作成。上で述べたlogmatcher機構やResharding対応など、場合によって必要なリソース、パラメータが異なるので、関連するリソースを一括で構築できるようなmoduleを用意しました。 ### Amazon EKS上にPub/Sub基盤用のkubenertesリソースのデプロイ Subscriberは、KinesisとEventを受け取るサービス側との間にworkerを挟む構成をとったため、EKS clusterにそのworkerをデプロイ。こちらも社内標準の仕組みでEKS clusterを構築し、helmfileによるmanifest管理でworkerの構成を管理しました。

## プロジェクト概要 自社で運用しているサービスの多くはコンテナ化され、インフラである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