[Cloud Wave 3기] 프로젝트 시작 전, 올리브영 테크 블로그에서 프로젝트 방향성 찾기

대규모 트래픽을 고려한 올리브영 아키텍처 구축 프로젝트(2024.08.12. ~2024.08.30.(3주))를 진행하며 기록한 내용을 아카이브 용도로 남깁니다.

 

금요일에 프로젝트 주제가 발표된 후 그 다음주부터 바로 프로젝트를 진행해야 했기 때문에

주말 동안 프로젝트의 방향성을 잡기 위해 올라와 있는 올리브영 테크 블로그 글들을 보며 중요한 점들을 정리했습니다.

 

가능한 모든 게시글을 확인하며 도움이 되거나 중요한 내용들을 최대한 정리해두었습니다.

 

그 중 특히 중요했던 두 가지를 간추려 간단히 정리해보았습니다.

 

1. CI/CD 툴로 Jenkins를 채택하지 않은 이유

저희 팀 프로젝트의 경우 결과적으로 Jenkins를 사용하지 않고 ArgoCD와 Gitlab을 이용했습니다.

다음과 같은 이유 때문입니다.

---

인용: https://oliveyoung.tech/blog/2022-05-03/How-to-Set-up-Build-Process-with-Teamcity/

Plugin 관련 이슈

Jenkins는 다양한 Plugin을 제공하는 장점이 있습니다. 하지만 Docker Container에서 작업을 진행하며 Plugin 을 설치할때마다 재시작를 해야한다는 난관에 부딪혔습니다. 운영 상에 Plugin 에 문제가 있어 이를 제거하고 다시 배포를 해야한다고 가정한다면, 재시작을 위해 기다리는 시간이 있다면 참으로 난감하겠지요?

또한 현재 올디브는 OnPremise 서버를 사용하는데요. 이렇다보니 Plugin 설치를 할때마다 방화벽을 뚫어야하는 아찔한 상황도 있었습니다.

Docker container 실행 문제

또한 Docker container 실행 시 간헐적으로 프리징 현상이 있었습니다. 쉽게 설명하면 Job이 실행되고 종료가 되지 않는 현상이었습니다.

기존에도 Jenkins를 이용했지만 서버의 제약적인 환경과 Docker와의 궁합이 좋지 않다고 판단했습니다.

---

 

그 외 보충 자료 조사

Jenkins는 본래 클라우드 네이티브 애플리케이션의 동적이고 분산된 특성에 맞춰 설계된 것이 아니라, 기존의 모놀리식 애플리케이션을 위해 만들어졌습니다. 이로 인해 클라우드 네이티브 환경에서는 사용에 불편함이 따르는데, 이를 해결하기 위해 쿠버네티스 환경에 맞춘 Jenkins X 프로젝트가 진행되고 있습니다.

 

기존 Jenkins는 상태 유지를 필요로 하는 구조입니다. 구성 정보, 빌드 기록, 사용자 데이터를 저장해야 하기 때문에 클라우드 네이티브 환경에서 효율적인 확장과 관리에 제약이 있습니다. 이러한 상태 유지 구조는 영구 저장소를 필요로 하며, 복원성과 수평적 확장이 중요한 분산 시스템에서는 배포를 더욱 복잡하게 만듭니다.

 

참고: https://devops.com/the-future-of-jenkins-in-2024/

 

온프레미스 환경을 염두에 두고 만들어진 Jenkins는 이러한 이유 때문에 저희가 구축하는 데 필요한 컨테이너 환경과 맞지 않다고 판단하여 ArgoCD와 Gitlab를 이용하여 CI/CD 를 구축하게 되었습니다.

 

2. 이미지를 위한 CDN 사용

---

인용: https://oliveyoung.tech/blog/2021-11-22/How-to-Improve-Web-Performance-with-Image-Optimization/

 

E-Commerce는 사이트 특성상 사진이 많이 들어가고 상품을 팔기 위해 사진은 빠지지 않는 가장 중요한 요소이기 때문입니다. 또한 이 이미지의 사이즈는 판매와도 직결되는 부분입니다. KissMetrics의 연구 결과에 따르면 페이지 로딩이 약 1초씩 느려질 때마다 상품을 구매하는 사용자의 비율은 약 7%씩 감소할 수 있다고 합니다. 이미지가 중요한 사이트가 아니라면 굳이 이미지를 최적화하는데 드는 리소스와 비용을 투자할 이유가 크게 없습니다. 하지만 올리브영은 이미지가 중점인 사이트이기 때문에 이미지 최적화가 필요합니다.

---