ラベル Amazon の投稿を表示しています。 すべての投稿を表示
ラベル Amazon の投稿を表示しています。 すべての投稿を表示

2013年8月14日水曜日

s3cmd を用いた s3内における複数ファイル移動ワンライナー


s3に格納している大量のファイルを別のパスに移す必要があり、
Webコンソールでディレクトリのカット&ペーストでやろうとしたのですが、
途中で何度やり直してもエラーになってしまい、困ってしまいました。

しょうがないからs3cmdを用いて1ファイルずつ移動したので、後々のためにコマンドをメモ。


for i in `s3cmd ls s3://バケット名/元ファイルがあるディレクトリパス/ | awk '{ print $4 }'`; do s3cmd mv $i s3://バケット名/移動先のディレクトリパス/ ; done

実行後に、そういえば s3cmd でディレクトリのカット&ペーストって出来ないのかな…
って思いましたが、特に試してません(笑)


おしまい。

2013年5月26日日曜日

AWSの利用料金をzabbixに登録する


若干の今更感がありますが、とある出来事をきっかけに AWS CloudWatch APIを用いて、
zabbixに利用料金を登録するようにしたのでメモ。


とある出来事

AWS上に構築しているとあるシステムがあるのですが、運用がある程度落ち着いてきているため、
利用料金は月末にざっくり確認するくらいしかやってませんでした。

ある日、何気なく利用料金を確認してみると、なぜか普段よりも $200 くらい高い…。
これはと思いもろもろ確認してみると…

∑(゚Д゚)ガーン

検証用に立てた RDS インスタンスが上げっぱなしだった…しかも2台。。

今まで結構お金を気にして運用していたため、$200 とはいえガックリ…。

そこで、そういえばこんな↓記事を以前見たことを思い出し、

  【AWS発表】 AWSクラウドの利用料金を監視・通知できるように from Amazon Web Services ブログ

このあたり↓のブログを参考にさせて頂き、zabbix に利用料金を登録してみました。

  AWS SDK for Rubyを使ってAWSの課金額を取得する from cohakim's blog

  CloudWatch API + ZabbixでAWS課金情報をグラフ化 from Tech-Sketch

  Zabbix Senderで複数の値を一括登録 from ike-daiの日記


課金状況を CloudWatch から取得できるようにする

まず初めに、課金情報を CloudWatch から取得可能にするには、一つ事務的なステップを踏む必要があります。

AWS Account Activity にアクセスします。

既に自分は設定してしまっているので画像が異なるのですが、
この↓赤枠のあたりをクリックして遷移していくと、15分程度経つとCloudWatchから
確認出来るようになります。




スクリプト作成

AWS SDK for Ruby を使いました。
Zabbix に登録する部分は自分で書く自信が無かったので、zabbix_senderコマンドを使っています。
その形式に合わせるために、文字列をガチャガチャしていますが…。

ちなみに start time を4時間前にしているのは、これは1時間とかだと取得に
失敗するパターンがあり、ある程度安定して取れたのが4時間だった、というのが理由です。

これを実行すると、下記のような形で AWS Billing の値をまるっと取ってきます。

hoge-server AmazonEC2 1369563780 497.7
 hoge-server AmazonRoute53 1369563780 0.54
 hoge-server AmazonRDS 1369563780 132.89
 hoge-server AWSDataTransfer 1369563780 4.43
 hoge-server AmazonSNS 1369563780 0.0
 hoge-server AmazonS3 1369563780 1.45
 hoge-server USD 1369563780 637.0

ただし、これだけでは、zabbix にデータは登録されません。 先に zabbix 側でアイテムを作っておく必要があります。


Zabbixアイテム(トラッパー)作成

これは、それぞれ下記のように普通に登録します。




cronに登録

これで、データを蓄積する準備は出来たので、とりあえずcronに登録して定期実行します。

# send aws-billing-data to zabbix
0 * * * * cd /etc/zabbix/externalscripts; /usr/local/bin/ruby /etc/zabbix/externalscripts/get_aws_billing.rb

↑変な書き方をしているのですが、普通に登録しただけではどうも動かなくて、
この書き方であれば動いたので、そのままにしています。


グラフで確認

データが取れたら可視化、ということで下記のようにサービス毎に積み上げグラフにしてみました。


これだけだと全体金額が若干分かりづらいので、そちらは折れ線で。




おーやはりグラフになるといいですね。
グラフ自体は直近二週間ならCloudwatchでも見れますが、もっと蓄積したい場合はこの方法は良さそうです。

ただ、このきっかけとなったインスタンスの上げっぱなしを防止するにはこれだけだと
ちょっとイマイチ…毎日確認する必要があります。

日々のだいたいの増加量を算出して、それ以上の増加量を検知したらアラート、
とかすれば良さそうですが、それはまた別で…


おしまい。

2013年4月24日水曜日

s3cmdで、[Errno 32] Broken pipe と出た時の対処


s3cmd を使って、Jenkinsのジョブをs3に週次でバックアップしてるのですが、 ある時から、

$ s3cmd -f put /tmp/jenkins_bk.tar.gz s3://hogehoge/
/tmp/jenkins_bk.tar.gz -> s3://hogehoge/jenkins_bk.tar.gz  [1 of 1]
    7725056 of 5660650889     0% in    1s     7.02 MB/s  failed
WARNING: Upload failed: /jenkins_bk.tar.gz ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=0.00)
WARNING: Waiting 3 sec...

とか出て、アップロード出来なくなりました。その際の対処法のメモです。


S3のアップロードファイルサイズ制限が原因

色々調べてみたところ、どうもS3にはアップロードファイルサイズ制限(5GB)があるとのこと。
(公式のソースはちょっと見つけられませんでしたが…。)
確認すると、確かにバックアップファイルの容量が、5GB を超えてました。

$ ls -l
-rw-rw-r-- 1 jenkins jenkins 5660650889  4月 23 09:40 jenkins_bk.tar.gz

5GB超えのファイルをどうやってS3にアップロードするには

じゃあどうすればいいのってことになるのですが、かなり前の記事に記載がありました。

【AWS発表】 Amazon S3において大容量ファイルを分割アップロード可能にするマルチパートアップロード機能(Multipart Upload)の発表

ということらしいです。
小さいファイルに分割すればいいよ、と。


Multipart Upload を s3cmd で使う

それなら Multipart Upload オプションみたいなのを s3cmd で使用すればいいのか、
となるのですが、どうもパッケージでリリースされているものはそれに未対応とのこと。

ですが、beta版で対応しているらしいので、そちらを入れます。
公式ページにアクセスして、Download here をクリック。
α版のダウンロードページに行きますが、ちょっと不安なので Parent folder をクリックして、
1.1.0-beta2 をダウンロード

4/25訂正・追記: 1.1.0-beta3 で、Jenkinsからs3cmdを実行すると、
Problem: KeyError: 'elapsed'
S3cmd:   1.1.0-beta3
とかなって、この問題に当たるので、1.5.0-alpha3 を使用しました。

あとは下記のようにインストール。

~$ tar zxvf s3cmd-1.1.0-beta3.tar.gz

~$ cd s3cmd-1.1.0-beta3/
~/s3cmd-1.1.0-beta3$ ls -l
合計 144
-rw-r--r-- 1 hoge hoge  2707  8月  2  2011 INSTALL
-rw-r--r-- 1 hoge hoge  7651  1月 12  2012 NEWS
-rw-r--r-- 1 hoge hoge   661  1月 12  2012 PKG-INFO
-rw-r--r-- 1 hoge hoge 13130  8月  2  2011 README
drwxr-xr-x 2 hoge hoge  4096  1月 12  2012 S3
-rwxr-xr-x 1 hoge hoge 83178  1月 12  2012 s3cmd
-rw-r--r-- 1 hoge hoge 13655  1月 12  2012 s3cmd.1
-rw-r--r-- 1 hoge hoge    28  8月  2  2011 setup.cfg
-rw-r--r-- 1 hoge hoge  2399  1月  2  2012 setup.py

~/s3cmd-1.1.0-beta3$ sudo python setup.py install

~/s3cmd-1.1.0-beta3$ s3cmd --version
s3cmd version 1.1.0-beta3

で、設定ファイル作成。

~$ s3cmd --configure

Enter new values or accept defaults in brackets with Enter.
Refer to user manual for detailed description of all options.

Access key and Secret key are your identifiers for Amazon S3
Access Key: YOUR_ACCESS_KEY
Secret Key: YOUR_SECRET_KEY

Encryption password is used to protect your files from reading
by unauthorized persons while in transfer to S3
Encryption password: YOUR_PASSWORD
Path to GPG program [/usr/bin/gpg]:

When using secure HTTPS protocol all communication with Amazon S3
servers is protected from 3rd party eavesdropping. This method is
slower than plain HTTP and can't be used if you're behind a proxy
Use HTTPS protocol [No]: Yes

New settings:
  Access Key: YOUR_ACCESS_KEY
  Secret Key: YOUR_SECRET_KEY
  Encryption password: YOUR_PASSWORD
  Path to GPG program: /usr/bin/gpg
  Use HTTPS protocol: True
  HTTP Proxy server name:
  HTTP Proxy server port: 0

Test access with supplied credentials? [Y/n] n

Save settings? [y/N] y
Configuration saved to '/var/lib/jenkins/.s3cfg'

出来たファイルはこちら

~/.s3cfg

[default]
access_key = YOUR_ACCESS_KEY
bucket_location = US
cloudfront_host = cloudfront.amazonaws.com
default_mime_type = binary/octet-stream
delete_removed = False
dry_run = False
enable_multipart = True
encoding = UTF-8
encrypt = False
follow_symlinks = False
force = False
get_continue = False
gpg_command = /usr/bin/gpg
gpg_decrypt = %(gpg_command)s -d --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_encrypt = %(gpg_command)s -c --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_passphrase = YOUR_PASSPHRASE
guess_mime_type = True
host_base = s3.amazonaws.com
host_bucket = %(bucket)s.s3.amazonaws.com
human_readable_sizes = False
invalidate_on_cf = False
list_md5 = False
log_target_prefix =
mime_type =
multipart_chunk_size_mb = 1024
preserve_attrs = True
progress_meter = True
proxy_host =
proxy_port = 0
recursive = False
recv_chunk = 4096
reduced_redundancy = False
secret_key = YOUR_SECRET_KEY
send_chunk = 4096
simpledb_host = sdb.amazonaws.com
skip_existing = False
socket_timeout = 300
urlencoding_mode = normal
use_https = True
verbosity = WARNING
website_endpoint = http://%(bucket)s.s3-website-%(location)s.amazonaws.com/
website_error =
website_index = index.html

enable_multipart = True の項目を確認しました。

これでOKなのですが、デフォルトだと、

multipart_chunk_size_mb = 15

となっていて、15MBずつファイルをアップロードすることになるので、
ケチケチせず 1024 とかに変えておきます。


ようやくアップロード

これでようやく当初アップロードしたかったファイルをアップロード出来ます。
よーし…

~$ s3cmd -f put /tmp/jenkins_bk.tar.gz s3://hogehoge/
WARNING: Module python-magic is not available. Guessing MIME types based on file extensions.
/tmp/jenkins_bk.tar.gz -> s3://hogehoge/jenkins_bk.tar.gz  [part 1 of 6, 1024MB]
 1073741824 of 1073741824   100% in  116s     8.78 MB/s  done
/tmp/jenkins_bk.tar.gz -> s3://hogehoge/jenkins_bk.tar.gz  [part 2 of 6, 1024MB]
 1073741824 of 1073741824   100% in  133s     7.67 MB/s  done
/tmp/jenkins_bk.tar.gz -> s3://hogehoge/jenkins_bk.tar.gz  [part 3 of 6, 1024MB]
 1073741824 of 1073741824   100% in  240s     4.26 MB/s  done
/tmp/jenkins_bk.tar.gz -> s3://hogehoge/jenkins_bk.tar.gz  [part 4 of 6, 1024MB]
 1073741824 of 1073741824   100% in  123s     8.29 MB/s  done
/tmp/jenkins_bk.tar.gz -> s3://hogehoge/jenkins_bk.tar.gz  [part 5 of 6, 1024MB]
 1073741824 of 1073741824   100% in  239s     4.28 MB/s  done
/tmp/jenkins_bk.tar.gz -> s3://hogehoge/jenkins_bk.tar.gz  [part 6 of 6, 316MB]
 331925477 of 331925477   100% in   38s     8.18 MB/s  done

おー出来ました。良かった良かった。


おしまい。

2013年2月28日木曜日

Railsのassetsをs3に格納し、cloudfrontから配信する


今まで使おう使おうと思いつつ、さほどPVがあるサイトの運営をする機会がなかったため、
やってなかったcloudfrontを満を持して設定してみました。
(とりあえず入れとけ的な話もよく聞きますし…)

今回は、railsのassetsをS3に置いて、cloudfrontから配信するようにしました。
結果、噂通りすごく簡単に導入できたのですが、調査に割りと時間がかかったのでメモしておきます。

Herokuのドキュメントを取っ掛かりにしました。



概要は以下です。

  • assets格納用のS3バケットを作る
  • cloudfrontのdistributionを作成し、S3をorigin serverに設定
  • railsプロジェクトに設定追加
    • Gemfileに、gem "asset_sync" を追加
    • config/initializersに、asset_sync.rb を作成 (カスタム設定の場合)
    • config/environments/production.rbに、asset_host を設定
  • assets:precompile を実施

これだけ、すごく簡単でした。




まずは、S3のバケット作成。 これはcloudfrontを使う方には、特に説明不要と思うので省略。




次に、cloudfrontのdistribution設定。 こちらも、 公式ドキュメントを見ればOKかと思います




で、メインのrailsの設定です。

・Gemfileに、gem "asset_sync"を追加
これはそのままです。bundle install すればOK。


・config/initializersに、asset_sync.rb を作成。
https://github.com/rumblelabs/asset_sync のReadmeを参考に設定。(ymlで設定する例の記載もあります)

まずはrailsコマンドで設定ファイルのテンプレートを作成。
環境変数を使用することで作らなくても使用出来るようですが、個人的に設定ファイルが
あったほうが安心するタイプなので、今回は作りました。

$ rails g asset_sync:install --provider=AWS

下記のような形で自分好みに設定。


・config/environments/production.rbに、asset_host を設定
以下の通り。

  # Enable serving of images, stylesheets, and JavaScripts from an asset server   
  config.action_controller.asset_host = "//YOUR_CLOUDFRONT_ENDPOINT" 

'//' から始まっているのが変な感じがしますが、こうしておくとアクセスされたプロトコル
(HTTPなら http://YOUR_CLOUDFRONT_ENDPOINT、 HTTPSなら https://YOUR_CLOUDFRONT_ENDPOINT)
でcloudfrontにもリクエストするとのこと。




asset_syncの準備が出来たので、
bundle exec rake assets:precompile RAILS_ENV=production とかやると…

AssetSync: using config/initializers/asset_sync.rb
AssetSync: Syncing.

Uploading: assets/application-55f294e47fb7ed0b383b882262f9820d.js.gz

Uploading: assets/application-55f294e47fb7ed0b383b882262f9820d.js
AssetSync: Done.

という感じでS3にアップロードされるので、あとはCloudfrontがよしなにキャッシュしてくれます。




最後に、Rails を起動してアクセスすれば、cloudfrontからassetsを取得してることが分かると思います。




以上です。 思ってたよりもすごく簡単に出来ました。

キャッシュというとexpireをどうするか的な問題がもれなくついてくると思いますが、
railsはデフォルトで、ファイル名にハッシュをつけてくれるので問題ないようです。

ハッシュ値自体もファイルの中身から算出するとのことなので、stagingとかproductionとか
いくつか環境があっても共有できます。嬉しい。

また、assets_sync自体も既にS3にあるファイルはアップロードしないので、
余計な時間がかかることもありません。嬉しい。

AWS と rails という巨人と、その他素晴らしい先人達の肩にしがみつくと、自分もなんとか生きていける気がしました。


おしまい。

↓参考になります。

AWS SES の送信テスト用スクリプト


久々にSESの設定をしたので、ちゃんと出来たかメール送信テストをしてみようと思った時に、以前作ったスクリプトが出て来ました。


…それだけですm(__)m

おしまい。

CDPの実装ガイド買いました。自己学習はもちろん、誰かにAWSの操作方法から説明する時にもいいかもです。

2013年2月27日水曜日

ELB配下のインスタンス全てにcapistranoでデプロイする

最近はもっぱらAWSでのサーバ運用ばかりしています。

で、AWS EC2を使ってる際にどうしようかなぁと思うことの一つに、IPが固定されない、
ということがあると思います。

EIPなりVPCなり使えばIPの固定自体は出来ますが、いちいち固定IP付けるの面倒だし…という時とか。

今回はアプリケーションをデプロイする時にそれを感じました。

capistranoを用いたデプロイ時にデプロイ先のサーバのアドレスを指定しますが、
ELBにぶら下がるインスタンスに固定IP付けてないんだよなぁ、というケースです。

そこで aws-sdk for ruby を使って、ELB配下のインスタンスを取得するように設定してみました。

今回はVPC内のインスタンスを対象にしてたので、通常のEC2インスタンスであれば、 instance.private_ip_address を instance.dns_name にすればいいと思います。

実行結果は以下です。

$ bundle exec cap test_web
    triggering start callbacks for `test_web'
  * 2013-02-27 08:46:42 08:46:42 == Currently executing `test_web'
  * executing "echo 'Hi!'"
    servers: ["10.0.102.11", "10.0.101.11"]
    [10.0.102.11] executing command
 ** [out :: 10.0.102.11] Hi!
    [10.0.101.11] executing command
 ** [out :: 10.0.101.11] Hi!
    command finished in 4000ms


$ bundle exec cap test_app
    triggering start callbacks for `test_app'
  * 2013-02-27 08:46:56 08:46:56 == Currently executing `test_app'
  * executing "echo 'Hi!'"
    servers: ["10.0.102.11", "10.0.101.11"]
    [10.0.101.11] executing command
 ** [out :: 10.0.101.11] Hi!
    [10.0.102.11] executing command
 ** [out :: 10.0.102.11] Hi!
    command finished in 945ms


$ bundle exec cap test_db
    triggering start callbacks for `test_db'
  * 2013-02-27 08:47:04 08:47:04 == Currently executing `test_db'
  * executing "echo 'Hi!'"
    servers: ["10.0.102.11"]
    [10.0.102.11] executing command
 ** [out :: 10.0.102.11] Hi!
    command finished in 1019ms

おぉ、出来た。ちゃんとdb roleの時は1つのインスタンス宛になってます。

もっと色々活用するためにruby勉強せねば…。


おしまい。

まだ途中までしか読んでないですが、この本結構分かりやすいです。オライリーならPDFもありますし。

2012年3月14日水曜日

zabbixのグラフの日本語文字化け対応

※2013/5/9追記 フォントの指定場所が一箇所漏れていたので追記しましたm(__)m


Amazon Linux に、Zabbix Server を立てた際にグラフの日本語が文字化けしていたので、その時の対処メモ。
多分、Zabbixではお決まりの対処と思われます。

バージョンは下記の通り。

OS     : Amazon Linux AMI release 2011.09 x86/64
Zabbix : 1.8.10

以下がその文字化け(正確には日本語が豆腐になる)への対処法。

2011年9月17日土曜日

AWS : IAM でのサーバ証明書の登録方法


今回も boto のお話。

テーマは、「AWSで使用するサーバ証明書を登録してみよう」


ん?サーバ証明書??普通にやればいいんじゃないの??

って初めは思ったんですが、ELBを使ってSSL通信をしようとすると普通に必要になりました。

2011年9月16日金曜日

AWS : boto を用いた ELB の操作メモ


ちょっと久々に、boto のお話。

今回は、AWSELB をいじってみる。

◆Endpoint に接続

>>> import boto.ec2.elb
>>>
>>> conn=boto.ec2.elb.connect_to_region('ap-northeast-1') #コネクション取得
>>>
>>> conn.get_all_load_balancers() #既存のELBを確認(まだ何も無い)
[]

◆ロードバランサ作成


2011年9月6日火曜日

AWS : boto を用いたRDSの操作メモ

過去に何回かポストしてる AWS の python API である boto の話。

今回は、RDSを軽くいじってみる。ホントにかる~く。
引数が、キーワード引数とそうじゃないのと混じってるけど、まぁご愛嬌ってことで。。

◆Endpointに接続
>>> import boto.rds
>>> tokyo_rds = boto.rds.connect_to_region('ap-northeast-1')

◆起動
>>> rds_instance = tokyo_rds.create_dbinstance(
id = 'bototest',
allocated_storage='10',
instance_class='db.m1.small',
master_username='root',
master_password='xxxx',
security_groups=['testgroup'],
param_group='utf8')

◆スナップショット取得
>>> new_dbsnap = tokyo_rds.create_dbsnapshot('testsnap', 'bototest')

◆停止
>>> tokyo_rds.delete_dbinstance(
rds_instance.id,
skip_final_snapshot = False,
final_snapshot_id = 'testsnap2')

◆スナップショットからのリストア
>>> tokyo_rds.restore_dbinstance_from_dbsnapshot(
'testsnap2',
'restored_instance',
'db.m1.small')

◆スナップショット削除
>>> tokyo_rds.delete_dbsnapshot('testsnap')


こんなところ、軽すぎるか。。
まぁソースを確認したほうが、コメントもついてるから確実かつ分かりやすいですね。

https://github.com/boto/boto/blob/master/boto/rds/__init__.py

個人的にはAWS自体がEC2とRDSで表現が違ったりする(instance type と instance class とか、 name と id とか)のがちょっと始め混乱するけど、大した問題じゃあないか。


おしまい。

2011年8月23日火曜日

AWS : boto を用いた EC2 の操作メモ

AWS の python API である、boto の話。
あまり日本語情報が充実していないのでメモメモ~。

◆EC2の東京リージョンにつなげる
>>> import boto.ec2
>>>
>>> tokyo = boto.ec2.connect_to_region('ap-northeast-1')
>>>
>>> tokyo
EC2Connection:ec2.ap-northeast-1.amazonaws.com


◆EC2インスタンスを起動する
>>> reservation = tokyo_ec2.run_instances(image_id='ami-300ca731', key_name='testkey', instance_type='t1.micro', security_groups=['testgroup'])

※インスタンスを起動すると、Reservationというオブジェクトが返ってくる。これは同時に起動されたインスタンスのコレクション。
クラス変数として、

self.id
self.owner_id
self.groups
self.instances


を持つ。
つまり、インスタンスを確認するには、

>>> reservation.instances
[Instance:i-8899ef89]

とする。


◆tagをつけるには、、、

reservation.instances[0].add_tag(key='test',value='testvalue')

とかってする。


◆tagをキーにしてインスタンスを取得するには、、、

tagのkeyで取得する。

>>> tokyo.get_all_instances(filters={'tag-key':'test'})[0].instances
[Instance:i-aa0f71ab]

tagのvalueで取得する。

>>> tokyo.get_all_instances(filters={'tag-value':'testvalue'})[0].instances
[Instance:i-aa0f71ab]

keyとvalueの組み合わせで取得する。これが一番使うのかな~

>>> tokyo.get_all_instances(filters={'tag-key':'test', 'tag-value':'testvalue'})[0].instances
[Instance:i-aa0f71ab]

とかってすればいいんだけど、これだと "key:value" の組み合わせが1つしか指定できないので、

>>> tokyo.get_all_instances(filters={'tag:test': 'testvalue'})[0].instances

とすれば、複数の指定が出来る。


◆パブリックDNSを取得する
起動した直後は、情報がそろっていないため、microインスタンスなら1分程度待機し、

>>> reservation.instances[0].update()
u'running'

として更新する。

その後、

>>> reservation.instances[0].public_dns_name
u'ec2-46-51-226-124.ap-northeast-1.compute.amazonaws.com'

とすることでパブリックDNSを取得できる。

プライベートDNSは、

>>> reservation.instances[0].private_dns_name
u'ip-10-146-70-41.ap-northeast-1.compute.internal'

とする。

ひとまず簡単なところではこんな感じ。


◆一応最後に、起動したインスタンスを終了しておく

状態を確認
>>> reservation.instances[0].state
u'running'

インスタンスIDを確認
>>> reservation.instances[0]
Instance:i-8899ef89

インスタンスを削除
>>> reservation.instances[0].terminate()

落ちて行くのを確認
>>> reservation.instances[0].state
u'running'

>>> reservation.instances[0].update()
u'shutting-down'

>>> reservation.instances[0].state
u'shutting-down'

>>> reservation.instances[0].update()
u'terminated'


こんな感じで、、、

おしまい。

2011年8月22日月曜日

AWS : Auto Scaling お試しメモ

AWS本に従って Auto Scaling を試した時のメモ。
結構前にやったやつなので、自分へのリマインド的な感じ。

なんとなくのシナリオとしては下記の通り。

0.OS起動時にApacheが起動するAMIを用意しておく(別にApacheである必要はない)
1.ロードバランサを1つ作成
2.スケーリングする条件を設定
3.スケールアウトを試す
4.スケールインを試す
5.もろもろ設定削除して終了

といったところ。

では早速試してみる。ただエビデンスを貼っただけですが、、、
今回はbotoではなく、JavaのコマンドラインAPIを使用してます。


◆ロードバランサを作成

>>> elb-create-lb LoadBal
--listener "lb-port=80, instance-port=80, protocol=HTTP"
--availability-zones ap-northeast-1a
--region ap-northeast-1

DNS_NAME LoadBal-476601279.ap-northeast-1.elb.amazonaws.com

訳)
東京リージョンの、aゾーンに、LoadBalというロードバランサを作成。
リクエストをロードバランサの80番ポートで受け付け、バックエンドの80番ポートにHTTPプロトコルで流す。


◆Auto Scaling グループの起動コンフィグレーションを作成する。

>>> as-create-launch-config Configtest
--image-id ami-2c65cf2d
--instance-type t1.micro
--region ap-northeast-1

OK-Created launch config

訳)
東京リージョンの、指定AMI(ami-2c65cf2d)が、t1.microインスタンスで起動する、Configtestという名前の起動設定を作成する。
※指定するAMIはApacheが起動し、デフォルトページを返すようにしてある。


◆Auto Scaling グループを作成する。

>>> as-create-auto-scaling-group AutoScale
--launch-configuration Configtest
--availability-zones ap-northeast-1a
--min-size 1
--max-size 5
--load-balancers LoadBal
--region ap-northeast-1

OK-Created AutoScalingGroup

訳)
Configtest 起動コンフィグレーションを参照し、
ap-northeast-1a AZで
最小1つ、最大5つのLoadBalインスタンスを作成する、
AutoScaleという名前のauto-scaling-groupを作成する。


◆スケーリングするためのトリガを作成する。

>>> as-create-or-update-trigger Trigger1
--auto-scaling-group AutoScale
--namespace "AWS/EC2"
--measure CPUUtilization
--statistic Average
--dimensions "AutoScalingGroupName=AutoScale"
--units "Percent"
--period 60
--lower-threshold 30
--upper-threshold 70
--lower-breach-increment"=-1"
--upper-breach-increment "1"
--breach-duration 120
--region ap-northeast-1

DEPRECATED: This command is deprecated and included only to facilitate migration to the new trigger
mechanism. You should use this command for migration purposes only.
OK-Created/Updated trigger

訳)
このトリガはEC2のCPUUtilization メトリックにより制御される。
AutoScaleグループ内のEC2インスタンスの平均CPU使用率が2分間隔で70%を超えたら、スケールアウトを行う。
同じく、2分間隔で平均CPU使用率が30%を下回ったら、スケールインを行う。
スケールイン・スケールアウトともにインスタンスを1つずつ加減する。


◆何が起きているか確認する
下記は、オートスケール有効後にCPUに負荷をかけて、1つスケールアウトした後の出力。

>>> as-describe-scaling-activities --auto-scaling-group AutoScale --show-long --region ap-northeast-1

ACTIVITY,05d12fe9-355c-434a-a03e-e328413dbf21,2011-05-25T11:00:59Z,AutoScale,Successful,(nil),"At 20
11-05-25T10:59:47Z a breaching trigger explicitly set group desired capacity changing the desired ca
pacity from 1 to 2. At 2011-05-25T10:59:47Z trigger Trigger1 breached high threshold value for CPUU
tilization, 70.0, adjusting the desired capacity from 1 to 2. At 2011-05-25T11:00:12Z an instance w
as started in response to a difference between desired and actual capacity, increasing the capacity
from 1 to 2.",100,Launching a new EC2 instance: i-06167b07,(nil),2011-05-25T11:00:12.868Z
ACTIVITY,f4f00f27-7cb4-497f-9cda-fea15bb64bd1,2011-05-25T10:29:15Z,AutoScale,Successful,(nil),"At 20
11-05-25T10:28:24Z a user request created an AutoScalingGroup changing the desired capacity from 0 t
o 1. At 2011-05-25T10:28:29Z an instance was started in response to a difference between desired an
d actual capacity, increasing the capacity from 0 to 1.",100,Launching a new EC2 instance: i-821a7783,(nil),2011-05-25T10:28:29.681Z


0から1に増えて(最初の起動)、1から2にスケールアウトした感じの出力がされている。
上の方が新しいログの模様。


◆ホスト側の動き

vmstat で CPU使用率を監視していたら、スケールする際に再起動がされるもよう。

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 476488 6924 75980 0 0 0 0 9 12 0 0 100 0 0
0 0 0 476488 6924 75980 0 0 0 0 9 15 0 0 100 0 0
0 0 0 476488 6924 75980 0 0 0 0 8 10 0 0 100 0 0
0 0 0 476488 6924 75980 0 0 0 0 7 11 0 0 100 0 0
0 0 0 476488 6924 75980 0 0 0 0 8 9 0 0 100 0 0
0 0 0 476488 6924 75980 0 0 0 0 9 12 0 0 100 0 0
0 0 0 476488 6924 75980 0 0 0 0 7 11 0 0 100 0 0
0 0 0 476488 6924 75980 0 0 0 0 13 13 0 0 100 0 0

Broadcast message from root@ip-10-146-27-140
(unknown) at 11:08 ...

The system is going down for power off NOW!
Connection to ec2-46-51-225-202.ap-northeast-1.compute.amazonaws.com closed by remote host.
Connection to ec2-46-51-225-202.ap-northeast-1.compute.amazonaws.com closed.


◆スケールインを確認
負荷をかけるスクリプトが止まって一定時間たったため、スケールインが発生しているはず。

>>> as-describe-scaling-activities --auto-scaling-group AutoScale --show-long --region ap-northeast-1

ACTIVITY,586ec3c6-ca82-4fbf-8d14-cb3e150a9a72,2011-05-25T11:08:47Z,AutoScale,Successful,(nil),"At 20
11-05-25T11:06:44Z a breaching trigger explicitly set group desired capacity changing the desired ca
pacity from 2 to 1. At 2011-05-25T11:06:44Z trigger Trigger1 breached low threshold value for CPUUt
ilization, 30.0, adjusting the desired capacity from 2 to 1. At 2011-05-25T11:07:06Z an instance wa
s taken out of service in response to a difference between desired and actual capacity, shrinking th
e capacity from 2 to 1. At 2011-05-25T11:07:06Z instance i-821a7783 was selected for termination.",
100,Terminating EC2 instance i-821a7783,(nil),2011-05-25T11:07:06.148Z
ACTIVITY,05d12fe9-355c-434a-a03e-e328413dbf21,2011-05-25T11:00:59Z,AutoScale,Successful,(nil),"At 20
11-05-25T10:59:47Z a breaching trigger explicitly set group desired capacity changing the desired ca
pacity from 1 to 2. At 2011-05-25T10:59:47Z trigger Trigger1 breached high threshold value for CPUU
tilization, 70.0, adjusting the desired capacity from 1 to 2. At 2011-05-25T11:00:12Z an instance w
as started in response to a difference between desired and actual capacity, increasing the capacity
from 1 to 2.",100,Launching a new EC2 instance: i-06167b07,(nil),2011-05-25T11:00:12.868Z
ACTIVITY,f4f00f27-7cb4-497f-9cda-fea15bb64bd1,2011-05-25T10:29:15Z,AutoScale,Successful,(nil),"At 20
11-05-25T10:28:24Z a user request created an AutoScalingGroup changing the desired capacity from 0 t
o 1. At 2011-05-25T10:28:29Z an instance was started in response to a difference between desired an
d actual capacity, increasing the capacity from 0 to 1.",100,Launching a new EC2 instance: i-821a778
3,(nil),2011-05-25T10:28:29.681Z


とりあえずの動作確認は終了。


◆グループを終了させる。まずはトリガを削除

>>> as-delete-trigger Trigger1 --auto-scaling-group AutoScale --region ap-northeast-1

DEPRECATED: This command is deprecated and included only to facilitate migration to the new trigger
mechanism. You should use this command for migration purposes only.

Are you sure you want to delete this trigger? [Ny]y
OK-Deleted trigger


◆グループの最小サイズと最大サイズを0に設定し、全インスタンスを強制終了する。

>>> as-update-auto-scaling-group AutoScale --min-size 0 --max-size 0 --region ap-northeast-1

OK-Updated AutoScalingGroup


◆終了したか確認してみる。

>>> as-describe-scaling-activities --auto-scaling-group AutoScale --show-long --region ap-northeast-1

ACTIVITY,971a1a47-53d6-4e1d-a9e7-c5cf2a1d36ab,(nil),AutoScale,InProgress,(nil),"At 2011-05-25T11:15:
29Z a user request update of AutoScalingGroup constraints to min: 0, max: 0, desired: 0 changing the
desired capacity from 1 to 0. At 2011-05-25T11:15:37Z an instance was taken out of service in resp
onse to a difference between desired and actual capacity, shrinking the capacity from 1 to 0. At 20
11-05-25T11:15:37Z instance i-06167b07 was selected for termination.",0,Terminating EC2 instance i-0
6167b07,(nil),2011-05-25T11:15:37.271Z
ACTIVITY,586ec3c6-ca82-4fbf-8d14-cb3e150a9a72,2011-05-25T11:08:47Z,AutoScale,Successful,(nil),"At 20
11-05-25T11:06:44Z a breaching trigger explicitly set group desired capacity changing the desired ca
pacity from 2 to 1. At 2011-05-25T11:06:44Z trigger Trigger1 breached low threshold value for CPUUt
ilization, 30.0, adjusting the desired capacity from 2 to 1. At 2011-05-25T11:07:06Z an instance wa
s taken out of service in response to a difference between desired and actual capacity, shrinking th
e capacity from 2 to 1. At 2011-05-25T11:07:06Z instance i-821a7783 was selected for termination.",
100,Terminating EC2 instance i-821a7783,(nil),2011-05-25T11:07:06.148Z
ACTIVITY,05d12fe9-355c-434a-a03e-e328413dbf21,2011-05-25T11:00:59Z,AutoScale,Successful,(nil),"At 20
11-05-25T10:59:47Z a breaching trigger explicitly set group desired capacity changing the desired ca
pacity from 1 to 2. At 2011-05-25T10:59:47Z trigger Trigger1 breached high threshold value for CPUU
tilization, 70.0, adjusting the desired capacity from 1 to 2. At 2011-05-25T11:00:12Z an instance w
as started in response to a difference between desired and actual capacity, increasing the capacity
from 1 to 2.",100,Launching a new EC2 instance: i-06167b07,(nil),2011-05-25T11:00:12.868Z
ACTIVITY,f4f00f27-7cb4-497f-9cda-fea15bb64bd1,2011-05-25T10:29:15Z,AutoScale,Successful,(nil),"At 20
11-05-25T10:28:24Z a user request created an AutoScalingGroup changing the desired capacity from 0 t
o 1. At 2011-05-25T10:28:29Z an instance was started in response to a difference between desired an
d actual capacity, increasing the capacity from 0 to 1.",100,Launching a new EC2 instance: i-821a778
3,(nil),2011-05-25T10:28:29.681Z


0になった!


◆インスタンスが全て消えたので、グループを削除

>>> as-delete-auto-scaling-group AutoScale --region ap-northeast-1

Are you sure you want to delete this AutoScalingGroup? [Ny]y
OK-Deleted AutoScalingGroup


◆起動コンフィグレーションも削除しとく

>>> as-delete-launch-config Configtest --region ap-northeast-1

Are you sure you want to delete this launch configuration? [Ny]y
OK-Deleted launch configuration


◆最後にロードバランサを削除する

>>> elb-delete-lb LoadBal --region ap-northeast-1

Warning: Deleting a LoadBalancer can lead to service disruption to any
customers connected to the LoadBalancer. Are you sure you want to delete
this LoadBalancer? [Ny]y
OK-Deleting LoadBalancer


ホントにメモですみません。。m(__)m

おしまい。

---
下記の本を参考に行いました。
全体概要を把握するのにとっつきやすかったです。


2011年8月18日木曜日

s3fs : Amazon linux への導入

最近いじってるAWSのお話。

今回とりあげるのは、s3fs。
何かというと、AWSのストレージサービスであるS3のバケットをマウントして、ファイルシステムと同様に使うためのライブラリです。

もう結構前からあるのでご存知の方も少なくないかと思いますが、、、

それを導入した際に少し手間取ったので、手順をメモとして残しておきます。

まず環境は、下記の通り。

OS:Basic 32-bit Amazon Linux AMI AWSがAMIとして提供している例のあれです。

s3fs : s3fs-1.40  2011/08/17現在、1.59が最新ですがDevelopment版なので、念のためStableの方を使います。

以下、つらつらと。

◆ s3fs 導入前準備

 まずは必要なパッケージをインストール。wikiに書いている通り、足りないパッケージをインストールします。

# yum install gcc
# yum install libstdc++-devel
# yum install gcc-c++
# yum install curl-devel
# yum install libxml2.-devel
# yum install openssl-devel
# yum install mailcap
# yum install make

 ◎注意:
 fuse に関しては、yumでインストールせず、ソースからコンパイルする。
 デフォルト状態では、リポジトリのfuseのバージョンが、2.8.4 までしかなく、要件を満たせない。
 ということで、ソースダウンロード~コンパイル。

# wget http://sourceforge.net/projects/fuse/files/fuse-2.X/2.8.5/fuse-2.8.5.tar.gz/download
# ls -l
# tar zxvf fuse-2.8.5.tar.gz
# cd fuse-2.8.5
# pwd
# ls -l
# ./configure prefix=/usr
# make
# make install

 ここらへんを設定しておかないと、s3fs を configure する際に、fuse のバージョンとかを
 確認出来ないため、エラーになる。
# export PKG_CONFIG_PATH=/usr/lib/pkgconfig/:/usr/lib64/pkgconfig/
# echo $PKG_CONFIG_PATH

 共有ライブラリを探索するパスを再設定
# ldconfig

 動作中のカーネルにモジュールをインストールする。
 詳しくは聞かないでください。。
# modprobe fuse

 これが、普通に通れば問題ない。
# pkg-config --modversion fuse
2.8.5

 と、いうことで、必要なパッケージがそろったので、ここからs3fs自体のインストールを行う。

◆s3fs インストール

 s3fs ソースゲット。ネットから普通に落とします。
# wget http://s3fs.googlecode.com/files/s3fs-1.40.tar.gz
# sha1sum s3fs-1.40.tar.gz
# tar zxvf s3fs-1.40.tar.gz
# cd s3fs-1.40
# ./configure prefix=/usr
# make
# make install

 接続アカウント情報を記載したファイルを作成する。
# echo アクセスキー:シークレットキー > /etc/passwd-s3fs
# chmod 640 /etc/passwd-s3fs

ここまでで、s3fs のインストールは終了。
ここから実際にs3をマウントしてみる。

◆S3をマウント

# mkdir /mnt/s3
# s3js bucket-for-s3fs /mnt/s3 -o allow_other ※オプションを考慮する。権限関係とか。manで確認。

ん、何も出ないってことはうまくいったかな。
df で確認してみると、、、

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.9G 1.7G 6.2G 21% /
tmpfs 299M 40K 299M 1% /dev/shm
s3fs 256T 0 256T 0% /mnt/s3

なんと256T!これは使い放題だ~w
ファイルを作っても、ディレクトリを作っても、色々入ってるディレクトリを丸ごと移動しても、まったりはしてますがきちんと動作します。
そして、S3の方を確認してみると、、、おぉ~ちゃんと出来てる。

レスポンスの体感速度としては、

ls -l を普通に打って、返ってくるまで1秒弱くらい。
やっぱり結構もっさりって感じ。環境にもよるかもしれませんが。
中身がどうなってるのか見てませんが、リクエストが飛んでると想像すると、これくらいなんですかね。

まぁでもそれにつけても、ファイルシステムと同様に使用できる、という利便性が勝つかなぁと個人的には思います。
※ただし、クリティカルなシステムにすぐに使用できるか、という話になると、そんなに色んなパターンを試したわけではないので要検証、ご利用は自己責任で、という感じです、、、。

アンマウントしたい時は、普通に、

# umount /mnt/s3

でオーケー。

また、起動時にマウントするには、

/etc/fstab に、

s3fs#s3fs-test /mnt/s3/ fuse allow_other

を追記しておけば大丈夫です。
fstabの書き方は、cloudpackさんのblog記事を参考にさせて頂きました。ありがとうございます。


最後にひとつ注意。

マウントしている S3 のバケットにs3fsを通さずに直接フォルダを作成すると、s3fs(を用いてs3をマウントしているOS)からは見えません。
なので、s3fs経由で使用したいフォルダ(ディレクトリ)を作成する際には、OS側からディレクトリを作成する必要があります。

と、いうのも、s3fs でマウントしたディレクトリ以下で、ディレクトリの作成を行うと、当然ファイルシステム的にはディレクトリのみが出来るわけですが、AWSのS3を管理コンソールから見てみると、

作成したディレクトリ(S3的にはフォルダ)
作成したディレクトリと同じ名前の 0byte ファイル

が作成されています。
どうもこの 0byte ファイルが無いとs3fs的には認識出来ないようです。
かといって、管理コンソールでフォルダを作って、その後に同名の 0byte ファイルを配置しても、やっぱりOSからは見えませんでした。
おそらくMetadataで何か登録しているのだとは思いますが、そこまでは解析してません。。

ひとまずは、ディレクトリを作る時はOS側から作ろうか、という話でした。


とりあえず、s3fs の導入は以上~。


おしまい。

2011年8月17日水曜日

AWS : boto 各リージョンへの接続

AWS の Python API である、boto について。

まず始めに躓いたところは、指定のリージョンに接続出来ないよ!ってこと。

AWSの公式紹介ページでは、AWSへのコネクションの作成に、

>>> import boto
>>> boto.connect_ec2()

みたいな感じで接続してるんだけど、これだけじゃリージョン指定出来なくて北米とかにつながってしまう。

で、ソースを見ると

RegionInfoっていうクラスに、リージョン名渡して~みたいな感じで出来るのですが、、、

、、、っていうか接続するだけなのに、めんどうだな(-.-;)

って思いました。

それで、よくよくソースを探ってみると、ありました。リージョン指定で接続するメソッドが。

その名も

connect_to_region('リージョン名')

ずばりですね。

ってことで、これで簡単にリージョン指定で接続できます。

下記は、インタラクティブシェルを使って、東京リージョンのEC2で新規インスタンスをあげる例です。

>>> import boto.ec2
>>>
>>> ec2_conn = boto.ec2.connect_to_region('ap-northeast-1')
>>>
>>> ec2_conn
EC2Connection:ec2.ap-northeast-1.amazonaws.com
>>>
>>> rsv = ec2_conn.run_instances('ami-2e0ca72f', instance_type='t1.micro')
>>>
>>> rsv
Reservation:r-845a0e85
>>>
>>> rsv.instances
[Instance:i-44095645]
>>>
>>> instance = rsv.instances[0]
>>>
>>> instance
Instance:i-44095645
>>>
>>> print instance.region
RegionInfo:ap-northeast-1
>>>
>>> print instance.placement
ap-northeast-1a
>>>


3行目で、東京リージョンに接続。
8行目で、インスタンス起動。
21行目で、リージョンを確認。
24行目で、アベイラビリティゾーンを確認。

うん、ちゃんと取れてるみたいです。

同様に、自分が使用して出来たものとして、RDS(※注)・ELBがあります。
他も同様だとは思いますが、ソースを見て確認してみてください。

S3 と IAM は、接続の感じが違うみたいで、それぞれ普通に、

@S3
>>> import boto
>>>
>>> s3_conn = boto.connect_s3()

@IAM
>>> import boto
>>>
>>> iam_conn ~ boto.connect_iam()

と、します。
S3は、なんかリージョンの考え方が違うのかな。
IAMは、そもそもリージョンが無いからそれはそうか。

※RDSは、2011/08/17現在、pypiでの最新バージョンであるboto2.0では、リージョンのエンドポイントが
間違っていて、コネクションは作れるものの、インスタンスの作成等は出来ません。
boto/rds/__init__.py の def regions() に記載されているエンドポイントを自分で書き換えるか、
githubより最新のものをダウンロードする必要があります。
各AWSサービスのエンドポイント一覧は、こちら


おしまい。

2011年8月16日火曜日

AWS : boto API の導入

AWS(Amazon Web Service) の Python API である boto を使用する機会があったので、それについてちょくちょく書いていこうと思います。

まずは導入手順。

これは、基本的にはAWSの公式ページのままなので、別になんてことはないです。

◆pythonのパッケージ管理用のpipをインストール
(pipを入れる前に、easy_installも入れておく。)

# easy_install pip

◆botoライブラリをインストール

# pip install -U boto

これでインストールは完了。

なのですが、botoの開発は今もガンガンされているっぽいので、これだと最新のものが入らなくて困ることがあります。
例えば、2011/8/16現在では、pypiに登録されているboto2.0では、rdsのendpointの値が正しくないため、接続がうまくいきません。

なので、出来ればgithubから最新のソースをダウンロードして、

# python setup.py install 

とした方がいいと思います。
まぁとにかく、これでboto自体のインストールはOKです。

次に、アカウントに接続するためにクレデンシャルファイルというものを作ります。

◆クレデンシャルファイルを作成

・Linuxとかの場合
/etc/boto.cfg or ~/.boto に下記内容を記載

・Windowsの場合
任意の場所に下記内容を記載し、環境変数に
名前:AWS_CREDENTIAL_FILE
値 :作成したファイルのパス
として登録する。
http://code.google.com/p/boto/wiki/BotoConfigによると、BOTO_CONFIG として登録でもいいらしいけど未検証。

作成するファイルの内容
[Credentials]
aws_access_key_id = {ACCESS KEY ID}
aws_secret_access_key = {SECRET ACCESS KEY}
※{}はいらない。

インタラクティブpythonを起動して、

>>> import boto

で、特になにも出なければオッケーです。

おしまい。

ぐぐってもなかなかまとまった情報が手に入らないので、次からもっと色々と書いていく予定。

2011年5月29日日曜日

AWS EC2 : public DNS がかぶった時の対処

新規でAMIからインスタンス起動して、いつものマシン(CentOS)からアクセスしようとしたら
下記のメッセージが出て接続出来なかった。その時のメモ。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
**:**:**:**:**:**:**:**:0e:1a:7f:7f:0a:74:e0:ca.
Please contact your system administrator.
Add correct host key in /home/ec2-user/.ssh/known_hosts to get rid of this message.
Offending key in /home/ec2-user/.ssh/known_hosts:9
RSA host key for ec2-**-**-***-***.ap-northeast-1.compute.amazonaws.com has changed and you have requested strict checking.
Host key verification failed.

どうやら既存の ~/.ssh/knownhosts に登録済みのホストと同名なのに、
違うフィンガープリントだからやばいぞ、っていうことらしい。

ちょっとEC2で検証用にサーバ立てる時は、Elastic IP を振るのは
めんどうだからpublic DNS で接続してたらかぶっちゃったよ、、、
っていうオチらしい。

なので、~/.ssh/knownhosts から、メッセージで指摘されてる行の
ホストを削除したら、無事に接続出来るようになった。


↑[8/24 追記]
こんなことをしなくても、下記のコマンドでいけた。

RSA host key がかぶってますよ、と指摘されたホストをしていして、

# ssh-keygen -R 対象ホスト

で、OK。



最初は、まだ一度も接続してないのになぜ!?って思って動揺して
ちょっとハマってしまった。。

2011年5月26日木曜日

AWS RDS のタイムゾーンについて個人的まとめ

 RDSのタイムゾーンで色々試して、色々つまづいたのでまとめておく。

まず、2011/5/17現在、

RDSではtime_zoneの設定は出来ない。

USTの時刻がデフォルトとなっており、time_zoneは編集不可項目となっている。
参照:https://forums.aws.amazon.com/thread.jspa?threadID=38273 のNick@AWSさんの回答より。

代替案として次を試してみた。

  1. mysqlのコマンドから直接指定する。
  2. init_connectに、set time_zone = 'Asia/Tokyo'; を設定する。
ひとつずつ見ていくと、、、


  1. mysqlのコマンドから直接指定する。

まず、mysqlから GLOBAL time_zone を指定しようとすると、権限で怒られる。

mysql>  SET GLOBAL time_zone = '+9:00';
ERROR 1227 (42000): Access denied; you need the SUPER privilege for this operation

ただし、GLOBALじゃない、セッション毎の設定であればOK。

mysql> set time_zone = '+9:00';
Query OK, 0 rows affected (0.00 sec)

でも、これを毎回叩くのはどうだろう。プログラム側で対応しないといけないし、、、
う〜む。

こちらを参考にさせて頂きました。ありがとうございます。


ということで次。


     2. init_connectに、set time_zone = 'Asia/Tokyo'; を設定する。

これは、、、うまくいかなかった。
こちら↓を参照させて頂いてPHPスクリプトで、parameter group に設定しました。          

が、DBにつながらなくなってしまいました。。
厳密にはDBにはつながるのですが、SQLとか全て受け付けない、、、

mysql> show databases;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    19
Current database: *** NONE ***
ERROR 2013 (HY000): Lost connection to MySQL server during query

これでうまくいく環境もあるようですが、自分のところではダメでした。。
下記で同じ症状になっている方がいるようです。どうもリブートするとダメとか。

で、結論としては、タイムゾーンの設定はとりあえずプログラム側で、という切ない感じで。。

今後解決されることを切に願うばかりです、、、
誰かうまいやり方をされている方がいらっしゃいましたら、教えていただけると嬉しいですm(__)m

こちらに、プログラムでの対応案が書かれています。

AWS SDK for PHP の導入(simple版)

SDKの導入のメモ。
まぁ、Amazonのチュートリアル 通り。


◆SDKを下記サイトからダウンロード
   http://aws.amazon.com/sdkforphp

◆ダウンロードしたzipファイルを解凍
  > unzip sdk-latest.zip

◆回答したディレクトリ内のconfig-sample.inc.phpをコピー。
  > cp -p config-sample.inc.php config.inc.php

◆config.inc.php を下記のように修正。
値はAWSのアカウントページのセキュリティ証明書のページから取得する。
英語表記と日本語訳が微妙に異なってるので若干詰まった。

config.inc.php

/**
* Stores your AWS account information. Add your account information, and then rename this file
* to 'config.inc.php'.
*
* @version 2011.01.20
* @license See the included NOTICE.md file for more information.
* @copyright See the included NOTICE.md file for more information.
* @link http://aws.amazon.com/php/ PHP Developer Center
* @link http://aws.amazon.com/security-credentials AWS Security Credentials
*/
/**
* Amazon Web Services Key. Found in the AWS Security Credentials. You can also pass this value as the first
* parameter to a service constructor.
*/
define('AWS_KEY', '[アクセスキー ID]');
/**
* Amazon Web Services Secret Key. Found in the AWS Security Credentials. You can also pass this value as
* the second parameter to a service constructor.
*/
define('AWS_SECRET_KEY', '[シークレットアクセスキー]');
/**
* Amazon Account ID without dashes. Used for identification with Amazon EC2. Found in the AWS Security
* Credentials.
*/
define('AWS_ACCOUNT_ID', '[AWS アカウント ID]');
/**
* Your CanonicalUser ID. Used for setting access control settings in AmazonS3. Found in the AWS Security
* Credentials.
*/
define('AWS_CANONICAL_ID', '[標準ユーザーID]');
/**
* Your CanonicalUser DisplayName. Used for setting access control settings in AmazonS3. Found in the AWS
* Security Credentials (i.e. "Welcome, AWS_CANONICAL_NAME").
*/
define('AWS_CANONICAL_NAME', '[登録名]'); ※右上の、「ようこそ ~」の部分※以下は使ってないので未記入。
/**
* 12-digit serial number taken from the Gemalto device used for Multi-Factor Authentication. Ignore this
* if you're not using MFA.
*/
define('AWS_MFA_SERIAL', '');
/**
* Amazon CloudFront key-pair to use for signing private URLs. Found in the AWS Security Credentials. This
* can be set programmatically with .
*/
define('AWS_CLOUDFRONT_KEYPAIR_ID', '');
/**
* The contents of the *.pem private key that matches with the CloudFront key-pair ID. Found in the AWS
* Security Credentials. This can be set programmatically with .
*/
define('AWS_CLOUDFRONT_PRIVATE_KEY_PEM', '');
/**
* Set the value to true to enable autoloading for classes not prefixed with "Amazon" or "CF". If enabled,
* load `sdk.class.php` last to avoid clobbering any other autoloaders.
*/
define('AWS_ENABLE_EXTENSIONS', 'false');


これで準備オッケー。

おしまい。