'서비스 개발자를 위한 Kafka 쉽고 깊게 알기' 학습자료 오류

안녕하세요 수박님! 해당 질문 확인해주셔서 이용하시면 좋을꺼같습니다. https://inf.run/XcaYU 감사합니다!

커서기반의 페이징 부분 질문 있습니다.

안녕하세요 shyu6370님 질문 남겨주셔서 감사합니다.확인해본결과 ULID 라고 제가 말씀드렸는데 잠시 혼동이 있는거 같습니다. 감사합니다.

JDK 선택할 때 궁금점!!

안녕하세요 현자타임님 질문 주셔서 감사합니다. 우선 기준은 사실 크게 잡혀있지 않스니다. 완전하게 신규 플랫폼을 위한 프로젝트라면 Stable한 버전을 보통 사용하거나 최신 버전을 우선적으로 사용합니다. 왜냐하면 사용하는 라이브러리들에 대해서 기본적인 보안 이슈가 보통은 최신 버전의 언어를 요구하기 때문입니다. 하지만 만약 기존 레거시 시스템이 존재한다면, 보통은 해당 레거시 시스템의 버전을 따라갑니다.왜냐하면 기존 레거시 시스템의 모듈을 import해야 하는 경우 호환성이 지켜지지 않을 수 있기 떄문입니다. 그래서 상황에 따라 기준이 일부 상이하기 떄문에 이런 부분을 고려하시면 좋을꺼같고. 결과적으로 말씀드리자면 기준은 거의 없다고 보시면 됩니다. 보통은 레거시 시스템을 따라간다 정도로 이해하시면 될꺼같아요.그리고 보통은 openJDK를 저는 주로 사용하였습니다. 이유는 딱히 없고... 그냥 처음 접했던 sdk였기 떄문에 그대로 사용하는거 같아요.

혹시 어플리케이션을 실행할 수 있게 readme 같은건 따로 없나요?

안녕하세요 현자타임님 질문 남겨주셔서 감사합니다. 우선 docker를 실행후에, docker-compose 파일을 실행시켜주시면, kafka, zookeeper, kafka-ui가 실행이 될 겁니다. 그러면 기본적으로 사용하는 서비스들은 모두 실행이 된 것이고, 이후 bank-lecture, lecture-consumer 두 서비스를 구동시켜주시면 됩니다. 이 둘 사이에 순서는 크게 중요하지 않습니다. 다음으로는 client를 호출하여 API를 테스트 해보시거나, client를 사용하지 않는다면, curl, postman등을 활용하여 서버에 요청을 보내보시면 좋을꺼같습니다.clinet 실행은 README.md 파일을 참고해주시면 좋을 꺼 같습니다. 감사합니다.

패키지, 디렉터리 구조 질문 (강의 내용 관련X)

안녕하세요 동민님 질문 주셔서 감사합니다. 우선 패키지 경로는 제가 구현을 하면서 일부 설정이 잘못된 경우였던걸로 기억나는데, 이러한 설정을 기반으로도 동작이 가능하다는것을 보여드리고자 그냥 그대로 진행하였습니다. 딱히 큰 문제라고 생각하지 않았어요. 또한 실무에서도 이 부분은 기본적으로 적용되는 경로를 사용하는게 일반적이겠죠. 이 부분은 강의에서 크게 중요한 부분은 아니라서 그냥 그대로 진행했다고 봐주시면 됩니다. View도 비슷한 맥락입니다. 강의 목표와는 무관한 내용이기떄문에, 크게 고려하지 않았습니다. 혹시라도 혼동이 오신다면, 그 부분에 대해서는 제가 사과드리도록 하겠습니다. 강의 목표에 벗어나는 주제에 대해서는 크게 고려하지 않고 안일하게 생각한 저의 잘못이죠 ㅠㅠ

코틀린

Kotlin도 사실상 Java를 지원해주기 위한 함수형 프로그래밍일뿐입니다. Java에서 사용하는 Spring을 통해 기본적으로 비슷한 형태를 구현하기 떄문에 보시는데에 있어서 큰 문제는 없을꺼 같아요!

jpa entity 질문

안녕하세요 HAHA님 핵심을 잘 찌르는 질문 주셔서 감사합니다.사실 이 주제는 저도 아니만 같이 강의를 만드시는 분들 입장에서도 꽤나 주제가 많이 갈리는 주제였습니다.개발의 편의성이 중요하냐, 아니면 기본적인 규칙을 맞추는것이 중요하냐의 문제로 논쟁거리가 많았던 주제이기도 합니다. 하지만 상황에 따라서 조금 달라 질 수 있는 부분이 존재 할 꺼 같아요. data class 선언시 프록시 질문맞습니다. 지연로딩이라는 것이 프록시를 통하고 불변 객체를 통해 구동이 된다면, 정상 동작하지 않을 수 있죠. 그래서 일반적인 class가 권장됩니다. 하지만 상황에 따라서 kotlin-allopen 플러그인을 사용한다면, @Entity가 붙은 객체를 open 상태로 변경해주는 기능도 동작 가능합니다. 이런 플러그인도 고려해 보시면 좋지 않을까 싶어요. 이 부분에서 많이 갈리는게, 프로젝트를 data class로만 구성하고 싶어하시는 분들이 많습니다. 저도 어느정도 공감하는 부분도 많아서... class나 data class냐는 꽤나 논쟁거리가 있는거 같아요. Data class 사용 시 equals & hashCode이 부분도 질문해 주신 부분이 맞죠. 기본적인 id만을 비교 하는것이 성능과 안정성 면에서 좋습니다.왜냐하면 Entity가 영속되지 않은 상태(transient)일 때나, 지연 로딩된 필드가 로드되지 않았을 때 전체 필드로 비교하면 오동작할 수 있다는 문제가 있기 떄문입니다.그래서 class를 사용하는것이 더 유리하기도 합니다면.. data class를 사용하는 경우에 대해서는 오버라이딩 하는 표현식이 필요합니다.저는 그냥 이런 부분까지는 고려를 잘 안하는 스타일이라서... 그냥 작성을 하기는 했습니다.data class User(@Id val id: Long, var name: String) { override fun equals(other: Any?): Boolean { if (this === other) return true if (javaClass != other?.javaClass) return false other as User return id == other.id } override fun hashCode(): Int = id.hashCode() }간단하게 작성해보았는데, 이런 형태이지 않을까 싶습니다. data class 목적사실 저는 data class라는 표현을 사용하는것을 좋아해서 해당 형태로 모두 구현한 부분이기는 합니다. 당연하게도 정석적인 코어 레벨로 구현을 한다면, class가 좀 더 entity에 어울리는것은 사실이기도 하고요. 하지만 kotlin의 문법을 최대한 알려드리고 싶어서 data class로 모두 사용을 하였고, 일반적으로는 response에만 많이 사용하거나, 중간 DTO 모델 정도에만 많이 사용되는것이 data class의 사용처이죠하지만 일부 Entity에도 사용 할 수 있어요. 누군가에게는 그렇게 권장하지 않는 형태라고도 할 수 있겠지만, 저는 그렇게 규격에 얽메이는 것을 싫어해서... 예를들면 val대신 var로 구성 함으로써 내부 변수를 수정 가능한 형태로 구성하는 것이죠. equlas 질문말씀해 주신 부분이 맞죠. 예를들어 이런 형태가 있다고 가정해 볼게요.class Team( val members: List ) class Member( val team: Team )그러면 자동 생성된 함수들에 대해서는 양방향 참조가 발생 가능합니다.그래서 이런 형태에서는 ID만을 통해 검증을 하던가, ToString.Exclude, @EqualsAndHashCode.Exclude 이라는 형태도 사용하기는 합니다. 이 부분도 알아가시면 좋은데, 이렇게 처리하는것은 사실 떔빵?? 한다는 느낌에 가까워서 기본적으로는 구현체 함수를 오버라이딩 하는것이 편하실 겁니다. 결론적으로 말씀드리자면, 전체적으로 class가 Entity에 더 맞지 않냐?? 라는 생각은 맞습니다. 틀린 생각은 아니에요. 개인적으로 data class가 더 편하다고 생각하여 구성을 하였고, JPA와 호환성을 위해서는 플러그인이나 추가적인 오버라이딩이 필요하죠. 그래서 만약 불변을 강조하거나 간단한 프로젝트 이 강의와 같이 간단한 형태라면, data class가 구현하기에는 더 편하실 겁니다. 하지만 뭔가 복잡한 관계가 주어지는 프로젝트라면 일반적인 class를 추천 드리고 싶어요. 이런 내용도 강의에 녹아 드렸어야 했는데, 너무 제가 제 스타일로만 알려드리고 작성한거 같아서 너무 부끄러워지는 주제였던거 같습니다. 이렇게 정성스럽게 질문 주셔서 너무 감사드립니다.

SSD가 메모리인가요?

안녕하세요 누피님 질문 주셔서 감사합니다.엄밀히 말하면 메모리가 아니라 저장 장치이죠. 아무래도 메모리처럼 빠르게 접근 가능하다는 표현이 좀 혼용이 된거 같습니다. 둘은 다른 역할을 수행합니다. 감사합니다.

Circuit Breaker 질문

안녕하세요 HAHA님 질문 주셔서 감사합니다.말씀해주신것처럼 해당 패턴은 단일 인스턴스에서만 유효한 패턴입니다. 하지만 전체 인스턴스 상황을 가정한다면 중간에 이 값을 저장하고 관리 할 주체를 두면 좋겠죠 보통은 그래서 중앙화된 저장소로 Redis를 사용합니다. 싱글 스레드이기도 하기 떄문에 다중 인스턴스 상황에서 중앙 관리 주체로 사용하기에 용이한 형태가 될 것이고, 영구적으로 보관해야 할 데이터도 아니기 떄문에 캐시 데이터를 사용해도 무방하겠죠. 이렇게 답변 드리면 될꺼 같아요. 감사합니다.

HikariCP maxLifetime 가 db 부하에 주는 영향

안녕하세요 부릉부릉님 질문 주셔서 감사합니다.개인적인 생각으로는 연관이 되어 있을꺼같아요. maxLifeTime이 결국 커넥션이 풀에서 살아 있을 수 있는 최대 시간을 의미하게 되는데, 이 시간이 지나게 된다면, 새로운 커넥션을 만들어서 교체하는 작업이 일어나게 될 겁니다. 현재 상황을 예시로 들어보자면 30초로 설정이 되어 있다니, 풀 안의 모든 커넥션이 30초마다 교체가 되는 것이죠 또한 pod당 50개씩 구성이 되어 있으니 총 커넥션은 250개가 되겠네요. 이 상황에서 250개의 커넥션이 30초 주기마다 대량으로 폐기 되기 떄문에 안정된 커넥션 풀이라기보다는 일종의 팩토리같은 같은 상태가 되는게 아닐까 싶습니다. 커넥션을 재연결하는 과정도 결국 DB에 대한 요청이고, 애플리케이션에서 이 주기에 대해서 잠시 커넥션 부족 상태가 가능할꺼 같아서 결국 풀에 대한 고갈과 같은 현상이 발생할꺼 같다는 생각이 드네요.물론 상황마다 일부 다른 부분은 있겠죠 그래서 30초라는 주기가 pool 고갈의 원인일 될 가능성이 일부 있지 않을까 싶습니다.