AWSが教えてくれないコスト削減の小話いろいろ

米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。

最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。



削減余地はある

昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。

ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。

そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツモで月額数百～数千ドルくらい削減できたりするものです。

それ以外だと全体を通した契約部分的なところで、中長期的なボリュームディスカウントのような割引契約とか、ReservedInstance／SavingsPlans のような割引形態を上手く適用するためにリソース構成の整理整頓を含めて適切な金額を見積もるなど。

やればやっただけ数字には出るから嫌いではないんですけど、なかなか思うように進まないなぁと思うところがあったり、コーディング機会が減って頭がパァになるなぁと感じたり、したことで頭がパァになって雑談休憩している所です。


世の中は（多分）無駄だらけ

自分が元から関与しているところ、全く関与していないところ全部ひっくるめて、特に古い所ほどやれることはまだまだあると実感しているので、世の中にはもっと大量の余剰リソースがあるんだろうなぁと思った次第。


ここのブログも含め、コスト削減に関するアウトプットもそこそこあるし、ついこの前のイベントも盛況だったみたいじゃないですか。


その辺を見てると世間のエンジニアはちゃんと取り組んでいるんだなぁと思うかもしれませんが、自分の適当見解だと、そういう人材が面倒を見て最適化されているアカウントなんて極少数で、９割以上のアカウントは垂れ流しスペシャルかましてると思うんですよ。

なぜなら、最初から最適化された設計は難しいし、途中で変化していく事情に追随した最適化も難しいし、エンジニアとか関係なく世の中の何割かの人間は整理整頓お掃除の類が苦手であるからです。

とはいえリソース量が大きなところほど組織も大きくてしっかりやってると思うので、費用的な割合だと違うかもですが、小さめの規模になるほど杜撰になりがちなので、結構な数のアカウントでお宝が発掘できるだろうなぁという妄想 Tweet でした。


取り組む時のお気持ち

片っ端から存在するアカウントの状況を見ていくと、そう珍しくもなく『何やこの残骸は！』なリソースに出会うことがあります。

そういう時は『なっちょらん！ムキーッ！』って気持ちも多少は湧いてくるわけですが、そこをグッと抑えて『お宝発見！コスト削減王に！おれはなるっ！！』って勢いで突き進むとよいでしょう。

お宝を発見したということは、その取り扱いをどうするかを、担当者を探して確認と判断をする必要があり、やり取りする時に負の気持ちを出しちゃうと進行に支障をきたすので、あくまでも『旦那、良いモノ見つけたんですよ、対応したらこれくらいお安くなるザンス！（そろばんパチリ）』くらいの皆が幸せになりそうな感じがオススメなのです。


コスト削減の価値と技術力

SRE的な立ち位置から、直接自分が管理しているわけではないリソース群に対して、無駄を判断して対処内容を決めて、自分で処理するなり担当者にお願いするなりしていくわけです。

無駄にも色々あって、完全なゴミから、少し手間のかかるお宝まであって、その対処内容の多くはローリスクでローリターン以上を見込んでいくものばかりです。月額0.5万円を削るにしても、もし1.0万円の人的コストで対処できるなら、2ヶ月でペイできるので、明確な事情がない限りはやらない理由はありません。

もう少し金額や手間が大きな案件でも、そのほとんどは半年１年以上で見れば人的コストを確実に上回る削減案となるので、基本的にはやらない理由はないくらいの価値であると考えてよいです。注意したいのは、人やチームによって人的コストの部分や、進行速度が結構変わるというところです。

コスト削減に必要な『技術力』には、穏便な対話・適切な判断・早い対処をしようとする意志、があると考えます。これが強いと、少しの対話で具体的な対処内容を決定し、あとはスケジュールはもろもろの事情でこうしましょう、と素早く進行します。

しかし、これが弱かったり何かしらの障壁や文化の違いがあると、驚くほど進まなかったりするので、そういう根本的な部分の改善から企むのか、手取り足取り進行してコスト削減だけでも完結させるのか、といった異なるアプローチを考えたりと、それもまた『技術力』と踏まえて穏便かつ迅速にコスト削減王を目指すのであります。


ありがちな細かいコスト削減

ここからは、AWSコスト削減とリソース管理 | 外道父の匠 でまとめるような内容ではなかった細かい話をしていきます。

もしかしたらかき集めて年額で数百ドル数千ドルくらいかもしれませんが、難しい内容でもないので、コスパを考えるとチリツモが結構な価値になるかもしれません。

圧倒的 ElasticIP の未割り当て

おそらく唯一、誰にも確認せず即決で削除してしまってよいものがこちら、未割り当ての ElasticIP です。

VPC IP Address Manager (IPAM) の Public IP insights でもガッツリ表示されますが、偶然一時的に外したものを除けば、その未割り当て EIP をそのまま再利用する必然性はまずありません。

長く使わなかったけど再度割り当てたいリソースが出てきたなら、大人しく新規 EIP を作成して割り当て、DNS の A レコード値を書き換えてくればいいだけです。その程度を嫌って確保しようとするヤツがいたら『テメーの技術力は ElasticIP 月額500円より軽い…ッ!!』 と申してあげましょう。

小銭集めと侮るな EBS gp3 化

これは前も触れましたが、あまり細かく練られたわけではない環境の多くは EBS が gp2 で使われています。OS だけの 8GB や 10GB なら、まぁ目をつぶってもいいですが、拡張した容量となると話は変わってきます。

こちらを参考にしつつ、ほぼほぼ gp3 に変更をポチるだけで、高性能化＋20％OFF になる最高峰のチリツモ案件となります。

もし 1TB でも積もれば -$24/月 で、それだけで年額4万円なので、勉強会のピザ代くらい余裕で賄えるんだぞわかってんのか！皆でピザ代かき集めて学びに繋げるんだよぉ！

無惨なバックアップの残骸

環境の移行、新機能のテスト、定期バックアップと間引き割合、あたりを起因として RDS スナップショットや S3 バックアップデータ などがこんもり眠っていたりします。

容量が大きめだと数世代分や数年分が積もっただけで、ぼちぼちな費用になったりしますが、RDS や S3 のサービス毎の全体費用としてみると割合的に気付きづらいことがあります。

CostExplorer で【使用タイプ】でグループ化して詳細を確認したり、S3 は難しいですがディレクトリ毎にチェックするスクリプトを書いたりして、ひたすら眠り続ける用無しの残骸を発掘できれば、あとの処理は削除するだけなのでチャリンチャリンです。

棒立ちの未使用 ALB

確定で使われていない判断をするには、バックエンドのターゲットが Healthy で１つ以上存在するかをチェックしていきます。名前が開発用とかで本当にそれが必要かまでを確認するのは、また別の手間なので最初はそこまでやりません。

ただたまーに、ゼロなんだけど一時的な確認用をデプロイした時にだけターゲットに出現するような使い方もしていたりするので、削除前に確認は必要です。

とはいえ、開発ならば可能な限り ACM ゾーンを統一して１ALB に統合してしまうのがベストなので、もし開発用途で複数あるなら証明書のゾーンをチェックしつつ整理整頓のコミュニケーションをゴリゴリ進めるのがグッドです。

あとは開発用途のは AZ の数を 3 ではなく 2 にして（1 にはできない）PublicIP 課金を軽減するとか、機会があればセコくチマチマと回収していくのです。

不信感の塊 停止済み EC2

またその EC2 を使う時が？ おそらく!!!　多分!!!　本当!!? ふざけるなッ ふざけんなよ!!!　どうかしてんじゃないのか!!?　こんな……　こんな１年以上も EC2 を停止済みのままにしている奴の言うこと　信じるのか!!? 信じられるわけないだろ!!!

……という気持ちになることもありますが、停止しても EBS の課金は継続していることをゴンさんは知っています。gp2 なら 100GB で $12/月 なんです。ステータスの最終変更日時は記録されていますので、それを根拠にゴリゴリお掃除していきます。

扱う本人の心構えとしては、せめて１ヶ月経過で要不要を判断して削除するなり、最低でも安価なスナップショットを採ってインスタンスを削除するなり、放置・ダメ・絶対。

二重の極みな安全ライン

安定なインフラ整備の条件として、例えば CPU使用率の実質的な利用上限を 50% なり 60% に決めたとしましょう。これは守っていれば、トラフィックが急増しても 2.0倍、1.6倍 になってもギリ大丈夫という意味を持ちます。もちろん、事前に判明している急増時間はスケジューリングで別途対応する形です。

負荷対策やコスト削減で増減する際に、その基準をベースとして変更後のリソース量を試算するわけですが、それに対してより増やしておきたい、もう少し減らすのを抑えたい、というお気持ちがどこからともなく発生することがあります。これは正確にシステムを理解していない人間が絡む場合には、より安心安全を求める心理が働くので、避けて通れない異物だったりしますが、実質的に安全基準が二重に引かれることになります。

その心情を汲み過ぎると、最適なコストとは言えなくなりますし、無視しすぎると想定外の状況でのみそれ見たことか、と非難されかねません。基本的には基準に従う試算にすべきですが、リスクを取りすぎる必要もない場合、間をとって調整をこまめにして徐々に最適化状態に向かう、というのが大人なエンジニアリングなのです。

こういうのはクラウド環境の弊害ではありますが恩恵でもあるので、増やす時はガバっと増やして安全を確保して落ち着いたら早めに減らす、減らす時は怖いなら徐々にでいいから必ず最適に向かうこと、を守ればそこまでコストに悪影響が出るものでもありません。あまり基準に確執し過ぎず、かといって感情に寄りすぎず、柔軟な中でもルールに従うってのが肝要なのかなと思います。

寄せて空間を削り取れ Autoscaling

ということで、スポット事情等コミコミで安全条件を 50% と定めたなら、実際の使用状況を 50% に近づけるほど、許容範囲のリスクで最もコスパを良く運用できていることになります。

トラフィックの波が緩やかなサービスならそれが簡単なのですが、激しいとスケジュールによる強制調整を組み込むため、なかなか 24時間 50% 前後に寄せるというのは難しい話だったりします。

なのでトラフィックが高まるところで無理をするというよりは、日中の平和な時間帯や深夜といった落ち着く箇所の締め付けを厳しめにすると、急増リスクを低く搾り取りやすいのでオススメです。

CPU使用率のメトリクス・グラフにおいて、使用率の波線と（無いなら心眼で）50%ラインが引かれているとして、50%ラインより下かつ波線より上の空白面積が多いほど無駄があることになるので、その面積をリスク低めでいかに小さくするか、に着目して施策を考えるとよいでしょう。

搾り取れ コンピューター・リソース

主に CPU / Memory の話で、必要としていない CPUパワーやメモリ容量は回収していきましょう、というシンプルな内容をもう少し具体的に掘り下げておきます。

サーバーの用途って色々あります。よくあるWEB/アプリケーション・サーバーは24時間ユーザーリクエストを受けるので常時高負荷だし、定期処理をするジョブサーバーは処理中は超高負荷でそれ以外は無風、管理画面系や社内システムなどの多くはCPU使用率が無風です。

例えば EC2 で CPU使用率が常時5％未満な社内システムが動いていたとしましょう。インスタンスタイプが m7i.xlarge (4vCPU,16GiB,$0.2604/h) でメモリはそれなりに活用されていたとしたら、CPU量だけを下げて r7i.large (2vCPU,16GiB,$0.1596/h) にすることで、機能に影響なく -$0.1008/h → 年額 $883 を削減できることになります。

メモリについては、稼働中のサーバーで全プロセスの使用中メモリ容量の合計を下記コマンドで出すと、どれくらい必要としているかが判明し、実効メモリに対しての余り容量を確認することができます（※たまに嘘のRSS値を出して実効メモリをはみ出すタイプのプロセスもいるので注意）。


この例では 16GiB のリソースの中で 12～13GB 使っているということで適切ですが、この数値が 5～6GB だったら半分以上余らせているということで削減対象になります。

もし m7i.xlarge (4vCPU,16GiB,$0.2604/h) で稼働していた場合、CPU量はそのままにメモリ容量を減らして c7i.xlarge (4vCPU,8GiB,$0.2247) にすることで、-$0.0357 → 年額 $312 を削減できます。

まとめると、CPUパワーが余っている場合は、こういう方向で

  • c7i.2xlarge → m7i.xlarge → r7i.large
メモリが余っている場合はこう
  • r7i.2xlarge → m7i.2xlarge → c7i.2xlarge
なんなら普通に１～２段階スケールダウンするスカスカ事例もありえますし、要はちゃんとCPU/Memoryの必要量をチェックして最適化しましょうというだけの話です。

ちょっと特殊気味なジョブのような使用状態が極端な性質は、空白を無くすという意味でサーバーレス化が正当な対策になると思われますが、それだと構成を変える手間が大きいので、複数のvCPUを最大で並列で何vCPU使えているかをスレッド単位で見れば、vCPU数を減らすことに悪影響がないと判断できる場合もあります。

ついでに、第５世代以降を使っている場合は第７世代への変更を検討するとコスパが良くなって、Autoscaling系なら台数を減らせる可能性が高いです。第３，第４世代からだと壁があって変更が面倒なので、それくらい古いと対策事情が異なってきます。

EC2 だけでなくコンテナ系でも考え方は同様で、たまには放置しがちな稼働中の使用リソース量チェックをすると掘り出し物が見つかるかもということで。昔と違って SavingsPlans なら柔軟な変更が許容されるので減らせるものはガンガン減らせばいいのですが、あまりに減らせる量が大きいと SavingsPlans に無駄が生じてしまう可能性があるので、できるだけ減らす調整を優先してからの購入へってことになります。

王道とは SavingsPlans / ReservedInstance なり

EC2/ECS/EKS/Lambda などのコンピューティング系は SavingsPlans で、RDS/ElastiCache などのDB系は ReservedInstance を適用することでかなり安くなりますし、特に RDS は全体に対する割合が大きいので、その効果はバツグンです。

実際に適用したり試算するとわかるのですが、料金表のような割引率が実際の費用に必ずしも効かせられるとは限りません。SavingsPlans は日割り計算（セコい…ッ）なので消化率が100% 未満になることも普通にありますし、Reserved は柔軟なのはサイズだけでクラスは別なので、使用状況によっては全てに適用できるわけではないからです。

SavingsPlans は完全な効率を人間が判断することは不可能に近いので、管理画面の試算をある程度信じて購入することになり、たまに数％の実質的な割引率低下が発生するのは許容する気持ちでいるとよいです。

Reserved は運用も大事で、複数のアカウントで扱うインスタンスクラスを可能な限り統一し、支払いアカウントで購入すると管理しやすいです。ElastiCache なら r7g に統一するのは条件的にも難しくないし、RDS Aurora MySQL もサポート期限的に古いバージョンから離脱しているはずなので r6g or r6i に統一して……

っていうか、東京 Aurora の r7g はまだですか！？


おわりに

今年の2～3月に東京 Aurora r7g が来ると予想してたのに、もう２月が終わってガッカリしたので、この話は終わり終わり～。

ってことで、皆さんも円安が落ち着くことを祈祷しながら、小銭拾いに戻ってくださいな。大金を回収できても給料は上がらんかもしれんけど！気張っていきまひょ:-)


追記・小話

様々な契約と手段

CloudFront に限らず、規模の違いで安くするための契約や手段は全然異なってくるので、これを適用して当然とか、アレを知らないなんて遅れてるぅ～のような狭い視野にならない方が良いってのは、自戒を込めての話ですね。

AWSサポート、特に営業担当に相談すればかなりの部分を把握できますが、細かい所を含めてそれが全てでもないので、ってのが今回の主旨の１つです。


財布が傷まないとインセンティブが働かない

インフラリソースやサービス運営は管理しているけど、費用は受注とかで外部が支払っているパターンってのは普通にある話です。そういう時、高額に寄ってしまうと発注側から怒られが発生する可能性はありますが、コスト削減で安くしても受注側にメリットが発生しない、という運用になりがちな気がします。

そもそもコスト削減する余地があったのだから削減して当然だとも捉えられますし、経年によってリソースに空きが出たことに対する最適化かもしれませんが、そういう判断や施策の結果を契約に盛り込む、というのはなかなか難しいようにも思います。

発注側が100％支払うからそうなるわけで、受注側も一定割合支払っていれば、コスト削減した分は安く済みますよ、とかならインセンティブが発生しそうではあります。けど、その辺は全然知らないのでどこまでが現実的かわかりません。

いちエンジニアの希望としては、インセンティブが働かないから使用状況のチェックをしないとか、無駄の放置が最適解となるのは避けられる仕組みであってほしく、その辺が悩みどころの１つでもあります。


コスパ・タイパの優劣

＞ その分の時間をフィーチャー開発に費やしたほうがトータルで儲かるってのもあるからいつやるのか悩ましい

これを理由に軽微なコスト削減に取り組まない、ってのもまた選択としては真で、尊重されるべきものでもあります。

なので開発に取り組むべき人は、最低限に必要な判断や調整をしてもらって、作業の多くは SRE的な立ち位置から手伝うってのが、ほどほどな落とし所でもあります。

一方で、放置せず取り組むメリットは小銭の回収以外にもあり、これまでどのような箇所でよく無駄が発生していたかを把握し、根本的な仕組みや文化を改める機会とすることができます。

一度改めれば、その後に扱うシステムにおいて、今までよりは確実に初手からの最適化が進み、時間経過による無駄を発生しづらい運用にできていくはずなので、ただのコスト削減ではなく元を断つという考えで取り組めば、長い目で見てタイパ・コスパの良いものとできるのではないでしょうか。

クラウドの毒と解毒

＞ ハッキリ言ってユーザーがこれだけがんばって減らさなきゃいけないのってサービスとして未成熟ですよね

クラウドの拡張性が一部毒にもなっているという話ですが、クラウド以前の拡張性と性能に乏しく、あらゆるキャパシティと戦わなくてはならない環境と比べれば、今の方が圧倒的に幸せなことは言うまでもないです。

ただ、システムの仕組みや特徴が増え、リソースの変化も多い現状では、その全てを最適化して使うってのは一般的には厳しいのではないかと思います。

最近だと、それに対応するべくキャパシティ関連を自動増減するようなシステムも出現していますが、便利が故に検証も費用も多くかかるものとなっていたりと、全てが自動最適化するような形は遠い夢な気がします。

それゆえに、コスト削減というタスクも、エンジニアのひとつの分類・ジャンルとして専門的に確立し、全員がそこまで気を使わずに済みつつも、全員に必要とする知識と文化を促すような、そんな存在が重要になってくるのでは、と考えます。



こういったコメントを頂けると、書くべきだった思考を思い出せたり、話の広がりを得られるので、嬉しいです。

こんな雑談の相手をしていただいて、ありがとうございます:-)

Posted on 2024/03/01   カテゴリー: AWS, コスト削減 パーマリンク