리뷰이벤트 질문

이메일로 입장 전달해드렸습니다.

subnet, eni private <-> public설정 관련 궁금한게 있습니다!

안녕하세요 이재영님,2번: Public Subnet + Private ENI퍼블릭 서브넷은 라우팅 테이블이 인터넷 게이트웨이(IGW)를 포함하고 있어 외부와 통신이 가능한 서브넷입니다. 그런데 여기에 연결된 ENI가 퍼블릭 IP를 할당받지 않은 경우, 해당 인스턴스는 직접 인터넷과 통신할 수 없습니다.예를 들면, 인스턴스를 퍼블릭 서브넷에 띄우긴 했지만, 보안 또는 비용 이슈로 인터넷 통신을 제한하고 싶을 때 아마도... NAT 인스턴스나 로드 밸런서 바로 뒤에 있는 애플리케이션 서버가 이런 구조일 수 있습니다.그리고 퍼블릭 서브넷에 있는 이유는 다른 퍼블릭 리소스와 저지연 통신을 위해서지만, 직접 외부 노출은 피하고자 할 때 사용합니다.주의할 점으로는 외부와 직접 통신할 수 없기 때문에, 외부 통신이 필요하다면 NAT Gateway나 다른 방식을 사용해야 합니다. 4번: Private Subnet + Public ENI제 생각에 이럴 경우는 없는데요. 프라이빗 서브넷은 라우팅 테이블에 인터넷 게이트웨이가 없는 서브넷입니다. 그런데 ENI에 퍼블릭 IP가 붙어 있는 경우, 결국 외부와 통신을 시도하더라도 라우팅 경로가 없어 실패하게 됩니다.아마도 구성 실수로 퍼블릭 IP가 할당된 경우에 해당합니다. 또는, 서브넷 구조가 바뀌었지만 ENI 설정은 그대로 남은 경우. 실무에서는 일반적으로 비권장 구성입니다. 퍼블릭 IP가 있더라도 라우팅 테이블이 막혀 있기 때문에 효과가 없고, 보안상 혼란을 줄 수 있습니다. 실질적으로 이 조합은 작동하지 않으며, 설계 오류로 간주되는 경우가 많습니다.

postgres_loader의 apache-airflow-providers-postgres 버전 호환성

안녕하세요 jhlee님,Airflow는 오픈소스 프로젝트이다 보니, 버전 간 충돌이 발생하는 경우가 종종 있습니다. 그런 상황에서도 혼자 해결하려고 시도하셨다니 정말 잘하셨습니다.이번에 사용하신 apache-airflow-providers-postgres 6.x 버전에는 주요한 변경 사항이 포함되어 있습니다. Airflow의 공식 정책에 따르면, 각 provider 패키지는 특정 버전 이상의 Airflow core와만 호환되도록 되어 있습니다. 예를 들어, Postgres provider의 6.x 버전은 Airflow 2.11.0 이상에서만 사용할 수 있고, 5.x 버전은 Airflow 2.6.0 이상과 호환됩니다. 따라서 현재 사용 중인 Airflow 2.10.5 환경에서는 6.1.2 버전이 제대로 작동하지 않으며, 호환되는 5.x 버전을 사용하는 것이 올바른 선택입니다.좋은 질문 잘하셨습니다!

Airflow Limitation 강의에 대한 질문

안녕하세요Airflow는 각 Task를 실행할 때 스케줄링, Task 상태 확인, 로그 수집, 워커로 전달, 실행 환경 구성 등의 오버헤드(Overhead)가 발생합니다. 이 오버헤드가 실제 Task 실행 시간보다 길어지면 오히려 효율이 떨어지겠죠. 특별하게 정해진 것은 없지만 최소 Task 실행 시간은 약 30초 ~ 1분 이상. 그리고 설명드린대로 Task 하나의 실행 시간이 30초 미만이면 오버헤드가 상대적으로 커져 비효율적일 수 있죠.저라면 1분 이상의 작업 단위로 쪼개는 것을 추천하겠습니다.실제로는 Task당 1~5분 정도의 실행 시간이 가장 일반적이며, 이보다 짧으면 병렬 처리의 장점보다 오버헤드가 더 커질 수 있습니다.도움이 되었으면 좋겠습니다!

상속 질문

안녕하세요 천천히꾸준하게님,아이디가 아주 마음에 드네요 ㅎㅎㅎ Q1. Child 객체를 만들면 GrandParents 생성자도 실행되는데, 이게 항상 그런가요?네, 맞습니다.class Parents(GrandParents): def __init__(self): super().__init__() # GrandParents의 생성자 호출 Child 클래스의 생성자에서 super().__init__()을 호출하면, 그건 Parents의 생성자를 호출하게 됩니다. 그런데 Parents 생성자 안에 또 super().__init__()이 있기 때문에, 결과적으로 GrandParents까지 호출되는 거죠.즉, 연쇄적으로 올라가서 모든 조상 클래스의 생성자가 호출됩니다. 그래서 Child 객체는 grandmother, grandfather, mother, father 속성을 다 가지게 되는 거예요.Q2. 이런 식의 상속 방식, 실무에서 자주 쓰이나요?꼭 필요한 경우에만 이런 다단계 상속을 씁니다.실무에서는 일반적으로 다음과 같은 방식이 더 선호됩니다:상속은 깊지 않게 (2단계 정도가 적절)공통된 기능은 Mixin이나 Composition(구성) 방식으로 해결super()는 명확한 초기화 순서를 관리할 때 사용파이썬의 다이아몬드 상속(Multiple Inheritance)이 복잡한 문제를 일으킬 수 있기 때문에, 다단계 상속은 구조가 단순하거나, 잘 설계된 프레임워크 안에서만 사용하는 편이 좋습니다. Q3. Child 클래스에서 super()를 호출할 때, GrandParents는 빼고 Parents만 호출할 수 있나요?사실상 직접적으로 Parents만 호출한다는 건 불가능합니다.왜냐면 super()는 메서드 탐색 순서(Method Resolution Order, MRO)에 따라 위로 올라가며 init()을 호출하는 방식이기 때문입니다. 만약 정말 Parents까지만 호출하고 싶고, GrandParents는 제외하고 싶다면 Parents 클래스에서 super()를 아예 호출하지 않도록 수정해야 합니다. 그럼 도움이 되셨길 바라겠습니다 ~~!

MLFlow model versioning 방법 문의

안녕하세요 yuki님,강의 뒷부분에서 나오겠지만, MLflow의 mlflow.register_model() 또는 mlflow.register_model_from_run()을 사용하면 실험에서 모델을 자동으로 Model Registry에 등록할 수 있습니다. 또한 MLflow의 Autologging 기능을 사용하면 모델을 훈련하면서 자동으로 Model Registry에 등록할 수도 있습니다.예를 들면, 강의 자료 안에 mlruns/mlflow_client_run.py 보시면 코드 예제도 보실 수 있습니다.필요한 방식에 맞춰 적용하면 될 것 같네요! 😊

BroadCast 지원 가능 메모리 문의

안녕하세요 민수님,일단 첫번째 질문에 대한 답변으로는 Spark에서 broadcast 변수를 사용할 때, 최대 메모리 크기는 Spark의 executor 메모리 및 드라이버 메모리 설정에 따라 달라집니다. 하지만 일반적으로 몇 가지 고려해야 할 사항이 있습니다.기본적으로 spark.driver.maxResultSize 설정에 영향을 받음기본값은 1GB이며, 더 큰 데이터를 브로드캐스트하면 OOM(Out of Memory) 에러가 발생할 수 있음.필요하면 값을 늘릴 수 있음 (spark.driver.maxResultSize=4g 등).spark.sql.autoBroadcastJoinThreshold 값기본적으로 10MB (10485760 바이트) 이상인 경우 자동 브로드캐스트가 비활성화됨.이 값을 늘리면 더 큰 데이터를 브로드캐스트할 수 있지만, 너무 크면 실행 성능이 저하될 수 있음.Executor 메모리 제약브로드캐스트 데이터는 각 Executor에서 메모리에 유지되므로, 개별 Executor의 메모리 크기에 따라 제한됨.두번째 질문에 대한 대답으로는 저희가 meta를 dim_table이라 할 경우 ...브로드캐스트 가능: dim_table이 작을 경우 (보통 100MB 이하).브로드캐스트 불가능: dim_table이 크거나, TB 크기의 테이블에서 여러 컬럼과 매핑할 경우.대안: Shuffle Join, Partition 조정, Bloom Filter 등을 활용하시면 될 듯 합니다.

total을 float으로 바꾸신 이유

안녕하세요 천천히꾸준하게님,좋은 지적인 것 같습니다. 하지만, 나중에 경력을 쌓으시면 아시겠지만, 코드는 명시적으로 개발하면 할수록 타 개발자와 협업하기가 좋습니다. 이부분에서는 total이 int임을 명시적으로 float로 변환함으로써 의도를 명확히 하려는 목적이었습니다.답변이 도움이 되었으면 좋겠습니다.

docker-compose

안녕하세요 비가얼어죽으면비동사,그러게요 "django_celery_beat_periodictask" does not exist 에러가 있는 걸 보니 마이그레이션이 안되었나 보네요.레퍼런스로 올려주셔서 감사합니다

저만 안 되는 것인가요? ㅠㅠ

안녕하세요 Inhwa Choi님,localhost를 사용할 때 어떤 운영체제에서는 0.0.0.0이 되고, 어떤 운영체제에서는 127.0.0.1이 되는 이유는 운영체제의 네트워크 설정 방식과 특정 소프트웨어의 기본 바인딩 주소 차이 때문입니다.운영체제 자체는 일반적으로 localhost를 127.0.0.1로 해석하지만, 특정 네트워크 설정이나 애플리케이션의 기본 바인딩 방식에 따라 0.0.0.0이 될 수도 있습니다.이를 확실히 구분하려면 /etc/hosts 파일과 애플리케이션의 네트워크 바인딩 옵션을 확인하는 것이 중요합니다.차이는 없으니, 별로 신경쓰지 않으시고 되는 걸로 하시면 됩니다 ㅎㅎ