Skip to content

Instantly share code, notes, and snippets.

@moaikids

moaikids/gist:5720325

Created June 6, 2013 09:15
Show Gist options
  • Save moaikids/5720325 to your computer and use it in GitHub Desktop.
Save moaikids/5720325 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.md

#AWS Summit

#RedShift

  • Launched on Japan region (6/5)

    • hs1.xlarge or hs1.8xlarge

  • RedShiftの概要

    • オンプレの課題
      • 初期費用
      • ファシリティ周り(monitoring, backup, etc..)
      • scalability
    • 位置づけ
      • transaction - DynamoDB/RDS
      • analytics - Redshift/EMR
    • input
      • S3
      • EMR(直接Redshiftに書き込める？)
      • DynamoDB
        • Datapiplneを使ってインプットフローを制御できる
    • architecture
      • leader node x1 - compute node x n
      • 最大1.6PB
      • leader node でc++のコードを自動生成→compute nodeで実行
      • nodeのresizeには自動的にbackend clusterが生成され、裏でデータコピーされる。

  • 性能評価

    • NRI
      • 先行公開時から評価、不具合報告
    • 性能
      • 500億件 - 1.5TBのデータ
        • 8XL x 2 で43s x8で17s
          • ノードを増やすごとにスケール
          • クエリーの種類は？ → 一週間分のデータをgroup by で取得。週報を作成するイメージ
      • データロードもノードを増やすことでスケールする
      • 小さいテーブル(500億件から集約処理した1.2億件)
        • 小さすぎると並列処理分のオーバーヘッドでノードが多いほうが遅くなる or 線形に速くならないケースもある。
      • EMRとの比較
        • 500億件のデータに対するJOIN＋集計処理
          • RDBMS or DWHで得意な処理なので当然EMRより速い…
      • チューニング
        • distribution key と sort keyを適切に設定すると参照が速くなる
        • ただしロード時間が遅くなる傾向がある

  • 注意点

    • 不得意な処理
      • 特定のcompute nodeに処理が集中？full scanがかかる？
      • EMRと組み合わせて、加工済みのデータを集計するようにすれば大丈夫？
      • 大量のtransactionには不向き
        • 少ないtransactionで大量のデータ操作が得意

  • エコシステム

    • データ移行ツール
    • BIツール
      • 6/21(fri) ,8/2(fri) 目黒でセミナー実施予定 *質疑応答
    • パフォーマンス的な地雷は？
      • OLTPのような処理は不向き。redshiftのleader nodeは同時15query しか受け付けず、それ以上はqueueingされる
    • schemeの定義は
      • とても大事。一度設定したsort keyやdistribution keyは変更できない。この部分の変更が必要な場合はテーブル再定義→migrationが必要
    • なぜリアルタイムデータロードに対応しないのか？S3にデータを置かせるのはなぜか？
      • 我々はS3をストレージとして一番信頼しているから
    • どのタイミングでclusterが見えなくなるのか？
      • nodeの追加など、データの再分配が必要なタイミングでclusterが見えなくなる。データコピー完了後復帰する
    • 重複のあるデータのupdate insertは可能か？
      • 基本的にはデータロードは常にappendされていくので、工夫が必要。短期的なデータをtemporary tableに入れて、１日おきにQueryで重複をはじいてinsert、など
    • redshiftの資料等はあるか？
      • AWSのサイトに一つある

#HPC

  • intel
    • 立場
      • HPC / cloud / OSS
      • スパコンの性能向上に多大なる貢献
    • Xeon 5
      • 少ない電力で高性能
      • avx アクセラレータ。前の世代に比べて浮動小数点演算で倍の性能。
      • ターボブースト機能。電力、熱に余裕がある時はブーストしてスレッド機能を向上。温度管理が適切にされている環境でより優位性がある。
  • HPC on AWS
    • 時間課金。sequencialで3job実行するのと、3cluster pararelで実行するのとで、料金が変わらない
    • starcluster
  • クラスタインスタンス
    • 10GbE
    • 1プレイスメントグループに220ノードを格納可能
      • placement group内でインスタンスタイプを混在できない
  • 性能評価・事例
    • NASA
      • http://trs-new.jpl.nasa. gov/dspace/bitstream/2014/43124/1/12-4716_A1b.pdf
      • 数十万枚の画像データを解析。地表の起伏を解析
      • 小規模のMPI処理や、大規模Embarrassingly parallel処理をAWSで。
  • promotion

#Obama

  • ワタシハ オオキイ オカシイ オタク

  • チャレンジ

    • 何十億ドルというお金を集める必要がある。世界で30以内に入るECサイト
    • まったくの新しいアプリケーションを200以上作成
    • まったく新しい手法を用いたデータ解析。
    • 時間がない（6 monthes）
    • お金もない。参加する人の質が様々。平均年齢24歳。

  • 採用した技術

    • 様々
      • 多種多様な言語を用いることで開発が複雑化するが、疎結合なシステムにすることで複雑性を閉じ込める方向で
    • SQS
      • request数 比で対EC2で価格競争力がある。
      • 自前で作る時間が無いので、OSSやAWSの既存のサービスを有効活用
    • dynamoDB
      • mongoDBは書き込みが遅い…
      • dynamodbで750万件のデータを8分間で登録
    • multi region
      • タイフーン襲来…
      • 三ヶ月かけてus-eastに構築したシステムを、９時間でus-westにも設置。
      • RDSを用いたデータの multi region DR backup

  • 学んだこと

    • game day
      • 障害の予行演習。何をすればよいか学習
      • 環境を壊すチームと、復元するチームで共同作業
    • 疎結合なアーキテクト
    • 失敗や障害から学ぶ
      • ピーク時で、１分あたり40万ドルの寄付。システムを落とすことは許されない。
      • 運用中にPIOPSが導入された。乗り換えたら10倍の性能。
    • 耐障害性
      • S3に置いた静的ページを、最後の砦として使用

#CDP

  • http://aws.clouddesignpattern.org/index.php/
  • 6月末にCDP niteを開催予定？
  • backup
    • snapshot pattern
      • EBSへのamiのバックアップ
    • Cloud DI
      • 各インスタンスの振る舞いを外部で定義
        • tag
          • ec2の場合最大10個、150文字まで、という制約あり。
        • UserData
  • security
    • operation firewall pattern
      • security group の設定
    • ondemand bastion
      • 踏み台サーバー。こちら経由でアクセスをするように。
      • 使用が終わったらterminateする
    • ondemand firewall pattern
  • HA
    • avalavitiy zone をまたいでfail overしたい
    • internal dns
      • 切替速度がdnsのTTLに依存する
    • routing based HA
      • ノード監視ツール : corosync, pacemaker
  • 本

#Panel Discussion

  • treasure data
    • consumerization of IT
    • data analysis をconsumerizationするのを目標に起業
  • 三井物産
    • 基幹業務はSAP
      • 将来的に動作し続けるかどうかが肝
      • 検討項目：既存のアセットとの親和性、グローバル（≒日本のドメスティック市場）への対応、運用コスト、マネージ出来るか、セキュリティ担保、トータルコストの削減が可能か…等々
  • 電通
    • マーケティングの流れがマスからITへ
    • 事例：エコポイントのキャンペーン対応
      • salesforce + aws
    • consumerの接点となる部分：AWS
      • オンプレミスとの結合をどうするか
      • 基盤となるIT部分がいかに柔軟で堅牢であるかが大事
  • 新しい技術に対するスタンスは？
    • TD:先端技術にはいいところも悪いところもある。悪いところがあるのなら出来る限り速く解消する必要がある。ex. 高機能vs安定性。
    • 三井物産：エンプラはどうしても保守的になる。ただし時代の流れに付いて行かないと置いていかれる。R&D部門を作りそこで評価。
    • 電通：PC→スマフォのパラダイムシフトで、consumerは24時間接触する存在に。波にのまれないためには乗り続けるしかない。
  • 懸念事項は？
    • 三井物産：セキュリティが一番大事。クラウドベンダーとの二人三脚が必要。
    • 電通：アプリケーション開発とセキュリティーベンダーは分けたほうが良い。
    • TD：一番言われるのはセキュリティ。法規制によっての縛りもある。ただし自社でもつ必要の無いデータ、持ちきれないデータについてはクラウドを有効活用するのも手
      • クラウドに出して良いデータとは？
        • customer interaction data - 購買履歴等は会社による。sensor dataなど個人情報に紐付かずかつ大量のものについてはクラウドに出しても良いのでは。
        • dataのanonymiseをどのようにやっていくか
  • どうやってWeb技術を取り組んでいくべきか
    • 電通：新しいものは世の中に無いのでやってみるしかない。リスクを最小限に留めるような仕組みは必要。
    • 三井物産：まずはやってみると良い
    • TD：簡単・使いやすい・素早く出来る、と言っていただける事が何よりも我々にとっては大事
    • 電通：早く出来て、安くて、将来的に拡張できる、というのがビジネス開発においては大事。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment