[AWSKRUG] 4월 1일 (월) - 네트워크 #network 소모임 후기

역시 내 직무와 핏하진 않지만 재밌어보여서 들으러간 세션

 

일단 우리서버에도 istio가 있는데 딱히 특별한 동작을 하고 있진 않지만 일단 클러스터로 떠 있으니 istio가 뭔지만 알아도 도움이 될 거 같아서 참석(istio는 kiali라는 거랑 같이 많이 쓴다고 함)

 

그리고 두번째 세션인 AWS network는 어떤 내용을 할지가 궁금했는데, 생각과는 전혀 달랐던 세션이라 아쉬웠다.

 

1. 쿠버네티스 클러스터 마이그레이션 작업 후기(feat. istio envoyfilter의 난)

구 클러스터 -> 신 클러스터, 최신 메타에 맞춰가기 위함

 

구 클러스터의 헬름 차트 : 뭘 하고자 하는지 알겠는데, 미묘하게 다르고 최신 메타는 아님 

 

작지만 묵직한 녀석

- 아이템 지급 요청 등을 받았을 때 해당 요청을 보낸 주체를 확인하여 통과하거나 막아주는 서버 일명 수문장

넘지 못하면 서버에 도달 못함

 

istio external authorization외부 인증서버

실질적인 특정 gRPC 스펙을 만족하는지 검증하는 작은 서버

 

client -> ingress gateway -> 수문장 -> sidecar proxy(application) -> DB

 

envoy filter

어떤 요청이 A를 만족하면 B를 하겠다는 것

external authorizatoin은 envoy filter를 사용함 : API를 입맛대로 쓰기위해서 사용하는 기능(커스텀 파라미터를 제공)

 

헬름 차트가 있어서 일부만 수정하면 되지 않으라 했지만 안됨

sni가 범인 : server name indication 클라이언트가 호출하려는 서버의 올바른 ssl 인증서를 확인할 수있도록 도와줌

 

TLS termination이 alb에서 일어남 구 클러스터에서는 NLB를 썼음 isito ingress gateway에서 tls termination

신 클러스터에서는 AL에서 ㅠㅠ 그래서 SNI 기반으로 뭔가 할 수 없음

 

isito ingress gateway에서 로드 밸런서단에서 tls termiatin이 수행됨 -> sni 기반의 fiter patch가 불가능

envoyfilter.EnvoyConfgiObjectMatch 설정을 잘못 수정했을 때 silent error를 겪음

ex) subfilter 까지 지정했지만 해당 subfilter는 지정한 filer 밑에 존재하지 않음

 

context gateway -> sidecar로 요청을 받고, 수문장 코드자체를 수정함

 

잘모르는 내용이지만 본인이 트러블 슈팅을 이야기 해줬음

 

질문) 왜 NLB로 회귀하지 않았나?

조직이 커지면 TLS 인증서 관리가 애매해지는데 ALB에서 처리하는게 가장 편함.

 

그리고 인프라 팀에서 클러스터를 관리하는게 아니고, 개발팀에서 관리하는 경우도 많은데 인증서 관리는 일반적으로 인프라팀에서 함

 

그래서 ALB에서 NLB로 회귀할 수 없었음

 

큰 조직에서 있을 법한 문제들을 들을 수 있어서 좋았음

(우리는 ALB를 하나만 쓰고 있기 때문에 인증서 관리가 딱히 어렵지 않음 ㅠㅠ)

---

2. 알아 두면, 쓸모 있는 AWS 네트워크 아키텍처

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

On-Premises - VPC 연결을 해야됨 근데, VPC가 나눠쓰게 됨(멀티 VPC 환경)

 

대규모 VPC 환경에서는 어떻게 하느냐?

 

전용선을 트랜지케이터?에 연결하고 VPC에 연결함, 그런데 트랜지케이터가 너무 비쌈

 

트래픽이 많아지면 가격이 늘어남

 

AWS끼리 주고받는건 무료 ! AWS는 outbound만 비용을 받음, 트렌지케이터는 data proccessing 비용이 나감 

 

어떻게하면 비용을 줄일 수 있을까? 대용량 데이터도 주고 받는데...

 

발표자 분은 VPC를 12개를 관리함(상용은 2개 - 실시간 대용량 트래픽이 흐름)

 

7~8G / 20~30G가 흐름 : 한달에 5천만원 트래픽 비용 인프라 비용은 더큼 ㅠ

 

트랜지케이터를 뒤로 뺌. 전용선을 DX 게이트웨이로 VPC로 개별적으로 연결, 그리고 분리...

 

결과 : 연간 4억을 줄임!!

 

Hybrid 환경에서 AWS 서비스 사용

On-Premises - AWS Cloud 전용선을 쓰는 경우도 있음 

 

Endpoint ENI를 VPC에 만들어줌 -> IG를 타지 않고 eni에 할당받은 ip를 활용하고 api gateway에 연결해서 사용

 

그런데 nslookup으로 ip를 쿼리했을 때 vpc의 ip를 알 수가 없었음

 

그래서 On-Premises DNS(Conditional fowarder)에서 - route53 resolver(inbound) 을 연결

 

s3용 interface endpoint가 필요하다. 그리고, 프라이빗 DNS 이름을 활성화 해야지 vpc 안에서 쓰지못하도록 한다.

 

On-Prem. -> AWS 연동 시 온프레미스 보안 설정 최적화

interface endpoint에 대한 ip 정책 : 방화벽을 뚫어야되는데 VPC 내부에 접근할 때는 IP가 랜덤 생성됨 - 그런데 이제는 지정 가능

 

서브넷을 생성할 때 IPv4 Address를 지정하면, 사용자 지정 IP를 관리하기 수월해짐

 

Private 경로에서 퍼블릭 서비스 이용하는 법

Private VIF 사용 사설 VPC endPoints에 접근 하도록하는 방식

 

Public VIF을 쓰면 쌈...  S3, API G/W, Kinesis와 같은 퍼블릭 서비스를 연동할 때 좋음

 

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

Cloud 인프라의 스케일 인/아웃 및 변경되는 IP 환경, 파드가 늘어날 때마다 접근하는 IP가 늘어날거임

 

방화벽 때문에 막혀서 계속 요청해야할 수도 있다. But NAT G/W를 통하면 해결할 수 있음!

 

NAT 사용 이슈 : 최대 55000개 동시 연결만 지원. ErrorPortALlocation 지표 증가. 여러 NAT GATEWAY에 여러 IP 주소를 추가할 수 있도록 지원(최대 8개 - 440000개 동시 연결 지원) - secondary ip 추가

 

IP 대역 중복 시, 통신 방법

AWS 간, AWS와 온프레미스 간의 통신에서..

 

vpc간 대역이 같으면 라우팅 불가. vpc - 온프레미스도 마찬가지

 

중간에 Load Balancer VPC를 두고 ALB or NLB를 이용

 

그냥 가장 좋은건 VPC의 IP를 바꾸면 됨...

 

IP가 아예 똑같으면 lb vpc를 못 씀, private link와 nlb를 활용해라.

 

중간부터는 쓰다 말았음. 어떻게 써야할 지 잘 모르겠어서...ㅠ

 

온프레미스의 비중이 너무 높아서.. 잘 와닿지 않았던 세션.

 

온프레미스를 쓸 당시에 나한테는 권한이 하나도 없었기 때문에 네트워크 단은 다뤄보지 못했었다.

 

그래도 AWS를 쓰면서 VPC와 동적 IP에 대한 내용은 어느정도 알고 있어서 아예 못 알아 듣지 않았다.

 

VPC Basic은 ... ㅠㅠㅠ 안했다.

---

마치며

두 세션 모두 너무 특정한 분야에 대한 테크닉을 설명해주는 거라 조금 힘들었음.

 

첫 번째 세션은 금방 끝나기도 했고, 트러블슈팅 사례에 대한 이야기라 그냥 훅 지나갔다.

그런데, 두 번째 세션은 급하게 준비하신 건지 좀 문제가 있었다.

 

알아두면 쓸모있는 AWS Network 아키텍처가 아니잖아요...

 

알아둬도 안쓸 가능성이 높은 AWS Network 아키텍처로 바꿔주세요.

 

이 세션에 대해 정리한 내용을 다시 볼 일이 있을까...?