[Project 관련]

박세건·2024년 4월 30일
0

직무면접대비

목록 보기
5/5
post-thumbnail

스프링은 무엇인가요?

  • Java 웹 개발을 편리하게 도와주는 프레임 워크
  • 복잡하고 어려운 설정이나 과정을 스프링에게 맡길 수 있어 개발자는 개발에 집중할 수 있다.
  • 복잡하고 중복되는 코드들을 제거하여 경량화(EJB때는 불편)
  • 오픈 소스 이기에 누구든지 스프링을 사용가능
  • 스프링 개발 기업에서 관리하기 때문에 안정적
  • 애플리케이션 프레임 워크 : 애플리케이션을 개발하는 데에 필요한 코드들의 뼈대를 제공

스프링의 특징은 무엇인가요?

  • (가장 큰 특징)POJO 프로그래밍
    • 자바의 라이브러리로만 이루어진 순수한 자바 객체
      • 외부 라이브러리를 사용하지 않는 객체
      • 외부 라이브러리를 사용한다면 변경이나 제거된다면, 구현된 모든 객체들을 수정
    • POJO를 사용하게 되면 외부적인 상황에 상관없이 유연하게 변화와 확장에 대응할 수 있게됩니다.
  • IoC
    • 객체에 대한 제어권을 스프링이 갖는다.
    • 덕분에 개발자는 개발에 집중
  • DI
    • 스프링이 객체들의 의존관계를 주입해주는 것
  • Bean
    • 스프링의 객체인 Bean에 실제 객체를 저장해서 관리
  • AOP(Aspect Oriented Programming, 관심 지향 프로그래밍)
    • 공통된 기능에 대해서 매번 중복되는 코드를 작성하는 비효율 문제
    • 이 문제를 해결하기위해 AOP
    • 중복되는 코드들을 없애기위해 따로 모아서 관리
      ex) 기능을 수행하기전 로그인 여부 확인

  • PSA(Portable Service Abstraction, 일괄된 서비스 추상화)
    JDBC를 이용하면 사용하고자 하는 DB가 어떤 것이든 관련 서비스를 추상화하여 일관된 방식으로 사용할 수 있도록 합니다.
    이처럼, 특정 기술과 관련된 서비스를 추상화하여 일관된 방식으로 사용하는 것을 PSA라고 합니다.

스프링 부트는 무엇인가요?

  • 스프링으로 인해 개발은 편해졌지만 초기설정이 복잡
  • 설정들을 간편하게 하게 위해 등장
  • 간편한 초기설정으로 구현에 집중 가능

왜 스프링 부트를 사용하셨나요?

  • 라이브러리들의 버전을 자동으로 관리
  • 내장 톰켓 제공
    • 이전에는 서버를 배포하기위해 톰캣과 같은 WAS를 설치하고, war 파일을 생성해서 배포해주어야했고 이러한 과정은 번거롭고 느렸다.
    • 스프링 부트를 사용하면, 내장 웹 서버(톰캣)를 갖고있어서 빠르게 실행 가능하다.
  • 실행 가능한 JAR로 개발 가능
    • 이전의 방식인 war 파일은 웹 서버에 의해서 배포가 되지만, JAR는 독립적(언제 어디서든)으로 실행 가능
    • JAR 파일은 크기가 작다
    • 배포 간단, 효율
  • json 형태 변환과 같은 다양한 설정들이 스프링 부트는 자동화 되어있습니다.

AWS(Amazon Web Services)란?

아마존에서 제공하는 클라우드 컴퓨팅 플랫폼

클라우드 컴퓨팅이란?

인터넷을 통해 연결된 원격 컴퓨터를 활용하는 기술
왜 클라우드 컴퓨팅을 사용할까?

  • 언제 어디서나 사용할 수 있고
    • 온디맨드(on-demand 서비스 : 언제 어디서나 고객 중심에서 니즈를 해결)
  • 사용한 만큼만 비용을 지불한다.
  • 전세계에 빠르게 서비스를 배포할 수 있다.

클라우드 컴퓨팅 서비스 종류

기업이 준비해놓은 환경에 사용자들이 선택해서 사용할 수 있다.

  • IaaS(Infrastructure as a Service)
    • 사용자가 선택할 수 있는 범위가 가장 넓은 클라우드 컴퓨팅 서비스
    • OS와 애플리케이션 직접 관리
    • 물리적 자원 제공
    • ex) EC2, S3
    • Ex. 요리를하기 위해 재료부터 도구 까지 내가 준비, 단 장소를 지원받음
  • Paas(Platform as a Service)
    • 개발자는 코드만 제공, 나머지는 Paas 서비스가 알아서 배포와 스케일링까지 진행
    • ex) AWS Elastic Beanstalk, Google App Engine
    • Ex. 요리를 하기 위해서 재료(코드)만 제공하면 요리에 필요한 나머지를 지원
  • Saas(Software as a Service)
    • 완성된 형태 ( 모든것을 제공 )
    • 소프트웨어를 제공
    • ex) MarketPlace, DropBox, Google App
    • Ex. 완성된 요리를 제공
  • Iaas :
    • 빈 땅을 빌려서 그 위에 내가 원하는 집을 짓는 구조
    • IT 인프라(서버, 스토리지, 네트워크 등)을 가상화로 빌려 운영체제, 애플리케이션 등을 설치 및 관리하여 운영
  • Paas :
    • 완성된 부엌을 빌리고 내가 원하는 음식을 요리하는 구조
    • 개발 환경, 런타임을 제공하므로 사용자는 코드만 가져와서 개발을 진행할 수 있도록 제공
  • Saas :
    • 음식점에서 완성된 음식을 받아서 먹는 구조
    • 이미 완성된 소프트웨어를 사용하는 서비스

인프라?

애플리케이션을 구축, 운영, 관리 하는데 필요한 모든 자원

Sping Boot와 AWS를 활용하여 웹 서비스를 구현한 과정을 자세히 설명해주세요

  1. EC2 인스턴스를 생성합니다.
  2. putty를 통해서 EC2에 SSH로 접속
  3. 프로젝트를 빌드해서 Jar 파일 생성
  4. 생성된 Jar 파일을 EC2에게 전송
  5. EC2에서 Jar 파일 실행
  6. 클라이언트는 EC2의 ip로 접근 가능
    추가로 EC2서버를 중지할때마다 변경되는 IP를 고정시키기위해 Elastic IP를 할당

IAM(Identity and Access Management) 사용자란?

AWS 리소스에 대해서 액세스 권한을 가진 개별 사용자 계정입니다.
이는 액세스 권한 관리, 보안과 감사, 모니터링을 위한 핵심 요소입니다.

Putty란?

리눅스 서버에 원격으로 접속하기 위한 도구이고, 이를 통해 SSH 접속가능합니다.
EC2를 생성할때 .pem 키 파일이 생성되는데 Putty는 이 파일을 .ppk 파일로 변환할 수 있고 이를 통해 안전한 SSH 접속을 할 수 있습니다.

SSH란?

원격 안전하게 접속하여 명령을 내릴 수 있도록 하는 프로토콜
컴퓨터 간 안전한 통신을 위한 프로토콜

  • 이전의 텔넷을 사용해 통신했지만 보안을 적용하지 않고 통신 -> 사용자 정보 탈취 가능성 ->SSH 등장

EC2(Elastic Compute Cloud)란?

AWS에서 제공해주는 가상 컴퓨팅 서비스로 사용자가 필요한 컴퓨팅 리소스를 신속하게 프로비저닝(IT자원을 사용가능 하도록 준비)하고 관리 합니다.
즉, AWS에게 원격으로 제어할 수 있고 서버를 운영시킬 가상의 컴퓨터를 한 대 빌리는 것
성능, 용량 등을 설정해서 사용할 수 있고 사용한 만큼 비용이 들기 때문에 Elastic(탄력적인)이 붙게되었다.
직접 설정할 수 있기 때문에 사용자의 요구에 따라 CPU,메모리 등과 같은 리소스를 유연하게 조정할 수 있습니다.

Elastic IP란?

EC2로 부터 제공되는 IP는 중지하게되면 사라지고 IP를 다시 확인해줘야하는 번거로움이 있습니다.
EC2는 서버를 책임지기때문에 ip주소가 바뀐다면 해당 주소가 DNS주소가 계속 변환되는 것
이러한 문제를 해결하기위해서 중지하고 다시 시작해도 IP주소가 유지되게 하기 위해서 Elastic IP를 제공합니다.
DNS 설정시 계속 IP가 변경되면 귀찮아진다 -> 고정 한다면 문제 해결

AWS의 어떤 서비스를 사용하셨나요?

  • EC2
    • AWS에서 제공해주는 가상 컴퓨팅 환경입니다. AWS로부터 서버를 운영할 컴퓨터를 빌린다.라고 생각하자. 사용자의 요구사항에 맞게 환경을 구성할 수 있고 모니터링, 네트워킹, 보안, 등의 기능을 제공해줍니다.
    • 서버를 운영하기위한 하드웨어 비용은 비싸고 복잡하고 오래걸린다.
    • 저 또한 이 프로젝트를 싸고 빠르고 안전하게 배포 시키기 위해서 EC2 서비스를 사용하였습니다.
  • S3
    저는 S3를 Travis 를 통한 빌드 결과를 저장하는데 사용했고 S3 에 저장된 빌드 결과 파일을 AWS CodeDeploy를 통해 EC2로 배포하였습니다.
    • AWS에서 제공해주는 확장 가능한 스토리지 서비스입니다.
    • 무제한 데이터 저장 공간 제공(사용하는 만큼 비용 지불)
    • 99.99% 내구성으로 데이터 손실 위험 최소화
    • 보안 기능 제공(암호화, 액세스 제어, 로깅 등)
    • 손쉬운 관리 : AWS 콘솔, CLI로 쉽게 관리
    • 다른 AWS 서비스들과 원활한 통합 가능
  • CodeDeploy
    저는 프로젝트를 진행하면서 S3에 저장되어있는 빌드 결과(배포 파일)을 EC2에게 배포하는데 이 서비스를 이용하였습니다.
    • AWS CodeDeploy는 애플리케이션 배포를 자동화하고 관리하는 서비스로, 다양한 배포 대상과 배포 구성 옵션을 제공하여 신속하고 안정적인 배포를 지원합니다.
    • Amazon EC2 인스턴스에 배포할 수 있습니다.
    • 신속하게 배포 가능
    • 중단을 최소화하며 배포 가능
    • 관리하는데 필요한 파일(AppSpec 파일) : AppSpec 파일의 구조, 예제, 간격, 파일 위치 등에 대한 자세한 내용은 AWS 문서를 참조하세요.

CI/CD를 구축한 경험에 대해 설명해주세요.

  • 애플리케이션을 수정할때마다 테스트, 빌드, 배포 과정이 필요
  • 수정할때마다 이 과정을 일일이 실행하는 것은 중복되고 시간이 오래걸림
    • 이 과정에서 휴먼 에러가 발생할 수도 있음
  • 이 문제를 해결하기 위해 CI/CD가 등장
  • 빌드, 테스트, 배포를 자동화 시키고 개발자는 구현에 집중
  • 프로젝트를 진행하면서 GitHub를 통해서 버전관리를 진행
  • 먼저 CI를 적용시키기위해서 Travis 플랫폼을 사용
  • yml 파일에 설정정보를 저장한 후에 GitHub와 연결
  • PUSH 했을때에 자동적으로 빌드, 테스트를 수행할 수 있게하였습니다.**
  • CD를 적용시키기 위해서 EC2와 적합성이 좋은 AWS의 CodeDeploy를 사용
  • Travis CI를 통한 빌드 결과를 AWS S3 저장소에 저장
    • CodeDeploy는 저장기능이 없어서 S3필요
  • 이 결과를 CodeDeploy를 통해서 EC2에게 배포
  • 배포 과정 또한 YAML을 통해서 설정
  • PUSH 과정을 통해서 배포까지 자동적으로 진행될 수 있도록 하였고 시간 절약과 효율성을 챙길 수 있었습니다.

Travis와 AWS CodeDeploy의 역할과 기능에 대해서 설명해주세요.

Travis

  • 비즈니스 기능을 구현한뒤 PUSH를 하면 Travis CI가 이를 확인하고 자동적으로 테스트와 빌드를 실행합니다. PUSH한 결과를 통합하여서 테스트를 실행하고 결과에 문제는 없는지 확인하고 빌드를 한뒤 빌드한 결과를 제공합니다. 하지만 Travis CI 자체적으로 배포파일을 관리하지 못하기때문에 AWS의 S3 스토리지 서비스를 이용하여 배포를 진행하였습니다.

CodeDeploy

  • CodeDeploy는 AWS에서 제공하는 배포관련하여 자동화를 제공해주고 관리해주는 서비스입니다.
    저는 이 서비스를 이용해서 이전에 S3에 저장시켰던 빌드결과를 CodeDeploy를 통해서 EC2로 자동적으로 배포할 수 있도록 구현하였습니다. 이를 통해서 안정성과 속도 그리고 중단의 최소화를 경험할 수 있었습니다.

CodeDeploy가 빌드와 배포 둘다 가능한거로 아는데 왜 Travis CI를 쓰셧나요?

  • 배포만 필요한 상황에 대처하기 어려움
  • 배포를 하기위해서는 반드시 빌드를 해야하는 상황 발생
  • 이를 해결하기 위해 분리

CI 동작하는 과정?

  1. 프로젝트를 수정하고 PUSH
  2. CI서버가 이를 확인하고 Build, Test 실행
  3. 실행 결과를 개발자에게 전송(email 설정가능)
  4. 에러가 발생하면 다시 수정, 성공이면 CD과정 진행

CD 동작하는 과정?

  1. 통합테스트 실행하며 안정성 확인
  2. 보안 취약점 검사
  3. 운영 환경에 배포

다른것을 사용하지 않고 Travis를 통해 CI를 구현한이유?

  • 대표적인 CI툴로 젠킨스(Jenkins)가 있음
  • 구성이 많아 플러그인 설정 과정이 매우 복잡하고 오래걸림
  • 반면에, TravisCI는 설정을 yml파일을 통해 빠르게 진행 가능
  • Travis는 오픈소스 프로젝트는 무료지만 그게 아니라면 비싼편
  • 때뮨에 대규모 프로젝트를 진행한다면 Jenkins를 사용하는 것이 좋아보임

다른것을 사용하지 않고 CodeDeploy를 통해 CD를 구현한이유?

  • EC2와 호환성이 좋다
  • 주변 환경에 대한 제약이 없어 모든 애플리케이션에서 작동
  • 중지 및 롤백 가능

데이터 파이프라인?

  • 코드에 대해 사전 정의 된 작업을 수행하는 일련의 처리 단계
  • 목적 : 반복적인 프로세스를 자동화하여 시간 절약
    코드를 빌드, 테스트, 배포 의 과정을 거쳐서 개발을 추진하는 과정

    릴리스 : 버전 제어 저장소의 애플리케이션 업데이트

NGINX란?

  • 동시접속 처리에 특화된 웹 서버 프로그램, Reverse Proxy Server, 로드 밸런서로도 활용
    - 우리는 Reverse Proxy Server로 NGINX를 사용해서 프로젝트를 진행
  • 다량의 트래픽을 해결하기위한 비동기 Event-Driven 구조의 웹서버
    • Event-Driven 구조 : Event의 상태변화를 기반으로 작동
    • Event : 커넥션 형성, 커넥션 제거, 요청 처리
  • apache는 클라이언트 접속마다 Process 혹은 Thread 를 생성하는 구조입니다. 때문에 메모리 소모가 크다(Context-Switching이 자주발생하기때문)
  • Apache : 안정성, 확장성, 호환성
  • NGINX : 성능이 우세

테코톡(피케이의 NGINX)를 보고

  • 아파치 서버
    • 새로운 요청이 들어올때마다 새로운 프로세스를 생성
    • 모듈을 추가해서 기능을 확장하기 쉽다
    • C10K문제 발생(10000개의 Connection 문제) -> 더이상 Connection 생성 불가
    • 이를 해결해줄 NGINX 등장
    • master process와 worker process 구조
    • master process는 설정파일을 읽고 실제 작업을 처리할 수 있는 woker process 생성
    • woker process가 비동기 방식으로 대기하는 이벤트를 하나의 스레드로 처리
    • woker process는 쉬지 않고 계속해서 일하게됨 -> 효율적

Foward Proxy Server vs Reverse Proxy Server

Proxy(대리) Server

  • Client와 server 사이에서 대리인의 역할
    Poward Proxy Server
  • 클라이언트 바로 앞에 위치한다.
  • 클라이언트의 대리인(클라이언트의 기능을 대신 수행)
  • 장점
    • 캐시를 사용하기에 클라이언트에게 빠른 데이터 제공 가능
    • 익명성 가능 : 프록시를 통해서 서버에 요청하기때문에 누가 요청을 보냇는지를 숨겨줄 수 있다.
    • 접근을 제한해줄 수 있다

Reverse Proxy Server

  • 서버앞에 위치한다.
  • 서버의 대리인(서버의 기능을 대신 수행)
  • 장점
    • HTTPS를 적용하기 위해 NGINX가 앞단에서 보안 연결을 담당하고 서버에는 HTTP로 전달
    • 캐싱
    • 보안 : 클라이언트가 보낸 요청이 정확히 어디 서버로 가는지를 알 수 없다
    • 로드밸런싱

Load Balancing

너무 많은 클라이언트의 요청때문에 서버가 버티지 못한다.
확장이 필요함을 느낌
확장의 방식 종류

  • Scale-Up : 업그레이드 : 성능 증가 : 가격이 비쌈
  • Scale-Out : 물량 증가 : 여러개의 서버를 배치 : 가격 저렴
    Scale-out을 통해 여러개의 서버가 생성되었을때 서버의 부하를 나눠주는 무엇인가 필요하고 이를 Load Balancing 이라고 한다.

Web Server?

HTTP 요청을 받고 자료를 HTTP로 보내는 컴퓨터

  • 정적 페이지를 제공

WAS?

  • 동적 페이지를 위한 서버

NGINX를 사용하여 무중단 배포를 구현한 과정에 대해 설명해주세요.

쓰게된 이유

  • CI/CD를 사용해도 새로운 버전을 배포하기위해서 서비스가 잠시 중단
  • 이러한 중단 현상을 막기위해 사용

Reverse Proxy Server

  • NGINX를 reverse Proxy Server 로 사용해서 무중단 배포를 구현
  • 외부의 요청을 받아 연결된 백엔드 서버로 요청을 전달

과정

  • EC2, NGINX, 스프링부트 jar 2개 필요
  1. 사용자의 요청
  2. NGINX는 사용자의 요청을 현재 연결된 스프링부트로 전달(8081 포트)
  3. 신규 버전은 연결되지 않은 스프링부트에 배포(8082)
  • 이 과정에서 중단은 없음
  1. nignx reload를 통해 8082를 바라보도록 설정
  • 이 과정은 1초 이내에 실행됩니다.
  1. 만약 문제가 발생하면 다시 이전으로 nignx reload로 간단하게 해결(롤백)

무중단 배포 방식

  • AWS의 Blue-Green
  • Docker를 이용한 방식
  • NGINX를 이용한 방식
    • 제일 가격이 저렴.

도커(Docker)란?

Docker란, Go언어로 작성된 리눅스 컨테이너 기반, 오픈소스 가상화 플랫폼
도커만 설치하면 어떤 운영체제의 컴퓨터에서든 똑같이 돌아가는 가상환경을 띄울 수 있다.
즉, 컴퓨터는 윈도우인데 서버가 리눅스라면 환경이 달라 오류가 발생할 수 있고 이 문제를 해결해줄 수 있는 것이 도커 이다.

컨테이너?

애플리케이션 실행에 필요한 모든 파일, 라이브러리, 설정 등을 포함하는 독립적인 실행 환경

쿠버네티스(kubernetes)

컨테이너를 쉽고 빠르게 배포 및 확장하고 관리 하는 과정을 자동화해주는 오픈소스 플랫폼
Ex. 서비스 사용자가 증가할 때 자동으로 스케일 확장(추가적인 웹애플리케이션 배포)
Google에서 개발한 컨테이너 오케스트레이션 도구

오케스트레이션 도구란, 구성 요소나 서비스를 자동으로 배포, 구성, 관리, 모니터링 하는 역할의 소프트웨어를 칭함.
즉, 컨테이너 오케스트레이션 도구는 컨테이너화된 서비스와 그 환경을 효율적으로 운영하기 위한 소프트웨어

!많은 컨테이너를 관리하는데 용이하기 떄문에 한 개의 인스터너스 만있다면 필요없다. -> 상황마다 다르다.

컨테이너, 도커, 쿠버네티스 관계

  • 컨테이너 : 애플리케이션과 그 주변 환경(라이브러리, 설정 등)을 가상화 기술을 사용해서 만들어진 하나의 패키지
  • 도커 : 애플리케이션을 컨테이너로 패키징하는 도구
  • 쿠버네티스 : 만들어진 컨테이너를 운영하고 관리

컨테이너 기반 가상화?

VM 가상화 방식 : 게스트의 OS까지 포함한 전체를 가상화해서 사용한 방식

  • OS를 여러개 돌려야 하기에 무겁고 느리다.
  • 완전한 격리로 보안성, 에러가 다른 VM에 번지지않음

컨테이너 기반 가상화 방식 : OS를 공통으로 추상화 시켜서 관리하고 Application 실행에 필요한 파일과 라이브러리만 격리하여 실행 환경 -> 경량화, 빠름

가상화란?

  • 물리 자원을 복제하여 새로운 가상의 자원을 생성하는 행위
  • 서버 가상화 : 하나의 물리적 서버를 여러개의 가상의 서버로 분할하여 사용하는 기술 -> 각각의 가상 서버에 각기 다른 OS 설치 가능
    디스크가 메모리인척 하는 가상 메모리인것처럼, 하드웨어나 운영체제 같은 리소스의 실체를 감추고 진짜 인척 하는 것
    게스트는 자신이 사용하는 리소스가 가상화 되었는지 알 수 없다.

사용하는 이유

  • 물리적 서버의 공간을 최대한 활용 가능
    여러개의 가상 공간을 물리적인 가상 공간에서 관리할 수 있기 때문에 유지 보수, 관리 가 용이 해지고 하드웨어 비용 절감

마이그레이션(Migration,이동,이주)

데이터를 한 위치에서 다른 위치로, 한 형식에서 다른 형식으로 또는 한 애플리케이션에서 다른 애플리케이션으로 이동하는 프로세스

프로비저닝(Provisioning)

프로비저닝은 필요한 자원(서버, 네트워크, 소프트웨어 등)을 자동으로 설정하고 배포하는 과정을 의미합니다. 대표적인 사용 사례는 다음과 같습니다:

  • 클라우드 인프라 프로비저닝:
    • AWS, Azure, GCP 등에서 VM, 스토리지, 네트워크 등 자원을 코드화한 템플릿(Terraform, CloudFormation 등)을 사용해 자동 배포합니다.
  • 컨테이너 및 오케스트레이션:
    • Docker와 Kubernetes 같은 플랫폼에서 컨테이너를 자동 생성, 스케일링, 업데이트하는 데 프로비저닝이 활용됩니다.

NGINX의 어떤 기능을 사용하셨나요?

  • NGINX를 Reverse Proxy Server로 사용
  • 서버로 부터 요청되는 것을 NGINX가 받아서 서버로 요청
  • 사용자의 요청을 받아주는 포트와 신규 버전을 배포할 포트 2개사용
  • 신규 버전이 배포되면 사용하지 않는 포트에 배포
  • nignx reload를 사용해서 사용자와 연결시켜줄 포트 교체

어떤 방식의 무중단 배포를 사용했냐

  • Rolling : 특정한 몇개의 서버의 라우팅을 종료하고 먼저 업데이트 시킨뒤 다시 라우팅 연결, 나머지 업데이트되지 않은 서버는 다시 업데이트하고 다시 라우팅
    • 호환성 문제가 발생할 수 있음
  • Blue-Green
  • canary
    • 기존 버전의 애플리케이션을 사용자의 요청을 처리하도록 유지
    • 새로운 버전의 애플리케이션을 배포하고 로드 밸런서를 통해 일부 트래픽을 새로운 버전으로 라우팅
    • 새로운 버전의 안정성을 확인하기위해, 트래픽 비율을 늘려가면서 전환, 10% → 25% → 50% → 100%

      Blue-Green 방식으로 진행 운영중인 구성과 같은 구성의 인스턴스 구성한뒤에 새로운 버전 배포 후 NignxReload(Road Balancer)로 트래픽을 새로운 버전으로 변경

NGINX의 또 다른 기능은?

  • HTTPS 적용
  • 무중단 배포
  • 로드밸런싱 : 다량 트래픽 분할 처리
  • 캐싱 : 서버까지 가지 않고 정적 데이터 바로 응답
  • 웹서버 : 정적 페이지 데이터를 제공해줄 수 있는 서버

무중단 배포로 얻을 수 있는 이점은 무엇인가요?

  • 신규 스프링부트 프로젝트를 배포하는 과정에서 서비스가 중단되는 현상
  • 이 문제를 무중단 배포로 해결
  • 클라이언트에게 끊기지 않는 서비스 제공

ERP란?

  • ERP(Enterprise Resource Planning : 전사적자원관리)
  • 기업의 모든 업무(재고, 회계, 인사, 급여 등)를 통합해서 관리할 수 있는 시스템

MSA란?

Monolithic Architecture (모놀리식 아키텍쳐) : 모든 구성요소가 한 프로젝트에 통합되어있는 형태

  • 부분적인 오류가 전체 서비스 장애로 확대
  • 여러 구성요소가 강하게 결합
  • 네이버처럼 다양한 기능을 갖는 서비스가 하나의 애플리케이션으로 합쳐져있다면 유지보수, 개발이 어렵고 많은 개발자들의 충돌이 발생할 수 있다.
    이러한 모놀리식 아키텍쳐의 한계점을 해결하기위한 MSA

MSA(Micro Service Architecture) : 각각의 기능 API 별로 나눠서 개발하고 배포하는 방식

  • 서비스 별로 독립적인 배포(CD) 가능
  • 작고 단순하고 분리된 서비스 -> 확장 가능, 유연한
profile
멋있는 사람 - 일단 하자

0개의 댓글