Developers IOで発生したブログ障害について(2022年12月2日PM発生)

日本時間 2022 年 12 月 2 日 (金)の午後、 当ブログサイト(DevelopersIO)で発生していた障害についての報告です。
2022.12.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

re:Invemt2022の re:Play 開催中、 2022年12月2日 13:15 ~17:30 (日本時間) に発生していた、DevelopersIOのブログ障害について共有させていただきます。

公式ツイート

事象内容

  • 個別記事、記事一覧ページを有効でURLで開くと、「404」案内ページが表示される状態でした。

正常応答率の変化

対応時系列(JST)

  • 13:15 障害発生
  • 13:30 社内報告をうけ、調査に着手
  • 15:00 Lambda関数で発生していたエラーを特定
  • 15:30 実行環境交換、 キャッシュクリア
  • 16:45 エラー回避のパッチ完成
  • 17:15 パッチを評価後、デプロイ
  • 17:30 復旧確認

原因

不要な Authorization ヘッダー

WordPress をヘッドレスCMSとして 公開済みの記事データを参照、HTMLを生成する SSR (Server Side Rendering)用の Lambda関数で、 不要な Authorization ヘッダーが付与されていました。

export const getPost### = async (slug: string) => {
  const response = await axiosInstance.get<Post[]>(`${endpoint}`, {
    auth: config.auth
  })

当設定は、SSR利用の初期段階で、Basic認証で保護された検証環境を利用するためのものでした。

WordPressのアプリケーションパスワード設定

正規CMS利用者(執筆者)が、自身の権限で WordPress APIを実行する事を意図して、アプリケーションパスワード が新規に登録されました。

アプリケーションパスワードを設定したユーザーが存在しない WordPress は、 無効な Authorization ヘッダー が リクエストヘッダー に含まれている場合でも、認証を必須としない WordPress のAPIを利用可能でした。

  • アプリケーションパスワード設定前
$ curl -u user:password https://example.com/wp-json/wp/v2/statuses/ -s | jq .
{
  "publish": {
    "name": "公開済み",
    "public": true,
    "queryable": true,
    "slug": "publish",
    "date_floating": false,
    "_links": {
      "archives": [
        {
          "href": "https://example.com/wp-json/wp/v2/posts"
        }
      ]
    }
  }
}

アプリケーションパスワードが設定後のWordPress は、 リクエストヘッダーに Authorization ヘッダーが存在する場合、その値を評価する様になり、 認証エラー(401)が発生するようになりました。

  • アプリケーションパスワード設定後
$ curl -u user:password https://example.com/wp-json/wp/v2/statuses/ -s | jq .
{
  "code": "invalid_username",
  "message": "<strong>エラー</strong>: 不明なユーザー名です。もう一度確認するか、メールアドレスを入力してください。",
  "data": {
    "status": 401
  }
}

対策

今回、暫定対策として、以下を行いました。

  • Lambda関数の修正。 無効な Authorization ヘッダーの付与撤去。
  • 認証失敗により生成されたネガティブキャッシュデータの削除

まとめ

想定外の障害でしたが、社内各方面からの支援により半日程度で復旧ができました。 ご協力頂いた方々、この場を借りてお礼させていただきます。

今回明らかになった各種テスト不足や、エラーハンドリングなどの課題については、逐次改善を図りたいと思います。

根本対策としては、類似の障害が発生した場合でもサービス影響を極小化できる仕組みの実現。 Amazon S3を筆頭とする非機能要件に優れたサービス、より疎結合に活用する方向で検討を進めていきたいと思います。