[{"content":" 2025.10.01 / 18:00 - 20:00 진행, 숭인관 403호\n💡 Member Session 이번 세션에서는 5명의 멤버가 API Gateway, Lambda, EventBridge Manager, SQS, SNS 를 주제로 발표를 진행했습니다.\n세션이 끝난 뒤에는 함께 SAA 문제를 풀고, 오답을 공유하며 학습 내용을 점검하는 시간을 가졌습니다.\n세션 1: API Gateway 이번 세션은 오혜인 님께서 진행해주셨습니다.\n세션 주제는 API Gateway로, 서비스의 개념부터 실제 적용 예시까지 폭넓게 다뤘습니다.\nAPI Gateway가 클라이언트와 서버 사이에서 요청을 라우팅하고 인증, 모니터링, 트래픽 제어 등을 수행하는 서비스라는 점을 중심으로 살펴보았습니다.\n또한, HTTP API / REST API / WebSocket API의 차이와 각각의 사용 사례를 비교하면서,\nServerless 아키텍처(Lambda 연동) 환경에서의 활용 방법도 함께 학습했습니다.\n세션 2: Lambda 두 번째로 나혜윤 님께서 진행해주셨습니다.\n주제는 AWS Lambda로, 서버리스(Serverless) 컴퓨팅의 핵심 개념과\n이를 기반으로 한 이벤트 기반 함수 실행 구조(FaaS) 에 대해 다뤘습니다.\nLambda는 서버를 직접 관리하지 않고, 이벤트 발생 시에만 코드를 실행하는 서비스로,\n개발 속도 향상과 인프라 관리 부담 절감, 그리고 비용 효율성 측면에서 강점을 갖습니다.\n세션에서는 Lambda의 핵심 구성 요소(함수, 트리거, 권한) 와\nIAM 실행 역할, 콜드 스타트 문제, 실행 제한 등 실무에서 고려해야 할 포인트들을 함께 배웠습니다.\n또한 콘솔 실습을 통해 직접 Lambda 함수 생성 → 트리거 연결 → 실행 테스트까지 확인했습니다.\n마지막으로, 실시간 데이터 처리·파일 자동 변환·정기 작업 자동화 등\nLambda가 비용 효율적이며 자동 확장 가능한 서버리스 아키텍처의 대표 솔루션임을 이해할 수 있었습니다.\n세션 3: EventBridge 세 번째로 김가은 님께서 진행해주셨습니다.\n주제는 Amazon EventBridge로, AWS에서 제공하는 이벤트 기반 아키텍처(EDA) 구축 서비스에 대해 다뤘습니다.\nEventBridge는 이벤트를 규칙(Rule)에 따라 필터링하고, 다양한 대상(Target) — 예를 들어 Lambda, SNS, SQS, Step Functions 등 — 으로 전달해주는 서버리스 이벤트 라우팅 서비스입니다.\n즉, 서비스 간 복잡한 연결 없이 느슨한 결합(Loosely Coupled) 구조로 시스템을 통합할 수 있습니다.\n세션에서는 EventBridge의 핵심 구성 요소인 Event / Event Bus / Rule / Target을\n물류센터의 ‘택배 분류 과정’에 비유하여 직관적으로 이해할 수 있었습니다.\n또한 CloudWatch Events와의 차이점, 다중 타깃 전달(fan-out), 이벤트 재처리(Replay),\nSaaS 연동 등 실제 활용 사례를 통해 EventBridge의 실무 적용 가능성도 함께 배웠습니다.\n마지막으로, DLQ(Dead Letter Queue) 설정, 이벤트 필터링 최적화, 순서 보장 한계 등\n실무에서 반드시 알아야 할 주의사항과 함께,\nEDA가 마이크로서비스 구조에서 어떤 이점을 제공하는지 명확히 이해할 수 있는 세션이었습니다.\n세션 4: SQS 네 번째로 방민채 님께서 진행해주셨습니다.\n주제는 Amazon SQS(Simple Queue Service) 로, 분산 시스템에서 비동기 메시지 큐를 통해 서비스 간 결합도를 낮추고, 트래픽 폭주 상황에서도 안정적으로 처리량을 평탄화하는 방법을 다뤘습니다.\nSQS는 Producer → Queue → Consumer 구조로 메시지를 안전하게 전달하며, 주요 기능으로 Visibility Timeout(동일 메시지 중복 처리 방지),\nDelay Delivery(지연 전송), DLQ(실패 메시지 격리/분석),\nLong Polling(빈 응답 감소로 비용 효율) 등을 제공합니다.\n또한 Standard Queue(무제한 처리량, 최소 1회 전송/순서 미보장) 와\nFIFO Queue(정확히 1회 전송, 엄격한 순서 보장·처리량 제한) 의 차이를 비교하며\n업무 특성에 따른 선택 기준을 정리했습니다.\n실습에서는 콘솔에서 큐 생성 → 메시지 전송/수신(폴링) → 암호화/정책 설정 →\n옵션 편집 및 삭제까지 전 과정을 수행해 보며, 운영 관점의 체크포인트를 익혔습니다.\n세션 5: SNS 다섯 번째로 박슬기 님께서 진행해주셨습니다.\n주제는 Amazon SNS(Simple Notification Service) 로,\n하나의 메시지를 여러 구독자에게 동시에 전달할 수 있는 완전 관리형 메시징 서비스에 대해 다뤘습니다.\nSNS는 게시자(Publisher) 가 메시지를 주제(Topic) 에 발행하면,\n구독자(Subscriber) 가 이메일, 문자, Lambda, SQS, HTTP(S) 엔드포인트 등 다양한 방식으로 메시지를 수신할 수 있습니다.\n이 구조를 통해 하나의 이벤트를 여러 대상에게 동시에 전송하는 팬아웃(Fan-out) 패턴을 쉽게 구현할 수 있습니다.\n세션에서는 SNS의 A2A(Application-to-Application), A2P(Application-to-Person) 구조,\n표준 주제(Standard Topic) 와 FIFO 주제(FIFO Topic) 의 차이,\n그리고 메시지 속성 필터링, DLQ, 암호화 및 보안 정책 등 주요 기능을 학습했습니다.\n또한 SNS vs SQS 비교를 통해\nSNS는 이벤트 브로드캐스트, SQS는 비동기 버퍼링에 강점을 가진다는 점을 명확히 구분했습니다.\n실제 아키텍처에서는 두 서비스를 함께 사용해 확장성과 신뢰성을 모두 확보하는 패턴을 자주 활용함을 배웠습니다.\n마무리 마지막으로, 멤버들이 함께 SAA 문제 5개를 풀고 오답을 공유하며 부족한 개념을 보완했고, 학습한 내용을 정리해 노션에 기록하는 시간을 가지며 세션을 마무리했습니다.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/3rd/post-5-member-session/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2025.10.01 / 18:00 - 20:00 진행, 숭인관 403호\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-member-session\"\u003e💡 Member Session\u003c/h2\u003e\n\u003cp\u003e이번 세션에서는 5명의 멤버가 \u003cstrong\u003eAPI Gateway, Lambda, EventBridge Manager, SQS, SNS\u003c/strong\u003e 를 주제로 발표를 진행했습니다.\u003c/p\u003e\n\u003cp\u003e세션이 끝난 뒤에는 함께 SAA 문제를 풀고, 오답을 공유하며 학습 내용을 점검하는 시간을 가졌습니다.\u003c/p\u003e","title":"Member Session (2)"},{"content":" 2025.09.24 / 17:00 - 19:00 진행, 숭인관 403호\n💡 Member Session 지난주까지는 코어 멤버 세션이 진행되었고, 이번 주부터는 모든 멤버들이 돌아가면서 AWS의 핵심 주제를 맡아 세션을 진행하고 있습니다.\n이번 세션에서는 5명의 멤버가 IAM, Route53, Secrets Manager, CloudWatch, CloudFront 를 주제로 발표를 진행했습니다.\n세션이 끝난 뒤에는 함께 SAA 문제를 풀고, 오답을 공유하며 학습 내용을 점검하는 시간을 가졌습니다.\n세션 1: IAM 먼저 코어 멤버 권민정 님께서 진행해주셨습니다. 이번 세션에서는 IAM(Identity and Access Management) 을 주제로, 기초 개념부터 심화 개념까지 폭넓게 다뤘습니다.\n특히, 실무와 시험(SAA) 모두에서 자주 등장하는 IAM 사용자 vs 역할, 정책 적용 방식, 최소 권한 원칙에 대해 사례와 함께 구체적으로 배울 수 있었습니다.\n세션 2: Route53 두 번째로 멤버 오혜인 님이 AWS의 DNS 웹 서비스인 Route 53에 대해 세션을 진행했습니다. Route 53의 기본 역할인 도메인 이름 관리, DNS 쿼리 처리, 트래픽 라우팅, 헬스 체크 기능을 중심으로 살펴보고, 실제로 도메인을 등록하는 과정과 요금 체계까지 정리했습니다.\n또한 Route 53이 EC2, ELB, S3 등 AWS 인프라뿐만 아니라 외부 인프라와도 연동 가능하다는 점을 함께 확인하며, 실무와 시험 모두에서 자주 활용되는 핵심 포인트들을 배웠습니다.\n세션 3: Secrets Manager 세 번째로 멤버 정다연 님이 AWS Secrets Manager에 대해 세션을 진행했습니다.\nSecrets Manager는 데이터베이스 비밀번호, API 키, 인증 토큰 등 민감한 정보를 안전하게 저장하고 관리할 수 있는 서비스로, IAM 정책 기반 접근 제어, 자동 암호화(KMS 연동), 비밀 값 자동 로테이션 기능을 제공합니다.\n이번 세션에서는 Secrets Manager의 기본 개념과 KMS와의 연동 원리를 이해하고, 하드코딩 대신 안전하게 시크릿을 관리할 수 있는 방법을 살펴보았습니다.\n세션 4: CloudWatch 네 번째로 멤버 김소망 님이 AWS의 대표적인 모니터링 서비스인 CloudWatch에 대해 세션을 진행했습니다.\nCloudWatch는 로그, 메트릭, 알람, 대시보드를 통해 리소스와 애플리케이션 상태를 모니터링할 수 있는 서비스입니다.\n이번 세션에서는 EC2 CPU 사용률을 예시로, 임계치 초과 시 알람을 받아 자동 대응(Auto Scaling, 알림 전송 등) 할 수 있는 흐름을 살펴보았으며, CloudWatch Agent와 커스텀 메트릭을 활용해 모니터링 범위를 확장하는 방법도 함께 다뤘습니다.\n이를 통해 CloudWatch가 단순 지표 확인을 넘어, 장애 탐지와 자동화된 운영 관리에 중요한 역할을 한다는 점을 배울 수 있었습니다.\n세션 5: CloudFront 다섯 번째로 멤버 김서윤 님이 AWS의 CDN 서비스인 CloudFront에 대해 세션을 진행했습니다.\nCloudFront는 전 세계 엣지 로케이션을 통해 정적·동적 콘텐츠를 사용자와 가장 가까운 위치에서 전달하여 지연 시간을 줄이고 성능을 높여주는 서비스입니다. 이번 세션에서는 오리진과 엣지 로케이션의 개념, 캐시 동작 방식, 지리적 제한(Geo Restriction)과 보안 설정 등 주요 기능을 살펴보았습니다. 이를 통해 CloudFront가 글로벌 서비스 확장과 성능 최적화에 핵심적인 역할을 한다는 점을 확인할 수 있었습니다.\n마무리 마지막으로, 멤버들이 함께 SAA 문제 5개를 풀고 오답을 공유하며 부족한 개념을 보완했고, 학습한 내용을 정리해 노션에 기록하는 시간을 가지며 세션을 마무리했습니다.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/3rd/post-4-member-session-1/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2025.09.24 / 17:00 - 19:00 진행, 숭인관 403호\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-member-session\"\u003e💡 Member Session\u003c/h2\u003e\n\u003cp\u003e지난주까지는 코어 멤버 세션이 진행되었고, 이번 주부터는 모든 멤버들이 돌아가면서 AWS의 핵심 주제를 맡아 세션을 진행하고 있습니다.\u003c/p\u003e","title":"Member Session (1)"},{"content":" 2025.09.17 / 18:00 - 20:00 진행, 숭인관 403호\n💡 Core Member Session 이번 두 번째 코어 멤버 세션에서는 스토리지, 로드 밸런싱과 오토 스케일링, RDS와 CI/CD, 그리고 AWS 아키텍처까지 클라우드의 주요 주제를 다루었습니다. 각 세션을 통해 다양한 AWS 서비스의 개념을 정리하고 실제 사례와 함께 이해할 수 있는 의미 있는 시간이었습니다.\n세션 1: 스토리지 가장 먼저 코어멤버 박슬기님이 세션을 진행했습니다.\n이번 세션에서는 AWS에서 제공하는 대표적인 스토리지 서비스인 S3, EBS, EFS, 그리고 추가 스토리지 서비스(ETC)에 대해 꼼꼼하게 설명해주셨습니다.\n특히 각각의 서비스가 언제 적합한지, 어떤 차이가 있는지 구체적인 예시와 함께 알려주셔서 이해하기 쉬웠습니다. 또 실습 이미지 자료를 많이 보여주셔서 실제로 사용하는 느낌을 받을 수 있었고, 복잡해 보이는 스토리지 개념도 훨씬 명확하게 다가왔습니다.\n세션 2: 로드 밸런싱과 오토 스케일링 두 번째로는 코어멤버 김소망님이 로드 밸런싱과 오토 스케일링을 주제로 세션을 진행하셨습니다.\nELB(Elastic Load Balancer)를 시작으로 ALB(Application Load Balancer), NLB(Network Load Balancer), 그리고 ASG(Auto Scaling Group)까지 다양한 서비스의 특징과 차이점을 비교하며 설명해주셨는데요.\n특히 각각의 서비스가 어떤 상황에서 쓰이는지 실제 아키텍처 흐름 속에서 보여주셔서 헷갈리지 않고 이해할 수 있었습니다. 귀엽고 재밌는 이미지를 중간중간 넣어주셔서 발표가 지루하지 않고 끝까지 집중할 수 있어 좋았습니다.\n세션 3: RDS \u0026amp; Github Actions 세 번째 세션은 코어멤버 오혜인님이 맡아주셨습니다.\nAWS의 대표적인 데이터베이스 서비스인 RDS와 Amazon Aurora의 차이를 비교하면서 시작해, NoSQL과 Key-Value DB, Document 기반 DB의 특징, 그리고 In-Memory DB 개념까지 차근차근 설명해주셨습니다.\n특히 AWS에서 제공하는 ElastiCache 서비스와 Redis, Memcached와의 호환성을 언급해주셔서 실제 서비스 환경에서 어떻게 활용할 수 있는지도 감을 잡을 수 있었습니다.\n또한 CI/CD의 개념과 함께 Github Actions 예시 코드를 보여주며 알기 쉽게 정리해주셨습니다. 발표가 간결하면서도 예시가 풍부해서 어려운 개념도 쉽게 다가왔습니다.\n세션 4: AWS 아키텍처 마지막으로는 캡틴 김시은님이 AWS 아키텍처 전반을 정리하며 세션을 마무리해주셨습니다.\n3-Tier Architecture를 비롯해 Serverless, Event-driven, Micro-service Architecture의 특징을 소개하고, 실제 서비스에서 자주 활용되는 다양한 배포 전략도 함께 다루었습니다.\n특히 블루-그린 배포 전략을 중심으로, 왜 이러한 방식이 안전한지, 실제 프로젝트에 어떻게 적용되는지 알기 쉽게 설명해주셨습니다. 풍부한 이미지 자료와 실제 코드 예시까지 더해져, 단순히 개념만 배우는 것이 아니라 실제 아키텍처 설계에 응용할 수 있는 인사이트를 얻을 수 있었습니다.\n마무리 이번 코어 멤버 세션은 정말 알차고 즐거운 시간이었습니다.\n발표를 준비하면서 스스로 공부한 내용을 정리하고 다른 사람들에게 설명하다 보니, 단순히 아는 것에서 그치지 않고 더 깊게 이해할 수 있었습니다. 또 다른 멤버들의 발표를 들으면서 서로 다른 시각과 설명 방식으로 같은 주제를 접하니 훨씬 폭넓게 배우는 느낌이 들었습니다.\n각 세션마다 이해를 돕기 위한 이미지, 예시 코드, 실제 사례가 풍부하게 준비되어 있어 지루할 틈이 없었고, 클라우드 서비스의 기초부터 응용까지 자연스럽게 연결되는 흐름을 따라가며 배울 수 있었습니다.\n앞으로 있을 다음 세션도 기대가 많이 되고, 멤버들과 함께 성장해가는 과정이 더욱 즐거운 것 같습니다.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/3rd/post-3-core-member-session-2/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2025.09.17 / 18:00 - 20:00 진행, 숭인관 403호\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-core-member-session\"\u003e💡 Core Member Session\u003c/h2\u003e\n\u003cp\u003e이번 두 번째 코어 멤버 세션에서는 스토리지, 로드 밸런싱과 오토 스케일링, RDS와 CI/CD, 그리고 AWS 아키텍처까지 클라우드의 주요 주제를 다루었습니다. 각 세션을 통해 다양한 AWS 서비스의 개념을 정리하고 실제 사례와 함께 이해할 수 있는 의미 있는 시간이었습니다.\u003c/p\u003e","title":"Core member session (2)"},{"content":" 2025.09.10 / 18:00 - 20:00 진행, 숭인관 403호\n💡 Core Member Session 이번 코어 멤버 세션에서는 AWS 아키텍처의 기초 개념부터 EC2와 VPC까지 클라우드의 핵심 주제를 다뤘습니다. 각 세션을 통해 AWS 인프라의 구조와 서비스 흐름을 이해하고, 기초 서비스에 대한 이해를 넓힐 수 있었습니다.\n세션 1: AWS 아키텍처 기초 먼저 캡틴 김시은님이 세션을 진행했습니다. 해당 세션에서는 AWS 인프라의 기본 단위인 리전과 가용 영역(AZ) 개념을 살펴보았습니다.\n이어 클라우드 아키텍처에서 자주 활용되는 클라이언트-서버 모델과 웹서버의 기본 동작 흐름을 설명하며, 확장성 개념인 수직적 확장(Scale Up)과 수평적 확장(Scale Out), 그리고 로드밸런싱을 통한 트래픽 분산 방식을 이해했습니다.\n마지막으로 다양한 AWS 서비스와 클라우드 아키텍처 사례를 제시했습니다.\n세션 2: EC2 컴퓨팅 서비스 다음으로 코어멤버 권민정님이 AWS의 가장 대표적이고 기초적인 서비스인 EC2에 대해 세션을 진행했습니다.\nEC2 인스턴스를 생성할 때 고려해야 하는 AMI, 인스턴스 유형, IAM 인스턴스 프로파일 등의 주요 옵션을 정리하고, 추가로 인스턴스 연결 방식과 인스턴스 구매 옵션을 함께 살펴보았습니다.\n이를 통해 인스턴스를 생성하고, 활용하는 기초적인 개념을 다룰 수 있었습니다.\n세션 3: 네트워크 및 보안 마지막 세션에서는 클라우드 아키텍처의 핵심인 네트워크와 보안을 주제로 코어멤버 김가은님이 세션을 진행했습니다.\n네트워크 부분에서는 VPC 서비스를 중심으로, 이를 구성하는 서브넷, 인터넷 게이트웨이, NAT 게이트웨이, 라우팅 테이블의 기본 역할을 설명했습니다. 또한 네트워크 ACL과 보안 그룹의 차이를 비교하며, stateless와 stateful 방식을 이해하는 시간을 가졌습니다.\n추가로 IAM 서비스를 함께 다루면서, 권한 관리와 보안 강화를 위한 핵심 개념을 익히는 것으로 세션을 마무리했습니다.\n마무리 이번 세션은 AWS 기초 개념을 정리하고 다지는 의미 있는 시간이었습니다. 적극적으로 발표 준비와 세션 진행을 맡아준 코어 멤버들 덕분에 성공적으로 세션을 마무리했습니다!\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/3rd/post-2-core-member-session-1/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2025.09.10 / 18:00 - 20:00 진행, 숭인관 403호\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-core-member-session\"\u003e💡 Core Member Session\u003c/h2\u003e\n\u003cp\u003e이번 코어 멤버 세션에서는 AWS 아키텍처의 기초 개념부터 EC2와 VPC까지 클라우드의 핵심 주제를 다뤘습니다. 각 세션을 통해 AWS 인프라의 구조와 서비스 흐름을 이해하고, 기초 서비스에 대한 이해를 넓힐 수 있었습니다.\u003c/p\u003e","title":"Core member session (1)"},{"content":" 2025.09.03 / 18:00 - 20:00 진행, 숭인관 403호\n💡 OT 2025년 9월 3일, ACC 동덕여대 3기가 첫 OT를 열고 공식적인 활동을 시작했습니다. 이번 모임은 새로운 멤버들과 함께 앞으로의 클라우드 학습 여정을 그려보는 의미 있는 시간이었습니다.\n세션 1: ACC DWU 소개 AWS Cloud Club이란? AWS Cloud Club(ACC)는 2023년부터 시작된 AWS 공식 학생 지원 프로그램입니다. AWS Cloud Club in Korea 연합에 속해 있으며, 대학별 캡틴을 중심으로 클라우드 학습 커뮤니티를 운영합니다. 이번 ACC DWU 3기는 캡틴 1명, 코어멤버 5명, 멤버 4명으로 구성된 소수 정예 팀으로 운영됩니다.\n3기 커리큘럼 소개 ACC DWU가 한 학기동안 멤버들과 함께 진행할 전체 커리큘럼을 소개했습니다.\nOpen Session (1): 캡틴과 코어멤버들이 진행하는 AWS 기초 서비스 학습 세션입니다. Case Study: 실제 기업의 AWS 아키텍처 사례를 조사하고 분석하는 팀 프로젝트입니다. Study: AWS SAA 자격증 스터디를 필수로 진행하며, 관심 분야에 따라 자율적인 스터디 그룹을 추가로 운영합니다. Open Session (2): 모든 멤버가 AWS의 15가지 핵심 서비스로 발표를 진행합니다. Open Session (3): 모든 멤버가 관심 있는 아키텍처, 분야, 프로젝트 등 자유롭게 주제를 선택해 발표를 진행합니다. AWS 연사 세션: 동덕·광운·인하·동국대학교가 함께하는 연합 세션이 예정되어 있습니다. AWS 실무자들의 세션과 네트워킹 기회를 제공합니다. Final Project: 팀별로 AWS 아키텍처를 직접 설계하고 실제로 작동하는 서비스로 구축하는 프로젝트 활동입니다. 세션 2: 홈서버에서 클라우드까지 이어서 코어 멤버 권민정님이 클라우드 입문자를 위한 기초 세션을 진행했습니다. 홈서버의 개념부터 시작하여 클라우드 서비스의 본질을 이해하는 시간이었습니다. 아래에는 발표 내용을 간단하게 정리했습니다.\n클라우드의 시작, 홈서버와 온프레미스 클라우드는 홈서버와 온프레미스 환경의 발전된 형태입니다. 직접 물리 서버를 구축하고 관리하는 온프레미스는 초기 비용이 크고 확장이 어렵다는 한계가 있었고, 클라우드는 이러한 단점을 극복하기 위해 등장했습니다.\n클라우드 서비스 모델: IaaS, PaaS, SaaS 클라우드는 공급자가 제공하는 서비스 범위에 따라 세 가지 모델로 나뉩니다.\nIaaS: 인프라(서버, 스토리지 등)를 빌려 쓰는 방식 (예: AWS EC2) PaaS: 인프라에 더해 개발 환경(OS, 런타임 등)까지 제공되는 방식 (예: AWS RDS) SaaS: 완성된 소프트웨어를 구독하여 사용하는 방식 (예: Google Drive) 클라우드의 핵심 개념 추상화와 가상화: 복잡한 물리적 하드웨어를 논리적으로 분할(가상화)하고, 사용자가 쉽게 선택할 수 있도록 단순화(추상화)하는 기술입니다. 확장성과 가용성: 필요에 따라 리소스를 유연하게 늘리거나 줄일 수 있으며, 안정적인 서비스 운영이 가능합니다. Serverless: 서버 관리의 부담 없이 코드 실행에만 집중할 수 있는 환경을 제공합니다. (예: AWS Lambda) 클라우드의 장단점과 학습 로드맵 클라우드는 유연하고 강력하지만, 비용 예측이 어렵고 공급자에게 의존하게 된다는 단점도 있습니다. 클라우드를 제대로 이해하기 위해서는 EC2, S3, VPC 등 기초 서비스를 익히고, GUI 콘솔 사용부터 시작해 최종적으로는 IaC(Infrastructure as Code)를 통한 인프라 자동화까지 단계적으로 학습해나가는 것이 좋습니다.\n마무리 이번 ACC DWU 3기는 소규모로 운영되는 만큼, 멤버들과 더 가깝게 교류하며 함께 성장하려 합니다. 앞으로 함께 활동하며 멤버들이 클라우드 시대에 필요한 핵심 역량을 갖춘 전문가로 함께 성장해나갈 것을 기대합니다!\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/3rd/post-1-ot/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2025.09.03 / 18:00 - 20:00 진행, 숭인관 403호\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-ot\"\u003e💡 OT\u003c/h2\u003e\n\u003cp\u003e2025년 9월 3일, ACC 동덕여대 3기가 첫 OT를 열고 공식적인 활동을 시작했습니다.\n이번 모임은 새로운 멤버들과 함께 앞으로의 클라우드 학습 여정을 그려보는 의미 있는 시간이었습니다.\u003c/p\u003e","title":"OT"},{"content":" 2024.9.10 - 2025.01.04 진행\n💡 Final Project Case study를 마무리한 후, final project 팀 구성을 진행했어요. 서쪽솜솜 팀: 김시은, 권민정, 조정원, 최가람, 하서정 솜솜파티 팀: 이가연, 황지민, 김민경, 이승연, 오은아 Bingo 9월 동안, 팀별 프로젝트 주제를 설정하고 팀별 빙고 활동을 진행했어요. 두 팀 모두 빙고 활동에 적극적으로 참여했으며, 팀워크를 다지고 서로를 알아가는 소중한 시간을 보냈어요! 모의 프로젝트 발표 세션 10월, 11월동안 프로젝트를 계획하고 준비하는 시간을 가졌어요. 팀 별로 프로젝트에 사용할 기술 스택, 요구사항 분석, 아키텍처 설계 등의 활동을 진행했어요. 11월 23일에는 지금까지 팀 별로 프로젝트의 진행 상황과 설계 내용을 발표하는 모의 프로젝트 발표 세션을 가졌어요. 프로젝트 개발 기말고사가 마무리된 이후, 프로젝트의 본격적인 개발을 진행했어요. 백엔드 서버와 AWS 아키텍처와의 연결부터 CI/CD 구축, 부하 테스트와 같은 심화적인 작업까지 수행했어요. 서쪽솜솜: 팝업 스토어 예약 시스템 팝업스토어 예약 오픈 시간에 순간적으로 급증하는 트래픽을 견디기 위한 유연하고 확장성 높은 아키텍처를 구성한 시스템입니다. 자신과 유사한 특성을 가진 사람의 카드 결제 데이터을 기반으로 다른 팝업 스토어를 추천받는 추천 시스템이 구성되어 있습니다. 자세한 내용은 Final Project 서쪽솜솜: 팝업 스토어 예약 시스템에서 확인해주세요. 솜솜파티: 축제 예약 플랫폼 강력한 부하를 감당할 수 있으며 안정성이 높아 견고한 아키텍처를 구성한 시스템입니다. 대규모 데이터 처리가 가능하고 정확한 메시지 송수신이 가능한 실시간 채팅 시스템을 함께 구현했습니다. 자세한 내용은 Final Project 솜솜파티: 축제 예약 플랫폼에서 확인해주세요. 마무리 final project는 오랜 시간동안 진행한 볼륨과 크기가 큰 프로젝트 활동이었어요. final project에서 대부분의 멤버들이 처음으로 AWS 아키텍처를 직접 설계하고 구성했어요. 오랜 시간동안 함께 성실하고 적극적으로 프로젝트 활동에 참여해준 멤버들 덕분에 성공적으로 final project를 모든 팀이 완성하고 발표를 진행할 수 있었습니다! ","permalink":"https://ddwu-aws-cloud-club.github.io/post/2nd/post-5-final-proj/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2024.9.10 - 2025.01.04 진행\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-final-project\"\u003e💡 Final Project\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eCase study를 마무리한 후, final project 팀 구성을 진행했어요.\n\u003cul\u003e\n\u003cli\u003e서쪽솜솜 팀: 김시은, 권민정, 조정원, 최가람, 하서정\u003c/li\u003e\n\u003cli\u003e솜솜파티 팀: 이가연, 황지민, 김민경, 이승연, 오은아\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"bingo\"\u003eBingo\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"bingo\" loading=\"lazy\" src=\"/2nd/final_proj/bingo.png\"\u003e\u003c/th\u003e\n          \u003cth\u003e\u003cimg alt=\"bingo\" loading=\"lazy\" src=\"/2nd/final_proj/bingo_1.png\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cul\u003e\n\u003cli\u003e9월 동안, 팀별 프로젝트 주제를 설정하고 팀별 빙고 활동을 진행했어요.\u003c/li\u003e\n\u003cli\u003e두 팀 모두 빙고 활동에 적극적으로 참여했으며, 팀워크를 다지고 서로를 알아가는 소중한 시간을 보냈어요!\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"모의-프로젝트-발표-세션\"\u003e모의 프로젝트 발표 세션\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"westsomsom\" loading=\"lazy\" src=\"/2nd/final_proj/westsomsom.png\"\u003e\u003c/th\u003e\n          \u003cth\u003e\u003cimg alt=\"partysomsom\" loading=\"lazy\" src=\"/2nd/final_proj/partysomsom.png\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cul\u003e\n\u003cli\u003e10월, 11월동안 프로젝트를 계획하고 준비하는 시간을 가졌어요.\u003c/li\u003e\n\u003cli\u003e팀 별로 프로젝트에 사용할 기술 스택, 요구사항 분석, 아키텍처 설계 등의 활동을 진행했어요.\u003c/li\u003e\n\u003cli\u003e11월 23일에는 지금까지 팀 별로 프로젝트의 진행 상황과 설계 내용을 발표하는 모의 프로젝트 발표 세션을 가졌어요.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"프로젝트-개발\"\u003e프로젝트 개발\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"westsomsom\" loading=\"lazy\" src=\"/2nd/final_proj/westsomsom_1.png\"\u003e\u003c/th\u003e\n          \u003cth\u003e\u003cimg alt=\"partysomsom\" loading=\"lazy\" src=\"/2nd/final_proj/partysomsom_1.png\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cul\u003e\n\u003cli\u003e기말고사가 마무리된 이후, 프로젝트의 본격적인 개발을 진행했어요.\u003c/li\u003e\n\u003cli\u003e백엔드 서버와 AWS 아키텍처와의 연결부터 CI/CD 구축, 부하 테스트와 같은 심화적인 작업까지 수행했어요.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"서쪽솜솜-팝업-스토어-예약-시스템\"\u003e서쪽솜솜: 팝업 스토어 예약 시스템\u003c/h2\u003e\n\u003cp\u003e\u003cimg alt=\"westsomsom\" loading=\"lazy\" src=\"/2nd/final_proj/westsomsom_2.png\"\u003e\u003c/p\u003e","title":"Final Project -  최종 프로젝트 발표"},{"content":" DDWU ACC 2nd Final Project Team 1 west-somsom (서쪽솜솜) https://github.com/orgs/west-somsom/repositories\n프로젝트 소개 팝업 스토어를 이용하려는 사용자가 다양한 정보를 탐색하고 예약 및 소통을 원활하게 진행할 수 있도록 지원하는 통합 플랫폼\n주요 기능 사용자 관리 카카오 소셜 로그인을 통한 간편 로그인 사용자 정보 등록, 조회 및 수정 팝업 스토어 정보 관리 팝업 스토어 등록 팝업 스토어 정보 전체 목록 조회 및 상세 조회 이름 및 카테고리 기반 검색 채팅을 통한 소통 지원 예약 등록 시점에 채팅방 함께 개설 팝업 스토어 당 한 개의 1 : N 채팅방 텍스트 채팅 예약 관리 예약 신청 예약 중 사용자의 현재 순번 실시간 확인 예약 내역 조회 예약 취소 및 삭제 알림 전송 예약 즉시 예약 확인 이메일 알림 전송 예약일 하루 전(오후 3시) 예약 확인 알림 전송 아이템 기반 사용자 맞춤형 추천 사용자 프로필 및 카드 결제 내역 데이터를 기반으로 개인화된 팝업 스토어 추천 제공 아키텍처 설계 설계 핵심 팝업 스토어 예약 서비스는 예약 오픈 시점에 대량의 사용자 접속 발생 특정 기간 동안 사용자 트래픽 폭증 → 트래픽 부하 분산 및 관리 필요 사용자 데이터의 무결성과 서비스 안정성을 보장하기 위해 Multi-AZ 기반의 이중화 구성이 필요 아키텍처 설계 및 구성 Infra 전반적인 구성 Public과 Private으로 분리하여 외부 사용자가 접근하는 네트워크와 데이터가 저장된 네트워크 분리 Public Subnet 외부 트래픽 처리 Private Subnet에 위치한 인스턴스 접근을 위해 Bastion host 설정 Private Subnet에 위치한 인스턴스의 인터넷 사용을 위해 NAT Instance 설정 Private Subnet 데이터베이스와 캐시, 애플리케이션 서버 등 민감한 데이터가 저장된 자원을 배치 Bastion Host를 통해 간접적으로 접근 가능 트래픽 분산 서비스의 안정성을 위해 2개의 가용 영역 사용 ALB를 통한 인스턴스 부하 분산 Auto Scaling 설정 및 ALB 대상 그룹 지정 기능 팝업 스토어 정보 등록 및 조회 기능 구현\nRedis OSS with ElastiCache 활용 등록 기능 팝업 스토어 정보를 DB와 Redis에 동시에 저장하여 조회 속도 최적화 등록 시, Redis 캐시에 중복 데이터가 저장되지 않도록 유효성 검사를 추가로 수행 조회 기능 전체 정보 조회 시 Redis에서 우선 데이터 조회 캐시 미스 발생 시 DB에서 데이터를 조회하고, 이를 Redis에 저장 현재 채택 방식 조회 기능은 RDS 직접 조회 방식을 사용 중으로, 캐시를 활용한 방식은 향후 효율성을 검토해 개선 예정 예약 알림 기능 구현\nEventBridge Scheduler → SQS → Lambda → SES 연결 구조 예약 시 사용자 이메일로 예약 관련 내용이 발송 Spring Boot 서버에서 EventBridge Scheduler를 생성하기 위한 SDK를 호출 생성된 Scheduler가 SQS로 메시지를 전송 SQS 메시지가 Lambda Trigger를 통해 Lambda 실행 Lambda에서 SES 이메일 발송을 위한 SDK를 호출 Scheduler 생성 시 전달한 파라미터의 내용이 SES를 통해 이메일로 전송 예약 기능 구현\nRedis OSS with ElastiCache 사용 예약 가능 인원수 제한을 위해 슬롯 초기화(10개) 사용자 예약 요청 처리 Redis의 Set을 사용해 사용자가 이미 대기열에 있는지 또는 예약 요청을 보낸 적이 있는지 확인 확인 후 Redis 대기열(List)에 추가 Redis Pub/Sub(Publish/Subscribe)를 통해 실시간으로 예약 처리 초반에는 스케줄러를 사용하였으나 이후 성능 개선을 위해 Redis Pub/Sub 도입 → 유의미한 성능 개선\nRedis Pub/Sub 방식\nRedis에서 제공하는 실시간 이벤트 기반 비동기 메시징 시스템\n메시지를 발행하고 이를 구독하는 애플리케이션 간 실시간 메시지 전달\n예약 요청이 들어오면 메시지를 Redis 채널에 발행\n`redisTemplate.convertAndSend(channel, message);` Redis는 해당 채널 구독 중인 구독자에게 메시지 전달\n메시지를 수신한 후 예약 요청 처리\n```jsx @Override public void onMessage(Message message, byte[] pattern) { String channel = new String(pattern); String receivedMessage = new String(message.getBody()); log.info(\u0026quot;Received message: {} from channel: {}\u0026quot;, receivedMessage,channel); // 예약 처리 로직 실행 processReservation(receivedMessage); } ``` 예약 가능 슬롯키 확인 후 순서대로 예약 처리\n중복 예약을 막기 위해 예약한 사용자를 Redis에 추가\nTTL 만료 설정을 팝업 스토어 예약 기간 동안 유지 예약 취소 시 Redis에서 슬롯 수 업데이트 및 사용자 Redis 중복 확인 데이터에서 제거 Back-End 소셜 로그인 서비스 카카오 오픈 API를 활용한 소셜 로그인/로그아웃 구현 흐름 로그인 흐름: 카카오 로그인 요청 → 콜백으로 인증 코드 수신 → 액세스 토큰 발급 → 사용자 정보 조회 및 저장 정보 업데이트: API를 통해 사용자 정보를 수정 및 유지 카카오 인증 및 사용자 정보 관리 카카오 로그인 URL 생성 : https://kauth.kakao.com/oauth/authorize를 활용해 로그인 요청 URL 생성 액세스 토큰 발급 : 사용자 인증 후 받은 code로 카카오 API에서 토큰 요청 사용자 정보 조회 : 액세스 토큰으로 사용자 정보 조회 후 DB에서 저장 및 세션 생성 콜백 및 사용자 정보 갱신 카카오 로그인 콜백: 토큰 및 사용자 정보 처리 후 성공 메시지 반환 사용자 정보 업데이트: 전화번호, 성별, 나이 등 사용자 정보를 업데이트(추가적으로 입력받음)하고 DB 및 세션 동기화 사용자 정보 API 사용자 정보 조회: 특정 사용자의 정보를 DB에서 검색 및 반환 사용자 정보 수정: 입력된 정보만 선택적으로 업데이트 추천 서비스 구매 데이터 기반 팝업 스토어 추천\n접근 방식:\n협업 필터링(collaborative filtering)과 아이템 기반 코사인 유사도(cosine similarity) 활용 Precision@K, Recall@K, F1-Score 등의 평가 지표를 사용하여 성능 검증 협업 필터링 코사인 유사도 목적 사용자 및 아이템 간 유사성을 바탕으로 추천 두 품목의 구매 패턴 방향성을 기반으로 유사성 측정 장점 데이터 패턴 분석을 통한 직관적 추천 구매 금액의 크기보다 패턴에 집중, 희소 행렬에 적합 사용 이유 대규모 사용자와 다양한 아이템 조합을 다룰 수 있음 효율적 계산과 사용자 구매 패턴 유사성 확인 데이터 개요:\n데이터 크기: 118,176개의 구매 기록과 10개의 특성 (성별, 나이, 구매금액 등) 사용자 ID를 입력받아, 유사도 기반 상위 N개 추천 품목을 출력하는 방식 사용자 ID는 주소, 성별, 나이를 결합해 생성 구매 금액은 추천 점수 계산에 사용 시각화 및 통찰: 추천 시스템의 구매 분석 결과\n성별 분석: 여성 사용자가 남성보다 높은 구매 금액을 기록 연령대별 구매 경향: 30대 사용자층이 가장 높은 구매력을 보임 시간대 분석: 주말 구매가 주중보다 많으며, 오후 구매가 오전보다 높음 품목별 구매 경향: 특정 품목 카테고리의 구매 금액 비중이 높음 월별 매출 추이: 계절별 매출 변화 확인 고빈도 고객 분석: 상위 5명의 고빈도 구매 고객 식별 → 활용 방안 💡 : 해당 고객을 타겟으로 한 로열티 프로그램 기획 가능 성능 평가 결과\nPrecision@K: 추천 품목 중 실제 구매한 품목 비율 Recall@K: 실제 구매 품목 중 추천된 품목 비율 F1-Score: Precision과 Recall의 조화 평균 결과: 우수한 Precision@3(0.8020 → 80% 정확도)를 보임 팝업 스토어 예약 시스템 적용\n사용자 정보(지역, 성별, 나이)를 통해 사용자 ID 생성 및 추천 결과 반환 추천 결과를 통해 사용자에 맞는 팝업 스토어를 화면에 띄워 사용자의 클릭 유도 예약 서비스 List와 Set을 결합하여 Redis 대기열 사용 Redis Pub/Sub를 사용하여 예약 처리 자동화 날짜와 시간대 별로 정해진 인원수만 선착순으로 처리 Redis에서 예약 가능한 인원수 확인 대기열에서 순서대로 예약을 처리하고 슬롯 데이터 업데이트 Redis 키에 TTL을 설정하여 예약 가능 기간 종료 후 데이터 자동 삭제 예약 시 중복 여부를 확인해 무분별한 요청 방지 어플리케이션 구성(100명이 요청하는 경우) 100명의 사용자가 특정 날짜의 특정 시간대에 예약 요청 100명의 사용자는 요청 순서대로 대기열에 등록 중복으로 예약 요청을 넣을 수 없도록 Redis에 등록 스케줄러가 동작하여 대기열에 있는 사용자 예약 처리 성공 시 선착순으로 10명씩 예약 성공 실패 시 “예약이 마감되었습니다.”라는 응답 반환 대기 시간 동안 현재 자신의 순번과 뒤에 남은 사람 수 확인 가능 위의 과정을 통해 이벤트 종료(특정 시간대에 10명 예약 성공) 채팅 서비스 WebSocket을 활용한 실시간 채팅 기능 WebSocket을 사용하여 클라이언트와 서버 간 실시간 양방향 통신 구현 Spring WebSocket 을 통해 채팅 메시지의 입장, 퇴장, 채팅 내용을 실시간으로 주고받을 수 있도록 처리 WebSocket 연결 및 메시지 전송 및 저장 흐름 클라이언트가 WebSocket 연결을 요청하면, WebSocketHandler 에서 연결을 수립하고, 연결 성공 메시지를 클라이언트에 전송 클라이언트에서 채팅 메시지를 전송하면, 이를 ChatMessageDto 객체로 변환하여 처리하고, 메시지 유형(입장, 채팅, 퇴장)에 맞게 적절한 처리를 수행 입장 (JOIN) 메시지는 해당 팝업 스토어에 참여한 세션을 관리하는 popupStoreSessions 맵에 세션을 추가 채팅 (TALK) 메시지는 Message 객체로 변환하여 DB에 저장하고, 모든 연결된 클라이언트에 실시간으로 메시지를 전송 퇴장 (LEAVE) 메시지는 해당 팝업 스토어의 세션에서 연결을 종료 채팅 메시지 조회 해당 스토어에 속한 모든 메시지를 조회하여 반환 검색 서비스 QueryDSL을 사용해 팝업스토어 검색 기능 구현 이름, 팝업스토어 시작일, 마감일, 위치 값을 쿼리스트링으로 입력해 검색 카테고리 값을 쿼리스트링으로 입력해 검색 기능 시연 https://drive.google.com/file/d/1np6pBRT7CSKuDsdFETkB0GAE_jj3KigE/view?usp=sharing 성능 테스트 1. 스모크 테스트 목적: 주요 기능이 정상 작동하는지 확인하는 간단한 테스트\n가상 사용자 수: 50명 최소한의 사용자 수로 주요 기능을 빠르게 확인 지속시간: 3분 시스템이 정상 동작을 보장하는지 빠르게 검증 피크타임, 램프업, 다운 여부 및 조건: 램프업: 1분 동안 0명 → 50명 피크타임: 1분 다운: 1분 동안 50명 → 0명 사용 시나리오: 팝업 스토어 정보 전체 조회: 데이터를 정상적으로 불러오는지 확인 예약 신청: 예약 데이터가 정상적으로 들어가는지 확인 현재 순번 확인: 예약 관련 데이터가 올바르게 표시되는지 검증 응답 성공률: 100% 주요 기능의 정상 작동 확인 http_req_duration 평균 요청 시간: 18.28ms http_reqs 초당 요청 처리량: 초당 95건 iteration_duration 평균 반복 시간: 1.05s 2. 부하 테스트 목적: 시스템의 최대 처리량을 파악하고 성능 병목 현상을 진단\n가상 사용자 수: 5000명 예상되는 최대 사용량 근처에서 테스트 지속시간: 10분 실제 사용 환경을 가정해 안정성을 확인 피크타임, 램프업, 다운 여부 및 조건: 램프업: 2분 동안 0명 → 5000명 피크타임: 6분 다운: 2분 동안 5000명 → 0명 사용 시나리오: 팝업 스토어 정보 전체 조회: 데이터 조회 요청이 많은 상황에서 성능 확인 검색: 다수의 검색 요청을 처리할 수 있는지 검증 팝업 스토어 정보 상세 조회: 여러 데이터 요청에 대한 복원력 확인 예약 신청: 동시다발적인 예약 생성 요청 처리 여부 확인 응답 성공률: 99.98% http_req_duration 평균 요청 시간: 6.17s http_reqs 초당 요청 처리량: 초당 362건 iteration_duration 평균 반복 시간: 31.28s 3. 스파이크 테스트 목적: 짧은 시간 동안 갑작스러운 사용량 증가에 대한 시스템의 복원력 확인\n가상 사용자 수: 10000명 극단적인 부하 상황을 가정 지속시간: 3분 단시간 내 급격한 부하 처리 및 안정성 확인 피크타임, 램프업, 다운 여부 및 조건: 램프업: 1분 동안 0명 → 10000명 피크타임: 1분 다운: 1분 동안 10000명 → 0명 사용 시나리오: 검색: 갑작스러운 검색 요청 폭주 시 성능 확인 팝업 스토어 정보 상세 조회: 여러 데이터 요청에 대한 복원력 확인 예약 신청: 갑작스러운 예약 요청 폭주 시 안정성 검증 redis pub/sub 적용 전\nredis pub/sub 적용 후\nredis pub/sub 적용으로 유의미한 성능 개선 확인\n응답 수신 시간(http_req_receiving) 크게 개선\nhttp_req_receiving 적용 전 적용 후 avg 1.36ms 708.93μs 서버-클라이언트 간 불필요한 전송 데이터 양 감소\n적용 전 적용 후 data_received 208MB 94MB 개선할 점 팝업 스토어 전체 조회 Redis 사용 전략 설정 도입 배경 기존 DB 직접 조회 방식에서, \u0026ldquo;connection timeout\u0026rdquo; 오류 발생: read tcp 192.168.1.6:58959-\u0026gt;15.164.35.224:80: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.\u0026quot; 원인은 대량 조회로 인한 DB 부하로 추정, 이를 해결하기 위해 캐시(Redis)를 통한 조회 도입 변경 내용: 팝업 스토어 등록 시 캐시에 저장 → 전체 조회는 캐시에서 처리 문제점 캐시 미스 시 DB 조회 및 캐시 저장 과정 추가로, 단순 DB 조회보다 비효율적, 성능 저하 개선 방향 캐시 도입시 캐시 전략 최적화 필요 자주 조회되는 데이터 우선 캐싱 캐시 적중률 향상을 위한 TTL(Time-to-Live) 및 데이터 구조 개선 EC2 접근을 위해 Bastion host 사용 Bastion host 대신 System Manager Session Manager 도입을 통해 보다 더 안전한 접근 관리 필요 CI/CD 파이프라인 부재 현재 배포 방식: 빌드 파일 생성 및 Filezilla를 통한 수동 배포 적절한 CI/CD 파이프라인 구축 필요 github action + ECR 등의 파이프라인 구축 가능 Auto Scaling 정책 부재 정책 설정의 필요성 성능 테스트 시 인스턴스의 컴퓨터 자원에 따라 결과가 다르게 나타남 적절한 동적 크기 조정 정책 필요 Auto Scaling Group의 CPUUtilization을 경보로 설정한 단계 크기 정책 필요 개선사항 백엔드 개선 검색 기능 category 검색 기능인덱스 설정 no offset 적용 채팅 기능 웹소켓 기반 단일 서버 구조 → Redis Pub/Sub 적용 다중 서버 간 메시지 동기화 가능 팝업 스토어 전체 정보 조회 기능 no offset 적용 예약 기능 지수 백오프 알고리즘 추가 예약 데이터 저장 실패 가능성 고려 Redis Pub/Sub 적용 기존의 스케줄러 방식보다 실시간성 개선 인프라 개선 Route53 + ACM 적용\nECS 클러스터 도입\nCI/CD 파이프라인 구축 컨테이너화 Bastion host → Instance connect endpoint 수정\nSession Manager는 비용이 많이 들어 대신 Instance connect endpoint를 도입하기로 결정 Bastion host보더 더 안전하게 접근 CloudWatch 지표 + 경보 설정\nECS 컨테이너 인스턴스(EC2)에 CloudWatch Agent 설치 및 메모리 지표 확인 ECS Cluster의 CPUUtilization 지표를 통한 경보 설정 경보 지표 시간 조건 scale-out ECS CPUUtilization 1분 80% 이상 (최대), 2번 체크 scale-in ECS CPUUtilization 10분 10% 이하 (평균) Auto Scaling 크기 조정 정책 설정\nCloudWatch 경보를 바탕으로 EC2 ASG, ECS Service에 단계 조정 정책 설정 ","permalink":"https://ddwu-aws-cloud-club.github.io/post/2nd/post-6-final-proj-west-somsom/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eDDWU ACC 2nd Final Project Team 1 west-somsom (서쪽솜솜)\u003c/strong\u003e\n\u003ca href=\"https://github.com/orgs/west-somsom/repositories\"\u003ehttps://github.com/orgs/west-somsom/repositories\u003c/a\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch1 id=\"프로젝트-소개\"\u003e프로젝트 소개\u003c/h1\u003e\n\u003chr\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e팝업 스토어를 이용하려는 사용자가 다양한 정보를 탐색하고 예약 및 소통을 원활하게 진행할 수 있도록 지원하는 통합 플랫폼\u003c/strong\u003e\u003c/p\u003e","title":"Final Project 서쪽솜솜: 팝업 스토어 예약 시스템"},{"content":"서비스 소개 사용자가 축제를 쉽고 직관적으로 예약하고, 참여자들과 정보를 공유하며 실시간 소통할 수 있는 종합 축제 예약 플랫폼.\n서비스 주요 기능 회원가입/로그인 기본 정보(이메일, 비밀번호, 이름)를 입력하여 간편하게 회원가입할 수 있으며, 가입한 계정을 통해 서비스 이용 가능 축제 정보 제공 축제 이름, 시작일과 종료일, 상세 설명 등 축제에 대한 전반적인 정보를 한눈에 확인할 수 있도록 제공. 축제 예약 원하는 축제를 쉽고 빠르게 예약할 수 있으며, 대기열 페이지를 통해 실시간으로 예약 순서를 확인할 수 있도록 구성. 채팅 시스템 실시간으로 소통하며 정보를 공유할 수 있는 채팅 기능을 제공. 축제 검색 최신 축제 정보를 탐색하거나 사용자가 입력한 키워드를 통해 원하는 축제를 빠르게 검색할 수 있도록 지원. 마이페이지 사용자가 예약한 축제와 참여 중인 채팅방을 확인하고 관리할 수 있도록 지원. 축제 알림 예약한 축제가 시작되기 하루 전에 푸시 알림을 제공. 기술 스택 📚 Tech Stack Spring Boot Spring JPA Spring Security JAVA JWT AWS SQS Kafka Stomp AWS Cognito Firebase Cloud Messaging AWS EventBridge AWS SNS AWS SQS 🔩 DB MySQL (AWS RDS) Redis (AWS ElastiCache) DynamoDB 🗜 DevOps AWS EC2 AWS Application Load Balancer AWS Auto Scaling AWS Code Delploy GitHub Actions Docker 프로젝트 산출물 API 명세서 기능 API URI HTTP Method 회원가입 /signup POST 회원가입 이메일 인증 /confirm-signup POST 로그인 /login POST 로그아웃 /signout POST 토큰 유효성 검사 /verify-token GET 토큰 갱신 /refresh-token POST 페스티벌 생성 /festivals/create POST 페스티벌 목록 조회 /festivals GET 페스티벌 세부 정보 조회 /festivals/{festivalId} GET 페스티벌 검색 /festivals/search GET 티켓 예매 /reservations POST 내 예약 목록 조회 /reservations GET 채팅방 참여 /festivals/chatting/{chatRoomId}/join POST 채팅방 진입 /festivals/chatting/{chatRoomId} GET 참여 중인 채팅방 목록 조회 /festivals/chatting/list GET 채팅방 나가기 /festivals/chatting/delete DELETE FCM 토큰 비활성화 /notification/deactivate POST FCM 토큰 활성화 /notification/activate POST 대기열 등록 /queues/{queue}/waiting-room/users/{email} GET 대기열에서 유저 순위 반환 /queues/{queue}/users/{email}/rank GET 예약 페이지 진입 가능 여부 반환 /queues/{queue}/users/{email}/allowed GET 대기열 탈퇴 /queues/{queue}/users/{email}/leave DELETE 대기 완료열 탈퇴 /queues/{queue}/users/{email}/leave-proceed DELETE ERD 아키텍처 설계 오토스케일링 그룹과 ALB를 활용해 고가용성과 확장성을 지닌 아키텍처 구성 EC2, RDS, ElasticCache 와 같은 리소스는 멀티 AZ 배포를 해 단일 장애점을 방지 데이터베이스와 브로커는 EC2와 다른 프라이빗 서브넷에 배치함으로써 EC2로만 접근이 가능해 보안이 향상 CI/CD Back-End Github Action, AWS ECR, Code Deploy를 활용한 Blue/Green 무중단 배포 파이프라인 구성 Blue/Green이란 대체 인스턴스(Green)를 생성해 배포하는 과정에서 원본 인스턴스(Blue)를 유지하고, 배포가 완료되면 트래픽을 전환한 후 Blue 그룹을 안전히 제거함으로써 배포 과정에서 서버가 중단되지 않는 배포 방식 여러 명이 동시에 작업 중일 때도 배포로 인해 서버가 중단되지 않아 개발 효율이 증진됨 Front-End 정적 파일(S3 + CloudFront)은 CI/CD 파이프라인에서 GitHub Actions를 활용해 자동으로 S3에 업로드하고, CloudFront의 캐시를 무효화하는 방식으로 무중단 배포를 구현 백엔드 서버(다른 origin)로 요청을 날릴 수 없기 때문에, Origins 설정에 ACM을 적용한 Application Load Balancer(이하 ALB)를 연결해 주고 요청은 ALB를 통해 EC2로 전달하도록 설정하여 Mixed Content 에러 해결 기능 설명 대기열 시스템 AWS SQS + Redis를 이용한 대기열 시스템 대기열 시스템은 클라이언트가 요청을 보낼 때 이를 차례대로 처리함으로써 서버 과부하를 방지하고 안정적인 서비스를 제공하는 데 핵심적인 역할을 합니다. 특히, 티켓팅과 같이 특정 시간에 요청이 집중되는 상황에서는 대기열 시스템이 필수적입니다. 이를 효율적으로 구현하기 위해 AWS SQS와 Redis를 함께 활용했습니다.\nRedis\n실시간 대기열 순서 관리 유저들의 대기 상태 관리 Redis Sorted Set이란?\nkey 하나에 여러 개의 score와 value로 구성되는 자료구조입니다. value는 score로 sort되며 중복되지 않습니다. 프로젝트 설정\nKey: Festival 정보 Value: 사용자 이메일 Score: 대기열에 입장한 시간을 유닉스타임(m/s) 값으로 설정 SQS\n대기 처리와 관련된 메시지를 비동기적으로 처리하는 역할을 담당 대기열의 상태 변화를 큐를 통해 안정적으로 처리 대기열 시스템을 통해 위와 같이 사용자들이 자신의 현재 대기 번호를 실시간으로 확인할 수 있습니다.\n요청 흐름\n유저가 대기열에 있는 경우 최초 요청 시: 유저는 Redis의 Sorted Set을 이용한 대기열에 등록됩니다. 이때 대기열에 유저가 성공적으로 등록되면, 해당 유저는 대기열 내에서 순위가 부여됩니다. SqsSender의 send() 메서드를 통해 SQS로 대기열에 유저가 등록되었다는 메시지를 전달합니다. 재요청 시: 유저가 재요청을 하면, 먼저 해당 유저가 대기열에 있는지 확인하고, 대기열에 있다면 대기표(대기 순위)를 반환합니다. 대기열에서 유저 스캔 및 입장 허용: 일정 시간(SQS의 지연 시간)이 지난 후, SQS로부터 응답이 오면 대기열에서 유저들을 스캔하여 순차적으로 10명씩 대기 완료 열로 이동시킵니다. 유저가 대기완료 열로 이동한 경우 재요청 시: 유저가 대기열에 없다면, 순번이 -1 로 반환되어 유저는 대기열에 없는 상태로 처리됩니다. -1을 받은 유저는 대기완료 열에 유저의 존재 여부를 다시 확인하기 위한 요청을 보냅니다. 대기완료 큐에 유저가 존재한다면, 해당 유저는 대기열을 통과했음을 의미하므로 예약 페이지로 이동하여 예약을 진행할 수 있습니다. 부하 테스트: K6 최대 사용자: 1000명 램프 업: 1000명의 사용자에 도달할 때까지 30초마다 100명의 사용자 추가 테스트 시나리오: 대기열 입장 → 5초 마다 rank 응답 반환 → 대기 완료 열로 이동 → 타겟 페이지로 이동 후 대기 완료 열에서 제거(사용자 점차 감소) 결과 평균 응답 시간: 1.28s 응답 시간이 9.55s까지 늘어날 수 있다는 점이 있음. 성능 최적화 필요 요청 실패율: 0% 지연 시간 = 1.28초 - 1.27초 = 0.01초 네트워크 지연 등을 포함한 최대 시간으로, 0.01초로 짧은 것으로 나타남 처리량 = 56,045 / 308.8 ≈ 181.48 RPS 낮은 처리량 개선 필요 - 불필요한 반복 요청 줄이기(캐싱 or 웹소켓을 사용해 서버에서 실시간으로 업데이트), 서버 성능 최적화 필요 예약 기능 비관적 락(Pessimistic Lock) 적용 1 2 3 4 5 6 7 8 9 10 11 12 13 14 @Override @Transactional public ReservationResponseDTO.makeReservationResultDTO makeReservation(Long userId, ReservationRequestDTO.makeReservationDTO request) { Ticket ticket = ticketRepository.findByFestivalIdAndFestivalDateWithLock(request.getFestivalId(), request.getFestivalDate()).orElseThrow(() -\u0026gt; new CustomException(ErrorCode.TICKET_NOT_FOUND)); } // ------------------------------------------------------------ public interface TicketRepository extends JpaRepository\u0026lt;Ticket, Long\u0026gt; { @Lock(LockModeType.PESSIMISTIC_WRITE) @Query(\u0026#34;SELECT t FROM Ticket t WHERE t.festival.id = :festivalId AND t.festivalDate = :festivalDate\u0026#34;) Optional\u0026lt;Ticket\u0026gt; findByFestivalIdAndFestivalDateWithLock(@Param(\u0026#34;festivalId\u0026#34;) Long festivalId, @Param(\u0026#34;festivalDate\u0026#34;) LocalDate festivalDate); } 공유 자원인 Ticket를 TicketRepository에서 불러올 때, @Lock 어노테이션을 사용하여 비관적 쓰기 락(PESSIMISTIC_WRITE LOCK)을 적용했습니다. 이를 통해 한 트랜잭션이 이 Ticket를 읽고 수정하는 동안 다른 트랜잭션이 접근하지 못하게 하여 동시성 문제를 방지하고, 데이터의 무결성을 유지했습니다. 검색 기능: ElastiCache와 Redis를 활용한 성능 개선 AWS ElastiCache란?\nAWS에서 제공하는 완전 관리형 캐싱 서비스로, Redis나 Memcached 같은 오픈소스 캐시 엔진을 기반으로 동작\n데이터 접근 속도를 높이고 애플리케이션 성능을 향상시키는 데 최적화\n검색 동작 흐름\nRedis에서 캐시 조회 캐시된 검색 결과가 있으면 반환 캐시에 검색 결과가 없는 경우 DB에서 검색 → 결과를 Redis에 캐싱한 뒤 반환 캐시 설정 및 전략\n캐싱 TTL(Time-To-Live): 10분 최신 데이터를 유지하면서 불필요한 캐싱 비용 및 메모리 사용량을 줄이기 위함 캐시 무효화 전략 새로운 축제 데이터 생성 시 관련 캐시를 삭제하여 DB 데이터와 캐시 데이터 간 일관성을 보장 성능 테스트 결과\n테스트 환경 100개의 축제 데이터를 대상으로 특정 키워드 검색 API를 100번 호출 결과 캐시 적용 전: 0.91초 캐시 적용 후: 0.63초 성능 약 0.28초 개선 회원가입/로그인 AWS Cognito + Spring Security + JWT AWS Cognito는 사용자 인증, 권한 부여, 사용자 관리를 위한 클라우드 서비스이며, 인증 토큰 발행을 통해 사용자 인증을 간편하게 처리할 수 있습니다. Cognito가 발급한 JWT 토큰을 Spring Security가 검증하도록 하여 보안 정책을 적용하였습니다.\n시연\n회원가입 로그인, 로그아웃 웹 푸시 알림 초기 설계\nEventBridge → API 호출 → 서버 내 푸시 알림 전송\n단점\n서버 리소스 집중 알림 대상자가 많아질수록 서버 부하 증가. 서비스 결합도 EventBridge가 API와 직접 연결되어 있어, API 구조 변경 시 EventBridge 설정도 수정이 필요. 확장성 부족 다른 알림 채널(이메일, SMS 등)로 확장하려면 추가 개발 필요. 최종 설계\nEventBridge → SNS → SQS → SNS로 푸시 알림 전송\n보완된 점\n내결함성 강화 SQS가 메시지를 대기열에 저장하기 때문에, 서버가 다운되더라도 메시지가 유실되지 않음. 서버 부하 감소 알림 전송 작업을 SNS로 위임하여, SNS가 실제 알림 메시지를 전송. 서비스 결함도 감소 EventBridge와 SQS가 직접적으로 결합되지 않고, SNS가 이를 연결함. SNS는 다중 구독자를 지원하기 때문에 이메일, Lambda 등 다양한 채널로 메시지 전송 가능. 시연\n채팅 시스템 Kafka \u0026amp; Stomp \u0026amp; DynamoDB \u0026amp; Redis 기반 채팅 시스템 분산 서버 환경에서 채팅 시스템의 요구사항은 다음과 같습니다.\n실시간으로 메세지를 송수신 해야 합니다. 메세지의 정확성을 보장 해야 합니다. 대규모 데이터인 메세지를 빠르게 로드 해와야 합니다. 이 3가지 조건을 각각 다음과 같은 구성으로 만족시켰습니다.\n1. 실시간 메세지 송수신 채팅에 자주 사용되는 STOMP를 사용해 구현했습니다.\n기본적으로 STOMP는 내장 메세지 브로커를 사용해 메세지 상태(순서, 채팅방 등)을 서버 메모리에 저장합니다. 그러나 분산 서버 환경에선 서버 간 구독 정보가 공유되지 않기 때문에 내장 메세지 브로커를 사용할 수 없습니다. 따라서 분산 서버 환경에선 중앙 집중 메세지 브로커가 필요합니다.\n2. 메세지 정확성 보장 \u0026amp; 병렬 처리로 처리량 극대화 분산 서버 환경에서 메세지의 순서, 채팅방 등 정확성을 보장하기 위해 중앙 집중 메세지 브로커인 카프카를 도입했습니다. STOMP의 메세지 브로커 역할을 카프카가 대신함으로써 분산된 서버의 각 사용자들에게 정확하게 메세지를 전달할 수 있게 되었습니다. 또한, 카프카의 특성인 파티션과 컨슈머 그룹을 이용해 메세지를 병렬로 처리하기 때문에 대규모 트래픽을 안정적으로 처리할 수 있게 되었습니다.\n3. 대규모 데이터 로드 채팅 메세지 내역은 대규모 데이터이기 때문에 RDS만으로는 빠른 처리가 불가하다고 판단했습니다. 따라서 Key-Value 기반의 DynamoDB에 메세지 데이터를 저장하여 빠르게 데이터를 로드해오게 구현하였습니다.\n+ 추가 기능 구현 읽지 않은 메세지 알림을 구현하였습니다. 이를 위해 채팅방 온라인 유저와 오프라인 유저를 구별해야 했는데, 이는 채팅방 입장/퇴장 시마다 호출되는 메서드이어야 하므로 빠른 처리와 RDS 부하 감소가 필수였습니다. 따라서 Redis로 온라인/오프라인 유저와 알림 개수를 계산하게 구현하였습니다.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/2nd/post-7-final-proj-party-somsom/","summary":"\u003ch1 id=\"서비스-소개\"\u003e서비스 소개\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e사용자가 축제를 쉽고 직관적으로 예약하고, 참여자들과 정보를 공유하며 실시간 소통할 수 있는 종합 축제 예약 플랫폼.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"서비스-주요-기능\"\u003e서비스 주요 기능\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e회원가입/로그인\n\u003cul\u003e\n\u003cli\u003e기본 정보(이메일, 비밀번호, 이름)를 입력하여 간편하게 회원가입할 수 있으며, 가입한 계정을 통해 서비스 이용 가능\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e축제 정보 제공\n\u003cul\u003e\n\u003cli\u003e축제 이름, 시작일과 종료일, 상세 설명 등 축제에 대한 전반적인 정보를 한눈에 확인할 수 있도록 제공.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e축제 예약\n\u003cul\u003e\n\u003cli\u003e원하는 축제를 쉽고 빠르게 예약할 수 있으며, 대기열 페이지를 통해 실시간으로 예약 순서를 확인할 수 있도록 구성.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e채팅 시스템\n\u003cul\u003e\n\u003cli\u003e실시간으로 소통하며 정보를 공유할 수 있는 채팅 기능을 제공.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e축제 검색\n\u003cul\u003e\n\u003cli\u003e최신 축제 정보를 탐색하거나 사용자가 입력한 키워드를 통해 원하는 축제를 빠르게 검색할 수 있도록 지원.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e마이페이지\n\u003cul\u003e\n\u003cli\u003e사용자가 예약한 축제와 참여 중인 채팅방을 확인하고 관리할 수 있도록 지원.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e축제 알림\n\u003cul\u003e\n\u003cli\u003e예약한 축제가 시작되기 하루 전에 푸시 알림을 제공.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch1 id=\"기술-스택\"\u003e기술 스택\u003c/h1\u003e\n\u003ch3 id=\"-tech-stack\"\u003e📚 \u003cstrong\u003eTech Stack\u003c/strong\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eSpring Boot\u003c/li\u003e\n\u003cli\u003eSpring JPA\u003c/li\u003e\n\u003cli\u003eSpring Security\u003c/li\u003e\n\u003cli\u003eJAVA\u003c/li\u003e\n\u003cli\u003eJWT\u003c/li\u003e\n\u003cli\u003eAWS SQS\u003c/li\u003e\n\u003cli\u003eKafka\u003c/li\u003e\n\u003cli\u003eStomp\u003c/li\u003e\n\u003cli\u003eAWS Cognito\u003c/li\u003e\n\u003cli\u003eFirebase Cloud Messaging\u003c/li\u003e\n\u003cli\u003eAWS EventBridge\u003c/li\u003e\n\u003cli\u003eAWS SNS\u003c/li\u003e\n\u003cli\u003eAWS SQS\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"-db\"\u003e🔩 \u003cstrong\u003eDB\u003c/strong\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eMySQL (AWS RDS)\u003c/li\u003e\n\u003cli\u003eRedis (AWS ElastiCache)\u003c/li\u003e\n\u003cli\u003eDynamoDB\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"-devops\"\u003e🗜 \u003cstrong\u003eDevOps\u003c/strong\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eAWS EC2\u003c/li\u003e\n\u003cli\u003eAWS Application Load Balancer\u003c/li\u003e\n\u003cli\u003eAWS Auto Scaling\u003c/li\u003e\n\u003cli\u003eAWS Code Delploy\u003c/li\u003e\n\u003cli\u003eGitHub Actions\u003c/li\u003e\n\u003cli\u003eDocker\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch1 id=\"프로젝트-산출물\"\u003e\u003cstrong\u003e프로젝트 산출물\u003c/strong\u003e\u003c/h1\u003e\n\u003ch2 id=\"api-명세서\"\u003eAPI 명세서\u003c/h2\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cstrong\u003e기능\u003c/strong\u003e\u003c/th\u003e\n          \u003cth\u003eAPI URI\u003c/th\u003e\n          \u003cth\u003eHTTP Method\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e회원가입\u003c/td\u003e\n          \u003ctd\u003e/signup\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e회원가입 이메일 인증\u003c/td\u003e\n          \u003ctd\u003e/confirm-signup\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e로그인\u003c/td\u003e\n          \u003ctd\u003e/login\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e로그아웃\u003c/td\u003e\n          \u003ctd\u003e/signout\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e토큰 유효성 검사\u003c/td\u003e\n          \u003ctd\u003e/verify-token\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e토큰 갱신\u003c/td\u003e\n          \u003ctd\u003e/refresh-token\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e페스티벌 생성\u003c/td\u003e\n          \u003ctd\u003e/festivals/create\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e페스티벌 목록 조회\u003c/td\u003e\n          \u003ctd\u003e/festivals\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e페스티벌 세부 정보 조회\u003c/td\u003e\n          \u003ctd\u003e/festivals/{festivalId}\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e페스티벌 검색\u003c/td\u003e\n          \u003ctd\u003e/festivals/search\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e티켓 예매\u003c/td\u003e\n          \u003ctd\u003e/reservations\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e내 예약 목록 조회\u003c/td\u003e\n          \u003ctd\u003e/reservations\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e채팅방 참여\u003c/td\u003e\n          \u003ctd\u003e/festivals/chatting/{chatRoomId}/join\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e채팅방 진입\u003c/td\u003e\n          \u003ctd\u003e/festivals/chatting/{chatRoomId}\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e참여 중인 채팅방 목록 조회\u003c/td\u003e\n          \u003ctd\u003e/festivals/chatting/list\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e채팅방 나가기\u003c/td\u003e\n          \u003ctd\u003e/festivals/chatting/delete\u003c/td\u003e\n          \u003ctd\u003eDELETE\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFCM 토큰 비활성화\u003c/td\u003e\n          \u003ctd\u003e/notification/deactivate\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFCM 토큰 활성화\u003c/td\u003e\n          \u003ctd\u003e/notification/activate\u003c/td\u003e\n          \u003ctd\u003ePOST\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e대기열 등록\u003c/td\u003e\n          \u003ctd\u003e/queues/{queue}/waiting-room/users/{email}\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e대기열에서 유저 순위 반환\u003c/td\u003e\n          \u003ctd\u003e/queues/{queue}/users/{email}/rank\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e예약 페이지 진입 가능 여부 반환\u003c/td\u003e\n          \u003ctd\u003e/queues/{queue}/users/{email}/allowed\u003c/td\u003e\n          \u003ctd\u003eGET\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e대기열 탈퇴\u003c/td\u003e\n          \u003ctd\u003e/queues/{queue}/users/{email}/leave\u003c/td\u003e\n          \u003ctd\u003eDELETE\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e대기 완료열 탈퇴\u003c/td\u003e\n          \u003ctd\u003e/queues/{queue}/users/{email}/leave-proceed\u003c/td\u003e\n          \u003ctd\u003eDELETE\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"erd\"\u003eERD\u003c/h2\u003e\n\u003cp\u003e\u003cimg alt=\"image\" loading=\"lazy\" src=\"/2nd/final_proj_partysomsom/image_1.png\"\u003e\u003c/p\u003e","title":"Final Project 솜솜파티: 축제 예약 플랫폼"},{"content":" 2024.08.11 - 2024.08.27 진행\n💡 Case Study core session을 마치고, 3주 간 case study를 진행했어요. case study에서는 AWS를 활용하는 여러 서비스의 아키텍처를 분석한 뒤 발표를 진행했어요. 팀을 구성하고, 팀별로 원하는 서비스를 선정해 AWS 아키텍처를 조사했어요. 팀 1: KTOWN4U의 글로벌 확장성과 개인화 서비스 최적화 글로벌 확장성을 높이고 폭발적인 트래픽을 감당하는 아키텍처 구성을 중점적으로 발표했어요. 데이터 웨어하우스를 활용한 개인화 서비스 최적화 방안에 대해서도 자세히 다뤘어요. 자세한 내용은 Case Study: KTOWN4U에서 확인해주세요 팀 2: 야나두의 클라우드 전환 야나두가 클라우드로 전환하게 된 배경과 전반적인 아키텍처 구성에 대해 설명했어요. 다른 교육 플랫폼의 아키텍처와 비교하며, 야나두 아키텍처가 앞으로 나아가야 할 개선 방향을 제시하기도 했어요. 자세한 내용은 Case Study: 야나두에서 확인해주세요 마무리 case study는 서비스의 아키텍처를 직접 분석해보는 값진 시간이었어요. 왜 특정 서비스를 사용해야 하는지, 어떻게 하면 더 효율적인 아키텍처를 만들 수 있는지, 그리고 어떤 방향으로 개선해야 할지 깊이 고민할 수 있었어요. 3주라는 시간 동안 모든 팀원들이 아키텍처를 완벽히 이해하기 위해 정말 열심히 노력했고, 덕분에 훌륭하게 케이스 스터디 발표를 마쳤습니다! ","permalink":"https://ddwu-aws-cloud-club.github.io/post/2nd/post-2-case-study/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2024.08.11 - 2024.08.27 진행\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-case-study\"\u003e💡 Case Study\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ecore session을 마치고, 3주 간 case study를 진행했어요.\u003c/li\u003e\n\u003cli\u003ecase study에서는 AWS를 활용하는 여러 서비스의 아키텍처를 분석한 뒤 발표를 진행했어요.\u003c/li\u003e\n\u003cli\u003e팀을 구성하고, 팀별로 원하는 서비스를 선정해 AWS 아키텍처를 조사했어요.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"팀-1-ktown4u의-글로벌-확장성과-개인화-서비스-최적화\"\u003e팀 1: KTOWN4U의 글로벌 확장성과 개인화 서비스 최적화\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e글로벌 확장성을 높이고 폭발적인 트래픽을 감당하는 아키텍처 구성을 중점적으로 발표했어요.\u003c/li\u003e\n\u003cli\u003e데이터 웨어하우스를 활용한 개인화 서비스 최적화 방안에 대해서도 자세히 다뤘어요.\u003c/li\u003e\n\u003cli\u003e자세한 내용은 \u003ca href=\"https://ddwu-aws-cloud-club.github.io/post/2nd/post-3-case-study-ktown4u/\"\u003eCase Study: KTOWN4U\u003c/a\u003e에서 확인해주세요\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cimg alt=\"case_ktown4u\" loading=\"lazy\" src=\"/2nd/case_ktown4u/info.png\"\u003e\u003c/p\u003e","title":"Case Study"},{"content":"KTOWN4U Case Study: 글로벌 확장성과 개인화 서비스 최적화 AWS 고객사례: 케이타운포유\n케이타운포유는 급성장 중인 K-Pop 및 한류 상품을 글로벌 판매하는 이커머스 서비스를 제공하는 회사로 2002년 서비스를 시작한 이래 200개국, 6개 언어로 500만 회원, 5,000여 개 팬클럽을 대상으로 서비스하고 있습니다. 케이타운포유는 B2B에서 B2C로 전환 후 2021년 매출액 2,000억을 돌파하며 짧은 기간에 15배에 달하는 성장을 하였습니다.\n케이타운포유는 사용자서비스, 운영시스템, 물류시스템(WMS) 등의 시스템을 개발, 운영하고 있으며, 이를 위해 모든 시스템을 AWS 클라우드에서 구축/운영하고 있습니다. 2022년에 많은 버그를 해결함과 동시에 트래픽 수용을 위한 개선을 이뤘고, 2023년에는 상품구조 개선, 물류시스템 개선 및 고도화, 거대 모놀리식 레거시 시스템을 MSA 구조로 변경 진행 중에 있습니다.\n당면 과제 케이타운포유는 비즈니스가 성장하면서 글로벌 사용자와 데이터가 증가하면서 자체 구축한 온프레미스 환경은 물리적인 한계로 안정적인 서비스를 제공하는 데 어려움이 있었습니다. 특히, 유명 K팝 아티스트의 앨범이나 한류 굿즈가 출시되거나 이벤트를 진행할 때 대규모 트래픽이 발생하여 서버가 다운되는 이슈가 있었습니다. 온프레미스 환경에서는 서버 자원 관리가 용이하지 않고 인프라를 탄력적으로 운영할 수 없었습니다. 케이타운포유는 글로벌 웹 커머스 플랫폼으로 더욱 도약하기 위해 인프라 관리 편의성과 접근성, 갑자기 급증하는 트래픽에 빠르게 대응할 수 있는 확장성과 안정성 보장, 웹 플랫폼의 고속 전송 네트워크 콘텐츠, 전 세계 고객의 경험 데이터를 기반으로 빅데이터 분석을 적용한 개인화 서비스, 마케팅 및 비즈니스 인사이트를 위한 데이터웨어하우스(DW)를 고려하게 되었습니다.\nAmazon CloudFront KTOWN4U의 CloudFront 도입 이유 콘텐츠 전송 네트워크(CDN) 서비스인 Amazon CloudFront를 도입하여 높은 전송 속도로 안전하게 콘텐츠를 전송할 수 있게 네트워크를 구축했습니다.\nAmazon CloudFront란? 개발자 친화적 환경에서 짧은 지연과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전세계 고객에게 안전하게 전송하는 고속 컨텐츠 전송 네트워크(CDN) 서비스\nCloudFront는 CDN 서비스 이외에도 기본 보안 기능(Anti-DDoS)을 제공\nCDN이란? 컨텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템 인터넷 서비스 제공자(ISP)에 직접 연결되어 데이터를 전송하므로, 컨텐츠 병목을 피할 수 있다는 장점 특징 웹 페이지, 이미지, 동영상 등의 컨텐츠를 본래 서버에서 받아와 캐싱 해당 컨텐츠에 대한 요청이 들어오면 캐싱해 둔 컨텐츠를 제공 컨텐츠를 제공하는 서버와 실제 요청 지점 간의 지리적 거리가 매우 먼 경우 or 통신 환경이 안 좋은 경우 → 요청 지점의 CDN을 통해 빠르게 컨텐츠를 제공 서버의 요청이 필요 없으므로 서버의 부하를 낮추는 효과 CloudFront 동작 방식 💡 엣지 로케이션: 컨텐츠가 캐싱되고 유저에게 제공되는 지점. AWS가 CDN을 제공하기 위해서 만든 서비스인 CloudFront의 캐시 서버 (데이터 센터의 전 세계 네트워크)\nAWS 백본 네트워크를 통해 컨텐츠를 가장 효과적으로 서비스할 수 있는 엣지로 각 사용자 요청을 라우팅하여 컨텐츠 배포 속도를 높임.\n컨텐츠가 엣지 로케이션에 없는 경우\nCloudFront는 컨텐츠의 최종 버전에 대한 소스로 지정된 오리진(S3 버킷, MediaPackage 채널, http 서버 등)에서 컨텐츠를 검색 컨텐츠를 제공하는 근원에서 제공받아 전달 컨텐츠가 엣지 로케이션에 있는 경우\n바로 전달 데이터 전달 과정\n클라이언트로부터 Edge Server로의 요청이 발생 Edge Server는 요청이 발생한 데이터에 대하여 캐싱 여부를 확인 사용자의 근거리에 위치한 Edge Server 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터를 응답합니다. 사용자의 요청에 적합한 데이터가 캐싱되어 있지 않은 경우 Orgin Server로 요청이 포워딩됨. 요청받은 데이터에 대해 Origin Server에서 획득한 후 Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답이 발생 CloudFront 장점 AWS 네트워크를 사용하면 사용자의 요청이 반드시 통과해야 하는 네트워크의 수가 줄어들어 성능이 향상됨. 파일의 첫 바이트를 로드하는 데 걸리는 지연 시간이 줄어들고 데이터 전송 속도가 빨라짐. 파일(객체)의 사본이 전 세계 여러 엣지 로케이션에 유지(또는 캐시)되므로 안정성과 가용성이 향상됨. 보안성이 향상됨. 오리진 서버에 대한 종단 간 연결의 보안이 보장됨. (https) 서명된 URL 및 쿠키 사용 옵션으로 자체 사용자 지정 오리진에서 프라이빗 콘텐츠를 제공하도록 할 수 있음. 결론 케이타운포유는 Amazon CloudFront를 도입해 글로벌 사용자가 콘텐츠에 신속하고 안정적으로 접근할 수 있도록 인프라를 구축함. 특히, 글로벌 이벤트와 대규모 트래픽 스파이크에 대비해 성능을 최적화. CloudFront는 CDN을 통해 엣지 로케이션에서 캐시된 콘텐츠를 제공, 네트워크 병목을 줄이고 서버 부하를 효과적으로 분산. 이를 통해 고속 전송과 보안성을 확보, 대규모 트래픽 시에도 안정적인 서비스 유지. 결과적으로, CloudFront는 케이타운포유가 글로벌 시장에서 서비스 품질을 유지하고, 고객 만족도를 높이는 중요한 요소로 자리잡음. Amazon S3 KTOWN4U의 S3 도입 이유 무제한에 가까운 스토리지인 Amazon Simple Storage Service (Amazon S3)를 추가하여 이미지 콘텐츠, 대용량 로그를 저장 및 분석에 사용했습니다.\nS3란? (Simple Storage Service) 업계 최고의 확장성과 데이터 가용성 및 보안과 성능을 제공하는 온라인 오브젝트 스토리지 서비스. 쉽게 말하자면 데이터를 온라인으로 오브젝트 형태로 저장하는 서비스이다. 온라인이라는 글자가 붙는 이유는 데이터 조작에 HTTP/HTTPS를 통한 API가 사용되기 때문. 또한 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있어 개발자가 쉽게 웹 규모 컴퓨팅 작업을 수행할 수 있도록 함. S3는 객체 스토리지(객체로 된 파일을 다루는 저장소)이기 때문에 S3에 파일을 설치하는 행위는 할 수 없고, 이미지나 동영상 파일 등만을 저장할 수 있음. 즉, 파일 업로드, 삭제, 업데이트만 가능하지, 프로그램을 설치해서 저장하는 기능은 없다고 보면 된다. S3를 사용하는 이유 S3는 저장 용량이 무한대이고 파일 저장에 최적화되어 있어, 용량을 추가하거나 성능을 높이는 작업이 필요 없다. 비용은 EC2와 EBS로 구축하는 것보다 훨씬 저렴함. S3 자체가 수천 대 이상의 매우 성능이 좋은 웹 서버로 구성되어 있어서 EC2와 EBS로 구축했을 때 처럼 Auto Scaling이나 Load Balancing에 신경쓰지 않아도 된다. 웹하드 서비스와 비슷하지만, 별도의 클라이언트 설치나 ActiveX를 통하지 않고, HTTP 프로토콜(restful)로 파일 업로드/다운로드 처리가 가능. S3 자체로 정적 웹서비스가 가능. 동적 웹페이지와 정적 웹페이지가 섞여있을 때 동적 웹페이지만 EC2에서 서비스하고 정적 웹페이지는 S3를 이용하면 성능도 높이고 비용도 절감할 수 있다. S3 사용 예 클라우드 저장소 (개인 파일 보관, 구글 드라이브처럼 사용 가능) 서비스의 대용량 파일 저장소 - 이미지, 동영상, 빅데이터 (ex: 넷플릭스) 서비스 로그 저장 및 분석 AWS 아데나를 이용한 빅데이터 업로드 및 분석 서비스 사용자의 데이터 업로드 서버 (이미지 서버, 동영상 서버) 중요한 파일은 EC2의 SSD (EBS: Elastic Block Store)에 저장하지 말고 S3에 저장 glacier와의 연동으로 비용 절감 및 규정 준수 가능 (빙하라는 뜻으로 자주 쓰지 않는 데이터를 S3에서 자동으로 변환) 결론 S3의 주요 특징: 무제한에 가까운 저장 용량과 안정적인 성능을 제공 파일 저장에 최적화된 객체 스토리지로, EC2와 EBS 대비 저렴한 비용 정적 웹 콘텐츠를 S3에 호스팅하여 성능 향상 및 비용 절감 도입 이유: 대규모 트래픽과 데이터 증가에 유연하게 대응 데이터 저장 및 전송을 간소화하여 인프라 관리 부담 감소 케이타운포유는 Amazon S3를 도입해 이미지 콘텐츠 및 대용량 로그를 효율적으로 저장하고 분석함. 결과적으로, S3 도입으로 케이타운포유는 대용량 데이터 관리와 비용 최적화를 실현하며, 서비스 안정성을 높임. Amazon Aurora Amazon Aurora란? MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진 특징: 고성능 스토리지와 고속 처리 능력: Aurora는 MySQL의 성능을 최대 5배, PostgreSQL의 성능을 최대 3배까지 높일 수 있다. 스토리지가 자동으로 조정되어 최대 128TiB(테비바이트)까지 확장 가능하다. 기존 MySQL, PostgreSQL 애플리케이션을 거의 변경하지 않고도 성능을 향상시킬 수 있다. 데이터베이스의 클러스터링과 복제를 자동으로 처리해 복잡한 관리 작업을 줄인다. 추가 참고 자료 PostgreSQL: 고급 기능을 제공하는 오픈 소스 RDBMS. 데이터 무결성, ACID 준수에 강점. Aurora Serverless v2: 클러스터의 용량을 자동으로 조정하여 운영 중단 없이 CPU 및 메모리를 동적으로 확장하는 기능 Route 53: DNS 웹 서비스로, 트래픽을 효율적으로 라우팅 케이타운포유의 Amazon Aurora Auto Scaling 개선 사례 비즈니스 환경: 케이타운포유는 이벤트 발생 시 평소보다 수십 배 이상의 트래픽 증가를 겪습니다. 기존 아키텍처 문제: 실시간 데이터베이스 부하: 캐시를 활용하더라도 API 호출이 많은 실시간 쿼리로 인해 DB 부하 발생 오토스케일링 한계: Scale-out 시, 평균 15분 소요 이벤트 발생 전, 수 시간 전에 읽기 전용 인스턴스를 미리 증설해야 하는 부담 예측 불가능한 이벤트로 인해 과도한 리소스 사용 및 비용 낭비 개선 목표 및 아이디어 핵심 요구사항: 순간적인 트래픽 스파이크 대응 비용 최적화 기존 Aurora 오토스케일링의 시간 지연 문제 해결 개선 아이디어: Serverless v2 인스턴스 활용: 기존 프로비저닝된 클러스터에 추가해 하이브리드 구조를 구성 고해상도 메트릭 기반의 감지: 1초 단위의 메트릭을 수집하여 스파이크 상황을 빠르게 감지 가중치 기반 트래픽 분배: 임계치 초과 시 트래픽을 Serverless 인스턴스로 자동 분배 개선된 오토스케일링 아키텍처 Aurora Mixed-Configuration Cluster 구성: 프로비저닝된 인스턴스: 기본 트래픽 처리 담당 Serverless v2 인스턴스: 스파이크 트래픽 대응을 위해 임계치 초과 시 트래픽 분산 가중치 조절: 트래픽 부하에 따라 가중치를 조정해 자동으로 트래픽 분배 자동화된 트래픽 조절 작동 원리: 평상시 Serverless v2 인스턴스의 가중치는 0 CPU 임계치 초과 시, 알람이 발생하며 가중치 증가 프로비저닝된 인스턴스 추가 후, 트래픽 재분배 및 Serverless 인스턴스 사용 중지 아키텍처 주요 요소 Aurora Serverless v2 읽기 전용 인스턴스 추가 및 커스텀 엔드포인트 설정: Serverless v2 인스턴스를 클러스터에 추가하여 가중치 0으로 설정 각 엔드포인트를 Route53에 연결하여 가중치 기반 라우팅을 설정 Enhanced Monitoring \u0026amp; 고해상도 메트릭 수집: 기본 메트릭(60초 주기)보다 더 높은 해상도를 위해 Enhanced Monitoring 활성화 1초 단위의 RDSOSMetrics를 CloudWatch에 수집 및 커스텀 메트릭 생성 Step Functions를 이용한 자동 트래픽 조절: 알람 발생 시, Step Functions이 자동으로 트래픽 비율을 조절 지속적인 모니터링을 통해 트래픽 변동 상황에 맞춰 실시간 조정 커스텀 메트릭 기반 오토스케일링: 평균 CPU 사용량 기준으로 오토스케일링을 설정하되, Serverless 인스턴스를 포함하지 않음 커스텀 메트릭을 기반으로 TargetTrackingScaling 정책 구성 테스트 결과 AS-IS : Aurora Cluster (Provisioned Only)\n트래픽 스파이크로 인해 약 15분간 CPU 100% 도달 및 서비스 장애 발생\n평균 CPU 사용률\nTO-BE : Aurora Hybrid Cluster (Provisioned + Serverless v2)\nServerless v2를 통해 순간적인 CPU 부하 해소, 안정적인 성능 유지\n프로비저닝 인스턴스 추가 후 Serverless 트래픽 비율 감소\n평균 CPU 사용률\n성과 및 효과 서비스 안정성: 예측 불가능한 글로벌 스파이크 트래픽에 안전하게 대응 시스템 성능 향상: 초기 부하 상태에서 응답 속도 220ms → 80ms로 개선 오토스케일링 시간 단축: 메트릭 주기 60초 → 10초 비용 절감: 불필요한 사전 증설 제거로, 이벤트 대응 비용 약 30% 절감 결론 및 추천 Aurora Hybrid Cluster 활용: 예측 불가한 트래픽 상황에 최적화된 아키텍처 운영 및 관리 부담 감소: 자동화된 모니터링 및 오토스케일링 향후 확장 가능성: Serverless v2 인스턴스를 활용해 다양한 데이터베이스 요구사항에 대응 마무리 Aurora Serverless v2 및 Mixed-Configuration Cluster는 효율적인 오토스케일링 전략으로 안정적인 서비스 제공을 위한 핵심 아키텍처가 될 것 적용 대상: 비즈니스 이벤트 시 높은 트래픽을 경험하는 기업 빠르고 유연한 오토스케일링이 필요한 환경 멀티 AZ 환경과 ELB KTOWN4U의 ELB 도입 이유 ELB을 활용해 부하 분산 및 유동성을 확보\n구조 두 개의 가용 영역(AZ A와 AZ B)에 각각 두 개의 EC2 인스턴스(C5n)가 배치되어 있고, 이 인스턴스들을 하나의 ELB(Elastic Load Balancing)가 관리하고 있는 구조\nAZ 도입 이점 우선 리전이란 개념을 알아야 하는데, 리전은 인프라를 지리적으로 나누어 배포한 것을 의미한다. 사용자와 리전을 가깝게 해야 network latency를 최소화할 수 있다.\n이 리전에서 개별의 데이터센터로 분리해놓은 것을 가용 영역(Availability Zone)이라 한다. 왜 AZ를 여러 개를 둘까? 이는 자연재해 및 정전 등의 재해로부터 자유로워지기 위해서이다. HA(고가용성) 을 위해 리전 내 복수의 가용 영역에 데이터(RDS)와 애플리케이션(EC2)를 배포하는 것이 좋다. 이를 통해 한 AZ의 서버가 죽어도 다른 AZ로 안정적으로 서비스 운영을 유지할 수 있다.\nElastic IP (탄력적 IP) AWS에서 제공하는 Static IP Address 이다. 인스턴스 장애가 발생한 AZ로부터 다른 AZ로 인스턴스 주소를 신속히 변경할 수 있다.\nELB 도입 이점 부하 분산 ELB는 네트워크 트래픽을 여러 대상으로 균등하게 분배하여 특정 서버에 과도한 부하가 걸리지 않도록 한다.\nAWS: Application Load Balancing, Network Load Balancing 및 Gateway Load Balancing의 차이점은 무엇인가요?\nALB는 들어오는 트래픽을 EC2 인스턴스를 비롯한 여러 대상에 분산합니다.\n서비스 중단 최소화 (고가용성 확보) 한 가용 영역에서 문제가 발생할 경우, 다른 가용 영역에서 서비스가 지속적으로 제공된다.\nAWS: Regions and Availability Zones\n가용 영역은 다른 모든 가용 영역과 수 킬로미터에 상당하는 유의미한 거리를 두고 물리적으로 분리되어 있다. (다만 모든 가용 영역은 서로 100km(60마일) 이내의 거리에 위치한다.)\n엔드포인트 역할 제공 트래픽을 하나의 경로로 받아서 다수의 인스턴스에 분산한다. 유저 입장에서는 각각의 인스턴스에 일일히 접근해서 관리하는 게 아닌 하나의 주소로 접속해서 관리할 수 있게 된다. Elastic Load Balancing AWS: Application Load Balancing, Network Load Balancing 및 Gateway Load Balancing의 차이점은 무엇인가요?\nApplication Load Balancer 로드 밸런싱의 주요 목적은 서버 부하 분산이다. 트래픽이 몰릴 때 특정 서버로 부하가 몰리지 않도록 적절히 분산해주는 역할을 한다. 이는 EC2뿐만 아니라 ECS의 컨테이너, Lambda 등에도 해당된다. 네트워크에서는 이를 L4/L7 Switch(OSI 4계층) 이라 부르며 클라우드 환경에서는 로드 밸런서라고 부른다.\nL4 Switch 4계층(Transport) IP/Port level에서 로드밸런싱 한다. 즉, 서버 A와 서버 B로 부하를 분산한다.\nL7 Switch 7계층(Application) User Request level에서 로드밸런싱 한다. 즉, /category 와 /search를 담당 서버들로 로드밸런싱\n또 ELB는 트래픽을 분산함으로써 특정 인스턴스나 AZ에 장애가 발생해도 자동으로 다른 인스턴스로 트래픽을 리다이렉트하여 서비스의 무중단 운영을 가능하게 한다.\nELB는 Auto Scaling과 함께 사용된다. 이때 자동으로 늘어난 인스턴스는 로드밸런서에 자동으로 등록되며, 마찬가지로 종료된 인스턴스도 로드밸런서에서 자동으로 등록 취소된다. 인스턴스가 증가하더라도 LB 는 하나의 엔드포인트가 제공하기 때문에 사용자는 다른 인스턴스에 접속하더라도 같은 엔드포인트로 접속하면 된다.\n다음은 다양한 유형의 LB이다.\nApplication Load Balancer ALB는 들어오는 트래픽을 EC2 인스턴스를 비롯한 여러 대상에 분산한다. 유연한 애플리케이션 수준의 트래픽 관리 및 라우팅이 필요한 경우에 적합하다. 마이크로서비스, 컨테이너화된 환경, 웹 애플리케이션에 가장 적합하다.\n예시\n전자 상거래 애플리케이션에는 제품 디렉터리, 장바구니 및 결제 기능이 있다. ALB는 이미지와 비디오를 포함하지만 열린 연결을 유지할 필요가 없는 서버에 제품 검색 요청을 전송한다. 이에 비해 클라이언트 연결을 유지하고 장바구니 데이터를 오랫동안 저장하는 서버로 장바구니 요청을 전송한다.\nGateway Load Balancer GLB를 사용하여 침입 탐지 및 방지, 방화벽 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 관리 및 확장할 수 있다.\nNetwork Load Balancer NLB는 네트워크 상태에 따라 트래픽을 분산한다.\n예시\n중복된 데이터가 포함된 데이터베이스 서버가 여러 개 있는 경우, NLB는 미리 정해진 서버 IP 주소 또는 서버 가용성에 따라 트래픽을 라우팅한다.\n비교 ALB NLB GLB OSI 계층 계층 7 계층 4 계층 3 및 계층 7 대상 유형 (트래픽을 라우팅하는 엔드 포인트) IP, 인스턴스 및 Lambda 대상 유형 IP, 인스턴스 및 ALB 대상 유형 IP 및 인스턴스 대상 유형 프록시 동작 연결 종료 연결 종료 흐름을 종료하지 않음 프로토콜 HTTP, HTTPS 및 gRPC 프로토콜 TCP, UDP 및 TLS 프로토콜 지원 IP 기반 라우팅 지원 알고리즘 라운드 로빈 플로우 해시 라우팅 테이블 조회 Amazon EC2 Amazon EC2 인스턴스 네이밍 인스턴스 패밀리 세대 추가 기능 구분자 인스턴스 크기 예시 c 5 n . large Amazon EC2 인스턴스 패밀리 Amazon EC2 인스턴스 유형\n범용 인스턴스\n용도 균형 있는 컴퓨팅, 메모리 및 네트워킹 리소스를 제공하며, 다양한 여러 워크로드에 사용할 수 있다. 이 인스턴스는 웹 서버 및 코드 리포지토리와 같이 이러한 리소스를 동등한 비율로 사용하는 애플리케이션에 적합하다. 인스턴스 유형 | 유형명 | 의미 | | \u0026mdash; | \u0026mdash; | | Mac | macOS | | M | 범용 (vCPU 1개, 4GB 메모리) | | T | 버스트가 가능한 CPU | | A | ARM 기반 |\n컴퓨팅 최적화 인스턴스\n용도 고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합하다. 이 범주에 속하는 인스턴스는 배치처리 워크로드, 미디어 트랜스코딩, 고성능 웹 서버, 고성능 컴퓨팅(HPC), 과학적 모델링, 전용 게임 서버 및 광고 서버 엔진, 기계 학습 추론 및 기타 컴퓨팅 집약적인 애플리케이션에 매우 적합하다. 인스턴스 유형 유형명 의미 C 컴퓨팅 최적화 메모리 최적화 인스턴스\n용도 메모리에서 대규모 데이터세트를 처리하는 워크로드를 위한 빠른 성능을 제공하기 위해 설계되었다. 인스턴스 유형 유형명 의미 R 초대형 메모리 X 랜덤 액세스 메모리(RAM) z 고주파수 메모리 가속 컴퓨팅 인스턴스\n용도 하드웨어 엑셀러레이터 또는 코프로세서를 사용하여 부동 소수점 수 계산이나 그래픽 처리, 데이터 패턴 일치 등의 기능을 CPU에서 실행되는 소프트웨어보다 훨씬 효율적으로 수행한다. 인스턴스 유형 유형명 의미 P 프리미엄 GPU G GPU F FPGA (Field Programmable gate Array) 스토리지 최적화 인스턴스\n용도 로컬 스토리지에서 매우 큰 데이터 세트에 대해 많은 순차적 읽기 및 쓰기 액세스를 요구하는 워크로드를 위해 설계되었다. 애플리케이션에 대해 대기 시간이 짧은, 수만 단위의 무작위 초당 I/O 작업 수(IOPS)를 지원하도록 최적화되었다. 인스턴스 유형 유형명 의미 D Dense Storage (고밀도 스토리지) H HDD I NVMe (Non-Volatile Memory Express) 추가 기능 추가 기능명 의미 a AMD 프로세서 b 블록 스토리지 최적화 d 인스턴스 스토어 볼륨 (휘발성) e 추가 스토리지 또는 메모리 g AWS Graviton 프로세서 i 인텔 프로세서 n 네트워크 최적화 z 고주파 C5n EC2 인스턴스 종류 AWS: 신규 C5n EC2 인스턴스 타입 출시 – 100Gbps 네트웍 대역폭 지원\n최대 100Gbps의 네트워크 대역폭을 통해 시뮬레이션, 인메모리 캐시, 데이터 레이크 및 기타 대규모의 통신처리를 필요로하는 애플리케이션들이 이전보다 훨씬 원활하게 실행됩니다.\n인스턴스 이름 vCPUs RAM EBS 대역폭 네트워크 대역폭 c5n.large 2 5.2GiB Up to 3.5Gbps Up to 25Gbps c5n.xlarge 4 10.5GiB Up to 3.5Gbps Up to 25Gbps c5n.2xlarge 8 21GiB Up to 3.5Gbps Up to 25Gbps c5n.4xlarge 16 42GiB 3.5Gbps Up to 25Gbps c5n.9xlarge 36 96GiB 7Gbps 50Gbps c5n.18xlarge 72 192GiB 14Gbps 100Gbps 인스턴스 구입 옵션 Amazon EC2 결제 및 구매 옵션\n온디맨드 인스턴스\n시작하는 인스턴스에 대한 비용을 초 단위로 지불 절감형 플랜(Savings Plans)\n1년 또는 3년 기간 동안 시간당 USD로 일관된 사용량을 약정하여 비용 절감 예약 인스턴스\n1년 또는 3년 기간 동안 인스턴스 유형 및 리전을 포함하여 일관된 인스턴스 구성을 약정 스팟 인스턴스\n미사용 EC2 인스턴스를 요청하여 EC2 비용을 대폭 줄임 전용 호스트\n인스턴스 실행을 전담하는 실제 호스트 비용을 지불하며, 기존의 소켓, 코어 또는 VM 소프트웨어별 라이선스를 가져와 비용 절감 전용 인스턴스\n단일 테넌트 하드웨어에서 실행되는 인스턴스 비용을 시간 단위로 지불 용량 예약\n특정 가용 영역의 EC2 인스턴스에 대해 용량 예약 Amazon ElastiCache KTOWN4U의 ElastiCache 도입 이유 ElastiCache를 활용한 캐시를 도입하여 데이터베이스에 직접적인 부하를 감소시킬 수 있도록 구성했습니다.\n구조 EC2 인스턴스와 ElastiCache가 연결되어 있고, Aurora 데이터베이스와는 연결되지 않은 구조\nElastiCache 도입 이점 및 사용 사례 Amazon ElastiCache 이점 빠른 응답 시간 비용 최적화된 성능 용량 관리 불필요 비즈니스 지속성 유지 Redis OSS 및 Memcached 호환 가능 사용 사례 백엔드 데이터베이스 로드를 줄여 총 소유 비용 절감 데이터를 캐시하고 데이터베이스 I/O를 오프로드하여 운영 부담을 줄이고 비용을 절감하여 데이터베이스 및 애플리케이션 성능을 개선 실시간 애플리케이션 데이터 캐싱 실시간 세션 스토어 실시간 순위표 엔진 비교 특징 Redis OSS Memcached 데이터 구조 문자열, 리스트, 셋, 해시, 정렬된 셋 등 다양한 데이터 구조 지원. 단순한 키-값 저장만 지원. (문자열) 영속성 디스크에 데이터를 저장하여 영속성 제공. 영속성 없음 (메모리에만 데이터 저장) 복제 및 페일오버 기본적으로 지원 (마스터-슬레이브 복제 및 자동 페일오버 가능) 지원하지 않음 스크립팅 Lua 스크립팅 지원 스크립팅 지원 없음 클러스터링 Redis 클러스터 기능으로 수평적 확장 가능 클러스터링 기본적으로 지원하지 않음 트랜잭션 MULTI/EXEC 명령어를 통해 트랜잭션 지원 트랜잭션 지원 없음 메모리 관리 LRU(Least Recently Used) 외 다양한 정책 지원 LRU(Least Recently Used) 정책만 지원 사용 사례 세션 관리, 채팅 애플리케이션, 실시간 분석 등 복잡한 데이터 구조가 필요한 경우 단순한 캐싱, 데이터베이스 쿼리 결과 캐싱 등 단순 캐싱 목적 성능 다양한 기능과 구조로 인해 성능이 약간 낮을 수 있음 단순 구조로 인해 매우 빠름 백업 및 복구 스냅샷을 이용해 백업 및 복구 가능 백업 및 복구 기능 없음 캐싱 전략 AWS: Memcached에 대한 캐싱 전략\n지연 로딩 (Lazy loading)\n전략 필요할 때에만 데이터를 캐시에 로드하는 전략 장점 - 요청된 데이터만 캐싱됨 - 노드 장애가 애플리케이션에 치명적인 영향을 주지 않음(노드 장애 : 서버나 네트워크 구성 요소 중 하나가 정상적으로 작동하지 않거나 완전히 멈추는 상황) 단점 - 캐시 누락 패널티(캐시에 요청된 데이터가 존재하지 않을 때 발생하는 성능 저하) 1. 캐시에서 데이터에 대한 초기 요청 2. 데이터에 대한 데이터베이스의 쿼리 3. 캐시에 데이터 작성 - 캐시에 저장된 데이터가 시간이 지남에 따라 오래되거나 최신 상태가 아닐 수 있음 라이트-스루 (Write-through)\n전략 데이터베이스에 데이터를 작성할 때마다 데이터를 추가하거나 캐시의 데이터를 업데이트하는 전략 장점 - 캐시에 저장된 데이터가 항상 최신 상태 - 쓰기 패널티 \u0026gt; 읽기 패널티 (사용자는 일반적으로 데이터를 업데이트할 때 지연시간에 더 관대) 단점 - 누락된 데이터 (ex. 캐시가 처음 시작할 때 비어있고, 특정 데이터에 대한 요청이 아직 발생하지 않은 경우) - 캐시 이탈 (캐시가 가득 찼을 때 덜 중요한 데이터가 제거되어 새로운 데이터를 저장할 공간을 확보하는 과정. 캐시 이탈이 발생하면, 자주 사용되거나 중요한 데이터가 캐시에서 제거될 수 있음) 추가 전략 - TTL 추가 (Adding TTL): 캐시에서 유효 기간을 설정하여 데이터가 오래되거나 불필요하게 남아 있지 않도록 관리하는 전략 추천시스템 로직 Amazon Aurora에 적재된 데이터를 DMS를 활용해 Amazon Redshift로 동기화하고, 데이터를 **Amazon Managed Workflows for Apache Airflow(MWAA)**와 ETL 서비스를 사용해 추출이 용이한 형태로 변환 후 Elasticsearch와 Amazon Personalize와 연동해 데이터를 분석하고 개인화 영역에서 활용할 수 있도록 구축했습니다.\n케이타운포유 아키텍처에서 추천 시스템에 대해 생략된 부분이 매우 많음 → 모든 서비스는 AWS의 서비스를 이용했다고 가정 후 진행\nRedShift 클라우드에서 완전히 관리되는 페타바이트급 데이터 웨어하우스 서비스\n데이터 웨어하우스(DW)란? 데이터 웨어하우스는 비즈니스 인텔리전스(BI) 활동을 지원하는 데이터 관리 시스템 비즈니스 인텔리전스(BI)란, 데이터를 수집, 정리, 분석하고 활용하여 더 나은 의사 결정을 내릴 수 있도록 지원하는 기술 여러 소스로부터 얻은 데이터를 중앙 집중화 및 통합하는 중앙 리포지토리 쿼리 및 분석 수행 RedShift 특징 클러스터 구조로, 리더 노드와 컴퓨팅 노드를 가짐\n노드 기능 리더 노드 • 외부 통신 처리 • 쿼리 실행계획 작성 컴퓨팅 노드 • 컴파일된 코드 실행(쿼리 수행) • 실행 후 결과를 리더 노드에게 전송 열 기반 데이터 스토리지\n데이터베이스 테이블 정보를 열 기반 방식으로 저장 디스크 입출력 호출 및 로드해야 하는 데이터 크기가 감소하는 이점을 가짐 열 기반 방식 덕분에 쿼리 성능, 데이터 처리 속도가 빨라짐 대용량 병렬 처리를 통해 복잡한 쿼리도 빠른 속도로 실행\n케이타운포유: 아키텍처에서 RedShift를 쓴 이유? 데이터 분석, 처리 서비스로는 Redshift 외에도 Athena, EMR이 존재\nAthena Redshift EMR 정의 쿼리 서비스 데이터 웨어하우스 빅데이터 플랫폼 서버 서버리스 서버 클러스터 서버 클러스터 데이터 위치 S3 클러스터 내 로컬 저장소, S3 및 외부 데이터 소스 S3 외에 위치 가능 쿼리 대화형 쿼리 복잡한 쿼리에 빠른 성능 쿼리 실행 외에도 분산 처리, 분석 작업 Athena를 사용하지 않은 이유\n케이타운포유 아키텍처는 Aurora에 저장된 데이터를 분석에 사용하기 때문\nAthena는 S3에 저장된 데이터를 쿼리하는 서비스\nRedShift는 S3, RDS 등 다양한 위치의 데이터를 분석 가능\n→ Aurora에 저장된 데이터를 분석하는 것에는 RedShift가 적절하다.\n단순 쿼리 서비스가 필요한 것이 아님\n데이터를 BI, 개인화에 사용할 목적\n단순 쿼리 서비스를 넘어서 대규모 데이터 세트를 처리하고 복잡한 분석을 수행할 수 있는 데이터 웨어하우스의 필요성을 가짐\n→ BI 및 개인화 목적에는 데이터 웨어하우스 솔루션인 RedShift가 적절하다.\nEMR을 사용하지 않은 이유\n데이터 웨어하우스의 필요성 EMR은 빅데이터 처리와 데이터 정제 작업에 최적화된 서비스\n케이타운포유가 필요로 하는 요소는 마케팅 및 비즈니스 인사이트이며 이는 빅데이터 처리에 중점을 두는 EMR보다 데이터 웨어하우스인 redshift에서 적절하게 제공 가능\n→ BI에 초점을 두는 데이터 웨어하우스인 RedShift가 더 적절하다.\nDMS 데이터를 쉽고 안전하게 이동할 수 있도록 지원하는 데이터베이스 마이그레이션 서비스\n작동 방식 Source, Target 엔드포인트, 데이터 복제 인스턴스 생성 복제 인스턴스를 통해 Replication Task 실행 데이터 복제 및 마이그레이션 진행 케이타운포유: DMS의 사용 케이타운포유 아키텍처는 DMS를 통해 Aurora에서 RedShift로 마이그레이션을 진행 ETL: Glue 서버리스 데이터 통합 서비스 · 완전 관리형 ETL 서비스\nETL이란? 추출, 전환, 적재(로드) 원시 데이터를 정리 및 구성해서 분석, 기계 학습 등의 용으로 준비하는 과정 소스 DB에서 관련 데이터 추출 분석에 적합한 형식으로 데이터 변환 데이터를 대상 DB에 로드 케이타운포유: ETL 서비스 ETL 과정이 아키텍처에서 생략되어 있어 어떤 ETL 서비스를 사용했는지 확인이 불가능 추천 시스템에서 AWS Glue를 ETL 서비스로 사용했다고 가정 Glue 구성 요소 Data catalog glue의 영구적 메타데이터 스토어 Crawler 지정한 데이터 소스를 읽어 메타데이터를 추출해 data catalog에 테이블 생성 Job ETL 작업을 수행하는데 필요한 비즈니스 로직 Script ETL 작업 코드 Glue 과정 크롤러 정의 크롤러는 데이터 소스를 읽고 data catalog에서 메타데이터 테이블 생성 Glue Job은 Data Catalog에 저장된 메타데이터를 참조하여 ETL 작업 정의 작업을 진행해 스크립트가 소스에서 데이터 추출, 변환 후 타켓으로 로드하는 ETL 과정 진행 Glue 사례: 올리브영 랭킹시스템 올리브영 테크블로그: 랭킹 시스템 개편기\n당면 과제\n랭킹 서비스 개편을 통해 세분화된 판매 랭킹 카테고리를 제공해야 하는 상황에서 문제 발생 랭킹 세분화로 랭킹의 종류가 추가될수록 DB 자원의 비효율성이 증가 현재의 랭킹 산출 방식이 랭킹 데이터의 산출 근거 파악에 부적절 해결\n기존의 산출방식 대신 신규 개발을 선택 Glue + Athena + Step Function을 사용해 랭킹 산출 시스템을 구현 구현: Glue\n데이터 카탈로그 생성을 위해 Glue 데이터베이스, 테이블 생성 크롤러 설정 기존의 RDB를 Glue Connector를 통해 연결 ETL Job 생성, 이를 통해 ETL 진행 Parquet 파일형식으로 전환하여 S3 버킷에 저장 → 기존 RDB에서 랭킹 산출용 데이터의 ETL을 진행하고 Parquet 형식으로 전환해 S3 버킷에 저장\nMWAA Amazon Managed Workflows for Apache Airflow\nAirflow란? 프로그래밍 방식으로 워크플로우를 작성, 예약 및 모니터링하는 오픈 소스 플랫폼\n→ 워크플로우 관리 도구\nAirflow 특징 파이썬을 이용한 데이터 파이프라인 정의 뛰어난 확장성 플러그인을 통한 쉬운 커스터마이징 편리한 웹 인터페이스 Airflow 기본 구성 DAG 반복 및 순환을 허용하지 않는 그래프 Operator Task의 Wrapper 역할 실제 작업을 정의하는데 사용 Action, Transfer, Sensor 타입이 존재 Task DAG의 실행 단위 Task 실행 시, Operator에서 정의한 작업을 수행 Task Instance 개별 Task가 실행된 인스턴스 MWAA 정의 Apache Airflow에 대한 관리형 오케스트레이션 서비스 데이터 파이프라인을 대규모로 설정하고 운영하는 데 사용 MWAA 작동 방식 MWAA에 사용할 S3 버킷 지정 S3에 DAG, 플러그인, Python 요구사항 저장 콘솔, CLI, SDK, Apache Airflow로 DAG 실행 및 모니터링 MWAA 사례: 29CM 개인화 추천시스템 기계학습운영(MLOps) 구축 Amazon SageMaker와 Amazon MWAA를 활용한 29CM의 개인화 추천시스템 MLOps 구축여정\n당면 과제\n기존 카테고리 페이지는 모든 사용자가 동일한 순서로 정렬된 상품 목록이 제시 카테고리 페이지에서 노출되는 상품을 개인화 추천 기반으로 재정렬하는 시스템 도입 개인화 모델의 학습, 배포 과정을 자동화하기 위해 기계학습 운영(MLOps) 체계의 구축 구현\nSageMaker + MWAA를 통한 기계학습 운영 구축 SageMaker의 데이터 전처리, 모델 학습, 모델 배포 과정을 각각 하나의 Task으로 정의 DAG 형성 DAG 파일, 플러그인, Python 요구사항을 S3(DAG bucket)에 저장 MWAA가 자동으로 Airflow 환경 구축 → MWAA를 통해 기계학습 운영(MLOps)을 구축, 전체 워크플로우를 자동화\nMWAA + Glue 분석: 아키텍처 Orchestrate an end-to-end ETL pipeline using Amazon S3, AWS Glue, and Amazon Redshift Serverless with Amazon MWAA\n2개의 계정 사용\nA(왼쪽): Source · Target S3 bucket 소유 B(오른쪽): 데이터 처리 작업 전담, MWAA, Glue, RedShift 소유 아키텍처 흐름\nA의 Source bucket에서 새로운 원시 데이터 탐색 AWS Glue로 ETL 작업 호출 및 진행 ETL 과정을 거친 데이터를 B의 Redshift에 적재 Redshift에서 저장 프로시저, SQL 명령 실행 A의 Target bucket으로 데이터 내보내기 새로운 데이터를 탐색해 ETL을 진행하고, 이를 Target bucket에 저장하는 모든 과정을 MWAA를 통해 워크플로우화함 OpenSearch AWS의 ElasticSearch 기반 오픈소스 검색 엔진 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색 등 사용 분석 도구로의 사용 검색 엔진이 갖는 특성을 분석에 활용 가능 검색 결과, 차원에 따라 분류 및 집계 가능 키워드, 결과 차원에 대한 스코어링 탑재 빠르고, 실시간 리포팅에 강함 OpenSearch vs ElasticSearch OpenSearch는 ElasticSearch 7.1.0의 포크 ElasticSearch의 라이선스 분쟁으로 인해 갈라서게 됨 OpenSearch ElasticSearch 데이터 수집 - 다른 AWS 서비스와 통합 중점 - 관리형 파이프라인 제공 - 다양한 데이터 유형, 구조 지원 - 대량 데이터 수집 지원 보안 AWS의 강력한 보안 기능 제공 무료에서 기본 보안 기능 제공 레퍼런스 적음 많음 케이타운포유: OpenSearch 사용 추측 다른 AWS 서비스와의 통합을 더 중시했다면 OpenSearch 사용 Personalize 데이터를 사용하여 사용자를 위한 항목 추천을 생성하는 완전 관리형 기계 학습 서비스\nPersonalize 과정: 브랜디 기술블로그 학습 데이터 준비\nPersonalize의 데이터 학습\n준비한 과거 데이터를 통해 데이터 세트 생성 추천 레시피를 선택해 솔루션 생성 레시피: 개인화\u0026amp;추천에 사용되는 알고리즘 솔루션: 레시피를 사용해 교육된 모델 결과물 솔루션 배포를 위한 캠페인 생성 실시간 데이터 수집하기\n이벤트 수집 SDK를 사용해 과거 + 실시간 데이터 조합으로 솔루션 제공 가능 추천 서비스의 흐름 추측 모든 서비스는 AWS의 서비스를 사용했을 것이라고 가정\nAurora에 데이터 적재 DMS를 활용해 Redshift로 동기화 Glue를 통해 ETL 진행, 데이터 정제 OpenSearch, Personalize에 정제된 데이터 연동, 개인화 구축 이 과정을 모두 Task로 설정 후 DAG 형성, MWAA를 통해 워크플로우화 ","permalink":"https://ddwu-aws-cloud-club.github.io/post/2nd/post-3-case-study-ktown4u/","summary":"\u003ch1 id=\"ktown4u-case-study-글로벌-확장성과-개인화-서비스-최적화\"\u003eKTOWN4U Case Study: 글로벌 확장성과 개인화 서비스 최적화\u003c/h1\u003e\n\u003cp\u003e\u003ca href=\"https://aws.amazon.com/ko/solutions/case-studies/k-town4u-case-study/\"\u003eAWS 고객사례: 케이타운포유\u003c/a\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e케이타운포유는 급성장 중인 \u003cstrong\u003eK-Pop 및 한류 상품을 글로벌 판매하는 이커머스 서비스를 제공하는 회사\u003c/strong\u003e로 2002년 서비스를 시작한 이래 200개국, 6개 언어로 500만 회원, 5,000여 개 팬클럽을 대상으로 서비스하고 있습니다. 케이타운포유는 B2B에서 B2C로 전환 후 2021년 매출액 2,000억을 돌파하며 짧은 기간에 15배에 달하는 성장을 하였습니다.\u003c/p\u003e","title":"Case Study: KTOWN4U"},{"content":"AWS Case Study : 야나두 8월 27일, 2024 - 김민경, 오은아, 이승연, 최가람, 하서정\n야나두 사례 연구\nAWS 서비스 중에 가장 만족스러운 기능은 RDS Proxy와 Graviton2이고, 유용하게 잘 사용하고 있습니다. RDS Proxy와 똑같은 기능을 온프레미스 환경에서 구축할 수 있지만, 문제가 발생했을 때 문제를 파악하는데 너무 많은 시간이 소요됩니다.\n당면했던 과제 온프레미스 환경의 단일 서버를 사용하다 보니, 초기 도입 비용에 대한 부담과 운영 및 유지보수 관리, 그리고 무엇보다 예측하기 힘든 트래픽으로 인해 사업을 확장하는데 어려움이 있었습니다. 온프레미스 환경의 서버는 잦은 서버 다운과 한번 다운된 서버는 직접 재시작해줘야 하고, 하드웨어 이슈가 있을 때마다 직접 현장에 방문해야 하는 문제가 있습니다. 탄력적 운영으로 안정적인 서비스 환경을 갖출 수 있고, 결정적으로 동일한 수준의 비용으로 고가용성을 확보할 수 있다는 점에서 클라우드 컴퓨팅을 고려하게 되었습니다. AWS Graviton2 Amazon Graviton2은 AWS에서 설계한 ARM 기반의 데이터 센터 프로세서입니다.\nAWS는 클라우드 인프라의 효율성을 높이고, 더 나은 성능과 비용 효율성을 제공하기 위해 이 프로세서를 개발했습니다.\nGraviton2 프로세서 주요 특징 ARM 아키텍처 기반: Graviton2는 ARM의 Neoverse N1 코어를 기반으로 하며, 64코어, 2.5GHz 클럭 속도로 동작합니다. 32MB L3 캐시와 8채널 DDR4-3200 메모리, 64개 PCIe4를 지원하며, 2TB/s 메시 아키텍처로 연결됩니다. 성능 향상: AWS Graviton2 프로세서는 x86 기반 프로세서에 비해 최대 40% 더 나은 가격 대비 성능을 제공합니다. 또한, Graviton1에 비해 7배 향상된 가격 대비 성능, 4배 더 빠른 컴퓨팅 코어, 5배 더 빠른 메모리 속도, 2배 더 큰 캐시를 제공합니다. 다양한 활용 가능: Graviton2는 EC2 인스턴스, 데이터베이스, 컨테이너, 서버리스 워크로드 등 다양한 AWS 서비스에 활용될 수 있습니다. 확장성: Graviton2는 64개의 vCPU(가상 CPU)를 제공하며, 고대역폭 메모리와 고속 네트워킹 성능을 지원하여 대규모 데이터 처리와 같은 고성능이 요구되는 작업에도 적합합니다. 아마존 웹서비스를 선택한 이유 야나두는 AWS 사용량이 점차 늘어나면서 비용과 성능 최적화를 고민하게 되었습니다. 그 연장선에서 최근에 출시된 AWS Graviton2를 테스트하고, 이미 야나두가 구성한 동일한 아키텍처 구조에서 큰 변화 없이 쉽게 적용할 수 있는 프로세스임을 확인했습니다. 현재는 적용을 위한 테스트를 모두 마치고, 순차적으로 Graviton2로 이전 중에 있습니다. Gravition2를 통해 더 높은 성능과 비용 최적화를 동시에 기대하고 있습니다.\nAmazon RDS Proxy Amazon RDS Proxy는\nAmazon Relational Database Service(RDS)의 1.완전관리형 및 고가용성 데이터베이스 프록시로, 애플리케이션의 확장성, 데이터베이스 장애에 대한 복원력, 2.보안을 강화합니다.\n1 . 완전관리형 기존 프록시 서버의 단점\n: 배포, 패치 적용 및 관리가 어려워 우수한 제품을 개발하는 데 투자해야 할 시간과 에너지가 허비\n→ Amazon RDS 프록시는 자체 프록시 서버를 패치하고 관리해야 하는 추가적인 부담 없이 데이터베이스 프록시의 이점 제공\n데이터베이스 프록시 서버는 데이터베이스의 추가 부하를 처리하는 데 도움\n완전 서버리스 방식이며 워크로드에 맞게 자동으로 규모가 조정됨\n2. 보안 DB 액세스에 IAM 인증을 적용 가능 DB 보안 인증 정보를 애플리케이션 코드에 하드 코딩하지 않아도 됨 → 데이터 보안을 추가로 제어 가능 AWS Secrets Manager를 사용해 DB 보안 인증 정보를 중앙에서 관리 가능 3. 고가용성 RDS Proxy와 똑같은 기능을 온프레미스 환경에서 구축할 수 있지만, 문제가 발생했을 때 문제를 파악하는데 너무 많은 시간이 소요됩니다.\n온프레미스 환경의 단일 서버를 사용하다 보니, 초기 도입 비용에 대한 부담과 운영 및 유지보수 관리, 그리고 무엇보다 예측하기 힘든 트래픽으로 인해 사업을 확장하는데 어려움이 있었습니다.\n온프레미스 환경의 서버는 잦은 서버 다운과 한번 다운된 서버는 직접 재시작해줘야 하고, 하드웨어 이슈가 있을 때마다 직접 현장에 방문해야 하는 문제가 있었습니다.\n탄력적 운영으로 안정적인 서비스 환경을 갖출 수 있고, 결정적으로 동일한 수준의 비용으로 3.고가용성을 확보 할 수 있다는 점에서 클라우드 컴퓨팅을 고려하게 되었습니다.\n애플리케이션 연결을 유지하면서 새 데이터베이스 인스턴스에 자동으로 연결\n→ DB 가용성에 영향을 미치는 가동 중단으로 인한 애플리케이션 중단 최소화\n장애 조치 발생 시, 요청을 새 데이터베이스 인스턴스로 직접 라우팅\n→ Aurora 및 RDS 데이터베이스의 장애 조치 시간이 최대 66% 단축\n일반적으로 35초 미만의 장애 조치, 2배 향상된 쓰기 지연 시간, 추가적인 읽기 용량, 마이너 버전 업그레이드 가동 중단 시간을 일반적으로 1초 미만으로 줄일 수 있는 두 개의 읽기 가능한 예비 배포를 포함하는 다중 AZ를 지원\n4. 효율적인 RDS 운용 오토스케일링을 통해 확장된 웹 애플리케이션이 실제 사용해야 하는 것보다 더 많은 수준의 커넥션을 요구하게 되어 관계형 데이터베이스에서 커넥션 연결을 효율적으로 관리해주는 Amazon RDS Proxy 서비스를 최근에 도입했고, 이로써 더 4.효율적인 RDS 운용이 가능해졌습니다.\nAmazon RDS 프록시 인스턴스는 RDS 데이터베이스 인스턴스에 대해 설정된 연결 풀을 유지 관리하므로, 새 연결이 설정될 때 일반적으로 발생하는 데이터베이스 컴퓨팅 및 메모리 리소스를 관리해야 하는 스트레스가 줄어듦 자주 사용하지 않는 데이터베이스 연결을 공유 → RDS 데이터베이스에 액세스하는 연결 수가 줄어듦 이러한 연결 풀링을 통해 DB에서 대량의 빈도와 횟수의 애플리케이션 연결을 효율적으로 지원하여 성능 저하 없이 애플리케이션을 확장 가능 AWS ElastiCache 사용 이유 사용량이 많아짐에 따라 성능 향상과 데이터베이스 부하 감소를 위해서 도입하였습니다. Amazon ElastiCache 메모리에 데이터를 저장하고 검색할 수 있는 분산 캐싱 솔루션을 제공하는 AWS의 관리형 서비스입니다.\nElastiCache는 Redis 및 Memcached 두 가지 인메모리 캐싱 엔진을 지원합니다.\nRedis\n고성능, 오픈 소스 인메모리 데이터 스토어 및 캐시 엔진입니다.\n다양한 데이터 구조를 지원하며, 주로 키-값 형태의 데이터를 저장하고 검색하는 데 사용됩니다.\n데이터 영속성, 복제 및 고가용성(HA) 설정을 지원하여 중요한 데이터에 대해 높은 신뢰성을 보장합니다.\nMemcached\n고성능 분산 메모리 객체 캐싱 시스템으로, 단순한 키-값 캐싱을 위해 사용됩니다.\nElastiCache의 핵심 기능 데이터 캐싱 자주 조회되는 데이터를 메모리에 저장하여 애플리케이션의 데이터 요청을 빠르게 처리할 수 있습니다. 데이터베이스 부하를 줄이고, 데이터베이스 인스턴스의 비용을 절감할 수 있습니다. ElastiCache의 특징 및 이점 마이크로초 응답 시간 핵심 데이터 조각을 메모리에 저장하여 매우 빠른 응답 시간을 제공합니다. 비용 최적화된 성능 선결제 비용이나 장기 약정 없이 사용한 리소스에 대해서만 비용을 지불합니다. 용량 관리 불필요 자동으로 확장 및 축소되며, 사용자는 용량 관리를 직접 신경 쓸 필요가 없습니다. 비지니스 지속성 유지 장애 조치, 백업, 복제 등의 기능을 통해 데이터의 가용성과 내구성을 유지할 수 있습니다. Redis OSS 및 Memcached 호환 가능 기존에 Redis나 Memcached를 사용하고 있던 애플리케이션과 쉽게 통합할 수 있습니다. 확장성 클러스터를 수평으로 확장할 수 있어 성능을 쉽게 조정할 수 있습니다. 보안 기능 VPC 지원, SSL/TLS 암호화, IAM 통합 등 다양한 보안 기능을 제공하여 데이터를 안전하게 보호할 수 있습니다. AWS WAF VPC 피어링 💡VPC(Virtual Private Cloud) 사용자의 AWS 계정 전용 가상 네트워크입니다. 💡VPC 피어링 연결 프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워킹 연결입니다. 각 서비스는 독립적인 VPC를 구축합니다. → 독립적인 아키텍처 기반으로 더 유연한 대응이 가능하도록 합니다. VPC 피어링을 통해 VPC를 연결해 보안을 강화합니다. →트래픽은 항상 글로벌 AWS 백본에서만 유지되고 절대로 퍼블릭 인터넷을 통과하지 않습니다. → 원활한 데이터 전송, 취약점 공격 및 DDoS 공격 위협 감소 ELB(Elastic Load Balancing) 💡로드 밸런싱(Load Balancing) 둘 혹은 셋 이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 부하를 나누는 것입니다. → 가용성 및 응답시간 최적화 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포합니다. ALB 작동 방식 하나 이상의 가용 영역(AZ)에 있는 여러 대상 및 가상 어플라이언스에서 들어오는 애플리케이션 트래픽을 자동으로 분산합니다. 애플리케이션에 대한 사용자의 요청이 발생합니다. 회사가 애플리케이션을 실행하는 여러 서버들의 배열(서버 팜)의 단일 서버로 로드 밸런서가 각 요청을 라우팅합니다. AWS WAF 가용성에 영향 / 보안 위협 / 과도한 리소스 사용 등 일반적인 웹 공격으로부터 웹 애플리케이션이나 API를 보호하는 웹 애플리케이션 방화벽입니다. 사용 이유 온라인으로 서비스 중인 유캔두 서비스의 보안 강화를 위해 채택합니다. 비정상 트래픽을 탐지하고 차단하기 위해 AWS WAF를 이용하여 대응합니다. 작동 방식 Amazon CloudFront나 Application Load Balancer에서 몇 번의 클릭 만으로 배포 가능합니다. CloudFront와 ALB, API Gateway에 Amazon WAF는 연동 가능하지만 보안 측면에서 더 나은 곳을 선택해야 합니다. 야나두는 Application Load Balancer을 사용했습니다. AWS WAF는 클라우드 환경과 온프레미스 환경에서 실행되는 애플리케이션을 보호합니다. 기존 규칙을 사용자 정의하거나 새로운 규칙을 생성해 특정 트래픽 패턴 필터링이 가능해 이를 통해 웹 공격에 대비하여 보안 계층을 추가합니다. 필터링 조건: IP 주소, HTTP 헤더 및 본문 또는 사용자 정의 URI와 같은 조건을 기준으로 웹 트래픽 필터링 규칙을 설정할 수 있습니다. 공격 패턴 차단: SQL 명령어 삽입 또는 XSS(크로스 사이트 스크립팅)과 같은 일반적인 공격 패턴을 차단하는 보안 규칙을 생성할 수 있습니다. AWS Firewall Manager와 AWS WAF의 빠른 규칙 전파를 사용하면 조직 전체에 보호 기능을 쉽고 빠르게 배포해 애플리케이션과 API의 가용성을 유지하고 보호할 수 있습니다. AWS Firewall Manager와의 통합 AWS Firewall Manager를 사용하여 여러 AWS 계정에 걸친 AWS WAF 배포를 중앙에서 구성 및 관리가 가능합니다. (새로운 리소스 생성 시)공통적인 보안 규칙 세트 준수를 보장합니다. Firewall Manager가 정책 위반 여부를 자동으로 감사하고 이를 보고합니다. 💡WAF를 어디에 연동할까? 위에서 말했듯이 보안 측면에서 고려하며 CloudFront, ALB, API Gateway 등 여러 곳 중 어느 곳에 연동할지를 결정해야 합니다.\nCloudFront와 ALB 두 곳에 전부 WAF 연동 CloudFront의 WAF는 L7 DoS 및 임계치 조절, IP Blacklist 차단 규칙으로 WAF룰을 수립합니다. ALB의 WAF는 웹 취약점 공격을 중점으로 룰을 구분하여 수립할 수 있습니다. WAF가 아닌 AWS WAF 도입 시 장점 Cloudfront나 ALB, API Gateway를 사용 중이면 바로 적용할 수 있습니다. 적용 대상과 동일 선상에서 동작하기에 네트워크 홉 추가가 없습니다. 트래픽이 증가하는 상황에서 확장이 유연합니다. 유지보수에 많은 노력이 들어가지 않습니다. 장애 발생 시 원복 시나리오가 간단합니다. 다른 교육 플랫폼들과의 아키텍처 비교 야나두 민병철교육그룹 Class 101 다노 보안성 WAF, VPC VPC 안정성 ALB Auto Scaling, RDS Aurora CloudFront CLB, ALB, NLB 성능 효울성 ALB Elemental MediaConvert CDN Elemental MediaConvert 비용 최적화 Graviton 2 EC2 Elastic Beanstalk, Lambda EKS, EC2 지속 가능성 RDS Aurora, ElastiCache, RDS Proxy Elastic Block Store S3 S3 각 플랫폼 별 특징\n야나두: 온라인 교육 플랫폼으로서 안정적이고 보안이 강화된 네트워크 운영하고, 글로벌 시장 확장을 목표로 하고 있습니다. 민병철 교육 그룹: 민병철교육그룹은 \u0026lsquo;민병철유폰\u0026rsquo; 서비스의 급격한 성장으로 인한 잦은 트래픽 변동에 유연하게 대응하면서, 적은 IT 인력으로도 효율적으로 인프라를 운영할 수 있도록 AWS의 다양한 매니지드 서비스를 활용하고 있습니다. Class 101: 모바일 앱으로 다 수의 동영상 강의를 제공하기 때문에 항상 낮은 레이턴시를 유지해야 합니다. 또한 빠른 실험에 적합한 가벼운 AWS Lambda와 같은 서버리스 컴퓨팅 서비스를 적용하여, 가설이 실험을 통해서 검증되면, 서비스화해 정식으로 제공합니다. 다노: 코로나 사태로 비대면 홈트레이닝 수요가 급증함에 따라, 다노는 안정적인 서비스를 제공하고 개발자들이 비즈니스 로직에 집중할 수 있는 클라우드 서비스가 필요했습니다. Amazon EKS를 도입함으로써, 다노는 서비스의 안정성을 높이고 급증하는 트래픽에 유연하게 대응하며, 개발자들이 인프라 관리 대신 핵심 비즈니스 로직에 집중할 수 있는 환경을 구현했습니다. 향후 목표를 위한 아키텍처 개선 방안 1. 글로벌 시장 진출 고려해야 할 조건\n전 세계의 사용자들과 상호작용이 필요한 동영상 스트리밍을 지연 없이 제공해야 합니다.\n필요한 AWS 서비스 : Amazon IVS (Interactive Video Service), AWS Fargate 💡 Amazon IVS 지연 시간이 짧은 비디오 또는 실시간 비디오를 전 세계 시청자에게 제공하여 몰입감 있는 라이브 환경을 선사하는 관리형 라이브 스트리밍 솔루션입니다. 💡 AWS Fargate AWS Fargate는 사용량에 따라 요금이 부과되는 서버리스 컴퓨팅 엔진입니다. 서버를 관리할 필요가 없기 때문에 애플리케이션 구축에 집중할 수 있습니다. 간단한 라이브 스트리밍 서비스 아키텍처: Simplifying live streaming contribution with Amazon IVS\n2. 원할한 사용자의 니즈 파악 필요한 AWS 서비스 : Amazon SageMaker 💡 Amazon SageMaker 기계 학습을 위한 다양한 목적별 기능 세트를 함께 활용하여 고품질의 기계 학습 모델을 빠르게 준비, 구축, 훈련 및 배포합니다. 💡 AWS Glue 분석, 기계 학습(ML) 및 애플리케이션 개발을 위해 여러 소스에서 데이터를 쉽게 탐색, 준비, 이동 및 통합할 수 있도록 하는 확장 가능한 서버리스 데이터 통합 서비스 SageMaker 워크로드 설명 설계 해본 아키텍처\n1. 데이터 수집 사용자의 니즈를 파악하기 위해 다양한 소스로부터 데이터를 수집합니다.\n데이터 소스: 웹 로그 데이터: 사용자의 클릭 스트림, 페이지 방문 기록 등을 수집합니다. 애플리케이션 로그: 사용자가 애플리케이션 내에서 수행한 작업에 대한 로그 데이터를 수집합니다. 설문조사 및 피드백 데이터: 사용자가 직접 입력한 피드백이나 설문조사 응답을 수집합니다. 소셜 미디어 데이터: 사용자의 소셜 미디어 활동을 수집하여 감정 분석 등에 활용할 수 있습니다. 데이터 수집 도구: Amazon Kinesis: 실시간 스트리밍 데이터를 수집합니다. AWS Lambda: 다양한 소스로부터 데이터를 수집하여 Amazon S3에 저장할 수 있습니다. Amazon S3: 수집된 데이터를 저장하는 데이터 레이크 역할을 합니다. 2. 데이터 전처리 수집된 데이터를 모델에 사용하기 적합한 형태로 전처리합니다.\n데이터 클렌징: 결측치 처리, 중복 제거, 데이터 정규화 등을 수행합니다. 특징 엔지니어링: 모델 학습에 필요한 주요 특징(Feature)을 추출합니다. 데이터 레이블링: 필요한 경우, 데이터를 레이블링하여 학습에 사용합니다. 전처리 도구: Amazon SageMaker Processing: 대규모 데이터 전처리를 자동화하고 병렬 처리합니다. AWS Glue: 데이터 변환, 정제 작업을 수행합니다. 3. 모델 훈련 전처리된 데이터를 사용해 머신러닝 모델을 훈련시킵니다.\n모델 선택: 사용자의 니즈를 파악하기 위해 다양한 모델을 선택할 수 있습니다. 예를 들어, 추천 시스템(협업 필터링, 콘텐츠 기반 필터링)이나 감정 분석 모델 등이 있습니다. 훈련 환경: Amazon SageMaker 훈련 인스턴스를 사용해 대규모 데이터를 효율적으로 처리합니다. 하이퍼파라미터 튜닝: SageMaker의 하이퍼파라미터 튜닝 기능을 사용해 최적의 모델을 생성합니다. 4. 모델 배포 및 실시간 예측 훈련된 모델을 배포하고 실시간으로 예측을 수행합니다.\n모델 배포: Amazon SageMaker Endpoint를 통해 모델을 배포합니다. 실시간 예측: 사용자 데이터가 입력될 때마다 실시간으로 예측을 수행하여 사용자의 니즈를 파악합니다. 서버리스 배포: SageMaker Serverless Inference를 통해 비용 효율적인 서버리스 환경에서 예측을 수행할 수 있습니다. 5. 모니터링 및 피드백 루프 배포된 모델의 성능을 지속적으로 모니터링하고, 새로운 데이터를 통해 모델을 업데이트합니다.\n모델 모니터링: SageMaker Model Monitor를 사용해 모델 성능을 모니터링하고 데이터 드리프트를 감지합니다. 피드백 루프: 새로운 데이터를 통해 모델을 지속적으로 재훈련하여 정확도를 유지합니다. A/B 테스트: 다양한 모델을 테스트하여 가장 효과적인 모델을 선택합니다. 6. 사용자 니즈 파악 및 활용 모델의 예측 결과를 기반으로 사용자의 니즈를 파악하고, 이를 다양한 비즈니스 로직에 활용할 수 있습니다.\n추천 시스템: 사용자가 필요로 할 만한 상품이나 콘텐츠를 추천합니다. 개인화: 사용자의 니즈에 맞춘 개인화된 경험을 제공합니다. 마케팅 전략: 예측된 니즈를 기반으로 맞춤형 마케팅 전략을 수립합니다. 참고 기술 블로그 Amazon SageMaker와 Amazon MWAA를 활용한 29CM의 개인화 추천시스템 MLOps 구축여정 롯데ON 사례로 본 개인화 추천 시스템 구축하기, 2부 : Amazon SageMaker를 활용한 MLOps 구성 및 추천 모델 실시간 서비스 ","permalink":"https://ddwu-aws-cloud-club.github.io/post/2nd/post-4-case-study-yanadoo/","summary":"\u003ch1 id=\"aws-case-study--야나두\"\u003eAWS Case Study : 야나두\u003c/h1\u003e\n\u003cp\u003e8월 27일, 2024 - 김민경, 오은아, 이승연, 최가람, 하서정\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://aws.amazon.com/ko/solutions/case-studies/yanadoo/\"\u003e야나두 사례 연구\u003c/a\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAWS 서비스 중에 가장 만족스러운 기능은 RDS Proxy와 Graviton2이고, 유용하게 잘 사용하고 있습니다. RDS Proxy와 똑같은 기능을 온프레미스 환경에서 구축할 수 있지만, 문제가 발생했을 때 문제를 파악하는데 너무 많은 시간이 소요됩니다.\u003c/strong\u003e\u003c/p\u003e","title":"Case Study: 야나두"},{"content":" 2024.07.14 - 2024.08.04 진행\n💡 Session 실습과 과제 형태로 코어 세션 활동을 진행했어요. AWS의 필수적이고 기초적인 서비스를 학습할 수 있는 재미있는 세션으로 구성했어요. 샌드박스 계정을 제공해서 모든 멤버가 직접 서비스를 실습해 볼 수 있도록 했어요. 세션은 기초, 중급, 심화, Challenge라는 총 4가지 단계로 나눠서 진행됐어요. 기초 세션에서는 S3, RDS, VPC 서비스에 대해 간단하게 이해하고 직접 버킷, 데이터베이스, 네트워크 등을 구성해볼 수 있어요. 중급 세션은 기초에서 더 나아가 EC2, 데이터 마이그레이션, VPC 응용 등 좀 더 심화된 주제로 진행돼요. 심화와 Challenge에서는 AWS를 사용하면서 반드시 관심을 가질 만한 CI/CD, Serverless, MSA 등의 심층적인 이론을 다루고, 실습으로 아키텍처 구성을 진행했어요. Homework 동아리원들이 코어 세션을 진행하고 진행 상황을 작성해서 인증했어요. 모든 동아리원들이 성실하게 코어 세션에 참여해 세션을 훌륭하게 수료했어요! ","permalink":"https://ddwu-aws-cloud-club.github.io/post/2nd/post-1-core-session/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2024.07.14 - 2024.08.04 진행\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-session\"\u003e💡 Session\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e실습과 과제 형태로 코어 세션 활동을 진행했어요.\u003c/li\u003e\n\u003cli\u003eAWS의 필수적이고 기초적인 서비스를 학습할 수 있는 재미있는 세션으로 구성했어요.\u003c/li\u003e\n\u003cli\u003e샌드박스 계정을 제공해서 모든 멤버가 직접 서비스를 실습해 볼 수 있도록 했어요.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cimg alt=\"1\" loading=\"lazy\" src=\"/2nd/core_session/1.png\"\u003e\u003c/p\u003e","title":"Core session"},{"content":" 2023.04.14 / 14:00 - 16:00\njitsi (온라인)\n💡 팀 별 프로젝트 발표 약 한달간 진행된 팀 프로젝트를 발표하고 의견을 주고받았어요. 팀 A: 콘서트 예약 프로그램 MSA기반의 콘서트 예약 프로그램을 구현하고, 선착순 콘서트 예약은 Redis 를 이용하여 구성하고, 개발하였습니다. 자세한 내용은 다음 페이지에서 확인해주세요 팀 B: 수강신청 모의 프로그램 3Tier 아키텍처 기반의 수강신청 모의 프로그램을 구현했습니다. 수강신청 성공을 확인하기 위한 이메일 시스템을 SES를 통해, 선착순 대기열을 Redis을 통해 개발하였습니다. 자세한 내용은 다음 페이지에서 확인해주세요 ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-14-9th-session/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.04.14 / 14:00 - 16:00\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-팀-별-프로젝트-발표\"\u003e💡 팀 별 프로젝트 발표\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e약 한달간 진행된 팀 프로젝트를 발표하고 의견을 주고받았어요.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"팀-a-콘서트-예약-프로그램\"\u003e팀 A: 콘서트 예약 프로그램\u003c/h3\u003e\n\u003cp\u003eMSA기반의 콘서트 예약 프로그램을 구현하고, 선착순 콘서트 예약은 Redis 를 이용하여 구성하고, 개발하였습니다. 자세한 내용은 \u003ca href=\"https://ddwu-aws-cloud-club.github.io/post/1st/post-15-final-proj-a/\"\u003e다음 페이지\u003c/a\u003e에서 확인해주세요\n\u003cimg alt=\"5\" loading=\"lazy\" src=\"/1st/session_3/5.png\" title=\"5\"\u003e\u003c/p\u003e","title":"9th Session: Final Project -  최종 프로젝트 발표"},{"content":"1️⃣ 프로젝트 아키텍처 외부 사용자 또는 클라이언트는 API Gateway를 통해 서비스에 액세스합니다. 각 서비스는 독립적으로 배포되며, EC2 인스턴스에서 실행됩니다. 서비스 별 데이터는 각 RDS 인스턴스에 저장되며, 프라이빗 서브넷에 배치됩니다. API Gateway를 통해 서비스 간 통신이 이루어지며, Gateway는 각 서비스의 IP 및 포트에 대한 정보를 갖고 있습니다. JWT 토큰을 사용하여 인증 및 권한을 부여하고, 서브넷 및 보안 그룹으로 네트워크 보안을 강화했습니다. 유레카 서버는 서비스의 등록 및 검색을 관리하며, 서비스 Discovery를 지원합니다. 2️⃣ 프로젝트 설명 MSA 아키텍처를 사용 : 서비스를 마이크로 단위로 분리\nUser Service : 유저 관련 서비스 담당 Concert Service : 콘서트 관련 서비스 담당 Reserve Service : 선착순 예약 서비스 담당 Eureka Service : 디스커버리 관련 서비스 담당 Gateway Service : 라우팅 관련 서비스 담당 3️⃣ 주요 서비스 기능 설명 Reserve Service 핵심인 선착순 콘서트 예약 = Redis 로 구현\n🔎 Redis를 사용하는 이유? 🔍\n보통 콘서트 예약과 같은 실시간 처리가 중요한 서비스의 경우, 특정 시간에 트래픽이 몰려 서버가 다운되거나 원활하지 않은 이벤트 처리가 되는 경우가 많습니다.\nRedis에서 제공하는 자료구조 Sorted Set 활용 모든 요청이 DB로 가지 않아 부하를 덜 수 있고, 차례대로 일정 범위만큼 처리 할 수 있다는 장점 📌 `**Redis Sorted Set**`은 !!! 한 Key에 대해 여러 value와 score를 가지고 있으며, 중복되지 않는 value를 통해 score순으로 데이터를 정렬하는 자료구조 입니다. 💡 ***우리 프로젝트 적용 방법*** ✔️ Sorted Set의 Key는 Event로 설정\n✔️ Value : 사용자명\n✔️ Score : 이벤트에 참여한 시간을 유닉스타임(m/s) 값으로 설정\n→ 참여한 사람들을 순서대로 정렬\n코드 실행 흐름\n가정 : 콘서트 티켓 30장 / 참여 유저 100명\n100명의 유저가 콘서트 티켓 예약 요청 → 100명의 유저는 대기열에 쌓임\n1초마다 동기화\n→ 예약 성공, 실패 로직 수행\n성공 시, 100명의 유저의 접속 순서대로 10명씩 티켓을 발급한다. 실패 시, 다음 대기열로 돌아가면서 남은 대기열 순번을 표출한다. 해당 과정을 반복하면서 콘서트 티켓 판매(30개 발급 완료)를 종료한다.\n💡 이때 **10개씩 발급하는 이유**는 ❓ DB 부하 문제 실제 서비스 : 100000개의 요청 중 1000개의 티켓을 발급하는 상황이라 가정, 1초마다 50개씩 순차적으로 발급하는 방법으로 DB 부하를 줄일 수 있을 것 같습니다. 주요 코드\nEventScheduler.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 @Slf4j @Component @RequiredArgsConstructor public class EventScheduler { private final TicketService ticketService; **@Scheduled(fixedDelay = 1000) // 1초마다 도는 대기열 동기화 스케줄러 구성** private void concertEventScheduler(){ **if(ticketService.validEnd())**{ log.info(\u0026#34;===== 선착순 티켓팅이 종료되었습니다. =====\u0026#34;); return; } **ticketService.publish(Event.TICKET); ticketService.getOrder(Event.TICKET);** } } 1초마다 도는 대기열 동기화 스케줄러 구성 (예약실패) 콘서트 티켓 30개가 모두 발급되면 선착순 콘서트 예매 종료 (예약성공) 예매가 종료되지 않은 경우, 티켓을 발급하고 남은 대기열에 순번 표출 TicketService.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 @Slf4j @Service @RequiredArgsConstructor public class TicketService { private final RedisTemplate\u0026lt;String,Object\u0026gt; redisTemplate; private static final long FIRST_ELEMENT = 0; private static final long LAST_ELEMENT = -1; private static final long PUBLISH_SIZE = 10; private static final long LAST_INDEX = 1; private EventCount eventCount; public void setEventCount(Event event, int queue){ this.eventCount = new EventCount(event, queue); } public void addQueue(Event event){ final String people = Thread.currentThread().getName(); final long now = System.currentTimeMillis(); redisTemplate.opsForZSet().add(event.toString(), people, (int) now); log.info(\u0026#34;대기열에 추가 - {} ({}초)\u0026#34;, people, now); } public void getOrder(Event event){ final long start = FIRST_ELEMENT; final long end = LAST_ELEMENT; Set\u0026lt;Object\u0026gt; queue = redisTemplate.opsForZSet().range(event.toString(), start, end); for (Object people : queue) { Long rank = redisTemplate.opsForZSet().rank(event.toString(), people); log.info(\u0026#34;\u0026#39;{}\u0026#39;님의 현재 대기열은 {}명 남았습니다.\u0026#34;, people, rank); } } public void publish(Event event){ final long start = FIRST_ELEMENT; final long end = PUBLISH_SIZE - LAST_INDEX; Set\u0026lt;Object\u0026gt; queue = redisTemplate.opsForZSet().range(event.toString(), start, end); for (Object people : queue) { final Ticket ticket = new Ticket(event); log.info(\u0026#34;\u0026#39;{}\u0026#39;님의 {} 티켓이 발급되었습니다 ({})\u0026#34;,people, ticket.getEvent().getName(), ticket.getCode()); redisTemplate.opsForZSet().remove(event.toString(), people); this.eventCount.decrease(); } } public boolean validEnd(){ return this.eventCount != null ? this.eventCount.end() : false; } public long getSize(Event event){ return redisTemplate.opsForZSet().size(event.toString()); } } addQueue() : 이벤트 요청한 유저들을 추가 value : 유저의 고유 값 score : 현재 시간(m/s)으로 대기열에 추가 getOrder() : 차례대로 들어온 유저들의 요청을 기반으로 대기열 순번 표출 publish() : 1초마다 콘서트 예매에 참여하는 사람수(10명)씩 콘서트 티켓을 발급 후 대기열에서 제거 TicketServiceTest.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 @SpringBootTest class TicketServiceTest { @Autowired private TicketService ticketService; @Test void 선착순_100명에게_티켓_30개_제공() throws InterruptedException { final Event ticketEvent = Event.TICKET; final int people = 100; final int limitCount = 30; final CountDownLatch countDownLatch = new CountDownLatch(people); ticketService.setEventCount(ticketEvent, limitCount); List\u0026lt;Thread\u0026gt; workers = Stream .generate(() -\u0026gt; new Thread(new AddQueueWorker(countDownLatch, ticketEvent))) .limit(people) .toList(); workers.forEach(Thread::start); countDownLatch.await(); **Thread.sleep(5000); //발급 스케줄러 작업 시간** final long failEventPeople = ticketService.getSize(ticketEvent); assertEquals(people - limitCount, failEventPeople); // output : 70 = 100 - 30 } private class **AddQueueWorker** implements Runnable{ private final CountDownLatch countDownLatch; private final Event event; public AddQueueWorker(CountDownLatch countDownLatch, Event event) { this.countDownLatch = countDownLatch; this.event = event; } @Override public void run() { ticketService.addQueue(event); countDownLatch.countDown(); } } } 대기열에 사람들을 추가하는 AddQueueWorker 생성 1초마다 도는 티켓 발급, 남은 대기열 동기화 스케줄러의 작업을 위해 Thread.sleep(5000) 설정 ♦️ 결과 ♦️ 100명의 사용자 요청, 30개의 콘서트 티켓 발급을 제외하면 70명이 콘서트 티켓을 받지 못한 것을 확인할 수 있다.\n🎥 Reserve Service 시연영상\n🔎 Concert Service 콘서트 생성 및 조회 RDS, EC2 를 사용하였다. EC2 서버에서 콘서트 생성 및 조회하면 EC2 내부의 concert RDS로 접근하여 C, R 구현 프로젝트 구조\n주요 코드\nConcertRepository.java\n1 2 3 4 @Repository public interface ConcertRepository extends JpaRepository\u0026lt;Concert, Long\u0026gt; { Optional\u0026lt;Concert\u0026gt; findByTitle(String title); } 제목으로 콘서트를 조회하는 Jpa 코드입니다. ConcertService.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 @Service public class ConcertService { private final ConcertRepository concertRepository; public ConcertService(ConcertRepository concertRepository) { this.concertRepository = concertRepository; } // R) 제목으로 콘서트 가져오기 public ConcertResponse getConcertByTitle(String title) { Optional\u0026lt;Concert\u0026gt; concert = concertRepository.findByTitle(title); ConcertResponse concertResponse = null; if (concert.isPresent()) { concertResponse = ConcertResponse.of(concert.get()); } return concertResponse; } // C) 콘서트 생성 public Concert createConcert(ConcertDto concertDto) throws Exception { try { Concert concert = Concert.builder() .title(concertDto.getTitle()) .genre(concertDto.getGenre()) .startDate(concertDto.getStartDate()) .endDate(concertDto.getEndDate()) .price(concertDto.getPrice()) .description(concertDto.getDescription()) .runningTime(concertDto.getRunningTime()) .build(); return concertRepository.save(concert); } catch(Exception e) { System.out.println(e.getMessage()); throw new Exception(\u0026#34;잘못된 요청입니다.\u0026#34;); } } } 콘서트 생성, 조회( C, R ) 를 구현한 서비스 코드입니다 ➕ ***참고사항*** 아래 모든 시연 화면들은 EC2 서버를 중단한 상태이므로 local로 실행한 테스트입니다.\n📍 콘서트 생성\n콘서트 정보를 RequestBody로 기입 후 /concert/create POST 요청 DB(RDS)에 콘서트가 생성 📍 콘서트 제목으로 조회\nRequestParam에 조회하고자 하는 콘서트이름을 넣어 /concert/title GET 요청 해당하는 콘서트 정보가 반환 User Service 회원 정보 서비스 로그인, 회원가입, 로그아웃 JWT 로 구현 EC2, RDS, Redis 사용 구조\n주요 코드\nUserService.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 @Service @Transactional @RequiredArgsConstructor public class UserService { private final UserRepository memberRepository; private final PasswordEncoder passwordEncoder; private final JwtProvider jwtProvider; private final RedisTemplate redisTemplate; private final RefreshTokenRepository refreshTokenRepository; // 로그인 public SignResponse login(SignRequest request) throws Exception { User member = memberRepository.findByAccount(request.getAccount()).orElseThrow(() -\u0026gt; new BadCredentialsException(\u0026#34;잘못된 계정정보입니다.\u0026#34;)); if (!passwordEncoder.matches(request.getPassword(), member.getPassword())) { throw new BadCredentialsException(\u0026#34;잘못된 계정정보입니다.\u0026#34;); } return SignResponse.builder() .id(member.getId()) .account(member.getAccount()) .name(member.getName()) .email(member.getEmail()) .nickname(member.getNickname()) .roles(member.getRoles()) .token(jwtProvider.createToken(member.getAccount(), member.getRoles())) .build(); } //로그아웃 @Transactional public void logout(String refreshToken, String accessToken){ Optional\u0026lt;Long\u0026gt; findUserId = jwtProvider.getUserIdToToken(accessToken); //액세스 토큰 남은 유효시간 Long expiration = jwtProvider.getExpiration(accessToken); //리프레시 토큰 남은 유효시간 Long refreshExpiration = jwtProvider.getExpiration(refreshToken); // 액세스 토큰 유효시간이 남았을 경우에만 로그아웃 수행 if (expiration \u0026gt; 0) { // 액세스 토큰을 만료시킴 // Redis Cache에 저장 redisTemplate.opsForValue().set(accessToken, \u0026#34;logout\u0026#34;, expiration, TimeUnit.MILLISECONDS); } // 리프레시 토큰이 유효할 경우에만 삭제 if (refreshExpiration \u0026gt; 0) { // 리프레시 토큰 삭제 refreshTokenRepository.deleteByUserId(findUserId.get()); } } // 회원가입 public boolean register(SignRequest request) throws Exception { try { User member = User.builder() .account(request.getAccount()) .password(passwordEncoder.encode(request.getPassword())) .name(request.getName()) .nickname(request.getNickname()) .email(request.getEmail()) .build(); member.setRoles(Collections.singletonList(Authority.builder().name(\u0026#34;ROLE_USER\u0026#34;).build())); memberRepository.save(member); } catch (Exception e) { System.out.println(e.getMessage()); throw new Exception(\u0026#34;잘못된 요청입니다.\u0026#34;); } return true; } // 회원 조회 public SignResponse getMember(String account) throws Exception { User member = memberRepository.findByAccount(account) .orElseThrow(() -\u0026gt; new Exception(\u0026#34;계정을 찾을 수 없습니다.\u0026#34;)); return new SignResponse(member); } } 회원가입, 로그인, 로그아웃, 회원 조회가 이루어지는 서비스 코드입니다. SecurityConfig.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 @Slf4j @Configuration @RequiredArgsConstructor @EnableWebSecurity public class SecurityConfig { private final JwtProvider jwtProvider; @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf((csrf) -\u0026gt; csrf.disable()) // CORS 설정 .cors(c -\u0026gt; { CorsConfigurationSource source = request -\u0026gt; { // Cors 허용 패턴 CorsConfiguration config = new CorsConfiguration(); config.setAllowedOrigins( List.of(\u0026#34;*\u0026#34;) ); config.setAllowedMethods( List.of(\u0026#34;*\u0026#34;) ); return config; }; c.configurationSource(source); }) // 세션 관리 설정 제거 및 세션 생성 정책 설정 .sessionManagement(session -\u0026gt; session .sessionCreationPolicy(SessionCreationPolicy.STATELESS) ) // 조건별로 요청 허용/제한 설정 .authorizeRequests(authorize -\u0026gt; authorize // 회원가입과 로그인은 모두 승인 .requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll() .requestMatchers(new AntPathRequestMatcher(\u0026#34;/member/register\u0026#34;, \u0026#34;POST\u0026#34;)).permitAll() .requestMatchers(new AntPathRequestMatcher(\u0026#34;/member/login\u0026#34;, \u0026#34;POST\u0026#34;)).permitAll() .requestMatchers(new AntPathRequestMatcher(\u0026#34;/member/logout\u0026#34;, \u0026#34;PATCH\u0026#34;)).permitAll() // /admin으로 시작하는 요청은 ADMIN 권한이 있는 유저에게만 허용 .requestMatchers(\u0026#34;/admin/**\u0026#34;).hasRole(\u0026#34;ADMIN\u0026#34;) // /user로 시작하는 요청은 USER 권한이 있는 유저에게만 허용 .requestMatchers(\u0026#34;/user/**\u0026#34;).hasRole(\u0026#34;USER\u0026#34;) .anyRequest().authenticated() // 나머지 요청은 모두 거부 // .anyRequest().denyAll() ) // JWT 인증 필터 적용 .addFilterBefore(new JwtAuthenticationFilter(jwtProvider), UsernamePasswordAuthenticationFilter.class) // 에러 핸들링 .exceptionHandling(exception -\u0026gt; exception .accessDeniedHandler((request, response, accessDeniedException) -\u0026gt; { log.error(\u0026#34;Access Denied: {}\u0026#34;, accessDeniedException.getMessage()); // 권한 문제가 발생했을 때 이 부분을 호출한다. response.setStatus(403); response.setCharacterEncoding(\u0026#34;utf-8\u0026#34;); response.setContentType(\u0026#34;text/html; charset=UTF-8\u0026#34;); response.getWriter().write(\u0026#34;권한이 없는 사용자입니다.\u0026#34;); }) .authenticationEntryPoint((request, response, authException) -\u0026gt; { log.error(\u0026#34;Authentication Error: {}\u0026#34;, authException.getMessage()); // 인증문제가 발생했을 때 이 부분을 호출한다. response.setStatus(401); response.setCharacterEncoding(\u0026#34;utf-8\u0026#34;); response.setContentType(\u0026#34;text/html; charset=UTF-8\u0026#34;); response.getWriter().write(\u0026#34;인증되지 않은 사용자입니다.\u0026#34;); }) ); return http.build(); } @Bean public PasswordEncoder passwordEncoder() { return PasswordEncoderFactories.createDelegatingPasswordEncoder(); } } JWT 관련 설정을 한 코드 입니다. JwtAuthenticationFilter.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 public class JwtAuthenticationFilter extends OncePerRequestFilter { private static final String AUTHORIZATION_HEADER = \u0026#34;Authorization\u0026#34;; private static final String BEARER_TYPE = \u0026#34;Bearer\u0026#34;; private final JwtProvider jwtProvider; private ObjectMapper objectMapper; private UserService userService; private RedisTemplate\u0026lt;String, String\u0026gt; redisTemplate; private AuthenticationManager authenticationManager; public JwtAuthenticationFilter(JwtProvider jwtProvider) { this.jwtProvider = jwtProvider; } public JwtAuthenticationFilter(JwtProvider jwtProvider, ObjectMapper objectMapper, UserService userService, RedisTemplate\u0026lt;String, String\u0026gt; redisTemplate) { this.jwtProvider = jwtProvider; this.objectMapper = objectMapper; this.userService = userService; this.redisTemplate = redisTemplate; } public void setAuthenticationManager(AuthenticationManager authenticationManager) { this.authenticationManager = authenticationManager; } @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token = jwtProvider.resolveToken(request); if (token != null \u0026amp;\u0026amp; jwtProvider.validateToken(token)) { // (추가) Redis 에 해당 accessToken logout 여부 확인 String isLogout = (String)redisTemplate.opsForValue().get(token); if (ObjectUtils.isEmpty(isLogout)) { // 토큰이 유효할 경우 토큰에서 Authentication 객체를 가지고 와서 SecurityContext 에 저장 Authentication authentication = jwtProvider.getAuthentication(token); SecurityContextHolder.getContext().setAuthentication(authentication); } // // check access token // token = token.split(\u0026#34; \u0026#34;)[1].trim(); // Authentication auth = jwtProvider.getAuthentication(token); // SecurityContextHolder.getContext().setAuthentication(auth); } filterChain.doFilter(request, response); } // Request Header 에서 토큰 정보 추출 private String resolveToken(HttpServletRequest request) { String bearerToken = request.getHeader(AUTHORIZATION_HEADER); if (StringUtils.hasText(bearerToken) \u0026amp;\u0026amp; bearerToken.startsWith(BEARER_TYPE)) { return bearerToken.substring(7); } return null; } } Jwt가 유효성을 검증하는 Filter 코드입니다. RedisConfig.java\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 @Configuration public class RedisConfig { @Value(\u0026#34;${redis.host}\u0026#34;) private String redisHost; @Value(\u0026#34;${redis.port}\u0026#34;) private int redisPort; @Bean public RedisConnectionFactory redisConnectionFactory() { return new LettuceConnectionFactory(redisHost, redisPort); } @Bean public RedisTemplate\u0026lt;String, String\u0026gt; redisTemplate() { RedisTemplate\u0026lt;String, String\u0026gt; redisTemplate = new RedisTemplate\u0026lt;\u0026gt;(); redisTemplate.setKeySerializer(new StringRedisSerializer()); redisTemplate.setValueSerializer(new StringRedisSerializer()); redisTemplate.setConnectionFactory(redisConnectionFactory()); return redisTemplate; } } Redis 설정 정보를 포함하고 있는 코드입니다. 📍 회원가입\n회원 정보를 RequestBody로 /member/register POST 200OK 로 “true” 반환 📍 로그인\nRequestBody로 ID/PW 를 /member/login POST 요청 토큰이 발생함과 동시에 DB(RDS)에 회원이 등록 → 여기서 반환된 토큰을 복사\n📍 회원 확인 (조회)\nParam으로 ID를 포함해서 토큰과 함께 /member/user/get GET 요청 로그인할 때 복사한 토큰을 Authorization에 Token 부분에 기입 200OK 로 회원 정보가 반환 성공\n🔻 토큰을 기입하지 않으면 401 에러 발생\n실패\n📍 로그아웃\n토큰을 Header에 기입하고 /member/logout으로 PATCH 요청 Redis 접속해서 확인 (로컬이라서 127.0.0.1:6379 포트 이용) → KEYS * 명령어를 입력하면, request 시 보낸 access token이 Redis에 잘 저장된 것을 확인\nKEYS 명령어는 key-value 중 key만 보여준다. Key 만료시간 확인 TTL 명령어로 만료시간을 확인 (유효 시간 : 3600sec) 3162이라고 나오는 건 만료될 때까지 3162sec 남았다는 뜻 value 확인 → 토큰에 대한 value 로 “logout” 이 설정되었음\n그 후로 ElasticCache를 연동하여 로그아웃 구현을 마무리 했어야 했으나, 저희 팀 AWS 비용 이슈로 전체적인 서비스들을 종료시켜놔서 이 부분 구현은 중단 되었습니다.. 4️⃣ Github ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-15-final-proj-a/","summary":"\u003ch2 id=\"1프로젝트-아키텍처\"\u003e1️⃣ 프로젝트 아키텍처\u003c/h2\u003e\n\u003chr\u003e\n\u003cul\u003e\n\u003cli\u003e외부 사용자 또는 클라이언트는 API Gateway를 통해 서비스에 액세스합니다.\u003c/li\u003e\n\u003cli\u003e각 서비스는 독립적으로 배포되며, EC2 인스턴스에서 실행됩니다.\u003c/li\u003e\n\u003cli\u003e서비스 별 데이터는 각 RDS 인스턴스에 저장되며, 프라이빗 서브넷에 배치됩니다.\u003c/li\u003e\n\u003cli\u003eAPI Gateway를 통해 서비스 간 통신이 이루어지며, Gateway는 각 서비스의 IP 및 포트에 대한 정보를 갖고 있습니다.\u003c/li\u003e\n\u003cli\u003eJWT 토큰을 사용하여 인증 및 권한을 부여하고, 서브넷 및 보안 그룹으로 네트워크 보안을 강화했습니다.\u003c/li\u003e\n\u003cli\u003e유레카 서버는 서비스의 등록 및 검색을 관리하며, 서비스 Discovery를 지원합니다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cimg alt=\"Untitled\" loading=\"lazy\" src=\"/1st/final_a/Untitled.png\"\u003e\u003c/p\u003e","title":"Final Project A: 콘서트 예약 프로그램"},{"content":"B팀 프로젝트 소개 솜솜이의 수강 신청을 책임질, 모의 수강신청 프로젝트\nhttps://github.com/ddwu-aws-cloud-club/team-b\n요구사항 및 시나리오 정의\n수강신청 서비스는 새학기가 시작될 때 사용자가 몰릴 것이다. 특정 기간에 사용자 트래픽이 과중된다. 트래픽 분산이 필요하다. 사용자의 데이터와 서비스의 안정성을 위해 이중화 구성(Multi - AZ)이 필요하다. 사용자 1 ~ n 명의 경우 인스턴스 경량화가 필요하다. 사용자가 100명이 될 경우, 관리형 서비스가 필요할 것이다. 사용자가 1000명이상이 될 경우, 부하를 줄이기 위한 아키텍처 구성이 필요하다. ← 저희 서비스에서는 이 부분에 집중하게 되었습니다. 아키텍처 설계 적은 사용자에 대한 고려\n사용자가 100명 이하인 경우 [ 고려 사항 ] 기본 아키텍처 적절한 인스턴스 선택 인스턴스 경량화 - 데이터베이스 분리, web/was 분리 → 3 Tier 구축 기본 보안 및 모니터링 비용 효율적인 구성 [아키텍처 구성] 단일 퍼블릭 서브넷 → Public과 Private으로 분리함으로써 외부 사용자가 접근하는 네트워크와 데이터가 저장된 네트워크를 나눈다.\n인스턴스 경량화를 위해 WEB/WAS 역할을 하는 인스턴스와 DB 역할을 하는 인스턴스를 분리한다.\n사용자는 Route53이라고 하는 DNS서비스를 통해 Public IP를 찾아서 AWS VPC 안에 구성된 인스턴스와 연결하여 서비스를 이용한다.\n퍼블릭 서브넷에 있는 탄력적 ip 가 사용되는 Instance는 Web과 WAS 역할을 하고 프라이빗 서브넷에 있는 인스턴스는 데이터베이스 역할을 한다.\n기본 모니터링\nCloudWatch를 통한 리소스 메트릭 및 로그 모니터링 자동 대시보드 생성, 임계치 초과 알람(Slack 연결) 2계층 구성\n인스턴스 경량화 - 3tier 분리 구축\npublic subnet web server private subnet was db 사용자가 1000명인 경우 여전히 소규모 서비스이기는 하지만 사용자와 트래픽 증가에 대한 대비를 미리 해보자!\n→ 고 가용성에 집중을 하자\n[ 아키텍처 설계 ] HA(고가용성)을 위한 방안 이중화\n다중 가용영역 (Multi -AZ)\n서비스를 보다 안전하게 구성하려면 1개 이상의 가용 영역을 사용해야 한다.\n단일 인스턴스, 단일 데이터베이스 개수를 늘리는 Scale Out\nELB를 이용한 수평적 확장 인스턴스 개수가 여러 개일 때 트래픽을 어떻게 처리할까? → 인스턴스 앞 단에서 사용자 트래픽을 받아서 각 인스턴스에게 분배해줘야 한다. ELB를 사용함으로써 트래픽을 받아 부하를 분산시키고 가용성을 높여줄 수 있다. 트래픽 분산 트래픽 분산 대상 EC2 인스턴스 컨테이너 IP 주소 다중 가용 영역 지원 자동으로 용량 확장 오토 스케일 그룹 지원(자동으로 인스턴스를 ELB에 등록하고 제외) ELB Service ALB(Application Load Balancer) 고가용성, 자동확장 L7기반 로드 밸런서 컨텐츠 기반 라우팅 HTTP, HTTPS, HTTP/2 지원 헬스 체크 세션 유지 모니터링/로깅 Infra 최종 서비스 아키텍처는 다음과 같습니다. CICD 사용 기술 WAF (Web Application Firewall)\nApplication Load Balancer 앞에 WAF를 통해 웹 서버 자원에 대해 유입되는 HTTP(S) 트래픽을 분석하고 차단하였습니다.\nWAF는 Access Control list를 정의하고, 탐지 Rule을 설정함으로써 내부 자원을 보호합니다.\n이중화 구성을 통한 안정성 개선\n다중 가용영역 활용 로드 밸런서를 통한 서버 이중화 ALB를 통해 요청을 적절히 배분하였습니다. 데이터베이스 이중화 Master-Slave 구조 선택(=Primary-Secondary 구조)\n트래픽이 늘어남에 따라 자연스럽게 병목현상이 생길 수 밖에 없으며, 쓰기는 원본 서버에서만 수행하게 하고 읽기는 원본의 복제 서버에서 읽어오게 한다면 쓰기의 기능과 읽기의 기능을 향상시켰습니다.\nMonitoring 아키텍처 구성 prometheus (:9090)\nalertmanager (:9093)\n이벤트 브릿지는 비용 문제와 더불어, 굳이 한 단계를 거쳐 진행 할 필요성을 느끼지 못해 사용하지 않았습니다.\nnode exporter 모니터링 중 조건(위험 감지)이 만족되면 알림을 띄우게 됩니다.\n다음 기본적인 다섯 가지 규칙에 엇나가면 slack 채널에 자동으로 전송됩니다.(현재 개인 채널에서 확인)\n💡 **instanceDown** - 인스턴스가 다운되었을 때 **HostOutOfMemory** - 메모리가 부족한 경우(10% 미만) **HostMemoryUnderMemoryPressure** - 메모리 압력이 높아지는 경우 **HostOutOfDiskSpace** - 디스크 공간이 부족한 경우 **HostHighCpuLoad** - CPU 부하가 높아지는 경우 HostOutOfMemory - 메시지가 가는지 확인을 위해 우선 100% 미만으로 설정함\ngrafana (:3000)\ncpu, memory, network, Disk, File System 상태를 대쉬보드를 통해 모니터링할 수 있습니다.\n현재 Node Exporter로 was의 정보를 가져오며 이를 위해 Node Exporter Full 대쉬보드를 사용하였습니다.\n엔드 포인트 nodeExporter (:9100) from WAS\nWAS 서버의 메트릭을 수집해서 엔드포인트에 노출 부하 테스트 Apache Bench\n💡 ab -n 100 -c 10 -p “courseId.txt” -T “application/json” http://api 15000명이 15000번 요청한다. request 별 반응 시간\nBack-End Redis 대기열 💡 레디스 사용 이유\nRedis에서 제공하는 자료구조 중 하나인 Sorted Set을 활용하여 모든 요청이 DB에 바로 부하가 가지 않고 차례대로 일정 범위만큼씩 처리하는 구성 선착순 이벤트 시 대기하고 있는 인원에 대해 대기열 순번을 표출하기 용이 기프티콘 선착 이벤트 구조 - Sorted Set 을 통한 이벤트 구현\nSorted Set Key에는 EVENT 를 설정합니다. Value에는 **사용자명(Pir, David, Foo, John)**을 설정합니다. 해당 예제는 사용자명으로 했지만 사용자명이 중복일 경우, 사용자에 대한 고유한 값으로 세팅하면 됩니다. Score에는 참여한 사람들을 순서대로 정렬하기 위해, 이벤트를 참여한 시간을 유닉스타임(m/s) 값으로 넣어줍니다. 📌 어플리케이션 구성 - 30개 선착순 이벤트(자리가 30개 있는 경우)시 100명이 요청했을 경우 (1) 100명의 유저가 수강신청을 진행합니다.\n(2) 100명의 유저는 대기열에 쌓이게 됩니다.\n(3) 1초마다 동기화 돼어 과목 마감(성공), 실패 로직을 수행합니다.\n(4) 성공시, 이벤트가 종료되지 않았으면 100명의 유저중 먼저 들어온 순서대로 10명씩 수강 신청을 성공합니다.\n(5) 실패시, 다음 대기열로 돌아가면서 남은 대기열 순번을 표출합니다.\n(6) 해당 과정을 반복하면서 이벤트는 종료(30개 발급완료)합니다\n💡 10개씩 발급하는 이유는 DB 부하를 줄이기 위해서 입니다. 다중스레드를 발생시켜(50개) 동시성 테스트\nLock (Application) avilableSeets이 40일 때\n수강 취소 부분 동시성 제어 (by named Lock) 다중 서버 세션 관리 Lambda + SES 흐름 Lambda를 사용하여 RDS에 접속합니다. Enroll 테이블과(수강신청 기록을 저장하는 테이블) Student 테이블을 Join하여 이메일을 추출합니다. SES을 사용하여 해당 이메일로 수강신청 완료 메일을 보냅니다. SNS에서 SES로 변경한 이유 SNS : SNS를 통해 이메일을 보내기 위해서는 먼저 이메일 주소가 SNS 주제(Topic)에 구독되어 있어야 하며, 이 구독 프로세스는 수동으로 확인 링크를 클릭해야 완료됩니다. 이 방식은 동적으로 변하는 이메일 주소에 대해 자동화된 방식으로 이메일을 보내는 데는 제한이 있습니다. SES : 이메일을 프로그래밍 방식으로 보내는 서비스로, 수신자 목록이 동적으로 결정되며, 데이터베이스의 내용에 따라 변화되는 서비스에 SNS보다 적합합니다. Lambda 함수 코드 (이 코드는 SNS 사용을 기준으로 작성해둔 코드입니다)\nRDS 접속 성공\nSES 생성 계정 샌드박스 해제 필요 - 프로덕션 액세스 요청하기\n샌드박스 상태에서는 등록된 사용자에 한에서만 이메일을 주고 받는 것이 가능합니다. 따라서 계정을 프로덕션 액세스가 가능하도록 AWS측에 요청해야 합니다.\nAWS에 프로덕션 액세스 요청\n1차적으로 요청을 하였으나 더 세부적인 정보가 필요하다는 답변이 왔고, 좀 더 디테일하게 2차적으로 요청을 했습니다. (아직 승인 대기 중인 상태)\nAs Is → To Be 기술적 관점 캐시 서버: ElastiCache for Redis로 마이그레이션 현재는 WAS 인스턴스 내부에서 Redis를 구현하였으나, 추후 캐시 서버를 위한 ElastiCache를 따로 두어 개선하고자 합니다.\n3Tier CICD 개선 현재는 Docker+GithubAction을 통해 CICD 를 진행하고 있습니다.\n해당 방식의 문제\n현재 액션에서 사용하는 방식은 Docker Hub 의 public Repository에 도커 이미지를 업로드하고 있기 때문에, public에서의 보안 문제가 발생할 수 있습니다. 이에 Terraform 을 통한 CICD 파이프라인을 개선한다면 보다 3Tier에 적합하도록 개선할 수 있을것으로 보입니다.\n출처: [CICD] Terraform을 통한 AWS 3 Tier 구성 및 CI/CD 파이프라인 배포 #1 - 아키텍처 및 CICD 흐름 소개\nBastion Host 사용 시 이슈 (pain point) 현재 저희 아키텍처에서는 Bastion host를 사용하여 타 인스턴스에 접근하고 있습니다.\nEC2 접근 방법 변경에 대한 고민\n이에 대해, Bastion host 대신 AWS System Manager Session Manager를 도입하여 보다 안전하게 접근을 관리할 수 있을 것으로 보여, 추후 도입하여 서비스를 개선할 수 있을 것으로 보입니다.\n관련 자료: Amazon EC2 Instance Connect Endpoint 를 활용한 폐쇄된 VPC 환경의 AWS EC2 접근 - LG CNS\nbastion host 사용하는 경우\nBastion Host를 사용하여 Private Subnet의 EC2에 접근한다면 keypair 기반의 접속을 동반 Pain point 지속적인 keypair 관리 이슈 1인 1계정 사용 시 많은 기회비용 발생 폐쇄망에서 사용 불가능 VPN 등 다른 Workaround 방식 필요 추가 리소스 사용으로 인한 자원 비용 및 관리 에포트 추가 발생 일원화 된 접근 제어, 모니터링 불가 추가적인 작업 혹은 솔루션이 필요 Session Manager를 사용하는 경우\nBastion Host 대비 장점 key pair 없이 IAM을 통한 일원화된 EC2 자원 접근 통제 Cloud Trails, SSM Session Logging 을 통한 접근 모니터링 및 감사 가능 Pain point 폐쇄망일 경우 Endpoint를 추가 구성하여야 하는 번거로움이 존재 ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-16-final-proj-b/","summary":"\u003ch2 id=\"b팀-프로젝트-소개\"\u003eB팀 프로젝트 소개\u003c/h2\u003e\n\u003cp\u003e솜솜이의 수강 신청을 책임질, 모의 수강신청 프로젝트\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/ddwu-aws-cloud-club/team-b\"\u003ehttps://github.com/ddwu-aws-cloud-club/team-b\u003c/a\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e요구사항 및 시나리오 정의\u003c/p\u003e\u003c/blockquote\u003e\n\u003cul\u003e\n\u003cli\u003e수강신청 서비스는 새학기가 시작될 때 사용자가 몰릴 것이다.\n\u003cul\u003e\n\u003cli\u003e특정 기간에 사용자 트래픽이 과중된다.\u003c/li\u003e\n\u003cli\u003e트래픽 분산이 필요하다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e사용자의 데이터와 서비스의 안정성을 위해 이중화 구성(Multi - AZ)이 필요하다.\n\u003cul\u003e\n\u003cli\u003e사용자 1 ~ n 명의 경우 인스턴스 경량화가 필요하다.\u003c/li\u003e\n\u003cli\u003e사용자가 100명이 될 경우, 관리형 서비스가 필요할 것이다.\u003c/li\u003e\n\u003cli\u003e사용자가 1000명이상이 될 경우, 부하를 줄이기 위한 아키텍처 구성이 필요하다. ← 저희 서비스에서는 이 부분에 집중하게 되었습니다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch1 id=\"아키텍처-설계\"\u003e아키텍처 설계\u003c/h1\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e적은 사용자에 대한 고려\u003c/p\u003e","title":"Final Project B: 모의 수강신청 프로그램"},{"content":" 2023.03.16 / 18:00 - 19:30\njitsi (온라인)\n💡 팀 별 프로젝트 기획안 발표 지난 2주간 팀 별로 아키텍처를 기획하고 유저 시나리오에 대해 구상했어요. 팀 A 아키텍처 팀 B 아키텍처 ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-13-8th-session-copy/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.03.16 / 18:00 - 19:30\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-팀-별-프로젝트-기획안-발표\"\u003e💡 팀 별 프로젝트 기획안 발표\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e지난 2주간 팀 별로 아키텍처를 기획하고 유저 시나리오에 대해 구상했어요.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"팀-a-아키텍처\"\u003e팀 A 아키텍처\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"2\" loading=\"lazy\" src=\"/1st/session_8/1.png\" title=\"1\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch3 id=\"팀-b-아키텍처\"\u003e팀 B 아키텍처\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"2\" loading=\"lazy\" src=\"/1st/session_8/2.png\" title=\"2\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e","title":"8th Session: Final Project -  아키텍처 기획 및 유저 시나리오"},{"content":" 2023.02.24 / 18:00 - 19:30\njitsi (온라인)\n💡 팀 별 프로젝트 기획안 발표 팀 별 진행할 프로젝트의 기획안을 발표하고, 프로젝트 설계를 진행하며 팀 별 역할을 나누었어요. 팀 A 팀 B ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-12-7th-session-copy/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.02.24 / 18:00 - 19:30\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"-팀-별-프로젝트-기획안-발표\"\u003e💡 팀 별 프로젝트 기획안 발표\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e팀 별 진행할 프로젝트의 기획안을 발표하고, 프로젝트 설계를 진행하며 팀 별 역할을 나누었어요.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"팀-a\"\u003e팀 A\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"2\" loading=\"lazy\" src=\"/1st/session_7/1.png\" title=\"2\"\u003e\u003c/th\u003e\n          \u003cth\u003e\u003cimg alt=\"3\" loading=\"lazy\" src=\"/1st/session_7/2.png\" title=\"3\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch3 id=\"팀-b\"\u003e팀 B\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"2\" loading=\"lazy\" src=\"/1st/session_7/3.png\" title=\"2\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e","title":"7th Session: Final Project - 프로젝트 기획"},{"content":" 2023.02.17 / 18:00 - 19:30\njitsi (온라인)\nPreview 과제 발표 모든 멤버들이 금융 기업에서 중요한 아키텍처 요소에 대해 조사하며, 새롭게 알게 된 사실을 발표했어요.\n💡 Final Project 소개 이전 세션 일정을 뒤로 미루고, Final Project에 대한 소개와 더불어 최종 프로젝트를 진행하게 되었어요. 최종 프로젝트는 두 개의 팀으로 나뉘어 기획부터 구축까지 완료하는 것을 목표로 진행되어요.\n🗓️ 프로젝트 일정 02.17 - 02.24: 프로젝트 기획 진행\n02.25 - 03.16: 아키텍처 기획 및 유저 시나리오\n03.17 - 04.06: 최종 아키텍처 설계 구축\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-11-6th-session-copy/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.02.17 / 18:00 - 19:30\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"preview\"\u003ePreview\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e과제 발표\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e모든 멤버들이 금융 기업에서 중요한 아키텍처 요소에 대해 조사하며, 새롭게 알게 된 사실을 발표했어요.\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"2\" loading=\"lazy\" src=\"/1st/session_6/1.png\" title=\"2\"\u003e\u003c/th\u003e\n          \u003cth\u003e\u003cimg alt=\"3\" loading=\"lazy\" src=\"/1st/session_6/2.png\" title=\"3\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch3 id=\"-final-project-소개\"\u003e💡 Final Project 소개\u003c/h3\u003e\n\u003cp\u003e이전 세션 일정을 뒤로 미루고, Final Project에 대한 소개와 더불어 최종 프로젝트를 진행하게 되었어요.\n최종 프로젝트는 두 개의 팀으로 나뉘어 기획부터 구축까지 완료하는 것을 목표로 진행되어요.\u003c/p\u003e","title":"6th Session: Final Project"},{"content":" 2023.02.03 / 18:00 - 19:30\njitsi (온라인)\nPreview 과제 발표 모든 멤버들이 지난주 세션의 과제였던 ECS 를 통한 모놀리스 -\u0026gt; MSA 관련 실습을 진행했어요.\n💡 Open Session 이번주부터는 멤버들의 오픈 세션과 코어 세션을 격주로 병행하게 되어 오픈 세션의 첫 주자이신 어진님께서 배포전략을 주제로 발표를 진행했어요.\n롤링(Rolling) 배포 Blue/Green 배포 카나리(Canary) 배포 세 가지의 배포 전략을 소개하고, Blue/Green 배포 실습을 진행했어요.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-10-5th-session-copy/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.02.03 / 18:00 - 19:30\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"preview\"\u003ePreview\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e과제 발표\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e모든 멤버들이 지난주 세션의 과제였던 ECS 를 통한 모놀리스 -\u0026gt; MSA 관련 실습을 진행했어요.\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cimg alt=\"2\" loading=\"lazy\" src=\"/1st/session_5/2.png\" title=\"2\"\u003e\u003c/th\u003e\n          \u003cth\u003e\u003cimg alt=\"3\" loading=\"lazy\" src=\"/1st/session_5/3.png\" title=\"3\"\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch3 id=\"-open-session\"\u003e💡 Open Session\u003c/h3\u003e\n\u003cp\u003e이번주부터는 멤버들의 오픈 세션과 코어 세션을 격주로 병행하게 되어 오픈 세션의 첫 주자이신 어진님께서 \u003ccode\u003e배포전략\u003c/code\u003e을 주제로 발표를 진행했어요.\u003c/p\u003e","title":"5th Session: Open Session"},{"content":" 2023.01.28 / 10:00 - 11:30\njitsi (온라인)\nPreview 과제 발표 모든 멤버들이 저번주에 함께 토론한 Case Study에 대해 상대 팀의 Case Study 관련 질문을 주고 받거나, 핵심적인 아키텍처와 관련된 추가 설명을 발표했어요.\n💡 Core Session 저번 키워드 투표에서 가장 많은 관심을 받은 MSA 키워드를 바탕으로, Building Microservices 에 대해 캡틴 유빈이 발표를 진행했어요.\nAWS의 자동화와 관련된 AWS Elastic Container Service AWS Elastic Container Registry 서비스를 소개했어요.\nMSA가 무엇인지, 그리고 이와 관련된 서비스 지향 아키텍처(Service Oriented Architecture)가 무엇인지 이해했어요. Microservices의 특징들을 Monolith와 비교하며 알아보았어요. Distributed Monolith에 대해 이야기하며, 이와 MSA는 어떻게 다른 것이며 MSA를 큰 고민없이 도입했을 때의 문제점에 대해 파악했어요. Decomposing monoliths 진행 과정을 세세히 살펴보며, Monolithic application을 MSA로 마이그레이션 하는 과정을 살펴보았어요. LoadBalancer, ECS, ECR 등을 활용한 최종적인 MSA를 구성하고 이를 실습을 통해 직접 구현해보았어요. ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-9-4th-session/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.01.28 / 10:00 - 11:30\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"preview\"\u003ePreview\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e과제 발표\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e모든 멤버들이 저번주에 함께 토론한 Case Study에 대해 상대 팀의 Case Study 관련 질문을 주고 받거나, 핵심적인 아키텍처와 관련된 추가 설명을 발표했어요.\u003c/p\u003e","title":"4th Session: Core Session"},{"content":" 2023.01.20 / 18:00 - 19:30\njitsi (온라인)\nPreview 과제 발표 저번 주 과제 필수 과제\n추가적인 리소스 조사해오기 - 이해가지 않았던 부분, 궁금했던 부분 핸즈온 복습! 자율 과제\n오늘 공부한 내용 전반적으로 복습하기 Challenge Lab 도전하기 → 도전시 캡틴에게 계정 문의 모든 멤버들이 저번주에 학습한 내용을 복습하고, 핸즈온을 다시 실습하거나, 서버리스 등 추가적인 내용을 조사했어요.\n💡 Case Study 이번 주에는 2주간 각 팀이 조사한 기업 사례를 발표하고 이야기했어요.\n팀 1: Autodesk의 빅데이터 처리 팀 2: 드라마앤컴퍼니의 인프라 아키텍처 팀 1: Autodesk의 빅데이터 처리 Autodesk에서 람다 아키텍처를 바탕으로 람다, hive, s3들을 사용하여 어떤 아키텍처를 구축한 것인지 발표했어요. 자세한 내용은 다음 페이지에서 확인해주세요 드라마앤컴퍼니의 aws 클라우드 도입 이유와 함께 Amazon RDS for Aurora 로 데이터베이스를 마이그레이션 한 사례 등을 발표했어요. 자세한 내용은 다음 페이지에서 확인해주세요\n기업의 복잡한 아키텍처에 대해 함께 발표와 질문을 통해 이해할 수 있는 시간이었어요. 2주간 모든 팀원들이 아키텍처를 조사하기 위해 많은 노력을 하고 함께 토론했어요.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-6-case-study/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.01.20 / 18:00 - 19:30\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"preview\"\u003ePreview\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e과제 발표\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch4 id=\"저번-주-과제\"\u003e저번 주 과제\u003c/h4\u003e\n\u003cp\u003e필수 과제\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e추가적인 리소스 조사해오기 - 이해가지 않았던 부분, 궁금했던 부분\u003c/li\u003e\n\u003cli\u003e핸즈온 복습!\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e자율 과제\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e오늘 공부한 내용 전반적으로 복습하기\u003c/li\u003e\n\u003cli\u003eChallenge Lab 도전하기 → 도전시 캡틴에게 계정 문의\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e모든 멤버들이 저번주에 학습한 내용을 복습하고, 핸즈온을 다시 실습하거나, 서버리스 등 추가적인 내용을 조사했어요.\u003c/p\u003e","title":"3rd Session: Case Study"},{"content":"Autodesk의 빅데이터 처리 Autodesk 사례 연구 - 빅 데이터 처리\n빅데이터를 처리하는 방법, 람다 아키텍처 스트림 처리의 결과를 배치 처리로 치환하다.\nAutoDesk는 실시간에 가까운 데이터 처리를 통해 비용을 최대 90% 절감하고 비즈니스 사용자를 위한 분석 기능을 개선했습니다.\n💡 람다 아키텍처를 왜 사용할까요?\n대용량 데이터는 일반적으로 쿼리에 많은 시간이 소요됩니다. (데이터양에 따라 조회에 몇 시간이 걸릴 수도 있습니다.)\n람다 아키텍처는 스피드 레이어 + 배치 레이어의 조합으로 이런 대용량 데이터에도 어느 정도의 실시간 분석을 지원해줍니다.\n모든 데이터는 반드시 배치 레이어에서 처리합니다. 과거의 데이터를 장기적인 스토리지에 축적하고, 여러 번이고 다시 집계할 수 있게 합니다. 배치 레이어는 대규모 배치 처리를 실행할 수 있는 반면, 1회 처리에는 긴 시간이 걸립니다.\n배치 처리 결과는 서빙 레이어를 통해서 접근 + 응답이 빠른 데이터베이스를 설치 ⇒ 결과를 바로 추출 배치 뷰: 서빙 레이어에서 얻어진 결과 → 정기적으로 업데이트되지만 실시간 정보 X 스트림 처리를 하기 위해 스피드 레이어를 설치 → 결과: 실시간 뷰 (배치뷰가 업데이트될 동안까지만 이용하고 오래된 데이터를 순서대로 삭제) 배치 뷰와 실시간 뷰 모두를 조합시키는 형태로 쿼리를 실행 → 최근 24시간의 집계 결과는 실시간 뷰를 참고하여 그 이전의 데이터에는 배치 뷰를 사용 → 이런 과정으로 배치 처리와 스트림 처리의 결점을 모두 보완하는 람다 아키텍처를 사용하였습니다.\n람다 아키텍처의 장점 실시간 뷰의 결과는 나중에 배치 뷰로 치환 → 스트림 처리의 결과는 일시적으로만 사용되고, 이후 배치 처리에 의해 올바른 결과를 얻습니다. 따라서 스트림처리가 정확하지 않아도 배치 처리만 안정되게 동작하면 스트림 처리를 다시 실행할 필요가 없습니다. 레이어 정리 배치레이어\n기존 데이터처리를 위한 배치 프로세스\n데이터를 처리하는 단위(unit)로 데이터가 입력되면 해당 단위로 데이터 처리를 하게 됩니다. 입력되는 데이터는 마스터데이터 셋이라고 해서 저장되거나 읽기만 가능하고 변경은 안되는 immutable data set의 성질을 갖습니다. 단위 프로세스로 처리되기 때문에 해당 단위의 처리시에 이후에 들어온 데이터는 처리하지 못합니다. 특정단위의 배치 프로세스이기 때문에 데이터의 정합성이나 충돌, 동시성, 이상현상, 장애등에 대해서 비교적 자유로운 특성을 갖습니다. 스피드레이어\n실시간 데이터를 처리하고 응답시간을 빠르게 유지 및 집계\n배치 레이어를 사용하여 대용량 데이터 조회 속도의 이슈를 해결했지만, 배치가 도는 간격의 사이에 있는 데이터는 조회할 수 없습니다. 그래서 배치 레이어에서 생기는 이러한 갭을 채우기 위한 역할을 합니다. 스트림으로 들어온 데이터를 처리하기 위한 큐나 버퍼같은 구조를 사용하고 효율적 스트림처리를 위한 증분처리 방식을 사용합니다. 배치프로세스가 완료된 시점에는 처리된 실시간 뷰는 삭제되게 됩니다. 서빙레이어\n배치에 의해서 처리된 요약 데이터를 제공\n배치 레이어 및 스피드 레이어의 출력을 저장합니다. 클라이언트에서는 이 서빙 레이어에 미리 계산된 데이터를 조회하기 때문에 빠른 응답이 가능합니다. 장단점\n이와 같은 3계층의 람다 아키텍처는 데이터의 정확성,일관성을 제공함과 동시에 최소의 지연으로 실시간적인 결과를 사용자에게 제공하는 장점이 있습니다.\n배치레이어와 스피드레이어의 분리로 인한 관리포인트의 증가 배치처리와 실시간처리시의 개발언어나 오픈소스 인프라의 컨셉자체가 틀려 고려할 사항이 많고 이에 따라 기능이 중복되고 관리/유지보수에 많은 공수가 투입되며 복잡 아키텍처 설명 람다 아키텍쳐는 특정 솔루션에 종속적이지 않습니다. 따라서, 데이터의 처리 기법을 소개하는 레퍼런스 아키텍쳐로 이해해야 하며, 운영하는 서비스의 특성을 고려하여 솔루션을 선택하고 조합합니다.\n결론적으로, 람다 아키텍처의 솔루션으로 사용될 수 있는 조합은 매우 다양합니다. 아래는 다른 솔루션 조합의 예시입니다.\nAutoDesk는 공개한 아키텍처에서 일부 내용을 비공개 혹은 표현하지 않았습니다. 따라서 작성한 아키텍처 솔루션은 일부 아키텍처로만 추측한 내용이므로 틀린 내용이 있을 수 있습니다.\nAutodesk의 실제 아키텍처\n저장소(=마스터 데이터 셋)\n대량의 데이터를 저비용으로, 안정성 있게 (유실이 없게) 저장할 수 있는 것이 필요합니다. 그리고 이런 대량의 데이터를 배치로 처리할 때 되도록이면 빠른 시간내에 복잡한 알고리즘을 적용해서 계산할 수 있는 계층이 필요합니다.\n👉Autodesk는 이를 위해 AWS S3를 사용하였습니다.\n스피드 레이어 실시간 처리\n실시간 처리는 복잡한 알고리즘을 빠르게 데이터를 처리할 수 있는 솔루션이 필요한데, 대표적으로 Apache Storm등이 있으며, 이 아키텍처에서는 AWS Lambda 함수를 통해 처리될 것으로 보입니다.\n실시간 뷰\n빠른 읽기와 쓰기를 지원해야 하기 때문에, Redis와 같은 In-memory 기반의 NoSQL이 적절하게 추천됩니다.\n👉Autodesk에서는 실시간 뷰로 dynamoDB를 사용하였습니다.\n배치 레이어 배치 처리\nHive는 MapReduce를 이용해 데이터를 처리하는데, 이는 람다 아키텍처의 배치 레이어에서 대규모 데이터셋을 처리하는 데 사용될 수 있습니다. 이 과정에서 Hive는 데이터를 집계, 변환, 로딩하는 등의 배치 작업을 수행합니다. 메타데이터를 업데이트하기 위해 Hive가 사용되며, 이는 배치 레이어가 데이터를 관리하고 처리하는 역할의 일부일 수 있습니다.\nOptimal Batch Converter (AWS Glue와 같은 AWS 서비스나 다른 서드파티가 사용되었을 수 있습니다.)\n배치 뷰\n아키텍처에 특정 기술로 명시적으로 표시되지 않았지만, 데이터 웨어하우스(AWS Redshift) 나 Hadoop/HDFS 또는 Amazon S3와 같은 파일 저장 시스템에 저장될 수 있습니다.\n→ 해당 아키텍처에서는 전반적으로 이벤트 기반의 서버리스 서비스인 AWS Lambda를 광범위하게 활용합니다.\n개선 방안 람다 아키텍처의 재구성 RDBMS를 활용한 유연성 증대 방안\n이러한 람다 아키텍쳐는 대용량 데이터 처리와 실시간 정보 제공을 위한 장점을 가지고 있음에도 불구하고 대부분 하둡이나 NOSQL등의 솔루션을 조합해서 구현하는 경우가 대부분이기 때문에, 유연성 측면에서 문제점을 가지고 있습니다.\n🔑 예시\n배치 뷰를 HBase를 사용하고, 실시간 뷰를 Redis를 사용할 경우, 상호 솔루션간 데이터 조인이 불가능할 뿐더러, 인덱스나 조인,그룹핑, 소팅 등이 어렵습니다. 이러한 기능이 필요하다면 각각 배치 처리와 실시간 처리 단계에 추가적으로 로직을 추가해서 새로운 뷰를 만들어야 합니다.\n이를 더 쉽게 설명하면, 일반적인 NoSQL은 키-밸류 스토어의 개념을 가지고 있습니다.\n일별 배치로 생성된 이벤트 데이터 테이블\n그래서 위와 같은 테이블이 생성되었다 하더라도, 특정 컬럼 별로 데이터를 소팅해서 보여줄 수 없습니다. 만약 소팅된 데이터를 표현하고자 한다면, 소팅이 된 테이블 뷰를 별도로 생성해야 합니다.\n→ 이런 문제점을 보강하기 위해서는 실시간 뷰와 배치 뷰 부분을 RDBMS를 사용하는 것을 고려해볼 수 있습니다. 쿼리에 특화된 OLAP 데이터 베이스를 활용하는 방법도 있고, 또는 HP Vertica 등을 활용할 수 있습니다. (HP Vertica는 SQL을 지원하지만, 전통적인 RDBMS가 데이터를 행 단위로 처리하는데 반하여, Vertica는 데이터를 열 단위로 처리해서 통계나 쿼리에 성능이 매우 뛰어납니다. 유료이지만 1테라까지는 무료로 사용할 수 있으니 뷰 테이블 용도 정도로 사용하는데는 크게 문제가 없습니다.)\n카파 아키텍처 선택 스피드 레이어와 배치 레이어가 모두 똑같은 처리를 구현하고 있으므로 중복된 비즈니스 로직 및 두 경로의 아키텍처 관리에 따른 복잡성이 발생합니다. → 이 때문에 람다 아키텍쳐를 단순화한 \u0026lsquo;카파 아키텍쳐(Kappa architercutre)\u0026lsquo;를 선택하기도 합니다.\n1. Near Real Time Data Stream 실시간에 가까운 데이터 스트림 (✍️ 세은 어진)\n2️⃣ Part 1(Near Real Time Data Stream) 목차\n아키텍처 흐름 설명 실시간 처리를 위한 Lambda 사용 데이터 레이크로서의 S3 사용 a. 데이터 웨어하우스와 데이터 레이크 비교 SQS(DLQ) SNS DataDog Apache Hive 아키텍처 최대 10배 이상으로 급증하는 수신 데이터를 처리할 수 있도록 기존 시스템을 개선 + 데이터 처리 속도와 가용성을 1시간으로 개선하고 처리 비용을 70% 줄이기\n높은 처리량, 짧은 지연 시간, 실시간에 가까운 처리를 달성하기 위해 Autodesk는 Amazon DynamoDB를 통합했습니다. ADP는 Amazon DynamoDB를 사용하여 수천 건의 동시 요청을 수밀리초 내에 처리합니다. 또한 Amazon Simple Storage Service(S3)를 사용하여 안전한 데이터 레이크를 구축하고 높은 데이터 가용성을 달성했습니다. 흐름 1 . Raw Data 저장: Amazon S3에 원시 데이터가 저장됩니다.\na . 원시 데이터는 Amazon S3에 저장됩니다. S3는 인터넷 스토리지 서비스로, 대량의 데이터를 안전하게 저장하고 검색할 수 있는 데이터 레이크의 역할을 합니다.\nb . 데이터 레이크는 원시 데이터를 그대로 저장해두는 공간으로, 데이터 웨어하우스와는 달리 구조화하지 않은 상태로 데이터를 저장합니다.\n2 . SNS 알림: Amazon SNS를 통해 원시 SNS 알림이 발송됩니다.\na . 원시 데이터가 S3에 저장되면, Amazon SNS를 통해 알림이 발생합니다.\nb . SNS는 분산 애플리케이션, 마이크로서비스, 서버리스 애플리케이션 등에 대한 메시지 전달을 담당합니다.\n3 . 데이터 정제 및 보강: Lambda가 데이터 정제와 보강을 담당합니다.\na . 만약, 데이터 정제 및 보강이 실패한다면 DLQ에서 해당 이슈를 캐치합니다.\nb . DLQ에서 문제가 된 데이터를 File Copy Lambda로 전달합니다.\nc . File Copy Lambda는 데이터를 복사하여 Failed S3 Location에 저장합니다.\nd . Failed S3 Location에 저장된 데이터들은 나중에 다시 검토하거나 추가적인 조치를 취할 수 있습니다.\n💡 기존의 배치 처리 모델은 일정한 주기로 데이터를 처리하는 방식에서 AWS Lambda를 사용하여 데이터가 수신되는 즉시 해당 데이터를 처리예약된 시간에 데이터 처리를 기다리지 않고도 데이터를 실시간으로 처리할 수 있게 해주는 효과를 냅니다.\nLambda 함수가 이벤트를 트리거하면 DynamoDB는 이에 대한 신속하고 효율적인 응답을 제공하여 동시 다발적인 요청에 효과적으로 대응합니다.\n4 . Update Metadata\na . Hive를 사용하여 해당 데이터와 관련된 메타데이터 업데이트를 진행합니다.\nb . 메타데이터 업데이트는 데이터의 구조, 스키마, 타입 등의 정보를 정리하고, 데이터의 검색 및 관리를 용이하게 하기 위한 목적으로 이루어집니다.\n💡 복잡한 MapReduce 작업을 SQL-like 쿼리로 간소화하여 대용량 데이터의 처리를 쉽게 해주는 데이터 웨어하우스 도구입니다.\nHive는 Hadoop 클러스터 위에서 동작하므로 Hadoop의 확장성과 안정성을 그대로 활용합니다. 대용량 데이터를 처리하는 데에는 Hive가 더 적합합니다.\n5 . 모니터링 및 경고: 전체 시스템은 DataDog를 통해 모니터링되며, 이상 징후나 오류에 대해 경고해줍니다.\na . AWS 서비스들과 연동된 DataDog을 통해 전체 데이터 처리 과정을 모니터링 합니다.\nb. 이를 통해 시스템의 정상 작동 상태를 유지하고, 문제가 발생하면 신속하게 대응할 수 있습니다.\n6 . 로그 처리: 처리된 데이터 로그는 \u0026lsquo;Clean Logs’ S3에 저장되고, 문제가 있는 로그는 \u0026lsquo;Dirty Logs\u0026rsquo;로 분류되어 별도로 관리됩니다.\na .정제된 데이터는 \u0026lsquo;clean logs\u0026rsquo;로, 정제되지 못한 데이터는 \u0026lsquo;dirty logs\u0026rsquo;로 분류되어 다시 S3에 저장됩니다.\n💡 이렇게 데이터 레이크에 저장된 로그 데이터는 필요에 따라 추출, 변환, 로드(ETL) 작업을 거쳐 분석 및 처리됩니다.\nLambda 실시간에 가까운 처리를 위해 람다를 어떻게 사용했는가\n데이터가 S3에 도착하는 즉시 수집한 데이터를 자동으로 정리하고 보강하는 Lambda 함수를 트리거하여 실행합니다. Lambda의 특성상 위 과정은 처리를 위한 사전 설정된 서버가 없어도 이루어지며, 필요한 컴퓨팅 리소스를 동적으로 할당받아 사용합니다. ⇒ 이를 통해 데이터 처리 시간을 단축하고, 처리량이 갑자기 증가해도 유연하게 대응할 수 있습니다.\nS3 데이터 레이크로서 어떻게 활용했는가\n데이터 웨어하우스와 데이터 레이크 비교\n데이터 레이크 데이터 웨어하우스 데이터 형식 원시 데이터 및 비정형 데이터와 같은 모든 구조의 데이터 저장이 가능합니다. 구조화된 형식으로 저장합니다. 유연성 다양한 데이터 분석 도구와 호환됩니다. 더 큰 유연성 제공합니다. 특정 스키마에 맞춰진 쿼리를 위해 최적화된 구조입니다. 처리 목적 대규모 데이터 처리, 복잡한 분석, 데이터 마이닝, 머신 러닝, etc\u0026hellip; 비지니스 인텔리전스와 같은 정형화된 보고서 분석 성능 다양하고 복잡한 분석이 가능합니다. 종종 처리 속도가 느릴 수도 있습니다. 빠른 읽기 및 쿼리 성능을 위해 최적화되어 있습니다. 비용 더 낮은 비용으로 더 많은 스토리지 볼륨을 확보할 수 있습니다. 다양한 형태의 데이터 저장: S3에는 다양한 소스로부터 수집된 원시 데이터가 저장됩니다. 이 데이터는 구조화되지 않은 로그 파일, JSON, CSV 등 다양한 형식을 가질 수 있습니다.\n유연한 데이터 접근 및 분석: S3에 저장된 데이터는 필요에 따라 다른 AWS 서비스(ex. Lambda, Apache Hive)에 의해 접근되고 처리됩니다. 이를 통해 데이터를 정제하고, 보강하며, 분석에 필요한 형태로 변환합니다.\n대규모 데이터 처리: 데이터 레이크로서 S3는 대용량의 데이터를 저장하고 관리할 수 있는 능력을 가지고 있습니다. 따라서 실시간에 가까운 데이터 스트리밍 및 분석이 가능합니다.\nSQS (DLQ) 배달 못한 편지 대기열, Dead Letter Queue\nSQS : 완전 관리형 메시지 대기열 서비스입니다. 서버리스 애플리케이션 간에 메시지를 안전하게 전송, 저장 및 수신을 할 수 있게 해줍니다. SQS가 Lambda 함수의 트리거로 설정되는 것이 일반적입니다. Dead Letter Queue (DLQ) : SQS의 구성요소로, SQS 메시지 큐에서 처리되지 못한 메시지를 보관하는 곳입니다. SQS는 메시지를 서비스 간에 전달하는 역할을 하는데, 여기서 메시지가 정상적으로 처리되지 않을 경우(예: 오류 발생, 처리 시간 초과 등), 해당 메시지는 DLQ로 이동합니다. DLQ를 사용하면 실패한 메시지를 분리하여 관리할 수 있으며, 이를 통해 문제 해결과 재처리를 용이하게 할 수 있습니다. DLQ는 시스템의 안정성과 신뢰성을 높이는 데 중요한 역할을 합니다. SNS 데이터 처리 과정 중에 발생하는 중요한 이벤트들에 대해 알림을 제공하는 역할\nRaw data가 S3에 성공적으로 저장되었을 때, 이 정보를 Lambda 함수에 알려주고 있습니다. DataDog 대규모 애플리케이션 및 인프라를 위한 SaaS 기반 모니터링 및 분석 플랫폼\n클라우드 기반의 모니터링 서비스로, 시스템의 성능, 상태, 오류 등을 실시간으로 추적할 수 있습니다. 이 시스템에서는 데이터의 정제 및 보강 과정을 DataDog를 사용하여 실시간으로 모니터링 하고 있습니다. 문제 발생시 DataDog는 즉각적인 경고나 알림을 제공하여 시스템 관리자나 개발자가 빠르게 대응할 수 있도록 해줍니다. (ex. 데이터 처리 지연, 시스템 성능 저하, 프로세스 중단, etc) 데이터 처리 과정의 안정성과 효율성을 보장하는 데 중요한 역할을 수행합니다. Apache Hive Hadoop 기반 데이터 웨어하우스 소프트웨어로, 대규모 데이터셋을 관리하고 분석하는 데 사용\n이 시스템에서 Hive는 메타데이터 업데이트를 위해 사용되고 있습니다. Hive는 SQL과 유사한 HQL(Hive Query Language)을 제공하여, 사용자가 복잡한 데이터 처리 작업을 쉽게 수행할 수 있도록 합니다. 메타데이터 : 다른 데이터를 정의하고 기술하는 데이터입니다. 메타데이터를 업데이트함으로써, 데이터가 더 잘 조직되고 검색이 용이해지며, 추후 데이터의 관리 및 사용에 있어서 중요한 역할을 합니다. 왜 Hive인지 SQL과 유사한 쿼리 언어: Hive는 SQL과 유사한 HQL을 사용하여 데이터에 쉽게 접근하고 분석할 수 있습니다. 익숙한 언어를 사용하여 빅데이터를 다룰 수 있게 해줍니다. 데이터 웨어하우스에 최적화: Hive는 데이터 웨어하우스를 위해 설계되었으며, 대규모 데이터의 관리 및 쿼리에 효과적입니다. 참고 ) https://velog.io/@anjinwoong/Hive-Hive-의-특징 2. Batch Support 배치 지원 (✍️ 현정 희진 유빈)\n2️⃣ Part 2(Batch Support) 목차\nETL 소개 Lambda 소개 배치 처리 모델(이전 아키텍처) vs. 이벤트 기반 모델(Lambda) 아키텍처 설명 Lambda + DynamoDB → ETL 처리 과정 Hive (Hadoop + Hive) 심화 내용 + 생각해 본 내용 ETL Extract(추출), Transform(변환, 가공), Load(로드)의 머리 글자를 딴 것 입니다. 추출, 전환, 적재(ETL)는 다양한 소스의 데이터를 데이터 웨어하우스라고 부르는 대형 중앙 집중식 리포지토리에 결합하는 과정입니다. ETL은 원시 데이터를 정리 및 구성해서 스토리지, 데이터 분석, 기계 학습(ML)용으로 준비하기 위한 비즈니스 규칙 세트입니다. 사용자는 데이터 분석(비즈니스 의사 결정의 결과 예측, 보고서 및 대시보드 생성, 운영 비효율성 저감 등)을 통해 특정 비즈니스 인텔리전스 요구 사항을 해결할 수 있습니다. 추출(Extract) 데이터 추출은 하나 이상의 여러 소스에서 데이터를 가져오는 작업입니다. 추출 방식에 있어서 배치 ETL와 실시간 ETL(스트리밍 ETL)의 두 가지 범주로 나눌 수 있습니다. 배치 ETL은 지정된 시간 간격으로만 소스에서 데이터를 추출하고, 스트리밍 ETL은 데이터 추출 가능 즉시 ETL 파이프라인을 통과합니다. 변환(Transform) ETL을 수행하기 위해 비정형 데이터를 정형으로 재정렬하거나, 추출한 데이터를 몇 개의 필드로만 제한 하는 등의 변경 작업이 발생합니다. 로드(Load) 위 프로세스를 통해 데이터를 준비했다면 어딘가의 데이터 저장소에 로드 해야합니다. 일반적으로 데이터베이스는 BI 및 분석 시스템과 함께 작동하도록 설계된 중앙 집중식 레포지토리인 통합 데이터 웨어하우스입니다. ETL이란 무엇인가요? - 추출, 전환, 적재 설명 - AWS\nLambda Lambda는요 .. !\n서버를 프로비저닝 또는 관리하지 않고도 실제로 모든 유형의 애플리케이션과 백엔드 서비스에 대한 코드를 실행할 수 있는 이벤트 중심의 서버리스 컴퓨팅 서비스입니다. 여기서 서버리스 컴퓨팅이란 서버의 설정과 관리 없이 백엔드 서비스를 운영할 수 있게 해주는 클라우드 컴퓨팅 실행 모델입니다. 사용자는 코드 작성에만 집중하고, 나머지 인프라 관리는 AWS가 담당하게 됩니다. 이는 개발자가 인프라에 대한 고민 없이, 더 빠르고 효율적으로 애플리케이션을 개발하고 배포할 수 있게 해줍니다. Lambda를 사용하면 사용자 지정 로직을 통해 다른 AWS 서비스를 확장하거나, AWS 규모, 성능 및 보안으로 작동하는 자체 백엔드 서비스를 만들 수 있습니다. 계속 실행시키는 작업 대신 특정한 시기에만 실행시키는 경우에 Lambda를 사용하면 유용합니다. 빠르게 확장하고 수요가 없을 때는 0으로 축소해야 하는 애플리케이션 시나리오에 이상적인 컴퓨팅 서비스입니다. 이번 아키텍처에서는 파일 extract 와 이벤트 통계를 위해 사용합니다. 자세한 내용은 아래 “이 목차” 에서 확인할 수 있습니다.\nLambda를 언제 사용할까요? 복잡도가 낮은 코드: Lambda는 최소한의 변수와 타사 종속성을 사용하여 코드를 실행하기 위한 완벽한 선택입니다. 복잡도가 낮은 코드가 포함된 쉬운 작업을 간소화된 방식으로 처리할 수 있습니다. 실행 시간 단축: Lambda는 가끔식 발생하는 작업을 실행하는 데 적합하며 몇 분 내에 실행될 수 있습니다. 드문 트래픽: 기업은 서버가 유휴 상태일 때 이를 싫어하며 여전히 비용을 지불해야 합니다. 기능별 지불 모델은 컴퓨팅 비용을 크게 절감하는 데 도움이 될 수 있습니다. 실시간 처리: AWS Kinesis와 함께 사용되는 Lambda는 실시간 배치 처리에 가장 적합합니다. 예약된 CRON 작업: AWS Lambda 기능은 예약된 이벤트가 정해진 예약 시간에 작동하도록 하는 데 적합합니다. 배치 처리 모델(이전 아키텍처) vs. 이벤트 기반 모델(Lambda) 실행 방식: 배치 처리 모델: 일정한 주기(일반적으로 시간 단위 또는 일 단위)로 데이터를 일괄적으로 처리하는 방식입니다. 데이터가 쌓이면 주기적으로 일괄 처리 작업이 실행되어 데이터를 분석하고 결과를 생성합니다. 이벤트 기반 모델 (Lambda): 데이터 이벤트가 발생할 때마다 즉각적으로 반응하는 방식입니다. 특정 이벤트(예: 데이터 도착, 파일 업로드 등)가 발생하면 AWS Lambda 함수가 트리거되어 이벤트를 처리하고 필요한 작업을 수행합니다. 실시간 처리: 배치 처리 모델: 주기적인 일괄 처리로 인해 데이터 분석 결과가 일정 시간에 한 번씩 생성되므로 실시간 처리에는 적합하지 않습니다. 이벤트 기반 모델 (Lambda): 이벤트가 발생하자마자 Lambda 함수가 실행되므로 거의 실시간으로 데이터를 처리할 수 있습니다. 데이터 처리 지연: 배치 처리 모델: 일정한 주기에 따라 데이터 처리를 수행하므로, 데이터 수신부터 결과 생성까지의 시간이 상대적으로 길 수 있습니다. 이벤트 기반 모델 (Lambda): 이벤트가 발생하자마자 처리되므로 거의 실시간으로 데이터를 처리하며, 지연 시간이 짧습니다. 아키텍처 설명 Batch: 데이터를 실시간으로 처리하는게 아니라, 일괄적으로 모아서 처리하는 작업\n💡 배치 처리 모델 → 이벤트 기반 모델 (Lambda) - Autodesk는 예약된 시간에 데이터를 처리하면서 분석을 지연시키는 것이 아니라, 수신되는 데이터를 즉시 처리할 수 있게 되었습니다.\nBatch Support에서는 위에서 설명한 아키텍처의 배치 레이어에 대해 다룹니다.\n1 과정에서 S3에 저장한 clean logs(정제된 데이터)에서 파일과 이벤트 통계를 람다로 extract 하고, 그 데이터를 DynamoDB에 적재합니다.\nDynamoDB는 하단 람다와 함께 적절한 사이즈의 파케이(= 하둡에서 칼럼방식으로 저장하는 저장 포맷) 파일 메타데이터로 제공합니다. 람다는 매시간 Hive에 메타데이터를 업로드하는 함수를 호출합니다.\n람다는 최적의 배치 변환기를 통해 매시간마다 최적화 된 보강 데이터 / 지연 데이터를 S3에 저장합니다. 배치 레이어의 저장소에는 가공전의 원본 데이터를 모두 저장합니다. 데이터가 처리된 후에도 저장소에 데이터를 삭제하지 않습니다.\n이렇게 원본 데이터를 저장함으로써, 배치 뷰의 데이터가 잘못 계산되었거나 유실되었을때, 복구가 가능하고, 현재 데이터 분석에서 없었던 새로운 뷰(통계)를 제공하고자 할 때 기존의 원본 데이터를 가지고 있음으로써, 기존 데이터에 대해서도 새로운 뷰의 통계 분석이 가능하게 됩니다.\nLambda + DynamoDB → ETL 처리 과정 이번 아키텍처에서는 파일 extract 와 이벤트 통계를 위해 Lambda를 사용합니다.\n이때 DynamoDB와 연동하여 ETL(추출 변환 로드) 과정을 진행합니다. DB 테이블의 데이터 변경에 대해 변환 작업을 수행할 수 있습니다.\nDynamoDB란? AWS에서 제공하는 서버리스 기반 Key-Value NoSQL 데이터베이스입니다. Serverless Batch Processing S3에 어떤 오브젝트가 들어왔을 경우 Lambda Splitter가 Mapper에 작업을 분배합니다. Mapper들은 작업이 끝난 후 DynamoDB에 저장됩니다. Lambda Reducer가 S3로 다시 아웃풋합니다. Pull Event Type(Model) Pull 이벤트 모델에서는 AWS Lambda가 직접 데이터를 생성하는 것이 아니라, 데이터 소스에서 Lambda 함수를 트리거하도록 허용하는 방식입니다.\n대표적인 예시로는 Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS), Amazon EventBridge (CloudWatch Events) 가 있습니다.\nPull Event 모델을 사용하면 데이터 소스에서 데이터가 생성되는 시점이나 이벤트가 발생하는 시점에 따라 Lambda 함수를 트리거할 수 있어서 이벤트 중심 아키텍처를 구성하는 데 효과적입니다.\n실시간에 가까운 처리에서 S3 clean logs 에 저장된 데이터를 Extract합니다.\nHive Apache Hive Hive는 Hadoop 에코시스템 중에서 데이터를 모델링하고 프로세싱하는 경우 가장 많이 사용하는 데이터 웨어하우징용 솔루션입니다. Hadoop을 기반으로 빌드되었기 때문에 페타바이트 규모의 데이터를 신속하게 처리할 수 있습니다. Apache Hadoop Distributed File System(HDFS)에서 추출한 대용량 데이터 세트를 읽고, 쓰고, 관리하도록 설계된 오픈 소스 데이터 웨어하우스 소프트웨어입니다. 사용자가 SQL을 사용하여 페타바이트 데이터를 읽고 쓰고 관리할 수 있도록 합니다. SQL과 유사한 인터페이스로 Apache Tez 또는 MapReduce를 사용하여 대규모 데이터 세트를 쿼리할 수 있습니다. 광범위한 Apache Hive 문서 및 지속적 업데이트를 통해 쉽게 액세스할 수 있는 방식으로 계속해서 데이터 처리를 혁신합니다. 데이터양에 좌우되지 않는 쿼리 엔진\nHadoop 상의 분산 애플리케이션은 애초에 높은 확장성과 내결함성을 목표로 설계되었습니다. 수천 대나 되는 하드웨어를 이용하는 것이 전제입니다. Hive도 연장 선상에 있습니다 → 대규모 배치 처리를 꾸준히 실시합니다. 텍스트 데이터 가공, 열 지향 스토리지를 만드는 등의 무거운 처리에 적합합니다. 대화성이라기 보다는 안전성에 장점이 있습니다. Hive는 배치 처리 툴이라기 보다는 데이터 집계를 위한 쿼리 엔진입니다. 이 아키텍처에서는 하둡과 함께 사용된 것으로 추정됩니다.\nHive 동작 방식 Hive는 SQL에 익숙하고 프로그래머가 아닌 사람도 HiveQL이라는 SQL과 유사한 인터페이스를 사용하여 페타바이트 규모의 데이터를 처리할 수 있도록 만들어졌습니다. 기존의 관계형 데이터베이스는 중소 규모의 데이터 세트에 대한 대화형 쿼리를 위해 설계되었으므로 대규모 데이터 세트를 제대로 처리하지 못합니다. Hive는 대신 배치 처리를 사용하므로 대규모 분산 데이터베이스에서 신속하게 작동합니다. Hive는 HiveQL 쿼리를 MapReduce 또는 Tez 작업으로 변환하여 Apache Hadoop의 분산 작업 예약 프레임워크인 YARN(Yet Another Resource Negotiator)에서 실행됩니다. Hadoop 분산 파일 시스템(HDFS) 또는 Amazon S3와 같은 분산 스토리지 솔루션에 저장된 데이터를 쿼리합니다. 데이터베이스 및 테이블 메타데이터를 메타스토어에 저장합니다. 메타스토어는 데이터를 쉽게 추상화하고 검색할 수 있는 데이터베이스 또는 파일 기반 스토어입니다. 심화+고민해 본 부분) Spark \u0026amp; Hadoop을 사용하지 않은 이유? Hadoop+Spark 조합이 보편적입니다. 그런데 이를 사용하지 않고 Hadoop+Hive를 사용한 이유는 무엇일까요?\n→ Hive는 데이터 처리를 위한 대규모 배치 처리 구조를 지원하는데, 이를 위해 사용했을 것으로 추측됩니다.\n→ Spark는 일반적으로 데이터를 실시간으로 처리합니다.\nHive\nHive는 데이터베이스가 아닌 데이터 처리를 위한 배치 처리 구조입니다. 읽어 들이는 데이터의 양을 의식하면서 쿼리를 작성해야 원하는 성능이 나올 수 있습니다. Hive는 대용량 데이터 처리에 유용하고 분산 환경을 지원합니다. 메타정보를 보관하는 메타 스토어를 가지고 있어, 메타데이터 관리에 용이합니다. → 메타데이터를 통한 데이터 분석 가능 심화 내용 + 생각해 본 내용 1. 어떻게 수신되는 데이터를 즉시 처리할 수 있도록 하였는가? AWS는 배치 처리 모델을 기반으로 하던 ADP를 AWS Lambda에서 실행되는 이벤트 기반 모델로 전환하는데 도움을 주었습니다. 그 후 Autodesk는 예약된 시간에 데이터를 처리하면서 분석을 지연시키는 것이 아니라 수신되는 데이터를 즉시 처리할 수 있게 되었습니다. ETL 집계를 자동화 해주고, 거의 실시간으로 처리됩니다. 2. 어떻게 수천 건의 동시 요청을 수 밀리초 내에 처리할 수 있는가? Apache Hive를 이용한 빠른 데이터 처리가 있었습니다.\nDynamoDB는 읽기 속도가 RDBMS보다 빠른 분산형 및 관리형 NoSQL 데이터베이스로서, 대규모의 동시 요청을 효과적으로 처리하기 위해 설계되었기 때문에 이를 사용한 게 유용하였다고 생각됩니다.\nAmazon DynamoDB 기능 | NoSQL 키-값 데이터베이스 | Amazon Web Services\n3. Apache Hive: Hive를 어떤 용도로 사용했는가? Apache Hive는 Apache Hadoop을 기반으로 빌드되었기 때문에 페타바이트 규모의 데이터를 신속하게 처리할 수 있었습니다.\n또한, SQL과 유사한 인터페이스로 Apache Tez 또는 MapReduce를 사용하여 대규모 데이터 세트를 쿼리할 수 있습니다.\n맵리듀스 프로그래밍 모델은 Map과 Reduce라는 크게 2가지 단계로 데이터를 처리합니다. 맵은 입력 파일을 한 줄씩 읽어 데이터를 변형(Transformation)하며 리듀스는 맵의 결과 데이터를 집계(Aggregation) 합니다.\n하둡 프로그래밍 - MapReduce\n대규모 분산 처리를 위한 용도로 사용했을 것이라 추측됩니다.\nArchive\n→ 실시간성 데이터에 대한 니즈가 증가하면서 일반적으로 하둡만으로 처리하기 어려워졌고, Hadoop + Spark 조합으로 많이 사용한다.\nSpark\nSpark는 분산 시스템을 사용한 프로그래밍 환경으로 대량의 메모리를 활용하여 고속화를 실현하는 것입니다. 인메모리 상에서 동작하기 때문에 반복적인 처리가 필요한 작업에서 속도가 하둡보다 1000배 이상 빠릅니다. Spark는 Hadoop이 아니라 MapReduce를 대체합니다. Spark 상의 데이터 처리는 자바 등의 스크립트 언어를 사용할 수 있습니다. ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-7-case-study-autodesk/","summary":"\u003ch1 id=\"autodesk의-빅데이터-처리\"\u003eAutodesk의 빅데이터 처리\u003c/h1\u003e\n\u003cp\u003e\u003ca href=\"https://aws.amazon.com/ko/solutions/case-studies/autodesk-big-data-processing/?did=cr_card\u0026amp;trk=cr_card\"\u003eAutodesk 사례 연구 - 빅 데이터 처리\u003c/a\u003e\u003c/p\u003e\n\u003ch1 id=\"빅데이터를-처리하는-방법-람다-아키텍처\"\u003e빅데이터를 처리하는 방법, 람다 아키텍처\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e스트림 처리의 결과를 배치 처리로 치환하다.\u003c/strong\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAutoDesk는 실시간에 가까운 데이터 처리를 통해 비용을 최대 90% 절감하고 비즈니스 사용자를 위한 분석 기능을 개선했습니다.\u003c/strong\u003e\u003c/p\u003e","title":"Case Study: Autodesk"},{"content":" 2023.01.20 / 18:00 - 19:30\njitsi (온라인)\n드라마앤컴퍼니의 인프라 아키텍처 당면 과제 초기에 드라마앤컴퍼니는 국내의 타 클라우드 서비스를 이용하였으나, 잦은 서버 및 네트워크 점검 등의 외부 요인으로 리멤버 서비스가 중단되는 문제가 있었습니다. 뿐만 아니라 서버 사양 변경 불가, 불편한 웹 콘솔, API가 제공되지 않는 점 등의 불편함이 컸기 때문에 서버 이전을 고려하게 되었습니다. 드라마앤컴퍼니의 임세준 CTO는 “클라우드를 사용하지 않으면 서비스가 급성장했을 때 기술적으로 인프라가 이를 절대로 뒷받침할 수 없습니다. 서버를 구매할 경우에는 발주에서 입고까지 몇 주가 걸리고, 호스팅 서비스를 이용한다 해도 직접 소프트웨어 설치 및 하드웨어 관리에 드는 리소스가 급증합니다. 스타트업 특성 상 적은 인력과 합리적인 비용이 중요했고 다양한 매니지드 서비스를 제공하는 클라우드 외에는 다른 대안이 없었습니다.” 라고 말했습니다.\n데이터베이스 드라마앤컴퍼니 소개 드라마앤컴퍼니는 명함 관리 애플리케이션 ‘리멤버’를 개발 리멤버는 받은 명함을 스마트폰으로 촬영하면 수기로 명함 정보를 입력해주는 서비스 💡 About Cloud\nAWS 클라우드 도입 이유 잦은 서버 및 네트워크 점검 등으로 리멤버 서비스가 중단되는 이슈 발생 서버 사양 변경 불가, 불편한 웹 콘솔, API 제공 X 데이터베이스 초기 : MySQL용 Amazon RDS 사용 현재 : Amazon RDS for Aurora (Amazon Aurora)로 이전 AWS Aurora AWS Aurora\nMySQL 및 PostgreSQL과 호환되는 완전 관리형 데이터베이스 엔진 MySQL 및 PostgreSQL 데이터베이스에서 사용하는 코드, 도구 및 애플리케이션 모두 Aurora에서 사용 가능 Amazon Aurora는 표준 MySQL 데이터베이스보다 최대 5배 빠르고 표준 PostgreSQL 데이터베이스보다 3배 빠릅니다. 또한 1/10의 비용으로 상용 데이터베이스의 보안, 가용성 및 안정성을 제공합니다. 하드웨어 프로비저닝, 데이터베이스 설정, 패치 및 백업과 같은 시간 소모적인 관리 작업을 자동화하는 RDS에서 Amazon Aurora의 모든것을 관리합니다.\nAuroraDB Cluster Aurora DB 클러스터 = 기본 인스턴스 + 복제본 인스턴스\n기본 인스턴스 복제본 인스턴스 지원 작업 읽기 및 쓰기 작업 읽기만 가능 보유 개수 1개 최대 15개 🔽 Client 요청부터 AuroraDB까지의 흐름\nClient는 Router53에서 정의한 도메인으로 API 요청 Route53은 들어오는 트래픽을 ELB와 연결 ELB는 들어온 트래픽을 여러 EC2 인스턴스로 분산 EC2에 올린 AP 서버는 필요한 데이터를 **AuroraDB**에서 읽거나 쓰는 등 DB 작업 수행 드라마앤컴퍼니의 AuroraDB 활용\n자동 장애 조치 자동 스토리지 용량 확장 → DB 관리 비용을 획기적으로 줄임\nAWS Aurora 사용법 여러가지 사용 방법을 지원하지만 주요한 세 가지 방법은 다음과 같다.\nAuroraDB 단독 사용 → 드라마앤컴퍼니 채택 방식 💡 Aurora DB를 단독으로 사용하는 경우, 데이터베이스 인스턴스를 프로비저닝하고 데이터를 저장한다. 이는 전통적인 방식으로 데이터베이스를 관리하고 확장할 때 사용한다.\nAuroraDB Serverless 사용 💡 Aurora Serverless는 사용자의 애플리케이션 요구에 따라 자동으로 크기가 조절되는 서버리스 데이터베이스 서비스이다. 서버리스 모델은 사용량에 따라 자동으로 확장 및 축소되므로 유동적이며 비용 효율적이다. Aurora Serverless는 예측할 수 없거나 가변적인 워크로드에 적합하다.\nAuroraDB와 RDS 연결 💡 AuroraDB는 RDS에 속하며, MySQL 및 PostgreSQL과 호환된다. 따라서 AuroraDB를 사용하면서 다른 RDS 데이터베이스와 연결하여 데이터를 공유하고 활용할 수 있다. 이는 다양한 데이터베이스 솔루션을 하나의 애플리케이션에서 혼용해야 할 때 유용하다.\nAWS RDS vs AWS Aurora 데이터베이스 엔진 호환성 Aurora: MySQL 및 PostgreSQL만 호환 RDS: MySQL, PostgreSQL, Oracle, MariaDB 등 다양한 데이터베이스 엔진 지원 성능 및 확장성 Aurora: 분산 스토리지 아키턱처 사용 + 자동 확장과 읽기 전용 replica를 활용하여 성능 향상 RDS: 일반적으로 Aurora 보다 성능 및 확장성에 제한이 있음 가격 Aurora: RDS보다 비쌈 → 성능과 기능 차이를 고려할 때 비용 효율적 RDS: 다양한 엔진과 인스턴스 유형을 지원하므로 옵션에 따라 가격 변경 다중 가용 영역 Aurora: 멀티 AZ 지원 X → Aurora Global Database를 통해 여러 지역에서 동시에 CRUD 가능 RDS: 멀티 AZ 지원 O으로 가용성을 높일 수 있음 이런 상황에선 RDS, 저런 상황에선 Aurora!\n💡 RDS\n다양한 데이터베이스 엔진을 지원하고 비교적 사용이 간편하기 때문에 단순한 요구사항이나 비용을 최소화하고 싶을 때 선택\n💡 Aurora\n대규모 트래픽이 예상되거나, 자동화된 기능(자동 백업, 자동 확장, 자동 복원) 등 비용 대비 성능이 중요한 경우에 선택\n캐시 ElastiCache ElasticCache란?\n인 메모리 데이터베이스 캐싱 시스템을 제공\n→ 애플리케이션이 데이터를 검색 할 수있는 성능, 속도 및 중복성을 향상\nMemcached와 Redis 비교 Memcached와 Redis 엔진은 둘 다 인 메모리 키 - 값 저장소\n데이터 지속성 (Persistence)\nMemcached는 모든 데이터가 유실되지만, Redis는 데이터를 Disk에도 저장하기 때문에 메모리에서 유실된 데이터를 복구할 수 있음\nAOF(Append Only File) Log 와 RDB(Redis Database Backup File) Snapshot 이라는 기능\n→ in-memory 에 저장된 데이터를 Disk에 백업해주는 기능\nData eviction\nLRU (Least Recently Used) 방법 redis는 추가적인 방법을 통해서도 데이터 관리 가능 No Eviction (데이터를 삭제하지 않고 메모리가 차면 key 추가를 허용하지 않음) - 메모리가 부족하면 에러 반환 TTL (Time to Live : TTL 표기가 된 데이터를 먼저 지우고 나머지는 아직 유효한 것으로 간주함) Redis 5가지 데이터 형식\nString, Set, Sorted Set, Hash, List ElatiCache for Redis 클러스터, 복제(Replication) 노드, 샤드 설정들을 해주어야 함\n클러스터: 여러 컴퓨터가 연결돼 하나의 시스템처럼 동작하는 것, 데이터베이스에서는 안정성과 가용성을 높이기 위해 여러 노드가 협력하는 구조.\n샤드: 대용량 데이터를 분산 저장하기 위한 방법, 큰 테이블이나 데이터를 작은 조각으로 나눠 각각을 다른 노드에 저장함으로써 전체 시스템의 성능을 향상시키고 부하를 분산함.\n싱글 클러스터 노드(No Replication) 클러스터 모드 없이 복제(Replication)만 지원(클러스터 모드 X) 클러스터 모드와 Replication 모두 지원(클러스터 모드 O) Primary Node와 Replica Node로 구성하는게 일반적!\n→ shard로 여러 벌 준비하여 data partinioning을 수행하는 것 == 클러스터 모드(clsuter mode)\nUntitled%205.png\n노드(Primary Node) 문제 발생 → Replica Nodes 사용 → 복제 지연으로 인해 일부 데이터 손실 최소화 가능 특정 가용 영역에 문제 발생 → Multi-AZ 구성으로 타 가용 영역의 Replica Node 사용 제일 좋은 것은 3번!!!\n트래픽도 여러 샤드로 분산시킬 수 있고 데이터를 Master 노드 + 복제 해놓기 때문에 Master에 장애가 발생해도 복제본을 사용할 수 있음.\n각각의 특징 정리 스케일 업(수직확장) 과 스케일 아웃(수평확장)\n• 각 단일 서버(하드웨어)의 성능을 증가시켜서 더 많은 요청을 처리하는 방법\n즉, 스케일 업은 단일 하드웨어의 성능을 높이기 위하여 CPU, 메모리, 하드디스크를 업그레이드 하거나 추가하는 것\n동일한 사양의 새로운 서버(하드웨어)를 추가하는 방법 데이터의 증가나 요청량이 증가하더라도 동일하거나 비슷한 사양의 새로운 하드웨어를 추가하면 대응이 가능\n즉, 위의 클러스터 모드에서는 Scale Out을 한다는 큰 장점이 있다\n모니터링 리멤버는 서비스 모니터링을 어떻게 하고 있을까? - DRAMA\u0026amp;COMPANY\n리멤버 서비스 내에서는 “라이브” 회원 간에 명함을 교환하거나 개인 정보에 변동 사항이 있을 때 푸쉬 알림 기능을 지원하기 위해 Amazon Simple Notification Service(Amazon SNS)도 사용 중입니다. (…중략….) 드라마앤컴퍼니는 Amazon CloudWatch를 통해 서버의 상태를 실시간으로 확인하여 문제가 발생할 경우 각 담당자들에게 메일을 발송하는 Amazon Simple Email Service(Amazon SES)도 이용하고 있습니다.\nAWS 서비스 소개 👀 Cloud Watch? Amazon CloudWatch는 Amazon Web Services(AWS) 리소스 및 AWS에서 실행되는 애플리케이션을 실시간으로 모니터링 할 수 있다. CloudWatch를 사용하여 리소스 및 애플리케이션에 대해 측정할 수 있는 변수인 지표를 수집하고 추적할 수 있다.\n💬 SNS? **Amazon Simple Notification Service(Amazon SNS)**는 구독 중인 엔드포인트 또는 클라이언트에 메시지를 전달 또는 전송하는 것을 조정하고 관리한다. CloudWatch와 함께 Amazon SNS를 사용하여 경보 임계값에 도달한 경우 메시지를 전송한다.\n🗨️ SES? Amazon Simple Email Service(SES)는 사용자의 이메일 주소와 도메인을 사용해 이메일을 보내고 받기 위한 경제적이고 손쉬운 방법을 제공하는 이메일 플랫폼\nCloudWatch를 사용하여 Amazon SNS 주제 모니터링 하는 법 리멤버가 모니터링하는 것들 Application Performance\nAP는 일반적으로 다음과 같은 일반적인 지표를 추정한다. CPU 사용량, 평균 응답 시간, 오류율, 트랜잭션 추적, 인스턴스, 요청, 가동시간 중 리멤버는 현재 New Relic으로 throughtput, 평균 응답 시간, 오류 발생율, 슬로우 트랜잭션 및 cpu/메모리 사용율을 주로 확인한다.\nInfrastructure Metrics\n서버 프로세스가 아닌 다른 요인으로 서버에 문제가 발생했을 경우 New Relic으로 확인하고 있다. 특히 트래픽 별 IO양, 디스크 사용율은 물론 Infrastructure의 관점의 여러 가지 metrics를 통해 Load average와 CPU 사용율을 중심으로 문제가 되는 지점을 파악할 수 있다. 이후 동일한 문제가 발생하지 않기 위해 자동화.\nSLI/SLO\n아직 제대로 된 거 없고 이제 막 시작하는 단계!\n특정 서비스의 health 를 나타내는 지표\n리멤버 도메인 특성상 관리해야 하는 지표가 있을 경우 상황에 따라 개발자들이 인지 후 조치를 위해 CloudWatch에 custom metric 전송 후 alarm을 만들어 관찰한다.\n리벰버가 모니터링 도구로써 AWS CloudWatch와 New Relic를 사용하는 법, 그리고 차이점은? (1) 문제 발생 시 Slack으로 메시지를 수신\nNewRelic의 경우 terraform 모듈을 이용해 각 애플리케이션 마다 Slack으로 알람 메시지 전송하는 Alert 관리 Alert 발생 시 과정을 스레드로 기록 AWS CloudWatch + SNS slack으로 알람 메시지가 전송 (2) 사용자 문의 및 모니터링 중 이상징후 발견\n특정 사용자의 개인적인 문제 대응 Logs에서 해당 유저가 요청한 API목록 확인 서비스 지표에 이상징후에 대한 대응. 두 모니터링 서비스 모니터링 리멤버가 CloudWatch를 사용할 때 주의했던 점 애플리케이션 로그를 CloudWatch 에 쌓지 말자 AWS의 CloudWatch Log는 여러 서비스와 연동이 편리하지만 비용이 다른 로그 저장소들에 비해서 매우 높다.\nCloudWatch Log는 수집 항목이 $0.76 per GB에 비해 NewRelic에서 한 달 기간 동안 스토어 비용 포함해 $0.3 per GB이다.\nNewRelic처럼 대체제가 있기 때문에 어플리케이션 로그를 포함한 여러 형태, 여러 소스의 로그들을 CloudWatch에 쌓이지 않게 할 수 있다면 로그를 남기지 않는 것이 비용 절감에 매우 도움이 된다.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-8-case-study-%EB%93%9C%EB%9D%BC%EB%A7%88%EC%95%A4%EC%BB%B4%ED%8D%BC%EB%8B%88/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.01.20 / 18:00 - 19:30\u003cbr\u003e\njitsi (온라인)\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch1 id=\"드라마앤컴퍼니의-인프라-아키텍처\"\u003e드라마앤컴퍼니의 인프라 아키텍처\u003c/h1\u003e\n\u003ch2 id=\"당면-과제\"\u003e당면 과제\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e초기에 드라마앤컴퍼니는 국내의 타 클라우드 서비스를 이용하였으나, 잦은 서버 및 네트워크 점검 등의 외부 요인으로 리멤버 서비스가 중단되는 문제가 있었습니다. 뿐만 아니라 서버 사양 변경 불가, 불편한 웹 콘솔, API가 제공되지 않는 점 등의 불편함이 컸기 때문에 서버 이전을 고려하게 되었습니다. 드라마앤컴퍼니의 임세준 CTO는 “클라우드를 사용하지 않으면 서비스가 급성장했을 때 기술적으로 인프라가 이를 절대로 뒷받침할 수 없습니다. 서버를 구매할 경우에는 발주에서 입고까지 몇 주가 걸리고, 호스팅 서비스를 이용한다 해도 직접 소프트웨어 설치 및 하드웨어 관리에 드는 리소스가 급증합니다. 스타트업 특성 상 적은 인력과 합리적인 비용이 중요했고 다양한 매니지드 서비스를 제공하는 클라우드 외에는 다른 대안이 없었습니다.” 라고 말했습니다.\u003c/p\u003e","title":"Case Study: 드라마앤컴퍼니"},{"content":" 2023.01.06 / 15:00 - 18:00\n역삼 센터필드 East 18층 AWS Office\nML Camp AWS Cloud Club in South Korea (경희대학교, 서울과학기술대학교, 숭실대학교, 인하대학교, 가톨릭대학교, 이화여자대학교, 숙명여자대학교, 남서울대학교, 동덕여자대학교, 광운대학교, 충남대학교) 에서 ML Camp를 진행했어요.\n💡 Details 참여자 분들을 위한 다양한 선물도 준비했어요. 🎁\nAWS 서비스인 Amazon Rekognition과 Amazon Textract를 활용하여 이미지를 라벨링하고 이미지의 텍스트를 추출하는 웹 앱을 만들어보는 캠프를 진행했어요. 기계 학습 서비스를 웹 앱에 적용해보는 챌린지를 진행하며, ML 서비스에 대해 학습할 수 있는 시간이었어요.\n📆 Contents Introduction \u0026amp; SetUp - 워크샵 구성 및 ML 개념 소개, 기본 셋팅 설정 Lab 1 - 기존 웹 앱에 Amazon Rekognition 서비스 적용 Lab 2 - 기존 웹 앱에 Amazon Textract 서비스 적용 네트워킹 시간 Picture 캡틴들 모두 멋진 발표와 함께 서포트를 담당했어요. 동덕여대 Cloud Club 멤버들도 함께 참여했어요! 네트워킹 시간을 통해 모두 친해질 수 있었어요. ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-5-ml-camp/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.01.06 / 15:00 - 18:00\u003cbr\u003e\n역삼 센터필드 East 18층 AWS Office\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"ml-camp\"\u003eML Camp\u003c/h2\u003e\n\u003cp\u003eAWS Cloud Club in South Korea (경희대학교, 서울과학기술대학교, 숭실대학교, 인하대학교, 가톨릭대학교, 이화여자대학교, 숙명여자대학교, 남서울대학교, 동덕여자대학교, 광운대학교, 충남대학교) 에서 ML Camp를 진행했어요.\u003c/p\u003e","title":"ML Camp"},{"content":" 2023.12.30 / 18:00 - 19:30\n동덕여대 인문관 A301호\nInfrastructure Camp 동덕여대 AWS Cloud Club에서 Infrastructure 캠프를 개최했어요. 💡 Details IAM / S3 서비스를 사용한 VPC(+네트워크) 환경 구축 실습(핸즈온) 과정을 진행했어요.\nAWS의 인프라를 구성하기 위한 AWS IAM AWS VPC AWS S3 서비스를 소개했어요.\nVPC와 더불어 네트워크에 대해 더 잘 이해하기 위해 Subnet 과 CIDR 등 추가적인 네트워크 지식을 전달했어요.\nPicture 캠프는 교내에서 온, 오프라인으로 진행되었어요.\n","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-4-infra-camp/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.12.30 / 18:00 - 19:30\u003cbr\u003e\n동덕여대 인문관 A301호\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"infrastructure-camp\"\u003eInfrastructure Camp\u003c/h2\u003e\n\u003cp\u003e동덕여대 AWS Cloud Club에서 Infrastructure 캠프를 개최했어요.\n\u003cimg alt=\"3_camp_1\" loading=\"lazy\" src=\"/1st/3_camp_1.jpeg\" title=\"3_camp_1\"\u003e\u003c/p\u003e\n\u003ch3 id=\"-details\"\u003e💡 Details\u003c/h3\u003e\n\u003cp\u003eIAM / S3 서비스를 사용한 VPC(+네트워크) 환경 구축 실습(핸즈온) 과정을 진행했어요.\u003c/p\u003e","title":"Infrastructure Camp"},{"content":" 2023.12.23 / 18:00 - 20:00 진행\nSession 과제 발표 (생략) 모든 팀원이 저번주 과제로 SAA dump 5문제를 풀었어요.\n💡 Core Session 저번 키워드 투표에서 가장 많은 관심을 받은 배포 자동화 키워드를 바탕으로, Automating Architecture 에 대해 캡틴 유빈이 발표를 진행했어요.\nAWS의 자동화와 관련된 AWS CloudFormation AWS Quick Starts AWS Systems Manager AWS OpsWorks AWS Elastic Beanstalk 서비스를 소개했어요.\nInfrastructure as code (IaC) 의 개념을 장점을 통해 이해했어요. Configuration Drift 를 이해하고 기능 중 하나인 Drift Detection의 작동 방식을 알아보는 등 AWS CloudFormation의 다양한 개념을 이해했어요. AWS Systems Manager가 하는 다양한 역할들을 이해하고, formation과의 비교를 통해 효과적으로 학습했어요. 그 외 AWS의 서비스 역시, 예시 시나리오를 통해 사용법과 특징을 학습했어요. 각 사례에 따른 자동화 솔루션을 고르는 최적을 방법을 찾으며, 추후 진행될 세션에서 활용하기 위한 다양한 자동화 예제를 AWS 공식 블로그를 통해 함께 살펴보았어요. 실제로 Cloud Formation에서 networking/application layer을 deploy, stack을 업데이트 및 삭제하면서 간단하게 서비스를 사용해보았어요. Picture 오늘의 세션은 온라인으로 진행되었어요. ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-3-2nd-session/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.12.23 / 18:00 - 20:00 진행\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"session\"\u003eSession\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e과제 발표 (생략)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e모든 팀원이 저번주 과제로 SAA dump 5문제를 풀었어요.\u003c/p\u003e\n\u003ch3 id=\"-core-session\"\u003e💡 Core Session\u003c/h3\u003e\n\u003cp\u003e저번 키워드 투표에서 가장 많은 관심을 받은 \u003ccode\u003e배포 자동화\u003c/code\u003e 키워드를 바탕으로, Automating Architecture 에 대해 캡틴 유빈이 발표를 진행했어요.\u003c/p\u003e","title":"2nd Session: Core Session"},{"content":" 2023.12.02 / 18:00 - 20:00 진행\nSession 과제 발표 (생략) 모든 팀원이 저번주 과제로 SAA dump 5문제를 풀었고, 유빈이 발표를 진행했습니다!\n💡 AWS 또는 클라우드 영상 발표하기 1 2 3 4 - 모든 멤버는 유튜브나 다른 곳에 있는 AWS, 또는 클라우드 관련 발표 영상**(혹은 다른 매체 가능)** 을 하나 선정해요. - 핸즈온일 경우, 실제 실습을 따라해보고 정리해서 발표해요. - 이론일 경우, 해당 내용을 공부하고 느낀 점을 정리해서 발표해요. - 영상을 보면서 궁금했던 점이나 더 알아보고 싶은 점을 자유롭게 얘기해요. 김유빈 : 서버리스와 K8s\n정채원 : Github Actions + AWS CodeDeploy + S3로 CI/CD 구축\n류혜수 : CloudWatch와 x-ray를 통해 관찰 가능성 확보하기\n박세은 : AWS Lambda Container를 활용한 서버리스 아키텍처 배포 및 성능 향상\n신이현 : [보안/인증] Amazon Cognito를 이용한 백엔드 API 권한 관리\n이어진 : AWS Serverless 기반 EDA (1) - 디커플링\n홍성주 : AWS 컴퓨팅 서비스 EC2 알아보기\n주현정 : AWS에서 DevOps, CICD 시작하기\n유희진 : 클라우드 컴퓨팅 한 방 정리 [안될과학-긴급과학 X AWS]\nPicture 오늘 오프라인 참여가 어려웠던 두 멤버는 온라인으로 함께하였습니다! ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-2-1st-session/","summary":"\u003cblockquote\u003e\n\u003cp\u003e2023.12.02 / 18:00 - 20:00 진행\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"session\"\u003eSession\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e과제 발표 (생략)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e모든 팀원이 저번주 과제로 SAA dump 5문제를 풀었고, \u003ccode\u003e유빈\u003c/code\u003e이 발표를 진행했습니다!\u003c/p\u003e\n\u003ch3 id=\"-aws-또는-클라우드-영상-발표하기\"\u003e💡 AWS 또는 클라우드 영상 발표하기\u003c/h3\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv class=\"chroma\"\u003e\n\u003ctable class=\"lntable\"\u003e\u003ctr\u003e\u003ctd class=\"lntd\"\u003e\n\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode\u003e\u003cspan class=\"lnt\"\u003e1\n\u003c/span\u003e\u003cspan class=\"lnt\"\u003e2\n\u003c/span\u003e\u003cspan class=\"lnt\"\u003e3\n\u003c/span\u003e\u003cspan class=\"lnt\"\u003e4\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd class=\"lntd\"\u003e\n\u003cpre tabindex=\"0\" class=\"chroma\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e- 모든 멤버는 유튜브나 다른 곳에 있는 AWS, 또는 클라우드 관련 발표 영상**(혹은 다른 매체 가능)** 을 하나 선정해요.\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    - 핸즈온일 경우, 실제 실습을 따라해보고 정리해서 발표해요.\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e    - 이론일 경우, 해당 내용을 공부하고 느낀 점을 정리해서 발표해요.\n\u003c/span\u003e\u003c/span\u003e\u003cspan class=\"line\"\u003e\u003cspan class=\"cl\"\u003e- 영상을 보면서 궁금했던 점이나 더 알아보고 싶은 점을 자유롭게 얘기해요.\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e\u003ccode\u003e김유빈\u003c/code\u003e : 서버리스와 K8s\u003c/p\u003e","title":"1st Session: warming up PT"},{"content":"Session DDWU 1st Crew의 OT를 진행하였습니다. ","permalink":"https://ddwu-aws-cloud-club.github.io/post/1st/post-1-ot/","summary":"\u003ch2 id=\"session\"\u003eSession\u003c/h2\u003e\n\u003cp\u003eDDWU 1st Crew의 OT를 진행하였습니다.\n\u003cimg alt=\"OT_1\" loading=\"lazy\" src=\"/1st/OT_1.jpeg\" title=\"OT_1\"\u003e\u003c/p\u003e","title":"OT"},{"content":"DDWU AWS Cloud Club ","permalink":"https://ddwu-aws-cloud-club.github.io/about/","summary":"\u003ch1 id=\"ddwu-aws-cloud-club\"\u003eDDWU AWS Cloud Club\u003c/h1\u003e","title":"About Me"},{"content":"☁️ DDWU AWS Cloud Club AWS Cloud Clubs는 AWS에서 공식 주관하는 글로벌 클라우드 동아리로, 전 세계 각국의 대학과 지역 단위로 운영되고 있어요. 학생들은 클라우드 컴퓨팅을 중심으로 함께 배우고 성장하는 경험을 쌓을 수 있어요.\n📢 DDWU ACC RECRUITING https://docs.google.com/forms/d/e/1FAIpQLSfxMGS6jnZSmoCg_QiJhs67KrBycsVHFI8AR_gssNGioGB9-g/viewform?usp=header\n동덕여자대학교 AWS Cloud Club 3기 멤버를 모집합니다! 클라우드 기술을 통해 함께 성장하고 싶은 여러분의 많은 관심과 지원을 기다립니다.\n일정 지원서 접수: 8월 19일(화) ~ 8월 25일(월) 23:59:59 최종 결과 안내: 8월 27일(수) 21시 예정 모집 대상 AWS 또는 클라우드 기술에 관심이 있는 동덕여자대학교 재학생 및 휴학생 세션, 프로젝트로 다양한 AWS 서비스들을 직접 사용하며 클라우드 기술을 익히고 싶은 분 교내외 학생 및 현직 엔지니어와 교류하며 기술 및 커리어에 대한 시야를 넓히고 싶은 분 활동 혜택 AWS 공식 동아리로서 크레딧, 자격증 바우처, 활동 인증서 등 다양한 지원 제공 AWS Korea에서 열리는 현직자와의 커리어 세션 및 AWS 실습 세션 참여 기회 전공, 배경 지식에 관계 없이 클라우드 컴퓨팅 및 AWS 기술과 친해질 수 있는 기회 ☁️ ACC Session 1. 캡틴 \u0026amp; 코어 멤버 세션 클라우드 기초와 AWS 핵심 서비스, 천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기와 같은 주제로 심도 깊은 지식을 습득하고, SAA 덤프 문제를 함께 풀어보며 실전 감각도 길러요.\n2. 스터디 (SAA 자격증) SAA(Solutions Architect Associate) 자격증 취득을 목표로 스터디를 진행해요. 운영진이 할당하는 서비스 주제를 각자 발표하고, 함께 덤프 문제를 풀어요.\n주제: 1주차: IAM, VPC, EC2, RDS, S3 2주차: API Gateway, Lambda, SQS, SNS 3주차: ElastiCache, CloudWatch, CloudFront, ECS + ECR, Load Balancer 3. Case Study 특정 기업의 서비스 아키텍처를 분석하고 발표해요. 단순히 하나의 서비스에 집중하기보다, 여러 서비스들이 어떻게 상호 연결되어 전체 시스템을 구성하는지 파악하는 것을 목표로 해요.\n4. AWS 연사 세션 \u0026amp; 멤버 세션 AWS 연사 세션: 현직 실무자와의 연합 세션을 통해 커리어와 기술 트렌드에 대한 깊이 있는 이야기를 들을 수 있어요. 멤버 세션: 멤버들이 직접 10분 이상 발표를 진행해요. 난이도와 주제는 자유롭게 정할 수 있어요. 세션 영상은 유튜브에 업로드되어 개인 포트폴리오로도 활용 가능해요. 5. 파이널 프로젝트 멤버들이 자유롭게 주제를 선정해 AWS 서비스를 활용한 프로젝트를 진행해요. 주제 선정에 어려움이 있을 경우 가상 면접 사례로 배우는 대규모 시스템 설계 기초와 같은 책을 참고해 아이디어를 얻을 수 있도록 가이드할 예정이에요.\n✅ FAQ (자주 묻는 질문) 비전공자, 1학년도 지원 가능한가요? 네, 지원 가능합니다. 다만 기초적인 개발 지식이 없다면 세션 진행이 다소 어려울 수 있어요. 선발 과정은 어떻게 되나요? 면접 없이 간소화되어 서류만으로 평가합니다. 코어 멤버와 일반 멤버의 차이는 무엇인가요? 코어 멤버는 각 세션마다 팀 리더로 활동해요. 세션 진행을 직접 이끌어나갈 수 있어요. 활동 기간은 어떻게 되나요? 9월 3일(OT)부터 내년 1월 초까지 활동합니다. 동아리 수료 조건은 어떻게 되나요? 총 12번의 세션 중 3번 이하로 결석 시 수료로 인정됩니다. 고정 세션은 언제, 어떻게 진행되나요? 매주 수요일에 학교 내 강의실에서 오프라인으로 진행됩니다. 유의사항 OT(9/3)는 반드시 참석해야 하는 필수 참석 행사입니다. 정기 세션 및 필수 참석 행사에 참여가 어려울 경우, 선발에 불이익이 있을 수 있습니다. CONTECT seplease@naver.com 🌫️ 이전 기수 활동 🌫️ ACC 1st ACC 2nd Post ","permalink":"https://ddwu-aws-cloud-club.github.io/_index-copy/","summary":"\u003ch1 id=\"-ddwu-aws-cloud-club\"\u003e☁️ DDWU AWS Cloud Club\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAWS Cloud Clubs는 AWS에서 공식 주관하는 글로벌 클라우드 동아리로, 전 세계 각국의 대학과 지역 단위로 운영되고 있어요. 학생들은 클라우드 컴퓨팅을 중심으로 함께 배우고 성장하는 경험을 쌓을 수 있어요.\u003c/p\u003e","title":"DDWU ACC"}]