본문 바로가기

반응형

전체 글

(133)
429(Too Many Request) 에러 해결하기 최근 Poe Build Cost 프로젝트를 진행하다 어느정도 사용가능한 상태가 되어, AWS에 배포 후 커뮤니티에 홍보를 했었다. 근데, 이때 생각지 못한 429 에러 문제가 발생했고, 이 문제를 해결하기 위해 다양한 방법을 시도했다.HTTP 429 (Too Manay Request)서버에서는 과도한 요청에 대해 부하를 방지하고자 HTTP 요청에 제한을 두기도 하는데, 이떄, 클라이언트에서 서버로 너무 많은 요청을 보낼 때 발생하는 에러이다. 내가 마주한 429 에러 상황문제 상황1. Poe Build Cost에서는 10~20개 가량의 아이템의 시세를 Path of Exile Trade(이하 POET)에 아래와 같은 형식의 데이터를 10초 간격으로 POST API로 요청을 보내고 응답 값으로 각 아이템 ..
Pob Build Cost 프로젝트 진행 배경 사람들이 사용해주는 서비스를 만들고 싶었다. 이전에 프로젝트들을 진행할 때면 시간이 지날수록 '이걸 완성하면 사람들이 사용할까?'라는 물음에 대한 답이 희미해져 갔다. 점점 의미없는 프로젝트를 하는 것 같았다. 그래서, 이번 프로젝트를 진행할 때는 사람들이 사용해주는, 실제 사용자가 있을 서비스를 만들고 싶었다. 실제 사용자를 확보하기 위해선 나름 고민해 본 결과 아래와 같이 정리되었다. 비슷한 서비스가 없고, 특정 사람들에게 필요해야 할 것. 매니악한 주제와 관련이 있으면, 확고한 사용자 층이 확보하기 쉬울 것 같다. 따라서, 기존에 비슷한 서비스가 없으며, 매니아들이 많은 서비스를 고민하다가 예전에 즐겨했던 PoE란 게임이 생각이 났고, 그때 당시 불편했던 것을 도와줄 수 있는 서비스를 만..
[Spring] 디자인 패턴 - 프록시/데코레이터 체이닝 참고 1. 스프링-핵심-원리-고급편, 김영한 참고 2. 위키백과 프록시/데코레이터 체이닝 프록시/데코레이터 패턴은 여러 번 중첩시킬 수 있는데, 이를 체이닝이라고 한다. 아래 사진의 '프록시 패턴 Ex.2'에 해당하는 3번째 구조가 체이닝의 예이다. 아래 그림과 같이 각 프록시/데코레이터는 동일한 인터페이스를 상속받으며, 각 프록시/데코레이터들은 순차적으로 이전 객체를 주입받아 순차적으로 연결된다. 예제 아래는 동작 시간을 측정해주는 데코레이터와 로그를 리포멧팅 해주는 데코레이터를 체이닝한 예제이다. 1. 인터페이스 정의 public interface Component { String operation(); } 2. 문자열관련 데코레이터 @Slf4j public class MessageDecorator ..
[Spring] 디자인 패턴 - 데코레이터 패턴 예시 참고 1. 스프링-핵심-원리-고급편, 김영한 참고 2. 위키백과 데코레이터 패턴의 전체적인 틀은 프록시 패턴과 동일하다. 1. Component 인터페이스 실제 객체와 부가 기능 추가를 위한 데코레이터의 인터페이스를 정의한다. public interface Component { String operation(); } 2. 실제 서버에 대한 객체 실제 서버에 대한 객체를 정의한다. @Slf4j public class RealComponent implements Component{ @Override public String operation() { log.info("RealComponent 실행"); return "data"; } } 3. Decorator 정의 위 실제 서버를 주입받고, 해당 서버에 추가할..
[Spring] 디자인 패턴 - 프록시 패턴 예시 참고 1. 스프링-핵심-원리-고급편, 김영한 참고 2. 위키백과 아래는 캐시 서버 형태의 프록시 예시 코드이다. 1. 인터페이스를 만들기 아래 사진과 같이 프록시와 실제 서버는 같은 인터페이스를 상속받는다. 따라서, 먼저 가장 큰 틀이 되는 서버 인터페이스를 만들어야 한다. 아래와 같이 인터페이스를 만들어 준다. 이후, 프록시와 실제 클래스에서는 Operation을 상속받아 기능을 구현할 것이다. public interface Subject { String operation(); } 2. 실제 클래스와 프록시 만들기 실제 클래스 아래는 실제 서버 클래스이다. 간단히 로그를 출력하고 1초간 정지한다. import lombok.extern.slf4j.Slf4j; @Slf4j public class RealS..
[Spring] 디자인 패턴 - 프록시 패턴(데코레이터 패턴) 참고 1. 스프링-핵심-원리-고급편, 김영한 참고 2. 위키백과 프록시 패턴 프록시는 클라이언트의 요청을 클라이언트 대신 서버로 전달하는 역할을 한다. 즉, 프록시 패턴이란 클라이언트에서 서버로의 직접 요청이 아닌, 클라이언트에서 서버로의 간접 요청을 하도록 중간에 프록시를 두는 방법을 말한다. 프록시 패턴의 이점 중간에 프록시를 둘 경우, 프록시에서 아래와 같은 여러가지 일들을 처리할 수 있다. 접근 제어(프록시 패턴) 권한에 따른 접근 차단 캐싱 (캐시 서버도 프록시 서버 중 하나) 지연 로딩 부가 기능 (데코레이터 패턴) 프록시 객체 조건 클라이언트는 요청이 프록시로 간건지, 서버로 간건지 몰라야 한다. 즉 서버와 프록시는 같은 인터페이스를 사용해야 한다.또한 클라이언트가 사용하는 서버 객체를 프록..
[Spring] 디자인 패턴 - 템플릿 콜백 패턴 참고 1. 스프링-핵심-원리-고급편, 김영한 참고 2. 위키백과 콜백 콜백(함수)는 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 말한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행 혹은 나중에 실행할 수 있다. 이전 글의 전략 패턴에서 Context의 execute를 실행하면, strategy의 call이 실행됐다. 여기서, strategy는 Context 뒤에서 동작하므로, strategy는 콜백에 해당한다. *스프링 내부에서 자주 보이는 패턴으로, GOF 패턴은 아님. *스프링에서 "~Template" 형식의 템플릿들은 템플릿 콜백 패턴으로 만들어져 있음. 예시 1. callback 인터페이스 정의 public interface CallBack { void call(); } 2. ..
[Spring] 디자인 패턴 - 전략 패턴 개선하기 참고 1. 스프링-핵심-원리-고급편, 김영한 이전 전략 패턴은 아래와 같이 새로운 Strategy마다 Context를 새로 생성해야 했다. Strategy strategy1 = new Strategy(); Context context1 = new Context(strategy1);//Context1 생성 context1.execute(); Strategy strategy2 = new Strategy(); Context context2 = new Context(strategy2);//Context2 생성 context2.execute(); 이번에는 Context의 Strategy를 생성자 주입이 아닌 파라미터로 주입받는 방법으로 개선해보자. 이렇게 파라미터 방식으로 주입받을 경우 각 Strategy마다 새..