通信ハンドリング実装で考慮すべきことまとめ

通信ハンドリング実装で 考慮すべきことまとめ 株式会社サイバーエージェント 矢野 春樹 2025.01.14

この資料は部署（コアテク）内で実施している、業務の一部をゆるく共有する会の資料です 実装の詳細などを載せていないライトな内容になりますので、その点ご了承ください

はじめに ● 通信ハンドリング、地味に色々と制御する必要がある ● ちゃんとやらないと面倒な不具合が生まれがち・生産性下がりがち ● やるべきことをざっくりまとめる

ログイン・アクセストークンの管理 ● 一般的にログインを行うとアクセストークンが得られ、それには有効期限が存在する ● リクエスト時に期限が切れていたら、リクエスト前に有効期限のチェックと再認証処 理が必要 ● WebSocketを使っている場合はそちらのセッション切れもチェックする

並列アクセス制御 ● 並列でリクエストメソッドが実行されるケースを考える ● 当然ながらリクエストの通信自体は並列で行うべき ● ただし、最初に届いた一回だけを優先すべき処理もある ● 例: アクセストークンの期限が切れているときに二重で再認証しないようにする

タイムアウト ● 通信に時間がかかりすぎてたらタイムアウトに ● ただしリソースのダウンロードについては、時間で判定すると大きいリソースでエ ラーになってしまう ● 時間でタイムアウトにするのではなく、ダウンロード処理が止まっているかどうかを みて判定

リトライ ● エラーになったら内部的にリトライすべき ● ただしリトライしても意味ないエラー（リクエストパラメータ不正など）もあるので リトライすべきエラーを判定する仕組みが必要 ● リトライ間にはインターバルを設け、インターバル秒数はリトライ回数ごとに増やす ● リトライ回数とインターバル秒数は設定可能にしておく

二重処理防止対応 ● タイムアウト時などにリトライを行うと、同じリクエストがサーバに2回届くケースが ある ● サーバで同じ処理が二重で行われないようにする必要がある ● リクエストに識別子を設けて同じ識別子が処理済みだったら処理しないなど

ログ ● 通信ログは生産性に大きく関わる ● 正常時・エラー時のリクエスト・レスポンス、通信時間、その他必要な情報 ● 外側からON/OFFできるようにしておく

バージョンチェック ● 通信時にクライアントで想定しているバージョンと違ったらエラーにする ● アプリバージョンやマスタデータのバージョンのエラーをスロー ● これをハンドリングしてアップデートを促したり、マスタデータを更新したり

キャンセル処理 ● 一つの通信自体は、リクエストを投げた後はキャンセルできない ● しかし再認証処理の後や、リトライの合間などキャンセルできる契機はある ● そのためキャンセルできるインターフェースにはするべき

暗号化 ● データ盗聴防止 ● データ改ざん防止 ○ こちらはハッシュ検証でも代替可能