AWS를 이용한 유레카 통신시 에러발생 및 해결방법

유레카 서버와 CIDR 주소 설정으로 사용자 간 통신하기

1. 유레카 서버를 통한 통신 환경의 이해

유레카(Eureka) 서버는 분산 시스템에서 서비스 디스커버리를 제공하는 중요한 구성 요소이다. 서로 다른 사용자가 유레카 서버를 통해 통신하려면 각 사용자의 네트워크 환경과 설정이 제대로 조율되어야 한다. 특히 AWS와 같은 클라우드 환경에서는 CIDR(Classless Inter-Domain Routing) 주소와 이를 기반으로 설정되는 서브넷, 인바운드 및 아웃바운드 규칙이 매우 중요한 역할을 한다.

2. CIDR 주소 충돌의 문제

AWS에서 EC2 인스턴스를 생성할 때, 기본적으로 CIDR 주소 범위가 자동으로 설정된다(Default 주소값 설정). 일반적으로 기본 VPC의 CIDR 주소는 172.31.0.0/16과 같은 디폴트 값으로 할당됩니다. 두 명 이상의 사용자가 AWS에서 서로 다른 VPC에 인스턴스를 생성했을 때, 두 VPC의 CIDR 범위가 같다면 다음과 같은 문제가 발생한다:

• 2-1. 유레카 서버에 요청을 보내는 것은 가능하지만, 응답을 받을 수 없다.
• 2-2. 네트워크 라우팅이 혼동되어 패킷이 정상적으로 전달되지 않는다.
• 2-3. 서버 간의 연결이 불안정하거나 아예 실패하게 된다.

3. 해결 방법: CIDR 주소와 네트워크 설정 조율

이 문제를 해결하기 위해, 서로 통신하려는 사용자들은 AWS 네트워크 설정을 조율해야 한다. 문제를 해결 방법:

3.1 CIDR 주소의 변경

서로 다른 사용자가 각자의 VPC에 대해 고유한 CIDR 범위를 설정해야 한다. CIDR 주소는 VPC 생성 시 설정하거나 기존 VPC를 수정하여 변경할 수 있다. 예를 들어:

• 사용자 A의 CIDR: 192.168.0.0/16
• 사용자 B의 CIDR: 10.0.0.0/16

CIDR 범위가 겹치지 않도록 설정함으로써 네트워크 충돌을 방지할 수 있다.

3.2 서브넷 구성

VPC 내에서 사용하는 서브넷 역시 겹치지 않도록 조정해야 한다. 서브넷은 CIDR 범위를 기반으로 생성되므로, CIDR 설정 이후 서브넷을 재구성하면 된다. 예를 들어:

• 사용자 A의 서브넷: 192.168.1.0/24
• 사용자 B의 서브넷: 10.0.1.0/24

3.3 보안 그룹 및 네트워크 ACL 설정

통신하려는 사용자들 간의 네트워크 트래픽을 허용하기 위해, 보안 그룹과 네트워크 ACL(Access Control List)을 조정해야 한다:

• 인바운드 규칙: 상대방의 IP 주소나 CIDR 범위를 허용.
• 아웃바운드 규칙: 상대방 서버로의 트래픽을 허용.
• 네트워크 ACL: 서브넷 수준에서 접근을 허용하도록 설정.

예를 들어, 사용자 A와 사용자 B가 서로의 EC2 인스턴스에 접근하려면 다음과 같은 규칙을 추가해야 한다:

# 사용자 A의 보안 그룹
인바운드: 사용자 B의 CIDR (10.0.0.0/16) 허용
아웃바운드: 사용자 B의 CIDR (10.0.0.0/16) 허용

# 사용자 B의 보안 그룹
인바운드: 사용자 A의 CIDR (192.168.0.0/16) 허용
아웃바운드: 사용자 A의 CIDR (192.168.0.0/16) 허용
    

4. 결론

유레카 서버를 활용한 사용자 간 통신에서 CIDR 주소 설정은 반드시 필요하다. 네트워크 충돌을 방지하기 위해 CIDR 주소, 서브넷, 보안 그룹 및 네트워크 ACL을 신중하게 설정해야 한다. 위와 같은 과정을 통해 우리는 유레카 서버를 사용하여 서로 다른 사용자 간의 통신을 성공적으로 구축할 수 있었다.