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つのボリュームタイプ
* ボトルネックを正しく理解し適切な対策をとる
* ユースケースによってインスタンスストアも検討する