Contenu connexe
Similaire à running web app on elixir (20)
Plus de 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