레디스 서버 한대가 죽더라도 락의 안전성을 보장하기 위해 3~5대의 다른 레디스 서버도 함꼐 있는거라면 이 서비스의 경우에는 레디스의 데이터를 모두 동기화시키는 작업이 매 요청마다 실행되는 건가요? 동기화 시키는 과정에서 TTL 에 작은 차이가 생길 수도 있디고 생각하는데 무시가능한 정도인지요?? 동기화를 시키지 않는다면 또 그 여러대의 레디스 서버가 봐라봐야할 한 곳이 다시 존재하게 됨으로써 어짜피 똑같은 건 아닌지.. 궁금합니다!
stream_notices 내부의 event_generator 함수 코드에서 yield f"data: {data}\\n\\n" 위의 개행 문자에 이스케이프가 두번 들어가서 메시지가 정상적으로 전송되어도 파싱 오류로 화면에 표시되지 않는 문제가 있는것 같습니다. 해결책은 이스케이프 문자를 하나만 사용하면 개행도 정상적으로 되고 문자열도 올바르게 출력됩니다. yield f"data: {data}\n\n"
# Redis 6.2 이상일 경우 GETDEL 사용 권장 # saved_code = await rd.getdel(cache_key) 이 코드 사용을 권장하셨는데 입력 값 비교 검증까지 통과하기 전에 값을 가져와서 바로 지워버리면 사용자가 실수로 인증번호 입력을 실패해도 다시 요청하도록 해야하는데 이를 감안하고서라도 GETDEL을 사용해야 한다면 이는 verify_code 함수의 원자성을 지키기 위한 권장 사항인가요? 혹은 verify_code 함수에 트랜잭션 관련 설정을 하고 GET과 DEL 호출을 쪼개서 하거나 Redis Functions을 사용하는 것을 고려하는게 더 나은지 궁금합니다.
docker exec -i my-redis redis-cli -x FUNCTION LOAD REPLACE < coupon_logic.lua 위의 기존 코드를 실행시키면 NOAUTH Authentication required 라는 오류가 발생합니다. 이 경우에는 docker exec -i my-redis redis-cli -a <비밀번호> -x FUNCTION LOAD REPLACE < coupon_logic.lua 와 같은 형식으로 입력하시면 정상 등록됩니다. 경고가 뜨긴 하는데 커맨드라인에 비밀번호를 직접 입력하지 말라고 하는거네요.
강의를 들으면서 코드를 따라 쳐보거나 개인적으로 간단한 기본 게시판을 만들어보면서 "보일러플레이트가 좀 많은데?"라는 생각이 들었습니다. 물론 FastAPI의 비동기 처리나 ML 붙이기도 쉬우며 api 개발과 문서화가 빠르고 간편하다는 장점이 있지만 이것만으로 실제 서비스 상황에서 FastAPI를 선택하는 이유가 되는 지에 대해 의문이 들었습니다. 실무에서는 어떤 기준으로 FastAPI를 고려하게 되는 지 질문드리고 싶습니다!
안녕하세요. 현재 팀 단위 프로젝트를 진행 중이며, Python으로 구현한 모델을 API 형태로 서빙하는 역할을 맡아 FastAPI를 공부하려고 합니다. LLM 모델을 로드하고 추론 요청을 처리하는 모델 서버 용도로 FastAPI를 활용할 계획이며, Spring 백엔드에서 해당 서버를 호출하는 구조를 고려하고 있습니다. 이 강의가 모델 서빙을 직접적으로 다루는 강의는 아니지만, FastAPI에 대해 전혀 모르는 상황이라 우선 강의를 통해 기본기를 익히고자 합니다. 모델 서버 구축 목적이라면 강의에서 어떤 섹션들을 필수적으로 들어야하는지 강사님의 의견을 듣고 싶습니다. 감사합니다.
학습 관련 질문을 남겨주세요 성실히 답변해드립니다! 강의와 관련이 없어도 유사한 학습 질문도 괜찮습니다 강의에서 나오는대로 따라 모두 설치를 했습니다. 근데 제 vscode에서는 강의처럼 자동 완성을 강의처럼 제공해주지 않고 있어요... 혹시 어떤 익스텐션인지 알 수 있을까요? 그리고 fastapi와 react에서 더 유용한 익스텐션들이 있다면 알고 싶어요!
안녕하세요. "주식 자동 매수 스케줄러 구축 2" 챕터 강의에서 아래와 같이 자동 매수 프로세스를 수동으로 트리거 API 호출했습니다. post /purchase/trigger trigger_auto_purchase() 함수 호출 API 응답 상태 코드: 200 API 응답 본문: {"rt_cd":"1","msg_cd":"40910000","msg1":"모의투자 주문이 불가한 계좌입니다."} 2026-02-18 18:04:16,130 - stock_scheduler - ERROR - 메타(META) 매수 주문 실패: 모의투자 주문이 불가한 계좌입니다. 위와 같이 응답 결과를 받았는데 영상을 보니 같은 모의 투자를 하신 것으로 보이는데 어떻게 주문 성공 처리되신건지 궁금합니다.
내가 타이타닉에 탔었다면?! PyTorch & Next.js로 생존 확률 예측 AI 웹 서비스 만들기
안녕하세요! 코드 중에서 이해 안가는 부분이 있어 질문드립니다. fig = px.sunburst(df, path=["Pclass", "Sex", "SurvivalStatus"], values="PassengerId", # 각 조각의 크기를 승객 수로 설정 title="Hierachical View of Survival by Class and Sex", color="Survived", color_discrete_map={1:'gold', 0:'darkblue'}) fig.show() 여기에서 values="PassengerId", # 각 조각의 크기를 승객 수로 설정 이라고 하셨는데 PassengerId는 단순 인덱스 개념이 아닌가요? 왜 사람 수를 의미하게 되는지 이해가 잘 가지 않습니다.
is_host와 사용자의 캘린더 보유를 모두 사용해야 한다고 생각합니다. 개인적으로 호스트가 정해진 서비스라면 모두 고려할 필요는 없지만, 실제 누구나 호스트의 역할을 하게 된다면 2가지를 병행해서 사용해야 한다고 판단했습니다. 홍길동이 호스트가 될수도 있고, 게스트도 될수 있습니다. 그래서 호스트별로 마스터가 될수 있는 캘린더의 아이디를 저정해서 실제 보유하고 있는 권한이 있는 호스트 인지 판단하려고 합니다.
파일삭제에 대한 정책은 있어야 한다고 생각합니다. 파일 저장공간에 대한 것은 비용입니다. 삭제 주기는 서비스 정책 및 신청약관에 명기해야 합니다. 파일 업로드시 YYYY/MM/DD 구성으로 파일 디렉토리를 구성해서 쉽게 일괄 삭제 할수 있게 구성합니다. 부킹데이터를 삭제하면, 파일도 삭제할 것인지 여부 해당 서비스가 무료/유료여부에 따라서 달라질것 같습니다. 원칙은 삭제해야 하는데, 해당 서비스의 경우 파일은 바로 삭제할것 같습니다. 보통 게스트의 개인정보와 관련된 것들이 많을것 같아서 바로 삭제하는 것이 좋습니다.
1) 부킹 파일 삭제 시, 먼저 '삭제 대기'로 해당하는 테이블 행에 표시를 하여 놓고, 일정 기간 후에 정리 작업을 통해 테이블로부터 삭제를 하여주고, 스토리지에서도 해당 파일을 같이 제거해 줍니다. 2) 부킹 삭제 시, 부킹을 먼저 '삭제 대기' 로 테이블 행에 표시를 하여 놓고, 파일들도 마찬 가지로 '삭제 대기'로 유지 시켜줍니다. 일정 기간 후, 부킹 데이터가 삭제 될 때, 같이 해당하는 부킹 파일 레코드 행들을 테이블로 부터 삭제하여주고, 스토리지에서도 물리적으로 제거 해줍니다. 이는 사용자가 실수로 특정 파일 및 부킹을 삭제 할 경우를 대비해 복구 할 시간을 주기 위함입니다. 즉시 물리 삭제를 수행할 경우 DB에는 삭제되었지만 파일이 남거나, 파일은 삭제되었지만 DB 에서는 계속 존재하는 불일치 문제가 발생할 수 있습니다.
게스트 예약 부킹 일정 변경 정책 일자와 타임 슬롯 변경을 허용합니다. 과거 일자로의 변경은 허용 되지 않습니다. 예약 날짜는 항상 현재 일자 및 시간 보다 미래 이어야 하기 때문입니다. 각 호스트 고유의 등록된 타임 슬롯으로만 변경이 허용 가능 합니다. 호스트 A의 캘린더에 지정된 타임 슬롯 이외에 시간을 선택한다면, 호스트와 게스트의 만남이 불가능합니다. 호스트의 캘린더에 해당 타임 슬롯의 자리가 비어있다면, 변경이 가능합니다. 그렇지 않다면, 해당 예약 내역 실패 오류를 반환합니다. 성공 시나리오 호스트 타임슬롯: 화,목,금 오후 3시 - 4시, 4시 - 5시, 6시 - 7시 (1월 3일~ 1월 10일 다 비어있음) 게스트는 2026년 1월 1일에, 2026년 1월 2일 (금요일) 오후 3시 부킹을 2026년 1월 6일 (화요일) 오후 6시로 변경하려고 합니다. a) 새 부킹 날짜는 현재 날짜보다 미래 날짜이며, b) 새 부킹 날짜는 호스트의 타임 슬롯의 일자와 일치하며, c) 1월 6일 오후 6시에는 자리가 비어있으므로, 일정 변경이 성공하게 됩니다. 실패 시나리오들 a) 1. 게스트는 2026년 1월 1일에, 2025년 1월 2일 (금요일) 오후 3시 부킹을 실수로 2025년 12월 30일 (화) 오후 6시로 변경하려고 합니다. 새 부킹 날짜는 현재 날짜보다 과거 날짜 이므로 유효 날짜 오류를 반환해줍니다. b) 1. 게스트는 2026년 1월 1일에, 2025년 1월 5일 (금요일) 오후 3시 부킹을 2026년 1월 5일 (월) 오후 6시로 변경하려고 합니다. 새 부킹 날짜는 현재 날짜보다 미래 날짜이므로 첫번째 조건을 통과합니다. 그러나, 호스트의 타임 슬롯 일자들과 맞지 않으므로, 유효하지 않은 타임슬롯 오류를 반환합니다. c) 1. 게스트는 2026년 1월 1일에, 2025년 1월 5일 (금요일) 오후 3시 부킹을 2026년 1월 6일 (화) 오후 6시로 변경하려고 합니다. 새 부킹 날짜는 현재 날짜보다 미래 날짜이므로 첫 번째 조건을 통과합니다. 호스트의 타임슬롯과 일치하므로, 두 번째 조건도 통과합니다. 그러나, 호스트의 캘린더에 이미 요청 시간대에 다른 게스트와의 예약이 존재하므로, 이미 존재하는 일자 오류를 반환합니다.
351쪽 내용 중에 "테스트할 때 현재 일시는 우리가 원하는 임의의 현재 일시값을 사용하도록 합니다. 종단점 함수에서는 어떻게 해야하고, conftest.py 파일에서 의존성 주입 오버라이드는 어떻게 해야할까요?" 이 질문에 대한 저의 구현이 맞는지 궁금합니다. appserver.apps.calendar.deps.py appserver.apps.calendar.endpoints.py conftest.py 3