まりぱらおーぐ

主にコンピューター周辺の話を中心に、気ままに書いていきます。

AWS Solution Days 2017


f:id:o_chicchi:20170705213304p:plain

AWS Solution Days 2017 ~ AWS DB Day ~

有給休暇を取得して、あくまで個人として、AWS DB Day 2017 を眺めてきました。 参加したセッションを中心に少しだけメモを公開。

現在の担当のお客様は、AWS使ってくれないので、無縁なので会社に申告しにくかったし、専門分野は一応違うので。

いずれ、ビデオとかスライドは公開されるのではないかと。

基調講演

基調講演は、途中から聞いてました。自分もそうですが、基幹システムの標準は、今でも、Oracle が標準だったり、自分の仕事の中での悩みは一緒だなと思って聞いてました。

公演内容は、公式サイトより。

  • Amazon Aurora for PostgreSQL Compatibility を評価して

    • 石井達夫さん(SRA OSS Inc.日本支社 取締役支社長)
  • 100コア時代に通用するデータベースソフトとは?本当のスケールアウトとは?

    • 小幡一郎さん(株式会社インサイトテクノロジー 代表取締役社長)
  • シェアードナッシング型 Web アプリケーションと Kinesis Firehose による大規模データストリーム処理

    • 倉林修一さん(株式会社Cygames 技術顧問 兼 サイゲームスリサーチ所長)
  • 感想

    • 倉林さん(Cygames)の話は、システム構成としても定石としては、やりかたはわからなくもないですが、大学の先生もされているとかで、話もよかったですし、説得力抜群でした。

クラウド上のデータ活用デザインパターン

  • 登壇者

    • 志村誠さん(AWS JAPAN SA)
  • データ活用の流れ

    • データを貯める
    • データを可視化
    • データサイエンス
  • If Your Company Isn’t Good at Analytics, It’s Not Ready for AI.

hbr.org

  • データ活用は試行錯誤が必要

  • オンプレミスの問題

    • 時間の柔軟性
    • アーキテクチャの柔軟性
    • リソースの柔軟性
    • ワークロードの柔軟性
  • AWSデータ活用環境

    • データレイク
      • S3 にデータを蓄積してその周辺にサービスを展開する考え方
    • 全てのデータを1箇所に集約する
    • データストアとデータ処理の分離
    • 用途に応じた適切な処理方法の選択
  • 関連するAWSのサービス

    • Amazon Redshift
    • Amazon Redshift Spectrum
    • Amazon EMR
    • Amazon Athena
    • Amazon Kinesis Streams
    • Amazon Kinesis Firehose
    • Amazon Kinesis Analytics
    • p2インスタンス & Deep Learning AMI
  • デザインパターン

    • パイプライン
    • 複数レイヤの分析
    • ホットデーター
    • ラムダアーキテクチャ
    • 分析
  • 感想

    • Summitでも、志村さんのセッションは聞かせていただいていて、内容はとても有益でありがたいのですが、僕は、彼の話のスピードに必死についていくしかなく、終わるとどっと疲れるのは内緒。特に、If Your Company Isn’t Good at Analytics, It’s Not Ready for AI. は、素晴らしい引用です。
    • デザインパターンは、メモしきれなかったので、スライド公開に期待です。

ETL をサーバーレスで実現する新サービス AWS Glue のご紹介

  • 登壇者

    • 下佐粉 昭(しもさこあきら)さん(AWS JAPAN SA)
  • キーワード

    • スケールアウト
  • ETL処理

    • データの前さばき(フォーマット変換など)は必要
  • AWS Glue

    • 巨大データへのETLをスケールアウトで、サーバレスで
    • 内部では、Spark を利用している
    • スケールアウトは勝手にやる
    • PySparkで、ETL処理をカスタマイズ
  • AWS Glue の機能

    • データソースをクロールする
    • データカタログで管理
    • ジョブを作成する
    • サーバレスで実行される
  • データカタログ

    • 表のメタデータをHIveメタストアで管理
    • クロールする範囲を設定できる
  • ジョブオーサリング

    • データソースとターゲットを指定して、ETLジョブを定義
  • オーケストレーション

    • ETLスクリプトを読み込んで実行
      • IAMロールを指定できる
    • ジョブ実行
      • ジョブのスケジュール、先行ジョブ指定可能
        • 但しカレンダー機能なない
      • API 呼び出し
  • まとめ

    • サーバレスETL
    • Sparkベース
    • PySpark
    • プレビュー中
  • 感想

    • プレビュー申し込んでいじってみよう

オンプレミスから RDS for Oracle / SQL Server への Lift & Shift

  • 登壇者

    • 北川 剛(AWS JAPAN 事業開発マネージャー)
  • キーワード

    • クラウドファースト
  • データベースの課題

    • データ容量増大
    • システム連携
    • データ再利用
  • 検討するきっかけ

    • サポート切れ
    • システム更新
    • 拡張性の確保
    • コスト削減
  • 移行方法

    • Heterogeneous or Homogeneous
    • EC2 or RDS
  • Data Migration Service

  • 感想

    • まぁ、そうなんだよね。自分、社内システムの担当者じゃないからわからないことたくさん。

Big Data JAWS

Gunosy での Kinesis Analyticsの利用について

  • 登壇者

    • 小出幸典(こいでゆきのり)さん(株式会社Gunosy 開発本部 開発・運用推進部部長)
  • ストリーム、バッチ処理をする理由

    • サービス制約
      • ニュースは鮮度の制約がある
      • 見せられる量には制限がある - コンテンツへの反映
      • クリックされた情報などを即座に反映したい
  • Kinesis Analytics

    • ログを fluentd で転送
    • Kinesis Firehose -> Kinesis Analtics -> Kinesis FireHose -> Elastic Search Service
    • サービスが東京にないので、オレゴン使っている
  • Tips

    • 東京からオレゴンに転送するにはどうしたら良いか
      • Lambda はスループットは厳しい、汎用性がない
      • fluentd を導入した
  • 所感

    • 開発がラク、IAMは面倒
    • クエリだけ考えればよい
    • 運用はラク
    • Streams/Firebase の流量は注意(キャパシティ)
    • コスト削減できた
  • ブログ

data.gunosy.io

tech.gunosy.io

リクルートテクノロジーズにおける EMR の活用とコスト圧縮方法

  • 登壇者

    • 渡部徹太郎さん(株式会社リクルートテクノロジーズ ITソリューション統括部 ビッグデータ部、BigData JAWS 代表)
  • リクルートのビジネスモデル

    • リボンモデル
      • マッチングサービス、マッチングしてフィーをもらう
  • データ処理技術

    • 行指向
    • 列指向
  • Hadoop

    • Spark は、Hadoop でも動く
    • Hadoop は、プロジェクト名
  • Hadoop の特徴

    • データはファイル
    • 計算と分散ファイル配置は分離
  • EMRの特徴

    • Apache Hadoop をラッピングしたサービス
    • S3 に置けば移動しなくてもよい
    • クラスタは捨てられる
  • 利用方法

    • WebUIコネクタ
      • ELB を使って、処理画面を見せる
    • Hiveクエリを呼び出せるツールを作っている
    • スケジューラー
      • 起動したままだとコストは高い
      • 時間起動でインスタンスを選んで起動
        • 10分毎にチェックをしていて、不足したら、スポットで確保する
        • SpotFleetは今更です
  • 活用事例

    • EMR に移行で、サーバをタイムリーに増やせるので、開発や運用時にカバーできる
  • 感想

    • リクルートの分析基盤は興味深かったです。自前で、利用者の為のインターフェース作っているとか凄いですね。

ドコモビッグデータ分析基盤の AWS 上構築経緯と開発裏話

  • 登壇者

    • 佐々木純さん(株式会社NTTドコモ サービスイノベーション部 主査)
  • 分析基盤の特徴

    • 多種データ
    • 超大容量DB
    • 多数ユーザ
    • 少人数開発/運用
  • 苦労した点

    • 社内調整
      • 社内中のデータをクラウドに放り込むは、セキュリティリスクをしつこかった。
      • 別システム(コンシェル)の利用実績あり
    • 初めてのAWS
      • コンサル、AWSJのサポート
  • セキュリティ対策

    • 280 の社内基準
    • 運用者による内部犯行の防止
      • 単独でできない仕組みは必要
    • 閲覧情報の制限
    • データの持ち出しの制限
    • 運用グループA/B を作って、片方だけで作業を完結しないようにしている
    • 承認されたスキーマーされたものしかみえない
    • 多数のシステムカタログテーブルの権限を剥奪して、参照用のクエリを用意している
    • (昔のRedshiftでは)任意のバケットのLOAD/UNLOADができる問題があった
  • 問題

    • スキーマ数/テーブル数 枯渇問題
    • 不適切クエリの増加
    • CTAS問題
    • UDF問題(VOLATILEで全部やっていた)
  • AWSのアップデート

    • LOAD/UNLOCAD Revoke
    • インスタンス性能向上
    • VPCエンドポイント for S3
    • Redshift - S3 VPC エンドポイント対応
    • CTASの自動圧縮
    • Schema数の拡大
    • Redshift Spectrum
  • AWSへの要望

    • PostGIS
    • 最大テーブル数
  • まとめ

    • AWSに構築した。
    • セキュリティ
    • 拡張性
  • 感想

    • データセンター設置する場所探しからは、自分は経験ないので、水道工事するとか分からなかったですw
    • ラック立てて、ラッキングしたり、自分でパッチパネル付けたりとかの経験はありますが、さすが、ドコモw

全体的な感想

BigData JAWS の話はよかったですね。どっちかというと、Big Data的な話聞くのと、Aurora セッションが面白かったのかな。 自分でも、聞いた話をもとにいろいろ試してみたい。 (てか、AWS の勉強にさける時間あるの? 割かなきゃいけないんだけど…。)

印象的だったのは、AWS志村さんのお話の中の If Your Company Isn’t Good at Analytics, It’s Not Ready for AI. の引用ですね。データの分析すらできてないところは、AIとか言えないよ、とは、その通りです。

渡部さん(リクルートテクノロジーズ)や、佐々木さん(ドコモ)のお話にある分析基盤を作れないような会社は、時代にとりのこされるんだなと。

Copyright © 2002-2015 まりぱらおーぐ All Rights Reserved.