※当日の生メモです(校正していませんm(_ _)m
[TA-07]AWS への DC マイグレーションストラテジー
移行検討
移行設計
- Rehost
- アプリ改修しない
- VMImport
- アプリ改修しない
- Refactor
- 仕様は維持、一部マネージドサービスを利用する
- Web/APサーバはEC2に行こうしRDBい部分的にRDS
- 仕様は維持、一部マネージドサービスを利用する
- Revise
- アプリの仕様は維持し、一部機能改修
- WebAppをステートレスAotoScalling
- アプリの仕様は維持し、一部機能改修
- Rebuid
- アプリを書き換え、マネージド
- DynamoDB,Lamdba,Coginitなどが
- アプリを書き換え、マネージド
- Replace
- 既存のアプリをマネージドサービスで置き換える
- VDIをWorkSpaces, WorkDocsで置き換える
- 既存のアプリをマネージドサービスで置き換える
クラウド最適化例
- 注意点
- 既存機能をすべて実現できるとは限らない
- RDS
- 最大容量
- 細かいパラメータ
- ELB
- 物理負荷分散で利用していた機能を利用したい
- RDS
- 一部機能はアプリで実装
- 現行機能のソフトウェアをEC2に導入する
- 既存機能をすべて実現できるとは限らない
運用設計時の検討事項
- 運用変更項目の洗い出し
- 既存運用で必要なくなる差ぎゅお
- 追加で必要になる作業
- 手順が変更になる作業
- 役割分担
- どのチーム
- AWS権限管理
- ガバナンス
- コスト管理
- セキュリテイチェック方法
- ケーススタディ 社内標準ガイドライン作成
- 課題
- 複数システムを移行死体
- インフラ設計、運用設計を効率化したい
- ガラパゴスなシステムができないようガバナンスを効かせたい
- 解決策
- サービスレベル・インフラ・運用の標準を定義
- 標準サービスレベルを定義
- サービスレベル毎のアーキテクチャを策定
- アーキテクチャごとにテンプレート化してデプロイを自動化する
- CloudFormation
- サービスレベル・インフラ・運用の標準を定義
- メリット
- 運用コスト低減
- ガバナンスを効かせられる
- セキュリティテンプレート化
- セキュリティ設定変更の権限で制限
- セキュリティテンプレート化
- 課題
移行方法・ツール
移行方式
- サーバ
- サーバ再構築
- EC2インスタンス作成、各種設定
- OSパッチ適用、各種設定
- (ry
- 仮想マシンのインポート
- VM ImportでOSイメージごと
- 事前作業
- クローン作成
- 事前作業
- イメージ抽出
- Import後作業
- 各種設定(NW等
- データ移行
- 稼働テスト(基板・アプリ)
- 詳細
- OS変更は必要最低限
- 例 CentOS6.6
- ブートローダ
- ネットワーク関連
- ファイルシステム関連
- 事前作業
- 従来の課題
- 転送に時間がかかる
- 失敗した場合転送からやりなおし
- 同時にImportできる数が少ない
- EC2 CLIのセットアップが必要
- プション指定が複雑
- EBSのタイプが選べない
- 新しいVM IMport API
- ImportInstance(旧)
- ImportImage/ImportSnapshot
- イメージ転送とImport処理を分離
- S3にあるイメージを起点といてAMI作成(インスタンスではなく
- OVA、複数Volumeで構成されるVMに対応
- 実際
- OVAファイルのS3バケットとキーを指定
- OVA内の複数Volumeを一括Import
- VM ImportでOSイメージごと
- サーバ再構築
- オンプレミスからAWSへの接続
- VPN
- 帯域影響
- 専用線(DirectConnect)
- 移行ではおすすめ
- S3はVPCの外(プロキシが必要)
- 帯域の考慮
- 転送時間=ダウンタイムをいかに短くするか？
- データ同期までの時間がダウンタイムに直結
- ダウンタイムに合わせたデータ移行方式を選択
- 待機を有効に使える方式を選択
- 転送時間=ダウンタイムをいかに短くするか？
- VPN
- データ移行
- ファイル単位での移行
- S3へ
- S3 API、3rdパーティー製
- 高速化
- 専用線
- マルチパートアップロード
- 並列で
- EC2へ
- CIFS,NFS等選択可能
- 高速化
- WAN最適化ソリューション
- Tsunami-UP
- ASpera
- WAN最適化ソリューション
- S3へ
- ブロックデバイスをそのまま移行
- VM ImportサービスのImportSnapshot API
- データボリュームをまるごと
- 差分転送可能
- WAN最適化ツールの併用可能
- VM ImportサービスのImportSnapshot API
- ミドルウェアの機能を利用
- バックアップ・リストア
- 現行環境に手を入れないですむ
- 一般的に時間がかかる、ダウンタイムが十分に取れるか？
- ミドルのレプリケーション機能
- 一旦現行のスレーブとｓて稼働し、移行時に切り離す
- Active Directoryなど
- レプリケーション専用のソフトウェアを使う
- Oracle GoldenGateなど
- ライセンス料金が考慮点(一時利用など交渉
- 一旦現行のスレーブとｓて稼働し、移行時に切り離す
- バックアップ・リストア
- 切り替え方式の選択
- 一括移行
- ダウンタイム最長
- 一括+差分移行
- バックアップ断面+切替時の差分
- 並行稼動による段階的移行
- データを同期しながら利用ユーザを徐々に移す
- ファイルサーバ等では有効だがアプリケーションによっては困難
- 一括移行
- ファイル単位での移行
- データ移行のポイント
- 十分なNW帯域
- 帯域を有効に使える方式を選択
[TA-08]ネットワーク Deep Dive
VPC ベストプラクティス
- AWS MarketPlaceを活用する
- ファイアウォール
- Sophos
- ロードバランサ
- f5
- A10
- WAF
- IMPERVA
- ルータ
- CISCO
- ファイアウォール
- VPC Peeringを利用する
- VPC同士を接続しルーティング
- VPC Connectiongを作成
- 事例
- 会社間を連携、即座に通信が可能
- 決済サービス会社
- モニタリング会社
- データ解析会社
- 新しいEDIとも言える
- 会社間を連携、即座に通信が可能
- セキュリテイ機能の共有例
- VPCを分割し管理する
- セキュリティチーム
- Proxy
- WAF
- アプリケーション運用チーム
- Web App
- セキュリティチーム
- VPCを分割し管理する
- VPCのルーティングとセキュリティ
- VPC内のルーティングはすべてルートテーブルに基づく
- IPレベルで接続性を確保
- どのオブジェクトに転送するかを管理
- 主なルーティングのエントリ
- local,NAT,VGW,pcx-xx
- 主なルーティングのエントリ
- ネットワークACL vs セキュリティグループ
- ネットワークACL
- サブネットレベルで効果
- ブラックリスト型
- 戻り通信を意識
- ステートレス
- セキュリティグループ
- サーバレベルで効果
- ホワイトリスト型
- 戻り通信を意識しない
- ステートフル
- ネットワークACL
- まとめ
- ルーティングで疎通性を確保
- 全体ポリシーで不必要な通信をネットワークACLで
- 個別App設定はセキュリティグループで
- VPC エンドポイント
- プライベートサブネットから直接S3アクセス
- VPC エンドポイントを作成
- ルーティングを設定
- エンドポイントポリシー
- アクセス制御(IAMと同様)
- バゲットポリシーを代替可能
- 移行について
- エンドポイントを作成
- ルートテーブルにルートを追加
- NATインスタンス経由でなくなる
- 注意事項
- リージョンをまたげない
- VPN, AWS Direct Connectから接続できない
- プライベートサブネットから直接S3アクセス
Direct Connectベストプラクティス
- AWS BGPの動作
- ルートにBGP属性値は付与しない
- お客様ルータのBGP属性値を評価
- ロードシェアリング可能(マルチパスが有効)
- プライベート接続ではVPCのプレフィックス(CIDR)を広告
- BFDがデフォルトで有効
- 回線のフェールオーバーを高速化する
- タイムアウト90-180secが一般的
- BFD
- 高速な障害検知RFC5880
- ミリ秒レベルのBFDパケットの送受信(対向
- ルーティングプロトコル(今回はBGP)へ障害通知
- 音声や映像などにおすすめ
- BFD対応ルータを使用
- BFD使えない場合
- BGPの機能の一部
- Keepaliveパケットを指定した間隔で送受信
- KeepaliveHoldtime時間内に受信できないと障害と判定
- デフォルト値90-180秒
- お客様側を低い値に設定すれば採用される
-
Direct Connectのトラフィック
- Active/Standby構成
- オンプレからのトラフィックはLocal Preferne
- オンプレの受信トラフィックはAS Path Prependのパス超 * Active/Standby注意点
- どちらがActiveなのかをきちんと管理
- VPNやベストエフォート回線がActiveにならないように
- 上りと下りのトラフィックを意識
- BGP属性値によっては起こりうる
- Active/Active
- ロードシェアリング
- 回線を束ねる機能
- マルチパス(AWS側はデフォルトで有効)
- Active/Active注意点
- 回線の切断時、正常な回線にトラフィックが移動するため帯域あふれに注意
- トラフィックの偏りに注意
- Active/Standby構成
-
占有型と共有型
- 物理線を専有
- Connections
- 1契約で接続可能VPC数は複数、VLAN定義した分だけ可能
- ポイントツーポイント
- 物理線を他のお客様と共有
- Virtual Interface
- 1契約で接続可能VPC数は1
- キャリア閉域網の共有型の例
- エンドユーザには1契約あたり1つのVirtual Interface
- 物理線を専有
ネットワークのコード化(Infrastructure as Code)
- マネージメントコンソールで手順書にしたがった手動オペレーションをコードの実行に置き換える
- 自動化可能
- 構成管理可能
- ツール
- Cloud Formation
- JSONによるテンプレート
- 複製、アップデート、バージョン管理が容易
- ワークフロー
- JSON作成
- CloudFormationにロード
- 稼働システムをJSON化
- CloudFormerでテンプレート作成
- AWS CLI
- シェルから利用
- VPCとサブネット作成
- AWS SDK
- py, rb, javaで
- Cloud Formation
- タグによる動的NAT制御
- シェルでINSTANCE_ID, MACなどを取得し動的に構成
- 参考
- Cloud Ninjaサンプルコード参照
- AWS専用線アクセス体験ラボの紹介
[TA-09]AWS System Operation Deep Dive (Monitoring / Logging / Configuration)
システム基盤運用で考えるポイント
- 監視
- 死活監視、性能、キャパシティ
- ロギング
- システム変更の管理
- オペレーション、API
- 構成管理
- ITILよりの観点
システム運用を支えるAWSサービスと利用例
モニタリング
- Amazon CloudWatchの概要
- 各種リソースを監視
- 死活、性能、ログ
- メトリクスの可視化
- アラーム
- 多くのAWSサービスに対応
- EC2
- EBS
- (ry
- 課金情報の監視
- 可用性の考慮不要
- 各種リソースを監視
- Amazon CloudWatchのコンセプト
- 全体(NameSpace)->部分
- グループ全体->Demension(InstanceID)
- Stats(Sum, Max, Min)
- NameSpace?
- AWS/AutoScaling
- AWS/Billing
- AWS/CloudFront
- AWS/EC2
- (ry
- 全体(NameSpace)->部分
- Amazon CloudWatchを使ったモニタリング
- CLIでデータ抽出
- 既存の統合監視ツールと連携
- 統合監視とCloudWatchの住み分け
- CloudWatch => AWSの責任範囲
- 3rd Party => OS、アプリケーション
- CloudWatchのデータは2週間
- メンテナンスウィンドウのアラート抑止はできないので
- ZABIX、JP1
- Mackerelを使ったモニタリング
- SaaS
- AutoScalingに対応
- メールに情報添付
- Sensuを使ったモニタリング
- cloudpack
- 自己監視->rabitMQ->Sensu
- SSL
- Cloud Watch Logs
- OSによる違い
- Linux：エージェント入れてログ投げる
- Windows：EC2 Configがログ投げる
- Tips
- 1回のpush 32KB
- /var/log/awslogs/log
- truncateされる
- 対応しているログローテーション
- rename and re-create
- copy and truncate
- create and ..
- ログの転送設定
- file_fingerpring_linesパラメータ
- デフォルト1行目
- file_fingerpring_linesパラメータ
- メトリックスフィルタ
- しきい値=>アラームなど
- アクション機能
- モニタリング => アクション
- 1回のpush 32KB
- OSによる違い
ロギング
- CloudTrail
- 標準サービス、オンにするだけで良い、無料
- API呼び出し、バゲットにログ保存(gz(中身はJSON))
- 活用例(利用ケース
- 検知
- 短期的な目的
- ログイン失敗
- インスタンス削除
- 短期的な目的
- 検索
- 中期的な目的
- 障害切り分け
- 中期的な目的
- 可視化
- 長期的な目的
- アクセス等、トレンド分析
- 長期的な目的
- 検知
- CloudWatch Logs Metric Fileterと連携
- 例、ログイン失敗n回でメール
- CLIで設定
- 監視項目例？
- CloudWatchアラームCloudFormationテンプレートあります
- 10個くらいの監視項目
- (中期)AWS CloudTrail API Activity Lookup
- 直近7日間
- CloudWatchと項目は若干異なる
- (長期)Amazon CloudSearch
- S3バケットを検索
- ElasticSearch, Kibana, Amazon Lambda
- CloudTrail -> S3 -> Lambda -> Logstash ElasticSearch => kibana
- Splunk App for AWS
- CSV等なんでも
- アドホッククエリ
構成管理
- AWS Config
- 構成変更 -> 記録 -> 変更・更新
- ->ヒストリ
- ->スナップショット
- aws configseviec ...
- リレーションを一括取得できる -> 差分検出できる
- -> 障害影響範囲分析できる
- -> 辺境影響事前調査できる
- aws configseviec deliver-config-snapshot...
- hh
ss時点での情報取得 - Logstorageによる可視化
- snapshotを元に構成図を作成
- hh
- 構成変更 -> 記録 -> 変更・更新
まとめ
- モニタリング
- CloudWatch
- インフラ監視
- Cloudtrail
[TA-10]AWS セキュアデザイン (IAM)
AWSのセキュリティ
- セキュリティ、コンプラ、ガバナンス、監視に関するアップデートが近年増加
- AWSのセキュリティ・コンプライアンス方針
- 最優先項目
- 継続的な投資
- 専門部隊の設置
- 責任共有モデルの採用
- サービス提供者、利用者の2者で確保
- お客様
- アプリケーション,コンテンツ
- NW-SEC,OS-SEC,Data-SEC,ACL
- AWS
- コンピュート、ストレージ、データベース、NW
- お客様
- サービス提供者、利用者の2者で確保
- 須臾な規制/標準/ベストプラクティスに準拠
- ISO27001, ISO9001, etc...
- DC物理監査等は古い -> 監査の観点を変えて欲しい
- FISC対応
- AWS,SI/ISVが共同調査、公開
- ホワイトペーパーの統制を確認可能
- AWSリスクとコンプライアンス
- (ry
- AWSを活用する歳のセキュリティ対策/監査のポイント
- OS以上は従来どおり
- データそのものはお客様管理
- AWSより下は第三者認証
- セキュリティツール・機能
- ネットワークセキュリティ
- Security-group
- Network Access Control List
- S3 VPCエンドポイント
- サーバ(OS)セキュリティ
- 従来どおり
- MarketPlaceのツールを活用
- WAF,FW,etc...
- WAFのプールを作ってLBするなど
- データセキュリティ
- データの分類(機密度、漏洩した際の損害額9
- すべての暗号化NG
- 暗号化鍵の管理(場所)
- データの削除
- データの分類(機密度、漏洩した際の損害額9
- 暗号化
- CloudHSMを用いた暗号化
- AWS Key Management Service
- ユーザによる暗号鍵の持ち込み
- S3,EBSに実装されたAWSによる暗号化(AWSによる鍵管理)
- Nasdaqデータ分析基盤の暗号化事例
- ユーザが鍵を管理
- オンプレミスにHSMを構築
- 暗号鍵をHSMで管理
- S3上のデータの暗号化
- EMR利用時のみ復号化
- ユーザが鍵を管理
- ネットワークセキュリティ
- アクセスコントロール
- 誰が、いつ、何のために、何をという観点でアクセス制御が可能
- AWSクラウドへのアクセスを完全に制御するためのMFAデバイス
- ActiveDirectryとの連携によるサイオンも可能
IAM(アカウント管理)
- AWS Identity & Access Management(IAM)サービスインタフェース)
- コンソール
- CLI
- 他のサービス
- IAMをサポートするサービス
- アクションレベルの権限 AWS Supportを除く全てのサービスでサポート
- リソースレベルの権限
- IAM Top10のベストプラクティス
- AWSアカウントのアクセスキーをロック
- 全てのリソースにアクセス可能である
- 万が一流出した際のリスクが大きい
- 個々にIAMユーザを作成
- 貸し借り禁止
- 特権ユーザにMFA
- HWベースSWベース
- HWベースで金庫管理など
- トークン型/カード型
- なりすまし防止
- IAMグループで管理
- 運用が楽
- 強度の高いパスワードポリシーの利用
- AWSアカウントのアクセスキーをロック
- 大規模な組織でマネジメントコンソールアカウント管理を効率化するには？
- Active Directry連携
- IAMのSAML連携、ADFSの使用
- 既存のユーザを利用
- ADのグループとIAMロールを対応付け
- 開発、本番、監査
- AWS-Test - ADFS-Test
- AWS-Production -
- AWS-...
- 開発、本番、監査
- ADFSログインページをイントラ内に
- ADFS側の要求規則の変種
- "AWS-"の変換ルールなど
- メリット
- アカウント管理が統合されリスクが低減
- 既存のユーザ情報をそのまま利用
- 既存の権限ベース
- (ry
- Active Directry連携
- EC2のIAMロールの利用
- メリット
- EC2上のアクセスキーの管理が容易
- (ry
- IAMポリシー
- アクセス条件の記述
- 基本パラメータは4つ
- Effect
- Action
- Resource
- Condition
- 基本パラメータは4つ
- 新機能 IAM Policy Validator
- チェック
- 整形
- 新機能 IAM Policy Simulator
- アクセスコントロールポリシーをテスト
- メリット
- web アイデンティティ
- STSを使用
- 監査
- IAM認証情報レポート
- アクセスキーのローテーション
- AWS CloudTrail
- AWS Config
- Aws CloudWatch
- パスワードローテーション
- アクセスキーのローテーション
- AWS環境の操作ログの取得について
- 有効化推奨
- リージョン単位
- CloudTrail
- AWS Config
- AWS Trusted Advisorによる確認
- AWS Support契約が必要
- セキュリティ全体のチェックが可能
[TA-11]AWS クラウドを活用した IoT / M2M ソリューション
はじめに
- IoT/M2Mとは
- デバイスからのデータ、AWSで何ができるか？
- IoT市場の規模
- 2020-26B
- IDC-J国内規模
- 9兆
- 2019-16兆
- 様々なマーケットで利用可能
- 製造
- 交通
- エネルギー
- 家電
- ヘルスケア
- 農業
- Amazonでの取り組み
- Amazon Drone
- Amazon echo
- Amazon Dash
- あきんどスシロー様
- 寿司皿センサ -> Kinesis -> Redshift -> Tabluew
- JMAS様
- O2O(Online to Offline)
- 設備管理や点検
- 出勤、受付、予約
- O2O(Online to Offline)
- ネビラボ様
- センサーデバイスとセット販売
- 14種類のプラがブルセンサ -> MQTT
- Ripplation様
- クロスプラットフォームデータ収集
- GRASSLAND
- ゲームログ収集 -> 様々なデータ
- クロスプラットフォームデータ収集
- イベント会場での騒音チェック
- Kinesis -> Lambda -> kintone
なぜ、AWS?
- 安く初めて、スケール可能
- グローバル展開
- 製造業など海外利用
- 40を超えるサービスを利用可能
IoT/M2Mで利用されるサービス
- レイヤリング
- デバイスインタフェース
- イベントドリブンプロセス、データ処理
- アプリケーションレイヤ、分析系プロセス
- デバイス管理
- IoT/M2Mゲートウェイ
- AWSとの間におおくの場合ゲートウェイを挟む
- ゲートウェイが、データ集約、フィルタ、データ伝送、インタラクション処理も賄うケースもある
- スマホがゲートウェイとなるケースもある
- MQTTプロトコル
- LightWaightなプロトコル
- Pub/Subモデル
- MQTTブローカーでブリッジして他のサービス連携するアーキテクチャ
データ、イベントプロセシング
- データフローとAWSサービスのマッピング
- 収集
- S3
- Kinesis
- 処理
- Lambda
- EMR
- 分析
- Redshift
- 収集
-
データ収集
- ファイル
- media, logfiles
- =>S3
- 基本領域
- =>S3
- media, logfiles
- ストリーム
- センサーデータ(テレメトリ)
- =>Kines
- 低レイテンシでデータ保存(バッファ)
- 3つのAZコピー
- プラガブルアーキテクチャ
- (例)後方にサービスを追加できる
- KCLでアプリはアクセス
- 新リリース
- 50KB単価=>25KB単価(値下げ)
- MAX1MB
- =>DynamoDB
- 容量制限無し
- KVS
- DynamoDB Strems
- センサーデータの投入トリガーで処理が可能になる
- =>Kines
- センサーデータ(テレメトリ)
- トランザクション
- DB
- =>
- DB
- ファイル
-
データ処理
- AWS Lambda
- イベントドリブン処理
- クラウドファンクション(JS) Node.js
- 自動スケール
- IoT/M2Mでの利用パターン
- Notificationの送信
- ライト点灯指示
- AWS Lambda
-
データ分析
- Amazon Redshift
- フルマネージドのDWH
- 従来のBIツールが利用可能
- 最大2PB
- EMR
- フルマネージドなHdoop
- Bootstrap Action
- 構築時にインストール可能
- Spak
- presto
- など11種類
- 構築時にインストール可能
- 他のサービス連携
- Kinesis, S3, DyanmoDB
- HiveやPigで直接アクセス
- Create Table でKinesを指定する
- Amazon Redshift
-
データ可視化
- 分析方法策定の流れ
- ビジネスの目的
- KPI策定
- 施策策定
- 。。
- テストシミュレーション
- ダベンポートによる文政の分類
- 過去、現在、未来
- AWSでのBigDataソリューション
- 時間タイミング、データ形状で分類する
- ストリーム
- Kiness,Lambda
- Apache Spark
- オンメモリ高速処理
- RDDを用いた反復処理
- Spark SQL, Spark Streaming etc...
- トランザクション
- DynamoDB
- ファイルアップロード
- S3 ### まとめ
- ストリーム
- 時間タイミング、データ形状で分類する
- 分析方法策定の流れ
IoT/M2Mのシステム構築においてAWSは低コスト、スケーラブル
データ形状、データ特性、クエリ特性で最適なサービスを組み合わせる
[TA-12]新サービス解説セッション ~ Amazon Elastic File System と Amazon Machine Learning ~
AWSストレージのポートフォリオ
- S3
- HTTPベースのAPIでアクセス
- EBS
- SANのようなブロックストレージ
- Glacia
- 低コスト
[NEW]ELASTIC File System
- NFS v4
- Linuxでマウントして使う
- VPC内のマウントターゲットがNFSの接続先
- ユースケース
- コンテンツのリポジトリ(共有ストレージ)
- AutoScalingするサーバ郡でユーザデータを教諭
- ビックデータ/HPC
- コンテンツのリポジトリ(共有ストレージ)
特徴
- シンプル
- フルマネージド型
- 管理不要
- 数秒で利用可能
- 課金シンプル
- 保存した容量にお応じて
- NFSなので(ry
- フルマネージド型
- 柔軟・スケール
- 容量は自動で拡張・縮小
- 性能も容量に応じてスケール
- 小容量でもバースト
- SSDベース
- 数千の同時接続可能
- 高耐久性・高可用性
- 複数のAZ複製
- 複数のAZから同時に読み書き可
利用イメージ
- コンソール
- VPC選択
- マウントターゲット定義
- タグつけ
- 使う側
- mountするだけ
パフォーマンス
- 1TBの時100MB/s
1TB以上では毎日12時間、ベース性能の倍にバースト可能
-
料金
- $0.30/GB・月
- EFSは利用したストレージ容量のみのお支払い
- コミットメント、前払いなし
-
セキュリティ
- EFS API保護はIAM
- NFSアクセスの保護はマウントぽいと毎に設定できるセキュリティグループで
- ファイルへのアクセス保護はパーミッション、オーナで
-
現時点での仕様や制限
- v4.0(4.1, CIFSだめ)
- TCP 2049
- 推奨クライアントLinux NFSv4
- v4.0だけど未サポートなし
- ロックの機能
- Share denay(Windowsで使われてる)
- ACL
- Kerberos認証
- VPC外からアクセス
-
EBS vs EFS vs S3
- (ry
-
CDP: NFS Shareingパターンが変わる
- 元々の注意点(が不要になる)
- NFSサーバの管理が必要となる
- EC2インスタンスが多くなると
- (ry
- 元々の注意点(が不要になる)
-
スケジュール
- Limited Preview 先週から開始
- リリースは年内(US-East, EU)
Amazon Machine Learning
機械学習とは
- 分析分類
- 遡及的分析
- Redshift
- 即時の判断
- Kinesis
- Lamdba
- スマートアプリケーション(未来を予測9
- Amazon Machine Learning
- 遡及的分析
- 機械学習の例
- 教師あり学習に対応
- 2項分類 スパム判定など
- 過去のメールアーカイブを元に学習
- 多項分類 この商品は、本、日用品、食品のいずれか？
- 数値予測 線形回帰分析 明日の売上はどのくらいになるか？
- その他
- 詐欺の検知
- パーソナライゼーション
- (ry
- スマートアプリケーションが流行らない理由
- 作るためにはいかが必要
- 機械学習に強くて
- R,Python,Hadoopについよい
- 業務知識
- Amazon Machine Learningが解決
- 作るためにはいかが必要
Amazon Machine Learning
- Machine Learning as a Service
- アルゴリズム提供
- パッケージサービスとしての提供
- ワークフローが準備済み
- スケーラビリティ
- マネージド
- 3つの予測モデルとアルゴリズム
- 二項分類
- ロジスティック回帰
- 多クラス分類
- 多項式ロジスティック回帰
- 回帰分析
- 線形回帰
- 二項分類
- 予測手法
- バッチ予測
- S3上にアップロードされた予測対象に対して予測を実施
- リアルタイム予測
- 1件づつAPI呼び出す
- バッチ予測
- 4つのステップ(ワークフロー)
- Data Sourceの作成
- S3, Redshift, RDS for MySQL
- 教師データからモデルを作成
- アルゴリズムは自動選択
- モデルの品質評価
- データ70%でトレーニング、30%で答え合わせ
- 満足できない場合、教師データの見直し等でチューニング
- 実際の予測の実施
- バッチ予測
- リアルタイム予測
- Data Sourceの作成
- 料金について
- データ分析、モデルトレーニング
- $0.42/インスタンス時
- バッチ予測
- $0.10/1000
- リアルタイム予測
- $0.001/API
- データ分析、モデルトレーニング
- 利用について
- リージョン
- 現在us-east-1のみ
- 他リージョンS3利用可
- リージョン
- ユースケース
- 広告の不正クリック検出
- 教師データ：クリックログ
- デモグラ
- デモグラがわかっているユーザの行動ログ
- デモグラに基づいたレコメンデーション
- 教師データ：購入履歴にデモグラ情報がマッピングされたもの
- 顔写真から特定の人物かどうか判定する
- 教師データ：顔写真をグレースケールしたものビットマップ
- 広告の不正クリック検出
- ポイント
- 問題をどう解析に落としこむかが重要
アーキテクチャへの組み込み
- EMRを使用したバッチ予測
- S3のCSVデータソース
- Redshiftを使ったバッチ予測
- データ・ソース
- アプリケーションでSDK Realtime APIを利用
- 既存データフローに予測を追加
- DynamoDB -> Lambdaファンクションで
まとめ
- 機械学書を容易に
- S3やRedshiftのデータ利用が簡単