구름을 채우다

파이썬 클린 코드 (5/10)

최성훈 — Mon, 16 Jan 2023 00:09:29 +0900

5장. 데코레이터를 사용한 코드 개선

파이썬의 데코레이터

@modifier
def original(...):
	# ...

데코레이터는 데코레이터 이후에 나오는 것을 데코레이터의 첫 번째 파라미터로 하고 데코레이터의 결과 값을 반환하게 하는 문법적 설탕(syntax sugar)일 뿐이다.

... 예제에서 말하는 modifier는 파이썬 용어로 데코레이터라 하고, original을 데코레이팅된(decorated) 함수 또는 래핑된(wrapped) 객체라 한다.

함수 데코레이터

함수에 데코레이터를 사용하면 어떤 종류의 로직이라도 적용할 수 있다. 파라미터의 유효성을 검사하거나 사전조건을 검사하거나, 기능 전체를 새롭게 정의할 수도 있고, 서명을 변경할 수도 있고, 원래 함수의 결과를 캐시하는 등의 작업을 모두 할 수 있다.

class ControlledException(Exception):
    """도메인에서 발생하는 일반적인 예외"""


def retry(operation):
    @wraps(operation)
    def wrapped(*args, **kwargs):
    	last_raised = None
        RETRIES_LIMIT = 3
        for _ in range(RETRIES_LIMIT):  # 무시해도 되는 값은 '_'로 표현
            try:
                return operation(*args, **kwargs)
            except ControlledException as e:
                logger.info("retrying %s", operation.__qualname__)
                last_raised = e
        raise last_raised
    return wrapped

위에서 작성한 데코레이터는 파라미터가 없으므로 어떤 함수에도 적용이 가능하다.

@retry
def run_operation(task):
	"""실행 중 예외가 발생할 것으로 예상되는 특정 작업을 실행"""
    return task.run()

여기서 @retry 데코레이터는 실제로 파이썬에서 run_operation = retry(run_operation)과 동일하게 실행하게 해준다.

즉, run_operation() 함수가 실제로 실행되기 전 @retry 데코레이터의 로직이 실행되고, @retry 데코레이터의 파라미터로 run_operation() 함수가 넘어가는 것이다.

클래스 데코레이터

함수에 적용한 것처럼 클래스에도 데코레이터를 사용할 수 있다. (PEP-3129). 유일한 차이점은 데코레이터 함수의 파라미터로 함수가 아닌 클래스를 받는다는 것이다.

어떤 개발자들은 클래스 데코레이터가 복잡하고 가독성을 떨어뜨릴 수 있다고 말할 수 있다. 왜냐하면 클래스에서 정의한 속성과 메서드를 데코레이터 안에서 완전히 다른 용도로 변경할 수 있기 때문이다.

데코레이터를 남용할 경우 이것 또한 사실이다. 파이썬에서 보면 함수 데코레이터와 클래스 데코레이터는 다른 타입을 사용하는 것만 다를 뿐 차이점이 없다.

클래스 데코레이터는 코드 재사용과 DRY 원칙의 모든 이점을 공유한다. 클래스 데코레이터를 사용하면 여러 클래스가 특정 인터페이스나 기준을 따르도록 강제할 수 있다. 여러 클래스에 적용할 검사를 데코레이터에서 한 번만 하면 된다.
당장은 작고 간단한 클래스를 생성하고 나중에 데코레이터로 기능을 보강할 수 있다.
어떤 클래스에 대해서는 유지보수 시 데코레이터를 사용해 기존 로직을 훨씬 쉽게 변경할 수 있다. 메타클래스와 같은 방법을 사용해 보다 복잡하게 만드는 것은 주로 권장되지 않는다.

나는 데코레이터가 DRY 원칙의 모든 이점을 공유한다는 점과, 가독성을 떨어뜨릴 수도 있다는 점에 모두 동의한다.

게다가 데코레이터의 목적에 맞게 정확하게 사용하지 않으면 래핑된 객체(또는 함수)는 기존의 동작과 다르게 의도치 않게 동작할 수도 있으므로, 주의해서 사용하는 게 좋다.

class LoginEventSerializer:
    def __init__(self, event):
        self.event = event

    def serialize(self) -> dict:
        return {
            "username": self.event.username,
            "password": "**민감한 정보 삭제**",
            "ip": self.event.ip,
            "timestamp": self.event.timestamp.strftime("%Y-%m-%d %H:%M"),
        }


class LoginEvent:
    SERIALIZER = LoginEventSerializer

    def __init__(self, username, password, ip, timestamp):
        self.username = username
        self.password = password
        self.ip = ip
        self.timestamp = timestamp

        def serialize(self) -> dict:
            return self.SERIALIZER(self).serialize()

위 LoginEventSerializer와 LoginEvent 클래스는 (1) password 필드를 숨기고, (2) timestamp 필드를 포매팅한다.

위 방법은 처음에는 잘 동작하지만, 시간이 지나면서 시스템을 확장할수록 다음과 같은 문제가 발생한다고 말한다.

클래스가 너무 많아진다: 이벤트 클래스와 직렬화 클래스가 1:1로 맵핑되어 있으므로 직렬화 클래스가 점점 많아지게 된다.
이러한 방법은 충분히 유연하지 않다: 만약 password를 가진 다른 클래스에서도 이 필드를 숨기려면 함수로 분리한 다음 여러 클래스에서 호출해야 한다. 이는 코드를 충분히 재사용했다고 볼 수가 없다.
표준화: serialize() 메서드는 모든 이벤트 클래스에 있어야만 한다. 비록 믹스인을 사용해 다른 클래스로 분리할 수 있지만 상속을 제대로 사용했다고 볼 수 없다.

클래스 데코레이터의 대표적인 예를 살펴보자.

from datetime import datetime


def hide_field(field) -> str:
    return "**민감한 정보 삭제**"


def format_time(field_timestamp: datetime) -> str:
    return field_timestamp.strftime("%Y-%m-%d %H:%M")


def show_original(event_field):
    return event_field


class EventSerializer:
    def __init__(self, serialization_fields: dict) -> None:
        self.serialization_fields = serialization_fields

    def serialize(self, event) -> dict:
        return {
            field: transformation(getattr(event, field))
            for field, transformation in self.serialization_fields.items()
        }


class Serialization:
    def __init__(self, **transformations):
        self.serializer = EventSerializer(transformations)

    def __call__(self, event_class):
        def serialize_method(event_instance):
            return self.serializer.serialize(event_instance)

        event_class.serialize = serialize_method
        return event_class


@Serialization(
    username=show_original, password=hide_field, ip=show_original, timestamp=format_time
)
class LoginEvent:
    def __init__(self, username, password, ip, timestamp):
        self.username = username
        self.password = password
        self.ip = ip
        self.timestamp = timestamp

위 코드에서 첫 번째로 눈여겨봐야 할 점은 LoginEvent에서 SERIALIZER 속성이 사라지고, @Serialization 데코레이터가 추가된 것이다.

@Serialization 데코레이터를 통해서 LoginEvent의 각 필드는 어떤 함수를 통해 직렬화할 것인지 쉽게 알 수 있다.

데코레이터에 인자 전달 - (1) 중첩 함수의 데코레이터

크게 보면 데코레이터는 함수를 파라미터로 받아서 함수를 반환하는 함수이다. 이런 함수를 고차 함수(higher-order function)라고 부른다. 실제로는 데코레이터의 본문에 정의된 함수가 호출된다.

RETRIES_LIMIT = 3


class ControlledException(Exception):
    """도메인에서 발생하는 일반적인 예외"""


def with_retry(retries_limit=RETRIES_LIMIT, allowed_exceptions=None):  # 데코레이터의 파라미터를 받는 함수
    allowed_exception = allowed_exceptions or (ControlledException,)

    def retry(operation):  # 데코레이터 로직을 수행하는 함수
        @wraps(operation)
        def wrapped(*args, **kwargs):  # 데코레이팅 된 결과를 반환 하는 함수
            last_raised = None
            for _ in range(RETRIES_LIMIT):  # 무시해도 되는 값은 '_'로 표현
                try:
                    return operation(*args, **kwargs)
                except ControlledException as e:
                    logger.info("retrying %s", operation.__qualname__)
                    last_raised = e
            raise last_raised

        return wrapped

    return retry

책에서 말하는 것처럼 @with_retry 데코레이터는 retry라는 클로저를 반환한다. 즉, @with_retry 데코레이터는 결과적으로 함수를 반환하는 함수인 것이다.

이 데코레이터를 다른 함수에 적용한다면 다음과 같이 적용할 수 있다.

@with_retry()
# 또는 @with_retry(retries_limit=5)
# 또는 @with_retry(allowed_exceptions=(AttributeError,))
# 또는 @with_retry(retries_limit=5, allowed_exceptions=(ZeroDivisionError, AttributeError))
def run_operation(task):
    return task.run()

@with_retry 데코레이터는 내부적으로 run_operation() 함수를 호출하고, 이 로직은 wrapped() 클로저에서 구현돼 있다.

데코레이터에 인자 전달 - (2) 데코레이터 객체

RETRIES_LIMIT = 3


class ControlledException(Exception):
    """도메인에서 발생하는 일반적인 예외"""


class WithRetry:
    def __init__(self, retries_limit=RETRIES_LIMIT, allowed_exceptions=None):
        self.retries_limit = retries_limit
        self.allowed_exceptions = allowed_exceptions

    def __call__(self, operation):
        @wraps(operation)
        def wrapped(*args, **kwargs):
            last_raised = None
            for _ in range(self.retries_limit):
                try:
                    return operation(*args, **kwargs)
                except self.allowed_exceptions as e:
                    logger.info("retrying %s due to %s", operation, e)
                    last_raised = e
            raise last_raised

        return wrapped

데코레이터 객체의 사용 방법은 이전 방법과 유사하다.

@WithRetry(retries_limit=5)
def run_operation(task):
    return task.run()

데코레이터와 DRY 원칙

모든 데코레이터, 특히 신중하게 설계되지 않은 데코레이터 코드는 코드의 복잡성을 증가시킨다. 어떤 사용자는 함수의 논리를 완전히 이해하기 위해 데코레이터의 경로를 따라가보길 원할 수 있다. 따라서 이 복잡성이 가치가 있어야 한다는 점을 기억하자. 그다지 재사용할 필요가 없을 경우 별개의 함수나 작은 클래스로도 충분한 경우가 있다.

데코레이터 작성 시 가장 중요한 내용이다.

우리가 데코레이터를 사용할 때, 그 내부 로직을 확인하지 않는 개발자는 거의 없을 것이다. (개발자는 데코레이터의 로직을 확인해야 하지만, 래핑 되는 함수의 입장에서는 데코레이터의 내부 로직을 알 필요가 없다.)

지금까지 예제에서 봤듯이 데코레이터를 작성하게 되면 함수의 depth가 증가하고, 데코레이터의 내부 로직을 이해하는데 시간이 필요하다. 따라서 내가 작성하는 데코레이터가 단순히 코드 재사용성을 높이기 위해서인지, 아니면 기존의 함수(또는 객체)의 기능을 확장하기 위함인지 확인이 필요하다.

개인적으로는 단순 코드 재사용성을 높여서 DRY 원칙을 따르기 위함이라면, 데코레이터 말고 별도의 함수나 클래스로 추출하는 것이 더 나은 방법이라고 생각한다. retry 기능과 같이 래핑 할 함수의 기능은 그대로 유지하되, 기능 확장이 필요한 경우에 데코레이터를 사용하는 것이 좋지 않을까?

책에서 말하듯이, 내가 작성한 데코레이터의 복잡성이 가치가 있어야 한다는 점을 명심하자.

좋은 데코레이터 분석

캡슐화와 관심사의 분리: 좋은 데코레이터는 실제로 하는 일과 데코레이팅하는 일의 책임을 명확히 구분해야 한다. 어설프게 추상화를 하면 안 된다. 즉 데코레이터의 클라이언트는 내부에서 어떻게 구현했는지 전혀 알 수 없는 블랙박스 모드로 동작해야 한다.
독립성: 데코레이터가 하는 일은 독립적이어야 하며 데코레이팅되는 객체와 최대한 분리되어야 한다.
재사용성: 데코레이터는 하나의 함수 인스턴스에만 적용되는 것이 아니라 여러 유형에 적용 가능한 형태가 바람직하다. 왜냐하면 하나의 함수에만 적용된다면 데코레이터가 아니라 함수로 대신할 수도 있기 때문이다. 충분히 범용적이어야 한다.

아마 @retry 데코레이터가 위에서 말하는 좋은 데코레이터의 대표적인 예일 것이다.

위 특징과 @retry 데코레이터를 하나씩 비교해 보면, @retry 데코레이터는 위에서 말하는 모든 특징들을 만족한다는 것을 알 수 있다.

파이썬 클린 코드 (4/10)

최성훈 — Sat, 7 May 2022 02:59:05 +0900

4장. SOLID 원칙

S: 단일 책임 원칙
O: 개방/폐쇄의 원칙
L: 리스코프(Liskov) 치환 원칙
I: 인터페이스 분리 원칙
D: 의존성 역전 원칙

단일 책임 원칙 (S)

단일 책임 원칙(Single Responsibility Principle - SRP)은 소프트웨어 컴포넌트 (일반적으로 클래스)가 단 하나의 책임을 져야한다는 원칙이다. 클래스가 유일한 책임이 있다는 것은 하나의 구체적인 일을 담당한다는 것을 의미하며, 따라서 변화해야 할 이유는 단 하나뿐이다.

도메인의 문제가 변경되면 클래스를 업데이트해야 한다. 다른 이유로 클래스를 수정해야 한다면 추상화가 잘못되어 클래스에 너무 많은 책임이 있다는 것을 뜻한다.

여기서 말하는 도메인의 문제가 뭘까?

그리고 다른 이유로 클래스를 수정해야 할 잘못된 예가 뭐가 있을까?

아직은 추상적인 감밖에 잡히지 않네..

너무 많은 책임을 가진 클래스

class SystemMonitor:
    def load_activity(self):
        """소스에서 처리할 이벤트를 가져오기"""
    
    def identify_events(self):
    	"""가져온 데이터를 파싱하여 도메인 객체 이벤트로 변환"""
    
    def stream_events(self):
        """파싱한 이벤트를 외부 에이전트로 전송"""

이 클래스의 문제점은 독립적인 동작을 하는 메서드를 하나의 인터페이스에 정의했다는 것이다. 각각의 동작은 나머지 부분과 독립적으로 수행할 수 있다.

이 디자인 결함은 유지보수를 어렵게 하여 클래스가 경직되고 융통성 없으며 오류가 발생하기 쉽게 만든다. 이 예제에서 각 메서드는 클래스의 책임을 대표한다. 각각의 책임마다 수정 사유가 발생한다. 즉 메서드마다 다양한 변경의 필요성이 생기게 된다.

즉, 쉽게 말해서 SytemMonitor라는 클래스는 이벤트를 (1) 로드하고 (2) 파싱하며 (3) 외부로 전송한다.

책에서는 SystemMonitor 클래스의 책임이 너무 크다고 보는 것인데, 내 생각에는 "이벤트를 로드/파싱/전송하는 역할이 그렇게 큰 책임인가?" 싶긴 하다.

책임 분산

class AlertSystem:
    def run(self):
        """메소드 실행"""

class ActivityReader(AlertSystem):
    def load(self):
        """소스에서 처리할 이벤트를 가져오기"""

class SystemMonitor(AlertSystem):
    def identify_event(self):
        """가져온 데이터를 파싱하여 도메인 객체 이벤트로 변환"""

class Output(AlertSystem):
    def stream(self):
        """파싱한 이벤트를 외부 에이전트로 전송"""

개방/폐쇄 원칙 (O)

개방/폐쇄 원칙(Open/Close Principle)은 모듈이 개방되어 있으면서도 폐쇄되어야 한다는 원칙이다(물론 다른 측면에서의 개방과 폐쇄이다).

클래스를 디자인할 때는 유지보수가 쉽도록 로직을 캡슐화하여 확장에는 개방되고 수정에는 폐쇄되도록 해야 한다.

간단히 말해서 확장 가능하고, 새로운 요구사항이나 도메인 변화에 잘 적응하는 코드를 작성해야 한다는 뜻이다. 즉 새로운 문제가 발생할 경우 새로운 것을 추가만 할 뿐 기존 코드는 그대로 유지해야 한다는 뜻이다.

새로운 기능을 추가하다가 기존 코드를 수정했다면 그것은 기존 로직이 잘못 디자인되었다는 것을 뜻한다. 이상적으로는 요구사항이 변경되면 새로운 기능을 구현하기 위한 모듈만 확장을 하고 기존 코드는 수정을 하면 안 된다.

OCP 최종 정리

... 이 원칙은 다형성의 효과적인 사용과 밀접하게 관련되어 있다. 다형성을 따르는 형태의 계약을 만들고 모델을 쉽게 확장할 수 있는 일반적인 구조로 디자인하는 것이다.

... (중략)...

마지막 중요한 요점은 코드를 변경하지 않고 기능을 확장하기 위해서는 보호하려는 추상화에 대해서 적절한 폐쇄를 해야 한다는 것이다.

음.. 이 부분을 읽다 보니 내가 짠 코드가 생각이 난다.

일종의 보일러 플레이팅 된 함수인데, 새로운 요구사항이나 도메인 변화에 따라서 해당 함수를 고치려면 그 함수를 사용한 모든 코드를 수정해야 한다.

프로젝트 내에서 워낙 많은 곳에서 쓰이다 보니 이제는 함부로 수정하기가 쉽지 않은데, 이 부분을 읽다 보니 내가 안티 패턴 코드를 작성한 것 같다.

리스코프 치환 법칙 (LSP)

리스코프 치환 법칙(Liskov substitution principle, LSP)은 설계 시 안정성을 유지하기 위해 객체 타입이 유지해야하는 일련의 특성을 말한다.

LSP의 주된 생각은 어떤 클래스에서든 클라이언트는 특별한 주의를 기울이지 않고도 하위 타입을 사용할 수 있어야 한다는 것이다. 어떤 하위 타입을 사용해도 실행에 따른 결과를 염려하지 않아야 한다. 즉, 클라이언트는 완전히 분리되어 있으며 클래스 변경 사항과 독립되어야 한다.

메서드 서명의 잘못된 데이터타입 검사

class Event:
    ...
    def meets_condition(self, event_data: dict) -> bool:
        return False

class LoginEvent(Event):
    def meets_condition(self, event_data: list) -> bool:
        return bool(event_data)

LoginEvent 클래스의 meet_condition() 메소드는 부모 클래스의 인자와 다르다. (dict <-> list)

리스코프 치환 법칙에 따르면 Event 객체와 LoginEvent 객체의 호출자는 아무 변경 없이 두 개의 객체를 사용할 수 있어야 한다.

하지만 두 클래스의 meets_condition() 인자가 서로 달라서 두 클래스 간의 다형성이 손상되고, 호출자는 서로 다른 방법으로 두 객체를 사용해야만 한다.

이는 메소드 인자뿐만 아니라 반환값에서도 판단할 수 있는데, boolean 값이 아닌 다른 타입을 반환해도 문제가 발생한다. 리턴 타입을 boolean에서 다른 값으로 변경한다면, 계약(contract)을 위반하게 되고 이는 프로그램이 정상적으로 동작한다는 기대를 할 수 없게 된다.

LSP 최종 정리

LSP는 객체지향 소프트웨어 설계의 핵심이 되는 다형성을 강조하기 때문에 좋은 디자인의 기초가 된다. 인터페이스의 메서드가 올바른 계층구조를 갖도록 하여 상속된 클래스가 부모 클래스와 다형성을 유지하도록 하는 것이다.

LSP를 지키지 않는다는 것은 부모 클래스의 계약과 호환되지 않는 확장을 한다는 것이므로 클라이언트와 계약이 깨지게 된다.

이 상태에서 억지로 확장하려고 한다면 결과적으로 수정에 대해 폐쇄되어야 한다는 개방/폐쇄 원칙(OCP)을 깨게 된다.

이는 리스코프 치환 법칙(LSP)은 개방/폐쇄 원칙(OCP)에 기여한다고 말할 수 있다.

인터페이스 분리 법칙

인터페이스 분리 원칙(Interface Segregation Principle, ISP)은 이미 반복적으로 재검토했던 "작은 인터페이스"에 대한 가이드라인을 제공한다.

파이썬에서 인터페이스는 클래스 메서드의 형태를 보고 암시적으로 정의된다. 이것은 파이썬이 소위 말하는 덕 타이핑(duck typing) 원리를 따르기 때문이다.

... 즉 클래스의 유형, 이름 , docstring, 클래스 속성 또는 인스턴스 속성에 관계없이 객체의 본질을 정의하는 것은 궁극적으로 메서드의 형태이다. ..(중략).."어떤 새가 오리처럼 걷고 오리처럼 꽥꽥 소리를 낸다면 오리여야만 한다."는 데서 덕 타이핑이라고 불린다.

파이썬에 인터페이스가 없는 이유는 동적 바인딩 때문이다.

Java와 같은 컴파일 언어의 경우 클래스가 어떤 메소드를 가지고 있는지 미리 선언해야 하며, 이는 컴파일 타임에 체크된다.

반면에 파이썬의 경우엔 동적 바인딩 때문에 클래스와 관련된 속성들이 런타임에 체크된다.

이런 특징 때문에 파이썬은 덕 타이핑을 따를 수밖에 없다.

책에서는 파이썬의 인터페이스가 암시적으로 정의되는 이유는 덕 타이핑을 따르기 때문인 것처럼 말하는데, 그게 아니라 파이썬이 동적 언어이기 때문에 덕 타이핑을 따를 수밖에 없고, 결과적으로 클래스의 메소드 형태를 보고 판단할 수밖에 없게 되는 것이다.

추상적으로 말하자면 ISP는 다음을 뜻한다. 다중 메서드를 가진 인터페이스가 있다면 매우 정확하고 구체적인 구분에 따라 더 적은 수의 메서드(가급적이면 단 하나)를 가진 여러 개의 ~~메서드~~클래스로 분할하는 것이 좋다는 것이다.

책에서는 여러 개의 메서드로 분할하는 것이 좋다고 말하는데.. 이는 번역 오류인 것 같다.

메서드가 아니라 클래스가 아닐까 싶다.

SRP와 유사하지만 주요 차이점은 ISP는 인터페이스에 대해 이야기하고 있다는 점이다. 따라서 이것은 행동의 추상화이다.

인터페이스 분리 법칙은 이 한 문장으로 요약할 수 있을 것 같다.

의존성 역전

의존성 역전 원칙(DIP)은 코드가 깨지거나 손상되는 취약점으로부터 보호해주는 흥미로운 디자인 원칙을 제시한다. 의존성을 역전시킨다는 것은 코드가 세부 사항이나 구체적인 구현에 적응하도록 하지 않고, 대신에 API같은 것에 적응하도록 하는 것이다.

추상화를 통해 세부 사항에 의존하지 않도록 해야 하지만, 반대로 세부 사항 (구체적인 구현)은 추상화에 의존해야 한다.

만약 A 객체가 B 객체를 사용 중이라면, A 객체는 B 객체에 의존적이게 된다.

B 객체에 변경사항이 생긴다면 A 객체도 변경이 필요할 수 있다는 것이다.

이를 방지하기 위해 B 객체를 사용하기 위한 인터페이스(파이썬에서는 추상 클래스)를 사용해야 한다.

즉, A-B 클래스의 상호작용에서, A가 B에 의존적인 상황을 예방하기 위해 A-C-B와 같이 인터페이스를 두는 것이다.

이렇게 하면 A가 B에 의존하는 것이 아닌, B가 C 인터페이스를 따르게 한다고 볼 수 있다는 것이다.

파이썬 클린 코드 (3/10)

최성훈 — Fri, 18 Mar 2022 04:49:17 +0900

3장. 좋은 코드의 일반적인 특징

계약에 의한 디자인

계약에 의한 디자인(Design by Contract)이란 이런 것이다. 관계자가 기대하는 바를 암묵적으로 코드에 삽입하는 대신 양측이 동의하는 계약을 먼저 한 다음, 계약을 어겼을 경우는 명시적으로 왜 계속할 수 없는지 예외를 발생시키라는 것이다.

이 책에서 말하는 계약은 소프트웨어 컴포넌트 간의 통신 중에 반드시 지켜져야 할 몇 가지 규칙을 강제하는 것이다. 계약은 주로 사전조건과 사후조건을 명시하지만 때로는 불변식과 부작용을 기술한다.

여기서 말하는 계약이란 쉽게 말해 docstring과 같은 문서화를 의미한다.

정확한 결과를 보장하기 위해 컴포넌트(함수, 메서드 등) 간 상호작용 중에 반드시 지켜야 할 규칙을 문서화하고, 이를 기반으로 컴포넌트의 동작을 검증하는 설계 방식이다.

즉, 계약(= 문서화)을 통해 각 컴포넌트의 동작을 명시하고, 이를 기반으로 설계를 한다.

사전조건(precondition): 코드가 실행되기 전에 체크해야 하는 것들이다. 함수가 진행되기 전에 처리되어야 하는 모든 조건을 체크한다. 일반적으로 파라미터에 제공된 데이터의 유효성을 검사하지만 유효성 체크를 통해 부작용이 최소화된다는 점을 고려할 때 유효성 검사를 많이 하는 것이 좋다. 예를 들어 데이터베이스, 파일, 이전에 호출된 다른 메서드의 검사 등이다. 이러한 작업은 호출자에게 부과된 임무이다.

사후조건(postcondition): 사전조건과 반대로 여기서는 함수 반환 값의 유효성 검사가 수행된다. 사후조건 검증은 호출자가 이 컴포넌트에서 기대한 것을 제대로 받았는지 확인하기 위해 수행한다.

불변식(invariant): 때로는 함수의 docstring에 불변식에 대해 문서화하는 것이 좋다. 불변식은 함수가 실행되는 동안에 일정하게 유지되는 것으로 함수의 로직에 문제가 없는지 확인하기 위한 것이다.

부작용(side-effect): 선택적으로 코드의 부작용을 docstring에 언급하기도 한다.

이렇게 계약에 의한 디자인을 하는 이유는 오류가 발생할 때 쉽게 찾아낼 수 있기 때문이다.

불변식이나 부작용은 가능하다면 함께 작성하는 것이 좋다.

만약 사전조건 검증에 실패한다면 이는 클라이언트의 결함(또는 실수)에 의한 것이고, 사후조건 검증에 실패한다면 사용된 모듈이나 클래스에 문제가 있다는 것이다.

사전조건의 경우엔 런타임에 확인할 수 있다는 것을 주의해야 한다. (잘 생각해보면 당연한 이유다. )

나는 기회가 있을 때마다 docstring을 자세하게 작성하려고 하는데, 아래는 레거시 코드를 리팩토링 하면서 작성한 docstring이다.

사전조건, 사후조건, 불변식이 포함된 docstring

사전조건, 사후조건, 부작용이 포함된 docstring

이처럼 계약(= docstring)을 미리 작성한다면 함수의 책임을 사전에 명확하게 정의할 수 있는 장점이 있다.

만약 오류가 발생한다면 함수를 호출한 곳에서 문제가 있는지, 함수 내부 로직상에 문제가 있는지 원인 분석에도 도움이 된다.

사전조건(precondition)

이제 문제는 이 유효성 검사를 어디서 할지이다. 클라이언트가 함수를 호출하기 전에 모든 유효성 검사를 하도록 할 것인지, 함수가 자체적으로 로직을 실행하기 전에 검사하도록 할 것인지에 대한 문제이다. 전자는 관용적인(tolerant) 접근법이다. 왜냐하면 함수가 어떤 값이라도 (심지어 깨진 데이터도) 수용하기 때문이다. 반면 후자는 까다로운(demanding) 접근 방법에 해당한다.

분석을 위해 DbC에 대한 까다로운 접근법을 사용해보자. 일반적으로 가장 안전하고 견고한 방법이며 업계에서도 가장 널리 쓰이는 방법이다.

음.. 나는 함수가 실행되는 가장 첫 부분에 유효성 검사(validation check)를 주로 넣는데, 운이 좋게도 올바른 방법이었구나 싶다. (함수 첫 부분에서 유효성 검사를 하는 이유는 딱히 없었고 그냥 그게 더 합리적으로 보였다. ㅋㅋ... )

여기서 주의해야 할 점이 있는데, 책에서는 다음과 같이 말한다.

어떤 방식을 택하든 중복 제거 원칙을 항상 마음속에 간직해야 한다. 중복 제거 원칙은 사전조건 검증을 양쪽에서 하지 말고 오직 어느 한쪽에서만 해야 한다는 것이다. 즉, 검증 로직을 클라이언트에 두거나 함수 자체에 두어야 한다. 어떤 경우에도 중복해서는 안 된다. 이것은 뒤쪽에서 다룰 DRY 원칙과 관련이 있다.

DRY 원칙이란 "Do Not Repeat Yourself"를 의미한다.

즉, 이미 있는 코드를 스스로 다시 짜지 말라는 말이다.

어떤 형태로든 중복된 로직을 제거하라는 의미이며, 사전조건을 검증할 때 (1) 함수를 호출하는 곳, (2) 함수 내부 둘 중 한 곳에서만 검증을 하라는 것이다.

DRY 원칙은 Django의 설계 철학 중 하나이다.

방어적(defensive) 프로그래밍

방어적 프로그래밍의 주요 주제는 예상할 수 있는 시나리오의 오류를 처리하는 방법과 (불가피한 조건에 의해서) 발생하지 않아야 하는 오류를 처리하는 방법에 대한 것이다. 전자는 에러 핸들링 프로시저에 대한 것이며, 후자는 어썰션(assertion)에 대한 것이다.

예외처리

마지막으로 중요한 개념이 하나 더 있다. 예외는 대개 호출자에게 잘못을 알려주는 것이다. 예외는 캡슐화를 약화시키기 때문에 신중하게 사용해야 한다. 함수에 예외가 많을수록 호출자가 호출하는 함수에 대해 더 많은 것을 알아야만 한다. 그리고 함수가 너무 많은 예외를 발생시키면 문맥에서 자유롭지 않다는 것을 의미한다. 왜냐하면 호출할 때마다 발생 가능한 부작용을 염두에 두고 문맥을 유지해야 하기 때문이다.

꽤 공감되는 말이다.

만약 함수 내부에서 발생시키는 예외가 많을수록, 함수를 호출하는 곳에서는 일어날 수 있는 예외 개수만큼 추가적인 예외처리를 해야 한다.

책에서는 이를 두고 "문맥을 유지"한다라고 표현한 것 같다.

예를 들면, 만약 아래와 같이 예외를 발생시킬 수 있는 something() 함수가 있다고 치자.

try:
	something()
except KeyError:
	handle_key_error()
except AttributeError:
	handle_attribute_error()

something()을 호출하는 곳에서는 something()이 어떤 예외를 일으키는지 알고 있어야 하며, 만약 발생할 수 있는 예외가 누락된다면 프로그램에 장애를 유발할 수 있다.

이러한 예외가 많아질수록 책에서는 다음과 같이 말한다.

이것은 함수가 응집력이 약하고 너무 많은 책임을 가지고 있다는 것을 알기 위한 경험적 확인 방법이 될 수도 있다. 예외가 너무 많이 발생하면 여러 개의 작은 것으로 나눠야한다는 신호일 수 있다.

관심사의 분리

소프트웨어에서 관심사를 분리하는 목표는 파급 효과를 최소화하여 유지보수성을 향상시키는 것이다. 파급(ripple) 효과는 어느 지점에서의 변화가 전체로 전파되는 것을 의미한다. 이러한 오류나 예외는 다른 예외를 유발하거나 혹은 먼 지점의 결함을 초래한다. 함수 정의를 약간만 변경해도 코드의 여러 부분에 영향을 미쳐 많은 코드를 변경해야 할 수도 있다.

음.. 요즘 내가 고민하고 있는 문제다.

아래와 같이 함수의 리턴 값을 dict에서 tuple로 변경하고 싶은데, 이 함수를 호출하는 부분이 너무 많다 보니 함부로 변경하기가 어렵다는 것이다.

def something():
    a = do_something()
    return a

위 함수를

def something():
    a = do_something()
    b = do_something_else()
    return a, b

이렇게 변경하고 싶지만, 그렇게 하려면 something()의 리턴값을 사용하는 모든 부분을 수정해야 한다.

좋은 방법은 없을까?

개발 지침 약어

DRY/OAOO

DRY(Do not Repeat Yourself)와 OAOO(Once and Only Once)는 밀접한 관련이 있으므로 함께 다룬다. 자명한 원리로써 중복을 반드시 피해야 한다.

YAGNI

YAGNI(You Ain't Gonna Need it)는 과잉 엔지니어링을 하지 않기 위해 솔루션 작성 시 계속 염두에 두어야 하는 원칙이다.

확장성을 고려한다면 가끔씩 고도화된 설계가 필요할 때가 있다.

책에서는 "오직 현재의 요구사항을 잘 해결하기 위한 소프트웨어를 작성하고 가능한 나중에 수정하기 쉽도록 작성하는 것이다."라고 했는데, 이는 '지금 당장은 일단 구현만 하면 되겠네'같은 오해의 소지를 불러일으킬 수 있다.

가령 내가 어떤 요구사항을 구현하기 위해서 (1) DB에 칼럼을 추가할 것인지, (2) 스키마를 정규화할 것인지 고민한다고 가정해보자.

그렇다면 나는 아래와 같은 경우를 두고 고민을 할 것이다.

DB에 단순히 칼럼만 추가했는데 더 복잡한 요구사항이 발생하는 경우 (예: 정규화)
스키마를 정규화했는데 추가 요구사항이 없는 경우

개인 성향 차이겠지만, 난 2번을 선호한다.
(즉, 일단 정규화를 한다는 뜻이다. )

1번과 같은 방법으로 계속 코드를 작성한다면, 언젠가는 돌이킬 수 없는 코드가 될 수도 있다고 생각하기 때문이다.

그렇지만 다른 누군가는 '굳이 지금 필요하지도 않은데 일을 더 크게 벌려야 하나?'라고 생각할 수도 있다.

난 아직도 정답을 잘 모르겠지만, 책에서는 다음과 같이 말한다.

다시 말해 디자인을 할 때 내린 결정으로 특별한 제약 없이 개발을 계속할 수 있다면, 굳이 필요 없는 추가 개발을 하지 말라는 것이다.

KIS

KIS(Keep It Simple)는 이전 원칙과 매우 흡사하다. 소프트웨어 컴포넌트를 설계할 때 과잉 엔지니어링을 피해야 한다. 선택한 솔루션이 문제에 적합한 최소한의 솔루션인지 자문해보자.

..(중략).. 기억해야 할 점은 디자인이 단순할수록 유지 관리가 쉽다는 것이다.

다시 책에서는 디자인을 단순하게 유지하라고 한다.

KIS에서 말하는 것을 보니, 코드 구조를 단순하게 유지하라는 말인 것 같다.

나는 디자인 패턴과 같은 거시적 관점에서의 설계를 생각했는데, 예제 코드를 보아하니 그저 코드를 단순하게 짜라는 말인 것 같다.

class ComplicatedNamespace:
    ACCEPTED_VALUES = ("id_", "user", "location")

    @classmethod
    def init_with_data(cls, **data):
        instance = cls()
        for key, value in data.items():
            if key in cls.ACCEPTED_VALUES:
                setattr(instance, key, value)
        return instance

위 코드를 아래와 같이 단순하게 변경한다.

객체를 초기화하기 위해서 반복문과 setattr()을 사용 중인데, 굳이 이렇게 작성할 필요가 없다는 것이다.

class ComplicatedNamespace2:
    ACCEPTED_VALUES = ("id_", "user", "location")

    def __init__(self, **data):
        accepted_data = {
            k: v for k, v in data.items() if k in self.ACCEPTED_VALUES
        }
        self.__dict__.update(accepted_data)

파이썬의 철학을 기억하자: 단순한 것이 복잡한 것보다 낫다.

컴포지션과 상속

상속은 강력한 개념이지만 위험도 있다. 가장 주된 위험은 부모 클래스를 확장하여 새로운 클래스를 만들 때마다 부모와 강력하게 결합된 새로운 클래스가 생긴다는 점이다. 이미 설명했듯이 소프트웨어를 설계할 때마다 결합력(coupling)을 최소한으로 줄이는 것이 중요하다.

..(중략).. 코드를 재사용하는 올바른 방법은 여러 상황에서 동작 가능하고 쉽게 조합할 수 있는 응집력 높은 객체를 사용하는 것이다.

상속이 좋은 선택인 경우

파생 클래스를 만드는 것은 양날의 검이 될 수 있으므로 주의해야 한다. 한편으로는 부모 클래스의 메서드를 공짜로 전수 받을 수 있는 장점이 있지만 그러나 다른 한편으로 모든 것을 새로운 클래스로 가져왔기 때문에 새로운 정의에 너무 많은 기능을 추가하게 되는 단점도 있다.

맞는 말이다.

자식 클래스가 부모 클래스를 상속한다면 부모 클래스의 모든 것(속성, 메소드)을 가져온다.

만약 자식 클래스에서 확장하는 범위가 적고, 자식 클래스가 부모 클래스의 메소드를 100% 활용하지 않는다면 이는 올바르지 않은(혹은 불필요한) 상속이다.

만약 그렇다면 자식 클래스가 확장하는 범위가 적절한지, 부모 클래스가 너무 많은 책임을 가지고 있는 건 아닌지 다시 확인해야 한다.

믹스인(mixin)

믹스인은 코드를 재사용하기 위해 일반적인 행동을 캡슐화해놓은 기본 클래스이다. 일반적으로 믹스인 클래스는 그 자체로는 유용하지 않으며 대부분이 크래스에 정의된 메서드나 속성에 의존하기 때문에 이 클래스만 확장해서는 확실히 동작하지 않는다. 보통은 다른 클래스와 함께 믹스인 클래스를 다중 상속하여 믹스인에 있는 메서드나 속성을 사용한다.

믹스인은 활용도가 높은 유용한 클래스다.

믹스인 클래스가 어떤 클래스인지는 예제를 통해서 이해하는 게 더 쉽다.

class BaseTokenizer:
    """하이픈(-)을 기준으로 문자열을 나눈다."""
    def __init__(self, str_token):
        self.str_token = str_token

    def __iter__(self):
        yield from self.str_token.split("-")


class UpperIterableMixin:
    """부모 클래스의 __iter__() 결과를 대문자로 변환한다."""
    def __iter__(self):
        return map(str.upper, super().__iter__())


class Tokenizer(UpperIterableMixin, BaseTokenizer):
    """믹스인에서 __iter__()를 호출하고 super()를 통해 BaseTokenizer에 위임한다."""
    pass

위 코드는 아래와 같이 실행된다.

>>> tk = Tokenizer("a-b-c-d-e")
>>> list(tk)
['A', 'B', 'C', 'D', 'E']

함수와 메서드의 인자

인자는 함수에 어떻게 복사되는가

파이썬의 첫 번째 규칙은 모든 인자가 값에 의해 전달(passed by a value)된다는 것이다. 즉 함수에 값을 전달하면 함수의 서명에 있는 변수에 할당하고 나중에 사용한다. 인자를 변경하는 함수는 인자의 타입에 따라 다른 결과를 낼 수 있다. 만약 변경 가능한(mutable) 객체를 전달하고 함수에서 값을 변경하면 함수 반환 시 실제 값이 변경되는 부작용이 생길 수 있다.

여기서 흔한 실수가 발생한다.

파이썬에서 함수 기본 인자는 함수가 호출되는 순간마다가 아니라 함수가 정의되는 순간에(한 번)만 평가된다.

따라서 만약 함수의 기본 인자가 변경 가능한(mutable)한 객체로 선언된다면 이후에 함수가 호출될 때마다 그 객체를 참조한다.

예를 들면 아래와 같다.

def append_to(element, to=[]):
    to.append(element)
    return to

>>> first_list = append_to(12)
>>> first_list
[12]
>>> second_list = append_to(42)
>>> second_list  # [42]가 나오길 기대한다.
[12, 42]

리스트 객체는 append() 함수가 정의될 때 한 번만 생성되고, 이후에 모든 append() 호출에 똑같은 리스트 객체가 참조된다.

이를 방지하기 위해 우리는 함수의 기본 인자로 변경 가능한(mutable)한 객체를 사용하지 않고, 다음과 같이 사용해야 한다.

def append_to(element, to=None):
    if not to:
        to = []
    to.append(element)
    return to

파이썬 클린 코드 (2/10)

최성훈 — Fri, 4 Mar 2022 05:31:51 +0900

2장. 파이썬스러운(Pythonic) 코드

인덱스와 슬라이스

.. 만약 래퍼도 아니고 내장(builtin) 객체를 사용하지도 않은 경우는 자신만의 시퀀스를 구현할 수 있다. 이때는 다음 사항에 유의해야 한다.

범위로 인덱싱하는 결과는 해당 클래스와 같은 타입의 인스턴스여야 한다
slice에 의해 제공된 범위는 파이썬이 하는 것처럼 마지막 요소는 제외해야 한다.

여기서 말하는 시퀀스(sequence)란 기본적으로 list, tuple, range 객체를 의미한다. (이외에 다른 시퀀스 타입도 존재한다.)

컨텍스트 관리자 (Context Manager)

컨텍스트 관리자는 파이썬이 제공하는 유용한 기능이다. 이것이 특별히 유용한 이유는 패턴에 잘 대응되기 때문이다. 이 패턴은 사실상 모든 코드에 적용될 수 있으며 사전조건과 사후조건을 가지고 있다. 즉 주요 동작의 전후에 작업을 실행하려고 할 때 유용하다.

일반적으로 리소스 관리와 관련하여 컨텍스트 관리자를 자주 볼 수 있다. 예를 들어 일단 파일을 열면 파일 디스크립터 누수를 막기 위해 작업이 끝나면 적절히 닫히길 기대한다. 또는 서비스나 소켓에 대한 연결을 열었을 때도 적절하게 닫거나 임시 파일을 제거하는 등의 작업을 해야 한다.

이 모든 경우에 일반적으로 할당된 모든 리소스를 해제해야 한다. 모든 것이 잘 처리되었을 경우의 해제는 쉽지만 예외가 발생하거나 오류를 처리해야 하는 경우는 어떻게 될까? ..(중략).. 가장 일반적인 방법은 finally 블록에 정리 코드를 넣는 것이다. 예를 들어 다음과 같은 간단한 예제를 생각해볼 수 있다.

fd = open(filename)
try:
    process_file(fd)
finally:
    fd.close()

그렇지만 똑같은 기능을 매우 우아하고 파이썬스러운 방법으로 구현할 수도 있다.

with open(filename) as fd:
    process_file(fd)

with문은 컨텍스트 관리자로 진입하게 한다.

컨텍스트 관리자는 __enter__()와 __exit__() 두 개의 매직 메서드로 구성된다.

with 블록이 실행되기 전에 __enter__() 메소드를 실행하고 그 반환값은 as로 지정된 변수에 저장되며(__enter__() 메소드가 꼭 값을 반환할 필요는 없다.), with 블록이 끝날 때는 __exit__() 메소드가 호출된다.

위 예제에서 open()은 컨텍스트 관리자 프로토콜을 구현하며, 예외가 발생한 경우에도 파일(fd)이 자동으로 닫힌다.

컨텍스트 관리자는 관심사를 분리하고 독립적으로 유지되어야하는 코드를 분리하는 좋은 방법이다.

프로퍼티, 속성과 객체 메서드의 다른 타입들

public, private, protected 프로퍼티를 가지는 다른 언어들과는 다르게 파이썬 객체의 모든 프로퍼티와 함수는 public이다. 즉 호출자가 객체의 속성을 호출하지 못하도록 할 방법이 없다.

엄격한 강제사항은 없지만 몇 가지 규칙이 있다. 밑줄로 시작하는 속성은 해당 객체에 대해 private을 의미하며, 외부에서 호출하지 않기를 기대하는 것이다. 다시 말하지만 이것을 금지하는 것은 아니다.

2년 넘게 파이썬만 쓰다 보니 접근제어자(Access Modifier)가 있는 자바는 어떻게 사용하는지 까먹은 것 같다.

파이썬의 모든 프로퍼티와 함수가 public인 것은 프로젝트 내 어디서든 프로퍼티/함수에 접근이 가능하므로 비즈니스 로직을 구현할 때는 매우 편하지만, 반대로 코드 퀄리티를 신경 쓰지 않으면 스파게티 코드가 돼버리는 단점이 있는 것 같다.

특히나 _의 경우는 언어에서 강제하는 것이 아니기 때문에 (우리 팀에 한에서는) 실무에서 잘 쓰지 않는 것 같다.

다음엔 신경 써서 잘 활용해봐야겠다.

밑줄 두 개를 사용하면 실제로 파이썬은 다른 이름을 만든다. 이름 맹글링(name mangling)이라 한다. 이것이 하는 일은 다음과 같은 이름의 속성을 만드는 것이다. "_<class-name>__<attribute-name>" 경우 '_Connector__timeout'이라는 속성이 만들어지며 이러한 속성은 다음과 같이 접근하여 수정할 수 있다.

>>> vars(conn)
{'source': 'postgresql://localhost', '_Connector__timeout': 60}
>>> conn._Connector__timeout
60
>>> conn._Connector__timeout = 30
>>> conn.connect()
connecting with 30s

이중 밑줄은 파이썬스러운(pythonic) 코드가 아니다.

속성을 private으로 정의하려는 경우 하나의 밑줄을 사용하고 파이썬스러운 관습을 지키자.

프로퍼티는 명령-쿼리 분리 원칙(Command and Query Separation - CC08)을 따르기 위한 좋은 방법이다. 명령-쿼리 분리 원칙은 객체의 메서드가 무언가의 상태를 변경하는 커맨드이거나 무언가의 값을 반환하는 쿼리이거나 둘 중에 하나만 수행해야지 둘 다 동시에 수행하면 안 된다는 것이다.

Get/Set의 성격을 띠는 메소드는 철저하게 로직을 분리하라는 뜻인 것 같다.

이터러블 객체

... 객체를 반복할 수 있는지 확인하기 위해 파이썬은 고수준에서 다음 두 가지를 차례로 검사한다.

객체가 __next__나 __iter__ 이터레이터 메서드 중 하나를 포함하는지 여부
객체가 시퀀스이고 __len__과 __getitem__을 모두 가졌는지 여부

이터러블을 사용하면 메모리를 적게 사용하지만 n 번째 요소를 얻기 위한 시간복잡도는 O(n)이다. 하지만 시퀀스로 구현하면 더 많은 메모리가 사용되지만 (모든 것을 한 번에 보관해야 하므로) 특정 요소를 가져오기 위한 인덱싱의 시간 복잡도는 O(1)로 상수에 가능하다.

컨테이너 객체

컨테이너는 __contains__ 메서드를 구현한 객체로 __contains__ 메서드는 일반적으로 Boolean 값을 반환한다. 이 메서드는 파이썬에서 in 키워드가 발견될 때 호출된다.

.. (중략) ..

이 메서드를 잘 사용하면 코드의 가독성이 정말 높아진다. (파이썬스러운 코드다!)

__contains__와 같은 매직 메서드를 구현하려면 클래스가 있어야 하는데, 현재 실무에서는 특별히 클래스를 따로 작성하지 않고 있다.

Django 프레임워크 내부적으로 모델-시리얼라이저-뷰 레이어를 두고 코드를 작성하기 때문에, 별도의 매직메서드를 위한 새로운 클래스를 작성할 필요가 딱히 없다.

Django에서 지원하는 클래스(모델, 시리얼라이저, 뷰)만으로도 대부분의 비즈니스 로직은 구현 가능하기 때문이다.

Django도 MVT(Model-View-Template)라는 MVC 패턴과 유사한 패턴을 가지고 있는데, MVC와 마찬가지로 Fat Model Skinny View이다.

Fat Model Skinny View를 지향한다면, 파이썬 매직 메서드를 모델 클래스 안에다가 구현하면 될 것 같다.

음.. 지금 돌이켜보니 요즘엔 비즈니스 로직을 View 레이어 근처에다가 구현했던 것 같은데, 다시 주의하면서 코드를 짜야겠다.

파이썬 클린 코드 (1/10)

최성훈 — Fri, 4 Mar 2022 05:31:30 +0900

1장. 코드 포맷팅과 도구

클린 코드의 중요성

코드의 품질을 관리하지 않는다면 결과적으로 기술 부채가 누적되어 실패한 프로젝트가 될 가능성이 높아진다.

클린 코드인지 아닌지는 다른 엔지니어가 코드를 읽고 유지 관리할 수 있는지 여부에 달려있다.

개인적으로 상당히 공감하는 말이다.

클린 코드 판단은 내 코드 리뷰에서도 이루어지는데, 내 코드가 꼼꼼하지 않게 승인돼도 큰 상관이 없다.
리뷰를 받는 코드의 maintainer는 나 자신(=코드 작성자)이기 때문이다.

하지만 대부분의 개발자는 은퇴할 때까지 한 곳에서만 일하지 않기 때문에, 내가 이직을 한다면 내 동료는 내가 작성한 코드를 유지보수해야만 한다.

내가 팀을 떠날 때의 maintainer는 내 동료이며, 내 코드에 대한 평가는 이때에도 이루어진다.

클린 코드를 위해서는 내가 알아볼 수 있는 코드가 아니라 동료도 알아볼 수 있는 코드를 작성해야 한다.

좋은 코드 레이아웃에서 가장 필요한 특성은 일관성이다. 코드가 일관되게 구조화되어 있으면 가독성이 높아지고 이해하기 쉬워진다. 만약 팀원 모두가 코드의 일관성을 유지하지 않고 자신의 방식으로 일을 하고 있다면 결국은 많은 시간과 노력을 투입해야만 할 것이다. 오류가 발생하기 쉽고 이해하기 어렵거나 애매한 부분이 많이 생기게 된다.

이 부분은 개인적으로 팀원 모두 노력이 필요하다고 생각한다.

우리는 유틸리티성 모듈의 이름을 정할 때 common, shared, 혹은 utilities라고 정할 수 있다.

하지만 공통 모듈임에도 불구하고 만약 여러 동료가 각기 다른 이름으로 모듈을 생성/관리한다면, 그 모듈은 책에서 말하듯이 이해하기 어렵거나 애매한 모듈이 돼버린다.

개인적인 생각으로는 비슷한 일이 발생할 때는 팀원에게 의견을 구하고, 프로젝트 내 일관성을 유지하기 위해 의견을 통일해야 하지 않을까 싶다.

Docstring과 어노테이션

코드에 주석(Comment)을 다는 것은 여러 가지 이유로 나쁜 습관이다. 첫째, 주석은 코드로 아이디어를 제대로 표현하지 못했음을 나타내는 것이다. 만약 무언가를 왜 어떻게 하는지 꼭 설명해야 한다면 그 코드는 아마도 충분히 좋지 못한 것이다. 둘째,

..(중략)..

그러나 docstring의 경우는 좀 다르다. 다시 말하지만 주석을 다는 것이 아니라 코드의 특정 컴포넌트(모듈, 클래스, 메서드 또는 함수)에 대한 문서화이다. 이런 컴포넌트에 사용하는 것은 허용될 뿐 아니라 권장되는 부분이다. 가능한 많은 docstring을 추가하는 것이 좋다.

주석(Comment)과 docstring의 차이를 이해하는 것이 중요하다.

특히 파이썬은 동적으로 타입을 결정하기 때문에 함수나 메서드를 거치면 변수나 객체의 값이 무엇인지 알기가 어려운 경우가 많다.

따라서 docstring을 통해 해당 컴포넌트에 대한 설명이 필요하다.

... 코드를 변경한 경우 위키(wiki), 사용자 매뉴얼, README 파일 또는 docstring 등 관련된 모든 내용을 업데이트하는 것이 중요하다.

.. 고 하지만 막상 실제로 업무를 진행하다 보면 다 챙기는 것은 불가능에 가까운 것 같다.

동료가 작성한 코드를 살펴볼 때는 다음 질문을 해야 한다.

이 코드를 동료 개발자가 쉽게 이해하고 따라갈 수 있을까?
업무 도메인에 대해서 말하고 있는가?
팀에 새로 합류하는 사람도 쉽게 이해하고 효과적으로 작업할 수 있을까?

나는 습관적으로 위와 같은 고민을 한다.

이런 고민 자체가 습관이 되다 보니 비록 코드를 짜기까지 시간이 걸리기도 하고, 코드 리뷰를 하면서 변수명이나 로직 자체에 대해서 의견을 제시하는 경우가 많다. (그냥 의견을 제시하는 것뿐이지만, 가끔씩 동료는 내가 딴지를 건다고 느끼는 것 같다. )

때문에 보이지는 않지만 동료의 감정을 상하게 만든 것 같이 느껴질 때가 있다.
(제 소프트 스킬이 부족한 탓입니다.. 동료분들께 다시 한번 사과드립니다 ‍♂️ ‍♂️)

그래도 이 부분을 읽으니 내가 가진 습관이 꼭 나쁜 습관은 아닌 것 같아서 조금이나마 위로가 된다.

Code Formatter와 Linter의 차이

최성훈 — Fri, 4 Mar 2022 05:31:09 +0900

Formatter: 코드 스타일을 수정함 (예: spacing, 줄바꿈, 주석 등)

Linter: 에러를 찾기 위해 코드를 분석하고, 더 나은 코드 퀄리티를 위한 모범 사례를 제공함

Formatter의 예는 아래와 같다.

a = [first_element, second_element, third_element, forth_element, fifth_element, sixth_element]

가 아래와 같이 변경된다.

a = [
  first_element,
  second_element,
  third_element,
  forth_element,
  fifth_element,
  sixth_element
]

Linter의 예는 아래와 같다.

type(a) is list

가 아래와 같이 변경된다.

isinstance(a, list)

가장 이상적인 사용 사례는

Formatter로 코드 스타일을 수정(또는 통일)하고
Linter로 발생할 수 있는 에러를 수정하거나 더 나은 구문을 사용한다.

Django ORM의 Case-Sensitive 검색 (MySQL)

최성훈 — Fri, 4 Mar 2022 05:30:04 +0900

얼마전 동료에게 CS(Customer Service) 문의가 들어왔다.

A 유저가 투표한 내용이 B 유저에게 노출이 됐다는 것이다.

내가 보기엔 꽤나 흥미롭고 귀찮은 이슈였는데( ), 동료가 분석한 원인은 다음과 같았다.

A가 '홍길동'에게 투표했음
A의 고유 ID는 ABCDE
B의 고유 ID는 ABcdE (대소문자만 다름)
Django 서버는 DB 설정에 따라서 대소문자를 구별함 (utf8_general_ci)
Django ORM filter()를 통해 case-sensitive한 쿼리(__exact__ field lookup)를 보내도, DB에서 case-insensitive하게 처리
DB에서 case-insensitive하게 처리하므로 A와 B는 동일한 사용자로 판단

이는 MySQL의 collation이 utf8_general_ci로 설정돼있어서 생긴 문제였다.

Non-UCA collations have a one-to-one mapping from character code to weight. In MySQL, such collations are case-insensitive and accent-insensitive. utf8_general_ci is an example: 'a', 'A', 'À', and 'á' each have different character codes but all have a weight of 0x0041 and compare as equal.

utf8_general_ci는 case-insenstive하며 accent-insensitive하다.

이름에서 알 수 있듯이, _ci는 case-insensitive를 의미한다.

collation에 대한 네이밍 컨벤션은 여기에 나와있으며, 아래와 같다.

Collation 접미사 의미

제일 근본적인 해결법은 DB 설정을 utf8mb4_bin과 같은 case-sensitive한 collation으로 바꾸는 것이겠지만, DB 설정을 바꾸는 일은 DBA에게 승인을 받아야 하기 때문에 대응까지 시간이 걸린다.

만약 개발자 입장에서 빠른 대응이 필요하다면 코드 배포로 쿼리에 COLLATE를 추가하는 것도 방법일 듯 하다.

[Docker] 컨테이너 외부로 노출하기 (docker0, veth)

최성훈 — Tue, 16 Jun 2020 04:12:19 +0900

네트워크 인터페이스 (Network Interface)

네트워크 인터페이스는 존재할 수 있는 모든 네트워크 어댑터에 대한 지속적 인터페이스를 IP 계층에 제공하기 위해 네트워크 고유 장치 드라이버 및 IP 계층과 통신하는 네트워크 고유 소프트웨어입니다. 또한, 네트워크 인터페이스에는 네트워크 주소가 있습니다.

가상 머신과 마찬가지로 도커 컨테이너 또한 가상 IP를 할당받는데요, 기본적으로 도커는 172.17.0.xxx의 IP 주소를 순차적으로 컨테이너에게 할당합니다.

먼저, 호스트의 네트워크 인터페이스를 살펴보겠습니다.

내 노트북의 네트워크 인터페이스 목록

여기서 우리는 docker0라는 네트워크 인터페이스를 확인할 수 있는데요, docker0는 실제 네트워크 어댑터가 연결되어있지 않은 가상의 리눅스 브릿지로, IP주소 172.17.0.1/16로 지정되어 있습니다. 또한 호스트의 IP 주소는 111.13.113.181입니다.

도커 서버는 리눅스 커널 내에서 컨테이너가 다른 컨테이너 또는 외부와 통신하기 위해 사용되는 이더넷 브릿지로서 호스트 시스템의 docker0 인터페이스를 생성하고 구성합니다. docker0 브릿지는 도커에 의해서 생성된 가상 인터페이스로, RFC1918에 의해 정의된 호스트 머신에서 사용하지 않는 범위 내에서 임의로 주소와 서브넷을 선택하여 docker0로 할당합니다. 모든 도커 컨테이너는 기본적으로 docker0로 연결되며, docker0에 연결된 컨테이너는 외부와 통신하기 위해 도커가 생성한 iptables NAT 규칙을 사용할 수 있습니다.

이제 컨테이너를 하나 생성하고, 그 컨테이너의 네트워크 인터페이스를 살펴보겠습니다.

임의로 생성한 컨테이너의 네트워크 인터페이스 목록

생성된 컨테이너는 eth0라는 네트워크 인터페이스를 가지며, IP 주소는 172.17.0.2/16인 것을 확인할 수 있습니다.

포트 바인딩 (Port Bindnig)

아무런 설정을 하지 않았다면, 우리가 생성한 컨테이너는 외부에서 접근할 수 없으며, 도커 엔진이 설치된 호스트에서만 접근할 수 있습니다. 이 컨테이너를 외부에 노출시키기 위해서는 먼저 호스트와 연결이 되어야 합니다. 이를 위해서 우리는 eth0의 IP와 포트 번호를 호스트의 IP와 포트 번호에 바인딩해야 합니다.

다음의 명령어로 컨테이너를 실행하고, 아파치 웹서버를 설치합니다.

$ docker run -i -t --name network_test -p 9999:80 ubuntu:14.04
root@57db86df07c5:/# apt install apache2 -y
root@57db86df07c5:/# service apache2 start

여기서 눈여겨 볼 점은, -p 9999:80 부분입니다. -p 옵션의 입력형식은 다음과 같습니다.

-p [바인딩 할 호스트의 포트]:[바인딩 할 컨테이너의 포트]

만약 호스트의 9999 포트 번호와 컨테이너의 80 포트 번호로 올바르게 바인딩이 되었다면, 다음 그림처럼 나타낼 수 있습니다.

바인딩 된 컨테이너

이제 올바르게 바인딩 되었는지 확인해봅시다. 호스트의 IP 주소인 110.13.113.181와 바인딩 된 포트번호인 9999를 사용하여 웹 브라우저에서 접속합니다. (물론 호스트에서 접속해야 합니다.) 만약 컨테이너가 올바르게 바인딩 되어 호스트와 연결이 되었다면, 아파치 웹 페이지가 보일 것입니다.

아파치 웹 페이지

호스트에서 9999 포트로 접속했을 때 아파치 웹 페이지가 보이네요! 이제 우리는 컨테이너가 호스트와 연결된 것을 확인했습니다.

veth 인터페이스 (veth Interface)

앞서 우리는 성공적으로 호스트와 컨테이너를 연결했습니다. 하지만 어떻게 컨테이너와 호스트가 연결되었는지 아직 잘 모릅니다.

다시 한 번 컨테이너와 호스트의 네트워크 인터페이스를 확인해봅시다.

컨테이너와 호스트의 네트워크 인터페이스 목록

아니 이게 뭔가요? 아파치 서버를 설치하여 테스트 하는 동안, 우리가 모르는 사이 vethcf10e95라는 네트워크 인터페이스가 추가되었습니다.

외부와 연결을 해야할 경우, 도커 데몬은 호스트 머신에 veth라는 네트워크 인터페이스를 생성합니다. 생성된 veth 인터페이스는 호스트의 docker0 브릿지에 바인딩됩니다. 컨테이너는 자신이 가진 eth0 인터페이스와 docker0 브릿지에 바인딩 된 veth 인터페이스를 통해 docker0 브릿지와 연결이 됩니다. 이를 통해 결론적으로 컨테이너는 외부와 통신을 할 수 있게 됩니다.

따라서 현재 제 노트북에서 컨테이너와 연결된 네트워크 인터페이스는 다음 그림과 같이 나타낼 수 있습니다.

바인딩 된 컨테이너

References

본 포스트는 다음의 주소를 참고하였습니다.

#2

최성훈 — Fri, 12 Jun 2020 17:54:31 +0900

도전

[Docker] Ubuntu 18.04 도커 엔진(Docker Engine) 설치하기

최성훈 — Mon, 8 Jun 2020 03:11:28 +0900

본 포스트 이후 모든 글은 Ubuntu 18.04를 기준으로 포스팅할 예정이니 참고 바랍니다.

설치 전제조건 (Prerequisites)

도커 엔진을 설치하기 위해서는 다음 우분투 버전 중 64비트 버전이 필요합니다.

Ubuntu Focal 20.04 (LTS)
Ubuntu Eoan 19.10
Ubuntu Bionic 18.04 (LTS)
Ubuntu Xenial 16.04 (LTS)

이전 버전 설치 제거하기

도커의 이전 버전들은 docker, docker.io 또는 docker-engine으로 불립니다. 만약 이 버전들이 설치되어 있다면 삭제하시면 됩니다.

$ sudo apt-get remove docker docker-engine docker.io containerd runc

만약 apt-get 명령어가 아무 패키지도 설치되어 있지 않다고 해도 문제는 없습니다.

이전 버전을 삭제하더라도 /var/lib/docker/ 경로에 이미지, 컨테이너, 볼륨 그리고 네트워크를 포함한 내용은 보존됩니다. 이제 도커 엔진은 docker-ce로 불립니다.

도커 엔진 설치하기

설치 방법

우리는 도커 엔진을 우리가 원하는 방법에 따라 다르게 설치할 수 있습니다.

대부분의 사용자들은 쉬운 설치와 업그레이드 작업을 위해 도커의 레포지토리를 설정하고, 그 레포지토리로부터 설치합니다. 이 방법이 권장되는 방법입니다.
몇몇 사용자들은 데비안 패키지(DEB)를 다운로드하고 수동으로 도커 엔진을 설치하고, 완전히 수동으로 업그레이드를 관리합니다. 이 방법은 물리적으로 인터넷 접근이 불가능한 에어갭 시스템에 도커를 설치하는 것과 같은 상황에서 유용합니다.
테스트 환경과 개발 환경에서 사용자들은 도커 엔진을 설치하기 위해 자동화된 편리한 스크립트를 사용하는 것을 선택할 수도 있습니다.

저는 첫 번째 방법으로 도커 엔진을 설치하도록 하겠습니다.

레포지토리를 사용하여 설치하기

새로운 호스트 머신에 도커 엔진을 처음 설치하기 전에, 도커 레포지토리를 설정해야 합니다. 그다음에 우리는 그 레포지토리로부터 도커를 설치하고 업데이트할 수 있습니다.

레포지토리 설정하기

apt 패키지 인덱스를 업데이트하고, apt가 HTTPS를 통해 레포지토리를 사용하기 위한 패키지를 설치합니다.
```
$ sudo apt-get update
$ sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
```

도커의 공식 GPG 키를 추가합니다.

$ sudo apt-get update
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

fingerprint의 마지막 8자리를 검색해서 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88의 fingerprint를 가진 키를 가졌다는 것을 확인합니다.

$ sudo apt-key fingerprint 0EBFCD88

pub   rsa4096 2017-02-22 [SCEA]
      9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
uid           [ unknown] Docker Release (CE deb) <docker@docker.com>
sub   rsa4096 2017-02-22 [S]

stable 레포지토리를 설정하기 위해 다음의 명령어를 사용하세요. nightly나 test 레포지토리를 추가하기 위해서는, 아래 명령어에서 stable 단어 뒤에 nightly 또는 test를 추가하세요.

주의: 아래의 lsb_release -cs 명령어는 xenial과 같은 우분투 배포 버전의 이름을 반환합니다. 가끔 Linux Mint와 같은 배포 버전에서는 $(lsb_release -cs) 부분을 부모 우분투 배포 버전으로 변경해야 합니다. 예를 들면, 만약 우리가 Linux Mint Tessa를 사용하고 있다면 bionic을 사용할 수 있습니다. 도커는 테스트하지 않거나 지원하지 않는 우분투 배포 버전에 대해서는 아무 보장도 하지 않습니다.
```
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
```

도커 엔진 설치하기

apt 패키지 인덱스를 업데이트하고, 가장 최신 버전의 도커 엔진과 containerd를 설치하세요. 특정 버전을 설치하려면 다음 단계로 넘어가세요.
```
$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io
```

특정 버전의 도커 엔진을 설치하기 위해, 레포지토리 내에 있는 설치 가능한 버전을 선택하고 설치하세요.

$ apt-cache madison docker-ce

  docker-ce | 5:18.09.1~3-0~ubuntu-xenial | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  docker-ce | 5:18.09.0~3-0~ubuntu-xenial | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  docker-ce | 18.06.1~ce~3-0~ubuntu       | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  docker-ce | 18.06.0~ce~3-0~ubuntu       | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  ...

두 번째 열의 문자열을 사용해서 특정 버전을 설치하세요, 예를 들면 5:18.09.1~3-0~ubuntu-xenial이 있습니다.

$ sudo apt-get install docker-ce= docker-ce-cli= containerd.io

hellow-world 이미지를 실행해서 도커 엔진이 정상적으로 설치되었는지 확인합니다.
```
$ sudo docker run hello-world
```
이 명령어는 테스트 이미지를 다운로드하고 컨테이너 내에서 실행시킵니다. 컨테이너가 실행될 때, 정보를 나타내는 메시지가 출력되고 종료됩니다.

이제 도커 엔진이 설치되고 실행 중입니다. 도커를 설치하면서 docker라는 사용자 그룹이 생성되었지만 어떤 사용자도 추가되지 않았습니다. 따라서 우리는 도커 명령어를 실행하기 위해 sudo 명령어를 사용해야 합니다.

Non-root 사용자로서 도커 관리하기

도커 데몬은 TCP 포트 대신에 Unix 소켓으로 바인딩합니다. 기본적으로 root 사용자가 Unix 소켓을 소유하고 있고, 다른 사용자들은 sudo 명령어를 사용해야만 접근할 수 있습니다. 도커 데몬은 항상 root 사용자로서 실행됩니다.

만약 sudo 명령어를 덧붙여서 도커 명령어를 실행하는 게 귀찮으시다면, docker라는 Unix 그룹을 생성하고 사용자를 추가하면 됩니다. 도커 데몬이 시작될 때, 도커 데몬은 docker 사용자 그룹의 사용자에 의해서 접근할 수 있는 Unix 소켓을 생성합니다.

도커 사용자 그룹은 root 사용자와 동일한 권한을 갖습니다. 시스템에 어떤 영향을 끼치는지 확인하려면 여기를 참조하세요.

docker 사용자 그룹을 생성합니다. (사용자 그룹이 존재하지 않는 경우)
```
$ sudo groupadd docker
```
현재 사용자를 docker 그룹에 추가합니다.
```
$ sudo usermod -aG docker $USER
```
그룹 사용자의 멤버 권한을 갱신하기 위해 로그아웃 후 다시 접속합니다.
만약 VM에서 테스트 중이라면, 변경 사항을 적용하기 위해 VM을 재부팅해야 할 수도 있습니다.
X Windows와 같은 데스크톱 리눅스 환경의 경우, 세션을 완전히 종료하고 다시 로그인하세요.
리눅스의 경우, 사용자 그룹에 변경사항을 적용하기 위해 다음의 명령어를 사용할 수 있습니다.
```
$ newgrp docker
```
sudo 명령어 없이 도커 명령어가 실행되는지 실행합니다.
```
$ docker run hello-world
```
만약 현재 사용자를 docker 그룹에 추가하기 전에 sudo 명령어를 사용해서 도커 명령어를 실행했다면, 아마 다음의 에러를 볼 수도 있습니다. 이 에러는 ~/.docker/ 경로가 sudo 명령어로 인해 잘못된 권한으로 생성되었다는 것을 의미합니다.
```
WARNING: Error loading config file: /home/user/.docker/config.json -
stat /home/user/.docker/config.json: permission denied
```
이 문제를 해결하기 위해, ~/.docker/ 디렉터리를 삭제하거나(디렉터리는 자동으로 다시 생성되지만, 개인 변경사항들은 모두 잃어버립니다), 다음의 명령어로 해당 디렉터리의 소유자와 권한을 변경합니다.
```
$ sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
$ sudo chmod g+rwx "$HOME/.docker" -R
```

References

본 포스트는 다음 주소를 참조하였습니다.

https://docs.docker.com/engine/install/ubuntu/

[Docker] 도커란?

최성훈 — Sat, 6 Jun 2020 02:05:41 +0900

도커란?

도커(Docker)는 리눅스 컨테이너에 여러 기능을 추가함으로써 애플리케이션을 컨테이너로서 조금 더 쉽게 사용할 수 있게 만들어진 오프소스 프로젝트이다.

Go 언어로 작성돼 있으며, 2013년 3월에 처음 발표된 이후 지금까지 꾸준히 개발되고 있다.

일반적으로 도커라 함은, 도커 엔진(Docker Engine) 또는 도커에 관련된 모든 프로젝트를 의미하지만, 도커 엔진이라는 의미로 더 많이 사용된다. (도커 엔진은 컨테이너를 생성하고 관리하는 주체로서, 그 자체로도 컨테이너를 제어할 수 있고 다양한 기능을 제공하는 도커의 주 프로젝트이기 때문)

컨테이너(Container) vs. 가상 머신(Virtual Machine)

컨테이너와 가상 머신은 호스트 운영체제(Host OS) 위에서 가상화를 통한 격리 환경을 구성한다는 공통점이 있다.

하지만 격리 환경을 구성하기 위해 기술적인 차이가 있다. 두 가상화 기술의 차이점을 살펴보도록 하자.

좌: 컨테이너, 우: 가상머신

컨테이너 (Container)

컨테이너는 코드와 그 종속성들을 함께 패키징 하는 애플리케이션 계층의 추상화이다. 여러 컨테이너가 동일한 시스템에서 실행될 수 있고 OS 커널을 다른 컨테이너와 공유할 수 있으며, 각각은 사용자 공간에서 격리된 프로세스로 실행된다. 컨테이너는 VM보다 더 적은 공간을 차지하며(컨테이너 이미지의 크기는 일반적으로 수십 MB이다), 더 많은 애플리케이션을 처리할 수 있고, 더 적은 VM과 운영체제를 요구한다.

가상 머신 (Virtual Machine)

가상 머신(이하 VM)은 물리적 하드웨어를 추상화하여 한 개의 서버를 여러 서버로 전환하는 것이다. 하이퍼바이저(Hypervisor)를 통해 단일 시스템에서 여러 VM을 실행할 수 있다. 각 VM에는 운영체제, 애플리케이션, 필수적인 이진 파일과 라이브러리가 포함되며, 이는 수십 GB를 차지한다. VM은 부팅 속도 또한 느릴 수 있다.

위는 도커 공식 홈페이지에서 발췌하고 번역한 내용이다.

위의 설명만 읽었을 때에는 컨테이너와 가상 머신의 가장 큰 차이점은 애플리케이션의 경량화와 디스크 용량뿐이라고 느껴진다.

하지만 그뿐만 아니라, 컨테이너를 사용함으로써 다음과 같은 장점을 가질 수 있다.

일관된 환경
- 컨테이너는 호스트 OS 위에서 실행되는 격리된 공간이다. 따라서 컨테이너 자체에 특별한 권한을 주지 않는 이상, 컨테이너 내부의 작업은 호스트 OS에 영향을 끼치지 않는다. 즉, 호스트 OS에는 일관된 환경을, 컨테이너에는 독립된 환경을 보장받을 수 있다.
애플리케이션의 독립성 및 확장성
- 하나의 서비스는 여러 모듈이 상호작용하는 로직을 포함하고 있으며, 모든 로직을 하나의 프로그램에서 실행하는 것을 모놀리틱 애플리케이션(Monolithic Application)이라고 한다. 모놀리틱 애플리케이션은 서비스가 복잡해지고 커질수록 애플리케이션 자체의 확장성과 유연성이 줄어든다.
- 이러한 단점을 해결하기 위한 개념이 바로 마이크로서비스(Microservice) 구조이다. 마이크로서비스는 여러 모듈을 독립된 형태로 구성하기 때문에 언어에 종속되지 않고, 빠르고 쉽게 모듈을 관리하고 확장할 수 있다는 장점이 있다. 컨테이너는 빠른 시간 내에 생성 및 실행이 가능하며, 여러 모듈에게 독립적인 환경을 동시에 제공할 수 있기 때문에 마이크로서비스 구조에서 가장 많이 사용되는 가상화 기술이다.

좌: 모놀리틱 애플리케이션, 우: 마이크로서비스

References

본 포스트는 다음 주소를 참고하였습니다.

https://www.docker.com/resources/what-container

[백준 2309번] 일곱 난쟁이

최성훈 — Thu, 13 Feb 2020 18:37:52 +0900

문제 보기

이 문제는 브루트 포스 문제이다.

문제에서 의도하는 바는 9명의 난쟁이 중 키의 합이 100이 되는 7명의 난쟁이를 고르는 것이다. (가능한 경우의 수가 여러 개일 경우 한 가지만 출력한다.)

이제 웬만한 브루트 포스 문제는 막힘없이 풀 수 있는 것 같아서 조금 성장한 느낌이 든다.

문제를 푼 로직은 다음과 같다.

DFS를 재귀적으로 사용하여 각 난쟁이를 선택한 경우와 선택하지 않은 경우의 수를 모두 구한다. (19~25번째 줄)
모든 경우 중 한 가지 경우의 난쟁이들을 선택한 뒤, 선택한 난쟁이의 수가 7이고 키의 합이 100인 경우 선택된 난쟁이들의 키를 출력한다. (9~17번째 줄)

이 문제를 풀면서 한 가지 배운 점이 있다면, 한 개의 리스트를 출력할 때, 리스트의 원소마다 구분자를 설정하여 한 줄로 출력할 수 있다는 것이다.

이는 15번째 줄에 다음과 같이 나타나 있다.

print(*sorted(answer), sep='\n')

import sys

dwarf_list = [int(sys.stdin.readline()) for _ in range(9)]
dwarf_check = [0 for _ in range(9)]
answer = []


def dfs(n, count, sum_height):
	if n == 9:
		if count == 7 and sum_height == 100:
			for idx, v in enumerate(dwarf_check):
				if v:
					answer.append(dwarf_list[idx])
			
			print(*sorted(answer), sep='\n')
			sys.exit(0)
		return

	# select a dwarf
	dwarf_check[n] = 1
	dfs(n + 1, count + 1, sum_height + dwarf_list[n])
	
	# don't select a dwarf
	dwarf_check[n] = 0
	dfs(n + 1, count, sum_height)


dfs(0, 0, 0)

[백준 6588번] 골드바흐의 추측

최성훈 — Tue, 11 Feb 2020 16:06:28 +0900

문제 보기

이 문제는 수학 문제이고, 에라토스테네스의 체가 필요하다.

문제가 요구하는 것은 말 그대로 골드바흐의 추측을 검증하는 것이다.

골드바흐의 추측이란 다음과 같다.

4보다 큰 모든 짝수는 두 홀수 소수의 합으로 나타낼 수 있다.

주어진 범위 내에 이 추측을 검증하기만 하면 된다.

문제를 푼 로직은 다음과 같다.

에라토스테네스의 체로 주어진 범위 내의 모든 소수를 구한다. (5~18번째 줄)
숫자 n을 입력받고 합이 n을 이루는 소수 a, b를 구한다. 두 소수 a, b를 찾았다면 "n = a + b"를 출력한다. (26~33번째 줄)
두 소수 a, b를 찾지 못했다면 "Goldbach's conjecture is wrong."을 출력한다. (35~36번째 줄)

이 문제가 생각보다 까다로운 점은 시간 초과에 있다.

여러 가지 이유로 시간 초과가 날 수 있는데, 내가 제거한 시간 초과 요인들은 다음과 같다. (여기를 참고)

에라토스테네스의 체
- 에라토스테네스의 체는 주어진 수 n까지 선형 탐색을 통해 모든 수에 대해서 소수 판별을 한다. 따라서 숫자를 입력받을 때마다 에라토스테네스의 체를 사용할 필요가 없이 입력값의 경계인 1000000을 포함하는 범위, 즉 1000001까지 한 번만 사용하면 된다. (18번째 줄)
소수 판정 범위
- 숫자 n의 소수 판정을 위해서 2부터 차례대로 n까지 나눗셈을 할 필요가 없다. n까지 나눗셈을 할 경우 O(n^2)의 시간 복잡도가 나오게 된다. sqrt(n)까지만 나누어줘도 소수 판정을 할 수 있다 (9번째 줄)
소수의 조합
- 합이 n인 두 소수 a, b를 구하기 위해 에라토스테네스의 체로 구한 소수들의 모든 조합을 구할 필요가 없다. 모든 조합을 구할 경우 O(n^2)의 시간 복잡도가 나오게 된다. n = a + b를 활용하여 선형 시간 안에 두 소수 a, b의 조합을 구할 수 있다. (28~30번째 줄)

import sys
from math import sqrt


# implementation of Sieve of Eratosthenes
def eratosthenes(n):
	sieve = [True for _ in range(n)]
	
	for i in range(2, int(sqrt(n)) + 1):
		if sieve[i]:
			for j in range(i * i, n, i):
				sieve[j] = False
				
	return sieve


# run only once
prime_list = eratosthenes(1000001)

while True:
	n = int(sys.stdin.readline())
	if n == 0:
		break
	found = False
	
	# for linear search
	for a in range(2, 1000001):
		if prime_list[a]:
			b = n - a
			if prime_list[b]:
				found = True
				print("{0} = {1} + {2}".format(n, a, b))
				break
	
	if not found:
		print("Goldbach's conjecture is wrong.")

[백준 1978번] 소수 찾기

최성훈 — Tue, 11 Feb 2020 02:40:11 +0900

문제 보기

import sys
from math import sqrt

n = int(sys.stdin.readline())
numbers = list(map(int, sys.stdin.readline().split()))


def is_prime(value):
	if value == 1:
		return False
	
	for i in range(2, int(sqrt(value) + 1)):
		if value % i == 0:
			return False
		
	return True


answer = 0
for i in numbers:
	if is_prime(i):
		answer += 1
print(answer)

[Java] Java 8 변경사항

최성훈 — Sun, 9 Feb 2020 03:45:51 +0900

Java 8 변경사항

2014년에 발표된 Java SE(Standard Edition) 8 버전에서는 다음과 같은 주요 변경사항이 있습니다.

람다 표현식 (Lambda expression): 함수형 프로그래밍이 가능하게 됨
스트림 API (Stream API): 데이터를 추상화하여 다룰 수 있게 됨
java.time 패키지: 더 직관적이고 개선된 Date, Time API를 제공
나즈혼 (Nashorn): 자바스크립트의 새로운 엔진을 도입

각 변경사항들의 특징에 대해서 살펴보겠습니다.

람다 표현식 (Lambda Expression)

람다 표현식(Lambda Expression)이란?

람다 표현식이란 익명 클래스의 한 개의 메소드를 식으로 표현한 것입니다. 여기서 익명 클래스란 말 그대로 이름이 없는 클래스로써, 단 한 개의 객체만을 생성할 수 있는 일회용 클래스입니다. (자바는 클래스의 선언과 동시에 객체를 생성하기 때문에 이름이 없으면 선언되는 그 순간에만 사용될 수 있습니다.)

익명 클래스의 예

new Object()
{
    int min(int x, int y)
    {
        return x < y ? x : y;
    }
}

람다 표현식의 예

(x, y) -> x < y ? x : y;

이러한 람다 표현식은 매개변수로 전달될 수도 있으며, 메소드의 결괏값으로 반환될 수도 있습니다. 따라서 람다 표현식을 사용하면 기존의 불필요한 코드를 줄여주고, 작성된 코드의 가독성을 높여줍니다. Java SE 8부터는 이러한 람다 표현식을 사용하여 자바에서도 함수형 프로그래밍을 할 수 있게 되었습니다.

람다 표현식 작성법

자바에서는 화살표(->) 기호를 사용하여 람다 표현식을 작성할 수 있습니다. 문법은 다음과 같습니다.

(매개변수 목록) -> {함수 몸체}

자바에서 람다 표현식을 사용할 때 주의할 점은 다음과 같습니다.

매개변수가 한 개인 경우 ()를 생략할 수 있습니다.
함수 몸체가 한 개의 명령문으로만 이루어진 경우에는 {}를 생략할 수 있습니다.
함수 몸체가 한 개의 return 문으로만 이루어진 경우에는 {}를 생략할 수 없습니다.

다음은 전통적인 스레드 생성 방식과 람다 표현식을 사용한 스레드 생성 방식을 비교하는 예제입니다.

new Thread(new Runnable()
{
	public void run()
    {
    	System.out.println("전통적인 방식의 스레드 생성");
    }
}).start();


new Thread(()->{
	System.out.println("람다 표현식을 사용한 스레드 생성");
}).start();

위의 예제에서 볼 수 있듯이, 매개변수로 정의된 Runnable() 인터페이스와 run() 추상 메소드를 람다 표현식을 사용하여 더 간결하게 구현한 것을 알 수 있습니다.

함수형 인터페이스 (Functional Interface)

함수형 인터페이스란 람다 표현식을 하나의 변수에 대입할 때 사용하는 참조 변수의 타입을 의미합니다. 함수형 인터페이스는 추상 클래스와 달리 단 한 개의 추상 메소드만을 가져야 합니다. 또, 다음과 같은 어노테이션(annotation)을 사용하여 함수형 인터페이스임을 명시할 수 있습니다.

@FunctionalInterface

위와 같은 어노테이션을 인터페이스의 선언 위에 붙이면, 컴파일러는 해당 인터페이스를 함수형 인터페이스로 인식합니다.

다음은 함수형 인터페이스의 예제입니다.

// 함수형 인터페이스 구현
@FunctionalInterface
interface ExampleInterface
{
	public int doSomething(int x, int y);
}

public class test
{
	public static void main(String[] args)
	{
		ExampleInterface implemented = (x, y) -> x + y;		// 추상 메소드 구현
		System.out.println(implemented.doSomething(10, 11));	// 21을 출력함
	}
}

위의 예제에서 볼 수 있듯이, implemented 변수는 람다 표현식으로 구현된 객체를 가리키고 있습니다. implemented 변수는 구현된 함수형 인터페이스 내의 doSomething() 메소드를 실행할 때마다, 람다 표현식으로 구현한 추상 메소드를 실행합니다.

스트림 API (Stream API)

스트림 API(Stream API)란?

자바에서는 여러 개의 데이터를 저장하기 위해서 배열이나 컬렉션을 사용합니다. 그리고 이렇게 저장된 데이터에 접근하기 위해서는 반복문이나 반복자(iterator)를 사용하여 매번 코드를 작성해야 했습니다.

하지만 이렇게 작성된 코드는 길이가 길고 가독성도 떨어지며, 코드의 재사용이 거의 불가능합니다. 또한, 정형화된 처리 패턴을 가지지 못했기 때문에 데이터마다 다른 방법으로 접근해야만 했습니다.

이러한 문제점을 극복하기 위해서 도입된 방법이 스트림 API입니다. 스트림 API는 데이터를 추상화해서 다루므로, 다양한 형태로 저장된 데이터를 위한 공통된 방법을 제공합니다. 따라서 스트림 API를 사용하면 배열이나 컬렉션 뿐만아니라 파일에 저장된 데이터도 모두 같은 방법으로 다룰 수 있습니다.

스트림 API의 특징

스트림 API는 다음과 같은 특징을 가집니다.

스트림은 외부 반복을 통해 작업하는 컬렉션과는 다르게 내부 반복을 통해 작업을 수행합니다.
스트림은 단 한번만 사용할 수 있습니다. (= 재사용이 불가능합니다.)
스트림은 원본 데이터를 변경하지 않습니다.
스트림의 연산은 필터-맵(filter-map) 기반의 API를 사용하여 lazy 연산을 통해 성능을 최적화합니다.
스트림은 parallelStream() 메소드를 통해 간단한 병렬처리를 지원합니다.

다음은 스트림 API의 예제입니다.

// 정수형 배열에서 스트림 생성
Integer[] arr1 = new Integer[] {1, 5, 11, 13, 20, 52};
Stream stream1 = Arrays.stream(arr1);
stream1.map(i -> i * 2);
stream1.filter(i -> i % 2 == 0);			// 재사용이 불가능하기 때문에 에러 발생!


// 정수형 배열에서 스트림 생성
Integer[] arr2 = new Integer[] {1, 5, 11, 13, 20, 52};
Stream stream2;
stream2 = Arrays.stream(arr2)
                .filter(i -> i % 2 != 0)	// {1, 5, 11, 13}
                .map(i -> i * 2);			// {2, 10, 22, 26}

스트림 API는 다음과 같이 세 가지 단계에 걸쳐서 동작합니다.

스트림 생성
스트림 중개 연산 (filter)
스트림 최종 연산 (map)

위의 예제에서 필터-맵이 동작하는 순서는 다음과 같습니다.

스트림 API의 흐름

java.time 패키지

JDK 1.0에서는 Date 클래스를 사용하여 날짜에 관한 연산을 수행했습니다. 하지만 현재는 Date 클래스의 대부분의 메소드는 사용을 권장하지 않습니다. (deprecated) JDK 1.1부터 제공된 Calendar 클래스는 날짜와 시간에 대한 정보를 쉽게 얻을 수 있었습니다. 하지만 Calendar 클래스는 다음과 같은 문제점을 가지고 있습니다.

Calendar 인스턴스는 immutable object가 아니라서 값이 수정될 수 있습니다.
윤초(leap second)와 같은 특별한 상황을 고려하지 않습니다.
Calendar 클래스에서는 월(month)을 나타낼 때 1~12가 아닌 0~11로 표현해야합니다.

따라서 많은 개발자들은 Calendar 클래스뿐만 아니라 더 나은 성능의 Joda-Time이라는 라이브러리를 함께 사용해왔습니다. Java SE 8 버전에서는 이러한 Joda-Time 라이브러리를 발전시킨 새로운 날짜/시간 API인 java.time 패키지를 제공합니다. java.time 패키지는 위와 같은 문제점을 모두 해결했으며, 다양한 기능을 지원하는 하위 패키지를 포함하고 있습니다.

다음은 java.date 패키지의 예입니다.

LocalDate today = LocalDate.now();
System.out.println("올해는" + today.getYear() + "년입니다.");

LocalDate otherDay = today.withYear(1982);
System.out.println("올해는" + otherDay.getYear() + "년입니다.");

나즈혼 (Nashorn)

지금까지 자바스크립트의 기본 엔진으로는 모질라의 라이노 (Rhino)가 사용되어 왔습니다. 하지만 세월이 흐르면서 자바의 최신 개선 사항 등을 제대로 활용하지 못하는 등 노후화 된 모습을 보여주게 됩니다.

따라서 Java SE 8 버전부터는 자바스크립트의 새로운 엔진으로 오라클의 나즈혼 (Nashorn)을 도입하게 됩니다. 나즈혼은 기존에 사용되어 온 라이노에 비해 성능과 메모리 관리 측면에서 크게 개선된 스크립트 엔진입니다.

[백준 9613번] GCD 합

최성훈 — Thu, 6 Feb 2020 16:21:20 +0900

문제 보기

import sys
from math import gcd

t = int(sys.stdin.readline())
for _ in range(t):
	line = list(map(int, sys.stdin.readline().split()))
	n, numbers = line[0], line[1:]
	
	answer = 0
	for i in range(n - 1):
		for j in range(i + 1, n):
			answer += gcd(numbers[i], numbers[j])
	print(answer)

[백준 5373번] 큐빙

최성훈 — Mon, 3 Feb 2020 02:23:57 +0900

문제 보기

import sys


def get_plain_index(p):
	if p == 'U':
		return 0
	elif p == 'L':
		return 1
	elif p == 'F':
		return 2
	elif p == 'R':
		return 3
	elif p == 'B':
		return 4
	elif p == 'D':
		return 5


def rotate(p, d):
	global cube
	idx = get_plain_index(p)
	
	if d == '-':
		# rotate plain
		cube[idx] = list(reversed(list(map(list, zip(*cube[idx])))))
		
		if p == 'U':
			cube[1][0], cube[2][0], cube[3][0], cube[4][0] = cube[4][0], cube[1][0], cube[2][0], cube[3][0]
		elif p == 'D':
			cube[1][2], cube[2][2], cube[3][2], cube[4][2] = cube[2][2], cube[3][2], cube[4][2], cube[1][2]
		elif p == 'F':
			temp = cube[0][2]
			cube[0][2] = list(map(list, zip(*cube[3])))[0]
			cube[3][0][0], cube[3][1][0], cube[3][2][0] = list(reversed(cube[5][0]))
			cube[5][0] = list(map(list, zip(*cube[1])))[2]
			cube[1][0][2], cube[1][1][2], cube[1][2][2] = list(reversed(temp))
		elif p == 'B':
			temp = cube[0][0]
			cube[0][0] = list(reversed(list(zip(*cube[1]))[0]))
			cube[1][0][0], cube[1][1][0], cube[1][2][0] = cube[5][2]
			cube[5][2] = list(reversed(list(zip(*cube[3]))[2]))
			cube[3][0][2], cube[3][1][2], cube[3][2][2] = temp
		elif p == 'L':
			temp = list(zip(*cube[0]))[0]
			cube[0][0][0], cube[0][1][0], cube[0][2][0] = list(map(list, zip(*cube[2])))[0]
			cube[2][0][0], cube[2][1][0], cube[2][2][0] = list(map(list, zip(*cube[5])))[0]
			cube[5][0][0], cube[5][1][0], cube[5][2][0] = list(reversed(list(zip(*cube[4]))[2]))
			cube[4][0][2], cube[4][1][2], cube[4][2][2] = list(reversed(temp))
		elif p == 'R':
			temp = list(map(list, zip(*cube[0])))[2]
			cube[0][0][2], cube[0][1][2], cube[0][2][2] = list(reversed(list(zip(*cube[4]))[0]))
			cube[4][0][0], cube[4][1][0], cube[4][2][0] = list(reversed(list(zip(*cube[5]))[2]))
			cube[5][0][2], cube[5][1][2], cube[5][2][2] = list(map(list, zip(*cube[2])))[2]
			cube[2][0][2], cube[2][1][2], cube[2][2][2] = temp
	elif d == '+':
		# rotate plain
		cube[idx] = list(map(list, zip(*reversed(cube[idx]))))
		
		if p == 'U':
			cube[1][0], cube[2][0], cube[3][0], cube[4][0] = cube[2][0], cube[3][0], cube[4][0], cube[1][0]
		elif p == 'D':
			cube[1][2], cube[2][2], cube[3][2], cube[4][2] = cube[4][2], cube[1][2], cube[2][2], cube[3][2]
		elif p == 'F':
			temp = cube[0][2]
			cube[0][2] = list(reversed(list(zip(*cube[1]))[2]))
			cube[1][0][2], cube[1][1][2], cube[1][2][2] = cube[5][0]
			cube[5][0] = list(reversed(list(zip(*cube[3]))[0]))
			cube[3][0][0], cube[3][1][0], cube[3][2][0] = temp
		elif p == 'B':
			temp = cube[0][0]
			cube[0][0] = list(map(list, zip(*cube[3])))[2]
			cube[3][0][2], cube[3][1][2], cube[3][2][2] = list(reversed(cube[5][2]))
			cube[5][2] = list(map(list, zip(*cube[1])))[0]
			cube[1][0][0], cube[1][1][0], cube[1][2][0] = list(reversed(temp))
		elif p == 'L':
			temp = list(map(list, zip(*cube[0])))[0]
			cube[0][0][0], cube[0][1][0], cube[0][2][0] = list(reversed(list(zip(*cube[4]))[2]))
			cube[4][0][2], cube[4][1][2], cube[4][2][2] = list(reversed(list(zip(*cube[5]))[0]))
			cube[5][0][0], cube[5][1][0], cube[5][2][0] = list(map(list, zip(*cube[2])))[0]
			cube[2][0][0], cube[2][1][0], cube[2][2][0] = temp
		elif p == 'R':
			temp = list(zip(*cube[0]))[2]
			cube[0][0][2], cube[0][1][2], cube[0][2][2] = list(map(list, zip(*cube[2])))[2]
			cube[2][0][2], cube[2][1][2], cube[2][2][2] = list(map(list, zip(*cube[5])))[2]
			cube[5][0][2], cube[5][1][2], cube[5][2][2] = list(reversed(list(zip(*cube[4]))[0]))
			cube[4][0][0], cube[4][1][0], cube[4][2][0] = list(reversed(temp))


# for all test cases
t = int(sys.stdin.readline())
for _ in range(t):
	cube = [
		[['w' for c in range(3)] for r in range(3)],
		[['g' for c in range(3)] for r in range(3)],
		[['r' for c in range(3)] for r in range(3)],
		[['b' for c in range(3)] for r in range(3)],
		[['o' for c in range(3)] for r in range(3)],
		[['y' for c in range(3)] for r in range(3)],
	]

	# for all operations
	n = int(sys.stdin.readline().strip())
	command_list = sys.stdin.readline().strip().split()
	for command in command_list:
		plain, direction = map(str, [c for c in command])
		rotate(plain, direction)

	for r in cube[0]:
		print(''.join(r))

[운영체제] 가상 메모리 관리

최성훈 — Sun, 2 Feb 2020 06:31:32 +0900

Virtual Memory Management (가상 메모리 관리)

가상 메모리란 메모리 내에 완전히 존재하지 않는 프로세스를 실행하는 기술을 의미한다. 프로그램의 인스트럭션들은 실행되기 위해서 메모리에 로드되어야 하지만, 프로그램 전체가 필요한 것은 아니다. 만약 그렇다 하더라도, 동시에 프로그램 전체를 사용하지는 않는다. 즉, 프로그램이 CPU에 의해 실제로 사용되는 부분만 메모리로 로드하고, 사용되지 않는 부분은 디스크로 옮겨서 실제 메모리를 대체하도록 하는 것이다.

프로그램의 일부만 메모리로 로드하여 실행하는 것은 다음과 같은 장점이 있다.

물리 메모리의 크기에 제한받지 않는다.
더 많은 프로그램이 동시에 실행될 수 있다. (CPU utilization 증가)
페이지 테이블 전체를 읽을 필요가 없기 때문에 프로그램을 Load/Swap 하기 위한 I/O 연산이 줄어든다.

Demand Paging (요구 페이징)

요구 페이징이란 프로세스를 구성하는 페이지 전체를 메모리로 적재하는 것이 아니라, 당장 필요한 페이지만 메모리에 적재하는 기술이다. 프로세스 내에서 한 번도 접근되지 않은 페이지는 절대로 메모리에 로드되지 않는다.

요구 페이징의 기본적인 개념으로 디스크의 페이지를 메모리로 적재할 때, Pager는 어떤 페이지가 사용될지 예측하고 메모리로 적재시킨다. 이때, 이미 메모리에 적재되어있는 페이지와 디스크에 있는 페이지를 구분해야 한다. 이를 위해서 valid-invalid bit를 사용한다.

프로세스가 3개의 페이지만을 사용할 때의 상황

위의 그림에서 프로세스는 A~H를 다 쓴다고 생각하지만, 실제로 메모리에는 A, C, F만 로드되어 있다. 이때 페이지 테이블에 존재하지 않는 페이지에 프로세스가 접근하게 된다면 디스크에서 해당하는 페이지를 메모리로 로드하고, 페이지 테이블을 업데이트한다.

Page Fault (페이지 부재)

페이지 부재는 프로세스가 메모리에 존재하지 않는 페이지에 접근하려고 할 때 발생한다.

Page Fault의 예

Copy-on-Write (COW)

fork() system call을 사용하면 자식 프로세스는 부모 프로세스를 복제한다. 즉, 프로세스를 복제하므로 부모와 자식 프로세스에 해당하는 메모리 내의 페이지 또한 중복된다. 게다가 fork() system call을 사용하면 대부분 exec() system call을 호출하기 때문에, 자식 프로세스는 제거되고 중복된 페이지 또한 메모리에서 해제되는데, 이는 운영체제 관점에서 매우 낭비적인 행위이다.

COW(Copy-on-Write)는 이러한 페이지의 불필요한 중복을 줄이는 방법이다. fork()를 통해 부모 프로세스가 소유하고 있던 메모리 영역은 모두 'copy-on-write'로 표시가 된다. 만약 자식 프로세스가 공유된 부모 프로세스의 페이지들 중 어떤 페이지라도 수정을 한다면 그때 페이지를 복사하여 수정한 후, 수정된 페이지를 메모리에 따로 저장한다.

COW(Copy-on-Write)의 예

COW의 장점은 자식 프로세스가 메모리에 로드된 페이지를 수정할 때에만 복사하기 때문에 기존의 fork()를 사용하여 페이지 전체를 복사할 때보다 빠르다.

Page Replacement (페이지 교체)

멀티 프로그래밍의 degree를 증가시키기 위해 프로세스를 계속 실행하다보면 Page over-allocation이 발생한다. 예를 들어 메모리에 프레임이 20개 있고, 한 개의 프로세스당 5개의 페이지가 필요하다면 총 4개의 프로세스가 동작할 수 있다. 하지만 어떤 프로세스가 추가적인 페이지가 필요하게 되면 Page Fault가 발생하고, 이를 해결하기 위해 디스크로부터 적절한 페이지를 찾아서 메모리로 적재시키려고 한다. 하지만 이 때 메모리에 남는 공간이 없으므로 이에 대한 해결책이 필요하다.

기본적인 Page Replacement (페이지 교체)

기본적인 페이지 교체의 예

기본적인 페이지 교체 방식은 메모리 내에서 교체될 victim 페이지를 선택하여 swap-out하고, 사용할 페이지를 디스크로부터 swap-in 한다. 이 때 페이지 테이블 내의 valid-invalid 비트를 사용한다. 하지만 이는 swap-in & swap-out을 위해 디스크에 2번 접근해야하기 때문에 매우 느리다. 따라서 우리는 modify-bit를 사용한다.

Modify-bit는 하드웨어적으로 구현하며, 해당 페이지가 최근에 변경된 적이 있으면 1로 설정하고, 변경된 적이 없으면 0으로 설정한다. Swap-out을 수행하면서 만약 해당 페이지의 modify-bit가 0이라면(= 최근에 사용된 적이 없다면) 그대로 버리고, 1이라면 disk에 저장한다. 이와 같이 Modify-bit를 사용한 방법은 I/O 연산을 절반정도 줄일 수 있다.

Page Replacement는 적을수록 좋다. 왜냐하면 디스크와 관련된 I/O 연산이 줄어들기 때문에 응답시간이 더 짧아지기 때문이다.

FIFO Page Replacement

FIFO 페이지 교체는 가장 간단한 페이지 교체 알고리즘이며, 메모리 내에서 가장 오래된 페이지를 victim으로 선택하여 교체하는 방법이다. 항상 최적의 결과를 가져다주진 않지만, 동작은 올바르게 한다는 것이 보장된다.

FIFO Page Replacement의 예. 파란색 원은 교체된 페이지를 나타내며, 총 15번의 페이지 교체가 발생한다.

메모리 내의 프레임의 갯수가 증가할 수록 Page Fault가 줄어드는 것이 이상적이지만, FIFO 페이지 교체에서는 프레임의 갯수가 늘어남에도 불구하고 Page Fault가 증가하는 경우가 존재한다. 이를 Belady's anomaly라고 한다.

Optimal Page Replacement

Optimal 페이지 교체는 가장 오랫동안 사용되지 않을 페이지를 교체하는 방법이다. Page Fault가 가장 적다는 것이 보장되며 Belady's anomaly도 일어나지 않는다. 하지만 미래의 페이지에 대한 정보가 필요하기 때문에 실제로 구현하기는 어렵다. (프로세스 스케줄링의 SJF와 비슷하다)

Optimal Page Replacement의 예. 총 9번의 페이지 교체가 발생한다.

LRU Page Replacement (LRU: Least Recently Used)

Optimal 페이지 교체가 실제로 구현하기 어렵기 때문에 우리는 Optimal 페이지 교체 알고리즘의 Approximation을 사용한다. 과거의 정보를 사용하여 미래의 대한 정보를 추정한다. 즉, LRU 페이지 교체는 최근에 사용한 페이지 중에서 가장 오래된 페이지를 victim으로 선택하는 방법이다.

LRU Page Replacement의 예. 12번의 페이지 교체가 발생한다.

LRU 페이지 교체를 구현하기 위해 하드웨어를 사용한 다음의 두 가지 방법이 있다.

Counter
- CPU에 클럭 레지스터를 추가한다. 이 레지스터는 메모리에 엑세스 할 때마다 증가한다.
- 페이지를 참조할 때마다 클럭 레지스터의 값이 페이지 테이블의 'time-of-use' 필드에 저장된다. 이렇게 함으로써 우리는 레지스터의 값을 통해 가장 최근에 페이지를 참조한 시간을 알 수 있다.
- 페이지 교체 시, 참조된 횟수가 가장 적은(time-of-use 값이 가장 작은) 페이지를 선택하여 교체한다.
- 단점
  - 페이지 테이블 내의 모든 값을 비교해야 하기 때문에 full search에 대한 오버헤드가 발생한다.
  - 페이지 테이블을 수정할 때 클럭 레지스터의 값이 유지되어야 한다.
  - 클럭 레지스터에 대한 overflow를 고려해야 한다.
Stack
- 페이지들을 관리할 스택을 사용하며, 이는 doubly-linked 리스트로 구현되어 있다.
- 스택의 바닥에 있는 페이지가 무조건 victim이다.
- 페이지가 참조될 때마다 스택에서 제거되고 다시 스택의 top으로 push된다. 따라서 가장 최근에 사용된 페이지는 스택의 top에 위치하게 된다.
- 단점
  - 페이지를 참조할 때마다 스택 내 페이지들의 위치 이동에 대한 오버헤드가 존재한다.

Counting-based Page Replacement

Counting-based 페이지 교체는 페이지를 사용할 때마다 횟수를 기록하는 방법이다. 이 방법에는 다음과 같이 두 가지가 존재한다.

LFU (Least Frequently Used)
- 카운트 값이 가장 작은 페이지를 victim으로 지정하고 교체하는 방법이다.
- 문제점
  - 앞으로 많이 사용할 페이지가 들어오더라도, 적은 횟수를 가지고 있기때문에 victim이 될 수 있다.
  - 초기에 많이 사용되고 더이상 사용하지 않을 페이지가 메모리에 남아있을 수 있다.
MFU (Most Frequently Used)
- 가장 최근에 사용된 페이지는 카운팅 횟수가 적을 것이라는 판단 하에, 카운트 값이 가장 큰 페이지를 victim으로 지정하고 교체하는 방법이다.

LRU Approximation 알고리즘

위에서 우리는 counter와 stack을 사용한 LRU 페이지 교체를 살펴보았다. 하지만 현실에서는 이를 구현하기 위해 완벽하게 하드웨어를 지원하는 시스템은 거의 존재하지 않는다. 따라서 우리는 reference-bit를 사용한다.

Reference bit
- 페이지에 접근할 때마다 하드웨어에 의해서 설정된다.
- 운영체제에 의해 초기값은 모두 0으로 설정된다.
- 우리는 reference bit를 통하여 어떤 페이지가 참조되었는지 알 수 있지만, 참조된 순서는 알 수 없다.

Additional-Reference-Bits 알고리즘

Additional-Reference-Bits 알고리즘은 페이지 테이블의 페이지마다 8비트의 reference bit를 가지며, 특정 시간 간격마다 reference bit의 값을 기록한다. Reference bit의 값을 기록할 때는 기존의 값을 right shift 하고, MSB에 reference bit의 값을 기록한다. 이 비트값을 사용하여 페이지를 사용한 시간으로 해석할 수 있으며, 비트값이 가장 작은 페이지가 victim이 된다. 하지만 단점으로는 가장 작은 비트값이 두 개 이상 존재할 수도 있다.

특정 시간 간격마다 기록되는 Reference bit

Second-Chance 알고리즘

Second-Chance 알고리즘은 이름 그대로 두 번의 기회를 주는 것이다. 기본적으로 reference bit가 0인 페이지를 victim으로 선택하며, reference bit가 1인 경우에는 0으로 설정하고 페이지에 접근한 시간을 업데이트한다. 그 후에 페이지를 교체하지 않고 다음 페이지부터 다시 탐색을 시작한다. 만약 모든 reference bit가 1인 경우에는 FIFO 페이지 교체와 같아진다.

Seconde-Chance 알고리즘은 주로 circular 큐를 사용하여 구현된다.

Second Chance 알고리즘의 예

Enhanced Second-Chance 알고리즘

Enhanced Second-Chance 알고리즘은 reference bit만 고려하는게 아니라, modify bit도 추가하여 함께 고려한다. Reference bit는 페이지를 참조할 때 기록되는 반면, modify bit는 페이지의 내용을 수정할 때 기록된다. 우리는 페이지의 상태를 알기 위해 이 두 개의 비트를 가지고 다음과 같이 페이지 상태를 나타낼 수 있다.

(Reference bit, Modify bit)
- (0, 0): Second-Chance 알고리즘을 통해 참조한 지 오래되었지만, 값이 수정된 적이 없음 (BEST)
- (0, 1): Second-Chance 알고리즘을 통해 참조한 지 오래되었지만, 값이 수정되었음
- (1, 0): 최근에 참조되었으며, 값이 수정된 적이 없음
- (1, 1): 최근에 참조되었으며, 값이 수정되었음

Enhanced Second-Chance 알고리즘은 위의 값들 중에서, 가장 낮은 값을 victim으로 선택하며, 최대 3번의 순회를 통해 victim을 구할 수 있다. 방법은 다음과 같다.

상태가 (0, 0)인 페이지를 찾아서 교체한다.
첫 번째 순회에서 victim 페이지를 찾지 못했다면 상태가 (0, 0)과 (0, 1)인 페이지를 찾아서 교체한다. 순회하면서 reference bit는 모두 0으로 만든다.
두 번째 순회에서 victim 페이지를 찾지 못했다면 페이지의 상태는 모두 (0, 0) 또는 (0, 1)만 남게된다. 그럼 다시 상태가 (0, 0)인 페이지를 찾아서 교체한다.

위와 같은 방법으로 victim 페이지를 찾으면 적어도 세 번째 순회가 끝날 때에는 모든 페이지의 상태가 (0, 0)이 되므로 victim을 찾을 수 있다.

Thrashing (쓰레싱)

우리는 프로세스에게 메모리 공간을 할당할 때 다음과 같은 이슈가 있다.

시스템이 요구하는 최소의 프레임
프로세스에게 메모리를 할당하는 방법 (균등하게 vs 상대적으로 다르게)
Global replacement vs. Local replacement
- Global replacement: victim을 찾을 때 메모리 전체에서 찾겠다.
- Local replacement: victim을 찾을 때 해당 프로세스가 소유한 프레임 중에서 찾겠다.

만약 프로세스를 실행하기 위한 충분한 프레임을 지속적으로 확보하지 못한다면 Page Fault는 급격하게 증가할 것이고, 이를 Thrashing이라 한다. Thrashing을 일으키는 시나리오는 다음과 같다.

멀티프로그래밍의 degree를 증가시킨다.
한 개의 프로그램이 추가적인 프레임을 요구하고, 이를 해결하기 위해 전역적으로 페이지를 교체한다.
다른 프로그램 또한 추가적인 프레임을 요구하게 되고, Page Fault가 발생한다.
Page Fault가 증가함에따라 디스크 I/O 작업이 증가하기 때문에 CPU utilization이 감소한다.
CPU 스케줄러는 CPU utilization이 감소하였기 때문에, 이를 보완하기 위해 다시 멀티프로그래밍의 degree를 증가시킨다.

Thrashing을 나타내는 그래프

[Java] JVM이란?

최성훈 — Thu, 30 Jan 2020 03:13:08 +0900

JVM이란?

JVM이란 Java Virtual Machine의 약자이다. 즉, 자바 애플리케이션을 실행하기 위한 가상 머신이다. JVM은 컴파일된 자바의 소스코드를 읽어 들이고, Java API를 통하여 운영체제와 Java의 중간자 역할로써 운영체제마다 다른 system call을 사용하여 운영체제가 다르더라도 동일한 연산을 수행할 수 있다.

자바 프로그램의 실행 과정

자바 프로그램의 실행 과정은 다음과 같다.

Java 컴파일러는 소스코드(.java)를 읽어서 바이트 코드(.class)로 변환한다.
Class Loader는 변환된 바이트 코드(.class)를 JVM의 Runtime Data Area로 로딩한다.
Exeuction Engine은 로딩된 바이트 코드(.class)를 해석한다. (해석하는 방법에는 Interpreter와 JIT Compiler 두 가지 방식이 있다.)
필요에 따라 Thread Synchronization과 Garbage Collection이 이루어진다.

Class Loader (클래스 로더)

Java는 동적으로 클래스를 읽어오므로, 프로그램이 실행되는 런타임에서야 프로그램의 모든 코드가 JVM의 Runtime Data Area로 로딩&링킹 된다. 이러한 역할을 하는 것이 Class Loader이다.

Runtime Data Area (런타임 데이터 영역)

Runtime Data Area는 JVM이 운영체제 위해서 프로그램을 실행하기 위해 할당받는 메모리 영역이다. 런타임 데이터 영역은 다음과 같이 5가지 영역으로 나뉠 수 있다.

스레드가 공유하는 영역
- Heap
  - new 명령어로 생성된 모든 객체와 배열이 저장되는 공간. Garbage Collection의 대상이 되는 공간이다.
- Method
  - 클래스의 정보, 변수의 이름이나 타입, 메소드의 이름이나 리턴 타입, static 변수, 상수 등이 저장되는 공간.
스레드가 공유하지 않는 영역 (= 스레드마다 가지고 있는 영역)
- PC Register
  - CPU의 Program Counter와 유사하며, JVM의 현재 인스트럭션의 주소가 저장된다.
- Stack
  - 각 메소드가 실행될 때마다 스택 프레임이 생성되는 스택 영역이다. 메소드가 실행하면서 사용하는 매개변수, 지역변수, 리턴 값 등이 저장되며, 메소드 실행이 끝나면 스택 프레임은 이 영역에서 제거된다.
  - Heap 영역에 있는 객체를 가리키는 레퍼런스 변수가 Stack에 저장된다.
- Native Method Stack
  - Java가 아닌 다른 언어로 작성된 코드를 위한 공간이다. JNI(Java Native Interface)를 통해 다른 언어의 코드를 실행하여 커널에 접근할 수 있다.

Runtime Data Area의 논리적 구조

Execution Engine (실행 엔진)

클래스 로더를 통해 JVM의 런타임 데이터 영역에 배치된 바이트 코드는 Exeuction Engine에 의해 실행된다. Execution Engine은 바이트 코드를 명령어 단위로 읽어서 실행한다. 하지만 바이트 코드는 기계가 바로 수행할 수 있는 언어보다는 비교적 인간이 보기 편한 형태이기 때문에, Execution Engine은 바이트 코드를 실제로 JVM 내부에서 기계가 실행할 수 있는 기계어로 번역하며, 방식은 다음과 같이 두 가지가 있다.

Interpreter (인터프리터)
- 바이트 코드의 인스트럭션을 한 줄씩 읽어서 해석하고 실행한다.
- 한 줄씩 해석하고 실행하기 때문에 바이트 코드의 각 명령어의 실행은 빠르지만, 프로그램 전체의 실행 결과는 느리다는 단점을 가지고 있다.
- 바이트 코드는 기본적으로 인터프리터 방식으로 동작한다.
JIT(Just-In-Time) Compiler
- 인터프리터의 단점을 보완하기 위해 도입되었다. 인터프리터 방식으로 실행하다가 적절한 시점에 바이트 코드 전체를 컴파일하여 기계어로 번역하고, 이후에는 해당 바이트 코드를 더 이상 번역하지 않고 기계어로 직접 실행하는 방식이다.
- 기계어를 실행하는 것이 한 줄씩 인터프리팅 하는 것보다 빠르고, 기계어는 캐시에 보관하기 때문에 한 번 컴파일된 코드는 빠르게 수행된다.

실행 엔진에서 메모리를 효율적으로 관리하기 위해 Garbage Collection을 실행한다.

Garbage Collection

Garbage Collection은 메모리 누수와 같이 프로그램이 필요하지 않은 메모리를 계속 점유하고 있는 상황에서 Garbage Collector가 주기적으로 메모리를 해제하는 행위이다. 이때 Garbage Collection의 대상이 되는 영역은 Heap 영역이다. 따라서 개발자가 따로 메모리를 관리하지 않아도 된다.

Garbage Collection을 수행하는 과정을 Mark & Sweep이라고 부른다. 다음의 과정을 살펴보자.

메소드 하나가 실행되면서, Stack과 Heap에 필요한 정보를 저장한다. (예: 변수, 동적 할당)
실행 도중, 더 이상 사용하지 않는 메모리 공간이 발생한다.
GC(= Garbage Collector)는 Stack 영역을 스캔하면서 현재 Stack 영역의 변수가 참조하고 있는 Heap 영역의 부분을 표시한다. 만약 Heap 영역의 객체가 다른 객체를 참조하면서 사슬이 형성되면, 참조하는 모든 객체를 표시한다. (Mark)
GC는 Heap 영역을 스캔하면서 표시되지 않은 부분의 메모리를 해제한다. (Sweep)

Garbage Collection의 예. a가 참조하던 Heap 영역의 d와 null 부분의 메모리는 더이상 참조되지 않기 때문에 GC에 의해서 해제된다.

Mark & Sweep을 수행하기 전에 Garbage Collector를 제외한 모든 스레드는 작업을 중단한다. 이를 Stop the world라고 부르며, GC의 작업이 끝나면 중단했던 작업을 다시 시작한다. 따라서 GC는 성능과 관련된 이슈를 가지고 있다.

본 포스트는 다음 주소를 참고하였습니다.

[Java] Java란?

최성훈 — Wed, 29 Jan 2020 20:03:25 +0900

Java란?

Java는 대표적인 객체지향 프로그래밍 언어(Object-Oriented Language)이다. 또한, 현재 세계에서 가장 많이 사용되고 있는 프로그래밍 언어이기도 하다. 자바는 주로 다음과 같은 언어로 불린다.

Platform Independant Language
- 여기서 플랫폼이라 함은, 운영체제를 의미한다.
- Java 컴파일러는 소스코드를 JVM이 이해할 수 있는 언어인 바이트 코드로 변환한다.
- 변환된 바이트 코드는 JVM을 통해 Windows, Linux, Mac OS와 같이 여러 운영체제에서 실행될 수 있다. (이는 이식성(=portability)을 보장한다.) 단, 해당 운영체제를 지원하는 JVM이 있어야 한다.
- 즉, 운영체제의 제약을 받지 않는 언어이다.
Object-Oriented Language
- 프로그램이 필요한 정보를 추상화시켜 상태와 행위를 가진 객체로 만들고, 그 객체들 간의 상호작용을 통해 로직을 구성하는 것을 추구하는 언어이다.

Compiler 언어 vs. Interpreter 언어

Java는 컴파일 언어와 인터프리터 언어의 특징 모두를 포함하고 있다. 소스코드가 Java 컴파일러를 통해 바이트 코드로 변환되고(컴파일 언어), 변환된 바이트 코드는 JVM에 의해 인터프리터 방식으로 실행된다. (인터프리터 언어)

Java 컴파일러를 통해 바이트 코드로 변환된 소스코드. 컴파일러 언어의 특징이다.

동일한 바이트 코드가 여러 운영체제에서 실행될 수 있다. 이 때, 해당 운영체제를 지원하는 JVM이 필요하다.

객체지향 언어의 특징

Abstraction (추상화)

구현하고자 하는 영역에서 불필요한 정보는 숨기고, 공통된 중요한 정보만 표현하여 이해하기 쉽게 모델화 하는 것이다. 즉, 객체지향 관점에서 클래스를 정의하는 행위이다.

추상화의 예

Encapsulation (캡슐화)

정보 은닉을 통해 코드 내부를 볼 수 없게 만드는 행위이다. 즉, 자신의 속성과 기능을 한 곳에 모아(=캡슐화하여) 재사용성을 높이고 장기 유지보수성(= maintainability)을 향상시킨다.

캡슐화가 적용되어있지 않은 예. 변경사항이 생기면 많은 양의 코드가 변경되야 한다.

캡슐화가 적용된 예. 외부의 사용자는 닭 객체의 모든 정보를 알 필요가 없어진다. 또한 변경사항이 생길 때 변경될 코드의 양이 적어진다.

이뿐만 아니라 캡슐화는 클래스 간의 낮은 결합도를 유지할 수 있도록 해준다.

Coupling (결합도)
- 하나의 기능을 수행하기 위해 다른 클래스나 모듈에 얼마나 의존적인지 나타낸다.
- 결합도가 높은 관계에서 하나의 클래스가 변경되면, 관련된 클래스들 또한 함께 변경되어야 한다. 이는 코드의 복잡도가 높아지고, 이해하기 어려워진다.
Cohesion (응집도)
- 하나의 모듈 내의 요소들이 서로 밀접하게 관련되어있는 정도를 나타낸다.
- 이상적으로 독립적인 모듈이 되기 위해서는 응집도가 강해야 한다.
- 응집도가 높으면 모듈을 쉽게 이해할 수 있고, 재사용하기 쉬워진다. 유지보수성이 향상된다.

Inheritance (상속성)

상속성은 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것을 의미한다. 상속을 사용하면 하위 클래스는 상위 클래스의 모든 속성과 연산을 다시 정의하지 않고도 사용할 수 있고, 때에 따라서는 상위 클래스에서 물려받은 속성이나 연산을 변경하거나 새로 추가할 수도 있다.

Polymorphism (다형성)

다형성은 하나의 객체가 여러 가지 클래스로 해석되어 다른 기능을 수행할 수 있는 능력을 의미한다. Java에서는 다형성을 지원하기 위해 오버라이딩, 오버로딩이 가능하다.

Overriding (오버라이딩)
- 부모 클래스의 메소드를 재정의 하는 것을 의미한다. 이때, 메소드 이름, 매개변수와 반환 값은 부모 클래스와 동일해야 한다.
Overloading (오버로딩)
- 부모 클래스와 같은 이름의 함수 및 메소드를 재정의하여, 매개변수의 타입과 개수에 따라 다르게 호출할 수 있게 하는 것을 의미한다.

상속과 오버라이딩의 예. 부모클래스의 sound() 메소드를 상속받아 재정의 한다.

오버라이딩 된 함수의 경우, 수행 중에 상위 클래스와 하위 클래스에서 적당한 함수를 동적으로 선택할 수 있다. 다음은 동적 바인딩의 예이다.

public static void main()
{
    Person p = new Person("A", "M");
    Student s = new Student("B", "F", 26);
    Person person;

    person = p;
    person.print() // Person 클래스의 print()가 실행됨. "A의 성별은 M입니다."

    person = s;
    person.print(); // Student 클래스의 print()가 실행됨. "B의 성별은 F이고, 26살 입니다."
}

[OpenStack에 contribute하기 - 6] 실전 (3)

최성훈 — Mon, 27 Jan 2020 21:01:21 +0900

본 포스트에서는 제출한 변경사항을 수정하는 방법과, 제출한 변경사항이 병합되는 과정을 살펴보겠습니다.

본 포스트는 변경사항을 이미 한 번 제출했다고 가정합니다.

리뷰 확인하기

우리가 제출한 변경사항에 대해서 코멘트가 달렸네요! 한 번 살펴봅시다.

다른 리뷰어들이 남긴 코멘트

먼저, 7번 패치셋을 제출하고 나서, Zuul로부터 Verified +1을 받았습니다. 즉, 빌드 테스트가 성공했다는 뜻입니다.

그다음으로 Lajos Katona와 Slawek Kalponski로부터 코멘트를 받았네요. 한 번 클릭해서 자세하게 살펴보겠습니다.

코멘트가 달린 커밋메시지

위 사진은 제가 작성한 커밋 메시지입니다. 노란색으로 하이라이트 된 부분에 달린 코멘트들을 한 마디로 요약하자면, '커밋 메시지를 이렇게 작성하지 마라'가 되겠네요... 하하 (쓴웃음)

다음으로는 제가 실제로 작성한 코드를 살펴봅시다.

코멘트가 달린 코드

코드를 살펴보기 전, 빨간 상자를 확인해주세요. 각 빨간 상자를 보시면 패치셋에 대한 번호가 있습니다. 이를 통해 각 패치의 변경 사항을 살펴볼 수 있습니다. 왼쪽에 보이는 부분은 Base 패치이고, 오른쪽은 7번 패치입니다. 즉, Base 패치부터 7번 패치까지 어떻게 변화되었는지 한눈에 확인하는 확인할 수 있습니다. 오른쪽은 7번 패치에서 달린 코멘트입니다.

코멘트가 달린 코드

위에서 달린 코멘트를 한 줄로 요약하자면, '이렇게 하는 방법 말고 다른 방법 없어? ~~ 이렇게 말이야'가 되겠네요. 그 부분에 제가 이해가 되지 않는 부분이 있어서 질문을 했고, 이에 또 다른 리뷰어가 코멘트를 달아주었네요. 두 명의 핵심 리뷰어의 리뷰를 통해 어느 정도 방향이 잡혔으니, 제출한 변경사항을 수정하고 다시 제출해봅시다.

제출한 변경사항 수정하기

우리는 이미 변경사항을 제출하기 위해 브랜치를 생성하고, 그 브랜치에서 작업했습니다.

현재 작업중인 브랜치

다행히 우리가 이전에 작업하던 bug/1857035 브랜치 그대로 있네요. 그럼 위에서 리뷰어들이 조언해준 대로 코드를 수정하고 아래의 명령어를 입력해봅시다.

$ git commit --amend

커밋 메시지

리뷰어들이 조언해준 대로 코드와 커밋 메시지를 수정하고 변경사항을 저장합니다. 여기서 주의해야 할 점은, Closes-Id 줄을 수정하면 안 됩니다. 이는 Gerrit이 커밋을 구분하기 위한 해쉬를 포함하고 있기 때문에, 이 태그가 포함된 줄을 수정해버리면 Gerrit이 우리의 변경사항을 추적할 수 없게 됩니다.

로컬환경에 반영된 변경사항

커밋이 끝난 후, 리뷰를 위해 아래의 명령어로 Gerrit에 제출합니다.

$ git review

변경사항 병합하기

위의 과정을 반복하면서 패치를 진행하다 보면, 아래와 같이 핵심 리뷰어들로부터 +2점의 코드 리뷰 점수 또는 +1점의 Workflow 점수를 받을 수 있습니다. (이와 관련한 정보는 여기를 확인해주세요)

핵심 리뷰어들로부터 받은 +2의 코드 리뷰

2명의 핵심 리뷰어들로부터 코드 리뷰 +2점과 Workflow +1점을 받았으니 이제 곧 머지가 될 것 같네요!

그런데 이게 무슨 일인가요?

Recheck

2명의 핵심 리뷰어들로부터 코드 리뷰 +2를 받았지만 실패한 빌드 테스트

첫 번째 빨간 상자처럼 빌드 테스트가 실패했네요. 저는 제 코드에 문제가 생긴 줄 알았지만, 이에 대해서 알아보니 Zuul이 OpenStack의 모든 프로젝트에 대해 여러 빌드 테스트를 동시에 진행하면서, 서버 환경에 잠재적인 에러를 유발할 수 있다고 합니다. 이와 같은 경우엔, 그냥 recheck라는 코멘트를 달면 Zuul은 다시 빌드 테스트를 실행합니다. 위의 사진에서 확인할 수 있다시피, 빌드 테스트가 성공하면 게이트 작업을 실행합니다. 이 게이트 작업을 통과하면 최종적으로 우리의 변경사항이 병합됩니다.

하지만 이게 쉬운 일은 아닙니다. 한 번의 빌드 테스트가 끝나기까지 서버의 상황에 따라 다르겠지만, 저는 대개 6시간 정도 걸렸던 것 같습니다. 저는 자주 빌드 테스트를 실패했습니다. 아래는 제가 매번 테스트에 실패하면서 recheck 코멘트를 단 흔적입니다.

실패한 빌드 테스트의 흔적들

Verified +2

Zuul이 빌드 테스트부터 게이트 작업까지 성공적으로 완료한다면 우리가 제출한 변경사항은 자동적으로 해당 프로젝트의 master 브랜치로 병합됩니다. 이와 동시에, Zuul은 해당 변경사항에 대해서 Verified +2점의 점수를 부여합니다. 아래는 제가 마지막 패치셋에서 받은 리뷰 점수들입니다. (Rodolfo Alonso Hernandez 씨의 리뷰 점수는 이전의 패치셋에서 받았습니다.)

가장 마지막 패치셋에 받은 리뷰 점수

Github

우리가 제출한 변경사항이 잘 병합되었는지 확인하기 위해서 Github의 OpenStack 프로젝트 레포지토리에서 확인할 수 있습니다. (제 경우는 openstack/neutron입니다.)

Github에서 확인할 수 있는 우리가 제출한 변경사항

축하합니다! 드디어 OpenStack에 첫 기여를 끝내셨네요!

저에게는 한 달이라는 긴 시간이었지만, 그 과정들을 이렇게 정리하면서 저뿐만 아니라 다른 사람들에게도 도움이 되고자 글을 남깁니다.

후에 OpenStack에 contribution을 하고자 하시는 분들께 많은 도움이 되면 좋겠네요.

정말 긴 글 읽어주셔서 감사합니다.

[OpenStack에 contribute하기 - 6] 실전 (2)

최성훈 — Mon, 27 Jan 2020 18:13:32 +0900

본 포스트에서는 OpenStack을 로컬 환경에 설치하고, 변경 사항을 제출하는 방법에 대해서 설명하고자 합니다.

DevStack

DevStack이란?

DevStack은 git의 master 브랜치의 최신 버전을 기반으로 완전한 OpenStack 환경을 신속하게 띄우는 데 사용되는 확장 가능한 스크립트 모음입니다. DevStack은 개발 환경과 많은 OpenStack 프로젝트의 기능 테스트의 기초로서 상호적으로 사용됩니다. 즉, OpenStack을 쉽게 설치할 수 있도록 도와주는 스크립트라고 생각하시면 됩니다.

DevStack 설치하기

주의! DevStack은 설치 중에 시스템의 많은 부분을 변경합니다. 오로지 이 목적으로만 사용되는 서버나 가상 머신에서만 DevStack을 실행하세요.

Stack User 추가하기 (Optional)

DevStack은 sudo권한이 부여된 비-루트 사용자로 실행되어야 합니다. ("ubuntu" 또는 "cloud-user"와 같은 클라우드 이미지에 대한 표준 로그인은 괜찮습니다.)

만약 클라우드 이미지를 사용하지 않는다면, DevStack을 실행하기 위해 다음과 같은 별도의 stack 유저를 생성할 수 있습니다.

$ sudo useradd -s /bin/bash -d /opt/stack -m stack

이 사용자가 시스템의 상당 부분을 변경할 것이므로, sudo 권한이 필요합니다.

$ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
$ sudo su - stack

DevStack 다운로드하기

$ git clone https://opendev.org/openstack/devstack
$ cd devstack

DevStack 레포지토리에는 OpenStack을 설치하는 스크립트와 구성 파일을 위한 템플릿이 포함되어 있습니다.

local.conf 생성하기

DevStack git 레포지토리의 최상위 경로에 4개의 암호가 있는 local.conf 파일을 생성하세요.

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

이는 DevStack을 시작하는데 필요한 최소 설정입니다.

DevStack 레포지토리 내의 samples/ 폴더 안에 local.conf를 위한 예제 파일이 있습니다.

설치 시작하기

$ ./stack.sh

인터넷 연결 속도에 따라 15~20분이 소요됩니다. 이 과정에서 많은 git tree와 패키지가 설치됩니다.

DevStack을 설치하면서 /opt/stack/ 경로에 keystone, glance, nova, placement, cinder, neutron 그리고 horizon이 설치됩니다. 다른 프로젝트에 대해서 작업하고자 한다면, Github에서 해당 프로젝트 레포지토리를 복제하시거나 다른 방법으로 설치해야 합니다.

변경사항 만들기

다음으로 진행하기 전에, 작업하고자 하는 프로젝트의 레포지토리 내에서 이 과정을 마치고 진행하세요. OpenStack의 경로는 /opt/stack/ 입니다.

변경사항을 작업할 프로젝트로 이동하기

OpenStack은 여러 서브 프로젝트들을 포함하고 있기 때문에, 본인이 작업하고자 하는 프로젝트로 이동해야 합니다. 저는 neutron 프로젝트에서 작업을 할 것이기 때문에, neutron 프로젝트로 이동하겠습니다.

$ cd /opt/stack/neutron

브랜치 생성하기

변경사항을 생성하기 전에, 브랜치를 생성해야 합니다. 작업을 저장할 토픽 브랜치를 생성하고, 그 브랜치로 변경하세요. 만약 blueprint에 대해서 작업 중이라면, 브랜치 이름을 bp/BLUEPRINT으로 생성하세요. 여기서 BLUEPRNIT는 Launchpad내의 blueprint 이름입니다. (예: bp/authentication)

일반적으로 버그에 대해서 작업할 때에는 브랜치 이름을 bug/BUG-NUMBER와 같이 생성합니다. (예: bug/1234567) 아니면 Gerrit에서 변경사항에 대한 제목을 나타낼 것이기 때문에, 의미 있는 이름으로 생성하세요. 제 경우 버그 번호는 1857035입니다.

버그 번호는 버그 페이지에서 아래의 빨간 박스 위치에서 확인할 수 있습니다.

버그 이슈 번호

다음의 명령어로 브랜치를 생성할 수 있습니다.

$ git checkout -b TOPIC-BRANCH

생성된 브랜치 bug/1857035

변경사항 작업하기

이제 해당 버그를 위한 브랜치로 이동했으니, 해당 버그나 이슈에 대해서 작업합니다. (제 경우에는 neutron/tests/functional/cmd/test_netns_cleanup.py에 대해서 작업했습니다.)

변경사항 테스트하기

여기를 참고하여 변경사항에 대해서 테스트하세요. 저는 tox를 사용합니다. 제가 사용한 명령어는 다음과 같습니다.

$ cd /opt/stack/neutron/neutron/tests/functional/cmd
$ tox -e functional -- test_netns_cleanup.NetnsCleanupTest.test_cleanup_network_namespaces_cleans_dhcp_and_l3_namespaces

이는 test_netns_cleanup.py 모듈의 NetnsCleanupTest 클래스의 test_cleanup_network_namespace_cleans_dhcp_and_l3_namespaces() 메소드를 테스트합니다. 여기서 주의할 점은 tox는 파일의 경로와 클래스, 메소드는 마침표(.)로 구분합니다.

테스트 결과

위와 같이 테스트가 성공적으로 끝났다면 이제 변경사항을 제출할 준비가 됐습니다.

변경사항 제출하기

변경사항을 제출하기 전에, OpenStack의 커밋 메시지 컨벤션과 관련된 포스트를 읽고 진행해주세요. (여기와 여기를 참고해주세요.)

작성한 커밋 메시지

대부분의 경우 Git-review가 설치한 Gerrit 커밋 훅에 의해 Change-Id 라인이 자동으로 추가된다는 점에 유의하세요. (가장 첫 번째 커밋에는 Change-Id를 작성하지 않으셔야 합니다.) 이미 커밋을 했는데 Change-Id가 추가되지 않은 경우, Gerrit 설정 단계를 다시 수행하고 다음의 명령어를 실행하세요. `git commit --amend` 커밋 훅은 실제로 아무 변경을 하지 않더라도 커밋 메시지 수정이 끝나면 Change-Id를 추가합니다. Gerrit이 혼동할 수 있으므로 Change-Id는 절대로 변경하지 마세요.

변경사항에 대해 작업하고 커밋한 후, 리뷰를 위해 제출하세요.

$ git commit -a
$ git review

제출한 변경사항 확인하기

우리가 제출한 변경사항은 실시간으로 여기에서 확인할 수 있습니다. 제 변경사항은 이미 OpenStack에 병합되었으므로, 다른 사람의 변경사항에 대해서 확인해보겠습니다.

지금까지 제출된 변경사항들

위에서 "Mask the token used to allow access to consoles"라는 변경사항을 살펴보겠습니다.

제출한 변경사항 페이지. 리뷰를 위해 사용된다.

왼쪽 위의 빨간 상자를 확인하시면, 현재 제출한 변경사항의 번호를 확인할 수 있습니다. 이 분의 변경사항의 번호는 704255입니다. 오른쪽 아래의 빨간 상자를 확인하시면 코드 리뷰 점수와 테스트 결과를 확인할 수 있습니다. 이 분의 변경사항은 현재 통과하지 못한 테스트가 있네요. 이 경우에는 다시 새로운 패치를 작성하고 제출하면 자동으로 다시 Zuul이 테스트하고, 해당 패치에 대해 리뷰 점수를 부여합니다.

현재 진행 중인 테스트에 대해서는 여기를 확인하시면 됩니다.

제출한 변경사항에 대해 진행중인 테스트

위에서 말했다시피, 실패한 테스트가 있음을 확인할 수 있습니다. 만약 Zuul의 빌드 테스트를 통과한다면 다음과 같은 이메일을 받으실 수 있습니다.

Zuul의 빌드 테스트 결과

이제는 우리는 Zuul로부터 빌드 테스트도 통과했고, 변경사항이 병합되기까지 핵심 리뷰어들로부터 +2점의 리뷰를 2번 이상 받기만 하면 됩니다!

[OpenStack에 contribute하기 - 6] 실전 (1)

최성훈 — Mon, 27 Jan 2020 15:06:38 +0900

이번 포스트에서는 OpenStack에 contribute 하기 전에 해결하기 쉬운 버그나 이슈를 찾는 방법에 대해 설명할 것입니다.

본 포스트는 실제로 제가 OpenStack에 기여하기 위해 진행했던 과정들임을 참고해주시기 바랍니다.

해결하고자 하는 버그 또는 이슈 찾기

OpenStack에 기여하는 방법은 여러 가지가 존재합니다. 하지만 blueprint에 제시된 새로운 기능을 구현하거나, 양이 많은 패치는 처음 기여를 하는 개발자들에게는 어려운 일입니다. 따라서 우리는 해결하기 쉬운, 간단한 버그부터 찾아보도록 하겠습니다.

먼저, OpenStack의 이슈나 버그들은 현재 대부분 Launchpad를 통해서 보고됩니다. OpenStack에는 매우 많은 프로젝트가 존재하는데요, 여기서 본인이 기여하고자 하는 프로젝트만 고르셔도 되지만, 저는 모든 프로젝트에 대해서 찾아보겠습니다.

OpenStack의 Launchpad에 접속했을 때의 메인화면

위의 카테고리에서 Bugs 섹션을 클릭해주세요.

OpenStack Launchpad의 Bugs 섹션

Bugs 섹션에서 위와 같이 현재 OpenStack 내에서 보고된 모든 이슈와 버그들을 확인할 수 있습니다. 왼쪽에 CRITICAL과 IN PROGRESS, CONFIRMED와 같은 정보를 확인하실 수 있는데요, 이와 같은 정보는 여기를 참고해주세요. 우리는 여기서 우리가 해결할 수 있는 쉬운 버그를 찾아야 합니다. 위에서 Advanced search를 클릭해주세요.

Advanced Search 화면

보고된 각 버그들 중에서, 쉬운 버그를 찾기 위해 위와 같이 체크해주세요. 그리고 스크롤을 아래로 내리다 보면 태그를 입력하는 곳이 있습니다.

Advanced Search 화면

이 부분이 정말 중요합니다. Tags에 low-hanging-fruit를 입력해주세요. 이 태그는 저희와 같이 OpenStack에 처음 contribute를 하는 사람들을 위한 태그입니다. 이 태그를 통해 해당 버그나 이슈가 해결하기 쉽다는 것을 초보 기여자들에게 알리고, 그와 동시에 진입장벽을 낮춰 OpenStack에 기여를 할 수 있도록 장려하는 태그입니다.

low-hanging-fruit 태그를 가진 버그와 이슈들

여기서 본인이 해결하고자 하는 버그나 이슈를 선택해주세요. 저는 neutron 프로젝트의 버그를 선택했습니다. (여기를 참고해주세요.)

보고된 버그

만약, 해당 버그나 이슈가 본인이 해결할 수 있다고 생각하신다면, 위에서 표시된 빨간 박스 안의 연필 모양을 클릭해서 해당 버그를 본인에게 할당하세요. (주의: 해당 버그가 이미 누군가에게 할당되어 있다면, 코멘트를 통해서 미리 그 사람과 상의한 후에 본인에게 할당하세요. 아무 상의 없이 본인에게 할당한다면 상대방의 기회를 뺐는 무례한 행동입니다.)

버그 페이지에 달린 코멘트. 해당 버그가 본인에게 할당된 것을 확인할 수 있다.

위와 같이 해당 버그 페이지의 코멘트를 통해 본인에게 할당된 것을 확인할 수 있습니다.

[운영체제] 메모리 관리 (2)

최성훈 — Fri, 24 Jan 2020 02:17:21 +0900

Fragmentation (단편화)

External fragmentation (외부 단편화)
- 프로세스를 실행하기 위한 메모리 공간이 physical 메모리 내에 존재하지만, 연속적이지 않아서 할당할 수 없는 상황
Internal fragmentation (내부 단편화)
- 프로세스를 실행하기 위해 메모리가 할당됐지만, 프로세스가 필요한 양보다 더 많이 할당되어 프로세스에게 할당된 메모리가 낭비되는 상황

External fragmentation과 Internal fragmentation

50-percent rule
- First-fit을 통계적으로 분석해보면, 만약 메모리 내에서 N개의 블록이 할당되었을 때, 0.5N개의 블록이 internal fragmentation으로 손실될 수 있다. 즉, 1.5N개의 블록 중 0.5N개가 손실되므로, 메모리의 1/3을 쓸 수 없게 될 수 있다는 것을 의미한다. 이러한 현상을 50-percent rule이라고 한다.

Solutions to External Fragmentation (외부 단편화의 해결방법)

Compaction (압축)

외부 단편화로 분산되어 있는 메모리 공간들을 재배치하여, 하나의 큰 메모리 공간으로 확보한다.

Paging (페이징)

가상 메모리를 사용하여 프로세스를 크기가 같은 블록인 페이지로 나누고, 물리 메모리도 페이지의 크기와 동일한 프레임으로 나눈다. 페이지와 프레임을 대응하여 연속적인 물리 메모리가 아니더라도 프로세스가 필요한 만큼의 프레임을 사용할 수 있도록 하는 기법. 연속적이지 않은 메모리 공간을 활용하기 때문에 외부 단편화를 해결한다. 하지만 고정된 크기의 프레임을 할당하기 때문에 내부 단편화가 발생한다.

작은 크기의 페이지를 사용하면 내부 단편화를 줄일 수 있지만, 페이지 테이블 내의 엔트리가 증가하고, 이는 더 큰 오버헤드를 유발한다.

Page (페이지)
- 논리 메모리를 일정한 크기로 나눈 블록
Frame (프레임)
- 물리 메모리를 일정한 크기로 나눈 블록

Paging을 사용한 주소 변환

CPU는 논리적 주소인 p와 d를 생성하는데, p는 page number, d는 page offset을 의미한다. 페이지의 크기는 하드웨어에 의해서 결정되는데, 주로 2의 지수형태이다. 페이지는 페이지 테이블을 통해 실제 물리 메모리의 주소로 매핑된다.

Paging의 논리적 주소

Paging의 예

Hardware Support for Paging

페이지 테이블을 만드는 대표적인 방법으로 다음과 같이 2가지가 있다.

CPU 내에 페이지 테이블을 만들기
메모리 내에 페이지 테이블을 만들기

첫 번째는 CPU 내부에 레지스터로 페이지 테이블을 만드는 것이다. 이는 주소변환을 빠르게 할 수 있지만, CPU가 사용할 수 있는 레지스터는 한정되어 있으므로 페이지 테이블의 크기가 매우 제한된다는 단점이 있다.

두 번째는 메모리 내부에 페이지 테이블을 만드는 것이다. 이는 첫 번째와 반대로 페이지 테이블의 크기에 제한이 없지만, 주소 변환 속도가 느리다는 단점이 있다. CPU는 프로세스에 접근하기 위해서 물리 메모리 내에 있는 페이지 테이블에 접근하고, 이 페이지 테이블을 다시 참조하여 물리 메모리 내의 실제 프로세스 주소로 접근하는데, 이는 2번의 메모리 접근을 하는 것이므로 매우 느리다.

페이지 테이블을 만드는 2가지 방법

위 두 가지 방법은 장단점이 너무 상반되기 때문에, 이를 해결하기 위해 페이지 테이블을 위한 캐시를 만들었다. 즉, 별도의 하드웨어를 둔 것이다. 이 하드웨어를 TLB(Translation look-aside buffer)라고 부른다. TLB는 CPU 내에 페이지 테이블을 두는 것보다 크기가 더 크고, 메모리 내에 페이지 테이블을 두는 것보다 주소 변환 속도가 더 빠르다는 장점이 있다.

TLB를 사용한 주소 변환

Page Protection

프로세스의 모든 주소는 페이지 테이블을 경유하므로, 페이지 테이블을 이용해서 보호 기능을 수행할 수 있다. 대표적으로 valid-invalid bit를 두고, 해당 비트가 유효할 때만 프레임에 접근하도록 하는 것이다.

page protection의 예

Page Sharing

프로세스는 code + data + stack + heap의 구조를 가지고 있다. 하나의 프로그램에서 여러 프로세스가 동일한 code를 사용한다면, 하나의 code 영역을 공유함으로써 메모리의 낭비를 줄일 수 있다. 하지만 이때 조건은, code는 reentrant(= read only) 해야 한다.

Page sharing의 예

Page Table Structure

32비트 시스템은 2^32(= 4GB)만큼의 주소 공간을 가진다. 여기서 페이지의 크기가 4KB(= 2^12)라고 가정하면, 페이지 테이블이 가질 수 있는 페이지의 개수는 1MB(= 2^20, 약 100만 개)이다. 32비트 시스템에서 페이지를 나타내는 주소는 32비트(= 4B)이므로, 프로세스당 페이지 테이블의 크기는 4B * 1MB = 4MB (= 2^22)이다.

이렇게 생성된 페이지 테이블들은 프로그램이 메모리에 적재될 때 함께 적재된다. 하지만 페이지 테이블은 4MB로써 매우 큰 크기를 가진다. 이때 페이지 테이블은 연속적으로 메모리에 적재되므로 단편화로 인해 메모리 공간을 낭비하게 된다. 이를 해결하기 위해 다음과 같은 구조를 제시한다.

Hierarchical Paging (계층적 페이징)
Hashed Page Table (해쉬 페이지 테이블)
Inverted Page Table (역 페이지 테이블)

Hierarchical Paging (계층적 페이징)

4MB의 연속된 메모리 공간은 생각보다 크다. 심지어 프로세스 또한 그 주소 공간 중 아주 일부분만 사용하므로, 페이지 테이블의 아주 일부분에만 접근할 것이다. 우리가 메모리 내에서 낭비되는 주소 공간을 페이징으로 해결한 것처럼, 페이지 테이블 내에서 낭비되는 공간 또한 페이징으로 해결할 수 있다.

계층적 페이징은 기존의 페이지 테이블 내의 페이지를 참조하는 또 다른 페이지 테이블(=outer page table)을 두어, 페이지 테이블을 비연속적으로 만드는 것이다.

Hierarchical paging의 예

32비트 주소체계에서, 기존의 4MB(= 2^22) 페이지 테이블은 1M(= 2^20)개의 엔트리를 가진다. Page of page table의 크기는 기존의 페이지와 동일하게 4KB(= 2^12)이므로, 1K(= 2^10)개의 엔트리를 가진다. 따라서, 기존의 페이지 테이블 내에 존재하는 page of page table은 1K(= 2^10)개가 존재한다.

Page of page table이 1K(= 2^10)개가 존재하므로 outer page table의 엔트리는 이와 동일하게 1K(= 2^10)개가 필요하고, 엔트리 한 개는 page of page table의 주소를 가리키므로 크기는 4KB(= 2^12)가 된다. 이는 페이지 1개의 크기와 동일하므로 더 이상 페이징으로 나눌 필요가 없게 된다.

위의 그림은 2번의 페이징을 통해 메모리 내의 프레임을 찾는 과정을 나타낸다.

Hierachical paging의 논리적 주소 변환 체계

32비트 주소 체계에서, 첫 10비트는 어떤 page of page table을 사용할지 찾는 데 사용된다. 두 번째 10비트는 우리가 메모리 내에서 어떤 프레임을 사용할지 찾는 데 사용된다. 남은 12비트는 프레임 내의 오프셋으로 사용된다.

Hashed Page Table (해쉬 페이지 테이블)

해쉬 페이지 테이블은 32비트 시스템에서 32비트보다 큰 주소를 처리할 때 사용한다. 해시 테이블의 각 항목들은 연결 리스트를 가지고 있다. 가상의 페이지 번호는 해싱되어 테이블에 저장된다. 각 연결 리스트의 항목들은 <가상 페이지 번호, 프레임 번호, 다음 항목을 향한 포인터>로 이루어져 있다. 해시 테이블로부터 물리 주소를 찾을 때 연결 리스트의 항목들로부터 가상 페이지 번호와 프레임 번호를 비교하여, 일치한다면 해당 주소를 반환한다.

Hashed page table의 예

Inverted Page Table (역 페이지 테이블)

기존의 페이지 테이블은 한 개의 프로세스당 한 개의 페이지 테이블을 가지고 있었다. 만약 프로세스가 많이 존재한다면, 페이지 테이블 또한 메모리에 저장되어 메모리 공간이 그만큼 필요하게 된다. 역 페이지 테이블은 시스템 내에 한 개의 전역 페이지 테이블을 두어 물리 메모리 내의 프레임에 대응하는 항목을 가진다. 이는 물리 메모리에서 실제로 사용되는 프레임만을 항목으로 가지므로 메모리의 낭비를 줄일 수 있지만, 각 프레임들이 어떤 프로세스에 의해서 사용되고 있는지 알기 위해 프로세스 ID가 필요하고, 해당 프레임이 몇 번째 페이지에 해당하는지 알기 위해 페이지 번호 또한 필요하다. 따라서 역 페이지 테이블은 <프로세스 ID, 페이지 번호>를 저장한다.

실제 물리 주소를 얻기 위해 <프로세스 ID, 페이지 번호>가 일치하는 항목을 찾고, 이때의 인덱스가 실제 메모리의 프레임 번호가 된다.

역 페이지 테이블은 메모리 공간을 많이 절약할 수 있지만, 프레임을 찾기 위해 테이블 전체를 검색해야 하므로 Linear search에 대한 오버헤드가 있다.

Inverted page table의 예

Solutions to Internal fragmentation (내부 단편화의 해결방법)

Segmentation (세그멘테이션)

가상 메모리를 사용하여 프로세스를 크기가 서로 다른 논리적 단위인 세그먼트로 분할하고 메모리를 할당하여 내부 단편화를 해결하는 기법. 프로세스를 메모리에 적재시키고 해제함을 반복함으로써 외부 단편화가 발생한다.

Segment (세그먼트)
- 가상 메모리 내에서 서로 크기가 다른 논리적 단위
- 각 세그먼트는 이름(또는 숫자)과 길이를 가지고 있다.
Segment table (세그먼트 테이블)
- 세그먼트들의 정보를 가지고 있는 테이블 <Base address, Limit>
- 테이블 내의 논리 메모리 주소를 1차원 물리 메모리 주소로 매핑한다.

Segmentation의 논리적 관점

Segmentation을 사용한 주소 변환

CPU는 논리적 주소인 s와 d를 생성하는데, s는 segment id, d는 offset을 의미한다. 세그먼트는 세그먼트 테이블을 통해 실제 물리 메모리의 주소로 매핑된다.

[백준 17825번] 주사위 윷놀이

최성훈 — Thu, 23 Jan 2020 01:05:39 +0900

문제 보기

이 문제는 브루트 포스 문제이다.

이 문제는 2019년 삼성 하반기 SW 역량 테스트에서 나온 두 번째 문제이다.

문제를 푸는데 3일이나 걸렸다... (도움을 주신 정인준 선배님 감사합니다ㅠㅠ)

지금 와서 되돌아보니 풀이의 큰 흐름은 맞았지만, 문제에서 간과하기 쉬운 조건들이 있었다.

이제는 삼성 SW 역량 테스트에서 알고리즘의 구현을 할 수 있는지 묻는 게 아니라, 문제 속에 찾기 힘든 조건들을 포함시키는 게 요즘 추세인 것 같다.

먼저, 백준에 나와있는 윷놀이 판의 그림은 헷갈리는 부분이 있으므로 이를 명확하게 하기 위해서 다음의 그림을 참고하면 좋을 것 같다.

윷놀이 판

위와 같은 윷놀이 판에서, 모든 경우의 수를 따져야 하므로 말이 지나갈 경로를 정해야 한다. 경로를 어떻게 구성하고 구현할지는 사람마다 다르겠지만, 나는 다음과 같이 구현하였다.

0번 경로

1번 경로

2번 경로

3번 경로

4번 경로

이와 같은 경로는 코드의 4~10번째 줄에 선언되어 있다.

나는 브루트 포스를 DFS로 구현하였는데, 문제를 푼 로직은 다음과 같다.

각 턴마다 말이 움직일 횟수를 가져온다. (24~25번째 줄)
현재 위치를 구하고, 만약 현재 위치가 도착지점이라면 다음 말로 넘어간다.(= 다음 말을 이동시킨다.) (32~34번째 줄)
각 말마다 다음 위치를 구하고, 그다음 위치가 만약 각 코너와 중앙이라면, 이동할 경로의 번호와 위치를 바꿔준다. (36~56번째 줄)
만약 말의 다음 위치가 도착을 넘어간다면, 도착에서 이동을 마친다. (58~60번째 줄)
시작과 도착을 제외하고, 만약 현재 말의 다음 위치에 이미 다른 말이 있다면, 다음 말로 넘어간다.(= 다음 말을 이동시킨다.) (62~66번째 줄)
모든 조건을 통과하고 난 후, 말을 이동시킨다. (68~71번째 줄)
DFS를 통해 모든 경우를 재귀적으로 탐색한다. (73번째 줄)
이동시킨 말을 다시 원래 위치로 되돌린다. (75~78번째 줄)

3번 과정에서 내가 빠트렸던 점은, 0번 경로에서 40번 위치로 이동할 때, 4번 경로의 40번으로 위치 변경을 시켜주지 않았던 것이다.

따라서 5번 과정에서, 실질적으로 0번 경로의 40번과 4번 경로의 40번은 같은 위치지만, 다른 위치로 판단하여 같은 위치에 말이 2개 있을 수 있었다.

이 문제에서 신경 써야 할 점은 DFS로 브루트 포스를 구현하는 것이 아니라, 말 그대로 윷놀이 게임을 어떻게 구현할지 그 조건을 잘 찾아내는 게 중요한 것 같다.

예제 입력으로도 찾기 힘든 반례가 있다면 다음을 참고하면 좋을 것 같다.

Input:

3 5 2 5 3 5 2 1 3 1

Output:

다음의 말들을 순서대로 움직이면 위의 결과를 얻을 수 있다.

1 2 2 1 1 1 1 1 2 1

import sys

movements = list(map(int, sys.stdin.readline().split()))
path_info = [
	[0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 0],
	[10, 13, 16, 19, 25],
	[20, 22, 24, 25],
	[30, 28, 27, 26, 25],
	[25, 30, 35, 40, 0]
]
# [i-th path, j-th block]
piece_positions = [[0, 0], [0, 0], [0, 0], [0, 0]]
piece_scores = [0, 0, 0, 0]
answer = 0


def dfs(idx):
	# termination condition
	if idx == 10:
		global answer
		answer = max(answer, sum(piece_scores))
		return answer
	
	# how many steps are going to be moved
	move = movements[idx]
	
	for i in range(4):
		# current piece position
		cur_path = piece_positions[i][0]
		cur_block = piece_positions[i][1]
		
		# if current piece finished the game
		if cur_block == len(path_info[cur_path]) - 1:
			continue
		
		next_path = cur_path
		next_block = cur_block + move
		# change path at the corner
		if cur_path == 0:
			if next_block == 5:
				next_path = 1
				next_block = 0
			elif next_block == 10:
				next_path = 2
				next_block = 0
			elif next_block == 15:
				next_path = 3
				next_block = 0
			elif next_block == 20:
				next_path = 4
				next_block = 3
		# change path at the center point
		elif cur_path < 4:
			if next_block >= len(path_info[cur_path]) - 1:
				next_path = 4
				next_block -= len(path_info[cur_path]) - 1
		
		# limit block to the last block of the path
		if next_block >= len(path_info[next_path]):
			next_block = len(path_info[next_path]) - 1
		
		# without the first & last block
		if path_info[next_path][next_block] != 0:
			# if next step is already taken
			if [next_path, next_block] in piece_positions:
				continue

		# move piece and update information
		piece_positions[i][0] = next_path
		piece_positions[i][1] = next_block
		piece_scores[i] += path_info[next_path][next_block]
		
		dfs(idx + 1)
		
		# reset piece and information
		piece_positions[i][0] = cur_path
		piece_positions[i][1] = cur_block
		piece_scores[i] -= path_info[next_path][next_block]


dfs(0)
print(answer)

[운영체제] 메모리 관리 (1)

최성훈 — Tue, 21 Jan 2020 15:54:03 +0900

Memory Access

프로그램은 실행되기 위해서 반드시 메모리에 로드되어야 한다.
CPU는 오로지 레지스터와 메인 메모리에만 접근할 수 있다.
메모리 유닛은 메모리 주소들의 흐름만 볼 수 있다.
- context oblivious
  - 메모리 주소만 알고 메모리에 대한 어떤 것도 모른다.
Memory Protection Mechanism

Memory Protection Mechanism. Base register와 limit register의 값으로 메모리의 범위를 정한다. 메모리 주소는 다른 프로세스 영역에 접근하면 안된다.

Address Binding

현대의 운영체제는 프로세스가 물리 메모리의 어떤 부분에도 상주할 수 있도록 한다.
컴파일러는 symbolic address를 relocatable address(= relative address)로 bind 한다.
링커와 로더는 relocatable address를 absolute address로 bind 한다.

Address Binding Time

Compile time: 만약 메모리 주소가 연역적인 것으로 알려지면, absolute code가 생성된다; 메모리 주소의 변경이 일어나면 반드시 코드를 다시 컴파일해야 한다. 현재는 거의 쓰이지 않는다.

Load time: 메모리 주소가 compile time에 알려지지 않았으면 반드시 relocatable code를 생성해야 한다.

Execution time: 만약 프로세스가 실행되는 동안 한 개의 메모리 구역에서 다른 구역으로 옮겨갈 수 있다면, 바인딩은 런타임까지 늦춰진다.

Logical vs. Physical Address Space

Physical address는 메모리 유닛에게 보여진다.
Logical address는 CPU에 의해서 생성된다.
compile time과 load time 바인딩 시에는 physical address와 logical address는 같은 주소를 가리킨다.
- 항상 같은 Physical address를 바인딩한다.
Execution time 바인딩 시에는 다르다.

Memory Management Unit (MMU)

Virtual address를 Physical Address로 매핑하는 하드웨어 장치

Relocation register를 가지고 있는 간단한 MMU

프로그램은 절대로 physical address를 볼 수 없다.
- 프로그램은 오로지 logical address 관점에서만 동작한다.
최종 physical address는 메모리에 접근될 때만 결정된다.

int a[10];
int *b;
b = a;
b = b + 4;
b = &b

위의 예에서, 5번째 줄에서 referencing을 할 때 메모리의 물리적 주소가 결정된다.

Dynamic Linking

Dynamic Linking: Execution time에 object 모듈을 연결하는 것

Static vs. dynamic linking
- Static linking: 로더에 의해서 시스템 라이브러리들이 바이너리 프로그램으로 결합된다.
- Dynamic Linking: Linking이 execution time까지 미뤄진다.
Dynamic Linking
- 프로그램 내에서 라이브러리를 호출하는 곳마다 stub이라는 작은 코드 조각이 생성된다.
- stub은 메모리 주소를 찾는 방법 또는 라이브러리를 메모리에 적재하는 법을 알고 있다.
- 라이브러리 버전을 업데이트할 때, static linking과 다르게 모든 프로그램을 재 컴파일할 필요가 없다.
- 운영체제의 도움이 필요하다.

Dynamic Linking을 사용하는 이유: 라이브러리 전체를 메모리에 복사하는 것보다는 프로그램 간의 중복된 라이브러리를 줄이기 위해

Swapping

프로세스를 실행하기 위해 필요한 메모리 공간이 물리 메모리의 용량을 넘어섰을 경우, swapping을 사용할 수 있다.

Swapping
- 메모리의 프로세스를 일시적으로 디스크로 옮기거나, 디스크로부터 읽어오는 기술 (예: Round-Robin CPU 스케줄러)

Contiguous Memory Allocation (연속 메모리 할당)

Multiple partition allocation

Fixed-sized partitions: batch 환경에서 주로 사용됨. 한 개의 파티션에 한 개의 프로세스가 위치한다. 더 이상 사용되지 않는 방법이다.
Variable partition size: 메모리의 어떤 부분이 사용 가능/불가능 한 지 나타내는 테이블을 사용한다.
- Hole: 사용 가능한 메모리 블록, 메모리 전체에 걸쳐서 흩어져있다. 프로세스가 메모리에 도착하면, 운영체제는 프로세스를 실행하기 위해 충분히 큰 블록을 찾는다.
사이즈 n의 요청을 어떻게 만족하지?
- First Fit: 프로세스를 실행하기 위해 충분히 큰 hole 중, 가장 첫 번째 hole을 할당시킨다.
- Best Fit: 프로세스를 실행하기 위해 충분히 큰 hole 중, 가장 작은 hole을 할당시킨다.
- Worst Fit: 가장 큰 hole을 할당시킨다.
보통 first fit과 best fit이 worst fit보다 더 나은 성능을 가진다.

[OpenStack에 contribute하기 - 5] Gerrit 사용하기 (2)

최성훈 — Mon, 20 Jan 2020 12:00:01 +0900

이번 포스트에서는, 변경 사항에 대해서 어떻게 추적하고, 각 리뷰 점수가 어떤 의미를 갖는지 알아보겠습니다.

변경사항 추적하기

변경사항을 제출하고 난 후, 여기서 변경사항을 추적할 수 있습니다. 로그인 후, 제출한 변경사항에 대해서 "Outgoing reviews", 리뷰하고 있는 변경사항에 대해서 "Incoming reviews", 본인이 리뷰어이거나 소유자인 변경사항에 대해 "Recently closed"인 대시보드를 볼 수 있습니다.

리뷰어 추가하기

때로는 우리의 패치에 대해서 의견을 내줄 사람들이 필요할 때가 있습니다. 왜냐하면 그 사람들은 여러 권한을 가지고 있을 수도 있고, 당신을 돕는 멘토일 수도 있기 때문입니다. 우리가 새로운 패치나 패치셋을 업로드했다는 것을 알리는 가장 쉬운 방법은 gerrit 웹 UI에서 그 사람들을 리뷰어로 추가하는 것입니다. 우리는 이름, gerrit 이메일 주소, ssh 사용자 이름 또는 gerrit ID로 검색할 수 있습니다.

리뷰어를 명시적으로 추가하기

일반적으로 패치마다 각 상호작용(새로운 패치셋, 코멘트, CI 시스템 투표 등)이 해당 패치에 대한 모든 리뷰어들에게 이메일 알림을 보낼 것이기 때문에 이 기능을 과도하게 사용하지 않는 것이 좋습니다.

만약 우리가 패치에 대해서 리뷰한다면 자동으로 리뷰어 목록에 추가됩니다.

Gerrit 웹 에디터

우리는 로컬에서 변경하지 않고 Gerrit 웹 인터페이스에서 패치를 편집하고 변경 내용을 게시할 수 있습니다. 작업하고 있는 로컬 브랜치가 자동으로 업데이트되지 않으므로, 양이 많은 코드 업데이트에는 일반적으로 권장되지 않습니다. 패치가 기본적으로 작은 pep8 failure(whitespace at the end of line, needing to wrap a line 등)을 제외하고 병합할 준비가 돼있는 몇몇 경우에, 이 gerrit 기능은 'git add', 'git commit --amend', 'git review' 과정을 거치지 않고 변경사항을 수정하고 게시하는데 매우 편리할 수 있습니다.

Gerrit 웹 에디터에 접근하기 위해, 파일의 Gerrit Code Review 페이지의 상단에 있는 패치셋 숫자 옆에 있는 종이 위에 글을 쓰고 있는 연필 같이 생긴 아이콘을 클릭하세요.

웹 브라우저로부터 변경사항 수정하기

변경사항 리뷰하기

거의 모든 레포지토리에서, Gerrit은 패치에 대해 5가지 투표 선택사항을 제공합니다. +2점과 -2점은 프로젝트의 핵심 리뷰 팀의 멤버들만 사용할 수 있습니다. 모두가 -1점과 +1점을 투표할 수 있습니다. 우리는 0점으로 아무 투표 없이 코멘트를 남길 수도 있습니다. 모든 경우에 우리는 최선의 판단을 하지만, 우리를 가이드하기 위해 커뮤니티의 경험으로부터 이러한 휴리스틱을 제공합니다.

OpenStack을 발전시키는 것은 패치 커미터들입니다. 리뷰어로써, 우리가 커미터들에게 서비스를 제공한다는 것을 기억하세요. 그 반대가 아닙니다. 커미터로써, 모든 사람이 동일한 규칙을 적용받는다는 것을 기억하세요. 우리의 패치에 투표하는 핵심 리뷰어들도 그들의 검토사항에 대해 동일한 리뷰 과정을 거칩니다.

Code Review +2

+2점의 투표는 핵심 리뷰어들만 사용할 수 있습니다. 일부 프로젝트에서는 +2점 만을 요구하고, 많은 프로젝트에서는 특정 상황(사소한 변경 등)에서 요구사항을 완화하지만, 변경사항이 병합되기 전에 2개의 +2점을 요구하도록 권장됩니다. 만약 핵심 리뷰어인 경우, 로컬 정책을 확인하세요. 헷갈리지만, 2개의 +1점과 +2점은 같은 게 아닙니다!

승인 없이 +2점을 투표하는 것은 다른 핵심 리뷰어가 변경사항을 승인하는 것에 만족한다는 것을 나타냅니다. 만약 다른 핵심 리뷰어가 이미 +2점을 투표했다면, 우리는 일반적으로 동시에 변경사항을 승인할 것입니다. 하지만 작성자나 다른 리뷰어가 적절하다고 생각될 경우, 사소한 피드백에 응답할 기회를 주기 위해 승인을 보류할 수 있습니다. 만약 피드백이 충분히 사소한 것이라면, +1점만 투표하는 것이 더 바람직합니다.

만약 다른 핵심 리뷰어가 이전의 패치셋에서 +2점을 투표했고, 해당 패치 이후 리뷰어들이 충분히 만족할 것으로 확신할 수 있는 사소한 방식으로만 변경된 경우, 다시 검토하기를 기다리지 말고 +2점으로 승인하세요. 이렇게 할 때에는 왜 그런 결정을 내렸는지 설명하는 코멘트를 남기세요.

Code Review +1

핵심 리뷰어가 아닌 경우, +1점은 변경사항을 검토했으며, 변경사항을 병합하는데 만족한다는 것을 나타냅니다. 우리의 기록이 핵심 리뷰 팀에게 알려지지 않는 경우, 코멘트 없이 +1점만 남기는 것은 그다지 유용하지 않습니다. (이 경우 곧 핵심 리뷰 팀에게 알려질 가능성이 큽니다.) 변경사항이 합당한 경우, 코멘트를 남기세요. 만약 패치를 테스트한 경우, 그렇게 말하세요: 올바른 패치인지 확인하기 위해 참조한 어떤 것이라도 있다면, 다음 리뷰어를 위해서 참조 링크와 함께 코멘트를 남기세요.

핵심 리뷰어들도 +1점을 사용할 수 있습니다. 패치가 괜찮다고 생각하지만 열린 질문이 있거나, 후속 변경에서 고칠 수 있는 사소한 피드백이 있지만 그 기여자에게 변경사항을 스스로 고칠 수 있는 기회를 주고 싶을 때 +1점을 주는 것을 고려해보세요. 예를 들어, 리뷰어들도 우리의 의견을 원하거나 우리를 도와주고 싶어 하기 때문입니다. 만약 기여자가 멘토를 찾고 있는지, 아니면 패치를 수정하거나 후속 변경사항을 직접 제출하기를 원하는지 확실하지 않은 경우, 직접 물어보세요! 많은 기여자들이 핵심 리뷰어들의 +1점에 빠르게 응답할 것입니다. 왜냐하면 기여자들은 그것이 +2점에 거의 다 왔다는 것을 알고 있고, 이것이 기여자를 격려하고 호의를 베푸는 데 -1점보다 훨씬 낫기 때문입니다.

핵심 리뷰어들조차 프로젝트의 모든 부분에 익숙하지 않을 수 있습니다. 자신 없는 영역에서 변경사항이 생기면 +1점을 투표할 수 있고, 그렇지 않다면 +2점을 투표하면 됩니다. 항상 그렇듯이, 왜 그런지 말하는 코멘트를 남기는 것이 도움이 됩니다.

Code Review 0

만약 우리가 변경 사항에 대해서 어떤 쪽이든 강한 느낌을 가지고 있지 않거나, 의견을 결정하기 위해 대답해야 할 질문이 있다면, 리뷰 없이 코멘트를 남길 수 있습니다. 만약 우리가 질문에 대한 답이 문제를 드러낼 것이라고 확신이 안 든다면, 처음에 -1점을 투표하는 것이 낫습니다. -1점이 없는 코멘트는 실수로 놓치기 쉬우므로, 답변이 없는 채로 시간이 꽤 지났거나, 우리의 코멘트에 아무도 답변을 하지 않고 새 패치셋이 게시된 경우, IRC로 제출자에게 연락하거나 -1을 고려해봐야 할 때일 수도 있습니다.

Code Review -1

-1점을 사용해서 변경사항이 병합되기 전에 패치가 수정되어야 한다고 굳게 믿는 문제를 발견했다는 것을 알리세요. 변경사항에 의해 유발된 새로운 버그부터 커밋 메시지의 오타(만약 git 기록에서 핵심 단어에 패치를 찾기 어렵게 만드는 오타가 있는 경우)처럼 사소한 것에 이르기까지 -1점을 주는 여러 가지 이유가 있습니다. 다시 한번, 최선의 판단을 하되, -1점을 투표할 때는 우리가 다른 사람의 일을 방해하는 것이므로 다른 방법(예: 후속 조치 변경)으로 해결할 수 없는 타당한 이유인지 확인하세요.

많은 리뷰어들이 이미 부정적인 리뷰가 있는 변경사항에 대해 우선순위를 두지 않을 것이라는 것을 기억하세요. 따라서 -1점을 투표함으로써 제출자에게 다른 개선을 요구하는 것뿐만 아니라, 더 많은 피드백으로부터 -1점을 잠재적으로 차단할 수 있습니다.

-1점의 리뷰에는 항상 실행 가능한 피드백이 포함된 코멘트가 동반되어야 합니다.

만약 많은 수의 패치셋이 있는 변경사항에 대해 리뷰할 경우, 이상한 점이 보이는지 이전의 기록을 돌아보는 것을 잊지 마세요. 그게 이전의 리뷰어에 의해 요청되었을지도 모릅니다. 만약 우리가 핵심 리뷰어이고, 우리가 다른 핵심 리뷰어에 의해 주어진 조언에 반대되는 조언을 할 필요가 있다고 생각한다면, 다른 리뷰어와 합의에 도달하는 것이 우리의 책임이고, 둘 다 문서화하는 것이 이상적입니다. -1점을 투표하기 전에, 변경사항이 무언가 망가트리지 않는 이상(이 경우, 상충되는 의견이 있고, 그 문제를 가능한 한 빨리 해결하기 위해 작업 중이라는 것을 알리는 코멘트를 남기세요), 핵심 리뷰어들 간의 의견 불일치를 다루는 것은 패치 제출자의 책임이 아닙니다.

Code Review -2

+2점의 투표는 핵심 리뷰어들만 사용할 수 있습니다. 다른 투표와 다르게, -2점은 'sticky'합니다. -2점은 제출자가 새로운 패치를 푸시해도 변경되지 않습니다. 즉, -2점을 지우려면 동일한 핵심 리뷰어의 조치가 필요하므로 주의하세요. -2점의 목적은 변경 제출자에게 그 변경 사항에 대해 작업하는 시간은 분명히 낭비될 것이라는 것을 알리는 것입니다. 만약 변경사항에 대해 -2점의 리뷰를 받는다고 기분 나쁘게 생각하지 마세요! 그 리뷰어는 우리의 소중한 시간과 에너지를 병합될 가능성이 있는 변화로 돌리려고 하는 것입니다.

-2점의 리뷰는 항상 그 변경사항이 프로젝트의 목표에 부합하지 않는 이유를 설명하는 코멘트를 첨부해서, 제출자가 그 이유를 이해하고 추후의 기여에 대해서 더 생산적으로 집중할 수 있도록 해야 합니다.

아래의 'Procedural Code Review -2'를 제외하고, -2점의 적법한 용도는 없습니다.

Procedural Code Review -2

일부 프로젝트에서는 Feature Freeze 후, 다음 릴리즈로 branching 하기 전에 Feature Freeze 동안 의도치 않게 기능이 병합되지 않도록 변경사항에 대해 -2점을 투표합니다. -2점을 투표한 사람은 마스터 브랜치가 새로운 기능을 위해 다시 열리면 -2점을 제거할 것입니다. -2점을 투표한 사람들은 무슨 일이 일어나고 있는지 설명하는 코멘트를 남겨야 합니다. 제출자들은 Freeze 기간 동안 변경 사항을 계속 수정할 수 있습니다.

Workflow -1

Workflow -1점은 변경사항이 현재 전체적인 리뷰를 위한 준비가 되어있지 않음을 나타냅니다. 핵심 리뷰어와 변경 소유자만 Workflow -1점에 투표할 수 있습니다. 모든 Workflow 투표는 새 패치셋을 제출할 때마다 삭제됩니다. 이것은 (명시적으로 추가되지 않은 리뷰어들로부터 가려진) Draft 변경사항의 레거시 방법보다 진행 중인 작업에 대해 피드백을 얻는 더 나은 방법입니다.

핵심 리뷰어들도 코드 리뷰 프로세스를 중단하지 않고 일시적인 조건 중 변경사항이 병합되는 것을 방지하기 위해 Workflow -1점에 투표할 수 있습니다.

Workflow +1

Workflow +1점은 변경사항이 핵심 리뷰어로부터 승인될 때 사용됩니다. Workflow +1점 없이 아무리 2개의 Code Review +2점을 받았다고 하더라도 변경사항은 병합되지 않습니다.

다른 변경사항 살펴보기

Gerrit에서 다른 기여자의 패치를 확인하고 변경할 수 있지만, 작업하기 전에 항상 그 기여자와 변경사항에 대해 논의해야 합니다.

git-review -d <change ID>

<change ID>는 Gerrit의 web UI에서 찾을 수 있습니다.

변경사항의 change ID

패치에 대해 체크아웃한 후, 자동으로 새로운 브랜치로 변경될 것이고, 거기서 우리는 새로운 변경사항에 대해 작업할 수 있습니다.

Cherry-picking

만약 우리의 커밋이 작업을 시작한 후 업데이트된 변경사항에 대해 의존적이고, 해당 변경사항으로부터 새로운 패치셋을 가져와야 할 경우, 우리의 변경사항 위로 cherry-pick을 할 수 있습니다.

git-review -x <change ID>

<change ID>는 이전의 경우와 동일합니다.

Merging

만약 변경사항이 승인되고 게이트 작업을 통과하면 Gerrit은 자동으로 최신 패치셋을 병합합니다.

각 패치셋은 테스트하기 전에 브랜치의 HEAD에 병합됩니다. Gerrit이 패치셋을 병합할 수 없는 경우, -1점 리뷰를 주고 병합 실패에 대한 코멘트를 추가합니다.

변경사항이 병합될 때마다, "merge-check" 파이프라인은 동일한 프로젝트에 열려있는 모든 변경사항이 여전히 병합 가능한지 검증합니다. 만약 어떤 작업이든 병합할 수 없다면, Zuul은 -1점의 리뷰를 주고, 병합 실패에 대한 코멘트를 추가합니다.

변경사항이 병합된 후에는, 프로젝트별로 사후 작업이 실행됩니다. 대부분의 post 작업은 문서를 게시하거나, coverage를 실행하거나, 번역 서버에 문자열을 전송합니다.

Project Gating

프로젝트 게이팅은 개발자의 패치셋이 병합되기 전에 회귀 테스트(regression test)를 실행하는 과정을 말합니다. 회귀 테스트를 실행하는 목적은 소스 코드 저장소에 제출된 새로운 변경사항이 새로운 버그를 유발하지 않는지 검증하는 것입니다. 게이팅은 일련의 테스트가 성공적으로 통과된 후에 패치셋이 개발의 주류로 병합되도록 함으로써 퇴보를 방지합니다.

게이팅에 사용되는 시스템은 Zuul로, Gerrit 이벤트 스트림을 listen 하고 YAML 파일로 구성하여 이벤트에 응답하여 실행할 일련의 테스트를 정의합니다.

대기열의 작업은 핵심 리뷰어가 변경사항을 승인하고(+1 Workflow를 사용하여) verified 된 +1점 투표가 존재하면 실행됩니다. 승인 시 최소 1개의 +2점 코드 리뷰 투표가 존재해야 합니다. (핵심 리뷰어가 승인할 때 부여할 수 있습니다.) 즉, 이 컨벤션은 승인을 위해 2개의 +2점 코드 리뷰가 필요하다는 것입니다.

구성된 게이트 파이프라인에서 승인된 패치셋에 대해 모든 작업이 성공하면, Gerrit은 trunk로 코드를 병합할 것입니다.

게이트 테스트를 실행하는 것 외에도, 게이트 파이프라인은 여러 프로젝트들에 대해서 병합하기 위한 변경사항들의 순서를 결정합니다. 변경사항들은 이 순서에 따라 테스트되고 병합되므로, 각 변경사항에 대해 다른 모든 레포지토리의 상태를 확인할 수 있습니다.

여기서 각 작업들의 상태를 확인할 수 있습니다.

https://zuul.openstack.org/에 접속하면 볼 수 있는 화면. 현재 zuul에서 동작하고있는 모든 작업들의 상태를 나타낸다.

본 포스트는 다음 주소를 참고하였습니다.

[백준 17822번] 원판 돌리기

최성훈 — Thu, 16 Jan 2020 15:22:15 +0900

문제 보기

이 문제는 BFS와 시뮬레이션 문제이다.

갈수록 삼성 SW 역량 테스트의 문제가 점점 더 구현에 까다로운 조건을 추가하기 시작하는 게 느껴진다.

먼저, 문제를 풀기 위해 원판의 숫자를 어떻게 표현할 것인지에 대해서 생각해보아야 한다.

문제에서 주어진 원판을 행렬로 표현하면 다음과 같다.

원판을 행렬로 나타낸 그림

이제 원판을 행렬로 나타냈으니, 원판을 회전시키는 함수를 작성한다.

i번째의 원판을 회전시킬 때, i의 배수인 원판 모두 회전을 시켜야 한다.

이 부분에 대한 구현은 13~27번째 줄에 다음과 같이 구현되어 있다.

def rotate(_x, _d, _k):
	# rotate counter-clockwise
	if _d:
		# for all disks which is multiple of x
		for i in range(_x, n + 1, _x):
			temp = deque(disk[i][1:])
			temp.rotate(-(_k % m))
			disk[i][1:] = temp
	# rotate clockwise
	else:
		# for all disks which is multiple of x
		for i in range(_x, n + 1, _x):
			temp = deque(disk[i][1:])
			temp.rotate(_k % m)
			disk[i][1:] = temp

deque 자료형은 built-in 함수로 rotate 함수를 제공한다.

그래서 나는 주어진 원판의 행렬에서 각 행을 deque 자료형으로 바꾸고, 회전시켜주었다.

지금 생각해보니 list형이 아니라 deque형으로 원판의 숫자를 읽어도 될 것 같다.

문제를 해결하기 위한 기본적인 함수를 작성했으니, 이제 문제에서 주어진대로 문제를 풀면 된다.

문제를 푼 로직은 다음과 같다.

주어진 횟수만큼 문제에서 언급한 대로 원판을 회전시킨다. (31~33번째 줄)
원판을 회전시킨 후, 모든 칸에 대한 BFS를 통해 인접하면서 같은 숫자를 찾는다. (35~63번째 줄, 70번째 줄)
BFS를 통해 찾은 인접한 숫자 중 같은 숫자가 있다면 그 숫자들을 원판에서 지운다. (65~68번째 줄)
BFS를 통해 찾은 인접한 숫자 중 같은 숫자가 없다면, 원판에 적힌 숫자들의 평균을 구하고, 평균보다 큰 수에서 1을 빼고 평균보다 작은 수에는 1을 더한다. (72~90번째 줄)

이 문제가 까다로운 점은 숨은 조건이 있다는 것이다.

먼저 첫 번째 숨은 조건은 2번에 있다.

우리는 먼저 원판을 행렬로 표현했다. 하지만 여기서 주의할 점은, 원판에서 인접한 숫자는 행렬의 양쪽 끝도 인접해있다는 것이다.

다음의 그림을 보면 이해하기 쉽다.

원판에서 인접한 숫자를 찾기 위한 숨은 조건

따라서 BFS를 통해 인접하면서 같은 숫자를 찾기 위해서는 이 숨은 조건 또한 포함해야 한다.

이 숨은 조건은 56~63번째 줄에 구현되어 있다.

사실 이 조건은 이미 문제에 제시되어 있지만, 간과하기 쉬운 조건이다.

문제에 제시돼있는 인접한 수의 조건

두 번째 숨은 조건은 원판에 적힌 숫자들의 평균을 구할 때이다.

백준의 예제 입력에서는 찾을 수 없는 조건이지만, 19년 하반기 삼성전자 SW 역량 테스트의 예제 입력에서 찾을 수 있는 조건이었다.

원판에서 평균을 구할 때 0이 아닌 숫자를 찾아야 하는데, 이때 0이 아닌 숫자가 없다면 division by zero 에러가 발생한다.

따라서 이 부분에 대해서도 조건 검사를 해주어야 한다.

이 숨은 조건은 80~82번째 줄에 구현되어 있다.

import sys
from collections import deque

# initialize
n, m, t = map(int, sys.stdin.readline().split())
disk = [[0 for _ in range(m + 1)] for _ in range(n + 1)]
for r in range(1, n + 1):
	line = list(map(int, sys.stdin.readline().split()))
	for c in range(1, m + 1):
		disk[r][c] = line[c - 1]


def rotate(_x, _d, _k):
	# rotate counter-clockwise
	if _d:
		# for all disks which is multiple of x
		for i in range(_x, n + 1, _x):
			temp = deque(disk[i][1:])
			temp.rotate(-(_k % m))
			disk[i][1:] = temp
	# rotate clockwise
	else:
		# for all disks which is multiple of x
		for i in range(_x, n + 1, _x):
			temp = deque(disk[i][1:])
			temp.rotate(_k % m)
			disk[i][1:] = temp


directions = ((0, 1), (1, 0), (0, -1), (-1, 0))
for _ in range(t):
	x, d, k = map(int, sys.stdin.readline().split())
	rotate(x, d, k)
	
	found = False
	total_visited = set()
	for r in range(1, n + 1):
		for c in range(1, m + 1):
			if (r, c) not in total_visited:
				q = deque([(r, c)])
				visited = set([(r, c)])
				
				# BFS
				while q:
					cur_r, cur_c = q.pop()
					
					# for 4 adjacent numbers
					for dr, dc in directions:
						next_r = cur_r + dr
						next_c = cur_c + dc
						if 0 < next_r <= n and 0 < next_c <= m and (next_r, next_c) not in visited:
							# if it's the same number
							if disk[next_r][next_c] and disk[cur_r][cur_c] == disk[next_r][next_c]:
								q.appendleft((next_r, next_c))
								visited.add((next_r, next_c))
					# hidden condition for circular disk
					if disk[cur_r][cur_c]:
						if (cur_r, m) not in visited and cur_c == 1 and disk[cur_r][cur_c] == disk[cur_r][m]:
							q.appendleft((cur_r, m))
							visited.add((cur_r, m))
						elif (cur_r, 1) not in visited and cur_c == m and disk[cur_r][cur_c] == disk[cur_r][1]:
							q.appendleft((cur_r, 1))
							visited.add((cur_r, 1))
				
				if len(visited) > 1:
					for vr, vc in visited:
						disk[vr][vc] = 0
					found = True
				
				total_visited |= visited
					
	if not found:
		count, average = 0, 0
		for i in range(1, n + 1):
			for j in range(1, m + 1):
				if disk[i][j]:
					count += 1
					average += disk[i][j]
		
		# filter divide by zero
		if count:
			average /= count

		for i in range(1, n + 1):
			for j in range(1, m + 1):
				if disk[i][j]:
					if disk[i][j] > average:
						disk[i][j] -= 1
					elif disk[i][j] < average:
						disk[i][j] += 1
	
print(sum(map(sum, disk)))

[백준 17837번] 새로운 게임 2

최성훈 — Tue, 14 Jan 2020 17:22:07 +0900

문제 보기

이 문제는 알고리즘 분류는 되어있지 않지만, 시뮬레이션 문제라고 생각한다.

갈수록 삼성의 SW 역량 테스트가 점점 어려워지는 게 느껴진다.

개인적으로 문제를 읽자마자 스택/큐의 개념이 떠올랐지만, 막상 파이썬으로 구현하니 스택/큐를 쓸 일이 없었다.

또한 C/C++의 포인터를 쓰고 싶었지만, 파이썬에는 포인터의 개념이 없기 때문에 해결법을 구상하는데 꽤나 오랜 시간이 걸렸다.

문제를 풀기 전, 중요한 변수가 3개 있다.

board_info: 체스판의 색깔 정보를 담고있는 변수
board: 체스판 위의 체스말 정보를 담고 있는 변수
chess_pieces: 체스말 리스트 (각 체스 말의 행, 열과 방향을 담고 있다.)

이를 가지고 문제를 해결하였다.

문제를 푼 로직은 다음과 같다.

체스 말이 다음에 이동할 곳의 정보를 얻는다. (만약 다음 칸이 체스판 바깥이거나 파란색이라면 방향만 바꿔준다.) (51~52번째 줄)
만약 다음에 이동할 칸이 현재 위치와 같다면(= 다음 칸이 체스판 바깥이거나 파란색이라면) 다음 체스 말로 넘어간다. (체스 말의 방향은 1번에서 이미 바뀌었다.) (54~56번째 줄)
현재 칸에서 이동할 말을 기준으로 현재 칸에 있는 체스 말들을 이등분한다. (58~60번째 줄)
만약 다음에 이동할 칸이 흰색이라면 체스말들을 옮기고, 체스 말들의 위치를 업데이트한다.(= chess_pieces의 값을 업데이트한다.) (62~67번째 줄)
만약 다음에 이동할 칸이 빨간색이라면 체스말들의 순서를 뒤집어서 옮기고, 체스말들의 위치를 업데이트한다. (68~73번째 줄)
만약 체스 말을 옮긴 곳에 체스 말이 4개 이상이라면 현재 턴을 출력하고 종료한다.
각 턴마다 모든 체스 말에 대해 위 작업을 반복하고, 턴이 1000 이상이면 -1을 출력한다. (48~50번째 줄, 79번째 줄)

3번부터 5번의 과정을 그림으로 요약하자면 다음과 같다.

체스판의 파란색 칸은 2번 과정을 실행하면서 자동으로 처리된다. (이는 코드의 흐름을 따라가다 보면 이해할 수 있다.)

중요한 점은, 체스 말을 이동시키고 chess_pieces 리스트 안에 있는 체스 말의 정보도 업데이트해주어야 한다.

백준에서 프로그램을 종료할 때, exit()를 호출하였는데 자꾸 런타임 에러가 떴다. 구글링을 해보니 sys.exit(0)을 호출해야 런타임 에러 없이 정상적으로 채점이 되는 것 같다.

import sys

n, k = map(int, sys.stdin.readline().split())
board_info = [[0 for _ in range(n + 1)] for _ in range(n + 1)]
board = [[list() for _ in range(n + 1)] for _ in range(n + 1)]
chess_pieces = [0]

# initial board information
for i in range(1, n + 1):
	line = list(map(int, sys.stdin.readline().split()))
	for j in range(1, n + 1):
		board_info[i][j] = line[j - 1]

# initial chess pieces and board
for idx in range(1, k + 1):
	r, c, direction = map(int, sys.stdin.readline().split())
	chess_pieces.append([r, c, direction])
	board[r][c].append(idx)
	

# returns false if it's blue or out of boundary
def boundary_and_blue_check(_r, _c):
	if _r < 1 or _r > n or _c < 1 or _c > n:
		return False
	if board_info[_r][_c] == 2:
		return False
	return True


# returns current position if it's blue or out of boundary
def get_next_pos(_r, _c, _d):
	next_r, next_c, next_d = _r, _c, _d
	# if next position is white or red
	if boundary_and_blue_check(next_r + directions[next_d][0], next_c + directions[next_d][1]):
		next_r, next_c = next_r + directions[next_d][0], next_c + directions[next_d][1]
	# if next position is blue or out of boundary
	else:
		next_d = next_d + 1 if next_d % 2 else next_d - 1
		# if next position is white or red
		if boundary_and_blue_check(next_r + directions[next_d][0], next_c + directions[next_d][1]):
			next_r, next_c = next_r + directions[next_d][0], next_c + directions[next_d][1]
			
	return next_r, next_c, next_d


directions = ((), (0, 1), (0, -1), (-1, 0), (1, 0))
turn = 0
while turn <= 1000:
	turn += 1
	for idx, piece in list(enumerate(chess_pieces))[1:]:
		r, c, d = chess_pieces[idx][0], chess_pieces[idx][1], chess_pieces[idx][2]
		next_r, next_c, chess_pieces[idx][2] = get_next_pos(r, c, d)
		
		# no need to move chess pieces because it's blue or out of boundary
		if r == next_r and c == next_c:
			continue
		
		# split chess pieces into 2
		base_index = board[r][c].index(idx)
		board[r][c], temp_list = board[r][c][:base_index], board[r][c][base_index:]
		
		# white
		if board_info[next_r][next_c] == 0:
			# move and update position of chess pieces
			board[next_r][next_c].extend(temp_list)
			for i in temp_list:
				chess_pieces[i][0], chess_pieces[i][1] = next_r, next_c
		# red
		elif board_info[next_r][next_c] == 1:
			# move and update position of chess pieces
			board[next_r][next_c].extend(reversed(temp_list))
			for i in temp_list:
				chess_pieces[i][0], chess_pieces[i][1] = next_r, next_c
		
		if len(board[next_r][next_c]) >= 4:
			print(turn)
			sys.exit(0)
			
print(-1)

[운영체제] 동기화 (2)

최성훈 — Tue, 14 Jan 2020 14:21:01 +0900

Bounded-Buffer 문제 (유한버퍼 문제)

소비자와 생산자가 유한 개의 버퍼 자원을 공유하는 상황에서, 다음 문제를 해결하고자 한다.

소비자와 생산자가 버퍼에 상호 배타적으로 접근
소비자는 버퍼에 원소가 한 개라도 있으면 버퍼를 소비해야 하고, 생산자는 버퍼에 원소가 없으면 원소를 생산해야 한다.

Bounded-Buffer 문제 해결을 위한 코드

위의 문제를 해결하기 위한 조건은 다음과 같다.

생산자가 먼저 실행된 적이 있어야 하고, 생산자의 실행 횟수가 소비자보다 많아야 한다.

위 문제를 해결하기 위해 사용하는 변수는 다음 세 가지이다.

세마포어 mutex(= 1): 생산자와 소비자의 상호배제를 위한 변수
세마포어 empty(= n): 비어있는 버퍼의 개수를 나타내는 변수
세마포어 full(= 0): 버퍼가 차있는 개수를 나타내는 변수

Reader-Writer 문제 (독자-저자 문제)

여러 개의 reader는 공유 데이터를 동시에 읽는 것이 가능한 반면에, writer는 reader가 공유 데이터를 읽는 동안 공유 데이터에 접근해서 수정할 수 없다.

Reader-Writer 문제는 2가지가 있다.

First reader-writer problem: writer가 대기하고 있다고 해서 reader가 다른 reader를 기다리면 안 된다. 마지막 reader가 공유자원을 release 하면 writer가 임계구역으로 진입한다.
Second reader-writer problem: 만약 writer가 대기하고 있다면, 어떠한 새로운 reader도 실행될 수 없다.

위 두 가지 모두 starvation의 가능성이 있다.

새로운 reader가 계속 들어오면 writer는 계속 기다려야 한다.
새로운 writer가 계속 들어오면 reader는 계속 기다려야 한다.

First reader-writer 문제 해결을 위한 코드

First reader-writer 문제 해결을 위해 사용하는 변수는 다음 세 가지이다.

세마포어 rw_mutex (= 1): reader와 writer의 상호배제를 위한 변수
세마포어 mutex (= 1): read_count를 갱신하기 위한 reader 간의 상호배제를 위한 변수
정수 read_count (= 0): 공유자원을 읽고 있는 reader의 개수를 나타내는 변수

위의 코드는 reader가 수행되는 동안 writer가 임계구역에 진입하는 것을 배제함으로써 First reader-writer 문제를 해결하지만, 이는 writer에게 starvation을 야기할 수 있다.

Dining-Philosophers 문제 (식사하는 철학자 문제)

철학자 5명이 원형 테이블에 앉아있다.

각 철학자들은 식사를 하기 위해서 젓가락 2개가 필요하며, 젓가락은 철학자의 왼쪽과 오른쪽에 위치한다.

각 철학자들은 한 번에 한 개의 젓가락만 집을 수 있다.

철학자가 식사를 하지 않는 동안에는 생각을 하는데, 생각을 하는 동안 다른 철학자들과 교류하지 않는다.

여기서 일반적인 해결법은 다음과 같다.

왼쪽의 코드는 각 철학자들이 자신의 왼쪽 젓가락을 먼저 집고, 오른쪽 젓가락을 집는다.

젓가락을 다 집은 후, 식사를 하고 다시 왼쪽 젓가락을 놓고 오른쪽 젓가락을 놓는다.

만약 한 명의 철학자가 젓가락을 모두 집어 든다면 그 철학자는 식사할 수 있고, 다른 철학자는 그 철학자의 식사가 끝날 때까지 대기한다.

하지만 모든 철학자가 동시에 자신의 왼쪽의 젓가락을 집어 드는 경우 Deadlock이 발생한다.

따라서 이 방법은 올바른 해결법이 아니다.

Deadlock 문제를 해결하기 위해 다음과 같은 3가지 방법이 존재한다.

5명의 철학자 중 4명만 식사를 할 수 있게 한다.
양쪽의 젓가락을 집을 수 있을 때, 동시에 그 젓가락을 집게 한다.
홀수번째 철학자는 왼쪽-오른쪽 순으로, 짝수번째 철학자는 오른쪽-왼쪽 순으로 젓가락을 집게 한다.

[운영체제] 동기화 (1)

최성훈 — Fri, 10 Jan 2020 00:05:34 +0900

Bounded-Buffer 문제 (유한 버퍼 문제)

생산자와 소비자

생산자(Producer)는 데이터를 생성하고, 소비자(Consumer)는 데이터를 소비한다.

생산자가 데이터를 생산하면 in이 증가하고, 소비자가 데이터를 소비하면 out이 증가한다. in과 out이 같은 경우, 버퍼가 가득 찼는지 비어있는지 확인할 수 없다.

in과 out의 값으로는 버퍼에 있는 데이터의 양을 알 수가 없다. (위의 그림 참조) 따라서 counter 변수를 사용한다. 하지만 counter 변수는 생산자와 소비자가 동시에 접근하므로 Race condition이 발생한다. 따라서 동기화가 필요하다.

Race condition
- 여러 프로세스(또는 스레드)가 공유자원에 동시에 접근할 때, 접근 순서에 따라 결과가 달라질 수 있는 상황

Synchronizaiton (동기화)

Multi-threaded application
- 스레드는 프로세스 안에서 메모리를 공유한다. (스택은 별개로 가진다.) 데이터 손상을 막기 위해서는 동기화가 필요하다.
  - 특히, Silent corruption에 주의가 필요하다.
    - OS나 디스크 펌웨어가 데이터가 잘못됐다고 인식하지 못하는 corruption. 심각한 에러를 초래할 수 있다.
Kernel mode
- 커널 자료구조 업데이트
  - 여러 프로세스가 동시에 커널 모드로 들어갈 수는 있지만 동시에 커널 데이터는 수정이 불가능해야 한다.
- Preemptive 커널 vs. Nonpreemtive 커널
  - Nonpreemtive 커널
    - Race condition이 없다.
    - 대신 반응이 느리다.
  - Preemptive 커널
    - Real time system에서 빠른 응답이 필요하기 때문에 사용한다.

Critical Section 문제 (임계구역 문제)

일반적인 프로세스의 실행구조

Entry section
- 임계구역으로 진입하기 전의 구역
Critical section (임계구역)
- 여러 프로세스들이 공유자원을 수정할 가능성이 있는 코드 구역
- 만약 하나의 프로세스가 임계구역에 있다면, 다른 어떤 프로세스도 진입해서는 안된다.
Exit section
- 임계구역을 벗어남을 알리기 위한 구역
Remainder section
- 코드의 나머지 부분

Critical Section 문제의 3가지 해결 조건

아래 3가지 요구사항을 만족시켜서 Critical Section 문제를 해결하겠다.
- Mutual exclusion (상호배제)
  - 임계구역에서 한 개의 프로세스가 작업 중일 때, 다른 프로세스는 접근할 수 없다.
- Progress (진행)
  - 임계구역에서 작업 중인 프로세스가 없고, 임계구역으로 진입하려는 프로세스가 있다면 하나를 적절히 선택하여 진입할 수 있게 한다. 선택은 즉각적이다.
- Bounded waiting (유한대기)
  - 다른 프로세스들의 Starvation을 방지하기 위해, 한 번 임계구역에 들어간 프로세스는 다시 임계구역에 들어갈 때 횟수에 제한을 두어야 한다.

Critical Section의 소프트웨어적 해결방법

Peterson's Algorithm

프로세스 i의 실행구조

프로세스가 2개일 때만 사용 가능
프로세스 i와 프로세스 j가 공유하는 자원
- int turn: 임계구역에 진입할 프로세스는 누구인가
- boolean flag[2]: 임계구역에 프로세스가 진입할 준비가 되어있는가
Mutual exclusion (상호배제) - 만족
- 프로세스 i가 임계구역의 진입할 준비가 되었고, turn = j로 설정함으로써 프로세스 i는 무한루프에 빠져 대기상태가 되고, 프로세스 j가 임계구역에 진입한다.
Progress (진행) - 만족
- 프로세스 j가 임계구역에서 작업을 마치고 flag[j] = false가 되면 프로세스 i는 곧바로 임계구역으로 진입한다.
Bounded waiting (유한대기) - 만족
- 프로세스 j가 임계구역에서 작업을 마치면 프로세스 i가 임계구역으로 진입하여 기아 현상이 사라진다.

피터슨 알고리즘의 단점으로는 아무 일도 안 하는 대기상태를 while문으로 구현하였는데, 이는 busy waiting으로써 CPU 자원을 낭비한다.

Critical Section의 하드웨어적 해결방법

test_and_set

임계구역에 프로세스가 있을 때 lock은 true, 프로세스가 없으면 lock은 false이다.

test_and_set 인스트럭션 구조

test_and_set을 사용한 프로세스의 실행구조

만약 임계구역에 어떤 프로세스도 없는 상태에서 test_and_set을 호출하면 결괏값은 false를 반환하고, lock은 true가 된다. 따라서 임계구역의 진입하려는 프로세스는 while문을 빠져나오고 임계구역에 진입하게 된다.

임계구역에서 작업을 마친 프로세스는 lock = false를 통하여 다른 프로세스가 임계구역에 진입하기 위해 경쟁할 수 있도록 해준다.

위의 코드는 starvation의 가능성이 있다.

compare_and_swap

임계구역에 프로세스가 있을 때 lock은 1, 프로세스가 없을 때 lock은 0이다.

compare_and_swap 인스트럭션 구조

compare_and_swap을 사용한 프로세스의 실행구조

test_and_set과 다르게 3개의 매개변수가 필요하다. lock의 메모리 주소, lock의 기댓값 그리고 lock을 설정할 값이다.

만약 임계구역에 프로세스가 없다면 compare_and_swap은 0을 반환하고, lock을 1로 설정한다. 따라서 임계구역에 진입하려는 프로세스는 while문을 빠져나오고 임계구역에 진입하게 된다.

임계구역에서 작업을 마친 프로세스는 lock = 0를 통하여 다른 프로세스가 임계구역에 진입하기 위해 경쟁할 수 있도록 해준다.

위의 코드는 starvation의 가능성이 있다.

Mutex와 Semaphore

Mutex

위에서 설명한 하드웨어적 해결방법들은 프로그래머가 다루기 어렵고, 플랫폼에 종속적이다.

따라서 대부분의 운영체제는 프로그래머를 위해 API를 제공해주는데, mutex이다.

acquire와 release, 그리고 프로세스의 실행구조

Mutex도 test_and_set과 비슷한 구조로 작동함을 알 수 있다.

Mutex의 acquire 함수를 보면, 임계구역에 진입하려는 프로세스들을 blocking 하기 위해 busy waiting을 사용하는 것을 알 수 있다. 이를 spinlock이라고 부르며 마찬가지로 CPU 사이클을 낭비한다.

Semaphore

Mutex보다 조금 더 강력한 대안으로 semaphore가 있다. Semaphore는 정수형 변수 S에 대해 wait, signal이라는 atomic 한 함수를 사용한다.

Semaphore에는 2가지가 있다.

Binary semaphore
- S의 값으로 0과 1만 사용하며, mutex lock과 비슷하게 사용한다.
Counting semaphore
- S는 사용 가능한 자원의 개수를 나타내며, 2 이상의 정수 값을 가진다.

wait와 signal 그리고 프로세스의 실행구조

사용 가능한 자원 S가 0보다 크다면 임계구역에 진입할 수 있고, 프로세스가 임계구역에 진입한다면 S를 감소시킨다.

만약 프로세스가 임계구역에 진입하려고 할 때 S가 0보다 같거나 작다면(= 사용 가능한 자원이 없다면) 프로세스는 block 된다.

하지만 위의 semaphore의 문제점 역시 spinlock으로 인한 CPU 사이클 낭비이다.

따라서 semaphore에 큐를 만들고, 이 큐를 통해 CPU가 스케줄링을 하도록 조작하는 방법이 있다.

변경된 wait와 signal

wait()
- 프로세스를 semaphore의 waiting queue에 넣는다.
- 프로세스를 waiting state로 바꾼다.
- CPU 스케줄러는 semaphore의 waiting queue에 없는, 다음에 실행할 프로세스를 선택한다.
signal()
- Semaphore의 waiting queue 안에 있는 프로세스 한 개를 ready state로 바꾼다.
- 프로세스를 ready queue로 삽입하여 CPU가 스케줄링할 수 있도록 한다.

Mutex와 Semaphore의 문제점

아래와 같은 경우 Deadlock이 발생할 수 있다.

Mutex와 Semaphore의 Deadlock 발생조건

또는, Semaphore의 ready queue가 FIFO가 아닌 LIFO로 구현되어 있다면 starvation이 발생할 수 있다.

[OpenStack에 contribute하기 - 5] Gerrit 사용하기 (1)

최성훈 — Sun, 5 Jan 2020 22:47:53 +0900

이번에는 우리가 OpenStack에 contribute하기 전에 Gerrit을 어떻게 사용해야 하는지 알아볼 것입니다.

Gerrit 흐름도

위의 그림은 Gerrit을 통한 코드 리뷰의 흐름을 나타낸 것입니다. 위의 그림을 간단하게 설명하자면 다음과 같습니다.

코드를 수정하고자 하는 프로젝트를 로컬 환경으로 clone합니다.
로컬 환경에서 수정하고자 하는 버그에 대해서 브랜치를 생성합니다.
변경사항에 대해 저장하고, 유닛 테스트를 진행한 다음, git commit을 실행합니다. (가장 첫 번째 커밋만 git commit으로 로컬 환경에 변경사항을 저장합니다.)
git review를 통해 Gerrit 리뷰시스템에 변경사항을 제출합니다.
자동 테스트 툴을 통해, 빌드 및 테스트를 진행하고, 제출한 코드를 리뷰 받습니다.
기존의 변경사항을 다시 수정해야할 경우, 코드를 변경하고 git commit --amend를 통해 다시 변경사항을 제출합니다. (반드시 --amend 옵션을 붙여야합니다.)

Bug에 대해서 작업하기

하나의 프로젝트에 대해서 버그 리포트는 Launchpad(https://bugs.launchpad.net/<프로젝트>)나 StoryBoard(https://storyboard.openstack.org)에 기록됩니다. 컨트리뷰터들은 정기적으로 완료할 작업을 찾을 때 이러한 버그 리포트들을 리뷰할 것입니다.

버그 상태에 대한 정보는 여기에 문서화 되어있습니다: https://docs.openstack.org/project-team-guide/bugs.html

작업하고싶은 버그를 발견한다면 그 버그를 자신에게 할당해도 됩니다. 리뷰를 업로드 할 때, Launchpad와 StoryBoard에 자동 업데이트를 위해서 커밋 메시지 속에 버그를 포함시키세요. Launchpad에서 사용 가능한 옵션은 다음과 같습니다.

Closes-Bug: #######
Partial-Bug: #######
Related-Bug: #######

그리고 StoryBoard에서는 다음과 같습니다.

Task: ######
Story: ######

변경사항 시작하기

작업을 저장할 브랜치를 생성하고, 그 브랜치로 전환하세요. 만약 blueprint에 대해서 작업하고 있다면, 브랜치의 이름을 bp/BLUEPRINT로 설정하세요. 여기서 BLUEPRINT는 Launchpad에서 blueprint의 이름입니다. (예: bp/authentication) 버그에 대한 일반적인 관습은 브랜치의 이름을 bug/BUG-NUMBER로 지정하는 것입니다. (예: bug/1234567)

git checkout -b TOPIC-BRANCH

변경사항 커밋하기

커밋 메시지의 타이틀은 50자 이내로 작성해야 합니다. 그 다음에 오는 문단은 변경사항에 대해 더 자세하게 설명해야 합니다.

만약 변경사항이 blueprint 또는 버그를 처리하는 경우, 다음 구문을 사용해서 커밋 메시지 안에 언급하도록 하세요.

Implements: blueprint BLUEPRINT
Closes-Bug: ####### (Partial-Bug or Related-Bug are options)

예를 들면 다음과 같습니다.

Adds keystone support

...Long multiline description of the change...

Implements: blueprint authentication
Closes-Bug: #123456
Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657

대부분의 경우 git-review가 설치한 Gerrit 커밋 훅에 의해서 Change-Id 라인이 자동으로 추가되는 점에 유의하세요. 이미 커밋을 했는데 Change-Id가 추가되지 않은 경우 Gerrit 설정 단계를 다시 수행하고 다음 명령을 실행하세요: git commit --amend. 커밋 훅은 우리가 실제로 아무 변경사항도 만들지 않았어도, 커밋 메시지 수정을 마치면 자동으로 Change-Id를 추가합니다. Change-Id는 절대로 변경하지 마세요. Gerrit이 혼동할 수 있습니다.

변경사항을 만들고, 커밋하세요. (아직 리뷰를 제출하지는 않았습니다.)

git commit -a

마스터 브랜치에서 변경사항을 만들지 마세요. 그렇게 하면 upstream으로부터 새로운 변경사항을 pull 할 때 충돌이 발생하고, merge 커밋은 Gerrit에 의해 거절됩니다.

Unit Test 실행하기

변경사항을 제출하기 전에, 우리는 꼭 테스트를 해봐야 합니다. OpenStack 프로젝트에서 파이썬 기반 유닛 테스트를 실행하는 법을 배우려면 다음 주소를 참고하세요: Running Python Unit Tests

리뷰를 위해 변경사항 제출하기

로컬 레포지토리로 변경사항을 커밋했다면, 코드 리뷰를 위해 Gerrit으로 전송하기 위해 필요한 것은 다음 명령어 한 줄이면 됩니다.

git review

위의 작업이 끝나면 제출한 변경사항에 대해 자동화 된 테스트가 실행될 것이고, 다른 개발자가 검토를 할 것입니다.

변경사항 업데이트 하기

만약 코드 리뷰 과정에서 추가적인 변경을 제안하는 경우, 기존 커밋을 변경하고 수정하세요. 커밋 메시지 아래에 있는 Change-Id 줄은 그대로 두세요. Gerrit은 이것이 기존 변경사항에 대한 업데이트된 패치셋이라는 걸 알고있습니다.

git commit -a --amend
git review

본 포스트는 다음 주소를 참고하였습니다.

[프로그래머스] 더 맵게

최성훈 — Sun, 5 Jan 2020 17:13:02 +0900

문제 보기

import heapq


def solution(scoville, K):
	answer = 0
	
	# make scoville list heap
	heapq.heapify(scoville)
	# while minimum of the heap is lower than K
	while scoville[0] < K:
		# mix 2 foods
		a = heapq.heappop(scoville)
		b = heapq.heappop(scoville)
		heapq.heappush(scoville, a + (b * 2))
		answer += 1
		
		if len(scoville) == 1 and scoville[0] < K:
			return -1
		
	return answer

[프로그래머스] 주식가격

최성훈 — Sat, 4 Jan 2020 04:02:19 +0900

문제 보기

def solution(prices):
	answer = [0 for _ in range(len(prices))]
	length = len(prices)
	
	# for all stock prices
	for i, p in enumerate(prices):
		
		# estimate duration
		duration = 0
		for j in range(i + 1, length, 1):
			# count time unconditionally
			duration += 1
			# if a stock price drops
			if prices[j] < p:
				break
		
		answer[i] = duration
		
	return answer

[프로그래머스] 쇠막대기

최성훈 — Wed, 1 Jan 2020 19:34:53 +0900

문제 보기

def solution(arrangement):
	answer = 0
	replaced = arrangement.replace('()', '.')
	stack = list()
	
	for i, c in enumerate(replaced):
		if c == '(':
			stack.append(c)
			answer += 1
		elif c == ')':
			stack.pop()
		else:
			answer += len(stack)
	
	return answer

[OpenStack에 contribute하기 - 4] Gerrit Account 구성하기

최성훈 — Sun, 29 Dec 2019 03:02:02 +0900

본 포스트는 우리가 Git 가이드를 완료한 상태라고 가정합니다.

Gerrit Account

Gerrit이란?

Gerrit은 OpenStack 커뮤니티가 사용하는 리뷰 시스템입니다.

회원가입

OpenStack의 Gerrit 페이지를 방문하고 sign in 링크를 클릭합니다.
사용자 이름을 선택하라는 메시지가 나타날 것입니다. StoryBoard나 Launchpad에서 사용했던 것과 같은 이름으로 사용합니다.

사용자 이름을 신중하게 입력하세요. 한 번 설정하면 변경할 수 없습니다.

지금부터 Gerrit에 로그인하면 StoryBoard나 Launchpad 로그인 정보를 입력하라는 메시지가 나타날 것입니다.

개인 기여자 라이선스 계약 (Individual Contributor License Agreement)

이것은 개인 또는 기업의 기여로부터 인정된 지적 재산권을 명확히 하기 위한 계약입니다.

Gerrit의 설정에서 New Contributor Agreement 주소를 클릭하고, 계약에 서명하세요. 코드와 문서를 contribute 하기 위해선 이 과정이 필요합니다. 이 과정 없이는 Gerrit에 패치를 푸시할 수 없습니다.

SSH 키 설정하기

요약하자면, 우리는 SSH 키 페어를 생성하고 Gerrit 서버에 공개 키를 제공할 것입니다. 시스템이 개인 키를 소유하고 있으면 시도-응답 인증(challenge-response authentication) 도중 Gerrit에 응답하는 데 문제가 없을 것입니다.

어떤 사람들은 여러 시스템에 접근하기 위해서 하나의 SSH 키 페어를 사용하는 반면에, 다른 사람들은 별도의 키 페어를 사용하는 것을 선호합니다. 두 가지 선택사항 모두 이 섹션에서 다룰 예정입니다.

존재하는 SSH 키 확인하기

터미널을 열고 다음을 입력합니다.

1

ls -la ~/.ssh

cs

일반적으로 공개 키 파일 이름은 다음과 같습니다.

id_dsa.pub
id_ecdsa.pub
id_ed25519.pub
id_rsa.pub

만약 .pub 파일이 없거나 OpenStack Gerrt에 대해 특정 집합을 생성하려면 키를 생성해야 합니다.

SSH 키 페어 생성하기

터미널에서 다음을 입력하여 주어진 이메일을 라벨로 사용하여 새 SSH 키 페어를 생성할 수 있습니다.

1

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

cs

"Enter a file in which to save the key" 메시지가 나타나면 엔터를 누르세요. 이것은 기본 위치를 허용합니다.

1

Enter a file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]

cs

프롬프트에서 만약 passphrase가 필요하다면 입력하고, 필요 없으면 엔터를 누르세요. (전 passphrase를 사용하지 않습니다.)

1
2

Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]

cs

OpenStack Gerrit 전용 개별 키 생성하기 (optional)

터미널에서 다음을 입력하여 주어진 이메일을 라벨로 사용하여 새 SSH 키 페어를 생성할 수 있습니다.

1

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

cs

"Enter a file in which to save the key" 메시지가 나타나면 반드시 새로운 키 페어의 이름을 지정하고 엔터를 누르세요.

1

Enter a file in which to save the key (/Users/you/.ssh/id_rsa): /Users/you/.ssh/id_openstack_rsa

cs

프롬프트에서 만약 passphrase가 필요하다면 입력하고, 필요 없으면 엔터를 누르세요. (전 passphrase를 사용하지 않습니다.)

1
2

Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]

cs

마지막으로 SSH키를 연결할 호스트가 무엇인지 구분해야 합니다. 편집기에서 "~/.ssh/config/"을 열고, 만약 파일이 없다면 파일을 생성하고 다음과 같은 내용을 추가하세요.

1
2
3
4
5

Host review.opendev.org review
  Hostname review.opendev.org
  Port 29418
  User <your_gerrit_username>
  IdentityFile ~/.ssh/id_openstack_rsa

cs

공개키 복사하기

터미널에서 다음을 입력하세요.

1

cat ~/.ssh/id_rsa.pub

cs

만약 개별 키 페어를 생성했고, 위의 예제와 같은 예제 파일 이름을 사용했다면 다음을 입력하세요.

1

cat ~/.ssh/id_openstack_rsa.pub

cs

결과를 클립보드에 복사하세요.

Gerrit으로 공개키 Import 하기

Gerrit의 SSH 공개키 설정 페이지로 이동하세요.
Add Key 버튼을 클릭하세요.
Add SSH Public Key 텍스트 박스 안에 공개키를 붙여 넣기 하고 Add 버튼을 클릭하세요.

Git Review

Git Review란?

Git review는 OpenStack 커뮤니티에 의해 유지되는 툴입니다. 다음과 같은 하위 명령을 'git'에 추가합니다.

1

git review

cs

OpenStack 프로젝트 레포지토리에 우리가 변경한 내용이 있는 경우, 이 하위 명령을 사용해서 변경 내용을 Gerrit에 게시하여 리뷰어들이 검토할 수 있게 할 수 있습니다.

설치

Debian, Ubuntu 또는 Mint와 같은 리눅스 배포를 사용하는 경우 터미널에 다음을 입력합니다.

1

sudo apt install git-review

cs

RedHat, Fedora 21 또는 이전 버전, 또는 CentOS를 사용하는 경우 터미널에 다음을 입력합니다.

1

sudo yum install git-review

cs

Fedora 22 이상 버전을 사용하는 경우 터미널에 다음을 입력합니다.

1

sudo dnf install git-review

cs

구성

Git review는 사용자 이름과 Gerrit 사용자 이름이 동일하다고 가정합니다. 그렇지 않은 경우 다음 명령을 통해 설정할 수 있습니다.

1

git config --global gitreview.username <username>

cs

만약 Gerrit username이 뭔지 모르겠다면, Gerrit settings를 확인하면 됩니다.

리뷰를 보낼 준비

우리의 패치에서 Git 커밋을 실행하기 전에 Git 리뷰를 초기화하는 것이 중요합니다. 다음 명령을 통해서 우리의 레포지토리 내의 초기 Git 리뷰 환경을 구성하세요.

1

git review -s

cs

위 명령어는 필요한 원격 호스트를 설정하고 Gerrit에 변경 사항을 푸시할 수 있도록 Git hook을 커밋합니다.

Git review는 하나의 레포지토리 안에서 한 번만 초기화되면 됩니다.

본 포스트는 다음 주소를 참고하였습니다.

https://docs.openstack.org/contributors/common/setup-gerrit.html

[OpenStack에 contribute하기 - 3] Git (2)

최성훈 — Sun, 29 Dec 2019 00:29:17 +0900

본 포스트에서는 OpenStack에 contribute 할 커밋들을 작성하는 좋은 예시와 나쁜 예시를 알아볼 것입니다.

공식 문서를 번역하는 것만으로도 도움이 되는 것을 느낍니다.

Git Commit의 좋은 관행

개요

이 글에서 제기될 핵심과 예제들은 변경 사항을 개별적인 커밋들로 분할하는 것에 대한 가치와, 좋은 커밋 메시지들을 작성하는 중요성에 대해서 증명할 것입니다. 만약 이 가이드라인들이 광범위하게 적용된다면 OpenStack Git 기록들의 질을 향상하는 데에 엄청난 기여를 할 것입니다. 이 글은 사람들에게 여러 혜택들을 인식하게 하는 당근과 같은 반면에, Gerrit code를 리뷰하는 누구나 채찍이 될 수 있습니다.

바꿔 말하면, Gerrit에서 변경사항들을 리뷰할 때, 코드의 정확성에 대해서만 간단하게 들여다보지 말라는 뜻입니다.

즉,

커밋 메시지 자체를 리뷰하고, 커밋 메시지의 자체로 개선을 요구하세요.
여러 논리적인 변화가 섞이는 커밋들을 조심하고, 커미터(commiter)에게 논리적으로 섞여있는 커밋들을 개별 커밋들로 분할하라고 요청하세요.
기능적 변경사항과 함께 공백 문자의 변경사항이 섞이지 않도록 하세요.
여러 기능적 변경사항들로부터 개별적으로 no-op 코드 리팩터링을 하지 마세요. (코드 리팩터링은 한 번에 하라는 뜻인 것 같습니다.)
기타 등등...

소프트웨어 소스코드는 "많이 읽히고, 드물게 작성"됩니다. 따라서 가장 중요한 기준은 커뮤니티 내의 커다란 개발자 그룹에 의해서 장기적인 유지보수성(maintainability)을 향상시키는 것이지, 코드를 두 번 다시 안 볼 수도 있는 한 명의 개발자를 위해서 희생을 하는 것이 아닙니다.

변경사항의 구조적 분할

좋은 커밋을 만들기 위한 기본적인 규칙은 커밋당 하나의 "논리적 변화"만 확실하게 하는 것입니다. 이것이 중요한 규칙인 이유는 다음과 같습니다.

변경되는 코드의 양이 적을수록 잠재적인 결함을 검토하고 식별하는 게 더 빠르고 쉽습니다.
만약 변경사항이 나중에 결함으로 발견되면, 잘못된 커밋을 되돌리는 것이 필요할 수도 있습니다. 이것은 원래의 커밋과 얽혀있는, 다른 관련 없는 커밋들이 없다면 훨씬 더 쉽게 할 수 있습니다.
Git의 이등분적인 성질을 사용해서 문제를 해결할 때, 잘 정의된 작은 변화는 문제가 되는 코드를 도입한 위치를 분리하는데 도움이 될 것입니다.

커밋을 작성할 때 피해야 하는 것들

공백 문자의 변경사항과 코드 변경사항의 혼합
공백 문자의 변경은 기능적 변경사항을 모호하게 해서 리뷰어가 해당 변경이 올바른지 정확하게 판단하기 어렵게 합니다. 해결법: 공백 문자의 변경사항, 기능적 변경사항으로 2개의 커밋을 생성합니다. 일반적으로는 공백 문자의 변경이 먼저 이루어지지만 엄격한 규칙은 아닙니다.
두 개의 관련 없는 기능적 변경사항들의 혼합
다시, 만약 관련 없는 두 변경사항들이 혼합되면 리뷰어들이 문제를 식별하기 어려울 것입니다. 그리고 만약 나중에서야 잘못된 커밋을 되돌려야 한다면, 관련 없는 변경 사항들은 분리되어야 할 것이고, 이는 또 다른 버그의 위험이 있습니다.
한 개의 커밋 속 커다란 새로운 기능
이는 하나의 기능 전체가 하나의 커밋으로 제공되면 안 된다는 것을 의미합니다. 새로운 기능은 종종 기존의 코드를 리팩터링 해야 합니다. 모든 리팩터링은 새로운 기능을 구현하는 작업과는 별개의 작업으로 수행하는 것이 매우 바람직합니다. 이는 리뷰어와 테스트 셋들이 리팩터링에 의해 의도하지 않은 변화가 없다는 것을 검증하는데 도움이 됩니다.

잘못된 구조적 분할에 대한 예

Nova 기록에 대한 예시를 들어봅시다. 집중해주세요, 커밋 해쉬가 참조용으로 인용됐지만, 작성자 이름은 지웠습니다. 왜냐하면 어떤 사람도 비난받을 필요가 없기 때문입니다. 거의 모든 사람들이 언젠가 이런 좋은 관행들을 어긴 것에 대한 잘못이 있습니다. 게다가 이런 커밋을 리뷰하고 승인한 사람들도 이러한 커밋을 작성하고 제출한 사람만큼의 잘못이 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

  commit ae878fc8b9761d099a4145617e4a48cbeb390623
  Author: [removed]
  Date:   Fri Jun 1 01:44:02 2012 +0000
 
    Refactor libvirt create calls
 
     * minimizes duplicated code for create
     * makes wait_for_destroy happen on shutdown instead of undefine
     * allows for destruction of an instance while leaving the domain
     * uses reset for hard reboot instead of create/destroy
     * makes resume_host_state use new methods instead of hard_reboot
     * makes rescue/unrescue not use hard reboot to recreate domain
 
    Change-Id: I2072f93ad6c889d534b04009671147af653048e7

cs

최소 2개의 개별적인 변경사항이 이 커밋 안에 있습니다.

"hard_reboot" 메소드 대신 새로운 "reset" API의 사용 전환
내부 드라이버들이 "hard_reboot"를 사용하지 않도록 조정

이것과 관련한 문제는 다음과 같습니다.

첫 번째로, 이러한 변화가 동시에 이루어져야 하는 설득력 있는 이유가 없습니다. 첫 번째 커밋은 여러 곳에서 "hard_reboot"를 호출하는 것을 멈추는 변경사항을 포함할 수 있었습니다. 두 번째 커밋은 "hard_reboot" 구현을 다시 작성할 수 있었습니다.
두 번째로, libvert의 'reset' 메소드를 사용하는 변경이 대규모 코드 리팩터링에 묻히면서 리뷰어들이 더 새로운 libvirt API 버전에 의존성이 있다는 사실을 놓쳤습니다. 이 커밋이 문제가 되는 원인이라는 것이 빠르게 확인되었지만, 관련 없는 다양한 변경사항이 포함되어 있기 때문에 사소한 복구는 불가능합니다.

좋은 구조적 분할에 대한 예

1
2
3
4
5
6
7
8
9
10
11

  commit 3114a97ba188895daff4a3d337b2c73855d4632d
  Author: [removed]
  Date:   Mon Jun 11 17:16:10 2012 +0100
 
    Update default policies for KVM guest PIT & RTC timers
 
  commit 573ada525b8a7384398a8d7d5f094f343555df56
  Author: [removed]
  Date:   Tue May 1 17:09:32 2012 +0100
 
    Add support for configuring libvirt VM clock and timers

cs

이 두 가지 변경 사항을 함께 적용하면 KVM 게스트 타이머를 구성할 수 있습니다. libvirt XML 구성을 생성하기 위한 새로운 API의 도입은 그 API를 사용하는 KVM 게스트 생성 정책의 변경 사항과 명확하게 분리되어 있습니다.

커밋 메시지 속 정보

변경 사항의 내용만큼이나 중요한 것은 그것을 설명하는 커밋 메시지의 내용입니다. 커밋 메시지를 쓸 때 기억해야 할 몇 가지 중요한 사항이 있습니다.

리뷰어가 원래 문제가 무엇인지 이해한다고 가정하지 마세요.
리뷰어가 외부 웹 서비스/사이트에 액세스 할 수 있다고 가정하지 마세요.
코드가 그 자체로써 증명/문서화한다고 가정하지 마세요.
이 변경사항이 왜 생기는지 설명하세요.
개선된 코드에 힌트가 있는지 커밋 메시지를 읽으세요.
리뷰를 결정하기에 충분한 정보가 있는지 확인하세요.
첫 번째 커밋 줄이 가장 중요합니다.
현재 코드의 제약 사항에 대해서 설명하세요.

따라야 할 핵심 규칙은 다음과 같습니다.

커밋 메시지는 패치의 정확성을 완전히 이해하고 검토하는 데 필요한 모든 정보를 포함해야 합니다. 적을수록 더 좋은 게 아닙니다. 많을수록 더 좋습니다.

잘못된 관행에 대한 예

예시 1)

1
2
3
4
5
6
7

    commit 468e64d019f51d364afb30b0eed2ad09483e0b98
    Author: [removed]
    Date:   Mon Jun 18 16:07:37 2012 -0400
 
      Fix missing import in compute/utils.py
 
      Fixes bug 1014829

cs

문제점: 이 커밋은 무엇을 import 하고, 어디가 누락이 되었으며, 왜 utils.py가 필요한 지 언급하지 않습니다. 이 정보는 실제로 버그 트래커에 있었고, 커밋 메시지 속에 복사해서 스스로 설명을 제공해야 했습니다. 예를 들면 다음과 같습니다.

1
2
3
4

      Add missing import of 'exception' in compute/utils.py
 
      nova/compute/utils.py makes a reference to exception.NotFound,
      however exception has not been imported.

cs

예시 2)

1
2
3
4
5
6
7
8
9
10

   commit 2020fba6731634319a0d541168fbf45138825357
   Author: [removed]
   Date:   Fri Jun 15 11:12:45 2012 -0600
 
    Present correct ec2id format for volumes and snaps
 
    Fixes bug 1013765
    * Add template argument to ec2utils.id_to_ec2_id() calls
 
    Change-Id: I5e574f8e60d091ef8862ad814e2c8ab993daa366

cs

문제점: 이 커밋은 현재 잘못된 포맷이 무엇인지, 새로운 포맷은 무엇인지에 대해 언급하지 않습니다. 다시 이 정보는 버그 트래커에 있었고, 커밋 메시지에 포함되어야 했습니다. 게다가 이 버그는 이전의 커밋의 변경으로 인한 회귀 현상을 고치고 있었지만, 이전의 변화가 무엇이었는지에 대한 언급이 없습니다. 예를 들면 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10

    Present correct ec2id format for volumes and snaps
 
    During the volume uuid migration, done by changeset XXXXXXX,
    ec2 id formats for volumes and snapshots was dropped and is
    now using the default instance format (i-xxxxx). These need
    to be changed back to vol-xxx and snap-xxxx.
 
    Adds a template argument to ec2utils.id_to_ec2_id() calls
 
    Fixes bug 1013765
Colored by Color Scripter

cs

예시 3)

1
2
3
4
5
6
7
8
9

  commit f28731c1941e57b776b519783b0337e52e1484ab
  Author: [removed]
  Date:   Wed Jun 13 10:11:04 2012 -0400
 
    Add libvirt min version check.
 
    Fixes LP Bug #1012689.
 
    Change-Id: I91c0b7c41804b2b25026cbe672b9210c305dc29b

cs

문제점: 이 커밋 메시지는 단순히 무엇이 행해졌는지 기록하고, 왜 행해졌는지는 기록하지 않습니다. 커밋 메시지는 이전의 어떤 변경 사항들이 새로운 최소 libvirt 버전을 도입했는지 언급해야 했습니다. 또, 검사에 실패했을 때 어떤 작동을 하는지 언급했어야 했습니다. 예를 들면 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10

    Add libvirt version check, min 0.9.7
 
    The commit XXXXXXXX introduced use of the 'reset' API
    which is only available in libvirt 0.9.7 or newer. Add a check
    performed at startup of the compute server against the libvirt
    connection version. If the version check fails the compute
    service will shutdown.
 
    Fixes LP Bug #1012689.
    Change-Id: I91c0b7c41804b2b25026cbe672b9210c305dc29b

cs

좋은 관행에 대한 예

예제 1)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

  commit 3114a97ba188895daff4a3d337b2c73855d4632d
  Author: [removed]
  Date:   Mon Jun 11 17:16:10 2012 +0100
 
    Update default policies for KVM guest PIT & RTC timers
 
    The default policies for the KVM guest PIT and RTC timers
    are not very good at maintaining reliable time in guest
    operating systems. In particular Windows 7 guests will
    often crash with the default KVM timer policies, and old
    Linux guests will have very bad time drift
 
    Set the PIT such that missed ticks are injected at the
    normal rate, ie they are delayed
 
    Set the RTC such that missed ticks are injected at a
    higher rate to "catch up"
 
    This corresponds to the following libvirt XML
 
      <clock offset='utc'>
        <timer name='pit' tickpolicy='delay'/>
        <timer name='rtc' tickpolicy='catchup'/>
      </clock>
 
    And the following KVM options
 
      -no-kvm-pit-reinjection
      -rtc base=utc,driftfix=slew
 
    This should provide a default configuration that works
    acceptably for most OS types. In the future this will
    likely need to be made configurable per-guest OS type.
 
    Closes-Bug: #1011848
 
    Change-Id: Iafb0e2192b5f3c05b6395ffdfa14f86a98ce3d1f

cs

이 예제 커밋에 대해 눈여겨봐야 할 점들은 다음과 같습니다.

원래 문제가 무엇인지 설명합니다. (잘못된 KVM 기본값)
적용하고자 하는 기능적 변경사항을 설명합니다. (새로운 PIT/RTC 정책)
변경사항의 결과에 대해서 설명합니다. (새로운 XML/QEMU 매개변수)
향후 개선의 범위를 설명합니다. (OS 유형별 구성 가능성)
Closes-Bug 표기를 사용합니다.

예제 2)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

  commit 31336b35b4604f70150d0073d77dbf63b9bf7598
  Author: [removed]
  Date:   Wed Jun 6 22:45:25 2012 -0400
 
    Add CPU arch filter scheduler support
 
    In a mixed environment of running different CPU architecutres,
    one would not want to run an ARM instance on a X86_64 host and
    vice versa.
 
    This scheduler filter option will prevent instances running
    on a host that it is not intended for.
 
    The libvirt driver queries the guest capabilities of the
    host and stores the guest arches in the permitted_instances_types
    list in the cpu_info dict of the host.
 
    The Xen equivalent will be done later in another commit.
 
    The arch filter will compare the instance arch against
    the permitted_instances_types of a host
    and filter out invalid hosts.
 
    Also adds ARM as a valid arch to the filter.
 
    The ArchFilter is not turned on by default.
 
    Change-Id: I17bd103f00c25d6006a421252c9c8dcfd2d2c49b

cs

이 예제 커밋에 대해 눈여겨봐야 할 점들은 다음과 같습니다.

문제 시나리오가 무엇인지 설명합니다. (혼합된 구조 배치)
버그 해결에 대한 의도를 설명합니다. (구조에 대한 스케줄러 필터 만들기)
버그 해결에 대한 간략한 구조를 설명합니다. (libvirt가 어떻게 구조를 반환하는지)
버그 해결의 한계에 대해서 기록합니다. (Xen에 필요한 작업)

본 포스트는 다음 주소를 참고하였습니다.

[OpenStack에 contribute하기 - 3] Git (1)

최성훈 — Sat, 28 Dec 2019 19:12:11 +0900

Git 관련 포스트인데 내용이 길다 보니 아마 2편 이상으로 나눠서 작성할 것 같습니다.

대부분의 OpenStack 개발 도구(예: git-review)들은 Windows 환경에서 잘 돌아가지 않으니, 리눅스 환경을 기준으로 포스팅합니다.

본 포스트는 Git 설치법과 OpenStack에 contribute 할 때의 커밋 메시지에 대해서 소개합니다.

이것저것 알아보면서 느낀 것이지만, 아무리 공식 문서라도 프로젝트나 버전마다 권장하는 내용이 조금씩 다르니 참고 바랍니다.

본 포스트는 우리가 Account Setup 가이드를 완료한 상태라고 가정합니다.

Git

Git이란?

Git은 OpenStack 커뮤니티가 소스 코드와 문서의 변경사항을 관리하기 위해 사용하는 무료 오픈 소스 분산 버전 컨트롤 시스템이다.

설치

Debian, Ubuntu 또는 Mint 같은 리눅스 배포판들은 터미널을 열고 다음을 입력합니다.

1

sudo apt install git

cs

Git 설정하기

깃을 설치했다면 우리는 환경을 설정할 필요가 있습니다. 터미널을 열고 다음 명령을 통해 이름, 성 그리고 이메일 주소를 입력하세요. 이것을 통해 우리의 contribution이 식별됩니다.

1
2

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

cs

Account Setup 단계에서 사용한 것과 동일한 이메일을 사용하세요.

Commit Message

커밋 메시지들은 리뷰어(reviewer)들이 가장 첫 번째로 보는 것들이고 git log 안에서 설명으로 사용됩니다. 커밋 메시지들은 레포지토리 안에서 변경 사항들의 기록에 대한 설명을 제공합니다. 커밋 메시지들은 패치(patch)가 한 번 적용이 되면 변경할 수 없습니다.

형식:

요약 (Summary Line)
빈 줄
내용 (Body)
빈 줄
태그 (Tags)

요약 (Summary Line)

요약은 패치 내용을 간략하게 설명합니다. 문자 제한은 50자입니다. 요약은 마침표로 끝나지 말아야 합니다. 만약 변화가 한 번의 커밋으로 끝나지 않는다면 커밋 메시지를 WIP(Work in Progress)로 시작하세요.

내용 (Body)

내용은 해결하고자 하는 이슈에 대한 설명, 고쳐야 하는 이유, 설루션에 대한 설명, 코드 구조를 어떻게 개선하는지에 대한 추가적인 설명, 또는 다른 연관 있는 패치에 대한 참조 등을 포함합니다. 각 줄은 72자로 제한됩니다. 내용은 독자가 문제의 원인을 이해한다거나, 외부 사이트에 접속이 가능하다는 가정 없이, 문제와 관련하여 모든 중요한 정보를 포함하고 있어야 합니다.

태그 (Tags)

태그는 다른 도구들로 변경 사항들을 연결하는 데 사용되는 참조입니다.

다음의 태그들은 필수적으로 요구됩니다:

Change-Id 줄은 변경사항을 설명하는 고유의 해쉬입니다. Change-Id는 Git commit hook에 의해서 자동적으로 생성됩니다. 이 줄은 리뷰 피드백에 따라오는 커밋을 rebase 할 때 변경되면 안 됩니다. 왜냐하면 이 줄은 패치 버전을 추적하기 위해 Gerrit에 의해 사용되기 때문입니다.

StoryBoard 명시 태그:

Task: 변경사항에 의해 생성되는 StoryBoard 내의 작업 번호. 이 태그는 자동으로 그 작업을 'Review' 상태로 업데이트하고, 패치를 적용할 때 우리에게 배정됩니다.
Story: 패치가 적용되고자 하는 StoryBoard 내의 스토리 번호. 이 태그는 우리의 패치를 참조하는 링크와 함께 스토리에 코멘트를 달 것입니다.

Launchpad 명시 태그:

Closes-Bug: 만약 커밋이 참조하는 버그를 완전하게 해결하고 이슈를 닫고자 한다면 Closes-Bug 태그를 사용하세요. 태그 숫자로 해당 버그의 Launchpad의 ID를 사용하세요; Gerrit이 자동으로 그 버그로 링크를 생성할 것입니다.
Partial-Bug: 만약 커밋이 버그의 부분적인 해결과 추가적인 작업이 필요하다면 Partial-Bug 태그를 사용하세요. 태그 숫자로 해당 버그의 Launchpad의 ID를 사용하세요; Gerrit이 자동으로 그 버그로 링크를 생성할 것입니다.
Related-Bug: 만약 커밋이 단순히 참조된 버그와 연관이 있다면 Related-Bug 태그를 사용하세요. 태그 숫자로 해당 버그의 Launchpad의 ID를 사용하세요; Gerrit이 자동으로 그 버그로 링크를 생성할 것입니다.
Partial-Implements: 만약 커밋이 Launchpad blueprint를 부분적으로 구현한다면 Partial-Implements 태그를 사용하세요. 태그 ID로써 blueprint의 이름을 사용하세요.
Implements: 만약 커밋이 Launchpad blueprint를 완전히 구현한다면 Implements 태그를 사용하세요. 태그 ID로써 blueprint의 이름을 사용하세요.

만약 해당 프로젝트가 StoryBoard를 사용한다면 StoryBoard의 태그를 사용하고, Launchpad를 사용한다면 Launchpad의 태그를 사용하면 됩니다.

다음의 태그들은 선택사항이지만, 패치에 적용될 수 있으면 사용하는 것이 권장됩니다.

이는 포스팅하지 않으니, 아래의 주소를 참고하기 바랍니다.

DocImpact
APIImpact
SecurityImpact
UpgradeImpact
Depends-On

본 포스트는 다음 주소를 참고하였습니다.

[OpenStack에 contribute하기 - 2] Account Setup

최성훈 — Sat, 28 Dec 2019 04:31:36 +0900

OpenStack 커뮤니티에서 채팅 서비스로 IRC를 사용한다지만 저는 사용할 일이 없을 것 같아서 포스팅하지 않습니다.

OpenStack Foundation Account 구성하기

OpenStack Foundation Account는 우리가

선거에서 투표할 수 있게 합니다.
OpenStack 프로젝트에서 특정 포지션에 지원할 수 있게 합니다.
OpenStack 컨퍼런스에서 발표할 수 있게 합니다.
OpenStack 컨퍼런스에서 투표할 수 있게 합니다.

(딱히 쓸 일이 없어보이는 장점들...)

회원가입

만약 코드 기여를 하고싶다면 반드시 같은 이메일을 사용하도록 하세요. 왜냐하면 나중에 각 계정들의 이메일 주소가 일치하는 것이 중요합니다.

OpenStack Foundation 회원가입 페이지로 이동하세요.
Individual Member:Free 섹션의 Community Member를 클릭하세요.
이름과 이메일 주소, 성별을 작성합니다. 회원가입의 각 단계마다 같은 이메일 주소를 사용하세요. 이 이메일 주소는 로그인 할 때 사용됩니다. 그리고 성별은 공공 API에 의해서 사용 가능합니다.
나머지 양식을 채우고 제출하세요.

OpenStack 공식 문서에 있는 그림. Foundation Member말고 왼쪽의 Community Member를 선택한다. Foundation Member는 주기적으로 투표하는게 의무이며, 이를 수행하지 않을 시 계정이 정지된다고 한다.

Task Tracker Account 구성하기

OpenStack 커뮤니티는 현재 버그 추적 소프트웨어로 Launchpad에서 StoryBoard로 변경하는 과정 중에 있습니다. 프로젝트가 명시된 on-boarding 문서에서 그 프로젝트가 Launchpad를 쓰는지 StoryBoard를 쓰는지 특별히 주의하세요. 만약 당신의 프로젝트가 Launchpad를 사용하고 있다면, 이 포스트(문서)의 Launchpad 섹션을 주목하세요.

Task Tracker Account는 우리가

버그를 제보할 수 있게 합니다.
새로운 기능을 위한 스토리를 생성할 수 있게 합니다. (프로세스는 프로젝트마다 다릅니다.)
버그/새로운 기능의 진행결과를 추적할 수 있게 합니다.

StoryBoard

StoryBoard란?

StoryBoard는 OpenStack 커뮤니티가 개발하고 있는 버그 추적 소프트웨어이고, 현재 마이그레이션 작업 중입니다. 몇몇 프로젝트는 이미 StoryBoard를 사용하고 있습니다.

회원가입

storyboard.openstack.org로 이동하세요.
오른쪽 위에 login 버튼을 클릭하세요.
이미 Ubuntu One 계정을 소유하고 있다면, 그냥 로그인하면 됩니다.
만약 Ubuntu One 계정이 없다면, I am a new Ubuntu One user를 클릭하세요.
양식을 채우고 제출하세요.

Launchpad

Launchpad란?

Launchpad는 OpenStack 커뮤니티가 버그 추적을 하는 구식(오래된) 방법입니다.

회원가입

이미 회원가입을 했습니다. Launchpad는 StoryBoard처럼 인증을 위해 Ubuntu One 계정을 사용합니다.

본 포스트는 다음 주소를 참고하였습니다.

https://docs.openstack.org/contributors/common/accounts.html

[OpenStack에 contribute하기 - 1] 개요

최성훈 — Sat, 28 Dec 2019 01:38:59 +0900

개인적으로 OpenStack의 프로젝트에 기여하는 Developer가 돼보고 싶어서 시작하는 프로젝트입니다.

공식 문서를 참고해 차근차근 진행해 볼 계획이니, 프로젝트의 진행 속도는 많이 느릴 것 같습니다. (핑계 +1)

공식 문서가 OpenStack의 버전 별로 매번 업데이트 되기 때문에, 이것 저것 찾아보고, 번역하면서 포스팅하겠습니다.

OpenStack이란?

Software

OpenStack은 기업과 통신회사를 포함한 다양한 사용 사례들을 다루는 사설 및 공인 클라우드 플랫폼을 제공하는 소프트웨어 패키지입니다. 주요 초점은 IaaS(Infrastructure as a Service)와 IaaS위에서 빌드된 추가적인 서비스들입니다.

소프트웨어로써, OpenStack은 실제 다른 구조로 결합될 수 있는 마이크로서비스들의 집합으로부터 만들어졌습니다. 그 마이크로서비스들은 사용자들을 위해 REST API를 제공합니다. 그 사용자들은 클라우드 운영자(Operator)가 될 수도 있고 다른 서비스가 될 수도 있습니다. API를 더 쉽게 사용하기 위해 SDK를 사용하는 것도 가능합니다. 이 SDK들 또한 OpenStack 커뮤니티 내에서 프로젝트로 개발되고 있습니다.

커뮤니티에 의해서 개발된 서비스들은 소스코드로부터 설치할 tar파일로 이용 가능하고, 또한 다른 리눅스 배포에서 사용 가능하게 하거나 OpenStack 배포의 일부로 개선되고 패키징됩니다.

OpenStack 프로젝트의 구조

Contribution이란?

오픈 소스 프로젝트에서 contribution이란, 그 프로젝트가 목적을 달성하도록 돕는 어떤 것이든 될 수 있습니다. 코드 기여뿐만 아니라 테스팅, 문서화, 요구사항 수집, 버그 리포팅 등이 있습니다.

본 포스트는 다음 주소를 참고하였습니다.

https://docs.openstack.org/contributors/common/introduction.html

# 1

최성훈 — Fri, 27 Dec 2019 18:50:28 +0900

각자의 방향으로

[프로그래머스] 다리를 지나는 트럭

최성훈 — Fri, 27 Dec 2019 18:24:58 +0900

문제 보기

[백준 17779] 게리맨더링 2

최성훈 — Thu, 26 Dec 2019 21:14:25 +0900

문제 보기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

import sys
 
n = int(sys.stdin.readline())
A = [[0 for _ in range(n + 1)] for _ in range(n + 1)]
for r in range(1, n + 1, 1):
    line = list(map(int, sys.stdin.readline().split()))
    for c in range(1, n + 1, 1):
        A[r][c] = line[c - 1]
 
 
def solution(x, y, d1, d2):
    max_sum, min_sum = 0, sys.maxsize
    temp_board = [[0 for _ in range(n + 1)] for _ in range(n + 1)]
    
    # border 1
    for d in range(0, d1 + 1, 1):
        temp_board[x + d][y - d] = 5
    
    # border 2
    for d in range(0, d2 + 1, 1):
        temp_board[x + d][y + d] = 5
    
    # border 3
    for d in range(0, d2 + 1, 1):
        temp_board[x + d1 + d][y - d1 + d] = 5
    
    # border 4
    for d in range(0, d1 + 1, 1):
        temp_board[x + d2 + d][y + d2 - d] = 5
    
    # sum of sector 1
    sum1 = 0
    for i in range(1, x + d1):
        for j in range(1, y + 1, 1):
            if temp_board[i][j] == 5:
                break
            sum1 += A[i][j]
    max_sum = max(max_sum, sum1)
    min_sum = min(min_sum, sum1)
        
    # sum of sector 2
    sum2 = 0
    for i in range(x + d2, 0, -1):
        for j in range(n, y, -1):
            if temp_board[i][j] == 5:
                break
            sum2 += A[i][j]
    max_sum = max(max_sum, sum2)
    min_sum = min(min_sum, sum2)
        
    # sum of sector 3
    sum3 = 0
    for i in range(x + d1, n + 1, 1):
        for j in range(1, y - d1 + d2, 1):
            if temp_board[i][j] == 5:
                break
            sum3 += A[i][j]
    max_sum = max(max_sum, sum3)
    min_sum = min(min_sum, sum3)
        
    # sum of sector 4
    sum4 = 0
    for i in range(n, x + d2, -1):
        for j in range(n, y - d1 + d2 - 1, -1):
            if temp_board[i][j] == 5:
                break
            sum4 += A[i][j]
    max_sum = max(max_sum, sum4)
    min_sum = min(min_sum, sum4)
    
    # sum of sector 5
    sum5 = total - (sum1 + sum2 + sum3 + sum4)
    max_sum = max(max_sum, sum5)
    min_sum = min(min_sum, sum5)
    
    return max_sum - min_sum
 
 
total = sum(map(sum, A))
answer = total
for r in range(1, n + 1, 1):
    for c in range(1, n + 1, 1):
        for d1 in range(1, n + 1, 1):
            for d2 in range(1, n + 1, 1):
                if 1 < r + d1 + d2 <= n and 1 <= c - d1 < c + d2 <= n:
                    answer = min(answer, solution(r, c, d1, d2))
print(answer)
 
Colored by Color Scripter

cs

[백준 17142] 연구소 3

최성훈 — Sun, 22 Dec 2019 23:47:28 +0900

문제 보기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

import sys
from collections import deque
from itertools import combinations
 
n, m = map(int, sys.stdin.readline().split())
board = [list(map(int, sys.stdin.readline().split())) for _ in range(n)]
directions = ((-1, 0), (0, 1), (1, 0), (0, -1))
 
# get list of viruses
virus_list = deque()
empty_rooms = 0
for i in range(n):
    for j in range(n):
        if board[i][j] == 0:
            empty_rooms += 1
        elif board[i][j] == 2:
            virus_list.appendleft((i, j))
 
answer = sys.maxsize - 1
# for all combinations of viruses
for selected in combinations(virus_list, m):
    q = deque()
    visited = set()
    for virus in selected:
        q.appendleft((virus, 0))
        visited.add(virus)
    
    # bfs
    infected, max_dist = 0, 0
    while q:
        cur, dist = q.pop()
        for dr, dc in directions:
            next_r = cur[0] + dr
            next_c = cur[1] + dc
            if -1 < next_r < n and -1 < next_c < n:
                if (next_r, next_c) not in visited:
                    if board[next_r][next_c] != 1:
                        # update distance and infection count only if virus is spread in empty room
                        if board[next_r][next_c] == 0:
                            infected += 1
                            max_dist = max(max_dist, dist + 1)
                        q.appendleft(((next_r, next_c), dist + 1))
                        visited.add((next_r, next_c))
    # update answer if we succeeded in spreading virus
    if infected == empty_rooms:
        answer = min(answer, max_dist)
        
# if answer is not found
if answer == sys.maxsize - 1:
    print(-1)
# if answer is found
else:
    print(answer)
 
Colored by Color Scripter

cs

[백준 17140] 이차원 배열과 연산

최성훈 — Sat, 21 Dec 2019 22:23:46 +0900

문제 보기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

import sys
from collections import Counter
 
r, c, k = map(int, sys.stdin.readline().strip().split())
A = [[0 for _ in range(101)] for _ in range(101)]
for i in range(3):
    line = list(map(int, sys.stdin.readline().strip().split()))
    for j in range(3):
        A[i][j] = line[j]
 
answer, max_r, max_c = 0, 3, 3
while A[r - 1][c - 1] != k and answer < 101:
    # operation R
    if max_r >= max_c:
        # for all rows
        for i in range(max_r):
            sorted_row = list(sorted(Counter(A[i]).items(), key=lambda x: (x[1], x[0])))
            
            j = 0
            for key, occurrence in sorted_row:
                if key != 0:
                    A[i][j] = key
                    A[i][j + 1] = occurrence
                    j += 2
            max_c = max(max_c, j)
            # set rest of blanks to 0
            for j in range(j, 101, 1):
                A[i][j] = 0
    # operation C
    else:
        # transposed matrix of A
        transposed_A = list(zip(*A))
        for j in range(max_c):
            sorted_col = list(sorted(Counter(transposed_A[j]).items(), key=lambda x: (x[1], x[0])))
            
            i = 0
            for key, occurrence in sorted_col:
                if key != 0:
                    A[i][j] = key
                    A[i + 1][j] = occurrence
                    i += 2
            max_r = max(max_r, i)
            # set rest of blanks to 0
            for i in range(i, 101, 1):
                A[i][j] = 0
    answer += 1
 
if answer < 101:
    print(answer)
else:
    print(-1)
 
Colored by Color Scripter

cs

[백준 17143] 낚시왕

최성훈 — Thu, 19 Dec 2019 16:31:51 +0900

문제 보기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

import sys
 
 
def move(r, c, s, d, z):
    temp_speed = s
    # minimize the steps of shark's movement
    if d == 1 or d == 2:
        temp_speed %= (2 * R) - 2
    elif d == 3 or d == 4:
        temp_speed %= (2 * C) - 2
    
    new_r, new_c, new_d = r, c, d
    for _ in range(temp_speed):
        if new_d == 1 and new_r == 1:
            new_d = 2
        elif new_d == 2 and new_r == R:
            new_d = 1
        elif new_d == 3 and new_c == C:
            new_d = 4
        elif new_d == 4 and new_c == 1:
            new_d = 3
        
        new_r += directions[new_d][0]
        new_c += directions[new_d][1]
    
    return new_r, new_c, s, new_d, z
 
 
R, C, M = map(int, sys.stdin.readline().split())
board = [[0 for _ in range(C + 1)] for _ in range(R + 1)]
for _ in range(M):
    r, c, s, d, z = map(int, sys.stdin.readline().split())
    board[r][c] = [s, d, z]
directions = {1: (-1, 0), 2: (1, 0), 3: (0, 1), 4: (0, -1)}
 
 
answer = 0
# 1. move fisher
for fisher_pos in range(1, C + 1, 1):
    # 2. get the nearest shark from the ground
    for r in range(1, R + 1, 1):
        if board[r][fisher_pos]:
            answer += board[r][fisher_pos][2]
            board[r][fisher_pos] = 0
            break
 
    # 3. move sharks
    temp_board = [[0 for _ in range(C + 1)] for _ in range(R + 1)]
    for r in range(1, R + 1, 1):
        for c in range(1, C + 1, 1):
            if board[r][c]:
                new_r, new_c, s, d, z = move(r, c, board[r][c][0], board[r][c][1], board[r][c][2])
                
                # if sharks conflict
                if temp_board[new_r][new_c] == 0:
                    temp_board[new_r][new_c] = [s, d, z]
                elif z > temp_board[new_r][new_c][2]:
                    temp_board[new_r][new_c] = [s, d, z]
    board = temp_board
print(answer)
 
Colored by Color Scripter

cs

[백준 17144] 미세먼지 안녕!

최성훈 — Sat, 14 Dec 2019 21:45:17 +0900

문제 보기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

import sys
from collections import deque
 
R, C, T = map(int, sys.stdin.readline().split())
board = [list(map(int, sys.stdin.readline().split())) for _ in range(R)]
air_purifier = list()
 
# find air purifier
for r in range(R):
    for c in range(C):
        if board[r][c] == -1:
            air_purifier.append((r, c))
 
# for a given time
directions = ((-1, 0), (0, 1), (1, 0), (0, -1))
for t in range(T):
    spread_q = deque()
    # for all dust on the map
    for r in range(R):
        for c in range(C):
            if board[r][c] > 0:
                spread_amount = board[r][c] // 5
                
                # for all directions
                for dr, dc in directions:
                    next_r = r + dr
                    next_c = c + dc
                    # if next block is available
                    if -1 < next_r < R and -1 < next_c < C:
                        if board[next_r][next_c] != -1:
                            board[r][c] -= spread_amount
                            spread_q.appendleft((next_r, next_c, spread_amount))
    
    # spread dust
    while spread_q:
        r, c, spread_amount = spread_q.pop()
        board[r][c] += spread_amount
 
    # air purifier works counter-clockwise
    base_r, base_c = air_purifier[0]
    for r in range(base_r - 1, -1, -1):
            board[r][base_c] = board[r - 1][base_c]
    for c in range(C - 1):
        board[0][c] = board[0][c + 1]
    for r in range(base_r):
        board[r][C - 1] = board[r + 1][C - 1]
    for c in range(C - 1, base_c, -1):
        if board[base_r][c - 1] == -1:
            board[base_r][c] = 0
        else:
            board[base_r][c] = board[base_r][c - 1]
        
    # air purifier works clockwise
    base_r, base_c = air_purifier[1]
    for r in range(base_r + 1, R - 1, 1):
        board[r][base_c] = board[r + 1][base_c]
    for c in range(C - 1):
        board[R - 1][c] = board[R - 1][c + 1]
    for r in range(R - 1, base_r, -1):
        board[r][C - 1] = board[r - 1][C - 1]
    for c in range(C - 1, base_c, -1):
        if board[base_r][c - 1] == -1:
            board[base_r][c] = 0
        else:
            board[base_r][c] = board[base_r][c - 1]
 
answer = 0
for r in range(R):
    for c in range(C):
        if board[r][c] > 0:
            answer += board[r][c]
print(answer)
 
Colored by Color Scripter

cs

[프로그래머스] 탑

최성훈 — Sun, 10 Nov 2019 22:54:20 +0900

문제 보기

[프로그래머스] 프린터

최성훈 — Sun, 10 Nov 2019 21:52:11 +0900

문제 보기

[프로그래머스] 기능개발

최성훈 — Sun, 10 Nov 2019 19:44:39 +0900

문제 보기