AWS Casual Talks#2 の参加報告 #awscasual

SHARE

こんにちは、髙橋@SSTDです。

先日開催されたAWS Casual Talks#2に参加しました。 今回は、「AWS新サービスあれこれ」というテーマで、Redshift/Kinesis/CloudTrail などのAWSの新サービスについて実際に使ってみてどうなの？ということを中心とした内容でした。

私自身もAWS EC2やS3などはよく利用しますが、AWSの提供するサービスの範囲が広すぎるため、AWSの全てのサービス内容の把握が大変です。 そのため、こうした機会に、自分が普段使わないサービスについて知ることができることは非常に嬉しいですね。

余談ですが、AWS Test Driveの日本語版が発表され覗いてみたところ、弊社のLifeKeeperが掲載されておりました。 ぜひLifeKeeper for AWS Test Driveをお試し下さいませ。

TT1

目次

目次

No. 発表者 タイトル
1 @kani_b CloudTrailでログとれーる
2 @suzu_v Data Stream Processing and Analysis on AWSFluentd, Elasticsearch, DynamoDB, EMR and Amazon Kinesis
3 @mineroaoki ふつうのRedshiftパフォーマンスチューニング
4 @ar1 AWS使用がもっと楽になるネットワーク系の新サービス at VPC,ELB,CloudFront,Route53
5 @yamakatu EC2 + Spot Instance + Spark + MLlib で実現する簡単低コスト高速機械学習
6 @hakobera 5分でできる ebfly
7 @tanaka_733 Logging and Data Analysis on .NET Framework with Redshift and DataPipeline
8 @mikeda AWSメインの会社に転職したので数少ないAWS経験の話もしくは個人検証してるCloudSearchの話。もしくはその両方

1. CloudTrailでログとれ～る

  • Hokuto Hoshi
  • COODPAC Inc.

HeartBleedとAWSの話

最近トレンドな話。 AWSをテーマにするとインフラよりの参加者が多いようで、苦労話にうなずいている方が多かったですね。

CloudTrail

  • AWSのログが欲しい
    • 前は、AWSサービスではログが残らなかった…
    • 監査の上でもAWSのログ記録も重要になる
    • CloudTrailが発表されてログが提供されるようになった
  • CluodTrailの特徴
    • AWSアカウント内のAPIコールのログを生成
    • ログはS3に出力
    • SNSに通知可能
    • 他アカウントに出力可能
    • ログ形式はJSON
    • アカウントID, IAMのユーザ名, 対象API名, 時間, etc.
  • 課題
    • パースを自前でする必要有
    • 対応策としてツールの利用
      • MongoDBやElasticsearchなどの利用
      • SumoLogic, Splunkなど
      • 上記の主な役割は、ログのパース、検索、サマライズがメイン
    • AWS全体のサービスに比べて、対応サービスが少ない
    • リージョン対応にアジアにない
      • リージョンが関係ないサービスには有効
      • IAM (Identity and Access Management)
        • IAMのPolicy追加などの操作ログが出力される
      • STS (Security Token Service)

AWS Game DayでCloudTrail利用した際の話

Game Dayとは、ある一日で、チームが敵味方に分かれ、一方は知恵を絞ってシステムを破壊し、もう一方は全力でそれを修復するというものです。

  • AWSを運用する上での、セキュリティの面で気にする点として
    • 運用時のIAM権限とS3バケットの扱いに注意する
    • IAMユーザからCloudTrail周りの権限を取り除く
    • ログの保持方法を固める
      • ログ集約のアカウントにまとめる

イベント当日の攻撃・修復内容のまとめは下記ブログにて覗ける。 AWS Game Day Japan 2014春を開催してきた

iwasを書いた話

IAMのログをパースして、変更履歴をGitで管理してくれるiwasを作った話。

2. Data Stream Processing and Analysis on AWS: Fluentd, Elasticsearch, DynamoDB, EMR and Amazon Kinesis

  • 株式会社ading
  • https://suzuken.hatenablog.jp/
  • https://suzuken.hatenablog.jp/entry/2014/04/21/060620

Amazon Kinesisとは

ストリーミングデータをリアルタイムに処理するサービス。 アーキテクチャについては下記スライドが詳細。

adingのシステム構成の変遷

  • 2012中頃
    • ELB -> EC2(php+apache) -> S3 -> EMR -> MongoDB(EC2) clusters -> EC2(php+apache) ELB
    • 良い点
      • MongoDBの柔軟性
      • データの受け入れが安定
    • 悪い点
      • 非リアルタイム
      • MongoDBのWriteによる負担が高い、集計処理が重い、MapReduceジョブを回す必要有
  • 2014 early
    • ELB -> EC2(fluentd) -> EC2(fluentd for aggregater) -> EMR(Hive) or Growth Forcast or Elasticsearch+Kibana -> DynamoDB -> EC2(servlet(scala))
    • 良い点
      • Es+Kibanaにより、リアルタイムにドリルダウン可能に
      • DynamoDBによりwrite/read共に安定
    • 悪い点
      • fluentdが便利すぎるために、aggregatorに役割を集中してしまっている
      • ストリーム処理をより柔軟に、多様に、疎結合に扱いたい
      • Esのメンテが大変に

Amazon Kinesisの検証

  • どういう場面で使うのか？
    • 広告ログを分析するための基盤
    • アドホックな分析&定常分析
    • 広告のターゲティングにも使う
  • 検証時のシステム要件
    • 複数サービスのログの常に取り込み
    • 過去ログと現在のログの分析の両立
    • ターゲティングはベストエフォート

Kinesis Applicationが必要となり、Streamingをどう処理させるのかのアプリケーションが必要。 現状は、US regionのみ対応。

log -stream-> Amazon Kinesis -shard(Partition Key)-> Kinesis Application -> DataStore

  • 検証結果
    • 1 shard 1000 put request/sec
      • 制限が色々あるので注意
    • Kinesis内に24時間データが残ってくれている
    • Kinesisへの書き込み失敗時のハンドリングを考慮する必要有
    • 1レコードずつでしか現状ではデータが入れられないので、fluentdのようにチャンクでデータを送信するロガーと相性が悪い

所感

Kinesis ApplicationからDynamoDBへの書き込みは楽、Scalingも問題ない。 Kinesisの東京リージョンにほしい、batchWriteが欲しい。

3. ふつうのRedshiftパフォーマンスチューニング

  • Cookpad Inc.
    • 元々はTeradataでコンサル

RedShiftの扱う際のデータの規模感

Redshiftは、並列RDBMS。 データ量の規模に応じて、Redshiftのチューニングが重要になる。 下表はデータ量に応じての対応の温度感を大まかに表している

行数 サイズ 雰囲気 設計時の態度
100億~ 1TB~ マジヤバイ 細心の注意
~100億 ~1TB 大きい 真面目にやれ
~10億 ~100GB 普通 考える
~1億 ~10GB 小さい 適当
~1千万 ~1GB ゴミ 無視

アーキテクチャ

Redshiftは、二つのノードに分かれている。

  • Leader Node: 接続、クエリの解析、実行計画の構築、およびCompute Nodeでのクエリ実行を管理
  • Compute Node: データを保存し、計算を行い、Leader Nodeによって指示されたクエリを実行

 

TT2

並列の単位は、Compute Node内のNode Sliceの数に相当する。

  • 一番小さいインスタンスでも2 Slicesあるので、2並列にはクエリが実行可能
  • 行は、分散キーのハッシュ値で決定する
  • 典型的なシステム
    • Server -> Hadoop -> Redshift -> BI, 直SQL, バッチ
    • Server -> Redshift -> BI, 直SQL, バッチ

Redshiftでの処理単位

10億件程度であれば、Redshiftは普通に扱える。 そのため、Redshiftで実施する処理を処理単位毎に分けて考える必要が有る。

処理単位 処理時間 雰囲気
オンライン (OLTP) マイクロ秒 通常のRDBで行うような更新処理
オンライン (OLAP/tactical) 0.1~X sec 小さな分析用のクエリ
オンライン (OLAP/strategic) X sec ~ X min 大きな分析用クエリ
バッチ X min ~ X hour バッチ処理
  • OLTP: オンライントランザクション処理(On-Line Transaction Processing)
    • 困難
      • リクエストの並列度が高い場合は無理
      • 秒間2桁以上のリクエストを保証する場合は無理
      • 高頻度、細粒度で更新は無理
        • 5分間隔の追加くらいが限界
        • ただし、小さいデータに対して細かいクエリ程度であれば可能
  • OLAP: オンライン分析処理(On-line Analytical Processing)
    • tactical
      • チューニング
        • 特定のキーをSort Keyとして割り当てる
          • Sort KeyとはRDBのindexみたいなもの
        • テーブルサイズを実測して、一番データサイズを小さくする
          • Redshiftでは、テーブルごとに圧縮方法を変更可能
        • 事前にジョインを行い、一つの大きいテーブルを作ることは、あまり効果がない (事前集計はOK)
          • データのIOが大きくなり、結果的に遅くなる可能性が高い
        • なるべく正規化する
    • Strategic, Batch
      • やってはいけないケース
      • 全行SELECTを行い、Redshiftの外で非同期処理を実施
      • 重要な設計方針として、並列RDBMSの場合は、データを移動したら負け
      • ネットワークI/Oが最もボトルネックになる

重要なリソース

Redshiftなどの並列DBを考える際に、どのリソースでボトルネックになっているかを考えるべき。 そのとき、ノード間を繋ぐネットワークI/Oが一番のボトルネックになっている あるインスタンスを利用したときの実測が下記の表。

リソース 速度(実測値) 倍率
cpu ? ?
memory 20gb/s 100x
disk 300mb/s 10x
network 30mb/s 1x

チューニング

チューニングをする際には、一番ボトルネックとなるネットワークでのデータ転送を減らすことが重要。 そのためには、データの再分散を避けることが重要である。 Redshiftの外とのデータ移動だけではなく、Redshiftの各ノード間でデータを移動するのも駄目。

  • JoinとGroupByを避ける
  • JoinキーがDistkeyならば再分散は起こらない
    • distkeyを指定したカラムは同じ値の場合に同じノードに保存されるようになり，そのカラムを含むテーブルをJOINで結合するSQLの高速化が期待できる
    • 例: ユーザIDが同じであれば、同じノードスライスに分類される、つまりjoinの相手が同一ノードに存在するということ。
  • 目印は、”DS_DIST_NONE”
    • 再分散されない目印
    • 巨大テーブルをjoinする際には、これが表示されていることをチェックする
  • このように分散キーが非常に重要。Hadoopには分散キーがない。

まとめ

  • 並列RDBはネットワークが最も貴重
  • ネットワークの負荷を減らすには分散キーが重要
  • データを移動させない
  • 質問
    • 分散キー候補が複数有る場合は、どういう風に選択すれば良いですか?
      • 分散キー候補が複数する場合、テーブルを新規に作成し、試行錯誤して良い分散キーを探す
      • ただし、100億件のテーブルを複数作るのは大変なので、どちらかに寄せるしかないかもしれない。

4. AWS使用がもっと楽になるネットワーク系の新サービス at VPC,ELB,CloudFront,Route53

  • Amazon Web Services

新サービス紹介

2014年にAWSに追加されたネットワーク系の新サービスについての紹介

  • ELB
    • Logging
      • ELBのアクセスログをS3に保存可能に。
      • 12 fields into 1 request / 1 line
    • Connection Draining
      • ロードバランさからインスタンスをはずす際に、設定したタイムアウトの間は処理中のリクエストがある場合、待ってくれる
      • デフォルトで5分間、新規追加時は有効
      • ECDHE and Server Order Preference(SOP)サポート
        • EDHでの鍵交換
  • CloudFront
    • SNI (Server Name Indication)
      • HTTPSをユーザが独自証明書なし利用可能に
      • ただしクライアント側の対応も必要
      • HTTP Redirectが可能
      • HTTP -> HTTPSにリダイレクト可能
    • EDNS-Client-Subnet
      • より正確にもっとも近いエッジロケーションが選択されるようになった
  • Route53
    • ヘルスチェック機能の拡充
      • かなりコストを削減できる
      • 各リージョンから独立したヘルスチェックを行える（10秒間隔が可能）
      • フェイルオーバ実行の閾値
        • 1~10の間で設定可能
      • HTTPSへの対応
      • レスポンス文字列の設定可能に
  • VPC
    • VPCピアリング（現在は同一リージョン）
      • VPC間接続には、Inviteが必要
      • VPCピアリングはアドレスの重複を許さない
      • [https://aws.typepad.com/sajp/2014/04/vpc-peering-tips.html]
      • ピアリングした同士でのIPアドレスの重複を許さないので、調整が必要

5. EC2 + Spot Instance + Spark + MLlib で実現する簡単低コスト高速機械学習

内容

Sparkを手軽に試す方法についての紹介

  • Hadoopの苦手な処理: 繰り返し処理(処理結果を更に自身にインポートする)
    • Disk I/O
    • タスク処理の準備にかかる時間
  • SparkでHadoopの欠点を補う
    • fast event-driven RPC library
  • 機械学習 on Spark -> 代表的な用途
    • 機械学習には繰り返し処理が激しいアルゴリズムがある
    • MLlib（機械学習ライブラリ）
      • SVMとか使える
  • Spark on EC2というスクリプトで簡単に起動ができる
  • Spark on EMRもある

6. 5分でできる ebfly

ちなみに、AWS Elastic Beanstalkは、Webアプリの実行環境を構築・管理するAWSの一サービスです。

7. Logging and Data Analysis on .NET Framework with Redshift and DataPipeline

  • 株式会社グラニ

概要

Windows Server (on AWS)でもログ収取とデータ分析をするための話

ソーシャルゲームへの流量

ゲーム自体には、

  • ピーク 1万req/sec
  • daily １億req

グラニがC#こだわる理由

グラニがC#にこだわる理由 第1回　神獄のヴァルハラゲートの裏側をCTOが語り尽くす！ を参照とのこと。

データ解析までのシステム構想

現在考えているデータ解析までのシステム構想としては、下記の流れでRedshiftに送れるようにしたい。

EC2 -> S3 -> AWS DATA Pipeline -> Redshift

今はまだ、Redshiftを使っておらず、Sumologicを利用している。

Windowsでログ転送したい

  • ETW (Event Tracing for Windows)
    • 1000 req/secであれば特別な配慮いらず
    • OSの機能として搭載
  • SLAB (Semantic Logging Application Block)
    • SLABは、ETWと組み合わせて使う
    • .NETアプリからの扱いが楽になった
    • ETWとSLABを使ってS3にログをアップロード

グラニさんの別の方が書いたスライドにて、ログ解析基盤の詳細を確認することができます。

8. AWSメインの会社に転職したので数少ないAWS経験の話もしくは個人検証してるCloudSearchの話。もしくはその両方

AWSを使った仕事経験

AWSで0から構築するためのドキュメントとコードのみで納品したこともある。 インフラもコードに近づいてきている。

Cloud Searchを使ってみた感想等

AWSは、どんどんアップデートされていき、一つ一つのサービスの充実だけでなく、AWS内の各サービスの連携もどんどん向上していっている印象を受けますね。 以上で勉強会の報告を終わります。

ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

前の記事

Tableau Server で初めてのグラフ共有

次の記事

はじめてのElasticsearch