안녕하세요. 이번에 Internal(내부) ELB 생성하고 테스트, 적용하는 과정 중에
어떤 트러블을 겪었는지 적어볼려고 합니다. 해당 트러블로 인해 웹 아키텍처에
대해서 다시 고민해보는 시간을 가졌습니다. 혼자 고민하면서 저만의 결론을
내린 내용을 토대로 글을 작성합니다.


해당 그림에서 제공해주는 용어들 중에서 모르는 사람이 있을 수도 있어 간단하게
설명을 하고자 합니다.
Virtual Private Cloud, 이름 그대로 독립된 가상 Cloud 이다.
VPC는 RFC1918이라는 사설 IP 대역에 맞추어 설계해야함.
VPC의 IP 주소 범위이다. Subnet은 단일 가용영역(Availability Zone= AZ)에 상주함.
CIDR의 주소 범위를 Subnet으로 맛깔나게 표현한 거다.
인터넷에 접근할 수 있냐 없냐로 구분함. 즉 Internet Gateway를 연결했냐 안했냐로 구분하면 됩니다
Internet Gateway는 인터넷과 통신하기 위한 경로이다.
NAT Gateway 의 NAT은 Network Address Translation의 약자이다
패킷의 IP 주소, 포트 등을 변환하는 기술을 의미 함
Private Subnet에서 외부 Public Networ와 통신하기 위해서 사용한다.

해당 그림처럼 Private 인스턴스는 Public IP이 아닌 Private IP만 가지고 있음
ex) Private Subnet에서 Slack 알람 보내기
이 부분은 넘어가겠습니다.
여러 Test 케이스를 할려고 합니다
Public EC2


"use client" // directive for client components
import axios from 'axios';
const MyComponent = () => {
const jaeha = axios.get("http://internal-jaeha-test-1659558992.ap-northeast-2.elb.amazonaws.com/health")
console.log(jaeha)
return <div>Hello</div>

const getData = async () => {
const gg = await fetch("http://internal-jaeha-test-1659558992.ap-northeast-2.elb.amazonaws.com/health")
const jaeha_json = await gg.json();
console.log(jaeha_json)
return <div>jaeasdha</div>
}
export default MyComponent;

Front Code
const fetchPosts = async () => {
const response = await fetch("http://internal-jaeha-test-1659558992.ap-northeast-2.elb.amazonaws.com/health", {
cache: "no-store",
});
return await response.json();
};
const Posts = async () => {
const data = await fetchPosts();
// const respoe = await data.json()
return JSON.stringify(data)
};
export default Posts;



트래픽이 나가는 경로를 중심으로 생각을 해봤다.
해당 경로를 정리해서 보면 잘못된 것이 보인다
잘못된 부분을 정리하자면
Nextjs Client Component
Internal ELB 에선 인터넷에 트래픽을 못 보낸다. 하지만 공용 IP 가 존재하지 않기 떄문에
Response 트래픽을 못 보낸다. 고로 TimeOut이 발생함