2015年7月18日
から hiruta
Amazon Linuxのdocker イメージをGoogle Container Registryからpull・run #gcpja はコメントを受け付けていません

Amazon Linuxのdocker イメージをGoogle Container Registryからpull・run #gcpja

Amazon Linuxのdocker imageを作成し、Google Container Registryにアップロードを行い、

Amazon Linuxのdocker イメージを作成する方法については、http://dev.classmethod.jp/cloud/aws/docker-serverspec-configspec-ci/　を参照にしました。

AmazonLinux dockerイメージをローカルのdocker環境にインポートします。

# docker import < amazonssh.tar

# docker tag amazonssh asia.gcr.io/#your-project-id#/amazonssh

Google Container Registryにアップロードを行います。

# gcloud docker push asia.gcr.io/#your-project-id#/amazonssh
The push refers to a repository [asia.gcr.io/#your-project-id#/amazonssh] (len: 1)
Sending image list
Pushing repository asia.gcr.io/#your-project-id#/amazonssh (1 tags)

適当なVMインスタンスを起動します。GCSへのリード書き込み権限を付与することを忘れずに。

# gcloud compute instances create instance-test-docker --image centos-7  --scopes https://www.googleapis.com/auth/devstorage.read_write

dockerのインストール、起動

# yum install docker

# service docker start

asia リージョンのバケットにアップしたので、gcr.ioで見つからないとエラーとなります。

# docker pull gcr.io/your-project-id/amazonssh
Trying to pull repository gcr.io/your-project-id/amazonssh ... not found
FATA[0000] Error: image your-project-id/amazonssh:latest not found

Google Container Registryからdocker イメージを取得します。

# docker pull asia.gcr.io/your-project-id/amazonssh
Trying to pull repository asia.gcr.io/your-project-id/amazonssh ...
3fe81e712d9e: Download complete
a09fe07f3274: Download complete
81bcdeaea41c: Download complete
7ad48843769c: Download complete
9b15589bc305: Download complete
48fc49b0c3fa: Download complete
25a9a1b3f0d0: Download complete
cbfa77630235: Download complete
76ab5065c4b2: Download complete
Status: Downloaded newer image for asia.gcr.io/your-project-idamazonssh:lat

docker イメージがpullできていることを確認できます。

# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
asia.gcr.io/your-project-id/amazonssh latest 3fe81e712d9e 2 weeks ago 874.1 MB

docker containerを起動

# docker run -h amazonssh -t 3fe81e712d9e /bin/bash
Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5534906edb50 3fe81e712d9e:latest "/bin/bash" 17 seconds ago Up 16 seconds 22/tcp agitated_fermi

GCEでAmazon Linuxの環境を構築することも可能となります。

Container-Optimized Compute Engine Instancesでインスタンス起動時にContainer Registryから取得して、Containerを起動することも可能ですが、こちらについては、別途機会に。

2015年6月23日
から hiruta
EFS(Elastic File System)のスナップショットオプションはない？はコメントを受け付けていません

EFS(Elastic File System)のスナップショットオプションはない？

Elastic File SystemのFeedback（バックアップについて）を送ったら、下記回答が得られました。

We do not currently have a “snapshots” feature, but you can use standard file system tools and practices such as performing an rsync to another file system, running a script to take regular rsync-based differential backups, creating ad-hoc copies of individual directories, using third party backup tools, etc. to protect your data against logical corruption.

EFSは、snapshotsは対応していないとのこと。rsyncのような標準のシステムツールでバックアップするてことになる模様。サードパティ用のバックアップを併用するのがいいようです。

ある時間から復元するようなことはできない。バックアップの設計は別途必要か。

2015年6月18日
から hiruta
GCP Next Tokyoに参加してきました。 #GCPNext はコメントを受け付けていません

GCP Next Tokyoに参加してきました。 #GCPNext

6/18 (木）に、六本木ヒルズ（アカデミーヒルズ49F)で行われた GCP Next Tokyoに参加してきました。GCP Nextはニューヨーク、サンフランシスコ、東京、ロンドン、アムステルダムで開催される世界規模のGCPのイベントになります。

GCP Next自体何年か前から開催されていましたが、当初は、40名程度でしたが、今年は、キーノート会場は満席、立ち見もある盛況ぶりでした。

HTC様のGCPを使った事例

デバイスの同期
デバイスの更新周期3年
デバイスを超えてアプリケーションを実行
少ない帯域でアプリケーションに対応
DCのレプリケーション
距離的に近いDCを選択
接続障害に対する耐性
アプリケーションは切断しても続行

上記課題に対して、GCPを使うことでどう解決したかの話

バージョンコントロール
push通知クライアント同期
差分だけを転送する

Googleの技術サポートはエンジニアが対応するので、きめ細かな対応も評価しているとのこと

pwc

消費型モデルをどう構築するか

GCPを選択した理由
分析の部分
重要な部分を担っている。セキュア、全体のトレンド
世界中にスケールするインフラが必要
今プランを策定しないと間に合わない

クラウドプラントフォーム一連のサービスがまとまっているもの

70 エッジローケーション
33カ国

レイテンシーの信頼性の高いネットワーク
500人のセキュリティエクスパート
ミッションインポッシブルの技術レーダーによる侵入検知
データを傍受して読むのも不可能

Broadleaf

なぜGoogleをインフラとして選択したか

当初は、自社のDCを構築
40,000万社を接続してコントロール
ネットワークで卸、工場を接続

AWSも検討したが、GCP上での動作実績のあるMEGALLANのミドルウェアがあるため、GCPを採用

Gooogleの方が拡張性に優れている、大量トランザクションに耐えうる。

こちらでも、サポートが優れている。通常では対応してくれないこともしてくれる

GCP移行後は、システム停止も発生していないとのこと（ライブマイグレーションなどメンテナンス不要にする機能も使えます。）

Groovenauts

最も速く、最も協力で最も質の高いクラウドプラットフォームで構築してきました。
くみ上げていく運用する時代の終焉
新しいビジネスに集中もできる。

クラウドは、やめるのも、使い続けるのも可能。新しいイノベーションも生まれやすい。

ここまでの午前中の部（キーノート）

午後は、ビジネストラック、デベロッパートラックに分かれてセッションがランチを挟んで続きました。

両者のうち、ビジネストラックを選択しました。

Engine入門

AppEngineは、PaaSの名もまだの時代に生まれたサービス。

Container Engineは、VMの依存性を解決するが、コンテナ間通信、セットアップ、ホスト間移動の課題を解決するために生まれた。

Compute Engine、i2.xlargeとn1-highmem-4を比較して、GCPのコストパフォーマンスの良さが話された。

Fastlyでは、リバースプロキシVamishを使って、4万リクエストを裁いてしまう。

Compute Engine自体インスタンス起動も秒単位。(AWSだと数分かかる)

クラウドネットワーキング

長年15年投資してきた。光ファイバー
GCPは新しいけど、インフラは長年やってきました。

SDN
どこでもベストパフォーマンスが得られる

Direct Peering

PGP Peering

Private network 相互接続
公共インターネットを経由しない
パフォーマンスも予測しやすい
揺らぎに依存もしない

Carrier Interconnect

Service Providerを介してPeeringなしで接続

Equinix

Equinix Performace Hub

ISP, NSP
自分のキャビネットから
往復の遅延は低い
セキュリティ、コンプライアンスも維持

ビックデータ

データの世界がチェンジ
量が爆発的に増加ログファイル、エンドポイント、デバイス
アーカイブも
データが10倍に

320億のIoTデバイス
リアルタイムでキャプチャしないといけない
クラウドベースのコンピューティング

ビックデータは複雑

Google NoSQLの導入したけど

Map Reduceでリーズナブルに分析ができない
コンピューティングリソースも必要
チャンスもあるけど、活用できない問題も
より使いやすくする

70%はインフラ構築等などに時間を費やしている

データをコンバージョンするときに時間を使えるようにする

経年劣化
速く使えばデータの可視も

SUNGARD、DeNAの事例について。

Tableau

当初はデータの可視化を目指す
自分でデータを見て、理解することを手助けるのがTableauの会社創立の使命とのこと
だれでも簡単にデータを分析することを目指す。

数字は瞬時に理解することはできない
グラフにして初めて理解できる。

Tableau Onlineは、Tableau Desktop、Tableau ServerのようにChorme、Safari等ブラウザ以外一切ソフト導入が必要としない。分析とかも問題なく利用可能。

年間サブスクリプション価格が、破格の60,000円。（支払いは年間一括。月額は現状ないが、検討してもらいたい）

Tableauは、CloudSQLに接続することも可能。※credentialsには気をつける。tableauのデモの際にも、BigQueryに接続できないことがあった。

管理（Cloud Monitoring + Logging )

70%はメンテナンスの維持に使われている
イノベーションしたいとしても10%以下の現実

Cloud Monitoringはメンテナンスの手助けをしてくれる。

AWSでできないことも、GCPだと解決できることもあることがより実感できるイベントでした。

2015年5月28日
から hiruta
【Preview Service】Amazon Aurora ファーストインプレッション #jawsug はコメントを受け付けていません

【Preview Service】Amazon Aurora ファーストインプレッション #jawsug

昨年末のre:Inventで発表されたAmazon Auroraが八ヶ月ほどでようやく使用できるようになりました。

provison 3 (リリースバージョン？）が使用できるようになりましたので、Amazon AuroraをManagement ConsoleからLaunchしてみました。

使えるようになったAuroraのバージョンでは、preview専用画面ではなく、他のRDSエンジンと統合されています。

対応インスタンスは、db.r3.largeとdb.r3.xlargeのみ。（これしか選択できない）

現在のRDS ( MySQL )とは、Multi-AZの概念が少し異なっています。Master & Replica で構成されます。現在では、Read Replicaは別途Launchするが、Auroraは、Multi-AZで、Crearte Region in Different Zoneを指定すると、初期構築時に作成されます。

Provisoned IOPS、gp2かディスクストレージは明示的に設定できないようです。また、マイナーバージョンの指定がなくなっており、シンプルになっています。

初回時バックアップの時間指定がない。バックアップ時間は、04:05 – 04:34で登録されるようです。

Multi-AZ構成にすると、Master/ReadReplicaが明示的に表示されます。Master 2Zone、ReadReplica 2Zoneを使用するようにみえる。3AZ（1 AWSアカウントでは事実上2AZしか使えない）しかない東京リージョン対応の際、どのようになるのか。

FailoverがRebootとは別に項目が追加されています。

RDS Event SubscriptionももちろんAuroraでも対応しています。Event Subscriptionのカテゴリは別段変わっていない模様。

AWS CLIからはまだ未対応ですので、作成はManagement Consoleのみとなっています。

細かい点はのちほど。

2015年5月20日
から hiruta
【新サービス】Preemptible VM発表！ #gcpja はコメントを受け付けていません

【新サービス】Preemptible VM発表！ #gcpja

昨日リリースされたPreemptible VMを使用してみました。（最大40%のGCE料金値下げも発表）

Preemptible VMは、Googleの余剰インフラを格安で使用することができます。使用制限事項があるので、留意して使うのが必要になります。

システムイベントによりシャットダウンされる場合がある
24時間でterminateされる
Googleインフラに余剰がある場合は使えるが、いつも使えるとは限らない（余剰リソースが使えない場合は使用できない）
Live migration　はできない

上記条件以外は通常のインスタンスで使用できるようです。使うには、WebUIかgcloudから。

Web UI

gcloudコマンド

gcloud compute instances create instance-1 --machine-type n1-standard-1 --zone us-cent
ral1-a --image hogehoge-image --network product-network --preemptible

n1-standard-1インスタンスの場合、通常$0.055のところ、＄0.0165で利用できます。

https://cloud.google.com/compute/pricing#machinetype

AWSにもスポットインスタンスが、変動価格のインスタンスに対し、Preemptible VMは、定額型スポットインスタンスというところ。（スポット価格を設定しないところがいい）

Preemptible VMのユースケースとしては、多量に並列処理するような計算サーバー、24H以内で終了されるバッチ処理などに使用できると思われます。 Google Dataflowなど。

HadoopでPreemptible VM使えるようにできる模様。

gclooud compoents repositories に、標準リポジトリ以外が登録されていると、gcloud compute commandがアップデートできないので、注意が必要。

2015年5月16日
から hiruta
第二回 GCPUG Tokyo に参加しました。 #gcpug はコメントを受け付けていません

第二回 GCPUG Tokyo に参加しました。 #gcpug

昨日、第二回 GCPUG Tokyo に参加しました。GCPUG Fukuokaと被るFirebaseについては割愛。別ブログ記事に記載してあるので、そちらを参照ください。

新しいストレージサービス Cloud BigTable

Googleのインターナルなサービス、GMail、youtube等、に使われている Key-Value型データベース。

Cloud BigTableを利用して、GCPの1サービスとしてCloud storeが稼働している

Tableserver failureも、1秒で復旧。ユーザが認識しなくていいリカバリ。

Managed Service No SSH、No VMインスタンス

AWSのDynamoDBににているサービスとのこと

HBase Client互換。HBaseのシステム構成に似ている。

現時点（ベータ）では、SDD Storageのみだが、HDD Storageにも近日対応とのこと　※HDD Storage $0.036/GB-Month)

ユースケース　IoT、マーケティング、金融、エネルギー、通信

Cloud Dataflow

ノード数が計算に必要な分だけVMインスタンスを起動してくれる。※インスタンスタイプとかは指定できるとのこと

デモでは、VMインスタンスが自動で上がってきている点、BigQueryにデータが入っている点を行われていました。

Cloud Dataflowに似ているものに、Kinesis KCLアプリケーションがあるが、Consumer(ノードに相当）がスケール処理は別途考慮が必要なので、Cloud Dataflowの方がサイジングとか低減が図れるのではと思いました。

GCPで知られていない便利な機能の紹介

Goolge Cloud Registory

Git リポジトリ。Githubとかとの同期もできる模様。/　にコードがないとリンクが張られないいけていない。今後の改善には期待したい。

Push To Deploy ( Release pipline )

jenkinsを起動してねの一文が書いてあるだけのページになっている

Goolge Cloud Trace
Cloud Debugger
Google cloud Respositories

docker のprivate respositoryをGCSをストレージとして作成できるサービス。

Google Metadata Server

AWSに同様のものがあるが、こちらのほうが高機能。etcdよりは劣る。

metadataに関して、個人的に記載したものを記載しておきます。（http://qiita.com/web_se/items/b129d13cdf76b07bb1f1 )

startup script / shutdown script

VMインスタンスを起動時、シャットダウン時に読み込ませるスクリプト。AWSだとuser-dataに相当。AWSのuserdataと異なる点は、GCSにスクリプト本体を置いておき、ロードさせることが可能な点。

過去個人的に記載したものを記載しておきます。( http://www.totalsolution.biz/startup-script%e3%80%81shutdown-script-gcpja/ )

AWS Simple IconのようなサービスのIcon集の公開が望まれる。（現在パートナー企業のみ限定公開されているとのこと）

2015年5月14日
から hiruta
【新サービス】S3 VPCエンドポイント発表！ #jawsug はコメントを受け付けていません

【新サービス】S3 VPCエンドポイント発表！ #jawsug

http://aws.typepad.com/aws_japan/2015/05/vpcendpointfors3.html　にリリースされたS3 VPC エンドポイントを検証してみました。

今までのEC2からS3にアクセスするパターン

VPC End Pointを利用したS3のアクセスパターン

VPC Endpointを作成する際、ルート情報を自動で入れることが可能です。作成の際、以下にチェックを入れます。

ルーティングテーブルに以下のように登録されるのがわかります。下画像から東京リージョンのS3のエンドポイントにルートが設定されているのがわかります。

環境は以下で実施

AmazonLinux 2015.03 (HVM)
インスタンスタイプ m3.medium
リージョンはEC2、S3とも東京リージョンとする

1G ダミーファイルをS3にPUTをAWS CLIを利用して、3度ずつ実施

VPCEndpoint経由で検証した際、curlでHTTP通信ができないことを確認

パターン	1回目	2回目	3回目
IGW経由	28s	33s	33s
VPCEndpoint経由	29s	28s	29s

IGW経由とほぼ変わらない、極端に早くなることはなかった。

DB on EC2などIGWを付けないVPCでサーバーのログをS3に退避するとき、IGWの負荷を下げるなどで活用できるのではと思われます。

V~~PC Endpointを設定できる AWS CLIのコマンドはまだ公開されていない模様。~~

aws cli 1.7.27で対応。

<pre>  create-vpc-endpoint
[--dry-run | --no-dry-run]
--vpc-id <value>
--service-name <value>
[--policy-document <value>]
[--route-table-ids <value>]
[--client-token <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton]</pre>

2015年5月10日
から hiruta
AWS EC2とGCEを比較してみましたはコメントを受け付けていません

AWS EC2とGCEを比較してみました

AWS EC2とGCEを比較してみました。

インスタンスタイプ

AWS EC2の方が提供されているインスタンスタイプは多いが、n1-standard-1レベルでi2レベルのパフォーマンスが出るとここと。(→ここを参照)

AWS EC2			GCE
Type	mem	price	Type	mem	price
汎用インスタンス※お試しインスタンス
t2.micro	1	0.02	f1-micro	0.6	0.013
t2.small	2	0.04	g1-small	1.7	0.0347
t2.medium	4	0.08
標準インスタンス
m3.medium	3.75	0.101	n1-standard-1	3.75	0.069
m3.large	7.5	0.203	n1-standard-2	7.5	0.138
m3.xlarge	15	0.405	n1-standard-4	15	0.276
m3.2xlarge	30	0.810	n1-standard-8	30	0.552
			n1-standard-16	60	1.104
コンピューティング向最適化インスタンス
c3.large	3.75	0.128	n1-highcpu-2	1.8	0.086
c3.xlarge	7.5	0.255	n1-highcpu-4	3.6	0.172
c3.2xlarge	15	0.511	n1-highcpu-8	7.2	0.344
c3.4xlarge	122	1.0211	n1-highcpu-16	14.40	0.688
c3.8xlarge	244	2.043
メモリ最適化インスタンス
r3.large	15.25	0.210	n1-highmem-2	13	0.162
r3.xlarge	30.5	0.420	n1-highmem-4	26	0.324
r3.2xlarge	61	0.840	n1-highmem-8	52	0.648
r3.4xkarge	122	1.680	n1-highmem-16	104	1.296
r3.8xlarge	244	3.360
ストレージ最適化インスタンス
i2.large	30.25	1.001
i2.xlarge	61	2.001
i2.4xlarge	122	4.002
i2.8xlarge	244	8.004

揮発性ディスク

AWS	GCE
インスタンスストア	LocalSSD

インスタンスストアとLocalSSDのパフォーマンスを以前取得してみたページはここ　を参照

LocalSSDは、300GB　x1からインスタンスタイプによる制限なく利用できる

可用性

AWS	GCE
EC2 Auto Recovery	Liveマイグレーション
インスタンスストア付インスタンスには対応していないイベントキックがCloudWatch	バックで動作する

GCE　Liveマイグレーションについては、http://qiita.com/kazunori279/items/41520689337a644a87b4 に書かれています。

AutoScaling

AWS	GCE
AutoscalingGroup AutoScalingLaunchConfiguration	インスタンスグループインスタンステンプレート AutoScaler
	Rolling Updateテンプレートからスタートアップスクリプトを分離することができる

ネットワーク

AWS	GCE
リージョン、ゾーンを意識	リージョン、ゾーンを意識しないリージョンが異なるインスタンスに同じPrivate IP CIDRを割り当てることができる

ファイアウォール

AWS	GCE
EC2ごとに最低1つのSecurity Group	ネットワークに１つ

負荷分散

AWS	GCE
ELBinternalなクローズなロードバランサーが作成可	HTTPロードバランサHTTPロードバランサーに割り当てられるIPがGoogleUSが保持しているIPが割り当てられる暖気無で100万リクエスト/秒を裁ける性能

料金割引

AWS	GCE
最低1年のRIを契約が要途中契約が不可。（USの銀行口座がある場合は売却が可能）	事前契約無の長期継続割引（月単位も可能）

2015年5月6日
から hiruta
startup-script、shutdown-script について #gcpja はコメントを受け付けていません

startup-script、shutdown-script について #gcpja

インスタンス起動時にサーバー固有の設定を行うのに、startup-script(cloud-init？)という機能があります。

スタートアップスクリプト、シャットダウンスクリプトをinstance-template等で以下で指定できます。AWSだと、userdata scriptが相当しますが、AWSの場合、Launch Configrationに組み込まれてしまっており、userdata scriptを変更する際、Launch Configrationの作り直しが必要だが、GCEではGoogle Cloud Storageなど、instance-templateから分けることができますので、scriptだけ変更することも可能。anoymous accessを使うため、Google Cloud Storageにscriptを置く際、public-readできるようにしておく必要があります。→ここ

また、shutdown-scriptは、AWSだとAutoScaling lifecycle hookに相当するものと思われます。

--metadata startup-script-url=gs://h-XXXX-XXXX/startup.sh shutdown-script-url=gs://h-XXXX-XXXX/mackerel-retire.sh

登録されると、WEB UI等に下記のように確認することができます。

画面(上記のSerial console output)、CLI commandでstartupscriptのログを確認することができます。コンソール出力だと「startupscript:」の行がスタートアップスクリプトのログになります。

gcloud compute instances <instance id> get-serial-port-output instance-1

クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。