これは神社に関する一連の投稿の最初の部分です。 このシリーズの記事の目的は、既存のファイルダウンローダーに対するShrineの利点を示すことです。

---

私が神社の開発を始めてから1年以上が経ちました。 この間、Shrineは多くの興味深い機能を受け取り、エコシステムが大幅に成長し、十分な開発者が本番環境でShrineを使用し始めました。



利点の説明を掘り下げる前に、一歩戻って、主に神社の開発の動機として何が役立ったかを詳細に検討する必要があります。



特に、既存のブートローダーの制限についてお話したいと思います。 ニーズに最適な選択を行えるように、これらの制限を認識することが重要だと思います 。

必要条件

---

要件は次のとおりです。

1. Amazon S3上のファイルは直接ダウンロードする必要があります
2. ファイルはバックグラウンドで処理および削除する必要があります。
3. ダウンロード処理中に処理が実行される場合があります。
4. 続編の統合
5. Rails以外のフレームワークで使用する機能

私の意見では、最初の2つのポイントは非常に重要です。フォームを操作するときに最適なユーザーインターフェイスを実現できるからです。 ただし、最後の2点も注意せずに放置しないでください。



1. Amazon S3または類似物を使用して、ファイルのダウンロードプロセスを最適化できます。

これには確かにいくつかの利点があります。リソース消費の削減、ストレージカプセル化による水平スケーリング、Herokuなどのディスクベースのソリューションとの連携。 ディスク書き込み機能を提供せず、 クエリ実行に時間制限があります 。



2.バックグラウンドタスクでのファイルの処理と削除により、ローカルファイルシステムまたはAmazon S3などの外部ストレージにファイルを保存するかどうかに関係なく、ファイルを非同期で操作できます。これにより、ユーザーインターフェイスが大幅に改善されます。 バックグラウンドタスクを使用することも、アプリケーションの高帯域幅を維持するために必要です。これは、ワーカーが遅い要求に縛られないためです。



3.ダウンロードプロセス中の処理は、特にファイルのサイズが異なるなど、複数のファイルバージョンが作成される場合は特に、小さなファイルで正常に機能します。 一方、ダウンロード処理は、ビデオなどの大きなファイルにも必要です。 そのため、あらゆる種類のファイルを処理できるライブラリが必要です。



4. ActiveRecord以外のORMで使用することも非常に重要です。 すでに登場したように、より機能的で生産的なRubyのORM。



5.最後に、Railsにふさわしい代替物がRubyコミュニティに登場しました。 Webフレームワークと簡単に統合する機能が必要です。



次に、要件を考慮して、既存のライブラリを調べて、それらの主な欠点を検討します。

クリップ

---

ActiveRecordの簡単な添付ファイル管理

ActiveRecordに強く依存しているため、停滞-さようならPaperclipと言えます。 これはActiveRecordで使用される非常に一般的なライブラリなので、残りの要件を見ていきましょう。

直接ダウンロード

Paperclipには直接ダウンロード機能はありません。 aws-sdkを使用して、S3に直接読み込むためのリンクとパラメーターを生成し、Paperclipを介してファイルをダウンロードするときと同じ方法でモデル属性を編集できます。



ただし、Paperclipは1つのリポジトリでのみ機能します。 動作するには、すべてのダウンロードがメインのS3ストレージで直接行われる必要があります。 攻撃者は添付ファイルなしでファイルをアップロードでき、その結果、多くの孤立したファイルが作成される可能性があるため、これはセキュリティの問題につながります。 S3がこれをあなたのためにしたなら、それははるかに簡単でしょう。

バックグラウンドタスク

バックグラウンドタスクでは、 delayed_pa​​peclipが使用されます。 ただし、delayed_pa​​perclipは、ファイルが完全にダウンロードされた後にのみタスクを開始します。 つまり、S3への直接ダウンロードを望まない場合、またはできない場合、ユーザーはバックグラウンド処理を行う前にファイルを2回（最初にアプリケーション、次にストレージに）ダウンロードする必要があります。 そして、それは非常に遅いです。



また、delayed_pa​​perclipは、バックグラウンドでのファイルの削除をサポートしていません。 これは大きなマイナスです。ファイルの各バージョンに対してHTTPリクエストを実行する必要があるためです（S3に複数のバージョンのファイルが保存されている場合）。 Paperclipは、アンインストールする前に各バージョンの存在もチェックするため、この機能が追加されることを期待しないでください。 もちろん、ファイルの削除を無効にすることはできますが、そうすると孤立ファイルに問題が生じます。



最後に、 delayed_pa​​perclipはActiveJobにバインドされるようになりました。つまり、バックグラウンドタスクのライブラリで直接使用することはできなくなりました。

なりすまし攻撃のMIMEタイプの誤検出

Paperclipには、誰かがファイルのMIMEタイプを置き換えようとしているかどうかを検出する機能があります。 ただし、この機能はしばしば誤って機能し、ファイル拡張子がファイルの内容と一致しても、検証エラーが発生する可能性があります。 この場合、誤検知はユーザーにとって非常に迷惑なため、これは非常に決定的な要因です。



もちろん、この機能を無効にすることもできますが、これによりアプリケーションはファイルをダウンロードする際の攻撃に対して脆弱になります 。

搬送波

---

Rails、Sinatra、その他のWebフレームワーク向けの優れたファイルアップロードソリューション

CarrierWaveは、クラス内にカプセル化して、モデル内の構成を正しく維持したPaperclipへの答えです。



CarrierWaveはSequelと統合されています。



残念ながら、 carrierwave_backgrounderおよびcarrierwave_direct拡張機能の場合、ORM CarrierWave統合では十分ではありません。 動作させるには、ActiveRecord固有の追加コードがたくさん必要です。

直接ダウンロード

前述のように、CarrierWaveエコシステムにはS3- carrierwave_directに直接読み込みソリューションがあります。 これは、S3に直接アップロードするためのフォームを作成し、ダウンロードしたファイルのS3キーをブートローダーに割り当てることができるように機能します。

<!-- Form submits to "https://my-bucket.s3-eu-west-1.amazonaws.com" --> <%= direct_upload_form_for @photo.image do |f| %> <%= f.file_field :image %> <%= f.submit %> <% end %>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、S3に直接複数のダウンロードを行う必要がある場合はどうなりますか？ READMEは、carrierwave_directがシングルダウンロード専用であることを指摘しています。 JSON APIはどうですか？ これは通常の形式であり、S3にアップロードするためのURLとパラメーターを生成するだけなので、carrierwave_directがこの情報をJSON形式で取得しないのはなぜですか？



しかし、 fog-awsを使用してS3リクエスト生成ロジック全体を再実装する代わりに、単にaws-sdkに依存している場合はどうでしょうか？

 # aws-sdk bucket = s3.bucket("my-bucket") object = bucket.object(SecureRandom.hex) presign = object.presigned_post
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 <!-- HTML version --> <form action="<%= presign.url %>" method="post" enctype="multipart/form-data"> <input type="file" name="file"> <% presign.fields.each do |name, value| %> <input type="hidden" name="<%= name %>" value="<%= value %>"> <% end %> <input type="submit" value="Upload"> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # JSON version { "url": presign.url, "fields": presign.fields }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメソッドには次の利点があります：Railsに関連付けられておらず、JSON APIで動作し、複数のファイルのダウンロードをサポートします（クライアントは各ファイルに対してこのデータを使用して単純にリクエストを行うことができます）。 ）

バックグラウンドタスク

まず、carrierwave_directがバックグラウンド処理を設定するための指示を提供することに注意してください。 ただし、バックグラウンドタスクを正しく設定するのはかなり難しいタスクなので、これを行うライブラリに依存するのは理にかなっています。



これは、 carrierwave_backgrounderにつながります。 このライブラリはバックグラウンドタスク処理をサポートしていますが、私の経験では不安定でした（ 1および2 ）。 また、バックグラウンドでファイルを削除することもサポートしていません。これは、複数のファイルを削除する際の決定的な要因です。



これをすべて克服したとしても、carrierwave_backgrounderとcarrierwave_directを統合することはできません。 前述したように、ファイルをS3に直接アップロードし、バックグラウンドタスクでファイルを処理および削除したいと思います。 しかし、これらの2つのライブラリは相互に互換性がないようです。これは、私の場合、CarrierWaveで目的のパフォーマンスを達成できないことを意味します。

Githubで未解決の問題を閉じる

人気のあるオープンソースライブラリのメンテナーに感謝しない人もいることを理解しており、お互いをより柔らかく尊重する価値があります。 ただし 、 CarrierWave 開発者が 未解決の タスクを 閉じる 理由を 理解 できません 。



そのような閉じられたタスクの1つは、検証の前にCarrierWave処理を不必要に実行することです。 これは深刻なセキュリティホールです。ファイルサイズ/ MIME /測定値の検証は処理後にのみ実行されるため、攻撃者は任意のファイルを画像プロセッサに転送できるためです。 これにより、アプリケーションはImageTragick 、 画像爆弾、または大きな画像のダウンロードなどの攻撃に対して脆弱になります。

整頓

---

Rubyへのファイルのアップロード、試行3

Refileは、CarrierWaveの作者であるJonas Niklasによって、Rubyでのファイルアップロードを改善する3番目の試みとして作成されました。Dragonflyと同様に、Refileはオンザフライで処理できるように設計されました。 CarrierWaveの複雑さに悩まされた後、Refileのシンプルでモダンなデザインが本当に有望であることがわかったので、私はそれに貢献し始め、最終的に私はすぐに招待されました。

 Refile.attachment_url(@photo, :image, :fit, 400, 500) # resize to 400x500 #=> "/attachments/15058dc712/store/fit/400/500/ed3153b9cb"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Refileの新しいアイデアには、一次ストレージとしての一時的および永続的ストレージ、ストレージのクリーンな抽象化、IO抽象化、クリーンな内部デザイン（GODオブジェクトなし）、ボックスからの直接ダウンロードが含まれます。 きれいなRefileデザインのおかげで、Sequel統合の作成は非常に簡単でした。

直接ダウンロード

Refileは、ファイルをダウンロードする最初のライブラリです。直接ダウンロードのサポートが組み込まれているため、ユーザーが選択したときに添付ファイルを非同期でダウンロードできます。 ラック経由でファイルをアップロードするか、Refileを使用してS3に直接アップロードして、S3要求パラメーターを生成できます。 すべてを行うJavaScriptライブラリもあります。

 <%= form.attachment_field :image, presigned: true %>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、パフォーマンスが大幅に向上します。 ファイルをS3に直接アップロードする場合、「一時」としてマークされているバケットディレクトリにアップロードします。 次に、検証に合格し、レコードが保存されると、ダウンロードしたファイルは永続的なストレージに移動されます。 一時ストレージと永続ストレージがS3にある場合、Refileをリロードする代わりに、S3 COPY要求を発行します。



言葉ではなく、直接ダウンロードの要件を満たしました。

バックグラウンドタスク

Refileの制限の1つは、バックグラウンドジョブのサポートの欠如です。 Refileはブート時に処理を実行し、S3 COPYの最適化があるため、ここではバックグラウンドタスクは不要だと思われるかもしれません。



ただし、S3 COPY要求はHTTP要求のままであり、フォーム送信の期間に影響します。 さらに、S3 COPY要求の速度はファイルサイズに依存するため、ファイルが大きいほど、S3 COPY要求は遅くなります。



さらに、Amazon S3は多くのクラウドストレージサービスの1つにすぎません。ニーズに最適な別のサービスを使用できますが、そのような最適化はなく、直接ダウンロードもサポートしていません。

ロード中の処理

ロード処理中の処理は、ローカルに保存され、迅速に処理される画像に適していると思います。 ただし、オリジナルをS3に保存すると、Refileは最初にS3からオリジナルをロードする必要があるため、初期バージョンリクエストの処理がはるかに遅くなります。 この場合、すべてのバージョンを前処理するバックグラウンドタスクを追加することを検討する必要があります。



ビデオなどの大きなファイルをダウンロードする場合は、通常、ダウンロードプロセス中よりもダウンロード後に処理することをお勧めします。 ただし、Refileは現在これをサポートしていません。

トンボ

---

ロード中に処理するためのRuby gem-シナトラのRailsでのイメージのロードに適しています

Dragonflyは、読み込み中に処理するための別のソリューションであり、Refileよりもはるかに長いシーンにあり、私の意見では、読み込み中にはるかに高度で柔軟な処理機能を備えています。



DragonflyはSequelで動作しません。これは予想されることで、アダプターを作成する準備もできますが、モデルに関連付けられた一般的な動作 はActiveRecordモデルに固有の動作と混ざり合うようであるため、これを行う方法は明確ではありません。



バックグラウンドタスクや直接ダウンロードのサポートもありません。 後者は手動で行うことができますが、Paperclipと同じ欠点があります。



もう一つ重要な点があります。 イメージサーバー（ダウンロードプロセス中の処理用のDragonflyアプリケーション）を介したファイルの取得は、完全に別の責任です。 つまり、すべてのもの（直接ダウンロード、バックグラウンドタスク、さまざまなORMなど）に付属する別のファイルアップロードライブラリを使用して、ファイルをリポジトリにアップロードし、引き続きDragonflyを使用してこれらのファイルを提供できます。

 map "/attachments" do run Dragonfly.app # doesn't care how the files were uploaded end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

攻撃

---

ファイルをダウンロードする別のアプローチ

Attacheは、ブート中の処理をサポートする比較的新しいライブラリです。 DragonflyとRefileの違いは、Attacheが個別のサービスとして実行されるように設計されているため、Attaacheサーバーを介してファイルがダウンロードされ共有されることです。



Attacheには、ダウンロードしたファイルをデータベースレコードにリンクするためのActiveRecord統合があり、直接ダウンロードがサポートされています。 ただし、バックグラウンドタスクでファイルをバックアップおよび削除するには、まだ十分な機能がありません。 さらに、Attacheには十分な柔軟性がありません。



Dragonflyのように、Attacheをモデルに統合する必要はありません。これにはShrineを使用できます。 今年、シンガポールのRedDotRubyConfを訪れました。そこで、偶然Attacheの作者と会い、ファイルのダウンロードに関する問題について非常に興味深い議論をした後、添付ファイルのロジックにShrineを使用し、バックエンドとして。



このようにして、Attacheはファイルを配布すると同時に、Shrineへの添付ファイルを使用して作業を行うことができます。

結論として

直接ダウンロードのサポート、バックグラウンドでのファイルの管理、起動時の処理、および他のORMで使用できることは、ライブラリに本当に期待していることです。 ただし、これらの要件をすべてサポートする既存のライブラリはありません。



そのため、私は既存のライブラリの知識に基づいて新しいShrineライブラリを作成することにしました。



Shrineの目標は、ファイルを操作するときにさまざまなタスクを最適化する機能と柔軟性を提供するために、不器用になることではありません。



これは野心的な目標ですが、1年間の活発な開発と研究の後、私はこれを達成したと感じています。 少なくとも、他のRubyライブラリよりも多くの機能があります。 このシリーズの残りの部分では、Shrineで使用できるすべてのクールな機能を紹介しますので、ご期待ください！

---

オリジナル： Shrine：Motivationを使用したファイルのアップロードの改善

著者のブログシリーズの他の記事：

• Shrine：Uploaderを使用したファイルのアップロードの改善
• Shrineによるより良いファイルアップロード：添付ファイル
• Shrineによるファイルのアップロードの改善：処理
• Shrineを使用したファイルのアップロードの改善：メタデータ