クラウドインフラ構築記

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

2016年2月14日
から hiruta
Googe Cloud Vision GCSに対応 #gcpja はコメントを受け付けていません

Googe Cloud Vision GCSに対応 #gcpja

Cloud Vision Early Access ProgramのGoogleグループに流れていたことですが、Cloud Visionは、Google Cloud Storageの画像を読み込むことが可能になっています。

ようやく動作できるように(解析結果がレスポンスデータとして戻ってくるように)なりましたので、サンプルコードを掲載します。

下記ソースのbatch_requestのところがポイント。


from PIL import Image
from PIL import ImageDraw
from pprint import pprint
# The url template to retrieve the discovery document for trusted testers.
DISCOVERY_URL='https://{api}.googleapis.com/$discovery/rest?version={apiVersion}'

def get_vision_service():
credentials = GoogleCredentials.get_application_default()
return discovery.build('vision', 'v1', credentials=credentials,discoveryServiceUrl=DISCOVERY_URL)

def main():

batch_request = [{
'image': {
'source': {
'gcs_image_uri': "gs://XXXXXXXXX/top-bnr-70.png"
}
},
'features': [{
'type': 'FACE_DETECTION',
'maxResults': 30,
}]
}]

service = get_vision_service()
request = service.images().annotate(body={
'requests': batch_request,
})
response = request.execute()
pprint(response['responses'][0])

faces = response['responses'][0]['faceAnnotations']

Googleでは、Google Cloud Visionだけでなく、音声認識、Google Photo等Deep Learningをすでに運用されているので、Google Cloud Visionも解析にDeep Learning技術を使用しています。

Deep LearningのFrameworkとして切り出して公開されているのが、TensorFlowになります。(分散環境に対応したTensorFlowも公開されるとのこと)

TensorFlowは複数台の分散環境(40G portsのスペックを有しているJupiter network)で初めて性能を発揮します。スタンドアロンでは性能を発揮できません。つまり、TensorFlowをAWSのGPインスタンスで動かしても期待して性能がでません。

なお、Google Cloud Vision は、数週間後パブリックβでだれでも使用できるようになるようです。

2016年2月11日
から hiruta
Hadoop Spark Conference 2016参加レポート #hcj2016 はコメントを受け付けていません

Hadoop Spark Conference 2016参加レポート #hcj2016

2/8 のHadoop Spark Conference 2016 参加サポートです。今回はSpark Conference 併催になります。1,300名を超える申込者と人気で、各セッション立ち見も出るほど1日中熱気に満たしていました。

キーノート

Hadoopはひとつものではなくなった。

従来は、HDFS+MapReduceが中核でしたが、組み合わせで使っていく方向に。

パッケージの多様化。

並列分散エンジン(Apache Tez)も登場し、現在変化も激しいので、現在の状況を見ておくことが重要

hadoop上で多様なエコシステムが動作している。

バッチ処理をストリーミング処理を透過的に行えるものも。Google Dataflow (Apache Beam)

https://cloud.google.com/dataflow/blog/dataflow-beam-and-spark-comparison

ResourceManagerであるYARNもCPUだけでなく、GPCPUなどにも焦点を置く方向に。

HDFSについても、SSD、メモリの活用で中間データのR/Wの高速化

無停止でローリングアップデート

メンテナンスリリース(2.6、2.7)の継続、Java8対応

Spark 2.0

ユースケースてには、BIが一番。Dataware、レコメンドエンジン、ログ、不正検出等にも

サブクエリー、ビューもDataFrames APIで

Tungsten backendでStreamingの課題を解決

Next-gen Streaming with Dataframesは数週間後発表があるので

Spark 2.0では、125 million rows/secのベンチ結果も。(1.6では13.95 milliion rows/sec)

今年4月~5月にリリース予定。

JVMチューニング

heap memoryのサイズを変更するだけでパフォーマンスが変わる

Spark 1.6ではGCのオーバーヘッドが減っている

ストリーミングアーキテクチャー StateからFlowへ

3-Tierとマイクロサービスの違い

従来のバッチの有限の入出力に対し、ストリーミングは、無限の入出力、サービス間遅延にも考慮が要

非同期なサービス間疎結合の設計が必要

これに対応できるのが、Kafka、MapR Stream

ビックデータ可視化の性能を検証

DWHに比べて、デフォルト設定のHiveは遅い

Spark SQLは、ヒット件数が多だと、1/2

チューニングポイント

エグゼキュータ、パーティション数

データフォーマット

Hive

分散処理エンジンにMR使用している場合は、Apache Tezへの切替を

 

MLLib Now and Beyond

[slideshare id=58034098&doc=2016-02-06spark-conference-japan-160209041021]

手軽に機械学習を扱うことができる

DataSetとDataFrameは今後統合予定

MLLib Pipeline API

Modelを、S3他クラウドストレージに保存することもできるが、永続化に対応していないアルゴリズムもあるので注意が必要

MLLib 2.0 Roadmap

時系列データのSparkでの処理

時系列データをSparkで扱うと不便になるのでは?

が、結論時系列データも問題なく扱える。

Hive on Spark

Hiveは遅い。Hiveクエリによっては、数時間、1日かかるケースも

Hive on Sparkは、HiveQ互換なので、Hive資産の再利用も可能、バッチ処理が1/3になる。

また、Spark on elasticSearch -hadoop データの可視化ツールとして導入コストも低くそうな印象でした。standaloneのSpark 1.6の環境で試してみよう。

2016年2月7日
から hiruta
Instance GroupでAutoHealingに対応 #gcpja はコメントを受け付けていません

Instance GroupでAutoHealingに対応 #gcpja

Instance Templates、Instance Group(AWSだとAutoScaling)を使う場合、以前はheath checkに失敗していも、インスタンスのre-createが行えなかったが、(いつからはわかりませんが)heath checkがNGの場合、インスタンスを作り直してくれるAutoHealingに対応しています。GCE(Google Compute Engine)の場合、0.5sでパケロスなしで別の仮想サーバーにマイグレーションと組み合わせることで可用性を高めることも可能。

screencapture-console-cloud-google-com-compute-instanceGroups-details-asia-east1-a-instance-group-1-1454847528634

揮発性ディスクであるLocalSSDをインスタンスに対して8diskまで付けることも可能。LocalSSDは、ディスク容量375GBかつ高いディスクIOを特徴をもっている。f2-microでもLocalSSDは使用可能。

screencapture-console-cloud-google-com-compute-instancesAdd-1454847393294

2016年1月31日
から hiruta
Google Cloud Visionでランドマーク認識 #gcpja はコメントを受け付けていません

Google Cloud Visionでランドマーク認識 #gcpja

Google の画像認識APIであるGoogle Cloud Visionが使えるようになりましたので、少しいじってみました。

Google Cloud Visonは、物体検知、有害コンテンツ検知、ランドマーク検知、OCR、顔検知など画像の情報を抜き出すことが可能です。REST APIでGoogleサイドと通信していると想定される。

Vision用のService Accountを作成し、credentialsの設定をするしておく必要があります。

export GOOGLE_APPLICATION_CREDENTIALS=deeplearning-environment-78bacd3d4b5b.json

Google APIにアクセスするのに、API discovery documentをベースとしたservice objectを作成する。GAリリースしたものは自動でfetchされるのだが、Vision APIは、alphaリリースなので、下記よりダウンロードする必要があります。

https://cloud.google.com/vision/docs/vision_discovery_v1alpha1.json

def get_vision_service():
 credentials = GoogleCredentials.get_application_default()
 with open(API_DISCOVERY_FILE, 'r') as f:
 doc = f.read()

 return discovery.build_from_document(
 doc, credentials=credentials, http=httplib2.Http())
LABEL_DETECTION  ラベル
FACE_DETECTION 顔認識
LANDMARK_DETECTION ランドマーク認識
TEXT_DETECTION OCR
LOGO__DETECTION ロゴ
SAFE_SEARCH__DETECTION  有害情報検知
SUGGESTION_DETECTION

以下ランドマーク認識の例です。以下で画像データをbase64にエンコードし、Vison APIに渡しています。

 with open(photo_file, 'rb') as image:
 image_content = image.read()
 batch_request = [{
 'image': {
 'content': base64.b64encode(image_content)
 },
 'features': [{
 'type': 'LANDMARK_DETECTION',
 'maxResults': 4,
 }]
 }]
 service = get_vision_service()
 request = service.images().annotate(body={
 'requests': batch_request,
 })
 response = request.execute()

IMAG0142

過去デジカメで撮影した写真を解析すると大阪城(Osaka Castle)として認識されています。位置情報もばっしり。

 {u'responses': [{u'landmarkAnnotations': [{u'locations': [{u'latLng': {u'latitude': 34.686777, u'longitude': 135.525799}}], u'score': 0.613115, u'mid': u'/m/024b_g', u'boundingPoly': {u'vertices': [{u'y': 955, u'x': 1545}, {u'y': 955, u'x': 2411}, {u'y': 1346, u'x': 2411}, {u'y': 1346, u'x': 1545}]}, u'description': u'Osaka Castle'}]}]}

TEXT_DETECTIONを使うと、ちらし画像から文字情報を取り出す(OCR)することもできます。

顔認識は、認識したポリゴン点の座標(fdBoundingPoly)を返してくれます。ただ、画像の中のすべての顔を認識してくれない、顔認識に失敗するケースがあるようです。

2016年1月26日
から hiruta
Autorecoveryの致命的な仕様 はコメントを受け付けていません

Autorecoveryの致命的な仕様

インスタンスの自動復旧機能として、Auto recoveryが用意されています。一時的な障害、インスタンスストアがアタッチしている、1日3度のリカバリのリトライに失敗する際、Auto recoveryを諦めるという運用上致命的な仕様があります。諦めたインスタンスの復旧は手動でstop/startを行えること。Autorecoveryを復旧手段に頼るのはやめるのがいいかもしれません。

screencapture-docs-aws-amazon-com-AWSEC2-latest-UserGuide-TroubleshootingInstanceRecovery-html-1453810845891

上記仕様については、トラブルシューティングで記載されております。(トラブルシューティングは英語版ドキュメントのみです。)

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstanceRecovery.html

この一方、GCEは稼働中のVMを0.5sでパケロスなしで別の仮想サーバーに移動してくれる。(http://qiita.com/kazunori279/items/41520689337a644a87b4 にGoogleの中の人が詳しく書いています。)

本ブログ稼働中のGCEインスタンスは100day連続稼働中です。instance template差し替え後止まっていないじゃないかと。

2016年1月24日
から hiruta
GCE間ネットワークのスループット #gcpja はコメントを受け付けていません

GCE間ネットワークのスループット #gcpja

ツイートに以下がありましたので、

iperf3で実際GCE間スループットを計測してみました。Preemptible VMでも制限されることなく、2Gbit/secでます。

同じリージョン間

0.00-10.00  sec  2.33 GBytes  2.00 Gbits/sec  491             sender

異なるリージョン間

.00-10.00  sec   131 MBytes   110 Mbits/sec   59             sender

2Gbits/secのスループットが出るのは、同一リージョンのGCE間になります。
異なるリージョンのGCEでも同じNetworkに属しているなら、Private IPで通信が可能。GCPの場合、リージョンを意識しないシステム構成も可能です。

2016年1月17日
から hiruta
DataFramesとDataSetを試してみました。 #ApacheSpark はコメントを受け付けていません

DataFramesとDataSetを試してみました。 #ApacheSpark

Spark 1.6がリリースされたことで、DataSet、DataFrameを試してみました。

まずは、事前に下記をインストールしておきます。(CentOS7にて)

  • Java7 1.7.0_80
  • Hadoop-2.6.3のインストール※インストールはこちらを参照してください。
  • Development  Toolsをグループインストール

環境変数の設定

export SPARK_DIST_CLASSPATH=$(hadoop classpath)

VMパラメータを設定します。これをしないと、Sparkのビルド途中でout of memoryで失敗します。

export MAVEN_OPTS="-Xmx2g -XX:MaxPermSize=512M -XX:ReservedCodeCacheSize=512m"

Spark 1.6のビルドをします。かなり時間がかかりますので、完了まで待ちます。Scalaは、 2.10.4

build/mvn -Pyarn -Phadoop-2.6 -Dhadoop.version=2.6.3 -DskipTests clean package

hadoopデーモンの起動

start-all.sh

DataSetで取り込むAWS IP Rangesをcsv形式で取り組んでおきます。Sparkはjson形式も取り込むことも可能ですが、ip-ranges.jsonそのままだとjson構造が入れ子になっていることもあり、csvにしてからSpark DataSetに取り込みました。

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | {ip_prefix,region,service}' | jq "[.ip_prefix,.region,.service] | @csv" > ip_ranges.txt

Spark Shellを起動します。


$ spark-1.6.0/bin/spark-shell
log4j:WARN No appenders could be found for logger (org.apache.hadoop.metrics2.lib.MutableMetricsFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Using Spark's repl log4j profile: org/apache/spark/log4j-defaults-repl.properties
To adjust logging level use sc.setLogLevel("INFO")
Welcome to
____ __
/ __/__ ___ _____/ /__
_\ \/ _ \/ _ `/ __/ '_/
/___/ .__/\_,_/_/ /_/\_\ version 1.6.0
/_/

Using Scala version 2.10.5 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_80)
Type in expressions to have them evaluated.
Type :help for more information.
16/01/17 09:26:46 WARN Utils: Your hostname, localhost.localdomain resolves to a loopback address: 127.0.0.1; using 172.16.10.18 instead (on interface enp0s3)
16/01/17 09:26:46 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to another address
Spark context available as sc.
SQL context available as sqlContext.

scala>

DataFramesスキーマ定義を設定

scala> case class AwsIp(ip_prefix: String, region: String, service: String)

上記で取得したAWS IP rangesのcsvをDataFramesに取り組みます。

scala> val awsip = sc.textFile("/home/hdspark/ip_ranges.txt").map(_.split(",")).map(p => AwsIp(p(0),p(1),p(2))).toDF()

DataFramesスキーマ定義の確認

scala> awsip.printSchema()
root
|-- ip_prefix: string (nullable = true)
|-- region: string (nullable = true)
|-- service: string (nullable = true)

regionでグルーピング。東京リージョンのCIDR数は、オレゴンより多いとは。

scala> awsip.groupBy("region").count().show()
+--------------+-----+
| region|count|
+--------------+-----+
| eu-central-1| 18|
| cn-north-1| 10|
| us-east-1| 122|
|ap-northeast-1| 56|
|ap-southeast-1| 50|
| us-west-1| 46|
| us-west-2| 51|
|ap-southeast-2| 34|
|ap-northeast-2| 11|
| GLOBAL| 35|
| us-gov-west-1| 6|
| sa-east-1| 29|
| eu-west-1| 74|
+--------------+-----+

serviceでグルーピング

scala> awsip.groupBy("service").count().show()
+--------------------+-----+
| service|count|
+--------------------+-----+
|ROUTE53_HEALTHCHECKS| 16|
| ROUTE53| 1|
| AMAZON| 323|
| CLOUDFRONT| 17|
| EC2| 185|
+--------------------+-----+

regionが「ap-northeast-1」が合致するものを抽出し、その中で、serviceが「AMAZON」のものを抽出することも。

scala> val f1 =awsip.filter(awsip.col("region").equalTo("ap-northeast-1"))
scala> f1.filter(f1.col("service").equalTo("AMAZON")).show()
+---------------+--------------+-------+
| ip_prefix| region|service|
+---------------+--------------+-------+
| 27.0.0.0g22|ap-northeast-1| AMAZON|
| 46.51.224.0g19|ap-northeast-1| AMAZON|
| 52.68.0.0g15|ap-northeast-1| AMAZON|
| 52.92.60.0g22|ap-northeast-1| AMAZON|
| 52.94.9.0g24|ap-northeast-1| AMAZON|
| 52.95.30.0g23|ap-northeast-1| AMAZON|
| 52.95.34.0g24|ap-northeast-1| AMAZON|
| 52.95.56.0g22|ap-northeast-1| AMAZON|
| 52.95.243.0g24|ap-northeast-1| AMAZON|
|52.95.255.48g28|ap-northeast-1| AMAZON|
| 52.192.0.0g15|ap-northeast-1| AMAZON|ml
| 52.196.0.0g14|ap-northeast-1| AMAZON|
| 54.64.0.0g15|ap-northeast-1| AMAZON|
| 54.92.0.0g17|ap-northeast-1| AMAZON|
| 54.95.0.0g16|ap-northeast-1| AMAZON|
| 54.150.0.0g16|ap-northeast-1| AMAZON|
| 54.168.0.0g16|ap-northeast-1| AMAZON|
| 54.178.0.0g16|ap-northeast-1| AMAZON|
| 54.199.0.0g16|ap-northeast-1| AMAZON|
|54.231.224.0g21|ap-northeast-1| AMAZON|
+---------------+--------------+-------+
only showing top 20 rows

こんな感じで、フィルタリング機能も充実しています。DataSet 、DataFramesについては下記も参照してください。

http://spark.apache.org/docs/latest/sql-programming-guide.html

in-memoryで動くこともあるが、Hadoopより100x高速なので、これからデータプロセッシングはSparkがお勧め。

2016年内に、2.0のリリースも予定。(Rearchitecting for Mobile Platform、MLLib 2.0)

MLLib 2.0 については、https://issues.apache.org/jira/browse/SPARK-12626も。

Google Dataproc、EMRとも現状、Spark 1.6.0には対応していません(1.5.2が対応している最新版)。Google DataProcは、2015/9、2015/11と新バージョンがリリースしているなので、次は、2016/1に新バージョンがリリース?

2015年12月29日
から hiruta
Google Dataflow入門編 #gcpug #gcpja はコメントを受け付けていません

Google Dataflow入門編 #gcpug #gcpja

Google Dataflowが、GAになりましたので、Google Dataflowを改めて。

cloudservice accountとか、Compute Engine Service Accountとか、新規プロジェクト作成時のみしか自動追加されない。既存プロジェクトに追加する方法が知りたいところ。Service Accountが登録されているなら、credentailsは不要のようだ。

  • maven 3.3.9
  • Java8 1.8.0_66
$git clone https://github.com/GoogleCloudPlatform/DataflowJavaSDK-examples.git

WordCountのサンプルを実行。実行過程で、VM インスタンスが起動します。

$ ../apache-maven-3.3.9/bin/mvn compile exec:java -Dexec.mainClass=com.google.cloud.dataflow.examples.WordCount &nbsp;-Dexec.args="--runner=BlockingDataflowPipelineRunner --project=<project name> --stagingLocation=gs://<GCS bucket>/staging/"

dataflowのコードテンプレートを生成は以下で行えます。

mvn archetype:generate \
 -DarchetypeArtifactId=google-cloud-dataflow-java-archetypes-starter \
 -DarchetypeGroupId=com.google.cloud.dataflo

Cloud Pub/Sub(PubSubIO)からデータを取得、処理を行い、BigQuery IO(BigQueryIO)でGoogle BigQueryに書き込むのもできてしまいます。

google dataflow は、現在のところ、preemptible VMに対応していません。preemptible VMはDataflowのようなジョブの使い方にはマッチすると思われるので今後のサポートに期待したい。

マシンタイプは、DataflowPipelineOptionsでディスクサイズ、Workerのサイズ、マシンタイプのカスタマイズは可能です。

オプションについては、https://cloud.google.com/dataflow/pipelines/specifying-exec-params

eclipse用のDataflow pluginも用意されているので、eclipse上からDataflowアプリケーションを実行させることも可能です。ローカル実行も。

https://cloud.google.com/dataflow/getting-started-eclipse?hl=ja

 

2015年12月26日
から hiruta
Google Cloud DatalabでBigQueryデータの可視化をしてみました。 #gcpug #gcpja はコメントを受け付けていません

Google Cloud DatalabでBigQueryデータの可視化をしてみました。 #gcpug #gcpja

Google Cloud Datalabは、ワンクリックで開始できる大規模データの探索、分析、可視化が行えるツールです。

過去途中でOut Of Memoryでデプロイに失敗していましたが、昨日試したところ、正常にデプロイできるようになっていました。アップレートされたのでしょうか。

Cloud Datalabを始めるには、https://cloud.google.com/datalab/?hl=ja から

Deployをクリックすれば、必要なインスタンスとかを作成してくれます。完了まで10分程度かかります。

screencapture-datalab-cloud-google-com-1451113496606

デプロイが成功すると、下記画面が表示できるようになります。

screencapture-main-dot-datalab-dot-skillful-fx-531-appspot-com-tree-1451114146971

変数定義

import gcp.bigquery as bq
import pandas as pd
df = bq.Query('SELECT * FROM [nginx_datasheet.access_log] limit 10000').to_dataframe();

10,000レコードをSELECTするのに、10秒。BigQuery Web UIだと4.2s(2Gデータ)なので、オーバーヘッドがある?

BigQueryのuaフィールドでグルーピングを行います。

groups = df.groupby('ua')

最後に、グラフで可視化

df['ua'].value_counts().head(20).plot(kind='bar', figsize=(20,10))

screencapture-main-dot-datalab-dot-skillful-fx-531-appspot-com-notebooks-access_log_analytics-ipynb-1451114559409

チュートリアルもDatalabをデプロイするとできます。Cloud Storageからデータをロード、むろんBigQueryのデータをロードして、可視化が簡単にできます。

グラフについても、折れ線、棒グラフ、パイチャート等できるようです。

作成したNoteBooksについては、Cloud Source Repositoryに保存されるようになっていて、Cloud Datalabを削除しても、再作成時に以前作成したNotebooksを再ロードしてくれます。

Cloudlabの削除もApp Engineを削除すれば、ワンクリックで完了です。

2015年12月23日
から hiruta
CloudSQL Second Generation ベンチマーク #gcpja #gcpug はコメントを受け付けていません

CloudSQL Second Generation ベンチマーク #gcpja #gcpug

初代CloudSQLより7x 高速スループット、20x ストレージ拡張性の特徴を持っているCloud SQL Second Generationがβ公開されています。インスタンスタイプもCompute Engine相当になっています。

CloudSQLのmysqlバージョンは、5.6.25(5.6.25-google-log)。Auroraは、5.6.10。

TPC-CでCloudSQL Second Generationのベンチマークを計測してみました。計測対象は、 db-n1-highmem-2(RAM 13G、10TB)を利用しました。r3.xlarge相当

多重度 Throughput(tps) Response time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level New-Order Payment Order-Status Delivery Stock-Level
db-n1-highmem-2  16  92.8 92.8 9.3 9.3 9.3 171 127 10  262 11
Aurora

db.r3.xlarge

16 195.5 195.6 19.6 19.6 19.6 67 27 7 91 9

現状Auroraの1/2のベンチマーク結果となっているようです。CloudSQL Second GenerationからCompute Engine同様継続割引が自動的に適用されます。

初代CloudSQLからのアップグレードは現状提供されていませんので、マニュアルでの移行が必要です。