서비스 레지스트리란 무엇일까요?

서비스 레지스트리는 애플리케이션 수준 통신을 위한 데이터 구조 스토리지의 데이터베이스로서, 애플리케이션 개발자가 특정 애플리케이션에 사용되는 스키마를 등록하고 찾을 수 있는 중심 위치의 역할을 합니다.

현대적인 소프트웨어 설계는 애플리케이션 프로그래밍 인터페이스(API)를 통해 데이터를 교환하는 느슨하게 결합된 분산형 마이크로서비스를 기반으로 합니다.

대기업을 비롯한 모든 기업의 업무에서 이와 같은 애플리케이션 간 데이터 교환은 필수적입니다. 모든 애플리케이션은 매초 데이터를 주고받으며 원활한 비즈니스 운영을 지원하기 때문에 데이터 무결성 보장이 매우 중요합니다. 그러면 이처럼 다양한 애플리케이션이 이러한 필수 데이터를 실제로 사용하도록 어떻게 지원해야 할까요? 핵심 솔루션 중 하나는 서비스 레지스트리입니다.

예를 들어 Apache Kafka와 같이 데이터를 전송하는 메시징 시스템은 기본적인 데이터 검증을 제공하지 않습니다. 데이터 생성자가 사용할 수 없는 데이터를 전송하면 무슨 일이 발생할까요? 예를 들어 생성자가 필드를 추가 또는 제거하거나 데이터 형식을 변경하면 어떻게 될까요? 데이터 사용자가 이러한 변경에 대해 알림을 받지 못하는 경우 데이터를 올바르게 처리할 수 없고, 최악의 경우 전체 시스템이 다운될 수 있습니다.

데이터 교환이 이루어지기 전에 데이터 사용자는 생성자가 사용 중인 데이터 구조(즉 스키마)가 무엇인지 알아야 합니다. 또한 사용자는 이 스키마가 언제 변경되는지 알아야 합니다. 데이터는 메시징 시스템을 중단시키는 일 없이 변화해야 합니다.

예를 들면 생성자는 파일이 첨부된 이메일을 보내는 식으로 사용자에게 수동으로 스키마를 전송할 수 있습니다. 하지만 다수의 수동 프로세스와 마찬가지로 이 작업은 복잡하고 오류가 발생하기 쉬우며 감사하기 어려울 수 있습니다. 그로 인해 서비스가 중단되고 장애의 원인을 정확히 파악하기가 힘들게 됩니다.

반면, 서비스 레지스트리는 쉽게 액세스할 수 있는 플랫폼을 통해 이러한 정보를 제공할 수 있습니다. 서비스 레지스트리는 생성자 애플리케이션의 개발자가 사용 중인 스키마를 특정 애플리케이션에 등록할 수 있는 중심 위치의 역할을 합니다. 또한 사용자 애플리케이션 개발자는 서비스 레지스트리를 사용해 이 스키마를 찾고 애플리케이션이 해당 생성자의 데이터를 사용하도록 지원합니다. 서비스 레지스트리에 저장할 수 있는 스키마로 Apache Avro, JSON Schema, Google Protocol Buffer 등이 있습니다.

스키마 외에도 서비스 레지스트리는 '아티팩트'라 불리는 다른 자산을 저장할 수 있습니다. 예를 들어 애플리케이션 수준 동기식 통신을 위한 API 사양도 서비스 레지스트리에 저장할 수 있습니다. 서비스가 더 다양해지고 복잡해질수록 서비스 레지스트리의 유용성이 커집니다.

서비스 레지스트리라는 개념이 도입된지 몇 년이 지났지만, 최근에 이와 같이 마이크로서비스 환경에서 필수적인 용도에 적합한 것으로 알려지면서 새롭게 관심이 집중되고 있습니다. 서비스 레지스트리는 생성자 및 사용자 애플리케이션 개발자의 합의에 따라 특정 애플리케이션의 데이터 구조에 대한 SSOT(Single Source Of Truth) 역할을 합니다. 서비스 레지스트리는 '계약 우선' 접근 방식을 지원합니다. 애플리케이션을 먼저 코딩하고 다른 애플리케이션이나 조직이 자사 애플리케이션과 통신할 수 있도록 뒤늦게 계약을 제안하는 대신, 서비스 레지스트리는 입력, 출력, 페이로드 사양, 심지어 검증 규칙까지 포함하는 계약을 미리 지정합니다. 모든 것이 명확히 게시되므로 상호 작용 방식 역시 명확히 알 수 있습니다.

Apache Kafka를 활용 사례로 들어 서비스 레지스트리의 작동 방식에 대해 알아보겠습니다. Kafka는 사용자에게 데이터 구조를 자동으로 제공하지 않고 데이터 검증도 전혀 제공하지 않으므로, 서비스 레지스트리는 이 특정 활용 사례에 이상적입니다. Kafka는 데이터를 구문 분석하거나 읽지 않으므로 필수 리소스를 소진하지 않습니다. 따라서 데이터를 직접 사용자에게 매우 빠르게 배포할 수 있습니다. Kafka로 데이터를 검증하는데 시간이 걸린다면 성능이 훨씬 저하될 것입니다. 따라서 데이터 거버넌스가 없어도 Kafka에는 문제가 되지 않습니다. 오히려 Kafka의 주요 이점인 고성능을 지원할 수 있는 것은 바로 이런 이유에서입니다.

하지만 사용 중인 애플리케이션이 데이터를 적절히 사용할 수 있게 하려면 데이터 구조에 관한 일부 다른 거버넌스를 구현해야 합니다. 규칙을 제공하고 이를 실행하는 서비스 레지스트리가 바로 솔루션입니다.

사용자와 생성자는 Kafka를 통해 데이터를 교환합니다. 서비스 레지스트리를 사용해 생성자와 사용자가 처음부터 트래픽을 정의하는 메타데이터를 문서화 및 공유하고 메타데이터에 대해 합의하면 향후 데이터 관련 오류를 피할 수 있습니다. 메타데이터는 서비스 레지스트리에 저장된 스키마 형태로 제공됩니다.

생성자 애플리케이션 개발자가 서비스 레지스트리에 스키마를 등록하면 서비스 레지스트리는 생성자가 자체 스키마의 사양을 준수하는지 확인합니다. 서비스 레지스트리는 등록된 스키마와 맞지 않는 불량 데이터를 거부하기까지 합니다.

스키마는 위 예시와 같이 특정 생성자 애플리케이션 개발자가 등록할 수 있습니다. 또는 개발 팀 내에서 일반용으로 조직이 등록할 수 있습니다. 이 두 번째 사례에서 서비스 레지스트리는 사용자 애플리케이션 개발자뿐 아니라 생성자 애플리케이션 개발자를 위한 라이브러리의 기능을 수행합니다.

한편, 사용자 애플리케이션 개발자도 라이브러리와 같은 서비스 레지스트리를 활용해 스키마를 검색하므로 생성자 애플리케이션에서 생성되는 데이터를 사용하는 애플리케이션을 빌드할 수 있습니다. 스키마가 변경되면 서비스 레지스트리가 사용자에게 최근에 업데이트된 스키마를 제공합니다.

서비스 레지스트리는 개발 팀과 비즈니스에 다음과 같은 이점을 제공합니다.

애플리케이션에서 데이터 구조 분리

서비스 레지스트리를 사용해 애플리케이션에서 데이터의 구조를 분리하고, REST 인터페이스를 사용해 런타임에 데이터 구조 및 API 설명을 공유하고 관리할 수 있습니다.

탁월한 데이터 품질

서비스 레지스트리는 스키마를 검증하고 데이터 오류를 감지하여 데이터 무결성을 보장합니다. 서비스 레지스트리에는 업로드된 콘텐츠가 구문론 및 의미론적으로 유효하고 다른 버전과 호환 및 역호환되는지 확인하는 규칙이 포함될 수 있습니다. 하지만 서비스 레지스트리는 생성자가 스키마에 맞지 않는 불량 데이터를 전송하지 못하게 합니다.

문서화된 SSOT(Single Source Of Truth)

서비스 레지스트리는 모든 관련 당사자가 검증하고 동의한 SSOT(Single Source Of Truth)를 제공합니다.

개발자 생산성 향상

서비스 레지스트리는 스키마와 API 설계를 일관되게 재사용할 수 있도록 지원하므로 개발자가 생성자 또는 사용자 애플리케이션을 빌드할 때 시간을 단축할 수 있습니다.

비용 절감

런타임 때보다는 개발 라이프사이클 초기에 데이터 관련 오류를 감지하므로 개발 과정에서 오류 다운스트림을 수정할 때 소요되는 개발 시간으로 인한 비용이 크게 절감됩니다.