그렇다면, 최근 우리의 기억에서 잊혀진 데이터 용량에 대해 다시 한번 고찰해 보고자 한다.

사전적 정의부터 알아보자!

비트(Bit, Binary digit) 는 하나의 비트는 0 이나 1 의 값을 가질수 있고, 각각은 참, 거짓 혹은 서로 배타적인 상태를 나타낸다.

바이트(Byte) 는 일정량의 비트 모음을 정의할때 사용하며, 컴퓨터의 기억장치의 크기를 나타내는 단위로 자주 쓰인다. 실질적인 의미는 ASCII 문자 하나를 나타내는 단위로 최근에는 사실상 1바이트를 8비트로 간주하는 경우가 흔하다.

• 옥텟(octet): 한데 묶여 쓰이는 2진 이진부호모음. 바이트가 8비트를 가리킬 때 서로 같은 뜻을 갖는다. 전기통신 분야에서는 바이트란 용어 대신 옥텟이란 표현을 사용한다. 팔중수라고도 부른다.
• 니블(nibble) = 1바이트의 절반으로 보통 4비트를 가리킨다. 이때 바이트 하나는 상위 니블(상위 4비트)과 하위 니블(하위 4비트)로 나눌 수 있다.
• 워드(word): 전자통신 기기에 따라 2바이트 또는 4바이트를 묶어서 부르는 단위이다.
• 킬로바이트(kbyte): 1024 바이트는 1 킬로바이트이다.

해묵은 이슈이긴 한데, 시간이 지날수록 컴퓨터 저변 확대와 데이터 용량 단위 증가로 인한 이슈가 발생하게 되었다.

앞서 정의된 바와 같이 용량 표현의 최소 단위인 바이트(byte)는 비트(bit)를 기반으로 한 이진법을 사용하고 있기 때문에 1KB 는 1,024 Byte 이다.
하지만, 우리가 표준으로 사용하는 국제단위계(SI)는 모두 10진법을 기초로 하고, 이를 기반으로 제조사는 표기를 하기 시작하며 문제가 발생하기 시작했다.

1,024 Byte 나 1,000 Byte 나 큰 차이가 없어, 같은 크기로 받아들여졌지만, 용량이 커질 경우 그 차이는 매우 커지게 된다.

이러한 문제를 해결하기 위하여 1998년 IEC(International Electrotechnical Commission)에서 아래와 같은 새로운 표기법을 만들었다.

이제 KB 는 1,000 Byte 이고 새롭게 추가된 표기법인 KiB 는 1,024 Byte 이다.

지금 이 이슈를 다시 고찰할 필요성을 느낀 이유는 AWS 단위 표기의 구분을 명확히 하고 있기 때문이다.
아래와 같이 표기 단위에 따라 다르게 구분하여 사용해야 한다.

• 참조링크
  https://ko.wikipedia.org/wiki/비트_(단위)
  https://ko.wikipedia.org/wiki/바이트
  https://ko.wikipedia.org/wiki/SI_접두어
  https://ko.wikipedia.org/wiki/국제단위계

Bit(Binary digit) Byte 의 고찰 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

저희 팀에서는 TypeORM을 활용하여 쿼리 조회를 수행하고 있습니다. 이 글에서는 특히, TypeORM의 QueryBuilder를 활용하여 쿼리를 더 재사용 가능하고 테스트 작성이 용이한 형태로 리팩토링한 내용을 소개하려 합니다.

왜 QueryBuilder의 재사용성을 높여야 하는가?

ORM을 통한 데이터 조회는 대체로 편리하고 가독성이 높은 코드를 작성할 수 있어 개발자들 사이에서 선호되는 방식입니다. 객체를 통한 조회는 테스트 코드를 작성하고 검증하기가 비교적 수월하며, 쿼리 조건을 명시적으로 나열하여 가독성을 높일 수 있어 코드로서의 명료성을 지킬 수 있습니다.

그러나 ORM이 제공하지 않는 특별한 기능이나 일부 동작을 원할 때, QueryBuilder를 통한 데이터 조회를 고려해야 하는 상황이 발생합니다. 이때 일부 쿼리문이 코드로 들어오면서 QueryBuilder를 사용하는 코드는 가독성을 낮추고, 테스트 작성이 어려워지며 코드의 재사용성이 떨어질 수 있습니다.

개선 사례: 매물 조회를 위한 QueryBuilder 활용

직방에서는 사용자들이 전국 각지에 등록된 다양한 매물을 지도와 필터를 통해 쉽게 찾을 수 있는 매물 찾기 기능을 제공하고 있습니다. 사용자들은 매물 검색 시 다양한 정보와 조건을 입력할 수 있어, 이에 대응하는 복잡한 코드 로직이 매물 정보 조회 부분에서 수행되고 있습니다.

이에 기존 코드의 복잡한 부분을 알고있기에 이번에 진행한 지킴중개를 위한 별도의 페이지에서는 조금 더 유지보수가 용이한 형태로 진행한 QueryBuilder 사용 사례를 소개할까합니다.

QueryBuilder 조건 적용을 위한 모델과 클래스 작성

매물 조회를 위한 매물 조회 옵션 클래스를 정의해줍니다.

필터 기능의 경우 매번 요구되는 옵션이 아니기에 모두 optional 처리를 해줍니다.

export class ItemFindOptions {
 public floorTypes?: Array<'지상' | '반지하' | '옥탑'>
 public depositMax?: number
 public depositMin?: number
 public type?: '전세' | '월세' | '매매'
 public rentMin?: number
 public rentMax?: number
 public bjdCodes?: string[]
}

필터 옵션에 입력된 값을 이용해서 QueryBuilder에 쿼리를 적용시켜주는 ItemFindQueryBuilder 클래스를 작성합니다.

export class ItemFindQueryBuilder {
 private alias = 'item'

 constructor(private qb: SelectQueryBuilder<Item>, private options: ItemFindOptions) {
  this.alias = this.qb.alias
 }

 public build(): SelectQueryBuilder<Item> {
   this.qb.andWhere(
    new Brackets((innerQb) => {
     this.setFloorTypes(innerQb, options)
         .setDepositMax(innerQb, options)
         .setDepositMin(innerQb, options)
    }),
   )

  return this.qb
 }

 private setFloorTypes(qb: WhereExpressionBuilder, options: ItemFindOptions) {
  if (options.floorTypes && options.floorTypes.length > 0) {
   qb.andWhere(
    new Brackets((innerQb) => {
     options.floorTypes?.forEach((floorType) => {
      switch (floorType) {
       case '지상':
        innerQb.orWhere(`${this.alias}.floorType = '지상'`)
        break
       case '반지하':
        innerQb.orWhere(`${this.alias}.floorType = '반지하'`)
        break
       case '옥탑':
        innerQb.orWhere(`${this.alias}.floorType = '옥탑'`)
        break
      }
     })
    }),
   )
  }

  return this
 }

 private setDepositMin(qb: WhereExpressionBuilder, options: ItemFindOptions) {
  if (options.depositMin) {
   qb.andWhere(`${this.alias}.deposit >= :depositMin`, { depositMin: options.depositMin })
  }

  return this
 }

 private setDepositMax(qb: WhereExpressionBuilder, options: ItemFindOptions) {
  if (options.depositMax) {
   qb.andWhere(`${this.alias}.deposit <= :depositMax`, { depositMax: options.depositMax })
  }

  return this
 }
}

Repository에 매물 조회 옵션을 이용해서 조회할 수 있는 메소드를 작성합니다.

 public async findByOptions(options: ItemFindOptions, offset = 0, limit = 20) {
  const qb = await this.createQueryBuilder('item')
  const itemFindBuilder = new ItemFindQueryBuilder(qb, options).build()
  itemFindBuilder.skip(offset).take(limit)

  return itemFindBuilder.getMany()
 }

블로그 작성을 위해서 일부 필터만 구현했지만 실제 관리자 페이지에서 사용할 수 있는 필터의 수는 19개입니다. 필터 항목이 총 19개이며, 일부 필터를 여러 화면에서 사용한다면 각각의 조회를 위한 메소드를 구현한다면 findByOOO, findByOOOAndOOO, findByOOOAndOOOAndOOO와 같은 무수히 많은 메소드가 생성될 수 있습니다.

실제 사용 후 느낀 편리함

실제 수많은 코드 리뷰 과정을 통해 팀원들과 유사한 형태의 QueryBuilder 재사용을 위한 코드가 구성되었습니다. 해당 코드를 사용하면서 몇 달간의 서비스 운영, 신규 개발, 유지보수를 진행하며 겪은 장점은 다음과 같습니다.

데이터를 몰라도 필터 사용에 문제가 없다.

필터를 구현하기 위해서는 현재 데이터가 어떻게 구성되어 있고, 어떤 조건들을 사용해야 하는지 등 기존 데이터에 대한 업무 지식이 필요합니다. 하지만 구성한 빌더와 연동하는 ItemFindOptions 객체를 통해서 실제 구현부와 데이터를 알지 못하더라도 현재 어떤 조회가 구현되어 있는지 빠르게 확인할 수 있습니다. 또한, 구현된 필터는 언제라도, 누구라도 바로 사용할 수 있습니다.

이곳저곳 매물 조회를 위한 만능 메소드

테스트 코드 열심히 작성했는데 잘못 조회한 케이스 없으신가요?

가끔 테스트 코드까지 열심히 작성했는데 실제 구동 시 일부 조건에서 의도치 않게 조회되는 케이스를 가끔씩 겪게 됩니다. 특히나 조건이 복잡해지는 경우 AND, OR 조건의 괄호에 의해서 많이 발생합니다. 이미 많은 코드에서 검증되었고 또한 테스트 코드를 통한 빌더에 대한 검증이 이뤄졌기 때문에 많은 코드들에서 걱정 없이 해당 메소드를 통해 손쉽게 매물에 대한 조회를 수행합니다.

ORM 만큼이나 수월한 테스트 코드 작성

ORM과 QueryBuilder를 통한 조회 중 가장 큰 차이점이자, 저는 ORM을 통한 조회를 더 선호하는 이유는 테스트 코드 작성의 난이도가 낮아진다는 점입니다.

ORM은 객체 지향적인 접근 방식으로 데이터를 다루기 때문에 테스트 코드 작성이 자연스럽고 직관적입니다. 객체와 데이터베이스 간의 매핑이 이미 정의되어 있기 때문에 별도의 쿼리 빌딩 로직을 작성하지 않아도 됩니다. 따라서, ORM을 사용하면 쿼리 빌딩과 관련된 테스트 코드를 작성할 필요가 줄어들어 전반적인 테스트 작성이 간편해집니다.

반면에 QueryBuilder는 쿼리를 직접 작성해야 하기 때문에 쿼리 로직의 테스트 코드 작성이 필수적입니다. 특히 복잡한 쿼리에서는 AND, OR 조건 및 괄호 처리 등이 추가로 필요하므로 테스트 코드 작성이 더욱 번거로울 수 있습니다.

다음은 실제 검증하는 테스트 코드 일부입니다.

 test('[depositMin] 최소보증금이 주어지면 최소보증금 조건을 추가한다.', () => {
  const itemFindBuilder = new ItemFindQueryBuilder(mockQb, {
    depositMin: 5000,
  }).build()

  expect(mockQb.andWhere).toHaveBeenCalledWith(
   expect.stringContaining(`deposit >= :depositMin`),
   expect.objectContaining({ depositMin: 5000 }),
  )
 })

위의 내용처럼 제공하는 각 필터 항목에 해당하는 쿼리들이 잘 추가되었는지 유닛테스트를 통해서 검증하고 있습니다.

이미 제공하는 필터의 모든 기능을 해당 빌더에서 테스트하기에 각 서비스 로직에서는 조건에 맞는 ItemFindOptions 객체가 잘 생성되었는지만 확인하면 되기에 기존 결합된 코드에 비해서 테스트 코드 작성의 난이도가 낮아졌습니다.

결론

QueryBuilder를 사용해야하는 케이스에서 재사용성을 높이고 테스트 코드 작성의 편의성을 높이기 위해 다양한 빌더 클래스를 도입하였습니다. 이러한 빌더 패턴을 적용함으로써 새로운 필터의 추가나 변경이 쉬워지고, 유지보수도 간편해집니다. 또한, 각 빌더 클래스에 대한 테스트 코드 작성으로 코드 품질을 높이는데 기여하였습니다.

마지막으로

지금까지의 경험을 토대로 우리는 코드의 유연성과 확장성을 높이는 방법에 대해 고민해보았습니다. 적절한 도구와 디자인 패턴의 적용은 개발 생산성을 향상시키며, 팀 전체의 코드 품질을 향상시키는데 중요한 역할을 합니다. 저희 팀의 끊임없는 학습과 개선을 통해 더 나은 코드와 효율적인 테스트 방법을 찾아 나가는 여정은 계속될 것입니다. 함께 성장하며 더 나은 소프트웨어를 만들어 나가기를 기대합니다.

감사합니다.

TypeORM QueryBuilder 활용 사례: 재사용성을 높이는 방법과 테스트 작성하기 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

백엔드 개발 업무를 하다보면 데이터베이스에 쿼리하는 일이 잦은데요. 그러다보면 종종 성능을 고려한 SQL을 작성해야하는 고민에 마주하게 됩니다.

필요한 데이터를 어떻게 테이블에서 조회하고 갱신할지에 대해 최적의 방법을 생각하게 되는데요.

이번 글에서는 인덱스 성능이 안 나오는 몇몇 사례를 중심으로 SQL의 비효율을 제거하는 과정을 (특히 인덱스 중심으로) 정리해 보도록 하겠습니다.

TOC

1. SQL 튜닝 개요
2. 인덱스 튜닝 세부 분류
3. 인덱스가 있는데도 인덱스를 안타는 케이스
4. 인덱스를 타긴 타는데 성능이 안나오는 케이스
5. 인덱스 스캔 비효율은 없지만 성능이 안나오는 케이스
6. 인덱스가 너무 많이 있는 케이스
7. 마무리

SQL 튜닝 개요

SQL 튜닝은 동일한 쿼리 결과를 더 빠르고 더 가볍게 개선하는 모든 행위를 말합니다.

SQL 튜닝의 성능지표는 cpu 시간이나 block IO 등을 통해 평가합니다. 동일한 결과를 조회하는데 DBMS가 얼마나 더 적은 자원을 사용했느냐가 성능 좋은 쿼리의 기준이 됩니다.

SQL의 튜닝 포인트들은 인덱스 튜닝, 조인 튜닝, 소트 튜닝, DML 튜닝 등이 있는데요. 이번 글에서는 인덱스 튜닝에 대해서 다뤄보도록 하겠습니다.

※인덱스 튜닝 관련 배경설명들이 매우 방대한 관계로 아래 항목들에 대한 자세한 설명은 각 항목에 연결해드린 외부 자료 참고 부탁드리겠습니다.

• explain, explain analyze
  - https://dev.mysql.com/doc/refman/8.0/en/explain-output.html
  - https://dev.mysql.com/blog-archive/mysql-explain-analyze/
• storage architecture
  - https://blog.ex-em.com/1699
• block io
  - http://www.gurubee.net/lecture/3117
• clustered index / nonclustered index
• single block io / multi block io
• table random access / table sequential access
• buffer pool access, latch

인덱스 튜닝 세부 분류

인덱스 튜닝은 아래와 같이 세부적으로 나누어 볼 수 있습니다.

1. 인덱스를 타지 않는 경우
   1.1. 인덱스가 없을때
    — 인덱스 생성
   1.2. 인덱스가 있을때
    — 인덱스 컬럼 가공으로 인한 성능저하 여부 확인
    — 인덱스 손익분기점 확인 (=테이블 풀스캔이 더 효율적인지 확인)
2. 인덱스를 타는 경우
   2.1. 인덱스 스캔 비효율 (인덱스 스캔량이 최종rows 보다 훨씬 많을때)
    — 인덱스 필터링으로 동작하는 인덱스 스캔 개선
   2.2. 인덱스 스캔 비효율은 없지만, 테이블 엑세스가 많을때
    — 인덱스만 읽고 멈추도록 개선
3. 불필요한/중복인 인덱스 제거or통합
    — DML 성능 향상
    — 인덱스 다이브 성능 개선

이 중에서 아래 4가지 항목에 대해 사례와 함께 살펴보도록 하겠습니다.

• 인덱스가 있는데도 인덱스를 안타는 상황 → 인덱스 손익 분기점
• 인덱스를 타긴 타는데 성능이 안나오는 상황 → 인덱스 스캔 비효율
• 인덱스 스캔 비효율은 없지만 성능이 안나오는 상황 → 테이블 랜덤엑세스 최소화
• 인덱스가 너무 많이 있는 상황 → 중복 인덱스 최적화

※ 테스트 환경은 아래와 같이 구성했습니다.

• mysql 8.0.34 (https://registry.hub.docker.com/_/mysql/)
• default my.cnf (zero config)

인덱스가 있는데도 인덱스를 안타는 상황 → 인덱스 손익 분기점

인덱스 스캔으로 잘 동작하던 SQL이 어느날 갑자기 테이블 풀스캔으로 동작하는 상황이 있습니다.

옵티마이저가 인덱스 레인지 스캔보다 테이블 풀스캔을 선택했기 때문인데요. 실제로 io 가 어떻게 발생하길래 옵티마이저가 그런 선택을 했는지 살펴보도록 하겠습니다.

실험을 위한 데이터는 국토부 실거래 데이터(http://rtdown.molit.go.kr)를 사용했습니다.

<거래금액>      82,500
</거래금액><거래유형>중개거래
</거래유형><건축년도>2002
</건축년도><년>2023
</년><등기일자>23.04.11
</등기일자><법정동> 영등포동
</법정동><아파트>영등포푸르지오
</아파트><월>3
</월><일>11
</일><전용면적>59.912
</전용면적><중개사소재지>서울 영등포구
</중개사소재지><지번>647
</지번><지역코드>11560
</지역코드><층>10
</층><해제사유발생일> 
</해제사유발생일><해제여부> 
</해제여부>

데이터의 스키마는 대략 아래와 같습니다.

• 지역코드
• 매물구분 (아파트,오피스텔,연립다세대)
• 거래구분 (매매,전월세)
• 거래일자
• 매매금액
• 보증금
• 월세
• 기타
  - 갱신요구권
  - 해제사유발생일
  - 등기일자
  - …

위 데이터를 기반으로 2020년도 이후 분량만 뽑아서 아래와 같이 아파트 실거래 테이블을 구축했습니다.

create table T
(
	id int unsigned auto_increment
		primary key,
	지역코드 varchar(5) not null,
	거래년월 int unsigned not null,
  	...
);

create index IDX_01 on T (거래년월);
...

이 테이블을 특정 거래일자 전후로 실행계획이 다르게 동작하는데요. 아래와 같이 인덱스가 있는데도 인덱스를 타지않고 풀스캔으로 동작하는 경우가 등장했습니다.

select count(*) from T
# 2034128건

select * from T where 거래년월 >= 202307
# 96977건 (range scan)

select * from T where 거래년월 >= 202306
# 134176건 (range scan)

select * from T where 거래년월 >= 202305
# 173069건 (full scan) <<< 갑자기 인덱스를 안탄다..?

위 상황과 관련하여 mysql 공식문서(table-scan-avoidance) 에서는 아래와 같이 4가지 상황을 가이드하고 있습니다.

• The table is so small that it is faster to perform a table scan than to bother with a key lookup. This is common for tables with fewer than 10 rows and a short row length.
• There are no usable restrictions in the ON or WHERE clause for indexed columns.
• You are comparing indexed columns with constant values and MySQL has calculated (based on the index tree) that the constants cover too large a part of the table and that a table scan would be faster. See Section 8.2.1.1, “WHERE Clause Optimization”.
• You are using a key with low cardinality (many rows match the key value) through another column. In this case, MySQL assumes that by using the key probably requires many key lookups and that a table scan would be faster.

3,4 항목을 보시면 옵티마이저가 “인덱스 키 조회 비용이 테이블 스캔 비용보다 더 크다고 판단” 하면, 인덱스가 있는데도 불구하고 테이블 풀 스캔을 사용한다고 설명합니다.

인덱스 스캔보다 테이블 풀스캔 비용이 더 낮아지는 지점을 “인덱스 손익 분기점” 이라고 하는데요.

위 그래프처럼 테이블 풀스캔의 비용은 일정한데 비해, 인덱스 스캔은 조회 건수에 비례하고 있습니다.

또한 쿼리 구조나 시스템 상황 등에 따라 기울기가 조금씩 달라지게 되는데요. 인덱스 스캔의 비용 직선이 테이블 풀스캔과 만나는 지점 어딘가에서 옵티마이저는 인덱스를 사용하지 않는 실행계획을 세우게 됩니다.

실제로 그렇게 동작하는지 확인해보겠습니다.

옵티마이저 테이플 풀스캔 vs 힌트 인덱스 레인지 스캔 : io 비교 (상세)

• https://gist.github.com/paulan-zb/51a7c8af8e9161faf129fa3154b93ffb

옵티마이저 테이플 풀스캔 vs 힌트 인덱스 레인지 스캔 : io 비교 (요약)

/**
 * 옵티마이저 풀스캔 vs 힌트 인덱스스캔 성능비교 정리
 */
## 옵티마이저 풀스캔
# => 논리IO: 145788-83717 = 62071
# => 물리IO: 36651-21307 = 15344

## 힌트 인덱스스캔
# => 논리IO: 275930-16207 = 259723
# => 물리IO: 3483-1205 = 2278

## 논리IO 비교 : 
# 259723 / 62071 = 4.18428896
# 259723 - 62071 = 197652
# => 인덱스스캔이 테이블풀스캔보다 논리IO가 훨씬 많이 발생했음 (풀스캔 대비 400% 수준)
# => 인덱스스캔에서 인덱스트리의 root-branch-leaf노드(block)를 각각 탐색하는 비용
#    + 최종 leaf노드에 담겨있는 clustered index key(여기에서는 pk id) 로 테이블엑세스를 single block io 로 접근함 (1요청 1블록)
# => 테이블스캔에서는 데이터block 을 곧바로 접근 + multi block io 방식으로 접근함 (1요청 N블록 → 서버/os 설정에 따라 달라질 수 있음)

## 물리IO 비교 : 
# 2278 / 15344 = 0.14846194
# 15344 - 2278 = 13066
# => 힌트인덱스스캔이 옵티마이저풀스캔보다 더 적은 물리IO가 발생함 (풀스캔 대비 14% 수준)
# => 인덱스스캔에서는 많은 block io 비용을 사용해서 최종row의 key를 선정한 다음에 테이블엑세스를 진행한 반면,
# => 테이블스캔에서는 일단 필요한 블록을 다 읽은 다음에 최종row 를 필터링했기 때문.

위 비교 자료를 통해 아래와 같이 결론을 정리할 수 있습니다.

• 스캔량이 인덱스 손익 분기점을 지나면, 테이블 풀스캔보다 인덱스 스캔에서 논리IO 가 더 많이 발생함
• 옵티마이저는 이를 알고 풀스캔을 실행계획으로 선택함

인덱스 스캔은 결국 소량의 데이터를 찾는 목적에서 잘 동작합니다. 많은 양의 데이터를 조회하는 쿼리에서는 적합하지 않으므로 다른 조회 전략을 찾는게 유리할 수 있습니다.

즉, 인덱스 스캔 에서는

1. 인덱스트리를 탐색하는 비용과
   버퍼캐시키체인 -> 래치 -> 버퍼풀에서 인덱스엑세스(없으면 버퍼풀 로딩) -> 인덱스필터링 -> 최종 대상 리프노드에 저장되어있는 클러스터드인덱스키(PK)로 테이블엑세스(이 역시 버퍼풀에서 먼저 찾고 없으면 로딩)
2. 최종 인덱스 리프노드에서 뽑은 clustered index key 로 테이블 로우를 읽는 비용(random access) 을 합한 비용이 발생하고,

테이블 풀스캔 에서는

1. 전체 테이블 로우를 다 읽는 비용(sequential access) 만 발생합니다.

너무 많은 대상을 인덱스로 찾으면, 전체 테이블을 읽는 비용보다 인덱스를 찾는 비용이 훨씬 더 많은 비용이 발생할 수도 있습니다. 인덱스를 안탄다고 강제로 힌트를 지정하더라도 사실은 그게 DBMS에 더 많은 io 비용을 만들어버리게 되는 것입니다.

다시 말해서, 테이블 풀스캔이 항상 나쁜 것은 아니고, 바꿔말해 인덱스 스캔이 항상 좋은 것도 아닙니다. 각 상황에 맞는 최적의 스캔방법을 선정하는 것이 중요합니다.

인덱스를 타긴 타는데 성능이 안나오는 상황 → 인덱스 스캔 비효율

인덱스필터링조건 vs 인덱스엑세스조건 : block io 비교 (인덱스 100개 읽어서 타겟팅완료 vs 인덱스 10개 읽어서 타겟팅 완료)

튜닝포인트 : 인덱스 필터링조건 → 엑세스조건 으로 변경

인덱스를 잘 탔는데도 성능이 떨어지는 상황이 있을 수 있습니다.

인덱스 스캔 자체에서 비효율이 발생하는 경우인데요. 복합인덱스에서는 인덱스 구성 컬럼에서 범위조건이 사용되면, 해당 컬럼 이후의 컬럼들은 인덱스 스캔이 “엑세스” 가 아니라 “필터링” 으로 동작합니다.

예를 들면, 동일테이블 동일인덱스 에서

• 상황1 : 100건 스캔 → 5건 필터링 → 5건 테이블엑세스
• 상황2 : 20건 스캔 → 5건 필터링 → 5건 테이블엑세스

로 동작할수도 있다는 의미 입니다.

위 상황을 만들어서 한번 살펴보도록 하겠습니다.

아래와 같은 테이블을 준비했습니다.

create table T
(
	id int unsigned not null
		primary key,
	지역코드 varchar(5) not null,
	거래년월 int unsigned not null,
  ...
);

create index IDX_02 on T (지역코드, 거래년월);
...

위 테이블에서 서울지역의 2023년도 매매건수를 확인해보겠습니다.

select count(*)
from T
where 지역코드 like '11%'
and 거래년월 between 202301 and 202309
-- 27498건

explain
select count(*)
from T
where 지역코드 like '11%'
and 거래년월 between 202301 and 202309
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+--------------------------------+
# |id|select_type|table|partitions|type |possible_keys|key   |key_len|ref |rows  |filtered|Extra                           |
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+--------------------------------+
# |1 |SIMPLE     |T    |null      |range|IDX_02       |IDX_02|206    |null|360246|11.11   |Using index condition; Using MRR|
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+--------------------------------+

위에서 만든 IDX_02 인덱스를 레인지 스캔으로 잘 타는 것처럼 보입니다.

하지만 실제로는 어떻게 스캔이 동작하는지 좀 더 상세하게 확인해보겠습니다.

explain analyze
select count(*)
from T
where 지역코드 like '11%'
and 거래년월 between 202301 and 202309
# -> Aggregate: count(0)  (cost=84718 rows=1) (actual time=132..132 rows=1 loops=1)
#     -> Filter: ((T.`지역코드` like '11%') and (T.`거래년월` between 202301 and 202308))  (cost=80715 rows=40023) (actual time=1.19..130 rows=25620 loops=1)
#         -> Covering index range scan on t using IDX_02 over ('11￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿' <= 지역코드 <= '11￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿￿' AND 202301 <= 거래년월 <= 202308)  (cost=80715 rows=360246) (actual time=0.0297..96.3 rows=167787 loops=1)

explain analyze 에서 분석한 내용을 확인해보면,
1) 인덱스 레인지 스캔을 통해 167787건 읽은 다음
2) 140289건이 필터링되어 25620건이 출력으로 나와
3) 최종적으로 count함수로 1건이 Aggregate되었다고 설명하고 있습니다.
27498/167787 = 0.16388636 (약 16%) 즉 16% 를 얻기위해 84% 를 읽고 그냥 버려버리는 매우 비효율적인 처리로 동작했습니다.

사실 이 167787건은 지역코드 11(서울지역) 에 해당되는 데이터 건수이고, 25620건은 지역코드 11(서울지역) + 거래년월 2023–01 ~ 2023–09에 해당되는 데이터 건수인데요.

위에서 만든 IDX_02 인덱스는 (지역코드, 거래년월) 컬럼으로 만들어졌고, 위 쿼리는 지역코드 거래년월 만 사용했는데, 왜 두 컬럼중 앞쪽 지역코드 컬럼만 사용되었을까요?

그 이유는 복합인덱스의 경우, 인덱스 선행컬럼이 조건절에 없거나 =조건이 아니면, 인덱스 스캔 과정에 비효율이 발생하기 때문입니다.

인덱스 스캔은 액세스 조건과 필터 조건으로 구분되어 동작하는데요.

• 인덱스 엑세스 조건 : 인덱스 스캔 범위 결정
• 인덱스 필터 조건 : 테이블 엑세스 여부 결정
• 테이블 필터 조건 : 최종 결과집합 포함 여부 결정

위 문제의 쿼리에서는 인덱스 선행컬럼인 지역코드를 지역코드 like '11%' 와 같이 범위검색으로 접근했기 때문에, 인덱스 후행컬럼인 거래년월 컬럼조건 거래년월 between 202301 and 202309 이 스캔범위를 결정하는데 사용되지 못했기 때문입니다.

이런 유형의 쿼리는 선행컬럼의 범위검색 조건을 IN-List 조건으로 변경하는 것으로 개선할 수 있습니다.

explain
select count(*)
from T
where 지역코드 in (
    '11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740'
)
and 거래년월 between 202301 and 202309
# +--+-----------+-----+----------+-----+-------------+------+-------+----+-----+--------+------------------------+
# |id|select_type|table|partitions|type |possible_keys|key   |key_len|ref |rows |filtered|Extra                   |
# +--+-----------+-----+----------+-----+-------------+------+-------+----+-----+--------+------------------------+
# |1 |SIMPLE     |T    |null      |range|IDX_02       |IDX_02|206    |null|27499|100     |Using where; Using index|
# +--+-----------+-----+----------+-----+-------------+------+-------+----+-----+--------+------------------------+
# => 인덱스 레인지스캔 탐

explain analyze
select count(*)
from T
where 지역코드 in (
    '11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740'
)
and 거래년월 between 202301 and 202309
# -> Aggregate: count(0)  (cost=8912 rows=1) (actual time=34.6..34.6 rows=1 loops=1)
#     -> Filter: ((T.`지역코드` in ('11000','11110','11140','11170','11200','11215','11230','11260','11290','11305','11320','11350','11380','11410','11440','11470','11500','11530','11545','11560','11590','11620','11650','11680','11710','11740')) and (T.거래년월 between 202301 and 202309))  (cost=6162 rows=27499) (actual time=0.0413..32.8 rows=27498 loops=1)
#         -> Covering index range scan on t using IDX_02 over (지역코드 = '11000' AND 202301 <= 거래년월 <= 202309) OR (지역코드 = '11110' AND 202301 <= 거래년월 <= 202309) OR (24 more)  (cost=6162 rows=27499) (actual time=0.0368..16.8 rows=27498 loops=1)

27498건 읽어서 최종 27498건을 사용했고, 27498/27498 = 1.0 (100%) 스캔 비효율이 없는 쿼리로 개선되었습니다.

IN-List 조건은 내부적으로 IN절을 N번 반복하는 형태로 동작하는데요. 이는 explain analyze 에서 레인지스캔 분석 부분을 살펴보면 (지역코드 = '11000' AND 202301 <= 거래년월 <= 202309) OR (지역코드 = '11110' AND 202301 <= 거래년월 <= 202309) OR (24 more) 로 표현되어 있는 것으로 확인할 수 있습니다.

즉, 인덱스 선행컬럼인 지역코드 조건이 = 조건으로 총 26회 펼쳐져서 동작하게 되어, 지역코드 + 거래년월 조건으로 정확하게 필요한 영역(27498건) 만 스캔하도록 동작하게 되었습니다.

※ 인덱스 탐색 동작에 대한 내용은 다음 기회에 좀 더 자세히 설명해보도록 하겠습니다.

※ IN-LIST 변환에 너무 많은 값이 들어가게 되면 오히려 성능이 나빠질 수도 있습니다. (ex. eq_range_index_dive_limit)

이처럼 explain 결과에서 인덱스 스캔 사용여부만 확인하고 넘어간다면, 비효율적인 인덱스 스캔을 놓치게 될 수도 있습니다. 인덱스 스캔으로 동작하지만 실제 비효율적인 동작이 있는지 explain analyze 를 통해 한번 더 확인해본다면 예상하지 못한 성능저하를 예방할 수 있습니다.

인덱스 스캔 비효율은 없지만 성능이 안나오는 상황 → 테이블 랜덤 엑세스 최소화

테이블엑세스 vs 인덱스만읽기 : block io 비교 (인덱스 10개 테이블 5개 읽어서 타겟팅완료 vs 인덱스 10개-5개필터링 해서 타겟팅완료)

튜닝포인트 : 인덱스 컬럼 추가

인덱스 스캔 비효율은 없지만 그래도 성능이 안나오는 경우도 있습니다.

이런 케이스는 실제 데이터를 스캔하는 일량 자체가 많은 상황이기 때문에, 조회 조건이나 순서를 조정하는 등의 SQL 외적인 방법을 고려하는게 바람직하지만,

그럼에도 불구하고 특정 상황에서는 SQL 레벨에서 성능을 개선하는 방법도 있습니다.

아래 데이터를 통해 확인해보겠습니다.

create table T
(
	id int unsigned not null
		primary key,
	지역코드 varchar(5) not null,
	거래년월 int unsigned not null,
	거래금액 int unsigned not null,
  ...
);

create index IDX_02 on T (지역코드, 거래년월);
...

## 서울지역 2020~2022년 사이 시군구별 최고매매가 계산
select 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드;

explain
select 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드;
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+---------------------+
# |id|select_type|table|partitions|type |possible_keys|key   |key_len|ref |rows  |filtered|Extra                |
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+---------------------+
# |1 |SIMPLE     |t    |null      |range|IDX_02       |IDX_02|206    |null|195035|100     |Using index condition|
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+---------------------+
# => 레인지스캔 잘 탐

explain analyze
select 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드
# -> Group aggregate: max(T.`거래금액`)  (cost=212457 rows=238) (actual time=10.8..892 rows=25 loops=1)
#     -> Index range scan on t using IDX_02 over (지역코드 = '11000' AND 202001 <= DEAL_YM <= 202212) OR (지역코드 = '11110' AND 202001 <= DEAL_YM <= 202212) OR (24 more), with index condition: ((T.`지역코드` in ('11000','11110','11140','11170','11200','11215','11230','11260','11290','11305','11320','11350','11380','11410','11440','11470','11500','11530','11545','11560','11590','11620','11650','11680','11710','11740')) and (T.거래년월 between 202001 and 202212))  (cost=192953 rows=195035) (actual time=0.061..857 rows=140289 loops=1)
# => 인덱스스캔 140289건 → 테이블스캔 140289건 (100%, 비효율없음)
# => 140289건 → group by 25건

IDX_02 인덱스를 레인지 스캔으로 비효율없이 잘 쿼리하는 것 같습니다.

show status like 'Innodb_buffer_pool_read%'
# +-------------------------------------+-----+
# |Variable_name                        |Value|
# +-------------------------------------+-----+
# |Innodb_buffer_pool_read_ahead_rnd    |0    |
# |Innodb_buffer_pool_read_ahead        |0    |
# |Innodb_buffer_pool_read_ahead_evicted|0    |
# |Innodb_buffer_pool_read_requests     |16453|
# |Innodb_buffer_pool_reads             |1432 |
# +-------------------------------------+-----+

select 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드;

show status like 'Innodb_buffer_pool_read%'
# +-------------------------------------+------+
# |Variable_name                        |Value |
# +-------------------------------------+------+
# |Innodb_buffer_pool_read_ahead_rnd    |0     |
# |Innodb_buffer_pool_read_ahead        |0     |
# |Innodb_buffer_pool_read_ahead_evicted|0     |
# |Innodb_buffer_pool_read_requests     |474380|
# |Innodb_buffer_pool_reads             |4003  |
# +-------------------------------------+------+
# => 474380-16453 = 457927 (논리read io)

위 쿼리는 스캔 비효율은 없지만 read io 일량(인덱스 스캔 + 테이블 랜덤 엑세스) 자체가 많은 케이스 입니다. 140289건을 읽기위해 457927만큼의 read io 가 발생했습니다.

이런 경우에는 아래와 같이 인덱스에 컬럼을 추가하는 것으로 인덱스까지만 읽고 테이블 랜덤 엑세스가 발생하지 않도록 유도할 수 있습니다.

-- create index IDX_02 on T (지역코드, 거래년월);
create index IDX_03 on T (지역코드, 거래년월, 거래금액);

## 서울지역 2020~2022년 사이 시군구별 최고매매가 계산
select /*+ index(T IDX_03) */ 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드;

explain
select /*+ index(T IDX_03) */ 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+------------------------+
# |id|select_type|table|partitions|type |possible_keys|key   |key_len|ref |rows  |filtered|Extra                   |
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+------------------------+
# |1 |SIMPLE     |t    |null      |range|IDX_03       |IDX_03|206    |null|217038|100     |Using where; Using index|
# +--+-----------+-----+----------+-----+-------------+------+-------+----+------+--------+------------------------+
# => 레인지스캔 잘 탐

explain analyze
select /*+ index(T IDX_03) */ 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드
# -> Group aggregate: max(T.`거래금액`)  (cost=70364 rows=238) (actual time=2.25..218 rows=25 loops=1)
#     -> Filter: ((T.`지역코드` in ('11000','11110','11140','11170','11200','11215','11230','11260','11290','11305','11320','11350','11380','11410','11440','11470','11500','11530','11545','11560','11590','11620','11650','11680','11710','11740')) and (T.거래년월 between 202001 and 202212))  (cost=48660 rows=217038) (actual time=0.0412..187 rows=140289 loops=1)
#         -> Covering index range scan on t using IDX_03 over (지역코드 = '11000' AND 202001 <= 거래년월 <= 202212) OR (지역코드 = '11110' AND 202001 <= 거래년월 <= 202212) OR (24 more)  (cost=48660 rows=217038) (actual time=0.0369..104 rows=140289 loops=1)
# => 140289건 읽어서 140289건 필터링 (100%, 비효율없음)
# => 인덱스스캔 140289건 → group by 25건 (커버링인덱스에서 필터링 동작, 테이블스캔이 사라짐)

show status like 'Innodb_buffer_pool_read%';
# +-------------------------------------+-----+
# |Variable_name                        |Value|
# +-------------------------------------+-----+
# |Innodb_buffer_pool_read_ahead_rnd    |0    |
# |Innodb_buffer_pool_read_ahead        |0    |
# |Innodb_buffer_pool_read_ahead_evicted|0    |
# |Innodb_buffer_pool_read_requests     |16320|
# |Innodb_buffer_pool_reads             |1289 |
# +-------------------------------------+-----+

select /*+ index(T IDX_03) */ 지역코드, max(거래금액)
from T
where 지역코드 in ('11000', '11110', '11140', '11170', '11200', '11215', '11230', '11260', '11290', '11305', '11320', '11350', '11380', '11410', '11440', '11470', '11500', '11530', '11545', '11560', '11590', '11620', '11650', '11680', '11710', '11740')
and 거래년월 between 202001 and 202212
group by 지역코드;

show status like 'Innodb_buffer_pool_read%';
# +-------------------------------------+-----+
# |Variable_name                        |Value|
# +-------------------------------------+-----+
# |Innodb_buffer_pool_read_ahead_rnd    |0    |
# |Innodb_buffer_pool_read_ahead        |0    |
# |Innodb_buffer_pool_read_ahead_evicted|0    |
# |Innodb_buffer_pool_read_requests     |33105|
# |Innodb_buffer_pool_reads             |1490 |
# +-------------------------------------+-----+
# => 33105-16320 = 16785 (read io)

IDX_02 에 비해 IDX_03 에서 read io 가 큰 폭으로(asis: 457927 → tobe: 16785) 줄어들었습니다.

/**
 * 결론
 */
## 비효율은 없지만 테이블랜덤엑세스(read io 실제 일량)가 많은 상황
# => 474380-16453 = 457927 (read io)
# => 인덱스스캔 140289건 → 테이블스캔 140289건 (100%, 비효율없음) → group by 25건

## 인덱스 컬럼추가로 테이블랜덤엑세스 최소화
# => 33105-16320 = 16785 (read io)
# => 인덱스스캔 140289건 → group by 25건 (테이블랜덤엑세스 사라짐)

기존 대비 3% (16785 / 457927 = 0.03665431) 수준의 io 만 사용하는 쿼리로 개선되었습니다. 쿼리가 인덱스만 읽고 처리를 완료할 수 있도록 변경되어서 테이블 랜덤 엑세스가 사라졌고, 이에 관련 비용들이 줄어들게 된 것입니다.

커버링인덱스의 실제 io 프로파일링을 확인해보니, 생각했던 것 보다 더 많은 io 를 줄일수 있다는 것을 알 수 있었습니다. (테이블 랜덤 엑세스 비용이 그 만큼 비싸다는 반증으로 볼 수 있겠습니다.)

커버링인덱스는 유용한 인덱스 튜닝 방법이긴 하지만, 복잡한 인덱스를 여기저기 과도하게 생성하게 되면 또 다른 문제가 발생할 수 있습니다.

이어지는 주제에서 과도한 인덱스가 어떤 문제를 발생하는 지에 대해 자세히 다뤄보도록 하겠습니다.

인덱스가 너무 많이 있는 상황 → 중복 인덱스 최적화

중복인덱스 테이블 vs 인덱스없는 테이블 vs 인덱스 최적화 테이블 : query profile 비교

튜닝포인트 : 인덱스 통폐합

인덱스를 줄이는 것도 인덱스 튜닝이 될 수 있습니다.

너무 많은 인덱스, 불필요한 인덱스는 DML 성능을 떨어뜨립니다. 또한 저장공간의 낭비, 의도하지 않은 인덱스 선정 등과 같은 부작용도 함께 발생할 수 있습니다.

중복인덱스 테이블과 인덱스를 최적화한 테이블 간의 query profile 을 비교해보겠습니다.

실험을 위한 테이블을 아래와 같이 준비했습니다.

create table 아파트_실거래
(
	id int unsigned auto_increment
		primary key,
	거래일자 datetime not null,
	아파트코드 int unsigned not null,
	전용면적 decimal unsigned default 0 not null,
	...
);
create index IDX_01 on 아파트_실거래 (전용면적);
create index IDX_02 on 아파트_실거래 (거래일자);
create index IDX_03 on 아파트_실거래 (아파트코드, 전용면적, 거래일자);
create index IDX_04 on 아파트_실거래 (아파트코드, 전용면적);
create index IDX_05 on 아파트_실거래 (아파트코드);

## 인덱스 없는 테이블
create table 아파트_실거래_noindex like 아파트_실거래;
insert into 아파트_실거래_noindex select * from 아파트_실거래;

## 인덱스 통폐합 테이블
create table 아파트_실거래_compact_index like 아파트_실거래;
insert into 아파트_실거래_compact_index select * from 아파트_실거래;
create index IDX_02 on 아파트_실거래_compact_index (거래일자);
create index IDX_03 on 아파트_실거래_compact_index (아파트코드, 전용면적, 거래일자);

중복인덱스 테이블 vs 인덱스없는 테이블 vs 인덱스 최적화 테이블 : query profile 비교 (상세)

• https://gist.github.com/paulan-zb/6245874265333577523746084d2de9f5

중복인덱스 테이블 vs 인덱스없는 테이블 vs 인덱스 최적화 테이블 : query profile 비교 (요약)

/**
 * 중복인덱스 vs 인덱스없음 vs 인덱스통폐합 DML 성능비교 정리
 */
## 중복인덱스 테이블
# block io :
# => read io : 15876 → 450088 => 434212
# => write io :  1857 → 201534 => 199677

## 인덱스 없는 테이블
# block io :
# => read io : 41120 → 82548 => 41428
# => write io :  3412 → 23887 => 20475

## 인덱스통폐합 테이블
# block io :
# => read io : 16932 → 176005 => 159073
# => write io :  1856 → 82184 => 80328


## 결론1
# 동일 스키마 테이블에 10000건 insert 에 대해서
# write io 는 중복인덱스(199677) > 인덱스통폐합(80328) > 인덱스없음(20475) 의 형상을 띔
# => 중복인덱스(199677) / 인덱스통폐합(80328) = 2.48577084 (약 250%)
# => 중복인덱스(199677) / 인덱스없음(20475) = 9.75223443 (약 970%)


## 결론2
# DML 쿼리에서는 테이블 CUD 뿐만아니라, 인덱스 갱신/정렬 도 함께 발생하기때문에
# read io 역시 중복인덱스에서 훨씬 많이 발생함
# => 중복인덱스(434212) / 인덱스통폐합(159073) = 2.72963985 (약 270%)
# => 중복인덱스(434212) / 인덱스없음(41428) = 10.48112388 (약 1050%)


## 결론3
select table_schema, table_name,
       round(sum(data_length)/1024/1024,2) as 'table Size(Mb)',
       round(sum(index_length)/1024/1024,2) as 'index Size(Mb)',
       max(table_rows) as rows_number,
       max(auto_increment) as auto_increment_value
from information_schema.tables
where table_schema = 'test' and table_name like '아파트_실거래%'
group by table_schema, table_name;
# +------------+---------------------+--------------+--------------+-----------+--------------------+
# |TABLE_SCHEMA|TABLE_NAME           |table Size(Mb)|index Size(Mb)|rows_number|auto_increment_value|
# +------------+---------------------+--------------+--------------+-----------+--------------------+
# |test        |아파트_실거래              |82.61         |176.34        |1495158    |31963385            |
# |test        |아파트_실거래_noindex      |82.61         |0.00          |1495158    |31963385            |
# |test        |아파트_실거래_compact_index|82.61         |30.56         |1495158    |31963385            |
# +------------+---------------------+--------------+--------------+-----------+--------------------+
# => 불필요한 인덱스 최적화를 통해, 테이블보다 인덱스 사이즈가 더 큰 비효율을 개선할 수 있음
# => 중복인덱스 : 82.61(테이블) / 176.34(인덱스)
# => 인덱스통폐합 : 82.61(테이블) / 30.56(인덱스)
#     => 176.34 → 30.56 으로 asis 대비 17% 수준으로 인덱스 용량 최적화
#     => 176.34/82.61(약 210%) → 30.56/82.61(약 36%) 으로 테이블 대비 인덱스 용량 최적화
# => 인덱스없음 : 82.61(테이블) / 0(인덱스)

위 비교 자료를 통해 아래와 같이 결론을 정리할 수 있습니다.

• 불필요한 인덱스로 인해 DML 쿼리에서 상당한 비효율이 발생할 수 있음
• DML 성능 뿐만아니라, 저장공간 낭비도 발생할 수 있음

인덱스는 꼭 필요한 조회경로에 대해서만 생성하는 것이 좋습니다.

특히 중복 인덱스의 경우에는 조회/갱신 양쪽 모두에서 불필요한 성능저하가 발생할 수 있는데요. 가능하다면 중복 인덱스가 보인다면 인덱스 정리를 고려해볼 수 있겠습니다.

※중복 인덱스 정리는 해당 컬럼을 사용하는 모든 쿼리의 실행계획에 영향을 줄 수 있으므로 신중한 진행이 필요합니다.

마무리

지금까지 인덱스를 타더라도 성능이 안나올 수 있는 상황들을 살펴봤습니다.

• 인덱스가 있는데도 인덱스를 안타는 상황 → 인덱스 손익 분기점
   — 옵티마이저 테이플풀스캔 vs 힌트 인덱스레인지스캔 : block io 비교
• 인덱스를 타긴 타는데 성능이 안나오는 상황 → 인덱스 스캔 비효율
   — 인덱스필터링조건 vs 인덱스엑세스조건 : block io 비교 (인덱스 100개 읽어서 타겟팅완료 vs 인덱스 10개 읽어서 타겟팅 완료)
   — 튜닝포인트 : 인덱스 필터링조건 → 엑세스조건 으로 변경
• 인덱스 스캔 비효율은 없지만 성능이 안나오는 상황 → 테이블 랜덤엑세스 최소화
   — 테이블엑세스 vs 인덱스만읽기 : block io 비교 (인덱스 10개 테이블 5개 읽어서 타겟팅완료 vs 인덱스 10개-5개필터링 해서 타겟팅완료)
   — 튜닝포인트 : 인덱스 컬럼 추가
• 인덱스가 너무 많이 있는 상황 → 중복 인덱스 최적화
   — 중복인덱스 테이블 vs 인덱스없는 테이블 vs 인덱스 최적화 테이블 : query profile 비교
   — 튜닝포인트 : 인덱스 통폐합

이 밖에도 인덱스 튜닝 포인트는 많이 있을 수 있습니다.

• 인덱스 스킵 스캔
• 인덱스 다이브 최적화
• 인덱스를 이용한 sort 연산 생략
• …

튜닝의 핵심은 이슈 상황에 따라 어떤 지점에서 어떤 비용이 많이 발생하는지를 파악하는게 가장 중요합니다.

1) explain, explain analyze 등을 통해 쿼리가 어떻게 동작하는지 확인하고,
2) 필요하다면 쿼리 프로파일링을 통해 실제 시스템에서 cpu, block io 등이 얼마나 발생하고 있는지 검토한 다음,
3) 비효율을 제거할 수 있는 포인트를 찾고,
4) 해당 지점을 효율적으로 동작하도록 개선해 나가는게 중요하겠습니다.

감사합니다.

MYSQL 인덱스 튜닝 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

모듈 페더레이션(Module Federation) 은 애플리케이션을 여러 개의 작은 애플리케이션으로 분할하는 것을 말합니다. 마이크로 서비스와 유사하여 Micro-frontends 라고도 불립니다. 직방 프론트엔드 팀에서는 react-native를 사용하여 앱을 개발하면서 다음과 같은 미션을 수행하기 위해 모듈 페더레이션을 고려하고 있습니다.

• 업데이트 과정 최적화
  OTA(Over-the-air programming)를 활용하여 자바스크립트 코드를 업데이트하여, 사용자는 앱을 다시 다운로드하거나 재설치하지 않고도 업데이트된 서비스를 사용할 수 있습니다.
• 유연한 배포 관리
  각 모듈의 코드를 서버에서 제어하므로 A/B 테스팅, 사용자 그룹 또는 각 모듈별로 업데이트를 제어할 수 있습니다.
• 심사과정 없는 앱 업데이트
  remote 모듈을 업데이트하는 것으로 앱을 업데이트를 수행할 수 있습니다. 다만 Store의 정책을 위반하지 않도록 코드에 대한 수정 사항이나 조정을 제공하는 데 사용하여야 하고, 새 기능을 추가해서는 안 됩니다.
• 서비스 별 개발 및 배포
  전체 서비스를 빌드하는 것에 비해 작은 앱으로 빌드하게 되어 디버깅 및 테스트를 빠르게 할 수 있습니다.

모듈 페더레이션의 기능

모듈 페더레이션을 통해 다음과 같은 것을 이룰 수 있습니다.

• 애플리케이션을 여러 개의 격리된 컨테이너로 분할할 수 있습니다.
• 각 컨테이너에 대한 빌드 및 프로세스를 구성할 수 있습니다.
• 필요에 따라 컨테이너를 동적으로 로드할 수 있습니다.
• 각기 다른 버전의 컨테이너를 로드할 수 있습니다.
• 외부 Micro-frontend를 사용가능하게 됩니다.

모듈 페더레이션의 용어

모듈 페더레이션을 이해하기 위해서는 몇가지 용어를 익혀두어야 합니다.

• Host Application(host): 처음으로 실행되는 컨테이너, 스토어에 배포된 앱
• Local module(local): App bundle(.ipa, .apk)에 포함되는 모듈
• Remote module(remote): App bundle 로 포함되지 않으며 요청시 원격 위치에서 다운로드됩니다.
• Expose : 컨테이너가 외부에 노출하려는 모듈의 목록을 나타냅니다.
• Shared: 별도의 청크로 분리하여 앱의 런타임에 로드해 사용하는 의존성 모듈입니다.
• Shell: 껍데기라는 의미로 여러 마이크로 프론트엔드 프로젝트를 모아서 보여주는 하나의 프론트엔드 프로젝트입니다. 마이크로 앱 간의 라우팅, 공유 데이터 저장소 초기화 및 각 앱의 lazy loading 을 처리합니다.

react-native 에 모듈 페더레이션을 적용하기 위해서는 Re.Pack 라이브러리를 사용해야 합니다.

Re.Pack

Re.Pack은 callstack 에서 만든 React Native 어플리케이션을 위한 bundler 입니다. react-native cli 를 대체하고, 개발 서버로 작동하거나 React Native 앱을 번들링 하는 역할을 합니다. 또한, Re.Pack 은 Webpack 으로 제작된 번들을 react-native 애플리케이션에서 사용할 수 있게 만들어, 코드 스플리팅(Code splitting) 을 가능하게할 수 있습니다.

Re.Pack을 코드레벨에서 살펴보면서 간단하게 모듈 페더레이션을 살펴보도록 하겠습니다. 앱의 구조는 다음 그림과 같이 host앱이 app1, app2의 remote 앱을 가지는 구성을 해보도록 하겠습니다.

프로젝트의 구조는 다음과 같습니다.(monorepo 구조를 사용합니다)
각각의 모듈에서 독립적으로 구성 및 실행이 가능하도록 구성합니다.

/packages
  ㄴ host
    ㄴ android
    ㄴ ios
    ㄴ webpack.config.js
  ㄴ app1
    ㄴ android
    ㄴ ios
    ㄴ webpack.config.js
  ㄴ app2
    ㄴ android
    ㄴ ios
    ㄴ webpack.config.js

host 설정

host 앱은 app1, app2 컨테이너로부터 “./App” 모듈을 import 합니다.
원격으로 모듈을 불러오기때문에 로딩이 발생하게됩니다. 로딩을 처리하기 위하여 Suspense 와 ErrorBoundary를 사용하도록 합니다.

//App.tsx
import { Federated } from "@callstack/repack/client"

const App1 = React.lazy(() => Federated.importModule("app1", "./App"))
const App2 = React.lazy(() => Federated.importModule("app2", "./App"))

return (
  <ErrorBoundary>
   <React.Suspense
    fallback={
      <Loading />
    }>
    <App1 />
   </React.Suspense>
  </ErrorBoundary>
  <ErrorBoundary>
   <React.Suspense
    fallback={
      <Loading />
    }>
    <App2 />
   </React.Suspense>
  </ErrorBoundary>

host는 각 remote 모듈을 요청할 주소를 설정해주어야합니다. Re.Pack의 ScriptManager.shared.addResolver 를 사용하여 주소를 설정하도록합니다.

// index.js
import { ScriptManager, Federated } from "@callstack/repack/client"

const resolveURL = Federated.createURLResolver({
 containers: {
  app1: __DEV__
   ? "http://localhost:9001/[name][ext]"
   : `https://CF.zigbang.in/chunks/app1/${Platform.OS}/[name][ext]`,
  app2: __DEV__
   ? "http://localhost:9002/[name][ext]"
   : `https://CF.zigbang.in/chunks/app2/${Platform.OS}/[name][ext]`,
 },
})

ScriptManager.shared.addResolver(async (scriptId, caller) => {
 const url = resolveURL(scriptId, caller)
 return {
  url,
  cache: false,
  query: {
   platform: Platform.OS,
  },
 }
})

개발시에는 localhost:9001, localhost:9002 주소를 사용하도록 하였기 때문에 host의 dev 서버 이외에도 각각의 모듈의 서버를 실행해주어야합니다. (host 앱은 기본적으로 localhost:8081 주소를 사용합니다.)

//package.json
"start": "react-native webpack-start --port 9001",

$app1 % yarn start
>Server listening at http://[::1]:9001
$app2 % yarn start
>Server listening at http://[::1]:9002

모듈 expose 설정

각 컨테이너에서는 host 에서 요청할 모듈을 expose 해주어야합니다.

//app1/webpack.config.js
plugins: [
      new Repack.plugins.ModuleFederationPlugin({
        name: 'app1',
        exposes: {
          './App': './src/App.tsx',
        },

//app2/webpack.config.js
plugins: [
      new Repack.plugins.ModuleFederationPlugin({
        name: 'app2',
        exposes: {
          './App': './src/App.tsx',
        },

보신 코드를 통해 코드 스플리팅과 모듈을 원격으로 불러오도록 구성이 가능하게 됩니다.

캐싱

remote 모듈은 요청 시 네트워크를 통해 다운로드를 하기 때문에 최적화를 위해 캐싱을 활용할 수 있습니다. 한번 다운로드된 모듈은 ScriptManager에 의해 캐싱되어 이후에 다시 요청을 할 때에는 다운로드를 하지 않습니다. 그렇다면 업데이트된 모듈을 다운로드하기 위해서는 어떻게 해야 할까요?
캐싱된 모듈을 사용하지 않고 모듈을 다시 다운로드하기 위해서 다음과 같은 방법을 사용할 수 있습니다.

• url 변경 : 기본적으로 ScriptManager 는 method/url/query/header or body를 비교하여 다운로드가 필요한지 결정합니다.
• 서버 캐싱 Invalidation: Cloudfront 등 을사용하여 서버에서 캐싱을 하고 있다면 Invalidation을 통해 캐시를 새로 다운로드하도록할 수 있습니다.
• invalidateScripts 메서드 사용: ScriptManager.shared.invalidateScripts 메서드를 활용하여 캐시를 제거할 수 있습니다.

Re.Pack 앱 배포

Re.Pack 앱을 배포할때에는 host 앱과 remote 모듈을 배포하는 방식이 다릅니다. host 앱을 배포하기 위하여 번들링 된 .ipa, .apk 파일을 만들어야 합니다.
이때 ios에서는 main.jsbundle 파일이 필요로 하는데 webpack-bundle 커맨드를 통해 번들을 생성하여 main.jsbundle 로 지정해주어야 합니다.

//기존 react-native main.jsbundle 생성
"build:ios": "react-native bundle --entry-file='index.js' --bundle-output='./ios/main.jsbundle' --reset-cache --dev=false --platform='ios'",
//repack에서 bundle 생성
"bundle:ios": "react-native webpack-bundle --platform ios --entry-file index.js  --bundle-output ./ios/main.jsbundle --dev=false",

remote 모듈을 배포를 할 때에도 webpack-bundle 커맨드를 통해 청크를 생성하여야 합니다. webpack-bundle을 통해 생성된 build는 다음과 같은 구조를 가지게 됩니다.

/build
  ㄴ ios
    ㄴ assets
    ㄴ app.container.bundle
    ㄴ app.container.bundle.map
    ㄴ index.bundle
    ㄴ index.bundle.map
    ㄴ src_App_tsx.chunk.bundle
    ㄴ src_App_tsx.chunk.bundle.map   

생성된 청크를 서버에 업로드하여 다운로드할 수 있도록 합니다. 저의 경우 S3에 업로드하였습니다.

Re.Pack 사용시 고려해야할 사항

Re.Pack을 적용하고 사용해 보면서 겪은 것들이 많았습니다.

• 모듈 페더레이션에 대한 이해도가 필요하였고, 기존 앱을 어떻게 분할하고 구성할 것인지 많은 고민이 필요하였습니다.
• 초기 설정을 하는 과정에서 react-native와 native 라이브러리와의 호환성으로 인해 버전을 수시로 변경하여야 했습니다.
• 기존의 metro 번들러에 비하여 속도적으로 느렸지만 리소스를 분리하여 빌드하기에 더 빠르게 빌드할 수 있었습니다.
• remote 모듈을 사용하면서 네트워크 비용이 발생하게 되었습니다.
• 앱의 개수가 늘어나게 되면서 테스트 앱의 관리비용이 증가하였습니다.
• 에러 발생 시 생태계의 도움을 받기 힘들어 많은 시간이 필요했습니다.

마치며

react-native에 모듈 페더레이션을 도입하기 위해 Re.Pack을 사용한 경험을 소개해 드렸습니다.
모듈 페더레이션은 react-native를 사용하고 계시는 많은 개발자들에게 성숙한 서비스의 개발환경 개선을 위한 좋은 방안이라고 생각합니다. 이 글에서 제시하는 Re.Pack을 통해 모듈 페더레이션을 사용해 보시면 좋을 것 같습니다.

출처:
사진-1: https://rangle.io/blog/module-federation-federated-application-architectures

react-native 에 모듈 페더레이션 더하기 (with. RePack) was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

개발단계에서 부하를 발생시켜 성능테스트를 해야 할 경우가 간혹 있습니다. 이 경우 NodeJS 부하테스트 툴인 autocannon을 주로 사용하는 편인데요. 오늘은 부하테스트가 필요한 실제와 가까운 사례를 한 가지 들어 보면서 autocannon을 사용하는 법을 소개해 드리도록 하겠습니다.

비즈니스 로직을 만드는 과정에서 만약 두 위치 거리를 계산하는 것이 필요하다고 가정해 보겠습니다. 이 문제를 해결하기 위한 방법은 크게 두 가지로 직접 구현하거나, 검증된 오픈소스를 사용하거나 일 것 같습니다.

직접 구현하는 것도 좋지만 구면에서 두 지점간거리를 구하는 공식이 생각보다 복잡하고 이 복잡한 수식을 코드로 옮기다가 실수가 발생할 수도 있을 것 같아 검증된 오픈소스 라이브러리를 사용하기로 했습니다.

두 지점간 거리를 구하는 오픈소스 라이브리리를 검색해보니 다양하게 나옵니다 .여러 오픈소스 라이브러리 중 geolib, haversine 그리고 cheap-ruler 이 셋이 괜찮아 보였습니다. 셋 중 계산결과의 정확도 보다는 좋은 성능을 가진 라이브러리를 선택하기로 결정했습니다.

NodeJS는 다수 클라이언트의 요청을 제한된 쓰레드로 처리하기 때문에 Event Loop를 블록시킨다면 다른 클라이언트 요청도 블록되기 때문에 연산을 할 때 리소스를 많이 사용할 것 같은 라이브러리를 사용할 때 성능을 검증할 필요가 있습니다.

먼저 두 지점간거리를 구하는 NestJS HTTP API 3개를 만들어 보겠습니다. /distance1, /distance2, /distance3 3가지 path를 만들었고 /distance1은 haversine, /distance2는 geoLib 리고 /distance3은 CheapRuler를 사용합니다.

controller

import { Controller, Get, Query } from '@nestjs/common';
import { AppService } from './app.service';

class GetDistanceRequest {
  point1Lat: number;
  point1Lng: number;
  point2Lat: number;
  point2Lng: number;
}

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get('/distance1')
  getDistance1(@Query() query: GetDistanceRequest) {
    return this.appService.getDistanceByHaversine(
      { lat: query.point1Lat, lng: query.point1Lng },
      { lat: query.point2Lat, lng: query.point2Lng },
    );
  }

  @Get('/distance2')
  getDistance2(@Query() query: GetDistanceRequest) {
    return this.appService.getDistanceByGeolib(
      { lat: query.point1Lat, lng: query.point1Lng },
      { lat: query.point2Lat, lng: query.point2Lng },
    );
  }

  @Get('/distance3')
  getDistance3(@Query() query: GetDistanceRequest) {
    return this.appService.getDistanceByCheapRuler(
      { lat: query.point1Lat, lng: query.point1Lng },
      { lat: query.point2Lat, lng: query.point2Lng },
    );
  }
}

service

import { Injectable } from '@nestjs/common';
import * as geolib from 'geolib';
import * as haversine from 'haversine';
import * as CheapRuler from 'cheap-ruler';

export class Point {
  lat: number;
  lng: number;
}

@Injectable()
export class AppService {
  getDistanceByHaversine(point1: Point, point2: Point) {
    const distance = haversine(
      { latitude: point1.lat, longitude: point1.lng },
      { latitude: point2.lat, longitude: point2.lng },
      { unit: 'meter' },
    );

    return distance;
  }

  getDistanceByGeolib(point1: Point, point2: Point): number {
    const distance = geolib.getDistance(point1, point2);

    return distance;
  }

  getDistanceByCheapRuler(point1: Point, point2: Point): number {
    // eslint-disable-next-line @typescript-eslint/ban-ts-comment
    // @ts-expect-error
    const ruler = new CheapRuler(point1.lat, 'meters');
    const distance = ruler.distance(
      [point1.lng, point1.lat],
      [point2.lng, point2.lat],
    );

    return distance;
  }
}

앱을 실행시킨 후 3가지 경우를 테스트해 보니 각 결과는 아래와 같았습니다.

$ curl 'localhost:3000/distance1?point1Lat=37.497952&point1Lng=127.027619&point2Lat=37.508872&point2Lng=127.063186'
3364.237180878499

$ curl 'localhost:3000/distance2?point1Lat=37.497952&point1Lng=127.027619&point2Lat=37.508872&point2Lng=127.063186'                                       
3368

curl 'localhost:3000/distance3?point1Lat=37.497952&point1Lng=127.027619&point2Lat=37.508872&point2Lng=127.063186'
3370.5534698980437

두 지점은 사실 지하철 2호선 강남역과 삼성역이었습니다. 네이버 지도에서 둘 간 거리는 3.4km 인것으로 확인돼 계산 결과에서 셋의 라이브러리 모두 가까운 거리를 계산하는데 있어서 크게 오차를 가지지는 않을 것 같습니다.

autocannon

autocannon은 JavaScript로 만들어진 http API 부하테스트 툴입니다. 설치 후 cli 또는 Node.JS 라이브러리 형태로 사용가능합니다.

/distance1을 테스트 하기 위한 라이브러리로 형태의 코드는 다음과 같습니다.

import autocannon from "autocannon";

async function main() {
  const instance = autocannon({
    url: "http://localhost:3000/distance1?point1Lat=37.497952&point1Lng=127.027619&point2Lat=37.508872&point2Lng=127.063186",
  }, finishedBench);

  autocannon.track(instance, {
    renderProgressBar: true,
    renderLatencyTable: true,
    renderResultsTable: true,
  });

  function finishedBench (err: any, res: any) {
    console.log('finished bench', err, res)
  }
}

main();

결과는 아래와 같이 출력되는데요. 첫 번째 표는 request latency, 두 번째 표는 request volume 입니다.

request latency 표는 요청에 대한 응답속도라고 볼 수 있습니다. 2.5%는 빠른 상위 latency 2.5%를, 50%는 latency의 중앙값을, 97.5%는 느린 하위 latency 그리고 99%는 가장 느린 백분위의 latency 를 나타냅니다.

request volumn 표는 초당 전송된 요청의 수, 다운로드된 byte 수를 보여줍니다. 그리고 매 초당 한 번씩 샘플링 됩니다. 숫자가 높을 수록 더 많이 처리가능한, 높은 성능을 가진다고 볼 수 있습니다. request latency와 달리 1%는 가장 느린 경우를 나타내며 %가 올라갈수록 상위로 빨라지는 경우라고 볼 수 있습니다.

Running 10s test @ http://localhost:3000/distance1?point1Lat=37.497952&point1Lng=127.027619&point2Lat=37.508872&point2Lng=127.063186
10 connections


┌─────────┬──────┬──────┬───────┬──────┬────────┬─────────┬───────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg    │ Stdev   │ Max   │
├─────────┼──────┼──────┼───────┼──────┼────────┼─────────┼───────┤
│ Latency │ 0 ms │ 0 ms │ 2 ms  │ 3 ms │ 0.2 ms │ 0.62 ms │ 30 ms │
└─────────┴──────┴──────┴───────┴──────┴────────┴─────────┴───────┘
┌───────────┬─────────┬─────────┬─────────┬────────┬─────────┬────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%  │ Avg     │ Stdev  │ Min     │
├───────────┼─────────┼─────────┼─────────┼────────┼─────────┼────────┼─────────┤
│ Req/Sec   │ 11527   │ 11527   │ 14495   │ 15087  │ 14170.4 │ 1131.5 │ 11526   │
├───────────┼─────────┼─────────┼─────────┼────────┼─────────┼────────┼─────────┤
│ Bytes/Sec │ 2.82 MB │ 2.82 MB │ 3.55 MB │ 3.7 MB │ 3.47 MB │ 277 kB │ 2.82 MB │
└───────────┴─────────┴─────────┴─────────┴────────┴─────────┴────────┴─────────┘

Req/Bytes counts sampled once per second.
# of samples: 10

┌────────────┬──────────────┐
│ Percentile │ Latency (ms) │
├────────────┼──────────────┤
│ 0.001      │ 0            │
├────────────┼──────────────┤
│ 0.01       │ 0            │
├────────────┼──────────────┤
│ 0.1        │ 0            │
├────────────┼──────────────┤
│ 1          │ 0            │
├────────────┼──────────────┤
│ 2.5        │ 0            │
├────────────┼──────────────┤
│ 10         │ 0            │
├────────────┼──────────────┤
│ 25         │ 0            │
├────────────┼──────────────┤
│ 50         │ 0            │
├────────────┼──────────────┤
│ 75         │ 0            │
├────────────┼──────────────┤
│ 90         │ 1            │
├────────────┼──────────────┤
│ 97.5       │ 2            │
├────────────┼──────────────┤
│ 99         │ 3            │
├────────────┼──────────────┤
│ 99.9       │ 4            │
├────────────┼──────────────┤
│ 99.99      │ 12           │
├────────────┼──────────────┤
│ 99.999     │ 29           │
└────────────┴──────────────┘

142k requests in 10.01s, 34.7 MB read

위의 예에서는 요청파라미터를 쿼리스트링에 고정하여서 매번 요청하였는데, 매 번 요청 마다 값을 바꿔서 테스트 해 볼 수도 있습니다. 그렇게 하기 위해서는 아래 코드에서 볼 수 있듯이 requests에서 요청 전 쿼리스트링을 세팅하도록 설정하면 됩니다. 개인적으로 요청 파라미터를 요청마다 랜덤하게 바꿀 수 있다는 점 때문에 다른 툴에 비해 autocannon을 주로 사용합니다.

import autocannon from "autocannon";
import qs from "node:querystring";
import * as _ from "lodash";

function randomLat() {
    return _.random(36.0, 37.5)
}

function randonLng() {
    return _.random(125.5, 128.5)
}

async function main() {
  const instance = autocannon({
    url: "http://localhost:3000/distance1",
    requests: [
        {
            path: "",
            method: "GET",
            // @ts-ignore
            setupRequest: (request, context) => {
              const params = {
                point1Lat: randomLat(),
                point1Lng: randonLng(),
                point2Lat: randomLat(),
                point2Lng: randonLng(),
              };
              const queryString = qs.encode(params);
              
              request.path = "http://localhost:3000/distance1?" + queryString;
              return request;
            },
          },
    ]
}, finishedBench);

  autocannon.track(instance, {
    renderProgressBar: true,
    renderLatencyTable: true,
    renderResultsTable: true,
  });

  function finishedBench (err: any, res: any) {
    console.log('finished bench', err, res)
  }
}

main();

그 외에 얼마나 테스트를 지속할 것인지(duration), 몇 회 테스트할 것인지(amount), 동시 연결을 몇 개 할 것인지(connections), 초당 요청 수를 몇 회로 제한할 것인지(connectionRate) 등 세부 설정도 가능합니다.

예를 들어, 60초 동안 테스트를 하고 싶다면 아래와 같이 duration: 60을 추가해 주면 됩니다.

  const instance = autocannon({
    url: "http://localhost:3000/distance1",
    duration: 60, // 60초 동안 테스트
    requests: [
    ...

테스트 결과

/distance1, /distance2 그리고 /distance3을 60초 동안 위경도를 무작위로 바꿔가면서 테스트한 결과입니다.

1. /distance1

Running 60s test @ http://localhost:3000/distance1
10 connections


┌─────────┬──────┬──────┬───────┬───────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%   │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼───────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 5 ms  │ 10 ms │ 0.56 ms │ 4.14 ms │ 358 ms │
└─────────┴──────┴──────┴───────┴───────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 243     │ 307     │ 10775   │ 14207   │ 9183.5  │ 4386.86 │ 243     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 59.7 kB │ 75.4 kB │ 2.64 MB │ 3.49 MB │ 2.25 MB │ 1.08 MB │ 59.7 kB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.
# of samples: 60

┌────────────┬──────────────┐
│ Percentile │ Latency (ms) │
├────────────┼──────────────┤
│ 0.001      │ 0            │
├────────────┼──────────────┤
│ 0.01       │ 0            │
├────────────┼──────────────┤
│ 0.1        │ 0            │
├────────────┼──────────────┤
│ 1          │ 0            │
├────────────┼──────────────┤
│ 2.5        │ 0            │
├────────────┼──────────────┤
│ 10         │ 0            │
├────────────┼──────────────┤
│ 25         │ 0            │
├────────────┼──────────────┤
│ 50         │ 0            │
├────────────┼──────────────┤
│ 75         │ 0            │
├────────────┼──────────────┤
│ 90         │ 1            │
├────────────┼──────────────┤
│ 97.5       │ 5            │
├────────────┼──────────────┤
│ 99         │ 10           │
├────────────┼──────────────┤
│ 99.9       │ 44           │
├────────────┼──────────────┤
│ 99.99      │ 181          │
├────────────┼──────────────┤
│ 99.999     │ 330          │
└────────────┴──────────────┘

551k requests in 60.03s, 135 MB read

2. /distance2

Running 60s test @ http://localhost:3000/distance2
10 connections


┌─────────┬──────┬──────┬───────┬───────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%   │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼───────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 5 ms  │ 10 ms │ 0.54 ms │ 3.81 ms │ 289 ms │
└─────────┴──────┴──────┴───────┴───────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 252     │ 337     │ 11311   │ 14191   │ 9314.02 │ 4482.55 │ 252     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 61.9 kB │ 82.8 kB │ 2.78 MB │ 3.48 MB │ 2.29 MB │ 1.1 MB  │ 61.9 kB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.
# of samples: 60

┌────────────┬──────────────┐
│ Percentile │ Latency (ms) │
├────────────┼──────────────┤
│ 0.001      │ 0            │
├────────────┼──────────────┤
│ 0.01       │ 0            │
├────────────┼──────────────┤
│ 0.1        │ 0            │
├────────────┼──────────────┤
│ 1          │ 0            │
├────────────┼──────────────┤
│ 2.5        │ 0            │
├────────────┼──────────────┤
│ 10         │ 0            │
├────────────┼──────────────┤
│ 25         │ 0            │
├────────────┼──────────────┤
│ 50         │ 0            │
├────────────┼──────────────┤
│ 75         │ 0            │
├────────────┼──────────────┤
│ 90         │ 1            │
├────────────┼──────────────┤
│ 97.5       │ 5            │
├────────────┼──────────────┤
│ 99         │ 10           │
├────────────┼──────────────┤
│ 99.9       │ 45           │
├────────────┼──────────────┤
│ 99.99      │ 164          │
├────────────┼──────────────┤
│ 99.999     │ 276          │
└────────────┴──────────────┘

559k requests in 60.03s, 137 MB read

3. /distance3

Running 60s test @ http://localhost:3000/distance3
10 connections


┌─────────┬──────┬──────┬───────┬───────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%   │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼───────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 5 ms  │ 10 ms │ 0.55 ms │ 3.67 ms │ 290 ms │
└─────────┴──────┴──────┴───────┴───────┴─────────┴─────────┴────────┘
┌───────────┬───────┬─────────┬─────────┬────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%    │ 2.5%    │ 50%     │ 97.5%  │ Avg     │ Stdev   │ Min     │
├───────────┼───────┼─────────┼─────────┼────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 289   │ 293     │ 11543   │ 14255  │ 9292.22 │ 4581.79 │ 289     │
├───────────┼───────┼─────────┼─────────┼────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 71 kB │ 71.9 kB │ 2.83 MB │ 3.5 MB │ 2.28 MB │ 1.12 MB │ 70.9 kB │
└───────────┴───────┴─────────┴─────────┴────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.
# of samples: 60

┌────────────┬──────────────┐
│ Percentile │ Latency (ms) │
├────────────┼──────────────┤
│ 0.001      │ 0            │
├────────────┼──────────────┤
│ 0.01       │ 0            │
├────────────┼──────────────┤
│ 0.1        │ 0            │
├────────────┼──────────────┤
│ 1          │ 0            │
├────────────┼──────────────┤
│ 2.5        │ 0            │
├────────────┼──────────────┤
│ 10         │ 0            │
├────────────┼──────────────┤
│ 25         │ 0            │
├────────────┼──────────────┤
│ 50         │ 0            │
├────────────┼──────────────┤
│ 75         │ 0            │
├────────────┼──────────────┤
│ 90         │ 1            │
├────────────┼──────────────┤
│ 97.5       │ 5            │
├────────────┼──────────────┤
│ 99         │ 10           │
├────────────┼──────────────┤
│ 99.9       │ 45           │
├────────────┼──────────────┤
│ 99.99      │ 142          │
├────────────┼──────────────┤
│ 99.999     │ 254          │
└────────────┴──────────────┘

558k requests in 60.03s, 137 MB read

60초 동안 1, 2, 3 경우 각 551k, 559k, 558k가 처리되었고 request latency는 평균 0.56ms, 0.54ms, 0.55ms로 큰 차이가 없습니다. 결론적으로 3 개의 라이브러리 모두 크게 성능의 차이는 없는 것 같습니다.

그렇다면 오픈소스 커뮤니티의 크기와 활동정도, 정확도, 사용성 등에 따라 선호하는 것을 선택하면 될 것 같습니다.

결론

3가지 오픈소스 라이브러리의 처리 속도를 비교하기 위해 NodeJS 부하테스트 툴인 autocannon을 사용해보았고 각 요청마다 파라미터를 세팅하는 방법, 세부적인 테스트 옵션, 결과 테이블에 대한 내용을 소개해 드렸습니다.

기회가 된다면 autocannon을 한 번 쯤은 사용해보시길 추천드립니다.

쉽고 빠른 NodeJS 부하테스트 툴, autocannon was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요 직방 DataManagement팀 DBA James 입니다.

AWS RDS 모니터링을 위한 다양한 솔루션들이 존재하지만 그중 가장 기본이라고 할 수 있는 CloudWatch를 활용한 모니터링 이야기를 해보려 합니다.
(aurora RDS의 경우로 이야기하겠습니다)

AWS RDS Console에서 RDS의 Status 모니터링을 해오셨던 분이라면 Monitoring 탭에서 제공하는 CloudWatch의 지표들을 많이 접해오셨을 것이라고 생각합니다.

일반적으로 RDS Monitoring에서 기본적으로 제공되는 CloudWatch 지표는 다음과 같습니다.

다양한 지표들을 제공해 주지만 모니터링을 하면서 우리는 이렇게 많은 지표를 모두 볼 수도 없고, 항상 필요하지는 않습니다.

다양한 지표의 홍수 속에서 필요한 정보를 선별하고 선택과 집중이 필요한 부분이죠.

ChatGPT에게 Aurora RDS를 모니터링하는데 중요한 지표를 물어보았습니다.

100가지 지표 중 내가 원하는 중요한 지표를 보기 위해서는 열심히 마우스 휠을 굴리거나 지표명을 검색하여 원하는 정보의 확인이 가능합니다.

DB 모니터링 시, 대부분의 문제는 복합적인 원인으로 인해 발생하는 경우가 많기 때문에 하나의 지표로는 상태 파악이 쉽지 않습니다.

하지만 안타깝게도 AWS RDS Console에서 제공하는 CloudWatch에서는 내가 원하는 지표들을 한눈에 확인이 불가능하고 레이아웃 편집이 불가능하기 때문에 모니터링으로서의 기능은 떨어진다고 할 수 있습니다.

그렇다면 내가 필요한 지표의 정보만 한눈에 볼 수 있는 조금 더 간편하게 모니터링을 할 수 있게 만들어주는 나만의 Dashboard를 만들어 보겠습니다.

나만의 Dashboard 만들기

CloudWatch Dashboard 자체를 만드는 법은 어렵지 않습니다.

다시 한번 ChatGPT에게 물어보았습니다.

위 방법을 따라서 Dashboard를 생성하고 ChatGPT가 추천해 준 중요 지표를 추가해 보겠습니다.

다수의 DB를 한눈에 모니터링이 가능한 나만의 Dashboard 가 완성되었습니다.

끝! 이라고 하기에는 지표의 그래프만 봐서 현재 상태가 정상인지 혹은 주의 깊게 지켜봐야 하는 상태인지 파악이 어렵지 않으신가요?

이제는 좀 더 멀리서 봐도 상태를 파악할 수 있는 Dashboard를 만들기 위한 추가 설정을 진행해 보겠습니다.

첫 번째, Horizontal thresholds(가로 주석/임계값) 추가입니다.

Horizontal thresholds 추가는 가로주석을 통해 멀리서 Dashboard를 확인할 때 에도 경고 또는 위험 수준에 근접한 지 확인을 용이하게 하기 위한 기능입니다.

설정을 위한 방법은 대상 지표의 [Edit graph] 화면으로 이동 후 [Options] 탭에서 [Add Horizontal annotations] 버튼을 클릭하여 항목을 추가/설정해줍니다.

지표의 변화가 현재 정상적인지, 가로 주석에 근접한 주의가 필요한 상황인지 파악이 용이해진 것을 확인할 수 있습니다.

두 번째, Anomaly detection(이상 탐지) 추가입니다.

CloudWatch Anomaly detection(이상 탐지)이란?

지표에 대해 ‘이상 탐지’를 사용 설정하면 CloudWatch는 통계 및 기계 학습 알고리즘을 적용합니다. 이러한 알고리즘은 시스템 및 애플리케이션의 지표를 지속적으로 분석하고, 정상 기준을 결정하며, 최소한의 사용자 개입으로 이상을 나타냅니다.

알고리즘은 이상 탐지 모델을 생성합니다. 모델은 정상 지표 동작을 나타내는 예상 값의 범위를 생성합니다.

AWS Document 내용 발췌

간단하게 얘기하면, 지표의 CloudWatch 지표를 분석하여 예상 값의 범위를 밴드로 표시하고, 지표의 실제 값이 이 밴드를 초과하면 빨간색으로 표시해주는 기능입니다.

적용을 통해 확인해 보겠습니다. 적용 순서를 이미지로 나열해 보겠습니다.

여기까지가 지표에 anomaly detection을 적용 완료한 상태로 이어서 Dashboard에도 적용 완료된 지표를 등록하면 작업이 완료됩니다.

마치며

지금까지 나만의 Dashboard의 생성과 조금 더 편안한 모니터링을 위한 가로 주석과 이상탐지 두 가지 모니터링 보조 설정을 적용해 보았습니다.

물론 다양한 모니터링 솔루션이 많이 나와있지만, 자주 이용하는 AWS Console에서 제공하는 기능을 활용한 모니터링이 필요하신 분들에게 조금이라도 도움이 되었기를 바라며 글을 마치도록 하겠습니다.
긴 글을 읽어주셔서 감사합니다.

참고

• https://chat.openai.com/
• https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html

RDS 모니터링을 위한 나만의 CloudWatch Dashboard 만들기 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we think about monitoring, the first thing that comes to our minds are logs and metrics. We oftentimes underestimate traces because of the extra work we need to set up traces, whereas metrics and logs on the other hand are often automatically provided when using any cloud platform.

The combination of metrics, logs, traces, and alarms is known as observability. Different from monitoring, which only tells us that there is something wrong within our system, for example with metrics, the goal of observability is to correlate the data collected trying to help us identify what, where, and why something is wrong.

In this blog post, we will show you how to collect traces by setting up a simple observability stack with node js and typescript. Although this is not the focus of this post, Grafana also works perfectly integrating with external metrics and logs you must already have, and we encourage you to take a look at their other integrations.

Prerequisites

We must install Grafana and Loki so we can add telemetry to our test application. For that reason, you should have the following tools installed. Please follow their respective installation guide.

• NodeJs ≥ 18
• Docker for Desktop
  (Kubernetes is included but you must enable it)
• kubectl
• Helm

Setting Helm Repositories and Containers

Helm is a package manager that will help us set up our Kubernetes environment with minimal effort. After installing Helm, you can add Grafana and Tempo repositories with the following commands.

#adding Grafana charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

Installing Tempo

For this example, we will use the standard configuration of tempo, but if you wish to customize any values please check tempo helm documentation and examples. You can easily customize your distribution by creating a YAML file and applying it with Helm.

helm upgrade --install tempo grafana/tempo

Tempo supports many receivers and protocols and for the purpose of this tutorial, we will use OTLP receiver with HTTP protocol (port 4318). If you are interested in other receivers take a look o Tempo's documentation.

Installing Grafana

In order to install Grafana we need to configure our Helm template to add our tempo container as a data source, so we can visualize our traces on Grafana. For more information on Grafana customization please check Helm documentation.

• Add the following content to a file called grafana-helm.yaml

env:
  GF_AUTH_ANONYMOUS_ENABLED: true
  GF_AUTH_ANONYMOUS_ORG_ROLE: 'Admin'
  GF_AUTH_DISABLE_LOGIN_FORM: true

datasources:
  datasources.yaml:
    apiVersion: 1

    datasources:
      - name: Tempo
        type: tempo
        access: proxy
        orgId: 1
        url: http://tempo:3100
        basicAuth: false
        isDefault: true
        version: 1
        editable: false
        apiVersion: 1
        uid: tempo

• Install Grafana with the YAML file we just created

helm upgrade -f grafana-helm.yaml --install grafana grafana/grafana

Configure Nginx-controller

We will need to access both our Grafana and our tempo services so therefore we need to expose the service with Nginx-controller and k8 ingress, so we can use it in our test application.

1. Install Nginx-controller

helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

2. Creating Ingress for the services

• Save the following content to a file called ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: grafana
  namespace: default
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  ingressClassName: nginx
  rules:
    - http:
        paths:
          - pathType: Prefix
            backend:
              service:
                name: grafana
                port:
                  number: 80
            path: /
    - http:
        paths:
          - pathType: Prefix
            backend:
              service:
                name: tempo
                port:
                  number: 4318
            path: /v1/traces

• Create ingress with kubectl

kubectl create -f ingress.yaml

Testing Grafana

After completing the setup you will be able to access both services in the following addresses. If you wish to use a host instead you can change your ingress file as needed. Check K8 documentation for more details.

Grafana: http://localhost

You can also check all the Kubernetes resources we created with the following command:

#services and pods
kubectl get all -A

#for our custom ingress
kubectl get ingress

Other Observaibility Integrations

This is not the main focus of this tutorial, but if you wish you can also use metrics, logs, and alerts with Grafana. In order to do that you can use Prometheus for metrics, and Loki for logs for example. The installation process can be done in the same way we did with Helm. For more information check Prometheus Helm documentation and Loki Helm documentation.

Setting Up OpenTelemetry with NodsJs

We want to add traces to any NodeJs API, so you can actually use your own project if you wish. If you don't already have a project you can use any open-source sample available on GitHub, like for example the cats API on NestJs repository:

https://github.com/nestjs/nest/tree/master/sample/10-fastify

Adding OpenTelemetry Dependencies

Add the following dependencies to your project:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-http @opentelemetry/sdk-node @opentelemetry/sdk-trace-node

Adding Tracer and Auto-instrumentation

On your src folder add a tracer.ts file with the following content:

import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { NodeSDK } from '@opentelemetry/sdk-node';
import {
  BasicTracerProvider,
  ConsoleSpanExporter,
  SimpleSpanProcessor,
} from '@opentelemetry/sdk-trace-node';
import { Resource } from '@opentelemetry/resources';
import { SemanticResourceAttributes } from '@opentelemetry/semantic-conventions';

class Tracer {
  private sdk: NodeSDK | null = null;

  // url is optional and can be omitted - default is http://localhost:4318/v1/traces
  private exporter = new OTLPTraceExporter({ url: "http://localhost/v1/traces"});

  private provider = new BasicTracerProvider({
    resource: new Resource({
      [SemanticResourceAttributes.SERVICE_NAME]: 'DEMO-APP',
    }),
  });

  public init() {
    try {
      // export spans to console (useful for debugging)
      this.provider.addSpanProcessor(
        new SimpleSpanProcessor(new ConsoleSpanExporter()),
      );

      // export spans to opentelemetry collector
      this.provider.addSpanProcessor(new SimpleSpanProcessor(this.exporter));
      this.provider.register();

      this.sdk = new NodeSDK({
        traceExporter: this.exporter,
        instrumentations: [
          getNodeAutoInstrumentations({
            // Lets disable fs for now, otherwise we cannot see the traces we want,
            // You can disable or enable instrumentation as needed
            '@opentelemetry/instrumentation-fs': { enabled: false },
          }),
        ],
      });

      this.sdk.start();

      console.info('The tracer has been initialized');
    } catch (e) {
      console.error('Failed to initialize the tracer', e);
    }
  }
}

export default new Tracer();

Initialize our Tracer

Make sure you initialize your tracer before your server starts, otherwise, auto-instrumentation won't work properly. On your main.ts file (or your entry point class) add the following code.

import tracer from './tracer'
tracer.init()

//Other imports
...

async function bootstrap() {
...
}

bootstrap()

Testing our Telemetry

After running your application let's use some of the APIs so we can generate some traces. For the cat API example, you can run one of the commands below.

# POST cats
curl -X POST http://localhost:3000/cats -H "Content-Type: application/json" -d '{
    "name":"test",
    "age": 18,
    "breed": "test"
}'

# GET cats
curl  http://localhost:3000/cats

Check Telemetry on Grafana

After collecting some data, let's check our traces on Grafana. On the Explore menu, Tempo will be selected automatically, but if not, select Tempo in the data source drop-down list.

On the query options, select search and input the name of the service we configured in our tracer.ts file (DEMO-APP). You will be able to see all the instrumentation collected with auto instrumentation.

Note that auto instrumentation collects different information for each library. For example, if you check our HTTP spans you will be able to see many of our request parameters. Now, if we were using MySQL, we would be able to see up to the query executed for that specific trace. For each instrumentation, check their respective documentation specifically.

If you are curious about which libraries are instrumented automatically, check the documentation on the @opentelemetry/auto-instrumentations-node npm page.

Adding Manual Span

For this tutorial, we've only touched the auto-instrumentation setup, and even though this alone helps us to see the path our users take inside of our system, it does not always provide us with all the information we need.

OpenTelemetry also allows us to define our own custom spans and add them to our traces. This is useful for example when you need to add business information to the telemetry.

You can play around with your own custom spans by adding them to your API code. Follow the documentation for more information.

Extra (Telemetry Propagation)

Trace opens a whole lot of possibilities for us. However, we only saw a small part of it in this tutorial. OpenTelemetry also works really well with distributed systems and provides us with tools to integrate APIs together in the same trace. This is extremely useful when working with microservice architecture, where multiple APIs are triggered for a single user action.

In order to connect microservices together, you should configure OpenTelemetry to send and receive traces to and from other APIs. You can easily achieve that using custom headers and openTelemetry node SDK.

OpenTelemetry provides us with some examples of how to set up our API to communicate with other services. Check the documentation on propagation for more details.

Tracing NodeJs Applications with OpenTelemetry was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요. 호갱노노 BE 팀의 오스틴입니다.

이번 포스팅에서는 AWS lambda@edge를 활용하여 이미지에 워터마킹 하는방법에 대해서 이야기해보겠습니다.

이미지 워터마킹을 다루기에 앞서 일반적으로 서비스에서는 이미지를 어떤식으로 저장하고 사용하는지를 먼저 다루어 보겠습니다.

이미지 다루기

우리가 접하는 많은 서비스에서 이미지는 모두 온라인상 어딘가에 저장되어 있고, 클라이언트가 요청할 때마다 이미지를 전송합니다.

아주 단순한 시스템에서는 서버내 폴더 어딘가에 저장해 놓았다가 내려주기도 하고, Web Server 와 WAS 가 분리된 구조에서는 정적인 파일(html, js, image)들을 Web Server 에 저장하는 방식으로 서버의 부하를 분산시키고 캐시를 사용하기도 합니다.

AWS 를 사용하는 경우에는 S3 를 image 서버처럼 활용하기도 합니다. 이와 같은 경우에는 image 를 서버로 업로드하는게 아니라, presigned URL 을 활용하여 클라이언트에서 S3로 직접 이미지를 upload 하는 방법을 주로 사용합니다. 다음 그림은 presigned URL 을 생성하는 람다를 활용한 s3 upload 방법입니다.

CloudFront 와 Lambda@Edge

저희 호갱노노에서는 AWS 를 기본 서버 환경으로 사용하고있고 S3 에 이미지를 저장하고 있습니다.

그리고, 저장된 이미지는 AWS CloudFront 를 통해 사용자에게 전달됩니다. 다음은 CloudFront (이후 CF) 에 대한 AWS 의 설명입니다.

Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다.

그럼 이제 S3 에 있는 이미지를 워터마킹해서 내려주는 방법을 알아보겠습니다.

저희는 CloudFront 를 통해 내려주는 이미지에 워터마킹을 표시하기 위해서 lambda@edge 를 사용하였습니다.

다음은 lambda@edge 에 대한 AWS 에 설명입니다.

Lambda@Edge를 사용하면 Node.js 및 Python Lambda 함수를 실행하여 CloudFront가 제공하는 콘텐츠를 사용자 지정하여 AWS 위치의 함수를 최종 사용자와 더 가깝게 실행할 수 있습니다. 이 함수는 서버 프로비저닝 또는 관리 없이 CloudFront 이벤트에 응답하여 실행됩니다. Lambda 함수를 사용하여 CloudFront 요청 및 응답을 다음과 같이 변경할 수 있습니다.

그러니까 CF 에 들어오는 요청 전후로 람다함수(에지함수)를 이용하여 req/res 를 변경할 수 있습니다. 그리고, 워터마킹은 바로 이 람다함수를 작성하여 실행합니다.

워터 마킹을 위한 Lambda@Edge 설정

• lambda 페이지로 이동 후 Region을 Virginia로 바꿉니다. 그리고 Create function을 클릭합니다. (lambda edge는 Virginia에서만 사용 가능)

• 필요한 내용을 채우고 Create Function 을 클릭합니다. 내용은 이름만 적어도 됩니다. (기존에 사용하던 role을 그대로 사용하고 싶다면 Execution role에서 Use an existing role을 선택합니다.)

• Configuration > Permissions에서 해당 Role을 클릭합니다.

• 아래 화면에서 Policy 왼쪽 +를 누르면 json이 나오고 Edit을 눌러 아래와 같이 적어줍니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "logs:CreateLogGroup",
            "Resource": "{resource arn을 적어주세요}"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "lambda:GetFunction",
                "lambda:EnableReplication*",
                "cloudfront:UpdateDistribution",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams"
            ],
            "Resource": "*"
        }
    ]
}

• Trust relationships 탭으로 이동해서 아래와 같이 수정합니다.
  Service 목록에 “edgelambda.amazonaws.com”이 꼭 있어야 합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "lambda.amazonaws.com",
                    "edgelambda.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

• 코드를 작성합니다.코드가 너무 크다면 업로드 할 수 있습니다.

예제 함수들 및 response 생성 및 업데이트 을 확인할 수 있습니다.

다음은 실제 코드중 워터마킹하는 부분만 발췌하였습니다.

/**
 * watermark 생성 로직
**/
let resizedWaterMarkImage = sharp('watermark.png').rotate();
const width = imageMetaData.width;
const heigth = imageMetaData.height;

// ....
// 원본이미지에 맞게 워터마크의 크기를 조절한 후,
// ....
resizedWaterMarkImage = await resizedWaterMarkImage.resize(waterWidth, waterHeight, { fit: 'inside' }).toBuffer();
await zigbangImage.composite([{ input: resizedWaterMarkImage, gravity: 'center' }]);

• 그리고, 테스트를 해봅니다. (이벤트 함수 예제)
  Test할 때 생기는 log는 확인이 가능합니다. CloudWatch Log group에 없다면 생성하면 됩니다.

• 새 버전을 publish 합니다.

• publish 한 람다의 ARN을 복사 후 CF 에 붙입니다.
  behavior 까지 새롭게 만드려면 Create behavior 를 하고 그게 아니라면 해당 Behavior를 수정합니다.

• 적용시 캐시 때문에 시간이 다소 소요될 수 있습니다. 그럼, 다음과 같이 호갱노노 이미지가 워터마크로 이미지에 표시됩니다.

결과물

이상으로 S3 에 저장된 이미지를 CloudFront 의 lambda@edge 를 통해서 워터마킹 하는 방법에 대해서 알아봤습니다.

확실히 AWS 를 활용하면 많은 노력 없이도 쉽고 편리하게 서버에서 이미지를 다룰 수 있다는 점이 참 매력적인거 같습니다.

감사합니다.

lambda@edge를 활용한 이미지 워터마킹 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

코드의 가독성은 매우 중요한 문제입니다.

클린코드로 대표되는 코드 작성 지침에는 다양한 제안이 있습니다. 변수 이름을 어떻게 짓는 것이 좋은가부터 시작해서, 전체적인 코드의 구성과 분리등의 컨벤션까지 커버합니다. 이 모든것이 읽기좋은 코드를 작성하기 위한 제안이고, 그것만으로도 책 한권은 우스울정도로 얘기를 쏟아낼 수 있습니다

하지만 이러한 클린코드는 어디까지나 텍스트 그 자체에만 집중합니다. IDE가 지원하는 여러 강력한 개인화는 다루지 않죠. 때문에 클린코드 지침과 별개로, 각자의 개발환경에서 코드의 가독성을 높이기 위한 다양한 개인화 시도는 해 볼 가치가 있습니다.

사람의 눈은 패턴인식기입니다. 때문에 텍스트 그 자체보다, 색과 모양등의 패턴 등의 다양한 시각 효과를 코드에 적용하면 전체적인 가독성이 훨씬 좋아집니다.

코드 작성과 코드 읽기의 비중은 1:10정도입니다. 개발자들은 대부분의 시간을 코드를 읽는데 보냅니다. 가독성에 신경쓰는건 당연한 일이죠.

에디터 설정

ide가 지원하는 여러가지 에디터 설정을 바꾸어서, 가독성을 끌어올리는 방법을 알아보겠습니다.

찾기 결과 하이라이트

특정 단어 찾기시 눈에 띄게 좀 더 밝기를 올리거나, 사각박스를 치거나 하는 것을 저는 좀 더 선호합니다. 별다른 설정 없이도 부분의 컬러 스킴들이 이러한 텍스트 찾기 결과를 눈에 띄게 하이라이트 하지만, 코드를 읽는게 아니라 빠르게 눈으로 훑어가면서 단번에 눈에 뜨이게 하는편이 저는 더 좋더라구요.

코드 읽기의 대부분은 텍스트 또는 변수를 찾아가면서 뇌내 디버깅 내지는 변수 변화 흐름 추적이니, 이런식으로 밝게 시각적 꼬리표를 달아두는 것이 여러가지로 편리합니다.

커서가 위치한 변수 하이라이트

매번 텍스트 찾기를 할 수만은 없는 노릇입니다. 요즈음의 ide는 커서가 위치한 변수를 하이라이트해주는 기능이 있죠. 그 하이라이트를 좀 더 하이라이트답게 바꾸어 봅시다.

위와 같이 설정하면, 커서를 올린것만으로도 변수의 흐름이 확연이 눈에 보이게 됩니다. 특히 쓰기가 일어나는 경우는 다른 색으로 표현가능해서 어떤 시점에 읽기쓰기가 일어나는지 단번에 알 수 있죠. 스크롤이 넘어가도 커서는 해당 변수 밑에 계속 있기에, 드륵드륵 코드를 내려가면서 전체 흐름을 보기에도 편합니다.

저같은 경우에는 위와같이 파스텔톤 형광 계열 빨강과 노랑으로 해두었습니다. 각자의 컬러 스킴에 맞추어 눈에 잘 띄게 해두면 코드 읽기가 한결 쉬워질겁니다.

커서가 위치한 라인 하이라이트

가끔은 변수가 아니라 라인 바이 라인으로 모든 코드를 읽어내려나가야 할 때가 있습니다.

기본적으로도 커서가 위치한 라인이 하이라이트가 되긴하지만…

조금 더 눈에 띄면 좋겠단 생각을 지울수가 없죠.

위와같이 테마에서 자주 쓰이는 색에서 좀 벗어난 색으로 포인트를 주면, 내가 지금 어디를 읽고 있었는지 한번에 화면내에서 볼 수 있습니다.

함수 분리선

이상적으로는, 한 파일안에 손으로 셀 수 있을정도의 갯수의 함수가 있고, 많아야 1000 라인정도의 코드만 있으면 좋겠지만, 실제로는 그러지 않을때가 많습니다.

인덴트가 들쭉날쭉하면서 어디서부터 어디까지가 이전 함수의 범위였는지 한번에 알기도 어려울때가 많죠.

ide가 감지하는 범위 내에서긴하지만, 함수 사이마다 분리선을 그어줄 수 있습니다.

수없이 많은 함수들 사이를 공백으로 다다다다 구별하는것도 좋지만, 그 전에 ide가 지원하는 구분선을 먼저 시도해보는것도 좋을거 같습니다.

시맨틱 하이라이팅

이 기능은 제가 제일 좋아하는 기능중 하나입니다. 변수마다 서로 다른 임의의 색상을 부여하는 기능이죠.

기본적으로는 이 기능이 off 상태일텐데… 그렇게되면 아래처럼 보입니다.

코드들이 다소 플랫해보이죠. 여기서… 해당 옵션을 키게 되면 각 변수별로 색상이 부여됩니다. 이제 여기서 취향에 따라서 색상을 더 부여주면 아래처럼 좀 더 구별이 쉬워집니다.

위와 같이 ide의 설정만으로도 코드의 시각적 패턴화가 상당히 이루어집니다. 하지만 아래의 플러그인까지 설치하면 훨씬 더 코드 읽기가 쾌적해지는걸 경험했습니다.

플러그인

인덴트 레인보우

코드 작업을 하다보면, 그러지 않으려고 해도 들여쓰기 단계가 깊어지는 경우가 있습니다.

ide 의 기본 지원 기능으로, 들여쓰기 단계마다 수직선을 그어주지만, 아무래도 역부족인점이 있습니다. 특히 동일 들여쓰기 단계가 길어지는 코드의 경우, 까딱하다가는 눈으로 쫓던 코드 스코프를 놓치기 십상이죠.

하지만 이처럼 시각적으로 강조를 하게되면, 훨씬 보기 편해지는걸 느낍니다.

Indent Rainbow - IntelliJ IDEs Plugin | Marketplace

여러가지 방법을 동원해서 코드의 가독성뿐만 아니라, 시각적 강조와 효과로 코드를 패턴처럼 눈에 보이게끔 하는 방법들을 알아보았습니다. 익숙해지면 코드를 변수와 선언의 연속인 글자들이 아니라, 색과 도형으로, 읽는게 아니라 흘깃 보고 바로 알아챌 수 있게 되어 훨씬 생산성이 높아지는걸 경험할 수 있습니다.

코드 가독성을 높이는 젯브레인 계열 IDE 에디터 세팅과 플러그인 추천 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요 BE APT 팀의 Jin 입니다.

개발자라면 누구나 한번 쯤 클린코드에 대해 들어본 적 있지 않으신가요?우리 모두 클린코드의 지침을 따르다 보면 읽기 쉬운 코드가 작성된다고 잘 알고 있습니다.

그렇다면 클린코드의 가독성이 왜 좋은지 생각해보신적이 있나요?저는 이번 포스팅에서 클린코드를 다른 시각으로 바라보고 개발자가 클린 코드를 왜 쉽게 이해하는지에 대해 얘기하려 합니다.

(참고로 제 얘기는 대부분 “프로그래머의 뇌” 라는 책을 바탕으로 합니다.)

먼저 본격적으로 시작하기에 앞서 우리는 언제 코드가 읽기 쉽다, 이해하기 쉽다고 느낄까요? 우리는 코드를 읽을 때 머릿속에 혼란(코드가 하는 일, 작동방식, 의미의 혼란)이 없을 때 코드를 이해하기 쉽다고 느낍니다.

그러면 우리는 코드를 읽을 때 도대체 어떤 혼란이 우리 뇌 속에서는 일어날까요?

코드를 읽을 때 일어나는 3가지 혼란

1. 지식의 부족

아래 코드는 APL이라는 언어로 된 코드로 숫자 n을 이진수 표현으로 변경하는 코드입니다.

2 2 2 2 2 T N

코드를 읽으시면서 어떠셨나요? 혼란스럽지 않으셨나요? 여기서 우리가 혼란스러웠던 이유는 T에 대한 지식이 없기 때문입니다.

2. 정보의 부족

아래의 코드는 자바로 작성된 코드입니다.

public class BinaryCalculator {

  public static void main(Integer n) {
    System.out.println(Integer.toBinaryString(n));
  }
  
}

이번엔 코드를 읽으시면서 어떠셨나요? 이번에도 혼란스러웠나요? 이번 코드는 자바 언어 전문가가 아니어도 어떤 일을 하는지 메서드 이름으로 유추할 수는 있었을 거라 예상합니다. 하지만 toBinaryString() 메서드 내부적으로 어떻게 작동하는지 모른다면 이코드도 혼란스러울 수 있습니다. 그 혼란의 원인은 toBinaryString() 메서드에 관한 정보가 부족하다는 점입니다.

3. 처리 능력의 부족

아래 코드는 베이직으로 작성된 코드입니다.

LET N2 = ABS (INT(N))
LET B$ = ""
FOR N1 = N2 TO 0 step 0
  LET N2 = INT(N1/2)
  LET B$ = STR$(N1- N2 * 2) + B$
  LET N1 = N2
NEXT N1
PRINT B$

이번엔 코드를 읽으시면서 어떠셨나요? 이번에도 혼란스러웠나요? 이번 코드에서는 변수 이름이나 연산자를 통해 무슨 일하는지 유추가 가능합니다. 하지만 코드의 각각의 단계가 실행되는 것을 한눈에 파악하기 어려워 혼란스러울 수 있습니다. 이번 혼란은 처리 능력이 부족하기 때문입니다. 이런 코드는 이해하기 위해서는 변수들의 중간값을 따로 적거나 하는 등의 노력이 필요할 수 있기 때문입니다.

이제까지 우리 머릿속에서 일어나는 혼란들에 대해 알아봤습니다. 그럼 이번엔 우리가 프로그래밍을 할 때 우리 두뇌에 어떤 일이 일어나는지 알아보겠습니다.

코딩을 할 때 우리 두뇌는 크게 3가지 기억과 관련된 영역이 사용됩니다.

1. 장기 기억 공간(long-term memory, LTM)

• 오랜 시간에 걸쳐 얻은 정보를 저장하는 장소입니다.
• 컴퓨터의 하드디스크 드라이브와 비슷합니다.
• 여기에 저장된 기억은 아주 오랫동안 보관됩니다.
• 이진 검색과 같은 추상적 알고리즘, 프로그래밍 언어 문법, 특정 언어의 키워드, 자전거 타는 법, 신발 끈을 묶는 법 등이 여기에 저장되어 있습니다.
• 앞서 얘기한 혼란 중 지식이 없다는 것은 LTM에 해당 내용이 없다는 뜻입니다.

2. 단기 기억 공간(short-term memory, STM)

• 들어오는 정보를 잠시 보관하는 곳입니다.
• 최대 공간이 12개를 넘지 않습니다. (2–6 사이로 추정)
• 우리의 두뇌는 정보들을 청크(chunk) 라는 묶음으로 나누려고하고 LTM과 협업을 통해 STM의 공간 제약을 극복합니다. (아래에서 좀 더 자세히 설명하겠습니다.)
• 특정 코드에서의 키워드 , 변수명, 자료구조 등이 여기에 저장 됩니다.
• 컴퓨터의 캐시나 메인 메모리와 비슷합니다.
• 앞서 얘기한 혼란 중 정보가 부족하다 것은 STM에 해당 내용이 없다는 뜻입니다.

우리의 뇌가 청킹과 LTM과의 협업을 통해 공간의 제약을 극복하는 방법에 대해 좀 더 자세히 설명해 보겠습니다.

다음 문장을 5초간 본 후 어떤 문장인지 기억해 보세요

abk mrtpi gbar

어떠셨나요? 기억하기 쉬웠나요?

그럼 다음 문장을 똑같이 5초간 보고 기억해 보세요

cat loves cake

어떠셨나요? 훨씬 쉽지 않았나요? 그 이유는 LTM에 세 단어의 지식이 있어서 한 단위로 묶을 수 있기 때문입니다. 하지만 abk mrtpi gbar와 같은 문장은 각 단어를 기억해야 하고 STM 한도를 넘어섰기 때문에 어렵습니다

3. 작업 기억 공간(working memory)

• 실제 LTM, STM 의 정보를 가지고 와서 정보를 처리하는 곳 입니다. (생각, 아이디어, 해결책 등이 여기서 만들어집니다.)
• 컴퓨터의 프로세서와 비슷합니다.
• STM과 동일하게 2–6까지 항목만 저장할 수 있고 청킹을 사용해서 더 많은 정보를 처리할 수 있습니다.
• 앞서 얘기한 혼란 중 처리 능력이 부족하다는 것은 작업 기억 공간이 과부하 상태라는 뜻입니다.

그럼 어떻게 이런 공간들이 서로 상호 작용해 우리는 코드를 이해하게 되는 걸까요? 예를 하나 들어보겠습니다. 제가 몇 달 전 만든 코드에 버그가 생겨 코드를 분석해야 하는 상황입니다. 버그는 삽입정렬을 구현하는 부분에서 발생했다고 가정하겠습니다.

이때 코드를 분석하면 제 머릿속에서는

• 코드를 읽으면서 분석하는 내용, 버그 리포트 내용 등이 STM에 저장됩니다.
• 몇 개월 전에 구현한 내용, 삽입정렬에 관한 내용, 삽입정렬 구현 시 흔히 발생한 오류나 겪었던 경험, 잘 알려진 해결법 등을 LTM에서 가져오려고 합니다.
• 관련된 LTM과 STM에 있는 내용들이 working memory에 들어오게 되고 버그에 대한 해결법을 도출하게 됩니다.

그럼 이제 까지 배운 내용을 드디어 클린코드에 적용 해봅시다.

1. 함수의 인수를 최대한 작게 유지하라!

함수의 인수는 작을수록 좋다는 클린코드의 지침입니다.

앞에 말씀드렸다시피 우리의 작업 기억 공간의 용량은 6개 정도로 작아서 많은 매개변수 리스트를 기억하기에는 무리가 있습니다. 그래서 함수의 인수가 많을수록 우리는 인지부하를 느낄 게 될 가능성이 높습니다.

클린코드에서는 인수가 많을 때 줄이는 방법으로 인수 객체를 사용해서 개념을 표현하라고 합니다. 예를 들어 다음과 같은 메서드가 있습니다.

public void line(int xOrigin, yOrigin, xDestination, yDestination)

우리의 두뇌는 4개의 청크(xOrigin, yOrigin, xDestination, yDestination)로 인식하게 될 가능성이 큽니다.

이번엔 클린코드 지침대로 인수 객체를 도입해 보겠습니다.

public void line(Point origin, Point destination)

이렇게 되면 우리 두뇌는 2개의 청크(origin좌표, destination좌표)로 해당 메서드를 인식하게 될 가능성이 커지고 이로써 작업 기억공간의 부하를(4->2) 줄일 수 있게 됩니다. (물론 코드에 사전 지식을 얼마나 가지고 있냐 또는 개인에 역량에 따라 첫 번째 코드를 보고 머릿속에서 바로 2개의 청크로 인지할 수도 있습니다. )

2. 클래스/메서드를 작게 유지하라.

많은 기능을 가지는 “만능 클래스” 또는 “만능 메서드”를 의미 있는 단위로 분리해서 작게 만들라는 클린 코드의 원칙입니다.

긴 클래스, 긴 메서드를 읽을 때는 해당 코드가 무슨 일을 하는지 코드를 한줄 한줄 읽어야 하고 이는 우리 두뇌에서 청킹 작업을 하는데 많은 시간을 쏟고 어렵게 만듭니다.

반면 긴 클래스, 메서드를 작은 단위로 분리하면 분리된 클래스, 메서드의 이름이 문서 역할을 합니다.그래서 코드를 읽을 때 그 이름을 가지고 효율적으로 청킹을 할 수 있게 되고 이는 우리의 작업 기억 공간과 STM의 용량 부하를 줄이는 효과로 이어지게 됩니다.

3. 반복하지 마라!

코드의 중복을 없애라는 클린코드의 지침입니다. 유지보수를 위해서도 있지만 가독성 측면에서도 중복은 혼란을 야기 하기 쉽습니다. 예를 들어 다음과 같은 두 메서드가 있습니다.

int foo(int j) {
  if (j < 0)
    return j;
  else
    return ++j;
}

int goo(int j) {
  if (j < 0)
    return j;
  else
    return j+2;
}

foo() 함수를 보고 난 뒤 goo() 함수를 보게 되면 우리 작업 기억 공간은 LTM에서 foo()에 대한 정보를 수집하게 될 것입니다. 그리고 나서는 goo() 함수를 foo() 함수와 동일하다고 잘못 인지하게 될 가능성이 높습니다.

4. 의미 있는 이름을 지어라!

이름에 의도를 분명히 밝히라는 클린코드의 지침입니다. 구체적으로는 아래와 같은 여러 지침이 있습니다.

• 해법 영역에서 가져온 이름을 사용하라.
• 문제의 영역에서 가져온 이름을 사용하라.
• 의미 있는 맥락을 추가하라.

이렇게 많은 클린 코드 지침들은 LTM과 관련이 있습니다. 올바른 개념을 이름에 단어로 적절히 사용하면 코드를 읽을 때 관련 정보를 LTM에서 찾는 데 도움을 주기 때문입니다.

예를 들면 Visitor 디자인 패턴이 적용된 코드에 xxxVisitor라는 단어를 넣어주면 해당 코드가 Visitor 패턴이 적용되어있다는 걸 인지하고 관련 정보를 가지고 와서 이해하게 됩니다. 또는 지뢰 찾기 게임에서 게임판을 theList와 같은 함축적인 이름으로 명명 하는것보다 gameBord와 같은 이름을 지어주면 우리는 해당 코드를 읽을 때 도움이 되는 정보들을(지뢰 찾기 게임판은 여러 칸으로 구성되어 있다 등) LTM에서 가져올수 있습니다.

추가로 클린코드에는 없지만, 우리가 보편적으로 준수하는 네이밍(camelCase, snake_case) 관례 또한 인지과정과 연관이 있습니다. 아시다시피 STM의 크기는 제한적이기 때문에 효율적으로 저장하기 위해 우리 뇌는 이름을 청킹 하려고 하고 합니다. 이름이 체계적일수록 이름의 각 부분을 식별하고 청킹 하기 쉽습니다. 예를 들어 nmcntrlst 보다 name_counter_list 같은 이름이 관련된 내용(이름, 카운터, 리스트)을 훨씬 쉽게 우리는 인지 할 수 있습니다.

마치며

우리 모두 타인, 자신의 코드를 읽으며 좌절하고 괴로워한 경험이 있을것입니다. 저는 우리 모두 뇌의 동작방식을 이해하고 효과적으로 코드를 읽어나가길 기대하며 이 글을 작성했습니다.

사실 이 글이 그동안 모르셨던 엄청난 사실을 알려주지는 않았을 겁니다. 하지만 우리가 그동안 “그래 이런 코드가 읽기 쉽지” 라고 당연히 생각했던 부분에 대해서 과학적인 근거를 제시했을 거라 생각합니다.

제가 소개하지 않았지만, 책에서는 신속하게 코드를 읽는 법, 다른 언어를 빨리 배우는 법, 복잡한 문제를 더 잘 해결하는 법, 코드베이스를 평가하는 법, 설계 개선법 등 재밌고 유익한 내용이 많이 들어 있습니다. 궁금하시다면 직접 책을 읽어보면 좋을 것 같습니다.

Ref

http://www.yes24.com/Product/Goods/105911017 (프로그램의 뇌)

http://www.yes24.com/Product/Goods/11681152 (클린코드)

코드가 클린 하면 왜 좋아?(feat. 뇌 인지 관점) was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.