컴퓨터가 뭘까

Kotlin Spring boot에서 AWS Secret Manager 사용하기

연두연두부 — Sun, 31 Mar 2024 23:59:19 +0900

AWS Secrets Manager는 데이터베이스, API 키, 토큰 등 secret 정보를 안전하게 저장하고 교체 및 관리할 수 있게 해주는 AWS 서비스입니다. 코드 상에 보안 유지가 필요한 정보를 노출하여 공개 원격저장소에 올라가게 된다면? 더 나아가 서비스 코드일 경우는 그 영향은 치명적일 것입니다. 민감한 정보들을 관리하는 다양한 솔루션들이 있습니다. 그 중에 AWS Secrets Manager을 소개합니다. 본 글은 AWS RDS를 사용하는 것을 전제로 합니다.

AWS에서 세팅하기

AWS 서비스 중 Secrets Manager를 이동합니다.

목록 우측 상단에 버튼을 클릭하여 신규로 생성합니다. Secret Type은 RDS를 선택하고 username과 secret name을 동일하게 /dev/practice/mysql로 하여 만들었습니다.

encryption key는 AWS KMS로 미리 만들어둔 aws/secretsmanager를 사용하였습니다.

Secret 생성 후에 Secret Value를 보고 수정할 수 있습니다. 다음 secret 에서 username, password, engine, host, port, dbname 관련 secret value를 관리하고 있는 것을 확인할할 수 있습니다.

Spring boot에 적용하기

spring boot에서 secret manager를 사용하고자 build.gradle.kts에 다음 dependency를 추가하여 사용할 수 있습니다.

// aws secret manager 관련
implementation("software.amazon.awssdk:secretsmanager")

// (선택) bootstrap을 사용한다면 추가
implementation("org.springframework.cloud:spring-cloud-starter-bootstrap:4.1.2")

// json 관련
implementation("com.google.code.gson:gson:2.10.1")

// (선택) aws secret manager에서 제공하는 jdbc 사용한다면 추가
implementation("com.amazonaws.secretsmanager:aws-secretsmanager-jdbc:1.0.8")

// (선택) app 자체적으로 mysql jdbc 관리 등 목적으로 사용한다면 추가
implementation("com.mysql:mysql-connector-j:8.3.0")

1) 첫번째 방식으로 AWS secrets manager에서 secret value를 가져올 수 있습니다. 이 때 필요한 dependency입니다

// aws secret manager 관련
implementation("software.amazon.awssdk:secretsmanager")

implementation("org.springframework.cloud:spring-cloud-starter-bootstrap:4.1.2")

implementation("com.amazonaws.secretsmanager:aws-secretsmanager-jdbc:1.0.8")

# application-dev.yml
spring:
  datasource:
    url: jdbc-secretsmanager:mysql://{db-url}
    username: dev/practice/mysql
    driver-class-name: com.amazonaws.secretsmanager.sql.AWSSecretsManagerMySQLDriver
...

# application.yml
cloud:
  aws:
    region:
      static: ap-northeast-2
...

AWS Secrets Manager에서 MySQL 외 다른 데이터베이스도 지원하고 있습니다. AWS Secrets Manager 공식문서

AWS Secrets Manager 보안 암호의 자격 증명을 사용하여 SQL 데이터베이스에 연결 - AWS Secrets Manager

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. AWS Secrets Manager 보안 암호의 자격 증명을 사용하여 SQL 데이터베이스에 연결

docs.aws.amazon.com

2) 두번째 방식은 app 레벨에서 Aws Secrets Manager secret 정보를 가져오는 부분을 직접 만들어 커스텀하게 사용할 수 있습니다. 이번 글에서는 직접 구현해서 secret 정보를 사용할 예정입니다. 이 떄 dependency입니다.

// aws secret manager 관련
implementation("software.amazon.awssdk:secretsmanager")

// json 관련
implementation("com.google.code.gson:gson:2.10.1")

// mysql jdbc 관련
implementation("com.mysql:mysql-connector-j:8.3.0")

이번 포스트에서는 직접 Secret Value를 들고오는 로직을 구현해서 datasource를 만드는 예제를 진행할 예정입니다.

로직 직접 구현해서 Secret 정보 사용하기

현재 팀에서 프로젝트 진행 시 local과 dev, stage, prod(product) 크게 2가지로 나눠 database config를 구성하고 있습니다. 그 이유는 보안중요성이 다르기 때문입니다. 즉, aws secrets manager에는 dev, stage, prod(product)에 대응하는 db secret 정보를 관리하고 있습니다.

모든 profile(local, dev, stage, prod)이 공통으로 사용하는 application 정보는 application.yml에서 관리하고 있습니다. datasource 연결 시 mysql driver를 사용하기 때문에 application.yml에 명시해서 사용하고 있습니다. 그리고 현재 AWS 서비스를 ap-northeast-2(Seoul) region에서 사용하고 있기 때문에 region을 명시합니다.

# application.yml
spring:
    datasource:
        hikari:
            connection-init-sql: SELECT 1
            driver-class-name: com.mysql.cj.jdbc.Driver
    ...

cloud:
  aws:
    region:
      static: ap-northeast-2

로컬환경(즉,profile이 local)에서 개발 시 유연하게 대처하기 위해 application-local.yml에 직접 db url, username, password를 명시해서 사용합니다.

# application-local.yml
spring:
  datasource:
    hikari:
      local:
        jdbc-url: jdbc:mysql://{my-host}:{my-port}/{my-dbname}?useSSL=false&rewriteBatchedStatements=true&profileSQL=true&logger=Slf4JLogger&maxQuerySizeToLog=999999
        username: {my-username}
        password: {my-password}
  ...

이외 profile(dev, stage, prod)에서 각 profile에 대응하는 application-xxx.yml에, profile에 대응하는 AWS Secrets Manager에 저장한 dbSecretKey를 명시합니다.

# application-dev.yml
cloud:
  aws:
    secretsManager:
      dbSecretKey: dev/practice/mysql

본 글 예제는 profile dev 기준으로, 앞서 만든 AWS RDS secret 정보를 AWS Secrets Manager에서 불러와서 datasource를 만들어 사용하고자 합니다.

Aws Secret 컴포넌트에서 application.yml에 명시한 region에 있는 aws secrets manager client를 관리합니다. 그리고 secret client를 통해 secretName에 대응하는 secret 정보를 찾아 secret value를 가져오는 역할을 수행합니다. 이 때 발생하는 exception은 aws secrets manager 관련 exception으로 specific한 exception을 사용했습니다.

@Component
class AwsSecret : LoggerCreator() {

    @Value("\${cloud.aws.region.static}")
    private lateinit var region: String

    @Throws(AWSSecretsManagerException::class)
    fun secretManagerClient(): SecretsManagerClient =
        SecretsManagerClient.builder()
            .region(Region.of(region))
            .credentialsProvider(DefaultCredentialsProvider.create())
            .build()

    @Throws(AWSSecretsManagerException::class)
    fun secretValue(secretName: String): String =
        secretManagerClient().getSecretValue(
            GetSecretValueRequest.builder()
                .secretId(secretName)
                .build()
        ).secretString()
}

AwsAdapter 컴포넌트에서는 secret Name에 대응하는 secret value을 AwsSecret 컴포넌트를 통해 가져옵니다. 이 때 secret Value는 Json text 형태로, AwsAdapter 컴포넌트에서 gson 을 통해 dto 객체로 변환합니다. 그리고 AWS Secrets Manager에서 secret value을 가져오면서 발생한 exception을 처리합니다.

@Component
class AwsAdapter(
    private val awsSecret: AwsSecret
) : LoggerCreator() {
    fun getDbSecretValue(secretName: String): DbSecretValueDto? =
        try {
            GsonUtil.fromJson(awsSecret.secretValue(secretName), DbSecretValueDto::class.java)
        } catch (e: Exception) {
            log.error(FAIL_TO_GET_DB_SECERT_VALUE, e)
            null
        }
}

AwsAdapter 컴포넌트에서 변환하는 DbSecretValueDto입니다. gson util에서 singleton Gson 객체를 이용하여 gson 에서 지원하는 fromJson을 사용할 수 있도록 하였습니다.

data class DbSecretValueDto(
    val username: String?,
    val password: String?,
    val engine: String?,
    val host: String?,
    val port: String?,
    val dbname: String?
)

object GsonUtil {
    private val gson = GsonBuilder()
        .disableHtmlEscaping()
        .setPrettyPrinting()
        .serializeNulls()
        .create()

    fun <T> fromJson(json: String, classOfT: Class<T>): T = gson.fromJson(json, classOfT)
}

Database config에서 local 외 profile일 경우 (dev, stage, prod) AwsAdapter을 통해 DB Secret Value 정보 DbSecretValueDto를 활용하여 datasource를 만듭니다.

@Configuration
class DatabaseConfig (
    private val awsAdapter: AwsAdapter
): LoggerCreator() {
    @Value("\${cloud.aws.secretsManager.dbSecretKey}")
    private lateinit var secretName: String

    /**
     * local 외 DataSource bean 생성 함수
     */
    @Primary
    @Bean(name = ["defaultDataSource"])
    @Profile("dev", "stg", "prd")
    fun defaultDataSource(hikariProperties: HikariProperties): DataSource? = try {
        // DB 정보 획득
        val dbSecret = secretName.let {
            awsAdapter.getDbSecretValue(it)
        } ?: throw Exception(FAIL_TO_GET_VALUE_FROM_APPLICATION)

        // JDBC URL 생성
        val jdbcUrl = buildString {
            append("jdbc:mysql://")
            append("${dbSecret.host}:${dbSecret.port}/${dbSecret.dbname}")
            append("?allowUrlInLocalInfile=true&allowLoadLocalInfile=true&rewriteBatchedStatements=true")
        }

        // DataSource 생성
        hikariDataSource(HikariConfig().apply {
            this.jdbcUrl = jdbcUrl
            this.username = dbSecret.username
            this.password = dbSecret.password
        })
    } catch (var7: Exception) {
        log.error(ERROR_DATA_CONFIG, var7)
        var7.printStackTrace()
        null
    }

     /**
     * local DataSource bean 생성 함수
     */
    @Primary
    @Bean(name = ["defaultDataSource"])
    @Profile("local")
    fun defaultDataSourceLocal(hikariProperties: HikariProperties): DataSource = hikariDataSource(HikariConfig().apply {
        jdbcUrl = hikariProperties.local!!.jdbcUrl
        username = hikariProperties.local.username
        password = hikariProperties.local.password
    })

    private fun hikariDataSource(hikariConfig: HikariConfig) = HikariDataSource(hikariConfig).also { it.validate() }

}

추가로 Spring boot프로젝트에서 Jpa를 사용한다면 transaction 관련 config를 추가해서 사용해주면 됩니다. 다음 config는 database config에서 설정된 dataSource bean을 활용합니다.

@EnableJpaRepositories(
    basePackages = ["com.study.my.*.domain"],
    entityManagerFactoryRef = "defaultEntityManagerFactory",
    transactionManagerRef = "defaultTransactionManager"
)
@Configuration
@EnableTransactionManagement
class TransactionConfig(
    @Qualifier("defaultDataSource") private val dataSource: DataSource?,
    private val appConfig: AppConfig,
    private val jpaProperties: JpaProperties,
    private val hibernateProperties: HibernateProperties
) : LoggerCreator() {

    @Value("\${my-project.config.jpa.default-base-packages:com.study.my.*.domain}")
    private lateinit var BASE_PACKAGES: String

    @Value("\${my-project.config.jpa.default-packages-to-scan:com.study.my.*.domain.*.entity}")
    private lateinit var PACKAGES_TO_SCAN: String

    @Primary
    @Bean(name = ["defaultEntityManagerFactory"])
    fun defaultEntityManagerFactory(
        builder: EntityManagerFactoryBuilder
    ): LocalContainerEntityManagerFactoryBean = hibernateProperties.determineHibernateProperties(
        jpaProperties.properties, HibernateSettings()
    ).let {
        builder
            .dataSource(dataSource)
            .packages(*arrayOf(PACKAGES_TO_SCAN))
            .persistenceUnit("defaultEntityManager")
            .properties(it)
            .build()
    }

    @Primary
    @Bean(name = ["defaultTransactionManager"])
    fun defaultTransactionManager(@Qualifier("defaultEntityManagerFactory") entityManagerFactory: EntityManagerFactory): PlatformTransactionManager =
            JpaTransactionManager(entityManagerFactory)

}

kotlin 프로젝트에서 openapi code generator 사용하기

연두연두부 — Sun, 24 Mar 2024 23:59:16 +0900

서론

현재 참여하고 있는 프로젝트는 쿠버네티스 환경으로, 여러 컴포넌트로 구성된 마이크로서비스 아키텍처입니다. 각 컴포넌트는 서로 다른 네트워크 주소와 포트에서 실행됩니다. 따라서 각 컴포넌트의 API를 호출하려면 다음과 같은 어려움을 겪었습니다. 하지만 분산된 시스템에서 서로 다른 서비스의 API를 호출하는 것은 복잡합니다. 네트워크 주소 관리, 로드 밸런싱, 오류 처리 등 고려해야 할 사항이 많기 때문입니다. 이러한 과정을 자동화하고 개발 효율성을 높이기 위해서 Open Api CodeGenerator를 도입하는 것을 고려했습니다.

Open Api Code Generator는 OpenAPI Spec을 기반으로 프로젝트 코드를 생성해주는 오픈소스 툴입니다. 기본적으로 각 컴포넌트 API를 OpenAPI 스펙으로 정의하여 Api문서 공유가 가능합니다. 그리고 그 스펙을 기반으로 자동으로 Api client 코드를 생성되어 Controller 클래스가 상속받아 사용하여 일관성이 있게 개발가능합니다. 그리고 다른 컴포넌트의 API도 손쉽게 호출할 수 있습니다! 이를 통해 자동으로 생성된 API 클라이언트 코드로 API 테스트를 자동화하여 API 호출 문제를 사전에 예방할 수 있습니다.

현재 팀에서 각 컴포넌트에 대한 Api Spec 작성 및 관리는 Swagger hub 통해 하고 있습니다. 이번 포스트에서는 swagger hub에 있는 Api spec을 이용하여 Api 개발 시 필요한 세팅을 작성하고자 합니다.

환경

기본 프로젝트 환경은 spring boot 2.7, Java Version 11 입니다. 기본 환경 세팅은 제외하고 추가나 필요한 코드 위주로 소개하겠습니다.

OpenAPI Code Generator를 사용하기 위해 build.grardle.kts에 다음과 같이 플러그인 및 dependency 추가가 필요합니다.

plugin{
    id("org.openapi.generator") version "7.4.0"
    ...
}

dependency{
    implementation("org.springframework.boot:spring-boot-starter-validation")

    implementation("com.squareup.okhttp3:okhttp:5.0.0-alpha.12")
    implementation("com.google.code.gson:gson:2.10.1")
    ...
}

현재 Api 개발을 할 대상 컴포넌트를 'my-component'라고 가정합니다. 그리고 다른 컴포넌트들 api spec도 swagger hub에 명세되어 있다고 가정합니다. swagger hub에 my-component 프로젝트를 생성하여 Api spec을 작성합니다. swagger hub를 연동하기 위해 프로젝트 내부에 my-component와 타컴포넌트 api key들을 .swagger/hubapi.json에 추가해주었습니다.

// hubapi.json
{
  "key":"apikey 작성",
  "test.componentA": "apikey 작성" ,
  "test.componentB": "apikey 작성" ,
}

OpenAPI를 통해 code를 생성하는 gradle task를 만듭니다. task에서 사용할 input에 대한 정의를 먼저 합니다. swagger hub에 작성한 api spec을 기준으로 Api 코드를 생성하고자 provide spec 에 작성합니다. 그리고 my-component 컴포넌트의 특정 api에서 타 컴포넌트에 있는 api를 호출하는 경우, 그 컴포넌트들의 정보를 consume spec에 작성합니다.

object UserDefineInputs {
    data class GenerateTaskInput(val name: String, val specUrl: String)

    val provideSpec = GenerateTaskInput("my-component", "https://api.swaggerhub.com/apis/test/my-component/1.0.0")

    val consumeSpecs = listOf(
        GenerateTaskInput("componentA", "https://api.swaggerhub.com/apis/test/component-a/1.0.0"),
        GenerateTaskInput("componentB", "https://api.swaggerhub.com/apis/test/component-b/1.0.0")
    )
}

현재 프로젝트에서 api spec 작성과 관리를 원격 환경인 swagger hub에서 하고 있어 그 기준으로 환경 설정이 됩니다. swagger hub는 유료이기에 open api generator 도입 전에 테스트하고자 하시면 로컬에서 간단히 openapi.yaml을 생성하여 open api generator를 사용할 수 있습니다. 이럴 경우 swagger hub url이 아닌 yaml 파일 위치를 참조할 수 있도록 변경해주셔야 합니다.

GenerateAllSpecs, GenerateProvideSpec, GenerateConsumeSpec task를 만들어 필요에 따라 provide, consume api 코드를 모두 생성/업데이트할 수 있도록 했습니다. 기본적으로 build 시 GenerateAllSpecs task와 동일하게 provide, consume spec 코드가 생성되도록 했습니다. 그리고 src/ 디렉토리에서 api 생성 코드들을 관리하여 버전 관리하고 싶다는 팀원의 니즈로 code generate 되는 위치를 지정합니다.

val generatedPath = "src/generated"
val generatedPathForKotlin = "$generatedPath/kotlin"

tasks.register("GenerateAllSpecs") {

    println(">>> Deleting openapi generated files")
    val genMetaFiles = files("$generatedPath/.openapi-generator")
    delete(genMetaFiles)

    val genSrcFiles = files("./$generatedPath")
    delete(genSrcFiles)

    println(">>> Creating directory 'src/generated' for openapi generated files")
    val directory = file("$generatedPathForKotlin/.generated_files")
    Files.createParentDirs(directory)

    registeredGenerateTasks.forEach { it.taskProvider.get().doWork() }
}

tasks.register("GenerateProvideSpec") {
    registeredGenerateTasks.filter { it.isForProvide }.forEach { it.taskProvider.get().doWork() }
}

tasks.register("GenerateConsumeSpec") {
    registeredGenerateTasks.filter { !it.isForProvide }.forEach { it.taskProvider.get().doWork() }
}

registerGenerateProvideSpec, registerGenerateConsumeSpec 에서 input에 정의한 api spec 문서를 참조하여 open api option에 따라 코드를 생성합니다. 또한 조금 더 빠른 코드 생성을 위해 각 컴포넌트별 gradle task가 만들어질 수 있도록 하였습니다.

data class RegisteredGenerateTask(
    val name: String,
    val isForProvide: Boolean,
    val taskProvider: TaskProvider<GenerateTask>
)

val registeredGenerateTasks = mutableListOf<RegisteredGenerateTask>()

fun registerGenerateTask(
    name: String,
    swaggerUrl: String,
    isForProvide: Boolean,
    configOptions: List<String>
): TaskProvider<GenerateTask> {
    val packageNamePrefix = if (isForProvide) "provide" else "consume"
    val apiPackageName = "${GenerateTaskConfig.PACKAGE_PREFIX}.$packageNamePrefix.test.$name.api".replace("[-]".toRegex(), "_")
    val modelPackageName = "${GenerateTaskConfig.PACKAGE_PREFIX}.$packageNamePrefix.test.$name.model".replace("[-]".toRegex(), "_")
    val taskName = "Generate${packageNamePrefix.capitalize()}_$name"
    val generatorName = if (isForProvide) "kotlin-spring" else "kotlin"

    val newTaskProvider = tasks.register<GenerateTask>(taskName) {
        generatorName.set(generatorName)
        outputDir.set(project.file("./").absolutePath)
        // 로컬에 있는 yaml 파일을 사용할 경우 다음 옵션 사용 inputSpec.set(yamlFilePath)
        remoteInputSpec.set(swaggerUrl)
        apiPackage.set(apiPackageName)
        modelPackage.set(modelPackageName)
        globalProperties.set(GenerateTaskConfig.globalOptions)
        configOptions.set(configOptions)
    }
    registeredGenerateTasks.add(RegisteredGenerateTask(name, isForProvide, newTaskProvider))
    return newTaskProvider
}

GenerateTaskConfig 에 open api code generate 옵션을 두어 관리하고 있습니다. open api code generate 옵션은 default 값이 있고 사용자가 옵션을 지정할 수 있습니다.

object GenerateTaskConfig {
    private const val GENERATED_KOTLIN_SOURCE = "src/generated/kotlin"
    const val PACKAGE_PREFIX = "com.my.test"

    val globalOptions = mapOf(
        "apis" to "",
        "models" to "",
        "verbose" to "true",
        "supportingFiles" to "",
    )
    val serverConfigOptions = mapOf(
        "interfaceOnly" to "true",
        "useSwaggerUI" to "true",
        "useTags" to "true",
        "enumPropertyNaming" to "UPPERCASE",
        "sourceFolder" to GENERATED_KOTLIN_SOURCE
    )
    val clientConfigOptions = mapOf(
        "dateLibrary" to "java8",
        "hideGenerationTimestamp" to "true",
        "sourceFolder" to GENERATED_KOTLIN_SOURCE,
        "serializationLibrary" to "gson",
        "library" to "jvm-okhttp4"
    )
}

consume한 컴포넌트들의 api를 사용하기 위해 api client를 이용하는 데 어려움을 겪어 clientConfigOptions를 설정하는데 어려움이 많았습니다.

특정 팀원이 date가 다른 경우가 발생했었는데 OpenAPI Code generator의 dateLibrary 옵션 영향으로 발생했었던 거였습니다. 그래서 dateLibrary를 java8로 명시하여 해결하였습니다.

kotlin-openapi-generator 공식문서를 통해 client 기본 library가 jvm-okhttp4 인 것을 확인했습니다. jvm-okhttp4라이브러리는 serialization 시 Moshi를 사용하고 있었습니다. OpenAPI Code generator는 다양한 설정을 통해 클라이언트 생성에 사용되는 라이브러리를 조정이 가능하여 dependency에 추가한 Gson을 이용하여 serialize 되도록 하였습니다. 즉, clientConfigOptions에 library와 serializationLibrary를 명시하여 해결하였습니다. 참고로 Java spring boot 일 경우 지원되는 library, serializationLibrary가 다르니 공식문서를 꼭 참조하시길 추천드립니다.

설정 옵션에 따라 다음과 같이 client 에 있는 api를 호출할 때 필요한 infrastructure 코드들이 생성이 됩니다.

앞서 정의한 registerGenerateTask 를 호출하여 spec 을 참조하여 code generate하는 task을 생성합니다.

UserDefineInputs.provideSpec.run { registerGenerateTask(name, specUrl, true, GenerateTaskConfig.serverConfigOptions) }
UserDefineInputs.consumeSpecs.forEach { spec ->
    spec.run {
        registerGenerateTask(name, specUrl, false, GenerateTaskConfig.clientConfigOptions)
    }
}

로컬환경 IntelliJ IDEA에서 OpenAPI code generate task를 실행할 때 Gradle의 기본 Java 힙 메모리(512Mb)가 부족하여 클라이언트 생성에 실패할 수 있습니다. 원활하게 code generate를 하기 위해 Gradle 설정 파일인 gradle.properties를 수정하여 Java 힙 메모리 크기를 늘립니다.

org.gradle.jvmargs=-Xmx8192m

적용

1) Swagger hub에 명세한 API 문서에 따라 API 개발

앞서 Swagger hub에 my-component에 명세했었습니다. GenerateAllSpec task를 실행하게 되변 my-component, 즉 provide spec을 참조하여 MyApi가 생성됩니다. 이 때, Swagger hub에 명세한 response 클래스도 생성되어 API 클래스의 메서드 return 타입은 response가 됩니다. Controller 클래스에서 MyApi 클래스를 상속하여, MyApi에 명세된 메서드들을 override하여 개발하게 됩니다.

@RestController
class MyApiController(
    private val systemService: SystemService
    private val personService: PersonService
) : MyApi {
    private companion object : LoggerCreator()

    override fun systemHealthCheck(): ResponseEntity<DefaultResponse> = systemService.systemHealthCheck()

    override fun getAllPersons(): List<Person>? = personService.getAllPersons()

    ...
}

2) 타컴포넌트 API 호출

component A, component B 등 consume한 컴포넌트들의 client를 이용하기 위해, ApiConstants 의 companion object에 호출할 api를 작성합니다.companion object를 사용하면 해당 객체 내의 속성은 클래스 로딩 시점에 초기화되며, 이후에는 해당 클래스의 인스턴스나 다른 객체에서 접근하더라도 초기화 과정이 다시 일어나지 않습니다. 따라서 companion object 내에서 초기화된 api들은 클래스가 로드될 때 한 번만 호출되어 초기화됩니다. 이후에는 항상 같은 인스턴스를 반환하게 됩니다. 즉, 싱글톤으로 사용이 가능합니다.

object ApiConstants : LoggerCreator() {
    init {
        log.info("[INITIALIZED] api list for openapi consume project")
    }
    val aaApi = ComponentATestAApi()  
    val abApi = ComponentATestBApi()
    val baApi = ComponentBTestAApi()
}

@Service
class serviceService(){
    fun hello(){
        println("hello to componentA")
        ApiConstants.aaApi.hello()
        println("hello to componentB")
        ApiConstants.baApi.hello()
    }

    fun bye(){
        println("bye bye to componentA")
        ApiConstants.abApi.bye()
    }
}

참조

[querydsl] mysql filesort관련 group by 성능 최적화

연두연두부 — Sun, 17 Mar 2024 23:59:08 +0900

mysql 환경에서 querydsl 를 도입하면서 성능 저하 문제를 피하기 위해 고민하고 있습니다. 데이터 조회 시 사용하는 group by 쿼리에서 불필요한 filesort 로 성능저하가 발생할 수 있습니다. filesort는 MySQL 서버가 메모리 버퍼에 담을 수 없는 방대한 데이터를 정렬하기 위해 임시 파일을 사용하는 방식입니다. 이는 불필요한 디스크 I/O 작업을 증가시켜 쿼리 실행 속도를 크게 저하시킵니다.

이번 포스트에서는 querydsl group by 쿼리에서 발생하는 filesort 문제를 분석하고, order_by_null 옵션을 활용하여 Filesort를 효과적으로 방지하는 방법을 소개합니다.

MySQL 정렬 방식

MySQL은 데이터 정렬을 위해 다음 두 가지 방식을 사용합니다.

인덱스 정렬
데이터가 이미 정렬된 상태로 저장된 인덱스를 활용하여 정렬 작업을 수행합니다. 인덱스 정렬은 메모리 접근만으로 이루어지기 때문에 Filesort에 비해 훨씬 빠른 속도를 제공합니다. MySQL Optimizer는 인덱스 정렬이 가능한 실행계회에 우선순위를 두고 선택합니다.
- 장점: 메모리 접근만으로 이루어지기 때문에 Filesort에 비해 훨씬 빠른 속도를 제공합니다. 쿼리 실행 계획에 using index라는 메시지가 표시되어 정렬 방식을 쉽게 확인할 수 있습니다.
- 단점: 인덱스가 많아지면 InnoDB 버퍼 풀을 위한 메모리 사용량이 증가합니다.
Filesort
- GROUP BY 또는 ORDER BY 절에 인덱스를 사용할 수 없는 경우
- 정렬 대상 데이터가 메모리 버퍼 크기를 초과하는 경우
- 복잡한 쿼리 조건으로 인해 인덱스 사용이 비효율적인 경우
인덱스를 사용할 수 없는 경우에 MySQL은 데이터를 임시 파일에 저장하고 외부 정렬 알고리즘을 사용하여 정렬 작업을 수행합니다. Filesort는 다음과 같은 경우 발생합니다.
- 장점: 인덱스 정렬 방식에 비해 유연하게 사용할 수 있습니다. ORDER BY 절에 여러 컬럼을 지정하거나 복잡한 정렬 조건을 사용할 수 있습니다.
- 단점: 데이터량이 많거나 정렬 대상 데이터가 메모리 버퍼 크기를 초과하면 성능 저하가 발생합니다. 쿼리 실행 계획에 using filesort라는 메시지가 표시되어 성능 문제 진단에 도움이 됩니다.

Filesort 발생 원인

Querydsl Group By 쿼리에서 Filesort가 발생하는 주요 원인을 정리하자면 다음과 같습니다.

Group By 대상 컬럼에 인덱스가 없는 경우

MySQL에서 group by 쿼리 실행 시 group by 대상 컬럼에 인덱스를 사용하여 데이터를 그룹화합니다. 하지만 group by 대상 컬럼에 인덱스가 없는 경우, MySQL은 데이터를 전체 테이블에서 스캔하여 그룹화해야 하며 이 과정에서 Filesort가 발생하게 됩니다.

ORDER BY 절에 Group By 대상 컬럼이 없는 경우

ORDER BY 절에 group by 대상 컬럼이 없는 경우, MySQL은 먼저 group by 작업을 수행한 후 결과 데이터를 다시 정렬해야 합니다. 이때 Group By 결과 데이터가 메모리 버퍼 크기를 초과하면 filesort가 발생하게 됩니다.

Filesort 발생 시 문제점

Filesort 발생 시 다음과 같은 문제점이 발생할 수 있습니다.

쿼리 실행 속도 저하

Filesort는 다음과 같은 과정에서 불필요한 디스크 I/O 작업을 증가시켜 쿼리 실행 속도를 크게 저하시킵니다.

1. 정렬 대상 데이터를 메모리 버퍼에 담을 수 없는 경우, MySQL은 데이터를 임시 파일에 저장합니다.
2. 임시 파일에 저장된 데이터를 외부 정렬 알고리즘을 사용하여 정렬합니다.
3. 정렬된 데이터를 다시 메모리에 로드하여 쿼리 결과에 반영합니다.

만약 여러 번 서비스 요청 등 많은 데이터 조회시 쿼리 실행 시간이 지연되어 사용자 경험에 악영향을 미칠 수 있습니다.

서버 부하 증가

Filesort는 CPU 및 메모리 자원을 많이 소모하여 서버 부하를 증가시킵니다.

CPU 사용량 증가: 외부 정렬 알고리즘은 CPU를 집중적으로 사용합니다.
메모리 사용량 증가: 정렬 대상 데이터가 메모리 버퍼에 담을 수 없는 경우, 임시 파일을 저장하기 위한 추가 메모리가 필요합니다.
디스크 I/O 사용량 증가: 임시 파일 읽고 쓰기 작업이 증가하여 디스크 I/O 사용량이 증가합니다.

이는 다른 쿼리 실행 속도에도 영향을 미쳐 전체 시스템 성능 저하를 초래할 수 있습니다.

Filesort 방지 방법

인덱스 활용
ORDER BY 절에 지정된 컬럼에 인덱스를 생성하면 MySQL은 인덱스를 사용하여 데이터를 정렬하므로 Filesort를 방지할 수 있습니다.
order_by_null 옵션 활용
ORDER BY 절에 group by 대상 컬럼을 포함하고, 해당 컬럼 값이 null인 경우 맨 앞 또는 맨 뒤로 정렬하도록 지정하면 Filesort를 방지할 수 있습니다.
쿼리 최적화
- WHERE 절 조건 활용: 불필요한 데이터를 쿼리 결과에서 제외하여 정렬 대상 데이터의 양을 줄일 수 있습니다.
- SELECT 절 최적화: 필요한 컬럼만 SELECT하여 정렬 대상 데이터의 양을 줄일 수 있습니다.
- GROUP BY 절 최적화: group by 대상 컬럼을 최소화하여 group by 작업에 소요되는 시간을 줄일 수 있습니다.

QueryDsl에서 order_by_null 옵션 활용

이번 프로젝트에서 Querydsl group by 쿼리에서 filesort를 방지하기 위해 order_by_null 옵션을 사용하고 있습니다. 다음은 프로젝트에서 사용중인 코드를 예시로 만들었습니다.

fun searchAll(
        searchParam: SearchParam,
    ): List<ProductDetail> = queryFactory.selectFrom(productDetail)
        .where(
            buildConditions(searchParam)
        )
        .applyGroupBy(searchParam.groupByList)
        .orderBy(OrderByNull.DEFAULT).fetch()

searchParam에 있는 groupByList에 있는 groupBy 대상 컬럼들이 인덱스에 없다면? querydsl에서 group by 대상 기준으로 using filesort옵션이 활성화되어 정렬을 하게 됩니다. 아직 querydsl에서는 using filesort을 조작할 수 있는 유틸함수를 제공해주지 않는 것 같았습니다. 별도로OrderByNull 클래스를 만들어 group by 시 사용하고 있습니다.

/**
 * group by 시 filesort 방지
 */
class OrderByNull private constructor() : OrderSpecifier<Comparable<*>>(
    Order.ASC, Expressions.nullExpression(), NullHandling.Default
) {
    companion object {
        val DEFAULT: OrderByNull = OrderByNull()
    }
}

마무리

Querydsl group by 쿼리에서 filesort는 쿼리 실행 속도를 크게 저하시키고 서버 부하를 증가시키는 문제점을 야기합니다. 따라서 인덱스 활용, order_by_null 옵션 활용, 쿼리 최적화 등의 방법을 통해 filesort를 방지하고 쿼리 성능을 향상시키는 것이 중요합니다.

참고자료

https://jojoldu.tistory.com/477

[kotlin] 동시성 제어하기

연두연두부 — Sun, 10 Mar 2024 23:59:14 +0900

동시성 문제는 여러 개의 스레드가 동시에 실행될 때 발생할 수 있는 문제로, 데이터 일관성 문제, 경쟁 조건 등이 대표적인 예입니다.

데이터 일관성 문제: 여러 스레드가 동일한 데이터를 동시에 수정할 때, 데이터의 일관성이 깨질 수 있습니다. 예를 들어, 한 스레드가 데이터를 수정하는 도중에 다른 스레드가 데이터를 수정하면 데이터가 손상될 수 있습니다.
경쟁 조건: 여러 스레드가 서로 경쟁하면서 자원을 사용할 때, 스레드 간의 충돌로 인해 예상치 못한 결과가 발생할 수 있습니다. 예를 들어, 한 스레드가 자원을 사용하고 있는 도중에 다른 스레드가 자원을 사용하려고 하면 충돌이 발생할 수 있습니다.

이번 포스트에서는 포인트 선물하기를 코틀린에서 동시성 문제를 해결할 때 사용할 수 있는 방법들을 소개하고자 합니다 .

volatile

공유 변수의 값이 변경될 때마다 모든 스레드가 해당 값을 최신 상태로 읽을 수 있도록 하는 키워드입니다. 변수 값 변경 시 모든 스레드에 즉시 알립니다. Kotlin 1.9.0 에서 kotlin.concurrent.Volatile 은 stable로 지원합니다.

class Account(var balance: Int = 0) {
    companion object {
        val totalBalance = AtomicInteger(0)
    }
}

fun sendPoint(sender: Account, receiver: Account, amount: Int) = runBlocking {
    sender.balance -= amount
    receiver.balance += amount
    Account.totalBalance.addAndGet(amount)
    println("[SEND] $amount")
}

fun main() {
    val sender = Account(100)
    val receiver = Account(0)
    val jobs = List(5) {
        launch {
            sendPoint(sender, receiver, 10)
        }
    }
    jobs.forEach { it.join() }
    println("[TOTAL] ${Account.totalBalance}")
}

하지만 @volatile은 atomic read, write는 보장하지만 atomicity of larger actions을 보장하지 않습니다. 즉, 변수 값 읽기/쓰기만 동기화합니다. 여러 스레드가 동시에 변수를 증가시키는 경우, 읽기/쓰기 사이에 다른 스레드의 변경 내용이 반영되지 않을 수 있습니다.

totalBalance 변수를 증가시키는 task이 여러 단계로 이루어져 있다면, 이 작업 전체가 원자적으로 수행되지 못할 수 있습니다. 만약 두 스레드가 동시에 point를 보내는 작업을 수행한다면, 다음과 같은 상황이 발생할 수 있습니다.

첫 번째 스레드가 totalBalance 변수의 값을 읽습니다.
두 번째 스레드가 totalBalance 변수의 값을 읽습니다.
첫 번째 스레드가 읽은 값에 1을 더하고, 더한 값을 totalBalance 변수에 씁니다.
두 번째 스레드가 읽은 값에 1을 더합니다.
두 번째 스레드가 더한 값을 totalBalance 변수에 씁니다.

fun sendPoint(sender: Account, receiver: Account, amount: Int) = runBlocking {
    sender.balance -= amount
    receiver.balance += amount

    // totalBalance 수정 (비원자적)
    val prevTotalBalance = Account.totalBalance.get()
    val newTotalBalance = prevTotalBalance + amount
    Account.totalBalance.compareAndSet(prevTotalBalance, newTotalBalance)

    println("[SEND] $amount")
}

@Volatile은 공유자원에 접근하여 write하는 스레드가 1개이고 공유자원을 read하는 스레드가 여러 개일 경우 유용합니다. 하지만 여러 스레드에서 동시에 접근하여 read/write 하는 공유자원은 @Volatile만으로는 안전하지 않습니다. 자원의 가시성을 확보하여 동기화에 유용하지만, 원자성 연산을 보장하지 않아 동시성 이슈를 해결에 충분하지 못합니다.

synchronized

한 번에 한 스레드만 접근할 수 있도록 하는 방법입니다. synchronized method or block을 스레드가 참조하는 동안 다른 스레드는 대기하게 됩니다.

1) synchronized method

메서드 전체가 동기화되어야 하거나 간단하고 직관적인 동기화 방법입니다. 하지만 상대적으로 성능 저하 가능성이 있습니다.

class Account(var balance: Int = 0) {
  companion object {
    @Volatile
    var totalBalance = 0

    @Synchronized
    fun sendPoint(sender: Account, receiver: Account, amount: Int) {
      // 송금 전에 송금자가 충분한 잔고를 가지고 있는지 확인
      if (sender.balance >= amount) {
        sender.balance -= amount
        receiver.balance += amount
        totalBalance += amount
        println("[SEND] $amount 포인트")
        receiver.receivePoint(amount)
      } else {
        println("[FAILED] 송금자가 잔고 부족")
      }
    }
  }

  @Synchronized
  fun receivePoint(amount: Int) {
    balance += amount
    println("[RECEIVE] $amount 포인트를 받았습니다.")
  }
}

fun main() {
  val sender = Account(100)
  val receiver = Account(0)
  val jobs = List(5) {
    launch {
      Account.sendPoint(sender, receiver, 10)
    }
  }
  jobs.forEach { it.join() }
  println("[TOTAL] ${Account.totalBalance}")
}

2) synchronized block

class Account(var balance: Int = 0) {
  companion object {
    @Volatile
    var totalBalance = 0

    fun sendPoint(sender: Account, receiver: Account, amount: Int) {
       // 송금 전에 송금자가 충분한 잔고를 가지고 있는지 확인
        if (sender.balance < amount) {
          println("[FAILED] 송금자가 잔고 부족")
        }
        synchronized(this) {
          sender.balance -= amount
          receiver.balance += amount
          totalBalance += amount
          println("[SEND] $amount 포인트")
          receiver.receivePoint(amount)
        }
      }
    }
  }

  fun receivePoint(amount: Int) {
    synchronized(this) {
      balance += amount
      println("[RECEIVE] $amount 포인트를 받았습니다.")
    }
  }
}

fun main() {
  val sender = Account(100)
  val receiver = Account(0)
  val jobs = List(5) {
    launch {
      Account.sendPoint(sender, receiver, 10)
    }
  }
  jobs.forEach { it.join() }
  println("[TOTAL] ${Account.totalBalance}")
}

synchronized는 임계 구역을 보호하는 데 유용합니다. 하지만 위 코드에서는 다음과 같은 문제가 발생할 수 있습니다.

synchronized 사용으로 인해 전체 Account 객체에 대한 lock이 걸려 성능 저하
totalBalance 업데이트 시에도 전체 객체 lock 필요 -> 불필요한 락으로 인한 동시성 제어 효율 저하

임계 구역 내에서 다른 스레드의 작업 완료를 기다리는 경우, 현재 스레드가 자신을 블록하여 CPU 자원을 낭비합니다. 그리고 다른 스레드가 임계 구역을 떠날 때까지 Unlock을 기다리는 스레드들이 CPU 자원을 소모하며 대기하게 됩니다. 스레드 경쟁이 심할수록 더 많은 스레드들이 블록 및 잠금 해제 대기를 하게 됩니다. 임계 구역 코드가 길다면 낭비 가능성이 더욱 높아지게 됩니다.

synchronized 키워드 방식은 병렬성에 취약하여 대규모 서비스에서 synchronized 키워드를 많이 사용할 경우 심각한 성능 저하가 생길 수 있습니다.

atomic 변수

원자적으로 연산을 수행할 수 있는 thread-safe 자료구조입니다. 여러 스레드가 동시에 접근하더라도 데이터 일관성을 유지할 수 있습니다. atomic 변수는 java.util.concurrent 패키지에 있으며, AtomicInteger, AtomicLong 등이 있습니다.

class Account(var balance: Int = 0) {
    companion object {
        val totalBalance = AtomicInteger(0)
    }
}

fun sendPoint(sender: Account, receiver: Account, amount: Int) = runBlocking {
    sender.balance -= amount
    receiver.balance += amount
    Account.totalBalance.addAndGet(amount)
    println("[SEND] $amount points")
}

fun main() {
    val sender = Account(100)
    val receiver = Account(0)
    val jobs = List(5) {
        launch {
            sendPoint(sender, receiver, 10)
        }
    }
    jobs.forEach { it.join() }
    println("[TOTAL] ${Account.totalBalance}")
}

atomic 변수는 다음과 같은 장점을 같습니다.

atomic 변수는 compare-and-swap(CAS) 연산을 사용하여 원자적으로 값을 변경합니다. CAS 연산을 통해 다른 스레드의 접근을 막지 않기 때문에 여러 스레드가 동시에 접근하더라도 데이터 일관성을 유지할 수 있습니다.
atomic 변수는 일반적인 변수와 달리 메모리에 한 번만 저장됩니다. 이는 여러 스레드가 동시에 접근할 때 메모리 접근 횟수를 줄일 수 있어 메모리 효율성을 높일 수 있습니다.
atomic 변수를 사용하면 여러 스레드가 동시에 접근할 때, context switching이 감소합니다. atomic 변수가 원자적으로 연산을 수행하기 때문에 스레드 간의 충돌을 방지하고,lock 사용을 줄임으로써 context switching이 최소화하여 시스템의 성능을 향상 시킬 수 있습니다.
하지만 복잡한 경우에는 다른 방식을 사용해야 합니다.

thread-safe (concurrent) collections

여러 스레드가 동시에 접근할 수 있는 컬렉션입니다. 스레드 안전성을 보장하며, 동시성 작업을 효율적으로 수행할 수 있습니다.

class Account(private val initialBalance: Int) {
  private val balance = AtomicInteger(initialBalance)

  fun sendPoint(amount: Int, receiver: Account) {
    if (balance.addAndGet(-amount) < 0) {
      println("[FAILED] ${this.name}님의 포인트가 부족합니다.")
      return
    }

    receiver.receivePoint(amount)
    println("[SEND] ${this.name}님이 ${receiver.name}님에게 ${amount}포인트를 선물했습니다.")
  }

  fun receivePoint(amount: Int) {
    balance.addAndGet(amount)
    println("[RECEIVE] ${this.name}님이 ${amount}포인트를 받았습니다.")
  }
}

fun main() = runBlocking {
  // 캐시처럼 사용할 ConcurrentHashMap
  val users = ConcurrentHashMap<String, Account>()

  // 사용자 추가
  users["Karina"] = Account("Karina", 100)
  users["Giselle"] = Account("Giselle", 150)
  users["Ningning"] = Account("Ningning", 50)
  users["Winter"] = Account("Winter", 200)

  // 10개의 무작위 송금 작업 실행
  val jobs = List(10) {
    launch {
      val senderName = users.keys.random()
      val receiverName = users.keys.random()
      val amount = (1..10).random()

      // ConcurrentHashMap에 없는 사용자 확인
      val sender = users[senderName] ?: run {
        println("[FAILED] ${senderName}님은 존재하지 않는 사용자입니다.")
        return@launch
      }

      // 송금자 잔고 확인
      if (sender.balance.addAndGet(-amount) < 0) {
        println("[FAILED] ${senderName}님의 포인트가 부족합니다.")
        return@launch
      }

      // 수신자 정보 확인
      val receiver = users[receiverName] ?: run {
        println("[FAILED] ${receiverName}님은 존재하지 않는 사용자입니다.")
        return@launch
      }

      // 포인트 송금
      receiver.receivePoint(amount)
      println("[SEND] ${senderName}님이 ${receiverName}님에게 ${amount}포인트를 선물했습니다.")
    }
  }

  // 모든 작업 종료 기다림
  jobs.forEach { it.join() }

  // 최종 잔고 출력
  users.forEach { (name, account) -> println("[TOTAL] $name님: ${account.balance.get()}포인트") }
}

ConcurrentHashMap은 여러 사용자가 동시에 데이터에 접근해야 하는 경우 HashMap보다 ConcurrentHashMap을 사용하면 락을 사용하여 동시 접근을 제어하여 시스템의 안정적인 동작을 기대할 수 있습니다.
concurrent collection은 여러 사용자가 동시에 데이터를 읽고 쓰는 경우에 유용합니다. 그리고 여러 사용자가 동시에 티켓을 예약하는 경우 데이터 경쟁 가능성이 높은 경우에 concurrent collection을 활용합니다. 대표적으로 caching system이 있습니다. 다음은 ConcurrentHashMap을 사용하는 라이브러리입니다. explain Guava for cache, explain Caffeine for cache

semaphore

lock 이 아닌 semaphore 기반으로 여러 스레드가 공유 자원에 접근하는 것을 제어합니다. 한 번에 접근할 수 있는 스레드의 수를 제한함으로써 데이터 일관성 문제를 예방할 수 있습니다.

class Account(var balance: Int = 0)

fun sendPoint(sender: Account, receiver: Account, amount: Int, semaphore: Semaphore) = runBlocking {
  // 세마포어 획득
  semaphore.acquire()
  try {
    // 송금 전에 송금자가 충분한 잔고를 가지고 있는지 확인
    if (sender.balance >= amount) {
      sender.balance -= amount
      receiver.balance += amount
      println("[SEND] $amount 포인트")
    } else {
      println("[FAILED] 송금자가 잔고 부족")
    }
  } finally {
    // 세마포어 해제
    semaphore.release()
  }
}

fun main() = runBlocking {
  val sender = Account(100)
  val receiver = Account(0)
  val semaphore = Semaphore(1) // 이체 시 동시성을 1로 제한
  val jobs = List(5) {
    launch {
      sendPoint(sender, receiver, 10, semaphore)
    }
  }
  jobs.forEach { it.join() }
  println("[TOTAL] sender : ${sender.balance}")
  println("[TOTAL] receiver: ${receiver.balance}")
}

mutex

lock을 이용하여 한 번에 한 스레드만 접근할 수 있도록 합니다. 이를 통해 데이터 일관성 문제를 해결할 수 있습니다. 뮤텍스를 획득하고 해제할 경우 명시적으로 lock 획득/해제 호출이 필요합니다.

class Account(var balance: Int = 0)

fun sendPoint(sender: Account, receiver: Account, amount: Int, mutex: Mutex) = runBlocking {
    with(mutex) {
        // 잠금 획득
        lock()
        try {
            sender.balance -= amount
            receiver.balance += amount
            println("[SEND] $amount points")
        } finally {
            // 잠금 해제
            unlock()
        }
    }
}

fun main() = runBlocking {
    val sender = Account(100)
    val receiver = Account(0)
    val mutex = Mutex()
    val jobs = List(5) {
        launch {
            sendPoint(sender, receiver, 10, mutex)
        }
    }
    jobs.forEach { it.join() }
    println("[TOTAL] sender : ${sender.balance}")
    println("[TOTAL] receiver: ${receiver.balance}")
}

`withlock()` with ReentrantLock

lock을 이용하여 한 번에 한 스레드만 접근할 수 있도록 합니다. block 내 코드를 실행하기 때문에 자동으로 lock 획득/해제가 됩니다. 이에 따라 블럭 withlock() 외부에 있는 코드는 lock 해제까지 영향을 받게 됩니다. ReentrantLock을 사용해서 다시 재진입이 가능합니다.

fun sendPoint(sender: Account, receiver: Account, amount: Int, lock: ReentrantLock) = runBlocking {
  lock.withLock {
    // 송금 전에 송금자가 충분한 잔고를 가지고 있는지 확인
    if (sender.balance >= amount) {
      sender.balance -= amount
      receiver.balance += amount
      println("[SEND] $amount 포인트")
    } else {
      println("[FAILED] 송금자 잔고 부족")
    }
  }
}

fun main() = runBlocking {
  val sender = Account(100)
  val receiver = Account(0)
  val lock = ReentrantLock()
  val jobs = List(5) {
    launch {
      sendPoint(sender, receiver, 10, lock)
    }
  }
  jobs.forEach { it.join() }
  println("[TOTAL] sender : ${sender.balance}")
  println("[TOTAL] receiver: ${receiver.balance}")
}

actors

Actor는 독립적인 실행 단위로, 자신의 상태와 메시지를 처리하는 로직을 가지고 있습니다. Actor 간의 통신은 메시지를 통해 이루어지며, 메시지는 Actor의 mailbox에 저장됩니다.

스레드와는 달리, Actor는 상태를 가지지 않으며, 실행 중에 다른 Actor나 함수를 호출할 수 있습니다. 이로 인해 Actor 방식은 스레드 간의 경쟁 조건을 방지하고, 자원 관리를 간편하게 할 수 있습니다.

sealed class Message {
    data class SendPoint(val amount: Int) : Message()
}

class Account(var balance: Int = 0)

class AccountActor(val account: Account) : CoroutineScope {
    private val channel = Channel<Message>()
    override val coroutineContext = SupervisorJob() + Dispatchers.Default + channel

    fun send(message: Message) {
        launch {
            channel.send(message)
        }
    }

    fun receive(): Message = channel.receive()
}

fun main() = runBlocking {
    val sender = Account(100)
    val receiver = Account(0)
    val senderActor = AccountActor(sender)
    val receiverActor = AccountActor(receiver)

    val jobs = List(5) {
        launch {
            senderActor.send(Message.SendPoint(10))
            receiverActor.send(Message.SendPoint(-10))
        }
    }

    jobs.forEach { it.join() }

    println("[TOTAL] sender : ${sender.balance}")
    println("[TOTAL] receiver: ${receiver.balance}")
}

Message 클래스를 sealed 클래스로 정의하고, SendPoint 클래스를 그 하위 클래스로 정의합니다. sealed class를 사용하면 메시지의 타입이 명확하게 정의되기 때문에, 다른 스레드나 코루틴에서 잘못된 메시지를 전송하는 것을 방지할 수 있습니다. 이를 통해 안전한 동시성을 보장할 수 있습니다. 따라서 Message 클래스의 하위 클래스인 SendPoint, ReceivePoint 등을 정의하여 각각의 메시지 타입을 명확하게 구분할 수 있습니다.

AccountActor 클래스를 정의하여 Account 객체와 통신할 수 있는 채널을 생성합니다. sendPoint() 메소드는 채널을 통해 amount 값을 전송하고, receivePoint() 메소드는 채널로부터 값을 수신합니다. main 함수에서는 AccountActor 객체를 생성하고, sendPoint() 메소드를 호출하여 sender와 receiver의 balance를 수정합니다. 모든 작업이 완료된 후에는 balance 값을 출력합니다.

결론

다음 상황에서 동기화 방식을 추천합니다.

일반적으로 synchronized나 ReentrantLock을 추천합니다.
특정 변수값 변경 시 모든 스레드에 동기화가 필요한 간단한 경우에는 volatile, atomic 변수을 사용하는 것을 추천합니다. 예를 들면 10번 출석체크를 했는지 횟수를 카운팅하는 시스템에서 count 변수 증가를 할 때 적절합니다.
여러 스레드가 동시에 컬렉션에 접근해야 하는 경우 concurrent 컬렉션을 이용하여 동기화를 추천합니다. 예를 들면 온라인 쇼핑몰에서 여러 고객이 동시에 제품 목록을 조회하고 장바구니에 담는 시스템에서 productList 컬렉션 관리할 때 적절합니다.
특정 메서드 실행 중 다른 스레드의 접근을 차단해야 하는 경우에는 synchronized method 동기화를 추천합니다. 예시로는 파일 시스템에서 파일을 읽고 쓰는 메서드 동기화가 있습니다.
특정 코드 블록만 동기화해야 하는 경우에는 synchronized block 동기화를 추천합니다. 예시로 여러 스레드가 동시에 데이터베이스에 접근해야 하는 경우, 접근 코드만 동기화가 있습니다.

Java 기본 개념

연두연두부 — Thu, 29 Jul 2021 22:25:01 +0900

Java 자료형

Primitive
- 실제 데이터 값을 저장하는 자료형
- 크게 논리형, 문자형, 실수형
- boolean, char, byte(-128-127) , short, int, long, float, double
Reference Type
- 메모리 주소 값을 통해 객체를 참조하는 타입
- 실제 객체 - 힙 영역에 저장
- 참조 타입 변수 - 스택 영역에 실제 객체들의 주소를 저장
- 객체를 사용할때 참조 변수에 저장된 객체의 주소를 불러와 사용하는 방식

Integer a = (Integer) 500;
Integer b = (Integer) 500;
System.out.println(a==b); //false

Integer a = 127;
Integer b = 127;
System.out.println(a==b); //true

IntegerCache.low 보다 크고 IntegerCache.high 보다 작은 int 리터럴 i를 넘긴다면, Integer.valueOf() 메소드는 IntegerCache 로부터 Integer 객체들을 리턴 IntegerCache.low 와 IntegerCache.high 의 기본값은 각각 -128과 127.

즉, Integer.valueOf() 메소드는 -128 에서 127 사이의 int literal을 넘겨줄 때, 새로운 Integer 객체를 생성하고 리턴하는 대신, 내부의 IntegerCache 객체에서 Integer 객체를 반환한다. 캐시는 static block에 의해 IntegerCache 클래스가 메모리에 로드되는 처음에 초기화된다. Java는 -128 부터 127 범위의 정수 객체를 캐싱한다. 이 범위의 정수들은 개발할 때 빈번하게 사용되기 때문이다. Integer 캐시는 범위를 수정할 수 있지만 그외 타입 캐시는 수정 불가능하다.

Integer과 int 크기 비교
- int : Primitive type
- Integer : Wrapper 클래스
약 5배차이
Object 8 byte
Integer 16 byte
Integer 참조하는 변수 4 byte
Integer 사이즈 = 16+4 byte

Primitive type과 Wrapper class

Primitive type : int
- 산술연산 가능
- null로 초기화 불가능
Wrapper class
- 산술연산 불가능 → Unboxing으로 가능
- null 값 처리 가능 → DB에서 특정 컬럼의 자료형이 정수형이지만 null이 들어올 수 있을 때 VO에서 Integer를 사용하여 null인 경우를 처리할 수 있다

Boxing과 Unboxing

Boxing
- Primitive 자료형 → Wrapper 클래스
Unboxing
- Wrapper 클래스 → Primitive

싱글톤

객체를 하나만 생성해야 할 때
그리고 그 객체에 어디서든 접근이 가능해야 할 때

public class Star{

	private static Star instance = new Star();

	private Star() {}

  	public static Star getInstance() {
      		return instance;
  	}
}

싱글톤 패턴 작성 방식

eager intialization
- 위 코드의 방식
- 클래스가 최초로 로딩 될 때 객체가 생성되기때문에 Thread-safe
Lazy Initialization with synchronized
- 동적 바인딩(dynamic binding)(런타임시에 성격이 결정됨)을 통해 인스턴스를 생성
- synchronized 키워드를 이용한 게으른 초기화 방식인데, 메서드에 동기화 블럭을 지정해서 Thread-safe
Lazy Initialization. Double Checking Locking(DCL, Thread-safe)
- 인스턴스가 생성되지 않은 경우에만 동기화 블럭이 실행되게끔 구현하는 방식
Lazy Initialization. LazyHolder(게으른 홀더, Thread-safe)
- volatile 이나 synchronized 키워드 없이도 동시성 문제를 해결

자바와 스프링의 싱글톤 차이점

싱글톤 객체의 생명주기가 다르다

자바 싱글톤 객체의 범위는 클래스 로더가 기준
스프링에서는 어플리케이션 컨텍스트가 기준
Bean을 등록할 때 범위의 default는 Singleton다. 싱글톤 이외 범위는 prototype, request, session이 있다.

final

클래스 앞에 final키워드가 붙으면 '자식을 가질수 없는 최종 클래스'
메소드 앞에 final키워드가 붙으면 '더이상 오버라이딩 할 수 없는 최종 메소드'
변수 앞에 final은 상수화

주의!! final int[] array로 할당된 그 변수의 수정 (혹은 새로운 값 할당)이 금지된거지, 그 변수가 가리키고 있는 참조안에 있는 값들이 immutable이라는 뜻은 아님

상속

자식 클래스에서 오버라이딩하는 메서드는 이름이 같아야 한다.
- 매개변수가 같아야 한다.
- 리턴 타입이 같아야 한다.
접근 제어자를 부모 클래스의 메서드보다 좁은 범위로 변경할 수 없다.
예외는 부모 클래스의 메서드보다 많이 선언할 수 없다.
인스턴스 메서드를 static메서드로 또는 그 반대로 변경할 수 없다.

상속 키워드

인터페이스 <- 클래스 implements
인터페이스 <- 인터페이스 extends★

추상클래스와 인터페이스

추상클래스

단일상속
is-a
생성자가질수있음

인터페이스

다중상속
has-a
생성자가질수없음
인터페이스 멤버변수는 public static final 고정
인터페이스 메서드 public 고정
상속받은 메서드는 overriding하더라도 public
- 자바 8 default 메서드 쓸 수 있음
- 자바 9 private, private static를 쓸 수 있음

접근제어자(접근범위 넓은 순으로)

public - protected - default - private 전체 - (다른패키지)자손/상속 - 같은패키지 - 같은클래스

주의!!! 최상위 클래스에만 사용될 수 있는 접근제한자는 public이다

다형성+상속

참조변수가 더 상위클래스 >=
메서드 호출할 때, (동적바인딩)
- 참조변수의 클래스에 해당 메서드가 있는가
- 참조변수의 클래스의 부모클래스에 해당 메서드가 있는가
- new로 생성되는 (오른쪽) 클래스에 해당 메서드가 있는가
- new로 생성되는 (오른쪽) 클래스까지 하위 클래스 중에 해당 메서드가 있는가

동적바인딩

컴파일시 참조변수의 클래스 타입이지만 런타임시 해당 클래스를 찾아간다

instanceof 연산자

null instanceof Object
- instanceof연산에서 앞에 null이 오면 무조건 false를 반환한다.

컬렉션 프레임워크

Collection 인터페이스

List 인터페이스
1. ArrayList
  - synchronized를 이용한 과도한 동기화는 성능을 떨어뜨릴 수 있고 교착 상태에 빠뜨릴 수 있으며, 예측할 수 없는 동작을 유발
2. CopyOnWriteArrayList
  - 내부의 배열은 절대 변경할 수 없으므로 순회할 때 락이 필요 없어서 속도면에서 매우 빠르다
  - List를 읽기 위해 어딘가에 전달할 때 원본이 아닌 복사본을 만들어서 전달
3. synchronizedList
  - 한번에 하나의 스레드만 접근
  - 동기화로 스레드 세이프
Set 인터페이스
- Set에 null이 추가된다
Queue 인터페이스
Map 인터페이스
- Map은 컬렉션을 상속하지 않는다
- HashMap 키에 null이 된다
HashMap의 키에 오는 클래스에 hashcode + equals 재정의

컬렉션에서 오토박싱/언박싱

오토 언박싱
컬렉션에서 값을 읽어서 기본타입에 할당
오토 박싱
컬렉션에다가 기본타입 저장 컬렉션에는 무적권 "객체"만 저장가능!

Comparable Comparator 인터페이스

메소드 1개밖에 없음

 new Priority Queue((a, b) -> { return a-b;});

스트림 종류

FileInputStream 비문자
FileReader 문자
BufferedReader로 개행단위

File file = new File("c:\\example\\File\\umejintan_new.txt");
input = new FileInputStream(file);
int readBuffer = 0;
byte [] buffer = new byte[512];
while((readBuffer = input.read(buffer)) != -1) {
	System.out.write(buffer, 0, readBuffer);
}

File file = new File("C:\\Users\\world\\Desktop\\javaprogramming\\FileIO\\Sample.txt");
FileReader filereader = new FileReader(file);
//입력 버퍼 생성
BufferedReader bufReader = new BufferedReader(filereader);
String line = "";
while((line = bufReader.readLine()) != null){
	System.out.println(line);
}

File.Seperator 운영체제에 상관없이
직렬화
- 객체의 상태값을 일렬로 나열한 것
- 객체의 상태값을 객체로 복원한 것

연산

1. BigDecimal

BigInteger, BigDecimal로

https://sejoung.github.io/2019/03/2019-03-07-Item_60_Avoid_float_and_double_if_exact_answers_are_required/

2. 오버플로우 방지

면접질문

Q1 클래스에서 사용하는 변수의 3가지 종류에 대해 설명해주세요.

로컬 변수는 메서드 내에서 선언된 위치부터 소속된 중괄호가 끝나는 지점까지 사용이 가능합니다.
인스턴스 변수는 클래스를 통해 생성된 인스턴스 내에서 접근이 가능합니다.
클래스 변수는 클래스의 모든 인스턴스에서 공유하는 변수로서 클래스가 메모리에 올라갈 때 static 영역에 생성됩니다.

Q2 Wrapper Class에 대해 설명해주세요.

8개의 기본 타입에 해당하는 데이터를 객체로 포장해주는 클래스
Wrapper 클래스를 이용할 때 주의할 점은 참조형끼리 연산이 불가능하기 때문에 기본 자료형으로 변환하여 연산해야 한다.

Q3 StringBuilder와 StringBuffer의 차이점을 설명해주세요.

둘의 차이점은 동기화 처리 여부입니다.
StringBuilder는 동기화 처리를 하지 않아 StringBuffer보다 속도가 더 빠릅니다. StringBuffer은 속도는 느리지만 멀티 스레드 환경에서 안전하게 사용할 수 있습니다.

문제 1

class A {
	String go() {
		return "Go!";
	}
}

class B extends A {
	//int go() {
	//	return 3;
	//}
	String go() {
		return "3";
	}
}

public class Main {
	public static void main(String[] args) {
		A a = new B();
		System.out.println(a.go());
	}
}

실행 결과는?

컴파일 에러
런타임 에러
Go!
3

문제 2

String a = "Joylish";
String b = "Joylis"+ "h";
String c = new String("Joylish");
int x = 10;

a == b 는 무엇일까요?
a + a == a+b 는 무엇일까요?
a + x == b+x 는 무엇일까요

[대규모 서비스를 지탱하는 기술] 1장 정리

연두연두부 — Thu, 29 Jul 2021 19:19:02 +0900

'대규모 서비스를 지탱하는 기술' 책을 읽고 정리하였습니다.

무엇을 '대규모'라고 하는가

취업 준비할 때 공고를 보면, 대규모 서비스를 운영해본 경험이 있는 분을 우대한다는 문구가 많았다. '무엇을, 어떤 것을 보고 대규모 서비스라고 하는지' 궁금했다.

대규모 서비스는 1대의 서버로 운영할 수 없는 서비스 , 즉 서버 확장이 필요한 서비스라고 한다. 고객은 웹 사이트, 앱 및 플랫폼에서 항상 똑같은 서비스를 제공받길 기대한다. 책을 주문하고 있는데 갑자기 웹 사이트가 느려지거나 404 페이지가 난다면? 이는 고객 만족도를 떨어트린다. 여러 번 발생한다면? 고객은 다신 서비스를 이용하지 않거나 다른 경쟁 서비스로 이동할 수 있다. 따라서 회사 입장에선 서비스가 더 빠르게 성장하길 원하기 때문에 확장성을 고려해야할 수 밖에 없는 것이다.

그렇다면 서버 확장하는 방법은 무엇이 있을까

What is Scaling

확장성은 시스템이 제대로 기능하기 위해 요구사항에 맞추어 용량 및 성능을 조정하는 것이다.

Scale up

CPU 변경/ RAM 추가 또는 고성능 서버로 교환하여 기존 서버의 성능이나 용량 증강시켜, 더욱 처리 능력을 향상시키는 것이다.
하나의 서버의 능력을 증강하기 때문에 수직 스케일링(vertical scaling)이라고 한다.

확장성
- 하드웨어 허용 범위 내에서만 확장 가능하다. 그 이상으로 업그레이드를 하고자 한다, 새로운 장비로 교체해야 한다.
- 새 장비로 교체할 때, 데이터 전체의 마이그레이션 작업이 필요해 HA 구성이 아닌 이상 다운타임이 불가피하다. 저장된 데이터양에 따라 작업이 수개월 걸릴 수 있다.
비용
- 추가적인 네트워크 연결 없이 용량을 증강할 수 있다.
- 추가되는 용량이나 업그레이드 비용만 부가된다.
- 인프라의 노후화로 인한 업그레이드 주기는 이전보다 좁혀지는 추세이다. 최근에는 짧게 3년에서 최대 7년까지로 잦은 교체 주기로 인한 비용을 고려했을 때 scale out 대비 상대적으로 불리하다
장애
- Server 한 대에 모든 부하가 집중되므로 장애 시 영향을 크게 받을 수 있는 위험성이 있음
활용
- 온라인 금융거래와 같이 워크플로우 기반에 빠르고 정확하면서 단순한 처리가 필요한 OLTP(Online Transaction Processing) 환경에서는 고성능의 스케일업 방식이 적합
- 백업용 스토리지를 구축하는 데 있어서 향후 수년간 데이터 증가 폭이 미미하거나 규모가 작은 경우

Scale out

기존 서버와 동일하거나 비슷한 사양의 서버 대수를 늘려 기존 서버의 성능이나 용량 증강시켜, 더욱 처리 능력을 향상시키는 것이다.
사용자는 분산 파일 시스템이나 글로벌 네임스페이스(global namespace)를 통해 스토리지 서버 클러스터를 하나의 시스템으로써 인식하며, 서버를 추가로 확장하기 때문에 수평 스케일링(horizontal scaling)이라고 한다.

확장성
- 확장이 유연하다. 장기적인 용량 증가 추이를 예측할 필요 없이 그 시점에 필요한 만큼 서버를 추가해 용량과 성능을 확장할 수 있다.(pay-as-you-grow)
- 여러 개의 서버에 부하를 균등하게 분산시키기 위해 로드 밸런싱이 필요하다
- 복수의 서버를 연결하기 때문에 케이블링이 복잡하다
- 개별 노드는 scale up 된 하이엔드 하드웨어보다 상대적으로 성능이나 안정성이 떨어질 수 있다.
비용
- 기존 서버에 새 서버를 연결해서 사용하거나 다운타임 없이 오래된 서버를 인프라에서 제거하면 된다.
- 소프트웨어 가격이 스케일업에 비해 비싸다.
장애
- Server 한 대가 장애로 다운되더라도 다른 server로 service 제공이 가능하다
- 노드를 확장할수록 문제 발생의 잠재 원인 또한 추가한 만큼 늘어나게 된다
  - 여러 노드 간 데이터 직렬화 및 동기화 문제 발생 가능
  - 노드가 늘어나도 성능이 증가하지는 않고 노드 증가에 따라 수용가능한 트래픽이 늘어나 대역폭은 증가해 지연이 발생할 가능성이 있다
활용
- 여러 노드를 연결해 병렬 컴퓨팅 환경을 구성하고 유지하려면 아키텍처에 대한 높은 이해도가 요구
- 대량의 데이터 처리와 복잡한 쿼리가 이루어지는 OLAP(Online Analytical Processing) 애플리케이션 환경
  - 데이터 마이닝
  - 검색엔진 데이터 분석 처리
고민할 부분 Wrap up

요청을 어떻게 여러 서버에 분산할 것인가?
DB를 분산했을 때 데이터 동기화 문제처리는 어떻게 할 것인가?
분산 환경에서 주는 네트워크 지연시간(latency)은 어떻게 처리할까?
서비스간 트랜잭션 처리, 장애 복구는 어떻게 할까?
여러 대 운용은 어떻게 자동화할 것인가?

Reference

JVM

연두연두부 — Wed, 7 Jul 2021 19:18:57 +0900

JVM이 왜 등장했을까

Java는 네트워크에 연결된 모든 디바이스에서 작동하는 것이 목적이었다. 즉, 디바이스마다 운영체제와 하드웨어가 다르기 때문에 플랫폼에 의존적이지 않는 언어를 만들고 싶었다고 한다. 그래서 Java 바이트 코드를 실행시킬 수 있는 JVM이 등장했다.

주요 용어

환경, 플랫폼 = 운영체제 + CPU
ex) 내 컴퓨터의 운영체제는 Linux야. CPU는 AMD 라이젠.
컴파일 플랫폼 : 프로그램을 만들고 있는 컴퓨터 (개발자 컴퓨터)
타겟 플랫폼 : 프로그램을 사용할 컴퓨터 (사용자 컴퓨터)

환경이 다를 경우 Java와 C/C++ 대응방식

C/C++ : 크로스컴파일; 타겟 플랫폼에 맞춰 컴파일

Java : 자바 바이트 코드는 플랫폼에 상관없이 / 플랫폼 독립적으로 JVM 위에서 동작
주의! JVM은 타겟 플랫폼에 의존한다

Java를 사용해서 프로그램을 작성하려면 JDK를 설치해야 한다.
여기서 JDK는 운영체제별 종류가 다르다. JDK안에는 JRE, API, JVM이 포함되어 있다.
운영체제마다 다른 JVM이 제공되기 때문에 독립적일 수 있다.

JVM은 무엇일까

JVM(자바가상머신)은 Java의 바이트 코드를 운영체제가 이해할 수 있는 기계어(명령어)로 해석한다. JVM은 Main method가 없으면 실행되지 않는다.

Java로 작성한 소스코드(.java)가 컴파일
Java 바이트코드(.class)파일 생성
바이트 코드는 JVM을 거쳐서 기계어로 변환

.java 파일 : java 규칙에 맞게 작성한, 사람이 읽을 수 있는 소스코드 파일이다
.class 파일 : 컴파일러에 의해 생성된 java bytecode로 구성된 파일이다.
컴파일러 : .java파일에 오류가 있는지 검사하고 JVM을 위한 Java 바이트 코드를 생성한다.

Java 소스코드가 실행되기까지

Java Compiler
JIT Compiler
Java Virtual Machine(JVM)

JVM 구조

class loader subsystem
runtime data area
execution engine
native method interface - JNI
native method libraries

1. Class Loader Subsystem

클래스 로더(Class Loader)

Runtime 시에 .jar 파일 내 저장된 클래스 파일(Java 바이트코드)을 JVM에 로드하고 사용하지 않는 Class는 메모리에서 삭제한다.
자바는 동적 로딩(Dynamic Loading) 을 지원한다. Class Loader는 컴파일 타임에 모든 클래스가 로딩되지 않고 필요한 시점에 (런타임 도중) 해당 클래스를 실행하고 로딩한다.

Java 8 기준 ClassLoader 계층구조

1) Bootstrap ClassLoader

최상위 클래스
<JAVA_HOME>/jre/lib에 담긴 자바 라이브러리를 로딩한다.
Native C로 구현됨.

2) Extension ClassLoader

<JAVA_HOME>/jre/lib/ext 폴더에 담긴 자바의 확장 클래스파일을 로딩한다.
Java로 구현됨.

3) Application ClassLoader

-classpath(또는 -cp)폴더에 있는 클래스를 로딩한다.
Java로 구현됨.
개발자가 직접 작성한 코드를 로딩한다.

위의 클래스들은 아래 3가지 원칙에 따라 동작한다.

Delegation Principle
클래스 로더는 상위 클래스 로더로 로딩요청을 위임한다. 최상위 클래스로더, 부트스트랩 로더에서부터 로딩요청을 수행하고 하위 클래스로더로 요청을 넘긴다.
Visibility Principle
범위 규칙을 적용한다. 하위 클래스로더는 상위 클래스로더의 클래스를 찾을 수 있다. 하지만 상위클래스 로더는 하위클래스 로더가 로딩한 클래스를 사용할 수 없다.
Uniqueness Principle
하위 클래스로더는 상위 클래스로더가 로딩한 클래스를 다시 로딩하지 않는다.

2. Runtime Data Area ⭐

JVM 이 Java 바이트코드를 실행하기 위해 운영체제로부터 할당받은 메모리 공간이다. Thread끼리 공유하는 영역인지 아닌지 여부에 따라 Runtime Data Area에 있는 주요 구성요소를 정리해보았다.

2-1 Thread가 공유하지 않는 영역

1) PC Register

스레드가 시작될 때 함께 생성되는 공간이다. 스레드마다 1개씩 있다.
스레드가 어떤 부분을, 어떤 명령으로 실행해야 할 지 기록한다.
JVM은 Stacks-Base 방식으로 작동한다. 즉, JVM은 CPU에 직접 Instruction을 수행하지 않고 Stack에서 Operand를 뽑아내 이를 별도의 메모리 공간, PC Register에 저장한다

2) JVM Stack

Thread 제어를 위해 사용되는 메모리 영역이다. 스레드가 생성될 때마다 1개씩 생성된다.
메소드 호출 시 생성되는 스레드 수행정보를 기록하는 Frame(Stack Frame)을 저장하는 공간
메소드 정보, 지역변수, 매개변수, 연산 중 발생하는 임시 데이터 저장하는 공간
기본(원시)타입 변수는 스택 영역에 직접 값을 가진다. 참조타입 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다.

Method 가 호출 되면 Method와 Method 정보는 Stack에 쌓이게 된다.
Method 호출이 종료 될때 Stack point에서 제거 된다. Method 정보는 해당 Method의 매개변수, 지역변수, 임시변수,메소드 호출 한 주소 등을 저장하고 Method 종료시 메모리 공간이 사라진다.

멀티 Thread 프로그램의 경우 각 Thread가 자신의 Stack을 가지고는 있지만 Heap 영역은 공유하기 때문에, 프로그래밍시에 Thread-safe 하지 않는 이슈에 주의하며 프로그래밍을 해야 한다.

3) Native Method Stack

Java가 아닌 다른 언어로 작성된 코드(C, C++ 등)에서 제공되는 Method 정보를 저장하기 위한 Stack
JNI(Java Native Interface)가 해당 코드를 바이트코드로 변환하여 저장한다.

2-2 Thread가 공유하는 영역

4) Method Area/Class Area/Static Area

JVM이 읽어들인 클래스와 인터페이스에 대한 Runtime Constant Pool, 멤버 변수, 클래스 변수(Static 변수), 생성자와 메소드를 저장하는 공간이다.

프로그램 실행 중 클래스가 사용되면, JVM은 클래스 파일(Java 바이트 코드)을 읽어서 분석하여 클래스 변수, 클래스의 인스턴스 변수, 메소드 코드 등을 Method Area에 저장한다.

프로그램이 실행되면 모든 코드가 저장되어 있는 상태가 아니다. new 키워드를 통해 객체가 동적으로 생성되기 이전에는 텍스트 일 뿐이다. 객체 생성 후에 메소드를 실행하게 되면 해당 클래스 코드에 대한 정보를 Method Area에 저장 하게 된다.

클래스 변수(Static 변수)는 Method Area의 Class Variable에 저장한다.

기본형이 아닌 static 클래스형 변수는 레퍼런스 변수만 저장되고 실제 인스턴스는 Heap에 저장되어 있다. 그 후 이 인스턴스의 변수를 저장하기 위해 Heap에 메모리가 확보가 되고 Heap의 인스턴스가 Method Area의 어느 클래스 정보와 연결되는지 설정 하게 된다.

Method Area/Class Area/Static Area에 저장되는 정보

(a) Type Information

클래스와 인터페이스를 Type라고 본다.

Type의 전체 이름 (패키지명 + 클래스명)
Type의 직계 하위 클래스 전체 이름
Type의 클래스 / 인터페이스 여부
Type의 modifier (public / abstract / final)
연관된 인터페이스 이름 리스트

(b) Runtime Constant Pool ⭐

Method Area 에 있는 독자적인 영역
클래스 파일 constant_pool 테이블에 해당하는 영역
상수 자료형을 저장하여 참조하고 중복을 막기 위한 공간

Type, Field, Method로의 모든 Symbolic Reference 정보를 포함
클래스와 인터페이스 상수, 메소드와 필드에 대한 모든 레퍼런스를 저장한다
Constant Pool의 Entry는 배열과 같이 인덱스 번호를 통해 접근
Object의 접근 등 모든 참조를 위한 핵심 요소

Field Type
Field modifier (public / private / protected / static / final / volatile / transient)

(d) Method Information : Constructor를 포함한 모든 메소드

Method Name
Method Return Type
Method Parameter 수와 Type
Method modifier (public / private / protected / static / final / syncronized / native / abstract)
Method 구현 부분이 있을 경우 ( abstract 또는 native 가 아닐 경우)
Method의 byteCode
Method의 Stack Frame의 Operand Stack 및 Local variable section의 크기
Exception Table

(e) Class Variable : static 키워드로 선언된 변수

모든 인스턴스에 공유 되며 인스턴스가 없어도 직접 접근이 가능하다. 이 변수는 인스턴스의 것이 아니라 클래스에 속하게 된다.
클래스를 사용 하기 이전에 이 변수들은 미리 메모리를 할당 받아 있는 상태가 된다.
final class 변수는 상수로 치환 되어 Runtime Constant Pool에 값을 복사한다.

5) Heap

객체를 저장하는 가상 메모리 공간 (Method Area 는 클래스를 위한 공간)
new 연산자로 생성된 객체와 배열을 저장한다. 이때, Class Area에 올라온 클래스들만 객체로 생성할 수 있다.
힙 영역에 생성된 객체와 배열은 스택 영역의 변수나 다른 객체의 필드에서 참조한다. 참조하는 변수나 필드가 없다면 의미 없는 객체가 되어 GC의 대상이 된다.

(a) Young Generation

Eden : 객체들이 최초로 생성되는 공간
Survivor 0 / 1 : Eden 에 의해 참조되는 객체들이 저장되는 공간

(b) Old Generation

접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체들이 저장되는 공간

생성된 객체들의 주소값이 저장된 공간
Class Loader 에 의해 로드되는 Class, Method 등에 대한 메타 데이터가 저장되는 영역. (해당 정보는 JVM에 의해 사용된다)
Reflection을 사용해 동적으로 클래스가 로딩 되는 경우에 사용
→ 내부적으로 Reflection 을 자주 사용하는 Spring Framework를 사용한다면 이 영역에 대한 고려가 필요

❗❕ Java 8부터는 Permanent 영역대신 Metaspcae 로 호출되는 네이티브 영역에 저장됩니다.

3. Execution Engine

Class Loader가 JVM에 로드한 클래스 파일(Java 바이트 코드)를 실행한다. Execution Engine을 통해서 Machine이 읽을 수 있는 형태로 ByteCode를 변환한다.

Execution Engine 구성 요소

1) Interpreter

Execution Engine은 Java 바이트 코드를 한 줄 씩(명령어 단위로) 해석해서 실행한다.
한 줄 씩 읽어서 속도가 느리다는 단점이 있다.

2) JIT(Just - In - Time) 컴파일러 / 동적 번역(Dynamic Translation)

인터프리터 방식의 단점을 보완하기 위해 도입
Java 바이트코드를 실행(이하 인터프리팅)하는 시점에 JIT 컴파일러는 Java 바이트코드를 컴파일하면서 변환된 기계어를 캐시에 저장한다. 한 번 컴파일된 이후에는 캐시에 보관된 기계어를 사용하기 때문에 바뀐 부분만 컴파일하여 빠르게 수행할 수 있다.
Java 바이트코드를 기계어 변환하는 데에도 비용이 들기 때문에 JVM은 모든 코드를 JIT 컴파일러 방식으로 실행하지 않는다. 인터프리터 방식을 사용하다 일정 기준이 넘어가면 JIT 컴파일 방식으로 명령어를 실행한다.

3) Garbage Collector

RuntimeDataArea의 Heap 영역의 더 이상 참조되지 않는 객체를 해제하는 방식으로 메모리를 관리한다

참고자료

https://asfirstalways.tistory.com/158
https://www.holaxprogramming.com/2013/07/16/java-jvm-runtime-data-area/
Execution Engine : https://www.slipp.net/wiki/pages/viewpage.action?pageId=8880270
JVM의 실행 엔진 : https://www.javacodegeeks.com/2018/04/jvm-architecture-execution-engine-in-jvm.html
JIT 컴파일 : https://ko.wikipedia.org/wiki/JIT_%EC%BB%B4%ED%8C%8C%EC%9D%BC
JIT 컴파일러 : https://medium.com/@ahn428/java-jit-%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC-c7d068e29f45

[백준 9935번] 문자열폭발

연두연두부 — Mon, 5 Jul 2021 05:02:00 +0900

https://www.acmicpc.net/problem/9935

9935번: 문자열 폭발

첫째 줄에 문자열이 주어진다. 문자열의 길이는 1보다 크거나 같고, 1,000,000보다 작거나 같다. 둘째 줄에 폭발 문자열이 주어진다. 길이는 1보다 크거나 같고, 36보다 작거나 같다. 두 문자열은 모

www.acmicpc.net

문제 접근 및 해결 방법

처음에 replace와 재귀를 이용해서 Java로 풀었는데 메모리 초과가 났다. 싸피분들과 리뷰를 하며 스택을 이용해야한다는 걸 알게 되었다. 백준 9935번 문자열 폭발과 유사해서 다시 풀어보았다. 마침 Go를 배우고 있어서 Go로 다시 풀어보았다. 풀면서 Go에 stack이 없어서 slice 개념을 이용해서 구현했다. 또한 풀면서 Go가 지원하는 자료형에 char이 없어서 slice한 string이 byte형이 된다는 것을 알게되었다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
package main
 
import (
    "bufio"
    "fmt"
    "os"
)
 
func main() {
    r := bufio.NewReader(os.Stdin)
    w := bufio.NewWriter(os.Stdout)
    defer w.Flush()
 
      var str, target string
      var stack []byte
  
      fmt.Fscan(r, &str, &target)
  
      var lenOfStr int = len(str)
      var lenOfTarget int= len(target)
  
      for i := 0; i < lenOfStr; i++ {
        stack = append(stack, str[i])
 
        var lenOfStack int = len(stack)
        if stack[lenOfStack-1] == target[lenOfTarget-1] { // 만약 넣은 문자가 폭발문자열의 끝문자와 같을 경우
            if lenOfStack >= lenOfTarget && string(stack[lenOfStack-lenOfTarget:lenOfStack]) == target {
                stack = stack[:lenOfStack-lenOfTarget] // 폭발문자열이 있으면 폭발문자열 빼주기
            }
        }
    }
  
    if len(stack) == 0{
        fmt.Fprintln(w, "FRULA")
    }else{ 
        fmt.Fprintln(w, string(stack))
    }
}
Colored by Color Scripter
cs

Windows 에서 Go 환경 세팅

연두연두부 — Mon, 5 Jul 2021 03:20:47 +0900

https://www.inflearn.com/course/go%EC%96%B8%EC%96%B4/

쉽고 빠르게 끝내는 GO언어 프로그래밍 핵심 기초 입문 과정 - 인프런 | 강의

구글 서버, Docker, 우버등이 Go언어를 활용한 대표 프로젝트이고 최근에는 데이터 분석 및 블록체인에서도 많이 활용하고 있어 Go언어의 인기는 계속해서 수직 상승할 것으로 예상됩니다., 쉽고

www.inflearn.com

(다음 강의를 듣고 학습하였습니다.)

0. Go, Atom, Git 다운로드

Go 설치할 때 Go 경로는 기본적으로 주어지는 C:\Program Files\Go\ 로 했습니다.

1. Go 개발환경(공간) 생성

C:\workspace\go-study\ 로 Go 개발환경(공간)을 만들었습니다. 그리고 bin, pkg, src 폴더를 만들어 줍니다.

2. Go 개발환경(공간) 설정

Go 개발환경을 생성한 다음에 시스템에 Go 개발환경관련해서 설정해주어야합니다. 시스템 환경 변수 편집에 들어가서 GOPATH, GOBIN를 설정해줍니다. You don’t need to set GOROOT, really 를 참고하면, 이미 go에 $GOROOT가 포함되어 있다고 하여 설정해주지 않았습니다.

3. Go 시스템환경변수 확인

go env

시스템 환경 변수 편집 후, cmd를 켜서 다음 명령어를 입력하여 GOBIN, GOPATH를 확인합니다.

만약 GOPATH와 GOBIN이 설정한 경로와 다르다면, 다시 시스템환경변수 편집기를 켜서 사용자 변수에 해당 변수가 있는지 확인합니다. 만약 있으면 지웁니다.

Windows 에서 godoc : 'godoc'은 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다.

연두연두부 — Mon, 5 Jul 2021 02:55:04 +0900

https://yeondube.tistory.com/entry/Windows-%EC%97%90%EC%84%9C-Go-%ED%99%98%EA%B2%BD-%EC%84%B8%ED%8C%85

Windows 에서 Go 환경 세팅

https://www.inflearn.com/course/go%EC%96%B8%EC%96%B4/ 쉽고 빠르게 끝내는 GO언어 프로그래밍 핵심 기초 입문 과정 - 인프런 | 강의 구글 서버, Docker, 우버등이 Go언어를 활용한 대표 프로젝트이고 최근에는..

yeondube.tistory.com

GOPATH, GOBIN 환경변수를 모두 설정해주었습니다. Go 패키지들을 보기위해 cmd에서 godoc 명령어를 입력해보았습니다. 'godoc'은 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다. 라고 나와 godoc을 다운로드 받았습니다.

1. godoc 다운로드

cmd 에서 다음 명령어를 입력합니다.

go get golang.org/x/tools/cmd/godoc

하지만 여전히 'godoc'은 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다. 라고 나왔습니다. 그래서 시스템환경변수로 지정한 GOPATH을 직접 명시하여 cmd에서 다음 명령어 입력했습니다.

%GOPATH%/bin/godoc -http=localhost:8080

다음 명령어가 실행되는 것을 확인하고 시스템환경변수 Path에 제가 생성한 workspace의 bin 경로를 추가해주었습니다. GOPATH를 추가했을 때처럼 시스템환경변수 편집기에 직접 접근하였습니다.

다음은 Path를 더블 클릭했을 때 나오는 환경 변수 편집 공간입니다. 이전에 생성한 go 개발환경 아래에 있는 bin 폴더 경로를 추가해줍니다.

path를 추가한후에 cmd를 재실행하여 다음 명령어를 실행하였습니다.

godoc -http=localhost:8080

chrome 새창에 localhost:8080으로 들어가면 godoc을 볼 수 있었습니다. 명령어 godoc만 입력하시면 기본포트 6060으로 godoc이 실행되어 localhost:6060으로 접속하면 됩니다.

참고자료

https://pkg.go.dev/golang.org/x/tools/cmd/godoc

godoc · pkg.go.dev

Godoc extracts and generates documentation for Go programs. It runs as a web server and presents the documentation as a web page. godoc -http=:6060 Usage: godoc [flag] The flags are: -v verbose mode -timestamps=true show timestamps with directory listings

pkg.go.dev

컴퓨터가 뭘까

Kotlin Spring boot에서 AWS Secret Manager 사용하기

AWS에서 세팅하기

Spring boot에 적용하기

로직 직접 구현해서 Secret 정보 사용하기

kotlin 프로젝트에서 openapi code generator 사용하기

서론

환경

적용

1) Swagger hub에 명세한 API 문서에 따라 API 개발

2) 타컴포넌트 API 호출

참조

[querydsl] mysql filesort관련 group by 성능 최적화

MySQL 정렬 방식

Filesort 발생 원인

Filesort 발생 시 문제점

Filesort 방지 방법

QueryDsl에서 order_by_null 옵션 활용

마무리

참고자료

[kotlin] 동시성 제어하기

volatile

synchronized

1) synchronized method

2) synchronized block

atomic 변수

thread-safe (concurrent) collections

semaphore

mutex

withlock() with ReentrantLock

actors

결론

Java 기본 개념

Java 자료형

Boxing과 Unboxing

싱글톤

싱글톤 패턴 작성 방식

자바와 스프링의 싱글톤 차이점

final

상속

상속 키워드

추상클래스와 인터페이스

추상클래스

인터페이스

접근제어자(접근범위 넓은 순으로)

다형성+상속

동적바인딩

instanceof 연산자

컬렉션 프레임워크

Collection 인터페이스

컬렉션에서 오토박싱/언박싱

Comparable Comparator 인터페이스

스트림 종류

연산

1. BigDecimal

2. 오버플로우 방지

면접질문

Q1 클래스에서 사용하는 변수의 3가지 종류에 대해 설명해주세요.

Q2 Wrapper Class에 대해 설명해주세요.

Q3 StringBuilder와 StringBuffer의 차이점을 설명해주세요.

문제 1

문제 2

[대규모 서비스를 지탱하는 기술] 1장 정리

무엇을 '대규모'라고 하는가

그렇다면 서버 확장하는 방법은 무엇이 있을까

What is Scaling

Scale up

Scale out

Reference

JVM

JVM이 왜 등장했을까

주요 용어

환경이 다를 경우 Java와 C/C++ 대응방식

JVM은 무엇일까

Java 소스코드가 실행되기까지

JVM 구조

1. Class Loader Subsystem

클래스 로더(Class Loader)

2. Runtime Data Area ⭐

2-1 Thread가 공유하지 않는 영역

`withlock()` with ReentrantLock