생각을 개발하자, 박진형

[TIL - 1029] Jackson을 사용하면서, 쿼리플랜의 중요성, Spring AOP로 트랜잭션 처리할 때 조심해야할 것

Tue, 30 Oct 2018 00:35:00 +0900

feature 개발 진행하면서 알게된 것들

책, 영상, 자료를 먼저 보고 파악한 내용이 아닌 실제 필요한 기능 개발을 하면서 알게된 것들 : 정말 소중한 경험을 하면서 얻게된 것들을 당분간 남길 것 같음
Jackson json 파싱 기준(예제)
- 자바빈 규약을 지켜야함 : NoArgsConstructor, setter/getter
- [] 일 경우 array로 할지, List로 할지는 마음대로 하면 됨

{
  "id": 123,
  "name": "Pankaj",
  "permanent": true,
  "address": {
    "street": "Albany Dr",
    "city": "San Jose",
    "zipcode": 95129
  },
  "phoneNumbers": [
    123456,
    987654
  ],
  "role": "Manager",
  "cities": [
    "Los Angeles",
    "New York"
  ],
  "properties": {
    "age": "29 years",
    "salary": "1000 USD"
  }
}

@Data

public class Employee {

    private Long id;
    private String name;
    private boolean permanent;
    private Address address;
    private long[] phoneNumbers;
    private String role;
    private List<String> cities;
    private Map<String, String> properties;
}

Jackson 데이터가 없을 경우
- null이 아니라 size가 0

{
  "DoTest": [    
  
  ]
}

public class DoTest {

    private List<SubTest> subTests;
}

@Transactional 롤백 : RuntimeException에 대해서만 자동 rollback을 해주고, Unchecked Exception에 대해서는 설정해줘야함
쿼리 플랜 : 쿼리를 기능되게끔 짰다고 해서 그만인 것이 아니라 쿼리는 어떻게 해라라고 짜주지 않기 때문에 대신 짜주는 옵티마이져가 어떤 계획을 가지는지 확인해야함
- 풀스캔을 하고 있지 않은지, 잘못된 인덱스를 선택해서 검색하는 것은 아닌지 확인해야함
- 참고자료 남겨뒀다가 시간날 때 봐야지

> EXPLAIN SELECT * FROM group WHERE xxx_id = 1;

[TIL - 1025] 오늘은 개발보단 일에 대한 이야기, @RestController redirect하기, Options HTTP 메소드

Fri, 26 Oct 2018 00:33:00 +0900

working

프로젝트에 투입되기 전 배경지식을 얼른 캐치하는 것이 좋음 : 기획 배경, 사용 플로우(직접 사용해보기), API/테이블 목록, 정의, ERD 파악하기
다른 분의 코드를 보니깐 딱 든 생각은 컨벤션의 중요성과 문서화의 중요성(혹은 주석이라도 남기기)임 : 후임자가 코드를 보는데 아무런 설명이 없다면 생산성에 엄청난 악영향을 끼치게 됨
- API의 사용처, 객체의 역할, 메소드 각각에 대한 주석 등이 굉장히 생산성에 영향을 미친다는 것을 알게됨

스프링 MVC

@RestController redirect

@Controller와 달리 redirect를 시키기위해서 HttpServletRequest(JavaEE)를 인자로 받아서 redirect 시켜줘야함
직접적인 JavaEE API 직접적인 사용을 피하고 Spring MVC가 제공 API를 사용하기 : RestTemplate
- HttpStatus.MOVED_PERMANETLY : 301, redirect 상태코드

@GetMapping("/test")
public ResponseEntity<String> test() {
    HttpHeaders headers = new HttpHeaders();
    headers.setLocation(Uri.create("/test2"));
    return new ResponseEntity(headers, HttpStatus.MOVED_PERMANETLY);
}

@Qualifier

동일 타입 빈 객체 중 특정 이름으로 생성되어있는 빈을 주입받을 때 사용하는 어노테이션 : 동일 타입 인스턴스 2개가 등록되어있는 경우

HTTP

Request Header Referer

쉽게 말하면 현재의 전 링크 : 요청에 대한 응답을 구성할 때 다른 리소스를 요청해야할 때가 있음 다른 리소스를 요청하면 그 리소스는 request를 받아 요청을 처리하는데, 그때 header에 Referer로 이전에 요청한 URL가 기록

Referer: https://www.daum.net

Options 헤더

요청 URI에서 사용할 수 있는 메소드(HTTP Method)에 무엇이 있는지 요청
- 아래 예제는 모질라에서 제공 : 응답 헤더 Allow로 요청 가능한 메소드 목록이 넘어옴
- 굳이 아는 API에 대해 요청을 할 때 Options로 체크할 필요가 있을까?

curl -X OPTIONS http://example.org -i

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0

[TIL - 1024] MySQL 데이터타입, 정규화(1)

Thu, 25 Oct 2018 01:14:00 +0900

MySQL

데이터 타입

성능을 위해서 꼭 맞는 데이터를 고르기 : 공간 낭비(읽어오는 시간, 공간까지도 낭비)
숫자
- unsigned : 양수(+)만

타입	크기	참고
BIT(N)	1 ~ 64bit까지 지정	크게 잡고 작은 수를 넣을 경우 0으로 채워짐
TINYINT	1byte
SMALLINT	2byte
INT	4byte
BIGINT	8byte
FLOAT	4byte
DOUBLE	8byte
DECIMAL	지정 시 : (M, N), Mbyte(정확한 소수점을 저장할 때 사용)	M 길이로 N개 남은 수부터는 소수점으로,

문자

타입	크기	참고
CHAR(N)	Nbyte 고정	크기만큼의 데이터가 아니라면 공백으로 채움
VARCHAR(N)	가변 길이	데이터 크기만큼 사용
TEXT	최대 65535byte	TINY(255byte), MEDIUM(16777215byte), LONGTEXT(4294…..;;)도 있음

시간

타입	참고
DATE
TIME
DATETIME	DATE + TIME
YEAR
TIMESTAMP	수정에 맞춰 자동으로 데이터 변경

boolean 타입 저장하기 : tinyint(1) - 1비트로도 충분히 표현가능하지만 mysql에서는 1바이트를 요구

키 종류

슈퍼키 : 고유하게 식별되는 애트리뷰트 집합(후보키 + 일반 애트리뷰트 == 슈퍼키)
후보키 : 슈퍼키 부분 집합, 하나라도 제거되면 슈퍼키가 아닌 것(슈퍼키 - X == 일반키 라면 후보키)
- 여기서 하나를 선택해서 PK(기본키)로 사용함
- 여기서 하나를 선택하지않고 임의적으로 만든 키를 사용할 수 있음 : 인공키(아무런 의미없지만 식별가능하도록 유일하면서 NOT NULL인)

정규화

잘 설계된 테이블

다른 개체의 속성값을 가져오는 것은 FK를 통해 참조를 한다
- CRUD가 자유롭지 못함 - 디펜던시를 깊게 가져 코드 변경을 자유롭게 하지 못하는 코드와 같음
한 테이블에 서로 다른 정보를 저장하는 것은 좋지않음 : 역할에 따라 객체 분리하듯 데이터도 구분(관심사끼리 분리라는 표현을 쓰더라)되는 것끼리 따로 저장하는 것이 좋음

정규화

분해를 잘하는 것 : 문제점을 줄일 수 있도록 테이블을 설계
함수적 종속성 : 생각해본 내용을 옮기자면 X의 값으로 Y를 식별해낼 수는 있지만(함수적 종속성을 가짐), Y는 X를 식별해낼 수 없음(X가 무엇인지 결정할 수 없음)
- 한 쪽은 유일하고, 한 쪽은 같은 데이터가 있을 수도 있고 아닐 수도 있음
- 위의 상황을 X는 함수적으로 Y를 결정한다라고 함, Y가 달라지면 X는 무조건 달라짐
정규형 모델 : 조금 더 알아보자
1. 1NF(1차 정규화 - 기본) : 테이블에는 키(PK)가 있어야함, 애트리뷰트는 원자성을 가져야함(주소와 같이 쪼갤 수 있는 애트리뷰트를 가지면 안됨, 하나의 로우에 여러 값을 저장X)
2. 2NF
3. 3NF
4. BCNF

정규화의 한계

무조건적으로 정규형으로 맞출 수 없는 것이 실무에서는 FK JOIN으로 인한 성능 저하를 막고 한 번에 테이블의 값을 가져오기위해서 한 곳에 몰아서 데이터를 저장하기도 함
- 테이블의 한계를 자바 코드에 그대로 가져와서 고통을 받기보다 JPA를 사용하여 프로세스 메모리 상에서는 객체를 분리하여 사용할 것 : 한번 다뤘던 주제 - 블로그 다시 읽어보기

[TIL - 1023] 문제 해결 방법 - 팩토리 메소드 패턴

Wed, 24 Oct 2018 00:49:00 +0900

java

팩토리메소드 패턴

객체를 만드는 공장을 생성해두는 것
- 왜? 특정 조건에 의해 생성되는 인스턴스(같은 상위클래스의 하위클래스)가 다를 때 구체적인 클래스로 인스턴스 생성하는 코드 작성하지않고 생성 권한을 위임 받은 아이에게 요청하면 결합도를 낮출 수 있기 때문(구체적인 클래스를 명시해서 직접 생성하기보다 맞는 조건이 있으면 생성, 없으면 예외 발생이 되도록 할 수도 있음)
- 조금 더 나아가면 싱글턴일 때 팩토리 혹은 인스턴스 관리자에게 인스턴스를 특정 조건값을 주고 가져오게 할 수도 있음 : 여기에 더 추가하자면 인스턴스들에게 물어봐서 특정 조건값에 너희 부합하냐라고 묻는 메소드를 요청해서 맞을 때 가져오도록 코드를 짜면 switch 혹은 if ~ else 의 떡칠을 막을 수 있다고 생각이 듦
예제 코드
- 검색해서 본 예제 코드에서는 팩토리를 abstract로 선언해두고 extends해서 여러 팩토리를 만들고 하는데, 굳이 지금은 적용할 필요를 느끼지 못하여 1 depth를 유지함 뿐만 아니라 abstract 보다 interface로 선언해두는 것이 더 낫지 않을까? 어떤 타입의 인스턴스를 생성하는 능력을 가지고 있는 팩토리라고 생각한다면? 또 팩토리는 상태값이 없을테니 상태 필드도 없을텐데

public class ObjectFactory {

    public static UpperObject of(int value) {
        switch (value) {
            case 2:
                return new ExtensionObjectOne();
            break;

            case 1:
                return new ExtensionObjectTwo();
            break;

            default:
                throw new IllegalArgumentException();
        }
    }
}

interface UpperObject {

}

class ExtensionObjectOne implements UpperObject {

}

class ExtensionObjectTwo implements UpperObject {

}

[TIL - 1021] Spock가 뭐길래, 인덱스(1), int(11)이 뭘까?

Mon, 22 Oct 2018 01:26:00 +0900

test

spock 사용해보기

기존에 자바 코드(+spring)를 테스트할 때는 JUnit(unit test), Mockito(integration test)을 사용해서 테스트를 했는데, 워크샵에서 groovy로 테스트 코드를 작성하는 것을 보고 무엇인지 보았더니 Spock 였음

/* build.gradle Spock 추가 : mvnrepo(Core Module) : 스프링 환경에서 테스트 하는 것이 아니므로 Core만 */
dependencies {
    testCompile group: 'org.spockframework', name: 'spock-core', version: '1.1-groovy-2.4'
}

junit과 비교했을 때 Spock는 어떤 특징을 가지는지 알아보았음
- POJO 테스트

/* 테스트 대상 코드 */
public class Person {

    private static NameRule rule = BasicRule.of();
    private String name;

    public Person(String name) {
        if (!rule.isValid(name)) {
            throw new RuntimeException("올바르지않은 이름 설정");
        }
        this.name = name;
    }
}


/* Spock : 디펜던시 추가 후 테스트 클래스 생성할 때 테스트 프레임워크 선택할 수 있음 */
def "기본 룰 - 3자 미만"() {
    given:
    def invalidName = "te"
    
    when:
    new Person(invalidName)

    then
    def exception = thrown(RuntimeException.class)
    exception.message == "블라블라"
}

/* 여러가지 한꺼번에 테스트하기 */
def "기본룰 테스트"() {
    expect:
    new Person(name)

    where:
    name | _
    "jinbro" | _
    "te" | _
    "power" | _
    "qw" | _
}


#######
Condition failed with Exception:

new Person(invalidName)
|          |
|          te
java.lang.RuntimeException: 올바르지않은 이름 설정


Condition failed with Exception:

new Person(invalidName)
|          |
|          qw
java.lang.RuntimeException: 올바르지않은 이름 설정

사용해보니
- 조금 더 테스트하도록 유도하는 점(블록 없이는 실행안됨 - 로그만 찍어보기가 아니라 결과 관련 블록 있어야)이 있음
- where 블록을 통해서 여러 케이스를 하나의 메소드로 묶어 테스트 할 수 있음 : 테스트 코드가 줄어듦 - JUnit의 경우 첫번쨰 실패 케이스만 알 수 있음
- Mock 테스트도 가능함 : Mock() 함수를 통해서

MySQL

인덱스(1) - 레코드를 저장하는 방식

검색 속도를 올리기 위한 레코드 저장 방식 : 검색(Select)속도를 올리는 대신 Insert, Update, Delete 속도는 느려짐
- 인덱스를 재편집 해야하기 때문에 : B+Tree 구조로 정렬해둔 상태
- 자주 사용되는 컬럼에 대해 인덱스를 걸어둠 : 검색 속도를 높여야할 필요성이 있는 데이터의 경우 불가피하게 선택할 수 밖에 없음

인덱스 종류

Clustered Index : PK를 인덱스(자동 생성), PK를 기준으로 실제 데이터 위치까지도 변경됨, PK를 기준으로 검색하여 빠른 속도로 검색
- 인덱스의 Key가 PK
- 레코드의 위치를 Value로 가지고 있음 : PK로 검색하면 빠르게 데이터 위치를 찾을 수 있음
- BTree 구조

mysql> show index from employee\G;
*************************** 1. row ***************************
        Table: employee
   Non_unique: 0
     Key_name: PRIMARY
 Seq_in_index: 1
  Column_name: id
    Collation: A
  Cardinality: 2
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
1 row in set (0.00 sec)

ERROR:
No query specified

Secondary Index(Non Clustered Index) : 해당 인덱스를 만들 때에는 데이터 정렬 자체도 변경되지않고(실제 데이터 위치 변경없음), 해당 컬럼 기준 B+Tree만 하나 더 만드는 것
- PK를 Value로 가지고 있음 : PK를 찾아 Clustered Index로 다시 가서 레코드 위치를 찾음
- BTree 구조
- 풀스캔해서 찾는 것보다 트리구조로 되어있는 상태에서 검색하는 것이 더 빠름
- FK는 자동으로 인덱스 생성

mysql > create index idx_employee_createdtime on employee (created_time);

Cardinality(인덱스 선정 기준 중 하나) : 사전의 뜻으로는 농도, 카디널리티가 높다는 뜻은 걸러낼 수 있는 데이터가 많다는 것
- sex(성별 컬럼)를 인덱스로 잡을 경우 남/여 50%만 걸러낼 수 있으므로 성능상 이점을 가져갈 수 없음
- 반대로 단순하게 auto_increment 설정된 int 타입의 Primary Key에 대한 인덱스가 자동생성되었는데, 각각 다 다르고 걸러내기가 쉬움(카디널리티가 높음)
index는 내일 데이터 bulk insert 해두고 테스트를 해봐야겠음

궁금했던 것 - int(11)에서 (11)은 무엇을 의미할까?

디스플레이 옵션인데, 디스플레이할 때 비는 자리만큼 0을 채우도록(zerofill) 하는 옵션
- 디스플레이 적용하기위해서는 컬럼 지정 시 zerofill로 선언해야함
- int(11)을 사용하는 이유는? int가 4byte인데 unsigned 표현할 수 있는 데이터 범위가 21억… 10자리가 max size + 1

mysql > create table user ( id int(11) unsigned zerofill not null auto_increment, name varchar(16) not null, primary key (id) );
.
.
.
select * from user;
+-------------+------+
| id          | name |
+-------------+------+
| 00000000001 | a    |
| 00000000002 | b    |
| 00000000003 | c    |
| 00000000004 | d    |
| 00000000005 | e    |
+-------------+------+

[TIL - 1020] 병렬처리 API, MySQL 엔진/스토리지 엔진, replication 개념, 롤백하려면 어디에 저장?

Sun, 21 Oct 2018 01:58:00 +0900

java

병렬로 연산하기

ExecutorService API
- 쓰레드풀에 일정 개수의 쓰레드를 만들어두고 처리하는 방식의 API : limit 개수만큼 동시에 처리함

ExecutorService executor = Executors.newFixedThreadPool(5);
List<Future<String>> results = new ArrayList<>();
for (int i = 0; i < 30; i++) {
    results.add(executor.submit() -> {
        Thread.sleep(5000);
        return Thread.getCurrrentName() + ", end time : " + LocalDateTime.now();
    });    
}

for (Future<String> result : results) {
    System.out.println(result.get());
}

executor.shutdown();

Stream API(java8)
- 하나의 task를 여러개 task로 쪼개고, 처리한 후 하나로 합치는 형태로 처리 : ForkJoin Framework(Pool) - ForkJoinPool은 ExecutorService 구현체
- 노는 CPU가 없도록 하는 알고리즘이 적용되어있음 : 각각이 내부적으로 queue가 생성되고 task를 처리함, 자신의 task가 모두 처리된 경우 다른 task를 가지고 올 수 있음

Stream.iterate(1L, i -> i + 1)
        .limit(limit)
        .parallel()
        .reduce(0L, Long::sum);

병렬처리와 순차처리 비교, 주의해야할 점

task가 독립적이지 않다면 오히려 성능 저하될 가능성(각각이 서로에 영향을 미치는 경우) : 아래의 예의 경우 전 연산이 현재 연산 결과에 영향을 미칠 수 있음(연관된)
특정 메소드를 사용할 때만 사용할 것 : iterate()의 경우 boxing 객체 생성(primitive -> object) -> 연산을 위해 unboxing() 해야
- 아래의 예제코드의 iterate가 순차처리 메소드 : 하나씩 어떤 처리를 하는 것(무한스트림 생성)
- Boxing된 객체를 unboxing해서 연산하도록 처리하는 것이 비효율적이라는 것도 알아갑니다! : iterate가 아닌 IntStream/LongStream과 같은 API 사용하기
내부적으로 queue를 만들어내서 task를 처리 : 그만큼 비용이 든다는 이야기 같음 - 무작정 사용하는 것이 사용해서 얻는 성능 이점보다 잃는 것이 많을 수 있다는 위험

long start = System.currentTimeMillis();
long result = Stream.iterate(1L, i -> i + 1)
        .limit(limit)
        //parallel()
        .reduce(0L, Long::sum);

System.out.println(((System.currentTimeMillis() - start) / 1000) + "초");
return result;

병렬처리 : 20초
순차처리 : 1초

mysql

용어 정리

데이터베이스(schema) : 테이블 컨테이너(단지 담는 역할)
- MySQL에서는 schema와 database는 동의어 : MsSQL(sql-server)에서는 schema가 database 보다 하위 컨테이너
쿼리 종류
1. DDL : 데이터베이스/테이블/스토어드 프로시져 생성, 변경 작업 쿼리(CREATE, ALTER)
2. DML : 데이터 조작 쿼리 - SELECT, UPDATE, DELETE, INSERT
3. DCL : 권한 관련 - GRANT

엔진

MySQL 엔진 : 연결을 맞이하고 파싱된 쿼리를 최적의 방법으로 실행되기위해 계획하는 역할(하나의 종류 밖에 없음)
- 생각하는 담당
스토리지 엔진(핸들러) : 데이터를 저장하고 저장된 데이터를 찾아오는 역할(여러개를 동시에 사용할 수 있고 여러 종류가 있으며, INNODB가 기본 스토리지 엔진)
- SELECT, INSERT, UPDATE, DELETE 실질적인 데이터 관련 작업은 여기서 담당
- InnoDB : PK를 기준으로 데이터 클러스터링(저장) - 순서대로 저장, PK를 기준으로 검색은 빠름(클러스터링 인덱스 - 그래서 이런 이름이었군…)

# 테이블 생성 시 스토리지 엔진 지정 가능
> CREATE TABLE test (....) ENGINE=INNODB;

# 기본 스토리지 엔진 조회
> SELECT engine, support FROM information_schema.engines WHERE support='DEFAULT';
+---------+
| support |
+---------+
| InnoDB  |
+---------+
1 row in set (0.00 sec)

replication

시스템 안정성을 위한 복제 작업을 뜻함 : 메인으로 사용하고 있는 master 데이터베이스가 장애를 일으켰을 때 서비스가 중단되는 것을 막기위해 미리 복제해두었다가 서비스를 계속할 수 있도록 하는 것
역할에 따른 권한 제한
1. master : insert, update, delete
2. slave : read-only
운영 : 물론 정해져 있는대로 구성하는 것은 아니라 운영 상황에 맞게 조금씩 변형시킬 수 있음
1. active-active : master 만을 가지고 서비스를 할 수도 있지만 active-active 상태로 만들어 읽기 작업은 slave 데이터베이스에 수정 및 삭제 작업은 master가 하도록 하여 부하 분산(전제 조건은 sync 되어야 한다는 것)
2. active-stand by : slave 데이터베이스를 오로지 백업용으로만 사용
구축 어떻게 되지? : 바이너리 로그를 활성화해두면 DML(데이터 변경 쿼리), DDL(스키마 변경 쿼리)을 남기고 slave에서 로그를 참조하여 replication 작업을 수행함
- slave 데이터베이스는 master에 접속하여 로그를 요청하고 받아온 로그를 기록한 후 복제(실행)
- 로그를 쓰는 것도 자원 소모입니다
구축해보기 : AWS 환경에서 해보기

트랜잭션 roll-back

롤백이 되면 트랜잭션 처리 이전의 상태로 돌아가야하는데, InnoDB는 메모리영역에 UPDATE, DELETE 되기 전의 상태를 저장해둠 : UNDO 로그 영역(메모리)

[TIL - 1019] 오늘의회고, upsert 쿼리, git tag/config, api 구조

Sat, 20 Oct 2018 03:09:00 +0900

오늘의 회고

드디어 시스템 파악하기 시작! 모르는 것은 모른다고 말하고 배우는 자세를 취하면 아무리 실력 없더라도 안좋게 보지는 않을까 생각함. 그리고 입사해서 느낀 것은 글로 정리하는건 역시나 중요하다는 것 사내 위키에 시스템에 대한 히스토리 정리, 설명이 잘 되어 있다보니 파악하기가 수월하였음 명패에 쓴 “기본으로 돌아가자” 문구처럼 모르겠으면 거기서 헤매기보다 처음부터 훑어보면서 어디를 모르는지 체크부터 하도록 해야겠다. 오늘 공부 못한만큼 내일 많이 해야지~~~

데이터베이스

upsert

데이터베이스에 저장되어있는 데이터가 있을 경우(unique key값 기준) update, 없을 경우 insert 하도록 sql을 짜서 데이터 중복되지 않도록 하는 것을 말함
- 조회한 데이터를 메모리로 가져와서 필터링한 결과 있을 경우/없을 경우를 나눠서 쿼리를 또 다시 날리는 것과 일종의 프로시져처럼 하나의 쿼리로 조건문을 만들어 사용하는 것 중 어느 것이 나을까? : 성능 상의 이점과 유지보수 관점의 문제인가(너무 민감하게 받아들이는 것인가)
- MySQL upsert 쿼리 관련 docs
같은 쿼리를 2번 실행했을 때의 결과 : 존재한다면 같은 쿼리라도 @update.com으로 update 하기를 선언한 쿼리

mysql> insert into student (name, email) values ('jinbro', 'jinbro@test.com') on duplicate key update name='jinbro', email='jinbro@update.com';
Query OK, 1 row affected (0.01 sec)

mysql> select * from student;
+--------+-----------------+
| name   | email           |
+--------+-----------------+
| jinbro | jinbro@test.com |
+--------+-----------------+
1 row in set (0.00 sec)

mysql> insert into student (name, email) values ('jinbro', 'jinbro@test.com') on duplicate key update name='jinbro', email='jinbro@update.com';
Query OK, 2 rows affected (0.01 sec)

mysql> select * from student;                                                                
+--------+-------------------+
| name   | email             |
+--------+-------------------+
| jinbro | jinbro@update.com |
+--------+-------------------+

git

tag

커밋을 참조하기 쉽게 이름을 붙이는 것 : 특정 커밋에 특정한 정보를 달아주는 것, release 커밋에 대해 tag를 활용
종류
1. light-weight tag : 간단하게 이름만 붙임
2. annotated tag : 이름, 설명, 서명, 이메일, 태그 생성 날짜 정보를 포함시킬 수 있음
만들어보기
- 특정 저장소에만 정보 설정하기 : git config (옵션없이 하면 로컬 config)

# light-weight tag
> git tag ${태그이름}


# annotated tag 
> git tag -a ${태그이름} # m 옵션을 추가해서 바로 설명을 추가할 수 있음


# tag list
> git tag -n
version-0.0.1   first commit
version-0.0.2   두번째 베타버젼

API 구조

업무에 대해서 전달해주시는 과정에서 core API와 core 주변에 그려진 API에 대한 설명을 듣고 알게된 점을 적어봄
core API와 주변 API : core API는 말 그대로 핵심 기능 요청 - 응답 받을 수 있는 API이고, core 주변에 딸려 있는 API는 core API의 구성요소를 aggregation 하여 만들어진 편의성에 초점을 둔 API

[TIL - 1018] git command, APM이란, aws 리소스 알아보기

Fri, 19 Oct 2018 00:01:00 +0900

git

git flow(+operation)

fork flow : master, develop, feature, release, hotfix 브랜치로 구성하고, 저장소는 upstream, origin, local으로 구성함
- 브랜치 : master가 현재 운영, develop은 기능 개발 시 출발점이 되는 브랜치, feature는 각 기능 개발 때 사용되는 브랜치(develop에서 branch 생성), release는 다음 release될 브랜치, hotfix는 긴급하게 수정해야하는 상황이 발생했을 때 master로부터 브랜치를 따서 수정 후 merge 배포를 진행함(절대적인 것은 아님! - 각 팀의 운영 노하우에 따라 조금씩 수정될 수 있음)
- 저장소 : upstream을 prod로 사용하고 origin은 개발자 개인 repo로 upstream을 fork한 repo, local은 개발자의 로컬 저장소

command

cherry-pick : 특정 브랜치와 merge 하는 것이 아니라 특정 브랜치들의 변경사항은 각각 놔두면서 흡수하는 것 - 새로운 커밋(들)을 만들어냄(내용은 복사본, pick한 커밋만큼 생성)
- next-release 작업이 진행되고 있는 상황에서(dev까지 완료되었건 feature에 있건 간에) master에 긴급 수정한 내용이 생겼을 때 next-release에도 반영해야한다면 cherry-pick을! : release 브랜치에서 새로운 커밋 생성

/* master */
4c01e372f5f7e7ff727f3f5422fae19f0154d7ad (HEAD -> master) prod hotfix
bb237d418692237ebd09bf09178675b8e067fb9e prod commit

> git cherry-pick 4c01e37

/* release branch */
97594e7ccb7b20f375ed109cf0f107f9ee96dc9c (HEAD -> release) prod hotfix
c869dada3813365f36ff4c034fbd244fe2c57324 next-release commit
bb237d418692237ebd09bf09178675b8e067fb9e prod commit

interactive rebase(squash) : 여러 커밋을 하나의 커밋으로 만드는 작업을 할 때 사용 - 단 원격저장소(hub 목적)에 push한 커밋가지고는 하지말기!(reset 보다 revert를 사용하는 것이 더 나은 이유와 같음)

infra

APM : Application Performance Management(성능 관리, 모니터링툴) - pinpoint, new relic 등이 있음
- 3계층(tier) 구조 : 프론트 / 서버 / 데이터베이스, 지금은 3계층 이상으로 N계층으로 더 세분화해서 나눔(MSA) - 도메인 별로 더 쪼개서 관리하기 쉽도록, 관리해야할 대상이 많아져 몇군데만 보는 것이 아니라 다 들여다보고 대응할 수 있어야해서 APM을 사용하게 됨
- tier와 layer 차이 : 외부로 분리해내는 것과 내부적으로 계층을 나눈 것

AWS 리소스

AMI : Amazon machine Image - 인스턴스를 이미지화 하여 복제(scale out)가 쉬움, AWS는 트래픽에 따라 오토스케일링이 편하다는 점!
access key ID/secret key : API로 리소스 사용가능(써드파티툴로 제어가능) - 주로 마스터 계정의 액세스키가 아닌 IAM 계정(제한된 권한)의 액세스키를 발급하여 사용
cloud watch : EC2 인스턴스를 비롯한 모니터링 가능한 서비스의 인스턴스에 attach 시키면 됨, 알람 수치를 설정할 수 있음, 뿐만 아니라 오토스케일링(out, in)
aws-cli : cli에서 aws 리소스를 제어할 수 있음 - 단 access-key가 있어야함(발급 받으면 됨)
s3 : HTTP로 파일 업로드, 다운로드 가능 - 동적인 처리없이 정적으로 파일만 주고 받는 프로그램을 만든다면 S3를 사용하는 것이 더 효율적
- 업로드 후 curl로 다운로드 테스트
- 버킷에 권한 설정 가능 : AWS에서 제공해주는 기능으로 버킷에 대한 정책(공개 여부, 공개 범위 등) json 데이터를 만들기 쉽고 적용하기도 쉬움
- metadata 설정으로 캐시 설정 가능, 라이프 사이클 설정 가능, 버져닝 가능(동시에 라이프 사이클 설정은 안됨)
- 해봐야할 것 : spring cloud로 S3 파일 업로드 해보기
cloud front(캐시 서버 - 엣지 로케이션) : HTTP 메소드로 동적인 작업일 경우(POST, PUT, DELETE 등) origin으로, 그 외엔 파일 있을 경우 캐시된 파일을 내려주고 origin으로
- cloud front에 복사된 파일이 없을 경우 origin으로 가게 되어있음 : 임의 갱신할 때 이용할 수 있는 특징(요청 URL 변경하기)
- deploy : 엣지 로케이션에 배치된(생성된) 단위
- 단순하게 가까워서 얻는 이점도 있음
- ec2 - cloud front(custom origin) 연동 : HTTP 통신
rds
- 탄력적으로 관리 가능 : 스케일링 가능, replica 서비스 제공 등
- 해봐야할 것 : master/slave(Replication) 구성해보기

네트워크

HTTP 헤더

referer : 어디에서 요청을 했는지 나타내는 값을 Request 헤더에 넣어서 보냄

[TIL - 1017] 트랜잭션 격리수준, mysql 설치/계정 설정, stored procedure, operation process

Thu, 18 Oct 2018 01:07:00 +0900

데이터베이스

트랜잭션 격리 수준(Lock 정책)

멀티쓰레드 환경에서 트랜잭션이 지켜야하는 트랜잭션 간의 간섭 금지(Isolation)와 속도 트레이드오프 발생 : 격리 수준 특징을 알아야 도메인 특징에 따라 알맞는 격리 수준을 골라 트레이드오프 상황을 벗어날 수 있을 것이라 생각됨
- 데이터베이스마다 다르기 때문에 어떤 격리 수준이 있는지는 알아봐야함

명칭	설명	발생할 수 있는 문제점
`read uncommited`	커밋되지 않은 데이터 변경까지도 다른 트랜잭션에서 읽기 가능	phantom read, non-repeatable read, dirty read
`read commited`	커밋된 데이터 변경을 읽을 수 있음	phantom read, non-repeatable read
`read repeatable`	조회한 데이터에 대해 Lock이 걸리고 수정할 수 없는 상태	phantom read
`serializable`	하나의 트랜잭션이 처리될 동안 완전한 Lock - 다른 트랜잭션 처리 대기	-

phantom read : 같은 범위에 대한 검색을 했는데 다른 트랜잭션의 작업으로 인해 다른 개수(삭제, 추가)가 검색됨
non-repeatable read : 같은 데이터 임에도 불구하고 다른 트랜잭션의 작업으로 인해 변경된 데이터 값이 읽힘
dirty read : 커밋되지않은 데이터가 읽히다보니 해당 데이터를 변경한 트랜잭션에 의해 커밋되지않았을 때 쓰레기 값이 되었지만 그대로 저장되는 문제

mysql 설치 후 계정 생성

설치 이후에는 root 계정만 존재하므로 사용자 계정을 생성해서 사용할 것 : 호스트 종류(localhost, @ <- 외부 접근), 접근 제어(예를 들어 특정 스키마만 접근, select 권한만) 등 생각하고 유저 생성
- mysql 5.7 부터 password가 아닌 authentication_string : user 테이블 조회 시

stored procedure

여러 쿼리를 하나의 프로시져로 선언해두고 요청이 들어왔을 때 실행함 : 말 그대로 절차를 저장해둠
- 네트워크에서 주고 받아야할 데이터가 줄어듬 : 쿼리 데이터 주고 받지 않아도 됨 - procedure 호출
- 특징에 대해서도 더 알아보기 : 어떤 점 때문에 사용하고 어떤 점 때문에 사용하기를 꺼리는지까지
오늘은 개념까지만…(잘자고 출근해야지!) 내일은 mysql에서 procedure 만들어두고 spring에서 procedure 호출해보는 것까지 해보면 좋겠..!
- mssql(sql-server)에서는 프로시져 권장이라는 말이 있던데 이 부분도 찾아보기

운영

프로세스

운영 프로세스에 대한 이해없이 업무를 할 수 없을 것 같다는 생각이 들어 프로세스를 찾아보고 정리해보았음
- 아직까지는 직접 겪어본 바에 비춰 적기보다 그동안 어렴풋이 알고 있었던 개념과 검색과 시니어분께 여쭤 얻은 답을 기반으로 정리함(제대로 느끼는 그 날이 얼른 오길)
- 회사에 따라 아래 프로세스를 다 가져가는 경우가 있는 반면 통합해서 진행하는 것으로 보여짐

환경	설명
`local`	개발자 개인 개발 환경 - 공통된 개발 환경과 코드컨벤션과 같은 약속이 되어있어야함(개발 후 통합했을 때에 대한 대비 및 원활한 팀 운영)
`development(dev)`	개발한 소스코드를 서버 환경과 같은 환경에 모아 테스트하는 환경, prod 서버 환경보다는 간소화(기능 위주의 테스트)
`integration`	컴포넌트 간의 의존성을 가지고 있을 때 한 곳으로 모아 테스트하는 환경
`qa`	QA 엔지니어가 테스트하는 환경 - 항목을 짜두고 테스트
`staging`	운영 환경으로 들어가기 전 최종적으로 거의 운영 환경과 동일하게 구성하여 테스트 하는 환경
`production(prod)`	실제 서비스 운영 환경

[TIL - 1015] 절차지향과 객체지향, IaaS/PaaS 개념

Tue, 16 Oct 2018 00:16:00 +0900

절차지향 vs 객체지향 프로그래밍

입사 첫날 운 좋게도 객체지향의 사실과 오해 저자이자 배민찬 개발자이신 조영호님의 특강을 들을 수 있었다. 절차지향과 객체지향적인 설계와 코드를 비교해가며 각각의 특징과 장단점에 대해 들을 수 있는 시간이었다.

절차지향

데이터를 관리하는 클래스와 로직을 처리하는 클래스가 분리되어 있음 : 객체는 단지 데이터를 getter/setter 하는 용도로 밖에 사용되지않음
중앙 집중형 코드가 완성됨 : 역할에 따라 로직을 처리하지않고, 데이터를 가진 객체들이 한 곳에서 모여서 절차지향적으로 처리되다보니 변경사항이 생겼을 때 유연하지못함

객체지향

데이터(상태값)와 로직 처리를 클래스로 구분하지않고 역할을 기준으로 분리함 : 역할을 수행(로직)함에 따라 상태값(데이터)이 변경됨
- 각자 맡은 바가 있기 때문에 한 곳에서 처리하지않고 각각에게 위임을 하는 코드가 완성됨
RDBMS와 결합해서 코드를 작성하게 될텐데 서로 다른 패러다임으로 인해 Mapper를 사용하게됨 : JPA(대표 구현체 - Hibernate)
- 무조건적으로 객체지향이 좋은 것이 아니라 상황에 따라 절차지향만으로도 개발할 수 있음. 다만 변경에 유연한 개발을 위해 객체지향이 필요할 뿐

IaaS, PaaS

IaaS : Infrastructure-as-a-service, 인프라 제공 서비스, AWS/Microsoft Azure가 대표적인 서비스
PaaS : Platform-as-a-service, IaaS 포함 개발 툴/기능/배포까지 제공하는 서비스, Heroku가 대표적인 서비스