1. Hot code upgradeの仕組み
   a. ErlangVMの提供する機能
   b. OTPの提供する機能
2. ACCESSでの運用状況・設計判断について紹介

Hot code upgradeの仕組み

Hot code upgradeとは

• ErlangVMの実行を止めずにコードを更新できる
• Erlang/OTPの強みの1つとされることが多い
• が、あまり情報が出回ってない
  • 実運用してる人はわりと少ないようだ
• 「やめておけ」と言われることが多い(こことか)

Pros

• OSプロセスが生き続けるので、メモリ上のデータ・TCPコネクションなどを維持できる
• Load balancerの向き先などを変更しなくてよい
• ErlangVM再起動などの手段よりも速い
• (なんだかかっこいい)

Cons

• 正しくやるのは難しい
  • コード変更内容に応じて更新時の処理が違う
  • 特にテストをきっちりやるのは困難
    • 変更内容に応じて毎回状況が違う
    • prod環境のプロセス内部状態(厳密には負荷状況も)を再現しなければならない

Module loading

• ErlangVMはmodule単位でコードを管理する
• コンパイラは各moduleのソースコードからbeamファイルを作る
• ErlangVM起動後、beamファイルを読み込んで実行
  • beamファイルの読み込み操作などのAPIが提供されているので、Erlang/Elixirから挙動をプログラミングできる
    • :code, Code, IEx.Helpers

How hot code upgrade works (1)

• ErlangVMは各moduleの中身を2バージョンまで保持する
  • "current"と"old"
• currentとoldのコードはどちらも実行可能
• “新規の”関数呼び出しはcurrentを使う
  • モジュール名を指定せずに同一モジュールの関数を呼ぶ場合(local call)は”新規”ではない

How hot code upgrade works (2)

• 新しいバージョンのmoduleをロードしたとき
  • ロードしたバージョンをcurrentに
  • currentをoldにする
  • oldを捨てる
    • その際oldを実行中のプロセスはbrutal kill
      • stacktraceが残ってれば”実行中”

注意点

• killされないよう、oldからcurrentに切り替わるようにしなければならない
  • 普通にGenServerなどを書いてればだいたい大丈夫
• 一部の操作はoldを消してcurrentだけにしようとする
  • やはりold実行中プロセスがkillされる
  • たとえば:release_handler.make_permanent/1をテキトーに呼ぶと危険

Demo

Demo (1)

• 次のスライドのコードをloop.exなどとして保存
• iexから以下でループ開始
  • > c("loop.ex")
  • > spawn_link(fn -> Loop.loop(0) end)
• コードを書き換えて、再度 > c("loop.ex")を試す

defmodule Loop do
  def loop(n) do
    Enum.each(1..20, fn i ->
      :timer.sleep(1_000)
      IO.inspect({n, i, str(), __MODULE__.str()}) # local and remote call
    end)
    __MODULE__.loop(n + 1) # remote and tail-recursive call
  end

  def str() do
    "str/0 version1" # change this and reload!
  end
end

Demo (2)

• 一度新バージョンのコードを実行しても、callstackが残っていると移行しきれない
• 旧バージョンが完全になくなるのは、loop/1の末尾再帰のとき
  • 末尾再帰がremote callでない場合、oldのままで更新されず、次バージョンのload時にkill
• 移行しきる前に2回loadするとkill

Hot code upgrade and OTP

OTP special processes (GenServerなど)

• module差し替えだけで済まない場合がある
  • プロセスの持つデータの移行
• code_changeの仕組み
  • 更新対象のcallback moduleを使っている全プロセスで処理を中断させる
  • code_change/3 callbackでデータ移行
  • 通常の処理を再開

code_change/3のデメリット

• 一連の挙動はsystem messageのやり取りで実現されている
  • けっこう無駄なやり取りが多い
  • system messageへの応答が通常処理でブロックされうる。5秒タイムアウトで強制kill
  • 一部のライブラリが定義するプロセスでは、system messageをちゃんとhandleしてくれない場合がある
• suspendしている間は処理が滞る
  • 対象プロセス群の内部状態をatomicに更新するが、こんな重量級の仕組みはいらない場合も多い

OTP application/release

• OTP application:
  • beamファイルと設定ファイルからなるパッケージングの単位
  • appupファイル: バージョン更新処理を定義する
    • “code_change/3でデータ移行”もここで指定
• OTP release:
  • 複数のOTP applicationsをErlangVMとセットにしたもの
  • relupファイル: appupファイル群をまとめたもの
  • release単位で更新を適用する方法が定義されている(:release_handler)

release一式を生成するツールたち

• systools: Erlang同梱(詳細不明)
• reltool: Erlang同梱(詳細不明)
• relx: 起動スクリプトもセットで便利、systoolsに依存(使っている)
• exrm: Elixir用、relxベース(一時使っていたが今は使ってない)
• distillery: pure Elixir(使ってない)

ACCESSにおける運用状況

antikytheraについて

• OSSのPaaS framework
• AWSで稼働中
• 社内の各チームがそれぞれOTP applicationを作る
• antikythera coreチームがまとめて運用
• (いろいろしゃべりたいが、時間の都合で略)

自動デプロイ方針

• antikythera本体の更新はreleaseを作って:release_handler.install_release/2で取り込む(hot code upgrade)
• 各チームのOTP appの更新は:release_handler.upgrade_app/2で取り込む(hot code upgrade)
• “ややこしい”更新は特別扱いして、EC2インスタンス入れ替えで適用する
• hot code upgradeの際にはcode_change/3しない
  • updateではなくload_moduleを使う単純なappupを生成するツールを自作

“ややこしい”更新について

• 以下のような更新はgitコミットメッセージに固定文字列を入れておく
  • プロセス内部状態の変更
  • supervision treeの構造変更など、初期化処理の変更
• デプロイの際、変更分のコミットメッセージを見てデプロイ方式を切り替え

code_change/3を使わない理由

• (デメリットについては前述)
• cowboy websocketプロセスがsystem messageに応答しない
  • suspendのためsystem messageが送られると、websocketプロセスがcrashして:init.restart/0になる
• 動作検証が割に合わない
  • 1回きりのcode_change/3のためにテスト書きたくない
    • 更新内容に応じて状況を再現するのもしんどい
  • インスタンス追加なら更新内容に依らず、同じようにクラスタに参加するだけ

code_change/3の代替案

• code_change/3に相当するコードをhandle_*の最初に呼び出してデータ移行することもある
• 単にプロセス内部状態を切り替えるだけ(同じmoduleを使う全プロセスでsyncする必要が無い)ならこれで良い
• ただし以下は問題になりうる
  • 移行処理が何度も呼ばれる。idempotentにして、余計な処理はしない
  • 一度もmessageが来ないプロセスでは移行処理も走らない
• pros/consを比べて、インスタンス入れ替えと使い分ける

hot code upgradeの意義

• インスタンス入れ替えだけでもまあまあOKだが、以下のためなるべくhot code upgradeを使いたい
  • 1日に何十回もデプロイしようと思うと、インスタンス入れ替えは遅すぎる
  • websocket connectionをそのままキープしたい
  • raft_fleetのprocess rebalancingは比較的重いので避けたい

Summary

• hot code upgradeそのものは有用だが、OTPにあまり頼り過ぎると良くない場合もある
  • GenServerばかり書いているとcode_change/3が目立つが、これが役に立つのは限られた状況のみ
• hot code upgradeだけでやろうとせず、インスタンス入れ替え方式にfallbackできるように用意しておくといい