"클리어"의 두 판 사이의 차이

2020년 6월 27일 (토) 19:28 판

프로젝트 개요

기술개발 과제

국문 : 누구나 쉽게 이용할 수 있는 클라우드 스토리지

영문 : Easy-to-use custom cloud storage

과제 팀명

클리어

지도교수

김성환 교수님

개발기간

2020년 3월 ~ 2020년 6월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 20139200** 심*교(팀장)

서울시립대학교 컴퓨터과학부 20159200** 홍*현

서울시립대학교 컴퓨터과학부 20179200** 송*승

서울시립대학교 컴퓨터과학부 20179200** 이*우

서론

개발 과제의 개요

개발 과제 요약

1. 언제 어디서나 사이트에 접근하여 자신의 파일을 업로드할 수 있으며, 이렇게 업로드한 파일들을 자유롭게 내려받을 수 있다.
2. 대용량 파일(최대 4~5GB) 업로드 및 다운로드를 수행할 수 있다.
3. 다른 사용자들과 팀을 이뤄 자신이 업로드한 파일들을 공유할 수 있다.
4. 파일 즐겨찾기 기능을 통해 자신이 선호하는 파일들을 한눈에 확인할 수 있다.
5. 이미지 파일 및 동영상 미리보기 기능을 통해 업로드된 파일들을 확인할 수 있다.
6. 휴지통 기능을 통해 파일을 삭제하거나 다시 복구할 수 있다.
7. RESTful API 설계를 통해 프론트엔드와 백엔드간의 소통을 원활하게 한다.
8. Docker를 이용하여 다양한 Linux 서버에 이식 가능한 시스템을 만든다.
9. JWT 토큰 및 OAuth2 시스템을 이용한 사용자 인증 시스템을 구축한다.

개발 과제의 배경

우리가 평소에 일상적으로 사용해왔던 구글 드라이브나 N드라이브와 같은 클라우드 스토리지 서비스들은 다양한 소셜 로그인 기능을 제공하지 않는 단점을 지니고 있었다. 우리는 이 점에 착안하여 일반적인 로그인과 함께 OAuth2를 이용한 구글, 페이스북 계정 로그인 방식을 제공하는 새로운 클라우드 스토리지 서비스를 만들어 보기로 했다. 우리가 만든 서비스를 통해 각 사용자는 자신의 파일들을 업로드/다운로드 할 수 있으며, 팀을 구성하여 같은 팀에 속해있는 다른 사람들과 자신의 파일을 공유할 수 있을 것이다. 또한, 각 사용자는 자신이 선호하는 파일들을 등록하여 이들을 따로 관리할 수 있는 기능을 제공받게 될 것이다.

개발 과제의 목표 및 내용

1. JWT 토큰을 이용한 로그인 보안 제공

REST API의 특징 중 하나는 무상태성(stateless)으로, 이는 클라이언트의 context를 서버상에 저장하지 않는다는 의미이다. 따라서 RESTful한 시스템을 구축하기 위해 인증 방식으로 서버에 각 사용자의 데이터를 저장하여 사용하는 session 방식 대신 토큰 자체에 사용자에 대한 정보를 저장하고 있어 서버에 사용자의 정보를 따로 저장할 필요가 없는 JWT 토큰 인증 방식을 선택했다. JWT 토큰은 토큰 자체에 사용자의 정보를 저장하고 있으므로 서버에 세션을 저장할 때보다 서버의 부하가 줄어든다는 장점이 있으며, 이는 사용자에게 더욱 양질의 서비스를 제공해줄 수 있다는 것을 의미한다. 또한, OAuth2에서도 JWT 토큰 방식을 이용하기 때문에 연동이 편리하다는 장점도 가지고 있다.

그림 1. JWT 토큰 인증 방식

위 그림과 같이 JWT 토큰을 통한 인증 방식은 최초 토큰 발급 시에만 DB에 접근하고 그 이후에는 JWT 토큰을 통하여 인증을 진행하기 때문에 세션 방식의 인증보다 서버 부하가 줄어든다는 장점이 있다.

하지만 한편으로 JWT 토큰은 몇몇 보안상의 문제도 가지고 있다. 토큰에 들어있는 정보는 서버의 secret key로 암호화되어 있으므로 토큰의 위/변조는 불가능하지만, 토큰을 보내는 도중에 허가받지 않은 사람이 토큰을 탈취하여 마치 허가받은 사용자인 것처럼 서버에 접근할 수 있다. 토큰이 탈취당한 사실을 알았다 해도 서버 측에서 사용자의 로그인 정보를 저장하지 않기 때문에 이미 발행된 토큰을 만료시킬 방법이 없으며, 이는 JWT를 통한 인증 방식에서 중요한 문제가 된다. 이 문제를 해결하기 위해 대표적으로 사용자에게 유효시간이 짧은 JWT 토큰과 함께 유효시간이 긴 Refresh 토큰을 발급해주고 JWT 토큰이 만료되었을 때 refresh 토큰을 이용하여 새로운 JWT 토큰을 발급받는 방법이 있다. 하지만 이 방법은 재발급 과정에서 refresh 토큰을 검증해야 하기 때문에 서버에 추가적인 refresh 토큰을 저장해야 한다. 이는 stateless한 방법이 아니기 때문에, 대신 다음과 같은 방법을 사용하기로 했다.

1, 발급한 JWT 토큰에 짧은 유효기간을 설정한다(5분).
2. 사용자가 서버에 특정 요청을 보내기 위해 JWT 토큰을 보낼 때, 유효기간이 다시 설정된 새로운 JWT 토큰을 발급해준다.
3. 유효기간이 지난 JWT 토큰을 통하여 요청을 보낼 경우, 해당 토큰을 제거하여 사용자를 로그아웃 상태로 만든다.

이러한 방법은 토큰 재발급 과정이 빈번하게 일어난다는 단점이 존재하지만, 이러한 재발급 과정은 DB에 접근하지 않고 처리할 수 있기 때문에 기존에 refresh token을 서버에 저장하는 방법보다 더 나은 성능을 보일 수 있을 것이다.

2. OAuth2를 이용한 구글 및 페이스북 로그인 구현

OAuth2는 JWT토큰을 사용한 인증방식이다. OAuth2를 통한 로그인 방식에서는 아래와 같은 네 가지의 개념이 존재한다.

1. Resource owner : 기존의 클라이언트에 해당한다.
2. Client : 기존의 백엔드 서버에 해당하는 부분이다.
3. Authorization server : OAuth2 인증을 담당하는 부분으로, 각 소셜 서비스에서 담당한다.
4. Resource server : Authorization server를 통한 인증이 성공했을 때, 우리의 서버로 사용자의 정보들을 제공해준다.

그림 2. OAuth2 로그인 인증 방식

위의 그림은 OAuth2의 로그인 인증 방식을 보여준다. 각 단계별로 차례대로 살펴보자. 먼저 클라이언트(Resource Owner)는 OAuth2 Authorization server에 로그인을 요청한다. Authorization server는 사용자의 ID 및 비밀번호가 유효할 경우 사용자에게 access token을 보내준다. 사용자는 이 access token을 우리의 서버(Client)에 보낸다. 우리의 서버는 OAuth2 Authorization server에 access token을 보내 유효한지 검증받고, 유효할 경우 Resource server로부터 사용자의 프로필 정보를 전달받는다. 이 정보 중 사용자의 고유 ID를 이용하여 DB 상에서 사용자의 정보를 찾고, 정보가 있으면 사용자에게 JWT token을 보내준다. 정보가 없을 경우 새로 회원가입을 시켜준 뒤 JWT 토큰을 보내준다. 사용자는 이 토큰을 이용하여 서버의 정보에 접근할 수 있게 된다.

3. chunk upload를 통한 대용량 업로드 및 재개 가능한 업로드 구현

파일을 서버에 업로드할 때, 서버는 파일을 메모리에 적재시킨 뒤 서버에 저장하는 과정을 거친다. 이는 파일의 용량이 커졌을 때 서버의 메모리에 심한 과부하가 걸린다는 뜻이며, 메모리 용량이 부족하여 업로드되지 않거나 최악의 경우에는 서버가 다운될 수도 있다는 뜻이다. 이것 말고도 다른 문제가 있는데, 파일을 통째로 업로드하게 되면 업로드 일시 정지 및 재개 기능을 구현할 수가 없게 된다. 업로드를 중단한 뒤 재개할 때 클라이언트는 서버에 어느 부분까지의 데이터가 저장되어 있는지에 대한 정보를 알아야 하는데, 파일을 통째로 업로드하면 이러한 정보를 얻는 것이 불가능하기 때문이다.

위와 같은 문제들을 해결하기 위해, 우리는 파일을 chunk 단위로 조각내어 서버에 차례대로 보내는 방식으로 대용량 업로드를 구현하기로 했다. 이렇게 업로드를 수행할 경우 서버의 메모리 부하도 적어질 것이며, 서버 측에서 파일이 어느 부분까지 저장되었는지에 대한 정보를 쉽게 저장할 수 있으므로, 재개 가능한 업로드를 구현하는 것이 가능해진다. 파일을 chunk 단위로 전송하기 위해 자바스크립트 라이브러리인 flow.js를 사용하기로 했다. 자세한 동작 과정은 아래와 같다.

1. 클라이언트가 서버로 업로드 요청을 보낸다.
2. 서버는 클라이언트가 파일을 보낼 URL을 만들어 클라이언트에게 전송해준다.
3. 클라이언트는 서버가 전송해준 URL을 통해 파일을 chunk 단위로 전송하며, 서버는 클라이언트가 보내준 chunk가 이미 저장된 부분은 아닌지 확인한다. 이미 저장된 부분일 경우, 이를 
   클라이언트에게 알려주어 클라이언트가 그 부분 이후의 chunk부터 전송할 수 있도록 한다.
4. 전송이 끝나면, 서버는 chunk들을 합쳐 하나의 온전한 파일로 만든다.

4. Stream API를 통한 대용량 다운로드 구현

파일을 다운로드할 때도 업로드할 때와 반대로 클라이언트의 메모리에 파일을 저장한 뒤 디스크에 쓰는 과정을 거치기 때문에 클라이언트의 메모리 부족 문제가 생길 수 있다. 이를 해결하기 위해 자바스크립트 라이브러리인 StreamSaver.js를 이용하기로 했다. StreamSaver.js는 Streams API를 사용하여 데이터를 메모리에 저장하지 않고 writestream을 이용하여 파일 시스템에 직접적으로 파일을 기록하는 방식을 사용한다. 메모리에 한번 파일을 저장한 뒤 디스크에 쓰는 과정을 거치지 않으므로 메모리 문제도 발생하지 않으며, 메모리에 기록하는 과정이 사라졌으므로 다운로드 속도의 향상도 기대할 수 있다.

관련 기술의 현황

1. Object Storage

최근 들어 어떠한 기준으로도 분류하거나 계층화할 수 없는 비정형 데이터들이 늘고 있는데, 이러한 데이터들을 효과적으로 처리하기 위해 클라우드 스토리지에서 Object Storage를 사용하고 있다. Object Storage는 계층형 디렉토리를 사용하는 파일 스토리지와는 반대로 데이터를 object로 관리하는 스토리지 구조이다. Object Storage는 데이터에 고유한 ID를 부여하여 컨테이너 또는 버킷에 저장하고, 데이터가 필요할 때 부여했던 ID를 통해 데이터를 호출하는 방식으로 사용한다. 이러한 호출 방식을 통해 복잡한 관리가 필요했던 기존의 계층형 디렉토리에 들어가던 비용을 절약할 수 있고, 추후 규모 확장에도 유연하게 대처할 수 있다. Object Storage는 데이터를 분할하여 저장하는 IDA(Information Dispersal Algorithm) 기술을 적용한다. 이 기술을 통해 데이터들은 작은 조각으로 나뉘어 여러 군데의 스토리지에 분산되어 저장될 수 있다.

2. Hybrid Cloud Storage

Hybrid Cloud Storage는 둘 이상의 public cloud 또는 private cloud 환경이 조합된 형태이다. public cloud는 확장성이 뛰어나고 저장공간도 매우 넓다. 하지만 보안적인 측면을 중요하게 여기는 작업은 public cloud를 통해 수행할 수가 없는데, 이러한 작업은 기업이 자체적으로 개발한 private cloud를 통해 수행하게 된다. private cloud는 public cloud에 비해 보안이 강력하지만 비용이 public cloud에 비해 많이 들며, 제공되는 기능도 제한되어 있다. 이러한 두 가지 방식의 클라우드의 장점만을 합친 것이 hybrid cloud storage 형태이다. hybrid cloud는 데이터들을 필요에 따라 public cloud나 private cloud로 자유롭게 이동할 수 있도록 해준다. 이를 통해 매우 중요한 데이터는 private cloud에, 비교적 덜 중요한 데이터들은 public cloud에 저장하는 식으로 보안과 성능을 모두 확보할 수 있다.

3. 대용량 클라우드 스토리지 SW 개발

소셜, 모바일, IoT 등에 의한 기하급수적인 데이터 증가속도로 인해 기존의 스토리지보다 규모가 더 큰 스토리지에 대한 요구가 발생했다. 이러한 요구에 맞추기 위해 국내에서는 NHN, 다음과 같은 회사가 자체적으로 PB 규모의 파일 저장을 지원하는 분산시스템을 개발하여 자사 서비스에 활용 중이다. 해외에서는 빅데이터 분석, 슈퍼컴퓨팅과 같은 분야에서 PB 단위의 스토리지 구축이 증가하고 있으며, Intel, Apache, Redhat 등이 공개 소프트웨어 기반의 분산파일 시스템을 만들어 배포 중이다. 또한, 이러한 파일 규모의 증가에 대응하기 위해 기존의 HDD 중심에서 SSD 및 차세대 메모리 – 스토리지 융합 시스템으로 발전하려는 움직임을 보이고 있다.
(출처 : https://library.etri.re.kr/service/rsch/issue-report/down.htm?view=open&id=683 – 한국전자통신연구원 지식공유플랫폼, 컴퓨팅 산업의 주요 이슈와 전략 핵심 방향, 조병선)

특허조사 및 특허 전략 분석

1. 클라우드 스토리지 시스템(KR20140045738A)

- 발명자 : 엄영익, 김정한, 김태훈

- 요약 본 발명은 클라우드 스토리지 시스템에 있어서, 데이터를 저장하는 하나 이상의 스토리지 서버; 상기 스토리지 서버와 동일한 근거리 통신망에 있으며, 상기 스토리지 서버에 저장되어 있는 데이터를 기초로 클라이언트의 요청을 수행하는 마스터 서버; 클라이언트와 동일한 근거리 통신망에 있으며, 상기 마스터 서버가 전송한 데이터 중 상기 클라이언트에서 자주 접근되는 데이터를 저장하는 하나 이상의 분산 캐싱 서버;를 포함하되, 상기 클라이언트는 상기 분산 캐싱 서버에 자신이 접근하려는 데이터가 있는지 여부를 블룸 필터(Bloom filter)를 통해 확인하는 클라우드 스토리지 시스템을 제공한다.

- 출처 : https://patents.google.com/patent/KR20140045738A/ko (google patents)

2. Cloud based file storage service (US8620879B2)

- 발명자 : Ryan Cairns

- 요약
서버는 사용자로부터 저장할 파일을 전달받고, 해당 파일에 대한 hash value를 생성한다. 서버는 해당 hash value와 동일한 hash value를 가지고 있는 파일이 이미 저장되어 있는지 확인하고, 만약 그렇다면 사용자에게 해당 파일의 복사본을 저장하고 있는 저장소 위치를 가리키는 포인터를 전달하여 복사본에 접근할 수 있는 권한을 준다. 저장되어 있지 않을 경우 서버는 사용자에게 해당 파일을 업로드할 것을 요청한다. 서버는 사용자의 파일 접근 권한을 확인하기 위해 사용자에게 파일의 비밀번호나 해당 파일의 일부분을 요청할 수 있다. 또한, 이러한 권한 체크를 통과했더라도 서버는 사용자의 접근을 제한할 수 있다.

- 출처 : https://patents.google.com/patent/US8620879B2/en (google patents)

기술 로드맵

클라우드 스토리지 어플라이언스

시장상황에 대한 분석

경쟁제품 조사 비교

내용

마케팅 전략 제시

내용

개발과제의 기대효과

기술적 기대효과

내용

경제적, 사회적 기대 및 파급효과

내용

기술개발 일정 및 추진체계

개발 일정

내용

구성원 및 추진체계

내용

설계

설계사양

제품의 요구사항

내용

설계 사양

내용

개념설계안

내용

이론적 계산 및 시뮬레이션

내용

상세설계 내용

내용

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

내용

포스터

내용

완료작품의 평가

내용

향후계획

내용

특허 출원 내용

내용

@@ 93번째 줄: / 93번째 줄: @@
 최근 들어 어떠한 기준으로도 분류하거나 계층화할 수 없는 비정형 데이터들이 늘고 있는데, 이러한 데이터들을 효과적으로 처리하기 위해 클라우드 스토리지에서 Object Storage를 사용하고 있다. Object Storage는 계층형 디렉토리를 사용하는 파일 스토리지와는 반대로 데이터를 object로 관리하는 스토리지 구조이다. Object Storage는 데이터에 고유한 ID를 부여하여 컨테이너 또는 버킷에 저장하고, 데이터가 필요할 때 부여했던 ID를 통해 데이터를 호출하는 방식으로 사용한다. 이러한 호출 방식을 통해 복잡한 관리가 필요했던 기존의 계층형 디렉토리에 들어가던 비용을 절약할 수 있고, 추후 규모 확장에도 유연하게 대처할 수 있다. Object Storage는 데이터를 분할하여 저장하는 IDA(Information Dispersal Algorithm) 기술을 적용한다. 이 기술을 통해 데이터들은 작은 조각으로 나뉘어 여러 군데의 스토리지에 분산되어 저장될 수 있다.
-===2. Hybrid Cloud Storage===
+====2. Hybrid Cloud Storage====
 Hybrid Cloud Storage는 둘 이상의 public cloud 또는 private cloud 환경이 조합된 형태이다. public cloud는 확장성이 뛰어나고 저장공간도 매우 넓다. 하지만 보안적인 측면을 중요하게 여기는 작업은 public cloud를 통해 수행할 수가 없는데, 이러한 작업은 기업이 자체적으로 개발한 private cloud를 통해 수행하게 된다. private cloud는 public cloud에 비해 보안이 강력하지만 비용이 public cloud에 비해 많이 들며, 제공되는 기능도 제한되어 있다. 이러한 두 가지 방식의 클라우드의 장점만을 합친 것이 hybrid cloud storage 형태이다. hybrid cloud는 데이터들을 필요에 따라 public cloud나 private cloud로 자유롭게 이동할 수 있도록 해준다. 이를 통해 매우 중요한 데이터는 private cloud에, 비교적 덜 중요한 데이터들은 public cloud에 저장하는 식으로 보안과 성능을 모두 확보할 수 있다.