지원서 작성 가이드와 샘플이력서 살펴보기 강의질문

안녕하세요. 수강자님포트폴리오는 한장에 하나의 프로젝트가 다 들어가도록 핵심을 정리해서 보여줘야 합니다.물론 신입일 경우 많은 내용을 보여주고 싶은 마음이 있겠으나, 서류를 검토하는 입장에서는 내용이 많다고 더 보지도 않고 오히려 서류가 많아져서 정작 중요하게 부각되어야 할 내용이 보이지 않는 경우가 많습니다.따라서 이력서와 마찬가지로 단순하고 명확하게 작성하는게 중요합니다. 경력직인 경우 포트폴리오는 필요없습니다. 경력기술서에 자세히 적으면 되고, 본인이 직접 한 업무라면 그에 따른 설명도 지원하고자 하는 회사의 업무 방향에 맞게 작성해서 어필해야 합니다. 연관관계가 있다면 더욱 좋겠죠? 무료편에는 회사 공고 분석이 다소 적은 분량으로 올라가있습니다만, 채용 공고를 분석해서 그에 맞는 방향으로 이력서를 수정해서 제출해야 합니다. 참고하시기 바랍니다.

인증 에러

안녕하세요. 메시지 에러 자체는 RabbitMQ의 인증 에러 인데요, 도커 ps와 log를 확인해보시고, management 에 접근해보시기 바랍니다. (admin/admin으로 http://localhost:15672에 접근되는지) 원래 기본 계정은 guest/guest 입니다. 강의에 나온대로 RabbitMQ를 먼저 설치한 뒤 테스트 해보시고 제대로 된다면 도커 설정의 문제이므로 (로그나 권한 실행 타이밍으로 인한 에러)일 이 부분을 체크 먼저 하시고 범위를 줄여오류 사항을 예측해봐야 합니다.구글에서 docker rabbitmq access reused error 로 검색했을때 위에 언급한 문제들의 해결방법이 나오므로 참고해보시되, 먼저 어드민 콘솔 부터 접근 되는지, 계정이 맞는지 부터 점검 해보시기 바랍니다. 감사합니다.

RabbitMQ에서의 트랙잭션 메시징 질문

안녕하세요. 수강자님 DB와 RabbitMQ같은 메시지 브로커의 트랜잭션은 서로 독립적입니다.그래서 RabbitMQ에서 트랜잭션을 구현하려면 DB와는 별도로 자체에서 처리하는 방식으로 "처리는 가능" 합니다. 19강 자료에 나와있는데, amqp-client에 의존성 (starter-amqp에 포함)channel.txSelect():트랜잭션 시작. 이후 모든 메시지 전송 작업은 이 트랜잭션 내에서 실행.channel.txCommit():트랜잭션 커밋. 모든 작업이 성공적으로 수행되었음을 RabbitMQ에 알림.channel.txRollback():트랜잭션 롤백. 트랜잭션 내 작업을 무효화하고 변경사항을 되돌림.이 방식으로 처리는 가능합니다만, 아시다시피 메시지큐는 비동기 환경에서 분산 메시징을 처리하는데 탁월한 미들웨어이기 때문에 이 방식으로 굳이 트랜잭션을 구현하는게 의미있나? 라는 관점에서 보면 구현 비용대비 실효성이 떨어지는 편입니다따라서 19강에서 설명하는 바와 같이 Outbox 패턴(db에 별도로 저장 한 뒤 다른 프로세스를 통해 메시지 처리)이나 TCC와 같은 형태의 재시도와 보정을 통한 멱등성을 보장하는게 훨씬 업무적으로는 좋은 선택이라고 판단합니다. 완강이 얼마 남지 않으셨네요. 마무리 잘 하시기 바랍니다. 감사합니다.

기술분석 - 배포시스템을 구축해야한다면? 부분은 강의가 제공되지 않는건가요?

안녕하세요. 수강자님빌드 배포 관련 사항은 제가 임의의 시나리오를 통해 CI/CD를 개발한다면 어떻게 아케텍처를 분석해서 적용할 수 있는가를 가상으로 설정해서 설명해보려고 넣었습니다만, 중요도에 비해 강의 분량이 다소 과하고 면접에서 필요한 부분의 개념은 강의 자료에 나온 키워드만 이해하셔도 무리없겠다 생각해서 생략 했습니다.해당 설명이 19강에서 다시 언급은 되었는데, 목차에서 관련 내용을 업데이트 하질 못했네요. 혼란을 드려 죄송합니다.블루그린/카나리 배포 정도의 차이와 특징 등을 이해하시면 되는데 여기에 더해서 배포 시스템을 개발 할 때 분석하고 적용해야 할 기능들을 정리하는건 기술면접에 큰 도움은 안될거 같아 강의를 듣는 입장에서 효율상 시간 부담을 덜어 드리고자 과감히 생략했으니 양해 부탁드립니다. 감사합니다.

Nginx와 로드밸런서의 관계

안녕하세요. 질문 알람을 제때 못받아서 답변이 다소 늦어진 점 죄송합니다. 강의에서 언급한 Nginx를 통해 부하분산을 한다와 이후에 로드 밸런싱 기법에 대해서 바로 설명을 이어서 하였습니다. 웹 서버 자체의 로드 밸런싱을 통해 부하분산을 할 수 있다고 이해하시면 되겠습니다.장표의 그림상으로는 별도의 로드밸런서 장비가 있었으나, 없을 경우 웹 서버들로도 충분히 로드밸런싱을 구성할 수 있다는 내용입니다. 감사합니다.

안녕하세요 "섹션2 8. Consumer간 작업 분배" 에서 질문 있습니다.

안녕하세요. 수강자님 컨슈머가 붙은 상태에서 정상적으로 메시지 큐에서 컨슈머에 전달 되면 정확하게는 처리중인 상태입니다.내부에서 따로 설정한 로직 (여기서는 슬립 후 처리) 이후 소진이 완료되고 ack 가 호출되고 이때가 소진이 완료된 시점이 됩니다. 로그가 빨리 올라와서 구분이 어려울 수 있으니 초 단위로 대기를 준 부분이 아직 처리가 안된 상태이고, 이 후에 메시지가 출력된 이후에 ack 가 전달되면 소비가 완료된 상태입니다.해당 강의는 메시지의 전달과 처리, 처리 완료 후 프로세스를 설명한 것이므로 초 단위 처리하는 부분이 실제 비즈니스 영역의 로직을 대체해서 소진 완료 이전에 로직을 실행하고 실행 후 act 가 날라가고 처리완료(소진완료) 된다고 이해하시면 됩니다. 감사합니다.

안녕하세요 섹션2. 12번 강의에서 질문 있습니다.

수강자님 안녕하세요. 특정한 뉴스를 발행하는 경우 데이터가 쌓이는게 우려될 경우 Direct로 설계하는게 맞고, 회원 등급별로 후처리 등을 염두에 둘 경우 팬아웃으로 써도 무방하빈다.pub/sub을 이용한 알람이 주 예제이고, 뉴스구독의 경우 fanout이든, direct이든 topic이든 구현하는 목적에 부합하는 방식으로 선택하시면 되는 문제라서 예제에서 단계별로 흐름을 설명하면서 각 exchange의 특징을 보여들릴 목적이지 뭘 선택하느냐는 실제 개발 환경에서의 목적에 따라 취사선택하시면 됩니다. 발행/구독 모델에 특정 사용자만 매칭해서 쏴야 할 경우, 전체에게 다 발행할 경우, 관심사 별로 유연하게 할 경우 해당 업무는 설계하는 목적에 따라 각각 direct, fanout, topic 을 선택해서 진행하시면 됩니다. 감사합니다.

Producer/Consumer 단위

수강자님 안녕하세요. 보통 우리가 메시지큐를 얘기할 때 인스턴스 단위로 얘기를 합니다.즉, 애플리케이션을 띄우는 단위를 말하고, 트래픽이 몰려서 큐처리에 행이 걸려 늦게 처리될 경우 이를 해소하기 위해서 서버 증설을 얘기하느데, 이 때 워커 노드(애플리케이션를 띄울 수 있는 서버 단위)를 늘리는 것을 메시징 미들웨어에서의 스케일 아웃이라고 표현합니다. 참고하시기 바랍니다. 감사합니다.

수업자료 제공 ?

안녕하세요. 수강자님 첫 강의에 보면 수업자료가 첨부 되어 있습니다.확인 부탁드려요. 감사합니다

컨슈머 서버 질문드립니다

안녕하세요. 수강자님 서비스가 복잡해질수록 발행하는 이벤트도 다양해지고 받는 쪽, 컨슈머도 이에 비례해서 증가하기 마련입니다. 싱글 도메인에 단순 비동기라면 적은 수의 메시지로도 문제가 없겠지만 복잡한 메시징 전송이나 상태 전송, 메시지의 컨펌 등 여러 레이어에 걸쳐 처리해야 할 경우 엠큐의 효과가 극대화 됩니다.브로드캐스팅 뿐 아니라 pub sub도 여러 도메인에서 활용 가능하므로 사용하기 나름입니다감사합니다