유레카 외에 최근에 자주 사용되는 서비스 디스커버리는 어떤게 있을까요?

안녕하세요.국내 닷넷계열의 강의 중에선 여러 분야를 다뤄주시고 계셔서 닷넷쪽 지식에서 많은 도움을 받고 있습니다maui 관련 강의도 올려쥬신 만큼 이후에 혹시 블레이저 쪽 강의를 만들어주실 계획이 있으실까요?

안녕하세요!덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다. MSA 전환 시점 관련해서 질문 드립니다.모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요?물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다.예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다.감사합니다!

안녕하세요 재성님.덕분에 AWS 에 대해서 조금더 알게 되었습니다.감사합니다 AWS 로 인프라를 구성했을때비용을 어떻게 예측할 수 있을까요?청구서에서 보는거 말고 이정도 규모면 얼마정도의 비용이 발생할지 알 수 있는 방법이 있을까요?  감사합니다.   

보통 구현 클래스 뒤에 Test를 붙이면 Idea에서 자동 추적을 해줘서 Test로 빠르게 이동이 가능한데,POST_specs 같이 만드신 이유가 있을까요?

안녕하세요 강사님! 강의 잘 듣고 있습니다.실제 서비스 환경에서 로드 밸런서를 두는 시점(예: 트래픽 기준이나 서버 수 기준)을 어떻게 판단하시는지 궁금합니다.단순히 서버 부하율이 높아졌을 때 적용하는 건지, 아니면 아키텍처 설계 초기에 미리 구성하는 경우가 더 일반적인지도 궁금합니다.

안녕하세요 강사님 카프카에서 컨슈머가 메시지를 읽은 후 처리 과정에서 실패했을 때 재처리 전략을 어떻게 잡으면 좋은지 궁금합니다.consume 이후 비즈니스 로직 실행중에 예외가 발생하여 실패한 경우OOM 등의 이유로 서버가 비정상적으로 종료되어 실패한 경우위의 두가지 상황에서 일반적으로 어떻게 처리하는지 궁금합니다.

강의를 들으며 제일 강조하시는게 "요구사항 충족" 이라고 생각했습니다. 처음부터 아키텍처를 정해놓지 않은 상태로 요구사항 충족을 목표로 달리는 형태로 설명해주셔서 TDD의 의미나 철학을 이해하는데 도움은 많이 됐습니다!궁금한 것은 현업에서도 새로운 프로젝트를 시작할때 이와 같은 방식으로, 아키텍처를 특별히 정해놓지 않고 개발하는것이 일반적인가요? 테스트 표면을 통해 아키텍처를 유연하게 변경 가능하다고 하신 말씀도 이해를 했는데 서비스 기획 및 설계 단계에서 서비스의 성격/특성에 맞추어 아키텍처정도는 어느정도 정하고 가는것도 괜찮지 않을까 생각하여 여쭤봅니다!!

우선 좋은 강의 정말 잘 들었습니다. 감사합니다. 그동안 파편화되어 있던 "어떻게 도메인을 분리하는가"에 대한 질문이 강의를 토대로 많이 깔끔해질 수 있었습니다.말씀 주신 방식을 토대로 현재 신규 도입하고 있는 서비스를 이벤트 스토밍을 토대로 구체화해 보고 있는데요.아무래도 강의가 제작되고 나서 시간이 좀 흐른 만큼, 현재에도 해당 방식을 토대로 설계를 해 가시고 계신지, 뭔가 더 좋은 방식이 추가되셨을지 궁금합니다!

안녕하세요. enabled 설정시 1 입력후 esc를 눌러도 wq를 입력 할 수 없습니다. 어떻게 진행햐 할끼요??

안녕하세요 선생님.미션 주신거 이행하면서 궁금해서 질문드려요.다른강의에서 가용성(Availability), 시스템 이중에 대해서 설명해주셨는데..MSA에서 가용성? 시스템 이중을 적용하면..일반 사용자가 서버 끊김을 못느끼게해야하는데..기존의 도커나 쿠버네티스를 2중으로 설정해줘야하는게 맞는지 궁금합니다.예를들어서 강의에서 섷명해주신게이트웨이,사용자서비스,게시판서비스,포인트 서비스가 있다고 할경우..게이트웨이 2개 사용자서비스2개 게시판 서비스2개 포인트 서비스 2개로 해야하는것일까요?

안녕하세요, 강사님! Spring Boot TDD 강의 정말 잘 듣고 있습니다. 강의 내용 중 궁금한 점이 생겨 질문드립니다.보통 Spring에서 개발할 때 Controller-Service-Repository 구조의 레이어드 아키텍처를 많이 사용하는데요, 강의에서는 컨트롤러가 직접 리포지토리의 save 같은 메서드를 호출하면서 비즈니스 로직을 처리하는 경우가 있는 것 같습니다.혹시 이것이 강의의 핵심 내용에 집중하기 위해 코드를 단순화하신 것인지, 아니면 강사님께서 실제로 선호하시는 개발 스타일이신지 궁금합니다. 만약 후자라면 어떤 장점이 있는지 그 이유에 대한 의견을 여쭙고 싶습니다.더불어, "TDD를 잘하려면 인터페이스를 많이 사용해야 한다"는 것이 일종의 오해라는 말씀에 크게 공감했습니다. 그런데 왜 개발자들 사이에서 이런 오해가 생겨나게 된 것인지 그 배경이 궁금합니다.마지막으로 추후에 비즈니스가 복잡해지면 테스트가 깨졌을 때 어디가 문제인지 파악이 어려울 것 같은데요 이에 따른 문제를 어떻게 해결하시나요? 단위테스트를 추가로 작성하시는지도 궁금합니다.

안녕하세요, 강사님. TDD 관련 강의 항상 잘 듣고 있습니다.강의 내용을 따라 실습을 진행하던 중, 테스트 격리 전략에 대해 궁금한 점이 생겨 질문 남깁니다. # 강의에서 다뤄주신 상황강의에서처럼 여러 테스트 메서드에서 동일한 이메일 값을 사용하니, 테스트 클래스 전체를 실행했을 때 JPA의 유니크 제약 조건 위반 에러가 발생했습니다. 이로 인해 개별 테스트는 성공하지만 전체 테스트는 실패하는 상황에서 궁금증이 생겼습니다. # 제가 먼저 생각한 해결책: @Transactional을 이용한 롤백저는 강의를 들여면서 이 문제를 해결하기 위해, 각 테스트 메서드에 @Transactional 애너테이션을 붙여 테스트가 끝나면 자동으로 롤백시키는 방식을 먼저 떠올렸습니다. 이 방법으로 각 테스트가 독립적인 트랜잭션 내에서 실행되고, DB 상태를 다음 테스트에 영향을 주지 않는 상태로 유지할 수 있다고 생각했습니다. ##강사님의 방식(임의 데이터 generator)에 대한 질문##그런데 강사님께서는 강의에서 롤백 방식을 사용하지 않으시고, UUID 등을 활용해 매번 고유한 이메일 주소를 생성해주는 데이터 제너레이터 방식을 사용하셨습니다. 강의에서도@Transactional 을 성능 등 여러가지 이유로 인해 사용하지 않았다고 하셨는데요.@Transactional을 이용한 롤백 방식도 충분히 좋은 해결책이라고 생각했는데, 강사님께서 UUID 생성 방식을 선택하신 특별한 이유나 설계 철학이 궁금합니다.혹시 제가 생각한 롤백 방식에 비해 UUID 생성 방식이 갖는 실용적인 장점(ex. 롤백을 하지 않으니 디버깅의 용이성(?))이 있을까요? 두 방식의 장단점과 어떤 상황에서 어떤 전략을 선택하는 것이 실무에서 더 좋을지에 대한 강사님의 고견을 듣고 싶습니다. 감사합니다!

강의는 gateway로 끝으로해서 끝나느데..에우레카에대한 강의는 없나요?또.. 게이트웨이 설정할때..application.yml에서..localhost:8080/8081/8082 이렇게 하셨는데..실제 서비스할때도 그렇게 적용해야하는것일지 궁금합니다.

OS- 아마존 리눅스 2023 6.1epel 레포지토리 활성화 명령어 입력(amazon-linux-extras install epel -y) 하면command not found 라고 /뜹니다.어떻게 해야 할까요??   

강의를 들으면서 내부 설계에 의존하는 테스트라는 것이 무엇인지 조금 헷갈려서 질문 드립니다. 강의 초반에는 테스트가 내부 설계에 의존해서는 안된다고 말씀 주셨습니다. 내부 설계에 의존하게 되면 테스트가 깨지는 등의 부작용이 발생할 수 있기 때문이라는 점도 함께 말씀 주셨는데, 이번 강의에서는 내부 설계에 의존해야 하는 케이스를 설명 해주셨습니다. 다만 왜 이런 케이스에는 내부 설계에 의존해야 하는지를 확실하게 이해를 하지 못했습니다. 조금 더 자세한 질문을 드리자면내부 설계의 의미내부 설계에 의존해야 하는 이유이 두가지를 잘 이해하지 못한 것 같습니다.내부 설계라는 것이 클라이언트가 실제로 사용하는, 외부로 공개된 인터페이스를 제외한 모든 부분을 말하는 것일까요? 이번 강의에서 내부 설계에 의존해야 하는 이유는클라이언트는 어떤 방식으로 암호화를 하는지 알 필요가 없다.하지만 현재 공개된 인터페이스로는 실제 비밀번호가 평문으로 저장이 되었는지, 아니면 정말 암호화가 이루어져 저징이 되었는지를 확인할 수 있는 방법이 없다.그러므로 실제 암호화 로직을 테스트 해야한다 (내부 설계에 의존해야 한다)정도로 이해했습니다만 제가 맞게 이해한 것인지 감이 오질 않습니다. 요약하자면내부 설계란 외부로 드러난 인터페이스 외적인 것들을 말하는 것인지왜 내부 설계를 의존해야만 하는 상황이 발생하는지정도일 것 같습니다. 감사합니다.

퍼블릭 서브넷: Bastion host (외부 접속용)프라이빗 서브넷: 실제 EC2 애플리케이션 서버목표: GitHub Actions + Docker를 사용해 프라이빗 EC2에 배포제가 찾은 방법은 첫번째로GitHub Actions에서 Bastion host로 먼저 SSH 접속 Bastion에서 프라이빗 EC2로 SSH 중계내부 EC2에서 Docker pull & deploy방식인데요 이 방식으로 하려면 bastion host 보안 그룹 인바운드 규칙을 모든 IP 허용을 해야해서 이게 맞나 싶습니다.그리고 다른 방법은 github self-hosted runner를 쓰는 건데요. 아직 잘 모르는 영역이라 해보기 전에 질문 올립니다.제가 말한 방법 이외에 또 다른 방법이 있는지 궁금하기도 해서 도와주시면 감사하겟습니다

테스트와 코드간 성장 헙력 관계를 보면서 문득 궁금증이 들었습니다. 테스트 시나리오는 작성하면서 시나리오의 순서 역시도 중요하지 않을까? 하는 의문이 들었습니다. 단순한 기능들은 (예시로 들어주신 회원가입)은 테스트 시나리오의 순서에 큰 영향을 받지 않을 것 같으나 좀 더 복잡한 로직, 예를 들면 금액 계산과 같은 로직은 테스트 시나리오를 작성함에 있어서 순서를 신경 써야 할까요? 좋은 예시가 떠오르지는 않지만예약 시스템을 만들면서 테스트 시나리오를 짠다고 했을 때 테스트 시나리오의 순서대로 코드가 성장이 된다고 가정하면 테스트 시나리오를 작성하는 순서 역시도 중요한 부분 중 하나일 수 있겠다는 생각이 들었습니다.강사님은 테스트 시나리오를 작성 하실 때 순서를 크게 신경 쓰지 않으시나요? 아니면 로직의 흐름을 미리 어느정도 파악해 두시고 시나리오를 그 흐름에 맞춰 작성하시나요? 두서 없는 질문이라 정말 죄송합니다.

@SpringBootTest 어노테이션에 classes를 사용해 CommeceApiApp.class를 구체적으로 지정하시는 이유가 있으실까요?

섹션 2 강의를 듣고 난 후 퀴즈를 푸는데 다음과 같은 문제가 나왔습니다. 소프트웨어 테스트에서 코드의 실제 문제는 있지만 테스트 결과는 성공으로 나타나는 오류 유형은 무엇일까요?문제를 읽다보니 거짓 음성과 거짓 양성이 헷갈리기 시작했습니다.시스템에 문제가 있으나(코로나 양성) 테스트(코로나 검사)는 시스템에 문제가 없다(코로나 음성)라고 나왔으니 거짓 음성이다. 라고 이해하면 되는 것일까요?