2025年10月～クラウドストレージ開発：10月までの進捗完了済みの内容

ファイルのメタ情報DB選定：PostgreSQL
ファイルのメタ情報DB選定理由：　
カラムでファイルのメタ情報を保持しつつ、削除・送信済などのフラグ情報はRDB側で一元管理するため、商用ライセンス不要かつJSONBインデックスに対応しているPostgreSQLを採用しました。（今後拡張するかもしれないため考慮）MongoDBのようにドキュメント単位で全体更新が必要な構造的制約がなく、REST設計にも適していると考えています。

ログ情報DB選定：Redis(TTL) + list → PostgreSQL
ログ情報DB選定理由：
ログデータは高頻度で更新が発生するため、ディスク依存のMongoDBではなく、パフォーマンス重視でRedisを採用し、今後の分析などの拡張することを想定し、ログを上書きせずに保持する必要があるため、アクセス毎にlistに格納、セッションをTTLで保持し、一定数のログがlistにたまった段階で一括でPostgreSQLに登録する方針です。アクセス毎に登録した場合には、スキーマ制約がかかるため確実に保存される保証がないためです。

また、ファイルメタ情報管理とログ管理のスキーマは分けて運用する方針です。ファイルメタ情報とログを同一スキーマにした場合には、アクセスログだけで頻繁に書き込みが想定されるためスキーマ制約をうけパフォーマンスに問題が生じるためです。

CloudFormation or CDKの構成理由：
スケーラビリティも意識し、ユーザー登録時にCloudFormationで各種リソースを自動プロビジョニングする設計を構想中です。S3のオブジェクトにユーザ一のファイルを一元管理した場合には、ユーザーIDとファイルIDを組み合わせて取得しなければならないためRest APIが煩雑になることを避けるためです。

ファイルメタ情報DB設計（PostgreSQL）：
PostgreSQLの運用設計では、データ可視性の原因になるラップラウンド防止のためautoVacuumを常時バッチで監視を行い、必要に応じてVacuum Freezeを自動で実行させる方針です。

障害設計では、データの整合性の確認やWALからテーブルに書き込みを行っている場合にWALが破損した場合にはテーブルの復旧が困難になるので、WALのアーカイブはS3に保管予定です。
インデックス設計では、NULLはソートや比較ができないためNULL率が高い場合には、インデックスの恩恵が受けられないことを考慮した上でユースケースに合わせてwhere句で設計しています。
また、同一値が多いカラムにインデックスを貼った場合には、B-treeのバランスが崩れることにより断片化が起きてしまうことを避けるため、インデックスにはなるべくPKを含めた複合インデックスにしています。