2.1 WebCL

WebCL⁽²⁾은 플러그인 없이 웹 브라우저만을 이용하여 병렬컴퓨팅을 수행하도록 OpenCL을 웹에서도 사용할 수 있도록 Javascript 언어로 결합한 프레임워크이다. OpenCL API 리스트와 매칭되는 WebCL API를 제공하고 있으며, 이를 통해 Javascript에서도 병렬컴퓨팅이 가능하다. 즉 단순 UI 인터페이스 기능만 담당하던 웹 브라우저에서 3D 그래픽 처리나 실시간 동영상 편집 도구, 시각화 처리와 같은 고성능이 필요한 처리 로직들이 구현 가능해졌다.

WebCL은 Khronos 그룹에서 표준을 제정하였으며 2011년 WebCL 1.0 버전이 릴리즈 되었다. 해당 표준 작업은 모질라, 구글, 오페라, 어도비 등 웹 기술 업체들과 삼성전자, 인텔, AMD, ARM, 엔비디아, 퀄컴 등 모바일 프로세서 기술 기업에서 참가하였다. 하지만 현재 WebCL은 모든 범용 웹 브라우저에서 사용이 불가능해졌으며, ETRI의　High Web⁽⁵⁾과 같은 전용 웹 브라우저 환경에서만 사용할 수 있다는 단점이 있다. 이로 인해 최근 WebCL 기술을 사용한 애플리케이션 활용 사례나 연구들이 더 이상 진행되지 않는 상황이다.

2.2 WebGL

WebGL⁽¹⁾은 웹 기반의 3D 그래픽 라이브러리로 자바스크립트 언어에서 사용할 수 있으며, 별도의 플러그인 사용 없이 3D 컴퓨터 그래픽스 API를 제공하는 캔버스 HTML 요소의 일부분이다. WebGL은 OpenGL ES2.0을 기반으로 2011년 3월 세부 사양이 버전 1.0으로 출시되었으며, 비영리 단체인 Khronos 그룹에 의해서 관리되고 있다. 최근 WebGL2 버전이 출시되었으며, 해당 버전에서는 쉐이더 언어로 GLSL 3.0을 사용할 수 있게 되었다. WebGL은 현재 구글 크롬, 인터넷 익스플로러 11, 모질라 파이어폭스, 사파리 오페라 등 대부분의 범용 웹 브라우저에서 사용 가능하다. WebGL 기반의 Three.js 및 Babylon.js와 같은 웹 3D 라이브러리를 이용한 다양한 웹 3D 애플리케이션들이 개발되고 있으며, 웹 브라우저의 동적인 CSS 효과들을 위해 사용되기도 한다. 또한 최신 WebGL 2 버전의 경우 Compute Shader가 사용 가능해지면서, 3D 그래픽 뿐 아니라 범용 계산 목적의 컴퓨팅 계산도 가능해졌다. 하지만 최신 WebGL 2 버전의 경우 Apple의 Safari 웹브라우저에서는 향후 지원 중단이 결정되었으며, 최신 웹 환경에서 3D/컴퓨팅 계산을 위한 WebGPU 표준의 확대로 인하여 WebGL 2 버전의 확대 적용은 어려워질 것으로 예상한다.

2.3 WebGPU

WebGPU⁽³⁾는 “현대 3D 그래픽 및 계산 기능”을 제공하기 위한 가속 그래픽 및 컴퓨팅을 위한 최신 웹 표준 및 Javascript API이다. WebGPU 표준은 기존 WebCL 및 WebGL API의 대안으로 다양한 업체들의 고유 기술 및 목적들을 반영할 수 있는 형태로 설계 및 개발이 진행 중이다. 현재는 주요 최신 웹 브라우저들의 개발(실험) 버전에서 WebGPU API의 사용이 가능한 상태이다. WebGPU는 기존 WebCL과는 달리 주요 업체들이 참여하며 각자의 차세대 GPU 기술들을 지원할 수 있도록 표준을 개발 중으로, 향후 범용적으로 사용될 가능성이 큰 것으로 평가된다. 또한, WebGL은 범용 컴퓨팅 계산보다는 3D 그래픽 처리를 위한 API로써 일반적인 계산 목적으로는 충분하지 않았다. 따라서 WebGPU는 WebGL과는 달리 일반 범용 목적의 계산 처리 시에도 WebGL 보다 월등한 성능개선 효과를 보여주고 있다.

그림1은 기본적인 WebGPU의 내부 구성 계층 구조이다. 가장 하위 계층에는 GPU 하드웨어가 존재하며, 이를 Vulkan⁽⁶⁾, Direct3D 12⁽⁷⁾, Meta⁽⁸⁾l과 같은 다양한 Native 레벨의 GPU 드라이버에서 제어하고 있다. 그리고 최상단 웹 애플리케이션 계층에서는 Javascript 및 Shader Code를 이용하여 프로그램을 작성하며, 실제 WebGPU 구현체인 User Agent를 통해 GPU 접근이 가능하다.

그림. 1. WebGPU 시스템 계층

Fig. 1. System layer of WebGPU

현재 구글 크롬 웹 브라우저에서는 User Agent로 dawn 엔진을 통해 WebGPU 표준의 구현체를 개발 진행 중이다. 이외에도 Apple은 User Agent를 Webkit 엔진에서 구현하고 있으며, Mozila 파이어폭스의 경우 WebGPU의 User agent로 wgpu 엔진을 개발 진행 중이다.

3.1 AES 알고리즘

AES(Advanced Encryption Standard) 암호화 알고리즘⁽⁴⁾은 DES를 대체할 목적으로 NIST가 표준으로 개발한 암호화 알고리즘이다. 암호화와 복호화 과정에서 동일한 키를 사용하는 대칭 키 알고리즘으로 DES와 비교하면 키 길이를 자유롭게 사용할 수 있다. Feistel 구조인 DES에 비해 SPN 구조인 AES는 역함수가 필요하다는 단점은 있지만, 중간에 스왑(swap) 연산 없이 한 번에 암/복호화가 가능해 상대적으로 효율적인 설계가 가능하다.

그림. 2. AES 알고리즘 수행 과정

Fig. 2. AES algorithm execution process

그림. 3. WebGPU 기반 컴파일 및 실행 과정

Fig. 3. WebGPU-based compilation and execution process

AES-256인 경우 총 14라운드 처리 단계로 구성되며 그림 2와 같이 암호화 과정을 수행한다. 암호화 과정을 살펴보면, 가장 먼저 Key expansion 단계를 거쳐 하나의 주 암호화 키로부터 많은 라운드 키들을 생성한다. 추가로 키의 크기에 따라 총 라운드의 수가 달라지므로 만들어야 할 라운드 키의 개수도 다르다. AES 알고리즘은 라운드 키를 만들 때 32비트(4바이트, 1워드)씩 연속적으로 만든다. AES는 세 버전 모두 128비트의 블록 크기를 사용하므로, 하나의 라운드 키는 이 4바이트 워드를 4개 합쳐서 만든다. 그러므로 AES-128, 192, 256 버전은 각각 44, 52, 60개의 4바이트 워드를 만든다. 초기 Key expansion 단계를 거친 후 실제 암호화 단계를 수행하다. 128bit PLAINTEXT 입력을 256bit 비밀키의 첫 128bit와 XOR 연산한 후 연산이 끝난 128bit의 결과물을 8bit씩 4x4 행렬로 정렬하여 SubBytes, ShiftRows, MixColumns, AddRoundKey와 같은 4가지 연산 과정을 256bit 비밀키의 경우 14번 수행한다. 단 마지막 라운드에서는 MixColumns 과정은 생략한다. AES의 총 라운드 계산 회수는 비밀키 크기에 따라 달라지는데, 128/192/256bit인 경우 라운드 계산은 10번/12번/14번 수행한다.

3.2 WebGPU 기반 AES 알고리즘

본 논문에서 구현한 WebGPU 기반의 AES 암호화 알고리즘의 전체 구성은 그림3과 같다. 기본적으로 AES 알고리즘은 웹 프로그램 언어인 Javascript로 구현된다. 이 중 AES 알고리즘에서 병렬처리 가능한 로직 부분을 WebGPU 코드로 재작성하여 실행속도를 가속화 하고자 한다. 따라서 순차적으로 처리되던 AES 알고리즘을 병렬처리할 수 있도록 그림4와 같은 구조로 변경하였으며, AES 알고리즘의 라운드 연산 부분인 Encrypt 모듈을 GPU의 Compute Shader 코드로 재작성하여 실행하였다. 각 Shader 코드의 입력값으로 Key expansion 과정을 거쳐 생성된 round key와 암호화할 PlainText 블록을 Host에서 Device(GPU)로 전달하며, Shader 코드에서는 모든 라운드 계산이 완료되면 최종 CipherText 결과를 Host로 반환하며 암호화 과정이 완료된다.

그림. 4. AES 알고리즘의 병렬처리 구조

Fig. 4. Parallel processing structure of AES algorithm

본 연구의 실험은 구글 크롬 웹 브라우저에서 진행하는데 Encrypt GPU 코드는 GLSL(OpenGL Shading Language) 코드로 작성하였다. 하지만 GLSL 코드는 현재 WebGPU 환경에서 바로 실행 불가능하여, Khronos 그룹에서 제안한 이종 플랫폼에서의 병렬처리를 위한 중간언어인 SPIR-V 코드로 변환이 필요하다. 이를 위해 Javascript 언어로 이식된 glslang⁽⁹⁾을 사용하여 GLSL 코드를 SPIR-V 코드로 변환한 후 GPU 실행 요청을 수행하였다. 최종 변환된 SPIR-V 코드는 WebGPU API를 사용하여 실제 GPU에게 실행 요청을 한다. 이는 웹 브라우저 Javascript 엔진 내부의 WebGPU 표준을 위한 오픈소스 구현체인 Dawn⁽¹⁰⁾에서 처리하고 있다. Dawn은 클라이언트-서버 형태로 구현되어 있으며, 클라이언트인 DawnWire 모듈과 실제 GPU 실행을 위한 Raw 레벨 API와의 연계를 담당하는 DawnNative 서버 모듈로 구성되었다.

최종 GPU 실행은 각 업체에서 제안하는 차세대 GPU API인 Vulkan, Direct3D 12, Metal과 같은 다양한 Native GPU API 레벨에서 처리된다. 본 연구의 실험환경에서 사용한 크롬 웹 브라우저의 경우 Vulkan을 사용하여 최종 GPU 코드를 실행하고 있다.

그림. 5. WebGPU 기반 AES 실행 과정

Fig. 5. WebGPU-based AES execution process

본 논문에서 제안한 WebGPU 기반 AES 알고리즘의 전체적인 실행 과정은 그림5와 같다. 가장 먼저 Javascript로 구현된 AES 알고리즘의 초기화 단계에서 암호화 대상 데이터 및 암호키를 설정하고, 이를 기반으로 라운드 키를 생성한다. 이후 GPU 병렬처리를 위해 작성된 GLSL 코드를 SPIR-V 코드로 변환한 후 이를 WebGPU API를 이용하여 최종 GPU의 실행을 요청한다. 최종적으로 GPU 명령어를 제출할 때 GPU로 데이터를 함께 보내주는데, AES 알고리즘에서는 암호화할 Plaintext 데이터와 AES 라이브러리 초기화 시 생성한 RoundKey를 함께 입력으로 전송한다. 이를 이용하여 GPU 코드 내부에서 요청된 각 Plaintext 블록 데이터를 대상으로 암호화 로직을 수행하며 최종 결과는 Host 메모리로 반환한다. WebGPU에서는 GPU 코드 실행시 OpenCL 또는 WebCL과 같이 Work-groups 및 Work-items 값에 대한 세부 설정은 하지 못한다. 단지 인코딩된 GPU Command를 dispatch 하는 시점에 GPU 코어의 Matrix 크기를 설정 가능하며 GPU 코드 내부에서는 현재 실행되고 있는 코드의 GPU 코어의 Matrix의 위치를 gl_GlobalInvocationID 오브젝트를 통해 참조할 수 있다.

3.3 Shader 코드의 사전 변환 최적화

우선 현재 WebGPU 스펙에서는 GPU 코드 작성을 위한 Shader 언어가 지정되어 있지는 않다. 따라서 각 GPU의 API에 따라 Metal용 앱은 Metal Shading Language를 사용하고 Direct3D 12용 앱은 HLSL을 사용하며 Vulkan용 앱은 SPIR-V 또는 GLSL을 사용할 수 있다. 이외에도 현재까지 WebGPU를 위한 Shader 언어로 SPIR의 일부 프로파일과 Web Shading Language로 진화한 Apple의 웹 환경을 위한 WHSL(Web High-level Shading Languages) 제안이 있다. 하지만 이 두 가지 모두 다양한 업체에서 받아드릴 수 없는 단점이 있다. 또한 SPIR의 경우 정의되지 않은 동작과 안전성 검증에 대한 문제가 있는데, 이를 구글과 모질라에서는 재작성 패스를 통해 이를 해결하고 있다. 반대로 Apple의 제안 경우 현장에 존재하는 여러 업체의 GPU API들을 고려하지 않기 때문에 상당한 저항에 부딪혔다. 따라서 표준 그룹인 Khnors에서는 Vulkan 및 SPIR-V를 중심으로 하는 표준을 제안하였으며, 그림6과 같은 SPIR-V 파일 포맷 중심의 생태계 형태로 발전할 예정이다 ⁽¹¹⁾. 최종적으로 본 논문에서 적용한 구글 크롬의 dawn 엔진에서는 GLSL(OpenGL Shading Language) Shader 코드를 사용하는데, dawn에서는 GLSL을 바로 사용할 수 없어 코드를 실행하기 전 런타임시 웹 브라우저에서 SPIR-V 코드로 컴파일하는 과정을 추가로 수행해야만 한다.

그림. 6. SPIR-V 파일 포맷의 생태계

Fig. 6. Ecosystem of SPIR-V File Format

실험 환경에서는 해당 변환과정에 약 900~1,000ms 정도의 시간이 소요되었다. GLSL 코드를 SPIR-V 코드로 변환할 때 glslang 도구를 이용하는데, 해당 과정은 실행 시 1회 발생하며, 작은 크기의 작업일 경우 변환과정 자체가 큰 부하가 되기도 한다. 따라서 본 논문은 웹서버에서 Shader 코드 변환과정을 사전에 수행한 후 웹 브라우저에서는 사전 변환된 SPIR-V 바이너리 코드를 직접 로드 하는 방식을 적용하고자 한다. 이를 통해 실행 시간 중 변환 시간이 제거되므로 전체 실행속도를 개선할 수 있다. 이를 위해 그림3의 “Translator (GLSL to SPIR)” 항목의 처리 시간을 개선할 수 있었으며, 단지 웹서버로부터 약 13kbyte 크기의 Shader 코드를 서버에서 웹 브라우저로 다운로드만 받으면 컴파일 과정 없이도 동일한 동작이 가능하였다.

3.4 GPU 중첩 실행을 통한 최적화

GPU 커널을 중첩하여 실행함으로써 GPU 자원 활용률을 최대한으로 끌어내는 최적화 방법^(12)(13)을 본 WebGPU 환경에 적용하고자 한다. 일반적으로 GPU에게 Shader 코드 실행 요청 시 전체 데이터를 한 번에 전송하여 처리하는 단순 형태의 순차 실행 방법이 있으며, 이는 그림7의 좌측 부분과 같다.

그림. 7. 순차 실행과 동시 실행

Fig. 7. Serial execution and concurrent execution

GPU 처리 과정을 세부적으로 나누면 Host와 GPU 메모리 사이 입/출력 데이터를 송/수신하는 데이터 통신 구간과 실제 계산이 이뤄지는 Compute Shader 실행 구간으로 나눌 수 있다. 데이터 송/수신 구간 동안에는 GPU의 계산 유닛은 유휴 자원으로 남아있는데 이를 개선하고자 그림7과 같은 중첩 실행이 가능한 동시 실행 방법을 적용하고자 한다. 이는 통신하려는 데이터의 크기가 커질수록 통신 작업에 처리되는 시간이 늘어나면 GPU Compute 유닛의 유휴시간도 함께 증가하므로 전체 성능도 저하되었다. 따라서 GPU 자원을 최대한 활용할 수 있도록 작업을 분할한 후 동시에 메모리 입/출력과 Compute 유닛을 최대한 실행할 수 있는 중첩 실행 방안을 제안한다. 또한, 데이터의 크기가 커질수록 데이터 송/수신 시간이 비례하여 증가하는데 작은 단위로 작업을 나누어 중첩 실행할 경우 데이터 송/수신 시간에도 Compute Shader를 실행하게 되므로 GPU 활용률을 최대한으로 끌어내어 최종 실험결과 그림9와 같이 최대 25\% 정도의 속도 개선을 확인할 수 있었다. 이와 같은 중첩 실행 방법은 GPU의 글로벌 메모리의 크기보다 더 큰 크기의 데이터도 분할 실행을 통해 처리 가능해진다는 장점이 있다.

위와 같은 최적화 작업을 위해 본 실험에서 사용한 크롬 및 GLSL Compute Shader 기반의 WebGPU 환경 기반에서 그림5의 “GPU 명령 제출 및 데이터 전송“ 단계와 ”Data Reception“ 과정을 수행하는 실제 코드를 살펴보면 아래의 예시와 같다.

const gpuCommands = commandEncoder[idx_buf].finish();

device.defaultQueue.submit([gpuCommands]);

const returnArr = await gpuReadBuffer.mapReadAsync();

주어진 코드는 OpenCL이나 CUDA와 같은 Native 환경의 GPU API와는 달리 그림 7의 GPU 실행 과정을 세부적으로 구분하여 처리할 수 없다는 문제점이 있다. 즉 submit() 함수를 호출하는 순간 “Host to GPU" 데이터 전송 과정과 GPU 코드 실행의 두 과정이 한 번에 처리되어, 데이터 전송 완료 시점과 GPU 코드 실행 단계를 구분하여 처리할 수 없다. 따라서 본 연구의 WebGPU 환경에서는 Shader 코드의 실행 크기를 n개로 분할 한 후 연속적으로 GPU 실행을 요청하였다. 그리고 GPU Shader 코드의 처리 후 반환 데이터 수신을 비동기적으로 처리함으로써 GPU 활용률을 최대한 사용할 수 있도록 처리하였다.