- Spring Boot
- Spring Data JPA
- thymeleaf
- Javascripit
- AWS(EC2,RDS,S3)
- CI & CD(Travis,NGINX,CodeDeploy)
그림 1. 아키텍처 도식도.
그림 1은 전체 시스템의 아키텍처를 보여준다. 크롤링 서버는 수집한 이미지를 저장소에 저장하고, 이미지의 Hash 정보와 이미지의 출처 URL을 웹 서버에 전송한다. 요청을 받은 웹 서버는 해당 데이터들을 데이터베이스에 저장한다. 사용자가 얼굴 매칭을 요청하면 웹 서버에서는 사용자의 입력 이미지를 인공지능 서버에 전달하고, 이후 인공지능 모델이 사용자 이미지와 수집된 데이터를 비교하여 그 결괏값을 웹 서버에 반환한다. 매핑된 컨트롤러는 이미지와 Hash 값, 정확도를 결과로 반환받고, Hash 값을 이용해 데이터베이스에서 출처 URL을 탐색한다. 이후 모든 결과를 전달받으면 결과 데이터를 View로 전달하여 사용자에게 보여준다.
웹 서비스의 구동은 Linux 환경에서 이루어졌다. 웹 서버는 Java 언어와 Spring Boot를 사용하여 구현되었고 내장 서버로는 Tomcat이 사용되었다. 웹 View는 Thymeleaf를 사용하였다. AWS의 EC2 Linux서버에 웹 서비스를 배포하였고 RDS MySQL로 데이터베이스를 연동하였다. 배포 자동화와 무중단 배포(CI & CD)를 위해 Travis, AWS CodeDeploy, NGINX, AWS S3를 사용하였다. 서버는 크롤링으로 수집된 데이터의 저장을 위한 서버, 서비스를 위한 웹 서버, 사용자의 이미지를 전달받아 얼굴 매칭을 진행하는 서버로 구분된다. 데이터 저장 서버는 크롤링으로 수집된 얼굴 이미지의 출처 URL과 이미지의 Hash 값을 받아 데이터베이스에 저장한다.
Controller, Service, DTO(Data Transfer Object), Entity, Repository로 구성되어 있으며, 서비스 클래스에서 요청을 넘겨받아 DTO 객체를 생성하고 Repository에 저장한다. 데이터베이스와의 연동은 Spring Data JPA를 이용하여 구현되었
그림 2. 데이터 전달 과정.
그림 2는 컨트롤러에 Post 요청이 전달되었을 때 데이터베이스까지 저장되는 과정이다. 먼저 매핑된 URL에 데이터 저장 요청이 들어오면, Controller에서 해당 요청을 수신하여 저장할 정보를 Service 클래스에 보낸다. Service 클래스에서는 전달받은 데이터로 DTO 객체를 생성하고, Repository의 save() 메서드를 호출하여 연동된 데이터베이스에 저장한다. 저장할 때는 DTO 객체에서 Entity 객체를 얻어 저장한다. 두 번째로 사용자가 접속하게 되는 웹 서버이다. 해당 웹 서버는 Controller, Service, View로 구성된다. Controller에서는 마찬가지로 매핑된 URL로의 요청을 처리하고, Service에서는 인공지능 서버에서 전달받은 결과 데이터로 DTO 객체를 생성하는 역할을 한다.
그림 3. 컨트롤러 매핑.
그림 3은 컨트롤러의 매핑을 알기 쉽게 도식화한 그림이다. Controller는 크게 Home, Input, Result로 나누어져 있으며 각각 View와 매핑되어 해당 페이지를 보여준다. Result는 인공지능 서버에서 결과를 받는 URL과 사용자에게 결과 페이지를 반환하는 URL로 나뉜다. 웹 서버에서 인공지능 서버로 사용자 이미지를 전송할 때 HTTP Post 메서드를 사용하며, Multipart/form-data 형식으로 전달된다. 이때 클라이언트의 JSESSIONID도 같이 넘겨주게 된다. 매칭 결과의 수신은 해당 컨트롤러와 매핑된 URL에 요청이 수신되면 발생한다. 수신되는 데이터는 매칭된 이미지, 이미지의 Hash 값, 매칭 정확도이며, 이미지는 Multipart/form-data, 나머지 데이터는 Json 형식으로 직렬화하여 전송된다.
그림 4. Hash값을 이용한 URL 탐색.
"api/detection/result"로 요청이 수신되어 얼굴 매칭 결과를 전달받게 되면, Service 클래스에서는 수신한 데이터로 DTO 객체를 생성하고, 이를 View에 넘겨주게 된다. 그림 6은 Hash 값으로 데이터베이스에서 출처 URL들을 가져오는 쿼리문이다. 결과 데이터로 전달받은 이미지의 Hash 값으로 데이터베이스에 질의하여 해당하는 출처 URL 정보들을 가져온다. 이러한 과정은 중복되는 이미지들을 하나만 저장하고도, 해당하는 모든 출처를 반환할 수 있도록 해준다.
매칭과 결과의 수신 과정에서 클라이언트 간의 구분은 세션 아이디를 이용한다. 클라이언트가 페이지에 접속하게 되면 웹 서버에서는 세션 아이디를 찾게 되고, 세션 아이디가 아직 존재하지 않는다면, 세션 아이디를 생성하여 Cookie에 넣어준다.
그림 5. 세션을 이용한 클라이언트 구분.
그림 5는 클라이언트를 구분하는 과정을 그림으로 나타낸 것이다. 이미지 업로드 버튼을 클릭하는 이벤트가 발생하였을 때 해당 클라이언트의 웹 서버 세션 아이디를 가져오게 되고, 이를 입력 이미지와 함께 매칭 서버로 전달하게 된다. 매칭 서버에서는 결과를 웹 서버에 보낼 때 헤더를 수정하여 클라이언트의 세션 아이디로 요청을 보낸다. 웹 서버에서는 결과를 수신받고, 이전에 클라이언트가 웹 서버에 접속할 때 생성하였던 세션에 결과 데이터를 저장한다. 모든 결과가 수신되고, 클라이언트가 결과 페이지로 리다이렉트 될 때 세션에 저장되어있는 결과 데이터를 View에 넘겨주게 된다. 세션에 저장되어있는 데이터는 데이터를 View에 넘겨준 후 바로 제거된다. 각 클라이언트는 다른 세션아이디를 가지기 때문에 클라이언트는 각각 독립된 페이지를 보는 것이 보장된다. 마지막으로 인공지능의 매칭을 실행하는 서버이다. 인공지능 서버에서는 웹 서버에서 전송하는 사용자 입력 이미지와 세션 아이디를 Controller에서 수신하고, 이를 이용하여 매칭 시스템을 실행한다.
그림 6. 다중 요청의 순차 처리.
그림 6은 다중요청의 처리 과정이다. 요청들이 수신되면 이를 대기열에 추가하고, 순차적으로 처리한다. 리소스가 모두 이용되고 있을 경우에는 추가적인 대기시간이 필요하다. 멀티스레드에서의 안전성을 위해 synchronized 블럭을 사용하였고, Queue 방식을 사용하여 대기열을 구성하였다. 이러한 대기열 방식은 각 요청이 순차적으로 처리됨을 보장한다. 처리 순서가 되면 사용자 이미지와 수집된 이미지의 임베딩 차를 구하게 되고, 이를 설정된 임계값과 비교한다. 만약 차이가 임계값 보다 작다면 동일 인물로 판단하고 매칭된 이미지와 Hash값, 매칭률과 같은 결과 데이터를 웹 서버로 전송한다.
배포 자동화와 무중단 배포를 위한 인프라를 구축하였다. Travis CI, AWS CodeDelpoly, AWS S3, NGINX를 사용하였고, EC2 서버에 두 개의 애플리케이션을 두었다.
그림 7. 배포 과정.
그림 7는 CI&CD에서의 배포 과정을 도식화한 그림이다. git 저장소로 프로젝트가 푸시되면 Travis에서는 푸시된 프로젝트를 빌드하고 S3에 Jar 파일을 저장한다. 그 후 CodeDeploy에 배포 요청을 하게 되고, CodeDeploy는 S3에서 Jar 파일을 전달받아 EC2 서버에 배포를 실행한다. 이때 NGINX가 가리키는 애플리케이션(현재 실행 중인 포트)이 아닌 다른 애플리케이션에 배포를 진행한다. 배포가 완료되면 정상적으로 실행되는지 확인하기 위해 Health Check를 거치게 되고, NGINX에서 Reload를 실행하여 최신 버전이 배포된 애플리케이션을 가리키도록 변경한다.
그림 8. 결과 화면.
매칭이 완료되고, 이전에 클라이언트가 보냈던 매칭 요청에 대한 응답이 반환되면 결과 페이지로 이동하여 수신된 결과 데이터를 보여준다. 결과 페이지에선 사용자가 입력한 사진과 매칭 결과를 보여준다. 만약 사용자의 사진이 특정 사이트에서 발견이 되었다면 발견된 사진과 출처 URL, 그리고 매칭률을 보여준다. 매칭률은 높음, 중간, 낮음으로 나타낸다. 해당 시스템은 사용자의 개인정보 유출을 최대한 많이 찾아내는 것을 목적으로 하기 때문에 미검출이 발생하지 않도록 딥러닝 모델의 임계값을 조절하였고, 따라서 이미지의 오검출이 어느 정도 발생할 수 있다.