AWSKRUG 네트워크 소모임 (2024.04)

쿠버네티스 클러스터 마이그레이션 작업 후기(feat. istio envoyfilter의 난) - 발표자 : 박새미 (데브시스터즈)

• 클러스터 마이그레이션?
  • 오래된 클러스터에 있던 서비스를 새 클러스터로 옮긴다.
  • 앱들이 대부분 helm 차트로 깎아서 ArgoCD로 배포하고 있음.
  • 이 차트로 구 클러스터와 새 클러스터 모두에 잘 배포한다.

헬름차트? (모네 vs 르누아르의 사례) => 뭘 하고자 하는지는 알겠는데, 비슷비슷하고 다른 부분도 조금씩 있고...

수문장?

• 데브시스터즈에서 아이템 지급 인증에 사용하는 서버
• istio의 external authorization 기능을 이용한 외부 인증 서버
• gRPC 스펙을 따르는 서버
• 그래서 어떻게 동작하냐?
  • 클라이언트는 istio ingress gateway를 통해 서비스에 요청을 보낸다.
  • 이 때 istio는 external authorization 서버에 요청을 보내서 인증을 받는다.
  • istio는 envoy filter를 이용해서 이 요청을 가로채서 external authorization 서버에 요청을 보낸다.

문제점

범인은 sni였음.

• SNI (Server Name Indication)
• 어떻게 동작 중인가?
  • ALB로 들어온 요청이 Istio Ingress Gateway로 들어온다.
  • Istio Ingress Gateway는 envoy filter를 이용해서 요청을 가로챈다. 등등...
• 근데 왜 문제가 생겼나?
  • 구 클러스터에서는 NLB를 써서 istio gateway에서 tls termination을 수행했다.
  • 신 클러스터에서는 ALB를 써서 tls termination을 ALB에서 수행하고, istio gateway에서는 SNI를 기반으로 뭔가를 할 수가 없다.

배운 점

• istio ingress gateway가 아닌 LB 단에서 TLS Termination이 수행될 경우, SNI 기반의 filter patch가 불가하다.
• envoyfilter.EnvoyConfigObjectMatch 설정을 잘못 수행했을 때 silent error를 겪을 수 있다.

그래서 해결책은?

• istio gateway를 안 쓰고 Sidecar container로 바로 받아서 쓰도록 했음
• 그리고 일부 코드 수정까지

알아 두면 쓸모 있는 AWS 네트워크 아키텍처 - 발표자 : 고재성 (SKTelecom)

Hybrid Cloud를 위한 네트워크 인프라

• 멀티 VPC 환경에서 On-Prem과 Clodu를 연결하는 방법
  • 전용선을 Transit Gateway까지 끌어오고, Transit Gateway를 통해 VPC와 연결
  • 이외에 Peering 등...
• 그런데... Transit Gateway가 결코 싸지 않음...
• 일반적으로 AWS에서 Data Transfer 비용을 책정한다고 하면 inbound는 무료고, outbound만 비용이 발생한다.
• 그런데 Transit Gateway는 inbound/outbound 모두 비용이 발생한다. (GB당 0.02달러정도)
• 저걸 어떻게 줄이지? 에서 고민이 시작되었다.
• 왜? 대용량 트래픽이 On-Premise에서 AWS로 들어오는 경우가 많기 때문에...
  • 회선을 따져보니 10G 2개, 40G 2개로 쓰고 있는데, 이걸 평균적으로 따져보니 월에 5천만원, 연간 6억원정도가 나오더라.
• 그래서 Transit Gateway는 뒤로 뺐다.
  • On-Prem에서 오는 트래픽은 DX Gateway(Direct Connect Gateway)를 통해 VPC로 들어오게 했다.
• DX Gateway는 연결할 수 있는 VPC 개수 제한이 있기 때문에 3개로 나눠서 쓰고 있다. (당시에는 10개가 리밋이었는데 작년 3월에 20개까지 늘어났다고 함)

하이브리드 환경에서 AWS 서비스 사용

사설 망에서 AWS 서비스를 사용하려면?

• VPC Endpoint ENI를 사용해서 VPC로 접근하고, 프라이빗하게 API Gateway나 Kinesis, Code Commit같은 서비스를 사용할 수 있다.
• 이걸 쓸 때 Endpoint ENI를 2개 만들어뒀다고 가정하고, VPC Endpoint를 통해서 API Gateway로 꽂는다고 가정하자.
  • 이 때 API Gateway 주소가 있다고 하고, 그쪽으로 요청을 nslookup같은걸로 보내보면 IP가 공인이 아니고 private ip가 나오고 vpc endpoint eni가 잘 resolving된다.
  • 그런데 on-prem 환경에서 api gateway의 주소를 쏘면 resolving이 안된다. DNS때문에.
  • 그래서 Route53 Resolver(inbound)를 사용해서 on-prem에서도 VPC Endpoint를 통해 AWS 서비스를 사용할 수 있게 했다.
    • 어떤 가용 영역에서 만들건지, 어떤 VPC에서 만들건지, 어떤 서브넷에서 만들건지 등을 설정할 수 있다.
    • 그리고 이걸 통해 on-prem에서도 Inbound Endpoint를 통해 AWS 서비스를 사용할 수 있게 했다.
  • 그런데 서버가 여러대고 그러면 이런 설정을 일일이 해주기가 어렵기 때문에, On-Prem DNS 서버에 Conditional Forwarding을 설정해서 Route53 Resolver로 가게 할 수 있다.
    • 그러면 On-Prem에서 동일한 엔드포인트로 요청을 해도 잘 resolving을 되게 만들 수 있다.
    • 그러면 On-Prem이든 Cloud든 동일한 URL을 가지고 API Gateway를 호출할 수 있다. very good!
• 그러면 S3는?
  • S3는 Gateway Endpoints랑 Interface Endpoint를 둘 다 이용해서 사용할 수 있다.
  • 그러면 Interface Endpoint를 두 개 만들어놓고 S3를 nslookup으로 찔러보면? 공인 IP가 나온다.
  • 그러면 어떻게 해야되냐? Interface Endpoint에서 Private DNS를 설정해줘야 한다. (기본은 Disable)
    • 그래서 일일이 Private DNS를 설정해줘서 해당 Endpoint에 대해 Private DNS를 응답할 수 있게 해야 한다. 저걸 켜게 되면 Private으로만 응답한다.
    • 그리고 이렇게 하려면 Gateway Endpoint를 반드시 켜줘야한다. Cloud 안에서는 Gateway Endpoint를 통해서 S3에 접근하면 되고.
    • On-Prem에서는 Interface Endpoint를 통해서 S3에 접근하게 된다.
  • 이렇게 하면 Cloud와 On-Prem에서 동일한 URL로 S3에 접근할 수 있다.
  • 그리고 만일 On-Prem에서 DNS 설정을 따로 안 하고 그냥 S3에 접근하려면? DNS 주소를 AWS에서 제공해주는 VPC Endpoint DNS 주소로 바꿔주면 된다. (Conditional Forward를 안 써도 접근 가능)
    • 다만 이렇게 하면 Cloud와 On-Prem에서 동일한 URL로 S3에 접근할 수 없다.

Private 경로를 통한 AWS Public 서비스 사용

• Public 서비스로 접근하려면? 전용선을 쓰고 VPC Endpoint를 이용하면 된다. (요거는 Private VIF)
• 그런데 다른 방법도 있음. Public VIF
  • Private Network 연동 : VPC 연동, 사설 AS / IP로 연동 가능 - Private VIF
  • Public Service 연동 : AWS Public 서비스 연동 가능, 공인 AS / IP로 연동 가능 - Public VIF
    • 그리고 이렇게 하면 단가도 더 쌈
• 그리고 Public VIF를 쓰면 공인 IP를 써야하기 때문에 On-Prem에서 NAT를 한 번 거쳐서 Publci VIF를 통해 퍼블릭 서비스에 접근하면 된다.

AWS -> On-Prem 연동 시, On-Prem 보안 설정 최적화 방안

• On-Prem에서 Cloud로 점진적 전환할 때, On-Prem에는 서비스가 일부 남아있고, Cloud에도 일부 서비스가 있을 때, Cloud -> On-Prem 방향으로 통신이 이뤄진다.
• 근데 이럴 때 보면 막 MSA로 간다면서 EKS Cluster를 만들거나, ASG를 가지고 막 스케일링을 하거나.
• 근데 이렇게 하다보면 IP 개수가 되게 많아지고, 보안 설정 잡기가 되게 힘들다.
• 막 C클래스 통으로 열어줘! 이러면 보안팀 극대노 시전 가능 ㅋㅋ
• 그래서 이럴 때는? NAT G/W 같은거 써서 묶어서 보내려고 많이 하겠지.
• 그러면 On-Prem에는 NAT IP만 열어주면 되니까.

그런데... NAT G/W 사용하면서 이슈가 발생할 수 있음. - ErrorPortAllocation 오류

• NAT G/W는 최대 55,000개의 동시 연결을 지원하는데, 이걸 넘어가면 ErrorPortAllocation 오류가 쭉 올라간다.
• 그래서 이럴 때는? 2023년 2월부터 NAT G/W의 용량을 늘릴 수 있게 된다.
  • 여러 IP 주소를 추가하여 최대 440,000개의 동시 연결을 지원할 수 있게 된다. (8배)
• 그래서 이걸 어떻게 하냐? NAT G/W에서 Secondary IP 주소를 넣으면 개수가 늘어나고, 8개까지 늘려서 최대 440,000개의 동시 연결을 쓸 수 있다.

IP 대역 중복시 통신 방법 (AWS간 통신, AWS - On Prem 간 통신)

• VPC 1번이 10.0.0.0/24 대역이고, VPC 2번도 10.0.0.0/24 대역이면? 통신 안되지.
• 마찬가지로 On-Prem도 10.0.0.0/24 대역이고, VPC도 10.0.0.0/24 대역이면? 당연히 통신 안되지.
• 그래서 중간에 Loadbalancer VPC를 둔다.
  • VPC와 LB VPC 간에는 Peering이나 Transit Gateway를 통해 연결하고, LB VPC와 On-Prem 사이에는 VPN이나 DX를 통해서 연결한다.
  • 그러면 LB VPC에서는 ALB나 NLB를 가지고 라우팅만 거쳐가도록 설정해주면 된다.
• 그러면 중간에 있는 LB VPC의 LB가 NAT 역할을 해주면서 중복되는 IP 대역을 통신할 수 있게 된다.

그런데...

• IP까지 동일한 그런 상황이면? 완전히 대역까지 동일하면... (e.g. VPC1은 10.0.0.0/24, On-Prem도 10.0.0.0/24)
• 그러면 중간에 LB VPC를 10.0.1.0/24 정도로 만들어주고, VPC1과 LB VPC 간 Peering이나 TGW를 끊고, Private Link를 통해서 연결한다. 그리고 On-Prem과 LB VPC 간 VPN이나 DX를 통해서 그대로 연결한다.
• 그리고 LB VPC에는 NLB를 두고, On-Prem과만 라우팅 테이블을 구성하고 통신하면 된다. On-Prem에서는 LB VPC쪽으로 통신하면 되는거고.
• 그러면 이렇게 하면 IP까지 동일한 상황에서도 통신이 가능하다.

그리고 LB VPC 대신에 Endpoint VPC를 두고 Endpoint ENI를 가지고 LB 역할을 해서 써도 된다.