https://aws.amazon.com/ko/blogs/korea/amazon-ebs-update-new-elastic-volumes-change-everything/

 

Amazon EBS 업데이트 – 언제나 자유롭게 볼륨 유형 및 크기 변경 가능 | Amazon Web Services

AWS 고객은 서비스를 시작한 후, 사용자 트래픽 및 데이터 사이즈가 증가함에 따라 기존 볼륨을 수정하여 용량을 추가하거나 I/O 성능 특성을 변경해야 할 경우가 생깁니다. 이를 변경하기 위해, 2

aws.amazon.com

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

 

볼륨 크기 조정 후 Linux 파일 시스템 확장 - Amazon Elastic Compute Cloud

볼륨 크기 조정 후 Linux 파일 시스템 확장 EBS 볼륨 크기를 늘리고 난 후에는 파일 시스템 관련 명령을 사용하여 파일 시스템의 크기를 늘려야 합니다. 볼륨이 optimizing 상태가 되자마자 파일 시스�

docs.aws.amazon.com

2017년 발표된 신규 EBS가 출시되면서 EC2에서 EBS를 사용할 경우 저장 공간에 대한 탄력적인 운영이 가능해졌습니다. 

 

예를들어 용량이 부족할 때는 일정 비율 이상으로 자동 증가하는 방법들을 선택할 수 있게 되었죠.

 

최근 수동으로 용량을 증가할 일이 있어서 관련 내용을 정리해봤습니다. 

 

만약 해당 시스템이 현재 서비스 중인 시스템이라도 중단 없이 처리가 가능합니다. 하지만, EBS에 손실될 경우 문제가 될만한 중요한 정보가 있다면 스냅샷을 꼭 만든 후 진행하시기 바랍니다. 

 

스냅샷을 생성해두면 문제가 발생 시 기존 EBS를 해제하고 스냅샷으로 새로운 볼륨을 생성 후 기존 인스턴스에 연결할 수 있습니다. 

 

우선 AWS Console에서 EC2 >> EBS >> 볼륨을 선택합니다. 

그리고 수정이 필요한 볼륨을 선택한 후 "볼륨 수정"을 선택합니다.

그리고 필요한 볼륨으로 크기를 조정합니다.

이제 시스템에 접속해서 lsblk 명령으로 인스턴스에 연결된 블록 디아비스 정보를 확인합니다. 

 

현재 8G를 사용중이며 총 용량이 16G인 것을 확인할 수 있습니다. 

사용하지 않고 있는 8G를 xvda1에 추가해 보겠습니다. 

growpart 명령으로 파티션을 확장합니다. 디바이스 이름과 파티션 번호 사이에는 띄어쓰기가 있으니 유의하세요.

df 로 파일 시스템을 확인해보면 아직 이전 상태인 것을 확인 할 수 있습니다. 

xfs_growfs 명령으로 파일 시스템을 확장합니다. 

이후 df로 다시 확인하면 xvda1 의 용량이 8G 에서 16G로 확정된 것을 확인 할 수 있습니다.

 

확장된 volume은 다시 축소할 수 없으니 꼭 필요한 경우 진행하시고, 확정 전에 꼭 스냅샷을 만들어 두시는걸 추천드립니다.

 

복잡하진 않지만 찾아보지 않으면 알 수 없는 내용이라 간단히 정리해 보았습니다. 

 

조금이라도 도움이 되셨길 바랍니다. :)

>> EPEL(Extra Packages for Enterprise Linux) 저장소 활성화하기

https://aws.amazon.com/ko/premiumsupport/knowledge-center/ec2-enable-epel/

>> 원격접속을 위한 키 발급 및 설정

EC2는 기본적으로 생성 시 발급한 공개키를 사용하여 원격접속 할 수 있도록 설정되어 있습니다. EC2에 키 페어를 설정하는 방법은 아래와 같습니다.

 

EC2 생성 전에 키 페어로 가서 ...

"키 페어 생성" 버튼을 눌러 ppk를 생성합니다. 이때 비번 설정은 없으니 참고하세요. 

 

EC2 기본 설정을 완료 후 시작을 누르면 키 페어 설정 화면이 나옵니다. 여기서 새로 생성할 수도 있으며 생성된 키 페어를 설정할 수 있습니다. 

 

키 페어가 변경된 경우에 대해서는 이 링크를 참고하세요. 

 

이제 putty에서 Auth에 다운받은 ppk 파일을 설정합니다. 

그리고 ssh 연결 설정에서 host name에 public dns 값을 입력, 사용자에 ec2-user를 입력 후 연결할 수 있습니다. 

 

파일 이동을 쉽게 하기 위해 WinSCP를 사용하는 경우 아래 이미지를 참고해서 ppk 파일을 설정하면 됩니다. 

 

보안 그룹에서 접속할 instance의  inbound 설정에 ssh 연결을 위해 22 번 포트를 가능한 제한되고 안전한 PC에서만 접속할 수 있도록 접속 가능한 IP를 제한해야 합니다. 

 

예를들어 자신의 회사에서 사용하는 public ip가 1.1.1.0 ~ 1.1.1.255까지 사용하며 자신의 ip가 1.1.1.11이라고 가정해 봅시다. 

 

인바운드 규칙에서 소스에 값을 적용할 때는 CIDR 표기법으로 기록해야 합니다. 

 

만약 회사원 일부가 접속을 할 경우 1.1.1.0/24 로... 자신만 접속한다면 1.1.1.11/32로 설정하면 됩니다. 

 

혹시 원격접속을 "브라우저 기반 ssh 연결"하려면 추가 설정이 필요합니다. 

 

"브라우저 기반 ssh 연결"은 "웹 브라우저 -> EC2 Instance Connect -> EC2 Instance"의 과정을 거쳐 연결됩니다. 이때 EC2 Instance Connect은 각 지역별로 별도의 IP 대역이 할당되어 있습니다.  예를들면 서울 리전(ap-northeast-2)의 경우 13.209.1.56/29를 ssh의 포트에 같이 포함하여 적용되어 있어야 합니다. 이에 대한 상세한 내용은 https://ip-ranges.amazonaws.com/ip-ranges.json 파일을 참고하시면 됩니다.

 

>> VPC를 생성하면..

라우팅 테이블 , 네트워크 ACL, 보안 그룹이 자동으로 같이 생성됩니다.

>> 실행중인 EC2로 이미지 생성 시

실행중인 인스턴스로 이미지 생성을 하게 되면 인스턴스가 일시적으로 중단된 듯 한 상황이 발생할 수 있습니다. 주의하세요.

>> EC2에서 다른 EC2로 원격 접속하기

해당 EC2에 설정된 키 페어를 다운받고, ppk일 경우 pem 파일로 변경(https://aws.amazon.com/ko/premiumsupport/knowledge-center/convert-pem-file-into-ppk/)합니다.

$ sudo puttygen ppkkey.ppk -O private-openssh -o pemkey.pem

puttygen이 설치되지 않은 경우 putty(혹은 putty-tools) 패키지를 설치하면 됩니다. EC2의 경우 epel을 활성화되지 않을 경우 패키지를 찾을 수 없습니다. 

sudo ssh -i your-key.pem ec2-user@ec2-ip

>> node 설치 방법

https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/setting-up-node-on-ec2-instance.html

 

# download
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

# nvm 활성화
. ~/.nvm/nvm.sh

# nodejs 설치
nvm install node

#pm2 설치
npm install pm2 

 

 

Redis와 같은 VPC 안에 EC2를 생성했다고 가정합니다. 다른 VPC에 있을 경우 VPC Peering 설정이 필요하며 이 내용은 곧 다시 업로드할 예정입니다. 

 

일단 EC2에 redis-cli 설치를 위해 gcc를 설치합니다. redis를 별도 설치해되 되지만 ec2 에서는 redis-cli만 사용할 예정이니 redis 자체 설치를 하는 방법은 사용하지 않겠습니다.

 

 

sudo yum install -y gcc 

 

redis-stable 버전을 다운받아 빌드를 해야 하니 임시 폴더 혹은 프로그램 빌드를 위한 별도 폴더를 만들어 작업하실것을 추천드립니다.

 

wget http://download.redis.io/redis-stable.tar.gz && tar xvzf redis-stable.tar.gz && cd redis-stable && make

 

redis 자체를 쓰지는 않고 redis-cli만 사용합니다. redis-cli를 사용하기 쉽게 /usr/bin에 복사합니다. 

sudo cp src/redis-cli /usr/bin 

 

redis-cli가 잘 실행된다면 redis에 원격접속을 해봅니다.

 

redis-cli -h redis-endpoint-address

redis의 주소는 기본 엔드포인트나 리더 엔드 포인트나 상관없이 잘 연결됩니다. 

 

만약 접속이 안된다면 보안 그룹에 설정된 인바운드 설정에 port가 잘 열려 있는지 확인해야 합니다. 

 

VPC 의 보안 -> 보안 그룹에서 redis에 설정된 보안 그룹을 찾아 inbound 규칙에서 TCP 6379 포트 혹은 별도 설정한 redis 포트가 규칙에 적용되어 있는지 확인해 보세요.

 

아래와 같은 설정으로 규칙이 적용되어 있어야 합니다. 

 

 

이상입니다.

 

다음은 VPC Peering 설정 방법과 EC2와 Redis가 서로 다른 VPC, 다른 리전에 있을 경우 연동하는 방법을 정리해 보겠습니다.

S3에 생성한 정적 웹사이트는 http로 만들어진 endpoint로 접속이 가능합니다. 

 

사용자들의 보다 안전한 접속을 보장하기 위해 https를 적용하는 방법을 알아보겠습니다.

 

여담인데 S3에 있는 각각의 파일은 https로 접근이 됩니다.

 

 

 

 

그런데 정적 웹사이트는 https를 기본으로 지원되는지 않습니다. https에는 공급자에 대한 정보가 있어야 하지만 s3의 정적 웹 사이트는 사용자 도메인없이 제공되는 웹 사이트이기 때문에 제공되는 컨텐츠 자체의 책임 권한 문제 때문이지 않을까 생각됩니다. (혹시 정확히 아시는 분은 댓글 부탁드립니다.)

 

 

기존 사용하던 도메인의 서브 도메인이므로 기존 등록기관을 이용할 수 있을까 했는데 IP가 없고 endpoint만이 존재하기 때문에 불가합니다. 이를 위해 ACM(AWS Certificate Manager)을 이용해 인증서를 등록하고 CloudFront에 S3 파일들을 CDN에 올리고 SSL을 적용한 후 Custom Domain 을 설정하고 Route53에서 CloudFront에 배포한 웹호스팅 도메인과 Custom Domain을 연결하여 적용해야 합니다. 

 

이 글에서는 이미 발급된 도메인에 추가로 서브 도메인을 만들어 S3 정적 웹사이트를 https로 서비스하는 과정을 다룹니다. 도메인 발급과 S3 만으로 서비스를 하고 싶은 경우 이전 글을 참고하세요.

 

apex 도메인이 ACM에 등록된 경우가 아니라면 서브 도메인만 생성하여 사용할 수 있습니다. 다음은 AWS 메뉴얼의 내용입니다. 

"DNS 표준에 따라 IP 주소로 매핑되며 실뢰할 수 있는 (A)레코드가 apex 도메인(example.com)에 사용되어야 합니다. Route 53을 사용하는 경우에만 apex 도메인이 CloudFront 배포를 가리키도록 할 수 있습니다. 다른 DNS 공급자를 사용하는 경우 하위 도메인(www.example.com)을 사용해야 합니다." (출처 : 참고 링크 )

 

그럼 순서대로 하나씩 살펴보겠습니다. 

 

서브 도메인 SSL 인증서 생성하기

우선 ACM으로 들어갑니다. (서비스에서 ACM 혹은 Certificate Manager로 검색 가능합니다.)

ACM으로 들어가서 인증서 프로비저닝을 시작합니다. 

 

그리고 공인 인증서 요청을 선택합니다. ACM에서 생성하는 SSL 공인 인증서는 무료입니다.

ACM에서 인증서를 요청전에 꼭 리전을 us-east-1으로 설정해야 CloudFront의 Custom SSL Certificate에서 설정이 가능합니다. 관련해서는 이 링크를 참고하시기 바랍니다.

 

인증서 요청은 총 5단계로 진행됩니다. 

  • 1단계: 도메인 이름 추가
  • 2단계: 검증 방법 선택
  • 3단계: 태그 추가
  • 4단계: 검토 및 요청
  • 5단계: 검증

우선 도메인을 추가합니다. 와일드 카드로 작성해도 되지만, 저는 다른 서브 도메인들과 구분을 위해 test.exmaple.com 과 같은 서브 도메인을 전체 기입했습니다. 다음을 누르면 검증 방법을 선택할 수 있습니다.

이메일 검증은 시간이 너무 오래 걸리기 때문에(메일이 안옵니다.... 꽤... ), DNS 검증을 선택하면 CNAME에 등록해야 하는 이름을 출력합니다. 그걸 복사해서 도메인 관리 사이트에서 CNAME에 등록해주면 됩니다.

DNS 검증 과정은 약 5 ~ 10분 정도 혹은 그 미만으로 소요됩니다.

 

검토 요청 후 인증서의 상태는 "발급 보류"로 되어 있다가, 메인 링크로 검토 완료가 되면 "발급 완료"로 변경됩니다. 

 

이렇게 인증서 발급 절차는 완료되었습니다. 

 

이제 기존에 만들어진 S3를 CloudFront로 연결하기 전에 S3를 정적 웹사이트로 만드는 절차를 간단히 살펴보겠습니다. 

 

S3로 정적 웹사이트 만들기

예제-03에서 다루었지만, 간단히 다시 정리합니다. 

 

버킷 이름, 리전을 선택하고 생성합니다. 저는 이미 만들어진 버킷을 사용할 것이지만 생성 및 설정에서 주의할 사항이 있어 추가 정리하려 합니다.

 

웹 사이트로 사용할 버킷의 이름을 만들 때는 주의할 점이 있습니다. ( 참고 링크 )

  • 버킷을 가상 호스팅 하기 위해서는 버킷 이름과 CNAME이 동일해야 합니다. 예를 들면, 버킷 이름과 도메인 이름이 test.example.com이라면 CNAME 레코드는 test.example.com.s3.amazonaws.com 이어야 합니다. ( 위 링크의 "Amazon S3 URL을 CNAME으로 사용자 지정" 부분을 참고하세요.) 이는 http만 지원하는 기능입니다.
  • https로 서비스 할 경우 버킷의 이름에 period( . )을 사용하면 안됩니다. 그리고 가상 호스팅은 http만 지원하기 때문에 CloudFront와 Route53을 사용하여 구축해야 합니다. ( 위 링크의 영문 버전 문서에만 이 내용이 명시되어 있으니 참고하세요. - AWS 공식 문서인데 중요한 내용인데도 불구하고 한글 버전 문서가 정확하지 않은건 좀 아쉽네요. )
Virtual hosted URLs are supported for non-SSL (HTTP) requests only. When using virtual hosted–style buckets with SSL, the SSL wild-card certificate only matches buckets that do not contain periods. To work around this, use HTTP or write your own certificate verification logic.

이제 버킷을 하나 만들고 "Welcome!!"이라고 출력되는 index.html 파일을 만들어서 업로드 합니다. 

 

그리고 버킷의 속성에서 정적 웹 사이트 호스팅을 활성화 합니다.

그 후 엔드포인트로 접근하면 "403 Forbidden"에러를 볼 수 있습니다. 이 설정은 웹 사이트 호스팅을 위한 엔드포인트를 오픈하는 역할만 합니다. 하지만 버킷의 객체들에는 접근 권한이 없기 때문에 이런 에러가 발생합니다.

 

파일의 엔드포인트로 접근을 시도해도 아직은 "AccessDenied" 에러만 보게 됩니다. 

 

일반 유저가 접근할 수 있도록 하려면 두 가지 방법이 있습니다. 버킷의 "권한" -> "버킷 정책"에 모든 대상에게 Get 에 대한 권한을 허용하는 것과 특정 파일만 선택해서 퍼블릭으로 설정하는 방법입니다. 

 

index.html 파일을 선택하여 퍼블릭으로 설정해 보세요.

 

이 설정 후에는 파일의 엔드포인트 혹은 호스팅 엔드포인트 모두 접근이 가능합니다. 

 

혹은 버킷 정책에 아래와 같이 입력하면 버킷 전체가 퍼블릭으로 설정되어 버킷 내 어떤 파일이든 접근이 가능합니다. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your_bucket_name/*"
        }
    ]
}

 

Hosting 할 S3 버킷을 준비했으니 이제 도메인의 네임서버를 AWS 로 변경하여 본격적으로 AWS에 서비스를 연동해 보겠습니다. 

 

ACM에서 SSL Certificate 발급하기

보다 안전한 서비스를 위해 AWS Certification Manager에서 SSL 인증서를 발급 신청합니다. 발급 신청 전 서비스 지역을 us-east-1 (미국 동부 (버지니아 북부)로 세팅하세요. CloudFront에서 인증서는 us-east-1에 등록된 인증서만 세팅이 가능합니다. 

ACM console에서 "공인 인증서 요청" -> "도메인 이름 추가" 에서 소유한 도메인과 서브 도메인 이름들을 추가합니다. 서브 도메인 사용을 위해 입력시 *.example.com 과 같이 입력해 두세요. 검증방법은 DNS로 설정 후 "확인 및 요청"을 선택하면 검증을 위한 값이 화면에 출력됩니다. 이 값을 기존 도메인 등록기관에서 CNAME으로 등록한 후 몇 분이 지나면 검증이 완료됩니다. 

CloudFront에 S3 버킷 배포하고 SSL Certificate 설정하기

우선 CloudFront에서 Origin Domain Name에서 배포할 버킷을 선택하세요.

만약 버킷의 이름이 버킷의 이름이 도메인명과 동일하지 않다면 S3 버킷의 endpoint를 복사해서 넣으시기 바랍니다. 

그리고 CNAMEs에는 사용할 도메인들을 입력합니다.

 

Default Root Object는 index.html 혹은 필요한 파일을 지정하세요.

 

그리고 Custom SSL Certificate를 선택 후 인증서를 선택합니다. (ACM us-east-1 리전의 인증서 리스트만 선택할 수 있습니다.)

 

이제 Create Distribution 버튼을 눌러 배포를 선택합니다. 배포 완료까지는 약 20분 가량 소요된다고 했는데, 저는 50분 이 소요되었습니다.

Route 53에 도메인 연동하기

기존 도메인을 Route 53으로 이동해야 하는 이유는 서브 도메인을 관리하기 용이하기 때문입니다. 사실 도메인을 여기서 생성하면 더 저렴하긴한데, 이미 다른 곳에서 등록하는 바람에 -_-a

 

저처럼 기존 도메인이 AWS가 아닌 다른 도메인 등록기관에서 등록한 경우 (저는 whois.co.kr에서 등록했습니다.) 네임 서버를 AWS로 돌려두면 이후 세팅들이 편리합니다. 물론 예제-03에서 언급한 것처럼 포워딩 세팅만으로도 가능하지만 https를 위한 인증서 서비스나 서브 도메인 관리를 위해서는 Route 53을 사용하는게 더 좋습니다. 

 

이제 Route 53으로 가서 "호스팅 영역 생성"을 시도합니다. 

소유하고 있는 도메인 이름을 입력하고 생성을 하면 NS와 SOA 유형의 두 값이 등록된 것을 확인할 수 있습니다. 

 

그럼 기존 등록기관에서 네임서버를 위 NS 영역의 네 주소로 변경합니다. 변경된 네임서버가 적용되기까지는 꽤 오랜 시간이 소요될 수 있습니다. 로컬의 경우 수십분에서 1시간 정도, 전 세계에 모두 적용되려면 2~3일의 시간이 소요될 수 있으니, 현재 서비스 중인 도메인의 네임서버 변경은 신중이 결정되어야 합니다.

 

이제 도메인의 IPv4 주소를 입력합니다. IP가 별도로 존재하지 않기 때문에 CloudFront에 등록된 endpoint를 복사하여 등록합니다. "레코드 세트 생성"을 선택 후 "A-IPv4 주소" 유형을 선택, "별칭"을 "예"로 선택 후 CloudFront의 도메인 endpoint를 입력 후 "레코드 세트 저장"을 눌러줍니다. 

 

이제 http와 https로 일정 시간이 지난 후 정상적으로 접속되는 것을 확인할 수 있습니다. 일반적으로 www 서브 도메인은 도메인 주소로 연결이 되므로 CNAME 유형으로 등록합니다. "별칭"은 "아니오"로 선택 후 값에는 CloudFront의 도메인의 endpoint를 입력해주시면 됩니다. 

 

이상입니다. 

 

 

이 글의 일부는 AWS 공식 문서( 링크 )를 참고하였습니다. 단계별 상세 내용은 해당 문서를 참고하시기 바랍니다.

 

1. 도메인 등록하기

- whois.co.kr 등에서 도메인을 먼저 구매하세요.

 

도메인 네임은 알파벳과 숫자, 그리고 -(하이픈) 으로 구성할 수 있습니다. 도메인은 단순한 조합이 아닌 계층적인 구조로 이루어집니다. 

 

helloworld. co. kr(실제 생성 하실 때는 각자 원하는 이름으로 사용해야 합니다.)로 예를 들어보면... 

 

kr은 1단계로 최상위 도메인으로 국가도메인(kr, us 등)을 나타냅니다.

co는 2단계로 해당 도메인을 운영하는 기관의 성격을 나타냅니다.(co: 기업 , or:비영리기관 등)

helloworld 는 3 단계로 도메인 네임을 사용하는 기관이나 개인이 원하는 이름을 등록합니다. 

1단계의 종류에 따라 계층이 다를 수 있으며, 대표적으로 com 을 사용할 경우 1/2단계만으로 구성되기도 합니다.

위 예에서 없는 프로토콜, 예를들어 www, ftp 등은 발급된 도메인을 어떻게 활용할지에 따라 사용할 수 있습니다. 

 

이 1단계 종류의 인기에 따라 각 도메인 발급 기관은 가격을 다르게 측정하기도 합니다.

참고로 whois의 경우 io의 경우 1년 기준으로 6만원대이고 com의 경우 2만원대입니다. 

 

이후 등록인 정보 / 연장 책임자 정보를 입력 후 결제를 하면 해당 도메인을 소유할 수 있습니다. 

 

 

2. S3에 서비스를 위한 버킷 생성하기

 

S3에 helloworld.co.kr이라는 이름의 루트 도메인 버킷과 www.helloworld.co.kr이라는 이름의 서브 도메인 버킷을 만들어 보겠습니다.

 

루트 도메인 버킷에는 실제 컨텐츠를, 서브 도메인 버킷에서는 루트  도메인으로 리디렉션 되도록 설정해야 합니다. 

 

먼저 루트 도메인 버킷을 생성합니다. AWS S3 Console로 접속해서 helloworld.co.kr라는 이름으로 새로운 버킷을 생성합니다. 생성 시 컨텐츠로 사용될 파일들에 대해서는 퍼블릭 액세스를 허용하기 위해 "모든 퍼블릭 액세스 차단"을 해체하고 생성합니다. 

 

생성이 되었다면 버킷의 "속성" 탭으로 가서 "정적 웹 사이트 호스팅" 을 선택 후 아래와 같이 설정합니다. 해당 탭의 상단에 있는 엔드포인트는 여러분의 컨텐츠로 접근할 수 있는 주소입니다. html 컨텐츠를 업로드 후 이 주소로 접속하여 확인할 수 있습니다. 개인적으로 사용하거나 제한된 용도로 사용할 때는 별도의 도메인 설정없이 이 endpoint만을 사용할 수도 있습니다.

다음으로 "www.helloworld.co.kr"이라는 이름으로 서브 도메인 버킷을 만듭니다. 이 버킷은 루트 도메인 버킷으로 리디렉션하는 용도로 사용합니다. 버킷 생성 후 "정적 웹 사이트 호스팅" 설정에서 "요청 리디렉션"을 선택 후 루트 도메인 버킷 명을 입력하고 프로토콜에는 http를 입력하면 됩니다. 

공식 문서에는 "웹 사이트 트래픽용 로깅 구성"이 있지만, 추후 "구글 애널리틱스"를 예정이기 때문에 이 부분은 넘어가겠습니다. 필요하신 분들은 공식 문서를 참고하세요.

 

이제 "index.html"파일을 생성 후 아래 코드를 삽입합니다. 

<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>My Website Home Page</title>
</head>
<body>
  <h1>Welcome to my website</h1>
  <p>Now hosted on Amazon S3!</p>
</body>
</html>

이 파일을 "루드 도메인 버킷"에 업로드합니다. 

파일 추가 후 "다음" 버튼을 누르고 속성 중 "퍼블릭 권한 관리"에서 "이 객체에 퍼블릭 읽기 엑세스 권한을 부여함"을 선택 후 "업로드"버튼을 선택하여 컨텐츠 업로드를 완료합니다. 

파일 업로드를 할때마다 이렇게 지정할 수도 있지만 버킷의 정책을 변경하는 방법도 있습니다. 버킷의 "권한" -> "버킷 정책"을 눌러 아래 정책을 복사해서 넣고 저장하시면 helloworld.co.kr 에 업데이트되는 모든 컨텐츠를 누구나 읽을 수 있게 됩니다. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::helloworld.co.kr/*"
            ]
        }
    ]
}

 

이제 "루트 도메인 버킷"의 엔드포인트와 "서브 도메인 버킷"의 엔드포인트로 접근을 테스트 해보시기 바랍니다. 두 엔드포인트 모두 "루트 도메인 버킷"의 index.html의 내용을 출력한다면 모두 정상적으로 성정된 것입니다.

 

이제 등록한 도메인을 "루트 도메인 버킷"으로 연결되도록 설정해 보겠습니다.

 

3. 도메인 연결하기

 

다시 whois로 돌아가 "내 도메인 자산 관리" 화면에서 "루트 도메인 버킷"으로 연결할 도메인을 선택 후 화면 하단의 "포워딩 서비스"를 선택합니다. 

"루트 도메인 버킷"의 엔드 포인트를 복사해 포워딩 URL에 복사해서 넣은 후 "주소창에 도메인명 유지"를 선택해야 합니다. 

"주소창에 포워딩 URL 표기"를 선택하면 도메인 주소를 입력 후 aws s3의 엔드포인트 주소를 주소창에 출력하게 됩니다.

 

금일 내용 중 "서브 도메인 버킷"을 같이 만들었는데 이어지는 다음 글에서 사용될 예정입니다. 

 

그럼 다음 글에서 다시 뵈요!!

 

 

Oh my goodless 입니다. 정말로.. 

 

감동이네요. 감사합니다. :)

 

해당 글 링크는 여기로 .. :)

DynamoDB에 대해서 내용은 이 링크를 꼭 한번 읽어보시길 권유 드립니다.

 

이 예제에서는 1:1 모델링에 적합한, 전달될 유저 ID를 분할키로 사용하고, info라는 키에 name과 phone 정보를 담아보겠습니다. 

 

DynamoDB에서 "test_db"라는 이름으로 테이블을 먼저 생성해 보겠습니다. 그리고 분할키의 이름은 "key"로 지정하겠습니다. 분할키에는 전달될 유저 ID를 지정하겠습니다.

 

정렬키도 별도로 추가하지 않겠습니다. 생성이 완료되었으면 바로 람다 함수를 추가해 보겠습니다. 

함수명을 "save"라는 이름으로 생성합니다. aws-sdk 모듈은 바로 사용 가능해서, 아래 코드를 붙여서 바로 테스트 가능합니다.

var AWS = require("aws-sdk");
AWS.config.update({
    region: 'ap-northeast-2',
    endpoint: "http://dynamodb.ap-northeast-2.amazonaws.com"
})

const dynamo = new AWS.DynamoDB.DocumentClient();

exports.handler = (event, context, callback) => {
    const params = {
        TableName: 'test_db',
        Item : {
            "key" : event.id,
            "info" : event.info
        }
    };

    dynamo.put(params, callback);
};

이 람다 함수가 DynamoDB에 쓰기를 하려면 해당 권한이 필요합니다. FullAccess를 설정하기 보다는 쓰기 권한만 있는 정책을 만듭니다. IAM으로 가서 "역할 만들기"로 이동하여 "정책 생성"을 선택합니다.

서비스는 DynamoDB를 선택, 권한은 DeleteItem, PutItem, UpdateItem 만 설정합니다. 그리고 접근을 허용할 리소스는 생성한 DynamoDB의 arn을 복사해서 삽입합니다.

"rule_lambda_write_item" 이라는 이름으로 정책을 저장하고, 이 정책을 적용한 역할 "role_lambda_write_item"을 생성합니다.

이제 람다 함수로 돌아와서 역할을 설정해 줍니다. 

 

그리고 아래처럼 테스트를 설정 후 실행해 봅니다.

이후 DynamoDB "항목"탭에 가면 아래와 같이 입력된 정보를 확인할 수 있습니다.

 

마지막으로 생성한 람다 함수를 API Gateway와 연결해 보겠습니다. 

 

API Gateway에 대한 상세한 절차는 아래 링크를 참고해 주세요. 여기서는 간략히 기술하겠습니다. 

( 서버리스 서비스 예제 - 01 [ API Gateway - Lambda-ElastiCache(Redis) ] )

 

 

API Gateway로 이동해서 MyStore라는 이름의 API를 생성합니다.

"put-info"라는 이름으로 리소스를 생성하고 메소드는 "POST"를 선택 후 Lambda 함수는 "save"라고 명명한 함수를 선택하자. 이후 API를 prod라는 스테이지 이름으로 명명 후 완료하면 접근 가능한 URL이 부여됩니다.

 

이제 모든 설정이 마무리 되었습니다.  curl로 아래와 같이 테스트를 해보시기 바랍니다.

curl -L -v -d "{\"id\": \"test_id101\", \"info\" : {\"name\":\"console\", \"phone\":\"111) 1234-5678\"}}" -H "Accept: application/json" -H "Content-Type: application/json" path_your_endpoint

정상적으로 완료되었다는 메세지를 확인했다면 DynamoDB에서 결과를 확인할 수 있습니다. 

 

 

이상입니다. 여러분들도 문제없이 잘 진행되셨길 바랍니다. 질문이 있다면 댓글로 달아주세요.

최근 본격적으로 AWS에 서비스를 구축하면서 자잘하게 부딪혔던 작은 문제들을 정리하는 김에 저처럼 처음 접해보시는 분들께 도움이 되길 바라며 공개해 봅니다.

 

앞으로 몇 번에 걸쳐 간단한 샘플을 만들어보면서 실제 서비스 인프라를 구축하기 위해 어떤 과정들이 필요한지 하나씩 정리해 보겠습니다.

 

이번에 제작할 샘플은 REST API를 통해 Redis에 정보를 저장하는 과정을 만들어 보겠습니다. 

 

서비스는 아래와 같이 구성해 보겠습니다.

 

 

작업은 크게 네 단계로 진행합니다. 

 

1. VPC 구성하기

2. Redis 구성하기

3. Lambda 함수 제작

4. API Gateway 구성하기

 

따라하기 식으로 구성했으니 편하게 진행해 보시기 바랍니다. 바로 시작해 보겠습니다. 

 

1. VPC(Virtual Private Cloud) 구성하기

중요한 정보를 저장하는 저장소이므로 VPC를 구성하여 외부의 무분별한 접근을 차단하도록 하겠습니다. (2013년부터 AWS에 구축되는 모든 인프라는 VPC안에 구축되도록 강제되고 있습니다. 필수 과정이니 가능한 상세하게 짚고 넘어가도록 하겠습니다.) 이 과정에서는 VPC를 구성하고 서브넷(VPC 내부에서 서비스 목적에 따라 IP 범위를 나누어 구분하기 위한 설정), 보안 설정을 하게 됩니다. Redis를 외부에서 직접 접근하지 못하게 막아야 하므로 Public IP나 Elastic IP를 사용하지 않고 Private IP로만 설정하겠습니다. (public ip를 할당할 수는 없습니다. ^^a)

 

1-1. VPC 생성하기

마법사로 생성하지 않고 필요한 과정 전부를 직접 만들면서 진행하겠습니다.

 

우선 VPC 탭에서 "VPC 생성" 버튼을 누릅니다. "이름 태크"에는 "test-vpc"로 명명하겠습니다. 

IPv4 CIDR(Classless Inter-Domain Routing) 블록에는 VPC 안에서 사용할 주소 범위를 지정해야 합니다. 세 개의 subnet으로 관리해야 한다는 가정으로 설정하겠습니다. "192.168.0.0/16"으로 입력합니다. IPv6 블록은 없음으로 하겠습니다.

 

VPC와 함께 기본적으로 "라우팅 테이블"(Routing Table-라우터가 이를 사용해 최적의 경로를 결정하고 패킷을 전송합니다.), "네트워크 ACL"(Access Control List-오고 가는 패킷을 분석하여 정해진 규칙에 따라 패킷을 전송/차단합니다.)에 새로 생성한 VPC를 위한 항목이 자동 생성됩니다. 

 

1-2. 서브넷 설정

다음으로 서브넷(Subnet-네트워크 영역을 분리)을 생성해 보겠습니다.

 

DB, Service, Management 영역으로 구분하겠습니다. 그럼 아래와 같은 구조를 가지게 될겁니다. 

 

[db 영역]

CIDR 블럭 : 192.168.10.0/24

가용 ip 대역 : 192.168.10.4 ~ 192.168.10.253 (251개)

 

[Service 영역]

CIDR 블럭 : 192.168.20.0/24

가용 ip 대역 : 192.168.20.4 ~ 192.168.20.253(251개)

 

[Management 영역]

CIDR 블럭 : 192.168.30.0/24

가용 ip 대역 : 192.168.30.4 ~ 192.168.30.253(251개)

 

더보기

AWS는 가용 ip 대역 중 처음 4개 IP주소와 마지막 1개 IP주소를 예약하여 사용합니다.

첫 번째 ip는 subnet id, 마지막 한 개는 broadcast addr, 그리고 두 번째에서 네 번째 ip는 NAT Gateway로 활용됩니다.

(이에 대해서는 https://aws.amazon.com/ko/vpc/faqs/ 에서 찾을 수 있었으며, 5개의 ip는 AWS에의해 예약되었기 때문에, 사용자가 사용할 수 없다고 나와 있으나 각각이 정확히 무엇에 활용되는지에 대한 내용은 찾을 수 없었습니다. 알게 되면 글을 수정해 두겠습니다.)

 

서브넷 영역을 어떻게 사용할지 계획을 세웠으니, 실제로 생성해 보겠습니다.

서브넷 생성화 화면 에서 "이름 태크"에는 영역별로 알맞은 이름을 넣어주세요. "test-vpc-subnet-"을 prefix로 두고 영역별 이름을 db, service, management로 명명해 보겠습니다. 

 

(* "DNS 호스트 이름 편집"에서 "DNS 호스트 이름"을 활성화 해두세요. )

 

IPv4 CIDR 블럭은 위에 정리했던 내용대로 입력하시면 됩니다. 가용 영역을 선택하지 않으면 AWS가 알아서 설정하게 됩니다.

 

이제 서브넷 설정을 모두 마치면 아래와 같은 결과를 보실 수 있습니다. 

 

2. Redis 구성하기

이번에는 Redis를 구성하기 위해서 ElastiCache로 가보겠습니다. 확장성과 안정성을 고려해 Cluster 모드로 설정하겠으나 테스트 용도이니 가장 저렴한 노드로 구성하겠습니다.

 

2-1. Redis 생성하기

 

이름을 "test-redis"로 입력하고 노드 유형을 "cache.t3.small"로 지정하겠습니다. 샤드 당 복제본도 기본설정 2에서 1로 조정했습니다. 

 

그리고 서브넷 그룹에서 "새로 생성"을 선택하고, test-vpc를 위한 그룹을 "test-vpc-group"로 생성합니다. 서브넷은 위에서 "test-vpc-subnet-db" 라고 명명한 서브넷을 선택합니다.

 

서브넷 그룹은 ElastiCache console 메인 화면의 좌측 메뉴에 "서브넷 그룹"이라는 메뉴를 통해 생성/수정/삭제 할 수 있습니다.

 

나머지는 기본 값으로 두고 생성을 완료합니다. 생성 완료까지는 약 5분 ~ 10분 정도 소요됩니다. 

 

2-2. redis-cli로 Redis 접속해보기

현재 생성된 Redis는 VPC안에 생성되어 있으며, 설정된 보안 그룹에서 inbound에 예외처리를 하지 않아 직접 접근할 수 없는 상태입니다. 또한 RDS와 달리 ElastiCache는 AWS 외부에서 접속 할 수 없도록 되어 있습니다. 이를 위해 ElastiCache-Redis가 설정된 VPC 내부에 EC2를 추가하여 접근해 Redis로 접속할 수 있습니다. 

 

그럼 EC2를 생성, 원격접속하여 redis-cli를 설치 후 Redis로 접속을 시도해 보겠습니다.

 

EC2 생성 과정은 간단히 텍스트로 정리하겠습니다. 

 

1) "Amazon Linux 2 AMI (HVM), SSD Volume Type" 선택

2) "t2.micro" 선택 

3) 인스턴스 구성에서 ..

   3-1. 네트웍크에서 test-vpc 선택

   3-2. 서브넷은 test-vpc-subnet-management 선택

4) 스토리지 추가 , 태그 추가 - 기본 설정

5) 보안 그룹 구성 -> 기존 보안 그룹 선택 -> test-vpc 보안 그룹 선택

6) "검토 및 시작" -> "시작하기" 버튼 선택

7) 기존 키 페어 선택 또는 새 키 페어 생성 -> "새 키 페어 생성" -> "키 페어 이름"에 "test-vpc-key-pair" 입력 -> "키 페어 다운로드" 선택 (다운로드된 키 페어는 EC2에 원격접속할 때 사용됩니다.)

8) "인스턴스 시작" 선택

 

이제 EC2로 접속하여 Redis로 연결해보겠습니다. 외부에서의 접속을 위해 public ip와 라우팅 설정을 추가하겠습니다. 

 

우선 생성된 인스턴스 상태를 살펴보겠습니다. 

 

현재는 public dns가 설정되지 않은 걸 확인 할 수 있습니다.

 

이제 VPC로 다시 가서 "인터넷 게이트웨이"를 선택 후 "인터넷 게이트웨이 생성"을 누르고 생성을 시도합니다. name tag에는 "igw-test-vpc-management"라고 명명합니다. 생성 직후에는 상태가 "detached"로 되어 있습니다. 이제 생성한 igw를 선택 후 "작업" -> "VPC에 연결"을 선택합니다. 그리고 "test-vpc"에 연결합니다. 

 

그리고 EC2 화면에서 생성한 인스턴스를 선택 후 하단 "설명"탭의 "서브넷 ID"를 선택하면 VPC 화면으로 전환됩니다. 이후 하단의 "라우팅 테이블"탭을 선택하고 하단의 "서브넷 연결"을 선택, "서브넷 연결 편집"을 선택 후 "test-vpc-subnet-management" 서브넷을 선택 후 "저장"하세요. 그리고 "작업" 버튼에서 "라우팅 편집"을 선택하고 "라우팅 추가" 버튼을 눌러 라우팅 정보를 추가합니다. 

각 대상에는 "0.0.0.0/0"를 입력하고 "igw-test-vpc-management"를 찾아 선택합니다. 그리고 다시 인스턴스 설정 화면을 돌아옵니다.

 

다음으로 외부에서 접속할 수 있는 public ip를 elastic ip 탭에서 할당해 보겠습니다.

 

"탄력적 IP"라는 메뉴를 선택한 후 "탄력적 IP 주소 할당" 버튼을 선택하여 퍼블릭 주소를 하나 할당합니다. 그리고 "Actions" 버튼을 눌러 "탄력적 IP 주소 연결"을 선택한 후 생성한 인스턴스에 연결해 줍니다.

다시 인스턴스 정보 화면으로 넘어가면 생성한 IP가 public ip에 세팅된 것을 확인할 수 있습니다. 혹시 "퍼블릭 DNS"에 할당된 정보가 없다면 VPC에서 "DNS 호스트 이름"을 활성화하여 저장하면 됩니다.

마지막으로 보안 그룹에서 SSH 포트(22)에 대한 인바운드 규칙을 추가하겠습니다.

 

이제 SSH를 사용하여 인스턴스에 연결해 보겠습니다.

 

위에서 다운받은 ppm(Privacy Enhanced Mail)파일을 그대로 사용할 수 있으며, putty 혹은 ssh client에서 사용하려면 ppk(Putty Privite key) 파일로 변경해야 하는데 이에 대해서는 여기서 상세히 다루지는 않겠습니다.

ssh -i your_pem_file ec2-user@ec2_public_dns 형태로 접속을 시도하면 됩니다. 

 

더보기

"WARNING: UNPROTECTED PRIVATE KEY FILE!" 에러가 발생한 적이 있는데 windows에서는 이상하게 다운받은 c:\Users\내계정명\Downloads에서는 문제 없는데, 다른 드라이브로 옮겨서 테스트 했을 때는 이 에러가 발생했었습니다. 에러 내용은 해당 파일에 접근할 수 있는 권한이 너무 많이 열려 있다는 내용인데, 저와 같은 현상이 발생하는건 애매하네요 -_-a

 

이제 redis-cli를 설치해서 접속해 보겠습니다.

 

우선 gcc가 없다면 먼저 설치해 주세요.

sudo yum install -y gcc

그리고 redis를 다운받아 설치합니다. 

sudo wget http://download.redis.io/releases/redis-5.0.6.tar.gz

sudo tar xvzf redis-stable.tar.gz 

cd redis-stable 

sudo make distclean
sudo make MALLOC=libc

sudo cp src/redis-cli /usr/bin/

생성된 Redis를 선택해서 아래 정보를 보시면 기본 엔드포인트가 비어 있는 걸 확인할 수 있습니다.

이는 위에서 클러스터 모드로 설정했기 때문인데, 클러스터 이름을 선택하여 아무 샤드나 선택하여 들어간 후 내부 노드 하나를 선택하면 엔드포인트가 있습니다. (클러스터 모드가 아닌 경우 기본 엔드포인트를 바로 확인할 수 있습니다.)

 

이 엔드포인트를 복사해서 아래와 같이 접속하면 정상적으로 접근 가능합니다. 

redis-cli -h your_redis_node_endpoint

이제 저장소에 대한 설정이 마무리되었습니다. 다음으로는 서비스 영역을 제작할 차례입니다.

3. Lambda 함수 제작

Redis Cluster에 점수를 기록하는 함수를 제작해 보겠습니다.

 

우선 nodejs를 사용해 setScore라는 이름의 람다 함수를 하나 만듭니다.

 

ioredis module이 필요하기 때문에 실제 필요한 코드와 module은 zip으로 압축해서 올려야 합니다. 로컬에서 폴더를 만들어 모듈을 설치하고, index.js 파일에 아래 소스를 붙여 넣으세요.

 

npm install ioredis
// index.js

'use strict';
var Redis = require('ioredis');

exports.handler = (event, context, callback) => {
    var client = new Redis.Cluster([
        { 
            host: "your_redis_endpoint_1",	
            port: 6379
        },
        { 
            host: "your_redis_endpoint_2",
            port: 6379
        }
    ]);

   var key = event.id;
   var score = event.score;
   client.set(key, {"score": score}, (err, ret) => {
        if(err)
            console.info("err = ", err);
        else
            console.info("ret = ", ret);
        client.quit(()=> {
            callback(err, {body:  "Result : " + ret});    
        });
    })  
}

(* Redis를 클러스터 모드로 설정하지 않았다면 Redis.Cluster 대신 new Redis( "기본 엔드 포인트")로 지정하여 사용하세요.)

 

그리고 해당 폴더의 내용을 zip으로 압축 후 "업로드", 그리고 해당 함수를 저장합니다.

redis 주소는 위에서 생성한 세 노드 모두 입력해 두시면, 추후 특정 노드에서 문제 발생 시 별도 처리 없이 즉각 대응 가능합니다. 아래와 같이 설정된 redis 주소를 입력해 두시기 바랍니다. 

이제 이 함수가 Redis가 있는 VPC에 접근할 수 있도록 허용해야 합니다.

 

IAM에서 "역할" -> "역할 만들기"를 선택합니다.

그리고 Lambda를 선택 후 "AWSLambdaVPCAccessExecutionRole"역할을 선택합니다.

그리고 역할 이름을 "lambda-vpc-execution-role"로 입력하여 할당한 후 람다 함수로 돌아가 하단의 "실행 역할"에서 "lambda-vpc-execution-role"를 선택합니다. 

 

그리고 하단의 VPC 항목으로 가서 "test-vpc"를 선택하고 서브넷 항목에 db, management 서브넷을 선택합니다. 보안 그룹은 default를 선택한 후 람다 함수를 저장합니다.

이제 잘 작동하는지 테스트 해보겠습니다.

위와 같이 설정 후 테스트를 시도하면 아래와 결과를 확인할 수 있습니다.

ssh로 접속해서 잘 입력되었는지 확인 해보세요. :)

 

4. API Gateway 구성하기

REST API로 선택, "새 API" 선택, API 이름에는 "leaderboard"라는 이름으로 입력하겠습니다.

 

"leaderboard"API 화면에서 리소스를 생성하고, 리소스 이름은 "put-score"로 지정하세요.

 

그리고 메서드를 "POST"로 생성합니다.

그리고 "Lambda 함수"를 선택 후 위에서 생성한 "setScore" 람다 함수를 지정합니다.

 

이제 생성한 리소스를 배포할 차례입니다. "작업" 버튼을 눌러 "API 배포"를 선택하고 "배포 스테이지"에서 "새 스테이지"를  선택 후 "스테이지 이름"에는 "prod"라고 입력합니다. 

이제 스테이지로 가면 호출할 수 있는 URL을 확인 할 수 있습니다. curl을 이용해서 정상 작동하는지 확인해 보겠습니다.

curl -L -v -d "{\"id\": \"test_id2\", \"score\" : 1000}" -H "Accept: application/json" -H "Content-Type: application/json" path_your_url

 

수고하셨습니다. 최종 테스트를 한번에 잘 완료되셨길 바랍니다. 

 

"따라하기" 처럼 해볼 수 있도록 정리해 봤는데 도움이 되었나 모르겠네요. 어쨌든 나중에 까먹으면 다시 보려고 정리를 시작한 글인데 생각보다 꽤 오래 걸렸네요. 

 

무사히 잘 마치셨길 바라며 다음에는 DynamoDB 사용하면서 정리한 글로 다시 뵙겠습니다. :)

 

 

 

 

  1. MG 2020.09.12 14:05

    많은 도움을 받고 있습니다.
    "로컬에서 폴더를 만들어서 ioredis 모듈을 설치하고 ZIP 파일로 업로드" 이부분에서 막혔는데 도움을 받을 수 있을까요?
    npm install ioredis 를 터미널에서 실행하면

    npm WARN saveError ENOENT: no such file or directory, open '/Users/user/package.json'
    npm WARN enoent ENOENT: no such file or directory, open '/Users/user/package.json'
    npm WARN user No description
    npm WARN user No repository field.
    npm WARN user No README data
    npm WARN user No license field.

    + ioredis@4.17.3
    updated 1 package and audited 496 packages in 1.75s

    32 packages are looking for funding
    run `npm fund` for details

    found 48 low severity vulnerabilities
    run `npm audit fix` to fix them, or `npm audit` for details

    이렇게 나오네요..
    폴더를 지정해야 하는건지.. 아니면 모듈을 다운로드 받아서 압축만 풀면 되는건지 잘모르겠습니다..ㅜ

    • 가끔.하늘 가온아 2020.09.14 09:58 신고

      경고 메세지 입니다. npm init로 프로젝트 폴더 초기화를 해주시면 package.json 파일이 생성되고 npm install 되는 내용들이 저장됩니다.

      모듈 설치는 정상적으로 된 것이니 사용하시면 됩니다.

      npm audix fix 명령을 통해 low severity vulnerabilities 취약점 이슈도 같이 해결하고 가시면 좋습니다.

  2. MG 2020.09.15 17:12

    답변 감사드립니다 ^^

( Windows 10 / VisualStudio 2017 환경에서 테스트 되었습니다. )

 

우선 AWS Console에서 필요한 계정과 SQS 설정을 해보겠습니다. 이미 계정 생성과 SQS 설정이 되어 있다면 다음으로 건너띄시기 바랍니다. 

 

여기서는 sqs_tester로 만들어 보겠습니다.

 

권한은 쓰기, 읽기를 분리해도 되고, 테스트를 위해 생성한다면 AmazonSQSFullAccess로 적용해도 괜찮습니다.

이제 SQS를 세팅해 보겠습니다.

FIFO 대기열로 생성해 보겠습니다. 구성은 기본 상태로 진행하겠습니다. 아.. 대기열 이름 끝은 ".fifo"로 끝내야 하니 주의하세요. 그리고 초당 300개의 메세지를 처리할 수 있다고 하니 실제 사용하실 때는 이런 제한사항을 꼭 확인 후 사용하시기 바랍니다.

 

큐가 생성되었다면 이제 접근을 위한 권한을 생성해 보겠습니다. 생성된 큐를 선택하고 하단에서 "권한"탭을 선택합니다.

프린시펄에서는 iam에서 생성한 사용자 ARN을 추가합니다. 그리고 하단의 작업에서 허용할 권한을 선택합니다.

 

아래에는 보내기 위해 필요한 권한과 메세지를 가져오는 측의 권한을 별도 계정에 할당한 결과입니다.

 

이제 AWS 설정 과정은 모두 마무리 되었습니다. 이제 실제 메세지를 보내는 cpp 코드를 만들어 보겠습니다.

 

우선 필요한 package를 NuGet으로 설치하세요.

 

필요한 패키지는 core와 sqs만 있으면 됩니다.

설치 시 자신의 프로젝트를 선택하면 lib include 에 대한 내용은 자동으로 세팅됩니다.

 

리눅스 계열에서는 aws cpp sdk를 git clone 혹은 별도로 다운받아 설치하시면 됩니다. cmake 시 BUILDONLY 옵션으로 core와 sqs만 지정해서 빌드하시는게 빠릅니다. 전체 설치했다가는 ... -_-a

 

이제 main.cpp를 프로젝트에 추가하고 아래 코드를 붙여 넣어보겠습니다. 

#include <aws/core/Aws.h>
#include <aws/core/auth/AWSCredentialsProvider.h>
#include <aws/sqs/SQSClient.h>
#include <aws/sqs/model/SendMessageRequest.h>
#include <aws/sqs/model/SendMessageResult.h>
#include <iostream>

int main(int argc, char** argv)
{
	Aws::SDKOptions options;
	Aws::InitAPI(options);

	Aws::Client::ClientConfiguration clientConfig;
	clientConfig.region = "ap-northeast-2";

	{
		Aws::String queue_url = "https://sqs.ap-northeast-2.amazonaws.com/111111111/sqs_test.fifo" ;
		Aws::String msg_body = "{\"key\":\"your_key\", \"value\":\"your_message\", \"ip\":\"162.158.186.95\"}";
		Aws::String msg_group_id = "msg_group_name_text";

		Aws::SQS::SQSClient sqs(Aws::Auth::AWSCredentials("your_access_key", "your_secret_key"), clientConfig);

		Aws::SQS::Model::SendMessageRequest sm_req;
		sm_req.SetQueueUrl(queue_url);
		sm_req.SetMessageGroupId(msg_group_id);
		sm_req.SetMessageBody(msg_body);
		sm_req.SetMessageDeduplicationId("unique_value_for_deduplication");	

		auto sm_out = sqs.SendMessage(sm_req);
		if (sm_out.IsSuccess())
		{
			std::cout << "Successfully sent message to " << queue_url <<
				std::endl;
		}
		else
		{
			std::cout << "Error sending message to " << queue_url << ": " <<
				sm_out.GetError().GetMessage() << std::endl;
		}
	}


	Aws::ShutdownAPI(options);
	system("PAUSE");

	return 0;
}

https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/examples-sqs-messages.html 의 샘플 코드에 인증, 지역설정을 추가했습니다. 

 

그리고 FIFO 대기열을 위해 DeduplicationId를 추가했습니다. 이는 FIFO에서 중복된 메세지가 기록되지 않도록 하기 위한 값으로 일정 시간 안에는 유니크해야 합니다. 기록된 메세지가 이미 사라졌거나 같은 값이 존재하더라도 10분(?? 정확한 수치는 공식 문서에서 찾지 못했습니다.) 정도 지나면 중복된 값이 나오더라도 기록됩니다. 

 

만약 중복될 경우에도 메세지를 보내는 어플리케이션에서는 메세지가 정상적으로 보내졌다고 판단되고, FIFO 대기열에서는 DeduplicationID 를 체크해서 중복으로 보내진 내용은 대기열에 추가하지 않습니다. 

 

코드 설명은 짧고 간단해서 별도 추가 설명은 필요 없을 듯 하네요. 혹시 궁금한 점이 있으면 댓글로 남겨주세요.

 

 

java 사용할 때는 credential 파일과 config 파일을 자신 계정 루트에 .aws 폴더 만들어서 넣으면 되는데... 

 

cpp sdk에서는 region 정보가 담긴 config파일을 사용하지 않습니다.

 

https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html

(* cpp sdk에서 credential 설정하는 방법)

 

Aws::SDKOptions options;
Aws::InitAPI(options);

Aws::Client::ClientConfiguration clientConfig;
clientConfig.region = "ap-northeast-2";
.
.
.

Aws::SQS::SQSClient sqs(clientConfig);
.
.
.

위의 샘플 코드처럼 clientconfiguration을 별도 설정하여 사용할 서비스 생성 시 인자로 같이 넘겨주면 됩니다.

+ Recent posts