IT系のめもを蓄積していこうかと
Google Computer Cloud（以下、GCP）で、
グローバルロードバランサの背後にnginxを置く場合は、
keepaliveをしておこう。
（参考）
https://blog.percy.io/tuning-nginx-behind-google-cloud-platform-http-s-load-balancer-305982ddb340
これやっておかないと、結構502がでる。
ちなみに、650秒をkeepalive_timeoutにするなら、
ロードバランサのタイムアウトは600秒程度、つまり少し短めがよいとのこと。
実は、AWSのELBも同様。
とはいえ、結構な高負荷にならないと、本事象は目立ってこないので、
なかなか難しいところである。
以上
Google Computer Engineにおいて、
いつの間にか、google-cloud-sdkのインストール方法に変更があった。
古いインスタンスと、新しいインスタンスで操作方法が異なってしまったので、
備忘録として残しておく
（古いインスタンス）
最初から、google-cloud-sdkがはいっており、
gcloudコマンド等が使えた。
そして、
# gcloud components update
が実行できた。
→ おそらく、これはマニュアルにある、install.shを実行したやつなのだろう。
（新しいインスタンス）
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になったのに、
日本語マニュアルを見ると未だにベータ版って記述残ってるし。。
このあたりしっかりやって欲しいわ。。
ここ最近、インフラ寄りの話ばかりであるが、
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の残念なところは、現状キャッシュされているものの情報や、ヒット率等の統計が取れないところである。
しかし、何度も書いたように、開発者（もっといえばコンテンツ開発者）にありがたいインフラ構成というのは、特筆すべき点かと思われる。
以上
GCPからのメール送信というと、
などがよく出てくるが、
SendGridを使うほどではなく、
たまにアラートなどで使いたい場合に、
上記どちらの方法もやりにくい。
実際にrubyスクリプトから、SMTP接続してメール送信をするケースにおいて、
どうもSMTPリレーが上手くいかなかった（Postfixでちゃんとリレー設定しないと難しいのかな？）ので、
アプリパスワードを発行して、GoogleAppsへSMTP接続すれば、無事送信できることが確認できた。
詳しくは以下。
https://support.google.com/mail/answer/185833?hl=ja
最近はwebhookなども通知に使われるが、
やはり入れておきたいメール通知。
以上
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のバケット間転送でも超高速。
驚異的。。。