Storageを技術検証して導入しないことにした理由みんなのウェディングのエンジニア合原です。弊社のスタンダードな画像アップロード方法として、導入できないか技術検証してみた話をします。下記の通り、Rails5.2より追加されたファイルアップロードを行うための機能です。これを使うと、投稿フォーム等で容易にファイルアップロードが実現できます。Recordオブジェクトに添付することを容易にします。開発およびテスト用のローカルディスクベースのサービスが付属しており、ファイルをバックアップおよび移行用の従属サービスにミラーリングすることができます。下図に示す通り、ポリモーフィック関連のテーブル設計を前提としています。blobsテーブルが画像のメタ情報やファイルパスなど、画像自体のデータを保持し、attachementsテーブルがblobsと該当モデルとの紐付けの役割を担います。Storageをご覧ください。イメージ図(S3へのアップロードを想定)※便宜上テーブルカラム等は簡略化しています。Storage標準の機能のみで問題はありません。弊社で取り扱う画像にはユーザーからの投稿画像があり、審査を行う必要があります。審査ステータスもテーブル管理する必要があります。Storageを利用することを前提に技術検証をしてみました。実際の利用を想定して新しいテーブル設計をしてみるS3へのアップロードを試してみるテーブル設計そこで下記のようなテーブル設計をしてみました。Storage標準のテーブル構成に関連する形で、画像自体の審査ステータスも管理できるデータモデリングをしてみました。Storageを利用できる状態を実現できました。Storageでは標準でymlを使って、S3のバケットをアップロード先として指定できます。"images"実はこの機能、バケット単位でしか指定ができません。(=オブジェクトキーの指定ができません。Storageを利用してアップロードされた、あらゆるファイルが一つのバケットに混在する状態となってしまいます。弊社の各種サービスでも利用することを想定した場合、この状態は受け入れられません。ネットワーク障害やアプリケーション側でのバグによりアップロードが正常に出来なかった場合、つまり、上述のテーブルと画像の実態ファイルとの同期が取れなくなった場合、画像の識別ができなくなってしまうことが想定されます。Storageの導入を見送ることとしました。こちらの記事も参考にしてみてください。弊社では上述の課題については、別のやり方で現在対応中です。折を見て、こちらで発信していきます!(2018年11月01日)twitterfacebookhatenabookmark最新の記事みんなのウェディングはEKSで動いていますタイポグラフィとCSSのスタイル宣言2019年新卒エンジニア研修もそろそろ終盤です。