간단한 블로그

아래에 적어두는 방식은 평상시 운영하고 있는 서비스가 특정 이벤트로 인해 더 많은 요청이 들어올 것을 대비하기 위한 계산 방식이다. 단순히 요청량과 CPU 사용률만으로 계산하는 방식으로 신뢰도가 굉장히 낮지만, 기본적인 지표로 삼고 메모리 혹은 로드 밸런서의 부하 등을 감안하여 인스턴스의 수를 조정할 수 있다. 평상시 인스턴스당 요청 처리량 먼저 이벤트 중이 아닌, 평상시 운영중인 서비스의 인스턴스당 요청량을 계산한다. 평상시 피크 타임의 Request 횟수를 획득한 후, 그 값을 인스턴스 개수로 나눠 피크 타임에 인스턴스 하나당 처리되는 요청의 양을 구한다. 평상시 피크 타임(23시 ~ 00시) 총 250,000 Request, 16개의 인스턴스를 사용 중일 때 250,000 req / 16 insta..

BF캐시와 pageshowBack-Forward Cache. BF캐시는 SPA나 다이나믹한 웹 사이트 등 JS의 영향이 커지고 각 페이지의 '무게감'이 커짐에 따라 중요해졌다. 브라우저가 노출하던 페이지를 메모리에 그대로 유지해두고 다른 페이지로 이동함으로써, 사용자의 뒤로가기/앞으로가기 동작시 유지해둔 페이지와 그 상태를 그대로 노출하는 것이다. 간단하게 각 페이지를 스택 구조로 쌓는다고 보면 될 것이다.사용자 입장에서는 보던 페이지를 빠르게 볼 수 있고 하던 작업을 이어서 할 수 있으니 아주 좋은 경험을 할 수 있다. 특히 초기 동작이 느린 SPA기반 사이트에서는 더 큰 도움이 된다. 하지만 FE개발자의 입장에서는 이 BF캐시가 양날의 검이다. '느리다'는 말 대신 화면이 업데이트 되지 않거나(메모리..

최근에 '인클루시브 디자인 패턴'이라는 책을 읽었다. 아무래도 퍼블리싱-디자인에 가까운 내용이고 대부분의 사용자가 모바일 기기를 사용하며 제공하는 서비스가 아주 다이나믹한(그래서 이 책에서 자주 언급하는 스크린 리더와 전혀 어울리지 않는), 그리고 인터넷 속도의 저점이 매우 높은 우리나라에는 어울리지 않는 내용이 많았다. 하지만 그 중에서도 충분히 주의깊게 읽어 볼만한 내용들이 있었기에 그 내용들을 지금의 내가 가진 생각과 더불어 간략하게 적어두려고 한다. 인클루시브 디자인 인클루시브 디자인이란 타깃이 아니라고 생각되는 소수의 사용자, 그러니까 흔히 말하는 장애인, 고령자, 다른 언어를 사용하는 외국인 등이다. 따라서 우리나라에서는 당연하게 무시하는 스크린 리더 사용자를 포함한다. 이전 어느 웹툰 회사에..

내가 2022년 상반기에 진행했던 프로젝트는 사내에서 PDP라고 불리던(이곳에서는 호텔,모텔,펜션,게스트하우스 등 국내 숙소의 상세 정보 페이지를 통칭한다) 상세 페이지를 완전히 새롭게 개발하여 기존 페이지를 대체하는 작업이었다. 개발하기로 하여 사전 회의에 모두 참여했던 담당자가 퇴사하는 바람에 갑자기 맡게 된 프로젝트로, 2명이 약 5개월간 개발을 진행했다. 나는 페이지에 노출되는 숙소의 위치, 정책 등 상세 정보, 후기, 그리고 쿠폰 정보 등을 주로 담당하여 개발했다. 이 프로젝트는 기존 하나의 프로젝트에서 노출하던 영역을 새로운 도메인이자 서비스로 분리하여 개발하는 마이크로 프론트엔드 개발이었다. Next.js를 이용하여 개발하고 AWS Beanstalk를 이용해 배포되었기에 새로운 도메인이 추가..