인프런 커뮤니티 질문&답변

안녕하세요, 이도원입니다.

서비스 디스커버리의 역할은 레지스트리 역할도 포함하면서, 애플리케이션을 구성하는 서비스의 위치 검색을 하도록 도와주는 것입니다. 서비스들 간의 통신에 포트 바인딩 정보가 필요하다는 것은 호스트명 또는 IP 주소를 직접 사용하게 되는 경우일텐데, 서비스 디스커버리에 등록 된 서비스들은 서비스명(Eureka의 경우 instance-id)과 자신들의 실제 위치를 등록합니다. 따라서, 다른 서비스들이 사용할때는 실제 위치(IP:PORT) 보다는 서비스명으로 사용하게 되며, 서비스명으로 호출이 되면, 로드 밸런서에 등록된 서비스들 중, 사용이 가능한 서비스가 요청 처리를 하게 됩니다. 말씀하신대로 Eureka와 같은 애플리케이션의 서비스 디스커버리에 등록 된 서비스들을 호출할 때, http 프로토콜을 이용하여 호출하게 되면, 서비스들의 실제 IP:PORT 정보가 필요하지만, lb 프로토콜을 이용하게 되면, 서비스명으로 호출되어, 등록 된 여러 서비스 인스턴스 중 하나가 라운드로빈 방식에 의해 실행되게 됩니다. 따라서, 애플리케이션 명으로 서비스간 호출이 이뤄진다면, 포트 바인딩 처리를 호출하는 측에서 별도로 할 필요가 없습니다.

추가로, 서비스 디스커버리 역시 단일 에러 포인트를 만들수 있기 때문에, 1개의 서버로 구성하기 보다는 HA 구성을 할 수 있도록, 2개 3개 확장해서 구현하시는 것이 좋습니다.
추가 질문 사항이 있으시면 언제든지 글 남겨 주세요.

감사합니다.

안녕하세요, 인프런 AI 인턴입니다. 램쥐뱅님.

서비스 디스커버리에 대한 질문을 주셔서 감사합니다. MSA(Microservices Architecture)에 대한 이해에 중심이 되는 부분이죠. 서비스 디스커버리는 MSA 환경에서 각 서비스가 동적으로 발견될 수 있도록 돕는 핵심 요소입니다.

1. 서비스 디스커버리 개요: Spring Cloud에서는 Eureka와 같은 서비스 디스커버리 도구를 사용하여 서비스가 자동으로 등록되고 검색될 수 있도록 합니다. 각 서비스는 자체적으로 Eureka에 자신을 등록하며, 다른 서비스는 이를 통해 필요한 서비스를 찾아 호출합니다.

2. gRPC와 서비스 디스커버리: gRPC 서비스를 사용할 때도 동일한 방식으로 서비스 디스커버리를 이용할 수 있습니다. gRPC 서버가 Eureka와 같은 서비스 레지스트리에 자신을 등록하고, 클라이언트는 이를 통해 서비스를 발견하여 포트와 호스트 정보를 얻어옵니다. 이를 통해 웹과 gRPC 통신 모두 필요할 때 유연하게 접근할 수 있습니다.

3. 자동화된 구성: 포트 바인딩과 같은 설정은 보통 서비스 시작 시 동적으로 할당되며 이 정보는 서비스 디스커버리가 관리해 줍니다. 특히, Kubernetes와 같은 플랫폼을 사용한다면, 서비스 엔드포인트와 포트는 클러스터 환경에서 투명하게 관리됩니다.

4. 어플리케이션 레벨에서의 서비스 디스커버리 활용: 플랫폼이 아닌 어플리케이션 레벨에서 디스커버리를 할 경우에는 보통 다음과 같은 방식으로 구현합니다:

   • Spring Cloud Netflix Eureka: Java 어플리케이션에서 가장 널리 사용되는 방법 중 하나입니다.
     
   • Consul, Zookeeper: 다른 언어 또는 다양한 환경에서 사용할 수 있는 서비스 디스커버리 도구입니다.
     

각 포트와 서비스는 Eureka나 다른 서비스 등록 서비스에 의해 관리되므로 개발자는 포트나 호스트에 대한 세부사항보다는 비즈니스 로직에 집중할 수 있습니다.

관련된 질문들 예제를 보시면 추가적인 이해가 도움이 될 수 있습니다:

• “안녕하세요! 질문이 있습니다.!”
  
• “http client 및 아키텍처에 대한 질문입니다”
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.