개린이의 일기장

git branch 전략 + commit 기록 방법 선택하기

Hyunec — Mon, 9 Oct 2023 00:36:15 +0900

git branch 전략과 commit 방법은 이미 많은 레퍼런스가 존재합니다.
하지만 지금 내 환경에 적합한 전략을 선택하는 것은 조금 다른 이야기입니다.

이 글에서는 사이드 프로젝트를 진행하면서 내가 해본 선택 과정을 기록합니다.

GitHub - Our-Class-Bank/core-backend: [side-project] 우리반은행

[side-project] 우리반은행. Contribute to Our-Class-Bank/core-backend development by creating an account on GitHub.

github.com

배경

github repository 에서 1인 백엔드 개발
프론트 개발은 별도의 repository 사용
dev, prod 배포 환경 지원 필요

전략 선택 과정

1. 초기 전략

feature, dev, main 브랜치만 사용하는 약식 Git Flow 전략

local 에서 feature 단위로 완성된 기능을 remote feature 브랜치에 머지합니다.
remote feature 브랜치를 dev 에 머지합니다.
qa 가 끝나면 main 브랜치에 머지합니다.

github issue 번호 기반으로 commit 기록

이 방법으로 commit 이 어떤 github issue 와 연결되었는지 직관적으로 알 수 있었습니다.

하지만 큰 내용도 아닌 것을 매번 github issue 를 작성하는 게 귀찮았습니다.
그리고 1인 개발이기 때문에 커밋 이상으로 이슈 트래킹 할 일은 없을 것 같았습니다.

micro commit 관점에서 issue, pr 에 너무 많은 기록은 꽤 지저분해 보입니다.

2. commit 기록 방법 변경

feature, dev, main 브랜치만 사용하는 약식 Git Flow 전략

milestone 단위로 prefix 를 만들고, 중분류를 나누어 commit 기록

github issue 대신 노션 보드로 작업을 관리했습니다.
그리고 일정 기간 단위로 milestone 뭉쳤습니다.

notion 으로 작업 관리

하지만 dev 브랜치만으로는 프론트 qa 와 배포 관리가 힘든 상황이 생겼습니다.
qa 를 위한 브랜치가 한 개다 보니 qa 완료 기능과 아닌 기능을 분리하기 힘들었기 때문입니다.

3. release branch 도입

feature, dev, release, main 브랜치만 사용하는 약식 Git Flow 전략

local 에서 feature 단위로 완성된 기능을 remote feature 브랜치에 머지합니다.
remote feature 브랜치를 dev 에 머지합니다.
qa 가 끝나면 versioning 후 release 브랜치에 머지합니다.
약속된 시간에 release 브랜치를 main 브랜치에 머지합니다.

milestone 단위로 prefix 를 만들고, 중분류를 나누어 commit 기록

하지만 feature 브랜치를 꼭 써야 되나?라는 생각이 들었습니다.
실무라면 특정 feature 만 테스트하거나 history, conflict 방지를 위해서라도 필요하지만, 1인 개발이다 보니 브랜치를 모두 컨트롤하는 게 어렵지 않았기 때문입니다.

4. feature branch 삭제

dev, release, main 브랜치만 사용하는 약식 Git Flow 전략

milestone 단위로 prefix 를 만들고, 중분류를 나누어 commit 기록

dev 브랜치에서 직접 개발을 진행하여 머지 회수를 줄였습니다.

마치며

v1.0.0 배포!

사실 1인 개발이라면 이런 전략들을 덜 고민해도 됩니다.
conflict 가 발생하더라도 그 commit 이 무엇이었는지 다 내 머릿속에 있을 테니까요.
혹자는 실무라면 여러 사람이 같이 일하고 그라운드 룰이 있기 때문에 이런 약식 전략은 별 의미가 없다고 말할 수도 있습니다.

저는 오히려 반대라고 생각합니다.

실무라고 할지라도 특정 프로젝트는 소수의 인원으로 진행할 수 있습니다.
신규 프로젝트를 셋업 하는 데는 컨텍스트를 이해하는 소수의 인원이 진행하는 것이 더 효율적일 수 있습니다.
그라운드 룰이 있을지라도 각 스쿼드는 독립적인 전략을 사용할 수 있습니다.

저는 모든 것을 실무라는 생각으로 지금에 최소이면서도 확장 가능한 선택을 하려고 노력합니다.
그래야만 실무에서 문제를 만났을 때 그 경험을 활용하여 더 좋은 선택을 할 수 있기 때문입니다.

어쩌면 실무는 더 극한일지도..?

참고자료

개인적으로 정리한 커밋

Spring cache 는 어떤 provider 를 사용하는 것이 좋을까?

Hyunec — Sun, 2 Apr 2023 00:30:13 +0900

회사에서 local cache 를 사용할 일이 생겼습니다.
동료분이 guava 를 알려주셨고 처음 들어보았기에 일단 baeldung 을 검색해 보았는데 조금 이상했습니다.

https://www.baeldung.com/guava-cache

캐시를 사용할 때 익히 쓰던 @Cacheable 어노테이션이 보이지 않았습니다.
그래서 익숙하던 ehcache 를 검색해 보면서 비교해 봤습니다.

The difference between Ehcache and Guava Cache - actorsfit

Recently, I have been doing some cache transformation scenarios, and there are some experience summaries as follows: Cached version: Ehcache: 2.8.3 Guava: 17.0 Ehcache supports persistence to the local disk, but Guava cannot;Ehcache has a ready-made cluste

blog.actorsfit.com

guava 는 가볍습니다.
guava 는 내부적으로 ConCurrentHashMap 을 사용하고 있습니다.

읽다 보니 동시성은 안전하지만 왠지 성능이 떨어질 것 같다는 직감이 들었습니다.
그래서 몇 개의 문서를 찾아본 결과 guava 는 읽기보다는 쓰기 작업이 중요한 상황에 쓰면 좋다는 내용을 찾았습니다.

여전히 꺼림칙한 느낌이 있어서 좀 더 찾아보었더니 guava 는 deprecated 되었습니다!
심지어 꽤 오래 전인 1.5.1.RELEASE 에서였습니다.

31. Caching

The Spring Framework provides support for transparently adding caching to an application. At its core, the abstraction applies caching to methods, reducing thus the number of executions based on the information available in the cache. The caching logic is

docs.spring.io

다시 처음으로 돌아가서 조사하던 중 caffeine 캐시를 찾았습니다.
ehcache 가 익숙하긴 하지만 기능이 많고 무거웠기에 가벼운 caffeine 을 사용하기로 최종 결정했습니다.

https://www.baeldung.com/spring-boot-caffeine-cache

The Spring Framework provides support for transparently adding caching to an application. At its core, the abstraction applies caching to methods, thus reducing the number of executions based on the information available in the cache. The caching logic is

docs.spring.io

code kata 를 하자! - Codewars

Hyunec — Mon, 20 Feb 2023 03:04:37 +0900

A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each

카타는 하나의 양식을 여러 번 반복하면서 조금씩 개선하는 가라데의 운동입니다.

보통 코딩 테스트 통과를 위한 알고리즘 공부는 leetcode, 백준을 추천하곤 합니다.

하지만 저는 실무에 있어 퍼즐에 가까운 알고리즘 풀이보다는, 범용적인 자료구조와 해당 언어의 Best Practice 학습이 더 중요하다고 생각합니다. 그러던 중 codewars 라는 사이트를 알게 되었고 제 목적에 부합하고 꽤 유용하다고 생각되어 간단히 소개해보고자 합니다.

Codewars - Achieve mastery through coding practice and developer mentorship

A coding practice website for all programming levels – Join a community of over 3 million developers and improve your coding skills in over 55 programming languages!

www.codewars.com

Pros

1. 공부하고 싶은 언어와 목적을 선택할 수 있습니다.

특히 문제 선택을 위해 참고할 수 있는 유형을 태그로 지원해 줍니다.

2. Best Practice 를 볼 수 있는 UX 가 압도적으로 훌륭합니다.

다른 사람의 코드를 볼 수 있는 기능은 다른 사이트에도 있지만, UX 가 압도적으로 훌륭합니다.
codewars 를 소개하는 가장 큰 이유입니다.

Cons

1. 커뮤니티 형태의 운영에서 생기는 단점

codewars 는 문제를 사용자 스스로 올릴 수 있고, 커뮤니티에서 자체적으로 관리됩니다.
그렇기에 참여가 적은 문제는 품질 관리 수준이 낮고, 난이도가 높아질수록 억지스러운 문제들도 존재합니다.

2. 분석 도구의 부족

효율성까지 분석해 주는 다른 사이트와 달리 성공과 실패만을 알려줍니다.

3. 앞의 2가지 이유로 코딩 테스트 준비 용도로는 추천하지 않습니다.

코딩 테스트 준비가 목표라면 leetcode, 백준을 추천합니다.

개인적인 활용

알지 못했던 String.replaceFirstChar 활용을 통한 개선

1. 하루에 1~2개 정도, 낮은 레벨의 문제만 풉니다. (kyu8 ~ kyu5)

낮은 레벨의 문제는 보통 요건이 단순하고 5줄 미만으로 해결할 수 있습니다.
자료구조와 Best Practice 를 학습하려는 목표에 적합합니다.

2. 문제의 태그를 선별적으로 활용합니다.

선호 태그 FUNDAMENTALS STRINGS LISTS
비선호 태그 MATHEMATICS ALGORITHMS PUZZLES

Spring Cloud OpenFeign + WireMock Test

Hyunec — Sun, 5 Feb 2023 02:26:47 +0900

Netflix OSS 에서 시작한 Feign 은 강력한 기능과 편의성으로 Spring Cloud 에 OpenFeign 으로 편입되었습니다.
OpenFeign 은 다음과 같은 장점을 가지고 있습니다.

외부 연동 로직을 간소화 시킵니다.
MSA 구성에 큰 도움을 줍니다. SAGA 패턴, 마이크로서비스 통신
탄력성 등 리액티브 시스템의 특성을 만족시키는데 유용한 패턴을 제공합니다.

OpenFeign 은 이미 널리 알려진 기술이기에 좋은 글들이 많지만 Kotlin + Test 로 작성된 글은 별로 없었습니다.
그래서 외부 연동을 준비하며 학습한 OpenFeign 의 기능을 구현과 테스트로 설명합니다.

GitHub - Hyune-s-lab/openfeign-spring-tutorial: openfeign 연습하기 with spring cloud

openfeign 연습하기 with spring cloud. Contribute to Hyune-s-lab/openfeign-spring-tutorial development by creating an account on GitHub.

github.com

1. OpenFeign 준비하기

// build.gradle.kts
extra["springCloudVersion"] = "2021.0.5"

dependencies {
	implementation("org.springframework.cloud:spring-cloud-starter-openfeign")
}

@Configuration
@EnableFeignClients("com.example.openfeignspringtutorial.openfeign")
class OpenFeignConfig

feign 을 적용할 패키지를 지정합니다.

// application.yml
logging:
  level:
    com:
      example:
        openfeignspringtutorial:
          openfeign: DEBUG

feign:
  client:
    config:
      fake-api: // feign name
        logger-level: basic
        

// application-test.yml
logging:
  level:
    com:
      example:
        openfeignspringtutorial:
          openfeign: DEBUG

feign:
  client:
    config:
      fake-api: // feign name
        logger-level: full

openfeign 은 debug 레벨에서만 로깅이 되기 때문에 패키지를 지정해야 합니다.
openfeign logger level 은 필요에 맞게 설정합니다.

2. 외부 연동하기 - OpenFeign

@RestController
class PostController(private val fakeApiOpenFeign: FakeApiOpenFeign) {
    @GetMapping("/posts/{postId}")
    fun getPost(@PathVariable postId: Long): PostResponse = fakeApiOpenFeign.getPost(postId)
}


@FeignClient(name = "fake-api", url = "https://jsonplaceholder.typicode.com")
interface FakeApiOpenFeign {
    @GetMapping("/posts/{postId}")
    fun getPost(@PathVariable postId: Long): PostResponse
}

PostController 로 들어온 GetPost 가 feign 을 통해 외부 url 을 호출하는 코드입니다.
샘플 코드에서는 Fake Api 를 활용했습니다.

// application.yml
application:
  feign-url:
    fake-api: https://jsonplaceholder.typicode.com

@FeignClient(name = "fake-api", url = "\${application.feign-url.fake-api}")
interface FakeApiOpenFeign {
    @GetMapping("/posts/{postId}")
    fun getPost(@PathVariable postId: Long): PostResponse
}

url 을 application.yml 에서 관리할 수도 있습니다.

3. 테스트 준비하기

// build.gradle.kts
dependencies {
    // feign mock test
    testImplementation("com.github.tomakehurst:wiremock-jre8:2.35.0")
    
    // kotest, gson
    ...
}


// application-test.yml
application:
  feign-url:
    fake-api: http://localhost:9561

@TestConfiguration
class WireMockServerConfig : ApplicationListener<ApplicationReadyEvent> {
    @Bean
    fun wireMockServer(): WireMockServer =
        WireMockServer(9561)

    override fun onApplicationEvent(event: ApplicationReadyEvent) =
        wireMockServer().start()
}

wiremock 은 stub server 를 기동시킬 수 있는 라이브러리로 외부 연동 테스트에 적합합니다.
테스트 설정에서는 애플리케이션 기동 완료 후 9561 포트로 wireMock 을 기동시킵니다.
- @PostConstruct 보다는 순서를 고려하여 더 확실한 ApplicationReadyEvent 를 활용 합니다.

object WireMockServerConst {
    const val port = 9561
    const val rootResponsePath = "src/test/resources/__files/"

    object GetPosts {
        const val url = "/posts/([1-99])"
        const val responsePath = "payload/post.json"

        fun absoluteResponsePath(): String = rootResponsePath + responsePath
    }
}

// resources/__files/payload/post.json
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

테스트 편의를 위한 상수 값들을 하나의 파일로 응집시킵니다.
wiremock 은 파일 형태의 json response body 를 지원 합니다. 기본 경로는 resources/__files 입니다.

4. 정상 응답 테스트

@ActiveProfiles("test")
@SpringBootTest(classes = [WireMockServerConfig::class])
internal class FakeApiOpenFeignTest(
    private val wireMockServer: WireMockServer,
    private val fakeApiOpenFeign: FakeApiOpenFeign,
) : BehaviorSpec({
    Given("getPosts stub - success") {
        wireMockServer.stubGetPosts(
            WireMock.aResponse()
                .withStatus(HttpStatus.OK.value())
                .withHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
                .withBodyFile(WireMockServerConst.GetPosts.responsePath)
        )

        When("feign 으로 getPost 호출") {
            val then = fakeApiOpenFeign.getPost(1L)

            Then("response 일치") {
                val expected: PostResponse = Gson().fromJson(
                    JsonReader(FileReader(WireMockServerConst.GetPosts.absoluteResponsePath())),
                    PostResponse::class.java
                )
                then shouldBe expected
            }
        }
    }
})

private fun WireMockServer.stubGetPosts(responseDefinitionBuilder: ResponseDefinitionBuilder) {
    stubFor(
        WireMock.get(WireMock.urlPathMatching(WireMockServerConst.GetPosts.url))
            .willReturn(responseDefinitionBuilder)
    )
}

wiremock stub server 와 gson 을 활용해 테스트할 수 있습니다.
kotlin 의 확장 함수를 통해 stub 생성 메서드를 깔끔하게 분리할 수 있습니다.

5. 예외 처리하기 - ErrorDecoder

// application.yml
feign:
  client:
    config:
      fake-api:
        logger-level: basic
        error-decoder: com.example.openfeignspringtutorial.openfeign.FakeApiErrorDecoder

class FakeApiErrorDecoder : ErrorDecoder {
    private val log = LoggerFactory.getLogger(this.javaClass)

    override fun decode(methodKey: String, response: Response): Exception {
        log.info("### ${response.status()}, methodKey = $methodKey");

        if (response.status() == HttpStatus.BAD_REQUEST.value()) {
            return ResponseStatusException(
                HttpStatus.valueOf(response.status()),
                "<You can add error message description here>"
            )
        }

        if (response.status() == HttpStatus.NOT_FOUND.value()) {
        	...
        }

        if (response.status() == HttpStatus.INTERNAL_SERVER_ERROR.value()) {
        	...
       	}

        return Exception(response.reason())
    }
}

openfeign 은 ErrorDecoder 를 통해 응답코드에 맞는 예외처리를 지원합니다.
기본적으로 ResponseStatusException 으로 반환하는 것을 추천합니다.

    Given("getPosts stub - BAD_REQUEST") {
        wireMockServer.stubGetPosts(WireMock.badRequest())

        When("feign 으로 getPost 호출") {
            val then = shouldThrow<ResponseStatusException> {
                fakeApiOpenFeign.getPost(1L)
            }

            Then("BAD_REQUEST 확인") {
                then.status shouldBe HttpStatus.BAD_REQUEST
            }
        }
    }

    Given("getPosts stub - INTERNAL_SERVER_ERROR") {
        wireMockServer.stubGetPosts(WireMock.serverError())

        When("feign 으로 getPost 호출") {
            val then = shouldThrow<ResponseStatusException> {
                fakeApiOpenFeign.getPost(1L)
            }

            Then("INTERNAL_SERVER_ERROR 확인") {
                then.status shouldBe HttpStatus.INTERNAL_SERVER_ERROR
            }
        }
    }

wiremock 은 간단하게 응답코드를 변경해서 내려보내줄 수 있습니다.

6. 목표 서버 Connection refused 대응하기 - retry

@Configuration
@EnableFeignClients("com.example.openfeignspringtutorial.openfeign")
class OpenFeignConfig {
    @Bean
    fun retryer(): Retryer {
        return Retryer.Default(300, 2000, 3)
    }
}

    Given("getPosts stub - Connection refused") {
        wireMockServer.stop()

        When("feign 으로 getPost 호출") {
            val then = shouldThrow<RetryableException> {
                fakeApiOpenFeign.getPost(1L)
            }

            Then("Connection refused 확인") {
                then.message shouldStartWith "Connection refused"
            }
        }
    }

RetryableException 발생시 등록된 retryer 로직이 동작 합니다.

마무리

openfeign 사용에 필요한 내용들을 어느 정도 정리했지만 실무를 위해서는 고민할 점이 남아있습니다.
하지만 이번 글에서는 키워드만 공유하고 좀 더 실무에 적용해본 후 정리하겠습니다.

Connection refused 외에도 재시도할 수 있을까? - ErrorDecoder Custom
200 OK 예외는 어떻게 해야 될까? - ErrorDecoder Custom
대상 서버의 장애가 장기화되면 어떻게 해야 될까? - Circuit Breaker, FallBack

RandomCode Generator 성능 측정하기

Hyunec — Wed, 11 Jan 2023 16:40:49 +0900

일련번호는 총 16 자리의 숫자/영문 대문자로 이루어진 문자열이다.

최근 회사 업무를 하던 중 기존에 작성된 무작위 일련번호를 만드는 로직을 보게 되었습니다.
간단한 업무 내용에 Util 성격의 로직이었지만, 구현된 로직은 생각보다 복잡했습니다.
그래서 기존 로직의 의도를 파악하고, 개선을 시도해 보았습니다.

먼저 결론을 공유하고, 시도한 개선을 따라가 보겠습니다.

결론 (각 1만, 10만, 50만, 100만 회 반복)

ThreadLocalRandom 의 성능은 매우 뛰어나다. Kotlin Random 역시 뛰어나다.
String 변환은 매우 비싼 작업이며 Sequence 가 효율적으로 작동하지 않을 수 있다.
Coroutine 은 학습이 부족하여 적용하지 않았다.

GitHub - Hyune-s-lab/perf-16-digit-code-generator: 16자리 코드 생성 성능 테스트

16자리 코드 생성 성능 테스트. Contribute to Hyune-s-lab/perf-16-digit-code-generator development by creating an account on GitHub.

github.com

기존 로직 분석

CodeGenerator.kt

object CodeGenerator {
    private val numUpperChars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray()
    private const val codeDigits = 16

    fun generate(count: Long): Set<String> {
        val codes = mutableSetOf<String>()
        val code = StringBuilder()
        do {
            repeat((1..codeDigits).count()) {
                getRandomIndex().apply {
                    code.append(numUpperChars[this])
                }
            }
            codes.add(code.toString())
            code.clear()
        } while (!isGeneratedCountEnough(codes, count))

        return codes
    }

    private fun getRandomIndex() = ThreadLocalRandom.current().nextInt(0, numUpperChars.size)
    private fun isGeneratedCountEnough(codes: Set<String>, count: Long) = codes.size >= count
}

숫자와 영문 대문자만을 가진 Character Pool 을 활용하여 낭비 없이 랜덤 문자를 가져옵니다.
StringBuilder 를 통해 코드 생성 과정의 낭비를 없애고, Set 자료구조를 통해 완성된 코드의 중복을 방지합니다.
ThreadLocalRandom 의 활용으로 안전하고 빠른 Random 을 구현했습니다.

Random 대신 ThreadLocalRandom을 써야 하는 이유

java.util.Random은 멀티 쓰레드 환경에서 하나의 인스턴스에서 전역적으로 의사 난수(pseudo random)를 반환한다. 따라서 같은 시간에 동시 요청이 들어올 경우 경합 상태에서 성능에 문제가 생길 수 있

velog.io

숫자와 문자로만 이루어진 16자리라면 UUID 를 활용하면 어떨까?

UUIDStrategy.kt

UUIDWithSequenceStrategy.kt

검증된 UUID 로직을 활용하기에 성능이 좋아질 것으로 기대했지만, 기존 대비 2배 수준의 성능 차이가 납니다.

class UUIDStrategy : CodeGenerationStrategy {
    override fun generate(size: Long): Set<String> =
        (1..size)
            .map { UUID.randomUUID().toString().uppercase().replace("-", "") }
            .toSet()
}

가독성은 확실히 좋아졌지만, String 변환의 비용이 크기 때문인 것 같습니다.

ThreadLacalRandom, Java Random, Kotlin Random 은 어떨까?

LegacyWithJavaRandomStrategy.kt

LegacyWithKotlinRandomStrategy.kt

Java Random 은 꽤 느립니다.
Kotlin Random 과 ThreadLocalRandom 은 큰 차이가 없습니다.

class LegacyWithJavaRandomStrategy : CodeGenerationStrategy {
    override fun generate(size: Long): Set<String> {
	...
    }

	// companion object 에 선언한 random 사용
    private fun getRandomIndex() = random.nextInt(0, numUpperChars.size) 
    private fun isGeneratedCountEnough(codes: Set<String>, count: Long) = codes.size >= count
    
    companion object {
        private val numUpperChars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray()
        private val random = Random() // Java Random 선언
        private const val codeDigits = 16
    }
}


class LegacyWithKotlinRandomStrategy : CodeGenerationStrategy {
    override fun generate(size: Long): Set<String> {
	...
	}

	// Kotlin Random 사용
    private fun getRandomIndex() = Random.nextInt(0, numUpperChars.size)
    private fun isGeneratedCountEnough(codes: Set<String>, count: Long) = codes.size >= count
    
    companion object {
        private val numUpperChars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray()
        private const val codeDigits = 16
    }
}

Java Random 은 사용 전 객체 생성을 해줘야 합니다. 본 코드에서는 companion object 에 선언하였습니다.
Kotlin Random 은 바로 사용할 수 있었습니다. (이미 companion object)

UUID 를 그대로 쓰면 어떨까?

PerformanceTest.kt

fun measureTimeMillis3(size: Long): Long {
    var codes: List<UUID>
    val elapsed = measureTimeMillis {
        codes = (1..size).asSequence()
            .map { UUID.randomUUID() }
            .toList()
    }

    codes.size shouldBe size

//    println(codes)
    return elapsed
}

UUID 는 최적화가 잘되어서인지 아주 높은 성능을 보여주었습니다.
Sequence 도 잘 적용됩니다.

커스텀 로직보다는 검증된 라이브러리를 활용하는 것의 성능이 더 좋을 것이다.

직접 해보기 전까지는 위와 같이 생각했었습니다.
하지만 직접 해보면서 업무 성격에 따라서는 직접 만드는 것이 더 유리할 수도 있다는 것을 알았고, 기존 코드를 학습하면서 ThreadLocalRandom 이라는 몰랐던 기능과 Java Random 과 Kotlin Random 의 차이도 알 수 있었습니다.

비록 가독성은 차이가 있지만, 기존 로직이 업무 요건을 만족하고 성능 차이가 크기에 그대로 둘 것 같습니다.

Datagrip 에서 Datasource 공유하기

Hyunec — Sat, 19 Nov 2022 18:41:29 +0900

DB 접속 정보 세팅은 가장 기초적인 개발 환경 세팅의 하나입니다.
보통은 애플리케이션이나 환경 변수 정보 모음에서 가져오거나, 별도로 관리되는 엑셀 파일을 활용하곤 합니다.
하지만 균일한 개발 환경을 보장하기 힘들고, 접속해야 되는 DB 가 많은 경우 꽤나 번거로운 일입니다.

Datagrip 은 Export Settings 이라는 좀 더 똑똑한 방법을 지원합니다.

Manage data sources | DataGrip

www.jetbrains.com

datasource 세팅이 완료된 기존 직원

1. export 시키고 싶은 정보를 global datasource 로 설정

2. export - Database 2개 체크

datasource 정보를 받고 싶은 신규 직원

1. import - setting.zip 파일 선택

2. 성공!

스프링 마이크로서비스 코딩 공작소 (2)

Hyunec — Thu, 6 Oct 2022 02:38:44 +0900

GitHub - Hyune-s-lab/optima-growth: 스프링 마이크로서비스 코딩 공작소

스프링 마이크로서비스 코딩 공작소. Contribute to Hyune-s-lab/optima-growth development by creating an account on GitHub.

github.com

Phase 1
3. 스프링 부트로 마이크로서비스 구축하기
4. 도커
https://hyune-c.tistory.com/53

Phase 2
5. 스프링 클라우드 컨피그 서버로 구성 관리
6. 서비스 디스커버리
이 글입니다.

eureka-server 구현

유레카는 클라이언트의 생존 여부를 체크하여 API 게이트웨이의 라우팅을 돕습니다.

eureka-server

// build.gradle.kts
dependencies {
    implementation("org.springframework.cloud:spring-cloud-starter-netflix-eureka-server")
}


// EurekaServerApplication.kt
@EnableEurekaServer
@SpringBootApplication
class EurekaServerApplication

fun main(args: Array<String>) {
    runApplication<EurekaServerApplication>(*args)
}

// application.yml
server:
  port: 8761

eureka:
  instance:
    appname: eureka-server
  client:
    register-with-eureka: false
    fetch-registry: false

licensing-service

// build.gradle.kts
dependencies {
    implementation("org.springframework.cloud:spring-cloud-starter-netflix-eureka-client:3.1.4")
}


// LicensingServiceApplication.kt
@EnableEurekaClient
@SpringBootApplication
class LicensingServiceApplication

fun main(args: Array<String>) {
    runApplication<LicensingServiceApplication>(*args)
}


// application.yml
server:
  port: 8080

eureka:
  instance:
    appname: licensing-service
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://localhost:8761/eureka/

http://localhost:8761/

유레카는 클라이언트를 알지 못합니다.
클라이언트가 유레카의 url 을 알고 정보를 보내줍니다. (application.yml 의 defaultZone)
유레카는 클라이언트 application 의 생존 여부를 알 수 있습니다. (LICENSING-SERVICE)

http://localhost:8761/eureka/apps

유레카에서 관리되는 application 을 볼 수 있습니다. json 형태도 가능합니다.
instanceId 의 ip 를 보면 172 대역대로 사설망임을 확인할 수 있습니다.

API 호출

ip 로 api 요청 시 성공합니다!

docker setting

docker 는 시행 착오가 조금 있었습니다. 코드 소개 후 아래에서 설명 합니다.

Dockerfile

# docker/eureka-server/Dockerfile
FROM openjdk:17-jdk-slim-buster
ARG JAR_FILE=/eureka-server/build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]


# docker/eureka-server/licensing-service
FROM openjdk:17-jdk-slim-buster
ARG JAR_FILE=/licensing-service/build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

기존 root 경로에 있던 Dockerfile 을 service 에 맞는 폴더로 분리했습니다.
docker setting 후 이어질 환경 설정 분리에서 좀 더 활용해봅니다.

docker-compose.yml

version: "3"
services:
  eureka-server:
    image: eureka-server
    ports:
      - "8761:8761"
  licensing-service:
    image: licensing-service
    ports:
      - "8080:8080"
    links:
      - eureka-server

run.sh

# eureka-server
cd eureka-server
./gradlew bootjar
cd ..
docker build -f docker/eureka-server/Dockerfile -t eureka-server .

# licensing-service
cd licensing-service
./gradlew bootjar
cd ..
docker build -f docker/licensing-service/Dockerfile -t licensing-service .

# 백그라운드로 실행
nohup docker-compose up 1>/dev/null 2>&1 &

기존에는 서비스가 1개였기에 바로 실행했습니다.
하지만 이제는 서비스가 2개인만큼 백그라운드로 실행하게 하고 로그를 남기지 않게 했습니다.

./run.sh

docker dashboard 에서 8761, 8080 포트로 정상실행 된 것을 볼 수 있습니다.

(개별 서비스로 실행했을 때와 달리 docker 로 실행 시 30초 정도의 지연이 걸릴 수 있습니다.)
정상적으로 클라이언트를 찾은 것 처럼 보이지만 IP 가 보였던 아까와는 달리 해시 값이 보입니다?
API 호출도 되지 않습니다???

시행 착오 1 - IP 가 왜 안 나올까?

docker dashboard 를 보면 licensing-service-1 의 컨테이너 ID 와 유레카의 해시 값이 같음을 알 수 있습니다.
하지만 IP 의 형태가 아니고 API 호출이 정상적으로 되지 않습니다.

처음에는 설정의 문제로 생각해서 eureka.instance.preferIpAddress=true 도 설정했지만 결과는 같았습니다.

그러다 책을 다시 보니 흐름상 클라이언트의 요청은 API 게이트웨이를 통해 서비스로 전달되고 있었습니다.
그리고 8장에서 서비스 라우팅에 대해 나오는 것을 볼 때 굳이 지금 더 찾아봐야 될 이유가 없을 것 같아 보류했습니다.

시행 착오 2 - 도커 컨테이너에서 localhost 를 쓰면 어떻게 될까?

기존 설정은 그대로 둔 채 docker 세팅만 완료한 후 기동 했을 때, 기동은 되었지만 유레카에서 보이지 않았습니다?
이상해서 로그를 보니 유레카의 url 을 찾지 못하고 있었습니다!

관련 자료를 찾고 다시 생각해보니 당연한 것이었습니다.
docker 는 컨테이너 단위로 동작함으로 port 만으로는 접근이 불가능합니다!

찾아보니 host 의 ip 에 접근할 수 있는 방법이 있어 설정을 바꾸니 정상 접근되었습니다.

# licensing-service 
# application.yml
eureka:
  instance:
    appname: licensing-service
    prefer-ip-address: true
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      # defaultZone: http://localhost:8761/eureka/ # localhost 기동시
      defaultZone: http://host.docker.internal:8761/eureka/ # docker 기동시

환경 변수 관리 by Dockerfile

책에서는 Spring Cloud Config 의 장점을 말합니다.
하지만 저는 강한 필요성을 느끼지 못했기에 Dockerfile 로 접근하였습니다.

서비스와 config 를 분리할 수 있다.

# application.yml
server:
  port: ${SERVER_PORT}
  

# Dockerfile
FROM openjdk:17-jdk-slim-buster
ENV SERVER_PORT=8080 # 환경 변수 주입
ARG JAR_FILE=/licensing-service/build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

제가 가장 좋아하는 방식으로 Dockerfile 을 활용하여 환경 변수를 관리합니다.
dev, stg, prod 별로 Dockerfile 을 관리할 수도 있고, 작은 프로젝트에서는 서비스 안에 둘 수도 있습니다.

평소에는 설정 정보만 모아두는 git repository 를 운영합니다.
그리고 배포 스크립트 작성 시 (git action) 서비스에 해당하는 Dockerfile 을 가져와 실행할 수 있습니다.

개인적으로 사이드 프로젝트할 때는 배포에 elastic beanstalk 를 활용합니다.
elastic beanstalk 을 활용하면 AWS 에서 안전하게 환경 변수를 관리할 수 있어 참 편했습니다.

사용해보지는 않았지만 AWS Systems Manager, Secrets Manager 역시 관련된 솔루션으로 알고 있습니다.

서비스 인터페이스로의 접근 방식을 추상화할 수 있다.

# application.yml
spring:
  datasource:
    url: ${JDBC_URL:jdbc:h2:mem:testdb}
    driverClassName: org.h2.Driver
    username: ${JDBC_USERNAME:sa}
    password: ${JDBC_PASSWORD:}

이것 역시 Dockerfile 을 통해 관리할 수 있습니다.
기본 값을 활용하면 local 기동시 편하고 안전해 유용하게 사용하고 있습니다.

config 를 중앙 관리할 수 있다.

별도의 git repository 에 Dockerfile 을 관리하는 방법으로 대체할 수 있습니다.
이력 관리도 돼서 유용합니다.

config 를 변경 감지할 수 있다.

이것은 불가능합니다.

하지만 개인적인 경험으로 볼 때 config 가 바뀌면 코드의 변경은 필연적이었습니다.
(네트워크 설정이 바뀔 때는 코드의 변경이 없어도 되지만, 그런 경우는 AWS 의 영역이었습니다.)
그렇기 때문에 변경 감지가 저에게는 그다지 유용한 기능으로 와닿지 않았습니다.

마치며

이번 Phase 를 진행하면서 전 회사 생각이 많이 났습니다.

전 회사에서는 docker 를 적극적으로 쓰긴 했지만, 대부분 팀장님이 세팅한 것을 받아쓰기만 했었습니다.

하지만 이번에 docker 를 세팅해보면서 이렇게 좋고 편한 걸 왜 그동안 안쓴거지? 라는 생각이 많이 들었습니다.
이미 현대의 배포는 모두 수평 확장을 기반하고 있고 컨테이너 기반으로 움직이기에 유용할 것 같습니다.
좀 더 잘 쓸 수 있도록 공부해야겠습니다!

config 에 대해서도 그렇습니다.

Dockerfile 로 관리되긴 했지만 서비스와 같은 repository 에 있었기에 보안 지적을 받았기에, s3 로 이관하고 배포 스크립트에서 가져와 활용하는 것을 지원했었습니다.
그때도 말한 내용이지만 s3 로 이관되면 이력 관리도 힘들어지고, 어차피 private repository 가 털린 상황이면 s3 도 위험하긴 마찬가지다. 라고 생각합니다. 별도의 git repository 로 이관하는 것 까지도 말했지만.. 결국은 s3 로 결정된 슬픈 기억이 떠올랐습니다. ~~보안은 참 어렵네요.~~

spring cloud config 가 좋은 기술인 건 분명하지만, 아직 저에게는 와닿지 않고 있습니다.
복잡도가 높아져 꼭 도입해야만 하는 시점이 오면 좋겠다는 생각이 들었습니다.

스프링 마이크로서비스 코딩 공작소 (1)

Hyunec — Sun, 2 Oct 2022 01:54:45 +0900

GitHub - Hyune-s-lab/optima-growth: 스프링 마이크로서비스 코딩 공작소

스프링 마이크로서비스 코딩 공작소. Contribute to Hyune-s-lab/optima-growth development by creating an account on GitHub.

github.com

Phase 1
3. 스프링 부트로 마이크로서비스 구축하기
4. 도커
이 글입니다.

Phase 2
5. 스프링 클라우드 컨피그 서버로 구성 관리
6. 서비스 디스커버리
https://hyune-c.tistory.com/54

새로 입사한 회사는 제가 생각한 것보다 훨씬 서비스 구분이 많았습니다.
솔직히 이렇게까지 세분화 해야되나? 라는 생각이 들 정도였습니다.
마이크로서비스는 잘 쓰면 높은 생산성과 장애 격리를 가져갈 수 있지만, 높은 설계/운영 난이도와 흐름 추적이 어렵기 때문입니다.
이 문제 때문에 전 회사에서는 api, batch 딱 2개의 서버만 운영하기도 했습니다.
그리고 굳이 바꾸려고 하지도 않았습니다. 스테이지와 어울리는 아키텍처였기 때문이죠.

하지만 전부터 공부하고 싶었던 마이크로서비스이기에 책을 한 권 따라가 보면서 기록해봅니다.
책에서는 java 11 과 maven 을 사용하지만, 이왕이면 최신으로! kotlin 과 gradle 로 따라가 봅니다.

이 시리즈는 책일 읽어가며 조금씩 작성됩니다.
어쩌면 책을 다 읽는 시점에는 지금의 생각과 달라질 수도 있겠네요. ㅎㅎ

필자의 배경 지식은 아래와 같습니다.

- 마이크로서비스의 이론만 조금 알고 있다.
- ~~간소화된~~ Saga Orchestration 을 구현해봤다.
- kotlin 연습만 해봤다. 비즈니스 개발 X
- 이미 구성된 Docker 환경을 사용/운영만 해봤다.

licensing-service 구현

라이센스 발급, 수정, 삭제를 위한 REST API 를 만들었습니다.
하지만 책과는 달리 국제화도 적용하지 않았고, 너무 쉽기에 따로 설명하지 않습니다.

docker-compose & boot script

알면 정말 쉽고 유용하지만, 모르면 손도 못 대는 docker 입니다.
전 회사에서는 팀장님이 구성한 세팅을 사용만 했지만 이제는 조금씩 알려고 합니다.

Dockerfile

# java 17을 사용합니다.
FROM openjdk:17-jdk-slim-buster
# build 를 통해 생성되는 jar 파일 경로를 JAR_FILE 변수를 지정합니다. 
ARG JAR_FILE=licensing-service/build/libs/*.jar
# jar 파일을 복사해 옵니다.
COPY ${JAR_FILE} app.jar
# 실행 합니다.
ENTRYPOINT ["java","-jar","/app.jar"]

docker 는 image 기반으로 작동합니다.
Dockerfile 은 이 image 를 만들기 위한 환경 파일이라고 할 수 있습니다.

docker-compose.yml

version: "3"
services:
  license-service:
    image: license-service
    ports:
      - "8080:8080"

관련 설정을 매번 스크립트로 칠 필요 없이 yml 로 설정할 수 있습니다.
특히 여러 개의 서비스를 띄울 때 유용합니다.

run.sh

# licensing-service
cd licensing-service
./gradlew bootjar
cd ..

docker build . --tag license-service
docker-compose up

docker 를 띄우는 일련의 과정을 편하게 하기 위한 script 입니다.
git action 등을 사용할 때 활용하면 편합니다.

./run.sh

겨우 하나의 command 로 빌드부터 부팅에 성공했습니다!

생성된 image 를 보고 싶다면 확인해볼 수도 있습니다.

서비스 라우팅 & 서비스 디스커버리

처음 마이크로서비스를 접했을 때, 가장 크게 든 의문은 2개였습니다.

내부 서비스 간에 어떻게 인증/인가를 하는 거지?
서비스간 통신이 필요한 유스 케이스는 어떻게 처리하지?

이제는 실무를 하고 공부를 하면서 조금은 답이 생겼기에, 책의 내용과 함께 좀 더 얘기해보려고 합니다.

서비스 라우팅 (API 게이트웨이)

모놀리식 아키텍처에서는 접근 포인트가 단일 서버이기에 라우팅의 필요성이 낮았습니다.
과거에는 웹서버가 분리되기도 했지만, 현대에는 AWS 에서 ALB, Shield 등의 솔루션을 제공해주면서 분리된 이유도 있습니다.
하지만 마이크로서비스에서의 API 게이트웨이는 한 단계 더 나아갑니다.

책의 그림에는 인증에 대한 영역만 있지만, 전 회사에서는 SSO 를 고려한 인가까지를 구상했었습니다.
물론 인가까지 고려한다면 화면번호나 도메인 등의 서비스 디펜던시가 생길 수 있습니다.
하지만 각 서비스에서는 인가에 대한 부담을 덜 수 있어 더 좋은 아키텍처라고 생각합니다. (AWS IAM)

혹자는 서비스 간의 통신 시간을 고민합니다.
하지만 API 게이트웨이 이후는 private VPC 로 묶고 gRPC 등의 통신방식 변경으로 해결할 수 있다고 생각합니다.
현대의 개발은 더 많은 개발자가 더 많은 서비스를 병렬적으로 개발하는 것이 더 중요하기 때문입니다.

마지막으로 API 게이트웨이는 필연적으로 이 시스템에서 가장 많은 트래픽을 받게 되는 서비스입니다.
따라서 이벤트와 같이 일회성이거나 순간적 트랙픽이 몰리는 서비스는 분리하는 것도 좋다고 생각합니다.

서비스 디스커버리 (유레카)

이미 인증/인가가 끝난 요청을 포팅만 하는 쉬운 서비스라고 볼 수도 있지만, 헬스 체크와 서킷 브레이커의 아이디어가 필요할 것 같습니다. 그리고 비교적 자주 바뀌고 추가되는 개념인 end-point 를 유기적으로 관리할 수 있는 방법도 궁금해졌습니다.

마치며

첫 번째 글이라서 조금 짧습니다.
그래서 쓸까 말까 고민했지만, 하나의 큰 글보다 여러 개의 작은 글이 더 가치 있다고 생각하는 요즘입니다.

그리고 아키텍처를 고민하는 것은 항상 재미있다고 느끼는 요즘입니다.

[트러블 슈팅] ECS 클러스터 안의 서비스간 네트워크 연결 불가

Hyunec — Sat, 24 Sep 2022 12:57:57 +0900

글을 시작하기 전에 짧게 배경을 설명합니다.

필자의 인프라 지식과 경험은 아래와 같습니다.

- [On-premise] 서버 이중화 구성 & 운영 경험 O
- [AWS] EC2 기반의 Elastic Beanstalk 구성 & 운영 경험 O
- [AWS] ECS 운영 경험 O EKS X
- [AWS] VPC, 보안그룹, 인바운드 규칙에 대한 이해
- Docker 에 대한 이해
- MSA 개발에 대한 이해 O MSA 인프라에 대한 이해 X
- 그리고 이 정도로 거대한 규모의 인프라는 처음 만져봄

저는 9/1 일 신생 PG 회사로 이직하면서 모기업의 승인&정산 업무를 배정받았고, 이전 담당자는 퇴사가 예정되어 있었습니다. ~~이 글을 쓰는 시점에 이미 퇴사하신~~
승인/정산은 어느 회사에서나 가장 민감한 도메인 중 하나이고, 그 중에서도 본사의 트래픽은 업계 탑 이었습니다.
하지만 외주에 개발을 의존하고 있었고, 전임자는 팀장급의 도메인 지식에 보안 업무까지 할 정도로 인프라 실력자이신 분이었기에 상당한 부담이 되었습니다.

이슈의 시작

본사의 정산 시스템 어드민을 통해 정산 마감한 데이터가 필자 회사의 정산 시스템의 어드민에서는 보이지 않는다.

처음 CS 가 들어왔을 때는 어디 서버를 말하는 것인지도 모르겠고, 내가 AWS 권한이 있긴 한가? 조차 몰랐습니다.
저는 이럴 때 일단 업무 흐름도를 그립니다. 이하의 글에서는 접두사로 시스템을 구분합니다.
본사 정산 시스템 settlement / 필자 회사의 정산 시스템 ksettlement

그림을 그리고나니 확인할 포인트가 보이기 시작했습니다.

settlement-scheduler 에서 ksettlement-interface 로 signal 이 전송되었는가?

본사의 정산 마감 처리는 성공 했습니다. 따라서 db 기록은 남았을 것이라고 생각했고 정상이었습니다.
서버의 전송 기록을 확인해야되는데 아쉽게도 datadog 과 같은 모니터링 툴이 설치되어 있지 않아 cloudwatch 로 봐야 했습니다.

개발 소스 분석을 통해 로깅을 남기는 부분을 확인하고, settlement-scheduler 에서 signal 전송 성공 로그를 확인했습니다.

ksettlement-interface 에서 settlement-interface 를 통해 데이터를 가져왔는가?

실패 로그를 찾았습니다! 이것을 통해 문제를 추정할 수 있었습니다.

ksettlement-interface 와 settlement-interface 구간에 문제가 있다.
로깅 간격이 매우 짧은 것을 볼 때 네트워크 이슈가 의심된다.

하지만 이상한 점도 있었습니다.

settlement-scheduler 는 왜 성공으로 기록한거지?
settlement-interface 로 전달했다는 것만으로 역할을 다 한 것인가?
그렇다면 settlement-interface 는 왜 재시도를 하지 않은거지?
choreography 패턴이라고 보기에는 예외 처리/복구 전략이 너무 빈약하지 않나..?

추가 확인 과정에서 알게 되었지만 개발단의 버그가 있었습니다.

네트워크 이슈는 특정 에러코드로 기록하고, 재시도 대상에서 제외합니다.
~~저는 네트워크 이슈도 재시도 해야된다고 생각합니다.~~
실패한 트랜잭션임에도 불구하고 settlement-scheduler 는 정상 건으로 기록하는 버그가 있었습니다.

어쨋든 네트워크 이슈도 확인해야 될 것 같습니다.

보안을 위해 많은 정보를 가렸지만 컨테이너 이름이 다르고, VPC/서브넷/보안 그룹은 모두 같음을 확인할 수 있습니다.

사실 여기까지 보고 네트워크도 문제 없네 라고 생각했습니다.
하지만 ECS 와 Fargate 에 대한 이해가 부족하니 확신이 없어 좀 더 찾아보고 있었습니다.
그러던 중 운 좋게도 오늘부터 메가존 엔지니어 분들이 상주 지원을 한다는 사실을 떠올리고 바로 물어보러 갔습니다.

서로 다른 서비스는 서로 다른 fargate 에 올라가 있는 것이다.
따라서 보안그룹에서 자기 자신을 호출하는 인바운드 규칙이 있어야 한다.

저 같은 경우가 종종 있는지 바로 눈치를 채시더라구요..!
다시 확인해보니 8080 의 인바운드 규칙이 있긴 하지만 211 대역인 것을 보면 테스트를 위해 임시 등록한 것 같습니다.
~~분명히 이 부분도 봤다고 생각했는데 포트만 보고 간과했습니다.. ㅠ~~

보안그룹에 8080 포트를 인바운드 규칙으로 추가하고 이슈를 해결했습니다!

마치며

중간이 많이 생략되었지만 처음에는 prod 환경이기에 네트워크를 의심하지 않았고, 완전히 다른 흐름을 보는 실수를 하기도 했습니다. ECS 지식이 부족했기에 중요한 포인트를 찾지 못해 헤맨 것도 있구요.
해결하고 나니 창피할 정도로 쉽고 당연한 것이었네요.

기성 대기업이었다면 담당자가 따로 있었고 관련 확인이 완전히 위임 됩니다.
업무의 분리와 집중이라는 관점에서는 좋지만, 상대적으로 느리고 전체 업무 흐름에 대한 이해도가 떨어지게 됩니다.

지금 제가 다니는 회사는 트래픽은 업계 상위권이지만 스타트업의 성격으로 일하고 있습니다.
그렇기에 구성원에게도 AWS 권한이 있고, 다행히도 인프라 기본 지식이 있었기에 직접 트러블 슈팅할 수 있었습니다.
들어온지 얼마 안되었음에도 이렇게 전체 흐름에 관련된 이슈를 처리할 수 있어서 보람차고 꽤 재미있는 경험이었습니다!
~~devops 님.. 어서 와주세요.. 제발..~~

요즘 애들은 문해력이 낮아진걸까?

Hyunec — Sat, 10 Sep 2022 00:31:17 +0900

09:42 ~ 13:00

소위 요즘 학생들이 단어를 모른다, 문해력이 떨어진다라고 말하고 이것이 큰 문제인 것으로 알려지고 있다.
하지만 사실은 영상 독해력이 높아지는 등 이전 세대와 다른 양상의 패러다임이 생기고 있는 것이다.

기술/업무와는 전혀 관계 없는 영상처럼 보이지만 느낀 것이 많습니다.

시대는 지속적으로 바뀌어 가고 우리가 만드는 서비스를 소비하는 층은 점점 어리고 새로워져 갑니다.
하지만 우리는 비즈니스를 하는 사람들이기에 너무나도 어렵지만 패러다임의 변화를 캐치할 수 있어야 하고,
최소한 변화를 인정하고 수용하는 자세를 가져야 된다고 생각합니다.

잘못된 분석의 사례

2차 대전 중, 미 해군분석센터 연구원들은 임무를 마치고 돌아온 전투기들의 총탄 자국에 대해 연구하였다.
그 연구 결과는, 비행기의 총탄 자국이 가장 많은 부분을 더 튼튼하게 보강하여, 적의 공격을 받더라도 전투기의 손실을 최소화할 것을 권유하는 보고서를 남겼다.

그런데 수학자로서 통계연구팀에 속해있던 에이브러햄 왈드(Abrahan Wald)는 전혀 다른 의견을 제시했다.
그는 해군분석센터의 연구가 살아 돌아온 전투기만을 대상으로 하였다는 점을 지적했다.
격추된 전투기는 돌아올 수 없으니, 외상 부위를 평가할 때 반영되지 못했다는 것이다.

당초의 보고서에 따르면 총탄을 많이 맞은 부분을 보강하여야 한다.
그러나, 실제로는 전투기가 그렇게 총탄을 많이 맞았음에도 무사히 돌아올 수 있었으므로, 해당 부분에 대해서는 보강의 필요가 없다. 오히려 귀환한 비행기의 총탄 맞지 않은 부분이 보강의 필요성이 더 크다.
그 부분을 타격 당한 전투기는 돌아오지 못했기 때문이다.

생존자 편향의 오류 Survivorship Bias

잘못된 분석군의 선정으로 인해 문제의 본질을 파악하지 못하는 오류를 말하고 있습니다.

직관만 믿고 까불었다가 망한 PM의 사연

안녕하세요, 검색 프로덕트 매니저 Demi예요.

medium.com

마찬가지로 경험과 데이터에 기반하지 못한 직관은 위험합니다.

요즘 핫한 회사들은 소위 PO 라는 말을 많이 사용합니다.

PO 라 함은 자신이 속한 프로덕트에 무한한 책임감을 가지고 일해야 됩니다.
그리고 그 안에서 남들과는 다른 혁신을 가져올 수 있기를 기대합니다.
과거에는 이것들이 기획자에게만 요구되었다면 지금은 개발자에게도 요구되고 있습니다.

말이 좋아 혁신이지 정말정말 어려운 일입니다.

돌아보면 실무에서도 단편적인 결과만 보고 실수한 적이 많습니다. 많은 반성이 됩니다.
올바른 데이터와 선정과 문제의 본질을 볼 수 있는 능력을 길러야 되겠습니다.

Repository 가볍게 관리하기

Hyunec — Mon, 1 Aug 2022 14:05:38 +0900

GitHub - Hyune-c/blogcode-repository-di: Repository 의존성을 가볍게 관리하기

Repository 의존성을 가볍게 관리하기. Contribute to Hyune-c/blogcode-repository-di development by creating an account on GitHub.

github.com

작고 단순한 피쳐를 개발할 때는 크게 신경 쓰지 않던 것들이 공부하고 실무를 할수록 의문이 생기곤 합니다.
그중 하나인 Repository를 개발하면서 느낀 점을 기록해봅니다.

도메인 로직과 영속성 영역의 경계는 어디일까?
어떻게 하면 인적 실수를 줄이고 생산성을 높일 수 있을까?

지금의 회사에서 개발하는 애플리케이션은

B2B 성격이기에 그리드 형태의 조회 로직이 많습니다.
그렇기에 개발 편의성을 위해 포기한 부분이 있고, 그중 하나가 Repository의 거대함입니다.

도메인 로직이 영속성 영역에 위치하고, 거대하고 복잡한 쿼리로 구현되어 있습니다.
- 4천 줄 이상의 클래스도 존재하며 로직 이해가 힘듭니다.
- DB의 용어를 그대로 사용해 가독성이 떨어집니다.

v1 - 기존의 실무에서 사용되던 방법

@Repository
public interface V1StudentRepository extends
		JpaRepository<Student, Long>,
		V1StudentQuerydslRepository,
		V1StudentJooqRepository {

	// 이름으로 조회하는 경우 JpaRepository를 활용합니다.
	Student getByName(final String name);
}

interface V1StudentJooqRepository {

	// 이름과 나이로 조회하는 경우 Jooq를 활용합니다.
	Student getByNameAndAge(String name, Integer age);
}

interface V1StudentQuerydslRepository {

	// 나이와 주소로 조회하는 경우 Querydsl을 활용합니다.
	Student getByAgeAndAdress(Integer age, String adress);
}

쉬운 기능은 JpaRepository를 통해 생성되는 메서드를 활용합니다.
일부 복잡한 쿼리는 Jooq or Querydsl을 활용합니다.

v2 - 복잡한 조회만 하고 싶습니다

복잡한 조회 쿼리만 필요한 경우에는 Jooq와 Querydsl만 활용하고 싶습니다.
JpaRepository를 활용하면 사용되지 않는 CRUD 메서드가 다수 생성되기 때문입니다.

@Repository
public interface V2StudentRepository extends
		V2StudentQuerydslRepository,
		V2StudentJooqRepository {

}

interface V2StudentJooqRepository { ... }
interface V2StudentQuerydslRepository { ... }

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.example.blogcoderepositorydi.v2.repository.V2StudentRepository' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}

JpaRepository를 빼면 되겠지라고 단순하게 접근했지만, v2는 작동하지 않습니다.
V2StudentRepository는 interface이기 때문에 DI를 할 수 있는 구현체가 존재하지 않기 때문입니다.

Spring Data JPA 는 어떻게 interface 만으로도 동작할까? (feat. reflection, proxy)

Spring Data JPA를 공부하면서 궁금한 것이 있었습니다. public interface MemberRepository extends JpaRepository { List findAllByName(String name); } 위와 같이 MemberRepository는 인터페이스고, @Reposito..

pingpongdev.tistory.com

v3 - v2를 보완하기 위해 기본 구현체를 만듭니다

public interface V3StudentRepository {

 Student getByNameAndAge(String name, Integer age);
 Student getByAgeAndAdress(Integer age, String adress);
}

@RequiredArgsConstructor
@Repository
public class V3StudentRepositoryImpl implements V3StudentRepository {

	private final V3StudentJooqRepository v3StudentJooqRepository;
	private final V3StudentQuerydslRepository v3StudentQuerydslRepository;

	@Override
	public Student getByNameAndAge(final String name, final Integer age) {
		return v3StudentJooqRepository.getByNameAndAge(name, age);
	}

	@Override
	public Student getByAgeAndAdress(final Integer age, final String adress) {
		return v3StudentQuerydslRepository.getByAgeAndAdress(age, adress);
	}
}

interface V3StudentJooqRepository { ... }
interface V3StudentQuerydslRepository { ... }

interface mixin 대신 delegate 패턴을 활용합니다.
기능이 변경되어도 사용자 코드에 영향이 없는 느슨한 결합을 만족하지만, 코드 양이 늘어난 것이 조금 불편합니다.

v4 - Spring Data Repository로 기본 구현체를 만듭니다

public interface V4StudentRepository extends
		// org.springframework.data.repository.Repository
		Repository<Student, Long>, 
		V4StudentQuerydslRepository,
		V4StudentJooqRepository {

}

interface V4StudentJooqRepository { ... }
interface V4StudentQuerydslRepository { ... }

v3에 비해 코드 양이 줄어듭니다.
기능이 늘어나도 mixin Repository에만 수정이 일어납니다.
하지만 Repository<>는 스프링 프레임워크에 의존성을 가집니다.

혹자는 도메인 로직에서 프레임워크 의존성을 완전히 배제해야 된다고 말합니다.
하지만 변경의 가능성이 매우 낮고, 개발 편의성이 명백히 향상된다면 팀의 예외로 정할 수 있다고 생각합니다.
~~스프링 없는 백엔드 개발이라니.. 끔찍하군요.~~

v5는 조금 더 학습 후 별도의 글을 작성 예정입니다. 지금의 내용은 참고만 해주세요.

v5 - 인터페이스와 구현체를 패키지로 분리한 구조

// v5.domain
public interface V5StudentRepository {

	Student getByNameAndAge(String name, Integer age);
	Student getByAgeAndAdress(Integer age, String adress);
}


// v5.infrastructure
public interface V5StudentJpaDao extends
		V5StudentRepository,
		Repository<Student, Long>,
		V5StudentJooqDao,
		V5StudentQuerydslDao {

}

interface V5StudentJooqDao { ... }
interface V5StudentQuerydslDao { ... }

~~Repository는 객체의 상태를 관리하는 저장소로서 domain 레이어에 위치합니다.~~
~~Dao는 영속성 상태를 관리하는 구현체로서 infrastructure 레이어에 위치합니다.~~

~~DDD의 아이디어를 기반으로, 레이어를 엄격하게 구분해서 유연하고 모듈화에 강합니다.~~
~~하지만 러닝 커브가 높고 개발자마다 해석이 조금씩 다르기에 팀에 실제로 적용하기까지는 꽤 어려움이 있습니다.~~

Repository와 Dao의 차이점.

Repository와 Dao의 차이점에 대한 논쟁은 이전부터 끝없이 진행되어 왔다. 이번 포스팅에서는 Repository와 Dao의 차이에 대한 나의 생각을 논해보록한다. 필자가 생각하기에 Dao와 Repository의 차이점을

bperhaps.tistory.com

DAO vs Repository Patterns | Baeldung

Understand the difference between the DAO and Repository patterns with a Java example.

www.baeldung.com

여기까지가 고민을 해결하기 위해 공부한 이론입니다.
하지만 실무에서의 개선은 조금 다릅니다.

실무에서의 개선

public interface BizSlipRepositoryJooq {

	/**
	 * [손익현황] 손익현황 조회
	 */
	List<ProfitAndLossStatus> findProfitAndLossStatus(ProfitAndLossStatusFilterInput input);

	... // 30개가 넘는 public 메서드가 존재함
}

@Repository
public class BizSlipRepositoryJooqImpl implements BizSlipRepositoryJooq {
	@Override
	public List<ProfitAndLossStatus> findProfitAndLossStatus(final ProfitAndLossStatusFilterInput input) { ... }
    
    ... // private 메서드를 포함하여 총 4000 line의 구현 클래스
}

BizSlipRepositoryJooq는 Jooq로 복잡한 조회 쿼리를 처리하기 위해 만들어진 interface입니다.
하지만 30개가 넘는 public 메서드를 구현하기 위해 4000 line의 구현 클래스가 존재합니다.
로직을 이해하는 것부터 개선과 기능 수정을 시도하는 것조차도 너무 힘든 일입니다.

// before
public interface SlipRepository extends JpaRepository<BizSlip, Long>, BizSlipRepositoryCustom, BizSlipRepositoryJooq {
	...	
}


// after
public interface BizSlipRepository extends
		JpaRepository<BizSlip, Long>,
		BizSlipRepositoryCustom,
		BizSlipFindProfitAndLossStatusRepositoryJooq,
		BizSlipRepositoryJooq {
	...
}

public interface BizSlipFindProfitAndLossStatusRepositoryJooq {

	/**
	 * [손익현황] 손익현황 조회
	 */
	List<ProfitAndLossStatus> findProfitAndLossStatus(ProfitAndLossStatusFilterInput input);
}

// 대상 메서드만 단일 interface로 분리
@Repository
public class BizSlipFindProfitAndLossStatusRepositoryJooqImpl implements BizSlipFindProfitAndLossStatusRepositoryJooq {

	@Override
	public List<ProfitAndLossStatus> findProfitAndLossStatus(final ProfitAndLossStatusFilterInput input) { ... }
}

대상 메서드만 단일 interface로 분리했습니다.

대상 로직이 하나의 클래스로 응집되었습니다.
4000 line의 거대 Impl에서 300 line을 분리해 가독성을 높였습니다.
로직의 수정 없이 단순히 클래스만을 분리했기에 가볍게 접근할 수 있습니다.

하지만 이 방식은 부족한 부분도 존재합니다.

기능의 개수만큼 클래스가 생기고 네이밍의 어려움이 생깁니다.
접근 제한자 활용이 힘듭니다.

마치며

장황하게 설명한 이론과는 다르게 실무는 협업이기에 충분한 의도와 근거를 가지고 점진적인 개선을 해야 됩니다.
그래서 실무에서는 가독성 향상을 위한 Repository 분리만을 선택했고 가볍게 접근할 수 있었습니다.
실무에서의 개선은 이렇게 접근해야 된다고 생각합니다.

마찬가지로 DDD가 좋다고 하여 v5의 구조를 바로 적용해서는 안됩니다.
중요한 것은 레거시와 생산성, 러닝 커브를 고려한 지속적인 개선을 시도할 수 있는 사이클을 만드는 것 입니다.
이 관점에서 지금의 회사에는 v4의 구조가 적절하다고 생각하기에 이 방향으로 개선해 나갈 생각입니다.

토스 SLASH 22 를 보고..

Hyunec — Mon, 11 Jul 2022 00:12:22 +0900

토스 SLASH 22를 보고 관심 있는 주제인 Server/DevOps 위주로 정리했습니다.

소위 말하는 네카라쿠배의 컨퍼런스를 보면서 느끼는 것 중 하나는 대용량/동시성 처리를 위해서는 아키텍처와 생각의 패러다임 전환이 필요하고, 인프라의 재설계 및 운영 방법에 대한 고민도 필수적이라는 것입니다.
그리고 필연적으로 높은 운영 난이도가 요구되기에, 과도기의 회사에서는 어디까지를 트레이드 오프 해야 할지 항상 고민됩니다.

지속 성장 가능한 코드를 만들어가는 방법

패키지를 잘 관리함으로써 코드의 응집성을 높일 수 있습니다.
- import를 정리하는 것 또한 클린 코드의 영역입니다.

레이어 참조는 한 방향으로 이루어져야 하며, 레이어 역류와 레이어 건너뛰기는 금지됩니다.
멀티 모듈을 통해 레이어를 격리시킬 수 있습니다.

지금은 레이어 역류의 위험성을 알고 있지만, 처음에는 잘못된 줄도 모르고 반복하던 실수 중 하나입니다.
이를 막기 위해 모듈을 분리하거나 레이어 간의 메시지 전달을 엄격히 분리된 dto로 하는 방법 등이 있지만, 보일러 플레이트가 많아지고 지금의 규모에서 고민해야 될 문제인가? 를 고민하게 만드는 주제이기도 합니다.

코드 리뷰어 활동을 하면서 남긴 글을 공유합니다.
https://hyune.gitbook.io/hyune-wiki/and/codesquad/22reviewer/undefined/service-dto

토스뱅크의 완전히 새로운 대출 시스템

MSA 아키텍처 도입
flyway를 통한 DB 스키마 관리
- ddl-auto 옵션을 validate로 설정하여 prod 배포 시 2차 확인.
각각의 대외기관은 TPS가 다르기에 독립적인 유량 제어를 위해 카프카와 파이프라인을 활용합니다.
- 정확한 TPS 측정을 위해 API 통신은 동기로 처리합니다.
resdis에 지표를 저장하고, rdb에 분 단위의 통계를 저장하는 방법으로 유동적인 서킷 브레이커를 구현했습니다.
- 서킷 브레이커로도 감당되지 않는 경우 대기열을 활용합니다.

유량 제어와 서킷 브레이커에 대해 다시 한번 정리할 수 있었습니다.
특히 대기열까지 활용하는 것은 생각하지 못했는데 좋은 인사이트를 얻었습니다.

왜 은행은 무한스크롤이 안되나요

계정계는 고객의 거래 데이터를 다루는 영역으로 높은 신뢰도가 필요합니다.
채널계는 기능 요청의 포인트로 계정계에 비해서는 상대적으로 낮은 신뢰도를 가집니다.

토스에서는 계정계의 정보를 채널계에서도 가지고 있는 방식을 선택했습니다.
예외 처리 흐름을 상정하고 카프카를 활용해 거래내역을 동기화했습니다.

요약

빠른 거래내역 조회를 위해 채널계에 거래내역을 적재
채널계에서 적재된 거래내역을 이용해 중복 송금 방지
카프카를 이용해 계정계와 채널계 사이의 거래내역을 동기화
만약의 경우를 대비해서 수동 동기화 제공

최근 회사에서도 비슷한 성격의 업무에 대해 고민하고 있기에 재미있게 봤습니다.
다행히도 제가 생각해낸 아이디어와 영상에서 말하는 계정계 원장의 정보를 채널계에서도 가지고 있는다가 같아 재미있었습니다.

토스증권 실시간 시세 적용기

API Polling 방식으로 실시간 시세를 구현했지만, 좀 더 좋은 사용자 경험을 위해 WebSocket 방식을 선택.
- 양방향 통신이 아닌 단방향만 필요하다면 SSE(Server Sent Event)도 좋은 선택입니다.
  (방화벽 등 보안 설정 용이)
- WebSocket 방식이 지연되는 경우 API Polling을 사용하는 방법으로 구축 초기에 아주 유용하게 사용되습니다.

트러블 슈팅

Connection 부하 분산을 위해 Round Robin 방식과 Least Connection 방식을 혼합해서 사용.
WebSocket 사용 시 비정상 종료에 대한 예외 처리를 잘해야 합니다.
대용량 트래픽 처리 시 방화벽과 보안 장비의 처리량도 고려해야 합니다.
스케일 아웃의 유연함을 위해 온프레미스 환경에서 클라우드 환경으로의 이전을 고려하고 있습니다.

처음에는 API Polling 방식으로 접근했다는 것에 놀랐고, 이미 완성된 기능이 있음에도 불구하고 좋은 사용자 경험을 위해 WebSocket 방식으로 재 구현했다는 점에서 두 번 놀랐습니다.
만약 내가 저 상황이라면 그렇게 선택할 수 있을까? 고민하게 됩니다.

애플 한 주가 고객에게 전달 되기까지

동시성을 다루기 위한 Lock 사용 방법

보편적인 락 구현은 DBMS에 락을 위한 테이블을 생성하고 트랜잭션 시작 시 테이블에 락을 잡습니다.
독립적인 DBMS를 사용하는 MSA 환경에서는 적절하지 않기에 Redis 기반의 분산 락을 설계했습니다.
만약의 상황을 위해 낙관적인 락을 추가로 구현했습니다.

해외 구간 네트워크 지연을 보완하기 위한 브로커 전략

매매 서버에서 고객의 요청을 받는 스레드와 브로커에게 요청하는 스레드를 분리하고 비동기 처리합니다.
브로커로의 요청을 멱등하게 구현하고, 재시도 주기를 적절하게 설정합니다.

브로커 의존성 격리하기

매매 서버에서 브로커로의 연결을 인터페이스로서 매매 요청 서버로 분리합니다.
- 이를 통해 도메인 로직은 매매 서버에 응집되고, 처리량과 스케일 아웃의 책임은 매매 요청 서버로 격리됩니다.
마찬가지의 이유로 체결 수신의 서버 또한 분리되어 있습니다.
체결 수신 서버는 매매 서버로 응답하기 전에 DB 기록을 함으로써 다양한 Fail Over 전략의 선택이 가능합니다.

동시성과 브로커는 최근 가장 관심 있는 주제이기에 아주 재미있게 봤습니다.
특히 브로커로의 접근을 스레드 단위로 분리하고, 매매 서버와 매매 요청 서버를 물리적으로 분리한 것이 인상적입니다.

Java Native Memory Leak 원인을 찾아서

개인적으로 Memory Leak에 관심이 있지만 제가 일하는 환경과는 조금 거리가 있는 주제이기에 정리하지는 않습니다.
하지만 글로만 봤었던 소스 변경 없이도 GC나 컴파일러 변경만으로도 튜닝이 가능하다는 것에 대한 실 사례를 보니 조금 신기했습니다.

번외로 Heap Dump 분석 툴인 VisualVM의 세팅과 분석한 기록을 남깁니다.
https://hyune.gitbook.io/hyune-wiki/framework-and-library/monitoring/visualvm

어떻게 안정적인 서비스를 빠르게, 자주 출시할 것인가?

MSA 환경에서의 복잡한 프로젝트 세팅 시간을 줄이기 위해 Boilerplate Project를 운영합니다.
- 사내 프로젝트의 세팅을 균일화하여 관리하였기에, 최근 log4j 취약점 이슈일 때도 일괄 수정 배포가 용이했습니다.
CI/CD는 yaml을 통해 관리하기 쉬운 GoCD와 Git Action을 활용합니다.
배포 시 쿠버네티스와 Istio를 통해 비율 단위의 트래픽 조절이 가능합니다.
MSA의 가장 큰 어려움 중 하나인 분산 추적 시스템을 자체 구현했고 Alert도 구현하였습니다.

익히 알고 있는 내용 위주였지만 빅테크의 인프라, CI/CD 관리는 새삼 대단하다고 느꼈습니다!
아쉬운 점은 서버 단위의 설정 관리 방법에 대한 얘기가 없었습니다.
(Spring Cloud Config Server 같은 것을 사용할까?)

번외로 현재 재직 중인 회사에서는 분산 추적 시스템을 Datadog으로 관리합니다.
https://hyune-c.tistory.com/entry/Datadog-%EC%97%90%EC%84%9C-GraphQL-%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81-%EB%A7%9B%EB%B3%B4%EA%B8%B0

INSERT INTO SELECT SHARED LOCK은 레코드 락으로 작동하는가? with MySql

Hyunec — Wed, 6 Jul 2022 20:09:17 +0900

회사에서 수기 작업 간 발생한 이슈를 해결하면서 회사 시니어님이 공유해주신 자료를 보고 이론으로 공부만 했던 것이 문득 궁금해져 테스트해 본 기록을 남깁니다.

환경

MySql 8.0
Datagrip
Transaction Mode - Manual

테스트 1

목표

Table 단위의 LOCK이 걸리는가? 아니면 ROW 단위의 LOCK이 걸리는가? - 레코드 락
특정 ROW에만 SHARED LOCK이 걸리고, 다른 ROW의 CRUD에는 영향이 없는가?
- SHARED LOCK - 읽기 가능. 수정/삭제 불가

초기 세팅

create table test1 (
    col1 int primary key auto_increment,
    col2 char(10)
);
create table test2 select * from test1 limit 0;

insert into test1 (col2) values ('aaa'),('bbb'),('ccc');

## 현재 걸린 lock 조회
select * from performance_schema.data_locks

시나리오

# Session 1
begin;

insert into test2
select *
from test1
where col1 = '1';

col1=1 S락 획득 시도
primaryKey=1 S락 획득 성공

# Session 2
update test1
set col2 = '1111'
where col1 = 2;

col1=2 X락 획득 시도
primaryKey=2 락이 존재하지 않았기에 X락 획득 성공

# Session 2
update test1
set col2 = '1111'
where col1 = 1;

col1=1 X락 획득 시도
하지만 Session 1 에서 S락을 걸고 있었기에 호환되지 않아 WAITING.

결과

락이 걸리지 않은 레코드에는 update가 가능하다.
즉 레코드락으로 작동하는 것을 확인할 수 있다.
S락이 걸린 레코드에 X락이 획득 요청이 들어오면 S락이 해제될 때까지 기다린다.
- S락과 X락은 호환되지 않기 때문이다. timeout, deadlock의 주범.

하지만..

정리하면서 최근 읽은 REAL MySQL의 잠금 파트가 생각나서 다시 읽어봤습니다.

이 테이블에 인덱스가 하나도 없다면 어떻게 될까?
이러한 경우에는 테이블을 풀 스캔 하면서 UPDATE 작업을 하는데,
이 과정에서 테이블에 있는 30여만 건의 모든 레코드를 잠그게 된다.
이것이 MySQL의 방식이며, MySQL에서 인덱스 설계가 중요한 이유 또한 이것이다.

- REAL MySQL 1권. 5.3.2 인덱스와 잠금 (172p)

이 내용을 읽고 앞의 테스트를 다시 보니 의문이 생겼습니다.
where 조건의 col1은 PK이기에 unique index로 이미 잡혀있어 단일 레코드 락이 걸립니다.
- 하지만 index가 없는 col2라면?
- col2에 non unique index를 걸고 조회한다면?

테스트 2

목표

index가 아닌 col2를 where 조건으로 실행하는 경우 락이 어떻게 잡히는가?

초기 세팅 동일

시나리오

# Session 1
begin;

insert into test2
select *
from test1
where col2 = 'bbb';

col2=bbb S락 획득 시도.
하지만 모든 레코드에 대해 S락 획득 성공.

# Session 2
update test1
set col2 = 'fff'
where col2 = 'ccc';

col2=ccc X락 획득 시도.
하지만 Session 1 에서 모든 레코드에 S락을 걸고 있기에 호환되지 않아 WAITING.

결과

index가 없다면 모든 레코드가 락에 걸린다.

테스트 3

목표

col2에 non unique index를 걸고 where 조건으로 실행하는 경우 락이 어떻게 잡히는가?

초기 세팅

create table test1
(
    col1 int primary key auto_increment,
    col2 char(10)
);

create table test2
select *
from test1
limit 0;

insert into test1 (col2)
values ('aaa'), ('aaa'),
       ('bbb'), ('bbb'),
       ('ccc'), ('ccc');

create index test1_col2_index on test1(col2); ## 인덱스 생성

시나리오

# Session 1
begin;

insert into test2
select *
from test1
where col2 = 'bbb';

col2=bbb S락 획득 시도.
primaryKey=3,4,5 S락 획득 성공.
col2는 non unique index이지만 primaryKey=3,4 S락 획득 성공.
primaryKey=5 S락이자 GAP락 획득.

# Session 2
update test1
set col2 = 'fff'
where col2 = 'ccc';

col2=ccc X락 획득 시도.
primaryKey=5,6 X락 획득 성공.
하지만 unique index 때와는 다르게 REC_NOT_GAP, GAP 락들이 추가로 획득됩니다.

# Session 2
update test1
set col2 = 'ggg'
where col2 = 'bbb';

col2=bbb X락 획득 시도.
하지만 Session 1에서 S락을 걸고 있기에 호환되지 않아 WAITING.

결과

테스트 1과 결과는 같지만 락이 걸리는 형태가 매우 다릅니다.

결론 요약

MySQL(InnoDB)에서 INSERT INTO SELECT SHARED LOCK은 index가 있는 경우에만 레코드 락으로 작동합니다.

non unique index의 경우 락이 걸리는 형태가 매우 다릅니다.
심지어 no index 인 경우는 전체 레코드 락으로 테이블 락과 같은 상태가 됩니다.

하지만 실무에서는 큰 문제가 없을 것으로 예상됩니다.

이 이슈는 일반적이지 않은 업무 흐름에서 수기 작업 간 조작을 잘못한 인적 실수입니다. (영업의 요청)
실무에서 사용되는 테이블과 대상 컬럼은 최소한 non unique index가 잡혀 있을 것으로 기대합니다.

아쉽게도 IS, IX, GAP Lock 등에 대해서는 좀 더 공부가 필요합니다.
관련되어 잘 정리되어 있는 블로그를 공유합니다.

Lock의 종류 (Shared Lock, Exclusive Lock, Record Lock, Gap Lock, Next-key Lock)

jaeseongdev.github.io

ErrorMessage를 관리하는 방법

Hyunec — Wed, 15 Jun 2022 02:29:16 +0900

GitHub - Hyune-c/blogcode-errormessage

Contribute to Hyune-c/blogcode-errormessage development by creating an account on GitHub.

github.com

HTTP status code는 3자리의 코드와 설명으로 표현됩니다.
하지만 실무에서는 더 많고 다양한 종류의 에러 표현을 위해 name, code, reason을 활용하곤 합니다.
그리고 간결함과 생산성을 위해 프로젝트 내에서도 code와 reason이 직관적으로 연결되기를 기대합니다.

STEP 1. Enum으로 관리하기

@Getter
@RequiredArgsConstructor
public enum Errorcode {

 NOT_EXIST_PRODUCT("1001", "대상 상품 없음"),
 OUT_OF_STOCK("1200", "상품 재고 없음"),
 UNKNOWN("9999", "알 수 없는 에러"),
 ;

 private final String code;
 private final String reason;
}


@Entity
public class Product {

 ...
 
 public void order(final Integer quantity) {
  if (this.quantity < quantity) {
   throw new ProductException(Errorcode.OUT_OF_STOCK);
  }

  this.quantity -= quantity;
 }
}


@RestControllerAdvice
public class ControllerAdvice {

 @ExceptionHandler(ProductException.class)
 @ResponseStatus(HttpStatus.BAD_REQUEST)
 protected ErrorResponse handleBusinessException(final ProductException ex) {
  return new ErrorResponse(ex.getErrorcode());
 }
}

장점

작은 프로젝트에 적합합니다.

단점

name, code 변경 시 배포가 필요합니다.
admin 개발이 필요한 경우 코드 중복이 발생합니다.
프로젝트 밖에서 전체 에러 목록을 알기 힘듭니다.
메시지 국제화가 어렵습니다.

구현 방법이 아주 쉬워 사이드 프로젝트를 할 때 많이 썼던 관리 방법이지만 단점이 꽤 있습니다.

STEP 2. MessageSource로 관리하기

@Getter
@RequiredArgsConstructor
public enum Errorcode {

 NOT_EXIST_PRODUCT("1001", "product.not_exist_product"),
 OUT_OF_STOCK("1200", "product.out_of_stock"),
 UNKNOWN("9999", "product.unknown"),
 ;

 private final String code;
 private final String propertiesCode;
 private String reason;

 @RequiredArgsConstructor
 @Component
 public static class ErrorreasonInjector {

  private final MessageSource messageSource;

  @Value("${application.locale}")
  private String locale;

  @PostConstruct
  public void postConstruct() {
   Arrays.stream(Errorcode.values())
     .forEach(errorcode -> errorcode.reason = messageSource.getMessage(errorcode.getPropertiesCode(), null, Locale.forLanguageTag(this.locale)));
  }
 }
}


// messages.properties
product.not_exist_product=대상 상품 없음
product.out_of_stock=상품 재고 없음
product.unknown=알 수 없는 에러

장점

작은 프로젝트에 적합합니다.
메시지 국제화가 용이합니다.

단점

name과 code 변경 시 배포가 필요합니다.
admin 개발이 필요한 경우 코드 중복이 발생합니다.
프로젝트 밖에서 전체 에러 목록을 알기 힘듭니다.
MessageSource는 Map 자료구조와 같이 key, value 한 쌍만을 지원합니다.

실무 코드와 인프런의 김영한님 스프링 MVC 2편 - 메시지, 국제화를 보고 구현했습니다.
하지만 여전히 STEP 1의 단점을 가지고 있으며, 에러 표현에 필요한 name, code, reason의 값을 보여주기 힘듭니다.

STEP 3. DB에서 가져오기

@Getter
@RequiredArgsConstructor
public enum Errorcode {

 NOT_EXIST_PRODUCT,
 OUT_OF_STOCK,
 UNKNOWN;

 private String code;
 private String reason;

 @RequiredArgsConstructor
 @Component
 public static class ErrorreasonInjector {

  private final ErrorcodeDataRepository repository;

  @Value("${application.locale}")
  private String locale;

  @PostConstruct
  public void postConstruct() {
   Arrays.stream(Errorcode.values())
     .forEach(errorcode ->
       repository.findByNameAndLocale(errorcode.name(), locale)
         .ifPresent(e -> {
            errorcode.code = e.getCode();
            errorcode.reason = e.getReason();
           }
         )
     );
  }
 }
}


// data.sql
insert into errorcode_data(locale, name, code, reason)
values ('ko', 'NOT_EXIST_PRODUCT', '1001', '대상 상품 없음'),
       ('ko', 'OUT_OF_STOCK', '1200', '상품 재고 없음'),
       ('ko', 'UNKNOWN', '9999', '알 수 없는 에러');

장점

name, code, reason을 모두 표현할 수 있습니다.
메시지 국제화가 용이합니다.
프로젝트 밖에서 전체 에러 목록을 알기 쉽습니다.

단점

name 변경시 배포가 필요합니다.
DB 관리가 필요합니다.

앞에서 문제로 있던 것들을 조합하여 DB를 통해 구현했습니다.
name은 의도적으로 프로젝트 내에 두어 직관성을 높였습니다.

코드로 구현하지는 않았지만 더 생각해볼 것도 있습니다.

EnumMap을 활용할 수 있습니다.
DB 검색을 하는 STEP 3에서는 캐시를 활용할 수 있습니다.
- 빠른 변경 반영을 위해 evict 정책, 백도어 API, 또는 pub/sub를 통한 갱신을 도입할 수 있습니다.
에러 메시지를 동적으로 관리하고 싶다면
- 메시지를 String.format() 형태로 만들고 CustomException을 만들 때 매개변수를 받을 수 있습니다.
- 또는 CustomException 생성 시 별도의 필드를 활용할 수도 있습니다.
완벽한 국제화는 BCP47 등 고려해야될 점이 더 많습니다.
백엔드는 code만 관리하고 사용자에게 노출되는 reason은 프론트엔드가 관리하게 하는 방법도 있습니다.

마치며

지금의 회사는 조금 다른 형태로 사용하고 있습니다.

// 에러코드만으로 예외를 throw
throw new CustomException("4012");

// Supplier를 통해 네이밍은 했지만 일괄 검색은 힘듬
public static final Supplier<CustomException> ERROR_SLIP_DTL_NOT_FOUND = CustomException.supply("4012");

String의 4자리 숫자 code를 MessageSource의 find code 값으로 활용하고 있습니다.
MessageSource 기술을 활용하고 있긴 애매한 부분이 있다고 생각합니다.

지금의 회사는 국제화를 고려하는 단계가 아닙니다.
code가 String이기에 type safe하지 않습니다.
프로젝트 내에서 직관적인 code - reason 매핑이 힘듭니다.
매핑을 위해서는 별도 관리되는 엑셀이나 DB를 직접 검색해야 합니다.

제가 선호하는 방식은 STEP 2와 STEP 3입니다.

에러 코드는 일반적인 도메인과 다른 성격을 가지고 있습니다.

보통 한번 만들어진 code는 변경되지 않습니다.
새로운 에러 유형이 생기면 새로운 code를 생성합니다.
반면 reason은 좀 더 구체화되거나 에러를 나누는 등 변경될 수 있습니다.

이 관점에서 볼 때 STEP 2의 방법은

reason만 messages.properties로 관리됩니다.
properties 파일을 공유하는 방식으로 프로젝트 외부에서도 접근할 수 있습니다.

반면 STEP 3의 방법은 DB 관리가 필요하긴 하지만 간결함과 생산성을 모두 가져갈 수도 있습니다.

레거시 코드 개선하기 with delegate pattern

Hyunec — Sun, 5 Jun 2022 11:32:16 +0900

GitHub - Hyune-c/blogcode-delegate

Contribute to Hyune-c/blogcode-delegate development by creating an account on GitHub.

github.com

STEP 1. 개선 전 코드

https://github.com/Hyune-c/blogcode-delegate/commit/7ac445974e1fc497509813303d80151ce705ce1c

AWS S3 조작을 담당하는 서비스로 개선 전 코드는 중복 코드와 확장성에 큰 단점을 가지고 있었습니다.
초기에는 연관된 로직이 적어 괜찮았지만, 그것을 감안하더라도 가독성과 확장에 취약한 코드였습니다.
그러던 중 S3 버킷 추가의 요건이 생겼습니다.

STEP 2. 코드 개선

버킷 추가를 하기 전 기존 코드의 개선을 진행했습니다.

1. Properties

기존의 코드는 service 내에 accessKey와 secretKey가 노출되어 있었고, 매 요청마다 amazonS3 오브젝트를 생성했습니다.

@Configuration
@RequiredArgsConstructor
public class AmazonS3Beans {

 public static final Regions CLIENT_REGION = Regions.AP_NORTHEAST_2;

 @Value("${cloud.aws.credentials.accessKey}")
 private String accessKey;

 @Value("${cloud.aws.credentials.secretKey}")
 private String secretKey;

 @Bean
 public AmazonS3 amazonS3() {
  final BasicAWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey);
  return AmazonS3ClientBuilder.standard()
    .withCredentials(new AWSStaticCredentialsProvider(credentials))
    .withRegion(CLIENT_REGION)
    .build();
 }
}

amazonS3을 재사용하기 위해 bean으로 선언했습니다.
이후 코드에서는 accessKey, secretKey가 노출되지 않습니다.

public interface AmazonS3Properties {

 String getStagePath();
 String getBucketName();

 default String getProvendorContentUrl() {
  throw new UnsupportedOperationException("잘못된 호출 입니다.");
 }
}


@Component
public class AmazonS3PublicProperties implements AmazonS3Properties {

 @Value("${env.profile}")
 private String stagePath;

 @Value("${cloud.aws.provendor.content}")
 private String provendorContentUrl;

 @Value("${cloud.aws.bucket.public}")
 private String bucketName;
}

public 버킷은 url 연결이 가능한 도메인을 가집니다.
인터페이스를 통해 버킷의 설정 값을 다르게 설정하고 가져올 수 있습니다.

2. Request 생성 책임 Provider

기존의 코드는 request object의 생성 책임 구분이 없었고, 비슷한 구현이 반복되었습니다.

public abstract class AbstractAmazonS3UploadRequestProvider {

 private final String stagePath;
 private final String bucketName;

 protected AbstractAmazonS3UploadRequestProvider(final AmazonS3Properties properties) {
  this.stagePath = properties.getStagePath();
  this.bucketName = properties.getBucketName();
 }

 public PutObjectRequest createRequest(final File file) {
  return createRequest(file.getName(), file);
 }

 public abstract PutObjectRequest createRequest(final String sourceName, final File file);

 protected PutObjectRequest createRequest(final String objectKey, final File file, final CannedAccessControlList cannedAclHeader) {
  final PutObjectRequest request = new PutObjectRequest(bucketName, objectKey, file);
  request.setMetadata(ObjectMetadataType.getMetadata(file));
  request.withCannedAcl(cannedAclHeader);

  return request;
 }

 protected String generateObjectKey(final String sourceName) {
  final LocalDateTime now = LocalDateTime.now();
  final String hash = LocalDateTimeUtils.toIsoFormat(now) + "_" + DigestUtils.md5Hex(String.valueOf(now.getNano()));
  return stagePath + "/" + hash + "/" + sourceName;
 }

 @Getter
 @RequiredArgsConstructor
 public enum ObjectMetadataType {

  CSV("text/csv; charset=UTF-8"),
  XLSX("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; charset=UTF-8"),
  XLS("application/vnd.ms-excel; charset=UTF-8"),
  HTML("text/html; charset=UTF-8");

  ...
 }
}


@Component
public class AmazonS3PublicUploadRequestProvider extends AbstractAmazonS3UploadRequestProvider {

 private static final CannedAccessControlList CANNED_ACL_HEADER = CannedAccessControlList.PublicRead;

 public AmazonS3PublicUploadRequestProvider(final AmazonS3PublicProperties properties) {
  super(properties);
 }

 @Override
 public PutObjectRequest createRequest(final String sourceName, final File file) {
  final String objectKey = generateObjectKey(sourceName);
  return createRequest(objectKey, file, CANNED_ACL_HEADER);
 }
}

S3 업로드를 위한 Request 생성 책임을 Provider로 모았습니다.

생성자를 통해 설정을 주입하며, 중복 코드를 줄였습니다.
사용자는 오픈된 2개의 createRequest() 메서드를 통해 PutObjectRequest를 생성합니다.
나노초 값을 시드로 한 해시를 통해 중복되지 않는 object path를 구현했습니다.
공개 여부는(CANNED_ACL_HEADER) 구현 클래스에서 정의합니다.

3. Delegate 클래스

기존의 코드는 특정 목적을 위한 메서드를 새로 만들었습니다.

public abstract class AbstractAmazonS3Service {

 private final AmazonS3 amazonS3;
 private final String bucketName;

 protected AbstractAmazonS3Service(final AmazonS3Properties properties, final AmazonS3 amazonS3) {
  this.amazonS3 = amazonS3;
  this.bucketName = properties.getBucketName();
 }

 public PutObjectResult putObject(final PutObjectRequest request) {
  try {
   return amazonS3.putObject(request);
  } catch (final SdkClientException e) {
   log.error(e.getClass().getName(), e);
   throw new IllegalStateException();
  }
 }

 public String getObjectFullPath(final String objectKey) {
  return amazonS3.getUrl(bucketName, objectKey).getPath();
 }

 public void getObject(final String objectKey, final File targetFile) {
  amazonS3.getObject(new GetObjectRequest(bucketName, objectKey), targetFile);
 }
}


public class AmazonS3PublicService extends AbstractAmazonS3Service {

 public AmazonS3PublicService(final AmazonS3PublicProperties properties, final AmazonS3 amazonS3) {
  super(properties, amazonS3);
 }
}

S3를 조작을 위임하는 클래스를 구현했습니다.

생성자를 통해 설정을 주입하며, 중복 코드를 줄였습니다.
S3만 조작하도록 수정하고, 특화 로직처럼 보이던 네이밍을 수정했습니다.
- 오브젝트 추가, 오브젝트 주소 가져오기, 오브젝트 가져오기

STEP 3. 버킷 추가

@Component
public class AmazonS3PrivateProperties implements AmazonS3Properties {

 @Value("${env.profile}")
 private String stagePath;

 @Value("${cloud.aws.bucket.private}")
 private String bucketName;
}


@Component
public class AmazonS3PrivateUploadRequestProvider extends AbstractAmazonS3UploadRequestProvider {

 private static final CannedAccessControlList CANNED_ACL_HEADER = CannedAccessControlList.Private;

 public AmazonS3PrivateUploadRequestProvider(final AmazonS3PrivateProperties properties) {
  super(properties);
 }

 @Override
 public PutObjectRequest createRequest(final String sourceName, final File file) {
  final String objectKey = generateObjectKey(sourceName);
  return createRequest(objectKey, file, CANNED_ACL_HEADER);
 }
}


@Service
public class AmazonS3PrivateService extends AbstractAmazonS3Service {

 public AmazonS3PrivateService(final AmazonS3PrivateProperties properties, final AmazonS3 amazonS3) {
  super(properties, amazonS3);
 }
}

새로운 버킷이 추가되어도 Properties, Provider, Service만 추가하면 되어 영향도를 최소화할 수 있습니다.

STEP 4. 사용 코드

@Service
public class SomethingWithExcelService {

 private final AbstractAmazonS3UploadRequestProvider amazonS3DelegateProvider;
 private final AbstractAmazonS3Service amazonS3Delegator;

 public SomethingWithExcelService(final AmazonS3CommonPrivateUploadRequestProvider amazonS3DelegateProvider, final AmazonS3PrivateService amazonS3Delegator) {
  this.amazonS3DelegateProvider = amazonS3DelegateProvider;
  this.amazonS3Delegator = amazonS3Delegator;
 }

 public void doSomething(final File file) {
  // 전처리 ...

  final PutObjectRequest request = amazonS3DelegateProvider.createRequest(file);
  amazonS3Delegator.putObject(request);

  // 후처리 ...
 }
}

파일 업로드에 필요한 버킷을 생성자 주입하기에 유연한 변경이 가능합니다.

조금 더 생각해 볼 것

처음에는 파일 조작 방법으로 S3 이외의 것이 들어올 수 있다고 생각해 Facade 패턴도 고려했습니다.
- Facade 패턴을 사용하면 사용되는 service를 package-private으로 숨길 수 있습니다.
- 하지만 S3 이외의 파일 조작을 하는 것은 너무 먼 미래일 것 같아 지금의 개선을 유지했습니다.
Provider를 Service의 inner class로 이동하면 좀 더 간결한 코드가 될 수 있습니다.
- 하지만 코드 리뷰 결과 클래스가 커지는 것보다는 분리하는 것이 좋겠다는 의견을 수렴했습니다.

220611 아래의 내용은 피드백을 받아 수정한 내용으로 회사코드까지는 적용되지 않았습니다.

STEP 5. 다중 상속을 활용한 Properties 구조화

STEP 3의 properties는 하나의 타입과 2개의 구현체로 설계했었습니다.
- 슈퍼 타입과 서브 타입을 통해 개선했습니다.
STEP 3는 AmazonS3Properties가 3개의 메서드를 가지고 있었습니다.
- getProvendorContentUrl() 메서드의 사용을 public 서브 타입에서만 접근할 수 있도록 개선했습니다.

조금 더 생각해볼 것 2

AmazonS3Client는 singleton bean으로 생성되지만, ThreadSafe하기에 지금의 코드를 유지해도 괜찮습니다.

AmazonS3Client (AWS SDK for Java - 1.12.237)

This action filters the contents of an Amazon S3 object based on a simple structured query language (SQL) statement. In the request, along with the SQL expression, you must also specify a data serialization format (JSON, CSV, or Apache Parquet) of the obje

docs.aws.amazon.com

for vs stream

Hyunec — Wed, 1 Jun 2022 18:33:48 +0900

이전에 공부했던 내용이지만 잘 설명해준 유튜브를 보고 내용을 정리해 봅니다.

기본 정보

for, foreach

구체적인 로직이 외부에 노출되는 외부 반복의 형태입니다.
for문은 java 1, foreach문은 java 5부터 등장했습니다.
foreach문은 컴파일 시 for문으로 변환됩니다.

stream

구체적인 로직이 외부에 노출되지 않는 내부 반복의 형태입니다.
함수형 프로그래밍 패러다임이 도입된 java 8부터 등장했습니다.

차이

익숙함의 차이에서 오는 가독성의 호불호가 있습니다.
디버깅 난이도의 차이가 있습니다.
- for 에러 발생 위치가 바로 노출됩니다.
- stream 지연 연산을 통해 실행되기에 에러 발생 시 위치를 추적해야 합니다.
병렬 처리 구현의 차이가 있습니다.
- for 구체적인 로직을 나누어 구현하고 합쳐야 합니다.
- stream parallelStream()으로 쉽게 처리됩니다.

성능 차이

공부했을 때 가장 고민한 부분으로 primitive/array에서는 차이가 있지만, wrapper/collection에서는 큰 차이가 없습니다.

stream은 for문에 비해 최적화가 잘 이루어지지 않았습니다.

stream이 for문보다 늦게 나왔기 때문입니다.
하지만 이전과 다르게 java가 빠르게 업데이트되고 있기에 개선을 기대합니다.

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

- 매년 두 번 non-LTS 릴리즈, 날짜는 3월이랑 9월
- 2년마다 LTS 릴리즈

stream은 for문에 비해 오버헤드가 발생합니다.

stream 사용을 위해서는 boxing이 필요하지만, for문은 인덱스에 바로 접근하여 오버헤드가 발생하지 않습니다.
하지만 프로덕션 코드에서는 boxing된 collection이 주로 사용되기에 큰 차이는 아니라고 생각합니다.

나의 사용법

저는 프로덕션 코드에서 stream과 boxing-unboxing 최소화를 위해 wrapper type 사용을 선호합니다.

개인적으로는 가독성이 훨씬 좋다고 생각합니다.
JDK 발전에 따라 지원되는 API와 최적화 혜택을 받을 수 있습니다.
코딩 스타일의 일관성을 가져갈 수 있습니다.
나아가 메서드/클래스 분리나 함수형 프로그래밍으로의 전환이 용이합니다.
primitive 사용이 메모리나 속도면에서 좋다는 주장도 있지만,
- type을 일관되게 사용함으로 인해 boxing을 줄입니다.
- 현대 개발은 변경에 강하도록 가독성을 올리고 비용을 더 들이는 것이 낫다고 생각합니다.
- 조금의 속도 차이는 감수할 수 있습니다.
일부 최적화된 성능이 필요하거나, 공통 모듈에서는 primitive와 for문을 사용합니다.

Entity의 field type은 무엇이 적합할까?

Hyunec — Wed, 25 May 2022 23:15:43 +0900

@Entity
public class Accommodation {

    @Id
    private Long id;

    private String locationName;
    private String description;
    private String imagePath;

    private int pricePerDay; // primitive type?
    private int positionX;
    private int positionY;
}

최근 리뷰를 한 코드 중 일부입니다.

저는 entity의 필드는 항상 wrapper type으로만 사용했기에 이 코드를 보았을 때 어색함을 느꼈습니다.

하지만 근거 있는 설득을 하기 위해 관련 자료를 조사했고 그 기록을 남겨봅니다.

ID

The primary key, or the property or field of a composite primary key, must be one of the following Java language types:
- Java primitive types
- Java primitive wrapper type
- sjava.lang.String
- java.util.Date (the temporal type should be DATE)
- java.sql.Date
- java.math.BigDecimal
- java.math.BigInteger

https://docs.oracle.com/javaee/6/tutorial/doc/bnbqa.html#bnbqf

JPA 공식 문서를 보면 primitive types 도 허용하고 있습니다.

하지만

We recommend that you declare consistently-named identifier attributes on persistent classes and that you use a nullable (i.e., non-primitive) type.

https://docs.jboss.org/hibernate/orm/5.3/userguide/html_single/Hibernate_User_Guide.html#entity-pojo-identifier

가장 일반적인 구현체인 Hibernate의 문서를 보면 명시적으로 non-primitive type의 사용을 권장하고 있습니다.
id를 primitive type으로 하면 0과 null을 구분할 수 없습니다.
- primitive type의 기본 값이 0이기 때문입니다.
그렇기 때문에 null이 허용되는 wrapper type을 활용해야 제대로 구분할 수 있습니다.

ID가 아닌 값

반면 ID가 아닌 값은 제 평소 사용에 대한 명백한 근거를 찾기 힘들었습니다.
하지만 저와 비슷한 고민을 한 스택 오버 플로우의 질문을 찾았고 그것을 기반으로 제 생각을 좀 더 정리해보았습니다.

데이터의 null 여부를 판단할 수 있어야 합니다.
null 데이터도 가져올 수 있어야 합니다.
- 혹자는 null 데이터의 존재 자체를 문제로 말할 수 있지만, 경험상 실무 DB에는 null인 컬럼이 꽤 존재했습니다.
소수 필드의 boxing-unboxing은 배제합니다.
- 컴퓨팅 능력이 충분히 저렴해지고 높아졌습니다.
- boxing-unboxing 이슈는 반복문과 같이 사용될 때 발생한다고 생각합니다.
코딩 스타일의 일관성을 가져갈 수 있습니다.
일부 @Ttransient 필드에 대해서는 사용하기도 합니다.

위와 같은 이유로 저는 Entity의 모든 필드를 wrapper type으로 사용하는 걸 선호합니다.

Entity members should they be primitive data types or java data types?

Is there a difference in declaring the enabled variable as Boolean or boolean? Which is preferable from a memory footprint perspective. @Entity class User { @Column Boolean enabled; }

stackoverflow.com

현재 환경에 맞는 값을 가져오기 with enum

Hyunec — Wed, 18 May 2022 23:25:25 +0900

로직은 같지만 개발과 운영에서 필요한 값이 다른 경우가 있는데, 대표적으로 url이 있습니다.
지금의 회사에서는 enum을 통해 관리하고 있지만, 그 방식이 enum 스럽지 않다고 생각하고 있었습니다.

그러던 중 기존 test - dev - stage - prod로 구성되었던 환경이 dev - qa - stage - prod로 변경되었고, 이 과정에서 코드를 개선한 내용을 기록해 봅니다.

Before

환경 변수 enum

public enum DeploymentEnvironment {

	DEV, QA, STAGE, PROD;

	private static final String AUTH_SERVER_NAME = Optional.ofNullable(System.getenv("AUTH_SERVER_NAME"))
			.orElse("");

	public static boolean isDev() {
		return AUTH_SERVER_NAME.equals(DEV.name().toLowerCase(Locale.ROOT));
	}

	public static boolean isQA() {
		return AUTH_SERVER_NAME.equals(QA.name().toLowerCase(Locale.ROOT));
	}

	public static boolean isStage() {
		return AUTH_SERVER_NAME.equals(STAGE.name().toLowerCase(Locale.ROOT));
	}

	public static boolean isProd() {
		return AUTH_SERVER_NAME.equals(PROD.name().toLowerCase(Locale.ROOT));
	}
}

환경 구분이 enum으로 존재하긴 하지만 모든 환경을 확인하기 위해서는 4개나 되는 if-else가 필요합니다.

사용 예시 1

// swagger 설정
public class OpenApiConfig {

	private OpenAPI getOpenAPI() {
		if (DeploymentEnvironment.isDev()) {
			return new OpenAPI()
					.addServersItem(new Server().url("https://dev.aaa.co.kr/"))
					.addServersItem(new Server().url("http://localhost:8820/"));
		}

		if (DeploymentEnvironment.isQA()) {
			return new OpenAPI()
					.addServersItem(new Server().url("https://qa.aaa.co.kr/"))
					.addServersItem(new Server().url("http://localhost:8820/"));
		}

		if (DeploymentEnvironment.isStage()) {
			return new OpenAPI()
					.addServersItem(new Server().url("https://stage.aaa.co.kr/"))
					.addServersItem(new Server().url("http://localhost:8820/"));
		}

		if (DeploymentEnvironment.isProd()) {
			return new OpenAPI()
					.addServersItem(new Server().url("https://api.aaa.com/"))
					.addServersItem(new Server().url("http://localhost:8820/"));
		}

		return new OpenAPI()
				.addServersItem(new Server().url("http://localhost:8820/"));
	}
}

환경별로 다른 url을 설정하기 위해서는 4번의 if-else를 사용해야 했습니다.

사용 예시 2

public enum BBBCallbackRequest {

	UPDATE_USER_ID(HttpMethod.PATCH, () -> getBaseUrl() + "/api/shop/user"),
	;

	private final HttpMethod httpMethod;
	private final Supplier<String> urlSupplier;

	private static String getBaseUrl() {
		if (DeploymentEnvironment.isProd()) {
			return "https://shop.bbb.com";
		}

		if (DeploymentEnvironment.isStage()) {
			return "https://shopstage.bbb.co.kr";
		}

		if (DeploymentEnvironment.isQA()) {
			return "https://shopqa.bbb.co.kr";
		}

		throw new IllegalStateException("local, dev 에서는 콜백하지 않습니다.");
	}
}

심지어는 환경에 따라 예외를 발생시켜야 되는 경우도 있었습니다.
무엇보다도 url이 곳곳에 분산되어 관리하기 힘들었고 변경에 들어가는 공수도 컸습니다.

After

환경 변수 enum

public enum DeploymentEnvironment {

	LOCAL("", ""),
	DEV("", "https://dev.aaa.co.kr/"),
	QA("https://shopqa.bbb.co.kr", "https://qa.aaa.co.kr/"),
	STAGE("https://shopstage.bbb.co.kr", "https://stage.aaa.co.kr/"),
	PROD("https://shop.bbb.com", "https://api.aaa.com/");

	public static final DeploymentEnvironment CURRENT_DEPLOYMENT_ENVIRONMENT;

	private final String bbbCallbackUrl; 
	private final String baseUrl;

	static {
		final String authServerName = Optional.ofNullable(System.getenv("AUTH_SERVER_NAME"))
				.orElse("")
				.toUpperCase(Locale.ROOT);
		CURRENT_DEPLOYMENT_ENVIRONMENT = Arrays.stream(DeploymentEnvironment.values())
				.filter(environment -> environment.name().equals(authServerName))
				.findFirst()
				.orElseThrow(() -> new IllegalArgumentException("알 수 없는 환경 변수"));
	}
}

현재 환경을 CURRENT_DEPLOYMENT_ENVIRONMENT로 정의하고 정적 초기화합니다.

사용 예시

// 사용 예시 1 
public class OpenApiConfig {

	private static OpenAPI getOpenAPI() {
		if (CURRENT_DEPLOYMENT_ENVIRONMENT.getBaseUrl().isBlank()) {
			return new OpenAPI().addServersItem(new Server().url("http://localhost:8820/"));
		}

		return new OpenAPI().addServersItem(new Server().url(CURRENT_DEPLOYMENT_ENVIRONMENT.getBaseUrl()));
	}
}

// 사용 예시 2
public enum BBBCallbackRequest {

	UPDATE_USER_ID(
			HttpMethod.PATCH, () -> CURRENT_DEPLOYMENT_ENVIRONMENT.getBbbCallbackUrl() + "/api/v2/shop/user"),
	;
    
	private final HttpMethod httpMethod;
	private final Supplier<String> urlSupplier;
}

사용 예시가 극단적으로 간결해졌습니다.
무엇보다도 enum을 통해 코드 응집도를 높였기에 환경이 변경되어도 enum만 수정하면 되는 것이 가장 큰 장점입니다.

마치며

예시는 2개뿐이지만 실제로는 더 많은 사용이 있었고, 이 수정을 통해 미래의 변경 영향도도 축소할 수 있습니다.

만약 환경 변수 관리가 더 민감했다면 Spring Cloud Config 등을 활용할 수 있겠지만, 그것 또한 구성과 운영의 어려움이 있고 지금의 회사에서도 Dockerfile을 통한 관리 정도는 하기에 괜찮다고 이 정도의 개선만 진행했습니다.

분산 트랜잭션 설계하기 (초급)

Hyunec — Mon, 9 May 2022 10:53:05 +0900

분산 트랜잭션 관리는 MSA 운영의 핵심 중 하나로 설계도 어렵지만 제반되는 기술도 러닝 커브가 상당히 높습니다.

이와 관련되어 실무에서 경험해본 내용과 F-Lab의 twitch-clone 프로젝트를 진행하면서 고민해본 기록을 남겨봅니다.

2PC 패턴과 (2 Phase Commit) SAGA 패턴에 대한 배경 지식이 있다면 글을 이해하는데 더 좋습니다.

마이크로서비스 분산 트랜잭션 관리 (2Phase Commit)

개요 앞선 포스팅에서 마이크로서비스 분산DB 환경에서 고려되어야 할 사항에 대해 살펴보았다. 자세한 내용은 아래 포스팅을 참고하기 바란다. 마이크로서비스 Schema 분리 설계 (테이블 분리,

waspro.tistory.com

마이크로서비스 분산 트랜잭션 관리 (Saga Pattern)

개요 앞선 포스팅에서 마이크로서비스 분산DB 환경에서 고려되어야 할 사항에 대해 살펴보았다. 자세한 내용은 아래 포스팅을 참고하기 바란다. 마이크로서비스 분산 트랜잭션 관리 (2Phase Co

waspro.tistory.com

1. 초기 설계와 최종 모델

twitch-clone 프로젝트는 domain이 분리된 모듈로 개발되고 있습니다.

즉 api-module로 들어오는 사용자의 구독 요청에 user-module의 구독 usecase를 호출합니다.

구독에 필요한 부가 기능인 결제를 추가했지만 user-module에서 한 번에 처리되는 게 불편합니다.

payment-module로 결제를 분리하고 usecase를 별도로 만들었습니다.

그리고 구독에 트랜잭션을 걸어 구독과 결제를 하나의 업무 단위로 움직이게 설계했습니다.

결제가 추가되었음에도 불구하고 api-module에서는 이전의 usecase를 동일하게 사용할 수 있습니다.

즉 구독에 필요한 로직이 변경되더라도 외부에 변화가 없는 느슨한 결합의 로직이 완성되었습니다.

하지만 단점에도 불구하고 우리는 api-module에서 2PC 패턴으로 트랜잭션을 관리하는 모델을 최종 선택 했습니다.

2. 왜 2PC 패턴인가?

선택의 이유를 좀 더 쉽게 설명하기 위해 외부 서비스 로직이 있다고 가정하고 확장했습니다.

결제를 하기 위해서는 부정 방지 여부를 확인해야 하고, 구독이 성공하면 기록을 남겨야 합니다.

이 모델은 Choreographed SAGA 패턴과 유사합니다.
- 메시지 브로커 활용 대신 트랜잭션을 잡고 있는 점이 달라 장애 처리는 비교적 용이하지만,
  복수 개의 서비스에 연쇄적인 트랜잭션이 생기고 있어 관리와 추적이 힘들다는 단점이 같습니다.
- 반면 2PC 패턴은 트랜잭션의 관리 주체가 한 곳으로 집중되어 트랜잭션 관리가 용이합니다.
api-module만이 Spring 의존도를 가지며 그 외 module은 도메인 로직만을 가지도록 설계했습니다.
따라서 usecase에 따라 각 module에서 생성된 결과를 api-module에서 영속시킵니다.
사이드 프로젝트이기에 복잡도가 높지 않기에 로직의 추가가 api-module에 영향을 주어도 괜찮다고 생각했습니다.

위와 같은 이유로 느슨한 결합을 일부 포기하더라도 2PC 패턴을 선택하는 게 좋다고 판단했습니다.

마치며

모든 패턴에는 장단점이 존재하기에 최신의 이상적인 모델만을 고수하는 것은 정답이 아닙니다.

중요한 것은 주어진 업무 성격과 인프라 제반 사항, 인력 분배와 러닝 커브, 운영까지를 고려하여 트레이드오프 하고 지금에 맞는 베스트 프렉티스를 선별하는 것이고, 그런 능력을 가져야 합니다.입니다.

그렇기 위해서는 많은 패턴을 학습하고 설계해봄으로써 배경 지식을 쌓아야 합니다.

이번 설계가 그러했습니다.

아마 실무였다면 트랜잭션 타임을 줄이기 위해 MQ를 도입하고 Orchestration Saga 패턴을 고려했을 것 같습니다.

하지만 사이드 프로젝트에 MQ까지 고려하는 것은 힘들었고, 학습 목표인 도메인 분리와 모듈 프로그래밍에 맞게 좀 더 쉬운 아키텍처를 선택했습니다.

마지막으로 극도의 성능과 분산 트랜잭션이 필요하다고 알려진 게임 분야에서도 필요에 따라서는 2PC를 구현하여 성공적으로 운영하는 사례를 공유하며 마무리합니다.

'AWS와 토스페이먼츠를 통해 E-Commerce 스타트업 혁신하기' 웨비나 후기

Hyunec — Fri, 29 Apr 2022 18:44:32 +0900

(22.04.27) 웨비나에서 소개한 기술 중 중요하거나 당사에 적합하다고 생각하는 내용을 회사 내부에 소개하는 글을 작성했습니다.
이 중 일부 민감 항목을 제외한 간단한 후기를 작성하며, 일부 내용은 재직 중인 회사의 시선에서 작성되었습니다.

저는 이전 경력으로 VAN과 페이의 운영 업무를 했었습니다.

그러다 보니 자연스럽게 결제 서비스의 선두 주자인 토스에 관심이 있었고, 특히 브랜드 페이는 웨비나 전부터 긍정적으로 생각하는 모델 중 하나였습니다.

그러던 중 AWS의 주관으로 무신사에 브랜드 페이를 적용한 대표 사례를 소개하는 웨비나를 들을 수 있는 기회를 얻었고, 이미 큰 트래픽을 처리하는 회사의 설계를 보며 최근 설계하고 있는 당사의 MSA에도 큰 영감을 얻었기에 내용을 기록해봅니다.

OO페이, 우리 회사도 만들 수 있을까?

우리 쇼핑몰 이름 딴 간편결제, OO페이를 만들고 싶다면, 토스페이먼츠 간편결제 솔루션 브랜드페이를 도입해 보세요. 적은 시간과 비용으로 결제전환율 95% 이상의 간편결제를 구축할 수 있어요

blog.tosspayments.com

발표 섹션은 4개였지만, 기록은 기술 내용이 들어가 있는 1, 3번째 만을 대상으로 합니다.

1. E-commerce를 위한 AWS 아키텍처 진화하기.pdf

5.17MB

2. AWS 공동 웨비나 토스페이 발표자료_v7_220404.pdf

2.38MB

3. AWS+토스페이먼츠 발표자료 (빌링개발팀 최진호)_최종_Font_rev2.pdf

1.59MB

4. 스타트업을 위한 AWS x Toss Payments의 특별 혜택.pdf

0.53MB

1. E-commerce를 위한 AWS 아키텍처 진화하기

데이터 흐름을 분석하여 인사이트 도출까지 고려한 모델을 말하고 있습니다.

Auto Scaling Group

ecs에 설정할 수 있는 고가용성 기능 중 하나입니다.
예정된 이벤트라면 수동으로 스케일 업을 지정할 수 있습니다.
하지만 보통은 자동으로 스케일 업 & 스케일 아웃되기를 기대합니다.
- 최소 24시간 이상의 데이터가 있는 경우, 지난 14일 동안의 metric을 분석해 향후 48시간의 지표를 예상하여 자동 설정됩니다.

Amazon Aurora

당사에서는 RDS만을 레플리카 없이 모두 마스터로 운영하고 있습니다.
보통은 레플리카의 적극적인 활용을 말하지만, 당사는 B2B 성격이 강하며 그리드 조회 기능이 대부분입니다.
따라서 CQRS 패턴과 데이터웨어하우스의 도입이 선행되는 것이 좋다고 생각합니다.

같이 쓰면 좋은 서비스

Performance Insights (성능 개선 도우미)

당사는 AWS의 관제 시스템보다는 datadog을 적극적으로 사용하려 합니다.

RDS Proxy

'AWS Secrets Manager과 통합되어 Credentials를 안전하게 관리할 수 있다'라고 하지만 지금은 필요성이 와닿지 않았습니다.

분석 시작하기

Amazon Kinesis Data Streams

발표에서는 사용자 흐름의 통계화를 위해 Kinesis를 말합니다.
하지만 사용자 흐름에 대한 트래킹은 datadog을 활용할 수 있다고 생각합니다.
- 이미 당사의 일부 시스템은 사용자 흐름을 datadog으로 추적 가능합니다.
- 하지만 발표 자료 수준의 인사이트를 얻을 수 있는 정형화된 데이터는 아닙니다.

Amazon Athena

앞의 이슈들을 해결하기 위한 방법으로 사내에서 선택한 기술 중 하나입니다. (+ AWS Glue)
당사는 아직 MSA를 준비하는 초창기이기에 같은 도메인이 각 모놀리식 서비스마다 조금씩 다른 시선으로 개발되어 있습니다.
- 이것을 공통 도메인으로 분리하는 것이 MSA의 최종 목표이며, 이 과정은 매우 힘들고 긴 호흡이 필요합니다.
- 그렇기에 과도기인 상황에서 필요한 데이터를 추출함에 있어서는 ETL을 활용하는 것이 가장 적절하다고 판단했습니다.

Amazon QuickSight

이미 내부에서 시각화된 지표 대시보드 개발했습니다.
Amazon QuickSight는 Saas 형태이기에 편리하겠지만, 메트릭 집계가 선행되어야 하기에 와닿지 않았습니다.

머신 러닝 활용하기

머신 러닝에 대해 잘 모르기도 하고, 기초 자료를 위한 메트릭 집계가 선행되어야 하기에 와닿지 않았습니다.

3. AWS+토스 페이먼츠 발표자료

Monolithic → Microservice

당사의 레거시와 비슷합니다!

MSA! 제가 생각하는 모델은 이것과 비슷하지만 BFF를 곁들입니다.

무신사에서 브랜드 페이를 위해 사용하는 서비스들

아쉽게도 당사는 아직 MQ조차 사용하지 않는 동기식 처리가 대부분이며, 배치가 아닌 스케줄러의 형태만 운영되고 있습니다.
자료에서는 카프카를 말하지만, 러닝 커브가 높고 당사의 트래픽 수준에서는 큰 이점 없이 운영 난이도만 높아진다고 생각합니다.
- 비교적 쉽게 사용할 수 있는 AWS SNS/SQS를 생각하고 있습니다.
- 발표에서도 초기에는 Amazon MQ와 AWS SNS/SQS를 병행 사용하다가 이후 kafka로 넘어갔다고 합니다.

대량 데이터 조회와 유지보수는 어떻게 해야될까?

Hyunec — Sat, 2 Apr 2022 16:18:49 +0900

GC에 익숙한 사람이라면 모두 Generational GC가 최고라고 이야기합니다.
'generational hypothesis는 대부분 상황에서 Young Object는 Old Object 보다 죽을 가능성이 클 것으로 내다본다.' 2008년에는 맞는 말이었죠. 하지만 지금은 설득력이 떨어집니다.

Red Hat 개발자 Christine Flood - DevNation 2016 中

기술의 발전과 시장의 변화에 따라 과거에는 옳았던 것이 지금은 재해석되고 있습니다.

클라우드의 도입으로 어려웠던 확장/고가용의 기술이 쉬워지고, 하드웨어의 비용이 낮아진 것이 하나의 예입니다.

회사의 성장에 따라 다뤄야 하는 데이터는 기하급수적으로 늘어나고 기존의 방법으로는 해결하기 힘든 순간이 옵니다.

지금 다니는 회사에도 그 시점이 다가오고 있습니다.

물론 좋은 아이디어들이 많이 있지만, 우선 순위가 다른 지금의 회사에 그대로 적용하는 것은 꽤 어려운 일 입니다.

그렇기에 기술 부채는 계속 쌓이고 있고, 응급조치만으로는 할 수 없는 시점이 다가오고 있습니다.

저는 백엔드 엔지니어로서 그때를 위해 기술을 재해석하고 지금에 적절한 기술을 준비하는 과정을 기록합니다.

지금의 개발 & 조회 환경

배경

각각의 플랫폼들은 모놀리식으로 개발되어 있음
비슷한 데이터가 독립적으로 존재하고 있으며 호환되지 않음
대량 데이터를 다룰 수 있는 인력 부재

내가 소속되어 있는 플랫폼 P의 환경

입점된 대형 업체는 1개뿐임에도 불구하고 간헐적인 속도 이슈 발생
- 인덱스 수정, 최대 조회 기간을 1달로 제한하는 등의 단발성 응대로 해결
- 상반기 내 다수의 대영 업체 입점 예정
대부분의 조회 로직이 영속성 레이어에 집중되어 있음
- 초대형 쿼리로 구성된 로직은 수정 난이도가 높고 높은 업무 이해도가 요구됨
- 데이터의 상태가 개별 column으로 관리되며 비슷한 상태가 중복되기도 함 (ex. SYSTEM_USER_YN)
도메인 로직 정의보다 DB 테이블 정의가 선행되고 그것에 맞추는 개발을 하고 있음
- 확장성보다는 성능과 개발 속도를 중시한 단일 테이블 형태가 많음
read only DB에 대한 필요성은 공감되고 있지만 실 적용하지 못하고 있음
GraphQL의 특성을 살리지 못하고 화면 별로 특화된 대형 조회 쿼리 형태로 운영되고 있음
- 오히려 학습과 문제 해결 난이도만 높아짐

개선을 위한 아이디어

이미 알려진 아이디어는 많습니다.
하지만 내가 일하는 환경에 적용할 수 있도록 재해석하는 것은 완전히 다른 영역입니다.

1. 영속성 레이어에 집중된 로직을 분리

지금의 구성. 출처: 만들면서 배우는 클린 아키텍처

제가 생각하는 초대형 쿼리가 생겨나는 원인은

요구 사항의 변경을 도메인이 아닌 쿼리, 즉 영속성 레이어에서 해결하고 있습니다.
보통 높은 이해도가 필요한 복잡한 업무 환경에서 나오는 현상이며, 지금의 빠른 개발을 위해 쿼리의 일부만 수정하거나 인덱스를 통해 해결하기에 해당 기능에 특화된 대형 쿼리로 작성되곤 합니다.
- 이 로직은 재사용이 불가능하고 높은 결합도를 가집니다.
수정을 위해서는 문맥 이해와 영향도 체크 후 분리, 추상화 비용이 개발에 준하는 수준으로 발생됩니다.

과거에는 맞습니다.

소프트웨어는 비교적 짧은 수명을 가지고 워터폴 방식으로 개발되었습니다.

변경은 비교적 적거나 보수적으로 수용되었고, 변경 난이도가 일정 수치를 넘어서면 차세대 개발로 대체되었습니다.
자연스럽게 비교적 긴 수명의 DB와 높은 비용의 하드웨어 집중된 개발이 되었습니다.
한 가지 예로 성능 향상을 위해 join을 줄이는 단일 테이블 전략이 많이 사용되었습니다.

지금은 다릅니다.

높아진 개발 비용과 니즈가 다양해진 지금의 환경에서는 변경 난이도를 낮추는 것이 더 중요해졌습니다.

도메인 레이어에서 범용 로직을 조립하는 DDD 이론이 나왔습니다.
클라우드가 등장하면서 확장성이 용이해지고 인프라 의존도가 줄었습니다.

백엔드 개발 측면에서 단적인 예를 들자면

과거에는 높은 컴퓨팅 비용이 드는 stream 대신 for문을 사용해야 된다는 의견도 있었습니다.
지금은 하드웨어 활용으로 개발 난이도를 낮추고, 나아가 함수형 패러다임으로의 변경까지 일어나고 있습니다.

저와 비슷한 생각으로 레이어를 나눈 좋은 글이 있어 공유합니다.

Layered Architecture Deep Dive

최근 진행 중인 프로젝트는 Layered Architecture를 선택하여 패키지를 구성하고 개발하였습니다.

msolo021015.medium.com

2. 성능 개선을 위한 방법

WAS 스케일 업, 스케일 아웃(Scale-up, Scale-out)

클라우드 환경이라면 가장 영향도가 적은 방법으로 인프라 성능을 확장시키는 것입니다.

EC2 개별 구성-> Elastic BeanStalk -> ECS - Fargate -> Kubernetes 순으로 기술을 도입할 수 있습니다.
Elastic Load Balancer를 통해 트래픽을 분산시키고, Auto Scaling을 통해 스케일 업을 자동화할 수 있습니다.
업무 성격에 따라 T 타입 인스턴스를 통한 버스트 기능을 활용하는 방법도 있습니다.

DB 스케일 업, 스케일 아웃(Scale-up, Scale-out)

Replication DB
- CUD 로직을 수행하는 master DB와 R 로직을 수행하는 복제 DB를 구성하는 방법으로 확장성이 용이합니다.
- 단점으로는 동기화에 시간이 걸리며, DB 연결의 추가 개발과 인프라 구성이 필요합니다.
RDB를 사용하고 있다면 Amazon Aurora 도 좋은 선택입니다. (2021.11부터 MySql 8.0 지원)

파티셔닝(Partitioning), 샤딩(Sharding)

과거에는 직접 구성해야 됐지만, 지금은 DB나 프레임워크에서 지원해주기도 하는 전통적인 분산 처리 기술입니다.
하지만 운영 난이도가 높고 RDB가 대세였던 시기에 분산 처리를 하기 위해 나온 기술이기에, 최근에는 분산 처리를 전제로 한 기술이 권장되고 있습니다.
- NoSQL, CDC(Changed Data Capture), ETL

ETL (Extract, Transform, Load), Data warehouse

비슷하지만 다른 데이터를 의미있게 재구성해야하는 현대의 개발에 가장 활용성 높은 기술 중 하나입니다.
과거에는 배치성의 개발이 필요했지만 현재는 AWS Redshift, Athena 등을 통해 편리하게 작업할 수 있습니다.
단점으로는 학습과 운영 난이도가 높으며 데이터를 집계, 재배열하는 시간이 필요해 실시간 처리는 힘든 기술입니다.

CQRS (Command and Query Responsibility Segregation)

명령과 조회의 책임 분리를 하는 패턴으로 앞에 소개한 방법 중 가장 적은 영향도와 개발 비용이 듭니다.

CUD 로직은(등록, 수정, 삭제) Command로 모아 도메인 로직에 응집시키고 ORM 기술을 활용합니다.
R 로직은(조회) Query로 모으며 필요에 따라 native query를 사용하기도 합니다.

3. 지금에 적절한 기술을 선별하는 것

알려진 기술들은 이미 많습니다. 중요한 것은 지금에 적절한 기술을 선별하는 것입니다.

플랫폼 P는 사용량이 적음에도 불구하고 성능 이슈가 발생하고 있으며, 대형 업체의 추가 입점이 예정되어 있습니다.

이대로라면 이미 제한한 최대 조회 범위를 더 줄여야 하고, 적절하게 조절하지 못했다면 장애로 번질 수도 있습니다.

백엔드 아키텍처만을 수정합니다

가장 영향도가 낮은 방법으로 CQRS의 분리와 도메인 레이어의 도입이 있습니다.

개발의 수정 난이도는 낮춰주지만, 이미 부하가 발생하고 있는 환경에 드라마틱한 효과를 기대하기는 힘듭니다.
아키텍처의 복잡도가 높아지는 만큼 혼란을 막기 위해 컨벤션 정의가 선행되어야 합니다.

대형 업체별로 테이블을 분리합니다

기존에는 몇 개의 거대한 테이블에 데이터와 복잡한 조회 로직이 모여 있었기 때문에 조회에 문제가 되었습니다.

따라서 대형 업체별로 테이블을 분리하는 방법이 있습니다.

하지만 이미 구현된 거미줄 같은 로직에 연관된 테이블을 대형 업체 별로 추가해야 되기에 개발 복잡도가 급격하게 높아짐으로 장기적인 해결책이라고 볼 수 없습니다.

가장 큰 문제는 CRUD가(Create, Read, Update, Delete) 모두 하나의 서비스에서 일어나고 있다는 것입니다.

즉 지금의 구성은 동기화에는 좋지만 확장과 부하에 약하고, 유지보수의 용이성의 고려도 필요합니다.

성능 향상과 유지보수성을 모두 만족시키기 위해서는 패러다임을 변경해야 됩니다.

CQRS의 서비스 단위 분리

기존의 업무를 분석하고 재해석하여 CUD와 대용량 R 업무를 구분합니다.

그리고 CUD는 기존의 서비스에서 진행하고, 대용량 R 업무는 서비스를 분리합니다.

테이블 설계 방식 변경

CUD 서비스의 테이블은 확장성이 좋고 ORM 기술 사용에 용이한 조인 테이블 전략으로 설계합니다.

성능이 필요한 대용량 R 업무가 분리되었기에 가능합니다.

Data warehouse 도입

Data warehouse를 도입하여 대용량 R 업무의 조회를 위한 테이블을 독립적인 공간에 구성합니다.

AWS의 기술을 사용한다면 최근 공개된 AWS Glue Studio의 사용을 고려하는 것도 좋습니다.
배치로 구현한다면 NoSQL의 도입도 고려할 수 있습니다.
RDB 수준의 ACID를 준수하지는 않지만 대용량 조회라는 업무 성격상 적합하기 때문입니다.

개선 방향

1. 모든 CRUD 가 하나의 서비스에서 처리되는 지금의 상태

2. 대용량 R 은 분리되었지만 여전히 하나의 서비스에서 처리

3. 대용량 R 을 독립적인 서비스로 분리

나아가 이기종 플랫폼의 정보를 Data warehouse로 통합할 수도 있습니다.

기타

ETL/Data warehouse 운영의 가장 큰 단점은 실시간 데이터와 집계 과정에서 발생하는 간극입니다.

즉 대용량 조회는 D-2 이전의 데이터만 지원한다와 같은 업무적 합의가 필요합니다.

과거 운영했던 업무 중에 하나를 예로 들면

카드사 별 카드 이용내역을 배치를 통해 시간 단위로 별도 시스템으로 집계합니다.
카드 이용내역은 즉시 확인 가능하지만, 매입내역은 익일 확인 가능합니다.

마치며

앞에서 말한 것들은 새로운 패러다임을 도입하는 만큼 구성원 모두가 공부해야 되는 양도 많습니다.

저도 아직 이해가 깊지 못하기에 개인적으로 공부하며 최근 맡은 개발과 사이드 프로젝트에서 자체적으로 도입해보고 있습니다.

제가 생각하는 좋은 엔지니어란 정석을 알고 뒤처지지 않으면서도 지금에 적절한 기술을 선택할 수 있는 사람입니다.

그리고 이런 사람들이 모여 좋은 자극을 자발적으로 공유할 때, 모두의 실력이 상향 평준화되고 높은 퀄리티의 결과물이 나올 수 있다고 생각합니다.

좋은 자극을 지속적으로 받을 수 있는 환경을 기대하며 성능 개선에 관련된 영상을 하나 남기고 글을 마칩니다.

초식 - 서버 성능 올리기 (처리량, 응답시간) - 최범균

마이크로 서비스도 리소스 동기화가 필요할까?

Hyunec — Fri, 4 Mar 2022 18:46:20 +0900

이번에 회사 최초로 시작하는 MSA 개발의 첫 삽을 제가 뜨게 되었습니다!

사실 이 개발을 하면서 제일 큰 걱정은 MSA 책 한 개도 안 봤는데 내가 설계해도 되나......... 였습니다.

설상가상으로 설계기간도 충분하지 못했죠.

하지만 틈틈이 읽은 서적과 블로그들이 큰 도움이 되었고, 부족하지만 제가 설계하고 개발한 기록을 공유합니다.

개발한 내용

기본 구성

오래되고 사용자가 많은 플랫폼 B와 비교적 최근에 개발되었지만 사용자가 적은 플랫폼 P가 존재합니다.

서로 다른 환경에서 운영되고 있던 플랫폼의 각 DB와 회원 등록/수정 로직이 통합 중에도 유지되어야 합니다.

구현된 언어와 프레임워크도 달랐고, 통합 대상인 회원의 식별자와 업무 내용도 미묘하게 달랐습니다.

이해를 돕기 위해 업무 내용의 일부를 먼저 설명하며, 해결하기 위한 설계로 2가지 플랜을 구상했습니다.

회원은 거래처(매장)와 같은 의미를 가집니다.
거래처는(B: shop, P: cust) 복수 개의 유통사를(B:vendor, P: biz) 가질 수 있습니다.

PLAN A

PLAN A. 통합회원에 대리키 userNo 를 만들고, 각 플랫폼의 PK 값을 테이블 관계로 관리합니다.

장점

통합회원에는 회원 상세 정보가 없기에 각 플랫폼에서 회원 정보가 변경되어도 알 필요가 없습니다.
- 인증과 직결되는 일부 항목은 필요하지만 개수를 최소화합니다. (ex. 비활성화 여부)
로그인 ID(userId)와 password가 통합되고, 인증에 필수적인 필드를 한 곳에서 관리할 수 있습니다.
기존 플랫폼의 DB 변경이 최소화됩니다.

단점

통합회원에서 회원 상세 정보가 알고 싶다면 각 플랫폼으로 회원 PK를 통해 요청해야 합니다.

PLAN B

PLAN B. 통합회원의 대리키 userNo 를 각 플랫폼에 추가합니다.

장점

통합회원에는 회원 상세정보가 없기에 각 플랫폼에서 회원 정보가 변경되어도 알 필요가 없습니다.
- 인증과 직결되는 일부 항목은 필요하지만 개수를 최소화합니다. (ex. 비활성화 여부)
로그인 ID(userId)와 password가 통합되고, 인증에 필수적인 필드를 한 곳에서 관리할 수 있습니다.
각 플랫폼의 회원 상세정보를 원하는 대로 가져올 수 있습니다.

단점

회원 상세정보를 가져오는 네트워크 비용이 비교적 큽니다.
기존 플랫폼 DB에 userNo 가 추가됩니다.

상위 도메인은 하위 도메인의 키만을 가지도록 함으로써
리소스 관리의 이슈를 최소화할 수 있도록 설계했습니다.

하지만..

PLAN C

PLAN C. 회원상세정보가 플랫폼과 통합회원에 모두 존재합니다.

결론적으로 PLAN C의 설계로 개발을 진행하게 되었습니다.

이미 MSA를 경험해본 분이라면 PLAN C의 그림이나 이 글의 제목에서 의아함을 느끼셨을 것 같습니다.

리소스 관리는 도메인 별로 분리된 하나의 서비스에서 하면 되는데, 왜 동기화를 고민하지?

아쉽게도 특수한 업무 요건과 글로 작성하기 힘든 내부의 이슈로 인해 과도기적인 설계를 했어야 되기 때문입니다.

인증 진행 간 회원 상세 정보를 보여줘야 하며, 통합인증의 테이블을 사용해야 한다. (스냅샷)
각 플랫폼의 회원 등록/수정을 통합 회원에서도 알아야 한다. (동기화)

하지만 요건 만족을 우선한 설계를 했다고 하기에는 부족한 통찰로 합리적인 설득을 하지 못하고 안일하게 넘어간 점이 몹시 아쉽습니다.

마이크로 서비스도 리소스 동기화가 필요할까?

본론을 말하기 위한 배경 설명이 너무 길어졌네요. 다시 처음으로 돌아가겠습니다.

제일 좋은 것은 동기화가 필요하지 않은 설계를 하는 것입니다.

하지만 리얼 월드에서는 앞에서처럼 필요한 경우가 생기곤 하기에, 동기화 방법에 대한 생각을 기록해봅니다.

신뢰할 수 있는 리소스는 플랫폼에 있습니다.
- 동기화는 여러 가지 이유로 실패할 수 있습니다.
  최악의 경우에는 수동 작업을 해야 될 수도 있는데, 이때를 위한 신뢰할 수 있는 대상을 고려해야 합니다.
  신뢰할 수 있는 대상을 정하는 방법은 리소스의 관리 책임 주체는 누구인가? 를 생각하면 될 것 같습니다.
- 각 플랫폼에는 상대적으로 많은 회원정보 수정 로직이 있고 수정이 시작되는 지점입니다.
  따라서 리소스의 관리 책임이 각 플랫폼에 있다고 간주할 수 있음으로 신뢰할 수 있는 대상은 각 플랫폼이 되어야 하며, 반대로 통합인증의 리소스는 스냅샷으로 간주합니다.
회원정보 수정은 누가 해야 될까?
- PLAN C에서는 같은 리소스의 관리 대상이 2곳입니다.
  따라서 양쪽의 변경이 동시에 하기 위해 수동으로 트랜잭션을 구현해야 합니다.
  여기에서 JPA의 양방향 매핑의 연관 관계의 주인에서 인사이트를 얻었습니다.
  한쪽을 주인으로 설정하는 것이죠.
- 1번을 통해 신뢰할 수 있는 리소스가 플랫폼에 있다는 것을 알 수 있습니다.
  따라서 플랫폼이 주인으로서 트랜잭션의 주체로 설계하며 통합인증에서는 키 값과 최소한의 상태만 가지도록 합니다.
- 하지만 그럼에도 불구하고 업무 요건에 따라 통합회원에서 정보를 수정해야 되는 경우도 있습니다.
  아쉽게도 처음의 아이디어에는 위배되지만 요건 만족을 위해 어쩔 수 없이 예외 로직을 개발했습니다.
  이때 트랜잭션의 주체는 반대가 되어야 합니다.
동기화 간 지연과 유실을 대비해야 합니다.
- 보편적으로 좋은 해결책은 큐의 도입입니다.
  - 큐가 대상으로 push - 재시도는 용이하지만 큐를 를 지속적으로 관리해야 한다.
  - 대상이 큐를 polling - 실패 시 이미 소비된 큐가 유실될 위험이 존재한다.
  - 보통 큐가 대상으로 push 하는 방식으로 사용됩니다.
- AWS SQS를 통해 권한 제어를 도입하면 보안 향상도 기대할 수 있습니다.
어떤 도메인은 자주 바뀌지 않기에 실시간 동기화에 관대할 수도 있습니다.
- 이 경우 실시간 동기화보다는 배치를 활용하는 방법이 있습니다.
- 실시간 동기화를 하는 경우에도 배치를 사용하여 안정성을 높일 수 있습니다.
- 또는 스냅샷을 캐시로 저장하는 방법도 있습니다. (ex. redis)
충분한 환경에서 성숙 단계의 마이크로 서비스를 지향한다면 SAGA 패턴을 고려합니다.
- Choreography와 Orchestration은 구성은 어렵지만 MSA 트랜잭션 관리에 가장 좋은 구조입니다.

Saga pattern - Azure Design Patterns

Use the Saga design pattern to ensure data consistency on distributed transactions in microservices architectures.

docs.microsoft.com

마치며

출처: https://waspro.tistory.com/

지금 회사의 구성을 MSA로 전환한다면 어떻게 해야 될까?

막연하게 생각했을 때 Step 1처럼 복수의 프로젝트가 하나의 DB를 공유하는 것에서 시작할 것이라고 생각했습니다.

하지만 현실은 많이 달랐고 공부했던 개념들을 모아 독자적인 흐름을 설계했습니다.

그 과정에서 발생한 개발의 어려움은 반대로 좋은 설계의 필요성에 대한 공감대를 형성하기도 했습니다.

제 최종 목표는 플랫폼에서 독립적인 마이크로 서비스와 각 플랫폼에 특화된 Backend for Front-end로 설계하는 것입니다.

아마 이 과정에서도 트레이드 오프를 반복하겠지만 지금의 경험이 도움이 되고, 나아가 이 모든 경험들이 더 좋은 설계의 기반이 되기를 기대하며 글을 마칩니다.

오늘의집 MSA Phase 1. 백엔드 분리작업 - 오늘의집 블로그

마이크로서비스 열차 탑승을 위한 백엔드 분리 과정

www.bucketplace.co.kr

오늘의집 MSA Phase 1. Aggregator 공통모듈 - 오늘의집 블로그

1년차 백엔드 개발자의 MSA 공통모듈 개발기

www.bucketplace.co.kr

Custom LocalDateUtils 리팩토링

Hyunec — Tue, 4 Jan 2022 01:08:06 +0900

이번에 회사 업무의 일부를 확장/분리하는 업무를 맡았습니다.
프로젝트의 세팅부터 해야 되는 작업이었기에 제가 주도적으로 개발할 수 있었는데요.
이 과정에서 작업한 Legacy의 공통 Util 리팩토링의 일부를 기록해봅니다.

AS-IS의 문제점

// 0. 이 프로젝트에 의존적인 로직이 존재합니다.
//  ex) 입력 값이 파싱할 수 없는 isEmpty() 라면 빈 값을 반환. (에러가 아니라)
@UtilityClass
public class LocalDateUtils {

 // 1. LOCAL_DATE_FORMAT_WITH_HYPHEN, LOCAL_DATE_FORMAT 이 String 변수로 존재합니다.
 public static final String LOCAL_DATE_FORMAT_WITH_HYPHEN = "yyyy-MM-dd";
 public static final String LOCAL_DATE_FORMAT = "yyyyMMdd";

 // 2. NO_HYPHEN 은 매개 변수를 통해 받고 있지만,
 //  WITH_HYPHEN 은 명시된 메소드 이름을 사용하기에 일관성을 해칩니다.
 public static String toString(final LocalDate attribute, final String format) {
  if (attribute == null) {
   return "";
  }
  // 3. DateTimeFormatter 객체가 매번 재생성되고 있습니다.
  return attribute.format(DateTimeFormatter.ofPattern(format));
 }
 
 public static String toStringWithNoHyphen(final LocalDate attribute) {
  if (attribute == null) {
   return "";
  }
  return attribute.format(DateTimeFormatter.ofPattern(LOCAL_DATE_FORMAT));
 }

 public static LocalDate from(final String attribute) {
  // 4. isEmpty() 와 같기에 스페이스가 존재하는 문자열을 체크하지 못합니다. (ex. "  ")
  if (!StringUtils.hasLength(attribute)) {
   return null;
  }
  final String format = getFormat(attribute);
  validationCheck(format, attribute);
  return LocalDate.parse(attribute, DateTimeFormatter.ofPattern(format));
 }

 private static String getFormat(final String attribute) {
  // 5. 매직 넘버를 통해 비교하고 있으며, 가독성이 좋지 못합니다.
  return attribute.length() == 10 ? LOCAL_DATE_FORMAT_WITH_HYPHEN : LOCAL_DATE_FORMAT;
 }

 // 6. validation 목적이 명시적이지 않습니다.
 private static void validationCheck(final String format, final String localDate) {
  // 7. SimpleDateFormat 은 다중 스레드 환경에서 권장되지 않습니다.
  final SimpleDateFormat df = new SimpleDateFormat(format);
  df.setLenient(false);
  try {
   df.parse(localDate);
  } catch (final ParseException e) {
   log.error("LocalDateParse Error : ", e);
   throw new RuntimeException();
  }
 }
}

개선 1

AS-IS의 문제점을 고려해서 첫 번째 개선을 적용했습니다.

클린 코딩에 맞춰 최신 컨벤션을 적용합니다.
불필요한 객체 생성과 validation을 최소화합니다.
public 메소드 개수와 사용법을 표준화합니다,
- 확장성을 고려하여 메소드 이름보다는 enum을 매개 변수로 활용하여 로직을 분리합니다.

public class LocalDateUtils {

 @Getter
 @RequiredArgsConstructor
 public enum LocalDateFormatterType {
  WITH_HYPHEN(DateTimeFormatter.ISO_LOCAL_DATE),
  NO_HYPHEN(DateTimeFormatter.ofPattern("yyyyMMdd")),
  ;

  private final DateTimeFormatter formatter;
 }


 public static String toString(final LocalDate attribute, final LocalDateFormatterType type) {
  if (attribute == null) {
   return "";
  }

  return attribute.format(type.formatter);
 }

 public static LocalDate from(final String attribute) {
  if (!StringUtils.hasLength(attribute)) {
   return null;
  }

  try {
   return LocalDate.parse(attribute);
  } catch (final DateTimeParseException ex) {
   return LocalDate.from(LocalDateFormatterType.NO_HYPHEN.formatter.parse(attribute));
  } catch (final Exception ex) {
   log.error("### LocalDateParse Error : ", ex);
   throw new RuntimeException(); // 차후 적절한 에러로 치환
  }
 }
}

개선 2

하지만 이렇게 적용하고 보니 Fommatter 로직도 enum에 응집시키고 싶었습니다.
그리고 Util 은 공통 라이브러리로 분리할 수 있도록 범용적으로 설계되어야 한다고 생각하기에 두 가지 관점을 추가했습니다.

null과 공백 문자열의 후속 처리는 메소드를 호출하는 곳에서 합니다.
프로젝트에 의존적인 커스텀 에러보다는, 사용하는 곳에서 핸들링할 수 있는 범용 에러를 반환합니다.

public class LocalDateUtils {

 @RequiredArgsConstructor
 public enum LocalDateFormatter {
  WITH_HYPHEN(
    DateTimeFormatter.ISO_LOCAL_DATE::format,
    input -> LocalDate.parse(input)
  ),
  NO_HYPHEN(
    input -> DateTimeFormatter.ofPattern("yyyyMMdd").format(input),
    input -> LocalDate.from(DateTimeFormatter.ofPattern("yyyyMMdd").parse(input))
  );

  private final Function<LocalDate, String> toString;
  private final Function<String, LocalDate> toLocaldate;
 }

 public static String toString(final LocalDate input, final LocalDateFormatter formatter) {
  return Optional.ofNullable(input)
    .map(formatter.toString)
    .orElseThrow(IllegalArgumentException::new);
 }

 public static LocalDate toLocalDate(final String text) {
  try {
   return WITH_HYPHEN.toLocaldate.apply(text);
  } catch (final DateTimeParseException ex) {
   return NO_HYPHEN.toLocaldate.apply(text);
  } catch (final Exception ex) {
   log.error("### toLocalDate Error : ", ex);
   throw ex;
  }
 }
}

마지막으로 개선간 사용한 테스트 케이스를 남기며 글을 마칩니다.

@DisplayName("LocalDateUtils")
class LocalDateUtilsTest {

 @DisplayName("문자열 -> LocalDate")
 @ParameterizedTest
 @CsvSource(
   value = {
     "2020-01-01",
     "2020-01-31",
     "2021-12-01",
     "2021-12-31",
     "20200101",
     "20200131",
     "20211201",
     "20211231"
   }
 )
 void toLocalDate(final String input) {
  final LocalDate localDate = LocalDateUtils.toLocalDate(input);
  assertThat(localDate).isNotNull();
  log.info("### {}", localDate);
 }

 @DisplayName("문자열 -> LocalDate 오류")
 @ParameterizedTest
 @CsvSource(
   value = {
     "''",
     "'  '",
     "2020-01-00",
     "2020-01-32",
     "2021-1201",
     "202112-31",
     "20200100",
     "20200132",
     "202112011",
     "2021123"
   }
 )
 void toLocalDate_error(final String input) {
  assertThrows(DateTimeParseException.class, () -> LocalDateUtils.toLocalDate(input));
 }

 @DisplayName("문자열 -> LocalDate null 오류")
 @ParameterizedTest
 @CsvSource(value = ",")
 void toLocalDate_error_null(final String input) {
  assertThrows(NullPointerException.class, () -> LocalDateUtils.toLocalDate(input));
 }

 public static Stream<LocalDate> LOCAL_DATES() {
  return Stream.of(
    LocalDate.of(2020, 1, 1),
    LocalDate.of(2020, 1, 31),
    LocalDate.of(2021, 12, 1),
    LocalDate.of(2021, 12, 31)
  );
 }

 @DisplayName("LocalDate -> 문자열 WITH_HYPHEN")
 @ParameterizedTest
 @MethodSource("LOCAL_DATES")
 void toString1(final LocalDate input) {
  final String string = LocalDateUtils.toString(input, LocalDateFormatter.WITH_HYPHEN);
  assertThat(string).isNotBlank();
  log.info("### {}", string);
 }

 @DisplayName("LocalDate -> 문자열 NO_HYPHEN")
 @ParameterizedTest
 @MethodSource("LOCAL_DATES")
 void toString2(final LocalDate input) {
  final String string = LocalDateUtils.toString(input, LocalDateFormatter.NO_HYPHEN);
  assertThat(string).isNotBlank();
  log.info("### {}", string);
 }
}

'수십억건에서 QUERYDSL 사용하기' 를 보고..

Hyunec — Sun, 19 Dec 2021 18:30:56 +0900

기술 영상의 요약이나 후기는 웬만하면 작성하지 않는 편입니다. 하지만 우아콘 2020의 이동욱 님 발표 영상은 하나하나가 너무나도 실무적이고 주옥같은 내용들 뿐이라서 꼭 기억하고 싶은 마음에 정리해봅니다.

[우아콘2020] 수십억건에서 QUERYDSL 사용하기

테스트 환경

OpenJDK 1. 8.0_252
Querydls_JPA 4.2.1
AWS Aurora MySQL 5.6 1.19.6

1. 워밍업

extends / implements 사용하지 않기

JPAQueryFactory 를 Bean 으로 사용함으로서 extends/implemets 를 제거할 수 있습니다.

발표 자료에는 없지만 JPAQueryFactory를 Bean으로 설정해주는 작업이 필요합니다.

@Configuration
public class QueryDslConfig {

   @PersistenceContext
   private EntityManager entityManager;

   @Bean
   public JPAQueryFactory jpaQueryFactory() {
      return new JPAQueryFactory(entityManager);
   }
}

영상을 보면서 회사 코드와 사이드 프로젝트들을 점검해보니, 모두 extends/implements를 사용하고 있었습니다. 아마 김영한 님의 강의에서 가져온 것 같습니다.
그리고 사이드 프로젝트에서는 Configuration으로 했지만, 회사코드에서는 각 Impl에서 new JPAQueryFactory(em); 를 하고 있었어 리팩토링 해야겠다고 생각했습니다.

하지만 아무리 생각해봐도 영상 내용으로의 개선이 더 낫다는 생각이 들지 않았습니다.
Custom으로 선언하고, Impl에서 구현하는 것이 클래스는 많아질지라도 유지보수 편의성을 위해 역할을 나누고 가독성을 향상하는 것이 더 좋다고 생각해서였습니다.

마침 댓글을 보니 저와 비슷한 생각을 하신 분이 있어 남깁니다.

동적 쿼리

BooleanExpression 을 사용하면 조건문의 가독성이 높아지고, null 을 반환하게 되더라도 Where 절에서 조건이 무시되기 때문에 안전합니다.

링크의 블로그에 좀 더 많은 내용이 있습니다.

[Querydsl] 다이나믹 쿼리 사용하기

안녕하세요! 이번 시간에는 Querydsl에서의 다이나믹 쿼리를 어떻게 작성하면 좋을지에 대해 진행합니다. 처음 Querydsl을 쓰시는 분들이 가장 많이 실수하는 부분이니 그럼 시작합니다! 모든 코드

jojoldu.tistory.com

2. 성능개선 - Select

Querydsl의 exist 금지

exist는 조건에 맞는 값을 찾으면 바로 반환하지만 count 쿼리는 전체 행을 모두 조회함으로 성능이 떨어지며, 이 차이는 스캔 대상이 앞에 있을수록 커집니다.

Querydsl 의 exist 는 내부적으로 count 쿼리를 사용하고 있기에, limit(1) 을 직접 구현해서 사용하는 것이 좋습니다.

cross join 회피

Hibernate 의 문제이기에 Spring Data JPA 도 동일하게 발생합니다. 명시적 join 을 통해 해결합니다.

Entity 보다는 Dto를 우선

Entity를 직접 조회하면 단순 조회 기능에서의 성능 이슈 요소가 있습니다.

하이버네이트 1차, 2차 캐시 문제 발생
불필요한 칼럼을 조회합니다.
@OneToOne N+1 쿼리 발생

아래에서는 이슈를 해결할 수 있는 몇 가지 방법들을 소개합니다. 결론적으로 실시간으로 Entity 변경이 필요한 경우엔 Entity를, 성능 개선이나 대량의 데이터 조회가 필요한 경우엔 Dto를 조회하는 것을 추천합니다.

#1 조회컬럼 최소화하기

#2 불필요한 컬럼 조회 하지 않기

#3 @OneToOne 에서의 N+1 문제

N+1 문제는 @OneToOne(fetch = FetchType.LAZY) 설정으로도 해결되지 않으며, Fetch Join 의 사용을 추천합니다.

링크의 블로그에 좀 더 많은 내용이 있습니다.

[JPA] @OneToOne에서 Fetch 전략을 Lazy로 설정했을때 발생하는 이슈

Lazy Loading JPA의 유일한 단점은 사용하기 쉬운만큼 성능적인 측면에서 발생할 수 있는 이슈를 간과하기 쉽다는 것인데, 성능이 안나올때 가장 먼저 고려해봐야할 부분이 즉시로딩(EAGER LOADING)으로

1-7171771.tistory.com

#4 연관된 Entity의 save를 위해서는 반대편 Entity의 ID만 있으면 된다.

#5 distinct 사용시에는 필요한 컬럼만 조회해서 사용합니다.

Group By 최적화

order by null 을 통해 Filesort 를 제거할 수 있지만 Querydsl 에서는 지원되지 않습니다.

OrderByNull 을 직접 구현함으로서 해결할 수 있습니다. 하지만..

Using filesort는 정렬이 필요한 데이터를 메모리에 올리고 정렬 작업을 수행한다는 의미로, 이미 정렬된 인덱스를 사용함으로써 해결할 수 있습니다. 영상에서는 우리가 사용하는 모든 Group By 가 index를 탄다는 보장이 없기에 말하고 있습니다.

하지만 8.0 이상을 사용하는 환경이라면 더 이상 고려하지 않아도 됩니다.

Previously (MySQL 5.7 and lower), GROUP BY sorted implicitly under certain conditions. In MySQL 8.0, that no longer occurs, so specifying ORDER BY NULL at the end to suppress implicit sorting (as was done previously) is no longer necessary. However, query results may differ from previous MySQL versions. To produce a given sort order, provide an ORDER BY clause.

MySQL :: MySQL 8.0 Reference Manual :: 8.2.1.16 ORDER BY Optimization

8.2.1.16 ORDER BY Optimization This section describes when MySQL can use an index to satisfy an ORDER BY clause, the filesort operation used when an index cannot be used, and execution plan information available from the optimizer about ORDER BY. An ORDER

dev.mysql.com

마지막으로 Paging 이 필요하지 않고 정렬 건수가 적다면 WAS에서 정렬하는 것을 추천합니다.

일반적으로 WAS 리소스가 DB 리소스보다는 여유 있고 저렴하기 때문입니다.

커버링 인덱스

Cluster Key 인 PK 로 key 를 조회하고 SELECT 컬럼을 조회한다.

커버링 인덱스를 사용할 땐 inline view (from 절의 subQuery)에서 커버링 인덱스를 통해 필터를 하도록 하는 게 일반적이지만, JPQL은 from 절의 서브 쿼리를 지원하지 않아 직접 구현해야 합니다.

링크의 블로그에 좀 더 많은 내용이 있습니다.

1. 페이징 성능 개선하기 - No Offset 사용하기

일반적인 웹 서비스에서 페이징은 아주 흔하게 사용되는 기능입니다. 그래서 웹 백엔드 개발자분들은 기본적인 구현 방법을 다들 필수로 익히시는데요. 다만, 그렇게 기초적인 페이징 구현 방

jojoldu.tistory.com

1. 커버링 인덱스 (기본 지식 / WHERE / GROUP BY)

일반적으로 인덱스를 설계한다고하면 WHERE 절에 대한 인덱스 설계를 이야기하지만 사실 WHERE 뿐만 아니라 쿼리 전체에 대해 인덱스 설계가 필요합니다. 인덱스의 전반적인 내용은 이전 포스팅을

jojoldu.tistory.com

3. 성능 개선 - Update/Insert

일괄 Update 최적화

Dirty Checking - 실시간 비즈니스 처리, 실시간 단건 처리
Querydsl.update - 대량의 데이터를 일괄로 Update 처리

주의할 점은 일괄 업데이트는 영속성 컨택스트의 1차 캐시 갱신이 안됨으로 Cache Eviction 이 필요합니다.

JPA로 Bulk Insert는 자제한다.

JPA 에서는 Insert 합치기가 적용되지 않는다.

// 3번의 DB 연결이 필요한 비효율적인 insert
INSERT INTO table_a (subject, content)
VALUES ('sub1', 'con1');
INSERT INTO table_a (subject, content)
VALUES ('sub2', 'con2');
INSERT INTO table_a (subject, content)
VALUES ('sub3', 'con3');

// 1번의 DB 연결로 개선한 효율적인 insert
INSERT INTO table_a (subject, content)
VALUES ('sub1', 'con1'),
       ('sub2', 'con2'),
       ('sub3', 'con3');

즉 위와 같은 성능 개선을 할 수 없다는 뜻입니다.

영상에서 JdbcTemplate를 말하지만 type safe 하지 않은 단점과 함께 EntityQL를 소개합니다. 하지만 이도 설정과 사용법에 단점을 가지고 있으므로 선택적으로 사용해야 된다고 말합니다.

저는 Spring 진영에서 공식적으로 밀어주는 JOOQ를 추천합니다. starter 가 존재하기에 세팅도 쉽고, 사용 경험도 매우 좋았습니다.

마무리

JPA, QueryDSL은 편리하지만 결국 DB에 쿼리를 날려서 조회하는 것이기에, 그 과정을 잘 이해하고 고민해야 합니다.

생각해보니 지금까지는 데이터가 적은 환경에서만 일하고 공부했기에, JPA를 심도 있게 사용하지 못했었습니다. 그러다 보니 문법과 기본적인 사용법은 알지만, 실무에서의 고급 활용을 위한 이해가 부족합니다.

물론 지금의 회사에서도 JPA, Querydsl을 사용하긴 하지만, 아직은 JOOQ의 사용이 더 많습니다. DB 구성이 ORM 기술에 적합하지 않게 설계되어있고, Procedure도 많이 존재하기 때문이라고 생각합니다. 무엇보다도 사용하는 사람이 기술에 대한 이해도가 높고 잘 사용해야 되는데 저부터도 이해도가 부족하다는 것을 느꼈습니다.

다행히도 내년의 회사 과제 중 하나로 MSA 구성이 있습니다. 이때 성능 분석도 도입하고, 열심히 공부해서 JPA를 좀 더 적극적으로 사용해보고 싶습니다.

파이팅!!

Datadog 에서 GraphQL 모니터링 맛보기

Hyunec — Tue, 14 Dec 2021 23:44:25 +0900

이 글에서는 널리 쓰이는 모니터링 솔루션 중 하나인 datadog을 적용하면서 알게 된 정보를 기록해봅니다.

공식문서에 있는 내용은 언급만 하고 넘어가며, 완결되지 않은 이슈들도 있기에 맛보기로 생각하고 읽어주세요!

AS-IS

자동화된 모니터링 룰이 없으며, cloudwatch로 사후 모니터링만 가능.
datadog를 도입하기로 했으나, graphql이 제대로 지원되지 않음.

datadog 은 공식 문서가 잘 나와있는 편이기에 설치나 일반적인 세팅에는 어려움이 없었습니다. 특히 resource를 기반으로 제공되는 기능들이 강력해서 REST API를 쓰는 환경이라면 크게 어려움 없이 세팅이 가능했습니다. 하지만 당사에서 사용하는 graphql 은 resource 가 모두 POST /graphql로 통일되어 버리는 문제가 있어 커스텀 설정이 필요했습니다.

커스텀 설정으로 넘어가기 전 환경 변수로서 제공하는 기능들을 먼저 소개합니다.

환경 변수로 사용 가능한 기능

Tracing Java Applications

Datadog, the leading service for cloud-scale monitoring.

docs.datadoghq.com

1. 요청 고유 값

-Ddd.logs.injection=true
default=false
Enable automatic MDC key injection for Datadog trace and span IDs.

2. Query Param

-Ddd.http.server.tag.query-string=true
default=false

-Ddd.trace.header.tags={header_name}:{datagod_display_name}
- -Ddd.trace.header.tags=Content-Type:Content-Type-Name
default=null

4. Body

기본 기능 없음

Can trace http request / response? · Issue #2236 · DataDog/dd-trace-java

My company use datadog Java Trace Agent. Can trace http request / response? I can't manual at that.

github.com

커스텀 설정으로 사용 가능한 기능 (CustomTag)

1. Custom Tag 개발을 위한 기본 이해

APM 화면과 매칭하여 용어 설명

Span 관계

childSpan(Span) ↔︎ rootSpan(MutableSpan)

datadog의 모니터링 단위는 span으로 이루어져 있습니다.
span을 사용하는 곳에 @Trace 어노테이션 사용이 필수입니다.
custom tag는 항상 rootSpan 에도 기록하는 것이 모니터링 편의상 좋습니다.
Span과 MutableSpan 은 캐스팅이 필요하며, 서로 다른 라이브러리를 참조하고 있기에 미묘하게 사용법이 다릅니다.

final Span childSpan = GlobalTracer.get().activeSpan();
final MutableSpan rootSpan = ((MutableSpan) GlobalTracer.get().activeSpan()).getLocalRootSpan();

// error 처리를 위한 사용법이 서로 다름
childSpan.setTag(Tags.ERROR,true);
rootSpan.setError(true);

customTag ↔︎ hostTag

hostTag - 대시보드, 메트릭 등에서 감지되는 tag로 사전 정의되었기에 환경 변수를 통해 사용 가능합니다.
customTag - 임의로 주입할 수 있지만, 대시보드, 메트릭 등에서 감지되는 않는 tag입니다.

2. Custom Tag 사용을 위한 Component 만들기

public class DatadogSender {

 private static final String GRAPHQL_RESOURCE_PREFIX = "/graphql";
 private static final String ERROR_CODE_TAG_KEY = "error.error_code";
 private static final String USERNAME_TAG_KEY = "user.username";

 @Trace
 public static void setTag(final String key, final Object value) {
  final Span childSpan = GlobalTracer.get().activeSpan();
  final MutableSpan rootSpan = ((MutableSpan) GlobalTracer.get().activeSpan()).getLocalRootSpan();

  childSpan.setTag(key, String.valueOf(value));
  rootSpan.setTag(key, String.valueOf(value));
 }

 @Trace
 public static void setErrorTag(final GraphQLError error) {
  final Span childSpan = GlobalTracer.get().activeSpan();
  final MutableSpan rootSpan = ((MutableSpan) GlobalTracer.get().activeSpan()).getLocalRootSpan();

  childSpan.setTag(Tags.ERROR, true);
  rootSpan.setError(true);

  // errorMsg 와 errorCode 는 항상 기록됩니다.
  setTag(DDTags.ERROR_MSG, error.getMessage());
  setTag(ERROR_CODE_TAG_KEY, GraphQLExceptionUtils.errorCode(error));

  // stackTrace, ResourceName, Principal 은 가져올 수 있는 경우만 기록됩니다.
  setTag(DDTags.ERROR_STACK, GraphQLExceptionUtils.stackTrace(error));
  setResourceNameTag(GraphQLExceptionUtils.resourceName(error));
  setPrincipalTag();
 }

 public static void setResourceNameTag(final String value) {
  final String resourceName = GRAPHQL_RESOURCE_PREFIX + (value.startsWith("/") ? value : "/" + value);
  setTag(DDTags.RESOURCE_NAME, resourceName);
 }

 public static void setPrincipalTag() {
  Optional.ofNullable(SecurityContextHolder.getContext().getAuthentication().getPrincipal())
    .filter(UserPrincipal.class::isInstance)
    .map(UserPrincipal.class::cast)
    .ifPresent(principal -> setTag(USERNAME_TAG_KEY, principal.getUsername()));
 }
}

모니터링 편의상 rootSpan에도 항상 기록해주는 것이 좋기 때문에 헬프성 Component를 구현했습니다.
실무에서 사용하는 Component에서 일부 기능만을 가져와 각색한 것이기에 흐름만 이해해주시길 바랍니다.

요점은 childSpan과 rootSpan을 항상 같이 사용해주고, error 처리는 handler에서 GraphQLError를 통해 한다는 것입니다.

3. GraphQL에서의 사용

이제 제일 고생했던 GraphQL에 적용입니다.

글의 처음에 쓴 것처럼 datadog 은 아직 GraphQL을 지원하지 않고 있습니다.

공식 support 채널에도 요청했지만 준비 중이라고 기달려달라는 답변만..

AOP를 쓰면 되겠지라는 생각으로 접근해서 requestJson의 기록은 성공했지만, resourceName 은 쉽지 않았습니다.

GraphQL의 특성상 requestBody를 파싱해야 resourceName 이 나오는데 AOP를 설정이 힘들었습니다.
처음에는 프론트의 도움을 받아 resourceName을 별도의 key로 빼려고 생각했지만 프론트의 작업량이 너무 많아 취소했고, 어쩔 수 없이 우회 안을 생각해야만 했습니다.

그러다 로그인 요청을 제외한 모든 요청이 인가가 필요하다는 것에 착안해서 PreAuthorize에 AOP를 거는 생각을 했고 성공했습니다.

@Aspect
@Component
@RequiredArgsConstructor
public class GraphQLDatadogAspect {

 @Pointcut("@annotation(org.springframework.security.access.prepost.PreAuthorize)")
 public void preAuthorizePointCut() {
 }

 @Before("preAuthorizePointCut()")
 public void beforePreAuthorize(final JoinPoint joinPoint) {
  DatadogSender.setResourceNameTag(joinPoint.getSignature().getName());
 }

 @Before(value = "execution(* graphql.kickstart.execution.GraphQLObjectMapper.readGraphQLRequest(..))")
 public void graphqlRequest(final JoinPoint joinPoint) {
   ...
 }
}

성공과 실패건 모두 resourceName 이 보입니다.

하지만 실패 건의 경우 status_code는 200이고 좌측에 빨간 불이 들어온 것을 볼 수 있습니다. 이 이유는 예외 처리에서 설명하겠습니다.

4. 예외 처리

Error Span 처리 흐름

제가 다니는 회사를 포함하여 많은 회사들은 RESTful API를 사용하지 못하고 있습니다.
대표적인 것 중 하나가 status_code의 별도 관리 입니다.
보통 요청 결과가 에러이더라도 status_code는 200으로 받고 respone body에 별도의 code를 사용합니다.

시퀀스 다이어그램을 보면 내부 에러 코드가 9999 인 경우에만 error로 간주하여 setErrorTag()를 거치게 됩니다.

그리고 이 과정에서 status_code는 200으로 유지되지만 span 은 error로 처리되어 모니터링 대상이 됩니다.

200 ok 이지만 error span 으로 체크되고, stackTrace 가 기록 됩니다.

모니터링 편의성 & 자동화

위에서 작업한 errorSpan 은 datadog에서 지원하는 Monitors 기능을 통해 slack 알림이 가능합니다.

Create Monitors

Create monitors

docs.datadoghq.com

slack 알림

마치며

저는 백엔드 개발자로서 개발보다 중요한 게 운영이고, 그러기 위해 모니터링 자동화가 필수적이라고 생각합니다.

비록 한글 자료가 적어 설정하는 데에는 정말 고생했지만, 목표한 바를 이뤄 조금 만족했습니다.

하지만 datadog 은 정말 많은 integration을 제공해주고 있고 이것들을 조금씩 설정해나가야 하기에 아직 할 것은 많아 보입니다..

이외에도 작업하거나 시행착오 겪은 것들이 많지만 모두 기록하기는 힘들어 키워드만 남기면서 글을 마무리합니다.

cloudwatch와 datadog logs의 연동
datadog agent의 한계상 response body의 기록은 5000byte
유저의 액션을 모두 추적 - RUM(프런트)과 APM(백엔드)의 연계
Session Replay 기능

어느 새벽에 작성하는 첫 회고록

Hyunec — Fri, 10 Dec 2021 06:57:24 +0900

백엔드 개발자 커리어를 시작한 지 1년 4개월이 된 어느 날 새벽, 소용돌이치는 생각들을 정리하려 쓴다 쓴다 생각만 했던 회고를 기록해봅니다.

개발자가 되기 위해..

열정적이지 못했던 인프라/기술지원을 그만두면서 개발자가 되기 위한 방법을 찾았습니다. 늦은 나이에 시작한 개발이기에 돈보다 중요한 건 시간이었습니다. 그래서 국비 지원보다는 부트캠프가 좋다고 판단했고, 몇 개의 비교 끝에 코드스쿼드 교육기관을 선택했습니다. 그리고 그것은 저에게 최고의 선택이었습니다.

기존의 주입식 교육이 아닌 자기 학습을 위한 교육 방법과 몰입할 수 있는 가이드라인을 제시해주었고, 저에게는 꽤나 맞는 교육법이었습니다. 교육기간 내내 교육장에서 가장 늦게 나가는 학생 중 한 명이었고 배수진을 치고 온 만큼 절박하게 공부했습니다.

그리고 수료와 동시에 백엔드 개발자로서 커리어를 시작했습니다.

저는 이전 회사의 경험으로 IT 전반에 대한 지식이 있었기에, 혼자 하는 공부보다는 실무의 사이클을 경험하는 것이 훨씬 중요하다고 생각했습니다. 그렇기에 준비를 더 해야 되는 대기업보다는 지금 갈 수 있는 가장 빠른 회사를 선택했고, 처음에는 작은 실무의 사이클을 개발하고 경험할 수 있다는 것만으로도 너무 만족스러웠습니다.

하지만 작은 스타트업의 단점들이 나오기 시작했고, 제대로 된 시니어가 없는 상황에서의 몇 번의 개선 시도는 실패하기 일쑤였습니다. 성장이 고팠던 저는 불만이 쌓였고, 그렇게 1년 동안 2개의 회사를 거쳤습니다. 짧은 기간에 2번의 이직을 하면서 힘들기도 했지만 하루하루를 코드스쿼드 때보다 더 몰입해서 공부했고, 어떻게 성장할 것인가에 대한 작은 단서를 찾기도 했습니다.~~라고 생각했습니다.~~

슬럼프가 왔습니다.

이전의 회사는 구성원들의 연차도 적고, 아직 아이템도 뚜렷하지 않은 작은 스타트업이었습니다. 그렇다 보니 기획의 변경도 잦고, 기술의 깊이보다는 시간을 쏟아 해결할 수 있는 피쳐를 다수 개발하는 게 주 업무였습니다.

저는 지금의 환경에 필요한 최소한의 기술을 ~~베스트 프랙티스가 아닐지라도~~ 행할 수 있는 개발자가 좋은 개발자 라고 생각합니다. 그렇기에 야근이 강요되는 회사가 아니었음에도 항상 제가 원하여 막차를 타는 생활을 하면서 지금 필요한 피쳐 개발에 몰입했습니다. 아마 부족한 제 실력으로도 회사에 기여하고 있다는 소속감과 성장에 대한 기대감 덕분에 즐기며 일할 수 있었던 것 같습니다.

다행히 지금의 회사는 팀원들도 훌륭하고 깊이를 고려하며 성장할 수 있는 기반과 조금의 여유도 있는 훌륭한 환경입니다. 그러다 보니 개발 속도만 생각했던 이전과 다르게 깊이를 고민하면서 제 기술적 부족함을 직시할 수 있었습니다. 하지만 회사의 업무에서 새로운 기술의 학습과 적용, 일정을 저울질하다 보니 자괴감이 들었고, 그동안 잘 실천하지 못했던 설계의 중요성도 크게 느끼게 되었습니다.

그리고 가장 해서는 안 되는 것 중 하나인 타인과의 비교를 하기 시작했습니다.

xxx는 MSA를 하면서 대량 트래픽을 경험하고 있다던데 나는 뭐 하고 있는 거지..?

yyy는 연봉을 zzz만원이나 받는다는데..

사실 해결 방법은 알고 있습니다.

저는 저 자신을 나태하고 수동적이라고 생각합니다. 그래서 몰입을 위해 강한 제약 사항을 걸곤 합니다. 이전의 회사들에서 걸었던 빠른 개발 일정이 그것 입니다. 하지만 지금의 회사에서는 다른 시야를 가져야 되면서 오는 차이와 그 사이에서 오는 나에 대한 실망감과 괴리감이 슬럼프의 원인일 것입니다. 하지만 이것은 커리어 몇 년차쯤 겪는 번아웃 중 하나이고, 업무에 익숙하지 않은 지금이 지나면 괜찮아질 과도기입니다. ~~근데 난 아직 그 시기도 아니고, 다 알면서 왜 이럴까.. ㅠㅠ~~

그래서 다시 몰입을 위한 방법을 생각했습니다.

지금까지는 성장을 위해서 순수 기술에 대한 공부만, 시간을 쏟는 방법으로만 했습니다. 특히 '함께 자라기' 같은 책은 실무와는 먼 이론이라고만 생각했습니다. 하지만 슬럼프를 겪으면서 순수 기술에 대한 내용이 아니면 보지도 않던 유튜브를 보면서 마음을 정리했고, 개발바닥의 유튜브가 참 많은 도움이 되었습니다.

몰입과 함께 자라기에 대해 생각하게 해준 영상

마치며

아마 옛날이었다면 이런 주제의 글을 쓰는 것을 굉장히 두려워했을 것입니다.

하지만 공부하면서 느낀 것은 모두 나와 같은 시기를 겪었거나 겪을 것이고, 약점이라고 생각하는 것을 공개하는 것이 창피하다고 생각할 필요가 없다는 것입니다. 오히려 하나의 팀이나 동료로서 더 좋은 방향으로 빌드업할 수 있도록 공유하는 것이 더 가치 있다는 것을 깨달았습니다.

저 또한 이렇게 글을 쓰면서 소용돌이치는 생각들을 정리하는 좋은 시간이 되었습니다.

아직 해결하지 못한 슬럼프이지만 곧 나아질 것을 기대하며 글을 마칩니다.

느슨한 결합도의 설계를 위해! (2)

Hyunec — Sat, 4 Dec 2021 16:39:12 +0900

요구 사항 정리와 AS-IS 분석은 끝났지만 설계하기 전에 개발 범위 산정과 제약 조건을 먼저 생각해야 합니다.

목표 달성을 위한 리팩토링은 끝이 없기에 일정과 범위를 조율해야 하고, 개인의 이해도는 차이가 있기에 실무의 설계는 범용적인 구성을 해야 합니다. ~~디자인 패턴 공부의 필요성을 느끼는 요즘입니다.~~

이런 생각을 가지고 개발한 과정을 기록해봅니다.

개발 범위 산정

최소 개발 범위는 심플하지만 앞으로 알림 톡의 종류가 많아질 것을 대비하면 AlarmGqlService의 호출도 interface로 만들고 내부 서비스들도 표준화시키는 것이 좋을 것 같습니다.

하지만 개발 범위를 AlarmGqlService까지 확장하면 입력부에 대한 검증과 interface 설계에 따른 리팩토링도 추가되어야 해서 '알림 톡 호출 주소 변경'이라는 컴팩트한 목표에 맞지 않다고 생각했습니다. 그리고 사실 최소 범위도 이미 강한 결합도를 가졌기에 이 것을 해결하는 것이 우선이라고 생각했고, SysSmsSendService 정도는 가져갈 수 있다고 판단해서 개발 범위를 확정했습니다.

제약 조건

2 영업일 이내의 개발 기간
환경변수의 관리 주체를 분리한다.
공통 로직을 분리하며 중복되는 로직을 최소화
상속보다는 조합을 사용하자.
최신 컨벤션에 맞는 코드 정리
테스트 방법에 대한 고려

개발 기간이라는 단어에는 설계와 QA도 포함되어야 한다고 생각한 때가 있었습니다.

하지만 실무를 하다 보니 개발과 배포는 직결되지 않고, QA 후 돌아오거나 기타 이슈로 늘어지는 일정은 예상하기 힘들기에 분리해야 된다는 것을 느꼈습니다. 좀 더 복잡한 업무라면 분석과 설계 기간도 분리했겠지만 이번 업무는 같이 해도 될만한 분량이라고 판단했고, 최소한의 개발 기간으로서 2일을 산정했습니다.

설계

AS-IS를 분석하면서 공통부로 분리해야 될 로직이 보였고, 사이드 프로젝트에서 연습한 JWT 적용의 패턴에서의 Provider 가 생각났습니다.

Spring Security 로 회원 가입을 구현해보자 (2)

Step 3. JWT 적용 1. 준비 // build.gradle dependencies { implementation 'io.jsonwebtoken:jjwt-api:0.11.2' runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.2' runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11..

hyune-c.tistory.com

그래서 설계한 모델입니다. 전송을 위한 책임을 ApiGetwaySender라는 정보 전문가에게 위임함으로써 일련 과정을 모듈화 시켰습니다.

1. 환경 변수 관리

// application.yml
aws:
  lambda:
    apiGateway:
      baseUrl: ${API_GATEWAY_BASE_URL}
      username: ${API_GATEWAY_USERNAME}
      password: ${API_GATEWAY_PASSWORD}

민감정보는 환경 변수로 관리합니다.

@Getter
@Configuration
public class ApiGatewayConfiguration {

 @Value("${aws.lambda.apiGateway.baseurl}")
 private String baseUrl;

 @Value("${aws.lambda.apiGateway.username}")
 private String username;

 @Value("${aws.lambda.apiGateway.password}")
 private String password;
}

그것을 주입받는 주체로서 Configuration을 만듭니다.

2. 공통 변수, 로직 관리

@Getter
@Component
@RequiredArgsConstructor
public class ApiGatewayProvider {

 // API GATEWAY 통신 오류
 public static final Supplier<CustomGraphQLException> BAD_RESPONSE_EXCEPTION =
   CustomGraphQLException.supply("M9999");

 private String baseUrl;
 private String username;
 private String password;

 public static final String SUCCESS_TEXT = "Success";
 public static final String SENDING_NUMBER = "15000000";

 private final ApiGatewayConfiguration configuration;
 private final RestTemplate restTemplate;

 @PostConstruct
 private void postConstruct() {
  baseUrl = configuration.getBaseUrl();
  username = configuration.getUsername();
  password = configuration.getPassword();
 }

 public String generateJwt() {
  final Request request = Request.of(GET_SESSION.getUrl(), username, password);
  final HttpHeaders headers = GET_SESSION.getHeaderType().getHttpHeadersFunction().apply("");
  final HttpEntity<Request> httpEntity = new HttpEntity<>(request, headers);

  final Response response = restTemplate.exchange(
      baseUrl + GET_SESSION.getUrl(),
      GET_SESSION.getHttpMethod(),
      httpEntity,
      Response.class
    )
    .getBody();

  return Optional.ofNullable(response)
    .map(Response::getToken)
    .orElseThrow(BAD_RESPONSE_EXCEPTION);
 }

 @Data
 @AllArgsConstructor(staticName = "of")
 private static class Request {

  private String url;
  private String username;
  private String password;
 }

 @Data
 @AllArgsConstructor
 @NoArgsConstructor
 private static class Response {

  private String token;
 }
}

Provider는 이 모듈에서 공통으로 사용되는 변수와 로직을 모아놓은 것으로 v2에서는 모든 요청에 jwt 가 필요합니다. 따라서 jwt를 가져올 수 있는 로직을 만들고 필요한 곳에서 호출할 수 있도록 합니다.

3. 각 구현 Service 별 발송과 검증을 위한 값을 enum으로 관리

@Getter
@RequiredArgsConstructor
public enum ApiGatewayRequestType {

 GET_SESSION("/sessions", WITHOUT_AUTHORIZATION, POST, "", Integer.MAX_VALUE),
 xxxxx1("/kakao/xxxxx1", WITH_AUTHORIZATION, POST, "xxxxx1", 50),
 xxxxx2("/kakao/xxxxx2", WITH_AUTHORIZATION, POST, "xxxxx2", 10),
 xxxxx3("/kakao/xxxxx3", WITH_AUTHORIZATION, POST, "xxxxx3", 1000),
 RESET_PASSWORD("/kakao/resetpw", WITH_AUTHORIZATION, POST, "reset_pw", 10),
 ;

 private final String url;
 private final ApiGatewayHeaderType headerType;
 private final HttpMethod httpMethod;
 private final String kakaoTemplateCode;
 private final int limit;
}

@Getter
@RequiredArgsConstructor
public enum ApiGatewayHeaderType {

 WITH_AUTHORIZATION(jwt -> {
  final HttpHeaders headers = new HttpHeaders();
  headers.setContentType(MediaType.APPLICATION_JSON);
  headers.setAccept(Collections.singletonList(MediaType.APPLICATION_JSON));
  headers.setBearerAuth(jwt);
  return headers;
 }),
 WITHOUT_AUTHORIZATION(ignored -> {
  final HttpHeaders headers = new HttpHeaders();
  headers.setContentType(MediaType.APPLICATION_JSON);
  headers.setAccept(Collections.singletonList(MediaType.APPLICATION_JSON));
  return headers;
 }),
 ;

 private final Function<String, HttpHeaders> httpHeadersFunction;
}

최초 jwt를 가져올 때는 jwt 가 없는 header 가 필요하며, 혹여 이후에도 jwt 가 필요 없는 요청이 생기는 경우를 위해 enum으로 관리합니다.

4. 검증, 후처리 로직과 발송 로직의 분리

@Service
@RequiredArgsConstructor
public class ApiGatewaySender {

 private final ApiGatewayProvider apiGatewayProvider;
 private final RestTemplate restTemplate;

 public ResponseEntity<Response> request(final ApiGatewayRequestType requestType, final Object body) {
  final String jwt = apiGatewayProvider.generateJwt();
  final HttpHeaders headers = requestType.getHeaderType().getHttpHeadersFunction().apply(jwt);
  final HttpEntity<?> httpEntity = new HttpEntity<>(body, headers);
  final String url = apiGatewayProvider.getBaseUrl() + requestType.getUrl();

  return restTemplate.exchange(
    url,
    requestType.getHttpMethod(),
    httpEntity,
    Response.class);
 }

 @Data
 @AllArgsConstructor
 @NoArgsConstructor
 @Builder
 public static class Response {

  private String messageId;
  private String to;
  private String status;
  private String text;

  public boolean isSuccess() {
   return ApiGatewayProvider.SUCCESS_TEXT.equals(text);
  }
 }
}

발송의 책임을 ApiGetwaySender로 모으고 공통 응답에서 성공 여부를 검증하는 메서드도 제공합니다.

5. 기존 구현 Service를 검증, 후처리 로직만 남을 수 있도록 개선

@Service
@RequiredArgsConstructor
public class ResetPasswordService {

 // 1일 최대 10개까지 발송하실 수 있습니다.
 private static final Supplier<CustomGraphQLException> RESET_PASSWORD_EXCEPTION =
   CustomGraphQLException.supply("M0001");
 private static final ApiGatewayRequestType REQUEST_TYPE = RESET_PASSWORD;

 private final SysSmsSendService sysSmsSendService;
 private final ApiGatewaySender apiGatewaySender;

 public void send(final String receiveNumber, final String paramsPassword) {
  final Request request = Request.of(receiveNumber, paramsPassword);
  sendValidation(request.getReceiveNumber());
  final ResponseEntity<Response> exchange = apiGatewaySender.request(REQUEST_TYPE, request);

  Optional.ofNullable(exchange)
    .map(HttpEntity::getBody)
    .filter(Response::isSuccess)
    .ifPresentOrElse(
      response -> sysSmsSendService.insertSysSmsSend(
        null,
        response.getMessageId(),
        response.getTo(),
        REQUEST_TYPE.getUrl(),
        response.getStatus()
      ),
      () -> {
       throw BAD_RESPONSE_EXCEPTION.get();
      }
    );
 }

 private void sendValidation(final String receiveNumber) {
  final int sendCount = sysSmsSendService.getResetPasswordLimitCount(receiveNumber);
  if (sendCount >= REQUEST_TYPE.getLimit()) {
   throw RESET_PASSWORD_EXCEPTION.get();
  }
 }

 @Data
 @AllArgsConstructor
 @NoArgsConstructor
 @Builder
 public static class Request {

  private String templateCode;
  private String receiveNumber;
  private String sendingNumber;
  private String paramsPassword;
  private String paramsLoginUrl;

  public static Request of(final String receiveNumber, final String paramsPassword) {
   final String paramsLoginUrl = generateParamsLoginUrl();

   return new Request(
     REQUEST_TYPE.getKakaoTemplateCode(),
     SplitAndJoinUtils.joinCountryContactsNumber(receiveNumber),
     SENDING_NUMBER,
     paramsPassword,
     paramsLoginUrl
   );
  }

  private static String generateParamsLoginUrl() {
   if (isStageServer()) {
    return "https://stage.company.com/login";
   }

   if (isDevServer()) {
    return "https://dev.company.com/login";
   }

   return "https://prod.company.com/login";
  }
 }
}

이제 발송은 ApiGatewaySender에게 위임하고 검증, 후처리, 발송에 필요한 값 역시 ApiGatewayRequestType를 통해 가져와 로직을 단순화 시킬 수 있습니다. 그리고 ApiGatewayRequestType를 클래스 변수로 관리함으로써 성능의 향상도 기대할 수 있습니다.

6. 테스트

// 실제 알림톡을 받으려면 @disable 를 풀고 receiveNumber 를 기록합니다.
@SpringBootTest
class ResetPasswordServiceTest {

 @Autowired ResetPasswordService passwordService;

 @DisplayName("알림톡 - 비밀번호 초기화")
 @Test
 void getJwt() {
  // given

  // when
  passwordService.send("010-****-****", "12345");

  // then

 }
}

영향도를 줄이기 위해서는 mock 을 활용하여야겠지만, 이미 mock을 활용한 통합 테스트가 존재하고 있었습니다. 그리고 개발간 매번 postman을 활용하는 것은 힘들었기에 샘플 테스트를 만들고 merge 시에는 @Disabled로 변경했습니다.

마치며

앞의 과정들을 통해 목표한 수준의 느슨한 결합도는 달성했지만, 실무라는 제한적인 환경이다 보니 좀 더 만족스럽게 하지 못한 부분이 있습니다. 예를 들면 jwt 캐싱, 인터페이스를 통한 설계, 역할을 분리해서 조합으로 구성, 특히 이 글을 작성하게 영감을 준 로치의 글에서 나온 Validator의 분리입니다.

하지만 그러기 위해서는 목표 범위 이상을 개선해야 했고, 무엇보다 제 디자인 패턴 지식이 부족함을 느꼈습니다.

글을 마치며 제가 생각하는 다음 스텝의 설계를 남겨봅니다.

2021.12.03 - [Computer Science/Software Architecture] - 느슨한 결합도의 설계를 위해! (1)

느슨한 결합도의 설계를 위해! (1)

Hyunec — Fri, 3 Dec 2021 22:29:39 +0900

높은 응집도와 느슨한 결합도의 설계는 객체 지향을 공부하는 사람이라면 누구나 고민하는 주제입니다.

공부는 했었지만 부끄럽게도 잘 활용하지 못하던 중 같이 공부하는 로치의 글을 보고, 또 운 좋게 설계가 필요한 업무를 맡게 되면서 개발한 내용을 기록해봅니다.

응집도와 결합도

응집도와 결합도는 소프트웨어 품질을 결정 짓는 요소이다. 대다수의 사람들은 코드를 작성할때 "응집도" 와 "결합도" 를 생각하지 않은채 관성적으로 코드를 적고는 한다. 응집도와 결합도는

devroach.tistory.com

업무 배경

알림 톡 발송의 주체는 외부 업체로 Lambda를 통해 연동되어 있습니다.
발송 기록은 저장되고 있습니다. (백엔드 - RDB, Lambda - DynamoDB)

개발 요건

Lambda API의 주소가 변경되었습니다. (v1 -> v2)
v2에는 jwt 인증이 추가되었습니다.
1. jwt 만료 시간은 5분이며 refresh token 은 없습니다.

AS-IS 분석

개행을 좀 더 의미 있게 할 수 있을 것 같습니다.
모든 환경 변수가 @Value로 각 서비스에 반복되어 주입되고 있습니다.
환경 변수 외의 공통 변수는 ApiGatewayCommon에 관리되고 있지만 좀 더 잘 관리할 수 있을 것 같습니다.
상수들이 public으로 선언되어 있습니다. 그리고 좀 더 일관성 있게 관리하고 싶습니다.
validation 로직이 반복되고 있습니다.
모든 서비스에서 Lambda 호출 로직이 반복되고 있습니다. 그리고 실패 로직이 너무 복잡합니다.
Request는 각 service 별로 다르기에 inner class로 만든 것은 좋지만, 좀 더 정제할 수 있을 것 같습니다.
Response는 모든 service에서 같기에 중복을 제거할 수 있을 것 같습니다.

AS-IS service 중 하나를 각색한 코드를 첨부하며 다음 글에서는 개선 과정을 기록해보겠습니다.

2021.12.03 - [Computer Science/Software Architecture] - 느슨한 결합도의 설계를 위해! (1)

@Service
@RequiredArgsConstructor
public class ResetPasswordService {

 // 1. 환경 변수로 관리되는 baseUrl
 @Value("${aws.lambda.apiGateway}")
 public String BASE_URL;

 // 2. public static final 변수들
 public static final String TEMPLATE_CODE = "/company/resetpw";

 public static final Supplier<CustomGraphQLException> RESET_PASSWORD_EXCEPTION =
   CustomGraphQLException.supply("M0001");

 public static final Integer RESET_PASSWORD_LIMIT = 10;

 private final RestTemplate restTemplate;

 private final SysSmsSendService sysSmsSendService;

 public void send(String receiveNumber, String paramsPassword) {
  Request request = Request.of(receiveNumber, paramsPassword);

  // 3. validation 로직과 일치하지 않는 메소드명
  int sendCount = sysSmsSendService.getResetPassword(request.getReceiveNumber());

  if (sendCount >= RESET_PASSWORD_LIMIT) {
   throw RESET_PASSWORD_EXCEPTION.get();
  }

  HttpEntity<?> entity = new HttpEntity<>(request, getHttpHeaders());

  ResponseEntity<Response> exchange =
    restTemplate.exchange(BASE_URL + TEMPLATE_CODE, POST, entity, Response.class);

  // 4. 복잡한 API 호출 정상 여부 판단
  if (isNull(exchange.getBody()) || isNull(exchange.getBody().getText())
    || !SUCCESS.equals(exchange.getBody().getText())) {
   throw CustomGraphQLException.supply("API GATEWAY 통신 오류").get();
  }

  // 5. 전송 기록
  sysSmsSendService.insertSysSmsSend(...);
 }

 public static class Request {

  private String templateCode;
  private String receiveNumber;
  private String sendingNumber;
  private String paramsPassword;
  private String paramsLoginUrl;

  public static Request of(String receiveNumber, String paramsPassword) {
   // 6. 카카오톡 templateCode
   String templateCode = "company_reset_pw";
   // 7. 작동 환경에 따라 달라지는 redirect url
   String paramsLoginUrl = "https://prod.company.com/login";
   if (isStageServer()) {
    paramsLoginUrl = "https://stage.company.co.kr/login";
   }
   if (isDevServer()) {
    paramsLoginUrl = "https://dev.company.co.kr/login";
   }
   return new Request(
     templateCode,
     SplitAndJoinUtils.joinCountryContactsNumber(receiveNumber),
     // 8. 공통으로 관리되는 발송 번호
     ApiGatewayCommon.SENDING_NUMBER,
     paramsPassword,
     paramsLoginUrl
   );
  }
 }

 // 9. 공통 응답
 public static class Response {

  private String messageId;
  private String to;
  private String status;
  private String text;
 }
}

DB 값을 enum 으로 표현해보자

Hyunec — Sat, 20 Nov 2021 19:57:15 +0900

enum 은 서로 연관된 상수들의 집합으로 반복적으로 사용되는 코드 값을 표현할 때 유용합니다.
실무에서는 개발 편의성을 위해 DB에 있는 업무 코드들을 표현하기도 합니다. (등급 코드, 사용 여부 등)

하지만 프로젝트가 나눠지면 매번 복사해줘야 되고, 변경점이 생기면 반영이 필요하기에 썩 좋은 아이디어는 아닙니다.
때문에 쉬운 방법으로는 코드 테이블을 만들거나, 최신의 개발에서는 코드 정보를 MSA로 나누기도 합니다.

그럼에도 불구하고 업무 성격상 변경이 매우 적은 경우에는 개발 편의성과 성능 향상을 위해 사용할 수 있기에 실무에서 해본 리팩토링 내용을 기록해봅니다.

Java Enum 활용기 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요? 우아한 형제들에서 결제/정산 시스템을 개발하고 있는 이동욱입니다. 이번 사내 블로그 포스팅 주제로 저는 Java Enum 활용 경험을 선택하였습니다. 이전에 개인 블로그에 E

techblog.woowahan.com

기존 코드의 문제

@Getter
@AllArgsConstructor
public enum RowStatusCd {

	U("USE"), // 사용
	N("UNUSE"), // 미사용
	D("DELETE"); // 삭제

	private String status;

	public static String USE = U.name();
	public static String UNUSE = N.name();
	public static String DEL = D.name();
}

위 코드는 사용 여부와 soft delete를 표현하는 실무 코드의 일부를 각색하여 리팩토링 했습니다.

U, N, D 은 DB 값이며, 그 의미를 enum으로 접근해야지 알 수 있습니다.
1. 향후 DB 값이 바뀐다면 enum 명 자체가 변경되어야 하므로 변경 여파가 큽니다.
1번의 문제를 보완하기 위해 static 변수를 사용했습니다.
1. 하지만 이 것이 DB 값과 직결된다는 것을 코드에서는 알 수 없습니다.

DB 값을 dataValue 로 명시한 코드

@Getter
@AllArgsConstructor
public enum RowStatusCode {

	USE("U"), 
	UNUSE("N"), 
	DELETE("D"), 
	;

	private final String dataValue;
}

DB에서는 RowStatusCD로 축약되어 있었지만 애플리케이션으로 가져오면서는 축약하지 않고 RowStatusCode를 사용했습니다.
enum의 네이밍을 명시적으로 바꿈으로써 주석을 달 필요가 없어지고 사용하는 곳에서 의도를 바로 알 수 있게 하였습니다.
dataValue를 사용함으로써 static 변수를 사용하지 않아도 됩니다.

enum을 사용하는 곳에서 코드의 길이는 큰 차이가 없지만, DB 값이라는 명시성을 보여줄 수 있습니다.

// AS-IS
SYS_USER.ROW_STS_CD.in(RowStatusCode.USE, RowStatusCode.UNUSE),

// TO-BE
SYS_USER.ROW_STS_CD.in(USE.getDataValue(), UNUSE.getDataValue()),

좀 더 복잡한 실무 예시

@Getter
@AllArgsConstructor
public enum CreditCard {

	KB("02", "국민", "3455"),
	HANA("11", "하나", "3600"),
	NH("08", "농협", "3700"),
	;

	private final String dataValue; // DB 에 저장된 값
	private final String name;  // 카드명
	private final String bin;   // 카드빈 (카드사별로 할당되는 카드의 시작 값)

	public static CreditCard findByValue(final String value) {
		return Arrays.stream(CreditCard.values())
				.filter(e -> e.dataValue.equals(value))
				.findFirst()
				.orElseThrow(() -> new IllegalStateException("유효하지 않은 카드 정보 입니다."));
	}

	public static CreditCard findByCardNo(final String cardNo) {
		final String cardBin = cardNo.substring(0, 4);
		return Arrays.stream(CreditCard.values())
				.filter(e -> e.dataValue.equals(cardBin))
				.findFirst()
				.orElseThrow(() -> new IllegalStateException("유효하지 않은 카드 정보 입니다."));
	}
}

샘플 코드보다 좀 더 복잡한 실무에서의 제가 생각하는 best practice를 준비해봤습니다.

각 enum 이름은 쉽게 이해할 수 있는 업무 내용을 사용합니다.
각 enum에 매칭 되는 DB 값은 dataValue로 네이밍 합니다. (value로 직역하기에는 모호함이 있었습니다.)
필요에 따라 Arrays.stream 대신 EnumMap을 구성합니다.
실제 코드에서는 주석 내용을 팀 컨벤션으로 공유한 후 모두 삭제합니다.

리팩토링 전의 코드와 같은 형태를 취하려면, enum 이름에 dataValue가 있어야 합니다.

문법적으로 불가능하거니와 enum 이름이 '02' 면 업무 로직을 파악하는데 직관적이지 못합니다.

저는 클린 코드와 컨벤션을 준수하지만 기존 코드와의 일관성을 위해서는 일부 트레이드오프 해야 되는 부분도 있다고 생각합니다.

그렇기에 위의 코드를 실무에 적용하는 것은 조금 더 고민해보겠지만, 일반적인 enum과 DB값으로서의 enum을 구분해서 사용해야 된다는 것에 대한 고민을 이 글을 통해 말하고 싶습니다.

좋은 개발 문화란? - (2) 준비

Hyunec — Mon, 15 Nov 2021 15:43:46 +0900

소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다.

즉 소프트웨어 장인 정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.

- 소프트웨어 장인. 3장 소프트웨어 장인정신

이전 글에서는 실패와 개발 문화의 중요성에 대해 이야기했습니다.

이번 글에서는 지금 제 환경에서 시도할 수 있는 좋은 개발 문화의 준비를 기록합니다.

업무	설명	기간 산정	예시
A	외부 솔루션 도입	연구가 필요하기에 단순 표기가 어려움	모니터링 솔루션
B	단순 화면 기능 개발	단순 표기 가능	API response 변경
C	업무 이해도가 필요한 개발	리팩터링 범위에 따라 다름 (테스트, 구조 수정 등)	상품 구매 후처리 로직 변경
D	기 개발 건의 QA 처리	단순 표기 가능	B, C 의 QA 오류
E	기능 변화에 영향이 없는 개선 (보통 개발팀 한정)	범위에 따라 다름	형상 관리 도입, 테스트 케이스 작성

위의 제 루틴 업무를 정리한 것입니다.
저는 기획의 요청에 따라 'A~C'의 업무를 병행하면서 'D'의 업무도 처리하고 있습니다.

이 중에서 주로 문제가 되는 것은 'C' 겠죠.
과연 어느 정도까지 테스트를 작성해야 되고 구조를 수정해야 'D'를 원활히 처리할 수 있을까요?
어쩌면 'D'가 발생하지 않는다고 생각하고 개발해야 될까요?

'E'는 어떨까요?
가시화하기 힘든 개선이기 때문에 어려운 설득을 준비해야 되는데 '설득을 위한 준비'를 하는 시간을 어떻게 할애해야 할까요?

일반적으로는 이슈가 있어도 제대로 관리되지 않다가 터진 후에야 숙련된 개발자들이 일정 기간을 공들여 개선안을 적용합니다.
이후에도 이슈를 미리 감지하고 개선하는 것이 좋겠지만, 보통은 또 다음 이슈가 터질 때쯤에야 하게 됩니다.
루틴 업무를 하면서 가시화되지 않은 이슈 개선을 준비하고 설득하는 일은 보통의 모티베이션으로는 매우 힘든 일이기 때문입니다.
혹자는 '조금 불편하지만 잘되고 있는데 뭐 어때요?' 또는 '지금 문제가 되는 것이 아니니 당신의 개인 시간을 할애해서라도 하시면 됩니다.'라고 할 수 있습니다. 그리고 보통은 루틴 업무로 돌아가죠.

이미 이전 글에서 정답에 가까운 개발 문화를 가져왔는데도 실패했었습니다.

그리고 그 이유 중 하나를 아래와 같이 생각했습니다.

당면한 회사의 비즈니스 목표는 상용화된 프로덕트였고 그렇기 위해서는 빠른 개발이 우선이었는데, 이런 상황에서 단기적으로 제 개선안은 걸리적거릴 뿐이었습니다.

그렇다면 좋은 품질의 소프트웨어 개발은 시간이 오래 걸릴까요?

'소프트웨어 장인' 은 그렇지 않다고 말합니다.

작은 코드 조각에서는 XP 실행 관례를 마스터한 소프트웨어 장인과 일반 개발자 간의 업무 능력 차이가 별로 없을 수 있다. 하지만 다루어야 할 문제가 복잡해지면 차이가 어마어마하게 벌어진다. 애플리케이션의 크기가 크면 XP 실행 관례를 몸에 익힌 소프트웨어 장인이 XP 실행 관례를 전혀 수용하지 않은 보통의 개발자보다 훨씬 더 빨리 작업을 완료한다.

- 소프트웨어 장인. 15장 실용주의 장인정신 - 좋은 품질은 비싸고 시간이 오래 걸릴까?

문제는 개선안 그 자체가 아니라 팀의 러닝 커브를 높이기 위한 접근 방법이었다는 것을 깨달았습니다.
그렇다면 팀의 러닝 커브를 높이기 위한 접근 방법에는 무엇이 있을까요?

저는 모든 개발자가 소프트웨어 장인정신을 가지고 일하며, 주변으로는 선을 행하고 있다고 생각합니다.

하지만 개개인의 표현 방식은 다릅니다. 또한 회사와 개인의 발전은 일치하지 않기에 개인 시간을 할애하는 것을 거부할 수도 있고, 사람이기에 슬럼프에 빠질 수도 있습니다.

그렇기에 개인에게서 독립적인 문화로서 자주적, 심리적 안정감, 지속성이라는 키워드를 생각했습니다.

'왓챠' 의 짬 데이

'소프트웨어 장인: 13. 배움의 문화'에서는 '회사에서의 펫 프로젝트 시간을 허용하기'를 말하고 있습니다.

보통의 회사에서는 허용되지 않는 일이지만 이미 '왓챠'라는 회사에서는 '짬 데이'라는 문화가 운영되고 있는 것을 알았습니다.

저는 이 것이 건전한 개발 문화를 성장시킬 수 있는 라이프 사이클의 시작이라고 생각합니다.

많은 회사에서는 개발 문화를 조직할 때 단발성의 의견을 수집받지만 별 소득이 없는 경우가 대부분입니다.

평소에 생각하는 불만이나 개선 사항은 많겠지만 막상 써내라고 하면 추상적이고, 정리도 안되고 무엇보다도 귀찮기 때문이죠.

반면에 주기적으로 시간을 할애해준다면, 루틴 업무와 별개로 생각하고 준비할 수 있기 때문에 본 업무를 먼저 해야 된다는 강박이나 죄책감에서 벗어나 심리적 안정감을 가지고 더 좋은 방법을 귀찮지 않게 준비할 수 있을 것입니다. 예를 들자면 아래와 같은 것 들입니다.

저번 주에 개발한 업무를 페어 프로그래밍으로 리팩터링
테스트 케이스 정비
모니터링 관리
새로운 프레임워크, DB 연구
어쩌면 리프레쉬?

이런 문화의 반복은 생산성의 향상만을 목표하지 않습니다.

오히려 기반이 될 수 있는 구성원 간의 신뢰와 공감, 그리고 여러 기술의 러닝 커브를 완만하게 올려 생산성을 향상하고 비즈니스의 성공을 도울 수 있습니다.

물론 회사의 입장에서도 최소한의 준비는 필요합니다.

주기적인 회고와 세미나를 통해 구성원 모두의 수준을 높일 수 있도록 하고, 무엇보다도 실패의 책임을 개인에게 묻지 않는 것이 중요합니다.

다행히도 지금 다니는 회사에서는 2주 단위의 회고와 팀장님 재량 하에 리팩터링과 기술 연구를 지원받고 있습니다.

사실 이 정도의 문화도 훌륭하다고 생각하지만, 제도화된 것과 재량 하의 것은 심리적 안정감과 지속성에서 큰 차이가 있다고 생각합니다.

'소프트웨어 장인'을 읽고 이 글을 쓰면서 느낀 건데 이 모든 것이 결국 '애자일 프로세스'로 귀결된다는 것을 느꼈습니다.

1년 전까지는 그냥 새로운 패러다임이라고 생각했지만, 실무를 겪으면 겪을수록 그 필요성을 체감하고 대단하다고 느끼고 있습니다.

이 글은 여기에서 끝나지만 다음에는 '좋은 개발 문화란? - (3) 정착'으로 글을 작성해보고 싶습니다!

WATCHA WEB 팀의 2020년 회고

지난 1년간 무엇이 바뀌었을까?

medium.com

왓챠 개발자 이스터에그의 비법은? 짬데이?!

[기업분석보고서] [인터뷰] "공부하고 공유하는 짬데이, 소통의 스쿼드"

www.jobplanet.co.kr

좋은 개발 문화란? - (1) 실패

Hyunec — Mon, 15 Nov 2021 15:43:30 +0900

과거의 애플리케이션은 ~~아마도~~ 충분한 계획을 기반으로 개발되었으며, 변경점도 ~~비교적~~ 많지 않았습니다.

그리고 대부분 SI 식 개발로 비즈니스가 분리되었기에, 지속성보다는 요구 사항 충족과 납기일이 우선 되었었습니다.

이때에는 단어조차 생소한 개발 문화는 중요하지 않았으며, 위에서 내려온 계획에 맞는 개발을 하나라도 더 하는 게 미덕이었습니다.

하지만 현대의 애플리케이션은 긴 생명 주기와 모호해진 개발과 운영의 경계로 개발보다는 운영하면서 더 많은 이슈를 만나게 됩니다.

그러다 보니 자연스럽게 개발의 지속성에 대해 생각하게 되고 그것들을 아우르는 것으로 개발 문화가 나오게 되었습니다.

이제는 개발이 비즈니스의 성공에 직결적인 요소가 되었기에 개발 문화의 중요성이 업계 전반에 퍼져 있고 채용에도 중요한 화두가 되곤 합니다.

이 글에서는 개발 문화에 대한 제 생각과 경험을 기록합니다.

아래에서 말하는 비즈니스는 업무 영역만이 아닌,
새로운 일 -> 기획 -> 개발 -> 시장 검증 -> 운영까지의 일련의 프로세스를 말합니다.

저는 비교적 늦게 개발을 시작했지만 그 덕분에 최신의 개발론을 배울 수 있었고, 그것들을 회사에 적용하고 싶었습니다.

원활한 비즈니스를 위한 전반적인 프로세스 작성부터 PR리뷰, 레이어 관리, 메타 단어, 배포 전략 등 코드 레벨까지를 문서화하여 팀에 공유하고 도입하려고 노력했습니다.

하지만 제가 작성한 문서들은 잘 관리되지 못했고,
개선안들은 대부분 공감을 얻지 못했습니다.

무엇이 문제였을까 생각해봤습니다.

무엇을 위한 개선인지를 잃어버렸습니다.

개발과 비즈니스가 직결되어 있다고 말해놓고, 비즈니스를 고려하지 않은 개선을 하려고 했습니다.

제가 다니던 회사는 아직 상용화된 프로덕트를 개발하지 못했고, 총원 10~15명, 백엔드 개발자 2~3인으로 구성원 대부분이 2년 차 이하의 스타트업이었습니다.

당면한 회사의 비즈니스 목표는 상용화된 프로덕트였고 그렇기 위해서는 빠른 개발이 우선이었는데, 단기적인 상황에서 제 개선안은 걸리적거릴 뿐이었습니다.

더 큰 문제는 경험 부족이었습니다.

처음에는 '이미 검증된 방법을 왜 수용하려고 하지 않지?'라는 생각이 들었지만, 조금만 운영해봐도 허점이 드러났고 심지어 만든 저 조차도 누락하고 실수했습니다.

이런 상태로 팀을 설득하려고 했으니 제대로 적용했더라도 제가 먼저 떨어져 나갔을 것입니다.

아마 제가 더 경험이 풍부했다면 팀원 모두의 경험치와 의견을 수용해서 좀 더 완화된 개선안을 제안했겠지만 부족했습니다.

결국 제가 작성한 개선안들은 대부분 폐기됐고 처음으로 돌아갔습니다.

생각해보니 제가 했던 방법은 레이싱 경기 중에 엔진을 교체하는 것과 같았습니다.

더 좋은 엔진을 사용하는 것이 장기적으로는 좋지만, 그것을 레이싱 경기 중간에 해서는 안됐습니다.

최소한 경기가 끝난 후, 좀 더 많은 레퍼런스로 팀을 충분히 설득해서 교체했어야 했죠.

다행히 문제를 찾는 과정에서 저의 부족함을 깨닫고, 제가 찾은 개선안들이 부채로서 해결되어야 한다는 것은 팀에 공유할 수 있었습니다.

아마 개선안을 다시 준비할 때는 조금 더 나은 공감을 얻을 수 있겠죠.

무엇보다도 제 마음의 안정을 찾을 수 있었습니다.

만약 이런 시도를 하지 않았다면 일을 하면서도 한편으로는 '왜 이런 낙후된 방법으로 일하는 거지? 왜 개선하려 하지 않는 거지?'라는 불만이 가득했을 것입니다.

하지만 시도해봤기에 간과한 점과 부족한 점을 알 수 있었고, 지금 내가 해야 할 일에 대해 완전히 공감하고 몰입할 수 있었습니다.

좋은 개발 문화의 좋은 적용 사례는 이미 회사 소개나 블로그, 책 등에 정답에 가까운 내용들은 많이 있습니다.

하지만 앞선 실패에서 일반적인 정답보다는 '지금 내가 속한 조직에 적합한지? 구성원들의 합의를 이끌어 낼 수 있을지?'가 더 중요하다는 것을 경험했습니다.

그러기 위해서는 지금을 분석해야 되고 경험과 신뢰가 쌓이는 시간이 해결해줄 것 같습니다.

하지만 지금까지의 경험을 돌이켜 볼 때 그렇지 않았습니다.

업무 경험이 쌓이면 당연히 개선에 대한 아이디어가 떠오르지만, 의도적으로 그것을 구체화시키고 설득하는 일은 완전히 다른 영역입니다.

또한 회사의 개발자로 일하는 이상 다양한 요구 사항을 빠르게 개발해야 되는 강박과, 리팩터링에 대한 죄책감이 조금씩은 있습니다. 그리고 그 중간 어디쯤을 찾는 것이 개발자의 역량 중 하나입니다.

이렇게 보면 개발자가 알아서 그 중간 어디쯤을 잘 찾고 잘 조율하면 될 것 같습니다.

하지만..

이 글을 쓰게 된 이유는 회사에 있던 '소프트웨어 장인'을 읽으면서 '14장. 기술적 변화의 실행'에서 영감을 얻어서입니다.

이미 아는 내용이고, 너무나도 당연한 내용이지만 정작 실무에서는 제대로 활용하지 못했었습니다.

다음 글은 개발 문화를 '준비' 하는 것에 대해 기록해보겠습니다.

업무에 적절한 pagination 선택하기

Hyunec — Sun, 7 Nov 2021 03:31:17 +0900

pagination은 백엔드 구현에서 가장 많이 고려해야 되는 기술 중 하나입니다.

일반적으로 알려진 pagination 기술에는 page, slice 가 있고 특수한 경우에 사용되는 noOffset과 Covering Index 기술이 있는데요.

이번 글에서는 실무에서 만난 특이한 pagination 사례에 대해 각색하여 기록해봅니다.

업무 요건

전체고 조회가 필요합니다.
상품군이 신설되었습니다.
기존에는 회사와 상품이 존재했으며 M:N 관계입니다.
상품군과 상품은 1:N 관계입니다.
상품군과 회사의 관계는 M:N 관계입니다.
서로 다른 재고처에 있는 재고를 합쳐야 합니다.
각 상품군별, 회사별로 소계를 보여주어야 합니다.
페이지당 300개 안팎은 허용 범위입니다.

기술적 배경

각 도메인별 조인이 많이 일어나 성능 이슈가 있습니다.
1. 상품군과 상품, 회사는 서로 다른 테이블에서 관리되고 있습니다.
2. 재고의 총수량은 결과 모든 재고처의 합으로 실시간 계산됩니다.
레거시 로직의 개선은 힘듭니다.

전체고 조회는 신설된 요건이지만 기존에는 비슷한 로직을 '한방 쿼리'라는 거대한 SQL와 slice 방식으로 처리하고 있었습니다.

slice 방식은 cursor와 size를 통해 다음 데이터를 가져오는데, 소계가 생기면서 그 처리가 힘들어졌습니다.

업무 요건의 엑셀을 예로 들어

size = 5 일 때
- 0 페이지(1 ~ 5): A 마켓의 식용유 상품군이 소계까지 정상적으로 출력됩니다.
- 1 페이지(6 ~ 10): B 마켓의 식용유 상품군은 소계까지 보이지만 A 마켓의 커피 상품군은 첫 줄만 보이고 잘려버립니다.
- 2 페이지(11 ~ 15): A 마켓의 커피 상품군이 나오지만 limit 가 소계까지 가지 못합니다.

프론트의 관점에서는 스크롤하면 다음 페이지가 나오기에 큰 문제가 없어 보입니다.

하지만 백엔드의 관점에서는 전체 데이터를 생성한 후에야 cursor와 limit를 활용할 수 있습니다.

상품 종류 수를 통해 rowCount를 계산하여한다고 해도 테이블에 존재하지 않는 소계를 염두에 두고 로직을 구현해야 되기에 복잡도가 상승합니다.

그리고 상품과 회사가 늘어나고, 특히 재고 처가 늘어날수록 쿼리 성능이 저하될 것임이 확실해 보입니다.

그래서 조금 다른 접근법을 생각해봤습니다.

기술적 배경 확인

특정 회사와 특정 상품군에 M:N으로 존재하는 상품은 50개 이하입니다.
상품군 - goods, 회사 - company, 상품 - product

그리고 화면에서 호출할 API를 설계해봤습니다.

// A. 전체 회사 목록
GET /companies

// B. 전체 상품군 목록
GET /goods

// C. 대상 회사들의 모든 상품 개수 (총 row 수)
GET /products/count?companyId=10,20

// D. 특정 회사 & 특정 상품군에 해당하는 상품 목록
GET /products?goodsId=10&companyId=10
GET /products?goodsId=10&companyId=20
GET /products?goodsId=20&companyId=10
GET /products?goodsId=20&companyId=20

// E. 특정 회사 & 특정 상품군에 해당하는 상품 소계
GET /products/sum?goodsId=10&companyId=20

// F. 대상 회사들의 모든 상품 총계
GET /products/sum?companyId=10,20

// G. 앞의 API 를 조합하여 모든 자료를 한번에 반환
GET /products/total?companyId=10,20

해당 페이지에 접근하면 A, B API를 통해 전체 회사와 상품군 목록을 가져오고 List로 관리합니다.
C API 를 통해 전체 개수를 보여줄 수 있습니다.
프론트에서는 그리드 화면의 최하단에 위치할 때마다 1번에서 생성한 List를 통해 D, E API를 동시에 호출합니다.
1. 특정 회사와 특정 상품군에 속하는 상품은 50개 미만이고, 페이지 단위는 300 임으로 6쌍씩 호출해도 됩니다.
2. D API 호출은 매번 같은 row 수가 반환되지는 않기에 페이지 단위는 유동적일 수 있습니다.
1번의 모든 List 소비가 끝나면 F API를 통해 총계를 가져옵니다.
1. 또는 최초에 호출해 항상 보여주는 방법도 있습니다.

기존의 한방 쿼리에 비해 API 가 많아졌기에 프론트의 로직이 복잡해지긴 했지만, 로직의 분리로 각각의 부담이 줄고 부분적인 리팩터링이 가능한 구조입니다. 무엇보다도 사용자의 입장에서는 이전과 차이가 없거나, 좀 더 빠른 속도를 제공할 수 있습니다.

그리고 기능이 부분적으로 구현되었기에 사용자에 맞춘 커스텀이 쉬워집니다. (ex. 소계 노출 여부)

하지만 여전히 문제는 남아 있습니다.

상품의 상태를 실시간으로 계산하기에 스크롤 중 상품에 변화가 있으면 총계와 맞지 않을 위험이 있습니다.
1. 업무 성격상 전체고 조회를 할 때 상품에 변화가 없을 것으로 기대됩니다.
2. 업무 성격상 최종본은 엑셀이나 출력자료를 사용할 텐데 이때는 속도가 느리더라도 G API를 사용할 수 있습니다.

기존의 로직을 유지하면서 성능을 가져갈 수 있는 방법도 있습니다.

repository 레이어의 결과를 캐싱합니다.
1. REPEATABLE READ에서 착안한 방법으로 해당 페이지를 이탈할 때 캐시를 지워주는 로직이 필요합니다.
2. 로직이 분리되지 않았으므로 유지보수의 어려움은 존재합니다.
3. JPA를 사용하지는 않음으로 영속성 콘텍스트가 아닌 수동 캐싱을 구현해야 합니다.

업무적으로 아직 결론을 내지 못한 주제이지만 전체 List를 반환하는 것 밖에 몰랐던 처음에서 업무 요건에 맞는 pagination 기술을 선택하고, 이제는 커스텀한 pagination 기술을 고민해야 되는 시기가 되었습니다.

좋은 기술에는 끝이 없고 필요에 의한 공부를 하는 것이 재미있다고 느꼈습니다.

Java 백엔드 개발 환경을 세팅해보자

Hyunec — Sat, 30 Oct 2021 04:11:47 +0900

처음 개발을 시작할 때를 돌이켜보니 잘 모르기도 했고, 가격적인 부담이 있어 제대로 세팅하지 못해 버벅거렸던 기억이 있습니다.
그러다 이번에 코드 스쿼드 TA를 하게 되면서 초보 개발자 분들에게 도움이 되고자 기록을 남겨봅니다.
지금 제가 사용 중이거나 좋다고 생각하는 조합을 개인적인 관점에서 작성한 내용이니 참고해서 세팅하시면 됩니다.

1. 개발 장비

MacBook 사용을 권장합니다.

네카라쿠배의 백엔드 개발자를 목표로 하신다면 매우 높은 확률로 MacBook을 사용하실 것이고, IDE 사용법이나 애플 생태계의 앱을 사용하는 것에 있어 Window와는 조금 차이가 있습니다. 생산성 차이도 있고 특히 Shell은 지금부터 익숙해지는 것이 좋습니다.
M1부터는 가격적인 부담도 내려갔고 학습을 위해서는 MacBook Air면 충분합니다. 또는 가격대가 떨어진 구형 모델을 구매하고 취직 후 판매를 하셔도 됩니다. 저도 공부하면서 구매한 MacBook을 구매가와 거의 같은 가격에 했습니다.

별도의 키보드 사용을 권장합니다.

바른 자세를 위해, 그리고 개인적으로는 인텔 MacBook을 사용하면서 저온 화상을 입은 경험이 있어 별도의 키보드를 사용했습니다.
저는 무소음, 무선 키보드를 선호하기에 선택지가 많지 않은데요.
지금 사용하는 키보드는 텐키리스 애플 매직 키보드입니다. (13만 원)
하지만 공부할 때는 가격적인 부담으로 카넥스 키보드를 사용했습니다. (6만 원)
외형과 타건감이 매직 키보드와 비슷해서 좋았지만, 결과적으로 내구성이 부족하고 블루투스 인식이 불안정해서 갈아탔습니다.

트랙패드 사용을 추천합니다.

하지만 마우스를 선호하시는 분도 있고, Pro라면 기본 트랙 패드가 충분히 커서 별도로 사용하지 않기도 합니다. (14만 원)

2. 개발 외 사용하는 앱

karabiner

윈도우에 익숙한 분들을 위해 키패드를 커스텀하게 변경해줍니다.

구름 입력기

MacBook의 기본 한글 자판은 쌍자음이 존재하는 자음을 두 번 누르면 쌍자음으로 자동 완성됩니다. 이것을 개선해줍니다.
한영 전환에 구분 없이 ` 를 쉽게 사용해주는 기능을 옵션으로 제공합니다.

PhotoScape X

기본 제공되는 사진 앱의 부족함을 보완합니다.

Macs Fan control

발열을 잡기 위한 쿨러 컨트롤을 도와줍니다.

Notion, Obsidion

마크다운 지원으로 자체 문서를 작성하는데 큰 도움이 됩니다.

Itsycal

달력 관련 어플 입니다.

Kiwi for Gmail

메일 관리를 도와주는 어플 입니다.

Screen Brush

화면 공유시 자신의 화면에 그림을 그릴 수 있습니다.

Alfred (부분 유료)

전 사용하지 않지만 Mac의 전반적인 사용 생산성을 높여줍니다.

magnet (유료)

화면 분할을 더 편하게 하고 싶은 분에게 추천합니다.
전 spectacle 을 사용합니다.

3. 개발 관련 앱

Docker

가상 환경을 편하게 구성할 수 있도록 도와줍니다.

WorkBench

실행 계획을 시각화해서 보여주는 Visual Explain 기능 때문에라도 설치하시는 것을 추천합니다.
저는 Datagrip 을 사용하고 있습니다.

iTerm

터미널을 커스터마이징하고 편하게 사용할 수 있게 도와줍니다.

Postman

가장 사용하기 쉬운 API 테스트 도구 중 하나입니다.
저는 언젠가부터 Swagger 와 Intellij http 에 익숙해져서 사용하지 않고 있습니다.

4. Intellij

Community 버전으로라도 사용을 권장합니다.

plugin

Material Theme UI, Atom Material Icons

다소 칙칙한 intellij 환경을 비주얼 하게 바꿔줍니다.

CamelCase

변수명 작성 시 case 전환을 편하게 도와줍니다.

GitToolBox

blame을 보여줍니다. 그 외의 기능은 딱히 신경을 안 써봤네요.

Rainbow Brackets

괄호에 색깔을 줘서 좀 더 보기 편하게 만들어 줍니다.

SonarLint

코딩의 best practice를 도와주는 플러그인으로 사용을 권장합니다.

Grep Console

디버깅할 때 가독성을 높일 수 있습니다.
저는 로깅시 '###' 를 키워드로 붙이고, 하이라이트 키워드로 사용합니다.

Preferences

keymap

Split Right 단축키 추가

Build, Execution, Deployment > Build Tools > Gradle

Build and run using, Run tests using을 Gradle에서 Intellij IDEA로 변경합니다.

Editor > Code Style

GoogleStyle 또는 naver-coding-convention Scheme 사용을 추천합니다.

Editor > Code Style > Java > Code Generation

Final Modifier 사용을 권장합니다.

String 을 잘 써보자

Hyunec — Sat, 16 Oct 2021 15:08:16 +0900

String 은 Java에서 가장 오래되고 많이 다루는 자료형 중 하나입니다.

그만큼 다루는 방법도 여러 가지인데요. 실무를 하면서 헷갈리기 Best Practice를 기록해 봅니다.

단 String의 반복 연산은 일반적이지 않기에 다른 개선에 비해 드라마틱하지 않습니다.

그리고 실무에서는 팀 컨벤션으로서의 코드 일관성이 우선이기에 무조건적인 적용은 권장하지 않습니다.

각 항목별 제목으로 Best Practice가 기록되어 있습니다.
그래프의 수치는 높을수록 좋은 성능을 의미합니다.

1. String 은 Immutable 합니다.

워낙에 많은 블로그에 잘 소개되어 있기에 이어질 내용의 배경으로서 기록은 하지만 내용은 생략합니다.

String과 Mutable, Immutable에 대해서 헷갈린다면 검색해보시길 권장합니다.

2. 숫자 자료형의 String 변환은 '+' 연산자를 사용합니다.

간혹 올드하거나 C++에 익숙한 개발자는 String.format()을 즐겨 쓰는데 ~~그게 나예요.~~

String.format()가 제일 낮은 성능을 가지고 있고, 그 외에는 비슷한 성능을 가지고 있는 것을 볼 수 있습니다.

하지만 코드의 간결성을 위해 '+' 연산자를 사용을 권장합니다.

How to convert int to String in Java – the fastest way

What is the fastest way to convert an int into a string in Java? We compare four methods using benchmark tests, running on Java 7 to 14.

www.happycoders.eu

3. String 결합은 '+' 연산자를 사용합니다.

String 결합은 흔하게 반복적인 작업으로 보통 4가지 방법을 사용합니다.

+ 연산자
String.format()
StringBuilber, StringBuffer
드물게 Stream & String.join()

각각의 성능을 비교해봅니다.

두 개의 문자열

10개의 개별 문자열을 연결할 때의 성능

전반적으로 StringBuilder의 성능이 높지만, 그 차이가 적고 코드의 간결성을 고려할 때 '+' 연산자 사용을 권장합니다.

100개의 문자열&amp;nbsp;

예외적으로 대량의 문자열을 결합하는 경우는 '+' 연산자의 성능이 현저히 줄어듬으로 StringBuilder를 권장합니다.

그리고 대량의 문자열을 결합하는 대부분의 경우는 Stream을 사용할 것임으로 Stream 사용을 권장합니다.

간혹 올드하거나 C++에 익숙한 개발자는 String.format()을 즐겨 쓰거나 String 은 Immutable 함으로 '+' 연산자가 느리다고 말할 수 있습니다. ~~이것도 나~~

과거에는 맞았지만 최신의 개발을 하고 있다면 다릅니다.

'+' 연산자는 컴파일 시점에 Java 컴파일러에 따라 최적화됩니다.

Java 1.5는 StringBuilder로 최적화되며, Java 9는 아예 바이트 코드 단위의 최적화가 이루어집니다.

요즘의 개발 환경은 대부분 Java 8 이상임으로 '+' 연산자의 사용을 권장합니다.

더 자세한 변천사는 Java 버전별로 'The Java Language Specification'의 'String Concatenation Operator +'를 찾아볼 수 있습니다.

Java Compiler Optimization for String Concatenation

String concatenation was a costly affair in the early Sun Java versions(till JDK1.4 to be precise). Even though later JDK’s brought the…

medium.com

4. 문자열 분리는 split()을 사용합니다.

문자열 분리는 보통 2가지 방법을 사용합니다.

StringTokenizer
split

StringTokenizer는 legacy 클래스입니다.

legacy는 더 이상 사용할 수 없는 deprecated와는 다르게 사용은 할 수 있지만, 권장되지 않습니다.

StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead.

- StringTokenizer javadoc

StringTokenizer는 정규식을 사용할 수 없습니다.

StringTokenizer 가 성능이 조금 더 좋지만 Legacy 된 이유라고 생각합니다.
반면 split은 Java 버전이 올라갈수록 개선되고 있으며, 정규식을 미리 컴파일하는 방법으로도 보완할 수 있습니다.

따라서 극도의 성능이 필요한 예외적인 경우가 아니라면 split 사용을 권장합니다.

참고 자료

String Performance Hints | Baeldung

Learn about the performance aspects of the Java String API

www.baeldung.com

@Component vs @Configuration

Hyunec — Sat, 25 Sep 2021 00:14:38 +0900

개발하면서 Component와 Configuration 어노테이션은 많이 만났었지만 이 글을 작성하기 전에는

@Configuration 은 설정 클래스에 사용하는 어노테이션
@Component는 Bean 클래스에 사용하는 어노테이션

정도로만 알고 있었습니다. 하지만 공부하다 보니 모호하게 알고 있던 부분을 좀 더 알게 되었고, 이 내용을 기록해 봅니다.

# 비교

@Component

@ComponentScan 을 통해 검색됩니다.
- @SpringBootApplication에 래핑 되어 있기에 일반적으로는 신경 쓰지 않아도 됩니다.
용도에 맞춘 스테레오 타입의 어노테이션을 가지고 있습니다.
- @Controller @Service @Repository @Configuration
- 가능하면 스테레오 타입을 사용합니다.
@Bean 과는 차이점이 있습니다.
- 둘다 Bean을 생성한다는 것에서는 같지만 @Component는 class level에서, @Bean 은 method level에서의 어노테이션입니다.
- @Component는 Bean의 클래스 소스가 편집 가능할 때, @Bean 은 인스턴스 화할 코드가 수동으로 작성됨으로 외부 라이브러리나 써드파티 클래스도 Bean으로 등록이 가능합니다.

@Configuration

@ComponentScan 을 통해 검색됩니다.
- @Configuration 도 @Component의 한 종류이기 때문입니다.
각종 스프링 인터페이스의 구현에 함께 활용됩니다.

여기까지만 보면 잘 모르고 혼용해서 써도 애플리케이션이 돌아는 갑니다.

하지만 Bean 을 생성하는 방법에서는 차이가 있습니다.

# Bean을 생성하는 방법

1. @Component

@Component
public class SimpleComponent {

}

2. @Bean (in @Configuration)

@Configuration
public class SimpleConfigBean {

	@Bean
	public SimpleClass1 simpleComponent1() {
		return new SimpleClass1();
	}
}

3. @Bean (in @Component): Lite Mode

@Component
public class SimpleComponentBean {

	@Bean
	public SimpleClass2 simpleComponent2() {
		return new SimpleClass2();
	}
}

proxy 된 simpleConfigBean 과 인스턴스화된 simpleComponentBean 출력

Spring에서는 기본적으로 Bean을 등록할 때 proxy를 사용합니다.

하지만 Lite Mode 는 실제 인스턴스를 생성하기에 proxy 가 필요한 Spring 기능들을 사용할 수 없습니다. (AOP 등)

따라서 이 차이를 알고 필요한 곳에서만 특정 목적으로 사용해야 합니다.

Elastic Beanstalk 구성 삽질기 - 글쑤시개

Hyunec — Sat, 14 Aug 2021 17:46:50 +0900

개발 초기에는 AWS 구성을 하는 것도 일이기에, 지금까지는 프론트 개발자가 백엔드 소스를 받아서 local에서 서버를 띄우는 방식으로 진행했습니다. 물론 매번 DB를 올리지 않아도 되도록 local h2 구성을 해주고, 실행 편의 방법과 README를 제공해줬지만 프론트 개발자 입장에서는 불편한 게 현실이었습니다.

그러던 중 슬슬 목표한 앱의 한바퀴가 성공했기에 AWS 구성을 해보았고 그 기록을 남겨봅니다.

⚠️ 주의!

이 글은 사이드 프로젝트 구성을 위한 삽질기이기에 접근 제어 및 보안이 실무 수준에 미치지 못합니다.
실무에서 고려해야될 사항이나 도움이 될만한 내용은 코멘트했지만,
개인적인 경험에서 나온 기록이기에 선별적으로 이해해주시면 감사하겠습니다.

# 계획

작업 전 배경 지식

실물 장비 기반의 인프라 구성/운영 경험 (IDC)
이미 구성된 AWS 시스템의 운영 경험
EC2 - RDS 의 단일 구성 및 배포 경험
VPC - 보안그룹 - 라우팅 테이블 등 네트워크에 대한 포괄적인 이해

목표

Elastic Beanstalk 으로 EC2 - RDS 로 구성하자
개발 편의성을 우선하며, 고가용성과 보안 등은 차후 과제로 남겨둡니다

AWS 알기 전에는 기초적인 파티션 나누기와 웹 서버 설정부터 심지어 자바 설치까지 직접 했었는데요.
AWS에서는 이런 기본적인 것들은 디폴트 설정으로 제공하거나 GUI 환경에서 간단히 수정할 수 있게 도와줍니다.

공부할 때는 EC2 - RDS를 각각 구성했었지만, 이번 기회에 Elastic Beanstalk을 설정해보려고 합니다.

# Elastic Beanstalk

바로 진행해도 되지만, 저는 서버에 들어가는 것을 좋아하기에 서버에 들어갈 수 있는 '키 페어' 생성을 먼저 해보겠습니다.

1. EC2 키 페어 만들기

모든 서비스 > 컴퓨팅 > EC2 > > 네트워크 및 보안 > 키 페어

저는 EC2 에 직접 연결하는 몇 가지 방법 중 'SSH 클라이언트'로 접근하는 방법을 선호합니다.
익숙한 환경이기도 하고 제일 빠르게 작업할 수 있기 때문이죠.

서버로 직접 연결할 일이 없다면 사용하지 않아도 좋지만 사용을 적극 권장합니다.

2. Elastic Beanstalk 웹 앱 생성하기

AWS 에 로그인하면 바로 첫 화면에 있는  웹 앱 구축  을 따라가서

기본적인 애플리케이션 정보를 입력하고 하단의  추가 옵션 구성  을 선택합니다.

추가 옵션 구성에서 신경 써야 하는 것은 총 4개 입니다.

용량 - EC2
보안 - 키 페어 설정 (중요!)
알림 - 선택 사항으로 추후 Cloudwatch Alert 를 구성해도 됩니다.
데이터베이스 - 데이터베이스는 분리해서 관리하는게 좋다고 생각합니다.

하나의 애플리케이션에는 복수개의 환경을 구성할 수 있습니다. dev/prod 가 분리되어야 하는 시점에 추가 환경을 구성 예정입니다.

Beanstalk 상태 확인

샘플 페이지 접속 성공!

3. EC2 확인 & 접속

탄력적 IP 사용 확인

모든 서비스 > 컴퓨팅 > EC2 > 인스턴스 > 연결

> chmod 700 Gssg-prod.pem
> ls -lrt Gssg-prod.pem
-rwx------@ 1 choibyunghyeon  staff  1678  8 14 12:18 Gssg-prod.pem

pem의 권한은 700으로 설정합니다.

> ssh -i "Gssg-prod.pem" ec2-user@{'인스턴스 연결' 의 캡쳐 참조}

설정한 키 페어가 있는 경로에서 ssh 명령을 통해 서버에 접속할 수 있습니다.

서버 접속 성공!

# RDS

실무라면

마스터 사용자 이름과 port를 변경해주는 것이 좋습니다.

private zone에 DB를 위치시키고 ec2를 통해서만 접근 가능하게 포트 포워딩할 것을 권장합니다.
AWS DocumentDB에서는 Cloud9를 사용할 것을 권장하기도 합니다.

1. 데이터베이스 생성

모든 서비스 > 데이터베이스 > RDS > 데이터베이스 생성

2. 추가 구성 설정

추가 구성에서  '퍼블릭 엑세스 가능' 을 설정해줍니다.

3. 보안 그룹 설정

ec2 에서의 접근 외에도 개발 편의상 내 집에서는 바로 접근할 수 있게 설정합니다.

4. RDS 확인 & 접속

datagrip 등의 툴로 접속 여부를 확인할 수 있습니다.

# 애플리케이션 배포

1. jar(or war) 준비

Beanstalk 은 환경별로 외부 환경 변수를 편리하게 관리할 수 있습니다.
저는 Spring Boot를 사용하기에 yml로 local/prod profile을 구분하고 외부 환경 변수를 주입받게 구성했습니다.

2. 모니터링

> cd /var/log
> tail -f web.stdout.log

AWS의 이벤트나 기본 모니터링이 존재하긴 하지만 콘솔이 더 익숙하기에 서버에서의 모니터링을 준비합니다.

3. Beanstalk 외부 환경 변수 설정

Elastic Beanstalk > 환경 > {환경 이름} > 구성 > 소프트웨어 수정

Beanstalk 환경별로 서로 다른 외부 환경 변수를 운영할 수 있습니다.
위에서는 JDBC 연결을 외부 환경 변수로서 설정했습니다.

서버 기동 성공! 'Started GssgBeApplication in 19.228 seconds'

Swagger 접속 성공!

# 마무리

이전까지는 공통된 서버가 없었으니 에러 대응하기가 참 힘들었는데 이제는 서버가 올라갔으니 편리하게 에러를 봐줄 수 있을 것 같습니다. AWS 덕분에 인프라 작업이 많이 편해지긴 했는데, 그래도 헷갈리는 건 어쩔 수 없네요. ~~인프라도 디버그가 됐으면 좋겠다~~

구성도와 다음 계획을 마지막으로 기록하며 글을 마칩니다.

구성도

DB 는 private subnet 에 위치 시켜야겠지만 이번 버전에서는 보안 그룹으로만 제어 합니다.

다음 인프라 작업들..

CI/CD 구성 - git branch에 대응하는 CodePipeline
- 현재는 circleCI로 CI 만 구성
관제 구성 - slack webhook, Cloudwatch Alert
접근 제어 - 지정된 자사 앱에서만 접근할 수 있도록 제어
TimeZone 관리
HTTPS 설정
코드 품질 관리 - SonarQube 적용
- 현재는 Codecov로 구성
DB 형상 관리 - flyway

Slack Bot 으로 채널에 글쓰기

Hyunec — Wed, 4 Aug 2021 00:15:10 +0900

옛날에 채널에 글을 작성하는 슬랙 연동을 했을 때는 webhook으로 했던 것 같은데, 다시 해보니 잘 안됐습니다.

정확히는 local 에서는 됐지만 github에 올리면 webhook url 이 바뀌는 현상이 발생했습니다.
이상해서 검색해보니 요즘은 slack API 를 연동하는 것이 최신이기도 하고 webhook 보다 다양하게 쓸 수 있을 것 같아서 연동해본 내용을 기록합니다.

사전 조사

Using Slack APIs

Every Slack app has access to a bag of tricks—a range of APIs that provide access to read, write, and update all kinds of data in Slack.

api.slack.com

먼저 slack API 사용을 위해서는 어떤 것을 해야 되는지 살펴봅시다.

Post bodies 에서 확인 가능한 example

이 example 에서 header의 Authorization에 token 이 들어가야 된다는 것을 확인할 수 있었습니다.

사용 가능한 API들

chat.postMessage: Sends a message to a channel.&nbsp; 가 제가 원하는 API라는 것을 찾을 수 있었습니다.

API 발송 준비

1. API 스펙 확인

token과 함께 scope 도 필요한 것을 볼 수 있습니다.

아마 기존에 네이버나 카카오를 연동시켜보신 분이라면 developer 등록하는 절차가 기억나실 겁니다.
slack 도 비슷한 방식으로 내 앱을 등록하고 앱을 통해 토큰을 생성할 수 있습니다.
그러면 bot token 을 만들기 위해 Your Apps 에 가서 app을 만들어봅시다.

2. 내 app 생성

앱을 만드실 때 주의할 점을 2개입니다.
Bots으로 선택하고, Permission에서 scope를 주는 것입니다.

3. 워크스페이스 & 채널에 연결하기

Install to Workspace를 통해 원하는 워크스페이스에 연결

xoxb로 시작하는 bot token 생성 확인

앱을 채널에 초대

4. 발송

POST https://slack.com/api/chat.postMessage
Content-Type: application/json
Authorization: Bearer xoxb-2198502468292-***

{
"channel": "C029T",
"text": "I hope the tour went well, Mr. Wonka."
}

마무리

다 연동하고 나서 안 것이지만 기존의 webhook 방식에 문제가 있던 것이 아니었습니다.
문제가 된 부분은 local에서 테스트한 후 webhook url을 public repository에 그대로 push 했고, 그것이 GitGuardian과 slack의 감지 시스템을 통해 차단이 된 것이었습니다. (기존에 했던 작업은 private repository 이어서 생각하지 못한 부분이었습니다.)

이 이슈는 AWS Elastic Beanstalk 에 환경 변수로 넣으면 해결되는 문제이기에 더 이상 개선하지는 않았습니다.
마지막으로 연동한 코드 중 일부를 공유합니다.

@RequiredArgsConstructor
@Service
public class PostMessageService {

    private final String slackBotToken;
    private final WebClient webClient;

    private static final String chatPostMessage = "https://slack.com/api/chat.postMessage";

    public Mono<String> sendChatPostMessage(PostMessageDto postMessageDto) {
        return webClient.post()
            .uri(chatPostMessage)
            .headers(headers -> headers.add(AUTHORIZATION, "Bearer " + slackBotToken))
            .contentType(MediaType.APPLICATION_JSON)
            .bodyValue(postMessageDto)
            .retrieve()
            .bodyToMono(String.class);
    }
}


@Test
public void send() {
    // given
    String webhookTestUrl = "C029******";
    PostMessageDto postMessageDto = PostMessageDto.of(webhookTestUrl, "Test Message");

    // when
    String block = postMessageService
    .sendChatPostMessage(postMessageDto)
    .block();

    // then
    assertThat(block).startsWith("{\"ok\":true");
}

DynamicUpdate 활용기

Hyunec — Tue, 27 Jul 2021 18:10:52 +0900

GitHub - Hyune-c/blog-code: https://hyune-c.tistory.com/ 의 예제 code

https://hyune-c.tistory.com/ 의 예제 code. Contribute to Hyune-c/blog-code development by creating an account on GitHub.

github.com

팀으로 진행하고 있는 사이드 프로젝트에서는 회원 관리를 자체적으로 구현했습니다.
로그인도 별 문제없고 잘 되는 줄 알았는데, 어느 순간 로그인이 되지 않는 현상이 발생했습니다.
다행히도 문제는 금방 해결했지만 생각할게 많아진 주제였기에 기록을 남겨봅니다.

1. 회원 구현

@Entity
public class Member {

 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;
 private String email;
 
 @Convert(converter = PasswordEncryptConverter.class)
 private String password;
 private String introduce;
}

비밀번호를 BCryptPasswordEncoder로 암호화한, 별로 특별할 게 없어 보이는 회원 구현입니다.

2. 테스트

@Test
public void update_withoutDynamicUpdate() {
 // 1. member 생성
 String password = "1234";
 Member member = new Member("choi8608@gmail.com", password, "변경전 - withoutDynamicUpdate");
 memberRepository.save(member);
 long memberId = member.getId();
 
 // 2. 영속성 컨텍스트 초기화 후 member 조회
 em.clear();
 member = memberRepository.findById(memberId).get();
 
 // 3. 암호화된 비밀번호 확인
 System.out.println("### " + member.getPassword());
 assertThat(passwordEncoder.matches(password, member.getPassword())).isTrue();
 
 // 4. '자기소개' 만 수정 (dirtyCheck)
 // 4-1. 모든 컬럼이 업데이트되면서 password 가 또 암호화됨
 memberService.updateIntroduce(member.getId(), "변경후 - withoutDynamicUpdate");
 
 // 5. 영속성 컨텍스트 초기화 후 member 조회
 em.clear();
 member = memberRepository.findById(memberId).get();
 
 // 6. 비밀번호가 틀려짐
 System.out.println("### " + member.getPassword());
 assertThat(passwordEncoder.matches(password, member.getPassword())).isFalse();
}

1번에서 회원이 생성되고, 암호화된 비밀번호가 들어갔음을 확인할 수 있습니다.

4번에서는 자기소개만 수정했는데 비밀번호도 같이 update 됨을 볼 수 있습니다. 그리고 insert 의 비밀번호와 update 의 비밀번호 해시값이 서로 다릅니다.

의도하지 않게 비밀번호가 update 된 것도 문제지만, 비밀번호가 달라진 게 더 큰 문제였습니다!

JPA의 구현체인 hibernate는 애플리케이션이 처음 로드될 때 entity 들을 모두 스캔하여 update 쿼리를 캐시 해놓고 사용합니다. 그렇기에 dirtyCheck 된 entity가 통째로 update 된 것입니다.

문제는 여기에 password가 있었고, convert 되어버렸기 때문이었습니다.
즉 영속성 초기화 후 조회된 entity는 이미 암호화된 비밀번호를 가지고 있었고, 전체 update를 통해 암호화된 비밀번호가 또 한 번 암호화되어 저장된 것이죠.

3. 테스트 - @DynamicUpdate

해결 방법은 쉽습니다.
entity에 @DynamicUpdate를 달아주면 됩니다.

@DynamicUpdate
@Entity
public class MemberWIthDynamicUpdate {
 ...
}

아까의 테스트와 다르게 의도한 자기소개 필드만 update 된 것을 확인할 수 있습니다.

4. 언제 써야 될까?

얼핏 보기에는 영향받는 칼럼도 적고 의도하지 않은 변경도 일어나지 않아 더 좋을 것 같아 보이지만 기본 설정이 아닌 이유가 있습니다.

위에서 설명한 것처럼 JPA의 구현체인 hibernate는 애플리케이션이 처음 로드될 때 entity 들을 모두 스캔하여 업데이트할 쿼리를 캐시 해놓고 사용합니다. 즉 DynamicUpdate를 사용하면 캐시 된 쿼리가 아닌 동적 쿼리를 새로이 생성하고, 이 과정에서 오버헤드가 발생해 더 적은 필드만 수정됨에도 오히려 성능이 떨어집니다.

대신 entity의 필드 개수가 많고 그 중 소수의 필드만 업데이트 되는 일이 잦을 때는 유용합니다.
(물론 이런 경우는 entity 가 적절하게 분리된 것이 맞느냐를 먼저 의심해야 됩니다.)
마지막으로 격리 수준을 낙관적 락으로 @Version 어노테이션을 같이 사용할 경우 사용하는 것이 좋습니다.
(주로 @Version 필드만 업데이트하기 때문에)

표준 예외 처리에서 로깅까지 (2)

Hyunec — Sat, 3 Jul 2021 00:51:47 +0900

Step 3. 비동기 로직

@Configuration
@EnableAsync
public class AsyncConfiguration implements AsyncConfigurer {

}

먼저 비동기 사용을 위한 설정을 추가합니다.

@RestController
public class AsyncTestController {

    private final AsyncService asyncService;

    @GetMapping("/api/test/async")
    public void asyncTest() throws InterruptedException {
        for (int i = 1; i <= 100; i++) {
            MDC.put("tid", String.valueOf(i));
            asyncService.async(i);
        }

        Thread.sleep(3000L);
    }
}

@Service
public class AsyncService {

    @Async
    public void async(Integer tid) throws InterruptedException {
        Thread.sleep((long) (Math.random() * 1000 + 1));
        log.info("### mdc.tid={}, inputValue={}", MDC.get("tid"), tid);
    }
}

다음은 controller와 service를 만듭니다.

controller에서는 모든 비동기 처리가 끝나기 전 서버 종료를 방지하기 위해 3 초의 sleep을 적용합니다.
service에서는 무작위 처리를 위해 1초 이하의 sleep을 적용합니다.

여기까지가 전 글의 내용입니다.
이제 문제를 해결하기 전에 원인을 알아보고 진행하겠습니다.

Spring에서는 webRequest 당 하나의 쓰레드를 할당해서 작업을 처리합니다.
이 정보는 ThreadLocal에 저장되며, MDC는 MDCAdapter의 구현에 따라 이 정보를 가져와 처리하기에
정보를 공유할 수 있습니다.

하지만 비동기 처리를 위해서 사용하는 TaskExecutor는 새로운 쓰레드를 만드는데,
이때 기존 쓰레드의 context 가 공유되지 않습니다.

Step 3-1. 생성되는 쓰레드에 context 공유하기

public class MDCTaskDecorator implements TaskDecorator {

    @Override
    public Runnable decorate(Runnable runnable) {
        Map<String, String> copyOfContextMap = MDC.getCopyOfContextMap();

        return () -> {
            if (copyOfContextMap != null) {
                MDC.setContextMap(copyOfContextMap);
            }

            runnable.run();
        };
    }
}

새로 생성되는 쓰레드에 context를 복사하기 위한 TaskDecorator를 구현합니다.

public class AsyncConfiguration implements AsyncConfigurer {

    @Bean
    public TaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();

        taskExecutor.setTaskDecorator(new MDCTaskDecorator());
        taskExecutor.setCorePoolSize(20);
        taskExecutor.setMaxPoolSize(50);
        taskExecutor.setQueueCapacity(100);

        return taskExecutor;
    }
}

구현한 TaskDecorator를 AsyncConfiguration에 추가합니다.
이때 비동기 처리를 위한 적절히 배압 설정을 합니다.
본 예제에서는 100 건이 동시에 들어옴으로 QueueCapacity를 100으로 설정했습니다.

비동기 로직에도 MDC 를 활용한 로깅이 적용된 것을 확인할 수 있습니다.

마치며..

처음에는 UUID로 logId를 남기면서 잘 만들었다고 생각했는데, 지금 보니 전혀 실용적이지 않은 구현이었네요.
~~어쩌면 지금도 전혀 실용적이지 않을 수 있지만~~
아마 다음 버전을 작성한다면 레이어별 수행 시간을 체크하고 slack 알림을 하는 것까지는 구현할 것 같습니다.
같이 처리할 수 있을지 모르겠지만 slowquery 모니터링까지도 고려하고 있습니다.

사실 요즘 구성이 잘 되어 있는 회사는 kafka로 메시지 큐를 구성하고 elastic과 kibana로 로그를 관리합니다.
하지만 지금 회사의 규모에서는 오버 스펙이기도 하고 기반 기술의 공부가 부족하기에 이 정도만 적용해도 충분할 것 같습니다.

언젠가는 전부 설계하고 구현할 수 있게 되기를..

표준 예외 처리에서 로깅까지 (1)

Hyunec — Fri, 2 Jul 2021 17:10:15 +0900

이전에 코드스쿼드에 공개해서 반응이 뜨거웠던(?) 표준 예외 처리가 있습니다.
하지만 실무를 하다 보니 부족한 점이 보이고, 고도화하는 김에 로깅까지 해야겠다고 생각해서 글을 작성해봅니다.
이전의 repository 도 남기지만 굳이 참고하지 않고 본 코드만 따라오셔도 무방합니다.

[deprecated] 표준 예외 처리

표준 예외 처리에서 로깅까지

Step 1. 리팩터링

이전에 작성한 표준 예외 처리를 리팩터링 하는 것으로 시작하겠습니다.

1. ExceptionAdvice 분리

한개로 운영하던 ExceptionAdvice 에서 공통으로 사용하는 메소드를 BaseExceptionAdvice 로 분리했습니다.

2. 테스트 케이스

오류 발생시 logId 로 원인을 추적할 수 있습니다.

이 정도로 장애 원인을 추적할 수 있나?

실무에서는 장애를 추적하기 위해 장애 난 시점만이 아닌 연관된 흐름을 봐야 합니다.
하지만 Step 1 에서는 logId 가 에러 발생 시점에만 존재하기 때문에 동시에 요청이 들어온다면 추적이 어렵습니다.

다음 Step에서 MDC를 활용해서 개선해보겠습니다.

Step 2. MDC로 개선하기

MDC (Mapped Diagnostic Context)

멀티 쓰레드 로깅에 활용되는 기술인 NDC (Nested Diagnostic Context)에 java.util.map의 적용으로 사용성을 높인 기술로
각 쓰레드 별로 별도의 로깅 쓰레드를 정적 메서드로 관리할 수 있습니다.
현재 log4j와 logback에서만 MDC 기능을 제공하고 있습니다.

1. MDC 적용

매우 쉽습니다!
Filter에서 transactionId를 UUID로 생성하고 map을 사용하듯이 넣어주면 됩니다.

사용 역시 map과 같습니다.
하지만 여전히 필요한 곳에서 MDC를 호출해줘야 되기에 불편합니다.

@Component
public class MdcLogEnhancerFilter implements Filter {

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain)
        throws IOException, ServletException {
        MDC.put("transactionId", UUID.randomUUID().toString());
        filterChain.doFilter(servletRequest, servletResponse);
    }

    @Override
    public void destroy() {
        MDC.clear();
        Filter.super.destroy();
    }
}


@GetMapping("/api/test")
public void test() {
    System.out.println("system out");
    log.info("### log info");
    log.info("### MDC transactionId={}", MDC.get("transactionId"));
    throw new RuntimeException("test!! " + MDC.get("transactionId"));
}

어느 예제에서는 Interceptor에서 구현했지만, 저는 요청의 시작인 Filter부터 관리를 하고 싶어 Filter에 구현했습니다.

2. console logging pattern 설정

logging pattern 은 logback의 기본 pattern을 참고했습니다. Link

중요한 부분은 [%mdc{transactionId:--}] 입니다.

// application.yml

logging:
  pattern:
    console: '%clr(%d{${LOG_DATEFORMAT_PATTERN:yyyy-MM-dd HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} [%mdc{transactionId}] %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}'

3. 예외 처리 개선

Step 1 에서는 BaseExceptionAdvice에서 UUID를 만들었습니다.
하지만 이제는 MDC를 활용해서 개선할 수 있습니다.

public class ErrorResponse {

    private final String code;
    private final String message;
    private final LocalDateTime time = LocalDateTime.now();
    private final String transactionId = MDC.get("transactionId");
    private final List<FieldError> errors;

    public static ErrorResponse of(ErrorCode errorCode, BindingResult bindingResult) {
        return ErrorResponse.builder()
            .code(errorCode.name())
            .message(errorCode.getReason())
            .errors(FieldError.of(bindingResult))
            .build();
    }
    ...
}

다음은 BaseExceptionAdvice에서 UUID 생성 대신 exception trace를 출력하도록 변경합니다.
필요에 따라 excetption을 모두 출력하지 않고 getStackTrace()를 가져올 수도 있습니다.

public abstract class BaseExceptionAdvice {

    protected void preHandle(Exception ex) {
        log.error("### message={}, cause={}", ex.getMessage(), ex.getCause(), ex);
    }
}

이제 개선된 생성자와 preHandle에 맞게 exceptionAdvice를 변경해 줍니다.

public class BasicExceptionAdvice extends BaseExceptionAdvice {

    ...

    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    protected ErrorResponse handleException(Exception ex) {
        preHandle(ex);
        return ErrorResponse.of(UNKNOWN);
    }
}

에러가 발생해도 깔끔하게 나옵니다!

하지만..

비동기 로직에서는 의도와는 다르게 MDC에 넣은 값이 출력되지 않습니다!
무슨 설정이 빠진 걸까요?

비동기에서의 MDC 적용은 다음으로 이어집니다.

사이드 프로젝트의 기록 - 글쑤시개 (1)

Hyunec — Tue, 22 Jun 2021 01:14:29 +0900

돌아보니 저는 백엔드 역량에만 치우진 사이드 프로젝트만 하고 있었던 것 같습니다.
그러다보니 항상 반쪽짜리 프로젝트만 만들게된 것이 아쉬웠고, 이즈음에서 제대로된 한 사이클의 어플리케이션을 만들어봐야겠다는 결심을 했습니다.

이 시리즈는 프로젝트를 진행하면서 겪는 어려움과 회고가 기록할만큼의 쌓이면 작성됩니다.

글쑤시개 BE

사이드 프로젝트 선택

먼저 내가 풀스택으로 개발할 것인가? 아니면 팀을 구할 것인가? 를 고민했는데, 실무와 병행하면서 실력을 키우려면
백엔드에 더 집중해야된다는 결론을 냈습니다.

몇 번의 사이드 프로젝트와 실무를 경험하면서 개발자의 관점에서 느낀 점은 3가지 였습니다.

내가 안다고 생각하던 기술도 노베이스에서 적용하려고 하면 헤멘다.
공부한 기술을 실무에 적용하고 싶지만, 피쳐 개발이 우선인 스타트업의 특성 상 쉽지 않다.
사이드 프로젝트 아이템의 참신함은 중요하지 않다. 중요한 것은 기술을 녹이는 것이다.

백엔드의 가장 흔한 프로젝트인 게시판 만들기도 기술과 설계를 적용하기 시작하면 얼마든지 도전적인
프로젝트가 될 수 있다는 것을 알고있기에, 실력 향상에 적합한 팀을 찾기로 했습니다.

제가 잡은 최소 기준은 4가지 였습니다.

경력 있는 프론트 개발자가 있는 팀.
프로토 타입이 나와있거나, 최소한 기획안이 확정된 팀.
주 1.5 ~ 2 영업일을 기술적으로 투자할 분량이 있는 프로젝트.
사이드 프로젝트임을 인정하고 비지니스 모델이 없는/서두르지 않는 팀.

다행히 기준에 부합하는 팀에 합류 할 수 있었습니다.

팀 구성

기획 1 경력 0년
디자인 1 경력 0년
FE & 앱 1 경력 0년 (C++ 게임 개발 경력 n년)
BE 1 경력 1년 (인프라 & 기술지원 경력 n년)
주 1회 오프라인 모임

개인 목표

도전적인 기술 적용
흐름도, 객체 관계에 입각한, 변경에 강한 설계
CI/CD 구성
테스트 설계
모니터링 설계
위 모든 과정을 기록

주요 진행 내용 & 어려움

초기 세팅 및 FE 와 API 연동 & Swagger 제공
spring security 를 활용한 JWT 로그인 & 권한 관리 Link

기획에서 기술 리뷰까지

개발자의 일정 관리를 위해서 가장 중요하다고 생각하는 것은, 기획자의 전체 의도를 파악하고 MVP 에 맞는 (또는 일정에 맞는)
기술 범위를 산정하는 것이라고 생각합니다.
하지만 팀원의 절반이 팀 프로젝트 경험이 없고, 체계가 잡히지 않았기에 커뮤니케이션 낭비는 필연적일 것 같습니다.
회사라면 오프라인 미팅과 잦은 슬랙을 통해 의견을 좁힐 수 있지만, 본업과 병행해야 되는 사이드 프로젝트의
특성상 커뮤니케이션 포인트를 줄이면서 해결할 수 있는 방법을 고민해야만 합니다.

마치며

만료 기한이 짧은 JWT 를 통한 로그인은 구현했지만, 기획에서는 기 로그인자는 로그인 과정을 생략한다 는
요구 사항을 전달해주었습니다. 직관적으로 드는 생각은 refresh token 을 활용하는 것이지만,
이것을 FE 에도 설명하기 위해서는 공부하고 구성도를 그려야 할 것 같습니다.

짧은 2 주의 개발에서도 도전적인 기술을 적용했고, 앞으로도 회사에서는 해보지 못한,
하지만 도움이 될 기술을 연습할 수 있을 것이라는 생각에 즐겁습니다.

Spring Security 로 회원 가입을 구현해보자 (3)

Hyunec — Sat, 19 Jun 2021 20:10:31 +0900

Step 4. Custom Annotation 을 통해 로그인 정보 가져오기

1. Custom Annotation 구현

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
public @interface LoginMember {

  boolean required() default true;
}

annotation 은 기본 값을 true 로 두고 필요한 api 에서만 사용합니다.

@Component
public class LoginMemberArgumentResolver implements HandlerMethodArgumentResolver {

  private static final String AUTHORIZATION_HEADER = "authorization";

  private final JwtAuthTokenProvider jwtAuthTokenProvider;
  private final MemberRepository memberRepository;

  @Override
  public boolean supportsParameter(MethodParameter methodParameter) {
    return methodParameter.hasParameterAnnotation(LoginMember.class);
  }

  @Override
  public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
      NativeWebRequest webRequest, WebDataBinderFactory binderFactory) {
    LoginMember loginUserAnnotation = parameter.getParameterAnnotation(LoginMember.class);
    if (!loginUserAnnotation.required()) {
      return null;
    }

    HttpServletRequest request = webRequest.getNativeRequest(HttpServletRequest.class);

    return Optional.ofNullable(request.getHeader(AUTHORIZATION_HEADER))
        .map(authorization -> authorization.split("bearer")[1])
        .map(jwtAuthTokenProvider::convertAuthToken)
        .map(JwtAuthToken::getEmail)
        .map(email -> memberRepository.findByEmail(email)
            .orElseThrow(() -> new CustomAuthrizationException(ErrorCode.NOT_EXIST_MEMBER)))
        .orElseThrow(() -> new CustomAuthrizationException(ErrorCode.FORBIDDEN));
  }
}

resolver 는 jwt 를 해석해서 이메일 정보를 가져오고, 회원이 존재하는지를 검증합니다.

2. Resolver 설정

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

  private final LoginMemberArgumentResolver loginMemberArgumentResolver;

  @Override
  public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
    resolvers.add(loginMemberArgumentResolver);
  }
}

3. JWT 에서 로그인 정보 가져오기

@RestController
public class LoginController {

  @GetMapping("/api/v1/my")
  public void my(@LoginMember Member loginMember) {
    log.info("### loginMember.getEmail()={}, loginMember.getRole()={}", loginMember.getEmail(), loginMember.getRole());
  }
}

controller 에서 jwt 에 없던 id 정보를 확인할 수 있습니다.

마치며

구현을 하면서 배운 것도 많았지만, 반대로 미숙한 부분도 많았습니다.

filter 레이어에서의 에러 처리
- 인증/인가 예외 처리를 제대로 하고 있는가?

AuthTokenProvider 에 Authentication 을 가져오는 메소드가 있는게 적절한가?
UsernamePasswordAuthenticationToken 외를 이용해서 인증을 하려면 어떻게 해야할까?
SecurityContextHolder 를 더 잘 이용할 수 있는 방법은 무엇일까?

특히 예제에서는 회원 정보를 가져올 때 SecurityContextHolder 를 통한 것이 아닌 별도의 Resolver 를 만들었습니다.
조금 구현해본 바로는 Authentication - User - principal 와 Adapter 를 이해해야되는데,
이 과정에서 Member entity 에 extends 를 해줘야하는 등 종속성이 생기는 것 같아 이상한 느낌이 들었습니다.

아마 공부가 부족해서 잘못 이해했거나 best practice 를 찾지 못한 것이라고 생각합니다.
하지만 security 는 워낙 양이 방대하고 사이드 프로젝트를 하는데는 이 정도의 구현으로 충분하기에
고도화는 좀 더 공부하고 해볼 생각입니다.

금방 할 수 있기를..

Spring Security 로 회원 가입을 구현해보자 (2)

Hyunec — Sat, 19 Jun 2021 18:44:35 +0900

Step 3. JWT 적용

1. 준비

// build.gradle

dependencies {
  implementation 'io.jsonwebtoken:jjwt-api:0.11.2'
  runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.2'
  runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.2'
}

// application.yml
application:
  jwt:
    secreat: ${SECREAT:341242FF3617E8D58D7A4F6FEED56FEB8619CF82B9B00829A02E161A4418BFA2}

본 예제에서는 jwt 생성시 HS256 알고리즘을 사용합니다.
HS256 알고리즘을 위해서는 secreat 이 256 bit 이상이어야하는데, 이를 위해 'TEST_KEY' 문자열을 SHA256 으로 해시합니다.

@Configuration
public class JwtConfiguration {

  @Value("${application.jwt.secreat}")
  private String secreat;

  @Bean
  public JwtAuthTokenProvider jwtAuthTokenProvider() {
    return new JwtAuthTokenProvider(secreat);
  }
}

secreat 을 환경 변수에서 가져오고, 다음 step 에서 만들 provider 를 bean 으로 등록합니다.

public enum Role {
  ADMIN("ROLE_ADMIN", "관리자 권한"),
  MEMBER("ROLE_MEMBER", "회원 권한"),
  UNKNOWN("UNKNOWN", "알 수 없는 권한");

  private final String code;
  private final String description;
}


@Entity
public class Member {

  private String role;

  public Member(String email, String password) {
    this.email = email;
    this.password = password;
    this.role = Role.MEMBER.getCode();
  }
}

Member entity 에 role 을 추가하고, 생성자에 Member 권한을 부여하는 로직을 추가합니다.

예외 처리는 최소화해서 구현했기에 생략합니다. repository 를 참고해주세요.

2. JwtAuthToken & Provider 구현

public class JwtAuthToken implements AuthToken<Claims> {

  private final SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;

  @Getter
  private final String token;
  private final Key secreatKey;

  JwtAuthToken(String token, Key secreatKey) {
    this.token = token;
    this.secreatKey = secreatKey;
  }

  JwtAuthToken(String email, String role, Date expiredDate, Key secreatKey) {
    Map<String, Object> claims = new HashMap<>() {
      {
        put("email", email);
        put("role", role);
      }
    };
    this.token = Jwts.builder()
        .setClaims(claims)
        .signWith(secreatKey, signatureAlgorithm)
        .setExpiration(expiredDate)
        .compact();
    this.secreatKey = secreatKey;
  }

  @Override
  public boolean validate() {
    return getClaims() != null;
  }

  @Override
  public Claims getClaims() {
    try {
      return Jwts.parserBuilder().setSigningKey(secreatKey).build().parseClaimsJws(token).getBody();
    } catch (... exception) {
      ... 예외 처리
    }

    return null;
  }
}

token 종류가 늘어날 것을 고려해 AuthToken interface 를 활용합니다.
JwtAuthToken 은 token string 과 secreat 를 관리하는 객체입니다.
- 신규 jwt 생성시 claim 에 이메일 주소와 권한을 넣습니다.
claims 의 예외 처리는 구현하지 못했습니다. (마지막에 설명합니다.)

public class JwtAuthTokenProvider implements AuthTokenProvider<JwtAuthToken> {

  private static final String AUTHORITIES_KEY = "role";
  private final Key secreat;

  public JwtAuthTokenProvider(String secreat) {
    byte[] keyBytes = Decoders.BASE64.decode(secreat);
    this.secreat = Keys.hmacShaKeyFor(keyBytes);
  }

  @Override
  public JwtAuthToken createAuthToken(String email, String role, Date expiredDate) {
    return new JwtAuthToken(email, role, expiredDate, secreat);
  }

  @Override
  public JwtAuthToken convertAuthToken(String token) {
    return new JwtAuthToken(token, secreat);
  }

  @Override
  public Authentication getAuthentication(JwtAuthToken authToken) {
    if (authToken.validate()) {
      Claims claims = authToken.getClaims();
      Collection<? extends GrantedAuthority> authorities = Collections.singleton(
          new SimpleGrantedAuthority(claims.get(AUTHORITIES_KEY).toString()));
      User principal = new User(claims.get("email").toString(), "", authorities);

      return new UsernamePasswordAuthenticationToken(principal, authToken, authorities);
    } else {
      throw new CustomAuthenticationException(ErrorCode.FAILED_GENERATE_TOKEN);
    }
  }
}

token 종류가 늘어날 것을 고려해 AuthTokenProvider interface 를 활용합니다.
JwtAuthToken 을 만드는 역할과 Authentication 을 가져오는 역할을 합니다.

3. 로그인을 구현합니다

@RestController
public class LoginController {

  private final LoginService loginService;

  @PostMapping("/api/v1/login")
  public String login(@RequestBody @Valid LoginMemberRequest request) {
    JwtAuthToken jwtAuthToken = loginService.login(request.getLoginId(), request.getPassword());

    return jwtAuthToken.getToken();
  }
}


@Service
public class LoginService {

  private final static long LOGIN_RETENTION_MINUTES = 300;

  private final AuthenticationManagerBuilder authenticationManagerBuilder;
  private final JwtAuthTokenProvider jwtAuthTokenProvider;
  private final PasswordEncoder passwordEncoder;

  private final MemberRepository memberRepository;

  public JwtAuthToken login(String loginId, String password) {
    Member member = memberRepository.findByEmail(loginId)
        .orElseThrow(() -> new CustomAuthenticationException(NOT_EXIST_MEMBER));

    if (!passwordEncoder.matches(password, member.getPassword())) {
      throw new CustomAuthenticationException(NOT_VALID_PASSWORD);
    }

    // 중요! SecurityContextHolder
    UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(member.getEmail(), password);
    Authentication authentication = authenticationManagerBuilder.getObject().authenticate(authenticationToken);
    SecurityContextHolder.getContext().setAuthentication(authentication);

    Role role = authentication.getAuthorities().stream()
        .map(GrantedAuthority::getAuthority)
        .findFirst()
        .map(Role::of)
        .orElseThrow(() -> new CustomAuthrizationException(NOT_EXIST_AUTHORIZATION));
    Date expiredDate = Date.from(
        LocalDateTime.now().plusMinutes(LOGIN_RETENTION_MINUTES).atZone(ZoneId.systemDefault()).toInstant());

    return jwtAuthTokenProvider.createAuthToken(member.getEmail(), role.getCode(), expiredDate);
  }
}


@Service
public class CustomUserDetailsService implements UserDetailsService {

  private final MemberRepository memberRepository;

  @Override
  public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {
    return memberRepository.findByEmail(email)
        .map(this::createSpringSecurityUser)
        .orElseThrow(() -> new CustomAuthenticationException(ErrorCode.NOT_EXIST_MEMBER));
  }

  private User createSpringSecurityUser(Member member) {
    List<GrantedAuthority> grantedAuthorities = Collections.singletonList(new SimpleGrantedAuthority(member.getRole()));
    return new User(member.getEmail(), member.getPassword(), grantedAuthorities);
  }
}

로그인 과정에서 SecurityContextHolder 에 인증 정보를 등록하고, jwt 를 반환합니다.

3-1. SecurityContextHolder 흐름

LoginService.login() 에서는 고작 3줄로 표현되었지만, 이 흐름이 security 에서 제공하는 마법같은 인증 기능입니다.
아래는 그 중 일부를 설명한 것으로 디버그 모드를 통해 흐름을 따라가보시는 것을 추천합니다.

@Service
public class LoginService {

  // 1. UsernamePasswordAuthenticationToken 를 가져오기 위해 DaoAuthenticationProvider.retrieveUser() 가 호출됩니다.
  UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(member.getEmail(), password);
  Authentication authentication = authenticationManagerBuilder.getObject().authenticate(authenticationToken);

  // 4. 인증된 Authentication 를 SecurityContextHolder 에 등록합니다.
  SecurityContextHolder.getContext().setAuthentication(authentication);
}


public class DaoAuthenticationProvider extends AbstractUserDetailsAuthenticationProvider{

  // 0. BCrypt 로 정의한 PasswordEncoder 가 적용됩니다.
  public DaoAuthenticationProvider() {
    setPasswordEncoder(PasswordEncoderFactories.createDelegatingPasswordEncoder());
  }

  @Override
  protected final UserDetails retrieveUser(String username, UsernamePasswordAuthenticationToken authentication)
    throws AuthenticationException {
    // 2. loadUserByUsername() 를 CustomUserDetailsService 로 Override 하였기에 우리가 찾는 회원의 UserDetails 를 가져올 수 있습니다.
    UserDetails loadedUser = this.getUserDetailsService().loadUserByUsername(username);
  }

  @Override
 protected void additionalAuthenticationChecks(UserDetails userDetails,
   UsernamePasswordAuthenticationToken authentication) throws AuthenticationException {

  // 3. 비밀번호를 비교하는 부분으로 passwordEncoder 가 적용됩니다.
  String presentedPassword = authentication.getCredentials().toString();
  if (!this.passwordEncoder.matches(presentedPassword, userDetails.getPassword())) {
   throw new BadCredentialsException(this.messages
     .getMessage("AbstractUserDetailsAuthenticationProvider.badCredentials", "Bad credentials"));
  }
 }
}


@Service
public class CustomUserDetailsService implements UserDetailsService {

  // 2-1. UserDetails 을 가져오는 로직을 Override 합니다.
  @Override
  public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {
    ... UserDetails 가져오기
  }
}

4. 로그인 테스트

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class LoginControllerTest {

  @DisplayName("[web] 로그인")
  @TestFactory
  public Stream<DynamicTest> login() {
    String email = "hyune@gmail.com";
    String password = "1q2w3e4r*";

    return Stream.of(
        dynamicTest("[성공] 회원 가입", () -> {
          ... 회원 가입
        }),
        dynamicTest("[성공] 로그인", () -> {
          ... 로그인
        })
    );
  }
}

로그인에 성공하면 정상적인 jwt 가 반환됨을 확인할 수 있습니다.

로그인 정보 가져오기는 다음으로 이어집니다.

Spring Security 로 회원 가입을 구현해보자 (1)

Hyunec — Sat, 19 Jun 2021 01:26:54 +0900

생각해보니 저는 이미 구현되어 있는 인증을 가져다 쓰기만 할 뿐, 그 내부 구조는 이해하지 못하고 개발해온 것 같습니다.
그래서 이번 사이드 프로젝트에는 Spring Security 를 활용해 암호화부터 JWT 까지의 회원 가입을 구현했고 그 기록을 남겨봅니다.

아쉽게도 Spring Security 는 이해가 깊지 못해 일부 저의 방식으로 구현한 내용이 있습니다. 내용을 읽는데 참고해주세요.

코드는 일부 각색되었습니다.
각 Step 별 자세한 코드는 repository 의 서브 branch 를 참고해주세요.

Spring Security 로 회원 가입을 구현해보자

Step 1. 회원 가입

@Entity
public class Member {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;
  private String email;
  private String password;
}

최소한의 정보를 가진 회원 entity 를 만들고 정상 가입 됬지만,
비밀번호는 평문 그대로 저장되어 있습니다.

Step 2. 비밀번호 암호화

비밀번호 암호화를 위해 spring security 에서 제공하는 BCrypt 암호화를 사용합니다.

1. Security 설정

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-security'
}


@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
  ... security 기본 설정
}

build.gradle dependencies 와 WebSecurityConfig 를 추가합니다.

@Configuration
public class PasswordConfiguration {

  @Bean
  public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
  }
}

BCrypt 로 PasswordEncoder bean 을 생성합니다.

2. 비밀번호 암호화 적용

@RequiredArgsConstructor
@Converter
public class PasswordEncryptConverter implements AttributeConverter<String, String> {

  private final PasswordEncoder passwordEncoder;

  @Override
  public String convertToDatabaseColumn(String entityAttribute) {
    return passwordEncoder.encode(entityAttribute);
  }

  @Override
  public String convertToEntityAttribute(String databaseColumn) {
    // DB 에서 가져올 때는 복호화하지 않습니다.
    return databaseColumn;
  }
}


@Entity
public class Member {

  @Convert(converter = PasswordEncryptConverter.class)
  private String password;
}

Member entity 의 password 에 PasswordEncryptConverter 를 적용합니다.

3. 암호화 적용 테스트

@DisplayName("[성공] 회원 가입")
@Test
public void success_create() throws Exception {
  // given
  String password = "1q2w3e4r*";

  // when
  ... create

  // then
  assertThat(passwordEncoder.matches(password, member.getPassword())).isTrue();
}

JWT 적용은 다음 글로 이어집니다.

RSS 로 블로그를 모아보자

Hyunec — Sun, 23 May 2021 03:50:44 +0900

요즘은 많은 회사들이 기술 블로그를 운영하고, 감사한 개발자분들이 양질의 블로그를 운영해주시고 있습니다.
하지만 반대로 너무 많다 보니 모아보기가 힘들고, 모아주는 서비스는 내 입맛에 맞지 않거나 알람 확인이 힘들 때가 있는데요.

그래서 저는 사설 Slack 채널에 RSS 피드 구독 설정을 했고 이 과정에서의 작은 팁을 공유합니다.

구독 방법은 공식 레퍼런스를 참고해주세요.

Slack에 RSS 피드 추가

즐겨 찾는 블로그나 새 사이트가 있나요? Slack을 사용하여 RSS 및 Atom 피드를 모두 구독하고 선택한 Slack 채널에서 업데이트를 받을 수 있습니다. 참고...

slack.com

RSS 피드 가져오기

기억보단 기록을

Java, TypeScript, ORM, RDBMS, AWS 를 주로 다루고 공유합니다.

jojoldu.tistory.com

양질의 블로깅을 빠른 주기로 올려주셔서 항상 감사하게 보고 있는 이동욱 님의 블로그입니다.
블로그에서는 RSS 피드를 찾을 수 없지만, 다행히 대부분의 플랫폼에서는 RSS 기능을 자체 지원해주고 있습니다.

이외에도 운영이 잘 되고 있는 대부분의 블로그는 플랫폼에서 제공하는 RSS 설정을 했거나 별도로 제공하고 있습니다.

Github	https://{아이디}.github.io/atom.xml https://{아이디}.github.io/feed.xml
Tistory	https://hyune-c.tistory.com/rss
Medium	https://medium.com/feed/@{아이디}
Brunch	프로필에서 '페이지 소스 보기' 후 RSS 검색

잘못된 RSS 피드는 에러가 발생하니 꼭 확인하고 구독해주세요!

구독 중인 RSS 피드

Yun Blog	https://cheese10yun.github.io/feed.xml
D2 Blog	https://d2.naver.com/d2.atom
자바캔(Java Can Do IT) (최범균)	https://javacan.tistory.com/rss
기억보단 기록을 (이동욱)	https://jojoldu.tistory.com/rss
개린이의 일기장	https://hyune-c.tistory.com/rss
우아한형제들 기술 블로그	https://techblog.woowahan.com/feed/
컬리 기술 블로그	https://helloworld.kurly.com/feed.xml
NHN Cloud Meetup	https://meetup.toast.com/rss
MUSINSA tech	https://medium.com/feed/musinsa-tech
에디의 기술 블로그	https://brunch.co.kr/rss/@@2MrI
Eternity's Chit-Chat (조영호)	http://rss.egloos.com/blog/aeternum
포스타입 팀	https://team.postype.com/rss

mongoDB tutorials

Hyunec — Tue, 18 May 2021 00:02:19 +0900

이번에 회사의 새로운 아이템을 프로토타입으로 만들 일이 생겼는데 회사에서 주로 사용하는 툴에 익숙해질 겸 가볍게 NCP와 mongoDB 를 사용해서 구성해보기로 했습니다.

Naver Cloud Playform - 처음 만져봄.
mongoDB - select 문도 할 줄 모름.

목표

머신러닝으로 돌린 데이터를 mongoDB 에 적재합니다.
이미 운영 중인 AWS EC2 서버에서 NCP로 연결합니다.

NCP - Cloud DB for MongoDB 구성

AWS 가 아닌 NCP를 사용한 이유는 크레디트를 투자받았기 때문입니다.
퀵스타트 가이드가 잘 돼있어서, 캡처보다는 한 작업들을 서술형으로 작성합니다.

항목	Dev	Prod	Dev(계획)	Prod(계획)
서버 구성	Stand Alone	Stand Alone	Stand Alone	Replica Set
VPC	Public	Public	Private	Private
Sub User	O	O	O	O

이미 사용하고 있던 AWS EC2를 사용하기로 했기에 APP 서버는 따로 구성하지 않았습니다.
하지만 이 경우 VPC를 public으로 생성할 수밖에 없었습니다.
sharding 은 아니더라도 arbiter를 포함한 replica set을 구성하려고 했으나, NCP에서는 public 구성의 경우 stand alone 만이 지원되었습니다.
이미 운영 중인 EC2를 옮기거나, 별도 운영은 공수가 크다고 판단되어 stand alone으로 구성하게 되었습니다.
public VPC를 생성하고, ACG (AWS의 보안 그룹)의 inbound 규칙을 회사 IP와 변경한 포트로 적용했습니다.

Cloud DB for MongoDB 는 나온 지 얼마 안 되어서인지 지원되지 않는 서비스가 있어 아쉬웠지만, 퀵스타트가 잘 돼있어서 구성은 생각보다 쉽게 되었습니다. (대신 비용은..)

후속 작업은 블로그에 쓰기보다는 내부 지식 공유도 겸하기 위해서 docker를 통한 세팅과 튜토리얼을 만들어 봤습니다.
새로 시작하는 아이템이라서 애정도 가고, 잘돼서 mongoDB 를 좀 더 적극적으로 써봤으면 좋겠습니다!

https://github.com/Hyune-c/mongodb

기술 '잘' 선택하기

Hyunec — Fri, 7 May 2021 18:58:48 +0900

최근 회사에 DB 형상 관리 라이브러리를 새로 적용할 일이 생겼습니다.
익숙한 것은 flyway 였지만 요즘은 오픈소스가 워낙에 많고, 내가 모르는 더 좋은 라이브러리가 있지 않을까?하는 생각에 찾아보기 시작했고, 그 과정이 생각보다 재미있었기에 글을 작성해봅니다.

결론부터 말하자면 flyway를 선택했습니다.
이하에서는 라이브러리 대신 기술이라는 단어를 사용합니다.

기술을 검색하기 시작했을 때 제가 알던 키워드는 형상관리, flyway 단 2개였습니다.

1. 구글 검색하기

개발의 알파이자 오메가 구글 검색입니다.
1 페이지에 모두 같은 기술로 도배되어있기에 사실상 여기에서 flyway를 선택하고 끝내도 이상하지 않습니다.

하지만 관련 검색어를 보면 다른 키워드도 보입니다.
조금 더 검색해봅시다.

2. stackshare

Software and technology stacks used by top companies

All the best Open Source & Software as a Service (SaaS) tools in one place, ranked by developers and companies using them. Compare and browse tech stacks from thousands of companies and software developers from around the world.

stackshare.io

요즘 뜨는 기술 소개 (?) 사이트입니다.
기술별 카테고리 구분과 연관 비교까지 해줘서 내가 모르던 키워드를 인지하는데 좋습니다.

여기에서도 Liquibase 가 보이네요.

stack 수도 거의 비슷한 것을 보면, 어쩌면 내가 알지 못하던 liquibase 가 더 뜨고 있고 배워야 할 기술일 수도 있겠네요.

3. Google Trands

다시 구글입니다.
5년 추세를 볼 때 flyway 가 7:3 정도로 우세함을 알 수 있습니다.
(솔직히 liquibase 처음 들어봤는데 3이나 차지하다니.. 반성합니다.)

글로벌로 보면 5:5이고 flyway는 북미, 중국에서 주로 쓰이는 것에 비해, liquibase는 유럽권에서 많이 쓰이고 있음을 알 수 있습니다.
개인적으로 신기술을 적용함에 있어 중국, 한국에서 주로 쓰이는 기술보다는 유럽권에서 쓰이는 기술을 선호하기에
이쯤 되면 liquibase를 선택하는 것도 괜찮겠다는 생각이 듭니다.

4. Github Repository

GitHub - flyway/flyway: Flyway by Redgate • Database Migrations Made Easy.

Flyway by Redgate • Database Migrations Made Easy. - GitHub - flyway/flyway: Flyway by Redgate • Database Migrations Made Easy.

github.com

GitHub - liquibase/liquibase: Main Liquibase Source

Main Liquibase Source. Contribute to liquibase/liquibase development by creating an account on GitHub.

github.com

요즘은 정말 많은 라이브러리들이 오픈소스로 공개되어 있고, README 가 작성되어 있습니다.
기술적인 면에서는 오히려 공식 홈페이지보다 더 많은 정보를 얻을 수도 있죠.
제가 레포지토리에서 주로 보는 항목은 다음과 같습니다.

Star 개수, 최근 커밋 일시, 최근 이슈 작성 일시

비교해본 결과 liquibase의 레포지토리의 활성도가 더 높았습니다.

시작은 flyway로 했지만 점점 찾아볼수록 liquibase로 선택이 기울어가고 있습니다.
하지만 결론적으로 flyway를 선택하게 되었습니다.

5. 실무

글의 서두에 썼다시피 이런 과정을 거친 이유는 회사 할 기술을 찾기 위해서입니다.
그리고 회사에 적용하기 위해서는 성능도 중요하지만 다른 생각해야 될 것들도 많죠.

레퍼런스의 접근성

둘 다 성숙된 기술이니만큼 충분한 레퍼런스가 있지만, 한글화 자료는 상대적으로 flyway 가 훨씬 많았습니다. ~~영어 잘하고 싶다.~~

익숙함 & 러닝 커브

아무리 좋은 기술이라도 내가 속한 조직이 그 기술에 익숙하지 않고, 성능이 그것을 습득하는데 걸리는 수고를 압도할 수 없다면 선택을 위한 설득력이 없습니다.

팀장님 오더

6. 그 외

버전 선택

https://mvnrepository.com/

Spring을 사용하는 프로젝트는 대부분 maven이나 gradle을 사용하기에 쉽게 찾을 수 있습니다.
개인적으로는 최신 버전보다는 stable에서도 1~2 단계 아래 버전을 사용하곤 합니다.

Spring Boot Reference Documentation

The reference documentation consists of the following sections: Legal Legal information. Getting Help Resources for getting help. Documentation Overview About the Documentation, First Steps, and more. Getting Started Introducing Spring Boot, System Require

docs.spring.io

하지만 버전의 직접 명시보다는 Spring Boot의 검증된 라이브러리 버전 관리를 사용하는 것을 추천합니다.
대부분의 성숙된 라이브러리는 이미 Spring에서 관리를 해주고 있기 때문입니다.

반대로 Spring에서 관리해주지 않는 기술이라면 이전의 단계를 모두 통과하였더라도 보수적으로 생각해볼 것을 추천합니다.

마무리

폐쇄적이고 유료이던 라이브러리, 설루션 시장이 점점 오픈되면서 이렇게 기술을 선택하고 설득하는 과정도
개발자의 역할 중 하나라고 생각합니다.
예시는 영향도가 적은 형상 관리 툴이기에 이 정도의 조사로도 문제가 없겠지만,
영향도가 큰 기술을 선택함에 있어서는 벤치마크와 같은 성능 테스트도 추가해서 설득력을 높여야 됩니다.

마지막으로 flyway를 샘플 구현해본 레포지토리를 남깁니다.

https://github.com/Hyune-c/simple-flyway

API Versioning 전략

Hyunec — Wed, 14 Apr 2021 16:59:53 +0900

API Versioning은 불특정 다수의 컨슈머가 접속하는 OpenAPI를 지원하기 위해 필수적인 요소 중 하나로, 설령 컨슈머가 한 곳이라고 하더라도 원활한 적용과 장애 시간 최소화를 기대할 수 있습니다. (물론 훌륭한 배포 전략을 준비하면 더 좋습니다.)

아래는 일상 속 사물이 알려주는 웹 API 디자인 을 읽고 해결한 고민과 경험을 기록해봤습니다.

브레이킹 체인지 - 호환성을 지원하지 않게 되는 변경 (특히 하위 호환성)
컨슈머 - API 를 사용하는 클라이언트 (프론트)
프로바이더 - API를 제공하는 서버 (백엔드)

일상 속 사물이 알려주는 웹 API 디자인 - YES24

웹 API는 새로운 서비스나 앱을 만들 때 기존에 존재하던 서비스가 제공하는 기능을 활용할 수 있도록 해준다. 굳이 기존 서비스에 대한 자세한 소스 코드를 알지 않더라도 개발자가 만드는 프로

www.yes24.com

Versioning 전략

API를 제공하다 보면 브레이킹 체인지를 만나는 것은 필연적입니다.
다만 운영 방법에 따라 컨슈머의 인지를 돕고, 프로바이더는 더 적은 변화의 개발을 기대할 수 있습니다.

	v1	v2
경로	GET /v1/transfers Host: api.bankingcompany.com	GET /v2/transfers Host: api.bankingcompany.com
도메인	GET /transfers Host: api.bankingcompany.com	GET /transfers Host: apiv2.bankingcompany.com
쿼리 파라미터	GET /transfers?version=1 Host: api.bankingcompany.com	GET /transfers?version=2 Host: api.bankingcompany.com
커스텀 헤더	GET /transfers Host: api.bankingcompany.com Version: 1	GET /transfers Host: api.bankingcompany.com Version: 2
콘텐츠 네고시에이션	GET /transfers Host: api.bankingcompany.com Accept: application/vnd.bank.1+json	GET /transfers Host: api.bankingcompany.com Accept: application/vnd.bank.2+json
컨슈머의 설정	GET /transfers Host: api.bankingcompany.com Authorization: Bearer 4R57TD78	GET /transfers Host: api.bankingcompany.com Authorization: Bearer 4R57TD78

선호하지 않는 버저닝 전략

도메인 전략과 쿼리 파라미터 전략은 가장 선호하지 않는 전략입니다.

도메인 버저닝 전략은 작은 변경에도 도메인이라는 비교적 큰 단위의 변경이 필요합니다.
쿼리 파라미터 버저닝 전략은 패스와 파라미터의 역할을 침범한다고 생각합니다.

커스텀 헤드 전략과 콘텐츠 네고시에이션은 좀 더 RESTful 한 설계가 가능하기에 좋아 보였습니다.
하지만 RESTful 함보다는 컨슈머 친화적인 설계를 지향하기에 선택하지 않았습니다.

컨슈머의 사용이 어렵고, 무엇보다 변경을 인지하는 것이 어렵습니다.
- (드물지만) 헤더 사용이 제한된 컨슈머가 존재할 수 있습니다.
내부용으로만 사용된다면 충분히 좋은 선택이라고 생각합니다.

컨슈머의 설정 전략은 컨슈머 친화적이지만 프로바이더에서 고려할 것이 너무 많습니다.

경로 버저닝 전략

저는 경로 전략을 추천합니다.
그리고 API 사용에 대한 철학을 포함하여 단점을 보완합니다.

의미 있는 에러 메시지를 구현합니다.
- Deprecate 된, 또는 예정을 알려줄 수 있습니다.
- 응답 코드를 활용하는 것도 좋습니다. (301 Moved Permanently, 302 Found)
- HATEOAS를 구현하는 경우 link를 고려합니다.
버저닝은 리소스 단위로 관리합니다.
- 비록 일부 API는 브레이킹 체인지가 없다고 하더라도, 컨슈머의 직관적인 인지를 돕습니다.
하위 호환성을 고려합니다.
낱개의 필드보다는 네이밍 된 객체를 사용합니다.
- null 인 객체/필드는 내려보내지 않음으로써 컨슈머가 옵셔널 처리를 할 수 있도록 유도합니다.
단순 조회성 API 라면 요건 변경에 따른 필드는 추가하되 기존의 필드도 남겨두는 것을 고려합니다.
- (비록 response의 크기는 커지지만) 일부 값의 부재로 생기는 전체 에러를 방지하고, 나머지는 정상적으로 보여줄 수 있습니다.
- 단 컨슈머가 응답으로 추가적인 연산을 하는 경우는 안됩니다. 오히려 의도하지 않은 문제가 발생하고 추적이 더 어려워집니다.
변경이 잦은 리소스는 분리를 고려합니다.
- 변경이 적은 핵심 리소스와 변경이 많은 유동적인 리소스로 분리합니다. 또는 재설계합니다.
컨슈머에게 친절한 API를 만듭니다.
- 컨슈머가 넣어야 하는 param에 디폴트 값을 넣어줍니다.
- 하위 리소스가 유일할 경우 id를 생략합니다.
  - ex) 영화에는 별점이 1개만 존재합니다.
  - Good - PUT /movie/{movieId}/rating
  - Bad - PUT /movie/{movieId}/rating/{ratingId}

후기

혹자는 원칙과 기술에 입각한 설계와 개발만이 서비스의 수명을 길게 해 준다고 말합니다.
하지만 발전하는 기술 앞에 저는 항상 비숙련자이고, 컨슈머의 숙련도는 예측할 수 없습니다. 그리고 우리의 시간은 항상 부족하며 요건은 계속해서 변하기에 완벽함을 보증하는 것은 불가능합니다.

때문에 최선을 학습하되 현재의 상황에 맞는 선택으로 트레이드오프 해야 한다고 생각합니다.

토끼책을 읽고 - 메시지를 믿을 수 있을까? (2)

Hyunec — Mon, 8 Mar 2021 22:14:16 +0900

[v4] 조금 다른 예를 들어보겠습니다.

/*
  1. 제품을 만들기 위한

  부품 (인자로서 사용됨을 표시하기 위해 Dto 표기)
 */
@Setter
@Getter
@NoArgsConstructor
public class PartDto {

  // 모든 곳에서 필요합니다.
  private Boolean steal;

  // 컴퓨터와 핸드폰에서 필요합니다.
  private Boolean semiconductor;

  // 선풍기에서 필요합니다.
  private Boolean propellers;

  // 선풍기와 핸드폰에서 필요합니다.
  private Boolean button;
}

/*
  1. 제품을 만들기 위한 부품이 있는지 확인하고

  있으면 만드는 서비스
 */
public class ProductService {

  public boolean createComputer(PartDto partDto) {
    if (partDto.getSteal() && partDto.getSemiconductor()) {
      // do work...
      return true;
    }

    return false;
  }

  public boolean createFan(PartDto partDto) {
    if (partDto.getSteal() && partDto.getPropellers() && partDto.getButton()) {
      // do work...
      return true;
    }

    return false;
  }

  public boolean createPhone(PartDto partDto) {
    if (partDto.getSteal() && partDto.getSemiconductor() && partDto.getButton()) {
      // do work...
      return true;
    }

    return false;
  }
}

으악! 요즘 누가 이렇게 코드를 짜나!

하지만 종종 이런 코드를 보곤 하죠

이상적인 프로그래밍과는 조금 거리가 있지만 Dto를 공통적으로 쓰고, Dto 생성 후 부분적으로 Setter 사용, (전 글에서 나온 것과 같이) 메시지 인자를 수신받는 곳에서 검증합니다. 만약 제품이 늘어난다면 검증 로직을 어디에 만들어야 될까요?

[v5] 저는 검증 로직을 모으는 것을 선호합니다.

/*
  1. 제품을 만들기 위한

  부품 (인자로서 사용됨을 표시하기 위해 Dto 표기)
 */
@Setter
@Getter
@NoArgsConstructor
public class PartDto {

  public enum PartOf {
    COMPUTER,
    FAN,
    PHONE,
    UNKNOWN
  }

  private PartDto.PartOf partOf;

...

  public boolean naming(PartDto.PartOf partOf) {
    if (partOf.equals(PartOf.COMPUTER) && this.getSteal() && this.getSemiconductor()) {
      this.partOf = PartOf.COMPUTER;
    }

    if (partOf.equals(PartOf.FAN) && this.getSteal() && this.getPropellers() && this.getButton()) {
      this.partOf = PartOf.FAN;
    }

    if (partOf.equals(PartOf.PHONE) && this.getSteal() && this.getSemiconductor() && this.getButton()) {
      this.partOf = PartOf.PHONE;
    }

    if (this.partOf == null) {
      this.partOf = PartOf.UNKNOWN;
      return false;
    }

    return true;
  }
}

/*
  1. 제품을 만들기 위한 부품이 있는지 확인하고

  있으면 만드는 서비스
 */
public class ProductService {

  public boolean create(PartDto partDto) {
    // do work...
    return true;
  }
}

/*
  1. 제품을 만드는 서비스를 호출하는

  객체
 */
@RequiredArgsConstructor
public class Factory {

  private final ProductService productService;

  public void createProduct() {
    PartDto part1 = new PartDto();
    part1.setSteal(true);
    part1.setPropellers(true);
    part1.setButton(true);

    if (part1.naming(PartOf.FAN)) {
      System.out.println("part1 로 FAN 만들기: " + productService.create(part1));
    }

    PartDto part2 = new PartDto();
    part2.setSteal(true);
    part2.setPropellers(true);
    part2.setButton(true);

        // 검증에 실패해 제품 생산을 위한 요청 (메시지) 를 보내지 않습니다.
    if (part2.naming(PartOf.COMPUTER)) {
      System.out.println("part2 로 COMPUTER 만들기: " + productService.create(part2));
    }
  }
}

특히 Dto로 모으는 것을 선호합니다.

1. 객체에 역할이 있는 것처럼, 메시지도 역할을 줄 수 있다.
2. 메시지를 보내는 것도 비용이다. 사전에 검증되어 전달된 메시지는 신뢰한다. (내부용 로직일시에만)
3. 비슷한 성격의 로직만 모음으로서 생각의 범위를 줄일 수 있다.

물론 다른 해결 방법도 여러 가지가 있습니다.

Dto를 더 분류할 수도 있고, 검증만을 하는 서비스를 만들 수도 있고, 만약 API 호출 형태였다면 수신 측에서 검증하는 전 구조가 더 나았겠죠.

무엇이 되었든 중요한 건 약속된 구조로 레이어를 나누고 팀에 공유하는 것이라고 생각합니다.

목표는 지속 가능한 개발이니까요.

회고

사실 이 글을 쓰게 된 계기는 대가의 이론과 내 능력 사이의 괴리, 거기서 오는 설득력의 부족, 배움이 필요한 기술과 한정된 일정에서 오는 이런저런 안 좋은 생각 중에 문득 눈에 들어와서였습니다. 만약 대가의 이론이기에 문자 그대로를 적용해야 된다는 게 기저에 있다면, 재해석과 설득은 너무 힘든 과정이 됩니다.

다행히도 옛날이었으면 무심코 지나쳐갔을 내용을 코드로 설명할 수 있는 능력이 생겼고, 내용을 정리하는 과정에서 나쁜 생각은 많이 사라진 것 같습니다.

지속 가능한 개발을 유지하되 그 기준을 상향시키자!

회고의 결론은 항상 같은 느낌.

토끼책을 읽고 - 메시지를 믿을 수 있을까? (1)

Hyunec — Mon, 8 Mar 2021 21:51:55 +0900

이전 회사에서는 객체 지향적인 설계보다는 일단 되는 프로그램을 만드는 게 먼저였는데, 이번에 옮긴 회사에서는 객체 지향에 대한 투자를 많이 하는 것 같습니다. 이론의 부족함을 느꼈기에 이전에 읽으려다 만 토끼 책 (객체지향의 사실과 오해 - 조용호 저)을 읽어봤습니다.

역할, 책임 & 메시지, 협력

대부분 좋은 내용이고 이전에 구현한 ~~어설픈~~ OOP, ORM에 대한 고민을 해결해줬지만, 하나가 계속 걸려서 이 글을 쓰게 되었습니다.

메시지를 믿을 수 있을까?

책에서 언급되지 않은 부분은 각색하고, 관련된 코드의 브랜치를 스텝별로 대괄호 표시했습니다. 
https://github.com/Hyune-c/Trust-Message/tree/master

[v1] 책에서는 판사-토끼-증인을 객체로서 책임과 메시지를 설명하고 있습니다.

메시지 (메소드) 를 통해 재판이 진행됩니다.

/*
  1. 전달자 - 토끼를 알고 있고
  2. 증언이 필요하지만 아직 증인이 누구인지 모른채로
  3. 재판을 진행할 책임이 있는

  판사
 */
public class Judge {

    ...
  // 1. 재판하라.
  public String doJudge() {
    // 2. 목격자를 불러오라.
    witness = communicator.findWitness();
    // 4. 증언하라.
    // 증언할 것이 있으면 유죄. 없으면 무죄.
    return (witness.doTestimony().isEmpty())
        ? "Innocence"
        : "Guilty";
  }
}

@Test
public void 정상_재판하라() {
  // given
  String testimony = "저는 보잘 것 없는 사람입니다.";
  // 1. 증언할 말이 있는 증인 - 모자장수
  Witness madHatter = new Witness(testimony);
  // 2. 모자장수를 알고 있는 전달자 - 토끼
  Communicator rabbit = new Communicator(madHatter);
  // 3. 토끼를 알고 있는 판사 - 왕
  Judge king = new Judge(rabbit);

  // when
  // 4. 재판하라!
  String judgeResult = king.doJudge();

  // then
  System.out.println(judgeResult);
}

[v2] 증언 방식이 바뀌었습니다!

판사는 증인에게 언제, 어디서 본 것인지 증언하라고 합니다. (메시지 인자)

다행히도 증인은 어제 광장의 일을 증언할 수 있었습니다.

public class Judge {
    ...
  // 1. 재판하라.
  public String doJudge() {
    // 2. 목격자를 불러오라.
    witness = communicator.findWitness();
    // 4. 증언하라.
    // 증언할 것이 있으면 유죄. 없으면 무죄.
    String testimonyKey = "어제왕국";
    String testimony = witness.doTestimony(testimonyKey);
    System.out.println(testimony);
    return (testimony.isEmpty())
        ? "Innocence"
        : "Guilty";
  }
}

@Test
  public void 정상_재판하라() {
    // given
    Map<String, String> testimonyMap = Map.of(
        "어제왕국", "엘리스를 보았어요!",
        "오늘광장", "저는 보잘 것 없는 사람입니다.");
    // 1. 증언할 말이 있는 증인 - 모자장수
    Witness madHatter = new Witness(testimonyMap);
    // 2. 모자장수를 알고 있는 전달자 - 토끼
    Communicator rabbit = new Communicator(madHatter);
    // 3. 토끼를 알고 있는 판사 - 왕
    Judge king = new Judge(rabbit);

    // when
    // 4. `어제왕국` 의 일을 재판하라!
    String judgeResult = king.doJudge();

    // then
    System.out.println(judgeResult);
  }

[v3] 이번에는 어제 분수의 일을 물었습니다.

불행히도 증인은 어제 분수의 일을 알지 못합니다! (NPE...?)

요지는 '메시지를 묻기 전에 (증언하라) 메시지를 처리할 수 있는지 (증언할 수 있는지)를 확인하는 것'입니다.

다행히도 책에서는 이미 답을 주었습니다.

메시지를 수신받은 객체는 우선 자신이 해당 메시지를 처리할 수 있는지 확인한다. 148p

메시지 인자를 수신받은 객체인 증인이 검증하도록 코드를 수정해, 증언이 없는 이 재판은 무죄입니다!

public class Witness{
...
public String doTestimony(String testimonyKey) {
return(testimonyMap.containsKey(testimonyKey))
        ? testimonyMap.get(testimonyKey)
        : "";
  }
}

이렇게 수신받은 객체에서 일을 하는 것으로 행복하게 끝났습니다.

하지만..