03 June 2015

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
  • 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
  • 負荷推移傾向
    • 規則的にピークが来る
    • ピーク/アイドルで40倍程度の差
    • プッシュ通知をたまにするとそこでトラフィックが増える
  • これをすべてオンデマンド、AutoScaling なしだと 113万円/月 くらい
  • 設計方針
    • web api
      • リクエストに応じて AutoScaling
      • spot は使わない (突然死が許容できない)
    • worker
      • job 数に応じて AutoScaling
      • こっちは spot を使う
      • spot 以外に reserved 1 台を置いておく
      • 突然死のリカバリを考慮しておく
    • 共通
      • spot を使わない場合は極力 reserved
      • 小さめのインスタンスタイプを使って細かく増減させる
        • m3.2xlarge -> m3.large x 4 など
      • 予定されたアクセス増には scheduled action で対応
      • スパイクへの対応は今回は扱わない
  • spot を (超) 優先する とは
    • オンデマンド/reserved より spot を、少し早くスケールアウトさせ、少し遅くスケールインさせる
    • spot が全部落ちた場合は、オンデマンド・reserved でカバーする
      • 今回の場合はジョブの処理量が一時的の落ちる
  • 注意点
    • web api
    • スティッキーにしない。ステートレスに
    • ELB のスケールにも注意
    • worker
      • 仮にspotが全く変えなくても大丈夫な実装にする
      • ELB の health check に頼れないので自前でやる必要がある
    • 共通
      • スケールアウトのトリガーからサービスインまでを極力短くする (2~5分)
        • 時間がかかる初期化は AMI に入れておく
      • 適切な閾値は変わっていくので定期的に見直し
      • インスタンス数、spot 数の上限に注意。緩和申請をだす
  • 具体例
    • web api
      • 詳細は資料で
      • yaml で設定を書いて、自前ツールで反映させている
    • worker
      • 詳しくは資料で
  • パラメータチューニングの要領
    • 詳しくは資料で
  • reserved instance の試算
    • AutoScaling と組み合わせると計算が面倒になる。Billing information とにらめっこするしか無い
  • 期待できる成果
    • https://docs.google.com/spreadsheets/d/1UJt8Em7moosKliTfK5Jfkpa82N_sRcC4gjM0Uu-wUjg/edit?usp=sharing
    • 113 万 - 27 万くらいになった
  • その他のコストカットポイント
    • 各サービスの 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 が提供するアルゴリズム
      • 自分で実装はできない
    • パッケージサービス
      • 必要なワークフローが予め提供されている
    • スケーラビリティ
      • 分散システムの運用を気にしなくて良い
  • アルゴリズム
    • 二項分類
      • ロジスティック回帰
    • 多クラス分類
      • 多項式ロジスティック回帰
    • 回帰分析
      • 線形回帰
  • 予測手法
    • バッチ予測
      • S3 などにアップロードした予測対象データに対して、まとめて予測を実施
    • リアルタイム予測
      • データを 1 件ずつ API でなげて予測を得る
  • ワークフロー
    • 教師データを準備
    • 教師データからモデルを作成
    • モデルの品質評価
      • 作成したモデルに対して、評価用のデータを流して精度を測る
    • 実際の予測の実施
      • バッチ or リアルタイム
  • 料金
    • データ分析・モデルトレーニング・評価
      • $0.42/インスタンス時
    • バッチ予測
      • $0.10/1000
    • リアルタイム予測
      • $0.10/1000
  • リージョン
    • us-east-1 のみ
      • 他のリージョンの s3 も利用できる
  • 解決したい問題をモデルに落としこむのが一番大事
    • 広告の不正クリック検出
      • 過去のクリックログを教師データ
      • 二項分類
    • デモグラ推定
      • デモグラがわかっているユーザーの行動ログを教師データ
      • 多クラス分類
    • デモグラに基づいた推薦
      • 購入履歴にデモグラがマッピングされたものを教師データ
      • 多クラス分類
    • 顔写真から特定の人物かどうかを判定する
      • グレースケールにした画像を教師データ。サイズを統一。(ビットごとの濃度を値とする長いベクトルになる)
      • 二項分類

感想

  • EFS は今のシステムでは使い道がぱっと思いつかないけれど、選択肢として覚えておく
  • Machine Learning は非専門家でも機械学習の導入を簡単にするもので、差別化できるほどの高度なことはできないけれど、たまっているデータをまずは有効活用したいというニーズに答えているもののようだった
    • たしかに、門外漢の自分でもなにかやってみよう (簡単なものならできそう) という気になったので