WIL 20230924

0. 기간 : 

20230918 ~ 20230924

1-1. 이번 주 동안 있었던 일

이력서 작성

1-2. 이번 주 체크리스트

[ O ] 예쁜 말로 협업하였는가?

[ O ] 12시간 동안 몰입하였는가?

[ O ] 코딩 시 복사 + 붙여넣기를 하지 않았는가?

[ O ] 친절한 개발자였는가?

[ O ] 이번 주를 평가하였을 때 주니어 개발자가 될 수 있겠는가?

 

2. 이번 주 소감

더 열심히 지내자

3. 이번 주에 배운 것

 

0. Docker

OS위에 가상환경을 띄우는 것

(VM 보다 가벼운 가상환경) : 우리는 node랑 postgres를 띄운다. redis도 띄울 수 있다.

1. Dockerfile 이해하기

 

#build stage

FROM node:18-alpine AS build

 

WORKDIR /usr/src/app

워킹 디렉토리

 

COPY package*.json ./

package.json과  package-lock.json을 워킹 디렉토리에 COPY

 

RUN npm install

npm 설치

 

COPY . .

전체 파일 복사

 

RUN npm run build

빌드

 

#prod stage

FROM node:18-alpine

 

WORKDIR /usr/src/app

 

ARG NODE_ENV=production

ENV NODE_ENV=${NODE_ENV}

 

COPY --from=build /usr/src/app/dist ./dist

dist 복사

 

COPY package*.json ./

 

RUN npm install --only=production

 

RUN rm package*.json

package.json, package-lock.json 삭제

 

EXPOSE 3000

3000포트 연결

 

CMD [ "node", "dist/main.js"]

package.json 삭제해서 스크립트가 없으므로 node 기본 명령어로 dist/main.js 실행

2. typeORM update

typeORM에서는 update를 사용할 때 변경 기준이 앞에 오고 변경할 것이 뒤로 간다.

  async update(updateDeviceDto: UpdateDeviceDto) {
    try {
      const result = await this.deviceRepository.update(
        { uuid: updateDeviceDto.uuid },
        { fcmToken: updateDeviceDto.fcmToken }
      );
      if (result) return `기기가 재연결 되었습니다.`;
      else `기기 재연결에 실패하였습니다.`;
    } catch (error) {
      return "일시적인 오류가 발생하였습니다.";
    }
  }

 

3. 마이크로 서비스 아키텍처 (MSA)

 

마이크로서비스 아키텍처란?

마이크로서비스 아키텍처((Microservice Architecture)는 하나의 큰 애플리케이션을 비즈니스 단위의 여러 개의 작은 서비스로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말합니다. 서비스의 전체 사이클은 몇 가지 단일 기능 모듈들의 합으로 이루어지며, 해당 모듈들은 개별적으로 배포되고 운영됩니다. 일반적으로 DevOps 에자일 방식으로 개발하고 배포합니다. 각 기능들은 독립적인 자동화 서비스(마이크로서비스)로서 개별 서버를 갖고 있게 됩니다. 각 마이크로서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성하게 됩니다.

 

MSA의 등장 배경

 

기존 Monolithic Architecture의 한계

• 부분 장애가 전체 서비스의 장애로 확대될 수 있음
• 전체 시스템 구조 파악이 어려움
• 서비스 변경이 어렵고, 수정 시 영향도(사이드 이펙트 등) 파악이 힘듦
• 빌드 시간 및 테스트, 배포 시간의 급증
• 서비스의 특정 부분만 스케일아웃(sacle-out) 하기 어려움

 

 

MSA의 특징

① 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공한다.
② 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로서비스는 비즈니스 영역의 한 부분에서만 책임을 담당한다. 그리고 여러 애플리케이션에서 재사용할 수 있어야 한다.
③ 마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.
④ 애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
⑤ 작고 독립적이며 분산된 마이크로서비스를 사용해 조직은 명확히 정의된 책임 영역을 담당하는 소규모 팀을 보유할 수 있다. 이 팀들은 애플리케이션 출시처럼 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.

 

MSA의 목적

마이크로서비스를 달성하기 위해서는 많은 노력과 비용이 수반된다. 따라서 MSA를 적용하고자 할 경우 명확한 목적을 갖고 적용을 고려해 보아야 한다.
1) 마이크로서비스 아키텍처를 통해 달성하고자 하는 목표는 무엇인가?
명백한 목표 예를 들어 기존 대비 1.5배 빠른 성능, 이벤트에도 중단되지 않는 가용성 높은 서비스 등 결과를 기준으로 설명할 수 있어야 하며, 시스템의 end-user에게 이점을 제공하는 방식으로 설명될 수 있어야 한다.
2) 마이크로 서비스 사용에 대한 대안을 고려했습니까?
마이크로서비스가 제공하는 것과 동일한 이점을 얻을 수 있는 다른 많은 방법이 있다. 때로는 MSA를 고려하지 않고도 적용 가능한 방법이 다양하게 존재하므로, 이에 대한 고려를 선행한 후 MSA를 선택하는 것이 좋다.

 

 

 

MSA 장점

1. 배포

- 서비스별 개별 배포가 가능합니다.(배포시 전체 서비스의 중단이 없습니다.)

- 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능합니다.

 

2. 확장

- 특정 서비스에 대한 확장성(scale-out)이 유리합니다.

- 클라우드 기반 서비스 사용에 적합합니다.

 

3. 장애

- 일부 장애가 전체 서비스로 확장될 가능성이 적습니다.

- 부분적으로 발생하는 장애에 대한 격리가 수월합니다.

 

4. 그 외

- 새로운 기술을 적용하기 유연합니다.(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)

- 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.

 

MSA 단점

1. 설계의 어려움

 

- MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야합니다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야합니다.

 

2. 성능

- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재합니다.

 

3. 테스트/데이터 트랜잭션

- 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.
- 통합 테스트가 어렵습니다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않습니다.

 

4. 데이터 관리

- 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵습니다.

- 데이터를 관리하기 어렵습니다.

4. 배운 것들을 토대로 적용할 미래

개발자

5. 다음주 목표

이력서 완성

6. 나에게 응원 한 마디

취업 할 수 있다