クラウドインフラ構築記

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

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

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

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

  • Dockerコンテナ goo.gl/48SBjC

  • Bulid Trigger config goo.gl/88ylgC

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が使えるゾーン展開も。

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 

昨日の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への対応が待たれるところ。

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程度ではCommitted Use Discountsでなくても、いいのでは。

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

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

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

We’re making Google Data Studio free for everyone: https://t.co/QlKJ7euMtl [create/share as many reports as you need, all for free]

— Google Analytics (@googleanalytics) 2017年2月2日

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

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がダメだとは書いていないようです。

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レベル

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

昨日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

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)で文字数をカウントすることで日本語とかも送信が可能になりました。