クラウドインフラ構築記

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

2015年8月30日
から hiruta
GKEのコンテナをDatadogで監視 はコメントを受け付けていません

GKEのコンテナをDatadogで監視

3-datadog-docker

※glcoud compoents updateでCloud SDKを最新にしておきます。

GKEクラスタを作成

 

gcloud container clusters create test-cluster --zone asia-east1-a --machine-type g1-small --num-nodes 1 --network stage-network

指定しないと、n1-standard-1とクラスタノード数3で起動します。

gcloud containers コマンドのデフォルトクラスタを「test-cluster」に設定します。

gcloud config set container/cluster test-cluster

kubectlとの連携

gcloud container clusters get-credentials

作成したクラスタの確認

gcloud container clusters describe test-cluster --zone asia-east1-a

作成するコンテナ用jsonを作成します。jsonだけでなく、yamlでも作成可能です。

{
 "kind": "Pod",
 "apiVersion": "v1",
 "metadata": {
 "name": "nginx",
 "namespace": "default"
 },
 "spec": {
 "containers": [
 {
 "name": "nginx",
 "image": "nginx",
 "imagePullPolicy": "Always",
 "ports": [
 {
 "containerPort": 22,
 "name": "ssh",
 "protocol": "TCP"
 }
 ]
 }
 ]
 }
}

Pods (Containers)を作成します。

kubectl create -f nginx.json
kubectl describe pods nginx

コンテナを削除する場合は、以下コマンドで完了。

kubectl delete -f nginx.json

作成したコンテナを確認します。Node Clusterも確認できます。Datadog Agentをインストールする際、sshログインする必要があります。

kubectl get pods nginx -o wide
NAME READY STATUS RESTARTS AGE NODE
nginx 1/1 Running 0 -340s gke-test-cluster-919cf59d-node-zgrc

Containerが起動すれば、Runningになるかと思います。内部的にイメージになんらか問題が生じて、Containersが起動できなくなっているケースもあります。Node Cluseterにログイン後、docker ps -aで、Containerは確認できます。(Datadogを使えば、コンテナの状態も確認できると思われます。)

Datadogに登録

Datadogの登録は割愛します。


 

ホストサーバーにDatadog Agentをインストール

Datadogのダッシュボードにある左メニューのIntegrationのAgentを選んで、「Debian」を選択します。 すると1行ペラっとコマンド出てきますから、それをコピーします。

DD_API_KEY=XXXXXXXXXXXXXXXXXXXXXXX bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)"

 

ホストサーバーからDocker Agentをインストール

IntegrationのAgentを選んで、「CoreOS」を選択します。

docker run -d --name dd-agent -h `hostname` -v /var/run/docker.sock:/var/run/docker.sock -v /proc/mounts:/host/proc/mounts:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e API_KEY=XXXXXXXXXXXXXXXXXXXXXXX datadog/docker-dd-agent

Docker 用監視ファイルの設定

サンプルのdocker用yamlファイルが置かれているので、リネームして、agentを起動します。


cp /etc/dd-agent/conf.d/docker.yaml.example /etc/dd-agent/conf.d/docker.yaml
dd-agent start

2015年8月16日
から hiruta
CloudSQLについて、TPC-Cベンチマークしてみました。 #gcpja はコメントを受け付けていません

CloudSQLについて、TPC-Cベンチマークしてみました。 #gcpja

Amazon Auroraに引き続き、CloudSQLのベンチマークを測定してみました。Cloud SQLに、Amazon Aurora相当のインスタンスタイプがないので、厳密な比較はできませんが、参考程度に。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。
ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

Table Record
customer 480000
district 160
item 100000
new_orders 144000
order_line 4799437
orders 480000
stock 1600000
warehouse 16

CloudSQLは以下の状態で行いました。

インスタンスクラス DB Engine version 備考
D8 5.6.26 Engineのバージョンは明示的には指定不可

メモリ4G※CPU情報については公開されていませんので、コア数は不明。mysqlのバージョンもmysqlに接続して確認。gcloudとDeveloper Consoleから確認はできない。

測定用インスタンスは、CloudSQLと同じリージョンにあるpreemptible VM (n1-standard-1)で。

検証用とかにPreeemtible VMお得で便利です。

結果

多重度 Throughput(tps) Response time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level New-Order Payment Order-Status Delivery Stock-Level
1 6.3 6.3 0.6 0.6 0.6 125 56 10 174 6
4  16.7  16.7  1.7  1.7  1.7  198  146  10  245  6
16  43.1  43.1  4.3  4.3  4.3  377  290  10  397  7
32 59.7 59.7 6.0 6.0 6.0 556 335 16 555 13

Cloud SQLは、IPv6にも対応、Repliaなどにも対応しているので、今後期待できるサービスです。

Cloud SQLはGCEのネットワークに配置することができないので、今後改善してほしいところ

2015年8月16日
から hiruta
Amazon Auroraをベンチマークしてみました。 はコメントを受け付けていません

Amazon Auroraをベンチマークしてみました。

Amazon Auroraのベンチマークを測定してみました。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。
ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

Table Record
customer 480000
district 160
item 100000
new_orders 144000
order_line 4799437
orders 480000
stock 1600000
warehouse 16

RDSは以下の状態で行いました。

インスタンスクラス DB Engine version 備考
db.r3.xlarge Aurora 5.6.10a Engineのバージョンは明示的には指定不可

RDSと測定用クライアント(r3.xlarge)は別AZに配置。

結果

多重度 Throughput(tps) Response time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level New-Order Payment Order-Status Delivery Stock-Level
1 9.9 9.9 1.0 1.0 1.0 93.20 20 10 113 7
4 37.9 37.9 3.8 3.8 3.8 95 22 10 116 8
16 129.2 129.2 12.9 12.9 12.9 107 32 12 131 9
32 198.3 198.3 19.8 19.8 19.8 133 66 14 163 13

 

多重度 CPU使用率 DiskQueueDepth(Count)
1 10% 9
4 30% 16
16 80% 13
32 92% 25

まとめ

多重度1でquery_cache_typeを変更して測定してみましたが、on/offの差は見られませんでした。

また、RDSと測定用クライアントを同一AZに配置した場合に比べて、3割程度の性能劣化が見られました。

以下は、測定用クライアントとRDSが同一AZにあった場合の結果になります。

多重度 Throughput(tps) Response time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level New-Order Payment Order-Status Delivery Stock-Level
16 195.5 195.6 19.6 19.6 19.6 67 27 7 91 9

 

2015年7月28日
から hiruta
July Tech Festa 2015に7/25参加しました。 #jtf2015 はコメントを受け付けていません

July Tech Festa 2015に7/25参加しました。 #jtf2015

7/25 産業技術大学院大学で行われた July Tech Festa 2015に行ってきました。

以下のセッションに参加しました。

IoT時代のデバイスクラスタHashicorp consulを用いたIntel Edisonクラスタの構成

fogとクラウドどう役割分担させるのがポイント。fogはリアルタイムの処理を行い、クラウド側では大量データ蓄積、分析・学習に利用する。

実際構築したシステムの技術の解説。MQTT、Wi-Fi Mesh Network、Consul

MQTTは、TLSで暗号化が推奨。

Wi-Fi Mesh Networkは、SPOFにならないとか良い点もあるが、デフォルトカーネルでは動かず、カーネルビルドが要。→

Consul 運用自動化ツール。Wi-Fi  Mesh Networkと相性が良い。Go 1.4 x86 32bitのバイナリで動かせる。

真剣にDocker運用を考える人に、各種監視ツールとサービスを比

Dockerの監視を自作(DIY)で、それとも、SaaSの監視サービスでまかないか。

Docker  Containerの監視粒度は、1回/5分では不十分。1データ/1秒、一年間保存位しないとNG

CloudWatchの監視粒度とかではDocker Containers監視は不十分ということに。

Docker Containers監視を自作(DIY)で求められる監視粒度が満足できればいいが、そうは簡単ではない。

SaaS系の監視サービスだと、サービス終了した場合はどうするか個人的には気になる。

New Relic、App Dynamics、Mackerel、Signakfx、libratoについて、一丁一端がある。

DatadogがDocker Containers監視については現状ベストとのことに。

今話題のAnsibleのモジュールをゼロから自分で作ってみよう

標準で提供されているモジュールだけでも十分だが、かゆいところまでしたい場合はモジュールを作成する。

本当に足りない機能をモジュールで作成するのがいい。(今回のセッションではSolarisのホスト名変更が標準では対応していないので、モジュールを書いて、pull requestした話がありました。)

開発したモジュールを標準モジュールに取り組んでもらうには、いくつかのルールがある。説明、利用例に準拠させる必要がります。

仮想化とストレージの新しい形!ハイパーコンバージインフラの技術解説

オンプレのストレージ仮想化は、スモールスタートしずらい

安価なストレージ仮想化では、SANのポート、ストレージヘッドの性能に制限

拡張する場合、非効率なサイロ化

そこで、ソフトウェア処理で何とかするのが、Nutanix

Googleが描く、MapReduceを超えたビックデータの世界

Googleのコンテナ技術Borg

Google BigQuery

Googleも初期には、oracleとかRDBを使っていたが、膨大なGooogle検索のインデックスを管理するPBサイズになり、対応しきれなくなったとのこと。BigQueryのサービスが生まれた。インフラをあまりしらないユーザも使える。最適化されていたクエリ(糞クエリ)も高速で実行が可能。管理者不要、パフォーマンス劣化がない

1,000億行Read(フルスキャン)しても、20秒かからない。

RDBだと、一台のマシンで1日かかることも。

BigQueryがなぜ速いのかの説明。カラム指向ストレージ。カラム毎に異なるストレージに入れるので、クエリ実行効率、圧縮効率もいい

数千台のサーバーで並列実行。他のクラウドだとマネできない。

RasPiからBigQueryにも。fluent-plugin-bigqueryを使う場合、GCEだと、AWSでいうIAM Roleに相当する自動でアクセスするcredentailsを取得する仕組みがRasPiとかIoT deviceだと使えないのが課題。

Google Dataflow

機械学習(Machine Learning)

実行環境側でshared。Kinesisの場合、sharedをKinesis Streamを作成する際、指定する必要があるが、スケールも自動でしてくれる。

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年7月12日
から hiruta
Cloud Source Repositoryを使用してみました。 #gcpja はコメントを受け付けていません

Cloud Source Repositoryを使用してみました。 #gcpja

Google Cloud Platformには、git リポジトリ、Cloud Source Repositoryが提供されています。現在ベータといことで、無料で使うことが可能。(500MBのサイズ制限は有り)

ローカル環境に、Chef、knife-soloの環境を構築

curl -L https://www.opscode.com/chef/install.sh | 
/opt/chef/embedded/bin/gem install knife-solo --no-ri --no-rdoc
knife solo init knife-solo
cd knife-solo

Chefのリポジトリでgit local repositoryとして初期化

git init 

すべてのファイルをgitの管理下に

git add -A
git commit -m 'first commit'

Generate and store your Git credentials

screencapture-console-developers-google-com-project-skillful-fx-531-clouddev-source-repo-1436674845613

生成されたものを、.netrcに貼り付ける。

git config credential.helper gcloud.cmd

gitのリモートレポジトリとしてgoogleの下記URLを登録

git remote add google https://source.developers.google.com/p/your-project-id/

Cloud repositoryにアップロード

git push --all google

Developer Consoleから下記のように確認できるようになります。

screencapture-console-developers-google-com-project-skillful-fx-531-clouddev-source-browse-vDFBdy1OoJh-master-1436673896028

 

プライベートリポジトリとして使うことができます。プライベートリポジトリx1しか作成できないようです。

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名程度でしたが、今年は、キーノート会場は満席、立ち見もある盛況ぶりでした。

IMAG0383

 

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

IMAG0384

 

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

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

ここまでの午前中の部(キーノート)

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

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

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エンジンと統合されています。

aurora_w_1

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

aurora_w_2

 

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

aurora_w_2_1

 

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

aurora_w_3_1

 

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

aurora_w_3_2

 

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

aurora-list

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

aurora-pullmenu

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

ui-sc

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がアップデートできないので、注意が必要。