CROOZ TECH BLOG

~読んだらわかるSHOPLISTの裏側~

CROOZ TECH BLOGとはクルーズ株式会社の開発チームが技術について共有するブログです
開発の中での発見や知識を広めてオモシロカッコイイ〇〇をツクリます。

AWSのパブリックIPv4の有償化について

こんにちは。クルーズの鈴木です。

 

AWSより昨年7月に発表があったとおり、今月よりElastic IPアドレス以外のすべてのパブリックIPに対して課金が発生するような料金体系の変更がありました。

今回はこの話題について触れたいと思います。

 

Cost ExplolerでVPCの料金が今月急に上がった

実はパブリックIP有償化の件は、既に社内から報告を受けていたものの6か月前だったことで、Cost Explolerで請求内訳をみても「VPC料金急に上がったんだけどなんでだ…??。最近VPC PeeringやVPC Endpoint新規で作ったっけ…?」

みたいな状況で、請求額が上がった理由がIP有償化だということにすぐには気づけませんでした。

 

ただ請求書のサービス別料金の内訳をよくよく見ていくと、以下のようにVPCの内訳として「IPv4 address per hour」の記載があり、それでパブリックIPv4の料金有償化の件とつながりました。

 

 

 

月当たりどのくらいの追加課金となったか

当社の場合ですが、前月比で概ね250ドルVPC料金が上がりました。

事前に発表されていたものなので見込んではいたもののせいぜい50~100ドル程度だと予想していたのですが、予想を大幅に上回る金額となってしまいました。

 

差異要因としては現在も調べているところですが、NATゲートウエイやALBなどのマネージドサービスの場合に複数サブネットにまたがる = 当然IPも複数必要になっている。

という部分の考慮が不十分だったのではないかと考えています。

 

パブリックIPv4の有償化について

サービス利用側としてIPv4の枯渇の問題は、私が大学に通ってた頃から言われていたことではあるものの今まで当たり前に使えていたものでかなり驚きました。

そして今月のVPC請求額の急増をみて改めてIPv4の枯渇に対する実感が沸いたというのが正直な感想です。

 

利用してるサービス全体のAWS料金で見れば今回の有償化によるコスト増は1%にも満たないですが、ALBの統合などでIPv4アドレスの利用を少しで減らせる余地が無いかについて今後取り組んでいきたいと考えています。また、続報を更新します。

円安によるITインフラコスト急増に対抗するためにここ1年間で取り組んだこと

こんにちは。クルーズの鈴木です。

 

昨今、円安がすごいですよね。

年末あたり1ドル150円にまでになった時はさすがに驚きました。

 

さて、皆さんがお勤めの会社ではドル支払のクラウドサービスは利用しておりますでしょうか?

AWSGCPなどを利用されている会社はそれなりに多いのではないかと思います。

当社もAWSGCPを利用しており、2022年ごろか急激に進み始めた円安の影響で当社でもドルで支払っているインフラコストは上昇し、ここ1年で約1~2割多く支払いをしている状況です。

 

今回は、この円安分の費用上昇分を削減すべく、ここ1年間で取り組んできたことについて紹介したいと思います。

個々の会社によってアーキテクチャや、エンジニアリングチームの体制、得意分野など異なるとは思いますが、同じ悩みを抱えている方で何かの参考になればと思っています。

 

まずは考え方を変えるところから

「円安でインフラコストあがっちゃってさあ。(省略)。でどうしようか?」

という話を数名としたのですが、リアクションとして「どうしようもなくない?」という反応が大半でした。

確かにエンジニアの視点からみれば、クラウドベンダーはここ1年間同じ性能のシステムリソースに対して同じ金額をドルで支払っていて、かつ原因は為替でありエンジニアとしては為替変動はアンコントローラブルだから、まあ言ってしまえば「どうしようもない」です。

ただ、我々は日本で商売をしていて、お客様から日本円で料金をいただいて、サービスに必要なインフラコストを含む料金を日本円で支払っているので、ドル支払いの金額が変わらなくても、円安になれば日本円での支払額は増えてしまいます。

 

なので

・為替レート云々ではなく、インフラコストは円換算で考える。

・要するに追加でコストを1~2割削減すればよい。

・為替レートはアンコントローラブルだけど、実装やサービス選定などはエンジニアでコントロールでき、ここで追加削減ができないかを考えればよい。

・上記が実現でき、かつ円安→円高に進めば何もしなくてももっとコストが勝手に下がる

という考え方に基づいてどこの費用減らせる?を考えて取り組んできました。

 

コスト内訳を細かく分析する

AWSGCPをはじめとする各クラウドサービスにはコスト内訳の見れるダッシュボードがあります。

例えばAWS だとCost ManagementやCost Explolerなどです。

当社でも以前よりどのサービスでどの程度費用が発生しているか、各サービスのインスタンス毎のメトリクスや、ZabbixやPrometeusなどをはじめとする監視システムで性能的な余剰が無いかなどは確認し、問題があればリソース見直しを進めていました。

 

だだここも、今までと同じ運用をしているだけでは新たな削減余地が見つけられないため、コストカテゴリ毎や、インスタンスタイプ毎、APIの種類毎などディメンジョンを細分化して一体何の費用発生が多いのかを細かく見ていきました。

 

EBS料金、ネットワーク転送料金は削減余地あり

コストを分析していく中でEC2やS3、ECSといったサービス単位で分類して考えがちですが、細かく見ていくうえでEBSに対しての費用割合が多いことに気づきました。

当社の場合、ECSやRDSなどのPaaSも使用していますが、EC2の利用も依然あり、端的に言えば仮想サーバのSSDです。

なのでEBSの料金を抑制するために以下を実施、現在も進めています。

 

インスタンスのスペックアップにより稼働インスタンス数(EBS個数)を減らす。

  →結果としてインスタンス数が減るのでEBSのボリューム数も減る。

・DBを役割別に分ける&インスタンスサイズの最適化&稼働インスタンス数を減らす。

  →前提の思想は上記記載と同じでスペックアップで台数を減らす。

  →役割別に分けることで、1インスタンスあたりのEBSサイズを減らす。

  →役割別に分けることで、役割毎に必要な稼働インスタンス数(EBS個数)を減らす。

 

またネットワーク転送については、細かく見てみると意図していない料金発生がありました。

具体的にはCDN上に配置できるような静的コンテンツに対して、EC2などへの直接参照や、CDN上に同一コンテンツがあるリソースなんだけどオリジンサーバを見ているケースです。

このあたりはコスト分析であたりを付けつつ、ソース上あたりを付け、参照先を差し替えるという地道な対応となるのですが現在進めています。

 

円安のタイミングにコスト削減を行う重要性

インフラのコストを削減は簡単にできるものばかりではなく、何かしらの作業工数がかかります。

 

例えば最小構成分をリザーブインスタンスやSavingsPlans で購入するなど、「買い方」の工夫などは手間も少なく当社も既に取り入れています。

一方でインフラ構成変更やプログラム変更を伴うものもあり、そのような場合に開発、テストなどでそれなりの作業量が発生し、削減施策実施のタイミングや既存開発との優先度などでどちらを先にすべきかで議論になることがあります。

この議論の結論は私の考えとしてはどちらを優先にではなく、両方重要なものなので進めるが正しいと思っています。優先度の議論をすると進まなくなるからです。

当然エンジニアの人数には限りはありその中で何に注力するかという話は重要だと思っています。ただ注力しない = 全くやらないだけだと本当に進まなくなるので、できる範囲で。ただし1週間何もしないのではなく最低でもN時間はコスト削減に充てて少しずつでもよいので進めるという進め方にすべきだと考えて今進めています。

 

また為替レートはエンジニアから見るとアンコントローラブルだということは、今後上がるかもしれないし下がるかもしれない。であれば、円安のタイミングでコストの削減が行え、仮に仮に将来円高に動けば何もしなくてもさらにコストが下がる。そうすればその削減分でサービス向上のため投資ができる可能性があり、円安の今だからこそ改めてコスト削減余地が無いかについて見なおすべきだと考えています。

 

今回は具体的なインフラコストの削減事例としてEBS、ネットワークトラフィックに着目した部分について紹介しましたが、ほかにもプログラム的に実施している処理のインフラサービスへの外出し、プログラム改修によるシステムリソース消費量の削減など鯖ざまな施策を行っております。

これらの施策についても機会があれば紹介したいと思っております。

未経験からエンジニアになって思うエンジニアを経験するメリット

こんにちは。新卒2年目のKEN☆YAMAGUCHIです!

今回は「未経験からエンジニアになって思うエンジニアを経験するメリット」というタイトルでお話をしたいと思います。

僕自身、未経験からエンジニアになり1年間エンジニアをして開発部に所属しておりました。その後は事業部に異動となり現在に至ります。

そこで今回は、エンジニアという技術職を経験したのちにビジネス職に転向した際に感じたエンジニアを経験することのメリットについてお話しさせていただきます。

駆け出しエンジニアの方はもちろん、エンジニアを目指している方、エンジニアに少しでも興味がある方にとってためになるのではないかと思うので、最後まで読んでいただければ幸いです!

続きを読む

未経験からSQLを学ぶ上で知っておくべき勉強法をまとめてみた

こんにちは。新卒2年目のRYOBALです。

入社後1年間サーバーサイドエンジニアとして業務を行い、その後プロモーション部でSHOPLIST内のデータ分析や施策提案などを行っています。今でもBigQueryでSQLを使ったデータ分析を日々行っています。

今ではSQLを使った分析は欠かせないスキルで今後も業務で成果を出すために欠かせないスキルだと考えています。

今後、エンジニアやマーケティング業務を行っていきたい方は身につけておくと非常に役立つスキルです。

今回はそんな僕が未経験からSQLを学ぶ上で知っておくべき勉強法を紹介しますのでぜひ最後まで読んでみて下さい。

続きを読む

エンジニアも外部のメディアに露出することの重要性

こんにちは。新卒2年目のKEN☆YAMAGUCHIです!

今回は「エンジニアも外部のメディアに露出することの重要性」というタイトルでお話をしたいと思います。

僕自身の話をすると、メディアというのはおこがましいですが、本ブログの執筆・Twitterアカウントの運用・イベントへの登壇を経験しております。

これらの経験をしていく中で、エンジニアの方がメディアへ露出している姿を目にすることが多くなりました。その中で感じた技術広報の重要性や実際にSHOPLISTが行っている広報活動についてお話しできればと思います。

駆け出しエンジニアの方はもちろん、エンジニアを目指している方、エンジニアでメディア露出へのご興味がある方にとってもためになるのではないかと思うので、最後まで読んでいただければ幸いです!

続きを読む