事後分析: Bad Gateway

2024-01-11 にドメイン更新失敗によって発生した Logto サービス障害のインシデントレポート。

Gao

Founder

1/12/2024

概要

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

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 にも影響します。このエンドポイントは、クラウドサービスから取得する必要のあるコネクタ情報を含むサインイン体験設定を取得するために使用されます。