接客サービス配信の不具合に関するご報告

2019/09/17 11:20頃 - 2019/09/17 13:01 頃に発生しました、管理画面で設定した配信トリガーとは異なる条件で接客サービスが配信されてしまう不具合につきまして、下記の通りご報告させていただきます。

なお、本不具合の影響を受けたお客様につきましては、影響範囲の詳細をご説明するご連絡を、メールにて個別に送信させていただきました。そちらにつきましても併せてご確認ください。

1. 発生した事象

• 事象(1)

  • 特定の条件を満たす接客サービスが、最新の配信トリガー設定ではなく、2019/09/17 11:20 時点の配信トリガーをもとにして配信が行われるという事象が発生しました。

• 事象(2)

  • 特定プロジェクトの特定の接客サービスの配信における「対象イベント（配信トリガー）」において、条件を設定しているにも関わらず、条件が無視され、セグメント条件のみで配信が行われるという事象が発生しました。

2. 発生期間

2019/09/17 11:20頃 - 2019/09/17 13:01 頃

3. 影響を受けたプロジェクト / 接客サービス

• 事象(1)

  • 対象接客サービス

    • 2019/09/17 11:20 頃 - 2019/09/17 12:41 頃の期間中に作成 / 変更された接客サービス

• 事象(2)

  • 対象プロジェクト:

    • 2019/09/06 12:04 頃から 2019/09/17 11:20 頃まで接客サービスを一度も作成・変更していないプロジェクト

  • 対象接客サービス

    • 2019/08/06 12:01 頃から 2010/09/17 11:20 頃までに新規作成されていない接客サービス
    • かつ、2019/08/06 12:01 頃から 2010/09/17 11:20 頃までに変更されていない接客サービス
    • かつ、何らかの配信トリガーが設定されているサービス

4. 原因

管理画面の機能追加のための一連の変更によるものです。

今回、管理画面の「対象イベント（配信トリガー）」部分において、「or条件」を指定できるようにするための機能追加を行いました。これに伴い、同機能のデータ保持方法が変更となったため、データを2系統（従来のデータを trigger 、新たなデータを trigger_v2 と呼びます）用意し、下記の順番で、データ移行および画面のリリースを実施しました。

• 2019年8月6日

  • 接客サービス保存時にtrigger のデータを trigger_v2 にコピーする処理をリリース

• 2019年9月6日

  • 過去の全ての trigger のデータを trigger_v2 へのデータ移行を実施

• 2019年9月17日

  • 管理画面のリリースを行い、管理画面およびTrackサーバーは全て trigger_v2 側を参照するに設定

事象(1)の原因

9月17日のリリース後、別のエラーが原因で、Trackサーバーのみをリリース前の状態に切り戻しました。そのため、以下のような状態となりました。

• 管理画面の設定内容は trigger_v2 に保存されている
• Trackサーバーからの接客配信は trigger を用いて行われる

このため、管理画面の設定とは異なるデータで配信が行われてしまいました。

事象(2)の原因

配信の実動作の際には、パフォーマンス向上のため、キャッシュレイヤーを設けた上で、データ部分を直接参照するのではなく、キャッシュ部分を参照していました。このキャッシュは、管理画面から接客サービスを作成・編集したタイミングで更新され、一つでも接客サービスが作成・更新されれば、該当プロジェクト内の全てのキャッシュデータが更新される仕組みでした。

しかしながら、今回の機能追加では、 管理画面の操作を介さない方法でtrigger から trigger_v2 へとデータの直接移行を行っており、trigger_v2 に対応するキャッシュ部分が生成されないままの状態でした。

そのため、データ移行を行った9月6日から、機能全体がリリースされた9月17日までの間に、一度も接客サービスの作成・編集を行わなかったプロジェクトでは、 trigger_v2 に対応するキャッシュ部分が存在しない状態が維持されていました。

KARTEでは「対象イベント（配信トリガー）」が存在しない場合「全配信」と判定されてしまうため、結果として管理画面の設定とは異なるデータで配信が行われてしまいました。

5. 恒久対応・再発防止対応

該当機能に関しては、問題点を修正した上で、再度リリースを行います。

また、再発防止対応として以下の検討・対応を行います。

• trigger のキャッシュに対するTTL（Time to live : データが破棄・再生成されるまでの時間）の設定
• trigger が空だった場合の処理の見直し（全配信されるのではなく、配信されない側に倒す）
• データ移行を伴う機能改修における後方互換性維持の徹底
• データ移行を伴う機能改修における、リリースフローおよび切り戻しフローの見直し

上記以外に関しても、システム的な誤配信を排除するために有効だと思われる手段については、随時積極的に採用していく予定です。

このたびはご迷惑をおかけしてしまい、誠に申し訳ございませんでした。