> For the complete documentation index, see [llms.txt](https://injun-woo30000.gitbook.io/growth-log/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://injun-woo30000.gitbook.io/growth-log/daily-review/2021/april/2021-04-08-thu.md).

# 2021-04-08(Thu)

| 항목         | 내용                            |
| ---------- | ----------------------------- |
| 학습 날짜      | 2021-04-08(목)                 |
| 학습 시간      | 09:00\~23:00                  |
| 학습 범위 및 주제 | Eager Loading vs Lazy Loading |
| 학습 목표      | Rails를 헷갈렸던 부분을 정리한다.         |
| 동료 학습 방법   | -                             |

## 상세 학습 내용

### Rails 개념 보충

#### Eager loading vs Lazy loading

**Lazy Loading은 연관된 데이터들을 실제로 접근하기 전에는 로딩하지 않는다.** Lazy loading의 예시를 보자.

```
users = User.where(status: 'active').joins(:profile)
users.each do |user|
  user_date << {
    name = user.name
    age = user.profile.age
  }
end
```

데이터에 접근하기 위해 users를 호출하는 1번의 쿼리를 날리고, 이후 do 루프에서 `user.profile.age` 구문에 의해 profile에 접근할 때마다 N번의 쿼리를 추가로 날리게된다.

**이런 문제를 N+1 Problem라고 한다. 근본적으로 ORM에서 Lazy Loading을 사용할 때 발생되는 문제인 것이다.**

Rails는 이런 문제를 해결하기 위해 `includes`라는 메서드를 제공해준다.

> With includes, Active Record ensures that all of the specified associations are loaded using the minimum possible number of queries

자 아래처럼 코드를 수정해보자.

```
users = User.where(status: 'active').includes(:profile)
users.each do |user|
  user_date << {
    name = user.name
    age = user.profile.age
  }
```

위 코드에서는 두 번의 쿼리가 발생한다. users 데이터를 찾을 때 한번, users에 대한 profile을 찾는데 한번. 이러한 로딩 방식을 eager loading이라고 부른다.

그럼 `joins`가 `includes`보다 효율적인 경우는 무엇일까? 아래처럼 필터의 역할을 할 경우 효율적이다.

```
users = User.joins(:profile).where('profile.status = ?', 'active')
users.each do |user|
  user_date << {
    name = user.name
  }
end
```

do 루프에서 profile의 데이터를 사용하지 않고, profile은 단지 filter의 역할을 하는 것이다.

* [참고 1](https://medium.com/sjk5766/laravel-n-1-problem-88e1674e652e)

## **MSA란?**

* 단일 애플리케이션을 작은 서비스 suite로 개발하는 방법.
* 각각 자체 프로세스에서 실행되고 가벼운 연결방식, 대개는 HTTP 기반 API와 통신한다.
* 비즈니스 기능을 중심으로 구축되며 완전 자동화 된 배포 머신을 통해 독립적으로 배포할 수 있다.
* 최소한의 중앙 집중식 관리가 있으며, 다른 프로그래밍 언어로 작성되고 다른 데이터 저장 기술을 사용할 수 있다.

### 장점

* 장애 격리와 복구가 쉽다. 장애난 서비스만 장애나니까.
* 비용 효율적으로 증설이 가능하다. 증설이 필요한 서비스만 증설시키면 되기 때문이다.
* 서비스 개선 속도가 증가한다. 빠른 배포가 가능하다.
* 생산성 향상이 될 수 있다. 코드양이 적어 쉽게 수정이 가능하다.
* 신기술 도입이 쉽다.
* Polyglot을 적용할 수 있다. 서비스에 최적화된 개발 언어와 데이터베이스를 선택하기 쉽다.

### 고려해야할 것

* MSA에 적합한 서비스인가?
  * 빠르고 잦은 배포를 필요로 하는가?
  * 성능에 민감한 서비스인가? 마이크로서비스면 잦은 통신이 필요하므로 성능 이슈가 있을 수 있다.
  * 분산 트랜잭션이 있는 서비스인가? 한번에 트랜잭션을 쓸 수가 없다.
* 데이터의 중복성을 허용해야한다.
* 배포 및 릴리즈를 자동화해야한다. 서비스가 많다보니 자동화가 되지 않으면 운영에 굉장한 부담이 발생할 수 있다.
* MSA 서비스에 맞는 팀이 운영되어야 한다.

![image](https://user-images.githubusercontent.com/54612343/114047621-c7523e80-98c4-11eb-8a00-1eb651846609.png)

NHN 페이코의 도메인별 MSA 구축 사례.

![image](https://user-images.githubusercontent.com/54612343/114047876-fd8fbe00-98c4-11eb-98b9-8e64f1945a80.png)

소스 중복, 배포주기, 트래픽 유입, 분산트랜잭션 줄여야하는 부분들 고려해서 도메인 다시 결합했다고함.

## **학습 내용에 대한 개인적인 총평**

커머스 분야 백엔드 개발자가 되고 싶다.

## **다음 학습 계획**

* QR 코드 리더기에 테이블 붙이기