Do it, it will be better

공통점 AWS에서 제공하는 DNS(Domain Name System) 관리 서비스 둘 다 도메인 이름을 등록하고, IP 주소를 할당하고, 도메인 이름에 대한 라우팅 정보를 관리 차이점 (+설명) Route53 DNS(Domain Name System) 서비스. DNS는 인터넷에서 사용되는 IP(Internet Protocol) 주소와 같은 숫자 형식의 주소를 사람이 이해할 수 있는 문자열 형태로 변환하여 도메인 이름을 인식할 수 있게 해주는 시스템. Route 53은 DNS 서비스를 제공하면서 도메인 이름 관리와 라우팅을 가능하게 함 → 사용자는 자신의 도메인을 쉽게 등록하고 관리할 수 있으며, 트래픽을 다른 AWS 리소스로 라우팅하여 도메인 이름을 사용하는 웹사이트나 애플리케이션의 가용성을 높임 Rou..

배경 internal 통신을 위한 alb가 생길 때, 얘가 누구랑 통신을 하는 것인지, private subnet안에 숨겨져 있는데 당연히 public으로 두지 않아야 한다는 것은 알지만 정확히 어떤 목적으로 숨겨진 것인지, 어떻게 통신을 하는지, 아예 내부에서만 트래픽이 돌게 할 수 는 없을까 등에 대해 고민 비교 공통점 VPC 외부와 통신하지 않고 VPC 내부에서만 vpc 외부에 있는 서비스들에 접근해야 할 때, Private Subnet 안에 있는 EC2 인스턴스, ECS 컨테이너 인스턴스, Lambda 함수 등에서는 VPC Endpoint 또는 NAT Gateway를 사용하여 액세스할 수 있다. 차이점 VPC endpoint AWS 서비스와 VPC 간의 트래픽을 안전하게 전달하기 위한 가상 인터페..

배경 보안 그룹에 대해 막연하게만 알고 있어서 조금 더 깊이 알아보기로 함. 여기서 추가로 어려운게 생기면 후속 리서치 예정 요약 Virtual Private Cloud(VPC)의 보안을 강화하고 모니터링하는 데 사용할 수 있는 여러 기능 중 하나. 트래픽에 대해 관리하고 추적하는 것들. 그 중 보안그룹과 acl은 특정 인/아웃 바운드 트래픽에 대해 제어하는 기능. 보안그룹 ACL(Network Access Control List) flow log traffic monitoring 비교 공통점 다음 항목에 대해서는 제어하지 않는다. Amazon Domain Name Services(DNS) Amazon Dynamic Host Configuration Protocol(DHCP) Amazon EC2 인스턴스..

요약 공통점 수직, 수평 확장이 가능하며 데이터 샤딩과 읽기 레플리카 지원 멀티 az 지원, 페일 오버 기능 제공 읽기 속도는 마이크로초 단위 차이점 엘라스틱 캐시의 가격이 메모리디비의 약 66% → 40%정도 더 싸다 엘라스틱 캐시는 페일오버시 데이터 손실이 우려되나, 메모리디비는 그부분을 보장한다 엘라스틱 캐시는 쓰기가 마이크로초 단위, 메모리 디비는 밀리세컨드초 단위 → 메모리 디비가 느림 고민 신규 서비스에서 사용할 redis를 생성하고자함. 레디스를 캐시로 사용하기 위한 aws 서비스에는 elasticache 와 memorydb가 있음. 둘 중 어느 쪽으로 선택해야 하는가? 데이터베이스의 목적은 아니고, 오로지 캐싱만을 목적으로함. 비교 ElastiCache 설명 aws에서 제공하는 완전 관리형..

aws 에서 제공하는 ec2 인스턴스 사용시 해당 인스턴스에 접속하는 방법은 크게 세 가지. 1. 콘솔 상에서 인스턴스로 연결 2. 세션 매니저를 사용 3. 키페어를 등록하여 로컬의 터미널에서 ssh -i 명령을 통해 접속 각 방법은 특징들이 있다. 1번은 일단 매우 쉽다. 단, 접속하고자 하는 인스턴스가 퍼블릭 ip를 가지고 있어야 하기 때문에 실제 서버의 역할을 하기엔 보안상 이슈가 있다. 3번은 내 로컬에서 원격의 인스턴스를 접속하여 서로 파일을 전송하거나 연결을 하기 위한 방법. 로컬의 운영체제 별로 조금 다른 접근이 필요. 가장 큰 특징은 키페어를 발급받아 퍼블릭 키와 프라이빗 키의 매칭을 통해 접속을 하는 방식. 해당 방식에 대해서는 추후 단독 컨텐츠로 설명 예정. 2번 세션 매니저를 이용하게..

원하던 것 : 키페어 없이 aws 콘솔에서 바로 인스턴스에 접속 오류 상황 : 단순하게 퍼블릭 ip를 생성해서 콘솔 상에서 접속하는 것이기 때문에 키 페어나 다른 에러가 짐작도 안됨. 해결 : 놀랍게도 로컬 환경에서의 타임 존이 맞지 않아서 발생. 이게 무슨 상관인가 싶기도 하고, 왜? 싶긴한데, 노트북을 처음 받고 제대로 타임 존 설정을 해 두지 않고 인스턴스 생성 후 접속을 시도했던 부분을 수정하니 제대로 접속이 되었다. 에러 수집가답게도 다양한 경험을 했다. 언제나 기기를 처음 받으면 기본 셋팅이 중요함을 잊지말자.

[AWS][ElastiCache] #1. 엘라스틱 캐시의 클러스터 고르기 상황 마지막 프로젝트를 진행하면서 제작한 서비스의 메인 ec2 상의 api 서버는 기본적으로 mysql 기반의 rds 로 엔드포인트가 향해있었다. 어플리케이션을 통해 들어온 사용자의 예약 정보를 저장하기 위한 데이터베이스가 필요했기 때문. 솔직히 여기까지만 해도 토이프로젝트로는 충분하다고 생각했다. 실제 우리가 많은 양의 데이터를 처리하거나, 처리 속도에 대한 제한까지 신경쓸 것 같진 않았다. 사실 작은 규모의 데이터 입출력을 다룰 땐 캐싱이 필요하지 않다. 오히려 비용적 측면에서 캐싱을 함으로써 발생하는 추가 비용이 rds를 직접 다녀오는 비용보다 클 수 있다. 단, 요구사항 명세에서 클라이언트로 부터 다음과 같은 요구를 받게되었..

어차피 인스턴스 내에서 작업을 하는 중이니까 특히 s3 버킷의 경우 정적파일이라서 매번 새로 빌드하면 새로 올려야한다. 파일 질라같은 프로그램으로 매번 인스턴스에서 로컬로 받아서 올리고 s3 파일 삭제하고 하기 귀찮으니까 한줄로 덮어쓰기까지 가능한 aws-cli를 활용하쟈! aws configure 프로필 > 보안자격증명 여기서 액세스키 id 랑 secret key를 받을 수 있는데 꼭 저장하자 id는 노출되도 괜찮지만 secret key는 노출되지않도록 조심 aws-cli 사용을 위한 설정 $ aws confiugre 여기서 위에서 알아낸 id랑 key 넣어준다. 리전과 aws.log 포맷은 좋아하는거 넣어주면 된다. 이걸 넣어줘야 aws-cli 활용할때 쉽게 가능함:) 인스턴스 내에서 s3로 폴더 이..

EC2 인스턴스는 가장 처음 생성하면 당연히 깡통 있는 것 git 하나 뿐이다. 그럼 작업을 하기위한 설정들이 조금 필요하다. 순서대로 복붙! node & npm 설치 과정 $ sudo apt-get install build-essential libssl-dev $ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash $ source ~/.bashrc $ nvm install 16.15.0 #이건 내가 글을 쓰는 시점에서 그냥 최신 각자 알아서 curl 설치 과정 $ sudo apt install curl $ curl -sL https://deb.nodesource.com/setup_14.x | sudo -..

약 2-3일간 초보자 단계에서 볼 수 있는 에러란 에러는 다 만난 것 같다. 1. 트리거 중복문제 s3 버켓에 트리거를 걸고 싶었는데 중복으로 걸리는 문제라고한다. s3 > 속성 > 이벤트 알림 지우고 다시걸면 된다. 2. 람다 함수의 트리거에 sqs를 붙일 때, timeout error가 발생했다. 함수 제한 시간은 많은데 sqs의 제한 시간은 그보다 짧아서 sqs의 에러발생 타이밍을 함수가 잡지 못해서 발생한다. 함수가 먼저 에러가 발생했음을 알아야 sqs로 그 알람이 가야하기때문에 함수의 타임아웃 시간을 더 줄여줬다. 람다 함수 일반구성 > 시간 설정