Hong

안녕하세요 smallchoi님 질문 주셔서 감사합니다!!&nbsp;모든 쿼리는 수업 자료에 첨부되어 있는데 혹시 그쪽 부분을 확인해보시겠어요??영상 아래쪽에 <code>수업 노트</code> 이 영역을 클릭하시면 관련된 쿼리들이 보이실겁니다.

실습용 테이블, 데이터 생성 파일 있을까요?

음... 누락이 된거 같은데 잠시 추가로 확인해보겠습니다. 불편을 드려 죄송합니다.&nbsp;일단 Docker의 경우에는 대부분의 사람들이 사용한다는걸 어느정도 가정한 부분은 있어서 따로 설치하는 과정은 다루지는 않았습니다.<ul><li>윈도우, 맥, 리눅스 등등 환경마다 각각 다 다르다보니 이 부분은 양해 부탁드립니다.</li></ul>&nbsp;사용한 IDE는 젯브레인 계열 아무거나 사용하시면 되고 저는 goland 사용했는데 이게 개발자마다 다 달라서... 평소 사용하시는걸 사용하시는걸 추천드립니다.&nbsp;하지만 연결 관련해서 촬영했던 기억이 있는데 이 부분을 한번 검토해볼게요.&nbsp;다시한번 불편을 드려서 죄송합니다.

수업에서 사용하는 툴 질문드려요

안녕하세요 DongHyun Gu님 질문 남겨주셔서 감사합니다.당연하게도 여러 인스턴스가 구성된 환경에서는 한계가 있습니다. 그리고 데이터 모듈이라는거 자체가 보통은 하나의 인스턴스로 유지가 된다고 가정하고 촬영되었습니다.<ul><li>물론 상황에 따라서 감당이 안된다면 여러개가 존재 할 수 있겠죠</li></ul>&nbsp;파드가 여러개인 상황에서 고려해야하는 부분은 다양하게 있겟지만 우선 질문 주신 내용을 기준으로 한번 다뤄보도록 할게요.&nbsp;<ol><li>currentTimeStamp</li></ol>당연하게도 해당 값은 매번 key가 달라지니 유니크 제약 방어가 무력화됩니다. 멀티 파드에서 동시 트리거되면 둘 다 새 인스턴스로 실행돼요&nbsp;그래서 이걸 보장하기 위해서 다양한 방식이 있을텐데, 대표적으로<ul><li>ShedLock : 가장 흔한 방식으로 DB 락 테이블 방식</li><li>Quartz Cluster Mode : 스프링 배치와 별개로 클러스터 락을 잡아버림</li><li>K8s CronJob + 단일 Pod: 잡에 대한 트리거를 K8s가 담당을 하게 되고, 앱 파드는 그냥 워커 형태로 구현 형태가 단순합니다.</li><li>Airflow/Argo Workflows: 사실상 단일 인스턴스로 안된다면 대용량을 위한 오케스트레이션으로 변경</li></ul>이정도가 될꺼같아요.&nbsp;<ol start="2"><li>멱등성은 기본적으로 Batch처리에서 보장해야 하는 옵션입니다. 이건 우리가 다시 실행하는 케이스들이 많기 떄문에 멱등하게 구성하시는게 좋으실거에요.</li></ol>&nbsp;혹시 추가적인 질문 있다면 부탁드립니다. 감사합니다.&nbsp;

여러 파드 환경에서 단일 실행 보장 방식

안녕하세됴 helloooo1님 확인해주셔서 감사합니다. 일부 잘못된 내용이 들어가 있었나보네요 ㅠㅠ 죄송합니다. 관련해서는 빠르게 수정 진행하도록 하며, 수업 자료에도 관련된 내용 첨부해놓도록 하겠습니다.&nbsp;감사합니다.

DESC, ASC

안녕하세요 syhan7516님 이렇게 질문 남겨주셔서 감사합니다. 제가 syhan님에게 도움이 되는거같아서 너무 뿌듯하네요!! 오늘도 좋은 하루 보내세요&nbsp;질문 주신 부분에 대해서 답변을 드릴게요.&nbsp;궁금하신 부분은 <code>파일의 서빙으로 성능적 이점을 얻기 위해서는 프론트와 백엔드가 하나의 서버에 위치해야 이점을 얻는가</code>를 고민하고 계시는거 같아요.&nbsp;일단 결과적으로는 그런거는 아닙니다. 그런 구조에 국한되어야만 이점을 가지는건 아니에요.일단 우리가 왜 정적 파일 서빙이 빠른지를 이해하시면 바로 <code>sendfile</code> 이라는 기능 떄문이에요.<ul><li>디스크의 파일을 유저 스페이스로 복사하지 않고 커널에서 바로 소켓으로 보낸다는 특징이죠.</li></ul>&nbsp;즉 이게 Spring이나 Node같은 WAS가 파일을 읽어 애플리케이션 메모리를 거친 뒤 응답을 보내는 이 과정보다는 컨텍스트 스위칭과 메모리 복사가 훨씬 적은 형태를 가지게 되는거죠.&nbsp;그래서 보통은 그냥 분리해요. 이런 관점에서는 사실상 물리적으로 어디에 위치하는지와는 무관한 구조가 되는거죠.&nbsp;그래서 오히려 분리하는 형태가 더 자주 보이게 됩니다. 뭐 일반적으로는 분리를 하니깐요.가장 극단적으로 예씨를 들어보자면 CDN정도가 될꺼같아요. 정적 파일을 가장 가까운 엣지 노드에 두고, 백엔드 API는 굉장히 멀리있는 리전에 두어도 문제가 없는거죠.&nbsp;그래서 그냥 개념을 딱 정리해드리자면, <code>정적 데이터는 동적 처리(WAS 같은것들)에서 분리해서, 정적 서빙에 최적화 되어있는 서비스 ( NGINX, CDN, S3 등등)에서 서빙을 해야 이점을 가진다.</code> 라고 할 수 있을꺼같습니다.&nbsp;감사합니다~!

정적 파일 서빙에 대한 성능 최적화에 대해 질문드립니다.

어우 soap님 질문 남겨주셔서 감사합니다. 꽤나 위험한 작업을 하셨군요 ㅠㅠ 많이 떨리셨겠어요...&nbsp;먼저 발생하신 장애는 기본적으로 발생가능한 장애입니다. 왜냐하면 <code>SharedLock</code> 을 잡기떄문에 쓰기가 차단되는걸로 보여요.<ul><li>SELECT는 허용될겁니다.</li></ul>&nbsp;그래서 데이터가 많게된다면, 해당 데이터들을 모두 스캔하는 동안 쓰기데이터가 대기하면서 커넥션 풀이 고갈되는걸로 보여요..&nbsp;해결하는 방법으로는 <code>CONCURRENTLY</code> 를 사용하는겁니다. 이러면 <code>ShareUpdateExclusive</code> 을 잡기떄문에 블로킹은 딱히 없기는하지만, 좀 더 오래걸리고 부하도 더 크기는 합니다.<ul><li>대신 서비스는 무중단으로 가능하죠</li></ul>&nbsp;이외에도 고려할만한게 있다면, 우선적으로 디스크 공간을 확인하셔야해요. WAL 증가도 존재하고 인덱스 생성으로 인해 크기를 더 잡아먹기 때문에 디스크가 여유있는지 확인해주시고 복제본이 있다면, WAL 증가로인해 복제지연이 발생하여 데이터가 정상적으로 표기되지는 않는지 확인해보시면 좋을꺼같습니다.&nbsp;근데 뭐... 사실 가장 좋은 방법은 사용자가 별로 없는 시간대에 최대한 영향을 주지 않는 시간대에 실행하는게 좋습니다. 이런 경우에는 굳이 <code>CONCURRENTLY</code> 를 쓸 필요도 없겠죠&nbsp;어느정도 질문에 대한 답이 되셨을까요?? 혹시 추가적인 질문이 있다면 남겨주세요!!

라이브 운영중인 환경의 테이블에 인덱스 추가시 고려사항

안녕하세요 IwantKtor님 질문 남겨주셔서 감사합니다. 우선 대규모의 서비스를 운영하는 회사인가보네요 축하드립니다!!&nbsp;분석에 대한 순서를 말씀해주셨는데, 일단 가장 대표적인거는 <code>.proto</code> 파일 분석입니다. 사실상 중앙화된 proto 레포가 어디에 있는지 파알하는것이 우선적일꺼같아요. 그리고 데이터팀이기 떄문에 사실상 모든 서비스를 보실필요는 없어요. 필요한 데이터만 보시면 될꺼같아요.<ul><li>이벤트 및 로그 생성 서비스 주체</li><li>데이터 파이프라인에 붙어있는 서비스 위주로</li><li>어차피 입사하시면 초기 서비스 구성도를 설명해주시니 이 과정에서 가장 대량의 처리를 담당하거나 코어 레벨로써 관리가 되는 서비스를 물어보시면 될 꺼 같습니다.<ul><li>추가로 Wiki라던지 문서들 한번 쭉 읽어보시는것도 방법입니다.</li></ul></li></ul>&nbsp;<code>.proto</code> 파일을 읽어보시는 순서도 아시면 좋기는 한데, 사실상 명확하게 어떤 역할을 하는지 해당 파일에서 잘 관리가 되어있을 확률이 높습니다. 그러기 때문에 <code>proto</code> 파일에서 Server 블록을 위주로 보시면 좋지 않을까 싶어요.&nbsp;근데 사실 실제로 사용이 되는지는 모르는거죠. 그래서 트래픽이 실제로 동작을 하는지도 같이 확인해보시면 좋을꺼같습니다.<ul><li>grpcCurl을 활용하시면 좋을꺼같네요.</li></ul>&nbsp;&nbsp;

gRPC 실무에서 질문

안녕하세요 배고프면근손실님 질문 남겨주셔서 감사합니다.&nbsp;음 아무래도 리스너 설정이 되어있을 확률이 있을꺼 같습니다. <code>ExecutionContextPromotionListener</code> 확인이 필요할꺼같아요. 왜냐하면 해당 리스터는 Step이 완료될 떄 지정한 key를 <code>JobExecutionContext</code> 로 복사하는 역할을 수행하기 떄문에 해당 부분을 확인해보시면 좋을꺼같아요.

job, step execution 관련 질문 드립니다.

안녕하세요 won님 답변이 늦어서 죄송합니다. 개인적으로 이 SAGA 패턴이라는게 저는 막 정해진 방식은 없다고 생각을 해요. 상황에 따라 맞춰서 가는게 맞다고 생각은 합니다.&nbsp;하지만 그래도 표준에 대한 기준으로 잡아보자면, 저는 <code>계속 진행하면서 각 보상 결과를 독립적으로 추적하는 구조가 되어야한다.</code> 라고 말할 수 있을꺼같아요.&nbsp;왜냐하면 가정을 해주신 2번 롤백이 실패했다는 상황이 사실상 1번 자체를 시도조차 하지 않는다는건 좀 다른 문제입니다. 상태 자체가 다르다고 느껴져요.&nbsp;명시적으로 우리가 잘못되었다고 1번 서비스는 롤백 시도도 안한다는게 일단 의도적으로 우리가 이걸 방치한다는 관점이기 떄문입니다. 최소한 시도를 해야 이걸 시도했는지 시도를 하지 않았는지 히스토리에 남아있는다는 관점도 있기 떄문이에요.&nbsp;이 SAGA라는것의 최종적인 목적이 결국 <code>시스템이 일관된 상태를 유지한다.</code> 가 기본적인 목표입니다. 그래서 1번은 독립적으로 실행되어야 해요.&nbsp;의존성관점에서도 이 틀은 벗어나지 않습니다. SAGA에서 의존성이라는 관점은 단순하게 <code>롤백 순서를 지켜야한다.</code> 정도의 관점이지 이걸 <code>롤백을 건너 뛰어도 된다</code> 까지는 다루지 않는게 맞는거 같아요.&nbsp;추적 관점은 보통은 우리가 상태 추적을 위한 step을 독립적으로 관리하시는게 편하실겁니다.&nbsp;예를들어 음.. 예시적인 코드로 표현하자면 이런 형태가 될꺼같아요.<pre><code>saga_instance
 saga_id, status (COMPENSATING | COMPENSATION_FAILED | COMPLETED)</code></pre>&nbsp;이렇게 status를 스탭마다 두어서 관리를 하는거죠. 이러한 관점에서 <code>WAL</code> 이라는 패턴도 한번 적용해보시면 도움이 되실꺼같아요.&nbsp;혹시라도 추가적인 질문이 있다면 남겨주세요 좋은 질문 남겨주셔서 감사합니다!&nbsp;&nbsp;

Orchestration SAGA 패턴 보상에 대한 질문입니다.

안녕하세요 IwantKtor님 질문 남겨주셔서 감사합니다!!<ul><li>제가 깜빡하고 답변을 못드렸네요 죄송합니다 ㅠ.ㅠ</li></ul>&nbsp;늦게라도 답변을 드리자면, 우선 <code>get</code> 은 선언 즉시 가져오는 행위고 <code>lazy</code> 는 접근 할 떄 값을 가져오는 행위죠. 우리가 이걸 JPA 관점에서도 실제로 적용이 가능한 형태고요&nbsp;get은 보통 그래서 함수 내부나 초기화 블록에서 사용이 되소 <code>lazy</code> 는 클래스 프로퍼티 관점에서 사용이 됩니다.&nbsp;그래서 좀 더 딱 정리를 해보자면 <code>get</code> 는 routing 블록 내부에서 이미 DI 컨텍스트가 준비된 시점에 호출 할 떄사용이 되거나, <code>lazy</code> 는 클래스 프로퍼트 즉 순환 의존이 생길꺼 같을 떄 사용한다고 봐주시면 될꺼같습니다.&nbsp;감사합니다!

Hong

投稿