Digitalocean ブロックストレージ 対 Amazon S3

Discourseプラグインのインストール中にコンテナを再構築する際、コマンドラインでディスク容量に関する警告を受けました。DigitalOceanのドロップレットから古いLinuxバージョンを削除するためのコマンドを実行しましたが、それでもSSD容量の50%以上を消費しています。

Discourseサイトの規模が大きくなるにつれ、ストレージソリューションを検討し始めました。現在は月額5ドルのDigitalOceanドロップレットを利用しており、DigitalOceanのブロックストレージとAmazon S3について調べています。Discourseの設定にS3の設定が組み込まれているのを見ると、S3の方がセットアップが簡単なのではないかと推測しています。

皆さんは自社のウェブサイトでどのようなストレージを利用していますか?読み込み速度の面でS3とDigitalOceanブロックストレージ、どちらが優れていますか?また、どちらがコスト面で有利でしょうか?S3の無料枠を使えば、DigitalOceanのブロックストレージよりも安く済むのではないかと思うのですがどうでしょうか?画像とバックアップの両方を保存していますか?それとも、DigitalOceanやAmazon以外の別のオプションをお勧めしますか?

「いいね!」 2

こんにちは、

S3 互換のストレージソリューションを提供しているプロバイダーは多数あります。いずれを利用しても構いません。私もいくつか利用しましたが、Digital Ocean Spaces が非常に優秀だとお勧めできます。

すでに Digital Ocean でホスティングを行っている場合は、高速かつ信頼性が高い Spaces を利用することをお勧めします。

ただし、CDN に関する懸念点もあるため、サードパーティ製の CDN を検討する必要があるかもしれません。

詳細については、以下のトピックをご覧ください:

「いいね!」 1

S3 は明らかにより成熟し、よりテストされたソリューションですが、価格の観点からは DO のオファリングがコミュニティにとって理にかなっているかもしれません。

どちらを選んでも、バケットの前に CDN を配置する必要がありますので、これを忘れないでください。

「いいね!」 3

Cloudflare の無料ティアは、バケットの前面で CDN として機能しますか?私はすでにドメイン設定で無料の DDoS 保護のために Cloudflare を利用しています。

DigitalOcean は、Spaces サービスが他の有名なプロバイダーよりも安いと宣伝していることに気づきました。これは確かにプラスです。

DigitalOcean Spaces に付属する CDN は Discourse と正しく連携しないため、リストにある他のプロバイダーのいずれかを選択しようと考えています。そうすれば、DigitalOcean Spaces と別途 CDN サービスの両方に料金を支払う必要がなくなります。

これはここに投稿します。なぜなら、Configure an S3 compatible object storage provider for uploads は1ヶ月後にすべての返信が削除されるように設定されているためです。

DO CDNの実装においてcontent-encodingが欠落しているのは確かに残念ですが、これは app.yml 内で すべての S3パラメータを設定した場合にのみ発生します。それらのパラメータをWeb管理コンソール経由のサイト設定で設定する場合、DOはS3アップロードのみをCDN経由で提供し、サイトアセットはソースから提供されます。

これは意図的な設計のようです。なぜなら、app.yml で設定された DISCOURSE_S3_CDN_URL 環境変数はアセットのCDN設定も上書きしてしまう一方、サイト設定のみで宣言された場合はそうならないからです。

これは少し一貫性がありませんが、サイトが破損することなくDO CDNをS3アップロードのみに使用することを可能にします。

これには2つの方法があります。

  • すべての S3設定をサイト設定のみに宣言する
rails c
SiteSetting.s3_upload_bucket="<bucket_name>/<uploads_folder>"
SiteSetting.s3_backup_bucket="<bucket_name>/<backups_folder>"
SiteSetting.enable_s3_uploads=true
SiteSetting.s3_access_key_id="<key>"
SiteSetting.s3_secret_access_key="<secret_key>"
SiteSetting.s3_endpoint="https://<sfo2>.digitaloceanspaces.com"
SiteSetting.s3_cdn_url="https://<bucket_name>.<sfo2>.cdn.digitaloceanspaces.com/<uploads_folder>"
SiteSetting.backup_location="s3"
  • app.yml 内で DISCOURSE_S3_CDN_URL を除くすべてのS3設定をシャドウし、DO CDNを SiteSetting.s3_cdn_url で宣言する
  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: <sfo2>
  DISCOURSE_S3_ENDPOINT: https://<sfo2>.digitaloceanspaces.com
  DISCOURSE_S3_ACCESS_KEY_ID: <key>
  DISCOURSE_S3_SECRET_ACCESS_KEY: <secret_key>
#  DISCOURSE_S3_CDN_URL: https://<bucket_name>.<sfo2>.cdn.digitaloceanspaces.com/<uploads_folder>
  DISCOURSE_S3_BUCKET: <bucket_name>/<uploads_folder>
  DISCOURSE_S3_BACKUP_BUCKET: <bucket_name>/<backup_folder>
  DISCOURSE_BACKUP_LOCATION: s3
rails c
SiteSetting.s3_cdn_url="https://<bucket_name>.<sfo2>.cdn.digitaloceanspaces.com/<uploads_folder>"

@falco もしこれに同意されるなら、元のウィキトピックを更新します。

「いいね!」 1

それは良いアイデアだとは思いません。

  1. 他のプロバイダー(AWS でさえ)はすべて CDN を必要としています。DO が壊れた無料の CDN を提供していることは単なる不具合であり、無視して標準的なオブジェクトストレージサービスとして扱うことができます。

  2. yml で S3 CDN URL を設定することと、サイト設定で設定することによって異なる動作が生じるという実装の詳細を推奨するのは、いつでも修正可能であるため、望ましいことではないと思います。

私はテストしていませんが、KeyCDN、Cloudfront、StackPath などの実際の CDN サービスでは動作することをお約束します。

「いいね!」 2