AWS Summit 2015 - Day1 - keynote
Keynote のメモ
AWS Japan CEO 長崎さん
昔Jeffが書いたメモ
- 低コスト構造を作り、それをローコスト化につなげることで、顧客満足度が高まる
- この構造がアマゾンのモデル
スケール、スピード、イノベーション
-
- 店舗がないので、テクノロジーが命
- サーバが間に合わない、などは命取り
- 顧客の価値にフォーカスしろ！
- 社内調査した所、開発者の時間のほとんどが、サーバのおもりに費やされていた
- ビジネスをより早く
- ワンクリックでサーバの準備が出来るようにし、インフラをプログラマブルにすることで価値にフォーカスできる
S3は年間102%の成長率
- EC2も93%の成長率
- 100万のアクティブユーザー
- 多くのパートナー企業
- 増え続けるAWSソフトウェアとSaaS
- ESP
- 冊子にしました
ユーザーコミュニティ
クラウドは今やニューノーマルに
- 特定の先進的な企業が使うものから、普通の企業が使う当たり前のソリューションに
スタートアップによるビジネスの開始
- やりたいことが即座に低コストに、初期投資を抑えて変動費に
- スピードを重視
aribnb
- ５人のエンジニアがAWSを使って運用している
- Dropbox
クラウドワークス 吉田さん
昨年上場
- 36で一度ビジネス失敗
- そこから再スタート
- AWSで始めて、3年でここまできた
クラウドソーシングとは
- 新しい外注方法
- 個人に対する発注
- 個人の労働力を企業が活用できる
歴史的に、経営は持たざる経営が進む
- 利用は9万社を突破
- 時価総額ランキングトップ10中8社が利用している
東証の鐘はユーザーに叩いてもらった
年収1000万でクラウドワークスで稼いでいる人もいる
新しい形の地方創世
ガイアの夜明けで次回取り上げてもらえる予定
- 錦織の試合が無ければ、今夜ｗ
100% AWS上で完結している
リクルートテクノロジーズ 中尾さん
- 海外に1000拠点
ビジネスは「リボンモデル」
2年半前に分社
- その一つがリクルートテクノロジーズ
リクルートは400以上のサービスを展開
- テクノロジーズは、そのITを支える
- 現在400名の会社
どうつかっているか？
Speed
- Flexbility
Fanctionality
キャンペーン等のトラフィックが予想できない場合に有効
- 同時にpush通知を送る場合
- 秒間に14000に送れる
長崎さん
- 素早いプロビジョン
それをすぐに縮退できるか
コアなサービス部分
既存の資産を容易にするサービス群
Gartner
実際の業務のサイズ・形は千差万別
ニーズに合ったプラットフォームを用意することで、これを解決してきた
共有ファイルシステムの課題
９年の運用実績
- 既存の資産を運用するのとは、全く違う規模感
データの収集・保管・分析・共有はとても困難だった
機械学習を利用する顧客が急増中
- Amazonは元々レコメンデーションで機械学習を利用
これをもっと社内で活用できないか？
Amazon Machine Learning
- フルマネージド型機械学習サービス
- ハードウェアも気にしなくて良い
Aurora
Amazon WorkSpaces
- ソフト・ハードの管理不要
- 様々なデバイスからアクセス可能
- 月額利用オンプレより半分の価格
Amazon ECS
Amazon Lambda
- コンピューティングリソースを極小化
- イベントをトリガーにコンピュータを起動
- そのイベントの時間しか課金されない
- 今までだと、インスタンス単位での課金(1h)だった
- 100msならその分だけ
第三者認証と監査により証明された、高いセキュリティ基準と運用基準
ファーストリテイリング CIO 玉置さん
売上高1兆3800億円！
作るシステムは最初からグローバル
- 直感的に、マニュアルいらずでどのデバイスでも動く
スピードに応えるクラウド
なぜAWS?
- 重視しているのは、Large Community
- エンジニア・デベロッパーを惹きつけて、自発的なエコシステムを作る魅力がある
- ここに非常に魅力を感じている
瞬間で、11万リクエスト/sec
正直、サイジングがきちんとあたった覚えが殆ど無い
そんなものよりAWSのスケーリングにかけている
マルチリージョン
Now Hiring!
長崎さん
- 「重力」には逆らえない
- 変化や未知のものはだれでも怖い
AWS Summit 2015 - Day1 - Amazon CloudSearch Deep Dive
- AWS 篠原さん
SnapDish事例
ランチセッション
- ランチといえば
- お弁当どうしよう
CloudSearchで検索を入れてる
そもそもどういうさーびす？
フルマネージドな検索エンジン
- 多言語対応 34言語
- ハイライト、サジェスト、地理など
AWSの中ではマイナー
Amazonで買い物すると。。。検索の下でA9というのが出る
- スタンフォードにA9.com
- そこで作ってる
どう使う？どういうもの？
南北線の検索をしたい
- 海外で発表したら、東京都地下鉄やばいという話になった
検索ドメインの作成
- 南北
- JSONで駅のコード、駅名などのデータファイルを作成(SDF)
- upload
- すると、勝手にスキーマ定義
- フィールド指定にDynamic Fieldも使える
プルダウンで選ぶだけで、日本語でのトークナイズができる
あとはもう、検索すれば出る
- OR検索とかも出来る
-
- 辞書のカスタマイズが可能
- きゃりーぱみゅぱみゅ、とか
- データファイルを作って、定期的に辞書に取り込んだり
- 辞書のカスタマイズが可能
シノニム・類義語
- これらもWebやCLIから登録できる
Bi-gram Index
- 言語をMultiple Languageにセットすれば使える
- 2文字ずつで切るとノイズが発生
- 東京都と京都
形態素解析とBi-gramを組み合わせて使う
- SourceField
- 両方でor検索的にして、形態素解析側を優先する
ソート順はTF-IDF
- ドキュメントにその言葉がいっぱい出てくるなら、高スコアにする
様々なexpression
- 結果の重みづけ、調整ができる
A/Bテスト機能
- 重み付けを変えた場合の結果を比較する機能
複数の方の組み合わせ
よみがなをベースとしたSuggestion
可用性、IAMによる管理
- AWS Security Blogにもいい例がある
Inside Amazon CloudSearch
フルマネージド
- Auto Pertitioning
- Auto Scaling
中身がどうなっているのか？
Indexing
- 中身はELBがいて、その裏にEC2が並んでる状態
- データを保存する場合に、どれかのノードに送られる
- そのノードが、ひとまずレスポンスを受け取った上で、DynamoにUpload。その後は非同期処理
- 定期的にS3/Dynamoにポーリングして、担当の処理があれば処理・Indexを作る
Query
- 受け付けるところまでは同じ
- 一般的なEC2の場合と同じAutoScalingが動いている
- クエリの量が増えると、それによって増える
AutoPertitioning
- データ容量の増加にどうやって対応してるか
最初はスケールアップ
- なので、ダウンタイムはないが切り替わり中はIndexingが反映されないことがある
１ノードでまかないきれなくなったら、スケールアウト
検索ドメインの変更など
- 同様にEMRで
初期のデータを投入する場合
大量のリクエストに備えて事前対応
導入事例
schoo
- 爆速で導入
- リリースまで1週間
nanapi
- デフォルトのまま使ってる
- それでもいい感じに検索できている
Chatwork
- 日本最大級の利用例
- 5億件以上のデータ
- 運用はほぼメンテナンスフリー
- CloudSearchにして速度はかなり改善した
更に知りたい方に
- DocValues
- CloudSearch SAのビデオ
- たとえば、普通のqとfq(filter query)の性能差とか
AWS Summit 2015 - Day1 - Aurora Deep Dive
- AWS 星野さん
Auroraについて
- RDSの5番目のエンジン
- クラウド時代に特化した新しいDBエンジン
previewだが、5/20からproduction環境に移行
料金体系
- R3シリーズのみの提供
- ライセンス料は不要
- MySQLとのコンパチブルを保つ
- ロックインはない
特徴
なぜデータベースを再考したか
モノリシックなDB
- 複数の機能レイヤーが１つのアプリケーションになっている
- スケールアウトする場合、このセットで増やす必要がある
- コスト・可用性・柔軟性の問題
今、再実装するならどうなるか？
- 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異常な以下は確認
Auroraの使いドコロ
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スペックを考慮
- S３のキー(先頭４文字)をランダム化するのが理想
Transform
どこで実行するか？
Amazon EMR
ポイント
Load
- Redshiftへのロード
ファイル一覧や正規表現に寄るCOPYコマンドを指定したり
ロードに失敗したレコードは
stl_load_errorsに格納MAX_LOAD_ERRORを指定し、一定回数のエラーは無視
ポイント
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
- ロード先のテーブルを本番テーブルと差し替えたり
- INSERT ~ SELECT はCOPYと同様にコンピュートノードで並列処理されるので効率が良い
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
まとめ
AWS Summit 2015 - Day1 - デベロッパーが切り拓く、次の時代
プラットフォームの変遷
- 5年スパンぐらいで、なにか起きている感じ
- また今年辺り、なにか新しいムーブメントが来るのでは
テーマ１: 外部環境が変わる中で、変わったこと、変わらなかったこと
変化の最初の頃ってわからない
- EC2が最初話に上がった時、凄さがわからなかった
- iPhoneで、最初誰がネットするんだって感じだった
今クラウド全盛だが、５年後ぐらいには違うことが起こっている
その時はやっているものに安住しないようにする
一番変わったことはなんですか？
変わらない所
やってる時はシンプルなのは不安だし厳しい
- 色々やってると、もっとしっかりした仕様が必要では？と迷うことも
- ただ、実際にはUnixの哲学のようなものが勝つ
テーマ２: 技術を取捨選択した際の大原則・考え方は？
オープンな方を選択してきた
- それが正解かはわからない
テーマを否定するようだが、技術は手段でしか無い
- 技術選択の善し悪しによって、キャリアを築いてくという考え方自体が危うい
- OSSはコミュニティとしてやっていく、というトレンドだからそうしただけ
- それは単純に流儀に乗っただけ
問題を設定して、それを解決するための技術を選択する、というのがあり方
- 選択するのは結構怖くて、ブログに書いて一晩たったらなんかあれれ？ということもある
- メインストリームからみて「おもちゃ」と言われるようなモノを選んでやってったところはある
課題が先にあるか？それとも、おもちゃとして触ってみる感じが強いか？
- やはり課題ベースで触ることが強い
- 興味ベースで触ることもあるが、今やっている仕事の中で何かしら課題が前提としてあるからやってる
- なんの課題もなく触ることはない
自分で問題設定を生み出せる人なんて起業しちゃえばいい、という気持ち(おおばさん)
- 会社にいるのは、問題が常に降ってくるから
技術から出発する、というのは非常に危険だと思っている(伊藤さん)
- この技術ではここまでしかできない、という制限が発生してイノベーションは起きない
- たとえば、デザイナーが先にプロダクトをデザインして、無茶なものを試行錯誤しながら何とかすると素晴らしい物が出来る、ということもある
世の中の大発明みたいなものは、好奇心から生まれるということもある
- 電気とか。最初は皆どうしていいかわからない
- ただ、僕らがやってるのはビジネス。そこは違う
これからの外部環境の変化を、どう迎え撃てばいいか？
- 個人としてどうすればいいか？
チームとしてどうするか？
マネジメントの話(伊藤さん)
- スタートアップだと、曖昧さに対する耐性が高いか低いか、というのが重要になる
- 最初にもやっとしたものを渡されて、徐々に形を作っていく
- モヤモヤした中を皆で突き進んで作っていく
- いい感じのPMがこっちだ！といって引っ張っていってくれるわけではない
- そういう状態でも進めていける人と一緒だと、やりやすい
そもそも変化を受け入れられる、という事が前提(大場さん)
- 開発にかぎらずビジネスを考える
- 開発部門、というかたちで区切ってしまったら、全員がビジネスのゴールを見るのが難しくなってしまった。
- そのため、企画とエンジニアの枠組みを切り離し、各チームにばら撒くようにしてみた
ビジネスのゴールでも、やはり同じ話で、責任を区切るべきではない
- そうやってエンジニアだから、という責任境界を区切らずに、モヤモヤした中でやることを見つけていける力が必要
いちデベロッパーとしてはどうか？
- 年齢の問題もあるが。。。
- 新しいテクノロジーが出てきた時に、一つにフォーカスしていくのは危うい
- 新しいテクノロジーを牽引していくのは、やはり若い人のやること
まとめ
- 最後に一言
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 鼓舞したかったんだろうが、現実が見えてない
- 現実を把握して、その状況を見てやっていく
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 正解がわからないから、いろんな人の話を聞きたくて皆カンファレンスに来てるのだろうが。。。(伊藤さん)
- そんなのはこっちもわからない
- 正解はわからなくていいんだけど、先行ってるのがどれくらいのポジションで、自分がどんな位置にいるのか
- トップと自分とのギャップを把握するのは大事
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
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をインストールして管理。オンプレミスも管理可能
- グループ内に一度にデプロイしたり１台ずつデプロイしたり、といった処理が可能
CloudFormation
Wordpressをデプロイする手法
wordpressのデプロイを題材に、４つのサービスを比較
- コンフィグも自動生成したり。
構成イメージ
どれがベストか、という話をするわけではない。
- 自分達の要件に合うかを検討する材料にしてください。
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 - 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 行ってきたまとめ
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 - 絶品ゆどうふのタレ
