./gradlew clean build 하면 오류가 생깁니다.

사실 Java 버전에 대한 문제는 버전을 맞춰주는 방법이 가장 효과적입니다.JVM 버전을 변경을 못하시는 이유가 있으실까요?

템플릿의 대한 정보는 sesclient에 왜 넘겨주나요?

템플릿을 통해서 어떤 이메일 형태를 보낼지가 결정이 되기 떄문입니다.해당 데이터를 DB에 보관을 하셔도 되고, 그냥 소스상에서 HTML 형태로 구성을 하셔도 됩니다. 그거는 개발하시는 상황에 따라서 달라지는 부분이라 고려해보시고 편하게 적용해보시면 될 꺼 같아요.

혹시 대규모로 메일 발송을 해야할 땐 어떤 조치를 해야하나요?

음 제가 어떤 상황인지를 정확하게 인지를 하지 못해서 저는 다음과 같은 상황을 가정해보겠습니다. 대량의 메일발송이 진행이 된다면, 일부 크론잡 스케줄러를 통해서 주기적으로 원하는 대상을 인식하고 메일을 전송한다고 가정해볼게요. 그러면 일단 원하는 데이터는 긁어왔을것이고, 원하는 이메일 형식도 긁어왔다고 가정을 하겠습니다.예를들면, A라는 사용자에게는 A라는 이메일을 전송을 해야하고B라는 사용자에게는 B라는 템플릿의 이메일을 전송을 해야 합니다.이 두가지 모두 DB를 통해서 관리가 되거나, 굳이 DB 데이터가 필요가 없다면, 내부 HTML파일의 형태에서 관리를 하셔도 됩니다. 이렇게만 가져오면, 그렇게 큰 문제가 없다고 생각을 합니다. 저는 단순히 API 요청에 따라서 메일을 전송하는 형태라서 Bulk형태로써 전송을 하지는 않아서 해당 부분에 대해서 잘 모르는 부분이 있을 수 있는데 Bulk형태의 메시지를 전송하는 Method를 지원해준다면, 해당 메서드를 활용하면 되고없다면, 단순히 긁어온 데이터에 대해서 템플릿을 주입해서 사용하는 형태로 구성하시면 될 꺼 같습니다.하나씩 보내도 문제가 안되는 이유는, 일단 발생하는 부하가 내부 DB와 같은 내부 시스템이 아니고 AWS에서 발생을 하며, AWS에서는 전송하는 메일 당 비용이 부과가 될 것이기 떄문입니다.

작동하는 방법

넵넵 맞습니다. 동시에 실행시키실 필요는 없지만, 작동을 시켜보시려면 둘다 결국 필요하시니 둘다 실행시켜주시면 될 꺼같습니다.안전하게 서버 실행 이후, Clinet를 실행시키면 좀 더 편하게 실행 가능하실꺼 같아요.

Package 구성

이건 개인적인 스타일이라고 생각하셔도 됩니다.외부에 빼는 방법도 있겠지만, 저는 항상 개발할때마다 API의 경우에는 domain에서만 repository를 주로 사용을 하기 떄문에, 내부에서 관리를 하는 편입니다.

Redis란 무엇인가? 질문사항

아 제가 설명드린 부분에 있어서 살짝 오해가 있을 수 있겠네요 ㅠㅠ 인지를 하였습니다.생각하고 고민하신 부분이 맞습니다. 제대로 이해하신거에요 단순히 HDD같은 하드디스크 모델이 아니라 SSD같은 고성능 디스크 모델을 사용하기 떄문에, Redis가 비싸지만 효과적이며, 일반적인 DB에 대해서 더 빠른 성능을 보장한다.물론 DB도 상황에 따라 SSD같은 디스크를 활용하며 캐시를 적용하지만, Redis만큼 범용적으로 적용을 하지는 않죠 이정도만 간단하게 이해하셔도 될 꺼 같습니다!혹시 추가적으로 더 자세히 알고 싶은 부분이 있다면 추가로 질문 부탁드립니다.알람이 오지 않아서 확인이 늦어 죄송합니다.. ㅠ

@Transactional(transactionManager = "createChatTransacationMansger") 질문 있습니다.

음 이 부분은 아마 직접 해보시면 이해가 되실겁니다.물론 매니저에 대한 어노테이션을 사용하시지 않으셔도 됩니다. 제가 말씀드리고 싶은 부분은 해당 프로젝트에서는 MySQL에 대한 Transaction격리 수준을 제어하는 Config 파일을 작성을 하였어요. 이렇게 작성이 되면, Spring에서 자동으로 Transaction을 관리해주지 않습니다.그래서 안정적인 운영을 위해서 Jpa나 DB를 조회하는 부분에 대해서 Manager 어노테이션을 붙여주셔야 합니다.여기서 그냥 일반 Transaction을 사용하셔도 되고 Manager을 사용하셔도 됩니다.그런데 그냥 코드의 통일상 Manager를 사용하시는걸 추천드리는 겁니다. 아마 가장 쉬운 이해는 직접 어노테이션이 없는 상황에서 적용을 해보셨을 때, DB에 데이터가 제대로 들어가는지 확인해 보시면 될 꺼같습니다.flush를 사용하시면, Tx를 제대로 담지 못했다는 에러가 발생 하실 겁니다.딱히 에러는 없고, 단순히 Spring에서 해당 Transaction을 인식하고 처리하지 못하는 케이스가 발생 합니다. 한번 해보시고, 추가적으로 궁금하신 부분 질문주시면 감사하겠습니다!!

강의 들으면서 블로그에 올려도 될까요?

안녕하세요 질문 주셔서 감사합니다.강의 관련된 내용을 블로그에 올리시는 것은 상관이 없지만, 출처는 남겨주시기를 바라겠습니다.또한어느정도의 자신의 언어로 순화하고 이해한 내용을 바탕으로 올리시면 좋을 꺼 같습니다.감사합니다 :)

OTP_ISSUER 가 2번 들어가는 이유 문의

안녕하세요 질문 주셔서 감사합니다:)먼저 OTP를 생성하는 해당 변수값은 일종의 리터럴한 형태입니다. 해당 규칙을 지켜야 하는 형태로써 사용이 되는 것이죠 그래서 가장 일반적인 형태를 지켜주기 위해, QR 코드의 형식을 지켜주기 위해서 URL 이러한 형태로써 구성을 하였다고 이해하시면 될 꺼 같습니다 :)

실 서비스 환경 문의

1번 질문 일단 제 경험상 아직까지 풀이 가득 차는 문제로 인해서 발생하는 이슈는 없었습니다.이러한 풀에 대한 부분은 기본적인 클라이언트 설정을 통해서도 할 수가 있지만, 여러개의 인스턴스를 통해서 로드밸런싱 처리가 들어가기 때문에 적절한 정책이 주어진다면 큰 걱정은 안하셔도 된다고 생각합니다. 2번 질문 소켓 컨트롤러에 있는 SendTo 어노테이션을 의미하시는걸로 이해를 하였습니다.해당 어느테이션은 단순히 어떤 경로로 요청을 내려줄지에 대한 부분인데, 결국 다중 인스턴스에 접근을 하는게 아니라 최종적으로 하나의 인스턴스에서 내려주는 결과값을 사용할텐데, 어떤 부분에서 문제가 생길 수 있는지 좀 더 자세한 설명 부탁드립니다. 저는 아직 어떤 문제점이 발생가능한지 크게 느끼지 못했습니다. 자세한 설명 추가해주시면 그에 맞춰서 대답해드리도록 하겠습니다. 3번 질문 실 운영환경을 어떻게 구성하냐에 따라 다릅니다. 결국 WAF같은 부분을 말씀하시는거 같아요.앞단에서 무언가를 필터링 해주는 것은 들어가게 됩니다. 저는 실무에서 NGINX는 사용하지 않고 AWS의 서비스를 활용하는 것으로 알고 있습니다. 음 주의해야 하는 부분은 롤링이 동작할 떄 주의하셔야 합니다.기본적으로 커넥션을 물고 있는 형태이기 떄문에, 해당 커넥션과 연결이 끊기게 되면 그에 따른 문제가 발생 할 수가 있습니다. 이 처리를 Front에서 후속 조치를 할 수도 있습니다. 저는 개인적으로 Front에서 일부 처리하는것을 지향하는 편입니다.왜냐하면 서버에서 이러한 커넥션들을 지속적으로 기록하고, Connection 문제에 따라서 다른 Connection으로 옮겨줘야 하는 과정은 꽤나 복잡하고 리소스도 많이 잡아먹는 작업입니다. 구현을 하게 된다면 Kafka같은 이벤트 스트리밍 툴을 활용해서 간단하게라도 구현을 할 수는 있겠지요. 이래서 제가 간단하게 생각을 해보았을떄는 이런 Connection이 끊기는 상황에 대해서 주의해야한다고 생각을 합니다. 저는 실무에서 Connection이 끊기면 그냥 retry하는 방향으로 동작을 하는데, 이는 작성하는 방법에 따라 다르겠죠. 회사에 따라 다르겠지만 WAF에 대한 구체적인 설정은 사실 서버 엔지니어가 다루지 않고, DevOps엔지니어가 주로 다루게 됩니다. 해당 부분은 제가 추후 실무를 처리하고 계시는 엔지니어 분께 한번 물어봐서 추가적으로 아는 부분이 생긴다면 공유해 드리도록 하겠습니다.아 그리고 아셔야 하는 부분이 있다면, Wss 통신도 결국 HTTP에 헤더를 추가한 형태 입니다. NGINX에서도 이러한 처리가 되는걸로 알고 있는데, 해당 부분을 알아보시는것도 한가지 방법일꺼같네요.