Cloud Composer 2の検証環境でRedisがメモリ不足に、ABEJAがDAG停止の事象と復旧プロセスを公開

要点

• ABEJAが、検証環境のCloud Composer 2でワークフロー（DAG）が停止したトラブルと、その復旧手順をブログで公開した。
• 原因はワーカーのメモリ不足により強制終了されたタスクがRedis内に残留し、メモリ不足（OOM）を引き起こしたことだった。
• 暫定対応として環境サイズを「小」から「中」に引き上げることでRedisのメモリ容量を増やし、システムの復旧に成功した。
• 恒久対策としてワーカーのメモリ割り当てを見直したほか、タスクキューの長さを監視するアラート設定などを確認した。

リード文

株式会社ABEJAの平原氏は2026年8月5日、同社技術ブログにおいて、検証環境のCloud Composer 2が停止した事象とその復旧対応に関する記録を公開した。Cloud Composer 2は、Google Cloudが提供するワークフロー管理サービスである。今回はタスクキューを担うRedisのメモリ不足（OOM）が発生し、ワークフロー全体が停止するトラブルに見舞われたという。公開された記事では、事象の分析から暫定対応、根本原因の特定と恒久対策にいたるまでが客観的に報告されている。

本文

検証環境で発生したスタック現象と「Celery」の強制終了

トラブルは検証環境でのシステムアップグレード検証時に発生した。すべてのDAG（Directed Acyclic Graph：ワークフローを定義するタスクの関連図）やタスクが「queued（実行待ち）」のまま進まなくなり、監視用ワークフローが停止し、タスク実行環境の「ワーカー」も再起動を繰り返す状態となった。

調査の結果、タスクを一時保管するRedis（メモリ上にデータを保持するデータベース）のメモリ使用量がほぼ100%に達し、Google Kubernetes Engine（GKE：コンテナ型アプリを統合管理するサービス）上のRedis Podも再起動を繰り返していると判明。ログには、非同期タスク処理システム「Celery」（非同期でタスクを処理するライブラリ）のコマンドがメモリ不足で強制終了（Return Code: 9）された記録があった。

異常タスクの蓄積がもたらしたRedisの再起動ループ

平原氏は原因を、ワーカーのメモリ不足に伴う連鎖反応と推測している。メモリ不足で強制終了されたCeleryタスクが未処理のままRedis内に残り続け、メモリを圧迫した。

これにより、Redisがメモリ不足（OOM：メモリ容量の上限に達してシステムが処理を継続できなくなる現象）で再起動ループに陥り、全体のワークフロー処理が停止したという。この際、Airflow上は残留タスクが少なかったものの、Celery側では「未確認タスク」が数万件規模に達していた。

環境サイズの変更によるRedisの暫定復旧

復旧に向け、平原氏がAI「Gemini」に相談したところ、環境サイズ変更によるRedisメモリ増設と、GKE上の永続ボリューム（PVC）削除によるダンプファイル消去の2案が浮上した。

今回は環境サイズを「小」から「中」へ変更する方法を選択。これによりRedisのメモリが増加し、稼働状態へと復旧した。平原氏は、元の環境サイズが最大である『大』だった場合、ボリューム削除や環境の再構築が必要だった可能性があると述べている。

visibility_timeoutの調整と恒久的な構成変更

復旧後は、数万件の未確認タスクを処理して環境サイズを『小』に戻すリカバリに移行した。ワーカーのメモリ不足を解消すべく、CPU割り当てを下げてメモリを増やす構成変更を行った。

しかし、タスク再取得の待機時間「visibility_timeout」がデフォルトの7日間に設定されており、処理に時間がかかる見込みだった。タスクが冪等（べきとう：何度実行しても同じ結果になる性質）であるため、設定値を段階的に短縮して処理を加速させ、未処理タスクを消化した。

恒久対応としてワーカーのメモリ割り当て設定は維持された。また、本番環境で同様の事象が起きないようインスタンスサイズとアラートの設定状況を確認したところ、問題はなかったという。予防策として、タスクキューの長さを計測するメトリクスを用いてキューが過大にならないよう監視する方針を示している。