請求書の一位を計算で見つける
目標
転送料金が怖い理由は、金額ではなくどこから発生したのかが見えないことです。このラボでは、クラウドのアカウントなしで、アーキテクチャのトラフィック経路を表に展開し、その表を読む計算機と、急増検知器を手で作ります。
単価表(このラボの前提)
| 経路 | 単価 |
|---|---|
| インターネットのイングレス | GBあたり$0 |
| インターネットのエグレス | GBあたり$0.09 |
| 同じAZ内 | GBあたり$0 |
| AZ間 | 両側に$0.01ずつ、実質GBあたり$0.02 |
| リージョン間 | GBあたり$0.02 |
| NATゲートウェイ | 処理量GBあたり$0.045、常駐の時間あたり$0.045(月730時間) |
| CDNのエグレス | GBあたり$0.06 |
料金は、事業者やリージョンごとに違います。ここで身につけるのは値ではなく、桁をつかむ方法です。
トラフィック経路(月間の転送量)
| 経路 | 種類 | 月間の転送量 |
|---|---|---|
| インターネットからWeb層 | ingress |
3,000 GB |
| Web層からインターネット | egress |
26,000 GB |
| アプリ(AZ-a)とDB(AZ-b) | cross-az |
8,000 GB |
| アプリからオブジェクトストレージ(NAT経由) | nat |
5,000 GB |
| ログから別リージョンのコレクター | cross-region |
1,200 GB |
| Webとキャッシュ(同じAZ) | same-az |
20,000 GB |
エグレス26,000 GBのうち18,000 GBは、平均20KBのAPIレスポンスで、残りの8,000 GBは、すでに圧縮された画像と動画です。
作るもの
| ファイル | 内容 |
|---|---|
/root/transfer/paths.csv |
経路ごとの転送量と料金 |
/root/transfer/02-top3.md |
料金の上位3つと合計 |
/root/transfer/bill.py |
表を読む計算機 |
/root/transfer/04-gzip.md |
圧縮による削減額 |
/root/transfer/05-cdn.md |
CDNの比較と、損益分岐のヒット率 |
/root/transfer/daily.csv・spike.py |
転送量の急増検知 |
/root/transfer/07-notes.md |
整理 |
参考
ステップ3の計算機とステップ6の検知器は、採点ツールが隠しておいた表でテストします。 表を差し替えても正しく動いてはじめて、設計会議で使えます。
経路を表にする
案内に書かれた6つの経路を、/root/transfer/paths.csvに경로,종류,월GB,월요금の4列で書いてください(韓国語で、順に「経路」「種類」「月GB」「月料金」を意味する語です)。無料の経路も、料金を0と書きます。
종류の列には、ingress、egress、same-az、cross-az、cross-region、natの6種類が入り、1行ずつ出てきます(韓国語で「種類」を意味する列名です)。
料金は、単価表の値をそのまま掛ければ求まります。AZ間は、出る側と入る側の両側に課金されるので、実質GBあたり$0.02です。ここを半分しか数えないのが、最もよくある間違いです。
無料の経路を表から外さないでください。どこが無料かが見えないと、次のステップで何をどこへ移すかを決められません。
料金が大きい順に並べる
料金が大きい項目3つを/root/transfer/02-top3.mdに書き、それぞれ何を変えると減るのかを1行ずつ添えてください。最後の行には、NAT常駐料金(730時間×$0.045)まで加えた月の合計を書いてください。
順序は、ステップ1の表からそのまま出ます。3つの項目の桁が互いにどれだけ違うかを見てください。
減らす方法は、前の理論にすべて載っています。経路を変える、配置を変える、サイズを減らすの3つのうちのどれかです。
NATには、処理量の料金とは別に、起動しているだけで付く時間あたりの料金があります。これはトラフィックを減らしてもなくなりません。
表を差し替えても正しく動く計算機を作る
/root/transfer/bill.pyを作成してください。python3 /root/transfer/bill.py <경로CSV>で呼び出すと、行ごとに料金を出力し、最後の行に합계,<숫자>を出力する必要があります(プレースホルダーは、順に経路のCSVファイルと数値です。韓国語の語は「合計」を意味します)。常駐料金は転送量と無関係なので、数えません。
単価は、スクリプトの中に定数として置きます。案内の単価表をそのまま写してください。
종류の列が単価を決め、월GBを掛ければその行の料金です(韓国語で、順に「種類」「月GB」を意味する列名です)。4列目があっても無視してください。計算機が計算し直してこそ意味があります。
採点ツールは、隠しておいた表でも実行します。表を差し替えても正しく動いてはじめて、設計会議で使えます。
圧縮の価値を金額で書く
エグレス26,000 GBのうち18,000 GBがAPIレスポンスで、平均20KBです。gzipで平均5KBになると、転送量と削減額がいくらになるか、そして圧縮から除外すべきものは何かを、/root/transfer/04-gzip.mdに書いてください。
20KBが5KBになれば、転送量は4分の1になります。18,000 GBはいくらになり、いくら減りますか。
減ったGBにエグレス単価$0.09を掛ければ、月間の削減額です。
残りの8,000 GBは、すでに圧縮された画像と動画なので、gzipをかけても減らず、CPUを使うだけです。また、ストリーミングのレスポンスは圧縮しません。チャンクがバッファーにたまり、ストリーミングがストリーミングではなくなるからです。
CDNのほうが安くなる分岐点を求める
画像と動画の8,000 GBを、CDNの背後に置きます。ヒット率が90%のときの月額料金と削減額、そしてヒット率がいくら以上ならCDNのほうが安くなるかを、/root/transfer/05-cdn.mdに書いてください。
今は8,000 GBがオリジンから直接出ていきます。ヒット率が90%なら、オリジンからは10%しか出ず、ユーザーへはCDNが8,000 GBをすべて送り出します。
オリジンのエグレスは$0.09、CDNのエグレスは$0.06です。2つの金額を足したものが、CDNを置いたあとの料金です。
損益分岐点は、ヒット率をhとおいて、8000 × (1 - h) × 0.09 + 8000 × 0.06 = 720を解けば求まります。パーセントで書いてください。
請求書より先に気づく仕組みを作る
/root/transfer/spike.pyを作成してください。날짜,GB形式の表を読み込み、直前7日間の中央値の3倍以上の日を1行ずつ出力し、1つでもあれば終了コード1、なければ0で終了する必要があります(韓国語の列名は「日付」を意味します)。前の7日分がそろっていない日は飛ばします。テスト用のサンプルは、/root/transfer/daily.csvに自分で作成してください。
料金のアラートは、たいてい遅すぎます。月の予算の半分を超えたというアラートが届いたときには、すでに数日分が出ていったあとです。
転送量そのものを指標にして、普段の何倍になったら通知するほうが、ずっと早く気づけます。中央値を使う理由は、平均が急増した日そのものに引きずられるからです。
statistics.medianで十分です。基準を低くしすぎると通知が毎日届き、毎日届く通知は誰も見なくなります。採点ツールはその点も見ます。
3つのことを整理する
/root/transfer/07-notes.mdに3行以上書いてください。料金が発生する方向、マルチAZで構成したあとに料金が上がる理由、料金の代わりに何で管理するか、です。
本文に이그레스、AZ、전송량が含まれている必要があります(韓国語の2つの語は、順に「エグレス」「転送量」を意味します)。