1부 이야기 - 분산 전략

마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처 패턴을 읽고 정리한다.

1부 이야기에서는 다양한 개념과 발전 과정을 말한다.

작성 시점은 20년 전으로 당시와 지금의 용어 & 개념이 다를 수 있고, 더 이상 사용 안 하는 것도 있을 수도 있다.

자세한 내용이 궁금하면 읽어보는 걸 권한다.

엔터프라이즈 애플리케이션 아키텍처 패턴(재출간판) - 교보문고

---

분산 객체의 매력

많은 업체에서는 분산 객체의 주목적은 다수의 객체를 필요에 따라 원하는 형태로 프로세싱 노드에 배치하기 위해서라 한다. 또한 투명성을 제공한다고 말한다.

투명성은 호출하려는 대상이 동일한 프로세스나 다른 프로세스 또는 다른 시스템에 있느냐와 관계없이 객체가 다른 객체를 한 프로세스 안이나 프로세스 간에 호출할 수 있게 해주는 개념이다.

투명성은 가치가 높고, 분산 객체의 여러 측면에 긍정적 영향을 주지만 일반적으로 성능에는 긍정적이지 않다.

---

원격 및 로컬 인터페이스

컴퓨터의 기본 작동 원리 때문에 클래스 모델별 분산이 좋지 않다.

한 프로세스 내의 프로시저 호출은 빠르지만, 분리된 프로세스 간의 프로시저 호출은 수십~수백배 느리다.

 

로컬 인터페이스는 가는 입자 인터페이스(fine-grained interface)일 때가 변경에 용이한 객체지향의 규칙을 따르기 때문에 바람직하다.

ex) 주소 클래스의 시 얻기, 도 얻기 등 메서드가 별도로 존재하는 인터페이스

 

원격 환경에서는 가는 입자 인터페이스가 맞지 않는다. 메서드 호출이 느리기에 때문에 결과적으로 호출 횟수 최소화를 위한 굶은 입자 인터페이스가 만들어진다. 이런 굶은 입자는 변경이 불편해 사용이 어렵지만 성능을 생각하면 어쩔 수 없다.

ex) 주소 클래스의 모든 정보를 한번에 얻는 인터페이스  

 

다중 프로세서를 효과적으로 활용하려면 클러스터링이 가장 적합하다.

---

분산이 필요한 상황

프로세스를 분리해야 하는 상황이 오면 다음과 같다.

- 비즈니스 소프트웨어에서 전통적인 클라이언트와 서버 간의 분리다. 사용자의 PC는 데이터의 공유된 리포지토리와는 다른 노드로 통신하려면 분리된 프로세스가 필요하다.

- 서버 기반 애플리케이션 소프트웨어와 데이터베이스 간에 자주 볼 수 있다. 

- 웹 시스템에서 웹 서버와 애플리케이션 서버 간에도 프로세스의 분리가 필요할 수 있다.

- 공급업체 간의 차이 때문에 분리해야할 수 있다. (외부 API 연동할 때)

---

분산 경계를 사용한 작업

굶은 입자 객체는 위임 외에 다른 일은 하지 않아, 가는 입자 객체에 대한 원격 파사드라고 한다. 

원격 파사드를 이용하면 굶은 입자 인터페이스를 사용할 때의 어려움을 최소화할 수 있다.

굶은 입자 인터페이스를 단순한 파사드로 유지하면 사람들에게 이 객체를 사용하게 허용할 수 있다.

데이터 전송 객체는 원격 파사드와 밀접하게 사용된다. 데이터 전송 객체는 양쪽에서 사용되니 양쪽에 공유되지 않는 것을 참조하지 않아야 한다. 결국엔 기본 객체만 참조한다.

 

브로커를 통해 객체를 프로세스 간에 마이그레이션해 분산을 구현하는 방법도 있다. 기본 개념은 데이터베이스에서 지연 로드 체계를 사용해 객체를 전송하는 것이다. 일부 O/R 매핑 툴은 이 기능을 지원한다.

---

분산을 위한 인터페이스

XML 기반 HTTP 통신에는 여러 장점이 있다.

- 많은 양의 데이터를 손쉽게 전송

- 원격 호출을 최소화

- 방화벽 통과 쉬움

- 서로 다른 플랫폼 간에 통신에 유용