수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다. 안정 해시는 이를 위해 보편적으로 사용하는 기술이다.
해시 키 재배치(rehash)문제
N개의 캐시서버에 부하를 균등하게 나누기 위해서 일반적으로 아래의 해시함수를 이용한다.
serverIndex = hash(key) % N
그런 만약 여기서 캐시 서버가 증가하거나 제거된다면 문제가 생긴다. N -> N-1으로 변경되었으니, 기존에 들어있던 데이터들이 잘못된 위치에 들어간 꼴이 되는 것이다. 따라서 현재 서버에 들어가 있는 대부분의 데이터를 다른 서버로 재 분배 해야한다. 안정해시는 이 문제를 효과적으로 해결하는 기술이다.
안정 해시
안정해시는 해시 테이블 크기가 조정 될 때 평균적으로 오직 k/n개의 키만 재배치하는 해시 기술이다.(k=키 개수, n=슬롯 개수) 해시 함수로 SHA-1을 사용한다고 했을 때 함수의 출력 값 범위(해시 공간; hash space)는 0~ 2^160-1이다. 여기서 처음과 끝을 연결해서 연결리스트처럼 만든 모양을 해시 링이라고 부른다.
해시 서버
해시 서버를 사용하면 해시 링의 특정 위치에 서버를 위치 시킬 수 있다. 이제 링의 특정 위치에 할당되는 서버는 특정 위치에서 값을 증가시키면서 가장 먼저 만나는 서버로 정할 수 있을 것이다. 그럼 서버가 제거된다면 제거된 서버 다음순서로 있던 서버로 기존 데이터를 옮기면 될 것이고, 서버가 추가된다면 추가된 서버 다음에 있는 서버에 할당되어 있던 데이터들 중에 추가된 서버보다 앞에 있던 데이터를 추가된 서버로 옮기면 될 것이다.
안정 해시 알고리즘의 기본 절차는 2가지이다.
1. 서버와 키를 균등 분포 해시 함수를 사용해 해시 링에 배치한다.
2. 키의 위치에서 링을 시계 방향으로 탐색하다 만나는 최초의 서버가 키가 저장될 서버다.
이 접근법은 2가지 문제가 있다.
1. 서버가 추가/삭제 된다면 파티션의 크기를 균등하게 유지할 수 없다.
2. 해시의 특성상 특정 서버에 데이터가 몰릴 수 있어서 키의 균등 분포를 달성하기 어렵다.
이 문제들을 해결하는 방법이 바로 가상 노드이다.
가상 노드
가상 노드는 실제 노드 또는 서버를 가리키는 노드로서 하나의 서버는 링 위에 여러 개의 가상 노드를 가질 수 있다.(바로가기, link를 생각하면 이해하기 쉽다) 이를 통해 파티션이 더 잘게 쪼개지게 되며, 가상 노드의 개수를 늘리면 키의 분포는 점점 더 균등해진다. 그러나 가상 노드의 개수가 늘어나면 저장 공간은 더 늘어나게 된다. 트레이드 오프가 필요한 순간이다.
처리율 제한 장치는 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하는 장치를 의미한다. 처리율 제한 장치를 두면 DoS 공격을 막고, 비용을 절감하며, 서버 과부하를 막을 수 있다.
이 장에서 작가는 지원자와 면접관의 대화를 통해 문제 이해 및 설계 범위를 확정하는 과정을 보여준다. 우리도 실제 설계를 할 때 면접관이 있다는 생각으로 문제를 명확하게 정의하고 한정할 필요가 있지만, 이 과정은 이 글에서는 제외한다.
요구사항
- 설정된 처리율을 초과하는 요청은 정확하게 제한한다.
- 낮은 응답시간: 처리율 제한 장치는 HTTP 응답시간에 영향을 주지 않아야 한다.
- 가능한 적은 메모리 사용
- 분산형 처리율 제한:하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유할 수 있어야 한다.
- 예외 처리: 요청이 제한되었을 때는 그 사실을 사용자에게 분명하게 보여줘야 한다.
- 높은 결함 남내성: 제한 장치에 장애가 생기더라도 전체 시스템에 영향을 주어서는 안된다.
처리율 제한장치는 서버와 클라이언트 사이에서 요청을 제한해야한다. 이는 서버측에 둬야한다. 클라우드 마이크로 서비스의 경우 처리율 제한 장치는 보통 API 게트트웨이에 구현한다. API 게이트웨이는 다양한 기능을 제공하는 완전 위탁관리형 서비스이다. 하지만 일단 API는 처리율 제한을 지원하는 미들웨어라는 점에만 주목하자.
처리율 제한은 5가지의 알고리즘이 유명하다.
- 토큰 버킷
토큰 버킷은 일정한 시간마다 토큰이 채워지는 버킷(양동이)에서 요청이 발생할 때마다 토큰을 소비해서 요청을 처리하는 것이다. 만약 토큰이 부족하다면 요청은 버려진다. 일반적으로 API 엔드포인트마다 별도의 버킷을 둔다.
장점 : 이 방식은 구현이 쉽고, 메모리 사용이 효율적이며, 짧은 시간에 집중되는 트레픽을 처리할 수 있다.
단점 : 버킷 크기와 토큰 공급률을 조정하기 까다롭다.
- 누출 버킷
요청을 큐에 넣고 고정 속도로 서버에서 읽어와서 처리하는 방식이다.
장점 : 큐의 크기가 제한되어있어서 메모리 사용이 효율적이며, 고정처리율때문에 안정적 출력이 필요한 경우 적합하다.
단점 : 단시간에 트래픽이 몰리는 경우 큐에 요청이 쌓이고, 최신 요청이 버려질 수 있다.(큐 오버플로) 또한 버킷 크기와 처리율을 조정하기 어렵다.
- 고정 윈도 카운터
타임라인을 고정된 간격의 윈도로 나누고(예컨데 1초마다 새로운 윈도가 기다리고 있다), 각 윈도마다 카운터를 붙인다. 요청이 들어올 때마다 윈도 카운터를 증가시키고, 임계치가 넘으면 다음 윈도우가 열릴때까지 요청은 대기한다. 이 알고리즘은 예상한 요청보다 많은 요청을 받을 수 있는 위험이 존재한다. 예컨데 5초마다 임계치가 10인 윈도우가 있는데, 4초에 10개가 들어오고 6초에 10개가 들어오면 3초에서 8초 사이에 20개의 요청을 받게 되는 것이다.
장점 : 메모리 효율이 좋다. 이해가 쉽다. 특정한 트래픽 패턴을 처리하기 좋다.(매 분마다 요청이 발생하는 경우 등)
단점 : 기대보다 많은 요청을 받을 수 있다(앞서 언급한 사례 참조)
- 이동 원도 로그
고정 윈도 카운터 방식의 단점을 보안한 방식으로, 요청은 들어올 때마다 log에 담긴다. 이때 윈도 크기에 해당하는 시간(예컨데 5초)보다 오래된 요청 log는 삭제한다. 오래된 요청을 삭제한 이후에 남아있는 요청의 크기가 임계값보다 작으면 요청을 처리한다.
장점 : 정확하게 처리율 한도를 제한한다.
단점: 다량의 메모리를 사용한다.
- 이동 윈도 카운터
이동 윈도 카운터는 고정 윈도 카운터와 이동 윈도 로그 방식을 결합한 방식이다. 고정 윈도와 동일하게 요청이 윈도우마다 카운터를 증가시키는데, 현재 시간을 끝으로 하는 윈도우가 걸치고 있는 2개의 윈도우(정확히 윈도우가 끝나는 지점에 있으면 1개)를 현재 윈도우가 몇 퍼센트씩 걸치고 있냐에 따라서 처리율을 계산한다. 예컨데 윈도우 크기가 1분이고, 현재 시간은 1분 20초라면 앞의 윈도우의 67%, 뒤의 윈도우의 33%를 걸치고 있다. 따라서 (직전 윈도에서 요청의 수) * 67% + (이번 윈도에서 쌓인 요청의 수) > (윈도 카운터 크기) 라면 요청을 버린다.
장점 : 짧은 시간에 몰리는 트래픽에도 잘 대응한다. 또한 메모리 효율도 좋다.
단점: 직전 시간대에 도착한 요청이 균동하게 분포되어 있다고 가정하므로 다소 느슨하다.(하지만 치명적이지 않음)
처리율 한도 초과 트래픽 처리
요청을 메시지 큐에 보관할 수도 있을 것이고, 사용자에게 429응답(too many requests)를 반환할 수도 있을 것이다.
분산 환경에서 처리율 제한 장치의 구현
Redis에서 카운터의 값을 읽고, counter+1의 값이 임계치를 넘는지 본 후에 넘지 않는다면 레디스에 보관된 카운터 값을 1만큼 증가시키는 방식은 경쟁 조건과 동기화 문제를 해결해야한다. 작가는 경쟁조건을 해결하는 2개의 블로그를 보여준다.
해당 장은 시스템 설계 면접에 접근하는 방법을 전하고 있다. 필자는 이 책을 시스템 설계 면접을 위해 읽은 것은 아니지만, 이 장을 통해 시스템 설계를 하면서 놓치면 안되는 부분을 다시한번 되짚을 수 있었다. 3장은 간단하게 언급하고 넘어가겠다.
효과적 면접을 위한 4단계 접근법
1. 문제 이해 및 설계 범위 확정
2. 개략적인 설계안 제시 및 동의 구하기
3. 상세 설계
4. 마무리(추가 논의)
작가는 4단계로 면접에 접근하라고 조언한다. 여기서 필자는 개략적인 설계안 제시 및 동의를 구하고 상세 설계를 마무리 한다는 지점이 정말 좋았다. 실제 설계를 하다보면 자신있는 부분에 대한 설계는 상세하게 하고, 잘 알지 못하는 부분에 대한 설계는 문제를 인지하지도 못한채 넘어가곤 한다. 그래서 커다란 시스템 설계를 단계별로 진행하면서 동의를 구하는 부분이 마음에 들었다. 아주 간단한 설계에서 시작해서 계속해서 다음 Step을 밟아가면서 동료에게 또는 선배/상사에게 조언을 받는다면 조금더 꼼꼼한 설계안을 만들 수 있지 않을까?
개략적인 규모추정은 보편적으로 통용되는 성능 수치상에서 사고 실험을 행하여 추정치를 계산하는 행위로, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것이다.
실제 시스템을 설계할 때 숫자를 확인하면서 설계를 하는 것은 아주 중요한 일이다. 예컨데, RabbitMQ을 사용해야 할 상황과 Kafka를 사용해야 할 상황을 구분하기 위해서는 초당 몇건의 요청이 들어오는지에 달렸다. 또한 유일ID 생성기를 설계할 때도, DB다중화 전략을 잡을 때도 모두 예상하는(또는 목표하는)요청의 숫자에서 시작해야 한다. 또한 규모 추정을 통해서 비용을 계산할 수도 있다. 비용 계산은 비즈니스의 일부로서의 개발을 바라봤을 때 개발보다 중요한 요소일수도 있다.
세부적인 데이터에 관한 내용은 블로그에 작성할 내용은 아닌 것 같으므로, 책에 있는 예시만 언급하고 넘어가겠다.
이 책은 대규모 시스템을 설계하기 위해서 해야할 접근방식과, 모범답안을 알려준다. 이 문제들과 답안을 통해서 대규모시스템의 문제를 도출해 낼 수 있는 힘과 이를 해결하기 위한 사고방식을 배울 수 있었다. 평소에 시스템 설계를 고민하면서 헤메이던 기억이 많은데, 가려운 곳을 시원하게 긁어주는 책이었다. 개인적으로 이 책은 가볍게 읽어도 좋을 것 같다. 각각의 컴포넌트가 아닌 시스템 전체를 설명하고 있어서 생각보다 어렵지 않고, 심지어 작가가 나열하는 문제를 어떻게 해결해 나가는지가 기대되기도 한다.
1장 사용자 수에 따른 규모 확장성
1장에서는 단일 서버에서부터 대규모 시스템을 설계하기 까지의 Step을 하나하나 알려준다. 각 Step이 어떤 문제에서 시작해서 어떤 형태로 변화하는지 아주 설득력 있게 다룬다
단일서버
단일서버는 웹서버 한대만으로 사용자 단말의 요청을 처리하는 구조다. 여기엔 DB도 없고, 캐시도 없으며, 정말 단일 웹서버만으로 요청을 처리한다. 아마도 데이터를 저장하는 위치는 해당 웹서버의 파일 시스템일 것으로 보인다.
데이터베이스
작가는 첫번째로 서버에서 데이터베이스를 분리한다. 단일 서버는 사용자가 증가하면 트레픽을 버틸만한 컴퓨팅 파워가 부족하기 때문이다. (자세한 언급은 없었지만, 당연하게도 단일버서는 조금만 트레픽이 증가해도 버틸 수 없다.) 데이터 베이스는 RDB와 NoSQL을 간단하게 비교해서 설명해준다. 그리고 각각의 DB를 선택해야하는 기준도 간단하게 언급한다.
수직적 규모 확장 vs 수평적 규모확장
수직적 규모 확장(이하 Scale up)은 사용하고 서버에 고사양 자원을 추가하는 방식을 의미하고, 수평적 규모 확장(이하 Scale out)은 서버를 추가해 주는 방식이다. 작가는 Scale up의 단점을 언급하면서 Scale out을 추천하고, 이를 위한 로드 벨런서까지 자연스럽게 이어지게 한다. 작가는 scale up의 단점을 확장에 한계가 있다는 점과, 자동복구나 다중화 방안을 제시하지 않는다는 것을 언급한다. 하지만 서버에 유입되는 트래픽의 양이 적을 경우에는 scale up도 좋은 선택이며, 단순한 솔루션이기 때문에 상황에 따라 선택할 수 있다고도 잠깐 언급한다.
로드밸런서
scale out을 하기 위해서는 하나의 엔포인트로 오는 사용자 단말의 요청을 여러개의 서버로 분산해 줘야한다. 그 역할을 하는 것이 로드 밸런서이다. 또한 로드 밸런서는 장애를 자동으로 복구할 수 있으며, 가용성(웹서버 하나가 죽더라도 다른 하나가 사용 가능한 것)이 향상된다. 로드 밸런러는 외부로 공개 IP를 Open해두고, 사설 IP 주소를 가지고 서버들에게 요청을 분산해 주는 방식을 택하고있다. 이제 웹 계층에 대해서 살펴봤으니 데이터 계층에 대해서 살펴본다.
데이터베이스 다중화
데이터베이스 다중화는 데이터베이스 서버를 여러개 만들어서 master 또는 slave의 역할을 수행하도록 한다. 이때 쓰기 연산은 master에서만 지원하고, slave는 master에서 그 사본을 전달받아서 읽기 전산을 지원한다. 일반적인 어플리케이션은 쓰기보다 읽기연산이 많으므로, slave 서버가 더 많다. 이렇게 데이터베이스 다중화를 수행하므로서 병렬 읽기로 인한 더 나은 성능과 서버가 분산되므로 인한 안정성(데이터 다중화로 인한 자연 재해로 인한 데이터 손실 최소화), 그리고 가용성(하나의 서버에 장애가 발생해도 다른 서버에서 서비스 가능)을 보장받는다.
캐시
이제 웹 계층과 데이터 계층에 대해 논의했으니, 응답시간을 개선하기 위한 캐시에 대해서 말해보자. 캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고 뒤이은 요청이 보다 빨리 처리 되도록 하는 저장소이다. 캐시 계층은 메모리를 활용하므로 DB에 비해 조회 속도가 빠르고, DB에 요청을 적게 주므로서 부하를 줄일 수 있다. 또한 캐시를 확장시키는 것도 가능하다.
작가는 캐시를 사용하기전에 해야할 질문을 친절하게도 대신 하고, 답변해주고 있다. 캐시가 바람직한 상황, 캐싱할 데이터의 종류, 캐시 만료 전략, 일관성 유지방법, 장애 대응, 캐시 메모리 크기, 데이터 방출 정책에 대한 언급을 하고 있다.(해당 내용은 필요하다면 책을 확인해보자)
CDN
CDN은 정적 콘텐츠 전송을 위한 지리적으로 분산된 서버의 네트워크이다. CDN을 통해서 정적파일을 캐싱해두면 지리적 이점을 바탕으로 성능을 향상시킬 수 있다. 하지만 비용, 만료 시한 설정, 장애 대응, 콘텐츠 무효과 방법 등을 고려해서 CDN을 도입해야 한다.
무상태 웹계층
웹 계층을 수평적으로 확장하려면 웹 계층은 무상태를 유지해야 한다. 이는 각각의 요청이 같은 서버로 들어올 것이라는 보장이 없기 때문에(이를 실현할 수 있지만 로드 밸런서에게 큰 부하를 준다) 사용자 단말의 상태를 유지해둬도 재조회가 불가능 하기 때문이다. 이를 위해서 상태는 NoSql과 같은 지속성 저장소에 보관하고, 필요할 때 가져와야 한다.
데이터 센터
데이터 센터를 다중화 하므로서 지리적 라우팅을 통한 성능 향상, 그리고 가용성 향상, 안정성 향상을 꾀할 수 있다. 하지만 데이터 센터 다중화는 몇가지 기술적 난제를 해결해야 한다. 이는 트레픽 우회(지리적 라우팅)과 데이터 동기화, 테스트와 배포이다.
메시지큐
메시지 큐는 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트이다. 메시지 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모의 확장성이 보장되어야 하는 안정적인 어플리케이션을 구성하기 좋다. 예컨데 서버와 서버간의 통신의 결합을 느슨하게 해서 두 서버중 누군가 시간이 성능이 부족해져도 독립적으로 확장할 수 있는 것이다.
로그, 메트릭 그리고 자동화
웹사이트와 함계 사업 규모가 커지고 나면 위의 도구는 필수적이다.
데이터베이스의 규모확장
DB는 scale up과 scale out이 모두 가능하다. 하지만 앞서 언급한바와 같이 scale up은 한계가 존재하며, SPOF(Single Point Of Failure)의 위한이 크다. 또한 비용도 많이 든다. 반면 수평적 확장은 DB 샤딩을 통해서 가능하다. 샤딩은 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술을 말한다. 이는 간단하게 (user_id%4)번 DB에 데이터를 저장하는 방식이 있다. DB 샤딩은 데이터가 너무 많아지면 재샤딩 하기도 하고, celebrity문제를 해결해야 하며(이후 안정해시를 이야기하며 힌트를 얻을 수 있다), 조인이 불가능해지기 때문에 비정규화를 통해 하나의 샤드에서 질의가 수행하도록 해야한다.
n+1문제는 잘 알려진 문제이다. 이를 위한 기본적인 해결책으로 join fetch를 사용하는 것 역시 아주 잘 알려져 있다. 하지만 이번에 n+1 문제를 해결하면서 만난 특이한 경험을 공유하려고 한다. 이를 위해서 @OneToOne Mapping이 걸려 있는 경우에 Laze Loading이 작동하지 않는 다는 사실과, 예상하지 못한 횟수의 쿼리가 날아간 사례를 설명하고, 해결했던 방법을 공유하고자 한다.
n+1 문제를 만나다
아래와 같은 Restaurant과 연관된 Entity, Repository, Service가 존재한다.
@Entity
public class Restaurant {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@OneToOne(mappedBy = "restaurant", cascade = CascadeType.ALL)
private RestaurantLocation location;
@OneToOne(mappedBy = "restaurant", cascade = CascadeType.ALL)
private RestaurantInformation information;
@OneToMany(mappedBy = "restaurant", cascade = CascadeType.ALL)
private List<RestaurantMenu> menus = new ArrayList<>();
}
public interface RestaurantRepository extends JpaRepository<Restaurant, Long> {
}
@Service
@RequiredArgsConstructor
@Transactional
public class RestaurantService {
private final RestaurantRepository restaurantRepository;
public RestaurantDetailResponse getRestaurantDetail(long restaurantId) {
Restaurant restaurant = restaurantRepository.findById(restaurantId).orElseThrow(NoRecordException::new);
return RestaurantDetailResponse.of(restaurant);
}
}
현재의 상황에서 RestaurantService의 getRestaurantDetail을 호출하면 n+1 문제가 발생한다. 이는 Restaurant 엔티티의menus 필드가 Lazy Loading하도록 설정되어 있기 때문이다.(@OneToMany의 fetch 설정은 Lazy가 기본이다)
따라서 n+1 문제를 해결하기 위해서 다음과 같이 RestaurantRepository에 left join fetch를 JPQL로 선언해둔 메서드를 추가하고, RestaurantService 코드를 수정했다.
public interface RestaurantRepository extends JpaRepository<Restaurant, Long> {
@Query(value = "select r from Restaurant r left join fetch r.menus where r.id=:id")
Optional<Restaurant> findByIdWithMenus(@Param(value = "id") long id);
}
@Service
@RequiredArgsConstructor
@Transactional
public class RestaurantService {
private final RestaurantRepository restaurantRepository;
public RestaurantDetailResponse getRestaurantDetail(long restaurantId) {
Restaurant restaurant = restaurantRepository.findByIdWithMenus(restaurantId).orElseThrow(NoRecordException::new);
return RestaurantDetailResponse.of(restaurant);
}
}
그럼 나의 상식대로는 n+1 문제가 해결되었어야 한다! 그런데 그렇지 않았다.
해당 메서드를 실행해 본 결과 다음과같은 쿼리가 수행되었다.(쉬운 이해를 위해 축약되었다.)
select * from restaurant r left join restaurant_menu m on r.id = m.restaurant_id where r.id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
최초에 걱정했던 join했던 menu에 대한 n+1문제는 깔끔하게 해결되었지만, 다른 쿼리들이 날아가는 것이다. 그것도 중복으로 엄청 많이!
@OneToOne Mapping은 Lazy Loading이 안될 수 있다.
결론부터 이야기하면, 결론부터 말하자면 연관관계 주인쪽 엔티티 측에서는 Lazy 로딩이 정상적으로 동작한다. 하지만 연관관계의 주인이 아닌 엔티티측에서는 Lazy로딩이 이루어지지 않는다.
Hibernate는 Proxy는 Null을 감싸지않는다. 이는 간단하게 생각해볼 수 있다. RestaurantLocation의 Proxy를 만드는 과정을 상상해보자.
최초에 Proxy는 RestaurantLocation을 상속받아서 프록시로 만들 것이다. 이때 프록시는 실제 데이터를 가지고 있지 않지만, 단 하나 PK값은 알고 있어야 한다. PK값을 알고 있어야 해당 레코드에 직접 접근해야 하는 시점에 쿼리를 날릴 수 있기 때문이다.
어라? 그럼 그냥 PK값도 모르고 실제 레코드에 접근해야 하는 시점에 쿼리를 달리면 되지 않나요? 아래의 쿼리처럼요 이거처럼요!
slect * from restaurant_location where restaurant_id=1
좋다. 그럼 PK를 저장하지 않고 사용자가 데이터에 직접 접근할 때 해당 쿼리를 수행하는 방식은 어떨까? 사용자가 특정 데이터에 접근할 때(restaurantLocation.getRoadNumber()) 앞서 언급한 쿼리가 날아갈 것이다. 그런데 이 쿼리의 결과가 0개라면 Proxy는 어떤 결과를 돌려줘야 할까? 아마도 Exception일 것이다. 그럼 사용자는 직접 접근하기 전까지 해당 필드가 존재하는지 아닌지 알 수 없다.
Hibernate를 만든 사람은 사용자가 데이터의 존재여부를 확인하는 시점을 최초에 Entity를 조회하는 시점으로 통일하기 위해서 다음과 같은 원칙을 세운듯 하다.
Proxy는 Null이거나, 실제 데이터를 담고 있어야 한다.
이제 다음 원칙을 만족하기 위해서 Hibernate가 @OneToOne Mapping된 필드를 Lazy Loading 조건부로 지원하는 이유를 이해할 수 있다. 만약 해당 필드가 실제 테이블에서 외래키를 가지고 있지 않다면, 그니까 연관관계의 주인이 아니라면 실제 데이터의 존재여부를 확인해서 Null이나 실제 데이터에 접근할 수 있는 Proxy를 반환해야 하는 것이다. 그런데 이를 위해서 한번 데이터를 조회한 이상 Lazy Loading의 의미가 사라졌기 때문에 연관관계의 주인이 아닌 @OneToOne Mapping된 필드는 Lazy Loading을 지원하지 않는 것이다.
그런데 왜 Eager로 설정된 필드를 여러번 조회하지?
앞서 서술한 이유를 차치하더라도 최초에 우리가 확인했던 쿼리는 이상하다. 앞선 쿼리를 다시한번 확인해보자.
select * from restaurant r left join restaurant_menu m on r.id = m.restaurant_id where r.id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
select * from restaurant_information where restaurant_id = 1;
select * from restaurant_location where restaurant_id = 1;
RestaurantInformation, RestaurantLocation 2개의 Entity는 @OneToOne으로 매핑되어있으니 쿼리가 추가적으로 날아가는 것에 의문이 생기지 않았다. 하지만 왜 하필 각각 6번씩 날아가는 것인가?
(이때 PK가 1인 레스토랑의 메뉴는 총 6개이다.)
Spring 코드를 뜯어 본 결과는 Query를 날려서 받아온 데이터의 Low 갯수만큼 반복문을 돌면서 Entity를 Initialize 하기 때문이었다.
아래의 코드는 org.hibernate.sql.results.spi.ListResultsConsumer.consume() 함수의 일부이다.
while문에서 최초로 rowProcessingState.next()를 호출하면 우리가 의도한 쿼리가 실제로 날아가게 된다. 나의 경우에는 select * from restaurant r left join restaurant_menu m on r.id = m.restaurant_id where r.id=1;
였다. 그리고 아래 줄에서 rowReader.readRow() 함수에서 각 row를 확인해서 Entity를 채워준다. 아래는 org.hibernate.sql.results.internal.StandardRowReader.readRow() 코드이다.
public T readRow(RowProcessingState rowProcessingState, JdbcValuesSourceProcessingOptions options) {
LoadingLogger.LOGGER.trace( "StandardRowReader#readRow" );
coordinateInitializers( rowProcessingState );
final Object[] resultRow = new Object[ assemblerCount ];
for ( int i = 0; i < assemblerCount; i++ ) {
final DomainResultAssembler assembler = resultAssemblers.get( i );
LoadingLogger.LOGGER.debugf( "Calling top-level assembler (%s / %s) : %s", i, assemblerCount, assembler );
resultRow[i] = assembler.assemble( rowProcessingState, options );
}
afterRow( rowProcessingState );
return rowTransformer.transformRow( resultRow );
}
그리고 coordinateInitializers()에서 row에 들어있는 각 데이터를 통해 를 통해 Entity의 필드를 채워주는데, 해당 코드는 다음과 같다.
private void coordinateInitializers(RowProcessingState rowProcessingState) {
final int numberOfInitializers = initializers.size();
...(중략)...
for ( int i = 0; i < numberOfInitializers; i++ ) {
initializers.get( i ).initializeInstance( rowProcessingState );
}
}
여기서 List<Initializer> initializers에서 순서대로 객체를 꺼내와서 initializeInstance를 호출하게 되는데, 꺼내온 Initializer객체들은 각각 DB에서 조회에온 필드를 담고있다. 이 중에서 특히 @OneToOne으로 매핑된 필드의 Initializer는 EntitySelectFetchInitialzer를 구현체로 가지고 있는데, 이 객체가 Entity의 해당 필드를 Initialize하는 방식이 직접 DB에 쿼리 하는 방식이었던 것이다!
Lazy Loading이 안된다면 Fetch Join으로
결국 해당 문제를 해결하기 위해서 Lazy Loading이 되지 않는다면 join fetch을 사용해서 한번에 가져오는 방식으로 문제를 해결했다. 이에대한 다른 해결책으로 Shared Key를 사용하거나, @OneToOne 관계를 @OneToMany/@ManyToOne으로 변형해서 사용하는 방식이 있는데, 최대한 직관적인 방식으로 해결했다.
public interface RestaurantRepository extends JpaRepository<Restaurant, Long> {
@Query(value = "select r from Restaurant r left join fetch r.menus left join fetch r.information left join fetch r.location where r.id=:id")
Optional<Restaurant> findByIdWithMenus(@Param(value = "id") long id);
}
훌륭한 객체지향 코드를 얻기 위해서는 클래스가 아니라 협력 안에서 객체가 수행하는 책임에 초첨을 맞춰야 한다. 이때책임이 객체가 수신할 수 있는 메시지의 기반이 된다. 객체가 수신하는 메시지들은 객체의 퍼블릭 인터페이스를 구성한다. 그럼 책임주도 설계를 하면 훌륭한 인터페이스를 얻을 수 있을 것 처럼 보인다. 하지만 그렇지 않다. 좋은 인터페이스는 몇가지 설계 원칙과 기법을 익히고 적용해야 한다. 이런 원칙과 기법들을 살펴보는 것이 이번 장의 주제이다.
01. 협력과 메시지
클라이언트-서버 모델
두 객체 사이의 협력을 설명하는 전통적인 메타포는 클라이언트-서버 모델이다. 클라이언트 객체는 메시지를 전송하고, 서버 객체는 메시지를 수신한다. 객체는 협력에 참여하는동안 클라이언트와 서버 모두를 수행하는 것이 일반적이다.
위의 그림에서 Movie는 가격을 계산하라는 메시지를 받는 서버인 동시에, 할일 요금을 계산하라는 메시지를 보내는 클라이언트인 것이다.
객체가 활용하는 메시지는 크게수신하는 메시지와 송신하는 메시지로 나뉜다. 보통 객체를 설계할 때 수신하는 메시지를 신경쓰지만, 송신하는 메시지 역시 중요하다.
여기서 요점은 객체가 협력하기 위해서 메시지를 활용한다는 것이다.
메시지와 메시지 전송
"메시지는 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단"
메시지 전송 or 메시지 패싱 : 객체가 다른 객체에게 도움을 요청하는 것
메시지 전송자 or 클라이언트 : 메시지를 전송하는 객체
메시지 수신자 or 서버 : 메시지를 수신하는 객체
메시지 : 오퍼레이션명 + 인자
메시지 전송 :메시지 수신자 +오퍼레이션명 + 인자
언어별 메시지 전송 표기법
메시지와 메서드
메서드 : 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저
객체가 다른 객체에게 메시지를 보내면메시지 수신자의 실제 타입에 따라 다른 메서드가 실행될 수 있다.메시지 전송과 메서드의 구분은 메시지 전송자와 메시지 수신자가느슨하게 결합될 수 있게 하므로서, 두 객체 사이의결합도를 낮추고 유연하고 확장 가능한 코드를 작성할 수 있게 만든다.
퍼블릭 인터페이스와 오퍼레이션
퍼블릭 인터페이스 : 객체가 의사소통을 위해 외부에 공재하는 메시지의 집합
오퍼레이션 : 퍼블릭 인터페이스에 포함된 메시지(수행 가능한 어떤 행동에 대한추상화로, 메시지와 관련된 시그니처)
메서드 : 실제로 수행되는 코드
객체가 다른 객체에게 메시지를 전송하면 런타임 시스템은 메시지 전송을 오퍼레이션 호출로 해석하고 메시지 수신자의 실제 타입을 기반으로 적절한 메서드를 찾아 실행한다.
메시지, 오퍼레이션, 메서드 사이의 관계
시그니처
시그니쳐 : 오퍼레이션이나 메서드의 명세를 의미한다. 오퍼레이션명+파라미터목록(+반환값 : 몇몇 언어는 반환값을 포함)
객체가 수신할 수 있는 메시지는 퍼블릭 인터페이스와 그 안에 포함될 오퍼레이션이 결정한다. 퍼블릭 인터페이스는 객체의 품질을 결정하기 때문에 메시지가 객체의 품질을 결정한다.
02. 인터페이스와 설계 품질
3장에서 언급한바와 같이 좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건이 있다. 이는꼭 필요한 오퍼레이션만 인터페이스에 포함하고,How보단 What을 표현하는 시그니쳐를 만들라는 것이다. 그런데 앞서 살펴본책임 주도 설계는 이 두가지 조건을 만족시켜준다.
비록 책임주도 설계가 훌륭한 인터페이스를 얻게 도와주지만, 퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법에 대해 알아보는 것은 중요하다.
디미터 법칙
묻지 말고 시켜라
의도를 드러내는 인터페이스
명령-쿼리 분리
디미터 법칙
디미터의 법칙은 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라는 것이다. 쉽게말해서"오직 하나의 도트만 사용하라"는 원칙이다. 예시를 들어보자.
클래스C와C의 내부에 있는 메서드M이 있을 때M에서 객체에게 보낼 수 있는 메시지는 다음과 같은 클래스의 인스턴스여야 한다.
(M에 의해 생성된 객체나,M이 호출하는 메서드에 의해 생성된 객체, 전역변수로 선언된 객체는 모두M의 인자로 취급)
M의 인자로 전달된 클래스(C자체를 포함)
C의 인스턴스 변수의 클래스
디미터의 법칙을 따르면부끄럼타는 코드(shy code)를 작성할 수 있다.불필요한 어떤 것도 다를 객체에게 보여주지 않으며, 다른 객체의 구현에 의존하지 않는 코드를 작성할 수 있다는 것이다.
메시지를 통해 반환받은 객체에 연쇄적으로 메시지를 전송하는 형태의 코드를 기차 충돌이라고 부르는데, 이는 메시지 전송자가 메시지 수신자의 내부 정보를 자세히 알게 된다. 따라서 메시지 수신자의캡슐화는 무너지고, 메시지 전송자는 수신자의내부 구현에 강하게 결합된다.
묻지 말고 시켜라
객체의 상태를 물어보는 행위는 알게된 다른 객체의 상태를 기반으로 의사결정을 한다는 것이다. 당연하게도 객체의 외부에서 해당 객체의 상태를 기반으로 결정을 내리는 것은 객체의 캡슐화를 위반한다.객체에게 상태를 물어보지 말고, 객체가 스스로 상태를 기반으로 의사결정을 하도록 시켜라.
"절차적인 코드는 정보를 얻을 후에 결정한다. 객체지향 코드는 객체에게 그것을 하도록 시킨다."
묻지 말고 시켜라 원칙에 따르면자연스럽게 정보전문가에게 책임을 할당하게 되고,높은 응집도를 얻게 된다. 개발을 하면서 내부의 상태를 묻는 오퍼레이션을 인터페이스에 포함하고 있거나, 내부의 상태를 이용해 어떤 결정을 내리는 로직이 객체 외부에 있다면 객체의 책임이 누수된 것이다.
의도를 드러내는 인터페이스
메소드의 이름을 짓는 방법은 두가지가 있다. 내부 구현을 드러내는 방법과 협력 관계를 드러내는 구현이다. 캔트 백은 어떻게 하느냐가 아니라 무엇을 하느냐에 따라 메서드 이름을 짓는 패턴을 의도를 드러내는 선택자라고 부르고, 이 방식을 권장한다. 내부 구현을 드러내면 2가지의 대표적인 단점이 존재한다.
1. 메서드의 내부 구현을 정확히 이해하지 못하면 두 메서드가 같은 역할을 수행한다는 사실을 알지 못한다. 즉, 메소드에 대해 제대로 커뮤니케이션 하지 못한다.
2. 메서드 수준에서 캡슐화를 위반한다. 구현을 드러낸 메서드를 변현하려면 단순히 참조하는 객체를 변경하는 것뿐만 아니라 호출하는 메서드를 변경해야 하는 것이다.
사실 가장 불편한 점은 같은 역할을 가진 두 메서드가 대체되지 못한다는 것이다.(다형성을 성공적으로 구현할 수 없음)
에릭 에반스는 켄트 백의의도를 드러내는 선택자를 인터페이스 레벨로 확장한 의도를 드러내는 인터페이스를 제시한다. 의도를 드러내는 인터페이스란 구현과 관련된 모든 정보를 캡슐화하고 객체의 퍼블릭 인터페이스에서 협력과 관련된 의도만을 표현해야 한다는 것이다.
03. 원칙의 함정
앞서 말한 원칙들은 절대적인 법칙이 아니다. 결국 설계는 트레이드오프이기 때문에 상황에 따라서 유연하게 원칙을 적용해야 한다. 어떤 상황에서 어떤 원칙을 고수할지 잘 판단하는 것이 바로전문가의 역량인 것이다.
디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다
JAVA 8에서 사용하는 intstream은 디미터 법칙을 위반하고 있는가? 아니다. intstream은 메서드가 자기자신과 동일한 클래스의 인스턴스를 반환한다. 디미터의 법칙은 결합도를 낮추기 위한 목적이다.따라서 내부 구현을 드러내지 않는 기차충돌코드(그렇게 보이지만 실제로는 그렇지 않다.) 는 여기에 존재하지 않는다. 맹목적으로 원칙만을 강조하지 말자.
결합도와 응집도의 충돌
기차코드(도트가 계속 반복되는 코드)는 일반적으로 결합도를 높힌다. 하지만 결합도를 높히는 행위가 응집도를 낮추는 행위가 될 수도 있다. 예를 들어서 영화관에서 특정 영화의 수익률을 계산하는 로직이 있다고 하자. 그럼 이 로직은 분명 '영화'라는 객체에서 많은 정보를 가져올 것이다. 예컨데 가격, 상영시간, 비용 등을 고려할 수 있을 것이다. 그럼 우린 앞서 배운 디미터 법칙에 따라서 이 행위를 '영화'라는 객체에 위임해야 하는 것일까? 생각해보면 영화의 수익률을 계산하는 로직은 영화관에게 주어진 책임이다. 영화관의 장비 감가상각비, 임대료, 프로모션 비용 등이 수익률을 결정하기 때문이다. 따라서 수익률을 계산하는 로직이 영화로 옮겨가면 결합도는 낮아질 수 있지만, 응집도도 함께 낮아지는 것이다.
응집도가 낮아야 하는 이유는 객체의 변경 포인트가 하나여야 하기 때문이다. 이런 목적을 달성하기 위해서는 결합도가 조금 높아지는 희생을 감수해야 하기도 한다.
클린 코드에서 디미터 법칙의 위반 여부는 묻는 대상이 객체인지, 자료 구조인지에 달려있다고 설명한다. 객체는 내부 구조를 숨겨야 하므로 디미터의 법칙을 따르는 것이 좋지만 자료 구조라면 당연히 내부를 노출해야 하므로 디미터 법칙을 적용할 필요가 없는 것이다.
다시한번 강조한다. 소프트웨어 설계에 법칙이란 조네재하지 않으니,원칙을 맹신하지 마라.
04. 명령-쿼리 분리 원칙
우선 명령과 쿼리가 무엇인지 명확하게 구분할 필요가 있다.
명령(프로시저) : 부수효과를 발생시킬 수 있지만, 값을 반환할 수 없다.
쿼리(함수) : 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다.
이 두가지 요소를 분리해서 만든 인터페이스를 명령-쿼리 인터페이스라고 부른다. 그럼 명령과 쿼리를 분리해서 얻는 장점은 무엇일까?
반복 일정의 명령과 쿼리 분리하기
이 챕터에선 명령과 쿼리를 분리하지 않아서 버그를 만난 사례를 소개한다. 캘린더를 만들드는데 어떤 이벤트가 반복되는 일정(생일 등)인지를 판단하는 메서드가 있었다. 이 메서드는 Meeting.isSatisfied(Schedule schedule) 이었는데 이 메서드가 이벤트가 반복되는 일정에 포함되는지 확인하고, 포함되지 않는다면 이벤트 날자를 일정 날자로 변경하는 것이었다. 이는 쿼리인줄 알았던 메서드가 부수효과를 발생시키는 것이었고, 코드의 실행결과를 예측할 수 없게 만들었다. 부수효과를 발생시키는 쿼리는 버그를 양산한다. 따라서 이를 분리해서 isSatisfied(Schedule schdeule), reschedule(Schedule schdule) 인터페이스로 나눴고 결과적으로 코드는 예측 가능하고 이해하기 쉬우며 디버깅이 용이한 동시에 유지보수가 수월해 졌다.
명령-쿼리 분리와 참조 투명성
여기선 3가지 개념을 설명해야 한다. 바로 참조투명성과, 부수효과, 불변성이다.
부수효과 : 상태의 변경이 일어나는 것
참조 투명성 : 어떤 표현식(수학에서 f(x), 프로그래밍에서 isSatisfied())이 있을 때 표현식의 결과 값(프로그래밍에서 리턴값)으로 표현식이 나타나는 모든 위치를 교체하더라도 결과가 달라지지 않는 특성
불변성 : 표현식에 같은 인자를 넣으면 항상 같은 결과값이 나온다.
참조 투명성을 만족하는 식은 우리에게 두가지 장점을 제공한다.
모든 함수를 이미 알고 있는 하나의 결괏값으로 대체할 수 있기 때문에 식을 쉽게 계산할 수 있다.
모든 곳에서 함수의 결괏값이 동일하기 때문에 식의 순서를 변경하더라도 각 식의 결과는 달라지지 않는다.
책임에 초점을 맞춰라
앞서말한 모든 방식을 효과적으로 지키는 아주 쉬운방법이 있다.
메시지를 먼저 선택하고 그 후에 메시지를 처리할 객체를 선택하라.
디미터 법칙: 협력이라는 컨텍스트 안에서 객체보다 메시지를 먼저 결정하면 객체의 내부 구조에 대해 알지 못한 상태로 메시지를 선택하기 때문에 디미터 법칙을 위반할 위험을 최소화할 수 있다.
묻지 말고 시켜라: 메시지를 먼저 선택하면 클라이언트 관점에서 메시지를 선택하기 때문에 필요한 정보를 물을 필요 없이 원하는 것을 표현한 메시지를 전송하면 된다.
의도를 드러내는 인터페이스 : 메시지를 먼저 선택한다는 것은 클라이언트가 무엇을 원하는지, 그 의도가 분명하게 드러날 수 밖에 없다.
명령-쿼리 분리 원칙: 메시지를 먼저 선택하는 것은 협력이라는 문맥 안에서 객체의 인터페이스에 관해 고민한다는 것을 의미한다. 객체가 단순히 어떤 일을 해야 하는지뿐만 아니라 협력 속에서 객체의 상태를 예측하고 이해하기 쉽게 만들기 위한 방법에 관해 고민하게 된다. 따라서 예측 가능한 협력을 만들기 위해 명령과 쿼리를 분리하게 될 것이다.
앞서 살펴본 데이터 중심의 설계가 가지는 여러 문제를 해결할 수 있는 가장 좋은 방법은 책이 중심의 설계를 하는 것이다. 하지만 책임 중심의 설계는 어떤 객체에게 어떠 책임을 할당할지 결정하기 어렵다. 이를 해결하기 위해서 이번장은GRASP 패턴을 확인해 본다. 그리고 책임 주도 설계의 과정을 한 걸음씩 따라가 보면서 객체에 책임을 할당하는 기본적인 원리를 살펴본다.
01. 책임 주도 설계를 향해
책임 주도 설계는 2가지 원칙을 따라야 한다.
데이터보다 행동을 먼저 결정하라.
협력이라는 문맥 안에서 책임을 결정하라.
데이터보다 행동을 먼저 결정하라
객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다. 객체는 협력에 참여하기 위해 존재하며, 협력 안에서 수행하는 책임이 객체의 존재가치를 증명한다.
데이터는 행동에 필요한 재료일 뿐이다. 따라서 우리는 객체의 데이터에서 행동으로 무게중심을 옮겨야 한다. 이 목표는 객체의 행동, 즉책임을 먼저 결정한 후에 객체의 상태를 결정하므로써 달성할 수 있다.
협력이라는 문맥 안에서 책임을 결정하라
객체에게 할당된책임의 품질은 협력에 적합한 정도로 결정된다. 이때 협력에서 책임의 적합도는 메시지를 보내는클라이언트의 의도에 적합한 책임을 말한다. 이를 위해서메시지를 결정한 후에 객체를 선택해야 한다. 메시지를 결정한 후에 객체를 선택하게 된다면메시지 송신자(클라이언트 객체)는 수신자에 대해 어떤 가정도 할 수 없다.메시지 전송자의 관점에서 메시지 수신자가캡슐화 되는 것이다.
책임 주도 설계
이제 책임 주도 설계를 더 자세히 살펴 볼 것이다. 이를 위해서 책임 주도 설계의 흐름을 한번 더 확인해보자.
시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
시스템 책임을 더 작은 책임으로 분할한다.
분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 된다.
02. 책임 할당을 위한 GRASP 패턴
책임 할당 기법중에 가장 유명한 것은GRASP패턴이다. 이를 통해서 책임 할당을 살펴보자.
도메인 개념에서 출발하기
설계 전에 도메인에대한 개략적인 모습을 그려보는 것은 유용하다. 예컨데 요구사항을 달성하는데 필요한 요소들을 간단하게 모델링 해 보는 것이다. 이때 중요한 것은 도메인 모델에 시간을 오래 쓰지 말아야 한다. 도메인 개념들의 의미와 관계는 설계를 하기전에 유용한 정보를 제공할 수 있다는 것으로 충분하다.
완벽한 도메인 모델은 존재하지 않는다. 설계를 고도화 할수록, 그리고 코드를 작성할 수록 더 나은 설계가 나오기 마련이다. 다시한번 강조한다. 도메인 개념은 설계를 시작하기전에 유용한 정보를 제공하는 수준에서 멈춰야한다. 더 이상의 노력을 들이지 말자
정보 전문가에게 책임을 할당하라
애플리케이션이 제공해야 하는 기능을 애플리케[이션의 책임으로 생각하자. 그리고 이 책임을 애플리케이션에 대해 전송된 메시지로 간주하고 이 메시지를 책임질 첫 번째 객체를 선택하는 것으로 설계를 시작한다.
우린 앞서 책임 주도 설계에서 계속해서 책임을 나누고, 객체에 할당하는 과정을 반복해야 한다는 사실을 확인했다. 그럼 구체적으로 "책임을 나누는 방법"과 "객체에 할당하는 방법"은 무엇일까?
메시지를 전송할 객체는 무엇을 원하는가? 메시지(책임)은 메시지를 전송할 객체(클라이언트 객체)의 의도를 반영해서 결정해야 한다. 그래야 캡슐화를 성공적으로 구현할 수 있다. 메시지를 클라이언트 입장에서 정의 해야한다는 사실은 최범균님의 HOW보단 WHAT을 드러내라라는 조언과 일맥상통한다.
메시지를 수신할 적합한 객체는 누구인가? 객체는 자율적인 존재여야 한다. 따라서 책임을 수행할 정보(상태; 데이터)를 알고 있는 객체에게 책임을 할당해야 한다. 이를 GRASP에서는 INFORMATION EXPERT(정보 전문가) 패턴이라고 부른다. 이때 정보 전문가는 다른 객체에게 메시지를 보내서 얻을 수 있는 정보도 본인 소유의 정보라고 생각하는 것 이다. 그리고 객체가 메시지를 수행하기 위해서 메소드를 구현 할 때 필요에 따라서 메시지를 정의하고, 다른 정보 전문가를 찾는 것이다.
높은 응집도와 낮은 결합도
사실 동일한 기능을 구현하는 설계는 무수히 많다. 설계는 트레이드오프 활동이라는 것을 기억하라. 그럼 수많은 설계 중에 어떤 설계를 선택해야 할까?
높은 응집도와 낮은 결합도는 객체에 책임을 할당할 때 항상 고려해야 하는 기본 원리다. 이를 GRASP에서는 LOW COUPLING(낮은 결합도) 패턴, HIGH COHESION(높은 응집도) 패턴 이라고 부른다.
낮은 결합도를 달성하기 위해서는 이미 결합되어 있는 객체에게 메시지를 보내면 된다. 즉, 결합되는 객체의 수를 최소한으로 유지하라는 것이다.
높은 응집도를 달성하기 위해서는 객체의 주된 책임을 확인해서 더 적합한 객체에게 메시지를 보내라. 이는 변경할 이유를 하나로 유지하는 방법에 대한 논의로, 이미 해당 객체가 변경될 이유에서 새로운 이유가 추가되지 않는다면 높은 응집도를 유지한 상태로 메시지를 처리할 수 있게 되는 것이다.
창조자에게 객체 생성 책임을 할당하라
객체 A를 생성해야할 책임은 아래 조건을 최대한 많이 만족하는 B에게 할당해야 한다.
B가 A 객체를 포함하거나 참조한다.
B가 A 객체를 기록한다.
B가 A객체를 긴밀하게 사용한다.
B가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다.(이 경우 B는 A에 대한 정보 전문가다.)
이러한 방식을 GRASP에서는 CREATOR(창조자) 패턴이라 칭한다. 이는 이미 결합돼 있는 객체에게 생성 책임을 할당하는 것으로 설계의 전체적인 결합도에 영향을 미치지 않도록 하는 것이다.
03. 구현을 통한 검증
DiscountCondition 개선하기
설계를 개선하는 작업은 변경의 이유가 하나 이상인 클래스를 찾는 것으로부터 시작하는 것이 좋다. 이는 클래스의 응집도가 낮은 것인데, 클래스의 응집도를 판단할 수 있는 세 가지 방법이 있다.
클래스가 하나 이상의 이유로 변경돼야 한다면 응집도가 낮은 것이다. 변경의 이유를 기준으로 클래스를 분리하라
클래스의 인스턴스를 초기화하는 시점에 경우에 따라 서로 다른 속성들을 초기화하고 있다면 응집도가 낮은 것이다. 초기화되는 속성의 그룹을 기준으로 클래스를 분리하라.
메서드 그룹이 속성 그룹을 사용하는지 여부로 나뉜다면 응집도가 낮은 것이다. 이들 그룹을 기준으로 클래스를 분리하라.
타입 분리하기
DiscountCondition는 순번조건과 기간조건이라는 두개의 타입을 하나의 클래스에서 처리한다. 이는 앞서 말한 개선번으로, SequenceCondition과 PeriodCondition으로 분리하면 된다. 그리고 Movie가 기존에 DiscountCondition만 의존하고 있던 상황을 SequenceCondition과 PeriodCondition을 동시에 의존하도록 코드를 변경하면 된다. 그런데 문제가 생겼다. 응집도를 높히려다 보니까 덩달아 시스템의 전체적인 결합도가 높아져 버린 것이다. 이는 다음과 같은 문제를 발생시킨다.
Movie클래스가 PeriodCondition과 SequenceCondition 클래스 양쪽 모두에게 결합된다는 것
새로운 할인 조건을 추가하기 어려워졌다. 새로운 할인조건은 Movie 클래스에게 새로운 의존성은 물론이고, 새로운 메서드까지 추가하게 만든다.
다형성을 통해 분리하기
사실 Movie입장에서 PeriodCondition과 SequenceCondition에게 보내는 메시지는 동일하다. 즉, 동일한 책임들을 수행하는 것이고, 같은 역할을 수행한다는 것이다. 협력안에서 역할은 대체 가능성을 의미하기 때문에, Movie는 구체적인 클래스는 알지 못한 채 오직 역할(Interface or Abstract)에 대해서만 결합되도록 의존성을 제한할 수 있는 것이다.
이 사례에서 알 수 있듯, 객체의 구체적인 타입에 따라 행동을 분기해야 한다면 명시적인 클래스를 정의해서 메시지를 수신하고 행동을 나눔으로써 응집도 문제를 해결할 수 있다. 이를 GRASP에서는 POLYMORPHISM(다형성) 패턴이라고 부른다.
프로그램을 if ~ else 또는 switch ~ case 등의 조건 논리를 사용해서 설계한다면 새로운 변화가 일어난 경우 조건 논리를 수정해야한다. 이럴 때 POLYMORPHISM 패턴은 객체의 타입을 검사해서 타입에 따라 여러 대안들을 수행하는 조건적인 논리를 사용하지 말라고 경고한다.
변경으로부터 보호하기
새로운 할인 조건을 추가하는 경우에는 어떻게 해야할까? 그냥 DiscountCondition을 상속받는 새로운 조건 객체를 만드는 것 만으로 충분하다. 어차피 Movie는 DiscountCondition이라는 인터페이스에 의존하기 때문에 전혀 문제가 없다.이처럼 변경을 캡슐화하도록 책임을 할당하는 것을 GRASP에서는 PREOTECTED VARIATIONS(변경 보호) 패턴이라고 부른다.
변화가 예상되는 지점을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라. 우리가 캡슐화해야 하는 것은 변경이다.
Movie 클래스 개선하기
Movie 클래스도 응집도가 낮다. 금액 할인 정책과 비율 할인 정책 두 가지 타입을 한 클래스에서 구현하고 있기 때문이다. 이를 개선하기 위해서 POLYMORPHSM 패턴을 적용하자. 할인 정책을 타입별로 분리하고, 메시지로만 협력하게 하는 것이다. 그리고 우리는 이를통해 PROTECTED VARIATIONS 패턴의 목표도 달성할 수 있다.
책에서는 Movie를 추상클래스로 만들고 AmountDiscountMovie, PercentDiscountMovie, NoneDiscountMovie 3가지 구체클래스로 상속받아 구현했다. 이 방식을 통해서 Movie의 공통되는 구현을 재사용하고 타입을 나눠서 POLYMORPHISM 패턴을 구현했다. 이 방식은 흔히 말하는 Template Method Pattern(템플릿 메소드 패턴)이다. 이 방식을 통해서 특정 작업을 처리하는 일부분을 서브 클래스로 캡슐화하여 전체적인 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내용을 바꿀 수 있다. 자주 사용하는 패턴이기도 하고, 다형성을 효과적으로 수행하는 방식이다(물론 코드 재사용을 위한 상속은 좋지 않다. 상속보다는 합성임을 기억하자). 단적인 예로 Spring Framework에서 AOP를 구현하기 위해서 Template Method Pattern을 변형해서 사용했다.
위의 그림은 최종 결과물이다. 그런데 이 그림은 앞서 만든 도메인 모델과 유사하다. 우린 도메인 모델을 만들 때 할인 정책과 할인 조건이 변경될 수 있다는 직관을 포함했다. 그리고 이 직관은 우리의 설계를 유연하게 만들었다. 도메인의 역할은 구현을 가이드하는 것이다. 객체지향은 도메인의 개념과 구조를 반영한 코드를 가능하게 만들기 때문에 도메인의 구조가 코드의 구조를 이끌어 내도록 해야 하는 것이다.
변경과 유연성
설계를 주도하는 것은 변경이다. 변경을 대비할 수 있는 방법은 2가지가 있다.
코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계 하는 것
코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만드는 것
앞선 그림에서 Movie를 상속해서 할인 정책을 구현현했다. 그런데 실행중 할인 정책을 변경해야 한다면 문제가 생긴다. Movie를 상속받은 객체를 다시 생성해서 필요한 정보를 복사해야한다. 또한 새로 생성된 객체는 물리적으로 다를 객체이기 때문에 모든 식별자를 갱신해 줘야하는 어려움도 있다.
2장에서 코드를 재사용하기 위해서는 합성을 사용하라고 조언했다. 이처럼 DiscountPolicy 인터페이스를 만들어서 할인정책을 캡슐화해보자.
이제 Movie에 연결된 DiscountPolicy를 교체하는 것만으로 할인 정책을 변경할 수 있다. 객체를 복사할 필요도, 식별자를 갱신할 필요도 없다.
우리는 변경을 대비하기 위해 코드의 구조가 바뀌는 모습을 지켜봤다. 그럼 도메인에 대한 관점도 변경되어야 한다.
도메인 모델은 구현과 밀접한 관계를 맺어야 한다. 도메인 모델은 코드에 대한 가이드를 제공할 수 있어야 하며 코드의 변화에 발맞춰 함께 변화해야 한다.
하지만 여전히 책임을 올바르게 할당하는 것은 어려운 일이다. 이를 위해 책임 주도 설계가 아닌 두번째 대안을 제시한다. 바로 절차형 코드로 실행되는 프로그램을 빠르게 작성한 후 완성된 코드를 객체지향적인 코드로 변경하는 것이다.(어쩌면 실무에서 더 많이 사용되고 있는 방법이다)
04. 책임 주도 설계의 대안
숙련된 설계자도 적절한 책임과 객체를 선택하기는 어렵다. 아무것도 없는 상태에서 책임과 협력에 관해 고민하기 보다는 빠르게 실행되는 코드를 얻고 리팩토링 하는 방법도 좋은 방법이다. 이때 주의할 점은 코드를 수정한 후에 겉으로 드러나는 동작이 바뀌면 안된다는 것이다. 동작을 유지한 채 캡슐화를 향상시키고, 응집도를 높이고, 결합도를 낮춰야한다.
이 방식을 확인하기 위해서 4장에서 만든 데이터 중심 설계를 리팩토링 해보자.
메서드 응집도
데이터 중심의 설계에서는 객체는 단지 데이터의 집합이며, 모든 절차는 ReservationAgency에 집중되어있다.
처음으로 할일은 응집도 높은 메소드로 ReservationAgency를 나누는 것이다. 긴 메서드는 다양한 단점을 가진다.
코드를 이해하는 데 시간이 오래 걸린다.
변경이 발생하면 수정할 부분을 찾기 어렵다.
일부 로직을 수정하면 나머지에서 버그가 발생한다.
로직의 일부를 재사용할 수 없다.
재사용을 위해서 코드를 복붙한다.(코드의 중복이 발생한다.)
이런 긴 메소드를 몬스터 메서드(monster method)라고 부른다.
메서드의 응집도를 높힌다는 것은 메서드가 단 하나의 이유로 변경된다는 것이다. 메서드 응집도를 높히면 각 메서드를 적절한 클래스로 이동시키기 쉬워진다.
평소에 내가 줄기차게 주장하던 하나의 메서드는 같은 수준의 지시문(private method 등)을 나열해야한다는 내용과 일맥상통한다. 이를 통해 public 메서드는 상위 수준의 명세를 읽는 것 같은 느낌이 들 수 있도록 하는 것이다.
메서드의 응집도를 높히므로서 이제 ReservationAgency 클래스는 오직 하나의 작업만 수행하고, 하나의 변경이유만 가지는 작고, 명확하고, 응집도가 높은 메서드들로 구성돼 있다. 이를 통해 앞서 언급한 긴 메스드의 단점을 모두 해결할 수 있었다. 그리고 이제 메서드를 적절한 위치로 이동시키자. 적절한 위치는 바로 메서드가 사용하는 데이터를 정의하고 있는 클래스이다.
객체를 자율적으로 만들자
자신이 소유하고 있는 데이터를 자기 스스로 처리하도록 만드는 것으로 자율적인 객체를 만들 수 있다. 이를 위해 메서드 안에서 어떤 클래스의 접근자 메서드를 사용하는지 파악하고, 그 객체로 메서드를 옮겨보자. 이를 통해서 캡슐화와 높은 응집도, 낮은 결합도를 가지는 설계를 얻게된다. 여기에 POLYMORPHISM 패턴과 PROTECTED VARIATIONS 패턴을 차례대로 적용하면 우리가 원하는 설계를 얻을 수 있다.
