クラウドインフラ構築記

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

2015年9月29日
から hiruta
第8回 コンテナ型仮想化の情報交換会@東京に参加しました。 #lxcjp はコメントを受け付けていません

第8回 コンテナ型仮想化の情報交換会@東京に参加しました。 #lxcjp

9月26日 IIJにて行われたコンテナ型仮想化の情報交換会Vol.8に参加しました。

Linux Namespaces

Hadoopでのコンテナ

Hadoop処理をコンテナで行う際のポイント

YARN http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html

NodeManagerが、OSレベルのメモリを監視していて、物理メモリがある一定量超えたら、OOM Killerでコンテナを強制終了

処理基盤は、割り当てたリソースをそれなりに使う。Unixベースのプロセスベースのコンテナにするか、cgroupで管理するか検討が必要。

(タイトル上はdocker pluginとなっているが、諸事情により、)docker-machine、docker-swarm

docker-machineはdocker engineだけで制御するように便利。インストールも簡単。

ただし、docker machineはrepositoryとしてdocker hubの選択肢がない。

docker swarm

containersのnodeへの割り当て方法を制御も。

kubernatesと同様コンテナ管理ソフトになるが、kubernatesはノードの利用率を偏ることない仕組みだが、swarmはspread/binpack/randomとノード割り当て方法を制御可能。ノードの使い方で検討が可能。

kubernatesも、どのNodeに割り当てるか、nodeSelectorラベルで制御ができます。

SmartOS入門

illumosから派生したLinuxであるSmartOS

LX Branded Zone

コンテナとしてdoker imageも扱えるが、起動しないことも。デモでは、core dumpが。

MINCS – Container in the shell script

シェルスクリプトでのコンテナ実装

https://github.com/mhiramat/mincs.git

FreeBSD Jail

カーネルをいじらないといけない。

docker on FreeBSDの話も。

ただし、ネットワーク(vnet)がうまく動かないとのこと

 LXD入門

本勉強会の主催者によるLXD入門。LXDは、LXCの置き換えではない。コンテナを作成したり、管理とここに書かれているので、一種のコンテナ管理ソフトか。

ここからLTになります。

FreeBSD VPS(Virtual Private System)によるライブマイグレーション

FreeBSDのコンテナ実装であるVPS(Virtual Private System)

FreeBSD 10系ではVPSは対応していないので、FreeBSD9系で試したとのこと

FreeBSD 10系でライブマイグレーションするとリストア時にkernel panic

FreeBSD 9系はEoLなので、FreeBSD最新版での正式対応が待たれるか。

同じ内容で、LTを行った方(@spg-games)がFreeBSD 10 VPS用のパッチを。。。 https://github.com/spg-games/vps

FreeBSD VPSでライブマイグレーションのデモをコンテナへのping疎通をモニタしながら、ライブマイグレーションを行いましたが、数秒(2~3秒)タイムアウトするだけで復旧。さすがに無停止で切替は難しいか。

どのセッションもかなりDeepな内容で、コンテナ技術の基盤について、あまりDeepすぎてわからない部分(namespace)もありましたが、コンテナ技術dockerだけでなく、多種多様なコンテナ技術を堪能できた一日になりました。

kubernateについて調べて今後は発表できればと思う。

2015年9月19日
から hiruta
JAWS-UG アーキテクチャ専門支部 CDP議論会 #1に参加してきました。 #jawsug はコメントを受け付けていません

JAWS-UG アーキテクチャ専門支部 CDP議論会 #1に参加してきました。 #jawsug

先日のJAWS-UGアーキテクチャー専門支部#2に議論参加側で参加してきました。

Blue-Green deployment パターン(EC2)実装編の叩き台

Blue-Green deploymentとしては、ELBによるもの、DNSによるもの実装としては2つある。

Opsworks、ElasticBeanstalkは、DNSベース。

Blue-Green Deploymentとは異なりますが、Rolling Updateの方法も。過去Rolling Updateの記事を参考までに。

今回は、Ec2のBlue-Green deploymentの話でしたが、Docker、No EC2の場合もあり、幅広くなりそう。

Lambda + API Gateway

受け付ける元がIoTデバイスの場合、100%の許容は必要ないのでは。Kinesisとかバッファリングできるので、少々のダウンとか許容できる

API Gatewayのベストプラスティス

Deploy APIで、ステージング環境(Stage)を作成できるので、Stage→ProductionでAPI GatewayのDeployment管理はできる、ただ、Lambda等組み合わせるので、こちらも考慮する必要があるか。Inheit from Stageで/(production)にoverrideも。

screencapture-us-west-2-console-aws-amazon-com-apigateway-home-1442656318044

 

API Gatewayはプロトコル変換が可能。Lambdaを使うと待機リソースが不要。

CodeDeply

デプロイ方式の議論から

  • AMI
  • userdata (cloud-init)
  • Chef/Ansible

Enterpriseの現場では、一番のAMIデプロイが多い。事実、tomcat、Apache等ミドルを入れ込んだ数種類のAMIを用意して、用途に合わせたサーバーを構築するケースもあります。AutoScalingの際、userdataがLaunch Configurationに組み込まれているので、userdata scriptで修正が生じた場合、Launch Configurationから作り直さなければならない。今後のアップデートを期待したい。

メリット

  • WebUI
  • AutoScaling時の自動適用

デメリット

  • ソースが、S3、githubのみ。
    • gitlab等プライベートリポジトリへは未対応。
  •  Internetへのアクセスが必要
    • S3のみに限定されているVPC Endpointの他のCodeCommit、DynamoDB等へ対応が待たれる。

CodeDepolyは開発環境で使うのいい?

DynamoDB Streams、Lambdaを使ったアーキテクチャーをまとめていければと思います。

次回はEc2を前提としないクラウドネイティブなCDP  10/15になります。

2015年9月18日
から hiruta
New Storage Class – Amazon S3 Standard – Infrequent Access #jawsug #gcpug はコメントを受け付けていません

New Storage Class – Amazon S3 Standard – Infrequent Access #jawsug #gcpug

9/16 2015 、Amazon S3 Storage の低コストストレージクラスとして、「Amazon S3 Standard – Infrequent Access ( 以下Standard-IA) 1」が発表されました。Standard-IAは、頻度に取り出さないデータ、長期間のファイル保存、バックアップ、DR向けとなっています。

auditなどの監査ログ系、アプリログなどの利用と考えられた設計となっています。取り出し料金が$0.01/GBがかかります。

なお、Standard-IAと利用用途が重なるGoogle Nearline Storageについても、同様$0.01/GBがかかります。

ゾーン限定の低価格Storage「Durable Reduced Availability (DRA) Storage」に相当するものはS3にはない。

AWS Google Cloud Platform
Standard Standard-IA Standard Durable Reduced Availability 

Storage

Nearline

Storage

-1TB $0.033 $0.019 $0.026 $0.02 $0.01
49TB $0.0324 $0.019
450TB $0.0319 $0.019
500TB $0.0313 $0.019
4,000TB $0.0308 $0.019
5,000TB $0.0302 $0.019

ネットワーク転送量は別途かかります。クラウドストレージへのアップロードはすべて無料。※GCPの場合、同じリージョン間のGCEとClud Storeageからのデータ取得は無料となっています。

S3の場合、バケットのライフサイクルポリシにTransitionsを設定させる必要があります。オブジェクトを更新してからxx日後にStandard-IAにするようにします。

{
  "Bucket": "xxxx-logs",
  "LifecycleConfiguration": {
      "Rules": [
      {
          "ID": "test_STANDARD_IA",
          "Prefix": "",
          "Status": "Enabled",
          "Transitions": [
          {
             "Days": 30,
             "StorageClass": "STANDARD_IA"
          }
          ]
       }
      ]
   }
}
aws s3api put-bucket-lifecycle-configuration --cli-input-json file://s3_standard_ia_lifecyclepolicy_config.json

AWS CLIは1.8.6で対応しています。

screencapture-aws-amazon-com-releasenotes-CLI-7507092461233524-1442623908846

リリース内容

1 https://aws.amazon.com/jp/about-aws/whats-new/2015/09/announcing-new-amazon-s3-storage-class-and-lower-glacier-prices/

2015年9月15日
から hiruta
JAWS-UGコンテナ支部vol.2 に参加しました。 #jawsug #jawsug_ct はコメントを受け付けていません

JAWS-UGコンテナ支部vol.2 に参加しました。 #jawsug #jawsug_ct

昨日、AmazonにてJAWS-UGコンテナ支部に参加しました。

ECSのサービス担当者によるAmazon ECS Case Study and Use Case

コンテナ

利用率の監視、モニタリングの監視が必要。セキュリティも。

コンテナの状態(Runningしているのか、Stoppingしているか)

コンテナ、クラスタが多くなると、管理も大変になる。ここで、AmazonECS、Kubernetes(Google Container Engine)が必要に。

AmazonECS

クラスタの中で複数のジョブスケジューラを起動できる。他のAWSサービス(EBS、ELB、Cloudformation等)との連携が可能。

シンプルなAPI

DockerHubに登録されているDocker イメージをpull、runするので、pullするのに時間がかかる、DockerHubにイメージを置くのがセキュリティ的に二の足を踏む場合も。

Google Container Registry に相当するサービスが望まれる。あと、コンフィグがjsonフォーマットだけでなく、yamlでも記載できれば。

ユースケース

バッチジョブ

マルチスケジュール機能を活用してバッチ処理に最適。

http://thinkit.co.jp/story/2015/04/10/5855

継続的インテグレーション

immutable infrastrure。サーバー使い捨て。コンテナの起動の高速な点を活用。

分散アプリケーション、マイクロサービス

MVCモデルでWebアプリケーションを開発デプロイすると規模も大きくなる。この反面、1 functionにサービス提供するのにコンテナには最適と考える。

IoT向けのサーバリソースにdockerも選択肢の1つになるのか。

PaasS。マルチテナントに適用しやすくなる。

IMAG0395

cloudpack 鈴木様のスライドより

すべてのインスタンスで動かしたいコンテナがあればAmazonECS Taskで動かせる読み物はこちら。

https://aws.amazon.com/jp/blogs/compute/running-an-amazon-ecs-task-on-every-instance/

EC2→ECS

EC2の資源をそのまま載せ替えることもできるが、2-Tier アーキテクチャで作り直すのがいい。

コンテナはSierの点から運用保守とか考えると導入しずらいのも事実。

Blue-Green Deployment with ECS and monitoring by はてな

ECSでBlue-Green deploymentを行うとすると、Taskのhost portをずらす、Delete/CreateLoadBalancerListenerがアトミックでないので、一時的に紐付けいているものがいなくなることも。この点、HA Proxyで解決できること

モニタリングは、ベーシックな監視はcgroup。詳細は、 https://docs.docker.com/articles/runmetrics/

 

docker in docker 。コンテナの中で、コンテナの話も。docker in dockerは正直実運用には。。。

https://blog.docker.com/2013/09/docker-can-now-run-within-docker/

https://github.com/tehranian/dind-jenkins-slave

docker in dockerとjenkins (Ci)との連携も

https://github.com/jpetazzo/dind

 

2015年9月13日
から hiruta
Datadogで、fluentd、nginxも監視してみました。 はコメントを受け付けていません

Datadogで、fluentd、nginxも監視してみました。

Datadogで、Fluentd、nginxについても監視が可能。

dd-system

Nginxのモジュールngx_http_stub_statusが有効である必要があります。組み込まれているかどうかは、nginx -Vで確認が可能です。

/etc/nginx/conf.d/virtual.conf

location /nginx_status {
stub_status on;
access_log off;
}

datadogの設定ファイルを作成します。.exampleでサンプルがおいてあるので、コピーして作成すればstatus urlを変更すれば完了。

/etc/dd-agent/conf.d/nginx.yaml


init_config:

instances:
# For every instance, you need an `nginx_status_url` and can optionally
# supply a list of tags. This plugin requires nginx to be compiled with
# the nginx stub status module option, and activated with the correct
# configuration stanza. On debian/ubuntu, this is included in the
# `nginx-extras` package. For more details, see:
#
# http://docs.datadoghq.com/integrations/nginx/
#

- nginx_status_url: http://localhost/nginx_status/

dd-nginx

/etc/td-agent/td-agent.conf


<source>
type monitor_agent
bind 0.0.0.0
port 24220
</source>

<match *>
id plg1
type forward
<server>
host localhost
</server>
</match>

設定を反映するには、fluentdを再起動します。

systemctl restart td-agent

下記コマンドで取得できるようになれば設定が反映されています。

curl -s http://127.0.0.1:24220/api/plugins.json

次に、datadogの設定ファイルを作成します。nginxと同様exampleからコピーでほぼ完了。

/etc/dd-agent/conf.d/fluentd.yaml


init_config:

instances:
# Every instance requires a `monitor_agent_url`
# Optional, set `plugin_ids` to monitor a specific scope of plugins.
- monitor_agent_url: http://localhost:24220/api/plugins.json
plugin_ids:
- plg1
# Optional, set 'tag_by' to specify how to tag metrics. By default, metrics are tagged with `plugin_id`
#- monitor_agent_url: http://example.com:24220/api/plugins.json
# tag_by: type

dd-fluentd

最後に、datadogのagentを再起動します。

sytemctl restart datadog-agent

設定が反映されているか下記コマンドで確認できます。

dd-agent info
 fluentd
-------
- instance #0 [OK]
- Collected 3 metrics, 0 events & 2 service checks

nginx
-----
- instance #0 [OK]
- Collected 7 metrics, 0 events & 2 service checks

それ以外にも、RabbitMQ、Cassandra、HA Proxy等監視できるプロダクトが豊富になっています。
 

2015年9月6日
から hiruta
Cassandra Meetup Tokyo 2015, Summerに参加してきました。 #cassandrameetupjp はコメントを受け付けていません

Cassandra Meetup Tokyo 2015, Summerに参加してきました。 #cassandrameetupjp

9月4日、Yahoo! Japanの方でCassandra Meetup Tokyo 2015が行われました。

Cassandraは、NoSQLの技術になり、DynamoDB、Google BigTableの仲間に入ります。

Apache Sparkと組み合わせることで、強力な分析基盤を構築することも可能。

Cassandra Meetup Tokyo 2015, Summer with Apache Cassandra Chief Evangelist, Patrick McFadin

Cassandra は、マスターレス、peer-to-peerで稼働するので、SPOFになり得ない、耐障害性にも優れています。

Wather Stationから気象データを収集するユースケースを話されましたが、Cassandraは、IoT deviceのデータ収集にも使用可能。

Apache Sparkと組み合わせられる。Apache Sparkは、In-Memoryで高速でデータ分析が行える特徴を持っており、Spark Streaming、SQL、機械学習(Machine Learning)、GraphXのコンポーネントもあります。

data processingを聞くと、Google Dataflowが思い浮かんだ。ClouderaがGoogle DataflowをSparkに統合する計画も。

http://jp.techcrunch.com/2015/01/21/20150120google-partners-with-cloudera-to-bring-cloud-dataflow-to-apache-spark/

Partition and Token Range

Cassandra dataをスキャンするには、token ringを使って、マルチノードにアクセスする。

Cassndaraから抽出したデータをCassndaraに書き出すことも。

spanBy

groupByより効率良くグルーピングできる。

Cassandraとsparkを使った yahooの事例

50を超えるyahooのサービスで利用されていること。

StorageにSSDを利用することで、QPS 6倍、レイテンシ1/10と性能向上が図れる。

Sparkはデータの可視化に。Sparkは、In-memoryで高速ではあるが、hadoopオーバーヘッド、HDFSの点でも、hadoopより高速と言える。

MySQLで4,000万レコードの更新がある場合、レプリケーション遅延が発生していた。

RDB系だとトランザクション量が多いとレプリカ遅延(RepliaLag)が発生する。トランザクション量が多い場合、NoSQL系が。

BlockTransferServiceが現状SSLされていないことも。

CyberAgentでの事例

Cassandraの導入。

jenkins、ansible + SensuでCassandraを使った運用。Masterレスなので、SPOFがない、ノードを増やすことで、スケールアウトも。

cpu/mem/nw/latency/fd はもちろん、jvmのGC、Cassandra_Status、Cassandra clusterのheathの監視を行っている。

repair & cleanupを7日。NW断があった障害に関しても、データロストはなかった。

書き込みを一端止めて、snapshotを取得することで、PITRに近いこともできるのでは。組み込まれることを期待。

Cassandra Tools

EC2でCassandraを使う場合、Ec2MultiRegionSnitch、 Ec2Snitchを確認。

  •  cassandra-stress
    • Cassandra負荷掛けツール。read/writeで負荷を掛けることが可能。
  • cassandra-stressd
    • 長時間負荷をかける場合は、こちら
  • cassandra.in.sh
  • json2sstable
  • sstable2json
    • deprecatedされており、Cassandra 3.0では廃止予定
  • sstablelevelreset
  • sstableofflinelevel
  • sstablerepairreset
  • sstablesplit
  • token-generator
    • 最適なtokenを算出してくれる

AWS上でCassandra環境構築する場合は、 cassandgo

参加者に、enterprise版のCassandraが入った2Gのusbメモリ。

P1000410

 

http://www.infoq.com/jp/news/2014/11/netflix-cassandra

http://www.infoq.com/jp/news/2014/11/netflix-cassandra

2015年8月30日
から hiruta
GKEのコンテナをDatadogで監視 はコメントを受け付けていません

GKEのコンテナをDatadogで監視

3-datadog-docker

※glcoud compoents updateでCloud SDKを最新にしておきます。

GKEクラスタを作成

 

gcloud container clusters create test-cluster --zone asia-east1-a --machine-type g1-small --num-nodes 1 --network stage-network

指定しないと、n1-standard-1とクラスタノード数3で起動します。

gcloud containers コマンドのデフォルトクラスタを「test-cluster」に設定します。

gcloud config set container/cluster test-cluster

kubectlとの連携

gcloud container clusters get-credentials

作成したクラスタの確認

gcloud container clusters describe test-cluster --zone asia-east1-a

作成するコンテナ用jsonを作成します。jsonだけでなく、yamlでも作成可能です。

{
 "kind": "Pod",
 "apiVersion": "v1",
 "metadata": {
 "name": "nginx",
 "namespace": "default"
 },
 "spec": {
 "containers": [
 {
 "name": "nginx",
 "image": "nginx",
 "imagePullPolicy": "Always",
 "ports": [
 {
 "containerPort": 22,
 "name": "ssh",
 "protocol": "TCP"
 }
 ]
 }
 ]
 }
}

Pods (Containers)を作成します。

kubectl create -f nginx.json
kubectl describe pods nginx

コンテナを削除する場合は、以下コマンドで完了。

kubectl delete -f nginx.json

作成したコンテナを確認します。Node Clusterも確認できます。Datadog Agentをインストールする際、sshログインする必要があります。

kubectl get pods nginx -o wide
NAME READY STATUS RESTARTS AGE NODE
nginx 1/1 Running 0 -340s gke-test-cluster-919cf59d-node-zgrc

Containerが起動すれば、Runningになるかと思います。内部的にイメージになんらか問題が生じて、Containersが起動できなくなっているケースもあります。Node Cluseterにログイン後、docker ps -aで、Containerは確認できます。(Datadogを使えば、コンテナの状態も確認できると思われます。)

Datadogに登録

Datadogの登録は割愛します。


 

ホストサーバーにDatadog Agentをインストール

Datadogのダッシュボードにある左メニューのIntegrationのAgentを選んで、「Debian」を選択します。 すると1行ペラっとコマンド出てきますから、それをコピーします。

DD_API_KEY=XXXXXXXXXXXXXXXXXXXXXXX bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)"

 

ホストサーバーからDocker Agentをインストール

IntegrationのAgentを選んで、「CoreOS」を選択します。

docker run -d --name dd-agent -h `hostname` -v /var/run/docker.sock:/var/run/docker.sock -v /proc/mounts:/host/proc/mounts:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e API_KEY=XXXXXXXXXXXXXXXXXXXXXXX datadog/docker-dd-agent

Docker 用監視ファイルの設定

サンプルのdocker用yamlファイルが置かれているので、リネームして、agentを起動します。


cp /etc/dd-agent/conf.d/docker.yaml.example /etc/dd-agent/conf.d/docker.yaml
dd-agent start

2015年8月16日
から hiruta
CloudSQLについて、TPC-Cベンチマークしてみました。 #gcpja はコメントを受け付けていません

CloudSQLについて、TPC-Cベンチマークしてみました。 #gcpja

Amazon Auroraに引き続き、CloudSQLのベンチマークを測定してみました。Cloud SQLに、Amazon Aurora相当のインスタンスタイプがないので、厳密な比較はできませんが、参考程度に。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。
ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

Table Record
customer 480000
district 160
item 100000
new_orders 144000
order_line 4799437
orders 480000
stock 1600000
warehouse 16

CloudSQLは以下の状態で行いました。

インスタンスクラス DB Engine version 備考
D8 5.6.26 Engineのバージョンは明示的には指定不可

メモリ4G※CPU情報については公開されていませんので、コア数は不明。mysqlのバージョンもmysqlに接続して確認。gcloudとDeveloper Consoleから確認はできない。

測定用インスタンスは、CloudSQLと同じリージョンにあるpreemptible VM (n1-standard-1)で。

検証用とかにPreeemtible VMお得で便利です。

結果

多重度 Throughput(tps) Response time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level New-Order Payment Order-Status Delivery Stock-Level
1 6.3 6.3 0.6 0.6 0.6 125 56 10 174 6
4  16.7  16.7  1.7  1.7  1.7  198  146  10  245  6
16  43.1  43.1  4.3  4.3  4.3  377  290  10  397  7
32 59.7 59.7 6.0 6.0 6.0 556 335 16 555 13

Cloud SQLは、IPv6にも対応、Repliaなどにも対応しているので、今後期待できるサービスです。

Cloud SQLはGCEのネットワークに配置することができないので、今後改善してほしいところ

2015年8月16日
から hiruta
Amazon Auroraをベンチマークしてみました。 はコメントを受け付けていません

Amazon Auroraをベンチマークしてみました。

Amazon Auroraのベンチマークを測定してみました。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。
ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

Table Record
customer 480000
district 160
item 100000
new_orders 144000
order_line 4799437
orders 480000
stock 1600000
warehouse 16

RDSは以下の状態で行いました。

インスタンスクラス DB Engine version 備考
db.r3.xlarge Aurora 5.6.10a Engineのバージョンは明示的には指定不可

RDSと測定用クライアント(r3.xlarge)は別AZに配置。

結果

多重度 Throughput(tps) Response time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level New-Order Payment Order-Status Delivery Stock-Level
1 9.9 9.9 1.0 1.0 1.0 93.20 20 10 113 7
4 37.9 37.9 3.8 3.8 3.8 95 22 10 116 8
16 129.2 129.2 12.9 12.9 12.9 107 32 12 131 9
32 198.3 198.3 19.8 19.8 19.8 133 66 14 163 13

 

多重度 CPU使用率 DiskQueueDepth(Count)
1 10% 9
4 30% 16
16 80% 13
32 92% 25

まとめ

多重度1でquery_cache_typeを変更して測定してみましたが、on/offの差は見られませんでした。

また、RDSと測定用クライアントを同一AZに配置した場合に比べて、3割程度の性能劣化が見られました。

以下は、測定用クライアントとRDSが同一AZにあった場合の結果になります。

多重度 Throughput(tps) Response time (90%tile)
New-Order Payment Order-Status Delivery Stock-Level New-Order Payment Order-Status Delivery Stock-Level
16 195.5 195.6 19.6 19.6 19.6 67 27 7 91 9

 

2015年7月28日
から hiruta
July Tech Festa 2015に7/25参加しました。 #jtf2015 はコメントを受け付けていません

July Tech Festa 2015に7/25参加しました。 #jtf2015

7/25 産業技術大学院大学で行われた July Tech Festa 2015に行ってきました。

以下のセッションに参加しました。

IoT時代のデバイスクラスタHashicorp consulを用いたIntel Edisonクラスタの構成

fogとクラウドどう役割分担させるのがポイント。fogはリアルタイムの処理を行い、クラウド側では大量データ蓄積、分析・学習に利用する。

実際構築したシステムの技術の解説。MQTT、Wi-Fi Mesh Network、Consul

MQTTは、TLSで暗号化が推奨。

Wi-Fi Mesh Networkは、SPOFにならないとか良い点もあるが、デフォルトカーネルでは動かず、カーネルビルドが要。→

Consul 運用自動化ツール。Wi-Fi  Mesh Networkと相性が良い。Go 1.4 x86 32bitのバイナリで動かせる。

真剣にDocker運用を考える人に、各種監視ツールとサービスを比

Dockerの監視を自作(DIY)で、それとも、SaaSの監視サービスでまかないか。

Docker  Containerの監視粒度は、1回/5分では不十分。1データ/1秒、一年間保存位しないとNG

CloudWatchの監視粒度とかではDocker Containers監視は不十分ということに。

Docker Containers監視を自作(DIY)で求められる監視粒度が満足できればいいが、そうは簡単ではない。

SaaS系の監視サービスだと、サービス終了した場合はどうするか個人的には気になる。

New Relic、App Dynamics、Mackerel、Signakfx、libratoについて、一丁一端がある。

DatadogがDocker Containers監視については現状ベストとのことに。

今話題のAnsibleのモジュールをゼロから自分で作ってみよう

標準で提供されているモジュールだけでも十分だが、かゆいところまでしたい場合はモジュールを作成する。

本当に足りない機能をモジュールで作成するのがいい。(今回のセッションではSolarisのホスト名変更が標準では対応していないので、モジュールを書いて、pull requestした話がありました。)

開発したモジュールを標準モジュールに取り組んでもらうには、いくつかのルールがある。説明、利用例に準拠させる必要がります。

仮想化とストレージの新しい形!ハイパーコンバージインフラの技術解説

オンプレのストレージ仮想化は、スモールスタートしずらい

安価なストレージ仮想化では、SANのポート、ストレージヘッドの性能に制限

拡張する場合、非効率なサイロ化

そこで、ソフトウェア処理で何とかするのが、Nutanix

Googleが描く、MapReduceを超えたビックデータの世界

Googleのコンテナ技術Borg

Google BigQuery

Googleも初期には、oracleとかRDBを使っていたが、膨大なGooogle検索のインデックスを管理するPBサイズになり、対応しきれなくなったとのこと。BigQueryのサービスが生まれた。インフラをあまりしらないユーザも使える。最適化されていたクエリ(糞クエリ)も高速で実行が可能。管理者不要、パフォーマンス劣化がない

1,000億行Read(フルスキャン)しても、20秒かからない。

RDBだと、一台のマシンで1日かかることも。

BigQueryがなぜ速いのかの説明。カラム指向ストレージ。カラム毎に異なるストレージに入れるので、クエリ実行効率、圧縮効率もいい

数千台のサーバーで並列実行。他のクラウドだとマネできない。

RasPiからBigQueryにも。fluent-plugin-bigqueryを使う場合、GCEだと、AWSでいうIAM Roleに相当する自動でアクセスするcredentailsを取得する仕組みがRasPiとかIoT deviceだと使えないのが課題。

Google Dataflow

機械学習(Machine Learning)

実行環境側でshared。Kinesisの場合、sharedをKinesis Streamを作成する際、指定する必要があるが、スケールも自動でしてくれる。