들어가며전시 도메인 프로젝트를 진행하면서 이미지 리사이징, 압축, 캐싱 등 성능 최적화를 위한 고민을 많이 했었다. 이때 인프랩 CTO이신 이동욱님의 인프런 아키텍처에 대한 컨퍼런스를 보니 어떤 방법이 있고 도입해야하는 근거를 명확히 설정할 수 있어 유익했다. 실제 서비스에 적용된 성능 최적화 기술에 대해 알 수 있었고, 실제 대부분의 웹 사이트에 공통으로 적용될 수 있는 부분이라 정리를 하려고 한다. 인프런의 글로벌 서비스 오픈 전 트래픽 비용 개선 요구글로벌 서비스는 환율에 민감하므로, 트래픽 비용을 최대한 개선해야 한다.또한, 인프런을 홍보하려면 무료 콘텐츠를 배포해야 하는데 이 부분에 대해서도 비용 절감이 반드시 필요하다. 파일 포맷 변경으로 이미지 트래픽 최적화커뮤니티나 콘텐츠 서비스를 한다면 ..
들어가며우리 프로젝트의 아키텍처는 다음과 같지만, 기능이 구현될 때마다 학생들의 피드백을 들어보기 위해 지속적인 프로토타입 배포가 필요하다. 기능을 구현하면서 완벽한 CI/CD 파이프라인을 구성하는 것은 현실적으로 어렵다고 느껴 간단히 프로토타입을 올리기 위한 환경을 구축하여 배포할 것이다. 이상적인 흐름은 AWS EC2 무료 인스턴스로 환경을 만들고, Docker를 이용하여 스프링 기반 서버 이미지 생성하여 컨테이너 환경에서 배포를 한 후, RDS for MySQL 무료 인스턴스를 DB로 두고, S3를 이미지 서버로 이용하는 것이다.이때, EC2에서 구동되는 스프링 기반 서버는 RDS, S3에 접근 제어에 대한 자격증명 관리도 AWS Parameter Store를 이용하도록 한다. S3, EC2 Ins..
들어가며전시 도메인에 대한 프로젝트를 진행하면서 관리자 페이지에서 전시를 수정할 수 있는 기능을 구현하고 있었다. 우리는 전시 내 이미지를 S3에 저장하고 그 경로를 DB에 저장하여 관리한다. 캐싱과 비동기를 도입하기 전에 로직 자체에서 성능이 향상될 수 있도록 적절한 자료구조를 이용해 시간 복잡도를 줄일 수 있는 것을 목표로 했다. 요구사항기존 이미지는 이미 업로드가 되어 전시 중인 이미지이며, 업로드 이미지는 새로 전시할 이미지이다.또한, 이미지 간 순서는 배치될 위치를 결정하므로 반드시 백엔드에서 알 수 있어야 한다. 문제 인식처음에는 기존에 존재하는 이미지를 깔끔하게 모두 삭제하고, 서버로 전달된 기존 이미지 및 업로드 이미지들에 대해 다시 저장하면 JPA의 더티 체킹으로 간단하게 되지 않을..
들어가며 EKS 기반으로 쿠버네티스 환경을 구축하고 Karpenter를 도입하여 효율적인 노드 오토스케일링이 되도록 구축한 후 팀 내에서 Prometheus, Grafana를 도입하는 역할을 맡아 아래처럼 대시보드를 구성해서 팀에 제공했다. 그러나 직접 모니터링 환경을 구축하지 않은 팀원들에겐 클러스터, 노드, 파드 등 메트린 관찰 대상이 많아 낯설게 느껴질 것 같다고 생각했다. ECS 기반으로 진행하기보다 복잡한 쿠버네티스 환경에서 아키텍처를 구축하며 경험을 기르고자 결심을 했으니 쿠버네티스가 제공하는 기능을 주체적으로 관리하고 싶었다. 다른 팀원들이 맡은 부분을 개발하고 테스트하는 기간에 우선적으로 파드 및 노드의 생성과 삭제에 관련된 메트릭인 Cpu, Memory, Status, Age를 시각적으..
들어가며대규모 트래픽을 고려하며 가용성과 보안성을 준수하는 올리브영 Public Cloud(AWS) 인프라 아키텍처 구축이라는 프로젝트를 진행하며 고가용성을 목적으로 운영 환경에서 모든 이중화를 마치고 리전에 대한 이중화도 필요하다고 생각했다. 아무래도 최근 CSP(Cloud Service Provider) 외부 원인일지라도 특정 클라우드 업체에 장애가 나는 경우가 있기에 멀티 클라우드로 해결하면 좋겠지만 우리는 정해진 CSP인 AWS를 기반으로 멀티 리전을 통해 해결하려고 했다. 또한 재해 복구 대상을 분석하고 전략 별 RPO 및 RTO에 따른 적절한 재해 복구 전략을 선택했다. 재해 복구 대상 분석클라이언트 요청 흐름Client REST API→ ALB→ EKS(Node Cluster) → Pod(C..
들어가며전체 아키텍처를 설계하는 과정에서 요소 하나를 배치하는 위치는 정말 중요하다.특히 네트워크 설계 등 상세 설계가 이루어진 후라면 더욱 더 변경이 어려울 수 있다. 문제 인식팀 프로젝트에서 아키텍처를 구성하며 실제로 구축까지 완료해야 했는데 우리의 아키텍처에서 붉은 박스 영역을 보면 ElastiCache를 배치할 Private Subnet 중 Application Subent, DB Subnet 어디에 배치해야할지 감이 잡히지 않았다. 문제 원인누구나 Application과 DB 사이에서 중간 역할을 한다는 것을 알 수 있을텐데 이 부분에 대한 명확한 기준이 있지 않으면 언젠가 또 다른 서비스에서 같은 고민을 할 것 같았다. 문제 해결해당 서비스의 책임에 대해 깊게 생각하면서 ElastiCache는..