ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Process (OTP) 들어가기,
    Elixir 프로그래밍 2022. 7. 12. 13:49

    글의 연재를 다시 시작하긴 하는데, 이전과 같이 꾸준히 올릴수 있을지는 모르겠습니다. 

    아무튼, Process 부터 한참 동안 안쓴 글을 다시 올리겠습니다. 

     

     

    Elixir라는 언어는 문법의 간결성, 함축성 외에

    Process를 통한 분산처리, 장애대응이 가능한 코드의 개발이 큰 장점입니다. 

     

    Elixir 의 기반인 Erlang 은 Ericson 사에서 대규모 네트워크 장비의 개발을 위해 만든 언어입니다.

    통신 중계기의 특성상 높은 안정성, 병렬처리, 분산처리가 가능해야, Erlang은 이런 시스템의 개발이 가능하도록

    만들어진 언어(플랫폼의 성격을 포함한) 입니다. 

     

    Process는 이런 안정성, 병렬처리, 분산처리를 구현하는 중요한 요소이며  , 사실 이를 위해서 함수형 언어가 만들어졌다고 할수 있습니다. 

     

     

    기술내용 보다, 우선 가볍게 다른 얘기를 먼저 해보겠습니다.

     

    "손오공" , 저는 손오공의 가장 큰 능력은 권두운을 타는 재주도, 여의봉도 아니라고 생각합니다.

    제가 생각하는 손오공의 가장 큰 능력은 "분신술" 이라 생각합니다. 

    강한적을 만났을 때, 손오공은 분신술을 이용해서 자신과 똑같은 능력을 가지는 손오공을 여럿 만드는

    분신술을 사용합니다.  이 손오공의 분신은 손오공과 같은 능력을 가지고 있을 뿐더라, 

    만일 분신 손오공이 죽더라도, 원래의 손오공에게는 아무런 해가 끼치지 않습니다. 

    강한적이 나타나면, 원하는 수 만큼의 분신을 만들어서  상대하는 분신술.. 

     

    Elixir 의 Process가 이 손오공의 분신술과 같다고 할 수 있습니다.

     

    Elixir 에서는 PC에서도 몇십만개의 Process를 만들수 있습니다. 

    다음과 같이 iex 에서, observer를 실행시켜보면,  생성할수 있는 Process의 수와 현재 생성된 Process 수를 확인할 수 있습니다.

     

     

    다음은 Elixir(Erlang) Process에 관한 사항입니다.

     

    • Elixir Process는 OS의 Process가 아니며 (Thread도 아니며) , Erlang VM 내의 Process 이다. 
    • Process아주 Light 하며, 실행 스케쥴링의 단위이다. 
    • 모든 Process는 독립적이다. (하나의 Process가 죽는 것은 다른 Process에 아무런 영향을 주지 않는다. )
    • Process 간에 공유되는 것은 없다. 

     

    Process에 대한 내용을 더 하기 전에,  다시 손오공 얘기를 좀더 하겠습니다. 

     

    손오공이 분신술을 사용할 수는 있지만, 만약 손오공 자신만 분신이 되고,  여의봉은 여러개 생기지 않는다면 

    어찌 될가요..?  아마도 분신된 여러 손오공은 여의봉을 사용하기를 기다려야 할거고, 이러면 분신의 큰 의미가 없을 겁니다. 

     

    Erlang에서는 애초에 함수형 언어로 만든 이유가 바로 여기 있습니다.   여러개의 Process를 생성할 수 있고, 

    이들 Process들 간에 공유되는 것이 없으며, 각 Process는 독립적으로 실행이 되는 것이 바로 이런, Shared Resource에 

    대한 Lock 문제가 애초에 발생되지 않도록 하기 위함 입니다.

     

    Java 나 C 같은 다른 언어에서도, 동시성을 구현할 수 있습니다. Thread 를 여러개 생성해서 동시성을 구현할 수 있지만, 

    가장 중요한 부분이 바로 Shared Resource 문제 입니다.  잘 설계되지 못하면,  오히려 Single Thread 보다 느린 Multiple Thread

    프로그램이 될 수 있습니다.  또한, Lock 이 발생할 경우 원인을 찾아서 해결하는 것도 몹시 어렵게됩니다. 

     

    Erlang 은 애초에 이런 Shared Resouce 에 대한 Lock 이 발생하지 않도록 만들었습니다. 

    이게 바로 Process 간에 공유되는 것이 없도록 한 이유입니다.  

     

     

    위의 그림에서와 같이 Erlang 은 1986 언어가 만들어 질때 부터, 동시성에 대한 해결 방안을 다른 식으로 풀어냈습니다. 

    "No Global Variable , Sharing Nothing"   Erlang 에서의 최소단위는 Process이며, 

    이 Process들간에는 공유되는 것이 아예 없습니다. (공유되는 State 자체를 만들 수 없습니다.)

     

    그리고, VM 내에서 하나의 Process 는 다른 Process의 실행에 아무런 영향을 주지 않습니다. 

    하나의 Process에 문제가 생겨서 죽어도, 다른 Process의 실행에는 영향을 주지 않습니다.  

    하나의 Process가 무한 Loop 를 실행해도, 다른 Process의 실행에는 영향을 주지 않습니다.  

     

    Elixir 에서는 이런 Process의 특성을 이용하여, 동시성과 장애 대응 프로그램을 개발합니다. 

     

    또한 VM 내에서 실행시킬 수 있는 Process의 개수는 VM 의 실행시 지정할 수도 있고, 개인 PC에서 실행 할 수 있는 

    Process의 개수도 보통 몇십만개 입니다.  그리고, 이런 Erlang Process들은 시스템 상의 복수개의 CPU Core에서 

    실행이되며, 이들 Process들간에 Shared Resource에 대한 Waiting 이 없게 되므로, 최대한 시스템의 성능을 

    활용하게 됩니다. 

     

    Java 의 Web Server는 Thread Pool 을 이용하는 반면,  Erlang 에서는 하나의 Client Session 마다 하나의 Process가 

    생성되어 전담처리를 하게 됩니다. 

     

    이후의 글에서는 이런 Process에 대한 내용과 이 Process로 이루어지는 OTP 에 대해 적겠습니다. 

     

     

Designed by Tistory.