running web app on elixir
•Transferir como PPTX, PDF•
1 gostou•3,777 visualizações
tokyo.ex #2
Recomendados
Mais conteúdo relacionado
Mais procurados
Destaque
Semelhante a running web app on elixir
Semelhante a running web app on elixir (20)
Mais de Tsunenori Oohara
running web app on elixir
- 1. Running web app on elixir 2016/5/23 tokyo.ex #2 おーはら
- 2. Agenda 自己紹介 |> 趣旨 |> サービス |> バージョンアップ |> インフラ |> デプロイ |> ランニング |> まとめ
- 3. 自己紹介 • おーはら(@ohrdev) • 好きなBehaviours: GenEvent • 寺社仏閣/仏像/写経/丸太収集/VR • 株式会社ドリコム – 技術基盤部/広告関連サービス • Elixirアプリのプロダクション利用は1年半位 – 運用:2, 検証:1, 開発:1,企画検討:1 • tokyo.ex の運営, ElixirMeetUp の企画, etc
- 4. 趣旨 • elixirの採用事例は徐々に増えつつあり、開 発/実装周りの情報は徐々に出てきつつあり ますが、運用周りの情報はまだ少ないです • 「どう実装するか」ではなく「どこで使ってる か」「どう運用しているか」についての紹介で す – これが最良な方法では（多分）ありません、今もよ り良い手法を模索中です – 良いアイデアがあれば是非教えて下さい – elixir自体についての話題は少なめです、ごめん
- 5. サービス • DreeVee – 動画広告ネットワーク/広告配信/広告ウォール • 制約/要件 – (配信/APIの)停止は許容できない • 売上にダイレクトに直結する – (ランディングページの)表示スピードが重要 • 売上にダイレクトに直結する – スパイクが予想できない • 広告のキャンペーン,イベント,導線強化,etc • どのタイミングで来るかの予想が難しい
- 6. サービス |> 規模,特徴 • サービス/ユーザー規模 – DAU:50〜60万 – ユーザーの視聴/購入情報：4500万件〜 • 広告毎に以下の上限(広告掲載をリアルタイ ムで落とす必要がある) – 予算/視聴・購入上限/ユーザー属性毎の閾値 • ユーザー毎にどの広告を出すか最適化する – ユーザーの視聴/購入履歴/属性から判定 – 表示毎に掲載広告を判定
- 7. サービス |> キャッシング • Varnishでページキャッシング – ESI(Edge Side Include)で画面要素毎にキャッシュ – ESIを入れ子にして更に子要素もキャッシュ • ESIタグのリストをAPI(elixir)で返却 – <esi:include src=“path/to/rails_partial”/> のリスト – リストはユーザー毎に異なる – 予算上限/視聴完了/etc毎のイベントのタイミング で、対象キャッシュのみクリア(BAN) • キャッシング/クリア条件はvclで実装
- 8. サービス |> 画面構成 ページ毎にキャッシュ 構成要素毎にキャッシュ 構成要素の子要素も さらにキャッシュ <esi:include src=“http://path/to/api”/> <esi:include src=“http://path/to/子要 素”/> <div> <esi:include src=“…”/> <esi:include src=“…”/> … </div>
- 9. サービス |> 画面描画 varnish railselixir http://path/to/web/app/view <esi:include src=“http://api/for/esi/list”> http://api/for/esi/list <esi:include src=“http://path/to/partial1”> <esi:include src=“http://path/to/partial2”> <esi:include src=“http://path/to/partial3”> http://path/to/partial1〜3 cache cache& refresh cache 上限到達等のイベント毎 に対象キャッシュをクリア
- 10. バージョンアップ • 対象 – サーバー(EC2のインスタンス,ASG設定,AMI,etc) – ミドルウェア(Erlang,Elixir,nginx,fluentd,etc) – ライブラリ(hex,git,etc) – ソースコード • 条件 – 無停止で実行できる – ロールバックできる – 検証しながらできる(Not ビッグバン)
- 11. インフラ • AWS – サーバー:EC2,ELB,ASG – データ:DynamoDB,ElasticCache,S3 • プロビジョニング – Ansible,Terraform • ログ – Fluentd,S3,BigQuery,TD,sentry,etc
- 12. インフラ |> AWS構成 internet ・・・・・・ Elastic Load Balancer Auto Scaling Group on-demand instance Spot instance Spot 価格 $xxx Spot 価格 $yyy
- 13. インフラ |> EC2インスタンス ・・・・・ ・・・・・ V0.2 V0.3・・・・・ S3: web app src&libs Centos6.x elixir 1.1.x erlang 18.x Centos6.x elixir 1.2.x erlang 18.x AMI: base image 起動設定起動script Base Image Instance Auto Scaling Group ansible terraform 起動AMI インスタンスタイプ(spec) スポット価格 deploy2 deploy1 インスタンス希望数 スケーリングポリシー
- 14. デプロイ • 基本方針 – インスタンスはイミュータブル(変更しない) – トラフィック状況によって自動でインスタンスを上 げ下げする(作成&deploy/停止される) – deploy時間は多少長くても許容する • Blue Green Deployment (っぽいやつ) – ロードバランサーの切り替えではない – オートスケーリンググループ単位でインスタンス を徐々に入れ替える方式
- 15. デプロイ |> ツール • exrm – MIX_ENV=prod mix release でリリースファイルを 作成 – (インスタンス起動時に実行) • init.dスクリプト(/etc/init.d/elixir) – {APP_PATH}/rel/my_app/bin/my_app (start|stop) を叩く – インスタンス起動時に実行 • mina(+ aws sdk) – 1) ソースをアーカイブしてS3にupload – 2) AutoScalingGroupのインスタンス数を変更
- 16. デプロイ |> インスタンスの起動 v1.2.5 v1.2.4 v1.0.1 v1.0.0 ・・・・・ ・・・・・ S3 AMI 起動トリガー ASGの起動設定 ELB, Spec, スポット価格, etc 1) S3から最新verのソースを取得 2) (MIX_ENV=prod mix release) 3) /etc/init.d/elixir start -./rel/myapp/bin/myapp start 起動script EC2 ELB Health Check Running!
- 17. デプロイ |> インスタンスの更新1 1. AMI,S3のソースコードを更新 2. ASGのインスタンス希望数を2倍に更新 3. ELBのインスタンスの状態が「In Service」にな るまで待つ 4. ASGのインスタンス希望数を元に戻す 5. 古いインスタンスがELBから切り離され、(1.で 更新した状態の)新しいインスタンスのみに なる 6. 古いインスタンスが削除される
- 18. デプロイ |> インスタンス更新2 インスタンス希望数:3 AMI: ver1.2.4 ソース: ver1.1.0 インスタンス希望数:3 AMI: ver1.2.5 ソース: ver1.1.1 インスタンス希望数:6 AMI: ver1.2.5 ソース: ver1.1.1 インスタンス希望数:3 AMI: ver1.2.5 ソース: ver1.1.1 old new old old new new create delete
- 19. デプロイ |> 所感1 • Erlang, Elixir のバージョンアップ等の大きな変 更時の検証がとても楽 – 1台だけ新Verで運用 => 1グループだけきりかえ => 全部きりかえ • インスタンスの切り替えが多いのでEC2ガチャ で稀に当たり(はずれ?)を引く – 1年半で1万インスタンス程をcreate/terminate – 半年に1回位（AWSのお約束？) – ソシャゲガチャのSSRよりは確立が高い(0.03%)
- 20. デプロイ |> 所感2 • デプロイ完了までに時間が掛かるのが課題 – コンテナ等で改善できないか検討中 • 異なるspec/環境で同時に走らせる事ができ るので、チューニングや検証が捗ります – 高いspecの少ないサーバー？ – 低いspecの多いサーバー？ – erlang/elixirのバージョンアップによる改善は？ – etc
- 21. ランニング • ASGの設定でインスタンス数が自動で上り下 がりするので運用がとても楽 • スポットインスタンスを多目に使っているので コスト的にお得感が大きい – 詳しくは「外道父の匠:AWSスポットインスタンスの 神髄 発表資料」 を参照 – http://blog.father.gedow.net/2015/06/18/aws- spot-instance/ – 外道父様、いつもありがとうございます
- 23. おまけ • Elixirのハンズオンイベントを企画しています – もしよろしければ、イベントに関するアンケートを お願いできますでしょうか？ – https://docs.google.com/forms/d/1VCA4cFzxWBR iYRFllGYLNVUFlOEGcUoJEXXCF27WSRs – ※ #beamlangtokyo@twitterでも後ほど告知しま す