RDSのディスクを後から変更するときに、リブートはどうなる？
今回は、RDSのディスク変更に伴うリブートの確認を行いました。前回のエントリで、mysqlの死活を秒間で確認するスクリプトを用意しているので、そいつを裏で回しておきます。
RDSでParameter Groups変更時のDBリブートについて調査してみた - 続 カッコの付け方
EBSタイプ変更せずに、容量だけUP
SSD GP2 -> GP2 で実験したところ、リブートは発生しませんでした。
でも何やら警告が出てますね。
- コンバージョンに長い時間がかかって、EBSのクレジット使い果たすよ。
- 操作が完了するまで、パフォーマンスに影響があるよ。
EBSのクレジットについては、別エントリで詳細を書く予定。
EBSタイプを SSD(GP2) -> SSD(PIOPS)に変更
今回は容量UPは行わず、 GP2 -> PIOPSへ種別変更だけにしましたが、こちらもリブートは発生しませんでした。
警告メッセージもほぼ同じ。変更後のストレージはgp2で無いから、EBSクレジットは関係無いような気がするけど、元ストレージから引っ張りだす時の話かな？
EBSタイプを SSD(GP2) -> Magneticに変更
GP2(SSD) -> Magnetic(HDD) に変更した場合は、マネジメントコンソールに下記が表記されます。
サービス断が明記されております。Single-AZで数分, Multi-AZで2分ぐらいのサービス断ということです。 死活監視のスクリプトもちゃんと反応しており、観測ではSingle-AZ構成で約5分程度でした。
まとめ
実はちゃんとメッセージに出ているというオチでしたが、まとめると
- gp2 -> gp2 リブート無し
- gp2 -> piops リブート無し
- gp2 -> magnetic リブート有り (サービス断)
ということでした。他のパターン (magnetic -> gp2とか) は今回試してませんが、少なくともディスク変更時には警告もなしにRDSサービス断ということは無いでしょう。
RDSでParameter Groups変更時のDBリブートについて調査してみた
RDSはインスタンスのスペックに応じて、自動でDBパラメータを調整してくれるのが売りでもありますが、どうしても変更したいパラメータがあったりします。有名なところでは
- max_allowed_packet
- character_set_xxx 系
この辺りのパラメータや、もっと重いパラメータ(クエリキャッシュの有効化等) 変更時に、DBリブートはかかるのか、かけなくていいのかを検証します。今回はとりあえずMySQLです。
リブートが掛かっていないかの確認
スクリプトを用意しました。しょうもないスクリプトですが、使ってください。
#!/bin/bash while : do dt=$(date) state=$(timeout 5 mysqladmin ping -u<User> -p<Pass> -h<EndPoint>) echo $dt-$state sleep 1 done
failoverをやった場合に、mysqladmin が接続を掴んで離さず、正確な停止時間が測れなかったので、timeoutを使ってみます。今回はfailover関係ないですが、一応入れたままで使います。 使い方は
$ ./mysqlping.sh > reboot.txt & $ tail -f reboot.txt
とか、tee でもいいですよ。
中身未設定のParameter Groupsを適応した場合
Parameter Groups を作成し、RDS Instance に適応しただけではリブートはかかりませんでした。
但し、マネジメントコンソールの表示は下記のように変化します。
設定直後
設定後しばらくたったら
pending rebootとなります。リブートは自動でかからないけど、リブートしないとParameter Groupsとして、paramtest は適応しないよ！という意味です。そのため、手動リブートが必要です。
Dynamicなパラメータを変更する
Parameter Groupsの設定画面で下記のような列があります。
これ、だいたい分かりますよね？たぶん
- Dynamic = DBリブート不要
- Static = DBリブート必要
だろうと、そう思ったら検証です。Dynamicでおそらくいちばん弄られているであろうパラメータを下記のように変更します。
先の工程で、paramtestというのを一旦空で作成し、適用だけはしているので、マネジメントコンソールで確認すると、一旦applyingになり、
すぐに in-syncとなります。リブートは自動で掛かることもないし、掛ける必要も無いです。
Staticなパラメータを変更する
今度はリブートが必要であろうパラメータ query_cache_type を変更します。このパラメータは文字通りのクエリーキャシュですね。MySQLというかRDSはデフォルトNOなのか、、へぇそうなんだ。まずは変更前にmysqlコマンドで直接確認。
mysql> show variables like 'query_cache_%'; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 1048576 | | query_cache_type | OFF | | query_cache_wlock_invalidate | OFF | +------------------------------+---------+ 5 rows in set (0.00 sec)
OFFですね。ではマネジメントコンソールで変更した直後のステータスは
自動でリブートはもちろん掛からないが、しばらくすると
でた、pending reboot
ということですので、手動でリブートする前に、パラメータ確認しましょう。
mysql> show variables like 'query_cache_%'; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 1048576 | | query_cache_type | OFF | | query_cache_wlock_invalidate | OFF | +------------------------------+---------+ 5 rows in set (0.00 sec)
OFFのまんまですね。
では、手動リブートし、しばらくした後確認したら。
mysql> show variables like 'query_cache_%'; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 1048576 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+---------+ 5 rows in set (0.01 sec)
ONになったよ！
まとめ
- Parameter Groups の変更や、割り当て作業で、自動でリブートかかることはない。
- Dynamicのパラメータ変更については、リブート不要。但し、Parameter GroupsのDBインスタンスへ割り当てと、同時に実行するなら、リブートは必要。
- Staticのパラメータについては、リブート必須。
とりあえず、RDSを立てたら、問答無用で Parameter Groups を一個作成し、適応、そしてリブートまでかけておけば、後からDynamicパラメータ変更となってもリブートの心配は不要ですし、損はないです。
monitで設定変更 & restartしても 反映されない時
プロセスがの死活を監視して、死んでたら勝手に再起動をかけてくれるというシンプルなデーモン monitですが、設定を間違った後に修正しても反映されないことがあります。そんな時はまず
# monit summary
で、現状を確認
Process 'hoge' Not monitored
とでたら、
# monit monitor hoge
とすればOK
digで . から掘る
何回やっても忘れてしまうのでメモ。
$ dig . ns ;; ANSWER SECTION: . 492579 IN NS j.root-servers.net. . 492579 IN NS e.root-servers.net. . 492579 IN NS a.root-servers.net. . 492579 IN NS b.root-servers.net. . 492579 IN NS l.root-servers.net. . 492579 IN NS h.root-servers.net. . 492579 IN NS d.root-servers.net. . 492579 IN NS c.root-servers.net. . 492579 IN NS m.root-servers.net. . 492579 IN NS f.root-servers.net. . 492579 IN NS g.root-servers.net. . 492579 IN NS i.root-servers.net. . 492579 IN NS k.root-servers.net. $ dig @a.root-servers.net jp. ns ;; ADDITIONAL SECTION: a.dns.jp. 172800 IN A 203.119.1.1 b.dns.jp. 172800 IN A 202.12.30.131 c.dns.jp. 172800 IN A 156.154.100.5 d.dns.jp. 172800 IN A 210.138.175.244 e.dns.jp. 172800 IN A 192.50.43.53 f.dns.jp. 172800 IN A 150.100.6.8 g.dns.jp. 172800 IN A 203.119.40.1 $ dig @a.dns.jp cloudpack.jp. ns ;; AUTHORITY SECTION: cloudpack.jp. 86400 IN NS ns-607.awsdns-11.net. cloudpack.jp. 86400 IN NS ns-1495.awsdns-58.org. cloudpack.jp. 86400 IN NS ns-282.awsdns-35.com. cloudpack.jp. 86400 IN NS ns-1784.awsdns-31.co.uk.
AppStreamでGoogleEarthをグリグリ動かす
AppStreamはレンダリングなどの重い処理をサーバー上で行い、絵だけを高速に様々なクライアントデバイス(スマホ、タブレット含む)に投げつけるサービスです。
AppStreamの存在意義
その手法の筋がいいか悪いかは別として、AppStreamの目指す分野はクラウド化出来ない最後の砦に対するAWSの挑戦だと取っています。シンクライアントに対する対義語で、ファットクライアントという言葉があるそうですが、まさに潤沢なリソース(CPU/メモリ) が無いと動かないアプリやゲームを動かすためのクライアントという意味です。
Web屋も、エンタープライズも、HPCも、Hadoop系もおまけにDaas(Workspaces)も揃っていて、最後の最後、明らかにクラウドが不得手としている分野です。
正直、ハードルは高い
他のAWSサービスとは違い、ガッツリ3D描画お行うようなサンプルを作らなければいけないので、AppStreamをためそうにもそれだけで結構な労力がかかりました。が、最近のアップデートで、Windows上のアプリをそのままAppStreamで配信できるようになったので、早速試してみる。
WindowsアプリをそのままAppStreamへ
ともかくアプリケーションを作ります。
するといきなりWindowsがブラウザ上で立ち上がります。
ふむふむ、こいつに仕込めばいいわけですな。IEからGoogle Earthをダウンロードして、インストールします。
サーバ上のレンダリングはおそらく早いと思うのですが、RDPがトロいので、カクつきます。下に小さくGPUはOffだと言ってますが、ホントかな？Google EarthでもGPUのデバドラ抜きではほぼ動かんぞ。
次に実際に配信するプログラムを指定します。今入れたばかりのGoogleEarthを指定します。
そして30分ぐらいかかるので、気長に待ちます。
準備出来たらこんな感じ
手順に従いテストを実行しましょう。そうしたらー
ｷﾀ━(ﾟ∀ﾟ)━! このグリグリ感は実際に体験しないと伝わらないので、無料枠もあるので、東京リージョンでぜひ！
課題
課題は超いっぱいあります。今回はGoogleEarthや、Blender,Gimp等がサンプルとして紹介されていますが、商用のライセンスが要るプロダクトとか、そもそも編集したファイルをどうやってローカルに引っ張ってくるかとか。ただ、こういうイロ者の方がやってて面白そうな感じがするので、新しいもの好きにはたまらない。
aws-cli で使える --query = jmespath をガッツリ使い込む
すでに結構色んな所で取り上げられている aws-cli の --queryですが、使ってみました。
とりあえずこれ試してみよう！
これを紹介だけで、このエントリの90%の価値が含まれております。騙されたと思ってやってみて。ぜひ
能書き
xpathってご存知？要は、xmlに対するクエリ言語のようなもので、xmlの構成に合わせてxpathを指定することにより、狙った特定の要素だけを引っ張り出したり、加工したりできます。最近の人はxmlは嫌いらしいですが、まあ、json も xmlの冗長部分を削いだものなので同じことがjsonに対してもできるってことですね。これがjmespathのはず、名前の付け方からして。ちなみに私はxpathで一発クエリで超複雑なxmlから、特定要素をスコンと狙い撃ちする感覚が大好き、快感です。
jmespathですが、はっきり言ってjqと機能的にかぶってます。xpathをやったことある人ならjmespathの方が多少学習コストが低いかもしれませんが、jemspathを積極的に使う理由は、プログラム上からの利用です。
上を見る限り、python,php,js,luaの4言語があります。rubyがハブられているのはやなかんじですが。js版はネイティブコードが一切絡まないので、GASやLambdaに容易にぶち込めるでしょうし、npmにも入ってる。まあ、jsonの展開なら本家本元のjavascriptに普通にやらせればいいというツッコミは置いといて。
jqはコマンドラインから使えるのが利点ですが、名前の付け方があまりよろしくなかったと思う。npmでjqとかで検索すると、JQueryのラッパーとかに引っかかってしまう。誰かが本気出せば jqの文法が通るライブラリを npmに展開してくれるでしょうが、今のところそれっぽいのは見つけられなかった。
実践サンプル
Route53のapex zone の AレコードAliasのDNSNameを狙い撃ち
aws route53 list-resource-record-sets --hosted-zone-id %hzid% \ --query 'ResourceRecordSets[?Name==`%your fqdn term .`].AliasTarget[].DNSName'
CloudFront ステータスが InProgressのやつだけ狙い撃ち
aws cloudfront list-distributions --query 'DistributionList.Items[?Status==`InProgress`].Id'
CloudFront の CNAME を狙い撃ち
aws cloudfront list-distributions --query 'DistributionList.Items[?Aliases.Items[0]==`%your fqdn%`].Id'
まとめ
aws限定だと jq があるからあんまり積極的に使う理由もないけど、結構面白い。And条件については、パイプの構文を使えば良さそうだけど、よくわかっていない。詳しくなったらまた書くつもり。
