일단 제 환경은 윈도우구요 apigateway-service 내의 application.yml 파일의 url를 일반 ip 어드레스가 아닌 loadbalancer 방식으로 변경하여 테스트하면 진행되지 않습니다; 트러블슈팅에 장시간이 걸렸는데 혹시나 해서 제 피씨 네임을 인식하지 못하나 해서 hosts 파일에 본인 pc 네임과 127.0.0.1을 추가해주면 됩니다. 만약 네 pc가 '뽀로로'인 경우 뽀로로 127.0.0.1을 'C:\Windows\System32\drivers\etc'의 파일에 추가해줍니다.
여러 서비스가 Kafka에 메시지를 전달해서 이를 단일 서버에서 저장하는 것은 이해가 갑니다! 그렇다면 조회할 때는 어떤 식으로 흐름이 발생하는건가요? 기존에 어플리케이션이 직접 DB와 커넥션이 되어있는 상태라면 조회문 날리면 그만인데 조회의 경우엔 조회 이벤트가 발생할 때마다 조회 이벤트를 보내면 DB가 카프카에 쿼리를 실행한 결과값을 저장하고, 어플리케이션에서는 또 컨슈머를 만들어서 그값을 가져오는 형태인가요?
안녕하세요, 궁금한 내용이 생겨 기존에 질문들을 살펴보고 제가 이해한 것이 맞는지 확인차 질문드립니다. redis의 싱글스레드 특성으로 100개 발급에 대한 race condition 해결 --> 그러나 insert 시 DB 처리량에 부하가 발생할 수 있음 kafka 미들웨어를 통해 100개의 쿠폰 저장 이벤트를 보관해두었다가 컨슈머에서 원할때 꺼내어 처리할 수 있는 여지를 주어 처리량 부하를 분산시킬 수 있음 ex) 쿠폰 발급은 당장 안해도 되니, kafka에 이벤트만 잘 발행되어 있다면 DB 작업량이 적은 새벽에 꺼내서 저장해도 됨 이렇게 이해했는데, 맞을까요?
안녕하세요, 강의 내용 중 table에 대해서 source를 topic으로 하는 경우 pull 쿼리가 불가능 한 이유에 대해 강사님께서 구체적으로 확인이 되지 않았지만 rocksdb 이슈로 추정된다라고 말씀하신 것 같은데요, 혹시 아래의 이유가 아닐 지 확인 부탁드립니다. https://docs.ksqldb.io/en/latest/concepts/materialized-views/ In ksqlDB, a table can be materialized into a view or not. If a table is created directly on top of a Kafka topic, it's not materialized. Non-materialized tables can't be queried, because they would be highly inefficient. On the other hand, if a table is derived from another collection, ksqlDB materializes its results, and you can make queries against it. document에 따르면 source가 topic인 table의 경우는 mview가 아니라고 하는 것 같습니다. (mview가 아니기 때문에 비효율적이다.) 그렇다면 이 경우는 rocksdb를 통해 stateful한 결과를 저장한 뒤 가져오는 것이 아닌 토픽으로부터 전체 레코드를 읽어와서 compact한 처리를 하는 케이스라고 볼 수 있을 것 같습니다. 즉, source가 topic인 케이스는 오히려 rocksdb를 사용하지 않는 케이스이기 때문에 그런 것이 아닐까 추측이 되는데요 어떻게 생각하시는지 궁금합니다.
안녕하세요, 늘 양질의 강의 제공해 주심에 감사합니다. 강의를 듣다가 알쏭달쏭한 부분이 있어 질문드립니다. Schema Registry 를 활용하여 하위(Backward) 호환성 유지 시, 새로운 스키마를 설정되게 되면 Worker Conenct 를 강제로 실행시켜 줘서 Sink Connector 가 새로운 스키마가 갱신되도록 해줘야하는 절차가 꼭 필요한가요? (Consumer 가 새로운 버전으로 스키마 업데이트가 되도록 강제하기 위한 수동 절차가 꼭 필요한 것인지 궁금합니다. 아님 이러한 부분도 자동으로 Schema registry 에서 Sink 쪽으로 콜백을 주어 캐시된 스키마에 대한 정보 업데이트가 되도록 되는건지,,) (Forward 호환성인 경우) Source Connector 에서 V1 버전 스키마로 메세지를 발행하다가, 어느 순간 신규 스키마 버전 V2 로 메세지를 발행하게 되어 Schema registry 에 V2 가 등록이 된 상태에서, Sink 쪽에서는 이 메세지를 받게 되면 schema id : v2 인 정보를 카프카 메세지 내에 정보를 통해 알게 될텐데, 그럼에도 아직 워커 커넥트 내부 캐시된 스키마 정보엔 v2 가 없더라도, Forward 호환성인 경우에는 Sink Connector(Consumer) 입장에선 Schema registry 를 새로이 호출하여 스키마 업데이트를 하지 않는걸까요 ? 보통 운영환경에서 스키마 관리 자체를 DB source connector 에서 자동으로 만들어주는 스키마가 아니라 Schema registry 에 직접 새로운 스키마를 등록하여 운영환경에서 활용하시는지, 혹은 SOurce connector 의 자동 스키마 완성으로 사용하시는지 궁금 합니다. 양질의 강의에 다시한번 감사드리며 답변 부탁드리겠습니다. 좋은 하루 되세요. 감사합니다.
안녕하세요 선생님 실습에서 multipart-topic으로 key 없이 전송을 했는데 모조리 partition2로 가는데 어떤 설정을 살펴보면 될까요? kafka는 confluent 7.6으로 실습하고 있습니다. key값을 준 경우에는 강의 실습과 동일하게 진행되었습니다.
안녕하세요 KStreamJoinKTable 실행시 에러가 발생해서요 ㅠ 에러는 아래와 같습니다. [order-join-application-517e77af-95a4-4398-9800-1cef92f224d1-StreamThread-1] ERROR org.apache.kafka.streams.KafkaStreams - stream-client [order-join-application-517e77af-95a4-4398-9800-1cef92f224d1] All stream threads have died. The instance will be in error state and should be closed. [order-join-application-517e77af-95a4-4398-9800-1cef92f224d1-StreamThread-1] INFO org.apache.kafka.streams.processor.internals.StreamThread - stream-thread [order-join-application-517e77af-95a4-4398-9800-1cef92f224d1-StreamThread-1] Shutdown complete Exception in thread "order-join-application-517e77af-95a4-4398-9800-1cef92f224d1-StreamThread-1" java.lang.UnsatisfiedLinkError: /private/var/folders/x8/qq1k6wyn1qs76952l1d1t0qh0000gn/T/librocksdbjni11881960449213041495.jnilib: dlopen(/private/var/folders/x8/qq1k6wyn1qs76952l1d1t0qh0000gn/T/librocksdbjni11881960449213041495.jnilib, 0x0001): tried: '/private/var/folders/x8/qq1k6wyn1qs76952l1d1t0qh0000gn/T/librocksdbjni11881960449213041495.jnilib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/x8/qq1k6wyn1qs76952l1d1t0qh0000gn/T/librocksdbjni11881960449213041495.jnilib' (no such file), '/private/var/folders/x8/qq1k6wyn1qs76952l1d1t0qh0000gn/T/librocksdbjni11881960449213041495.jnilib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389) at java.base/java.lang.Runtime.load0(Runtime.java:755) at java.base/java.lang.System.load(System.java:1953) at org.rocksdb.NativeLibraryLoader.loadLibraryFromJar(NativeLibraryLoader.java:78) at org.rocksdb.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:56) at org.rocksdb.RocksDB.loadLibrary(RocksDB.java:64) at org.rocksdb.RocksDB.<clinit>(RocksDB.java:35) at org.rocksdb.DBOptions.<clinit>(DBOptions.java:21) at org.apache.kafka.streams.state.internals.RocksDBStore.openDB(RocksDBStore.java:133) at org.apache.kafka.streams.state.internals.RocksDBStore.init(RocksDBStore.java:229) at org.apache.kafka.streams.state.internals.WrappedStateStore.init(WrappedStateStore.java:48) at org.apache.kafka.streams.state.internals.ChangeLoggingKeyValueBytesStore.init(ChangeLoggingKeyValueBytesStore.java:44) at org.apache.kafka.streams.state.internals.WrappedStateStore.init(WrappedStateStore.java:48) at org.apache.kafka.streams.state.internals.CachingKeyValueStore.init(CachingKeyValueStore.java:58) at org.apache.kafka.streams.state.internals.WrappedStateStore.init(WrappedStateStore.java:48) at org.apache.kafka.streams.state.internals.MeteredKeyValueStore.lambda$init$0(MeteredKeyValueStore.java:101) at org.apache.kafka.streams.processor.internals.metrics.StreamsMetricsImpl.maybeMeasureLatency(StreamsMetricsImpl.java:806) at org.apache.kafka.streams.state.internals.MeteredKeyValueStore.init(MeteredKeyValueStore.java:101) at org.apache.kafka.streams.processor.internals.AbstractTask.registerStateStores(AbstractTask.java:210) at org.apache.kafka.streams.processor.internals.StreamTask.initializeStateStores(StreamTask.java:275) at org.apache.kafka.streams.processor.internals.AssignedTasks.initializeNewTasks(AssignedTasks.java:76) at org.apache.kafka.streams.processor.internals.TaskManager.updateNewAndRestoringTasks(TaskManager.java:397) at org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:779) at org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:697) at org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:670) - 카프카를 공부하시면서 생긴 질문들을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
Microservcie간 통신 강의를 보다가 궁금하게 있어서 질문드립니다. user-service에서 order-service를 요청할때 인증은 필요가 없는건가요? order-service를 요청할때 따로 헤더에 토큰을 담지 않고 요청을 하고 있어서요. order-service를 IP로 지정하지 않고 유레카에 서비스 이름으로 지정해서 요청할때도 gateway를 통해서 요청이 들어 가는것인가요?
찾아보니 비슷한 질문이 있었던 거 같은데 현재 실습환경과 100% 일치하지 않아 도움을 구합니다. 실행환경은 다음과 같습니다 인텔리제이 : Build #IU-241.14494.240, built on March 28, 2024 JDK : 17 스프링부트 : 3.2.4 아시다 시피 최신 인텔리제이에서는 실습환경으로 제시되는 2.X 버전의 스프링부트 지원이 되지 않습니다. POM.XML로 강제로 버전을 내리거나 JDK 버전을 내리는 경우 서비스 기동이 제대로 되지 않습니다. 아마 스프링부트 3 버전에서는 JDK 특정 버전 이상을 강제하는 느낌입니다. 현재 pom.xml 설정은 다음과 같습니다. <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.4</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.example</groupId> <artifactId>user-serivce</artifactId> <version>0.0.1-SNAPSHOT</version> <name>user-serivce</name> <description>user-serivce</description> <properties> <java.version>17</java.version> <spring-cloud.version>2023.0.1</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <excludes> <exclude> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </exclude> </excludes> </configuration> </plugin> </plugins> </build> </project> 명렁어 실행 시 에러는 다음과 같이 발생합니다. [ERROR] Unknown lifecycle phase ".run.jvmArguments=-Dserver.port=9003". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-vers ion>]:<goal>. Available lifecycle phases are: pre-clean, clean, post-clean, validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sou rces, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-site, site, post-site, site-deploy. -> [Help 1] 동일한 명렁어를 윈도우즈 cmd에서 실행하면 다음과 같습니다. [WARNING] Error injecting: org.springframework.boot.maven.RunMojo java.lang.TypeNotPresentException: Type org.springframework.boot.maven.RunMojo not present at org.eclipse.sisu.space .URLClassSpace.loadClass ( URLClassSpace.java:147 ) (중략) Caused by: java.lang.UnsupportedClassVersionError: org/springframework/boot/maven/RunMojo has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0 본 문제 때문에 강의 진행이 안되고 있습니다. 꼭 해결해 주셨으면 합니다.
자동 커밋 옵션을 활성화한 경우 일정 시간마다 오프셋 커밋을 실행하는 것을 이해했습니다. 결제 이벤트를 처리하는 카프카 컨슈머가 100건의 레코드를 가져와서 한번에 처리하도록 구현되어 있을 때 레코드 처리 중간에 장애가 발생하여 오프셋 커밋을 하지 못하는 경우 어떤 일이 일어나는지 궁금합니다. 50번째 레코드를 처리하다가 장애가 발생했다고 가정하면 오프셋 커밋이 되지 못했으므로 다른 컨슈머 애플리케이션이 이미 처리된 100건의 레코드를 다시 가져와서 1~50번째 레코드가 중복으로 이벤트가 처리될 것 같습니다. 이는 컨슈머 애플리케이션은 언제든지 중복으로 레코드를 소비할 수 있다는 것으로 이해가 되고, 컨슈머 애플리케이션 로직을 작성할 때는 항상 중복 레코드가 처리되지 않도록 방어해야한다는 것을 의미한다고 생각합니다. 제가 만약 방어 로직을 작성한다고 하면 레코드의 메시지마다 유일한 키값을 같이 전송하여 해당 값을 Redis에 저장하고, redis에 저장된 상태라면 메시지를 처리하지 않도록 구현할 것 같습니다. 제가 오프셋과 관련하여 이해한 내용이 정확한지, 그리고 실무에서도 Redis를 활용한 중복 처리 방지 로직이 효과적인 방법인지 궁금합니다. 또한, 이와 같은 상황을 해결하기 위해 다른 방법을 사용하시는지도 알고 싶습니다. 답변 주시면 감사하겠습니다!
apigateway의 application.yml을 보면 get요청에는 authorizationHeaderFilter를 적용시키고 있습니다. authenticFilter는 그저 로그인 요청시 attempthAuthentication메소드와 successfulAthentication메소드를 통해 인증을 처리하고 response헤더에 토큰을 추가하는 역할입니다. 따라서 로그인 요청에만 적용하면 될 것 같은데, 깃허브의 최신코드 버전을 보면 거의 모든 요청에 authenticationFilter를 적용하고 있습니다. 왜 로그인요청이 아닌 다른 요청에다가 AthenticFilter를 적용할까요? apiGateway-service에서 GET요청만 AuthoriztionFilter를 적용하면 되지않나요?? http.authorizeHttpRequests((authz) -> authz .requestMatchers(new AntPathRequestMatcher("/actuator/**")).permitAll() .requestMatchers(new AntPathRequestMatcher("/h2-console/**")).permitAll() .requestMatchers(new AntPathRequestMatcher("/users", "POST")).permitAll() .requestMatchers(new AntPathRequestMatcher("/h2-console/**")).permitAll() // .requestMatchers(new AntPathRequestMatcher("/welcome/**")).permitAll() // .requestMatchers("/**").access(this::hasIpAddress) .requestMatchers("/**").access( new WebExpressionAuthorizationManager("hasIpAddress('127.0.0.1') or hasIpAddress('172.30.1.48')")) .anyRequest().authenticated() )
안녕하세요 강의 잘 보고 있습니다. 복제강의 수강중 궁금한점이 리더 - 팔로워 간의 복제시 팔로워에서 리더의 오프셋을 확인해 차이점이 있다면 팔로워로 저장한다고 이해했는데요. 이러한 복제 과정으로 인해 리더파티션에 이슈가 생길만한 케이스가 있는지 궁금합니다. 기본적으로 리더 파티션이 프로듀서 - 컨슈머와의 통신을 담당하기에 팔로워 파티션에서 복제과정을 담당하게 되는 형태인것 같아 문제가 없을것 같긴한데 .. 꼭 이렇게 생각하고 넘어가면 문제가 생기더라구요 ㅎ.. 혹시 복제과정이 리더 파티션 성능에 영향을 주게될만한 이슈가 있을지 우려되서 질문드립니다
