2022年に入ったあたりから円安による物価高が、いろいろなところに影響していると思います。わかりやすいのはガソリン・軽油、灯油、電気代、ガス代、食品あたりでしょうか。そのほかにもいろいろな商品がいつの間にか値上げされていてびっくりしたり。
GCPの利用料金は、使用しているリージョンに関係なく、米ドルで計算されます。そのため円相場は運用費用に大きく影響します。LotteryServの価格を決めた2021年は1ドル=110円くらいでした。多少レートが変動してもすぐには価格に影響させなくていいように考えて価格を決めたつもりなのですが、とうとう145円を超えてしまいました。それどころか150円にも届きそうな勢いです。わずか1年ちょっとでこんなに変わるなんて。
LotteryServの応募ページのレスポンスを向上では、ランニングコストも下がったはずなので、それを反映させたいと思っています。特に応募数が多い場面で効果が大きいはずです。
しかし今の円安は、この効果を見事に打ち消してしまっています。そのため今は価格改定の時期を検討しています。
GCPの中でも BigQueryは特徴あって魅力的なサービスだと思いますが、実際に使ってみると「利用料金がいつの間にかとんでもない金額になっていた」ことで有名です。料金がかるのは、基本は以下の2つです。(実際にはストリーミングとかの別料金もありますが、あまり使われないはずなので割愛します)
価格は東京/大阪リージョン、$1=￥135換算です。
この章は私の主観や予想を含みます。
検索が速いのがBigQueryの最大の魅力と思いますが、実は裏では結構な大規模なインスタンスが動いているのではないかと思います。その根拠は「クエリジョブ」の以下の記載です。
オンデマンド料金では、プロジェクトで最大 2,000 個の同時実行スロットを設定できます。
ここで「スロット」が何なのか問題になりますが、「コミットメント」に以下の様に説明されています。
スロットは、BigQuery で使用される仮想 CPU を表しています。
つまりGCEのvCPUやGKEのノードと同等のもの? でしょうか。
GCEでvCPUを2000予約する費用を試算してみます。どのようなタイプのvCPUを選ぶかにもよりますが、n2-standard-80(vCPU=80、メモリ320GB、$4.9835/時間)だと、以下のとおり。
$4.9835*2000/80=$124.5875≒￥16,819/時間
ちょっと微妙だったような... GCEのvCPUと同じという予想はハズレかもしれません。
がっつりBigQueryを使いながらも検索の料金をそれなりに抑えられるかもしれない仕組みが用意されています。一覧にすると以下のとおり。ちょこっと使いたい方は蚊帳の外です。
| 名称 | 概要 | 料金 |
|---|---|---|
| 月定額契約 | 購入した瞬間から、30日間の定額料金です。 | $2,400=￥324,000/月/100スロット |
| 年定額契約 | 購入した瞬間から、1年間の定額料金です。 | $2,040=￥275,400/月/100スロット |
| Flex Slots | 指定した短期間だけ、秒単位で定額にします。 | $4.80=￥648/時間/100スロット |
| BI Engine | オンメモリ検索で高速化。 | $0.0499/GB/時間 |
文字どおりの定額料金です。最初の1か月または1年は、途中で止められないので注意が必要です。また上記の料金は100スロットであることにも注意が必要です。通常のオンデマンド検索は2000スロットなので、スロットが少ないと「契約してみたけど検索遅い」ということになりそうです。オンデマンドでは2000スロット以上を使用する手段が用意されていませんが、定額契約では2000スロットを超えて予約できるそうです。東京リージョンでは最大1000スロットまでしか予約できないようです。
年定額契約をある程度のスロット以上購入すると、おまけとして下記のBI Engineの容量もついてきます。年定額契約するなら、これも使わない手はないです。
瞬間だけ定額という、変則的な料金プランです。使用する都度開始/終了を指定するようなので、定期的に決まった検索を行うなどの用途に向いています。購入するスロット数が多すぎると、購入に失敗することがあります。購入に成功すると解除するまで、秒単位で使っていても使わなくても課金されます。
上手く使えば費用と速度の両面で効果があるはずです。他プランとの組み合わせも可能です。
料金体系というより機能なのですが、別の料金体系を持っています。
Business Intelligence(以下BIと略)ツールのデータソースとしてBigQueryのテーブルを使用する場合に、レスポンスの改善や利用料金の低減の目的で使用します。BIツールとBigQueryを接続すると、ちょっとBIツールを操作しただけで何度も検索が発生していて、いつも間にかとんでもない金額を使ってしまうという悲劇を防げます。なんかのBIツールと組み合わせなければならないわけではないので、常時使うことも可能です。
検索をオンメモリで行うので非常に速いそうです。その検索用のメモリの予約した容量に応じて料金が決まります。素のBigQueryよりいろいろと制限が厳しく、BI Engineで検索できない場合、通常のBigQueryで検索され、料金もそちらのものとなります。
GAEのスタンダード環境では、言語によってインスタンスの起動時間に差があるのは、Java8を含む第1世代VMを利用している人には、良く知られた事実です。既に起動しているインスタンスがあっても、リクエストが増えて新たにインスタンスが起動される場合にも、この起動時間がかかります。そのためインスタンス起動が遅いと、時々レスポンスが悪く感じることになります。
昨年公式に公開されたJava17がいつの間にかGAEでもプレビュー版として使えるようになっていましたので、バージョンアップで起動時間がどう変化したか確かめてみたくなりました。それにSpringの起動時間も気になります。で、言語とそのバージョン + Webフレームワークの違いで、実際のインスタンス起動時間を計ってみました。
最初に断っておきますが、私が使用する(可能性のある)組み合わせのみの測定です。
| フレームワーク | |||
|---|---|---|---|
| なし | あり | ||
| 言語 | Java8 | 2.063 | - |
| Java11 | 1.055 | 3.737 | |
| Java17 | 0.939 | 3.551 | |
| Go 1.16 | 0.176 | 0.205 | |
単位はms。
VMの起動が早いのでしょうか。フレームワークなしならVM起動してても、ほとんど待たされている感覚はありません。PHP/Pythonと同じくらいの起動時間だと思われます。
まだプレビュー版であることはご理解ください。しかしJava11より少し早くなっているのはいいですね。
JavaVMに1秒+Springに3秒弱という結果でした。ブラウザを触っていても「あれ、遅いかな」と感じたころに応答が描画される感じです。これだけで十分「使えない」と判断できます。
起動時間の4秒というのは、GAEのJavaというと8しかなかった時代に、起動が遅いといわれていた状況よりも悪くなっています。Springはサーバレスという考えのなかった時代の、「起動しておいて口開けて待っている」ことが前提の時代の産物だけに、時代遅れの遺物になってしまった感があります。
サーバレスでやりたいなら、潔くSpringは捨てましょう。
インタプリタもVMも存在しない、ネイティブ実行されるだけあって、爆速です。ブラウザを触っていても、インスタンス起動が起きていることを全く感じることがありません。
「フレームワークというよりライブラリ」と言われるだけあって、遅延は30ms程度と、ほとんど影響がありません。SpringBootと対照的な結果ですが、時代が違うのでサーバレスも考慮された結果なのかもしれません。
(2022/07/14追記)
現在、GAEのJava17はプレビューから一般提供に格上げされています。