000001560595_1425351208416_0.5687465614331808

저작자표시-비영리-변경금지 2.0 대한민국
이용자는 아래의 조건을 따르는 경우에 한하여 자유롭게
l 이 저작물을 복제, 배포, 전송, 전시, 공연 및 방송할 수 있습니다.
다음과 같은 조건을 따라야 합니다:
l 귀하는, 이 저작물의 재이용이나 배포의 경우, 이 저작물에 적용된 이용허락조건
을 명확하게 나타내어야 합니다.
l 저작권자로부터 별도의 허가를 받으면 이러한 조건들은 적용되지 않습니다.
저작권법에 따른 이용자의 권리는 위의 내용에 의하여 영향을 받지 않습니다.
이것은 이용허락규약(Legal Code)을 이해하기 쉽게 요약한 것입니다.
Disclaimer
저작자표시. 귀하는 원저작자를 표시하여야 합니다.
비영리. 귀하는 이 저작물을 영리 목적으로 이용할 수 없습니다.
변경금지. 귀하는 이 저작물을 개작, 변형 또는 가공할 수 없습니다.

클
라
우
드
스
토
리
지
확
장
을
위
한
하
이
브
리
드
스
토
리
지
A
P
I
의
설
계
임
복
출
석사 학위논문
클라우드 스토리지 확장을 위한
하이브리드 스토리지 API의 설계
TheDesignofHybridStorageAPI
forCloudStorageExtension
2013년 02월
중 부 대 학 교 인 문 산 업 대 학 원
정 보 과 학 과
임 복 출

석사 학위논문
2013년 02월
정 보 과 학 과
임 복 출

지도교수 김 순 곤
이 논문을 석사학위 논문으로 제출함.
2013년 02월
정 보 과 학 과
임 복 출

임복출의 석사학위 논문을 인준함.
심사위원장 인
심 사 위 원 인
심 사 위 원 인
2012년 12월 일

-i-
◆ 목 차 ◆
목 차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ ⅰ
표 목 차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ ⅲ
그림목차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ ⅴ
제 1장 서 론 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 1
제 1절 연구 배경 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 1
제 2절 연구 내용 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 2
제 2장 관련연구 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 3
제 1절 클라우드 컴퓨팅 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 3
제 2절 클라우드 아키텍처 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 6
제 3절 클라우드 스토리지 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 11
제 3장 HybridStorageAPI의 설계 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 13
제 1절 전체시스템의 구성 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 13
1.파일 업로드 절차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 15
2.파일 다운로드 절차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 16
3.파일 목록 조회 절차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 17
제 2절 HybridStorageAPI시스템 구성 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 18
1.InboundHandler구간 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 19

-ii-
2.OutboundHandler구간 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 19
3.Controller구간 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 20
4.연동 프로토콜 방식 및 송수신 전문 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 20
제 3절 HybridStorageAPI시스템 연동 인터페이스 구성 ‧‧‧‧‧‧‧‧‧‧‧‧‧ 21
1.IF_USER_HSA ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 22
2.IF_HSA_STRG ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 26
제 4장 실험환경 및 결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 36
제 1절 HybridStorageAPI시스템 개발환경 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 36
제 2절 연동규격 및 절차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 38
1.파일 업로드 절차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 38
2.파일 다운로드 절차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 39
3.파일 목록 조회 절차 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 40
제 3절 업로드 및 다운로드 테스트 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 41
1.성능 테스트 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 42
2.HybridStorageAPI의 기술 검증 결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 48
제 5장 결론 및 향후과제 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 54
참고문헌 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 56
Abstract ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 58
감사의 글 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 60

-iii-
◆ 표 목 차 ◆
[표 1]추상화와 가상화 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 3
[표 2]클라우드 컴퓨팅의 장점과 단점 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 4
[표 3]아키텍처적인 요구 사항 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 6
[표 4]HybridStorage시스템 구성요소 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 14
[표 5]HybridStorageAPI개발항목 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 20
[표 6]인터페이스 구성 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 21
[표 7]FILE_UP_HSA Overview ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 22
[표 8]FILE_UP_HSA RequestDefinition ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 23
[표 9]FILE_UP_HSA ResponseDefinition ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 23
[표 10]FILE_UP_HSA ErrorCode‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 24
[표 11]FILE_DW_HSA Overview ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 24
[표 12]FILE_DW_HSA RequestDefinition‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 25
[표 13]FILE_DW_HSA ResponseDefinition‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 25
[표 14]FILE_DW_HSA ErrorCode ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 26
[표 15]FILE_UP_ES RequestParameter ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 26
[표 16]FILE_DW_ESRequestParameter‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 28
[표 17]FILE_AUTH_SW RequestParameter‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 29
[표 18]FILE_AUTH_SW ResponseParameter‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 29
[표 19]FILE_UP_SW RequestParameter‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 30
[표 20]FILE_DW_SW RequestParameter‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 32

-iv-
[표 21]HybridStorageAPI하드웨어 구성 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 36
[표 22]업로드 및 다운로드 테스트 개요 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 41
[표 23]EasyStorageUpload시험결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 42
[표 24]SwiftUpload시험결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 43
[표 25]GlusterUpload시험결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 44
[표 26]EasyStorageDownload시험결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 45
[표 27]SwiftDownload시험결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 46
[표 28]GlusterDownload시험결과 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 47
[표 29]Storages상호간 연동방식 비교 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 48
[표 30]Storage상호간 프로토콜 차이점 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 49
[표 31]RESTful방식 HTTP명령어 사용방식 차이점 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 50
[표 32]파일처리방식의 차이점 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 50
[표 33]업로드/다운로드 트랜잭션에 따른 인증방식의 차이점 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 51
[표 34]인증정보 Parsing예시 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 53

-v-
◆ 그 림 목 차 ◆
[그림 1] CloudArchitecture‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 7
[그림 2] SoftwareasaService ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 8
[그림 3] InfrastructureasaService‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 9
[그림 4] Platform asaService‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 10
[그림 5] CloudStorage ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 12
[그림 6] HybridStorage시스템 구성도 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 13
[그림 7] 파일 업로드 시나리오 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 15
[그림 8]파일 다운로드 시나리오 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 16
[그림 9]파일 목록 조회 시나리오 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 17
[그림 10]HybridStorageAPI개념도 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 18
[그림 11]HybridStorageAccess서버 구조 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 19
[그림 12]HybridStorageAPI인터페이스 정의 ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 21
[그림 13]파일 업로드 SequenceDiagram ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 38
[그림 14]파일 다운로드 SequenceDiagram ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 39
[그림 15]파일 목록 조회 SequenceDiagram ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ 40

-1-
제 1장 서 론
제 1절 연구배경
비즈니스 환경과 IT 발전의 빠른 변화만큼이나 기업들의 IT 비용은 늘어나고 있
다.따라서 급변하는 환경에 적절하게 대응하며 IT 비용을 절감하는 것은 모든 기
업들의 생존 관계가 되고 있다.이러한 부담은 IT 자산에 대한 기업들의 패러다임
에 변화를 가져 오고 있다.IT 자산에 대한 기존의 패러다임인 소유에서 이제는 사
용으로 바뀌고 있는 것이다.
여기에는 1980년대 후반부터 IT 운영의 아웃소싱(SM), 웹호스팅,
ASP(ApplicationServiceProvider)등의 등장은 이러한 패러다임의 변화에 한 몫을
하였으며,특히 2007년 이후에는 클라우드 컴퓨팅 서비스가 시장에 등장함에 따라
IT 자산은 소유보다는 서비스 받는다는 추세가 점점 확산되고 있다.
이러한 경향을 반증하듯 아마존,구글,IBM,MS,Yahoo등 주요 IT 기업들은 속
속 클라우드 서비스를 제공하고 있으며,최근 들어 Salesforce,Facebook,Youtube,
Myspace같은 기업들도 인터넷 사용자를 대상으로 한 클라우드 컴퓨팅 서비스를
제공하고 있다[1].
이런 기업들이 클라우드 컴퓨팅에 어떤 역할과 서비스를 제공하는지 간략하게 설
명하면,구글은 수십만 대 이상의 서버 관리 기술,수십 페타바이트의 데이터를 저
장하고 분석할 수 있는 기술 등을 보유하고 있으며,이런 기술 중 일부를 논문으로
외부에 공개해 클라우드 기반 기술의 성공 사례를 공유하고 있다.또한 메일,일정,
Docs등과 같은 일반 사용자가 사용하는 클라우드 기반의 서비스를 제공하며 앱엔
진(AppEngine)이라는 클라우드 기반의 플랫폼 서비스를 제공해 사용자가 개발한
애플리케이션을 클라우드 환경에서 실행할 수 있는 플랫폼을 제공한다.
아마존은 가상 머신,스토리지 등 클라우드 인프라 자원 서비스를 제공하며,세일
즈포스닷컴은 기업 대상 CRM 웹 애플리케이션 서비스를 제공한다[2].
본 논문에서는 클라우드 컴퓨팅의 여러 분야 중 스토리지(IaaS,PaaS)의 효율적

-2-
인 제공과 연동을 위한 방안으로 HybridStorage개념을 도입하여 클라우드 스토리
지 시스템에서 제공하는 OpenStack,Gluster,Atmos등의 다양한 스토리지 제공이
가능하도록 API의 설계를 진행 하였다.HybridStorageAPI를 설계하고 기본적인
시스템 플로우를 통한 결과를 제시하여,클라우드 컴퓨팅 환경에서의 스토리지 제
공이 가능 하도록 하였다.
제 2절 연구내용
본 연구는 클라우드 컴퓨팅 환경에서 Storage의 제공 용량 확대에 따라 Storage
의 증설 비용이슈를 해결하고,저 비용의 운용 가능한 Storage 기술을 확보하고
Open Source기반의 StorageSolution을 도입하여 다양한 사업 확장에 적용할 수
있는 기반을 마련하기 위해 HybridStorageAPI의 설계를 진행하였다.설계 방법을
제시한다면 다음과 같다.
첫째,클라우드 컴퓨팅에 대한 기술 및 원리,등장배경을 살펴본다.둘째,클라우
드 컴퓨팅 환경 구성과 서비스를 제공하기 위해 클라우드 아키텍처에 대한 연구
자료를 활용한다.셋째,스토리지의 다양한 환경과 HybridStorageAPI를 위해 클
라우드 스토리지 시스템에서 스토리지 제공방식을 연구한다.넷째,다양한 서비스에
스토리지를 제공하기 위한 OpenAPI형태의 서비스 프로토콜을 제안한다.
본 논문의 구성은 다음과 같다.제1장에서는 본 연구배경,연구내용을 설명한다.
제2장에서는 논문의 관련연구에 대하여 설명한다.제3장에서는 제시한 시스템의 전
체적인 구성과 세부구성,각 모듈의 기능을 상세히 설명한다.제4장에서는 제안된
방식의 실험환경을 설명하고,결과의 효율성을 증명하기 위하여 다양한 스토리지를
연계한 API의 시험결과를 제시한다.마지막으로 제5장에서는 본 논문에 대한 결론
과 향후과제를 제시한다.

-3-
제 2장 관련 연구
제 1절 클라우드 컴퓨팅
클라우드 컴퓨팅은 네트워크상에 분산되어 있는 컴퓨터를 가상화(virtualization)
시킨 후 인터넷과 네트워크 환경에 접근하여 실행하는 애플리케이션과 서비스를 말
한다.클라우드 컴퓨팅은 애플리케이션을 실행하는 사용자에게 제공할 항목인 컴퓨
터 자원의 가상화,무제한적인 사용,물리적인 컴퓨터 시스템들의 세분화 등에 의해
다시 구분된다[4].
클라우드 컴퓨팅은 큰 개념에서 클라우드 컴퓨팅을 구분할 수 있는 배치
(deployment)모델과 서비스(service)모델로 구분할 수 있다.
배치 모델은 클라우드 시스템이 네트워크상에서 어떤 위치에 있는지,어떤 목적
으로 사용되는지에 대한 정의이며 공공(public), 개인(private), 커뮤니티
(community),하이브리드(hybrid)클라우드 시스템으로 나뉘어진다[2,4].
시비스 모델은 공급자가 제공하는 클라우드 서비스 종류에 따라 구분된다.가장
잘 알려진 서비스 모델에는 SPI(Software product improvement) 모델인
SaaS(SoftwareasaService),PaaS(Platform asaService),IaaS(Infrastructureas
aService)가 있다.즉,서비스 모델은 구축한 서비스 종류에 따라 벤더가 무엇을
관리해야 하는지와 사용자의 권한이 무엇인지에 따라 구분된다[2].
클라우드 컴퓨팅의 정의를 좀 더 깊게 살펴보면,추상화와 가상화의 두 가지 개
념을 가지고 있으며,다음 [표 1]과 같다[4].

-4-
추상화
애플리케이션은 명시되지 않은 물리적인 시스템에서 실행되고,데이터도
알려지지 않은 위치에 저장되고,시스템 관리는 외부에 위탁하고,사용자는
어디서나 시스템에 접근할 수 있습니다.즉,시스템의 상세한 사항들을 사
용자와 개발자는 몰라도 시스템을 이용하거나 수정할 수 있다는 것
가상화
시스템과 저장장치(storage)는 중앙에 집중된 클라우시 시스템의 인프라
(instrastructure)로부터 필요한 만큼 공급받을 수 있다.요금은 사용한 만
큼 지불하고,다중 소유(multi-tenany)가 가능하고,시스템 자원들은 빠르
게 확장할 수 있다.즉,풀링과 공유되는 시스템 자원을 통해 하나의 시스
템을 공유해서 누구나 사용할 수 있다는 것
[표 1]추상화와 가상화
장점
-주문형 셀프서비스 :사용자는 클라우드 서비스 공급자와 개인적인 접촉
없이도 컴퓨터 자원을 사용할 수 있어야 한다.
- 광대역 네트워크 접근 :클라우드 시스템의 자원에 접근하는 것은 사용
자들이 플랫폼에 독립적으로 접근한다는 것을 의미하며 표준적인 체계의
네트워크를 사용할 수 있다.이는 다른 운영체제 간의 호환성을 보장하며
랩탑,휴대폰,PDA 같은 씬/팻 플랫폼을 지원한다는 뜻이다.
- 자원풀링 :클라우드 서비스 공급자는 멀티테넌트(multi-tenant)사용을
지원하는 시스템에서 공유할 수 있는 자원을 생성하며,물리적 시스템과
가상 시스템은 필요에 따라서 유동적으로 할당 혹은 재할당된다.풀링의
이러한 개념은 가상 머신,프로세싱,메모리,저장 장치,네트워크 대역과
연결 같은 자원들의 위치를 숨기기 위한 추상화에서 아이디어를 얻은 것이
다.
-민첩한 탄력성 :자원들은 빠르고 탄력적으로 준비될 수 있어야 한다.또
한 가상 머신은 자원을 더 나은 성능의 컴퓨터 또는 같은 성능의 컴퓨터
[표 2]클라우드 컴퓨팅의 장점과 단점
클라우드 컴퓨팅의 장점과 단점은 다음 [표 2]와 같다[4].

-5-
둘 중에서 어떤 형태로든 자동 또는 수동으로 추가할 수 있어야 한다.왜
냐하면 사용자 관점에서 클라우드 컴퓨팅 자원은 무제한이어야 하고,언제
나 얼마든지 구매할 수 있어야 하기 때문이다.
-종량제 서비스 :클라우드 시스템 자원의 사용량은 측정시스템을 기반으
로 해서 사용자에게 측정되고 검사되고 보고된다.즉,사용자는 저장장치
사용량,트랜잭션의 수,네트워크 I/O 또는 대역폭,사용된 프로세싱의 양
등을 기반으로 비용을 지불한다.아니면 사용자는 제공된 서비스의 수준에
따라 비용을 지불하기도 한다.
단점
- 애플리케이션과 서비스를 사용할 때,본인이 원하는 만큼 사용자화되지
않은 소프트웨어를 사용한다는 것이다.즉,많은 클라우드 애플리케이션이
유용하다고 할지라도 사용자 시스템의 내부에 설치되 애플리케이션들이 더
많은 기능을 가지고 있다.
- 모든 클라우드 애플리케이션은 WAN 연결 때문에 발생하는 고유의 대
기시간을 기다려야 하는 어려움을 가지고 있다.클라우드 애플리케이션이
대용량 프로세싱 작업에 뛰어나다 할지라도 사용자의 애플리케이션이 많은
양의 데이터를 전송해야 한다면 클라우드 애플리케이션은 사용자에게 최고
의 모델은 아니다.
-클라우드 컴퓨팅은 인터넷처럼 국적이 없는 무국적 시스템이다.또한 분
산된 시스템상에서 통신을 요청하는 것은 필수적으로 단방향이다.
- 사용자가 클라우드 컴퓨팅 안에서 '개인정보 보호와 보안'을 스스로 관
리해야 한다는 것이다.사용자의 데이터가 시스템상에서 이동하고 머무른
다면 더 이상 사용자의 관리 영역에 있지 않다.그런데 사용자는 법적인
조치가 시행된다고 할지라도 기술적인 문제로 인해 스스로의 개인 정보 보
호를 관리하는 클라우드 공급자를 파악할 수 없다.그러므로 데이터는 누
군가가 가로채거나 불법으로 사용할 수 있는 위험이 커진다.

-6-
탄력적 확장성
대부분의 디바이스들이 인터넷에 접속되는 지금의 환경에서는 서버
로의 사용자 요청을 예측하기 어렵다.그리고 서비스 계획 단계에서
정확한 용량 산정이 어렵다.따라서 시스템은 갑자기 부하가 증가하
거나 초기 계획 대비 시스템 리소스 사용이 많으면 빠르고 기민하게
시스템을 확장,축소할 수 있어야 한다.
고가용성
클라우드 서비스는 모든 자원(서버,데이터,파일 등)이 중앙 집중돼
있는 클라우드 서비스 내에 존재한다.따라서 클라우드 서비스의 안
정성에 문제가 있으면 문서,메일 등 사용자는 자신의 데이터를 전혀
사용할 수 없는 상황이 발생한다.따라서 클라우드 서비스는 기존 서
비스보다 훨씬 높은 고가용성을 필요로 한다.
자동화된
리소스 관리
구글은 수십만 대 이상의 서버를 운영 중이다.이런 서버를 수작업으
로 관리하는 것은 불가능하거나 많은 비용이 소요된다.클라우드 서
비스는 최소 수십∼수백 대 이상의 서버나 스토리지 등을 필요로 하
며,이들 리소스는 자동으로 관리되어야 한다.
자동 복구/치료
고가용성을 확보하고 자동화된 리소스 관리가 되기 위해 소프트웨어
자체적으로 복구,치료할 수 있는 능력은 핵심 요구 사항이라고 할
수 있다.이를 지원하기 위해 프로그램 개발은 더 어려워졌다고 할
수 있다.클라우드는 기존의 하드웨어에서 해결하던 많은 문제를 소
프트웨어로 해결하려고 한다.하드웨어는 말 그래도 상황에 따라 유
연하게 설정을 변경하는 것이 어렵다.자동화된 관리,유연한 확장성
[표 3]아케텍처적인 요구 사항
제 2절 클라우드 아키텍처
클라우드 컴퓨팅의 구현적인 기술을 보면 가상화와 분산 기술의 효과적인 사용에
있다.클라우드 아키텍처는 분산 기술을 필요로 하는 모든 시스템에 적용 가능한
아키텍처이다.이런 관점에서 아키텍처적인 요구 사항은 다음 [표 3]과 같다[4].

-7-
등을 제공하려면 소프트웨어로 대신해야 하는 경우가 많다.따라서
소프트웨어가 점점 더 똑똑해져야 하며,이런 시스템 소프트웨어를
사용하는 클라이언트 소프트웨어도 똑똑해져야 한다
클라우드 아키텍처의 개념은 다음 [그림 1]과 같다.
<그림 1> CloudArchitecture

-8-
클라우드 아키텍처를 서비스 모델에 따라 구분하면 다음과 같다.
SaaS(SoftwareasaService)는 애플리케이션,관리,사용자 인터페이스를 포함하
는 서비스 모델이다.SaaS 모델은 씬(thin)클라이언트 인터페이스를 통해서 사용자
에게 애플리케이션을 제공하고,사용자는 애플리케이션과 사용자간의 상호작용을
시작하면서 마칠 때까지 데이터를 관리할 책임이 주어진다.애플리케이션 다운로드
부터 인프라 구축까지 모든 과정이 벤더의 책임이다[2,3].
SaaS의 개념도는 다음 [그림 2]와 같다.
<그림 2> SoftwareasaService

-9-
IaaS(InfrastructureasaService)는 사용자가 가상 머신,가상 저장장치,가상 인
프라(Infrastructure)와 같은 하드웨어 자원을 사용할 수 있도록 서비스를 제공한다.
IaaS 서비스 공급자는 사용자들이 서로 다른 개발 목적을 가지고 있어도 모든 인프
라를 관리해 준다.즉,운영체제,애플리케이션,시스템에 대한 사용자 인터페이스
등을 모두 관리할 수 있다[2,3].
IaaS의 개념도는 다음 [그림 3]과 같다.
<그림 3> InfrastructureasaService

-10-
PaaS(Platform asa Service)는 사용자에게 가상 머신,운영체제,애플리케이션,
서비스,개발 프레임워크,트랜잭션,관리구조 등을 제공한다.사용자는 있는 애플리
케이션을 사용할 수 있다.서비스 공급자는 클라우드 인프라,운영체제,사용 가능
한 소프트웨어를 관리하며 서비스를 사용하는 동안 해당 애플리케이션을 설치,관
리하는 책임은 사용자가 진다[2].
PaaS의 개념도는 다음 [그림 4]과 같다.
<그림 4> Platform asaService

-11-
제 3절 클라우드 스토리지
클라우드 컴퓨팅 서비스 중에서 스토리지 서비스는 클라우드 스토리지(Cloud
Storage)또는 DaaS(DataasaService)라는 용어로 표현된다.클라우드 스토리지
는 네트워크를 통하여 가상화된 스토리지 자원을 사용자의 요구에 따라 제공하는
것으로 일반적으로 대규모 확장이 가능하고,특정 지리적 위치에 고정되지 않으며,
사용 시스템을 기반으로 하고,사용하거나 또는 할당된 스토리지 용량에 따른 가격
정책을 사용하며,애플리케이션에 유연한 특징 등을 가지고 있다.
Symantec에서 발표한 “StateoftheDataCenterReport2008”에 따르면 전 세계
21개국의 1,600개 기업의 데이터 센터를 대상으로 실시한 조사에서 기업의
ERP(Enterprise Resource Planning),CRM(Customer Relationship Management),
데이터 마이닝과 분석 등과 같은 기업 애플리케이션들과 특히 웹 애플리케이션에
의해 요구하는 스토리지 용량이 계속해서 증가하고 있는 것으로 나타난 반면,실제
로 스토리지 활용률은 55% 정도로 측정되고 있다.따라서 이러한 스토리지 활용률
을 높이기 위한 방안으로 스토리지 가상화 또는 클라우드 스토리지 등을 고려하고
있는 것으로 조사되었다.
클라우드 스토리지를 구축하기 위해서는 스토리지 가상화 기술이 필요하다.따라
서 클라우드 스토리지는 이기종 스토리지 통합,데이터 마이그레이션,백업,중복
데이터 제거,장애 복구 등과 같은 서비스를 네트워크를 통하여 사용자에게 제공하
는 것이라고 할 수 있다.
클라우드 스토리지는 보통 다음과 같은 특성을 가진다.첫째,대규모 확장이 가능
하다.둘째,지리적 위치에 고정되지 않는다.셋째,상용 시스템을 기반으로 한다.
넷째,사용하거나 또는 할당된 스토리지 용량에 따른 가격 정책을 갖는다.다섯째,
응용에 적용하기 쉽다.
클라우드 스토리지는 트랜잭션 기반의 데이터베이스 또는 일시적인 저장소 보다

-12-
는 예측할 수 없는 저장 공간 확장과 값싸고 오랫동안 저장할 수 있으며 접근하기
간단한 저장소로 적당하다.
클라우드 스토리지를 이용하기 위해서는 사용자가 클라우드 스토리지 서비스에서
제공하는 API를 가지고 요구하는 응용을 개발해야 하는 작업이 필요하다.하지만
최근에는 NFS,CIFS,FTP와 같은 표준 프로토콜을 통하여 스토리지를 접근할 수
있는 서비스를 제공하기도 한다.또는 클라우드 스토리지와 CDN을 통합함으로써
CDN상의 가장 가까운 위치에서 스토리지를 접근할 수 있는 서비스를 제공한다.
클라우드 스토리지의 장점은 비용을 절약할 수 있다는 것이다.임대하여 저장된
데이터의 용량만큼의 비용을 지불하는 서비스와 데이터 이동량에 따라 비용을 지불
하는 서비스가 있다.클라이언트 소프트웨어를 사용하여 백업을 설정할 수 있으며,
WAN을 통해 데이터를 전송할 수 있다.단점으로는 대역폭에 따라 성능이 좌우될
수 있으며 스토리지의 가용성에 심각한 문제가 있을 수 있다.클라우드 스토리지는
스토리지 공급자간의 네트워크 연결에 의존하기 때문에 네트워크 연결 등 글로벌
네트워크 중단 등의 문제에 영향을 받을 수 있다[5,6].
CloudStorage의 개념도는 다음 [그림 5]와 같다.
<그림 5> CloudStorage

-13-
제 3장 HybridStorageAPI의 설계
제 1절 전체시스템의 구성
본 논문에서는 저 비용으로 운영 가능한 Storage기술을 확보하고 OpenSource
기반의 StorageSolution을 도입하여 다양한 사업 확장에 적용할 수 있는 기반을
마련하기 위해 연구를 시작하였다.
POC(ProofofConcept)를 위한 최소 시스템 구성을 원칙으로 하며,성능 및 안정
성 테스트를 위해 기존 CloudSystem,상용 Network및 운영 장비를 분리하여 구
성하였다.
Hybrid Storage Access Server(HSAS)는 전면에 클라이언트를 위한 단일
API(HTTP 기반 Request/Response방식)를 제공하고 이면에는 다중 Storage고유
의 StorageAdaptor를 구현하였다.
HSAS는 RESTful방식 또는 POSIX 방식으로 제공되는 이기종 Storage를 한데
묶어 클라이언트에 단일한 공용의 API를 제공하는 HybridStorageGateway 역할
을 수행한다.
HybridStorage시스템 구성도는 다음 [그림 6]과 같다.
<그림 6> HybridStorage시스템 구성도

-14-
HybridStorage시스템을 구성하는 구성요소는 다음 [표 4]와 같다.
구성요소 설 명 비고
SKT EasyStorage
아마존 S3 API와 호환되는 RESTful기반의 API
제공하는 Storage서비스[7]
OpenStackSwift
아마존 S3와 유사하며 자체 이중화와 Failover기
능 지원하는 Storage[8]
RedhatGluster
오픈 소스 기반의 ScaleOut방식의 NAS
MetaServer가 필요없고 Scale-out한 파일 시스템
으로 모듈 구조[9]
HybridStorageAccess
Server
StorageGateway기능과 HybridAPI를 통해 서비
스를 제공하는 서버
CloudOpenAPIServer
Open Platform을 위한 South Bound을 구현한
OpenAPI서버
CloudOpenAPIDB OpenAPI처리를 위한 Database
CloudPOC Server
Open API및 Hybrid Storage Access Server와
Cloud시스템과의 연동
CloudMetaDB CloudMeta정보를 저장하고 있는 Database
Client
Storage및 API성능 테스트 툴
혹은 Hybrid Storage Access Server를 연동되는
시스템
[표 4]HybridStorage시스템 구성요소

-15-
1.파일 업로드 절차
User는 HSAS에 파일 업로드 요청을 하고 파일을 Storage에 업로드 한다.파일
업로드가 완료되면 HSAS는 Cloud POC 서버를 통해 업로드된 파일에 대한
Metadata를 저장한다.파일 업로드 시나리오는 다음 [그림 7]과 같다.
<그림 7> 파일 업로드 시나리오

-16-
2.파일 다운로드 절차
User는 CloudOpenAPI서버를 통해 파일 다운로드를 위한 token을 발급 받는다.
발급받은 token을 이용하여 USER는 HSAS에 파일 다운로드를 요청하고 storage에
서 파일을 다운로드한 후 종료한다.파일 다운로드 시나리오는 다음 [그림 8]과 같
다.
<그림 8> 파일 다운로드 시나리오

-17-
3.파일 목록 조회 절차
User는 Cloud Open API서버에 파일 목록 조회 요청을 한다.Cloud Open API
서ㅓ는 CloudPOC서버를 통해 MetaDatabase를 조회하여 파일 목록을 획득한 후
User에게 전달한다.파일 목록 조회 시나리오는 다음 [그림 9]와 같다.
<그림 9> 파일 목록 조회 시나리오

-18-
제 2절 HybridStorageAPI시스템 구성
HybridStorageAPI의 개념도는 다음 [그림 10]과 같다.
<그림 10> HybridStroageAPI개념도
Hybrid Storage API는 다수의 Storage연동절차를 Wrapping하고 기능을
Encapsulation하고 User에게 단일한 방법으로 Storage에 대한 업로드 및 다운로드
기능을 제공하는 것이므로 특정 Storage에 의존성에서 벗어나 확장 가능한 구조를
제공하게 된다.
Hybrid Storage Access Server(HSAS)는 Hybrid Storage API을 기반으로
InboundHandler,Controller및 OutboundHandler개념을 사용해서 각 Storage별
Adaptation을 지원함으로써 파일 업로드 및 다운로드 기능을 구현하였다.
그리고 Storage가 제공하는 API호출을 위한 과정을 단순화시켜 Storage별 서

-19-
비스 추가가 용이한 구조를 갖추는데 초점을 맞추어 설계 되었다.
HybridStorageAccess서버의 구조 개념도는 다음 [그림 11]과 같다.
<그림 11> HybridStorageAccess서버 구조
1.InboundHandler구간
User와 HSAS간 연동은 Inbound Handler에서 처리한다. User가 Inbound
Handler을 통해 업로드가 성공한 파일은 OutboundHandler에 의해 지정된 Storage
에 저장된다.User가 요청한 다운로드는 InboundHandler에 의해 1차적으로 분기되
고 지정된 Storage를 통해 파일을 획득하면서 동시에 User로 다운로드 시킨다.
2.OutboundHandler구간
각 Storage별 Handler가 Adaptation형태로 존재한다.User가 지정한 Storage로

-20-
업로드 하거나 지정된 Storage로부터 다운로드한다.
3.Controller구간
Controller는 InboundHandler와 OutboundHandler사이의 데이터 흐름을 관리
하고 통제한다.
4.연동 프로토콜 방식 및 송수신 전문
User 연동 프로토콜로써 REST 메시지를 처리한다.REST(Representational
StateTransfer)는 ROA(ResourceOriented Architecture)를 따른 웹서비스 디자인
표준이다.
HTTP를 기반으로 다음과 같은 Method를 제공한다.
첫째,리소스 조회를 위한 GET,둘째,리소스 갱신을 위한 PUT,셋째,리소스 생
성을 위한 POST,넷째,리소스 삭제를 위한 DELETE다.
HybridStorageAPI의 개발항목 리스트는 다음 [표 5]와 같다.
1.OutboundHandler개발항목
1.1 EasyStorageFileUpload/Download
1.2 SwiftFileUpload/Download
1.3 GlusterFileWriting/Reading
2.InboundHandler개발항목
2.1 사용자 요청 및 응답 기능
3.HybridStorageAPI(Controller)
3.1 사용자 요청에 대한 분기와 통계
4.StorageCommonFunction
4.1 Storage별 인증방식 구현
[표 5]HybridStorageAPI개발항목

-21-
제 3절 HybridStorageAPI시스템 연동 인터페이스 구성
구간별 연동 인터페이스 및 프로토콜에 대한 정의를 한다.Hybrid StorageAPI
인터페이스의 개념도는 다음 [그림 12]와 같다.
<그림 12> HybridStorageAPI인터페이스 정의
총 5개의 인터페이스로 구성되어 있으며,각각의 정의는 다음 [표 6]과 같다.
인터페이스 정의
IF_USER_COA: Request (HTTP) /
Response(XML)
Client와 CloudOpenAPI서버 구간
IF_USER_HSA:Request(HTTP)/
Response(XML)
Client와 Hybrid StorageAccess 서버 구간,
Upload는 Multipart로
IF_HSA_STRG:Request(HTTP)/
Response(XML)
Hybrid Storage Access 서버와 Storage서버
구간
IF_HSA_CC: Request (HTTP) /
Response(XML)
HybridStorageAccess서버와 CloudPOC 서
버 구간
IF_COA_CC: Request (HTTP) /
Response(XML)
Cloud Open API서버와 Cloud POC 서버 구
간
[표 6]인터페이스 구성
IF_USER_HSA, IF_HSA_STRG에 대해서 포함을 하며, IF_USER_COA,

-22-
IF_COA_CC,IF_HSA_CC에 대해 포함하지 않는다.포함되지 않는 인터페이스는
필요한 서비스별로 별도의 프로토콜을 개발하는 것으로 여기서는 개념만을 공유한
다.
1.IF_USER_HSA
FILE_UP_HSA :Cloud의 HybridStorage에 파일을 Upload하기 위한 연동 규격
이다.상세 정의는 다음 [표 7]과 같다.
Protocol REST
Resource-Catego
ryURI
/token조회를 통하여 전달받은 URL을 통해 업로드 한다.
enctype="multipart/form-data", method="post"방식으로 전달해야
한다.
업로드 요청시 storagetype을 전달해야 한다.
HTTP Method POST
Pre-Conditions N/A
Post-Conditions N/A
Idempotent Y
Security N/A
Authentication PRIVATE
Multipart Y
T hrottling
Policy
Policy Description
Application N/A
User N/A
Public N/A
Owner(email)
[표 7]FILE_UP_HSA Overview

-23-
FILE_UP_HSA RequestScheme의 정의는 다음 [표 8]과 같다.
Parameters
Name
Data
Type
Mandatory Description
Remar
ks
storage String
Easy storage-> ES,Switft-> SW,
Cluster-> GL
Payloads
Name
Data
Type
Remar
ks
N/A
PayloadSchema(XSD)
N/A
XML Format
N/A
[표 8]FILE_UP_HSA RequestDefinition
FILE_UP_HSA ResponseScheme의 정의는 다음 [표 9]와 같다.
Parameters
Name
Data
Type
Remar
ks
N/A
Schema(XSD)
N/A
XML Format
N/A
[표 9]FILE_UP_HSA ResponseDefinition

-24-
FILE_UP_HSA ErrorCode의 정의는 다음 [표 10]과 같다.
Code Messages HTTP StatusCode
403 Forbidden 403Forbidden
404 NotFound 404NotFound
408 RequestTimeout 408RequestTimeout
500 InternalServerError 500InternalServerError
502 BadGateway 502BadGateway
504 GatewayTimeout 504GatewayTimeout
[표 10]FILE_UP_HSA ErrorCode
FILE_DW_HSA :Cloud의 HybridStorage에 존재하는 파일을 다운로드하기 위
한 규격이며 상세한 정의는 다음 [표 11]과 같다.
Protocol REST
Resource-Catego
ryURI
/images,/music,/movies,/documents API등을 통하여 획득한
downloadURL이다.
HTTP Method GET
Pre-Conditions N/A
Post-Conditions N/A
Idempotent Y
Security N/A
Authentication PRIVATE
Multipart Y
T hrottling
Policy
Policy Description
Application N/A
User N/A
Public N/A
Owner(email)
[표 11]FILE_DW_HSA Overview

-25-
FILE_DW_HSA RequestScheme의 정의는 다음 [표 12]과 같다.
Parameters
Name
Data
Type
Remar
ks
N/A
Payloads
Name
Data
Type
Remar
ks
N/A
PayloadSchema(XSD)
N/A
XML Format
N/A
[표 12]FILE_DW_HSA RequestDefinition
FILE_DW_HSA ResponseScheme의 정의는 다음 [표 13]과 같다.
Parameters
Name
Data
Type
Mandatory Description Remarks
N/A
Schema(XSD)
N/A
XML Format
N/A
[표 13]FILE_DW_HSA ResponseDefinition

-26-
FILE_DW_HSA ErrorCode의 정의는 다음 [표 14]와 같다.
Code Messages HTTP StatusCode
403 Forbidden 403Forbidden
404 NotFound 404NotFound
408 RequestTimeout 408RequestTimeout
500 InternalServerError 500InternalServerError
502 BadGateway 502BadGateway
504 GatewayTimeout 504GatewayTimeout
[표 14]FILE_DW_HSA ErrorCode
2.IF_HSA_STRG
FILE_UP_ES :EasyStorageFileUploadRequest/Response
FILE_UP_ES에 대한 RequestParameter의 정의는 다음 [표 15]와 같다.
Required Parameter Format Description Remarks
Y BucketName String Object를 Upload할 Bucket이름
Y Key String Upload할 Object이름
Y Object file Upload할 File
[표 15]FILE_UP_ES RequestParameter
-RequestSyntax
PUT /KeyHTTP/1.1
Host:BucketName.es.tcloudbiz.com
Authorization:signatureValue
Date:date
Content-MD5:3+S1ojLTkRGOHQwv50kfsg==
Content-Type:application/octec-stream
Content-Length:Length
-RequestBody

-27-
ObjectData
-Responsesample
HTTP/1.1200OK
x - a m z - i d - 2 :
gyB+3jRPnrkN98ZajxHXr3u7EFM67bNgSAxexeEHndCX/7GRnfTXxReKUQF28IfP
ETag:7a7ec6062e6f7d92062811334d5ff342
Date:Mon,24Sep201207:29:34GMT
Accept-Ranges:bytes
Server:Restlet-Framework/2.0.8
x-amz-request-id:22264198756838A9
Access-Control-Allow-Origin:*
x-amz-version-id:
Content-Length:0
PUT /KeyHTTP/1.1
Date:date
Content-MD5:3+S1ojLTkRGOHQwv50kfsg==
Content-Type:application/octec-stream
Content-Length:Length

-28-
FILE_DW_ES:EasyStorageFileDownloadRequest/Response
FILE_DW_ES에 대한 RequestParameter의 정의는 다음 [표 16]과 같다.
Y BucketName String Object를 Upload할 Bucket이름
Y Key String Upload할 Object이름
N Range Integer 부분 데이터 지정
[표 16]FILE_DW_ES RequestParameter
-RequestSyntax
GET /KeyHTTP/1.1
Date:date
Content-Type:application/x-www-form-urlencoded;charset=utf-8
-Responsesample
HTTP/1.1200OK
x-amz-id-2:
gyB+3jRPnrkN98ZajxHXr3u7EFM67bNgSAxexeEHndCX/7GRnfTXxReKUQF28IfP
Last-Modified:Mon,24Sep201207:29:34GMT
ETag:"7a7ec6062e6f7d92062811334d5ff342"
Accept-Ranges:bytes
Server:Restlet-Framework/2.0.8
Vary:Accept-Charset,Accept-Encoding,Accept-Language,Accept
x-amz-request-id:99ED88EG5895DC46
Access-Control-Allow-Origin:*
Content-Type:application/octet-stream
Content-Length:594427

-29-
-ResponseBody
ObjectData
FILE_AUTH_SW :SWIFT AuthenticationRequest/Response
FILE_AUTH_SW에 대한 RequestParameter의 정의는 다음 [표 17]과 같다.
Y host String 인증 서버 URL
Y X-Storage-User String UserID
Y X-Storage-Pass String APIKey
[표 17]FILE_AUTH_SW RequestParameter
-RequestSyntax
GET /auth/<apiversion> HTTP/1.1
Host:인증 서버
X-Storage-User:UserID
X-Storage-Pass:APIKey
FILE_AUTH_SW에 대한 ResponseHeader의 정의는 아래 [표 18]과 같다.
Y X-Storage-Url String 스토리지 서비스 URL
Y X-Auth-Token String
스토리지 서비스 사용 인증을
위한 토큰
[표 18]FILE_AUTH_SW ResponseHeaders

-30-
-Responsesample
HTTP/1.1200OK
Server:nginx/1.1.14
Content-Length:126
Connection:keep-alive
X-Storage-Url:
https://ssproxy.ucloudbiz.olleh.com/v1/AUTH_a8b9c2b7-f6c3-4d3d-a4e9-ee04332652a5
X-Storage-Token:AUTH_tkfc98e1a2275e4d64aea58bf9295f87b3
X-Trans-Id:txbf2c8d34341a4a5497e955f2cc9d3725
X-Auth-Token:AUTH_tkfc98e1a2275e4d64aea58bf9295f87b3
FILE_UP_SW :SWIFT FileUploadRequest/Response
FILE_UP_SW에 대한 RequestParameter의 정의는 다음 [표 19]과 같다.
Y Host String 스토리지 서비스 URL
Y X-Auth-Token String 사용자 인증 토큰
Y Content-Type String Object형식
Y Content-Length String Object크기
Y Object ObjectData
[표 19]FILE_UP_SW RequestParameter

-31-
-RequestSyntax
PUT /<apiversion>/<account>/<container>/<object> HTTP/1.1
Host:StorageServiceServer
X-Auth-Token:AuthenticationToken
Content-MD5:bmhiQvUStNzddyWKob4Svg==
-RequestBody
ObjectData
-Responsesample
HTTP/1.1201Created
Content-Length:18
Content-Type:text/html;charset=UTF-8
ETag:6e686242f512b4dcdd77258aa1be12be
X-Trans-Id:tx6b08892a99e9465e9067cb86c9046f2c

-32-
FILE_DW_SW :SWIFT FileDownloadRequest/Response
FILE_DW_SW에 대한 RequestParameter의 정의는 다음 [표 20]과 같다.
Y Host String 스토리지 서비스 URL
Y
X-Auth-Toke
n
String 사용자 인증 토큰
N Range Integer 부분 데이터 지정
[표 20]FILE_DW_SW RequestParameter
-RequestSyntax
GET /<apiversion>/<account>/<container>/<object> HTTP/1.1
Host:StorageServiceServer
X-Auth-Token:AuthenticationToken
-Responsesample
HTTP/1.1200OK
ETag:6e686242f512b4dcdd77258aa1be12be
Accept-Ranges:bytes
X-Trans-Id:tx082bc4b037ea4cf08fa146a2593df75e
-ResponseBody
ObjectData

-33-
FILE_UP_GL:POSIX기반의 FileI/O을 사용해서 구현한다.
publicvoidwriteFile(){
Stringlocation=ConfigManager.getConfig().getGLRoot();
try{
StringfileLocationAndFileName=location+fileUpload.getFilename();
FileOutputStream fos = new
FileOutputStream(fileLocationAndFileName);
FileChannelfileChannel=fos.getChannel();
FileInputStream is=new FileInputStream(fileUpload.getFile());
//Noencryption-usezero-copy.
finalFileRegion region = new DefaultFileRegion(is.getChannel(),0,
is.available());
region.transferTo(fileChannel,region.getPosition());
fileChannel.close();
fos.close();
is.close();
listener.onStorageRequestSuccess(createObjectID(ConfigManager.getConfig().getStorage
Gluster()));
}catch(Exceptione){
e.printStackTrace();
}
}

-34-
privatevoidwriteResponseDownload(StringfileName)throwsCommonException{
try{
File file = new File(ConfigManager.getConfig().getGLRoot() +
fileName);
String lastModified = ServiceUtils.formatRfc822Date(new
Date(file.lastModified()));
Extentextent=getExtent(file.length());
HttpResponse clientResponse = new
DefaultHttpResponse(HttpVersion.HTTP_1_1,HttpResponseStatus.OK);
clientResponse.setHeader(HttpHeaders.Names.LAST_MODIFIED,
lastModified);
clientResponse.setHeader(HttpHeaders.Names.ACCEPT_RANGES,
HttpHeaders.Values.BYTES);
clientResponse.setHeader(HttpHeaders.Names.ETAG,
generateETag(lastModified,file.length()));
clientResponse.setHeader(HttpHeaders.Names.CONTENT_TYPE,
"application/octet-stream");
clientResponse.setHeader(HttpHeaders.Names.CONTENT_LENGTH,
file.length());
clientResponse.setHeader("Content-Disposition",
"attachment;filename="+file.getName());
writeResponse(channel,clientResponse);
FileInputStream fis=new FileInputStream(file);
final FileRegion region = new DefaultFileRegion(fis.getChannel(),
extent.getStart(),extent.getEnd());
ChannelFuturefuture=channel.write(region);
future.addListener(new ChannelFutureListener(){
publicvoidoperationComplete(ChannelFuturefuture){
FILE_DW_GL:POSIX기반의 FileI/O을 사용해서 구현한다.

-35-
if(region!=null){
region.releaseExternalResources();
listener.onDownloadComplete(ResultCode.SUCCESS);
}
}
});
}catch(FileNotFoundExceptione){
e.printStackTrace();
}
}

-36-
도입장비 용도 주요스펙 비고
S t o r a g e
Servers
POC 테스트용 스토리지 서
버
* Open Stack 기준
(2RU)
Xeon 2609(1 CPU),
12G RAM
3Tbyte SATA X 12
Disk (No RAID)
Dual or Quad
Ethernet(1G)
Dual Redundant
Power
* Gluster 기준(1RU)
Xeon 2609(2 CPU),
32G RAM
500G SATA X 2
(RAID 1, OS용)
Dual Ethernet(10G)
+1 Ethernet
SAS/SATA RAID
card
Dual Redundant
Power
JBOD 디스크 스토리지 Expender 3Tbyte SATA X
[표 21]HybridStorageAPI하드웨어 구성
제 4장 실험환경 및 결과
제 1절 HybridStorageAPI시스템 개발환경
본 논문에서 제안하는 시스템은 현재 CloudService에서 운용되는 환경과 별도로
구성을 하며 연구의 특성을 반영하여 다음 [표 21]과 같다.

-37-
*Gluster POC에서만 도입
12(or 24) Disk
Dual SAS
Interface(3Gbps)
Dual Storage
Controller
Dual Redundant
Power
Storage Front
Switch
Cloud Backbone(L3,
CISCO 6xxx) 스위치와
cascade 연결
48 port 1G Ethernet
L2 Switch /w 4 port
SPF(up to 10G)
(Cisco 3560 또는 동
급)
* Gluster의 경우 10G
지원 필요
S t o r a g e
B a c k e n d
Switch
스토리지 서버간 연동 전용
스위치
(Storage front switch
와 동급)

-38-
제 2절 연동규격 및 절차
본 논문에서는 별도의 화면을 제공하는 시스템의 특성상 HybridStorageAPI의
결과 도출을 위하여 연동 규격별 절차 및 테스트 결과를 도출하였다.
1.파일 업로드 절차
파일 업로드 시나리오 구현을 위한 SequenceDiagram은 다음 [그림 13]과 같다.
<그림 13> 파일 업로드 SequenceDiagram

-39-
2.파일 다운로드 절차
파일 다운로드 시나리오 구현을 위한 SequenceDiagram은 다음 [그림 14]와 같
다.
<그림 14> 파일 다운로드 SequenceDiagram

-40-
3.파일 목록 조회 절차
파일 목록 조회 시나리오 구현을 위한 SequenceDiagram은 다음 [그림 15]와 같
다.
<그림 15> 파일 목록 조회 SequenceDiagram

-41-
제 3절 업로드 및 다운로드 테스트
ApacheJmeter를 사용하여 멀티 업로드 및 다운로드를 테스트하였다.테스트를
위한 스레드 수와 업로드 및 다운로드,결과에 대한 개요는 다음 [표 22]와 같다.
StorageType 스레드수 업로드/다운로드 결과
Easystorage 30 Upload Success:30,Failed:0
Swift 30 Upload Success:30,Failed:0
Gluster 30 Upload Success:30,Failed:0
3개 Storage동시 요청 20:20:20 Upload Success:60,Failed:0
EasyStorage 20 Download Success:20,Failed:0
Swift 20 Download Success:20,Failed:0
Gluster 20 Download Success:20,Failed:0
3개 Storage동시 요청 20:20:20 Download Success:60,Failed:0
[표 22]업로드 및 다운로드 테스트 개요

-42-
1.성능 테스트
UploadTest는 30개의 스레드를 통해 시험 하였다.
EazyStorageUpload시험결과는 다음 [표 23]과 같다.
Sample
no
Start
Time
Thread
name
Label Sampletime(ms) Status Bytes
1 16:46:53.478 ThreadGroup1-8 HTTPRequest 80098 Success 80
….
[표 23]EasyStorageUpload시험결과

-43-
SwiftUpload시험결과는 다음 [표 24]와 같다.
Sample
no
Start
Time
Thread
name
Label Sample time(ms) Status Bytes
1 14:50:56.927 Thread Group 1-10 HTTP Request 87023 Success 80
…
[표 24] Swift Upload 시험결과

-44-
GlusterUpload시험결과는 다음 [표 25]와 같다.
Sample
no
Start
Time
Thread
name
…
[표 25]GlusterUpload시험결과
25MB 용량의 동영상 파일을 통해 업로드를 요청한 결과이며,Sampletime(ms)
를 확인해 보면 OutboundHandler를 거치지 않는 GLUSTER의 속도가 더 빠른 것
을 확인할 수 있다.

-45-
DownloadTest는 20개의 스레드를 통해 시험 하였다.
EazyStorageDownload시험결과는 다음 [표 26]과 같다.
Sample
no
Start
Time
Thread
name
…
[표 26]EasyStorageDownload시험결과

-46-
SwiftDownload시험결과는 다음 [표 27]과 같다.
Sample
no
Start
Time
Thread
name
…
[표 27]SwiftDownload시험결과

-47-
GlusterDownload시험결과는 다음 [표 28]과 같다.
Sample
no
Start
Time
Thread
name
…
[표 28]GlusterDownload시험결과
1MB 미만의 이미지 파일을 대상으로 다운로드 테스트한 결과이며,업로드와 마
찬가지로 OutboundHandler를 거치지 않는 GLUSTER의 속도가 일반적으로 빠른
성능을 보였다.

-48-
2.HybridStorageAPI의 기술 검증 결과
Storage상호간 연동방식 비교는 다음 [표 29]와 같다.
RESTful방식 HTTP기반 연동방식 파일 시스템기반 연동방식
EMC ATMOSStorage
EasyStorage
SwiftStorage
GLUSTER
[표 29]Storages상호간 연동방식 비교
ATMOS,Easy,SwiftStorages는 RESTful방식 HTTP기반 연동방식을 사용하는
공통점을 가지고 있다.RESTful방식 HTTP기반 연동방식은 전통적인 HTTP기반
연동을 통한 전문교환 방식에 비해 더 간결한 전문방식과 POST,GET,PUT,
DELETE와 같은 HTTP명령을 INSERT,SELECT,UPDATE,DELETE과 동일한
목적으로 사용하는 것을 말한다.
GLUSTER는 SAN(StorageAreaNetwork)과 유사한 연동방식으로 Storage을 운
영체제에 mount시킴으로써 로컬 드라이브처럼 사용하는 파일 시스템기반 연동방식
을 사용하고 있다.
RESTful방식 HTTP기반 연동방식으로 제공되는 Storages가 파일 시스템기반 연
동방식인 GLUSTER에 비해 보다 느슨한 형태(Decoupled)의 시스템 통합성을 제공
하는 것으로 평가된다.
상호간 프로토콜 유사성 및 차이점 기술검증은 다음과 같이 진행하였다.첫째
HTTP명령어 사용방식 유사성과 차이점 비교,둘째 파일처리방식의 유사성과 차이
점 비교,셋째 업로드 및 다운로드 트랜잭션에 따른 인증방식의 차이점 비교,넷째
Signature생성방식 비교,다섯째 사용자 인증방식 비교,여섯째 Signature세션유

-49-
ATMOS -Upload Swift-Upload Easystorage-Upload
POST /rest/objects/
HTTP/1.1
Host:storage.tcloud.co.kr
Date: Thu, 27 Sep 2012
01:58:01GMT
C on ten t- T y p e:
application/octet-stream
x-emc-uid:UID
x-emc-listable-meta:
Metadata
x-emc-signature:Signature
P U T
/version/account/container/file
nameHTTP/1.1
Host:10.10.76.55
Date: Fri, 12 Oct 2012
08:01:12GMT
C o n te n t- M D 5 :
bmhiQvUStNzddyWKob4Svg=
=
X-Auth-Token:Signature
PUT /filenameHTTP/1.1
H o s t :
bucketName.es.tcloudbiz.com
Date: Mon, 24 Sep 2012
07:29:32GMT
C o n te n t- M D 5 :
en7GBi5vfZIGKBEzTV/zQg==
C o n ten t- T y p e:
Authorization:Signature
ATMOS -Download Swift-Download
Easystorage-
Download
GET /rest/objects/objectID
HTTP/1.1
Date: Thu, 27 Sep 2012
02:00:14GMT
x-emc-uid:UID
G E T
/version/account/container/file
nameHTTP/1.1
Host:10.10.76.55
Date: Fri, 12 Oct 2012
07:59:31GMT
C on ten t- T y p e:
GET /filenameHTTP/1.1
H o s t :
bucketName.es.tcloudbiz.com
Date: Mon, 24 Sep 2012
07:48:22GMT
C o n ten t- T y p e:
[표 30]Storage상호간 프로토콜 차이점
효시간의 관점으로 진행하였다.
Storage상호간 프로토콜의 차이점은 다음 [표 30]과 같다(GLUSTER 제외).

-50-
ATMOS Storage SwiftStorage Easystorage
POST /rest/objects/
HTTP/1.1
PUT
/version/account/container/f
ilenameHTTP/1.1
PUT /filenameHTTP/1.1
H o s t :
bucketName.es.tcloudbiz.co
m
파일 Upload성공 후
ATMOS Storage로부터 회
신하는 매회 발급된 Object
ID가 해당 파일을 대표하기
때문에 동일 위치에 동일파
일을 올리면 매번 신규파일
로 인식됨
디렉터리 개념이 없음
동일 파일저장위치에 동일
파일명을 Upload하면
Overwrite됨
/container는 Upload 대상
folder명임
동일 파일저장위치에 동일
파일명을 Upload하면
Overwrite됨
bucketName은 Upload대상
folder명임
[표 32]파일처리방식의 차이점
RESTful방식 HTTP명령어 사용방식 차이점의 기술평가 결과는 차이점은 없으며
(업로드 기능에 있어 HTTP명령어 사용에 따른 차이점은 RESTful사용범위에서
인정가능)차이점 비교는 다음 [표 31]과 같다.
POST명령 (업로드)
GET명령 (다운로드)
PUT명령 (업로드)
PUT명령 (업로드)
[표 31]RESTful방식 HTTP명령어 사용방식 차이점
파일처리방식의 차이점의 기술평가 결과는 파일저장위치를 지정하여 Upload하는
방식은 유사하지만 파일처리방식에 차이가 있으며,차이점 비교는 다음 [표 32]와
같다.

-51-
x-emc-uid:UID
P U T
/version/account/container/f
ilenameHTTP/1.1
Cloud 기존 시스템으로부터
획득한 사용자 정보(UID,
Password)와 HTTP헤더를
암호화해서 Signature값을
생성
Swift Storage로부터 인증
과정(하기 인증절차 참고)에
서 획득한 사용자 정보
(Account값)과 Signature값
을 그대로 사용해야 함
Easy Storage로부터 획득한
사용자 정보(Access Key
ID,SecretAccess Key)와
HTTP 헤더를 암호화해서
Signature값을 생성
[표 33]업로드/다운로드 트랜잭션에 따른 인증방식의 차이점
업로드/다운로드 트랜잭션에 따른 인증방식의 차이점의 기술평가 결과는
Signature생성 및 획득방식에 차이가 있으며(UID는 UserID를 지칭함)차이점 비
교는 다음 [표 33]과 같다.
Signature생성방식 기술평가 결과는 ATMOS Storage와 Easy Storage는 매 요
청마다 HTTP Header의 요청 정보 문자열을 HmacSHA1 알고리즘을 이용해서
byte배열로 만들고 Base64 Encoding을 통해 생성한 Signature 값을 트랜잭션에
포함해야 하지만,이와는 다르게 SwiftStorage는 사용자 인증절차를 통해 획득한
Signature값을 그대로 사용해야 한다는 것이다.
사용자 인증절차 기술평가 결과는 ATMOS Storage는 서비스 서버에서 제공하는
HTTP규격에 의해 수행 하여야 하며,EasyStorage는 EasyStorage웹 관리자 페
이지에서 표출된 AccessKey ID와 SecretAccessKey를 UserID와 Password을
사용해서 사용자 인증절차를 수행하고 향후 AccessKey ID,SecretAccessKey
획득을 위한 연동이 필수적으로 요구된다는 것이다.

-52-
Request
POST /v2.0/tokensHTTP/1.1
Host:10.10.76.55
Content-Type:application/json
Accept:application/json
Content-Length:106
[Body-json]
{"auth": {"tenantName": "openstack", "passwordCredentials": {"username": "admin",
"password":"crowbar"}}}
Response
HTTP/1.1200OK
Content-Type:application/json
Vary:X-Auth-Token
Date:Fri,12Oct201207:54:05GMT
Transfer-Encoding:chunked
[Body-json]
{"access": {"token": {"expires": "2012-10-13T08:51:01Z", "id":
"af929499b80547e2bfafd5490102b6c5", "tenant": {"enabled": true, "id":
"3eee71dae03947709b1be1f1dfffc9e8", "name": "openstack"}}, "serviceCatalog":
[{"endpoints":[{"adminURL":"https://192.168.124.87:8080/v1/","region":"RegionOne",
" i n t e r n a l U R L " :
"https://192.168.124.87:8080/v1/AUTH_3eee71dae03947709b1be1f1dfffc9e8", "publicURL":
"https://10.10.76.55:8080/v1/AUTH_3eee71dae03947709b1be1f1dfffc9e8"}],
"endpoints_links": [], "type": "object-store", "name": "swift"}, {"endpoints":
[{"adminURL":"http://192.168.124.87:35357/v2.0","region":"RegionOne","internalURL":
"http://192.168.124.87:5000/v2.0", "publicURL": "http://10.10.76.55:5000/v2.0"}],
"endpoints_links":[],"type":"identity","name":"keystone"}],"user":{"username":
"admin","roles_links":[],"id":"0a5b2037771a4b09a5ba03438b5291cb","roles":[{"id":
SwiftStorage인증절차는 SwiftStorage와의 JSON전문을 사용한 HTTP규격은
다음과 같다.

-53-
"df79097e3b6f41b7a35e99ab605dfae1","name":"admin"}],"name":"admin"}}}
Signature값을 가져와 업로드/다운로드 트
랜잭션에서 그대로 사용
(af929499b80547e2bfafd5490102b6c5)
Account값을 가져와 업로드/다운로드 트
랜잭션에서 그대로 사용
(AUTH_3eee71dae03947709b1be1f1dfffc9e8)
[표 34]인증정보 Parsing예시
사용자 인증절차 수행시 필요한 업로드 및 다운로드 Parsing정보의 예시는 다음
[표 34]와 같다.
Signature세션유효시간은 ATMOS Storage와 EasyStorage는 최초에 한번 인증
절차를 수행하며,그 이유는 인증 후 세션유효시간이 정해져 있지 않기 때문이다.
그렇지만 SwiftStorage는 인증 후 24시간마다 세션이 만료되는 점에 유의해야 한
다.따라서 인증유효시간(세션만료시간)을 고려해서 매 6시간이 지난 요청에 대해
재 인증을 요청하도록 구현 하였다.
상호간 프로토콜 비교에 따른 결론은 HybridStorageAccess서버의 설계에서는
Storage별 연동기능을 Adaptation형태로 구현하는 것을 목표로 해야 한다는 것이
다.
비록 도입 Storages후보가 상이한 연동방식과 프로토콜을 사용하고 있지만 파일
처리방식,사용자 인증절차 수행방식,Signature생성방식 및 세션유효시간에 대한
유사성과 차이점을 상속과 다형성에 기반하여 작성함으로써 Storage별 연동기능을
Adaptor형태로 제공하는 방식인 Adaptation형태의 제공이 가능하다는 결론을 내렸
다.

-54-
제 5장 결론 및 향후과제
Hybrid Storage Access서버를 연동측면에서 분해하면 크게 Front-end와
Back-end연동으로 나눌 수 있다.
Front-end에서 서버와 단말 간 표준화된 통신규약은 외부 시스템과의 통신방식을
정의하는 것으로 기간계 시스템 연동규격을 사용하는 것이 바람직할 것이다.그렇
지만 서버와 서버 간 통신방식과 같은 이기종간 통신규약은 서비스를 제공하는
CP(ContentsProveder)의 기간계 시스템 연동규격에 호환되도록 작성하는 것이 바
람직하다.그러한 Front-end에서의 잘 정의된 통신규약은 보다 쉽고 신속히 Cloud
서비스의 확장을 보장한다.
반면에 Back-end에서 서버와 Storages간 서버와 내부서버 간의 통신규약은 확장
성보다 통합성에 주목해야 한다.특별히 서버와 Storage간 연동은 Storage연동규
격에 종속적이므로 Adaptation방식으로 규격화된 StorageAdaptor에 관한 인터페이
스를 규약하고 구현함으로써 HybridStorageAPI서버에 추가하는 과정이 매우 중
요하다.
결론적으로 향후 HybridStorageAPI서버의 상용화를 위해 필요한 향후 과제는
다음과 같다.
구조적 측면에서 HybridStorageAPI서버 구현으로 네트워크 및 통신 프로토콜
에 최적화된 소프트웨어 구조를 마련하였지만 각 Storage 연동에 있어서 ID,
Password사용에 관해 하드코딩 된 매직 넘버가 존재해 왔다.
예를 들면 EasyStorage의 경우 ID,Password를 획득할 수 있는 구체적인 연동
규약이 존재하지 않은 것으로 확인되었기 때문에 Easy Storage웹 관리자 페이지
에 표출된 AccessKeyID와 SecretAccessKey을 고정하여 사용자 인증절차를 수
행하여 왔다.향후 AccessKeyID,SecretAccessKey획득을 위한 연동은 필수적
으로 요구된다.
구조적 측면에서 Back-end를 위해 Adaptation 방식으로 규격화된 Storage
Adaptor에 관한 인터페이스 규약의 정의가 필요하다.Storage접근에 관한 인증 및

-55-
권한,Storage실사용에 관한 구현과 예외 처리와 같은 실제적 기능구현이 요구된
다.
역학적 측면에서 Front-end상에서 외부 시스템과의 연동을 위해 OpenAPI의 한
종류로써 HybridStorageAccess기능의 제공을 위한 통신규약의 정의가 필요하다.
현재는 CloudopenAPI에 파일 리스트 조회,업로드 및 다운로드와 같은 일부기능
에 한정적으로 구현되어 있다.
외부 시스템과의 연동을 위한 OpenAPI는 단말과 서버간,서버와 서버간을 분리
하여 정의하는 것이 바람직할 것이다.그렇지만 통신규약의 기초는 동일하게 가져
감으로써 호환성을 유지하는 것이 요구된다.
발전적 측면에서 HybridStorageAccess서버는 Cloud서비스를 사용하는 내부와
외부 시스템으로 위치하고 CloudopenAPI서버와 함께 제공됨으로써 Storage의 접
근방법을 내부와 외부 시스템으로 분리하는 역할을 수행하도록 배치해야 할 것이
다.
한편 가입자 순증과 경쟁자와의 경쟁력의 확보를 위해 Storage용량 증설이 불가
피한 시기가 도래하였다.
본 논문을 통해 HybridStorageAccess서버에 관한 ProofofConcept을 구현하
고 검증하는 과정에서 도출된 문제점을 기초로 HybridStorageAccess서버의 필
요성을 증명하였다.그리고 이 지식을 기반으로 단말 및 외부시스템에서 서버 접속
시 단일 서버를 통해 다중 Storages로의 접근성을 제공하는 방식이 현행 Storage
종속에 관한 문제점을 개선할 수 있으며 Storage용량증설에 관한 시스템 통합 및
확장을 동시에 만족시킬 수 있을 것으로 판단된다.

-56-
참고문헌
[1]http://blog.naver.com/PostView.nhn?blogId=4900789&logNo=140167478314
[2]김형준,조준호,안성화,김병준,“클라우드 컴퓨팅 구현 기술”,에이콘.
[3]김일수,김재영,김새이,“HybridStorageAPI개발 완료 보고서”,2012.
[4]배리 소신스키,정원천,김양수,“클라우드 컴퓨팅 바이블”,길벗.
[5]김영철,차명훈,이상민,김영균,“클라우드 컴퓨팅에서 스토리지 가상화 기술
동향”,전자통신동향분석 제24권 제4호,2009.
[6]김영택,“Cloud최적화 StoragePlatform EMC Atmos”,DataCenterofthe
Future,2010.
[7]SK telecom,“EasyStorage”,2012.
[8]정기영,“OpenStackObjectStorageService”,2011.
[9]Gluster.com,“IntroductiontoGluster”,2010.
[10]김종대,“진화하는 클라우드 모바일의 변화를 이끈다”,2011.
[11]전성원,주윤철,김태웅,“클라우드 환경을 위한 대규모 분산 저장 시스템”,
TelecommunicationsReview 제21권 3호,2011.
[12]고대식,“클라우드 컴퓨팅을 위한 스토리지 가상화”,전자신문.
[13]최완,“SaaS플랫폼 및 페타스케일 클라우드 스토리지 기술 동향”,한국전자통
신 연구원,2012.
[14]황진경,“CloudObjectStorageServicebasedonOpenstack”,2011.
[15]김영철,박근태,이상민,김홍연,김영균,“클러스터 파일 시스템 기술 동향”,
전자통신동향분석 제22권 제6호,2007.
[16]크리수토퍼 M.모이어,정윤진 “개념,패턴,그리고 프로젝트 클라우드 기반 애
플리케이션 개발”,제이펍.
[17]http://www.ciokorea.com

-57-
[18]http://www.itworld.co.kr
[19]http://dev.kthcorp.com
[20]http://developer.ucloudbiz.olleh.com
[21]http://bcho.tistory.com
[22]http://www.ddaily.co.kr/cloud
[23]http://www.seagate.com/kr/ko/tech-insights
[24]http://www.ibm.com/developerworks/kr/cloud
[25]http://soooprmx.com
[26]http://www.betanews.net
[27]http://www.openstack.or.kr
[28]http://www.gluster.org

-58-
ABSTRACT
Bock-Chool,Lim
DepartmentofInformationScience
GraduateSchoolOf
JoongbuUniversity
SupervisedbyProf.Soon-GohnKim
Asfastaschangesoccurinthebusinessenvironmentandinadvancementsof
informationtechnology thecostofIT forcorporationshasalsobeenincreasing.
Assuch,reducing IT costwhileresponding appropriately tothefastchanging
environmenthasbecomeasurvivalrelationshipforallcorporateentities.Sucha
burdenhasbroughtaboutachangetothecorporationsparadigm forIT assets.
Thefactisthattheexisting paradigm ofownershipforIT assetsischanging
tooneofusage.
Sincethelate1980stheemergenceofoutsourcing SM ofIT operation,web
hosting,application serviceprovideretchasplayed arolein such achangein
the paradigm.In particular after 2007,as cloud computing service has been
introduced to the marketplace the trend ofIT assets being transformed from
havingownershipintoreceivingservicehasgraduallyproliferated.
As if to prove such a tendency,major IT companies,including Amazon,

-59-
Google,IBM,Microsoft,Yahooandothersareofferingcloudserviceafteranther
cloud service; recently, companies like Salesforce, Facebook, Youtube and
MyspacehavestartedofferingcloudcomputingservicetotheInternetusers.
Toexplainbrieflythefunctionalityandservicesthatthesecompaniesofferin
termsofcloud computing,Googlehasthetechnologiestomanagehundredsof
thousandsofserversandstoreandanalyzetensofpetabytesofdata,andparts
ofthesetechnologieshavebeen madeavailabletotheoutsideworldandsome
successful cases of cloud-based technology are currently being shared.In
addition,services,such as mail,calendar,documents,etc.,thatare used by
generalusersareoffered,andbyprovidingacloud-basedplatform servicecalled
‘AppEngine,’theplatform thatenablesimplementationofapplicationsdeveloped
by theusersundercloudenvironmentisbeing provided.Amazon offersvirtual
machines,storageetcthatarea partofan infrastructuresupportserviceand
Salesforce.com provides to corporate enterprises a customer relationship
managementCRM webapplicationservice.
Inthispaper,by introducing theconceptofhybridstorageasanideaforan
efficientoffering and operation ofstorage(IaaS,PaaS)among many areas of
computing we willattemptto proceed with the design ofAPIin order to
facilitatetheoffering ofvarioustypesofstoragesuch asOpen Stack,Gluster,
Atmosetcthatareprovided by cloud storagesystems.By designing ahybrid
storageAPIandpresentingresultsthroughabasicsystem flow wewillenable
theofferingofstorageunderacloudcomputingenvironment.

-60-
감사의 글
한창 공부에 목마름이 있을 때 우연찮은 기회에 김순곤 교수님을 만나 뵙게 되었
고,이로써 목말랐던 공부를 교수님의 지도하에 다시 시작하게 되었습니다.그 시간
이 흘러 벌써 2년이 지났습니다.시간이 어떻게 흘러갔는지도 모르게 너무 빠르게
흘러 간 것 같습니다.저에게 이런 기회를 주신 김순곤 교수님과 저를 지도해 주신
많은 분들게 지면을 빌어 감사의 마음을 전하고자 합니다.
늘 부족했던 저에게 따뜻한 관심과 애정 어린 질타로 배움의 길을 인도해 주시며
꿈과 희망을 안겨 주신 김순곤 지도교수님께 존경하는 마음과 더불어 깊은 감사를
드립니다.
그리고 바쁘신 와중에도 저의 논문심사를 맡아주시고,소중한 충고를 아끼지 않
으셨던 박인규 교수님,박종훈 교수님께 감사를 드립니다.
여러모로 부족한 저에게 본 논문이 완성되기까지 미비점을 지적하여 주시고,많
은 관심으로 지도와 조언을 아끼지 않으셨던 정복희 선배님과 최원영 교수님께 진
심으로 감사드립니다.
저에게 학업을 다시 시작할 수 있는 기회를 만들어 주신 임형도 수석님과 항상
어려움이 있을 때마다 정신적으로 도와주신 김일수 본부장님께도 감사를 드립니다.
시간적,정신적으로 학문의 어려움에 처했을 때 항상 곁에서 많은 아이디어와 용
기로 격려와 조언을 아끼지 않으셨던 많은 선배님과 동기 석사과정의 많은 분들께
도 깊은 감사를 드립니다.
본 논문을 작성하는데 있어,S통신사의 PM분들과 같이 프로젝트에 참여하여 많
은 도움을 주신 김재영책임,김새이주임께도 감사를 드립니다.
항상 시간이 없어 학업과 회사 생활을 하는 데에도 불편함이 없도록 도와주신 회
사 동료분들과 그룹장님,그리고 사장님께도 감사하다는 말씀을 지면을 빌어 전하
고 싶습니다.

-61-
또한 항상 어려움에도 저의 곁에서 불평 불만 없이 학업에 정진할 수 있도록 도
와준 아내 김정아,그리고 우리 두 아들에게도 감사의 마음을 전합니다.말씀은 안
하시지만 저에게 항상 힘이 되어 주시는 형님들,처제들,어머니,장모님,장인어른
께도 감사하다는 말씀을 드립니다.
이외에도 제가 미처 언급하지 못한 고마운 분들이 너무나 많습니다.그분들의 이
름 하나 하나를 되새기지 못함을 죄송하게 생각하며,앞으로 박사과정에서도 더욱
더 학문에 정진하여 저를 지켜봐 주시는 모든 분들의 기대에 어긋나지 않도록 최선
을 다하겠습니다.감사합니다.

000001560595_1425351208416_0.5687465614331808

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to 000001560595_1425351208416_0.5687465614331808

Similar to 000001560595_1425351208416_0.5687465614331808 (20)

000001560595_1425351208416_0.5687465614331808