技術めも

awsのIPv6対応状況をまとめてみる。

■ELB

dualstackから始めるドメインであれば、IPv6対応である。

Route53を使う場合は、AAAAのaliasを貼ればよく、

他DNSを使う場合は、CNAME設定になるのかな？

dualstack.XXX.ap-northeast-1.elb.amazonaws.com

■S3

こちらもdualstackのドメインであれば対応済みということである。

https://aws.amazon.com/jp/blogs/news/now-available-ipv6-support-for-amazon-s3/

■Cloud Front

こちらは執筆時点では対応発表済みであるが、

逐次対応が進んでいる状況である。

そのため、ひょっとしたら、設定したにも関わらず、

名前解決できない可能性もある。

https://aws.amazon.com/jp/blogs/news/ipv6-support-update-cloudfront-waf-and-s3-transfer-acceleration/

その他、EC2などはIPv4を前提とした設計となっているため、

対応にはしばらくかかるだろう。

ただ、外向きの部分において、awsはIPv6対応を着実に進めているため、

appleのATS問題などは回避できそうである。

その他、私が知っている限りだと、

• さくらVPS
• さくらクラウド

はIPv6対応が結構すすんでいる。

ただし、さくらクラウドは共用ネットワークではIPv6が利用できなかったので、注意が必要。（※あくまで執筆時点）

さくらは比較的早期からIPv6対応していたので、近いうちにもろもろ対応してくれるだろう。

以上

以前の記事でnginxのIPv6対応を書いた。

しかし、設定上、

ipv6only=on

という記述は、1度しか書けないため、

virtualhostで複数運用している場合に、この設定は邪魔となる。

virtualhostで運用する場合が多いので、

最終的には以下のようにすればよいのではないだろうか。

/etc/nginx/nginx.conf

http {
    :
    :
    # serverディレクティブは書かない
    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/conf.d/default.conf

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name localhost;
    :
    :

/etc/nginx/conf.d/your-ssl-vh.conf

server {
    listen                  80;
    listen                  [::]:80;
    listen                  443 ssl;
    listen                  [::]:443 ssl;
    server_name             your-ssl-vh;
    ssl_certificate         /etc/pki/tls/certs/server.crt;
    ssl_certificate_key     /etc/pki/tls/certs/server.key;
    :
    :   

このように記載しておくと、your-ssl-vhホストでは、

ipv4、v6の、non-sslまたはsslでのlistenとなる。

non-sslサイトを生きにしつつ、sslも併用し、

念のためipv6対応も入れたいというケースはこのような対応となるだろう。

以上

GCPからのメール送信というと、

• 外部サービス（SendGrid）に接続してのSMTP通信
• GoogleAppsへのSMTPリレー

などがよく出てくるが、

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レベルのものまでしかサポートしていないため、

以下にあるファイルで上書きする必要がある。

https://github.com/munin-monitoring/munin/blob/8abb3faf7865af125ecc18b4feece35c59c90fd9/plugins/node.d/mysql_.in

このファイルで上書き、

1行目の

#!@@PERL@@

を

#!/usr/bin/perl

に直したら、MariaDB10.0.4でも問題なく動いた。

以上

remiレポジトリからインストールしたredis3.2でredis-cliを使うと、

コマンドアシスト（ヒント）が効くようだ。

たとえば、zrevrageを打ちたいとき、

zとうつと、アシストが出て、タブ押下で補完できる。

redisのコマンドって、なかなか覚えられないと思うが、

アシストがあると覚えやすくていいと思う。

以上

monitというとプロセス監視をしてくれるだけのイメージがあったが、

深く触ってみると、こいつはすごいなと思った。

基本的にmonitあれば大半のことは事足りると思う。

ちなみに環境は、centos7で、monitはepelレポジトリからインストールしました。

monitの便利なところとして、以下があげられる。

• プロセスの死活監視（ダウンしてくれれば、勝手に起動してくれるし、勝手に起動しない形も可能。DBなんかは勝手に起動して問題あるケースもあるよね？）
• 閾値と発砲の関連付け
• SMTPを使った発砲機能（リトライ機能もある）
• web管理画面

さらに、m/monitをつかえば、情報の集約も可能となる。

（有料だけど、買い切りでそれほど高くないのは、良心的）

クラウド環境では、かなりの監視ツールがあるが、

こねたことはできないので（できても意外に金がかかる。。）、

monit（もしくはm/monit）を併用すると、結構安心して夜も眠れる環境が出来そう。

どこかで、monitの設定を書いてみようと思う。

以上

ansibleのベストプラクティスを理解するのに時間がかかったが、

実案件の構築を通して、なんとなくわかってきた。

個人的な所感を表現すると、

「環境・特性・筐体ごとに役割を分割し、変数を割り当てる」

ということになる。

言葉で表すと、若干意味不明なので、例を書いてみる。

＜例＞

あるWEBサイトを作る場合、

サービス側と管理側でシステムが分かれるケースが多いだろう。

その場合、サービス側ではアクセスが多く、

参照が多いのであれば、DBに加えて、様々なキャッシュも併用する。

同時にwebサーバではkeepaliveを強くしたり、画像のキャッシュを行うこともあるだろう。

反対に、管理側では、アクセス人数が限られていることもあり、

キャッシュは使わないし、正確なデータ提供が求められる。

＜サービス側の構成＞

例えば、

• webサーバ2台　→　apache,phpが必要
• cacheサーバ2台　→　memcachedが必要
• dbサーバ2台（master、slave）　→　mysqlが必要

というようなケースを考えてみよう。

そして、

• 本番環境（production）
• 確認環境（staging）
• テスト環境（test）

という環境があるとする。

という状況において、

本番のインベントリファイルは以下のようになる。

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. servers-service.yml
2. env-service-production.yml
3. env-service-production-web.yml
4. env-service-production-cache.yml
5. env-service-production-db.yml

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より優秀なのではないか。