Home

0

JPA - 더티 체킹과 업데이트 그리고 벌크 연산

JPA 에서의 업데이트 - 더티 체킹 Entity 에 대한 더티 체킹 을 통한 업데이트가 이뤄집니다. JPA 에서는 Entity 를 업데이트 하기 위한 메소드가 별도로 존재하지 않습니다. JPA 에서의 업데이트는 엔티티 변경 과 더티 체킹 을 통해 업데이트가 이뤄집니다. JPA 에서 엔티티를 변경하기 위해서는 변경하고자 하는 엔티티를 조회한 후 해당 엔티티의 값을 변경하면 트랜잭션을 커밋할 때 변경 감지(Dirty Checking) 가 동작해서 데이터베이스에 UPDATE SQL 이 실행하는 방식으로 Entity 에 대한 변경을 반영합니다. @Override@Transactionalpublic ItemDto.Response modifyItemPrice(Long id, ItemDto.Request itemDto) { // 1. 변경하고자 하는 Entity 를 조회합니다. Optional<Item> optionalItem = itemRepository.findById(id); if (optionalItem.isPresent()) { Item item = optionalItem.get(); // 2. Entity 의 값을 변경합니다. item.updatePrice(itemDto.getPrice()); return ItemDto.Response.toDto(item); } else { throw new RuntimeException("Item not found"); }} Update 쿼리문 발생update item set item_type_id=?, modified_date=?, name=?, price=?, version=? where id=? and version=? 더티체크를 통한 업데이트의 한계더티 체킹을 통한 업데이트는 변경된 Entity 개수만큼 Update 문을 실행합니다. 그렇기 때문에 변경된 Entity 가 100개라면 100번의 Update 문이 실행되는 문제점이 있습니다.

0

Service Discovery 패턴

참고 https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ https://velog.io/@hoonki/마이크로서비스-패턴-서비스-디스커버리 Service Discovery 패턴이 등장하게 된 배경기존 서비스 인스턴스의 개수와 IP 가 고정적이였던 온 프레미스 환경과 달리 MSA 환경에서는 Application 들이 AutoScaling 을 하면서 동적으로 줄었다가 늘어나면서 IP 자체도 동적으로 바뀌게 됐습니다. Client 나 Gateway 입장에서 서비스 인스턴스들이 동적으로 늘었는지 줄었는지에 대한 파악을 하기가 어려운 문제가 있었고 그에 따른 LoadBalancing 하는데 어려움이 있었습니다. Service Discovery 패턴에서는 Service EndPoint 를 조회 및 관리하기 위한 Service Registry 가 있습니다. MSA 의 각 서비스들은 Service Registry 에 자신의 EndPoint 들을 등록합니다. Service EndPoint 를 접근하는 방식에 따라 두가지로 나뉘게 됩니다. 첫번째는 Client-Side Discovery 두번째는 Server-Side Discovery 패턴이 있습니다. 출처: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ Client Side DiscoveryMSA 내 한 서비스가 다른 서비스를 호출할때 Service Registry 로 부터 EndPoint 를 조회한 후 해당 서비스를 호출하는 방식입니다.

0

Spring Cloud - Eureka 에 Service 등록하기

목차 Spring Cloud - Eureka 에 Service 등록하기 Spring Cloud - Service Discovery Server (Eureka) 참고 https://cloud.spring.io/spring-cloud-netflix/reference/html/ https://coe.gitbook.io/guide/service-discovery/eureka Service 등록하기implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' @EnableDiscoveryClient@SpringBootApplication@EnableDiscoveryClientpublic class UserServiceApplication { public static void main(String[] args){ SpringApplication.run(UserServiceApplication.class, args); }} Eureka 서버에 등록을 위한 Properties 설정 추가eureka.client.register-with-eureka 값을 true 로 줌으로써 Eureka 서버에 등록하도록 설정합니다.

0

Spring Cloud - Service Discovery Server (Eureka)

목차 Spring Cloud - Eureka 에 Service 등록하기 Spring Cloud - Service Discovery Server (Eureka) 참고 https://cloud.spring.io/spring-cloud-netflix/reference/html/ https://coe.gitbook.io/guide/service-discovery/eureka 사용하는 Spring Cloud 버전plugins { id 'org.springframework.boot' version '2.4.5' id 'io.spring.dependency-management' version '1.0.11.RELEASE' id 'java'}group = 'com.example'version = '0.0.1-SNAPSHOT'sourceCompatibility = '11'repositories { mavenCentral()}ext { set('springCloudVersion', "2020.0.2")}dependencies { testImplementation 'org.springframework.boot:spring-boot-starter-test'}dependencyManagement { imports { mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}" }}test { useJUnitPlatform()} Spring Cloud EurekaMSA (Micro Service Architecture) 에서는 각 서비스를 관리하기 위해서 Service Discovery Server 가 필요합니다. Spring Cloud 에서는 Service Discovery 를 위해 Eureka 를 사용한다. Discovery Server (Eureka)implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'

0

Spring Batch - 배치 설정 (application.properties)

배치 잡의 실행 여부를 설정# Spring Boot 가 자동으로 실행시키는 Batch Job 을 실행시키도록 한다.spring.batch.job.enabled: true # default# Spring Boot 가 자동으로 실행시키는 Batch Job 을 실행하지 않도록 한다.spring.batch.job.enabled: false 배치 잡의 재시작 여부를 설정# 기본이 true, 재시작을 허용한다.spring.batch.job.restartable: true# 재시작을 허용하지 않는다spring.batch.job.restartable: false 실행할 배치 잡의 이름을 지정스프링 배치는 실행시 기본적으로 모든 Job 을 실행시킵니다. spring.batch.job.names 를 이용해 지정 Job 만 실행하도록 설정할 수 있습니다. 프로그램 실행시 특정 Job 을 전달받아 실행시키고 싶을 경우 spring.batch.job.names: ${job.name:NONE} 로 설정하면 외부에서 주입받은 Job 이름을 이용해 실행시킬 수 있습니다. 만일 전달받은 값이 없으면 아무 Job 도 실행시키지 않습니다. :NONE 은 프로퍼티 표현 중 하나로 전달받은 값이 없을 경우 NONE 으로 대체한다는 의미이다. # Hard Coding 방식spring.batch.job.names: springJob1# Binding 을 사용한 방식spring.batch.job.names: ${job.name:NONE}

0

쿠버네티스 - ServiceAccount

목차 쿠버네티스 - Secret 쿠버네티스 - ConfigMap 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod 쿠버네티스 - Data Plane 쿠버네티스 - Control Plane Post not found: k8s/k8s 참고 https://findstar.pe.kr/2023/04/09/access-k8s-api-from-pod/ https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/ ServiceAccount ServiceAccount 는 쿠버네티스 API 서버와 통신하고 클러스터 내의 다른 리소스에 접근하기 위한 인증 정보를 제공합니다. ServiceAccount 는 Pod 가 Kubernetes API Server 에 인증 하기 위한 Account 입니다. 때문에 Pod 를 생성할때 ServiceAccount 를 할당해야 하며 지정하지 않을 경우 default 가 자동으로 할당됩니다. Rule 과 RuleBinding 을 이용해 ServiceAccount 에 권한을 부여함으로써 Pod 가 다른 리소스에 접근할 수 있게 해줍니다. ServiceAccount 는 Namespace 단위로 생성되는 리소스며 다른 Namespace 에서 정의된 ServiceAccount 를 사용할 수 없습니다.

0

Istio - istioctl2

목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - istioctl Istio 란? 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ istioctl 설치Mac 을 사용하는 경우 HomeBrew 를 이용해 istioctl 을 설치할 수 있습니다. brew install istioctl 다른 OS 를 사용하거나 특정 버전의 Istio 를 사용하고 싶은 경우 다음과 같이 Istio 버전을 Setting 한 후 해당 버전을 내려받아 사용할 수 있습니다. export ISTIO_VERSION=1.14.5curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIO_VERSION TARGET_ARCH=x86_64 sh -

0

쿠버네티스 - CustomResource

참고 https://frozenpond.tistory.com/111 CustomResourceCustom Resource는 쿠버네티스에서 사용자가 정의한 리소스를 나타냅니다. 이는 일반적으로 클러스터 내에 존재하지 않는 기본 리소스의 새로운 종류를 정의하고, 이를 통해 사용자의 애플리케이션에 특화된 동작을 수행할 수 있도록 합니다. Custom Resource 는 클러스터 상태의 일부로서 존재하며, 일반적인 리소스와 동일한 방식으로 쿠버네티스 API를 통해 작동합니다. 예를 들어, 사용자는 Custom Resource 를 생성, 조회, 수정 및 삭제할 수 있습니다. Custom Resource 를 사용하기 위해 먼저 Custom Resource Definition(CRD) 을 정의해야 합니다. CRD는 Custom Resource 의 스키마를 설명하는 쿠버네티스 API 개체입니다. 이를 통해 Custom Resource 의 구조, 필드 및 기타 특성을 정의할 수 있습니다. CRD는 일종의 템플릿으로서, Custom Resource 의 정의를 기반으로 생성됩니다. CRD를 생성하면 쿠버네티스 API 서버가 새로운 Custom Resource 타입을 이해하고 처리할 수 있게 됩니다. Custom Resource Definition 을 작성한 후, 사용자는 해당 정의를 사용하여 Custom Resource 인스턴스를 생성하고 관리할 수 있습니다. Custom Resource 인스턴스는 일반적으로 YAML 또는 JSON 형식으로 정의되며, 클러스터에 배포됩니다. 이후 Custom Resource 는 클러스터 내에서 다른 리소스와 유사하게 다룰 수 있으며, 사용자는 쿠버네티스 API를 사용하여 Custom Resource 를 조작할 수 있습니다. Custom Resource 와 Custom Resource Definition 은 쿠버네티스의 확장성과 유연성을 높여줍니다. 사용자는 쿠버네티스 API를 통해 고유한 리소스 유형을 정의하고 제어할 수 있으며, 이를 통해 자신의 애플리케이션을 더욱 쉽게 관리할 수 있습니다.

0

쿠버네티스 - CA (Cluster Autoscaler)

목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s CA

0

쿠버네티스 - VPA (Vertical Pod Autoscaler)

목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s VPA