[2023 04 19] 암호화 소프트웨어 멀티쓰레드 구현 - Whitmem
[2023 04 19] 암호화 소프트웨어 멀티쓰레드 구현
Develop History
2023-04-19 02:41 게시 e650fd741f1dc7b2d844

0
0
245
이 페이지는 외부 공간에 무단 복제할 수 없으며 오직 있는 그대로 게시되며 부정확한 내용을 포함할 수 있습니다. 법률이 허용하는 한 가이드 라인에 맞춰 게시 내용을 인용하거나 출처로 표기할 수 있습니다.
This page is not to be distributed to external services; it is provided as is and may contain inaccuracies.
기존 기능의 문제점
기존 암호화 소프트웨어는 싱글 쓰레드에서 수행되는 소프트웨어로 버퍼 사이즈를 크게 두더라도 한 코어에서만 암호화를 진행하였다. 따라서 암호화 속도가 느려짐에 따라 SSD에서 암호화를 할 때 병목현상이 발생함을 알 수 있었다. 평균 파일을 4기가를 암호화할 때, 60MB/s 속도가 최대치였고, 이론상 SSD는 500MB/s 까지 낼 수 있는 상황이었다. 암호화를 수행하느라 다음 버퍼를 가져오지 못하고 있었던 것.
멀티쓰레드 구현
기존 방식에서 벗어나기 위해서, 한 섹션을 암호화하는 클래스를 만들어, 한 섹션에 대한 암호 정보를 파일 A로 저장하도록 구축하였다.
클래스
싱글 쓰레드 구현자
싱글쓰레드 처리자
추후 쓰레드가 몇 개든지에 따라 효율적으로 구성하기 위해 하나의 쓰레드를 처리하는 클래스를 만들어 구현하였다. SingleThreadEncryptor은 한 파일의 스트림에 대해서 지정된 위치만큼을 암호화하고, 새로운 파일로 내보낼 수 있도록한다. 만약 [영상] 파일이 있다면, 이 영상의 0~1000 사이즈 조각을 암호화하되 암호화한 파일을 일부 조각 파일로 내보낸다. 예) encrypted_1
멀티쓰레드 처리자
멀티 쓰레드 암호화 처리자
상기 단락의 싱글 쓰레드 구현자는 하나의 파일의 일부분을 암호화하고 내보내도록 구현하였다. 그러면 이제 실제로 암호화하고자 하는 파일을 적절하게 구획을 나누고 이를 동시에 실행할 수 있도록 처리하는 메인 처리자가 필요하다. 이 작업을 바로 ThreadSteamEncryptor에서 진행하도록 구현하였다. 클래스의 생성자에서 암호화하고자 하는 파일, 비밀번호, 쓰레드 개수를 받으면, 생성자에서 파일의 크기를 계산한 뒤, 파일의 크기에 쓰레드 개수를 나눠 쓰레드당 처리해야 할 스트림 크기를 계산한다. 계산한 크기를 바탕으로 각 쓰레드 당 처리해야할 구획을 나누고, SingleThreadEncryptor 클래스를 개수만큼 인스턴스화 해 각 영역의 암호화 처리를 동시에 시작한다. 각 쓰레드의 암호화가 언제 마무리될 지 알 수 없기 때문에, delegator을 통해서 실시간으로 쓰레드별 암호화 진행 상태를 가져오고 모든 쓰레드의 상태가 Finish상태가 되면 ThreadStreamEncryptor을 실행한 요청자에게 완료 피드백을 보낸다. 그렇게 되면 실제 UI쪽 쓰레드에서는 이 작업이 완료된 것을 알아차리고 다음 선택된 데이터로 넘어갈 수 있다.
파일 병합
한 가지 빠진 내용이 있다면, 파일을 각각 분할해서 암호화를 했기 때문에 파일도 여러 개 생성된다. 예를 들어, [영상]파일을 5개의 쓰레드로 암호화하면 encrypted_0, encrypted_1, encrypted_2, encrypted_3, encrypted_4 라는 암호화된 파일이 생성되며, 이 파일을 순차적으로 이어줘야 하나의 암호화된 파일로 구현할 수 있다. 이를 처리하기 위해서 병합 처리자를 만들었고, 병합 처리는 EncryptedFileMerger에서 처리한다.
EncryptedFileMerger
이 처리자는 다수 개의 파일 경로를 입력하고, 대상을 입력 해 주면, 대상 파일을 만들어 다수 개의 파일 스트림을 순차적으로 읽어 대상 파일의 스트림에 써 주도록 구현하였다.
결과
읽기/쓰기 속도 4000MB SSD 기준 싱글쓰레드로 650MB 파일을 암호화할 때 약 10-20초 가량 걸렸다면,
멀티 쓰레드 4개를 기준으로, 약 1-2초가 소요, 병합에 1초 정도가 소요되었다.
작업 관리자를 보더라도 모든 코어를 적절하게 사용하고 있으며, 싱글쓰레드의 경우 프로그램의 사용량이 15%에 머무른 반면, 멀티 쓰레드를 사용한 결과 70%까지 올라감을 알 수 있었다.
하지만, 장점만 존재했던 것은 아닌데, 멀티쓰레드 처리를 위해 동기화하는 작업이 필요하고, 다른 작업의 처리를 기다리거나 기다리기 위해 잠시 쉬어가는 코드 라인이 있었기 때문인지 용량이 매우 적으면서 개수가 매우 많은 대량의 파일을 처리할 때 한 파일 끝나고 넘어가는데 딜레이가 제법 차이가 있었다. 쓰레드가 시작되고 끝나는 것을 기다리는데 시간이 조금씩 누적되는 것으로 보인다.
따라서 파일 용량에 따라서 쓰레드를 사용할 것인지 안할 것인지 구현하는 것이 좋을 것 같다.
댓글 0개
댓글은 일회용 패스워드가 발급되며 사이트 이용 약관에 동의로 간주됩니다.
확인
Whitmemit 개인 일지 블로그는 개인이 운영하는 정보 공유 공간으로 사용자의 민감한 개인 정보를 직접 요구하거나 요청하지 않습니다. 기본적인 사이트 방문시 처리되는 처리 정보에 대해서는 '사이트 처리 방침'을 참고하십시오. 추가적인 기능의 제공을 위하여 쿠키 정보를 사용하고 있습니다. Whitmemit 에서 처리하는 정보는 식별 용도로 사용되며 기타 글꼴 및 폰트 라이브러리에서 쿠키 정보를 사용할 수 있습니다.
이 자료는 모두 필수 자료로 간주되며, 사이트 이용을 하거나, 탐색하는 경우 동의로 간주합니다.