カテゴリー「gcp」

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   [コメントがあればどうぞ]

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

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   [コメントがあればどうぞ]

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   [コメントがあればどうぞ]

GCPとAWSで、拠点(リージョン)間の通信速度を簡単に図ってみた。

正確ではないし、3回程度しか実施していないので、その点は考慮ください。

 

■ComputerEngineのインスタンス(ASIA)から(AMERICA東部)への230MBのSCP

24秒

 

■EC2のインスタンス(TOKYO)から(AMERICA東部)への230MBのSCP

23秒

 

ほとんど同じ。

GCPはネットワークの強さをうたっているが、AWSと変わらないケースもある。

 

GCPの場合、ローカルネットワーク上で、異なるリージョンのインスタンスをまとめられるので、

データベースなどを複数リージョンで準同期レプリケーションできるとよいと思っていたが、

その目論見は成立しそうにないことがわかった。

 

ただし、GCPはグローバルロードバランサーとか、CloudStorageがめちゃくちゃ優秀だから、

実際にサービスとしてユーザの体感速度的なものは、広域範囲で考えればAWSより優秀なのではないか。

 

投稿日時:2016年05月27日 23:47   カテゴリー:aws, gcp   [コメントがあればどうぞ]

GCP(Google Cloud Platform)における、

Google Cloud Storage(以下、GCS)がすごい。

 

AWSでいうところのS3にあたるものですが、

バケット間同期が、

25,000ファイル、8GBを転送(同期)するのに、約5分。

驚異的。。

 

JAVAの並列処理(4CORE)で、

S3に同じ量をアップするのに、8分だったから、

ちょっと負けた気分。

 

なお、GCSはgsutilというツールを使うのがよい。

JAVAなどはSDKが出ているが、とてもめんどくさい。

 

gsutilは、gcloudの認証に影響を受けるようなので、

予めサービスアカウントを発行して、gcloudでの認証処理をしておくのがよい。

 

追記

ちなみに、上記の5分という数字は、

バケットのリージョンが異なっていても、同じでも変わらない。

つまり、AsiaからAmericaのバケット間転送でも超高速。

驚異的。。。

 

投稿日時:2016年05月27日 23:30   カテゴリー:gcp   [コメントがあればどうぞ]