Spring Initializr를 통해 보는 스프링 각종 모듈 알아보기(2) - Messaging, I/O, OPS, Observability, Testing

7. Messaging

메시징은 어플리케이션 간에 요청 / 행동 전달 등을 할 때 이용합니다.

어플리케이션 A에서 어떤 일이 일어났다면 어플리케이션 B에서 그 일에 대한 일을 처리합니다.

여러 어플리케이션이 상호작용 한다면 메시지 큐를 사이에 두어서 그 일들을 잇게 됩니다.

- Spring Integration(필요시 사용)

Spring Integeration은 메시징과 관련된 패턴을 구현한 모듈입니다.

처음에는 메시징이 Integration과 무슨 상관이 있지라고 생각했지만 다른 뜻이 있더라구요.

 

Enterprise Integration Patterns(EIP) 라고 유명한 책이 있는데 거기에서 이름을 따왔습니다.

이 책에 의하면 기업에서 다양한 어플리케이션들을 개발하고 그것들끼리 소통하는 데에 적합한 패턴이 EIP입니다.

그리고 그 주요 소통 방법이 'Messaging' 입니다.

 

Spring Integration은 이러한 다중 어플리케이션 간의 소통을 세세한 설정들을 통해 지원하고 있습니다.

만약 이 패턴을 구현한 어플리케이션을 만들고 싶다면 Spring Integration을 추가하면 될 것 같습니다.

- Spring for RabbitMQ(중요)

RabbitMQ를 통해서 메시지를 주고 받는 기능을 구현한 모듈입니다.

스프링에서 추상화를 많이 시켜놔서 메시지의 publish/consume 기능을 간단하게 구현할 수 있습니다.

- Spring for Apache Kafka / Kafka Streams(중요)

기존에는 Apache Kafka 라이브러리를 이용하여 Java에서 카프카를 이용했지만,

Spring에서는 또 다른 스프링의 추상화된 간단한 방법을 사용하여 메시지를 publish/consume 할 수 있습니다.

물론 기존 Apache Kafka 라이브러리의 방법도 지원을 하고 있습니다.

Kafka Stream의 경우에는 하나의 라이브러리로서, Kafka를 이용하여 Streaming에 특화된 작업을 할 수 있습니다.
보통은 Kafka에서 메시지를 받거나 보내거나 둘 중에 하나를 하게 되지만,
Stream API는 메시지를 받아서 분석/가공하고 다시 다른 토픽으로 보내는 일을 합니다.

 

데이터의 분석이나 변환을 한다면 유용하게 사용할 수 있는 모듈입니다.

- Spirng for Apache ActiveMQ 5 / ActiveMQ Artemis(필요시 사용)

ActiveMQ는 요새 우선순위가 좀 밀리는 것 같기는 하지만, 여전히 사용을 고려해볼만한 메시지큐입니다.

- WebSocket(주목할 만 한 기술)

WebSocket은 메시징큐는 아니고 새로운 프로토콜입니다.
기존 Http 통신과는 다르게 지속적 연결 방식의 통신 방식을 지원합니다.

스프링 WebSocket에서는 SocketJS, STOMP와 함께 사용하여 웹소켓 어플리케이션을 만들게 해줍니다.

WebSocket은 채팅이나 유저들에게 실시간으로 정보를 업데이트 시켜줘야 할 때 유용할 것으로 보입니다.

- RSocket(주목할 만 한 기술)

Rsocket은 Reactive Stream을 지원하는 프로토콜입니다. 넷플릭스에서 만들었다고 합니다.

그래서 내부 구현도 Reactor를 사용하여 Mono, Flux를 이용해서 개발을 해야 합니다.

양방향 통신, 백프레셔 등을 지원하며 Reactive 하다는 점 때문에 처리량이 많을 때 효과적입니다.

아직까지는 많이 사용하는 것을 보지는 않았지만, 이후에 더욱 Reactive한 서비스를 원한다면 도입해볼만한 기술인 것 같습니다.

 

- Apache Camel(필요시 사용)

Apache Camel은 Spring Integration과 비교되어야 할 모듈입니다. 

Apache Camel 또한 Spring Integration과 마찬가지로 EIP을 구현한 프레임워크입니다.

인터넷을 검색해보니 Apache Camel의 기능이 더 방대하고 쓸만하다는 의견이 많더라구요.

어떤 것을 사용할지 설명한 글이 있어 링크 남깁니다.
참고) colordung.tistory.com/entry/Apache-Camel-VS-Spring-Integration

 

- Solace PubSub+(잘 안 씀)

Spring에서 Solace PubSub+라는 SaaS 메시징 서비스를 지원합니다.
한글로 된 관련글이 없는 걸 보니 국내에선 별로 사용하지 않는 것 같습니다.

 

---

8. I/O

- Spring Batch(중요, 거의 필수)

배치작업을 한다면 Spring Batch를 사용합시다. 

배치가 무엇인지 궁금하신 분은 다음 링크를 참조하시기 바랍니다(jojoldu.tistory.com/324)

간단하게 설명하면

'주기적으로 대량의 데이터를 읽고 처리해서 다시 저장해야 하는 작업들' 을 보통 Batch라고 합니다.

하루 매출을 저장해서 통계 처리를 하고 메일을 보내거나 이런 것들이 대표적이죠.

추가로 실패한 코드를 재시도 할 수 있는 Retry 기능도 여기에 들어있습니다.

 

- Validation(중요)

Validation 모듈은 데이터 클래스의 필드에 어노테이션 통해 제약사항을 걸어주는 기능을 제공합니다.

다음처럼 @NotNull이 지정되어 있다면, 만약 이 클래스를 만드는데 해당 값이 null일 경우 Exception을 발생시킵니다.

Validation을 이용하면 비어있는 입력 또는 이상한 입력을 미리 차단할 수 있습니다.

또한 데이터에 대한 설명 효과도 추가적으로 생깁니다.

웬만하면 DB를 사용한다면 의존성에 추가하여 Validation을 관리하기를 추천합니다.

public class Person {
    @NotNull
    private String id;
    @NotNull
    private String name;
    @Min(10)
    private int age;
    // getter/setter/constructor 생략
}

 

- Java Mail Sender(중요)

스프링에서 메일을 보낸다면 이걸 추가해서 개발하면 될 것 같습니다.

보낼 메일 주소를 설정하고, 해당 모듈의 메서드들을 이용하여 메일을 보낼 수 있습니다.

 

- Quartz Scheduler(중요)

스프링에는 기본적으로 @Scheduled 를 이용해 스케줄러에서 일정 시간마다 메서드를 실행할 수 있습니다.

그렇지만 Quartz는 데이터베이스 지원, 플러그인, 클러스터링 등 다양한 기능을 제공합니다.

좀 더 정교한 스케줄러를 원한다면 사용하면 될 것 같습니다.

다음은 스프링 scheduler와 quartz를 비교한 글입니다.

stackoverflow.com/questions/4385719/spring-scheduling-scheduled-vs-quartz

 

- Spring Cache Abstraction(중요)

스프링에서 캐시를 사용할 수 있도록 해줍니다.

@Cacheable 같은 어노테이션으로 지정하여 추상화된 방법으로 간단하게 적용할 수 있도록 해줍니다.

이름에 Abstraction이 들어있는 것처럼, Redis 같은 DB는 따로 설치를 해줘야 합니다.

 

그런데 이 의존성은 스프링 기본 모듈들에 포함이 되어 있어서 굳이 추가를 안 해줘도 웬만하면 포함이 되어 있는 것 같습니다. 

---

9. OPS

- Spring Boot Actuator(중요, 사용할 일 많음)

Spring Boot Actuator는 dependency에 추가하기만 하면 각종 엔드포인트가 추가됩니다.

어플리케이션 Health 체크, Metric 확인, Graceful Shutdown 등 URL을 이용해 여러 가지를 이용할 수 있게 됩니다.

단독으로도 사용하지만, 다른 기능들에서 선행적으로 필요로 하는 경우가 많습니다.

 

- Codecentric's Spring Boot Admin(server / client) (유용함)

스프링부트도 GUI 대시보드를 이용할 수 있습니다.

하나의 스프링부트 어플리케이션에 Admin Server 의존성을 추가해주고,

관리하고자 하는 어플리케이션에는 Client 의존성을 추가해 준 다음, 설정에서 둘을 연결해주면 됩니다. 

---

10. Observability

여기 있는 모듈들은 다 시계열 데이터나 어플리케이션의 상태 등의 데이터들을 관리하는 서비스들입니다.

Spring에서는 MicroMeter를 이용하여 각 모듈에 맞게, 해당 서비스에 전달될 수 있도록 변환시켜줍니다.

 

- DataDog, WaveFront, New Relic(필요시 사용)

이 세 서비스는 SaaS(Software as a Service)로서 기업 자체 분석 시스템을 갖추고 있습니다.

수익을 위한 서비스이기 때문에 뒤의 것들과 비교해서 세련된 느낌은 있습니다.

좋은 서비스들이지만 요금이 부과된다는 점을 고려하여 도입해야 할 것 같습니다.

스프링에서는 해당 서비스로 데이터들을 보낼 수 있도록 Module을 지원하고 있습니다.

 

- Influx(필요시 사용)

시계열 데이터를 다루는 DB 중에서는 현재 가장 인기가 많습니다.(참고: db-engines.com/en/ranking/time+series+dbms)

Grafana라는 데이터를 예쁘게 보여주는 서비스와 연결하여 사용하기도 합니다. 

 

- Prometheus(주목할 만 한 기술)

프로메테우스는 CNCF(Cloud Native Computing Foundation)에서 지원한 쿠버네티스에 이은 두 번째 인큐베이팅 프로젝트입니다.

애초에 클라우드 네이티브 재단의 지원을 받았다는 점, 그리고 그 전 서비스가 쿠버네티스라는 점 때문에

프로메테우스는 더욱 인기가 늘어나고 있는 것 같습니다.

실제로 쿠버네티스에서 적용하기도 어렵지 않아서 더욱 사용은 늘어날 것 같습니다.

Grafana와 연동이 가능합니다.

 

- Graphite(필요 시 사용)

이건 다른 두 개에 비해서는 사용 빈도는 좀 떨어지는 것 같습니다.

 

---

11. Testing

- Spring REST Docs(주목할 만 한 기술)

Spring에서 API를 문서화하는 방법으로 제일 유명한 것은 Swagger를 사용하는 것입니다.

그러나 Spring Rest docs는 Swagger와는 다른 방법으로 문서화를 제공합니다.

 

Swagger는 Annotation을 통해서 문서를 만드는데 반해 Rest Docs는 테스트코드를 통해서 명세를 기록합니다.

이 테스트 코드가 통과하지 못하면 문서 자체가 생성되지도 않습니다.

즉 테스트와 한 몸인 방법이기 때문에, 테스트 코드의 중요성이 높아지게 되며,

이 때문에 코드의 변경에 반응하는 최신 문서를 쉽게 유지할 수 있습니다.

 

저는 개인적으로는 웬만하면 Swagger보다 REST Docs를 적용할 것 같습니다.

 

자세한 내용은 다음 링크를 참고하기 바랍니다.(www.popit.kr/spring-rest-docs/)

 

- TestContainers(주목할 만 한 기술)

요새는 Docker에 DB를 띄워놓고 테스트를 하는 경우가 많습니다.

 

그러나 TestContainers는 매번 띄우는 리소스도 줄이고자,

코드에 띄우고자 하는 Container를 선언해 준 다음 동작시키면,

어플리케이션이 동작할 때 컨테이너를 띄우고, 종료한다면 컨테이너도 제거 해줍니다.

 

DB나 Message Queue 둘 다 적용 가능합니다.

Docker를 이용해서 테스트를 한다면 적용해볼 만 한 것 같습니다.

 

- Contract Verifier / Contract Stub Runner(주목할 만 한 기술)

Contract Test와 CDC(Consumer Driven Contract)에 대해서는 자료가 많지 않아서 다음의 글을 참고하시기 바랍니다.

MicroService에서 두 개 이상의 어플리케이션의 상호작용에 대한 방법론을 구현한 기술입니다.

(사실 저는 제대로 이해를 못했습니다..)

blog.kingbbode.com/posts/cdc-srping-cloud-contract

 

- Embedded LDAP Server(필요시 사용)

LDAP 보안 방식을 테스트할 때 사용하는 모듈입니다.

 

- Embedded MongoDB Database(MongoDB를 사용한다면 중요)

MongoDB 개발을 할 때 이 의존성을 넣어주면 H2 Database처럼 내장 DB로 간단하게 테스트할 수 있습니다.

개인적으로는 MongoDB를 사용한다면 같이 넣고 사용하는 것이 좋은 것 같습니다.