俺の報告

RoomClipを運営するエンジニアの日報(多分)です。

AWSでコスト計算する時はData Transfer Out Byteが重要です - 日報 #118

お金の話です。
AWSの。

一般的なアプリのサービスの場合、
サーバサイドのメインコストは下記の3つです。

  • RDS固定費
  • EC2固定費
  • S3固定費
  • 転送料金

使っていれば大物コストになりうるのはRedshiftやDynamo、CloudSearchあたりだと思いますが、
まぁ一旦ここは置いておきましょう。
特にRoomClipのような画像中心のサイトの場合は、
転送料金がバケモノ化していくので要注意でございます。

よくAWSの料金体系は複雑と言われます。
確かにそうなのですが、
複雑化している最大の要因は転送料金にあるんじゃないでしょうか。
もっと突っ込んで言えば、「S3の転送量が把握できない」ということが大きいのではないでしょうか?
今日はその辺について、僕が荒く把握するときの計算方法を記載してみます。

転送料金以外について、まず整理してみます。
これは実はとてもシンプルで、
RDSもEC2も時間従量課金なので、かなりコントローラブルです。
コスト計算は「立ち上げ予定のインスタンスの時間単位あたりの金額」さえ把握していれば、
かなり簡単に計算できます。
S3の固定費というのはストレージコストなのですが、
これはRDSやらEC2やら他のコストと比べたら大した金額にはならないし、
ある日突然爆増するというようなものでもないので、
そんなに緻密な計算はいりません。
せいぜい月当たりのアップロードバイト数を適当に把握していればOKなわけです。
Billing Managementの月間請求CSVをDLして、 Product CodeまたはProduct Nameの項目が、
AmazonEC2、AmazonRDS、AmazonS3の3領域の請求ドル金額を把握していれば問題ありません。

で、
問題は転送料金です。
Billing Management のProduct Name で AWS Data Transfer と表示される領域が超問題なわけです。
APN1-DataTransfer-Out-Bytes とか言われる項目ですね。

まずこいつが何者なのかをある程度ざっくり把握します。
AWSにおけるデータのやりとりは、 内部のやりとりと、外部のやりとりにざっくり言うと分かれます。
で、あんまり特殊なことをしない限り、前者の内部のやりとりはあまりコストがかかりません。
アメリカリージョンから大量のファイルを東京リージョンに定期的に引っ張るとか、
あんまりやらないと思います。
なので、基本的には後者の、外部とのデータのやり取りにおいて、
転送料金がかかるというわけです。
で、さらに言うと、
外部とのデータのやりとりを行うAWSのメインサービスは、
(今回の場合)EC2とS3です。
Webアプリへのアクセスに対して、
htmlやEC2上のCSSファイルやJSファイル、画像ファイルなどをやりとりする、
または、S3上に置いてある画像ファイルにアクセスする、
この2択に絞ってよいと思います。

で、そうなると、
Webサイトまたはアプリからの、
サービスへのアクセスがあった際に、
一体どれだけの転送量があるのか?ということに答えをもっていなければなりません。

そして、これが極めて問題で、把握しづらい領域だと思っています。
理由は3つです。
1つ目は、S3の転送量が(僕の知りうる限り、一発では)正確に把握できないことです。
マネジメントコンソールを見ても、S3の転送量に関するグラフは見れません。
なので、後述するやり方で、何となくS3の転送にかかる料金を計算する必要があります。
2つ目は、1つ目の問題も絡む話ですが、 外部サイトでS3の画像ファイルなどに直リンクをされると、
PVとの関連性が失われて、転送量の見積もりがまったくつかなくなります。
そして最後3つ目。
Billing Management のCSVで出力される Data Transfer Out Byte の料金は、
「全ての外部とのやり取りにおける転送料金」であるっぽい、ということです。
つまり、Data Transfer Out Byte が$100だったとしても、
その内いくらがS3とのやりとりで、いくらがEC2のやりとりなのかが、
よく分からないということです。

まとめると、
転送料金のベースとなる転送量を予想するのは、
S3の転送量マネジメントがないこと、
外部からリンクをはられること、などの理由で把握することが困難です。
そして、AWS側から転送料金と提示された金額は、
どのサービスとのやり取りなのかが分からないので、転送料金から転送量を逆算することも困難。
ということで、
転送料金を転送量でもって予想、計算をすることは難しい、
という風に見えてしまうんじゃないでしょうか。
多分、少なくとも僕はそうでした。

ですが、
最近は Cost Explorer というイケてるシステムが出来たお陰で大分改善されました。
というのも、 Cost Explorer は問題の3つ目を地味に解決してくれているように見えるのです。
Cost Explorer でのS3とEC2の金額と、 Billing の CSVのS3、EC2の金額は異なっているのです。
CSV上のEC2の金額は転送量は含まれない金額です。
なぜならCSV上ではAWS Data TransferではなくAmazonEC2項目での計上になるからです。
つまり、CSV上でのEC2の金額とCost Explorerの金額の差分が、
EC2の転送料金となるわけなのです。
EC2の転送料金が分かればS3の転送料金も分ります。
これによってS3、EC2の転送料金が把握できるので、
1リクエストあたりのEC2の転送料金はきっちり把握できます。

さて、残った問題は、
外部からのS3直読み込みがどの程度の影響をあたえるのか、ということだけです。
これはもう工夫してリファラルで入ってくる量から回帰式などを作って予想していくしかありません。

長いよ!
ぶつ切りにします。
もう少し分かりやすくまとめて再掲しますが、
とりあえず今日はここまで。