円安に負けるな！最大年間3000万ダウンも！クラウドコストを1ヶ月でパフォーマンス改善しつつコストダウンさせた話

＃ クラウドのコストちゃんと見直してますか？
円安。それはシステム開発にも重くのしかかる問題。
最初から携わってる案件だと気をつけてるのですが、途中から入った案件などは
クラウドのコストの見直しが必要でも対応できてないケースが多くあります
案件によってはテコ入れを行い１ヶ月の対応で年間3000万という大きくコストダウンできたケースもあります。

みなさん関わってるサービスの性質や状況によっても変わり、人によっては当たり前すぎる話が多いのですが、コストダウンできたケースや気をつけていることを参考までにお伝えします。

コストダウン=パフォーマンス改善=ユーザーの満足度改善

コストダウンの話はかかるお金を減らしたいモチベーション以外に、大抵コストを下げれる余地が大きい場所はサービスの一番負荷、アクセスが大きい場所であることが多いです。
そういう箇所はユーザーが増加してシステム負荷があがりコストも比例して上がっている一方ですし、ユーザーからの不満も重要機能部分のパフォーマンスに直結していたりするので、問い合わせの増加など如実に現れてきます。
多くのケースがコストダウンはもちろんですがシステムの負荷が大きくサービスを安定させたい、パフォーマンスを上げたいという話から入って作業を行うことが多々あります。
そのためコストダウンを図った以後は大抵パフォーマンスが改善し、最終的にユーザー満足度も上がることになります。
日頃からコストダウンできないかについて考えるのは、良いサービスを提供できるかにつながるのです。

一番大事なこと。ちゃんとコストのモニタリング、パフォーマンスのモニタリングを日頃おこなっているか？

これが一番重要な点です。まずがどれくらいコストがかかってるか、負荷がどこにかかってるかは日頃見ておくのは当たり前と思う方もいらっしゃると思いますが、結構なケースでコストのモニタリング、パフォーマンスのモニタリングを行っていない場合があり、現状を把握してないと改善もできません。
前述の通りパフォーマンスにも直結する話であり、パフォーマンスの良い安定したサービスを提供しようと思うなら合わせて把握しておくことが重要です

また定期的に見ておくことは、新しい機能を出した後や構成を変更した後など何かしらの変更した後で設計ミスなどで大きくコストが無駄にかかってしまっていた。。ということがたくさんあります。
１例で言うと

• 無駄なバックアップを放置していて数百万無駄に飛んだ
• 設定を一つ入れ忘れた結果数十万単位のコストが毎月増えてたが気づかなかった。
  などなど、設計漏れ、オペレーションミスも当然起こり得るので、日頃の変化を常に見てないと漏れてしまっていることが多くあります。

そもそも受託開発などの場合、コストを払うのが開発サイドではなかったりするので、コストに対する感覚が薄いケースが多いように思えます。クライアント様のコストが下がることによりその分開発コストに回せたり、サービスを継続していくことができるため、我々開発側にも大きく関係することだと認識しておくことも重要です

一番改善の可能性が多いのはRDB

大抵のケースシステム上一番重要なデータを扱う部分で、成長に伴い負荷も高くなりやすく、コストの割合も大きいのがRDB周りになります。パフォーマンスにも直結する部分で、基本的には設計時から気をつけながら実装をしなければいけないところですが、多くのケースで時間が経てば経つほど負荷がたかまり、とりあえずRDBのインスタンスを上げて対応して凌いでるなどと言ったことも多いでしょう。

ただ大抵のケース調査を行えば改善点が大抵お決まりで、設計時にそもそも考慮しておきたいが後になって発覚するケースが大半です

indexを適切にはっておらず、重いクエリを放置している

こちらが一番多いケースです。最初から考慮してなくてindex貼ってなかったや、サービスが拡大していってクエリが劣化していたなど、さまざまな理由があります。
こちらもまずindexが足りてないクエリをスロークエリーログなどから把握、サービスで一番アクセスされるであろうものから粛々とindexを貼っていきましょう。サービスが大きくなりきるとindexを貼ること自体が難しいケースもあるので早めに対応ができるとよいです。
改善した上でデータをさらにキャッシュした方がいいなどの設計の話もありますが、まずはクエリの見直しをするといいでしょう。

データを増やしていく一方で利用しないデータもずっと残している

こちらも多くあるケースです。サービスのフロントからは一部のデータしかアクセスしないのにデータを溜めっぱなしで、負荷などが上がっていくケースです。indexやパーティションによる分割で対応できるにはできるのであればデータ自体をなるべく減らすことができるのであれば減らすことを検討しましょう。
定期的にデータを分析用に移してフロント側のデータ量は軽くしておくなどしておくと、サービスの運用上も対応がしやすいです。
またそもそもデータの保存先がRDBじゃない方がいいのにRDBにとりあえず突っ込んでおいたけど負荷もかかるし扱いもしづらく無駄に放置してた。。なども非常に多くあります。
サービスで財産であるデータをどう利用するかは一番重要な点であるので、データがどのように増えていって、どのように利用されるべきか？この点をどう設計するかは重要です

書き込みが多いサービスなのに効率のよい書き込みをやっていない

書き込みが多いサービスではいかに負荷を高めないように効率よく書き込みを行うかが重要です。
基本的な対応としては

• 書き込みが多い場合は非同期に書き込みを行う
• 書き込みを行うときは一個一個データを書き込むのではなく可能な限りバルクで書き込んでいく
  などが考えられます。
  年間3000万ダウンさせた話もこのケースに該当していますが、全体の設計に理解が薄いと逆に負荷を与える実装にしていたケースを紹介します。

RDSのインスタンスサイズをいきなり最大までにしなければいけない事態に

ある案件で今まで同じ処理をやっていたものを、新しくgo langで書き直したようだったのですが、リリースから負荷が一気に増大。問題は色々あったのですが改善していっても不安定な状態は続き負荷もRDSのインスタンスサイズをいきなり最大までにしなければいけない状態になりました。新システムと旧システムは共存してうごいており、同じような実装をしていたはずで、処理も少ないはずの新システムが大きく負荷を与えてました。リリース後に止めるわけもいかず、この状態を維持し数年RDSのインスタンスサイズ最大で動かさざるを得なくなったため、コストは数百万レベル毎月増えてしまっていました。

数年後さらにユーザーが増加していく一方で流石に改善しないともうこれ以上サイズも上げれない状況だったので私の方でテコ入れを行うことになりました。
結果、数週間ほどで、新機能リリース前と同じサイズまで落とすことができました。改善は上に書いた対応をやっただけなのですが、実装に大きく問題がある箇所がありました。

go langで実装時にせっかく非同期で効率よく書き込みすべきところをプログラム側で逆に負荷を与える実装をしてしまった

システムは前述の非同期で処理を行う設計になっており、ちゃんと実装すれば複数データを効率良い書き込みができる状態にはなっていました。

ところが実装者がgo langに変更した際に誤って複数まとめて書き込みするのではなくgo routineで並列で処理をするように書き換えてしまっていました。
プログラム上は早くなるように思ったからだと思うのですが、システム全体では書き込みが非効率に集中してしまうため、かえって負荷を増大させる原因になっていました。

設計への理解が薄いと、局所的に効率がいいと思ったものが逆の結果を招いてしまうケースです。
対応は旧システムも非同期にしてたものの書き込み最適化してなかったため、あわせて効率よく書き込みを行うのと新システムは並列処理から書き込み処理を抜き出し、効率化を図りました結果が以下です

改善以前

改善後

一気に書き込みをバラバラに行うため、書き込み待ちが多数発生し、AASが100を超えてたものを10あたりに抑えることができました。

結果
月間のコストダウン
12300ドル

現在のレートだと

12300ドル*157円 = 1,931,100円のコストダウンになりました。

ついこないだ前130円代だった気がしてたのですが、その時代なら

12300ドル*130円 = 1599000円

だったのに、円安がさらに進み、何もしてなくてもコストが爆増してることを考えると恐ろしい時代です。

開発上の無駄の廃止： ログの垂れ流し

これも案件によっては結構見受けられるのですが、デバッグのログを大量に流しているのを開発時ならともかく、本番でもそのままにしているケースがありました。
こちらはすぐに改善できるのに放置されており、デバッグログのせいで、エラーログなど肝心なものが見づらくなる、パフォーマンスも落ちる、お金も膨大にかかってしまう状態でした。
ログはアクセスが増えるに比例して増加するため、もしこのような状態にしている場合はすぐに見直すと良いでしょう。

通信量との戦い

これは粛々と対応するしかないのですが、メディアサービス、ライブ配信サービスは通信量に大きくコストがかかります。これはもう画像のフォーマットの見直し、CDNなどの活用、ライブ配信サービスはクラウドによって転送量コストや利用しているライブ配信機能ごとにコストが変わります。切り替えなど難しいものもありますが適宜検討してみるのも良いかと思います

運用ミスで起こるコスト増

こちらは書きましたが、起きることは人が行うことなので仕方ないので、起こしてしまった人が問題と考えるのではなく、やはりそう言ったことにすぐ気づけるようにしておきましょう思います。どのケースも被害が小さいうちに対処する方が対応がしやすいです。何か変更があった場合は数日変化を見ておく癖をつけておきましょう

終わりに

まだまだコスト削減のケースはたくさんありますが、代表的なケース、効果が大きかったケースを幾らかご紹介しました。
みなさまの状況によってコスト削減できるケースは色々変わると思いますが、多くのサービスに携わってきた弊社であれば対応可能なケースがまだまだ多くあると思います。

あなたのサービスのコストも削減できるかも？？相談は無料ですので気になった方は下記フォームからご連絡いただければ無料で診断を行います
https://forms.gle/EBkcnBFw7NAfedk47