Erlang OTP: Distributed & Fault-Tolerant Systems Programming · レッスン

ホットコードローディングとアップグレード

Erlang独自のホットコードローディング機能を学び、稼働中のシステムを中断せずにライブアップグレードする方法を実践します。

「ホットコードローディングとアップグレード」はCoddyKit上の無料Erlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはErlang OTP: Distributed & Fault-Tolerant Systems Programming学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

What is Hot Code Loading?

Erlang's hot code loading is a standout feature! It lets you update a running application's code without stopping it. Imagine changing parts of a website's backend while it's actively serving users, without any downtime!

This capability is crucial for systems that need to run continuously, like telecommunications switches or large-scale distributed services. It ensures maximum uptime and service availability.

How Erlang Manages Code

The Erlang Virtual Machine (BEAM) manages code modules in a unique way. For each module, it can keep two versions loaded in memory: an 'old' version and a 'new' version.

When a process starts, it runs the 'new' version of the code.
If you reload a module, new calls to its functions will use the very latest 'new' version.
However, existing processes continue to execute the code they were loaded with until they make a call to a function in the *reloaded* module or are explicitly told to change.

Simple Module Reloading

You can interactively reload a module in the Erlang shell. The l(Module) function (short for 'load') compiles and loads the latest version of a module from the code path.

Let's see a quick example. We'll define a simple math module, then change a function and reload it.

Module Reload Demo

First, create my_math.erl:

Then, in the Erlang shell, compile it with c(my_math). Call my_math:add(1, 2). Now, *change* the add/2 function in the file to X + Y + 10. Save. Run l(my_math) and call my_math:add(1, 2) again. Notice the new result!

-module(my_math).
-export([add/2]).

add(X, Y) -> X + Y.

State Migration Challenge

Simple reloading works for purely functional changes (like our my_math example). But what if a running process, especially an OTP behavior like a GenServer, holds internal state that changes its structure?

If you just reload the code, the running GenServer still holds its old state format. The new code won't know how to interpret it, leading to crashes. We need a way to 'transform' the old state into the new state.

Introducing `code_change/3`

OTP behaviors provide a special callback function called code_change/3. This function is designed precisely for handling state migration during a hot code upgrade.

When you tell a running OTP process to upgrade its code, Erlang will call this function in the *new* version of the module. It's your chance to convert the process's old internal state to the new format.

The `code_change/3` Callback

The signature for code_change in a GenServer looks like this:

code_change(OldVsn, State, Extra) -> {ok, NewState}

OldVsn: The version of the code *being upgraded from*.
State: The current internal state of the process (in the old format).
Extra: Additional arguments, often unused.
You must return {ok, NewState}, where NewState is the transformed state in the new format.

GenServer Upgrade: State Transformation

Let's imagine a GenServer that stores a simple counter as an integer. We want to upgrade it to store the counter as a map #{value => integer()}.

The code_change/3 function will receive the old integer state and return a new map state. This ensures the GenServer continues running smoothly with the updated code and state structure.

GenServer `code_change/3` Example

Here's a simplified example of how code_change/3 would look in my_counter_v2. If our old state was just an integer (e.g., 10), and our new state needs to be #{value => 10}, the conversion is straightforward:

This transformation is key to seamless upgrades.

-module(my_counter_v2).
-behaviour(gen_server).

-export([start_link/0, get_count/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, 
         terminate/2, code_change/3]).

start_link() -> gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

get_count() -> gen_server:call(?MODULE, get_count).

init([]) -> {ok, #{value => 0}}.

handle_call(get_count, _From, State) -> 
    {reply, maps:get(value, State), State};
handle_call(_Request, _From, State) -> 
    {reply, not_understood, State}.

handle_cast(_Msg, State) -> {noreply, State}.

handle_info(_Info, State) -> {noreply, State}.

terminate(_Reason, _State) -> ok.

code_change(_OldVsn, OldState, _Extra) when is_integer(OldState) -> 
    io:format("~p: Upgrading state from ~p~n", [?MODULE, OldState]),
    {ok, #{value => OldState}};
code_change(_OldVsn, State, _Extra) -> 
    io:format("~p: No upgrade needed for state ~p~n", [?MODULE, State]),
    {ok, State}.

Upgrade Best Practices

Hot code loading is powerful, but requires careful planning:

Test Thoroughly: Always test your upgrade paths in a staging environment before deploying to production.
Backward Compatibility: Design code_change/3 to handle multiple previous versions if necessary.
Small, Incremental Changes: Avoid massive changes in state structure in a single upgrade. Break them into smaller, manageable steps.
Release Handling: In production, hot code upgrades are typically managed by 'release handlers' (like release_handler in OTP applications), which automate the process of loading new code and coordinating state changes across multiple processes and nodes.

Quick Check: Hot Code Loading

You've learned about Erlang's hot code loading and how it handles state changes. Which of the following statements about Erlang's code_change/3 callback are TRUE?

Recap: Live Upgrades

In this lesson, we explored Erlang's powerful hot code loading feature, which allows applications to be upgraded without downtime. We learned:

Erlang can keep 'old' and 'new' versions of modules loaded.
Simple code changes can be reloaded with l(Module).
For stateful processes like GenServers, the code_change/3 callback is essential for transforming a process's internal state when the code structure changes.
Careful planning and testing are vital for successful hot code upgrades.

This unique capability is a cornerstone of Erlang's fault-tolerant and highly available systems!

よくある質問

「ホットコードローディングとアップグレード」レッスンは無料ですか？

はい。「ホットコードローディングとアップグレード」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

「ホットコードローディングとアップグレード」で何を学びますか？

Erlang独自のホットコードローディング機能を学び、稼働中のシステムを中断せずにライブアップグレードする方法を実践します。ブラウザで直接実行するハンズオンコードでErlang OTP: Distributed & Fault-Tolerant Systems Programmingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Erlang OTP: Distributed & Fault-Tolerant Systems Programmingを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのErlang OTP: Distributed & Fault-Tolerant Systems Programmingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「ホットコードローディングとアップグレード」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンでコードを書いて実行できますか？

はい。すべてのErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Erlang OTP: Distributed & Fault-Tolerant Systems Programmingに戻る