VPCを切りすぎて失敗した話

Transcript

1. VPCを細かく切りすぎて失敗した話 tamagoya
2. ⾃⼰紹介 @tamagoya 梅⽥の会社で、WEBサービスのインフラ基盤に携 わり始めてから10年ほど 今年第⼀⼦が⽣まれました。 育児が⼤変で、活躍されているお⽗さんエンジニア の凄さを改めて感じる昨今。 好きなAWSサービス︓ CloudFront
3. 時は約3年前に遡ります
4. オンプレサーバのインフラ運⽤に⾟さを感じていました • 200台近いサーバが⾃由に通信できるネットワーク構成 • サーバをまたがる300以上のバッチ処理
5. オンプレサーバのインフラ運⽤に⾟さを感じていました • 200台近いサーバが⾃由に通信できるネットワーク構成 • サーバをまたがる300以上のバッチ処理 結果 • インフラをいじる時はtcpdumpを使って、サーバがどの タイミングでどこと通信しているか調査が必要 つらい
6. 他社のオンプレインフラに感銘を受ける • オンプレにサーバ台数と同じ量のL3通信機器を整備 • サーバ間の通信はLBとルータで制御 • リリースはサーバをアップデートするのではなく、ネッ トワーク機器の切り替えだけのブルーグリーンデプロイ
7. でも既存のオンプレ環境に いきなりそんな⼤きな変更はできない
8. そうだ︕ AWSのVPCを使えばできるかもしれない
9. ネットワークをうまく設計してAWS移⾏したい︕ オンプレからAWS移⾏が本格的に始まる時期 • オンプレからサブシステム単位でクラウドに移⾏ • サブシステムをAWSにどんどん作っていくにあたり、ネ ットワーク構成について基本⽅針が必要 VPCやサブネットはいくら切っても無料 • サブシステムのWEB、DB、バッチ毎に、VPCで分離して トランジットゲートウェイ(TGW)で接続先を制御
10. AWSネットワーク設計の２つの⽬的と実装⽅針 1. ブルーグリーン・デプロイメント a. サーバやDBをルーティング変更でリリース 1. セキュリティ観点で多層防御 a. IPルーティングの制御 ⇨ TGWとルーティング b. tcp/udpでの制御 ⇨ セキュリティグループ
11. 3年後。。。
12. VPC費⽤が爆増 VPCはいくら切っても無料だったのでは。。。
13. VPCは無料。でもその有料付属品は結構ある • secrets managerなどのPaaSためにVPCのインターフェ ース型エンドポイントは必要 • TGWも各種VPCにアタッチすると累積される 時間課⾦なので本番再現環境では費⽤が発⽣し続ける
14. そもそも論
15. そもそもやりたかった２つの⽬的は別の⽅法で実現可能 1. ブルーグリーン・デプロイメント a. サーバやDBをルーティング変更でリリース 1. セキュリティ観点で多層防御 a. IPルーティングの制御 ⇨ TGWとルーティング b. tcp/udpでの制御 ⇨ セキュリティグループ
16. ブルーグリーン・デプロイメントは別の⼿段で実装 • アプリに与える環境変数で接続先を変えるのが⼀般 • DNSで接続先の実態を変えても良い • 全接続元から⼀⻫に切り替えたい時は、RDS Proxyや ELBを利⽤
17. 多層防御は別のレイヤーで実現しても良い 階層名 今回の防御 代替案(ネットワークを頑張らない) アプリケーション層 接続用のID/PW、IAMロール プレゼンテーション層 セッション層 トランスポート層 セキュリティグループ セキュリティグループ ネットワーク層 VPC、ルーティング、TGW データリンク層 物理層
18. 教訓
19. VPCを細かく切って複雑なことをしても旨味は少ない • VPCを切るのは実質無料じゃない
20. VPCを細かく切って複雑なことをしても旨味は少ない • VPCを切るのは実質無料じゃない SA(藤原)さんからのアドバイス • VPCはオンプレのネットワーク境界を仮想的にAWS上に 再現した概念で、オンプレのネットワーク構成のやり⽅ をAWSに持ち込む必要がなければ、駆使する必要はない • VPC間のネットワークレーテンシーが、お⾦で解決でき ないボトルネックになる可能性もある
21. まとめ • ネットワークは特別な事情がない限りシンプルに • デプロイやセキュリティの最適化は上位レイヤーを活⽤ • 設計思想はSAさんに相談しよう︕