Serverless Opens the Future of File Sharing Services

サーバーレスでファイル共有サービスの未来を切り開く〜 Backlogにおける価値あるレガシープロトコルとの付き合い方 〜
DevelopersIO 2024 FUKUOKA Day1

GitHub：https://github.com/vvatanabe
X：https://twitter.com/vvvatanabe

Transcript

1. DevelopersIO 2024 FUKUOKA Day1 Yuichi Watanabe Copyright Nulab Inc. All Rights Reserved. サーバーレスで ファイル共有サービスの未来を切り開く 〜 Backlogにおける価値あるレガシープロトコルとの付き合い方 〜
2. イントロダクション Copyright Nulab Inc. All Rights Reserved.
3. 渡邉 祐一 Yuichi Watanabe 株式会社ヌーラボ サービス開発部Backlog課 2015年より株式会社ヌーラボの一員として、アカウ ント基盤「Nulab Apps」の開発を手掛けた後、Backlog に関わりました。一時期SREとしての役割を経て、再 びBacklogのチームへと戻りGitホスティング領域の開 発と運用を支えています。 X：https://x.com/vvvatanabe GitHub：https://github.com/vvatanabe 自己紹介 Copyright Nulab Inc. All Rights Reserved.
4. ▪ “進んでるね！”で、チームは進む。 みんなで使う簡単、便利な プロジェクト・タスク管理ツール。 タスク管理や Wiki など情報共有に関する豊富な機能がオ ールインワン 直感的に操作が可能なインターフェース SaaS版 / インストール版の2つの形態で提供 ▪ ▪ 担当者・期限を明確に チームのタスクを、担当者や期限を明確にして課題 を予定通りに完了させましょう。課題の更新は Backlogやメールで受け取れます。 ガントチャートで可視化 プロジェクト計画をガントチャートで可視化します 。メンバーの進捗を把握することで、作業の遅延に いち早く気づけます。 Wikiでドキュメント管理 Backlog Wikiは個人メモ、会議の議事録、作業マニュ アル、仕様書などチームメンバーに向けた情報を文 書で管理します。リンク共有やPDF出力にも対応し ています。 出先からも楽々！モバイルアプリ 無料で使えるBacklogモバイルアプリ（iOS / Android サポート）を利用すれば、外出先でもプロジェクト の進捗を確認したり、課題の追加やコメントを投稿 できます。 Copyright Nulab Inc. All Rights Reserved.
5. Copyright Nulab Inc. All Rights Reserved.
6. Copyright Nulab Inc. All Rights Reserved.
7. Copyright Nulab Inc. All Rights Reserved.
8. アジェンダ ファイル共有機能の現在 ファイル共有機能の課題 サーバーレスなアーキテクチャの考察 1 2 3 ケース毎の課題と解決策 4 まとめ 5 Copyright Nulab Inc. All Rights Reserved.
9. ファイル共有機能の現在 Copyright Nulab Inc. All Rights Reserved.
10. ファイル共有機能の現在 現行のアーキテクチャ ・Backlog本体と分けてファイル共有機能に特化したファイルサーバーを提供。 ・ストレージを本体に持たせると本体がスケールできなくなるため。 ・Backlog本体とユーザーはファイルサーバーにWebDAVプロトコルで接続。 ・複数のファイルサーバーが一定のグループ毎に割り振られる。 ・グループに応じて適切なファイルサーバーへ接続される。 AWS Cloud ※ コンポーネント間のLBは省略 File File File 本体 WEB File WebDAV WebDAV Copyright Nulab Inc. All Rights Reserved.
11. ファイル共有機能の現在 Apache HTTP Server と mod_dav mod_perl ・バックエンドのミドルウェアとしてApache HTTP Serverを使用。 ・mod_davモジュールでWebDavプロトコルをサポート。 ・mod_perlモジュールでBacklog特有の処理を拡張を実装。 ・時代の流れとともに、ApacheやPerlに詳しい人材は減ってはいるが... ・安定した機能を提供してくれる歴戦の戦士 AWS Cloud ※ コンポーネント間のLBは省略 File File File 本体 WEB File WebDAV WebDAV mod dav mod perl Copyright Nulab Inc. All Rights Reserved.
12. ファイル共有機能の現在 AWS Cloud Amazon EC2とEBS ※ コンポーネント間のLBは省略 File File File 本体 WEB File WebDAV WebDAV ・ファイルの保存先となるストレージはAWSのEBS。 ・EBSを使う兼ね合いでファイルサーバーはEC2を使用。 ・ファイルサーバーは複数のEBSをマウントしてディスク容量を拡張。 ・ファイルは一定のグループに分けて特定のEBSに保存。 mod dav mod perl Copyright Nulab Inc. All Rights Reserved.
13. ファイル共有機能の課題 Copyright Nulab Inc. All Rights Reserved.
14. ファイル共有機能の課題 ・EC2のセキュリティアップデート ・ディスク拡張 ・OSのEOLに伴うEC2の入れ替え オペレーションのコスト ・サーバーが状態（ストレージ）を持つため、状態を持たないコンテナと比べてスケールしにくい。 スケールアウトの難しさ ・使用しているEBSのタイプは汎用 SSD (gp3) ・ストレージの料金はプロビジョニングした容量 (GB/月) で決まる ・月で0.096USD per GB (アジアパシフィック東京) 例. 100TB * 0.096USD = 9600USD(1536000円) 1USD / 160円で換算 ・円安の影響が辛い😭 ストレージのコスト Copyright Nulab Inc. All Rights Reserved.
15. ファイル共有機能の課題 オペレーションコストとストレージの費用が抑えられるものは？ 2. Amazon EFS ・複数のAZで冗長化。 ・EC2やFargateからマウント可。 ・費用は高め。 ・月で0.36USD per GB (東京) ・定期的なディスク拡張作業不要 1. Amazon EBS ・パフォーマンスはEBS一択。 ・複数のEC2から同時書き込み不可。 ・月で0.096USD per GB(東京) ・定期的なディスク拡張作業必須 2. Amazon S3 ・複数のAZで冗長化。 ・ファイルシステムでとして使用するには、 Mountpoint for Amazon S3等のツールが必須。 ・低コスト。 ・最初の50TB、0.025USD per GB(東京) ・ストレージをサーバーの外に置けるので、ア プリのコンテナ化も容易になる。 Copyright Nulab Inc. All Rights Reserved.
16. サーバーレスな アーキテクチャの考察 Copyright Nulab Inc. All Rights Reserved.
17. サーバーレスなアーキテクチャの考察 ファイル共有機能の前提 ・RFC 3744（Web Distributed Authoring and Versioning, 通称WebDAV）のサポート ・Webサーバーをファイルサーバーとして利用するためのプロトコル。 ・HTTPを拡張しており、以下の主要な機能を提供する。 1. ファイル管理: ファイルの作成、編集、削除、コピー、移動。 2. ディレクトリ操作: ディレクトリの作成、削除、移動。 3. メタデータ管理: ファイルに対してプロパティやメタデータを設定、取得することができる。 4. ロック機能: ファイルやディレクトリをロックして、複数のユーザーによる同時編集を防ぐことができる。 ・ファイルはBacklogのプロジェクト毎に集約される。 ・ストレージの冗長化、バックアップ Copyright Nulab Inc. All Rights Reserved.
18. サーバーレスなアーキテクチャの考察 Amazon S3（Mountpoint for Amazon S3）の機能と制限 高レベルな可用性と耐久性のストレージを低コストで利用できるAmazon S3を使用したい。 Mountpoint for Amazon S3の検討： ・Amazon S3 バケットをローカルファイルシステムとしてマウントするためのツール。 ・Amazon S3はシンプルなKVSなので、階層構造特有の操作をサポートしていない。 ◯ 既存のファイルを一覧表示して読み取ることができる。 ◯ 新しいファイルを作成することもできる。 ✕ 既存のファイルを変更できない。 S3はアトミックにキーをリネームできない。（Copy->Deleteが必要） ✕ ディレクトリを削除できない。 S3はキープレフィックスが同じオブジェクトをアトミックにまとめて削除できない。 結論： ・Mountpoint for Amazon S3ではファイル共有機能の要件を満たせない。 ・Amazon S3のAPIを使ってファイルの実態の保存先として使う分には問題ない。 ◯ List Mountpoint for Amazon S3 ◯ Put ✕ Move ✕ Del dir /foo/bar/a.png /foo/bar/b.png /foo/bar/baz/c.png /foo/bar/baz/d.png 例. /foo をアトミックにリネーム・削除できない。 Copyright Nulab Inc. All Rights Reserved.
19. サーバーレスなアーキテクチャの考察 DynamoDBの機能と制限 ・Amazon DynamoDB は、フルマネージド NoSQL データベースサービス。 ・データテーブルを定義して一つのレコードに複数のプロパティを持たせることができる。 ・基本的にはKVSのようにユニークなキー（プライマリキー）を指定してデータを取得する。 ・インデックス（グローバルセカンダリインデックス等）を使うことでプライマリキー以外を指定してデータを取得できる。 ・設計次第で階層構造を表現したり、複数のプロパティを管理できる。 id UUID2 parent_id UUID1 name foo type Directory id UUID3 parent_id UUID1 name bar type Directory id UUID4 parent_id UUID1 name README.md type File id UUID7 parent_id UUID3 name hoge type Directory id UUID5 parent_id UUID2 name baz type Directory id UUID6 parent_id UUID2 name apple.png type File id UUID1 parent_id name root type Directory Copyright Nulab Inc. All Rights Reserved.
20. サーバーレスなアーキテクチャの考察 DynamoDBの機能と制限 ・DynamoDB の項目の最大サイズは 400 KB。 ・ファイル共有機能のユースケースでは、ファイルの実態は 400 KB 以上になることはよくある。 ・圧倒的容量不足。 バイナリデータなどサイズが大きくなりやすいデータは保存できない。 id UUID2 parent_id UUID1 name foo type Directory id UUID3 parent_id UUID1 name bar type Directory id UUID4 parent_id UUID1 name README.md type File id UUID7 parent_id UUID3 name hoge type Directory id UUID5 parent_id UUID2 name baz type Directory id UUID6 parent_id UUID2 name apple.png type File id UUID1 parent_id name root type Directory 400 KB制限 Copyright Nulab Inc. All Rights Reserved.
21. DynamoDB S3 ファイルのメタデータ ファイルの実態 サーバーレスなアーキテクチャの考察 S3でファイルの実態を、DynamoDBでファイルのメタデータを管理する ・ファイルの実態と階層構造・プロパティ（メタデータ）を分けて考える。 ・S3でファイルの実態を、DynamoDBでファイルのメタデータを管理することで容量不足を補う。 ・S3オブジェクトのキーにUUID等のユニークなIDを使用する。 ・DynamoDBアイテムのIDにS3オブジェクトのキーを指定して紐つける。 Attributes Key Type Desctiption id PK string ユニークなID 例. UUID parent_id GSI string 親ディレクトリのID name string ファイル、ディレクトリ名 例. report.pdf type string ファイル、ディレクトリの種別 例. File or Directory size number ファイルサイズ 例. 512 modify string ファイルの更新日時 例. ISO8601 dead_props map カスタムプロパティのマップ version number 楽観ロックのためにのバージョン番号 Key 1bdb5d9a-3581-49b0-a504-337b6f742aa7 d6c5e932-ef4f-4a05-a504-aae27bb5d62b ad06422b-64e3-444d-b06a-fc6ce2fce25a 43276bca-2f05-4650-ab23-16f1c18fd902 09524a50-ce18-42da-b7e9-c24ef97dba39 Copyright Nulab Inc. All Rights Reserved.
22. サーバーレスなアーキテクチャの考察 WebDAVのバックエンドを拡張する 課題： ・現行システムではApache HTTP Serverでファイルを読み書きして いる。 ・IOの先をS3とDynamoDBに変更する必要がある。 ・Apache HTTP Serverに独自のモジュールを作るのは避けたい。 アプローチ： ・Goのx/net/webdavパッケージを検討。 ・Goの準標準パッケージはWebDAVプロトコルをサポート。 ・ファイルのIOがFileSystem interfaceで抽象化されているので、 拡張しやすい。 ・さらに、webdav.Handlerがhttp.Handlerに準拠しているので、 標準のhttpパッケージでWebDAVサーバーを書ける。 ・S3とDynamoDBのAPIにはaws/aws-sdk-go-v2を使用する。 S3とDynamoDBをバック エンドにした独自の FileSystemを実装する http.Handlerのinterfaceになっ ているので、標準のhttpパッケ ージでサーバーを書ける ※ webdavパッケージのFileSystem interfaceとHandler Copyright Nulab Inc. All Rights Reserved.
23. サーバーレスなアーキテクチャの考察 そしてコンテナへ ・データをサーバレスなストレージに移行することで、アプリケーションは状態を持たなくなり、コンテナ化が容易に。 ・ストレージに関するコンピューターリソースのスケール、冗長性、メンテナンスはAWSにお任せ。 DynamoDB S3 ECS or EKS or Lamda ファイルのメタデータ ファイルの実態 mod dav mod perl x/net/webdav Copyright Nulab Inc. All Rights Reserved.
24. ケース毎の課題と解決策 Copyright Nulab Inc. All Rights Reserved.
25. ケース毎の課題と解決策 前提：ファイルの実態とメタデータの追加シーケンス WebDAVプロトコルは単一のファイルパスを指定してファイルの読み書きを行う 。（1リクエスト / 1リソース） ケース： /root/foo/apple.png を追加する。 ファイル追加のシーケンス： 1. アプリでファイルに付与するユニークなID（UUID等）を生成する。 2. 1.のIDをキーにして、ファイルの実態をS3に追加する。 3. 2.で失敗したらエラー終了。 4. 1.のIDをキーにして、ファイルのメタデータをDynamoDBに追加する。 5. 4.で失敗したらエラー終了。S3にファイルの実態は残るが、到達不能（どこか らも参照されない）ので影響なし。 id UUID2 parent_id UUID1 name foo type Directory id UUID3 parent_id UUID1 name bar type Directory id UUID4 parent_id UUID1 name README.md type File id UUID7 parent_id UUID3 name hoge type Directory id UUID5 parent_id UUID2 name baz type Directory id UUID6 parent_id UUID2 name apple.png type File id UUID1 parent_id name root type Directory ファイルのメタデータ ECS or EKS or Lamda ファイルの実態 IDを生成 Key UUID4 UUID6 メタデータの追加 実態の追加 Copyright Nulab Inc. All Rights Reserved.
26. ケース毎の課題と解決策 ファイルパスをもとに対象を効率的に特定する ケース： /root/foo/apple.png のStat（各種プロパティ）を取得する。 1. name=rootのアイテムを取得する。 2. patent_id=root.id のアイテム一覧を取得する。 3. 2.のアイテム一覧からfooを特定する。 4. patent_id=foo.id のアイテム一覧を取得する。 5. 4.のアイテム一覧からapple.pngを特定する。 6. apple.pngのStatを返却する。 課題： ファイルパスの階層が増えれば増えるほどクエリが増える。 各アイテムにファイルのフルパスを持たせる？ ・リネーム・削除の際に、関連する全アイテムのアトミックな更新が必要。 ・DynamoDBのトランザクションは100件まで... id UUID2 parent_id UUID1 name foo type Directory id UUID3 parent_id UUID1 name bar type Directory id UUID4 parent_id UUID1 name README.md type File id UUID7 parent_id UUID3 name hoge type Directory id UUID5 parent_id UUID2 name baz type Directory id UUID6 parent_id UUID2 name apple.png type File id UUID1 parent_id name root type Directory Copyright Nulab Inc. All Rights Reserved.
27. ケース毎の課題と解決策 ファイルパスをもとに対象を効率的に特定する 解決策： ファイルのフルパスをツリーでキャッシュする。 ・境界（プロジェクト）毎にファイルのフルパスをツリー構造. でメモする。 ・対象のパスを解決する際に、境界のツリーを取得する。 ・メモリ内でツリーをもとに対象（/root/foo/apple.png）のidを 解決する。 ツリーの保存先は？ ・DynamoDBの400kb制限があるのでS3に保存する。 ・さらに、ツリーのサイズに適切な閾値を設定して、 ツリーを更新するタイミングで分割・結合を繰り返す ことで肥大化を防ぐ。 root root UUID8.json UUID9.json Copyright Nulab Inc. All Rights Reserved.
28. ケース毎の課題と解決策 ファイル・ディレクトリの書き込み系の排他制御 ケース： ・ /root/foo/apple.pngを/root/foo/orange.pngにリネームする。 ・メタデータのプライマリキー（id）を指定してnameを更新する。 課題： ・DynamoDBの書き込み操作はデフォルトでは無条件。 ・なので、後勝ちで意図せず上書きしてしまう可能性がある。 ※ WebDAVプロトコルはロックをサポートしているが、ストレージレベ ルで制御したい 解決策： ・条件付き書き込みを利用して楽観ロックする。 ・更新対象のアイテムが取得時と同じ状態であることを条件とする。 ・version項目に現在のversionを指定する。 ・更新する際にアトミックにversionをインクリメントする。 ・条件を満たさず更新できなかった場合はエラーを返す。 Attributes Key Type Desctiption id PK string ユニークなID 例. UUID parent_id GSI string 親ディレクトリのID name string ファイル、ディレクトリ名 例. report.pdf type string ファイル、ディレクトリの種別 例. File or Directory size number ファイルサイズ 例. 512 modify string ファイルの更新日時 例. ISO8601 dead_props map カスタムプロパティのマップ version number 楽観ロックのためにのバージョン番号 $ aws dynamodb update-item \ --table-name YourDynamoDBTable \ --key '{ "id": {"S": "your-item-id"} }' \ --update-expression "SET #name = :new_name, version = version + :increment" \ --condition-expression "version = :current_version" \ --expression-attribute-names '{ "#name": "name" }' \ --expression-attribute-values '{ ":new_name": {"S": "new-name-value"}, ":current_version": {"N": "1"}, ":increment": {"N": "1"} }' \ --return-values "UPDATED_NEW" ※ AWS CLI を利用した例 Copyright Nulab Inc. All Rights Reserved.
29. ケース毎の課題と解決策 メタデータとツリーの整合性 ケース： ・ファイル・ディレクトリを追加・削除・リネームする。 ・階層構造が変わるため、メタデータの更新と同時にツリーも更新する必要がある。 課題： ・S3とDynamoDBの更新をアトミックに更新できない。（トランザクションが分離される） 解決策： ・ツリーの実態をS3で、ツリーの参照をDynamoDBで管理する。 ・書き込み時のフロー： 1. まずはユニークなID（UUIDなど）を生成する 2. 1.のIDで更新されたツリーの実態をS3に追加する。 3. 2.で失敗した場合はエラー終了。 4. メタデータとツリーの参照を、DynamoDBのトランザクションと条件付き書き込みで、アトミックに更新する。 5. 4.で失敗したらエラー終了。 ツリーの実態は残るが、どこからも参照されないので影響は無い。 DynamoDB S3 ECS or EKS or Lamda ファイルのメタデータ ファイルの実態 x/net/webdav ツリーの実態 ツリーの参照 Attributes Key Type Desctiption id PK string ユニークなID current_id string 最新版のツリーのID version number 楽観ロックのためにのバージョン番号 Copyright Nulab Inc. All Rights Reserved. ツリーの参照
30. ケース毎の課題と解決策 データのガベージコレクション（1） ケース： ・/root/barを削除する。 課題： ・ファイルやディレクトリを削除するたびに到達不能なデータが残る。 ・関連付いている子やS3の実態を再帰的に削除する？ ・DynamoDBのトランザクションは100件まで... 解決策： ・データのガベージコレクターを実装して定期的に実行する。 ・ガベージコレクターのフロー： 1. メタデータのparent_idをもとに親の存在チェックを行う。 2. 親が存在しなければ到達不能とみなして対象のメタデータを削除する （ルートは除外）。 3. 削除対象がファイルの場合、idを指定して対象のS3のオブジェクト（ ファイルの実態）も削除する。 id UUID3 parent_id UUID1 name bar type Directory id UUID4 parent_id UUID1 name README.md type File id UUID7 parent_id UUID3 name hoge type Directory id UUID5 parent_id UUID2 name baz type Directory id UUID6 parent_id UUID2 name apple.png type File id UUID1 parent_id name root type Directory 到達不能なので削除 S3の実態も削除 ファイルのメタデータ ファイルの実態 Key UUID1 UUID2 id UUID2 parent_id UUID1 name foo type Directory 削除 ガベージコレクター Lamda EventBridge Scheduler スケジューラー Copyright Nulab Inc. All Rights Reserved.
31. ケース毎の課題と解決策 データのガベージコレクション（2） ケース： ・ファイルの実態やツリーの実態をS3に追加成功したが、メタデータや ツリーの参照をDynamoDBに追加失敗した。 課題： ・エラーケースで発生した到達不能なオブジェクトがS3上に残る。 解決策： ・データのガベージコレクターを実装して定期的に実行する。 ・ガベージコレクターのフロー： 1. S3オブジェクトのリストを巡回する。 2. 作成日時がn日前 && オブジェクトのキーに紐付く メタデータ・ツリーの参照が存在しなければ、 対象のS3オブジェクトを削除する。 （作成日時をもとにメタデータを追加するタイミングを避ける） id UUID3 parent_id UUID1 name bar type Directory id UUID4 parent_id UUID1 name README.md type File id UUID7 parent_id UUID3 name hoge type Directory id UUID1 parent_id name root type Directory ファイルのメタデータ ファイルの実態 Key UUID4 ファイルのメタデータ の追加に失敗 ・メタデータが存在しない ・作成日時がn日前 Lamda EventBridge Scheduler ガベージコレクター スケジューラー Copyright Nulab Inc. All Rights Reserved.
32. まとめ Copyright Nulab Inc. All Rights Reserved.
33. まとめ DynamoDB S3 Users ECS or EKS or Lamda x/net/webdav ファイルのメタデータ ファイルの実態 ガベージコレクター Lamda EventBridge Scheduler スケジューラー サーバーレスなアーキテクチャのメリットの再確認 コスト効率： Amazon S3、DynamoDBを使用することでストレージコストを大幅に削減でき る。 スケーラビリティ： ステートレスな設計により、コンテナ化が容易になり、リソースのスケールア ウトが簡単になる。 運用負荷の軽減： AWSのフルマネージドサービスを利用することで、セキュリティアップデート やディスク拡張などの運用負荷を大幅に軽減できる。 ツリーの実態 ツリーの参照 Copyright Nulab Inc. All Rights Reserved.
34. まとめ レガシーなプロトコルを活かしつつ、新技術を導入する重要性 ・WebDAVプロトコルは古いプロトコルではあるが、実際にはまだ多くの利用者がいる。 ・ユーザーに価値を提供していることに変わりない。 ・レガシーなプロトコルでも、今の時代の進化した技術を適切に導入することで、システムの安定性と信頼性を維持しながら、 背後の技術的な改善を続けることは可能なはず。 Copyright Nulab Inc. All Rights Reserved.
35. まとめ 今後の展望 ・本セッションの内容はサーバーレスなストレージによるリアーキテクチャの考察に過ぎない。 ・まだまだ、不確実性も多く、これから実際にPoC（概念実証）を作成し、検証を進めていきたい。 ・将来的には、AWSの各種サービス効果的に組み合わせることで、 ・より効率的で高性能なファイル共有サービスを実現したい。 ・運用効率の向上とコスト削減を実現したい。 [余談] GoのwebdavパッケージやRFC 3744を読んで知識を補填していたら、 webdavパッケージの挙動でRFC3744準拠していない箇所を見つけたので、 ちょっとした修正を送ったらマージされた🍻 今後も機会があれば積極的に貢献して行きたい。 Copyright Nulab Inc. All Rights Reserved.
36. Copyright Nulab Inc. All Rights Reserved. ◤ 募集中のポジション◢ ・Backlogソフトウェアエンジニア ・SREエンジニア ・マーケティング課長 ・カスタマーサクセス など ＼ 採用ページに飛ぶよ／ We are Hiring!!