Hỏi & Đáp
안녕하세요 한번 더 문의드립니다.
제가 또 놓쳐버린 건가요..? ㅠㅠ 정말 죄송합니다. 잠시만요
- Lượt thích
- 0
- Số bình luận
- 1
- Lượt xem
- 14
Hỏi & Đáp
제가 또 놓쳐버린 건가요..? ㅠㅠ 정말 죄송합니다. 잠시만요
Hỏi & Đáp
안녕하세요 태경님 질문 남겨주셔서 감사합니다!! 우선 아무래도 인덱스라는 주제 하나로만 잡고 컨텐츠를 만드는것은 힘들꺼같고 ㅠㅠ 다뤄야 하는 정보가 크게 없습니다. 그나마 좀 더 다루는게 PostgreSQL 정도가 아닐까 싶습니다...!! 하지만 그렇다고 저런 인덱스들을 다 중점적으로 다루는 강의는 아니에요!! 그리도 현재 다른 DB에 대해서도 관심은 많지만, 현재는 AI 관련된 컨텐츠를 준비하고 있어서 추후에나 진행이 될꺼같습니다.. ㅠㅠ 감사합니다!
Hỏi & Đáp
안녕하세요 수업자료에 각각 첨부해드린걸로 기억하는데 확인해보시겠어요!?
Hỏi & Đáp
안녕하세요 종혁님 우선 sub 라는 필드는 보통 이 토큰을 사용하는 사용자의 정보 를 담게 됩니다. 그래서 우선적으로 정리해보자면 이렇게 이해하시면 될 꺼 같아요. 이메일을 Subject로 사용하는 경우 이메일이 서비스에서 유일한 값이고 로그인 ID 역할을 한다면 - sub = "hong@example.com" 회원 ID를 Subject로 사용하는 경우 (가장 많이 사용하는 방식) 데이터베이스의 PK가 변경되지 않는 값이라면 가장 안정적입니다. - sub = "12345" Username을 Subject로 사용하는 경우 Username이 절대 변경되지 않는 정책이라면 가능합니다. - sub = "hong" 그래서 우선적으로 제가 표현이 잘못되었을 수도 있을꺼 같은데 여러개의 sub 를 만든다라는 관점보다는 여러개의 기준 값이 들어갈 수 있다고 봐주시는게 좀 더이해하기에 편할꺼 같습니다. 이외에도 role , scope 같은 관점들도 들어갑니다.
Hỏi & Đáp
안녕하세요 식빵님 질문주셔서 감사합니다. 우선 이거는 음 Docker Desktop 문제로 보여요. cri-dockerd랑 프로비저닝 모드 문제로 알고 있습니다. 기본적으로 식빵님이 kubectl exec 를 실행하게 된다면, 특정 서버를 경유하게 되는데 (CRI) 이떄 이 경로에 프로토콜 불일치가 있기 떄문에 보이는 문제로 보입니다. 우선 Docker Desktop을 최신 버전으로 업데이트 해보세요. 버전 문제일수도 있을꺼 같아요. 아니면 가장 확실하게 해결할 수 있는 방법은 kind 모드로 변경하는 겁니다. Settings -> Kubernetes -> Cluster provisioning 부분에 kubeadm을 kind로 변경하시면 됩니다. 근데 이거는 이외에 추가적인 트러블 슈팅이 필요 할 수 있을꺼 같네요. 아니면 현재 실습을 기준으로만 한다면, 임시로 우회를 하시면 될꺼같습니다. docker ps | grep docker exec -it /bin/bash 혹시 진행해보시고 이슈 있다면 추가로 질문 남겨주세요 감사합니다.
Hỏi & Đáp
안녕하세요 규혁님!! 질문 주셔서 감사합니다. 사실 사용가능한 툴은 너무나도 많아요 대표적으로 Kafka UI 가 있을 수 있습니다. JSON으로 UI에서 직접 입력 그 외에도 Kafka HQ , Terraform 등등 인프라 환경에 따라서 제공되는 서비스들을 사용해보시면 좋을꺼 같아요!! 이 친구들은 yaml 같은 형태로 선언해서 사용을 합니다. 제가 그냥 쉘 스크립트로 진행한 이유는 추가적인 툴을 사용하지 않고도 적용이 가능하다는것을 보여드리기 위함이니 추후에 이런 서비스를 직접 구축하게 되실 떄 참고해보시면 좋을꺼 같습니다. 감사합니다!!
Hỏi & Đáp
안녕하세요 답변이 늦어서 죄송합니다 ㅠ.ㅠ 아무래도 개발을 설계하는 과정과 실제 구현체가 일부 다른 부분이 있는거 같습니다../ 하다보니 달라 질 수 있는데 이게 반영이 안된거 같네요 관련해서는 검토해보도록 하겠습니다. 기본적으로는 실제 구현체의 구조가 맞기때문에 해당 부분을 위주로 봐주시면 될 꺼 같습니다. 보시는데에 있어서 불편을 드려 죄송합니다...!
Hỏi & Đáp
안녕하세요 sejeong1108님 질문 주신 부분이 맞습니다. 말해주신 내용대로 자식 프로세스르 관점으로 띄우기 때문에, DAG 파일 하나당 별도 프로세스로 파싱하고, 끝나면 종료를 하게 됩니다. 즉 그래서 모듈 레벨에서의 @lru_cache 라는 애는 파싱 주기간에는 보존이 안되요. 대신 단일 파싱 사이클에서는 캐시가 유호할겁니다. 예를들어 한 DGA 파일 안에서 같은 설정 조회 함수를 여러 DAT/Task 루프에서 호출을 한다면, 한번만 DB에 가고 캐시에서 처리를 하는거죠 SingleFlight라는 패턴 공부해보시면 좋을꺼같아요. 음 추가로 현업에서 자주 사용하는 패턴에서 효과가 좋을만한것들만 우선적으로 나열해보자면, 파일 기반 캐시 -> 별도 스케줄러가 주기적으로 DB -> 로컬 파일로 덤프하고 DAG 파싱을 진행할떄는 이 파일을 읽는다. Redis 등등 -> 프로세스가 죽어도 외부 소스를 통해서 캐싱을 처리가능 DAG 파일 자체를 사전에 생성 -> CI/CD나 별도 Job이 DB 설정을 읽어서 이걸 기반으로 .py 파일을 만든다. 근데 이거는 사실 좀 어렵습니다. (대신 동적인 DAG 가 많은 경우에 좋겟죠 ) 이정도가 있을꺼 같아요. 질문 감사합니다!
Hỏi & Đáp
안녕하세요 smallchoi님 질문 주셔서 감사합니다!! 모든 쿼리는 수업 자료에 첨부되어 있는데 혹시 그쪽 부분을 확인해보시겠어요?? 영상 아래쪽에 수업 노트 이 영역을 클릭하시면 관련된 쿼리들이 보이실겁니다.
Hỏi & Đáp
음... 누락이 된거 같은데 잠시 추가로 확인해보겠습니다. 불편을 드려 죄송합니다. 일단 Docker의 경우에는 대부분의 사람들이 사용한다는걸 어느정도 가정한 부분은 있어서 따로 설치하는 과정은 다루지는 않았습니다. 윈도우, 맥, 리눅스 등등 환경마다 각각 다 다르다보니 이 부분은 양해 부탁드립니다. 사용한 IDE는 젯브레인 계열 아무거나 사용하시면 되고 저는 goland 사용했는데 이게 개발자마다 다 달라서... 평소 사용하시는걸 사용하시는걸 추천드립니다. 하지만 연결 관련해서 촬영했던 기억이 있는데 이 부분을 한번 검토해볼게요. 다시한번 불편을 드려서 죄송합니다.