프로젝트 설명
목적
•
Elastic Search 서버에 직접적으로 요청을 보내므로 서버자체의 보안성이 굉장히 떨어짐, 중간에 한번 서버를 은닉하기 위한 필요성을 느꼈음
•
종종 바뀌는 EC2 인스턴스 아이피에 대응하여 고정적인 IP에 대한 요청을 중계해주어 백엔드 서버가 불필요한 리소스 낭비를 방지하기 위함
구현하고자 했던 기능
•
기존 Elastic Server에 대한 직접적인 Request를 서버를 통해 중계 처리하고자 했음
•
Elastic Server 자체 Security 향상
기술스택
•
Spring Boot
•
Java
•
Nginx
KPT
Keep
•
작업 전과정에 있어서 구글링을 적극적으로 사용해보며 구글링 실력을 향상시킬 수 있었다.
•
RestTemplate → WebClient → RestTemplate Library를 2번이나 바꿨다.
◦
단순하고 사용이 쉽다는 RestTemplate을 처음에 도입했는데, GET Request에 Body를 붙여야한다는 조건 때문에 WebClient의 Method를 사용하려고 변경했었다가 ElasticSearch의 Search Request는 POST도 받는다는 걸 알게 되고서는 다시 단순하고 간단한 RestTemplate로 변경했다. RestTemplate을 사용했는데 단순하고 구현이 쉬워서 좋았다.
Problem/Try
•
WebClient냐 RestTemplate이냐 그것이 문제로다
◦
ElasticSearch의 Search Request는 GET으로 일반적인 GET Request와 달리 Request Body가 필요함
◦
WebClient의 Method와 같이 요청 타입을 명시하지 않은 함수에 GET Method와 같이 Body를 끼워날리려했다.
◦
RestTemplate보다 WebClient가 더 잘 되어 있는 것 같아 사용해서 구현을 시도했다.
•
Json 형태의 Request Body Controller에 입력받기
◦
Data 받는 것부터가 난관이었다.
◦
Request Mapping으로 지정된 경로에 Post Request로 Data를 받아보려 했는데, 이상하게 Request Body용으로 만들었던 Payload의 객체에 값이 제대로 들어가지 않았다.
◦
알고보니 payload의 field type 문제였다. MultiValueMap을 Map으로 변경해주었더니 됐다..!
느낀점
•
급하게 요청 받아 개발을 진행해 개선할 점이 많은 프로젝트였다. 추후 시간이 난다면 리팩토링을 진행해야겠다.
◦
Controller url
◦
Service 비즈니스 로직 분리
•
일주일 정도 진행한 짧은 프로젝트였지만 요청을 받고 요청에 대한 Data를 가공하고 다시 Response로 반환해보는 과정을 거쳤다는 점에 대해서 실속있었다고 생각한다.
•
코드를 누가 보더라도 쉽게 이해할 수 있도록 구조를 설계하고 최대한의 비즈니스 로직을 단순화시키는 과정이 재밌었다.
참고
•
Http Get 요청에 request body 붙이기
•
