14Room

みんな泣きながらオトナになったんだ。

CloudFrontで使うためのSSL証明書をアップロードしてみよう

aws

2015/3/23時点でCloudFrontで使う証明書はCLIでしかアップロードできません。コマンドは下記の通り。

aws iam upload-server-certificate --server-certificate-name cdn.naked.com --certificate-body file://cert --private-key file://private --certificate-chain file://chain --path /cloudfront/path/
  • cert:証明書ファイル
  • private:秘密鍵ファイル
  • chain:中間証明書

cdn.naked.comの部分は環境に応じて適宜変更してください。

mysqlをサービス投入前にウォーミングアップしよう

mysql

概要

mysqlを再起動するとメモリに乗っていたデータがなくなり、そのままサービスに投入するとメモリにデータが載るまで負荷が高くなります。 そこでMySQL::Warmerを使ってサービス投入前にウォーミングアップしましょう。

インストール

apt-get update
apt-get install cpanminus
cpanm MySQL::Warmer

実行（ウォーミングアップ）

mysql-warmup target-db -h target-host -uYYYYYYYYY -pXXXXXXX

GCEでオートスケールを停止してみる

gce gcp

概要

デプロイのタイミングでオートスケールが発動すると色々困るので、止めます。

実行

下記のコマンドで停止可能。integration-201510290920はオートスケールを止めたいインスタンスグループの名前です。

gcloud compute -q --project "naked.co.jp:api-project-123456789" instance-groups managed stop-autoscaling integration-201510290920

結果

下記のようにオートスケールがoffになりました。

f:id:naked123:20151127172306p:plain

試しにstressコマンドで残りのインスタンスのCPUを使い切っても、インスタンスが追加されることはありませんでした。

ちなみにstop-autoscalingはあるけどstart-autoscalingはないです。 たぶんinstance-groups managed set-autoscalingで再設定し直せって事なんだろうと思いますが、その辺の意図は汲んでくれって感じがgoogleっぽいですね。

GCEでNATインスタンスを作ってみる

gcp gce

概要

GCPではexternal IPを持たないインスタンスはインターネットと通信できません。しかしDBサーバのようにセキュリティ的にexternal IPを持たせたくないけど、時々apt-getなどでソフトウェアを更新したい場合もあります。 そこで、NATインスタンスをdefault GWにして外からは直接アクセスできないけど、中からはインターネットにアクセスできる環境を作ります。

NATインスタンス構築

GUI

インスタンス内での作業

パケットフォワーディングを有効にする

sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

NATの設定をする sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

ルーティング設定

GUI

Routesで新しいルーティングルールを作成

Destination IP range:0.0.0.0/0
Priority:1000
Instance tags:no-ip
next-hop:specify an instance
Next hop instance:gw

ファイアウォール設定

no-ipのタグ付きインスタンスからgwタグ付きのインスタンス(NATインスタンス)への通信を許可する。

GUI

Firewall rulesで新しいファイアウォールルールを作成

Source filter:instance tagsを選択
Source tags:no-ip
Allowed protocols and ports:tcp:1-65535;udp:1-65535;icmp
Target tags:gw

確認

no-ipのタグがついたインスタンスからinternetに向けてpingを打ったり、apt-get updateしたりして確認しましょう。

GCEではquotasに気をつけよう

gce

EC2でもインスタンスの可能起動数に上限があるようにGCEにも色々なリソースに上限値が設けられてます。 オートスケールでインスタンスを大量に起動したりすると、この上限値にブチ当たり欲しいインスタンス数が確保できず、サービス影響が出る可能性があります。

f:id:naked123:20151009185023p:plain

そこで上記の図のようにCompute Engineのquotasを表示させてみると、各リソースが現在どのくらい使われているのかが確認できます。 ここを時々チェックして、自分のようにSSDのディスクが確保できずに本番でアタフタしないようにしましょう。

ちなみに上限に届きそうな場合は左上の「Request increase」をクリックして希望の数値を入力後、どんな風にGCEを使うのか説明を添えて申請しましょう。自分は毎回「GCE上で僕らのサービスを提供するため」みたいな感じでお願いしてます。

申請が終わると「Quota Increase Request For naked.co.jp:api-project-123456789」みたいな題名のメールが直ぐに届いて無事設定完了です。

GCEはOPB25

gce gcp

ぱっと見た感じ、意味不明なsubjectですね。 「OPB25」は「Outbound Port 25 Blocking」の意味で、スパムメールなどを撲滅するためにGCE環境から外部にメールを直接送れないように25番portを塞いでいます。

なのでGCE環境からメールを送信したい場合はport番号を変更して、外部のメールサーバを経由する必要があります。

GCEではinternal IPが任意に設定できない代わりに、内部DNSにホスト名が自動で設定される。

gce gcp

長いsubjectのとおり、GCEではインスタンスのinternal IPを任意に設定することは出来ません(EC2では出来ます)。internal IPはインスタンスを起動すると自動で割り振られます。

f:id:naked123:20150918160210p:plain

上の図のようにExternal IPは「static IP address」を選ぶことで同じIPを使い回す事ができますが、internal IPは最初に設定する事も途中で変える事もできません。

しかし、それだとAPPサーバから参照するDBのIP addressが変わるたびにAPPサーバの設定変更の必要が生じてしまい面倒です。

そこで、GCEではインスタンス起動時に設定した「Name」が自動的に内部DNSに登録されるのでIP addressではなく名前でアクセスすることをお勧めしてるみたいです。

$ nslookup master-db
Server:        169.254.169.254
Address:    169.254.169.254#53

Non-authoritative answer:
Name:    master-db.c.api-project-123123123123.naked.co.jp.internal
Address: 10.10.0.5

上記のように実際にインスタンスに入って確かめてみると、Nameで設定した名前が登録されています。 各インスタンスの/etc/resolv.confにもinternal関係の設定が最初から入っています。

分かってしまえば「なーんだ」って感じですが、自分はinternal IPを変更する方法を探して数時間右往左往してしまいました・・・・。