진짜중복/가짜중복을 나누는데 있어서

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 스스로 두 가지 해석이 가능하다는 걸 발견하신 거 자체가 굉장히 중요한 포인트를 짚으신 거예요!이 두 질문은 사실 서로 다른 것을 묻고 있어요 ~1번 질문은 "이 카테고리의 색상을 다른 색으로 교체할 때"를 묻는 것이고, 2번 질문은 "색상의 이름(표기)을 수정할 때"를 묻는 거예요 !진짜 중복인지 가짜 중복인지를 판단하는 질문은 1번처럼 "A 데이터의 값을 수정하면 B 데이터의 값도 같이 수정되어야 하는가?"예요 ~이 맥락에서는 HOME 카테고리의 색을 YELLOW로 바꿔도 UNIVERSITY 카테고리의 색이 반드시 YELLOW로 바뀔 필요는 없으니 가짜 중복처럼 보일 수 있죠 !그런데 2번처럼 "RED라는 색상 자체의 이름 표기를 '빨강'으로 바꿀 때"를 생각해보면, RED라는 값을 공유하는 모든 카테고리가 동시에 '빨강'으로 바뀌어야 하므로 이건 진짜 중복이 돼요 ~결국 어떤 관점으로 질문을 던지느냐에 따라 달라지는데요, 이 부분이 바로 "서비스에서 데이터를 어떻게 사용하느냐에 따라 판단해야 한다"는 원칙이 적용되는 지점이에요 !색상 값 자체를 하나의 독립된 데이터로 관리할 필요가 있다면(예: 색상 이름을 통일되게 관리해야 할 때) colors 테이블을 분리하는 게 맞고, 단순히 각 카테고리마다 독립적인 색상 속성 하나를 기록하는 수준이라면 분리하지 않아도 돼요 !머리로 이미 colors 테이블 분리가 맞다는 감을 잡으셨다면 그 직관이 올바른 방향을 가리키고 있는 거예요:)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

23강 문제4 질문드립니다.

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 잘 이해하셨어요 ! 읽기 전용 복제본이 쓰기 트래픽 자체를 직접 해결하지는 못해요 ~문제의 핵심은 "연결 시간 초과(Timeout)가 발생했다"는 부분인데요, 이 Timeout의 원인이 쓰기 트래픽 자체의 양보다는 DB 연결이 과부하 상태에서 폭발적으로 몰리면서 발생한 연결 관리 문제에 더 가까워요 !C가 정답인 이유는읽기 전용 복제본을 추가하면 전체 트래픽 중 읽기 트래픽을 분산시켜서 기본 DB의 부하를 크게 줄여워요 !전자상거래 서비스 특성상 할인 행사 때는 쓰기보다 읽기(상품 조회, 재고 확인 등) 트래픽이 훨씬 많은 비중을 차지하거든요 ! 그리고 RDS Proxy가 수많은 DB 연결 요청을 커넥션 풀링으로 관리해줘서 연결 Timeout 문제를 직접적으로 해결해줘요 ~말씀처럼 다른 선택지들이 문제 상황을 직접적으로 해결하지 못한다는 점도 C를 고르는 이유가 돼요 !A는 단순 알림 기능이고, B는 패치 중단 시간을 줄이는 기능이고, D의 ElastiCache는 읽기 캐싱엔 좋지만 연결 Timeout 해결에는 직접적이지 않아요 !결론적으로 말씀하신 대로 읽기 부하를 줄여서 전체 DB 부하를 낮추는 것, 그리고 RDS Proxy로 연결 관리를 개선하는 것이 합쳐져서 C가 가장 적합한 답이 되는 것이죠 :)이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~

멀티 필드 실무 질문드립니다.

안녕하세요 ! 질문 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"멀티필드 강의를보면 실무에서 검색조건을 줄때 정말 좋은 기능같은데 실무에서도 자주 쓰이는지 궁금합니다."-> 네, 멀티필드는 실무에서도 검색 기능이 필요한 서비스라면 꽤 자주 활용되는 기능이에요 !말씀하신 것처럼 내부적으로 text와 keyword 두 가지 형태로 데이터를 보관하기 때문에 저장 공간이 늘어나는 건 맞아요 ~다만 실무에서는 저장공간보다 검색 품질과 기능이 더 중요한 경우가 많고, Elasticsearch 자체가 대용량 데이터를 다루도록 설계된 툴이다 보니 멀티필드로 인한 저장공간 증가는 보통 크게 부담스러운 수준은 아니에요 !오히려 실무에서 더 중요하게 고려하는 부분은 어떤 필드에 멀티필드를 적용할지 선별하는 것이에요 !말씀하신 것처럼 20개 필드가 있을 때 모든 필드에 멀티필드를 적용하는 게 아니라, 유연한 검색도 필요하고 정확한 필터링도 필요한 필드인 상품명, 카테고리, 구매자명 등 꼭 필요한 필드에만 선택적으로 적용하는 방식을 많이 사용해요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

페이지네이션 질문드립니다.

안녕하세요 ! 질문 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"id가 랜덤임에도 엘라스틱서치에는 mysql seq개념처럼 insert된것부터 document가 쌓여 그냥 조회하면 순차적으로 insert된것부터 나오게 되는걸까요?"-> 우선 Elasticsearch는 기본적으로 데이터를 삽입 순서대로 보장해서 반환하지 않아요 ~기본 조회 시에는 관련성 점수(_score) 기준으로 정렬이 되는데, "글"이라는 동일한 키워드로 검색하면 모든 문서의 점수가 같아지게 돼요 ! 이렇게 점수가 동일할 때는 내부적으로 삽입 순서와 유사하게 나오는 경우가 많아서 순서대로 나오는 것처럼 보이는 거예요 :)"만약 아무런 조건없이 asc정렬을 하고싶다하면 그냥 _search만 해도 되는걸까요?"-> 삽입 순서대로 정렬을 보장받고 싶으시다면 _search만으로는 안정적이지 않아요 ~실무에서도 명확한 순서가 필요하다면 sort 옵션을 사용해서 특정 필드 기준으로 정렬하는 것을 권장드려요 !예를 들어 날짜 필드나 id 필드 기준으로 asc 정렬하는 방식을 많이 사용해요:)추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

mysql 의 bitmap

안녕하세요 옥윤님 ! 질문 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"bitmap은 db 테이블에서 정보가 보이지 않던데 , redis 명령어로만 확인이 가능한 건가요??"-> 네 맞아요! Bitmap은 Redis의 자료구조이기 때문에 MySQL DB 테이블에는 저장되지 않아서 DataGrip 같은 DB 툴에서는 확인이 되지 않아요 ~실습한 DAU 카운팅 기능을 보시면, Bitmap 방식으로 구현할 때는 데이터를 아예 MySQL이 아닌 Redis에만 저장하는 방식으로 구현했기 때문에 Redis 명령어로만 확인이 가능해요 !추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

2. Kafka 설치 파일 다운받기 404 Not Found 오류 관련

안녕하세요 쿠가이든님! 제보해주셔서 감사합니다:)제보해주신 덕분에 강의자료도 바로 수정할 수 있었습니다!감사합니다~~~

AWS ECR

안녕하세요 ! 질문 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 두 번 하는 데는 이유가 있어요 !로컬 cmd창에서 aws configure를 하는 이유는 로컬 환경에서 Docker 이미지를 빌드한 다음 AWS ECR로 Push하는 작업을 하기 위해서예요 !즉, 로컬에서 ECR에 접근하려면 로컬 환경에도 AWS 인증 정보가 등록되어 있어야 해요 !그리고 EC2 터미널에서 aws configure를 하는 이유는 EC2에서 ECR로부터 이미지를 Pull 받아서 실행시키기 위해서예요 !EC2도 마찬가지로 ECR에 접근하려면 AWS 인증 정보가 필요하거든요 !결론적으로 로컬에서 ECR로 Push하는 작업과 EC2에서 ECR로부터 Pull하는 작업이 각각 별도의 환경에서 이루어지기 때문에 두 곳 모두에서 aws configure를 해줘야 해요 !EC2 터미널에서만 configure를 하면 로컬에서 ECR로 이미지를 Push하는 작업이 불가능하게 돼요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

S3 예상 기출 3번

안녕하세요 ! 질문 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !사실 24시간 이내와 1일 후는 실질적으로 같은 의미로 보시면 돼요 !S3 수명 주기 규칙에서 1일 후 삭제로 설정하면, 객체가 생성된 다음 날 자동으로 삭제가 되거든요~그래서 결과적으로 생성 후 24시간 이내에 삭제된다는 요구사항을 만족하는 구성이라고 보시면 돼요 !참고로 S3 수명 주기 규칙은 시간 단위가 아닌 일 단위로만 설정이 가능하기 때문에, 24시간 이내라는 조건을 충족하는 가장 짧은 단위가 바로 1일 후 삭제가 돼요 :)추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

33강 3번 문제 D번 질문

안녕하세요 인석님 ! 질문 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 말씀처럼 D번의 NAT 게이트웨이는 실제로 인터넷을 경유하는 방식이 맞아요 ~그런데 이 문제의 핵심 조건은 "퍼블릭 IP를 사용해서는 안 된다"는 것이에요 !여기서 말하는 퍼블릭 IP는 EC2 인스턴스 자체가 퍼블릭 IP를 가지는 것을 금지하는 의미에요 !D처럼 EC2를 프라이빗 서브넷에 배포하고 NAT 게이트웨이를 통해 연결하면, EC2 자체는 퍼블릭 IP를 갖지 않게 되므로 이 조건을 만족하게 돼요 ~즉, "퍼블릭 IP를 사용하지 말라"는 조건과 "인터넷을 전혀 쓰지 말라"는 조건은 다른 의미예요 !만약 인터넷 경유 자체를 완전히 피하고 싶다면 B번처럼 게이트웨이 VPC 엔드포인트를 사용하는 방식이 그 역할을 하는 거구요 !그래서 B와 D 둘 다 정답이 되는 거죠 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

insert , upsert 질문드립니다.

안녕하세요 ! 질문 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"결과가 PUT으로 할때나 POST로 할때나 결국 마지막꺼로 덮여씌워지는데 그냥 doc가 덮여져서 저장됐다 생각하면 될까요? 또 PUT이나 POST나 기능이 동일한데 일반 HTTP 메서드와 비슷하게 생각하면 되는걸까요?"-> /users/_create/{id} 는 PUT이든 POST든 HTTP 메서드에 관계없이 동일하게 동작해요 !create 엔드포인트는 해당 id가 이미 존재하면 에러를 반환하고, 존재하지 않을 때만 새로 저장하는 방식이에요 ~그래서 말씀하신 것처럼 마지막 걸로 덮어씌워지는 게 아니라, 두 번째 요청에서 이미 id가 존재한다는 에러가 발생하게 돼요 !덮어씌우는 동작은 create가 아니라 PUT /users/_doc/{id} 를 사용할 때 일어나는 거예요! 그리고 Elasticsearch에서 create 엔드포인트에 PUT과 POST 모두 사용 가능한 건, 일반적인 HTTP 메서드 의미(PUT=멱등, POST=비멱등)보다는 Elasticsearch 자체적으로 두 메서드를 동일하게 처리하도록 구현해둔 것으로 이해하시면 돼요 :)"UPSERT의 경우나 UPDATE ( 일부필드만수정 ) 의 경우 UPDATE로 age만 고치나 UPSERT로 그냥 전체 기존값을 쓰고 age만 바꿔서 하나 결과값은 동일한데 퍼포먼스차이나 실무에서는 그냥 update보다는 해당 Id에 다시 insert한다던가 어떠한 식으로 진행되는지 궁금합니다."-> 실무에서는 일반적으로 일부 필드만 수정할 때는 POST /users/_update/{id} 를 사용하는 걸 권장해요 !UPSERT(PUT /_doc/{id})로 전체 데이터를 다시 넣는 방식은 모든 필드 값을 다 알고 있어야 하고, 혹시라도 빠진 필드가 있으면 해당 필드가 사라져버리는 위험이 있어요 !반면 update는 변경하고 싶은 필드만 지정해서 보내면 나머지 필드는 그대로 유지되기 때문에 훨씬 안전해요 ! 퍼포먼스 측면에서도 전체를 덮어쓰는 것보다 일부만 수정하는 게 더 효율적이구요! 그래서 특정 필드만 바꾸는 상황이라면 update를 쓰는 게 실무에서도 더 일반적인 방식이죠 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~