라벨이 [AWS]인 게시물 표시

[AWS] API Gateway API Key 발급 및 사용량 계획 생성하기

이미지
안녕하세요. 남산돈가스입니다. 오늘은 AWS의 API Gateway에서 연결 된 API들의 API키 발급을 통한 요청 제한, 그리고 사용량 계획을 통한 사용량 조절을 알아보겠습니다. 네이버클라우드에서 제공하는 SENS를 통해서 문자 발송서비스를 OPEN API로 요청하는 법을 지난 포스팅에서 다루어 보았습니다. 문자발송서비스를 앞으로 다양한 사용자에게 제공한다고 가정해보았을 때, 각각의 사용자들의 모두 컨트롤하기 어려운 상황에 놓이기 마련입니다. 그런 경우에 대비하여 API Gateway는 연결해놓은 API에 한하여 사용자들에게 API Key를 관리하여 요청 권한을 제공하고, 사용량 계획을 이용하여 일,월 요청 수 또는 n초 당 m개의 요청 수를 제한하는 기능을 제공하고있습니다. 이 두가지의 기능만을 이용한다면, 다양한 사용자에 대한 API 관리가 용이해질 수 있습니다. 그럼, 차근차근 하나씩 설정을 해보도록하겠습니다. 먼저 API Gateway 콘솔 화면에서 좌측 사용량 계획탭을 선택합니다. 사용량 계획에 대한 이름과 설명을 입력한 뒤, 중간의 조절 부분을 보시면 요율과 버스트를 설정할 수 있습니다. 요율을 n초당 요청 수를 설정하는 곳이고, 버스트는 해당 n초에 대해서 m번의 요청을 가능도록 하는 지 설정하는 부분입니다. 조절부분의 설정을 마치셨다면, 하단의 할당량에서 일,주,월 당 n개의 요청건수를 허용하는 양을 설정합니다. 사용량 계획 설정을 마치고 다음을 선택하면, 연결 된 API 스테이지를 설정하는 화면입니다. 앞에서 설정한 사용량 계획을 어떤 API에 적용할 지 설정하는 부분입니다. 저는 nCloud_SENS API의 dev스테이지에 사용량을 설정했습니다. 다음 화면은 사용량 계획 API 키를 발급하는 화면입니다. 'API 키 생성 후 사용량 계획에 추가' 버튼을 선택합니다. API 키 생성 팝업에서 저는 남산돈가스(사용자)의 API 키를 발급했습니다. 다음과 같이

[AWS] SSL 인증서 요청시 DNS 검증방법 사용하기

이미지
지난 포스팅에서 Certification Manager 를 통한  SSL 적용방법에 대해 다룬적이 있습니다. 지난포스팅 보러가기 SSL 인증서를 발급받기 위해서는 이메일 인증을 통해  사용중인 도메인 소유자 임을 인증해야 합니다. 얼마 전부터 AWS 에서 DNS 검증을 통한  도메인 소유자 인증을 지원하기 시작 했습니다. 도메인 계정 관리자와 서비스 관리자가 따로 있다면 매번 도메인 소유자 인증때 마다 계정 관리자에게 확인을 하거나 고객사에 연락하여 확인을 요청하는 방법밖에 없었지만 더이상 이런 번거로운 작업이 필요 없어 졌습니다. 아래와 같은 방법으로 도메인 인증을 진행합니다. 1. SSL 인증서 요청 인증서 요청 페이지 에서 사용하고자 하는 도메인 이름 입력 후 다음을 선택 합니다. 2. 검증 방법선택 검증방법에 DNS 검증이 추가 되었습니다. DNS 검증을 선택하고 다음을 선택합니다. 3단계: 검토 및 요청에서 내용을 확인후 다시 다음 단계로 넘어 갑니다. 3. 검증 도메인이 검증 대기 상태로 등록 됩니다. DNS 에 CNAME 항목에 입력할  이름 / 값  정보가 노출 됩니다. 도메인 사이트로 이동하여 DNS 설정 메뉴에서 해당 값을 입력해주면 되지만 Route53을 사용하고 있다면 “Route 53 에서 레코드생성” 버튼을 선택하면 됩니다. 클릭해 보겠습니다. 생성 버튼을 클릭하면 Route 53 을 통해 자동으로 CNAME 이 등록됩니다. 도메인 등록 성공 메시지가 표출 됩니다. 변경사항 전파에 30분이 소유 된다고 하니 계속을 선택하고 기다립니다. 기다리는 동안 Route 53 메뉴로 이동해서 확인해 보면 CNAME 이 등록된 것을 확인해 볼 수 있습니다. 다시 인증서 요청 화면으로 이동합니다. 변경사항 전파가 완료되면 도메인 검증이 완료되고 인증서가 정상적으로 발급되었다는 메시지

[AWS] T2 인스턴스 무제한(Unlimited) 기능

이미지
AWS 계정 생성후 12개월 동안 주어지는 Free-tier 사용을 위하여 T2.micro 인스턴스를 생성하게 됩니다. 일반적으로 많이 사용되고 있는 T2 계열 인스턴스의 가장 큰 특징은 CPU 크레딧 입니다. T2 인스턴스는 실행되는 동안 CPU 크레딧을 누적하고 최대 성능을 필요로 할때 누적 되어있던 크레딧을 사용(CPU 버스팅)하는 구조입니다. 이런 구조적 제약으로 인하여 누적된 크레딧을 모두 소진한 경우에는 CPU 성능에 제한이 적용되게 됩니다. *CPU 크레딧 CPU 크레딧 하나는 1분 동안 100%의 사용률로 실행되는 vCPU 하나에 해당합니다. vCPU, 사용률 및 시간의 여러 가지 조합이 CPU 크레딧 하나에 해당합니다. 예를 들어, vCPU 하나가 2분 동안 50%의 사용률로 실행되거나, vCPU 2개가 2분 동안 25%의 사용률로 실행될 수 있습니다. CPU 를 지속적으로 많이 사용하지 않는 서비스의 경우 많이 사용되지만 갑작스런 사용량의 증가가 있을 경우 언제 CPU 성능제한이 일어날지 모르기에 실제 운영중인 서비스는 어쩔수 없이 M4 계열을 이용하는 경우가 많습니다. 이런 제약조건에도 불구하고 T2 인스턴스의 인기가 매우 높기에 지난주 AWS에서 T2 인스턴스를 위한 신규 기능을 추가로 발표 했습니다. 바로 T2 무제한 (Unlimited) 기능 입니다. AWS 공식 블로그에 나와 있는 T2 무제한 기능의 설명입니다. *T2 무제한 기능 T2에서 제공하는 버스트 모델을 확장하여, 이제 최대한 낮은 비용으로 원하는 기간 동안 높은 CPU 성능을 유지할 수 있는 기능을 추가합니다. 사용하시려면 인스턴스를 시작할 때, 이 기능을 활성화하면 되고, 이미 실행 중인 인스턴스에 대해 이 기능을 활성화할 수도 있습니다. 24시간 동안 평균 CPU 사용률이 기준선보다 낮을 경우, 중간에 급증하는 모든 사용량이 시간당 T2 인스턴스 가격에 포함됩니다. 인스턴스가 장기간에 걸쳐 높은 CPU 사용률로 실행될 경우 소액의

[AWS] 예약인스턴스 할인 공유 및 Credit 할인 공유 비활성화 설정하기

이미지
지난 포스팅을 통해 AWS 통합계정 설정을 통한 계정관리 및 비용할인에 대해 알아보았습니다. 통합결제계정을 사용하는 경우 통합할인에 매우 유용하지만 Credit 을 사용하거나 예약인스턴스(RI) 를 사용하고 있는 경우에 계정별 사용비용 계산이 복잡해 지는 문제가 발생 합니다. 이는 AWS 에서  고객할인을 최대한 많이 보장하고자 통합계정을 사용하고 있는 경우 예약인스터스(RI) 요금에 대해서 자동으로  혼합(Blended) 요금을 적용하기 때문입니다. 아래는 혼합요금에 대한 AWS 설명 입니다. http://docs.aws.amazon.com/ko_kr/awsaccountbilling/latest/aboutv2/con-bill-blended-rates.html#Blended_Calculated 간단하게 Blended 요금에 대해 알아 보면 아래는 t2.micro 에 대한 요금 기준 입니다. 온디맨드 는  $0.0144 표준 1년계약 (선수금 없음) 은  $0.009 입니다 아래 그림과 같이 통합으로 연결되어 있는 계정 중 하나의 계정에서만 RI 를 적용한다고 가정해 보겠습니다. 위의 그림으로 보면 Nmadopass 계정은 $0.0144 , Fico2000 계정은 $0.009 가 시간당 청구 되어야 합니다. 그런데 실제 청구서를 보면 (0.0144 + 0.009) / 2 = 0.0117 과 같이 Namdopass $ 0.0117 (Blended price*) fico2000 $ 0.0117 (Blended price*) 로 표출되는 것을 확인 할 수 있습니다. 아래 그림은 실제 청구서에 Blended 금액이 표시된 화면 입니다. 예약인스턴스가 혼합 요금으로 적용된 것을 확인 할 수 있습니다. 이렇게 복잡한 비용관리를 간소화 하고자 AWS 에서 최근 계정간 RI 공유 비활성화 기능을 지원하기 시작 했습니다. 설정을 위해서 마스터 결제 계정 콘솔로 로그인 합니다. 결제 대시

AWS Lambda - API Gateway로 S3 파일 업로드 API 만들기 #3 - API Gateway - Lambda 연결 및 테스트

이미지
안녕하세요. 남산돈가스입니다. AWS Lambda - API Gateway로 S3 파일 업로드 API 만들기 #1 , #2 에 이어 마지막 시간인 API Gateway - Lambda 연결 및 테스트가 남았습니다. 지난 포스팅까지 Lambda를 이용해 업로드 함수를 생성했고, API Gateway와 S3 기본설정을 통해 S3 파일 업로드 기능의 기본설정을 마무리했습니다. 오늘은 이 두 설정들을 연결하여 최종적으로 S3 업로드 Micro Service를 완성하겠습니다. 먼저 지난 포스팅에서 API Gateway를 생성했고, uploader라는 리소스까지 생성했습니다. 이번엔 이 uploader라는 리소스에 POST 매서드를 추가하고 작성했던 Lambda Function을 설정합니다. 통합 유형 - Lambda 함수 Lambda 리전 - 'Lambda함수를 생성한 리전' Lambda 함수 - '작성한 Lambda 함수명(리전 선택 시 자동완성으로 검색 가능)' 위와 같이 설정한 뒤 저장을 선택합니다. 저장을 선택 시 다음과 같이 uploader라는 리소스 밑에 post 매서드가 생성 된 것을 확인하실 수 있습니다. 다음으로, 우측 상단의 통합 요청을 선택하시면 아래와 같은 화면이 나옵니다. 그 중에서 하단의 본문 매핑 템플릿을 선택합니다. 요청 본문 패스스루에서 '정의된 템플릿이 없는 경우'를 체크하고 Content-Type에 매핑 템플릿 추가하여 multipart/form-data  을 추가하고 '템플릿 생성'에서 매서드 요청 패스스루를 클릭하시고 아래와 같은 패스스루가 나온 것을 확인하셨으면 저장을 누릅니다. 여기까지 설정을 완료하셨다면, API Gateway와 Lambda Function의 연결이 모두 완료 된 것입니다. 이제 실제 이 API Gateway를 배포하여 엔드포인트를 발급받고 실제 업로드가 되는지

AWS Lambda - API Gateway로 S3 파일 업로드 API 만들기 #1 - Lambda 함수 생성

이미지
안녕하세요. 남산돈가스입니다.  이번 포스팅에서는 웹을 개발하면서 가장 골칫거리지만 자주 쓰이게 될 수 있는 파일 업로드 기능 구현에 대해서 포스팅하려고합니다.  하지만 일반적인 파일업로드가 아닌, Lambda로 S3에 파일을 업로드 시키는 함수를 생성하고, 해당 Lambda함수를 API Gateway에 연결하여 multipart-form 형식으로 파일을 업로드하는 Serverless 파일업로드를 구현할 예정입니다.  이런 방식으로 업로드기능을 구현하게 되면, 추후에 어디든지 파일업로드 기능을 쓸 수 있는 Micro Service가 될 수 있습니다. 포스팅은 다음과 같이 3회에 걸쳐 진행되겠습니다. #1. Lambda 함수 생성 #2. API Gateway, S3 셋팅 #3. API Gateway - Lambda 연결 및 테스트 그렇다면 지금부터 그 첫번째 단계인 Lambda 함수 생성을 진행해보겠습니다. 먼저 Lambda 서비스에 접속한 뒤 Node.js 기반의 새로운 함수를 생성합니다. 함수를 생성하면 아래와 같이 트리거가 추가되지 않은 날것의 함수가 생성된 것을 확인하실 수 있습니다.  쥐도 새도 모르게 변하는 AWS 콘솔 덕분에(?) 매번 포스팅할 때마다 Lambdad의 콘솔화면이 다채롭게  변하고있네요...ㅎㅎ 기존의 포스팅에서는 위 사진처럼 인라인으로 편집하는 포스팅만 진행했었는데 금번 포스팅에서는 외부 node_module을 사용하는 경우라 로컬에서 작업한 소스를 ZIP파일 형식으로 업로드하여 함수를 생성해보겠습니다. 로컬 터미널에서 upload라는 폴더를 생성하고 index.js을 생성합니다. index.js 그리고 해당 함수에 필요한 node_module을 install 하기 위해서 npm install 명령어를 사용합니다. 필요 모듈 aws-sdk : AWS javascript sdk 모듈 parse-multipart : multipart형식으로

[AWS] Amazon 통합결제와 대량구매할인 서비스

이미지
AWS의 모든 요금체계는 기본적으로 사용한 만큼 비용을 지불하는 종량제 서비스 입니다. 하지만 충성고객 유치를 위하여 대량의 서비스사용 고객을  대상으로 요금을 할인해 주는 계층 서비스 요금 을 동시에 적용하고 있습니다. S3 서비스가  그 대표적인 예 입니다 아래 그림과 같이 최초 50TB 사용시 에 과금 금액과 이후 50TB 초과 사용시 의 금액이 서로 상이 함을 확인 할 수 있습니다. 이처럼 계층형 서비스 요금 은 단일 사용자가 다량의 서비스를 이용할 경우 가격인하 혜택의 적용을 받을수 있습니다. 하지만 기업의 부서별로 별도의 계정 을 관리하고 있거나 서비스 별로 별도의 계정 을 사용하는 경우는 어떨까요?  AWS 의 요금결제는 계정을 기준으로 이루어 각 계정간 서비스 사용량이 분산되어 요금 할인이 적용되지 않게 됩니다. 이런 경우에 사용할수 있는 서비스가  AWS Organizations의 통합 결제 기능  입니다. 통합결제 서비스는 아래와 같이 결제를 위한 Master Account 를 설정하고 하위에 Member Account 를 연결하여  Master Account 를 통해 모든 비용결제가 이루어 집니다. 또한 Master Account 에 연결된 Member Account 의 비용보고서도 한번에 확인이 가능합니다.   이때, Member Account의  서비스 이용량을 통합하여 대량할인 적용 이 이루어 집니다. AWS 에서 설명하고 있는 통합결제 계정의 장점 입니다. 통합결제의 장점  1. 하나의 청구서 – 여러 계정에 대해 하나의 청구서를 받습니다. 2. 추적 용이    – 각 계정의 요금을 간편하게 추적하고 비용 데이터를 CSV 형식으로 다운로드할 수 있습니다. 3. 사용량 통합    – 현재 여러 계정을 보유한 경우 AWS가 조직 내 모든 계정의 사용량을 통합하여 대량 구매 요금 할인 자격을 부여하므로 요금이 줄어들 수 있습니다. AWS 에서 설명하고 있는

[AWS] Amazon Polly 한국어 서비스 지원

이미지
지난 포스팅에서  Naver Clova Speech Synthesis (CSS) 를 통한 Text To Speech 서비스에 대해 간략하게 알아보았습니다. http://devstory.ibksplatform.com/2017/11/naver-clova-speech-synthesiscss-api.html AWS 에서는 아직 한국어 서비스가 지원되지 않고 있었는데 16일부터 Amazon Polly 서비스가 한국어 읽기 서비스를  지원한하고 합니다. Amazon Polly 는 AWS의 딥러닝 기반 TTS 서비스 로 2016년 처음 선을 보인 이후로 드디어  한국어 서비스를 지원하고 있습니다. AWS 콘솔을 통해 Amazon Polly 에 접속해 보면 현재 Seoyeon (서연) 이라는 이름의 여성 음성 한가지를 지원 중입니다. Naver 서비스와 조금 다른점은 API 콘솔을 통해서 바로 음성듣기 기능 테스트가 가능합니다. 첫인상은 네이버 CSS 서비스 보다 조금 더 자연스러운 느낌입니다. 스트리밍 방식을 사용하기 때문에 긴 텍스트를 한번에 입력해도 바로 음성재생 가능하다고 합니다. 추가적으로 SSML ( Speech Synthesis Markup Language (SSML) Version 1.1, W3C Recommendation ) 에 정의된 SSML 마크업 태그를 지원합니다. 지원되는 SSML 태그 형식을 활용하여 좀더 자연스럽운 말투나 효과 적용이 가능합니니다. <speak>   // SSML태그 루트 <break>   // 스피치에서 일시 중지 <lang>    // 특정단어 및 구 <mark>    // 텍스트 내에 사용자 정의 태그 배치 <p>       // 텍스트 단락 <phoneme> // 음성발음 지정 <prosody> // 텍스트의 볼륨, 속도 및 음색을 제어 <s>       // 

[AWS] CLI 를 활용한 RDS Cluster snapshot Restore

이미지
AWS 에서 제공되는 관리형 DB 서비스인 Aurora DB 를 활용하면 아래 림과 같이 자동으로 클러스터 스냅샷이 생성 되게 됩니다. 이때  콘솔을 통해서 Restore Snapshot 을 진행하게 되면 클러스터와  RDS 인스턴스가 자동으로 생성되게 됩니다. 동일한 작업을 AWS CLI로 진행하고자 아래  명령어를 통해 RDS 를 생성해 보았습니다.   restore-db-cluster-from-snapshot [--availability-zones <value>] --db-cluster-identifier <value> --snapshot-identifier <value> --engine <value> [--engine-version <value>] [--port <value>] [--db-subnet-group-name <value>] [--database-name <value>] [--option-group-name <value>] [--vpc-security-group-ids <value>] [--tags <value>] [--kms-key-id <value>] [--enable-iam-database-authentication | --no-enable-iam-database-authentication] [--cli-input-json <value>] [--generate-cli-skeleton <value>] Colored by Color Scripter cs Snapshot을 통해 DB가 정상적으로 만들어진 것 처럼 표출 되지만 아래와 같이 빈 클러스터만 생성되고 instance 가 생성되지 않습니다. 아무리 찾아봐도 Cluster를 동시에 생성할수 가 없어서 검색을 하다보니 CLI를

[AWS] 사용중인 EC2 인스터스의 Type 변경하기

이미지
AWS Free Tier 사용목적으로 계정을 생성하고 Amazon EC2 인스턴스를 생성하게 되면 일반적으로 Free Tier 지원이 가능한 t2.micro Type 의 인스턴스 를 구성하게 됩니다. 하지만 서버구성후 개발 프로그램 테스트를 진행하다 보면 리소스 부족으로 인해 인스턴스 Type 변경이 필요한 경우가 생기게 됩니다. 이때 인스턴스 Type 을  변경하기 위한 두가지 방법이 존재 합니다. 첫번째 방법은 AMI 이미지 생성 후 해당 이미지를 복원하여 신규 EC2 인스턴스를 생성하는 방법입니다. 이 방법은 서버 절체 시간을 최소화 할수 있는 장점이 있지만 VPC,  Subnet, Securety Group 등 설정 작업이 필요합니다. 두번째 방법은  현재 인스턴스  형상 그대로 Type 만 변경하는 방법으로 매우 편리하게 Type 변경이 가능하지만 서버 운영을 잠시 중단했다가 다시 시작해 주어야 합니다. 24시간 운영되는 서비스가 아닌 테스트용 서버의 경우에는 번거로움을 최소화 하는 두번째 방법으로 인스턴스 타입 변경이 가능합니다. 두번째 방법을 통해 EC2 인스턴스의 타입 변경방법을 확인해 보도록 하겠습니다. 1. 인스턴스 중지 EC2 대시보드에서 변경하고자 하는 인스턴스를 선택 후 작업 > 인스턴스 상태 > 중지 를 선택합니다. 2. 변경 유형 선택 인스턴스 중지가 완료 되면 작업 > 인스턴스 설정 > 인스턴스 유형변경을 선택 합니다. 인스턴스 유형변경 팝업이 노출되면 변경 하고자 하는 인스턴스 타입을 선택하고 “적용” 합니다. m4.large 를 선택해 보겠습니다. 타입 변경 후 인스턴스 유형을 확인해 보면 m4.large 로 변경된 것을 확인할 수 있습니다. 3. 인스턴스 재실행 이제 인스턴스 실행을 위해 작업  > 인스턴스 상태 > 시작을 선택 합니다. 해당 인스턴스 부팅

[AWS] 운영중인 EC2 Instance의 EBS 볼륨 확장하기

이미지
EC2 인스턴스는 실행중인 서버의 스토리지 볼륨을 확장 할 수 있습니다. 콘솔에서 EBS의 볼륨 크기를 수정하고 인스턴스에 접속하여 파티션을 확장해 주면 됩니다. 1. AWS 콘솔에서 EBS 볼륨 확장하기 EC2 대시보드 에서 확장하고 싶은 EBS 선택한 후 작업 > 볼륨수정 을 선택합니다. 볼륨수정 팝업이 표출되면 크기를 원하는 사이즈로 변경한 후  “수정” 버튼을 선택합니다. 확인 메시지가 출력되면 “예” 를 선택합니다. 대시보드에서 확인해 보면 크기가 8GB 에서 10GB 로 변경된 것을 확인할 수 있습니다. 변경작업이 완료될 때 까지 상태가 “Optimizing” 으로 표시됩니다.   확장이 완료 되었습니다. 2. 인스턴스의 볼륨 파티션 확장하기 AWS 콘솔을 통한 볼륨 확장이 완료되면 인스턴스에 접속하여 파티션을 확장해 주어야 합니다. 인스턴스에 SSH 접속 후 $ lsblk 명령어를 통해 파티션 영역을 확인합니다. 디스크는 10GB 로 확장되었지만 파티션 영역은 8GB 만 사용되고 있는걸 확인할 수 있습니다. 파티션 확장을 위하여 $ sudo growpart /dev/xvda 1 명령어를 입력합니다. $ lsblk 명령을 실행해 파티션이 확장 되었는지 확인합니다. 파티션이 10G 로 변경된 것을 확인할 수 있습니다. $ df –h 명령어를 통해 마운트 영역을 확인해 보면 /dev/xvda1  은 여전히 8GB의 디스크 공간만 사용되고 있음을 확인 할 수 있습니다. 디스크공간을 확장하기 위해  $ sudo resize2fs /dev/xvda1 명령을 실행합니다. $ df –h 명령을 실행해 디스크 공간을  확인 합니다. AWS 콘솔을 통해 확장한 만큼 10GB 영역이 마운트 되어 있는 것을 확인할 수 있습니다.