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

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

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

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

DESC, ASC

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

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

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

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

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

gRPC 실무에서 질문

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

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

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

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

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

DI시 eager과 lazy

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

강의가 검은 화면으로 나옵니다.

안녕하세요!! 이건 인프런측에서 제공해주는 서비스다보니.... 제쪽에서 무언가 처리해드릴 수 있는 부분이 없습니다 ㅠ.ㅠ 저도 한번 문의해보도록 하겠습니다!!