[MicroService] MSA의 이해(컨테이너 오케스트레이션, API 게이트웨이 패턴, 서비스 디스커버리 패턴, 플랫폼패턴) 2장

◆ MSA 구성 요소 및 MSA 패턴

▶ 인프라 구성 요소

     ● 컨테이너 오케스트레이션

          ⊙ 컨테이너 기술을 선택했다면 컨테이너를 관리하기 위한 기술 또한 필요

          ⊙ 컨테이너가 많아지면 그에 따라 컨테이너의 자동 배치 및 복제, 장애 복구, 확장 및 축소, 컨테이너 간 통신, 로드 밸런싱 등의 컨테이너 관리를 위한 기능이 필요한데 이러한 기술을 컨테이너 오케스트레이션(Container Orchestration)이라 함

          ⊙ 컨테이너 오케스트레이션 도구로는 도커 스윔(Docker Swarm), 아파치 메소스(Apache Mesos) 등이 있으며 최근에는 구글이 자사의 도커 컨테이너 관리 노하우를 CNCF 재단에 제공해서 공개한 쿠버네티스(Kubernetes8가 큰 인기를 끌고 있는데 쿠버네티스를 이용하면 손쉽게 사설 컨테이너 플랫폼 환경을 구축할 수 있기 때문

          ⊙ 쿠버네티스 대시보드

          ⊙ 쿠버네티스나 AWS 같은 플랫폼 사업자가 제공하는 대부분의 PaaS UI는 대부분 이와 유사한 시각적인 대시보드를 제공하는데 이곳에서 컨테이너 배포의 기본 단위에 해당하는 파드(Pod), 디플로이먼트(Deployment), 레플리카셋(Replica Sets) 정보를 확인하고 설정할 수 있음

          ⊙ 쿠버네티스는 다음과 같은 주요 기능을 제공

              → 자동화된 자원 배정(Automatic binpacking): 각 컨테이너가 필요로 하는 CPU와 메모리를 쿠버네티스에 요청하면 컨테이너를 노드에 맞춰 자동으로 배치

              → 셀프 치유(Self-healing): 컨테이너의 이상 유무를 점검(health check)해서 실패한 경우 자동으로 교체하고 재스케줄링

              → 수평 확장(Horizontal scaling): CPU 및 메모리 사용량을 일정량을 초과하면 자동으로 확장

 

          ⊙ 쿠버네티스는 애플리케이션으로 구현 가능한 일부 Micro Service 운영/관리 패턴을 자체적으로 내장하고 있기도 하기 때문에 이러한 대중성과 인기에 힘입어 최근에는 AWS, 애저, Pivotal, IBM 등 자체적인 컨테이너 기반의 PaaS 서비스를 제공하는 CSP 사업자들도 별도로 쿠버네티스 기반의 컨테이너 서비스를 제공

 

     ●  그 밖의 다양한 클라우드 인프라 서비스

          ⊙ AWS, Azure, GCP 등의 CSP 사업자 모두 기존의 물리 서버, 네트워크. 스토리지, DB를 대체 할 다양한 가상 서버, 가상 네트워크 및 가상 스토리지, 가상 DB 등을 제공하고 있으며 이들의 연계는 퍼블릭/프라이빗 간, 가상/물리 레거시 시스템 간에 모두 가능

          ⊙ 클라우드 인프라 선택지는 다양

          ⊙ 애플리케이션 형태를 MSA가 아닌 모노리스 시스템으로 구축하기 위해서는 가상 머신 클라우드 제품군인 AWS EC2, Azure VM을 사용할 수도 있고 모노리스 시스템이 아니라 MSA 시스템으로 간다고 해도 쿠버네티스는 아니지만 동일하게 컨테이너 기반인 AWS Elastic Beanstalk나 Elastic Container Service(ECS), Azure Web App, Google App Engine 등의 PaaS를 고려할 수도 있음

          ⊙ 처음에 클라우드 서비스 제품군을 접하면 각 벤더가 위와 같이 매우 다양한 제품군을 제공하기 때문에 선택하기가 어렵지만 이러한 서비스들을 클라우드 서비스 유형(laaS. PaaS, CaaS)으로 묶어서 보면 단순해짐

          ⊙ 서비스 유형별 대표적인 클라우드 서비스

              → laaS(Infrastructure as a Service): 가상 머신, 스토리지, 네트워크 같은 인프라를 필요한 만큼 적시에 제공하는 서비스로서 사용자는 이러한 인프라를 이용해 개발 환경을 구성한 후 애플리케이션을 배포 - AWS EC2(Elastic Compute Cloud), GCP Compute Engine, Azure VM

              → CaaS(Container as a Service): 컨테이너 기반 가상화를 사용해 컨테이너를 업로드, 구성, 실행. 확장, 중지할 수 있는 서비스로 애플리케이션을 바로 구동할 수 있는 환경을 제공한다는 점에서 PaaS와 유사 하지만 다른 환경에도 이식 가능한 컨테이너 기반 가상화를 제공한다는 점이 다름 - 마이크로소프트의 Azure Kubernetes Service(AKS), 아마존의 Elastic Kubernetes Service(EKS), Google Kubernetes Engine(GKE), AWS ECS

              → PaaS(Platform as a Service): 복잡함 없이 애플리케이션을 곧바로 개발, 실행, 관리할 수 있는 플랫폼 환경을 서비스 형태로 제공하는 것으로 laaS 위에 실제로 애플리케이션이 실행될 수 있는 미들웨어나 런타임까지 탑재된 환경 - Azure Web App, Google App Engine, Cloud Foundry, Heroku, AWS Elastic Beanstalk

 

---

▶  Micro Service 운영과 관리를 위한 플랫폼 패턴

     ● 애플리케이션이 실제로 구동되는 인프라 환경을 결정했다면 그 다음으로 선택한 인프라 환경 위에서 애플리케이션을 운영하고 관리하는 환경을 구성하는 방법을 생각해야 하는데 특히 애플리케이션을 빌드하고 인프라에 배포할 수 있는 환경이 중요

     ● Micro Service의 개념에서 마틴 파울러도 강조했지만 MSA 시스템을 구성하는 수많은 Micro Service를 하나하나 수동으로 빌드하고 배포한다면 비효율적이고 큰 혼란을 가져올 것이기 때문에 이러한 과정을 하나 하나 통제하고 자동화하는 것이 중요해졌음

     ● 개발 지원 환경: 데브옵스 인프라 구성

          ⊙ 그래서 필요한 요소가 Micro Service를 빌드하고 테스트한 뒤 배포할 수 있게 도와주는 개발 지원 환경인 데브옵스(DevOps) 환경

          ⊙ 데브옵스는 앞에서 언급한 것처럼 개발과 운영이 분리되지 않은 개발 및 운영을 병행할 수 있는 조직 또는 그 문화를 일컫는데 여기서는 협의의 의미로 개발과 운영을 병행 가능하게끔 높은 품질로 소프트웨어를 빠르게 개발하도록 지원하는 빌드, 테스트, 배포를 위한 자동화 환경

          ⊙ 수동 빌드 및 배포 과정

              → 개발자는 개발 환경에서 애플리케이션을 완성한 후 컴파일하고 수동으로 테스트한 후 발생한 오류를 수정 한 뒤 스테이징 환경에 배포

              → 개발자는 운영 환경에 배포하기 전에 스테이징 환경에서 다시 수동으로 테스트한 후 오류가 발생하면 첫 환경인 개발 환경으로 돌아가 오류를 수정한 뒤 스테이징 환경에서 다시 테스트를 수행

              → 이러한 과정이 무사히 끝나면 배포 승인을 받고 승인 완료 후 배포 담당자가 애플리케이션을 운영 환경에 배포

          ⊙ 수동 빌드/배포 과정에는 정말 많은 시간이 소요되며 마지막에 배포를 처리하는 배포 담당자는 보통 시스템 사용률이 낮은 야간에 시스템을 장시간 멈추고 배포 작업을 진행하는 경우가 많음

          ⊙ 당연히 이러한 환경에서는 비즈니스 민첩성이 높을 수 없기 때문에 이 같은 활동을 자동화할 필요가 생기는데 특히 여러 개의 Micro Service를 배포해야 하는 환경에서는 배포가 잦을 수밖에 없기 때문에 자동화가 절실

          ⊙ 자동화된 빌드나 배포 작업을 보통 CI/CD 라고 하며 여기서 CI는 지속적 통합(Continuous Integration)을 가리키는데 원래 지속적 통합은 애자일 방법론 중 켄트 벡(Kent Back)이 만든 XP(eXtreme Programming)의 주요 프랙티스로 시작됐으며 오랜 시간이 걸리는 빌드를 매일 자동화해서 수행한다면 개발 생산성이나 소스 코드 품질이 높아진다는 경험에서 출발

          ⊙ 지속적 통합/배포가 진행되는 과정

              → 작성한 소스 코드와 그것을 테스트한 테스트 코드를 형상관리 시스템에 전송(Push)

              → 빌드 도구에서 형상관리 서버의 코드를 가져와(Pull) 통합한 다음 자동으로 빌드하고 테스트 코드를 실행해 테스트를 수행

              → 테스트 수행 결과를 리포트 문서로 기록하고 빌드된 소스코드를 스테이징 환경에 자동으로 배포

              → 테스터가 스테이징 환경에서 테스트를 수행하거나 또는 빌드 및 단위 테스트 결과를 개발자가 혹인하고 문제가 있다면 즉시 소스코드를 수정

          ⊙ 자동으로 통합 및 테스트하고 그 결과를 리포트로 기록하는 활동을 CI라 하고 실행 환경에 내보내는 활동이 CD

          ⊙ CD는 지속적 제공(Continuous Delivery) 및 지속적 배포(Continuous Deployment)를 모두 포함

          ⊙ 지속적 제공은 빌드된 소스코드의 실행 파일을 실행 환경에 반영하기 전 단계까지 진행하는 방식이므로 아직 실행 환경에 배포되지 않았고 실행 환경에 반영하기 위해서는 승인 및 배포 담당자의 허가를 받아야 하며 배포도 수동으로 처리하는데 다소 엄격한 배포 절차를 밟는다고 할 수 있는 반면 지속적 배포는 소스코드 저장소에서 빌드한 소스코드의 실행 파일을 실행 환경까지 자동으로 배포하는 방식을 말하며 모든 영역을 자동화하는 것에 해당

          ⊙ 더 넓은 의미로 살펴보면 지속적 제공은 비즈니스 속도에 민첩하게 대응하기 위해 소프트웨어를 짧은 주기로 빈번하게 빌드, 테스트, 시장에 출시하는 모든 활동을 의미하기도 함

          ⊙ Continuous Delivery와 Continuous Deployment

          ⊙ 빌드/배포 파이프라인 설계

              →  빌드/배포되는 과정 동안 수행해야 할 태스크가 정의된 것을 빌드/배포 파이프라인이라고 하는데 빌드/배포 파이프라인은 통합 및 배포까지 이어지는 일련의 프로세스를 하나로 연계해서 자동화하고 시각화된 절차로 구축하는 것인데 어떤 단계를 거치고, 어떤 도구로 그 단계를 구성할지 결정해야 함

              →  클라우드 환경이 활성화되기 이전에는 배포 환경으로 베어 메탈 하드웨어를 사용하는 경우가 있어 일부 과정에서 수동으로 처리하는 절차가 있었지만 최근 클라우드 같은 가상 환경이 대중 화되면서 완전한 자동화가 가능해졌는데 인프라 구성을 마치 프로그래밍하는 것처럼 처리하고 소수의 인원으로 많은 컨테이너 배포 처리를 할 수 있게 됐는데 이를 가리켜 Infrastructure as Code라 함

              → Infrastructure as Code를 이용하면 배포 파이프라인 절차를 완벽하게 자동화 할 수 있으며 대규모 인프라 관리를 수행할 수 있고 코드이기 때문에 쉽게 공유 및 재사용이 가능

              → 형상관리 리포지토리에서 소스코드를 가져와 빌드해서 실행 파일을 만드는 작업, 실행 파일을 실행 환경에 배 포하는 작업, 그리고 이런 작업들을 통제하고 연결해서 전 작업이 성공하면 다음 작업이 자동으로 수행되게 하는 연계 자동화 작업으로 나눌 수 있는데 이를 모두 코드로 정의 및 설정할 수 있고 이를 지원하기 위한 여러 오픈소스나 솔루션을 이용할 수 있음

              → 모든 과정을 자동화하는 과정은 매우 힘든 작업이기 때문에 일부는 자동화, 일부는 수동으로 처리할 수도 있으며 어떤 애플리케이션은 성격에 따라 이 같은 전체적인 자동화가 필요할 수도 있고 아닐 수도 있는데 이에 맞게 빌드/배포 파이프라인도 애플리케이션마다 다르게 설정할 수 있음

              → MSA 시스템도 마찬가지인데 Micro Service는 각각 별도의 리포지토리를 가지고 있고 독립적으로 수정 및 빌드하고 배포해야 하므로 빌드/배포 파이프라인도 Micro Service 별로 별도로 설계

     ● Micro Service 생태계와 운영 관리 요소의 탄생

          ⊙ Micro Service 생태계가 어떻게 발전 했는지를 나타내는 발전 흐름

          ⊙ CI의 개념이 켄트 벡에 의해 XP 방법론의 프랙티스로 1999년에 소개되고 켄 트 벡, 스크럼의 켄 슈와버, 마틴 파울러 등 여러 소프트웨어 업계의 구루들이 모여 2001년에 애자일 선언을 했는데 그때부터 소프트웨어 업계가 장기적인 계획이나 단계적 프로세스 대신 빠 른 실패와 피드백을 기반으로 하는 실용적인 실천법을 선호하게 됨

          ⊙ 한편 다른 쪽에서는 아마존이 2006년에 laaS 서비스인 EC2를 발표하며 최초로 클라우드 사업을 시작했는데 그 즈음 DVD 대여 서비스로 출발했던 넷플릭스가 스트리밍 사업을 시작했는데 얼마 후에 스트리밍 데이터베이스의 스토리지가 손실되는 대규모 서비스 장애를 겪게 되었는데 이를 계기로 넷플릭스는 한 덩어리의 모노리스 시스템에서 Micro Service 기반의 시스템으로 전환하는 작업을 시작했는데 이때 선택한 것이 AWS의 EC2

          ⊙ 클라우드 기반에서 Micro Service로 전환하는 과정은 쉽지 않았는데 우선 애플리케이션이 한 덩어리였을 때 발생하지 않았던 여러 문제점이 불거졌으며 전체 서비스를 여러 개의 서비스로 분산 구성했을 때 한 서비스에서 발생한 장애가 다른 서비스로 전파된다거나 여러 서비스에 분산된 로그를 관리해야 하는 불편함, 서비스 하나가 동작하지 않아 시스템의 일부 기능이 동작하지 않아도 그것을 알아채지 못하고 장애가 방치되는 문제들이 발생

          ⊙ 넷플릭스는 이러한 문제의 해결법으로 다양한 서비스와 도구를 개발하게 되었고 넷플릭스의 기술력에 의구심을 갖는 사람들에게 보란듯이 오픈소스로 공개했는데 그것이 바로 넷플릭스 OSS

          ⊙ 넷플릭스 OSS에는 여러 Micro Service 간의 라우팅과 로드 밸런싱을 위한 줄 (Zuul)과 리본(Ribbon), 모니터링을 위한 히스트릭스(Hystrix), 서비스 등록을 위한 유레카(Eureka) 등이 포함돼 있는데 이러한 넷플릭스의 공유 활동이 Micro Service 기술을 발전시키는 시초가 됐는데 이를 기반으로 주요 Micro Service 운영 관리를 위한 문제 영역들이 활발히 논의되고 이를 해결한 기술들이 공유되고 자연스럽게 개발자 간 협업 및 오픈소스에 대한 기여가 이뤄졌고 이로 인해 업계가 함께 발전하게 됨

          ⊙ 이후 2013년에는 가장 유명한 컨테이너 기술인 도커가 세상에 등장했고 또한 이쯤에 스프링 진영에서는 Micro Service를 쉽게 개발할 수 있는 프레임워크인 스프링 부트를 발표하고 최근에는 컨테이너 오케스트레이션 기술인 구글의 쿠버네티스가 등장했는데 Micro Service의 개념을 마틴 파울러가 정리한 시점이 바로 이 시점

          ⊙ 간단히 정리하면 AWS의 클라우드 환경, 도커 컨테이너, 넷플릭스가 공유한 오픈소스, 스프링 프레임워크, 구글의 쿠버네티스 같은 것들이 Micro Service 생태계의 발전을 계속 이끌었고, 이러한 과정을 거쳐 Micro Service 아키텍처의 주요 문제 영역들이 논의되고 그에 대한 해결책이 제시돼 왔음을 알 수 있음

     ● Micro Service 생태계와 운영 관리 요소의 탄생

          ⊙ 넷플릭스는 이러한 문제의 해결법으로 다양한 서비스와 도구를 개발하게 되었고 넷플릭스의 기술력에 의구심을 갖는 사람들에게 보란듯이 오픈소스로 공개했는데 그것이 바로 넷플릭스 OSS

          ⊙ 넷플릭스 OSS에는 여러 Micro Service 간의 라우팅과 로드 밸런싱을 위한 줄 (Zuul)과 리본(Ribbon), 모니터링을 위한 히스트릭스(Hystrix), 서비스 등록을 위한 유레카(Eureka) 등이 포함돼 있는데 이러한 넷플릭스의 공유 활동이 Micro Service 기술을 발전시키는 시초가 됐는데 이를 기반으로 주요 Micro Service 운영 관리를 위한 문제 영역들이 활발히 논의되고 이를 해결한 기술들이 공유되고 자연스럽게 개발자 간 협업 및 오픈소스에 대한 기여가 이뤄졌고 이로 인해 업계가 함께 발전하게 됨

          ⊙ 이후 2013년에는 가장 유명한 컨테이너 기술인 도커가 세상에 등장했고 또한 이쯤에 스프링 진영에서는 Micro Service를 쉽게 개발할 수 있는 프레임워크인 스프링 부트를 발표하고 최근에는 컨테이너 오케스트레이션 기술인 구글의 쿠버네티스가 등장했는데 Micro Service의 개념을 마틴 파울러가 정리한 시점이 바로 이 시점

          ⊙ 간단히 정리하면 AWS의 클라우드 환경, 도커 컨테이너, 넷플릭스가 공유한 오픈소스, 스프링 프레임워크, 구글의 쿠버네티스 같은 것들이 Micro Service 생태계의 발전을 계속 이끌었고, 이러한 과정을 거쳐 Micro Service 아키텍처의 주요 문제 영역들이 논의되고 그에 대한 해결책이 제시돼 왔음을 알 수 있음

     ● 경험으로 획득한 지혜: Micro Service 관리/운영 패턴

          ⊙ Micro Service 구축 시 발생하는 문제는 주로 시스템을 여러 개의 서비스로 구성하기 때문에 발생하는 문제로 넷플릭스가 이 문제를 해결하는 데 크게 기여했는데 넷플릭스 OSS는 넷플릭스가 Micro Service를 개발하고 운영하면서 생긴 노하우를 다른 사람들도 쉽게 사용할 수 있도록 공유한 오픈소스

          ⊙ Micro Service 생태계에 크게 도움이 됐고 특히 Micro Service 관리와 운영을 지원하는 전형적인 Micro Service 애플리케이션 패턴으로 자리 잡음

          ⊙ API 게이트웨이, 서비스 디스커버리, 모니터링, 트레이싱 등이 다수의 Micro Service를 관리 및 운영하기 위한 플랫폼 패턴으로서 넷플릭스에서 소스를 공개하고 나서 패턴으로 정착되고 나중에 이러한 패턴을 적용한 다른 여러 도구와 오픈소스들이 생겨나는 밑거름으로 작용

          ⊙ 넷플릭스 OSS를 더 쉽게 쓸 수 있도록 스프링 진영의 피보탈에서는 기존의 스프링 부트 프레임워크에서 잘 돌아갈 수 있도록 넷플릭스 OSS 모듈들을 스프링 프레임워크로 감싸서 스프링 클라우드(Spring Cloud)19라는 명칭으로 발표했는데 이를 통해 스프링 부트와 스프링 클라우드는 Micro Service를 개발하기 위한 가장 대중적인 기본 프레임워크로 자리매김

          ⊙ 스프링 부트와 스프링 클라우드를 이용하면 Micro Service 애플리케이션의 운영 환경을 쉽게 구축 할 수 있음

   

     ● 스프링 클라우드: 스프링 부트 + 넷플릭스 OSS

          ⊙ 스프링 클라우드는 스프링 프레임워크를 개발하고 있는 피보탈에서 넷플릭스가 공개한 줄, 유레카, 히스트릭스, 리본 등의 넷플릭스 오픈소스를 스프링 부트 프레임워크 기반으로 사용하기 쉽게 통합한 것

          ⊙ 스프링 클라우드를 기반으로 한 아키텍쳐

          ⊙ 데브옵스 환경과 스프링 클라우드 서비스가 있고 그것을 기반으로 업무 처리 Micro Service가 운용

          ⊙ 비니지스를 구현한 Micro Service 와 스프링 클라우드 서비스의 연계 흐름

              → 모든 Micro Service(스프링 클라우드 서비스를 포함한)는 인프라에 종속되지 않도록 데이터베이스, 파일 등에 저장된 환경 설정 정보를 형상관리 시스템에 연계된 Config 서비스에서 가져와 설정 정보를 주입한 후 클라우드 인프라의 개별 인스턴스로 로딩

              → 로딩과 동시에 서비스 레지스트리에 자신의 서비스명과 클라우드 인프라부터 할당받은 물리 주소를 매핑 해서 등록

              → 클라이언트가 API 게이트웨이를 통해 Micro Service에 접근하고 이때 API 게이트웨이는 적절한 라우팅 및 부하 관리를 위한 로드 밸런싱을 수행

              → API 게이트웨이에서 클라이언트가 Micro Service에 접근하기 위한 주소를 알기 위해 서비스 레지스트리 검색을 통해 서비스의 위치를 가져옴

              → API 게이트웨이는 클라이언트가 각 서비스에 접근할 수 있는 권한이 있는지 권한 서비스 와 연계 해 인증/인가 처리를 수행

              → 모든 Micro Service 간의 호출 흐름은 모니터링 서비스 와 추적 서비스에 의해 모니터링되고 추적

 

     ●  다양한 서비스의 등록 및 탐색을 위한 서비스 레지스트리, 서비스 디스커버리 패턴

          ⊙ Front End 클라이언트가 여러 개의 Back End Micro Service를 어떻게 호출하고 스케일 아웃을 통해 인스턴스가 여러 개로 복제된 경우 어떻게 부하를 적절히 분한 할 까 하는 것들을 위한 패턴이 서비스 디스커버리(Service Discovery) 패턴

          ⊙ 클라이언트가 여러 개의 Micro Service를 호출하기 위해서는 최적 경로를 찾아주는 라우팅 기능과 적절한 부하 분산을 위한 로드 밸런싱 기능이 제공돼야 하는데 넷플릭스의 OSS로 예를 들면 라우팅 기능은 줄(Zuiil)이 로드 밸런싱은 리본(Ribbon)이 담당

          ⊙ 라우터는 최적 경로를 탐색하기 위해 서비스 명칭에 해당하는 IP 주소를 알아야 하는데 이러한 라우팅 정보를 클라이언트가 가지고 있으면 클라우드 환경에서 동적으로 변경되는 백 엔드의 유동 IP 정보를 매번 전송받아 변경해야 하기 때문에 제3의 공간에서 이러한 정보를 관리 하는 것이 좋은데 Back End Micro Service 서비스의 명칭과 유동적인 IP 정보를 매핑해서 보관할 저장소가 필요한데 넷플릭스 OSS의 유레카(Eureka)가 그 기능을 담당하고. 이러한 패턴을 서비스 레지스트리 패턴이라 함

          ⊙ 각 서비스 인스턴스가 로딩될 때 자신의 서비스 이름과 할당된 IP 주소를 레지스 트리 서비스에 등록한 다음 클라이언트가 해당 서비스명을 호출할 때 라우터가 레지스트리 서비스를 검색해 해당 서비스의 이름과 매핑된 IP 정보를 확인한 후 호출

          ⊙ 레지스트리 서비스는 모든 Micro Service의 인스턴스의 주소를 알고 있는 서비스 매핑 저장소가 되는데 모든 Micro Service가 처음 기동할 때 자신의 위치 정보를 저장하고 서비스가 종료될 때 위치 정보가 삭제됨

          ⊙ 서비스 레지스트리에는 업무 처리를 위한 Micro Service 뿐만 아니라 관리와 운영을 위한 기반 서비스의 주소도 함께 보관하는데 예를 들면, Config 서비스, 모니터 링 서비스, 추적 서비스도 모두 이름을 가지고 있기 때문에 주소를 가지고 있어야 함

          ⊙ 스프링 유레카로 레지스트리 서비스를 구현한 경우 서비스 이름 과 IP 포트 정보가 매핑된 것을 확인할 수 있음

          ⊙ 특히 다수의 인스턴스가 하나의 서비스 이름으로 등록될 때 다수의 IP 주소와 포트 정보가 매핑되고 라우터는 이 정보를 질의해서 로드 밸런싱도 할 수 있음

          ⊙ 이 패턴을 다른 솔루션에서도 제공하는데 쿠버네티스의 경우 이 같은 서비스 레지스트리, 디스커버리 기능을 자체 기능인 쿠버네티스 DNS 및 서비스(Kubernetes Service)로 제공

 

     ●  서비스 단일 진입을 위한 API 게이트웨이 패턴

          ⊙ 여러 클라이언트가 여러 개의 서버 서비스를 각각 호출하게 된다면 매우 복잡한 호출 관계가 만들어질 것인데 이러한 복잡성을 통제하기 위한 방법이 필요

          ⊙ 한 가지 해결책은 API 게이트웨이(Gateway)

          ⊙ 다양한 클라이언트가 다양한 서비스에 접근하기 위해서는 단일 진입점을 만들어 놓으면 여러모로 효율적

          ⊙ 다른 유형의 클라이언트에게 서로 다른 API 조합을 제공할 수도 있고 각 서비스에 접근할 때 필요한 인증/인가 기능을 한 번에 처리할 수도 있으며 정상적으로 동작하던 서비스에 문제가 생겨 서비스 요청에 대한 응답 지연이 발생하면 정상적인 다른 서비스로 요청 경로를 변경하는 기능이 작동되게 할 수도 있음

          ⊙ 이러한 서비스 흐름 제어를 위한 서비스 라우팅 기능은 L4 같은 하드웨어 장비로 구현할 수도 있고 소프트웨어로 구현할 수도 있는데 소프트웨어로 구현할 경우 API 게이트웨이가 애플리케이션 레벨의 라우팅 기능을 수행하며 또한 여러 인스턴스로 부하를 분산하는 로드 밸런싱도 수행하고 라우팅 시 필터를 둬서 라우팅 전과 후에 각각 수행되는 선행 처리와 후행 처리, 에러 처리 등을 손쉽게 구현할 수 있음

          ⊙ API 게이트웨이는 다른 서비스와 연계해서 다음과 같은 기능을 제공

              → 레지스트리 서비스와 연계한 동적 라우팅, 로드 밸런싱

              → 보안: 권한 서비스와 연계한 인증/인가

              → 로그 집계 서비스와 연계한 로깅 - API 소비자 정보, 요청/응답 데이터

              → 메트릭(Metrics) - 에러율, 평균/최고 지연시간, 호출 빈도 등

              → 트레이싱 서비스와 연계한 서비스 추적 - 트래킹 ID 기록

              → 모니터링 서비스와 연계한 장애 격리(서킷 브레이커 패턴)

          ⊙ 이러한 API 게이트웨이 패턴은 스프링 클라우드의 스프링 API 게이트웨이 서비스(Spring API Gateway Service)라는 제품으로 구현할 수 있는데 스프링 게이트웨이 서비스는 스프링 웹사이트(spring.io)에서 내려받아 간단한 스프링 애너테이션(Annotation – 자바 코드에 메타 데이터 형태의 주석을 달아 컴파일 혹은 런타임 시 해석되게 하는 기법으로 코딩 양을 줄이고 기술 설정 등을 추상화해서 코드 복잡도를 줄이는 효과) 설정만으로 손쉽게 적용할 수 있음

          ⊙ 다른 클라우드 플랫폼에서도 이러한 API 게이트웨이 패턴을 지원하는데 쿠버네티스의 경우 자체 기능인 쿠버네티스 서비스(Kubernetes Service)와 인그레스 리소스(ingress resources)로 제공

          ⊙ API 게이트웨이는 Front End가 Back End를 호출할 때 필요하다고 했는데 그뿐만 아니라 외부 레거시 시스템과 단일 지점에서 서로 다른 형태의 API를 연계하는 용도로도 사용되기도 함

---

다음장에서는 BFF 패턴에서 부터 이어서 포스팅하도록 하겠다 참고하도록하자.

https://joylucky7.tistory.com/52