실무 내용 문의드려요

안녕하세요 규혁님!! 질문 주셔서 감사합니다.사실 사용가능한 툴은 너무나도 많아요 대표적으로 Kafka UI 가 있을 수 있습니다.JSON으로 UI에서 직접 입력그 외에도 Kafka HQ, Terraform 등등 인프라 환경에 따라서 제공되는 서비스들을 사용해보시면 좋을꺼 같아요!!이 친구들은 yaml 같은 형태로 선언해서 사용을 합니다.제가 그냥 쉘 스크립트로 진행한 이유는 추가적인 툴을 사용하지 않고도 적용이 가능하다는것을 보여드리기 위함이니 추후에 이런 서비스를 직접 구축하게 되실 떄 참고해보시면 좋을꺼 같습니다.감사합니다!!

프로젝트 의존 관계

안녕하세요 답변이 늦어서 죄송합니다 ㅠ.ㅠ 아무래도 개발을 설계하는 과정과 실제 구현체가 일부 다른 부분이 있는거 같습니다../하다보니 달라 질 수 있는데 이게 반영이 안된거 같네요 관련해서는 검토해보도록 하겠습니다. 기본적으로는 실제 구현체의 구조가 맞기때문에 해당 부분을 위주로 봐주시면 될 꺼 같습니다. 보시는데에 있어서 불편을 드려 죄송합니다...!

데이터베이스 설정 가져오기 시 캐싱 관련 질문 있습니다

안녕하세요 sejeong1108님 질문 주신 부분이 맞습니다. 말해주신 내용대로 자식 프로세스르 관점으로 띄우기 때문에, DAG 파일 하나당 별도 프로세스로 파싱하고, 끝나면 종료를 하게 됩니다. 즉 그래서 모듈 레벨에서의 @lru_cache 라는 애는 파싱 주기간에는 보존이 안되요. 대신 단일 파싱 사이클에서는 캐시가 유호할겁니다. 예를들어 한 DGA 파일 안에서 같은 설정 조회 함수를 여러 DAT/Task 루프에서 호출을 한다면, 한번만 DB에 가고 캐시에서 처리를 하는거죠SingleFlight라는 패턴 공부해보시면 좋을꺼같아요. 음 추가로 현업에서 자주 사용하는 패턴에서 효과가 좋을만한것들만 우선적으로 나열해보자면,파일 기반 캐시 -> 별도 스케줄러가 주기적으로 DB -> 로컬 파일로 덤프하고 DAG 파싱을 진행할떄는 이 파일을 읽는다.Redis 등등 -> 프로세스가 죽어도 외부 소스를 통해서 캐싱을 처리가능DAG 파일 자체를 사전에 생성 -> CI/CD나 별도 Job이 DB 설정을 읽어서 이걸 기반으로 .py 파일을 만든다. 근데 이거는 사실 좀 어렵습니다. (대신 동적인 DAG 가 많은 경우에 좋겟죠 ) 이정도가 있을꺼 같아요. 질문 감사합니다!

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

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

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

음... 누락이 된거 같은데 잠시 추가로 확인해보겠습니다. 불편을 드려 죄송합니다. 일단 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을 활용하시면 좋을꺼같네요.