クラウドインフラ構築記

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

2017年10月15日
から hiruta
Google Cloud Functions Emulatorについて #gcpug はコメントを受け付けていません。

Google Cloud Functions Emulatorについて #gcpug

Google Cloud Functionsのローカルエミュレータとして昨日のGCPUG shonanで話がありました。

ただ、ローカルエミュレータはNode.js v6.11.1必要なので、MBAで動かすにはnodeをインストール(アップグレード)が必要になります。

https://github.com/GoogleCloudPlatform/cloud-functions-emulator/

 brew update
brew upgrade node
npm install -g npm

local emualtorは、下記でインストールできます。

 npm install -g @google-cloud/functions-emulator

v8.7のnode.jsが入ったので、warningがでましたが、functionsのデプロイ(deploy)、呼び出し(call) は問題ありませんでした。

 Warning: You're using Node.js v8.7.0 but Google Cloud Functions only supports v6.11.1

昨日も話されていましたが、Cloud Functionsのデプロイ調子悪いときとか、デバッグに有益かと思われます。

なお、CloudShellだと、functionsのローカルエミュレータはプリインストールされています。

2017年9月24日
から hiruta
cloud-function-python を試してみました。 #gcpug はコメントを受け付けていません。

cloud-function-python を試してみました。 #gcpug

公式には、node.jsのみサポートされていますが、cloud-function-pythonというpython scriptをCloud FunctionsにデプロイするCLIツールがあるので少し試してみました。(cloud-function-pythonはpureなpython sciriptをnode.jsに変換するツールので、直接cloud functionsにはデプロイは行えません。)

ローカルなmac環境をpyenvを利用してpython実行環境を構築しているのだが、通常のpyenv installでインストールされた環境では、py-cloud-fnを実行する際、python-dev、pyton3-devがないようとエラーになってしまう。

 py-cloud-fn -f myfunction.py my-function http 

そこで、pyenv installでshared libraryをサポートしたpythonをインストールする必要があります。

 env PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install -v 2.7.12

py-cloud-fnでinde.js等がcloudfn/targetフォルダに出力されているので、gcloud beta functions deployをすれば。Cloud Functionsにデプロイすることができます。

※ネイティブなpythonがCloud Functionsにサポートされることを期待したい。

 

2017年8月6日
から hiruta
RDSログのS3保存 はコメントを受け付けていません。

RDSログのS3保存

RDSのログをダウンロードするには、REST APIで取得しますが、一日経過したログはローテーションされて削除されます。

長期保存するには、定期的にS3にダウンロードする仕組みが必要。

そのまま使えるLambda functionが下記に公開されていました。

AWS Lambda function to export Amazon RDS MySQL Query Logs to S3

上記は差分更新に対応していない、圧縮対応とか改良してくれるスクリプトが公開されていました。(python 3対応)

https://github.com/om732/rdslogs2s3

Cloudwatch Eventsのスケジュールで定期起動するには、複数RDSのログを環境変数より変数のほうが都合がいいので両者を組み合わせてスクリプトを作成しました。

https://github.com/webse/rdslog_s3

また、ansibleからLambda functionsもデプロイすることができます。

 - hosts: localhost
tasks:
- name: looped creation
lambda:
name: '{{ item.name }}'
state: present
zip_file: '{{ item.zip_file }}'
runtime: 'python3.6'
role: 'arn:aws:iam::xxxxxxxxxxxx:role/role-test-dv-rdslog'
handler: 'rdslog2s3.lambda_handler'
region: ap-northeast-1
with_items:
- name: rdslog2s3-test
zip_file: rdslog2s3.zip

 

2017年7月20日
から hiruta
Cloud Spanner設計(PK、テーブル分割) #gcpja はコメントを受け付けていません。

Cloud Spanner設計(PK、テーブル分割) #gcpja

本日(ていうか日付変わっていたので昨日)Cloud Spannerの設計について解説セッションがありました。

酒とゲームとインフラとGCP 第6回 〜早く暑気払いしないと死ぬぞ〜@デジタルハリウッド@御茶ノ水! 

分散リレーショナルデータベースを使う上での設計のポイントが話された。

Cloud Spanner概要

 MySQLのスケールアウトが手間がかかるが、Spannerはノード追加削除でスケールアウトが自由自在

 リージョンなものの提供

 今後マルチリージョンを提供

 MySQLでないので意識するとよいパフォーマンスがでる

 低ワークロードではパフォーマンスが出ない

PKの使い方によってはデータが分散しない(データが偏る)

 オートインクリメントだと1ノードで入る(データが分散しない)可能性あるのでサポートしていない

 サポートしないのも1理由

 UUIDを使う ※128bitのを使うといい

 PKの選択でノードの偏りがある場合あり

  日付だと偏るケースがある

インターリーブ

  インターリーブ=親子関係

  関連したデータのロカリテティを管理できる

  関連したデータはあっちこっちにいくことがなくなる

  PKはインデックスいらない

  どこかのSpannerサーバに格納される場合あり

  セカンダリインデックスは、不要な場合は作成しない、できるだけ使わない

gRPC

  gRPCコネクション デフォルト4、最大256

       デフォルトの4で十分とのこと

  負荷試験でもそう変わらない

  try-errorを繰り返す

   セッション

  トランザクションを実行できるコンテキスト

  並列で行われるトランザクションは各自セッションを利用する必要あり

  セッション数=スレッド数

  MAX10,000

    Developer consoleのエラーレート

  abortしたトランザクションは自動リトライしてくれる

  例外がでていなければエラーレートは無視していい

  ノードは分散ストレージのデータを管理している

  ノードを削除すると管理していたスプリットのオーナが変わる

  障害時も同

  (ドキュメントに記載されていないことだが、)2GB per parent record

テーブル分割

    Size-based splits データの容量でテーブル分割

 Load-base splits 負荷によりテーブル分割

  シーケンシャルINSERTだと分割されない

 負荷試験は20-30j実施

 5分だとノードが十分に活用されていない

 負荷試験はデータベースをドロップしないと、正確な負荷試験ができない場合も

 LSM Treeを使っているとレコード削除だけでは削除されない

 テーブルのクリーンアップは一週間かかる

 TPS

ノード削除できない場合がある。データの容量が多すぎる。5TB Writeして1ノードにしても3ノード必要できないので削除できない

75%CPU超えたら、functionsでノード追加などできる

75%を1ノードの負荷目安

Dailyで取っているのでサポートに問い合わせて別のインスタンスに戻せる

Query Plan cache

  IDを変えると3つのキャッシュが作られるのでParameter Binding

 ( JDBCのPrepareStatementと同じ?)

ノード追加すると若干レイテンシーが落ちるが、しばらくすると回復する

リアルユースケース、実データで負荷試験

ロードツール

年内にもロードツールがでる?Dataflow IO

現状公式にはDML(ていうかWrite系SQL)にはサポートされていないが、SQLを書くと、Spannerコードにしてくれるツールを開発されたが、後々OSS化もあるとのこと

Spanner用のWirte系SQLをサポートした(制限有りの)JDBCドライバもあるが

2017年6月15日
から hiruta
Google Cloud Next ’17 in Tokyo の参加セッション聴講メモ(Day 2) #googlenext17 はコメントを受け付けていません。

Google Cloud Next ’17 in Tokyo の参加セッション聴講メモ(Day 2) #googlenext17

ザ・プリンス パークタワー東京で開催中の Google Cloud Next ‘17 in Tokyo に参加しました。

分散データベースCloud Spannerが明日(6/16?)から東京リージョンasia-northeast1で使用可能になることがキーノートで発表されました。

Container Engine 本番環境へのデプロイ

  • コンテナだけではないと思うんだが、一貫性であることが必要
  • 早急にデプロイを
  • Githubリポジトリでkubernates一番活発と言っていたが、最近は、TensorFlowのリポジトリも活発と思う。
  • ローリングアップデート(ダウンタイム無し)、過去のバージョンへの戻し(undo)、ロードバック
  • コンフィグをエクスポートして、再構成も可
  • Build Triggers
    • リポジトリにpushをトリガーにdocker imageも作成、デプロイも
  • demoで使ったコード

 

SORACOMでデバイスとGoogle マシンラーニングの連携で構築するIoTソリューション

  • SORACOM Beamで、Cloud IoT Coreに接続。
    • GCPのcredentialsはBeamで管理
    • JSONトークン発行も
    • Cloud IoT Coreにデータ送ってしまえば、後は、Functions、DataflowでBigQueryに蓄積することも。※Cloud ML Engineで機械学習連携も(BQ、Dataflow等はオートスケールなので、処理量に応じてスケールアウト、インもできるのでIoTシステムとして最適と思われる)
  • SORACOM FunnelをCloud Pub/Subに接続※新機能

Cloud Platform™ (GCP™)で始める IoT 入門セミナー

BigQueryの先進機能

※NEXT SFの元セッション動画

以前は、スタティックツリー。いまはダイナミックつり-。

Sharedの数を変えることが可能。

ブロードジャストJOINの方が早い

JOINに偏りがあると、クエリ速度が遅くなったり、メモリ不足になる場合も

Limitを指定したり、クエリの分割が重要

カウントもapploximateで。(Hyper LogLog+)

フルサイクルのデータ分析を実現・データ分析基盤を活用したデータサイエンスの実践

※NEXT SFの元セッション動画

GCPは、ほほすべてのサービス(Cloud Pub/Sub、Dataflow、BigQuery他)がオートスケール

スケール状態にかかわらず、全く同じコードを使用可能

ハイパーパラメータチューニングも自動できるCloud ML Engine

仮想マシンでこれらのサービスを作ることもできるが、スケールアウトで問題になる。

様々な分野の事例で解説!クラウドGPUを使ったHPCとリモートデスクトップアプリケーション開発

オンプレミスでGPUを構築するより、クラウドGPUは初期投資なし、構築時間削減が可能

NVIDIA® Tesla® P100 も近々使えるなるとのこと

K80より、8倍速い

将来的には、GPUが使えるゾーン展開も。

 

2017年4月30日
から hiruta
Google Datalabにバンドルされていないライブラリを追加するには #gcpug #gcpja はコメントを受け付けていません。

Google Datalabにバンドルされていないライブラリを追加するには #gcpug #gcpja

Google Datalabにバンドルされていないライブラリはデフォルトの状態では使うことはできない。

バンドルされていないライブラリを使うようにするには

https://cloud.google.com/datalab/docs/how-to/adding-libraries

にも記載されている二通りの方法がある

/content/datalab/.config/startup.sh に、datalab起動時に、pip installする記載を書き込むか、オリジナルなdocker イメージを作成する方法があります。

前者だと、datalab delete –delete-disk datalab-test とはすると、startup.shの内容は消えてしまう。永続的にするには、オリジナルdocker imageを作成する方法になります。

 

Dockerfileの作成をまず行います。

 FROM gcr.io/cloud-datalab/datalab:latest

RUN pip install https://storage.googleapis.com/videointelligence-alpha/videointelligence-python.zip

Video Intelligence APIはalpha版ライブラリをインストールする例になります。

dockerイメージのビルド

 docker build -t asia.gcr.io/[project-id]/datalab:1.0 . 

Container Registryにアップロード

 gcloud docker -- push asia.gcr.io/[project-id]/datalab

Datalabインスタンスの作成

 datalab create --image-name asia.gcr.io/[project-id]/datalab:1.0 --disk-size-gb 10 datalab-test 

2017年3月26日
から hiruta
Google Cloud Video Intelligence APIについて少し話させていただきました。 #gcpug #shonan はコメントを受け付けていません。

Google Cloud Video Intelligence APIについて少し話させていただきました。 #gcpug #shonan

昨日のGCPUG Shonan https://gcpug-shonan.connpass.com/event/52208/ にて、

Private beta の申請が通って、試した内容を少し話す機会を作っていただきました。

このときのスライド(一部カット版)を公開します。

Private betaとか、Try a demo NOW ( https://cloud.google.com/video-intelligence/#demo ) に書かれていないAPI Response の情報も記載しています。

http://qiita.com/web_se/items/0cf74a808b404da671b7

現在対応していないGoogle Cloud Client Libraryへの対応が待たれるところ。

2017年3月20日
から hiruta
Google Cloud Video Intelligence API で動画を解析してみました。#gcpug はコメントを受け付けていません。

Google Cloud Video Intelligence API で動画を解析してみました。#gcpug

下記動画をVideo Inteligence APIでLabel認識してみた。

主なシーンの解析結果は以下になりました。

認識された動画の中の開始点、終了点、認識文字、認識精度がJSON形式で返ってきます。

startTimeOffset、endTimeOffsetは、ミリ秒の数値になります。

"description":"Bus",
                  "locations":[
                     {
                        "confidence":0.5243035,
                        "segment":{
                           "endTimeOffset":"-1",
                           "startTimeOffset":"-1"
                        },
                        level: "VIDEO_LEVEL"
                     },
                     {
                        "confidence":0.5243035,
                        "segment":{
                           "endTimeOffset":"38757893"
                        },
                        level: "SHOT_LEVEL"
                     }
                  ]

2,3のシーンの解析結果

上記のシーンの認識結果は、

  • Mountain (0.50)
  • Mountain range (0.55)

認識度も50%

上記のシーンの認識結果は、

  • Android (0.51)
  • Mobile phone (0.98)
  • iPhone (0.81)
  • Portable communications device (0.91)
  • Samsung (0.5)
  • Smartphome (0.99)
  • Apple (0.63)

Smartphoneである可能性高いよ、なぜかiPhoneの判定も。

ただ、他のDetectionより解析時間がかかるように見られます。

2017年3月19日
から hiruta
Committed Use DiscountsとSustained use discountの比較 #gcpug はコメントを受け付けていません。

Committed Use DiscountsとSustained use discountの比較 #gcpug

Committed Use DiscountsがGCPでも使えるようになりましたので、すでに利用できている継続利用割引(Sustained use discount)と比べて、どの位安価か調べてみました。

https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts?hl=en_US&_ga=1.230413599.2091612383.1481360112

Standardインスタンスタイプで比較(月単位、単位ドル)

n1-standard-1 n1-standard-2 n1-standard-4 n1-standard-8 n1-standard-16 n1-standard-32 n1-standard-64
 vCPU 1 2 4 8 16 32 64
Memory 3.75 7.5 15 30 60 120 240
commitment 28.03 56.05 114.60 224.21 448.41 895.83 1,793.65
Sustained use discount 31.17 62.74 125.08 249.77 499.14 997.87 1,995.34
full 44.53 89.06 178.12 356.24 712.48 1424.96 2,849.92
 Difference -3.14 -6.69 -10.48 -25.56 -50.73 -102.04 -1,055.69
※AWS相当タイプの1年前払いなし 46.72 76.01 151.18 302.35 603.85  N/A 2417.10

n1-standard-1程度ではCommitted Use Discountsでなくても、いいのでは。

継続割引の段階でも、AWSより安価でしたが、さらに安くなっている。

高スペックになればほど、Committed Use Discountsのメリットが享受できるとみられます。

2017年3月18日
から hiruta
Google Cloud Video Intelligence API を使ってみました。 #gcpug はコメントを受け付けていません。

Google Cloud Video Intelligence API を使ってみました。 #gcpug

Video Intelligence APIのPrivate Beta使えるようになったので、少し感想を。

.MOV、.MPEG4、.MP4、.AVIの動画フォーマットは対応しているとのこと

顔認識、ラベル認識、そして、動画のシーンの区切りを認識できるようです。

  • Face detection
features = [enums.Feature.FACE_DETECTION]
operation = video_client.annotate_video(path, features

operation.result().annotation_results[0].
face_annotations
  • Label detection
video_service_request = video_service.videos().annotate(
body={
'inputUri': gcs_uri,
'features': ['LABEL_DETECTION']
})
response = video_service_request.execute()

labelData = response['response']['annotationResults'][0]['labelAnnotations']
  • Shot change detection

const request = {
inputUri: gcsPath,
features: ['SHOT_CHANGE_DETECTION']
};

video.annotateVideo(request)

const shotChanges = doneResponse[0].annotationResults[0].shotAnnotations;

の動画を、Cloud Video Intelligence API で解析したところ、44分ほどの動画でしたが、6分ほどで処理が完了。処理リージョンは、asia-east1を使用。

解析結果は以下jsonで返されます。

labelAnnotations[] ラベル認識結果一覧
labelAnnotations[].description ラベル認識結果
labelAnnotations[].languageCode
labelAnnotations[].locations[].segment.startTimeOffset ラベル認識された認識開始時間
labelAnnotations[].locations[].segment.endTimeOffset レベル認識された認識終了時間
labelAnnotations[].confiidence
labelAnnotations[].level
facelAnnotations[].segments.startTimeOffset 顔認識された認識開始時間
facelAnnotations[].segments.endTimeOffset 顔認識された認識終了時間
shotAnnotations[] シーンの変化
shotAnnotations[].startTimeOffset 認識開始時間
shotAnnotations[].endTimeOffset 認識終了時間

 

Cloud Vision APIとそう変わらない感じで使えるように見られます。画像と違って、処理に時間がかかることもあり、Botサービスで利用する場合、処理を受け付けた旨を返して、解析結果が出たら、結果を返す仕組みが必要と思われます。Line botのaccess tokenの有効期限は考慮は必要か。