代表的な面接トピック

バックエンド面接:Node.js 22 の安定版 WebSocket を安全に導入するにはどうするか?

バックエンド難しい
Offer.cc 編集チーム公開日 更新日

質問

あるチームが、サードパーティ製 WebSocket ライブラリを Node.js 22 の組み込み API に置き換えたいと考えています。どのように評価し、ロールアウトしますか?

プロンプトとコンテキスト

リアルタイムコラボレーションサービスにおいて、サードパーティの WebSocket ライブラリを使用した数万件の長期接続が存在します。Node.js 22.4 で WebSocket が安定版となったため、チームは依存関係の削減を望んでいます。互換性、ライフサイクル、バックプレッシャー、認証、可観測性、ロールバックを網羅して回答してください。

面接官がテストしている点

API の安定性と本番環境での成熟度を区別できているか、また、制限、ハートビート、ブロードキャストのバックプレッシャー、グレースフルシャットダウン、段階的な移行を設計できるかどうかを確認しています。

明確にすべき質問

クライアントプロトコル、プロキシのサポート、メッセージサイズ、ピーク時の接続数、認証情報の更新、ノード間のファンアウト、再接続、リージョン障害について尋ねます。現在のライブラリが維持しなければならない拡張機能の動作と保証を特定します。

30秒の回答

「API とプロトコルの差異マトリクスを作成し、Node 22.4+、プロキシ、クライアントを検証します。各接続に認証、ハートビート、アイドルタイムアウト、メッセージサイズ制限を設定し、ブロードキャストにはバックプレッシャー対策として有界キューを使用し、シャットダウン時は新規接続を拒否した後にドレインします。シャドウイングとカナリアリリースを実施し、ハンドシェイク成功率、切断数、P95 レイテンシ、メモリ、CPU を比較し、迅速なロールバックのためにサードパーティ実装への切り替えスイッチを維持します。」

ステップバイステップの深掘り

ランタイムとプロトコルの検証

Node のドキュメントでは、v22.4.0 から WebSocket は実験的機能ではなくなったとされています。Node のバージョンを固定し、ハンドシェイク、拡張機能、プロキシのタイムアウト、TLS 設定を検証します。

接続ライフサイクルの設計

接続時に認証と認可を行い、アイドル、ハートビート、切断コードのポリシーを設定します。再起動時は、新規接続の受け入れを停止し、ドレインを行い、再接続のヒントを送信します。

バックプレッシャーとサイズ制限の処理

各接続に有界の送信キューを割り当てます。制限に達した場合は、再構築可能なメッセージを破棄するか、品質を低下させるか、遅延コンシューマを切断します。単一のクライアントがメモリやイベントループを枯渇させないよう、フレームサイズと集約メッセージサイズに上限を設けます。

認証と認可の適用

ハンドシェイク時に短期間有効な認証情報を検証し、機密メッセージについてはテナントとリソースの権限を再確認します。更新に失敗した場合は接続を切断し、再認証を要求します。

複数ノードへのスケール

接続状態はローカルに保持し、イベントはメッセージバス経由でルーティングします。再接続時にすべてを再ブロードキャストするのではなくギャップを再生できるように、サブスクリプションにバージョンまたはカーソルを付与します。

カナリアリリース、監視、ロールバック

社内およびトラフィックの 1% に対して有効化します。ハンドシェイクの失敗、接続維持率、再接続数、キュー破棄数、P95 レイテンシ、メモリ、CPU を比較します。古い実装への切り替えを可能にしておき、プロトコルやリソースのリグレッションが発生した場合は元に戻します。

模範解答

API が安定したという理由だけでライブラリを置き換えることはしません。Node 22.4+、プロキシ、クライアントの互換性を固定した上で、ハンドシェイク認証、ハートビート、アイドルタイムアウト、サイズ上限、有界送信キューを追加します。ノード間では接続状態ではなくイベントとカーソルを共有し、再接続時はギャップのみを再生します。ロールバック用に古いパスを残した状態で、カナリアリリースによりハンドシェイク成功率、切断数、再接続数、キュー破棄、P95、メモリ、CPU を比較します。

よくある間違い

安定した API を完全な代替と同一視すること

ライブラリは拡張機能、圧縮、特定の再接続動作を提供している場合があります。各相違点を文書化してテストしてください。

遅延コンシューマポリシーを省略すること

無制限のキューはメモリを枯渇させます。キューを有界にし、再構築可能なメッセージを破棄するか、切断します。

ハンドシェイク時のみに認可を行うこと

長時間の接続中に権限が取り消されることがあります。機密性の高いアクションには、メッセージレベルのチェックまたはポリシーバージョンが必要です。

再起動時に接続を強制切断すること

再接続ストームが発生します。ドレインを行い、再接続にジッターを持たせ、明示的な切断コードを使用してください。

追加の質問

再接続ストームをどのように制御しますか?

明確な切断理由を返し、クライアント側でジッターを伴う指数バックオフを使用し、サーバー側で IP、テナント、アカウントごとにレート制限を適用します。

サードパーティライブラリをそのまま維持するのはどのような場合ですか?

必要な拡張機能、圧縮、プロキシ互換性、成熟したテレメトリが代替されず、置き換えの価値が低い場合に維持します。評価の境界を記録しておきます。

バックプレッシャーをどのようにテストしますか?

遅延クライアントとバーストブロードキャストを注入し、キュー制限、破棄動作、イベントループ遅延、メモリ曲線を観察します。

ノード間で順序をどのように維持しますか?

サブスクリプションストリームごとに単調増加カーソルを割り当て、バス経由でバージョンを伝達します。クライアントはギャップを検出して再送を要求します。

公開情報ソース

関連する質問