Dataverse Community Meeting 2023: Sharing data for future generation 2편

Dataverse의 미래 발전 방향

Dataverse의 미래 발전 방향은 크게 세 가지 정도로 요약할 수 있었습니다.

1. Frontend와 Backend를 분리하고 Frontend를 React/TS 기반의 SPA로 개선
2. Shibboleth 등 여러 인증 수단을 래핑하고 OIDC와 Keycloak으로의 전환
3. 컨테이너화

Frontend와 Backend 분리 및 SPA 개선

Dataverse의 기술 스택은 Java EE 8, JPA, JSF로 되어있습니다.

스프링 부트와 관련 스택들이 보편화된 지금에 와서는 다소 연식이 느껴지는 기술들인데요.

Dataverse가 2007년에 시작한 프로젝트이다보니 아무래도 현재에 와서는 레거시 코드가 되어버린 것이 꽤나 있습니다.

Java EE 8과 스프링은 선택의 차이라고 생각할 수도 있지만, JSF의 경우 Java 기반 웹 서버가 웹 페이지 렌더링부터 백엔드 역할까지 모두 수행하고 있기 때문에 역할이 분명하지 않고 메인 모듈의 역할이 너무 무겁습니다.

요즘 많이 사용되는 React를 활용한 SPA 구성도 어렵구요.

그렇지만 Dataverse가 잘 하고 있는 점은 API 구성을 잘 해놓았다는 것입니다.

Dataverse의 API 구성은 다음과 같습니다.

1. Search API
2. Data Access API
3. Native API
4. 그 외

특히 Native API의 경우 기본 GUI Application을 구성하는 데 필요한 API를 모두 제공하고 있기 때문에, Dataverse의 프론트엔드는 이를 기반으로 대체될 수 있습니다.

그렇기 때문에 Dataverse 개발팀은 Dataverse Frontend를 React/TS, SPA 기반으로 재구성하려고 시도하고 있습니다.

https://github.com/IQSS/dataverse-frontend

GitHub - IQSS/dataverse-frontend

앞으로 Dataverse는 Frontend와 Backend를 분리함으로써 결합도를 낮추고 더 자유로운 구성을 지원하게 될 것입니다.

인증 방식의 변화

대한민국에서는 자주 쓰이지 않지만, 외국에서는 인증에 shibboleth라는 방식이 자주 사용됩니다.

그런데 shibboleth의 경우 앞에서 언급한 SPA로의 변화와 상충되는 부분이 있습니다.

shibboleth는 SPA 환경을 고려하여 만들어진 인증 시스템이 아니기 때문입니다.

shibboleth란 무엇이고 왜 SPA 환경에서 사용되기 어려울까요?

 

shibboleth는 single sign-on system입니다.

즉, 하나의 계정을 가지고 다른 조직 또는 기관에서 운영하는 시스템에 로그인 할 수 있도록 돕는 시스텝입니다.

Dataverse는 학교 같은 학술단체나 기관에서 운영하는 경우가 많기 때문에, 일반적으로 이용자들이 계정을 가지고 있습니다.

이 경우에 원래 가지고 있던 계정으로 Dataverse에 로그인 할 수 있으면 편리하겠죠.

이런 이유로 Dataverse에서 shibboleth가 널리 사용되고 있었던 것입니다.

 

그러나 shibboleth는 SPA 환경에서 잘 작동하지 않는데요.

그 이유는 shibboleth의 인증 절차 중 리다이렉트가 필요하고 세션 쿠키를 활용하기 때문입니다.

shibboleth의 경우 사용자를 인증 서비스로 리다이렉트하여 사용자 이름과 암호를 입력하도록 요구합니다.

그러나 SPA에서는 ajax 기술을 이용하므로 리다이렉트가 이루어지기 어렵습니다.

또한 세션 쿠키를 사용하여 인증 상태를 추적하는데, 다른 도메인 또는 서브도메인간 쿠키 공유가 제한되기 때문에 세션 쿠키를 사용하기 어렵습니다.

따라서 SPA 환경에서 shibboleth를 활용하는 것 보단 OIDC나 OAuth 2.0 같은 인증 프로토콜을 사용할 것을 권장하고 있습니다.

 

그러나 SPA로의 전환은 필요하고, OIDC나 OAuth 2.0 같은 인증도 지원해야 합니다.

따라서 Dataverse 개발팀은 이러한 인증 방법을 래핑하여 하나의 인터페이스로 여러 인증 방식을 지원할 계획입니다.

컨테이너화

지금까지 Dataverse의 인프라 구성 방식은 전통적인 것에 가까웠습니다.

물론 AWS 클라우드 환경에서 구성했기 때문에, 정말로 전통적인 것은 아닙니다.

그러나 EC2 인스턴스 기반으로 구성되어 있어 인프라 프로비저닝이 불편하고 서버 가용성을 확보하기 어렵습니다.

지금까지는 EC2 인스턴스를 2개로 다중화함으로써 가용성을 확보해왔습니다만, 앞으로는 컨테이너화를 통해 이러한 것을 달성하려고 합니다.

이와 같은 노력을 Containerization Working Group을 통해서 계속해왔고, 저 또한 시간이 될 때마다 참여해왔습니다.

https://ct.gdcc.io/

The Global Dataverse Community Consortium

그 전까지는 Dataverse의 컨테이너화를 커뮤니티 주도 노력에 맡겨 왔으나, 3월에 한국을 방문하여 제안한 이후부터 Containerization Working Group을 만들어 지속적으로 노력을 이어오고 있습니다.

Dataverse의 다양한 활용

컨퍼런스에 직접 가서 보니 Dataverse의 활용이 매우 다양했습니다.

• Dataverse의 기본적 활용인 학술 데이터의 축적과 활용
• 의료법 컴플라이언스를 준수하는 Dataverse의 활용
• Dataverse 업로드를 편리하게 해주는 Upverse
• Dataverse 데이터셋 리뷰를 편리하게 해주는 EasyReview
• Dataverse 데이터를 TenserFlow API를 이용하여 다운로드 없이 학습하고 모델 업로드
• Dataverse에 소프트웨어 버전을 업로드하여 versioning과 권리관계를 명확히 하는 시도

이러한 내용들에 큰 감명을 받았고 데이터를 업로드, 다운로드 할 수 있는 시스템이 구축되어 있는 만큼 Dataverse를 백엔드로 활용하여 다른 서비스로 활용하는 사례가 굉장히 많았습니다.

이런 사례들 뿐만 아니라 Dataverse를 효율적으로 구성할 수 있는 아키텍처에 대한 발표 등 영감을 주는 많은 내용을 들으면서 서울대학교에서의 데이터버스 또한 발전할 수 있는 여지를 많이 찾아낼 수 있었습니다.