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

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

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

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

目次

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のチューニングが重要になる。 下表はデータ量に応じての対応の温度感を大まかに表している

アーキテクチャ

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

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

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

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

Redshiftでの処理単位

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

• 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が一番のボトルネックになっている あるインスタンスを利用したときの実測が下記の表。

チューニング

チューニングをする際には、一番ボトルネックとなるネットワークでのデータ転送を減らすことが重要。 そのためには、データの再分散を避けることが重要である。 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 で実現する簡単低コスト高速機械学習

• 株式会社マーズフラッグ
• Mahoutで体感する機械学習の実践

内容

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

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

6. 5分でできる ebfly

• AWS Elastic Beanstalk
  • ebflyというツールを作った
    • Ebfly を使った Sinatra アプリケーションの AWS Elastic Beanstalk へのデプロイ
    • github ebfly
  • Elastic Beanstalk用のCLI
    • herokuっぽく利用したかった。

ちなみに、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の機能として搭載
    • 詳細はこちらのJapan WDK Support Blogを参照_
• SLAB (Semantic Logging Application Block)
  • SLABは、ETWと組み合わせて使う
  • .NETアプリからの扱いが楽になった
  • ETWとSLABを使ってS3にログをアップロード

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

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

AWSを使った仕事経験

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

Cloud Search

Cloud Searchを使ってみた感想等

• Cloud Search
  • 全文検索エンジン
  • 2014/3/15に日本語対応!その他大幅アップデートでかなり使えるようになった。
    • Amazon CloudSearch 大幅アップデート – 1ヶ月100ドル以下でより良い検索が可能に！日本語にも対応！
• Cloud Searchの特徴
  • 良い点: インスタンスタイプと台数が自動でスケーリング
  • 不明点: 価格見積もりが難しそう

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

About Kai 36 Articles

マーケティング業務を担当。セミナー、勉強会の企画運営、情報発信を行う。API事業を中心に、リード獲得、ナーチャリングに注力。

Twitter YouTube