July

안녕하세요 Jun Dawin Nodric님 질문 주셔서 감사합니다.&nbsp;몇가지 상황이 존재할꺼 같습니다.&nbsp;<ol><li>명확한 스키마 기반의 기준이 필요한 경우</li></ol>서비스 인터페이스를 통해서 다양한 언어에서 포괄적으로 사용 가능하기 떄문에 특정 기준을 잡을 떄 활용이 가능합니다.&nbsp;<ol start="2"><li>내부 시스템 간 통신의 일관성</li></ol>REST 는 팀별로 설계가 상이하기 떄문에 .proto 파일을 통해서 규격을 제공 할 수 있을꺼 같습니다.&nbsp;감사합니다.

grpc 도입을 고려할만한 케이스

안녕하세요 민수킴님 질문 주셔서 감사합니다. 질문 주신 부분이 맞습니다. 기본적으로 <code>a=1</code> 구문으로 사용하시게 된다면, 해당 구문은 숫자로 인식하는게 아니라 문자로 인식을 하게 되고, 해당 값이 맞는 raw가 true로 판별되어 뒤에 따라오는 Raw는 정렬이 되지 않습니다.&nbsp;구체적인 사항은 제가 오늘 밤에 들어가 강의 내용을 좀 더 확인을 해봐야 하지만, 질문 주신 내용이 우선적으로 틀린 질문은 아닙니다. 이런 케이스에 대해서 만약 완전한 정렬을 하고 싶으시다면, 2차 정렬 조건을 두어서 처리를 해야 하는게 맞습니다.추가적인 질문이 있다면 남겨주신다면, 좀더 세세한 부분은 제가 7.7일경 밤에 강의 내용을 추가로 확인하고 전달드리도록 하겠습니다.

Order BY 강의 12분 질문

안녕하세요 질문 턴태님 질문 주셔서 감사합니다. 이 강의는 기본적으로 단일 인스턴스 상황을 가정하여 예시로 어떤 형태인지 알려드리고자 촬영이 되었는데 이렇게 더 큰 그림을 보시면서 다중 인스턴스 상황을 가정하셨다니!! 너무나도 기쁘네요 ㅎㅎ 이렇게 강의 내용을 넘어서서 고민하시는 분들이 더 많아지면 좋겠습니다.&nbsp;일단 메시지 자체가 화면상에 보이는 부분은 문제가 되지 않습니다. UI에서 이런 부분은 모두 표기가 가능하기 떄문이에요&nbsp;하지만 서버간 이 메시지를 동기화 해야 한다면 문제가 조금 복잡해 질 수가 있습니다.&nbsp;말씀해 주신대로 단일 메시지의 경우에는 단순히 Pub/Sub 모델이 가장 많이 사용이 됩니다. 메시지 자체의 크기가 크지 않기 떄문에 효과적이고 모든 서버에 요청이 가기 떄문에 구현을 하는데에 있어서 큰 문제가 없고 말씀해주신대로 roomId와 기본적인 prefix가 혼용이 되어서 이벤트가 브로드캐스팅 될 것입니다.&nbsp;또한 한쪽에 소켓 통신을 모는 행위는 사용하지 않는 편인거 같습니다. 부하에 대해서도 핸들링 할 수 있는 부분이 적고 애초에 한쪽에 커넥션을 몬다는 행위가 LB를 적용하는 의미가 없어지기 떄문이죠&nbsp;한가지 더 질문을 주셨는데 스트리밍 관련해서는 Redis Pub/Sub 모델을 사용하지 않습니다. 대표적으로 WebRTC같은 기술이 사용이 되거나 Peer to Peer와 같은 형태가 사용이 됩니다.일반적으로 Soop이나 네이버 치지직과 같은 서비스는 이 P2P랑 웹 소켓 통신을 혼용해서 사용한다고 봐주시면 됩니다.

Streaming 중인 서비스에서 모든 파드에 broadcast하는 방법

안녕하세요 니홍님 예전 강의다 보니 설명에 대해서 좀 누락된 부분이 있었나보네요 ㅠㅠ 이렇게라도 답변 드리도록 하겠습니다.&nbsp;기본적으로 <code>upsert</code> 는 <code>Find AND Update</code> 아니면 <code>Find And Insert</code> 입니다. 결국 Find를 한 후에, filter에 따라 하는 행위가 달라집니다.&nbsp;단순히 insert만 해야 하는 상황이라면 <code>insert</code>만을 사용하는것이 당연히 더 좋습니다.왜냐면 명시적으로도 스탭이 줄어들기 떄문이죠.&nbsp;제가 <code>upsert</code> 를 사용하는 이유는 모듈 개발에 특화되어 있는 명령어이기 떄문입니다.<ul><li>중복된 데이터는 업데이트 해야 하지 않는 경우 하나의 커맨드를 통해 처리가 가능하기 때문이죠.</li></ul>&nbsp;물론 Find를 클라이언트 레벨에서 진행하고, Update를 진행해도 되지만, 그러면 커넥션을 두번 연결해야 하는 문제가 생기니, 가능하다면 <code>upsert</code>를 도입해보시면 어떨까 싶습니다.&nbsp;감사합니다!

upsert

안녕하세요.해당 부분은 소스코드에 ddl을 올려드렸습니다.그걸 복사하셔서 사용하시면 됩니다!&nbsp;답변이 늦어서 죄송합니다 ㅠ

stock 테이블 생성 문의

변경하는거 자체는 어렵지 않을꺼 같은데.. 오히려 제가 HTML이랑 JS를 따로따로 구현하여 하는 작업을 안한지 오래되어서... 실무를 경험하면서 그러한 작업을 할 일이 없어지는거 같습니다...<ul><li>그러다보니 큰 도움을 드리기가 어려운 주제로 보입니다.</li></ul>&nbsp;굳이 HTML, JS를 따로 구현하여 사용하시는 이유가 있을까요?? 보통 어느 회사도 저런식으로 구현을 하는 경우는 들어보지는 못해서요..

프론트쪽이 리액트로 되어있는데요..

docker를 사용하신다면, 그냥 이미지를 생성하실 떄, 빌드 바이너리 파일을 넘겨주면 되지 않을까 싶습니다.<code>golang</code>에서 빌드 파일을 생성하는 명령어는 <code>go build -o <이름></code> 을 통해서 생성한 바이너리 실행파일을 넘겨주고,해당 이미지 내부에서 <code>go run <./이름></code> 을 통해 실행시키면 되지 않을까 습니다.&nbsp;

오늘 강의 듣기 시작했는데요!

안녕하세요 질문 남겨주셔서 감사합니다. 일단 우선적으로 제가 현재 소스코드를 날려먹은 상태여서... ㅠㅠ 정확한 부분은 코드를 봐야 알수가 있는 부분인거 같습니다. 혹시라도 제가 답변해 드리는 내용에 대해서 이해가 잘 안되신다면 관련하여 코드도 첨부해 주시면 감사하겠습니다.&nbsp;해당 질문에 대해서는 먼저 스펙에 대한 기준이 필요할꺼같습니다.플랫폼을 구성하는데에 있어서 큰 서비스를 운영하는지, 아니면 간단한 서비스인지에 대해서 관점이 달라지는거 같습니다.&nbsp;큰 서비스를 운영한다면, 기본적으로 메시지 처리를 채널로 하지 않습니다. 데이터 유실에 대해서도 어느정도의 책임을 가지고 있어야하기 떄문에, 보통 저런 구조에서의 채널을 Kafka를 적용하여 관리를 하게 됩니다.<ul><li>물론 내부적으로 코드에서는 채널을 통해 무언가를 처리해도 무방합니다.</li></ul>&nbsp;이러한 관점이 중요한 부분은 서비스에 대해서 오버 스펙을 굳이 구현 할 필요는 없기 떄문입니다. 회사에서의 비용절감도 어느정도 중요한 부분이기 떄문이에요.<ul><li>그래서 실제로 Kafka를 안써보신 분들도 꽤나 있는걸로 알고 있습니다.</li></ul>&nbsp;하지만 작은 서비스라면, 사실 어떻게 관리를 하든 무방합니다. 그래서 저는 개인적으로 장단점이 있는거 같아요.여러개의 고루틴을 관리하는것은 쉽지가 않지면, 병렬적으로 좀 더 가볍게 처리 가능한 장점이 있습니다. 하지만 그에 따라서 개발자가 고생을 많이 하는 형태라고 생각을 합니다.&nbsp;하나의 루틴을 통해서 관리하는것은 간단하지만 아무래도 데이터의 사이즈가 커지기 떄문에 병목이나 문제가 생길 수 있는 부분이 꽤나 발생할꺼같습니다.&nbsp;개인적으로는 최적화를 위해서는 병렬적인 처리가 더 좋다고 생각을 해요. 하지만 실무에서는 최적화도 중요하지만, 유지 관리의 가능성도 잘 잡고 있어야 하기 떄문에, 상황에 따라서 달라지는거 같습니다.<ul><li>내가 정말 자신있다고 생각을 한다면 병렬적으로 하시는게 맞다고 생각을 합니다. 하지만 어느정도 팀내의 레거시를 따라야한다거나, 팀 내에서의 코드 작성이 자신이 없다면 하나에서 관리를 해도 무방합니다.</li></ul>&nbsp;하지만 결론적으로는 최선의 방법은 kafka를 통해서 관리하는것입니다. 이 강의에서 사용한 방법은 Kafka까지 가게 된다면 수강하시는 분들이 너무 어려워하실꺼 같아 다루지는 않았습니다.&nbsp;혹시 제가 잘못된 답변을 드렸거나 엉뚱한 소리를 했다면 한번 더 질문 남겨주시면 감사하겠습니다.좋은 주말 보내세요 :)&nbsp;

RunInit() 관련 질문

상황에 따라 꽤나 다른거 같습니다. 이거는 사실 인프라적인 부분이라서 제가 정답을 알려드리기에는 조금 부족한 부분이 있겠다라는 생각도 들어요.&nbsp;일단 기본적으로 Azure에 대해서는 동적인 wss 통신을 지원해주지 않는걸로 알고있습니다..일반적으로 실무에서는 FrontDoor라는 기능을 제공을 하는데, Azure에서는 wss에 대해서 딱히 지원을 해주지 않는걸로 알고 있어요.<ul><li>좀 예전에 알게 된 사실이라서 지금은 어떨지 모르겠네요..</li></ul>&nbsp;AWS에 대해서는 관련하여 제가 좀 더 검색하고, 실무자님에게 물어보며 질문에 대한 답을 한번 찾아오도록 하겠습니다. 제가알고 있는 지식을 제공해 드리는것도 좋지만 좀 더 인프라를 집중적으로 하시는 분의 의견도 들어보는게 좋지 않을까라는 생각이 드네요.&nbsp;관련하여 추후에 추가로 공지해 드리도록 할게요 감사합니다!<ul><li>그리고 기본적으로 어떤 플랫폼과 요청인지에 따라 다르겠지만, 요청이 빈번하게 발생하고 지속적인 폴링 작업이 요구된다면, wss 통신이 압도적으로 HTTP보다 좋습니다. 단지 HTTP에 비해서 구현하기 어렵다는 단점을 제외한다면요!!</li></ul>

소켓 연결과 http

안녕하세요. 솔직하게 예전에 촬영했던 강의라서.. 까마득하기 떄문에 딱히 version에 대해서는 기억이 나지 않네요 ㅠㅠ &nbsp;Cluster에서 기본적으로 설정되는 버전이 있는걸로 알고 있는데, 최근에 생성했던 mongo cluster의 경우에는 다음과 같은 버전을 가지고 있습니다.<ul><li>8.0.4</li></ul>&nbsp;혹시 추가적인 도움이나 질문이 있다면 남겨주세요! 관련해서 알려드리도록 하겠습니다.

July

投稿