ポストモーテム: ユーザーサインイン中に予期しない 500 エラーが発生

概要#

2024年7月18日、Logto Cloud は認証サービスからの 500 内部サーバーエラーによりサービスの停止が発生しました。

• 影響を受けたユーザー: 認証を試みたすべてのクラウドユーザー
• 影響を受けた地域: ヨーロッパとアメリカ
• 重大性: 重要、ユーザーのサインインの体験を妨害

根本的な原因#

最近のクラウド展開中に、データベーススキーマの互換性が壊れたため、ステージング環境と本番環境の間で切り替えが行われた時にサインインエクスペリエンス API が失敗しました。

タイムライン#

• 2024-07-18 08:57 (UTC): Logto Cloud に更新がデプロイされました
• 2024-07-18 09:28 (UTC): 最初のユーザーが 500 エラーを報告
• 2024-07-18 09:31 (UTC): 開発チームが問題を認識して調査開始
• 2024-07-18 09:32 (UTC): 問題が自動的に解決される
• 2024-07-18 09:40 (UTC): 根本原因を特定

インシデント分析#

データベースの互換性を壊す変更とは何か、そしてなぜ行われたのか？#

現在、「Bring your UI」と呼ばれる新機能を開発中です。この機能により、ユーザーは Logto のサインイン体験を独自のウェブページでカスタマイズできるようになります。この機能のために sign-in-exp テーブルに新しいカラムを追加し、カスタム UI 設定を保存する必要がありました。

開発中に要求の変更があったため、この機能のリリースが遅れていましたが、スキーマ変更の最初の部分はすでに数週間前に本番環境にデプロイされていましたが、まだ使用されていませんでした。このデータベースカラムの更新は この PR によって導入されました。

残念ながら、この変更は後方互換性を持っておらず、新しいデータベースと通信する際に旧コードからの API リクエストが失敗する原因となりました。

Logto Cloud の新バージョンをどのようにデプロイしますか？#

Logto Cloud の新バージョンをデプロイする際、まずステージング環境にデプロイし、その後ステージング環境と本番環境を切り替えます。プロセスは以下の通りです:

1. データベース変更スクリプトを実行し、データベースを更新します。
2. 新しいソースコードをステージングサーバーにデプロイします。
3. ステージングサーバーを起動し、テストを行います。
4. 「ステージング」と「本番」サーバーを入れ替えて、ユーザーがダウンタイムなしで新しいバージョンにアクセスできるようにします。

しかし、両方の環境では同じデータベースを共有しており、全プロセスには時間がかかります。データベースの更新と環境の切り替えの間の時間帯では、オンラインユーザーはまだ本番環境におり、旧コードで新しいデータベースと通信しようとします。

これがインシデントの根本原因であり、問題が 35 分以内に自動的に解決された理由です。

なぜこれはコードレビューで対処されなかったのですか？#

我々はデータベースの後方互換性をチェックする CI タスクを持っています。しかし、以前は PR をマージする前に CI チェックを通過することが必須ではありませんでした。これは、大部分の開発フェーズは短期間で行われ、初期と後続のスキーマ変更は通常同じリリースフェーズで行われるからです。

今回は、機能リリースが遅れたため、スキーマ変更が 2 回のリリースにまたがって行われました。開発者は CI の失敗は予想されるものだと考え、レビューアーに対して PR のマージを妨げないように伝えました。

コミュニケーションのギャップもあり、最終的に必要な後方互換性のサポートなしに PR がマージされました。

教訓#

• データベーススキーマに互換性が壊れる変更を加える際は、常に旧バージョンのソースコードとの後方互換性を考慮すべきです。
• データベースカラムを変更する際は、スキーマに直接変更を加えるのではなく、廃止と移行アプローチを使用すべきです。
• 開発者はリリースプロセスとタイムラインに対する意識を高めるべきです。

是正および予防措置#

• ✅ データベース後方互換性の CI チェックは、スキーマの変更を含む PR をマージする前に必ず通過することが求められます。
• ✅ チーム内で後方互換性の重要性を強調します。