クラウドインフラ構築記

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

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

Cloud Spanner設計（PK、テーブル分割） #gcpja

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

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

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

Cloud Spanner概要

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

　リージョンなものの提供

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

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

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

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

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

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

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

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

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

インターリーブ

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

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

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

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

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

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

gRPC

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

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

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

　　try-errorを繰り返す

   セッション

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

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

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

　　MAX10,000

    Developer consoleのエラーレート

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

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

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

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

　　障害時も同

　　（ドキュメントに記載されていないことだが、）２GB per parent record

テーブル分割

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

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

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

　負荷試験は20-30分j実施

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

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

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

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

　TPS

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

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

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

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

Query Plan cache

  IDを変えると３つのキャッシュが作られるので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"
                     }
                  ]

２，３のシーンの解析結果

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

  • 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