More Related Content
Similar to running web app on elixir
Similar to running web app on elixir (20)
More from Tsunenori Oohara
More from Tsunenori Oohara (12)
running web app on elixir
- 3. 自己紹介
• おーはら(@ohrdev)
• 好きなBehaviours: GenEvent
• 寺社仏閣/仏像/写経/丸太収集/VR
• 株式会社ドリコム
– 技術基盤部/広告関連サービス
• Elixirアプリのプロダクション利用は1年半位
– 運用:2, 検証:1, 開発:1,企画検討:1
• tokyo.ex の運営, ElixirMeetUp の企画, 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で実装
- 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
上限到達等のイベント毎
に対象キャッシュをクリア
- 11. インフラ
• AWS
– サーバー:EC2,ELB,ASG
– データ:DynamoDB,ElasticCache,S3
• プロビジョニング
– Ansible,Terraform
• ログ
– Fluentd,S3,BigQuery,TD,sentry,etc
- 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のインスタンス数を変更
- 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