> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2021/w05-risk-exposure-of-the-payment-sdk.md).

# W05-決済SDKのリスクへの露出

B2B決済の快驢向け体験改善に取り組む中で、改善前後の変化をよりよく測るため、ユーザーセッション単位の指標を新しく定義した。B2Bの利用体験とサービス性能を、より客観的に表したいからだ。その一環として、新しい指標構造に合わせ、現在のJS SDKが送る計測データを補うことになった。

JS SDKは決済画面にとって極めて重要だ。トラフィックの大半がこのSDKを通じて決済サービスを利用しており、呼び出しは一日約50万回と見込まれる。影響範囲が大きいため、私はSDKを変更する基準をかなり高く置いてきた。ロジックも安定しており、B2B決済に取り組んだこの1年間、一度も更新していない。

計測データの追加自体は、開発量も変更幅も小さかった。それでも公開を前に、私は1週間も引き延ばした。先延ばしの癖ではなく、怖かったからだ。公開過程の至るところでリスクにさらされ、覚悟を決める時間が必要だった。

SDKの公開フローには、制御できない感覚がある。見える範囲が狭く、重要な箇所に操作の手段がない。このSDKはBurstにホストされている。Burstのdashboardと計画を見ると、長く手入れされていない印象を受ける。コードをコミットした後、公開はBurstが提供する一つのコマンドだけに依存する。コマンド実行中はブラックボックスで、完了するとBurstのオリジンサーバー上のリソースが更新される。その後は手動でCDNを更新する。タンポポの綿毛を吹いたようで、どこを飛び、最後にどこへ落ちるかわからない。CDN各ノードの更新状況、全体への反映完了、端末キャッシュの影響でいつユーザーが最新版SDKを使えるか。すべて経験で推測するしかない。段階的な配信もできず、素早いロールバック策もない。さらに、この過程は完全に無言で進み、承認も関係者への通知もない。

公開後に監視できるのはSDK内部の例外だけだ。呼び出し数やサービスの安定性などの技術指標は、BurstやCDN事業者の情報に頼ることになるが、その完全性と正確さには疑問がある。

これらの問題についてowlとlxに相談した。誰も完全な解決策は持っていなかったが、今後のリリース管理に向けた示唆は得られた。JS SDKとNative SDKの大きな違いの一つは、完全に動的になることで生じるバージョン管理の難しさだ。利用側が読み込むSDKのURLを変えられないなら、利用側からバージョンという概念を隠すことになる。

SDK内部にも、グローバルなwindowオブジェクトの汚染など、ほかの問題がある。今年はSDKの管理改善をB2Bフロントエンドの計画に入れる。今は一日数十万件で済んでいても、将来100万件になれば、大きな危険になる。