クラウドインフラ構築記

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

2015年5月16日
から hiruta
第二回 GCPUG Tokyo に参加しました。 #gcpug はコメントを受け付けていません

第二回 GCPUG Tokyo に参加しました。 #gcpug

昨日、第二回 GCPUG Tokyo に参加しました。GCPUG  Fukuokaと被るFirebaseについては割愛。別ブログ記事に記載してあるので、そちらを参照ください。

新しいストレージサービス Cloud BigTable

Googleのインターナルなサービス、GMail、youtube等、に使われている Key-Value型データベース。

Cloud BigTableを利用して、GCPの1サービスとしてCloud storeが稼働している

Tableserver failureも、1秒で復旧。ユーザが認識しなくていいリカバリ。

Managed Service No SSH、No VMインスタンス

AWSのDynamoDBににているサービスとのこと

HBase Client互換。HBaseのシステム構成に似ている。

現時点(ベータ)では、SDD Storageのみだが、HDD Storageにも近日対応とのこと ※HDD Storage $0.036/GB-Month)

ユースケース IoT、マーケティング、金融、エネルギー、通信

Cloud Dataflow

ノード数が計算に必要な分だけVMインスタンスを起動してくれる。※インスタンスタイプとかは指定できるとのこと

デモでは、VMインスタンスが自動で上がってきている点、BigQueryにデータが入っている点を行われていました。

Cloud Dataflowに似ているものに、Kinesis KCLアプリケーションがあるが、Consumer(ノードに相当)がスケール処理は別途考慮が必要なので、Cloud Dataflowの方がサイジングとか低減が図れるのではと思いました。

GCPで知られていない便利な機能の紹介

  • Goolge Cloud Registory

Git リポジトリ。Githubとかとの同期もできる模様。/ にコードがないとリンクが張られないいけていない。今後の改善には期待したい。

  • Push To Deploy ( Release pipline )

jenkinsを起動してねの一文が書いてあるだけのページになっている

  • Goolge Cloud Trace
  • Cloud Debugger
  • Google cloud Respositories

docker のprivate respositoryをGCSをストレージとして作成できるサービス。

  • Google Metadata Server

AWSに同様のものがあるが、こちらのほうが高機能。etcdよりは劣る。

metadataに関して、個人的に記載したものを記載しておきます。(http://qiita.com/web_se/items/b129d13cdf76b07bb1f1 )

  • startup script / shutdown script

VMインスタンスを起動時、シャットダウン時に読み込ませるスクリプト。AWSだとuser-dataに相当。AWSのuserdataと異なる点は、GCSにスクリプト本体を置いておき、ロードさせることが可能な点。

過去個人的に記載したものを記載しておきます。( http://www.totalsolution.biz/startup-script%e3%80%81shutdown-script-gcpja/ )

AWS Simple IconのようなサービスのIcon集の公開が望まれる。(現在パートナー企業のみ限定公開されているとのこと)

2015年5月14日
から hiruta
【新サービス】S3 VPCエンドポイント発表! #jawsug はコメントを受け付けていません

【新サービス】S3 VPCエンドポイント発表! #jawsug

http://aws.typepad.com/aws_japan/2015/05/vpcendpointfors3.html にリリースされたS3 VPC エンドポイントを検証してみました。

今までのEC2からS3にアクセスするパターン

IGW-パターン

 

 

VPC End Pointを利用したS3のアクセスパターン

VPCEnd-パターン

 

VPC Endpointを作成する際、ルート情報を自動で入れることが可能です。作成の際、以下にチェックを入れます。

rt

 

ルーティングテーブルに以下のように登録されるのがわかります。下画像から東京リージョンのS3のエンドポイントにルートが設定されているのがわかります。

 

screencapture-ap-northeast-1-console-aws-amazon-com-vpc-home-1431608334790

環境は以下で実施

  • AmazonLinux 2015.03 (HVM)
  • インスタンスタイプ m3.medium
  • リージョンはEC2、S3とも東京リージョンとする

1G ダミーファイルをS3にPUTをAWS CLIを利用して、3度ずつ実施

VPCEndpoint経由で検証した際、curlでHTTP通信ができないことを確認

パターン 1回目 2回目 3回目
IGW経由 28s 33s 33s
VPCEndpoint経由 29s 28s 29s

IGW経由とほぼ変わらない、極端に早くなることはなかった。

DB on EC2などIGWを付けないVPCでサーバーのログをS3に退避するとき、IGWの負荷を下げるなどで活用できるのではと思われます。

VPC Endpointを設定できる AWS CLIのコマンドはまだ公開されていない模様。

aws cli 1.7.27で対応。

<pre>  create-vpc-endpoint
[--dry-run | --no-dry-run]
--vpc-id <value>
--service-name <value>
[--policy-document <value>]
[--route-table-ids <value>]
[--client-token <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton]</pre>

2015年5月10日
から hiruta
AWS EC2とGCEを比較してみました はコメントを受け付けていません

AWS EC2とGCEを比較してみました

AWS EC2とGCEを比較してみました。

インスタンスタイプ

AWS EC2の方が提供されているインスタンスタイプは多いが、n1-standard-1レベルでi2レベルのパフォーマンスが出るとここと。(→ここ  を参照)

AWS EC2 GCE
Type mem price Type mem price
汎用インスタンス※お試しインスタンス
t2.micro 1 0.02 f1-micro 0.6 0.013
t2.small 2 0.04 g1-small 1.7 0.0347
t2.medium 4 0.08
標準インスタンス
m3.medium 3.75 0.101 n1-standard-1 3.75 0.069
m3.large 7.5 0.203 n1-standard-2 7.5 0.138
m3.xlarge 15 0.405 n1-standard-4 15 0.276
m3.2xlarge 30 0.810 n1-standard-8 30 0.552
n1-standard-16 60 1.104
コンピューティング向最適化インスタンス
c3.large 3.75 0.128 n1-highcpu-2 1.8 0.086
c3.xlarge 7.5 0.255 n1-highcpu-4 3.6 0.172
c3.2xlarge 15 0.511 n1-highcpu-8 7.2 0.344
c3.4xlarge 122 1.0211 n1-highcpu-16 14.40 0.688
c3.8xlarge 244 2.043
メモリ最適化インスタンス
r3.large 15.25 0.210 n1-highmem-2 13 0.162
r3.xlarge 30.5 0.420 n1-highmem-4 26 0.324
r3.2xlarge 61 0.840 n1-highmem-8 52 0.648
r3.4xkarge 122 1.680 n1-highmem-16 104 1.296
r3.8xlarge 244 3.360
ストレージ最適化インスタンス
i2.large 30.25 1.001
i2.xlarge 61 2.001
i2.4xlarge 122 4.002
i2.8xlarge 244 8.004

 

揮発性ディスク

AWS GCE
インスタンスストア LocalSSD

インスタンスストアとLocalSSDのパフォーマンスを以前取得してみたページはここ を参照

LocalSSDは、300GB x1からインスタンスタイプによる制限なく利用できる

可用性

AWS GCE
EC2 Auto Recovery Liveマイグレーション
インスタンスストア付インスタンスには対応していないイベントキックがCloudWatch バックで動作する

GCE Liveマイグレーションについては、http://qiita.com/kazunori279/items/41520689337a644a87b4 に書かれています。

AutoScaling

AWS GCE
AutoscalingGroup
AutoScalingLaunchConfiguration
インスタンスグループ
インスタンステンプレート
AutoScaler
Rolling Updateテンプレートからスタートアップスクリプトを分離することができる

ネットワーク

AWS GCE
リージョン、ゾーンを意識 リージョン、ゾーンを意識しないリージョンが異なるインスタンスに同じPrivate IP CIDRを割り当てることができる

 

 

 

ファイアウォール

AWS GCE
EC2ごとに最低1つのSecurity Group ネットワークに1つ

負荷分散

AWS GCE
ELBinternalなクローズなロードバランサーが作成可 HTTPロードバランサHTTPロードバランサーに割り当てられるIPがGoogleUSが保持しているIPが割り当てられる暖気無で100万リクエスト/秒を裁ける性能

料金割引

AWS GCE
最低1年のRIを契約が要途中契約が不可。(USの銀行口座がある場合は売却が可能) 事前契約無の長期継続割引(月単位も可能)

 

 

2015年5月6日
から hiruta
startup-script、shutdown-script について #gcpja はコメントを受け付けていません

startup-script、shutdown-script について #gcpja

インスタンス起動時にサーバー固有の設定を行うのに、startup-script(cloud-init?)という機能があります。

スタートアップスクリプト、シャットダウンスクリプトをinstance-template等で以下で指定できます。AWSだと、userdata scriptが相当しますが、AWSの場合、Launch Configrationに組み込まれてしまっており、userdata scriptを変更する際、Launch Configrationの作り直しが必要だが、GCEではGoogle Cloud Storageなど、instance-templateから分けることができますので、scriptだけ変更することも可能。anoymous accessを使うため、Google Cloud Storageにscriptを置く際、public-readできるようにしておく必要があります。→ここ

また、shutdown-scriptは、AWSだとAutoScaling lifecycle hookに相当するものと思われます。

--metadata startup-script-url=gs://h-XXXX-XXXX/startup.sh shutdown-script-url=gs://h-XXXX-XXXX/mackerel-retire.sh

登録されると、WEB UI等に下記のように確認することができます。

screencapture-console-developers-google-com-project-skillful-fx-531-compute-instancesDetail-zones-asia-east1-a-instances-instance-group-1-kglv-1430876084443

 

画面(上記のSerial console output)、CLI commandでstartupscriptのログを確認することができます。コンソール出力だと「startupscript:」の行がスタートアップスクリプトのログになります。

gcloud compute instances <instance id> get-serial-port-output instance-1

screencapture-console-developers-google-com

 

 

2015年5月5日
から hiruta
Azure DNS previewの価格を比較してみました。 はコメントを受け付けていません

Azure DNS previewの価格を比較してみました。

http://azure.microsoft.com/en-us/pricing/details/dns/ で、Azure DNS previewが発表されました。ただし、previewということで、AzureDNSへのアクセス方法は、PowerShellのみです。

料金も公開されていましたので、早速Cloud DNSと料金を比較してみました。結論、ほぼ同等の料金形態です。

Cloud DNS Azure DNSpreview
HostZone(25 zoneまで) $0.2 $0.25
HostZone(25zone以上) $0.1 $0.05
DNS クエリ(10億まで) $0.4 $0.2
DNS クエリ(10億以上) $0.2 $0.1
アクセス方法 cli(gcloud)、web PowerShell
ドメインレジストラ

2015年4月29日
から hiruta
instance groupのRolling Updateでinstance templateを更新 #gcpja はコメントを受け付けていません

instance groupのRolling Updateでinstance templateを更新 #gcpja

instance groupを使う場合、instance templateが必要になり、なんらかでinstance templateの更新が必要になった場合、インスタンスの再立ち上げなり必要になります。今回試したのが、無停止でインスタンスの更新を行えるRolling Updateになります。

https://cloud.google.com/compute/docs/instance-groups/manager/

screencapture-cloud-google-com-compute-docs-instance-groups-manager-1430285617901

変更前のインスタンステンプレートを作成します。

gcloud compute  instance-templates create demo-instance-template-1 --machine-type n1-standard-1 --network product-network --maintenance-policy MIGRATE --scopes "https://www.googleapis.com/auth/compute" "https://www.googleapis.com/auth/devstorage.read_write" "https://www.googleapis.com/auth/bigquery" "https://www.googleapis.com/auth/sqlservice.admin" "https://www.googleapis.com/auth/logging.write" --image centos-7 --boot-disk-type pd-standard  --metadata startup-script-url=gs://h-private-auto/startup_demo.sh --boot-disk-device-name demo-instance-template-1

インスタンスグループを作成します。

gcloud preview managed-instance-groups --zone asia-east1-a create demo-instance-group-1 --base-instance-name demo-instance-group-1 --template demo-instance-template-1 --size 2

HTTPロードバランサーのためのヘルスチェックを作成します。

gcloud compute  http-health-checks create "demo-health-check" --port "80" --request-path "/index.html" --check-interval "5" --timeout "5" --unhealthy-threshold "2" --healthy-threshold "2"

HTTPロードバランサーを作成しておきます。

gcloud preview instance-groups --zone asia-east1-a add-service demo-instance-group-1 --port 80 --service http
 gcloud compute backend-services create demo-web-service --http-health-check demo-health-check
gcloud compute backend-services add-backend demo-web-service --group demo-instance-group-1 --zone asia-east1-a
gcloud compute url-maps create demo-web-map --default-service demo-web-service
gcloud compute target-http-proxies create demo-web-proxy --url-map demo-web-map
gcloud compute forwarding-rules create http-rule --global \
    --target-http-proxy demo-web-proxy --port-range 80

ロードバランサにExternal IP (グローバルIPアドレス)が割り当てられます。
変更後のインスタンステンプレートのためのstartup scriptを作成します。

#! /bin/bash

timedatectl set-timezone Asia/Tokyo

PRIVATE_IP=`curl "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip" -H "Metadata-Flavor: Google"`
INSTANCE_ID=`curl -s http://metadata.google.internal/computeMetadata/v1/instance/hostname -H "Metadata-Flavor: Google" | cut -d "." -f 1`

yum -y install httpd
service httpd start

cat >/var/www/html/index.html <<EOF
renew $INSTANCE_ID
EOF

変更後のインスタンステンプレートを作成します。

gcloud compute  instance-templates create demo-instance-template-2 --machine-type n1-standard-1 --network product-network --maintenance-policy MIGRATE --scopes "https://www.googleapis.com/auth/compute" "https://www.googleapis.com/auth/devstorage.read_write" "https://www.googleapis.com/auth/bigquery" "https://www.googleapis.com/auth/sqlservice.admin" "https://www.googleapis.com/auth/logging.write" --image centos-7 --boot-disk-type pd-standard  --metadata startup-script-url=gs://h-private-auto/startup_demo_2.sh --boot-disk-device-name demo-instance-template-2

set-templateでインスタンステンプレートを変更することも可能ですが、こちらだとインスタンスは自動では変更になりません。

 gcloud preview managed-instance-groups --zone asia-east1-a  set-template demo-instance-group-1 --template demo-instance-template-1

インスタンステンプレートのローリングアップデートを行うには、下記のようにします。インスタンスが起動立ち上がってくる時間を考慮する必要があるので、–min-instance-update-timeオプションを指定しています。(このオプションを指定しないと片方のインスタンスが準備ができる前にもう片方のインスタンスの更新が始まり、Server Errorが起きました)

 gcloud preview rolling-updates --zone asia-east1-a start --group demo-instance-group-1 --template demo-instance-template-2 --min-instance-update-time 360s

5秒間隔でcurlコマンドにてhttpアクセスを定期的にしましたが、アクセスエラーを起こすことなくインスタンステンプレートの更新が行えました。※AWSのAutoScalingでは実現されていない機能。AWSでは、ElasticBeanstalkを使うことでRolling Updateが可能のようです。

screencapture-cloud-google-com-compute-docs-instance-groups-manager-1430286981365
Instance Group Update ServiceのAlpha versionでも将来仕様が変更になる場合があるかもしれません。

2015年4月11日
から hiruta
GCPUG in Fukuoka 1st 「最新のビックデータ解析・リアルタイムモバイル開発を学ぶ」 #gcpug はコメントを受け付けていません

GCPUG in Fukuoka 1st 「最新のビックデータ解析・リアルタイムモバイル開発を学ぶ」 #gcpug

本日のGCPUG in Fukuoka 1st でした。(初福岡でもありましたけど)

「Google BigQueryとCloud Dataflowでかんたんビッグデータ分析」Google デベロッパーアドボケイト 佐藤 一憲氏 @kazunori_279

google検索のためのソフトウェア開発を10年ほどやってきた

市販のDBではまかないきれない

ベストなファイルシステムを作っていこう

GFS、MapReduce

1億人のアクセスログをjoinするとか、普通のDBだと止まる

けど、MapReduceは処理できてしまう

ものすごい規模で展開されている

Google 検索のインデックス規模は100PBを超えている

BigDataとの戦い

ログも何十TB

 

Adword 広告のサービス

APIのログを取ってみても、何TBになる

内部的には、Dremelのテクノロジ

Dremelのテクノロジを外のお客様に公開 = BigQuery

 

BigQueryについて

hadoop、MapReduce

百台のマシンにばらばらにして、データの整列とか並列に

安いサーバーでも並列で何百台で処理

簡単に使える。普通のSQLで

非エンジニアでの利用が多い。Google社内では。

他のユーザへの影響もない。

パフォーマンスも圧倒的に多い

デモ サンプル wiki10B wikiのデータを100億行のデータが入っている

 

タイトルに、「あいうえお」正規表現で実行

3s キャッシュオフでも

 

Storageのコストと検索のコスト

BigQueryは、S3より安い。ログをBigQueryに入れる案件も

 

アウトプットにGoogle スプレットシートで分析もできる。

 

Hadoop の解析結果をHBaseに入れる必要がある

 

Hadoopのプログラムテーブルに対して処理することができる

 

BIツール「BIME」について

BigQueryはあらかじめインデックスを作っておく必要がない

 

なんで速いのか

データ分析用のデータベース

行の更新はできない

行の追加のみ

ログ

カラム単位で違うディスクに入れておくカラムベースストレージ

スコアだけ集計したいとき、ストアデータだけ読んできて解析

何千台のサーバーを自由で使える

Googleのサーバーは用途で分けていない

他のクラウドベンダーではありえないこと

全てのサーバーはGoogleのサービスに共有できる

Google検索の仕組みをそのまま使ったのがBigQuery

他社のクラウドベンダーには難しいのでは

100億行のデータ + join + 10億行でhadoopでやろうとすると数十分

BigQueryだと、3min

Fluendとの組み合わせが便利

Dataflow

Dataflowは現在は、α版。ただβも近いうちにリリースされるとのこと。

BigQueryにデータをインポートする必要がある

データによっては、クレンジングが必要なデータもある

ETL データをリードして、不要なデータをはずすとか

Flume MapReduceの上で動くフレームワーク

MapReduce

処理が多段に。

多段の処理を組み立てるのがめんどくさい

データのパイプラインをプログラムコードで書く。MapReduceで自動生成 →Flume

何台くらいで動かすのか最適化も自動でやってくれる

最適な台数を見つけるのに、MapReduceを何台か回す →Flumeが勝手にやってくれる

 

MilWheel ストリーム処理

広告基盤でリアルタイム処理する必要。インプレッションとか

リアルタイム集計したい

 

flume、MilWhelをベースに作り直したのがDataflow

 

Full Managementで提供すたのがDataflow

 

バッチ処理、ストリーミング処理も。複数のDBを統合も

関数プログラミングで

バッチとストリーム処理両方に適用

運用コストも掛からない

SDKもオープンソース

実装を変えることもできる

 

GroupByKey

Sで始めるものとか実行できる

 

Fixed Windows 1hおき

Sliding ストリーミング

 

Direct Runner 手元で確かめる

Cloud Dataflow Service Runner

GCEインスタンス上で

 

Spark-dataflow

Dataflowを実装した例も

 

過去のデータがGCS

結果はBigQuery上で

ユーザがビデオ見て終わるのを3minごとにWindowで集計する例

Pipelineの定義

テキストデータのparse

カンマ区切りのデータをばらす

アーカイブに保存

BigQueryのデータのカラムに入れる

ランキングを集計

を並列に

裏でGCEのインスタンスが起動して処理する

起動する台数は、キモ細かく制御できる。

DataflowのアーキテクチャーはAsakusa Frameworkに近いとのこと。Kinesisにも近そうだが、違な点も。

「Firebaseによるリアルタイムモバイル開発」Google デベロッパーアドボケイト Ian Lewis氏 @IanMLewis

時代は、モバイルにシフト

モバイルを使っているユーザが多い

パソコンと両方使っている人も多いが、モバイルにシフト

モバイル対応を考えるときに課題も

マルチデバイス スマホ、タブレットそれぞれ iOS、Androidか多岐に渡っている

ソフトウェアも変わるので、開発も困難

これから、Wear、TV、自動車も

バックエンドサーバーも

初めての人が構築するのは難しい

モバイルは移動が前提なので、移動した場合にも対応も

 

そこで、Firebaseを使うとなぜ便利か

 

リアルタイムDB、ユーザ管理、ファイルホスティング

 

DBは、NoSQL

SQLを使わない。JSON

ミリ秒単位で更新

スマホ、Firebaseごとにデータを保持。それぞれsyncしている

データを保存するだけでsync

オフライン、ネットワークが不安定になっても、読み込んだりできて、接続したらsyncしてくれる

 

ユーザ管理も柔軟に

 

CDNも勝手にやってくれる

 

Npm install -g firebase-toolsでfirebase command line toolsを入れられる。(→ここ

 

Firebase init セキュリティの設定とかかかれているjsonファイルが取得される

ファイルホスティング対象しないようにもできる

正規表現でマッチングすることもできる

 

Firebase deply アップロード

 

認証とオンライン状態

twiter側でアプリを作成。ClientIdを登録。認証用のCallbackでID、パスワードを入れて自分のアプリにリターン

 

ユーザがオンラインになったら、通知をしてくれる。モバイルの場合、ねっとわーくの状態が変わるので、この辺の設計が大変になるが、firebaseをネットワークの状態をみて、処理を書くことができる

 

課金プランは、コネクション数。

超えた場合は、アプリが動かなくなるのではなく、超えた分は課金される

 

Google docsのアプリのようなものを作るのは簡単

 

GCEハンズオンワークショップ 吉積情報 吉積礼敏氏

GCE + CloudSQLでwordpressを立ち上げるハンズオン。テキストは下記に公開されています。

goo.gl/ua5fQw

https://github.com/gcpug/gcp-demos

プロジェクトIDとプロジェクト名は同じにしておくといい。プロジェクトIDはGCP Commnad line toolsとかに利用するので。

ハンズオン形式なので、気になった点を2,3点

画面でもインスタンスを起動できるが、コマンドだと以下のようになります。

gcloud compute instances create handon-20150411-01 –machine-type n1-standard-1   –image “https://www.googleapis.com/compute/v1/projects/ubuntu-os-cloud/global/images/ubuntu-1404-trusty-v20150316”   –network product-network –boot-disk-type “pd-ssd” –zone “asia-east1-a”

ハンズオン途中で、gcloud compute instances createでVMインスタンス作る際、特定zoneでエラーになった。

– The zone ‘projects/XXXXXX/zones/asia-east1-a’ does not have enough resources available to fulfill the request. Try a different zone, or try again later.

ただ、ホテルに戻った後、再トライしたところ、問題なかったので、まれにインスタンスが起動できないことがある(とのこと)。

CloudSQLインスタンスを画面から作成。※ここだけは、コマンドが確認できない

RDSのインスタンス生成より劇的に速い。

cloud sql instances create wp-demo –region asia-east1 –assign-ip –authorized-network 107.XXX.XXX.XXX

5.6系はベータなので、GA Releaseを。

VMインスタンスに元々Google Command Line Tools ( gcloud )が入っているが、ただバージョンが古いとかasia-east-1 zoneを認識しない問題があるようです。

Manage Cloud SQL Instances by Cloud SDK →https://cloud.google.com/sql/docs/cloud-sdk

CloudSQLもCLIでReadReplica作成、バックアップWindowの設定などできる。

ただ、CLIによるDBユーザ追加のコマンドの記載がない。ハンズオンでは画面からDBユーザ作成を行った。ユーザ制御のCLIコマンドを探してはいるが、現状見つけられていません。

最後に。

BigQuery、Dataflowと「Big-DataはGoogle」と言えるほど、Googleのインフラ基盤はすごいと再認識できた勉強会でした。

Carrier Interconnectは現在テスト中とのこと。近々利用できるようなことも

2015年3月30日
から hiruta
第11回クラウドごった煮参加レポート #cloudmix はコメントを受け付けていません

第11回クラウドごった煮参加レポート #cloudmix

3/28 産業技術大学院大学で開催されたクラウドごった煮勉強会参加レポートになります。

コンテナ技術は、GKEをはじめとするコンテナ管理ツールが充実、OSレベルでもRHEL Atomic Host、CoreOSと選択肢はできてきた印象。開発環境だけでなく、production環境にも採用してきている一番盛り上がっている技術でもある。

IBM Containers

IBMとDocker社と戦略的パートナーとして提携

IBM Bluemix(PaaS)上で提供されている。

SoftLayer上にPaaSを実装

Bluemix = Cloud FoundryベースのPaaS

Dockerの実行環境とプライベートリポジトリを公開している

Bluemix のホストは、SoftLayerのベアメタルサーバー上で動作している

iceがcf(CloudfoundryのCLIツール)とか隠蔽しているとのこと

 

RHEL Atomic Host

/varだけ書き換えられる。監視ツールを入れたい場合は、コンテナに。

Kubernetes and Google Containers Engine (GKE)

Pods 密結合したコンテナの集まり。

yaml に、いくつ起動するか記載して、コンテナが落ちた際に起動する

特定のIPアドレスを持たせる

数ヶ月のうちに、Versionは、1.0となるとのこと。

数十Podsを扱えるようになる。

Private リポジトリをCloud Storageに作成できる

DockerHubのプライベートリポジトリは参照できない模様。

AmazonLinux Docker Imageを、GCE上のdocker実行環境でrunするところまでは確認しましたので、GKEを使って上げ下げをトライ中。詳細は別記事にて記載します。

Docker Machine

Apache Mesos

クラスタ環境の管理ツール

10,000スケール程度まで可

ヘッドノードを可用性で ZooKeeper

実行環境をジョブごとに変えられる

Mesos DNS

IPがわかっても、ポートがわからないと ポート番号が分からないとアクセスできない

Rancher.ioを試してみる

[slideshare id=46435599&doc=rancher-150330021249-conversion-gate01]

クラスタを管理するシステム
Docker版Opn Stackのようなイメージ
リソースの監視もできる。

Docker run -p 8080:8080 rancher/server
ホストの追加はWEB UIで
導入は楽。コンテナが動けば動いてしまう。
コンテナで括っているので、拡張性がない
今はセキュリティグループはない。今後実装予定
https://github.com/stevef1uk/docker_for_rpi

Monitoring Docker with Mackerel

コンテナの監視もMackerelで。

Cgroup特有の情報は見えない
/sys/fs/cgroup/{cpuacct,memory}
リソース制御するのもこの辺をいじる
/sys/fs/cgroup/cpuacct/docker/{container id}/cpuacct.usage

メモリはcacheとかも
memory.stat

また、Radpberry Piでもmarchel agentは動く。

[slideshare id=46435598&doc=rpi-150330021248-conversion-gate01]

2015年3月27日
から hiruta
第二回Intel Edison 勉強会に初めて参加してみて #IntelEdisonUG はコメントを受け付けていません

第二回Intel Edison 勉強会に初めて参加してみて #IntelEdisonUG

今日Intel Edison 勉強会が、歌舞伎座タワー19F ドワンゴ様のセミナールームでありました。JAWS DAYSでHack Daysでハンズオンを受講しましたが、IoTに注視(IoTのインフラ基盤も)しています。

OSアップデート

OSアップデートは、Reboot otaではなく、flashall.batの方が。flashall.batだと設定がすべて初期化されます。Edisonが起動できなくなった場合にもflashall.batで復旧ができる。

Wi-Fiダイレクト(Edison同士をつなぐことができる。アドホックネットワークを構築できる?)や、パーティション割り当ての変更等、バグフィックスも多数。

後述の発表でもあるIoTで最適プロトコルと行っていいMQTTがはじめから使える(mosquitto、root権限で実行するとのことですが)

Edison を色々試してみた

[slideshare id=46309857&doc=edison-150326051335-conversion-gate01]

Edisonを組み込んだ(組み立てた)製品の紹介。

MQTTというTCP上で動くプロトコルについて

[slideshare id=46312662&doc=edison-mqtt-2015-03-26-150326063723-conversion-gate01]

IoTは、細切れのパケットを送受信するので、最適。シンガポールのDCに飛ばして、シンガポールのDCから送信するデモでしたが、距離を意識しないレイテンシでした。(WICEDを使ったデモ)

MQTT as Service sango という MQTTのManaged Serviceの紹介話も。 sangoのインフラ基盤はDigital Occeanとのこと。IoT通信の場合、かなりの数のIoTデバイスがサーバーにアクセスすることも考えられるので、データ転送量の考慮も必要。

MQTT通信スクリプトが書ける MQTTCLI (https://github.com/shirou/mqttcli)もあるが、本セッションでnode.jsを使ったMQTT通信の話。

Edison v.s Raspherry Pi徹底比較

Edisonは軽量。消費電力が低い。インターフェースにWi-Fi Dual band(2.4G/5G)、Bluetoothがあり、Raspherry PiがEthernetのみに比べて、優位。ストレージは、SDカードが使えるRaspherry Piには劣りますが。Raspherry PiがPCに近い位置づけと考慮すると納得。

AtomのCPUでDual Core。32bit OSですが、64bitを疑似ですが、問題なく演算ができる。

2015年3月23日
から hiruta
JAWS DAYS 2015に参加しました。 #jawsug #jawsdays はコメントを受け付けていません

JAWS DAYS 2015に参加しました。 #jawsug #jawsdays

昨日開催されたベルサイド新宿グラウンドで開催されたJAWS-UG 1年に1度のビックイベント「JAWS DAYS 2015」に参加しました。JAWS-UG歴も振り返ってみました。

[Aceに聞け] cloudtrailとconfigによるセキュリティ強化のための第一歩

1

 

はじめてのIoT 〜 IoTデバイスとクラウドの素敵な関係 〜

IoTデバイスとクラウドを使ってセンサーハック 〜 データ可視化 〜

2

 

午前の部は、Edisonにサンプルのnode.jsをアップロード、ビルド、実行し、LEDセンサーが点灯するサンプル等を試しました。(1xGrove – Rotary Angle Sensorのトグルがoffになっていると点灯もされません。)

 

午後の部は、Kinesis、Cognitoを使って、Edisonのセンサーから取得されたデータをグラフ化+S3にデータをアップロード/DynamoDBへのデータ挿入までハンズオン形式で行いました。

グラフ化とS3アップするKinesisアプリケーションを動かすEC2は分けるとグラフ化とデータ蓄積をマルチで行えます。午後Part 1のセッションでは、EC2 x1でしたので、ハンズオンでは、ここまでは確認はしませんでした。

Edisonを始めたい方は、Grove – Starter Kit for Arduinoも一緒に購入するのがお勧め。(今日購入しました。)

“モノ”をクラウドへつなぎやすくするための取組/技術/アーキテクチャ

IoT動向、海外イベントの話から、IoTアーキテクチャー

3

IoTは95年時代のインターネットのブームに似ている。生活家電にIoTデバイスが組み込まれ、インターネットに接続される時代が近い将来くる。収集・蓄積・分析のトライアングルが重要

IoT時代のデータ伝送とインフラに求められている機能

4

IoTのクラウドからの反応速度は、1秒。かなりシビアな用件が求められる。IoTゲートウェアに機能を詰め込みすぎず、最低限の機能で実装するのが求められる。設置場所も簡単に交換するのが難しいところに設置されるケースもあるので。(MDFの中とか)

cloudtrail以外には、IoTを中心というか、IoT一色になっていました。

午前の部のHack DaysがトグルがOFFになっているため、LEDが付かない原因に至るまで時間がかかりました。

最もリツイートが多かったツイートは

IoTのネットワークは、「運用でカバー」で対応は難しいとのこと。ゲートウェイはシンプルに。(credeitalsキーをIoT deviceの中に入れるのは論外。Cognitoを使って、AWSサービスにアクセスする)

JAWS-UGの勉強会には、意外に一年半前に開催された

screencapture-jawsug-chiba-doorkeeper-jp-events-6891

 でした。

ビックのイベントとしては、DAYSの他には、JAWS-UG三都物語てところ。(re:Invent 2014に去年初めて参加しましたが)
AWSのアカウント自体は、6-7年前には作っていた記憶が。(EC2-Classicが使える、Default VPCが使える。AWS CLIのハンズオンでは。。。)

最近は、Google Could Platformのユーザグループ「GCPUG」にも参加していますなど、個人的には、GCE、GCE Auto Scaler、GKE、Google Dataflowなど検証しております。

4/11にはこちらにも →ここ (立ち見でいいのであれば今からでも申し込みできます) Google Dataflowの話とか、GCEハンズオンワークショップなどもかなり盛りだくさんの内容になります。

screencapture-gcpugfukuoka-connpass-com-event-13204