문제 상황

Spring Cloud Eureka서버의 경우, Discovery서버로 작용한다. 그런데, 연결할 서버를 내부 네트워크가 아닌 외부 네트워크를 사용 할 경우, 정상적으로 매핑이 불가하였다.

특히 EC2의 경우, Elastic 아이피를 적용 했음에도 불구하고, 연결되는 ip는 퍼플릭 주소가 아닌 프라이빗 ipV4 주소로 맵핑이 되었다.

퍼블릭 주소가 아닌 프라이빗주소가 discoveryclient에 매핑이 된다.

이렇게 된다면, 모든 Spring Cloud 서비스가 같은 네트워크에 있다면 문제가 없지만, 물리적으로 다른 네트워크에 있게 되면 심각한 문제를 초래하게 된다.

---

해결책 수집

해결 방안 수립

1. AWS EC2의 Private ip에 접속 할 수 있게 세팅

비록 프라이벳 ipv4주소로 매핑되지만, 이를 aws 설정을 통해 연결이 가능하도록 설정하면 해결이 되리라 기대하였다.

2. Spring Cloud Discovery서버의 맵핑을 직접적으로 연결하도록 세팅

모든 서비스가 자동으로 Spring Cloud Discovery에 연결 되면 좋겠지만, 기본적으로 내부 아이피로 매핑 되므로, 이 부분에 관여 하는 방법으로 해결 할 수 있을것으로 기대하였다.

---

해결방안 결정 및 적용

해결 방안 결정

비교적 쉽게 해결 할 수 있는 방안 1부터 진행 하였다.

해결 방안 적용

1. AWS EC2의 Private ip에 접속 할 수 있게 세팅

EC2 서브넷 → 네트워크 ACL →인바운드 아웃바운드 세팅을 해주었다.

private ip에 접속허용에 실패하여 기존 세팅으로 되돌려 놓았다

이외에도 다양한 시도를 해보았지만, private ip에 접속허용에 실패하였다. 시간이 많다면 해결 못 할 일은 아니라고 생각했지만, 시간적 효율을 생각하여 2번 방안으로 넘어가기로 하였다.

2. Spring Cloud Discovery서버의 맵핑을 직접적으로 연결하도록 세팅

Spring Cloud Eureka를 사용하는 이유는 명백하다. 모든 서버의 연결을 추상화 하여 관리 한다는 장점이 있기 때문이다. 하지만 일일히 서버 주소를 맵핑하는 것은 그 장점이 사라지게 된다. 그 관점에서 최대한 추상화의 개념을 잃지 않고 맵핑 하는 방법을 고안해보았다.

<application.properties>

eureka.instance.hostname=35.79.145.16

원래 이 옵션은 ip주소를 맵핑하는 것이 아니라 hostname을 맵핑하는 옵션이다. 하지만, 수많은 시도 끝에 이렇게 맵핑하면, 실제로 apigate-service에서 이용하는 주소값을 hostname으로 사용 할 수 있음을 알게 되었다. 약간의 편법이라 할 수 있다.

TestController

앞서 말한 최대한 추상화를 하기 위해서, 서버를 실행할때, config값을 github repository에서 가져 올 수 있는 Spring Config를 연동 하였다.

application.properties에 쓰지 않고 서버 실행시, 특정 리포지토리에 있는 config 파일에서 서버를 맵핑 할 수 있게 되었다.

---

결과 반영

이로써, 내부 네트워크 뿐만 아니라 물리적으로 분할 되어있는, 네트워크에서도 하나의 eureka 서버에 연결 할 수 있게 되었다.

Spring Eureka에 정상적으로 맵핑 된 모습을 확인 할 수 있다.