今年も始まりました。#AWSSummit。
普段行くものとは一番異なる点。そうDJがいるということ。
何かショーが始まりそうな華やかなオープニングです。
投稿が遅くなりがちなのでいっそ書きながら投稿してみましたが、最終系までには時間かかってしまいました。。
基調講演
- クラウドは今やニューノーマルになった
- 3年前5年前に興味を示さなかった顧客が興味を示しだした
- matzさんの話を思い出した
- Ruby東京プレゼンテーション2015 にいってきた#使えると使えないのタイムラグ
- イノベーションは少し先をいく
- わかってもらえない
- たたかれる
- 心が折れそうになる
- matzさんの話を思い出した
- 広告宣伝費全くなしで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＄
- インスタンスはR3シリーズのみの提供
特徴
- クエリ性能の向上
- 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の合計値
- 上限に達していたら大きいタイプに変更すると改善される
- 最適化インスタンスについてはココ↓をみる
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らしいなと思いました。
すでにあるモノはとことん活用して、すでにあるモノでは物足りない場合は自分たちで改善したモノを作ってしまう。
そいうところはエンジニアだからこそできる楽しいところだなーと。
あとびっくりしたのは、元(?)同期が登壇していたのはちょっと悔しいというか、いい刺激になりました。
話しかけたかったけど、色んな人たちに囲まれていて話しかけられず、後悔です。