본문 바로가기

분류 전체보기

 (161)
JavaSpring @RequestHeader 사용시 주의점 문제 사항 프로젝트에서 요청받은 전체 Header 정보가 필요했다. JavaSpring에서 지원해 주는 @RequestHeader를 통해 전체 Header 정보를 HashMap에 담아 사용을 했다. 로컬 서버를 돌려 기능 테스트 해보니 정상적으로 HashMap에서 Header 정보를 가져오지 못하고 있었다. ✔ 이유 Header의 key값이 잘못 되었던 것이었다. AWS CF에서 전달해 주는 Header를 명세를 확인하고 정확히 입력을 했는데도 불구하고 실제 출력해 보니 대문자, 소문자 차이가 있었던 것이다. ✔ HttpServletRequest.getHeader는 정상적으로 돌아갔던 이유 그동안 사용했던 HttpServletRequest.getHeader는 대소문자 구분 없이 정상적으로 돌아갔다. 그..
AWS API 사용에 있어 요청 할당량 고려하기 App Notification Push를 위한 자체 유틸 함수 사용 💬 이번에 회사에서 별도의 push 서버를 만들기로 했다. 이를 위해 기존 push를 날리는 함수에 대해 성능 테스트를 하기로 했다. 테스트 결과를 통해 push 서버를 만드는 과정에서 고려해야 할 사항들을 체크하기로 했다. ✔ 테스트 진행 💬 1만 유저에게 push를 보내는 테스트를 했는데, 소요되는 시간이 10분이 넘어갔다. 시간을 줄이기 위해 Thread 10, 20개로 늘려가며 추가적인 테스트를 했다. 그랬더니 throttling 예외가 발생을 했다. 초당 처리량이 200~300건 밖에 안되었는데 기존 함수에서 사용하고 있는 AWS SNS API에서 성능 제한을 위해 throttling이 발생한 것이다. ✔ 원인 파악 💬 AWS ..
Java에서 AWS SDK를 사용할 때 발생하는 Warning & Error 로그 제거 AWS SDK 2 Version을 적용했을 때 발생한 Warning & Error 💬 Java Spring Project에 AWS S3 사용을 위하여 의존성을 추가하여 사용하였다. 그 이후부터 아래와 같은 Warning과 Error가 발생하기 시작하였다. 서버를 가동하는 데에는 문제가 없어서 그동안 놔두었는데, 유의미하지 않은 Warning과 Error의 메시지가 계속해서 뜬다면 실제 중요한 로그를 놓칠 수 있다고 판단이 되어 이번 기회에 해결하기로 했다. ✔ Warning 문구 [main] WARN com.amazonaws.util.EC2MetadataUtils - Unable to retrieve the requested metadata (/latest/meta-data/instance-id). Fa..
Map vs DTO 사용 현업 코드를 작성하며 Map 사용 💬 입장 대기열을 위한 코드를 작성을 하게 되었다. 코드 작성을 하며, 요구 사항이 계속해서 변경이 되는 상황이었다. 그러다보니 User 데이터에 저장이 되어야 하는 값들이 계속해서 변경이 되었다. 유연하게 데이터가 변경이 되더라도 대응 가능한 Map을 사용하기로 했다. ✔ Map을 사용하며 느낀 장단점 💬 Map을 사용을 하다보니 계속 변경이 되는 저장 값들을 쉽게 대응할 수 있었다. 처음에는 빠르게 작업을 진행하는 데에 많은 도움이 되었다. 그런데 코드가 늘어나고 대기열 User 데이터가 사용되는 곳이 많아지자 오히려 작업 속도가 현저히 줄어들게 되었다. User 데이터를 가져다가 사용하기 위해 들어있는 Key 값을 기억하고 있어야 했으며, 상황에 따라 뭐가 들어있었..
2023년을 돌아보며... 재취업을 위한 노력 ✔ 6개월간 취업 도전 사이드 프로젝트를 하면서 이력서를 작성했다. 작성이 완료된 이력서로 7~80군데를 넣었지만 좋은 소식은 얻을 수 없었다. 몇 군데를 커피챗과 면접을 보긴 했지만 공고와 달리 실제로 사용하는 기술 스택이 다르거나 비전이 보이지 않아 포기를 하게 되었다. 첫 취업 때 경험을 통해 신중하게 내가 성장할 수 있는 회사를 고르기 위해서였다. ✔ 항해 99 진행 이후 더 이력서를 제출했지만 서류부터 통과가 되지 않았다. 관련된 사이드 프로젝트가 하나뿐이고 내가 가진 역량을 보여줄 수 있는 자료들이 부족했기 때문이라는 생각을 하게 되었다. 혼자 준비할 수 있으면 좋겠지만, 내 성격상 상황이 주어져야 더 잘할 수 있기 때문에 기간이 짧은 부트캠프를 알아보게 되었다. 항해 9..
Redis I/O에서 생기는 동시성 문제 이슈 💬 회사 프로젝트에서 캐싱을 위하여 Redis를 사용을 하고 있다. 일반 로직에서 캐싱을 읽고 업데이트 해주는 작업이 같이 수행이 되었다. 트래픽이 발생하기 이전에는 응답 시간이 짧아 Redis I/O에서 발생하는 문제는 발생하지 않았는데, 트래픽이 몰리면서 중간 로직의 응답시간이 길어지면서 Redis I/O 과정에서 업데이트를 하기 이전에 데이터를 읽어가는 문제가 발생하게 되었다. 대응 방안 고민 💬 하나의 자원에 하나의 스레드만 접근을 하여 처리를 할 수 있어야 데이터의 무결성이 깨지지 않을 수 있다. 무결성을 지켜주기 위하여 하나의 자원에 접근을 제한하는 Synchronized, Lock 등을 고려해볼 수 있었다. 회사에서는 서버를 Scale-out을 하여 여러대를 운영을 하고 있었기 때문에 ..
[240121] 어뷰징 관련 내부&외부 허가 IP 적용 어뷰징 로직을 적용하고 간과한 것 💬 어뷰징 로직을 적용을 하고 생각지 못한 문제가 발생했다. 외부와 내부에서 허용을 해줘야 하는 IP도 벤을 걸리는 현상이 발견되었고 그로 인해 서비스 운영이 일시적으로 문제가 되었다. ✔ 내부 IP 벤 문제 발생 💬 회사 내부에서는 공통적으로 적용되는 로직은 별도의 프로젝트로 만들어 의존성을 부여를 했다. 어뷰징도 그런 로직 중 하나였고 외부 통신하는 프로젝트에만 의존성 업데이트를 했었기에 문제가 되지 않았다. 하지만 내부 통신하는 쪽 코드에 어뷰징이 담긴 모듈의 의존성을 업데이트해야 하는 상황이 발생했고 그로 인해 내부 IP에도 어뷰징 관련 로직이 적용이 되어 벤이 되는 현상이 나타난 것이다. ✔ 내부 IP 벤 대응 방안 💬 서버의 IP는 서버가 꺼졌다가 켜지거나, ..
[231210] 필요 없는 Warning Log를 제외시키기 필요 없는 Warning Log를 제외시켜야 하는 이유 💬 API를 개발하면서 무심코 무시했던 Warning들이 많았다. 실제로 코드를 실행시키는 데에는 문제가 없었기 때문이었다. 그런데 회사에서 API를 개발하면서 필요 없는 Warning까지 전부 Log에 찍히게 된다면 실제로 중요한 Warning을 놓치게 된다는 것을 알게 되었다. ✔ Project에서 Warning을 대처하기 💬 최대한 Warning이 발생하지 않도록 코드를 작성하는 것이 옳다. 하지만 Warning을 신경 쓰면서 코드를 작성할 경우 가독성이 많이 떨어지는 경우 가끔 마주하게 되는데, 이 때는 오히려 Warning을 무시하는 것이 더 좋은 방법인 것 같다. ✔ Java에서 Warning 무시하기 💬 Warning을 간단하게 무시하는..

티스토리툴바