0Pricing
Elixir & Phoenix: Scalable Backend Development · 강의

고급 감독 전략

`:one_for_one`을 넘어 다양한 감독 전략을 살펴보고 견고하고 장애를 허용하는 시스템을 설계합니다.

고급 감독 전략은(는) CoddyKit의 무료 Elixir & Phoenix: Scalable Backend Development 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Elixir & Phoenix: Scalable Backend Development 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Elixir & Phoenix: Scalable Backend Development 강의에는 총 4개의 강의가 포함되어 있습니다.

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

Beyond Basic Supervision

In Elixir, supervisors are key to building fault-tolerant applications. You've likely encountered the default :one_for_one strategy.

This strategy restarts only the crashing child process. But what if processes are tightly coupled or have dependencies?

Elixir offers more advanced supervision strategies to handle complex failure scenarios, ensuring your application remains robust.

Strategy: One For All

The :one_for_all strategy is powerful for tightly coupled processes.

  • What it does: If any child process dies, all other child processes are terminated and then all children are restarted.
  • When to use it: Ideal when child processes are interdependent and cannot function correctly if one of them fails. Think of a group of processes that must always be in a consistent state together.

It ensures the entire group is always fresh and consistent after a failure.

One For All in Action

Let's see :one_for_all with two workers. If Worker 1 crashes, both Worker 1 and Worker 2 will restart.

Notice the output showing both workers terminating and then starting again.

defmodule Main do
  defmodule MyWorker do
    use GenServer

    def start_link(name) do
      GenServer.start_link(__MODULE__, nil, name: name)
    end

    def init(_) do
      IO.puts("Worker #{inspect(self())} started!")
      {:ok, %{}}
    end

    def handle_call(:crash, _from, state) do
      IO.puts("Worker #{inspect(self())} crashing!")
      exit(:boom)
      {:reply, :crashed, state}
    end

    def handle_call(:status, _from, state) do
      {:reply, :ok, state}
    end

    def terminate(reason, _state) do
      IO.puts("Worker #{inspect(self())} terminating due to #{inspect(reason)}!")
    end
  end

  def main() do
    children = [
      {MyWorker, :worker1},
      {MyWorker, :worker2}
    ]

    opts = [strategy: :one_for_all, name: MyOFA_Supervisor]
    {:ok, _pid} = Supervisor.start_link(children, opts)

    Process.sleep(100)

    IO.puts("\n--- Initial state ---")
    GenServer.call(:worker1, :status, 100)
    GenServer.call(:worker2, :status, 100)

    IO.puts("\n--- Crashing Worker 1 ---")
    try do
      GenServer.call(:worker1, :crash, 100)
    rescue
      _ -> IO.puts("Worker 1 process exited.")
    end

    Process.sleep(500)

    IO.puts("\n--- After crash and restart ---")
    GenServer.call(:worker1, :status, 100)
    GenServer.call(:worker2, :status, 100)

    :ok
  end
end

Main.main()

Strategy: Rest For One

The :rest_for_one strategy is useful for processes with a linear dependency chain.

  • What it does: If a child process dies, it and all subsequent (later started) child processes are terminated and then restarted. Processes started before the crashing child are left untouched.
  • When to use it: Use this when processes have a cascading dependency. For example, if Process C depends on Process B, and Process B depends on Process A. If B crashes, C must also restart, but A is fine.

It's a more surgical restart than :one_for_all.

Rest For One in Action

Here, we have three workers. If Worker 2 crashes, Worker 2 and Worker 3 will restart, but Worker 1 will remain unaffected.

Observe how only the affected and dependent processes are restarted.

defmodule Main do
  defmodule MyWorker do
    use GenServer

    def start_link(name) do
      GenServer.start_link(__MODULE__, nil, name: name)
    end

    def init(_) do
      IO.puts("Worker #{inspect(self())} started!")
      {:ok, %{}}
    end

    def handle_call(:crash, _from, state) do
      IO.puts("Worker #{inspect(self())} crashing!")
      exit(:boom)
      {:reply, :crashed, state}
    end

    def handle_call(:status, _from, state) do
      {:reply, :ok, state}
    end

    def terminate(reason, _state) do
      IO.puts("Worker #{inspect(self())} terminating due to #{inspect(reason)}!")
    end
  end

  def main() do
    children = [
      {MyWorker, :worker1},
      {MyWorker, :worker2},
      {MyWorker, :worker3}
    ]

    opts = [strategy: :rest_for_one, name: MyRFO_Supervisor]
    {:ok, _pid} = Supervisor.start_link(children, opts)

    Process.sleep(100)

    IO.puts("\n--- Initial state ---")
    GenServer.call(:worker1, :status, 100)
    GenServer.call(:worker2, :status, 100)
    GenServer.call(:worker3, :status, 100)

    IO.puts("\n--- Crashing Worker 2 ---")
    try do
      GenServer.call(:worker2, :crash, 100)
    rescue
      _ -> IO.puts("Worker 2 process exited.")
    end

    Process.sleep(500)

    IO.puts("\n--- After crash and restart ---")
    GenServer.call(:worker1, :status, 100)
    GenServer.call(:worker2, :status, 100)
    GenServer.call(:worker3, :status, 100)

    :ok
  end
end

Main.main()

Supervisor Restart Intensity

Supervisors also come with options to prevent endless restart loops, which can consume system resources.

  • :max_restarts: The maximum number of times a child process (or group of processes, depending on strategy) can be restarted within a given time frame.
  • :max_seconds: The time frame (in seconds) during which :max_restarts is counted.

If the restart count exceeds :max_restarts within :max_seconds, the supervisor itself will terminate, potentially crashing its own supervisor.

Restart Intensity Example

Here, we set max_restarts: 2 and max_seconds: 5. If Worker 1 crashes more than twice within 5 seconds, the supervisor will give up and crash itself.

Run this code multiple times and observe the supervisor terminating.

defmodule Main do
  defmodule MyWorker do
    use GenServer

    def start_link(name) do
      GenServer.start_link(__MODULE__, nil, name: name)
    end

    def init(_) do
      IO.puts("Worker #{inspect(self())} started!")
      {:ok, %{}}
    end

    def handle_call(:crash, _from, state) do
      IO.puts("Worker #{inspect(self())} crashing!")
      exit(:boom)
      {:reply, :crashed, state}
    end

    def handle_call(:status, _from, state) do
      {:reply, :ok, state}
    end

    def terminate(reason, _state) do
      IO.puts("Worker #{inspect(self())} terminating due to #{inspect(reason)}!")
    end
  end

  def main() do
    children = [
      {MyWorker, :worker1}
    ]

    opts = [strategy: :one_for_one, name: MyIntensitySupervisor,
            max_restarts: 2, max_seconds: 5]
    {:ok, sup_pid} = Supervisor.start_link(children, opts)

    Process.sleep(100)

    IO.puts("\n--- Crashing Worker 1 repeatedly ---")
    Enum.each(1..3, fn i ->
      IO.puts("Attempt #{i}:")
      try do
        GenServer.call(:worker1, :crash, 100)
      rescue
        _ -> IO.puts("Worker 1 process exited.")
      end
      Process.sleep(100) # Short delay between crashes
    end)

    Process.sleep(1000) # Give supervisor time to react

    IO.puts("\n--- Supervisor status ---")
    if Process.is_alive(sup_pid) do
      IO.puts("Supervisor is still alive.")
    else
      IO.puts("Supervisor has terminated due to excessive restarts.")
    end

    :ok
  end
end

Main.main()

Custom Supervision Strategies

While :one_for_one, :one_for_all, and :rest_for_one cover most cases, Elixir allows for custom supervision strategies.

  • You can implement the Supervisor behaviour yourself.
  • This involves defining init/1 and handling restart logic based on the :which_child argument in handle_call/3.

This is an advanced topic, typically needed for highly specific and complex restart policies not covered by the built-in strategies.

When to Use Which Strategy?

Choosing the right strategy is crucial for your application's resilience.

  • :one_for_one: Default, independent processes. Most common.
  • :one_for_all: Tightly coupled processes where consistency is paramount.
  • :rest_for_one: Processes with linear, cascading dependencies.
  • Custom: Rare, for unique restart requirements.

Always consider the relationships and dependencies between your processes when designing your supervision tree.

Advanced Supervisor Quiz

A critical process P1 provides a service that P2 and P3 absolutely rely on. If P1 crashes, P2 and P3 cannot function correctly and also need to be restarted to ensure data consistency.

Which supervision strategy is best suited for a supervisor overseeing P1, P2, and P3 in this scenario?

Recap: Robust Supervision

You've now explored advanced Elixir supervision strategies that go beyond the default :one_for_one.

  • :one_for_all restarts all children if any child fails.
  • :rest_for_one restarts the failing child and all subsequent children.
  • You also learned about max_restarts and max_seconds to control restart intensity.

These tools allow you to design highly resilient, fault-tolerant applications by precisely controlling how your system reacts to process failures.

자주 묻는 질문

“고급 감독 전략” 강의는 무료인가요?

네 — “고급 감독 전략” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Elixir & Phoenix: Scalable Backend Development 강의 전체를 잠금 해제할 수 있습니다. Elixir & Phoenix: Scalable Backend Development 강의에는 총 4개의 강의가 포함되어 있습니다.

“고급 감독 전략”에서 뭘 배우나요?

`:one_for_one`을 넘어 다양한 감독 전략을 살펴보고 견고하고 장애를 허용하는 시스템을 설계합니다. 브라우저에서 직접 실행하는 실습 코드로 Elixir & Phoenix: Scalable Backend Development을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Elixir & Phoenix: Scalable Backend Development을(를) 시작하는 데 경험이 필요한가요?

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

“고급 감독 전략” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Elixir & Phoenix: Scalable Backend Development 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Elixir & Phoenix: Scalable Backend Development 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 분산 Elixir와 클러스터링
  2. 고급 감독 전략
  3. 동적 감독자와 레지스트리
  4. GenStage와 백프레셔 파이프라인
← Elixir & Phoenix: Scalable Backend Development(으)로 돌아가기