クラウドインフラ構築記

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

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の有効期限は考慮は必要か。

2017年2月5日
から hiruta
Google Data Studioでカスタムクエリ #gcpja #gcpug はコメントを受け付けていません。

Google Data Studioでカスタムクエリ #gcpja #gcpug

データのVisualizationツールであるGoogle Data Studioが完全に無料化されました。

ひっそり(?)カスタムクエリにも対応していました。

https://support.google.com/360suite/datastudio/answer/6370296?hl=en&ref_topic=6370347#custom_query

が、Standard SQLで、カスタイムクエリを作成すると、クエリは作成はできますが、レポートでグラフ部品を追加する際に、エラーとなります。

レポート上でグラフ部品を追加すると、

starts_widthはある文字で始めるフィールドでフィルタする際に使います。(Standard SQL)

legacy SQLだと、レポート上のグラフ表示は問題はないようです。

legacy SQLのみサポートしているのか。カスタムクエリのヘルプページ にもStandard SQLがダメだとは書いていないようです。

2017年1月22日
から hiruta
APIGateway + AWS Lambda とGoogle Cloud Functions のレスポンスタイムについて はコメントを受け付けていません。

APIGateway + AWS Lambda とGoogle Cloud Functions のレスポンスタイムについて

AWS Lambdaには、直接HTTPアクセスすることができない。API Gatewayを使わないといけないので、レスポンス的にボトルネックになる場合があることを、先週のserverless meetup Tokyoであった。

直接HTTPでfunctionsをキックすることができるGoogle Cloud Functions (近々public beta)とのレスポンス時間をcurlにて計測してみた。

  • Google Cloud Functionsがus-central1(Council Bluffs, Iowa)なので、AWSのリージョンの中で近いus-east-2(オハイオ)で
  • 初期化処理がある初回は除く
  • curlコマンドで確認
  • Functions メモリ 256MB
  • Functionsは、hello worldレベル
API Gateway + Lambda Google Cloud Functions
 0.813  0.703
0.782  0.709 
0.775  0.775 
0.710  0.692 
0.600  0.733 
0.703  0.694 
0.774  0.748 
0.802  0.727 
0.582  0.426 
0.583  0.774 

さほどの差はありませんでしたが、若干Cloud Functionsの方がレスポンスは良かった。

2017年1月18日
から hiruta
Serverless Meetup Tokyo vol.2に参加しました。 #serverlesstokyo はコメントを受け付けていません。

Serverless Meetup Tokyo vol.2に参加しました。 #serverlesstokyo

昨日Serverless Meetup Tokyo vol.2に参加しました。

Tune up AWS Lambda

Lambdaのパフォーマンスに関する話

知っておくべきこと

  • 同時実行数 ある時点にfunctionsが実行される数
    • ストリーム別
      •  シャードの数を大きくするとスケールしていく
      •  Lambdaの実行数は、シャードの数とイコール

セーフティガードとして、Limit = 100

    • それ以外
      •   一秒あたりのイベント数*実行時間

APIGatewayの時は秒間のリクエスト30s 30rps

同時実行数の制限緩和も可能だけど、実績がない場合は通らない。

実施にThrottleされているか確認

  • ライフサイクルコめコンテナ  Sandbox として動いている。dockerではない
    • 開始 コンテナ作成されて、コンテナ内にロード・展開(コールドスタート)
    • 終了
    • 再利用※時間が経っていない場合は、再利用される
      • 初期化処理は再利用されるのでパフォーマンス的なアドバンテージがある
      • 再利用されるとは保証するわけではない
  • パフォーマンス関連
    • メモリ設定

コンピューティング全体の設定なので、CPU必要な場合はあげるといい

    • バッチサイズ

 一度に取得する最大のレコード数

シャード数増やすことで同時処理数も増えるので、どちらがいいかはワークロード次第

  • Lambda functionを速くする方法
    • 定常的にリクエストする

ファンクションにたいしてPingするなり、ポーリングする処理を実装する

推奨の間隔は五分

    • コンピューティングリソースを増やす
    • 言語を変える

スピンアップの順番は、Java <  C# <  python < node.js

    • VPC使わない

ENIの生成、アタッチ処理は遅い

    • パッケージサイズを小さくする

Javaの場合、ProGuard等難読化ツールでパッケージを小さくできる

Lambdaの場合、使用するモジュールをコードに同封しないといけない。

    • グローバルスコープ
    • 同時実行性

インフラエンジニア”リング”レスアーキテクチャ

AzureFunctions 処理数1,200/ ピーク 3,700/分捌いている。

AzureFunctionsは、bashでコードを書ける。Functions内で、perlも使えてしまう。

Serverless AWS構成でセキュアなSPAを目指す

Cloudfront + Amazon S3に一応Serverless

API Gateway + Lambdaになってしまうので、レイテンシ問題がある

Google Cloud FunctionsとかAzureFunctionsだとHTTP(S) Trigger機能があるので、レイテンシでどの程度違うかは別途検証してもようと。

STSのCredential有効期限(最大1H)とCognito Token(最大24H)なので、気をつける

Json Web Token https://blog.kazu69.net/2016/07/30/authenticate_with_json_web_token/

Data + No-Ops

データ処理、No-Opsでできる

プラットフォーム作らないくてもいい

より良いソフトウェアを作るのに力を費やすのがいい

Googleでは、Billionユーザの大きなデータを日々受け取っている

BigQuery の外にあるデータも分析できる

https://cloud.google.com/bigquery/external-data-sources

Bigqueryでは、構造化したデータしか扱えないので、複雑な処理はGoogle Dataflow

2016年12月29日
から hiruta
Google Cloud FunctionsでLINE Botサーバーを立てる #gcpug #gcpja はコメントを受け付けていません。

Google Cloud FunctionsでLINE Botサーバーを立てる #gcpug #gcpja

Cloud Functions でLINE Botサーバーを立ててみました。

LINE BOTアカウントの作成、LINE@MANAGERの設定は以下を参照

http://qiita.com/saitoryc/items/9f5833495d1e0453e052

AWS Lambdaの場合API Gatewayと併用しないといけないが、Google Cloud FunctionsだとHTTP Triger (HTTPS)でFunctionsを実行できるので、便利です。

LINE BOTサーバーはHTTPS通信できることが必要ですが、Cloud functions HTTP TriggerはHTTPSに対応済みなので、この点問題はありません。

実際のコードですが、Cloud Functions用の引数に変更する点と、HTTP通信でMessageAPIサーバに送信する際、Content-Lengthヘッダーを付与するようにしています。付与しないとMessageAPIサーバーからBad Requestと返ってきます。この点、LINE developersのドキュメントには記載されていません。


var gcloud = require('gcloud')({
projectId: process.env.GCP_PROJECT
});
var https = require('https');
var channel_access_token = '[ACCESS TOKEN]';

exports.linebot = function (req, res) {
var json = req.body;
json.events.forEach ( function(message,index){
events = message;
});
var postData = {
"replyToken" : events.replyToken,
"messages" : [
{
"type" : "text",
"text" : events.message.text
}
]
};
var options = {
hostname: 'api.line.me',
path: '/v2/bot/message/reply',
headers: {
"Content-type": "application/json; charset=UTF-8",
"Authorization": "Bearer " +channel_access_token,
"Content-Length": JSON.stringify(postData).length
},
method: 'POST',
};

var req = https.request(options, function(res){
res.on('data', function(chunk){
}).on('error', function(err){
console.log(err);
}).on('end', function(){
console.log('finish sending text message');
});
});
var sendData = JSON.stringify(postData);
req.write(sendData);
req.end();
};

Cloud Vision APIとかGoogleAPIと連携も可能かと思われます。

Content-Lengthで文字数をカウントする際、postData.lengthの代わりにBuffer.byteLength (postData)で文字数をカウントすることで日本語とかも送信が可能になりました。