ID:42407さん

##### 背景 - Uber,Wolt,Menuなど複数の配送サービスを管理する配送プラットフォームが開発対象 - ユーザーが「料金優先」「距離優先」などの条件を指定すると、最適な配送サービスを自動的に選択してくれる - ユーザーが指定した時間内にドライバーが見つからない場合、キャンセル依頼を自動送信してくれる ##### 課題 - キャンセル依頼が自動送信された後、次の配送サービスに対して、ユーザーが手動で配送依頼し直す必要があった ##### 要件 - キャンセル依頼が自動送信された後、次の配送サービスに自動的に配送依頼し直してあげる ##### いくつかの設計案 - **案A: 「現在試行中の配送サービス」だけを管理する方式**: 既存の配送依頼テーブルに「今どの配送サービスを試行中か」を管理するカラムを1つだけ持たせる方式。シンプルだが、過去に試行した配送サービスがどういう状態で終わったかが残らない - **案B: 配送サービスごとのステータスを管理する方式（採用）**: 配送依頼ステータステーブルを新規追加し、配送サービスごとのステータス（未募集/募集中/ドライバーマッチ済み/キャンセル済み）を管理する ##### 最終的に選んだ設計案 案Bを採用した。以下がその決め手。 - **障害時の状態追跡**: 案Bなら各配送サービスのステータスが独立して記録されるため、障害発生時にどのサービスがどの状態で止まったかを正確に把握できる - **次候補の算出がシンプル**: 配送依頼ステータステーブルから「未募集」の配送サービスを取得し、ユーザーが選択した優先順に従って次候補を決める。別途キューやリストを管理する必要がない ##### 開発でハマった点・難しかった点 - **キャンセルJobと外部イベントのタイミング競合**: キャンセルJobが発火する前に、外部配送サービスから先にキャンセルされる場合があった。その際、二重にキャンセル＋自動切り替えの処理が実行されてしまった。対策として、キャンセルJob実行時に「対象の配送サービスがまだ募集中か」をステータスで必ずチェックし、既に終了済みならスキップする設計にした - **イベントログのエラーハンドリング**: 初期実装ではログ記録に失敗すると配送処理全体が打ち切られる実装になっていた。チーム内で話し合った結果、「ログは観測用データであり、ログ書き込みエラーで配送処理を止めるべきではない」となり、ログ記録に失敗した時はSentry通知のみ行いメイン処理は継続する設計に修正した

##### 背景 - 在庫管理アプリケーションzaicoでは、画面表示時に発注点切れ在庫件数を毎回DBから取得していた - 発注点切れ在庫件数の取得には、在庫テーブル・発注点管理テーブル・グループ系の中間テーブルなど複数テーブルのJOINが必要だった - 在庫データは数千万件あり、発注点切れ在庫件数の取得に時間がかかっていた ##### 課題 - 発注点切れ在庫件数の取得が遅く、画面表示のパフォーマンスに影響していた ##### 要件 - 発注点切れ在庫件数の取得を高速化すること ##### 前提 - ユーザーと在庫データはそれぞれ複数のグループに所属している（多対多の関係） - ユーザーは自身が所属していないグループの在庫データは参照できない - そのため、同じ事業所であっても各ユーザーによって、発注点切れ在庫件数が異なる - また、Webアプリサーバーは分散化されている ##### いくつかの設計案 - **案A: DBに保持する方式**: 在庫データの更新時に発注点切れ件数を再計算してDBに保存する方式。画面表示時の集計が不要になるが、在庫データの更新頻度が高いため更新のたびに再計算が走りDBへの書き込み負荷が増える。また、実際の在庫データと件数カラムの二重管理になり、不整合のリスクがある - **案B: 事業所単位でキャッシュを取得・削除する方式**: シンプルだが、同じ事業所でもユーザーのグループ所属によって見える在庫が異なるため、不正確な件数が返ってしまう - **案C: ユーザー単位でキャッシュを取得・削除する方式**: ユーザーごとに正確なデータを返せる。ただし在庫データが更新された時に、影響を受けるユーザーを特定して個別にキャッシュを削除する必要があり、削除漏れによる古いデータ表示のリスクがある - **案D: ユーザー単位でキャッシュを取得・事業所単位でキャッシュを削除する方式（採用）**: ユーザーごとに正確なデータを返しつつ、削除は事業所単位でまとめて行う。一部のユーザーのキャッシュが不必要に削除されるが、削除漏れが起きない ##### 最終的に選んだ設計案 案Dを採用した。以下がその決め手。 - **正確性と削除の確実性の両立**: ユーザー単位で取得することで正確な件数を返し、事業所単位で削除することで削除漏れを防げる。多少の過剰削除は「その1回だけ遅くなる」だけで、業務上問題ない - **分散サーバー環境への対応**: サーバー内メモリキャッシュだと、同じユーザーでもアクセス先のサーバーが変わるとキャッシュが効かない。キャッシュサーバーを導入することでどのサーバーからでもキャッシュを共有できるようにした ##### 開発でハマった点・難しかった点 - **キャッシュの有効期限の設計**: 有効期限を長くするとキャッシュヒット率は上がるが古いデータが表示されるリスクが高まり、短くすると頻繁にDBアクセスが発生してキャッシュの意味が薄れる。最終的には、在庫データ更新時に能動的にキャッシュを削除する方式にし、有効期限は「万が一削除漏れがあった場合の安全策」として長めに設定した キャッシュ導入の際の実装メモは以下にまとめています。 [キャッシュ導入の実装メモ](/2024/02/14/RailsCacheRedis/)

##### 概要 - 在庫管理アプリケーションzaicoでは現在の在庫数量と将来の入庫予定・出庫予定の数量を別々のテーブルで管理していた。 - 現在の在庫数量に将来の入庫予定・出庫予定の数量を加味した新しい数量（論理在庫と呼ぶ）を管理できるようにする。 ##### 設計について検討したこと - 論理在庫を新しいテーブルとして管理するか？ - それとも在庫テーブルにカラム追加するか？ - もしくはカラム追加せず、表示するときに毎回計算するようにするか？ - 性能懸念はないか？ など ##### 課題・問題点 - 在庫テーブルは数千万件のレコードを持っており、適切に扱わないと性能懸念がある - 在庫テーブルはアプリの根幹となるテーブルであり、安易に手を加えるのはリスクがある - またzaicoはWebアプリだけでなくモバイルアプリもあるのでそれらの整合性を考慮する必要がある など ##### 最終的に選んだ案、決め手 - 毎回計算する方法だと在庫件数が多い場合の性能低下が無視できないことが判明したので在庫テーブルにカラムを追加する方法を選択した - ただしカラム追加時のALTER実行時に1時間程度時間がかかることが判明したので、メンテナンス時間を設けた - またモバイル対応は後から行うことにし、まずはwebから開発・リリースすることでリスクを抑えた ##### 実装時の工夫 手戻りの少ないように先に画面側のモックを作成し、関係者と認識を合わせておくことで手戻りのリスクを低くした。