필터:#AWS×

AWS Summit SEOUL 2026 후기

AWS Summit SEOUL 2026을 다녀왔다. 요즘 관심을 가지고 있던 주제가 마이그레이션, 운영, 그리고 AWS의 생성형 AI 서비스인 Bedrock이었던 만큼, 이번 Summit에서는 해당 내용을 다루는 세션들을 위주로 듣고 오자는 목표를 가지고 참여했다. 이번에 들었던 세션은 다음과 같다. Amazon Bedrock Knowledge Base와 S3 Vectors로 스트리밍 AI 챗봇 구축하기 VMware 종속을 넘어 자율로, 삼성SDS와 함께하는 AX 전략 2천만 디바이스 요청을 처리하는 API Gateway 마이그레이션 생존기 (LG U+) Amazon Bedrock Knowledge Base와 S3 Vectors로 스트리밍 AI 챗봇 구축하기.. 가장 인상 깊었던 세션은 첫 번째 세션이었다. 현재 진행 중인 팀 프로젝트와도 방향성이 맞닿아 있었기 때문에 개인적으로 가장 많은 인사이트를 얻을 수 있었던 시간이었다. 세션에서는 Bedrock Knowledge Base와 S3 Vectors를 활용해 도서 기반 AI 챗봇을 구축한 사례를 소개했다. 단순히 “챗봇을 만들었다” 수준의 발표가 아니라, 실제 서비스 관점에서 어떤 고민과 선택이 있었는지를 상세하게 다뤘다는 점이 특히 좋았다. 발표에서는 다음과 같은 내용들을 단계별로 설명했다. 소비자 요구사항 분석 Bedrock Knowledge Base의 동작 방식 문장 단위 분할(Chunking) 벡터 변환(Embedding) 기본 청킹(Default Chunking)에서 시맨틱 청킹(Semantic Chunking)으로 개선한 과정 특히 RAG(RetrievalAugmented Generation)를 실제로 운영 환경에 적용하면서 발생했던 문제들과 그 해결 과정이 굉장히 인상 깊었다. PoC 단계에서 비용을 고려한 모델 선택 전략, 토큰 사용량 최적화, Guardrail을 통한 제약 설정, 데이터 트래킹 등 단순 기능 구현을 넘어 “서비스 운영” 관점에서 어떤 요소들을 고려해야 하는지까지 다루며 발표가 진행되었다. 무엇보다 좋았던 점은 발표자분이 직접 겪었던 트러블슈팅 경험들을 솔직하게 공유해주셨다는 부분이었다. Bedrock을 처음 접하거나 실제 프로젝트에 적용해보는 과정에서 충분히 마주칠 수 있는 문제들이 많았고, 현재 진행 중인 프로젝트에서도 충분히 참고할 수 있을 만한 좋은 레퍼런스가 될 것 같다는 생각이 들었다. VMware 종속을 넘어 자율로, 삼성SDS와 함께하는 AX 전략.. 이어서 들었던 삼성SDS 세션 역시 굉장히 흥미로웠다. 세션에서는 Nutanix와 AWS 서비스를 활용해 VMware 환경에서 어떻게 전환(Migration)을 진행했는지 실제 사례 중심으로 설명했다. 단순히 “클라우드로 옮긴다” 수준이 아니라, 왜 전환을 결정했는지, 어떤 구조로 운영했는지, 운영 과정에서 어떤 문제를 겪었는지까지 실제 현업 관점에서 다뤘다는 점이 인상적이었다. 2천만 디바이스 요청을 처리하는 API Gateway 마이그레이션 생존기 (LG U+).. 마지막으로 들었던 LG U+ 세션도 굉장히 재미있게 들었다. 대규모 트래픽 환경에서 API Gateway를 어떻게 마이그레이션했고, 실제 운영 과정에서 어떤 문제를 해결했는지를 중심으로 발표가 진행되었다. 특히 기억에 남았던 부분은 다양한 모델 테스트를 통해 최적의 RAG 패턴을 구축해 나가는 과정이었다. 단순히 성능만 보는 것이 아니라 비용 효율성과 운영 안정성까지 고려하며 최적의 구조를 찾아가는 과정이 인상 깊었다. 또한 “최저 비용으로 운영 혁신을 달성한다”는 관점에서 접근한 내용들이 실제 서비스 운영을 고민하는 입장에서 굉장히 현실적으로 다가왔다. 이번 AWS Summit SEOUL 2026은 단순히 새로운 서비스를 소개하는 행사가 아니라, 실제 기업들이 어떤 방식으로 AWS 서비스를 운영 환경에 적용하고 있는지 생생하게 들을 수 있었던 자리였다. 특히 최근 관심을 가지고 공부하고 있던 분야인: 마이그레이션 운영 자동화 Bedrock RAG 생성형 AI 서비스 아키텍처 등과 관련된 실제 사례들을 직접 들을 수 있어서 개인적으로 굉장히 의미 있는 시간이었다. 기술 자체도 중요하지만, 결국 실제 서비스에서는 비용, 운영 안정성, 장애 대응, 트래픽, 데이터 관리까지 모두 함께 고려해야 한다는 점을 다시 한번 느낄 수 있었던 경험이었다. 현재 진행 중인 프로젝트에서도 이번 Summit에서 들었던 내용들을 많이 참고하게 될 것 같다.

May 20, 2026컨퍼런스
AWS Summit SEOUL 2026 후기

SAA 공부하며 끄적이는 개념들,,

S3 Presigned URL 업로드(대규모 사용자 파일 업로드 적합) 웹 서버/EC2가 파일을 직접 받지 않게 하고 애플리케이션은 업로드 권한이 있는 Presigned URL만 발급 Storage Gateway File Gateway 온프레미스에서 S3를 로컬 파일 서버처럼 사용하게 해주는 서비스 S3 Glacier Deep Archive 이 스토리지 클래스는 규정 준수 요구 사항을 충족하기 위해 데이터세트를 수년 동안 보존하도록 설계되었으며, 백업이나 재해 복구 또는 검색하는데 최대 72시간까지 기다려도 되는 자주 액세스하지 않는 데이터에도 사용할 수 있다. S3 Glacier Instant Retrieve 의료 의미지, 뉴스 미디어, 유전체학 등 즉각적 접근이 필요한 아카이브 데이터에 적합하다. S3 Glacier Flexible Retrieve 즉각적 접근은 필요없지만 백업, 재해복구 등 대용량 데이터 세트를 몇분 12시간 내 검색 무료 제공 S3 Intelligent Tiering 액세스 빈도, 불규칙한 사용 패턴 모를 때 사용 가능, 다양한 액세스 패턴에 적합 S3 Standard 자주 접근하는 범용 스토리지 S3 StandardInfrequent Access(S3 StandardIA) 가끔 Access 하지만 가끔할 때 즉각적 접근 필요 시 적합 S3 One ZoneInfrequent Access 하나의 지역에만 사용 가능한 S3 클래스 단일 AWS 가용 영역에 데이터를 저장하기 때문에 스토리지 클래스에 저장된 데이터는 가용성 영역이 파괴되는 경우 손실 AWS Transfer Family SFTP, FTPS, FTP 및 AS2 프로토콜을 사용하여 Amazon S3, Amazon EFS로 파일을 전송할 수 있게 하는 서비스 AWS FSx 클라우드에서 다양한 파일 시스템을 제공하는 완전 관리형 서비스 사용자는 고성능 파일 시스템을 쉽게 설정, 관리 및 운영할 수 있으며 윈도우 파일서버, Lustre, NetApp ONTAP, OpenZFS와 같은 다양한 파일 시스템 옵션을 선택할 수 있다. 온프레미스 환경과 클라우드 환경을 연결하여 하이브리드 클라우드 스토리지 솔루션 AWS FSx for NetApp OnTAP NetApp의 인기있는 OnTAP 파일 시스템에 구축된 매우 안정적이고 확장 가능하며 성능이 뛰어나고 기능이 풍부한 파일 스토리지를 제공하는 완전관리형 서비스 데이터 센터에 클라우드의 간소성과 유연성을 제공하고 데이터 센터의 모든 엔터프라이즈 기능을 퍼블릭 클라우드에 제공 AWS EC2 배치 그룹 종류 클러스터 배치 그룹 단일 가용 영역 내에 있는 인스턴스의 논리적 그룹(인스턴스는 단일 랙에 격리되지 않음) 파티션 배치 그룹 애플리케이션에 대한 상관 관계가 있는 하드웨어 장애 가능성을 줄이는 데 도움 파티션 배치 그룹을 사용하는 경우 Amazon EC2는 각 그룹을 파티션이라고 하는 논리 세그먼트로 나눈다. 각 랙은 자체 네트워크 및 전원이 있다. 배치 그룹 내 두 파티션이 동일한 랙을 공유하지 않으므로 애플리케이션 내 하드웨어 장애의 영향을 격리 분산형 배치 그룹 각각 고유한 하드웨어에 배치된 인스턴스 그룹 인스턴스가 동일한 장비를 공유할 때 장애가 동시에 발생할 수 있는 위험이 줄어듦 Spot 인스턴스 AWS의 남는 EC2 자원을 매우 싸게 빌려주는 방식(최대 90% 할인) 대신 AWS가 필요하면 갑자기 회수할 수 있음(보통 2분 전 알림 제공) Batch Job 작업에 적합 실패하면 다른 인스턴스가 다시 처리(중단 허용 가능) EC2 Spot Fleet 여러 Spot Intance 요청을 관리하고 지정된 목표 용량을 충족시키기 위해 여러 인스턴스 유형과 가용 영역을 활용하여 비용을 최적화하는 서비스 스팟 인스턴스 풀에서 사용 가능한 인스턴스를 검색하여 목표 용량을 자동으로 채우고 필요에 따라 인스턴스 유형과 가용 영역을 변경하여 비용을 절감하고 애플리케이션의 가용성을 높일 수 있음 DR Options Backup & Restore ($) 느림(시간 단위, Hours) 단순 데이터 백업 Pilot Light ($$) 중간(십분 단위, 약 10분 90분), DB만 동기화 Warm Standby($$$) 빠름(분 단위, 약 5분 15분), DB 동기화 + APP은 낮은 스펙으로 대기 MultiSite($$$$) 아주 빠름(거의 실시간), DB 동기화 + 같은 스펙의 APP 구성 Network AWS Global Accelerator 트래픽 관리를 간소화하고 성능을 최대 60% 개선하는 네트워킹 서비스 AWS Shield와 통합되어 DDoS 공격으로부터 애플리케이션을 보호, 애플리케이션 상태, 사용자 위치 및 고객이 구성하는 정책의 변경에 즉각적으로 대응하여 항상 성능에 기반한 최적의 엔드포인트로 사용자 트래픽을 라우팅 고정/정적 IP 주소 또는 빠른 지역 장애 조치에 필요한 HTTP 사용 사례에 적합 전 세계 사용자가 AWS 애플리케이션에 더 빠르고 안정적으로 접속하도록 AWS 글로벌 네트워크로 우회시켜주는 서비스 ALB, NLB, EC2, Elastic IP 앞에는 붙이나 S3에 직접 접근은 하지 않는다. 항목 CloudFront Global Accelerator 역할 CDN 네트워크 가속 캐싱 O X 정적 콘텐츠 강함 약함 TCP/UDP 최적화 일부 매우 강함 게임/실시간 앱 보통 강함 CloudFront 파일을 가까운 곳에 캐시 Global Accelerator 네트워크 경로 자체를 최적화 VPC Endpoint Endpoint 유형 중 하나 VPC Endpoint를 사용하면 VPC 내부 또는 외부에 있는 AWS 서비스들과 통신할 때 인터넷 통신이 되지 않더라도 Private한 통신 환경을 통해 서비스에 접근 NLB 데이터를 전송하는 지연 시간을 최소화하고 다른 AWS 영역으로 신속하게 페일오버해야 하는 요구 사항을 충족 TCP/UDP 트래픽을 처리하며 네트워크 계층에서의 로드 밸런싱 ALB 주로 HTTP/HTTPS 트래픽을 처리하는 데 사용되며 애플리케이션 계층에서의 로드 밸런싱을 제공 오토 스케일링 그룹을 함께 사용하여 애플리케이션의 트래픽 변화에 따라 자동으로 서버 인스턴스 수를 조정 AWS VPC Lattice 다양한 AWS 서비스와 리소스 간의 연결, 보안, 모니터링을 중앙 집중식으로 관리할 수 있도록 지원하는 완전 관리형 애플리케이션 네트워킹 서비스 VPC Lattice를 사용하면 복잡한 네트워크 구성 없이도 서비스 간 통신을 간소화하고 보안 정책을 일관되게 적용하며 트래픽 흐름을 효율적으로 관리 AWS Elastic Fabric Adapter(EFA) Amzon EC2 인스턴스에 연결하여 고성능 컴퓨팅(HPC) 및 기계 학습(ML) 워크로드를 가속화하는 고급 네트워크 인터페이스 EFA는 노드 간 통신을 향상시켜 클라우드에서 대규모 애플리케이션을 실행할 수 있도록 지원하며, 특히 HPC 및 ML 작업에서 성능 향상을 제공한다 AWS Transit Gateway 여러 VPC와 온프레미스를 중앙 허브로 연결하는 서비스 VPC Peering 단점 해결 암호화 제공x AWS PrivateLink PrivateLink는 AWS 내의 VPC와 서비스를 연결하는 데 사용되지만 온프레미스 데이터 센터를 AWS에 연결하도록 설계되지 않았다. DB & Data AWS RDS 데이터 베이스 인프라 및 업데이트들을 AWS 측에서 관리해주고 데이터베이스의 설치, 운영 그리고 관리 등의 서비스들을 지원하는 AWS 관계형 데이터베이스 RDS Proxy 데이터베이스의 연결 관리를 위한 메모리 및 CPU 오버헤드를 줄이며 성능 개선, 예기치 않은 트래픽 급증 처리 Amazon RDS 유휴 암호화 데이터베이스 인스턴스, 자동 백업, 읽기 전용 복제본, 스냅샷 등 저장된 데이터를 보호 AWS는 기본 스토리지와 백업 데이터를 AES256 암호화 알고리즘을 사용하여 암호화 Amazon RDS Custom 기본 OS 및 DB 환경에 액세스할 필요가 있는 레거시, 사용자 지정, 패키지 애플리케이션을 위한 관리형 데이터베이스 서비스 AWS SCT(Schema Conversion Tool) 소스 데이터베이스의 데이터베이스 스키마를 대상 Amazon RDS 인스턴스와 호환되는 형식으로 자동으로 변환하는 프로젝트 기반 사용자 인터페이스를 제공 Amazon Aurora MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진 (읽기 전용)자동으로 3개의 AZ에 6개의 복제본 생성( DynamoDB 서버리스 기반 KeyValue NoSQL 데이터베이스 용량에 맞게 테이블을 자동으로 조정하므로 별로 관리하지 않아도 성능 유지, 주문형 백업 기능 제공(보관을 위해서 특정 시점 백업 및 복구, 단 35일로 제한) 온디맨드 용량 모드(주문형 모드) 이전에 관찰된 트래픽 수준까지 상승/하락 시 워크로드 즉시 수용 가능. 읽기/쓰기 용량 모드 있음 트래픽에 따라 자동 확장하고 앱에서 읽기/쓰기 요청에 대해서만 비용 지불, 용량 계획 없이 요청 당 지불가격 제공 변동성이 큰 트래픽 프로비저닝 모드 애플리케이션에서 필요한 초당 읽기/쓰기 횟수 미리 지정 AutoScaling 사용하여 변경에 따라 용량 자동 조정 가능. 예측 가능한 트래픽 GSI(Global Secondary Index) 기본 테이블과 다른 파티션 키와 정렬 키를 사용하여 데이터를 조회할 수 있는 인덱스 GSI를 사용하면 기본 테이블의 파티션 키와 정렬된 키와는 다른 기준으로 데이터를 검색할 수 있어 다양한 쿼리 패턴을 지원 빠르지만 자유로운 검색에 약한 DynamoDB의 보완 DynamoDB와 DAX(DynamoDB Accelerator)가 결합되면 한 단계 업그레이드하여 읽기 중심의 워크로드에서 초당 수백만 개의 요청에도 마이크로초의 응답 시간을 지원 + 인메모리 캐시 DynamoDB TTL(Time to Live) 항목별 타임스탬프를 정의하여 더 이상 필요하지 않은 시기를 결졍 지정된 타임스탬프의 날짜 및 시간 직후 DynamoDB는 쓰기 처리량을 소모하지 않고 테이블에서 항목을 삭제 DynamoDB Global Tables MultiRegion, MultiActive 구조 모든 리전에서 읽기, 쓰기 가능 여러 리전에서 데이터를 실시간으로 복제하며 사용자 요청에 빠르게 대응할 수 있음 낮은 지연 시간 보장 AWS PITR(PointinTime Recovery) 특정시점복구 AWS 서비스에서 제공하는 백업 및 복구 기능으로 데이터베이스를 특정 시점으로 복원 Amazon Athena 표준 SQL을 사용해 S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스 Amazon Athena Federated Query 데이터 분석가가 서로 다른 데이터 소스에 저장된 데이터를 단일 SQL 쿼리를 통해 분석할 수 있게 해주는 기능 S3, RDS, DynamoDB 등 다양한 데이터 소스를 마치 하나의 데이터 웨어하우스처럼 쿼리할 수 있도록 함 AWS Kinesis 실시간 스트리밍 데이터를 수집, 분석, 처리하는 서비스 Kinesis Data Streams 수집 & 전송 대규모의 애플리케이션의 로그, IoT 디바이스의 데이터 등 스트리밍 데이터를 실시간으로 수집하는 서비스 수집한 데이터는 다른 AWS 서비스 또는 애플리케이션에서 사용되어 분석처리 기본 보존 시간은 24시간이며 최대 8760시간(365일)까지 연장 Kinesis Data Firehose 실시간 스트리밍 데이터를 안정적으로 받은 후 필요한 경우 변환하여 다른 AWS의 서비스로 전달하는 서비스 Lambda 함수를 호출하여 데이터 변환 후 전송 가능 Kinesis Data Analytics SQL/Apache Flink로 데이터 스트림 분석 Kinesis Video Streams 비디오 스트림 수집, 저장 및 처리 Amazon MSK(Managed Streams for Apache Kafka) Apache Kafka를 사용하여 스트리밍 데이터를 처리하는 애플리케이션을 빌드하고 실행할 수 있는 완전관리형 서비스 Amazon Redshift 클라우드에서 완전히 관리되는 페타바이트급 데이터 웨어하우스 서비스, 지정시간동안 앱 비활성화일 때 분석 서버, 클라이언트 측 암호화 지원 AWS Glue 사용자가 여러 소스의 데이터를 쉽게 검색, 준비, 이동, 통합할 수 있도록 하는 서버리스 데이터 통합 서비스(JDBC 커넥터를 통해 특정 데이터베이스 연결을 지원) Athena에서 쿼리 가능한 Parquet 파일을 쓸 수 있음 AWS Glue DataBrew 코딩 없이 데이터를 정리하고 정규화하여 분석 및 기계 학습(ML)에 적합하게 준비할 수 있도록 도와주는 시각적 데이터 준비 도구 데이터 분석 및 ML 전에 데이터를 쉽게 처리하고 정제할 수 있도록 지원 DataBrew를 사용하면 데이터 준비 시간을 최대 80%까지 단축 AWS Lake Formation S3의 기본 데이터가 있는 데이터베이스, 테이블 및 열과 같은 데이터 카탈로그 리소스에 대한 액세스 권한을 부여하거나 취소 가능 서비스 Amazon AppFlow Salesforce, SAP, Zendesk, Slack 및 ServiceNow 같은 SaaS와 S3/Amazon Redshift 사이 데이터를 안전하게 전송할 수 있는 완전 관리형 통합 서비스 Amazon ElastiCache 더 느린 디스크 기반 데이터베이스에 전적으로 의존하기 보다는 신속한 관리형 인 메모리 시스템에서 정보를 검색할 수 있는 기능을 지원함으로써 웹 애플리케이션의 성능을 향상 + 분산세션 데이터 관리 인터넷 규모의 실시간 애플리케이션을 지원 도입을 위해선 아키텍쳐 변경이 필요 Amazon Neptune AWS에서 제공하는 완전 관리형 그래프 데이터베이스 서비스 고도로 연결된 데이터셋을 효율적으로 저장하고 쿼리할 수 있도록 설계되었으며 주로 소셜 네트워킹, 추천 엔진, 지식 그래프, 생명과학 연구 등의 분야에서 활용 AWS Neptune Streams Amazon Neptune 그래프 데이터베이스의 변경 사항을 실시간으로 캡처하고 처리할 수 있는 기능. 이를 통해 데이터베이스의 변경 사항을 다른 시스템으로 복제하거나 변경 내용을 기반으로 새로운 로직을 트리거하는 등 다양한 작업을 수행 AWS Quantum Ledger Database(Amazon QLDB) 투명하고 변경 불가능하며 암호화 방식으로 검증 가능한 트랜잭션 로그를 제공하는 완전 관리형 원장 데이터베이스 AWS Lustre 고성능 병렬 파일 시스템인 Lustre를 기반으로 하는 Amazon FSx for Lustre 서비스 대규모 컴퓨팅 워크로드에서 높은 처리량과 낮은 지연 시간을 제공하며 AWS 클라우드에서 사용하기 쉽도록 완전 관리형으로 제공. 특히 머신 러닝, 고성능 컴퓨팅(HPC), 미디어 처리 등 데이터 집약적인 작업에 적합 Security AWS Secrets Manager 자격증명 저장 및 관리 서비스 AWS Console이나 AWS CLI(Bastion 호스트처럼)를 통해 EC2 인스턴스에 안전하게 로그인할 수 있는 기능 DB 비밀번호, API Key, 인증 정보 같은 Secret 관리 전용 서비스 AWS Secrets Manager Auto Rotate(자동회전) 보안 암호의 만료 시점을 자동으로 관리하고 주기적으로 암호를 교체하여 보안을 강화하는 기능 Amazon Cognito 웹 및 모바일 앱을 위한 자격 증명 플랫폼 OAuth 2.0 액세스 토큰 및 AWS 보안 인증을 위한 사용자 디렉터리, 인증 서버, 인증 서비스 Amazon GuardDuty 계정보호 서비스 AWS 계정 및 워크로드에서 악의적 활동 모니터링하고 상세 보안 결과 제공 위협 탐지 서비스 Amazon Inspector 취약점 스캔 서비스 Amazon Shield advance 정교한 대규모 DDoS 공격에 대한 보호 및 완화 실시간 가까운 가시성 EC2, ELB, CloudFront, Global Accelerator, Route 53 요금 보호 제공 Amazon Macle 민감한 데이터를 검색, 모니터링 및 보호하는데 도움이 되는 관리형 데이터 보안 서비스 Amazon Firewall Manager 여러 AWS 계정과 리전에서 방화벽 규칙을 중앙에서 관리할 수 있도록 하는 보안 서비스 AWS WAF용 관리형 규칙과 통합되므로 사전에 구성된 WAF 규칙을 애플리케이션에 손쉽게 배포 AWS KMS(Key Management Service) 클라우드 환경에서 데이터를 보호하기 위한 AWS의 암호화 키 관리 서비스 KMS는 암호화 키를 안전하게 생성, 저장, 관리하고 이를 사용하여 AWS 서비스와 애플리케이션에서 데이터를 암호화하거나 복호화할 수 있도록 지원 고객 관리형 키(CMK) 사용자가 생성, 소유, 관리하는 키로 키, 정책, 키 사용 권한 등을 사용자가 직접 설정 AWS 관리형 키 AWS가 관리하는 키로 사용자는 키 정책을 설정할 수 없지만 키 사용 권한을 제어 S3 버킷에 저장된 중요한 데이터를 암호화할 때 사용자는 AWS 관리형 키 대신 CMK를 사용하여 데이터에 대한 통제력을 높일 수 있다. AWS Security Token Service(STS) AWS 리소스에 접근하기 위한 임시 보안 자격 증명을 발급하는 서비스 기존 IAM 사용자나 역할에 대한 접근 권한을 일시적으로 부여하여 특정 작업이나 리소스에 대한 액세스를 제어 SAML 호환성 없이도 기존 LDAP 디렉터리 서비스를 사용하여 AWS Management Console에 사용자를 인증 Monitoring Amazon QuickSight PostgreSQL용 Amazon S3 / RDS 비롯한 다양한 데이터 소스에서 대화형 대시보드 및 보고서 생성하는 데이터 시각화 서비스 AWS CloudTrail 사용자가 활동 및 API 사용 추적하여 감사, 보안 모니터링 및 운영 문제 해결 AWS Config 리소스 구성 사항 변경 추적 규칙 생성으로 EBS 볼륨의 암호화 여부 확인 후 암호화되지 않은 볼륨에 플래그 지정 가능 Amazon Workload Discovery AWS 클라우드 워크로드를 시각화하여 아키텍처 다이어그램으로 자동 생성해주는 솔루션 AWS 환경에서 실행되는 애플리케이션 및 서비스들의 구조를 자동으로 파악하고 시각적으로 보여주는 도구 AWS 비용 및 사용 보고서 쿼리, 리소스 검색, 아키텍처 다이어그램 저장 및 내보내기 등을 수행 AWS XRay 애플리케이션이 처리하는 요청에 대한 데이터를 수집하고 해당 데이터를 보고, 필터링하고, 인사이트를 얻어 문제와 최적화 기회를 식별하는 데 사용할 수 있는 도구를 제공하는 서비스 애플리케이션의 동작에 관한 데이터를 수집/분석하는 서비스 XRay는 특히 트러블슈팅의 목적으로 이용 AWS Step Functions 실시간 진단 및 대시보드를 제공하고 Amazon CloudWatch 및 AWS CloudTrail과 통합되며 전체 상태, 실패한 단계, 입력 및 출력을 비롯한 모든 실행 관련 정보를 기록. 서버리스 서비스 시각적 워크플로우를 사용하여 분산 애플리케이션 및 마이크로 서비스의 구성 요소를 조정하여 애플리케이션을 쉽게 구축할 수 있게 해주는 완전 관리형 서비스 여러 AWS Lambda 함수를 반응형 서버리스 애플리케이션에 결합하고 EC2 인스턴스, 컨테이너 또는 온프레미스 서버에서 실행되는 데이터 및 서비스를 오케스트레이션 가능 AWS Resource Groups Tag Editor 태그를 기반으로 리소스를 관리하고 구성하도록 특별히 설계 AWS Trusted Advisor AWS 환경의 비용, 보안 및 성능을 최적화 AWS Systems Manager 클라우드 및 온프레미스 리소스의 통합 관리를 지원하며 자동화와 효율성을 통해 운영 복잡성을 줄이고 보안을 강화하는데 필수적인 도구 회사는 실행 중인 애플리케이션을 중단하지 않고 IAM 역할이나 사용자를 수동으로 생성하거나 수정하지 않고도 EC2 인스턴스를 패치 기본 호스트 구성 관리 Systems Manager가 EC2 인스턴스를 관리형 인스턴스로 자동 관리할 수 있게 해주는 AWS Systems Manager의 기능 Service Snowball Edge (마이그레이션 장비) 기존 저장소의 대역폭이 충분하지 않을 때 대용량 데이터 세트를 클라우드로 이전하는데 도움(80TB(실사용 72TB)까지 한번에 이동 가능하며 Snowball Edge는 100TB(실사용 83TB)까지 가능) aws가 고용량 저장 장비를 사용자에게 보내고 사용자는 장비에 데이터를 복사해 다시 aws에게 보낸다. aws는 장비에 저장된 데이터를 S3, EBS, Glacier 등으로 저장한다. Amazon Snowcone AWS Snow Family에 속하는 소형, 휴대용 엣지 컴퓨팅 및 데이터 전송 장치 Snowcone은 데이터 수집, 처리, 저장 및 전송을 위해 설계되었으며 특히 네트워크 연결이 제한적이거나 신뢰할 수 없는 환경에서 유용 AWS DataSync 데이터 전송 프로세스의 관리와 고성능 및 보안 데이터 전송에 필요한 인프라를 모두 자동화 endtoend 보안을 제공하여 데이터가 안전하고 온전하며 사용할 준비가 된 상태로 도착하도록 보장 암호화, 데이터 무결성 확인 및 대역폭 최적화도 처리 온프레미스 ↔ AWS 사이에서 데이터를 빠르고 자동으로 옮겨주는 데이터 전송 서비스 전송 가능 대표 대상 S3, EFS, FSx 지원 프로토콜 NFS, SMB, 객체 스토리지 Amazon SQS(Simple Queue Service) 작업 요청 솔루션을 분리하여 대기열에 따라서 인스턴스 수를 확장 및 리소스 추가제공 갑작스러운 작업이 몰려도 추후 처리가능하도록 보관기능 제공 손실위험이 있는 데이터를 잠시 보관하는 용도 Dead Letter Queue 등 다양한 옵션으로 메시지 처리가 실패했을 경우 해당 메시지를 보관했다가 다시 처리할 수 있게끔 하는 기능을 제공 Amazon SNS(Simple Notification Service) 클라우드에서 손쉽게 알림을 설정, 운영 및 전송할 수 있도록 하는 웹 서비스 Amazon SES(Simple Email Service) 기업이 자체 이메일 주소와 도메인을 사용하여 이메일을 보내고 받을 수 있도록 하는 비용 효율적이고 확장 가능한 이메일 서비스 AWS Fargate EC2 인스턴스의 서비스나 클러스터를 관리할 필요없이 컨테이너 실행을 위해 ECS에 사용가능한 기술 컨테이너를 실행하는 데 필요한 컴퓨팅 리소스를 자동으로 할당하고 관리 AWS Fargate Spot Fargate를 이용해 컨테이너를 실행할 때, AW의 유휴 용량을 활용하여 Fargate 정가보다 최대 70% 저렴한 비용으로 컨테이너를 실행할 수 있는 기능 Amazon VPC CNI(Container Network Interface) 플러그인 EKS 클러스터에서 파드에 대한 네트워킹을 담당하는 플러그인. 이 플러그인은 각 노드에 VPC IP 주소를 할당하고 파드들이 서로 통신할 수 있도록 네트워크를 구성하는 역할 AWS App2Container(A2C) 기존 온프레미스 또는 가상 머신에서 실행되는 Java 및 .NET 애플리케이션을 컨테이너화된 애플리케이션으로 전환하여 현대화할 수 있도록 지원하는 명령줄 도구. 이 도구를 사용하면 코드 변경 없이 애플리케이션을 컨테이너 이미지로 변환하여 ECS 또는 EKS와 같은 컨테이너 오케스트레이션 서비스에서 실행 AWS Lightsail 저렴하고 예측 가능한 가격으로 컨테이너와 같은 클라우드 리소스의 간단한 관리를 제공하는 사용하기 쉬운 가상 프라이빗 서버 클랄우드의 문턱을 낮춘 상품, 개인 개발자나 IT 인프라 관리자가 없는 소규모 기업체에 적합한 서비스 AWS Database Migration Service Oracle에서 Oracle로의 동종 마이그레이션은 물론 Oracle 또는 Microsoft SQL Server에서 Amazons Aurora로의 서로 다른 데이터베이스 플랫폼 간의 이기종 마이그레이션을 지원 짧은 지연시간으로 데이터를 지속적 복제 가능 AWS Control Tower Best Practice에 기반한 보안 멀티 계정 환경(Landing Zone이라고 부른다)의 설정을 자동화하는 매니지드 서비스 AWS 환경에 대한 지속적인 가시성을 제공하기 위해 프로비저닝 된 OU 및 계정 수, 활성화 된 가드레일 수 등을 시각화한 대시보드를 제공하여 이를 통해 해당 가드레일에 대해 OU 및 계정의 상태를 확인할 수 있도록 제공 Guardrail 클라우드 리소스 설정 시 보안 규칙에 어긋나지 않도록 클라우드 리소스를 유지시킬 수 있는 기능을 제공 특정 설정 정책 배포 차단 Detective Controls(탐지 제어) AWS Config 규칙을 사용하여 조직의 AWS 계정 및 리소스에서 규정 준수 위반 사항을 지속적으로 모니터링하는 기능 AWS Account Factory AWS Control Tower의 핵심 기능 중 하나로, 새로운 AWS 계정을 손쉽게 만들고 관리할 수 있는 자동화된 프로세스를 제공 AWS Elastic Beanstalk 웹 애플리케이션 및 서비스의 배포 및 조정을 위한 서비스 코드를 업로드 하면 Elastic Beanstalk이 용량 프로비저닝, 로드 밸런싱, 자동 조정부터 시작하여 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리 AWS Amplify 풀스택 애플리케이션 개발을 지원하는 개발 플랫폼 프론트엔드와 백엔드를 쉽게 설정, 개발, 배포를 통합적으로 관리하는 데 유용 Elastic Beanstalk은 백엔드를 쉽게 구성해주지만 Amplify는 프론트엔드, 백엔드, CI/CD를 쉽게 올인원으로 만들도록 도와준다.

May 20, 2026AWS
SAA 공부하며 끄적이는 개념들,,

서버가 죽지 않도록... ELB와 Auto-Scailing 이해하기 (feat. AWS)

먼저 ELB와 AutoScailing에 대해 알아보자. ELB (Elastic Load Balancing) ELB는 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 자동으로 분산시킨다. 단일 가용 영역 또는 여러 가용 영역에서 다양한 대상에 걸쳐 애플리케이션 트래픽의 부하를 분산하여 애플리케이션의 결함 허용 능력을 높인다. 그 중 ALB(Application Load Balancer)의 특징은 OSI 모델의 7계층(애플리케이션 계층)에서 작동하며 HTTP/HTTPS 프로토콜의 헤더 내용을 기반으로 고급 라우팅 결정을 내릴 수 있다. NLB(Network Load Balancer)는 OSI 모델의 4계층에서 작동하며 초당 수백만 개의 요청을 처리할 수 있는 성능을 제공한다. 또한 가용 여역당 하나의 고정 IP를 가질 수 있다는 큰 특징이 있다. 쉽게 얘기해보면 웹서비스를 운영한다면 ALB를, 게임 서버나 실시간 스트리밍이라면 속도가 생명인 NLB를 사용한다고 볼 수도 있겠다. AutoScailing Amazon EC2 AutoScailing은 애플리케이션의 부하를 처리할 수 있는 정확한 수의 EC2 인스턴스를 유지할 수 있게 도와준다. 지정된 조건에 따라 EC2 인스턴스를 자동으로 시작하거나 종료한다. 이를 통해 수요가 급증할 때는 성능을 유지하고 수요가 적을 때는 비용을 절감한다. 가장 큰 목적은 고가용성(HighAvailability)이다. scale out = 서버의 갯수가 늘어남, scale in = 서버의 갯수가 줄어듬. scale up = 서버의 리소스가 증가, scale down = 서버의 리소스가 감소. AutoScailing의 구성 순서는 아래와 같다. 1. ELB를 생성하면서 빈 타겟그룹을 생성한다. 2. 빈 타겟그룹으로 로드밸런서를 생성한다. 3. AutoScailing 그룹을 만든 후, 위에서 만든 빈 타켓그룹에 넣어준다. 간단한 실습을 통해 개념을 익히고 감각을 익혀보자. Web 서버를 ubuntu 24.04 기반으로 생성하여 AutoScailing을 구성해보자. EC2 인스턴스 개수는 최소 1대 최대 3대 가용 영역 최소 2개 이상(a, c)으로 하는 AutoScailing 가능한 web 서버들을 프라이빗 서브넷에 위치. stress 패키지가 재부팅 시에도 자동으로 부하가 걸리게끔. 외부(노트북의 브라우저)에서 웹페이지가 보이도록. ALB의 Listen Port : 88 Web 서버(인스턴스)를 생성할 때 퍼블릭으로 둔 후 필요한 패키지를 설치하고 인스턴스를 이미지 화 하여 프라이빗 서브넷에 인스턴스를 생성하는 방향으로 진행하였다. 먼저 퍼블릭 서브넷에 인스턴스를 하나 만들어서 nginx, stress(cpu 부하용) 패키지를 설치한 후 이미지화 하여 시작 템플릿을 만든다. bash apt update y && apt install y nginx echo webtem /var/www/html/index.html systemctl enable now nginx stress 패키지 설치 후 cpu에 부하 걸어주기. bash apt install y stress stress c 2 t 1200 t3.micro의 vcpus 갯수가 2개 이상이므로 c 2, t초 20분 동안 2 core cpu에 100% 부하를 준다. bash tee /etc/systemd/system/stress.service bash systemctl daemonreload systemctl enable stress 시스템 반영 후 재부팅 시에도 stress를 주도록 설정한다. 여기까지 했다면 이제 이미지(AMI)를 생성하고 시작 템플릿을 생성해준다. 1\. 로드 밸런서 생성 Internetfacing을 선택하고 2개의 가용 영역을 생성해주는데 퍼블릭 서브넷으로 설정을 해준다. 보안 그룹은 22번과 80번 포트가 열린 보안그룹을 선택한다. 여기서 대상 그룹을 생성해줘야 한다. 대상 그룹 생성 탭에 들어가 빈 타겟 그룹을 생성해준 뒤 돌아와서 생성한 대상 그룹을 선택해 준다. 2\. AutoScailing 그룹 생성 다음으로 AutoScailing 그룹을 생성해줘야 한다. 여기서도 2개의 가용 영역을 생성해주는데 서브넷은 프라이빗 서브넷에 위치시킨다. (EC2 인스턴스가 프라이빗 서브넷에 생성되어야 하므로) 기존의 로드 밸런서에 연결하는 설정을 해주고 위에서 만들었던 로드 밸런서 대상 그룹을 선택해준다. 지금부터가 중요하다. "ELB 상태 확인 켜기"를 체크해주고,  원하는 용량, 최소 용량, 최대 용량을 정의한 뒤 정책 이름을 설정해준다. 목표 CPU 사용률은 70%로 설정한다. 평균 CPU 사용률이 70%를 넘어서면 AutoScailing이 인스턴스를 늘려야겠다라고 판단해 새로운 인스턴스를 생성한다. 여기서 새로운 인스턴스는 기존에 생성된 인스턴스 스펙과 동일하게 생성된다. (아까 만든 시작 템플릿을 바탕으로) 추가로 모니터링 섹션에서 "그룹 지표 수집 활성화"를 체크해주면 CloudWatch에서 지표를 볼 수 있다. 최종적으로 88번 포트로 접속하면 잘 뜨는 것을 확인할 수 있다. 평균 CPU 사용률이 70%가 넘어가면 인스턴스가 최대 3개까지 늘어나도록 설정했다. 필요시 사용률이 줄어들면 인스턴스가 줄어들도록 scale in 정책을 만들 수 있다. 이 부분도 평균 CPU 사용률을 정의해주면 해당 값 이하로 떨어질 경우 AutoScailing이 인스턴스 갯수를 줄인다. CloudWatch 콘솔에 접속해 지표를 보면 CPU 사용률을 확인할 수 있다. (미처 CloudWatch에서 지표 확인 화면을 캡처하지 못해 비슷한 상황인 다른 사용자의 CloudWatch 이미지를 가져왔다.) 경보 알람이 발생하면 AutoScailing이 발생하고 인스턴스가 늘어나고 줄어드는 동작을 진행한다.  AutoScailing 흐름을 보면 이런 흐름이다. 지금까지 구성한 실습을 보면 이러하다. ALB가 퍼블릭 서브넷에 위치하여 외부 손닙을 맞이하는 입구 역할을 하고 EC2는 프라이빗 서브넷에 숨서어 실제 서비스를 제공한다. 외부 사용자는 ALB(88포트)로 들어오고, ALB는 내부망을 통해 EC2(80포트)로 연결을 토스한다. 인스턴스는 공인 IP가 없어도 ALB 덕분에 안전하게 서비스할 수 있다. 시작 템플릿은 서버를 만들 때 필요한 붕어빵 틀이라고 생각하면 편하다 AutoScailing 그룹을 생성하고 scale out(확장), scale in(축소) 정책을 생성해 CPU 부하에 따라서 시작 템플릿을 활용해 서버를 자동으로 생성하고 삭제한다. 이 과정에서 궁금증이 생겼다. "그럼 CPU 사용률이 떨어져 인스턴스가 삭제될 때 해당 인스턴스에 남아있는 사용자는 안 튕기나?" 삭제 결정이 내려진 서버에는 더 이상 새로운 사용자를 보내지 않는다.(배수 상태, Draining) 이미 접속 중인 손님이 볼일을 마칠 때까지 설정된 시간(기본 300초)동안 기다려 준다. 시간이 다 되면 사용자가 남아있더라도 연결을 끊고 서버를 종료한다. (이때 브라우저는 자동으로 다른 살아있는 서버에 재접속을 시도한다.) 그래서 사용자 입장에서는 잠깐의 딜레이가 발생하고 다른 큰 이슈 없이 사용할 수 있게된다. 좋은 인프라륵 구축하는 것도 중요하지만 이 속에서 "사용자가 장애를 느끼지 않게 하는 것"이 가장 큰 핵심인 것 같다. ALB와 AutoScailing의 조합은 단순한 자동화를 넘어 서비스의 연속성을 보장하는 강력한 도구인 것 같다.

May 12, 2026AWS
서버가 죽지 않도록... ELB와 Auto-Scailing 이해하기 (feat. AWS)

ECS vs Docker Swarm 컨테이너 오케스트레이션 비교 프로젝트

ECS vs Docker Swarm 컨테이너 오케스트레이션 비교 프로젝트 "성능 비교에서 운영 철학 비교로 — 실패가 아닌 발견의 과정" 프로젝트 개요 항목 내용 프로젝트 유형 인프라 비교 실험 기간 2026년 4월 목표 동일 EC2 환경에서 Docker Swarm과 Amazon ECS의 성능·운영 특성 비교 핵심 기술 Docker Swarm, Amazon ECS(EC2 Launch Type), AWS ALB, Prometheus, Grafana, k6 인프라 EC2 t3.small × 2대, ALB, VPC(퍼블릭 서브넷 단일 구성) 초기 목표 CPU 부하 상황에서의 오토스케일링 반응 속도 비교 컨테이너 강제 종료 후 복구 시간(Recovery Time) 측정 동일 애플리케이션 · 동일 부하 시나리오 기반의 공정한 비교 시스템 구성 공통 환경 EC2 t3.small × 2대 (각 2GB RAM) ├── 애플리케이션 컨테이너 (Spring Boot /env, /stress, /health) ├── cAdvisor (컨테이너 메트릭 수집) └── nodeexporter (시스템 메트릭 수집) 모니터링: Prometheus + Grafana 부하 생성: k6 (rampingarrivalrate 방식) 로그 수집: Python autoscaletest.py (2초 간격 컨테이너 수 추적) Docker Swarm 구성 Manager Node (클러스터 제어 + ingress 담당) Worker Node 1 ─┐ Worker Node 2 ─┘ → 앱 컨테이너 실행 (2 replicas) 네트워크: bridge / overlay 스케줄링: 로컬 Besteffort 방식 Amazon ECS 구성 ECS Cluster ├── EC2 인스턴스 1 (ECS Agent + 앱 Task + cAdvisor) └── EC2 인스턴스 2 (ECS Agent + 앱 Task + cAdvisor) Task 스펙: 0.25 vCPU / 0.5GB → 0.5 vCPU / 0.5GB (진행과정에서 변경) 네트워크: bridge → awsvpc 전환 ALB + Target Group(IP 타입) + Health Check(/health) 오토스케일링: CloudWatch CPU 70% 초과 시 Task 증가 비교 공정성 가설 및 검증 가설 — "Swarm 3대 vs ECS 2대가 공정한 비교다" 두 플랫폼을 같은 인스턴스 수(예: 둘 다 2대)로 맞추는 것이 얼핏 공정해 보이지만, 실제 애플리케이션을 처리하는 데이터 플레인 자원을 기준으로 보면 다르다. Docker Swarm은 Manager 노드가 클러스터 제어(오케스트레이션) 및 ingress 트래픽을 담당하므로, 앱 컨테이너는 Worker 2대에만 배치된다. Amazon ECS는 ECS의 Control Plane이 AWS 관리 영역에 존재하므로, 별도의 Manager 인스턴스가 불필요하다. EC2 2대 모두 앱 Task를 실행하는 워커 역할을 한다. 따라서 공정한 비교 기준은 "앱을 실제로 처리하는 인스턴스 수" 이며, 이 관점에서: Swarm: Manager 1대 + Worker 2대 (총 3대) ↔ ECS: EC2 2대 (총 2대) 양쪽 모두 앱 처리 인스턴스는 2대로 동일하다. 하지만 이 가설이 성립하려면 한 가지를 검증해야 했다. "Swarm Manager가 앱 컨테이너를 실행하지 않고, 실제 처리 부하는 Worker 2대가 전담하는가?" 검증 — 노드별 리소스 사용 현황 측정 Grafana + nodeexporter로 유휴 상태에서 각 노드의 리소스 사용량을 측정했다. 노드 역할 CPU Busy Sys Load RAM 사용량 비고 :::::: Swarm Manager 3.1% 12.5% 25.3% CPU/Load 가장 높음 → 제어 부담 Swarm Worker 1 2.5% 28.5% 33.1% Sys Load 매우 높음 → 실제 연산 수행 Swarm Worker 2 2.5% 4.5% 34.0% 메모리 점유 높음 → 앱 컨테이너 실행 ECSClu 1 2.0% 1.0% 34.9% 안정적 유휴 상태 ECSClu 2 2.1% 2.5% 34.9% ECSClu 1과 거의 동일 패턴 검증 결과 — 가설 입증 측정 결과는 가설을 명확히 지지한다. Manager: RAM 25.3%로 Worker(3334%)보다 유의미하게 낮고, Sys Load도 낮다. 앱 컨테이너를 실행하지 않고 클러스터 제어 부담만 지고 있음이 확인됐다. Worker 1·2: RAM 3334% 점유 및 높은 Sys Load → 실제 앱 컨테이너들이 Worker 노드에 배치되어 자원을 점유하고 있음. ECSClu 1·2: RAM 34.9%로 Swarm Worker와 유사한 수준 → 동일한 앱 처리 부담을 지고 있음. 결론: "Swarm 3대(Manager + Worker 2) vs ECS 2대"는 공정한 비교다. 앱을 실제로 처리하는 데이터 플레인은 양쪽 모두 2대이며, ECS는 관리형 서비스이므로 Manager 인스턴스 비용 없이 동일한 처리 용량을 확보할 수 있다. 실험 1 — 컨테이너 장애 복구 테스트 테스트 방법 runrecoverytest.py 스크립트를 각 노드에 대해 실행해 측정을 자동화했다. SSH로 원격 접속하여 docker kill로 컨테이너를 강제 종료하고, Prometheus API를 5초 간격으로 폴링해 컨테이너 수가 다시 EXPECTEDREPLICAS(1) 이상으로 복구되는 시점을 감지한다. [측정 흐름] kill 명령 실행 (killepoch 기록) → 5초 간격 Prometheus 폴링 (containerstarttimeseconds 기반) → 새 컨테이너의 starttime이 killepoch 이후임을 확인 → 복구 시각 기록 (recoveryseconds = recoveredepoch killepoch) → 결과를 recoverysummary.csv / recoveryraw.csv 에 저장 Prometheus 쿼리 구조 Swarm: containerlabelcomdockerswarmservicename="myapp" 으로 서비스 단위 집계 ECS: name="ecstoy." 정규식으로 Task 컨테이너 집계 복구 판단: max(containerstarttimeseconds{...}) 값이 kill 시점 이후로 갱신되었는지 확인 Docker Swarm Test ※ 그라파나 대시보드의 시간축은 UTC 기준으로 표시되며, 실제 테스트 실행 시각(KST, UTC+9)과 9시간 차이가 있습니다. ECS Test ※ 그라파나 대시보드의 시간축은 UTC 기준으로 표시되며, 실제 테스트 실행 시각(KST, UTC+9)과 9시간 차이가 있습니다. 전체 측정 결과 (recoverysummary.csv) 총 8회 테스트 수행 (Swarm 4회, ECS 4회). 테스트 ID 플랫폼 kill 시각 복구 시각 복구 시간(초) 결과 :: swarmworker120260406 Swarm 14:32:27 14:32:46 19.08초 ✅ success swarmworker220260406 Swarm 15:34:42 15:35:01 19.19초 ✅ success ecs120260407 ECS 02:42:49 — timeout ❌ fail ecs220260407 ECS 03:19:07 03:30:25 677.63초 (약 11분) ✅ success swarmworker120260411 Swarm 13:50:25 13:50:46 21.20초 ✅ success swarmworker220260411 Swarm 13:54:44 13:55:05 21.21초 ✅ success ecs120260411 ECS 13:56:26 14:13:54 1047.99초 (약 17분) ✅ success ecs220260411 ECS 14:17:25 14:40:39 1394.02초 (약 23분) ✅ success 플랫폼별 요약 구분 측정 횟수 평균 복구 시간 범위 성공률 ::::: Docker Swarm 4회 약 20초 19.08 21.21초 4/4 (100%) Amazon ECS 4회 약 1,040초 (약 17분) 677초 1,394초 (1회 timeout 제외) 3/4 (75%) Swarm은 4회 모두 1921초로 일관된 복구를 보인 반면, ECS는 677초1,394초로 회차마다 편차가 크고, 1회는 180초 timeout 내에 복구 자체를 실패했다. ECS timeout 케이스(ecs120260407)는 스크립트 제한(180초) 때문에 실패로 기록됐지만, 이후 테스트에서 같은 노드가 1,047초 만에 복구된 것으로 보아 실제 복구는 이뤄졌으나 측정 범위를 벗어난 것으로 판단된다. 원인 분석 (ECS 복구 지연) ECS의 복구 지연은 단순한 성능 문제가 아니라 구조적 설계 차이에서 비롯된다. ① ALB Health Check 대기 (가장 큰 원인) 체크 주기: 기본 30초 정상 임계 횟수: 기본 5회 최소 소요: 30초 × 5회 = 150초(2분 30초) ② Deregistration Delay (Connection Draining) 기존 컨테이너 등록 해제 대기: 기본 300초(5분) 이론 합계: 5분 + 2분 30초 ≈ 7분 30초 실측값(677초1,394초)은 이 이론치보다도 훨씬 큰데, 이는 테스트 당시 EC2 자원 여유 부족으로 새 Task 생성 자체가 지연됐기 때문으로 추정된다. ③ ECS Agent 폴링 주기 EC2 내 ECS Agent는 실시간 Push가 아닌 주기적 Poll 방식으로 AWS Control Plane과 통신 Swarm 대비 수초수십초 추가 지연 발생 ④ ECS 회차별 편차의 원인 실험 당시 EC2 t3.small(2GB)에 ECS Agent, cAdvisor, nodeexporter가 상주 중이었고, 새 Task 생성 시 메모리 여유가 부족한 경우 배치 자체가 지연됐다. 이는 ECS의 Resource reservation 기반 스케줄링 특성상, 자원이 확보되지 않으면 배치를 아예 거부하는 구조에서 비롯된다. 최적화 가능 방향 설정 항목 기본값 최적화 값 효과 Deregistration Delay 300초 30초 이하 대기 시간 대폭 단축 Health Check Interval 30초 10초 확인 주기 단축 Healthy Threshold 5회 2회 통과 시간 20초로 단축 EC2 메모리 여유 확보 Task 0.25vCPU/0.5GB 인스턴스 업그레이드 or Task 스펙 조정 Task 배치 지연 해소 실험 2 — CPU 부하 오토스케일링 테스트 부하 시나리오 (k6 stresstest.js) 시나리오: rampingarrivalrate 워밍업(30→2분) → CPU 상승(60→3분) → 70% 근접(80→3분) → 유지(80, 5분) → 추가 확장(100, 3분) → 유지(100, 5분) 오토스케일링 트리거: CPU Utilization 70% 초과 Docker Swarm 오토스케일링 결과 이벤트 시각 내용 ScaleOut 10:56:15 2 → 4 컨테이너 증가 Stabilization 10:56:15 이후 count=4로 안정 유지 ScaleIn 11:00:15 4 → 2 컨테이너 감소 SelfHealing 실험 중 1→0→1 컨테이너 재생성 확인 Amazon ECS 오토스케일링 결과 및 이슈 ECS에서는 의도한 ScaleOut 대신 SelfHealing(Task 교체) 현상이 반복됐다. 증상 /stress 요청으로 CPU 100% → /health 지연 → ALB Health Check 실패 ECS가 Unhealthy Task를 종료 후 새 Task 생성 (Desired Count 유지) container=error 로그 반복 확인 원인 부하가 한쪽 컨테이너에 집중 → 전체 평균 CPU가 낮아 오토스케일링 미충족 bridge 모드 고정 hostPort(80) → 동일 인스턴스에 복수 Task 배치 불가 조치 및 awsvpc 전환 후 네트워크 모드: bridge → awsvpc 전환 Target Group 타입: instance → IP 타입 재생성 부하 방식: constantarrivalrate → rampingarrivalrate로 변경 전환 후 2→3 증가는 확인됐으나 Task 1개가 종료되는 현상 재발. 실험 시간 제약으로 완전한 안정화 달성 전 종료. 주요 트러블슈팅 기록 T1. Bridge 모드 고정 hostPort Scaleout 실패 내용 증상 Desired Count 34로 변경해도 Running Task는 2개에서 증가 안 함 원인 hostPort=80 고정 시 EC2 한 대에 동일 포트 컨테이너 2개 배치 불가 조치 hostPort=0(동적 포트) 변경 → 이후 awsvpc + IP Target Group으로 전환 T2. Target Group 설정 오류 → Health Check 실패 → SelfHealing 오해 발생 흐름 bridge 모드에서 hostPort 고정 → Scaleout 시도 시 포트 충돌로 신규 Task 배치 실패 → awsvpc 전환 결정 → 기존 instance 타입 Target Group을 ip 타입으로 변경 시도 → AWS 정책상 불가(immutable) → Target Group 신규 생성했으나 포트 설정 미스 → ALB가 Task를 Unhealthy로 판정 → ECS가 Unhealthy Task 종료 후 새 Task 생성 반복 → Task가 죽었다 살아나는 걸 보고 Scaleout으로 오해 → 실제로는 SelfHealing(장애 교체) 이었음 내용 증상 Scaleout을 기대했으나 기존 Task가 종료되고 새 Task가 생성되는 패턴 반복 근본 원인 instance 타입 Target Group → awsvpc 전환 후 ip 타입으로 재생성 필요. AWS ALB Target Type은 생성 후 변경 불가(immutable)이므로 신규 생성했으나 포트 설정 불일치로 Health Check 계속 실패 조치 Target Group ip 타입으로 재생성 (port 8080, /health) → ALB Security Group에서 8080 인바운드 허용 확인 → /stress?timeout=10 → timeout=1로 부하 완화 T3. Grafana 컨테이너 수 과다 표시 내용 증상 ECS Running Task 2개인데 Grafana에서 45개로 표시 원인 awsvpc 모드에서 Task마다 internalecspause 컨테이너 자동 생성 조치 PromQL에 containerlabelcomamazonawsecscontainername="toysb" 필터 추가 비교 분석 핵심 지표 비교 항목 Docker Swarm Amazon ECS 설계 목적 경량 오케스트레이션 클라우드 운영 플랫폼 복구 시간 약 21초 약 7분 (기본 설정) 스케일링 반응 즉시 (로컬 스케줄러) 수십초수분 (CloudWatch 기반) 스케줄링 방식 Besteffort (공격적) Resource reservation (보수적) 오버커밋 가능 거의 불가 네트워크 오버헤드 낮음 (bridge/overlay) 높음 (ENI, ALB, Target Group) 운영 복잡도 낮음 높음 안정성 상대적으로 낮음 높음 모니터링 통합 직접 구성 필요 CloudWatch 기본 연동 왜 ECS가 느린가 (구조적 이해) [Docker Swarm 복구 흐름] 컨테이너 종료 감지 (Docker Engine 내장) → 즉시 재스케줄링 (로컬 의사결정) → 컨테이너 Running → 즉시 트래픽 수신 ≈ 수초20초 [Amazon ECS 복구 흐름] Docker Engine 장애 감지 → ECS Agent 전달 → AWS Control Plane 보고 (네트워크 왕복) → 새 Task 생성 → ENI 할당 → ALB Target Group 등록 → Health Check 대기 (30초 × 5회 = 150초) → Deregistration Delay 대기 (300초) ≈ 7분+ ECS의 느림은 "안전한 트래픽 전환을 보장하는 설계"의 결과다. 💡 프로젝트를 통해 얻은 핵심 인사이트 1. 동일 환경 비교의 어려움 — ECS는 불리한 조건에서 측정됐다 ECS를 Swarm 수준에 맞추기 위해 세팅 초기에 Task 리소스를 0.25 vCPU/0.5GB로 제한하자 컨테이너 불안정, 메모리 부족, GC 문제가 발생했다. "비교를 공정하게 만들려다 ECS의 장점을 모두 제거하는" 역설을 경험했다. 이번 실험에서 측정된 ECS의 느린 복구 시간(677초1,394초)은 ECS 자체의 한계가 아니라 실험 조건의 한계다. [이번 실험의 ECS 조건 — 불리한 환경] EC2 t3.small (2GB) 위에 ECS Agent + cAdvisor + nodeexporter 상주 → Task 리소스를 0.25vCPU/0.5GB로 억지로 제한 → 메모리 여유 부족으로 새 Task 배치 자체가 지연 → Swarm 비교를 위해 ECS 본래 설계 방식을 벗어난 구성 [ECS 본래 용도로 사용했다면] Fargate 사용 → EC2 관리 불필요, AWS가 미리 준비한 자원 풀에서 즉시 컨테이너 주입 → Task 배치 지연 없음 → Health Check 설정 튜닝 (Interval 10초, Threshold 2회) 시 복구 시간 20초대도 가능 즉, "ECS가 느리다"가 아니라 "EC2 위에 억지로 올린 ECS가 느렸다" 는 것이 정확한 표현이다. Fargate로 ECS 본래 용도대로 운영했다면 복구 속도 자체는 Swarm과 크게 다르지 않을 수 있다. 2. 비교 관점의 전환 Before After 단순 성능 비교 (속도) 운영 전략 비교 (적합한 환경의 차이) "ECS가 느리다" "EC2 위에 억지로 올린 ECS가 느렸다" "Swarm이 더 좋다" "온프레미스엔 Swarm, 클라우드엔 ECS(Fargate)" 3. 실무 관점에서의 선택 기준 ECS가 Swarm보다 낫다거나, 기업이 Swarm을 버리고 ECS를 선택한다는 식의 결론은 정확하지 않다. 실제로는 인프라 환경(온프레미스 vs 클라우드 온디맨드) 에 따라 각각이 적합한 상황이 다르다. 상황 적합한 선택 이유 온프레미스 / 자체 서버 보유 Docker Swarm 클라우드 벤더 종속 없이 직접 소유한 서버에서 경량 오케스트레이션 운영 가능. AWS API 호출 비용·지연 없음. AWS 클라우드 온디맨드 Amazon ECS ALB·CloudWatch·IAM·VPC 등 AWS 에코시스템과 완전 통합. 인프라를 직접 소유하지 않고 사용한 만큼만 과금. 클라우드지만 벤더 독립이 중요 Docker Swarm 멀티클라우드 또는 이식성이 중요한 환경에서는 Swarm이 유리. 서버리스 지향, 인프라 관리 최소화 ECS (Fargate) EC2 자체를 관리할 필요 없이 컨테이너 단위로 과금·운영 가능. 이 프로젝트를 통해 깨달은 핵심은, "어느 쪽이 더 좋은가"가 아니라 "우리 인프라 환경이 온프레미스냐 클라우드냐에 따라 자연스럽게 선택이 갈린다" 는 점이다. 온프레미스 서버를 보유한 조직이 굳이 ECS를 쓸 이유가 없고, AWS 위에서 운영하는 조직이 굳이 Swarm을 직접 관리할 이유도 없다. 4. 트러블슈팅 역량 단순 기능 구현을 넘어, 네트워크 모드 선택이 확장성에 미치는 영향, ALB Health Check가 복구 시간을 결정하는 메커니즘, ECS Agent 폴링 방식의 한계 등 인프라 내부 동작 원리를 실험을 통해 직접 검증했다. 기술 스택 구분 기술 컨테이너 오케스트레이션 Docker Swarm, Amazon ECS (EC2 Launch Type) 애플리케이션 Spring Boot (Java) 인프라 AWS EC2 (t3.small), ALB, VPC, Target Group 모니터링 Prometheus, Grafana, cAdvisor, nodeexporter 부하 테스트 k6 (rampingarrivalrate), Python (autoscaletest.py) 네트워크 bridge, overlay, awsvpc, ENI 회고 및 결론 본 프로젝트는 "완벽한 비교 실험"보다 더 가치 있는 것을 남겼다. 단순히 수치를 비교하는 과정에서, 두 시스템이 서로 다른 문제를 풀기 위해 설계됐다는 점을 발견했다. ECS를 Swarm처럼 다운그레이드해서 비교하는 것 자체가 잘못된 접근이었음을 실험 도중 깨달았고, 그 깨달음 자체가 이 프로젝트의 핵심 성과다. Docker Swarm은 빠르고 단순한 오케스트레이터, Amazon ECS는 느리지만 안정적인 클라우드 운영 플랫폼이다.

May 11, 2026오케스트레이션
ECS vs Docker Swarm 컨테이너 오케스트레이션 비교 프로젝트

On-Premise Kubernetes 클러스터 구축 및 CI/CD 파이프라인 자동화 프로젝트

OnPremise Kubernetes 클러스터 구축 및 CI/CD 파이프라인 자동화 프로젝트 기간: 2026.04.27 – 2026.04.30 기술 스택: Kubernetes · Helm · ArgoCD · GitHub Actions · Amazon ECR · AWS 역할: 온프레미스 K8s 클러스터 세팅 / 초기 매니페스트 작성 / Helm Chart 고도화 / CI/CD 파이프라인 구축 목차 1. 프로젝트 개요 2. 전체 아키텍처 3. 온프레미스 K8s 클러스터 구성 4. 초기 매니페스트 작성 5. Helm Chart 고도화 6. ECR 프라이빗 레지스트리 연동 트러블슈팅 7. ArgoCD 기반 CI/CD 파이프라인 구축 8. 배포 검증 결과 9. 회고 및 개선 방향 1. 프로젝트 개요 단순히 애플리케이션을 컨테이너로 실행하는 수준을 넘어서, 실제 운영 환경에 가까운 배포 자동화 구조를 직접 설계하고 구현하는 것을 목표로 했습니다. 온프레미스 VMware 환경에 Kubernetes 클러스터를 직접 구성하고, 원시 YAML 매니페스트에서 출발해 Helm Chart로 고도화한 뒤 GitHub Actions → ECR → ArgoCD 로 이어지는 GitOps 기반 CI/CD 파이프라인까지 완성했습니다. 핵심 목표: 쿠버네티스 핵심 리소스(Deployment, Service, Ingress, Namespace)를 실제 클러스터에서 직접 경험 Prod / Dev 환경을 노드 단위로 분리하여 운영 안정성 확보 Helm Chart로 환경별 설정을 코드로 관리 GitOps 방식으로 배포 이력 추적 및 자동화 2. 전체 아키텍처 개발자 코드 Push │ ▼ GitHub Actions (CI) │ Docker 이미지 빌드 │ Amazon ECR Push ▼ ArgoCD (CD / GitOps) │ Git 상태 감지 → Sync ▼ OnPremise K8s 클러스터 (VMware 211.183.3.0/24) ├── Master Node (211.183.3.200) ├── Prod: worker1 (211.183.3.210) + worker2 (211.183.3.220) └── Dev: devworker (211.183.3.230) 외부 접근 흐름: 사용자 → Route53(prod.dongkyu.cloud) → EC2 nginx 리버스 프록시 → Tailscale 터널 → K8s NGINX Ingress Controller (NodePort 31018) → Service → Pod 3. 온프레미스 K8s 클러스터 구성 31. 클러스터 노드 구성 역할 호스트명 IP 환경 Master toymaster 211.183.3.200/24 제어 플레인 Worker toyworker1 211.183.3.210/24 Prod Worker toyworker2 211.183.3.220/24 Prod Worker devtoyworker 211.183.3.230/24 Dev kubeadm v1.30.14, Ubuntu 24.04, Flannel CNI로 구성했으며 Pod CIDR은 10.244.0.0/16을 사용했습니다. 32. Prod / Dev 환경 분리 단순히 Namespace만 분리하면 Pod가 어느 노드에든 스케줄링될 수 있습니다. 노드 라벨과 nodeSelector를 조합해 Prod Pod는 Prod 노드에만, Dev Pod는 Dev 노드에만 배치되도록 강제했습니다. bash kubectl create namespace dev kubectl create namespace prod kubectl label node toyworker1 env=prod kubectl label node toyworker2 env=prod kubectl label node devtoyworker env=dev yaml Deployment spec 일부 spec: template: spec: nodeSelector: env: prod dev 환경은 env: dev 항목 Dev Prod Namespace dev prod Node 라벨 env=dev env=prod 도메인 dev.dongkyu.cloud prod.dongkyu.cloud 레플리카 1 2 4. 초기 매니페스트 작성 41. 애플리케이션 구조 Backend(Spring Boot, 8080 포트)와 Frontend(Nginx, 80 포트)를 각각 Deployment + Service로 정의하고, NGINX Ingress Controller로 외부 라우팅을 구성했습니다. yaml appdeploy.yml — backend Deployment (일부) apiVersion: apps/v1 kind: Deployment metadata: name: backenddep spec: replicas: 2 selector: matchLabels: app: backend template: spec: nodeSelector: env: prod imagePullSecrets: name: ecrsecret containers: name: backend image: 431538665162.dkr.ecr.apnortheast2.amazonaws.com/backend:latest ports: containerPort: 8080 42. Ingress 라우팅 설계 /api/(.) 경로는 backend로, 나머지 경로(/?(.))는 frontend로 분기합니다. yaml ingress.yml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: appingress annotations: nginx.ingress.kubernetes.io/rewritetarget: /$1 nginx.ingress.kubernetes.io/useregex: "true" spec: ingressClassName: nginx rules: host: prod.dongkyu.cloud http: paths: path: /api/(.) pathType: ImplementationSpecific backend: service: name: backend port: number: 8080 path: /?(.) pathType: ImplementationSpecific backend: service: name: frontend port: number: 80 외부 요청 경로: prod.dongkyu.cloud └─ DNS: 211.183.3.231 (Ingress Controller External IP) └─ NGINX Ingress: Host 헤더 확인 ├─ /api/ → backend Service → Pod └─ / → frontend Service → Pod 5. Helm Chart 고도화 초기 매니페스트는 환경마다 중복 YAML을 작성해야 했습니다. Helm Chart로 템플릿화하여 하나의 Chart를 values 파일만 바꿔 dev/prod에 재사용하는 구조로 개선했습니다. GitHub: LDK511/aws13k8sproject 51. 디렉토리 구조 helm/ ├── backend/ │ ├── Chart.yaml │ ├── templates/ │ │ ├── deployment.yaml │ │ ├── service.yaml │ │ └── ingress.yaml │ ├── values.yaml 공통 기본값 │ ├── valuesdev.yaml Dev 오버라이드 │ └── valuesprod.yaml Prod 오버라이드 └── frontend/ ├── Chart.yaml ├── templates/ │ ├── deployment.yaml │ └── service.yaml ├── values.yaml ├── valuesdev.yaml └── valuesprod.yaml 52. values.yaml 구조 yaml backend/values.yaml env: prod imagePullSecret: ecrsecret replicaCount: 2 image: repository: 431538665162.dkr.ecr.apnortheast2.amazonaws.com/backend tag: "latest" service: port: 8080 ingress: enabled: true className: nginx host: prod.dongkyu.cloud yaml backend/valuesdev.yaml — dev 환경 오버라이드 env: dev replicaCount: 1 image: tag: "latest" ingress: host: dev.dongkyu.cloud 53. Helm 템플릿 — Deployment yaml backend/templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: backend spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: app: backend template: spec: nodeSelector: env: {{ .Values.env }} imagePullSecrets: name: {{ .Values.imagePullSecret }} containers: name: backend image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" ports: containerPort: 8080 54. 배포 명령 흐름 bash 문법 검사 helm lint ./backend && helm lint ./frontend 렌더링 미리보기 (실제 배포 전 확인) helm template backenddev ./backend f ./backend/valuesdev.yaml Dev 배포 helm install backenddev ./backend n dev f ./backend/valuesdev.yaml helm install frontenddev ./frontend n dev f ./frontend/valuesdev.yaml Prod 배포 helm install backendprod ./backend n prod f ./backend/valuesprod.yaml helm install frontendprod ./frontend n prod f ./frontend/valuesprod.yaml 업데이트 helm upgrade backenddev ./backend n dev f ./backend/valuesdev.yaml Before vs After 비교: 항목 초기 매니페스트 Helm Chart 고도화 후 환경별 파일 dev/prod 각각 별도 YAML values 파일만 교체 재사용성 없음 (복사·붙여넣기) 하나의 Chart 재사용 배포 이력 수동 관리 helm history로 추적 롤백 이전 파일 재적용 helm rollback 1커맨드 6. ECR 프라이빗 레지스트리 연동 트러블슈팅 문제 상황 ECR 프라이빗 저장소에서 이미지를 Pull할 때 ImagePullBackOff 오류가 지속적으로 발생했습니다. 터미널에서 docker login을 성공했음에도 동일한 에러가 반복되었습니다. 근본 원인 분석 원인 설명 인증 주체 분리 터미널의 docker login 정보를 Kubelet이 자동으로 공유하지 않음 저장 위치 차이 로그인 정보는 /.docker/config.json (유저 홈) → Kubelet은 참조 불가 노드 전파 안 됨 마스터 노드 인증은 워커 노드에 전파되지 않음 런타임 차이 최신 K8s는 containerd 사용 → Docker 로그인 정보와 미호환 해결 방법 ECR 로그인 토큰을 Kubernetes Secret으로 등록하고 Deployment에 명시적으로 연결합니다. 핵심 원리: IAM 키는 "열쇠를 만들 권한"이고, 실제로 이미지를 Pull하는 Kubelet이 열 수 있는 "물리적 열쇠"(ecrsecret)를 네임스페이스에 직접 비치해야 합니다. bash Step 1: ECR 인증 토큰으로 K8s Secret 생성 (유효시간 12시간) kubectl create secret dockerregistry ecrsecret \ dockerserver=431538665162.dkr.ecr.apnortheast2.amazonaws.com \ dockerusername=AWS \ dockerpassword=$(aws ecr getloginpassword region apnortheast2) yaml Step 2: Deployment에 imagePullSecrets 명시 spec: template: spec: imagePullSecrets: name: ecrsecret containers: name: backend image: 431538665162.dkr.ecr.apnortheast2.amazonaws.com/backend:latest 운영 개선 포인트: ECR 토큰은 12시간마다 만료됩니다. 실제 운영 환경에서는 CronJob을 통한 자동 갱신이 필요합니다. 7. ArgoCD 기반 CI/CD 파이프라인 구축 71. CI/CD 흐름 개발자 Push (main → Prod, develop → Dev) │ ▼ GitHub Actions ├── Docker 이미지 빌드 └── Amazon ECR Push (이미지 태그: commit SHA) │ ▼ ArgoCD (Git 저장소 감지) │ helm/backend/values.yaml의 image.tag 변경 감지 ▼ K8s 클러스터 자동 Sync ├── dev namespace ← develop 브랜치 └── prod namespace ← main 브랜치 72. ArgoCD 설치 (Helm) bash helm repo add argo https://argoproj.github.io/argohelm helm repo update helm install argocd argo/argocd \ namespace argocd \ createnamespace \ set server.service.type=NodePort \ set server.service.nodePortHttps=31443 Tailscale IP를 통해 ArgoCD UI에 접근합니다: https://100.100.150.8:31443 73. Application CRD 구성 ArgoCD에게 "어떤 Git 저장소의 어떤 Chart를 어떤 네임스페이스에 배포할 것인가"를 선언하는 Application CRD를 작성합니다. yaml argocd/backenddev.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: backenddev namespace: argocd spec: project: default source: repoURL: https://github.com/LDK511/aws13k8sproject.git path: helm/backend targetRevision: develop Dev → develop 브랜치 helm: valueFiles: valuesdev.yaml destination: server: https://kubernetes.default.svc namespace: dev syncPolicy: automated: Git 변경 감지 시 자동 배포 selfHeal: true 클러스터 상태가 Git과 달라지면 자동 복구 prune: true Git에서 삭제된 리소스 자동 제거 총 4개의 Application CRD를 작성하여 backenddev, backendprod, frontenddev, frontendprod 모두 자동 배포가 가능하도록 구성했습니다. bash kubectl apply f argocd/backenddev.yaml kubectl apply f argocd/backendprod.yaml kubectl apply f argocd/frontenddev.yaml kubectl apply f argocd/frontendprod.yaml 74. 브랜치 전략 연계 브랜치 ArgoCD Target 배포 환경 네임스페이스 main main Prod prod develop develop Dev dev 8. 배포 검증 결과 81. Pod 배치 확인 83. Ingress 라우팅 검증 bash kubectl get ingress A NAMESPACE NAME CLASS HOSTS ADDRESS PORTS dev appingress nginx dev.dongkyu.cloud 211.183.3.230 80 prod appingress nginx prod.dongkyu.cloud 211.183.3.230 80 84. ArgoCD 동기화 상태 4개 Application(backenddev, backendprod, frontenddev, frontendprod) 모두 Healthy / Synced 상태로 정상 동작을 확인했습니다. 9. 회고 및 개선 방향 잘 된 점 초기 단순 매니페스트에서 Helm Chart 고도화, CI/CD 연동까지 전체 배포 사이클을 한 번에 경험 nodeSelector를 통한 Prod/Dev 노드 분리로 리소스 격리 구현 ECR ImagePullBackOff 트러블슈팅 과정에서 K8s 인증 체계(Secret, Kubelet, containerd)에 대한 깊은 이해 획득 GitOps 방식으로 배포 이력 추적 및 selfHeal을 통한 클러스터 자동 복구 경험 개선할 점 / 향후 계획 개선 항목 이유 ECR Secret 자동 갱신 CronJob 12시간 토큰 만료 문제 해결 TLS/HTTPS 적용 (certmanager) 현재 HTTP로만 서비스 중 HPA (Horizontal Pod Autoscaler) 트래픽 기반 자동 스케일링 Prometheus + Grafana 모니터링 강화 Pod/노드 메트릭 시각화 이 프로젝트의 핵심 가치는 "서비스를 만드는 것"이 아니라 "서비스가 어떻게 운영되는가"를 직접 설계하고 증명한 것입니다. DNS → Ingress → Service → Pod로 이어지는 네트워크 흐름, ECR 인증 구조, Helm 기반 환경 분리, GitOps 배포 방식은 클라우드/DevOps 직무에서 즉시 활용 가능한 역량입니다.

May 10, 2026kubernetes
On-Premise Kubernetes 클러스터 구축 및 CI/CD 파이프라인 자동화 프로젝트