クラウドインフラ構築記

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

本日（ていうか日付変わっていたので昨日）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ドライバもあるが

ザ・プリンス パークタワー東京で開催中の 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の方がレスポンスは良かった。