diceken/道玄坂LT 意味不メモ 20150115

## 道玄坂LT 意味不メモ 20150115
道玄坂
# トップバッター
名前聞き忘れた・・・

サイバーエージェントの話
KVSはKumofs 使ってたけど Aerospike　に
Cassandra memcache とかも使ってますmongoDB使ってないっす

集計処理
Hadoop
CDH 4.4 クラスタ430TB/USED140TB
日時でdistcpしてエンジニア以外が使える環境持っていてそこにtableau+impalaでquery投げてる


docker と ansible は導入済で本番まで持って行ったよ

# EC2 Auto Recoveryってどのレベル?
cloudpack 吉田さん
EC2にAuto Recoveryついたよ。ただし対応しているEC2(リージョンとかインスタンスとか)は限定的
EBSを利用している場合に限られる < 早い話限定的VMware HAじゃね

元々障害切り分けの多くはSSHログインできるか試して、ダメならリブートで大抵(8割9割)解決できていた(異なるHypervisorに移るから?)ので、これ(ダメならHardwareをリブート=Hypervisorを切り替えて起動)を自動化してくれるのは超楽

TriggerはAWS側のStatusCheckFailed_System のみ。つまり、AWS側で問題が起きないと試せない(OS側やこちらのスクリプトでは制御できない)
-> 動作テストできないじゃん -> 動作させる方法がある(ここ聞き逃した。。)  shutdown -h now -> Auto Recovery が作動
インスタンスID等は全て引き継ぐ ( Console では見た目に違いがないので実際に何が起こったのかよーわからん
Auto Healing by Auto Scalingよりも楽 (EBSの中身引き継ぐので

※後ろで中の人と話してたらどうやらVMware HAの簡易版っぽい?


# Amazon Aurora
Amazon AWS　大谷さん
S3バケット-> Lambdaファンクション -> DynamoDB
今までRDSといえばDBに手を入れない100%のcompatible
Cloud特有だとどうしても足りない部分あるなあ。
ネットワークの遅延とかマスターとの切り離しとか・・・。

クラウド上で動くための最適化がされたぜい!
ストレージは自動的に10GBずつ拡張されていくぜい!
SQL/TransactionsはRDBそのまま
Buffer Pool Cache/Logging+Storage は独自実装で複数AZをまたいで共有
つまりRDBとストレージ部分が分離されている -> つまりつまり、  Oracle ASMと似た思想
S3へ高速差分バックアップ -> 差分バックアップなので、ディスクのスナップショット機能使ってるのかな?

3AZ - 6way replication = 4 of 6のquorum
1AZ死んだら 3 of 4 に自動フォールバック -> つまり 1AZが落ちても無問題
Region内部で３冗長なので、Hadoopとかと多分同じで2冗長を優先し3冗長目は遅れて同期、ってやってそう
3 of 6の読み込みクオラム
SSDベースマルチテナントストレージ
ディスク増設不要・64TBまでスケール
使用量チャージ
Aurora、いいなあ。。。

Log-structured Storage as a Service -> AWS独自
小さいチャンクベースで個別でredo log を持つ
DBとストレージ層のインタラクションを減らす工夫
キャッシュが内部で独自で抱えているのでDBが使える状態まで高速に可能
レプリカラグは10-20msec
最大レプリカは15個まで作成可能

# Presto
分散SQLの実装
Tez/Spark/Impalaに近いぜ
Hive / MySQL とかを 後ろに繋げてselectでJOINしたりできるぜ
selectの結果をテーブルにできるぜ
集計をprestoでやって結果をmysqlに書き直すとかもできるぜ

prestogres(postgresのプロトコルで投げられる)
psql -> prestogres -> Presto に query とかできる
psql -> prestogres -> presto -> mysql -> return the result from mysql -> presto -> psql
とかキモイ挙動できる

http://t.co/ROHKqYAxJm

# RHEL7
Yuryuさん
大抵過去のコマンド残ってたり一度きりだったりするので、
怖がらずに新しいOSとりあえず導入しようぜ。
気に入らなきゃ昔のコマンド使えばいいし。

http://t.co/sRyagmjhSy

# CloudFormation
cyberzの新卒さん
Cloud Formation

ボタン一つでインフラ生成/破棄
生成破棄の対象はjsonで.テンプレートは再利用可能
Jsonテンプレートをシェルに打ち込んで Jenkins から動的に環境を生成
cronでCloudFormationで作成データをS3にアップ作業終わったら破棄
-> Hadoopで使うとEMRですな

Blue Green deployment してみた
VPC内部でMySQL/ELBの切り替え
遅延が発生した
Route53で weight を設定して blue -> green で対処
EC2 ~ ELB の生成には 3~5分かかった
テンプレートをjsonで記述大変だった
DRYに記述できない/コメント書けない/Dry-runができないのでテストが大変

# Cloud周り全般
小清水さん

OpenStackでリソース管理
仮想マシンでリソース提供
コンテナでアプリケーション実行
Dockerで実行環境の作成配備
Kubernetesコンテナのオーケストレーション

# Datomic
今井さん
Clojureの作者の商用分散DB
http://docs.datomic.com/architecture.html

Peers -> アプリと同じメモリを共有してJVM内部でオブジェクトとして動く.くっそ早い。
	Query Parse / Live Index / Cache / Comm
Transactor -> 全てのwrite operationがここを使う。writeはスケールしにくい?
Storage Services -> DynamoDBとかCassandra/Riak/Couchbase/Infinispan memory cluster 自由に選べる. Transactorが書きに行ったり、データをキャッシュに無いモノを返したり

* スケール・シャーディングは面倒臭い
* NoSQLは結局自分で管理しないといけない
* クラウドネイティブなDB作りましょう、が経緯
* Avoid monolisic
* シンプル /スケーラブル / ACID
http://docs.datomic.com/architecture.html

# HBase徹底入門
サイバーエージェント鈴木さん
HBaseのアーキテクチャの説明してた(完)
まあ、今更なので。

# HPRed Hat Storage on SL4540(Proliant)
大容量HDD
Hadoopクラウドとかで
HP helion openstack
RHEL OSP 5 on HP ConvergedSystem700x
http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA5-4584ENW

Packstack(Juno)
https://wiki.openstack.org/wiki/Packstack

Hadoopのケースも多様化してる
YARN多 (カートリッジ型)
HDFS普通YARN普通(カートリッジ+ストレージサーバ)
YARN少HDFS多(ストレージサーバ)

HPC
Green of IT -> Green by IT

CloudServiceAutomation(CSA)
混在しているクラウド環境をまとめる
国防総省とか

GPUとCPUの差を意識しない時代に(クラウド+Grid+環境)
Mesosがスパコンの世界では流行ってる
(HadoopのJobとかMPIの実行のリソース制御に利用されている
優先度順位変更、CPU、メモリ資源の割り当て

(HPC -> PBSpro Moab Hadoop Mesosに期待

超省電力サーバ
HP Moonshot(超省電力) 10数w/1枚

serverCONDOホスティング社 ARM版が最近出てきている
信号所利用のコア: C66x とかもある

BIOS / RAIDの自動設定をどうする? etc

# Spark
SIROK (Cyber agentの関連会社) 片岡直之 katty 0324
なんでHadoopより速いん?
Hadoopがディスク読んで処理、ディスク読んで処理、に対してSparkは全部オンメモリなので。
ほんまかいな
インストール方法を試した、mesosのmaster/slaveを立ててみた

※ オンメモリ系はメモリ溢れたら大抵破綻するで

# Fluentdが増えていった的な
拡大期
Elasticsearchへの書き込みが詰まり始める
川越して宿を取れ
ログが増えると行数増える
fluentdに仕事をさせすぎるのはやめよう
設定行数とシステムの複雑性はあんま関係ないかも
	道玄坂
	# トップバッター
	名前聞き忘れた・・・

	サイバーエージェントの話
	KVSはKumofs 使ってたけど Aerospike　に
	Cassandra memcache とかも使ってますmongoDB使ってないっす

	集計処理
	Hadoop
	CDH 4.4 クラスタ430TB/USED140TB
	日時でdistcpしてエンジニア以外が使える環境持っていてそこにtableau+impalaでquery投げてる


	docker と ansible は導入済で本番まで持って行ったよ

	# EC2 Auto Recoveryってどのレベル?
	cloudpack 吉田さん
	EC2にAuto Recoveryついたよ。ただし対応しているEC2(リージョンとかインスタンスとか)は限定的
	EBSを利用している場合に限られる < 早い話限定的VMware HAじゃね

	元々障害切り分けの多くはSSHログインできるか試して、ダメならリブートで大抵(8割9割)解決できていた(異なるHypervisorに移るから?)ので、これ(ダメならHardwareをリブート=Hypervisorを切り替えて起動)を自動化してくれるのは超楽

	TriggerはAWS側のStatusCheckFailed_System のみ。つまり、AWS側で問題が起きないと試せない(OS側やこちらのスクリプトでは制御できない)
	-> 動作テストできないじゃん -> 動作させる方法がある(ここ聞き逃した。。) shutdown -h now -> Auto Recovery が作動
	インスタンスID等は全て引き継ぐ ( Console では見た目に違いがないので実際に何が起こったのかよーわからん
	Auto Healing by Auto Scalingよりも楽 (EBSの中身引き継ぐので

	※後ろで中の人と話してたらどうやらVMware HAの簡易版っぽい?


	# Amazon Aurora
	Amazon AWS　大谷さん
	S3バケット-> Lambdaファンクション -> DynamoDB
	今までRDSといえばDBに手を入れない100%のcompatible
	Cloud特有だとどうしても足りない部分あるなあ。
	ネットワークの遅延とかマスターとの切り離しとか・・・。

	クラウド上で動くための最適化がされたぜい!
	ストレージは自動的に10GBずつ拡張されていくぜい!
	SQL/TransactionsはRDBそのまま
	Buffer Pool Cache/Logging+Storage は独自実装で複数AZをまたいで共有
	つまりRDBとストレージ部分が分離されている -> つまりつまり、 Oracle ASMと似た思想
	S3へ高速差分バックアップ -> 差分バックアップなので、ディスクのスナップショット機能使ってるのかな?

	3AZ - 6way replication = 4 of 6のquorum
	1AZ死んだら 3 of 4 に自動フォールバック -> つまり 1AZが落ちても無問題
	Region内部で３冗長なので、Hadoopとかと多分同じで2冗長を優先し3冗長目は遅れて同期、ってやってそう
	3 of 6の読み込みクオラム
	SSDベースマルチテナントストレージ
	ディスク増設不要・64TBまでスケール
	使用量チャージ
	Aurora、いいなあ。。。

	Log-structured Storage as a Service -> AWS独自
	小さいチャンクベースで個別でredo log を持つ
	DBとストレージ層のインタラクションを減らす工夫
	キャッシュが内部で独自で抱えているのでDBが使える状態まで高速に可能
	レプリカラグは10-20msec
	最大レプリカは15個まで作成可能

	# Presto
	分散SQLの実装
	Tez/Spark/Impalaに近いぜ
	Hive / MySQL とかを後ろに繋げてselectでJOINしたりできるぜ
	selectの結果をテーブルにできるぜ
	集計をprestoでやって結果をmysqlに書き直すとかもできるぜ

	prestogres(postgresのプロトコルで投げられる)
	psql -> prestogres -> Presto に query とかできる
	psql -> prestogres -> presto -> mysql -> return the result from mysql -> presto -> psql
	とかキモイ挙動できる

	http://t.co/ROHKqYAxJm

	# RHEL7
	Yuryuさん
	大抵過去のコマンド残ってたり一度きりだったりするので、
	怖がらずに新しいOSとりあえず導入しようぜ。
	気に入らなきゃ昔のコマンド使えばいいし。

	http://t.co/sRyagmjhSy

	# CloudFormation
	cyberzの新卒さん
	Cloud Formation

	ボタン一つでインフラ生成/破棄
	生成破棄の対象はjsonで.テンプレートは再利用可能
	Jsonテンプレートをシェルに打ち込んで Jenkins から動的に環境を生成
	cronでCloudFormationで作成データをS3にアップ作業終わったら破棄
	-> Hadoopで使うとEMRですな

	Blue Green deployment してみた
	VPC内部でMySQL/ELBの切り替え
	遅延が発生した
	Route53で weight を設定して blue -> green で対処
	EC2 ~ ELB の生成には 3~5分かかった
	テンプレートをjsonで記述大変だった
	DRYに記述できない/コメント書けない/Dry-runができないのでテストが大変

	# Cloud周り全般
	小清水さん

	OpenStackでリソース管理
	仮想マシンでリソース提供
	コンテナでアプリケーション実行
	Dockerで実行環境の作成配備
	Kubernetesコンテナのオーケストレーション

	# Datomic
	今井さん
	Clojureの作者の商用分散DB
	http://docs.datomic.com/architecture.html

	Peers -> アプリと同じメモリを共有してJVM内部でオブジェクトとして動く.くっそ早い。
	Query Parse / Live Index / Cache / Comm
	Transactor -> 全てのwrite operationがここを使う。writeはスケールしにくい?
	Storage Services -> DynamoDBとかCassandra/Riak/Couchbase/Infinispan memory cluster 自由に選べる. Transactorが書きに行ったり、データをキャッシュに無いモノを返したり

	* スケール・シャーディングは面倒臭い
	* NoSQLは結局自分で管理しないといけない
	* クラウドネイティブなDB作りましょう、が経緯
	* Avoid monolisic
	* シンプル /スケーラブル / ACID
	http://docs.datomic.com/architecture.html

	# HBase徹底入門
	サイバーエージェント鈴木さん
	HBaseのアーキテクチャの説明してた(完)
	まあ、今更なので。

	# HPRed Hat Storage on SL4540(Proliant)
	大容量HDD
	Hadoopクラウドとかで
	HP helion openstack
	RHEL OSP 5 on HP ConvergedSystem700x
	http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA5-4584ENW

	Packstack(Juno)
	https://wiki.openstack.org/wiki/Packstack

	Hadoopのケースも多様化してる
	YARN多 (カートリッジ型)
	HDFS普通YARN普通(カートリッジ+ストレージサーバ)
	YARN少HDFS多(ストレージサーバ)

	HPC
	Green of IT -> Green by IT

	CloudServiceAutomation(CSA)
	混在しているクラウド環境をまとめる
	国防総省とか

	GPUとCPUの差を意識しない時代に(クラウド+Grid+環境)
	Mesosがスパコンの世界では流行ってる
	(HadoopのJobとかMPIの実行のリソース制御に利用されている
	優先度順位変更、CPU、メモリ資源の割り当て

	(HPC -> PBSpro Moab Hadoop Mesosに期待

	超省電力サーバ
	HP Moonshot(超省電力) 10数w/1枚

	serverCONDOホスティング社 ARM版が最近出てきている
	信号所利用のコア: C66x とかもある

	BIOS / RAIDの自動設定をどうする? etc

	# Spark
	SIROK (Cyber agentの関連会社) 片岡直之 katty 0324
	なんでHadoopより速いん?
	Hadoopがディスク読んで処理、ディスク読んで処理、に対してSparkは全部オンメモリなので。
	ほんまかいな
	インストール方法を試した、mesosのmaster/slaveを立ててみた

	※ オンメモリ系はメモリ溢れたら大抵破綻するで

	# Fluentdが増えていった的な
	拡大期
	Elasticsearchへの書き込みが詰まり始める
	川越して宿を取れ
	ログが増えると行数増える
	fluentdに仕事をさせすぎるのはやめよう
	設定行数とシステムの複雑性はあんま関係ないかも