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

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

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 : utf8 character_set_connection :  utf8   character_set_database :  utf8 character_set_filesystem :  utf8 character_set_results :  utf8 character_set_server :  outfit 그 다음으로, collation으로 검색을 하면 두가지 항목이 나오는데 utf8_unicode_ci로 변경합니다. collation_connection :  utf8_unicode_ci collation_server : utf8_unicode_ci 여기까지 수정하셨다면, 데이터베이스의 utf8 설정이 완료 된 상태입니다. 이제 timezone을 설정해보겠습니다. MySQL Workbench에서 해당 RDS에 접속하고 한글화 설정을 위한 프로시져를 등록합니다. DELIMITER | CREATE PROCEDURE '설치한 DB명' . `store_time_zone` () IF NOT (POSITION( 'rdsadmin@' IN CURRENT_USER ()) = 1 ) THEN SET SESSION

[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 네트워크 구성과 프라이빗 | 퍼블릭 서브넷을 각각 생성해 줍니다. V

AWS RDS parameter group을 이용하여 Function 생성하기

이미지
지난 포스팅에서 AWS RDS를 이용해 MySQL DB를 생성해보았습니다. 이후에 MySQL DB에서 Fucntion을 생성하고 사용해야하는 경우가 생기게 됩니다. 예를 들어, DROP FUNCTION IF EXISTS hello_world; DELIMITER $$ CREATE FUNCTION hello_world (addressee TEXT ) RETURNS TEXT DETERMINISTIC READS SQL DATA BEGIN RETURN CONCAT( 'Hello ' , addressee); END; $$ DELIMITER ; SELECT hello_world( 'Earth' ); 위와 같은 FUNCTION을 생성하려고 SQL문을 작성하고 실행해보면 AWS RDS는 Error Code: 1419. You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) 이런 에러가 발생하게 됩니다. 에러를 확인해보면 log_bin_trust_function_creators_variable 를 설정하라는 내용입니다. 기존의 로컬이나 물리적 서버 설치였으면 cnf와 같은 환경설정 파일 상에서 환경변수를 설정해줄 수 있었지만,  AWS RDS는 ssh와 같은 접속을 지원하지 않기때문에 parameter group 설정을 지원하고있습니다. AWS RDS Dashboard로 이동합니다. 왼쪽 메뉴에서 파라미터그룹탭으로 이동하면 default 그룹만 있는 상태입니다. 파라미터 그룹 생성을 클릭합니다. 사용하고 있는 DB 엔진을 선택하고 그룹이름과 설명을 입력하고 생성을 클릭합니다. 새로 생성한 파라미터 그룹의 파라미터 편집버튼을 누르고 필터에 function이라고 입력