Polymor!

kernel parameters

Megan Kim — Sun, 4 Dec 2022 13:56:46 +0900

ssh 로그인 없이 통신하기

Megan Kim — Thu, 28 Apr 2022 15:21:25 +0900

client> ssh serverHostname@serverIP 인 상황일때

client --------------------->--------------->-------------------->--------- server

1. ssh-keygen -t rsa

-> ~/.ssh/ 밑에 id_rsa(비밀키) , id_rsa.pub(공개키)생김

2. id_rsa.pub(공개키)를 server로 옮김 ~/.ssh/authorized_keys 파일에

3. ~/.ssh/known_hosts 에는 서버 rsa공유키 cat /etc/ssh/ssh_host_rsa_key.pub

값이 ~/.ssh/id_rsa.pub 이랑 다를수있음

이랬는데도 안되는 케이스가 있다..

1. REMOTE HOST IDENTIFICATION HAS CHANGED!"

> client-server 연결이 최초가 아닐때 발생할 수 있는 에러

client> ~/.ssh/known_hosts 라는 파일은 기존에 연결된 적이있는 서버의 rsa 공유키가 저장된다.

근데 현재 접속하려는 서버의 rsa 공유키가 달라져있다면 문제가 생기는 것이다.

[3] 과정대로 하던가, 혹은 서버가 내 접속권한이 없는 상황이라면,

client> ssh-keygen -R serverIP 로 초기화 시켜준다.

추가적으로, [3] 에서 /etc/ssh/ssh_host_rsa_key.pub 가 아니라 ~/.ssh/id_rsa.pub 을 했을때 안될 수 있으니 유의해라.

ssh 통신 과정에서 서버의 rsa 공유키 체크를 etc/ssh/ssh_host_rsa_key.pub 이 위치에 있는 것을 하는 듯하다.

2. rsa 공유키 인증 로그인이 아예 안될 때

server> vi /etc/ssh/sshd_config [루트 권한으로 들어가야함]

#주석이 있다면 풀어주세요.

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

3. client> ~/.ssh/id_rsa 의 권한 문제

owner를 제외한 그룹,other 에 read,write,execute권한이 부여되있을 경우 이 비밀키를 신뢰하지않아 효력잃게됨.

client> chmod 600 ~/.ssh/id_rsa

내가 너무 일하기가 싫어서 ... 젠킨스 (1)

Megan Kim — Wed, 9 Mar 2022 13:30:18 +0900

마지막으로 글을 쓴지 1년이 되었다.

지난 해 3월을 끝으로 다시 글을 쓰게 된건 조금 부끄러운 일이다.

그동안 글을 못쓴 이유와 다시 쓰는 이유는,

1. 회사에 취업했다.

2. 회사의 인터넷망은 웃기게도 티스토리 24시간 차단이다.

3. 이 회사는 놀랍도록 레거시하게 서비스를 운영한다.

4. 그래서 불만이 많은 사람들은 아름다운 CI/CD를 구축하고자한다.

5. 그 대표적인 젠킨스를 어느정도 공부했고, 현재 이 툴을 사용하고 있고 이제 이걸 정리할 시간이 된 것같다.

으악!

이 자만한 표정의 아저씨가 젠킨스다. 그리고 저 고래는 Docker..

솔직히 말해서 젠킨스 별거 없다 생각했다. 한 2주면 다 하지않겠어? 라고 생각했지만 그건 내가 자만했던것..

어떠한 테크를 현업에 도입할 때엔 아래와 같은 순서가 필요하다.

1. 현 업무 중 사람이 하지 않아도 되는일과 사람이 꼭 해야하는 일 구분 하기.

2. 사람이 하지 않아도 되는 일을 대신 하게될 적당한 툴 찾기/만들기 (여기서 나는 젠킨스를 채택)

3. 구체적으로 업무 흐름도에 맞게 설계하기

- git commit 되면 개발팀이 운영팀에게 구두로 전달 ====> git polling 커밋 시점 인지 [젠킨스가 해줌]

- git 에서 local pc 로 다운로드 받기 ====> git clone해서 jenkins서버로 가져옴 [젠킨스가해줌]

- stage 서버에 반영사항 배포 하고 테스트 ====> 개발자가 작성한 shell 실행하여 배포 자동화 [젠킨스가 해줌]

- 이전 버전의 백업 파일 local pc에 보관(규칙따윈없음) ====> 날짜에 맞게 파일 백업 및 관리해줌 [젠킨스가 해줌]

- 실서버에 반영사항을 서버에 배포하기 ====> 개발자가 작성한 shell 실행하여 배포 자동화 [젠킨스가 해줌, 실수없이!]

- 배포 후 테스트 진행 ====> test 시나리오 job 으로 테스트 진행 및 결과 로깅 [젠킨스가 해줌]

- rollback 을 해야할 때 직접 백업 파일 옮겨다 재배포 ====> rollback 시나리오 job으로 자동 재 배포 [젠킨스가 해줌]

4. 젠킨스를 설치한다.

5. 필요한 플러그인을 다운로드 받는다.

6. 젠킨스 서버와 당사 서버들 간 방화벽 설정을 한다. (인프라팀 요청)

7. 스테이지 서버를 타켓 서버로 설정하고 3의 과정의 flow를 구현해낸다.

8. 테스트를 거듭하고 실제 사용을 하며 안정화 및 고도화 작업 한다.

9. 팀장님께 결과를 보여드린다.

10. 실서버에 젠킨스를 도입하여 프로세스를 전환한다.

11. 모니터링 툴, 로그 툴, 그리고 도커까지 계속하여 고도화 작업을 진행한다.

끝 ! 그럼 이제 젠킨스 빌드 버튼을 누르면 알아서 내가 1시간 넘게 해야 했던 일들을 2~3초만에 해준다.

rollback이 더이상 두렵지도않다. 사람보다 소프트웨어가 정확하고 신속하니까.

다시한번 말하지만 정말 일이 하기가 싫어서 젠킨스를 구축한거다.

[Spring] JPA 쿼리 분석 (1) 연관관계 정의

Megan Kim — Thu, 11 Mar 2021 12:08:17 +0900

1 : N (일대다) 연관 관계를 갖는 Cart와 CartItem을 상상하자.

1개의 Cart는 N개의 CartItem을 가질 수 있다. 양방향 연관관계 매핑을 아래와 같이 한다.

CascadeType.ALL은 영속성을 전이하는 것이다. Cart의 영속성이 연관관계를 갖는 CartItem list Entities에 전이되는 것 뿐이다.그러나 Cart가 CartItem의 변경감지를 대신해주진 않음 절대로.

// Cart Entity 

@OneToMany(fetch = FetchType.LAZY,mappedBy="cart",cascade = CascadeType.ALL, orphanRemoval = true)    // 02-15 Megan
    private List<CartItem> cartItems;

// CartItem Entity

@ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "cart_id")

* Cart가 가지고 있는 연관 엔티티 CartItem 들 중 하나의 quantity 값을 수정한다고 가정하자.

1. Cart 영속성 : 없음 -> CartItem 영속성 : 없음

( @Service logic에는 @transactional 없고, getCartItems()는 cart 엔티티 내부 메서드이다. != repo)

 public void UpdateItemQuantity(long cartid,Integer quantity) {

        
         Cart cart = this.findById(cartid);

         cart.getCartItems().get(0).UpdateQuantity(quantity);
        
        

    }

결과: Select 2회 (FetchType.Lazy로 설정했기때문에 getCartItems() 호출 시에 두번째 쿼리가 날라간다.)

Hibernate: select cart0_.cart_id as cart_id1_1_0_, cart0_.account_id as account20_1_0_, cart0_.address as address2_1_0_, cart0_.city as city3_1_0_, cart0_.content as content4_1_0_, cart0_.country as country5_1_0_, cart0_.created_at as created_6_1_0_, cart0_.grand_total as grand_to7_1_0_, cart0_.item_discount as item_dis8_1_0_, cart0_.item_price_total as item_pri9_1_0_, cart0_.province as provinc10_1_0_, cart0_.road_address as road_ad11_1_0_, cart0_.session_id as session12_1_0_, cart0_.shipping as shippin13_1_0_, cart0_.status as status14_1_0_, cart0_.tax as tax15_1_0_, cart0_.token as token16_1_0_, cart0_.updated_at as updated17_1_0_, cart0_.user_discount as user_di18_1_0_, cart0_.zip_code as zip_cod19_1_0_ from shop.cart cart0_ where cart0_.cart_id=?


Hibernate: select cartitems0_.cart_id as cart_id10_2_0_, cartitems0_.cart_item_id as cart_ite1_2_0_, cartitems0_.cart_item_id as cart_ite1_2_1_, cartitems0_.active as active2_2_1_, cartitems0_.cart_id as cart_id10_2_1_, cartitems0_.content as content3_2_1_, cartitems0_.created_at as created_4_2_1_, cartitems0_.discount_price as discount5_2_1_, cartitems0_.price as price6_2_1_, cartitems0_.product_id as product11_2_1_, cartitems0_.quantity as quantity7_2_1_, cartitems0_.sku as sku8_2_1_, cartitems0_.updated_at as updated_9_2_1_ from shop.cart_item cartitems0_ where cartitems0_.cart_id=?

2. Cart 영속성 : 저장 -> CartItem 영속성 : 저장

 public void UpdateItemQuantity(long cartid,Integer quantity) {

        
         Cart cart = this.findById(cartid);

         cart.getCartItems().get(0).UpdateQuantity(quantity);
        
        
         save(cart);
    }

결과 : Select 2회 + update 1회 (Cart는 변경감지 없으므로 CartItem만 update 쿼리날림)

Hibernate: select cart0_.cart_id as cart_id1_1_0_, cart0_.account_id as account20_1_0_, cart0_.address as address2_1_0_, cart0_.city as city3_1_0_, cart0_.content as content4_1_0_, cart0_.country as country5_1_0_, cart0_.created_at as created_6_1_0_, cart0_.grand_total as grand_to7_1_0_, cart0_.item_discount as item_dis8_1_0_, cart0_.item_price_total as item_pri9_1_0_, cart0_.province as provinc10_1_0_, cart0_.road_address as road_ad11_1_0_, cart0_.session_id as session12_1_0_, cart0_.shipping as shippin13_1_0_, cart0_.status as status14_1_0_, cart0_.tax as tax15_1_0_, cart0_.token as token16_1_0_, cart0_.updated_at as updated17_1_0_, cart0_.user_discount as user_di18_1_0_, cart0_.zip_code as zip_cod19_1_0_ from shop.cart cart0_ where cart0_.cart_id=?
Hibernate: select cartitems0_.cart_id as cart_id10_2_0_, cartitems0_.cart_item_id as cart_ite1_2_0_, cartitems0_.cart_item_id as cart_ite1_2_1_, cartitems0_.active as active2_2_1_, cartitems0_.cart_id as cart_id10_2_1_, cartitems0_.content as content3_2_1_, cartitems0_.created_at as created_4_2_1_, cartitems0_.discount_price as discount5_2_1_, cartitems0_.price as price6_2_1_, cartitems0_.product_id as product11_2_1_, cartitems0_.quantity as quantity7_2_1_, cartitems0_.sku as sku8_2_1_, cartitems0_.updated_at as updated_9_2_1_ from shop.cart_item cartitems0_ where cartitems0_.cart_id=?
2021-03-11 11:42:33.445  INFO 1088 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: findOrderIdUsingGET_1
Hibernate: update shop.cart_item set active=?, cart_id=?, content=?, created_at=?, discount_price=?, price=?, product_id=?, quantity=?, sku=?, updated_at=? where cart_item_id=?

3. Cart 영속성 : 변경감지로 인한 저장 -> CartItem 영속성 : 저장

@transactional 
public void UpdateItemQuantity(long cartid,Integer quantity) {

        
         Cart cart = this.findById(cartid);

         cart.getCartItems().get(0).UpdateQuantity(quantity);
        
        
         cart.updateItem(1000,10,10);
         
    }

결과 : Select 2회 + update 2회

Hibernate: select cart0_.cart_id as cart_id1_1_0_, cart0_.account_id as account20_1_0_, cart0_.address as address2_1_0_, cart0_.city as city3_1_0_, cart0_.content as content4_1_0_, cart0_.country as country5_1_0_, cart0_.created_at as created_6_1_0_, cart0_.grand_total as grand_to7_1_0_, cart0_.item_discount as item_dis8_1_0_, cart0_.item_price_total as item_pri9_1_0_, cart0_.province as provinc10_1_0_, cart0_.road_address as road_ad11_1_0_, cart0_.session_id as session12_1_0_, cart0_.shipping as shippin13_1_0_, cart0_.status as status14_1_0_, cart0_.tax as tax15_1_0_, cart0_.token as token16_1_0_, cart0_.updated_at as updated17_1_0_, cart0_.user_discount as user_di18_1_0_, cart0_.zip_code as zip_cod19_1_0_ from shop.cart cart0_ where cart0_.cart_id=?
Hibernate: select cartitems0_.cart_id as cart_id10_2_0_, cartitems0_.cart_item_id as cart_ite1_2_0_, cartitems0_.cart_item_id as cart_ite1_2_1_, cartitems0_.active as active2_2_1_, cartitems0_.cart_id as cart_id10_2_1_, cartitems0_.content as content3_2_1_, cartitems0_.created_at as created_4_2_1_, cartitems0_.discount_price as discount5_2_1_, cartitems0_.price as price6_2_1_, cartitems0_.product_id as product11_2_1_, cartitems0_.quantity as quantity7_2_1_, cartitems0_.sku as sku8_2_1_, cartitems0_.updated_at as updated_9_2_1_ from shop.cart_item cartitems0_ where cartitems0_.cart_id=?
2021-03-11 11:42:33.445  INFO 1088 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: findOrderIdUsingGET_1
Hibernate: update shop.cart set account_id=?, address=?, city=?, content=?, country=?, created_at=?, grand_total=?, item_discount=?, item_price_total=?, province=?, road_address=?, session_id=?, shipping=?, status=?, tax=?, token=?, updated_at=?, user_discount=?, zip_code=? where cart_id=?
Hibernate: update shop.cart_item set active=?, cart_id=?, content=?, created_at=?, discount_price=?, price=?, product_id=?, quantity=?, sku=?, updated_at=? where cart_item_id=?

(참고) FetchType.Lazy vs FetchType.Eager

# fetchType.LAZY - cartItem 정보 없음

Hibernate: select cart0_.cart_id as cart_id1_1_0_, cart0_.account_id as account20_1_0_, cart0_.address as address2_1_0_, cart0_.city as city3_1_0_, cart0_.content as content4_1_0_, cart0_.country as country5_1_0_, cart0_.created_at as created_6_1_0_, cart0_.grand_total as grand_to7_1_0_, cart0_.item_discount as item_dis8_1_0_, cart0_.item_price_total as item_pri9_1_0_, cart0_.province as provinc10_1_0_, cart0_.road_address as road_ad11_1_0_, cart0_.session_id as session12_1_0_, cart0_.shipping as shippin13_1_0_, cart0_.status as status14_1_0_, cart0_.tax as tax15_1_0_, cart0_.token as token16_1_0_, cart0_.updated_at as updated17_1_0_, cart0_.user_discount as user_di18_1_0_, cart0_.zip_code as zip_cod19_1_0_ 
           from shop.cart cart0_ 
           where cart0_.cart_id=?



#fetchType.EAGER - join 해서 다 가져옴

Hibernate: select cart0_.cart_id as cart_id1_1_0_, cart0_.account_id as account20_1_0_, cart0_.address as address2_1_0_, cart0_.city as city3_1_0_, cart0_.content as content4_1_0_, cart0_.country as country5_1_0_, cart0_.created_at as created_6_1_0_, cart0_.grand_total as grand_to7_1_0_, cart0_.item_discount as item_dis8_1_0_, cart0_.item_price_total as item_pri9_1_0_, cart0_.province as provinc10_1_0_, cart0_.road_address as road_ad11_1_0_, cart0_.session_id as session12_1_0_, cart0_.shipping as shippin13_1_0_, cart0_.status as status14_1_0_, cart0_.tax as tax15_1_0_, cart0_.token as token16_1_0_, cart0_.updated_at as updated17_1_0_, cart0_.user_discount as user_di18_1_0_, cart0_.zip_code as zip_cod19_1_0_, cartitems1_.cart_id as cart_id10_2_1_, cartitems1_.cart_item_id as cart_ite1_2_1_, cartitems1_.cart_item_id as cart_ite1_2_2_, cartitems1_.active as active2_2_2_, cartitems1_.cart_id as cart_id10_2_2_, cartitems1_.content as content3_2_2_, cartitems1_.created_at as created_4_2_2_, cartitems1_.discount_price as discount5_2_2_, cartitems1_.price as price6_2_2_, cartitems1_.product_id as product11_2_2_, cartitems1_.quantity as quantity7_2_2_, cartitems1_.sku as sku8_2_2_, cartitems1_.updated_at as updated_9_2_2_ 
           from shop.cart cart0_ 
           left outer join shop.cart_item cartitems1_ on cart0_.cart_id=cartitems1_.cart_id 
           where cart0_.cart_id=?

JPA , hibernate, 그리고 SpringDataApi

Megan Kim — Wed, 24 Feb 2021 14:27:05 +0900

JPA ?

Java Persistence API 라는 뜻으로 Java 진영의 ORM(Object-Relational Mapping) 기술의 표준이다.

객체와 데이터베이스 간의 적절하고 이상적인 매핑은 개발자들의 가장 큰 고민이 될테며 JPA는 이를 해결해주기 위한 솔루션이다.개발자가 JDBC 를 직접적으로 쓰지않고 JPA가 쿼리를 날려주고 영속성을 관리해주는 등 큰 메리트가 있어 Java 개발에 있어 매우 편리함을 제공한다. 가장 큰 이점은 '패러다임의 불일치'(RDB엔 상속,다형성,객체,참조 등과같은 객체지향 성격이없다) 문제를 해결해주는 것이다. 데이터베이스에는 상속관계가 없고 양방향 연관관계가 존재하지않는데, 객체에선 이를 어떻게 바라보고 데이터를 담아내야하는지 등에대한 고민을 하게된다.

public interface EntityManager {

    public void persist(Object entity);

    public <T> T merge(T entity);

    public void remove(Object entity);

    public <T> T find(Class<T> entityClass, Object primaryKey);

}

**참고로 MyBatis는 SPL Mapper이고 JPA는 Object Mapper 이기에 서로 다른 개념이다.

Hibernate vs JPA?

JPA는 Interface이고 Hibernate는 그 JPA 를 구현하는 구현체(Class)이다. 물론 구현체로 hibernate외에 DataNucleus, EclipseLink등 도 있으니 꼭 hibernate를 사용하는 것은 아니다. 'spring-starter-data-jpa'에는 hibernate 기능을 사용하는건 참고하자. 아래와 같은 관계라고 생각하면 편하다.

// JPA interface

public interface JPAInterface{

    void method1(){}
    void method2(){}
    
    
    }

// Hibernate Implementation

public class hiberateclass implements JPAInterface{

	void method1(){ System.out.println("method1"); }
    void method1(){ System.out.println("method2"); }
    
   }

Spring Data JPA?

쉽게말하면 JPA를 한단계 더 추상화한 것이라고 생각하자. 이를테면 우리는 Spring 개발에 있어 entity manager을 직접 가져다 쓰기 보단 repository를 사용하는데, 이것이 바로 JPA를 추상화한 인터페이스이다. Repository 인터페이스의 기본 구현체인 SimpleJpaRepository의 코드를 보면 아래와 같이 내부적으로 EntityManager을 사용하고 있는 것을 볼 수 있다.

public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {

    private final EntityManager em;

    public Optional<T> findById(ID id) {

        Assert.notNull(id, ID_MUST_NOT_BE_NULL);

        Class<T> domainType = getDomainClass();

        if (metadata == null) {
            return Optional.ofNullable(em.find(domainType, id));
        }

        LockModeType type = metadata.getLockModeType();

        Map<String, Object> hints = getQueryHints().withFetchGraphs(em).asMap();

        return Optional.ofNullable(type == null ? em.find(domainType, id, hints) : em.find(domainType, id, type, hints));
    }

}

추가적으로, JPARepository는 무엇이냐?

// JPArepository를 이용하여 memberrepository 만들기

public interface MemberRepository extends JpaRepository<Member, Long> {

Member findByName(String name);

Page<Member> findByName(String name, Pageable pageable);
}

필자는 위와같이 JpaRepository를 뭔지도 모르면서 무작정 갖다썼던 때가 있다. 그러다 생각을 해보니,

MemberRepository 도 인터페이스이고, JpaRepository도 인터페이스일텐데, 대체 class가 없는데 이걸 어떻게 쓰고 있었던거지?

그리고 @Repository는 왜 안붙여도 동작하는거지? 하는 원초적인 질문을 갖게 되었다.

JpaRepository는 기본적으로 CRUD 관련 메소드들만 갖고있는 인터페이스인데 Spring에서 관리를 해주어 실행될때 클래스도 생성되고 빈으로 자동 등록되어 사용가능하게 되는 것이다. 더불어 쿼리까지 생성하여 날려주니 더할 나위없이 편리한 기능들을 제공한다.

JpaRepository 내에 entitymanager 가 있을 것이고 그래서 @Repository 어노테이션을 안붙여도 된다고 한다.

[네이버 라이브 쇼핑]스트리밍 서버 분석 1편

Megan Kim — Fri, 19 Feb 2021 14:40:14 +0900

영상 기반의 이커머스 서비스에 관심을 가지게 된지 벌써 6개월이 지났다.

예상한대로 2021년, 네이버, 쿠팡, 배민 할 것 없이 국내에 내놓아라 하는 IT기업에서 이 서비스를 수면위로 하나 둘 들어내고있다. 그들의 채용 공고만 보아도 앞으로 이 서비스가 얼마나 핫해질지 예상할 수 있다.

그리고 또 하나 주목해야할 중국의 '콰이쇼우'라는 중국판 유튜브로 불리는 이 기업. 올 해 2월 드디어 주식시장에 등판하면서 엄청난 주목을 받고 있다. 머지않아 영상 기술이 시장을 장악할 것이고 이에 대한 관심도는 상승할 것이라고 예상한다.

오늘은 지난달 첫 서비스를 개시한 국내 라이브 커머스 네이버의 라이브 쇼핑*을 이야기 해보고자한다. 기술적인 측면에서 개인적으로 분석해보고 느낀 점들을 작성한 것이니 참고만 하면 좋을 것 같다.

shoppinglive.naver.com/home

네이버 쇼핑라이브

산지에서 해외까지, 생생한 리얼쇼핑

shoppinglive.naver.com

출처; Deview 2019

영상 미디어 스트리밍 개념을 잘 이해할 수 있는 그림이니 참고하면 좋을 것 같다. 오늘 주제는 라스트 마일의 HLS over HTTP이다.

먼저 html 소스 헤더를 잠깐 살펴보면,

async src에 해당하는

https://cdn.jsdelivr.net/npm/hls.js@0.14.16/ 라는 것이 궁금해져서 들어가 봤다.

jsdelivr이라는게 무료로 CDN을 제공해주고 이에 필요한 오픈소스같은 것을 제공받고 있는 것같다. 정확히는 모르겠으나 CDN이 대용량 트레픽과 분산서버를 고려할때엔 영상서비스에서 반드시 필요한 것인걸로 알고 있으나 아직은 서비스 초기단계니 크게 비용을 안들이고 있는게 아닐까?하는 생각이 들었다.

www.jsdelivr.com/

jsDelivr - A free, fast, and reliable CDN for Open Source

Supports npm, GitHub, WordPress, Deno, and more. Largest network and best performance among all CDNs. Serving more than 80 billion requests per month. Built for production use.

www.jsdelivr.com

* 홈 화면

처음 홈화면은 210.89.167.4 에 접속해서 일반적인 이커머스 처럼 필요한 정보들을 GET으로 가져오는 것을 볼 수있다.

8064780 등은 홈 화면에서 보여지는 video 들 정보를 가지고 오는 것 같다. 그리고 각각의 LIVE 비디오들이 꾸준하게 스트리밍 되는 것을 확인 할 수 있다. 이때 접속하는 서버가 달라짐을 볼 수 있다. 아래에서 구체적으로 살펴보자.

* 라이브 스트리밍

총 세가지가 반복되는 것을 볼 수 있다.

상품,판매자에 대한 정보 GET 110.XX.XX.XX --> 좋아요나 커멘트 남기면 POST 110.XX.XX.XX
chunklist.m3u8 GET 211.XX.XX.XX.XX [영상에 대한 정보]
720.stream.ts GET 211.XX.XX.XX.XX [실제 영상 데이터]

211.XX.XX.XX은 CDN 서버가 아닐까 싶다.

라이브스트리밍과 VOD의 가장 큰 차이점은, 라이브 스트리밍은 계속 GET으로 chunk된 영상을 받아온다.

이는 지난번 포스팅에서 말했던 progressive-download / adapt-download 와 연관되있는 것처럼 보였다.

그렇다면 사용되는 프로토콜은? 정답은 HLS 이다.

Content-Type : application/vnd.apple.mpegurl

chunk파일의 확장자 m3u8 - metadata를 가진 manifest 파일

stream파일 확장자 ts

등을 볼 수 있듯, apple사의 HLS 프로토콜을 사용한다.

mpeg-dash 로 변경하겠다는 이야기를 들은 바가 있는데 아직은 거까지 구현은 안된것 같다. free loyalty기술이 아니다 보니 현실적으로 어려움이 있을 것 같다.

HLS official developer site

더불어 html5 <video> 지원 브라우저라면 <video>태그로 웹페이지를 구성하면 된다.

또한가지 주목해볼만한 것은 connection : keep-alive 이다.

엄밀히 말하면 TCP connection을 유지 시켜주는 기능이라 생각하면 된다.

기본적으로 http는 단방향 프로토콜이다. 그래서 매번 Connection은 끊어지고 새로 생성해야한다. keep-alive의 특징은 연결된 소켓에 I/O access가 마지막으로 종료된 시점부터 지정 time-out 시간동안 access가 없어도 세션이 유지된다는 것이다. 이로 인해 성능이 개선 될 수도 있지만, 정적인 웹서버의 경우는 큰 효과는 없고 또한 여러 Client 동시 접속시 과부하를 일으킬 수 도있다.

커넥션 연결시간을 아낄수 있다

* VOD 스트리밍

VOD는 라이브와는 전혀다른 방식으로 영상을 스트리밍하는 것을 한눈에 볼수 있다.

하나의 커넥션으로 지속적으로 받아오는 것을 볼 수 있고

content-type : video/mp4 로 우리가 보통 익히 아는 mp4확장자임을 알 수 있다.

비동기에 대한 이해( feat. Spring @Async)

Megan Kim — Fri, 12 Feb 2021 14:33:40 +0900

지난번 포스팅에서도 한번 작성한 적이 있는 '비동기'라는 주제의 이야기. 아직도 그 끝을 파진 못했지만 공부를 하다 깨달은 점들이 있어서 글을 작성해 봅니다.

*** 결론은 무엇이 비동기,동기 그리고 Blocking, Nonblocking 인지는 어떤 '맥락' 에서인지에 따라 논하는게 맞는 것같다.

그렇지 않으면 상이한 두 개념을 오롯이 이해하기가 만만치않다. 의식의 흐름만 계속되면서 악순환이 마련된다.. 내얘기.....

[비동기 : Asynchronous]

우선 두가지 맥락을 이해하자. 비동기로 '동시성(Concurrency)' 혹은 '병렬성(Parallelism)' 을 구현할 수 있다.

동시성(Concurrency) - '논리적인개념' : 쓰레드가 혹은 프로세스가 다수개

동시성은 CPU코어의 시분할 멀티 태스킹으로 이해하면 될 것 같다. 멀티 프로레싱, 멀티 쓰레딩도 포함 시켜도 된다. 단, CPU 싱글코어라고 가정 했을 때 말이다. (CPU코어는 일을하는 주체 이다. CPU는 매 순간 어떤 프로세스이건 딱 1줄의 명령어를 Fetch해서 '처리'하는 점을 기억하자.)이말은 무엇이냐, 아무리 '동시'에 10개의 독립적인 프로세스(메모리 상에 로드 된 프로그램) 이 실행된다 하여도, 그게 '진짜' 동시간대에 실행되는 것이 아니라, 그렇게 보이는 것 뿐이다. 시분할되어 여러 프로세스를 어떤 우선 순위 큐같은 자료구조에 넣어두고, 사실상 '순차적으로 하나씩' 매우 빠르게 실행되어 동시에 실행되는 것 처럼 보이는 것 뿐이다.

자, 그럼 이게 비동기랑 무슨 연관이 있냐?

다시 10개의 프로세스가 실행되고 있다는 이야기로 되돌아가보자. 1번 프로세스가 종료되어야 2번 프로레스를 실행할 수 있고 2번이 끝나야 3번이 시작될 수 있고.. 이러한 맥락의 상황은 '동기'식 방식이자 앞 프로세스가 'Blocking'을 하고있다 라고 표현 할 수 있다. 그렇다면 1번 프로세스가 버퍼링이 걸려 10분동안 끝나지않는다면, 2번~10번 프로세스는 무한 '대기'상태에 있다. 그렇기때문에, 1~10번 프로세스는 서로 완전 독립적으로 ('비동기') 실행되어야만 동시성이 보장된다. Non-blocking과 물론 연관이 있지만, 이 이야기는 다른 특정 상황의 맥락에서 다시 자세히 살펴보자.

병렬성(Parallelism) - '물리적인 개념' : CPU 코어 즉 프로세서가 여러개

병렬성은 동시성과 다른 개념으로, '한 시점에 정말 여러개의 프로세스가 실행되는 것'을 생각하면 된다. 즉, 최소 듀얼 코어가 보장되어야 병렬성을 구현할 수 있다.

우리가 통상적으로 다룰 '비동기'는 동시성 맥락이 대부분이라고 생각하면된다. 결국 하나의 자원(CPU)를 어떻게 효율적으로 여러 프로세스 혹은 쓰레드가 사용하면 좋을지에 대한 이야기가 앞으로의 내용들이다. 아니, 사실상 하나의 어플리케이션 내의 멀티 쓰레드를 이야기 하게 될 것이다. 비동기 구현을 위해 Fork 로 프로세스를 새로 생성하면서 발생하는 컨텍스트 스위칭은 하는 것보다 Thread를 생성하는 것이 훨씬 효율적이다. Stack외엔 공유된 메모리 자원을 사용하기 때문에 복사될 데이터의 양이 훨씬 더 적기때문이다.

비동기를 그럼 어떻게 이해하면 좋을까? "A라는 작업과 B라는 작업이 발생 순서에 서로 영향을 주지않는 것"

통상적으로 비동기적 프로그래밍을 구현하기 위해 멀티쓰레드를 기반으로 하게된다고 알고 있다. 그렇다면 '비동기는 무조건 멀티 쓰레드이고 Non-Blocking이네?' 라고 이해하면 될 것인가? 정답은 아니다.

I/O 를 핸들링 하는 대표적인 '비동기' 함수로 알려져 있는 SELECT() 함수를 떠올려보자. (Blocking + Async)

SELECT는 기본적으로 커널에게 다수의 file descriptor들에 대한 감지된 I/O 이벤트 정보를 요청하여 변화를 포착하였을 때 리턴된다. 이 맥락에서 즉 SELECT함수는 Blocking함수라는 것이다. 포착되기 전엔 호출한 곳으로 커널에서 제어권을 넘기지 않는다. 단 여기서 중요한 것은, 일단 감지가 되어 호출한 곳으로 돌아가고 난 후에 다음 로직들이 실행되는 동안에도 파일 디스크립터에 대한 I/O 이벤트 감지 업무는 실행 되고 있다. 여기서 이 맥락이 바로 비동기라는 것이다! 꼭 쓰레드를 생성하지 않아도, 맥락상 비동기가 구현되는 것이다.

참고로 epoll은 select 처럼 계속해서 정보를 넘기지 않기 위해서 관찰 대상인 fd들의 정보를 담은 저장소를 직접 운영체제가 담당한다.

* Spring에서 두가지 맥락의 비동기가 있다. - Controller layer VS Service layer

다음 두 상황을 가정하고 비교해보자.

하나의 서버에 10만명이 A라는 CONTROLLER에 request를 보냈을때, 어떻게 처리할 것인가?

먼저 알아야 할 점은, Spring의 Bean은 Singleton-Pattern을 따른다. 싱글톤 패턴은 다수의 요청에도 해당 클래스에 대한 인스턴스는 하나만 생성이 된다. 불필요한 메모리 누수를 방지할 수 있다는 장점이 있다.

Spring bean에 등록된 객체는 싱글톤을 따르기때문에, 하나의 객체만이 Heap영역에 있고 , 클라이언트 Thread 들에서 그 객체를 공유케된다. 즉, 메소드 영역의 메소드만 공유하게 해주는 하나의 인스턴스가 등록되는 것이라 생각하자.

그래서 필연적으로 해당 객체에는 상태(State) field를 가지고 있으면 하나의 공유 자원에 대한 Thread-Safe가 보장이 되지않겠다. 다시 말해, Thread-Safe는 기본적으로 보장되지않는다.

Singleton 패턴을 조금 더 생각해보자. - 어떻게 해야 Thread-Safe하게 구현 할 수 있을 것인가?

Eager Initialization 은 컴파일 타임에 Class Loader 가 정적 바인딩을 통해 인스턴스를 생성하는 것을 의미한다. 이렇게 인스턴스를 생성하지 않고 Runtime에 동적 바인딩으로 객체가 필요할 때, 즉 클라이언트의 요청이 왔을 때 생성하면 synchroized 를 통해 생성해야하는데, 이는 불필요하게 매번 블로킹이 되기때문에 비효율적이다.

public class Singleton {
    // Eager Initialization
    private static Singleton uniqueInstance = new Singleton();

    private Singleton() {}

    public static Singleton getInstance() {
      return uniqueInstance; 
    } 
}

다시 이야기해서 Client들의 요청은 개별 쓰레드로 동시에 처리가 되는 맥락에서 '비동기'적인 처리라고 말할 수 있다.

아~ 그런데 오해하지말자. 100만개의 요청을 위해 100만개를 직접 Thread 생성하고 삭제하는 것은 절대아니다!! Thread는 기본적으로 임계값이 있기 때문에 이것은 Thread Pool 로 JVM이 관리하는 영역으로 문제가 해결이 된다. Thread Pool 을 사용하면 매번 생성, 삭제를 할 필요없이 재사용 가능하다. Thread도 Context-Switching 비용이 부담이 있기때문에 훨씬 효율적이다.

*(번외) Thread Pool 와 DB Connection pool 의 크기, 실행 쓰레드 최대 개수 등은 같을까?

당연히 다르다. 매번 Request 마다 DB를 접속하는 것은 아니기때문에 1:1 매핑일리없다. 참고로 Connection Pool도 싱글톤 패턴이다.

A라는 SERVICE 안에서 a라는 작업과 b라는 작업을 서로 순서 무관하게 동시에 진행하고 싶을때 어떻게 할 것인가?

=> 이 맥락에서 비동기 @Async 가 사용되는 것이다.

물론 앞서 이야기했던 기본적인 자바,스프링의 쓰레드 개념과 동일한 개념이지만, 강조하고 싶은것은 '비동기'를 논할 때는 항상 맥락을 우선적으로 파악하는 연습이 중요하다고 생각해서 굳이 분리를 한 것이다.

*본론 : Spring에서의 비동기 @Async 에 대해 이야기해보자

[AWS] RDB 와 스프링 연동하기

Megan Kim — Wed, 10 Feb 2021 17:10:58 +0900

AWS 제품 중 RDB 인스턴스를 스프링과 연동하는 법에 대해 살펴봅시다.

* Amazon EC2 : Amazon Elastic Computing Cloud - A사 클라우드 컴퓨팅 제품들 중 가장 핫한 제품이라고 볼 수 있다.

우선, AWS에서 프리티어로 RDB 인스턴스를 생성합니다. 프리티어는 12개월간 무료로 한정된 리소스를 사용하는 타입입니다. 제공 범위 초과하여 사용할 시 요금이 부과되는데, 예를들어 SSD 20GB가 최대인데, 21GB 사용시 요금 부과된다. 금수저가 아니라면 주의하자.

인스턴스 생성은 몇가지 옵션만 설정하면 곧 바로 10분내로 생성이된다. 이때 신경써야할 옵션은 다음과 같다.

1. 본인이 필요로하는 데이터베이스의 엔진 선택.

나는 MariaDB(MySQL과흡사) 를 사용할 예정이므로 다음과 같이 택했다.

2. 'Public Access Allow' 옵션 사용하기

인스턴스 생성 시 'Public Access Allow'를 해주어야만 범용적으로 사용이 가능하다.

3. VPC 에서 인바운드 규칙 추가하기

보안을 위해 허용 ip와 포트번호 범위를 추가한다. VPC 보안 그룹에서 인바운드 규칙을 설정하여 allow/deny 할 IP 등을 설정해줄 수 있다. 참고로 VPC는 Virtural Private Cloud의 약자로, EC2의 네트워킹 계층으로서 사용자가 정의하는 가상 네트워크라고 볼 수 있다.

인바운드 규칙을 설정하지않으면 스프링 부트 실행시 TCP CONNECTION TIMEOUT 에러가 발생한다.

*인스턴스 생성이 완료 되었으면, 이제 스프링 Web Application에서 기존에 사용하던 Local DB가 아닌, AWS RDB를 연결해보자. [Gradle 기준]

1. Dependencies 추가

// build.gradle

runtimeOnly 'org.mariadb.jdbc:mariadb-java-client'

2. applications.properties (혹은 application.yml)

server.port=스프링 서버의 포트 

/* 필수 */
spring.datasource.url=jdbc:mariadb://인스턴스 엔드포인트/생성데이터베이스명
spring.datasource.username= 인스턴스 유저명
spring.datasource.password= 인스턴스 패스워드

driver-class-name= org.mariadb.jdbc.Driver
spring.jpa.database-platform=org.hibernate.dialect.MariaDBDialect

/* 선택 */
spring.jpa.show-sql=true
spring.jackson.property-naming-strategy=SNAKE_CASE
spring.jpa.generate-ddl=true
spring.jpa.hibernate.ddl-auto=validate
createDatabaseIfNotExist=true

* 생성 데이터베이스 명은 아래에서와 같이 미리 만들어야 사용할 수 있다. 'DB 식별자'와는 다른 것이니 에러에 주의하자.

* DDL-AUTO = CREATE를 두고 스키마에 테이블을 생성해도 되지만, 나는 별도로 Command Line으로 셋팅하였다.

또한 Docker 가상 환경 MySQL 에서 작성한 것을 참고하길 바란다.

docker exec -i -t mariadb bash

root@e7e28e122e3d:/# mysql -h <인스턴스엔드포인트> -P <포트번호> -u <유저네임> -p

Enter Password : <유저패스워드>

mysql > CREATE SCHEMA `shop`

		CREATE TABLE `shop`.`product`
(
    `product_id`     BIGINT      NOT NULL AUTO_INCREMENT,
    `seller_id`      BIGINT      NOT NULL,
    `title`          VARCHAR(50) NOT NULL,
    `meta_title`     VARCHAR(50),
    `slug`           VARCHAR(50) ,
    `sku`            VARCHAR(50),
    `price`          INT         NOT NULL DEFAULT 0,
    `discount_rate`  INT        DEFAULT 0,
    `quantity`       INT         NOT NULL DEFAULT 0,
    `thumbnail_path` VARCHAR(200)         DEFAULT NULL,
    `image_path`     VARCHAR(200)         DEFAULT NULL,
    `content`        TEXT                 DEFAULT NULL,
    `created_at`     DATETIME    NOT NULL,
    `updated_at`     DATETIME             DEFAULT NULL,
    `published_at`   DATETIME             DEFAULT NULL,
    `starts_at`      DATETIME             DEFAULT NULL,
    `ends_at`        DATETIME             DEFAULT NULL,
    PRIMARY KEY (`product_id`),
    UNIQUE INDEX `uq_slug` (`slug` ASC),

    CONSTRAINT `fk_product_account`
        FOREIGN KEY (`seller_id`) REFERENCES `shop`.`account` (`account_id`)

);

위와 같은 방법으로 스키마와 테이블을 잘 생성하였으면 이제 스프링을 돌려보자.

그럼 다음과 같이 API를 통해 실행하였을 때 Query문이 잘 실행되는 것을 볼 수 있다.

API request 실행 to Spring

insert query 실행 to RDB

이렇게 하면 스프링과 EC2 DB 연동을 마무리 되었다.

Spring Web 어플리케이션을 EC2 클라우드 서버를 통해 배포하는 것과 스트리밍 서버를 연동 시키는 과정을 해볼 예정이다.

[e-commerce] JPA 영속성 전이(feat.상품을 장바구니에 담기)

Megan Kim — Sun, 7 Feb 2021 23:50:30 +0900

본격적으로 구체적인 기술 구현에 초점을 둔 글을 써본다. 나와 같은 상황에 처해 고민을 하는 누군가에게 도움이 조금이나마 되길 바라며 공유의 차원에서 성실하게 작성해본다.

기본적으로, 이커머스에서 상품을 구입하는 과정에서 크게 세가지 프로세스를 거친다.

상품을 장바구니에 담는다.
장바구니에 담긴 아이템들을 주문한다.
주문한 아이템들에 대한 결제를 한다.

상품을 장바구니에 담는 것 vs 장바구니 아이템을 주문하는 것

이 두가지를 비교하고자 실제 상용화된 이커머스 서비스를 들여다보면, 후자보다 전자의 프로세스가 훨씬 가볍다는 것을 알 수 있다.

장바구니에선 수량을 변경하고 배송지를 수정하고 아이템을 삭제할 수 있다. 설령 품절이 되어도 주문전에만 감지하면 되니 빠른 동기화는 필요없다. 반면 오더창으로 넘어가게 되면 모든게 FIX된 정확한 데이터들이어야만 하므로 훨씬 견고하게 움직여야한다.

*상품을 장바구니에 담을 때 DB 에 쿼리를 날릴 것인가?

이 점을 두고 팀원들이랑 정말 생각 이상의 긴 회의를 하게 되었다. Frontend 에서 product 와 관련된 데이터들을 보내줄 것이고, 이걸 이용해서 cart item 을 만들면 된다라는 주장과, 아니다, DB 에서 해당 productid로 쿼리를 날려 데이터를 받아와야한다는 주장이었다.

결론적으로 말하면, 전자의 방법이 이상적이나, 현재 우리의 시스템에선 cart item 은 productid를 참조하고 있고 , 이를 위해선 필연적으로 DB에 쿼리를 날릴 수 밖에 없었다.

/***** cartitem entity ****/

@Entity
public class CartItem {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long cartItemId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "product_id")
    private Product product;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "cart_id")
    private Cart cart;
    
    이하 생략 
    
    
    }

/****** product entity  ******/

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long productId;


    @OneToMany(mappedBy= "productId", cascade = CascadeType.ALL, orphanRemoval= true)
    private List<cartItem> cartItems = new ArrayList<cartItem>();
    
    이하 생략 
    
    }

/***** cart entity  *****/

@Entity
public class Cart {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long cartId;


    @OneToMany(mappedBy= "cartId", cascade = CascadeType.ALL, orphanRemoval= true)
    private List<cartItem> cartItems = new ArrayList<cartItem>();
    
    이하 생략 
    
    }

cartItem 을 저장하려면, 즉 em.persist(cartItem) 이 가능해지려면, cartItem 엔티티와 연관관계를 가지고 있는 엔티티가 JPA 영속 상태여야만한다.

Frontend에서 아무리 product의 엔티티 모든 필드를 DTO로 전달하고 이를 '객체'엔티티로 만들었다해도, 이것은 그저 비영속 컨텍스트이다. 주의해야한다. 필연적으로 DB에 em.find(productid,product.class) 와 같이 쿼리를 보내야한다.

* Cartitem의 생명주기에 따른 관리

우선 , 현재 Cart와 CartItem은 '양방향 연관관계'를 가지고 있으며 그 연관관계의 주인은 FK를 가진 CartItem이다.

CartItem은 Cart가 먼저 생성이되어야 생성될 수 있고, Cart가 삭제되면 마찬가지로 삭제된다. 이로서 CartItem의 생명주기는 Cart에 의존적이다. 여기서 말하는 생명주기는 서비스 로직 내의 생명주기보다는 Cart 와의 의존성의 의미가 더크다.

이런 상황에서는 cascade = CascadeType.ALL(영속성전이) , orphanRemoval = true (고아객체) 옵션을 쓰기 시기 적절하다고 판단한다.

영속성 전이는 부모 엔티티를 영속화 하거나 삭제하는 등의 행위에 함께 자식 엔티티들도 적용시키는 옵션이다.

/****** 영속성 전이를 사용하지 않을 경우 *********/

// 부모(Cart) 저장
Cart cart = new Cart();
em.persist(cart);

// 1번 자식(CartItem1) 저장
CartItem cartItem1= new CartItem();
cartItem1.setCart(cart);
cart.getCartItem().add(cartItem1);
em.persist(cartItem1);

// 2번 자식(CartItem2) 저장
CartItem cartItem2 = new CartItem();
cartItem2.setCart(cart);
cart.getCartItem().add(cartItem2);
em.persist(cartItem2);

/****** 영속성 전이를 사용하는 경우 *********/

CartItem cartItem1= new CartItem();
CartItem cartItem2 = new CartItem();


Cart cart = new Cart();

cartItem1.setCart(cart);
cartItem2.setCart(cart);

cart.getCartItem().add(cartItem1);
cart.getCartItem().add(cartItem2);

// 부모(Cart) 저장, 연관된 자식들(1,2) 저장
em.persist(cart);

영속성 전이는 연관관계를 매핑하는 것과는 아무런 연관이 없으며, 그저 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공한다. 그래서 위와 같이 cartItem들을 cart에 연관관계를 추가한 후 cart를 영속 상태로 만드는 것을 확인할 수 있다.

위와 같이 한 트랜잭션에서 카트와 카트아이템들이 생성되는 경우는 없지만(Cart는 선 트랜잭션 상에서 만들어진 후, 다음 트랜잭션에서 cartItem을 추가함) , Cart에서 CartItem들을 '관리하고 책임하는 객체' 라는 객체지향적 관점에서 사용하게 되었다.

POST /api/cartitem vs POST /api/cart/{id}/cartitem

첫번째로 API로 쓰게 되면, Cart 객체의 책임이 적어진다. Cart 객체는 CartItem들을 효과적으로 관리하기 위해 존재하는 객체라고 생각하기 때문에 CartItem이 단독적으로 생성되고 수정되고 삭제되는 일은 어울리지 않는다.

또한, CartItem의 추가,수정,삭제 등에 따라 Cart의 TotalPrice,Quantity 등 값이 업데이트 되어야하는 점을 고려했을때도 일리가 있다.

따라서, CartItem 은 항상 Cart에 add를 해주고 영속성 전이로서 Cart가 관리하게 해야한다. 특히 Cart가 삭제되는 경우 빛을 발한다.

다음으로 고아 객체는 왜 사용하는게 좋을 것인가에 대한 이야기다. 고아 객체는 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능이다. 정말 정말 중요한 것은 이 기능은 연관 엔티티를 참조하는 것이 나 하나일 때만 사용해야한다.

예를 들어, CartItem과 Product 가 양방향 연관관계를 가지고 있다면, 이 기능은 절대 사용해선 안된다.

Cart 가 CartItem 을 주도적으로 관리하고 있기 때문에 사용 가능한 것이고, 'CartItem'을 낱개 단위로 삭제하는 상황에서 매우 편리하다.

/***** 고아 객체 옵션 사용한 경우 ******/

Cart cart = em.find(Cart.class, cartId);

cart.getCartItems().remove(0);   // 첫번째 아이템 제거됨
em.flush(cart);  // 이 시점에 DB에 Delete 쿼리 날라감. 혹은 transaction끝날때

Cart의 첫번째 아이템을 삭제 하는 경우 위와 같이 Cart에서 연관관계를 끊어내면 자동으로 delete쿼리가 날라간다. 다시 이야기하지만, 이 기능은 특정엔티티가 개인 소유하는 엔티티에만 적용하여야한다. 즉 @OneToOne 혹은 @OneToMany 에서 말이다.

결론적으로, Cart 객체는 CartItem을 관리하는 유일의 부모의 역할을 해내야하는 객체로 바라보아야한다.

Cart없는 CartItem은 없고, CartItem없는 Cart는 무의미하다.

한가지 더 알아야하는 것은 'fetch = FetchType.LAZY' (지연로딩) 이다. Cart에서 지연로딩을 사용하지 않으면 매번 CartItem들이 즉시로딩되면 이는 N+1 문제를 야기한다.

CartItem.getCart().메소드() 를 통해서 CartItem이 주체가 되어 필요에 의해 Cart에 의존관계를 맺어야할지 등에대한 고민이 있다. 분명한건 CartItem이 FK를 들고있고 연관관계의 주인이기때문이다.

Cart의 List<CartItem>은 GET /api/cart 같은 상황에선 반드시 필요할 것 같으나, 실질적으로 cartitem 을 관리하는 건 cartitem 본인이 되어야 더 깔끔한 로직이 나올 수도 있을 것같다.

고민을 해결하고자 작성하였으나 결국 고민만 더 늘고 끝났다. JPA는 강력하고 견고하지만 , 이를 잘 써먹으려면 더 많이 깊게 공부를 해야한다는 생각뿐이다. 다만 한가지 얻은게 있다면,도메인을 면밀히 분석하면 그 위에 놓여진 객체들의 역할, 책임 분할에 대한 시각이 생기게 되고 그 한끝차이들이 설계를 좌우한다는 것이다. Cart와 CartItem의 관계 , 그리고 Order와 Payment에 비해 영속성에 대한 부담감이 비교적 적은 데이터들을 품고있다는 것을 생각하니 수월하게 로직의 방향성을 잡을 수 있었다.

* 유레카. 해결책을 찾았다!

Cart가 전적으로 Cartitem을 관리하는 방향으로 결정했다.

 @OneToMany(fetch = FetchType.LAZY,mappedBy="cart",cascade = CascadeType.ALL, orphanRemoval = true)   
    private List<CartItem> cartItems;

Fetch를 LAZY로 설정해놓으면, 아래와 같이 새로운 cartitem을 add() 할때, 기존에 있던 cartitem들이 프록시엔티티이므로 효율성 문제는 사라진다. 이렇게 Cart만 Save하게 되면, 새로운 Caritem에 대한 INSERT 쿼리 하나만 날라가게된다. (영속성전이)

// CartService 

    public long addItem(long cartid,long productid) {
        Cart cart = findOne(cartid);
        cart.getCartItems().add(CartItem.createCartItem(cart,productRepository.findById(productid).get()));

        return save(cart).getCartId();

    }

마찬가지로 Delete도 아래와같이 구현하면, 해당 cartitem 이 삭제된다. (고아 객체)

public long delete(long cartid, long cartitemid) {
        Cart cart = findOne(cartid);
        cart.getCartItems().remove(cartItemRepository.findById(cartitemid).get());
        return save(cart).getCartId();
    }

[e-commerce] Rest API 설계 디자인

Megan Kim — Sun, 7 Feb 2021 10:28:57 +0900

*RESTful API에 대한 기본 이론 설명은 생략하겠습니다.

Rest에 대한 기본적인 이해와 그 규칙들을 좀 체계적으로 공부해보고싶은데 영어 원서에 대한 부담이 없다면 , 책살돈이 없다면(?), 아래 pdf를 제본해서 보길 추천한다. 번역본들은 거의 다 사야되는데.. Mark Masse 저자의 'REST API Design Rulebook' 이 교재는 꽤 유명해서 서치하면 잘 나오는데 책말고 pdf도 있으니 아래 링크에서 확인하면 된다.

github.com/indrabasak/Books/blob/master/REST%20API%20Design%20Rulebook.pdf

indrabasak/Books

CS Books. Contribute to indrabasak/Books development by creating an account on GitHub.

github.com

매우 짧아서 이틀이면 다볼 수 있다.

개인적인 조언이지만.. Rest에 관한 규칙들은 생각보다 저자들마다 하는말이 좀 달라서 이것 저것 레퍼런스 참고하면 머릿속만 복잡해지지 실무에 딱딱 적용시켜보기가 만만치않다. 꼭!! 책을 통해서 전체 큰 숲을 보고 적용시켜보는 과정을 거치면 좋겠다.

먼저, 이 글을 읽는 당신이 이커머스 REST API를 설계하고자한다면 아래 레퍼런스에서 큰 그림을 먼저 그리며 필요한 요소들이 뭔지 쓱 느낌을 알면 좋을 것같다. 보통 커머셜한 사이트에서 자사 API 지원 도큐멘트들은 차고넘치나 도움이 별로 안되는데! 이건 좀 도움을 많이 봤다.

docs.clover.com/reference

API Reference Overview

docs.clover.com

[ 자 이제 진짜 알겠으니깐 이커머스에 필요한 핵심 API들을 다루어보자 ]

* * 규칙 및 설계 가이드

- CRUD 에 기반한 기본적인 API 먼저 구현하면서 가이드라이닝을 하는것이 효과적이다.

: 막상 해보다보면 Account 같은건 GET 이 많고 , Cart 같은건 PUT이 많다. 그래도 기본 CRUD를 다 구현하는 걸 목표로 잡고하자.

- '수정' 은 가급적 꼭 'PUT' 메소드를 사용할 것. 어떤 이는 'POST'로 작업을 하는데 이는 PUT이 지원안되는 브라우저시절이있었기때문에 통용해서 썼다는데 우리는 경험을 하기위한 것이니 'PUT' 사용하기.

- 국룰이라고 말하는 ' 복수형 명사 ' 사용하기. 예를 들어 회원 삭제를 /account/delete/{id} 이런식으로 동사형은 지양하도록 하겠다.

Account

	GET	POST	PUT	DELETE
회원 추가		/accounts/
회원 정보 조회	/accounts/{id}
회원 정보 수정			/accounts/{id}
회원 삭제				/accounts/{id}

회원 추가 (POST), 즉 회원 가입 의 경우엔 상세 항목들은 RequestBody에 JSON 방식으로 아래와 같이 들어간다.

Address

	GET	POST	PUT	DELETE
배송지 목록 조회	/accounts/{id}/addresses/{id}
배송지 추가		/accounts/{aId}/addresses/
배송지 수정			/accounts/{id}/addresses/{id}
기본 배송지 설정			/accounts/{id}/default-address/{id}
배송지 삭제				/accounts/{id}/addresses/{id}

* 기본 배송지는 어떻게 관리할 것인가?

보통 이커머스를 살펴보면, 배송지는 개인정보랑 따로 관리를 하고, 기본 배송지도 지정할 수 있다. 예를 들어 아래를 보면, 기본 배송지로 어떤 배송지를 택을 하면 페이지 reloading 없이 ajax 로 POST로 패킷이 날라간다. (참고로 마켓컬리는 PUT이 거의 없다.)

나는 default address 를 db 상에서 따로 테이블을 만들어서 관리하고 있고, account-defaultaddress 와 같은 조인테이블을 생성했다.

address 테이블에 default라는 필드를 만들어서 상태를 관리해도 좋을 듯했으나, 여러 고민끝에 조인 테이블을 만들었다.

Product

	GET	POST	PUT	DELETE
상품 조회	/products?category={id}
상품 추가 (seller)
상품 수정 (seller)
상품 삭제 (seller)

상품은 굉장히 많기 때문에 보통 카테고리로 관리가 된다. 또한 상품은 Seller account type을 가진 회원만이 추가,수정,삭제를 할 수 있다.

그리고 Tag 로 상품을 검색할 때나, '추천순','별점순' 등으로 랭킹을 해야하기 때문에 질의문이 굉장히 많이 쓰이게된다.

이 부분은 다음에 따로 다룰 예정이다.

<진행중>

Cart

GET	POST	PUT	DELETE

CartItem

Order

OrderItem

Payment