「Emacs & trampで編集だー」 と思ってたのですが、なんだかんだでパスありログインのサーバが多くて、vimちょっとは覚えようかと。
とりあえず、正規表現による置換
まず、VIMの正規表現は pcreじゃないらしい。.+ とか普通に反応して欲しいのだが、方言を覚えるのも面倒くさいので
/\v[regexp]
と\v をつければいいらしい。
で、置換ですが、:%s/\vとやっても出来なかったが、vimは直前の正規表現パターンを覚えているらしいので、それを使えば良いらしい。ハイライトしてからの置換だから、間違いがなくていいね！:%s//#&/gとかを、一旦検索&ハイライトしてから打つ。
ハイライトの消し方は :noh
ちょっと作業効率UP
Google Cloud Monitoring でカスタムメトリクスを投げてみました。
下記の2つがあります。
サンプルがあるので、サクッと両方共動かします。
見た感じだとカスタムメトリックのコールでAPI使用数を消費しているので、この工程は必須では無いかと。前の記事にSS貼っておきました。
Google Cloud Monitoringを試し、そしてビビる - 続 カッコの付け方
scopesまず、GCEのインスタンス起動時にscopeというものを指定します。解釈としては、EC2の IAMロールとおなじ。ここは まだDevelopers console で出来ないので、gcloudコマンドでインスタンス作成する必要があります。。
gcloud compute --project "<Project>" \ instances create cm-example-vm --image centos-6 \ --zone asia-east1-b \ --scopes https://www.googleapis.com/auth/monitoring \ https://www.googleapis.com/auth/devstorage.read_only \ --machine-type g1-small
この scopes は、 Developers console上からも指定できることはできますが、 Cloud Monitoringのエンドポイントが指定出来ないようです。よって、gcloud 必須。また、残念なことにこのscopesは後付け不可能です。ここもできれば改善してほしい。
# yum install python-setuptools # easy_install pip # pip install --upgrade google-api-python-client
Example: Using a Lightweight Custom Metric - Google Cloud Monitoring — Google Cloud Platform
pidをグラフ化ですので、あくまでデモ用
Example: Using a Labeled Custom Metric - Google Cloud Monitoring — Google Cloud Platform
こちらは店舗のシャツの在庫をグラフ化、シャツの色とサイズでラベル付け
ダッシュボードに貼り付けたらこんな感じ。
lightweightはいいとして、labeledはこんな感じで表示をカスタム出来ます。
scopesを指定出来ない。scopesに頼らなくともできるはず。今回はサンプル通りにやりましたが、pythonで組み込みとかやらなくても行けると思う、たぶん。それとscopesは無理だけどカスタムメトリックの後付けはできるはず。
Google Cloud Monitoring はGCEのVMインスタンスやディスクのリソース監視やアラート、さらにはエンドポイント監視ができるものです。AWSでいうところの CloudWatchです。が、もともとはstackdriverというサービスをGCPに取り込んだものという経緯があります。長らくリミテッドプレビューでしたが、いよいよBetaとなり、ガチ運用も踏まえてためしてみました。私はstackdriverを使ったことが無いので、ガチ使いしていた人は間違ってたら教えて下さい。
大体の機能はスクリーンショットのみにします。見てもらったほうが早いです。
プロジェクトオーナーのみが有効化可能です。編集可能ユーザーでも無理ですのでご注意。あと、APIも有効化しておきましょう。APIの有効化はプロジェクトオーナー以外でも可能です。マニュアルに書いてないですが、おそらくやっておかないとCustom Metricsが打てないと思うので、後々響くはず。
エージェントを入れないとかなり低機能となってしまうので、入れたほうがいいです。Cloud Monitoringのキーが必要なので、下記をメモっておく。また、これもプロジェクトのオーナー以外は、キー自体見ることができないようです。
あとは管理対象インスタンス上で下記を
curl -O https://repo.stackdriver.com/stack-install.sh bash stack-install.sh --api-key=<cloud monitoring api key>
スクリーンショットのみです。使いやすいです。
Notificationとして 最近流行りの Hipchat や Slack にも投げられます。Webhookで汎用にも対応。
MDで文章追加もできる。テンプレートとか効くかどうかはまだ調べてない
Ackとかもいける。
これもドキュメントのまんまですのでやり方は割愛。結果こんな感じです。インスタンスの中に出てきますね。
簡単に言うとWeb/URL監視ですね。これもスクリーンショット見てください。
さすがは元単体のサービスと思うぐらい、よく出来ています。
Hipchat campfire Slack に投げつけられるのもいい。さすがにこれがタダってことは無いと思うけども、そんな常識が通用しないのがgoogleの面白いところ。しかし、本当にこれがタダなら価格破壊もいいとこ、ビビるわ。
stackoverflowでもこの件について触れられていますが、GCEでは、インスタンスからのOutbound:Port25は全面シャットアウトです。そのため、メール送信にはSendGridが必要となります。
Google Compute Engine (GCE) email delivery solution? - Stack Overflow
GCPとSendGridの提携により、月 25,000通は無料で送れるようです。その気になればAWS SESも使えるはずですが、無料分があるので、、
あとはGoogleの公式ドキュメントの日本語訳です(^^)ちなみに環境はCentOS
Sending Email from an Instance - Google Compute Engine — Google Cloud Platform
$ gcloud compute ssh INSTANCE
2) rootになって、 umask 077を指定
[user@test-centos ~]$ sudo su - [root@test-centos ~]# umask 077
3) /etc/postfix/sasl_passwd ファイルを作り、下記の書式でSendGridのユーザー名:パスワードを入れてください。 改行無しでね。
[root@test-centos ~]# cat > /etc/postfix/sasl_passwd << EOF [smtp.sendgrid.net]:2525 YOUR_SENDGRID_USERNAME:YOUR_SENDGRID_PASSWORD EOF
4) postmapコマンドで.db作成。
[root@test-centos ~]# postmap /etc/postfix/sasl_passwd [root@test-centos ~]# ls -l /etc/postfix/sasl_passwd* -rw------- 1 root root 68 Jun 1 10:50 /etc/postfix/sasl_passwd -rw------- 1 root root 12288 Jun 1 10:51 /etc/postfix/sasl_passwd.db
5) /etc/postfix/main.cfに追記
[root@test-centos ~]# cat >> /etc/postfix/main.cf << EOF smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_tls_security_level = encrypt header_size_limit = 4096000 relayhost = [smtp.sendgrid.net]:2525 EOF
6) 認証ライブラリが最新かどうか、確認してね
[root@test-centos ~]# yum install cyrus-sasl-plain
7) postfix を reloadしてね。(訳者注 postfix は restart > reloadとは限らないところがあったはずなので、明示的に reloadが必要なはず。)
[root@test-centos ~]# postfix reload postfix/postfix-script: refreshing the Postfix mail system
8) プレーンテキストのsasl_passwdはもう不要だから、消しといて。
mailコマンドで飛ばしてみましょう。届いたメールの Return-Path: は xxxxxxx@sendgrid.meとなってます。
スパムに使われる対策ですよねー。Asure, SoftLayler, GCEともにメール出すならSendGrid使ってです。むしろ素の状態で1通でもメール送信できるAWSのほうが稀少なぐらい。
知っている人は知っている、GCP(GCE)のロードバランサーはリージョン跨ぎができます。昨年10月頃？より、Developers Consoleから確認できるロードバランサーは2つになりました。
このうち、リージョン跨ぎロードバランサーはHTTP負荷分散の事になります。ただしこちらのロードバランサーはまだBetaとなっています。さらに正確には HTTP負荷分散は 本エントリの Cross-Region load balancing と Content-based load balancing の2つがあります。
エンジニアであれば、きっとそう思います。ですができるんです。どうして？と聞かれても全部は説明できませんが、確実に言える仕様を書きますと、
説明出来る部分もあるのですが、長くなるので別エントリでいずれ。
まず、HTTPロードバランサーはBetaということもあり、2015/03/01時点ではDevelopers Consoleからすべての操作はできませんでした。gcloud コマンドを使わないと一部完結しない部分があるようです。ホントは全部Developers Consoleで片付けたかったのですが、真逆のコマンドベースのチュートリアル通りの平凡な内容になってます。
Cross-Region Load Balancing - Google Compute Engine — Google Cloud Platform
OSは何でもOKです、index.htmlに、自分のリージョンやホスト名がわかるような文字を書きましょう。
ここからが長いステップです。まず、各オブジェクトの関連図を
四の五の言わずにチュートリアル通りに作ってから見直しましょう。初見では意味がわかりません、きっと。ただ、これから打つコマンドはこの図を実現するものであり、作る順番は右の方から依存関係に則した順番で作るということは意識しておいたほうが良いです。
ここがDevelopers Consoleで出来ません。確かに項目としてはすでにあるのですが、どうやっても進めないステップがあったためです(もしかしたら私のオペレーションが悪いのかもしれません)。まずは gcloudコマンドのpreview機能を使えるようにします。
$ gcloud components update preview
ここから先はチュートリアルのほぼまんまです。アジアと北米にアレンジしただけです。
$ gcloud preview instance-groups --zone us-central1-a create us-resources $ gcloud preview instance-groups --zone as-east1-b create as-resource
スペルミスです、 as-resourcesのsが漏れてます。気にしないで。注意したいところは、1 instance-group = 1 zone という点です。1 region ではなく、zoneです。そもそもAWSのAZと比較できるものではないかもしれませんが、複数のzoneに振りたいのであれば、その数だけ instance-groupを作成する必要があります。今回は各々のregionに1個ずつインスタンスを立てるので、2個だけです。
インスタンスをinstance-groupに追加します。ここまではコマンド以外でも出来た気がする。
$ gcloud preview instance-groups --zone us-central1-a instances \
--group us-resources add <北米に作ったインスタンス>
$ gcloud preview instance-groups --zone asia-east1-b instances \
--group europe-resources <アジアに作ったインスタンス>
ここからgcloudコマンドじゃないと無理だった。そもそもDevelopers Consoleに、本項目を設定できる場所がない。
$ gcloud preview instance-groups --zone us-central1-a add-service us-resources \
--port 80 --service http
$ gcloud preview instance-groups --zone asia-east1-b add-service as-resource \
--port 80 --service http
ヘルスチェックの作成です。デフォルトのまんまなので、作って終わり。
$ gcloud compute http-health-checks create basic-check
今度はbackend-serviceを作成します。もくもくと作っていきます。ここもgcloudコマンドでないと出来そうで出来なかった。
$ gcloud compute backend-services create web-service \ --http-health-check basic-check
backend-servicesに、前ステップで作ったinstance-groupを追加します。
$ gcloud compute backend-services add-backend web-service \
--group us-resources --zone us-central1-a
$ gcloud compute backend-services add-backend web-service \
--group as-resource --zone asia-east1-b
次はurl-mapの作成。URLによって、参照するバックエンドのサーバを変えたいのであれば、content-based routing を参照せいと書いてありますが、今回は無視。
$ gcloud compute url-maps create web-map --default-service web-service
さらに、http-proxyの作成です。直前で作った url-map を参照しています。
$ gcloud compute target-http-proxies create web-proxy --url-map web-map
そしていよいよ最後、forwarding-ruleを作ります。
$ gcloud compute forwarding-rules create http-rule --global \
--target-http-proxy web-proxy --port-range 80
その前に、私が試していたところ、実際にインスタンスのヘルスチェックが通るまで、結構時間がかかりました。しばらく待てば下記の画面が確認できます。
こうなるまでしばし待ちます。
さあ、curlで叩くよ！
東京(LocalPC)から
$ curl 107.178.250.170 this is asia
$ curl 107.178.250.170 this is us1
効いてる！Geo Routing相当です！
では早速アジアのサーバを殺します。 東京(LocalPC)から
$ curl 107.178.250.170 this is us1
$ curl 107.178.250.170 this is us1
アジアが死んだのでアジアからのリクエストが北米に飛びました。
東京(LocalPC)から
$ curl 107.178.250.170 this is asia
$ curl 107.178.250.170 this is us1
無事復帰しました。IPアドレス晒しましたが、しばらくしたら潰します。
まだBeta版とは言え、本当にリージョン跨ぎが出来ます。検証については、北米を止めたケースももちろんやってますが、長くなるので割愛しました。感想も混ざってますが、一応まとめると。
googlecomputeengine - HTTP Load Balancerを使って、Host名やURIによって接続するインスタンス(群)を切り替える - Qiita
動画付きです、忙しいかたはこちらの動画をみて、おおーと驚きましょう。
lsyncdを使って、2台のサーバ上のファイルを双方向からの同期を検証していた時に、予期せぬファイル削除が発生しました。その謎と対処方法について迫ります。
lsyncdは自分の特定のディレクトリを見張り、変更(ファイルの追加、変更、削除等)のイベントが発生した場合、それをトリガーに他のサーバへ伝搬したりすることができます。しかし、lsyncdはあくまでも自サーバのファイル変更を捕まえるだけなので、相手のサーバに起こった変更はわかりません。
そこで、例として2台のサーバでお互いにlsyncdをかけることにより、2台が全く同じ状況を作ります。下図のような構成です。(絵はAWSですが、別にAWSに限った話ではないです。)
CentOS 6系の場合は、下記を参考にインストールできます。
このエントリにも記載があるように、initスクリプトがミスっていますので、修正が必要です。/etc/lsyncd.confに設定ファイルを置く場合は、ここの修正は不要ですが、上記を参考にアレンジしましょう。
lsyncd は 2.1 系で大きく設定ファイルが変更されています。 2.0系の設定ファイルはまず動かないと思います。ここはマニュアル読むしか無いです(日本語の2.1系の情報は少ないと言われています。)
Manual to Lsyncd 2.1.x · axkibe/lsyncd Wiki · GitHub
とりあえず、設定例を載せておきます。
settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd-status.log",
statusInterval = 20
}
sync {
default.rsync,
delay = 0,
source="/tmp/lsync-test",
target="[user]@[相手ホスト]:/tmp/lsync-test/",
rsync = {
rsh = "/usr/bin/ssh -i [ssh-key] -o StrictHostKeyChecking=no"
}
}
/tmp/lsync-test にファイルを書いたり消したりして、動作を確認しましょう。問題無いことが分かります。(循環が発生しそうですが、大丈夫でした)
ためしに図の サーバA を止めてみます。すると、LBはすべてのリクエストをサーバBに流れます。サーバBに対して書き込まれたファイルは、lsyncd によりサーバAに伝搬しようとしますが、Aは死んでいるので受け取れません。その時lsyncdはどうなるのか。
答えは、リトライを繰り返すです。BはAが死んでいても、思いを伝えようと、何度も何度もリトライします。健気です、切ないです。。
ですが、この動作を利用すれば、このままAが復帰した暁には、Bの思いはAに届きそうです。やったね！サーバB！
なんと無残な！この事象の発生メカニズムはこうです。
5については、B->Aの同期が早く届く場合もあるので、100%ではありませんが、実際に確認することは出来ました。これを何とかしましょう。
Lsyncd 2.1.x ‖ Layer 4 Config ‖ Default Behavior · axkibe/lsyncd Wiki · GitHub
上記にデフォルトの動作として delete=true のかわりに delete="running" とすれば、スタートアップ時の削除は抑制できるよーと書いてあります。早速適応して、試すとうまく行きました。
settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd-status.log",
statusInterval = 20
}
sync {
default.rsync,
delay = 0,
source="/tmp/lsync-test",
target="[user]@[相手ホスト]:/tmp/lsync-test/",
delete="running",
rsync = {
rsh = "/usr/bin/ssh -i [ssh-key] -o StrictHostKeyChecking=no"
}
}
めでたしめでたし。
実はこれで終わりではないです。確かにファイル喪失という最悪の事態は回避できますが、今度はB単独時に削除されたファイルを復帰させてしまう可能性があります。
これを抑制するには init = false を指定しましょう、これもマニュアルに書いてあり、扱いは要注意とのことです。
EBSにSSDタイプが追加されてしばらく経ちましたが、
「でも、お高いんでしょ？」
「値段調べたけど、そんなに高く無いし、SSDだったら絶対に早いよね！HDDよりは」
という先入観があると思いますが、ちゃんと調べてみました。
それはAWSのドキュメントです。
Amazon RDS のストレージ - Amazon Relational Database Service
これを読めば、このエントリはもう用済みです。#説明書読まない病は直さんとイカンです。
General PurposeにはEBS I/O クレジットというものが有ります。他方でも紹介されていますが、ディスクI/Oが少ない時にクレジットがたまり、大規模なディスクI/Oが発生した時にそのクレジット分だけバーストするというものです。同じような考え方が t2系インスタンスのCPUクレジットですが、考え方が少し異なる点があります。
使わない時にクレジットがたまる(但し上限あり)という考え方は両方同じです。しかし、EBSクレジットは、最初からかなりクレジットを持った状態から始まりますつまり。
どんなシステムでも確実にEBSのI/Oがホットになる瞬間があります。それはOSの起動時です。EBSクレジットの目的はここにあります。
gp2にはEBSクレジットが存在し、これを使うことによって3000IOPSまで、EBSクレジットが続く限りバーストできます。それに対してio1は、予め指定したIOPSを買うイメージです。では、gp2のクレジットが尽きたらどうなるのでしょうか？ここがベースラインです。ベースラインは一律ボリュームサイズ(GB)の3倍です。つまり100GBならば300IOPSがベースラインとなります。io1はこの容量/IOPSのレートを変えたい用途でも使えます。
EC2のEBSでは、GB容量の30倍という極端な例(5GB - 150 IPOSとか) が作れますが、RDSの io1は 100GB - 1000 IOPSが下限となるため、RDS用途の主たる目的はパフォーマンスを保証したいときだと思います。
gp2のベースラインは GB容量 * 3 となります。バーストして、クレジットを使い切ると、ベースラインとなるのは書きましたが、計算ルールがCPUと異なります。バーストの上限は3000 IOPSで、ベースラインとの差分で計算されます。つまり、1TB の gp2 の場合、ベースラインは 3000 IOPSなので、そもそもバーストの必要がありません。対して100GBの gp2の場合、ベースラインは 300 IOPS 、さらに 200GBの場合は 600 IOPS となり、バーストはこのベースラインとの差分で計算されます。つまり、ベースラインが高い = 容量が大きいほど、クレジット消費は緩やかになります。
| ボリュームサイズ（GiB） | ベースパフォーマンス（IOPS） | 3,000 IOPS での最大のバースト期間（秒数） | 空のクレジットバランスを補充する秒数 |
|---|---|---|---|
| 1 | 3 | 1,802 | 1,800,000 |
| 100 | 300 | 2,000 | 18,000 |
| 250 | 750 | 2,400 | 7,200 |
| 500 | 1,500 | 3,600 | 3,600 |
| 750 | 2,250 | 7,200 | 2,400 |
| 1,000 | 3,000 | 該当しない* | 該当しない* |
Amazon EBS ボリュームの種類 - Amazon Elastic Compute Cloudより抜粋
ほとんどのユースケースにおいて、gp2がコストパフォーマンス的には有利でしょう。ただし、ディスクIOがある程度見積もれる状態かつ、gp2のベースラインでは足りない場合、io1という選択を考慮します。magneticについては、極端に少ない容量の場合は有利であると思います。
