AWS Summit Tokyo 2015 2 日目のメモ
AWS Summit Tokyo 2015｜EventRegist（イベントレジスト） 2 日目のメモです。
ネットワーク Deep Dive
- VPC ベストプラクティス
- AWS Market Place を活用する
- VPC Peering を利用する
- 他企業とのデータ連携
- Security Group で必要な通信だけに限定する
- セキュリティ関連の機能を共通機能として切り出して、アプリの VPC と peering する
- セキュリティチームが proxy やフィルターなどを共通基盤として扱う
- VPC のルーティングとセキュリティ
- ルーティング
- サブネットに割り当てられている route table によって行う。ip レベルの制御
- セキュリティ
- ネットワークACL と セキュリティグループ
- NACL はブラックリスト、セキュリティグループはホワイトリスト
- 禁止して、必要な物だけ許可するが定石
- NACL で禁止して、セキュリティグループで必要なものを許可するのがおすすめ
- VPC のエンドポイント
- private subnet から直接 s3 にアクセスできる
- いままでは public の subnet に NAT インスタンスを置かなくてはいけなかった
- 現在は s3 だけだが、他サービスにも展開予定
- エンドポイントポリシー
- IAM のポリシーのように json で定義
- 特定のバケットだけアクセスを許可、など
- リージョンは超えられない
- peering している先など、外からのアクセスもできない
- DirectConnect ベストプラクティス
- 回線のフェイルオーバーを高速化する
- BFD
- 対向のルータ同士で BFD パケットを送りあって障害検知する
- タイムアウトで検知するよりも高速。ミリ秒単位
- ルーターが BFD に対応している必要がある
- BFD が使えない場合は BGP の設定をチューニングする。keepalive, holdtime を小さい値に
- トラフィック設定
- Active/Standby の構成
- Active/Active の構成
- 占有型と共有型
- ネットワークのコード化
- CloudFormation
- VPC の設定などを json のテンプレートで記述する
- 新規作成のフロー
- json を編集 -> CloudFormation にファイルをロード -> スタックの完成
- すでにある構成をテンプレート化する
- CloudFormer でできる
- aws cli
- cli と python/ruby/java etc の sdk
- 動的な処理もできる
感想
- CloudFormation はちゃんと使いたい感
- DirectConnect の話はついていけなかった
APN Cloud Architecture of the Year 2014 の Top 3 を公開!
- 石田大成社
- 画像処理を今までオンプレでやっていて、サーバを増やすのが大変だった
- spot instance で低コストで実現
- オンプレ環境から VPN 接続、インターネットGW とは接続せず、public ip も一切振らない
- マネージメントコンソールはできることが多すぎたので、必要な機能だけに絞った UI を作って、社内に開放した
- HANDS LAB
- ショッピングセンター向けポイントシステム
- システムの内製化をすすめていた
- エクセルとか Access は使えるけども、というレベルのメンバーが多い
- そのため ユニケージ開発手法 をとっていた
- プレーンテキストを DB にしてシェルでロジックを書く
- ハンズラボが採用しているユニケージという謎テクノロジーについて 第1回 | HANDSLAB エンジニアブログ
- ユニケージのコードベースのままスケールさせるには、S3 を DB として使うのがよかった (一般的にはアンチパターンだけど)
- ユニケージのファイルの置き場所がローカルから S3 に変わっただけで移行できた
- 最近は普通に DynamoDB とか使っている
- classmethod
- 「紅白歌合戦」にもAWS 「毎秒数十万」デバイスにメッセージを同時配信 - ITmedia エンタープライズ の話
- あらゆるものの冗長化
- 構成の自動化
- CloudFormation
- 開発・ステージングやリージョンを問わず、全く同じ環境を作る
- 最後に packer + ansible で AMI 作成
- とにかくたくさん並べる
- 壊れたら切り離す。リージョンごと壊れたら DNS でそこを切り離すなど
- 当日
- 障害が起こっても原因調査をしない。すぐに捨てる
- ビッグスタート
- c3.xlarge 1000 台を 3 時間あげても10万円
- ログはとっておく
- fluentd で
- 2 年目は CloudFormation 使い回しで構築時間、コストは数分の一になった
感想
- ユニケージ開発手法は驚きでした
【デベロッパー向け】 サーバにログインしない・させないサービス運用
- gnousy
- ニュース配信
- 広告配信
- アドネットワーク
- プラットフォーム事業
- エンジニア
- 26 名 + インターンで 30 名ほど
- デザイン + フロント: 3 人
- クライアント + QA: 5人
- Web + API: 5 人
- 広告: 5 人
- 数値解析、コンテンツ: 5人
- インフラ: 1 人
- その他 SM っぽい人
- 言語
- API: golang
- 管理画面: Rails
- バッチ、内部UI: python, Django
- その他
- github
- chef + opsworks
- 特徴
- 小さい単位で作ってすぐ捨てる
- マイクロサービス的な考え方
- 機能が増え過ぎたら分割
- メンテするよりリプレース
- サーバへの不要なログインをやめよう
- デプロイ
- 信頼出来ないデプロイ
- 事故のリスク、手戻りの発生、エンジニアの時間的・精神的な負担
- 継続的デリバリ
- 使えばいいというものではなくて、すべてを統合したワークフローを作ることが大事
- 現在はGithub を中心とした開発・デプロイフロー
- Github, circleci, opsworks
- https://speakerdeck.com/koid/yokuwakaru-aws-opsworks
- merge ボタンにすべてを集中させる
- merge したタイミングで CI (test, build) -> S3 upload -> opsworks で deploy
- deploy したければ pull request を作るというワークフロー
- github にデプロイ履歴が残る
- opsworks にも残る
- 信頼出来ないデプロイ
- ログ調査
- どこかに集約してブラウザなどから確認できるように
- os/middleware ログ収集
- アプリケーションログ収集
- airbrake
- kibana
感想
- 1 クリックで deploy とか、ログインせずにログを確認するとかは確かに便利なんだけど、詳細がよくわからなかった
- さらっとした発表で、3 分の 1 くらい時間が余っていた
Auto Scaling x Spot Instances によるスケーラビリティとコストカット事例
- 想定サービス
- twitter like な自社サービス
- ユーザー数 100万+
- 成長率 110%/month
- システム構成
- web api (ec2)
- Rails
- m3.2xlarge x 8 (常に 8 台)
- worker (ec2)
- rails + resque
- c4.2xlarge
- その他 ELB, RDS, ElasticCache
- web api (ec2)
- 負荷推移傾向
- 規則的にピークが来る
- ピーク/アイドルで40倍程度の差
- プッシュ通知をたまにするとそこでトラフィックが増える
- これをすべてオンデマンド、AutoScaling なしだと 113万円/月 くらい
- 設計方針
- web api
- リクエストに応じて AutoScaling
- spot は使わない (突然死が許容できない)
- worker
- job 数に応じて AutoScaling
- こっちは spot を使う
- spot 以外に reserved 1 台を置いておく
- 突然死のリカバリを考慮しておく
- 共通
- spot を使わない場合は極力 reserved
- 小さめのインスタンスタイプを使って細かく増減させる
m3.2xlarge->m3.large x 4など
- 予定されたアクセス増には scheduled action で対応
- スパイクへの対応は今回は扱わない
- web api
- spot を (超) 優先する とは
- オンデマンド/reserved より spot を、少し早くスケールアウトさせ、少し遅くスケールインさせる
- spot が全部落ちた場合は、オンデマンド・reserved でカバーする
- 今回の場合はジョブの処理量が一時的の落ちる
- 注意点
- web api
- スティッキーにしない。ステートレスに
- ELB のスケールにも注意
- worker
- 仮にspotが全く変えなくても大丈夫な実装にする
- ELB の health check に頼れないので自前でやる必要がある
- 共通
- スケールアウトのトリガーからサービスインまでを極力短くする (2~5分)
- 時間がかかる初期化は AMI に入れておく
- 適切な閾値は変わっていくので定期的に見直し
- インスタンス数、spot 数の上限に注意。緩和申請をだす
- スケールアウトのトリガーからサービスインまでを極力短くする (2~5分)
- 具体例
- web api
- 詳細は資料で
- yaml で設定を書いて、自前ツールで反映させている
- worker
- 詳しくは資料で
- web api
- パラメータチューニングの要領
- 詳しくは資料で
- reserved instance の試算
- AutoScaling と組み合わせると計算が面倒になる。Billing information とにらめっこするしか無い
- 期待できる成果
- その他のコストカットポイント
- 各サービスの reserved を契約
- 高騰しにくいタイプの spot を使う
- 旧世代とか
- worker 系の処理でできるものは lambda にするとかなり安い
- spotfleet api を使うとさらに徹底して低価格を追求でいる
- アプリのチューニングをしてタイプを下げる
- lambda が tokyo region に来るのでさらに倹約アーキテクチャを作りたい
感想
- 細かいパラメータ、パラメータを決める式は資料待ち
- AutoScaling + reserved instance の場合の試算は難しい
- スパイクへの対応の話を聞きたかった
新サービス解説セッション ~ Amazon Elastic File System と Amazon Machine Learning ~
EFS
- aws ストレージのポートフォリオ
- s3
- ebs
- glacier
- efs
- efs とは
- nas のようなサービス
- nfsv4 を利用
- linux からマウントして利用できる
- ユースケース
- コンテンツのリポジトリ
- autoscaling するサーバ群で、ユーザーがアップロードしたファイルを全サーバで共有する
- ビッグデータ/HPC
- コンテンツのリポジトリ
- 特徴
- シンプル
- フルマネージド
- nfs なので既存のアプリ・ツールとシームレス
- 保存された合計容量だけの課金
$0.30/GB・月- reserved, provision なし
- 柔軟・スケーラブル
- 容量は自動的に拡張・縮小
- 性能は容量に応じてスケール
- 容量が少ない時はバースト可能
- SSD ベース
- 高耐久性・高可用性
- 複数AZに複製されて保存
- 複数AZから同時に読み書き可
- シンプル
- セキュリティ
- API の保護は IAM で
- アクセスの保護はセキュリティグループ (マウントポイントごとに設定できる)
- ファイルへのアクセス保護はファイルパーミッション、オーナーで
- 現在は limited preview
- ebs vs efs vs s3
- プロトコル: SCSI/NFS/HTTP API
- 課金: 容量(+性能)/容量/容量+req数
- 耐久性: 1az/複数az/3箇所以上
- nfs sharing パターン (クラウドデザインパターンより)
- この nfs 部分として efs を使うとかなり簡単
- 提供スケジュール
- 申し込むと oregon から順次開始
- us-east, eu は年内
Machine Learning
- サービスのポートフォリオ
- バッチ
- redshift, rds, s3, emr
- リアルタイム
- kinesis, ec2, lambda
- 予測
- ML
- バッチ
- 機械学習の例
- スパムメールの判定
- ML は教師あり学習にだけいまのところ対応している
- 多クラス分類
- 売上予測 (線形回帰)
- スパムメールの判定
- スマートアプリケーションを作るには
- 機械学習に強くて、R, Python や Hadoop, Spark に明るくて、特定ビジネスドメインの経験が深い
- これを満たすのは難しい
- ML は開発者でもこれらができるようにするためのマネージドサービス
- Machine Learning as a service
- amazon が提供するアルゴリズム
- 自分で実装はできない
- パッケージサービス
- 必要なワークフローが予め提供されている
- スケーラビリティ
- 分散システムの運用を気にしなくて良い
- amazon が提供するアルゴリズム
- アルゴリズム
- 二項分類
- ロジスティック回帰
- 多クラス分類
- 多項式ロジスティック回帰
- 回帰分析
- 線形回帰
- 二項分類
- 予測手法
- バッチ予測
- S3 などにアップロードした予測対象データに対して、まとめて予測を実施
- リアルタイム予測
- データを 1 件ずつ API でなげて予測を得る
- バッチ予測
- ワークフロー
- 教師データを準備
- 教師データからモデルを作成
- モデルの品質評価
- 作成したモデルに対して、評価用のデータを流して精度を測る
- 実際の予測の実施
- バッチ or リアルタイム
- 料金
- データ分析・モデルトレーニング・評価
$0.42/インスタンス時
- バッチ予測
$0.10/1000
- リアルタイム予測
$0.10/1000
- データ分析・モデルトレーニング・評価
- リージョン
us-east-1のみ- 他のリージョンの s3 も利用できる
- 解決したい問題をモデルに落としこむのが一番大事
- 広告の不正クリック検出
- 過去のクリックログを教師データ
- 二項分類
- デモグラ推定
- デモグラがわかっているユーザーの行動ログを教師データ
- 多クラス分類
- デモグラに基づいた推薦
- 購入履歴にデモグラがマッピングされたものを教師データ
- 多クラス分類
- 顔写真から特定の人物かどうかを判定する
- グレースケールにした画像を教師データ。サイズを統一。(ビットごとの濃度を値とする長いベクトルになる)
- 二項分類
- 広告の不正クリック検出
感想
- EFS は今のシステムでは使い道がぱっと思いつかないけれど、選択肢として覚えておく
- Machine Learning は非専門家でも機械学習の導入を簡単にするもので、差別化できるほどの高度なことはできないけれど、たまっているデータをまずは有効活用したいというニーズに答えているもののようだった
- たしかに、門外漢の自分でもなにかやってみよう (簡単なものならできそう) という気になったので