JPA는 Java Persistence API의 약자로, RDB와 Java Objects 간 데이터 접근, 관리, 지속성에 대한 명세라고 생각하면 된다.
좀 더 간단하게는 Relational Database와 Java application이 상호작용하게 도움을 주는 녀석이라고 생각하자.
JPA의 핵심은 다음과 같다.
1. Object-Relational Mapping (ORM): JPA는 자바 오브젝트들과 데이터베이스 테이블을 양방향으로 매핑해 주는 방법을 제공한다. 이는 개발자들에게 코드상에서 자바 오브젝트들을 가지고 데이터베이스의 데이터들을 핸들링할 수 있게 한다.
2. Entity Classes: JPA는 엔티티 클래스를 정의할 수 있게 해주는데 엔티티 클래스라 함은 데이터베이스에 저장하고 싶은 데이터들을 또는 칼럼을 나타낸다. 이런 클래스들은 일반적으로 JPA 어노테이션들을 사용하여 데이터베이스를 구체화한다. (예: @Table(name = "users"), @Entity 등)
3. EntityManager: 엔티티 매니저는 JPA에서 핵심이 되는 인터페이스인데, 엔티티들을 관리하는데 사용된다. EntityManager는 CRUD에 대한 메서드들을 제공하며 JPQL(Java Persistence Query Language)를 사용해서 데이터베이스에 대한 쿼리를 수행할 수도 있다. 이 EntityManager는 하나의 트랜잭션에 하나가 쓰이게 된다. 즉, 고객의 요청에 의해 어떤 데이터베이스에 대한 작업을 하기 위해 트랜잭션이 시작된 후 모든 데이터베이스에 대한 작업이 끝나면 트랜잭션을 커밋하면 데이터베이스에 작업이 반영된다. 그 후 엔티티 매니저는 닫혀야한다.
4. JPQL(Java Persistence Query Language): JPQL은 SQL과 유사하나, JPA 엔티티와 이용될 수 있도록 설계되었다. JPQL을 사용해서 객체지향 방식으로 데이터베이스 쿼리를 수행할 수 있고 데이터를 가져올 수 있다.
5. Persistence Unit: Persistence Unit은 설정과 관련이 있고 이는 어떻게 JPA가 Java Application 내에서 사용되는지를 정의한다. data source, entity classes, 또는 다른 JPA와 관련된 세팅들을 명세한 설정이라고 생각하면 된다.
6. Transaction Management: JPA는 트랜잭션 관리를 지원하는데 트랜잭션 관리란 데이터베이스에 변화가 생겼을 때 그에 대한 지속성 또는 업데이트 처리를 말한다. 어노테이션을 사용하거나 코드 기반의 메서드를 통해 트랜잭션을 정의하고 관리할 수 있다.
JPA를 사용하므로써, 자바 개발자는 데이터베이스와 연관된 작업을 좀 더 객체 지향적으로, 표준화된 방식으로 작업할 수 있다.
h2.console.enabled: true = console이라는 웹 브라우저에서 h2 database를 작업할 수 있는 설정을 적용한다는 의미
h2.console.settings.web-allow-others: true = 웹 브라우저로 접속하는 것을 허용
h2.console.path: /h2-console = 웹 브라우저 접속 URI는 /h2-console
이렇게 작성하고 서버를 실행해보자.
H2 console
브라우저에 H2 Database를 연동하기 위해 실행한 서비스 URL에 path로 /h2-console을 입력해 보면, 위와 같은 화면이 노출된다. 이것이 H2가 제공하는 console인데 여기서 데이터베이스에 접속할 수 있다.
Settings는 H2, MariaDB, MySQL 등 여러 Database가 있지만 H2를 그대로 사용할 것이고 Driver Class는 org.h2.Driver, JDBC URL은 jdbc:h2:mem:testdb라고 작성하면 In Memory 형식의 데이터베이스로 testdb라는 데이터베이스 이름을 가진 데이터베이스에 접속하겠다는 의미가 된다. Username과 Password는 default로 Username은 sa, Password는 없다.
이 상태에서 접속을 시도해 보면 이러한 에러를 마주치게 된다.
데이터베이스를 찾지 못했다는 뜻인데, 예전 버전에서는 데이터베이스를 못 찾으면 데이터베이스를 생성해 줬는데 이제는 그렇지 않다. 이제는 데이터베이스를 직접 만들어 놓은 상태로 접속해야 한다. 이를 해결하기 위해 UserService에 Entity 클래스를 만들어 User 테이블을 하나 추가해서 데이터베이스를 만들 거다.
ddl-auto는 어떻게 데이터베이스 스키마가 생성과 변경되는지에 대한 제어값인데, 여러 값이 있다.
create: 애플리케이션이 실행될 때마다 Hibernate가 데이터베이스 스키마를 매번 scratch 상태에서 만들어낸다. 이는 기존에 존재했던 데이터들에 손상이 있을 수 있다.
update: Hibernate는 애플리케이션의 엔티티 클래스들의 현재 상태와 매치되도록 데이터베이스 스키마를 업데이트한다. 이는 테이블, 칼럼, 제약 조건들이 추가되거나 변경될 수 있다. 그러나 기존에 존재했던 것들을 삭제하지는 않는다. 이 옵션은 개발 또는 테스트 단계에서 유용할 수 있다.
validate: Hibernate는 어떠한 데이터베이스 스키마에도 변경을 가하진 않는다. 오직 애플리케이션 내 정의된 엔티티들의 매핑들이 유효한지를 판단한다. 만약 애플리케이션에서 정의된 값과 데이터베이스 사이에 어떠한 불일치라도 있으면 에러를 던진다.
none: Hibernate는 스키마에 대해 어떠한 생성이나 유효성 검증에 대한 수행을 하지 않는다. 정상적으로 또는 엔티티 클래스들의 매핑값과 일치한 데이터베이스 스키마를 만들어내는 모든 책임은 사용자에게 가해진다.
create/update 속성값은 Production 환경에서는 주의 또 주의해야 한다. 데이터 손실 또는 예상하지 못한 스키마의 변화가 생길 수 있으며 이 속성값들은 흔히 개발 단계 또는 테스팅 단계에서 간편하게 데이터베이스 셋업을 하기 위해 설정하는 옵션들이기 때문에 Production 환경에서는 validate 또는 none 속성값을 사용할 것을 권장한다.
H2 Database 연동 확인하기
이렇게 모든 설정을 마치고 나면 서버를 재실행해보자. Hibernate 관련 로그들이 여럿 찍히는 걸 확인할 수 있다.
H2 Database에 User Table을 생성한 로그가 찍힌 것이다. H2 Console로 가서 다시 로그인해 보자.
JDBC URL을 jdbc:h2:mem:users라고 변경한 후 접속하면 정상적으로 접속이 되고 Users라는 테이블 하나가 보인다.
또한, User.java 파일에서 정의한 필드들이 칼럼으로 만들어진 것도 확인할 수 있다.
기존에 GatewayService의 application.yml 파일은 eureka.client.register-with-eureka가 false, eureka.client.fetch-registry: false였는데 둘 다 true로 변경해주었다. 그래서 eureka에 이 서비스를 등록하고 eureka에 등록되어 있는 서비스들을 실시간으로 데이터 조회하게 된다.
그 다음, 중요한 부분인 spring.cloud.gateway.routes에 기록되는 각각의 서비스들의 uri다.
보면 user-service의 uri가 lb://USER-SERVICE로 변경되었는데 lb는 Load Balancer의 약자로 eureka에 등록된 Named Service 기반으로 서비스를 찾겠다는 뜻이고 그 서비스의 이름이 USER-SERVICE가 된다는 뜻이다.
주의
서비스의 이름에 "_"가 들어가면 안된다. 나도 이거 때문에 한참 고생했는데 만약 있다면 저렇게 USER-SERVICE로 바꾸자.
기존에 eureka 서버를 띄우면 application name으로 등록된 서비스들의 이름이 보였다. (아래 사진을 참고)
이렇게 eureka에 등록된 서비스들의 이름을 가지고 Gateway가 실제 서비스의 uri를 찾아간다.
server.port를 우선 0으로 지정해서 임의의 포트를 할당받게 했다. 실행할 때마다 번거롭게 포트를 새롭게 지정해 줄 필요 없이 원하는 만큼 서비스의 인스턴스를 실행할 수 있다. 실제로 서비스의 인스턴스를 두 개 정도 띄워보자. IntelliJ에서 인스턴스를 여러개 띄우는 방법은 이미 전 포스팅에서 설명했던 부분이니 넘어간다.
두 개를 띄우고 eureka 서버에 들어가보면 위 사진처럼 두개의 인스턴스가 기동되어 있음을 확인할 수 있다. 그리고 각 인스턴스의 포트를 신경쓰지 않고 Named 기반의 서비스를 Gateway에서 등록했으니 UserService로의 요청을 Gateway는 잘 전달해줄 수 있을 것이다.
Load Balancing 확인
실제로 유저 서비스는 인스턴스가 두개가 등록됐는데 외부 요청이 들어올 때마다 Gateway가 어떤 인스턴스에 요청을 보내는지 확인해보자. 그리고 어떤 방식으로 유저 서비스에 대한 요청을 Load Balancing해주는지도 확인해보자.
Postman으로 테스트해 볼 예정이고 그 전에 UserService의 코드를 좀 수정해야한다.
package com.example.tistoryuserservice.controller;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.core.env.Environment;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@Slf4j
@RestController
@RequiredArgsConstructor
@RequestMapping("/user-service")
public class StatusController {
private final Environment environment;
@GetMapping("/welcome")
public String welcomePage() {
return "Welcome ! This is User Service.";
}
@GetMapping("/message")
public String message(@RequestHeader("user-request") String header) {
log.info("header: {}", header);
return "header check";
}
@GetMapping("/check")
public String check() {
log.info("current port: {}", environment.getProperty("local.server.port"));
return "Hi, check method !" + environment.getProperty("local.server.port");
}
}
Environment 클래스를 주입한다. 이 클래스는 환경 변수에 접근할 수 있게 해주는 스프링에서 제공해주는 클래스이다. 이 클래스를 주입받고 check() method에 이 요청이 들어왔을 때 처리해주는 현재 서버의 포트를 찍어주게 변경했다.
그리고 인스턴스를 두 개 띄웠으니까 각 인스턴스의 잡혀있는 포트를 확인해보자.
유레카 서버에서 보면 인스턴스 두 개에 각각 링크가 걸려있다. 각 링크를 클릭해보면 포트번호를 확인할 수 있는데 나의 경우 인스턴스 한 개는 56482, 56537로 잡혀있다.
이 두 개의 포트번호를 확인한 후 Postman을 열어 실제로 요청을 보내보자.
최초 요청을 보내면 응답은 포트번호 56482로 나온다. 즉, 56482로 띄워진 인스턴스가 이 요청을 처리했다는 의미인데 바로 한번 더 요청을 보내보자.
그 다음 요청은 56537로 잡힌 인스턴스가 이 요청을 처리했다. 이후에 계속 실행을 해보면 한번은 56482가 한번은 56537 인스턴스가 각 요청을 처리한다 이런 방식을 라운드로밍 방식이라고 하고 Load Balancer가 각 요청에 대해 띄워져 있는 인스턴스에게 한 번씩 요청을 전달해 처리하도록 수행해준다. 이게 Load Balancing이고 이를 Spring Cloud Gateway가 해준다.
@Configuration어노테이션을 추가하면 스프링 부트가 자동으로 이 클래스를 설정 처리해준다.
그리고 그 클래스 내부에 @Bean으로 등록한 메소드를 하나 만들고 RouteLocatorBuilder 인스턴스를 build()한다.
이 RouteLocatorBuilder로 라우트 별 설정을 할 수 있다. 이 gateway로 들어오는 요청의 path가 /user-service로 시작하는 모든 요청에 대해 RequestHeader와 ResponseHeader를 추가한다. Header를 추가할 때 key/value쌍으로 추가하면 되는데 이렇게 추가를 할 수 있고 그 요청에 대한 URL을 http://localhost:8081로 보낸다는 의미에 uri()가 있다.
이렇게 Config파일을 하나 만들고 서버를 재실행한 후 UserService에 새로운 Request Controller를 만들어보자.
UserService
package com.example.tistoryuserservice.controller;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@Slf4j
@RestController
@RequestMapping("/user-service")
public class StatusController {
@GetMapping("/welcome")
public String welcomePage() {
return "Welcome ! This is User Service.";
}
// 새롭게 추가한 부분
@GetMapping("/message")
public String message(@RequestHeader("user-request") String header) {
log.info("header: {}", header);
return "header check";
}
}
새로운 GetMapping 메소드를 추가했고 Parameter로 RequestHeader를 받는 header 하나를 넣었다. 이렇게 파라미터에 요청 헤더를 받아올 수 있는데 이 헤더값을 로그로 찍은 후 "header check" 이라는 문자열을 응답 메세지로 반환한다.
이제 /user-service/message로 요청을 해서 filter가 동작하는지 확인해보자.
Filter 동작 확인하기
위 사진처럼/user-service/message로 요청을 보냈을 때 Response Headers에User-Response라는 key가 담겨있는것을 확인할 수 있다. key에 대한 value는 'user-response-header'라고 명시되어 있음을 확인할 수 있다.
여기서 한가지 더 확인할 수 있는건 Request Header에는 추가한"user-request"가 들어가 있지 않는것을 볼 수 있는데 이는 filter를 거치기 전 request header에 정보이기 때문이다. 완벽하게 filter가 정상적으로 동작하고 있는것이다.
그 filter를 거친 request header의 값은 어디서 확인하냐면 UserService의 Controller에서 파라미터에 넣었던 @RequestHeader를 통해 확인할 수 있다.
그러니까 흐름은외부 요청 -> Gateway -> Filter -> UserService이렇게 진행되고 위 브라우저에서는 외부 요청단계에 머물러 있는것이고 로그로 찍힌 상태에서는 UserService에 도달한 상태. 이렇게 외부 요청을 중간에 가로채서 추가적인 작업을 Filter를 통해서 수행할 수 있다.
이렇게 Filter를 설정할 수도 있고 application.yml 파일로도 Filter를 추가할 수 있다. 그것도 한 번 해 볼 생각이다.
application.yml 파일로 filter 추가하기
우선 위에서 등록해봤던 @Configuration을 주석처리하자. filter를 application.yml 파일로 설정할 생각이니까.
spring.cloud.gateway.routes.filters에CustomFilter를 추가했고 그 전에 입력한 AddRequestHeader와 AddResponseHeader는 주석처리했다. 이렇게 설정한 후 재실행 시켜서 다시 UserService에 요청을 보내보자.
UserService가 응답할 수 있는 어떤 요청도 상관없이 요청을 보내보면 gateway service에서 확인할 수 있는 로그가 있다.
필터가 적용된 UserService에 대한 요청이 들어왔을 때 찍힌 로그가 보인다. 이렇듯 사용자 정의 필터를 원하는 서비스마다 적용시킬 수 있다.
GlobalFilter 추가하기
GlobalFilter는 gateway service로부터 들어오는 모든 요청에 대해 필터를 적용하는 것이다.
이 또한 CustomFilter를 만드는것과 비슷하게 만들 수 있다.
filter 패키지 안에 GlobalFilter.java 파일을 만들고 다음과 같이 작성했다.
GlobalFilter는 CustomFilter 만들 때와 거의 유사하다. 똑같다고 봐도 되는데 코드에서 달라지는 부분은 Config 클래스에 properties가 추가됐다. baseMessage, preLogger, postLogger 세 개의 필드를 추가했고 이 값은 application.yml 파일에서 지정해 줄 것이다.
application.yml 파일에서 spring.cloud.gateway.default-filters에 GlobalFilter가 추가됐음을 확인할 수 있다. 이렇게 default-filters로 추가하면 어떤 라우트가 됐던간 이 gateway를 통과하는 모든 요청은 저 필터를 거친다.
그리고, args로 Config 클래스에서 만든 세 가지 필드 baseMessage, preLogger, postLogger 값을 설정했다.
이렇게 작성하고 gateway-service를 재실행해서 UserService에 요청을 날려보자. 그럼 gateway service에서 이런 로그를 확인할 수 있다.
보면 GlobalFilter가 가장 먼저 시작하고 GlobalFilter가 끝나기 전 CustomFilter가 동작해서 끝나고 난 후 GlobalFilter가 마지막으로 끝난다. 모든 필터는 이렇게 동작한다. GlobalFilter로 설정한 필터가 제일 먼저 시작해서 제일 나중에 끝난다.
LoggingFilter 추가하기
필터를 하나 더 추가해서 적용했을 때 필터의 우선순위에 따라 필터가 적용되는 순서가 달라짐을 확인해보고 적절하게 사용할 수 있도록 해보자. CustomFilter, GlobalFilter를 만든 패키지에 LoggingFilter.java 파일을 만든다.
이번에는 Lambda식이 아니고 인스턴스 생성 후 인스턴스를 리턴하는 방식으로 구현해보자. 정확히 같은 내용인데 이렇게 된 코드를 Lambda 표현식으로도 사용할 수 있음을 이해하기 위해서 이렇게 작성했다.
다른건 다 똑같고 OrderedGatewayFilter()의 두번째 인자로 Ordered.LOWEST_PRECEDENCE를 적용하면 이 LoggingFilter가 가장 나중에 실행된다. Ordered.HIGHEST_PRECEDENCE도 있는데 이는 GlobalFilter보다도 더 먼저 실행된다. 그래서 그 차이를 확인해보자.
Part 3에서 조회의 응답 속도를 더 개선하기 위해 내장(Nesting)방법을 이용해서 조회 속도를 더 개선했었다.
그러니까 지금까지 배운 방법은 populate, virtual, nesting 이렇게 크게 3가지를 배워서 조회 속도를 개선해 봤는데 데이터가 정말 무수히 많아지면(몇백만개 또는 몇천만개 혹은 그 이상) 데이터를 내장시켜서 가져올 때 속도가 느려질 수 밖에 없다.
이는 내장시킨 데이터 때문이 아니라 스캔하는 방법에 더 가까운데 기본적인 데이터 스캔 방식은 처음부터 가지고 있는 데이터의 마지막까지 하나씩 가져와 데이터를 찾아내는 COLLSCAN(컬렉션 스캔) 이라는 스캔 방식을 취한다. 이게 데이터가 적을땐 거의 아무런 영향을 끼치지 않는다 (컴퓨터의 연산 속도는 정말 빠르기 때문에) 그러나 데이터가 커지면 커질수록 이 차이가 발생하는데 여기서 개선할 수 있는 방법은 IXSCAN(인덱스 스캔)을 사용하는 것이다.
위처럼 특정 Collection에서 age라는 필드에 index를 오름차순으로 걸었을 때를 가정해보자. 만약 그 Collection의 모든 document 중 age가 53인 데이터만 가져오고 싶다는 쿼리를 작성해서 날리면 인덱스 스캔은 위 그림에서 하단 인덱스의 오름차순 데이터를 가지고 데이터를 찾는다. 최초의 시작은 처음부터가 아니라 중간부터 시작해서 중간인 데이터 age:30이 원하는 53인지 판단 후 53보다 작기 때문에 왼쪽 부분은 더 이상 보지 않는다. 그럼 벌써 모든 데이터의 절반이 필터링 된 것이다. 이게 인덱싱 스캔이다. 그리고 찾은 30이 53보다 작기 때문에 우측으로 넘어가서 우측 끝과 30 사이인 53으로 포인터가 넘어간다. 53은 원하는 값이기 때문에 단 두번만에 원하는 데이터를 찾게된다. 이런 방법을 인덱스 스캔이라고 한다.
실제로 데이터가 한 10만개 정도 있을 때 컬렉션 스캔과 인덱스 스캔은 응답의 속도 차이를 보인다. 아래 예시를 보자.
COLLSCAN Vs. IXSCAN
우선 내 DB에 Users라는 컬렉션에는 데이터가 10만개정도가 있다.
이 상태에서 최초에는 컬렉션 스캔으로 데이터를 가져와보자.
다음과 같이 필터링 조건을 age가 20보다 큰 녀석들로 설정하고, Sort를 age가 오름차순(1) Sort한다는 조건을 걸고 우측 Explain 버튼을 클릭해보자.
그러면 화면창이 하나 뜨는데 거기에는 어떤 데이터를 어떻게 가져와서 얼마나 걸렸는지 자세하게 보여준다.
사진에서 보면 우측 "211ms execution time"라고 보인다. 즉, 모든 처리를 211ms만에 실행했다는 얘기이다. 이제 인덱싱을 걸어서 데이터를 조회해보자.
상단에 보면 Indexes라는 탭이 있다.
인덱스를 새로 생성해보자.
이제 같은 조건으로 쿼리를 실행해보면 다음과 같은 결과를 도출해낸다.
우측 끝에 139ms만에 끝났다는 결과를 얻을 수 있다. 고작 10만개 정도인데도 이런 차이를 보이면 데이터가 많아지면 많아질수록 그 효율성은 더 커질것이다. 이런식으로 인덱싱을 사용해서도 데이터 조회에 응답 속도를 줄여줄 수 있다.
복합 인덱스
이번에는 단일 인덱스가 아니라 복합(여러개) 인덱스를 걸어서 조회해보자.
위에서는 age 하나만 가지고 인덱스를 만들어 스캔했다면 이번엔 username과 같이 인덱스를 걸어서 스캔했을 때 어떤 영향을 끼치는지 알아보자.
우선, 인덱스를 만들지 않고 username을 오름차순, age를 오름차순으로 정렬하는 쿼리를 실행했을 때 응답 속도를 확인해보자.
위처럼 쿼리를 날려보면 아래와 같은 결과를 얻는다.
컬렉션 스캔으로 가져온 데이터를 솔팅하는데 총 109ms의 처리 시간이 발생했다. 여기서 인덱스를 걸어보자.
username 오름차순, age 오름차순에 대한 인덱스를 만들어보자.
이렇게 인덱스를 만들고 다시 조회해보자.
인덱스를 만들어 조회해보면 IXSCAN이라고 나온다. 제대로 인덱스를 이용해 스캔하고 있다.
그럼 반대로 age를 먼저 입력해보자. { age: 1, username: 1 }
신기하게 이번에는 컬렉션 스캔을 수행했고. 우측에 이용가능한 인덱스가 없다고 표시된다. 왜 그럴까 ?
복합 인덱스는 인덱스를 만들 때 필드의 순서가 영향이 있게 된다. 따라서 인덱스를 만들 때 필드의 순서가 중요하다.
이번에는 하나는 오름차순 하나는 내림차순으로 만들어보자.
이렇게 age를 오름차순 username을 내림차순으로 설정하고 인덱스를 만들었고 이와 같은 조회를 해보자.
당연히 IXSCAN을 한다. 합리적이다. 이번에는 반대로 age를 내림차순 username을 오름차순으로 조회해보자.
이것또한 인덱스 스캔을 했다. 왜 그럴까? 위에서는 필드의 순서가 중요하다고 했는데 이런 인덱스는 만든적이 없지만 인덱스 스캔을 했다.
인덱스는 대칭 구조를 갖는다고 생각하면 된다. 만약 인덱스를 { age: 1, username: -1 }로 만들었을 때 여기에 -1을 곱해보면 { age: -1, username: 1 }이 되는데 이 또한 인덱스 스캔으로 동작한다. 그래서 대칭 구조로도 인덱스를 사용할 수 있다고 알아둬야겠다.
그리고 위 결과에서도 알 수 있듯 인덱스 스캔이 더 오래걸리기도 한다. 이는 인덱스를 사용할 때 인덱스가 걸린 필드의 분포도가 영향을 끼치는데 인덱스를 만든 필드의 분포도가 커지면 커질수록 인덱스 스캔은 속도가 오래걸린다. 그래서 인덱스를 남발하는 건 절대 좋은게 아니다. 또한 인덱스를 만들면 인덱스를 생성하는데 들어가는 비용이 꽤나 크기 때문에 메모리를 차지하는데 이 또한 무시할 수 없다. 아래 그림을 보면
101200개의 Documents의 토탈 사이즈보다, Index 5개의 토탈 사이즈가 더 크다. 이 정도로 인덱스는 크기를 많이 차지하는데 크기만 차지하는 문제를 가지고 있는것이 아니고 이렇게 되면 인덱스를 통해 READ하는 속도는 낮출 수 있을지 몰라도 CREATE하는 속도가 올라간다. 데이터를 만들 때 역시 인덱스를 걸어주기 때문이고 인덱스가 많아지면 많아질수록 구조는 복잡해지기 때문이다.
그래서 인덱스를 남발하는건 절대 좋은게 아니라고 할 수 있다. 상황과 처한 상태에 맞게 적절히 사용해야한다.
참고로 텍스트를 인덱스로 사용할 수 있다. 예를 들어, 블로그의 title 같은 텍스트를 인덱스를 걸고 싶으면 아래처럼 하면 된다.
저렇게 title과 content 모두 text로 search할 때 인덱스를 만들어내고 싶으면 복합 인덱스를 사용하면 된다.
마무리
컬렉션 스캔과 인덱스 스캔을 비교해 보았는데 무조건적으로 인덱스 스캔이 좋은것은 아니다. 만약 데이터가 적은 경우, 오히려 인덱스 스캔이 컬렉션 스캔보다 오래걸릴 수 있다. 위에서 언급했던 것처럼 컴퓨터의 연산 속도는 굉장히 빠르기 때문에 백개, 천개정도는 네트워크 속도를 제외하면 거의 차이가 없는데 여기서 인덱싱을 사용하면 오히려 불필요한 과정을 거칠 수 있어진다. 즉, 항상 그렇듯 상황과 상태를 고려해서 구조를 깔아야 한다는 것을 또 한번 느끼고 마무리.
API Gateway를 구현해보자. 그 전에 API Gateway가 있을 때 얻는 이점이 무엇이길래 이 녀석을 구현하는지 알아보자.
API Gateway가 없을 때 외부에서 어떤 요청을 하면 그 요청을 앞 단에서 해당 요청을 처리하는 서비스(뒷 단)와 통신하여 응답을 외부에게 돌려주는 구조가 될 것이다. 이 상태에서는 어떤 문제도 없지만 만약 기존에 있던 서비스들 중 어떤 것이 URL이 변경된다던지, 서비스를 운영하는 서버가 이전된다던지 등 어떤 변화가 생기게 되면 서비스의 URL같은 호출 정보가 변경된다. 호출 정보가 변경되면 그 변경 사항에 맞게 앞 단은 다시 설정 작업을 해야하고 그 작업으로 인해 서비스는 다운타임이 발생한다.
이와 반대로 API Gateway와 같은 중개자가 있는 구조를 살펴보자.
이런 구조를 가졌을 때 외부에서 요청이 들어오면 앞 단은 그 요청을 API Gateway에게 보내게 되고 API Gateway는 그 요청을 처리해주는 서비스에게 전달해주기만 하면 된다. 여기서 만약 위와 같은 상황인 서비스의 URL이 변경되거나, 서비스를 운영하는 서버가 이전된다거나 하더라도 앞 단에서 수정할 부분은 없다. 앞 단은 서비스가 무엇이 있는지조차 알 필요도 없다. 그저 API Gateway와 통신만 하면 되기 때문이다. 서비스를 운영하는 서버가 이전된 경우에 그 서버를 API Gateway에 등록(정확히는 Service discovery이지만 그림에서 표현하지 않았기에 편의상)하기만 하면 된다. 심지어 같은 서비스의 여러 인스턴스가 존재할 때 Load Balancing 처리도 해주기에 좋은 점은 늘어난다.
spring cloud gateway에 어떤 서비스들을 등록되어 라우팅될 것인지를 작성하는 부분인데 내가 만든 UserService를 이 gateway에 등록해서 UserService에 대한 요청이 들어오면 요청을 전달해준다. 그 때 작성하는 부분이 id, uri, predicates이다.
id는 고유값으로 서비스 이름을 설정했다. uri는 해당 서비스가 실행되고 있는 URL정보를 작성한다. predicates은 조건을 명시하는 부분인데 Path에 /user-service/**로 작성하게 되면 gateway로 들어오는 요청의 path 정보가 user-service가 붙고 그 뒤에 어떤 값이 들어오더라도 uri에 명시한 서비스로 요청을 전달한다.
이 application.yml 파일은 많은 변화가 있을 예정이지만 일단은 지금 상태로도 충분하다.
Start Gateway Server
이렇게 작성해놓고 Gateway Service를 실행시켜보면 다음처럼 정상적으로 실행됐다는 로그가 찍혀야한다.
정상적으로 Gateway Service가 올라왔고 이 Gateway를 통해 UserService를 호출했을 때 UserService로 요청이 전달되는지 확인해본다. 그러기 위해서는 UserService에 Controller가 필요하다.
UserService Controller
controller 패키지 하나를 만들고, 그 안에 StatusController.java 파일을 생성
package com.example.tistoryuserservice.controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/")
public class StatusController {
@GetMapping("/welcome")
public String welcomePage() {
return "Welcome ! This is User Service.";
}
}
간단한 Welcome page를 만들었다. UserService의 /welcome으로 요청하면 "Welcome ! this is User Service."라는 문장이 노출되어야 한다. 그러나, gateway를 통해 요청해보면 다음과 같은 404 에러 화면을 마주하게 된다.
이런 현상이 발생하는 이유는 gateway를 통해 호출하는 경로 http://localhost:8000/user-service/welcome 이는 곧 gateway에서 routing 설정대로 http://localhost:8081/user-service/welcome으로 전달한다.
그러나, 만든 UserService의 welcome page 경로는 http://localhost:8081/welcome으로 되어 있다. (위 controller 코드 참고)
그렇기 때문에 404에러를 마주하게 된다. 이를 해결하기 위해 UserService의 Controller를 수정하자.
package com.example.tistoryuserservice.controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/user-service")
public class StatusController {
@GetMapping("/welcome")
public String welcomePage() {
return "Welcome ! This is User Service.";
}
}
StatusController 클래스의 @RequestMapping value를 "/user-service"로 명시했다. 이 클래스에 대한 context path를 지정한것과도 같다. 이렇게 설정한 후 다시 서버를 실행시켜서 확인해보면 정상 응답을 돌려받는다.
마무리
간략하게 Gateway Service를 구현해봤고 앞으로 더 많은 작업을 할 예정이다. 본 포스팅은 여기서 마무리.
eureka.client.fetch-registry:true로 설정하면 eureka server로부터 갱신되는 서비스 정보들을 지속적으로 받겠다는 의미이다.
eureka.client.service-url.defaultZone: http://127.0.0.1:8761/eureka eureka server 정보를 기입하는 부분이다.
UserService 실행
이제 User Service를 실행해보자. 다음과 같은 로그가 출력되면 된다.
그리고 이렇게 정상 실행이 됐으면 Eureka server를 열어보자. User Service가 등록된 모습을 확인할 수 있다.
해당 라인에서 우측 Status 칼럼에 보면 UP(1)이라고 보인다. 한 개의 인스턴스가 띄워져 있는 상태란 의미이다. 한번 여러개를 띄워보자. 같은 서비스라 할지라도 포트를 나누어 더 많은 인스턴스를 띄울 수 있다. 그리고 이렇게 여러개의 인스턴스를 띄워서 부하 분산 처리가 가능해진다.
Start Multiple Instance
기본적으로 IntelliJ에서 상단 아이콘바에 실행버튼을 클릭하면 서버가 실행되는데 이 외 여러 방법으로 실행이 가능하다. 그리고 그 방법을 통해 여러개를 띄워보자.
첫번째는 Run/Debug Configurations이다.
사진처럼 실행할 애플리케이션 선택창을 클릭해서 Edit Configurations를 누르면 아래처럼 Run/Debug Configurations 창이 하나 노출된다.
위 창에서 빨간색 네모칸으로 표시한 "Copy configurations" 버튼을 누르면 현재 실행하고 있는 애플리케이션 구성과 동일한 또 다른 인스턴스의 애플리케이션 구성을 만들 수 있다. 그렇게 하나 추가하면 다른 인스턴스로 또 하나를 실행할 수 있다. 근데 그대로 복사해서 실행하면 같은 포트를 사용할 거기 때문에 포트 충돌 에러가 발생할것이다. 그래서 포트를 변경해줘야 한다. 다음 사진을 보자.
실행할 때 VM option을 추가해줄 수 있다. VM option에 application.yml 파일에 설정한 server.port값을 위 사진처럼 변경한다.
설정 후 Apply > OK
이렇게 새로운 Configurations이 생겼고 역시 실행 버튼 또한 활성 상태가 된다. 이 인스턴스도 실행해보자.
정상 실행이 되었고 9092 포트로 실행됐다는 로그가 보인다. 이 인스턴스 역시 Eureka Server에 등록될 것인데 한번 Eureka Server를 띄워보자. Status를 보면 UP(2) 라는 표시가 보인다.
2개의 유저 서비스가 띄워져있음을 그리고 그 서비스가 모두 같은 Eureka Server에 등록되어 있음을 확인할 수 있다.
Maven으로 빌드 후 패키징하는 명령어인데 clean은 기존에 패키징했던 것들을 전부 말끔히 지우고, compile은 빌드를 한다. package는 말 그대로 패키징을 하는 것이고 -DskipTests=true는 프로젝트 내 테스트 파일이 있을 때 테스트를 스킵한다는 의미이다.
그럼 프로젝트 루트 경로에 target이라는 폴더가 생기고 해당 폴더 안에 .jar파일이 생긴다.
.jar파일의 이름은 pom.xml파일에서 설정한 값으로 그대로 만들어지는데, 앞 부분은 <name></name>안에 설정된 값이고 뒷 부분은 <version></version>안에 설정된 값이다.
실행해보면 포트를 49318이라는 포트로 잡은 것을 확인할 수 있다. Eureka Server에서도 확인해보자.
여기서 0번 포트라고 표시되어 있다. 실제로 포트를 0번으로 잡은건 아니고 우리가 설정한 0이라는 값이 그대로 출력된 모습인데 이 링크를 실제 클릭해보면 같은 49318로 연결됨을 확인할 수 있다.
하나 더 띄워보자. 터미널에서 실행한 방법 그대로 실행해보는데 이번엔 포트를 명시하지 않고 실행해보자.
mvn spring-boot:run
역시나 임의의 포트로 자동 할당된 모습이다. 이렇게 일일이 포트를 직접 명시하는 게 아닌 랜덤 포트를 할당받는 방법으로 인스턴스를 여러개 기동시킬 수 있다.
근데 이대로는 문제가 있다. 어떤 문제냐면 Eureka Server를 다시 보면 분명 인스턴스를 두 개 띄웠지만 하나만 보여진다.
이는 왜일까? Eureka Server에서 서비스를 등록할 때 서비스를 표시하는 방법에서 원인이 있다.
서비스를 등록할 때 서비스 표현 방법을 59.29.234.174:user-service:0 이렇게 표현 하는데 이는 서비스가 띄워진 IP:서비스의 이름:서비스의 포트이다. 서비스의 이름과 서비스의 포트는 application.yml파일에서 설정한 spring.application.name값과 server.port값인데 이 두개의 차이가 인스턴스별 존재하지 않기 때문에 아무리 많이 몇 개를 띄우더라도 Eureka Server는 하나만을 표시할 것이다.
이를 수정하기 위해, eureka.instance.instance-id 값을 부여해야한다.
이렇게 application.yml파일을 수정 후 다시 인스턴스 두 개를 실행한 뒤 Eureka Server를 다시 확인해보자.
이제는 서버의 IP뒤에 알수없는 랜덤값이 표시된 것을 확인할 수 있고 띄운 인스턴스 개수만큼 표시됨을 확인할 수 있다. 이렇게 여러개의 인스턴스를 띄우고 같은 Eureka Server에 등록하는 방법을 알아봤다. 이렇게 여러개의 인스턴스를 띄워서 서비스를 운영하면 유저가 요청을 했을 때 해당 요청을 처리할 수 있는 인스턴스들 중 남는(놀고있는) 인스턴스를 찾아 그 인스턴스에게 요청을 할당하는 Load Balancing기술을 사용할 수 있게 된다.
User Service 내 API 및 비즈니스 로직을 구현하기 전 API Cloud Gateway를 구현해보자.
Spring Cloud Netflix Eureka는 Service discovery tool을 말한다. Service discovery는 분산 시스템에서 각 인스턴스(서비스)들을 등록하고 관리해 주는데 관리해 준다는 건 외부에서 요청이 들어올 때 그 요청을 처리할 수 있는 인스턴스(서비스)가 어떤 서비스인지를 찾아주는 것을 포함한다.
위 그림에서 Netflix Eureka는 API Gateway 바로 다음 단계에 존재하는데, 서비스에 외부 요청이 들어오면 API Gateway는 요청을 받아 해당 요청을 처리할 수 있는 서비스를 찾기 위해 Eureka에게 물어본다. Eureka는 해당 요청을 처리할 수 있는 서비스가 본인한테 등록된 게 있는지 확인 후 있다면 해당 서비스에게 요청을 전달한다. 이렇게 각 서비스들을 관리하고 등록하는 작업을 하는 게 Service discovery고 Spring에서는 Netflix Eureka를 사용할 수 있다.
위 그림에서 각 서비스는 각기 다른 서버에서 구현될 수도 있고 같은 서버내에 포트번호를 다르게 설정하여 동시에 띄울 수 있다. 그에 따라 각 서비스별 호출 URL이 달라질 수 있음을 그림에서 표현한다. 이제 이 Service discovery를 직접 구현해 보자.
Spring Eureka Server 생성
IntelliJ IDEA를 이용해서 프로젝트를 생성할 거다. 우선 New Project로 프로젝트를 만들기 시작하면 좌측 Generators 섹션에 Spring Initializr가 보인다.
여기서 나는 다음과 같이 설정을 했다.
Name, Location은 원하는 대로 설정하면 되고 Language는 Java를 Type은 Maven을 설정했다.
Group은 회사라면 회사 도메인을 거꾸로 쓰는 게 일반적이다. 여기서는 그냥 com.example로 설정했다.
Artifact는 애플리케이션 이름을 작성하면 되며
Package name은 Group.Artifact를 이어 붙여서 설정한다.
JDK는 20으로 설정했고 Java 버전은 17로 설정했다.
Packaging은 Jar를 선택하면 된다.
Next를 누르면 Spring Boot 버전과 Dependencies를 설정할 수 있다.
Spring Boot는 3.1.4 버전을 선택했고 좌측 Dependencies에서 Spring Cloud Discovery > Eureka Server를 선택한다.
선택하면 우측 Added dependencies 항목에 선택한 dependencies들이 추가되는 것을 확인할 수 있다.
Create 누르면 프로젝트가 생성된다.
pom.xml
프로젝트가 생성되면 가장 먼저 확인할 것은 pom.xml 파일이다. 내가 선택한 Eureka dependency가 잘 추가되었는지, 다른 설정에 이상은 없는지 확인해 보자.
spring-cloud-starter-netflix-eureka-server가 dependency로 잘 등록되어 있는 것을 확인할 수 있으며 아래쪽 spring-cloud-dependencies로 version이 ${spring-cloud.version}으로 명시된 것을 확인할 수 있는데 이는 위에 properties안에 <spring-cloud.version>2022.0.4<spring-cloud.version>로 세팅된 값을 가져온다.
문제없이 잘 등록된 것 같다.
@SpringBootApplication
다음으로 확인할 것은 현재 상태에서 유일하게 생성되어 있는 .java 파일이다. 이 파일에서 main()이 있고 스프링은 최초의 시작점을 이 파일로 시작하는데 그때 필요한 Annotation이 @SpringBootApplication이다. 이 어노테이션이 있는 파일을 Spring Boot가 찾아서 최초의 시작을 한다.
package com.example.discoveryservice;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class DiscoveryServiceApplication {
public static void main(String[] args) {
SpringApplication.run(DiscoveryServiceApplication.class, args);
}
}
이 서버는 Eureka Server로 만들 거니까 위 클래스에 @EnableEurekaServer 어노테이션을 붙여주자.
package com.example.discoveryservice;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication
@EnableEurekaServer
public class DiscoveryServiceApplication {
public static void main(String[] args) {
SpringApplication.run(DiscoveryServiceApplication.class, args);
}
}
이 밖에 추가적으로 해줄 일은 없다.
application.yml
src/main/resources경로에 보면 기본으로 application.properties 파일이 있을 건데. properties를. yml파일로 변경해서 사용할 거다.
server.port는 8761로 spring.application.name은 discoveryservice로 설정했다. 일반적인 설정 내용이고 중요한 부분은 eureka항목이다. 두 가지 설정을 해줬다.
eureka.client.register-with-eureka: false
eureka.client.fetch-registry: false
Eureka server로 기동 할 서버인데 왜 client값을 설정해야 하는가에 대한 의문이 생기는데 이 내용은 spring boot가 기본적으로 eureka server를 띄우면 본인도 eureka에 서비스로 등록이 된다. 그러나 본인은 서버이기 때문에 eureka에서 서비스로 등록할 필요가 없기 때문에 본인은 client로 등록하지 않을 것을 명시하는 설정값이라고 생각하면 된다.
Started Eureka Server
이제 필수적으로 수행할 설정을 다 끝냈으니 서버를 시작해 보자. 서버를 시작하면 하단에 Console창에 아래 같은 로그가 출력되어야 한다.
2023-10-06T10:58:50.210+09:00 INFO 4334 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8761 (http) with context path ''
2023-10-06T10:58:50.212+09:00 INFO 4334 --- [ main] .s.c.n.e.s.EurekaAutoServiceRegistration : Updating port to 8761
2023-10-06T10:58:50.214+09:00 INFO 4334 --- [ Thread-9] e.s.EurekaServerInitializerConfiguration : Started Eureka Server
2023-10-06T10:58:50.244+09:00 INFO 4334 --- [ main] c.e.d.DiscoveryServiceApplication : Started DiscoveryServiceApplication in 4.949 seconds (process running for 6.551)
서버를 띄웠으니 웹 브라우저에서 http://localhost:8761을 입력해 진입해 보면 다음과 같이 Eureka server가 띄워진다.
Spring Cloud는 분산 시스템 (MSA 역시 포함)에서 흔하게 사용되는 구조 및 패턴을 쉽게 빌드 및 배포할 수 있도록 도와주는 툴을 제공해 준다. 그런 분산 시스템에서 흔하게 사용되는 기능(툴)이란 건 configuration management, service discovery, circuit breakers, routing, proxy, control bus, authentication, cluster 등 여러 기술이 있다.
Distributed/versioned configuration은 각 서비스마다 필요한 세팅 및 환경변수가 존재하기 마련인데 이런 모든 필요한 세팅을 한 곳에서 관리하여 유지보수 및 환경 세팅의 변화가 생겼을 때 서비스의 재빌드 및 재배포를 거치지 않고 서비스를 다운타임 없이 지속 운영할 수 있는 방법을 말한다. 아래 그림을 보자.
위 그림처럼 각 서비스마다 필요한 환경과 세팅 내용을 한 곳에서 관리하고 그 관리하는 서버를 Git과 연동하여 Spring Cloud Config Server는 Git으로부터 저장되어 있는 환경 정보를 불러와 각 서비스들에게 제공한다.
Service discovery, registration은 Part 1에서 말한 Spring Eureka와 같은 도구를 말한다. 각 서비스들을 등록, 관리하여 이 분산 시스템에서 사용되는 서비스들은 어떤것들이 있고 각 서비스들을 상황에 맞게 관리해 주는 역할을 한다.
Routing, Load Balancing, Service to service calls은 Spring Cloud Gateway로 구현할 수 있는데 클라이언트로부터 요청을 받아 해당 요청을 처리할 수 있는 서비스에게 요청을 전달하며 전달할 때 부하를 분산해주며 각 서비스와 서비스 사이에서 요청을 전달하고 전달받을 수 있게 도와준다.
Circuit Breakers는 장애 처리를 도와주는 기술인데 위 그림이랑 똑같이 서비스가 총 3개가 있다고 가정했을 때, 유저가 유저 정보를 확인하기 위해서 유저 정보를 확인하는 요청을 했을 때 유저 정보에는 본인이 주문했던 또는 주문 중인 이력도 존재한다. 이때 주문 이력을 알아오기 위해 오더서비스를 호출하는데 오더서비스에 문제가 생겼을 때 오더서비스 하나 때문에 전체 유저 정보를 못 가져온다면 사용자 경험은 좋지 못할 것이다. 이때 서킷브레이커를 이용해서 오더서비스로부터 데이터를 받아오지 못하더라도 유저 정보만은 데이터를 가져올 수 있도록 처리해 줄 수 있다. 이 내용도 차차 구현해 보도록 하겠다.
요즘 한창 재미 들려 공부하는 MSA. 하나도 빠짐없이 배우고 공부한 내용을 기록해 보고자 한다.
MSA(MicroService Application)
우선 MSA는 Micro Service Application의 약자로, 어떤 서비스가 가진 기능을 제공할 때 하나의 큰 애플리케이션에서 모든 기능을 수행하는 것이 아니라 기능별, 특징별, 구성별로 서비스들을 작게 나누어 각 기능에 특화된 하나의 작은 서비스를 구축하고 그 구축한 여러 개의 서비스들이 모여 거대한 하나의 애플리케이션이 되는 형태를 말한다.
위 사진에서 우측 SERVICE A, SERVICE B가 있다. 이 두 개의 서비스들은 각자 자신이 수행해야 할 최소 단위의 기능들만을 모아 구성된 하나의 작은 서비스다. 예를 들어, 쇼핑몰 기능을 제공하는 하나의 서비스에 결제 관련 기능을 담당하는 SERVICE A, 장바구니 관련 기능을 담당하는 SERVICE B로 나뉘어 그렇게 각 모든 작은 서비스들이 모여 하나의 큰 서비스를 이루는 것처럼 말이다.
사용자는 이 쇼핑몰이 어떤 구조로 서비스를 제공하는지 알 필요 없이 단순하게 쇼핑몰 사이트에 들어가 원하는 행위를 하면 그 각각의 행위가 필요한 기능, API를 서비스 내에서 알아서 관리하고 호출, 신청, 반환, 응답하면서 서비스가 수행된다.
위 사진에서는 클라이언트에서 요청을 하는 게 첫 번째 흐름인데 요청을 SERVICE A 또는 SERVICE B에 직접적으로 하는 게 아닌 중간에 있는 API Gateway에게 요청한다. API Gateway 역시 Microservice가 된다. API Gateway는 외부의 모든 요청을 이 녀석이 책임지고 받아 이 요청을 처리할 수 있는 서비스를 찾아서 그 서비스에게 돌려주는 Service Discovery Server(Netflix Eureka)에게 전달한다.
여기서 잠깐 Eureka에 대해 얘기하자면, Eureka는 Netflix에서 분산된 서비스들을 등록하고 관리하는 도구이다. 이 Eureka는 분산된 시스템 구조에서 각 서비스들을 등록, 관리, 소통하게 해준다. 이 Eureka를 Service discovery tool이라고 한다.
Eureka 서버는 해당 요청을 처리할 수 있는 서비스를 찾아서 API Gateway에게 그 서비스를 알려주면 API Gateway는 해당 서비스에게 요청을 전달해 준다. 받은 요청을 처리할 수 있는 서비스는 해당 서비스를 처리 후 응답할 결과를 API Gateway에게 다시 돌려주고 최종적으로 클라이언트에게 돌아가게 된다.
전반적인 흐름을 봤을 때 이런 구조를 왜 굳이 가져야 하나 싶지만 이런 구조를 가지는 이유는 다음과 같다.
만약 각 마이크로서비스가 가져야 할 기능을 하나의 서버에서 전부 담당한다면 A가 처리할 기능 A, B가 처리할 기능 B를 모두 담당하고 있을 것이다. 이때 A가 처리할 기능 A를 수정 작업하는 상황이 생겼을 때 B는 어떠한 작업도 필요하지 않지만 서비스의 빌드와 배포가 다시 일어나야 하고 그렇기에 서버의 다운타임이 생긴다. 그 반대도 역시 마찬가지. 그 결과 사용자는 좋지 않은 사용자 경험을 할 수 있다. 그렇다면 이를 작은 단위로 서비스를 분리하여 특정 기능의 수정 및 추가가 일어날 때 해당 서비스만 변경 작업을 하고 해당 서비스가 제공하는 기능을 사용하는 서버 및 게이트웨이는 변경의 진행 여부조차 알 필요 없이 서비스는 계속해서 실행 상태를 유지할 수 있다.
API Gateway는 사용자의 요청을 받아 해당 요청에 대한 라우팅, 필터링, 요청에 대한 트래픽 관리를 해준다. 요청에 대한 트래픽 관리는 부하 분산과 관련이 있는데 이는 사용자에게 받은 요청에 대한 Load Balancing 처리를 해준다. 예를 들어, 쇼핑몰 서비스의 유저 관련 기능을 제공하는 하나의 마이크로서비스가 3개의 다른 포트로 실행되어 Eureka에 등록되면 사용자가 유저 조회와 같은 유저 관련 API를 호출할 때 현재 각 3개의 마이크로서비스 중 이 요청에 응답할 수 있는 서비스를 알아서 찾아 그 서비스로부터 데이터 요청 및 응답을 받는다.
