[SKALA] 클라우드 기초 학습(1) - 개념 단어 정리

SKALA 에서 처음으로 클라우드에 관해 배우게 되었다.

그래서 클라우드 수업에서 사용되는 단어들이 낯설었고 그에 대한 정리가 필요해보였다.

 

선언적 방식 (Declarative)

"무엇을 해야 하는지"를 정의하는 방식

• 개발자는 결과(목표)를 정의하고, 시스템이 알아서 목표를 달성
• 내부적인 처리 방식은 시스템이 자동으로 결정
• 예로는 K8S의 Manifest 파일을 정의하는 것이 있다.

명령적 방식 (Imperative)

"어떻게 해야 하는지"를 정의하는 방식

• 개발자가 세부적인 수행 절차(How)를 직접 작성
• 프로세스를 제어할 책임이 개발자에게 있음

최근 선언적 방식이 가독성, 유지보수성, 확장성 등의 이유로 명령적 방식보다 더 많이 사용되고 있다.
우리는 무의식적으로 두 가지 방식을 모두 활용하고 있지만, 그 차이를 이해하고 목적에 맞게 선택하면 더욱 효과적으로 활용할 수 있을 것 같다고 생각된다.

---

Instance (인스턴스)

하나의 실행 단위를 의미한다.

많이 들어보고 코딩에서도 많이 쓰이는 용어이지만, 막상 설명하려하면 모호한 개념이였다.

쉽게 말하면, 인스턴스는 우리가 실행하는 하나의 프로그램 또는 프로세스라고 생각할 수 있다.

예를 들어, AWS의 EC2 인스턴스를 생성하면, 가상 머신 하나가 실행되는 것이다.

Service (서비스)

특정 기능을 수행하는 단위

서비스는 하나의 인스턴스로 구성될 수도 있고, 여러 개의 인스턴스가 함께 동작하는 경우도 있다.

예를 들어, 웹 애플리케이션을 위한 인증 서비스나 결제 서비스가 각각 독립적인 서비스로 동작할 수 있다.

 

Application (애플리케이션)

사용자의 특정 목적을 수행하는 소프트웨어 프로그램

애플리케이션은 여러 개의 서비스와 인스턴스로 구성될 수 있다.

 

쇼핑몰 어플리케이션을 예를 들어 위의 인스턴스, 서비스를 예를 들어볼 수 있다.

Application: 쇼핑몰 웹사이트
Service: 사용자 관리 서비스, 주문 서비스, 결제 서비스 등
Instance: 서비스가 실행되는 각각의 서버

 

Application ≥ Service ≥ Instance

애플리케이션은 여러 개의 서비스를 포함할 수 있고, 서비스는 여러 개의 인스턴스(서버)로 구성될 수 있다.

주문 서비스를 하나의 서버로도 구동할 수 있지만, 여러개의 서버를 통해 구동할 수도 있다는 점이다.

---

Node (노드)

클라우드 및 네트워크에서 사용하는 하나의 단위

위의 인스턴스 개념과 노드의 개념이 헷갈리었다. 노드 또한 많은 분야에서 범용적으로 사용되는 단어였다.

노드는 조금 더 명확한 의미를 가진 단위 표현이라고 이해해보면 도움이 될 것 같다.

또한, 해당 용어가 사용되는 맥락에 맞게 이해하려는 과정이 필요해보인다. 

• 네트워크 노드 → 하나의 물리 장비 (예: 한 대의 서버)
• AWS Node 그룹 → 여러 대의 컴퓨터로 이루어진 그룹
• 데이터 구조에서의 노드 → 명확하게 분리된 데이터 단위

Cluster (클러스터)

여러 개의 노드(서버)를 하나의 시스템처럼 운영하는 방식

클러스터를 사용하면 성능과 확장성을 높이고, 시스템 장애에도 유연하게 대처할 수 있다.
클러스터의 주요 예시는 다음과 같다.

• 데이터 클러스터: 대용량 데이터를 저장하고 처리하는 클러스터
• 쿠버네티스 클러스터: 컨테이너 기반의 애플리케이션을 관리하는 클러스터
• 웹 애플리케이션 서버 클러스터: 부하를 여러 서버에 분산하는 클러스터

Cluster ≥ Node

클러스터는 노드들의 집합으로 특정 목적에 맞게 만들어 사용한다.

---

Gateway (게이트웨이)

네트워크의 입구와 출구 역할을 하는 장치 또는 서비스

• 외부와 내부 네트워크를 연결
• 다른 프로토콜 간 변환 수행

API Gateway는 대표적인 예시로, 클라이언트가 여러 서비스에 직접 접근하는 것이 아니라, Gateway를 통해 요청을 전달할 수 있도록 한다.

클라이언트의 요청을 특정 서비스로 이동시켜주지만, 부하를 분산하는 역할은 하지 않는다.

Load Balancer (로드 밸런서)

트래픽을 여러 노드(서버)로 분산하는 역할

트래픽이 한 서버에 집중되면 과부하가 발생할 수 있다. 로드 밸런서는 이를 방지하고 성능을 최적화한다.

API 요청을 변환하거나 보안 기능을 제공하지는 않는다.
대표적인 예시로 AWS Elastic Load Balancer(ELB)가 있다.

Router (라우터)

네트워크를 연결하고, 최적의 경로를 찾아주는 장치

라우터는 여러 네트워크 간의 데이터를 전달하며, 패킷을 목적지까지 올바르게 전달하는 역할을 한다.

서로 비슷한 역할을 수행하지만, 각자의 역할이 있기에 명확하게 알고 가야할 부분인 것 같다.

---

Monolithic Architecture (모놀리식 아키텍처)

하나의 큰 애플리케이션으로 개발

• 유지보수 및 확장 어려움
• 오류 발생 시, 전체 시스템 영향
• 정확한 요구사항이 필요할 때 적합

Microservice Architecture (마이크로서비스 아키텍처)

작은 서비스 단위로 개발

• 유지보수 및 확장 용이
• 장애 발생 시, 특정 서비스만 영향
• 대규모 시스템에서 유리함

최근 MSA가 주목받으며 중요한 개념으로 자리 잡고 있다. 하지만 트랜잭션 관리가 중요한 금융권에서는 여전히 모놀리식 아키텍처를 유지하는 경우가 많다.
이는 MSA가 분산 환경을 기반으로 하기 때문에 트랜잭션 관리가 복잡해질 수 있으며, 데이터의 일관성을 유지하는 것이 더욱 어려워지기 때문이다.
따라서, MSA가 무조건적으로 좋은 선택이라고 생각하기보다는, 서비스의 요구사항을 면밀히 분석하고 적절한 아키텍처를 선택할 수 있는 판단력을 기르는게 중요해보인다.

---

Security Group (SG)

인스턴스 레벨에서 동작하는 방화벽

• 기본적으로 모든 인바운드 트래픽(들어오는 요청)은 차단
• 모든 아웃바운드 트래픽(나가는 요청)은 허용
• 상태 저장(Stateful) 방식:
  들어오는 트래픽(Inbound)이 허용되면, 자동으로 나가는 트래픽(Outbound)도 허용
• EC2 인스턴스에 적용됨

예시)

22번 포트(SSH) 허용 설정 하게되면 (인바운드 허용)
사용자가 EC2에 SSH로 접근 가능해진다.
그러면 SSH 응답 패킷도 자동으로 허용되어진다. (상태 저장으로 인한 아웃바운드 허용)

Network ACL (NACL)

VPC 서브넷 레벨에서 동작하는 방화벽

• 들어오는 트래픽(Inbound)과 나가는 트래픽(Outbound)을 각각 설정해야 함
• 무상태(Stateless) 방식:
  인바운드에서 특정 포트를 열어도, 아웃바운드에서 해당 포트를 별도로 허용해야 함
• 서브넷 단위로 적용

예시)

22번 포트(SSH) 허용 설정 하게되면 (인바운드 허용)

사용자가 EC2에 SSH로 접근 가능해진다.

하지만, 아웃바운드에서 22번 포트를 열어주지 않으면 응답 패킷이 차단된다. (무상태로 인한 아웃바운드 비허용)

EC2를 사용하면서 깊이 생각하지 않고 사용했던 부분들이 있었는데, 위의 개념을 이해하고 나니 앞으로 EC2를 사용할 때 더 명확하게 관리가 가능할 것 같다.

---

클라우드의 주요 특성

1. 확장성 (Scalability)

필요한 만큼 자원을 쉽게 확장하거나 축소할 수 있는 능력

클라우드에서는 사용량이 증가하면 자동으로 서버를 추가하고, 사용량이 감소하면 불필요한 자원을 줄이는 기능을 제공한다.
예시:

• EC2 인스턴스의 Auto Scaling
• Kubernetes의 Horizontal Pod Autoscaler (HPA)

2. 탄력성 (Elasticity)

급격한 변화에도 리소스를 자동으로 조절하여 유지하는 능력

클라우드는 예상치 못한 트래픽 변화에도 유연하게 대응할 수 있어야 한다. 탄력성이 뛰어난 시스템은 부하가 증가하면 자동으로 리소스를 늘리고, 부하가 줄면 자동으로 리소스를 축소하여 비용을 절감할 수 있다.

 

차이점: 확장성과 탄력성?

• 확장성: 시스템이 최대 성능을 유지하도록 자원을 조절하는 것
• 탄력성: 급격한 변화가 발생해도 자동으로 리소스를 조정하는 것

3. 내결함성 (Fault Tolerance)

시스템이 장애를 스스로 감지하고 회복할 수 있는 능력

클라우드에서는 일부 서버가 장애를 일으키더라도 전체 서비스가 중단되지 않아야 한다. (= 고가용성)

 

내결함성을 갖춘 시스템의 특징

• 여러 개의 가용 영역(Availability Zone)에 분산 배포
• 자동 복구 기능 제공 (예: AWS Auto Healing, Kubernetes Self-Healing)
• 장애 발생 시 즉시 대체 서버를 활성화

예시:

• AWS RDS Multi-AZ: 데이터베이스가 장애를 일으키면 자동으로 대체 인스턴스를 활성화
• Kubernetes의 ReplicaSet: 하나의 Pod가 종료되면 자동으로 새로운 Pod 생성

4. 민첩성 (Agility)

빠르게 변화하는 환경에 대응하고, 필요한 자원을 신속하게 활용하는 능력

클라우드는 기업이 변화하는 시장에 빠르게 대응할 수 있도록 돕는다.

• 새로운 기능을 빠르게 개발 및 배포 (CI/CD)
• 필요한 리소스를 몇 분 만에 추가 가능
• DevOps 및 AI Ops를 통해 자동화된 운영 가능

클라우드 환경을 구축할 때 이러한 장점을 충분히 이해하고, 이를 최대한 활용할 수 있도록 설계하는 것이 중요해보인다. 

---

서버리스(Serverless)

서버리스란 서버가 항상 실행되지 않고, 요청이 있을 때만 실행되는 컴퓨팅 방식을 의미한다.

 

서버리스의 특징

• 서버 관리 불필요 → 인프라 운영 없이 코드 실행 가능
• 사용한 만큼만 비용 지불 → 실행 시간에 따라 요금 부과
• 자동 확장 → 트래픽 증가 시 리소스 자동 확장

서버리스의 대표적인 예시

• AWS Lambda → 요청이 있을 때만 실행되는 함수 기반 서버리스 컴퓨팅
• Google Cloud Functions → 클라우드 이벤트에 반응하여 실행
• Azure Functions → 마이크로서비스 기반의 서버리스 환경 제공

서버리스 아키텍처의 장점

• 비용 절감 (서버를 항상 실행할 필요 없음)
• 운영 부담 감소 (서버 관리 필요 없음)
• 확장성이 뛰어남 (자동 확장)

Q : 서버리스는 이벤트 기반으로 작동한다고 하는데 서버 작동중이 아닌데 이벤트를 어떻게 감지할까?

A : 서버리스 어플리케이션이 해당 이벤트를 감지하는 것이 아니라 클라우드 업체(AWS, Google 등)가 이벤트를 감지해서 서버리스 어플리케이션을 실행시키는 구조였다. 이벤트는 푸시나 폴링 방식으로 이벤트를 수집한다고 한다.

서버리스는 서버 없이 작동되는 개념의 어플리케이션을 말하는 줄 알았지만, 그런건 아니었다.
MSA와 적합하여 점점 서버리스 구조를 많이 적용시키고 하니 확실히 알고 가야 할 개념인 것 같다.

 

위의 단어들은 개발하면서 한 번쯤은 들어봤던 개념들이지만, 추상적으로만 알고 사용해왔다는 걸 알게되었다.

정리하고 나니 앞으로의 대화나 클라우드 이해에 있어 더 도움이 될 것 같다.