[부트캠프 - 26일차] 1/27.화 - Network & Cloud

developowl·2026년 1월 29일

부트캠프

목록 보기
17/29
post-thumbnail

Firewall

Linux 에서 방화벽

  • 서버용 운영체제는 설치하면 자체 방화벽이 함께 설치가 됨

  • 운영체제에서 동작하는 서버의 방화벽은 서버 보안을 강화하기 위해서 최소한의 서비스 포트만 열어둔 채 대부분의 서비스는 차단을 함

  • 방화벽은 필요한 IP 주소와 서비스 포트에 대해서만 열어주고 나머지는 모두 차단하는 화이트리스트 기반 정책을 관리

  • 서버에서 동작하는 방화벽도 마찬가지로 서비스에 필요한 IP 주소와 서비스 포트를 방화벽 정책에 추가하는 방식이 서버 보안을 더 강화해줄 수 있지만, 경우에 따라서는 특정 포트만 차단하는 블랙리스트로 운용할 수 있음

  • 서버 방화벽은 운용상의 불편함 때문에 기능 자체를 끄고 사용하는 경우도 있음

  • 반드시 사용해야 하는 경우: 데이터센터 서버의 접근 제한 및 이력 관리를 위해 사용하는 서버 접근 솔루션이나 데이터베이스 서버의 접근 및 세부 쿼리에 대한 제어를 사용하는 경우 / 데이터베이스 접근 솔루션을 사용하는 경우 반드시 서버 방화벽에서 해당 솔루션의 IP 주수와 포트만 허용하고 나머지 주소는 차단해야만 해당 솔루션을 제외한 허용되지 않은 접근을 막을 수 있음

  • 리눅스에서 호스트 방화벽 기능을 위해서는 iptables 를 많이 사용

  • CentOS 7 이상에서는 iptables 대신에 firewalld 를 사용하도록 되어 있으며 Ubuntu에서는 UFW(Ubuntu FireWall)를 사용해 방화벽 서비스를 제공하지만 UFW는 iptables의 프론트엔드 역할을 수행

netfilter

  • iptables는 방화벽의 역할처럼 패킷을 차단, 허용하는 등의 필터링 기능을 직접 수행하는 것은 아니고 리눅스 커널에 내장된 netfilter 라는 리눅스 커널 모듈을 통해 필터링이 이루어짐
  • iptables는 netfilter를 이용할 수 있도록 해주는 사용자 공간 응용 프로그램
  • iptables 나 firewalld 그리고 UFW는 모두 netfilter에 대한 프론트엔드 역할을 수행

iptables

  • iptables를 통해서 서버에서 허용하거나 차단할 IP나 서비스 포트에 대한 정책을 수립
  • 수립된 정책은 정책 그룹으로 관리
  • 정책 그룹은 서버 기준의 트래픽 구간별로 만드는데, 트래픽 구간은 서버로 유입되는 구간(INPUT), 서버에서 나가는 구간(OUTPUT), 서버를 통과하는 구간(FORWARD) 등을 의미
  • 개별 정책의 방향성에 따라 구분한 그룹을 체인이라고 하고, 체인을 역할별로 구분한 그룹을 테이블이라고 함
  • iptables 에는 Filter Table, NAT Table, Mangle Table, Row Table, Security Table이 있음
    • 이중에서 패킷을 차단하거나 허용하는데 사용되는 테이블이 Filter Table
    • 리눅스의 호스트 방화벽은 이 필터 테이블을 통해서 트래픽을 제어하는 것을 의미

방화벽 활성화 / 비활성화

# 우분투의 ufw 비활성화
systemctl disable ufw
systemctl stop ufw

# iptables 설치
sudo apt update

sudo apt install iptables

iptables --version

iptables-persistent 설치

  • iptables는 명령어로 규칙을 설정해도 재부팅하면 모든 규칙이 초기화 되므로 규칙을 저장하고 자동으로 불러오는 도구를 함께 설치해야 함
sudo apt install iptables-persistent

# 현재 설정 저장
sudo netfilter-persistent save

방화벽 정책 확인

iptables -L
  • target: ACCEPT | REJECT
  • prot: 프로토콜(모든 프로토콜을 허용할 때는 all)
  • opt source: 출발지(모든 곳을 지정할 때는 anywhere)
  • destination: 목적지
# icmp는 ping 명령이 사용하는 프로토콜, 모든 곳에서 출발하는 ping 명령을 모든 곳에서 허용
ACCEPT icmp-- anywhere anywhere

# 현재 서버에 http(80) 서비스가 가능하도록 서비스 포트를 개방
# 추가할 때는 A나 append 옵션을 사용하고 그 다음에 체인(INPUT, OUTPUT, FORWARD)을 기재하고 뒤에 추가하는 정책이 어떤 프로토콜의 어떤 포트에 적용할 것인지 또는 어떤 IP 주소나 인터페이스에 대해 기재
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# 삭제
iptables -D INPUT -p tcp --dport 80 -j ACCEPT

# 체크
iptables -L # 단, 이렇게 확인하는 경우 정책이 많으면 찾기가 어려움
iptables -C INPUT -p tcp --dport 80 -j ACCEPT 

# 방화벽은 위에서 아래로 순서대로 매치를 함
# 일치하는 라인을 만나면 이후 라인은 검사하지 않음

# 라인번호 확인
iptables -L --line-number 

# 특정 라인에 추가
iptables -I INPUT 1 -p tcp --dport 22

# 특정 서비스 포트에 대해 특정 IP만 허용
	# 172.16.10.10만 22번 포트에 접근 가능하도록 허용
iptables -A INPUT -p tcp -s 172.16.10.10/32 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

# IP 범위로 지정
iptables -A INPUT -p tcp -m iprange --src-range 172.16.10.10-172.16.10.255 --dport 22 -j ACCEPT

# 포트를 범위로 지정
iptables -A INPUT -p tcp -m multiport -s 172.16.10.10/32 --dport 22:100 -j ACCEPT

1. Cloud Computing

On-Premise

  • 기업이 자체 데이터 및 솔루션 등을 저장하기 위해 데이터 센터를 구축해서 IT 서비스를 수행하는 방식
  • 하드웨어를 포함한 모든 자원에 대한 초기 투자 비용과 탄력적이지 않은 제한된 용량으로 지속적 관리 비용이 증가하는 단점이 있음
    • 단, 기업에 내재화된 서비스를 통해 품질 및 보안에 대한 신뢰도는 높음
  • 기업이 On-Premise 방식에서 벗어나 Cloud 서비스 전환을 고민하는데, 그 이유 중 하나가 높은 초기 도입 비용과 운용에 따른 추가 비용 때문
  • Om-Premise 방식으로 설계 시 자원 사용량은 가급적 최대 사용량을 근거로 하고, 네트워크 트래픽 또한 최대 순간 트래픽을 가정하기 때문에 고사양의 설계를 하게 되고 증설에 따른 시간적, 인적 비용도 무시할 수 없음
  • 동일 사양으로 1~5년 간의 고정적 비용을 따져본다면 특정 시점부터는 Cloud 비용이 더 커질 수 있기 때문에 Cloud 도입은 비용 측면 보다는 서비스의 가용성과 품질을 확인
  • Cloud 접근 방식은 사용한 만큼 지불하는 정산 방식을 통해 필요에 따라 민첩하고 탄력적으로 사용할 수 있으므로 Cloud Computing 및 서비스에 대한 정확한 관리 및 조정 능력이 필요함
    • 현 상황에 적합한 Cloud 세팅 값을 찾는 것이 서비스의 안정화와 비용 절약의 시작

Cloud Computing

  • 정보 처리를 자신이 보유한 PC가 아닌 인터넷 너머에 존재하는 컴퓨터에서 처리하는 사고 방식 또는 개념
  • IT 자산을 소유하는 것이 아니라 서비스로 이용하는 모델
  • Cloud 이용자는 인터넷에 접속한 후 웹 브라우저나 Cloud 서비스 전용 소프트웨어 등을 통해 서비스를 이용할 수 있음
  • 서비스 제공자의 최소한의 관리나 개입만으로도 신속하게 생성/제거/구성 할 수 있는 공유 공간의 컴퓨팅 자원들을 언제, 어디서 어떤 단말 인지와 관계없이 필요할 때 편리하게 네트워크에 접속할 수 있게 하는 모델

Cloud 특징

  • On-Demand Self-Service: 사용자가 별도의 기술 습득 없이 필요할 때 온라인으로 즉시 사용
  • Broad Network Access: 네트워크를 통한 컴퓨팅 자원 접근(Any time, Any place, Any device)
  • Resource Pooling (자원 공동 관리): 다중 임대 모델을 통한 자원 할당 (Multi-Tenancy)
  • Rapid Elasticity (빠른 요구 탄력성): 비즈니스 상황에 따른 컴퓨팅 자원의 탄력적 사용(Flexibility, Scalability)
  • Measured Service (도수제, 종량제): 서비스를 사용한 만큼 비용 지불(Pay-Per-Use, Pay as you go)

Cloud 장점

  • 경제성, 자동화, 이동성, 자원 공유, 가용성, 빠른 구축 속도
  • 확장성
    • Scale-Up: 업그레이드
    • Scale-Out: 개수를 늘리는 것
  • Redundancy or Resilience (중복성 또는 탄력성)
    • 퍼블릭 클라우드는 대부분 여러 개의 데이터 센터를 가지고 있어서 데이터를 여러 곳에 중복해서 저장할 수 있음

Cloud 한계

  • Internet Access(No Internet = No Cloud)
  • Security
  • Privacy
  • Vendor Lock-in(Application migration may be impossible)

Cloud Service 종류

컴퓨팅 자원

Network → Storage → Server → Virtualization → OS → MiddleWare → Runtime → Data → Application

  • On-Premise: 모든 컴퓨팅 자원을 직접 구축하고 관리

IaaS (Infrastructure as a Service)

Network → Storage → Server → Virtualization

  • 서버, 스토리지, 네트워크와 같은 인프라 자원을 가상화 해서 사용자 요구에 따라 인프라 자원을 사용할 수 있게 해주는 Cloud 서비스 방식
  • 자동화되고 신속한 확장성을 갖고 있는 IT 인프라를 의미하며 비용은 사용량에 따라 지불하는 방식
  • 서비스로서 Infrastructure의 개념도 중요하지만 물리적으로 인프라에 사용되는 각각의 자원의 특징에 대한 지식이 유지 관리 차원에서 반드시 필요
  • 대표적인 IassS 서비스: AWS - EC2(Elastic Compute Cloud)
  • → All CSPs are providing IaaS to the public

PaaS (Platform as a Service)

Network → Storage → Server → Virtualization → OS → MiddleWare → Runtime

  • 서비스 개발자가 애플리케이션 개발, 실행, 관리 등을 할 수 있도록 안정적인 플랫폼(실행 환경) 또는 프레임워크를 제공하는 Cloud 서비스 방식
  • 프로그래밍 언어의 개발 환경이나 실행 환경 또는 데이터베이스 등이 미리 설치되어 있어서 인프라 구축을 하지 않아도 그 기반을 사용할 수 있기 때문에 단기간에 개발을 해서 서비스를 제공할 수 있음
  • IaaS 와 차이점은 서버, 네트워크, 보안 부분을 Cloud 사업자에게 위임하는 것이고, SaaS는 정해진 소프트웨어를 서비스로 제공하는 것이고, PaaS는 직접 개발한 프로그램을 가동하기 때문에 자유도가 높음
  • 세일즈 포스가 제공하는 force.com과 사이보우즈의 kintone, 오픈 소스 PaaS 기반 Cloud Foundry, GCP, serviceNow Platform, DBMS on Cloud (OCI) 등이 있음
  • 개발 프레임워크: Ruby on Rails, Spring, Node.js, Eclipse 등
  • 메시징 미들웨어(Message Broker): Amazon SQS, Rabbit MQ, Kafka 등

SaaS (Software as a Service)

Network → Storage → Server → Virtualization → OS → MiddleWare → Runtime → Data → Application

  • 업무에서 사용하는 소프트웨어 기능을 인터넷 등의 네트워크를 통해 필요한 만큼 이용할 수 있도록 제공하는 형태
  • 하나의 서버를 여러 기업에서 공유하는 것을 전제한 multi-tenant 방식 서비스를 제공하지만, 데이터는 기업 사용자별로 분리되도록 설계하여 보완성을확보
  • 소프트웨어의 업데이트 작업은 사용자가 아니라 Cloud 사업자가 수행하기 때문에 항상 최신의 기능을 사용할 수 있으며 소프트웨어 버그가 방치되지 않음
  • 대표적인 소프트웨어: 전자 메일, 그룹웨어, CRM(Customer Relationship Management - 고객 관리 시스템)
    • Google Apps, salesforce, Office 365 등

DaaS (Desktop as a Service)

서비스로서의 데스크톱을 의미하는데, 인터넷만 연결되면 언제 어디서나 어떤 기기로도 기업 내부 망에 접속할 수 있는 Cloud 서비스의 일종

  • 모든 정보가 중앙 서버에 저장되기 때문에 직원의 개별 PC가 바이러스에 노출되거나 파손, 분실되어도 정보 유출의 위험이 적으며 외부에서 기업의 업무 망에 접근하는 가장 안전한 기술
  • 특징
    • 연속성 : 구성원들이 일하는 장소나 기기에 상관없이 사무실과 동일한 업무 경험을 유지할 수 있도록 지원
    • 비용 절감 (가상의 업무 공간을 구독의 형태, 초기 구축 비용 X)
    • 구축 비용의 유무가 가상화 데스크톱인 VDI(Virtual Desktop Infrastructure 와 DaaS를 차별화하는 요소
    • 가상화가 일어나는 공간이 사용자가 보유한 인프라면 VDI가 되고 Cloud 사업자면 DaaS가 됨
    • 보안성 : 기업의 업무망을 중앙의 가상화된 서버로 조성하기 때문에 개인 PC에는 화면만 전송하는 기술이므로 개인 PC가 보안에 취약해도 중앙 업무망은 영향을 받지 않음

Public Cloud

CSP(Cloud Service Provider) 가 시스템을 구축하고 인터넷망 등의 네트워크를 통해 불특정 다수의 기업과 개인에게 서비스를 제공하는 형태

특징

  • 사용량에 따라 비용을 지불하는 요금 산정 방식(종량제)
  • 사용자 및 그룹 관리로 권한 관리를 통해 서비스를 격리하기 때문에 사용자 간이 간섭이 발생하지 않음
  • 사용자는 IT 자산을 보유하지 않더라도 컴퓨팅 리소스를 서비스로 사용할 수 있으며, 필요한 컴퓨팅 자원을 단기간에 저비용으로 마련할 수 있고 운용 관리 부담이 적음
  • 서비스 이용자를 제한하지 않음

Private Cloud

Cloud 서비스의 사용자 또는 사업자의 데이터 센터에 Cloud 관련 기술이 활용된 자사 전용 환경을 구축하여 컴퓨팅 리소스를 유연하게 이용할 수 있는 형태

  • 폐쇄적인 구조
  • 특정 기업의 특정 사용자만을 대상으로 하는 Cloud 서비스
  • 가상화, 자동화와 같은 Cloud 관련 기술의 활용으로 인해 시스템의 성능과 비용이 최적화되므로 유연한 사용자 정의가 가능
  • 자원과 데이터의 제어권을 기업 자체에서 소유
  • 물리적인 데이터 보안 측면에서 퍼블릭 클라우드보다 강함
  • 구현 방식
    • On-Premise Private Cloud
      • 자사가 보유하고 운영
    • Hosted Priviated Cloud
      • Cloud 사업자가 장비를 보유하고 Private Cloud 서비스를 제공하는 형태
    • Community Cloud
      • 공통의 목적을 가진 특정 기업들이 클라우드 시스템을 형성하여 데이터센터에서 공동 운영하는 형태
      • Public cloud 와 Private cloud 의 중간적인 형태
    • Hybrid Cloud
      • Public Cloud 와 Private Cloud 를 네트워크를 통해 결합해서 두가지 서비스의 장점을 활용할 수 있도록 만든 클라우드 서비스 방식
      • 서로 다른 Cloud 간에 데이터와 애플리케이션 공유 및 이동이 유연하게 처리될 수 있고, 용도에 맞는 서비스 구현에 유리
      • 기업 내부의 민감하고 중요한 데이터 처리 작업은 퉁제력을 강화하기 위해서 Private Cloud 를 사용
      • 일반 업무 데이터 처리 같은 보안 요구 사항이 낮은 작업이나 워크로드가 지속해서 증가하는 작업에는 리소스 자동 조정이 가능한 퍼블릭 클라우드를 사용하기도 하는데 최근에는 가상 서버와 물리 서버의 결합으로 보기도 함
    • Multi Cloud
      • 조직이 2개 이상의 클라우드 제공업체의 클라우드 컴퓨팅 서비스를 사용하여 애플리케이션을 실행하는 것
      • 단일 클라우드 스택을 사용하는 대신 2개 이상의 퍼블릭 클라우드, 2개 이상의 프라이빗 클라우드 또는 둘의 조합을 포함
      • 특정 비즈니스 요구에 가장 적합한 기능을 선택하면 공급업체 종속을 최소화 할 수 있음

Cloud & On-Premise

비용

  • 초기 투자 비용은 On-Premise 가 많이 소모
  • 사용자가 5년 이상의 장기간에 걸쳐 시스템을 계속하는 경우나 대규모 시스템을 구축하고 운용할 경우에는 On-Premise 가 더 저렴할 수 있음
  • Cloud 구축 시 기존 In-Premise 시스템의 수정이나 데이터 이행에 소모되는 비용이 많이 발생하는 경우도 있음

안정성과 신뢰성

클라우드의 리스트

  • IaaS 의 리스크는 Cloud 사업자의 하드웨어 장애로 인한 데이터 손실이나 서비스 중단 등을 들 수 있고, 네트워크 리스크로는 통신 도청, 중간자 공격, 스푸핑 같은 통신 위협과 네트워크 관리 미비에 따른 시스템 다운 위협 등을 꼽을 수 있음
  • 사용자가 세울 수 있는 대책으로는 IaaS의 장애에 대비하여 가상 서버를 백업하거나 쉽게 가상 서버 환경을 구축하기 위한 템플릿을 마련하는 것

Cloud 보안 거버넌스

  • 클라우드를 이용함으로 인해 기업 사용자는 자사가 보유한 정보의 관리와 처리를 클라우드 사업자에게 맡겨 버리기 때문에 보안 등의 리스크를 모두 통제할 수 없다는 문제가 발생
  • 클라우드 보안 거버넌스의 관점에서 바라보면 클라우드 서비스의 Incident와 서비스 복구와 같은 사항들은 제어가 어렵고 클라우드 사업자의 갑작스런 파산이나 서비스 중단과 같은 클라우드 서비스의 연속성 리스크 또한 존재
  • 기업 사용자는 클라우드 사업자 및 이용자 측에서 잠재된 보안 위험 요소를 확인해 두는 것이 중요하고, 클라우드를 이용할 때 클라우드 사업자와 이용자 사이의 책임 분계선 등 이용자가 관리할 수 있는 범위를 파악한 후 보안 대책과 백업을 마련할 필요가 있음

클라우드를 지탱하는 기술

가상화(Visualization)

물리적인 메모리와 하드 디스크, OS 등 다양한 부품을 소프트웨어로 대체하는 것이 가상화 기술

  • 가상 서버는 물리 서버 1대 위에 게스트가 되는 서버 여러 대를 가상으로 생성하는데, 본래 서버에 필요한 물리적인 부품을 가상으로 생성해서 가상 서버로 만드는 것
  • 네트워크의 경우도 마찬가지로 물리적 배선 1개를 가상으로 분할하여 다른 네트워크와 통합하거나 그 즉시 연결을 바꿀 수도 있음
  • 가상 서버에 할당된 메모리와 스토리지는 자유롭게 늘리거나 줄일 수 있기 때문에 나중에 필요할 때 용량을 늘리거나 줄여 메모리와 스토리지의 성능을 조절할 수 있지만 가상 서버의 성능을 올리는 것은 한계가 있음
  • 성능을 한계까지 끌어올려도 부하가 발생할 때 서버 대수를 늘리지 않으면 대응할 수 없는데, 물리적인 서버의 경우 1대를 늘리는데 CPU와 메인보드, 메모리, 스토리지 등이 필요
  • 가상화는 소프트웨어처럼 구축하기 때문에 서버 복제가 쉽고 대수를 늘리거나 줄이기도 쉬움

분산 처리와 로드 밸런서

분산 처리란 기기 여러 대에 분산하여 처리하는 방법

  • 같은 기능이나 정보를 가진 서버 여러 대에 분배하여 처리하면 서버 1대의 부담을 줄이고 서버가 응답할 수 없거나 다운되는 사태를 막을 수 있음
  • 서버 여러 대에 분배하는 장치를 Load Balancer 라고 하는데, 로드 밸런서는 각 서버를 확인하여 부하를 분산하고 경우에 따라서는 부하가 너무 높아진 서버를 분리하기도 함
  • AWS - ELB(Elastic Load Balancing)

이중화

  • 시스템이나 서버에 문제가 생겨도 계속 가동할 수 있도록 조치하는 것
  • 백업하거나 여러 대를 운영하는 것이 일반적
  • 가상화나 분산 처리 방식은 이러한 이중화에도 크게 도움이 되는데, 서버 여러 대를 구축하는 것은 그것만으로도 백업이 되고 분산 처리를 해두면 서버 한 대에 문제가 생겨도 다른 서버에 의해 기능이 유지됨

2. Cloud Native

조직이 Public, Private, Hybrid Cloud 와 같은 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있도록 해주는 기술

  • Container, Micro Service, Service Mesh, Immutable Infra, Declarative API(선언적 API) 가 이러한 접근 방식의 예시이며, 이러한 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 해주는 견고한 자동화 기능을 함께 사용하면 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주 예측 가능하게 수행할 수 있음

Cloud Native 적용이 필요한 이유

  • 서비스 배포 시간 단축
    • 지속적인 적용(Continues Delivery)을 통한 빠른 배포 가능
  • 애플리케이션 및 서비스 현대화
    • 컨테이너로 애플리케이션을 배포하면 운영 인프라에 대한 종속성 감소
    • Kubernetes는 모든 인프라에 컨테이너를 배포할 수 있는 단일 통합 플랫폼 제공
  • 신속한 신규 서비스 개발 사이클
  • 사업 성장을 위한 조직 문화 혁신 촉진

Pillars of Cloud Native

DevOps

IT 서비스 설계, SW 개발, 릴리즈 및 운영에 이르기까지 전체 서비스 수명 주기에 함께 참여하는 IT 서비스 운영 및 개발 엔지니어의 업무 방식

  • 데브옵스는 팀이 애플리케이션 개발에서 프로덕션 운영에 이르는 전체 프로세스를 소유하는 방법론
  • 일련의 기술 구현을 넘어 문화와 프로세스의 완전한 변화를 요구
  • 전체 기능이 아닌 작은 구성 요소에서 작업하는 엔지니어 그룹을 요구하여 일반적인 오류 소스인 핸드 오프를 줄임
  • 소프트웨어의 개발과 운영의 합성어로서 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화

DevOps Tool Chain

  • 계획(PLAN) - 목적을 수행하기 앞서 방법이나 젃차 등을 미리 생각하여 계획
  • 코드(CODE) - 코드 개발 및 검토, 버젂 관리 도구, 코드 병합
  • 빌드(BUILD) - 지속적 통합(CI) 도구, 빌드 상태
  • 테스트(TEST) - 테스트
  • 패키지(PACKAGE) - 애플리케이션 디플로이 이젂 단계
  • 릴리스(RELEASE) – 변경 사항 관리, 릴리스 승인, 릴리스 자동화
  • 구성(OPERATE) - 인프라스트럭처 구성 및 관리, laC (Infrastructure as Code) 도구
  • 모니터링(MONITORING) - 애플리케이션 성능 모니터링, 최종 사용자 경험

CI/CD

애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법
새로운 코드 통합으로 인해 개발 및 운영 팀에 발생하는 문제(integration hell)를 해결하기 위한 방법

  • CI (Continuous Integration) - 지속적인 통합
  • CD (Continuous Delivery) - 지속적인 서비스 제공
  • CD (Continuous Deploy) - 지속적인 배포

Microservices

애플리케이션을 상호 독립적인 최소 구성 요소로 분할

  • 모든 요소가 독립적으로 연동되어 테스크를 수행
  • 소프트웨어 개발에 대한 이러한 접근 방식은 세분화, 경량화 되어 있으며 다수의 애플리케이션 간에 유사한 프로세스를 공유하는 기능을 중시함
  • 특징
    • 높은 유지 관리 및 테스트 가능성
    • 느슨한 결합(어느 한쪽의 변화가 다른쪽에 영향을 끼치지 않도록 함)
    • 독립적으로 배포 가능
    • 비즈니스 역량을 중신으로 구성됨
    • 소규모 팀이 소유함
profile
Don’t get mad at the computer.

0개의 댓글