하이버네이트는 내부적으로 두종류의 캐쉬를 지원하는데 하나는 First-level cache 이고 다른 한종류는 Second-level Cache 이다

First-level cache?

대부분의 ORM (Object Relational Mapping) 프레임워크가 지원하는것처럼 하이버네이트또한 일차적 캐쉬를 지원한다. 

일차캐쉬는 Hibernate 의 Session 단계에서 지원하는 캐쉬로 가장 비싼 연산작업중 하나인 데이터베이스와의 대화를 줄여주기 위해 존재한다. Session 안에서 동작하는 캐쉬이기 때문에 Session 이 종료되면 캐쉬도 같이 사라지게 된다.

Second-level cache?

First level cache 이 세션 단계에서의 캐쉬라면 second level cache 는 session factory 단계에서 지원하는 캐쉬로 session factory 에서 생성되는 session 간에 공유가 된다. 

표로 다시 정리하면

동시성 캐쉬 전략

Entity 에 대해 캐쉬 사용할때 샘플코드

@Entity(name = "Company")
@Cacheable
@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public static class Company {

}

참조: 

1. https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#caching

JPA를 사용해서 엔티티간의 관계를 설정할때 아래와 어노테이션을 작성하는 일이 많은데 어떤 의미를 가지고 있는지 알아보자

@OneToMany(cascade={CascadeType.REFRESH, CascadeType.MERGE}, fetch = FetchType.LAZY)

먼저 각각의 CaseType에 들어가기전에 영속성 컨텍스트와 JPA의 상태에 대한 선행지식이 필요하다

Persistence Conxtet (영속성 컨텍스트)

공식문서의 정의를 참조해보자 

A persistence context is a set of entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed. The 
EntityManager
 API is used to create and remove persistent entity instances, to find entities by their primary key, and to query over entities.

어렵게 정의되어 있지만 간단하게 요약하자면 영속성 컨텍스트가 영속성 컨텍스트안에 있는 엔티티들의 변화를 추적하고 관리한다는 이야기다.

엔티티 객체의 상태

JPA의 동작들

Cascade 종류

JPA 표준에 사용하면 아래와 같이 6가지 Cascade Type 있다

하이버네이트에만 존재하는 CaseCade Type

참조:

1. https://docs.jboss.org/hibernate/orm/5.6/userguide/html_single/Hibernate_User_Guide.html

2. https://stackoverflow.com/questions/161224/what-are-the-differences-between-the-different-saving-methods-in-hibernate

어플리케이션을 구동하기 위해 사용되는 설정값들을 어플리케이션이 돌아가는 플랫폼안에서 보통 환경변수 혹은 파일안에 저장해두고 쓰는데 어플리케이션 설정값을 Zookeepr, AWS Secrets 과 같은 외부 서비스에서 불러들이거나 보안을 위해 설정값들을 메모리 안에서만 저장이 필요한 경우에 활용 가능한 방법이다.

Spring boot 에서 만 활용 가능한 방법

EnvironmentPostProcessor 를 활용

public class PriceCalculationEnvironmentPostProcessor implements EnvironmentPostProcessor {

    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, 
      SpringApplication application) {
        PropertySource<?> system = environment.getPropertySources()
          .get(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME);

        Map<String, Object> prefixed = names.stream()
          .collect(Collectors.toMap(this::rename, system::getProperty));
        environment.getPropertySources()
          .addAfter(SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME, new MapPropertySource("prefixer", prefixed));
    }

}

Spring boot 와 Spring boot를 사용하지 않는 환경에서 활용 가능한 방법

ApplicationContextInitializer 를 활용한 방법

먼저 아래와 같이 프로퍼티 값을 오버라이드 하는 코드를 작성해준다.

public class PropertyOverrideContextInitializer
  implements ApplicationContextInitializer<ConfigurableApplicationContext> {
    @Override
    public void initialize(ConfigurableWebApplicationContext applicationContext) {
        ConfigurableEnvironment environment = applicationContext.getEnvironment();
        MyConfigProps configProps = Binder.get(environment).bind("my-config", MyConfigProps);
        System.out.println(configProps.getHomekey());
    }
  }

여기서 네가지 방법으로 어플리케이션에 적용 가능하다

1. web.xml 안에 있는 contextInitializerClasses 에 추가 혹은 상응하는 Java Config (Spring MVC)

    <context-param>
        <param-name>contextInitializerClasses</param-name>
        <param-value>com.xxxx.PropertyOverrideContextInitializer</param-value>
    </context-param>

자바로 설정시에 

@ContextConfiguration(initializers = PropertyOverrideContextInitializer.class)
public class AppConfig {

}

스프링만 사용시 

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
MyAppContextInitializer initializer = new MyAppContextInitializer();
initializer.initialize( ctx );

ctx.register( com.my.classpath.StackOverflowConfiguration.class );
ctx.refresh()

JobLauncher launcher = context.getBean(JobLauncher.class);

2. META-INF/spring.factories 추가하여 자동 설정 추가 (Spring Boot) 

org.springframework.context.ApplicationContextInitializer=
org.springframework.boot.context.PropertyOverrideContextInitializer

3. 어플리케이션 추가 실행코드에 추가코드에 추가하는 방법 (Spring boot)

application.addInitializers(PropertyOverrideContextInitializer.class);
application.run(args);

혹은

new SpringApplicationBuilder(YourApp.class)
    .initializers(PropertyOverrideContextInitializer.class);
    .run(args);

4. context.initializer.classes 프라퍼티 설정 (Spring boot)

context.initializer.classes=com.xxxx.PropertyOverrideContextInitializer

참조

1. https://www.baeldung.com/spring-tests-override-properties
2. https://stackoverflow.com/questions/35217354/how-to-add-custom-applicationcontextinitializer-to-a-spring-boot-application
3. https://stackoverflow.com/questions/35048164/spring-applicationcontextinitializer-and-properties
4. https://stackoverflow.com/questions/13288841/applicationcontextinitializer-in-a-non-web-spring-context

Kubernetes 개발 환경을 위한 Garden IO 소개

배경

최근 많은 기업들이 운영 환경을 Kubernetes로 이전하면서 개발자들은 새로운 과제에 직면하게 되었습니다. 특히 로컬 개발 환경에서 마이크로서비스 아키텍처를 효율적으로 개발하고 테스트하는 것이 주요 과제 중 하나입니다. 기존에는 Docker Compose를 통해 이러한 환경을 쉽게 구성할 수 있었지만, Kubernetes 환경으로 전환하면서 새로운 도구가 필요하게 되었습니다.

이러한 상황에서 Garden IO가 주목받고 있습니다. Garden IO는 Kubernetes와 클라우드를 위한 엔드투엔드 개발 및 테스트 플랫폼으로, 개발부터 테스트, CI까지 일관된 워크플로우를 제공합니다.

Garden IO란?

Garden IO는 다음과 같은 특징을 가진 개발 도구입니다:

1. Kubernetes 네이티브 개발 환경 지원
2. 서비스 간 의존성 관리
3. 환경별 설정 템플릿 제공
4. 빠른 피드백 루프 제공
5. 통합 테스트 환경 지원

주요 기능

1. 서비스 의존성 관리

Garden IO의 가장 강력한 기능 중 하나는 서비스 간 의존성을 자동으로 관리해준다는 점입니다. 예를 들어:

• 서비스 A가 서비스 B에 의존할 경우, Garden은 자동으로 B를 먼저 배포한 후 A를 배포합니다.
• 의존성 그래프를 자동으로 생성하여 복잡한 마이크로서비스 아키텍처도 효율적으로 관리할 수 있습니다.

2. 설정 템플릿 기능

Docker Compose 사용자들이 익숙해 있는 환경 변수 관리와 설정 커스터마이징을 Garden IO에서도 동일하게 사용할 수 있습니다:

• 환경별(개발, 스테이징, 운영) 설정 분리
• 변수 치환 및 템플릿 기능
• 설정 재사용성 극대화

설치 및 설정 방법

설치하기

Garden IO는 다양한 운영체제에서 쉽게 설치할 수 있습니다:

MacOS:

brew tap garden-io/garden
brew install garden-cli

Linux:

curl -sL https://get.garden.io/install.sh | bash

Windows:

choco install garden-cli

프록시 설정

방화벽 뒤에서 Garden을 실행할 경우, 프록시 설정이 필요할 수 있습니다:

export HTTP_PROXY="http://proxy.example.com:8080"
export HTTPS_PROXY="http://proxy.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.example.com"

프로젝트 구성 예시

Garden IO 프로젝트는 garden.yml 파일을 통해 구성됩니다. 아래는 간단한 예시입니다:

kind: Project
name: my-project
environments:
  - name: local
    providers:
      - name: kubernetes
        context: docker-desktop

---
kind: Module
name: backend-service
type: container
services:
  - name: backend
    ports:
      - name: http
        containerPort: 8080
dependencies:
  - database-service

---
kind: Module
name: database-service
type: container
services:
  - name: database
    ports:
      - name: postgres
        containerPort: 5432

장점과 실제 사용 경험

Garden IO를 실제 개발 환경에 도입하면서 경험한 주요 장점들은 다음과 같습니다:

1. 개발 환경의 일관성: 모든 개발자가 동일한 환경에서 작업할 수 있습니다.
2. 빠른 피드백: 변경사항을 즉시 확인할 수 있어 개발 생산성이 향상됩니다.
3. 쿠버네티스 친화적: 운영 환경과 유사한 환경에서 개발할 수 있습니다.
4. 자동화된 의존성 관리: 복잡한 마이크로서비스 아키텍처도 효율적으로 관리할 수 있습니다.

결론

Garden IO는 Kubernetes 기반의 개발 환경에서 Docker Compose의 편리함을 그대로 가져오면서, 추가적인 기능들을 제공합니다. 특히 마이크로서비스 아키텍처를 개발할 때 서비스 간 의존성 관리와 환경 설정의 유연성을 제공하여 개발자의 생산성을 크게 향상시킬 수 있습니다.

향후 Kubernetes가 더욱 보편화되면서, Garden IO와 같은 도구의 중요성은 더욱 커질 것으로 예상됩니다. 특히 개발 환경과 운영 환경의 간극을 줄이고, 효율적인 개발 워크플로우를 구축하고자 하는 팀에게 훌륭한 선택이 될 것입니다.

사용자가 많아지고 트래픽이 많아질고 시스템 스케일링이 필요해지는 시점이 오면 데이터베이스 캐싱에 대한 고민을 하게된다.

이번 포스팅에서는 데이터베이스 캐싱 전략에 대해 알아보고자 한다

먼저 들어가기에 앞서 Cache Hit을 알아보자

Cache hit 이란?

찾으려는 데이터가 캐쉬에 저장되어 있어 데이터베이스를 거치지 하고 캐쉬에서 바로 데이터를 가져오는 형태.

Cache hit이 많이 발생할수록 데이터 베이스에 대한 부담이 줄어든다.

Cache-Asdie

일반 적인 형태의 캐쉬로 어플리케이션이 캐쉬업데이트 업데이트 담당.

캐쉬에 먼저 쿼리문을 보내고 캐쉬에 데이터가 없을시 데이터베이스에서 데이터를 가져온후 캐쉬에 데이터를 업데이트 한다

장점: 

1. 데이터베이스 데이터 모델과 캐쉬의 데이터 모델이 다르게 저장 가능

2. 캐쉬 서버가 다운되도 데이터베이스에서 데이터를 가져올수있다.

3. Lazy Loading 

단점:

1. 데이터와 캐쉬간의 데이터 불일치 발생 가능성. (Time to live 값을 설정하거나 캐쉬를 무효화하는 전략 수립 필요)

2. 어플리케이션이 캐쉬관리 담당

Read-Through (동기적 처리)

캐쉬에 데이터가 없으면 원본 데이터 소스에 접근해서 데이터를 가져오고 캐쉬에 저장

장점:

1. Lazy Loading 

2. 어플리케이션이 캐쉬를 관리하지 않음

단점:

1. 최초로 데이터를 요청한 사람의 응답속도가 느림.

Write-Through (동기적 처리)

캐쉬가 데이터베이스와 어플리케이션 사이에 위치하고 있고 캐쉬에 데이터를 저장하고 데이터베이스 이어서 바로 저장.

Read through 전략과 같이 이용되면 Cache Hit 확률을 높일수 있다.

장점:

1. Write-Behind 보다 데이터 유실 위험 적음

단점

1. 캐쉬와 데이터베이스에 동시에 저장하기때문에 느린 쓰기 속도

Write-Behind (비동기적 처리)

캐쉬에만 데데이터를 저장하고,  데이터 소스에는 별도의로 주기적으로 저장하는 방식

장점: 

1. Write-Through 보다 향상된 쓰기 속도

2. 데이터베이스에 대한 부담을 줄일

단점

1. Cache 가 다운되면 데이터 유실 위험