tusで受けて、SFTPで流す: ファイル転送を支える構成と実装

Road to SRE NEXT@福岡
ロリポップ! for Gamers のファイルマネージャ機能において、大容量ファイル転送を実現する構成と実装について紹介します。 採用している connect-web の制約により client-streaming が使えず、初期案としてユーザーインスタンス内にバイナリを配置する方式を検討しましたが、認証・TLS・バイナリのデプロイといった課題に直面しました。 最終的には tus でアップロードを受け、SFTP で転送する proxy アプリを構築。本発表ではその選定理由と構成、Kubernetes との組み合わせなど、裏側を支える設計と工夫を共有します。

Transcript

1. 1 新宮 隆太 ロリポップ‧ムームードメイン事業部 2025.05.09 Road to SRE NEXT@福岡 tusで受けて、SFTPで流す: ファイル転送を⽀える構成と実装
2. 2 ⾃⼰紹介 ロリポップ‧ムームードメイン事業部 forGamersチーム 2021年 新卒⼊社 新宮 隆太 Shingu Ryuta ECサービスのSREを経て、2024/4からロリポップ ‧ムームードメイン事業部でアプリケーションエン ジニアに。 • 趣味はポータブルオーディオ • 家ではLXDとk8sを飼っています • あだ名: ほみるん • X: @h0mirun_deux
3. 3 アジェンダ 1. ロリポップ! for Gamersの紹介 2. ファイルマネージャー機能 3. ファイル転送に関する課題 4. 採⽤した構成 5. まとめ
4. 1. ロリポップ! for Gamersの紹介 4
7. 1. ロリポップ! for Gamersの紹介 7 アーキテクチャ refs: ロリポップ! for Gamersの立ち上げ
8. 1. ロリポップ! for Gamersの紹介 8 技術スタック- Webアプリケーション • connect-go ◦ gRPC 互換の RPC 実装ライブラリで、HTTP/1.1 上でも動作するのが特徴 ◦ Protobuf を使った スキーマ駆動開発が可能 ◦ connect-web を使えば、フロントエンドから直接 RPC を呼び出せる
9. 2. ファイルマネージャー機能 9
10. 2. ファイルマネージャー機能 10 ファイルマネージャー機能とは 開発中の画面です
11. 2. ファイルマネージャー機能 11 • SSHを利⽤せずにゲームサーバー内のファイルを操作で きるようにする機能 ◦ ファイルの各種操作 ◦ ファイルの編集 ◦ ファイルのダウンロード‧アップロード ファイルマネージャー機能とは
12. 3. ファイル転送に関する課題 12
13. 3. ファイル転送に関する課題 13 アップロード Backend インスタンス UploadRPC LXD API fileUpload こんな感じでいいんじゃないか....?
14. 3. ファイル転送に関する課題 14 アップロード Backend インスタンス UploadRPC LXD API fileUpload
15. 3. ファイル転送に関する課題 15 技術的な課題 • connect-webの制約によりclient-streamingが利⽤でき ない ◦ フロントエンド - バックエンド間はconnect-webを利⽤している ▪ connect-webはproxyなしで直接RPCを呼び出せるJSのライブラリ ◦ client-streamingが利⽤できないと通信が途切れたときの再送制御が難しい
16. 3. ファイル転送に関する課題 16 • アップロードされるファイルサイズが数百MB-数GB ◦ ⼤容量転送ではネットワーク帯域を⼀時的に専有してしまう ◦ ユーザー起因で切断されると再送コストが⾼い 事業特性的な課題
17. 4. 採⽤した構成について 17
18. 4. 採⽤した構成について 18
19. 4. 採⽤した構成について 19 • tusでアップロードを受け取り、SFTPでインスタンスへ 直接転送する中継アプリを実装 • 認証認可はシンプルにSFTPの仕組みに乗っかる 特徴
20. 4. 採⽤した構成について 20
21. 4. 採⽤した構成について 21 • ユーザーがインスタンスにファイルをアップロードす るときに利⽤される内製アプリケーション SFTP Proxy
22. 4. 採⽤した構成について 22 • フロントエンドからtusで送られてきたファイルをSFTP でVMインスタンスに流す SFTP Proxy SFTP Proxy tus SFTP
23. 4. 採⽤した構成について • 秘密鍵と転送するファイルを受け取り、受け取った鍵 を利⽤する 23 SFTP Proxy SFTP Proxy tus SFTP
24. 4. 採⽤した構成について • このアプリケーション⾃体に認証認可は存在せず、対 象インスタンスに対して公開鍵認証で接続できるかで 担保 • SFTPで利⽤するキーペアはbackendで⽣成し、LXD APIを利⽤してインスタンスに設定 24 SFTP Proxy
25. 4. 採⽤した構成について 25
26. 4. 採⽤した構成について 26 • HTTPベースのシンプルなファイルアップロードプロトコル • ⼤容量ファイルのチャンクアップロードに対応 • 標準仕様があり、クライアント∕サーバ双⽅の実装が豊富 • 必要に応じてアップロードの再開にも対応可能 技術選択: tus - tusとは
27. 4. 採⽤した構成について • スキーマ駆動開発が⾏いやすい • リクエスト‧レスポンスをProtobufやOpenAPIで定義しやすい • Websocketの場合は実装の⾃由度は⾼いが、双⽅向通信なので定義が難しい • 既存のアプリケーションはスキーマ駆動で開発をしている 27 技術選択: tus - WebSocketとの⽐較 → 一貫性のある開発体験の担保
28. • 再送制御が備わっており、ファイル転送に向いている • 途中でネットワークが切断されても途中から再送できる仕組みがある 4. 採⽤した構成について 28 技術選択: tus - WebSocketとの⽐較 Server 途中から再送 15/100MB 転送済み
29. 4. 採⽤した構成について 29 • もともとSFTPクライアントによる接続を提供していた • SFTPを使えば、すでに確⽴されたファイル操作機能を そのまま活⽤できる 技術選択: SFTP
30. 信頼性‧可⽤性 4. 採⽤した構成について • tusの採⽤による再送制御 • 再送制御による信頼性の向上 • チャンク単位ではなくbyte単位での再送制御なのでretryにかかるコストが最⼩限 30 Server Offset: 0B 0/100MB 転送済み
31. 信頼性‧可⽤性 4. 採⽤した構成について • tusの採⽤による再送制御 • 再送制御による信頼性の向上 • チャンク単位ではなくbyte単位での再送制御なのでretryにかかるコストが最⼩限 31 Server Offset: 0B 15/100MB 転送済み
32. 信頼性‧可⽤性 4. 採⽤した構成について • tusの採⽤による再送制御 • 再送制御による信頼性の向上 • チャンク単位ではなくbyte単位での再送制御なのでretryにかかるコストが最⼩限 32 Server Offset: 0MB 15/100MB 転送済み Offset: 15MB 再送
33. 信頼性‧可⽤性 4. 採⽤した構成について • tusから中間ファイルを作らずstreamingでSFTP転送 • ユーザーから⾒たときの処理の即時性 • sftp proxyまでの転送が完了したのではなくSFTP経由でインスタンスまで転送が完了したとき に、ファイル転送が完了になる • 中間ファイルを管理するボリュームを管理しなくて良い 33
34. 4. 採⽤した構成について 34 • LBの分離 • 普段のWebアプリケーションへのアクセスで通るLBと切り離した • 障害の影響範囲をファイル転送機能に閉じられる • タイムアウトなどの設定もファイル転送の特性に合わせて調整ができる 信頼性‧可⽤性
35. 6. まとめ 35
36. 6. まとめ 36 • ⼤容量ファイル転送には構成と実装の⼯夫が必要。 • ファイル転送においてtus + SFTPを採⽤したことで、運 ⽤保守性と開発体験の両⽅を担保した。 • 構成の選択には多くのトレードオフがあり、背景を意 識した設計が重要だと再認識した。
37. 37 ご清聴ありがとうございました