모던플로우

Key-Value-Store 만들면서 겪은 이슈

모플로 — Sun, 20 Aug 2023 22:46:50 +0900

Key-Value-Store를 구현하는 과정에서 docker-compose를 사용했는데 기대하던 실험 결과가 나오지 않았습니다.

그래서 제가 만난 이슈와 해결방법에 대해 공유하려합니다.

간단한 Key Value Store 프로젝트 소개

GitHub - hojihun5516/key-value-store

Contribute to hojihun5516/key-value-store development by creating an account on GitHub.

github.com

1) User는 Proxy 서버로 데이터 저장을 요청합니다.

2) Proxy 서버는 해시링을 통해 적절한 Store 서버에 저장을 합니다.

3) Store 서버는 1초에 1번씩 redis에 헬스 카운트를 올리고, Service Discovery는 5초에 한번씩 Store서버가 죽었는지 확인합니다.

4) 죽은 Store 서버가 있다면 Service Discovery 서버는 Proxy 서버로 '해시링에서 죽은 스토어 서버를 제거' 하라는 요청을 보냅니다.

-> "cap, pacelc 이론을 통해 스토어 서버가 장애시 PA로 가용성을 보장하고, 일반 상황시 EL로 일관성을 희생하여 더 적은 지연 시간을 가져간다" 라는 실험주제입니다.

제가 원하는 실험방법은 초당 n*100 번의 Request를 보내는데 도중 Store 서버 1개를 중단시키고 장애가 복구되는 과정을 모니터링 하는것입니다.

아래 그림은 제가 구현한 서버의 구성도입니다.

Situation

Store A를 제거했을 때 전체 요청 중 약 '1/3이 실패 응답', '2/3가 성공 응답'으로 오길 기대했습니다.

하지만 Store A를 제거했을 때 Proxy 서버로부터 응답 속도가 지연되면서 요청수 자체가 줄어들었습니다.

Task

가장먼저 에러로그를 확인했습니다.

java.net.SocketTimeoutException: Read timed out

java.net.ConnectException: Connection timed out

java.net.SocketException: Connection reset
        at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:323) ~[na:na]
        at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) ~[na:na]

Store A를 제거했을 때 매번 다른 에러가 떴습니다.

Connection이 잘 안돼서 pending이 걸리는것같은데... 라는 생각이 들었고,

Store 서버를 종료했는데도 불구하고 죽은 Store A서버에 요청을 보내고 응답을 기다리는게 이해가 안됐습니다.

그리고 가끔씩 원하는 방향대로 성공했는데 이 때 뜨는 에러는 아래와 같은 UnknownHostException이였습니다.

java.net.UnknownHostException: store-service-1
        at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:567) ~[na:na]
        at java.base/java.net.Socket.connect(Socket.java:633) ~[na:na]

Action

저는 위의 에러 로그로부터 힌트를 얻었습니다.

UnknownHostException이 떴을때는 실험이 잘 됐기 때문에, Store A 서버를 죽였을때는 dns서버가 Store A 서버를 제대로 인식하지 못해야 한다고 생각했습니다.

그래서 docker의 dns캐시에 대해 알아보게됐습니다.

docker는 dns가 내부적으로 사용되고 있고, dns를 통해 service name과 ip를 맵핑시켜서 통신합니다.

***

컨테이너 통신

- Docker Compose에서는 서비스 이름을 사용하여 다른 컨테이너에 접근할 수 있습니다.

- 이는 내부적으로 Docker의 DNS 서버가 관리하며, 서비스 이름을 해당 컨테이너의 IP 주소로 변환합니다.

***

처음엔 Docker Process를 끄면서 동시에 DNS서버를 강제 리프레쉬 하는 방향을 생각했지만 공식문서를 찾아봐도 관련옵션이 없어서 다른 방법을 생각했습니다

제가 생각한 방법은 Connection Timeout을 핸들링 하는 방법입니다.

같은 Docker network에서 connection timeout을 낮추는 방법을 선택했습니다.

극단적으로 1ms는 너무 낮은값이지만 같은 도커 네트워크 환경이고, 실험을 위해 사용하는 방법이기 때문에 괜찮다고 판단했습니다.

Result

Store A 서버를 죽였을 때

장애시 PA를 통해 전체 요청중 1/3이 실패, 2/3이 성공 응답이 오는것을 확인할 수 있었습니다.

RabbitMQ 자세히 알아보자

모플로 — Wed, 2 Aug 2023 08:10:49 +0900

1. RabbitMQ 란?

서버간 메세지를 전달해주는 오픈소스 메세지 브로커입니다.
RabbitMQ는 AMQP프로토콜을 구현한 메세지 브로커입니다.

AMQP란?

AMQP란 Advanced Message Queuing Protocol로 client application과 middleware broker와의 메세지를 주고 받기 위한 프로토콜이다.

2. 구조

1) Producer

메시지를 보낼 때 RabbitMQ에 직접 연결하고 메시지를 publish(발행)합니다.

2) Exchanges

Exchange는 받은 메시지를 하나 이상의 Queue에 라우팅(전달)합니다.

라우팅 방식은 Exchange의 타입에 따라 다릅니다.

- Direct Exchange: Routing Key가 특정 Queue의 Binding Key와 정확히 일치할 때 메시지를 해당 Queue로 라우팅합니다.

- Topic Exchange: Routing Key와 Binding Key 사이에 와일드카드 매칭을 허용하여 메시지를 라우팅합니다.

- Fanout Exchange: Binding Key를 무시하고 모든 연결된 Queue에 메시지를 브로드캐스트합니다.

- Headers Exchange: Routing Key를 무시하고 메시지의 헤더 속성을 기반으로 메시지를 라우팅합니다.

3) Bindings

Binding은 Exchange와 Queue 사이의 연결을 정의합니다.

Binding을 통해 Exchange는 어떤 Queue에 메시지를 전달할지 결정합니다.

4) Queues

Queue는 메시지를 저장하는 버퍼입니다. 각 Queue는 메시지를 받아서 저장하고, Consumer가 처리할 준비가 될 때까지 메시지를 보관합니다.

5) Consumer

Consumer는 Queue에 연결되어 있으며, 메시지가 Queue에 도착하면 그 메시지를 가져와서 처리합니다.

3. 언제 쓰는건데?

사실 이 글을 쓰는 주요 목적입니다.

예시가 있다면 이해가 빠르죠!

1) 서비스 설계 상황

- MSA 서비스(계정, 쿠폰, 알림)로 구성되어 있습니다.

2) 비즈니스 요구사항

- 회원가입을 하면 가입 환영 쿠폰을 발급해줍니다.

- 회원가입을 하면 가입 인사 이메일을 전송합니다.

3) 해결방법

3-1) message Queue를 쓰지 않는다면?

가입 시 자동으로 이벤트 참여를 시키려면 회원가입(signUp)함수에 지속적으로 추가해야합니다.

이렇게 되면 회원가입이라는 함수는 많은 일을 하게되고 비즈니스 복잡도가 증가하게 됩니다.

물론 이 방법으로도 비즈니스 요구사항을 해결할 수 있습니다.

// 계정서버
fun signUp(userSignUpRequest: UserSignUpRequest){
	...
    val createdUserEntity = userRepository.save(userEntity)
    
    couponClient.issueSignUpCoupon(userId = createdUserEntity.id)
    notificationClient.notifySignUpEmail(userId = createdUserEntity.id)    

}

3-2) message Queue를 쓴다면?

Producer(계정)서버에서 가입 이벤트를 발행하고, 가입한 행위를 필요로하는 Consumer(쿠폰, 알림)들이 메시지를 받아갑니다.

이렇게 작성하면 회원가입 함수는 회원가입을 하고 가입 이벤트를 발행하는 일만 할 수 있습니다.

회원가입 했을 때 추가적인 비즈니스 요구사항이 생기면 계정서버의 작업은 필요 없이, 메시지를 받아서 작업하면 됩니다.

이때는 Direct를 쓰는게 명확하다고 생각합니다

// 계정서버
fun signUp(userSignUpRequest: UserSignUpRequest){
	...
    val createdUserEntity = userRepository.save(userEntity)
    userSignUpEventProducer.publish(
        event = userEventFactory.userSignUpEvent(userEntity = createdUserEntity),
    )
}

// 쿠폰 서버
fun receiveUserSignUpMessage(payload: Long, message: Message): Any? {
	issueSignUpCoupon(userId = payload)
}

fun issueSignUpCoupon(userId: Long){
	...
}

// 알림 서버
fun receiveUserSignUpMessage(payload: Long, message: Message): Any? {
	notifySignUpEmail(userId = payload)
}

fun notifySignUpEmail(userId: Long){
	...
}

4. 메시지 유실에 대해

1) 사례

이 챕터는 제가 일을 하던중 겪은 이슈를 정리하기위해 추가했습니다.

메시지를 수신하여 외부 서비스 api 호출을 하는 작업을 했는데, 인증 만료로 401 ERROR가 발생했습니다.

지속적으로 외부 서비스에 401 ERROR를 발생시켰고 뒤늦게 발견하게 됐습니다.

2) 분석

제 로직은 Exception을 던졌고, messageQueue에도 제대로 성공했다는 메시지를 보내지 못했습니다.

rabbitMQ는 성공 메시지를 받지 못해서 메시지를 유실시키지 않게 하기위해 실패한 메시지를 다시 큐에 쌓아둡니다.

이 상황이 계속 반복되어 실패하는 메시지를 통해 외부 서비스를 계속 호출하는 이슈를 만났습니다.

Consumer가 메시지를 성공적으로 처리했음을 RabbitMQ에 알리는 것은 중요합니다.
이것이 "acknowledgment"이며, 이를 통해 RabbitMQ는 메시지를 큐에서 안전하게 제거할 수 있습니다.
만약 이 ack가 전송되지 않으면, RabbitMQ는 메시지가 처리되지 않았다고 가정하고 다른 Consumer에게 메시지를 다시 전송할 것입니다.

git 폴더별 유저 설정

모플로 — Thu, 16 Feb 2023 21:07:46 +0900

https://modernflow.tistory.com/158

한 디바이스에 git 계정 여러개 등록

회사에서 깃을 사용하던 중 제 개인 계정도 등록하고 싶어서 공부하게 됐습니다. 1. ssh key 생성 - 경로 이동 cd ~/.ssh - 키 생성 - 여기서 제 깃 이메일과 -f라는 옵션으로 구체적인 파일명을 적어주

modernflow.tistory.com

위의 과정을 따라하고 오시길 바랍니다

# ~/.gitconfig-personal 
[user]
        email=hojihun5516@daum.net
        name=hojihun5516

#~/.gitconfig

[user]
        name = jihoonheo
        email = company@company.com

[includeIf "gitdir:~/next-step/"]
        path = ~/.gitconfig-personal

[includeIf "gitdir:~/numble/"]
        path = ~/.gitconfig-personal

[core]
        autocrlf = input

두개의 파일을 위와같이 설정해주면 됩니다

Database Index는 언제 써야하는가?

모플로 — Sun, 22 Jan 2023 22:46:53 +0900

1. 배경

개발자 친구들과 이야기를 하던중 sql tuning작업을 통해 조회 쿼리 속도를 높였다는 이야기를 들었습니다.

막연하게 떠오르는 생각은 "아! 당연히 Indexing을 했겠구나" 였지만 그때 문득든 생각이 있습니다.

Indexing은 쿼리 조회 속도를 높이고 Index를 갱신를 갱신하기 때문에 CUD에 대해서는 느리다
그렇다면 로그를 남기는 것과 유사한 기능을 제외하고, 많은 비즈니스 기능은 빠른 조회를 필요로하는데 이런 테이블에 전부 인덱싱을 해야하는게 좋을까?

제가 찾은 결론부터 말하면 "아니다" 입니다.

DB에서 데이터를 스캔하는 방식은 풀스캔(Full Scan)과 인덱스 스캔(Index Scan)이 있습니다.

위의 친구같은 경우는 풀스캔으로 되어있던 방식을 인덱스 스캔으로 변경하여 조회 속도를 높인 케이스입니다.

2. 스캔 종류

1. 풀스캔(Full Scan)

- Application에서 SELECT * FROM USER WHERE ID = 10; 이라는 쿼리요청이 온다.

- 테이블 전체 데이터를 디스크에서 메모리로 옮긴 후 모든 데이터를 조사해서 ID가 10인 USER를 반환한다.

2. 인덱스 스캔(Index Scan)

- Application에서 SELECT * FROM USER WHERE ID = 10; 이라는 쿼리요청이 온다.

- 인덱스에서 필요한 데이터가 있는곳을 조사해서 필요한 데이터 블록만 읽는다. (인덱스를 조회해서 필요한 블록만 읽는다)

- ID가 10인 한건의 데이터가 들어있는 USER 테이블의 데이터 블록만 선택적으로 읽고 반환한다.

2-1 인덱스 구조

인덱스 구조에대한 글이 아니라서 가볍게 설명하겠습니다

1) B 트리

- 루트, 브랜치, 리프 구조로 리프노드에 데이터블럭의 위치를 저장한다

2) 해시테이블

- 해시함수를 사용하여 변환한 값을 인덱스로 사용하여 키와 데이터를 저장하는 구조입니다.

3. 그렇다면 언제 풀스캔이 유리한가?

테이블의 데이터를 모두 가져가야 하는경우
테이블의 데이터가 많이 없는 경우

풀스캔은 한번의 I/O로 가능한 한 크기의 데이터를 읽어서 I/O수를 줄여줍니다.

위의 경우에서 인덱스 스캔을 하게 된다면 읽어야 하는 데이터 블록이 늘어나고, 하나씩 읽어가며 I/O횟수도 늘어납니다.

항상 인덱싱을 하는게 좋은게 아니라,

특정 키 조회를 자주 쓸때, 필요한 인덱스 구조를 고민해보고 작성해야 한다고 생각합니다.

Restful API 설계

모플로 — Sun, 8 Jan 2023 23:50:09 +0900

이 글을 쓰는 이유

고민

- 저는 현재 회사에서 msa구조를 갖고 서비스를 개발중입니다.

- 새로운 기능을 개발하는 도중 자원을 표현하는 계층을 어떻게 표현해줘야 할까?라는 고민을 했습니다.

- 본문 하단에 고민에 대한 테스크와 결과를 적어두었습니다.

1. Restful api가 나온 이유

- 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST(Representational State Transfer)를 발표했습니다.

- Rest를 직역하면 자원(리소스)의 표현에 의한 상태 (정보) 전달이라고 해석할 수 있습니다.

- 조금 풀어서 해석하면 웹에 존재하는 모든 자원에 고유한 URL을 부여하여 활용하는 것을 의미합니다.

2. Restful api란?

- REST 아키텍처 스타일을 따르는 API를 REST API라고 합니다.

- REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 합니다.

- 그렇기에 Restful한 api와 Rest api는 같은의미로 사용할 수 있습니다.

3. Rest 아키텍쳐 스타일

1. URI는 자원의 위치를 표현한다.

- id가 1인 아이템을 조회한다.

# good
GET /items/1

#bad
GET /my-item/listup/1

2. HTTP Method (GET, POST, PUT, DELETE 등)를 사용하여 자원에 대한 행위를 표현합니다.

# 아이템을 등록한다
POST /items
body {"title":"초코 아이스크림", "price": 1000, "type":"snack"}

#1번 아이템을 가져온다
GET /items/1

#snack타입인 아이템들을 가져온다
GET /items?type=snack

#1번 아이템의 가격을 바꾼다
PATCH /items/1
{"price":1200}

#1번 아이템의 title과 type을 바꾼다
PUT /items/1
{"title": "해리포터와 마법사의 돌", "price":1000, "type":"book"}

#1번 아이템을 DB에서 지운다
DELETE /items/1

위의 설계대로라면 Entity는 아래처럼 유추해볼 수 있습니다

class Item(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    val title: String = "",

    val price: Int,

    val type: ItemType,
)

enum class ItemType{
    BOOK, SNACK ... ;
}

2-1 Put vs Patch

Put

- 요청을 일부분만 보낸 경우 나머지는 default 값으로 수정되는 게 원칙으로 바뀌지 않는 속성도 모두 보내야 합니다.

- 그렇기 때문에 해당 api를 사용하는 클라이언트는 resource의 상태(값)를 알고 있어야합니다.

- 해당 resource에 값이 없으면 요청 받은 body로 create해줘도 무방합니다.

- 그렇기에 1번을 요청하든 100번을 요청하든 멱등성이 보장됩니다.

Patch

- 하나의 resource에 하나의 property를 변경합니다.

- 멱등성을 보장하지 않습니다.

4. 고민한 테스크

4-1 문제

- msa구조로 Accounts서버와 Products서버가 나눠져있습니다.

- 쇼핑몰로 예를들면 유저가 좋아요를 클릭한 아이템과 조회한 아이템에 대한 정보를 Accounts서버에 저장해주어야 합니다.

- 클라이언트의 정렬 조건등에 의해 아이템의 type을 같이 저장해주어야 합니다.

4-2 접근

- 확장 가능성을 고려하여 테이블은 좋아한 아이템, 조회한 아이템을 따로 설계를 했습니다.

- 하나의 테이블에서 관리하지 않고, 두개의 테이블에서 관리하기 때문에 api도 분리했습니다.

- 하나의 테이블로 관리하지 않았기 때문에 api에서도 다른 데이터라는 사실을 분명히 드러냈습니다.

4-3 api 스펙 작성

* header authorization Bearer ey~~~~~ -> 모든 요청에 JWT토큰을 사용해서 유저 정보를 식별함 (생략)

#사용자가 아이템을 조회했을 때 최근 본 항목에 등록한다
POST /accounts/viewed-items
body {"itemId":1, "type":"snack"}

#사용자가 아이템에 대해서 좋아요를 클릭했을때 좋아한 목록에 등록한다
POST /accounts/liked-items
body {"itemId":1, "type":"snack"}

#사용자가 좋아한 아이템을 수정한다
PUT /accounts/liked-items
body {"itemId":1, "type":"book"}

#사용자가 좋아한 아이템들을 조회한다
GET /accounts/liked-items

#사용자가 좋아한 아이템을 제거한다
DELETE /accounts/liked-items/1

위의 스펙을 보고 아래와 같은 entity를 유추해볼 수 있습니다.

class UserLikedItem(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    val userId: Long = 0L,

    val itemId: Long = 0L,

    val itemType: ItemType = UNKNOWN,

    val likedAt: LocalDateTime = LocalDateTime.now(),
)    

enum class ItemType{
    UNKNOWN, BOOK, SNACK ... ;
}

4-4 스펙 고민

1) 논리적 경로

- liked-items와 viewd-items는 논리적으로는 items라는 폴더로 묶어도 괜찮지 않을까?

- 그렇다면 아래처럼 가능하지 않을까?

GET /accounts/items/liked-items
GET /accounts/items?type=liked

결정: 논리적으로는 그럴 수 있지만, 실제 데이터의 위치를 표현하는게 설계를 직관적으로 꼬지않고 하는것이라고 생각해서 4-3처럼 작성했습니다.

2) Post

- 아래처럼 POST의 URI 무언가를 식별하는 키를 같이 넣어주면 안되는가? 라고 생각했지만 이는 잘못된 설계임을 알게 되었습니다.

- URI는 데이터를 식별하는 정보로 사용되어야 합니다.

- URI의 정보를 활용해서 데이터를 등록하면 안됩니다.

# bad
POST /accounts/liked-items/1
{"type":"book"}

# good
POST /accounts/liked-items
{"itemId":1, "type":"book"}

결정:

- 4-3처럼 등록했습니다

- 또한 1번 아이템에 대해 멱등성을 보장해야한다면 POST가 아닌 PUT이 올바르다고 생각합니다.

5. 추가적인 생각

- 모든 api를 restful 하게 가져갈 수 없지만, restful하게 가져갈 수 있는 api라면 최대한 아키텍처를 지켜주는게 좋다고 생각합니다.

- restful api가 나온 이유에 대해 생각해보고, 클라이언트 개발자가 api 문서만 보고도 어떤 행위를 하는 api인지 파악할 수 있다면 잘 작성한 문서라고 생각합니다.

- 추가적으로 독자님의 비슷한 경험이나 판단 근거에 대해서 댓글 달아주시면 정말 감사하겠습니다!

위키피디아에 더 자세한 추가 설명이 나와있습니다.

한 디바이스에 git 계정 여러개 등록

모플로 — Mon, 3 Oct 2022 15:37:08 +0900

회사에서 깃을 사용하던 중 제 개인 계정도 등록하고 싶어서 공부하게 됐습니다.

1. ssh key 생성

- 경로 이동

cd ~/.ssh

- 키 생성

- 여기서 제 깃 이메일과 -f라는 옵션으로 구체적인 파일명을 적어주었습니다

ssh-keygen -t rsa -C hojihun5516@daum.net -f hojihun5516 (개인계정)

ssh-keygen -t rsa -C company@company.com -f company (회사계정 임시로 company라고 사용)

2. public key 복사

cat hojihun5516.pub

- 위의 명령어로 나온 내용을 복사하여 github->settings->ssh keys에 등록해줍니다

3. ssh config 생성

cd ~/.ssh

vim config

Host github-hojihun5516
	HostName github.com
	User hojihun5516@daum.net
	IdentityFile ~/.ssh/hojihun5516

Host github-myNickname
	HostName github.com	
	User company@company.com
	IdentityFile ~/.ssh/company

4. 디바이스에 ssh 등록

ssh-add hojihun5516

ssh-add company

에러가 날 경우 eval $(ssh-agent) 실행하고 다시 등록

5. 클론 받으셔도되고 remote 변경해서 테스트 해보셔도됩니다~

AWS Codepipeline-Elasticbeanstalk-free tier 자동 배포(3)

모플로 — Tue, 22 Feb 2022 23:57:24 +0900

Codepipeline 생성

2. 소스 스테이지

- Github v2를 사용합니다.

- 연결에 원하는 Repository 혹은 계정을 등록해줍니다.

- Observer가 해당 repository의 branch를 보고있다가 변경이되면 해당 파이프라인이 실행됩니다.

3. 빌드 스테이지추가

- 저는 환경변수를 사용해야했기 때문에 제가 작성한 prod.env 파일의 내용들을 빌드 프로젝트에 추가했습니다.

- 완료한 이후 빌드스테이지탭에서 다음을 눌러주세요

4. 배포스테이지 추가

5. 배포기다리기

6. ElasticBeanstalk에 환경변수 넣어주기

- 환경속성 입력해주고 저장한다음 반영하는데에는 생각보다 오래걸려요

다시 접속해보면 배포가 완료되어있습니다.

해당 튜토리얼을 해보시고 생략해도 되는부분이 있다면 알려주시면 감사하겠습니다.

AWS Codepipeline-Elasticbeanstalk-free tier 자동 배포(2)

모플로 — Tue, 22 Feb 2022 23:57:10 +0900

Elastic Beanstalk 생성

애플리케이션이름, 환경이름만 넣고 아래와 같이 세팅했습니다.

** 추가옵션 구성 **

1) 환경생성

2) 네트워크 수정

- 아래 데이터베이스 서브넷도 체크해주세요

- t2 micro는 가용영역이 2a와 2c만 허용한다고 하네요

접속

AWS Codepipeline-Elasticbeanstalk-free tier 자동 배포(1)

모플로 — Tue, 22 Feb 2022 23:57:01 +0900

1.설명하기에앞서 CICD를 위해 시도한 것들

githubaction
ECR - ECS(EC2) - ALB

Github Action은 사용하기 편했습니다.
marketplace가 존재하여 원하는 flow는 쉽게 찾을 수 있었습니다.
ECR - ECS(EC2)를 활용하여 배포를 했는데 t2-micro(프리티어용) 인스턴스로는 CD를 할 수 없었습니다.
ENI가 최소 3개가 필요한데 t2-micro는 2개만 지원하기 때문에 아무리 soft memory를 줄여도 이를 해결할 수 없었습니다.
fargate를 사용한다면 쉽게 해결할 수 있겠지만 사이드 프로젝트라서 비용부분을 줄이고 싶었습니다.

그래서 요즘 많이 사용한다는 codepipeline을 사용해봤습니다.
AWS의 codepipeline은 github뿐 아니라 다른 repository에서도 코드를 참조할 수 있었습니다.

elasticbeanstalk는 Paas로 생각보다 좋았습니다.
제가 코드에 집중할 수 있는 환경을 만들어주었습니다.

2. project에 필요한 files

1) Procfile
프로젝트 root에 Procfile을 만들어주세요

web: npm run deploy

2) buildspec.yml
프로젝트 root에 buildspec.yml을 만들어주세요

version: 0.2
phases:
  install:
    commands:
      - 'npm ci'
  build:
    commands:
      - 'npm run build'
artifacts:
  files:
    - '**/*'

3) package.json
package.json의 scripts부분에 해당 deploy명령어를 추가해주세요

"scripts": {
...
"deploy": "npm ci && npm run build && npm run start:prod"
}

터미널에서 git 인증 id, pw 안될 때

모플로 — Mon, 17 Jan 2022 16:51:47 +0900

step1.

root 아래에 .git-credentials 파일 생성

step2.

github -> settings -> developer settings 에서 token 발행 (발행 권한 맨위에 1개만 체크해도 됨) - repo 권한

step3.

step1에서 생성한 .git-credentials 아래에 https://[user id]:[token]@github.com 을 입력

ex) https://hojihun5516:ghp_ynQb3Y21Q1XdybCfoID4gq6j8pW3w1ubO@github.com

step4.

터미널에 git config --global credential.helper store 입력

모던플로우

Key-Value-Store 만들면서 겪은 이슈

간단한 Key Value Store 프로젝트 소개

Situation

Task

Action

Result

RabbitMQ 자세히 알아보자

1. RabbitMQ 란?

AMQP란?

2. 구조

3. 언제 쓰는건데?

4. 메시지 유실에 대해

git 폴더별 유저 설정

Database Index는 언제 써야하는가?

1. 배경

2. 스캔 종류

3. 그렇다면 언제 풀스캔이 유리한가?

Restful API 설계

이 글을 쓰는 이유

1. Restful api가 나온 이유

2. Restful api란?

3. Rest 아키텍쳐 스타일

1. URI는 자원의 위치를 표현한다.

4. 고민한 테스크

5. 추가적인 생각

한 디바이스에 git 계정 여러개 등록

AWS Codepipeline-Elasticbeanstalk-free tier 자동 배포(3)

Codepipeline 생성

AWS Codepipeline-Elasticbeanstalk-free tier 자동 배포(2)

Elastic Beanstalk 생성

AWS Codepipeline-Elasticbeanstalk-free tier 자동 배포(1)

목차

1.설명하기에앞서 CICD를 위해 시도한 것들

2. project에 필요한 files

터미널에서 git 인증 id, pw 안될 때