2026 / 03
Camunda 8.8 フルスタックの運用
成果接続の再利用が原因であり接続の古さではないと特定し、調整を積み増すのではなく、検証されていなかったポリシーそのものを撤去しました。
概要
Camunda 8 の全構成（Zeebe、Operate、Tasklist、Optimize、Web Modeler、Keycloak）を単一の公開ドメインの背後で運用し、実は逆効果だった「接続処理の修正」を診断・撤回した記録。
背景
14 個の単一レプリカサービスへ接続ポリシーを追加した後、外部アクセスが遅く感じられるようになりました。
システム
Tasklist182 requests / 88 connections
commonHttpProtocolOptions.maxRequestsPerConnection: 1問題は、追加した「修正」だった。
The fix was the problem.
Evidence over guesswork.課題
「外部アクセスが重い」という報告を追跡した結果、数週間前に未確認のまま追加されていた接続再利用ポリシーに行き着きました。14 個のバックエンドサービスに対し、接続数とリクエスト数がほぼ 1:1 になるよう強制していたのです。
調査
最初の仮説
毎回新しい接続を作れば古い経路を避け、外部アクセスが改善すると考えました。
当初の判断根拠を鵜呑みにせず、Envoy の /clusters 統計で実際の効果を直接検証しました。「修正済み」サービスは 778 リクエストに対し 697 接続、比較対象の除外サービスは通常の接続再利用で 88 接続に対し 182 リクエストという結果に。対象の 14 サービスはすべて単一レプリカだったため、そもそもリクエストごとに新規接続を強制するロードバランシング上の根拠は存在しませんでした。
証拠
commonHttpProtocolOptions:
maxRequestsPerConnection: 1Envoy の実測は 778 リクエストに 697 接続。Tasklist は 182 リクエストを 88 接続で再利用していました。
退けた修正
リクエストごとに新しい接続を強制する設定（maxRequestsPerConnection: 1）は確かに障害パターンを消しましたが、実測すると接続の再利用そのものを壊すことで消していました——778 リクエストに対し 697 接続、一方 Tasklist は 182 リクエストを 88 接続で処理。修正は誤った理由で効いており、その代償は 14 サービスにまたがる不要な接続の作り直しでした。
判断
追加調整を重ねず、検証されていなかったポリシーを撤去しました。
結果
再調整ではなく完全に撤去。判断根拠と Envoy の証拠を記録に残すことで、同じ「未確認の判断」が知らぬ間に再導入されないようにしました。
次に変えること
現在の制約: これはこのクラスターで得た運用上の証拠であり、一般化できる性能ベンチマークではありません。
次の一手: 今後の経路変更に備え、Envoy 統計を再現可能な形で採取します。
関連する記録
778 リクエストに 697 接続 →技術構成
Camunda 8.8 · Zeebe · Keycloak · Elasticsearch · Envoy / kgateway