技術めも

google-cloud-sdkがyumでインストールするようになっていた

Google Computer Engineにおいて、

いつの間にか、google-cloud-sdkのインストール方法に変更があった。

古いインスタンスと、新しいインスタンスで操作方法が異なってしまったので、

備忘録として残しておく

（古いインスタンス）

OS：CentOS Linux release 7.2.1511 (Core)
構築日時：2016年3月ごろ

最初から、google-cloud-sdkがはいっており、

gcloudコマンド等が使えた。

そして、

# gcloud components update

が実行できた。

→　おそらく、これはマニュアルにある、install.shを実行したやつなのだろう。

（新しいインスタンス）

OS：CentOS Linux release 7.2.1511 (Core)
構築日時：2016年12月ごろ

gcloudコマンドが最初から使えない代わりに、

yumでインストール可能となっていた。

このインストール方法だと、

# gcloud components update

が実行できなくなっていた。

→　いつの間にか、/etc/yum.repos.d/google-cloud.repoファイルに、

google-cloud-sdkのセクションが追加されていた。

というわけで、

古いインスタンスの/etc/yum.repos.d/google-cloud.repoファイルを以下のように変更。

[google-cloud-compute]
name=Google Cloud Compute
baseurl=https://packages.cloud.google.com/yum/repos/google-cloud-compute-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

そして、

# yum install -y google-cloud-sdk

を実行し、最新のsdkをインストール。

・・・すれば行けるはず。

↑はまだ実行してないんだけどね。。

ひょっとしたら、古いgcloudを削除する必要ありそう。。

GCPは変更があっても、

マニュアルの反映が遅かったりして、ちょっとわかりづらいわ。。

stackdriverだって、2016年10月にGAになったのに、

日本語マニュアルを見ると未だにベータ版って記述残ってるし。。

このあたりしっかりやって欲しいわ。。

投稿日時：2016年12月11日 00:06 カテゴリー：gcp

CloudCDNについて

ここ最近、インフラ寄りの話ばかりであるが、

GooglePlatformで使えるCloudCDNについて書いておく。

CloudCDNはawsのcloud frontなどとは違い、

ロードバランサーの一機能として利用できる。

特徴としては、

ロードバランサーと同一ドメインで利用できるところである。

イメージ的には以下のようになる（実際は違いますけど。。）


    user <--> load balancer <--> cloud cdn <--> vm instance

この構成のよいところは、オリジンであるVMインスタンス（awsでいえばEC2）に置いてあるキャッシュさせたいコンテンツを、

ロードバランサーと同じドメインで取得できるところである。

そのため、VMインスタンスに画像等を丸々配備できるため、開発者がインフラを意識する必要がなくなるということだ。

これに対し、他CDNの場合、キャッシュさせたいコンテンツを他ドメインから取得させるよう、

HTMLをコーディングする必要がある。

しかし、CloudCDNなら、それを意識する必要はない。

これは開発者から見ると非常に大きな利点である。

（awsのcloud frontのL7機能でキャッシュの有無を調整することは可能だが、キャッシュさせないコンテンツでも瞬間的にはキャッシュされるので、

一意URLによるGETなどはあらかじめ注意して開発する必要がある）

ただし、HTTP/1.1の場合、同一ドメインから同時にアクセスできるURL数というのはブラウザで制御しているため、

実際には様々なドメインから取得させた方がユーザへの体感速度の向上が図れるのは周知の事実である。

（HTTP/2ではこの問題も多少はマシになるとは期待してますが、、）

ただ、CloudCDNの残念なところは、現状キャッシュされているものの情報や、ヒット率等の統計が取れないところである。

しかし、何度も書いたように、開発者（もっといえばコンテンツ開発者）にありがたいインフラ構成というのは、特筆すべき点かと思われる。

以上

投稿日時：2016年10月17日 00:54 カテゴリー：cdn, gcp

fastlyについて書く

以前の記事で、CDNについて書いてみようかなということにしていたので、

次世代CDNとうたわれるfastlyについて書いてみる。

fastlyの最大の特徴は、

0.5秒で世界中のキャッシュを消す

というインスタントパージ機能である。

これはほんとにすごい。

他のCDNでは実現できていない高機能である。

実際にキャッシュが消えたかを確認するには、

キャッシュを消す前後で、以下APIをたたいてHASHを確認することができる。

https://docs.fastly.com/api/tools#content

実際にHASHは異なっていたし、キャッシュも消えていた。

もうひとつfastlyはすごいと思ったことがある。

それはキャッシュしなかった場合でも、

選択される回線の速度が非常に速い。

実際にルータのホップ数などを見ても、とても少ない。（そのため、オリジンとfastly間の転送料金が高めだが）

広域にコンテンツを展開したいとき、

非常に有効なCDNだと思われる。

以上

投稿日時：2016年10月17日 00:26 カテゴリー：cdn

awsのIPv6対応状況

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対応していたので、近いうちにもろもろ対応してくれるだろう。

以上

投稿日時：2016年10月17日 00:07 カテゴリー：aws

nginxのipv4とipv6、non-sslとssl

以前の記事で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対応も入れたいというケースはこのような対応となるだろう。

以上

投稿日時：2016年10月16日 23:52 カテゴリー：nginx, server

GoogleComputerEngineからのメール送信

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

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

などがよく出てくるが、

SendGridを使うほどではなく、

たまにアラートなどで使いたい場合に、

上記どちらの方法もやりにくい。

実際にrubyスクリプトから、SMTP接続してメール送信をするケースにおいて、

どうもSMTPリレーが上手くいかなかった（Postfixでちゃんとリレー設定しないと難しいのかな？）ので、

アプリパスワードを発行して、GoogleAppsへSMTP接続すれば、無事送信できることが確認できた。

詳しくは以下。

https://support.google.com/mail/answer/185833?hl=ja

最近はwebhookなども通知に使われるが、

やはり入れておきたいメール通知。

以上

投稿日時：2016年08月15日 23:14 カテゴリー：gcp

cloudfrontを利用してみた

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についても、機会があれば書いてみようと思います。

以上

投稿日時：2016年08月13日 23:36 カテゴリー：aws, cdn

muninでMariaDBの監視

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でも問題なく動いた。

以上

投稿日時：2016年07月29日 23:20 カテゴリー：mariadb, rdb, server

redis3でコマンドアシストがあった

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

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

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

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

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

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

以上

投稿日時：2016年07月29日 23:11 カテゴリー：redis

monitってすごいわ

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

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

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

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

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

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

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

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

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

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

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

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

以上

投稿日時：2016年07月11日 00:46 カテゴリー：server

カテゴリー

アーカイブ