블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

구글 클라우드 MySQL서비스의 흥미로운 가격 정책

조대협 (http://bcho.tistory.com)


구글 클라우드의 MySQL 서비스인 CloudSQL을 보다보니, 신기한 가격 정책이 있어서 정리해놓고자 한다.

1세대와 2세대의 가격 정책이 다른데, 1세대의 가격 정책이 재미있는점이 있다.


기본 가격 정책


1,2세대 모두 기본 적인 가격 정책은 다음과 같다


저장량 + 인스턴스 기동 비용 + 네트워크 비용

  • 저장량은 말 그대로 저장된 데이타의 양에 따라 과금이 된다
  • 네트워크 비용은 outbound로 나가는 트래픽만 과금이 되는데, 이것도 같은 리전 안의 구글 클라우드에서 호출하는 경우에는 과금이 되지 않는다. 과금이 되는 경우는 구글 클라우드를 쓰더라도 다른 대륙의 인스턴스가 호출을 하거나 또는 다른 클라우드 서비스에서 호출을 하는 경우에만 과금이 되기 때문에, 일반적인 상황에서는 거의 네트워크 트래픽 비용이 과금이 되지 않는다.
  • 인스턴스 기동 비용은 인스턴스가 떠있는 동안데 받는 비용인데 이 부분이 흥미롭다.
인스턴스 가동 비용

1세대 CloudSQL 경우 Package plan 과 Pay per use plan 두가지가 있다.
Package Plan은 일단위 과금이며, 인스턴스가 기동이 되어 있는 일 기준으로 과금이 된다. 이건 모 일반적인 것이고
흥미로운 가격 정책이라고 하는것은 Pay per use plan이다. Pay per use plan은 인스턴스가 떠 있는 시간동안 분당 과금을 하는 것이다. 일반적인 분당 과금 처럼 보일 수 있지만 재미 있는 것은 Cloud SQL 인스턴스 생성시 activation policy (활성화 정책) 이라는 것을 설정할 수 있는데, 이 활성화 정책을 ALWAYS(항상) 으로 해놓으면, 인스턴스를 수동으로 내리지 않는 이상은 항상 떠 있는 케이스이다. 여기까지가 일반적인것이고
활성화 정책중 ON DEMAND(요청시)로 해놓으면, MySQL이 15분 동안 아무 Request가 없으면 해당 MySQL 인스턴스는 자동으로 비활성화 되고 인스턴스 비용이 과금되지 않는다. 비활성화 상태에서 요청이 들어오면 자동으로 활성화 상태가 된다. ON DEMAND는 활성화 상태에서 사용량을 분당으로 과금한다.

아래 그림은 CloudSQL 인스턴스를 생성할때, ON DEMAND 활성화 정책 + 사용량에 따른 청구 방식으로 설정하는 화면이다.




쉽게 설명하면, 서버에 요청이 없으면 자동으로 대기 상태로 들어가면서 데이타 저장 비용만 과금이 되고, 인스턴스 비용은 과금이 되지 않는다는 이야기이다.

이는 항상 서버가 돌아도 되지 않는 일 배치나 또는 개발 환경등에 유용하게 사용될 수 있다. 
물론 이렇게 인스턴스가 될때만 과금하게 하는 것은 수동으로 데이타를 백업 받고 인스턴스를 내렸다가 사용할때 인스턴스를 새로 올리고 데이타를 부어도 되고 또는 수동으로 일일이 인스턴스를 껐다 켰다 해도 유사한 효과를 볼 수 는 있지만, AWS의 경우 시간당 과금이기 때문에, 개발 환경처럼 수분을 쓰고 마는 환경에서는 분당 과금인 CloudSQL에 비해서 금액 절약효과를 보기가 어렵고, 무엇보다 귀찮다.

아래는 20GB 용량을 하루에 4시간 정도 D32 인스턴스로(32GB 메모리 머신) , 300만 IO가 발생하는 일배치를 돌리는 시나리오에서 추가 IO가 없다고 가정할때 가격 시뮬레이션 한 케이스인데 Package plan을 이용할 경우 약 한달에 1116$, Pay per use plan을 사용할 경우 약 338$ 로 약 3.4배 정도의 가격 차이가 있는 것을 확인할 수 있다. 
(참고, Package Plan의 D32 인스턴스는 300만 IO까지는 무료이며, Pay Per Plan의 경우 무조건 100만건당 0.1$가 과금된다. 아래 계산 결과는 Pay per use는 모든 IO 가 과금이 되기 때문에 # of IO를 300만으로 입력하였고, Package Plan은 무료 IO를 넘는 부분에 대해서만 입력하기 때문에, 현재 계산에서 300만 IO는 D32 인스턴스 크기에서는 무료이기 때문에 별도 입력하지 않았다.)




1세대의  Pay per use plan을 사용하면 딱 트렌젝션을 돌릴때만 분당 과금을 할 수 있기 때문에 가격이 저렴해진다.
단 주의 할점은 오랜 시간 서버를 돌리는 경우에는 Pay per use plan 보다는 당연히 Package plan이 저렴하기 때문에 일정 시간 이상 인스턴스를 사용하는 경우는 Pay per use 보다는 package plan을 사용하기 바란다.

가격 정책에 대한 자세한 내용은 https://cloud.google.com/sql/pricing 에 있다. 
어떤 정책이 유리한지는 가격 시뮬레이션을 해보면 되는데 시뮬레이션용 계산기는 https://cloud.google.com/products/calculator/ 를 사용하기 바란다.



구글 CloudSQL(MySQL) 접속하기

조대협 (http://bcho.tistory.com)


개요 


구글 클라우드에서는 MySQL의 매니지드 서비스 형태로 CloudSQL 서비스를 제공한다. 

이 글에서는 CloudSQL을 서버에서 접근하는 방법과, 일반적인 MySQL 클라이언트로 접근하는 방법에 대해서 설명하고자 한다.


몇가지 배경


CloudSQL은 매니지드 MySQL서비스이다. 아마존에 RDS서비스와 같다고 보면 되는데 현재는 1세대를 서비스하고 있고, 곧 2세대가 서비스 예정이다.

1세대는 500GB까지의 용량까지 지원하고 있지만 2세대는 10테라까지 지원을 한다.

현재 지원되는 MySQL버전은 5.5와 5.6 지원하고, 내부 엔진으로는  InnoDB만을 제공한다.


2 세대에 기대되는 기능으로는 On Prem(호스팅 센터에 있는) MySQL과 복제 구성이 가능하다. On Prem에 있는 서버를 마스터로 할 수 도 있고, 반대로 마스터를 CloudSQL로 사용하고 읽기 노드를 On Prem에 구성하는 등 다양한 하이브리드 구성이 가능하다. (기대되는 부분)


자동 백업, 확장을 위한 읽기 전용 노드 (Read replica)등 필수적인 기능을 제공하고 있다.


연결 방식


CloudSQL은 RDS와는 다르게 private ip (10.x.xx)를 아직 지원하지 않고 public ip만을 지원한다. 그래서 서버에 접근하려면 이 public ip를 통해서 접근하면 된다. 보안을 위한 접근 통제 방법으로 특정 IP 주소에서 들어오는 트래픽만을 받아드리도록 설정이 가능하다.


또는 PaaS서비스인 구글 앱앤진을 사용하는 경우에는 구글 앱앤진의 인스턴스나 그룹 단위로 접근 통제가 가능하다.

다음 그림은 콘솔상에서 접근이 가능한 IP 주소를 지정하는 화면이다.



MySQL 클라이언트를 이용하여 접속을 할때 mysqlclient를 이용하여 직접 ip등을 입력하고 접속을해도 되지만 이 경우에는 CloudSQL에서 Ip를 허용해줘야 하기 때문에 개발이나 기타 운영 환경등에서 IP 주소가 바뀌면 그때 마다 설정을 해줘야 하기 때문에 불편할 수 있다.

이를 조금 더 편하게 하려면 mysqlclient를 사용하지 않고 구글에서 제공하는 "gcloud" 라는 도구를 이용하면, 별도로 접속 IP를 열지 않더라도 접속이 가능하다.

접속 방법은 먼저 gcloud  명령어를 인스톨 한 후에 


$ gcloud config set project [클라우드 프로젝트 이름]

$ gcloud beta sql connect [CloudSQL 인스턴스이름] —user=root

(여기서 --user=root 에서 root 사용자는 MySQL 인스턴스내의 사용자이다)


으로 접속하면 MySQL 클라이언트와 동일한 툴로 접속이 된다.


gcloud 툴킷을 이용한 자세한 접속 방법은 https://cloud.google.com/sql/docs/mysql-client#connect-ssl 를 참고하기 바란다.


참고

  • Toad, MySQL Workbench 등에서 안전하게 연결하는 방법 https://cloud.google.com/sql/docs/admin-tools#squirrel


AWS (Amazon Web Service) 사용시 주의 사항


1. IP가 매번 바뀐다.

aws의 ec2 instance는 restart시 마다 ip가 매번 바뀐다. ip를 바꾸지 않으려면 EIP (Elastic IP)를 사용해야 하는데, 비용이 크다. 그래서 이런 경우에는 aws에 자체 dns 서버를 세팅하고, instance 가 start up 될때 마다, 고유 서버의 dns 이름을 새로 binding된 ip와 맵핑해서 dns서버에 등록하도록 스크립트를 짜 놓으면 유용하다.


2. io bandwidth를 믿지 마라

aws의 가장 큰 어려운 점이, 네트워크 대역폭이다. 아무래도 공유 서비스이다 보니 네트워크 대역폭이 매우 느리다. 즉 내부 서버간 예를 들어 application server - dbms 또는 application server간에 네트워크 대역폭이 느리고 또는 일정하지 않기 때문에 대 부분의 병목이 여기서 발생한다.

이를 해결하기 위한 방법은 큰 ec2 instance를 사용하면 높은 대역폭을 사용할 수 있으며,

Provisioned IOPS를 지원하는 ec2 instance의 경우에는 일정 수준의 IOPS를 보장해준다. (물론 돈을 내야 한다.)

또는 고 성능의 IOPS를 보장하는 인스턴스를 사용하는 것도 방법이 된다.

다른 방법으로는 Placement group이라는 옵션을 사용할 수 있다. 이는 clustering이 필요한 솔루션 (Nosql이나 cache 솔루션)을 사용할때 이 placement group을 이용하면, 해당 서버들을 가능하면 물리적으로 가까운 곳에 위치 시켜서, network 지연을 최소화 한다.

참고 http://bcho.tistory.com/630


3. 미리 resource를 확보해라.

EIP는 5개, EC instance는 20개가 처음 계정을 만들었을때 디폴트 값이다. 테스트 환경을 사용하거나 몬가 하다보면 eip나 ec2 instance가 모자르게 되는데, 미리 미리 확장에 대비해서 확보해놓는 것도 중요하다. 신규 신청시 시간이 걸리기 때문에 미리 신청해놔야 하며, 상품에 따라서 미리 확보해놓으면 과금이 될 수 있다. 아래는 디폴트로 확보되는 자원의 수이다.

EIP – 5
EC2 instance – 20
EBS Volumes – 5,000 volumes or an aggregate size of 20 TiB (max volume size is 1TB)
PIOPS - 10,000 Provisioned IOPS or an aggregate size of 20 TiB (whichever is smaller) S3 Buckets – 100 
Route53 - 100 Hosted Zones and 10,000 Resource Record Sets per Hosted Zone 
ELB - 10 concurrent load balancers 
RDS – 20 RDS MySQL instances (each instance has hard limit max 1024GB) and up to 5 Read Replica instances can be created from a Master. 
VPC – 5 VPCs, 20 subnets each, 50 Security Groups each, 50 rules per Security Group and 5 Security Groups per instance. 10 Network ACLS per VPC, 20 rules per ACL. 10 Route Tables per VPC and 20 entries per route table


4. 가급적이면 VPC를 사용하자.

VPC는 Virtual Private Cloud의 약자로 10.x.x.x 와 같은 내부 ip 대역을 사용할 수 있게 해준다. 이는 논리적으로 다른 서비스(다른 사용자의)와 분리하게 해줄뿐더러, ip를 고정으로 사용할 수 있게 해주시 때문에 위의 1번 문제를 회피할 수 있도록 해준다.


5. 과금에 관련해서.

안쓸때는 꺼놔라. 다 과금 된다.

1시간5분을 사용하더라도 2시간으로 과금된다. 서버의 startup과 down은 시간 단위로 하자.


6. RDS

최대 용량이 1TB이다. 장점은 AZ(Zone)간의 HA를 기본적으로 지원한다.

replica는 db당 최대 5개 까지만 지원한다.


7. multicast

AWS는 multicast를 지원하지 않는다. 상당수의 클러스터링 솔루션이 muticast를 사용하는 경우가 많다.(Oracle RAC) 이경우에는 AWS에서 클러스터를 사용할 수 없다.


8. ELB는 고정 IP가 아니다.

ELB는 HA와 확장성을 지원하기 위해서 DNS Round Robine 방식으로 연결된다. 즉 고정 IP를 사용할 수 없다. 시스템에 대한 접근 IP(방화벽등을 위해서)가 필요할 경우 ELB 앞단에 HA Proxy등 별도의 Proxy를 둬야 한다.


9. AWS에는 IDS가 없다.

기본적으로 탑재된 침입 탐지등의 ids/ips 솔루션이 없기 때문에, 보안이 중요한 경우 이를 사전 고려 해서 ec2 위에서 기동 될 수 있는 ids/ips 솔루션을 탑재하는 것이 좋다.


10. 장기적인 이용에는 on-demand instance를 이용하지 마라.

on-demand instance는 그때 그때 사용하기는 좋지만 과금 모델이 가장 비싸다. 어느정도 기간을 가지고 이용할 예정이면 reserved instance나 spot instance를 이용하는 것이 저렴하다.







Amazon RDS 성능은 물리 서버의 30% 정도일 뿐!

Amazon RDS에서 DB 테이블 재구성하는 이슈가 있어서 물리 장비 테스트 후 

Amazon RDS에 적용한 적이 있습니다. 사용하고 있는 Amazon RDS 인스턴스가 성

능이 나쁘지 않은만큼 물리 장비 대비 크게 뒤쳐지지 않을 것이라고 예상을 했습니다.

그러나, 실제 적용해본 결과, 물리 서버 대비 30%정도 퍼포먼스만 발휘하는 결과가 

나왔습니다. 로컬 물리 DB에서 15분 걸리던 작업이, Amazon RDS에서는 45분 이상 

소요가 된 사례가 있습니다. 예상 시간보다 상당히 오래 걸려서 크게 당황을 했었죠.

무엇보다 MySQL은 단일 쓰레드에서 Nested Loop 방식으로 SQL을 처리하기 때문

에, CPU의 성능이 전체적인 DB 퍼포먼스에 직접적인 영향을 미칩니다. 병렬 처리가 

없다는 MySQL 특성이 Amazon RDS에서 가장 큰 병목이 되는 것입니다.


http://dev.kthcorp.com/wp-content/uploads/2012/11/H3_2012_double_sided.pdf

403페이지 내용中

AWS의 Zone은 같은 지역에 있는 물리적으로 다른 데이타 센터의 개념을 이야기 함.

RDS의 Multi Zone replication은 한 데이타 센터가 고장 나더라도 다른 데이타 센터에서 서비스가 가능한 구조.

기본적으로  Active-Stand by 형태로 복제하다가, 장애가 나면 stand by 서버로 fail over하는 구성


중요한 것중 하나는 MySQL RDS의 경우 자동 Back 시, 시스템이 일시적으로 멈추는 현상이 보이는데, Multi AZ deploy의 경우, back up시에, 자동 fail over하여, 멈추는 현상 없이 서비스가 가능함


http://aws.amazon.com/ko/about-aws/whats-new/2010/05/18/announcing-multi-az-deployments-for-amazon-rds/

Announcing Multi-AZ Deployments for Amazon RDS

We are excited to announce Multi-Availability Zone (Multi-AZ) deployments for Amazon Relational Database Service (Amazon RDS). This new deployment option provides enhanced availability and data durability by automatically replicating database updates between multiple Availability Zones. Availability Zones are physically separate locations with independent infrastructure engineered to be insulated from failure in other Availability Zones. When you create or modify your DB Instance to run as a Multi-AZ deployment, Amazon RDS will automatically provision and maintain a synchronous “standby” replica in a different Availability Zone. In the event of planned database maintenance or unplanned service disruption, Amazon RDS will automatically failover to the up-to-date standby so that database operations can resume quickly without administrative intervention.

The increased availability and fault tolerance offered by Multi-AZ deployments are well suited to critical production environments. To learn more, visit the Amazon RDS product page.