'섹션 2. 데이터 주고받기, Spring Boot API 서버 만들기' - '10. Postman으로 API 테스트하기' 질문 입니다. 오타로 @PostMapping과 @GetMapping의 URL이 불일치해서 포스트맨에서 제대로된 값이 안나왔더라고요. 이럴 경우 오류도 안떠서 해결하기가 힘든데, URL 오타를 방지하는 방법이 있을까요?
안녕하세요. 의욕적으로 배우고 있는 학생입니다. 클로드코드를 커서에서 확장프로그램은 잘 실행이 되는데, cli방식으로만 하면 실행되지 않고 있습니다. 커서 터미널에서 claude를 실행하여 클로드코드가 작동하면 드래그하여 위치를 상단으로 바꾸면 검정색 화면으로 바뀝니다. 해결할 수 있는 방법이 있을까요?
해답에 (A)가 오답인 이유가 Glacier 유형은 법/감사/규정 목적으로 장기 보관해야 되는 경우에만 사용하기 때문이라고 해설이 되어 있는데 문제에는 회사의 보안 규정에 스토리지 전략을 따르는 것으로 주어져 있습니다. 문제에서의 회사의 보안 규정이 법/감사/규정에 포함되지 않는건가요?
안녕하세요~ 현재 아래 기술 스택을 사용한 API 서버가 존재합니다. Spring Boot 3 Kotlin JPA(JDBC) WebClient 예를 들면 아래와 같이 구성되어 있고, @RestController class SampleController( private val service: SampleService ) { @GetMapping("/sample") suspend fun start() { service.withoutDispatchers() } } @Component class SampleClient { private val webClient: WebClient by lazy { WebClient.builder() .baseUrl("https://api.com") .build() } suspend fun fetch(): Int { return webClient.get() .uri { uriBuilder -> uriBuilder.path("/number").build() } .retrieve() .awaitBody() } } interface SampleRepository : JpaRepository<SampleEntity, Long> @Service class SampleService( private val client: SampleClient, private val repository: SampleRepository, ) { suspend fun withoutDispatchers(): Int = coroutineScope { // non-blocking val deferred: Deferred<Int> = async { client.fetch() } // blocking val entity: List<SampleEntity> = repository.findAll() deferred.await() + entity.size } } Controller에서부터 suspend function으로 시작되면 Dispatchers.Unconfined를 사용하여 API 요청에 의해 할당받은 Tomcat 스레드를 그대로 사용하는 것으로 알고 있습니다. 이후 Service 레이어에서 suspend function이 동일하게 Dispatchers.Unconfined를 유지하기 때문에 요청 시 Tomcat 스레드는 그대로 사용되고 WebClient 요청 시 Dispatchers.IO를 사용하면, Tomcat 스레드와 별개로 Dispatchers 스레드 풀에서 스레드를 가져와 사용하는 것으로 알고 있습니다. 1번의 요청에서 Tomcat 스레드 1개 + Dispatchers 스레드 1개 = 총 2개가 사용됩니다. WebClient 요청 시 Dispatchers.IO를 생략하고 Dispatchers.Unconfined를 유지하면 , 코루틴의 재개 시 WebClient 응답을 동일한 Tomcat 스레드가 처리하게 하여 스레드 1개만을 사용하는 것이 서버에 더 효율적이지 않을까? 하는 생각이 들었습니다. 스레드가 Blocking되어도 WebClient의 NIO 이벤트 루프에 들어온 요청은 처리되어 응답에 대한 처리만 대기하고 있을 것이고, 테스트해보았을 때도 WebClient의 요청을 시작한 스레드가 JPARepository를 사용하는 코드에 의해 Blocking되어도 await()에서 문제 없이 응답을 받아올 수 있었습니다. 혹시 제가 생각하지 못한 또 다른 문제가 있을까요? 제가 혹시 잘못 알고 있는 부분이 있거나 Dispatchers.IO를 생략하지 못 하는 이유가 있다면 설명해주시면 감사하겠습니다!
몇번을 다시 설치 해도 강사님과 버전을 맞춰 다시 해봐도 없어지질 않네요. 다른분들 혹시 지금 설치하시는 분들 괜찮으신지요? 하나 틀린건 전 우분투 24.04.3 라이브 서버에 직접 설치하는것 입니다. 서버만 계속 지웠다 이것저것 해보는데 안되네요..ㅜ,ㅜ 지금 마지막으로 서버 버전도 22.04.05 버전으로 다시 설치해보려 합니다.ㅎ
1. 현재 학습 진도 redis 2. 어려움을 겪는 부분 간단하게 제 프로젝트를 소개하자면 RSS피드를 통해 블로그의 글들을 불러와서 하나의 게시판에서 볼 수 있는 서비스 입니다. 스케쥴러 작업에서 구독한 피드의 새로운 글들을 불러옵니다. 피드마다 비동기로 병렬 처리됩니다. 이때 새로운 글인지 아닌지를 판단할 때 피드마다 redis를 사용하거나 피드마다 db의 조회를 통해 차이를 확인했는데 redis를 사용했을 때 빨라질 것이라 생각했지만 빠르지 않았습니다. 3. 시도해보신 내용 앞선 강의를 토대로 쿼리발생 횟수를 모니터링 횟수로 측정한 결과 피드가 100개일 경우 db의 조회를 활용했을 때 비동기 병렬 처리 되므로 100개의 select문이 나갑니다. redis를 사용했을 때는 0개의 select문으로 감소합니다. 하지만 성능은 비슷합니다. 예상 가는 이유로는 redis를 사용했을 때 그 횟수가 너무 잦아서 redis에 연결하는 네트워크 시간 때문에 차이가 미미하다는 말이 있던 것 같습니다. 만약 제 가설이 맞다고 한다면 redis를 사용할 때 항상 네트워크의 횟수를 최소화 해야만 redis의 성능을 온전히 이끌어 낼 수 있는건가요? 보통 레디스를 사용할 때 이걸 다 생각하면서 1번만 redis가 조회 되도록 하고 생각하면서 쓰나요? 그렇다면 제 코드에서 redis의 성능을 올바르게 나타내려면 피드의 새로운 글들을 하나의 List로 전부 묶은 후 redis에서 한번의 연결을 통해 한번에 캐싱을 확인해서 성능을 높여야 하는건가요?
1. 현재 학습 진도 부하테스트 2. 어려움을 겪는 부분 부하 테스트의 코드를 통해 성능 개선 사례를 적으려고 합니다. 하지만 현재 평균 req_duration 즉 레이턴시가 너무 낮게 나옵니다. vus를 300으로 두었는데 아마 커넥션 풀이 모자라서 대기가 길어지는게 원인 같긴 합니다. 하지만 이걸 떠나서도 vus 300치고 너무 느리다고 판단되어서 이걸 개선했다고 포트폴리오에 쓰는게 의미가 있을지 걱정됩니다. 또한 커넥션 풀이 모자라다고 대기업 개발자들이 항상 aws의 사양을 up시켜 커넥션 풀만 늘려서 해결하는 해결 방식을 사용하지는 않을 것 같은데 보통 성능 최적화를 통해 커넥션풀 점유를 짧게 해서 최대한 커넥션풀 고갈을 방지하는 방식으로 해결하나요? 만약 그렇다면 성능 최적화 하는 방법에 부하를 분산하기 위한 kafka, redis, msa같은 기술들이 들어가는 건가요? 마지막으로 성능 최적화를 포트폴리오 이력에 쓸 때 적절한 vus수가 궁금합니다 예를들어 면접관이 봤을 때 300명이라면 너무 적다고 판단되지 않을까 걱정되어서 어느 정도의 대략적으로 vus가 적정 인원인지가 궁금합니다, 3. 시도해보신 내용 시도하진 않았지만 개선할 방법으로는 강의에서 제공해주신 mysql의 실행계획을 통해 index 추가와 커넥션풀 사이즈 늘리는 것 그리고 캐싱 도입을 생각하고 있긴합니다.