IT系のめもを蓄積していこうかと
GCPからのメール送信というと、
などがよく出てくるが、
SendGridを使うほどではなく、
たまにアラートなどで使いたい場合に、
上記どちらの方法もやりにくい。
実際にrubyスクリプトから、SMTP接続してメール送信をするケースにおいて、
どうもSMTPリレーが上手くいかなかった（Postfixでちゃんとリレー設定しないと難しいのかな？）ので、
アプリパスワードを発行して、GoogleAppsへSMTP接続すれば、無事送信できることが確認できた。
詳しくは以下。
https://support.google.com/mail/answer/185833?hl=ja
最近はwebhookなども通知に使われるが、
やはり入れておきたいメール通知。
以上
AWSのCDNであるCloudFrontを利用したので、
その特徴を記載しておく。
良い点
・L7レベルで動作
たとえば2つのオリジンを設定して、
パスパターンによって、振り分け先を変更できること。
静的コンテンツはS3に、動的コンテンツはELBに振るなどが可能。
・独自ドメインでのSSLが利用可能
S3では出来ない独自ドメインSSLが利用可能。
・AWS内のオリジンとは高速な通信
オリジンがELBの場合、ELB配下のインスタンスが巨大な画像等を返す場合、
通信が安定しているcloudfrontに返すほうが、インスタンスの負荷は下がる。
悪い点
・変更反映が遅い
15分くらいかかるのだろうか。
・キャッシュ削除が遅い
これも15分くらいかかっている感じがする。
・連続的にGETアクセスした場合にキャッシュさせたくなくてもキャッシュされる
例えば2つオリジンを設定して、片方を静的、もう片方を動的とする。
動的コンテンツ側に振られるURLに瞬間的に連続アクセスした場合、すべてのリクエストが動的コンテンツ側に来るわけではなく、
cloudfrontにキャッシュされてしまう。
後述するキャッシュのヒット条件にもよるが、
キャッシュさせないはずの動的コンテンツが、実際にはキャッシュからエンドユーザに返される可能性がある。
最も簡単・確実に回避するためには、URLに一意のクエリ文字列を付ければよい。（JSを使って、タイムスタンプ＋ランダム文字列などを付与する）
・オリジンへ渡すヘッダー情報がキャッシュキーの種となる
オリジンへ渡すヘッダーとしては諸々設定が可能だが、
動的コンテンツをオリジンとする場合、user-agentなどを通ししまうと、
それがキャッシュキーの種となり、結果としてキャッシュヒット率が下がる。
この場合は、cloudfront独自の「IS_MOBILE」的なヘッダーを付けて、オリジン側で判定として使える。
逆に言うと、cloudfrontを使う場合、オリジンで「IS_MOBILE」などの判定処理を用意しておく必要がある。
CloudFrontは設定が細かく、結構難しい。
ただ、統計情報も充実しており、
なんといっても高負荷に強く、エッジロケーションも広いので、
上手く使えば非常に強力な製品だと感じた。
気を付けるべきは、動的コンテンツを背後に置く場合だろう。
キャッシュ条件、キャッシュ生存期間など、動的コンテンツ作成者側が意識しておくことで、
より有用なものとすることが出来ると思う。
最近は、CDNが多用されているので、
各CDNの特徴をよく確認し、十分に検証したうえで、
導入を検討するとよいと思う。
他のCDNについても、機会があれば書いてみようと思います。
以上
muninでMariaDB10.0.4を監視してたら、
情報がほとんどあつまっていなかった。
munin自体はepelからインストールしたのだが、
これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、
以下にあるファイルで上書きする必要がある。
このファイルで上書き、
1行目の
#!@@PERL@@
を
#!/usr/bin/perl
に直したら、MariaDB10.0.4でも問題なく動いた。
以上
remiレポジトリからインストールしたredis3.2でredis-cliを使うと、
コマンドアシスト（ヒント）が効くようだ。
たとえば、zrevrageを打ちたいとき、
zとうつと、アシストが出て、タブ押下で補完できる。
redisのコマンドって、なかなか覚えられないと思うが、
アシストがあると覚えやすくていいと思う。
以上
monitというとプロセス監視をしてくれるだけのイメージがあったが、
深く触ってみると、こいつはすごいなと思った。
基本的にmonitあれば大半のことは事足りると思う。
ちなみに環境は、centos7で、monitはepelレポジトリからインストールしました。
monitの便利なところとして、以下があげられる。
さらに、m/monitをつかえば、情報の集約も可能となる。
（有料だけど、買い切りでそれほど高くないのは、良心的）
クラウド環境では、かなりの監視ツールがあるが、
こねたことはできないので（できても意外に金がかかる。。）、
monit（もしくはm/monit）を併用すると、結構安心して夜も眠れる環境が出来そう。
どこかで、monitの設定を書いてみようと思う。
以上
ansibleのベストプラクティスを理解するのに時間がかかったが、
実案件の構築を通して、なんとなくわかってきた。
個人的な所感を表現すると、
「環境・特性・筐体ごとに役割を分割し、変数を割り当てる」
ということになる。
言葉で表すと、若干意味不明なので、例を書いてみる。
＜例＞
あるWEBサイトを作る場合、
サービス側と管理側でシステムが分かれるケースが多いだろう。
その場合、サービス側ではアクセスが多く、
参照が多いのであれば、DBに加えて、様々なキャッシュも併用する。
同時にwebサーバではkeepaliveを強くしたり、画像のキャッシュを行うこともあるだろう。
反対に、管理側では、アクセス人数が限られていることもあり、
キャッシュは使わないし、正確なデータ提供が求められる。
＜サービス側の構成＞
例えば、
というようなケースを考えてみよう。
そして、
という環境があるとする。
という状況において、
本番のインベントリファイルは以下のようになる。
inventry-service-production.ini
# ---------- # servers # ---------- [servers-service-web] service-production-web01 service-production-web02 ### ↑のセクションは、webサーバとしてのグルーピング [servers-service-cache] service-production-cache01 service-production-cache02 ### ↑のセクションは、cacheサーバとしてのグルーピング [servers-service-db] service-production-db01 service-production-db02 ### ↑のセクションは、dbサーバとしてのグルーピング # ---------- # grouping # ---------- [servers-service:children] servers-service-web servers-service-cache servers-service-db ### ↑のセクションは、全体のグルーピング # ---------- # environment # ---------- [env-service-production:children] servers-service-web servers-service-cache servers-service-db ### ↑のセクションは、本番環境全体のグルーピング [env-service-production-web:childeren] servers-service-web ### ↑のセクションは、本番環境webサーバのグルーピング [env-service-production-cache:childeren] servers-service-cache ### ↑のセクションは、本番環境cacheサーバのグルーピング [env-service-production-db:childeren] servers-service-db ### ↑のセクションは、本番環境dbサーバとしてのグルーピング
この状態において、
必要なgroup_vars以下のファイルは以下の通りとなる。
1のファイルに書かれる設定は、「サービス側共通設定」である。
つまり、環境や種別が変わっても、必ず設定されるべきものである。
例えば、sshの設定などは、比較的このケースにあたるだろう。
（当然、all.ymlでもよい。ただし、all.ymlは、サービス側・管理側での共通設定という位置づけの方がよいと思う）
2のファイルに書かれる設定は、「本番環境サービス側共通設定」である。
つまり、本番環境のすべての筐体に設定されるべきものである。
例えば、本番環境のみ監視ツールを入れたい場合などのは、このケースにあたるだろう。
3のファイルに書かれる設定は、「本番環境のサービス側webサーバでの共通設定」である。
ここでは、apacheやphpの設定がそれにあたる。
どうように、4、5も解釈できるだろう。
さらにいうと、dbサーバでは、masterとslaveがわかれるが、
これはhost_varsを使って、さらに筐体ごとに設定をわけてやればよい。
ansibleは奥が深い。
設定された変数の適用順番、マージ方法、上書き、予約語（関数）衝突もあり、
なかなかうまくいかないだろうが、
このあたりを抑えておくと、幅が広がる感じがすると思う。
管理側については、
省略するが、大筋この流れでかけるはず。
以上
ansibleでshellコマンドを使うとき、
リスト変数に対してできるだけ簡単にできないかをやってみた。
以下備忘録です。
[ シナリオ ]
複数ユーザのbashrcに同じ情報（ここではumask）を書き込む
[ コード ]
- name: change umask
shell: dummy=`sudo cat /home/{{ item }}/.bashrc | grep -F "umask"` && [[ -n $dummy ]] || echo "umask 002" >> /home/{{ item }}/.bashrc && source /home/{{ item }}/.bashrc
with_items:
- hoge
- fuga
failed_when: false
tags: common, users
ちょっと長いが、.bashrcからumaskをgrepして、
結果がなければ、umaskを書き込んで、
sourceで反映している。
本来ならregisterとか使ってやるべきだが、
リスト変数に対して書くと冗長になるので、
このようなやり方にした。
Dict型でregisterできればよいのだけど、
そんな方法あるのかな？
set_factとかでもやれそうな気がするんだけど、
一時的な変数をあまり維持するのも微妙だしな。。
GCPとAWSで、拠点（リージョン）間の通信速度を簡単に図ってみた。
正確ではないし、3回程度しか実施していないので、その点は考慮ください。
■ComputerEngineのインスタンス（ASIA）から（AMERICA東部）への２３０MBのSCP
24秒
■EC2のインスタンス（TOKYO）から（AMERICA東部）への２３０MBのSCP
23秒
ほとんど同じ。
GCPはネットワークの強さをうたっているが、AWSと変わらないケースもある。
GCPの場合、ローカルネットワーク上で、異なるリージョンのインスタンスをまとめられるので、
データベースなどを複数リージョンで準同期レプリケーションできるとよいと思っていたが、
その目論見は成立しそうにないことがわかった。
ただし、GCPはグローバルロードバランサーとか、CloudStorageがめちゃくちゃ優秀だから、
実際にサービスとしてユーザの体感速度的なものは、広域範囲で考えればAWSより優秀なのではないか。
GCP（Google Cloud Platform）における、
Google Cloud Storage（以下、GCS）がすごい。
AWSでいうところのS3にあたるものですが、
バケット間同期が、
25,000ファイル、8GBを転送（同期）するのに、約5分。
驚異的。。
JAVAの並列処理（４CORE）で、
S3に同じ量をアップするのに、8分だったから、
ちょっと負けた気分。
なお、GCSはgsutilというツールを使うのがよい。
JAVAなどはSDKが出ているが、とてもめんどくさい。
gsutilは、gcloudの認証に影響を受けるようなので、
予めサービスアカウントを発行して、gcloudでの認証処理をしておくのがよい。
追記
ちなみに、上記の5分という数字は、
バケットのリージョンが異なっていても、同じでも変わらない。
つまり、AsiaからAmericaのバケット間転送でも超高速。
驚異的。。。
以前の記事で、
master、slave構成において、
があることが抜けていた。
今回のように、maxscaleでsalve auto promotionを使う場合、
データロスト率が低い準同期方式がよいと思われる。
準同期レプリケーションについては、詳細説明をされているホームページがあるので、
それを参照されたい。
準同期レプリケーションの設定は以下。
[mysqld] plugin-load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so rpl_semi_sync_master_enabled=1 rpl_semi_sync_master_timeout=1000 rpl_semi_sync_slave_enabled=1
これで、プラグインのロードと、
準同期レプリケーションの設定が入る。
なお、ここでは、masterがslaveに、slaveがmasterになることがあるので、
master・slave問わず同じ設定を入れている。
ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。
非同期と混在させることが出来なかったような気がするので、
遠隔地にバックアップをおくこともできないと思われる。
これらについて、検証したら詳細を記述したい。