絶品ゆどうふのタレ

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

AWS Summit 2015 - Day2 - keynote

  • 昨日と同じ話は省略

AWS Mobile Service

  • Mobile SDK

    • Mobileの中から直接AWSにアクセスすることが出来る
    • モバイルの中で使いやすい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

  • 基板となるインフラ運用にはまだ課題があった

  • 一元化したサービスの運用

  • キーワードはマネージドサービス

  • DynamoDBのリリース

  • Dynamoはモバイル・IoTにも効果的

  • DynamoDB Stream

    • DBの更新情報を外部アプリケーションから利用可能
    • Device -> Dynamo -> Stream -> lambda -> Redshift/SNS/Machine Learningなどの連携

Community HERO 横田さん

  • スシローとガリバーの事例

  • スシロー

    • 店舗データをKinesis + Redshift
    • これをAmazon Machine Learningにかける試み
  • ガリバー

    • モバイル業務アプリ
    • Cognite ベースで認証
    • モバイルからLabmda -> Dynamo -> Labmda -> SNSで通知
  • ほとんどEC2を使っていない

  • 最初にAWSを使おうと決意すると、まずオンプレからEC2に移そうとかんがえる
  • 次のステップで出てくるのがこれらのクラウドネイティブなサービス
    • マネージドサービスを組み合わせることで、運用・構築をもっと楽に

Gene

  • モバイルのもう一つのアプローチ
  • エンタープライズモビリティ
    • WorkSpaces
    • WorkDocs
    • WorkMail
  • すべてがモバイルデバイス対応

  • Amazon WorkDocsの日本語UI・東京リージョン

Wrap up

  • 10月にAWS re:Invent

AWS Summit 2015 - Day2 - 今日から始められる、機械学習!Amazon Machine Learningのご紹介

  • AWS 今井さん

機械学習の例

  • スパムメール判定

    • 二値判定、二項分類
    • 教師データ
    • 別の方法でSpam判定ずみのデータを元に学習
    • それを元に判定
  • 商品カテゴリの判定

    • マルチクラス分類
    • この商品はどのカテゴリのものか?
  • 明日の売上の予測

    • 回帰分析
    • 過去のデータ群を教師データとする
    • それを元にモデルの線を引き、明日の条件に最も合う条件で予測する
  • スマートのアプリケーションを作るには

    • 機械学習に強くて
    • R / Python場合によってはHadoop / Sparkに明るい
    • 特定分野のビジネス経験が必要
  • これは大変

  • なので、Amazon Machine Learning

Amazon Machine Learning

  • Amazonアルゴリズムを提供
  • パッケージサービスとして提供
    • ワークフローが予め提供されている
    • MLは教師あり学習に対応している
  • スケーラビリティ

  • 取り扱えるモデルとアルゴリズム

    • 二項分類
      • ロジスティック回帰
    • 多クラス分類
    • 回帰分析
      • 線形回帰
  • 予測手法

    • バッチ予測
      • S3にあるデータをまとめて予測を実施
    • リアルタイム予測
      • データを一件ずつAPIを使って投げて予測

AMLの使い方

  • 教師用・評価用データを準備
    • S3 / Redshift / RDS for MySQLをデータソースとして利用可能
    • CSV形式のデータ
  • 教師データからモデルを作成
  • モデルの品質評価
    • 評価用のデータを流してテスト
    • 7割の教師データを使って学習、3割を使って品質評価をする(自動で分けてくれる)
    • Scoreの許容度をどこにするかをグラフィカルに設定できる!
    • 制度に満足できない場合は、教師データを精査して繰り返す
  • 実際の予測に使う

料金

  • 分析、トレーニング、評価
  • バッチ予測
    • $0.10/1000
  • リアルタイム予測

    • $0.10/1000
    • +モデル10MBあたり$0.001/h
  • リージョンはus-east-1のみ

    • どのS3リージョ運のデータでも大丈夫

利用例

  • 広告の不正クリック検出

    • 教師データ: 実際のクリックログ
    • 問題の分類: 二項分類
    • 出力: ログごとに不正かどうかチェック
  • 広告のリダイレクタの中でAPIを叩けば、その場で不正かどうかの判定が可能

  • デモグラ推定

    • 教師データ: でもグラがわかっているユーザーの行動ログ
    • 問題の分類: 多クラス分類
    • 出力: ユーザーを行動ログからデモグラ判定
  • デモグラに基づいたレコメンデーション

    • 教師データ:購入履歴にデモグラをマッピングされたもの
    • 問題の分類: 多クラス分類
    • 出力: ユーザーのデモグラを入力し、F1なので商品カテゴリこれがいい、みたいな出力
  • 写真からの判定

    • この後デモ

アーキテクチャへの組み込み

  • S3からデータを出し、MLにかけてまたS3へ
  • Redshiftをデータソースとして扱い、S3へ
  • リアルタイム予測
  • DynamoDB StreamsやLambdaを使って MLにかける

AML説明まとめ

  • 機械学習の導入が用意になり、すぐにでもデータ分析が始められる

AMLデモ

  • 榎並さん

  • 顔写真から特定の人物判定

    • 顔写真をグレースケールにしたビットマップ
      • 各ピクセルの明度を数値化して、大きな配列にする
    • 二項分類
  • 構成

    • OpenCVで顔部分を検出
    • 写真をグレースケールに
  • トレーニングデータについて

    • 前処理の部分は自分で用意する必要はある

流れ

  • トレーニングデータCSVをS3にアップロード
  • AMLのコンソールからCSVを指定
    • CSVの最後の部分が二項分類の値だよね(binaryだよね)というのを予測してくれる
  • 自動で学習と品質評価をしてくれる
    • アップロードデータの3割を自動で評価データにしてくれる
  • 出た結果を元に、許容度を設定
  • ML real time の設定をすると、リアルタイム予測ができるようになる

  • APIで正しい写真を渡すと、正解フラグとスコアが帰ってくる

    • 間違った写真でも同様

まとめ

  • 機械学習のプロフェッショナル用のサービス、という趣よりも、詳しくないデベロッパーでもすぐ始められるサービス

AWS Summit 2015 - Day2 - ネットワークDeep Dive

  • AWS 吉田さん

VPCベストプラクティス

Marketplaceを活用する

  • ファイアウォールやロードバランサ、WAF、ルータ、ネットワーク高速化などの製品が利用可能
  • EC2のMarketplaceから検索

VPC Peeringを利用する

  • 2つのVPCの間でネットワークをpeeringする
    • 企業間コラボレーション
      • お互いの会社がAWSをつかっていれば、簡単にネットワーク接続が可能
      • セキュリティグループで必要な通信だけに絞ることもできる
      • 新しいEDI
    • セキュリティ昨日の共有例
      • Proxy / WAFをセキュリティチームが共有サービスとしてメンテ
      • アプリケーションチームのVPCは直接インターネットにアクセスできず、VPC Peeringでセキュリティチームレイヤにつないでアクセス

VPCのルーティングとセキュリティ

  • VPCのルーティングはすべてサブネット単位のルートテーブルに基づく
  • IPレベルでの接続性確保が目的

  • 主なルーティングのエントリ

    • VPC内のCIDR: local
    • default route: 0.0.0.0 NAT
    • オンプレへのトラフィックはVGW: 192.168.0.0/16とか
    • 通信したいVPCのネットワークアドレスへのルーティングは Peering Connectionへルーティング
  • ACLとセキュリティグループ

    • ACL: ブラックリスト
      • ステートレスなので、戻りも明示する
      • ネットワーク構築時に不要な通信を禁止
    • セキュリティグループ: ホワイトリスト
      • ステートフルなので、戻りを考慮する必要はない
      • 運用時に必要な通信を許可
  • ベストプラクティス例

    1. ルーティングですべての到達性を確保
    2. 全体ポリシーで不必要な通信をACLで構築時に禁止
    3. 個別に必要な通信をセキュリティグループで許可

VPCエンドポイント

  • S3へのアクセスは、以前はNATインスタンスなどを通す必要があった

    • シングルポイントだった
    • それを解決
  • private subnetに設定することで、中から直接外にアクセスできるようになる

  • エンドポイントポリシー

    • VPCエンドポイントに直接IAMポリシーを設定可能
  • 既存からの移行

    • 既存のNAT構成の中にVPC endpointのルーティングを追加すれば、ロンゲストマッチに依ってVPC endpointが優先される
  • 注意点

    • リージョンをまたいで通信することはできない
    • VPN / AWS DirectConnect / VPC PeeringなどからVPC endpointは使えない

Direct connect ベストプラクティス

  • BGPの動作
    • ルートにBGP除く聖地は付与しない
    • お客様ルータのBGP俗世地を評価
    • ロードシェアリング可能
      • マルチパス有効
    • プライベート接続ではVPCのプレフィックスを広告
    • パブリックだとAWSクラウド内のプレフィックスを広告
    • BFDが有効

回線フェイルオーバーの高速化

  • BGPでは、障害検知が遅くてフェイルオーバーが遅いことが問題になりやすい

  • BFD

    • ミリ秒レベルで対向ルーター同士でBFDパケットを送受信
    • なくなった場合に障害検知
    • 非常に高速なフェイルオーバー
    • リアルタイム性の高いアプリケーションの場合は設定を
    • 推奨
  • KeepaliveとHoldtime

    • BGPの機能の一部
    • keepaliveを指定した間隔で送受信
    • 単純にこのHoldtimeのデフォルト値を短くする
      • 自分のるーたの設定値を低い値にすれば、AWS側のるーたもその低い方を採用する仕組み

経路の冗長化

  • Active/Standby

    • 片方だけVPNという接続をしてる人もいる
    • BGPの属性値によってどのPathを選択するかを設定
    • のぼりとくだりは違う属性値で管理されている
      • AS Path Prepend
      • オンプレからの送信はLocal Pre...を優先
  • 注意点

    • どちらの回線がActiveなのかをきちんと管理
    • 上りと下りのトラフィックを意識
  • Active/Active

    • マルチパスによって、複数経路に対してロードバランスして送信する
    • Maxmmum Path
    • AWSのルータではマルチパスが有効になっている
  • 注意点

    • 回線の切断時、正常な回線のトラフィック・帯域溢れに注意
      • マルチパスのペアをもう一つ用意したり
      • Active/Standbyにしたり

占有型と共有型

  • DirectConnectの構成

    • 物理線(Connection)の中にVLAN(Virtual interface)を構成してる
  • 占有型と共有型

    • 占有型: Connection単位
    • 共有型: Virtual Interface
      • 1契約につき1接続
      • たくさんVPC接続する場合は、その数分だけ契約する
    • どれくらい必要になるのかをよく見て、契約を判断
  • キャリア閉域網の共有型の例

ネットワークのコード化

  • ネットワークにフォーカスしたコード化

  • CloudFormation

    • JSONテンプレートを用意して構築
    • updateも可能
  • AWS CLI / SDK

CloudFormationの例

  • VPC / Subnetの構成例
  • サンプルテンプレートを元に使ったり、サードパーティツールで便利に書ける

  • JSONを編集 -> CloudFormationでロード

  • CloudFormerを利用したテンプレート作成

    • 既存の構成を元にテンプレート作成

AWS CLI / SDK

  • シェルのコマンドを使う

  • VPC作成の例

  • PythonSDKなども可能

  • タグに寄る動的NAT制御の例

    • NATインスタンス起動時に自分自身の情報を元に判定してルートテーブルを更新する

さいごに

AWS Summit 2015 - Day2 - AWS System Operation Deep Dive

  • AWS 酒徳さん

  • AWS上での運用をどうやって行くべきか

システム運用で考えるポイント

  • クラウドだからといって考える事の基本は同じ
  • Monitoring
    • 死活監視
    • キャパシティ監視
  • Logging
    • 誰が、いつ、どのような変更をしたのか
  • Configuration
    • 構成管理
    • Chef / Puppetとかの個別の構成ではなく、システム全体の構成の話

Monitoring

  • CloudWatch

    • AWSのリソース監視
    • 死活・性能・ログ監視
    • メンテナンスイベント
    • 他にも、課金状況の監視など
  • 何がオンプレと違うか?

    • モニタリングのマネージドサービス
      • 可用性を考える必要がない
    • データの持ち方
      • データポイントとしてデータを丸ごとごそっと持っている
        • 個々のメトリクス情報として持っているわけではない
      • いろんな切り口でモニタリングデキる
        • Metrics / Namespace / Dimension などという組み合わせによって絞り込んでみていく
      • これらを統計値として見る
        • sum / max/ min など
  • CLIから情報を引っこ抜いてきて情報を持ってくることができる

CloudWatchと監視ツールの線引と連携

  • 責任共有モデルの範囲か否か、で分けたりするのがひとつの手

    • カスタムメトリクスを使えば、CloudWatchだけで監視することもできる
  • 定期メンテナンスの時にアラートを出したくない、とか

  • オンプレミスの環境と組み合わせながら、やっていったりするのが効率が良い

  • Mackerel / DatadogなどでSaaSで監視してしまうのも手

  • Sensuを使ったモニタリング

    • RappidMQを使ってスケール
    • SSLを使った通信でセキュアに
  • CloudWatch Log

    • エージェントがLogをendpointに送る
    • 1回あたりのpushは32KB まで
      • それを超えるとログがトランケートされる
      • そのメッセージしか残らない
      • ログのカット等をアプリ側で実装する必要がある
    • 対応しているローテーション
      • rename and re-create
      • copy and truncate
      • ceate common-patterned file
        • poort毎に異なるファイルに書き込まれるようなパターンのログは追えない
    • ログの転送設定
      • file_fingerprint_lines
        • デフォルトでは1
        • 1行目は必ず同じになる!という場合には上手く動かないので、この辺を変える必要がある

Logging

  • CloudTrail

    • APIの発行とAWSリソースの呼び出しをCloudTrailでJSONのログとして保存
  • 利用ケース

    • 検知
      • 何かあったらすぐ知りたい
    • 検索
      • かつて何があったか調査したい
    • 可視化
      • トレンド
  • CloudWatch Logs Metrics Filterの利用

    • CloudTrailのログをCloudWatch Logsにどんどん投げ込む
    • CloudFormationのテンプレートが公開されている
  • CloudTrail API Activity Lookup

    • 直近7日間のログが閲覧できる
    • ただし、CloudTrailのサポートするサービスをすべて見れる、というわけではない。注意
  • CloudSearch, Lambdaとの連携

    • S3にup されたCloudTrailのログをLambdaが検知してCloudSearchに流す
  • ElasticSearch, Kibana, Lambdaの連携

    • S3に入ったのをLabmdaが検知し、それをElasticsearchに流し込んでKibanaで表示
  • splunkでもとかでも可視化可能

  • 短期、中期、長期の目的に依って使い分ける

Configuration

  • AWS Config

    • 構成変更を記録して、変更の記録
      • ヒストリとして残す
      • 今の状態をスナップショットとしてのこす
  • リレーションシップ

    • relationship
      • 今の変更点が、どんなものに影響を及ぼすかをJSONに記録される
      • EBSが3つから4つになった場合の差分が記録されたり
    • セキュリティグループの変更の影響が、どれくらいのインスタンスに影響するかを見ることができる
  • Logstorage

まとめ

  • もちろん、今回のもので全てできるわけではない
  • サードパーティー製のツールも使いつつ、上手く組み合わせて運用していく

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以上のコントロールを管理
  • お客様でデータと権限のコントロールを

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 - 新サービス解説セッション 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 行ってきたまとめ

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

yudoufu.hatenablog.jp

今日のリンクまとめ

全体を通しての感想

良かった

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

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

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

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

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

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

改善されるといいな

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

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

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

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

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なしでよくなった
  • その他にも色々