기억보다 기록을

멋지고 꼼꼼하게 글을 쓰고 싶지만 .. 그렇게하면 자꾸 미룰 것 같아서, 내가 나에게 알려주는(?) 용도로 기록한다. # N+1 문제가 무엇이냐면 아주 간단히 말하자면 쿼리가 날아갈 때 기존 쿼리에 의해 다른 쿼리도 N번 날라가서 , 원래 날리려던 쿼리(1) 에 N번의 쿼리도 추가로 실행되는 문제가 생긴다. 저는 멤버만 조회하려 했는데요 갑자기 멤버가 속한 팀도 우후죽순 카타시안 곱처럼 (정확한 비유 아님) 짠하고 나왔어요 그럼 어떤 문제가 생기냐면. 디비에서 값을 내려서 실행할 때 최소한의 데이터를 받아야하는데 데이터가 와르르맨션처럼 몰려와서 서비스: 나 무거워 내 성능 힘들어 상태가 된다. 우리는 이 문제를 해결하기 위해 1. fetch join 사용 2. @batchsize 어노테이션 사용 3. D..

Intro. 알림 시스템(Notification system) 을 갖춘 어플리케이션 프로그램은 고객에게 중요할 만한 정보를 비동기적으로 제공한다. 최신 뉴스, 제품 업데이트, 이벤트 등이 여기에 해당한다. 알림 서비스는 한번에 다량의 메세지를 보낼 경우를 생각하면 신중히 설계되어야한다. 또한 알림 시스템은 모바일 푸시 알람에 한정되지 않는다. 알림 시스템을 개략적 설계하고 이를 최적화 하는 단계를 들여다보자👍 [1단계] 문제 이해 및 설계 범위 확정 : 하루에 백만 건 이상의 알림을 처리하는 확장성 높은 시스템을 구축하는게 쉬운 과제가 아니므로, 어떻게 구현되는지 대화를 통해 개략적으로 이해해보자. 1. 어떤 종류의 알림을 지원해야 하는지? - 푸시 알림, SMS 메시지, 그리고 이메일이다. 2. 실시간..

Intro. 요즘 대규모시스템설계 스터디를 하면서 첫 발표가 4장이었다. 발표용으로 내용을 간략하게 정리했는데, 책의 리소스가 정말 좋기도 하고 참고문헌을 타고 가다보면 재밌는 사례가 많다. 책의 내용만 흡수해도 정말 많이 발전하겠구나 싶고. 시스템 디자인에 대해 고려해본 적이 없던 주니어 엔지니어가 이 책을 읽으면서 그 동안 "궁금했지만 정확히 어떻게 질문해야할지 몰라 모호했던 것들"을 구체화하며 알아가는 과정이 재밌다. 많은 사람들이 좋은 책이라 말하는 이유를 알겠다! [04] 처리율 제한 장치의 설계 ✏️ 처리율 제한 장치(rate limiter) : 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)를 제어하기 위한 장치. 예를 들어 HTTP에서 이 장치는 특정 기간 내에 전송되는 클라이언..

종료된 컨테이너를 ps -a 해서 매번 rmi 하는 것이 번거로우니 (도커 카테고리 첫번째 글 참고) 아래 명령어를 통해 한번에 삭제해줄 수 있다. 맥os 기준이고 윈도우는 다르다. 복사해서 터미널에 붙여넣기하면 된다. docker stop $(docker ps -q) docker rm $(docker ps -a -q) docker rmi -f $(docker images -q) $( )는 명령어 실행 시 return 값을 문자열 형태로 반환한다. 1. docker ps로 현재 실행중인 프로세스 확인 (nginx, httpd) 2. 위의 명령어 실행 -> 모두 deleted 됨 3. dockder ps 로 다시 확인 -> 실행중인 컨테이너 모두 사라짐

우선 도커허브에서 톰캣을 풀 받고 실행하자 그럼 localhost:8080로 연결했을 때 실패한다. 왜냐면 브라우저가 request 날린 곳은 기존 host OS이지 도커 컨테이너가 아니다. 그럼 어떻게 하냐면 Browser -> host OS로 요청하면 host OS는 container로 redirect 시켜줘야 한다. 그걸 포트포워딩이라 한다. 포트포워딩은 어떻게 하냐면 -d : 데몬으로 실행, 즉 백그라운드에서 계속 돌게 한다. docker pull httpd: 아파치 이미지로 컨테이너 생성을 위해 pull docker images : 이미지 확인 ps 로 프로세스 확인했을 때 톰캣이 돌고있다면 꺼주자 (stop _ (_에는 container ID 입력)) stop 시키고 다시 ps 로 stoppe..

stop했으니 rmi 명령어를 통해 삭제가능할 것 같지만 안된다. (image is being used by stopped container) 즉 stopped가 아닌 deleted 상태로 전환 필요 그래서 docker ps -a (-a는 all 의 약자, 프로세스 전부 보여달라는 명령어) 하여 container ID 확인 후 rm 명령어 통해 종료된 컨테이너를 remove한다 그 이후 remove image 성공 docker images를 입력하면 getting_started image가 삭제되었음을 확인 가능하다.

1. 문제상황 유저가 정보를 수정할 때 (클라이언트가 서버로 업데이트 리퀘스트를 날릴 때) 비밀번호값을 입력하는데 값을 입력해도 자꾸 "raw password cannot be null" 이 나왔다. 값을 입력했는데 null로 인식되는게 이상해서 1) 프론트단에서 값을 잘못 받았나 2) 백에서 유효성 검사를 하는 중에 에러가 난건가 3) BCryptPasswordEncoder가 제대로 안먹고 데이터가 꼬였나 4) 영속성 단계에서 내가 뭔가 잘못 설정했나? 라는 생각이 들어서 하나씩 원인이 될 수 있는 것들을 살펴봤다. 1) 프론트단에서 값을 제대로 받고 있는가 -> js, jsp 모두 제대로 값을 받고 있었다. 2) 유효성 검사 제대로 됐나? -> 제대로 된 것 확인했다. 유효성 검사가 제대로 되어서 r..

패킷 스위칭으로 서킷 스위칭 (선이 계속 늘어나는 방식)의 단점을 보완하고 비용이 덜 드는 방식으로 데이터를 전송할 수 있다. 데이터의 헤더엔 출발지/목적지/조립 순번등을 적어 데이터와 함께 보내고 라우터에선 패킷 포워딩 (근처의 라우터로 포워딩한다) 을 진행한다. 라우터를 통해 목적지에 도착한 패킷은 재조립을 통해 정리된다. 목적지 정보가 중복되어 충돌날 수 있기에 유일한 값이 필요한데 그게 바로 IPv4, IPv6 방식이다. 유일한 값을 헤더에 설정하여 보냈을 때 라우터를 거쳐 목적지에 도착하게 되고, 도착한 컴퓨터에 여러 프로그램이 떠있는데 이 프로그램들은 각자 포트넘버를 가지고 있다. 그래서 우리 패킷은.. 10.1.5.7:3000 (Ipv4 주소 + 3000포트) 라는 목적지 정보를 헤더에 담고..