By
—

定額プロバイダ併用で転送量破産に備える

はじめに

今回は、転送量課金が定額制のプロバイダを利用してコスト削減に成功した事例を紹介します。この事例そのものは当社特有のケースになりますが、似たような考え方が適用できるケースは多いと思います。

当社はインフラをほぼ全面的にAWSに移行していますが、コストの内訳を見るとおよそ三分の一が転送量課金でこの割合が増える傾向にあります。また、月々の変動が激しいのも転送量課金です。

従って、コストを考える上で転送量課金の管理が重要になるのですが、これはなかなか難しい課題です。その理由は、AWSにおいては、転送量課金を削減するオプションがあまりないことです。これは、長くAWSを使っていると、多くのユーザが悩まされる問題ではないかと思います。

インスタンスの料金であれば、リザーブドインスタンスとかスポットインスタンスとか、いろいろなオプションがあって、手間をかけてコストを減らす手段がいろいろあります。また、トラフィックの問題でも、レイテンシーの改善については CloudFront があって、HTTP2対応を含めていろいろな構成が可能です。

しかし、転送量課金については、どのサービスを利用しても基本的に同じで、AWSを使用している限り変えようがありません。

現在問題になっているのは、試用版ファイルの配布という限定されたアプリケーションだけですが、今後、他のアプリケーションでも似たような問題が発生する可能性が高いと考えました。

そこで、サービス本体はAWSに置いたままで、限定的に Sakura Cloud を併用し、キャッシュサーバを配置することで、大幅なコスト削減に成功しました。

問題

この問題については、以前、AWS Lambda と NewRelic Insightsを使って S3の転送量を監視する という記事で取り上げています。

  • プロモーションとして試用版のアプリケーションを多数配信している
  • ファイルサイズが大きいものがあり、そのうちいくつかが多数ダウンロードされている
  • 転送量課金はダウンロード件数に比例するので、変動が大きい

という問題があって、S3のログを NewRelic Insights というサービスに転送して、ここでダッシュボードやアラートを設定して管理しているという話です。

この方法でしばらく調査を続けた所、トラフィックの変動には次の二点の要因があることがわかりました。

  1. セールやプロモーションなどによって、一時的に特定の商品に注目が集まる
  2. 特定ユーザが同じファイルを繰り返しダウンロードする

1.は、トラフィックに比例してその商品の売上も上がりますので、必要な販売コストと考えることができます。問題は2.です。

ダウンロードされるファイルは、有償で特定のユーザに一定期間だけ公開されるものと、試用版などで全ユーザに公開されるものがあります。この試用版のファイルを繰り返しダウンロードするユーザがいるのです。

同じファイルを何度もダウンロードしても意味がないので、これは意図的なものではなく、ダウンロードするソフトのバグの可能性が高いと思います。おそらく分割ダウンロードに伴う 206 Partial Content の処理に問題があるのだと推測していますが、UAなどでは、この問題を起こすアプリを特定できませんでした。

そこで、前の記事にも書いたアラートを改良したり、問題を発見した時に、すぐそのユーザだけをブロックするスクリプトを書いたりしたのですが、状況は改善されませんでした。

その理由としては、S3から直接ファイル配信していることによる下記のような制限のためでした。

  1. アクセスログの配信に平均一時間程度の遅れがあるので、アラートが1〜2時間遅れて発行される
  2. S3は、IPアドレス等によるアクセス制限の機能はあるが、トラフィック制限やコネクション回数に応じた細かい制限ができない

他プロバイダへの全面的移行は不可

これらの状況を考えて、最初は、他のプロバイダへの移行を検討しました。

単純な転送量の単価では、AWSより安いものがたくさんあります。また、配布用WebサーバとしてS3のようなマネージドサービスでなくNginxを使えば、もっと細かい制限が可能になります。

しかし、問題はファイルの管理です。問題の業務は、当社のeCommerceプラットフォームの商品管理の一部になっており、この機能を利用してファイルをアップロードして、配布用のURLを発行するようになっています。

このプラットフォーム全体を移行することは難しく、かと言って、試用版ファイル配布の機能だけを分離して移行したのでは、他の業務とのつながりがなくなり、使い勝手が大幅に低下してしまいます。

また、現在、当社の開発運用のワークフローや権限の管理は、AWSのIAMを中心に集約されており、他のプロバイダを併用することで、管理作業が複雑になることは避けなければなりません。

この状況は、AWSを使っているスタートアップでは、ほぼ必然的に起こるような気がします。

つまり、初期の段階で、シンプルなレンタルサーバとして使っているうちは移行は簡単なのですが、ある程度事業が軌道に乗ってくると、管理やパフォーマンスの問題から、AWS特有の機能を使う必要が出てきます。そして、目先の問題に対応しているうちに、いつのまにかAWSにロックインされていて、他社への移行が難しくなっていきます。

転送量課金の料金が問題になってくるのは、この段階からです。それだけのトラフィックがあるということは、事業が成功しているので、そのコストは致命的なものではないでしょう。でも、単純な従量課金で全くコントロールできないのでは、安心して手放しで放置することもできません。

定額制プロバイダ+キャッシュによる解決

そこで、ファイル配布は従来通りS3をベースとしたまま、フロントエンドにキャッシュ用の Proxy Server を設置することにしました。

このProxy Server に Disk Cache の機能をもたせることで、ファイルのアップロードや管理はS3(従来のアプリケーション)で行なったままで、大半のトラフィックをフロントエンドに移すことができます。

そして、そのフロントエンドは さくらのクラウド に置くことにしました。

さくらクラウドは、IaaS型のクラウドプロバイダで、利用方法や機能はAWSに似ていますが、原則定額料金になっているという特色があります。

回線料金も、回線速度を指定してルータ+スイッチのクラスを選ぶことにより、定額で利用することができます。

FAQによると、利用するルータ+スイッチの目安となる転送量を大幅に越えた時には、帯域制限が行なわれるとのことです。

もし、サービスの可用性を重視するのであれば、S3のように予定外のトラフィックがあった時も、全部要求通り転送してくれる方がいいでしょう(後で請求書を見て頭をかかえることになるとしても)

しかし、試用版ファイルの配布のようなコストパフォーマンスを重視する業務では、むしろ予定外の大量トラフィックは遮断してしまう代わりに料金が極端に増えない方が望ましいでしょう。

さくらクラウドでは、帯域制限をかける前には通知が来るとのことで、この時点で、ルータ+スイッチのクラスをアップグレードするという方法も選べます。もし超過トラフィックが短期間しか続かないことがわかっていれば、数時間から数日の間だけ、上のクラスのルータ+スイッチを使うということも可能です。

どちらの方法を取るといても、知らないうちに大量の予定外のダウンロードがあって、突然料金が高くなるということは避けられます。

Nginx の設定

今回の構成はこのようになります。

以下のNginxの設定ファイルのテンプレートの一部を示します。

http {
  ...
  proxy_cache_path /var/cache/nginx/proxy_cache levels=1:2 keys_zone=cache-space:64m max_size=10g inactive=120m;
  proxy_temp_path /var/cache/nginx/tmp;
  ...
}


limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
  ...
  limit_rate_after 1m;
  limit_rate <%= node['nginx']['limit_rate'] %>;
  limit_conn addr <%= node['nginx']['limit_conn'] %>;
  ...
  location /xxxxx/ {
    ...
    proxy_cache cache-space;
    proxy_cache_valid 200 302 <%= node['nginx']['proxy_cache_valid_200'] %>;
    proxy_cache_valid 404 1m;
    add_header X-Cache $upstream_cache_status;
    proxy_pass https://s3-ap-northeast-1.amazonaws.com/(bucket名)/ ;
  }

現在は、不正ユーザに対しての制限は基本的なものだけですが、今後、実際のトラフィックを見ながら、細かい制限を追加していく予定です。

削減コスト

ここ半年の間の関連するコストを以下に示します。

外的な要因での変動はありますが、およそ $1700 前後だったものが $750 程度になっています。だいたい半分にすることができました。

今後の予定

さくらクラウドには、ウェブアクセラレータのマネージドサービスもあります。

今後、ファイル配布だけでなく、一部のサイトのアセッツ配布をこれで行うことを検討しています。

ただし、当社は、海外からのユーザの多いサイトも運用しているので、レイテンシーの観点から一部の日本ユーザ主体のサイトに対して行なうことになると思います。

最終的には次のような形態で、従量課金のAWSと定額制のSakura Cloudを併用する形になるのではないかと思います。

  • ファイル配布
    • 今回と同じ S3 + Cache Proxy on Sakura Cloud
  • アセッツ配布
    • 海外ユーザ中心のサイト → CloudFront
    • 日本ユーザ中心のサイト
      • コストパフォーマンス重視のサイト → 自営Nginxによるキャッシュ運用
      • 品質(レスポンス)重視のサイト → さくらのウェブアクセラレータ

いずれにせよ、アプリケーションのコアの部分は当分の間AWSで運用すると思いますが、フロントエンドの配置については、いろいろ工夫して、コストパフォーマンスを追求していきたいと思っています。

一緒にユニークな決済サービスを作ってくれる Rails エンジニアを募集中です！
多国籍なメンバーと一緒に仕事をしてみませんか？詳細はこちらのリンクです:D
Degicaの採用情報