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とか言えないよ、とは、その通りです。

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