本投稿は TECOTEC Advent Calendar 2022 の22日目の記事です。
今日誕生日の人おめでとう。
證券フロンティア事業部 初老エンジニアの望月です。
はじめに
エンジニアのみなさん、上長から「サーバコストを削減して」の任務を拝命していますか？(大変ですね)
事業会社が利益を出すためにコストを下げる。下げたコストをサービス向上のための投資にまわし、更に売上を上げる。当然のことですね。
現在サーバコスト削減の道半ばではありますが、コスト削減のために意識してきたことを書いてみます。
この記事のターゲット
サーバ構成はザックリとクラウドとオンプレミスに分けることができます。
今回はクラウドのコストダウンについて記載していきますが、根本的な考え方に差はあまりありません。
この記事では私が使い慣れているAWSのサービス名称で記載させて頂きます。GCPやAzureでも同様のサービスが存在していると思います。
また、オンライン処理(Webサービス等)とバッチ処理ではコスト削減の手法が変わってきます。
比較的簡単なバッチ処理をターゲットとしてコスト削減について記載していきますが、オンライン処理でも根本の部分は共通であると思いますのでぜひ最後までご一読ください。
コストダウンの基本
クラウドのコストは基本的に従量課金制となっており、
「利用するサーバリソース(CPUやメモリの大きさ等) × 利用時間」
でおおよその金額が決定します。
フルマネージドサービスではアクセス回数でコストが計上されることも多いですが、結局のところ「アクセス回数 ≒ リソース消費量」なので近しいコストにいきつくと思います。
結論
先に結論を申し上げると、以下の2点を改善することでコスト削減に繋がります。
- 利用するサーバリソースを縮小する
- サーバの実行時間を短縮する
サーバリソースと利用時間でできた面積を小さくしていくイメージですね。
ただし、サーバリソースを無暗に削減することが悪手に繋がることもあります。
リソースを削減したことで実行時間が延長してしまった。
あるいは逆に、実行時間を短縮するためにリソースを増加したが返って面積が増えてしまった等です。
要はバランスを見極めることが肝となります。
バランスとは
クラウドは基本的にリソースと利用時間の掛け算でコストが発生するということは前述の通りです。
ここでのリソースとは占有するために確保したサイズのことであって、実際に利用しているリソース量とイコールになる訳ではありません。
サーバリソースを決定する際「実行される処理の量に対して、十分余裕があるリソースを確保する」というのが一般的な考え方かと思います。
この「余裕」の部分がコスト増の主原因となります。
積極的なコストを削減を目指すためには、確保したリソースに対して安全な範囲で「可能な限り」処理を詰め込んでいくことで、処理を短時間で実行させることになります。
利用するサーバリソースの削減
まずは基本となりますが過大に確保しているサーバリソースがあるか確認します。
サーバの負荷状況を確認しつつ、適正なサイズに変更します。
ここで「適正なサイズ」という第一関門が訪れます。
オンライン処理とバッチ処理
オンライン処理を実行しているのか、バッチ処理を実行しているのか、はたまた両方を実行しているのかで適正なサイズの概念が変わってきます。
これらの一番の違いは、処理に対する負荷予測精度の高さとなります。
一般的にオンライン処理はユーザの利用状況によって大きく負荷が変化するので、安定的に稼働させるためにはある程度の余裕が必要です。
このある程度を余裕を予測するのがエンジニアの腕の見せようとも言えるのですが、突発的な負荷は予測を越えることが度々あります。
コスト削減のためにサービスを停止させてしまったら本末転倒と言えます。
古い話題にはなりますが、バルス砲などが顕著な例でしょう。
昨日の「バルス」の記録がでました。ツイート数のピークは主人公が「バルス」と発したのとほぼ同じタイミングで日本時間の午後11時21分50秒、ツイート数は143,199TPSで、これまでの最高である今年の「あけおめ」の33,388TPSを大幅に上回っています。
— Twitter Japan (@TwitterJP) 2013年8月3日
バッチ処理の負荷に関しては殆どのケースでコントロールが可能であり、負荷を予測することが容易であると言えます。
突発的な負荷が発生しない状況を構築できれば、前述した「ある程度の余裕」を限りなく小さくすることが可能になります。
イメージとしてはCPUの平均負荷が30%台で安定していた場合、同一リソースで最大3倍の処理を実行できることになります。
アプリケーション以外のOSやミドルウエア等が動作しているのである程度の余裕は必要なのですが、ここから先は経験と勘と度胸と継続的な監視によって「ある程度の余裕」を削り取っていけば良いだけです。
利用時間の短縮
メジャーな手法としてはサーバレス化が挙げられます。 利用する時間だけサーバを起動することで、利用していない時間帯のサーバ費を削減することができます。
更に一歩踏み込むには、残念ながらアプリケーションの改修が必要になってきます。 ただし、無暗に処理を改善していくのは愚策です。
まずは、処理をある程度のパートに分けて、実行時間を把握する必要があります。 観察してみると面白いのですが、想像もしていなかった処理で時間がかかっていることが非常に多いです。
ここまできたら後は処理を改善させるだけです。
ですが、全方位作戦は愚策中の愚策ですので一旦停止してください。
実行時間が長い箇所、しかも実行回数も多い処理を特定して、そこから改善を始めていきましょう。
おそらく2,3箇所を改善しただけで、劇的に実行時間が削減されるハズです。
コストダウンへのショートカット
ここまでつらつらと書かせて頂きましたが、実際のところ最初に着手するべきなのは契約の見直しとなります。
コストは利用するサーバリソースと時間で決まると述べてきましたが、実際のところは料率を加えた3次元で請求額が決定します。
AWSの各割引契約はサーバ構成を変更せずに値下げを受けられる可能性があります。
ただし適用するための制限も多く、場合によっては契約に合わせたコード改修も必要になることもあります。
AWSの代表的な割引契約は以下のものが挙げられます。
リザーブドインスタンス(RI)
SavingPlans(SP)
SPOTインスタンス
非常にザックリと解説すると、リザーブドインスタンスとSavingPlansは先払い割引ですが、常時サーバを使い続けることが前提となっています。
SPOTインスタンスについては、空いているサーバを安く借り上げるイメージです。
空いていなければ使えませんし、オンデマンドで使うユーザが現れたら処理を中断してサーバを返却する必要もあります。
リザーブドインスタンスとSavingPlansはチバユキさんの記事(特に空振りの箇所)を読んで頂くとイメージしやすいと思います。
SPOTインスタンスについてはtonishyさんの記事で具体的に解説されています。
最後に
コストダウンのための大まかな手順を列記させて頂きます。 多少前後することもあるかと思いますが、案件の状況や構成によって調整をしてみてください。
1. 発生しているコストの明細を把握する
2. コストが大きい箇所から順に改善に着手する
3. 契約や設定だけコスト削減できる箇所を先に潰す
4. アプリケーション層の改修は最後にまわす
5. コストエクスプローラーのグラフが下がっていく様子を日々楽しむ
現在参画している案件では、サービス開始当初と比較して70％程度のサーバコスト削減を達成できました。
それでも道半ば、非機能要件であるコスト改善に終わりはありませんね。
