Life is wonder-ful

'Why did we create Erlang?'의 번역. 번역은 정말 어렵다. 이렇게 짧은 글을 대충 초벌 번역하는데도 2시간 걸렸다. 제대로 하면 하루 종일 걸리겠지...

배운점

• 짧은 글 일수록 내용에 대한 이해가 더 많이 필요하다. 당연한 이야기지만 내용을 모르면 문맥을 알 수 없어 문장만으로는 번역을 할 수가 없다
• 역시 핵심 용어의 번역어 선택이 어렵다. 초벌 번역 완료 후에 여러 후보들 중에 적절한 번역어를 선택하는게 좋을 것 같다. 고장, 장애, 오류, 실패... -.-
  
• 어휘력의 한계를 절실하게 느꼈다. 분명 적절한 우리말이 있는데 안 떠오른다
• 영문자 사용은 어쩔 수 없다? RPC, OTP, MMU 이걸 다 어쩌나
• 초벌 번역은 직역으로 하고 나중에 온전한 우리말로 옮긴다?
  

왜 얼랭을 만들었나?

Maybe it didn’t happen exactly this way, but this is the way I think it should have happened
이렇게는 되지 말아야 했겠지만, 나는 이 일이 일어났어야 한다고 생각한다. ???

문제 영역 - 매우 동시 진행적이고 분산된 시스템

• 수천개의 동시 트랜잭션
• 가벼운 트랜잭션
• 가장 큰 CPU 부하는 계산이 아니라 동시 진행과 통신으로 발생한다
• 다양한 컴퓨터
• 다른 종류(빅엔디언, 리틀엔디언, 인텔, 스팍, 파워피씨 등등)
• 아무것도 공유하지 않는다(메모리 공유하지 않음, 다른 통신 장치(이더넷, 에이티엠, 사설))
• 다양한 운영체제
• 솔라리스, 브이엑스웍스, 윈도우즈, 피에스오에스, 리눅스 등등

문제 영역 - 중단시간 없음

• 계획되거나 계획되지 않은 중단시간은 허용되지 않는다
• 허용 기준: 9 다섯개 = 가동시간 99.999% 혹은 일년에 중단시간 5분
• 소프트웨어 오류의 복구
• 큰 시스템은 소프트웨어 오류가 있을 것이다
• 하드웨어 고장의 복구
  
• 네트웍 고장, 프로세서 고장
• 실행 중에 컴퓨터나 다른 하드웨어를 추가하고 빼는게 가능하다
  
• 실행 중인 시스템의 코드를 갱신한다

문제 영역 - 쉬운 프로그래밍

• 매우 표현력이 풍부한 프로그래밍 언어
• 프로세서 아키텍쳐 간의 쉬운 이식성
• 대규모 개발(수십 혹은 수백 명의 프로그래머)
• 점진적이고 탐험적인 프로그래밍
• 에러수정하기와 추적하기 - 고객이 운영중인 시스템도
• 설계의 모든 단계에서 에러수정과 갱신이 쉽다

해결 영역 - 동시 진행

• 충분히 가벼운 쓰레드/프로세스를 제공하는 업계에서 쓸만한 수준의 OS나 언어가 없다

• 프로세스는 독립적이어야 한다
• 공유하는 자원 없음
• 어느 프로세스든 다른 프로세스를 파괴할 수 없어야 한다
• 선택적 메시지 수신으로 사건/상태 행렬을 줄여라 ???

해결 영역 - 동시 진행과 분산

• OS를 수정하거나 새 OS를 만들지는 않고 싶으니 가벼운 프로세스는 "미들웨어"로 구현되어야 한다. 예를 들면 OS 위에서
• 프로세스를 독립적으로 만들기 위해서는 MMU의 통제나 포인터 없는 언어(혹은 안전한 포인터를 가진 언어)가 필요하다.
• 사건/상태 행렬을 줄이는 것은 신호/상태 모델을 불필요하게 만든다. ???
  
• 신호 상태 모델은 함수/서브루틴이 아니라 최상위 수준에서만 일시정지하는 쓰레드를 필요로 한다. 이는 적절한 RPC를 불가능하게 한다.

해결 영역 - 동시 진행과 분산: 설계 결정사항

• 운영체제 위의 가상 기계에 동시 진행성을 구현한다
• 명시적인 포인터가 없는 언어를 사용한다
• 프로세스간의 통신 방법으로 복사 메지시 전달만을 사용한다
• 선택적 메시지 수신을 구현한다
• 다른 기계 상의 프로세스들 사이의 통신은 같은 기계 상의 프로세스들 사이의 통신과 동일하게 만들어야 한다
• 실행 중에 획득된 타입 정보는 얼랭 표현을 외부 표현으로 자동 변환을 가능하게 한다

해결 영역 - 중단시간 없음

• 오류 검출의 원칙: 시스템의 장애가 있는 부분이 스스로 장애를 검출하고 바로 잡도록 허용하는 것은 안전하지 않다
• 시스템의 장애가 있는 부분 --장애 감지 | 관측자를 망칠 수 없음 --> 관측자

해결 영역 - 중단시간 없음

• 어떤 프로세스의 소프트웨어 오류는 다른 프로세스에 의해 가장 잘 감지된다
• 어떤 프로세서의 장애는 다른 프로세서에 의해 가장 잘 감지된다
• 우리는 종종 프로세스들 중 하나가 어떤 이유로 실패했다면 트랜잭션에 속한 모든 프로세스를 중단할 수 있기를 원한다

해결 영역 - 중단시간 없음: 설계 결정사항

• 프로세스 사이의 "연결" 개념을 고안. 프로세스가 실패하면 특별한 메시지(신호)를 연결되어 있는 모든 프로세스에게 보낸다.
• 프로세스의 장애를 알리는 신호를 받는 프로세스의 기본 동작은 "죽고" 모든 연결된 프로세스들에게 신호를 보내는 것이다.
• 특변한 표시를 해서, (trap_exit) 프로세서가 기본 동작을 변경하고 장애 신호를 보통의 메시지로 받을 수 있어야 한다
• 연결은 양방향이다 - (설계 실수일지도?)

해결 영역 - 중단시간 없음: 설계 결정사항

• 두가지 경우
  
• 엄청 많은 클라이언트를 가진 서버. 클라이언트에 장애가 발생하면 서버는 교정 동작을 수행해야 한다
• 트랜잭션에 속한 엄청 많은 프로세스 - 하나가 실패하면 모두 실패해야 한다
• 연결과 신호 방식은 프로세서 경계를 넘어서도 동작한다
• 한 프로세서에 장애가 발생하면 장애가 발생한 프로세서에 속한 프로세스에 연결된 모든 프로세스에 신호가 보내질 것이다.
• 오류 대처 철학: "망가지게 내버려둬" 그리고 다른 프로세스들이 상황을 수습하게 하라

해결 영역 - 중단시간 없음

• 기본 설계 패러다임
• 모든 활성 트랜잭션은 연결된 프로세스 그룹으로 표현하도록 하라
• 비활성(침체 상태?) 트랜잭션들은 복제되고 견고한 데이터베이스(Mnesia)에 저장하라
• trap_exit하여 실패한 트랜잭션의 자원을 해제하는 자원 할당 프로세스가 트랙잭션에 필요한 자원을 할당하도록 해야 한다
• ???

해결 영역 - 중단시간 없음: 설계 결정사항

• 가상 기계 설계로 인해 새 코드를 적재할 수 있게 하고 프로세스가 새 코드로 이행할 수 있도록 한다
• 이전 코드를 실행하고 있는 프로세스를 검출하는 능력
• 표준 설계 패턴(OTP의 일부)을 설계하여 원한다면 데이터를 새로운 형식으로 변환할 수 있다
• 애플리케이션 소프트웨어는 소프트웨어 수정과 장애 복구에 대해 고려할 필요가 있지만, 얼랭/OTP의 지원으로 이러한 영향은 최소화되었다

문제 영역 - 쉬운 프로그래밍 (다시 상기)

• 매우 표현력이 풍부한 프로그래밍 언어
• 프로세서 아키텍쳐 간의 쉬운 이식성
• 대규모 개발(수십 혹은 수백 명의 프로그래머)
• 점진적이고 탐험적인 프로그래밍
• 에러수정하기와 추적하기 - 고객이 운영중인 시스템도
• 설계의 모든 단계에서 에러수정과 갱신이 쉽다

해결 영역 - 쉬운 프로그래밍

• 자동 메모리 관리와 가비지 컬렉션을 지원하는 고수준 함수형 언어를 사용한다
• 프로세서 아키텍쳐 사이의 쉬운 이식을 위해 가상 기계에 의한 중간 코드 수행을 사용한다
• 간단한 비계층적 모듈 시스템
• 얼랭 쉘은 어떤한 특별한 테스트 프로그램 없이 바로 기능을 테스트하는 것을 허용한다
• 가상 기계는 디버깅과 장애 추적을 돕는다
• 동적 코드 교체 또한 소프트웨어 개발과 테스트에 아주 유용하다

의견

• 우리는 아래를 사용해서 일부 사람들을 흠칫 놀래켰다
• 함수형 언어
• 비OO 언어
• 재귀, 단일 할당 등
• 가상 기계
• 다시 말하면 업계 주류로부터 멀리 갈라져 나왔다. 우리는 아주 많은 지침을 동시에 바꾸고 있다.
• 주류의 태도 변화는 가능하다(자바 이전에 사람들이 가비지 컬랙션에 대해 뭐라고 했는지 떠올려보라)

의견

• 얼랭이 점점 많이 사용되고 있으니 곧 임계 질량에 도달할 것이다.