무중단 배포

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"혹시 처음에는 하나 모놀리식으로 만들다가 ASG(auto scaling group과 LB)를 같이 쓰는 모드로 바꿀려면 기존에 설정을 바꾸어 주어야 하나요?"-> 네, 몇 가지 부분은 변경이 필요해요 ! 크게 보면 아래와 같은 부분들을 신경 써주셔야 해요~~우선 로드밸런서(ALB)를 앞단에 두게 되면 기존에 EC2의 퍼블릭 IP나 도메인으로 직접 트래픽을 받던 구조에서, ALB의 DNS로 트래픽을 받는 구조로 바뀌게 돼요 ! 그래서 도메인 설정이나 보안 그룹 설정을 변경해주셔야 해요 ~그리고 ASG를 쓰게 되면 서버 인스턴스가 여러 대로 늘어날 수 있기 때문에, 세션이나 파일 업로드 같은 부분에서 특정 서버에 종속되는 데이터가 없는지 꼭 확인해보셔야 해요 ! 예를 들어 로컬 디스크에 파일을 저장하거나 인메모리 세션을 쓰고 있다면 여러 서버 간에 데이터가 공유가 안 돼서 문제가 생길 수 있거든요 ! 이런 부분은 S3나 Redis 같은 외부 저장소로 이전해주시는 게 좋아요 ~또한 ASG에서 새 인스턴스가 자동으로 올라올 때 애플리케이션이 정상적으로 배포되어 실행될 수 있도록 Launch Template 설정도 잘 맞춰주셔야 해요 !기존 모놀리식 코드 자체를 크게 바꿀 필요는 없고, 인프라 구조 쪽 설정을 순서대로 잘 잡아주시면 전환이 가능해요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

workflows/deploy.yml 궁금증

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"혹시 이부분에 APPLICATION_PROPERTIES 말고 secretes 에 변수만 넣어서 하는 방법이 따로 있나요?"-> 네 ! APPLICATION_PROPERTIES는 application.yml 파일 전체 내용을 하나의 secret 값으로 통째로 넣는 방식인데요, 이 대신 각 환경변수를 개별 secret으로 분리해서 관리하는 방법도 있어요 ~예를 들어 DB_URL, DB_USERNAME, DB_PASSWORD 등 각각의 값을 GitHub Secrets에 따로 등록한 뒤, deploy.yml에서 application.yml을 직접 생성하는 방식으로 작성하실 수 있어요 !다만 이 방식은 환경변수 항목이 많아질수록 deploy.yml이 길어지고 관리가 번거로워질 수 있어서, 실제로는 APPLICATION_PROPERTIES 방식처럼 파일 전체를 하나의 secret으로 관리하는 게 더 편리한 경우가 많아요 ~프로젝트 규모나 팀 상황에 따라 편한 방법으로 선택하시면 될 것 같아요 :)추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

31강 이미지내용에 틀린 부분이 있는 것 같습니다.

안녕하세요 tjwcskdle1님! 확인해보니 말씀해주신 대로 3번째 서브넷 부분은 10.10.0.16/29가 맞습니다! 제보해주신 덕분에 다른 수강생분들도 같이 참고할 수 있겠네요:)감사합니다~!!

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

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 스스로 두 가지 해석이 가능하다는 걸 발견하신 거 자체가 굉장히 중요한 포인트를 짚으신 거예요!이 두 질문은 사실 서로 다른 것을 묻고 있어요 ~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하는 작업이 불가능하게 돼요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~