こんにちは。クルーズの鈴木です。
昨今、円安がすごいですよね。
年末あたり1ドル150円にまでになった時はさすがに驚きました。
さて、皆さんがお勤めの会社ではドル支払のクラウドサービスは利用しておりますでしょうか？
AWSやGCPなどを利用されている会社はそれなりに多いのではないかと思います。
当社もAWSやGCPを利用しており、2022年ごろか急激に進み始めた円安の影響で当社でもドルで支払っているインフラコストは上昇し、ここ1年で約1～2割多く支払いをしている状況です。
今回は、この円安分の費用上昇分を削減すべく、ここ1年間で取り組んできたことについて紹介したいと思います。
個々の会社によってアーキテクチャや、エンジニアリングチームの体制、得意分野など異なるとは思いますが、同じ悩みを抱えている方で何かの参考になればと思っています。
まずは考え方を変えるところから
「円安でインフラコストあがっちゃってさあ。(省略)。でどうしようか？」
という話を数名としたのですが、リアクションとして「どうしようもなくない？」という反応が大半でした。
確かにエンジニアの視点からみれば、クラウドベンダーはここ1年間同じ性能のシステムリソースに対して同じ金額をドルで支払っていて、かつ原因は為替でありエンジニアとしては為替変動はアンコントローラブルだから、まあ言ってしまえば「どうしようもない」です。
ただ、我々は日本で商売をしていて、お客様から日本円で料金をいただいて、サービスに必要なインフラコストを含む料金を日本円で支払っているので、ドル支払いの金額が変わらなくても、円安になれば日本円での支払額は増えてしまいます。
なので
・為替レート云々ではなく、インフラコストは円換算で考える。
・要するに追加でコストを1～2割削減すればよい。
・為替レートはアンコントローラブルだけど、実装やサービス選定などはエンジニアでコントロールでき、ここで追加削減ができないかを考えればよい。
・上記が実現でき、かつ円安→円高に進めば何もしなくてももっとコストが勝手に下がる
という考え方に基づいてどこの費用減らせる？を考えて取り組んできました。
コスト内訳を細かく分析する
AWSやGCPをはじめとする各クラウドサービスにはコスト内訳の見れるダッシュボードがあります。
例えばAWS だとCost ManagementやCost Explolerなどです。
当社でも以前よりどのサービスでどの程度費用が発生しているか、各サービスのインスタンス毎のメトリクスや、ZabbixやPrometeusなどをはじめとする監視システムで性能的な余剰が無いかなどは確認し、問題があればリソース見直しを進めていました。
だだここも、今までと同じ運用をしているだけでは新たな削減余地が見つけられないため、コストカテゴリ毎や、インスタンスタイプ毎、APIの種類毎などディメンジョンを細分化して一体何の費用発生が多いのかを細かく見ていきました。
EBS料金、ネットワーク転送料金は削減余地あり
コストを分析していく中でEC2やS3、ECSといったサービス単位で分類して考えがちですが、細かく見ていくうえでEBSに対しての費用割合が多いことに気づきました。
当社の場合、ECSやRDSなどのPaaSも使用していますが、EC2の利用も依然あり、端的に言えば仮想サーバのSSDです。
なのでEBSの料金を抑制するために以下を実施、現在も進めています。
・インスタンスのスペックアップにより稼働インスタンス数(EBS個数)を減らす。
→結果としてインスタンス数が減るのでEBSのボリューム数も減る。
・DBを役割別に分ける＆インスタンスサイズの最適化＆稼働インスタンス数を減らす。
→前提の思想は上記記載と同じでスペックアップで台数を減らす。
→役割別に分けることで、１インスタンスあたりのEBSサイズを減らす。
→役割別に分けることで、役割毎に必要な稼働インスタンス数(EBS個数)を減らす。
またネットワーク転送については、細かく見てみると意図していない料金発生がありました。
具体的にはCDN上に配置できるような静的コンテンツに対して、EC2などへの直接参照や、CDN上に同一コンテンツがあるリソースなんだけどオリジンサーバを見ているケースです。
このあたりはコスト分析であたりを付けつつ、ソース上あたりを付け、参照先を差し替えるという地道な対応となるのですが現在進めています。
円安のタイミングにコスト削減を行う重要性
インフラのコストを削減は簡単にできるものばかりではなく、何かしらの作業工数がかかります。
例えば最小構成分をリザーブドインスタンスやSavingsPlans で購入するなど、「買い方」の工夫などは手間も少なく当社も既に取り入れています。
一方でインフラ構成変更やプログラム変更を伴うものもあり、そのような場合に開発、テストなどでそれなりの作業量が発生し、削減施策実施のタイミングや既存開発との優先度などでどちらを先にすべきかで議論になることがあります。
この議論の結論は私の考えとしてはどちらを優先にではなく、両方重要なものなので進めるが正しいと思っています。優先度の議論をすると進まなくなるからです。
当然エンジニアの人数には限りはありその中で何に注力するかという話は重要だと思っています。ただ注力しない = 全くやらないだけだと本当に進まなくなるので、できる範囲で。ただし1週間何もしないのではなく最低でもN時間はコスト削減に充てて少しずつでもよいので進めるという進め方にすべきだと考えて今進めています。
また為替レートはエンジニアから見るとアンコントローラブルだということは、今後上がるかもしれないし下がるかもしれない。であれば、円安のタイミングでコストの削減が行え、仮に仮に将来円高に動けば何もしなくてもさらにコストが下がる。そうすればその削減分でサービス向上のため投資ができる可能性があり、円安の今だからこそ改めてコスト削減余地が無いかについて見なおすべきだと考えています。
今回は具体的なインフラコストの削減事例としてEBS、ネットワークトラフィックに着目した部分について紹介しましたが、ほかにもプログラム的に実施している処理のインフラサービスへの外出し、プログラム改修によるシステムリソース消費量の削減など鯖ざまな施策を行っております。
これらの施策についても機会があれば紹介したいと思っております。
