스프링 부트 개발자를 위한 오픈소스 ‘Dapr’ 관련

Spring > Article(s)

---

Article(s)

• 개발자들이 있는 곳에서 출발하기
• 오늘날 쿠버네티스와 클라우드 네이티브 런타임
• 내일: 통합된 크로스 런타임 경험
• 스프링 부트 개발자의 경험 향상을 위한 대퍼 활용
• 장점과 트레이드오프
  • 장점
  • 트레이드오프
• 요약 및 다음 단계

---

스프링 부트 개발자를 위한 오픈소스 ‘Dapr’

스프링 부트와 대퍼(Dapr)를 함께 사용하면, 복잡한 쿠버네티스(Kubernetes, K8s) 클러스터 없이도 로컬에서 대퍼 기반의 애플리케이션을 실행, 테스트, 디버그할 수 있어 개발 과정이 더 간단해집니다. 오늘날 개발자들은 다양한 도구와 클라우드 서비스들을 평가하고 사용해야 하며, 복잡한 내부 개발 프로세스를 따라야 하는 상황에 직면합니다. 이번 글에서는 오픈소스 프로젝트인 대퍼가 스프링 부트 개발자들이 더 견고하고 환경에 종속되지 않는 애플리케이션을 구축하는 데 어떻게 도움을 줄 수 있는지 살펴봅니다.

본문은 요즘IT와 번역가 Jane Heo가 함께 토마스 비타레(Thomas Vitale), 마우리시오 살라티노(Mauricio Salatino)의 글 <Open-Source Dapr for Spring Boot Developers>을 번역한 글입니다. 필자인 토마스 비타레는 1985년에 설립된 국제적인 IT 회사인 시스터매틱(Systematic)에서 소프트웨어 아키텍트로 활동 중이며, 마우리시오 살라티노는 대퍼(Dapr)를 기반으로 한 관리형 서비스와 엔터프라이즈 솔루션을 제공하는 다이아그리드(Diagrid)에서 OSS 소프트웨어 엔지니어로 근무하고 있습니다.

스프링 부트^[1]와 대퍼(Dapr)^[2]를 함께 사용하면, 복잡한 ^[3]쿠버네티스(Kubernetes, K8s) 클러스터 없이도 로컬에서 대퍼 기반의 애플리케이션을 실행, 테스트, 디버그할 수 있어 개발 과정이 더 간단해집니다.

오늘날 개발자들은 다양한 도구와 클라우드 서비스들을 평가하고 사용해야 하며, 복잡한 내부 개발 프로세스를 따라야 하는 상황에 직면합니다. 이번 글에서는 오픈소스 프로젝트인 대퍼가 스프링 부트 개발자들이 더 견고하고 환경에 종속되지 않는 애플리케이션을 구축하는 데 어떻게 도움을 줄 수 있는지 살펴봅니다. 또한 개발자들이 기존의 내부 개발 프로세스를 유지할 수 있도록 지원합니다.

---

개발자들이 있는 곳에서 출발하기

스페인 바르셀로나에서 열린 스프링 I/O 컨퍼런스에서 스프링 커뮤니티를 직접 만날 기회가 있었습니다. 이 컨퍼런스는 스프링 프레임워크 유지 관리자, 핵심 기여자, 최종 사용자들이 매년 모여 프레임워크의 최신 추가 기능, 뉴스, 업그레이드 및 향후 계획을 논의하는 자리입니다.

쿠버네티스, 컨테이너, 그리고 스프링 부트 애플리케이션을 다양한 클라우드 제공업체에 배포하는 방법 등 많은 발표를 볼 수 있었는데, 이러한 주제는 항상 스프링 개발자들에게 적합한 방식으로 다뤄졌습니다. 클라우드 네이티브 환경에서 소개되는 대부분의 도구는 새로운 도구를 사용하고 개발자 작업을 변경하도록 요구하며, 때로는 복잡한 구성이나 원격 환경이 포함되기도 합니다.

예를 들어, 대퍼 프로젝트는 쿠버네티스 클러스터에 설치할 수 있지만, 이를 로컬 개발 프로세스에 포함하려면 쿠버네티스 작업을 추가로 수행해야 합니다. 일부 개발자는 로컬 개발 과정에서 쿠버네티스를 포함하는 데 익숙할 수 있지만, 다른 팀들은 테스트컨테이너와 같은 도구를 사용해 코드 변경을 테스트할 수 있는 임시 환경을 로컬에서 간단하게 생성하는 것을 선호합니다.

대퍼는 프로그래밍 언어와 관계없이 일관된 ^[4]API를 제공합니다. 대퍼는 애플리케이션 기능을 개발할 때 사용할 수 있는 다양한 빌딩 블록(상태 관리, 발행/구독, 서비스 호출, 액터(Actors), 워크플로우 등)을 제공합니다.

90% 이상의 프로덕션 대퍼 워크로드가 쿠버네티스에서 실행

대퍼에 대한 복잡한 설명에 시간을 할애하기보다, 이번 글에서는 대퍼 프로젝트와 스프링 부트 프레임워크 간 통합이 대퍼 지원 애플리케이션 개발 경험을 어떻게 단순화할 수 있는지 중점적으로 다룹니다. 특히, 쿠버네티스 클러스터 내에서 실행하지 않고도 로컬에서 실행, 테스트, 디버깅이 가능한 방식을 살펴봅니다.

---

[5]클라우드 네이티브 런타임

오늘날 대퍼 프로젝트를 사용하려면, 사용하는 프로그래밍 언어와 상관없이 쿠버네티스 클러스터에 대퍼를 설치하는 것이 가장 쉬운 방법입니다. 쿠버네티스와 컨테이너 런타임은 현재 자바 애플리케이션에서 가장 흔히 사용되는 실행 환경입니다.

그러나 자바 개발자들에게 매일 쿠버네티스 클러스터에서 애플리케이션을 실행하고 작업하도록 요청하는 것은 그들의 익숙한 범위를 벗어난 일일 수 있습니다. 많은 개발자들에게 쿠버네티스 사용법을 교육하는 데는 시간이 걸리며, 대퍼와 같은 도구를 클러스터에 설치하는 방법도 배워야 합니다.

스프링 부트 개발자라면, 대부분 로컬에서 애플리케이션을 코딩하고 실행하며 디버깅하고 테스트하고 싶을 것입니다. 이러한 이유로 대퍼는 테스트컨테이너팀과 협력하여 쿠버네티스 클러스터 없이 로컬에서 대퍼를 활용할 수 있는 개발 환경을 제공하게 되었습니다.

스프링 부트 개발자는 쿠버네티스 클러스터를 사용하거나 대퍼가 쿠버네티스에서 어떻게 작동하는지 배우지 않아도 대퍼 API를 사용할 수 있습니다.

이 테스트는 테스트컨테이너가 @ClassRule 애노테이션을 사용하여 대퍼 런타임을 설정(provision)하는 방식을 보여줍니다. 이 애노테이션은 대퍼 런타임을 부트스트랩(초기화)하는 역할을 하며, 이를 통해 애플리케이션 코드는 대퍼 API를 사용하여 상태를 저장하거나 조회하고, 비동기 메시지를 교환하며, 구성을 가져오고, 워크플로우를 생성하고, 대퍼의 액터 모델을 사용할 수 있습니다.

이와 일반적인 스프링 부트 애플리케이션은 어떻게 비교될까요? 예를 들어, 레디스(Redis)^[6], 포스트그레SQL(PostgreSQL)^[7], 래빗엠큐(RabbitMQ)^[8]를 사용해 데이터를 저장하고 조회하며, 카프카(Kafka)^[9]를 통해 비동기 메시지를 교환하는 분산 애플리케이션이 있다고 가정해 봅시다. 해당 애플리케이션의 코드는 [여기 (salaboy/example-voting-app)](java/ 디렉토리 아래에 자바 구현 코드가 있습니다) 에서 확인할 수 있습니다.

스프링 부트 애플리케이션에서는 레디스 클라이언트뿐만 아니라, 포스트그레SQL JDBC 드라이버^[10]와 래빗엠큐 클라이언트도 종속성으로 추가해야 합니다. 또한 레디스를 위한 Spring Data KeyValue^[11], 포스트그레SQL을 위한 Spring Data JDBC^[12], 래빗엠큐를 위한 스프링 부트 Messaging 래빗엠큐와 같은 스프링 부트 추상화를 사용하는 것이 일반적입니다.

이러한 추상화와 라이브러리는 기본 레디스, 관계형 데이터베이스, 래빗엠큐 클라이언트의 기능을 확장하여 스프링 부트 프로그래밍 모델에 적합하게 만들어 줍니다. 스프링 부트는 단순히 클라이언트를 호출하는 것에 그치지 않고, 클라이언트의 생명주기를 관리하며, 개발자들이 일반적인 사용 사례를 구현할 수 있도록 지원하고, 그 과정에서 모범 사례를 자연스럽게 따를 수 있도록 돕습니다.

스프링 부트 개발자들이 대퍼 API를 어떻게 사용할 수 있는지 보여준 테스트를 되돌아보면, 상호작용은 다음과 같이 보일 것입니다.

두 번째 다이어그램에서는 스프링 부트 애플리케이션이 대퍼 API에만 의존합니다. 위에서 설명한 대퍼 API를 사용하는 단위 테스트와 이전 다이어그램 모두에서 HTTP나 gRPC(gRPC Remote Procedure Call)^[13] 요청을 통해 대퍼 API에 직접 연결하는 대신, 대퍼 Java SDK를 사용하기로 결정했습니다. 애플리케이션 클래스패스에는 래빗엠큐, 레디스 클라이언트나 JDBC 드라이버가 포함되지 않았습니다.

대퍼를 사용하는 이 접근 방식에는 여러 가지 장점이 있습니다.

1.

애플리케이션은 레디스나 래빗엠큐 클라이언트를 포함할 필요가 없으므로 의존성이 줄어듭니다. 따라서 애플리케이션 크기가 작아질 뿐만 아니라, 애플리케이션이 배포되는 환경의 특정 인프라 구성 요소에 덜 의존하게 됩니다. 이러한 클라이언트의 버전은 특정 환경에서 실행 중인 구성 요소의 인스턴스와 일치해야 한다는 점을 기억해야 합니다.

최근에는 스프링 부트 애플리케이션이 클라우드 제공업체에 배포되는 경우가 많아지면서 데이터베이스나 메시지 브로커 같은 구성 요소의 버전을 개발자가 제어하기 어려운 환경이 흔합니다. 개발자들은 일반적으로 이러한 구성 요소를 로컬 환경에서 컨테이너를 사용해 실행하므로, 고객을 대상으로 하는 환경에서 애플리케이션이 실행될 때 버전 불일치 문제가 발생할 가능성이 큽니다.

2.

애플리케이션은 레디스, 래빗엠큐, 포스트그레SQL에 직접 연결하지 않습니다. 연결 풀 구성 및 기타 세부 사항은 인프라와 밀접하게 관련되어 있습니다. 이러한 구성 요소가 애플리케이션 코드에서 분리되고 대퍼 API 뒤로 통합되면서 애플리케이션이 더 간단해졌습니다.

3.

새로운 애플리케이션 개발자는 래빗엠큐, 포스트그레SQL, 레디스의 작동 방식을 배울 필요가 없습니다. 대퍼 API는 자체적으로 명확합니다. 예를 들어, 애플리케이션 상태를 저장하려면 saveState() 메서드를 사용하면 되고, 이벤트를 발행하려면 publishEvent() 메서드를 사용하면 됩니다. IDE를 사용하는 개발자는 사용 가능한 API를 쉽게 확인할 수 있습니다.

4.

클라우드 네이티브 런타임을 구성하는 팀은 선호하는 도구를 사용해 사용할 수 있는 인프라를 구성할 수 있습니다. 예를 들어, 자체 관리하는 레디스 인스턴스를 Google Cloud In-Memory Store로 전환하려면 애플리케이션 코드를 수정하지 않고도 레디스 인스턴스를 교체할 수 있습니다. 자체 관리하는 카프카 인스턴스를 Google Pub/Sub 또는 Amazon SQS/SNS로 교체하려면 대퍼 설정만 조정하면 됩니다.

그런데 이렇게 하면, saveState/getState, publishEvent 같은 API는 어떻게 되는 걸까요? 구독(subscription)은 어떻게 처리할까요? 이벤트를 소비하는 방법은? 이러한 API 호출을 스프링 부트와 더 잘 통합해, 개발자가 새로운 API를 배우지 않아도 되도록 개선할 수 있을까요?

---

내일: 통합된 크로스 런타임 경험

대부분의 기술 문서와 달리, 여기에서의 답은 “상황에 따라 다릅니다”가 아닙니다. 물론 답은 YES입니다. 우리는 스프링 데이터와 메시징(Messaging) 접근 방식을 따라, 스프링 부트와 완벽히 통합된 더 풍부한 대퍼 경험을 제공할 수 있습니다. 이 접근 방식을 로컬 개발 환경(테스트컨테이너 사용)과 결합하면, 팀이 로컬, 쿠버네티스, 클라우드 제공업체 등 다양한 환경에서 빠르게 실행되며, 변경 없이 작동하는 애플리케이션을 설계하고 코딩할 수 있도록 도와줍니다.

이미 레디스, 포스트그레SQL 및/또는 래빗엠큐를 사용하고 있다면, 스프링 데이터와 스프링 래빗엠큐/카프카/펄사(Pulsar)^[14]와 같은 스프링 부트 추상화를 비동기 메시징을 위해 사용하고 있을 가능성이 높습니다.

Spring Data KeyValue에 대한 자세한 내용은 ‘A Guide to Spring Data Key Value’ 게시물을 참고하세요.

@Bean
public KeyValueOperations keyValueTemplate() {
    return new KeyValueTemplate(keyValueAdapter ());
}

@Bean
public KeyValueAdapter keyValueAdapter() (
    return new MapKeyValueAdapter (WeakHashMap.class);
}

Employee employee = new Employee(1, "Mile", "IT", "5000");
keyValueTemplate.insert(employee);

ID로 직원을 조회하려면,

Optional<Employee> savedEmployee = keyValueTemplate.findById(id, Employee.class);

비동기 메시징을 위해 스프링 카프카, 스프링 펄사, 스프링 래빗엠큐를 살펴볼 수 있습니다. 이들 모두 메시지를 생성하고, 소비할 수 있는 방법을 제공합니다. (관련 자료: Messaging with RabbitMQ)

카프카로 메시지를 생성하는 것은 다음과 같이 간단합니다.

@Autowired
private KafkaTemplate<String, String> kafkaTemplate;

public void sendMessage(String msg) (
    kafkaTemplate.send(topicName, msg);
}

카프카 메시지를 소비하는 것도 매우 간단합니다.

@KafkaListener (topics = "topicName", groupId = "foo")
public void listenGroupFoo(String message) {}
    System.out.println("Received Message in group foo:" + message):
}

래빗엠큐의 경우에도 거의 동일한 방식으로 처리할 수 있습니다.

@Autowired
private final RabbitTemplate rabbitTemplate;

그리고 메시지를 보내려면 이렇게 하면 됩니다.

rabbitTemplate.convertAndSend(topicExchangeName, "foo.bar.baz", "Hello from RabbitMQ!");

래빗엠큐에서 메시지를 소비하려면 다음과 같이 할 수 있습니다.

String foo = (String) rabbitTemplate.receiveAndConvert("nyqueue");

---

스프링 부트 개발자의 경험 향상을 위한 대퍼 활용

이제 새로운 대퍼 스프링 부트 스타터를 사용했을 때 어떻게 보일지 살펴보겠습니다.

DaprKeyValueTemplate을 살펴보겠습니다.

@Autowired
private final DapzleyValueTerplate keyValueTemplate;

이제 KeyValueTemplate을 사용하여 우리의 Vote 객체를 저장해 보겠습니다.

Vote vote- nev Votevote、 voterid, a0inctcocution, Voterid
// Store the vote
keyValuetemplate.insert (vote);

KeyValue 저장소에 쿼리를 생성하여 저장된 모든 투표를 찾아보겠습니다.

KeyValueQuezy<String> keyValueQuezy = new ReyValueQuezy<String>("'type' == 'vote'");
Iterable<Vote› votes = kejValuelenplate.find(keyValueQuery, Vote.class);

왜 이게 중요할까요? 대퍼 KeyValueTemplate은 스프링 Data KeyValue에서 제공하는 KeyValueOperations 인터페이스를 구현하는데, 이는 레디스, 몽고DB(MongoDB)^[15], 멤캐시드(Memcached)^[16], 포스트그레SQL, MySQL 등과 같은 도구들에 의해 구현됩니다. 큰 차이점은 이 구현이 대퍼 API와 연결되며, 특정 클라이언트를 필요로 하지 않는다는 점입니다.

동일한 코드는 레디스, 포스트그레SQL, 몽고DB 및 AWS 다이나모DB(DynamoDB)^[17], 구글 클라우드 파이어스토어(Google Cloud Firestore)^[18]와 같은 클라우드 제공업체 관리 서비스에 데이터를 저장할 수 있습니다. 대퍼에서는 30개 이상의 데이터 저장소를 지원하며, 애플리케이션이나 의존성에 대한 변경 없이 사용할 수 있습니다.

비슷하게 DaprMessagingTemplate을 살펴보겠습니다.

@Autowired
private final DaprMessagingTemplate<Vote> messagingTemplate

이제 메시지/이벤트를 발행해 보겠습니다.

messagingTemplate.send(voteProperties.topic(), vote);

메시지/이벤트를 소비하려면 카프카 예제와 유사한 주석 방식으로 사용할 수 있습니다.

@Topic(name = topiclame, pubsubllane = pubSubllame)
@PostMapping("/ subsesibe")
public void handlellessages(@RequestBody CloudEvent<Vote> event) {
    LOG.info("*+++++CONSUME ()-====-*, event);
}

중요한 점은 기본적으로 대퍼가 CloudEvents를 사용하여 이벤트를 교환한다는 것입니다(다른 형식도 지원됨). 이는 내부 구현에 관계없이 동일하게 적용됩니다. @Topic 주석을 사용하면 애플리케이션이 특정 Dapr PubSub 구성 요소에서 지정된 Topic의 모든 이벤트를 수신하도록 구독합니다.

다시 말해, 이 코드는 카프카, 래빗엠큐, 아파치 펄사와 같은 모든 지원되는 Dapr PubSub 구성 요소 구현뿐만 아니라 Azure Event Hub, Google Cloud PubSub, AWS SNS/SQS와 같은 클라우드 제공업체 관리 서비스에도 적용됩니다(자세한 내용은 Dapr Pub/sub 브로커 문서 참조).

DaprKeyValueTemplate과 DaprMessagingTemplate을 결합하면 개발자는 통합된 API를 통해 데이터 조작과 비동기 메시징에 접근할 수 있습니다. 이 방식은 애플리케이션 의존성을 추가하지 않으며, 환경과 관계없이 포터블합니다. 즉, 동일한 코드를 다른 클라우드 제공업체 서비스에서 실행할 수 있습니다.

이것이 스프링 부트와 더 비슷해 보이지만, 더 많은 작업이 필요합니다. Spring Data KeyValue 위에 Spring Repository 인터페이스를 구현하여 CRUDRepository 경험을 제공할 수 있습니다. 또한 테스트에 대한 일부 미비한 부분이 있고, 개발자가 이 API를 빠르게 시작할 수 있도록 하는 문서가 필요합니다.

---

장점과 트레이드오프

새로운 프레임워크나 프로젝트, 도구를 기존의 기술 스택에 추가할 때, 그 도구가 나에게 어떻게 작동할지 이해하는 데 있어 트레이드오프를 아는 것이 중요합니다.

대퍼의 가치를 이해하는 데 도움이 되었던 한 가지 방법은 80% 대 20% 규칙을 사용하는 것이었습니다. 이 규칙은 다음과 같습니다.

• 80%의 경우, 애플리케이션은 메시지 브로커, 키/값 저장소, 구성 서버 등과 같은 인프라 구성 요소에 대해 간단한 작업을 수행합니다. 애플리케이션은 상태를 저장하고 검색하며 비동기 메시지를 발행하고 소비하여 애플리케이션 로직을 구현해야 합니다. 이러한 시나리오에서는 대퍼로부터 가장 큰 가치를 얻을 수 있습니다.
• 20%의 경우, 특정 메시지 브로커에 대한 깊은 전문 지식이 필요하거나 복잡한 데이터 구조를 구성하기 위한 성능 좋은 쿼리를 작성해야 하는 고급 기능을 구축해야 합니다. 이러한 경우에는 대퍼 API를 사용하지 않아도 괜찮습니다. 왜냐하면 애플리케이션 코드에서 특정 인프라 기능에 접근해야 할 수도 있기 때문입니다.

새로운 도구를 살펴볼 때 이를 가능한 많은 사용 사례에 맞추려고 일반화하는 것이 일반적입니다. 대퍼에서는 대퍼 API가 사용자의 사용 사례에 맞을 때 개발자에게 도움을 주는 데 집중해야 합니다. 대퍼 API가 맞지 않거나 특정 API가 필요한 경우, 제공자별 SDK/클라이언트를 사용하는 것도 괜찮습니다.

대퍼 API가 기능을 구축하기에 충분할 때와 그렇지 않은 때를 명확히 이해함으로써, 팀은 기능을 구현하기 위해 어떤 기술이 필요한지 미리 설계하고 계획할 수 있습니다. 예를 들어, 래빗엠큐/카프카나 SQL 및 도메인 전문가가 고급 쿼리를 구축하는 데 필요한가요?

또한 우리가 피해야 할 또 다른 실수는 도구가 우리의 배포 관행에 미치는 영향을 고려하지 않는 것입니다. 환경 간 마찰을 줄이는 데 적합한 도구를 사용할 수 있고, 개발자가 클라우드 제공업체에서 실행할 때 필요한 동일한 API와 의존성을 사용하여 로컬에서 애플리케이션을 실행할 수 있도록 할 수 있다면 좋습니다.

이 점들을 염두에 두고 장점과 트레이드오프를 살펴보겠습니다.

장점

• 분산 애플리케이션에서 요구하는 공통된 동작에 접근하고, 애플리케이션의 여러 모듈이나 계층에 걸쳐서 공통적으로 발생하는 문제나 기능을 처리하는 간결한 API를 제공합니다. 이를 통해 개발자는 복원력(재시도 및 회로 차단 메커니즘), 가시성(오픈 텔레메트리(OpenTelemetry)^[19] 사용, 로그, 트레이스 및 메트릭), 보안(인증서 및 상호 TLS(mTLS)^[20])과 같은 문제를 대퍼에 위임할 수 있습니다.
• 새로운 스프링 부트 통합 덕분에 개발자는 기존의 프로그래밍 모델을 사용하여 기능에 접근할 수 있습니다.
• 대퍼와 테스트컨테이너 통합 덕분에 개발자는 대퍼를 실행하거나 구성하는 데 걱정할 필요가 없고, 기존 개발 루프에 외부 도구를 배우지 않아도 됩니다. 대퍼 API는 개발자가 로컬에서 기능을 구축, 테스트 및 디버깅할 수 있도록 제공됩니다.
• 대퍼 API는 개발자가 인프라와 상호 작용할 때 시간을 절약할 수 있도록 도와줍니다. 예를 들어, 모든 개발자가 카프카/펄사/래빗엠큐가 어떻게 작동하는지 배우는 대신, 대퍼 API를 사용하여 이벤트를 발행하고 소비하는 방법만 배우면 됩니다.
• 대퍼는 클라우드 네이티브 환경에서의 포터빌리티를 가능하게 하여, 코드 변경 없이 로컬 또는 클라우드 관리 인프라에서 애플리케이션을 실행할 수 있습니다. 대퍼는 운영/플랫폼 팀이 다양한 지원되는 구성 요소에서 인프라를 연결할 수 있도록 명확한 관심사의 분리를 제공합니다.

트레이드오프

대퍼 API와 같은 추상화 계층을 도입하면 항상 일부 트레이드오프가 따릅니다.

• 대퍼는 모든 시나리오에 가장 적합하지 않을 수 있습니다. 이러한 경우에는 특정 클라이언트/드라이버가 필요한 복잡한 기능을 별도의 모듈이나 서비스로 분리할 수 있습니다.
• 대퍼는 애플리케이션이 실행될 대상 환경에서 필요합니다. 애플리케이션은 대퍼가 존재하고 애플리케이션이 제대로 작동하도록 필요한 인프라가 올바르게 연결되어 있어야 합니다. 만약 운영/플랫폼 팀이 이미 쿠버네티스를 사용하고 있다면, 대퍼는 ^[21]CNCF(Cloud Native Computing Foundation) 프로젝트로서 상당히 성숙한 프로젝트로 3,000명 이상의 기여자가 있으므로 쉽게 도입할 수 있습니다.
• 애플리케이션과 인프라 구성 요소 사이에 추가적인 추상화가 있을 경우 문제 해결이 더 어려워질 수 있습니다. 스프링 부트 통합의 품질은 문제가 발생했을 때 오류가 개발자에게 얼마나 잘 전달되는지로 측정할 수 있습니다.

장점과 트레이드오프는 귀하의 특정 상황과 배경에 따라 달라진다는 것을 알고 있습니다. 이 목록에 빠진 내용이 있다면 언제든지 문의해 주세요.

---

요약 및 다음 단계

Dapr Statestore (KeyValue)와 PubSub (Messaging)을 다룬 것은 첫 번째 단계에 불과하며, 스프링 부트 프로그래밍 모델에 더 고급 대퍼 기능을 추가하면 개발자가 강력한 분산 애플리케이션을 만드는 데 필요한 더 많은 기능에 접근할 수 있습니다. TODO 목록에 대퍼 Workflows를 통한 내구성 있는 실행이 포함되어 있으며, 서비스 간 복잡하고 장기 실행되는 오케스트레이션을 개발하는 원활한 경험을 제공하는 것이 일반적인 요구 사항입니다.

제가 스프링 부트와 대퍼 통합 작업을 열정적으로 진행한 이유 중 하나는 자바 커뮤니티가 생산성과 일관된 인터페이스에 집중하여 개발자 경험을 다듬기 위해 열심히 노력했다는 것을 알기 때문입니다. 저는 자바 커뮤니티에서 쌓인 모든 지식이 대퍼 API를 다음 단계로 끌어올리는 데 활용될 수 있다고 확신합니다. 기존 API로 다룰 수 있는 사용 사례를 검증하고 갭을 찾아내어 더 나은 통합을 구축하고 다양한 언어에서 개발자 경험을 자동으로 개선할 수 있습니다.

Spring I/O에서 제시한 예제의 모든 소스 코드는 이 글의 “Today, Kubernetes, and Cloud-Native Runtimes” 섹션에 링크되어 있습니다.

우리는 스프링 부트와 대퍼 통합 코드를 Dapr Java SDK에 병합하여 스프링 부트에서 작업할 때 기본 대퍼 경험으로 만들 예정입니다. 문서도 곧 제공할 거고요. 만약 이 프로젝트에 기여하거나 대퍼가 스프링 부트와 더 잘 통합될 수 있도록 도와주고 싶다면 우리에게 연락주세요.

---

원문

Open-Source Dapr for Spring Boot Developers

Using Dapr with Spring Boot simplifies the development for Dapr-enabled apps: run, test, and debug locally without the need to run inside a K8s cluster.

스프링 부트 개발자를 위한 오픈소스 ‘Dapr’

---

스프링 부트와 대퍼(Dapr)를 함께 사용하면, 복잡한 쿠버네티스(Kubernetes, K8s) 클러스터 없이도 로컬에서 대퍼 기반의 애플리케이션을 실행, 테스트, 디버그할 수 있어 개발 과정이 더 간단해집니다. 오늘날 개발자들은 다양한 도구와 클라우드 서비스들을 평가하고 사용해야 하며, 복잡한 내부 개발 프로세스를 따라야 하는 상황에 직면합니다. 이번 글에서는 오픈소스 프로젝트인 대퍼가 스프링 부트 개발자들이 더 견고하고 환경에 종속되지 않는 애플리케이션을 구축하는 데 어떻게 도움을 줄 수 있는지 살펴봅니다.

---

1. 스프링 부트: 웹사이트나 모바일 앱과 같은 소프트웨어를 빠르고 효율적으로 개발할 수 있도록 도와주는 프레임워크 ↩︎

2. 대퍼: 큰 소프트웨어를 여러 개의 작은 서비스로 나누어 쉽게 개발하고 운영할 수 있도록 도와주는 오픈 소스 도구 ↩︎

3. 쿠버네티스: 애플리케이션을 실행하고 관리하는 자동화 도구 ↩︎

4. 한 시스템이 다른 시스템과 통신하거나 기능을 호출할 수 있도록 제공하는 규칙, 프로토콜, 그리고 도구의 집합 ↩︎

5. 클라우드 환경에서 애플리케이션을 효율적으로 개발, 배포, 실행할 수 있도록 설계된 실행 환경 ↩︎

6. Redis: Remote Dictionary Server의 약자로, 주로 메모리 기반의 데이터 저장소로 사용되는 오픈 소스 소프트웨어 ↩︎

7. PostgreSQL: 오픈 소스 기반의 관계형 데이터베이스 관리 시스템(RDBMS) ↩︎

8. RabbitMQ: 오픈 소스 메시지 브로커(Message Broker) 소프트웨어로, 애플리케이션 간 메시지를 송수신하고 관리하는 역할 ↩︎

9. Kafka: 대규모 데이터 스트리밍과 메시지 큐잉을 효율적으로 처리할 수 있는 시스템으로, 높은 처리 성능과 내구성을 제공 ↩︎

10. JDBC(Java Database Connectivity): API를 사용하여 Java 애플리케이션이 데이터베이스와 상호작용할 수 있도록 해주는 소프트웨어 컴포넌트 ↩︎

11. Spring Data KeyValue: 프로젝트의 일환으로 제공되는 데이터 저장소 추상화 라이브러리 ↩︎

12. Spring Data JDBC: JDBC를 사용하여 관계형 데이터베이스와 상호작용하는 스프링 데이터 프로젝트의 모듈 ↩︎

13. 구글에서 개발한 고성능, 오픈 소스 원격 프로시저 호출(RPC) 시스템 ↩︎

14. 고성능의 분산 메시징 시스템으로, 실시간 데이터 스트리밍 및 메시징을 지원하며, 뛰어난 내구성, 확장성, 멀티 테넌시 기능을 제공하는 오픈 소스 플랫폼 ↩︎

15. MongoDB: NoSQL 데이터베이스의 하나로, 비관계형 데이터베이스 시스템 ↩︎

16. Memcached: 메모리 기반 캐시 시스템으로, 주로 데이터베이스나 웹 애플리케이션에서 자주 조회되는 데이터를 메모리에 저장해 두고 빠르게 접근할 수 있도록 도와주는 시스템 ↩︎

17. DynamoDB: AWS에서 제공하는 NoSQL 데이터베이스 서비스 ↩︎

18. Google Cloud Firestore: 클라우드 기반 NoSQL 데이터베이스 ↩︎

19. 분산 시스템에서 애플리케이션의 동작을 추적하고 모니터링할 수 있도록 도와주는 오픈소스 프로젝트 ↩︎

20. Mutual TLS의 약자. 클라이언트와 서버가 서로를 인증하는 보안 프로토콜 ↩︎

21. 클라우드 네이티브 컴퓨팅 재단 ↩︎