とあるITエンジニアのブログ: 2014

2014年2月19日水曜日

訂正：RDSのエンドポイントについて考察

こんにちは！

以前のブログ（RDSのエンドポイントについて考察）で設定に誤りがあったことがわりました。
ごめんなさい。

mysql-proxy.cnf内にあらかじめslaveを5台分書いておけば良いとしていましたが、mysql-proxyの起動時に名前引きをしていて、slaveを事前に作っておかないとmysql-proxyが起動しないようです。

そこで対策を考え中です。
良いアイデアがありましたら、コメントください！

また、もう１つの問題点は、そもそもmysql-proxyがダウンした場合について、考えが抜けていました。
そこでこれを解消するために、ELBをもう１つ使います。
ウェブ用のインスタンスのバランシングにHTTPのELBを用意していますが、これと同様にMySQLの3306ポートをバランシングするELBを用意します。

PHPなどで、DBの参照の際は、ELBのエンドポイントに接続するようにしてください。
更新は、masterのエンドポイントを指定します。

2014年2月18日火曜日

CloudFormationを使ってみた

こんにちは！

これまでブログに書かせてもらった内容をCloudFormationを使って、自動で作成してくれるように作ってみました。
図の構成が、自動でできあがります。

以下をテキスト保存して、CloudFormationでお試しください！

{
"AWSTemplateFormatVersion": "2010-09-09",
"Resources": {
"VPC": {
"Type": "AWS::EC2::VPC",
"Properties": {
"CidrBlock": "10.0.0.0/16",
"InstanceTenancy": "default",
"EnableDnsSupport": "true",
"EnableDnsHostnames": "true"
}
},
"subnet01": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.1.0/24",
"AvailabilityZone": "ap-southeast-1a",
"VpcId": {
"Ref": "VPC"
}
}
},
"subnet02": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "10.0.2.0/24",
"AvailabilityZone": "ap-southeast-1b",
"VpcId": {
"Ref": "VPC"
}
}
},
"inetgw": {
"Type": "AWS::EC2::InternetGateway",
"Properties": {
}
},
"dhcpopt": {
"Type": "AWS::EC2::DHCPOptions",
"Properties": {
"DomainName": "ap-southeast-1.compute.internal",
"DomainNameServers": [
"AmazonProvidedDNS"
]
}
},
"nwacl": {
"Type": "AWS::EC2::NetworkAcl",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"routetable": {
"Type": "AWS::EC2::RouteTable",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
"elbaslb": {
"Type": "AWS::ElasticLoadBalancing::LoadBalancer",
"Properties": {
"Subnets": [
{
"Ref": "subnet01"
},
{
"Ref": "subnet02"
}
],
"HealthCheck": {
"HealthyThreshold": "2",
"Interval": "30",
"Target": "HTTP:80/index.html",
"Timeout": "5",
"UnhealthyThreshold": "2"
},
"SecurityGroups": [
{
"Ref": "sgall"
}
],
"Listeners": [
{
"InstancePort": "80",
"LoadBalancerPort": "80",
"Protocol": "HTTP",
"InstanceProtocol": "HTTP"
}
]
}
},
"asgassg": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"Properties": {
"AvailabilityZones": [
"ap-southeast-1b",
"ap-southeast-1a"
],
"Cooldown": "300",
"DesiredCapacity": "1",
"MaxSize": "4",
"MinSize": "2",
"HealthCheckGracePeriod": "300",
"HealthCheckType": "ELB",
"VPCZoneIdentifier": [
{
"Ref": "subnet01"
},
{
"Ref": "subnet02"
}
],
"LaunchConfigurationName": {
"Ref": "lcaslc"
},
"LoadBalancerNames": [
{
"Ref": "elbaslb"
}
]
}
},
"rdsmaster": {
"Type": "AWS::RDS::DBInstance",
"Properties": {
"AutoMinorVersionUpgrade": "true",
"DBInstanceClass": "db.t1.micro",
"DBInstanceIdentifier": "master",
"Port": "3306",
"AllocatedStorage": "5",
"BackupRetentionPeriod": "1",
"DBName": "MyDatabase",
"Engine": "mysql",
"EngineVersion": "5.5.33",
"LicenseModel": "general-public-license",
"MasterUsername": "rdsuser",
"MasterUserPassword": "MyPassword",
"PreferredBackupWindow": "16:35-17:05",
"PreferredMaintenanceWindow": "mon:14:02-mon:14:32",
"MultiAZ": "true",
"VPCSecurityGroups": [
{
"Ref": "sgall"
}
],
"DBSubnetGroupName": {
"Ref": "dbsubnetmultiazsg"
},
"Tags": [
{
"Key": "workload-type",
"Value": "production"
}
]
}
},
"rdsslave0": {
"Type": "AWS::RDS::DBInstance",
"Properties": {
"AutoMinorVersionUpgrade": "true",
"DBInstanceClass": "db.t1.micro",
"DBInstanceIdentifier": "slave0",
"Port": "3306",
"SourceDBInstanceIdentifier": {
"Ref": "rdsmaster"
}
}
},
"lcaslc": {
"Type": "AWS::AutoScaling::LaunchConfiguration",
"Properties": {
"ImageId": "ami-56bee804",
"InstanceType": "t1.micro",
"KeyName": "astest",
"SecurityGroups": [
{
"Ref": "sgall"
}
], "BlockDeviceMappings": [
{
"DeviceName": "/dev/sda1",
"Ebs": {
"VolumeSize": 8
}
}
]
}
},
"dbsubnetmultiazsg": {
"Type": "AWS::RDS::DBSubnetGroup",
"Properties": {
"DBSubnetGroupDescription": "for Multi-AZ",
"SubnetIds": [
{
"Ref": "subnet01"
},
{
"Ref": "subnet02"
}
]
}
},
"sgall": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "allow all",
"VpcId": {
"Ref": "VPC"
},
"SecurityGroupIngress": [
{
"IpProtocol": "-1",
"CidrIp": "0.0.0.0/0"
}
],
"SecurityGroupEgress": [
{
"IpProtocol": "-1",
"CidrIp": "0.0.0.0/0"
}
]
}
},
"scalingDecreaseGroupSize": {
"Type": "AWS::AutoScaling::ScalingPolicy",
"Properties": {
"AdjustmentType": "ChangeInCapacity",
"ScalingAdjustment": "-1",
"AutoScalingGroupName": {
"Ref": "asgassg"
}
}
},
"scalingIncreaseGroupSize": {
"Type": "AWS::AutoScaling::ScalingPolicy",
"Properties": {
"AdjustmentType": "ChangeInCapacity",
"ScalingAdjustment": "1",
"AutoScalingGroupName": {
"Ref": "asgassg"
}
}
},
"alarmawsec2assgCPUUtilizationadd": {
"Type": "AWS::CloudWatch::Alarm",
"Properties": {
"ActionsEnabled": "true",
"ComparisonOperator": "GreaterThanOrEqualToThreshold",
"EvaluationPeriods": "1",
"MetricName": "CPUUtilization",
"Namespace": "AWS/EC2",
"Period": "300",
"Statistic": "Average",
"Threshold": "50.0",
"AlarmActions": [
{
"Ref": "scalingIncreaseGroupSize"
}
],
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "as-sg"
}
]
}
},
"alarmawsec2assgHighCPUUtilizationremove": {
"Type": "AWS::CloudWatch::Alarm",
"Properties": {
"ActionsEnabled": "true",
"ComparisonOperator": "LessThanThreshold",
"EvaluationPeriods": "1",
"MetricName": "CPUUtilization",
"Namespace": "AWS/EC2",
"Period": "300",
"Statistic": "Average",
"Threshold": "50.0",
"AlarmActions": [
{
"Ref": "scalingDecreaseGroupSize"
}
],
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "as-sg"
}
]
}
},
"acl1": {
"Type": "AWS::EC2::NetworkAclEntry",
"Properties": {
"CidrBlock": "0.0.0.0/0",
"Egress": true,
"Protocol": "-1",
"RuleAction": "allow",
"RuleNumber": "100",
"NetworkAclId": {
"Ref": "nwacl"
}
}
},
"acl2": {
"Type": "AWS::EC2::NetworkAclEntry",
"Properties": {
"CidrBlock": "0.0.0.0/0",
"Protocol": "-1",
"RuleAction": "allow",
"RuleNumber": "100",
"NetworkAclId": {
"Ref": "nwacl"
}
}
},
"subnetacl1": {
"Type": "AWS::EC2::SubnetNetworkAclAssociation",
"Properties": {
"NetworkAclId": {
"Ref": "nwacl"
},
"SubnetId": {
"Ref": "subnet01"
}
}
},
"subnetacl2": {
"Type": "AWS::EC2::SubnetNetworkAclAssociation",
"Properties": {
"NetworkAclId": {
"Ref": "nwacl"
},
"SubnetId": {
"Ref": "subnet02"
}
}
},
"gw1": {
"Type": "AWS::EC2::VPCGatewayAttachment",
"Properties": {
"VpcId": {
"Ref": "VPC"
},
"InternetGatewayId": {
"Ref": "inetgw"
}
}
},
"subnetroute1": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "routetable"
},
"SubnetId": {
"Ref": "subnet02"
}
}
},
"subnetroute2": {
"Type": "AWS::EC2::SubnetRouteTableAssociation",
"Properties": {
"RouteTableId": {
"Ref": "routetable"
},
"SubnetId": {
"Ref": "subnet01"
}
}
},
"route1": {
"Type": "AWS::EC2::Route",
"Properties": {
"DestinationCidrBlock": "0.0.0.0/0",
"RouteTableId": {
"Ref": "routetable"
},
"GatewayId": {
"Ref": "inetgw"
}
},
"DependsOn": "gw1"
},
"dchpassoc1": {
"Type": "AWS::EC2::VPCDHCPOptionsAssociation",
"Properties": {
"VpcId": {
"Ref": "VPC"
},
"DhcpOptionsId": {
"Ref": "dhcpopt"
}
}
}
},
"Description": ""
}

2014年2月13日木曜日

コンテンツの同期

こんにちは！

AutoScaleで増えていくWebサーバのコンテンツの同期についてです。

awsコマンドを使ってS3のデータを同期するのが良いかと思います。

aws s3 sync s3://bucketname/ /var/www/html/ --region ap-southeast-1

という感じです。
rc.localに書いておけば良いと思います！

2014年2月12日水曜日

Route53の文字列によるHealthCheckを試してみた

こんにちは！

AWSのRoute53を使って、サイト内の文字列によるHealthCheckを試してみました。

結論：

おそらく英数字記号のみ
おそらく問題無い場合が1、問題有りが0

最初に、Search Stringに日本語で書いたところ、結果が0でした。
文字列を変えてみたけど、結果は同じでした。
次に、英語で書いてみたところ、結果が1になりました。

0が正常なのか、1が正常なのかわからなかったので、サイト内に含まれていない英語を書いてみました。
結果は、0でした。

ですので、結論の内容が正しいかと思います。

トップページにDBから英数字をひっぱってくるようなPHPを用いて、この仕組みを使えば、WebとDBの連携が正常にできていることを監視できそうです！

追記
ちなみに、body内の文字列が対象と書いてあったけど、headタグ内のtitleに書いた文字列も対象になってました。

2014年2月7日金曜日

AMI公開しました

こんにちは！

AMIを公開しましたので、こちらで告知します。
Tokyo: ami-a7640ea6
Singapore: ami-56bee804

内容は、
Amazon Linux
Apache
PHP
MySQL-Proxy
td-agent

がyumを使ってインストールしてあります。

rc.localにyum updateの実行と、
td-agent.confのS3バケット内に、IPアドレスでフォルダを作るように、sedで設定の一部を書き換えるコマンドを記載しています。

httpd.confやphp.iniはデフォルトです。

mysql-proxy.cnfは、RDSのエンドポイントを書き換えて使ってください！

2014年2月6日木曜日

RDSのエンドポイントについて考察

こんにちは！

前回のブログでRead Replicaを増やしたときのことを考えるってことでしたが、

そもそもMySQL Proxyにあらかじめ想定範囲の台数分を設定してしまえば良いと思いました。

つまり、最初はslave2台で構成するとしても、将来的に5台まで増やしちゃうかもと想定するなら、あらかじめ5台に分散する設定を書いてしまえばいいということです。

MySQL Proxyの設定ファイルでいうと、

proxy-backend-addresses=master.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave01.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave02.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave03.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave04.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,slave05.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306

あとは負荷に応じて、3台目のRead Replicaをslave03という名前で、4台目をslave04という名前で・・・

と作っていけば良いと思います。

もちろん負荷が低くなったら、Read ReplicaをdeleteしてしまってもOKです。

そうなると、今度はRead Replicaを増減させるようなAuto Scalingのようなことができたら、もっとうれしいですね

何か方法があるか探してみます。

2014年2月5日水曜日

突発的なアクセス集中に耐える構成案

こんにちは！

これまでのブログの内容から、自分は図のような構成を提案します。
Instanceを作り込むのは大変ですが、1つ作ってAMIにして、AutoScaleで拡張していく構成です。

Instanceの中身は、

Apache
PHPなどのアプリ用の言語
MySQL Proxy
td-agent（fluentd）

といった感じです。

注意点は、MySQLの更新系は必ずRDSのmasterに接続するように、PHPなどで制御してください。
逆に参照系は、ローカルホストに接続するようにして、MySQL-Proxyが勝手に分散してくれます。

Apacheのアクセスログは、S3に保存されますが、アクセスログからサイトのアクセス分析をするのは、あまり現実的ではないと思ってます。GoogleAnalyticsなどの外部の分析ツールをページに埋め込んだ方がよいと思います。

※RDSのRead Replicaが増えたときの対処を、これから検討していきます。

2014年2月4日火曜日

ApacheのアクセスログをS3にためる

こんにちは！

fluentdを使って、ApacheのアクセスログをS3のバケットにためる手順です。
fluentdの設定が難しくて、なかなか苦労しました。
次回苦労しないように、ここに書き留めておきます。

TreasureDataリポジトリを追加します。
vi /etc/yum.repos.d/treasuredata.repo で次を記述します
[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
enabled=1
gpgcheck=0

fluentdをインストールします。
yum install -y td-agent

fluentdの実行ユーザでaccess_logを読めるように権限を設定します。

chgrp td-agent /var/log/httpd/

chmod g+rx /var/log/httpd/

設定ファイルを作成します※赤字の部分は修正してください。

vi /etc/td-agent/td-agent.conf

<source>
  type tail
  format apache2
  path /var/log/httpd/access_log
  pos_file /var/log/td-agent/httpd.access_log.pos
  tag s3.apache.access
</source>

<match s3.*.*>
  type copy

  <store>
    type s3

    aws_key_id AWS-ACCESS-KEY
    aws_sec_key AWS-SECRET-KEY
    s3_bucket apache-accesslog
    s3_endpoint s3-ap-southeast-1.amazonaws.com
    path access_log_
    buffer_path /var/log/td-agent/s3

    time_slice_format %Y%m%d_%H%M
    time_slice_wait 1m
    utc

    buffer_chunk_limit 256m
  </store>

</match>

起動します。

/etc/init.d/td-agent start

Apacheにアクセスして、ログがS3のバケット内に作成されればOKです！

RDSの参照分散(3)

こんにちは！

今日はMySQL Proxyの設定について書きたいとおもいます。
まずは図のような構成をAWSに作りました。

その後にEC2 Instanceに次の手順でMySQL Proxyを入れてRDSに分散するように設定しました。

1. InstanceにSSHでログインして、rootになります。
2. yum install -y --enablerepo=epel mysql mysql-proxy

__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2013.09-release-notes/
[ec2-user@standard ~]$ sudo su -
[root@standard ~]# yum install -y --enablerepo=epel mysql-proxy mysql
Loaded plugins: priorities, update-motd, upgrade-helper
epel/x86_64/metalink | 3.9 kB 00:00
epel/x86_64 | 4.2 kB 00:00
epel/x86_64/group_gz | 237 kB 00:00
epel/x86_64/updateinfo | 761 kB 00:00
epel/x86_64/primary_db | 5.9 MB 00:04
epel/x86_64/pkgtags | 881 kB 00:01
653 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package mysql.noarch 0:5.5-1.3.amzn1 will be installed
--> Processing Dependency: mysql55 >= 5.5 for package: mysql-5.5-1.3.amzn1.noarch
---> Package mysql-proxy.x86_64 0:0.8.2-1.el6 will be installed
--> Processing Dependency: libevent-1.4.so.2()(64bit) for package: mysql-proxy-0.8.2-1.el6.x86_64
--> Running transaction check
---> Package compat-libevent.x86_64 0:1.4.13-4.10.amzn1 will be installed
---> Package mysql55.x86_64 0:5.5.34-1.40.amzn1 will be installed
--> Processing Dependency: real-mysql55-common(x86-64) = 5.5.34-1.40.amzn1 for package: mysql55-5.5.34-1.40.amzn1.x86_64
--> Running transaction check
---> Package mysql55-common.x86_64 0:5.5.34-1.40.amzn1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================
Package Arch Version Repository Size
======================================================================================================================================================
Installing:
mysql noarch 5.5-1.3.amzn1 amzn-main 2.6 k
mysql-proxy x86_64 0.8.2-1.el6 epel 204 k
Installing for dependencies:
compat-libevent x86_64 1.4.13-4.10.amzn1 amzn-main 115 k
mysql55 x86_64 5.5.34-1.40.amzn1 amzn-updates 7.5 M
mysql55-common x86_64 5.5.34-1.40.amzn1 amzn-updates 48 k

Transaction Summary
======================================================================================================================================================
Install 2 Packages (+3 Dependent packages)

Total download size: 7.9 M
Installed size: 29 M
Downloading packages:
(1/5): compat-libevent-1.4.13-4.10.amzn1.x86_64.rpm | 115 kB 00:00
(2/5): mysql-5.5-1.3.amzn1.noarch.rpm | 2.6 kB 00:00
warning: /var/cache/yum/x86_64/latest/epel/packages/mysql-proxy-0.8.2-1.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY:00 ETA
Public key for mysql-proxy-0.8.2-1.el6.x86_64.rpm is not installed
(3/5): mysql-proxy-0.8.2-1.el6.x86_64.rpm | 204 kB 00:00
(4/5): mysql55-5.5.34-1.40.amzn1.x86_64.rpm | 7.5 MB 00:00
(5/5): mysql55-common-5.5.34-1.40.amzn1.x86_64.rpm | 48 kB 00:00
------------------------------------------------------------------------------------------------------------------------------------------------------
Total 6.7 MB/s | 7.9 MB 00:01
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Importing GPG key 0x0608B895:
Userid : "EPEL (6) <epel@fedoraproject.org>"
Fingerprint: 8c3b e96a f230 9184 da5c 0dae 3b49 df2a 0608 b895
Package : epel-release-6-8.9.amzn1.noarch (installed)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : compat-libevent-1.4.13-4.10.amzn1.x86_64 1/5
Installing : mysql55-common-5.5.34-1.40.amzn1.x86_64 2/5
Installing : mysql55-5.5.34-1.40.amzn1.x86_64 3/5
Installing : mysql-5.5-1.3.amzn1.noarch 4/5
Installing : mysql-proxy-0.8.2-1.el6.x86_64 5/5
Verifying : mysql55-common-5.5.34-1.40.amzn1.x86_64 1/5
Verifying : mysql-5.5-1.3.amzn1.noarch 2/5
Verifying : mysql-proxy-0.8.2-1.el6.x86_64 3/5
Verifying : compat-libevent-1.4.13-4.10.amzn1.x86_64 4/5
Verifying : mysql55-5.5.34-1.40.amzn1.x86_64 5/5

Installed:
mysql.noarch 0:5.5-1.3.amzn1 mysql-proxy.x86_64 0:0.8.2-1.el6

Dependency Installed:
compat-libevent.x86_64 0:1.4.13-4.10.amzn1 mysql55.x86_64 0:5.5.34-1.40.amzn1 mysql55-common.x86_64 0:5.5.34-1.40.amzn1

Complete!

3. vi /etc/sysconfig/mysql-proxy で次のように追記しました。

# Options for mysql-proxy

ADMIN_USER="admin"

ADMIN_PASSWORD=""

ADMIN_LUA_SCRIPT="/usr/lib64/mysql-proxy/lua/admin.lua"

PROXY_USER="mysql-proxy"

PROXY_OPTIONS="--daemon --log-level=info --log-use-syslog --defaults-file=/etc/mysql-proxy.cnf"

4. vi /etc/mysql-proxy.cnf で次のように記述しました。

※最終行は実際には1行で書きます。RDSのendpointをカンマ区切りで記述します。

[mysql-proxy]

plugins=admin,proxy

admin-lua-script=/usr/lib64/mysql-proxy/lua/admin.lua

admin-username=admin

admin-password=admin

proxy-address=127.0.0.1:3306

proxy-backend-addresses=mysqlproxytest-master.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,mysqlproxytest-slave1.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306,mysqlproxytest-slave2.ckj5g4ick5ri.ap-southeast-1.rds.amazonaws.com:3306

5. chmod 660 /etc/mysql-proxy.cnf で権限を変更します。※これをやらないとエラーが出ます。

6. vi /etc/init.d/mysql-proxy で起動スクリプトを一部改変します。※39行目

変更前）

daemon $prog $PROXY_OPTIONS --pid-file=$PROXY_PID --user=$PROXY_USER --admin-username="$ADMIN_USER" --admin-lua-script="$ADMIN_LUA_SCRIPT" --admin-password="$ADMIN_PASSWORD"

変更後）

daemon $prog $PROXY_OPTIONS --pid-file=$PROXY_PID --user=$PROXY_USER

7. /etc/init.d/mysql-proxy start で起動します。

8. 下のようになればOKです。

# mysql -u admin -p -h 127.0.0.1 -P 4041

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 1

Server version: 5.0.99-agent-admin

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * from backends;

+-------------+-----------------+---------+------+------+-------------------+

+-------------+-----------------+---------+------+------+-------------------+

| 1 | 10.0.0.73:3306 | unknown | rw | NULL | 0 |

| 2 | 10.0.0.169:3306 | unknown | rw | NULL | 0 |

| 3 | 10.0.1.188:3306 | unknown | rw | NULL | 0 |

+-------------+-----------------+---------+------+------+-------------------+

3 rows in set (0.00 sec)

mysql> exit

Bye

2014年2月3日月曜日

RDSの参照分散(2)

こんんちは！

前回予告してたとおり、HA ProxyとMySQL Proxyを検証して、RDSの参照分散を検討します。

HA Proxyはすぐに挫折しました。
設定と動作はできたのですが、HA Proxyの設定の内容がちゃんと理解できませんでした。
ネットで「HA Proxy MySQL」で検索したら設定の仕方は、けっこう出てきます。その通りにやったら出来ました。
が、その設定の内容が、HA Proxyのドキュメント（英語）を読んでもよくわかりません。
英語力の問題かもしれませんが・・・

ということで、MySQL Proxyを試しています。
いまのところ、2台のRDSのうち、片方には接続できていますが、もう片方につながらない状態です。

原因解決して、次回は手順を載せたいと思います。

2014年1月31日金曜日

RDSの参照分散

こんにちは！

RDSは便利ですけど、参照分散の方法については、どうするのが最適なのか悩んでいます。
オンプレでやっていたときは、LVSを使う方法を採用するケースが多くありました。

ただ、AWSだとLVSを使うのに少しコツがいるようです。
先々のトラブルを回避するために、LVSは見送ろうと思っています。

Route53を使ってHealthCheckかけてラウンドロビンしよう！と思ったけど、HealthCheckの対象はIPアドレスで固定しなければダメなようです。
ELBで負荷分散しよう！と思ったら、ELBはEC2インスタンスにしかバランシングができない仕様でした。

MySQL Proxyを使うか、HA Proxyを使うか・・・　どちらかを採用することになりそうです。
どちらも、来週から少し検証してみようと思います。

2014年1月30日木曜日

AWS AutoScale コンパネでやってみた（2）の修正版

こんにちは！

AutoScaleをコンパネでやってみた手順です。赤字が修正部分です。

○事前準備
KeyPairs: astest
Security Groups: astest-sec （SSH / HTTP / HTTPSを許可）
AMIs: asami （Amazon Linuxにhttpdを入れ自動起動にして、適当なindex.htmlを配置してあります）
ELB: astest-elb （AutoScaleで作成したInstanceをELBのバランシグ対象にします。作成時はInstanceは0個で作成しました。）

○シンガポールリージョンでやってます。
○ELBにInstanceを2つ作り、負荷に応じて4つまで増えるようにします。負荷が減ったら2つに戻るようにします。
○負荷はCPU使用率が平均で50%以上とします。

○手順

1. AUTO SCALINGのLaunch Configurationsを押します
2. Create Auto Scaling Groupのボタンを押します
3. Create launch configurationのボタンを押します
4. AMIを選びます。My AMIsの中のasamiを選びます
5. Instanceはそのままで、Nextボタンを押します
6. Nameを入れ（astest-lcとします）、Nextボタンを押します
7. Storageはそのままで、Nextボタンを押します
8. Select an existing security groupを選択して、astest-secを選択し、Reviewボタンを押します
9. Create launch configurationボタンを押します
10. key pairにastestを選択し、Create launch configurationボタンを押します

そのまま、Create Auto Scaling Groupの設定画面が出てきます

1. Group nameを入れます（astest-asgとします）
2. Group sizeを2にします
3. Availability Zoneにap-southeast-1aとap-southeast-1bの2つを入れます
4. Advanced Detailsを開きます
5. Load Balancingにチェックを付け、ELBを選択（astest-elb）します
6. Health Check TypeをELBにし、Nextボタンを押します
7. Use scaling policies to adjust the capacity of this groupを選択します
8. Scale between 2 and 4 instancesに変更します
9. Increase Group SizeにあるAdd new alarmを押します
10. 図のようにします。Nmae of alarmを変更するのがポイント！

11. Take the actionを Add 1 Instanceにします

12. Decrease Group SizeにあるAdd new alarmを押します
13. 図のようにします。Nmae of alarmを変更するのがポイント！

14. Take the actionを Remove 1 Instanceにします
15. Nextボタンを押します
16. Reviewボタンを押します
17. Create Auto Scaling groupボタンを押します

その後、インスタンスが2つできあがり、負荷によって増減するようになります。

2014年1月29日水曜日

AWS AutoScale コンパネでやってみた（3）

こんんちは！

前回の原因ですが、Scaling Policyがよろしくなかったです。
同じ名前のポリシーの中に、Instanceの追加と削除のアクションを2つともかいてしまっていたので、増やしたり減らしたりと、異常な感じでした。

50%以下になったら削除するポリシーと50%以上になったら追加するポリシーを別々の名前で作りましょう！

下の図のような感じです。
前回の手順の修正版は、後日出す予定です。

CentOS5のルート証明書期限切れ

こんにちは！

昨日付けでルート証明書の有効期限が切れたようです。
サーバからサーバへの接続に証明書を利用していると、証明書のエラーが出てしまい接続できない問題がでるようです。

GlobalSignのサイトから新しい証明書をダウンロードして解決！

AWS AutoScale コンパネでやってみた（2）

こんにちは！

AutoScaleをコンパネでやってみた手順です。

○事前準備
KeyPairs: astest
Security Groups: astest-sec （SSH / HTTP / HTTPSを許可）
AMIs: asami （Amazon Linuxにhttpdを入れ自動起動にして、適当なindex.htmlを配置してあります）
ELB: astest-elb （AutoScaleで作成したInstanceをELBのバランシグ対象にします。作成時はInstanceは0個で作成しました。）

○シンガポールリージョンでやってます。
○ELBにInstanceを2つ作り、負荷に応じて4つまで増えるようにします。負荷が減ったら2つに戻るようにします。
○負荷はCPU使用率が平均で50%以上とします。

○手順

1. AUTO SCALINGのLaunch Configurationsを押します
2. Create Auto Scaling Groupのボタンを押します
3. Create launch configurationのボタンを押します
4. AMIを選びます。My AMIsの中のasamiを選びます
5. Instanceはそのままで、Nextボタンを押します
6. Nameを入れ（astest-lcとします）、Nextボタンを押します
7. Storageはそのままで、Nextボタンを押します
8. Select an existing security groupを選択して、astest-secを選択し、Reviewボタンを押します
9. Create launch configurationボタンを押します
10. key pairにastestを選択し、Create launch configurationボタンを押します

そのまま、Create Auto Scaling Groupの設定画面が出てきます

1. Group nameを入れます（astest-asgとします）
2. Group sizeを2にします
3. Availability Zoneにap-southeast-1aとap-southeast-1bの2つを入れます
4. Advanced Detailsを開きます
5. Load Balancingにチェックを付け、ELBを選択（astest-elb）します
6. Health Check TypeをELBにし、Nextボタンを押します
7. Use scaling policies to adjust the capacity of this groupを選択します
8. Scale between 2 and 4 instancesに変更します
9. Increase Group SizeにあるAdd new alarmを押します
10. 図のようにします

11. Decrease Group SizeにあるAdd new alarmを押します
12. 図のようにします

13. Nextボタンを押します
14. Reviewボタンを押します
15. Create Auto Scaling groupボタンを押します

その後、インスタンスが2つできあがり、負荷によって増減するはずですが、
いきなり3つのインスタンスを作成されてしまいました。

原因とかそのあたりは、次回のブログで書く予定です。その前に原因調査ですが・・・・

AWS AutoScale コンパネでやってみた（１）

こんにちは！

AutoScaleをコンパネからやってみました。
結論としては、ELBに傘下させる方法がわからなく、うまくいってません。

設定途中のオプションのようなところをちゃんと見ていなかったので、設定できてないのかもしれません。

もう1度最初からやってみて、結果を明日のブログに書こうと思います！

ただ、別件で時間をとられてしまい、なかなか進捗はよくありません・・・

2014年1月27日月曜日

AWS AutoScaleをためしてみる

こんにちは！

以前はコマンドでしか設定できなかったAutoScaleですが、いまはコンパネから設定できるようになっています。
コンパネからの設定を試したことがなかったので、やってみようと思います。

手順などは、後日掲載する予定です！

2014年1月24日金曜日

yumでMySQL5.6をインストールする話

こんにちわ！
今日はAWSではなく、MySQLの話です。

CentOSでMySQLのインストールのときに、単にyumを使っても5.1だったりします。
EPELやREMIなどのリポジトリを追加しても、5.5にはなりますが、5.6をインストールしたい要件が多くなってきました。

これまでは、MySQLの公式ページからrpmをダウンロードしてきてインストールしてました。

ところが、昨日公式ページにyumのリポジトリが公開されているのを見つけました。
http://dev.mysql.com/downloads/repo/

これを使うと、さくっとMySQL5.6がインストールできます。
手順を残しておきます。

# rpm -ivh http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm
Retrieving http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:mysql-community-release-el6-5 ################################# [100%]

# yum install mysql-server

Loaded plugins: priorities, update-motd, upgrade-helper

1 packages excluded due to repository priority protections

Package mysql-server is obsoleted by mysql-community-server, trying to install mysql-community-server-5.6.15-1.el6.x86_64 instead

Resolving Dependencies

--> Running transaction check

---> Package mysql-community-server.x86_64 0:5.6.15-1.el6 will be installed

--> Processing Dependency: mysql-community-common(x86-64) = 5.6.15-1.el6 for package: mysql-community-server-5.6.15-1.el6.x86_64

--> Processing Dependency: mysql-community-client(x86-64) = 5.6.15-1.el6 for package: mysql-community-server-5.6.15-1.el6.x86_64

--> Running transaction check

---> Package mysql-community-client.x86_64 0:5.6.15-1.el6 will be installed

--> Processing Dependency: mysql-community-libs(x86-64) = 5.6.15-1.el6 for package: mysql-community-client-5.6.15-1.el6.x86_64

---> Package mysql-community-common.x86_64 0:5.6.15-1.el6 will be installed

--> Running transaction check

---> Package mysql-community-libs.x86_64 0:5.6.15-1.el6 will be installed

--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================

Package Arch Version Repository Size

======================================================================================================================================================

Installing:

mysql-community-server x86_64 5.6.15-1.el6 mysql56-community 51 M

Installing for dependencies:

mysql-community-client x86_64 5.6.15-1.el6 mysql56-community 17 M

mysql-community-common x86_64 5.6.15-1.el6 mysql56-community 296 k

mysql-community-libs x86_64 5.6.15-1.el6 mysql56-community 1.8 M

Transaction Summary

======================================================================================================================================================

Install 1 Package (+3 Dependent packages)

Total size: 71 M

Installed size: 322 M

Is this ok [y/d/N]: y

Downloading packages:

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

Installing : mysql-community-common-5.6.15-1.el6.x86_64 1/4

Installing : mysql-community-libs-5.6.15-1.el6.x86_64 2/4

Installing : mysql-community-client-5.6.15-1.el6.x86_64 3/4

Installing : mysql-community-server-5.6.15-1.el6.x86_64 4/4

Verifying : mysql-community-client-5.6.15-1.el6.x86_64 1/4

Verifying : mysql-community-libs-5.6.15-1.el6.x86_64 2/4

Verifying : mysql-community-common-5.6.15-1.el6.x86_64 3/4

Verifying : mysql-community-server-5.6.15-1.el6.x86_64 4/4

Installed:

mysql-community-server.x86_64 0:5.6.15-1.el6

Dependency Installed:

mysql-community-client.x86_64 0:5.6.15-1.el6 mysql-community-common.x86_64 0:5.6.15-1.el6 mysql-community-libs.x86_64 0:5.6.15-1.el6

Complete!

2014年1月23日木曜日

VM Importできました

こんにちわ！

AWSのVM Importが出来たので、その記録を残します。
参考になれば幸いです。

Import元のシステムは以下を使いました。
仮想： Citrix Xen Server 6.2.0 SP1

ゲスト：CentOS 6.4（10GBのストレージ、NIC*1）

作業環境は、Windows7 + Citrix Xen Centerと、

Ubuntu + ec2-api-toolsを使っています。

まずは、ゲストOSをExportしてイメージファイルを取ります。

完了すると、C:\CentOS6.4の中に、VHDファイルができあがります。

ここから先はAWSへの作業なります。

個人的にLinuxでの作業のほうが楽なので、出来あがったVHDファイルをUSBメモリ等でLinuxに持って行って作業します。（OVFファイルは不要です）

あらかじめ、S3のバケットと、インスタンスに適用するSecurityGroupを作成しておく必要があります。

次のコマンドを使って、S3にイメージをアップロードして、EC2インスタンスを作成します。

ec2-import-instance VHDファイル名 -t m3.xlarge -f VHD -a x86_64 -b S3バケット名 -g SecurityGroup名 -z ap-southeast-1a -p Linux --region ap-southeast-1 -o アクセスキー -w シークレットキー

一部改変しますが、具体的には、

ec2-import-instance 17519150-e914-46e5-8baf-d6805b6a4e2e.vhd -t m3.xlarge -f VHD -a x86_64 -b vhdfile-centos -g tcpall -z ap-southeast-1a -p Linux --region ap-southeast-1 -o ABCDEFGHIJKLMNOPQRST -w ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmn

イメージのアップロードの進捗が出ます。

Requesting volume size: 10 GB

TaskType IMPORTINSTANCE TaskId import-i-fgns67y9 ExpirationTime 2014-01-30T02:06:18Z Status active StatusMessage Pending InstanceID i-58fadb0e

DISKIMAGE DiskImageFormat VHD DiskImageSize 1065635840 VolumeSize 10 AvailabilityZone ap-southeast-1a ApproximateBytesConverted 0 Status active StatusMessage Pending

Creating new manifest at vhdfile-centos/18496c78-faf6-4006-943d-3c7301b2b533/17519150-e914-46e5-8baf-d6805b6a4e2e.vhdmanifest.xml

Uploading the manifest file

Uploading 1065635840 bytes across 102 parts

0% |--------------------------------------------------| 100%

|=======

その後、100%まで行くとコマンドプロンプトが返ってきます。

0% |--------------------------------------------------| 100%

|==================================================|

Done

Average speed was 0.868 MBps

The disk image for import-i-fgns67y9 has been uploaded to Amazon S3

where it is being converted into an EC2 instance. You may monitor the

progress of this task by running ec2-describe-conversion-tasks. When

the task is completed, you may use ec2-delete-disk-image to remove the

image from S3.

※ import-i-fgns67y9 タスクIDです。次のコマンドで使います。

その後、AWSで自動的にインスタンスの作成が始まっています。

次のコマンドで、インスタンスの作成状況を確認します。

ec2-describe-conversion-tasks --region ap-southeast-1 import-i-fgns67y9

TaskType IMPORTINSTANCE TaskId import-i-fgns67y9 ExpirationTime 2014-01-30T02:06:18Z Status active StatusMessage Progress: 56%InstanceID i-58fadb0e

DISKIMAGE DiskImageFormat VHD DiskImageSize 1065635840 VolumeId vol-6eaa8561 VolumeSize 10 AvailabilityZone ap-southeast-1a ApproximateBytesConverted 1065635840 Status completed

Progressが100%になったら完了です！

EC2のコンパネで確認してください。出来上がっているはずです。

最後に、不要になったらS3に保存されているイメージファイルを削除したほうが、お金の節約になります。

ec2-delete-disk-image --region ap-southeast-1 -o ABCDEFGHIJKLMNOPQRST -w ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmn -t import-i-fgns67y9

以上で、 VM Import の検証ができました！

2014年1月22日水曜日

VM Importを試してます

こんにちわ

AWSのVM Importを試してます。

Citrix Xen Server 5.6.0 SP2で稼働中のCentOS6.4を、AWS上で稼働させる目的でテストしています。

私の知識不足だと思いますが、３回ほど失敗しました。

VHDイメージファイルをS3にアップロードされるのですが、そこからインスタンス作成でエラーになってしまいます。

うまくいったら、手順も含めてまとめたいと思っています！

2014年1月20日月曜日

はじめまして

とあるITエンジニアのブログを始めました。
はじめまして。

最近問い合わせが増えてきているAWSのことを中心に、サーバやインフラについての雑多なことを書いていきたいと思っています。

AWSソリューションアーキテクトに１回落ちてしまいましたけど、次は合格できるように勉強中でもあります。
新しいサービスが次々に生まれてくるので、新しいことも覚えつつ、情報発信していきますので、よろしくお願いします。

登録: 投稿 (Atom)