クラウドインフラ構築記

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

2016年12月5日
から hiruta
Amazon AthenaのPartitioningについて #jawsug #gcpug はコメントを受け付けていません。

Amazon AthenaのPartitioningについて #jawsug #gcpug

https://cloud.google.com/storage/docs/public-datasets/landsat からダウンロードできるデータで、Amazon Athenaをつかって、クエリを実行してみました。

テーブル構成は以下の通りです。

CREATE EXTERNAL TABLE athena_test.landsat_data_csv (
SCENE_ID STRING,
PRODUCT_ID INT,
SPACECRAFT_ID STRING,
SENSOR_ID STRING,
DATE_ACQUIRED DATE,
COLLECTION_NUMBER STRING,
COLLECTION_CATEGORY STRING,
SENSING_TIME timestamp ,
DATA_TYPE STRING,
WRS_PATH INT,
WRS_ROW INT,
CLOUD_COVER decimal ,
NORTH_LAT decimal,
SOUTH_LAT decimal,
WEST_LON decimal,
EAST_LON decimal,
TOTAL_SIZE decimal,
BASE_URL STRING
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
ESCAPED BY '\\'
LINES TERMINATED BY '\n'
LOCATION 's3://athena-test-data01/csv/';

単一のCSVでは、Partitioningでデータスキャンする容量を減らすことは不可。(Partitioningのために、S3上でフォルダが分かれてファイルが配置されていないといけないため)

Amazon Athenaの課金は、スキャンするサイズによるので、課金にもろ響きます。Athena破産の可能性も。

screencapture-console-aws-amazon-athena-home-1480936289615

データスキャンした容量は、968MB (CSVのファイルサイズと同じなので、全スキャン)が読まれます。

screencapture-bigquery-cloud-google-results-cms-production-1225-bquijob_780f3acf_158cebfd84f-1480937513091

一方、同じクエリでBigQueryで実行させるとほとんどスキャンされないで結果が返る。

BigqueryのようなことがAthenaでできると思ったら、間違いです。

2016年12月4日
から hiruta
GCPUG Shonan vol.9 (re:dash、Data Studio)によるVisualization #gcpug はコメントを受け付けていません。

GCPUG Shonan vol.9 (re:dash、Data Studio)によるVisualization #gcpug

GCPUG Shonan vol.9が本日ありました。お題は、BigQueryのデータのre:dash、DataStudioによるVisualization(可視化)でした。

サンプルデータのBigQueryへのインポート

 bq load --source_format=CSV --field_delimilter=',' --skip_loading_rows=1 --max_bad_records=1000 redash_shonan_handon.taxi gs://bq_shonan_handon/taxi.csv ./schema.json

Cloud Launcherにより、re:dashインスタンスの作成

※re:dash自体は、mac os x上のDocker上にも作ることは可能です。

IAMの設定だけでは、BigQuery Userの権限を与えておいても、re:dashでSELECT SQLすら権限がないよとなっていまいます。

Error running query: { "error": { "errors": [ { "domain": "global", "reason": "accessDenied", "message": "Access Denied: Table XXXXXXXXXXXXXXXXXXX:billing.201612: The user bqclient@XXXXXXXXXXXXXXXXXXX.iam.gserviceaccount.com does not have permission to query table XXXXXXXXXXXXXXXXXXX:billing.201612." } ], "code": 403, "message": "Access Denied: Table XXXXXXXXXXXXXXXXXXX:billing.201612: The user bqclient@XXXXXXXXXXXXXXXXXXX.iam.gserviceaccount.com does not have permission to query table XXXXXXXXXXXXXXXXXXX:billing.201612." } }

BigQueryのdatasetにおいて、Share datasetで最低Service Account名で権限を付与する必要があります。

screencapture-bigquery-cloud-google-queries-cms-production-1225-1480852442942

BigQueryの権限付与もIAMで一括して行ってほしい。

re:dash自体、0.12.0+b2449 (Cloud Launcherのばーじょんは少し古い)となっており、発展途上なところもあり、使い勝手的に?なところもあります。

Google Data Studio ( FREE版はレポートは5つまで)の紹介。re:dashはSQL(legacy SQL/Standard SQL)で組み立てるのが、Data Studioは、クエリの組み立てのカスタマイズは高くない。ただ、緯度経度情報があれば、MAPのコンポーネントがあるので、地図上にBigqueryのデータをplotすることは可能。コンポーネントについては揃っているように見えました。

(おまけ)re:inventで発表されたAmazon Athenaについて

Amazonが、BigQueryを意識して作ったと思いますが、Partitioning しないとCOUNTでもすべてのデータをスキャンしていまうこと。Partitioning Data することで、スキャンする量を制限はできそうですが。

Colossusの仕組みをAthenaで実現するのは不可能ではと思われる。

 

2016年11月13日
から hiruta
GCPUG しょうなん vol.8勉強会に参加しました。 #gcpug はコメントを受け付けていません。

GCPUG しょうなん vol.8勉強会に参加しました。 #gcpug

GCPUG しょうなん 一周年記念パーティとあり、GCP、GAEの2パネルディスカッションで進行しました。

スイートとかN.Gの話とかもありましたので、ここに書けないことも。

  • 東京リージョンの話

asia-east-1だと、時間により速度にむれがあるが、東京リージョンは安定している。

東京リージョンのWindows Serverインスタンスでデータコピーが速い

  • BigQuery

某データウェア製品と比べても、BigQueryはお安くできてしまう。

Bigqueryは、viewとか作成できますが、極力正規化すべき。(来年から価格体系が変わるらしい)

Auditログで、テーブルをフルスキャンする「SELECT *」しているユーザを特定することも。

  • Google Dataflow

GAE → Task Queue →プリエンプティブ インスタンス起動してやっていた処理も、Google Dataflow (Apache Beam)でかなりスマートにできる。 サポート言語は、Java、pythonだけど。

  • GAE

近年のサーバレスアーキテクチャーの流れで、PaaSが再注目。

プロジェクト作成時しかGAEのリージョン指定できないので、海外から東京リージョン(asia-northeast-1)に移行する際、プロジェクト作成から、IAM、Service Accountとかデータストア移行とかが発生する

App Engine Flexible Environment(FE)  1度の処理は保証されるTask Queueが使えるGCE

一周年記念パーティとのこともあり、料理も豪華でした。

15036550_1307693945971247_1726746184250435722_n

15027715_1307693989304576_4623979243900585908_n

15085621_1307705149303460_6262092848792538092_n

 

次回は、12/4予定とのこと。BigQueryとData StudioのVisualizationらしい。

2016年10月2日
から hiruta
CloudSQL Proxyを使用してCloudSQL SEに接続してみた。 #gcpja はコメントを受け付けていません。

CloudSQL Proxyを使用してCloudSQL SEに接続してみた。 #gcpja

CloudSQL インスタンスに接続するのに、通常の3306/tcpを行う方法とは別に、CloudSQL Proxyを使う方法があります。

CloudSQL Proxyを使わない場合、Authorized networksに、GCEインスタンスの外部向けIPアドレス(グローバルIP)を追加する必要があります。追加する必要がないのが、CloudSQL Proxyを使用した接続方法になります。

続きを読む →

2016年9月4日
から hiruta
ubuntuにjupyter notebookを導入 #jupyter はコメントを受け付けていません。

ubuntuにjupyter notebookを導入 #jupyter

9/1に、OSSユーザの勉強会 TensorFlow編でGoogle 中井様(@enakai00)から、jupyterでTensorFlowの話がありましたので、jupyter notebookをUbuntu 14.04に、jupyter notebook & TensorFlowをインストールしてみました。

続きを読む →

2016年7月26日
から hiruta
GCEにシリアルコンソール接続 はコメントを受け付けていません。

GCEにシリアルコンソール接続

getSerialPortOutputでもboot時のメッセージは確認はできますが、この方法だとread-onlyで、アクションを実行させることはできない。

シリアルコンソール接続てものが。

シリアルポート接続の有効化は以下コマンドで完了。

gcloud compute instances add-metadata [INSTANCE_NAME]  \
    --metadata=serial-port-enable=1

シリアルポート接続を有効にすると、Enable connecting to serail portsが有効化されます。Web UIでは有効にできなそう。

screencapture-console-cloud-google-com-compute-instancesDetail-zones-asia-east1-a-instances-instance-group-2-opjd-1469446491789

firewall ruleで22/tcpを閉じた状態でもコンソールのログインプロンプトが出ます。

https://cloud.google.com/compute/docs/instances/interacting-with-serial-console

注意書きにも書かれていますが、SSH鍵、IPアドレス、GCPプロジェクト名がわかっているとどこからでも接続できてしまう。IPベースのアクセス制限に対応してないとのこと

 

2016年7月24日
から hiruta
GCPUG信州の機械学習の勉強会に参加しました。 #gcpug はコメントを受け付けていません。

GCPUG信州の機械学習の勉強会に参加しました。 #gcpug

昨日GCPUG信州の機械学習がテーマの勉強会に参加してきました。

Google Cloud Platform概要

  • Googleのデータセンターの電力管理も、GoogleDeepMindにて、40%の削減
  • Googleのサーバーはリソース状況により、どのサービスに使われるか変わる
  • Googleのデータセンターの使用効率も80%
  • 1Pbpsのネットワーク
  • Region とZone。現在5つ。日本リージョンも近々?
  • AppEngineの起動は速い。Go言語だと40s位
  • インスタンス使用時間により、自動割引。同じマシンタイプを合算して割り引きしてくれる
  • Preemtible VMs Borgのプライオリティの低いサービスを利用
  • GCEのインスタンス課金は10分単位。10~20分程度の利用時間だと、1H課金のクラウドに比べ、単純に計算するだけでも、コストは1/2

Speech API

  • 文脈認識率は8割。Cortana、WindowsAPIはせいぜい3~4割※単語レベルは高いが。
  • US方言も。ただ、日本語の方言は対応していない
  • しゃべり言葉はあまりよくない?
  • Cloud Natural language API

Speech API、βリリースにあたり、長い時間の音声ファイルの認識に使えるAsyncRecognizeの新機能が。gRPCプロトコルを使用している
screencapture-mail-google-com-mail-u-0-1469332131909

TensorFlow

  • PythonAPI、C++ APIが提供されているが、Python APIを使うのがよさそう
  • 並列分散処理を簡単に実装できる。
  • アルゴリズムを実装する道具、位置づけ
  • APIも豊富 https://www.tensorflow.org/versions/r0.9/api_docs/python/index.html
  • TensorFlow独自のプロセッサーを作成していた(TPU)。AlphaGoも使用されていた。
  • ただ、GCEには、GPUインスタンスがない。GPUはCloud Machine Learningでは使えるとのこと。現在Limit Preview

CloudVisionAPIをIoTに

  • プライバシー保護が重要。人の顔にマスク(モザイク)を掛ける
  • APIベースなので、リソースが限られたRaspberryPiとかに有益

Docker

  • コンテナの粒度はアプリ単位
  • SwarmがDocker Engineに統合されたので、kubernatesとの使い分けはどうするか。今は過渡期

GCEをTensorFlow計算エンジン

  • パーセプトロン
  • バックプロパゲーション
  • 畳み込みCNN。画像認識に使われている
  • 過去にもネオコグニトロンと同等の機能があったが、ネットワークの性能、CPUパワーとかが当時に比べて向上したことで、DeepLearningが進化
  • gcloud config-ssh ssh configurationに、インスタンスのaliasを登録してくれる。ssh <instance>.<region>.<project>でアクセスが可能に。Ansibleで複数インスタンスで学習自動化するのに役に立つ

CloudVisionAPI、Speech API、バックでは、DeepLearning技術は使われているので、Googleの基盤を少しわかった気がします。

 

 

2016年7月23日
から hiruta
Internal Load Balancing 登場 #gcpja はコメントを受け付けていません。

Internal Load Balancing 登場 #gcpja

待望の Google Cloud Platform (GCP)にも、L4ベースInternal Load Balancingが登場。

Private IPアドレスのインスタンスでLoad Balancingも可能に。

まだ、使えないので、ドキュメントからわかる範囲で書いています。αサービスが使えるようになれば後日レポートします。

ドキュメントはこちらから。 https://cloud.google.com/compute/docs/load-balancing/internal/

主な特徴としては。

  • リージョン内のインスタンスにアクセスが可能。リージョン跨ぎでインスタンスをロードバランシングできない模様
  • ヘルスチェック ※133.211.0.0/22からの通信はFirewallなり許可しておく必要がる

もうPrivateなインスタンスのロードバランスの可用性に心配する必要がない

ユースケース

  • 3-Tier Web サービス(アプリケーションレイヤー、バックエンドデータベース)
  • データベースインスタンス他Internalなサービスのロードバランシング

Google Cloud Internal Load Balancingは、Andromeda network virtualization stack上に構築された lightweight load-balancing、インスタンスベースではなく、ソフトウェアベースのロードバランシング

気になる点

  • Load Balancing用IPの割り当て。手動とネットワーク内でIPを自動割り当てが可能?
gcloud alpha compute forwarding-rules create NAME --address ADDRESS --load-balancing-scheme internal 
  • Load Balancing用に割り当てられるPrivate IPはスケールアウトにより、MAX IPアドレスを割り当てる?

–capacity-scaler,–max-rate,–max-rate,-per-instanceのオプションはinternal load balacingでは使えません。

alphaバージョンでは以下制限があるようです。

  • 500インスタンスへのアクセスに制限
  • next-hop IP
  • VPNを通じた通信は行えない
  • オンプレからInternal Load Balancingへの通信は未サポート

三層構造のアーキテクチャー、イントラネット向けWEBインフラなどの構築に使えると思われます。