[항해99 취업 리부트 코스 학습일지] 3기 23일차 TIL(부제: 집중은 안 되지만 열심히 노력중)

안녕하세요! delay100입니다.

 

월요일이 밝았습니다.. 일요일 하루를 공부 많이 안했다고 긴장이 좀 풀렸어요..

분명 일요일에도 2시간 공부했는데!! 하루종일 너무 집중이 안됐어요..ㅠㅠ 그래도 팀끼리 이야기는  여전히 5시간이나 했고..!? 나름 열심히 하려고 노력은 했습니다...

오늘은 이 글을 마치고 도커(docker) 강의를 듣고 잘거에요! 너무 피곤해서 다는 못듣고 잘거같긴 한데... 우선 빨리 들으러가보겠습니다. 

 

---

오늘의 타임테이블

• 9시~10시 팀 스크럼(잠깨기용 수다 feat.월요병)
• 10시~12시 2문제 해결
• 12시~2시 침대의 유혹(낮잠에..)
• 2시~4시 2문제 해결
• 4시~5시 프로젝트 선택 가이드 꼼꼼히 비교하기(2번 pick)
• 5시~5시50분 프로젝트 선택 공지
• 5시50분~ 7시10분 팀원끼리 이야기(DP 포도주 문제 + MSA 이해하기)
• 7시10분~8시 멘토님 순회
• 8시~8시40분 팀원끼리 Rock 스터디
• 8시40분~9시30분 저녁
• 9시30분~새벽 Docker 강의 듣기

---

Q1. 팀원끼리 한 스터디

 

A1.  DP(백준 포도주_2156번 문제)

dp는 배열의 특정 위치 이전까지의 확정을 구해놓는 특징이 있습니다.

이 문제는 포도주를 3개이상 마실 수 없으므로 특정 위치에 아래와 같은 상황을 적용시킬 수 있습니다.

xoo(안마심, 마심, 마심)

xo(안마심, 마심)

x(안마심)

사진에서 w[i]는 와인, dp는 해당 index까지의 최대 마신 와인이 저장되어 있습니다. 

백준 2156번 문제 해설

 

A2.  MSA 개념

1. 기본적인 개념

• 스프링 부트와 톰캣 서버:
  • 웹 요청 처리: 웹 요청이 들어오면, 서버는 이를 처리하기 위해 하나의 스레드를 사용합니다.
  • 기본 스레드 설정: 스프링 부트의 톰캣 서버는 기본적으로 10개의 스레드를 사용합니다. 즉, 동시에 10개의 요청을 처리할 수 있습니다. 이 스레드는 요청을 받아들이고 처리한 뒤 응답을 보냅니다.
  • 최대 스레드 수: 최대 200개의 스레드까지 사용할 수 있도록 설정할 수 있습니다. 예를 들어, 큰 트래픽을 처리하기 위해 스레드 수를 늘릴 수 있습니다.
  • 최대 TCP 연결 수: 기본적으로 한 번에 10,000개의 TCP 연결을 처리할 수 있습니다. 예를 들어, 이를 10개로 설정할 수도 있습니다. 이 설정은 얼마나 많은 클라이언트가 동시에 서버에 연결될 수 있는지를 결정합니다.
  • 대기열(accept_count): 대기열은 기본적으로 5개로 설정되어 있습니다. 즉, 현재 처리 중인 스레드 외에 최대 5개의 요청이 대기할 수 있습니다. 대기열이 다 차면 추가 요청은 즉시 거부됩니다.

2. 요청 처리 방식

• 요청당 하나의 스레드: 각 요청은 하나의 스레드가 처리합니다. 요청이 들어오면 스레드 하나가 그 요청을 처리하고, 완료되면 다시 사용 가능 상태로 돌아갑니다.
• MSA에서의 유연한 설정: 마이크로서비스 아키텍처(MSA)에서는 각 서비스마다 설정을 다르게 할 수 있습니다. 예를 들어, 주문 서비스(Order Service)와 상품 서비스(Item Service)의 스레드 수와 연결 수를 각각 다르게 설정할 수 있습니다.

3. 스케일링 전략

• 스케일 업:
  • 서버의 성능을 향상시키는 방식입니다. 예를 들어, 더 많은 메모리나 더 빠른 CPU를 추가하여 서버 하나를 더 강력하게 만듭니다.
  • 예시: 한 서버에 10개의 CPU 코어와 32GB의 메모리를 추가하는 것.
• 스케일 아웃:
  • 여러 서버로 나누어 처리하는 방식입니다. 도메인별로 확장할 수 있습니다.
  • 예를 들어, 주문(Order) 서비스에 요청이 몰릴 때, 주문 서비스만 더 많이 실행시킬 수 있습니다. 이를 위해 여러 대의 서버에 주문 서비스를 배포하고 부하를 분산시킵니다.
  • 모든 서비스를 다 확장하는 것이 아니라, 필요한 서비스만 확장할 수 있다는 장점이 있습니다.
  • 예시: 주문 서비스가 몰릴 때, 주문 서비스를 처리하는 서버를 3대에서 10대로 늘리는 것.

4. 모니터링과 독립성

• 모니터링:
  • MSA를 사용하면 각 서비스의 상태를 쉽게 모니터링할 수 있습니다. 예를 들어, 각 서비스의 CPU 사용량, 메모리 사용량, 요청 처리 속도 등을 모니터링 툴을 통해 실시간으로 확인할 수 있습니다.
  • 어떤 서비스가 바쁜지 쉽게 알 수 있습니다. 예를 들어, 주문 서비스가 많이 바쁘다면 주문 서비스의 부하를 줄이기 위해 서버를 추가로 배포할 수 있습니다.
• 독립성:
  • 각 서비스는 독립적으로 관리되고 확장됩니다. 이는 서비스 간의 간섭을 최소화하고, 각 서비스가 독립적으로 동작하게 합니다.
  • 예를 들어, 아이템(Item) 서비스가 바쁜 상황에서 주문(Order) 서비스의 스레드가 많이 생기는 경우는 잘못된 설정입니다. 이 경우, 각 도메인 서비스가 독립적으로 동작하고 확장되는 것이 중요합니다.
  • MSA를 통해 각 서비스가 독립적으로 동작하고 필요에 따라 확장할 수 있으므로, 시스템 전체의 효율성과 안정성을 높일 수 있습니다.

결론

• 요청이 오면 하나의 스레드가 그 요청을 처리합니다.
• MSA는 각 서비스를 독립적으로 설정하고 확장할 수 있습니다.
• 이를 통해 서비스 상태를 쉽게 모니터링할 수 있고, 필요한 서비스만 확장하여 효율적으로 관리할 수 있습니다.
• 예를 들어, 주문 서비스가 많이 바쁠 때 주문 서비스만 추가로 확장함으로써 효율적으로 트래픽을 처리할 수 있습니다. 이를 통해 시스템 전체의 성능을 최적화할 수 있습니다.

order ,item, user, security 로 분리되어있는 MSA

 

A3.  DB rock

3-1-1. 낙관적 잠금

충돌이 생기지 않을 것이라고 생각하고 락을 잠그지 않는 것

만약 A하기 이전에 결과물을 기억해놨다가 A를 하고나서 값이 바뀌어있으면 롤백해줘야 함

=> 개념적인 락이지 DB에 락을 거는 것도 아니고, 구현적으로 락이 걸리는 것도 아님

=> 사실 락이 아님

 

3-1-2. 비관적 잠금

충돌이 생길 것이다하고 락을 거는 것

A(기본 읽기동작)를 읽기만 해도 잠그는 것

B가 와서 쓰기 불가능

 

[잠금의 유형]

3-2-1. 공용 락(조회만)

읽기 가능, 쓰기 불가

내가 만약 student를 읽고 있으면 다른 애가 student를 바꿀 수 없고 읽기 가능

 

3-2-2. 베타 락

내가 쓰기/수정이 목적

내가 student를 수정하고 있을 때 다른 사람이 왔을 때 읽기, 쓰기 불가

 

[락이 걸려있으니까 문제가 생길 수 있음]

문제1. Blocking

베타 락 걸어둔 상태 -> B가 와서 읽고 싶은데 못 읽음 -> C가 와서 읽고 싶은데 못 읽음

 

문제2. DeadLock

A트랜잭션, B트랜잭션이 둘다 1, 2 DB를 쓰려고 함

동시에 A가 1번에 베타락을 걸고 B는 2번에 공용락을 걸어둔 상태

A는 B가 해결되길 기다리고 B는 A가 해결되길 기다리는 상태가 됨(무한 기다림)

---

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

 

---

 

A1. 도커와 VM의 차이, 도커가 왜 VM에 비해 장점인가?

제일 큰 차이점은 도커는 따로 os를 쓰는 것.

VM은 하이퍼바이저를 써서 위에 띄우지만, 현재 사용중인 OS의 종속적임

도커는 OS를 깔고싶은 OS를 쓸 수 있다는 점. 가볍다(이식을 해주면 되니까)_경량성

 

VM은 만약 현재 운영체제가 windows라면 windows말고 다른 os를 쓰려면 다른 하드웨어를 구매해야 함

 

도커는 docker에 window 넣어서 하면 되는거라서 엄청난 이식성임!

도커는 도커 컨테이너에 여러개 띄울 수 있어서 독립적으로 개발할 수 있음

각각의 도커 이미지에 띄우면 이상적인 아키텍쳐임(모듈화) 이식성이 크다!

 

---

 

A2. 서킷 브레이커 처리는 어떻게 하는지?(개념, 구현)

마이크로 서비스끼리 장애관리를 어떻게 하는가?

서킷 브레이커는 서비스 호출할 때 실패를 감지하고 일정 시간동안 실패된 서비스 요청을 차단하는 방식으로 동작하는 패턴임

일정 시간동안 반복적으로 서비스 호출해보고 실패 비율이 높아지면 해당 서비스 자체를 차단하는 식으로 진행

쓰레드풀은 한정적인데 계속 요청이 오면 낭비되니까 차단하는 거임!

서버가 다운되는 것을 막아주는 패턴임 

Spring web에도 있는 정보!(참고하기)

 

---

 

A3. 트레이드오프(Trade-off)시 우선순위 정할 때 가중치로 더 생각해봐야하는것??

시스템 목적이나 요구사항, 제약조건에따라 case by case가 많이 나뉨

우선순위별로 나열하면 아래와 같다.

1. 제일 높다고 생각되는건 "기능, 요구사항"

요구사항은 조회만 하는건데 개발자가 나중을 위해서  "~ 필요하지 않을까?"는 지양해야함

정작 나중에 가면 안쓰기도 하기때문임!

2. "성능"

실시간으로 데이터가 변해야하는데 그게 잘 되는지?

3. "유지보수성"

회사에 있는 이상 계속 개발을 해야하니까(재사용성, 유지보수성)

4. "비용"

CTO, CEO같이 임원들 기준으로는 비용이 제일 중요할거임

 

---

 

A4. 도메인 분리하는 방법

1. 비즈니스 요구사항을 잘 이해하고 정의

정산 시스템을 예로 들면, 전자상거래 시스템이 있으면 주문, 제품, 고객, 결제의 요구사항을 가짐

 

2. bownded context 데이터 모델, 비지니스 모델을 어떻게 가져갈건지?

정산, 제품(Product), 고객(Customer), 결제(Payment) 각각에 대한 객체

 

4. Entity를 정하고 Entity 값을 어떻게 할건지? 경계(aggregate)를 어떻게 할건지? 

정산, 제품, 고객, 결제 클래스 등을 둠

고객 - 주소 비지니스 로직. . .

---

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

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

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