Erlang OTP: Distributed & Fault-Tolerant Systems Programming · 강의

Erlang OTP 사례 연구

대규모 Erlang OTP 배포의 실제 사례와 모범 사례를 분석하고, 업계의 성공 사례에서 배웁니다.

Erlang OTP 사례 연구은(는) CoddyKit의 무료 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Erlang OTP: Distributed & Fault-Tolerant Systems Programming 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Learning from Erlang's Giants

Why is Erlang chosen for mission-critical systems? Its unique strengths – concurrency, fault tolerance, and distribution – make it ideal for applications needing near-perfect uptime.

Today, we'll explore how major real-world projects leverage these Erlang/OTP features to build highly robust and scalable systems.

Ericsson AXD 301: Telecom Reliability

Ericsson's AXD 301, a massive ATM switch, was one of Erlang's earliest and most famous success stories. It achieved "five nines" (99.999%) availability, meaning less than 5 minutes of downtime per year.

This incredible reliability was largely due to Erlang's:

Fault Tolerance: Supervisors automatically restarting failed components.
Hot Code Upgrades: Updating software without service interruption.
Process Isolation: Failures in one part don't bring down the whole system.

Simulating AXD 301's Resilience

The AXD 301's resilience came from processes that could fail and be restarted by supervisors. This tiny example shows a worker that intentionally crashes, and its supervisor immediately restarts it, demonstrating a core Ericsson principle.

-module(crash_demo).
-behaviour(gen_server).
-export([start_link/0, init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).
-export([crash_me/0, main/0]).

%% Worker functions (behaves as a gen_server)
start_link() -> gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
init([]) -> io:format("Worker started!~n"), {ok, nil}.
crash_me() -> gen_server:call(?MODULE, crash).
handle_call(crash, _From, State) -> 
    io:format("Worker intentionally crashing!~n"), 
    exit(i_crashed), %% Simulate a crash
    {reply, ok, State};
handle_call(_Req, _From, State) -> {reply, ok, State}.
handle_cast(_Msg, State) -> {noreply, State}.
handle_info(_Info, State) -> {noreply, State}.
terminate(_Reason, _State) -> io:format("Worker terminating.~n").
code_change(_OldVsn, State, _Extra) -> {ok, State}.

%% Supervisor part (embedded for this demo)
start_supervisor() ->
    supervisor:start_link({local, demo_sup}, ?MODULE, supervisor). %% Pass 'supervisor' as InitArgs

%% This init/1 is for the supervisor behavior callback
init(supervisor) ->
    SupFlags = #{strategy => one_for_one, intensity => 1, period => 5},
    ChildSpecs = [
        #{id => my_worker,
          start => {?MODULE, start_link, []}, %% Start the worker part of this module
          restart => permanent,
          shutdown => 5000,
          type => worker,
          modules => [?MODULE]}
    ],
    {ok, {SupFlags, ChildSpecs}}.

%% Main entry point for runnable
main() ->
    io:format("Starting supervisor and worker...~n"),
    {ok, _SupPid} = start_supervisor(),
    timer:sleep(100), %% Give worker time to start
    io:format("Worker PID before crash: ~p~n", [whereis(?MODULE)]),
    crash_me(), %% Trigger crash of the worker part
    timer:sleep(100), %% Give supervisor time to restart
    io:format("Worker PID after restart: ~p~n", [whereis(?MODULE)]),
    ok.

WhatsApp: Billions of Messages

WhatsApp handled billions of messages daily with a relatively small engineering team, largely thanks to Erlang. Its architecture efficiently managed massive concurrent user connections by leveraging:

Massive Concurrency: Erlang's lightweight processes (millions per node) allowed handling countless simultaneous users.
Message Passing: Asynchronous message passing between processes mimicked the real-world communication flow.
Distribution: Erlang's built-in distribution enabled seamless scaling across multiple server nodes.

WhatsApp's Core: Simple Messaging

At its heart, WhatsApp is about processes sending messages. This snippet shows two processes communicating, illustrating the fundamental building block of their system.

-module(messenger).
-export([start_sender/1, start_receiver/0, main/0]).

%% Receiver process
start_receiver() ->
    spawn(fun() -> receiver_loop() end).

receiver_loop() ->
    receive
        {message, From, Msg} ->
            io:format("Receiver (~p) got: ~s from ~p~n", [self(), Msg, From]),
            From ! {ack, self()},
            receiver_loop();
        _ ->
            io:format("Receiver got unknown message.~n"),
            receiver_loop()
    end.

%% Sender process
start_sender(ReceiverPid) ->
    spawn(fun() -> sender_loop(ReceiverPid) end).

sender_loop(ReceiverPid) ->
    Msg = "Hello from sender!",
    io:format("Sender (~p) sending '~s' to ~p~n", [self(), Msg, ReceiverPid]),
    ReceiverPid ! {message, self(), Msg},
    receive
        {ack, _Receiver} ->
            io:format("Sender (~p) received acknowledgement.~n", [self()]);
        _ ->
            io:format("Sender got unexpected reply.~n")
    end,
    timer:sleep(100),
    ok. %% Only send one message for this demo

%% Main entry point for runnable
main() ->
    io:format("Starting messaging demo...~n"),
    Receiver = start_receiver(),
    timer:sleep(50), %% Give receiver a moment to start
    Sender = start_sender(Receiver),
    io:format("Sender PID: ~p, Receiver PID: ~p~n", [Sender, Receiver]),
    timer:sleep(500), %% Allow messages to exchange
    ok.

RabbitMQ: Reliable Message Queues

RabbitMQ, a widely used open-source message broker, relies heavily on Erlang/OTP for its robustness and scalability. It provides critical features such as:

Reliability: Persistent message queues ensure messages aren't lost even if the server crashes.
Clustering: Multiple RabbitMQ nodes can form a cluster, sharing queues and data, thanks to Erlang's distribution.
Fault Tolerance: Supervisors manage internal components, ensuring continuous operation and automatic recovery.

Best Practice: Embrace 'Crash First'

A key takeaway from these case studies is Erlang's "crash first" philosophy. Instead of trying to prevent every error, systems are designed to crash cleanly and be restarted by a supervisor. This approach leads to:

Simpler error handling logic.
More robust systems that automatically recover.
Easier identification of root causes through crash reports.

Best Practice: Seamless Hot Upgrades

Another powerful feature utilized in high-availability systems like Ericsson's is hot code loading and upgrades. Erlang allows you to replace running code modules without stopping the application or losing its state.

Essential for systems requiring continuous uptime.
Minimizes maintenance windows.
Enables rapid deployment of fixes and new features.

Best Practice: Scale with Distribution

Erlang's built-in support for distributed computing is fundamental to scaling systems like WhatsApp and RabbitMQ. It allows applications to seamlessly span multiple machines or nodes.

Node Communication: Processes on different machines can communicate as if they were local.
Global Registration: Register process names globally, making them discoverable across the cluster.
Fault Tolerance: Distribute workload and ensure that the failure of one node doesn't bring down the entire system.

Check Your Understanding

Based on the real-world case studies discussed, which of the following are key benefits of using Erlang/OTP for building highly available and scalable systems?

Recap: Learning from Success

We've explored how major projects like Ericsson AXD 301, WhatsApp, and RabbitMQ leverage Erlang/OTP's unique strengths.

Fault tolerance via supervision allows systems to recover automatically from failures.
Hot code upgrades enable continuous service without downtime, crucial for critical systems.
Massive concurrency and distribution are key to scaling applications and building resilient architectures.

These principles are central to designing and building robust, real-world Erlang applications.

자주 묻는 질문

“Erlang OTP 사례 연구” 강의는 무료인가요?

네 — “Erlang OTP 사례 연구” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 강의 전체를 잠금 해제할 수 있습니다. Erlang OTP: Distributed & Fault-Tolerant Systems Programming 강의에는 총 4개의 강의가 포함되어 있습니다.

“Erlang OTP 사례 연구”에서 뭘 배우나요?

대규모 Erlang OTP 배포의 실제 사례와 모범 사례를 분석하고, 업계의 성공 사례에서 배웁니다. 브라우저에서 직접 실행하는 실습 코드로 Erlang OTP: Distributed & Fault-Tolerant Systems Programming을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Erlang OTP: Distributed & Fault-Tolerant Systems Programming을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Erlang OTP: Distributed & Fault-Tolerant Systems Programming은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“Erlang OTP 사례 연구” 강의는 얼마나 걸리나요?

대부분의 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(으)로 돌아가기