Redshiftの分散スタイルとソートキーの決定方法を聞いてきた

6月１日　AWS　Summit Tokyo 2017に行ってきた！

次は
Amazon Redshift テーブル設計詳細ガイド –分散スタイルとソートキーの決定方法–

をメモメモ

---

・クエリ性能をさらに向上させたい

・大切なことは何か→書いてある
　最良のソートキー
　最適な分散スタイル

・分散スタイルとソートキーに関する悩み
　そもそも、メリット・デメリットが・・・
　統一感ない

・分散スタイル
・分散スタイルとは何か
　１万枚の注文書　５人の名前が書かれたお客様
　１０人で抽出

・３つの分散スタイル
　ＥＶＥＮ
　　１万枚を、１０００枚ずつ１０人
　ＫＥＹ
　　注文者名が　あではじまるひと、　かで始まる人
　ＡＬＬ
　　１０部コピーする

・最適な分散スタイルの例
　ＥＶＥＮ分散された注文書とＡＬＬ分散された名簿
　　１０人ほぼ等しく終える
・最適じゃない
　ＫＥＹ分散された注文書とＡＬＬ分散された名簿
　　あ行にくらべ、ワ行の人が早く終わる
　ＡＬＬ分散注文書、ＡＬＬ分散名簿

・ＥＶＥＮ分散とＥＶＥＮ分散
　　→再分散が起きる
　ＫＥＹ分散された名簿

・現実はさらに難しい
　さまざまなクエリに対応する必要がある
　分散キーは１テーブルに１個しか選べない
　フローチャートで機械的に判断

・分散キーの候補となる列の抽出
　公開された資料を印刷して貼っておいてね！

　均一に分散している
　　あ行　ＶＳ　わ行
　　ＮＵＬＬの割合が大きい列
　　調べ方　countで

　　その列のカーでぃなりてぃは高い？
　　スライスの数に対して相対的に高いか？
　　→４～５倍以上
　　調べ方　approximate count distinct 誤差２％だけど、高速

　その列でフィルターされているか　Ｎｏなら向いている　ＹＥＳなら保留
　ＳＱＬは資料を見てね！

　その列は第一ソートキー
　　→　ゾーンマップが聞く可能性
　　１Ｍごとのデータブロックの最大値と最小値

　その列でマージジョインしている？
　　一番高速なジョイン

・分散スタイルの決定

　結合に使用されているか
　　　→ＡＬＬ分散の結合子からなくなる

　分散キー候補があるか

　追加ストレージを許容できるか
　　→コピーされる：容量

　並列性能を犠牲にできるか

　ＡＬＬ分散が不向き
　　大きなファクトテーブル
　　結合しない単一テーブル
　　複雑な集計
　　頻繁に書き換えられる

　分散キー候補があるか
　結合条件で分散キー候補を使用するか？

・どのクエリを優先すべきか
　　いろいろ

・ソートキー
　ソートするメリット
　　ディスクＩＯ削減
　　クエリー実行時のソート処理
　　まーじＪＯＩＮ

・種類
　　ＣＯＭＰＯＵＮＤ（順番重要）
　　ＩＮＴＥＲＬＥＡＶＥＤ：メンテナンスコストが高い
　→一般的にはＣＯＭＰＯＵＮＤで十分


・ソート形式の決定
　ソートはＭＥＲＧＥ　ＪＯＩＮを有効にしますか
　実行時のＳＯＲＴ処理を削減しますか
　ソートはゾーンマップで改善するか
　さまざまな列でフィルターしますか？
　必要に応じてＶＡＣＵＵＭ　ＲＥＩＮＤＥＸできますか？
　データに８バイト以上のプリフィックスがありますか？
　　http://www→全部同じ：事実上ソートされない

・最良のソートキー列の決定
　　マージジョイン：ＤＩＳＴＫＥＹとおなじ
　　ＯＲＤＥＲ　ＢＹ
　　フィルタ

・まとめ
　分散スタイル
　　１．ＫＥＹ分散
　　２．ＡＬＬ分散
　　・結合に注目
　　ソートキー
　　interleave使えるか



　

awsのブロックチェーンに対する取組を聞いてきた！

6月１日　AWS　Summit Tokyo 2017に行ってきた！

次は

Blockchain on AWS Ethereum Deep Dive with INFURA（いんふ～ら）

をメモメモ

---

・いんてるありがとう
・あんけーとよろしくね

・アジェンダ
　ＡＷＳのとりくみ
　ブロックチェーンを支えるＡＷＳ
　Ethereum Deep Dive with INFURA

・自己紹介

・ＡＷＳの取り組み
　ブロックチェーンサービス：まだだしていない
　世界中でユースケース、支援依頼ふえつづけている
　　機能性、拡張性、柔軟性
　今後より多くの関連情報・コミュニティの支援
　　日本で初めてのセッション

・事例
　バンク　オブ　イングランド
　　去年：ラスベガス　Ｒｅ：インベント
　　ＰｗＣと一緒に　ＰｏＣ
　　ＶＰＣ，Ｄｏｃｋｅｒ、ＥＣＳ・・・
　→ふつうのＷｅｂアプリですよね…

　Coinbase（ビットコイン取引所）
　　そのまえのＲｅ：インベント
　・セキュリティ
　・急速な拡大
　・１ＴＢをリアルタイムに分析
　　　間にkinesis streamを入れた

ブロックチェーンを支えるＡＷＳ
・ＳｅｃＯｐｓ
　Ｓｔｒａｇｅ　　　　ＢｉｇＤａｔａ　Ａｎａｌｙｔｉｃｓ
　Ｃｏｍｐｕｔｅ　　　Ｓｔｒｅａｍ　Ｐｒｏｃｅｓｓｉｎｇ
　Ｎｅｔｗｏｒｋｉｎｇ

・Ａｍａｚｏｎ　ＥＣ２インスタンスファミリー
　汎用
　コンピューティング最適化
　ストレージ・ＩＯ最適化
　メモリ最適化
　ＧＰＵ／ＦＰＧＡ

・Ａｍａｚｏｎ　Ｅｌａｓｔｉｃ　Ｂｌｏｃｋ　Ｓｔｏｒｅ（ＥＢＳ）
　Ｅｌａｓｔｉｃ　Ｖｏｌｕｍｅ


・Ethereum Deep Dive with INFURA
　Say Hello to インフラ

・自己紹介
　ニューヨーク

・Ethereumとは何か
　分散パブリックブロックチェーン
　ブロックチェーンの技術もとにしてる
　ビットコインと違い、イーサを得ていく：暗号トークン
　イーサはネットワークの手数料にも使える

　ブロックチェーン：Ｐ２Ｐのためだけに、限定されている機能
　→新しいアプローチ

　いーさりあむ　ばーちゃる　ましーん
　チューリング完全：アプリつくれる

・比較

　いーさ
　　迅速に開発
　　シャーでぃんぐ
　　認証
　　抽象化：すぐに開発できる
　はいぱーれっじゃー
　ビットコイン

・なぜ、いーさ
　ばーちゃるましんつかえる
　エンタープライズイーサリアム：多くの人　日本でも
　　スマートコントラクト：トラスとフレームワーク

・スマートコントラクト
　コンピューターコード
　さまざまな取引を容易に
　条件合ったときに実行
　好きなオペレーションを展開

・会社ＣｏｎｓｅｎＳｙｓについて
　摩擦のないオペレーティングシステム
　すべての実装 dApp、製品：dAppをつくれるように
　エンタープライズの開発、ＰｏＣ

　ブロックチェーン　ソリューション　アーキテクチャ
　アプリケーション
　サーバー
　ブロックチェーン
　クラウドホスティング　ＩＮＦＵＲＡ　ゲートウェイ

　グローバル　デリバリー　エクスペリエンス

・イーサリアム開発の課題
　アプリケーション（ＤＡｐｐ）

　ユーザー　フロントエンド　（ＲＰＣ）　イーサリアムゲートウェイ　アプリケーション

・ラップトップにおける課題
　　リソース：特にディスク容量
　　管理

・クラウドＶＭにおける課題
　　同期時間
　　コスト

・ＩＮＦＵＲＡの紹介
　ティアレスなエンドポイント
　機能
　　セキュリティ
　　スタビリティ
　　フォルトとれランス
　　セキュリティ

・ワールドワイドピアリング

・アーキテクチャ
　ブーメラン型

・トラフィック、１日当たり８億

・ＡＷＳが支えている
　ログファイル分析の課題
　　無制限保存
　　どっかーとふるーえんとＤを使っている
　イーサリアムのシンク
　　デプロイするとき
　　攻撃を受ける
　→　Ｄｙｎａｍｉｃ　ＩＯＰＳ

　ＡＷＳ：高可用性

　https://infra.io

・まとめ

AWS Shield と AWS Lambda@Edgeによるセキュリティ話を聞いてきた！

6月１日　AWS　Summit Tokyo 2017に行ってきた！

次は

AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション

をメモメモ

---

・一般的なＷｅｂアプリケーション
　４つコンポーネント
　　静的：
　　動的：
　　パーソナライズ：
　　ＡＰＩ：

・デザイン上の考慮店
　セキュリティ
　可用性
　パフォーマンス
　モニタリング：通知

・デザインと実装における課題
　　柔軟性
　　モニタリングツール
　→かなり複雑なセットアップ

・このようなとき役立つ？
　柔軟性を失わず、構築できる

・静的コンテンツ
　Route53,CloudFront(CDN)
　CloudFrontを使ったエッジデリバリー
　　エンタープライズ級のＣＤＮ
　　ほとんどすべてのアセットで使っている
　エッジからの配信
　　ゲーム会社：きゃんでぃーふらっしゅ

・動的コンテンツの復旧能力
　ビジネスロジック、セキュリティ、ＴＴＬ０秒
　ELB
　なぜ、cloud Front必要→メリット４つ
　　ＴＬＳの終端
　　セキュアな全二重通信のコネクション
　　エッジとＥＬＢ間のコネクションの最適化
　　短い期間のキャッシュでも（ＴＴＬ）リクエスト急増時の耐性を大幅に上げる
　ＥＬＢの前にCloudFrontを配置している事例：slack

・パーソナライズされたコンテンツ
　カスタマイズされたコンテンツ、拡張性、遅延の低さ
　AWS Lambda
　利点
　　サーバー管理が不要
　　継続的スケーリング
　　使わないリソースの支払いない
　ＡＷＳのリージョン上のトリガー前程？
　もし、エッジでもできれば・・・
　Lambda@Edge
　　エッジロケーションにもたらす
　　Lambdaの特徴＋グローバルに分散（エンドユーザーの近くに）
　新しい使い方
　　バリデーション
　　Ｂｏｔもある
　　アクセス制御・認証
　　レスポンスの生成
　　Ａ／Ｂテスト：クッキー設定
　　セキュリティたかい接続
　　コンテンツのカスタム化

　エッジでコンテンツのパーソナライズ

・キャッシュ不可なＡＰＩ
　ＡＰＩゲートウェイ
　ラムダ使って、さーばーいらない

セキュリティ
・脅威の種類
　　ＤＤＯＳ
　　アプリケーション攻撃
　　不正ＢＯＴ

・ＤＤＯＳ攻撃の古いセキュリティ対策
　クライピングにトラフィックを送る
　データセンターにはクリーン
この問題
１）親和性の有効化
２）いつもＯＮではない→ひつようなときつかえないかも
３）エンドユーザーもＤＤＯＳもスクライピングへ→おそくなる

ＡＷＳの場合
・ＴＬＳ配信にＥｄｇｅを活用
・ＣｌｏｕｄFront標準セキュリティ機能　AWS サーティふぃけーと　まねーじゃー
・ＤＤＯＳ攻撃：ＡＷＳシールド

AWSシールド
　１．自動的にＡＷＳと統合
　２．常に作動
　３．経済的
　４．柔軟性

ＡＷＳシールドでＤＤＯＳ攻撃

ＡＷＳシールド２種類
　スタンダード：
　アドバンスド：プレミアム

　スタンダード：レイヤ３・４、レイヤ７はＷＡＦ
　アドバンスドは
　　ＤＤＯＳ自動検知
　　トラフィックエンジニアリング
　　レポート
　　２４時間３６５日の支援
　　経済てき

ＥＬＢとＡＬＢでファイヤーウォール

ＡＷＳ　ＷＡＦ
　柔軟なルール定義
　事前設定された保護
　セキュリティの自動化
　
まとめ
重要なポイント
１．セキュリティ機能標準で
２．Cloud Front：静的・動的コンテンツ
３．Lambda@Edge：パーソナライズ
　　Edge最大限に

OracleからAurora＆Redshiftへの移行実践ガイドを聞いてきた！

６月１日　AWS　Summit Tokyo 2017に行ってきた！

次は

Oracle DatabaseからAurora＆Redshiftに移行するための実践ガイド

をメモメモ

---

・自己紹介
・Oracleからの移行を検討しているお客様の声
　クラウドに移行：ＲＤＢもクラウドネイティブ
　ＣＰＵライセンスだとスケールできない
　予算のいっぱい、Ｏｒａｃｌｅ

・不安や悩み
　業務・開発
　　ＤＢ変更による影響
　　業務停止したくない
　ＩＴ部門
　　何をガイドしてよいかわからない
　　管理手法
　　移行費用

・決めなくてはいけないこと
１．対象システム
２．移行理由
３．移行戦略

・ＡＷＳの考えｗる６つの移行戦略
　りほすと：そのままもってくる
　りプラットフォーム：プラットフォームアップグレード
　買い替える
　リファクタ：書き換える　Oracle→おーろら
　廃止
　リテイン：保持（のこしておく）

複雑さ
　　保持
　　廃止
　　ホスト変更
　　買い替え
　　プラットフォームへんこう
　　書き換え：今回ここ

４．移行先
・ＲＤＳ　Ａｕｒｏｒａ（ＭｙＳＱＬ互換、ＰｏｓｔｇｒｅＳＱＬ互換）
・Ｒｅｄｓｈｉｆｔ

・特性概要
　→後で共有されるので、みてね
　ＯＬＴＰ：ＭｙＳＱＬ，Ｐｏｓｔｇｒｅ
　ＯＬＡＰ：Ｐｏｓｔｇｒｅ，ＲｅｄＳｈｉｆｔ

　数ミリ　ＭｙＳＱＬ
　数ミリ～　ＰｏｓｔｇｒｅＳＱＬ
　数ふん・時間　ＲｅｄＳｈｉｆｔ

　Ｊｏｉｎ
　　ＭｙＳＱＬ：ねすてっどループ
　　ＰｏｓｔｇｒｅＳＱＬ：ねすてっとループ、ハッシュ、ソートマージ
　　ＲｅｄＳｈｉｆｔ：ハッシュ、ソートマージ（Ｂ－ｔｒｅｅない）

・Ｓｔａｔｐａｃｋで評価してください
　SQL orderd by Elapsed Timeを調査

５．期限
６．担当者
→工数の見積もり
　移行先との違いの量

・ＡＷＳから提供する移行支援サービス
　データベースマイグレーションサービス（ＤＭＳ）
　ダウンタイム最小限で

　移行中もアプリケーションは稼働したまま

　１．ＤＭＳを用意する
　２．ソース・ターゲット接続
　３．ターゲット切り替え

　使用簡単
　豊富なプラットフォーム
　簡単なセットアップ
　高い信頼性：マルチアベイラビリティゾーンにできる
　低コスト

・ＡＷＳスキーマ　コンバージョン　ツール（ＳＣＴ）の特徴
　手動変更の補助：できなかった箇所・理由めいじ
　評価レポートの作成
　アプリケーションＳＱＬに対応
　豊富なプラットフォーム
→機械的に変換できるＳＱＬを変更
　評価レポート：何パーセント自動変換できるか
　Disableの制約
　ビットマップインデックスをどうするか

・違いのアジェンダ
　前程：
　　自動変換できない部分を抜き出している
　　機能は省いている

　移行事例
　　レコチョク
　　スライドシェアに上がっている

１．オブジェクトの違い
　インデックス
　シーケンス
　マテリアライズドビュー
　ＭｙＳＱＬのシーケンス
　　Auto_Increment
　マテリアライズドビュー
　　ＰｏｓｔｇｒｅＳＱＬ：読み取り専用
　　データベースリンク　関数
　　　RedShiftと組める
　パーティショニング
　ストアドプロシージャ
　　PL/pgSQL
　　ストアドルーチン
　→PL/SQLと同じではない

２．Selectでの違い
　互換性がないと
　　文法エラー
　　結果異なる：非互換に気付かない→やっかい

　結果相違を起こしやすい２大ポイント
　・ＮＵＬＬとから文字の違い
　　　ＯｒａｃｌｅはＮＵＬＬと空文字同じ
　　　ほかはＮＵＬＬと空文字違う
　　MySQL || はＯＲ CONCATはNULLが帰る
　→COALESCEで対応

　・ＣＨＡＲの末尾に埋められた空白の違い

　そのほか
　　・結合の方法の向き不向き
　　・ヒント
３．ＤＭＬでの主な違い
　Ｏｒａｃｌｅ：あまりいじらない
　ＭｙＳＱＬ：ファジーリードが発生しない
　ＰｏｓｔｇｒｅＳＱＬ
　ＲｅｄＳｈｉｆｔ：シリアライズのみ
　ＭｙＳＱＬ独自のロック
　　→次のキーまでロックしてしまう
　ＲｅｄＳｈｉｆｔ，ＰｏｓｔｇｒｅＳＱＬのバキューム
　　ＤＥＬＥＴＥ，Update
　PostgreSQL Vaccume FULL
　　ただし、Vaccumeはチューニングされている

　マネージ度型ＲＤＢＭＳなので、構築運用は簡単

・まとめ
　ブログで公開する
　順序決定要素
　　複雑かどうか
　　ミッションクリティカルか
　　得られる利益が大きいか
　→利益大きい
　　アセスメント

AIがメイクを無効化してしまう、メイク落としアプリ「MAKEAPP」

写真を選んでワンタップ、相手を一瞬で「すっぴん化」することが出来る

https://twitter.com/appmarkelabo/status/869754372598636544

国内でテレビがランサムウェアに感染

広告みたいだけど、一応メモ

進む｢家庭内IoT化｣に潜むリスク
http://toyokeizai.net/articles/-/169860