0
0
テーマ、知りたいこと
・一度しか参照されることのないファイルをS3に置いてしまう開発は妥当なのか？
背景、状況
マイクロサービスのシステムに関わっています。
API側でファイルを作成しS3にファイルを置き、そのパスをインターフェイス側に返しています。
過去作成したファイルを参照するようなログ機能はなく、都度作成を行い一度DLしたファイルは以降画面から参照されることはありません。
私の個人意見としては、
-
肯定
- DBのデータをファイルに書き出しているので、API側からはファイルに出力する内容だけ返して、インターフェイス側で全てファイル書き込みを行えばいらないファイルをS3に置く必要もないじゃないか（整理整頓）
- 画面に出てる内容を出力するなら、ファイル書き出しの為にもう一回同じ内容でAPIに問い合わせる必要なくなるな（一石二鳥）
-
否定
- データ量が多い場合は、インターフェイス側に負荷がかからないようにAPI側でファイル作成をした方が良い（負荷分散）
- そもそも同じ機能なのに一箇所だけ違う実装は自己満足（保守性）
- DBのデータを出しているとはいえ、一応出力時点でのデータは取っておいた方がいいだろう（保全性）
- アップロードとダウンロード2回分で置いておく分にはタダだろう（コスト）
それなりに長いシステムで基本的にこれまでと似たような機能は似たような実装をという方針が、脳死している気がしたので多方面からもご意見を伺いたいと思いました。
回答2件
#1
総合スコア146054
投稿2024/01/01 23:16
まず気になったことは、「同程度以下のコストで実装・運用できる代替手段があるか」です。
極論、「他に手段がない」あるいは「他には手間で迂遠な手段しかない」となった場合には、一見非合理に思えても選択するしかない場合もありえます。
あと、もとの質問の「肯定」と「否定」がごっちゃになっていませんか？
#2
総合スコア4443
投稿2024/01/02 10:22
思いついたものを追加。
Pros
-
インターフェイス側の負担が減る。
現状ではAPIの動作は、「必要なデータがS3上に準備できてからおもむろにパスを含む成功レスポンスを返す」か「データの取得・保存の過程で何らかの障害が発生した場合は失敗レスポンスを返す」かのいずれかになります。
一方、S3上に一時ファイルを用意せずにデータをレスポンスに乗せて送信すると、障害が起きたときにAPIの障害かそれ以外の障害かの切り分けまでインターフェイス側の負担になるかもしれません。
Cons
-
送信ずみのデータへの対処で負担が増える。
本来はデータへのアクセスを認められていない第三者がS3上のパスを知り得た場合に、データを窃取される懸念があります。
これに対しては、(例として) インターフェイス側で適切な設計をして権限外アクセスを防ぐ、S3上のデータを一定期間後に削除するジョブを走らせる、などといった対処が必要になり、設計や運用の負担が増えます。
どちらでもない
-
動いてるならええやん。
どういういきさつがあってこうなっているのか私は知りません。が、今までそれで動いていてなにも問題が起きてなかったのなら触らないでおきたいです。変えるとなると設計から変更になるし、変えたことでなにか予想外の副作用が発生することがないとは言い切れないですからね。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。