13. Mass Storage Management

Mass Storage란 하드 디스크와 같은 2차 저장장치를 의미한다.

 

Physical Disk Structure

기본적인 하드 디스크의 구조와 동작 방식에 대해 알아보자.

요즘은 2차 저장장치로 하드 디스크 대신 SSD도 많이 사용하지만, 아직까지는 하드 디스크를 많이 사용하고 있기 때문에 하드 디스크 사용을 전제로 설명한다.

 

하드 디스크를 옆에서 본 모습과 위에서 본 모습은 위의 그림과 같다.

데이터를 기록할 수 있는 플래터들이 있고, 플래터에 값을 쓰고 읽는 것은 스핀들에 연결된 헤드가 한다.

이론적으로 platter 하나에 헤드가 2개 붙을 수 있다. 앞면에 하나, 뒷면에 하나

그리고 스핀들 하나에 모든 헤드들이 달려있기 때문에 스핀들을 움직이면 모든 헤드가 동시에 움직이게 된다.

다른 Platter에 있더라도 같은 위치의 Track에 있는 데이터들은 모두 동시에 읽을 수 있다.

같은 위치의 Track들을 모두 모으면 원기둥(Cylinder) 모양이 만들어질 것이다. 이 원기둥에 있는 데이터는 모두 동시에 읽을 수 있다.

 

기본적으로 플래터는 계속해서 돌아가고 있고, 원하는 부분에 헤드를 옮겨서 원하는 데이터를 읽는 방식이다.

한 Track 안에 모든 데이터가 저장되어 있으면 최초의 한 번 헤드 움직임으로 모든 데이터를 읽을 수 있겠다는 생각을 할 수 있다.
=> 연속된 공간에 데이터를 저장하면, 헤드 한 번의 움직임으로 모든 데이터를 읽을 수 있다는 뜻.

 

원하는 부분의 Sector를 읽기 위해서는 어떤 정보가 있어야 할까.

먼저 Cylinder의 번호를 결정한다. 실린더의 번호를 결정한다는 것은 스핀들을 움직여서 헤드의 위치를 결정짓는다는 의미이다.  그런 다음 하나의 실린더에는 여러 surface의 track들이 들어 있는데, 그 중 어떤 surface의 track을 읽을 것인지를 명시해야 한다. 이건 Head의 번호로 지정할 수 있다.

마지막으로 특정 Track내에서 어떤 sector를 읽을 것인지를 명시해야 한다.
=> 특정 Sector를 읽기 위해서는 Cylinder #, Head #, Sector #를 명시해야 한다.
=> 줄여서 CHS체계라고 한다.

하드 디스크의 주소 체계는 CHS 체계이다.

 

하드 디스크에서 데이터를 읽는 시간은 3단계로 나눠볼 수 있다.

1. Seek time

물리적으로 스핀들을 통해 헤드를 움직여 원하는 track을 읽을 수 있도록 하는 것이다.

2. Rotational delay

원하는 track에 헤드를 위치시킨 후에는 플래터가 회전해서 원하는 섹터를 읽을 수 있을 때까지 기다려야 한다.

=> 평균적으로 반 바퀴 정도의 Rotational delay가 있다.

3. Transfer time

원하는 트랙의 원하는 섹터에 헤드가 위치하게 되었다면 이제 데이터를 읽어야 한다.

 

이 중 가장 오래래 걸리는 것은 당연히 물리적으로 Head가 움직이는 시간인 Seek time이다.

그 다음 Rotational delay, Transfer time 순으로 오래 걸린다.

Rotational dealy를 줄이기 위해서는 플래터가 회전하는 수 밖에 없는데, 이것은 OS가 어떻게 할 수 없는 영역이다.

그렇다면 우리는 Seek time을 최대한 줄여서 Disk I/O에 걸리는 시간을 줄여볼 수 있겠다.

 

Disk Structure

하드 디스크의 위치를 나타내는 정보를 OS는 LBA라고 알고 있다.
=> Logical Block Address

디스크와의 데이터 교환은 블럭 단위로 일어나기 때문에 OS는 하드 디스크의 주소 체계를 0번 Block, 1번 Block 이런 식으로만 알고 있다.

이 Block의 번호를 실제 Sector에 매핑을 해야 하는데, OS는 이러한 디테일까지는 모르고 이건 하드 디스크의 컨트롤러가 하게 된다.

 

일반적으로 Sector 0(zero)는 가장 위쪽 Surface의 가장 바깥 쪽 Track의 0번째 Sector를 의미한다.
sector 0를 시작으로 순차적으로 sector들에 번호를 할당한다.
=> 같은 트랙 내의 이웃한 섹터들을 순서대로 1번, 2번 섹터로 번호를 붙일지, 같은 실린더의 다른 플래터에 있는 섹터부터 2번, 3번을 붙일지는 하드 디스크마다 다르다. 이걸 정하는 건 하드 디스크 내부의 문제로 우리는 알 필요 없다.

 

Disk scheduling

하드 디스크에 접근하는 것은 매우 오래 걸리는 작업이기 때문에 이것을 최대한 줄이기 위해서 OS는 들어온 명령의 순서를 처리하는 순서를 정하게 되는데, 이것을 Disk Scheduling이라고 한다.

디스크에 접근하는 시간 중 대부분은 물리적으로 헤드를 움직이는 시간인 Seek time이 차지한다.

상식적으로 헤드가 멀리 움직이면 seek time이 증가할 것이다.
=> 헤드가 움직이는 거리인 seek distance에 seek time이 비례할 것이라는 것은 쉽게 생각할 수 있다.

 

Seek Time Benchmark

하드 디스크에 접근하기 위한 기본적인 시간을 제외하면, seek time은 distance의 루트에 비례한다는 것을 확인할 수 있다.

상수 a, b는 하드 디스크 마다의 특성에 따른 상수 값이고, distance의 루트 값에 비례해서 Seek time이 증가하게 된다.

=> Seek distance를 줄이면 Seek time을 줄일 수 있겠다!

 

애플리케이션에서 들어온 요청의 순서와 무관하게 OS가 하드 디스크에 요청하는 순서를 결정하는 일을 디스크 스케줄링이라고 한다.

디스크 스케줄링에 따라 Seek time이 달라질 수 있다.

 

OS의 입장에서 우리가 기대할 수 있는 건, LBA(Logical Block Address)가 연속되어 있으면 실제 디스크 상에서도 연속된 블럭일 것이라는 것이다.
정확히는 모르지만 OS는 그렇다고 믿고 일을 하겠다.

웬만하면 LBA가 연속적이면 같은 Track에 있을 것이라 믿고 일을 하겠다.
만약 연속적이지 않더라도 최대한 번호가 가까운 것부터 먼저 처리를 해주면 seek distance가 줄어들 것이다.

=> OS는 실제 디스크의 내부에 대해서는 알 수 없고, LBA를 통해 접근하기 때문에 LBA가 연속되어 있으면 실제로도 연속되어 있을 것이라 믿고 스케줄링을 하게 된다.

 

FCFS

스케줄링에서 빠지지 않고 등장하는 것이 FCFS(First Come First Served) 방식이다.

디스크 스케줄링도 스케줄링이기 때문에 FCFS는 무조건 고려된다.

하지만 들어온 순서대로 처리하면 헤드는 총 640실린더 만큼의 거리를 움직여야 한다.

=> 뒤에 나올 다른 정책들을 보면 알 수 있겠지만 굉장히 비효율적이다.

 

SSTF

SSTF는 현재 Head의 위치에서 가장 가까운 실린더를 먼저 service 해주자는 방식이다.

Seek distance 차원에서 SSTF가 좋다는 것은 당연한 생각이다.
그럼 이 정책을 쓰면 될까?

Seek time면에서 효율적이겠지만, CPU 스케줄링에서의 SJF 방식과 동일하게 Starvation 문제가 발생한다.

현재 헤드의 위치의 근처에 해당하는 요청이 계속 들어오면 멀리 있는 애들은 계속 서비스를 못 받게 될 수 있다.
=> Starvation 문제 발생 가능

또한 Starvation 문제 뿐 아니라 Fairness 문제가 발생한다.

예시에서 183번은 초기에 요청이 들어왔는데 제일 마지막에 서비스를 받았다.

이 시간 내에 서비스를 받을 것이라는 upper bound가 없기 때문에 performance에 대한 예측 가능성이 없다.
=> 이러한 문제들로 인해 함부로 사용할 수 없다.

 

SCAN

일명 Elevator Algorithm으로도 불리는 SCAN 알고리즘은 현재 내가 진행하고 있는 방향에 존재하는 모든 요청들을 처리하면서 한쪽 방향으로 진행하겠다는 정책이다.

그쪽 방향으로 진행이 끝이 나면 방향을 바꿔서 반대쪽으로 내려가면서 또 그 방향에 있는 요청들을 처리하겠다.

=> 엘리베이터가 위 아래로 왔다갔다 하는 것과 비슷하기 때문에 Elevator Algorithm으로도 불린다.

SCAN 알고리즘에서는 진행하던 도중에 방향을 바꾸는 일은 없다. 끝까지 가야지 방향을 바꾼다.

그림에서 알 수 있듯이, 반드시 끝까지 도달해야 진행 방향을 반대로 바꾼다.

SCAN 알고리즘은 SSTF가 가지고 있는 문제점을 어떻게 해결하나?

한 번 왔다갔다 하는 사이에는 반드시 모든 요청이 처리가 될 것이므로, startvation이 발생하지 않고, 처리 시간의 upper bound가 제공된다는 장점이 있다.

=> 끝에서 끝까지 이동하는 시간 내에는 반드시 서비스가 될 것이다.

그렇기 때문에 많은 OS들이 SCAN 알고리즘을 기반으로한 디스크 스케줄링 알고리즘을 사용하고 있다.

 

그렇다면 SCAN 알고리즘에는 문제가 없을까??

현재 진행하고 있는 방향에 더 이상 요청이 없음에도 불구하고 방향을 바꾸지 않고 끝까지 간다.
그런데 이건 문제로 봐야할지 아닐지 판단할 수 없다. 진행하는 도중에 해당 경로에 요청이 들어올 수도 있기 때문이다.
=> 하지만 그렇지 않을 가능성이 높기 때문에 의미가 떨어진다고는 할 수 있다.

또한 양 끝단에 있는 0번과 199번의 경우엔 한 번 왔다갔다 하는 동안 서비스를 받을 기회가 한 번 밖에 없다는 문제가 있다. 그 사이에 있는 애들은 왔다 갔다 하는 동안 2번의 기회를 갖는다.

끝단에 가까운 요청일수록 중간에 있는 애들에 비해 최악의 경우에 걸릴 수 있는 시간이 더 길어지는 현상이 있다.
=> 공평성의 문제가 발생

그런데 두 가지 모두 큰 문제는 아니다.

 

C-SCAN(Circular SCAN)

앞서 보았던 SCAN 방식과 유사하지만, 양쪽으로 왔다갔다 하는 SCAN 방식과 달리 C-SCAN 방식은 한 쪽 방향으로만 이동하면서 요청을 처리한다.

SCAN의 문제점 중 하나인 양 끝에 있는 애들은 기회가 더 적다는 문제를 해결하기 위해 만든 방법이다.

끝에 도달하면 방향을 바꿔서 다시 요청을 처리하면서 진행하는 것이 아니라, 요청을 처리하지 않고 시작점으로 재빠르게 돌아온다.

반대로 돌아올 땐 매우 빠르게 돌아오기 때문에 처리 시간의 upper bound가 헤드가 한 쪽 방향으로 끝까지 이동하는 시간만큼이된다.

 

C-SCAN에는 문제가 없는 것은 아니다.

돌아올 때에는 아무것도 하지 않고 돌아온다는 문제를 가지고 있고, SCAN이 가지고 있던 문제 중 하나인 더 이상 해당 방향에 요청이 없음에도 끝까지 간다는 문제는 여전히 해결하지 못하고 있다.

한 쪽 방향으로만 이동하는데 왜 Circular SCAN일까?
돌아올 때는 아무것도하지 않고 재빠르게 돌아오기 때문에 사실 양 끝이 이어져있는 것과 마찬가지다.
199번을 처리하고 나서 바로 0번으로 돌아오기 때문에

 

C-LOOK

C-SCAN처럼 한 쪽 방향으로만 이동하는 것은 동일하지만 전진하는 진행 방향 상에 아무런 요청도 없다면 더 이상 진행하지 않고 돌아오는 방식이다.
=> 전진하면서 요청이 있는지 보면서 가겠다는 의미에서 C-LOOK이라고 한다.

C-LOOK은 한쪽 방향으로만 이동하지만 양방향으로 이동하는 LOOK 방식도 있다.

C-SCAN에 대응되는 방식이 C-LOOK이고, SCAN에 대응되는 방식이 LOOK이다.

 

Arm Stickiness Problem

앞에 나온 방식들 중에 SCAN, C-SCAN, SSTF의 경우엔 공통적으로 Arm Stickiness Problem이라는 문제를 갖는다.
그러면 왜 앞에서 얘기하지 않았느냐.
매우 희박하게 발생하는 문제이기 때문에 별도로 다룬다.

현재 헤드의 위치가 15번 실린더에 있고 그 뒤로 6번 하나와 나머지는 다 15번이 연속해서 들어온다면,
SCAN, C-SCAN, SSTF 모두 15번을 먼저 처리하게 될 것이다.

=> SSTF는 현재 Head에서 가장 가까운 요청을 처리하고, SCAN, C-SCAN은 현재 진행방향 상에 있는 요청들을 모두 처리하기 때문이다.

그러면 6번은 계속해서 처리가 될 수 없다.

이게 왜 문제냐 하면 앞에서 SCAN, C-SCAN의 경우에는 Starvation이 발생하지 않고, 처리되는 시간의 upper bound를 제공한다고 했는데 이 경우에는 6번에 대해서 starvation이 발생하게 된다.
=> 하지만 매우 희박하게 발생하는 현상이다.

 

헤드가 현재 읽고 있는 실린더에 계속해서 요청이 들어오면 헤드가 움직일 필요가 없다.
=> Arm이 딱 붙어버렸다고 해서 Arm Stickiness Problem이라 불린다.

 

Disk Management

Logical formatting은 파일의 데이터는 그대로 둔 채로 파일 시스템의 모든 메타 데이터들을 지움으로써 아무런 파일에 대한 정보를 갖고 있지 않으므로 디스크가 빈 것과 같은 효과를 내는 것이다.

반면 Physical formatting은 실제 모든 데이터들을 지우는 것이다.

이때 디스크를 섹터 단위로 작게 잘라서 포매팅을 하게 된다.
개념적으로는 섹터를 512B 단위로 자르지만, 실제로는 메타 데이터인 head와 trailer까지 붙여서 자르기 때문에 512B보다 조금 더 크게 자르게 된다.

header와 trailer에는 데이터에 에러가 발생했는지를 나타내는 ECC가 들어 있다.
formatiing할 때 이것을 확인해서 에러가 발생했으면 Bad sector임을 알린다.

한 번 Bad가 난 Sector는 다음에 또 Bad가 날 확률이 높기 때문에 한 번 Bad Sector가 된 Sector는 더 이상 사용하지 않는다.

그런데 OS는 이 Sector의 번호와 LBA가 매핑되어 있기 때문에 계속해서 여기에 쓰라고 요청을 할 것이다. 그렇기 떄문에 연결을 끊고, 여분으로 남겨둔 Sector와 다시 매핑해준다.

 

partition은 물리적인 Disk를 논리적인 Disk로 만들어주는 기능이다.

파티션 하나를 만들게 되면 OS는 그 파티션을 하나의 별도의 디스크로 생각하게 된다.
실제로는 하나의 디스크지만 OS는 물리적인 디스크가 2개인 것처럼 관리를 한다.

 

RAID (Redundant Array of Inexpensive Disks)

디스크에 대한 접근은 매우 느리기 때문에, 여러 개의 Disk를 동시에 가동하면 성능이 좋아지지 않을까라는 생각을 할 수 있다.
=> 문제는 이것을 하나의 Disk처럼 보이게 만들어야 한다는 것이다.

디스크를 여러 개를 사용해서 용량과 속도를 높이겠다는 아이디어.

그러나 여러 개의 디스크를 하나의 디스크처럼 사용하기 때문에, N개의 디스크 중에 하나라도 고장나면 시스템 전체가 고장나게 된다는 문제가 있다.

=> 고장날 확률이 높아진다.

그렇기 때문에 데이터를 여러 곳에 중복적으로 저장함으로써 하나의 디스크가 고장난다고 하더라도 다른 디스크의 데이터를 이용해서 계속해서 서비스를 제공할 수 있도록 한다.

여러 디스크에 데이터를 저장하려면 데이터를 분할해서 저장해야 한다.
=> 데이터를 분할하는 방식과 데이터를 중복적으로 저장하는 방식을 결정해야 겠다.

 

하나의 디스크가 고장나면 전체가 고장나버린다는 신뢰도 문제를 해결하기 위해서 같은 데이터를 여러 번 저장할 수 있다.

예를 들어 Mirroring 방식에서는 각각의 Disk를 Duplicate해서 하나 더 둔다.

10개의 Disk를 가지고 RAID를 구축한다고 하면, 사실상 5개를 구축하는 것이고 나머지 5개는 쌍둥이 Disk를 만드는 것이다.
=> 전체 용량의 절반밖에 사용하지 못 한다는 문제가 있지만, 복사본이 있기 때문에 신뢰성은 높아진다.

Mirroring된 디스크와 원본 디스크가 동시에 고장나야 서비스를 제공하지 못하게 된다.
=> 그럴 확률은 매우 낮다.

예를 들어 디스크를 고치는데 10시간이 걸린다고 하면, Mirroring된 디스크까지 고장이나서 서비스를 제공하지 못 하게 되려면 10시간 내에 Mirroring된 디스크까지 고장이 나야 하는데 그럴 확률은 극히 드물다.

 

성능 측면에서 생각해봤을 때, 데이터를 어떻게 분할해서 저장할 것이냐에 따라 기법이 달라진다.

파일별로 데이터를 분할한다고 하면, 그 파일을 읽기 위해서는 결국 하나의 디스크에서 읽어야 하므로, 디스크 여러 개를 사용하는 의미가 없다.

RAID에서는 파일별로 분할하지 않고 어떻게 분할할 것인가?

파일 내의 데이터를 잘라서 분할해야 할 것이다.

자르는 사이즈에 따라 Bit-level striping과 Block-level striping으로 나뉜다.

 

• Bit-level striping

Bit 단위로 분할해서 저장하게 되면, 한 바이트를 읽을 때도 여러 DIsk에서 읽을 수 있다.

그럼 좋을까? 안 좋다.

하나의 디스크 내에서 한 bit만 읽고 다음 bit를 읽기 위해서 또 다시 Disk seek이 발생할 수 있다. 
=> 비트마다 Seek가 발생할 수 있기 때문에 이 방법은 못 쓴다.

 

• Block-level striping

한 파일 내의 데이터를 블럭 단위로 나눠서 저장한다.
=> 요즘 대부분의 RAID가 Block-level striping을 쓴다.

한 파일을 접근할 때 5개의 블럭을 읽어야 한다고 하면, 5개의 블럭을 5개의 디스크에서 동시에 읽을 수 있게 된다면 속도가 5배 빨라질 것이다.

 

RAID Levels

Redundancy 전략과 데이터를 분할하는 Striping 전력을 결합시켜서 어떤 RAID를 구축할 수 있을까.

 

RAID Level 0

RAID Level 0는 데이터는 블럭 단위로 나눠서 저장하고 신뢰성을 높이기 위한 정책은 사용하지 않겠다.
=> 데이터를 잃어버려도 신경쓰지 않겠다. Only 성능만 중요.

별로 중요하지 않은 데이터를 저장하지만 성능이 중요할 때는 RAID Level 0를 사용할 수 있을 것이다.

 

RAID Level 1

데이터는 블럭 단위로 분할하고, Mirrored disk를 사용하겠다.
=> RAID Level 1을 사용하면 특정 블럭에 데이터를 쓰고자 할 때 write가 한 번만 일어난다는 장점이 있다.
=> 다른 방식의 경우엔 여러 번이 발생할 수 있다. 이건 뒤에서 보겠다.

 

RAID Level 2, 3

RAID Level 2와 3는 Bit, Byte 단위로 striping을 하기 때문에 Seek가 너무 많이 발생해서 사용되지 않는다.

 

RAID Level 4

Block level striping을 하고 신뢰성 향상을 위해 Parity Block을 사용한다.

Parity는 Odd Parity가 될 수도 있고, Even Parity가 될 수도 있다.

 

각 디스크마다 같은 위치에 있는 블럭에 대해서 Parity Block을 만들어서 Parity disk에 저장한다.

Even parity를 사용한다고 했을 때 (0이 짝수개),
만약 4개의 Disk의 0번 블럭의 첫 번째 비트가 각각 1, 1, 0, 0 이라고 하면 Parity Block의 첫 번째 비트는 1이 된다.

블럭에 데이터를 write할 때마다 Parity block도 수정해야 한다는 문제가 있다.

그렇기 때문에 Read Operation도 추가된다. 블럭에 데이터를 쓰기 전에, 쓰고자 하는 블럭의 원본 데이터를 읽어서 데이터를 수정한 후에 bit가 바뀌었다고 하면 Parity block의 bit도 바꿔주어야 한다.

이러한 오버헤드가 있긴 하지만, 여러 디스크에서 동시에 I/O가 일어난다는 성능 향상이 더 크기 때문에 이 방법을 사용할 수 있다.

 

디스크가 고장나면 고장난 디스크를 빼고 새로운 디스크를 장착한 다음 나머지 살아있는 디스크들의 블럭과 Parity block을 사용해서 데이터를 복구한다.
=> 실시간으로 복구할 수 있기 때문에 서비스는 계속 제공할 수 있게 된다.

그런데 4개의 디스크 중 어떤 디스크에 업데이트를 하더라도 Parity block을 업데이트 해야 한다.
=> Parity block이 업데이트 되는 속도가 나머지 4개의 디스크에서 병렬적으로 업데이트되 속도를 따라가야 하는데, 그렇지 못한다.
=> Parity block이 bottle neck이 된다.
write가 발생할 경우 RAID Level 4는 효과가 없어지게 된다.

 

RAID Level 5

RAID Level 4에서 하나의 Parity Block이 나머지 4개의 디스크에 대한 write를 감당해야 하기 때문에 Parity Block이 Bottle neck이 됐었다. 이것을 해소하기 위해 나온 방식이 RAID Level 5이다.

첫 번째 블럭들에 대한 Parity Block은 1번 디스크에, 두 번째 블럭들에 대한 Parity Block은 2번 디스크에 이런 식으로 저장한다.

RAID Level 4에서 Parity Disk가 가졌던 부하를 5개의 디스크가 나눠서 갖게 되는 것이기 때문에 bottle neck이 없어진다는 장점이 있다.
=> 그런데 RAID Level 4에 비해 안 좋은 점은 없기 때문에 RAID Level 4는 사용되지 않는다고 볼 수 있다.

 

Choice of RAID Level

RAID 0는 신뢰도를 향상하기 위한 대책은 없기 때문에 데이터는 잃어버려도 상관없고 오로지 성능만 중요할 때 레벨0를 사용할 수 있다.
=> 백업이 매우 잘 되어 있는 경우에 성능을 위해 사용할 수 있다.

Level 2, 3의 경우엔 Bit, Byte 레벨로 데이터를 분할하기 때문에 사용하지 않는다고 했다.

Level 4의 경우엔 Level 5가 있기 때문에 사용되지 않는다.

 

그렇다면 실질적으로 사용할 수 있는 방식은 Mirroring 방식인 Level 1과 Parity 방식의 Level 5를 고민할 수 있다.

레벨 1의 경우에는 쓰기가 발생하면 원본 블럭과 Mirrored 블럭 2개의 블럭에 write를 하면 된다.

레벨 5의 경우에는 하나의 블럭에 write를 하기 위해서는 원본 블럭도 읽어야 하고, 원본 Parity 블럭도 읽어야 한다.
그러고 나서 데이터 블럭도 수정해야 하고, Parity 블럭도 수정해야 한다.

write에 대해서는 Level 1의 성능이 더 좋다.

log disk는 평소에는 계속 write만 발생하다가 DB를 복구할 때에만 read가 발생한다.
데이터의 write만 계속해서 발생하는 log disk에 대해서는 Level 1방식을 사용하는 것이 더 좋을 것이다.

 

하지만 Mirroring 방식을 사용하면 실제 용량의 절반 밖에 사용하지 못한다는 단점이 있기 때문에 용량적인 면에서는 레벨 5가 더 좋을 것이다.
그런데 요즘 디스크의 용량이 매우 크기 때문에 용량이 문제가 되는 경우는 잘 없다.

 

write는 많이 발생하지 않지만 데이터는 매우 많을 때는 레벨 5가 더 좋을 것이고,  이러한 경우가 아니라면 일반적으로 Level 1의 Mirroring 방식이 더 선호된다.