infoMore than 5 years have passed since last update.
AWS Summit Tokyo 2015 DAY2
Last updated at Posted at 2015-06-03
Official
- slide
- EC2多い時1000台
- Ops7人、90人エンジニア、10日/dayデプロイする
- 世界一巨大なモノリシックなRailsアプリケーション
- 開発しにくい状態の例
- 大量のレガシーコード、技術的負債
- テストがFailしていて、放置されている
- てプロイが属人的で、時間がかかりすぎたり、たまに失敗する
- 開発し易さを保つべき
- サービス開発とは何なのか
- 作っているのは機能ではなく、サービス、ユーザー体験
- 本番データを使って開発するべき
- 本番を同期したDBで開発するメリット
- ユーザーと同等の体験
- 予期せぬデータによるバグに気づきやすい
- 重いクエリに気づきやすい
- 昔はmysqldump。半年に1回。
- 今は、本番DBのslave1台を利用。
- auto increment idが衝突しないように、devではidにoffset値(60000とか大きい数値)を付ける。
- 行ベースレプリケーションしてる
- bin_logが大きくなるので１つDBをかましている
- slave_skip_error = ON
- 本番環境で開発する
- β機能リリース
- 公開範囲の限定する
- サービスの価値はユーザーに使ってもらわないとわからないから
- 作りこむより、速く失敗して気付くべき
- chanko
- 価値が検証されて価値が認められたら取り込む
- ステージング用のサーバは存在するが利用頻度は低い
- テスト
- Cookpadでは、rspec(21000 examples 1800 files) ある
- テストが多いと実行時間が長い、壊れやすい、環境依存などでメンテしにくいとかある
- rrrspec
- フォールトトレラント、いかにしてfailしにくいCIにするか
- rrrspecでは1回failしたら自動で再実行して1回通ればsuccessにするようになっている
- 割れ窓理論・・・CIがテスト失敗したら通知するようになっている
- pendingにさせっぱなしのテストの作者に通知するようになっている
- ビルド時間、通過率、コストなどをメトリクスとして指標
- デプロイに重要な事
- 属人性がないこと
- 正確であること
- ロールバックできること
- 十分に速いこと
- Capistranoではスケール出来ない
-
Mamiya (Selfイベントを利用してる)
- Cookpadでは13秒でデプロイ出来る
- 割れ窓を作らない為には、責任者と指標が必要
- 開発しやすさの価値
- 開発からデプロイまでのサイクルが速ければ、本番環境を使った開発が実現が出来る
- ユーザーと同じ体験の中で開発する
- 開発しやすさに投資する価値は十分ある
- 結果として開発組織もサービスも健全な状態が保てる
- slide
- Gunosyのエンジニア数26名
- 開発の特徴
- 小さい単位ですぐ捨てる
- マイクロサービス的な
- 機能が増え過ぎたら分割
- メンテするよりリプレイス
- サーバへの不要なログインをやめる
- サーバーにログインされて困る事
- 信頼出来ないビルド・デプロイ・・・どこの断面かわからない
- 勝手に加えられる変更・・・パッケージ、crontab
- 以前からChefを使用していたが・・・サーバとレシピに乖離があった。レシピを追随させる必要があった。
- デプロイは信頼出来る必要がある
- 信頼出来ないデプロイ
- 継続的デリバリ
- バージョン管理ツール、CIツール、デプロイツールなどを使えば良いと言うものではない -> フローを作る事が大事。
- Githubを中心とした開発・デプロイフロー
- Mergeボタンに全てを集中させる
- 各ブランチをマージする度に自動でビルド・テスト・デプロイ
- master, develop, feature, releaseというブランチ戦略
- デプロイしたければPullRequestを作る
- Opsworksでもデプロイ履歴が追える
- Pull requestDriven Deploy
- 全ての情報がGihubに集約
- 見える化、ビルドデプロイの効率化、事故の削減
- ワークフローがわかりやすくなった
- 調査の為のログ収集(ミドルウェア、アプリケーションログ)
- slide
- 設計方針
- web-apiはリクエスト数によってオートスケーリング
- web-apiはspotインスタンスは使わない
- workerはJob数に応じてオートスケーリング
- workerはspotインスタンスを優先的に使用する
- spotインスタンスを使用しない場合もReservedインスタンスを適用する
- メッセージ配信とかで負荷が増加したらScheduledActionで対応
- Spotインスタンスを優先する理由
- 少し速くスケールアウトさせ、より遅くスケールインさせる -> Spotが買える限りSpotのみが増減させる状況を作る
- スティッキーにしない
- 急なアクセス増の準備時にはインスタンス数だけでなく、ELBのスケールにも注意。
- 仮にSpotが全く買えなくても、オンデマンドでさばけるようにアプリを設計する
- ELBのヘルスチェックに頼れない
- スケールアウトからサービスインまでの時間を短く（２〜５分）
- 時間がかかる初期化処理はAMIに入れておく
- アプリケーションが刻々と変わるので、Threshuld値をその都度変更する
- SpotInstanceの上限に注意
- 設定はYAMLファイルに書いて適用させていた
- パラメータチューニング要領・・・プレゼン参照
- 期待出来る成果
- コストカット成果シート
- その他のコストカットポイント
- その他のサービスのReservedInstanceを使用してみる
- 高騰しにくいタイプのSpotInstanceを使うと安心
- WorkerにやらせているジョブをLamdaに移行したら安くなったりする
- 今後
- Labdaをフルに使ったらさらなる節約になるかも
- HTTP/2時代にステートレスを前提にしたawsでのスケールはどうなるのか
- Amazon Elastic File System
- NFS(NFSv4)でアクセス出来るストレージ
- コンテンツレポジトリ・ビックデータ/HPCとして利用例
- シンプル、フルマネージド型
- 課金体系は容量課金 $0.3/GB・月(USリージョン)
- 容量は自動的に拡張・縮小
- 性能に応じてスケール
- 数千のNFS同時接続可能
- 複数AZに複製されて保存される
- 複数AZに同時に書き込み可能
- mountコマンドで普通にマウント
- バースト機能あり(1TB以上では毎日12時間、倍にバースト可)
- TCP2049番ポート固定
- LinuxNFSv4クライアントサポート
- ロック,shareDeny,ACL,kerberos認証は現状未サポート
- 同一VPCからのみ接続可能
- EFSがあれば、NFS Sharingパターンが変わる
- Amazon Machine Learning
- 未来、未知を予測する
- スパムメールの判定(教師あり学習)
- 明日の売上はどのくらいになるか(線形回帰分析)
- 機械学習に強くて、R,Python、Hadoop,Spark、ビジネス分野の経験が深い人という採用は難しい -> スマートアプリケーションが解決
- Amazonが提供するアルゴリズムを使用
- パッケージサービスとして提供
- スケーラビリティは気にする必要はない
- 二項分類(ロジスティック回帰)例. このメールはスパム？
- 多クラス分類(多項式ロジスティック回帰)例.これは木、車、食べ物？
- 回帰分析(線形回帰分析)例.明日は水曜日、在庫はいくつくらい必要？
- バッチ予測(S3にアップロードしてバッチで)。
- リアルタイム予測(APIで)。
- 教師用、評価データを準備(S3,Redshift,RDSで)。
- 教師データからモデル(二項分類、多クラス分類、回帰分析)作成
- 作成したモデルに対して評価（評価用のデータを流してみて予測用の制度を測る事）を実施する。
- 制度に満足出来ない場合、教師用のデータのETLや量を再教育する。
- データ分析: $0.42/インスタンス時
- バッチ予測: $0.10/1000
- リアルタイム予測: $0.10/1000
- 現状リージョンはus-east-1のみ、S3は他リージョンでも可能。
- 利用例(広告の不正クリック検出、デモグラ推定、デモグラに基づいたレコメンデーション、顔写真から特定人物かどうか判定(顔写真をグレースケールしてビットマップ化したものを教師データに))
- 問題をどうモデルに落としこむかが大事
Register as a new user and use Qiita more conveniently
- You get articles that match your needs
- You can efficiently read back useful information
- You can use dark theme
What you can do with signing up
