나는 데브옵스 부트캠프에서 팀 프로젝트를 맡았다. 프로젝트는 특정 주제 에 대해 AWS 를 활용하여 최적의 클라우드 인프라 를 구축하는 것이 주 목표였고 이에 맞춰 프로젝트를 완료하였다. 이번 글에서는 맡았던 프로젝트를 설명하고 프로젝트 진행 과정에서 어려웠던 점과
나는 ECS 를 운용하고 있었고 ECR 에 있는 도커 이미지 를 task 이미지 로서 사용하고 있었다.기존에는 ECS 내 fargate 를 퍼블릭 서브넷 에 놓고 있었지만 보안이 신경쓰여 프라이빗 서브넷 으로 옮겼다. 그랬더니 아래와 같이 에러가 발생했다.에러 원인은
그라파나 를 사용해 ECS 클러스터 내 서비스 의 Metric 을 보는 방법을 공유하려 한다.Metric 을 통해 ECS의 CPU 사용률과 Memory 사용률을 볼 수 있다.선제조건: ECS 를 실행되고 있다는 전제하에 진행한다.Docker 를 통해 그라파나를 설치하고
private subnet 에 존재하는 자원(EC2 등) 이 VPC 외부에 존재하는 리소스에 통신을 요청하려고 한다고 가정해보자. 가능할까? 기본적으로 불가능하다. 왜냐하면 private subnet 은 VPC 외부로의 접근이 차단되어 있기 때문이다. 그럼에도 접근할
Auto Scaling Group 을 통해서 EC2 를 자동으로 Scale up/down 시켜줌을 통해서 확장성을 얻을 수 있다.단순히 Auto Scaling Group 를 생성함으로써는 자동으로 확장되지 않고 Auto Scaling Group 에 정책을 추가해주어야
Serverless IaC Framework를 활용해 아래와 같은 마이크로 서비스 아키틱쳐를 구현해보았다.SNS 를 활용해 추후 메일, 문자등을 받을 수 있는 확장성을 열어두었고 SQS 를 둠으로써 람다 함수간 직접 호출 시에 발생할 수 있는 메세지 유실을 방지하고자
위와 같이 (서버1)에서 다른 (서버2)에 API 요청을 했을 때, (서버2)가 모의의 사고(ex: 서버 다운)로 요청을 수행하지 못할 수 있다. 그렇다면 해당 API 요청은 소실되어 복구할 수 없을 것이다.(서버2)가 메세지를 받지 못함으로써 발생할 수 있는 API
테라폼으로 인프라를 구성하면 인프라를 손쉽게 지우고 다시 생성할 수 있다. AWS 또한 테라폼을 통해 인프라를 구성할 수 있어 실습하면서 배워보았고 실습한 결과를 공유하려 한다.테라폼을 통해서 아래와 같은 인프라 구성우선 AWS 콘솔을 통해 직접 리소스를 만들어본 다음
서버에 트래픽이 많아지면 서버의 확장을 고려하게 된다. AWS ECS 를 사용하면 원하는 개수만큼의 서버를 손쉽게 프로비저닝 및 배포할 수 있으며 트래픽 등에 따라 자동으로 스케일 아웃(수평 확장)이 진행되게 할 수 있어 급격한 트래픽에 대비할 수 있다. 또한 ECS
https://velog.io/@mimi0905/Presigned-URL을-이용하여-S3로-파일-업로드
이전에는 람다 함수를 SAM 을 통해 빌드하고 AWS Cloud 상에 배포한 뒤에 람다 함수를 테스트했었다. 그러나 배포를 하기 전에 미리 로컬 환경에서 테스트가 가능한 방법이 있어서 공유한다.
이미지참고자료:1\. Amazon S3 이벤트 알림2\. Amazon EventBridge 사용 설정3\. 연습: 알림용 버킷 구성(SNS 주제 또는 SQS 대기열)4\. Amazon SQS 시작하기5\. json strip6\. json viewer7\. How to
총 두개의 버킷을 생성한다.하나의 버킷은 원본 이미지를 저장할 버킷이고 다른 하나는 원본 이미지가 썸네일 이미지로 변경되어 넣어질 버킷이다.두개의 S3 버킷을 생성한다 (원본 이미지 저장용 하나, 썸네일로 변환되어 넣어질 놈 하나)필자는 버킷명을 원본이미지용: bk-p
이전 실습 의 연장선입니다. POST 전용으로만 작동하게 만들기 람다의 게이트웨이에 접속한다. 기존 ANY 를 제거한다. (ANY: 모든 메서드 (CRUD)를 의미함) POST 를 추가한다. 을 지