今年も始まりました。#AWSSummit。
普段行くものとは一番異なる点。そうDJがいるということ。
何かショーが始まりそうな華やかなオープニングです。
投稿が遅くなりがちなのでいっそ書きながら投稿してみましたが、最終系までには時間かかってしまいました。。

基調講演

クラウドは今やニューノーマルになった
3年前5年前に興味を示さなかった顧客が興味を示しだした
- matzさんの話を思い出した
  - Ruby東京プレゼンテーション2015 にいってきた#使えると使えないのタイムラグ
  - イノベーションは少し先をいく
    - わかってもらえない
    - たたかれる
    - 心が折れそうになる
広告宣伝費全くなしで1000万DLするようなアプリがある
- 何か聞き逃してしまいました…
あらゆる組織にagilityは重要になってくる
たらればをお客様に提供したケースの紹介
- 成功するかわからないものに巨大投資できない
- AWSなら数ペタバイトのデータ量であってもトランザクションまでやっていける
デプロイのスピードで売上を伸ばすことができた某飲食店
- コストもだけどデプロイの費用もボトルネックになる

クラウドワークス吉田さんのお話

クラウド(crowd)についてのお話

赤字上場から始まった
- 日本版ジェフ・ベゾスの心意気でいる(…！
あたらしいアウトソーシングをつくりだした
- クラウドソーシング
- 個人の労働力を
今日本の正社員比率は45.2%！50%を切っている
御社には80代まで働ける環境がある
- 70代も月収20万円
ガイアの夜明けに今夜でるかも！
- パリが雨の場合は放送される！
- 転記が良かったら有名なテニス選手のお話に…！

リクルートテクノロジーズ中尾さんのお話

トラフィックを予測できるものはオンプレを使っている
予測できないものはAWSを使っている
- SPEED
- Flexibility
- Functionality
- が必要な場合はAWSを使う

AWS 認定資格取得者専用ラウンジ

立ち見がつらくなってきたので、行ってみました。
ココです> http://www.awssummit.tokyo/labo.html#02
プレゼントをもらえました！ありがとうございます！

AWSせんべい
AWSモバイルバッテリー
モバイルPC用(?)ソフトケース

ロボットで実践！10分でわかる機械学習とその活用法

株式会社ナレッジコミュニケーション奥沢明さん
naoくんがプレゼンしてました！

なぜロボットが話題になっているのか

cloudを組み合わせることでデータ処理能力がup
機械学習
- データから潜在的なパターンを認識し、次のパターンを導き出し新たなデータを予測する
- 分析からモデル化まで機械学習が行う
- 人間だとデータ量が増えると処理できなくなってくる
- ロジック反映の自動化も可能

AmazonMachineLearning

特徴

操作性が簡単
専門知識がいらない
- モデルの評価
  - 機械学習がおこなったのものの正解率がわかる
  - 正答率が公開前にわかる

回帰分析二項分類多項分類

回帰分析
- 明日の天気を予測する
  - 過去のデータに基づいて未来の予測をする
二項分類
- 性別年齢年収勤続年数などから融資可能か判断する
多項分類
- 行動からユーザのプロファイルを判定し効果的な広告をだす
機械学習 > 分析
- 機械学習は分析以上の効果を上げられるというのが特徴

Amazon RDS for Aurora Deep Dive

Auroraはプレビュー中の機能のため頻繁に更新が行われる。
今日時点のこととして聞く。

Auroraの紹介

自動でパッチの適用そしてくれる
ボタンひとつでスケールアウト
RelationalDatabaseの新しいエンジン
- RelationalDatabaseをAWSが1から考えた
現在はLimited Preview中
- Virginia Oregon Ireland で展開中
- 5/20からプロダクション環境に移行
料金体系の特徴
- インスタンスはR3シリーズのみの提供
  - 最安 0.29$
  - 最高 4.64＄

特徴

クエリ性能の向上
MySQL5.6と互換性がある
- 既存のアプリケーションを簡単に移行
ストレージが10GB~64TBまでシームレスにスケールする
- 3つのAZに2つずつ、合計6個つのデータのコピーを保持する

なぜAmazonがDBを再考したか

現在のモノリシックなdatabase
- スケールアウトするときはこのセットを増やしていかなくてはならない
AWSのサービスを活かすことができてハイエンドDBのようなスピードと可用性MySQLとの互換性を併せ持つもの

アーキテクチャ

Servise OrientedドArchitecture
ログとストレージレイヤをシームレスにスケールするストレージに移動
バックアップはS3にもつ
キャッシュレイヤをぶんりした
- DBのプロセス外にもっていった
- 今までのRDBはプロセスをrestartするとキャッシュがリセットされた
- 外に出すことにより、restartしてもキャッシュをクリアしないようにした
HighAvailabilityを実現した
- 合計6つのコピーをおいている
- 3つまで壊れてもビルドできるようにしている
- 6本中4本書き込みしたら次の処理にいく
- Read Replicaでもマスターと同じストレージを参照している
Log Stractured Storage
- 追記型のストレージ
- シーケンシャルに読み出すことができる
- 常に最新のデータが末尾にある
- これによりS3へのバックアップなどが可能に

疑問

ディスクが6本あったら故障率があがるのでは？
- 2つのコピーに障害が発生しても読み書きに影響はない
- デモがありましたが本当になかったです…！

レプリケーション

マスタースタンバイ
全てが同じストレージを参照している
Auroraは15台まで子どもをつくれる
- 10~20msec の遅延おそくても30msec(公式ドキュメントでは100と言っている)
- failoverまだshippingしていないログ
皆が同じディスクを参照しているのでデータの欠損はほぼ起きなくなっている

セキュリティ

データの暗号化
SSL
あたらしい概念
- DBクラスタ
- writerとreader
Failoverが発生しても常にひとつのエンドポイントを見続ける

FailoverとRecovery

リードレプリカが存在する場合フェイルオーバーとリプレース時にCPU使用率がぐっとあがってしまう

Amazonredshift Integration DeepDive

Redshiftの実際の活用方法を説明

Redshiftの紹介

分散型のデータウェアハウス
超並列演算
データの格納は列思考(カラムナ)
クエリーの並列実行
投げたクエリがC++になってコンパイルされて実行されていく

主要アップデート

Redshiftに最適化されたドライバがリリースされた
Interleaved Sort Key

RedshiftにおけるIntegrationとは

Integration = データ量
オンプレとのデータ連携
データをS3にCSVファイルとして蓄積保全
オンプレから直でredshiftは推奨しない
S3がハブとなり他のAWSサービスと連携する

talend ETLツールの紹介

Extract Upload transform
RDBMSからレコードを抽出
- 差分データの抽出が最も難しい
- レコード数が少ない場合差分データを創りださずに毎回全件を抽出

設計のポイント

大量のレコードを抽出する場合メモリの枯渇を防ぐためにカーソルを利用
シリアルなuploadよりもパラレルなuploadがおすすめ
S3のオブジェクトキーは先頭4文字をランダム化するのが理想的
S3のファイルをEMRを使ってバッチ変換
一時テーブルにとりあえず入れておくその後本番テーブルにいれる

EMR

Hiveによるデータ変換
- S3　　　　S3
- ↓　　　　　↑
- Hive　->　Hive
AWSのCLIは非同期
- 同期して進めたいこのような処理は難しい
クラスタ作成待ち
- hiveスクリプロ実行度クラスタ削除待ち
Load
- ファイル一覧や正規表現をcopyコマンドに指定するとコンピュートノードが並列にデータをロード
- ロードに失敗したらstl_load_errors 表jに格納される
  - 許容できるエラー数を設定できる
- ロードの確認
- ロード時にはテーブルロックがかかる

まとめ

taledについて
- ツール導入によりETLの効率化
- スタンドアローンで動作するJavaプログラムでビルド実行
redshiftとデータ連携
極力均等なサイズに分割することがキモ

クラウドファースト時代のコンプライアンスとセキュリティの進化

Chad Woolf, Director, AWS Risc & Compliance

how security ?

20年来のITセキュリティ政策

ガバナンスの確立
- 新たな脅威への対処
- 検出集団の確率と予防への動き
整合性と信頼性を高めるための制御の自動化
システムネットワークITの難しさ
- 経済の拡大複雑化分散

クラウド発展の契機

セキュリティとクラウドの分野に支出が増えてる！

推進力セキュリティ

セキュリティ政策の重要性は増しているがその達成もより困難になっている
従来のセキュリティマネジメント方式では脅威の拡大に対応できない
問題は他にもある
- セキュリティを革新的なビジネスの妨げにするわけにはいかない

推進力アウトソーシング

企業は差別化につながらない作業を外注し競争力の強化に注力している
ベンダーリスクマネジメントは業務に不可欠なレベルにまで成長している

クラウドファースト

クラウド外注契約の進化版
従来のホスティングモデルとcotsソフトウェアの併用
アウトソーシングの利点に加えてアジリティ/セキュルティ/コストマネジメントを改善
クラウドファーストエンタープライズ市場での存在感の拡大

エンタープライズ市場でのクラウドの導入

簡易な点からより複雑な焦点の移動
監督監査機関よりも顧客の方がクラウドの管理についてよく知っている
放棄はビジネスの動きほど素早く変化しない

法規のクラウドへの適合

法規上のITの定義がクラウドによって崩壊している
コンプライアンスの解釈の段階でセキュリティリスクが失われる
クラウドに対応するために法規が徐々に変化している

移動可能なワークロード

組織の機密保持やコンプライアンスの管理を容易化する意味でもクラウドサービスが導入される
既存の制御構造との統合
Defaultでセキュアな法令に準拠したAWSアカウントの作成

Innovationの速度（全体に対するセキュリティの割合）

Innovationのは監査機関にも
監査中心のサービスと機能
- AWS Config
- AWS KMS
- AWS cloud trail
やるかやらないかではなくいつやるかの問題
- (今でしょ…?
規制対象の機密データはクラウドに格納しクラウドで処理するほうが適切

AWS EBSパフォーマンスベンチマーク2015

小林正人(Kobayashi Masato)さん
週刊AWSの和訳してる中の人！

おさらい

EC2にくっつけてつかうblockstrage
snapshotが特徴的
ディスクの暗号化
five9の可用性
Snapshotから任意のAZに移動できる
現時点で複数のEC2からひとつのEBSを参照はできない

アーキテクチャ

AZ内で複数のHWにレプリケートされている
一般的にさらなる冗長化は不要
すべてのポートを閉じてもEBSにはアクセス可能(…！)
Snapshotから復元したらボリュームタイプを変更可能

汎用SSD General Purpose SSD

最大10000IOPS
OSの起動時にバーストを利用するなどが可能
容量が3334では10,0001IOPS
バーストの継続時間
- I/Oクレジットの残高によって決まる

汎用SSD 容量とスループット

170GBが境目

Provisioned IOPS

指定したIOPSの±10％の範囲の性能を発揮する
容量の30倍が上限
320MB/s スループット

マグネティック

汎用SSDの前はこれがDefaultだった
コストが安い
課金体系に特徴がある
リクエスト回数による課金

律速する要素

3つの要素

EC2インスタンス側のスループット

コレを改善する
最適化オプションを有効にすることが重要！
上限に達していないかを確認する
CWのVolume Read Write byteの合計値
上限に達していたら大きいタイプに変更すると改善される
最適化インスタンスについてはココ↓をみる
- http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSOptimized.html

EBS自体の処理性能

上限に達していればタイプを変更したりスペックやサイズを変更する

EBSスループットを改善

EBSボリュームの read write の参照
上限に達していればタイプの変更がおすすめ
平均ブロックサイズから必要サイズを計算する
事前ウォーミングすると正しい性能がわかる
運用している場合は事前ウォーミングできない場合もある
- 運用上どちらがいいか判断してやってい
- ddコマンドでウォーミング
- RAIDを組む
- RAID0にする

実際に測定した結果！

ベンチマークと実際のパフォーマンスは異なることがある
c3.8xlarge
8KBランダム読み込み
- 大きなブロックサイズを扱う場合はIOPSの速度が限られてくる
- 大きなブロックアクセスした
  - 仕様どおりのIOPSがちゃんとでてた！

インスタンスストアを使う

揮発性で
- rebootでは揮発しない
ローカルディスクのやつ
- アプリの一時的なデータ保持に適している
i2.8xlarge
- 最もランダムアクセスに適したモノを選択
読み書きはややパフォーマンスがおちる
ボリュームの暗号化ハードウェアの機能を使って暗号化をするのでパフォーマンスに影響しない
- 実際に確認してみた
- 傾向は殆ど変わらない…！
- CPU使用率も殆ど差がない…！
- パフォーマンスへの影響はほぼない！

典型的な構成

アクセスブロックサイズが小さい場合
インスタンスタイプは小さくても汎用SSDで大きめに確保してIOPPSを上げる
大きいブロックを扱う場合はスループットを重視する
コストを最優先にする場合はマグネティックで
- 最大1TBなのでRAID構成をとるようにする
極めて高い性能が必要な場合はインスタンスストアを使う
3つのボリュームのなかから適切なものを選ぶ
パフォーマンスが不足している場合は何がボトルネックになっているのか正しく認識する！

感想

印象的だったのはAurora。
Auroraが誕生した経緯はAmazonらしいなと思いました。
すでにあるモノはとことん活用して、すでにあるモノでは物足りない場合は自分たちで改善したモノを作ってしまう。
そいうところはエンジニアだからこそできる楽しいところだなーと。
あとびっくりしたのは、元(?)同期が登壇していたのはちょっと悔しいというか、いい刺激になりました。
話しかけたかったけど、色んな人たちに囲まれていて話しかけられず、後悔です。