AWS Summit Tokyo 2015 DAY1/Tech Deep Dive by Amazon/全セッションメモ

※当日の生メモです(校正していませんm(_ _)m

[TA-01]Amazon CloudSearch Deep Dive

Amazon CloudSearchとは

• snap dish事例
• フルマネージ検索エンジン
• A9社
• JSONでスキーマ定義をうｐ
• 形態素解析
  • 辞書カスタマイズ
    • SDK,API
  • シノニム、類義
• Bi-gramもあり
• スコアリング
  • tf-idf
  • tuningは多彩
• A/Bテストがマネージメントコンソール上で可能
• Field Types
  • Literal
  • Double
  • Date ..
• Suggestions
• Multi AZ
• IAMによる管理

Inside Amazon CloudSearch

• EC2->SQS->(SDF)->EC2->CloudSearch

仕組み

Indexing

• S3+DynamoDB(メタデータ)をポーリング
• Lucen/Solr

Query

• (query)->ELB->EC2...
• ELBでパーティショニング
• フツーにAutoscaling

Auto Partitioning

• 最初はスケールアップ
• 1つのIndexをEMRで分割
• 結果整合性モデル
• 初期データが大きい場合は最初から横並び

事例

• schoo
• nanapi デフォルト辞書 cake-php事例
• ChatWork
  • 日本最大級
  • 5億件
• Lancers
• ごちクル
• SMART/insight
• Pasona/Connected

追加情報

• フィールド展開した場合のFullGC対応など
• DocValue
• Filtering vs. querying

[TA-02]Amazon RDS for Aurora Deep Dive

※Preview版 6/2 時点

Amazon Aurora

• RDS前提
• PIR可能
• RDSの新エンジン
• ゼロベース
• EPレベル可用性+OSSレベルのコスト
• 5番目のエンジン
• Price List
  • R3のみ
  • I/O課金
  • MySQL(5.6) 100% コンパチ

Amazon Auroraの特徴

• MySQL5.6 互換性
• 10GB-64TBAutoScale
  • プロビジョニング、サイジング不要
• 3つのAZ
• S3ストリーム
• 99.99%の可用性

なぜAmazonがデータベースを再考したか

• モノリシック
  • コスト・可用性・柔軟性の面での問題
• 70年台のアーキテクチャは古い
• クラウド向きなDBを作りたい
• フルマネージド

アーキテクチャ

• SOA
  • ログ、ストレージ
    • スケールしやすい
  • キャッシュ
    • DBのプロセス外
    • DB restartしても消えない
  • S3
    • バックアップ大事

• Control Plane

  • DynamoDB
  • SWF
  • Route 53

• Auroraのストレージ

  • 全SSDを利用したシームレスなスケール
    • 課金メリット
  • ログストラクチャードストレージ
  • 6つのdiskに書き込み
    • DC跨ぎ
    • 4本書き込みでACK
    • 10GBチャンク
  • ホットスポットの影響を取り除き高並列度
  • マスタ・スレーブ同じ
  • 自動で再ストライピング、修復、暗号化、ホットスポット除去

LogStoracturedStorage

• 追記型
  • メリット
    • シーケンシャルに読める
    • 末尾は最新
    • 継続バックアップ(ストリーム S3)が効率的
    • 10GBチャンク
• 6本
  • 故障は前提
    • 2本障害リードライト
    • 3本障害リードのみ
• MySQLのレプリケーションとの比較
  • リプリ遅延起きにくい
  • メタデータの転送のみ
  • マスタ・スレーブも同じdisk
    • データ欠損起こらない
  • MAX 15台のリードスレーブ
    • MySQLは5台
  • 10~20,100msのレプリカ遅延(全ノード)高速
• 旧RDSと違いスレーブもリード可

• セキュリティ

  • 暗号化
  • SSL
  • 直接アクセス不可(SSH)

• DBクラスタ

  • 単一のエンドポイントを提供
  • クラスタパラメータグループ
    • MySQLはDBパラメータのみ

• 新しいメトリクス画面

フェールオーバとリカバリ

• リードレプリカが存在する
  • 1,2分->1分
• リードレプリカが存在しない
  • 10分
• レプリカもリードできるのでスレーブとして扱える
• 障害発生時の起動ノードの指定が可能
  • 同じAZ,違うAZ選べる
• クラスタエンドポイント
  • Writeは常にマスター
  • CNAME
    • APは障害発生時もリトライで再接続
• 高速なデータ修復(クラッシュリカバリ)
  • MySQLはロールフォワード遅い(シングルスレッド)
  • Auroraはチャンク単位、マルチスレッドなので高速
• Streaming SnapshotとPITR
  • S3
  • 5分前から30日等(Backup Retention Period指定)
    • 2分程度になる予定
• SQLによるフェールオーバーのテスト
  • ALTER SYTEM CRASHなど

パフォーマンス

• クエリ並列度が高い、データサイズが大きいケースで効果が大きい
• ロック機構やQuery cacheなどに手を入れている
• MySQLとくれべてCPU使用率が高いが高スループット
• 性能は5倍(re:invent)
  • TPC-Cを同じ場合2.5

マイグレーション

• RDS for MySQLはワンクリック
  • パラメータ変更に注意
  • MyISAMは
  • INNODBのみ
• MySQL5.6->Auroraはレプリケーション可能
  • オンプレ切り替え可能
• 複数の小さいDBをシャーディングしている場合
  • 逆にまとめるメリット
• テーブル正規化、単発のクエリチューニングは今までどおり大事

まとめ

• クラウド向けにAmazonが再設計(MySQL5.6互換)
  • 実行計画は変わる
• 高い実行並列度、データサイズ大きい環境で性能発揮
• 高可用、高速フェールオーバ、PITR

[TA-03]Amazon Redshift Integration Deep Dive

セッションの目的

• オンプレ、他のAWSサービスと連携方法の知識を深める

Redshiftの概要

• 分散DWH
• 10GB eth
• JDBC/ODBC
• 列指向
• 圧縮
• DynamoDB,EMRなどとの親和性
• クエリ分割、C++コードレベル
• ノードスライス
  • メモリ、ディスク=CPUコア
• データロード
  • スロット数と同じ並列度でロード
  • S3からCSV
  • ファイル数はスロットの倍数が望ましい
  • EMR,DynamoDB,リモートホストから

Redshiftの主要アップデート

• Redshiftのカスタムドライバ
  • PostgreSQL->独自
  • jDBC4.1/4.0,ODBC3.8
• Interleaved Sort Key
  • Sort Keyがマルチカラム可能に
    • CREATE TABLE ... INTER...
    • Compound Sort Key
      • 先頭カラム飛ばしIndexFullScanの回避イメージ
• オンプレデータ連携
  • データをS3にCSVup後copyクライアント
  • 直接INSERTは非推奨
    • DynamoDB,kinesis経由で
• 他サービス連携
  • S3をハブに
  • ストリーム
    • Kinesis
  • イベント
    • Lambda

Redshiftにおけるインテグレーションとは？

• シンプルシナリオ
  • tarendの例
    • 1400万件のアンロード(CSV)
    • S3にうｐ(パラレル)
    • EMRでフィルタ
  • tarendの特徴
    • S3,Redshift連携デフォ
    • シナリオをzip(jarスクリプト)でエクスポートし実行可能
  • Extract-upoad-Transform-Loadまで1シナリオのデモ
    • Oracle RDS
  • データの抽出時点でCSV分割
  • 増分抽出の例
• CDC
  • データのロード先がファクトテーブルの場合、通常は日時や識別子などを抽出条件に使用
  • ケース
    • 毎回全件(少ない(数万件))
    • ソーステーブルにトリガー
    • RDBMSのトランザクションログを解析
• 設計のポイント
  • メモリ枯渇に注意、カーソル処理
  • ファイルは圧縮でうｐ
  • アップロードは並列で
    • tarendでは選択可能
  • S3のキーは日付+テーブル名などが分かりやすい

ETL + Upload

• Transformをどこで実行するか？
  • オンプレで側でやる
    • うｐ前クレンジングで転送時間の削減
    • オンプレリソース要
  • S3->EMRで(推奨)
    • Redshiftの負荷をオフロード
    • Hadoop関連技術要
  • Redshift内で
    • RedshiftのSQLで完結
    • Redshift負荷は上がる
• EMRのHiveによるTransform例
  • フルマネージドによるスケールメリット
  • S3 -> Hive -> S3
  • SQL likeに処理可能
  • tarendはEMRアダプタが無い
    • PowershellでAWS CLIとHiveのスクリプトを実行
    • すべて非同期呼び出しなので、前処理完了待ち(ポーリング)などの工夫が必要
• Redshiftへのロード
  • copyコマンド
    • 正規表現でファイル指定
    • 複数のコンピュートノードから並列に
      • ファイル単位なので注意
  • 新規テーブルの場合圧縮アルゴリズム自動
    • 事前設定すると解析処理をバイパスできる
  • STL_LOAD_ERRORS内部表にエラーコード格納
  • MAXERRORSオプションで許容エラー数を指定
  • tarendのフローでは、copyコマンド、insert/selectなど例
  • Management Consoleで処理件数などを確認可能
  • Load時(copyコマンド)にテーブルロック
  • テーブルのリネームをうまく使う
  • insert/selectはパラレル処理されるのでupdate/deleteよりおすすめ

まとめ

• ツール導入によるETL実装の効率化
  • 接続情報などをプロパティ化してジョブ間で共有
  • 毎回全フローを実行するのではなく各ステップ単位で、実行・デバッグ可能
  • 新しいドライバを使う

[TA-04]Enterprise Applications Deep Dive

AWSのエンタープライズアプリケーション

• Virtual Desktop
  • WoarkSpaces
    • マネージド型デスクトップコンピューティングサービス
    • Win,Mac,Android,iOSなどから
• Sharing & Collaboration
  
  • WorkDocs
    • マネージド型のセキュなエンタープライズストレージおよび共有サービス
    • アクセス制御、フィードバック既往
    • ドキュメントプレビューと共有はWebUIで直接閲覧
    • フィードバックでハイライトやコメント->メール通知
• Bussines Mail
  • WorkMail(Limited Preview)
    • マネージド型のEメール、カレンダーサービス
    • 暗号化キーや保存先、リージョンを設定
    • Outlook同等WebUIで

マネージドサービスの利点

• 調達、OS、ミドル導入、運用を任せられる
• 様々なデバイス(iOS...PCoIP)

高いセキュリティ

• WorkSpaces
  • PCoIP
  • MFA
• WorkDocs
  • すべて暗号化
  • CloudTrail監査ログ
• WorkMail
  • KMS

AWS Directory Service

• フルマネージド型の
• 2つのモード
  • SimpleAD
    • スタンドアローン
    • Samba 4
  • AD Connector
    • 既存のAD認証と連携
    • オンプレorVPC上のドメインを指定
    • 他要素認証(MFA)
• SSOの有効化
  • WorkSpacesとWorkDocs間
• 他要素認証(MFA)
  • 既存のRADIUSサーバと連携
  • ワンタイムパスワードなど
  • PAP/CHAP/MS-CHAP1/MS-CHAP2
• (例)Google Authenticatorを使った方法
  • スマホで無料利用
• Directory Service API
  • Create Directory
  • Create Snapshot
  • Enable SSO ...
• CloudTrailとの統合

Amazon WorkSpaces

• WoakSpacesバンドル
  • 6種類
• カスタムイメージの利用可能
  • 要件
    • sysprep互換
    • ユーザプロファイル
    • 10GB以内
    • ドメイン認証指定
  • コンソールから操作
    • 40,50分
    • Custom Bundleと紐付け
  • ベストプラクティス(カスタムイメージ作成)
    • Cドライブ空き
    • 最新プログラム、パッチ
    • 不要なキャッシュ削除
    • イメージを識別しやすく
• Amazon WorkSpaces Application Manager
  • アプリケーションのデプロイと管理
  • WAMカタログ
    • AWS Marketplace for Desktop Appsの利用
    • 特定業務アプリケーション
    • ライセンス保有アプリケーション
  • カタログの作成
    • アプリのアップロード
    • AWS Marketplace for Desktop Appsのサブスクリプション
  • VS、Officeなどのサブスクリプション利用が可能
• ネットワーク
  • 2つ
    • VPCおよびインターネット接続用ネットワーク
    • WorkSpace管理用、画面転送用ネットワーク
  • 要件
    • ADのポートなどいろいろ
    • チェックツールあり
  • インターネット経由 TCP/UDP 4172を使用
    • or 専用線(Direct Connect)
• インターネットへの接続
  • NAT Instanceパターン
  • On-Premise Firewallパターン
  • Public IP Addressパターン
• ローカルプリンターへの印刷
  • 自動的に認識される
• グループポリシーによる制御
  • pcoip.adm
• WorkSpaces API
  • オペレーション自動化
  • ディザスタリカバリイメージの展開
  • AWS CloudTrailでロギング

Amazon WorkDocs

• セントラルハブ
  • アクセス件の設定
• CloudTrail
  • APIコールレベルで監視

Amazon WorkMail

• AWS key Management servie
• Amazon Simple Email Serviceとの統合
  • 独自ドメインの設定、利用が可能
• DKIMによるメール署名の有効化

[TA-05]AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ

Introduction

• デプロイの自動化はまだまだ
• 必要性は別セッションで、今回は方法論

• AWSの関連サービス

  • Code Commit(Private Git)
    • Code
  • Code Pipeline
    • Build
    • Test
  • Elastic Beanstalk, OpsWorks
    • Deploy
    • Provision
    • Monitor
  • CloudFormation
    • Provision
  • CloudWatch
    • Monitor

• Elastic Beanstalk

  • 定番構成の構築、アプリデプロイの自動化サービス
    • 速く簡単
    • インフラの準備、運営からアプリスタックの管理
    • Auto Scaling
    • Java, PHP, Ruby, Node.js, .NET, Docker, Node.js

• OpsWorks

  • 多様なアーキテクチャをサポートするデプロイ、管理サービス
    • Chefのレシピ
    • ライフサイクルイベントにより動的な構成が可能
      • Chefの制御
    • 継続的な構成管理

• AWS CodeDeploy

  • アプリケーションデプロイに特化したサービス
    • Amazon.comと同じ仕組
    • エージェントをインストールするだけでEC2でもオンプレでも
    • グループ内で一度にデプロイしたり個別にデプロイしたり
      • タグ(インスタンス、Auto Scaleingグループ)で管理

• CloudFormation

  • 設定管理 & クラウドのオーケストレーションサービス
    • テンプレートを元にEC2やELBの構築を自動化
    • JSONで定義

各種サービスを使ったWorkpressのデプロイ手法

• Wordpressとは？
  • (ry
• 構築する構成イメージ
  • フロントELB
  • EC2 Webサーバ
  • RDS MySQL
  • WordpressのプラグインでS3
  • GitHubからコードをデプロイ
• 注意事項
  • Not どれがベスト
  • 特定アプリケーションにおける各種サービスの例

AWS Elastic Beanstalk

AWS Elastic Beanstalkによるプロビジョニング

• Enviloment作成
• インスタンス起動
• Host ManagerコンポーネントがManagerとHostManagerと通信
• 前もってGitHubにWordpressをアップ
• ダウンロード
• zip or warファイルでundeploy, deploy
  • ebdeployコマンド
  • S3に保存される

AWS Elastic Beanstalkを使った順次バッチデプロイ

• デプロイを1度に1台づつ、n%、全部など調整が可能

アプリケーションコンテナをカスタマイズ

• Elastic Beanstalk Configuration FIleで動作中のコンテナをカスタマイズ
• AMIを作り直さなくて良い

環境設定のRolling Update

• Auto Scalingグループ内にあるインスタンス置き換えを伴う操作を一部づつ実行
• 内部的にはCloud Formationの機能を利用

AWS OpsWorks

AWS OpsWorksによるプロビジョニング

• PHP App Serverレイヤーを作成
• PHP App Serverレイヤーにインスタンスを作成

AWS OpsWorksによるデプロイ

• レシピをデプロイ
• OpsWorksのエージェントがポーリング
• Appをダウンロードしてインストール

デプロイJSON

• host, database, username etc...などをパラメータ化可能

5つのライフサイクルイベント

• Setup
• Configure
• Deploy
• Undeploy
• Shutdown

ライフサイクルイベントによる自動デプロイ

• 複数ノードでConfigureイベントで同期実行される
  • 動的な構成変更に対応しているのがポイント

環境のカスタマイズ

• GitHubにChefのレシピを修正してpush
• カスタムCookBookの更新

CodeDeploy

CodeDeployによるデプロイのための事前準備

• EC2インスタンスにCodeDeployエージェントをインストール

CodeDeployによるデプロイ

• WordPressにAppSpecファイルを含める
• Deployment Groupに

Deplolyment Configuration

• どれ？
  • commit idを指定可能
• どうやって?
  • Deployment Configuration
• どこに?
  • タグで管理

appspec.ymlのhools

• シンプルに既存のshellスクリプトを利用可能

AWS CodeFormation + AWS CodeDeploy

• 連携はできない

AWS Cloud Formation

AWS Cloud Formationによるプロビジョニングおよびデプロイ

• テンプレート
• インスタンス起動タイミングでcfn-initが動いてデプロイ
• JSON形式
• インスタンス単位なので継続的デプロイ向きではない

まとめ

• デプロイ & マネジメントサービスを活用することで簡単にデプロイ自動化が可能
• サービスによってデプロイ手順が異なる
• システムの要件と合わせて最適なサービスを活用すべき

[TA-06]Amazon EBS パフォーマンスベンチマーク 2015

Amazon EBSについてのおさらい

• 基本
  • EC2インスタンスからアタッチして使用するブロックデバイス
  • Snapshot機能によるバックアップ、暗号化など
  • 99.999%の可用性
• EBSの特徴
  • 1GB~16TB
  • AZで独立
    • 復元は跨ぎ可能
  • 複数EC2インスタンスからの共有負荷
• アーキテクチャ
  • AZ内で複数HWでレプリケートされ冗長化不要
  • 実態はネットワーク接続型だが隠蔽されている

• ボリュームタイプ(3種類

  • 汎用SSD
  • Provisioned IOPS(SSD)
  • Magnetic
  • あとでSnapshot変更時にタイプ変更可能

• 汎用SSD

  • 標準
  • 1GB~16TB
  • 一時的に性能を引き上げるバースト
  • 1GB 3IOPSで計算する、1,000GB以下だと3,000IOPSまでバースト可能
  • 1000GB 10,000IOPSまで
  • 最大160MB/s
  • 1,000GB以降は3,000IOPS超える
  • バースト継続時間はI/Oクレジット残高によって決まる
    • 例 100GB 300IOPSベース 33分間バースト 5時間で補充
  • 容量とスループット
    • 170GB以下128MB/s
    • 214GB以上で160MB/s

• Provisioned IOPS

  • 年間99.9%の時間について指定IOPSの+-10%の性能を発揮
  • 4GB^16TB
  • IOPS
    • 100IOPSから20,000IOPSの間で指定可能
    • 容量の30倍が上限
  • 256KB/s / 1IOPSで計算
  • 最大320MB/s(1,200IOPS)

• Magnetic

  • 最も安価
  • 1GB~1TB
  • 平均100IOPS
  • 最大数百IOPSまでバーストできる場合がある
  • I/Oリクエスト回数で課金

EBSのパフォーマンスを律速する要素

• EC2インスタンス側のスループット
  • EBS最適化オプションを有効化
    • NW帯域を切り離す
      • 最小500Mbps(62.5MB/sec)
  • インスタンスタイプごとのEBSスループットの上限値を確認
    • CloudWatchのVolume Read/Write (Byte)で
  • 上限に達している場合はインスタンスタイプを大きくする
• EBS自体のI/O処理性能を改善する
  • 実績IOPSを確認する
    • CloudWatchのVolume Read/Write (Byte)で
  • 上限に達していればタイプを変更する
• 各EBSのスループットの確認する
  • 個々のEBSボリュームタイプのスループットを確認する
    • CloudWatchのVolume Read/Write (Byte)で
    • OSでEBS
  • 上限に達していればタイプを変更する

事前ウォーミング

• 各ブロックの初回アクセス時に5%~50%IOPS低下する
• Pre-wamingにで回避できる
• ベンチマーク時は必ず実施
• DD、完全フォーマットで

単体で性能が出ない場合

• RAID0を組む
  • RAIDO6はやめとけ
• Snapshotの管理が煩雑になる

ベンチマークに見る

• 注意
  • 正式使用ではない
  • 変わる可能性があるので実際のユースケースでは検証すること
• 目的
  • 理論値の確認
  • RAID0の検証

検証環境

• c3.8xlarge
• Amazon Linux
• XFS
• tool: FIO

8KBブロック ランダム読み込み

• IOPS、スループットともほぼ使用どおりに近い
  • スループットは余力がある

16KBブロック ランダム読み込み

• IOPS、スループットともほぼ使用どおりに近い
  • 汎用SSDはほぼ上限値に近い

4MBブロック ランダム読み込み

• RAIDO以外は上限
• スループット上限にあたるのでIOPS上げ過ぎない

各種のランダム読み書き

• 読み込みとほとんど同様

インスタンスストア戦略

• 追加コストなし
• 実態はEC2のローカルディスク
• インスタンス停止で消える(再起動は消えない)
• アプリケーションの一時領域などで活用

インスタンスストアベンチマーク

• i2.8xlarge
  • 800GB x 8 ストライピング
• Amazon Linux
• XFS
• tool: FIO

インスタンスストアベンチマーク結果

• 読み取り
  • 最大40万IOPS
  • 4MBブロックで3.5GB/sスループット
• 読み書き
  • 最大35万IOPS
  • 4MBブロックで3GB/sスループット

ボリュームの暗号化

• AES-256
• HWで行うためオーバヘッド無し

暗号化検証

• c3.8xlarge
• Amazon Linux
• XFS
• tool: FIO

暗号化検証結果

• 汎用SSD 10,000IOPS
• 仕様通り10,000IOPS
• CPU使用率は暗号化有無で変化なし
• 20,000IOPSもほぼ同等

典型的な構成

• 構成例：小さいデータへの多くのアクセス
  • IOPS優先EBS
  • 汎用SSDで大きめ容量
• 構成例：大きいデータへの多くのアクセス
  • スループットを優先、IOPSを無駄に挙げないことによりコストメリット
  • 起動ディスク以外はMagneticでコスト効率最大
• 構成例：極めてIOPSが求められる場合
  • インスタンスストアを利用する
  • 永続化が必要な領域はEBSを利用する

まとめ

• 3つのボリュームタイプ
• ボトルネックを正しく理解し適切な対策をとる
• ユースケースによってインスタンスストアも検討する