[항해99 취업 리부트 코스 학습일지] 3기 22일차 TIL(부제: DP, DB, MSA 프로젝트 관련 공부)

안녕하세요! delay100입니다.

오늘은 DP 문제가 나왔는데.. 음 너무 어려워서 대부분 블로그 글 보고 참고해서 했어요..ㅠㅠ

점화식을 세우는게 너무 어렵네요...

그리고 오늘도 역시 팀 스터디 하루종일 !! 유익한 정보를 나누었습니다!! ㅎㅎㅎ(아래에 정리해둠)

지금은 저녁 11시 6분인데요.. 내일은 정기 쉬는 날(일요일)이기 때문에 좀더 늦게까지 하다가 자려고 합니다..!!

오늘 팀 스터디를 너무 유익하게 많이해서.. Spring 강의를 목표치만큼 못들어서 내일도 좀 들어야할 듯 해요ㅠ ㅠ

그치만 화이팅해보겠습니다!

정규 시간이 지난 오후 11시 7분.. 모여서 추가 공부를 했습니다!

---

오늘의 타임테이블

• 9시~9시40분  팀 스크럼(DB가 트리형태인이유)
• 9시40분~11시30분 DP1문제 해결
• 11시30분~12시40분 점심
• 12시40분~3시 DP3문제 해결
• 3시~4시20분 세션
• 4시20분~ 5시55분 팀원끼리 이야기(DP 이해하기)
• 5시55분~7시 팀원끼리 멘토님께 질문할거 정리 + 토크
• 7시~8시20분 멘토님 순회
• 8시20분~9시10분 팀원끼리 DB락 스터디 및 그 외 면접질문
• 9시20분~새벽 Spring 강의 듣기

 

---

Q. 팀원끼리 한 스터디

 

A1.  DB가 트리 형태인 이유(vs 배열)

챗gpt에게 스터디 내용에 대해  말 정리를 부탁했습니다.

배열의 사용

1. 검색 시간 복잡도와 Auto Increment
   • 배열은 인덱스를 통해 O(1)의 시간 복잡도로 직접 접근할 수 있습니다. 하지만 데이터베이스에서는 일반적으로 배열보다는 트리 구조를 선호합니다. 이는 데이터의 정렬과 검색 효율성을 높이기 위함입니다.
2. 공간 관리
   • 배열에서는 삭제한 요소의 공간을 재사용하지 못하고, null 혹은 비어 있는 값으로 남을 수 있습니다. 이는 메모리 낭비로 이어질 수 있습니다. 데이터베이스에서도 이러한 문제를 최소화하고자 자동 증가하는 Primary Key (PK)와 같은 구조를 사용하여 공간을 효율적으로 관리합니다.

트리의 사용(PICK)

1. 데이터의 정렬과 검색 효율성
   • 트리 구조는 데이터를 정렬된 상태로 유지하면서 검색에 O(log N)의 시간 복잡도를 제공합니다. 이진 탐색 트리와 같은 구조는 데이터베이스의 검색 성능을 높이는 데 중요한 역할을 합니다.
2. 메모리 관리와 성능 최적화
   • 트리는 데이터의 삽입, 삭제 시에도 효율적으로 작동하여 메모리를 효율적으로 사용할 수 있습니다. AVL 트리나 B+ 트리와 같은 균형 잡힌 트리 구조는 데이터베이스의 성능을 최적화하는 데 기여합니다.

왜 데이터베이스는 트리 구조를 선택하는가?

• 성능과 관리의 통합
• 데이터베이스에서는 데이터의 정렬, 검색 효율성을 높이기 위해 트리 구조를 선택합니다. 트리는 데이터의 관리와 메모리 최적화를 함께 고려하여 성능을 향상시킬 수 있습니다.
• 다양한 응용 분야에서의 유리성
• 트리는 다양한 데이터 구조를 표현하고 관리하는 데 유리합니다. 데이터베이스는 파일 시스템, 조직도 등의 데이터를 계층적으로 표현할 때 트리 구조를 사용하여 데이터의 구조화와 관리를 용이하게 합니다.

결론

배열과 트리는 각각의 장단점을 가지고 있지만, 데이터베이스에서는 주로 트리 구조를 선택하여 데이터의 정렬, 검색 효율성을 최적화합니다. 트리는 데이터의 계층적 구조를 표현하고 관리하는 데 적합하며, 데이터베이스의 성능을 향상시키는 중요한 요소로 작용합니다. 따라서 데이터베이스 설계 시에는 데이터의 특성과 검색 패턴을 고려하여 효율적인 트리 구조를 선택하는 것이 일반적입니다.

추가로 참고한 블로그

[DataBase Index에서 기본적으로 HashTable이 아닌 B-Tree를 쓰는 이유]

https://foot-develop.tistory.com/56

DataBase Index에서 기본적으로 HashTable이 아닌 B-Tree를 쓰는 이유

 

A2. [알고리즘] 백트래킹 - 냅색 알고리즘 

i : 무게

배열 : 가지고 갈 수 있는 최대 가치

list[4] = 8 (무게가 4일때 가지고 갈 수 있는 가, 

냅색문제 설명

 

A3. DB 격리수준

 

[격리수준1]read uncommited : 커밋이 안됐는데 다른 트랜잭션이 읽을 수 있는 것 -> 기본적인 db에서는 이걸 안 씀

 [격리수준2]read commited : 커밋이 된거만 읽을 수 있음. -> non-repeatable read 발생

**non-repeatable read: 같은 트랜잭션 내에서 동일한 db에서 들어오는 값이 중요할 수가 있음 

트랜잭션 도중에 계속 다른데서 커밋을 해서 데이터를 수정한 경우에 값이 이상할 수가 있음

 [격리수준3]reapetable read : reapeateable됐을때만 할 수 있게함

a가 시작된 시점에서만 b, c, d, e버전을 들고 옴(a가 처음 시작 했을때의 b, c, d, e 데이터만 가져옴)

나머지 데이터는 b, c, d, e값은 중간에 커밋돼도 에 대해 락에따라 다르게 처리됨
 [격리수준4]phanthom read : 없던 데이터가 생기는 현상

 원래 10개였는데 누가 db에 값을 올려서 11번째꺼를 가져오는 경우

 [격리수준4]serializeable: 트랜잭션을 직렬로 쭉 실행함

 

격리수준2가 기본DB의 격리수준임! 여기서 발생하는 문제는 ROCK을 걸던지 분산락을 걸던지 해야 함

---

Q2. 오늘 진행된 멘토님과 질의응답 시간에 얻은 인사이트는 무엇인가요?

 

A1. 모노리스에서 통합테스트 어떻게 하는지? 부하테스트 어떻게 하는지?

[통합테스트]

실제 API를 호출해서 확인하는 End to END 테스트

*MSA

근데 MSA에서는 End to End 테스트가 쉽지 않음.

그래서 예상 데이터를 만들고 테스트를 하는게 많음, 왜냐? 서버를 다 따로 쓰기 때문에 

AcceptanceTest

databaseCleanUp -> 현재 db에 있는 데이터를 다 날리고 테스트 실행하도록 만든것

통합테스트 코드 예제

 

[부하테스트]

"K6라이브러리 사용법"을 검색

https://sjparkk-dev1og.tistory.com/221

k6를 이용한 부하테스트 방법

 

---

 

A2. 보상 트랜잭션이 뭔지?

=> 분산 시스템에서 트랜잭션의 일관성을 유지하려고 실패된 작업을 되돌리는 트랜잭션

MSA 에서 제일 힘든게 분산 트랜잭션 처리가 힘듦

모노리식과 다르게 MSA는 다 분산 트랜잭션이니까

 

ex) 항공예약, 호텔예약, 렌트카예약은 다 독립적으로 되어있음.

항공, 호텔, 렌트카를 하나의 트랜잭션으로 처리가 된다고 치면 이 모든 3개의 예약에 대해 성공을 해야 함

근데 항공, 호텔 성공했는데 렌트카가 실패했다면 보상 트랜잭션이 실행되면서 항공, 호텔이 다 취소되어야 함 

결제하고 환불하는 식으로 이루어져야 함

(항공에도 실패. 은행에도 실패 트랜잭션을 해야돼서 좀 복잡함)

 

---

A3. kafka의 동작 원리, redis event 나 RabbitMQ 에 비해서 장점이 뭔지?

- kafka

성능이 우수함(초당 수백, 수천만 메세지를 처리할 수 있음)  

대규모 스트리밍 서비스(실시간으로 데이터를 받아와야 하는 것)에 씀

파티션 내에서는 순서가 보장됨

=> 굳이 kafka가 어렵고 비싼데 쓰는 이유? 

데이터가 순서가 보장이 안될때 서버가 엄청 힘들어지면 순서가 보장이 되는 kafka가 좋음

데이터량이 많아졌을때 kafka를 선택하는게 좋음

사실 비용 문제때문에 kafka를 선택하지 못하는거임(너무 비쌈)

 

- redis event

빠른 읽기 쓰기를 제공하긴함. 

순서 보장이 되는지는 설정에 따라 다른데, 설정을 안하면 기본은 설정을 순서보장을 안 함

 

- RabbitMQ

멘토님)

실시간 차량 데이터를 처리하는 경우 10000대정도면 일주일에 4억~8억건 정도 쌓임, RabbitMQ를 이용할때는 n달에 한번씩 서버가 죽었었음 => Kafka로 변경

순서 보장 가능, 클러스터 환경에 따라 메세지가 보장이 안됨(보장을 한다는 확신이 없음)

redis랑 RebbitMQ는 우리 서버가 죽으면 데이터가 보장이 안됨(죽었을때 보장이 안됨)

kafka는 DB나 우리 서버가 죽었을 때 Queue에 계속 데이터를 밀어넣기 때문에 순서 보장, 데이터가 들어옴

 

---

A4. 로컬 - 스프링 클라우드 환경와 aws 실 배포 환경의 차이

로컬 환경

• Spring Cloud: 서비스 디스커버리, API 게이트웨이, 로드 밸런싱 등.
• 로컬 네트워크 설정: 각 마이크로서비스 간 통신 설정 필요.

AWS 실 배포 환경

• AWS 서비스:
  • Elastic Load Balancing (ELB): 로드 밸런싱.
  • AWS API Gateway: API 요청 라우팅.
  • ECS/EKS: Docker 컨테이너 관리.
  • IAM: 권한 관리.
• 네트워크 설정: VPC, 서브넷, 보안 그룹 등.

주요 차이점

1. 로드 밸런싱:
   • 로컬: Spring Cloud Load Balancer
   • AWS: ELB
2. API 게이트웨이:
   • 로컬: Spring Cloud API Gateway
   • AWS: AWS API Gateway
3. 서비스 디스커버리:
   • 로컬: Spring Cloud Netflix Eureka
   • AWS: AWS Cloud Map/ECS 서비스 디스커버리
4. 구성 관리:
   • 로컬: Spring Cloud Config Server
   • AWS: AWS Systems Manager Parameter Store/Secrets Manager

MSA vs. 모노리틱 아키텍처

• 모노리틱 서버: 모든 기능이 하나의 서버에 통합.
• MSA: 각 기능이 독립적인 마이크로서비스로 분리, 네트워크 관리가 복잡.

Docker와 MSA

• 컨테이너화: 마이크로서비스를 독립적으로 배포 및 관리.
• 이식성: 로컬 및 AWS 환경에서 동일하게 실행.
• 자동화: CI/CD 파이프라인으로 배포 자동화.

결론: 로컬에서는 Spring Cloud를 사용해 MSA를 구축하지만, AWS에서는 관리형 서비스를 활용해 효율적으로 운영할 수 있습니다.

 

---

 

A5. 로컬 부하테스트와 실 부하테스트의 차이

차이 없음! 로컬에서도 데이터를 만들어 실 부하 테스트와 동일하게 시뮬레이션 가능.

---

A6. EC2 vs. Docker Compose 독립성

 

• EC2: CPU, 메모리 등을 개별적으로 설정 가능, 독립적인 자원 할당.
• Docker Compose: 공유 자원을 사용하므로 완벽한 독립성 보장은 어려울 수 있음.
• 공통점: 둘 다 가상 컴퓨팅 환경, 자원 분리가 가능.

요약: EC2와 Docker Compose 모두 가상화 기술을 사용하지만, 자원 할당과 독립성 면에서 차이가 있습니다.

 

---

 

A7. 도커의 작동원리, 도커 컴포즈란?

도커 컴포즈란 도커 이미지를 여러개 관리할 수 있는 기술

 

---

 

A8. 재고관리에 배치를 쓰는 게 맞는지?

• 실시간 재고 관리: 주문이 들어오면 즉시 재고에서 차감 (-1). 이 방식은 실시간 재고 상황을 반영합니다.
• 정확한 처리: 실시간 처리가 정상적으로 이루어지므로, 별도로 배치 처리를 돌릴 필요가 없습니다.
• 관리 화면 (Admin): 실시간 재고 상태를 바로 확인할 수 있습니다.

요약: 재고는 실시간으로 관리되므로 배치 처리를 사용할 필요가 없습니다. Admin에서도 실시간 데이터를 확인할 수 있습니다.

 

A9. 증권이나 금융회사 12시에 점검. 뭐하나?

=> "일자 전환"

일자가 중요함(며칠날 결제했는지?) 23시 59분에 요청이 들어온 것에 대해서는 처리

그 사이에는 데이터가 들어오지 못하도록 막아두는거임! 시스템 준비를 위해

 

---

 

A10. 결제에서 대규모 트래픽 처리의 여러가지 방법

말정리가 잘 안돼서 gpt에게 정리를 부탁했습니다!

대규모 트래픽을 처리하는 방법에는 여러 가지가 있으며, 각 방법은 특정 상황에 유리한 장점이 있습니다. 여기 몇 가지 방법과 그에 대한 자세한 설명을 드리겠습니다.

Redis와 분산 락

• Redis 사용:
  • 캐싱: Redis는 고속의 인메모리 데이터 저장소로, 자주 조회되는 데이터를 캐싱하여 데이터베이스(DB) 부하를 줄일 수 있습니다. 예를 들어, 사용자 정보나 제품 가격 같은 자주 변경되지 않는 데이터를 Redis에 저장하면, DB에 직접 접근하는 횟수를 줄여 성능을 향상시킬 수 있습니다.
  • 분산 락: Redis를 이용해 분산 락을 구현하면, 여러 서버가 동시에 자원을 접근할 때 발생할 수 있는 충돌을 방지할 수 있습니다. 분산 락은 특정 리소스에 대한 접근을 제어하여 데이터 일관성을 유지하는 데 유용합니다.
• 분산 락 구현:
  • 재시도 (Retry): 락이 다른 곳에서 사용 중이면, 일정 횟수만큼 재시도를 하도록 설정할 수 있습니다. 예를 들어, 락이 해제될 때까지 3번 재시도하고, 그래도 실패하면 사용자에게 "잠시 후 다시 시도해 주세요"라는 안내 문구를 보여줄 수 있습니다.
  • 은행 자동이체 예: 예를 들어, 케이뱅크에서 신한은행으로 이체할 때 서버가 다운될 수 있습니다. 이런 경우, 23시 50분까지 계속 재시도를 하여 문제를 해결할 수 있습니다. 이 과정에서 무응답이 오거나 boolean 값이 반환되기도 합니다.

유량 제어 (Rate Limiting)

• 트래픽 제한: 유량 제어는 시스템이 처리할 수 있는 최대 트래픽을 설정하여 초과 요청을 제한하는 방법입니다. 예를 들어, 초당 2000번(tps)으로 트래픽을 제한하면, 이를 초과하는 요청은 더 이상 받지 않고 거부할 수 있습니다.
  • 안내 문구: 초과하는 요청이 발생할 경우, 사용자에게 "사용자가 너무 많아 이용할 수 없습니다"라는 안내 문구를 표시합니다. 이를 통해 사용자는 시스템 과부하 상태를 인지할 수 있습니다.
  • 큐 제한: 시스템 과부하를 방지하기 위해, 트래픽 초과 시 요청을 큐에 넣지 않고 바로 거부합니다. 이 방법은 시스템의 안정성을 높이는 데 도움을 줍니다.

재시도 전략 (Retry Strategy)

• 재시도 횟수 설정: 요청 실패 시 몇 번 재시도할지 설정합니다. 예를 들어, 특정 요청이 실패하면 5번까지 재시도하고, 여전히 실패하면 "결제에 실패했습니다. 다시 시도해 주세요."라는 안내 문구를 보여줄 수 있습니다. 이를 통해 일시적인 네트워크 문제나 서버 부하 문제를 해결할 수 있습니다.

은행권 예시

• 타행 이체: 은행 간 이체 시 서버가 다운될 때의 대처 방법입니다. 예를 들어, 케이뱅크에서 신한은행으로 이체할 때 서버가 응답하지 않으면, 재시도 전략을 통해 문제를 해결할 수 있습니다.
  • 배치 및 데몬 서버: 실패한 요청을 큐에 넣고 재시도를 관리합니다. 예를 들어, 23시 50분까지 재시도합니다. 배치 서버나 데몬 서버는 이러한 작업을 자동으로 처리하여 시스템의 안정성을 높입니다.
  • 수기 처리: 재시도가 실패하면, 다른 법인 계좌나 별도 계좌에 수기로 처리할 수 있습니다. 이는 예외 상황에서의 대처 방법으로 사용됩니다.

결론

Redis와 분산 락을 활용하여 실시간 트래픽을 효과적으로 처리하고, 유량 제어를 통해 초과 트래픽을 관리할 수 있습니다. 재시도 전략을 통해 안정성을 높이며, 예외 상황에는 수기 처리 등으로 대응할 수 있습니다. 이러한 방법들은 대규모 트래픽 상황에서도 결제 시스템을 안정적으로 운영하는 데 도움이 됩니다.

 

---

다음주 월요일에 멘토님과 추가적으로 해소할 질문들!

1. 도커와 VM의 차이, 도커가 왜 VM에 비해 장점?
2. 서킷 브레이커 처리는 어떻게 하는지?
3. CQRS 의 이점, 분산 DB의 장점과 단점, db로드밸런서
4. 도커 컨테이너를 잘 모르겠어요.

---

항해99 취업 리부트 코스를 수강하고 작성한 콘텐츠 입니다.

[할인]란에 “추천왕 3기 백지연” 입력 시 10만원 할인
(*얼리버드, 타 혜택 중복 적용 가능)

IT 커리어 성장 코스 항해99, 개발자 취업부터 현직자 코스까지