Azure Cache for Redisの落とし穴にはまった話
2.2K Views
October 05, 24
スライド概要
2024/10/05 Japan Azure User Group 14周年イベントのショートセッション資料です
関連スライド
各ページのテキスト
Azure Cache for Redisの 落とし穴にはまった話 2024/10/05 Japan Azure User Group 14周年イベント Shunsuke Yoshikawa
Shunsuke Yoshikawa X: @ussvgr Technical Evangelist @ AP Communications Organizer @ Platform Engineering Meetup Microsoft MVP (Microsoft Azure) 2023/06～ Kubestronaut 2024/07～
おことわり ・本セッションの内容は私が数年前に体験した内容をベースにした フィクション です。 ・現在の仕様や挙動では、お話しするとおりにならない可能性はあります。
こんな構成をつくった
構成 いわゆる一般的なWebアプリケーションを動かすための構成 セッション情報をAzure Cache for Redisに保持する アプリケーションサーバーはLinux
しばらくしたある日 … 開発者「なんかRedisに繋がらなくなってアプリ動かないんだけど」 わたし「マジ？ Azure Cache for Redisは二重化されてるから可用性高いはずでは…」 ※Azure Cache for Redis の Standard レベルと Premium レベルでは、2 つの専用仮想マシン(VM) で各キャッシュをホストすることで冗長性が 提供されます。
当時の調査 ・RedisのFailoverを契機に接続できなくなる ・tcpdumpで挙動を見たところ、 Failover発生時にRedis側から応答がなくなり クライアントが延々とパケットを 再送し続けている ・15分ぐらい再送を繰り返し、 当然その間アプリは機能しない
当時の対応 「Redisに繋がらなくなったらアプリを再起動する」 というパワープレイで対処。 Failoverのメトリックでアラート飛ばしたり、 いくつかの条件をもとにアプリを再起動するよう 「運用でカバー」することに。
改めて事象を調べてみた 公式ドキュメントに該当の事象について記したページが追加されてた 俺がハマってたときにこれさえあればチクショウ … Azure Cache for Redis にレプリカを追加する - Azure Cache for Redis | Microsoft Learn
おそらく当時の問題の原因はコレ 先のドキュメントから引用 俺がハマってたときにこれさえあればチクショウ … > 一部の Linux バージョンの既定の TCP 設定により、 > Redis サーバーの接続が 13 分間以上失敗する ことがあります。 > 既定の設定では、接続が正常に終了しなかった場合に、 > 終了した接続をクライアント アプリケーションで検出して自動的に > 復元できない場合があります。
GitHubにIssueもある .NET用のRedisクライアントライブラリ StackExchange.Redis のIssueに MS社員の方がコメントしている Connection does not re-establish for 15 minutes when running on Linux #1848 端的に言うと 「FailoverするときにFINパケットが飛ばないので クライアントがRedis側の異常を検知できない。 カーネルパラメーターを調整してTCPのリトライ回数を減らすことで、 早期にタイムアウトさせて再接続させよう」
教訓 ● 単一のサービスが高可用な設定だからといって安心してはいけない。 全体の構成で一気通貫で、ちゃんと高可用性を保てているか確認しよう。 ○ ● Azure Cache for Redisであればインスタンス再起動で Failoverを引き起こせる。 Azure Chaos Studioもテストに使えそう。 回復性をもったアプリを作るべきだが、 アプリのレイヤーで救えないケースもある ○ クラウドといえど、時には OS・カーネル・TCP/IPといった知識が必要となることもある。
皆様のAzureライフの一助となれば幸いです