지잉지잉 개발일기

[OpenSearch] Spring - Kotlin 기반의 OpenSearch Client 구현

지잉지잉 — Fri, 3 Nov 2023 23:13:14 +0900

1. 개요

ElasticSearch 에 비해 AWS OpenSearch는 JAVA API Client 문서가 불친절한 느낌이다.
이것 저것 해보면서 겪었던 시행 착오들을 기록하고,
SpringBoot - Kotlin 기반으로 AWS OpenSearch Instance에 접근하고 색인/검색 요청을 하는 JAVA API Client 설정 및 구현 방법을 정리한다.

2. Dependency

dependencies {
	...
	implementation("org.opensearch.client:opensearch-rest-client:2.11.0")
	implementation("org.opensearch.client:opensearch-java:2.7.0")
	implementation("jakarta.json:jakarta.json-api:2.0.1")
    	...
 }

jakarta.json-api 의존성을 추가해주지 않으면,
- java.lang.NoClassDefFoundError: jakarta/json/JsonException 에러가 난다.
- = ES에서 가져온 JSON 기반의 객체를 파싱하는데 실패하는 것 같다.

3. OpenSearchClient

import com.fasterxml.jackson.module.kotlin.jacksonObjectMapper
import org.apache.http.HttpHost
import org.apache.http.auth.AuthScope
import org.apache.http.auth.UsernamePasswordCredentials
import org.apache.http.impl.client.BasicCredentialsProvider
import org.opensearch.client.RestClient
import org.opensearch.client.json.jackson.JacksonJsonpMapper
import org.opensearch.client.opensearch.OpenSearchClient
import org.opensearch.client.transport.rest_client.RestClientTransport
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration
class OpenSearchConfiguration {

    @Bean
    fun openSearchClient(): OpenSearchClient {
        val host = HttpHost("127.0.0.1", 9200, "https") // OpenSearch Domain
        val credential = BasicCredentialsProvider().apply {
            this.setCredentials(
                AuthScope(host),
                UsernamePasswordCredentials("admin", "admin") // OpenSearch Username & Password
            )
        }

        val restClient = RestClient.builder(host).setHttpClientConfigCallback {
            it.setDefaultCredentialsProvider(credential)
        }.build()

        return OpenSearchClient(RestClientTransport(restClient, JacksonJsonpMapper(jacksonObjectMapper())))
    }
}

Webflux를 사용한다면 OpenSearchAsyncClient로 생성하여 비동기로 OpenSearch 호출이 가능하다.
JacksonJsonpMapper도 jacksonObjectMapper로 만들어주자. (안하면 parsing Exception 발생)

4. Service Example

import org.opensearch.client.opensearch.OpenSearchClient
import org.opensearch.client.opensearch.core.BulkRequest
import org.opensearch.client.opensearch.core.SearchRequest
import org.opensearch.client.opensearch.core.bulk.CreateOperation
import org.opensearch.client.opensearch.indices.CreateIndexRequest
import org.springframework.stereotype.Service

@Service
class OpenSearchService(
    private val openSearchClient: OpenSearchClient
) {

    /**
     * 인덱스 생성
      */
    fun createIndex() {
        try {
            val indexName = "test-index"

            val request = CreateIndexRequest.of {
                it.index(indexName)
            }

            openSearchClient.indices().create(request)
        } catch (e: Exception) {
            e.printStackTrace()
        }
    }

    /**
     * bulk index(색인)
     */
    fun bulk() {
        val indexName = "test-index"
        val dummyData = listOf(
            TestIndex(
                id = "test1",
                name = "test1",
                age = 20
            ),
            TestIndex(
                id = "test2",
                name = "test2",
                age = 30
            )
        )
        try {
            val bulkRequest = BulkRequest.Builder()

            dummyData.forEach {  testIndex ->
                bulkRequest.operations { operation ->
                    operation.create { co: CreateOperation.Builder<TestIndex> ->
                        co.index(indexName).id(testIndex.id).document(testIndex)
                    }
                }
            }

            openSearchClient.bulk(bulkRequest.build())
        } catch (e: Exception) {
            e.printStackTrace()
        }
    }

    /**
     * 검색
     */
    fun search(keyword: String): List<TestIndex> {
        val indexName = "test-index"
        return try {
            val request = SearchRequest.of { searchRequest ->
                searchRequest.index(indexName)
                searchRequest.query { query ->
                    query.match { matchQuery ->
                        matchQuery.field("name")
                        matchQuery.query {
                            it.stringValue(keyword)
                        }
                    }
                }
            }

            openSearchClient.search(request, TestIndex::class.java).hits().hits().mapNotNull {
                it.source()
            }
        } catch (e: Exception) {
            e.printStackTrace()
            emptyList()
        }
    }

    data class TestIndex(
        val id: String,
        val name: String,
        val age: Int,
    )
}

인덱스 생성, 색인, 검색 예제
간단하게 request 객체를 만들어 요청할 수 있다.

[Spring] RestDocs로 API 문서화를 간단히 해보자

지잉지잉 — Sun, 18 Jun 2023 21:58:35 +0900

1. build.gradle.kts 설정

추가해야 할 부분만 표시해놓았습니다~

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
   ...
   id("com.epages.restdocs-api-spec") version "0.16.0"
   ...
}

group = "com.test"
version = "0.0.1-SNAPSHOT"

java {
   sourceCompatibility = JavaVersion.VERSION_17
}

repositories {
   mavenCentral()
}

dependencies {
   ...
   testImplementation("com.epages:restdocs-api-spec-mockmvc:0.16.2")
}

openapi3 {
   this.setServer("https://localhost:8080") 
   title = "openapi3 test"
   description = "테스트 입니당"
   version = "0.1.0"
   format = "yaml" // or json
}

2. API 작성

간단한 테스트용 API를 작성한다.

@RestController
class TestController {

    @GetMapping("/test")
    fun getTest(@RequestParam name: String, @RequestParam age: Int) = ResponseEntity<TestResponse>(
        TestResponse(
            200, "Hello $name ($age)."
        ),
        HttpStatus.OK
    )
}

3. Test Code 작성

import com.epages.restdocs.apispec.MockMvcRestDocumentationWrapper
import com.epages.restdocs.apispec.ResourceDocumentation.parameterWithName
import com.epages.restdocs.apispec.ResourceSnippetParametersBuilder
import com.epages.restdocs.apispec.SimpleType
import org.junit.jupiter.api.BeforeEach

import org.junit.jupiter.api.Test
import org.junit.jupiter.api.extension.ExtendWith
import org.springframework.boot.test.context.SpringBootTest
import org.springframework.restdocs.RestDocumentationContextProvider
import org.springframework.restdocs.RestDocumentationExtension
import org.springframework.restdocs.mockmvc.MockMvcRestDocumentation
import org.springframework.restdocs.mockmvc.RestDocumentationRequestBuilders.get
import org.springframework.restdocs.payload.JsonFieldType
import org.springframework.restdocs.payload.PayloadDocumentation.fieldWithPath
import org.springframework.test.context.junit.jupiter.SpringExtension
import org.springframework.test.web.servlet.MockMvc
import org.springframework.test.web.servlet.result.MockMvcResultMatchers.status
import org.springframework.test.web.servlet.setup.DefaultMockMvcBuilder
import org.springframework.test.web.servlet.setup.MockMvcBuilders
import org.springframework.web.context.WebApplicationContext

@ExtendWith(RestDocumentationExtension::class, SpringExtension::class)
@SpringBootTest
internal class TestControllerTest {

    private lateinit var mockMvc: MockMvc

    @BeforeEach
    fun setUp(context: WebApplicationContext, restDocumentation: RestDocumentationContextProvider) {
        mockMvc = MockMvcBuilders.webAppContextSetup(context)
            .apply<DefaultMockMvcBuilder>(MockMvcRestDocumentation.documentationConfiguration(restDocumentation))
            .build()
    }

    @Test
    fun `스웨거 테스트`() {
        val name = "mark"
        val age = 20
        mockMvc.perform(
            get("/test?name={name}&age={age}", name, age)
        )
            .andExpect(status().isOk)
            .andDo(
                MockMvcRestDocumentationWrapper.document(
                    identifier = "test",
                    resourceDetails = ResourceSnippetParametersBuilder()
                        .tag("테스트")
                        .description("테스트 입니당")
                        .requestParameters(
                            parameterWithName("name").description("이름").type(SimpleType.STRING),
                            parameterWithName("age").description("나이").type(SimpleType.NUMBER),
                        )
                        .responseFields(
                            fieldWithPath("status").type(JsonFieldType.NUMBER).description("The status."),
                            fieldWithPath("value").type(JsonFieldType.STRING).description("The value."),
                        ),
                ),
            )
    }
}

4. run openapi3

테스트코드를 작성한 후, openapi3 를 실행한다.

5. openapi3.yaml 확인

해당 yaml을 swagger editor(https://editor.swagger.io/)에 붙여넣으면 정상적으로 문서화가 된 것을 확인할 수 있습니다.

아직 테스트 중이라 수정해야할 게 많습니다. 감안해서 확인 부탁드립니다~

동대문 임장 내용 정리 (feat. 전농동, 답십리, 장안동)

지잉지잉 — Mon, 29 May 2023 22:52:55 +0900

2023-05-29 12시 ~ 15시 (조금 흐렸다가, 쨍쨍해진 날씨)

돌아다닌 단지는 아래 지도에 표시된 전농동, 답십리 일대와 장안동은 현대홈타운 1차 아파트만 방문했다.

목록
1. 전농SK1차
2. 전농우성
3. 전농래미안엘파인
4. 답십리대림
5. 동답한신
6. 답십리동아
7. 답십리두산1단지
8. 답십리파크자이
9. 답십리청솔우성
10. 장안현대홈타운1차

단지 목록

1. 전농SK1차

단지	평형	가격대	교통	인프라
전농SK1차 1,830세대 2000-07-06	24A 24B 33A 33B 42	6.1 ~ 6.3억 2023-04, 24A평형 기준 전세가율 52~54%	청량리역 도보 30분 답십리역 도보 28분	단지 앞 학원, 마트 등 많은 상권 존재

주차하기 편리해보임
단지는 깨끗하지만 내부 엘리베이터나 현관문 등 컨디션은 좋지 않은듯..
상가에 이것저것 많아서 단지내에서 해결할 수 있는게 많은 것 같음.
유동인구가 많은 편은 아니고, 특히 아이들이 많이 보이지 않았다..!
근처 지하철역이 도보로 꽤 오래 걸리기 때문에 (28~30분), 근처 버스나 자차를 이용해야 함.

2. 전농우성

단지	평형	가격대	교통	인프라
전농 우성 1,234세대 1992-03-11	16 22 28 38 41	5.8억 ~ 6.8억 22평형 기준	청량리역 도보 33분 답십리역 도보 35분	딱히..?

이 아파트의 장점을 잘 찾지 못했다..ㅠㅠ
아파트 외관도 좋지 않은 편이라고 생각했고, 전농SK에 비하면 인프라나 교통도 별로. 심지어 유동인구도 거의 보지 못했다..

3. 전농래미안엘파인

단지	평형	가격대	교통	인프라
전농래미안엘파인 472세대 2011-06-23	24 32A 32B 33C 42	7.3 ~ 8.2억 2023-05, 24평형 기준 전세가율 52%	청량리역 도보 40분 답십리역 도보 36분	여기도 딱히..?

근처 전농SK, 전농우성에 비하면 확실히 신축 아파트 느낌이 났다.
하지만 여기도 상권과 교통이 별로였다. 유동인구도 거의 보지 못함.
주변에 빌라촌이 있는 듯 했다.
단지 내나 아파트 외관은 굉장히 깨끗하고 정리가 잘 된 느낌이였지만,
개인적으로 느낀 점은, 굳이 7억대에 여기로? 라는 의문이 들었다. (지극히 주관적인 생각입니다..!)

4. 답십리대림

단지	평형	가격대	교통	인프라
답십리대림 228세대 2003-01-08	24 32A 32B 42	6.1 ~ 6.7억 2023-05, 24평형 기준 전세가율 57~59%	답십리역 도보 24분	단지 바로 앞 조그만 상가가 있다. 그 외 아파트 앞에도 작은 상권들이 모여있지만, 대부분 미용실이나 배달음식점 등등.. 그저그랬다.

동답초등학교가 바로 붙어 있다.
그냥 초붙아 외에는 큰 장점이 없다고 느꼈다. (지극히 개인적인 느낌)
계단 + 복도식 아파트
나름 깔끔하고 정리가 잘되어 있다.
단지 나왔을 때 골목이 낡고 빌라촌들이 많았다.

5. 동답한신

단지	평형	가격대	교통	인프라
동답한신 600세대 1992-01-03	14 17 23 33 34	5.2 ~ 6억 2023-05, 23평형 기준 전세가율 58%	답십리역 도보 22분	단지 바로 앞 조그만 상가가 있다.

답십리 대림과 바로 붙어있다.
주변 상권도 공유하는 느낌. 가격은 굉장히 싸다고 느꼈다.
건물 외관이나 단지 내부 환경은 조금 낡아보이는 정도? 큰 특징은 없었다.
살짝 언덕

6. 답십리동아

단지	평형	가격대	교통	인프라
답십리동아 741세대 2001-11-23	27 32 38 42	5.8 ~ 6.5억 2023-05, 27평형 기준 전세가율 58~59%	답십리역 도보 19분	단지 내 편의점 등 상가가 있고, 입구에서 조금 내려오면 작은 상권들이 있다.

여기는 동별로 좋고 나쁨이 차이가 난 것 같다.
쪽문?후문? 쪽 단지는 별로 안좋아 보였지만, 정문 쪽 단지에는 인프라 접근성 등이 괜찮아 보였다.
살짝 오르막이 있다.
답십리 주민센터와 딱 붙어있어서 좋아보였다.

7. 답십리두산1단지

단지	평형	가격대	교통	인프라
답십리두산1단지 739세대 2000-08-02	23 25 32 42	6.2 ~ 7.2억 2023-05, 23평형 기준 전세가율 52~53%	답십리역 도보 22분	단지 내 조그마한 상가 존재

언덕이 가파랐다..(후문 쪽인 것 같음.)
아파트 내부 엘리베이터가 깨끗하고 현관쪽도 깨끗해보였다.
아파트 외관이나 단지 내부 환경 등 컨디션이 괜찮아보였다.
정문에 씨유 있음.

8. 답십리파크자이

단지	평형	가격대	교통	인프라
답십리파크자이 802세대 2019-01-22	20A 20B 25A 25E 25B 25C 33A	7.6 ~ 8.4억 2023-05, 20평형 기준 전세가율 50~51%	답십리역 도보 15분	잘 못봤다. 단지 내에 있었나? 지도상에는 단지 나와서 아래쪽에 조그만 상권이 있어보임

답십리동아, 답십리두산과 밀접해있음
주민센터가 초 근접해있음.
단지내 환경이나 외관 등 컨디션이 최상수준
단지로 통하는 문이 잠겨있음 (보안)
오늘 본 단지 중 입지나 아파트 컨디션은 최고인듯했다. 다만 가격이 비싼게 문제..ㅠ

9. 답십리청솔우성

단지	평형	가격대	교통	인프라
답십리청솔우성1차 1,542세대 2000-03-18	23A 23B 32 42	6.7 ~ 7.7억 2023-05, 23A평형 기준 전세가율 49~50%	청량리역 도보 30분 답십리역 도보 26분	시장과 연결되어 있음 시장 주변으로 약간의 상권

무난무난한 아파트.
전농SK 아파트와 근접해있다.
전농SK와 가격차이가 있는 만큼(5천+), 내 기준 전농 SK보다 깨끗하고 컨디션이 좋아 보였음.

10. 장안현대홈타운1차

단지	평형	가격대	교통	인프라
동답한신 2,182세대 2003-10-28	22C2 23C1 23C 32B 32B1 42 50	6.5 ~ 7.3억 2023-05, 22C2평형 기준 전세가율 61%	장한평역 도보 40분	단지 바로 앞 시장이 있고 상권이 엄청 발달함. 없는게 없는 정도?

인프라가 굉장히 좋고 유동인구가 굉장히 많은 동네
그렇다고 해서 유해시설 등은 딱히 안보임.
장안/답십리에 비해 학생들이 많이 보였다. (장안/답십리는 거의 안보였던 정도?)
단지 내부나 건물 외관도 굉장히 깨끗함.
단점은 교통이 별로 좋지 않은 듯 함. (주변에 버스정류장이 있는지는 모르겠지만..)

결론

방문 전, 전농SK나 답십리우성, 두산 등 대단지 아파트가 6억초반대라니! 라는 기대를 안고 갔었다.
굉장히 싼 가격이고 대단지라는 점에서는 좋아보였지만, 교통이나 유동인구, 인프라 등이 조금 아쉬운 수준이였다.
그에 반해 장안은 교통은 불편하지만 유동인구와 인프라가 굉장히 좋아보였다.
오늘 임장 중 사고 싶은 아파트를 고르라면
- 내 픽: 전농SK, 답십리두산
- 루책임 픽: 장안현대홈타운1차

[Spring] DI를 쉽게 하는 방법 (Feat. @RequiredArgsConstructor)

지잉지잉 — Sun, 26 Feb 2023 14:44:41 +0900

1. 개요

Spring DI 방법은 대표적으로 아래의 세 가지를 이용한다.
- 생성자 주입
- Field 주입
- Setter 주입
보통은 @Autowired를 이용한 Field 주입을 많이 사용하는데, 생성자 주입을 권장한다.
- 순환참조 이슈
- Bean을 Immutable 하게 주입 가능 등 장점이 많다.

2. 기본적인 생성자 주입 방법

@RestController
@RequestMapping("")
public class TestController {

    private final ProjectService projectService;
    private final CatalogService catalogService;
    private final MailService mailService;
    
    public TestController(ProjectService projectService, CatalogService catalogService, MailService mailService) {
        this.projectService = projectService;
        this.catalogService = catalogService;
        this.mailService = mailService;
    }
}

생성자에 Dependencies를 추가한다.
Spring은 해당 Dependency를 찾아와 자동으로 주입해준다.

3. 더 간단하게 생성자 주입

@RestController
@RequestMapping("")
@RequiredArgsConstructor
public class TestController {

    private final ProjectService projectService;
    private final CatalogService catalogService;
    private final MailService mailService;
}

@RequiredArgsConstructor
- final 혹은 @NonNull 이 붙은 필드만 받는 생성자 자동생성
@RequiredArgsConstructor로 생성자를 생략할 수 있고, 자동으로 의존성 주입(생성자 주입)까지 된다.

[Spring] Intellij Community로 Multi Module Project 생성하기

지잉지잉 — Sun, 26 Feb 2023 13:55:59 +0900

1. 개요

저는 Intellij Community를 사용하고 있는데, 제가 못하는건지 원래 안되는건지, Springboot-Java 프로젝트를 생성하는게 잘 안됐었습니다.
그래서 Springboot Initializer로 Project 들을 생성하고, 그 이후 root-project에 모듈들을 등록함으로써 Multi Module Project를 구성했습니다.

2. Project 구성

User라는 root-project와, 그 아래 admin/client/core/internal 4개의 Submodule을 구성했습니다.
user (root-project)
- admin
- client
- core
- internal

3. Root Project 생성

Spring initializer로 root project(user) 을 생성합니다. (https://start.spring.io/)위 처럼 프로젝트 설정을 마친 후, "GENERATE" 버튼을 클릭하여 프로젝트 생성합니다.

생성이 완료 되었으면 압축을 풀고 Intellij에서 Open 합니다.

4. Sub Module 생성

위에서 Springboot Initializer를 통해 4개의 모듈도 동일한 방법으로 생성해줍니다.
생성한 4개의 Sub Module을 Root Project Directory의 하위로 옮깁니다.

5. Sub Module 설정

위처럼 프로젝트를 모두 Root Project 아래에 넣고 Intellij에서 확인해보면, 해당 프로젝트는 Multi module Project로 인식이 되지 않습니다.
settings.gradle 파일에 4개의 Sub Module을 Include 하면, Root project에서는 include 된 4개의 프로젝트를 sub module로 인식합니다.

[Spring Webflux] 웹플럭스에 대한 간단 정리

지잉지잉 — Sun, 5 Feb 2023 22:31:46 +0900

Spring MVC와 Spring Webflux

Spring MVC는 Blocking / 동기방식으로 동작한다.
- 요청이 발생할 경우, 스레드풀 내 스레드 하나를 점유해 요청을 처리한다.
Spring Webflux는 Non-Blocking / 비동기방식으로 동작한다.
- 요청이 발생할 경우, 이벤트 루프가 돌아서 해당 이벤트를 처리하는 핸들러에게 처리를 위임하고, 처리가 완료되면 callback 메소드 등을 통해 응답을 반환한다.

Spring Webflux를 사용하는 이유

Spring MVC에 비해 적은 스레드를 이용하여 동시성을 핸들링한다.
즉 서버 자원을 낭비하지 않고 효율적으로 동작하는 것을 목적으로 사용한다.
- 보통 Spring MVC 의 Tomcat 서버에서는 스레드 수가 Default 200개이다. 서버에 요청이 많지 않을 경우, 노는 스레드가 생기고, 그만큼 자원이 낭비된다.

Reactive

Reactive Stream

Spring Webflux 에서 사용하는 Reactor는 Reactive Stream의 구현체이다.
- 논블로킹과 백프레셔를 이용한 비동기 데이터 처리의 표준

https://engineering.linecorop.com/ko/blog/reactive-streams-with-armeria-1

Subscriber -> Publisher: 구독 요청
Publisher -> Subscriber: Subscription 정보 전달
Subscriber -> Subscription -> Publisher: Subscription의 request 함수를 통해 Publisher에게 요청
Publisher -> Subscription -> Subscriber: Subscription의 시그널(onNext, onComplete, onError 등)을 응답

Mono와 Flux

Flux와 Mono는 Reactive Stream의 구현체인 Reactor 객체이며, 차이점은 발행하는 데이터 갯수이다.
- Flux: 0 ~ N 개의 데이터 전달
- Mono: 0 ~ 1 개의 데이터 전달

[Spring Batch] Spring Batch에 대하여

지잉지잉 — Sun, 29 Jan 2023 02:32:58 +0900

Spring Batch란?

대용량 일괄처리의 편의를 위해 설계된 가볍고 포괄적인 배치 프레임워크
Spring Scheduler와는 별개의 개념이다. Batch는 보통 Jenkins나 Spring Scheduler에 의해 Trigger 된다.

왜 쓸까? (내 생각..)

A라는 한 서버가 있고 이 서버에는 주기적으로 데이터를 처리해야하는 일련의 작업이 있다.
A서버의 해당 작업은 Spring Scheduler에 의해 해당 로직이 수행된다.
그러면 A서버는 데이터를 주기적으로 처리하는 일 뿐만아니라 본래 수행해야하는 요청/응답까지 수행했을 때 리소스가 부족하거나 하진 않을까?
이 작업을 Spring Batch로 구현한다면 => 별도의 배치서버로 구현하고 해당 서버는 Scheduler에 의해 실행이 된다.
즉 Spring Scheduler에 의해 Trigger가 된다면, 새로운 Job Instance가 생기고 배치작업이 끝나면 Job Instance는 사라진다. 배치가 실행되는 시간에만 서버의 리소스를 사용한다.
그렇기 때문에 서버에서는 리소스 관리를 수월하게 할 수 있다.

Tasklet 처리 방식과 Chunk 지향 처리 방식에 대하여

Spring Batch에서 "Job"은 순차적인 Step을 수행한다.

1. Tasklet 처리 방식

하나의 메서드로 구성되어 있는 간단한 인터페이스 이다. 1Step:1Tasklet

2. Chunk 지향 처리 방식

Chunk란, Batch 처리에서는 chunk 단위로 트랜잭션을 수행한다.
chunk는 트랜잭션 내에서 커밋하는 row 수 이며 chunk 단위만큼 커밋되거나 롤백된다.

여기서 ItemReader와 ItemProcessor에서는 데이터 1건씩 다뤄지고, Writer에서는 Chunk 단위로 처리된다.

어떤 캐싱을 도입할까? feat. 로컬캐시, Redis, 웹캐시

지잉지잉 — Sat, 7 Jan 2023 18:23:41 +0900

캐시란?

복잡한 연산이나 시간이 오래 걸리는 연산을 미리 수행한 후, 그 결과 값을 저장하여 필요시 빠르게 가져와 사용할 수 있게 하는 것

캐시의 종류

로컬캐시
Redis
DB내부 캐시
웹캐시
CDN 등

종류별 특징

로컬캐시: 서버의 리소스(Memory, Disk) 내 결과값을 저장한다. (Caffeine cache, EHcache)
- 장점
  - 타 서버간 통신비용이 발생하지 않는다.
  - 서버 인스턴스 메모리에 저장하기 때문에 가져오는데 속도가 빠르다.
- 단점
  - 서버가 여러대로 클러스터링 되어있는 경우, 동기화가 되지 않는다.
  - 캐시 데이터가 커질수록 서버 메모리가 부족해 지며 이에 따라 애플리케이션 성능이 저하 될 수 있다.

Redis: 데이터 영속성을 지원하는 In-memory 저장소 (스냅샷 기능을 통해 Disk에 캐시데이터를 저장할 수 있기 때문)
- 장점
  - 서버 복제 지원. Master-slave 구조로 여러대의 복제본을 만들 수 있다.
  - 트랜잭션 지원
  - 여러 데이터 자료형 지원(문자열, 숫자, boolean 등)
- 단점(?)
  - 싱글스레드로 동작하기 때문에 병목현상이 발생할 수 있다.
  - 로컬캐시에 비해 서버 <-> 레디스 간 통신 비용이 발생한다.

웹캐시: 웹 사용자에 의해 빈번히 요청되는 데이터를 웹캐시 서버(Nginx 등)에 보관함으로써 응답한다.
- Client - Nginx proxy server - server 구조 일 때, 요청이 nginx 서버에 캐시되어 있다면 실제 요청은 server에 전달되지 않고 Client에게 반환한다.
- 장점
  - 요청이 실제 서버로 넘어가지 않기 때문에 부하 자체를 줄여줄 수 있다.
- 단점
  - 별도의 웹캐시용의 서버 구성 필요
  - Client에서 Server로 요청하는 과정에 Proxy 서버가 중간에 끼게 되는 형태인데, 통신 과정이 늘어나니까 당연히 소요시간이 길어질 수 있다.

트랜잭션과 격리 수준 (Isolation Level)

지잉지잉 — Fri, 30 Dec 2022 15:38:01 +0900

트랜잭션(Transaction)이란?

데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위
SELECT, INSERT, DELETE, UPDATE (SQL) 하나만을 의미하는게 아니다. 하나의 작업에는 여러개의 질의어가 포함될 수 있다.

트랜잭션의 특징

ACID
- 원자성 (Atomicity)
  - 데이터베이스에 모두 반영되던가 (commit), 모두 반영되지 않던가 (rollback,aborted)
- 일관성 (Consistency)
  - 트랜잭션의 작업 처리 결과가 항상 일관성 있어야 한다.
  - 트랜잭션이 진행되는 동안 데이터베이스가 변경되더라도, 업데이트 이전의 데이터베이스에 트랜잭션이 진행됨으로써 일관성 있게 데이터를 처리한다.
- 독립성 (Isolation)
  - 둘 이상의 트랜잭션이 동시 실행 되고있는 경우, 하나의 트랜잭션이 완료될 때 까지, 다른 트랜잭션이 해당 트랜잭션의 결과를 참조할 수 없다.
- 지속성 (Durability)
  - 트랜잭션이 성공적으로 완료됐을 경우, 결과는 영구적으로 반영되어야 한다.

트랜잭션 격리 수준 (Isolation Level) 이란?

동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 서로 얼마나 고립되어 있는지를 나타내는 것.
즉, 특정 트랜잭션이 다른 트랜잭션에 변경한 데이터를 볼 수 있도록 허용할지 말지를 결정

격리 수준간 차이

격리 수준은 아래 4개로 나뉜다. 아래로 갈수록 격리 수준이 높아지며, 성능이 떨어진다.

1. READ UNCOMMITTED

트랜잭션 진행간, Commit 되지 않은 데이터를 참조하여 트랜잭션을 진행한다.
Dirty Read 문제가 발생할 수 있다.
- 1. A 트랜잭션에서 A 테이블의 데이터를 수정중인 상태 (Commit 전)
- 2. B 트랜잭션에서 A 테이블의 데이터를 조회 (Commit 전이지만 A 트랜잭션에 의해 수정된 데이터를 조회해옴.) -> Dirty Read
- 3. A 트랜잭션에서 문제가 발생해 Rollback
- 4. B 트랜잭션은 A 트랜잭션에 의해 수정된 데이터를 이용하여 트랜잭션을 진행함.

2. READ COMMITTED (Oracle Default)

1과 달리 Commit 된 데이터만 조회해온다.
UNDO 영역에 저장된 데이터를 참조하기 때문에 Dirty Read가 발생하지 않는다.
하지만 NON-REPEATABLE READ 부정합 문제가 발생할 수 있다.
- B 트랜잭션에서 ID 1번 상품의 가격을 조회 => 10,000원
- A 트랜잭션에서 ID 1번 상품의 가격을 10,000 -> 20,000원으로 수정 후 Commit
- B 트랜잭션에서 ID 1번 상품의 가격을 다시 조회 => 20,000원 (NON-REPEATABLE READ)

3. REPETABLE READ (MySQL Default)

트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회할 수 있음.
자신의 트랜잭션 번호보다 낮은 트랜잭션 번호에서 Commit된 데이터만 조회함.
자신의 트랜잭션 번호보다 높은 트랜잭션에 의해 변경된 데이터는 Commit에 상관 없이 UNDO 영역만 조회.
2와 달리 NON-REPEATABLE READ 부정합 문제가 발생하지 않는다.
- A 트랜잭션(no: 10)에서 ID 1번 상품의 가격을 조회 => 10,000원
- B 트랜잭션(no: 12)에서 ID 1번 상품의 가격을 10,000 -> 20,000원으로 수정 후 Commit
- A 트랜잭션에서 ID 1번 상품의 가격을 다시 조회 => 10,000원

4. SERIALIZABLE

트랜잭션에서 데이터 SELECT 시 공유잠금을 설정함으로써, 해당 데이터를 수정하지 못하도록 설정함.
격리수준을 REPETABLE READ 로 적용하면 뭐든 해결인가? => 아니다. Phantom READ (유령읽기) 문제가 발생한다.
- A 트랜잭션에서 SELECT * FROM PRODUCT WHERE PRODUCT_ID < 5 => 1개 상품 조회
- B 트랜잭션에서 id 3인 상품 신규 생성 후 커밋
- A 트랜잭션에서 동일한 SQL 실행 => 2개 상품 조회

[Kubernetes] Canary 배포 환경 구성

지잉지잉 — Fri, 30 Dec 2022 11:09:30 +0900

0. 개요

Canary 배포란?
- 구 버전의 서비스와 새 버전의 서비스를 동시 구성, 일부 트래픽을 새 버전으로 분산하여 에러 여부 판단 및 모니터링 하는 배포방식
- 보통 구 버전은 PRODUCTION / 새 버전은 CANARY 로 서비스를 칭한다.

그림 출처: https://medium.com/@domi.stoehr/canary-deployments-on-kubernetes-without-service-mesh-425b7e4cc862

k8s의 nginx-ingress-controller를 통해 트래픽을 분산할 수 있다.
- weight 기반: 100 - X % / X % 로 트래픽 분산 (random)
- cookie 기반: 요청의 cookie value를 확인하고 production / canary 서비스로 분산
- header 기반: 요청의 header value를 확인하고 production / canary 서비스로 분산

1. 테스트용 프로젝트 생성

간단하게 2개의 프로젝트를 구성한다.
동일한 API path를 가졌지만, 구 버전과 새 버전의 응답값이 다르게 (production / canary 구분 가능하도록) 구성했다.

@RestController
public class ProductionController {
	
    @GetMapping("/test")
    public ResponseEntity<String> test() {
    	return new ResponseEntity<String>("[PRODUCTION] requested.", HttpStatus.OK);
    }
}

@RestController
public class CanaryController {
	
    @GetMapping("/test")
    public ResponseEntity<String> test() {
    	return new ResponseEntity<String>("[CANARY] requested.", HttpStatus.OK);
    }
}

2. Docker build

해당 서비스를 k8s에 올리기 위해 Docker image를 만든다.
Dockerfile도 간단하게 만든다..!

FROM adoptopenjdk/openjdk11
ARG JAR_FILE_PATH=./build/libs/TestProject-0.0.1-SNAPSHOT.jar
COPY ${JAR_FILE_PATH} TestProject-0.0.1-SNAPSHOT.jar
ENTRYPOINT ["java","-jar","TestProject-0.0.1-SNAPSHOT.jar"]

해당 도커파일로 이미지를 빌드한다.
나는 구 버전을 test-project:0.0.1, 새 버전을 test-project-0.0.2 로 빌드했다.

$ docker build -t test-project:0.0.1 . 
...
$ docker build -t test-project:0.0.2 .
...
$ docker images
REPOSITORY		TAG		IMAGE ID	CREATED		SIZE
test-project		0.0.1		...		1 minute ago	459MB
test-project		0.0.2		...		1 minute ago	459MB

3. Kubernetes 배포

구 버전 / 새 버전의 서비스 총 2개의 서비스를 Kubernetes에 올리기 위해 yaml 파일을 만든다. (커맨드로도 가능하다.)
아래 예시는 k8s deployment 생성과 service 노출(등록) 설정이다. production / canary 서비스 각각 이미지가 다르다.

production-service.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: svc-production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: svc-production
  template:
    metadata:
      labels:
        app: svc-production
    spec:
      containers:
        - name: svc-production
          image: test-project:0.0.1
          ports:
           - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: svc-production
spec:
  type: NodePort
  selector:
    app: svc-production
  ports:
    - port: 8080

canary-service.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: svc-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: svc-canary
  template:
    metadata:
      labels:
        app: svc-canary
    spec:
      containers:
        - name: svc-canary
          image: test-project:0.0.2
          ports:
           - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: svc-canary
spec:
  type: NodePort
  selector:
    app: svc-canary
  ports:
    - port: 8080

이제 위 2개의 파일을 가지고 서비스를 만들어보자

$ kubectl apply -f production-service.yaml
deployment.apps/svc-production created
service/svc-production created

$ kubectl apply -f canary-service.yaml
deployment.apps/svc-canary created
service/svc-canary created

서비스 확인 (deployment, service, pod, replicaset 모두 정상적으로 생성되었다.)

$ kubectl get all
NAME			READY	STATUS		RESTARTS	AGE
pod/svc-canary-...	1/1	Running		0		1m
pod/svc-production-...	1/1	Running		0		1m	

NAME				TYPE		CLUSTER_IP		EXTERNAL-IP	PORT(S)		AGE
service/svc-canary-...		NodePort	10.xxx.xxx.xxx		<none>		8080:32309/TCP	1m
service/svc-production-...	NodePort	10.xxx.xxx.xxx		<none>		8080:31373/TCP	1m

NAME					READY	UP-TO-DATE	AVAILABLE	AGE
deployment.apps/svc-canary-...		1/1	1		1		1m
deployment.apps/svc-production-...	1/1	1		1		1m

NAME					DESIRED	CURRENT		READY		AGE
replicaset.apps/svc-canary-...		1	1		1		1m
replicaset.apps/svc-production-...	1	1		1		1m

이제 해당 두 서비스를 클러스터 외부에서 접근하기 위해 ingress를 생성한다.
Ingress도 서비스와 마찬가지로 각각 yaml 파일로 생성한다.

production-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: production-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: canary-test.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: svc-production
                port:
                  number: 8080

canary-ingress.yaml 파일을 생성하기 전에! production ingress 부터 생성해보자

$ kubectl apply -f production-ingress.yaml
ingress.networking.k8s.io/production-ingress created
...
$ kubectl get ingress
NAME			CLASS	HOSTS			ADDRESS			PORTS	AGE
production-ingress	nginx	canary-test.com		192.xxx.xxx.xxx		80	1m

ingress를 생성한 후 kubectl get ingress 로 ingress 목록을 확인 할 때, ADDRESS가 아직 매핑이 안되있을 수 있다. (최대 n분 이상 소요 될 수 있다고 하니 기다려보자.)
ADDRESS가 매핑이 완료되었다면 production 서비스의 API를 호출해본다.

$ curl http://canary-test.com/test
[PRODUCTION] requested.

production 서버의 API 요청/응답이 정상적으로 이루어졌다.
만약 정상 응답이 되지 않는다면 리눅스의 hosts 파일에 해당 host를 등록해야한다.

$ vi /etc/hosts

// 맨 아랫줄에 ip 호스트 등록
...
127.0.0.1	localhost
...
192.xxx.xxx.xxx canary-test.com

4. Canary 배포 설정

앞에서 production 서비스를 배포하고 ingress 도 설정을 완료했으니 이제 canary 서비스의 ingress 생성 및 설정을 해야한다.
그 전에 nginx-ingress의 canary 관련 annotations를 간단히 살펴보자면..

annotations	type	description
nginx.ingress.kubernetes.io/canary	String	카나리 배포 적용 여부("true", "false")
nginx.ingress.kubernetes.io/canary-by-header	String	header key 값
nginx.ingress.kubernetes.io/canary-by-header-value	String	header value 값
nginx.ingress.kubernetes.io/canary-by-header-pattern	String	정규표현식을 사용한 header value 확인
nginx.ingress.kubernetes.io/canary-by-cookie	String	cookie 기반 라우팅 설정
nginx.ingress.kubernetes.io/canary-weight	String	weight 기반 라우팅
nginx.ingress.kubernetes.io/canary-weight-total	String	총 weight 수. (default: 100) canary-weight-total: 1000 canary-weight: 10 일 때, 1000번 요청 중 10번 요청이 canary 서비스로 요청됨

출처: https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#canary

canary-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/canary: "true" # enable canary
    # weight 기반 라우팅 (100번 요청 중 50번)
    nginx.ingress.kubernetes.io/canary-weight: "50"
    # cookie 기반 라우팅 (cookie에 canary=always 로 설정시 canary 서버로 요청, canary=never 일 때 production)
    nginx.ingress.kubernetes.io/canary-by-cookie: "canary" 
    # header 기반 라우팅 (header에 target=canary 로 설정시 canary 서버로 요청, 아니면 production)
    nginx.ingress.kubernetes.io/canary-by-header: "target"
    nginx.ingress.kubernetes.io/canary-by-header-value: "canary"
spec:
  rules:
    - host: canary-test.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: svc-canary
                port:
                  number: 8080

생성 및 적용

$ kubectl apply -f production-ingress.yaml
ingress.networking.k8s.io/production-ingress created
...
$ kubectl get ingress
NAME			CLASS	HOSTS			ADDRESS			PORTS	AGE
production-ingress	nginx	canary-test.com		192.xxx.xxx.xxx		80	10m
canary-ingress		nginx	canary-test.com		192.xxx.xxx.xxx		80	1m

http://canary-test.com의 동일한 호스트로 production / canary 서비스가 canary 배포 구성이 완료되었다.

5. Test

5-1. weight 기반 라우팅

$ curl http://canary-test.com/test
[PRODUCTION] requested.
$ curl http://canary-test.com/test
[CANARY] requested.
$ curl http://canary-test.com/test
[PRODUCTION] requested.
$ curl http://canary-test.com/test
[PRODUCTION] requested.
$ curl http://canary-test.com/test
[CANARY] requested.

5-2. cookie 기반 라우팅

$ curl --cookie "canary=always" canary-test.com/test
[CANARY] requested.
$ curl --cookie "canary=always" canary-test.com/test
[CANARY] requested.
$ curl --cookie "canary=always" canary-test.com/test
[CANARY] requested.
$ curl --cookie "canary=always" canary-test.com/test
[CANARY] requested.
$ curl --cookie "canary=never" canary-test.com/test
[PRODUCTION] requested.
$ curl --cookie "canary=never" canary-test.com/test
[PRODUCTION] requested.
$ curl --cookie "canary=never" canary-test.com/test
[PRODUCTION] requested.
$ curl --cookie "canary=never" canary-test.com/test
[PRODUCTION] requested.

5-3. header 기반 라우팅

$ curl -H "target:canary" canary-test.com/test
[CANARY] requested.
$ curl -H "target:canary" canary-test.com/test
[CANARY] requested.
$ curl -H "target:canary" canary-test.com/test
[CANARY] requested.
$ curl -H "target:canary" canary-test.com/test
[CANARY] requested.
$ curl -H "target:canary" canary-test.com/test
[CANARY] requested.