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

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를 배포하여 엔드포인트를 발급받고 실제 업로드가 되는지 확인만 해보면 됩니다.
작업 탭을 선택하시고 API 배포를 선택한 뒤 배포할 스테이지 이름 및 설명…

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형식으로 들어 온 파일을 데이터 형식으로 변환sha1 : 암호화 모듈bluebird : 비동기 Promise …

[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 에서 설명하고 있는 통합결제 대량구매 할인 예시 입니다.

통합결제 대량구매 할인 예시

Bob 과 Susan  이…

[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>       // 텍스트에서 문장을 나타냄  <say-as>  // 텍스트 해석…

[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를 통해 Cluster Snapshot 을 복원하게 되면 추가적으로 인스턴스 생성작업을 다시 진행해 주어야 했습니다…

[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. 인스턴스 재실행
이제 인스턴스 실행을 위해
작업  > 인스턴스 상태 > 시작을 선택 합니다.


해당 인스턴스 부팅이 완료되면 변경 적용이 완료 됩니다.

이상 간단한 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 영역이 마운트 되어 있는 것을 확인할 수 있습니다.





AWS RDS parameter group을 이용해 character-set 변경(utf8), 타임존 변경하기

이미지
지난 포스팅에선 AWS RDS 파라미터 그룹을 생성하고 function을 생성할 수 있는 권한을 만들기 위해서 log_bin_trust_function_creators 변수를 변경해주었습니다.

이번 포스팅에선 지난 포스팅에서 생성한 파라미터 그룹을 이용하여 character-set , 타임존을 변경해보겠습니다.

우선 RDS 대시보드 콘솔로 이동합니다.


왼쪽 메뉴의 파라미터 그룹으로 이동합니다.

지난 포스팅에서 생성한 my-parameter-group 이 있습니다. 선택하시고 파라미터 편집으로 이동합니다.

필터에 character_set 으로 검색하면 6개의 항목이 나오는데 값 편집으로 모두 utf8로 변경합니다.
character_set_client : utf8character_set_connection : utf8character_set_database : utf8character_set_filesystem : utf8character_set_results : utf8character_set_server : outfit
그 다음으로, collation으로 검색을 하면 두가지 항목이 나오는데 utf8_unicode_ci로 변경합니다.
collation_connection : utf8_unicode_cicollation_server : utf8_unicode_ci 여기까지 수정하셨다면, 데이터베이스의 utf8 설정이 완료 된 상태입니다. 이제 timezone을 설정해보겠습니다.

MySQL Workbench에서 해당 RDS에 접속하고 한글화 설정을 위한 프로시져를 등록합니다.

DELIMITER | CREATE PROCEDURE '설치한 DB명'.`store_time_zone`() IF NOT (POSITION('rdsadmin@'INCURRENT_USER()) =1) THEN SET SESSION time_zone ='Asia/Seoul'; END IF | DELIMITER ;


프로시져를 등…

[AWS] 독립네트워크 구성을 위한 VPC 생성

이미지
VPC (Virtual Private Cloud) 는 AWS 에서 제공하는 가상네트워크 입니다.
최초로 AWS의 계정을 생성하고 인스턴스를 구성하게 되면 VPC에 대해 크게 신경을 쓰지않아도
서비스 구성에 큰 불편함이 발생하지 않습니다.
최초 계정 생성시 Default 로 생성된 VPC 를 통해 모든 서비스가 이루어 지기 때문입니다.

하지만 말 그대로 Default 설정이기 때문에 아무런 설정도 이루어져 있지 않습니다.

사용자는 필요에 따라 VPC 를 신규로 생성할 수 있으며
VPC 내부에 복수개의 Subnet 을 구성하여 네트워크를 격리 할수도 있습니다.

다음은 VPC 마법사를 통해서 생성이 가능한 4가지 구성입니다.

1. 단일 퍼블릭 서브넷이 있는 VPC

VPC 내부에 퍼블릭 접속이 가능한 단일 Subnet 서브넷 구성으로 Default VPC 구성과 동일 합니다.

2.  퍼블릭 및 프라이빗 서브넷 이 있는 VPC

일반적으로 가장 많이 사용하게 되는 구성으로 VPC 내부에
퍼블릭 네트워크와 프라이빗 네트워크를 분리하는 Subnet 구성입니다.


3. 퍼블릭 및 프라이빗 서브넷이 있고 하드웨어 VPN 액세스를 제공하는 VPC

하드웨어 VPN 연결이 가능한 구성으로
사내 인프라 구성과 Cloud 환경의  인프라를 VPN 으로 연결할 수 있는 구성입니다.


4. 프라이빗 서브넷만 있고 하드위에 VPN 액세스를 제공하는 VPC

3번 구성과 동일하지만 Couud 환경에 프라이빗 서브넷만 구성하였으므로
Cloud 환경의 외부 접속은 원척적으로 차단되고 사내 데이터 센터에서 VPN 을 통해서만
Cloud 환경 접속이 가능합니다.


그럼 실제로 VPC 환경을 새로 구성해 보도록 하겠습니다.
일반적으로 가장 많이 사요되는 퍼블릭/프라이빗 서브넷 혼용 VPC 를 생성하겠습니다.

마법사를 통한 VPC 생성을 진행하면 콘솔에서 자동으로 VPC 네트워크 구성과
프라이빗 | 퍼블릭 서브넷을 각각 생성해 줍니다.
VPC 이름을 입력하고 NAT 게이트웨이에…