PHPerKaigi 2024〜10年以上動いているレガシーなバッチシステムを Kubernetes（Amazon EKS） に移行する取り組み〜

PHPerKaigi 2024 の 10年以上動いているレガシーなバッチシステムを Kubernetes（Amazon EKS） に移行する取り組みのスライドです

Transcript

1. © Chatwork 10年以上動いているレガシーなバッチシステムを Kubernetes（Amazon EKS） に移行する取り組み 2024年03月08日　Shinohara Chatwork株式会社 PHPerKaigi 2024. March 8, 2024.
2. 自己紹介 2 • Chatwork 株式会社 コミュニケーションプラットフォーム本部 プロダクト開発ユニット サーバーサイ ド開発部 ◦ Shinohara • 2020年中途入社 ◦ Chatwork のバックエンドの機能開発や改善、技術的負債や開発生産性に対する取り組みを担当 ◦ 直近では Amazon EC2 → Amazon EKS へのバッチの移行をメインで進めている • X ◦ @shi_no_oit • Github ◦ tshinowpub
3. 事業概要 3 • 国内最大級のビジネスチャット「Chatwork」を展開。業界のパイオニアであり国内利用者数No.1*1、導入社数は 43.1万社*2を突破 • 圧倒的な顧客基盤とプラットフォームを背景に、DXされた業務プロセスそのものを提供するクラウドサービス、 BPaaSを展開 BPaaS (Business Process as a Service) ビジネスチャット「Chatwork」 お客様 オペレーター *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2023年5月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む44サービスをChatwork株式会社にて選定。 *2 2023年12月末時点
4. 開発における特徴 4 4 • ビジネスチャットは、業種や職種問わず、全従業員が業務時間中を通して使い続け るという特性を持つ • そのため、トラフィック量が膨大になる傾向 • 24時間365日止めることのできない、ビジネスにおける”インフラ”となるサービス ＝パフォーマンスとシステムとしての信頼性、どちらも高いレベルで担保する必要がある 高い非機能要件 利用ユーザーの多さ 導入社数 ※ 2023年12月末時点 43.1万 登録ID数 664.0万 DAU 110.8万 現状のトラフィック量 www.chatwork.comのCloudFrontのメトリクス。 リクエスト量が現時点（※）で毎分88万ほど。 秒間約1.5万のリクエストをさばいている。 ※ 2022年12月時点
5. 今日のアジェンダ 5 • なぜ Amazon EKS に移行することにしたのか？ • どのように進めていくのか？ • Worker の移行 • Job の移行 • まとめ
6. なぜ Amazon EKS に移行するのか？ どのように進めていくのか？ Worker の移行 Job の移行 まとめ 2. 1. 3. 4. 5.
7. なぜ Amazon EKS に移行するのか？ 7 例えば・・・ • Amazon EC2 と Amazon EKS の 二重運用 • PHPバージョンアップの大変さ • 技術上の課題（今回は触れません） 運用がつらいから
8. Amazon EC2 と Amazon EKS の二重運用 8 • EC2 と EKS の2つの実行環境の管理 ◦ EC2 に至っては権限の関係から環境変数の追加は都度 SRE に依頼する必要がある • 1つチームの中で開発が完結しない Web バッチ
9. Amazon EC2 PHPバージョンアップの大変さ 9 PHP のバージョンアップには、Amazon EKS 側で使用しているイメージのアップデートと Amazon EC2 で 動いているPHPの入れ替えの両方が必要 PHPバージョンアップ 切り離し • 構成管理がメンテナンスされていないため、変更が容 易でない • 詳しいメンバーが社内にいない Amazon EKS イメージを更新して差し替え • ベースのイメージを差し替えるだけ • デプロイも Argo CDでデプロイするのみ
10. なぜ Amazon EKS に移行することにしたのか？ どのように進めていくのか？ Worker の移行 Job の移行 まとめ 2. 1. 3. 4. 5.
11. どのように進めていくか？ 11 • 前提 ◦ 他の言語、他のフレームワークで作り直さない ▪ 別のリプレースプロジェクトが稼動しているため、そもそもの話はそちらで対応する ▪ なるべく工数をかけないために、既存のロジックをなるべく利用 • 最初は既存のバッチを分類するところから始める
12. バッチの分類 12 実際に分類を進めて行ったがバッチが100以上存在することから全てのパターンを洗い出すことを断念 断念するまでに発見した常駐プロセスである Worker と 特定の時間になると実行する Job というルールで分 類、全てのバッチは確認せず不確実な部分を許容しこの分類で移行を開始することに Worker Worker • 常駐プロセス • メッセージキューや DBをポーリング Worker Job • 定期処理 • 特定の時刻に実行
13. Worker（常駐プロセス） 13 • 「Chatwork」 では Amazon SQS や RDS をポーリングするものがほとんど ◦ Amazon SQS は通常のキューは同じメッセージを受信するケースが稀に存在、そのため排他 制御を行っているものも • 画面で同期的に処理するには時間がかかる処理で利用、多くは複数プロセスで動く • 既存のものはメモリリーク等の対策なのか30分で終了する仕組みとなっていた ポーリング ポーリング
14. Job（特定のタイミングで実行される単発の処理） 14 • 一般的にバッチと呼ばれるのはこのタイプ • 一日一回や数時間に一回実行 • 基本的には重複して起動できないものが多い • 数十秒で終了するものから、数十分、数時間実行されるものまで存在 規定の時間に実行
15. なぜ移行することにしたのか？ どのように進めていくのか？ Worker の移行 Job の移行 まとめ 2. 1. 3. 4. 5.
16. Worker の実行基盤の選定 16 • 実行環境 ◦ Amazon EC2 → Amazon EKS へ ▪ 利用料金節約のため、EKS の Node に スポットインスタンス を利用 • プロセス管理 ◦ 独自のプロセスマネージャー → Kubernetes の Deployment で管理 ▪ 1コンテナ1プロセスにする ▪ エラーになった場合は自動で再起動される • スケールイン、スケールアウト ◦ 時間帯によって EC2 の台数を調整 → KEDA や 社内の独自ツール
17. Amazon EKS の Node で使われる EC2 の選定 17 オンデマンド スポットインスタンス 料金 時間単位の課金制（リザーブドは予約することでの割引あり） 使用されていないオンデマンドのインスタンスを最大 90%OFFの価格で 利用できる 制約 特に制約はなし 価格の変動があり料金が高くなったり、オンデマンドの需要が増えたりす ることで停止が発生 終了時には2分間の猶予がありこの時間内にアプリケーションを終了す る必要がある キャパシティの再調整を入れることでこの 2分間での強制終了が発生す る確率を下げることができる 用途 メッセージングなどの高負荷かつ起動に時間がかかるシステ ムで利用 PHPで書かれている大部分で利用 参考： • スポットインスタンス • Amazon EC2 スポットインスタンスの基礎
18. コンテナの終了時の対策（Graceful Shutdown） 18 コンテナの終了時は SIGTERM のシグナルを受け取るので処理を中断して正常終了する処理が必要 Amazon EKS の場合、ローリングアップデート や EC2 の Node であるスポットインスタンス の終了時に呼 び出される PHP では pcntl_signal の関数でシグナルハンドラを設定できる 入れ替え前 入れ替え後 入れ替え後に終了 ※ ローリングアップデートのイメージ
19. アプリケーションの改善 19 • PHP のコードは独自フレームワークで実装されており、ファイルベースのルーティングを採用 • 一般的なフレームワークの Controller 部分のみ名前空間がない状態 • Controller 部分にコマンド系のライブラリ（symfony/console）やDIコンテナ等を載せる • 最近のPHPでの新規開発では独自フレームワークの上にライブラリを動かすことで、Controller 部分以 降をモダンな書き方ができるように調整をしている index.php index_controller.php require_once(“../index_controller.php”) use App/Hoge.php src/App/Hoge.php bin/console {コマンド名} controller.php src/App/Hoge.php require_once(“../index_controller.php”) use App/Hoge.php HTTP
20. スケールイン・スケールアウト 20 サービスの特性から日中の営業時間と夜間で明確にアクセス数の差があることから、以前から時間帯によっ てプロセス数を調整 EKS 上では KEDA というイベントベースで Pod 数を調整できるスケーラーを利用 移行したものは Cron schedule（もしくは同等の社内ツールで調整）、AWS SQS Queue を利用している ※ 他にも標準で Datadog や DynamoDB 等の様々なイベントでス ケールできる 引用：AWS SQS Queue
21. 21 移行して起きた問題
22. 移行してから起きた問題 22 • APM のメモリリーク ◦ NewRelic PHP Agent ◦ ddtrace（Datadog）拡張（特定のPHPの8.x.x と ddtrace の組み合わせ等） • AWS SDK for PHP の Amazon SQS からのメッセージ受信でメモリが増え続ける ◦ すぐに削除できない変数が内部的に残っており、GC が起動するまでメモリが解放されないため gc_collect_cycles を呼び出しGCを実行する ◦ 公式の Issue： Memory leak occurs when SqsClient is continuously called 自前で書いたコードではなく、APMやライブラリ起因で発生 バージョンアップや必要に応じてのGCの手動実行で回避
23. Worker の移行をしてみて 23 • 普段考えなくていい メモリの部分を考える必要が出てくる • APM のメモリリークが頻繁にある ◦ 特に気がつきにくい、特定のPHPのパッチバージョンと APM の組み合わせ
24. なぜ移行することにしたのか？ どのように進めていくのか？ Worker の移行 Job の移行 まとめ 2. 1. 3. 4. 5.
25. Job の実行基盤の選定 25 最初に考えられる選択肢としては Kubernetes の CronJob、しかし • Job が失敗した時に再実行する仕組み や GUIで任意のタイミングやパラメータで実行できる機能が欲 しい • 実行するスケジュールが JST で指定できず、UTCで記載する必要がある（1.27 から可能） という理由から実行基盤の選定から一旦行うことに
26. Job の実行基盤の選択肢 26 Argo Workflows + Amazon EKS AWS Batch for EKS Amazon EventBridge + Amazon SQS FIFO キュー + Worker
27. ArgoWorkflows + Amazon EKS 27 • Kubernetes クラスターに ArgoWorkflows をインストールし スケジューラーやGUI として利用す る • 社内ではすでに CD で ArgoCD を 利用している Workflow として該当の時間に Job を実行する
28. ArgoWorkflows + Kubernetes 28 メリット • ArgoCDに含まれてる Dex を使って権限を一元管理できる • JST のタイムゾーンで Cron をかける • 失敗した時の再実行を ArgoWorkflows から行える • 設定を Kubernetes の manifest ファイルで管理できる = Github で管理できる デメリット • スケジューラーと再実行のためだけに使用するのはオーバースペック ◦ ワークフロー管理するものがあれば良さそう • Kubernetes クラスターを跨いで管理できない
29. クラスターの運用と ArgoWorkflows のインストール先 29 マネージャークラスター アプリケーションクラスター ・マネージャークラスター ArgoCD や KEDA 等クラスターを跨い で利用するものを実行する、アップ デートはインプレース ・アプリケーションが実行され るクラスター EKSのバージョンアップ時には並行運 用され、アプリケーションの担当チー ムが移行を担当する クラスターを跨いだ CronJob を実行できない とアプリケーションクラスターに ArgoWorkflows を入れる必要がある
30. AWS Batch for EKS 30 内部的には EKS のノードである EC2 の起動が入るため処理が開始 するのに少し時間がかかる 引用：Amazon EKS における AWS Batch
31. AWS Batch for EKS 31 メリット • 普段運用しているアプリケーションの Node とは別で EC2 が立ち上がるので他のアプリケーションへ の影響を回避できる ◦ そのためリソースを使う重い処理には向いている • 再実行とかが必要な時に、実行できる人をAWS の認証基盤で管理できる デメリット • 別で EC2 が立ち上がるので、起動までに時間がかかる
32. Amazon EventBridge + Amazon SQS FIFOキュー + Worker 32 EventBridge をスケジューラーとし て利用、 FIFO キューが同一メッセージを排除 する仕組みを利用することでメッ セージを最初に掴んだ Worker が処 理する方法
33. Amazon EventBridge + Amazon SQS FIFOキュー + Worker 33 メリット • AWS マネージドで完結する • クラスターを跨いだ排他制御ができる デメリット • SQS のメッセージの期限が12時間なので実行の上限時間が存在する • Job の実行の管理が terraform で管理することになる ◦ 触る人が増えるとロックの問題が発生しそう
34. 結論：ArgoCD + Kubernetes 標準の CronJob を使う 34 • 一旦は ArgoWorkflows を試したが要件に合わないことや運用コストにあったメリットを得られないた め断念 • ArgoCD 2.8 から CronJob から Job を作成する機能の追加されたこと、そして Kubernetes 1.27 か ら CronJob を JST で記載 できるようになったことから当初課題になっていた部分が解決 • ArgoCD はすでに EKS へのデプロイで利用していたためアップデートすればこの機能が利用できた • ただし再実行をパラメータ付きで行うには工夫が必要
35. Job をリリースして 35 • 技術的に詰まるところはあまりなかったが 実行環境の選定にかなり時間を要した ◦ ArgoWorkflows の検証や AWS のサービスの調査 • 技術的選定は遅らせた方が良いケースもある ◦ 今回は ArgoCD のアップデートで要件を満たすことができた ◦ オープンソースやクラウドサービスの機能は日々アップデートされているので機能の追加によっ て新たな選択肢が生まれてくることも ◦ 最近の例だと Github Action Arm の Runner 等
36. なぜ移行することにしたのか？ どのように進めていくのか？ Worker の移行 Job の移行 まとめ 2. 1. 3. 4. 5.
37. まとめ と 今後の展望 37 • Amazon EKS（Kubernetes） に移行したアプリケーションは 、アプリケーションを開発するチーム単独 で開発〜運用までできるようになった • 基盤は完成したが本年度から他案件の優先度が上がり移行を進めて行くのが難しくなったためプロジェ クトを一旦停止することに ◦ 直近は Amazon Linux2 EOL に対応するためにより低コストでメリットを享受できる方法を探す • 社内で技術的負債や開発生産性に対して組織的に取り組んで行くことに ◦ 現在はフィーチャーチーム体制への移行途中で改善の余地がある状況 ◦ 現状のあるべき姿の可視化し、何から取り組んでいくべきなのか？を定める
38. 38 最後にPR Chatworkでは仲間を募集しています！ もう少し詳しく今日の話を聞きたい方、興味を持っていただけた方は 気軽にDMや以下ページよりご連絡ください！( X: @Chatwork_dev) PHPエンジニア エンジニア 採用ページ