현재 사내 프로젝트에서는 별도의 검색엔진 구성하지 않고, 프로젝트 폴더 내에 검색을 위해 전처리된 tsv 파일을 올려 awk 명령어로 텍스트를 처리하여 검색 기능을 구현하고 있다.
이에 사용되는 H.tsv, L.tsv 파일이 커서 git에 올려 사용하기에는
git clone 시간이 너무 오래걸리고
L.tsv는 git lfs(large file system)을 사용해도 git에 올릴 수 없다. (1.8 GB)
따라서 S3에 search 를 위한 파일들을 넣어두고 배포시 꺼내서 사용하려한다.
방법
S3 매번 요청해서 검색 값 가져오기
GitHub actions 로 미리 S3에서 zip 파일을 가져와 압축을 풀고 docker build 하기
Dockerfile 내에서 command 를 통해 zip 파일을 가져와 압축을 풀어 사용하기
Sass 검색엔진을 별도로 구성하여 파일없이 검색하기
직접 opensource 사용해서 검색엔진 구축하기
git, docker container 에는 무거운 파일들이 빠져있으므로 빌드시간, 이미지사이즈, git 작업 시간 등을 절약할 수 있다.
매 요청마다 특정파일(1기가 이상)을 보고 awk 작업을 수행하여 특정값을 가져오는데, 결국 해당 파일 전부를 읽는 비용이 청구되어 비용면에서는 좋지 않다.
S3 내부에서 awk 작업을 처리할 수 없고 결국 오브젝트 전체를 가져와야하므로 시간적으로도 좋지 않다.
github actions 수행시간이 길어진다.
workflow 파일만 조금 수정하면 되므로 비교적 구현이 쉽다.
docker build 시간이 길어진다. (github actions 내에서 수행하므로 같이 길어짐)
dockerfile 내에서 aws credential 작업을 해주어야하고, 그에 필요한 값들을 환경변수로 별도로 처리해주어야한다. (그냥 값을 넣어도 되긴하지만 보안상 좋지 않다.)
1번의 장점을 모두 가져올 수 있고, awk보다 빠르며, 단순 문자열 매칭 검색 외에 다양한 기능을 사용할 수 있다.
유저가 별로 없을 경우 데이터 전송당 요금만 부과하는 S3에 비해 인스턴스 요금이 추가로 부과되므로 오히려 비용이 더 크다.
모든 장점을 가져올 수 있고 비용이 4번에 비해 저렴함
소요가 너무 큼
현재 사용자가 많지 않으므로 검색엔진 구성은 이후로 미루고, 소요가 적은 2, 3번 중에 선택
2,3 번은 S3 파일을 가져오는 시점만 다른데, 전체 ci/cd 시간은 유지되지만 3번의 경우 docker image 사이즈가 2번에 비해 작아지므로 3번을 선택.
zip 파일 다운로드하고 unzip 하기 vs 파일 그대로 업로드하고 다운로드하기
3-1. zip 파일로 가져오기
당연히 비용이 더 저렴함 (둘다 작아서 몇배 차이나도 미세하긴함)
unzip 시간에 비해 네트워크를 타는 시간이 훨씬 크므로 비용도 적고, 시간도 줄이는 3-2번의 상위호환 방법
3-2. 파일 그대로 가져오기
비용 조금 더 비쌈
네트워크 전송량이 늘어나 느려짐