인프런 커뮤니티 질문&답변
작성한 질문수
각 애플리케이션에 랜덤포트를 부여하는 이유
작성
·
938
1
안녕하세요!!! 랜덤포트를 부여하는 이점에 대해서 아직도 이해가 잘 안갑니다.ㅜㅜ 마이크로서비스 애플리케이션의 확장성과 랜덤포트를 부여하는게 얼마나 깊은 관계가있나요?? 저는 정해두고 쓰는게 더 편하다고 생각했거든요. 그리고 실무에서도 정말 이렇게 랜덤포트로 사용하나요?
답변 1
1
안녕하세요, 이도원입니다.
랜덤포트의 사용 여부는 마이크로서비스가 독립적으로 사용되는지 LB(로드밸랜서)로 구성되어 사용되는지, 사용시 문제가 되었을 때 복귀해야 하는 구조는 어떻게 되어 있는지 등에 따라 결정하실 수 있습니다. 강의에서 설명 드렸던 랜덤포트(PORT: 0 설저)에 대한 설정은 LB사용을 예시로 보여드리기 위함이었고, 고정으로 설정한 상탱에서 진행하셔도 문제는 없습니다. 다만, Service Discovery에서 등록된 서비스들이 포트 간의 충돌이 발생할 경우 해당 서비스를 우회할 수 있는 포트를 지정하여 새롭게 실행하지 않고, 충돌이 발생한 서비스는 중지 시켜 버리게 됩니다. 포트를 잘 구분하여 서비스들을 배포한다고 했을때는 문제가 없을 수도 있습니다.
그런데, 서비스에서 LB를 사용하도록 되어 있다면, LB에 연결되는 다수의 동일 서비스들은 같은 형태(코드)로 작성되어진 애플리케이션인데, 매번 실행할 때마다 포트를 변경하는 작업을 하기에는 번거로울 수 있습니다. 이때 랜덤포트로 실행하며 임의의 사용가능한 포트가 할당 되고, Service Discovery에 등록될 때는 서비스명으로 사용되어지기 때문에, 여러 개의 서비스가 연결되어 있어도 하나의 서비스명이 요청을 받아 해당 서비스들에 요청처리를 배분해 줄 수 있게 됩니다.
실제로 MSA 형태로 구성된 애플리케이션들은 컨테이너 가상화 형태로 운영되는 경우가 대부분인데, Docker나 Kubernetes에서 컨테이너를 기동할 때는 외부와 연결되기 위한 포트를 랜덤포트로 설정(범위는 지정할 수 있습니다)되어 사용됩니다. 컨테이너 자체는 독립적인 IP를 가지고 있는 VM이라고 보시면 되고, 이 안에서 사용되는 포트는 어떠한 포트로 지정되어 있더라도 상관없이, 컨테이너 외부하고의 연결만 잘 되어 서비스 되는 구조라고 이해하시면 좋을 것 같습니다.
추가 질문 사항 있으시면 글 남겨 주세요.
감사합니다.
안녕하세요.. 랜덤 포트 관련하여 작업중에 궁금한 사항이 있어 찾다 해당 글을 보고 질문드립니다.
서비스별 서버가 다른 곳에 있고, 이에 디스커버리 설정을
prefer-ip-address: true,
id-address: xxx.xxx.xxx
이와 같이 설정하게되면, 요청 시 discovery가 xxx.xxx.xxx:random-port로 IP 를 알려주고, 해당 IP로 요청하게되면, Refuse가 됩니다. 해당 포트를 바인딩해줘야할거같은데, 랜덤 포트라서 어떻게 바인딩을 해야할지 혹은 설정 자체를 이렇게 하면 안되는건지 궁금합니다..
추가로, 로깅이나 메트릭을 가져올 때도 포트가 랜덤포트면 어떻게 처리가 되는지 궁금합니다..
소중한 답변 기다리겠습니다.
감사합니다.
안녕하세요, 이도원입니다.
말씀하신 부분이 Docker 컨테이너로 기동 시 랜덤포트에 대한 부분을 어떻게 매핑하는지에 대한 부분으로 해석되어 관련 질문으로 답변 남겨드립니다.
우선 실행하고자 하는 랜덤포트를 갖고 있는 서비스를 catalog-service라고 가정했을 때, 아래와 같이 랜덤 포트로 지정하셨다면,
catalog-service가 최종적으로 기동이 완료되는 시점에 특정 포트(랜덤)로 포트가 업데이트되어 기동됩니다. 그리고, 이렇게 확정된 IP와 포트 정보가 Service Registry(Eureka)에 등록됩니다. 이 시점에서 사용자는 catalog-service의 IP와 포트 정보를 모르기 때문에, 직접 웹브라우저나 다른 프론트엔드 등에서 서비스를 호출할 수 없을 겁니다. 대신, service-discovery에 catalog-service에 대한 정보를 요청하면, IP와 port 정보를 확인할 수 있기 때문에, 해당 정보를 가지고 서비스를 호출할 수 있습니다. 이 부분은 Eureka 대시보드를 통해서, 현재 등록된 인스턴드 정보 부분에서 catalog-service를 확인해 보시면, 링크를 클릭했을 때 바로 catalog-service 로 이동되는 것과 동일한 방식입니다. 따라서, catalog-service에 대한 정보를 직접적으로 알고 호출하는 것이 아니라, service-discovery에 등록된 정보를 바탕으로 해당 서비스에 통신하는 구조입니다. 예를들어 apigateway를 등록해 놓은 상태에서, apigateway에 라우팅 정보로 lb://catalog-service와 같이 등록해 놓게 되면, 직접적으로 catalog-service로 호출하는 것이 아닌, service-discvoery를 통해 catalog-service를 사용하는 방식이 되기 때문에, catalog-service의 위치를 직접적으로 모른다고 하더라도 사용에 문제는 없습니다. 따라서, 질문하신 부분에 대한 처리는 직접적으로 catalog-service를 호출하는 방식이 아닌 등록 된 catalog-service를 service-discovery로부터 얻고 그 정보를 토대로 이용하는 구조라고 이행하시면 좋을 것 같습니다. 아래 이미지는 직접적으로 catalog-service의 아이피와 포트를 알고 있을 때(또는 Eureka 대시보드에서 catalog-service의 링크를 호출했을 때) 보이는 이미지 입니다.
그리고, 아래는 apigateway-service를 이용하여 호출했을 때 이미지입니다.
apigateway-service와 service-discovery를 이용하여 catalog-service의 위치 정보를 모른다고 하더라도, 애플리케이션의 이름만으로 서비스를 사용하실 수 있습니다.
이렇게 service discovery 역할과 위치정보확인, 등록, 해제, 변경, 네트워크 등의 정보를 사용할 수 있도록 지원해 주는 것이 service mesh입니다. Kubernetes와 같은 경우에는 Istio와 같은 서비스를 연결하여 이러한 부분을 해결하고 있습니다.
감사합니다.
자세한 답변 정말 감사합니다.
답변 주신 내용에 있어 궁금한 사항이 남아 있어 한번 더 문의드립니다.
답변 주신 것과 같이 로컬에서 테스트했을 경우 저도 동일하게 문제가 없었습니다. 환경이 달라 문제가 된 것으로 파악하여, 저의 환경 및 테스트 구성에 대해 자세히 말씀 드리면,
A server (10.254.0.1) - Gateway-service , B server (10.254.0.2) - User-service
로 구성하여 테스트 진행하였으며,
/api/user-service/users 와 같이 gateway에 요청을 하게 되면, discovery에서 랜덤포트와 함께 로컬 주소로 리턴을 해주게 되는 것을 로그를 통해 확인하였습니다.
ex) 127.0.0.0:45234(random port)
이와 같이 리턴 했을 경우 B server로 가지 못하고 A server로 내에서 찾게 되찾게 되었습니다. 이로 인해
prefer-ip-address: true,
id-address: 10.254.0.2
설정을 했고, discovery에서 10.254.0.2 리턴을 해주게 됐습니다. 이로 인해 B-server로 정상적으로 갔으나, port는 랜덤포트이기 때문에 B-server에서의 설정이 되지 않아 refuse가 된 것으로 예측을 했습니다.
이러한 환경에서의 질문을 드렸었습니다.
답변 주신 것에 감사하면 한번 표하며,,,, 한번 더 질문올립니다.
감사합니다.
ㅜㅜ답변 정성스럽게 남겨주셔서 정말 감동입니다ㅠㅠ감사합니다!!이해도 너무 잘되었습니다 ㅎㅎ