AWS SAA 4주차 (2)

2025. 3. 15. 21:25·DevOps/AWS

1. 강의 내용

학습 범위

  • 17. 디커플링 애플리케이션: SQS, SNS, Kinesis, Active MQ
  • 18. AWS의 컨테이너: ECS, Fargate, ECR 및 EKS
  • 19. 솔루션 설계자 관점의 서버리스 개요

 


2. 강의 정리

1) SQS

: 메시지 큐 서비스로, 애플리케이션 간에 데이터를 주고받을 때 중간에 메시지를 임시로 저장하고 전달하는 기능을 한다.

 

 

1. 특징

  • 완전 관리형: 인프라 관리 없이 사용할 수 있음
  • 확장성: 무제한에 가까운 처리량, 대기열 메시지
  • 비동기 처리: 메시지를 보내고 즉시 다음 작업을 수행할 수 있음
  • 안전성: 메시지 손실 방지

    → 서비스 간의 의존성이 최소화 되고, 독립적으로 실행되어 전체적인 서비스의 유연성을 높임

 

 

2. SQS 구성 요소

  • 메시지(Message)
    • 전달하려는 데이터
    • 최대 256KB 텍스트 데이터 (더 큰 데이터는 S3와 연계 처리)
    • 기본적으로 4일 동안 저장되며, 최대 14일까지 연장 가능

  • 큐(Queue)
    • 메시지가 저장되는 공간
    • Standard Queue
      • 무제한에 가까운 처리량(자동 확장)과 최소 지연 시간 지원
      • 메시지가 적어도 한 번 이상 전달된다. (At Least Once Delivery)
      • 메시지 순서 보장 X, 중복 전달 방지 X
    • FIFO Queue
      • 기본으로 300 TPS, 높은 처리량 모드 시 최대 3000 TPS 지원
      • 중복 처리가 없도록 정확히 한 번만 전달된다. (Exactly Once Delivery)
      • 메시지 순서 보장 O, 중복 전달 방지 O

  • 생산자(Producer)
    • 큐에 메시지를 보내는 서비스

  • 소비자(Consumer)
    • 큐에서 메시지를 가져와 처리하는 서비스

 

 

3. 주요 기능

  • 가시성 타임아웃(Visibility Timeout)
    • 소비자가 메시지를 처리하는 동안 다른 소비자가 동일한 메시지를 중복 처리하지 않도록 설정된 시간
    • 기본값 30초, 최대 12시간까지 조정 가능
  • 긴 폴링(Long Polling)
    • 소비자가 큐에 메시지를 요청할 때, 대기열에 메시지가 없다면 메시지가 도착할 때까지 기다림
    • 빈 응답을 줄여 비용과 대기 시간을 최적화
  • 짧은 폴링(Short Polling)
    • 소비자가 큐에 메시지를 요청할 때, 즉시 응답을 반환하며 메시지가 없으면 빈 응답을 받음 (기본 설정)
  • 데드 레터 큐(Dead Letter Queue, DLQ)
    • 일정 횟수 이상 처리 실패한 메시지를 별도의 큐로 이동시킴
    • 디버깅 및 문제 분석 가능
  • 메시지 지연(Delay Queues)
    • 메시지를 큐에 추가한 후 일정 시간 동안 소비자에게 보이지 않도록 설정 (최대 15분)

 

 

4. SQS 동작 방식

  1. 생산자가 SQS 큐에 메시지를 전송 (SendMessage API 호출)
  2. 메시지는 SQS에 저장되며, 필요에 따라 복제되어 내구성을 보장
  3. 소비자가 큐에서 메시지를 polling하여 가져옴 (ReceiveMessage API 호출)
    • 처리 중 메시지가 다른 소비자에게 다시 할당되지 않도록 가시성 타임아웃이 설정됨.
  4. 메시지를 처리한 후, 소비자가 처리 완료를 알리기 위해 메시지를 삭제 (DeleteMessage API 호출)

 

 

5. 사용 사례

 

SQS 메시지 트래픽에 따른 Auto Scaling 적용(1)

 

SQS 메시지 트래픽에 따른 Auto Scaling 적용(2)

 

 


 

2) SNS

: 메시지를 발행(Publish)하면 이를 구독(Subscribe)한 모든 수신자에게 동시에 전달하는 push 기반 서비스이다.

SQS와 달리 메시지를 큐에 저장하고 소비자가 가져가기를 기다리는 방식이 아니라, 실시간으로 메시지를 push한다.

 

 

1. 특징

  • 완전 관리형: 인프라 관리 없이 사용할 수 있음
  • 확장성: 수백만 구독자에게 메시지 전송 가능
  • 실시간성: 메시지를 즉시 전달
  • 다양한 서비스 지원: 이메일, 

    → 서비스 간의 의존성이 최소화 되고, 독립적으로 실행되어 전체적인 서비스의 유연성을 높임

 

 

2. SQS 구성 요소

  • 메시지(Message)
    • 전달하려는 데이터
    • 최대 256KB 텍스트 데이터 (더 큰 데이터는 S3와 연계 처리)
    • 속성(Message Attributes)을 추가해 필터링 가능

  • 토픽(Topic)
    • 메시지를 발행하고 구독자가 수신하는 논리적 채널
    • 각 토픽은 고유한 ARN(Amazon Resource Name)을 가짐.

    • Standard Topic
      • 무제한에 가까운 처리량(자동 확장)과 최소 지연 시간 지원
      • 메시지가 적어도 한 번 이상 전달된다. (At Least Once Delivery)
      • 메시지 순서 보장 X, 중복 전달 방지 X
      • 다양한 서비스 구독자를 지원한다. (Email, SMS, HTTP, SQS, Lambda 등)
    • FIFO Topic
      • 기본으로 300 TPS , 높은 처리량 모드 시 최대 3000 TPS 지원
      • 중복 처리가 없도록 정확히 한 번만 전달 (Exactly Once Delivery)
      • 메시지 순서 보장 O, 중복 전달 방지 O
      • SQS FIFO Queue 구독자만 지원한다.

  • 발행자(Publisher)
    • 토픽에 메시지를 보내는 애플리케이션 또는 서비스.

  • 구독자(Subscriber)
    • 토픽에서 메시지를 받는 엔드포인트 (ex: 이메일, SMS, Lambda, SQS 등)

 

 

3. 주요 기능

  • 메시지 필터링(Message Filtering)
    • 구독자가 메시지 속성을 기반으로 수신 여부를 결정(예: "type=error" 메시지만 수신)
  • 팬아웃(Fan-out)
    • 하나의 토픽에서 여러 SQS 큐로 메시지를 분배 가능
    • SQS 큐의 액세스 정책에서 SNS가 메시지를 보낼 수 있도록 허용해야 함
  • 데드 레터 큐(Dead Letter Queue, DLQ)
    • 전달 실패한 메시지를 별도의 SQS 큐로 저장

 

 

4. SQS 동작 방식

  1. 발행자가 SNS 토픽에 메시지를 발행 (Publish API 호출)
  2. 메시지는 해당 모든 토픽 구독자에게 실시간으로 푸시
    • 메시지 필터링 정책이 적용된 경우, 조건에 맞는 구독자에게만 전달됨
  3. 구독자가 메시지를 수신하고 처리함
  4. SNS 메시지 전달 확인 (Optional)
    • SNS가 메시지 전달이 성공적으로 되었는지 확인하여, 실패 시 DLQ로 메시지를 보냄

 

 

5. 사용 사례

 

S3 이벤트를 여러 SQS 큐로 전달

 

SNS → Kinesis Data Firehose → S3 (실시간 로그 분석, 대규모 데이터 저장 등의 아키텍처 설계 가능)

 

 

 

 


 

3) Kinesis

: 실시간으로 스트리밍 데이터를 빠르게 수집/처리/분석할 수 있도록 지원하는 완전 관리형 서비스이다.

 

 

1. Kinesis Data Streams

  • 실시간으로 데이터 스트림을 수집하는 서비스
  • 샤드(Shard) 기반 아키텍처
    • 데이터 스트림은 샤드 단위로 나뉘어짐
    • 각 샤드의 초당 1MB 쓰기, 2MB 읽기 처리 가능
    • 처리량은 샤드 수에 비례하여 확장됨

    • 프로비저닝 모드
      • 사용자가 직접 샤드 개수를 지정하여 용량 설정
      • 지정한 샤드 개수에 따른 시간 단위의 비용
    • 온디멘드 모드
      • 마지막 30일간의 최대 처리량을 기준으로 자동 스케일링
      • 입출력 된 데이터(GB) 기준 비용

  • 데이터 레코드
    • 스트림에 저장되는 데이터
    • 각 레코드는 Partition Key와 Sequence Number로 식별된다.(Partition Key는 저장될 샤드를 결정한다.)

  • 데이터를 스트림에 넣는 Producer
    • 직접 개발: AWS SDK / Kinesis Agent / KPL(Kinesis Producer Library)

  • 데이터를 읽어 처리하는 Consumer
    • 직접 개발: AWS SDK / KCL(Kinesis Client Library)
    • 관리형 서비스: Lambda / Kinesis Data Firehose / Kinesis Data Analytics

  • 최소 1일 ~ 최대 365일까지 데이터가 보관된다.
  • 한 번 삽입된 데이터는 삭제할 수 없다.

 

 

2. Kinesis Data Firehose

  • 스트리밍 데이터를 지정된 AWS 데이터 저장소나 분석 서비스로 자동 전송하는 서비스 (S3, Redshift, OpenSearch)
  • Lambda를 통한 데이터의 변환(포맷, 필터링) 지원
  • 데이터를 일정 크기나 시간 간격으로 묶어 배치 단위로 저장소에 전송함 → Near Real-Time Service
더보기

Kinesis Data Streams vs Kinesis Data Firehose

 

  Kinesis Data Streams Kinesis Data Firehose
목적 대규모 데이터 스트리밍 수집 스트리밍 데이터를 AWS 및 외부 저장소로 전송
직접 개발 Custom Producer/Consumer 코드 작성 필요 완전 관리형(Fully Managed), 개발 없이 사용 가능
실시간 처리 실시간(Real-time, 약 200ms 지연) 거의 실시간(Near Real-time), 버퍼링 적용됨
확장성 샤드(Shard) 기반 수동 확장 또는 API로 확장 가능 자동 확장(Auto Scaling)
데이터 저장 기간 최소 1일 ~ 최대 365일 데이터 저장 없음
(즉시 대상 시스템으로 전송)
데이터 재처리 지원 (데이터 저장 후 다시 읽기 가능) 미지원 (한 번 전송 후 다시 불러올 수 없음)

 

 

 

3. Kinesis Data Analytics

  • 스트리밍 데이터를 실시간으로 분석하는 서비스
    SQL 쿼리 또는 Apache Flink를 사용해 실시간 데이터 분석
  • 실시간 분석 결과를 다른 Kinesis Stream, S3, Lambda 등으로 전송

 

4. Kinesis Video Streams

  • 비디오와 오디오 스트림을 실시간으로 수집, 처리, 저장하기 위한 서비스 (CCTV, 드론, IoT 카메라)

 


 

4) Amazon MQ

: 오픈소스인 Apache ActiveMQ와 RabbitMQ 를 기반으로 한, 메시지 브로커 서비스이다.

(메시지 브로커는 분산 시스템이나 MSA 환경에서 서비스들 간의 통신을 중개하는 역할을 하면서, 안정적(부하 분산)이고 비동기적인 처리를 가능하게 한다.)

 

 

특징

  • 기존에 ActiveMQ, RabbitMQ와 같은 오픈소스 메시지 브로커를 사용하던 온프레미스 애플리케이션을, 코드 변경을 최소화하여 AWS로 마이그레이션 할 수 있도록 한다.
    • 표준 메시지 프로토콜(AMQP, MQTT, STOMP 등)을 그대로 사용 가능
  • 완전한 서버리스 구조가 아니기 때문에, SQS, SNS와 같은 확장성은 상대적으로 낮다.

 

───

 

5) ECS

: ECS(Elastic Container Service), AWS에서 도커 컨테이너를 실행하고 관리할 수 있도록 하는 완전관리형 서비스이다.

 

 

1. ECS 실행 환경

 

EC2

  • 사용자가 도커 컨테이너가 실행되는 EC2 인스턴스를 직접 구성하고 관리해야 함.
    • 인스턴스 모니터링, Auto Scaling 과 같은 부분을 직접 관리
    • Spot Instance 사용하여 비용을 절약할 수 있음
  • ECS Agent가 EC2 인스턴스에서 실행되어, 해당 인스턴스를 ECS 클러스터에 등록함.
  • Task 정의에 따라 ECS 서비스가 EC2에 Task 컨테이너를 실행시킴.

 

 

Fargate

  • 사용자가 EC2 인스턴스를 전혀 관리하지 않음 (Serverless)
    • OS 수준의 접근은 안 됨
    • CI/CD, 무중단 배포 쉽게 적용 가능
  • Task 만 정의하면, AWS가 자동으로 Task 컨테이너를 실행할 인프라를 할당하고 관리함
    • Task 단위로 CPU / RAM 개별 지정해서 최적화 가능

 

 

2. ECS IAM Roles

 

EC2 Instance Profile

  • EC2 실행 방식 전용으로, 해당 EC2 인스턴스에서 실행되는 ECS Agent가 ECS나 다른 AWS 리소스와 통신할 수 있도록 IAM 권한을 부여함
    • ECR에서 Docker 이미지 pull
    • CloudWatch에 로그 전송

 

ECS Task Role

  • Task A, Task B가 각자 다른 AWS 리소스를 사용하는 경우, 각자의 Task Role로 IAM 권한을 분리하여 설정할 수 있음

 

 

3. ECS 로드 밸런서 통합

  • ECS + ALB 연동 시, 컨테이너 상태에 따라 자동으로 Target 등록 / 해제함 (ex. unhealthy 컨테이너)

 

4. ECS 데이터 볼륨 (EFS)

  • Task 컨테이너에서 EFS 마운트가 가능함

 

5. ECS (Task) Auto Scaling

  • 서버에서 실행 중인 Task 수를 자동으로 스케일링 해줌
    • ECS 평균 CPU / RAM 사용률
    • ALB Target 당 요청 수
    • CloudWatch Metric / Alarm
  • EC2 인스턴스로 실행했을 시, EC2 인스턴스 수를 스케일링 해주지는 않는다.
    • Task 수가 스케일링 되면, 이를 수용하는 EC2 인스턴스의 확장도 필요해진다.
    • EC2 인스터는 ASG로 묶어서 관리를 해야 함.
    • ECS Capacity Provider를 통해 ASG와 ECS Task Auto Scaling을 연동하여, EC2 인스턴스를 자동으로 확장시킬 수 있음.
  • Fargate 실행 시의 서버리스이기 때문에 AWS에서 자동으로 스케일링 해준다.

 


 

6) ECR

: ECR(Elastic Container Registry), AWS에서 제공하는 도커 이미지 저장소 서비스이다.

 

 

특징

  • 도커 이미지는 S3 기반으로 안전하게 저장된다.
  • private 저장소뿐만 아니라, public 제공하여 도커 이미지 공유가 가능하다.
  • 접근 권한은 AWS IAM(Identity and Access Management)을 통해서 관리한다

 


 

7) EKS

: EKS(Elastic Kubernetes Service), AWS에서 쿠버네티스를 실행하기 위한 서비스이다.

 

 

쿠버네티스

  • 애플리케이션 컨테이너를 자동으로 배포, 확장, 관리하는 오픈소스 오케스트레이션(조율) 서비스이다.
  • 클라우드 독립적이기 때문에, 어디서든 동일한 환경으로 운영할 수 있다.

 

특징

  • 이미 구축된 쿠버네티스 환경을 AWS EKS로 그대로 마이그레이션 해 사용할 수 있다.
  • 쿠버네티스의 제어 플레인(마스터 노드)을 AWS가 대신 관리하여, 사용자는 워커 노드를 손쉽게 생성하고 운영할 수 있다.

 

실행 방식

  • Managed Node Groups
    • AWS가 EC2 노드를 자동으로 생성하고 관리해준다.

  • Self Managed Nodes
    • 사용자가 EC2 인스턴스를 직접 생성하고 클러스터에 등록해야 한다.
    • ASG 또한 직접 구성해야 되며, EC2 AMI도 선택이 가능하다. (EKS Optimized AMI 추천)

  • Fargate
    • 사용자가 워커 노드를 직접 생성하거나 관리할 필요 없이, 서버리스로 컨테이너 단위로 실행된다.

 

───

 

8) App Runner

: 서버와 인프라 구성 없이, 웹 애플리케이션을 쉽게 배포하고 실행할 수 있게 하는 완전 관리형 서비스

 

 

특징

  • GitHub, ECR 에서 소스코드 또는 컨테이너 이미지를 가져와 자동으로 빌드 및 배포가 가능하다.
  • 로드 밸런서, HTTPS 암호화, ASG, VPC 보안 등의 기능이 기본으로 제공된다.

 


 

9) App2Container (A2C)

: 온프레미스에서 실행 중인 Java 또는 .NET 애플리케이션을 컨테이너로 변환해 AWS로 마이그레이션하여 배포할 수 있게 하는 서비스

 

 

특징

  • 실행 중인 Java 또는 .NET 애플리케이션을 분석하여 Dockerfile을 생성한다.
  • 컴퓨팅 환경, 네트워크 구성을 분석하여 실행 시 자동으로 설정한다.

 


 

10) Lambda

: 이벤트 요청이 발생했을 때, 함수 단위의 코드를 서버리스로 실행시켜주는 서비스

(이벤트 요청 예시. S3 파일 업로드, DynamoDB 데이터 변경, CloudWatch Events EventBridge 스케줄링, API Gateway 요청)

 

 

특징

  • 기본적으로 Lambda 함수는, 사용자가 만든 VPC 밖에서 실행된다.
    • 즉, 사용자 VPC 내부의 리소스에 직접 접근이 불가능하다.
    • 따라서 VPC 내부에서 실행되도록 하기 위해서는, VPC 설정(VPC ID, 서브넷, 보안 그룹)을 지정해주어야 한다.

 

실행 환경 (Lambda 함수 인스턴스)

  • RAM: 128MB ~ 10GB
  • 최대 실행 시간(Timeout): 15분
  • 환경변수: 4KB
  • 임시 디스크 용량(/tmp): 512MB ~ 10GB
    • Lambda 함수가 실행될 때 사용되는 임시 파일을 저장할 때 사용된다.

 

배포 환경

  • 배포 패키지(.zip, .jar) 크기: 50MB
  • 압축 해제 후 코드 + 의존성 크기: 250MB
  • Lambda 함수 배포는 AWS 내에서 코드를 작성할 수도 있지만, 직접 zip이나 jar 파일로 패키징해서 업로드 할 수도 있다.

 

 

SnapStart (Java 11)

  • Lambda 함수가 생성될 때, Java 함수를 미리 초기화시킨 스냅샷을 생성시키고 이를 저장한다.
  • 그리고 Java 함수가 실행될 때, 해당 스냅샷을 재사용하여 초기 실행시간을 크게 줄여 함수가 빠르게 실행될 수 있게 한다.

 

Lambda with RDS Proxy

  • Lambda 함수가 DB에 직접 연결을 하게 되면, 이벤트 요청이 늘어나게 되면 DB 커넥션 풀이 빠르게 고갈될 수 있다.
  • 이를 방지하기 위해, RDS Proxy를 두어 Lambda와 DB 간의 연결을 안정적으로 관리하도록 돕는다.

 

Invoking Lambda from RDS & Aurora

  • DB 내에서 내부 트리거나 프로시저를 통해, Lambda를 호출할 수 있도록 지원한다.
  • DB 인스턴스에서 Lambda 호출 권한과, Lambda로 아웃바운드 트래픽이 나갈 수 있도록 설정해야 한다.

 

RDS Event Notifications

  • RDS에서 발생한 이벤트에 대한 알림 기능을 제공한다.
    • ex. DB 인스턴스 생성, 삭제, 스냅샷 완료 등
    • SNS로 알림을 전송하거나, EventBridge와 연동하여 추가적인 이벤트 기반의 워크플로우 구현이 가능하다.
  • DB 데이터 변경에 대한 정보는 제공하지 않는다.

 


 

11) DynamoDB

: AWS에서 제공하는 완전 관리형 NoSQL 데이터베이스 서비스이다.

 

 

특징

  • 분산 데이터베이스로, 초당 수백만 요청을 처리 가능한 높은 성능을 가지고 있다.
    • 읽기 / 쓰기 처리량을 독립적으로 할당해 조정이 가능하다. (RCU / WCU, Capacity Units)
  • 테이블 구조는 Table, Item, Attribute으로 구성되어 있다.
    • Table이 최상위 개념으로, Table 안에 Item(=Row)들이 있고, Item은 Attribute(Key-Value)로 구성된다.
    • Primary Key는 단일 Partition Key와 Partition Key와 Sort Key를 조합한 복합키 형태로 관리한다.
    • 각 테이블은 반드시 Partition Key를 가져야 하고, 선택적으로 Sort Key를 지정할 수 있다.
    • 테이블의 스키마, 속성(Attribute)은 유연하게 저장할 수 있다.

 

DynamoDB Accelerator (DAX)

  • DynamoDB용 완전관리형 인메모리 캐시
  • 일반적인 DynamoDB도 ms 단위로 응답하지만, DAX 적용 시 μs 단위로 응답한다.

 

백업

  • Point in Time Recovery: 최대 35일간 모든 변경 이력을 보관하여, 새 테이블로 임의 시점 복구가 가능하다.
  • On-Demand 백업: 사용자가 수동으로 진행하는 백업으로, 삭제하기 전까지 유지된다. 또한 백업이 진행되는 동안 테이블 성능에 영향을 주지 않는다.
  • AWS Backup 서비스를 활용해 다른 리전으로의 백업 복사도 가능하다.

 


 

12) API Gateway

: API를 손쉽게 생성할 수 있도록 하는 완전관리형 서비스

REST API, HTTP

 

 

특징

  • API Gateway + Lambda 조합으로, 서버 구축 없이 API를 쉽게 배포할 수 있다.
    • Lambda 이외에도 다른 AWS 서비스 API를 호출이 가능하다.
  • REST API, HTTP API, WebSocket API Gateway 세 가지 유형의 API 배포가 가능하다.
    • HTTP API는 REST API Gateway의 일부 기능들을 제외하는 대신, 더 빠르게 동작하며 저렴한 비용으로 서비스를 제공한다.
      (제외 기능: 클라이언트별 API Key 발급, 요청 및 응답 데이터 변환, 요청 검증, 응답 캐싱 등)
  • AWS IAM, JWT, OAuth, API Key 등 여러 인증 및 인가 방식을 지원한다.

 

 

API Gateway Endpoint 타입

  • Edge-optimized
    • 전 세계에 사용자가 있는 글로벌 서비스에 적합하다.
    • CloudFront Edge 로케이션에서 API Endpoint가 배포되어 접근하는 방법이다.
  • Regional
    • 특정 리전 내에 사용자가 다수 있는, 로컬 서비스에 적합하다.
  • Private
    • VPC 내부에서만 접근이 가능한 엔드포인트이다.
    • 인터넷을 통해서 직접 엑세스가 불가능하고, VPC Endpoint를 통해서만 접근이 가능하다.

 


 

13) Step Functions

: AWS 서비스의 복잡한 워크플로우를 시각적으로 구성하고, 실행할 수 있게 하는 서비스

풀어서 정리를 하면, 여러 AWS의 여러 서비스(Lambda, ECS, DynamoDB 등)들의 복잡한 워커플로우를 시각적으로 구성한여, 각 작업을 순차 실행, 병렬 처리, 조건 분기, 타임아웃, 에러 처리와 같이 어떻게 실행할 것인지 워크플로우를 구성할 수 있도록 하는 오케스트레이션 서비스이다.

 

 


 

14) Cognito

: 사용자가 웹, 모바일 애플리케이션에서 안전하게 로그인할 수 있도록, 인증/인가 기능을 제공하는 완전 관리형 서비스이다.

 

 

User Pools

  • 사용자 계정 정보를 저장하고 관리하는, 사용자 디렉토리 서비스이다.
  • 소셜 로그인(Google, Facebook, Apple, etc.), SAML, MFA 연동을 지원한다.

Identity Pools (Federated Identity Management)

  • User Pools, 소셜 로그인, SAML을 통해 로그인한 사용자에게 AWS 리소스에 접근할 수 있는 임시 IAM Role 권한을 발급한다.
    • ex. S3 업로드, DynamoDB 접근
      (애플리케이션에서 등록된 사용자들에게, S3 버킷에 있는 자신의 폴더에서 이미지를 업로드 또는 다운로드할 수 있도록 구현 가능)

저작자표시 (새창열림)

'DevOps > AWS' 카테고리의 다른 글

AWS SAA 6주차  (0) 2025.03.29
AWS SAA 5주차  (0) 2025.03.24
AWS SAA 4주차 (1)  (0) 2025.03.14
AWS SAA 3주차  (0) 2025.03.08
AWS SAA 2주차  (0) 2025.03.01
'DevOps/AWS' 카테고리의 다른 글
  • AWS SAA 6주차
  • AWS SAA 5주차
  • AWS SAA 4주차 (1)
  • AWS SAA 3주차
wch_t
wch_t
  • wch_t
    끄적끄적(TIL)
    wch_t
  • 글쓰기 관리
  • 전체
    오늘
    어제
    • 분류 전체보기 (171)
      • Architecture (0)
      • Algorithm (67)
        • Math (5)
        • Simulation (1)
        • Data Structure (4)
        • DP (7)
        • Brute Fource (10)
        • Binary Search (6)
        • Greedy (2)
        • Graph (11)
        • Mst (1)
        • Shortest path (10)
        • Two Pointer (1)
        • Tsp (3)
        • Union Find (2)
        • Mitm (1)
      • CS (2)
        • 데이터베이스 (5)
        • 네트워크 (5)
      • DB (6)
      • DevOps (17)
        • AWS (9)
        • Docker (1)
        • CI-CD (5)
      • Error (1)
      • Project (0)
        • kotrip (0)
      • Spring (59)
        • 끄적끄적 (5)
        • 기본 (9)
        • MVC 1 (7)
        • MVC 2 (11)
        • ORM (8)
        • JPA 1 (7)
        • JPA 2 (5)
        • Spring Data Jpa (7)
      • Test (2)
      • TIL (6)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    docker
    Merge
    TempTable
    apache poi
    Sxssf
    백준 17299 파이썬
    Jenkins
    spring-cloud-starter-aws-secrets-manager-config
    view algorithm
    애플
    response_mode
    scope
    form_post
    spring-cloud-starter-bootstrap
    aws secrets manager
    docker: not found
    백준 3015 파이썬
    백준 17289 파이썬
  • 최근 댓글

  • hELLO· Designed By정상우.v4.10.3
wch_t
AWS SAA 4주차 (2)
상단으로

티스토리툴바