Skip to content

Latest commit

 

History

History
176 lines (136 loc) · 10.6 KB

2019q2.md

File metadata and controls

176 lines (136 loc) · 10.6 KB

20190601

Semantic Commit Messages

  • https://seesparkbox.com/foundry/semantic_commit_messages
  • 예전부터 따르고 있는 커밋 메세지 형태지만 맨날 명칭을 잊어버려 기록.
  • 회사에서 각각의 커밋은 작업 타입을 접두사로, Merge 커밋에는 지라 티켓 번호를 명시.
  • 내가 생각하는 이 메세지 형태의 장점은 코드 리뷰어가 편함.
  • 다만, 개발 과정에서 같은 작업 타입을 하나의 커밋으로 묶기 위해 rebase 를 많이 하게 됨. 또한, 팀 내 커밋 메세지 룰이 모든 개별 커밋 앞에 티켓 번호를 명시하는 것이라면 메세지가 지나치게 길어짐.

OFFSET 방식 페이징의 문제

OFFSET 방식 페이징의 성능 문제가 잘 정리되어 있음. 하지만 jOOQ 블로그에서 이메일 서비스를 예로 하며 현재 이메일이 총 몇개고, 몇 번째 페이지에 있는지는 사용자가 별로 신경 안쓰는 정보이며 페이스북, 트위터와 같이 타임라인 방식이 사용자에게 더 좋은 경험을 준다고 하는 부분은 공감하기 힘듬. 특히 예로 든 이메일 서비스의 경우 더욱 더. 이미 전자의 정보들을 얻는 것에 익숙해서인지도. 정말 필요한 정보인지는 별개. 다만 화면상에 페이지 정보를 전부 보여줌으로써 사용자에게 정확한 정보를 페이지 정보를 전달하는 일이 더 고되지는 건 사실임 (전에 무한스크롤 방식 화면 + OFFSET 방식 페이징으로 인해 발생한 문제가 있는데 정확한 상황이 잘 생각 안남). 추가로 자주 사용하는 일부 서비스의 페이징 관련 API 를 살펴 봄.

20190605

JMH

https://github.com/my-scratchpad/java-microbenchmark 자바 성능 측정을 위한 마이크로벤치마크 도구 jmh 를 살펴봄.

마이크로벤치마크에서 가장 조심해야 할 부분은, 아무 의미가 없더라도 항상 어떤 수치가 만들어진다는 사실입니다. 뭔가 측정은 하는데 그 실체는 확실치 않습니다. - 자바 최적화. 벤저민 J. 에번스 외 2명 저. 이일웅 역. 한빛미디어. 2019

위 문구가 굉장히 인상적임. 전체 코드 중 작은 자바 코드 한 조각의 성능을 정확히 측정하기는 매우 미묘하고 어려움. [자바 최적화] 책에서는 가능하면 마이크로벤치마크를 하지 않되 꼭 필요하다면 유스케이스를 정확히 파악할 것을 강조. 주로 마이크로벤치마킹을 하는 유스케이스는 다음과 같음.

  • 사용 범위가 넓은 범용 라이브러리 코드 개발
  • OpenJDK 또는 다른 자바 플랫폼 구현체 개발
  • 지연에 극도로 민감함 코드 개발

20190606

Domain Model And Persistence Model

최근 팀을 옮겼고 새로운 기능을 개발하며 신규 도메인 등장. 그에 따라 엔티티를 정의했는데 팀 내 리뷰 과정에서 생각이 많이 달라 합의할 수 있는 수준의 모델이 만들어지기까지 많은 의견이 오고 감. 나중에 알고 보니 엔티티를 도메인 모델 관점으로 보냐 영속성 모델 관점으로 보냐에 따라 의견이 많이 달라진 것.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE)
@ToString
@Table(
        indexes = {
                @Index(name = "foo_bar")
        }
)
@Audited
@AuditOverride(forClass=AbstractAuditable.class)
public class Entity extends AbstractAuditable {
}

자바, 스프링, 하이버네이트 조합에서 엔티티를 만들다 보면 DDD, Hexagonal Architecture에서 이야기하는 우리 코드의 중심에서 가장 순수한 것과는 이질감이 느껴짐. 하지만 도메인 모델과 영속성 모델을 분리하면 느끼던 이질감이 모두 해결될 듯.

“Are the benefits of pure DDD worth the cost in the speed of development?”

반면, Stackoverflow 에 관련 질문 답변 중 위 문장이 인상적. 맵핑 과정을 한단계 더 거친다는 것이 해보지 않은 일이라 부담스럽기는 함. 하지만 비즈니스가 계속되는 동안 도메인이 그 중심에 있는 것이라면 그런 수고로움을 감수할 만 하다고 생각. 팀 전원의 합의 하에 도메인 모델과 영속성 모델이 분리 된 설계를 해보고 싶음.

20190612

Backends For Frontends

API Gateway는 Reverse Proxy 패턴의 특화 된 형태. 단순 라우팅 외에 부가적인 역할도 가능. 주로 클라이언트-마이크로 서비스 간의 통신에 관해 다음과 같은 문제를 해결하기 위해 사용.

  • 마이크로 서비스들의 결합 (aggregation)
  • 너무 많은 네트워크 왕복
  • 인증 및 권한 문제 등

다음 두개 링크에서는 사용자 UI와 관련하여 API Gateway 가 좀 더 특화 된 형태인 BFF 를 소개.

BFF 는 마이크로 서버들의 응답을 결합하여 UI 에 특화 된 모델 형태로 반환. 따라서 클라이언트 별로 BFF 가 존재할 수 있음. 예컨대, 웹용 BFF, IOS용 BFF, Android 용 BFF 등.

20190614

gzip

gzip 은 LZ77, Huffman coding 알고리즘을 차례로 적용한 DEFLATE 알고리즘 기반. 텍스트 기반 데이터에서 최고 성능을 발휘.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
    <ol>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
        <li>Hello World</li>
    </ol>
</body>
</html>
$ gzip *.html
$ ls -lh

# 431B helloworld.html
# 156B helloworld.html.gz

LZ77 알고리즘

HTTP 명세

  • HTTP 명세상으로 클라이언트는 자신이 이해 가능한 컨텐츠 인코딩을 Accept-Encoding 헤더 필더에 포함해야 함.
  • 각 인코딩에 Q(quality) 값을 매개변수로 더해 선호도를 나타낼 수도 있음. 0.0 가장 원치 않음. 1.0 가장 선호함.
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

웹서버 적용

주의 할 점은 Reverse Proxy 의 경우, 클라이언트 최접점 서버에 적용해야지 프록시 뒤 서버에 적용하면 크게 이점이 없음.

AWS assume-role script

젠킨스 서버는 AWS A 계정, 프로덕션 구성은 B 계정, 이렇게 서로 다른 AWS 계정간에 Code Deploy 로 배포하기 위해서는 assume role 필요.

임시 자격 증명 발급을 위한 설정이 된 상황에서 AWS CLI 의 assume-role 커맨드를 통해 발급 받을 수 있음.

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:s3-access-example",
        "Arn": "arn:aws:sts::123456789012:assumed-role/xaccounts3access/s3-access-example"
    },
    "Credentials": {
        "SecretAccessKey": "9drTJvcXLB89EXAMPLELB8923FB892xMFI",
        "SessionToken": "AQoXdzELDDY//////////wEaoAK1wvxJY12r2IrDFT2IvAzTCn3zHoZ7YNtpiQLF0MqZye/qwjzP2iEXAMPLEbw/m3hsj8VBTkPORGvr9jM5sgP+w9IZWZnU+LWhmg+a5fDi2oTGUYcdg9uexQ4mtCHIHfi4citgqZTgco40Yqr4lIlo4V2b2Dyauk0eYFNebHtYlFVgAUj+7Indz3LU0aTWk1WKIjHmmMCIoTkyYp/k7kUG7moeEYKSitwQIi6Gjn+nyzM+PtoA3685ixzv0R7i5rjQi0YE0lf1oeie3bDiNHncmzosRM6SFiPzSvp6h/32xQuZsjcypmwsPSDtTPYcs0+YN/8BRi2/IcrxSpnWEXAMPLEXSDFTAQAM6Dl9zR0tXoybnlrZIwMLlMi1Kcgo5OytwU=",
        "Expiration": "2016-03-15T00:05:07Z",
        "AccessKeyId": "ASIAJEXAMPLEXEG2JICEA"
    }
}

응답 결과를 ~/.aws/config 에 적절히 구성해야 하는데 자동화 된 쉘스크립트 과정에 assume-role 과정이 포함되어 수동 처리 불가능. 하지만 다음과 같은 커맨드 조합으로 자동화가 가능.

echo " ########## AWS Assume Role"
temp_role=$(aws sts assume-role \
                    --role-arn "arn:aws:iam::${YOUR_AWS_ACCOUNT_ID}:role/{YOUR_ROLE_NAME}" \
                    --role-session-name "${YOUR_SESSION_NAME}")

export AWS_DEFAULT_REGION=ap-northeast-2
export AWS_ACCESS_KEY_ID=$(echo $temp_role | jq .Credentials.AccessKeyId | xargs)
export AWS_SECRET_ACCESS_KEY=$(echo $temp_role | jq .Credentials.SecretAccessKey | xargs)
export AWS_SESSION_TOKEN=$(echo $temp_role | jq .Credentials.SessionToken | xargs)

# assume-role 이후
# aws deploy push 를 통해 S3 업로드
# aws deploy create-deployment 통해 code deploy 배포 진행