항해 플러스 백엔드 (2주차 WIL)

2주차 WIL

 

2주차 KPT를 정리합니다.

 

 

 

 

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

 

요구사항

• 아키텍처 준수를 위한 애프리케이션 패키지 설계
• 동시성을 고려한 특강 조회 및 신청 API 서버 구현

 

1주차와 마찬가지로 단순 기능 구현에 대한 어려움은 없었습니다.

 

하지만 다른 온라인 강의를 통해 보기좋은 패키지 설계에 대해 살짝만 알았을 뿐

DIP와 OCP를 준수하기 위한 노력은 하지 안았기에 구조 자체를 잡게 너무 어려웠습니다.

 

또한 이전엔 애플리케이션단에서의 Lock을 구현했다면, 다중 인스턴스에서의 동시성 제어를 위해

DB Lock과 Redis를 사용했는데 둘 다 고민을 크게 하지 않고 사용했던터라 어려움을 많이 겪었습니다.

 

2. 시도

 

공개 Q&A에서 힌트를 얻어 다음과 같이 패키지 구조를 설계하였습니다.interfacesapplicationdomaininfrastructure

 

구조 자체는 괜찮았으나 application에 service를 두어 domain 상태를 변경하는 로직이 application 레이어에 있어DIP를 준수하지 못했습니다.

 

동시성 제어를 위해 실무에서 쓰던대로 메서드에 @transactonal을 통해 제어하려 했으나 접근을 막고동작하지 않게만 할 뿐 일부는 성공하고 일부는 실패하는 현상이 발생하였습니다.

 

창피하지만 Spring에서의 @transactonal은 하나의 작업 단위를 정의할 뿐, DB에 직접적인 Lock을 걸거나 하진 않는다는 사실을 이제야 깨달았습니다.

 

 

3. 해결

 

삽질을 많이해 과제 제출 기한이 임박해 DB 성능은 고려하지 않고 중간에 Redis를 도입하여 동시성을 제어하였습니다.

 

특강 신청 API에는 다음과 같은 두 가지 동시성 조건이 있었습니다.

• 한 강의에는 최대 30명만 선착순으로 신청할 수 있으며 그 이후 신청건은 처리되지 않는다.
• 한 유저는 같은 강의를 한 번만 신청할 수 있으며 그 이후 신청건은 처리되지 않는다.

위 두 조건을 준수하기 위해 현재 강의 신청 인원은 몇 명인지? 해당 유저가 신청을 이미 했는지?를 원자적으로 확인만 할 수 있다면 동시성을 제어할 수 있다고 판단했고 강의 인원은 increment, decrement를 이용, 한 유저의 중복 신청 방지는 setIfAbsent를 통해 해결하였습니다.

 

 

4. 알게된 것

 

Redis를 통해 동시성을 해결한 건 좋았지만 조건을 통과한 데이터들이 동시에 삽입되는 등 DB 부하에 대한 고려는 전혀 하지 못해습니다.

 

큰 서비스도 아니고 간단한 요구조건에 "동시성" 하나만 추가했는데 코드 양은 많지 않더라도 생각의 깊이가 코드를 찍어내는 실무와는 다르다는 것을 느꼈습니다.

 

이후 과제도 동시성 해결이 주 과제가 될 것 같은데 항상 두 가지 측면을 모두 고려하는 습관을 가져보려 합니다.

 

Keep

- 집에 돌아가면 나태해질게 뻔하니 매일 퇴근을 안하고 꾸준히 학습했습니다.

- 어찌저찌 원하던 Pass를 받았습니다.

Problem

- 이번주 코칭 시간을 잘못 예약하여 제출 전 피어 리뷰를 진행하지 못했습니다.

  이후엔 최소 수요일 전 까지는 예약을 해야할 것 같습니다.

- 욕심만 앞서 스터디 시간을 매일로 잡았습니다.

   스케줄을 조정하여 현실적인 시간으로 설정하고 어떻게든 모이려는 노력을 해야겠습니다.

- 어느순간 "성장"이 아닌 "PASS"에만 혈안이 되어 있었습니다.

   학습의 목적을 잊지 않기위해 계속 Remind 해야할 것 같습니다.

Try

- 매주 과제의 학습 Point를 명확히 이해하려 노력해야 합니다.

- "집단지성"의 힘을 믿고 질문하는 습관을 기릅니다.

 

 

 

2주차 주요 학습 Keyword

Clean ArchitectureConcurrencyDIPOCP