ENECHANGE所属のエンジニア id:tetsushi_fukabori こと深堀です。
この記事を書いている2024/04/26（金）はドル円の為替が一時156.7円まで上昇したと思ったら155円まで下ってまた156.2円位にはねたりと乱高下を繰り返しています。
今回の記事にも関係しますがAWSのコストを見るような部門には胃が痛い日々が続きますね。
見ないほうが精神衛生上よろしいのでしょうが、仕事ではそうもいかないのが辛いところです。
今回は2024年第1Q（弊社は12月決算なので1-3月が第1Qです）に実施したdev環境のインフラ構成変更と、それによるコスト削減を紹介します。
AWSでコスト対策をしようとするとどうしても悩みのタネになるNAT Gatewayを相手取って少しでもコストを下げられないか奮闘しました。
今回はAWS Transit Gatewayというサービスを利用してNAT Gatewayの台数を減らし、時間コストを削減しました。
アプリチームへの影響やコストのトレードオフが発生する対応なので事前の慎重な検討や丁寧な進行を心がけました。
この記事を届けたい人
- NAT Gatewayのコスト削減案を考えている人
- 円安ドル高と戦うソフトウェアエンジニア
- この記事を届けたい人
- 「dev環境統合」プロジェクトの概要
- dev環境ネットワークのBefore/After
- AWS Transit Gatewayとは
- dev環境統合による影響
- dev環境統合の進め方
- コスト削減効果
- まとめ
「dev環境統合」プロジェクトの概要
今回の対応はCTO室で当初「dev環境統合」と呼ばれたコスト削減プロジェクトから始まっています。
「dev環境統合」とは読んで字のごとくdev環境を統合する対応です。
もう少し具体的な話をしましょう。
ENECHANGEでは多くのサービスをtoB / ToCで展開しており、各アプリは様々な論理的境界でお互いに分割されています。
ネットワークレベルだったりAWSのアカウントレベルだったり様々ですが、相互の影響を最小化するためには何らかの分割が必要です。
分割されている以上はそれぞれのサービス毎に必要なクラウドインフラサービスを利用することになり、サービスや環境の数が増えるごとにインフラコストが発生します。
ここで本番環境でも検証環境でもない環境を「dev環境」と呼ぶことにします。
一般にdev環境には個人情報やユーザーデータは存在せず、サービス間の論理的な分割のレベルを下げてもインシデントには繋がりにくいでしょう。
また本番環境とシステム構成が同じ検証環境があれば、事前検証や不具合調査に必要な環境は充足しているので、dev環境については本番環境とシステム構成が少々変わっても業務影響は少なそうです。
このため、サービス・環境をまたいで同一のクラウドインフラリソースを共用することでコストを削減できないか、というのは「dev環境統合」プロジェクトです。
今回はdev環境統合プロジェクトのネットワークに関する対応の紹介記事です。
dev環境ネットワークのBefore/After
早速ですがBefore/Afterを見ていきます。
Beforeの要点は以下のとおりです。
- AWSアカウント内に複数のVPCが存在する
- VPC内に複数のサブネットが存在する
- サービスは複数の環境（本番/検証/dev1/dev2/...）をもつ
- 環境は複数のサブネットをもち、環境内にNAT Gatewayを単一または複数もつこともある
今回コスト削減の対象として考えたNAT Gatewayは別の外部サービスに接続をしたいサービスに配置されています。
外部サービスが接続元をIPアドレスで制限している場合などはどうしても必要になってきますが、御存知の通りコストが悩みのタネです。
Beforeの時点で対象候補として選定した範囲でいうと21サービス、25 NAT Gatewayが候補に上がりました。
Afterの要点は以下のとおりです。
- NAT Gatewayは全体で2つ（AZ毎に1つずつ、2 AZ分）に集約
- 各VPCに配置した集約用のサブネットにTransit Gateway Attachmentをアタッチする
- VPCをまたいでTransit Gatewayでネットワークを接続し、サービスのアプリケーションからインターネットへの通信は集約したNAT Gatewayを通過する
この対応によりAfterではNAT Gatewayの数が大きく減ります。
加えてNAT Gatewayに付与していたEIPも減っていますので、EIPのコストも削減になっています。
一方でAWS Transit Gatewayというリソースが新たに登場しており、こちらは逆にコストが増えることになります。
AWS Transit Gatewayとは
では今回の対応で使用したAWS Transit Gatewayというサービスについて軽く説明します。
なお、移行Transit GatewayをTGWと表記します（長いので）。
TGWは複数のネットワーク間を相互接続するネットワークサービスです。
説明を読む限りオンプレミスのネットワークとAWSを統合するためのソリューションとしての利用が念頭にありそうですね。
AWS Transit Gateway は、Amazon Virtual Private Cloud (VPC) とオンプレミスネットワークを中央ハブで接続します。この接続により、ネットワークが簡素化され、複雑なピア接続関係がなくなります。Transit Gateway は、拡張性の高いクラウドルーターとして機能し、新しい接続は 1 回だけ行われます。
TGWはネットワークを相互に接続するためのリソースで、ネットワークとTGWを接続するリソースがTGW Attachmentです。
接続したいサブネットに対してTGW Attachmentをアタッチすることでサブネット内にENIが足を伸ばします。
ENIを意識して管理する必要はありませんが、ENIがIPを使用しますのでサブネットの範囲としては加味する必要があるでしょう。
TGW Attachment 1つに対して各AZから1つずつサブネットをアタッチできます。
ルートテーブルでアタッチメントに向き先を指定すればTGWにトラヒックが流れます。
今回の対応ではほぼ決まり切ったルートになりますが、TGWにルートテーブルを定義することで宛先ごとに異なるネットワークにルーティングができます。
TGWおよびTGW Attachmentはマネージド冗長化されています。ALBなどと同じですね。
このため可用性などは意識しなくても確保されています。
条件として接続するネットワークのIPレンジが相互に重複しない必要があります。
同一AWSアカウント内であれば問題ないでしょう。
dev環境統合による影響
本対応はアプリ/インフラ双方に影響があります。
また、もちろんコスト削減になるのですが、増加するコストもあるためトレードオフを考える必要があります。
コスト面のトレードオフ
コストは以下のように増減します。
| 時間コスト | 流量コスト | |
|---|---|---|
| 減少 | $0.062 x 台数 / 時 （NAT Gateway） $0.005 x 台数 / 時 （パブリックIP） |
- |
| 増加 | $0.062 x 2台 / 時 （NAT Gateway） $0.070 x アタッチメント数 / 時 （TGW） |
$0.02 / GB （TGW） |
流量コストはNAT Gatewayの分があるのですが、この対応前後でNAT Gatewayを通る流量は変わらず、集約前の個々のNAT Gatewayを通るか集約後のNAT Gatewayを通るかの差しか無いので表からは除いています。
増加側の時間コストのNAT GatewayはAZ 2つに冗長化した弊社のケースで記載しています。
ポイントは以下のとおりです。
- 減少幅はNAT Gatewayの台数依存
- 増加幅はTGW Attachmentの個数依存
- 時間あたりコストはリソース数が同じならTGWの高くコストは増加する
- TGW Attachmentは集約先にも設置が必要なため、TGW Attachment 1つ分は必ずコスト増になる
- 流量コストは純増する
コストを削減するためには「新設するTGW Attachment数よりも削減するNAT Gateway数が十分上回る」ことと「流量コストの増加が時間コストの減少に対して小さい」ことが必要になります。
弊社の場合、以下のような状態だったためどちらもクリアしていました。
- VPCを共用しているサービス・環境があり、個々のNAT GatewayがTGW（VPCに1つでよい）に置き換えられる
- NAT Gatewayを複数AZに冗長化しているサービス・環境はTGWに置き換えられる
- dev環境は流量が少なくコストが極小
もしECSをつかっていてイメージPullが多い…とか、環境ごとにVPCが分かれていてVPC内のNAT Gatewayは冗長化していない…といったような状況ではコストメリットが出ないことが考えられます。
慎重にご検討ください。
アプリへの影響
アプリへの影響は「外向け通信の送信元IPアドレスが変化する」点です。
インフラ的にはNAT GatewayにアタッチするEIPが変わっているので当然なのですが、アプリ的には小さくない影響です。
外部システムと連携するアプリではリクエスト元IPアドレスによるホワイトリスト制限が入っていることは少なくありません。
NAT Gatewayを入れて通信している以上アプリとしては「送信元IPアドレスを固定したい」という要件がある可能性も十分に考えられるため、慎重に外部接続を検討する必要があります。
このような前提があるためバッタン切り替えではなくロールバックも視野に入れて移行を進めるとよいでしょう。
現用しているEIPは移行完了まで保持し続けることが必要になります。
dev環境統合の進め方
今回は以下のステップで移行を進めました。
1. 影響説明と参加意向ヒアリング
新たな集約NAT GatewayやTGWの設置の前に、まず候補となるNAT Gatewayを洗い出しました。
そのうえでNAT Gatewayを利用しているアプリの担当者に概要とIPアドレスが変更になること、また移行の進め方について共有しました。
この制約を呑める（またはCTO室がサポートすることで呑めるようになった）アプリだけが移行に参加できるよう、参加意向をヒアリングします。
意向に際してはむしろアプリチームの負荷が高く、外部サービスや顧客説明、作業依頼、検証といった様々なタスクが発生します。
ここで十分に納得してもらうことが成功の必須条件でしょう。
2. 事前見積もり
参加するアプリが決まったことで初めて見積りができるようになります。
弊社は構築している環境が多かったため、アプリにヒアリングする際に「実は不要だったNAT Gateway」もそれなりの個数が見つかりました。
こうして棚卸しになったことも本プロジェクトで嬉しい効果でした。
不要なリソースの削除は恒久的なコスト削減ですので積極的にやっていきましょう。
集約可能なNAT Gatewayの数と、集約に参加するアプリが属するVPCの数がわかれば削減効果が計算できます。 このコスト削減効果の規模感で実際に対応するかを判定します。
3. 集約NAT Gatewayの構築
集約NAT Gateway用のVPCやサブネット、IGW、NAT Gateway、ルートテーブルなどのネットワーク系リソースを作成します。
この時点でEIPを決めておくことでアプリ側の移行作業が行えるようになります。
4. 集約後IPへの移行
アプリチームに変更後に利用するIPアドレスを通知します。
アプリチームは顧客や外部サービスに対して「ホワイトリストに新IPアドレスを追加する」作業を行います。
弊社ではtoBのサービスもそれなりに数があり、この作業に一番時間がかかりました。
顧客からしてみると特に旨味のない作業の発生であるため、当然優先度も低くなります。
アプリ担当者の皆さんには顧客への説明や依頼など丁寧に進めて頂きとても助かりました。
5. 集約NAT Gatewayへの移行
新IPのホワイトリスト追加ができたらネットワークの経路を集約NAT Gatewayに移行します。
具体的な作業は以下のステップです。
- 移行するアプリのVPC内にTGW Attachment用のサブネットを作成（AZの個数分）
- TGW Attachmentをアタッチし、TGWのルートテーブルに以下の定義を追加する
- アプリVPCのCIDR範囲宛のトラヒックをアプリVPCにアタッチしたTGW Attachmentにルーティング
- 集約NAT Gateway用VPCのCIDR範囲宛のトラヒックを集約NAT Gateway用VPCにアタッチしたTGW Attachmentにルーティング（初回のみ）
- デフォルトルートとして集約NAT Gateway用VPCにアタッチしたTGW Attachmentにルーティング（初回のみ）
- 集約NAT Gateway用VPCのNAT Gatewayが設置されているサブネットのルートテーブルに以下を追加
- アプリVPCのCIDR範囲宛のトラヒックをTGW Attachmentにルーティング
- 集約NAT Gateway用VPCのCIDR範囲宛のトラヒックをlocalにルーティング（初回のみ）
- デフォルトルートとして集約NAT Gateway用VPCのIGWにルーティング（初回のみ）
- アプリVPCのアプリインスタンスが設置されているサブネットのルートテーブルのデフォルトルートをVPC内のNAT GatewayからTGW Attachmentに変更
- 外部サービスへの接続確認
- 外部サービスのホワイトリストから現用NAT Gatewayに付与しているIPアドレスを削除
- 現用NAT GatewayとEIPを削除
ポイントは太字の箇所です。
集約NAT Gatewayが配置されているサブネットにはリクエスト元のアプリのCIDRブロックからリクエストが到達しており、通信の戻り先もアプリのIP（アプリVPCのCIDR範囲内）です。
このためIGWが存在するサブネットには戻りのルートとして集約NAT GatewayのTGW Attachmentを明示し、そこからTGW→アプリVPCのTGW Attachmentという経路を作る必要があります。
上記の4. の手順がネットワークの切り替えタイミングですが、本プロジェクトではこのタイミングで通信断などは検知していません。
コスト削減効果
コストの削減効果を確認します。
本プロジェクトは2024/02で実施しました。 このため2024/01と2024/03のコスト比較で削減コストを確認しました。
結果として25%のコストダウンに成功しました！ 絶対値はネットワークの規模に寄りますが、十分な削減率ではないでしょうか？
削減の効果を測定するため、Cost Explorerで以下の設定で計測しています。
- 使用タイプ
- APN1-NatGateway-Hours
- APN1-TransitGateway-Hours
- APN1-TransitGateway-Bytes
- 環境（タグ）
- dev環境のみ
- ディメンション
- 使用タイプ
- 粒度
- 月別
なお使用タイプ「APN1-NatGateway-Bytes」は対応前後で本対応に関するコストが変化しないため含めていません。
まとめ
本プロジェクトではdev環境のNAT GatewayをTGWで集約することでコスト削減をはかりました。
アプリチームと協働し、慎重に進めることで利用者に影響を与えず25%のコスト削減ができました。
アプリチームと一体で様々な課題に挑戦したい方、ENECHANGEの採用サイトをぜひご覧ください。
