事後分析: Bad Gateway

概要#

2024-01-11 に、Logto サービスは多くの 502 Bad Gateway エラーを伴うサービス停止を経験しました。

• 開始時間: 2024-01-11 15:28 UTC 頃
• 解決時間: 2024-01-12 00:49 UTC 頃
• 期間: 約 9 時間
• 影響を受けたサービス: Logto 認証サービス、Logto クラウドサービス
• 影響レベル: 重大
• 根本原因: logto.app ドメインが失効し、更新が完了しなかったため。

タイムライン#

• 2024-01-11 15:28 UTC ユーザーが Logto 認証サービスにアクセスする際、502 Bad Gateway エラーを報告。
• 2024-01-11 15:42 UTC より多くのユーザーが同じ問題を報告。
• 2024-01-11 15:50 UTC チームメンバーが問題の調査を開始し、他のチームメンバーに電話。しかし、夜遅くであるため通常の電話では起きられないチームメンバーもいました。
• 2024-01-12 23:54 UTC クラウドサービスが認証サービスにリクエストを送信していることを発見するが、リクエストが ERR_TLS_CERT_ALTNAME_INVALID エラーにより失敗。
• 2024-01-12 00:36 UTC DNS キャッシュを消去してみたが効果なし。
• 2024-01-12 00:38 UTC TLS 証明書を再発行してみたが効果なし。
• 2024-01-12 00:45 UTC logto.app ドメインが失効している可能性に気づく。ドメインレジストラを確認すると、正常に更新されずにドメインが失効していました。
• 2024-01-12 00:49 UTC ドメインの更新が完了。サービスが徐々に正常に戻り始めました。

インシデント分析#

何が起こったのか？#

私たちのドメインは通常、ドメインレジストラを介して自動的に更新されます。しかし、今回の事例では、潜在的な誤設定により更新プロセスが失敗しました。その結果、logto.app ドメインが失効し、DNS 設定がレジストラの駐車ページを指すように更新されました。

現在、認証サービスは稼働していますが、大半のリクエストはそれに到達できません。唯一の例外は、auth.logto.io ドメインにバインドされている Logto 管理テナントであり、失効の影響を受けていません。

認証サービスに加え、Logto テナントを調整し、Logto Cloud Console（フロントエンドアプリ）を提供するクラウドサービスもあります。

ユーザーが Cloud Console を操作する際、アプリは直接認証サービスを呼び出すのではなく、すべての管理操作にクラウドサービスを呼び出します。

Logto Management API に合致するよう、リクエストを認証サービスに委ねるために「Management API プロキシ」エンドポイントを設計しました。全体のフローは次のようになります:

*.logto.app ドメインに証明書不一致の問題があるため、クラウドサービス（Node.js）はリクエストを拒否し、エラーをスローします。

通常、リクエストエラーはサービス全体のクラッシュを防ぐためにキャッチされます。しかし、プロキシモジュールから伝播されたエラーのため、既存のエラーハンドリングロジックではキャッチできず、サービスクラッシュにつながりました。

すべての Logto サービスには少なくとも 3 つのレプリカがあるが、クラウドコンソールからのほぼすべてのリクエストでエラーが発生したため、すべてのレプリカが容易にクラッシュしました。自動回復メカニズムが作動するまでに時間がかかるため、サービスがしばらく利用できなくなります。

これがユーザーが 502 Bad Gateway エラーを目にする理由です（すべてのレプリカがクラッシュ）。クラウドサービスが復旧すると、新しいクラウドコンソールリクエストと再試行リクエストが入り、クラッシュループが続きます。

クラウドサービスが停止すると、認証サービスの特定のエンドポイント、主に /api/.well-known/sign-in-exp にも影響します。このエンドポイントは、クラウドサービスから取得する必要のあるコネクタ情報を含むサインイン体験設定を取得するために使用されます。

解決#

• 手動でドメインを更新する。

得られた教訓#

• ドメインの失効に対する監視を常に設定するか、より長期間で購入する。
• タイムゾーンの違いがインシデント対応に遅れを生じさせる可能性があると認識する。
• すべてのドメインを監視の対象にする。
• 投げる可能性のあるモジュールと対話する際は注意を払い、エラーを適切にキャッチして処理できるようにする。

是正措置と予防措置#

• ✅ 自動更新が有効か否かにかかわらず、ドメイン失効に関する月次監視を追加。
• ✅ logto.app の監視を追加。
• ✅ クラウドサービスのエラーハンドリングロジックを更新し、プロキシエラーを適切にキャッチして処理するようにする。
• ✅ すべてのタイムゾーンをカバーする SRE チームを設置するまで、インシデントに対してチームを起こすことができる強力なアラートを実装する。