- 파일 처리
- 파일 read : 압축/암호화할 파일 읽기
- 파일 write : 압축/암호화된 파일 생성
- 파일 압축
- 줄 압축 : 동일한 내용의 line이 반복될 경우 압축
- 내용 압축 : 한 line에서 동일한 문자가 반복될 경우 압축
- 파일 전송
- Line별 전송
- 오류 발생시 재전송
- 특정 line 전송
- 압축 알고리즘은 변경 가능해야 한다.
- 암호화 알고리즘은 변경 가능해야 한다.
- 다중 사용자에 대한 요청을 처리할 수 있어야 한다. : 서버의 처리량보다 사용자 요청이 많을 경우에도 처리가 가능해야 한다.
- 동일 파일에 대한 압축은 가능한 최소화한다. : 동일한 파일에 대해 동일한 알고리즘으로 압축/암호화 하는 것을 최소화하기 위해 압축/암호화 파일은 별도로 관리한다. 단, 관리하는 파일의 양은 적정 수준을 유지해야 한다.
- 대용량 파일 저장소는 확장 가능해야 한다.
- 다국적으로 서비스를 제공해야 할 경우, 지역별(예. 아시아, 북미, 유럽 등)로 서버 배치 (지역간 파일 및 데이터 동기화를 고려해야 함)
- 무결성 확인을 위한 체크섬 관리 (SHA-1, MD5 등) : 체크섬을 제공하여 파일이 정상적으로 다운로드 되었는지 확인할 수 있도록 한다.
- 블랙리스트 관리 : 요청 이력(IP, 건수, 용량) 등을 기반으로 시스템에 부하가 갈 정도로 악의적 요청을 보내는 클라이언트 차단
- 서비스 중단을 방지하도록 시스템을 이중화해야 한다.
- 파일 업로드 및 삭제 : 전송할 대용량 파일 관리 (저장소에 업로드, 저장소에서 삭제)
- 파일 목록 검색 및 페이징 : 전송할 대용량 파일을 검색할 수 있는 기능. 건수가 많을 경우 페이징으로 출력하는 기능.
- 전송 중 오류가 발생한 경우 재전송이 가능해야 한다. : 파일 전송 도중 오류가 발생하여 다시 전송할 경우, 처음부터 다시 전송 받는 것이 아니라 오류가 발생한 부분부터 이어서 전송한다.
- 사용자 관리
- 로그인/로그아웃
- 그룹 관리 : 사용자를 그룹 단위로 관리할 수 있는 기능
- 권한 관리 : 사용자 또는 그룹 단위로 다운로드 가능한 파일 권한 관리� 파일을 관리(업로드 및 삭제)할 수 있는 사용자 권한 관리
- 사용 이력 로깅 : 파일별, 사용자별 전송 이력을 로깅한다. 시스템 부하를 막기 위해 특정 기간(예. 6개월)이 지난 이력은 주기적으로 삭제한다.
- 사용량 측정
- 스케쥴링 (예약 전송) : 사용자가 원하는 시간 또는 주기적으로 특정 파일을 지정하여 예약 전송할 수 있는 기능
- 보고서 생성 : 관리자를 위해 특정 기간에 대한 보고서 생성
- 과금 관리 : 사용자별 과금 관리
성능 테스트를 수행하여 목적에 맞는 압축 유틸리티를 선정한다.
- 측정 항목
- 압축 속도 및 압축률 : 압축 속도, 압축 해제 속도, 압축 사이즈 / 원본 사이즈 비율, 리소스 사용률 (CPU 및 메모리)
- 기타 고려 사항
- 라이선스
- 오픈 소스인 경우 릴리즈, 커밋 건수 등 커뮤니티 활동 상황
- 지원 언어
- 대상 유틸리티의 예
- gzip, bzip2, 7za 등
암호화 알고리즘을 선정한다. 전송된 파일을 사용자가 압축 해제할 수 있는 양방향 암호화 알고리즘 중 선택한다.
후보 알고리즘을 선정 후 암호화 성능을 측정한다. 시스템에 감내할 수 있는 최소 수준의 성능에 매치하면서 보안성이 높은 알고리즘을 선정한다.
보다 높은 수준으로 보안을 강화해야 할 경우에는 비대칭키 알고리즘을 선정하고, 인증서 발급을 위한 CA 도입을 고려한다.
- 대칭키 알고리즘
- 특징 : 암복호화에 서로 동일한 키가 사용되는 암호화 방식
- 장점 : 암호화 속도가 빠르다
- 단점 : 송신 측에서 수신 측에 암호키를 전달하는 과정에서 노출 우려가 있다.
- 알고리즘의 예 : 3DES, AES, ARIA, SEED 등
- 비대칭키 알고리즘
- 특징 : 암복호화에 서로 다른 키가 사용되는 암호화 방식. 하나의 키는 공개키로 사용.
- 장점 : 암호키 전달 과정이 불필요하므로 안정성이 높다.
- 단점 : 대칭키 방식에 비해 느리다
- 알고리즘의 예 : RSA, ECC 등
시스템 전체에서 단일 알고리즘을 사용할 경우에는 proxy patter을 이용해 구현하고, 복수 개의 알고리즘을 사용할 경우에는 factory pattern을 사용한다.
알고리즘별 구현체를 Config 컴포넌트를 이용해 설정으로 관리한다. Config 컴포넌트는 별도의 설정 파일을 통해 시스템 전반의 설정을 관리하며, reload 수행시 config에 대한 조회를 block함으로써 일관성을 유지한다.
- 제약 사항 : 클라이언트 영역에도 동일하게 압축 해제 및 복호화 매커니즘이 적용되어 있어야 한다.
다중 사용자의 요청을 처리할 수 있어야 한다.
대용량 파일 전송의 경우 메모리와 CPU를 많이 사용하는데, 과도한 요청으로 대기열이 쌓여서 시스템 성능이 저하되고 시스템이 다운되는 현상을 방지하기 위해 비동기 메시지 처리 방식으로 구성한다.
- Message Queue 특징
- 비동기 (Asynchronous) : 비동기 처리
- 비동조 (Decoupling) : 어플리케이션과 분리 가능
- 탄력성 (Resilience) : 일부 실패시 전체 영향을 받지 않음
- 반복 (Redundancy) : 실패할 경우 재실행 가능
- 보증 (Guarantees) : 작업이 처리된 것을 확인할 수 있음
- 확장성 (Scalable) : 다수의 프로세스들이 큐에 메시지를 보낼 수 있음
- Message Queue 제품 예
- ActiveMQ
- 다양한 언어 지원
- 클러스트링 가능
- 모니터링 도구 미지원
- RabbitMQ
- 다양한 언어 지원
- 클러스트링 가능
- 실시간 모니터링 및 관리 용이
- Kafka
- 대용량 실시간 처리에 특화되어 설계된 메시지 시스템
- 분산 시스템을 기본으로 설계
- ActiveMQ
- 선정을 위한 판단 근거
- 성능
- 지원 언어
- 설치를 위한 최소 사양
- 충분한 레퍼런스가 존재하는지
- 오픈 소스인 경우, 릴리즈, 커밋 건수 등 커뮤니티 활동 상황
- 상용인 경우, 기술 지원
자주 요청되는 파일에 대해서 압축/암호화된 파일을 별도로 저장한다. 사용자의 파일 사용 특성에 따라 캐쉬 알고리즘과 캐쉬 사이즈를 선정하고, 압축/암호화된 파일을 캐쉬한다.
- 캐쉬 대상
- 파일 정보 : DB에 저장 (알고리즘 ID도 함께 저장되어야 함)
- 원본 파일명
- 암호화 알고리즘 ID
- 압축 알고리즘 ID
- 압축/암호화된 파일 경로
- 최근 요청일시
- 요청 건수
- 압축/암호화된 파일 : 별도의 파일 저장소에 저장
- 파일 정보 : DB에 저장 (알고리즘 ID도 함께 저장되어야 함)
- 캐쉬 알고리즘 (LRU 또는 LFU 선호)
- LRU (Least Recently Used)
- LFU (Least Frequently Used)
- FIFO (First In First Out)
- Random
- 캐쉬 메커니즘 구현시 고려해야 하는 사항
- 파일 정보 삭제시 파일 저장소에서 압축/암호화된 파일도 함께 삭제한다.
- 원하는 시점에 캐쉬를 clean 할 수 있는 API를 제공한다.
- 압축 또는 암호화 알고리즘이 변경되면, 캐쉬 파일 정보 및 파일을 모두 삭제한다.
- 알고리즘 및 캐쉬 사이즈는 별도의 설정 파일로 관리하고 실시간으로 변경할 수 있도록 한다.
- 제약사항
- 멀티 서버에서 동일한 파일 저장소를 사용할 수 있도록 NAS 등의 적용이 고려되어야 한다. 그렇지 않을 경우에는 DB로 저장하는 파일 정보에 서버 정보가 추가되어야 한다.
전송된 파일의 유효성을 클라이언트에서 검사할 수 있도록 체크섬을 제공한다. 단방향 암호화을 통해 생성한 해쉬를 체크섬으로 제공한다.
- 체크섬 생성 알고리즘
- MD5 : 취약점이 알려져서 사용을 권장하지 않음
- SHA : SHA-0, SHA-1은 취약점이 알려져있으므로 SHA-2 권장. 통상 SHA-256 이상의 알고리즘을 사용하도록 권장됨.
- 구현 방안
- Java의 MessageDigest 활용
- com.google.common.hash의 File.asByteSource(file).hash(hashFunction) 사용
- 대용량 파일에 대한 성능 비교 및 사용 편의성을 고려하여 선정
