안녕하세요.
멘토링을 하면서 주니어 개발자들이 어려워 하는 개념들에 대해 어떻게 하면 쉽게 전달할 수 있을지에 대해서 많은 고민을 하고 있는 푸(Foo)라고 합니다.
잘 부탁 드리겠습니다.
이력
2019. 08 ~ 현재 : 카카오 자바 백엔드 개발자
2021. 08 ~ 현재 : programmers 백엔드 데브코스 멘토
2021. 12 ~ 현재 : F-Lab 자바 백엔드 멘토
책
이것이 취업을 위한 백엔드 개발이다 with 자바(링크)
기타 이력 및 타 플랫폼 강의들은 아래 GitHub 링크에서 확인할 수 있습니다.
GitHub - https://github.com/lleellee0
Khóa học
Đánh giá khóa học
- Resilience4j để tạo ra các dịch vụ không có lỗi - CircuitBreaker
- Phân phối danh mục đầu tư của bạn rất dễ dàng
- Xây dựng hệ thống mạnh mẽ cho phép lỗi
- Quản lý log cần thiết cho nhà phát triển
- Chiến lược triển khai và mẹo để triển khai dịch vụ ổn định
Bài viết
Hỏi & Đáp
수강 추천
이진아 님 안녕하세요!만약 배포 경험이 없으셨다면 다음 강의 먼저 수강해보시는걸 추천드립니다!포트폴리오 초간단 배포하기 https://inf.run/My8ci 스프링 부트 애플리케이션 베이스로 만들어진 강의인데, 아마 지금 강의보다 훨씬 쉬울겁니다.혹시 이전에 개발 경험 적어주시면 좀 더 타겟해서 다른 강의 추천드리겠습니다. :)
- 1
- 2
- 12
Hỏi & Đáp
복제 관련 질문입니다!
오래 기다리셨습니다. 일반적으로는 Primary-Replica 간의 복제 지연이 크게 문제가 되진 않지만, 만약 신경 써야하는 상황이라면 근본적인 DB 복제 지연 시간 줄이기 '방금 글 쓴 사용자(시스템)'의 읽기 요청은 Primary DB로 보내주기위 2가지 방법이 함께 적용되면 좋을 것 같습니다.1번은 복제 지연 시간을 줄여 가급적 복제 지연으로 인한 데이터 불일치가 발생하지 않도록 하는겁니다. 방법은 여러가지겠지만, DB 서버들의 사양을 올리고 쿼리 튜닝, 병렬 복제 등 다양한 수단을 활용하면 됩니다. 다만 이 부분은 백엔드 개발자보다는 DBA 레벨에서 다뤄야할 내용들 인 것 같아요. 그럼 2번은 복제 지연이 발생하면 안되는 요청과 아닌 요청을 구분하여 복제 지연이 발생하면 안되는 요청에 대해선 읽기 연산도 Primary에서 이루어지도록 하는겁니다. 이 때에는 당연히 사용자나 시스템을 구분할 수 있는 Key를 두어 구분해야하고, 시스템마다 공유할 수 있게 Redis 같은 공유 저장소를 활용해야합니다.그리고 스프링 부트 애플리케이션 기준으로 DataSource 를 Primary와 Replica 양쪽에 대해 설정해주고, 요청에 따라 읽기 연산이지만 Primary로 연결해야할 요소를 구분해줘야합니다. AOP를 활용하면 좋겠죠?다만 이렇게 설정하는게 정말 우리 시스템에 필요한지 검토해볼 필요가 있습니다. DataSource 설정이 두개가 되는 것도 설정의 복잡함을 만들고, 일반적으로 Primary-Replica 구조에서 사용하는 DB Proxy를 활용한 자동 Failover가 동작하지 않을 수도 있습니다. 애플리케이션 레벨에서 Failover를 직접 처리해줘야할 수도 있어요. 이런 불편함을 감수할 필요가 있는지 검토가 필요합니다. 제가 대략 알고있는, 경험해본 내용은 이정도인데 답변이 됐을까요? 추가적으로 궁금한 내용 있으면 질문 남겨주세요~ :)
- 1
- 2
- 45
Hỏi & Đáp
복제 관련 질문입니다!
공부맛있다님 안녕하세요! 좀 더 구체적으로 복제 지연 때문에 어떤게 문제가 되는지 이야기 해주시면 저도 같이 고민해볼 수 있을 것 같습니다~DB 레벨에서의 복제 지연에 대한 내용일까요~?어쩌면 CAP 이론에 대한 내용 읽어보시면 궁금하셨던 내용을 해소하거나 좀 더 구체화시켜서 질문주실 수 있을 것 같습니다!한번 확인해보시고 마저 질문 남겨주세요~
- 1
- 2
- 45
Hỏi & Đáp
현업에서 서킷브레이커 상태 전파를 할 때 Actuator를 사용 하시는지 궁금합니다!
드루와라잇님 안녕하세요~다른 인스턴스들로 서킷 브레이커의 상태를 전파하기 위해서는 Kafka 같은 메시지큐나 Spring Cloud Config 같은 분산 설정 관리 도구를 사용합니다. Actuator는 특정 인스턴스의 서킷 브레이커 상태를 확인하거나 강제로 변경하기위해서는 활용할 수 있지만, 상태 전파가 목적이라면 메시지큐나 분산 설정 관리 도구를 활용하는게 좋습니다~ 서킷 브레이커 상태를 전파하는 상황에 대해 경험을 이야기 드리자면, '추천' 로직을 수행하기 위해 여러 머신러닝, 딥러닝 모델을 호출하곤 하는데요, 일부 모델이 높은 부하를 받아서 응답이 느려지거나 분석에 실패하는 경우 해당 모델로 가는 서킷을 OPEN 시키는 상황이 있었습니다. 궁금하셨던 내용에 대한 답변이 됐을까요?또 궁금한 내용 있으면 질문 남겨주세요.감사합니다.
- 1
- 1
- 31
Hỏi & Đáp
@Transactional선언 메서드 정상동작하는건가요?
후아휴님 안녕하세요!해당 내용은 제가 예제 코드를 제미나이로 생성하면서 의도와 다르게 작성된 부분입니다!(Self Invocation이 아니라 public 되어 있어 외부 호출을 가정하여 이렇게 작성된듯합니다)이 부분은 강의 흐름에서 주요하게 소개되는 내용은 아니지만, 혼란을 드릴 수도 있는 내용이라고 생각되어 강의 예제 코드에 주석으로 보충 설명과 이 질문글 링크를 남겨놨습니다.제보해주셔서 감사하고, 수강에 불편을 드려서 죄송합니다. (_ _)
- 1
- 2
- 46
Hỏi & Đáp
영상 편집이 잘못된 것 같아요. (순서가 중간에 계속 바뀜)
말씀하신대로 영상 편집본 중 일부가 중복으로 포함되어있었습니다.이 부분 수정하여 다시 업로드 했습니다. 🙂오류 제보해주셔서 대단히 감사합니다!!
- 0
- 3
- 37
Hỏi & Đáp
영상 편집이 잘못된 것 같아요. (순서가 중간에 계속 바뀜)
dongbin-yoon님 안녕하세요!제가 지금 바로 확인해보고 조치 및 답변 드리겠습니다.수강에 불편 드려 죄송합니다. (_ _)
- 0
- 3
- 37
Hỏi & Đáp
trace 로그 보관 질문
안세영님 안녕하세요~우선 개발 환경에서 로그 레벨별로 파일을 나눠서 보관하는 경우는 흔하게 있습니다.다만 말씀하신 것처럼 'app-trace.log' 형태보다는 'app-trace-20250710.log' 같은 형태로 일단위로 로그를 저장하는 경우가 더 일반적입니다. 이렇게 파일 이름에 날짜가 들어있어야 파일 이름만으로 일정 기간이 지난 로그를 삭제하기 용이하기 때문입니다! 마지막으로 질문 주신 '그럼 trace로그도 하나로 묶어서 보관하는지, 묶는경우 삭제가 안되니까 나눠서 보관하는지요?' 라고 이야기해주신 내용에 대해선 상황에 따라 다르겠지만, 저의 경우 동일한 파일(정확히는 ElasticSearch의 인덱스)에 일자별로 구분하여 함께 보관하긴 합니다. (trace 로그도 너무 많이 로그가 남지 않도록 정리하고 있습니다.)다만 trace 로그가 너무 많이 발생한다면 다른 파일로 분리하는게 좋고,일반적인 애플리케이션 로그는 더 길게 보관용량이 큰 trace 로그는 짧은 기간만 보관하는 형태로 운영하는 경우도 아주 일반적입니다. 궁금하신 내용에 대한 답변이 됐을까요?또 질문 있으면 질문 남겨주세요.감사합니다.
- 1
- 2
- 42
Hỏi & Đáp
학습내용 블로그 개재 여부
김영록님 안녕하세요! 넵 올리셔도 괜찮습니다. 다만 인프런 AI 인턴이 이야기 한 것처럼 강의 출처를 명시해주시고, 강의 내용을 거의 똑같이 올리다시피 하지만 않으시면 좋을 것 같습니다!추가적으로 질문 있으면 질문 남겨주세요! 감사합니다.
- 1
- 2
- 49
Hỏi & Đáp
혹시 강의자료랑 강의 안에 나오는 pdf와 같은거가요?
핵심국사님 안녕하세요~해당 PDF는 과거 컨퍼런스에서 발표했던 내용의 PDF이고, 강의 자료는 제가 따로 올려두지 않았었습니다.조금 전에 업로드 해놨으니 확인해보시기 바랍니다.https://inf.run/AQDyU 수강하면서 궁금한 내용 있으면 또 질문 남겨주세요.감사합니다.
- 1
- 2
- 66