220730 Today I Learned

일지

7월말!!

---

오늘의 할일

• 220730 TIL 작성
• 9회차 멘토링
• 최종프로젝트; Dockerizing source code

---

1. VM 기반
= Agent에 배포해서 Job을 돌림
= Lable을 지정해서 1,2 / 3 식으로 지정해서 돌아감
= 실무에서는 VM기반으로 자주돌림

2. Contatiner 기반
= 개별 작업이 Pod위에 Job으로 구성되서 돌아감
= 연습이나 예제환경에서 구성/ 간단하게구성

4개 API
usage capacity > Promql
cost expcost > AWS RDS
인증 Keycloak
RDS 연동
API Spec / Table 명세서

**배포시에는 업데이트/업그레이드를 어떻게해야하는지도 고민을해야함

로컬개발시에는 고민안할수있지만 배포변경은 어떻게할지도 고민을 해봐야한다

**application에 대한 분리에 대한점도 고민
fe/be는 서로와 상관없이 배포가능한상태가되어야한다
> 상호간섭이 없어야 cloud native한 환경에 구축이 가능하다
> 원자성을 가지는 pod구성
> 개별 business logic 별로 컨테이너(pod)를 구성
> 서로다른기능을 하는 컨테이너들이 coupling되어있으면 그게무슨!
> API별로 depployment를 구성하는게 좋고
> lb와 같은 service부분도 정의해서 좋더

모놀리식 <> MSA

MSA 단점
 유지보수 (배포,HOTFIX)
 모니터링& 얼럿

 ISOLATION 되고 DEPENDENCY 없이 구성하는 MS도 중요하지만
그러한 서비스를 모니터링하고 얼럿거는것도 중요하다

MSA 핵심 > 서비스간에 연결되어야한다 S1,S3,S5, External svc
지금 프로젝트는 서비스하나로 연결해서 끝나기때문에 msa라기엔 부족
잘게 쪼개는게 msa아님!

circuit breaker / fallback 

UI

WEB		    S1 S3	
MOBILE	  API	    S2 S4 S5  | External svc
DEVIC	GATEWAY

> S5의 Idle이 오래 지속될경우 다른 서비스에서도 장애를 불러일으킬 수 있음
> 별도의 circuit breaker / fallback 절차를 도입해서 연쇄반응 제지

Domain context - 서비스를 어떻게 쪼개고 나누어야하는가?
> 신규프로젝트는 쪼개기하는데
> 기존앱 마이그레이션 > lift and shift

기술을 안다고해서 업무를 할 수 있는건아님

ca 단점
workernode deploy 2. cluster join 3. app deploy
> time consuming
> lobust traffic 대응불가

> 모니터링을 통해 사전에 노드를 늘림
event성 batch를 설정
80%의 사용량에 도달하면 노드를 추가시킴

단점2 부하 대응 후 scale in 과정에서 연결이죽음
기존 pod drain 시키고 워커 노드 순차적 종료
> 연결이 자꾸 끊기네요? 이거왜죠?

> 수동으로 비용을 관리하는것을 선호함

고객사따라 다르겠지만 HPA/CA까지는 호/불호가 갈림
> 이벤트시에 따라서 수동으로 관리를 선호하기도함

Backend 유형3가지
api / 인증(성격이다른서비스) / backdata (batch성 작업)
> 배포와 release 에 대한 부분 고민


app pipeline

frontend 1
backend 1 (api)
schedule (dataset) 1
authen 1 

sched를 같이 갈수도있고 authen을 분리할수도있고
> 고려사항 > 향후 release 및 Update 정책을 고려

devops?
기술? 프로세스? 조직? 사람이될수도있고

ㅐ=app을 빨리빨리 배포하기위해
플랫폼&짜동화

eks를 만들고 배포시스템을자동화한것 좀더 상세히쓰기 
Agile process practice 경험
gitops

terraform을 통해 자동화된 클러스터배포
AWS Cloud 환경에서 trf을 사용한 eks 배포를 위한 automation 구현