하하호홓

패스트캠퍼스 The RED : 성능의 神: 궁극의 성능 튜닝과 트러블슈팅 by 이상민 완강 후기

설 연수 — Sun, 15 Dec 2024 11:24:45 +0900

2024년, 패스트캠퍼스의 "궁극의 성능 튜닝과 트러블슈팅" 강의를 수강하면서 백엔드 엔지니어로서 한 단계 도약할 수 있었다.
실무에서 맞닥뜨리는 다양한 성능 문제를 해결하기 위한 체계적인 접근법을 배우며 성장을 이루었다고 생각한다.
어떤 부분에서 도움을 얻었는지 후기와 배운점, 앞으로의 목표를 적어보고자 한다.

강의와 함께 제공되는 교육과정 소개서

성능 지표

완강 후기

이 강의는 성능 저하의 주요 병목 지점을 이해하고, 이를 해결하기 위한 다양한 툴과 방법론을 다룬다. 특히 JVM, GC, Scouter, Whatap 등 실무에서 자주 사용하는 도구들을 활용해 문제를 진단하고 최적화하는 방법을 심도 있게 배울 수 있다. 강사님이 제시한 실제 사례와 문제 해결 과정은 이론에만 그치지 않고 현업에 바로 적용할 수 있도록 구성되어 있는 점이 좋았다.

강의 중 가장 인상 깊었던 부분은 성능 병목을 분석할 때 단순히 CPU나 메모리 사용량만 보는 것이 아니라, 서비스 특성에 맞는 지표를 정의하고 이를 바탕으로 문제를 해결하는 접근법이다. 이 과정을 통해 업무에서 어떤 문제를 우선적으로 해결해야 할지 우선순위를 명확히 설정할 수 있게 되었다.

수강 후 달라진 점

트러블슈팅: JVM 및 GC 로그를 분석하는 방법을 알게 되었고, 문제 원인을 파악할 수 있게 되었다.
시스템 성능 최적화: 병목 구간을 찾아 개선할 수 있게 되었다.
성능 테스트: JMH와 Gatling을 활용해 사전 성능 테스트를 진행할 수 있게 되어, 배포 후 문제 발생 가능성을 줄일 수 있게 되었다.

성능확인, 성능 테스트

앞으로의 목표

강의에서 배운 내용을 실무에 적용 및 성능 개선 문화를 확산시키고자 한다. 그리고 강의에서 다룬 도구들을 활용하여 대규모 트래픽 처리와 관련된 프로젝트에서 성과를 내는 것이 목표이다.

본 게시물은 패스트캠퍼스 수강 후기 이벤트 참여를 위해 작성되었습니다.

패스트캠퍼스 "백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리" 완강 후기

설 연수 — Wed, 13 Dec 2023 21:02:28 +0900

대용량 트래픽을 다루려면, 대용량 트래픽을 다루는 기술을 알아야 한다.

패스트캠퍼스에서 "백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리 강의"를 완강했다.

이 강의는 대규모 트래픽를 다루는 회사에서 주로 사용하는 기술인 MySQL, Kafka, MongoDB, Redis를 다루며,
이커머스 프로젝트를 통해 현업의 이커머스가 어떻게 구성되어있는지, 어떻게 일하는지 배울 수 있었다.

현업에서 실제 대규모 트래픽을 다루는 강사님들로부터 이론부터 실습, 그리고 노하우까지 학습해볼 수 있었다.

다른 플랫폼, 특히 패캠에서도 여러 강의를 수강해봤지만 기술 4개를 묶어서 이 가격에 판매하는건 가성비가 미쳤다고 생각한다.
(나는 시간이 돈이라고 생각하기 때문에, 삽질을 안하고 노하우를 습득했으니 돈을 벌었다고 본다..)

이 강의를 수강한 후, 단순 어플리케이션 기능구현에만 집중하는것이 아니라
대규모트래픽이 들어올 수 있다고 가정하고 만약의 상황에 대비하는 마음가짐을 갖게 되었다.

효율적인 데이터베이스 설계(MySQL), 유연함(MongoDB), 서버의 부하를 낮추는 방법(Redis), 트래픽 처리량을 늘리는법(Kafka)에 대한 자신감이 생겼고
단순 기술습득뿐만 아니라, 왜 필요한지 왜 이것이 해결방안인지를 알게되어 다음세대의 기술이 등장해도 쉽게 습득해볼 수 있을 것 같다.

어떤 기술이든 결국 문제가 있었고, 그 문제를 해결하기 위해 등장했기 마련인데, 이 강의를 통해서 문제해결에 대한 자신감을 얻은 느낌..?

주니어건 시니어건 안봤다면 추천해주고 싶은 강의였다.

개인적으로는 개발자라면 최소 한번이상 봐야하는 강의라고 생각한다.

본 게시물은 패스트캠퍼스 수강 후기 이벤트 참여를 위해 작성되었습니다.

ThreadLocal

설 연수 — Sun, 27 Mar 2022 13:52:38 +0900

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B3%A0%EA%B8%89%ED%8E%B8/dashboard

스프링 핵심 원리 - 고급편 - 인프런 | 강의

스프링의 핵심 원리와 고급 기술들을 깊이있게 학습하고, 스프링을 자신있게 사용할 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

스프링프레임워크를 사용하다보면 멤버변수를 선언해서 여러메서드에서 활용하도록 구현하는 개발자들을 종종 볼 수 있다.

스프링빈은 싱글톤으로 생성되기때문에,
멀티쓰레드 환경에서 싱글톤의 멤버변수를 각 쓰레드들이 쓰고 지우고 하다보면 데이터가 엉켜서 버그를 유발하는 원인이 될 수 있다.

ThreadLocal은 해당 쓰레드만이 접근할 수 있는 저장소를 말한다.
각 쓰레드마다 별도의 내부 저장소를 갖게되며, 같은 인스턴스의 ThreadLocal 멤버변수를 다른 쓰레드가 접근해도 문제가 발생하지 않는다.

사용방법

ThreadLocal<String> nameStore = new ThreadLocal<>();

주의사항

해당 쓰레드가 ThreadLocal을 사용하고 난 뒤, 저장된값을 제거해주어야 한다.
필히 remove를 호출하자.

MySQL-jOOQ BigDecimal 캐스팅 다루기

설 연수 — Sat, 26 Mar 2022 16:50:37 +0900

오류

오류 사례

적정금액일때는 잘 계산되던 프로그램이 숫자범위가 커지자 합계금액이 틀어지는 오류 발생.
(숫자 한계범위 초과)

오류 원인파악

형변환을 위해 BigDecimal로 타입캐스팅을 하고 있었음

ENTITY.COL1.subtract(ENTITY.COL2))
  .cast(BigDecimal.class).as("잔액")

.cast(BigDecimal.class)으로 발생하는 문제: 숫자 범위초과

.cast(BigDecimal.class)코드 SQL문법으로 다음과 같이 렌더링된다.

cast(? as decimal)

decimal의 기본값은 decimal(10)과 같다

cast(? as decimal(10))

즉, 10자리 정수까지만 처리가 가능하다는 의미로 이해하면 된다.

100억 미만까지 표현가능

MySQL피셜

문제점:

10자리를 초과하는 정수의 경우, 9999999999가 리턴된다.

	/**
	 |------------------|------------------|-------------------|-------------------|--------------------------|
	 |?                 |?                 |cast(? as decimal) |cast(? as decimal) |cast(? as decimal(30, 5)) |
	 |------------------|------------------|-------------------|-------------------|--------------------------|
	 |10000000000.11111 |10000000000.11111 |9999999999         |9999999999         |10000000000.11111         |
	 |------------------|------------------|-------------------|-------------------|--------------------------|
	 * */
	@Test
	void decimalCast() {
		final BigDecimal bigDecimalValue = BigDecimal.valueOf(1_00000_00000.11111); // 11자리 정수 + 5자리 소수점
		final double doubleValue = 1_00000_00000.11111;// 11자리 정수 + 5자리 소수점
		final var fetchOne = dslContext.select(
				DSL.value(bigDecimalValue),
				DSL.value(doubleValue).coerce(BigDecimal.class),
				DSL.value(bigDecimalValue).cast(BigInteger.class),
				DSL.value(bigDecimalValue).cast(BigDecimal.class),
				DSL.value(bigDecimalValue).cast(SQLDataType.DECIMAL.precision(30, 5))
		).fetchOne();

		// 형변환 X
		assertThat(fetchOne.component1())
				.as("캐스팅 안한 결과: 값이 그대로 출력된다.")
				.isEqualByComparingTo(bigDecimalValue);

		// decimal의 default: decimal(10)
		assertThat(fetchOne.component3())
				.as("BigInteger => cast(? as decimal): 소수점이 버려지고, 10자리 정수로 값이 변경된다.")
				.isEqualByComparingTo(BigInteger.valueOf((long) 9999999999.0));
		assertThat(fetchOne.component4())
				.as("BigDecimal => cast(? as decimal): 소수점이 버려지고, 10자리 정수로 값이 변경된다.")
				.isEqualByComparingTo(BigDecimal.valueOf((long) 9999999999.0));
	}

해결하기

DataType의 정수,소수점 범위 지정해서 캐스팅하기

BigDecimal의 경우, 캐스팅할때 DataType으로 범위를 설정해야 오류를 방지할 수 있다.

// <Z> Field<Z> cast(DataType<Z> type); DSL.value(bigDecimalValue).cast(SQLDataType.DECIMAL.precision(30, 5))

	/**
	 |------------------|------------------|-------------------|-------------------|--------------------------|
	 |?                 |?                 |cast(? as decimal) |cast(? as decimal) |cast(? as decimal(30, 5)) |
	 |------------------|------------------|-------------------|-------------------|--------------------------|
	 |10000000000.11111 |10000000000.11111 |9999999999         |9999999999         |10000000000.11111         |
	 |------------------|------------------|-------------------|-------------------|--------------------------|
	 * */
	@Test
	void decimalCast() {
		final BigDecimal bigDecimalValue = BigDecimal.valueOf(1_00000_00000.11111); // 11자리 정수 + 5자리 소수점
		final double doubleValue = 1_00000_00000.11111;// 11자리 정수 + 5자리 소수점
		final var fetchOne = dslContext.select(
				DSL.value(bigDecimalValue),
				DSL.value(doubleValue).coerce(BigDecimal.class),
				DSL.value(bigDecimalValue).cast(BigInteger.class),
				DSL.value(bigDecimalValue).cast(BigDecimal.class),
				DSL.value(bigDecimalValue).cast(SQLDataType.DECIMAL.precision(30, 5))
		).fetchOne();

		// 형변환 X
		assertThat(fetchOne.component1())
				.as("캐스팅 안한 결과: 값이 그대로 출력된다.")
				.isEqualByComparingTo(bigDecimalValue);
				
		// cast할때, 정석
		assertThat(fetchOne.component5())
				.as("DECIMAL.precision(30, 5) => cast(? as decimal(30, 5)): 자리수를 초과하지 않았기때문에 그대로 출력된다.")
				.isEqualByComparingTo(bigDecimalValue);
	}

개인의견: 캐스팅하는것이 성능저하에 영향이 조금이나마 영향이 있을것 같아 꺼려졌다.

캐스팅처리를 안하면 되는거아냐?: coerce로 SQL(cast) 렌더링 없이 제네릭 형변환하기

jOOQ에서 JAVA컴파일단 형변환만 수행하는 메서드가 존재했다: coerce(Class<Z> type)
제네릭 타입은 변환하지만, SQL 렌더링(cast)은 하지않음

// Field<Z> coerce(Class<Z> type);
@Test
void decimalCast() {
	final BigDecimal bigDecimalValue = BigDecimal.valueOf(1_00000_00000.11111); // 11자리 정수 + 5자리 소수점
	final double doubleValue = 1_00000_00000.11111;// 11자리 정수 + 5자리 소수점
	final var fetchOne = dslContext.select(
			DSL.value(bigDecimalValue),
			DSL.value(doubleValue).coerce(BigDecimal.class),
			DSL.value(bigDecimalValue).cast(BigInteger.class),
			DSL.value(bigDecimalValue).cast(BigDecimal.class),
			DSL.value(bigDecimalValue).cast(SQLDataType.DECIMAL.precision(30, 5))
	).fetchOne();

	// coerce: 타입 강제 형변환(SQL 렌더링 X)
	assertThat(fetchOne.component2())
			.as("캐스팅 안함")
			.isEqualByComparingTo(bigDecimalValue);
}

https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/datatype-coercions/

그러니까.. 형변환을 안하면 되는것 아니냐고.. 왜 해야되는데?: jOOQ클래스 Long필드를 BigDecimal로 바꾸기

왜 형변환이 필요했을까?
- 형변환이 필요없었던 jOOQ Class 필드
- BigDecimal을 BigDecimal과 연산할때는 형변환이 필요하지 않았다.

public class ENTITY extends TableImpl<ENTITY_RECORD> {
  // ...
  public final TableField<ENTITY_RECORD, BigDecimal> SUM_AMT = createField(DSL.name("SUM_AMT"), SQLDataType.DECIMAL(15, 3).defaultValue(DSL.inline("0.000", SQLDataType.DECIMAL)), this, "");
}

형변환이 필요했던 jOOQ Class 필드

필드의 제네릭 타입이 BigDecimal이 아님.
Long을 BigDecimal과 연산하려니 형변환이 필요했다.

public class ENTITY extends TableImpl<ENTITY_RECORD> {
    // ...
    public final TableField<ENTITY_RECORD, Long> DR_AMT = createField(DSL.name("DR_AMT"), SQLDataType.BIGINT.nullable(false).defaultValue(DSL.inline("0", SQLDataType.BIGINT)), this, "");
}

결론: decimal(numeric)의 소수점 유무가 jOOQ 필드타입에 영향을 미친것 같다.
(왜 BigInteger가 아니고 Long일까..?)

다른컬럼들처럼 AMT, QTY 컬럼은 그냥 BigDecimal로 다룰래
jOOQ Forced types으로 타입을 지정한다.
- jOOQ Forced types Manual: https://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced/codegen-config-database/codegen-database-forced-types/
- gradle.build

jooq {
    // ...
    project(sourceSets.main) {
        // ...
        generator {
            // ...
            database {
                // ...
                forcedTypes {
                    forcedType {
                        // Specify any data type that is supported in your database, or if unsupported, 
                        // a type from org.jooq.impl.SQLDataType
                        name = 'DECIMAL'
                        
                        // A Java regex matching data types to be forced to have this type.
                        includeTypes = '.*' 
                        
                        // A Java regex matching fully-qualified columns, attributes, parameters. Use the pipe to separate several expressions.
                        includeExpression = '.*AMT|.*PRICE|.*QTY'
                        
                        // Force a type on ALL or specific object types, including 
                        // ATTRIBUTE, COLUMN, ELEMENT, PARAMETER, SEQUENCE
                        objectType = 'COLUMN'
                    }
                }
            }
            // ...
        }
    }
    system(sourceSets.main) {
        // ...
        generator {
            // ...
            database {
                // ...
                forcedTypes {
                    forcedType {
                        name = 'DECIMAL'
                        includeTypes = '.*'
                        includeExpression = '.*AMT|.*PRICE|.*QTY'
                        objectType = 'COLUMN'
                    }
                }
            }
            // ...
        }
    }
}

소수점 없는 decimal타입을 BigDecimal로 다루는게 좋을까?
- 일단, 기존에는 Long이었다.
- BigDecimal보다 BigInteger가 더 적합한것 같다는 생각도 든다.
  (일단 생각만 하기로함…)
  - BigInteger로 다룰 경우,
    - 기존 BigDecimal처리를 BigInteger으로 변경해야 함.
      1. BigDecimal.ZERO → BigInteger.ZERO
      2. BigInteger와 BigDecimal 연산 시(+-*/), 타입으로인한 컴파일오류가 발생
        
        coerce활용 필요.
    - 응답GQL, DTO까지 변환해야 완전한 BigInteger적용.

전체 테스트코드

/**
 |------------------|------------------|-------------------|-------------------|--------------------------|
 |?                 |?                 |cast(? as decimal) |cast(? as decimal) |cast(? as decimal(30, 5)) |
 |------------------|------------------|-------------------|-------------------|--------------------------|
 |10000000000.11111 |10000000000.11111 |9999999999         |9999999999         |10000000000.11111         |
 |------------------|------------------|-------------------|-------------------|--------------------------|
 * */
@Test
void decimalCast() {
	final BigDecimal bigDecimalValue = BigDecimal.valueOf(1_00000_00000.11111); // 11자리 정수 + 5자리 소수점
	final double doubleValue = 1_00000_00000.11111;// 11자리 정수 + 5자리 소수점
	final var fetchOne = dslContext.select(
			DSL.value(bigDecimalValue),
			DSL.value(doubleValue).coerce(BigDecimal.class),
			DSL.value(bigDecimalValue).cast(BigInteger.class),
			DSL.value(bigDecimalValue).cast(BigDecimal.class),
			DSL.value(bigDecimalValue).cast(SQLDataType.DECIMAL.precision(30, 5))
	).fetchOne();

	// 형변환 X
	assertThat(fetchOne.component1())
			.as("캐스팅 안한 결과: 값이 그대로 출력된다.")
			.isEqualByComparingTo(bigDecimalValue);

	// coerce: 타입 강제 형변환(SQL 렌더링 X) https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/datatype-coercions/
	assertThat(fetchOne.component2())
			.as("캐스팅 안함")
			.isEqualByComparingTo(bigDecimalValue);

	// decimal의 default: decimal(10)
	// https://dev.mysql.com/doc/refman/5.7/en/precision-math-decimal-characteristics.html
	assertThat(fetchOne.component3())
			.as("BigInteger => cast(? as decimal): 소수점이 버려지고, 10자리 정수로 값이 변경된다.")
			.isEqualByComparingTo(BigInteger.valueOf((long) 9999999999.0));
	assertThat(fetchOne.component4())
			.as("BigDecimal => cast(? as decimal): 소수점이 버려지고, 10자리 정수로 값이 변경된다.")
			.isEqualByComparingTo(BigDecimal.valueOf((long) 9999999999.0));

	// cast할때, 정석
	assertThat(fetchOne.component5())
			.as("DECIMAL.precision(30, 5) => cast(? as decimal(30, 5)): 자리수를 초과하지 않았기때문에 그대로 출력된다.")
			.isEqualByComparingTo(bigDecimalValue);
}

https로 npm start

설 연수 — Thu, 1 Oct 2020 15:24:29 +0900

MacOS

HTTPS=true npm start

Window

set HTTPS=true && npm start

[Git] git branch 명령어 쳤을때 별도의 viewer가 뜨는문제 해결

설 연수 — Thu, 25 Jun 2020 16:10:50 +0900

git config --global pager.branch false

https://stackoverflow.com/questions/48341920/git-branch-command-behaves-like-less/48342309

인텔리J Entity Class에 @Table(name), @Column(name) 빨간줄 끄는방법

설 연수 — Fri, 12 Jun 2020 16:45:12 +0900

Preferences > Editor > Inspections > JPA의 Unresolved database references in annotations 체크 해제 후 OK

[Gradle] SpringBoot 실행이안될때

설 연수 — Thu, 21 May 2020 21:22:05 +0900

Unnecessarily replacing a task that does not exist is not supported.
Use create() or register() directly instead.  
You attempted to replace a task named 'Application.main()', but there is no existing task with that name.

[JWT] 토큰(Token) 기반 인증에 대한 소개

설 연수 — Wed, 20 May 2020 12:01:54 +0900

https://velopert.com/2350

[JWT] 토큰(Token) 기반 인증에 대한 소개 | VELOPERT.LOG

소개 토큰(Token) 기반 인증은 모던 웹서비스에서 정말 많이 사용되고 있습니다. 여러분이 API 를 사용하는 웹서비스를 개발한다면, 토큰을 사용하여 유저들의 인증작업을 처리하는것이 가장 좋은

velopert.com

AWS EC2에 카프카 클러스터 구성시 에러

설 연수 — Wed, 13 May 2020 19:04:36 +0900

요약 : 돈을 아끼기위해 프리티어스펙의 EC2로 인스턴스를 생성했을경우 메모리가 1G 할당된다.
문제는 카프카 브로커 설치 이후 주키퍼를 실행할때 512MB를 먹고 시작하며.. 이후 카프카가 1G를 먹고 실행하려던 중 에러가 발생한다.
금액을 지불하고 인스턴스 스펙을 올리던가 JVM메모리를 조정하여야 한다.

에러 로그

$ kafka-topics --zookeeper ...생략... --create --topic first-test --partitions 3 --replication-factor 3

OpenJDK 64-Bit Server VM warning: If the number of processors is expected to increase from one, then you should configure the number of parallel GC threads appropriately using -XX:ParallelGCThreads=N
Error while executing topic command : Replication factor: 3 larger than available brokers: 0.
[2020-05-13 09:24:03,192] ERROR org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 3 larger than available brokers: 0.
 (kafka.admin.TopicCommand$)

상태확인

Active: failed

$ sudo systemctl status confluent-kafka

● confluent-kafka.service - Apache Kafka - broker
Loaded: loaded (/usr/lib/systemd/system/confluent-kafka.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2020-05-13 09:26:45 UTC; 5s ago
Docs: http://docs.confluent.io/
Process: 1772 ExecStart=/usr/bin/kafka-server-start /etc/kafka/server.properties (code=exited, status=1/FAILURE)
Main PID: 1772 (code=exited, status=1/FAILURE)

May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal kafka-server-start[1772]: OpenJDK 64-Bit Server VM warning: If the number of processors is ex...ads=N
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal kafka-server-start[1772]: OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000...o=12)
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal kafka-server-start[1772]: #
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal kafka-server-start[1772]: # There is insufficient memory for the Java Runtime Environment to ...inue.
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal kafka-server-start[1772]: # Native memory allocation (mmap) failed to map 1073741824 bytes fo...mory.
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal kafka-server-start[1772]: # An error report file with more information is saved as:
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal kafka-server-start[1772]: # /tmp/hs_err_pid1772.log
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal systemd[1]: confluent-kafka.service: main process exited, code=exited, status=1/FAILURE
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal systemd[1]: Unit confluent-kafka.service entered failed state.
May 13 09:26:45 ip-172-31-42-242.ap-northeast-2.compute.internal systemd[1]: confluent-kafka.service failed.

/tmp/hs_err_pid1772.log 파일을 확인해보니 메모리 할당 오류인 것을 확인.



### 메모리 수정

카프카 메모리 수정.

$ sudo vi /usr/bin/kafka-server-start

if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
# export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"
export KAFKA_HEAP_OPTS="-Xmx256M -Xms128M"
fi

주키퍼 메모리 수정

$ sudo vi /usr/bin/zookeeper-server-start

if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
# export KAFKA_HEAP_OPTS="-Xmx512M -Xms512M"
export KAFKA_HEAP_OPTS="-Xmx256M -Xms128M"
fi


### 재시작

재시작

sudo systemctl restart confluent-zookeeper
sudo systemctl restart confluent-kafka

상태확인

sudo systemctl status confluent-zookeeper
sudo systemctl status confluent-kafka
```