안녕하세요, 강의 잘 듣고 있습니다. 양질의 강의 감사드립니다. Sorted Set을 활용한 리더보드 강의 시청 후 궁금한 점이 생겨 질문 남깁니다. Redis 공식 문서에 따르면 Score가 동률일 때 사전순(lexicographical)으로 처리된다고 명시되어 있는데요, 실제 비즈니스 환경에서는 사전순이 아닌 여러 기준을 복합적으로 비교해야 하는 경우가 많을 것 같습니다. Score가 64비트 부동소수점임을 활용해, 자릿수별로 기준을 나누는 방안(예: 1~8자리는 기본 점수, 9~12자리는 2순위 기준, 13~15자리는 3순위 기준 ...)도 생각해 보았습니다. 다만 동률 비교 기준이 많아지거나 기본 점수 자체가 클 경우 double 정밀도 한계로 인해 적용이 어렵겠다는 생각이 들었습니다. 실무에서는 이러한 복잡한 동률 상황을 어떤 방식으로 처리하는지 팁을 여쭤봐도 될까요? 감사합니다.
안녕하세요. 먼저는 기억하기 어려울 수도 있는 부분을 잘 정리하시고 전달해주셔서 감사합니다. 명쾌한 설명과 구조 정리 덕분에 명쾌하게 이해할 수 있는 것 같습니다. 구조와 테스트 면에서 제가 잘 몰라서 궁금한 부분에 대해 여쭤보고 싶습니다. Singleton 구현을 보다가 문득 생각이 드는 부분이 있었습니다. GameEngine을 만들 때 생성자를 public으로 만드셨는데 이 부분에서 API를 가져다 쓰는 입장을 생각하면 생성자를 private으로 만들고 Get만 공개하는 것이 더 안전하지 않았을까 하는 생각이 들었습니다. 두 번째로는 이런 전역 객체는 어떻게 테스트 하는가 입니다. 테스트도 마땅히 들어가야 할 것으로 알고 있는데 이 부분은 뒤에 나오겠지요?
라우팅 테이블 설정 이전에는 SSH를 통한 EC2 접속이 안된 것을 확인했습니다. 라우팅 테이블을 설정하시면서 라우팅 테이블과 서브넷, 라우팅 테이블과 IGW를 연결 이 목적이 서브넷 안에서의 요청이 라우팅 테이블을 거쳐 IGW로 나가도록 하는 것으로 이해 이후 SSH로 EC2 접속 가능 내부에서 외부로 나가는 설정을 한 것으로 이해되는데 왜 외부에서 내부로 들어오는 설정도 같이 된 것인지 궁금합니다. --- 추가적으로 NAT 게이트웨이에 대해서 학습을 했습니다. 라우팅 테이블에 대한 설정은 IGW와 서브넷과의 연결 방식이 별반 차이가 없었습니다. 그러면 외부인터넷용과 내부 인터넷 용을 가르는 건 라우팅 테이블이 아니라고 생각이 듭니다. 라우팅 테이블은 기본적으로 양방향 통신을 지원하고 다만 NAT 게이트웨이가 단방향성을 띄어 이 성향을 이어 자동으로 내부 인터넷용으로 사용되고 IGW는 양방향성을 띄기 때문에 자동으로 외부와의 소통 시 사용하는 모듈로 이해하면 될까요?
frontend 와 backend jwt 주고 받을때 controller 에서 @User 라는 데코레이션 혹은 그냥 @AuthenticationPrincipal AuthenticatedUser authenticatedUser, 만들어두고 사용하곤 했었는데 레파지토리를 나눠버렸을때는 어떻게 관리를 하게 되나요 ??
강의 잘듣고 있습니다! 도출된 애그리거트와 의문이 생겨 질문드립니다. 제가 알고 있는 Aggregate는 "여러 객체를 하나의 일관된 단위로 묶은 클러스터" 이고, Aggregate Root가 존재하며 외부에서는 Root를 통해서만 접근해야 한다고 이해하고 있습니다. 근데 노란 포스트잇으로 도출된 애그리거트 들은 객체를 하나의 일관된 단위로 묶은 클러스터의 개념은 아닌거 같아서요 세번째 강의의 코드만 대략 보고왔는데 이벤트 스토밍으로 도출된 애그리거트와는 조금 다른거 같아 질문드립니다ㅜ_ㅜ
레디스 서버 한대가 죽더라도 락의 안전성을 보장하기 위해 3~5대의 다른 레디스 서버도 함꼐 있는거라면 이 서비스의 경우에는 레디스의 데이터를 모두 동기화시키는 작업이 매 요청마다 실행되는 건가요? 동기화 시키는 과정에서 TTL 에 작은 차이가 생길 수도 있디고 생각하는데 무시가능한 정도인지요?? 동기화를 시키지 않는다면 또 그 여러대의 레디스 서버가 봐라봐야할 한 곳이 다시 존재하게 됨으로써 어짜피 똑같은 건 아닌지.. 궁금합니다!
stream_notices 내부의 event_generator 함수 코드에서 yield f"data: {data}\\n\\n" 위의 개행 문자에 이스케이프가 두번 들어가서 메시지가 정상적으로 전송되어도 파싱 오류로 화면에 표시되지 않는 문제가 있는것 같습니다. 해결책은 이스케이프 문자를 하나만 사용하면 개행도 정상적으로 되고 문자열도 올바르게 출력됩니다. yield f"data: {data}\n\n"
# Redis 6.2 이상일 경우 GETDEL 사용 권장 # saved_code = await rd.getdel(cache_key) 이 코드 사용을 권장하셨는데 입력 값 비교 검증까지 통과하기 전에 값을 가져와서 바로 지워버리면 사용자가 실수로 인증번호 입력을 실패해도 다시 요청하도록 해야하는데 이를 감안하고서라도 GETDEL을 사용해야 한다면 이는 verify_code 함수의 원자성을 지키기 위한 권장 사항인가요? 혹은 verify_code 함수에 트랜잭션 관련 설정을 하고 GET과 DEL 호출을 쪼개서 하거나 Redis Functions을 사용하는 것을 고려하는게 더 나은지 궁금합니다.
docker exec -i my-redis redis-cli -x FUNCTION LOAD REPLACE < coupon_logic.lua 위의 기존 코드를 실행시키면 NOAUTH Authentication required 라는 오류가 발생합니다. 이 경우에는 docker exec -i my-redis redis-cli -a <비밀번호> -x FUNCTION LOAD REPLACE < coupon_logic.lua 와 같은 형식으로 입력하시면 정상 등록됩니다. 경고가 뜨긴 하는데 커맨드라인에 비밀번호를 직접 입력하지 말라고 하는거네요.
안녕하세요. 언제나 좋은 강의 만들어주셔서 감사합니다. 강의에서 MSA는 서비스별로 DB를 구축하는 것으로 설명해주셨는데요. 이 경우, 서비스 수가 늘어날수록 데이터베이스도 함께 증가하게 되어 고정비용이 기하급수적으로 늘어날 것 같습니다. 실제로 기업에서 사용하는 MSA 구조에서도 이와 같이 서비스별로 별도의 데이터베이스를 구축하는지 궁금합니다.
안녕하세요 강의 잘 듣고있습니다. MSA 프로젝트 요구사항 및 설계 부분에서 모놀로식으로 설계하게 될때는 FK 를 걸지만 MSA 에서는 DB가 독립적으로 분리되어 있어서 FK 를 걸 수 없을것 같습니다 . Application 단에서도 하지않나요 ?? 예를들어서 @ManyToOne user: User;
