続 カッコの付け方

AWSを始めとしたクラウドコンピューティング全般と、唯一神emacsにおける()の付け方についてだらだら書きます

RDSのディスクを後から変更するときに、リブートはどうなる?

今回は、RDSのディスク変更に伴うリブートの確認を行いました。前回のエントリで、mysqlの死活を秒間で確認するスクリプトを用意しているので、そいつを裏で回しておきます。

RDSでParameter Groups変更時のDBリブートについて調査してみた - 続 カッコの付け方

EBSタイプ変更せずに、容量だけUP

 SSD GP2 -> GP2 で実験したところ、リブートは発生しませんでした。

f:id:iga-ninja:20150228064300p:plain

でも何やら警告が出てますね。

  • コンバージョンに長い時間がかかって、EBSのクレジット使い果たすよ。
  • 操作が完了するまで、パフォーマンスに影響があるよ。

EBSのクレジットについては、別エントリで詳細を書く予定。

EBSタイプを SSD(GP2) -> SSD(PIOPS)に変更

今回は容量UPは行わず、 GP2 -> PIOPSへ種別変更だけにしましたが、こちらもリブートは発生しませんでした。

f:id:iga-ninja:20150228064619p:plain

警告メッセージもほぼ同じ。変更後のストレージはgp2で無いから、EBSクレジットは関係無いような気がするけど、元ストレージから引っ張りだす時の話かな?

EBSタイプを SSD(GP2) -> Magneticに変更

GP2(SSD) -> Magnetic(HDD) に変更した場合は、マネジメントコンソールに下記が表記されます。

f:id:iga-ninja:20150228065926p:plain

サービス断が明記されております。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 に適応しただけではリブートはかかりませんでした。 但し、マネジメントコンソールの表示は下記のように変化します。 設定直後 f:id:iga-ninja:20150225234504p:plain 設定後しばらくたったら f:id:iga-ninja:20150225234521p:plain pending rebootとなります。リブートは自動でかからないけど、リブートしないとParameter Groupsとして、paramtest は適応しないよ!という意味です。そのため、手動リブートが必要です。

Dynamicなパラメータを変更する

Parameter Groupsの設定画面で下記のような列があります。 f:id:iga-ninja:20150225235302p:plain これ、だいたい分かりますよね?たぶん

  • Dynamic = DBリブート不要
  • Static = DBリブート必要

だろうと、そう思ったら検証です。Dynamicでおそらくいちばん弄られているであろうパラメータを下記のように変更します。 f:id:iga-ninja:20150225235546p:plain

先の工程で、paramtestというのを一旦空で作成し、適用だけはしているので、マネジメントコンソールで確認すると、一旦applyingになり、 f:id:iga-ninja:20150225235742p:plain

すぐに in-syncとなります。リブートは自動で掛かることもないし、掛ける必要も無いです。 f:id:iga-ninja:20150225235829p:plain

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ですね。ではマネジメントコンソールで変更した直後のステータスは f:id:iga-ninja:20150226000631p:plain

自動でリブートはもちろん掛からないが、しばらくすると f:id:iga-ninja:20150226000733p:plain

でた、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になったよ!

まとめ

  1. Parameter Groups の変更や、割り当て作業で、自動でリブートかかることはない。
  2. Dynamicのパラメータ変更については、リブート不要。但し、Parameter GroupsのDBインスタンスへ割り当てと、同時に実行するなら、リブートは必要
  3. Staticのパラメータについては、リブート必須

とりあえず、RDSを立てたら、問答無用で Parameter Groups を一個作成し、適応、そしてリブートまでかけておけば、後からDynamicパラメータ変更となってもリブートの心配は不要ですし、損はないです。

monitで設定変更 & restartしても 反映されない時

プロセスがの死活を監視して、死んでたら勝手に再起動をかけてくれるというシンプルなデーモン monitですが、設定を間違った後に修正しても反映されないことがあります。そんな時はまず

# monit summary

で、現状を確認

Process 'hoge' Not monitored

とでたら、

# monit monitor hoge

とすればOK

digで . から掘る

何回やっても忘れてしまうのでメモ。

f:id:iga-ninja:20150215220346j:plain

$ 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へ

ともかくアプリケーションを作ります。

f:id:iga-ninja:20150215005226p:plain

するといきなりWindowsがブラウザ上で立ち上がります。

f:id:iga-ninja:20150215005249p:plain

ふむふむ、こいつに仕込めばいいわけですな。IEからGoogle Earthをダウンロードして、インストールします。

f:id:iga-ninja:20150215005313p:plain

サーバ上のレンダリングはおそらく早いと思うのですが、RDPがトロいので、カクつきます。下に小さくGPUはOffだと言ってますが、ホントかな?Google EarthでもGPUのデバドラ抜きではほぼ動かんぞ。

次に実際に配信するプログラムを指定します。今入れたばかりのGoogleEarthを指定します。

f:id:iga-ninja:20150215005446p:plain

そして30分ぐらいかかるので、気長に待ちます。

f:id:iga-ninja:20150215005557p:plain

準備出来たらこんな感じ

f:id:iga-ninja:20150215085416p:plain

手順に従いテストを実行しましょう。そうしたらー

f:id:iga-ninja:20150215085347p:plain

キタ━(゚∀゚)━! このグリグリ感は実際に体験しないと伝わらないので、無料枠もあるので、東京リージョンでぜひ!

課題

課題は超いっぱいあります。今回はGoogleEarthや、Blender,Gimp等がサンプルとして紹介されていますが、商用のライセンスが要るプロダクトとか、そもそも編集したファイルをどうやってローカルに引っ張ってくるかとか。ただ、こういうイロ者の方がやってて面白そうな感じがするので、新しいもの好きにはたまらない。

CloudFrontで日本語URLをInvalidation(キャッシュクリア)するには

マネジメントコンソールでも

URLエンコードせよ!

以上

こんな感じで怒られます。

f:id:iga-ninja:20150215083514p:plain

URLエンコードも含めて、Chromeで確認するのが良いです。

f:id:iga-ninja:20150215084130p:plain

こいつをInvalidationにぶち込んでやればOKです。

aws-cli で使える --query = jmespath をガッツリ使い込む

すでに結構色んな所で取り上げられている aws-cli の --queryですが、使ってみました。

とりあえずこれ試してみよう!

JMESPath Tutorial — JMESPath

これを紹介だけで、このエントリの90%の価値が含まれております。騙されたと思ってやってみて。ぜひ

能書き

xpathってご存知?要は、xmlに対するクエリ言語のようなもので、xmlの構成に合わせてxpathを指定することにより、狙った特定の要素だけを引っ張り出したり、加工したりできます。最近の人はxmlは嫌いらしいですが、まあ、jsonxmlの冗長部分を削いだものなので同じことがjsonに対してもできるってことですね。これがjmespathのはず、名前の付け方からして。ちなみに私はxpathで一発クエリで超複雑なxmlから、特定要素をスコンと狙い撃ちする感覚が大好き、快感です。

jmespathですが、はっきり言ってjqと機能的にかぶってます。xpathをやったことある人ならjmespathの方が多少学習コストが低いかもしれませんが、jemspathを積極的に使う理由は、プログラム上からの利用です。

jmespath · GitHub

上を見る限り、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条件については、パイプの構文を使えば良さそうだけど、よくわかっていない。詳しくなったらまた書くつもり。