AWS Summit 2015 - Day2 - keynote
- 昨日と同じ話は省略
AWS Mobile Service
Mobile SDK
Mobile SDK for Unity
- Machine Learningのサポート
- Lambdaのサポート
Cognite
- ユーザー認証
- データ同期
- セキュリティ
Cogniteのアップデート
Mobile Analytics
- 短期間でデータを取得
- MAU/DAU/セッション/リテンションレポート
- ユーザーのイベントをトラッキング
Mobile Analyticsアップデート
- S3 / RedShiftへのエクスポート
SNS Push Notifications
- CloudWatchの通知の配信ステータス
- SNSでのLabmdaの起動
成功は突然、予期しないタイミングで来る
- その時のスケーラビリティ
Labmda
- イベント駆動型バックエンド
- 実行時だけの100ms単位の課金
- モバイル単位の課金不要
Lambdaの新たなイベントソース
- SNSからの通知をトリガーにLambdaを起動
- CloudWatch
- Cogniteデータが変更されるごとにLabmdaを実行
- LambdaのJava対応!
LabmdaとCogniteが東京リージョン対応
IoT
- Dash.lyの事例
- ODB-2ポートのデータをKinesisに送って解析
Kawamotoさん
- スイスアーミーナイフとRDBは似てる
色々な機能を持っている
- だが、拡張が難しい
Dynamo
- Amazon.comの救世主となるDB
- 拡張性・スキーマレス
基板となるインフラ運用にはまだ課題があった
- ベンチマーク
- キャパシティプランニング
一元化したサービスの運用
キーワードはマネージドサービス
DynamoDBのリリース
- フルマネージドのNoSQL
- 高可用性・堅牢性
- 3つのゾーンでレプリケーション
Dynamoはモバイル・IoTにも効果的
DynamoDB Stream
- DBの更新情報を外部アプリケーションから利用可能
- Device -> Dynamo -> Stream -> lambda -> Redshift/SNS/Machine Learningなどの連携
Community HERO 横田さん
スシローとガリバーの事例
スシロー
ガリバー
- モバイル業務アプリ
- Cognite ベースで認証
- モバイルからLabmda -> Dynamo -> Labmda -> SNSで通知
ほとんどEC2を使っていない
- 最初にAWSを使おうと決意すると、まずオンプレからEC2に移そうとかんがえる
- 次のステップで出てくるのがこれらのクラウドネイティブなサービス
- マネージドサービスを組み合わせることで、運用・構築をもっと楽に
Gene
- モバイルのもう一つのアプローチ
- エンタープライズモビリティ
- WorkSpaces
- WorkDocs
- WorkMail
すべてがモバイルデバイス対応
- タブレットの例
Amazon WorkDocsの日本語UI・東京リージョン
Wrap up
- 10月にAWS re:Invent
AWS Summit 2015 - Day1 行ってきたまとめ
AWS Summit 2015 に行ってきた!
とりあえず自分の参加したセッションの内容を全部記事化した(一つに書くには長すぎた)ので、 まとめ用Index記事をつくったよ!(`・ω・´)
- AWS Summit 2015 - Day1 - keynote - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - Amazon CloudSearch Deep Dive - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - Aurora Deep Dive - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - Redshift Deep Dive - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - デベロッパーが切り拓く、次の時代 - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - 自動デプロイ - 絶品ゆどうふのタレ
- AWS Summit 2015 - Day1 - EBSパフォーマンスベンチマーク2015 - 絶品ゆどうふのタレ
雑感
AWS Summit 2015 - Day1 - EBSパフォーマンスベンチマーク2015
- AWS 小林さん
EBSのおさらい
- ブロックレベルのストレージ
- スナップショットを使ってバックアップ
- 暗号化
99.999%の可用性
特徴
- 容量は1G単位で16TBまで
- マグネティックは1TBまで
- AZごとに独立
- スナップショットから任意のAZに復元可能
- 容量は1G単位で16TBまで
-
- 付け替えは可能
アーキテクチャ
ボリュームタイプ
汎用SSD
- デフォルト
- 費用対効果の高いディスク
- 一時的に3000IOPSになるバースト機能を備えている
1GBあたり3IOPSを常時確保(ベースパフォーマンス)
- 容量が1000GB以下の場合は3000IOPSに一時的に引き上げるバーストが可能
- たとえばOS起動時にはバーストさせて一気に起動させたり
- 最大は10,000 IOPSまで上昇
- 3334GBを超えたところで、常時10000IOPS
- 容量が1000GB以下の場合は3000IOPSに一時的に引き上げるバーストが可能
バーストの継続時間はIOクレジットの残高で決まる
- バーストが発生するとクレジットを消費
- 下回ったら時間とともにクレジットが溜まっていく
容量とスループット
- 容量依存でスループットが上がる
- 170GB以下では128MB/s
- 徐々に上がる
- 214GB以上では常時160MB/s
Provisioned IOPS
- SSDを超える性能
- 99.99%の時間について、指定IOPSの+-10%の範囲で性能発揮する
- 最大20000IOPSまで
- 最大320MB/s(1280IOPS以上)
- IOPS設定値依存
Magnetic
- 磁気ディスク
- かつてのデフォルト
- コスト安
- 1TBまで
- 平均100IOPS
- 最大数百IOPSまでバーストできる場合がある
- IOPSの命令回数ベースで課金
パフォーマンスの律速要素
EC2インスタンス側のスループット
- EBS-Optimized オプションを有効に
インスタンスタイプごとに上限値があるので、そこに到達していないか
- CloudWatchの Volume Read/Write Bytesの合計値で判断
上限に達している場合は、インスタンスタイプを大きくする
- EBS最適化をOnにすると、EBSへのアクセス回線をインターネットの帯域と別に確保する
- インスタンスタイプごとに帯域が異なる
EBS側のIO性能を改善する
- EBS側の実績値を確認する
- CloudWatchの Volume Read/Write Opsを参照
- OS から見てもいい
- 上限に達していたばあいは、ボリュームの上限を改善
EBS側のスループットを改善する
事前ウォーミング
- EBS各ブロックの初回アクセスに限り、IOPSが5~50%低下する
- 性能測定など
- プレウォーミングを実施すると、回避できる
実運用時には事前ウォーミング不可能な場合もある
実行方法
RAID構成
ベンチマーク検証
- それぞれのボリュームタイプについて、仕様通りの性能が出ていることを確認
RAIDによってそれを超えた性能が出せることをチェック
構成
- c3.8xlarge
- 2015.03
- xfs
- EBSはpre-warmingずみ
このへんはもうグラフ見ないと伝えづらい。。。
- こまかいブロック(8KB, 16KB)の場合はIOPSが高まって、そちらで頭を打つ
- スループットは余力があがったりする
- 大きなブロック(4MB)の場合は、IOPSの上限の前に、スループットが頭を打ってしまう
- 大きなブロックの場合、IOPS値を大きく取り過ぎてしまうと費用がもったいない場合があるので、注意
インスタンスストアとEBS
- もっと性能が欲しい場合は、インスタンスストアを使う
- 追加ストアなしで使えるディスク
- スループットはEBSとは独立している
- インスタンスを止めるとデータは消える
- 再起動では消えない
- アプリケーションが使う一時的なデータの置き場所や分散システムのデータ置き場
ベンチマークをしてみる
ボリュームの暗号化
- AES-256
- ハードウェア機能を使って暗号化するので、パフォーマンスに影響しない
- ほんと?というのを確認
fioで負荷をかけてiostat/vmstatでチェック
実際にグラフを見ると、IOPSはほぼ変わらない
- CPU使用率も殆ど差がない
典型的な構成例
小さいデータへのアクセスが多い場合
大きいデータへのアクセスが多い場合
- IOPSよりもスループットを重視
- シーケンシャルな場合も同様
- 無駄にIOPSを高めないようにするほうが、コストを抑えられる
低コストなストレージが必要な場合
- アクセス頻度が低い・パフォーマンスが不要な場合はマグネティック
極めて高いIOが必要な場合
- インスタンスストアを利用する
- OSやアプリケーションが必要とする大事なデータはEBSを利用する
まとめ
AWS Summit 2015 - Day1 - 自動デプロイ
- Elastic Beanstalk, Opsworks, CodeDeploy, CloudFormation
AWS 舟崎さん
どう使い分けたらいいか、どう組み合わせるか
Intro
- EC2 / ELB / RDS / S3 を組み合わせる事が非常に多い
設計としては多いが、デプロイを自動化する点まで考えられていることは少ない
- デプロイの自動化がなぜ必要か、はこのセッションの対象ではない。その前提で話す。
デプロイを考える際のフェーズ
- コーディング
- ビルド
- テスト
- デプロイ
- プロビジョン(リソース生成)
- モニタリング
Code Commit
Code Pipeline
- コードをデプロイする際の処理・ワークフローを自動化させる
- まだAWSとしてリリースされてない
Elastic Beanstalk / OpsWorks
- Deploy / Provision / Monitor
- Code Deploy
- Deploy のみ
- CloudFormation
- Provisionのみ
- Cloud Watch
- 監視
Elastic Beanstalk
- 定番構成の構築・アプリデプロイの自動化サービス
Opsworks
- 多様なアーキテクチャをサポートするデプロイ・管理サービス
- chefのレシピを使ってデプロイや運用タスクを自動化可能
- ライフサイクルイベントに従った動的な構成の変更
- 継続的な構成管理
Code Deploy
- アプリケーションのデプロイに特化
- agentをインストールして管理。オンプレミスも管理可能
- グループ内に一度にデプロイしたり1台ずつデプロイしたり、といった処理が可能
CloudFormation
Wordpressをデプロイする手法
wordpressのデプロイを題材に、4つのサービスを比較
- コンフィグも自動生成したり。
構成イメージ
どれがベストか、という話をするわけではない。
- 自分達の要件に合うかを検討する材料にしてください。
Beanstalk
起動の流れ
- ElasticBeanstalkがインスタンスを起動
- 中にHost Managerが入っていて、それが通信
GitHubと連携
- 順次バッチ処理でのデプロイ
- 一度に(1台/25%/全部)にデプロイ
- というのを調整できる
- Blue Green Deploy なんかもあり(今回は違う)
- 一度に(1台/25%/全部)にデプロイ
- 環境のカスタマイズ
- AMIを作りなおさなくても、Elastic Beanstalk Configuration fileで動作中のコンテナをカスタマイズできる
- 環境設定のRolling Update
- インスタンスの置換えを伴う操作を一部ずつ実行
- 裏ではCloudFormationのupdate policyという機能で実現してる
OpsWorks
起動の流れ
OpsWorksに指示を出すと、Agentがポーリングに合わせてAppを取得
- デプロイJSON を書いておけば、それをchefのレシピの中から呼び出せる
レシピの実行タイミングについて
Cookbookの更新
- リポジトリにPush
- カスタムCookbookの適用を指示
- ポーリングのタイミングで適用される
Code Deploy
サーバは起動しないので、自分でエージェントを入れる
- 入れたら、グループにインスタンスを追加
Depoyの流れ
- 環境のカスタマイズ
- appspec.ymlのなかに、hooksを設定できる
- shellscriptの実行が可能
- CloudFormation都の連携
CloudFormation
- CloudFormation template(JSON)の中にプロビジョニングとデプロイの内容を書いておく
- 頻繁にデプロイしないのであれば、CloudFormationでやってしまうのがいい
- 頻繁にやるなら、プロビジョニングだけを担当させる方がいい
まとめ
- それぞれ簡単にできるが、手順が異なる
- 要件に合わせて活用してください
AWS Summit 2015 - Day1 - デベロッパーが切り拓く、次の時代
プラットフォームの変遷
- 5年スパンぐらいで、なにか起きている感じ
- また今年辺り、なにか新しいムーブメントが来るのでは
テーマ1: 外部環境が変わる中で、変わったこと、変わらなかったこと
変化の最初の頃ってわからない
- EC2が最初話に上がった時、凄さがわからなかった
- iPhoneで、最初誰がネットするんだって感じだった
今クラウド全盛だが、5年後ぐらいには違うことが起こっている
その時はやっているものに安住しないようにする
一番変わったことはなんですか?
変わらない所
やってる時はシンプルなのは不安だし厳しい
- 色々やってると、もっとしっかりした仕様が必要では?と迷うことも
- ただ、実際にはUnixの哲学のようなものが勝つ
テーマ2: 技術を取捨選択した際の大原則・考え方は?
オープンな方を選択してきた
- それが正解かはわからない
テーマを否定するようだが、技術は手段でしか無い
- 技術選択の善し悪しによって、キャリアを築いてくという考え方自体が危うい
- OSSはコミュニティとしてやっていく、というトレンドだからそうしただけ
- それは単純に流儀に乗っただけ
問題を設定して、それを解決するための技術を選択する、というのがあり方
- 選択するのは結構怖くて、ブログに書いて一晩たったらなんかあれれ?ということもある
- メインストリームからみて「おもちゃ」と言われるようなモノを選んでやってったところはある
課題が先にあるか?それとも、おもちゃとして触ってみる感じが強いか?
- やはり課題ベースで触ることが強い
- 興味ベースで触ることもあるが、今やっている仕事の中で何かしら課題が前提としてあるからやってる
- なんの課題もなく触ることはない
自分で問題設定を生み出せる人なんて起業しちゃえばいい、という気持ち(おおばさん)
- 会社にいるのは、問題が常に降ってくるから
技術から出発する、というのは非常に危険だと思っている(伊藤さん)
- この技術ではここまでしかできない、という制限が発生してイノベーションは起きない
- たとえば、デザイナーが先にプロダクトをデザインして、無茶なものを試行錯誤しながら何とかすると素晴らしい物が出来る、ということもある
世の中の大発明みたいなものは、好奇心から生まれるということもある
- 電気とか。最初は皆どうしていいかわからない
- ただ、僕らがやってるのはビジネス。そこは違う
これからの外部環境の変化を、どう迎え撃てばいいか?
- 個人としてどうすればいいか?
チームとしてどうするか?
マネジメントの話(伊藤さん)
- スタートアップだと、曖昧さに対する耐性が高いか低いか、というのが重要になる
- 最初にもやっとしたものを渡されて、徐々に形を作っていく
- モヤモヤした中を皆で突き進んで作っていく
- いい感じのPMがこっちだ!といって引っ張っていってくれるわけではない
- そういう状態でも進めていける人と一緒だと、やりやすい
そもそも変化を受け入れられる、という事が前提(大場さん)
- 開発にかぎらずビジネスを考える
- 開発部門、というかたちで区切ってしまったら、全員がビジネスのゴールを見るのが難しくなってしまった。
- そのため、企画とエンジニアの枠組みを切り離し、各チームにばら撒くようにしてみた
ビジネスのゴールでも、やはり同じ話で、責任を区切るべきではない
- そうやってエンジニアだから、という責任境界を区切らずに、モヤモヤした中でやることを見つけていける力が必要
いちデベロッパーとしてはどうか?
- 年齢の問題もあるが。。。
- 新しいテクノロジーが出てきた時に、一つにフォーカスしていくのは危うい
- 新しいテクノロジーを牽引していくのは、やはり若い人のやること
まとめ
- 最後に一言
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 鼓舞したかったんだろうが、現実が見えてない
- 現実を把握して、その状況を見てやっていく
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 正解がわからないから、いろんな人の話を聞きたくて皆カンファレンスに来てるのだろうが。。。(伊藤さん)
- そんなのはこっちもわからない
- 正解はわからなくていいんだけど、先行ってるのがどれくらいのポジションで、自分がどんな位置にいるのか
- トップと自分とのギャップを把握するのは大事
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
AWS Summit 2015 - Day1 - Redshift Deep Dive
Redshiftの概要
LeaderNodeと並列のComputeNode
超並列演算
- CPU / disk /network /ioの並列化
データの格納
- 列思考(カラムナ)
各CPUコアにプロセスを張り付けていくような形で実行していく
- ノードスライス
データのロード
- COPYコマンドを実行すると、S3から直接ComputeがCSVファイルを引っ張ってくる
- ファイル数はスロットの倍が望ましい
Redshiftの主要アップデート
カスタムドライバ
- Redshift用ネイティブドライバが出た
- PostgreSQLのドライバよりも、パフォーマンス、信頼性が高い
Interleaved Sort Key
- Sort Keyを複数のカラムで指定可能になった
- それぞれのキーがフェアに扱われるようにデータが格納される
インテグレーション
データ連携をどうするか
オンプレミスとのデータ連携
- S3に一旦CSVをアップロード
- オンプレミスからRedshiftへの直接insertは推奨していない
- 不可が高い場合はDynamoなどを一旦挟んでからRedShiftへ
AWSサービス間のデータ連携
- S3がハブとなり、他のサービスと連携
- Data Pipeline
- Kinesis
- Lambda
サンプルシナリオ
- シナリオ
- RDBMSから抽出
- S3へアップ
- EMRに変換
- Redshiftにロード
バッチ
- Talendというツールを使ってみた
- 一旦S3にアップロード
- EMRに流してフィルタリング
結果をRedShiftへ
Talend
Extract
- CSVファイルとしてレコードを抽出
この時点で複数ファイルに分割
Change Data Capture - CDC
ポイント
- 大量レコードの場合は、メモリの枯渇を防ぐためにカーソルを利用
- 抽出後、圧縮すればアップロード時のコスト削減
- ファイル分割数は、スロットの倍に
Upload
- S3に並列アップロード
転送時間が短縮できる
ポイント
- Uploadの並列度は、クライアント側のCPUスペックを考慮
- S3のキー(先頭4文字)をランダム化するのが理想
Transform
どこで実行するか?
Amazon EMR
ポイント
Load
- Redshiftへのロード
ファイル一覧や正規表現に寄るCOPYコマンドを指定したり
ロードに失敗したレコードは
stl_load_errors
に格納MAX_LOAD_ERROR
を指定し、一定回数のエラーは無視
ポイント
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
- ロード先のテーブルを本番テーブルと差し替えたり
- INSERT ~ SELECT はCOPYと同様にコンピュートノードで並列処理されるので効率が良い
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
まとめ
AWS Summit 2015 - Day1 - Aurora Deep Dive
- AWS 星野さん
Auroraについて
- RDSの5番目のエンジン
- クラウド時代に特化した新しいDBエンジン
previewだが、5/20からproduction環境に移行
料金体系
- R3シリーズのみの提供
- ライセンス料は不要
- MySQLとのコンパチブルを保つ
- ロックインはない
特徴
なぜデータベースを再考したか
モノリシックなDB
- 複数の機能レイヤーが1つのアプリケーションになっている
- スケールアウトする場合、このセットで増やす必要がある
- コスト・可用性・柔軟性の問題
今、再実装するならどうなるか?
- 1970年代の方法では実装しない
- スケールアウトが簡単で、セルフヒーリングなもの
- AWSと簡単に連携したい
これをフルマネージドで提供する
アーキテクチャ
- ログレイヤ
ストレージレイヤ
- バックにスケールするストレージサービスを採用
- EC2 / Dynamo / SWF などを管理コンポーネントに採用
キャッシュレイヤの分離
- キャッシュをDBプロセスの外に置いた
- DBを再起動しても、キャッシュが残る
ストレージ
リードレプリカも同じストレージを参照
- 壊れた場合も再ストレイピング、ミラーの修復なども自動で走る
Log Structured Storage
- 追記型のストレージシステム
- 常に末尾にデータ追加
- GC
- 新規データは末尾に追記
- これが10GBのチャンクごとに書き込みが行われる
- 追記型のストレージシステム
ディスク障害検知
- 2つのコピーに障害があっても読み書き可能
- 3つ障害があっても読込は可能
- 自動検知して修復
-
- Binlogによるレプリケーションではない
- 同一のディスクを見ている
- マスターの負荷を最小限にしつつ、15台のリードレプリカを作成可能
- 同じデータのディスクを参照しているので、フェイルオーバーしてもデータロスがない
- Binlogによるレプリケーションではない
セキュリティ
- データの暗号化
- SSL
- 直接ログインは不可
DBクラスタ
- DBクラスタという概念を持っている
- マスタとリードレプリカ
- DB Parameter Group / Cluster Parameter Group
- DBクラスタという概念を持っている
新しいメトリクス画面
- キャッシュ・CPU使用率についてわかりやすくなる
フェイルオーバーとリプレース
- リードレプリカがある場合は1分程度でフェイルオーバー可能
- 優先的にフェイルオーバーさせるノードを指定可能
- ノードリプレース時の起動先AZを指定可能
クラスタエンドポイント
- WriterのCNAMEになっていて、壊れたら別の新しいノードに切り替わる
- Readerはそうはなっていないので、アプリケーションで対応
高速なデータ修復
- 並列、分散、非同期で行われる
Streaming snapshotとPITR
- バックアップを残す期間を指定可能
- 任意の時間に秒単位で戻すことが可能
- 現在では、2分前のデータから可能
SQLによるフェイルオーバーのテスト
- 擬似的に障害をシミュレート
パフォーマンスを引き出すために
- クエリ並列度が高い、データサイズが大きいケースで効果を発揮
ロックやQuery Cacheに手を入れて、性能を向上
CPU利用率はMySQLに比べて効率化
パフォーマンス
-
- MyISAMのテーブルは無いのでコンバートされる。1.5TB異常な以下は確認