Cloud: 개요 및 인프라

Ohback·2025년 4월 15일
awscloud클라우드

SK 네트웍스 Family AI camp

목록 보기
67/73

1. 클라우드란 무엇인가?

인터넷을 통해 컴퓨팅 자원(서버, 스토리지, 네트워크)과 플랫폼/애플리케이션을 필요할 때 즉시 빌려 쓰는 방식으로 업계에선 인프라(IaaS), 플랫폼(PaaS), 소프트웨어(SaaS)로 크게 나누며, 최근에는 인프라·플랫폼·AI/데이터를 통합 제공하는 전략적 클라우드 플랫폼 서비스(SCPS)라는 개념으로 설명한다.

1-1. 클라우드 등장 배경

  • CAPEX → OPEX 전환: 물리 서버를 직접 구매·유지하지 않고 사용량만큼 지불.
  • 가상화/컨테이너 보편화: 하드웨어 효율↑, 배포 자동화↑(Docker, Kubernetes).
  • 글로벌 연결성: 광대역 인터넷·CDN 덕에 전 세계 사용자에게 저지연 제공.
  • 서비스 복잡도 증가: 보안/로그/배포/데이터 등 운영 요소를 관리형 서비스로 위임.
  • AI 시대의 연산 수요: 대규모 학습·추론 인프라를 빠르게 확장하려는 수요.

1-2. 클라우드 서버의 장단점

장점

  • 초기 비용↓, 운영 자동화로 개발→실서비스 속도 빨라짐
  • 탄력적 확장/축소(트래픽 급증에도 자동 대응)
  • 글로벌 리전/가용영역으로 높은 가용성
  • 보안·관제·백업 등 관리형 서비스 다수 제공

단점

  • 벤더 락인(특정 서비스 의존)
  • 비용 예측 어려움(데이터 이그레스·서버리스 과금 등)
  • 지연/데이터 주권 이슈(국가별 규제)
  • 대규모 장애 시 광범위한 영향

1-3. 클라우드를 제공하는 회사 Top 3와 특징

시장 구도(2025년 1분기)

  • AWS 32%, Microsoft Azure 23%, Google Cloud 10%. 상위 3사가 합쳐 65% 비중. 성장률은 Azure·GCP가 30%대, AWS는 17%대. canalys.com

1) AWS (Amazon Web Services)

  • 가장 폭넓은 서비스 포트폴리오와 리전 규모
  • Nitro System으로 가상화 오버헤드↓·보안 격리↑, 성능/가격 효율↑
  • Bedrock으로 멀티 파운데이션 모델·에이전트/파인튜닝/가드레일·지식베이스까지 제공
  • Trainium/Graviton 등 커스텀 칩 투자(Trainium 2 가격-성능 개선 발표)

2) Microsoft Azure

  • Microsoft 365/Windows/SQL Server 등 엔터프라이즈 제품과의 긴밀한 통합
  • Microsoft Entra ID(구 Azure AD) 기반 통합 ID/접근관리
  • Azure Arc로 온프레미스·멀티클라우드 일원적 거버넌스/운영 제공
  • Microsoft Fabric으로 데이터 통합·분석·BI를 하나의 SaaS로 제공

3) Google Cloud (GCP)

  • 데이터/AI 특화: BigQuery(서버리스 DWH), Vertex AI(LLM/ML 플랫폼), TPU 가속기
  • Cloud Run으로 컨테이너 서버리스 운영 간소화
  • BigQuery는 ML·지리공간·BI 내장, 완전관리형 서버리스 아키텍처
  • Vertex AI로 LLM 커스터마이징·배포·에이전트 빌더 제공, TPU v5e 등 하드웨어 스택



2. AWS

이미지 출처: https://k21academy.com

AWS는 2025년 클라우드 시장 점유율 1위를 유지하고 있는 회사로, 전 세계적인 리전/가용영역, 수백 개의 관리형 서비스를 바탕으로 스타트업부터 엔터프라이즈까지 폭넓게 쓰인다. Nitro 기반의 보안/성능, Bedrock·SageMaker 등 AI 스택, Trainium/Graviton 등 커스텀 실리콘으로 인프라·AI 비용 효율을 강화하고 있다.

2-1. 주요 서비스

  • EC2: 가상 서버(온디맨드/스팟/리저브드, Graviton 포함)
  • S3: 객체 스토리지(버전관리·수명주기 정책)
  • EBS/EFS: 블록/네트워크 파일 스토리지
  • RDS/Aurora: 관리형 관계형 DB(MySQL/PostgreSQL 등)
  • DynamoDB: 서버리스 NoSQL
  • Lambda: 서버리스 함수
  • ECS/EKS/Fargate: 컨테이너 오케스트레이션/서버리스 런타임
  • VPC: 격리 네트워크(서브넷/NACL/보안그룹)
  • Route 53: DNS/헬스체크/지리적 라우팅
  • CloudFront: 글로벌 CDN
  • IAM/Cognito: 권한/정체성 관리
  • CloudWatch/CloudTrail: 모니터링/로깅/감사
  • SQS/SNS/EventBridge: 메시징·이벤트 버스
  • Step Functions: 서버리스 워크플로
  • API Gateway: API 관리
  • SageMaker / Bedrock: ML 파이프라인·생성형 AI/에이전트
  • Redshift/Glue/EMR/Athena/Kinesis: 데이터 웨어하우스/ETL/빅데이터/쿼리/스트리밍
  • OpenSearch Service: 검색·로그 분석
  • Organizations/Control Tower: 멀티계정 거버넌스/랜딩존



3. 운영 서버 환경 구성

3-1. 3계층 구조

3계층 구조는 시스템을 표현 계층(프런트/웹), 애플리케이션 계층(비즈니스 로직), 데이터 계층(DB/스토리지)로 분리해 설계·배포하는 아키텍처이다. 각 계층은 역할이 분리되어 독립적으로 확장·배포·운영할 수 있다는 점이 핵심이다.

출처: https://jaws-coding.tistory.com/9

  • 네트워크 계층(프레젠테이션 계층)

    • VPC 분리: 퍼블릭 서브넷(ALB, NAT), 프라이빗 서브넷(EC2, RDS)로 분리하는 것이 기본이다.
    • 보안 그룹: ALB는 80/443만 개방하고, EC2는 ALB 보안 그룹만 인바운드로 허용하는 것이 원칙이다.
    • 아웃바운드: EC2는 인터넷 업데이트를 위해 NAT 게이트웨이를 사용하는 것이 일반적이다.

  • 컴퓨트 계층(EC2)

    • EC2 = 클라우드의 가상컴퓨터이고, 인스턴스 = 그 가상컴퓨터 한 대의 실행체이다.
    • ASG(오토스케일링 그룹) 로 최소/최대/원하는 용량을 정의해 부하에 따라 자동 증감하는 구조이다.
    • Launch Template 로 AMI, 인스턴스 타입, 보안 그룹, 사용자 데이터 스크립트를 표준화하는 것이 중요하다.
    • 무상태 애플리케이션으로 설계해 인스턴스 교체 시 세션 유실이 없도록 하는 것이 핵심이다.

  • 데이터·스토리지 계층

    • RDS 는 프라이빗 서브넷 Multi-AZ로 구성해 장애 조치가 자동인 구조이다.
    • S3 는 정적 자산과 업로드 파일을 저장하고 CloudFront로 캐시·배포하는 구조이다.
    • 세션/캐시 는 ElastiCache Redis 등 외부 저장소를 사용해 서버를 무상태로 유지하는 구조이다.

3-2. EC2란?

EC2는 AWS에서 제공하는 가상 컴퓨터를 빌려 쓰는 서비스이다.
EC2 한 대의 실행체를 인스턴스라고 하며, CPU/메모리 사양(인스턴스 타입), 디스크(EBS), 이미지(AMI), 네트워크(VPC/서브넷/보안그룹), 접속 키(키 페어) 등의 요소로 구성된다. 웹 배포에서는 EC2 위에 리눅스 + Nginx(리버스 프록시) + Gunicorn/Uvicorn(WSGI/ASGI 앱 서버) + Django 를 올려 운영하는 구성이 표준이다.



3-3. Django의 구성요소 및 흐름

Django는 전통적 MVC를 Django스럽게 재해석해 MVT라고 부르며, Model, View, Template 3요소가 핵심이다.

이미지 출처: https://medium.com/@AyushAgrawal_/

3-4. 구성요소

  • Model:

    • 데이터 구조와 비즈니스 규칙을 정의하는 계층이다.
    • Django ORM으로 RDS(MySQL/PostgreSQL 등)와 상호작용하며, models.py와 마이그레이션으로 스키마를 관리한다.

  • View:

    • 요청을 받아 로직을 실행하고 응답을 결정하는 계층이다.
    • DB 조회·검증·권한 체크 등을 수행한 뒤 Template을 렌더링하거나 JSON을 반환한다.
    • URL 라우팅(urls.py)과 미들웨어를 통해 진입하게 된다.

  • Template:

    • 사용자에게 보여줄 화면을 렌더링하는 계층이다.
    • Django 템플릿 언어(DTL)로 HTML을 생성하며, 정적 파일은 static/에서 제공되고 사용자 업로드는 media/로 분리된다.

Django는 Controller 역할을 프레임워크(라우터/미들웨어)가 맡고, 개발자는 View에 집중한다는 점에서 전통 MVC와 표현이 다를 뿐 개념적 대응은 유사하다.

3-5. EC2 위에서의 Django 요청 흐름

사용자 → Route 53(도메인) → CloudFront/WAF(선택)
     → ALB(로드밸런서) → Nginx(EC2) → Gunicorn/Uvicorn → Django
     → URLconf → View → Model(ORM→RDS) → Template 렌더링 → 응답
                   ↘ static/media 는 보통 S3(+CloudFront)에서 제공
  • Nginx는 정적 요청을 가능한 한 캐싱/서빙하고, 동적 요청을 Gunicorn/Uvicorn으로 프록시하는 역할을 한다.
  • View는 비즈니스 로직을 수행하고, 필요 시 Model을 통해 RDS에 접근한 뒤 Template을 렌더링하여 HTML 응답을 만든다.
  • 정적/업로드 파일은 EC2가 아닌 S3(+CloudFront) 로 분리해 성능과 확장성을 확보하는 것이 일반적이다.

3-6. MVT와 인프라의 역할 매핑 요약

  • Model ↔ RDS/Aurora: ORM이 DB 연결을 추상화하여 데이터 영속성을 담당한다.
  • View ↔ Gunicorn/Uvicorn 경유 실행: WSGI/ASGI 앱 서버가 Django View를 호출한다.
  • Template ↔ Nginx/CloudFront 전송: 렌더링된 HTML은 Nginx를 통해, 정적 자산은 S3/CloudFront로 전송된다.
  • 보안·스케일링 ↔ ALB/ASG/보안그룹: 무중단 배포와 수평 확장을 인프라가 책임진다.



4. 관계형 데이터 저장, RDS

RDS(Relational Database Service)는 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora 같은 관계형 데이터베이스를 관리형으로 제공하는 서비스이다. 백업·패치·모니터링·장애 조치 같은 운영 작업을 AWS가 대신 처리하며, 애플리케이션은 표준 드라이버로 DB에 접속하면 된다.

4-1. 구성요소와 구조

  • DB 엔진/버전: MySQL, PostgreSQL 등 원하는 엔진과 버전을 선택하는 요소이다.
  • DB 인스턴스 클래스: vCPU·메모리 사양을 결정하는 요소이다.
  • 스토리지 타입: gp3(범용 SSD), io2(프로비저닝 IOPS) 등 성능·비용을 결정하는 요소이다.
  • Multi-AZ: 두 가용영역에 동기식 복제를 구성해 장애 시 자동으로 승격되는 구조이다.
  • 리드 레플리카: 읽기 부하를 분산하기 위한 비동기 복제 인스턴스 구조이다.
  • 서브넷 그룹: RDS가 배치될 프라이빗 서브넷 묶음이다.
  • 보안 그룹: 인바운드/아웃바운드 접근을 제어하는 가상 방화벽이다.
  • 파라미터/옵션 그룹: 엔진 설정값과 플러그인(예: pg_stat_statements)을 제어하는 구성이다.
  • 백업·스냅샷·PITR: 자동 백업과 시점 복구(Point-In-Time Recovery)를 제공하는 구성이다.
  • 모니터링: CloudWatch, Enhanced Monitoring, Performance Insights로 병목을 추적하는 구성이다.

4-2. 권장 배치(EC2 기반 3계층 예시)

사용자 → Route 53 → CloudFront(+WAF) → ALB
                             ↓
                    EC2(오토스케일링, 프라이빗 서브넷)
                             ↓
               RDS Multi-AZ(프라이빗 서브넷, SG 최소권한)

ALB는 퍼블릭 서브넷, EC2와 RDS는 프라이빗 서브넷에 두고, EC2 SG → RDS SG만 허용하는 최소 권한 구조가 기본이다.

4-3. 외부 저장소와 연동

여기서 “외부 저장소”는 보통 S3와의 연동을 의미하며, 다음과 같은 패턴이 있다.

(1) RDS ↔ S3 데이터 입출력

  • PostgreSQL(Aurora/RDS): aws_s3 확장으로 S3에서 테이블로 가져오거나 내보내는 구조이다.
    -- 예시: S3 객체를 테이블로 적재
SELECT aws_s3.table_import_from_s3(
  'public.my_table',
  '',
  '(format csv, header true)',
  'my-bucket',
  'path/data.csv',
  'ap-northeast-2'
);
    전제: RDS에 IAM 역할을 연결하고 해당 역할에 S3 권한을 부여해야 한다.
  • MySQL/MariaDB: 엔진 버전에 따라 LOAD DATA FROM S3 / SELECT INTO OUTFILE S3를 지원하며 대량 적재·언로드에 사용되는 구조이다.

(2) 스냅샷/로그 → S3

  • 스냅샷 내보내기: RDS 스냅샷을 S3로 내보내 보관·분석 파이프라인에 투입하는 구조이다.
  • 로그 통합: 느린 쿼리/일반 로그는 CloudWatch Logs로 내보내고, 이를 S3로 집계하여 Athena/Glue로 분석하는 구조이다.

(3) 애플리케이션 경유 연동

  • 대량 업로드 파일은 S3에 먼저 저장하고, Lambda/SQS로 비동기 파이프라인을 거쳐 RDS로 적재하는 구조가 유지보수에 유리하다.
  • 프라이빗 서브넷에서 S3에 접근할 땐 VPC 게이트웨이 엔드포인트(S3) 를 사용해 NAT 비용과 노출을 줄이는 것이 권장이다.

(4) 인증과 보안

  • Secrets Manager로 DB 자격증명을 관리하고 애플리케이션에 환경 변수로 주입하는 구조가 안전하다.
  • MySQL/PostgreSQL은 IAM 데이터베이스 인증을 지원하므로, 토큰 기반의 임시 접속을 고려하는 것이 좋다.



5. 정적 데이터 저장, S3

S3(Simple Storage Service)는 객체 스토리지로, 파일(객체)을 버킷에 저장하고 전 세계 어디서나 확장성과 내구성을 갖고 접근할 수 있는 서비스이다. 정적 웹 호스팅, 사용자 업로드, 로그 보관, 데이터 레이크 등 범용 저장소로 쓰인다.

5-1. 구성요소와 구조

  • 버킷(Bucket): 객체를 담는 최상위 컨테이너이다.
  • 객체(Object) & 키(Key): 파일과 그 경로/이름에 해당하는 식별자이다.
  • 버전관리(Versioning): 덮어쓰기·삭제 대비를 위한 다중 버전 저장 구조이다.
  • 스토리지 클래스: Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier(Instant/Flexible/Deep) 등 액세스 패턴별 비용 최적화 구조이다.
  • 수명주기(Lifecycle): 일정 기간 후 다른 클래스 이동·만료·삭제를 자동화하는 정책 구조이다.
  • 암호화: SSE-S3(기본), SSE-KMS(키 관리), SSE-C(고객 제공 키) 구조를 제공한다.
  • 액세스 제어: IAM 정책, 버킷 정책, 퍼블릭 차단, CORS, 객체 ACL(가급적 비권장)로 구성한다.
  • 이벤트: 객체 생성/삭제를 Lambda, SQS, EventBridge로 통지하는 구조이다.
  • 전송/업로드: 멀티파트 업로드, Pre-signed URL, Transfer Acceleration 등 대용량·원거리 최적화 구조이다.

웹 배포(정적·미디어) 구조

사용자 → CloudFront(OAC) → S3(프라이빗)
           ↘ WAF

S3는 퍼블릭 차단 상태로 두고, CloudFront의 OAC(Origin Access Control) 를 사용해 오직 CloudFront만 S3에 접근하게 하는 구조가 안전하다.

5-2. 외부 저장소(애플리케이션/브라우저)와의 연동

(1) 서버 사이드 업로드/다운로드

  • 서버(EC2/ECS/Lambda)가 IAM Role을 통해 SDK(boto3 등)로 S3에 직접 Put/Get하는 구조이다.
  • 프라이빗 서브넷에서 접근 시 S3 VPC 게이트웨이 엔드포인트를 사용해 인터넷/NAT 없이 통신하는 구조가 권장이다.

(2) 브라우저에서 직접 업로드(Pre-signed URL)

  • 백엔드가 S3 PutObject용 사전 서명 URL을 생성하고, 브라우저가 해당 URL로 직접 업로드하는 구조이다.
  • 서버의 트래픽/메모리를 거치지 않으므로 대용량 파일에 유리하며 비용도 절감되는 구조이다.
    # 예시: 파이썬(boto3) 사전 서명 URL 생성
import boto3, datetime
s3 = boto3.client('s3', region_name='ap-northeast-2')
url = s3.generate_presigned_url(
    ClientMethod='put_object',
    Params={'Bucket': 'my-bucket', 'Key': 'uploads/photo.png', 'ContentType': 'image/png'},
    ExpiresIn=600  # 10분
)
  • CORS 설정을 버킷에 적용해 브라우저 도메인에서의 PUT/GET을 허용하는 것이 필요하다.

(3) CloudFront + OAC로 안전한 다운로드

  • 다운로드는 CloudFront 배포 도메인을 통해 제공하고, S3는 버킷 정책으로 CloudFront 서명 요청만 허용하는 구조가 안전하다.
    // (개념 예시) S3 버킷 정책: CloudFront-OAC에서만 읽기 허용
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontOAC",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::<account-id>:distribution/<dist-id>" }
    }
  }]
}

(4) 데이터 레이크/분석 파이프라인

  • S3 → Glue/Athena/EMR/Redshift로 이어지는 분석 파이프라인 구성으로, 로그·원천 데이터를 S3에 적재한 뒤 스키마 온 리드 방식으로 쿼리하는 구조이다.
  • RDS 스냅샷을 S3로 내보내고, Athena/Glue로 탐색·전처리 후 다른 시스템에 적재하는 구조가 일반적이다.



6. 보안·비용 체크리스트

  • RDS: 프라이빗 서브넷, SG 최소 권한, Multi-AZ, 자동 백업, 성능 지표 알람이 기본이다.
  • S3: 퍼블릭 차단, OAC 기반의 CloudFront 원본 보호, SSE-KMS 암호화, 버전관리·수명주기 정책이 기본이다.
  • 네트워크: S3 VPC 게이트웨이 엔드포인트로 NAT 비용과 노출을 줄이는 것이 권장이다.
  • 자격증명: 애플리케이션은 IAM Role + Secrets Manager 조합으로 키 없는 운영을 구현하는 것이 표준이다.



profile
Ohback
기록은 기억을 지배한다.
이전 포스트

Docker: 컨테이너화 하기

다음 포스트

Team Project: 국립중앙박물관 AI Docent 서비스, "MUSE" 배포하기

0개의 댓글