2025-06-06 日報
- 認知証検診安全管理シートの作成
- イベントのお知らせ送信立会
- お知らせハング対応
- 内部仕様検討ミーティング
- Firebase Functionsの更新位置時を出力するスクリプトを追加
- 未送信者の抽出スクリプト
お知らせハング対応
Section titled “お知らせハング対応”お知らせ関連のファンクションは以下のように分かれており、それぞれの責務が異なっている。
- お知らせのキューにタスクを作成するファンクション
- タスクを処理するファンクション
- LINEメッセージを送信するファンクション
2の処理については、二重に処理されないように修正済みだった。この対応のついでに、1のファンクションについてもメモリを増強していた。しかし、本当にメモリ増強が必要だったのは2と3のファンクションだった。
本日、ステージング環境にて2のファンクションでメモリオーバーフローが発覚。急いで対応し、本番通知の12時にはなんとか間に合わせた。しかし、いざ本番で実行されると、3のファンクションでオーバーフローエラーが発生。
Firebase Functionsの更新日時を出力するスクリプトを追加
Section titled “Firebase Functionsの更新日時を出力するスクリプトを追加”Firebase Functions の大量デプロイ時に発生する問題で、Google Cloud Functions API のクォータ制限により、一括デプロイする際に API リクエスト数の上限に達し、一部の Functions が更新されないまま「デプロイ成功」と表示される現象が発生しています。暫定として、デプロイ後に更新されなかったFunctionsを抽出するためのスクリプトを追加しました。
Stack Overflow や GitHub のリポジトリでも、同様の問題が複数報告されており、大規模な Firebase プロジェクトで共通して発生する課題として認識されているようです。
API 呼び出し（書き込み）60 秒あたり 60というのが根拠だと思われます。 https://cloud.google.com/functions/quotas?hl=ja
API 呼び出し（読み取り）も60 秒あたり 1,200とあるので、追加したチェック用スクリプトもコールしまくると上限に達するので注意ですね。
恒久的には、変更のあったものだけを抽出して、デプロイ対象を分割するなどの自動化が必要です。
未送信者の抽出スクリプト
Section titled “未送信者の抽出スクリプト”最終的に送信対象のユーザーが2,704件となり、そのうち未送信だったユーザーは676件でした。 これらの対象者を抽出するためのスクリプトを実装。
Cursor Meetup Tokyo でれなかったー
Generated at: 2025/6/6 21:26:16