Tech

## Intro

문자열 데이터의 전처리 시에 많이 사용되는 기술로 대게 문자열에서 특정 pattern을 추출하거나 검색, 필터링할 때 많이 사용되어진다.

## regex

Regular Expression의 약자로 한국어로 **정규표현식**이라고 부른다. 대게 모든 언어에서 이를 이용할 수 있는 라이브러리를 제공하거나 기본으로 포함하고 있기 때문에 이를 이해하는 것은 문자열을 다루는 능력치를 한 층 더 끌어올려준다.

우선 기본적으로 모든 character를 이용해서 pattern으로 생성할 수 있다. 하지만, 이것만으로는 복잡한 기능을 수행하는데 부족하다. 따라서, 특별한 character를 활용하여 이를 수행할 수 있다.

> **Special Character** 

기본적으로 특수 문자는 regex에서 표현할 때, \를 이용해서 구분해주어야 한다. 하지만, 이를 사용하지 않고 바로 사용할 경우에는 대게 특별한 의미를 갖는 경우가 많다. 반대로, 일반 문자의 경우에는 \에 영어 character를 더하는 경우 특별한 의미를 갖는 경우가 있다. 하지만, 핵심적인 기능은 아래 문자들이다.

| Character | Mean | Example. pattern | Example. matched string |
| :-- | :-- | :-- | :-- |
| ? | 이전 문자가 있는 경우와 없는 경우를 모두 포함한다. | colou?r | color colour |
| + | 이전 문자가 하나 이상 있는 경우를 모두 포함한다. | o+h | oh ooh ooooooooh |
| * | 이전 문자가 0개 이상 존재하는 경우를 모두 포함한다. | oo*h | oh ooh oooooooh |
| . | 모든 문자라는 의미를 갖는다. | beg.n | begin begun begUn |
| ^ | 문자열의 시작 부분을 특정 짓는다. | ^a | aaaaa alto |
| $ | 문자열의 끝 부분을 특정 짓는다. | a$ | aaaaa sea |
| \| | \|를 좌우로 있는 두 word를 모두 포함한다. | hello\|world | hello world hello,world |

> **Square Bracket**

또한, square bracket([])이 가지는 기능이 다양하다. 이 내부에 있는 모든 문자를 하나의 문자로 취급한다는 것이 특징이며, 앞에서 살펴본 \|의 확장 버전이라고 볼 수 있겠다. 또한, 이 안에서는 일부 특수 기호가 또 다른 의미를 가지게 된다.

| Character | Mean | Example. pattern | Example. matched string |
| :-- | :-- | :-- | :-- |
| [] | []내부에 있는 모든 문자를 포함하는 글자가 하나라도 있는지를 확인 | [wW]ood | wood Wood |
| [a-z] | alphabet의 대소문자와 숫자에만 제한된 기능으로, 그 사이의 모든 문자를 포함한다는 의미를 내포한다. | [a-zA-Z0-9]+ | 1234 hello Hel10 Hellㅇ Happy |
| [^] | ^ 이후로 오는 문자를 포함하지 않는지 확인 | ^[^a-z] | A a 1234 | 

더 많은 기능 예를 들면, Grouping이라는 기능도 존재하지만 위의 내용만 숙지해도 문자열 처리의 기본은 가능하다.

사실 이것만으로는 내용이 부족할 수 있는데 playground 및 regex 용법에 대한 설명이 잘 정리된 사이트를 해당 사이트를 참고하기 바란다. [🔗 Regexr](https://regexr.com/)

## Reference
- Thumbnail : Photo by [Mingwei Lim](https://unsplash.com/es/@cmzw?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/word-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
- https://regexr.com/

REGEX

## Intro

`gRPC`와 `Protocol Buffer`라는 것에 대해서 설명한다. `gRPC`는 `Protocol Buffer`를 교환 가능한 형태의 IDL(Interface Definition Language)과 message를 기술하기 위해서 사용한다.

## gRPC

`gRPC`에서 client application은 전혀 다른 machine의 server application에 존재하는 method를 마치 local object로 존재하는 것처럼 직접적으로 호출할 수 있다. 이는 실제로 distributed application(ex. Web 개발에서의 BackEnd, FrontEnd | Micro Service Architecture)과 service들을 제작할 때 굉장히 유용하다. 다른 RPC System과 마찬가지로, `gRPC`는 원격으로 parameter를 제공하여 호출할 수 있는 method와 return type을 기술하여 service를 정의한다. Server 측에서는 interface를 구현하고, 실제로 client의 호출을 처리할 `gRPC` server를 실행시킨다. Client 측에서는, server의 method와 동일한 method를 제공하는 `stub`(`gRPC` client)를 가진다.

![gRPC overview](/images/grpc-overview.jpeg)

`gRPC` client와 server는 다양한 환경(Cloud, Server, Desktop, etc...)에서도 실행이 가능하며, 서로 의사소통이 가능하고, `gRPC`를 지원하는 어떤 언어로도 구현이 가능하다. 즉, Server와 Client에서 어떠한 언어를 사용해도 상관이 없다. 또한, 최신 Google API들을 `gRPC`로도 제공하고 있기 때문에 쉽게 이용이 가능하다.

기본적으로, `gRPC`는 구조화된 데이터의 Serialization을 위한 Google의 Open Source인 `Protocol Buffer`를 사용한다.

`Protocol Buffer`의 데이터의 구조는 `.proto` 로 끝나는 일반적인 텍스트 파일(proto file)에 정의한다. `Protocol Buffer` data는 `message`라는 형태로 작성되며, 각 `message`는 여러 name-value 쌍으로 구성된 `field`들로 구성된 작은 정보 record이다. 아래는 message의 간단한 예제이다.

```proto
message Person {
 string name = 1;
 int32 id = 2;
 bool has_ponycopter = 3;
}
```

일단 data 구조를 정의하면, 선호하는 language를 통해 `Protocol Buffer Compiler`(protoc)를 사용해서 data access class들을 생성할 수 있다. 이는 각 field에 대한 간단한 접근자(`name()`, `set_name()`)와 전체 구조를 raw bytes로 serialization/parsing할 수 있는 method를 제공한다. 예를 들어 C++를 선택하였다면, `protoc`은 `Person`이라는 class를 생성할 것이고, 이를 이용해서 `Person`에 대한 message를 얻거나, serialization, 또는 parsing을 수행할 수 있다.

또한, `gRPC` service를 `proto file`에 paramter, return type와 같이 정의할 수 있다.

```proto
// The greeter service definition
service Greeter {
 // Sends a greeting
 rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
 string name = 1;
}

// The response message containing the greetings
message HelloReply {
 string message = 1;
}
```

`gRPC`는 `protoc`와 특별한 `gRPC` plugin을 사용하여 `proto file`에서 code를 생성한다. 이를 통해, message type들을 얻고, serialization할 수 있는 일반적인 `Protocol Buffer` code와 `gRPC` client 와 server code를 얻을 수 있다.

## Protocol Buffer

`gRPC`를 제대로 활용하기 위해서는 `Protocol Buffer`에 대해서 자세히 알아두어야 하기에 별도의 섹션으로 분리하여 설명한다. `Protocol Buffer`는 구조화된 데이터를 Serialization(구조화된 데이터를 byte형태로 변환하는 과정 또는 이를 통해서 생성된 결과물)하고, 다시 Parsing(Serialization을 통해서 생성된 데이터를 원래의 구조화된 데이터로 변환하는 과정)하는 과정을 언어 중립적(어떤 프로그래밍 언어에서도 사용가능한), 플랫폼 중립적(어떤 플랫폼에서도 사용가능한)으로 확장한 메카니즘이다. **이는 JSON과 유사하지만, 더 작고 더 빠르며, 실제 언어와의 연결을 자동으로 생성해준다.**

`Protocol Buffer`는 다음과 같은 도구의 집합이다.

1. Definition Language(.proto file을 작성하는 언어이다.)
2. data의 interface, language에 따른 runtime library들, data를 위한 serialization format `Proto Compiler`에 의해 생성된 code

### 핵심 Idea

**`Protocol Buffer`는 megabyte 정도 크기의 구조화된 data를 위한 Serialization format을 제공한다. 이는 단기간의 Network Traffic에서부터 장기간 data 저장에 모두 유리하다. `Protocol Buffer`는 기존 data를 무효화거나 update하는 추가적인 code 작업없이 새로운 정보로 확장되어질 수 있다.** 뿐만 아니라 **하위 호환성(이전 version의 data의 요청에도 대응하는 것)을 유지하는 것이 중요하기 때문에 이들을 장기간 유지한다. `Protocol Buffer`는 새로운 field의 추가/삭제에도 서비스의 중단 없는 환경을 제공한다.**

`Protocol Buffer`들은 구글에서는 굉장히 일반적으로 사용되는 format이다. 이는 대게 광범위한 server간 통신에 사용될 뿐만 아니라 disk에 data를 기록하는데에도 사용되어진다. `Protocol Buffer` message와 service들은 `.proto` 파일에 기술자에 의해 정의되어진다.

`Proto Compiler`는 build time에 `.proto` file에 기반하여 이에 적힌 `Protocol Buffer`를 조작하기 위한 다양한 language의 코드를 생성하기 위해서 실행되어진다. 각각에 생성된 class들은 각 field에 접근하기 위한 간단한 접근자들을 포함하며, serialization과 parsing을 위한 method를 제공한다.

### 장점

`Protocol Buffer`는 구조화된 data를 어떤 언어에서든, 어떤 platform에서든 광범위한 상황에서 serialization/parsing할 필요가 있을 때 굉장히 유용하다. gRPC로 통신도 가능할 뿐만 아니라 이를 위한 data storage도 제공하기 때문이다. 또한 다음과 같은 장점을 포함한다.

1. 적은 data 저장공간
2. 빠른 parsing
3. 많은 programming 언어와의 호환성 
 - C++, C#, Java, Kotlin, Go, Dart, Python, Ruby, Javascript(Node), PHP
4. 자동으로 생성된 class를 통한 최적화된 기능성

### 한계점

`Protocol Buffer`가 항상 모든 데이터에 대해서 적절한 것은 아니다.

- `Protocol Buffer`는 전체 message들이 memory에 모두 load될 수 있고, object graph보다는 크기가 작다고 가정한다. 따라서, 1~2 megabyte 내외의 크기를 넘어선다면, 여러 개의 copy를 만들게 될 것이고, 이는 memory 사용의 비효율을 초래할 것이다.
- `Protocol Buffer`가 serialization되었을 때, 동일한 data는 다양한 형태의 binary serialization 형태를 갖는다. 그렇기에 이들을 직접적으로 parsing하기 전까지는 이것이 서로 동일한지 알 수 있는 방법이 없다.
- Message는 JPEG, PNG와 같은 전용 압축 알고리즘이 존재하지 않는다. (하지만, zip, gzip 등은 가능하다.)
- `Protocol Buffer` message들은 float 및 다차원 배열을 많이 포함하는 과학 및 공학 용도에서 크기와 속도 면에서는 최대 효율보다 낮은 성능을 보인다. 이러한 요구가 많은 경우에는 overhead를 줄이기 위해서 `FITS` 또는 이와 유사한 방식을 활용해야한다.
- `Protocol Buffer` Object Oriented Language가 아닌 경우(Fortran, IDL) 지원이 어렵다.
- `Protocol Buffer` message들은 자체적으로 data를 정의할 수는 없고, 사용자에 의해서 정의된 schema에 기반한다. 따라서, data에 상응하는 `.proto` file이 없다면, 이를 완벽하게 해석하는 것은 불가능하다.
- `Protocol Buffer`는 여러 organization의 표준은 아니다. 따라서, 일반적인 사용 환경에서는 적절하지 않을 수 있다.

### 작동 방식

1. data 구조를 정의하기 위해서 `.proto` file을 생성한다.
2. `.proto` file을 기반으로 `protoc`는 code를 생성한다.
3. 생성된 code와 project code를 같이 compile한다.
4. 이를 통해서 생성되는 `Procotol Buffer` class들을 활용하여 serialization, 공유 및 parsing이 가능하다.

`Protocol Buffer` class들은 다양한 method를 포함한다. 예를 들어, 특정 데이터를 stream, file로 부터 받아오거나 개별적으로 value를 추출하거나 해당 데이터가 존재하는지 확인하거나 다시 serialization하여 stream 또는 file로 만드는 과정이 가능하다.

### Definition Syntax

`.proto` file을 정의할 때, 먼저 optionality를 설정한다. 이는 `optional` 또는 `repeated` 또는 `singular` 중에 하나를 선택할 수 있다. (v2에는 `required`도 존재하지만 이를 사용하는 것을 좋지 않은 pattern으로 여긴다.)

위의 사항을 정한 후에는 data type을 기술해야 한다. `Protocol Buffer`는 보편적으로 사용되어지는 data type(Integer, Boolean, Float)을 제공한다.

field는 아래와 같은 것도 포함한다.

- `message` : data의 설정을 반복하는 경우 이를 사용할 수 있다.
- `enum` : 해당 type의 종류를 value들의 집합으로 표현할 수 있다.
- `oneof` : message가 여러 optional field를 포함할 때, 단 하나의 field만 가지도록 할 수 있다.
- `map` : key-value 형태로 기술할 수 있다.

optionality와 field type을 설정한 후에, field number를 할당해야 한다. 이는 다른 목적으로 사용하거나 재사용되어서는 안된다. 특정 field를 제거했다면, 이 숫자를 재사용하지 않도록 반드시 유의해야 한다.

### 추가적인 Data Type

`Protocol Buffer`는 다양한 scalar value type을 제공한다. 또한, 자신만의 합성 data type을 message를 정의함으로써 생성할 수 있다. 또한 보편적으로 사용되어지는 다음과 같은 type들도 추가적으로 정의되어있다.

- `Duration` : 시간을 의미한다. (ex. 42s)
- `Timestamp` : 시각을 의미한다. (ex. 2017-01-15T01:30:15.01Z)
- `Interval` : 시간 사이 거리를 의미한다. (ex. 2017-01-15T01:30:15.01Z - 2017-01-16T02:30:15.01Z)
- `Date` : 달력에서의 전체 날짜를 의미한다. (ex. 2025-09-19)
- `DayOfWeek` : 일주일에 요일을 의미한다. (ex. Monday)
- `TimeOfDay` : 하루에서 시간을 의미한다. (ex. 10:42:23)
- `LatLng` : 위도와 경도를 의미한다.
- `Money` : 화폐 단위를 의미한다.
- `PostalAddress` : 우편주소를 의미한다.
- `Color` : RGBA color 값을 의미한다.
- `Month` : 년에 따른 월을 의미한다. (ex. April)

## Outro

현재까지 사용해본 RPC는 ReST API, GraphQL이 있었다. ReST는 워낙 유명하고, JSON, xml기반으로 많이 사용하기 때문에 누구나 알법하다. 그리고, graphQL은 더 유동적인 구현 방식을 제공했기 때문에 Gatsby와 같은 platform이나 Github에서도 사용할 정도로 유명해졌다. 앞 서 얘기한 두 개는 BackEnd에서 FrontEnd로 제공하는 시스템에서 주로 이용된다는 것을 이번 기회로 깨달은 것 같다. 그렇기에 좀 더 사람이 이해하기 쉬운 구조로 되어있을 뿐만 아니라 굉장히 친숙하다. 하지만, `gRPC`는 성능 향상에 좀 더 초점을 두었고, `Server`간 통신에 더 방점을 둔 것이라는 것이 와닿았다. 여러 Virtual Machine이 많아지는 가운데에 이들간에 빠른 통신과 각 Machine간의 호환을 위한 여러 기능들에 좀 더 초점을 맞추고 있다는 것을 알게 되었다. 아마 앞으로 `gRPC`를 사용한다면 이러한 용도로 가장 많이 사용할 것 같다. 아마 이래서 주요 사용처가 Network Vender(CISCO, Juniper), CNCF, Netflix 등인 것일 수도 있겠다. 끝으로 이를 이용한 구현을 직접해보아야 더 나은 설명이 가능할 것 같으므로 후에 이에 대해서 더 자세히 다루겠다.

## Reference

- <https://grpc.io/docs/what-is-grpc/introduction/>
- <https://grpc.io/docs/what-is-grpc/core-concepts/>
- <https://developers.google.com/protocol-buffers/docs/overview>

gRPC

## Intro

**Vagrant**(베이그런트)는 Virtual Machine의 실행환경을 하나의 workflow 내에 구축하고 관리하는 도구이다. 쉬운 workflow 사용법과 자동화에 초점을 맞추어 **Vagrant**는 setup time이 굉장히 짧다. 또한, production과정과의 동등함을 제공하고, 과거의 시스템을 "나의 machine 내부에서" 동작시키는 것이 가능하다.

## Why Vagrant?

**Vagrant**는 `configuration`이 쉽고, 동일한 조건으로 재실행을 보장(reproducible)하며, 어느 장비에서든지 동작가능(호환성이 높은, portable)한 작업 환경을 제공한다. 이러한 작업 환경은 산업 표준 기술에 기반하며, 하나의 일관성있는 workflow에 의해서 제어되어 생산성과 유연성을 최대화한다.

이러한 마법같은 일을 성취하기 위해서, **Vagrant**는 `VirtualBox`, `VMware`, `AWS`, 또는 다른 `Virtual Machine` 제공자에 기반 위에서 동작하며, 이들을 활용하여 가상 환경을 구축할 수 있다.

### For Developers

만약 당신이 개발자라면, **Vagrant**는 의존성과 그들의 설정을 격리시킬 수 있다. 이때에 일회용으로 사용하든, 지속적인 환경으로 사용하든 상관없이 그 어떤 tool들(browser, editor, debugger 등)도 빠짐없이 포함시킬 수 있다. 일단 하나의 `Vagrantfile`을 생성하면, 단지 `vagrant up`만 실행시켜주면 모든 것이 설치되고 설정될 것이다. 이는 개발팀의 누구에게든지 공유될 수 있고, 어느 환경(Linux, MAC OS X, Window)에 있든 모든 팀 구성원은 동일한 환경(동일한 의존성, 동일한 설정)에서 code를 실행시킬 수 있다. 이를 통해서 `내 머신에서는 잘 동작하는데...`와 같은 에러를 해결할 수 있다.

### For Operators

만약 당신이 System operation/DevOps engineer라면, **Vagrant**는 개발 또는 테스팅을 위한 infrastructure(기반 환경)을 관리하기 위한 일회용 또는 일관적인 workflow를 제공한다. 이때에는 `sh`, `Chef`, `Puppet` 과 같은 방법을 통해 제어할 수 있으며, 실행 환경은 `VirtualBox`, `VMware`, `AWS` 등 다양한 환경을 활용할 수 있다. 여러 machine을 `ssh`를 통해서 접속하지 않고, **Vagrant**를 통해서 모든 것을 쉽게 제어할 수 있다.

### For Designers

만약 디자이너 직군이라면, **Vagrant**는 자동적으로 web app을 구동시킬 수 있는 모든 환경을 자동적으로 제공할 수 있다. 따라서, design 작업 외에는 더 알아야 할 것이 없다. 일단 개발자가 **Vagrant**를 설정하고 나면, 당신은 이를 다시 실행시키는 방법에 대해서 고민할 필요가 없다. 더 이상 개발자들을 괴롭히지 않고도 당신의 환경을 쉽게 변경할 수 있으며, version control만 쉽게할 수 있다면, 단순히 `vagrant up`으로 쉽게 적용이 가능하다.

## What is Vagrant?

해당 tutorial에서는 **Vagrant**를 통해 너의 첫번째 개발 환경을 생성할 것이다. 이를 통해서, **Vagrant**의 간략한 소개와 사전 준비사항과 가장 기본적이고 중요한 **Vagrant** 활용을 배울 것이다.

해당 tutorial에서는 `VirtualBox`를 활용하여 **Vagrant**환경을 구성해볼 것이다. 왜냐하면 이것이 여러 platform에서 사용되는 무료 software이기 때문이다.

### 사전 준비사항

1. **Vagrant** 설치 
 [🔗 link](https://www.vagrantup.com/docs/installation)
2. `VirtualBox` 설치 
 [🔗 link](https://www.virtualbox.org/wiki/Downloads)

단 두 개의 명령어로 원하는 환경의 VM(Virtual Machine)을 생성할 수 있고, 하나의 명령어로 삭제가 가능하다. 여기서는 Ubuntu 18.04 이미지를 이용할 것이다.

### 실행 테스트

> **1. Vagrant 초기화**

```bash
$ vagrant init hashicorp/bionic64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
```

이를 통해서, 현재 directory에 `Vagrantfile`을 생성하는 것이 가능하다.

> **2. (Optional) Box 설정**

Virtual Machine을 구성할 때, scratch(밑바탕, 대게 OS만 포함한 상태)에서 시작하는 것은 매우 느리다. 따라서, **Vagrant**에서는 setup time을 최적화하기 위해서, `box`라는 것을 이용한다. 이는 기존의 VM 구성 시에 사용하는 image와 비슷한 의미를 가진다. 따라서, `Vagrantfile`을 생성한 후에 해야할 가장 첫번째로 수행할 것이 해당 `box`를 구체화하고 기술하는 것이다.

`box`는 [Vagarnt Cloud](https://app.vagrantup.com/boxes/search)와 같은 registry에 upload가 가능하다. 또는 local filesystem에서도 참조가 가능하다.

우리가 이전에 했던 것처럼 `vagrant init`을 수행할 때, `box` 명을 써주면, `Vagrantfile`을 만들 때 현재 나의 machine에 해당 `box`가 존재한다면 불러오고, 그렇지 않으면 download한다. 그렇지 않고 download만 하고 싶은 경우에는 다음과 같은 명령어를 수행할 수도 있다.

```bash
$ vagrant box add hashicorp/bionic64
==> box: Loading metadata for box 'hashicorp/bionic64'
...
```

이를 수행한 후에 `Vagrantfile` 내부에서 VM의 box를 변경할 수 있다.

```Vagrantfile
# "2"는 Vagrant version을 의미
Vagrant.configure("2") do |config|
 config.vm.box = "hashicorp/bionic64"
end
```

이렇게 설정하게 되면, 해당 `box`의 latest 버전을 기본으로 사용하게 되는데, 특정 버전을 원한다면 다음과 같이 작성할 수도 있다.

```Vagrantfile
Vagrant.configure("2") do |config|
 config.vm.box = "hashicorp/bionic64"
 config.vm.box_version = "1.0.282"
end
```

현재 내 machine에서 `box`를 조회하거나 삭제하기를 원한다면, 다음과 같이 수행할 수 있다.

```bash
$ vagrant box list
hashicorp/bionic64 (virtualbox, 1.0.282)

$ vagrant box remove hashicorp/bionic64
Removing box 'hashicorp/bionict64' (v1.0.282) with provider 'virtualbox' ...
```

> **3. VM 실행**

기본적으로 현재 directory에서 `Vagrantfile`을 찾아서 Virtual Environment를 구성한다.

```bash
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
...
```

실행이 완료되면, 다음과 같이 ssh 접근 및 종료가 가능하다.

```bash
$ vagrant ssh
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)

vagrant@vagrant:~$ logout
Connection to 127.0.0.1 closed.
```

> **4. VM 삭제**

```bash
$ vagrant destroy
 default: Are you sure you want to destroy the 'default' VM? [y/N] y
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
```

### 반드시 알아야할 사항

> **1. Synchronize Local and Guest Files**

VM을 이용하여 개발하는 것은 편리하지만, 대부분의 사람들은 ssh를 이용해서 해당 시스템에 접속하여 작성하는 것은 불편하다고 느낄 것이다. 프로젝트가 두 개만 되어도 상당히 귀찮은 작업이다. 따라서, **Vagrant**는 자동으로 VM과 현재 나의 machine(host)의 file을 자동으로 sync한다.(동일한 file이 되도록 한다.) 즉, 내가 host에서 file을 작성함으로써 VM에 이를 적용하는 것도 가능하다는 것이다. 기본적으로 **Vagrant**는 VM에 Vagrantfile을 포함한 project directory를 `/vagrant` directory와 동기화한다.

> **2. VM으로 project 배포**

아주 간단한 예제로 apcache를 이용하여 project 배포를 수행해보자.

먼저, `Vagrantfile`이 존재하는 directory에 `html`이라는 폴더를 만든다.

```bash
$ mkdir html
...
```

아주 기본적인 HTML을 작성하자.(index.html)

```html
<!DOCTYPE html>
<html>
 <body>
 <h1>Hello, My First Vagrant Deploy!</h1>
 </body>
</html>
```

이제 실제로 apache를 설치하고, 지금 만든 파일을 apache process가 바라보는 folder로 전달해주는 shell script를 작성하자.(`bootstrap.sh`이라는 이름으로 project directory에 작성)

```shell
#!/usr/bin/env bash

apt-get update
apt-get install -y apache2

if ! [ -L /var/www ]; then
 rm -rf /var/www
 ln -fs /vagrant /var/www
fi
```

이제 이를 **Vagrant**에서 실행 시에 시작하도록 설정만해주면 끝이다.

```Vagrantfile
Vagrant.configure("2") do |config|
 config.vm.box = "hashicorp/bionic64"
 config.vm.provision :shell, path: "bootstrap.sh"
end
```

이제 다음을 통해서 실제로 html이 배포되었는지를 확인할 수 있다.

```bash
$ vagrant up

$ vagrant ssh

vagrant@vagrant:~$ wget -qO- 127.0.0.1
<!DOCTYPE html>
<html>
 <body>
 <h1>Hello, My First Vagrant Deploy!</h1>
 </body>
</html>

vagrant@vagrant:~$ logout
Connection to 127.0.0.1 closed.
```

> **3. Port Forwarding**

가장 기본적으로 많이 사용되는 Network 기술로 VM의 port를 host의 port와 mapping하여 host의 port를 통해 VM의 port에 접근할 수 있도록 하는 기술이다.

2번에서 작성했던 `Vagrantfile`을 다음과 같이 변경해주면 된다.

```Vagrantfile
Vagrant.configure("2") do |config|
 config.vm.box = "hashicorp/bionic64"
 config.vm.provision :shell, path: "bootstrap.sh"
 config.vm.network :forwarded_port, guest: 80, host: 4567
end
```

이를 적용하여 **Vagrant**를 재실행하기 위해서는 다음을 실행해주면 된다.

```bash
$ vagrant reload
==> default: Attempting graceful shutdown of VM...
...
```

browser를 통해 확인하면 아래와 같은 결과를 얻을 수 있다.

![vagrant-forwarding-test](/images/vagrant-forwarding-test.png)

> **4. WebApp 공유**

`ngrok`를 이용해서 WebApp을 공유하는 기능을 **Vagrant**가 포함하고 있다. 이를 `vagrant share`라고 부른다. 실행을 원한다면, 기본적으로 `ngrok`을 [🔗 설치](https://ngrok.com/download)한 후에 다음 command들을 실행시키면 webpage를 남들에게 share하는 것이 가능하다.

```bash
# vagrant share를 수행하기 위한 plug인을 설치한다.
$ vagrant plugin install vagrant-share

# (MAC OS) development tools가 없다는 에러 발생시 아래 명령어 실행
# xcode-select --install

$ vagrant share
...
==> default: Creating Vagrant Share session...
==> default: HTTP URL: http://b1fb1f3f.ngrok.io
...
```

`ngrok`은 무료로 server domain을 생성하고, web service를 hosting 해주는 tool이다. 사용법도 굉장히 간단해서 알아두면 좋다.

> **5. 여러 Machine 배포**

다음과 같이 `vm.define`을 통해서 여러 개의 machine을 한 번에 정의하는 것도 가능하다. 따라서, **Vagrant**가 VM을 configuration하는 것이 아니라 Virtual Environment를 configuration하는 것이라고 부르는 것이다.

```Vagrantfile
Vagrant.configure("2") do |config|
 config.vm.provision "shell", inline: "echo A"

 config.vm.define "web" do |web|
 test.vm.provision :shell, inline: "echo B"
 web.vm.box = "apache"
 end

 config.vm.define "db" do |db|
 config.vm.provision :shell, inline: "echo C"
 db.vm.box = "mysql"
 end
end
```

## Reference

- [🔗 Why Vagrant?, Vagrant 공식 사이트](https://www.vagrantup.com/intro)
- [🔗 Getting Started, Vagrant 공식 사이트](https://learn.hashicorp.com/collections/vagrant/getting-started)

Vagrant

[Bitcoin] 4. Blockchain

[Bitcoin] 3. Transaction


## Intro

**해당 Posting은 Bitcoin이 무엇이고, 이것으로 무엇을 할 수 있는지에 대해서 설명하지 않고 Bitcoin을 구현하는 기술에 대하여 다룹니다.** 또한, 책의 모든 내용을 충실히 번역하는 것이 아닌 작성자의 생각이 많이 담겨 있으니 유의 바랍니다.

**해당 chapter에서는 Bitcoin에서 데이터를 어떻게 Serialization 하고, Parsing 하는지에 대해서 다룹니다.**

---

먼저, Serialization이 무엇인지부터 알아보아야 합니다. Serialization이란 현재 programmer가 만들어놓은 data(Class Instance, 등)를 network를 통해서 다른 computer로 옮기거나, 저장 장치 file 등으로 옮겨 담을 때, **연속적으로 표현되는 형태**로 구조화하는 방법을 말합니다. 대게, 이러한 처리는 원본 데이터를 변환하기 때문에, 이를 원래 data로 변환하는 Parsing과 짝을 이룹니다.

데이터마다, 그리고 사람마다 더 좋다고 생각하는 serialization 방식은 매우 많습니다.

대게 고려하게 되는 사항은 다음과 같습니다.

1. **효율성** : 변환하는 데이터가 짧게 표현될 수록 더 효율적으로 전달이 가능하다는 것은 자명하기에 이는 가장 중요한 요소 중 하나입니다.
2. **보안성** : network로 전달이 될 가능성이 높기 때문에, 이를 전달받은 누구나 이를 변환할 수 있다면, 위험할 수 있습니다. 따라서, 보안성을 위해서, 암호화 또는 hashing을 수행하기도 합니다.
3. **안정성** : 대게 보안성과 묶어서 설명하지만, 여기서는 분리하였습니다. 즉, 데이터가 중간에 손실되지 않고, 안정적으로 제대로 도착했는지를 확인할 수 있도록 하는 것도 중요합니다.
4. **표준** : 결국 Serialization을 하더라도, 이를 수신받은 입장에서는 이를 번역한 내용에 관심이 있기에, 이를 번역할 방법이 서로 공유가 되어있어야 합니다. 그렇기에 많은 경우에, Serialization을 표준으로 정해진 방식을 통해서 수행됩니다. 또는, 새로운 표준을 만들어서 수행합니다.
5. **가독성** : 대게, serialization된 데이터 자체를 사람 간에 구두로 전달해야 할 경우가 있습니다. 이를 위해서, 인간 친화적인 형태로 데이터를 변조하는 경우도 많습니다.

---

먼저, Bitcoin에서 구체적으로 어떤 식으로 Serialization을 살펴보기 전에 기반 기술을 알아볼 것입니다. 각 기술에 대해서 이미 알고 있다면, 바로 다음으로 넘어가도 좋습니다.

### 1. Byte화

일반적으로, Serialization을 수행한 결과물은 bytes(8bit) 형태로 나타나는 것이 일반적입니다. 왜냐하면, 당연히 일반적인 programming에서 사용되는 integer(4 bytes) 형태로 표현하는 것은 비효율적이기 때문입니다. 또한, 컴퓨터 자체가 byte 단위로 데이터를 알아먹기 때문에, 컴퓨터 친화적으로 데이터를 변환한다고 생각하면 될 거 같습니다. 따라서, 데이터를 변환하여 결과물이 byte 단위로 묶이는 것이 일반적입니다. (+ 단순히 좀 더 효율적인 형태로 변환했다고 생각해도 됩니다. 그러기 위해서, 사람이 해당 문자를 보고, 한 번에 무슨 숫자인지 찾아내기는 좀 힘들어집니다.)

```c++
// c++을 안다면 도움이 되겠지만, c를 잘 모르신다면, 이해할려고 하지말고 넘어가셔도 됩니다.
int a = 255 // 4 bytes
char a = 255 // 1 byte
```

여기서, byte type을 다룰 때, 항상 발생하는 문제인 **호환성**을 확인해야 합니다. 사람은 일반적으로 수를 쓸 때, 왼쪽에서부터 큰수가 나오며, 오른쪽으로 쓰는 것이 표준처럼 정해져 있습니다. 하지만, computer 세계에서는 그렇지 않기 때문에, 왼쪽이 큰 수 인지, 오른쪽이 큰 수 인지를 정해줄 필요가 있습니다. 따라서, 이를 표준으로 정해서 어떤 데이터를 serialization 할 때 왼쪽이 큰 수가 되는 (Big endian)을 사용할지, 오른쪽이 큰 수가 되는 (Little endian)을 사용할지를 반드시 정해야 합니다.

### 2. Base58

이를 이해하기 위해서는 Base64를 먼저 이해해야 합니다.

이는 특정 데이터를 총 64개의 문자 (10(숫자) + 26(알파벳 소문자) + 26(알파벳 대문자) + 2(기호 +, /))로 이루어진 문자 체계로 변환하는 것을 말합니다. 우리가 하나의 byte(8 bits)로 256개의 데이터를 표현할 수 있지만, 다음과 같이 Base64로 변환하게 되면 6bit을 사용하기 때문에 결과적으로 데이터의 크기가 커지는 현상이 발생하게 됩니다.(결국에는 byte단위로 전송하는데, 그중에 6bit만 사용하기 때문입니다.) 그럼에도 이를 사용하는 이유는 **호환성**을 높이기 위해서 입니다. 국제적인 표준이기 때문에, Base64를 이용한다면, 어떤 시스템에서도 이를 해석하는 데는 문제가 없습니다. 따라서, 이러한 형태로의 변환은 굉장히 빈번히 사용됩니다.

그렇다면, Base58은 무엇인가에 대해서 고민을 해보아야 합니다. Base58이란, Base64에 **가독성**을 높이기 위한 version이라고 생각할 수 있습니다. 바로 사람이 읽었을 때, 헷갈릴 수 있겠다고 판단되는 데이터를 과감하게 제거해버리는 것입니다. 따라서, 기존의 Base64에서 0(숫자 0), O(대문자 o), l(소문자 L), I(대문자 i), +, /를 제거하여 표현하는 것입니다. 따라서, 결론상 58개의 문자 (9(숫자) + 25(소문자) + 24(대문자))로 표현하는 방식입니다. 또한, 부가적으로 **안정성**을 높이기 위해서, base58에서는 hash256을 이용해서 만들어진 데이터를 추가로 전송하여, checksum으로 사용하는 구현도 존재합니다. (checksum이란, 수신을 받은 측에서 데이터의 손실 여부를 확인할 때, 사용할 수 있는 데이터를 말합니다. 여기서는 자세히 다루지 않습니다.)

### 3. DER(Distinguished Encoding Rule)

serialization 기법 중에 하나입니다. 이름에서부터 느껴지다시피 serialization을 수행할 때, 정확한 구분자와 길이를 data 앞에 배치시켜서 변환을 쉽게 하기 위한 방법 중에 하나입니다. 여기서는, Bitcoin에서 사용하는 DER 방식만 다루기에 해당 방식이 어떻게 돌아가는지만 다루겠습니다.

BitCoin에서는 Signature(서명)을 전달할 때, 해당 방식을 사용하는데, 이는 이 전 chapter에서 살펴봤듯이 두개의 integer로 이루어집니다. 그렇기에 여러 개를 보낼 때, 이를 감싸 줄 수 있는 Sequence와 Integer 형을 보낼 때, 사용하는 구분자를 data 앞에 넣어주어야 합니다. (Sequence = 0x30, Integer = 0x02) 또한, data의 사이즈 역시 같이 붙여주어야 합니다. (단위가 byte라는 것을 유의합시다.)

따라서, 형태가 다음과 같습니다.

0x30 + {전체 전송 data의 사이즈} + 0x02 + {보낼 integer data의 사이즈} + {전송할 data(bytes)} + 0x02 + {보낼 integer data의 사이즈} + {전송할 data(bytes)}

예시로 다음을 들 수 있습니다. 만약에 1과 2라는 수를 동시에 보내고 싶을 때에는 다음과 같이 전달된다고 볼 수 있습니다.

0x30\0x06\0x02\0x01\0x01\0x02\0x01\0x02

아래 링크를 확인하면 더 자세한 방식들을 알 수 있습니다.

[🔗 ASN 형식의 DER 인코딩](https://docs.microsoft.com/ko-kr/windows/win32/seccertenroll/about-der-encoding-of-asn-1-types)

### 4. SEC(Standards for Efficient Cryptography)

serialization 기법 중에 하나이며, 특히 암호화 과정에서 사용되는 표준 정도로 볼 수 있습니다. 대게 ECC(Elliptic Curve Cryptography)의 암호화 시에 생성된 public key 등에 대한 표준화 내용을 포함합니다. Bitcoin에서는 Public key 전송 시에 SEC를 사용함으로 이에 대한 내용만을 다루겠습니다.

먼저, 여기서는 Public key를 두 가지 mode로 표현합니다.

첫 번째로, 압축(compression)을 사용하지 않은 표현법으로 이는 매우 단순합니다.

우선은, 0x04를 데이터 맨 앞에 붙이고, 순서대로 Public key의 X좌표, Y좌표를 붙여주면 됩니다.

0x04 + {public key's x (bytes)} + {public key's y (bytes)}

이는 항상 사이즈가 65(1 + 32 + 32)bytes로 고정된다는 점을 알 수 있을 것입니다. (그렇기 때문에, 위에서 설명한 DER 방식없이도 전송이 가능합니다.)

두 번째로, 압축(compression)을 사용하는 표현법입니다. 전송하는 두 개의 데이터 $x$,$y$가 Elliptic Curve 위에 존재한다는 연관점을 활용하는 것입니다. ($y^2 = x^3 + ax + b$)

$x$만 보내고, $y$를 알기 위해서는 두 가지 문제를 해결할 수 있어야 합니다.

1. 제곱근 연산($\sqrt{y^2}$)이 가능한가?
2. 제곱근으로 나온 결과값 중 어떤 것이 근인지 확신할 수 있는가?

일단 제곱근 연산은 다음과 같은 상황에서는 쉽게 구할 수 있습니다. ($p+1$이 4의 배수인 경우)

$$ p \% 4 = 3$$

$$(p + 1) \% 4 = 0$$

다행히도, Bitcoin가 사용하는 ECDSA에서는 이를 만족합니다. 그렇다면, 아래의 식을 만족하여 쉽게 제곱근을 구할 수 있습니다. (중간에 $(p+1)/2$ 이 가능한 이유는 Prime number는 2를 제외하고는 모두 홀수 이기 때문입니다.)

$$w^2 = v$$

$$w^{p-1} \% p = 1$$

$$w=w^{(p+1)/2}=w^{2(p+1)/4} = (w^2)^{(p+1)4} = v^{(p+1)/4} $$

또 하나의 제곱근을 구할 때에는 간단하게 다음을 수행합니다.

$$-w = p - w$$

다음으로, 제곱근으로 나온 값 중 특정하는 방법은 바로 홀수인지 짝수인지를 알려주는 1byte만을 전송해주면 됩니다. 왜냐하면, 위에 식에서 알 수 있듯이 $w$가 짝수이면, 또 다른 근인 $-w$는 홀수일 수 밖에 없기 때문입니다. ($p$ = 홀수)

따라서, 전송 시에는 다음과 같이 더욱 간소해집니다.

우선은, 0x02 또는 0x03 데이터를 맨 앞에 붙이고, 순서대로 Public key의 X좌표를 붙여주면 됩니다.

짝수 : 0x02 + {public key's x (bytes)}

홀수 : 0x03 + {public key's x (bytes)}

이는 항상 사이즈가 33(1 + 32)bytes로 고정된다는 점을 알 수 있을 것입니다.

아래 링크를 통해서 더 자세한 사항을 확인할 수 있습니다.

[🔗 Standards for Efficient Cryptography Group](https://www.secg.org/)

### 5. Hash160, Hash256

hash라는 것 역시 serialization part에서 빈번하게 등장할 수 밖에 없는 내용입니다. hash란 다음과 같은 특징을 가지는 함수를 말합니다.

1. one way function : 역연산이 불가능연산입니다.
2. return fixed length : 반환된 결과값이 항상 일정한 길이를 가집니다.
3. collision with very low probability : 반환된 결과값이 충돌될 가능성이 사실상 없다. 즉, 완벽한 1:1 대칭은 아니지만, 이에 매우 근사한다는 것입니다.

hash의 전반적인 설명은 여기서 다루지 않기 때문에, 이정도만 기억해두시면 됩니다. 역연산이 불가능하기 때문에, 대게 데이터를 알 수 없는 형태로 저장하고자 하는 경우에 많이 사용합니다. 대표적인 예시로 MD-5, SHA-1, SHA-2(SHA-256, SHA-512, ...)가 있습니다.

hash는 대게의 경우 매우 제대로 잘 동작하지만, collision에 의해서 망가지는 경우가 있습니다. 따라서, 이를 보안하기 위해서 계속해서 새로운 방법들이 고안 되었습니다.

따라서, Bitcoin에서는 SHA256 이후에 이를 다시 한 번 ripemd160을 수행하는 것을 Hash160이라고 하고, SHA256을 연달아서 두 번 수행하는 것은 Hash256이라고 합니다. 이름에서 알 수 있다시피, Hash160은 결과값이 160bits(20bytes), SHA256은 256bits(32bytes)입니다.

### 6. Varint

Variable + int의 합성어로 variable length로 integer data를 serialization하는 방법을 제시합니다. 최대 수의 범위는 $2^{64} - 1$까지 표현할 수 있기 때문에 매우 유용하며, 불필요한 데이터의 전송을 최소화할 수 있습니다. 내용 자체는 매우 간단합니다.

1. 해당 수가 253보다 작다면 1 byte만 이용해서 바로 표현합니다.
2. 그렇지 않고, 해당 수가 2^16 - 1 보다 작다면, 253(0xfd)를 prefix로 맨 앞에 붙이고, 2 byte를 이용해서 표현합니다.
3. 그렇지 않고, 해당 수가 2^32 - 1 보다 작다면, 254(0xfe)를 prefix로 맨 앞에 붙이고, 4 byte를 이용해서 표현합니다.
4. 그렇지 않고, 해당 수가 2^64 - 1 보다 작다면, 255(0xff)를 prefix로 맨 앞에 붙이고, 8 byte를 이용해서 표현합니다.

즉, 0으로 앞에 남는 byte를 보내는 양을 효과적으로 줄일 수 있기 때문에, 변수 상태의 integer를 전송할 때 많이 사용됩니다.

---

여기서 Bitcoin에서 Serialization를 수행하는 경우를 구체적으로 살펴보겠습니다.

### 1. Public Key

기본적으로 Public key는 모두에게 공개되어야 하는 정보 중에 하나입니다. 따라서, 이를 효율적으로 분배하는 문제 역시 중요하다고 할 수 있습니다. Bitcoin에서는 앞 서 살펴보았던, SEC, Base58를 이용하며, 필요에 따라서 hash160을 이용해서 내용을 감추기도 합니다.

일반적으로, SEC와 Base58을 이용하여, 데이터를 전송하는 이유는 후에 Public Key 역시 사람들에게 쉽게 노출이 되는데, 이를 쉽게 사람들이 알아볼 수 있게 하기 위함이며, hash160을 사용하는 이유는 Public Key를 감추기 위해서 입니다. 이 말이 이상하게 들릴 수 있는데, Public key가 Open 되고 바로 사용된다면, 문제가 되지 않지만, Public Key가 공개되고 오랜 시간이 지난다면, 문제가 발생할 가능성이 생기기 때문입니다. (너무나 오랫동안 노출된다면, private key가 결국은 해독될 수도 있습니다.) 이는 바로 다음 chapter에서 더 알아볼 수 있습니다.

### 2. Signature

Signature 방식 같은 경우는 표준처럼 넓게 사용되는 DER을 사용합니다.

### 3. Private Key

Private key를 전송한다는 것은 굉장한 위험을 초래할 수 있습니다. 하지만, 그럼에도 불구하고, 이를 전송해야할 경우가 있습니다. usb에 저장하고 싶다거나 별도의 software로 옮기고 싶은 경우도 존재합니다. 따라서, 이를 위한 Serialization Format도 존재합니다. 우리는 이를 WIF(Wallet Import Format)이라고 부릅니다.

이는 이름에서부터 느껴지듯이 Bitcoin에서 파생된 standard라고 볼 수 있습니다. 또한, 이는 Base58로 encoding된다는 점 정도만 기억하면 충분합니다.

또한, 위에서는 다루지 않았지만, Bitcoin network는 개발용(testnet)과 실제 서비스용(mainnet)을 가지고 있기 때문에, 이를 구분하는 구분자를 각 serialization 앞에 표시하는 것을 원칙으로 합니다.

- mainnet = 0x80
- testnet = 0xef

### 4. Number of data

bitcoin 상에서도 여러 개의 데이터를 전송해야 하는 경우가 많습니다. 그런데, 만약 해당 데이터의 갯수가 정해져있는 것이 아니라 때에 따라서 변경되는 경우에는 위에서 제시한 Varint를 사용할 수 밖에 없습니다. 이는 바로 다음 Chapter에서 알아볼 Transaction 내부에서 많이 사용되는 것을 알 수 있습니다.

이전 글과 동일하게 구현 사항은 github에 정의해두었습니다.

[🔗 GitHub - euidong/bitcoin](https://github.com/euidong/bitcoin)

## Reference

- [🔗 Programming Bitcoin](https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/)
- Tumbnail : Photo by [Icons8 Team](https://unsplash.com/@icons8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@icons8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


[Bitcoin] 2. Serialization

## Intro

Blockchain을 공부하게 되었는데, 이번 기회에 제대로 하자는 생각에서 Bitcoin 구현을 직접 수행해볼 생각입니다. 학습에 사용한 책은 위에 나와있는 책을 활용하였습니다.

**해당 Posting은 Bitcoin이 무엇이고, 이것으로 무엇을 할 수 있는지에 대해서 설명하지 않고 Bitcoin을 구현하는 기술에 대하여 다룹니다.** 또한, 책의 모든 내용을 충실히 번역하는 것이 아닌 작성자의 생각이 많이 담겨 있으니 유의 바랍니다.

**해당 chapter에서는 데이터의 인증을 어떻게 수행할 것인가에 대한 세부적인 내용을 다루겠습니다.**

> **(+) 들어가기에 앞 서...**

Bitcoin에서는 결제가 발생할 때, 이전 거래에서 얻은 Bitcoin을 통해서만 결제가 가능합니다. (거래를 통해 Bitcoin을 받은 적이 없다면, Bitcoin이 없는 것으로 간주합니다.)

또한, 우리는 이 거래 내역을 모두가 볼 수 있도록 공개합니다. 이 상황에서 우리가 특정 거래 내역에서 돈을 받은 사람이 자신이고, 그 거래에서 얻은 Bitcoin을 현재 거래에 사용할 것임을 증명하기 위해서는 어떻게 해야할까요?

---

일반적으로 인증이라는 것은 누군가가 특정 사실을 증명하는 것을 말합니다. 여기서는, 데이터의 작성자가 진짜 작성자가 맞는지를 확인하는 것입니다. 이는 대게 믿을 만한 제3 자에게 맡기거나 직접 눈으로 확인하는 방식이 있습니다. 하지만, 매번 이를 수행하는 것은 어렵기 때문에 우리는 원본 데이터에 서명을 하는 것을 택합니다. 이를 통해서, 자신이 해당 데이터의 작성자임을 분명하게 표시할 수 있습니다. 그런데, 이것을 programming 적으로 구현하는 것은 쉬운 일이 아닙니다.

대게 이를 위해서 우리는 공개키 방식이라는 것을 사용합니다. 공개키 방식이란, 암호화하는 도구와 해독하는 도구가 서로 다른 경우를 말합니다.

즉, 해독하는 도구는 누구나에게나 제공을 하고, 암호화하는 도구는 자신만이 가지고 있도록 하여, 원본 데이터와 원본 데이터를 암호화한 데이터를 같이 보내면, 이를 받은 사용자들이 해독하는 도구를 통해 암호화한 데이터를 복구하고, 원본데이터와 대조해보면, 원본데이터의 작성자가 전송자임을 명확하게 확신할 수 있는 것입니다. 즉, 원본데이터를 암호화한 데이터가 바로 하나의 서명이 되는 것입니다. 왜냐하면, 이를 암호화하는 키는 전송한 사람만 갖고 있기 때문입니다.

**programming적으로 이러한 공개키 방식을 구현하는 것은 one way function (한 방향 함수, 암호화는 쉽지만 inversion이 어려운 함수, 암호화 도구)이면서, trap door(속임수, 해독하는 도구)를 가지는 algorithm을 찾아내는 것입니다.** 즉, key를 갖고 있으면 쉽게 암호를 생성할 수 있지만, key가 없다면, 이를 만드는 것이 사실상 불가능하도록 만드는 것입니다. 여기에서 일반적으로 가장 많이 사용되는 것이 RSA라는 소인수 분해의 난해함을 이용하는 algorithm이 있습니다.

하지만, Bitcoin에서는 서명을 하기 위해서, ECDSA(Elliptic Curve Digital Signature Algorithm)를 사용합니다. 따라서, 여기서는 이 기술에 대해서 자세히 알아볼 것입니다.

일단 이를 이해하기 위해서 이를 이루는 기반 수학적 용어를 먼저 배워야 합니다.

1. 유한 공간 Finite Field
2. 타원 곡선 Elliptic Curve

따라서, 이에 대한 내용을 이제부터 하나하나씩 살펴보겠습니다.

## 1. 유한 공간 Finite Field

들어가기에 앞 서 두 가지 개념을 정리하고 가야 합니다.

먼저, 소수입니다. **소수**(**Prime Number**)는 1과 자신 이외의 자연수로 나눌 수 없는, 1보다 큰 자연수입니다. 또한, 해당 숫자들은 규칙성을 갖고 있지 않기 때문에, 하나의 소수가 주어진 뒤에 이보다 큰 바로 다음 소수를 찾는 것은 직접 해보지 않으면 알 수 없습니다.

다음은 **modulo(나머지 연산자, %)입니다.** 특정 값을 나누고, 남은 나머지를 반환하는 연산자라고 말할 수 있습니다.

$$10 \% 3 = 1, 10 \% 2 = 0$$

해당 연산은 일반적인 대수학의 연산과는 다르게 동작하게 하기 때문에, 이에 대하여, 앞으로 사용할 특징 몇 가지를 정리해보겠습니다.

1. $ a \% b \lt b $
2. $ (a \times b) \% c = \{(a \% c) \times (b \% c)\} \% c $
3. $ a^{b} \% (b-1) = 1 $

위의 3가지 특징에 대한 자세한 증명은 여기서 다루기보다, 궁금하시다면, 직접 찾아보시길 바랍니다.

이를 통해서 Finite Field에서의 연산을 표현할 수 있으니 이를 기억해둡시다.

**Finite Field**란 특정 소수보다 작은, 0을 포함한 자연수 집합으로, 이루어지고,

$$ F\_3 = \{ 0, 1, 2 \} $$

$$ F\_{11} = \{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 \} $$

다음 6가지 조건을 만족하는 집합을 의미합니다.

- Additive closed, 덧셈에 대하여 닫혀있다.
- Multiplicative closed, 곱셈에 대하여 닫혀있다.
- Additive identity, 덧셈에 대한 항등원($0$) 을 갖는다.
- Multicative identity, 곱셈에 대한 항등원($1$) 을 갖는다.
- Additive inverse, 덧셈에 대한 역원($-a$)을 갖는다.
- Multicative inverse, 곱셈에 대한 역원($a^{-1}$)을 갖는다.

각 조건을 살펴보기에 앞서서 Finite Field를 정의하는 소수보다 큰 값은 해당 소수를 통해서 modulo 연산되어, Finite Field에 속하게 됩니다. (이는 modulo 연산의 첫 번째 특징($a \% b \lt b $)을 통해 알 수 있습니다.) 마치 시계와 같이 순환하는 구조를 가진다고 생각할 수 있습니다.

이를 통해서, Finite Field의 첫 번째와 두 번째 조건은 만족한다는 것을 알 수 있습니다. 왜냐하면, 덧셈과 곱셈으로 생성된 결괏값은 반드시 다시 Finite Field에 속하게 되기 때문입니다.

세 번째, 네 번째 조건은 소수는 항상 2보다 크기 때문에, 0과 1을 포함할 수밖에 없음을 알 수 있습니다. 따라서, Finite Field는 덧셈과 곱셈에 대한 항등원을 가진다는 것을 확인할 수 있습니다.

다섯 번째는 다음과 같습니다.

$F\_{p} = \{0,1,2,3,..., p - 2, p - 1\}$이고, $ a \in F\_{p} $인 경우

$$ -a = p - a $$

라고 정의할 수 있습니다.

여섯 번째는 다음과 같습니다.

$F\_{p} = \{0,1,2,3,..., p - 2, p - 1\}$ 이고, $ a \in F\_{p} $인 경우

$$ a^{-1} = a^{-1} \times 1 = a^{-1} \times a^{p-1} $$

$$ a^{-1} = a^{p - 2} $$

modulo의 세 번째 특징을 활용하여 다음과 같이 정의할 수 있습니다.

이러한 modulo 연산을 활용하는 Finite Field의 특징은 다음과 같습니다.

위에서 보았듯이 덧셈과 곱셈 연산은 역원이 존재하여, 결괏값을 갖고 역으로 원래 값을 찾아내는 것이 가능합니다. 하지만, 이 공간에 역이 없는 연산자를 추가한다면 어떻게 될까요? 이를 기억하고 넘어갑시다.

## 2. 타원 곡선 Elliptic Curve

다음 식을 만족하는 점들이 그리는 곡선을 우리는 타원 곡선이라고 합니다.

$$ y^2 = x^3 + ax + b$$

![elliptic-curve](/images/elliptic-curve.jpeg)

타원 곡선 상에서 우리는 덧셈 연산과 굉장히 유사한 연산을 정의할 수 있습니다. 실제로 동작은 일반적인 수학에서의 덧셈은 아니지만, 덧셈의 특징을 갖기 때문에 $+$ 기호로 표현합니다.

바로, 각 타원 곡선과 3개의 점을 가지는 선을 그었을 때, 항상 다음 식을 만족한다는 것입니다. (R은 타원곡선과 만나는 세 번째 점을 X축 대칭이동한 점을 말합니다.)

$$ P + Q = R $$

![elliptic-curve-addition-1](/images/elliptic-curve-addition-1.jpeg)

$P(x\_1, x\_2)$, $Q(x\_2, y\_2)$가 타원 곡선 $y^2=x^3 + ax + b$ 위의 점이라고 할 때, $R(x\_3, y\_3)$의 좌표는 다음과 같이 표현할 수 있습니다.

- $ s = {dx \over dy} = { 3x^2 \over  2y } = { {y\_2 - y\_1} \over  {x\_2 - x\_1}} $
- $ x\_3 = s^2 - x\_1 -x\_2 $
- $ y\_3 = s(x\_1 - x\_3) - y\_1 $

이 연산 역시 다음과 같은 조건을 만족시킵니다.

- Identity, 항등원이 존재한다. => $ A + I = A $
- Invertibility, 역원이 존재한다. => $ A = (a\_1, a\_2)이면, -A= (a\_1, -a\_2) $
- Commutativity, 교환 법칙 => $ A + B = B + A $
- Associativity, 결합 법칙 => $ A + (B + C) = (A + B) + C $

여기서의 역원은 x축 대칭 이동을 통해 얻은 값이라는 것을 확인할 수 있습니다. 또한, 교점이 세 개인 시점에서 직선의 기울기를 무한대로 계속 올리다 보면 결국은 y축에 대칭인 형태로 직선이 만들어지는 것을 볼 수 있습니다. (아래 그림에서 두 번째) 이 경우에 우리는 실제로는 교점이 두 개지만, 무한대 지점에서 교점이 하나 더 있다고 말하고 이를 I(Infinity)라고 정의합니다. 그렇게 되면, 항등원이 바로 I가 되는 것을 확인할 수 있습니다. (두 번째 그림에서 $P + I = P$가 되는 것을 확인할 수 있습니다.) 이를 통해서 두 번째에 존재하는 역원까지도 증명이 가능합니다.($P + (-P) = I$)

![elliptic-curve-addtion-2](/images/elliptic-curve-addition-2.png)

![elliptic-curve-addition-3](/images/elliptic-curve-addition-3.jpeg)

세 번째는 너무나 자명하기 때문에 넘어가고, 네 번째는 아래 그림을 통해서 설명할 수 있습니다.

주황색 : $ (P + Q) + S = R\_1 + S = T $

초록색 : $ (P + S) + Q = R\_2 + Q = T $

![elliptic-curve-addition-4](/images/elliptic-curve-addition-4.jpeg)

추가적으로 살펴볼 수 있는 하나의 연산을 하나 더 알아보고 갑시다.

바로 접선에서 연산입니다. 이 경우는 P와 Q가 같다고 여깁니다. 즉, 자기 자신을 두 번 더 하는 것과 같습니다. 따라서, 우리는 이를 $ P + P = R = 2P $라고 표현합니다. 또한, 이를 반복하면서, 결과 값을 도출할 수 있습니다. 따라서, 우리는 다음과 같은 식도 작성이 가능합니다. (이를 우리는 Elliptic Curve에서의 **Scalar Multiplication**이라고 합니다.)

$$ kP = R $$

이를 계산하기 위해서는, 일반적으로 k 번의 Elliptic Curve Addition을 수행하게 됩니다. 하지만, 이를 더 간략화할 수 있는 방법이 있습니다.

$$ R = 63P = (1 + 2 + 4 + 8 + 16 + 32) P = (1 + (1+1) + (2+2) + (4+4) + (8+8) + (16+16)) P $$

즉, 이전 계산의 결과를 현재 계산에 활용하여 계산을 더 빠르게 할 수 있습니다. 위 예시에서는 62(63 - 1) 번의 더하기 연산을 10번으로 줄인 것을 볼 수 있습니다. (물론 이외에도 많은 방식으로 최적화를 할 수 있지만, 이 정도면 대게 충분합니다.)

![elliptic-curve-addition-5](/images/elliptic-curve-addition-5.jpeg)

여기서 주목할 포인트를 하나 짚어보고 가야합니다. 우리가 $R$과, $P$를 알고 있을 때, $k$ 구하는 것이 가능할까요?

이는 쉽지 않은 문제가 됩니다. 왜냐하면, 이러한 scalar multiplcation문제에서는 역원이 존재하지 않기 때문에, k에 값을 1부터 대입해보면서 확인해 볼 수밖에 없습니다.

---

이제 기본이 되는 두 이론을 세팅하였습니다.

일단은 유의해야 할 점은 바로 Finite Field로 Elliptic Curve를 가져오게 되면, 이는 discrete(불연속) 해진다는 점입니다. 또한, Scalar Multiplication에도 변화가 발생합니다. **바로 순환이라는 것이 생긴다는 점입니다.** $nP = R = 0$ 이 되는 $n$값이 존재하게 된다는 것입니다. 또한, 역원이 없는 성질 또한 유지되기 때문에, $kP$를 통해서 생성된 값($R$)과 P를 모두 공개하더라도, $k$가 밝혀질 가능성은 $n$값이 커질수록 불가능에 가깝다는 것입니다.

실제로 Bitcoin에서는 이 N을 매우 크게 설정하였기 때문에 문제가 없다고 할 수 있습니다. 한 번 Bitcoin에서, Finite Field 상의 Elliptic Curve의 모든 변수를 정리해봅시다.

기본적으로, 해당 암호화에 사용되는 모든 값의 단위는 256 bits 즉, 32 bytes를 사용합니다.

1. Elliptic Curve의 형태 : $a=0$, $b=7$을 사용하는 secp256k 1을 사용합니다. 이 형태는 다음과 같습니다. $$y^2 = x^3 + 7$$
2. Finite Field의 소수 : 위에서 말한 대로 $n$의 값을 크게 하기 위해서 finite field 자체의 크기도 매우 커져야 하기 때문에, $p$ 역시 매우 큽니다. $$p = 2^{256} - 2^{32} - 977 $$
3. Scalar Multiplication에 사용되는 Elliptic Curve 위의 한 점($G$) : 이 또한 매우 크기 때문에 각 좌표별로 따로 적겠습니다. $G\_x = $ 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798  
    $G\_y = $ 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
4. Scalar Mutiplication에 의해서 만들어지는 $k$의 범위 ($n$) : 위에서도 보았겠지만, 0x는 16진수를 의미합니다.  
    $n = $ 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141  

위의 데이터를 보다시피 매우 큰 범위의 값을 사용하는 것을 알 수 있습니다.

여기서 한 번 우리가 암호화 키와 해독 키(공개키)를 각 각 만들어보도록 하겠습니다.

먼저, 암호화 키($e$)를 만드는 것은 매우 쉽습니다.

바로 $n$보다 작은 임의의 수를 고르면 됩니다.

그리고, 이를 이용해서, 우리는 바로 해독 키인 공개키를($P$) 만들 수 있습니다.

$$ P = eG $$

이렇게 하면 끝입니다. 우리는 $e$를 모르기 때문에, $P$와 $G$가 모두가 아는 값이라고 할지라도 $e$를 알아낼 수 없습니다.

그렇기에 우리는 안심하고, P를 공개할 수 있는 것입니다.

이제 우리는 이것을 이용해서 한 번 서명을 통한 인증을 수행해보도록 하겠습니다.

먼저, 우리가 보내고자 하는 데이터를 $m$이라고 하겠습니다. 하지만, 이를 바로 사용하는 것은 쉽지 않습니다. 왜냐하면, 보내고자 하는 데이터의 크기가 32 bytes를 항상 만족하지 않기 때문입니다. 그렇다면, 이를 32 bytes로 변환해줄 방법이 필요할 것입니다. 그래서, 우리는 hashing을 수행합니다. 또한, 원본데이터 자체를 알아볼 수 없게 바꿔버리는 역할도 해서 암호화의 역할도 할 수 있습니다. 이를 통해서 만들어진 데이터를 우리는 $z$라고 하겠습니다.

이제 여기서, 우리는 비밀키가 아닌 또 하나의 값을 하나 생성해야 합니다. 바로 $k$입니다. 이는 비밀키와 마찬가지로 $n$보다 작은 32bytes로 지정해야 합니다.

$$ kG = R $$

을 전송자 측에서 계산을 하고, $R$의 $x$ 좌표를 $r$이라고 정의하면 거의 모든 설정은 끝났다고 할 수 있습니다.

이제 진짜로 서명을 시작할 수 있습니다.

바로 $ uG + vP = kP = R $라고 할 때,

$$ u + ve = k $$

$$ u = z / s $$

$$ v = r / s $$

가 되도록 하는 것입니다.

이렇게 되면, $u$라는 값은 $z$를 가지므로, 원본 데이터를 포함한다고 할 수 있습니다. 또한, $v$는 $r$을 포함하기 때문에 결과 값 자체를 포함하고 있다고 볼 수 있습니다.

이는 해당 방정식을 풀어서 보면, $$ s = ( z + re ) / k $$라는 것을 알 수 있습니다. 여기서 $e$와 $k$라는 감춰져야만 하는 값이 두 개 포함되는 것을 알 수 있습니다. 해당 방정식은 안전하게도 $e$, $k$가 모두 변수로 남기 때문에 $s$, $z$, $r$을 안다고 해도 $e$와 $k$를 구할 수는 없습니다.

따라서, $s$와 $r$을 하나로 합쳐서 하나의 서명(Signature)을 이루게 됩니다.

따라서, 전송자는 $z$(보낼 데이터)와 $r$, $s$(서명)를 전송함으로써, 데이터의 수신자가 직접 서명의 적절함을 확인할 수 있습니다.

수신자는 이제 받은 데이터를 통해서 다음 과정을 진행한다고 볼 수 있습니다.

1. $u$와 $v$를 생성합니다. ($u = z / s $, $v = r / s$)
2. $uG + vP$의 연산을 수행합니다.
3. 위의 결괏값을 통해서 얻은 좌표값의 x 좌표와 r 값을 비교하여 동일한지를 확인합니다.  
    $$ uG + vP = R $$
4. 이것이 동일하다면, 해당 데이터는 인증된 데이터입니다.

이것이 BitCoin에서 사용하는 서명 방식인 ECDSA입니다. 이에 대한 구현은 github에 올려 두었으니, 확인을 원하시면 체크해보시길 바랍니다.

[🔗 GitHub - euidong/bitcoin](https://github.com/euidong/bitcoin)

## Reference

- [🔗 Programming Bitcoin](https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/)
- Tumbnail : Photo by [Icons8 Team](https://unsplash.com/@icons8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@icons8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


[Bitcoin] 1. ECDSA를 이용한 서명

## Intro

Algorithm과 object 간의 책임 분배에 관한 pattern입니다.

즉, object의 사용 목적에 따라서 method를 정의할 때, 많이 사용되는 구현 pattern을 의미합니다.

## Behavioral Pattern

### 1. Chain of Responsibility(CoR)

![cor](/images/cor.jpeg)

**request를 여러 handler들을 하나의 chain으로 연결한 object에 전달하여 request를 처리하는 방식입니다.** 여기서 각 각의 handler는 스스로 작업을 끝내고 response를 보낼 수도 있고, 이를 다음 handler로 전달할 수도 있으며, 해당 request를 이용해서 side effect를 만들 수도 있다.

이는 대게 request를 처리하는 module을 설계하는 과정에서 많이 사용됩니다. 예를 들어, REST API 를 구현하고자 할 때, 여러 request에서 공통적으로 사용되는 logic을 별도의 middleware라는 것으로 분리하여 구현하고 재활용하는 것을 많이 볼 수 있습니다. (ex. nodeJS express, Go http.Handler, etc...)

---

여기서 CoR의 특징을 살펴보고 갑시다.

- Request의 처리 순서도 제어할 수 있습니다.
- 각 handler가 하나의 역할만 하도록 하여, 유연성과 가독성을 높일 수 있습니다.(Single Responsibility)
- 새로운 handler의 추가가 기존 code의 영향을 주지 않습니다. (Open/Close)

### 2. Command

![command](/images/command.jpeg)

**모든 request를 하나의 queue에 저장하고, 처리자는 queue의 순서에 따라서, request를 처리하는 pattern입니다.** 이러한 방식은 request를 마치 하나의 method paratemer로 받아들이도록 하고, request의 실행을 queue로 관리함으로써, 쉽게 되돌리기 기능도 지원하도록 할 수 있습니다.

쉽게 예를 들면, 식당에서 웨이터는 주문을 받아서, 영수증을 순서에 따라서 order board에 붙이면, 주방장은 이를 보고, 순서에 따라서 요리를 내보내는 형식이라고 보면 되겠습니다.

구현 시에는 Command라는 Interface를 구현하는 각각의 Command class를 작성합니다. 여기서 각 Command는 생성 시에 receiver를 전달받아서, 호출 시에 이를 Receiver에게 전달할 수 있도록 합니다. 그리고, Command Interface를 호출하는 Invoker를 선언해줍니다.

---

Command의 특징은 다음과 같습니다.

- Command 단위로 class를 구분할 수 있기 때문에 유연성이 높아집니다. (Single Responsibility)
- 새로운 Command의 추가가 기존 code에 영향을 주지 않습니다. (Open/Close)
- 되돌리기와 다시 재생 등의 동작의 구현이 쉽습니다.

### 3. Iterator

![iterator](/images/iterator.jpeg)
**내부의 구현물을 들어내지 않은 상태에서 구성요소를 순환하기 위해 고안된 pattern입니다.**

기본적으로는 iterator는 다음과 같은 요소로 이루어집니다.

1. 현재 자신의 구성요소를 retuern하는 method
2. 다음 iterator를 반환하는 method
3. 다음 iterator가 존재하는지를 체크하는 method

해당 object를 통해서 전체 구조를 순환할 수 있도록 하는 방식입니다. 주요 예시는 file 입출력을 예를 들 수 있습니다. 대게 while 문을 통해서 더 이상 읽을 문자가 없을 때까지 line 단위로 받아오며, next를 호출하는 식의 구현을 많이 보았을 것입니다. 이를 사용하는 이유는 두 가지로 들 수 있습니다.

1. object 내의 자세한 구현을 감추기 위해서
2. 필요에 따라 여러 iterator를 생성하기 위해서

대게 object가 하나 이상의 동일 object를 포함하게 된다면, 이 object를 순환할 수 있는 방법은 여러 가지가 존재하게 됩니다. 예를 들어 tree를 구현했다고 했을 때, 기본적으로 depth first search, breadth first search을 생각할 수 있습니다. 하지만, 상황에 따라서 효율적인 방식이 다르기 때문에, 각기 다른 순환 방식을 지원하는 것이 좋습니다.

---

iterator의 특징을 살펴보고 갑시다.

- Iterator 각 각에 필요로 하는 algorithm을 구현할 수 있기 때문에 유연한 구조를 가질 수 있습니다. (Single Responsibility)
- 새로운 iterator의 추가가 기존 code에 영향을 미치지 않습니다. (Open/Close)
- object로부터 생성된 각 iterator는 서로 독립적으로 동작할 수 있습니다.
- 하지만, 해당 구현은 다루고자 하는 데이터의 양이 적은 경우 지나칠 수도 있고, 직접 접근하는 것보다 속도가 느릴 수 밖에 없습니다.

### 4. Mediator

![mediator](/images/mediator.jpeg)

object 간의 혼란스러운 의존성을 줄이기 위해서 고안된 pattern으로, **object 간의 직접적인 사용을 제한하고, mediator라는 중계자를 통해서만 동작할 수 있도록 하는 pattern**입니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 디양한 object 간의 communication을 추출할 수 있기 때문에, object 본연의 작업에 집중하여 편리하고 유지하기 쉽게 만듭니다. (Single Responsibility)
- 새로운 mediator를 추가할 때, 기존 code의 변경이 필요 없습니다. (Open/Close)
- 각 Object 간의 의존성을 제거할 수 있습니다.
- 개발이 진행될수록 mediator가 전체 시스템을 관리하는 a God Object가 되고, mediator를 사용하는 모든 object가 이에 의존성이 생기게 됩니다.

### 5. Memento

![memento](/images/memento.jpeg)

object의 상태 변경에 이전 상태가 큰 영향을 미치거나 history에 대한 구현이 필요한 경우 구현할 수 있습니다. **object의 구체적인 구현에 대한 내용을 제외하고, 이전 상태를 저장하고, 필요에 따라 이를 다시 불러와서 사용하는 pattern**입니다.

구현을 하기 위해서는, 본래의 object를 그대로 두고, 필요로 하는 private variables를 포함하는 memento를 구현하여 state를 받을 수 있는 method를 포함하게 해서, 이 memento들만 caretaker라는 object에서 list형태의 history로 저장할 수 있도록 합니다.

---

memento의 특징은 다음과 같습니다.

- 기존 object의 encapsulation을 유지하면서, 기능을 구현할 수 있습니다.
- 기존 code를 그대로 유지한 채로 caretaker를 통해서, history logic을 작성할 수 있습니다.
- 그러나, memento를 유지하기 위한 추가적인 공간이 필요하며, 오래된 데이터 삭제를 위한 원본을 향한 추적이 필요로 됩니다.

### 6. Observer

![observer](/images/observer.jpeg)

가장 많이 쓰이면서, 중요한 pattern 중에 하나라고 생각합니다. **subscription 로직을 정의하고, subscription을 수행한 모든 object에게 특정 event의 발생을 전달하는 방식입니다.**

즉, object에서 특정 event가 발생하면, 이를 계속해서 broadcasting 하는 방식입니다. 따라서, 이를 구독하고 있는 각 object가 이에 따른 처리를 수행하는 방식입니다.

구현을 하기 위해서는,

Command Pattern과 굉장히 유사하다고할 수 있습니다. Command Pattern은 Queue에 Command를 차곡차곡 쌓아두고, 이를 사용하기를 원하는 Object가 이를 찾아가는 방식이라면, Observer Pattern은 저장하기보다는 이를 필요로 하는 Object에게 전달하는 방식입니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 새로운 Subscriber, Publisher가 기존 code에 영향을 미치지 않습니다. (Open/Close)
- 실행 중에 object간의 관계를 생성하는 것이 가능합니다.
- 그러나, Subscriber 간의 순서를 정의하거나 각 event의 순서를 엄밀히 구현하는 것은 별도의 구현체를 필요로 합니다.

### 7. State

![state](/images/state.jpeg)

**object의 내부 상태가 변화할 때마다 동작을 바꾸도록 하는 pattern입니다.** 마치 object가 이것의 class를 바꾸는 것과 같은 효과를 볼 수 있습니다.

가장 일반적으로 볼 수 있는 예시가 게시글 작성이다. 엄격한 절차를 따르는 글 작성에는 다음 세 가지의 과정을 거치게 됩니다.

1. 제출 전
2. 제출 완료 (검토 중)
3. 배포 (업로드 완료)

각 단계마다 사용할 수 있는 method와 각 method의 동작이 달라질 수 있습니다. 이를 별도의 class로 나누지 않고, 하나의 class로 만들면서 state를 포함하도록 함으로써, 이를 내부에서 control 할 수 있도록 하는 pattern입니다.

구현 시에는 각 State를 별도의 Class로 분리하고, 그 내부에서 변경되는 method를 직접 구현하도록 합니다. 따라서, 실제 state를 포함한 원본 class는 이 state에 정의된 method를 호출하도록 할 수 있습니다.

---

state의 특징을 살펴보고 갑시다.

- 별도의 state를 class로 분리하기 때문에, 유연한 구조를 만들 수 있습니다. (Single Responsibility)
- 새로운 state의 추가가 기존 code에 영향을 주지 않습니다. (Open/Close)

### 8. Strategy

![strategy](/images/strategy.jpeg)

동일한 method에 대해서 여러 algorithm을 정의하고, 각각을 별도의 class로 나누어 상호 호환이 가능하도록 하는 pattern입니다.

**즉, object의 method 자체를 별도의 interface로 분리하는 방식이라고 이해할 수 있습니다.** 앞서 보았던 state는 context(문맥)에 따라서, 상태가 바뀌지만 Strategy Pattern에서는 행위 자체가 바뀐다고 생각하면 됩니다.

대게 게임에서 쉽게 예시를 생각할 수 있습니다. player의 skill을 interface화 시키고, 해당 동작에 따른 damage와 mp 변화 등을 각 skill마다 직접 계산하여 player object로 전달할 수 있다고 생각하면 쉽습니다.

---

strategy의 특징을 살펴보고 갑시다.

- 실행 중의 특정 strategy를 선택하여 실행시키는 것이 가능합니다.
- 각 strategy에 대한 자세한 구현을 감출 수 있습니다.
- 대게 상속 형태를 대체하여 사용하는 것이 가능합니다.
- 새로운 strategy의 추가가 기존 code에 영향을 미치지 않습니다. (Open/Close)

### 9. Template Method

![templateMethod](/images/templateMethod.jpeg)

**algorithm의 skeleton을 상위 class에 정의하고, 전체적인 구조는 바꾸지 않으면서 각 단계에 대한 구현을 override 하는 pattern입니다.**

따라서, 전공과목 과제를 하다 보면 교수님들이 skeleton 코드를 준다고 했을 때, 대게 구조만 있고, 각 함수의 내부가 비어 있는 것을 볼 수 있었던 거 같습니다. 따라서, 해당 class를 inherit 하여 구체적인 구현을 하는 식으로 class를 만들면 됩니다.

---

template method의 특징은 다음과 같습니다.

- 구현의 내용을 줄이고, 중복되는 코드의 사용을 줄일 수 있습니다.
- 그러나, skeleton에 의한 제한으로 불가피하게 code의 변경이 발생할 수 있습니다.

### 10. Visitor

![visitor](/images/visitor.jpeg)

**특정 object에 접근하려는 object에 따라 별도의 algorithm을 적용하는 pattern입니다.**

즉, 사용하고자 하는 object를 하나의 interface로 추상화하고, 각 object는 이를 사용할 client(visitor)를 허용할 것인지 그리고 어떤 algorithm을 수행할 것인지를 정의해둡니다. 사용할 수 있는 예시는 사용할 수 있는 Element의 종류가 매우 다양하며 계속해서 추가될 가능성이 높을 때 사용할 수 있습니다. 그렇지만, Visitor의 추가는 매우 어렵기 때문에 이에 유의해야 합니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 새로운 algorithm의 추가가 기존 code의 변경없이 가능합니다. (Open/Close)
- 동일한 class 내부에서 동일한 동작을 여러 version으로 정의할 수 있어 유연합니다. (Single Responsibility)
- 그러나, visitor의 추가는 기존 algorithm의 수정을 불러올 수 있습니다.

## Reference

- Design Patterns: Elements of reusable object oriented software.
- Refactoring GURU : [https://refactoring.guru/design-patterns/structural-patterns](https://refactoring.guru/design-patterns/structural-patterns)
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

[Design Pattern] 4. Behavioral Pattern

## Intro

앞 서 살펴본 creational pattern이 object의 생성에 대한 방법들을 제공하였다면, 해당 object들의 관계를 어떻게 연결할 것인가에 대한 고민에서 만들어진 pattern이라고 생각하시면 됩니다.

예를 들어서, 외부 라이브러리와 내부 모듈 간의 상호작용이나 이들을 연결하는 방식을 정의하는 것이 일반적으로 가장 많이 사용되는 경우라고 볼 수 있습니다.

## Structural Pattern

### 1. Adapter

![adapter](/images/adapter.jpeg)

object와 object간의 상호작용을 돕는 가장 기본적인 방법입니다. 제 생각에는 **Converter로** 표현할 수 있을 거 같습니다. 예를 들어, pdf를 필요로 하는 module이 있다고 했을 때, 우리가 가진 것이 이미지밖에 없다면, 우리는 이를 변환해줄 수 있는 converter를 중간에 설치함으로써 이들을 수정해주지 않고, 합칠 수 있을 것입니다. 이러한 방식이 바로 Adapter pattern의 핵심이라고 할 수 있습니다.

일반적인 구현은 adapter라는 class를 변환 결과물의 class의 확장(상속)으로 둡니다. 이렇게 하면, 해당 class의 속성을 모두 가집니다. 여기서 adapter의 생성 시에 변환 전의 class를 전달하여, 내부 구현을 overriding 하는 방식을 취하도록 하는 방법입니다. **즉, adapter 자체가 원하는 제품의 변환 완료 상태라고 보시면 됩니다.**

refactoring.guru 사이트에서 예시를 든 상황을 봅시다.

원형 구멍에 원기둥을 넣으면서, 원형 구멍보다 반지름이 큰 원기둥은 filtering하는 코드가 있었다고 합시다. 이때, 원기둥이 아닌 직육면체를 넣고 싶다면, 어떻게 해야 할까요? 직육면체를 마치 원기둥처럼 받아들일 수 있도록 직육면체의 밑변의 변의 길이를 통해서 반지름을 생성해내는 로직을 가진 adapter를 만들어내면 될 것입니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 기존의 변환 결과물로 돌아가는 코드를 그대로 사용하는 것이 가능합니다.
- 대게 data의 변환 시에 많이 사용됩니다. (ex. XML -> JSON)
- 사실 임시 방편이라고 볼 수도 있습니다. 위에 원형 구멍에 넣을 수 있는 것을 원형기둥으로 제한한 상황에서 직육면체를 넣었다는 것에서부터 가독성이 떨어지고, 복잡도가 높아질 수 있는 것입니다.

### 2. Bridge

> before

![bridge-1](/images/bridge-1.jpeg)

> after

![bridge-2](/images/bridge-1.jpeg)

하나의 class의 크기가 너무 비대해지거나 각 class들 간의 의존성이 높아지는 경우에 이를 두 개의 계층 구조로 나누어 의존성을 제거하면서 개별적으로 개발하는 환경을 만드는 방식입니다.

개발을 진행하다 보면, 하나의 class의 크기가 굉장히 비대해지는  경험을 할 수 밖에 없습니다. 예를 들어서 처음에는 단순히 버튼이라는 class를 만들었었는데, 디자인의 detail을 위한 내용에 의해서 코드가 굉장히 비대해지고, 이를 click 했을 때, hover 했을 때와 같은 로직도 계속해서 추가되면서 class가 비대해지는 것을 볼 수 있습니다. 따라서, 여기서 design 부분을 별도의 class로 분리시키고 이를 기존 button class가 변수로 포함하는 방식이라고 생각할 수 있습니다.

**즉, 여러 구현 method, attribute를 하나의 attribute type으로 통합하고, 이를 interface로 만들어 사용하는 것입니다.** 이렇게 함으로써 좀 더 유연한 구조를 가질 수 있습니다. 사실 우리의 main application이 module을 직접 구현하지 않고, 여타 module을 install하여 사용하는 것도 이와 유사하다고 할 수 있겠습니다.

---

여기서 bridge의 특징을 살펴보고 갑시다.

- 대게 design(css style)/platform(ios, android, web)과 logic을 분리하여 서로간 의존성을 분리할 때, 유용합니다.

### 3. Composite

![composite](/images/composite.jpeg)

**object들을 tree 구조로 만들어**서 마치 하나의 object 인 것처럼 동작시키는 방법입니다. 그렇기에 만들고자 하는 구현 목표 자체가 tree 구조로 표현 가능할 때에만 사용 가능합니다. tree는 자신의 기능을 담는 root와 다른 subtree들로 이루어지며, 이들을 가리키는 pointer를 가진다.(subtree는 없을 수도 있다.)

대게 구현을 위해서, 가장 기반이 되는 기능을 interface type으로 생성하면, leaf처럼 사용될 class와 이를 담을 수 있는 형태의 class로 나누어 구현합니다.

예를 들면, file system을 예로 들 수 있습니다. file system은 크게 file과 folder로 나뉘어집니다. folder는 마치 하나의 subtree가 되는 것이고, file은 하나의 leaf가 되는 것이라고 생각할 수 있습니다. 각 leaf마다 알맞은 구현을 할 수 있고, folder에도 알맞은 구현을 쉽게 구현하는 것이 가능합니다.

---

여기서 composite의 특징을 살펴보고 갑시다.

- 계층으로 이루어지는 복잡한 구조를 쉽게 구조화할 수 있습니다.
- 새로운 요소를 추가할 때에도, 기존 코드에 영향을 주지 않습니다.
- 그러나, 억지로 도입하기 위해서, 과도하게 일반화한 구조를 가지게 되면, 이해하기 어려운 구조가 될 수 있습니다. 즉, tree를 구조를 가진다는 것이 명확할 때에만 사용하는 것이 좋습니다.

### 4. Decorator

![decorator](/images/decorator.jpeg)

**새로운 기능들을 object에 추가하기 위해서 기존 object는 그대로 두고, 새로운 기능을 포함하는 wrapper로 감싸주는 방식입니다.**

만약, 핸드폰 push 알림 기능을 구현해놓았고, 이를 여러 업체에게 배포하였다고 가정합시다. 그런데, 어떤 업체에서는 Facebook 알림, 또 다른 업체에서는 Slack 알림을 추가로 전송하기를 원한다면, 어떻게 해야 할까요? 가장 쉽게 생각 나는 방법은 각 notification 기능을 수행할 수 있는 class를 생성하고, app에서 여러 개를 생성해서 보내는 방법일 것입니다. 하지만, 단 하나의 object만 받을 수 있도록 구현이 되어 있고, 이를 실행시키는 app code를 변경할 수 없다면, 우리는 결국 3 가지의 알림을 하나의 class로 구현하기 위해서, 7개의 class가 필요합니다.

1. push 알림만 있는 class
2. facebook 알림만 있는 class
3. slack 알림만 있는 class
4. push + facebook 알림 class
5. push + slack 알림 class
6. slack + facebook 알림 class
7. push + slack + facebook 알림 class

이러한 구조를 가지는 거는 굉장한 중복 코드를 만들어낼 가능성이 있습니다. 그래서 나온 pattern이 decorator입니다. 기존 object에 새로운 기능을 하는 object를 감싸는 방법입니다. 실행 시에는 밖 or 안부터 실행을 시키면서 진행합니다.

---

여기서는 decorator의 특징을 살펴봅시다.

- 이 역시 기존 코드의 수정이 필요 없습니다.
- runtime에 쉽게 새로운 구현을 추가하거나 삭제할 수 있습니다.
- 각 wrapper가 하나의 기능만 하도록 구현하여, responsibility를 하나만 갖도록 할 수 있습니다.
- 그러나, 때로는 wrapper간 의존성으로 인해 특정 wrapper를 제거할 수 없는 경우가 생길 수도 있습니다.

### 5. Facade

![facade](/images/facade.jpeg)

**간소화된 interface를 복잡한 class 구조(library, framework)에 간단한 interface를 제공하는 pattern입니다.** 즉, third party를 사용할 때, 직접적으로 호출하는 것이 아닌 facade라는 object를 통해서 추상화한 method를 사용하도록 함으로써 실제 시스템과 third party와의 의존성을 줄이는 방식입니다.

---

facade의 특징은 위에서 말한 바와 같고, 주의사항이 하나 존재합니다.

- facade가 모든 object들의 구현을 아는 a god object가 될 수도 있습니다. 이렇게 되면, 사실상 이를 이용하는 application도 결코 system에 독립적일 수 없습니다.

### 6. Flyweight

> before

![flyweight-before](/images/flyweight-before.jpeg)

> after

![flyweight-after](/images/flyweight-after.jpeg)

object를 유지하는데 비용을 너무 많이 사용하기 때문에, **일반적으로 사용되는 동일한 부분을 별도로 object에 포함시키지 않고 공유하도록 함으로써 object를 경량화하기 위해서 나온 pattern입니다.**

---

Flyweight의 특징은 다음과 같습니다.

- RAM의 사용량을 줄인다는 것은 그만큼 CPU 사용량이 늘어난다는 것을 의미합니다.
- 또한, Computer를 위한 설계이니 만큼 사람이 이해하기에 가독성이 떨어질 수 있습니다.

### 7. Proxy

![proxy](/images/proxy.jpeg)

대체 object를 제공하거나 또 다른 object를 위한 placeholder를 제공하는 pattern이다. original object에 접근을 제어하면서, 요청의 처리 전 후로, 특정 동작을 수행하도록 할 수 있습니다.

가장 많이 사용되는 사례는 당연하게도 Database에 접근하는 로직을 정의하는 API를 만드는 경우를 예로 들 수 있습니다. API server는 사실상 database에 접근하기 이전에 수행해야 할 동작들을 미리 정의하고, 요청이 들어오면 이를 처리하여 client에게 전송하는 방식으로 구현되어 있습니다. 이것이 필요한 이유는 민감정보의 보호와 서비스 데이터를 안전하게 보장하기 위함이라고 할 수 있습니다.

따라서, 해당 object만으로도 사용이 가능하지만, 요구에 따라서, object 접근 전후로 처리가 필요한 경우 proxy pattern을 통해서 구현하는 경우가 많습니다.

---

Proxy의 특징은 다음과 같습니다.

- service와 이를 이용하는 client와 독립적으로 구현이 가능합니다.
- 일반적으로 service에 직접 접근하는 것보다 delay가 발생할 수 밖에 없습니다.

## Reference

중간에 좋은 reference를 찾았기 때문에 여기서부터는 출처가 바뀝니다. 저도 해당 사이트의 도움을 많이 받았기 때문에 해당 사이트 한 번 직접 가보는 것을 추천드립니다.

- Design Patterns: Elements of reusable object oriented software.
- Refactoring GURU : [https://refactoring.guru/design-patterns/structural-patterns](https://refactoring.guru/design-patterns/structural-patterns)
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

[Design Pattern] 3. Structural Pattern

## Intro

object의 instantiation을 추상화하는 방법입니다.

즉, instance를 만들 때, 어떻게 하면 재사용과 변경에 유용한 구조로 만들 수 있을까에 대한 고민의 결과로 나온 pattern이라고 볼 수 있습니다.

일반적인 순서로는 Abstract Factory, Builder, Factory Method, Prototype, Singleton이지만, 제가 이해하기 쉬운 순서대로 정리하겠습니다.

모든 가정은 App이라는 main class에서 product1과 product2라는 object가 필요하다는 가정하에서 이를 어떻게 얻어오는지에 대해서 살펴보겠습니다.

## Creational Pattern

### 1. Singleton

![singleton](/images/singleton.jpeg)

가장 먼저 알아볼 것은 Singleton 입니다. 가장 기본이기에 가장 중요한 design pattern 중에 하나라고 생각합니다.

우리가 특정 object가 필요할 때, 해당 대상을 단 하나만 만들어서 이를 전역에서 접근하도록 하여 구현하는 방식을 의미합니다.

당연히 이 방식을 이용하게 되면, zero copy라는 측면에서 효율이 굉장히 좋을 것입니다. 하지만, 이러한 pattern을 남용하게 된다면, 누가 이 product에 접근하고 있는지 그리고 누가 변경했는지 알기 어려워집니다. 따라서, **해당 Singleton에서 중요한 점이라면, 변하지 않는 값만 가지도록 하는 것입니다.**

이를 통해서, 누가 이를 사용하더라도 시스템에는 영향을 안 주면, zero copy로 사용하기 때문에 굉장히 효율상으로도 훌륭하게 사용할 수 있습니다.

하지만, maintainable의 입장에서는 큰 약점이 될 수 있습니다. 하나의 구현을 바꾸게 된다면, 전체 시스템이 어디서 어떻게 영향을 받는지 알 수 없기 때문에 이 점에서는 약점을 가지고 있습니다.

하지만, 우리가 다루는 object에 변화가 필요하고, 능동적인 조작이 필요한 경우에 object 자체로 singleton으로 만드는 것에는 제한이 생깁니다. 따라서, 우리는 object의 instance를 대신해서 생성해주는 factory라는 개념을 사용하게 됩니다. (이들을 singleton으로 만드는 것이 좋습니다.)

이는 저번 챕터 1에서 보았던 delegation을 활용한 것입니다. 자신이 사용하고자 하는 object의 instantiation을 다른 object에게 맡기는 형식입니다. 이를 통해서, 본연에 하고자 하던 행동에 좀 더 집중할 수 있습니다.

---

다음으로 넘어가기 전에, 한 번 더 머릿속에 정리합시다. 지금의 App이 알고 있는 사항은 무엇일까요?

어떤 내용도 추상화를 통해서 감추지 않았기 때문에, 우리는 productA, productB라는 object가 정확하게 무엇인지 알고 있고, 이를 만드는 방법까지도 완벽하게 알고 있는 상태입니다.

### 2. Builder

![builder](/images/builder.jpeg)

가장 쉽게 object의 생성을 맡긴다고 했을 때, 상상할 수 있는 구조입니다. IBuilder라는 interface를 통해서 builder를 묶어줄 수도 있지만, 단순히 각 object(product)에 대한 builder를 생성해줄 수도 있습니다.

**여기서 중요한 개념은 각 product에 대한 전문 생성자를 구축한다는 점입니다.** 내가 만들고자 하는 object에 대해서 이것만을 전문적으로 만들 수 있는 class를 singleton으로 생성함으로써, 쉽게 무언가의 제품을 만들고 싶다면, 이 builder에게 맡기면 되겠다는 식의 발상으로 이어질 수 있습니다.

builder는 얻고자 하는 product에 대한 모든 내용을 추상화해버리기 때문에, 내부의 코드가 정교하게 만들어지고 변화가 없다면, 매우 좋게 작동할 수 있습니다. 하지만, product 하나를 여러 object들이 사용한다면, 후에 변경이 매우 어려워질 수 있습니다.

---

자 이번에도 넘어가기 전에, 한 번 더 머릿속에 정리합시다. 지금의 App이 알고 있는 사항은 무엇일까요?

우리는 현재 builder라는 대상에게 object의 생성을 넘겼습니다. 그렇기 때문에 우리는 productA, productB라는 object가 정확하게 무엇인지 알고 있지만, 이를 만드는 방법은 모르는 상태입니다.

### 3. Abstract Factory

![abstractFactory](/images/abstractFactory.jpeg)

이제 그림이 조금 복잡해집니다. 여기서는 좀 더 복잡한 상황을 고려한다는 것을 직감적으로 받아들이시면 됩니다.

이제 우리는 만들고자 하는 object도 어떤 부류 중에 하나다 정도로만 알 수 있습니다. 이 상황에서 우리는 이를 만들고자 하는 object 마저 추상화를 한 것을 볼 수 있습니다.

또한, 우리는 Factory를 Singleton으로 만들어야 한다는 점에도 주목해야 합니다.

결국 모든 생성의 대한 권한은 factory에게 넘어갔고, 필요에 따라서 우리는 특정한 factory를 골라서 사용하면 됩니다. 마찬가지로 product 역시 필요에 따라 골라서 사용하면 됩니다.

하지만, 이 pattern은 굉장히 비싼 pattern이라고 볼 수 있습니다. 후에 지원하고자 하는 product 자체를 하나 더 만든다면, (ProductC) 이를 추가하기 위해서 모든 Factory는 이를 생성할 수 있도록 변경이 되어야 할 것입니다.

---

그럼 이번에는 어떨까요?

우리는 현재 factory라는 대상에게 object의 생성을 넘겼습니다. 또한, product 또한 추상화를 통해서 이것이 무슨 기능을 하는지는 어렴풋하게 알고 있지만, 이것이 정확하게 무엇인지는 모릅니다.(예전에는 정확하게 구두라고 지정했다면, 이번에는 두루 뭉술하게 신발이라고 쓰고 이를 사용하고 있다고 생각하시면 됩니다.) 그렇기 때문에 우리는 productA, productB라는 object가 정확하게 무엇인지도 모르고, 이를 만드는 방법 또한 모르는 상태입니다.

### 4. Prototype

![prototype](/images/prototype.jpeg)

Prototype의 뜻부터 알고 가면 좋습니다. 이는 하나의 type을 대표할 수 있는 전형적인 예, 원래의 형태 정도로 해석할 수 있습니다. 즉, 특정 부류를 설명할 수 있는 전형적인 예에서 부터 확장을 시작한다는 개념으로 받아들이는 것이 좋습니다.

기존의 Interface를 이용하는 방식은 대상이 정확하게 무슨 기능을 할 수 있는지에 대한 엄격한 선언이 있었다면, 해당 방식에서는 다소 느슨하다고 할 수 있습니다. 전형적인 예인 prototype에서부터 시작하여 이를 확장하여 표현한다는 것이 일반적인 견해라고 할 수 있습니다. 따라서, 구현도 Factory에서 Prototype을 가지고 이를 Clone 하여서 instantiating을 수행하거나 이를 확장하여서 또 다른 object를 생성하는 Factory를 구현하는 식으로 확장해나갈 수 있습니다.

그렇기에 Prototype 방식에서는 clone이라는 method가 굉장히 중요합니다. (또한, 이 Prototype은 Singleton이라는 것도 아시겠지요?) 기존의 abstract factory 방식과는 다르게 Factory 자체에서 Prototype을 가지고 있는 것입니다. 그리고, 이를 이용해서 object를 생성한다고 볼 수 있습니다.

이 방식은 과거 해당 책이 나오기 전까지만 해도 다소 비주류로 (물론 지금도 주류는 아닙니다.) 여겨졌었지만, 이제는 immutable이라는 말도 계속해서 사용되고 있고, Modern Java, javascript 등 여러 언어에서도 이 pattern을 기본으로 받아들였습니다.

---

여기서는 어떨까요?

이 또한 factory에게 생성을 맡겼고, product 또한 이를 대표할 수 있는 전형적인 예 정도를 알고 있다고 볼 수 있습니다. 그렇기 때문에 우리는 productA, productB라는 object가 정확하게 무엇인지도 모르고, 이를 만드는 방법 또한 모르는 상태입니다.

### 5. Factory Method

![factoryMethod](/images/factoryMethod.jpeg)

이번에는 조금 다른 구현입니다. 이번에는 생성을 위한 대리자를 두지 않고, 다른 Product를 쓰고 싶다면, App 자체를 새로 작성하자는 흐름입니다. 이렇게 하게 되면, App 자체가 특정 Product와 의존성이 생기게 됩니다. 하지만, 정확하게 Product를 알고 있다는 것은 type 검사에 시간을 낭비하지 않을 수 있다는 뜻이고, 그로 인해 더 빠른 개발이 가능하다는 뜻으로 받아들일 수 있습니다.

이 방법론은 대게 개발 초기에 매우 많이 쓰인다고 합니다. 왜냐하면, 아직 어떤 Product까지 지원할지 모르지만 어느정도의 추상화를 통해서 해당 object가 가져야 할 최소한의 기능을 지정해놓고, 바로 특정 object에 대한 개발을 시작함으로써 해당 시스템의 검증을 빠르게 수행할 수 있는 것입니다. 그리고, 후에 maintain의 시간이 오면, code를 refactoring 하고 위에서 보았던 다른 design pattern을 검토하며 선택하는 시간을 가진다고 볼 수 있습니다.

해당 시스템에 대한 구현은 제 Github에 별도의 Branch를 통해서 구현해두었습니다. 언어는 typescript로 작성하였고, 참고할 수 있으면 좋겠습니다. :)

[🔗 GitHub](https://github.com/euidong/oop-design-pattern/tree/creational-pattern)

## Reference

- Design Patterns: Elements of reusable object oriented software.
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

[Design Pattern] 2. Creational Pattern

## Intro

점점 다양한 언어들이 생겨나고, 객체 지향에 대한 관심이 시들해지고 있는 환경이라고 생각합니다. 하지만, 그럼에도 불구하고, 여러 시스템에서도 거의 고유 명사로 쓰이고 있기에 객체 지향의 대표적인 디자인 패턴을 익혀두는 것은 필수적이라고 생각해서 제가 봤을 때 가장 빈번하게 사용되는 용어에 대해서 정리를 좀 해보고자 합니다.

해당 글에서는 일단 introduction에 대한 내용을 정리합니다.

## Design Pattern

software적으로 특정 상황에서 일반적인 문제를 해결하기 위해서 반복되어 사용되는 pattern을 말합니다. 이는 특정 문제를 해결하기 위한 algorithm이 아닌 이런 구조가 더 경험상 안정적인 구조를 이룰 수 있다는 template를 제공하는 것입니다.

이러한 pattern들은 4개의 요소를 가집니다.

1. **Pattern name** : pattern의 실제 이름을 의미합니다.
2. **Problem** : 언제 해당 pattern을 적용하는지를 표기합니다. 하나의 pattern으로 여러 문제를 해결할 수 있다면, 당연히 list 형태로도 표기합니다.
3. **Solution** : design을 이루는 요소들과 관계, 역할(책임)을 명시한다. 하나의 문제에 정확하게 대치되는 해결책을 보여주는 것이 아니라 구조를 파악할 수 있는 template를 제공합니다.
4. **Consequences** : 해당 pattern을 적용하게 되었을 때 얻게 되는 결과로, 대게 유연하게 확장이나 재사용을 할 수 있는지에 대한 관점에서 장점과 단점을 표기합니다.

이 책에서 말하는 design pattern들이 추가하는 가장 큰 목표는

Object Oriented Programming을 100% 활용할 수 있는 방법을 찾는 것입니다.

**이는 Maintainable 하기 위해서, 가독성이 높고 유연하며, 재사용이 좋은 system을 구축하기 위한 방법을 찾는 것이라는 말과 같습니다.**

이를 항상 머릿속에 두고, 이어 나갑시다.

### Example) MVC

design pattern에 대하여 이해를 돕기 위한 예시입니다. 만약, MVC 자체가 생소하다면, 넘어가는 것이 좋습니다.

가장 일반적으로 UI 작업을 하게 될 때 많이 사용되는 design pattern입니다. 이를 구성하는 Model / View / Controller의 앞 글자를 하나씩 가져와서 이를 지은 것입니다.

여기서, Model은 application의 data를 표현하는 객체입니다. 
View는 model을 user들에게 보여주는 방법을 정의한 객체입니다. 
Controller는 user input에 대하여 model 또는 view를 어떻게 변경할지를 정의한 객체입니다.

여기서, 흔히 사용되는 design pattern 3가지를 발견할 수 있습니다.

> **1. Observer pattern**

이는 model과 view를 분리하고, subscribe/notify 형태를 갖게 한 구조입니다.(view는 model의 변경이라는 event를 구독하고 있고, model은 자신이 변경되면, view에게 이를 알려서, view가 변경될 수 있도록 한다.)

이렇게 분리함으로써 얻는 효과는 우리는 하나의 model에 대해서 여러 개의 view를 가질 수 있다는 점이다. 또한, 새로운 view를 추가할 때에도 model을 변경하지 않아도 됨으로 쉽게 확장이 가능하다.

> **2. Composite pattern**

View는 중첩해서 사용이 가능하다. 즉, View안에 View를 중첩해서 쌓음으로써 재사용을 수행하는 것이다.

> **3. Strategy pattern**

View는 user input을 받는 장치(button) 등을 포함하고 있고, Controller instance를 포함하고 있기 때문에, 해당 instance를 교체함으로써 쉽게 동작을 변경하는 것도 가능하다.

### Type

해당 책에서는 총 23가지의 design pattern을 제시합니다. 그들을 분류하는 체계를 어느 정도 나눈다면 쉽게 이해가 가능할 겁니다.

> **1. Purpose**

실제로 해당 pattern이 하고자 하는 바를 나타냅니다. 총 3 가지의 목적으로 design pattern을 나눈 것이 가능합니다.

1. **Creational** : object의 생성 시에 특정 부분을 자식 class 또는 다른 object로 옮기는 방법을 제공합니다.
2. **Structural** : class 또는 object를 구조화하는 방법을 제공합니다.
3. **Behavioral** : class 또는 object가 특정 행동을 구현하기 위한 각 요소의 관계를 정의합니다.

> **2. Scope** : 구현이 기본적으로 class 단위인지, object 단위 인지를 나타냅니다.

1. **Class** : class들과 subclass들 간의 관계를 다루기 때문에, 상속에 의해서 정의되며, compile time에 고정되어서 바뀌지 않습니다.
2. **Object** : object들 간의 관계를 의미하며, run time에 유동적으로 바뀔 수 있습니다.

![design-pattern-category](/images/design-pattern-category.jpeg)

### Basic Skill

design pattern이 해결하기 위해서 사용하는 일반적인 기술들을 먼저 이해하면, 이를 조합해서 우리는 design pattern을 구성할 것이므로, 이 일반적인 기술부터 알아보고 가도록 합시다.

#### Object Oriented Programming

이 책의 가장 기본이 되는 객체 지향에 대한  내용입니다. 이를 읽고 아래를 읽으시는 것이 이해가 더 쉬울 것입니다. 이미 알고 있다면, 바로 다음부터 읽으시면 될 거 같습니다.

일반적으로 object oriented program에서 object란 data와 해당 데이터를 조작하는 여러 operation를 묶은 것을 말합니다. 이때, 우리는 해당 object 안의 data를 직접적으로는 접근할 수 없고, object에게 operation의 동작을 요청함으로써 output으로써 data를 얻거나 변경할 수 있습니다. 이를 우리는 encapsulated 되었다고 합니다.

object에 의해서 선언된 모든 operation은 이름과 input parameter, output value를 명시한 signature를 가집니다. 이러한 signature를 모아놓은 것을 해당 object의 interface라고 합니다. 따라서, interface에 있는 내용을 만족하는 request만이 object로 보내진 다고 할 수 있습니다. 여기서 중요한 것은 interface는 절대로 구현을 포함하지 않습니다. 단지 해당 operation에 대한 이름과 input, output을 알려줄 뿐입니다. 그렇기에 같은 이름이며, 들어가는 데이터, 나오는 데이터는 같지만 전혀 다른 구현을 가지도록 만들 수도 있는 것입니다. 이처럼 run time에 interface를 implementation 한 object 중에서 무엇을 실행시킬지를 선택할 수 있도록 하는 기술을 dynamic binding이라고 합니다. interface가 runtime에 정확하게 어떻게 동작할지 여러 형태를 가지는 것을 우리는 polymorphism이라고 합니다.

이 구조가 가지는 장점은 다음과 같습니다.

> **1. 대체 가능하다.**

"우리가 글을 쓰기 위해서는 반드시 연필이 필요하다."는 규칙을 정했다면,

우리는 샤프나 다른 볼펜이 있더라도 이 규칙에 어긋나므로 우리는 기존 규칙을 다시 바꾸거나 연필을 가져와야 할 것입니다.

하지만, 애초에 규칙을 "우리가 글을 쓰기 위해서는 반드시 검은색을 표시할 수 있는 도구가 필요하다."는 규칙을 정했다면, 더 유연한 규칙이 될 수 있습니다.

우리의 코드도 마찬가지로 interface를 통해서 검은색 글자를 쓰는 함수를 정의한 interface로 선언하고 이를 type으로 지정해둔다면, 이를 실행하는 object가 연필, 샤프, 볼펜 무엇이 되어도 되기 때문에 대체 가능한 구조를 가질 수 있는 것입니다.

> **2. 유연하다.**

위의 처럼 규현 할 수 있기 때문에 우리는 유연하게 구조를 만들 수 있습니다. 모든 관계가 느슨하게 연결된다고 SW 업계에서는 자주 표현합니다.

가능한 한 최소한의 기능만을 통해서만 대상을 정의한다면, 더욱더 유연한 구조가 된다고 할 수 있습니다.

> **3. 가독성이 좋다.**

우리는 해당 object를 사용할 때 이것이 어떻게 돌아가는지 모르더라도 사용할 수 있기를 바랍니다. 스마트폰을 가동시키기 위해서 이것의 부팅 절차와 여러 algorithm을 이해하는 것은 우리가 문자를 보내는 과정에서 불필요한 내용입니다. 따라서, 우리는 최대한 최소한의 내용만을 알면 됩니다. 가령 "오른쪽  전원 버튼을 누르면(input) 화면이 켜진다(output)"는 이러한 내용입니다. 이는 우리가 더 복잡한 문자 메시지 보내기를 쉽게 할 수 있는 토대를 제공합니다.

> **4. 문서화가 용이하다.**

이제 우리가 시스템을 판매하거나 이를 통해서 같이 일해야 하는 경우가 생긴다면, 이에 대한 설명서가 필요합니다. 만약, 여러 방식으로 구현을 해두었다면, 통일성 있는 문서를 기대할 수는 없습니다. 하지만, interface를 통해서 구현했다면, 이 interface가 요구하는 동작만을 정확하게 적어둔다면, 쉽게 이해할 수 있고 구조화된 문서를 만들기가 용이합니다.

그렇다면, 실제로 programming에서 이 interface와 object를 구현하는지를 살펴보아야 합니다.

대게의 언어에서는 interface, abstract class라는 것을 포함합니다. 이들을 각 각 이들을 구현 또는 상속할 대상들이 반드시 가져야 할 요소(name, input parameter, return value)에 대한 내용을 기술합니다.

그러면 우리는 class를 통해서 이에 대한 구현을 수행합니다. 따라서, 우리는 하나의 interface에 대하여 여러 개의 구현을 가지게 됩니다. (이를 구현을 defer(미루었다)고 표현합니다.) 그리고, 이제 실제로 만들어지는 object들을 우리는 class를 instantiating(틀을 기반으로 복사)하여 생성하는데 이때 만들어진 대상을 우리는 특별히 instance라고 합니다.

또한, class를 선언한다는 것은 우리에게 두 가지 효과를 불러옵니다. class라는 instantiating 하기 위한 틀을 만들 뿐만 아니라 type을 생성합니다. 즉 우리가 일반적으로 instance를 만들기 위해서 다음과 같은 과정을 거치게 될 때 앞에 있는 Class는 class의 type을 의미하는 것이고, 뒤에 있는 것은 instance를 만들기 위한 틀을 의미합니다.

```c++
SimpleClass sc = new SimpleClass();
```

그렇습니다. 만약 우리가 class를 interface의 구현으로 만든 것이 아니라면, interface type을 만들면서, class 틀까지 같이 만든 것으로 이해할 수 있는 것입니다. 하지만, interface와 다른 점이라면, 이를 상속하게 되면, 이 안의 구현도 같이 subclass로 전달된다는 점이 있겠습니다. 따라서, 우리가 더 유연한 시스템을 만들고자 한다면, 당연히 일반 class를 통해서 만들어지는 type를 사용하기보다는 abstract class 또는 interface를 통해서 만들어지는 type을 활용하는 것이 더 유연하고, reusable 한 구조를 만드는 핵심이 될 수 있습니다.

마지막으로 다룰 내용은 class의 구성 방식입니다.

만약, 특정 시스템이 무언가를 구현한다고 했을 때, "A는 B다"를 통해서 구현하는 것이 좋을까 아니면, "A는 B를 갖고 있다"를 통해서 구현하는 것이 좋을 가입니다.

일반적으로 우리는 상속을 통해서 표현되는 관계를 "inheritance" 또는 "is a" 관계라고 합니다. 즉, A가 B라는 클래스를 상속한다면, A는 B이다.라고 말할 수 있습니다. 왜냐하면, B를 상속하는 A는 당연히 B의 하위 관계이기 때문입니다. (ex. 코끼리는 동물이다.) 하지만, 상속이 아닌 변수로서 이를 포함할 때 우리는 이를 "composition" 또는 ("has" or "use") 관계라고 합니다. 즉, A가 B를 갖고 있다로 보는 것입니다. (ex. 코끼리는 동물의 속성을 가진다.)

이 중에서 어떤 식으로 구현하는 것이 유연한 구조를 만들 수 있을지는 자명합니다. 당연히 composition입니다.

이를 알아보기 위해서 구현이 바뀌는 예시를 들어봅시다.

- 만약, 코끼리 중에서 코가 짧은 개체가 발견되어 더 이상 코끼리는 코가 크다는 속성을 쓸 수 없는 경우
 - inheritance, composition : 둘 다 구현부에서 쉽게 변경이 가능합니다.
- 코끼리 중에서 외계에 존재하는 종이 발견되어 외계종의 특징을 추가해야 하는 경우
 - inheritance : 외계 생명체라는 interface를 추가로 상속합니다. 하지만, 이 과정에서 충돌되는 속성들(ex. 겹치는 operation 이름, 서로 반대되는 성질) 등에 의해서 최악의 경우 interface를 수정해야 할 수도 있습니다. 그렇게 되는 경우 이 interface를 구현한 모든 class들 역시 변경이 필요합니다
 - composition: 해당 외계 생명체라는 속성을 가져와서 필요로 하는 속성만을 확인하고 구현합니다.
- 코끼리라는 식물이 새로 발견된 경우 => 모두 크게 변경해야 함.
 - inheritance : 상속을 식물로 변경하고, 식물의 속성에 구현된 것을 새로 정의합니다.
 - composition : 가지고 있던 변수를 식물로 변경하고, 변수에 의존성이 있던 부분을 직접 바꾸어 구현합니다.

따라서, 대개의 경우 상속은 interface를 직접적으로 구현할 때에만 사용하고, 그 외에 경우에 composition을 통해서 의존성을 형성하는 것을 선호합니다.

composition은 해당 관계가 run-time에 생성되는가 아니면, compile-time에 생성되는가에 따라서 두 개로 나뉠 수 있습니다.

만약, class 내부에서 해당 변수를 생성 시부터 소멸 시까지 갖고 있는다면, 이는 aggregation(have)로 볼 수 있습니다. (즉, compile time에 관계가 형성됩니다.) 그렇지 않고, run time에 생성되어 잠깐 사용되는 정도의 관계라면, 이는 acquaintance(use) 관계로 봅니다.

#### Finding Appropriate Objects

우리가 해결하고자 하는 문제를 위해서 어느 정도까지의 object들이 필요하고, 이를 어떻게 정의할 것인지를 결정하는 것을 도와줄 수도 있습니다.(Composite, Strategy,...)

#### Determining Object Granuality

Object를 무엇으로 결정했다면, 당연히 이 Object의 크기를 어느 정도로 할지에 대한 내용도 필요하게 될 것입니다. 이를 정의하는 design pattern(Facade, FlyWeight,...)도 존재합니다.

#### Specifying Object Interfaces

무엇을 interface에 추가해야 하는지 아니면 포함시켜서는 안 되는지에 대한 내용을 서술한 design pattern(Memento), interface 간의 관계를 표현하는 것(Decorator, Proxy)도 있습니다.

#### Delegation

delegation은 자신의 operation의 구현을 composition 한 instance에게 맡기는 방식입니다.

![delegation](/images/delegation.jpeg)

보는 바와 같이 자신의 Area라는 함수의 실행을 Rectangle의 Area 함수로 대체함으로써 더 유연한 구조를 만들 수 있습니다. 만약에 Window가 Circle로 바뀐다면 간단히 Circle의 instance를 생성해서 이 instance의 Area를 호출하도록 하면 될 것입니다.

이는 굉장히 유용하고, 유연한 개발이 가능하지만, 다른 instance의 요소를 실행시키니 만큼 run-time 중에 비효율적인 동작을 막을 수는 없습니다. 따라서, 이를 유의하고 사용해야 합니다.

실제로도 State, Strategy pattern에서도 사용됩니다.

## Reference

- Design Patterns: Elements of reusable object oriented software.
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

[Design Pattern] 1. Intro

S6 Overlay


## Intro

여태까지 docker의 driver를 통한 networking 기술을 알아보았고, 이제 libnetwork로 1/3에서 제시했던 기본 routing과 같은 기능 외에 구현되어 있는 기능들에 대해서 알아봅니다.

- service discovery
- load balancing

## Service discovery

모든 container들과 swarm의 서비스들이 이름을 통해서 각 각을 찾을 수 있도록 하는 것이다. Docker는 자체적으로 내부의 DNS 서버를 이용하여 이를 수행한다. 과정을 요약하자면 다음과 같다.

1. container가 이름을 통해서 특정 container를 찾아야 함을 인식한다.
2. 먼저 Local 내부에서 이에 대한 정보를 갖고 있는지를 탐색한다. -> 있다면, 종료
3. Docker DNS server에 이를 요청하는 query를 전송한다.
4. Docker DNS server는 모든 container의 name과 network alias(별칭)를 알기 때문에 이를 찾을 수 있다.
5. 이때, DNS server는 먼저 동일한 network에 해당 container가 존재하는지를 확인한다. -> 없다면, 외부 DNS server로
6. 존재한다면, 이를 요청을 보낸 resolver에게 전달하고, 이게 다시 container로 전달된다.

## Load balancing

docker swarm은 기본적인 load balancer를 지원하여, 아래 그림과 같이 구현되어진다.

```bash
$ docker service create \
  --name my-web \
  --publish published=8080,target=80 \
  --replicas 2 \
  nginx
```

![docker-ingress-network](/images/docker-ingress-network.png)

즉, 어디로 요청을 보낸다고, 할지라도 load balancer는 어디에 해당 서비스가 존재하는지를 파악하고, 이를 전달하는 것이 가능해진다. 따라서, 어느 노드로 요청을 보내더라도 정상적으로 요청이 전달될 수 있는 것이다. 이를 Ingress load balancing이라고 부른다.

만약, 특정 node로 전달된 요청은 해당 node에 있는 container로 전달되기를 바란다면, host모드를 이용하여 진행할 수도 있다.

여기까지가 network에 대한 전반적이 내용입니다.

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton


[Docker] Network(3)


## Intro

저번 글에 이어서 이번에는 docker network의 driver들에 대한 자세한 내용을 다루겠다.

- bridge networks
- overlay networks
- host networking
- IPVlan networks
- MacVlan networks

## Bridge Network

container간의 통신을 위해서 필요한 것이 bridge 네트워크이다. 하지만, 여기서 주의해야할 것은 오직, single host에서만 동작한다는 점이다. 즉, 다른 docker host에 존재하는 container와는 연결이 불가능하다.

그렇다면, bridge가 무엇인가? 이는 두 개의 network 장치를 연결하는 L2 switch를 말한다. 즉, container를 연결하는 도구라고 보면 되겠다. 이를 통해서 연결된 container는 해당 container의 모든 port에 접근이 가능해진다.

![docker-bridge-network](/images/docker-bridge-network.png)

위는 `$ docker network ls`를 입력하면 기본적으로 볼 수 있는 내용이다. 위에 세개는 처음부터 끝까지 docker에 존재하는 default network입니다. host는 직접적으로 host에 연결하는 경우의 network이고,(후에 설명합니다.) none은 아무 네트워크에도 연결되지 않아 외부로 어떤 traffic도 보내지 않을 container들이 속하게 된다. 여기서 bridge는 default bridge라고 불리며, network를 설정하지 않고, container를 생성하게 되면 기본적으로 해당 bridge로 연결되게 된다. 이를 통해서 container 간의 연결도 구현하는 것이 가능하다.

하지만, 일반적으로 단일 기기에서 container 간의 연결을 수행할 때에는 bridge를 직접 생성하여 연결하는 것이 일반적이다. (그 이유는 도메인 네임 설정을 자동으로 해준다는 점에서 이점이 있기 때문 -> [🔗 참고](https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge))

아래는 이를 이용한 간단한 예시이다.

```bash
# bridge 생성
$ docker network create -d bridge eui_bridge

# container 생성
$ docker container run -d --name c1 \
  -network eui_bridge \
  alpine sleep 1d
  
# container2 생성
$ docker container run -it --name c2 \
  -network eui_bridge \
  alpine sh
   
# ping을 통해 c1과 연결 여부 확인
$ ping c1
```

위의 과정을 처음부터 설명하자면,

1. eui\_bridge라는 network를 bridge로 생성한다.
2. container에 eui\_bridge를 연결하고, alpine 이미지를 기반으로 생성한다. 이때 시작 시에 sleep을 하루 동안 시행한다.(sleep 하는 이유는 꺼지지 않게 하기 위함)
3. 마찬가지로 eui\_bridge에 연결하고, alpine 이미지로 container를 생성한 후에 shell을 실행시킨다.
4. c2에서 실행된 shell에서 c1으로 ping을 전송한다. (이때 같은 network bridge끼리는 container name으로 domain이 생성된다.)

참고로 여기서 기억해야할 것이 있다면, bridge는 container간의 연결을 위한 것이고, container의 특정 port를 host와 mapping하고자 할 때에는 `--publish` 를 활용해야 한다.

```bash
$ docker run -p 5000:80 nginx
```

이를 통해서 host의 5000번과 container의 80번 port를 연결할 수 있다.

## Overlay Network

위에서 설명한 것이 단일 호스트 내부에서 container 간의 연결이었다면, 여러 host가 존재하는 cluster 환경에서 docker의 container간 통신을 위한 driver가 overlay이다. 현재에는 docker swarm을 통해서 application을 여러 host에서 제공하는 경우에 사용하게 된다.

먼저 원리를 알아보자면, VXLAN을 활용한다는 것이다. 이는 L3 network 상위에서 다른 두 기기 간에 L2 통신을 지원하는 것인데, 이를 통해서 우리는 다른 node간에 존재하는 container 끼리도 통신할 수 있도록 할 수 있다. docker swarm에 의해서 관리되어 L3로 연결된 두 node의 위에서는 VXLAN Tunnel EndPoint(VTEP)이 각 각 존재한다. 이들을 통해서, tunnel이 형성되고 통신이 가능해지는데, 기존에 container에 존재하고 있던 CNM에서 정의한 Sandbox 속에 virtual switch가 생성되고 이와 VTEP이 연결되어 다른 기기에 있는 container간에도 통신이 가능해지는 것이다.

예시를 든다면, docker stack을 통해서 시스템을 구성해본 적이 있다면, container를 생성하는 과정에서 network가 먼저 생성되는 것을 확인할 수 있을 것이다. 이때 생성되는 것이 overlay 네트워크로 이를 통해서 여러 container가 replica가 어느 node에 생길지 확정할 수 없음에도 통신을 자유롭게 하는 것을 볼 수 있다.

## Host Networking

해당 방식은 docker를 한 번이라도 써본 사람이라면 다음 명령어는 익숙할 것이다.

```bash
$ docker run -p 80:80 nginx
```

nginx image를 기반으로 container를 실행시키고, container 내부의 80번과 host의 80번 port를 mapping하겠다는 것이다. 이를 통해서 container는 host의 network에 관여하는 것이 가능하다.

하지만, host networking을 이용하게 되면 container 내부에 network stack이 생성되지 않고, 해당 container의 모든 network 설정이 해당 host의 설정에 그대로 mapping되는 것이다. 이를 이용하면 성능상의 이점은 있겠지만, 상당히 설정이 난잡해질 수 있다.

## IPVlan Network

MAC address와 IP adress를 부여하여, 실제 네트워크에 container를 직접 연결하는 방식이다.

장점은 별도의 port forwarding이나 bridge를 사용하지 않으므로 당연히 빠르지만, NIC를 이용하기에 promiscuous mode를 open해야 한다는 단점이 있다. 이는 switch가 데이터를 전송할 대상을 찾지 않고, 연결된 모든 대상에게 보내는 모드로, sniffing에 취약하고 이 때문에 public cloud system에서는 이를 막아 놓기에 사용할 수 없다.

![docker-ip-vlan](/images/docker-ip-vlan.png)
여기까지 말했을 때, 이해했다면, 이미 설정하는 것을 알아보러 떠나면 될 것이고, 이해하지 못했다면, 아마 쓸 일이 없을 것이니 넘어가시면 될 것이다.

자세한 사항은 공식 페이지를 참고하자.

[🔗 IPvlan networks](https://docs.docker.com/network/ipvlan/)

## MacVlan Network

ipvlan과 동일하지만 차이점은 MAC 주소를 할당한다는 점이다. 그 외에는 다를 것이 없다.

[🔗 macvlan networks](https://docs.docker.com/network/macvlan/)

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton


[Docker] Network(2)


## Intro

Docker Swarm을 docker stack을 이용하여 실행시키게 된다면, 무엇이 생성되는가? 우리는 서비스가 생성되기도 전에 network가 생성되는 것을 볼 수가 있다. container와 container간 그리고, host를 통해 외부 internet환경에 container를 연결 시키는 모든 과정을 알아보자.

Docker를 사용하다보면, host와 통신을 위해 외부로 port를 열어주는 것과 container 간의 통신을 헷갈려 하는 사람들이 생각보다 많은 것 같다. 심지어는 container간 통신을 위해서 localhost로 정보를 주고받을려고 하는 몹쓸 시도를 하는 관경도 몇몇 봐왔다.

따라서, 우리는 한 번 Docker의 network에 대해서 한 번 공부해보는 것이 좋을 것이다.

해당 차시에서는 우선 전체적인 docker network를 설명하는 기본적인 키워드를 알아볼 것이고,

2 차시에서는 주로 사용되는 docker network driver를 알아볼 것이고,

3 차시에서는 libnetwork의 핵심 기능 중 service discovery, load balancing에 대해서 알아보겠다.

## Docker Networking Base

우리가 기억해야 할 것은 CNM, libnetwork, Driver 이렇게 3가지다. 각 각이 무엇인지는 차례차례 알아보자.

### Container Network Model (CNM)

container간의 network를 구현하기 위한 design을 제시한 내용입니다. 따라서, idea일 뿐입니다. 자세한 내용은 하위 링크를 통해서 확인 가능합니다.

[🔗 Github - moby/libnetwork](https://github.com/moby/libnetwork/blob/master/docs/design.md)

하지만, 이를 좀 더 요약해봅시다. 일단 핵심 요소 3가지를 먼저 이해해봅시다.

- **Sandbox** : 고립된 하나의 Network 공간을 의미합니다. 해당 공간에는 ehternet interface나 port 그리고 routing table같은 구현이 포함됩니다.
- **Endpoints** : Virtual Network를 서로 연결하는 interface의 역할입니다. (veth라고도 불립니다.) CNM에서는 Sandbox 내부에서 이와 Network를 연결하는 역할을 합니다.
- **Networks** : Virtual Switch로 여기면 됩니다. 이를 통해서 여러 개의 endpoints를 연결할 수 있습니다.

자 이제 이렇게 3개의 네트워크를 정리하면, 이제 Container 내부에 Sandbox가 존재하고, 그 Sandbox 내부의 endpoints를 연결하는 Network를 통해서 결론적으로 Container 간의 연결을 수행하게 됩니다.

![cnm](/images/cnm.jpeg)

### libnetwork

위에서 이야기한 것처럼 CNM은 단순히 idea일 뿐입니다. 이를 구현허여 표준화된 것이 바로 libnetwork라고 생각하면 됩니다. 이는 Go를 이용하여 작성된 open source로 위에서 제시한 링크를 통해서 해당 open source에 접근할 수 있습니다. 위에서 언급한 CNM을 구현하였고, 추가적으로 service discovery, ingress-based container load balancing, network control plane 및 management plane 기능을 구현하였다. 현재에는 docker에서 network 구현에 사용된다.

\* control & management plane : 직접적으로 network의 흐름을 제어하는 단계로, routing과 같은 제어를 수행한다.

### Drivers

즉, libnetwork가 전체적인 network의 control plane과 management plane 기능을 구현하였다면, driver는 data plane을 구현한다. 즉, 직접적으로 데이터를 전달하는 역할을 수행한다. 이러한 기능들은 docker에서 여러 개의 driver라는 submodule을 통해서 구현하였다. docker pub를 통해서 default보다 나아간 driver 역시 설치가 가능하다. 하지만 기본적으로, host, bridge, overlay, ipvlan, macvlan 등을 포함하고 있다.

여기까지가 docker network에 대한 overview이다. 다음 차시에 계속...

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton
- Tumbnail : Photo by [Michael](https://unsplash.com/@michael75?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/cargo-ships?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


[Docker] Network(1)


## Intro

해당 글은 Linux에서 docker를 동작시킨다는 가정하에 작성하였다. (Window도 대부분 동일하다고 한다.)

docker는 여러 개의 보안 정책을 포함한다.

이를 크게 누가 관리하느냐에 따라서 두 개의 부류로 나눌 수 있다.

1. OS system (Linux)
2. Docker

이전 가상화와 반가상화를 비교한 글에서 보았듯이 Container 기술을 결과적으로 반가상화에 해당하며, 이를 위해서 OS의 지원이 필요하다. 따라서, 이를 Linux 자체에서 구현해주는 것이 존재하고, Docker에서 Application 단에서 구현한 부분으로 나뉘어지는 것이다.

먼저, Linux에서 지원하는 각종 security에 대해서 알아봅시다.

## Linux's Security for Docker

전체적인 디테일 사항은 정리하지 않는다. 해당 내용은 간단히 살펴보는 정도이다.

### Namespaces

namespace는 container 기술에서 매우 핵심적인 위치에 존재한다고 할 수 있다. 이를 통해서, OS를 여러 개로 나누고, 마치 완전히 고립된 형태의 OS처럼 느끼도록 만든다. (키워드는 isolation) 그렇다면 하나의 host 내에서 어떻게 여러 개의 container가 완벽하게 독립되어 있다고 느낄 수 있게 할 수 있을까? 이는 다음과 같은 종류의 namespace를 분리함으로서 가능하다.

- **process ID (pid)** : process는 tree 형태로 이루어지게 된다. 따라서, 하나의 process (즉, PID 1)에 의해서 여러 개의 process가 동작을 시작하는 것이다. 그런데, namespace를 통해서 우리는 여러 개의 완벽하게 독립적인 process tree를 구축하게 된다.
- **Network (net)** : 각 각의 container마다 network stack을 구현한다. 즉, network interface 부터 시작해서, IP Address, port, routing table 등을 구축하게 되는 것이다.
- **Filesystem / mount (mnt)** :모든 container가 각자의 root filesystem을 가지고, 다른 모든 container들은 이것에 접근할 수 없다.
- **Inter process Communication(ipc)** : process간의 통신을 위해서 우리는 shared memory를 사용하게 되는데 이 또한 고립적으로 구현되도록 한다.
- **User** : 각 container마다 다른 user group을 구축하고 사용할 수 있도록 한다.
- **Unix Time sharing (uts)** : hostname을 container마다 제공하는 것으로, 이를 통해서 network 상에서 ip가 아닌 hostname으로 접근하는 것이 가능해진다.

즉, 해당 절에서는 이 한 마디를 기억하면 편해집니다. "하나의 Docker의 container는 namespace들의 집합으로 이루어져있다."

### Control Groups(C group)

namespace가 각 container간의 isolation을 보장한다면, cgroup은 한계를 설정하는 것이 역할이다. container들이 하나의 machine에서 동작한다면 어쩔 수 없이 그들이 사용할 수 있는 총 자원의 양은 한정될 수 밖에 없다. 그리고, 자칫 잘못하면 하나의 container가 너무 많은 자원(CPU, Memory, Storage, ...)을 소모하여 다른 container의 동작을 방해할 수 있다. 이를 막기 위한 것이 바로 cgroup이다. 이를 통해서 우리는 각 container에게 자원을 나누어 할당하는 것이 가능하다.

### Capabilities

어떤 작업을 하더라도, Machine을 root 권한으로 작업을 하는 것은 굉장히 위험하다. 따라서, container에서 application을 동작시키기 위한 최소한의 권한만을 부여하여 사용하는 것이 올바르다. 이를 수행할 수 있도록, 권한을 지정하는 것이 가능하다.

### Mandatory Access Control(MAC) system

MAC은 파일이나 특정 데이터에 대한 접근 제어를 수행하는 것을 의미한데, 이는 AppArmor나 SELinux 등에 의해서 구현되어지는데, 기본적으로 Docker는 container에 AppArmor를 각 container에 적용하여 이를 구현한다. customizing이 가능하지만, 이에 대한 이해를 충분히 하기를 권한다.

### seccomp

seccomp의 filter mode를 활용하면, container에서 발생하는 syscall을 제한하는 것이 가능하다. 이는 MAC 처럼 직접 customizing도 가능하지만 이에 대한 깊은 이해가 뒷받침되어야 한다.

## Docker Engine's Security for Docker

### Secure Swarm Mode

기본적으로 Docker Swarm은 manager와 worker로 구분되어 동작한다. manager는 기본적으로 control plane을 제어하고, 전체 적인 cluster 환경을 구성하며, 작업을 적절하게 전달한다. 그리고, 전체적인 application code를 동작시키는 것이 worker들이 수행하는 역할이다. 기본적으로 manager와 worker들은 모두 다른 Node이다. 따라서, 이들간의 통신을 수행할 때에 인증과 같은 작업을 필수적이다. 따라서, Docker Swarm에서는 이를 지원하기 위해서 manager로 임명된 node를 CA로 하여 TLS 인증을 수행한다. 이를 통해서, 서로를 인증하고, 전송 데이터 암호화를 수행한다.  
  
\* control plane vs data plane : 통신을 일상에서의 교통흐름이라고 본다면, control plane은 신호등과 같은 규칙을 의미하고, data plane은 실제로 이동하는 차량들로 비유할 수 있다. 즉, control plane은 cluster 환경에서의 제어를 위한 데이터이고, data plane은 실제로 주고 받는 데이터라고 볼 수 있다.

### Image Scanning

Docker는 이미지에서 보안상의 취약점 여부를 scan하는 기능을 기본적으로 탑재하고 있다. 이를 통해서, 이미지가 가진 취약점 등을 파악하는 것이 가능하다.

### Docker Content Trust

Docker는 download 또는 실행할 이미지의 제공자를 식별하고 무결성을 쉽게 체크할 수 있도록 하기 위해서 Docker Content Trust를 제공한다. registry에 이미지를 업로드할 때, 직접 서명이 가능하고, 이를 통해서 특정 사용자에 의해서 생성되었음을 확정할 수 있다. 이렇게 서명이 존재해야만 pull이 가능하도록 설정하는 것 역시 가능하다.

### Docker Secrets

Docker에서 보안 정보를 안전하게 보관하기 위해서 고안된 것으로, 특정 타겟에서 안전하게 SSH key와 같은 정보를 안전하게 전달하는 것 이 가능합니다.

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton


[Docker] Security


## Intro

Virtual Machine과 Container는 현재의 여러 Computing 영역에서 빼놓을 수 없는 내용이 되었다. 그렇기에 이들의 발전 역사를 기반으로 하여 이들을 비교하고 정리해보도록 하겠다.

## History

Virtual Machine과 Container의 차이점을 이해하기 보다는 서사를 이해하는 것이 편할 것이다.

시작은 다음과 같다.

당신은 현재 다양한 service를 운영하고 있다. 그리고, 이를 운영하는 과정에서 가장 큰 문제를 겪게 된다.

여러 service는 매 번 다양한 요구에 의해서 상황이 바뀐다. 어느 날은 주문이 폭주해서 서버를 증설해야하고, 어느 순간에는 유지 비용이 아까워서 서버를 다시 축소시킨다.

또한, Hardware가 성능의 노후와 새로운 기기 및 시스템을 도입하고자 하는 욕구도 따른다.

> **Service 1, Service 3의 비용이 증가하면 Service 3이 영향을 받는다.**

![vm-container-1](/images/vm-container-1.jpeg)

이 과정에서 우리는 결국 하나의 machine에 하나의 service 만을 배포하게 된다. 다른 service가 과부화가 걸려서 다른 service도 같이 에러가 발생한다면, 얼마나 머리가 아프겠는가? 그런데, 여기서 공학자들이 참을 수 없는 일이 발생하는 것이다.

> **"비효율적" 자원 사용**

그래서 사람들은 선택에 기로에 빠진다. 머리가 아플정도로 고민해서, 최적의 상황을 만들어서 우리의 server를 예쁘게 만들고, 새로운 service가 나오고 기기가 추가될 때마다 이 고민을 반복하는가 아니면 그냥 하나의 machine에는 하나의 service만 넣는가?

이때, 사람들은 하나의 물리적 기기를 여러 개의 작은 기기로 나누는 것에 눈을 돌리게 된다.

그때, 떠오른 발상이 Virtual Machine이다. 물리적으로 존재하는 Machine을 이용해서 가상의 Machine을 만드는 것이다. 즉, 하나의 Machine이 이제 여러 개의 Virtual Machine이 될 수 있는 것이다.

이 발견을 통해서 사람들은 하나의 server를 여러 개의 virtual Machine으로 나누고 관리하는 것에 익숙해지며, Virtual Machine을 주류로 하는 VMware와 같은 업체가 큰 성장을 이루게 된다.

그러나, 여기서 Virtual Machine의 사용자들은 큰 고민을 갖게 된다. 바로 성능적인 Issue이다.

기존에는 Virtual Machine을 완벽하게 동작하는 OS 위에서 동작하도록 하였다. 하지만, 시간이 갈 수록 이러한 구조는 오히려 큰 비용을 유발했다.

이에 따라서 다양한 가상화 방법들이 연구되게 된다. 그렇게 나온 것이 지금까지는 3가지의 큰 흐름으로 이해할 수 있다.

![vm-container-2](/images/vm-container-2.jpeg)

> **1. Host 기반의 가상화**

우리가 앞서 봤던 사례들과 같이 기존에 Host가 존재하고, 거기에서 Virutalize SW를 이용하여, 가상화된 장치를 만들어서 사용하는 방식이다.

> **2. Hypervisor 기반의 가상화**

Host Machine을 배제하고, Host의 OS를 없애고, Hypervisor를 기반으로 여러 OS를 능동적으로 처리할 수 있는 형태로 구성한 것이다.

- 종류
  - 전가상화 : 전가상화란 전체 Hardware를 모두 가상화하는 방식으로 Hypervisor가 각 OS로 부터 오는 요청을 모두 사용하는 Hardware에 맞게 번역하는 기능을 수행한다.
  - 반가상화 : OS에서 자신의 명령어를 표준화된 형태로 전달합니다. 이를 수행하게 되면, Hypervisor에서 수행하는 동작의 비용을 크게 줄일 수 있습니다. 하지만, 이 경우에는 OS 자체를 수정해야 하기 때문에 큰 비용이 발생합니다.

> **3. Container 기반의 가상화**

Container 는 guest OS를 구현하지 않습니다. 각 Container에서 발생하는 OS 요청을 Host OS를 공유함으로서 수행합니다. 추가적인 기능은 Container 내부로 위임하여 훨씬 더 가볍고 이식성이 좋은 형태의 가상화가 가능합니다.

## Simulator vs Emulator

여러가지 이야기가 simulator와 emulator 사이에서 존재한다. 예를들어, high level로 작성하는 것이 simulator고 low level로 작성하는 것이 emulator라는 이런 말이다. 하지만, 이는 각 경우를 구현하는 과정에서 발생하는 특징이지 정의가 되지는 않는다.

Simulator는 특정 목적에 따라 기능을 수행할 수 있도록 임의로 구현하는 것을 의미한다. 즉, 완벽하게 동일할 필요는 없이 원하는 특징을 뽑아내는 것이 중요한 것이다. 반면에, Emulator는 완전 동일한 기기를 software로 구현하는 것을 말한다. 그 과정에서 Emulator는 Smulator보다 무거워질 수 밖에 없고, 그렇기에 low level language에 손이 가게 되고, 느려지게 된다.

이해가 어렵다면, 오락실 게임을 PC에서 하고, 동물의 숲 닌텐도 게임을 핸드폰으로 하는 불법적인 일도 해본 적이 있을 수 있다. 이는 가상으로 해당 기기를 구현하고, 이를 다른 기기에서 구동하는 것의 예이다.

## Reference

- [🔗 가상화 각 각을 비교](https://tech.cloud.nongshim.co.kr/2018/09/18/%EA%B0%80%EC%83%81%ED%99%94%EC%9D%98-%EC%A2%85%EB%A5%983%EA%B0%80%EC%A7%80/)
- Thumbnail: Photo by [william william](https://unsplash.com/@william07?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/cargo-ship?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
