Database JUNKY

MySQL,MariaDBを中心としたブログです

aws s3の利用料節約を考える:データ転送量を減らす!

f:id:hit10231023:20180911021856j:plain

awsにて、動画共有サイト、画像共有サイトでもそうだと思いますが、ec2インスタンスのコストよりかかるのが、ずばり!転送料です。一部のサービスでは、ec2のインスタンスコストよりデータ転送料金のほうがコストがかかっているという話をよく聞きます

たとえば利用料金。。

f:id:hit10231023:20180910203235j:plain

サービス事業から見ると、大した額ではないかもしれません、しかし、私から見れば、一日でお給料がすっ飛びそうなお値段だと思ってます。

これを、ここまで下げることができました!!

f:id:hit10231023:20180910203258j:plain

今回、どのように、awsの転送料金を下げたかについて説明していきたいと思います

S3の料金体系を学ぶ

個人的な主観ですが、s3の料金体型はほんとうにわかりずらいです。。 awsを利用するメリットは数多くありますが、一番恐れるのが、コストとして予測しずらい転送料の部分なんですよね。

qiita.com

を参考にさせていただきました。kawazさん曰く、

一番高いインターネットへのデータ送信だけ考えておけばよいと思います

まさしくこれです。データ送信のところをなんとかすれば、コストを下げれるのではないかと思いいろいろと試したことをメモします。

サービスのケース

ケースとして、そうですね。1ファイルのサイズが大きい、mp4などの動画ファイル提供するサービスだと仮定してみましょう

たとえばですが、10MBのファイルを10人の人が、クライアントからリクエストすれば、10MB X 10人で、100MBのネットワーク転送量になりますね。それが、100人だったら、1000人だったら、100000だったら?って考えれば、「あぁ、いろんな意味ですごいなS3」ってなるのが納得いただけるかと思います。

では、さっそく対応策について考えてみたいと思います

データ送信料を節約する!

現状、データ転送料を抑えるために、、で真っ先に切り捨てて考えなければいけないのは、awsそのものなんですね。awsには、cloudfrontなるCDNのサービスがあります。もちろん、高機能!かつ、魅力あるサービスです。ただし、on awsで使う上でこの転送料の呪縛からは絶対に逃げることはできません(笑)

CloudFrontでどれだけ速く、配信できたとしても、ネットワーク転送料は変わらないわけで。コスト削減にはなりません

CloudFrontは、もっと規模が大きくなってサービスの収益が見込めるときに使ったほうが良いでしょう

f:id:hit10231023:20180910203640j:plain

自作CDNを作ろう

そもそもCDNが何の略かもしれない私が考えてるわけなので、本来のCDNとは大幅にずれた話になりそうな気がしますので、色々な意味でこの話についてのつっこみは無しでお願いします。たぶん説明されても私には何のことがわからない人だと思いますので。

ネットワーク転送量で課金されないクラウドを選択

ネットワーク転送量がコストのネックになっている部分であれば、つまりは、ネットワーク転送量で課金されないところを選択すればいいんじゃないのか?つまり、VPSとかオンプレミス(データセンター)のaws外のサービスを活用するのは、どうだろう?といったところから考えてみます

VPS

以下どちらも、評判の良いVPS事業者です。

www.sakura.ad.jp

どちらも通信速度が安定しておりますし、サービスも良さそうです。 また、Conoha は萌えます。今回のCDN自作で、気にした部分は、

  • ネットワーク課金が従量制ではないこと
  • ディスクの容量がそこそこある

の2点です

自作CDN 構成

こうすれば、コストを抑えられるのでは的な考えで作ってみたのが以下の構成です。sakura internetで考えてみた例になります

f:id:hit10231023:20180910203722j:plain

要約すると

  • 初回アクセスは、自作CDNから取得しようと試みるも、キャッシュがないので、S3から持ってきたものを返す -> ここで、自作CDNにキャッシュされる
  • 2回目以降同様のファイルにアクセス要求がある場合は、キャッシュから取得する、つまり、S3へのアクセスはない

です。(ここまではイメージトレーニング)

この構成が、ばちっと決まれば、

10MB X 10人で、100MBのネットワーク転送量になりますね。それが、100人だったら、1000人だったら、100000だったら?って考えれば、いろいろ納得な感じで、「あぁ、いろんな意味ですごいなS3」ってなるのが納得いただけるかと思います

の話でたとえると、数値的な話だけしますと、S3のアクセスは10MBの初回だけで済むことになります。

結果のこの理論が、節約につながりました。

ミドルウェア選定

Nginx

やはり、Nginxでしょう!まず、現在で、nginx以外の選択肢はないと思っています。ただし、ここでは、Nginxが得意とする、Nginxキャッシュは使わないで構成しました。理由は、消えてもらってしまうと困るからです笑

次回、このあたりの設定を細かく説明していきたいと思います(次回はいつだ。。)

f:id:hit10231023:20180309123622p:plain