Backend Architecture on K-Life Hack | 韓国ハイエンド・ライフスタイルガイド

Valkey 8.0 への移行によるキャッシュスループットの改善とレイテンシスパイクの解消

Sat, 23 May 2026 09:55:55 +0900

AIエージェントのバーストトラフィックに伴うRedisの限界と遅延の発生

2026年5月現在、当社のAIエージェント基盤では、Claude CodeおよびCursorからの同時リクエストが急増しており、バックエンドのキャッシュ層として運用していたRedis 7.2クラスターにおいて深刻なパフォーマンス低下が確認されました。特に、ベクトル検索のメタデータキャッシュおよびセッション管理において、P99レイテンシが平常時の2msから150ms以上にまでスパイクする事象が頻発しました。

監視ツール（Prometheus/Grafana）による分析の結果、Redisのシングルスレッドモデルに起因するCPU飽和が原因であることが判明しました。Redis 7系でもI/Oスレッドの分離は可能ですが、2026年のワークロードにおける高度な並列処理要求に対しては、スループットの限界に達していました。これを受け、Linux Foundation傘下で開発が進められているValkey 8.0への移行を決定しました。

発生していた障害の技術的詳細

以下のログは、Redis 7.2ノードで発生していたスロークエリログの抜粋です。AIエージェントが生成する複雑なパイプラインリクエストが、メインスレッドを長時間占有していました。

# Redis Slow Log Excerpt
1) (integer) 1024
2) (integer) 1717143615 # 2026-05-31 14:20:15
3) (integer) 45000 # Execution time: 45ms
4) 1) "MGET"
 2) "session:ai_agent:user_992834..."
 3) "metadata:vector:index_442..."

この遅延により、アップストリームのgRPCサービスでタイムアウトが連鎖し、システム全体の可用性が98.2%まで低下しました。

Valkey 8.0 への移行手順とマルチスレッド最適化の設定

移行にあたっては、Redisとの完全なプロトコル互換性を維持しつつ、Valkey独自のマルチスレッド拡張機能を有効化しました。Valkey 8.0では、コマンド実行自体の並列化が強化されており、特に大規模なMGETやSCAN操作において顕著な性能向上が期待できます。

インストールおよびビルドプロセス

2026年環境の標準パッケージマネージャーである uv を介して依存関係を整理し、以下の手順でビルドおよびデプロイを実施しました。

# Valkey 8.0.1 のソース取得とビルド
git clone --branch 8.0.1 https://github.com/valkey-io/valkey.git
cd valkey
make -j$(nproc)
sudo make install

# 既存のRedis設定からの移行と最適化
cp /etc/redis/redis.conf /etc/valkey/valkey.conf
sed -i 's/redis/valkey/g' /etc/valkey/valkey.conf

スループット向上のための設定変更

Valkeyの性能を最大限に引き出すため、valkey.conf において以下のパラメータを調整しました。特に io-threads の最適化が鍵となります。 🛠️

# valkey.conf optimization for 2026 infrastructure
maxmemory 32gb
maxmemory-policy allkeys-lru
io-threads 8
io-threads-do-reads yes
# Valkey 8.0 specific: Enhanced multi-threading for command execution
server-threads 4
cluster-enabled yes

移行後のパフォーマンス検証とスループット測定

移行完了後、valkey-benchmark を使用して、旧Redis環境との比較検証を実施しました。検証環境は、AWS r7g.2xlarge インスタンス（Graviton 4）を使用しています。

ベンチマークコマンドの実行

# Valkey 8.0 への負荷テスト実行
valkey-benchmark -h 10.0.4.12 -p 6379 -c 200 -n 2000000 -t set,get,mget -P 16 --threads 8

検証結果の比較データ

指標	Redis 7.2 (Legacy)	Valkey 8.0 (New)	改善率
GET スループット (RPS)	420,000	1,350,000	+221%
MGET (10 keys) RPS	85,000	290,000	+241%
P99 レイテンシ (ms)	12.4ms	1.8ms	-85%
CPU使用率 (ピーク時)	98% (1 core)	45% (Distributed)	負荷分散成功

運用監視におけるメトリクスの変化とログ証跡

Valkey導入後、ノードの稼働状況を確認したところ、スレッド間のコンテンション（競合）が最小限に抑えられていることが確認されました。以下は valkey-cli info コマンドによる統計情報の出力です。 💡

# Valkey Stats Excerpt
valkey_version:8.0.1
multiplexing_api:epoll
io_threads_active:1
server_threads_active:4
instantaneous_ops_per_sec:1284902
total_net_input_bytes:15829304822
total_net_output_bytes:89230492833
rejected_connections:0

特筆すべきは、rejected_connections が 0 を維持している点です。旧環境では、TCPバックログの溢れにより、1時間あたり平均150件の接続拒否が発生していました。

発生した課題とトラブルシューティング

移行初期において、一部のクライアントライブラリ（旧式の redis-py 4.x系）で、Valkeyのクラスターバス通信におけるノード認識に失敗する事象が発生しました。 ⚠️

根本原因

Valkey 8.0 の CLUSTER NODES 応答に含まれるメタデータ形式が、一部の古い正規表現ベースのパーサーと競合していました。

解決策

クライアント側のライブラリを、2026年標準の valkey-py または最新の redis-py 5.5.0 以上にアップデートすることで解決しました。また、uv を使用してプロジェクト全体の依存関係を強制的に同期しました。

# 依存関係の更新
uv add valkey&gt;=8.0.0
uv lock

最終確認とシステムへの影響評価

本移行により、AIエージェントからのバースト的なリクエストに対しても、キャッシュ層がボトルネックになることなく、安定したレスポンスを提供可能となりました。2026年5月31日現在の本番環境において、エラー率は 0.01% 未満に抑制されています。

スループット: 従来の約3倍の処理能力を確保。
レイテンシ: スパイクが解消され、P99が2ms以下で安定。
リソース効率: マルチスレッド化により、マルチコアCPUの計算リソースを無駄なく活用。

今後は、Valkey 8.0 の新機能であるベクトルインデックスのネイティブサポートについても検証を進め、AIエージェントの推論高速化に寄与する予定です。

urllib3 Connection PoolにおけるIPS検知時の再試行制御とNATパケット解析

Thu, 21 May 2026 01:33:09 +0900

高負荷マイクロサービスにおけるurllib3コネクションプールの最適化とIPSの影響

高負荷なマイクロサービス環境において、urllib3 Connection Poolの適切な管理は、システム全体のレイテンシとスループットに直結します。特にIPS（Intrusion Prevention System）がインライン配置されたネットワーク経路では、不正トラフィック検知に伴うパケットドロップがコネクションプールの枯渇を引き起こす主要な要因となります。

IPSのインライン配置によるパケットドロップの影響

IPSがdropアクションを実行すると、クライアント側のurllib3はTCPの再送タイマーに基づき待機状態に入ります。IDS（検知のみ）とは異なり、IPSはパケットを物理的に遮断するため、プール内のコネクションが「ESTABLISHED」状態のままハングするリスクを孕んでいます。以下は、Snortを用いたICMPドロップルールの適用例です。

# /etc/snort/rules/local.rules
# alertからdropへ変更し、IPSモードを有効化
drop icmp any any -&gt; 10.10.11.10 any (msg: "ICMP ping Request Inline mode"; sid: 1000001;)

# Snortの実行（インラインモード）
snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -Q

この設定下でクライアントがリクエストを送信した場合、Destination port unreachableが返されるか、あるいは完全にサイレントドロップされ、urllib3側ではReadTimeoutErrorが発生します。💡 タイムアウト値の適切な設定は、このようなゾンビコネクションによるリソース占有を防ぐために不可欠です。

NAT環境におけるパケット構造とコネクション維持

NAT（Network Address Translation）を経由する通信では、L3およびL4レイヤーでIPアドレスとポート番号の変換が行われます。urllib3のHTTPConnectionPoolは、変換後の宛先IP（DIP）に対してコネクションを維持しますが、NATテーブルのタイムアウト設定とプールのkeep-alive設定が不整合を起こすと、無効なコネクションがプールに残留し、通信エラーを誘発します。

[HTTP Request: 192.168.100.10 -&gt; 10.10.11.10]
Before DNAT: |L3 SIP 192.168.100.1, DIP 192.168.100.10|L4 sport 5000, dport 80|
After DNAT: |L3 SIP 192.168.100.1, DIP 10.10.11.10|L4 sport 5000, dport 80|

[HTTP Response: 10.10.11.10 -&gt; 192.168.100.10]
Before SNAT: |L3 SIP 10.10.11.10, DIP 192.168.100.1|L4 sport 80, dport 5000|
After SNAT: |L3 SIP 192.168.100.10, DIP 192.168.100.1|L4 sport 80, dport 5000|

SQLインジェクション検知時の再試行戦略の最適化

特定のシグネチャ（例：UNION SELECT）に基づく攻撃が検知された場合、IPSは即座にセッションを遮断します。urllib3側で無制限な再試行（Retry）を設定していると、遮断されたリクエストが繰り返され、IPSのログを圧迫するだけでなく、アプリケーションスレッドを不必要に占有し続けます。⚠️ 異常検知時のリトライは、指数関数的バックオフを伴う制限的な設計が推奨されます。

import urllib3
from urllib3.util.retry import Retry

# SQLi検知等による遮断を考慮した再試行ロジック
retry_strategy = Retry(
total=3,
status_forcelist=[429, 500, 502, 503, 504],
allowed_methods=["HEAD", "GET", "OPTIONS"],
backoff_factor=1
)

http = urllib3.PoolManager(
maxsize=10, 
retries=retry_strategy,
timeout=urllib3.Timeout(connect=2.0, read=5.0)
)

SnortルールによるUNION SQLi検知の実装

以下のルールは、HTTP URI内のUNIONおよびSELECT文字列を検知し、アラートを生成します。インラインモードでは、これをdropに変更することで、アプリケーション層への到達を未然に防ぎます。🛠️ シグネチャベースの防御は、コネクション管理と密接に連携させる必要があります。

# SQLインジェクション検知ルールの定義
alert tcp any any -&gt; $HOME_NET 80 ( \
msg: "&gt;&gt;&gt; WEB-Attack SQL injection attempt using UNION SELECT &lt;&lt;&lt;"; \
flow:to_server,established; \
content:"UNION"; nocase; http_uri; \
content:"SELECT"; nocase; http_uri; \
pcre:"/UNION.+SELECT/Ui"; \
sid:1000002; rev:1;)

検知時のログ出力例： 06/30-12:33:42.766455 [] [1:1000002:1] >>> WEB-Attack SQL injection attempt using UNION SELECT <<< [] [Priority: 0] {TCP} 192.168.100.1:2508 -> 10.10.11.10:80

インフラ側のIPS挙動とクライアント側のurllib3コネクション管理を同期させることで、異常トラフィック発生時も安定したシステム稼働が可能となります。技術的な整合性を確保することが、マイクロサービス全体の堅牢性を高める鍵となります。