絶品ゆどうふのタレ

ふと気づいたことを綴るだけのメモ

負荷テストツールGatlingを触ってみた

負荷ツールとしてGatlingのことを少し前から耳にする機会が増えたので、利用してみることにした。

色々既出だとは思うが、公式のQuickstartに従って試してみたのでメモ。

GUIが必要だったので、今回は手元のMacで実行。

Gatlingとは

Java/Scala製の負荷テストツール

JMaterと似た感じのツールではあるが、

  • ハイパフォーマンス
  • 見やすいレポートHTML
  • developerフレンドリーなシナリオファイル

というのをウリとして謳っている。

たぶん、3項目とも対JMater(重い・レポート見づらい・XMLのシナリオつらい)を意識したメリットだろうなー。

なお、シナリオファイルは。。。

Gatling simulation scripts are written in Scala, but don’t panic!

わろた。

というわけで、触ってみる

Install

JavaとGalingをインストールする。Gatlingはunzipするだけ。

% brew cask install java
% wget https://repo1.maven.org/maven2/io/gatling/highcharts/gatling-charts-highcharts-bundle/2.1.6/gatling-charts-highcharts-bundle-2.1.6-bundle.zip
% unzip gatling-charts-highcharts-bundle-2.1.6-bundle.zip

シナリオの作成

テストシナリオ

まず最初に、テストシナリオを決める。チュートリアルに従って以下のとおり。

Gatling Recorderによるシナリオの記録

シナリオの作成には、Gatling Recorderを使う。

Gatling Recorderは、proxyを通してブラウザアクセスして記録を取ことで、Scalaで書かれたシナリオファイルを自動生成してくれるツール

もちろん、自分でScalaを書いてシナリオ作りをしても良いが、今回は手軽にできるproxy式の手法をとる。

起動と設定

Gatling Recorderを起動する。

% cd gatling-charts-highcharts-bundle-2.1.6
% bin/recorder.sh

ツールが起動したら、初期設定として以下のように項目を埋める。

f:id:Yudoufu:20150613170429p:plain

この状態で、WebプロキシとしてGatling Recorderを設定する。

f:id:Yudoufu:20150613170522p:plain

ブラウザアクセスでシナリオを作る

Start を押すと設定に従ってproxyが起動するので、ブラウザでアクセスしながら記録を取る。

シナリオ作成時のTipsとして、変なpluginなどの影響がないようにsecret windowでやるとよさ気。 また、Gatling Recorderにはログの間にTAGを差し込む機能があり、シナリオの記録が綺麗になるのでそれも活用するといい。

ということで、以下の流れで操作を記録する。

f:id:Yudoufu:20150613170548p:plain

ここまで実行し終わったら、Stop & Saveを押すと、user-files/simulations/computerdatabase/BasicSimulation.scalaにシナリオファイルが保存される。

内容は以下のようになった。

package computerdatabase

import scala.concurrent.duration._

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import io.gatling.jdbc.Predef._

class BasicSimulation extends Simulation {

    val httpProtocol = http
        .baseURL("http://computer-database.herokuapp.com")
        .inferHtmlResources(BlackList(""".*\.css""", """.*\.js""", """.*\.ico"""), WhiteList())
        .acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8")
        .acceptEncodingHeader("gzip, deflate, sdch")
        .acceptLanguageHeader("ja,en-US;q=0.8,en;q=0.6")
        .userAgentHeader("Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.39 Safari/537.36")



    val uri1 = "http://computer-database.herokuapp.com"

    val scn = scenario("BasicSimulation")
        // Search
        .exec(http("request_0")
            .get("/"))
        .pause(5)
        .exec(http("request_1")
            .get("/computers?f=macbook"))
        .pause(2)
        .exec(http("request_2")
            .get("/computers/6"))
        .pause(10)
        // Browse
        .exec(http("request_3")
            .get("/"))
        .pause(2)
        .exec(http("request_4")
            .get("/computers?p=1")
            .resources(http("request_5")
            .get(uri1 + "/computers?p=2"),
            http("request_6")
            .get(uri1 + "/computers?p=3")))
        .pause(2)
        .exec(http("request_7")
            .get("/computers/72"))
        .pause(1)
        .exec(http("request_8")
            .get("/"))
        .pause(1)
        .exec(http("request_9")
            .get("/computers?p=1")
            .resources(http("request_10")
            .get(uri1 + "/computers?p=2")))
        .pause(3)
        .exec(http("request_11")
            .get("/computers/70"))
        .pause(10)
        // Edit
        .exec(http("request_12")
            .get("/"))
        .pause(1)
        .exec(http("request_13")
            .get("/computers/new"))

    setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}

以上でシナリオの作成は完了。

テストの実行

今のシナリオを元に、Gatlingを起動する

% bin/gatling.sh

しばし待つと、実行候補となるシナリオの一覧が出てくるので、対象を選ぶ。(今回は0) なお、BasicSimulation以外の候補は、元々含まれているサンプル。

その他の質問もとりあえずEnterして実行する。

Choose a simulation number:
     [0] computerdatabase.BasicSimulation
     [1] computerdatabase.advanced.AdvancedSimulationStep01
     [2] computerdatabase.advanced.AdvancedSimulationStep02
     [3] computerdatabase.advanced.AdvancedSimulationStep03
     [4] computerdatabase.advanced.AdvancedSimulationStep04
     [5] computerdatabase.advanced.AdvancedSimulationStep05
0
Select simulation id (default is 'basicsimulation'). Accepted characters are a-z, A-Z, 0-9, - and _

Select run description (optional)

Simulation computerdatabase.BasicSimulation started...

するとテストが実行され、最終的に結果が出力される

================================================================================
---- Global Information --------------------------------------------------------
> request count                                         18 (OK=18     KO=0     )
> min response time                                    191 (OK=191    KO=-     )
> max response time                                    414 (OK=414    KO=-     )
> mean response time                                   217 (OK=217    KO=-     )
> std deviation                                         64 (OK=64     KO=-     )
> response time 50th percentile                        195 (OK=195    KO=-     )
> response time 75th percentile                        197 (OK=197    KO=-     )
> mean requests/sec                                  0.441 (OK=0.441  KO=-     )
---- Response Time Distribution ------------------------------------------------
> t < 800 ms                                            18 (100%)
> 800 ms < t < 1200 ms                                   0 (  0%)
> t > 1200 ms                                            0 (  0%)
> failed                                                 0 (  0%)
================================================================================

Reports generated in 0s.
Please open the following file: results/basicsimulation-1434181826508/index.html

結果の確認

results/basicsimulation-1434181826508/index.htmlにレポートが出力されたようなので、見てみる

% open results/basicsimulation-1434181826508/index.html

f:id:Yudoufu:20150613170606p:plain

思った以上にリッチなレポートが出力されていて、全体のrpsの状況や成功失敗のグラフ、各リクエストごとの詳細な情報、パーセンタイル値などが出た。

f:id:Yudoufu:20150613170622p:plain

f:id:Yudoufu:20150613170634p:plain

f:id:Yudoufu:20150613170721p:plain

今回のテストは動作チェック程度なので大したグラフになっていないが、これはまじめに負荷テストやるとすごく良さそう。 機会があったら、プロダクト側で使ってみたい。

Embulkではてなブログの記事をparseしてElasticsearchに入れてみる

Embulk良さそうだね、と言いつついじったことなかったので。 先日ちょっと近所で話題に上がったので、仕事中に息抜きでやってみた。on mac

先にまとめ

  • input / parser / execute / outputと、細かく分けてpluginになっており、一般的な形式ならほぼ組み合わせていける
    • 異常に楽
  • 一旦input側を作ってstdoutに出す -> outputを作る(もしくは逆順)、とステップを分割して作っていけるので、普通に作るよりハマりにくそう
    • sampleのinputデータも自動生成してくれるので、outputを先に作っても楽だったと思う(今回はやらなかったけど)
  • pluginを取り扱うのにembulk gemコマンドとか用意されてて地味に便利
  • 関係ないけどbrewすげぇ

Embulkのinstall

手元のMacでの実験なのでこんな感じ

% brew cask install java
% brew install embulk

RSSを取得してSTDOUTに出力させる

一気にやるとわからなくなるので、とりあえずRSSから取得してstdoutに出してみる

参考にするのは以下のあたり

Pluginをinstall

% embulk gem install embulk-input-http
% embulk gem install embulk-parser-xml

config.ymlの作成

  • inputhttpparserとしてxmlを使う
in:
  type: http
  url: http://yudoufu.hatenablog.jp/rss
  params: ~
  parser:
    type: xml 
    root: rss/channel/item
    schema:
      - { name: title, type: string }
      - { name: link, type: string }
      - { name: pubDate, type: string }
  method: get 
out:
  type: stdout
  • とりあえず標準出力に出す
  • schemaは、descriptionを含めちゃうと

実行

% embulk run config.yml
2015-06-09 16:12:06.611 +0900: Embulk v0.6.5
2015-06-09 16:12:08.400 +0900 [INFO] (transaction): {done:  0 / 1, running: 0}
2015-06-09 16:12:08.681 +0900 [INFO] (task-0000): GET "http://yudoufu.hatenablog.jp/rss"
Norikra meetup #2 に参加してきた,http://yudoufu.hatenablog.jp/entry/2015/06/03/235131,Wed, 03 Jun 2015 23:51:31 +0900
AWS Summit 2015 - Day2 行ってきたまとめ,http://yudoufu.hatenablog.jp/entry/2015/06/03/232347,Wed, 03 Jun 2015 23:23:47 +0900
AWS Summit 2015 - Day2 - 新サービス解説セッション EFS と ML,http://yudoufu.hatenablog.jp/entry/2015/06/03/223904,Wed, 03 Jun 2015 22:39:04 +0900
AWS Summit 2015 - Day2 - クラウドを活用したIoT/M2Mソリューション,http://yudoufu.hatenablog.jp/entry/2015/06/03/223701,Wed, 03 Jun 2015 22:37:01 +0900
AWS Summit 2015 - Day2 - AWS セキュアデザイン(IAM) Deep Dive,http://yudoufu.hatenablog.jp/entry/2015/06/03/223637,Wed, 03 Jun 2015 22:36:37 +0900
AWS Summit 2015 - Day2 - AWS System Operation Deep Dive,http://yudoufu.hatenablog.jp/entry/2015/06/03/223605,Wed, 03 Jun 2015 22:36:05 +0900
AWS Summit 2015 - Day2 - ネットワークDeep Dive,http://yudoufu.hatenablog.jp/entry/2015/06/03/223523,Wed, 03 Jun 2015 22:35:23 +0900
2015-06-09 16:12:09.064 +0900 [INFO] (transaction): {done:  1 / 1, running: 0}
2015-06-09 16:12:09.079 +0900 [INFO] (main): Committed.
2015-06-09 16:12:09.080 +0900 [INFO] (main): Next config diff: {"in":{},"out":{}}
  • ひとまず目的のデータは出た

Elasticsearchに入れてみる

以下の記事やREADMEを参考に、書いてみる

ElasticsearchのInstall

% brew install elasticesearch
  • brewで入れるとcluster_nameelasticsearch_usernameになってるので、必要なら適当に変える
% vi /usr/local/opt/elasticsearch/config/elasticsearch.yml
cluster.name: elasticsearch_yudoufu
% elasticsearch --config=/usr/local/opt/elasticsearch/config/elasticsearch.yml
  • とりあえずこれで、http://127.0.0.1:9200/にnodeが立つ
  • 9300がノード間通信のportで、こっちを使って接続するっぽい

Embulk pluginを入れる

% embulk gem install embulk-output-elasticsearch

config.ymlのoutputを作る

  • out部分を修正
    • 事前にindexを作っておく必要は特にないので、cluster_namenodesの情報だけ合わせておく
out:
  type: elasticsearch
  cluster_name: elasticsearch_yudoufu
  nodes:
    - { host: 127.0.0.1, port: 9300 }
  index: embulk_yudoufulog_rss
  index_type: embulk

実行

% embulk run config.yml
2015-06-09 17:05:01.632 +0900: Embulk v0.6.5
2015-06-09 17:05:03.559 +0900 [INFO] (transaction): [Dominus] loaded [], sites []
2015-06-09 17:05:04.391 +0900 [INFO] (transaction): {done:  0 / 1, running: 0}
2015-06-09 17:05:04.400 +0900 [INFO] (task-0000): [Siena Blaze] loaded [], sites []
2015-06-09 17:05:04.686 +0900 [INFO] (task-0000): GET "http://yudoufu.hatenablog.jp/rss"
2015-06-09 17:05:05.137 +0900 [INFO] (task-0000): Execute 7 bulk actions
2015-06-09 17:05:05.735 +0900 [INFO] (elasticsearch[Siena Blaze][transport_client_worker][T#5]{New I/O worker #22}): 7 bulk actions succeeded
2015-06-09 17:05:05.745 +0900 [INFO] (transaction): {done:  1 / 1, running: 0}
2015-06-09 17:05:05.761 +0900 [INFO] (main): Committed.
2015-06-09 17:05:05.762 +0900 [INFO] (main): Next config diff: {"in":{},"out":{}}

データの確認

  • データ入ったのを確認!!\(^o^)/
% curl -X GET http://127.0.0.1:9200/embulk_yudoufulog_rss/embulk/_search\?q\=AWS\&pretty
{
  "took" : 10,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 6,
    "max_score" : 0.26516503,
    "hits" : [ {
      "_index" : "embulk_yudoufulog_rss",
      "_type" : "embulk",
      "_id" : "AU3XWfGno1wqzcGPiVrl",
      "_score" : 0.26516503,
      "_source":{"title":"AWS Summit 2015 - Day2 - AWS System Operation Deep Dive","link":"http://yudoufu.hatenablog.jp/entry/2015/06/03/223605","pubDate":"Wed, 03 Jun 2015 22:36:05 +0900"}
    }, {
      "_index" : "embulk_yudoufulog_rss",
      "_type" : "embulk",
      "_id" : "AU3XWfGno1wqzcGPiVrh",
      "_score" : 0.111475274,
      "_source":{"title":"AWS Summit 2015 - Day2 行ってきたまとめ","link":"http://yudoufu.hatenablog.jp/entry/2015/06/03/232347","pubDate":"Wed, 03 Jun 2015 23:23:47 +0900"}
    }, {
      "_index" : "embulk_yudoufulog_rss",
      "_type" : "embulk",
      "_id" : "AU3XWfGno1wqzcGPiVrm",
      "_score" : 0.111475274,
      "_source":{"title":"AWS Summit 2015 - Day2 - ネットワークDeep Dive","link":"http://yudoufu.hatenablog.jp/entry/2015/06/03/223523","pubDate":"Wed, 03 Jun 2015 22:35:23 +0900"}
    }, {
      "_index" : "embulk_yudoufulog_rss",
      "_type" : "embulk",
      "_id" : "AU3XWfGno1wqzcGPiVrk",
      "_score" : 0.081366636,
      "_source":{"title":"AWS Summit 2015 - Day2 - AWS セキュアデザイン(IAM) Deep Dive","link":"http://yudoufu.hatenablog.jp/entry/2015/06/03/223637","pubDate":"Wed, 03 Jun 2015 22:36:37 +0900"}
    }, {
      "_index" : "embulk_yudoufulog_rss",
      "_type" : "embulk",
      "_id" : "AU3XWfGno1wqzcGPiVrj",
      "_score" : 0.057534903,
      "_source":{"title":"AWS Summit 2015 - Day2 - クラウドを活用したIoT/M2Mソリューション","link":"http://yudoufu.hatenablog.jp/entry/2015/06/03/223701","pubDate":"Wed, 03 Jun 2015 22:37:01 +0900"}
    }, {
      "_index" : "embulk_yudoufulog_rss",
      "_type" : "embulk",
      "_id" : "AU3XWfGno1wqzcGPiVri",
      "_score" : 0.057534903,
      "_source":{"title":"AWS Summit 2015 - Day2 - 新サービス解説セッション EFS と ML","link":"http://yudoufu.hatenablog.jp/entry/2015/06/03/223904","pubDate":"Wed, 03 Jun 2015 22:39:04 +0900"}
    } ]
  }
}

最終的なconfig.yml

備忘録としてまとめておく

in:
  type: http
  url: http://yudoufu.hatenablog.jp/rss
  params: ~
  parser:
    type: xml
    root: rss/channel/item
    schema:
      - { name: title, type: string }
      - { name: link, type: string }
      - { name: pubDate, type: string }
  method: get
out:
  type: elasticsearch
  cluster_name: elasticsearch_yudoufu
  nodes:
    - { host: 127.0.0.1, port: 9300 }
  index: embulk_yudoufulog_rss
  index_type: embulk

Norikra meetup #2 に参加してきた

  • https://atnd.org/events/65969

  • Norikraをつかいたいなーという気持ちを主張するためにとりあえずmeetupに参加してきた。

    • 画面黄色かった
    • だいたいみんな監視系で使ってた
    • だいたいみんなSPOFで困ってた
    • やっぱ便利そう
    • 使いたい
  • AWS Summitからのはしごだったのでさすがに疲れた。。。

メルカリでのNorikraの活用、Mackerelを添えて

  • kazeburoさん
  • Mercari

  • いかに早くスムーズにサイクルを回すか

  • Zabb....?

    • いいことはいっぱい
    • 煩雑だしめんどくさい
  • DevとOpsで情報を共有

  • MetricsをDevと共有
  • これを何とかするのに、fluentd経由でkibana / bigquery / tdなどでやっている

  • 何かあった時にすぐ知りたい

  • Norikra + mackerel

  • mackerel

    • はてな提供のサーバ管理ツール
    • Serverにagentを入れると、それをMackerelに送る
    • 直接クライアントを叩くことも可能
  • Norikra にSQLを投入するとmackerelにグラフを作られるようにしてみた

    • そこにalert用の閾値設定
  • メルカリでのNorikra構成

    • 各サーバからfluentd中継サーバへ、そこからnorikra
    • access_logとerror_logが対象
    • 全件処理してる
    • jolokiaを有効にしてKuradoでJVMのmonitoring
  • Norikraが落ちる問題

    • GCの途中で落ちてるっぽい
    • 正直分からない

設定とクエリ

  • Basic count()

    • Norikraで取ってきて、mackerelに投げてる
    • mackerelのいいところ
      • グラフの特定の値の表示を消すことができる
      • わずかしか出ない数値だけを表示したいときに楽
    • 特定のUAからのアクセスが「ある」場合をグラフ化
      • 閾値以下になった場合には、アラート発砲
  • percentile

    • アクセスのレスポンスタイムのパーセンタイルを取りたい
    • 全件やるとクエリが重そうだったので、1分間の最初の五万件だけを対象に絞った
    • percentilesのプラグインが返してくるのがオブジェクトの形になってしまうので、これをフラットにするためにもう一つplugin
    • レスポンスタイムの監視は、ほとんどの速いレスポンスに引きづられるので平均は意味が無い
    • なので、パーセンタイルや中央値などを使って監視するのが正しい
  • Q: kibanaと比べてどう?

    • データを一杯入れると重いし、グラフを多人数で見るのが重たい
    • リアルタイムにエラーログを見たい、とかはkibana使ってる
  • Q: メモリとかGCオプション

    • memory 64Gのマシンで、max 40Gで使ってる
    • メモリが少ないと圧縮、とかのオプションは外してる
    • フルGCで泊まる時間はNorikraでは問題ないので、そんなに気にしてない
  • Q: クエリのタイムウィンドウはどれくらいで運用してる?

    • 1分ぐらい
    • 特別重くかかるものの時だけは5分ぐらい
  • Q: 冗長化はしてる?

    • してない

Norikra to realtime log analytics

  • harukasan

  • 昔はsshでログ取ってくるとかhogehoge

  • 今はfluentd
    • そのままTDやHDFSやElasticsearchとか
  • さらにそれをCloudforecastとか、kibanaとかtableauとか

  • fluentdがあるおかげで、ここを通せばだいたいどうとでもなる

  • でも、そこから先の解析はまだよしなにやってくれるわけじゃない

解析の方式

  • Batch processing
    • daily / monthly...
    • PVとか
  • Ad-hoc analysis
    • Kibata & Elasticsearch
    • BI Tool: Tablau
  • Offline Analysis

  • Batch processは重すぎる

    • 5分毎の・・・1分ごとの。。。というのを知りたいときには困る
    • エラー時の情報をすぐに通知して欲しい
  • こういうのに向いてる方式

  • Stream Processing

    • データはずっと流れていて、そこにtime windowを切る
    • そのデータに対して処理をする
    • Norikra
  • Norikra

    • schema less
    • SQL like query
  • fluentdから送る

    • fluent-plugin-norikra
      • target_map_tag にしておくと便利
  • じゃあその結果を他に流すか?

    • fluentd -> Norikra -> fluentd
    • sweep でタグを使って投げる

Norikra Deployment

  • Norikra / GrowthforecastあたりはSPOFで困ってる

  • Hardware

    • Norikraにはメモリいっぱい(8GB以上
  • JVM 1.7

  • jruby でbuild
  • daemonize はsupervisord

  • Q: Norikra自身の監視は?

    • 特にしてない
  • Q: どのくらいの数のクエリ入れてますか?

    • 5~6こ
    • そんなに多くはならない
  • Q: time windowどのくらいにしてる?

    • 1分にしてる
    • でかくするとすごいメモリを食う

NorikraでWebサービスを守る

  • fujiwaraさん
  • HTTP status code / response timeを書いたり
  • fluentd-plugin-(datacounter|numeric-monitor)を置き換えた

  • r3.xlarge ( 4core 30GBのメモリ )

    • メモリは10Gから多い時で20Gいくかどうか
  • クエリ数はちょっと多い

    • VirtualHost毎にカウントしてる
    • なんだかんだ40クエリぐらいかけている
  • スパマーが来た

    • Web版を出したら、APIとかが見えるので、POSTをしてきたりされた
  • APIにPOSTメソッドにモリモリ送ってきものをクエリで抽出
  • twitter経由でのログインも抽出
  • さらに10分に何回、1時間に何回、という閾値も設定
  • これで引っかかったものをfluentdの自作プラグインでフックして、memcachedに投げ込んでspam-reportが発行される

  • まとめ

    • 簡単にクエリをカスタマイズできて、自作plugin書くと色々できる

Gunosy AdのNorikra事例

  • ユースケース

    • Adでターゲティング広告みたいなことしてる
    • ユーザーの好みと外れてるものはできるだけ早く外したい
    • イケてる広告画像をできるだけ早く洗い出したい
  • 環境

    • AWS
    • アドサーバはGolangにリプレース
  • c4.large 1台あたり

    • 1000req/sec
    • 2000~2500log/sec
  • 元々はRedshift+独自の集計

    • だるい
  • ログ量多くてkibana4に生ログ突っ込むと死ぬ

    • Speak streaming 使ってもしょうがない
  • そこでNorikra

  • 最終段のところでKibana4につっこむ

  • OpsWorksでポチポチサーバ構築して多段構成を何とかしてる

    • クエリ情報は全部custom jsonにくくりだしてる
  • 監視

  • datadogはdashbordにiframe埋め込めて便利

Norikra Recent update

  • (スライド見つからなかった)

  • tagomorisさん

  • 1年間で約17リリース

  • Suspend Queries

    • なんかの理由でちょっと止めたい
    • 登録はするけど一時的に止める、ということが可能に
    • suspendしたクエリはstats fileに吐き出されないので注意
  • Nullable fields

    • 同じようなデータなんだけど複数の場所から送られてくる
    • 新しいパラメータには存在するけど、古い方にはない。。。けど集計にはどっちも含めたい!という場合
    • NULLABLE()で囲むと、 項目がnullのイベントも抽出される
  • Listener

    • クエリのグループを指定するできる
      • LOOPBACK(target)
      • STDOUT() -> 結果が出たら、メモリプールに行かずにNorikraのログに吐かれる
  • Listener plugin

    • Listernerを自分で作れる
    • これでfluentd-pluginがなくても色々できる!
    • sync listener vs async listener
  • Dynamic plugin reloading

    • SIGHUPで読み込まれるようになった
    • restartなしでよくなった
  • その他にも色々

AWS Summit 2015 - Day2 行ってきたまとめ

昨日に引き続き、AWS Summit 2015のDay2に行ってきた。 昨日のまとめはこちら

yudoufu.hatenablog.jp

今日のリンクまとめ

全体を通しての感想

良かった

  • とにかくイベントの熱量と熱狂感がすごい

    • スーツもギークも関係なしに、まぁとにかくあらゆる分野の人がいる感じだし、誰もがAWSに期待している感じが凄くて圧倒される感じだった。
    • というか、もうクラウドは完全にコモディティ化してて、だれもAWSの実力に疑問を持たなくなったんだろうなぁ。
  • Lambda押しがすごい

    • たしかに、イベント駆動でサービスが起動するスタイルは今までなかったもので、かなり面白い
    • あっという間にあっちこっちのサービスとの連携機能が出来上がっていて、パワーを感じた
  • Auroraのバックエンドが知れて、すごく使いたくなった

    • まさにクラウド時代のDBという感じ。クラウド事業者だからこそ作れたDBだと思う。
    • 性能それ自体が上がるというわけじゃないけど、かなり内部的な効率が良さそうで信頼性も高くなりそうなので、きっとコストメリットも多くなってくるのでは。
    • 早く本番で使いたいなー
  • Machine Learningがすごく手軽そう

    • 機械学習系は理屈わかってないとなかなか手がでないけど、教師あり学習についてはもうこれでパッと入っていっちゃえそうな感じさえあっていい。
    • とはいえ、どうしても機械学習の一番面倒なところというか、前処理の部分は自分でCSVしてねって話なので、そこは頑張らないといけないね。
  • おべんとうおいしい

    • 無料イベントなのに。。。!まいせんのお弁当。。。!なんかすいませんありがとうございますおいしいです!><

改善されるといいな

  • Deep Dive / Dev系セッションの満席感やばい

    • 予約とか関係ないレベル。人が来過ぎで毎回溢れまくってた。
    • 次からはそもそも部屋を変えたほうが良さそう。
  • 濃厚なセッション多すぎてブース回れない。

    • や、悪いことじゃないんですが。
    • スポンサーさん的にはトークに持ってかれすぎてブースつらい、とかなかったのかな?と思った程度の話。
  • ケータイパシャパシャが本当にひどい。

    • 人の視界遮ってカメラ構えたり、スライドの全アクションをパシャパシャし続けてた人があちこちで発生してて辛かった。
    • あなた絶対twitterで問題視されてた流れもみてるよね?と思いつつ、もはや人の良心だけに期待するのは無理なことなのかなと感じた。

AWS Summit 2015 - Day2 - 新サービス解説セッション EFS と ML

EFS

  • AWS 辻さん

  • ストレージのポートフォリオ

    • S3
    • EBS
    • Glacier
    • EFS <- new!
  • NFSでファイルアクセスできるストレージ

    • NASのようなサービス
    • NFSv4を利用
    • EFSはファイル単位アクセス
      • EBSはブロックアクセス
  • EFSにはマウントターゲットを通じてアクセス

  • 幅ひろいユースケースで利用できる

EFSの特徴

  1. シンプル
    • フルマネージド型
    • NFSなので既存のツールを使える
    • 保存容量だけが課金対象
  2. 柔軟・スケーラブル
    • 容量は自動拡張・縮小
    • 性能は容量に応じてスケール
      • クレジット制もある
    • 数千のNFS同時接続をサポート
  3. 高い耐久性と可用性
    • 複数のAZに複製保存
    • 同時に読み書き可能

利用イメージ

  • 画面デモ
    • ポチポチやっていくだけで設定可能
  • Linux側からはmountコマンドでnfs4を指定するだけ

Deep Dive

  • パフォーマンス

    • 容量に比例してスループットが確保される
    • 1TBでは50MB/s -> 2TBでは100MB/s
    • バーストもある
      • 1TB未満の場合でも100MB/sにバーストできる(時間が短くなる)
  • 料金

    • $0.30/GB・月
    • 利用したストレージ容量のみの価格
  • セキュリティ

  • その他

    • プロトコル: NFSv4.0 (TCP 2049 port)
    • 推奨クライアント: Linux NFSv4クライアント
      • ロック・Share Deny・ACL・Kerberosなどは未サポート
    • 同一VPCからのみアクセス可能
  • EBS vs EFS vs S3

    • EBS / EFSは既存アプリと親和性が高い
    • S3は使う場合にはAPI対応が必要
  • CDP: NFS Sharingパターンが変わる

    • NFSだからこその注意点だった部分が楽になる
  • 提供スケジュール

    • Limited Previewで提供
    • 年内にはUS-East / EU

Amazon Machine Learning

AWS Summit 2015 - Day2 - クラウドを活用したIoT/M2Mソリューション

  • AWS 榎並さん

IoT/M2Mとは

  • Internet of things
  • machine to machine communications
  • このセッションの中では同じような扱いで話す

  • IoT市場の規模

  • 様々なマーケットで利用可能

  • Amazonでも色々

    • Drone
    • echo
    • dash
  • イベント会場の騒音チェックをしてみた

    • 騒音センサーからデータを送る

なぜAWSでIoT/M2M

  • 低コストに始めたい
  • いざ始めてスケールしなきゃいけない、ということになった場合にそれができる
  • グローバルにいろんなリージョンがある
  • 好きにつなぎあわせて課題を解決できる

メリットの有るシステム

  • デバイスインターフェース

  • 収集

    • S3 / Kinesis / DynamoDB
    • ファイル・ストリーム・トランザクションのそれぞれのタイプに対応
    • S3をデータの集積ポイントに
    • Kinesis自体は、一旦データを保存し、最小限のかたちで構成する
      • その上で、各クライアントライブラリを使って処理するアプリを用意する
      • 最近、max 1MBのデータまであげられるようになった
  • 処理
    • Lambda/KCL Apps
    • Lambdaはイベント処理のためのコンピュートサービス
  • 分析
    • Redshift
      • データウェアハウスサービス / Postgres互換
    • 最大2PBのデータ容量まで拡張
    • EMR
      • Hadoopホスティング
      • Bootstrap Action
        • EMR構築時にインストールできる
        • spark / prestoなどなど
      • 他のストレージに対して処理することもできる
        • Amazon Kinesis インテグレーション
        • Hiveのクエリなども書ける
        • S3インテグレーション
        • S3でデータを永続化し、必要なときに処理する

データ処理パターン

  • 分析方法策定の流れ

    • 目標定義
    • KPI策定
    • 施策策定
    • 実装
    • テスト
  • ダベンポートによる分析の分類

  • 適材適所でサービスを利用

  • Sparkについて

    • 大規模データをオンメモリで処理する分散処理基盤
    • RDDを用いた反復処理
    • SQL / Stream / 機械学習など複雑な利用用途も可能
  • Amazon Kinesis インテグレーションでSpark利用可能

まとめ

  • AWSのメリットを生かす
  • データ処理は重要な機能
    • データ特性とクエリ特性を考慮して設計する

AWS Summit 2015 - Day2 - AWS セキュアデザイン(IAM) Deep Dive

  • AWS 瀧澤さん

AWSのセキュリティ

  • AWSのセキュリティ方針

    • 最優先されるべき事項
    • 専門部隊を作り、継続的な投資
  • 責任共有モデル

    • AWSと利用者の2者で確保
    • AWSクラウド基盤部分をAWSが担当
    • その上につくるシステム・コンテンツ・ネットワーク設定を顧客が担当
  • 主要な規制・標準・ベストプラクティスに準拠

  • 第三者の監査機関によるチェック

  • 監査のやり方を変えて欲しい、というのがAWSからのお願い

    • 仮想化されてデータの物理的な場所、という考えがなくなっている
  • 金融機関向けにFISCへのAWS準拠状況を調査した資料を公開している

  • ホワイトペーパーでAWSの統制を確認可能

  • AWSを活用する際の監査のポイント

    • OS以上の部分は既存と同様に対応
    • データの所有権・統制権は顧客側にある
      • 重要なデータに対する暗号化と鍵管理
  • AWSのセキュリティツール・機能の提供

    • ネットワークセキュリティ
      • Security Group etc...
      • S3のVPCエンドポイント
    • サーバ(OS)セキュリティ
    • データセキュリティ
      • データの分類(機密度・漏洩した時の損害額)
      • 暗号化
      • 暗号鍵の管理
      • データの削除
      • データの暗号ソリューション
        • Cloud HSM
        • Key Management Service
        • 暗号済みの管理
        • AWS内で鍵を管理
      • KMSのセキュリティ
      • Nasdaqの例
        • オンプレミスにHSMを構築し、鍵を管理
        • S3城のデータを暗号化
        • EMR利用時のみ復号化
        • 万が一AWSから流出があったとしても、暗号化されたデータしかない
    • アクセスコントロール
      • 誰が、いつ、何のために、何を、という観点でアクセス制御
      • MFAデバイス
      • AD連携も可能

IAM

  • マネジメントコンソール
  • コマンドライン
  • SDK
  • 他のAWSサービスから

  • IAMをサポートするサービス

    • AWS Support API以外のアクションレベルの権限をサポート
    • リソースレベルの権限、タグベースのアクセス権限もサポート
    • 一時的なセキュリティ認証のサポート

IAM top10ベストプラクティス

  1. AWSアカウントのアクセスキーロック
    • マスターのアカウントのアクセスキーは削除
    • 流出時のリスクが大きい
  2. 個々にIAMユーザを作成
  3. 特権ユーザにはMFA
    • ルートアカウントはMFAで保護し、通常利用しない
    • ハードウェアのMFAを使う場合は2つ以上用意しておくと安全
  4. 個別のIAMユーザーを作成し、IAMグループで管理
    • 権限はグループに付与して管理する
  5. 強度の高いパスワード
    • パスワードポリシーの設定
  6. 最小限の特権
  7. ポリシー条件を使いこなす

大きな組織でマネジメントコンソールのアカウント管理を効率化するには?

  • Active Directory連携

    • IAMのSAML連携、ADFSの使用
    • ADのグループとIAMロールを対応付け
    • ADFSログインページはプライベート側に作ることができる
  • 要求規則の編集

    • 特定のプレフィックスを決めたりして、対応するRole同士でマッピングする
  • EC2上にAD/ADFSを建ててもいい

  • AD連携のいいところ

    • アカウント管理が統合され、リスクが低減する
    • 人のでいりなどが一元管理が可能

EC2にはIAMロールを利用

  • EC2内でクレデンシャルを取得するのに便利
  • IAMユーザーがリソースを作成・変更する権限を付与

新機能

  • IAM Policy Validator
    • 保存前にポリシーの検証
  • IAM Policy Simulator
    • Run Simulateすると、対象の操作が可能かどうかをチェックできる

監査

  • 何を見るべきか

    • IAM認証情報レポート
    • アクセスキーのローテーション
    • AWS CloudTrail
    • AWS Config
    • CloudWatch, Logs
    • 各サービスのログ
    • OS, アプリケーションログ
  • IAM 認証情報レポート

    • 認証情報ライフサイクルの要件結果を確認可能
    • データの重要度などに合わせて
  • パスワードのローテーション
  • 認証情報のローテーション
  • アクセスキーのローテーション

    • キーをもう一つ作って、各アプリケーションで切り替え
    • 終わって、Last Usedを確認しながらInactive / 削除
  • AWS環境の操作ログの取得

    • CloudTrailの有効化
  • AWS Trusted Advisorによる確認

    • AWS Supportを契約している場合

まとめ

  • 最もセキュリティに厳しい組織向けに構築された環境を利用可能
  • AWS上では1800以上のコントロールを管理
  • お客様でデータと権限のコントロールを