일하는 냐옹이

[Java Design Pattern] Strategy Pattern

Sat, 19 Nov 2022 00:00:00 +0900

Strategy Pattern (책임 연쇄 패턴)

전략패턴 패턴은 Gof Pattern 중 행동패턴에 포함되며 런타임 시 알고리즘을 변경할 수 있다. 일반적으로 알고리즘을 정의하는 인터페이스를 하나 두고 알고리즘을 구현하는 여러개의 구현체로 구성된다.

Diagrams

Context

전략을 포함하고 있는 클래스 컨텍스트는 동작을 구현하는 책임을 Strategy에 위임한다. 실제로 컨텍스트가 전략 변경이 필요한 클래스라고 볼 수 있다. 일반적으로 Strategy를 변경할 수 있는 메소드도 포함하고 있다.

Strategy

말 그대로 전략이다. Context가 필요로 하는 행위를 정의한 interface이다. Strategy은 컨텍스트에 영향을 주지 않고 행동을 변경할 수 있도록 interface로 정의하여 구현한다. 이를 Context의 필요에따라 여러가지 전략으로 구현한다.

Concrete Strategy

Strategy에 선언된 메서드를 구현한 클래스

적용하면 좋은 경우
런타임시에만 어떠한 알고리즘이 필요한지 알 수 있는 경우
클라이언트와 알고리즘을 독립적으로 구분하고 싶을 경우
특정 타입이나 값에 따라서 알고리즘이 변경되는 경우

장점
런타임까지 사용할 전략에 대한 결정을 연기하면 호출 코드가 보다 유연하고 재사용이 가능해진다.
알고리즘을 사용하는 Context와 독립적으로 알고리즘을 변경할 수 있다.
클라이언트와 알고리즘의 결합도 감소 (인터페이스의 정의가 변경되지 않으면 클라이언트는 영향을 받지않음) 

단점
아직까진 떠오르지 않는 거 같음 .... 

적용 예제

가정

피카츄가 포켓몬 배틀에 참여하려고 한다. 피카츄는 하나의 스킬만 가질 수 있으며 스킬은 라운드가 바뀔 때마다 변경할 수 있다. 피카츄가 배틀이 시작됐을 때 자유롭게 스킬을 변경할 수 있도록 도와주자.

Diagrams

Context - (전략을 필요로 하는 대상)

public class Pikachu {
    private Attack attack;

    public Pikachu(Attack attack) {
        this.attack = attack;
    }

    public String conductingBattle() {
        return attack.doAttack();
    }

    public void changeAttack(Attack newAttack) {
        this.attack = newAttack;
    }
}

간단하게 전략을 사용하는 메소드만 포함하고 있다.

Strategy

public interface Attack {
    String doAttack();
}

doAttack()메소드만 포함하고 있는 간단한 전략이다. java8 이상이면 인터페이스 메소드가 하나일 경우 간단한 문법으로 인터페이스 구현체를 생성할 수 있다. 토비의 스프링3.0에서는 전략의 메소드가 하나일 경우 Template/callback 패턴이라고도 부르는 것 같다. 주의할 점은 Template Method Pattern과는 아예 다른 패턴이니 혼동하면 안된다는 것이다.

Concrete Strategy

Concrete Strategy.1

public class HeadbuttAttack implements Attack {
    @Override
    public String doAttack() {
        return "몸통 박치기 !!";
    }
}

Concrete Strategy.2

public class IronTailAttack implements Attack {
    @Override
    public String doAttack() {
        return "아이언 테일!!";
    }
}

Concrete Strategy.3

public class MillionVoltsAttack implements Attack {
    @Override
    public String doAttack() {
        return "백만볼트 !!";
    }
}

배틀 시작

  public class PokemonBattle {
    public static void main(String[] args) {
        Map<String, Attack> attacks = createAttacks();

        System.out.println("Round 1 Start !!");
        Pikachu pikachu = new Pikachu(attacks.get("headButt"));
        System.out.println(pikachu.conductingBattle());

        System.out.println("Round 2 Start !!");
        pikachu.changeAttack(attacks.get("ironTail"));
        System.out.println(pikachu.conductingBattle());

        System.out.println("Round 3 Start !!");
        pikachu.changeAttack(attacks.get("millionVolt"));
        System.out.println(pikachu.conductingBattle());
    }

    private static Map<String, Attack> createAttacks() {
        return  Map.of(
                "headButt", new HeadbuttAttack(),
                "ironTail", new IronTailAttack(),
                "millionVolt", new MillionVoltsAttack()
        );
    }
}

결과 확인

피카츄가 원하는 대로 라운드가 변경될 때마다 스킬을 사용할 수 있게 됐다. 예제가 너무 간단해서 굳이 전략패턴을 사용하지 않아도 구현이 가능했지만,, 전략패턴의 의도가 무엇인지 확인하는 용도로 보면 좋을 것 같다.

Lambda로 전략 생성하기

 Pikachu pikachu = new Pikachu(() -> "몸통 박치기 !!");
        pikachu.changeAttack(() -> "아이언 테일 !!");
        pikachu.changeAttack(() -> "백만볼트 !!");

인터페이스의 메소드가 하나인 경우 위처럼 간단하게 구현체를 생성할 수 있다.

Reference

Strategy Pattern

HTTP/2

Sun, 16 Oct 2022 00:00:00 +0900

HTTP/2

HTTP/2의 주요 목적은 전체 요청 및 응답 다중화를 활성화 하여 대기 시간을 줄이고 HTTP 헤더 필드의 효율적인 압축을 통해 프로토콜 오버헤드를 최소화하며 요청 우선 순위 지정 및 서버 푸시에 대한 지원을 추가하는 것.

HTTP2는 HTTP 프로토콜의 핵심 개념은 변경되지 않았다. 대신 전체 프로세스를 관리하는 클라이언트와 서버 간에 데이터 형식이 프레임으로 지정하고 스트림이라는 연결단위를 통해 헤더 프레임 혹은 본문 프레임을 보낸다. 결과적으로는 기존에 사용하던 HTTP 프로토콜의 버전을 HTTP/2로 변경하여도 애플리케이션은 수정하지 않아도 된다.

기존 HTTP/1.1은 파이프라인을 추가하여 응답을 대기하지 않고 요청을 여러번 보낼 수 있게 되었지만, 응답은 순차적으로 이뤄지기 때문에 후순위 응답은 지연될 수밖에 없다. (네트워크 병목 발생 가능성 높음) 그리고 중복적인 헤더 필드가 매 요청마다 반복될 수 있기 때문에 불필요한 네트워크 트래픽을 유발할 수 있다.

바이너리 프레이밍 레이어

HTTP/2의 성능 향상의 핵심은 HTTP 메세지가 캡슐화되고 클라이언트 서버간에 전송되는 방법을 지시하는 새로운 바이너리 프레이밍 계층의 등장 덕이다.

줄바꿈으로 구분된 일반 텍스트 HTTP/1.x 프로토콜과 달리 HTTP/2 통신은 더 작은 메시지가 프레임으로 분할되며 각각은 이진 형식으로 인코딩된다.

이런 특별한 계층이 추가되었기 때문에 클라이언트와 서버 모두 바이너리 인코딩 메커니즘을 사용하여 서로의 메세지를 이해해야 한다. HTTP/1.x 클라이언트는 HTTP/2 전용 서버를 이해하지 못하고 그 반대도 마찬가지이다.

클라이언트와 서버가 바이너리 프레이밍 작업을 수행하기 때문에 응용 프로그램은 이러한 변화를 인식하지 못한다. (신경쓰지 않아도 된다는 얘기)

헤더압축

HTTP/1.x 에선 헤더의 메타데이터를 항상 일반 텍스트로 전송한다. 헤더에 쿠키등의 정보를 추가하면 HTTP Header의 크기는 HTTP Body의 크기와 별 다를 것 없어진다고 한다. 문제는 HTTP는 무상태 특성을 가지고 있기 때문에 매 요청마다 중복된 Header Field를 전송해야 한다는 것이다. HTTP/2는 이러한 오버헤드를 줄이고 성능을 개선하기 위해 HPACK 압축 형식을 사용하여 요청 및 응답 헤더를 압축한다.

주절주절

아직 제대로 이해 못했지만 ,, Static Table과 Dynamic Table이 존재하는데 Static Table에는 HTTP/2 Spec에 정의된 자주 사용되는 Key-Value 값 쌍을 저장하고 있고 Dynamic Table은 한번 송수신한 Header의 Key-Value를 저장해둔다고 한다.

첫 요청에서 Static Table에 저장된 key 값으로 헤더의 바이트 크기를 줄이고 Static Table에 저장되어있지 않은 값은 Dynamic Table에 저장해두는 것 같다.

그리고 이후 요청에서 Static Table의 값과 Dynamic Table의 값으로 전부 대체할 수 있다면 헤더의 크기는 상당히 줄어드는 것으로 보인다.

응답 다중화(Multiplexing)

HTTP/1.x는 클라이언트가 다중 병렬 요청을 하려면 다중 TCP 연결을 사용해야 한다. 이 경우 연결당 한번의 하나의 응답만 전달된다. 이는 Head of Line Blocking이 발생하고 TCP 연결이 비효율적으로 사용될 수 있다는 문제점이 있다.

HTTP/2는 이러한 문제점을 해결하기 위해 Multiplexing 방법을 도입하였다. Multiplexing 방식은 기존 HTTP/1.1과 동일하게 여러개의 요청을 받지만 Stream channel을 이용하여 하나의 Connection 만으로 여러개의 응답을 받을 수 있다. MultiConnection과 Multiplexing의 차이인 듯 하다. 동작 방식은 아직 잘 이해 못하겠다. 어렵다.

서버 푸쉬(Server Push)

HTTP/1.1 이전 버전에서는 클라이언트가 서버에 요청을 보내야만 원하는 데이터를 응답받을 수 있었다.

HTTP/2 서버푸쉬를 이용하면 클라이언트가 요청하기 전에 HTTP/2 호환 서버가 리소스를 HTTP/2 호환 클라이언트에게 보낼 수 있다. 서버 푸쉬의 목적은 클라이언트가 리소스가 필요한지 알기도 전에 미리 리소스를 로드하여 대기 시간을 줄이는 것을 목표로 하는 기술이다. 이때 한 페이지 렌더링에 필요한 여러 리소스를 전달하더라도 한 라운드의 HTTP 통신만 필요하기 때문에 성능이 향상된다고 한다.

그런데 Google 크롬 팀에 따르면 HTTP/2의 서버 푸쉬는 거의 사용되지 않는다고 한다. 실제로 푸시된 리소스를 사용하는 경우보다 사용하지 않는 이유 때문이라고 한다.

HTTP/2 버전 식별

h2 = TLS 사용하는 HTTP/2
h2c = TLS 사용하지 않는 HTTP/2 ALPN 프로토콜 식별자로 직렬화

Reference

[토비의 스프링] 토비의 스프링 3.1 2장 테스트

Wed, 05 Oct 2022 00:00:00 +0900

게시글에는 책의 설명과 무관한 내용이 섞여있습니다.

테스트

계속 변화하는 애플리케이션에 대응하는 첫번째 전략이 확장과 변화를 고려한 객체지향 설계와 그것을 효과적으로 담아낼 수 있는 IoC/DI 같은 기술이라면

두번째 전략은 만들어진 코드를 확신할 수 있게 해주고 변화에 유연하게 대처할 수 있는 테스트 기술이다. 스프링으로 개발하면서 테스트를 만들지 않는다면 이는 스프링이 지는 가치의 절반을 포기하는 셈이다.

UserDaoTest 다시보기

테스트의 유용성

처음과 동일한 기능을 수행함을 보장해줄 수 있는 방법은 바로 테스트이다.
테스트란 결국 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지 검증하기 위한 작업
테스트가 정확히 동작하지 않는다는 것은 코드나 설계에 결함이 있음을 알 수 있음. 즉 개발자는 테스트를 통해 코드의 결함을 제거할 수 있음

웹을 통한 DAO 테스트의 문제점

보통 웹 프로그램에서 DAO를 테스트하려면 웹 프로그램을 실행하기 위한 모든 계층의 코드를 전부 작성하고 이를 서버에 배치한뒤 실행시켜서 직접 사용자가 사용하는 방식처럼 테스트 해야한다.

이러한 테스트는 비효율적이다. 첫번째 문제점은 DAO를 테스트하기 위한 부가작업이 너무 많다는 점이고 두번째는 목적은 DAO 테스트지만 다른 계층에서 문제가 발생하면 그 문제를 찾아내야한다는 수고가 필요하다.

목적은 DAO 테스트 였는데 다른 계층의 코드와 컴포넌트, 그리고 서버 설정 상태까지 모두 테스트에 영향을 줄 수 있기 때문에 직접 웹 프로그램을 실행시켜서 테스트 하는 방법은 비효율적이다.

작은 단위의 테스트

테스트하고자 하는 대상이 명확하다면 그 대상에만 집중해서 테스트하는 것이 바람직함
테스트는 가능하면 작은 단위로 쪼개서 집중해서 할 수 있어야 한다.
통제할 수 없는 외부의 리소스에 의존하는 테스트는 단위 테스트라고 보기 어려울 수 있음
외부 리소스에 의존하는 경우 통합 테스트나 인수 테스트를 이용하여 검증할 필요가 있음
많은 단위가 참여하는 테스트는 문제의 원인을 찾는게 어려울 수 있으니 단위 테스트로 먼저 검증을 하고 난 뒤에 단위를 묶어 테스트 하는 것이 바람직

지속적인 개선과 점직전인 개발을 위한 테스트

처음 만든 초난감 DAO 코드를 객체지향적 코드로 발전시키는 과정의 일등 공신은 테스트였음
테스트가 없었다면 다양한 방법을 동원해서 코드를 수정하고 설계를 개선해나가는 과정이 미덥지 않을 수 있고 마음이 불편해지면서 개선을 멈췄을 수도 있음
결론은 DAO 기능을 검증해주는 테스트가 있었기 때문에 점직적으로 코드를 개선할 수 있었던 것. 코드의 결함도 테스트를 통해 빠르게 알아낼 수 있었음
테스트를 이용하면 새로운 기능의 정상동작을 확인할 뿐만 아니라 기존에 만들어뒀던 코드가 새로운 기능을 위해 수정한 코드로 인해 영향을 받지 않는지 확인할 수 있음

main()을 이용한 테스트의 문제점

수동 확인 작업의 번거로움

UserDaoTest는 수행하는 과정과 입력 데이터의 준비를 모두 자동으로 진행하지만 값이 올바른지는 출력된 데이터를 보고 개발자가 판단해야 한다. 즉 테스트 수행은 코드에 의해 자동적으로 진행되지만 결과를 확인하는 일은 사람의 책임이므로 완전히 자동으로 테스트되는 방법이라고 말할 수 없다. 이러한 방법은 검증할 단위가 적을때는 문제가 되지 않지만 테스트가 커질수록 불편하다. 또한 작은 차이는 발견하지 못하고 지나칠 수 있다.

실행 작업의 번거로움

간단히 실행 가능한 main() 메소드라고 해도 매번 실행하는 것은 번거로울 수 있다. 테스트할 클래스가 수백개가 되고 main() 메소드도 그만큼 만들어진다면 전체 기능을 테스트하기 위해 main() 메소드를 수백번 실행해야하는 수고가 필요하다. 그리고 결과를 확인하는 것도 사람의 몫이기 때문에 수백개의 실행결과를 보고 정상수행인지 직접 확인해야한다. 결론은 main() 메소드를 실행하는 방법보다 좀 더 편리하고 체계적으로 테스트를 실행하고 그 결과를 확인하는 방법이 필요하다.

테스트의 효율적인 수행과 결과 관리

main 메소드로는 편리한 수행과 편리한 결과 확인이 어렵다. 때문에 일정한 패턴을 가진 테스트를 만들 수 있고, 많은 테스트를 간단하게 실행시키고, 테스트 결과를 간단하게 확인하고 실패한 곳을 빠르게 찾아갈 수 있는 기능을 갖춘 테스트 지원 도구와 그에 맞는 테스트 작성 방법이 필요하다.

Junit 테스트로 전환

Junit은 프레임워크이다. 프레임워크의 기본 동작원리는 제어의 역전이다. 프레임워크는 개발자가 만든 클래스의 제어 권한을 넘겨받아서 주도적으로 애플리케이션 흐름을 제어한다. Junit도 개발자가 만든 클래스의 오브젝트를 생성하고 실행하는 일을 대신한다. 따라서 프레임워크에서 동작하는 코드는 main() 메소드도 필요없고 오브젝트를 만들어서 실행시키는 코드를 만들 필요도 없다.

테스트 메소드 전환

새로 만들 테스트 메소드는 Junit 프레임워크가 요구하는 두가지 조건을 따라야한다.

메소드가 public으로 선언되어야 한다.
테스트 메소드의 리턴값은 void여야 한다.
메소드에 @Test라는 애노테이션을 붙여줘야 한다.

빌드 툴

개발자 개인별로 IDE에서 Junit 도구를 사용해 테스트를 실행하는 것이 가장 편리하지만 여러 개발자가 만든 테스트 코드를 통합해서 테스트를 수행해야 할 때는 서버에서 모든 코드를 가져와 통합하고 빌드한 뒤애 테스트를 수행하는 것이 좋다. 이떄는 빌드 스크립트를 이용해 Junit 테스트를 실행하고 결과를 메일로 통보받는 방법을 사용하면 된다.

(개인적인 생각) 위와같은 상황 뿐만 아니라 테스트가 너무 많아 실행시간이 오래 소요되는 경우도 빌드 스크립트를 이용하면 좋은 해결 방법이 될 수 있을 것 같다.

테스트 결과의 일관성

테스트의 결과가 외부 상태에 따라 성공하기도 실패하기도 한다는 것은 큰 문제이다. 테스트는 코드가 변경되지 않으면 항상 동일한 결과를 내야한다.
기존 UserDaoTest의 문제는 이전 테스트 때문에 DB에 등록된 중복 데이터가 있을 수 있다는 점이다.
가장 좋은 해결책은 addAndGet() 테스트를 마치고 나면 테스트를 위해 등록된 데이터를 삭제해서 테스트를 수행하기 이전 상태로 만들어주는 것이다.
이러한 방식을 사용하면 테스트를 여러번 반복해서 실행하더라도 항상 동일한 결과를 얻을 수 있다.

포괄적인 테스트

테스트를 만들지 않는 것도 위험한 일이지만 성의없이 테스트를 만드는 바람에 문제가 있는 코드인데도 테스트가 성공하게 만드는 것은 더 위험하다.
특히 한 가지 결과만 검증하고 마는 것은 상당히 위험하다. 이런 테스트는 마치 하루에 두 번은 정확히 맞는다는 시계와 같을 수 있다.
모든 코드의 수정 후에는 그 수정에 영향을 받을만한 테스트를 실행하는 것을 잊지 말아야한다. (사이드 이펙트 체크)
모든 테스트는 실행 순서에 상관없이 독립적으로 항상 동일한 결과를 낼 수 있도록 해야한다.
성공하는 테스트 뿐만 아니라 실패하는 경우의 테스트도 작성해야 한다. 실패하는 테스트를 작성하면 예외적인 상황을 빠뜨리지 않는 꼼꼼한 개발이 가능하다.

테스트 주도 개발(TDD)

테스트 코드를 먼저 작성하고 이후 테스트 코드에서 정의된 기능을 프로덕션 코드로 작성하여 테스트를 성공하게 하는 방식의 개발 방법을 테스트 주도 개발(TDD) 이라고 한다.

테스트에 만들고 싶은 기능의 대한 조건과 행위 결과에 대한 내용이 잘 표현되어있으면 테스트 코드가 기능 정의서의 역할을 대신할 수 있다.

TDD는 테스트를 만들고 그 테스트가 성공하도록 하는 코드만 만드는 식으로 진행하기 때문에 테스트를 빼먹지 않고 꼼꼼하게 만들어낼 수 있다.
또한 테스트를 작성하는 시간과 애플리케이션 코드를 작성하는 시간의 간격이 짧아진다.
테스트를 작성하고 이를 성공시키는 코드를 만드는 작업의 주기는 짧게 가져가는 것이 좋다.
사실 개발자는 TDD를 몰라도 이미 테스트가 개발을 이끄는 방식으로 개발을 하고 있다고 생각한다. 머릿속으로 기능 정의서를 그려놓고 정의서에 맞춰서 개발하기 때문이다.
- 문제는 이렇게 머릿속으로 진행하는 테스트는 제약이 심하고, 오류가 많고, 다시 반복하기 힘들다는 점이다.
- 차라리 머릿속으로 복잡하게 진행하던 테스트를 실제 코드로 끄집어 내놓으면 이게 바로 TDD가 된다.

(개인적인 생각) 간단하게 성공시키는 코드를 작성하고 테스트를 수행하면서 개선하는 방법이 이미 완성된 프로덕션 코드를 작성하는 것보다 효율적이고 문제점을 빠르게 찾을 수 있다고 생각한다.

Junit의 테스트 독립성 보장

junit은 각 테스트 메소드를 실행할 때마다 테스트 클래스의 인스턴스를 새로 생성한다. 한번 만들어진 테스트 클래스의 오브젝트는 하나의 테스트 메소드를 사용하고나면 버려진다. 테스트 클래스가 @Test 테스트 메소드를 2개 가지고 있다면 테스트 클래스의 인스턴스는 두 번 생성된다. 이러한 방법을 사용하는 이유는 각 테스트의 독립성을 보장하기 위해서이다.

그러나 ApplicationContext 처럼 생성에 많은 시간과 자원이 소모되는 경우에는 테스트 전체가 공유하는 오브젝트를 만들기도 한다. 이때도 테스트는 일관성있는 실행 결과를 보장해야하고, 테스트의 실행 순서과 결과에 영향을 미치지 않아야 한다.

픽스처?

테스트를 수행하는 데 필요한 정보나 오브젝트를 픽스처(fixture)라고 한다. 일반적으로 픽스처는 여러 테스트에서 반복적으로 사용되기 때문에 @Before 메소드를 이용해서 생성해두면 편리하다.

DI와 테스트

구현체가 절대 변하지 않는다고 해도 DI를 사용해야 하는 세가지 이유가 있다.

첫째, 소프트웨어 개발에서 절대 바뀌지 않는 것은 없다. 클래스 대신 인터페이스를 사용하고 new를 이용해 생성하게 하는 대신 DI를 통해 주입받게 하는 것은 아주 단순하고 쉬운 작업이다.

둘째, 구현체가 변경되지 않는다고 해도 인터페이스를 두고 DI를 적용하게 해두면 기존의 서비스 기능 자체를 확장할 수 있기 때문이다.

셋째, 세번째 이유는 테스트 때문이다. 단지 효율적인 테스트를 손쉽개 만들기 위해서라도 DI를 적용해야 한다. 테스트를 잘 활용하려면 자동으로 실행 가능하며 빠르게 동작하도록 테스트 고드를 만들어야 한다. DI는 테스트가 작은 단위의 대상에 대해 독립적으로 만들어지고 실행되게 하는데 중요한 역할을 한다.

DirtiesContext

스프링 테스트 컨텍스트 프레임워크를 적용하면 애플리케이션 컨텍스트는 테스트 중에 딱 하나만 만들어지고 모든 테스트에서 공유한다. 이러한 상황에서 애플리케이션 컨텍스트의 구성이나 상태를 하나의 테스트를 위해 변경하면 나머지 모든 테스트에도 영향을 끼칠 수 있어 위험하다.

이러한 문제는 @DirtiesContext를 사용하면 어느정도 해결될 수 있다. 이 어노테이션이 붙은 테스트 클래스에는 애플리케이션 컨텍스트 공유를 허용하지 않는다. 하지만 클래스 위에 @DirtiesContext를 선언할 경우 해당 클래스의 테스트를 실행할 때마다 애플리케이션 컨텍스트를 새로 만들기 때문에 완벽한 해결 방법이라고 보기엔 어렵다.

하나의 메소드에서만 컨텍스트 상태를 변경한다면 메소드 레벨에 @DirtiesContext 를 붙여주는 것이 더 낫다. 
해당 메소드의 실행이 끝나고 나면 이후에 진행되는 테스트를 위해 변경된 애플리케이션 컨텍스트는 폐기되고 새로운 애플리케이션 컨텍스트가 만들어진다.

테스트를 위한 별도의 DI 설정

테스트에서 사용될 applicationContext를 따로 정의해두면 테스트에 필요한 설정 정보만 사용할 수 있으므로 효율적으로 테스트 할 수 있다.
테스트하기 불편하게 설계된 코드가 좋은 코드일 확률은 매우 낮다.

DI를 이용한 테스트 방법 선택

스프링 컨테이너 없이 테스트할 수 있는 방법을 가장 우선적으로 고려
- 이 방법이 테스트 수행속도가 가장 빠르다
여러 오브젝트와 복잡한 의존관계를 맺을 경우 스프링의 설정을 이용한 DI 방식의 테스트를 이용하면 편리함
예외적인 의존관계를 강제로 구성해야할 경우 수동 DI 해서 테스트하는 방법을 고려할 수 있음.

학습 테스트로 배우는 스프링

보통 개발자는 자신이 작성한 기능에 대해서만 테스트를 작성하면 됨
그러나 때로는 자신이 만들지않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리 등에서도 테스트를 작성할 수도 있음
- 이러한 테스트를 학습 테스트 라고 함
학습 테스트의 목적은 자신이 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용 방법을 익히려는 것
- 프레임워크나 라이브러리에 대한 검증이 아닌 자신이 얼마나 해당 기술이나 기능을 제대로 이해하고 있는지 확인하는 목적

학습 테스트의 장점

다양한 조건에 따른 기능을 손쉽게 확인해볼 수 있음
학습 테스트 코드를 개발 중에 참고할 수 있음
프레임워크나 제품을 업그레이드할 떄 호환성 검증을 도와줌
테스트 작성에 대한 좋은 훈련이 됨
새로운 기술을 공부하는 과정이 즐거워짐

버그테스트

QA팀의 테스트 중 기능에서 오류를 발견했다고 가정했을 때 무턱대고 코드를 수정하는 것보다 버그 테스트를 만들어보는 편이 유용하다.
버그 테스트는 처음에 버그가 원인이되어 실패하게 만들고 이후에 버그 테스트가 성공할 수 있도록 애플리케이션 코드를 수정한다.
- 이떄 테스트가 성공하면 버그는 수정된 것

장점

테스트의 완성도를 높여준다.
- 기존 테스트에서 발견하지 못한 이슈를 버그 테스트를 통해 완성도 향상
버그의 내용을 명확하게 분석하게 해준다
- 버그를 테스트로 만들어서 실패하게 하려면 버그의 원인을 명확히 알아야한다.
- 때문에 버그를 효과적으로 분석 가능
기술적인 문제를 해결하는 데 도움이 된다.
- 버그가 있는 것은 알지만 원인을 파악하기 힘들 때 도움이 됨
- 코드 분석으로 파악하기 힘들경우 동일한 문제가 발생하는 가장 단순한 코드와 그에 대한 버그 테스트를 만들어보면 도움이 됨

- 동등분할
같은 결과를 내는 값의 범위를 구분해서 각 대표 값으로 테스트하는 방법
어떤 작업의 결과 종류가 true, false, 또는 예외발생 세 가지라면 각 결과를 내는 입력 값이나 상황의 조합을 
만들어서 모든 경우에 대한 테스트를 해보는 것이 좋음

- 경계값 분석
에러는 동등분할 범위의 경계에서 주로 발생한다는 특징을 이용해서 경계의 근처에 있는 값을 이용해 테스트하는 방법
보통 숫자의 입력 값인 경우 0이나 그 주변 값 또는 정수의 최대값, 최소값 등으로 테스트 해보면 도움이 될 때가 많음

정리

테스트는 자동화 되어야 하고 빠르게 실행되어야 함
main() 테스트보다 junit 프레임워크를 이용한 테스트가 생산적임
테스트를 작성할 때 스프링에 의존하지 않는 테스트 작성 방법을 첫번째로 고려해보기
테스트 작성이 힘든 코드는 잘 설계된 코드라고 할 수 없음
테스트코드 작성 주기와 실제 기능 구현 주기는 짧게 가져가야 함
성의없이 테스트를 작성하지 말 것 (문제가 있는 코드인데 테스트를 통과하게 되면 곤란)
오류가 발견될 경우 그에 대한 버그 테스트를 만들어두면 유용
학습 테스트를 통해 프레임워크나 라이브러리에 대한 이해도를 검증할 수 있음
스프링을 사용하지 않더라도 DI는 유연한 테스트를 가능하게 해줌
기능을 먼저 구현하고 테스트를 작성하는 것이 아닌, 테스트를 먼저 작성하고 기능을 구현하는 TDD 방식을 고려해볼 수도 있음.

[토비의 스프링] 토비의 스프링 3.1 1장 오브젝트와 의존관계

Sun, 18 Sep 2022 00:00:00 +0900

게시글에는 책의 설명과 무관한 내용이 섞여있습니다.

오브젝트와 의존관계

DAO(Data Access Object)는 DB를 사용해 데이터를 조회하거나 조작하는 
기능을 전담하도록 만든 오브젝트를 말한다.

초난감 DAO

현재 초난감 UserDao의 코드는 객체지향적이지 않음. 예제 그대로일 경우 exception이 발생하면 리소스 해제가 되지 않을 것이고 매번 메소드를 호출할 때마다 매번 커넥션을 생성해서 연결해야하는 리소스적 단점도 존재함

잘 동작하는 코드이지만 문제점이 많은 코드이기에 개선이 필요함. 코드를 개선할 때는 개선해서 얻을 수 있는 장점과 편리함을 생각해야함. 스프링을 공부한다는 것은 이런 문제 제기와 의문에 대한 답을 찾아나가는 과정

초난감 DAO를 테스트 하면서 느꼈던 불편함 !

항상 동일한 대상을 등록하기 때문에 여러번 실행하면 실패함
초난감 DAO를 테스트하기 위해서 실제 사용되는 데이터베이스의 값을 수정하는 것이 마음에 걸림

DAO의 분리

소프트웨어는 변함 . 서비스가 종료되기 전까지는 끊임없이 변한다.
개발자는 변화를 어떻게 대응할 건지 생각해야함. 변화에 대응할 수 있는 유연한 설계가 필요
견고한 설계는 번거롭고 시간이 많이 소요됨. 하지만 요구사항이 변경되었을 때 변화를 대비하지 않은 코드보다 코드 수정 비용이 적음
분리와 확장을 고려하여 설계하여라.
관심사가 같은 것은 하나의 객체에 모이게 하고 관심사가 다른 것은 분리하여 서로 영향을 주지 않도록 하기
관심사를 분리하면 한가지 관심사에 대한 변경이 일어났을 때 그 관심에 집중되는 코드만 수정하면 됨 다른 코드가 있는 메서드에는 영향을 주지않고 관심내용이 독립적이므로 수정이 간단함

상속을 통한 확장 (템플릿 메서드 패턴)

상속을 통해 확장하면 관심사가 다른 코드를 분리해내고 독립적으로 변경, 확장이 가능하지만 두 가지 다른 관심사와의 긴밀한 결합을 허용한다.
서브 클래스는 슈퍼 클래스의 메서드를 사용할 수 있기 때문에 슈퍼 클래스가 변경될 때 서브 클래스에 영향이 갈 수 있음
관심사가 새로 추가될 때마다 매번 클래스를 생성해야 한다는 문제점이 있다.
단순한 기능을 위해 상속을 사용하게되면 다른 목적으로 새로운 클래스를 상속할 수 없다는 것도 문제가 된다. (자바는 다중 상속이 불가능 함)

DAO의 확장

관심사를 나눠 두개의 클래스로 분리

DB 커넥션과 DB 조작 관심사를 분리하여 클래스로 나누면 기능이 변화되지 않고 내부 코드를 개선할 수 있음
그렇지만 UserDao가 커넥션을 관리하는 클래스와 종속되어 있기 때문에 상속을 사용했을 때처럼 코드 수정없이 DB 커넥션 기능을 변경할 방법이 없음
구체적으로 사용할 클래스의 정보를 아는 것은 좋지않음. 구체적으로 정보를 알고있으면 그 해당 클래스와 종속되는 문제가 생김

관계설정 책임의 분리

UserDao의 ConnectionMaker를 추상화된 타입으로 변경했지만 UserDao 안에서 new 연산자로 SimpleConnectionMaker를 생성하고 있기 때문에 둘 사이의 강한 연결 관계가 형성된다.

UserDao가 독립적으로 확장 가능한 클래스가 되려면 UserDao에서 사용하는 객체들의 구현을 알지 못해야 한다. 때문에 구현체를 UserDao를 호출하는 클라이언트가 UserDao에게 주입하는 방식으로 결합을 끊어야한다.

UserDao가 느슨한 결합으로 DConnection 오브젝트를 사용하게 하려면 두 클래스의 오브젝트 사이에 사용관계 또는 링크, 또는 의존관계 라고 불리는 관계를 맺어주면 된다.

코드를 변경하기전 초난감 DAO는 OCP를 위배하고 있었지만, 변경된 코드는 OCP 원칙을 잘 따르고 있음

높은 응집도와 낮은 결합도

개방 폐쇄 원칙은 높은 응집도와 낮은 결합도라는 소프트웨어 개발의 고전적인 원리로도 설명이 가능하다. 응집도가 높다는 것은 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어있다는 것을 의미한다.

응집도가 높은 클래스는 요구사항 변경이 일어날 때 해당 클래스 기능의 대부분이 변경된다. 이때 만약 모듈의 일부분만 변경된다면 모듈 전체에서 어떤 부분이 바뀌어야하는지 파악해야 하고, 그 변경으로 인한 사이드이펙트를 모두 체크해야 한다.

낮은 결합도

결합도가 낮은 연결은 관계를 유지하기 위한 최소한의 정보만을 제공하고 나머지는 독립적으로 서로 알지 못하게 해야한다. 하나의 오브젝트가 변경이 일어날 때 관계를 맺고 있는 다른 오브젝트들도 변경이 일어나는 경우 결합도가 높다고 볼 수 있다.

전략 패턴

전략패턴이란 자신의 기능 맥락에서 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 외부로 분리시키고
이를 구현한 구체적인 알고리즘을 필요에 따라 바꿔서 사용하게 해주는 디자인 패턴

초난감 DAO의 개선된 코드는 스프링의 의존주입을 나타냈다고 느꼈음. 실제로 스프링은 빈 팩토리를 이용하여 의존을 주입하는데 이때 필요에 따라 사용될 구현체를 변경하여 주입할 수 있기 때문에 스프링의 의존 주입이 전략패턴과 같다고 느꼈음.

스프링의 의존을 주입하기 위해 팩토리 패턴, 전략패턴 그리고 또 어떤게 있을까..? 당장은 두 가지가 떠오름

제어의 역전(IoC)

팩토리

보통 객체의 생성방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 것을 팩토리라고 한다. 이때 말하는 팩토리는 디자인 패턴에서 다루는 추상 팩토리 패턴이나 팩토리 메서드 패턴과는 다르니 혼동하지 말아야 한다. 팩토리 메소드는 생성할 타입의 오브젝트를 어떻게 만들고 어떻게 준비시킬지 결정한다.

설계도로서의 팩토리

UserDao와 ConnectioMaker는 애플리케이션의 핵심적인 데이터 로직과 기술 로직을 담당하고 있다. DaoFactory는 애플리캐이션을 구성하는 컴포넌트의 구조와 관계를 정의한 설계도 같은 역할을 한다고 볼 수 있다.

DaoFactory를 분리했을 때 얻을 수 있는 장점은 매우 많지만 그중에서도 애플리케이션의 컴포넌트 역할을 하는 오브젝트와 애플르케이션의 구조를 결정하는 오브젝트를 분리했다는 데 가장 의미가 있다.

제어권의 이전을 통한 제어관계 역전

제어의 역전을 간단하게 설명하면 프로그램의 흐름이 뒤바뀌는 것

일반적으로 프로그램의 흐름은 프로그램이 시작되는 지점에서 위에서 아래로 흘러간다. 그리고 각 지점마다 사용할 오브젝트를 직접 생성한다. 반면 IoC는 자신이 사용할 오브젝트를 스스로 선택하지 않고 생성하지도 않는다. 일반적인 프로그래밍 방식처럼 오브젝트가 능동적이지 않고 수동적이다.

왜냐하면 관계 연결에 대한 모든 제어 권한을 자신이 아닌 다른 대상에게 위임하기 때문이다. 프로그램의 시작을 담당하는 main()과 같은 엔트리 포인트를 제외하면 모든 오브젝트는 이렇게 위임받은 제어 권한을 갖는 특별한 오브젝트에 의해 결정되고 만들어진다.

스프링의 IoC

스프링의 핵심을 담당하는 것은 빈 팩토리 또는 애플리케이션 컨텍스트라고 불리는 것이다.

오브젝트 팩토리를 이용한 스프링 IoC

스프링 Bean은 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트를 가리키는 말이다. 

애플리케이션 컨텍스트

오브젝트 팩토리에 대응되는 것이 스프링의 애플리케이션 컨텍스트. 애플리케이션 컨텍스트는 IoC 컨테이너라고도 불리고 빈 팩토리라고 부를 수도 있다. 애플리케이션 컨텍스트는 ApplicationContext 인터페이스를 구현하였는데, ApplicationContext 인터페이스가 BeanFactory 인터페이스를 상속했으므로 애플리케이션 컨텍스트는 일종의 빈 팩토리이다.

애플리케이션 컨텍스트는 애플리케이션에서 IoC를 적용해서 관리할 모든 오브젝트(Bean)에 대한 생성과 관계설정을 담당한다. ApplicationContext는 코드에서 직접 오브젝트를 생성하고 관계를 연결해주는 코드가 존재하지 않고, 오브젝트간의 관계를 설정정보를 통해 얻는다. 때로는 외부의 오브젝트 팩토리에 그 작업을 위임하고 그 결과를 가져다 사용하기도 한다.

애플리케이션 컨텍스트를 사용했을 때 얻을 수 있는 장점

클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다
- 오브젝트 팩토리는 클라이언트가 필요한 오브젝트를 가져오려면 구체적인 오브젝트 팩토리를 알아야한다.
- 오브젝트 팩토리는 새로운 오브젝트 팩토리가 필요할 때마다 오브젝트 팩토리 클래스를 추가해야한다.
애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다.
- 빈이 사용할 수 있는 기반기술 서비스나 외부 시스템과의 연동 등을 컨테이너 차원에서 제공해줌
- 오브젝트 생성과 관계 연결뿐만 아니라 객체의 생명주기, 만들어지는 방식, 후처리 설정 다변화 인터셉팅 등 오브젝트를 효과적으로 사용할 수 있는 기능 제공
애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공한다.
- 이름으로 빈을 검색할 수 있는 것 뿐만아니라 타입이나 선언된 어노테이션 등으로 빈을 검색할 수 있다.

스프링의 싱글톤 레지스트리

스프링은 싱글톤 패턴처럼 IoC 컨테이너에서 관리하는 빈의 인스턴스를 오직 하나만 생성하여 관리해준다. 이는 개념적으로 싱글톤 패턴과 닮았지만 실제 구현 방법에서는 큰 차이가 있다.

싱글톤 패턴

보통 싱글톤 패턴은 밖에서 오브젝트를 생성하지 못하게 생성자를 private으로 막아둔다. 그리고 인스턴스를 가져오는 메소드를 호출 할 때 인스턴스가 없으면 내부에서 생성하여 넘겨주고 이미 생성되어 있다면 static 필드에 저장해둔 오브젝트를 넘긴다. 이렇게만 보면 큰 문제가 없어보이지만 이렇게 구현된 싱글톤 오브젝트는 아래와 같은 단점이 존재한다.

private 생성자를 사용하고 있기 때문에 상속이 불가능. 다형성을 이용할 수 없음
싱글톤은 오브젝트를 만드는 방식이 제한적이기 때문에 테스트에서 사용될 때 목 오브젝트 등으로 대체하기가 힘듦
서버환경에서 싱글톤이 하나만 만들어지는 것을 보장하기가 어려움
싱글톤의 사용은 전역의 상태를 만들 수 있기 때문에 바람직하지 못함

싱글톤 레지스트리

스프링은 특별한 설정을 하지 않으면 기본적으로 빈을 싱글톤으로 관리한다. 앞서 소개한 것처럼 자바의 싱글톤 패턴은 여러가지의 단점이 있기 때문에 스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다. 스프링의 싱글톤 레지스트리는 싱글톤 패턴처럼 비정상적인 방법으로 싱글톤을 제공하는 것이 아닌 평범한 자바 클래스를 싱글톤으로 활용하게 해준다. 때문에 제약없이 클래스를 자유롭게 활용할 수 있고 스프링의 지지하는 객체지향 설계방식을 적용하는데에 아무런 제약이 없다.

싱글톤이기에 조심해야할 점

싱글톤은 자원을 효율적으로 사용할 수 있는 대신에 꼭 조심해야할 부분이 있다. IoC 컨테이너에서 오브젝트를 생성하고 그 오브젝트를 필요로 할 때 이미 생성된 오브젝트를 주입해주기 때문 멀티스레드 환경에서 동시성 문제가 발생할 수 있다. 결국 생성된 오브젝트는 heap 영역에 저장되기 때문에 모든 스레드가 접근할 수 있기 때문이다. 그래서 싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우 상태정보를 내부에 갖고 있지 않은 무상태 방식으로 만들어져야 한다. 그러나 읽기 전용의 값이라면 초기화 시점에 인스턴스 변수에 저장하고 공유하는 것은 문제가 되지 않는다.

의존관계 주입

IoC 컨테이너라는 단어만으로는 스프링이 제공하는 기능의 특징을 명확하게 설명하지 못함. IoC 개념이 적용된 템플릿 메소드 패턴을 이용한 프레임워크인지 서블릿 컨테이너처럼 서버에서 동작하는 프레임워크인지 명확하게 알 수 없음. 때문에 스프링이 제공하는 IoC 기능을 명확하게 설명하기 위해서 DI(의존관계 주입)이라는 좀 더 의도가 명확한 이름을 사용하기로 결정

DI의 핵심은 오브젝트 레퍼런스를 외부로부터 제공받아 이를 통해 여타 오브젝트와 동적으로 의존관계를 맺는 것이 핵심

스프링은 런타임시에 의존을 주입해준다. 그렇기 때문에 코드에는 런타임 시점의 의존관계가 들어나지 않는다. 그러기 위해선 인터페이스에만 의존해야한다. 이후 런타임 시점의 의존관계는 컨테이너나 팩토리같은 제3의 존재가 결정한다. 이후 의존관계는 제 3의 존재가 사용할 오브젝트 레퍼런스를 제공해줌으로써 만들어진다.

의존관계 검색과 의존관계 주입의 차이

의존관계 주입은 말 그대로 외부에서 생성자나 메소드로 의존을 주입 받지만 의존관계 검색은 의존관계를 맺을 오브젝트를 결정하는 것과 오브젝트 생성을 컨테이너에게 요청하고 이를 가져올 때는 생성자를 통한 주입 대신 스스로 컨테이너에게 요청하는 방법을 사용한다.

의존관계 검색도 의존관계 주입의 모든 장점을 갖고있지만 코드안에 오브젝트 팩토리나 스프링 API가 나타나는 단점이 있다. 대신 의존관계 검색을 사용하는 오브젝트는 직접 컨테이너에게 요청하기 때문에 스프링의 빈일 필요가 없다. 반면 의존관계 주입은 컨테이너가 주입받을 대상의 정보를 알고있어야 하므로 IoC 컨테이너에서 생성되는 오브젝트(Bean)여야 한다.

메소드를 이용한 의존관계 주입

1. 수정자 메소드를 이용한 주입

수정자 메소드를 이용한 의존관계 주입 방법은 외부로부터 제공받은 오브젝트 레퍼런스를 저장해뒀다가 내부의 메소드에서 사용하게 하는 DI 방식에서 활용하기에 적당하다.

2. 일반 메소드를 이용한 주입

수정자 메소드의 제약이 싫을 경우 일반 메소드를 이용하여 의존을 주입할 수 있다. 이 방식은 적절한 수의 파라미터를 가진 여러개의 초기화 메소드를 만들 수 있다는 장점이 있기 때문에 한번에 모든 필요한 파라미터를 다 받아야하는 생성자 주입보다 사용이 편리할 수 있다.

1장 정리

관심사의 분리

초난감이었던 UserDao의 관심사를 분리하여 리팩토링

변화가 잦은 부분을 추상화

클라이언트가 구체적인 구현체에 의존하지 않고 추상화된 인터페이스에 의존하게 된다면 구현체가 변경되어도 클라이언트는 코드를 수정하지 않아도 됨 (전략패턴)
관심사를 분리할 때 변화가 잦은 부분을 추상화하여 외부에서 구현체를 결정할 수 있도록 하면 (의존주입) 낮은 결합의 의존관계를 맺을 수 있음
결과로 한쪽의 기능 변화가 다른 쪽의 변경을 요구하지 않아도 되게 했고(낮은 결합도) 자신의 책임과 관심사에게만 순수하게 집중 할 수 있도록 함(응집도)

개방 폐쇄 원칙

자신의 책임 자체가 변경되는 경우 외에는 불필요한 변화가 발생하지 않게 막아주고 자신이 사용하는 외부 오브젝트의 기능은 자유롭게 확장하거나 변경할 수 있게 만들었음 (OCP)

제어의 역전 (IoC)

오브젝트가 생성되고 다른 오브젝트와 관계를 맺는 책임을 별도의 팩토리, 컨테이너에게 넘기고 자신이 사용할 오브젝트의 생성과 선택에 대해 자유로워졌음

의존관계 주입 (DI)

설계 시점과 코드에는 인터페이스로 느슨한 의존관계를 만들어놓고 런타임시에 실제 사용할 구체적인 의존 오브젝트를 제 3자(DI 컨테이너)의 도움을 받아서 주입

스프링?

스프링이란 오브젝트가 어떻게 설계되고 만들어지고 관계를 맺고 사용되는지에 관심을 갖는 프레임워크. 스프링의 관심은 오브젝트와 그 관계일 뿐 오브젝트의 설계와 분리, 개선은 개발자의 역할이다. 스프링은 원칙은 잘 따르는 설계를 적용하려고 할 때 번거로운 작업을 도와주는 도구일 뿐 그외는 개발자의 책임이다. 결론은 잘 디자인된 프로젝트를 만들어지려면 스프링에게만 의존하는 것이 아닌 개발자의 노력이 필요하다.

[토비의 스프링] 토비의 스프링 3.1 시작하기

Mon, 29 Aug 2022 00:00:00 +0900

게시글에는 책의 설명과 무관한 내용이 섞여있습니다.

토비의 스프링 3.1 정독 시작하기

토비의 스프링 책을 구매한지 벌써 1년이 지났는데 현재까지 책을 다 읽지 못하고 있었다.
올해가 가기전에 정독을 하기 위해서 11월쯤 토비의 스프링 책 스터디를 진행하려던 찰나 아주 좋은 기회가 생겼다 😆

바로 책의 저자분이 직접 운영하시는 읽기모임에 참여할 수 있게된 것 .. ! 토비의 읽기모임에선 많은 개발자 분들과 소통하며 책을 읽을 수 있다. 위협적인 책의 두께 때문에 열심히 잘 참여할 수 있을까 겁이 났지만, 흔치않은 기회였기 때문에 놓치기 너무 아쉬웠고 여럿이 읽으면 책임감도 생겨서 끝까지 참여할 수 있을 것 같아 신청했다.

읽기모임이 운영되는 동안 같이 참여하는 개발자 분들에게 도움이 될 수 있도록 열심히 글을 정리할 것이다. 본격적으로 읽기전에 작가들이 제일 중요하게 생각한다는 서문부터 정리하고 시작

스프링이란 무엇인가?

스프링은 자바 엔터프라이즈 애플리케이션 개발에 사용되는 애플리케이션 프레임워크이다. 애플리케이션 프레임워크는 애플리케이션 개발을 빠르고 효율적으로 할 수 있도록 도와준다.

누군가 스프링이 무엇이냐고 물어보면 잘 디자인된 프레임워크라고 말할 것 같다. 객체지향 그리고 소프트웨어 설계에 관한 책을 읽어보면 모두 공통적으로 단순하게 작성하라고 한다. 이는 단순함이 결국 유지보수성과 재사용성을 증가시키기 때문이라고 생각한다. 스프링은 간단한 방법으로 IoC/DI, PSA, AOP를 지원한다.

이 세가지 프로그래밍 모델들이 결합을 느슨하게 만들고 애플리케이션을 유연하게 만들기 때문에 잘 디자인 되었다고 생각한다.

애플리케이션의 기본 틀 - 스프링 컨테이너

스프링은 스프링 컨테이너 또는 애플리케이션 컨텍스트라고 불리는 스프링 런타임 엔진을 제공한다. 스프링 컨테이너는 설정정보를 참고하여 애플리케이션을 구성하는 오브젝트를 생성하고 관리한다.

업무 중에 애플리케이션 계층 구조에 대한 이해가 없어서 고생한 적이 있었다. 특정 Redis 채널에 대한 Listener 를 분명 하나만 생성하였는데 구독자 수가 1이 아닌 2로 조회되는 문제였다. 알고보면 단순한 이유였는데 Spring 에 대해 무지하여 원인 파악이 매우 느렸다.

원인은 이미 Root Context 가 공통으로 사용될 설정정보를 읽어서 Listener를 Bean으로 등록하였는데 dispatcher-servlet 에서 해당 설정파일을 import 하고있던 것이었다.

당시에는 정말 몰랐다.. 저 문제를 겪고나서 기초를 모르고 개발하면 한계에 도달한다는 것을 깨달은 것 같다 🥺

공통 프로그래밍 모델 - IoC/DI, 서비스 추상화, AOP

스프링은 애플리케이션을 구성하는 오브젝트가 생성하고 동작하는 방식에 대한 것 뿐만 아니라, 애플리케이션 코드가 어떻게 작성되어야 하는지에 대한 기준도 제시해준다. 이러한 틀을 보통 프로그래밍 모델이라고 하는데, 스프링은 아래와 같은 세가지 핵심 프로그래밍 모델을 지원한다.

1. IoC/DI

IoC/DI는 스프링 프레임워크의 근간이다. 스프링 프레임워크에서 동작하는 코드는 IoC/DI 방식을 따라 작성되어야 스프링이 제공하는 가치를 누릴 수 있다.

IoC란 Inversion of Control 제어의 역전을 의미한다. 스프링 프레임워크 에서는 객체 생성, 의존 관계 설정, 객체의 생명주기를 개발자가 작성한 코드가 아닌 스프링 컨테이너가 담당한다. 스프링 컨테이너가 코드 대신 객체의 관계와 생명주기, 생성을 담당하기 때문에 제어의 역전이라고 한다.

DI란 Dependency Injection 의존성 주입을 의미한다. 개발자가 객체간의 의존성을 설정하거나 클래스에 명시하면 의존성을 IoC 컨테이너가 자동으로 연결해준다.

2. PSA(Portable Service Abstraction)

두번째로 제공하는 프로그래밍 모델은 서비스 추상화 모델이다. 스프링을 사용하면 환경이나 특정 기술에 종속되지 않고
이식성이 뛰어나며 유연한 애플리케이션을 만들 수 있다. 이를 가능하게 해주는 것이 바로 서비스 추상화이다.
서비스 추상화는 실제 구현부를 감추고 필요한 기능만을 제공하기 때문에 사용자는 실제 구현부를 모르더라도 해상 서비스를 이용할 수 있다.

당장 떠오르는 것은 @Transactional 인듯 ?! 그리고 스프링과 관련없는 내용 중에선 OS layer의 VFS가 떠올랐다.

3. AOP(Aspect Oriented Programming)

AOP는 횡단 관심사를 독립적으로 모듈화 하여 모듈성을 증가시키는 프로그래밍 패러다임이다.
스프링은 AOP를 간단하게 구현할 수 있는 강력한 라이브러리 등을 제공한다.

@Transactional도 Spring AOP 중 하나이다.

스프링의 성공요인

단순함

과거에서부터 개발자들은 소프트웨어를 더욱 단순하게 만들고 재사용 할 수 있도록 유연하게 설계하는 방법을 고민해온 것 같았다. 단순함을 추구하는 것에는 이유가 있다고 생각한다. EJB도 과거엔 많이 사용되었지만 복잡하고 불편하기 때문에 기억속으로 사라진 것처럼 말이다.

스프링 프레임워크는 EJB를 비판하며 탄생했다. 스프링은 EJB가 잃어버렸던 객체지향 언어의 장점을 다시 개발자들이 살릴 수 있도록 도와주는 도구이다. 스프링이 강력히 주장하는 것은 가장 단순한 객체지향적인 개발 모델인 POJO(Plain Old Java Object) 프로그래밍이다.

유연성

스프링은 유연성을 중요한 가치로 내세운다. 스프링은 뛰어난 유연성과 확장성으로 많은 서드파티 프레임워크의 지원을 받을 수 있다. 스프링은 프레임워크를 위한 프레임워크로 여러 프레임워크를 함께 사용하게 해주는 접착 프레임워크라고도 한다.

스프링의 개발 철학 중 하나는 항상 프레임워크 기반의 접근 방법을 사용하라이다. 스프링의 기능은 대부분 핵심 기술을 확장해서 발전시킨 결과물이다. 스프링은 개발자들이 스프링 프레임워크를 확장하여 사용하여도 버전 호환성 문제가 발생하지 않는 아주 유연한 프레임워크이다.

[Java Design Pattern] Spring을 활용한 Chain Of Responsibility

Sun, 21 Aug 2022 00:00:00 +0900

Chain Of Responsibility Pattern (책임 연쇄 패턴)

책임 연쇄 패턴은 Gof Pattern 중 행동패턴에 포함되며 요청을 하나이상의 체인으로 구성된 객체에게 전달하여 메세지를 보내는 대상과 처리하는 대상을 분리한다. 체인은 책임에 따라 여러 역할로 나누고 각 체인은 서로 연결되어있다. 요청은 동적으로 처리되며, 하나의 체인은 책임에 따라 요청을 처리하고 역할이 끝나면 다음 체인으로 요청을 전달한다.

Diagrams

Client

Client는 요구사항에 따라 동적으로 체인을 구성한다. 체인은 하나일 수도 있고 여러개로 구성될 수 있다.
이뿐만 아니라 발신자의 요청을 수신하여 체인에게 전달하는 역할도 담당한다.

Handler

모든 Concrete Handler에게 공통된 기능을 선언한 인터페이스
요청을 처리하기 위한 메서드와 다음 체인을 지정하는 메서드가 포함되어 있다.

Concrete Handlers

Handler에 선언된 메서드를 구현한 클래스 요청을 수신하면 처리 여부에 따라 요청을 전달할지 판단한다.
일반적으로 불변하며, 생성자를 통해 필요한 모든 데이터를 지정한다.

적용하면 좋은 경우
요청을 처리할 객체들이 "동적"으로 연결되어야 할 때
요청을 처리할 수신자가 명시적으로 지정되어있지 않을 때
요청의 발신자와 수신자를 분리하고 싶을 때
코드에서 명시적으로 핸들러지를 지정하기 싫을 때 

장점
분기문을 제거할 수 있음
객체에게 유연하게 책임을 할당할 수 있음
결합도 감소
    - 요청한 객체는 요청을 처리하는 객체를 직접적으로 참조하지 않음
    - 메시지를 보내는 대상과 받는 대상이 분리되어 결합도가 감소함  
체인 내에서 구성을 변경하거나 삭제하여 책임을 동적으로 관리할 수 있음 (유연성 향상)

단점
요청에 대한 신뢰성을 보장하지 않음 (체인에게 요청이 전달되지 않을 수 있음)
시스템 성능에 영향이 갈 수 있음 (등록된 모든 체인을 순회함)
코드를 확인하는 것이 쉽지않아 코드를 잘못 작성할 경우 체인 내에서 사이클이 발생할 수 있음
디버깅으로 동작을 확인하기 어려움

적용 예제

가정

지하철 요금은 개찰구를 통과했을 때 지불하는 기본요금과 거리마다 추가되는 추가 요금으로 구성된다.
개찰구를 통과할 지불하는 1250원과 10Km를 넘어가면 5Km 마다 100원씩 추가로 지불해야한다.
10Km~50Km 구간에선 5Km 마다 100원씩 추가요금이 부과되고 50Km를 넘으면 8Km 마다 추가 요금이 부과된다.

조건문을 적용해서 해결한 예시

소프트웨어 적으로 지하철 요금을 계산하려면 기본 요금과 거리마다 부과되는 추가요금을 고려해야한다.
가장 쉽게 구현할 수 있는 방법은 거리마다 분기문으로 처리하여 코드를 작성하는 것이다.

 void calculateBaseOnDistance() {
        if (distance < 11) {
            System.out.println("기본요금");
        } else if (distance < 51) {
            System.out.println("5Km 마다 추가요금이 발생합니다.");
        } else if (distance > 51 ) {
            System.out.println("8Km 마다 추가요금이 발생합니다.");
        }
    }

조건문을 사용하여도 충분히 해결할 수 있지만 만약 새로운 요금 정책이 추가된다면
정책마다 조건을 추가하여야 한다. 조건이 많아지면 코드의 가독성이 저하되고 유지보수가 힘들어진다.
또한 많은 조건은 해당 클래스가 SRP를 위반한다는 신호로 받아드릴 수 있다.

책임 연쇄 패턴 적용

이제 조건문을 책임 연쇄 패턴을 이용하여 제거하는 방법을 알아보자 예제코드는 편리한 의존주입과 테스트 환경을 위해
Spring boot 2.6.3, junit5 를 사용하였다.

Diagrams

Client - version.1 (요청 전달 책임과 Chain 연결 책임을 분리)

요청을 체인에게 전달

@Component
@RequiredArgsConstructor
public class FareChainCalculator {

    @Qualifier("basicFareCalculator")
    private final FareChain basicChain;

    public int operate(int distance) {
        return basicChain.calculateBaseOnDistance(distance);
    }

}

체인의 연결 정보를 관리

@Configuration
public class FareChainConfig {

    @Bean
    public FareChain basicFareCalculator() {
        return new BasicFareCalculator(mediumDistancePassengerFareCalculator());
    }

    @Bean
    public FareChain mediumDistancePassengerFareCalculator() {
        return new MediumDistancePassengerFareCalculator(longDistancePassengerFareCalculator());
    }

    @Bean
    public FareChain longDistancePassengerFareCalculator() {
        return new LongDistancePassengerFareCalculator(null);
    }
}

version.1은 생성자 주입을 사용하여 체인을 연결한다.

Client - version.2 (분리되지 않은 경우)

public class FareChainCalculator {

    private final Map<String, FareChain> fareChainMap;

    public int operate(int distance) {
        setChain();
        FareChain basicChain = getBasicChain();
        return basicChain.calculateBaseOnDistance(distance);
    }

    private void setChain() {
        FareChain basicFareChain = getBasicChain();
        FareChain mediumDistancePassengerChain = getMediumDistanceFareChain();
        FareChain longDistancePassengerChain = getLongDistanceFareChain();

        basicFareChain.setNext(mediumDistancePassengerChain);
        mediumDistancePassengerChain.setNext(longDistancePassengerChain);
    }

    private FareChain getLongDistanceFareChain() {
        return fareChainMap.get(FareChainType.LONG_DISTANCE_PASSENGER_CHAIN.implementation());
    }

    private FareChain getMediumDistanceFareChain() {
        return fareChainMap.get(FareChainType.MEDIUM_DISTANCE_PASSENGER_CHAIN.implementation());
    }

    private FareChain getBasicChain() {
        return fareChainMap.get(FareChainType.BASIC_CHAIN.implementation());
    }
}

version.2은 Client가 요청 전달의 역할과 체인 연결 역할을 모두 수행한다. 해당 방법을 사용하려면
Concrete Handlers가 FareChain의 setNext(FareChain chain) 메서드를 구현해야 한다.

Handler

예제의 클라이언트가 분리되지 않은 경우에서는 setNext 메서드도 정의해야 한다.

public interface FareChain {

    int calculateBaseOnDistance(int distance);

    boolean canSupport(int distance);
}

Concrete Handlers

Concrete Handler.1

@AllArgsConstructor
public class BasicFareCalculator implements FareChain {
    private static final int MAX_DISTANCE = 10;
    private static final int BASE_FARE = 1250;

    private FareChain nextChain;

    @Override
    public int calculateBaseOnDistance(int distance) {
        if(!canSupport(distance)) {
            return BASE_FARE + /* 다음 체인 호출 */;
        }

        return BASE_FARE;
    }

    @Override
    public boolean canSupport(int distance) {
        return /* 요청 처리가 가능한지 판단 */;
    }
}

Concrete Handler.2

@AllArgsConstructor
public class MediumDistancePassengerFareCalculator implements FareChain {
private static final int MAX_DISTANCE = 50;

    private FareChain nextChain;

    @Override
    public int calculateBaseOnDistance(int distance) {
        if (!canSupport(distance)) {
           return operate(distance) + /* 다음 체인 호출 */;
        }
        return operate(distance);
    }

    @Override
    public boolean canSupport(int distance) {
        return /* 요청 처리가 가능한지 판단 */;
    }

    private int operate(int distance) {
        return /* 계산식 */;
    }
}

Concrete Handler.3

@AllArgsConstructor
public class LongDistancePassengerFareCalculator implements FareChain {

    private final FareChain fareChain;

    @Override
    public int calculateBaseOnDistance(int distance) {
        return /* 계산식 */;
    }

    @Override
    public boolean canSupport(int distance) {
        return /* 요청 처리가 가능한지 판단 */;
    }
}

결과 확인

이번 예제에서 구현한 책임 연쇄 패턴은 모든 체인을 순회하지 않고, 요청을 전달받은 체인이 요청을 처리할 수 없을 때 해당 체인의 역할을 수행하고 다음 체인에게 요청을 전달하는 방식으로 구현하였다.

    /*
     * 거리가 10일 경우 기본요금 1250
     * 거리가 11일 경우 1350 (5km 마다 100원씩 추가요금 부여)
     * 거리가 51일 경우 2150 (8km 마다 100원씩 추가요금 부여)
     */
    @ParameterizedTest
    @CsvSource(value = {"10:1250", "11:1350", "51:2150"}, delimiter = ':')
    void calculate(String distance, String fare) {
        int extractFare = fareChainCalculator.operate(Integer.parseInt(distance));

        assertThat(extractFare).isEqualTo(Integer.parseInt(fare));
    }

해당 테스트를 실행하면 정상적으로 동작하는 것을 확인할 수 있다.

Reference

Chain Of Responsibility Pattern

[Java] Hotspot JVM 맛보기

Thu, 07 Jul 2022 00:00:00 +0900

이번 포스팅은 JVM에 대해 간단하게 정리한 포스팅 입니다.
각 모듈에 대한 자세한 정보는 다음 포스팅에서 다루겠습니다 !

Hotspot JVM

Hotspot JVM은 JVM 구현의 일종이으로 높은 확장성과 성능을 제공한다. 자바 1.3 버전부터 기본 VM으로 사용되어 왔기 때문에 현재 운영되는 대부분의 자바 애플리케이션은 Hotspot 기반의 VM 이라고 볼 수 있다. Hotspot VM에는 런타임시 동적으로 최적화를 수행하는 JIT가 포함되어 있다. JIT 뿐만 아니라 다음과 같은 다양한 기능을 제공한다.

- GC를 이용하여 자바의 Heap 메모리를 효율적으로 관리
- 프로파일링, 모니터링 및 디버깅 도구
- 병렬 컴파일을 지원하는 컴파일러 인터페이스
- 네이티브 스레드 기반의 선점형 멀티스레딩
- 초고속 스레드 동기화
- VM 런타임

Hotspot JVM 구조

Hotspot JVM는 크게 Class Loader, Runtime Data Area, Execution Engine으로 구성되어 있다.
여기서 세부 항목인 Heap, JIT Compiler, Garbage Collection은 성능과 관련된 JVM의 주요 구성요소이다.

ClassLoader

클래스로더는 JRE의 핵심 구성요소로 런타임 동안 자바 클래스를 로딩, 링크, 초기화 절차를 거쳐 JVM에 동적으로 로드하는 역할을 한다. 일반적으로 클래스들은 한번에 모두 로딩되지 않고 애플리케이션이 필요로 할 때 로딩한다. 또한 클래스로더는 다음과 같은 세 가지 원칙을 따른다.

1. Delegation

클래스 로딩 요청을 상위 클래스 로더에게 전달하는 것. 상위 클래스에서 클래스를 찾거나 로드하지 않는 경우에만 하위 클래스 로더가 클래스를 로드한다.

2. Visibility

하위 클래스 로더는 상위 클래스 로더가 로드한 모든 클래스를 볼 수 있다. 그러나 부모 클래스로더는 자식 클래스 로더가 로드한 클래스를 볼 수 없다.

3. Uniqueness

클래스는 한번만 로드할 수 있다. 상위 클래스에서 이미 로드한 클래스를 하위 클래스로더가 다시 로드할 수 없다.

Runtime Data Area

Runtime Data Area는 JVM이 실행 중에 사용되는 다양한 데이터 영역을 정의한다. 데아터 영역 중 일부는 JVM 시작시 생성되고 JVM이 종료될 때만 소멸된다. Runtime Data Area는 스레드가 공유하는 영역과 공유하지 않는 영역으로 나눌 수 있다.

1. 스레드 공유 데이터 영역

Heap and Direct Memory, Method Area
해당 영역은 JVM 시작 시 생성되고 모든 스레드에서 공유한다.
GC는 Heap 영역에서만 발생한다.

2. 스레드가 공유하지 않는 데이터 영역

PC Register, JVM Stack, Native Method Stack
해당 영역은 스레드가 생성될 때 생성되고 해당 스레드에서만 사용된다.
여러 스레드가 실행 중인 경우 이러한 데이터 영역의 여러 복사본이 생성된다.

Execution Engine

실행엔진(Execution Engine)은 로딩된 클래스의 메서드들에 포함된 모든 인스트럭션 정보를 실행한다. 이때 바이트코드로 작성되어 있는 인스트럭션 정보를 OS가 읽을 수 있는 형태(기계어)로 변환해야 하는데, 실행엔진은 바이트코드를 한 줄마다 읽으며 변환하는 작업을 거친다. 실행엔진은 Java 코드 실행 뿐만 아니라 최적화, 메모리관리 또한 담당한다.

Java가 OS에 독립적일 수 있는 이유는 이처럼 런타임 시에 바이트코드를 기계어로 변경하기 때문이다. 실행 엔진은 앞서 소개한 최적화, 메모리 관리, 실행 등을 담당하는 세 가지 구성 요소가 포함되어 있다.

1. 인터프리터

바이트 코드를 읽고 기계어로 변환하여 순차적으로 실행한다. 인터프린터가 매번 동일한 바이트코드를 여러번 변환하는 것은 성능을 저하시키는 원인 중 하나이기 때문에 이러한 문제를 해결하기 위해 JIT 컴파일러가 도입되었다.

2. JIT(Just In Time)

인터프린터의 단점을 보완하기 위해 도입된 컴파일러이다. JIT 컴파일러의 주요 목적은 성능을 향상시키는 것이다. 모든 코드는 첫 실행시 인터프리터에 의해서 시작되고, 해당 코드가 자주 호출되면 컴파일할 대상이 된다. 해당 메서드가 정상적으로 해석되면 JIT 컴파일러가 수행 카운터를 증가시킨다. JIT 컴파일러는 수행 카운터와 백에지 카운터 값으로 컴파일할 대상을 정하기 떄문에 수행 카운터가 높거나 백에지 카운터가 높은 메서드를 우선적으로 네이티브 메서드로 변환한다. JIT 컴파일러에 의해 변환된 메서드는 다시 호출될 때 변환 과정을 거치치않고 바로 실행되기 때문에 성능이 향상된다.

간단하게 설명하면 자주 호출되는 메서드(Hotspot)를 우선적으로 컴파일한다.

3. GC(Garbage Collection)

GC(Garbage Collection)는 메모리(heap)를 관리하는 자바 프로그램이다. 런타임에 참조되지 않는 객체의 메모리를 회수하기 때문에 자바 메모리를 효율적으로 관리할 수 있다. 메모리를 GC가 관리하기 때문에 개발자는 메모리를 할당하거나 해제하는 로직을 작성할 필요가 없다. 추가로 GC는 항상 백그라운드에서 실행된다.

Reference

Hotspot

https://www.tuning-java.com/195
https://velog.io/@aki/HotSpot-JVM
https://www.oracle.com/java/technologies/whitepaper.html
https://velog.io/@roo333/Java-Garbage-Collection-Basics
자바 성능 튜닝 이야기 :: story.16 JVM은 어떻게 구동될까?

ClassLoader

Runtime Data Area

Execution Engine

[Java] synchronized

Sun, 26 Jun 2022 00:00:00 +0900

Java synchronized

Java의 synchronized는 Thread간의 동기화 매커니즘이다. synchronized는 하나의 객체를 여러 스레드에서 동시에 사용하거나 static으로 선언한 객체를 여러 스레드에서 사용할 경우에 적용한다. 주의할 점은 synchronized는 객체 단위로 동작하기 때문에 한 객체에서 synchronized를 사용하는 여러개의 메서드가 있다면 해당 키워드가 적용된 메서드는 동시에 실행되지 않는다. 또한 내부에서 동기화를 위해 Monitor를 사용하고 있으므로 성능저하 문제가 발생할 수 있다.

Monitor

모니터란 동시에 수행중인 프로세스나 스레드 사이에서 동기화를 적용하기 위한 high-level synchronization construct 이다. 모니터는 하나의 lock과 여러개의 condition variable로 이루어져있다. 모니터 내에서는 한번에 하나의 프로세스나 스레드만이 활동이 가능하므로 프로세스나 스레드가 모니터를 사용하다가 봉쇄상태로 변경되어도 다른 프로세스가 모니터에 접근하지 못한다.

Java Monitor

📌 모니터는 synchronized를 사용했을 때 이용된다.

Java의 모든 객체는 Monitor를 보유하고 있다. 객체는 heap 영역에 존재하므로 모든 스레드에서 공유가 가능하기 때문에 Monitor는 객체에 한번에 하나의 스레드만 접근할 수 있도록 막는다. 그리고 객체는 모니터가 할당되지 않은 상태이면 호출된 스레드에게 모니터를 할당한다. 소유권을 갖게된 스레드는 모니터에 진입하게 된다. 모니터에 하나의 스레드가 진입하게 되면 다른 스레드는 모니터를 사용할 수 있을 때까지 대기하게 된다. 즉 오직 모니터를 소유한 스레드만이 임계구역에서 작업을 할 수 있는 것이다.

1. 공유객체에 접근할 때 synchronized를 사용하지 않았을 경우

기부금을 처리하는 단체

public class Contribution {
    private int amount;
    public void donate() {
        this.amount++;
    }
    public int getTotal() {
        return amount;
    }
}

단순하게 기부금 필드와 기부금을 축적하는 메서드만 보유하고 있는 클래스이다.

기부자

public class Contributor extends Thread {
    private Contribution contribution;
    private String name;

    public Contributor(Contribution contribution, String name) {
        this.contribution = contribution;
        this.name = name;
    }

    public void run() {
        for(int loop=0; loop<1000; loop++) {
            contribution.donate();
        }
        System.out.format("%s total=%d\n", this.name, contribution.getTotal());
    }
}

1인당 1원씩 1000번 기부하고 기부가 완료되면 쌓인 기부금을 출력하는 클래스이다.

실행 소스코드

public class App {

    public static void main(String[] args) {
        Contributor[] contributors = new Contributor[10];
        Contribution contribution = new Contribution();

        for(int loop=0; loop < 10; loop++) {
            contributors[loop] = new Contributor(contribution, "Contributor"+loop);
        }

        for(int loop=0; loop < 10; loop++) {
            contributors[loop].start();
        }
    }
}

하나의 단체에 10명의 기부자가 1000원씩 기부하는 App 클래스이다.
소스코드로 예상할 수 있는 결과의 최대값은 10,000 일 것이다. 결과를 확인해보자.

결과

결과는 우리가 예상한 값과 다르다. 물론 여러번 실행하면 10,000 이라는 값이 출력되기도 한다. 그렇지만 대부분 10,000이라는 값은 출력되지 않을 것이다. 이러한 문제가 발생하는 이유는 여러개의 contributors 객체에서 하나의 contribution 객체의 donate() 메서드에 접근하기 때문이다. 앞서 말했듯이 객체는 heap 영역에 생성되므로 모든 스레드가 접근할 수 있다. 모든 스레드가 동시에 공유영역에 접근할 수 있다는 것은 스레드 동기화 문제가 발생할 수 있다는 것과 같다.

2. 문제 해결 방법

synchronized

위와 같은 경우 문제 해결방법은 간단하다. donate() 메서드에 synchronized 를 사용하면 된다.

     public synchronized void donate() {
        this.amount++;
    }

결과

synchronized 메서드를 추가하면 donamte() 메서드에 하나의 스레드만이 접근할 수 있게되므로 여러번 실행하여도 최대값은 10,000이 출력될 것이다. 하지만 이 예시는 간단한 예시이기 때문에 동기화가 필요한 메서드에 무조건 synchronized를 사용하는 방법은 옳지 않다. 메서드 내부에서 동기화가 필요하지 않은 라인도 동기화가 적용되어 성능에 큰 영향을 끼칠 수 있기 때문이다. 이번 게시물에서 소개하진 않았지만 인스턴스 메서드안에 동기화 블록을 적용하는 방법도 존재한다.

결론

synchronized를 사용해야할 경우는 존재할 수 있다. 그렇지만 synchronized의 동작 방식을 모르는 상태로 사용하게 되면
큰 성능이슈를 겪을 수 있다. 뿐만 아니라 클래스 변수는 인스턴스 메서드의 synchronized가 적용되지 않기 때문에 주의해서 사용해야 한다.

Reference

Monitor

Java Monitor

Java synchronized

자바 성능 튜닝 이야기 :: story.8 synchronized는 제대로 알고 써야한다.

[Java] Java Beans Pattern 멀리할래요

Sun, 12 Jun 2022 00:00:00 +0900

들어가며

이전에 무지성으로 남발하여 주로 사용하였던 Getter Setter가 객체지향 세계에선 아주 지양해야할 패턴이라는 것을 알게 되었다. Getter Setter가 존재하는 이상 그 클래스는 능도적인 객체가 아닌 자료구조에 불과하다고 한다. 그런데 가끔 특정한 라이브러리에서 Getter Setter 를 필요로 하는 것을 느꼈다. 물론 옵션을 설정할 수 있지만 주의해야 하는 것은 마찬가지이다. 그래서 이번에는 Java Beans Pattern에서 벗어나고 싶은데, 완전히 자유로워지기 힘든 이유를 정리하고자 한다.

Java Beans Pattern 지양해야 하는 이유

자바 개발자라면 객제지향 프로그래밍의 4대 원칙을 한번쯤 들어봤을 것이다. 간단하게 소개하자면 아래와 같다.

OOP 4대 원칙

1. 추상화(Abstraction)

구체적인 것을 분해 하여 재조립 하는 것

2. 상속(Inheritance)

상위 클래스의 특성을 하위 클래스가 물려받는 것

3. 캡슐화, 정보은닉 (Encapsulation)

역할에 관련있는 객체의 속성과 실제 행위를 묶어 실제 구현 내용을 외부에 노출하지 않는 것

4. 다형성(Polymorphism)

같은 형태를 가지고 있지만 다른 행위를 할 수 있음

1. 캡슐화 위배

Getter와 Setter의 경우 캡슐화를 위반한다. 객체가 무엇을 캡슐화 하고 있는지와 객체 내부의 복잡성은 오직 객체만이 알고 있어야 한다. 그런데 Getter와 Setter는 외부에 객체의 데이터를 노출하게 만든다. 물론 필드에 직접 접근하는 것이 아닌 메서드를 이용하여 접근하는 것이지만 우리는 Getter가 데이터에 직접 접근하여 해당 필드의 데이터만을 반환할 것이라고 믿고있다.

객체지향 세계에선 객체에게 특정한 행위를 요청했을 때, 외부에서는 객체가 어떠한 재료들로 무엇을 만드는지 알아선 안되고 알 필요도 없다.

2. 객체를 자료구조로 전락시킨다

객체지향 세계에서의 객체는 살아있고 능동적이다. 그런데 Getter/Setter가 남발된 객체는 생명이 없다. 그저 데이터를 외부에 노출하는 단순 자료구조일 뿐이다.

//안 좋은 예시
class Cash {
  private int value; 

  public  int getDollars() {
    return this.value();
  }
}

// 좋은 예시
class Cash {
  private final int value;

  public int dollars() {
    return this.value;
  }
}

차이는 메서드 이름밖에 없다고 생각할 수 있다. 그렇지만 메서드 이름에서 가져오는 뉘앙스는 완전히 다르다.
앞에서 설명했듯 객체는 살아있고 능동적이다. 그런데 getDollars()는 객체에게 달러를 찾아 반환하라고 명령 한다.
반면 dollars()의 경우 객체에게 얼마나 많은 달러가 필요한지 묻는다. 객체를 생명체로서 존중하고 있는 것이다.
또한 dollars()는 객체가 요청을 듣고 반환할 때 외부에선 객체가 어떠한 재료와 행위로 값을 반환하는지 유추하기 힘들다.

3. 불변객체가 될 수 없다

Setter 를 사용하면 누구나 객체의 값을 쉽게 수정할 수 있다. 이는 곧 불변객체가 될 수 없다는 의미와 같다. 불변객체는 생성과 동시에 값을 초기화 하므로 개발자가 이후에 객체의 상태값을 변경할 수 없다. 값이 변하지 않으면 식별자 가변성 문제와 부수효과 시간적 결합 문제에서 자유롭다. 뿐만 아니라 불변객체는 실패 원자성 의 장점이 있다. 그런데 Setter를 사용하게 되면 이러한 장점을 전부 누리기 어려워진다.

객체의 값을 쉽게 수정할 수 있게 된다면 개발자의 실수로 의도하지 않았던 결과를 초래할 수 있다. 문제를 해결하기 위해 실수로 발생한 부수효과(side effect)를 제거하려면 값을 수정하는 코드를 전부 찾아서 디버깅 해야하기 때문에 많은 시간이 소요된다.

Getter, Setter가 없을 때 발생하는 이슈

앞에서 설명한 내용들을 보면 java beans pattern 은 정말 안티패턴 처럼 느껴진다. 나만 그럴수도,,? 여튼 그래서 실제로 업무를 진행하면서 Setter 뿐만 아니라 Getter도 생성하지 않고 개발했던 적이 있었다. 자주 사용하던 방법이 아니여서 익숙하진 않았지만 크게 불편함은 없었다. 그런데 .. 예상하지도 못했던 부분에서 문제가 발생하였다. ObjectMapper로 Json을 역직렬화 할 때 멤버변수를 찾지 못하여 실패하는 이슈가 발생한 것이었다.

1. ObjectMapper

ObjectMapper에서 JSON을 자바 객체로 역직렬화 할 때 getter, setter 메서드 이름의 “get”과 “set”을 제거하여 객체의 멤버변수를 찾는다. getter, setter 없이 다른 방법으로도 필드명을 알아낼 수 있지만 따로 옵션을 설정하거나 어노테이션을 지정해줘야 한다.

📌 @JsonProperty

{
  "dollars" : 100
}

class Cash {

  @JsonProperty("dollars")
  private Integer dollars;

}

📌 ObjectMapper 설정 변경

ObjectMapper objectMapper = new ObjectMapper();
objectMapper.setVisibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY);

Reference

[네트워크 스터디] Chapter_04 엑세스 회선을 통해 인터넷의 내부로 !

Wed, 08 Jun 2022 00:00:00 +0900

ADSL 기술을 이용한 엑세스 회선의 구조와 동작

✔️ 인터넷의 기본은 가정이나 회사의 LAN과 같다

인터넷은 거대하고 복잡한 시스템이지만 패킷을 중재하는 부분은 가정, 회사의 LAN과 동일하다.
라우터의 기본적인 구조나 동작도 전혀 다르지 않다
가정이나 회사의 네트워크 규모가 커진 것이 인터넷

✔️ 가정, 회사의 네트워크와 인터넷의 차이점

인터넷은 중계 장치의 거리가 매우 멀다.
대한민국과 미국을 연결하려면 태평양을 넘어야하기 때문에 이더넷 케이블로 연결은 어렵다.
라우터의 등록정보가 수시로 바뀌기 때문에 경로 등록을 자동화 해야한다.
- 통신 장애가 발생하거나 인터넷에 새로 접속하는 회사가 있을 때마다 변경하는 것은 무리가 있음
요약하자면 거리의 차이와 경로 정보의 등록 방법 차이가 인터넷과 회사, 가정 LAN과의 차이

✔️ 사용자 인터넷을 연결하는 액세스 회선

인터넷 접속용 라우터는 액세스 회선의 규칙에 따라 패킷 송신 동작을 실행한다. (이더넷의 규칙과 다른 부분)
일반 가정에선 ADSL, FTTH, CATV, ISDN 등을 액세스 회선으로 사용한다.

💡 액세스 회선은 인터넷과 가정, 회사의 LAN을 연결하는 통신회선이다. 
💡 액세스 회선은 통신 회선의 사용법을 나타내므로 통신 회선의 원리나 구조를 나타내는 것이 아니다. 

✔️ADSL 모델에서의 패킷 신호화 과정

[ADSL 기술을 사용한 액세스 회선의 구성도]

위 그림의 오른쪽에서 왼쪽으로 패킷이 흘러간다. 즉 사용자의 라우터에서 송신된 패킷은 ADSL 모뎀이나 전화의 케이블을 통해 전화국에 도착하며 도착한 패킷은 ADSL 사업자의 네트워크를 경유하여 프로바이더 (ISP: Internet Service Provider)에 도착하는데, 이때 패킷은 도착하는 동안 여러 형태로 모습을 바꾼다.

💡 ADLS(Asymmetric Digital Subscriber)모델이란 전주에 부설된 전화용 금속제 케이블을 이용하여
  고속으로 통신하는 기술의 일종으로 사용자로부터 인터넷으로 향하는 상향(업로드)과 인터넷에서 사용자로 향하는 
  하향(다운로드)의 통신 속도가 서로 다른 것을 가리킵니다.

[액세서 회선을 통한 패킷의 전송 과정]

(1~4) 위 그림의 4번까지는 이더넷의 라우터와 큰 차이가 없음
(5) 인터넷 접속용 라우터와 **ADSL** 모뎀이 이더넷으로 연결되어 있으면 이더넷의 규칙에 따라 패킷을 송수신
(5) 이더넷의 헤더가 액세스 회선 사업자에따라 변형된다.
(5) MAC헤더 PPoE헤더 PPP헤더라는 3개의 헤더가 추가로 붙고 이더넷의 규칙따라 신호를 변환하여 송신한다
(6) 인터넷 접속용 라우터가 송신한 패킷을 ADSL 모뎀이 받아서 작게 분할하여 **셀**에 저장한다.
(7) 분할된 셀은 ATM 이라는 통신 기술에 사용된다.
(8) 셀에 저장된 패킷을 신호로 변환한다. 변환할 때는 직교 진폭 변조(QAM)라는 방식을 사용한다.
(9) 전화 케이블을 통해 전화국에 도착한 신호가 배선반과 스플리터를 통과하여 **DSLAM** 에 도착한다.
(10) DSLAM이 신호의 파형을 읽어 진폭과 위상을 조사하고 이것이 어느 비트에 대응하는지 판단하여 디지털 신호로 복원하여 전송한다.
(11) ATM 인터페이스가 셸을 수신한다.
(12) ATM 인터페이스가 셸을 원래의 패킷 형태로 되돌린다. (ATM 인터페이스를 셸을 원래 패킷으로 되돌리는 기능이 있음)
(13) BAS에 건내주기 위한 용도로 사용된 MAC 헤더와 PPoE헤더를 제거하고 PPP 헤더 이후 부분을 추출한다.
(14) 터널링에 필요한 헤더를 붙여서 출구를 향해 중계한다.
(15) 패킷이 터널링 출구에 있는 터널링용 라우터에 도착한다.
(16) 터널링용 헤더를 분리하고 IP 헤더 이후 부분의 패킷을 추출한다.
(17) 인터넷 내부에 중계한다.

💡 ADSL 모뎀은 패킷을 셀로 분할하고 전기 신호로 바꾸어 스플리터에 송신한다.
💡 셀은 맨 앞부분에 5바이트의 헤더와 48바이트의 데이터가 이어지는 작은 디지털 데이터의 덩어리이다.
💡 DSLAM이란 다수의 ADSL 모뎀의 기능을 여러개로 묶어서 하나의 케이스에 넣은 것
💡 DSLAM은 ATM 인터페이스를 가지고 있고 패킷을 분할한 셸 형태 그대로 후방의 라우터와 주고받는다. 
💡 BAS는 ATM 셸을 패킷으로 복원하여 인터넷 내부에 중계한다.

액세스 회선으로 이용하는 PPP와 터널링

내용을 설명하기전 다시한번 짚어보자면, ADSL이나 FTTH 등의 액세스 회선에서 인터넷을 향해 흘러온 패킷은 액세스 회선을 소유한 사업자가 운영하는 BAS에 도착한다.

인터넷은 다수의 라우터를 함께 연결하여 만든 것으로 액세스 회선을 라우터에 연결하는 것이 원칙이다. 그리고 액세스 회선이 ADSL이나 FTTH로 진화한 것으로 이것에 맞게 액세스 회선을 연결하는 라우터도 진화했다. 진화한 라우터를 BAS 라고 한다. 아래 내용은 무엇이 진화했는 지 설명하는 내용이다.

✔️인터넷에 엑세스 하기 위한 액세스 회선의 준비동작

ADSL이나 FTTH의 액세스 회선은 최초에 사용자명과 패스워드를 입력하여 로그인을 해야함. 그러나 BAS를 케이블로 고정적으로 접속하므로 PPP처럼 본인인지 확인할 필요가 없어진다.
ADSL이나 FTTH는 PC에 글로벌 주소를 설정하지 않으면 인터넷에 접속할 수 없다.

✔️BAS의 기능

BAS가 ADSL, FTTH 로그인 동작의 창구가 됨 (본인확인)
터널링이라는 개념을 사용하여 패킷을 운반하는 기능
TCP/IP의 설정 정보를 통지 (PPP와 동일)

터널링은 소켓과 소켓사이를 연결하는 TCP의 커넥션과 비슷하다. TCP 커넥션의 한쪽 출입구(소켓)에서
데이터를 넣으면 데이터가 그대로의 모습으로 반대쪽 출입구에 도착하는데 터널링은 이것과 같다. 

✔️터널링 기능에 의해 프로바이더에 패킷을 전달한다

사용자와 가장 가까운 전화국의 BAS와 프로바이더 라우터 사이에 있는 ADSL/FTTH 접속 서비스 사업자의 네트워크 안에 터널을 만든다. (액세스 회선이 프로바이더의 라우터까지 연결된다는 것)
터널링 실현 방식에는 TCP의 커넥션을 이용한 터널링과 캡슐화 방식의 터널링이 존재한다.
패킷을 그대로의 모습으로 운반할 수 있는 구조라면 원리적으로는 어떤 것에도 터널링을 이용할 수 있다.

프로바이더의 내부

액세스 회선을 통과한 패킷은 프로바이더의 라우터에 도착한다. 프로바이더의 라우터는 인터넷이 입구이며 여기에서부터 패킷은 인터넷의 내부로 들어간다. 인터넷의 실체는 단일 네트워크가 아닌 다수의 프로바이더의 네트워크를 서로 접속한 것이다. 프로바이더의 내부에는 POP 라우터와 NOC 라우터가 존재한다.

프로바이더를 경유하여 흐르는 패킷

✔️ BGP

프로바이더 간에는 서로 경로 정보를 교환하여 라우터에 자동 등록한다. 예를 들면 프로바이더 A가 102.47.0.0 의 경로를 알고있으면 접속 상대 (프로바이더 B)에게 102.47.0.0로 가려면 여기로 경유하세요 라고 알리는 것이다. 프로바이더 B는 A에게 받은 정보를 경로표에 등록하고 목적지가 102.47.0.0 일 때 프로바이더 A에게 패킷을 전송한다. 이러한 구조를 BGP라고 한다.

✔️ 트랜지트(transit, peer)

경로 정보 교환은 통지하는 경로 정보의 내용에 따라 두 가지 유형으로 나눌 수 있다. 하나는 인터넷의 경로를 전부 상대에게 통지하는 것이다.

위 그림으로 예를 들자면, 프로바이더 E와 연결되어 있는 프로바이더 D가 프로바이더 E에 대한 경로를 프로바이더 B, C에게 전부 통지하는 것이다. 그러면 프로바이더 B,C도 연결되어 있는 다른 프로바이더에게 프로바이더 E의 경로를 통지하게 된다. 그 결과 프로바이더 D를 통과하여 인터넷의 모든 프로바이더에게 패킷을 보낼 수 있게되는데, 이것을 트랜지트(transit)라고 한다.

✔️비트랜지트(= peer)

트랜지트와 또 다른 개념으로 비트랜지트 또는 피어라는 개념도 존재한다. 이것은 트랜지트와는 다르게 자신에게 직접 접속되어 있는 네트워크에 대한 경로만 상대에게 통지하는 것이다. 그러면 상대는 자신에게 직접 접속한 네트워크로 갈 패킷만 보내게 된다.

💡 이더넷의 내부에는 BGP라는 구조를 사용하여 프로바이더간에 경로 정보를 교환한다. 
💡 BGP의 구조에서는 정보를 교환하는 상대를 'peer'라고 한다. 'peer'는 비트랜지터와 트랜지터를 모두 포함한다.

✔️ IX(Internet exchange)

프로바이더끼리 접속하는 방법은 위 그림처럼 프로바이더 D와 프로바이더 C와 같이 1 대 1 형태로 접속하는 것이 기본이다. 지금도 이 방법을 사용 중이지만 이 방법만으로는 불편하다. 프로바이더끼리 1대1로 접속하는 방법밖에 없으면 모든 프로바이더가 서로 연결되어 있어야 한다. 현재는 국내에만 해도 여러 회사가 있으므로 이것은 보통일이 아니다. 이러한 상황에서 중심이 되는 설비를 설치하고 이것을 경유하여 접속하는 방법을 선택하면 통신 회선의 수를 억제할 수 있다. 이 경우 중심 설비를 IX라고 한다.

Reference

성공과 실패를 결정하는 1%의 네트워크

[네트워크 스터디] Chapter_03 케이블의 앞은 LAN 기기였다.

Sun, 29 May 2022 00:00:00 +0900

📗 Chapter_03 케이블의 앞은 LAN 기기였다. _허브와 스위치, 라우터의 탐험

🌟 3장의 요점 짚고 넘어가기 🌟

해당 챕터는 클라이언트 PC가 가정이나 회사의 LAN에 접속되고, 앞부분이 ADSL이나 광섬유(FTTH)등의 광대역 회선에 의해 인터넷에 접속된다는 최신의 대표적인 상황을 가정하여 설명한다.

이 경우 LAN 어댑터가 송신한 패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에 도착한다. 라우터의 앞부분은 이미 인터넷이므로여기에서부터 앞부분은 통신사가 패킷을 상대에게 운반한다. 우체통에 봉투를 넣으면 그 후에는 집배원이 편지를 상대에게 전달하는 것과 유사하다.

1. 케이블과 리피터 허브속을 신호가 흘러간다.

하나하나의 패킷이 독립된 것으로 동작한다.

컴퓨터에서 송신된 패킷은 허브나 라우터라는 중계 장치에 의해 중계되어 목적지에게 운반된다. 이때 중계장치는 패킷의 데이터 정보를 확인하지 않는다. 이는 애플리케이션의 데이터나 TCP 프로토콜의 제어정보는 패킷 운반 동작에 아무런 영향을 주지 못하는 것이다. 즉 HTTP 메세지나 TCP 수신확인 서버와 클라이언트의 관계 같은 것들은 모두 무시된다고 보면 된다. 따라서 모든 패킷은 독립적인 패킷으로 판단되어 목적지에 운반된다.

LAN 케이블은 신호를 약화시키지 않는 것이 핵심이다

LAN 어댑터가 흘려보낸 전기신호가 케이블을 통해 허브에 도착될 때 송출한 신호 그대로 허브에 도착하지 않는다. 케이블을 통과하는 사이에 신호의 에너지가 조금씩 떨어지므로 케이블의 길이가 길어질수록 신호가 약해진다.

신호가 약해지는 것 뿐만 아니라 이더넷의 경우 사각형의 각진 신호가 뭉개져서 둥글게 변한다. 신호의 각진 부분은 주파수가 높을수록 전압이 급격하게 변화하게 된다. 이처럼 급격하게 변화하다가 신호가 약해져서 변화가 없어질 때 각이 뭉개진다.

잡음이 없을 경우에도 신호가 도착할 때는 변형돼서 도착할 때가 대부분인데 잡음의 영향까지 더해지면 매우 심각하게 변화한다. 약해진 신호가 더욱 변형되어 0과 1을 잘못 판독할 수 있는데 이것이 통신 오류의 원인이 될 수 있다.

리피터 허브는 연결되어 있는 전체 케이블에 신호를 송신한다.

신호가 리피터 허브에 도달하면 리피터 허브는 LAN 전체에 신호를 흘린다. 이더넷의 기본 원리인 전체에 패킷의 신호를 뿌리고 수신처 MAC주소에 해당하는 기기만 패킷을 수신한다는 원리를 그대로 실현했다고 보면 된다.

리피터 허브의 내부는 아래 그림과 같은데 각 커넥터의 안쪽에는 LAN 어댑터 내부에 있는 PHY 회로와 역할이 같은 회로가 존재한다. 이를 LAN 어댑터 측과 같이 RJ-45 커넥터에 직접 접속하면 신호를 제대로 수신할 수 없다. 제대로 신호를 수신하려면 ‘송신 단자’의 신호를 ‘수신 단자’로 받도록 해야한다. 회로와 커넥터 사이의 신호선을 교차하는 이유는 이 때문이다.

리피터 허브의 끝 커넥터에는 MDI/MDI-X 라는 전환 스위치가 존재한다. MDI는 RJ-45 커넥터와 신호 송수신 회로를 직접 결선한 것이고 MDI-X는 교차하여 결선하는 것을 나타낸다. 허브의 커넥터 부분은 보통 MDI-X 이므로 허브끼리 접속할 때는 한쪽을 MDI로 설정해야 한다. MDI로 전환하는 스위치가 없고 모든 커넥터가 MDI-X인 경우에는 크로스 케이블로 허브들에 접속한다.

✔️ 리피터 허브

이더넷의 기본을 따르는 하드웨어
리피터 허브에 도달한 신호를 LAN 전체에 전달하지만 수신처 MAC 주소에 해당하는 패킷만 수신한다.
전체에 패킷의 신호를 뿌리고 수신처 MAC 주소에 해당하는 기기만 패킷을 수신한다는 의미
- MAC 헤더의 값을 확인 함
리피터 허브의 내부에는 PHY(MAU) 회로와 역할이 같은 회로가 존재한다.
리피터 허브의 끝 커넥터에서는 MDI/MDI-X와 같이 쓰여있는 전환 스위치가 존재한다.
MDI로 전환하는 스위치가 없고 모든 커넥터가 MDI-X인 경우에는 크로스 케이블로 허브들에 접속한다.
잡음의 영향을 받아 데이터가 변화한 것 같은 신호도 전송한다.

💡 리피터 허브는 연결된 케이블 전체에 신호를 송신한다.

2. 스위칭 허브의 패킷중계 동작

스위칭 허브는 주소 테이블로 중계한다

“스위칭 허브” 의 신호가 커넥터 부분에 도달하여 PHY 회로에서 수신되는 부분까지는 리피터 허브와 동일하다. PHY 회로에서 케이블을 흐르는 신호의 형식부터 공통의 신호 형식으로 변환한 후 신호는 MAC 회로에 들어간다. 이후 패킷을 디지털 데이터로 변환한 후 패킷의 맨 끝에 있는 FCS를 대조하여 오류의 유무를 검사하고 문제가 없으면 버퍼 메모리에 저장하고 오류가 있었던 패킷이면 폐기한다. 이 부분은 LAN 어댑터와 거의 같고 각 스위칭 허브의 커넥터 안쪽에는 LAN 어댑터와 같은 회로가 존재한다.

커넥터 안쪽에 있는 회로 부분을 포트라고 한다. 스위칭 허브의 각 포트는 PC의 LAN 어댑터와 거의 같지만 스위칭 허브의 포트는 MAC 주소를 검사하지 않고 모든 패킷을 수신하여 버퍼 메모리에 저장하기 때문에 스위칭 허브의 포트에는 LAN 어댑터와 달리 MAC 주소가 할당되어 있지 않다.

패킷을 버퍼 메모리에 저장하면 MAC 주소와 일치하는 것이 MAC 주소표에 등록되어 있는 지 조사한다. 주소표에 수신처 주소와 동일한 MAC 주소가 존재하면 주소표에쓰여있는 포트 위치에 패킷을 송신한다.

포트사이에 패킷을 운반할 때는 “스위치 회로” 에 패킷의 신호를 흘린다. 예를 들어 2번 포트에서 7번 포트로 패킷을 운반하려면 신호는 2번에서 들어올 것이다. 이때 선의 가로로 나열된 스위치의 왼쪽에서 7개까지의 스위치는 가로방향으로, 8번째의 스위치는 세로방향으로 전환한다. 그러면 아래 그림과 같이 신호는 출력측의 7번으로 흘러가서 7번 포트에 패킷이 도착한다. 이처럼 신호의 교점에 있는 스위치는 각각 독립적으로 움직이므로 신호가 중복되지 않으면 복수의 신호를 흘릴 수 있다.

💡 스위칭 허브는 MAC 주소표에서 MAC 주소를 조사하고 해당하는 포트에 신호를 송신한다.

✔️ 스위칭 허브

스위치 내부에는 MAC 주소와 포트번호를 등록한 테이블이 존재한다.
- 여기에는 수신포트와 송신 포트도 함께 등록된다.
스위치 내부 테이블 정보를 확인하고 패킷을 중계한다. (목적지 확인)
스위치 허브의 포트에는 MAC 주소가 할당되어 있지 않다.
누군가 스위칭 허브에서 신호를 송신 중이면 신호를 보내지 않고 대기한다.
신호의 교점에 있는 스위치는 독립적이므로 신호가 중복되지 않으면 복수의 신호를 동시에 흘린다.
패킷이 충돌하지 않도록 재밍신호를 보낸다.

✔️ 스위치 회로의 구조

그림과 같은 구조를 전자회로로 만든 것
신호선은 격자 모양으로 배치되고 교점에 스위치가 존재함
스위치는 전자적으로 개폐를 제어할 수 있음
전자적 개폐를 통해 신호가 흐르는 대상을 제어함
입력측은 수신측 포트에 접속되어 있고 출력측은 송신측 포트에 접속되어 있음

MAC 주소 테이블을 등록 및 갱신한다.

스위칭 허브는 패킷을 중계할 때 MAC 주소표의 내용을 갱신하는 동작도 실행한다. 갱신 동작에는 두 가지 종류가 있다. 첫번째는 패킷을 수신했을 때 송신처 MAC 주소를 조사하고, 수신한 입력 포트 번호와 하나의 세트로 MAC 주소표에 등록하는 것이다.

MAC 주소표를 등록하는 동작 말고도 등록되어 있는 내용을 지우는 또 하나의 동작이 존재한다. 이것은 기기를 이동했을 때 이동한 기기의 정보 수정없이 패킷을 전달하는 작업을 방지하기 위한 동작이다. 스위치 허브는 오래된 정보를 갱신하기 위해 일정시간 동안 사용되지 않은 정보를 지운다.

✔️ 스위칭 허브의 두 가지 갱신 동작

송신처 MAC 주소 조사 후 수신한 입력포트와 하나의 세트로 MAC 주소표에 등록
사용하지 않고 일장시간이 지나면 등록된 정보를 삭제하는 동작

예외적인 동작

스위칭 허브와 리피터 허브가 같이 접속할 때 송신 포트가 패킷을 수신한 포트와 같을 수 있다. 이때 스위칭 허브는 수신한 포트와 송신하는 포트가 같은 것을 확인하고 같은 값이라면 패킷을 폐기한다. 이뿐만 아니라 MAC 주소표에 수신처 MAC 주소와 일치하는 주소가 등록되어있지 않은 경우도 있다. 이 경우에는 어느 포트에서 송신해야 할지 판단할 수 없으므로 패킷을 수신한 포트 이외의 전체 포트에 패킷을 송신한다. 또한 수신처 MAC 주소가 브로드캐스트 주소인 경우에도 수신 포트를 제외하고 모든 포트에서 패킷을 송신한다.

스위칭 허브는 복수의 중계 동작을 동시에 실행한다

스위칭 허브는 수신처 MAC 주소의 기기가 존재하는 포트 이외에는 송신동작을 실행하지 않으므로 다른 포트는 빈 상태가 된다. 비어있는 포트에는 별도의 패킷을 흘릴 수 있으므로 스위칭 허브는 동시에 여러개의 패킷을 중계할 수 있다. 반면 리피터 허브는 들어온 신호를 모든 포트에 뿌리므로 동시에 두 개 이상의 신호가 들어오면 패킷이 충돌하기 때문에 복수의 신호를 동시에 흘릴 수 없다.

3. 라우터의 패킷 중계 동작

라우터의 기본

라우터의 원리도 스위칭 허브와 비슷하다. 그러나 구체적인 동작은 스위칭 허브와 다른데 라우터는 스위칭 허브와 달리 IP라는 개념을 바탕으로 하기 때문이다. 라우터의 내부 구조는 중계 부분과 포트 부분이라는 두 부분으로 구성되어 있다. 라우터의 중계 부분과 포트 부분의 역할은 LAN 어댑터의 역할 분담과 같다. 즉 라우터의 중계 부분은 IP를 담당하고 포트 부분은 LAN 어댑터와 같다고 생각하면 된다.

✔️ 라우터의 원리

패킷은 라우터의 포트 부분에서 수신한다. (포트 부분의 하드웨어에 의뢰하여 패킷을 수신)
패킷 수신 동작은 포트 부분에 연결된 하드웨어의 통신규칙에 따른다.
중계 부분에서는 받은 패킷의 IP 패킷에 기록되어있는 수신처 IP 주소와 중계 대상을 등록한 표를 대조하여 중계 대상을 판단한다.
라우터는 스위칭 허브와 달리 송신처나 수신처 둘 다 될 수 있음
라우터의 포트에는 IP주소가 할당되어 있음 만약 포트가 이더넷인 경우 MAC도 같이 할당 됨

✔️ 라우터의 구성

중계 부분과 포트 구분으로 구성되어 있음
IP개념을 바탕으로 설계되어 있음
라우터의 중계 부분이 패킷의 중계 대상을 판단함
라우터의 포트 부분은 패킷의 송수신 동작을 담당함
라우터의 포트 부분에는 다양한 하드웨어를 장착할 수 있고 라우터는 장착한 하드웨어에 맞는 통신 기술을 지원함

경로표에 등록된 정보

라우터는 스위칭 허브와 달리 IP 헤더에 기재되어 있는 수신처 IP 주소로 중계 대상을 판단한다. 라우터는 스위칭 허브와 취급하는 주소가 다르므로 중계 대상을 등록하는 테이블의 내용도 다르다.

💡 라우터는 IP 주소로 중계 대상을 판단한다.

라우터의 테이블은 라우팅 테이블 또는 경로표라고 불린다. 여기엔 아래와 같은 정보들이 등록되어 있다.

수신처(Destination)	넷마스크(Netmast)	게이트웨이(Gateway)	인터페이스(Interface)	메트릭(Metric)
10.10.1.0	255.255.255.0		e2	1
10.10.1.101	255.255.255.255		e2	1
192.168.1.0	255.255.255.0		e3	1
192.168.1.10	255.255.255.255		e3	1
0.0.0.0	0.0.0.0	192.0.2.1	e1	1

✔️ 라우팅 테이블 속성 정보

수신처

서브넷 자체를 나타내는 주소, 라우터가 중계할 대상

넷마스크

넷마스크 값에 따라 네트워크의 비트 수를 판단함

게이트웨이

라우터가 수신처에게 패킷을 전송할 때 거쳐야 하는 곳

인터페이스

인터페이스 항목에 등록되어있는 인터페이스(포트)에서 게이트웨이 항목에 등록되어있는 IP 주소를 가진 라우터에게 패킷을 중계함

메트릭

수신처 IP에 기록되어 있는 주소가 먼지, 가까운지를 판단하는 값

라우팅 테이블 수신처 항목에는 서브넷을 나타내는 IP 말고도 주소 집약 이라는 개념을 사용하여 몇개의 서브넷을 한개의 서브넷으로 간주한 후 묶은 서브넷을 경로표에 등록하기도 한다. 예를 들어 A 라우터에 10.10.1.0/24, 10.10.2.0/24, 10.10.3.0/24 서브넷이 연결되어 있을 때 B 라우터는 A라우터에 연결되어 있는 서브넷에게 패킷을 건낼 때 A 라우터에 패킷을 중계해야 한다는 사실은 변하지 않으므로 3개의 서브넷을 일괄적으로 통합하여 라우팅 테이블에 등록한다. 이것을 주소 집약 이라고 한다.

💡 라우터는 호스트 번호를 무시하고 네트워크 번호 부분만 조사한다.
💡 라우터의 경로표에서 '넷마스크' 항목은 경로표의 수신처와 패킷의 수신처 주소를 대조할 때 비트 수를 나타낸다.

라우터의 패킷 수신 동작

라우터 포트에는 MAC 주소와 IP가 할당되어 있으며 라우터는 자신의 주소에 해당하는 패킷만 수신하고 해당하지 않는 패킷은 폐기한다.

경로표를 검색하여 출력 포트를 발견한다.

MAC 헤더의 역할은 라우터에게 패킷을 건네주는 것이다. 때문에 라우터는 패킷 수신 동작이 끝나면 맨 앞의 MAC 헤더를 폐기한다. 수신동작이 끝나면 MAC 헤더 뒤에 있는 IP 헤더의 내용을 보고 패킷 중계 동작에 들어간다.

✔️ 중계 동작

수신한 패킷의 IP 주소와 경로표에 등록된 수신처 항목을 대조한다.
복수의 후보가 발견되면 네트워크 번호의 비트 수가 가장 긴 것을 찾는다.
네트워크 번호의 비트 수가 동일한 것이 존재하면 메트릭 값으로 판단한다.
해당하는 행이 하나도 발견되지 않을 경우 패킷을 폐기하고 ICMP 메세지로 송신처에 통지한다.

💡 라우터에서 중계하는 패킷의 수신처 MAC 주소에는 라우터의 포트에 할당된 MAC 주소가 기록되어 있다.

Reference

성공과 실패를 결정하는 1%의 네트워크

[글또 7기] 다짐

Sat, 14 May 2022 00:00:00 +0900

들어가며

읽기 좋은 글을 꾸준하게 작성하고 싶어서 글또라는 개발자 커뮤니티에서 활동하게 되었다. 꾸준하게 글을 작성하는 것이 목표인데…. 5월 초에 포스팅한 이후로 인제야 글을 작성한다. 느슨해지지 않기 위해 활동하면서 이루고 싶은 목표들을 정하기로 결심 !

참여한 이유

1. 가독성 높은 글

많은 글을 작성해보진 않았지만, 지금까지 포스팅했던 내용을 다시 읽어보면 가독성이 매우 떨어진다. 그리고 불친절한 설명 때문에 다른 사람이 내가 작성한 글을 읽었을 때 큰 혼란이 올 것 같았다. 이런 문제점을 어떻게 고쳐야 하나 고민하고 있을 때 운 좋게 발견한 것이 글또이다.

2. 게으름 탈출

강의를 듣거나 책을 읽는 것은 꾸준하게 하는 것이 어렵지 않은데 이상하게 글을 작성하려고 하면 게을러진다. 마음먹고 자리에 앉아도 포스팅하고 싶었던 내용을 정리하는 것이 그렇게 어렵다. 그래도 강제적으로 할 수밖에 없는 환경에 내던져지면 잘 적응하는 편이여서 글또는 나에게 딱 맞았다.

3. 학습한 내용 머릿속에 각인하기

가끔 학습한 내용을 전부 이해하지 못하고 그냥 지나칠 때 내용을 전부 잊어먹는 경우가 있다. 이럴 때 배운 내용을 다시 곱씹으면서 글로 작성하면 머릿속에 더 깊이 각인되는 효과가 있는 것 같다. 글또에서는 주로 공부한 내용을 포스팅할 것이기 때문에 글솜씨와 함께 나의 개발력도 상승하길 바라고 있다.

목표

1. 작성하고 싶은 글

원래 글또를 신청했을 당시에는 참여했던 스터디 중 가장 만족도가 높았던 JSCODE 운영체제 스터디의 후기를 작성할 생각이었는데 마음이 변했다. 지금은 아래와 관련된 내용의 게시물을 포스팅할 생각이다. 전부 작성할 수 있을진 모르겠지만 일단 도전 !

👊 작성하고 싶은 글 카테고리

읽었던 개발관련 도서 내용 정리
인상깊은 트러블슈팅 경험
Java의 모든 것 ?
Spring 뿌수기
컴퓨터 사이언스

2. 내성적인 인간 탈출

매우 내성적인 성격이라 먼저 나서지도 못하고 말수도 적지만, 글또에서는 좋은 것들은 공유하고 많은 사람과 교류하면서 서로 좋은 영향을 나누고 싶다. 적극적인 사람으로 변할 수 있길 🙏🏻

마치며

6개월 동안 초라한 블로그를 화려하게 바꿀 수 있길 ! 이번에는 마감일에 가깝게 글을 작성하였는데 다음번에는 미루지 않고 부지런하게 작성해야겠다. 앞으로도 계속 마감일에 가깝게 글을 작성하면 글 쓰는 게으름을 많이 고치지 못할 것 같다. 그리고 나의 피드백이 많은 사람에게 도움이 되면 좋겠다 !! 글또 화이팅 !

DNS 란?

Sun, 01 May 2022 00:00:00 +0900

브라우저에 “www.naver.com” 입력하면?

DNS가 무엇인지 알아보기 전에 먼저 브라우저에 “www.naver.com” 을 입력했을 때
어떻게 해당 도메인의 IP를 조회하는지 알아보자

브라우저 애플리케이션이 “도메인명”을 조회하는 DNS 리졸버 호출
DNS 리졸버가 DNS 서버에 보내는 조회 메시지를 생성
프로토콜 스택이 DNS 서버에 DNS 리졸버가 생성한 메시지를 송신
DNS 리졸버가 응답 결과를 수신

브라우저 애플리케이션이 “도메인명”을 조회한다고 했는데, 여기서 “도메인명” 이란 무엇을 말하는 걸까?
“www.naver.com”를 예시로 들었을 때 도메인명이란 www, naver, com 모두 해당된다.
보통 우리는 특정 웹사이트에 접속할 때 IP 주소가 아닌 도메인명을 입력해서 접속한다.

DNS 란?

사용자는 특정 웹사이트의 도메인명이 아닌 실제 IP를 알 필요가 없다. 하지만 OS 내부에서 다른 서버에 패킷을 송신할 때는 도메인명이 아닌 IP 주소가 필요하다. 앞서 설명한 것처럼 브라우저 애플리케이션은 도메인명으로 해당 서버의 IP 주소를 조회한다. 그렇다면 DNS란 무엇일까? DNS는 도메인명에 해당하는 IP와 기타 정보를 저장해둔 서버이다. 보통 아래와 같은 정보가 저장되어 있다.

이름	클래스	타입	클라이언트에 회답하는 항목
www.example.com	IN	A	192.168.2.5
example.com	IN	MX	192.168.2.6

✔️ 등록정보의 구성

이름
- 이름은 앞서 말한 도메인명에 해당된다.
클래스
- 클래스는 네트워크의 종류를 나타낸다. IN은 인터넷을 뜻한다.
타입
- 해당 도메인명에 어떤 타입의 정보가 지원되는지를 뜻한다. 예를 들면 MX는 메일의 배송 목적지, A는 도메인명에 IP 주소가 지원된다는 뜻
클라이언트에 회답하는 항목
- 이 항목은 도메인명에 해당하는 IP 주소를 의미한다.

등록된 정보를 간단하게 살펴보면 도메인명으로 해당하는 IP를 매칭 해둔 서버인 것 같다.
그런데? 대체 왜 필요한 것일까?

DNS를 사용하는 이유

간단하게 전화번호부를 예로 들어보자. 평소에 우리는 지인들의 전화번호를 전부 외우지 못한다. 하지만 우리는 현대인이기 때문에 전화번호를 외우지 못하는 것이 아무런 문제가 되지 않는다. 전화번호를 전화번호부에 이름으로 저장해두면 되기 때문이다. DNS도 비슷한 맥락이다. 우리가 자주 접근하는 웹 사이트 전부를 IP 주소만을 사용해서 접근할 수 있다고 생각하면 너무 끔찍하다. 북마크 기능이 있지만 접근하는 사이트마다 북마크를 해놓을수도 없는 노릇이다. DNS 서버는 우리가 도메인명으로 웹 사이트에 접근할 수 있도록 해주는 아주 고마운 서버이다. 그런데 DNS 서버없이 그냥 도메인명으로 통신하면 안될까? 라는 의문도 들 수 있다. 하지만 IP 주소는 32bit 만으로 이뤄져있는 반면에 도메인명은 수십 바이트부터 255 바이트까지 존재하기 때문에 라우터의 부하가 발생하여 통신이 지연될 수 있다.

[네트워크 스터디] Chapter_02 TCP/IP의 데이터를 전기 신호로 만들어 보낸다

Fri, 29 Apr 2022 00:00:00 +0900

📗 Chapter_02 TCP/IP의 데이터를 전기 신호로 만들어 보낸다

🌟 2장의 요점 짚고 넘어가기 🌟

Chapter 02에선 OS에 내장된 프로토콜 스택이 처음 등장한다. 프로토콜 스택은 네트워크 제어용 소프트웨어이다. 프로토콜 스택은 브라우저에서 받은 메세지를 패킷 속에 저장하고, 수신처 주소 등의 제어 정보를 덧붙인다. 프로토콜 스택은 통신 오류가 발생했을 때 패킷을 고쳐서 보내거나 통신의 기본을 조절하는 등의 다양한 역할을 한다.

이뿐만 아니라 프로토콜 스택은 패킷을 LAN어댑터(이더넷이나 무선 LAN으로 통신할 때 사용하는 하드웨어)에 넘긴다. 그리고 LAN 어댑터가 패킷을 전기신호로 변환하고 LAN의 케이블에 송출하는 과정을 통해 패킷이 네트워크 속으로 전달된다.

1. 소켓을 작성한다.

1️⃣ 프로토콜 스택의 내부 구성

아래 이미지는 브라우저에서 데이터를 전송했을 때 어떠한 소프트웨어와 하드웨어를 거쳐 서버에 도착하는 지

간단하게 요약한 이미지이다.

✔️ 네트워크 어플리케이션

브라우저, 메일러, 웹 서버, 메일 서버 등의 프로그램이 여기에 해당됨
네트워크 어플리케이션부터 아래로 향하여 데이터 송 수신 등의 일을 의뢰함
Socket
- 네트워크 애플리케이션 아랫부분에는 Socket 라이브러리가 존재하고 그 안에는 리졸버가 내장되어 있음
- Socket 라이브러리는 DNS서버에서 목적지의 IP 주소를 조회하는 역할을 담당함

✔️ 프로토콜 스택

프로토콜 스택은 OS 내부에 존재하는 네트워크 제어용 소프트웨어이다.
TCP, UDP 프로토콜을 사용하는 소프트웨어
- 프로토콜 스택의 윗부분에는 TCP, UDP 프로토콜을 사용하여 데이터 송수신을 담당하는 부분이 존재한다. 이 둘이 어플리케이션의 의뢰를 받아 송수신 동작을 실행한다.
IP 프로토콜을 사용하는 소프트웨어
- 데이터를 작게 나눈 패킷을 통신 상대까지 운반하는 것이 해당 소프트웨어의 주 역할
- IP 안에는 ICMP와 ARP라는 프로토콜을 다루는 부분이 존재함
- ICMP는 패킷을 운반할 때 발생하는 오류를 통지하거나 제어용 메세지를 통지할 때 사용됨
- ARP는 IP 주소에 대응하는 이더넷의 MAC 주소를 조사할 때 사용됨

✔️ LAN 드라이버

LAN 어댑터의 하드웨어를 제어함
LAN 드라이버 아래에 있는 LAN 어댑터가 실제 송 수신 동작, 즉 케이블에 대해 신호를 송 수신 하는 동작을 실행함

💡 프로토콜 스택이란 네트워크 제어용 소프트웨어이다. 프로토콜 스택은 제어 정보를 저장하거나 패킷을 LAN 어댑터에 넘기는 역할을 담당한다.

💡 브라우저나 메일 등의 일반적인 애플리케이션이 데이터를 송 수신할 경우에는 TCP를 주로 사용

💡 DNS 서버에 대한 조회 등에서 짧은 제어용 데이터를 송수신할 경우에는 UDP 사용

✔️ 소켓의 메세지 송신 동작

2️⃣ 소켓의 실체는 통신 제어용 제어 정보

프로토콜 스택은 내부에 제어 정보를 기록하는 메모리 영역을 가지고 있다. 해당 영역에는 통신 동작 제어에 필요한 제어 정보를 기록한다. 대표적으로 통신 상대의 IP주소, 포트번호, 통신 동작 진행 상태 등이 있다.

본래 소켓은 개념적인 것이고 실체가 존재하지 않는다. 굳이 말하자면 프로토콜 스택 내부에 저장된 제어 정보가 소켓의 실체라고 할 수 있다. 프로토콜 스택은 소켓에 기록된 제어 정보를 참조하면서 동작한다.

3️⃣ 소켓을 호출했을 때의 동작

✔️ socket()

애플리케이션이 socket을 호출하여 프로토콜 스택에게 소켓을 만들 것을 의뢰한다. 이때 프로토콜 스택은 소켓 한 개 분량의 메모리 영역을 확보하고 초기 상태임을 나타내는 제어 정보를 기록한다. 이 과정을 통해 소켓이 생성된다.
소켓이 생성되면 소켓을 나타내는 디스크립터를 애플리케이션에 알려준다. 디스크립터는 프로토콜 스택의 내부에 있는 다수의 소켓 중 어느 것을 가리키는지 나타내는 번호표와 같다. 디스크립터는 프로토콜 스택이 데이터 송 수신 동작을 의뢰할 때 통지한다.

2. 서버에 접속한다.

1️⃣ 접속의 의미

이더넷이나 통신 회선은 항상 케이블이 연결되어 있으므로 데이터를 신호로 변환하여 송신하기만 하면 언제든 통신이 가능하다. 하지만 소켓을 만든 직후에는 아무런 정보도 기록되어 있지 않기 때문에 통신 상대와의 사이에 제어 정보를 주고받아서 데이터 송 수신이 가능한 상태로 만드는 작업이 필요하다. 여기에서 주고받는 제어정보는 IP나 포트번호 등이다. 접속 동작에서 주고받는 제어 정보는 통신의 규칙으로 정해져 있다.

접속을 시도할 때는 제어 정보를 주고받는 것 뿐만 아니라 송 수신 데이터를 일시적으로 저장할 버퍼 메모리 확보도 이때 같이 실행된다.

2️⃣ 맨 앞부분에 제어 정보를 기록한 헤더를 배치한다.

✔️ 헤더란?

헤더는 클라이언트와 서버가 서로 연락을 절충하기 위해 주고받는 정보가 포함되어 있다.
헤더에는 데이터를 송 수신 하는 동작이나 연결을 끊는 동작도 포함되어 있기 때문에 통신 동작 전체에서 필요한 내용을 검토하여 TCP 프로토콜의 사양으로 규정하고 있다.
클라이언트와 서버 사이에 주고받는 패킷 맨 앞부분부터 부가된 제어정보를 헤더라고 한다.
이더넷이나 IP에도 동일한 헤더가 존재하기 때문에 TCP 헤더, 이더넷 헤더(=Mac 헤더), IP헤더와 같이 구분하여 사용해야 한다.

✔️ 소켓에 기록되는 정보

프로토콜 스택의 동작을 제어하기 위한 정보
- 애플리케이션에서 통지된 정보
- 통신 상대로부터 받은 정보
- 송 수신 동작의 진행 상황
프로토콜 스택이 소켓에 기록된 정보를 참조하면서 움직이기 때문에 소켓의 제어 정보는 프로토콜 스택과 일체화 되어있다 해도 무방하다.
소켓에 기록되는 정보는 상대측에서 볼 수 없다. 이미 서로 필요한 정보를 헤더로 주고받기 때문에 통신에는 문제가 없다.

🌟  통신 동작에 이용하는 제어 정보는 다음의 두 종류

1. 헤더에 기입되는 정보
2. 소켓에 기록되는 정보

3️⃣ 접속 동작의 실체

✔️ connet()

여기에 서버측의 IP 주소와 포트 번호를 입력하면 명령이 프로토콜 스택의 TCP 담당 부분에 전달된다.
그러면 TCP 담당 부분은 목적지 서버측의 TCP 담당 부분과의 사이에 제어 정보를 주고 받는다.

✔️ 클라이언트와 서버의 대화 과정

데이터 송 수신 동작의 개시를 나타내는 제어 정보를 기록한 헤더를 만든다.
헤더의 내용 중 중요한 것은 송신처와 수신처의 포트번호이다. 이를 통해 송신처와 수신처를 지정할 수 있다.
    
TCP 헤더가 만들어지면 이를 IP 담당 소프트웨어에 건네주어 송신하도록 의뢰한다.

송신 동작을 거쳐 네트워크를 통해 서버에  패킷이 도착하면 서버측의 IP 담당 소프트웨어가 이를 TCP 담당 소프트웨어 에게 전달한다.

서버측의 TCP 담당 소프트웨어가 TCP헤더를 조사하여 기록되어 있는 수신처 포트 번호에 해당하는 소켓을 찾아낸다. 
   해당하는 소켓이 발견되면 해당 소켓에 필요한 정보를 기록하고 접속 동작 상태를 진행 중으로 변경한다.
    
(4)번 과정이 끝나면 서버의 TCP 담당 소프트웨어는 응답을 돌려보내기 위해 IP 담당 소프트웨어에게 의뢰한다. 

이때 ACK라는 컨트롤 비트도 1로 설정하여 돌려보낸다. 

패킷이 클라이언트에게 정상적으로 돌아왔으면 TCP 헤더를 조사하여 서버측의 접속 동작이 성공했는 지 확인한다. 
   서버 측의 접속이 성공했으면 클라이언트 소켓에 서버 IP 주소나 포트 번호 등과 함께 접속 완료를 나타내는 제어 정보를 기록한다.
    
마지막으로 클라이언트에 패킷이 정상적으로 도착했다는 것을 알리기 위해 ACK 비트를 1로 만든 TCP 헤더를 서버측에 반송한다.

🌟 ACK는 패킷이 대상에게 잘 도착했는지 확인하는 용도로 사용된다.

3. 데이터를 송수신 한다.

1️⃣ 프로토콜 스택에 HTTP 리퀘스트 메세지를 넘긴다.

connect에서 애플리케이션에 제어가 되돌아오면 데이터 송 수신 동작이 들어간다. 데이터 송 수신 동작은 애플리케이션이 ✔️ write() 를 호출하여 송신 데이터를 프로토콜 스택에 건네주는 곳부터 시작된다.

프로토콜 스택은 받은 데이터의 내용을 곧바로 송신하는 것이 아니라 일단 프로토콜 스택 내부의 송신용 버퍼 메모리 영역에 저장하고 애플리케이션이 다음 데이터를 건네주기를 기다린다.

송신용 버퍼에 저장하는 이유는 애플리케이션에서 프로토콜 스택에 건네주는 데이터의 길이는 애플리케이션마다 상이하기 때문이다. 이러한 상황에서 받은 데이터를 곧바로 보내는 방법은 작은 패킷을 많이 보낼 수 있지만 네트워크 이용 효율이 저하되므로 어느 정도 데이터를 저장하고 나서 송 수신 동작을 진행한다.

송신 버퍼에 어느 정도의 데이터가 담겼을 때 송신한다는 규칙은 OS의 종류나 버전마다 달라지지만 MTU나 타이밍을 바탕으로 어느정도 판단할 수 있다.

✔️ MTU?

한 패킷으로 운반할 수 있는 디지털 데이터의 최대 길이 이더넷에서는 보통 1500 바이트
MTU에는 패킷의 맨 앞부분에 헤더가 포함되어 있음, 여기부터 헤더를 제외한 것이 하나의 패킷으로 운반할 수 있는 데이터의 최대 길이가 됨 이것을 MSS 라고 한다.

✔️ MSS?

헤더를 제외하고 한 개의 패킷으로 운반할 수 있는 TCP의 데이터 최대 길이
애플리케이션에서 받은 데이터가 MSS를 초과하거나 MSS에 가까운 길이에 이르기까지 데이터를 저장하고 송신동작을 진행하면 패킷이 잘게 나눠질 걱정을 하지 않아도 된다.

✔️ 타이밍?

애플리케이션의 송신 속도가 느려지는 경우 MSS에 가깝게 데이터를 저장하면 여기에서 시간이 걸려 송신 동작이 지연되므로 버퍼에 데이터가 모이지 않아도 적당한 곳에서 송신 동작을 실행해야 한다. 따라서 프로토콜 스택은 일정한 시간이 경과하면 패킷을 송신할 수 있게 내부에 타이머라는 소프트웨어를 둔다.

두 가지의 판단요소가 존재하지만 이 둘은 상반되는 면도 존재한다. MSS 바탕을 중시하면 패킷 길이가 길어져서 네트워크 이용 효율이 높아지지만 버퍼에 머무는 시간만큼 송신 동작이 지연될 우려가 존재한다. 반대로 타이밍을 중시하면 지연은 적어지지만 이용 효율이 떨어지므로 양자를 절충해서 적당히 시간을 가늠하여 송신 동작을 실행해야 한다. 그러나 TCP 프로토콜 사양에는 절충에 대한 규약은 없으므로 실제 판단은 프로토콜 스택을 만드는 개발자의 몫이다.

2️⃣ 데이터가 클 때는 분할하여 보낸다

HTTP 리퀘스트 메세지는 보통 그다지 길지 않은 것이 대부분이다. 하지만 항상 예외는 존재하기에 HTTP 리퀘스트 메세지가 한 개의 패킷에 전부 들어가지 못할 경우, 송신 버퍼에 들어있는 데이터를 맨 앞부터 차례대로 MSS의 크기에 맞게 분할하고 분할한 조각을 한 개씩 패킷에 넣어 송신한다.

3️⃣ ACK 번호를 사용하여 패킷이 도착했는지 확인한다.

데이터 송신동작은 앞서 설명한 것 만으로는 끝나지 않는다. TCP는 송신한 패킷이 상대에게 도착했는지 확인하고 도착하지 않았으면 다시 송신하는 기능이 있으므로 패킷을 송신한 후에는 확인 동작으로 넘어간다.

먼저 TCP 담당 소프트웨어는 데이터를 조각으로 분할할 때 조각이 통신 개시부터 따져서 몇 번째 바이트에 해당 하는지 세어둔다. 이 값을 시퀀스 번호라고 하며 TCP 헤더에 기록한다. 이렇게 시퀀스 번호를 기록할 경우 수신측에서 패킷의 누락여부를 확인할 수 있다. 수신측은 전달 받은 데이터의 바이트 크기를 확인하고 이를 ACK 번호에 기록하고 이 값에 1을 더하여 송신측에 전달한다.

✔️ 예시

총 4381바이트의 데이터를 전송한다고 가정한다.

[누락되지 않은 경우]

시퀀스 번호 1 , 데이터 크기 : 1460바이트
1. ACK 번호 1461
시퀀스 번호 1461, 데이터 크기 : 1460바이트
1. ACK 번호 2921
시퀀스 번호 2921, 데이터 크기 : 1460바이트
1. ACK 번호 4381

[누락된 경우]

시퀀스 번호 1 , 데이터 크기 : 1460바이트
1. ACK 번호 1461
시퀀스 번호 1461, 데이터 크기 : 1460바이트
1. ACK 번호 전송하지 않음
시퀀스 번호 1461, 데이터 크기 : 1460바이트 (재전송)
1. ACK 번호 2921

🌟  시퀀스 번호와 ACK 번호로 패킷이 수신측에 도착한 것을 확인한다.

🌟 ACK 번호를 통지할 때는 단순히 ACK 번호에 값을 설정할 뿐만 아니라 제어 비트의 ACK 비트도 1로 설정한다. 
이렇게하면 ACK 번호 필드가 유효하다는 의미가 된다.

4️⃣ 패킷 평균 왕복 시간으로 ACK 번호의 대기 시간을 조정한다.

ACK 번호가 돌아오는 것을 기다리는 시간을 타임아웃 값 이라고 한다.

네트워크가 혼잡하면 ACK 번호가 돌아오는 시간이 지연될 수 있다. 이때 ACK 번호가 돌아오기전에 패킷을 재전송하면 혼잡한 네트워크를 악화시키는 사태가 발생한다.

이러한 문제를 방지하기 위해 대기 시간을 적절하게 설정해야한다. 대기 시간이 너무 짧으면 패킷을 자주 보내게 되고 대기시간을 너무 길게 설정하면 패킷을 다시 보내는 동작이 지연되어 속도 저하의 원인이 되기 때문이다.

보통 TCP는 ACK 번호가 돌아오는 시간을 기준으로 대기 시간을 판단하여 동적으로 변경하는 방법을 취한다.

5️⃣ 윈도우 제어 방식으로 효율적으로 ACK 번호를 관리한다.

ACK 번호가 돌아올 때까지의 시간동안 아무 일도 하지 않고 기다리는 것은 자원과 시간 낭비이다.

낭비를 줄이기 위해 TCP는 윈도우 제어 방식에 따라 송신과 ACK 번호 통지의 동작을 실행한다.

윈도우 제어 방식이란 한 개의 패킷을 보낸 후 ACK 번호를 기다리지 않고 차례대로 연속해서 복수의 패킷을 보내는 방법을 말한다. 이럴 경우 ACK 번호가 돌아올 때까지의 시간이 낭비되지 않는다.

주의할 점은 ACK 번호를 기다리지 않고 차례로 패킷을 보내면 수신측의 능력을 초과하여 패킷을 보내는 사태가 발생할 수 있다.

수신측은 패킷을 수신하면 수신측 버퍼 메모리에 일시 보관한다. 수신측에서는 ACK 번호를 계산하는 작업이나 조각을 연결하여 원래 데이터를 복원하고 애플리케이션에 넘겨주어야 수신 버퍼에 저장된 데이터가 사용되어 사라진다. 하지만 송신측이 수신측의 처리속도보다 빠른 속도로 패킷을 송신하면 수신 버퍼에 데이터가 쌓이지 않고 사라질 수 있다.

이러한 문제를 방지하기 위해 수신측은 송신측에 수신가능한 데이터의 양을 통지한다. 수신 가능한 양은 TCP 헤더의 윈도우 필드에 기록하여 송신측에 알린다.

6️⃣ ACK 번호와 윈도우를 합승한다.

수신측은 네트워크 효율성 저하를 방지하기 위해 ACK 번호나 윈도우를 통지할 때 소켓을 바로 보내지 않고 잠시 기다린다. 기다리는 사이에 통지 동작이 발생하면 양쪽을 상승시켜서 한 개의 패킷으로 묶어서 전송한다.

예를 들자면 ACK 번호의 송신을 대조할 때 윈도우 통지가 발생하면 ACK 번호와 윈도우를 한개의 패킷에 합승 시켜서 통지하여 패킷의 수를 줄이는 것이다.

연속으로 ACK 번호 통지가 발생할 때도 마찬가지다. ACK 번호는 수신한 데이터의 끝이 어디인지를 송신측에 알리는 것이므로 ACK 번호가 통지가 연속적으로 발생하면 마지막 ACK 번호만 송신하고 나머지의 것은 생략해도 상관없다. 윈도우 통지도 마찬가지이다. 윈도우 통지가 연속적으로 발생하면 수신버퍼에 빈 공간이 늘어난다는 의미이므로 마지막 통지만 전달해도 문제가 발생하지 않는다.

7️⃣ HTTP 응답 메세지를 수신한다.

HTTP 리퀘스트 메세지를 보내면 웹 서버에서 응답 메세지가 돌아오기를 기다리고, 응답 메세지가 돌아오면 그것을 수신한다.

데이터를 수신하면 수신한 데이터 조각과 TCP 헤더의 내용을 조사하여 누락된 데이터가 있는 지 검사하고 문제가 없으면 송신측에 ACK 번호를 반송한다. 그리고 데이터의 조각을 수신 버퍼에 일시 보관하고 데이터 조각을 연결하여 애플리케이션에게 건네준다. 이를 정확하게 설명하자면 수신 버퍼에 저장된 데이터를 애플리케이션 메모리 영역에 옮기고 제어권을 애플리케이션에게 되돌려준다.

4. 서버에서 연결을 끊어 소켓을 말소한다.

1️⃣ 데이터 보내기를 완료했을 때 연결을 끊는다.

데이터의 송 수신 동작이 완료되면 대상과의 연결을 끊는다. 이때 연결 끊기를 시도하는 대상은 서버나 클라이언트의 구분이 없다. 만약 서버에서 먼저 연결을 끊는다고 가정하면 서버측의 프로토콜 스택이 TCP 헤더를 생성하고 컨트롤비트인 FIN의 값을 1로 설정하여 클라이언트에게 전송한다. 이때 서버측은 소켓이 연결 끊기 동작에 들어갔다는 것을 기록한다. 서버에서 FIN을 설정한 TCP 헤더가 클라이언트에게 도착하면 클라이언트는 자신의 소켓에 서버가 연결끊기 작업에 들어갔다는 것을 기록하고 서버측에 FIN 값을 수신했다는 의미로 ACK 값을 전송한다.

클라이언트측 소켓이 애플리케이션에 데이터를 전부 전달하면 클라이언트측의 애플리케이션도 close를 호출하여 데이터 송 수신 동작을 중지한다. 그러면 클라이언트의 프로토콜 스택도 서버와 마찬가지로 TCP 헤더에 FIN 값을 1로 설정하여 서버측에 전송한다. 서버측에서 ACK 값이 되돌아오면 서버와의 대화는 끝이난 것이다.

[연결 끊기 동작]

클라이언트가 FIN 송신
서버가 ACK 번호 송신
서버가 FIN 송신
클라이언트가 ACK 번호 송신

🌟 이때 연결 종료의 순서는 클라이언트와 서버가 서로 바뀔수도 있다.

2️⃣ 소켓을 말소한다.

서버와의 대화가 끝나면 더이상 소켓을 사용하여 서버와 대화할 수 없다. 하지만 이때 바로 소켓을 말소시키면 ACK 번호의 응답이 늦어 FIN을 재전송 할 때 기록 정보가 제거되어 어느 소켓이 수신 대상인지 알 수 없게 된다. 뿐만아니라 동일한 포트로 새롭게 생성된 소켓이 FIN을 수신하여 오동작이 발생할 수 있다. 이러한 문제 때문에 소켓을 바로 말소하지 않고 일정시간 기다린 후 말소한다.

Reference

https://velog.io/@anhesu11/HTTP-기본-이론-정리

성공과 실패를 결정하는 1%의 네트워크

[운영체제 스터디] 파일 시스템

Sun, 17 Apr 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

📁 File System

1. File and File System

✔️ File

“A named cllection of related information”
일반적으로 비휘발성의 보조기억장치에 저장
운영체제는 다양한 저장 장치를 file이라는 동일한 논리적 단위로 볼 수 있게 해줌
Operation
- create, read, wrtie reponsition (lseek), delete, open, close 등
- (reponsition) 파일의 내용 위치정보 재정의

✔️ File attribute ( 혹은 파일의 metadata)

파일 자체의 내용이 아니라 파일을 관리하기 위한 각종 정보들
- 파일 이름, 유형, 저장된 위치, 파일 사이즈
- 접근 권한 (읽기/쓰기/실행), 시간 (생성/변경/사용), 소유자 등

✔️ File system

운영체제에서 파일을 관리하는 부분
파일 및 파일의 메타데이터, 디렉토리 정보 등을 관리
파일의 저장 방법 결정
파일 보호 등

2. Directory and Logical Disk

✔️ Directory

파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한 파일
그 디렉토리에 속한 파일 이름 및 파일 attribute들
operation
- search for a file, create a
- list a directory, rename a file, travers the file system

✔️ Partition (=Logical Disk)

하나의 (물리적) 디스크 안에 여러 파티션을 두는게 일반적
여러 개의 물리적인 디스크를 하나의 파티션으로 구성하기도 함
(물리적) 디스크를 파티션으로 구성한 뒤 각각에 파티션에 file system을 깔거나 swapping등 다른 용도로 사용할 수 있음

3. File Operation

파일에 대한 연산은 모두 system call

✔️ open(”/a/b/c”)

디스크로부터 파일 c의 메타데이터를 메모리로 가지고 옴
이를 위하여 directory path 를 search
- 루트 디렉토리 “/”를 open하고 그 안에서 파일(디렉토리) “a”의 위치 획득
- 파일 “a”를 open하고 그 안에서 파일(디렉토리) “b”의 위치 획득
- 파일 “b”를 open하고 그 안에서 파일(디렉토리 일수도 있음) “c”의 위치 획득
- 파일 “c”를 open한다.
파일의 경로가 길어질 경우 Directory path의 search에 너무 많은 시간이 소요 됨
- Open을 read / write와 별도로 두는 이유임
- 한번 open한 파일은 read / write 시 directory search 불필요
Open file table
- 현재 open 된 파일들의 메타데이터 보관소 (in memory)
  - 파일을 오픈하면 해당 메타데이터가 메모리에 저장됨
- 디스크의 메타데이터보다 몇 가지 정보가 추가
  - Open한 프로세스의 수
  - File offset: 파일 어느 위치 접근 중인지 표시 (별도 테이블 필요)
File descriptor (file handle, file control block)
- Open file table에 대한 위치 정보 (프로세스 별)

프로세스 A가 open(”/a/b”)를 호출한다. (system call)
루트 디렉토리의 메타데이터 정보를 메모리에 할당한다.
루드 디렉토리의 메타데이터 정보로 디스크에 저장된 루트 디렉토리의 실제 내용을 검색한다 (루트 디렉토리 하위의 파일들 메타 데이터)
루트 디렉토리 컨텐츠에 파일 A의 정보가 존재한다. A는 사용자 프로그램이 호출한 파일의 경로에 포함되어 있기 때문에 A의 메타 데이터를 메모리에 할당한다.
A의 메타데이터 정보로 디스크에 저장된 A의 컨텐츠 위치를 찾는다.
A의 컨텐츠에 저장된 B의 메타데이터 정보를 메모리에 할당한다.
open() System call의 결과값을 사용자 프로그램에게 전달한다 (파일 b의 위치를 가리키는 디스크립터를 리턴함)
read(fd) = open()에서 리턴된 디스크립터와 읽을 범위를 지정하면 파일을 복사하고 메모리에 저장한 뒤(버퍼 캐싱) 프로그램에게 전달한다. (범위를 지정하지 않으면 처음부터 파일을 읽음)

4. File Protection

각 파일에 대해 누구에게 어떤 유형의 접근(read/write/execution)을 허락할 것인가?

✔️ Acess Control 방법

Acess Control list: 파일별로 누구에게 어떤 접근 권한이 있는지를 표시한다. 연결 리스트 형태로 구현이 가능하다.
Capabiliy: 사용자별로 자신이 접근 권한을 가진 파일 및 해당 권한을 표시한다. 마찬가지로 연결 리스트 형태로 구현이 가능하다.

✔️ Grouping

전체 user를 owner, group, public의 세 그룹으로 구분
일반적으로 가장 많이 사용되는 형식
각 파일에 대해 세 그룹의 접근 권한(rwx)를 3비트씩으로 표시
(예) UNIX
- rwx(owner) r—(group) r—(other)
  - owner는 모든 권한이 부여되어있고 group과 public은 읽기 권한만 부여된 상태이다.

✔️ Password

파일마다 password를 두는 방법 (디렉토리 파일에 두는 방법도 가능)
모든 접근 권한에 대해 하나의 password: all-or-nothing
접근 권한별 password: 암기 문제, 관리 문제

5.File System의 Mounting

앞에서 하나의 물리적 디스크를 파티션으로 나눠 여러개의 논리적 디스크로 사용할 수 있다고 설명했다. 각각의 논리적 디스크에는 파일 시스템을 설치할 수 있는데, 서로 다른 논리적 디스크에 존재하는 파일 시스템에 접근하려면 어떻게 해야할까? 다른 파티션에 존재하는 파일시스템에 접근하게 해주는 Mounting 기법이 존재한다. Mouting 기법이 무엇인지 알아보자

최상위 파일 시스템에 다른 파티션에 존재하는 파일 시스템에 연결된 디렉토리를 생성한다
연결된 디렉토리에 진입하면 해당 파티션에 존재하는 파일 시스템에 접근이 가능하다.

6. Access Methods

✔️ 시스템이 제공하는 파일 정보의 접근 방식

순차 접근 (sequential access)
- 카세트 테이프를 사용하는 방식처럼 접근
- 읽거나 쓰면 offset은 자동적으로 증가
직접 접근 (direct access, random access)
- LP 레코드 판과 같이 접근하도록 함
- 파일을 구성하는 레코드를 임의의 순서로 접근할 수 있음

Reference

이화여자대학교 반효경 교수님 운영체제 강의

[운영체제 스터디] 가상 메모리와 Page Fault

Sat, 16 Apr 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

🗳️ Virtual Memory

물리적 메모리의 주소변환은 운영체제가 관여하지 않지만 Virtual Memory 기법은 운영체제가 관여한다.

1. Demand Paging

실제로 사용자 프로그램에선 자주 사용되지 않는 코드가 대부분이다.

Demand Paging 기법은 실제로 사용될 경우 메모리에 올리기 때문에 많은 프로세스를 메모리에 동시에 올릴 수 있다.

Demand Paging 기법에선 무조건 한번은 page fault가 발생한다. (참조될 경우에 메모리에 올리기 때문)

실제로 필요할 때 page를 메모리에 올리는 것

I/O 양의 감소

한정된 메모리 공간을 조금 더 효율적으로 사용할 수 있기 때문에 Disk 에서 읽어오는 일이 적어짐

Memory 사용량 감소

빠른 응답 시간

더 많은 사용자 수용

Valid / Invalid bit의 사용

Invalid 의 의미

사용되지 않는 주소 영역인 경우

페이지가 물리적 메모리에 없는 경우

처음에는 모든 page entry가 invalid로 초기화

address translation 시에 Invalid bit이 set되어 있으면

“page fault”

2. Page Fault

invalid page를 접근하면 MMU가 trap을 발생시킴 (page fault trap)
Kernel mode로 들어가서 page fault handler가 invoke됨
다음과 같은 순서로 page fault를 처리한다.
- invalid reference? (eg. bad address, protection violation) → abort process
- Get an empty frame (없으면 뺏어온다: 다른 페이지가 할당된 frame에 replace)
메모리를 획득하면 해당 페이지를 disk에서 momory로 읽어온다
- disk I/O가 끝나기까지 이 프로세스는 CPU를 preempt 당함 (block)
- Disk read가 끝나면 page tables entry 기록, valid/invalid bit = “vaild”
- ready queue에 process를 insert → dispatch later
- 이 프로세스가 CPU를 잡고 다시 running
- 아까 중단되었던 instruction을 재개

✔️ Steps in Handling a Page Fault

페이지 테이블 엔트리에 접근한다.
접근한 엔트리의 Invalid bit이 invalid이면 trap을 발생시킨다.
커널모드로 변경되어 page가 저장된 하드디스크에 접근한다.
page를 비어있는 page frame으로 이동시킨다. 이때 비어있는 page frame이 존재하지 않을경우 다른 페이지가 할당된 frame에 replace한다
새로 할당된 page frame number를 입력하고 invalid bit을 수정한다.
trap에 의해 중단되었던 명령어를 다시 수행한다.

✔️ Performace of Demand Paging

Page Fault Rate 0≤ p ≤ 1.0
- if p = 0 no page fault
- if p = 1, every reference is a fault
Effective Access Time
- (1 - p) x memory access + P (OS & HW page fault overhead
  - [swap page out if needed]
  - swap page in
  - OS & HW restart overhead)

🌟 실제로 시스템에서 Page Fault Rate를 조사해본 결과 0.09 값이 측정된다. 즉 대부분의 경우는 메모리에서 직접 주소변환이 이뤄진다는 것이다.

2.2 Empty Frame이 없는 경우

✔️ Page replacement

어떤 frame을 빼앗아올지 결정해야 함
곧바로 사용되지 않을 page를 쫓아내는 것이 좋음
동일한 페이지가 여러번 메모리에서 쫓겨났다가 다시 들어올 수 있음
운영체제의 역할

✔️ Replacement Algorithm

page-fault rate을 최소화하는 것이 목표
알고리즘의 평가
- 주어진 page reference string에 대해 page fault를 얼마나 내는지 조사
reference string
- 시간순서에 따라 나열된 page frame (참조된 순서로 나열됨)
- reference string의 예
  - 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5

✔️ Page Replacement 흐름

swap out할 victim page를 선점하여 backing store에 swap out시킨다. 이때 변경사항이 있으면 변경된 내용을 저장하고 swap out한다.
victim page가 저장되어있던 page table 엔트리의 valid/invalid bit를 invalid 로 수정한다
swap out이 완료되면 victim page가 존재하던 frame에 trap을 발생시킨 page를 할당한다.
새롭게 할당된 page가 존재하는 page table 엔트리의 frame number를 수정한다.

💡 victim page

page replacement에 의해 swap out 되는 페이지를 victim page 라고 한다

2.3 Optimal Algorithm

MIN(OPT): 가장 먼 미래에 참조되는 page를 replace

✔️ Optimal Alogrithm?

미래의 참조를 어떻게 아는가?
- 미래를 모두 짐작해야하기 때문에 Offline algorithm 실제로 사용되진 않음
다른 알고리즘 성능에 대한 upper bound 제공
- Belady’s optimal algorithm, MIN, OPT 등으로 불림

✔️ Optimal Alogrithm 예시

[ 가정 ]

빨간색 숫자는 page fault가 발생한 page
연보라색 숫자는 메모리로 바로 참조되는 page

[ 예시 ]

1,2,3,4번 page의 참조가 발생하여 메모리에 할당한다.
1번과 2번 page가 메모리에서 바로 참조된다.
다음 순서로 5번 page가 참조되어 page fault가 발생한다.
이때 page frame은 모두 꽉 차있는 상태이므로 swap out할 page를 선점한다.
가장 먼 미래에 참조되는 4번 page를 swap out한다.

2.4 FIFO (First In First Out) Algorithm

가장 먼저들어온 page를 내쫓는 알고리즘

✔️ FIFO Anomaly (Belady’s Anomaly)

more frames ≠ less page fault
frame이 많을수록 page fault가 더 자주 일어난다.

✔️ FIFO (First In First Out) Algorithm 예시

[가정]

빨간색 숫자는 page fault가 발생한 page
연보라색 숫자는 메모리로 바로 참조되는 page

[예시]

1,2,3 번 page가 참조되어 page fault가 발생한다.
그 이후 4번 page가 참조되어 가장 먼저 들어온 1번 page가 swap out되고 4번 page가 할당된다.
1번 page가 재참조되어 1번 다음으로 빨리 들어왔던 2번 page를 swap out하고 1번 page를 할당한다.
가장 먼저 할당되었던 page를 swap out하면서 반복

2.5 LRU (Least Recently Used) Algorithm

LRU : 가장 오래 전에 참조된 것을 swap out 시키는 알고리즘

가장 오래전에 참조된 알고리즘을 swap out하기 때문에 swap out 되는 page의 인지도는 체크하지 않는다. (여러번 참조되었냐의 여부 확인 안함)

✔️ LRU (Least Recently Used) Algorithm 예시

[가정]

빨간색 숫자는 page fault가 발생한 page
연보라색 숫자는 메모리로 바로 참조되는 page

[예시]

1,2,3,4 번 page가 참조되어 page fault가 발생한다.
1번과 2번 page를 직접 메모리에서 참조한다.
5번 page가 page fault가 발생하여 오래전에 참조되었던 3번 page가 swap out 된다.
가장 오래전에 참조되었던 page를 swap out하면서 반복

2.6 LFU (Least Frequently Used) Algorithm

LFU: 참조 횟수(reference count)가 가장 적은 페이지를 지움

✔️ 최저 참조 횟수인 page가 여럿 있는 경우

LFU 알고리즘 자체에서는 여러 page 중 임의로 선정한다
성능 향상을 위해 가장 오래 전에 참조된 page를 지우게 구현할 수도 있다

✔️ 장단점

LRU처럼 직전 참조 시점만 보는 것이 아니라 장기적인 시간 규모를 보기 때문에 page의 인기도를 좀 더 정확히 반영할 수 있음
참조 시점의 최근성을 반영하지 못함
LRU보다 구현이 복잡함

✔️ LRU와 LFU 알고리즘 예제

[가정]

page frame은 4칸이 존재함
5번 page를 page fault 발생시켜야 하는 상황

[예시]

1번 페이지가 가장 먼저 할당되었고 1번 페이지는 총 4번 참조되었다.
1번 페이지 이후 2번 페이지가 할당되었고 2번 페이지는 총 3번 참조되었다.
2번 페이지 이후 3번 페이지가 할당되었고 3번 페이지는 총 2번 참조되었다.
마지막으로 4번 페이지가 할당되고 4번 페이지는 총 1번 참조되었다.

[결과]

LRU : 가장 오래전에 참조된 1번 page를 삭제함
LFU : 가장 최근에 할당되었음에도 적게 참조된 4번 page를 삭제함

2.8 Paging System에서 LRU, LFU 가능한가?

운영체제가 Page fault가 발생한 page를 물리적 메모리에 replace 한다. 그런데 비어있는 frame이 없을 경우 해당하는 알고리즘에 맞게 frame을 쫓아내야 하는데 이미 메모리에 해당 page가 존재할 경우 OS의 지원이 아닌 하드웨어 지원으로 주소변환이 일어나기 때문에 page의 참조 시간이나 page의 참조 횟수를 알 수 있는 방법이 없다. 즉 가상메모리 환경의 Page Fault 기법에서는 LRU, LFU 알고리즘을 사용할 수가 없다.

2.9 Clock Algorithm

LRU의 근사(approximation) 알고리즘

✔️ Clock Algorithm

여러 명칭으로 불림
- Second cahnge alogorithm
- NUR (Not Used Recently) 또는 NRU ( Not Recently Used)
Reference bit을 사용해서 교체 대상 페이지 선정 (circular list)
reference bit가 0인 것을 찾을 때까지 포인터를 하나씩 앞으로 이동
포인터 이동하는 중에 참조되지 않은 reference bit 1은 모두 0으로 바꿈
Reference bit이 0인 것을 찾으면 그 페이지를 교체
한 바퀴 되돌아와서도(=second chance) 0이면 그때에는 replace 당함
자주 사용되는 페이지라면 second change가 올 때 1
Clock algorithm의 개선
- reference bit과 modified bit (dirty bit)을 함께 사용
- reference bit → 1 최근에 참조된 페이지
- modified bit(=dirty bit) → 1 최근에 변경된 페이지 (I/O를 동반하는 페이지)
  - 메모리에서 write가 발생할 때 1로 세팅
  - page fault를 발생시킬 때 modified bit가 0인 page들을 먼저 쫓아내면 disk I/O 수행시간이 적어지는 장점이 있음

🌟 이미 메모리에 할당된 페이지를 참조할 때 reference bit을 변경하는 것은 OS가 아니라 하드웨어의 역할이다. 운영체제는 비트를 주기적으로 검사하여 reference bit이 0인 page를 replace 하는 역할을 한다.

3. Page Frame의 Allocation

💡 Allocation problem: 각 process에 얼마만큼의 page frame을 할당할 것인가?

✔️ Allocation의 필요성

메모리 참조 명령어 수행시 명령어, 데이터 등 여러 페이지 동시 참조
- 명령어 수행을 위해 최소한 할당되어야 하는 frame의 수가 있음
Loop를 구성하는 page들은 한꺼번에 allocate 되는 것이 유리함
- 최소한의 allcation이 없으면 매 loop 마다 page fault

✔️ Allocation Scheme

Equal allocation: 모든 프로세스에 똑같은 갯수 할당
Proportional allocation: 프로세스 크기에 비례하여 할당
Priority allocation: 프로세스의 priority에 따라서 다르게 할당

4. Global vs Local Replacement

✔️ Global replacement

Replace 시 다른 process에 할당된 frame을 빼앗아 올 수 있다
Process별 할당량을 조절하는 또 다른 방법
FIFO, LRU, LFU 등의 알고리즘을 global repacement로 사용시에 해당한다
Working set, PFF 알고리즘 사용

✔️ Local Replacement

자신에게 할당된 frame 내에서만 replacement
FIFO, LRU, LFU 등의 알고리즘을 process 별로 운영시

5. 다양한 캐싱 환경

✔️ 캐싱 기법

한정된 빠른 공간(=캐쉬)에 요청된 데이터를 저장해 두었다가 후속 요청시 캐쉬로부터 직접 서비스하는 방식
paging system 외에도 cache memory, buffer caching, Web caching 등 다양한 분야에서 사용됨

✔️ 캐쉬 운영의 시간 제약

교체 알고리즘에서 삭제할 항목을 결정하는 일에 지나치게 많은 시간이 걸리는 경우 실제 시스템에서 사용할 수 없음
Buffer caching이나 Web caching의 경우
- O(1)에서 O(log n) 정도까지 허용
Paging system인 경우
- page fault인 경우에만 OS가 관여함
- 페이지가 이미 메모리에 존재하는 경우 참조시각 등의 정보를 OS가 알 수 없음
- O(1)인 LRU의 list 조작조차 불가능

6. Thrashing

프로세스의 원활한 수행에 필요한 최소한의 page frame 수를 할당 받지 못한 경우 발생하는 현상

Page fault rate이 매우 높아짐
CPU utillization이 매우 낮아짐
OS는 MPD(Multiprogramming degree)를 높여아 한다고 판단
또 다른 프로세스가 시스템에 추가됨 (higher MPD)
프로세스당 할당된 frame의 수가 더욱 감소
프로세스는 page의 swap in / swap out으로 매우 바쁨
대부분의 시간에는 CPU가 한가함
low throughput

✔️ 대충 살펴봐도 프로세스 성능이 상당히 저하될 수 있는 현상이다. 이를 예방하기 위한 방법이 없을까?

있다 ! 앞서 설명한 Working set, PFF(Page-Fault Frequency) Scheme가 Thrashing 문제를 해결하기 위한 알고리즘이다.

6.1 Working-Set Model

✔️ Locality of reference

프로세스는 특정 시간 동안 일정 장소만을 집중적으로 참조한다.
집중적으로 참조되는 해당 page들의 집합을 locality set이라 한다.

✔️ Working-set Model

Locality에 기반하여 프로세스가 일정 시간 동안 원활하게 수행되기 위해 한꺼번에 메모리에 올라와 있어야하는 page들의 집합을 Working Set 이라고 정의한다.
Working Set 모델에서는 process의 working set 전체가 메모리에 올라와 있어야 수행되고 그렇지 않을 경우 모든 frame을 반납한 후 swap out (suspend)
Thrashing을 방지함
Multiprogramming degree를 결정함

6.2 Working-Set Alogorithm

✔️ Working set 결정 방법

Working set window를 통해 알아낸다
window size가 델타 인 경우
- 시각 t 에서의 working set WS (t)
  - Time interval [델타] 사이에 참조된 서로 다른 페이지들의 집합
- Working set에 속한 page는 메모리에 유지, 속하지 않은 것은 버림 (즉, 참조된 후 델타 시간 동안 해당 page를 메모리에 유지한 후 버림)

6.3 PFF (Page-Fault Frequency) Scheme

Page-fault rate의 상한값과 하한값을 둔다
- Page fault rate이 상한값을 넘으면 frame을 더 할당한다
- Page fault rate이 하한값 이하이면 할당 frame 수를 줄인다.
빈 frame이 없으면 일부 프로세스를 swap out 한다

7. Page Size의 결정

Page size를 감소시키면
- 페이지 수 증가
- 페이지 테이블 크기 증가
- Internal fregmentation 감소
- Disk transfer의 효율성 감소
  - Seek/rotation vs transfer
- 필요한 정보만 메모리에 올라와 메모리 이용이 효율적
  - Locality의 활용 측면에서는 좋지 않음

✔️ 현재 Trend

Larger page size

Reference

이화여자대학교 반효경 교수님 운영체제 강의

[운영체제 스터디] 불연속할당

Fri, 15 Apr 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

🗳️ Memory Management 2

1. Noncontiguous allocation(불연속할당)

불연속할당(noncontiguous allocation) 기법이란 하나의 프로세스가 물리적 메모리의 여러 위치에 분산되어 올라갈 수 있는 메모리 할당 기법을 말한다. 불연속할당 방식에는 하나의 프로그램을 분할하는 기준에 따라 동일한 크기로 나누어 메모리에 올리는 페이징 기법과, 크기는 일정하지 않지만 의미 단위(코드, 데이터, 스택 영역)로 나누어 메모리에 올리는 세그멘테이션 기법, 그리고 세그먼테이션을 기본으로 하되 이를 다시 동일 크기의 페이지로 나누어 메모리에 올리는 페이지드 세그먼테이션 기법 등이 있다.

1.1 Paging

페이징 기법은 프로세스의 가상 메모리를 동일한 크기의 Page로 잘라서 각 Page 별로 비어있는 물리적 메모리에 저장하는 방식을 말한다. 페이징 기법에서는 각 프로세스의 주소 공간 전체를 물리적 메모리에 한번에 올릴 필요없이 일부는 백킹스토어, 일부는 물리적 메모리에 혼재 시키는 것이 가능하다.

페이징 기법에서는 물리적 메모리를 페이지 크기와 동일한 프레임으로 나누어두기 때문에 앞서 설명한 동적 메모리 할당 문제가 발생하지 않는다. 비어있는 공간이 모두 동일한 크기여서 어떠한 위치에도 저장할 수 있기 때문이다. 하지만 이러한 특징은 복잡한 주소변환 절차를 필요로 한다.

✔️ 하나의 Page의 크기는 4KB

✔️ Paging 기법을 사용할 경우 해당 page의 **page table 주소와 논리적 주소를 물리적 메모리의 주소로 변환한다.

1️⃣ Paging 기법의 주소변환 절차는 어떻게 이뤄지나?

페이징 기법은 주소 변환이 페이지 단위로 이뤄져야 하기 때문에 조금 더 복잡한 주소변환 절차가 필요하다. 따라서 페이징 기법에서는 각각의 주소 변환을 위한 페이지 테이블을 가진다. 페이지 테이블은 프로세스가 가질 수 있는 페이지의 개수만큼 주소 변환 엔트리를 가지고 있으며, 엔트리는 페이지 번호와 페이지 오프셋으로 이루어져 있다. 추가로 페이지 테이블은 프로세스의 페이지 수 만큼 엔트리가 생성되기 때문에 큰 용량이 필요하여 메인 메모리에 저장된다.

1.2 Page Table

페이지 테이블이란 Page의 물리적 메모리 주소 변환을 하기 위한 자료구조이다. 페이지 갯수만큼 엔트리가 생성되기 때문에 많은 용량을 필요로 하여 메인 메모리에 저장된다. CPU가 물리적 주소에 접근하려면 Page table을 거쳐서 Page Frame 까지 도달해야 하는데, 둘 다 메인 메모리에 저장되어 있기 때문에 메모리에 두 번 접근하게 되는 오버헤드가 발생한다. Page table의 문제점을 해결하기 위한 방법을 알아보자

✔️ Page Table의 구성

Page-table base register (PTBR)

✔️ 페이지 테이블만 있었을 때, 물리적 메모리 주소에 닿기까지 2번의 메모리 접근이 필요하다. 첫번째 접근은 CPU → Page Table 접근 두번째 접근은 Page Table → Page frame 접근이다.

Page-table base register (PTBR)가 page table을 가리킴
- 메모리에 상주하고있는 page table의 시작위치
Page-table length register (PTLR)가 테이블 크기를 보관
모든 메모리 접근 연산에는 2번의 memory acess 필요
- page table 접근 1번, 실제 data/instruction 접근 1번
translation look-aside buffer (associative register or TLB)
- 속도 향상을 위해 사용되는 고속 lookup hardwore cache
- 메모리 접근 연산이 2번 이뤄지는 비효율적인 접근방식을 보완함
- page table에서 접근이 자주 이뤄지는 엔트리를 캐싱하고 있음
- CPU가 캐싱되어있는 페이지 주소를 찾을 경우 CPU → TLB → Physical Memory
- TLB에 존재하지 않을 경우 CPU → Page table(Physical Memory) → Physical Memory
- 물리적 페이지와 논리적 페이지 주소의 쌍으로 이뤄져있음

Associative registers(TLB) : 병렬 검색이 가능

TLB에는 page table 중 일부만 존재

Address translaction

page table 중 일부가 associative register에 보관되어 있음
만약 해당 page가 associative register에 있는 경우 곧바로 frame #을 얻음
그렇지 않은 경우 main memory에 있는 page table로 부터 frame #을 얻음
TLB는 context switch 때 flush (remove old entries)

1.3 Two-Level Page Table

속도는 느려지더라도 페이지 테이블의 크기를 줄이기 위한 방법이다.
이단계 테이블에서는 page table 자체를 page로 구성한다.
page table 자체를 page로 구성
사용되지 않는 주소 공간에 대한 outer page table의 엔트리 값은 null (대응하는 inner page table이 없음)
- 현대의 컴퓨터는 address space가 매우 큰 프로그램 지원 (최근에는 64bit 구성도 많음)
  - 32 bit address 사용 시: 2의 32승의 주소 공간이 필요하다 (4GB)
    - page size가 4K 시 1M개의 page table entry 필요
    - 각 page entry가 4B시 프로세스당 4M의 page table 필요
    - 그러나, 대부분의 프로그램은 4G의 주소 공간 중 지극히 일부분만 사용하므로 page table 공간이 심하게 낭비된다

🌟 이단계 페이지 테이블 예시

✔️ Logical Address (on 32-bit machine with $K page size)의 구성

20 bit의 page number
12 bit의 page offset

✔️ Page table 자체가 page로 구성되기 때문에 page Number는 다음과 같이 나뉜다

(각 page table entry가 4B)

10 - bit의 page number

10 - bit의 page offset

따라서, logical address는 다음과 같다

P1은 outer page table의 index이고

P2는 outer page table의 page에서의 변의(displacement)

✔️ 2단계 페이징에서의 Address-translation scheme

논리적 주소에서 outer table 의 index 번호를 찾는다.
outer table에서 P1값에 위치로 이동한 후 inner page table 엔트리의 위치 값을 가져온다.
outertable에서 inner page table로 이동한다.
inner table에서 P2값에 해당하는 엔트리로 이동한 후 저장된 물리적 페이지 프레임 주소를 얻게된다.

inner table의 크기는 4KB로 페이지의 크기와 동일하다.

이단계 테이블은 속도는 느리더라도 페이지 테이블의 공간을 줄이는 것이 목적인 반면에

여전히 inner table의 엔트리는 100만개 이상이 필요하다. 추가적으로 outer table 과 inner table로 구성되어 있어서 공간과 시간이 기존 page table에 비해서 더 손해이다.

하지만 그럼에도 이단계 테이블을 사용하는 이유는 ?!

프로그램을 구성하는 공간에서 사용되는 페이지의 수는 얼마 안되지만 페이지 테이블은 실제 사용하는 페이지의 수가 적더라도 논리적 메모리의 최대 크기만큼 엔트리를 생성한다. 그런데 이단계 페이지 테이블은 outer page table은 논리적 메모리 크기만큼 생성하지만 실제 사용이 되지않는 엔트리는 Null로 할당하고 inner table의 엔트리를 생성하지 않는다.

실제 프로그램은 프로그램이 사용되지 않더라도 4KB의 메모리 공간을 전부 채운다.

1.4 Multilevel Paging and Performance

주소공간이 더 커지면 다단계 페이지 테이블이 필요하다 다단계 테이블은 단계별로 페이지 테이블이 메모리에 존재하므로 logical address의 physical address 변환에 더 많은 메모리 접근이 필요하다 하지만 이러한 문제점은 TLB를 통하여 접근시간을 줄일 수 있다.

✔️ 4단계 페이지 테이블을 사용하는 경우

메모리 접근 시간이 100ns, TLB 접근 시간이 20ns이고
TLB hit ratio가 98%인 경우
- effective memory access time = 0.98 x 120 + 0.02 x 520 = 128 nanoseconds
  - 결과적으로 주소변환을 위해 28ns만 소요한다.

1️⃣ Memory Protection

Page table의 각 entry 마다 아래의 bit를 둔다.

✔️ Protection bit

Page에 대한 접근 권한 (read/write/read-only)
1. 페이지 테이블은 프로세스 마다 각각 생성되므로 다른 프로세스가 Page에 접근하는 것을 막기위한 것이 아니라 연산에 대한 접근 권한을 의미한다
2. 예를 들면 코드영역은 실행도중 변경되면 안되므로 read-only 권한을 부여하고 데이터나 스택영역에는 read, write 권한을 부여한다.

✔️ Valid (v) / Invalid (i) Bit in a Page Table

valid-invalid bit
- Valid (v)
  - Page 0을 예로 들면 Page 0이 실제로 2의 주소를 가진 Page frame에 할당된 것을 의미함 (실제로 페이지가 물리적 메모리에 존재한다)
- Invalid (i)
  - 해당 주소의 frame에 유효한 내용이 없을을 의미한다 (접근 불허)
    1. 프로세스가 그 주소 부분을 사용하지 않는 경우
    2. 해당 페이지가 메모리에 올라와 있지 않고 swap area에 있는 경우

1.4 Inverted Page Table (역방향 페이지 테이블)

Page table은 실행되는 프로세스마다 독립적으로 생성되기 때문에 메모리를 많이 차지한다. 하지만 Inverted Page Table은 기존 Page table과 다르게 모든 프로세스가 Inverted Page Table을 참조하게 하는 방식이다. Inverted Page Table은 Page Frame 기준으로 엔트리를 생성한다.

💡 Page table이 매우 큰 이유

모든 process 별로 그 logical address에 대응하는 모든 page에 대해 page table entry가 존재
대응하는 page가 메모리에 있든 아니든 간에 page table에는 entry로 존재

✔️ Inverted page table (역방향 페이지 테이블)

Page frame 하나당 page table에 하나의 entry를 둔 것 (system-wide)
메모리 공간을 확보하기 위해 사용 됨
역방향 페이지 테이블의 엔트리는 논리적인 페이지 번호와 Pid를 저장하고 있음
단점
- 테이블 전체를 탐색해야 함
조치
- associative register 사용 (expensive)

✔️ 주소변환과정

Page Table에서 pid와 page number로 해당 정보가 저장된 엔트리의 위치를 찾는다
찾아진 엔트리가 몇번째 위치에 존재하는지 확인하고 해당 주소의 페이지 프레임을 찾는다.
각 page tavle entry는 각각의 물리적 메모리의 page frame이 담고 있는 내용 표시 (process-id, process의 logical address)

1.5 Shard Page

✔️ Shared code

Re-entrant Code (=Pure code)
- read-only로 하여 프로세스 간에 하나의 code만 메모리에 올림 (eg, text, editors, compliers, winodw, systems)
Shared code는 모든 프로세스의 logical address space에서 동일한 위치에 있어야 함 (동일한 page number를 가져야함)
Private code and data
- 각 프로세스들은 독자적으로 메모리에 올림
- Private data는 logical address space의 아무 위치에 할당되어도 무방

✔️ 예를 들면?

서로 다른 프로세스 P1, P2, P3가 동일한 코드를 사용하다면 코드를 프로세스마다 각각 올리는 것은 비효율 적이다. 즉 공유할 수 있는 코드는 별도로 올리는 것이 아니라 같은 Frame으로 매핑하여 한칸의 Page Frame 만을 할당하는 것이 효율적이라고 할 수 있다. 하지만 모든 프로세스가 같은 코드영역을 참조하고 있기 때문에 공유하는 코드영역은 read-only로 설정해야한다. 그리고 공유코드는 프로세스가 다르더라도 동일한 logical address를 가져야한다.

2. Segmentation

프로그램은 의미 단위인 여러 개의 segment로 구성

작게는 프로그램을 구성하는 함수 하나하나를 세그먼트로 정의

크게는 프로그램 전체를 하나의 세그먼트로 정의 가능

일반적으로는 code,data,stack 부분이 하나씩의 세그먼트로 정의됨

Paging 방식처럼 동일한 크기로 분할하는 것이 아니라 동적 메모리 할당 문제가 발생할 수 있다.

✔️ Segment는 다음과 같은 logical unit 들

main()
function
global variables
stack
symbol table, arrays

2.1 Segmentation Architecture

✔️ Logical address 구성

segment-number, offset

✔️ Segment table

each table entry has:
- base - starting physical address of the segment
- limit - length of ther segment

✔️ Segment-table base register (STBR)

물리적 메모리에서의 segment table의 위치

✔️ Segment-table length register (STLR)

프로그램이 사용하는 segment의 수
- segment number의 크기는 STLR의 범위를 넘어서면 안됨

✔️ Segmentation의 주소변환

논리주소의 SegmentNumber가 STLR보다 작은 값인지 확인하고 만약 더 큰 값을 요청했다면 trap을 발생시킨다.
값이 STLR 범위에 포함될 경우 offset의 값이 segment의 메모리 범위안에 포함되는 지 확인한다
포함되는 값이면 Segment 시작위치와 Offset을 더해, 물리적 메모리 주소의 위치를 찾는다.

✔️ Sharing of Segments

첨부된 이미지를 보면 segment0은 프로세스 P1, P2가 서로 공유하여 사용하고 있다. 하나의 세그먼트를 여러개의 프로세스가 사용할 경우 각 프로세스들은 segment0에 대해 동일한 논리적메모리 주소를 가져야한다. 반면 각 프로세스마다 따로 사용하는 private segment의 경우 각자 다른 물리적 메모리 주소에 위치해있기 때문에 프로세스마다 논리적 메모리 주소도 동일하지 않아도 된다.

2.3 Paged Segmentation

Paged Segmentation은 Segmentation과 Paging 기법의 장점만을 가져와서 각 기법의 단점들을 보완한 방식이다.

무슨 말이냐 하면, Segmentation의 의미있는 단위로 프로그램을 나누는 방식과 Paging 기법의 동일한 크기로 프로그램을 나눈다는 장점이 합쳐진 것이다.

Paged Segmentation기법에서는 segment가 임의의 길이를 가진 것이 아닌 동일한 크기의 page들의 집합으로 구성되어 있다. 물리적 메모리에 적재하는 단위도 page 단위이기 때문에 외부조각 문제가 발생하지 않는다. 기존 Segmentation 방식과의 차이점은 segment table entry가 segment의 base address를 가지고 있는 것이 아니라 segment를 구성하는 page table의 base address를 가지고 있다는 것이다.

✔️ Paged Segmentation

Paged Segmentation 기법에선 주소 변환을 위해 외부의 세그먼트 테이블과 내부의 세그먼트 테이블을 이용한다.
하나의 세그먼트가 여러개의 페이지 테이블로 구성되기 때문에 각 세그먼트마다 페이지 테이블을 가진다.

✔️ Paged Segmentation의 주소변환 과정

논리적 주소의 상위 비트인 세그먼트 번호를 통해 세그먼트 테이블의 해당 항목으로 접근한다. (논리적 주소에서는 세그먼트 번호와 offset이 존재)
1. 접근한 세그먼트 항목에는 세그먼트 길이와 그 세그먼트의 페이지 테이블 시작 주소가 들어 있다.
세그먼트 길이값과 논리적 주소 하위 비트인 offset 값을 비교하고 offset값이 더 크다면 유효하지 않은 접근이므로 트랩을 발생시킨다.
그렇지 않은 경우 offset 값을 다시 상위 비트와 하위비트로 나눈다. (상위 비트는 세그먼트 내의 페이지 번호로 사용하고 하위 비트는 페이지 내의 변위로 사용한다)
세그먼트 테이블에 저장된 해당 세그먼트를 위한 페이지 테이블의 시작 위치를 확인했으므로 그 위치에서 페이지 번호만큼 떨어진 페이지 테이블 항목으로부터 물리적 메모리의 페이지 프레임 위치를 얻게 된다.
해당 페이지 프레임 위치에서 offset의 하위 비트값인 페이지 내 변위만큼 떨어진 곳이 물리적 메모리 주소이다.

💡 Memory Management에서 운영체제의 역할은?

없다. 앞서 설명한 내용들은 운영체제가 아닌 하드웨어들의 역할이다. 왜냐하면 프로세스가 CPU를 할방받으면서 메모리에 접근하는 것은 운영체제가 도움을 주는 것이 아니기 때문이다. 만약 메모리에 접근할 때 사용자 프로그램이 운영체제를 필요로하게 된다면, 사용자 프로그램이 메모리에 접근을 시도할 때마다 사용자 모드에서 커널모드로 변경되는 매우 비효율적인 작업이 진행될 것이다. 사용자 프로그램이 운영체제의 도움이 필요할 때는 메모리 접근이 아닌 I/O device 접근이다.

Reference

이화여자대학교 반효경 교수님 운영체제 강의

[운영체제 스터디] 메모리 관리 - 논리적 주소와 물리적 주소

Fri, 15 Apr 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

🗳️ Memory Management 1

1. 논리적 주소와 물리적 주소

✔️ 논리적 주소란(Logical address)?

프로세스마다 독립적으로 가지는 주소 공간
각 프로세스마다 0번지부터 시작
CPU가 보는 주소는 logical address이다.

✔️ 물리적 주소란(Logical address)?

실제 메모리에 올라가는 위치

1.2 주소 바인딩(Address Binding)

프로세스의 물리적 메모리 주소를 결정하는 것

Symbolic Address → Logical Address → Physical Address

🌟 Symbolic Address? 프로그래머가 사용하는 심볼릭한 주소

✔️ 사용자 프로그램

logical address만을 다룬다
실제 physical address를 볼 수 없으며 알 필요가 없다

✔️ Compile time binding

물리적 메모리 주소(physical address)가 컴파일 시 알려짐
시작 위치 변경시 재컴파일
컴파일러는 절대 코드(absolute code) 생성

❗ 논리적 메모리 주소가 물리적 메모리의 주소가 되므로 여유있는 메모리 공간이 있어도 고정적인 메모리 주소를 갖기 때문에 비효율적

✔️ Load time binding

프로그램 실행 시 물리적 주소가 결정되는 방식
컴파일러가 재배치 가능한 코드를 생성한 경우 발생 가능

✔️ Run time binding

프로그램 실행 도중 물리적 메모리 주소가 변경될 수 있는 방식
CPU가 주소를 참조할 때마다 binding을 점검해야 함 (address mapping table)
하드웨어적인 지원이 필요함
- (base and limit registers, MMU)
현대에서 주로 사용되는 방식

✔️ Memory-Management Unit (MMU)?

MMU
- logical address를 physical address로 매핑해 주는 Hardware device
MMU scheme
- 사용자 프로세스가 CPU에서 수행되며 생성해내는 모든 주소값에 대해 base register (=relocation register)의 값을 더한다

💡 운영체제 및 사용자 프로세스 간의 메모리 보호를 위해 사용하는 레지스터

relocation register
- 프로세스의 물리적 메모리 시작위치를 저장한다 (접근할 수 있는 물리적 메모리 주소의 최소값)
limit register
- 물리적 메모리 주소의 한계영역을 지정하기 위해 프로그램의 최대 크기를 저장한다.
- 논리적 주소의 범위 (프로그램의 최대 크기)
  - 예를 들어 P1의 시작 주소가 14000이고 프로그램의 크기가 3000일 때 P1은 14000~17000 사이만 접근할 수 있다.

2. Some Terminologies

1. Dynamic Loading

프로세스 전체를 메모리에 미리 다 올리는 것이 아니라 해당 루틴이 불려질 때 메모리에 load하는 것
memory utilization의 향상
가끔식 사용되는 많은 양의 코드의 경우 유용
- ex) 오류 처리 루틴
운영체제의 특별한 지원 없이 프로그램 자체에서 구현 가능(OS는 라이브러리를 통해 프로그래머를 지원함)

2. Overlays

메모리에 프로세스의 부분 중 실제 필요한 정보만을 올림
프로세스의 크기가 메모리보다 클 때 유용
운영체제의 지원없이 사용자에 의해 구현
작은 공간의 메모리를 사용하던 초창기 시스템에서 수작업으로 프로그래머가 구현
- Manual Overlay
- 프로그래밍이 매우 복잡함
- Dynamic Loading과 비슷한 역할을 하지만 OS의 지원이 하나도 없다는 점에서 차이가 있음

3. Dynamic Linking

Linking을 실행 시간(execution time)까지 미루는 기법

✔️ Static Linking

라이브러리가 프로그램의 실행 파일 코드에 포함됨
실행 파일의 크기가 커짐
동일한 라이브러리를 각각의 프로세스가 메모리에 올리므로 메모리 낭비
- ex) printf를 호출하는 n개의 프로세스가 있으면 동일한 라이브러리여도 각각 printf 함수의 라이브러리를 메모리에 올리게 됨

✔️ Dynamic linking

라이브러리가 실행시 연결(link)됨
라이브러리 호출 부분에 라이브러리 루틴의 위치를 찾기 위한 stub이라는 작은 코드를 둠
라이브러리가 이미 메모리에 있으면 그 루틴의 주소로 가고 없으면 디스크에서 읽어옴
운영체제의 도움이 필요함
Dynamic linking을 지원하는 라이브러리를 shared library 라고 함
- window → DLL
- linux → shared object

4. Swapping

프로세스를 일시적으로 메모리에서 backing store로 쫓아내는 것

Backing store(=swap area)?

디스크

많은 사용자의 프로세스 이미지를 담을 만큼 충분히 빠르고 큰 저장 공간

✔️ Swap in / Swap out

일반적으로 중기 스케줄러(swapper)에 의해 swap out 시킬 프로세스 선정
priority-based CPU scheduling algorithm
- CPU 우선순위가 낮은 프로세스를 swapped out 시킴
- CPU 우선순위가 높은 프로세스를 메모리에 올려놓음
Complie time 혹은 load time binding에서는 다른 메모리 공간이 비어있더라도 원래 메모리 위치로 swap in 해야 함
Execution time binding에서는 추후 빈 메모리 영역 아무 곳에나 올릴 수 있음
swap time은 대부분 transfer time(swap되는 양에 비례하는 시간)임
원칙적으로 프로세스 전체가 메모리에서 쫓겨나는 것을 Swap out 이라고 하지만 프로세스 일부분이 쫓겨나는 것도 swap out 이라고 부르기도 한다.

3. 물리적 메모리 관리

✔️ 메모리는 일반적으로 두 영역으로 나눠어서 사용 됨

OS 상주 영역(커널)
- interrupt vector와 함께 낮은 주소 영역 사용
사용자 프로세스 영역

✔️ 사용자 프로세스 영역의 할당 방법

Contiguous allocation(연속할당)
- 각각의 프로세스가 메모리의 연속적인 공간에 적재되도록 하는 것
  - Fixed partition allocation
  - Variable partition allocation
Noncontiguous allocation(불연속할당)
- 현대 시스템의 사용 방법
- 하나의 프로세스가 메모리의 여러 영역에 분산되어 올라갈 수 있음
  - Paging
  - Segmentation
  - Paged Segmentation

✔️ 외부조각과 내부조각

External fragmentation(외부 조각)
- 프로그램 크기보다 분할의 크기가 작은 경우
- 아무 프로그램에도 배정되지 않은 빈 곳인데도 프로그램이 올라갈 수 없는 작은 분할
Internal Fragmentation(내부 조각)
- 프로그램 크기보다 분할의 크기가 큰 경우
- 하나의 분할 내부에서 발생하는 사용되지 않는 메모리 조각
- 분할에 배정된 프로그램보다 분할의 크기가 더 커서 생기는 사용되지 않는 메모리 공간

4. Contiguous allocation(연속할당)

4.1 Fixed partition(고정분할)

물리적 메모리를 몇 개의 영구적 분할(partition)으로 나눔
분할의 크기가 모두 동일한 방식과 서로 다른 방식이 존재
분할당 하나의 프로그램 적재
융통성이 없음
- 동시에 메모리에 load되는 프로그램의 수가 고정됨
- 최대 수행 가능 프로그램 크기 제한
internal fragmentation(=내부조각) 과 external fragmentation(=외부조각) 발생

4.2 Variable partition(가변분할)

프로그램의 크기를 고려해서 할당
분할의 크기, 개수가 동적으로 변함
기술적 관리 기법 필요
external fragmentation(=외부조각) 발생

1️⃣ Hole

가용 메모리 공간
다양한 크기의 hole들이 메모리 여러 곳에 흩어져 있음
프로세스가 도착하면 수용가능한 hole을 할당
운영체제는 다음의 정보를 유지
- a) 할당 공간 b) 가용 공간(hole)

2️⃣ Dynamic Storage-Allocation Problem

가변 분할 방식에서 size n인 요청을 만족하는 가능 적절한 hole을 찾는 문제
First-fit
- Size가 n 이상인 것 중 최초로 찾아지는 hole에 할당
- 셋 중 오버헤드가 가장 적음
Best-fit
- Size가 n 이상인 가장 작은 hole을 찾아서 할당
- Hole들의 리스트가 크기순으로 정렬되지 않은 경우 모든 hole의 리스트를 탐색해야함
- 많은 수의 아주 작은 hole들이 생성됨
Worst-fit
- 가장 큰 hole에 할당
- 역시 모든 리스트를 탐색해야 함
- 상대적으로 아주 큰 hole들이 생성됨

🌟 First-fit과 Best-fit이 Worst-fit보다 속도와 공간 이용률 측면에서 횩하적인 것으로 알려짐 (실험적 결과)

3️⃣ Compaction

external fragmentation 문제를 해결하는 한 가지 방법
사용 중인 메모리 영역을 한군데로 몰고 hole들을 다른 한 곳으로 몰아 큰 block을 만드는 것
전체 프로그램 바인딩과 관련되어 있기 때문에 비용이 많이 듬
최소한의 메모리 이동으로 compaction하는 방법 (매우 복잡한 문제)
Compcation은 프로세스의 주소가 실행 시간에 동적으로 재배치 가능한 경우에만 수행될 수 있다.
- Runtime binding이 지원되어야 사용 가능함

Reference

이화여자대학교 반효경 교수님 운영체제 강의

[네트워크 스터디] Chapter_01 웹 브라우저가 메세지를 만든다

Thu, 14 Apr 2022 00:00:00 +0900

📗 Chapter_01 웹 브라우저가 메세지를 만든다

1. HTTP 리퀘스트 메세지를 작성한다

1️⃣ URL

✔️ HTTP URL 의 구성

ex ) http://user:password@www.example.co.kr:80/dir/file1.html

프로토콜 → http
사용자명 (생략 가능) → user
패스워드 (생략 가능) → password
웹 서버의 도메인명 → www.example.co.kr
포트번호 (생략 가능) → 80
파일의 경로명 → /dir/file1.html

💡 HTTP 의 경우 기본 포트는 80이고 HTTPS의 기본 포트는 443이다.

✔️ URL 은 여러 종류가 있다.

URL은 http로 구성되어있는 것 말고도 ftp: 나 mailto: 같은 다양한 프로토콜의 URL이 존재한다. 이유는, 브라우저는 웹 서버에 엑세스하는 클라이언트로만 사용하는 것이 아니라 파일을 다운로드/업로드하는 FTP의 기능이나

메일클라이언트의 기능도 가지고 있기 때문이다. 브라우저는 URL을 토대로 여러개의 기능 중 어느것을 사용하여 데이터에 엑세스하면 될지를 판단한다.

✔️ 다양한 URL의 구성

이와같이 쓰는 방법은 다양하지만 모든 URL에는 하나의 공통점이 있다. URL 맨 앞에 있는 프로토콜에 따라서 액세스 하는 대상이 달라진다는 것이다.

예를 들어 액세스 대상이 웹 서버라면 HTTP 프로토콜을 사용하고, FTP 서버라면 FTP, 메일을 송신할 때는 mailto 프로토콜을 사용하면 된다.

2️⃣ 브라우저의 URL 해독 방식

웹 서버에 보내는 리퀘스트 메세지를 작성하기 전에 URL을 해독한다. 아래 내용은 브라우저가 웹 서버에 엑세스하는 경우를 예로들어 설명한다.

URL을 요소별로 분리하여 나열한 것은 아래와 같다.

[http://www.example.co.kr](http://user:passwork@www.cyber.co.kr):80/dir/file1.html
[ http ]: + [ // ] + [ 웹 서버명 ] + [ / ] + [ 디렉토리명 ] +[ / ] + .... + [ 파일명 ]   

http는 앞서 설명한 프로토콜이 되는 것이고 //는 나중에 이어지는 문자열이 서버의 이름임을 나타낸다.

웹 서버명 다음에 이어지는 것은 서버에 파일이 저장된 위치인데 이는 생략이 가능하다.

✔️ 파일명을 생략한 경우

ex) http://www.example.co.kr

예시 url은 파일명을 생략했을 때의 url이다. 파일명을 생략하면 서버가 어느 파일에 액세스해야 하는 지 알 수 없다.

그래서 이와같은 문제를 대비하여 서버에서 파일명이 생략되었을 때 액세스할 default 파일을 설정해둔다. 대부분의 서버는 index.html 이나 default.html 이라는 파일명으로 설정해둔다.

💡 브라우저가 가장 먼저 하는 일은 URL 해독이다.

3️⃣ HTTP의 기본 개념

Hyper-Text Transfer Protocol(HTTP)란 지정된 규약을 지켜 웹 서버와 데이터를 주고받는 서버/클라이언트 모델을 따르는 비연결성 & 무상태 프로토콜이다.

애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. HTTP 패킷에는 여러 메타데이터와 성공 실패 정보가 담겨있으므로 서버와 클라이언트가 원활하게 대화할 수 있다.

💡 비연결성

연결을 유지하지 않는 것 특정한 옵션을 주면 일정시간동안 연결을 유지할 수는 있다.

💡 무상태

서버가 클라이언트의 상태를 보존하지 않는 것 매번 요청에 모든 상태값들을 전달해줘야 함 상태를 유지해줘야 할 경우 쿠키나 세션을 사용 함

✔️ HTTP Reuqest 패킷 구성

HTTP 요청 패킷은 크게 요청라인, 메세지 정보, 본문으로 나눌 수 있다.

요청라인 → HTTP Method, URL, HTTP 버전
메세지 정보 → 해당 요청에 대한 메타데이터를 담고있는 공간
본문(body) → 해당 요청의 실제 내용. POST가 아니여도 body를 사용할 수 있지만, 주로 Body를 사용하는 메소드는 POST이다.

✔️ HTTP Response 패킷 구성

HTTP 응답 패킷은 크게 상태라인, 메세지 정보, 본문으로 나눌 수 있다.

상태라인 → HTTP Method, 버전, 응답코드
- 응답코드는 주로 권한과 서버에러, 클라이언트에러 등으로 나눠서 성공과 실패 여부를 판단하는데에 사용된다,
메세지 정보 → 해당 응답에 대한 메타데이터를 담고있는 공간
본문(body) → 요청의 Body와 일반적으로 동일하다. body 존재할 수도 있고 존재하지 않을수도 있다. 가장 많이 사용되는 Body의 데이터 타입은 JSON(JavaScript Object Notation)이다.

✔️ HTTP Method

HTTP 메소드를 정리한 표이다. 버전마다 지원되는 메소드가 다르다.

메소드	의미
GET	지정한 정보를 도출할 때 사용된다. 파일의 경우 해당 파일의 내용을 되돌려보낸다.
POST	클라이언트에서 데이터를 body에 담아 송신할 때 사용된다.
PUT	URI로 지정한 서버의 파일을 치환한다. 파일이 없는 경우 새로 등록한다.
DELETE	URL로 지정한 서버의 파일을 삭제한다.
PATCH	리소스의 일부분만을 수정하는데에 쓰인다.
OPTION	통신 옵션을 통지하거나 조사할 때 사용된다.
HEAD	GET과 거의 같지만 데이터의 내용을 돌려보내지 않고 HTTP 메세지 헤더만을 반송한다. 속성 정보를 조사할 때 사용된다.
TRACE	서버측에서 받은 리퀘스트 라인과 헤더를 그대로 클라이언트에 반송한다. 프록시 서버 등을 사용하는 환경에서 리퀘스트가 치환되는 상태를 조사할 떄 사용된다.
CONNECT	암호화한 메세지를 프록시로 전송할 때 이용된다.

✔️ HTTP 간단한 통신과정 예시

웹서버에 특정 리소스를 얻기 위해 URI와 헤더에 요청에 필요한 정보를 담아 서버에 전송한다.
해당 리소스가 존재하면 응답 헤더에 필요한 정보를 담아서 보내거나 바디에 해당 요청 데이터를 전송한다.

🌟 실제로 요청과 응답 사이에 검증절차나 여러가지 일들이 일어나지만 자세한 내용은 생략하겠다.

2. 웹 서버의 IP 주소를 DNS 서버에 조회한다

HTTP 메세지를 만드는 것에 성공하면 이것을 OS에 의뢰하여 액세스 대상의 웹 서버에게 송신한다.

브라우저는 URL을 해독하거나 HTTP 메세지를 만들 수는 있지만 메세지를 네트워크에 송출하는 기능은 없으므로 OS에 의뢰하는 것이다.

이때 URL 안에 쓰여있는 서버의 도메인 명에서 IP 주소를 조사해야하는데, 이는 OS에서 송신을 의뢰할때는 도메인명이 아니라 IP 주소로 메세지를 받을 상대를 지정해야하기 때문이다.

✔️ 도메인명과 IP 주소를 구분하여 사용하는 이유

TCP/IP 네트워크는 IP 주소로 통신 상대를 지정하므로 IP주소를 모르는 상대에게 메세지를 전달할 수 없다. 이러한 이유 때문에 도메인 명과 IP 주소를 구분하는 것이다. 웹 브라우저는 Socket 라이브러리를 사용하여 도메인 명으로 IP 주소를 조회한다. 그렇다면 URL 안에서는 서버명이 아니라 IP 주소를 사용하는 것이 더 효율적이라는 생각이 들 수 있다. 실제로 서버명 대신에 IP 주소를 사용해도 올바르게 작동한다.그렇지만 기억하기 어렵다는 단점이 있다. 실행 효율 관점에서 바라보면 IP 주소대신 도메인명으로 사용하는 것이 좋은 방법이라고 할 수 없다. IP 주소는 32비트로 4바이트에 해당하는 개수밖에 없지만, 도메인 명은 수십 바이트 부터 최대 255 바이트 까지 존재한다. 그러면 그만큼 라우터가 부하되어 데이터를 운반하는 동작에 더 많은 시간이 걸릴 것이다. 하지만 이름을 알면 IP 주소를 알 수 있다거나 IP 주소를 사용하면 이름을 알 수있다는 원리를 이용하여 양쪽의 차이를 해소한 DNS가 라우터 부하의 문제점을 해결해준다.

✔️ Socket 라이브러리의 IP 주소 조회

웹 브라우저는 Socket 라이브러리의 도움을 받아 DNS서버에서 도메인명의 IP 주소를 조회할 수 있다.

DNS 서버에서 조회한다는 것은 DNS 서버에 메세지를 보내고 반송되는 응답 메세지를 받는 것이다. 이것은 DNS 클라이언트로 동작한다고 말할 수 있다. DNS 클라이언트에 해당되는 것을 DNS 리졸버(=리졸버)라고 한다.

DNS 원리를 이용하여 IP 주소를 조사하는 것을 네임 리졸루션 (name resolution) 이라고 하는데 리졸루션을 수행하는 것이 리졸버이다.

💡 Socket 라이브러리

OS를 이용하여 네트워크의 기능을 호출하기 위한 프로그램의 부품집

✔️ 리졸버 내부의 작동

✔️ 리졸버를 이용하여 DNS 서버를 조회한다.

리졸버의 프로그램명(gethostbyname)과 웹 서버의 이름을 쓰기만 하면 리졸버를 호출할 수 있다.

브라우저 애플리케이션이 Socket 라이브러리의 리졸버를 호출한다. 이때 gethostbyname에 웹서버 이름을 전달한다.
리졸버가 DNS 서버에 조회 메세지를 보낸다. 메세지 송신 동작은 OS 내부의 프로토콜 스택을 호출하여 수행한다.
DNS 서버에서 돌아온 응답 메세지를 수신한다.
응답 메세지에서 IP 주소를 추출하고 메모리 영역에 저장한 뒤 애플리케이션으로 돌아간다.

🌟 DNS 서버에 메세지를 송신할 때도 DNS 서버의 IP 주소가 필요한데, 이는 컴퓨터의 TCP/IP 설정 항목의 하나로 컴퓨터에 미리 설정되어 있다.

3. 전 세계의 DNS 서버가 연대한다

1️⃣ DNS 서버의 기본동작

DNS 서버의 기본 동작은 클라이언트에서 조회 메세지를 받고 조회의 내용에 응답하는 형태로 정보를 회답하는 일이다.

✔️ 조회 메세지 구성

이름
- 서버의 메일 배송 목적지와 같은 이름, 도메인 명
클래스
- 네트워크 종류를 검토하기위해 사용되는 것 현재는 인터넷 외의 네트워크는 소멸되었기 때문에 항상 인터넷을 나타내는 IN 값이 전달된다
타입
- 이름에 어떤 타입의 정보가 지원되는지를 나타낸다. 타입이 A이면 이름에 IP 주소가 지원되는 것을 나타내고 MX이면 이름에 메일 배송 목적지가 지원된다는 것을 나타낸다. 타입에 따라 클라리언트에 회답하는 정보의 내용이 달라진다.

이름이 www.example.com 인 서버의 IP 주소를 조사할 때 클라이언트는 다음과 같은 메세지를 보낸다.

해당 메세지를 수신했을 때 DNS가 어떠한 동작을 하는지 알아보자

[요청 메세지 예시 ]

이름 = www.example.com
클래스 = IN
타입 = A

[DNS 서버 내부 등록 정보 예시]

이름	클래스	타입	클라이언트에 회답하는 항목
www.example.com	IN	A	192.168.2.5
example.com	IN	MX	192.168.2.6

[DNS 서버의 동작]

DNS가 메세지를 수신하면 DNS 서버는 이름, 클래스, 타입의 값이 일치하는 데이터를 찾는다.
일치하는 데이터가 있으면 요청 값에 맞는 데이터를 클라이언트에게 전송한다. (예제를 기준으로 하면 192.168.2.5)

💡 DNS 서버는 서버에 등록된 도메인명과 IP 주소의 대응표를 조사하여 IP 주소를 회답한다.

2️⃣ 도메인의 계층

인터넷에선 막대한 수의 서버가 존재하기 때문에 모든 도메인 명을 하나의 DNS 서버에 등록하는 것은 불가능하다.

이러한 문제점은 정보를 분산시켜 다수의 DNS 서버에 등록하는 방식으로 해결할 수 있다. 다수의 DNS 서버는 계층적으로 구성되어있는데, 이는 조회 메세지를 수신한 DNS 서버에 해당 정보가 등록되어 있지 않아도 계층적으로 연대하고 있는 다른 DNS 서버에서 찾을 수 있다.

DNS 서버에 등록된 모든 정보는 모든 도메인명이라는 계층적 구조를 가진 이름이 붙여져 있다. DNS에서 취급하는 이름은 www.example.com 처럼 점으로 구분되어 있는데, 점으로 게층을 구분한다. 오른쪽에 위치한 것이 상위 계층이다. 계층구조와 같은 형태로 DNS 서버가 배치되며, 각 계층은 각자의 DNS 서버에 저장된다.

[계층 구조 예시]

URL → www.example.com

오른쪽에 위치한 것이 상위 계층이다.

com
- example
  - www

✔️ 담당 DNS 서버를 찾아 IP 주소를 가져온다

인터넷에는 DNS 서버가 수만 대가 있으므로 닥치는 대로 이를 뒤지면서 해당 도메인의 IP를 찾을 수는 없다.

그래서 다음과 같은 방법으로 이를 해결한다.

[예시]

URL → www.example.com

예시 URL 기준으로 최상위 도메인은 com이다. 하지만 실제로 URL은 com이나 kr 위에 루트 도메인이 존재한다. 루트 도메인은 com이나 kr같은 도메인 명이 존재하지 않기 때문에 보통 도메인을 쓸 때는 이것을 생략한다. 명시적으로 www.example.com. 처럼 URL 끝에 마침표를 찍기도 하지만 보통은 그렇게 사용하지 않는다.

하위의 도메인을 담당하는 DNS 서버의 IP 주소를 상위의 DNS 서버에 등록한다.
상위의 DNS 서버를 또 그 상위의 DNS 서버에 등록한다.
상위의 DNS 서버가 존재하면 이를 반복한다.

💡 이러한 방식은 상위 DNS 서버에서 하위의 DNS 서버의 IP 주소를 알 수 있다. (루트 도메인을 모든 DNS 서버에 등록하면 루트 도메인의 모든 하위 DNS 서버를 조회할 수 있음)

[IP 조회]

가장 가까운 DNS 서버에게 해당 도메인 명의 IP를 요청한다.
IP가 등록되어있지 않을 경우 루트 도메인 서버에게 해당 IP를 요청한다.
루트 도메인에도 해당 IP가 등록되지 않았을 경우 하향식으로 접근하여 IP를 찾을 때까지 하위 도메인 서버에 해당 IP 정보를 요청한다.

💡 앞서 설명한 내용은 기본이 되는 동작을 설명한 것으로 현실의 인터넷과 모든 동작이 일치하진 않는다. 현실의 인터넷은 한 대의 DNS 서버에 복수의 DNS 서버를 등록할 수 있으므로 한 도메인에 한대씩 DNS 서버가 존재한다고 단정할 수 없다.

3️⃣ DNS 서버는 캐시 기능으로 빠르게 회답할 수 있다.

DNS 서버는 한번 조사한 도메인 명을 캐싱할 수 있다. 요청받은 도메인 명이 캐싱되어 있으면 캐싱되어 있는 정보를 전달한다. 정보가 없을 경우에도 캐싱하기 때문에 정보가 존재하지 않는 다는 것도 빠르게 회답할 수 있다. 하지만 캐시된 정보가 변경될 수도 있으므로 캐시안에 저장된 정보를 올바르다고 단언할 수는 없다.

4. 프로토콜 스택에 메시지 송신을 의뢰한다

IP 주소를 조사를 마치면 액세스 대상 웹 서버에 메세지를 송신하도록 OS 내부 프로토콜 스택에 의뢰한다.

이 동작에서도 Socket 라이브러리를 사용하는데, 복수의 부품을 결정된 순서대로 호출해야하므로 복잡하다.

🌟 Socket 라이브러리를 이용한 데이터 송 수신 동작

서버측에서 소켓을 생성하고 클라이언트가 파이프를 연결하기를 기다린다. (소켓 생성 단계)
클라이언트가 서버측 소켓에 파이프를 연결한다 (소켓 접속 단계)
연결이 성공하면 데이터를 송 수신 한다 (송 수신 단계)
송 수신 동작이 끝나면 파이프 연결을 해제한다. (연결은 클라이언트, 서버 둘 중 어느 쪽에서 분리해도 상관없다.)

🌟 결정된 순서대로 Socket 라이브러리를 호출하는 애플리케이션 예시

socket()
- 소켓을 생성하고 완료되면 제어권을 애플리케이션에게 넘긴다. 소켓이 생성되면 디스크립터가 반환되는데, 이는 소켓을 식별하기 위한 식별자의 용도로 사용된다.
connect()
- 디스크립터, 서버의 IP 주소, 포트번호 세 가지 값을 입력하여 특정 소켓에 연결을 요청한다.
wirte()
- 송신 데이터를 메모리에 할당하고 wirte() 함수를 호출할 때 디스크립터와 송신데이터를 지정한다. 소켓에는 연결된 상대가 기록되어 있으므로 디스크립터로 소켓을 지정하면 연결된 상대가 판명된다.
read()
- 메세지를 수신할 때 사용된다. 수신한 응답메세지는 수신 버퍼에 저장된다. 수신버퍼는 애플리케이션 내부에 마련된 메모리 영역이므로 수신 버퍼에 메세지를 저장한 시점에 애플리케이션에게 메세지를 넘겨준다.
close()
- 메세지 송 수신이 완료되면 연결을 종료하는 함수 만약 read 동작을 수행하고 있는 도중에 연결이 종료되면 수신한 데이터를 건네주고 연결을 종료한다.

🌟 디스크립터 = 애플리케이션이 소켓을 식별하는 용도

🌟 IP와 포트번호 = 클라이언트와 서버 간에 상대의 소켓을 식별하는 용도

🌟 요청에는 하나의 리소스 정보만을 표시하고 있기 때문에 여러 파일의 정보를 읽으려면 요청을 각각 보내야한다. 요청을 각각 보내면 매번 TCP Connection 을 새로 맺어야하는데, 이는 비효율적일 수 있다. 그래서 HTTP 1.1 버전부터 일정시간동안 연결을 유지할 수 있는 옵션이 추가되었다.

Reference

https://velog.io/@anhesu11/HTTP-기본-이론-정리

성공과 실패를 결정하는 1%의 네트워크

[운영체제 스터디] 데드락과 데드락 발생조건 4가지

Mon, 04 Apr 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

⚠️ Deadlock

✔️ Deadlock

이련의 프로세스들이 서로가 가진 자원을 기다리며 block된 상태

✔️ Resource(자원)

하드웨어, 소프트웨어 등을 포함하는 개념
(예) I/O device. CPU cycle, memory space, semaphore 등
프로세스가 자원을 사용하는 절차
- 요청 (Request),획득 (Allocate),사용 (Use), 반납 (Release)

1. Deadlock 발생의 4가지 조건

✔️ Mutual exclusion (상호배제)

매 순간 하나의 프로세스만이 자원을 사용할 수 있음

✔️ No Preemption(비선점)

프로세스 자원을 스스로 내어놓을 뿐 강제로 빼앗기지 않음

✔️ Hold and wait

내가 가진 자원은 양보하지 않으면서 다른 프로세스의 자원을 기다리면서 보유 자원을 내놓지않고 계속 가지고 있는 현상

✔️ Circular wait

자원을 기다리는 프로세스간에 사이클이 형성되어야 함
프로세스 P0, P1 …… P5 이 있을 때
- P0은 P1에 가진 자원을 기다림
- P1은 P2가 가진 자원을 기다림
- P2는 P3가 가진 자원을 기다림
- P4는 P0이 가진 자원을 기다림

2. Resource-Allocation Graph (자원할당 그래프)

✔️ Graph에서 Deadlock 확인 방법

그래프에 cycle이 없으면 deadlock이 아니다

그래프에 cycle이 있을 때 자원의 인스턴스가 여러개이면 deadlock 일 수도 있고 아닐수도 있다.

1️⃣ Graph - 1

Vertex

Process P = {P1, P2, …. Pn}
Resource R = {R1, R2, …. Rn}

Edge

R2를 보유한 상태로 P1 → R1 자원을 요청
R2와 R1을 보유한 상태로 P2 → R3 자원을 요청
P3가 R3를 보유

DeadLock ?

P3에 할당된 R3가 해제될 수 있기 때문에 Cycle은 있으나 deadlock은 아니다.

2️⃣ Graph - 2

Vertex

Process P = {P1, P2, …. Pn}
Resource R = {R1, R2, …. Rn}

Edge

R2를 보유한 상태로 P1 → R1 자원을 요청
R2와 R1을 보유한 상태로 P2 → R3 자원을 요청
P3가 R3를 보유한 상태로 P3 → R2 요청

DeadLock ?

프로세스가 서로 가진 자원을 놓지 않고 다른 자원을 기다리고 있기 때문에 Deadlock 발생

3. Deadlock의 처리 방법

✔️ Deadlock Prevention

✔️ Deadlock Avoidance

✔️ Deadlock Detection and recovery

✔️ Deadlock Ignorance

Deadlock을 시스템이 책임지지 않음
UNIX를 포함한 대부분의 OS가 채택

3.1 Deadlock Prevention

자원 할당 시 Deadlock의 4가지 필요 조건 중 어느 하나가 만족되지 않도록 하는 것

✔️ Mutual Exclusion

공유해서는 안되는 자원의 경우 반드시 성립해야 함

✔️ Hold and Wait

프로세스가 자원을 요청할 때 다른 어떤 자원도 가지고 있지 않아야 한다
방법 1. 프로세스 시작 시 모든 필요한 자원을 할당받게 하는 법
방법 2. 다른 필요한 자원이 있으면 보유 자원을 내려놓고 다시 요청

✔️ No Preemption(비선점)

Process가 어떤 자원을 기다려야 하는 경우 이미 보유한 자원이 선점됨
모든 필요한 자원을 얻을 수 있을 때 그 프로세스는 다시 시작된다.
State를 쉽게 저장할 수 있고 복원할 수 있는 자원에서 주로 사용된다 (CPU, Memory)

✔️ Circular Wait

모든 자원 유형에 할당 순서를 정하여 정해진 순서대로만 자원 할당
- 예를 들어 순서가 3인 자원 R1를 보유 중인 프로세스가 순서가 1인 자원 R2를 할당받기 위해서는 우선 R1를 반납해야한다.

⚠️ 하지만 아직 발생할지 안할지도 모르는 Deadlock을 위와같은 방법으로 미리 예방하게 된다면 사용성을 저하시키고 성능을 감소되는 문제가 발생할 수 있다. 추가로 기아현상의 위험도 발생한다 ⚠️

3.2 Deadlock Avoidance

자원 요청에 대한 부가정보를 이용해서 자원 할당이 deadlock으로부터 안전(safe)한지 확인하고 할당한다. 시스템이 unsafe state에 들어가지 않는 것을 보장한다.

프로세스들이 필요로 하는 각 자원을 예측하거나 별 최대 사용량을 미리 선언하도록 하는 방법이다.

✔️ safe state

시스템 내의 프로세스들에 대한 safe sequence가 존재하는 상태
시스템이 safe state에 있으면 deadlock이 발생하지 않음

✔️ unsafe state

시스템이 unsafe state에 있으면 deadlock 발생 가능성이 있음

✔️ avoidance 알고리즘

Resource Allocation Graph alogorithm
- 자원의 인스턴스가 하나일 경우 사용하는 알고리즘
Banker’s Algorithm
- 자원의 인스턴스가 여러개일 경우 사용하는 알고리즘

1️⃣ Resource Allocoation Graph Alogorithm

이전에 소개한 Resource Allocoation Graph에서 점선(Clain edge)이 추가된 알고리즘

점선은 미래에 사용될 수 있는 자산을 가리킨다.

✔️ Claim edge

프로세스가 자원을 미래에 요구할 수 있다는 것을 뜻함 (점선)
프로세스가 해당 자원 요청시 Claime edge가 request edge로 바뀜 (실선)
요청자원이 해제되면 assignment edge는 다시 claim edge로 변경됨

✔️ request edge가 assignment edge로 변경 시 (점선을 포함하여) cycle이 생기지 않는 경우에만 요청 자원을 할당한다.

✔️ Cycle 생성 여부 조사시 프로세스의 수가 n일 때 O(n2)시간이 걸린다.

✔️ Resource Allocoation Graph Alogorithm 예시

P1과 P2가 미래에 R2를 요청할 가능성이 있음.
P2가 R1을 요청한 상태로 R2자원을 요청함.
P2가 R2을 할당받음 하지만 실제로 Resource Allocoation Graph Alogorithm 점선을 포함하여 cycle이 생성될 경우 자원을 내어주지 않기 때문에 R2를 할당받지 못한다. P2가 R2를 할당받으려면 R1을 소유하고 있는 P1이 R2를 할당받은 후 P1의 작업이 끝나서 R1과 R2가 해제될 때 P2가 할당받을 수 있다.

2️⃣ Banker’s Algorithm

자원의 인스턴스가 여러개일 경우 사용되는 알고리즘

모든 프로세스의 자원의 최대 사용량을 미리 명시하여 최대 사용량이 available 가능한 자원으로 충족 될 경우에만 자원을 내어준다.

✔️ 가정

모든 프로세스는 자원의 최대 사용량을 미리 명시한다.
프로세스가 요청 자원을 모두 할당받은 경우 유한시간 안에 이들 자원을 다시 반납한다.

✔️ 방법

기본 개념 : 자원 요청시 safe 상태를 유지할 경우에만 할당
총 요청 자원의 수가 가용 자원의 수보다 적은 프로세스를 선택함 만약 그런 프로세스가 없다면 unsafe한 상태
그런 프로세스가 있으면 그 프로세스에게 자원을 할당
할당받은 프로세스가 종료되면 모든 자원을 반납
모든 프로세스가 종료될 때까지 이러한 과정을 반복

✔️ Banker’s Algorithm 예시

Allocation

현재 소유하고 있는 자원

Max

최대로 요청할 수 있는 자원의 수

Available

가용 자원의 수

Need

앞으로 요청할수도 있는 남은 자원의 수 (Max - Allocation)

✔️ 5개의 프로세스가 존재한다고 가정한다.

✔️ 3개의 자원이 존재한다 A(10), B(5), C(7) 각 자원은 10, 5, 7개의 인스턴스를 가지고 있다.

✔️ 현재 가용 자원보다 Need 자원의 더 클 경우에 해당 프로세스는 자원을 할당받지 못한다. 자원 할당이 가능한 프로세스를 순서대로 나열하면 <P1, P3, P4, P2, P0> 이 된다.

3.3 Deadlock Detection and recovery

Deadlock 발생은 허용하되 그에 대한 detection 루틴을 두어 deadlock 발견시 recover한다.

Resource type 당 single instance인 경우 자원할당 그래프에서의 cycle이 곧 deadlock을 의미한다.

Resource type 당 multiple instance인 경우 Banker’s algorithm과 유사한 방법을 활용한다.

1️⃣ Wait-for graph Algorithm

자원당 하나의 인스턴스를 가지고 있을 경우 사용됨
Wait-for graph
- 자원할당 그래프의 변형
- 프로세스만으로 node를 구성함
  - P1이 가지고 있는 자원을 P2가 기다리는 경우 P2 → P1
  - Avoidance에선 P2 → R1 → P1
- 그래프에 점선이 없음
Algorithm
- Wait-for graph에 사이클이 존재하는지를 주기적으로 조사함 O(n2)

⚠️ Graph에 Cycle이 존재할 경우 Deadlock Detection ⚠️

2️⃣ Multiple instance인 경우에 사용되는 알고리즘

Banker’s Algorithm 과 비슷하지만 최대 요청가능한 자산을 예측하지 않고 Allocation, Request, Available 만 관리한다.

사용중인 자원을 해제한다는 가정하에 가용자원으로 safe sequence를 확인해보면 <P0, P2, P3, P1, P4> 와 같은 순서가 나타난다.

🌟 Request는 추가요청가능량이 아니라 현재 실제로 요청한 자원량을 나타낸다 🌟

✔️ Recovery

Process termination
- Deadlock에 연루된 모든 프로세스를 Abork 한다.
- Deadlock에 연루된 프로세스를 하나씩 Abork 해보고 해결되는 지 확인한다.
Resource Preemption
- Deadlock에 연루된 프로세스 중에 비용을 최소화할 victim을 선점하여 자원을 뺏는다.
- Safe State로 Rollback하여 Process를 재시작한다.
- Stavation 문제 발생 위험
  - 동일한 프로세스가 계속해서 victim으로 선점되는 경우
    - cost factor에 Rollback횟수도 고려한다.

3.4 Deadlock Ignorance

Deadlock이 일어나지 않는다고 생각하고 아무런 조치도 취하지 않는 방법으로 대부분의 범용 OS가 채택한 방법이다.

Deadlock은 매우 드물게 발생하므로 deadlock에 대한 조치 자체가 더 큰 overhead일 수 있다

만약, 시스템에 deadlock이 발생한 경우 시스템이 비정상적으로 작동하는 것을 사용자가 느낀 후 직접 process를 죽이는 방법 등으로 대처한다.

Reference

이화여자대학교 반효경 교수님 운영체제 강의

[운영체제 스터디] 프로세스 동기화 문제 3가지 해결방법과 세마포어 뮤텍스 차이

Sat, 02 Apr 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

Process Synchronization(Concurrency)

‼️ 프로세스 동기화와 관련된 3가지 문제

Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem

1. Bounded-Buffer Problem (Producer-Consumer Problem)

Bounded-Buffer Problem란 생산자와 사용자의 비율이 맞지않아서 사용자나 생산자가 무한히 대기하거나, 공유데이터에 동시에 접근하여 데이터 통일성이 깨질 수 있는 문제점을 얘기한다.

아래 내용은 이러한 문제점을 세마포어로 해결한 예시이다.

1.1 Bounded-Buffer의 문제점 해결 방안

✔️ Producer - 데이터를 버퍼에 채워넣는 역할

비어있는 버퍼가 있는 지 확인한다. (없을 경우 대기)
비어있는 버퍼가 있으면 공유데이터에 접근하고 lock을 건다.
비어있는 버퍼에 데이터 입력 및 버퍼를 조작한다
Lock을 해제한다.
Full Buffer를 하나 증가시킨다.

✔️ Consumer - 데이터를 사용하는 역할

full 버퍼가 있는 지 확인한다. (없으면 대기)
full 버퍼가 있을 경우 공유데이터에 접근하고 lock을 건다.
full 버퍼에서 데이터를 읽어오고 버퍼를 조작한다.
Lock을 해제한다.
Empty Buffer를 하나 증가시킨다.

‼️ 여기서 말하는 공유데이터는 ‼️

Buffer 자체 및 Buffer 조작 변수(empty/full buffer의 시작 위치)

1.2 세마포어를 적용한 동기화 기법 예제코드

Producer

Consumer

do {
	produce an item in x
	... 
	P(empty); /* 비어있는 버퍼의 수 확인 */
	P(mutex); /* 버퍼가 비어있으면 버퍼에 진입하고 lock */ 
	...
	add x to buffer
	...
	V(mutex); /* 버퍼 unlock */
	V(full);  /* full 자원을 증가시킴 */

} while(1)

do {
	P(full); /* 비어있지않은 버퍼의 수 확인 */
	P(mutex); /* 버퍼가 하나라도 비어있지 않으면 버퍼에 진입하고 lock */
	...
	remove an item from buffer to y
	...
	V(mutex); /* 버퍼 unlock */
	V(empty); /* 비어있는 버퍼의 갯수 증가 */
	...
	consume the item in y
	...
} while(1)

✔️ Synchrozination variables

semaphore empty = n; semaphore full = 0;
- 남은 full/empty의 buffer의 수 표시
semaphore mutex = 1;
- 공유 데이터의 상호배제를 위한 변수

2. Readers and Writers Problem

다수의 Readers Writer가 공용 데이터베이스에 접근하여 데이터 일관성을 해치는 문제점을 말한다. 이는 프로세스 동기화 기법으로 해결할 수 있다.

아래 내용은 프로세스 동기화 기법을 사용하여 해결한 예시이다.

2.1 Readers and Writers 문제점 해결 방안

✔️ Reader & Writer

Reader는 데이터를 읽기만 하는 프로세스
Writer는 데이터를 읽고 수정하는 프로세스

✔️ Reader & Writer Problem 방지

한 Writer가 임계구역에 진입한 상황일 때는 다른 프로세스가 임계구역에 접근하게 해선 안된다.
- 일단 Writer가 공유데이터에 접근 중이면 다른 Writer나 Reader들은 접근이 금지된다.
- Writer가 공유데이터에서 빠져나가야만 Reader의 접근이 허용된다.
Reader는 여럿이 임계구역에 접근해도 된다. 하지만 Reader가 접근 중일 때 Writer가 접근하게 해선 안된다.
- Writer는 대기 중인 Reader가 하나도 없을 때 공유데이터 접근이 허용된다.
Writer가 공유데이터에 접근 허가를 아직 얻지 못한 상태에서는 모든 대기중인 Reader들을 다 임계구역에 접근하게 해준다

2.2 세마포어를 적용한 동기화 기법 예제코드

✔️ Shared data

int readcount = 0
DB 자체

✔️ Synchronization variables

semaphore mutex = 1;
semaphore db = 1;

Writer

Reader

P(db);
...
writing DB is performed 
...
V(db);

P(mutex); /* 동시에 다른 reader가 readcount를 변경하는 문제가 발생하지 않도록 lock */
readcount++;
if(readcount == 1) P(db); /* 최초의 접근일 경우 writer가 접근 못하도록 db 봉쇄 */
V(mutex); /* readcount unlock */

‼️ 하지만 위 코드와 같은 해결방법은 stavation 발생 위험이 있음 ‼️

예를 들어 writer가 대기 중일 때 reader가 끈임없이 진입하게 되면 wrtier가 무한히 대기하게 되는 현상이 발생한다.

단순한 프로세스 동기화 예제일 뿐 최적의 해결방법이 아니기 때문에 참고만 하자.

3. Dining-Philosophers Problem (식사하는 철학자 문제)

하나 이상의 프로세스가 공유데이터 중 서로에게 필요한 자원을 하나씩만 가지고 양보하지 않아서 Deadlock 이 발생할 수 있는 문제

아래 예제를 참고하여 어떤한 경우에 문제가 발생하는지 알아보고 어떻게 해결하는지 알아보자

[문제 발생 예제 코드]

✔️ Synchronization variables

semaphore chopstick[5]
- 배열의 모든 값을 1로 초기화 했다고 가정한다

Philosopher i

do {
	P(chopstick[i]);
	P(chopstick[j + 1] % 5);
	...
	eat();
	...
	V(chopstick);
	V(chopstick);
	...
	think();
	...
} while(1);

✔️ 위 예제 코드의 문제점

모든 철학자가 동시에 배가 고파져 왼쪽 젓가락을 집어버린 경우 아무도 먹지 못하는 문제가 발생한다.
Deadlock 발생 위험이 있다.

[해결방안 예제 코드]

✔️ Synchronization variables

enum {thinking, hungry, eating} state[5];
semaphore self[5] = 0;
semaphore mutex = 1;

Philosopher i

/* 실행메소드 */
do {
	pickup(i);
	eat();
	putdown(i);
	think();
} while (1);

void pickup(int i) {
	P(mutex);
	state[i] = hungry;
	test(i);
	V(mutex);
	P(self[i]);
}

void pickdown(int i) {
	P(mutex);
	state[i] = thinking;
	test((j+4) % 5);
	test((j+1) % 5);
	V(mutex);
}

/* 대상 철학자의 오른쪽과 왼쪽 철학자가 식사중인지 검사하고 대상 철학자가 배고픈 상태일 때 식사를 허용한다. */
void test(int i) {
	if(state[(j+4) & 5] != eating && state[i] == hungry && state[(i + 1) % 5] != eating ) {
		state[i] = eating;
		V(self[i]);		
	}
}

✔️ 해결 방안

4명의 철학자만이 테이블에 동시에 앉을 수 있도록 한다
젓가락을 두 개 모두 잡을 수 있을 때에만 젓가락을 집을 수 있게 한다
비대칭
- 짝수(홀수) 철학자는 왼쪽(오른쪽) 젓가락부터 집도록

‼️ 여태까지의 예제코드를 살펴봤을 때 Semaphore의 문제점 ‼️

코딩하기 힘들다
정확성(correctness)의 입증이 어렵다
자발적 협력(voluntary cooperation)이 필요하다
한번의 실수가 모든 시스템에 치명적 영향을 끼친다.

💡 예시 1번

💡 예시 2번

V(mutex)
Critical Section
P(mutex)

P(mutex)
Critical Section
P(mutex)

[예시 1번]

Wait 시점과 Signal 시점이 반대가 되어 Mutual Exclusion이 깨진다.

[예시 2번]

자원을 해제하는 코드가 없기 때문에 서로 필요한 자원을 얻지 못하여 Deadlock 발생 위험이 있다.

4. Monitor

동시에 수행중인 프로세스 사이에서 추상 데이터 타입의 안전한 공유를 보장하기 위한 high-level synchronization construct이다. 기본적으로 Monitor는 여러 프로세스가 동시적으로 접근할 수 없기 때문에 lock, unlock이 필요없다. 이는 프로그래머가 동기화 제약 조건을 명시적으로 코딩할 필요가 사라지기 때문에 프로그래머의 부담이 줄어든다고 할 수 있다.

✔️ Monitor

모니터 내에서는 한번에 하나의 프로세스만이 활동 가능
프로세스가 모니터를 사용하다가 타이머 인터럽트가 발생하여도 다른 프로세스가 모니터에 접근하지 못한다. active한 프로세스가 0이 되거나 프로세스가 모니터 내부에서 잠들었을 때 다른 프로세스가 진입한다.
프로세스가 모니터 안에서 기다릴 수 있도록 하기 위해 condition variable 사용
condition x;
- condition value는 값을 가지지 않고 자신의 큐에 프로세스를 sleep 시키거나 깨우는 역할만 한다.
condition variable은 wait과 signal 연산에 의해서만 접근 가능
- x.wait();
  - x.wait()을 invoke한 프로세스는 다른 프로세스가 x.signal()을 invoke하기 전까지 suspend된다
- x.signal();
  - x.signal()은 정확하게 하나의 suspend된 프로세스를 resume한다. suspend된 프로세스가 없으면 아무 일도 일어나지 않는다.

4.1 모니터를 활용한 Bounded-Buffer Problem 문제 해결 방법

monitor bounded_buffer
{ int buffer[N];
	condition full, empty;

	void produce(int x) 
	{ if (buffer.size() == N) // 1
			empty.wait();  // 2
		else
			/* add x to empty buffer*/
			full.signal() ; // 3
		
	}

	void consume(int *x) 
	{ if (buffer.size == 0) // 1
				full.wait();      // 2
		else 
			/* remove an item from buffer an store it to */
			empty.signal();     // 3
	}

}

앞에 소개한 Bounded-Buffer 문제를 모니터로 변경한 소스코드이다. 모니터는 한 프로세스만 접근할 수 있으므로

세마포어처럼 공유변수에 lock/unlock 작업을 수행하지 않아도 된다.

✔️ produce(int x)

빈 버퍼가 있는 지 확인한다.
빈 버퍼가 없으면 empty큐에서 대기한다.
빈 버퍼가 있으면 버퍼에 데이터를 추가하고 full큐에 잠들어있는 프로세스 하나를 깨운다.

✔️ consume(int *x)

버퍼에 데이터가 있는 지 확인한다.
버퍼에 데이터가 없으면 full큐에 대기한다.
데이터가 있을 경우 버퍼에서 데이터 하나를 읽어오고 empty큐에 잠들어있는 프로세스 하나를 깨운다.

Reference

https://mangkyu.tistory.com/104

이화여자대학교 반효경 교수님 운영체제 강의

[운영체제 스터디] 프로세스 동기화 조건 3가지와 뮤텍스 세마포어

Mon, 28 Mar 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

1. 프로세스 동기화 프로그램적 해결법의 충족 조건

프로세스가 임계구역에 동시에 접근하는 것을 방지하고 데이터 일관성을 유지하려면 아래 세가지 조건을 충족해야한다.

✔️ Mutual Exclustion

프로세스 Pi가 Critical Section 부분을 수행 중이면 다른 모든 프로세스들은 그들의 Critical Section에 접근하면 안된다.

✔️ Progress

Critical Section에 접근한 프로세스가 없는 상황에서 Critical Section에 접근하고자 하는 프로세스가 있으면 Critical Section에 접근하게 해야한다.

✔️ Bounded Waiting

프로세스가 Critical Section에 들어가려고 요청한 후부터 그 요청이 허용될 때까지 다른 프로세스들이 Critical Section에 들어가는 횟수에는 한계가 있어야 한다. (기다리는 시간이 유한 해야함)
- 기아현상 방지

‼️ 예제 알고리즘으로 위 세가지 조건에 만족할 수 있는 방법이 무엇인지 알아보자

💡 실습 가정 !

모든 프로세스 수행 속도는 0보다 크다
프로세스들 간의 상대적인 수행 속도는 가정하지 않는다
예제 알고리즘은 두개의 프로세스가 있다고 가정한다 (P1, P2)
프로세스들은 수행의 동기화를 위해 몇몇 변수를 공유할 수 있다 (Synchronization variable)

2. Algorithm - 1

[변수 초기화]

✔️ Synchronization variable

int turn; → 프로세스가 임계구역에 들어갈 수 있는 조건인지 확인하는 변수
initially turn = 1; → 첫 진입을 P1에게 허용하기 위해 1로 초기화 함

[구현 코드]

✔️ Process P1 구현 코드

do {
		while(turn != 1); /* P1가 접근 가능한 상황이 될 때까지 while */
		**critical section**  /* 임계구역 */
		****turn ****= 2;         /* 프로세스 P2(이)가 접근할 수 있게 값 변경*/
		**remainder section**
} while (1); 

✔️ Process P2 구현 코드

do {
		while(turn != 2); /* P2가 접근 가능한 상황이 될 때까지 while */
		**critical section**  /* 임계구역 */
		****turn ****= 1;         /* 프로세스 P1(이)가 접근할 수 있게 값 변경 */
		**remainder section**
} while (1); 

💡 Algorithm - 1 은 Mutual Exclustion 을 만족하지만 Progress 조건은 만족하지 못한다. 💡

Algorithm - 1 을 예로 들면 반드시 교대로 임계구역에 들어갈 수 있게 설계되어있기 때문에 P1이 임계구역 접근에 시도를 하지않을 경우 turn의 값은 영원히 바뀌지 않는다. turn이 변경되지 않을 경우 P2이 입계구역에 접근하려고 해도 접근할 수 없게 된다. 또한 임계구역 접근 빈도가 서로 다를 경우에도 문제가 발생할 수 있다.

3. Algorithm - 2

[변수 초기화]

✔️ Synchronization variable

boolean falg[2];
initially flag[모두] = false; /* no one is in CS */
프로세스가 임계구역에 접근할 준비가 되면 (flag[i] == true)

[구현코드]

✔️ Process P1 구현 코드

do {
		flag[0] = true /* 임계구역에 들어갈 준비가 되었다 */
		while (flag[1]) /* P2가 임계구역에 접근한 상태인지? 접근했다면 P1은 대기 */
		**critical section**  /* 임계구역 */
		flag[0] = false;
		**remainder section**
} while(1);

✔️ Process P2 구현 코드

do {
		flag[1] = true /* 임계구역에 들어갈 준비가 되었다 */
		while (flag[0]) /* P1가 임계구역에 접근한 상태인지? 접근했다면 P2은 대기 */
		**critical section** /* 임계구역 */
		flag[1] = false;
		**remainder section**
} while(1);

💡 Algorithm - 2 은 Mutual Exclustion 을 만족하지만 Progress 조건은 만족하지 못한다. 💡

P1과 P2가 둘 다 임계구역에 접근하려고 값을 true로 변경했을 경우 2행까지 수행 후 끊임 없이 양보하는 상황이 발생할 수 있다. 이럴 경우 P1, P2 두 프로세스가 전부 임계구역에 접근하지 못하는 상황이 발생하기 때문에 Progress 조건을 만족하지 못한다.

4. Algorithm - 3 (Peterson’s Algorithm)

[변수 초기화]

Combined syschronization variables of algorithms 1 and 2
- Peterson’s Algorithm은 Algorithm - 1 , Algorithm - 2 에서 사용했던 모든 변수를 사용한다.

[구현코드]

do {
		flag[0] = true; /* My intention is to enter */
		turn = 2;       /* Set to his turn */
		while(flag[1] && turn == 2) /* wait only if */
		**critical section** /* 임계구역 */
		flag[0] = false;
		**remainder section**
}

💡 Algorithm - 3는 프로세스 동기화의 세가지 요구사항을 모두 만족한다. 💡

피터슨의 알고리즘은 다른 프로세스가 임계구역에 접근한 상황인지와 다른 프로세스의 임계구역 접근 차례를 모두 검사하고 접근을 시도하기 때문에 세가지 요구사항을 모두 만족한다.

‼️ Algorithm - 3 의 문제점 → Busy Waiting(=spin lock)! (계속 CPU와 memory를 쓰면서 wait) ‼️

만약 한 프로세스가 임계구역에 접근한 상황에서 다른 프로세스가 CPU를 할당받을 경우 while 조건에 충족하기 때문에 다른 작업은 수행하지 못하고 CPU를 빼앗길 때까지 while을 반복하게 된다. (의미없이 CPU 수행시간을 낭비하게 됨)

5. Synchronization Hardware

프로세스 동기화 문제는 소프트웨어가 Input과 Output을 하나의 인스트럭션으로 진행할 수 없어서 생긴 문제점이다. 이러한 문제점을 하드웨어적으로 test & modify를 atomic하게 수행할 수 있도록 지원하면 앞의 문제는 간단히 해결된다.

✔️ Counting semaphore (세마포어)

도메인이 0 이상인 임의의 정수값
자원의 갯수가 여러개인 경우
주로 resource counting에 사용

✔️ Binary semaphore (=mutex)

0 또는 1 값만 가질 수 있는 세마포어
- 자원의 갯수가 하나인 경우
주로 mutual exclusion (lock/unlock)에 사용 (=mutex)

5.1 Mutex

Mutex는 Mutual Exclustion의 약자이고 상호배재 한다는 뜻으로 사용된다. Mutex는 Locking 매커니즘으로 오직 하나의 쓰레드만이 동일한 시점에 뮤텍스를 얻어 임계 영역에 들어올 수 있고 오직 이 쓰레드만이 임계 영역에서 나갈 때 뮤텍스를 해제할 수 있다.

5.2 Mutual Exclustion with Test & Set

[변수 초기화]

✔️ Synchronization variable

boolean lock = false;

[구현코드]

do {
	while (Test_and_Set(lock));
	**critical section**
	lock = false;
	**remainder section**
}

💡 Test_and_set()

파라미터 변수의 값을 읽고, TRUE로 변경작업을 수행한다. 이전 알고리즘 1,2,3은 값을 읽고 변경하는 작업을 따로따로 진행했다면, Test_and_set()은 값을 읽고 변경하는 작업을 하나의 인터럭션으로 수행하므로 조금 더 간결하게 해결할 수 있도록 도와준다.

6. Semaphores

세마포어란 임계구역에 진입하기 어려울 때 프로세스가 자발적으로 대기 상태로 들어가는 방식이다. 세마포어는 앞의 방식들을 추상화 시킨 방식이다.

❓ 세마포어

block/wakeup 알고리즘
진입 불가능 시에는 대기상태로 전환
임계구역을 떠나는 프로세스가 대기 프로세스를 준비 상태로 깨워줌

❓ 세마포어 구성

하나의 정수값 (정수변수 value)
프로세스 대기 큐
정수에 대한 3가지 연산 : init, wait, signal
- wait 은 P 연산이라고도 불린다.
- signal 은 V 연산이라고도 불린다.

✔️ Semaphore 객체를 S 라 할 때

S.value: 자원 활용 현황
- 양수: 남아있는 자원의 수
- 음수: 부족하여 대기하고 있는 대기자 수
S.value의 초기값 n : 자원의 개수

아래의 두 가지 atomic 연산에 의해서만 자원에 접근 가능하다.

P(S): while (s<=0) do no-op; /*wait*/
			S--;

V(S): S++; /* 자원 반납 */

세마포어의 모든 오퍼레이션은 atomic하게 실행되어야 한다. wait 연산을 하는 동안 signal 연산을 하거나, 또는 그 반대의 경우 모두 발생해서는 안된다. 이를 보장하기 위해 각 연산이 실행되는 동안 인터럽트를 disable 시킴으로써 해결할 수 있다. 만약 다중 CPU 환경이라면 모든 CPU의 인터럽트를 disable 시켜야 한다. 헌데 모든 인터럽트를 디스에이블 할 경우 성능이 저하될 수 있기 때문에 compare_and_swap()을 사용하거나 spinlock 과 같은 busy waiting 기법을 사용하기도 한다.

6.1 Block & Wakeup Inmplementation

✔️ Busy-wait 과 Block/wakeup

busy-wait과 block/wakeup 방식을 비교하자면 block/wakeup 방식을 사용하는 것이 효율적이다. busy-wait 방식은 자기 차례가 아니면 의미없이 CPU 시간을 낭비하는 반면에 block/wakeup 방식은 자기 차례가 아닐 경우 block 상태로 전환하기 때문이다.

그런데 임계구역의 코드가 짧을 경우에는 block/wakeup 방식보다 busy-wait 방식이 더 효율적일 수 있다. ready 상태에서 block 상태로 전환하고 다시 block 상태에서 ready 상태로 전환하는 것에 오버헤드가 따르기 때문이다.

정리하자면 임계구역이 짧을 경우에는 busy-wait 방식이 효율적이고 임계구역 코드가 길 경우에는 block/wakeup 방식이 효율적이다.

7. Deadlock

둘 이상의 프로세스가 서로 원하는 리소스가 상대방에게 할당되어 있을 경우 무한히 대기하는 현상을 말한다. 보통 시스템적으로 한정된 자원을 여러 곳에서 사용하려고 할 때 발생한다.

Reference

https://mangkyu.tistory.com/104

이화여자대학교 반효경 교수님 운영체제 강의

[운영체제 스터디] 다단계 큐 스케줄링과 프로세스 동기화

Wed, 23 Mar 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

1. Multilevel Queue (SingleCore Cpu 기준)

✔️ Multilevel Feedback Queue보다 프로세스 차별적인 방식

✔️ Ready queue를 여러 개로 분할

foreground (interactive)
background (batch - no human interaction)

✔️ 각 큐는 독립적인 스케줄링 알고리즘을 가짐

foreground - RR (라운드 로빈)
- 사용자와 대화하는 프로세스이기 때문에 응답시간이 짧은 것이 중요하다
background - FCFS (선입선출)
- 사용자와 대화없이 CPU만 사용하는 batch형 작업이기 때문에 응답시간이 빠를 필요가 없다

✔️ 큐에 대한 스케줄링이 필요

Fixed priority scheduling
- serve all from foreground then from background
- Possibility of starvation
  - 우선순위가 높은 작업이 종료되지 않으면 우선순위가 낮은 프로세스는 영원히 실행되지 못하는 문제가 발생할 수 있다.
Time slice
- 각 큐에 CPU time을 적절한 비율로 할당
- starvation을 막기위해 전체 CPU 사용시간을 우선순위가 높은 foreground 작업에 80% 할당하고 우선순위가 낮은 background 작업에 20%를 할당하게 한다.

2. Multilevel Feedback Queue (SingleCore Cpu 기준)

✔️ 프로세스가 다른 큐로 이동할 수 있음

✔️ 에이징(aging)을 이와 같은 방식으로 구현할 수 있음

✔️ Multilevel-feedback-queue scheduler를 이루고 있는 요소들

Queue의 수
각 큐의 scheduling algorithm
Process를 상위 큐로 보내는 기준
Process를 하위 큐로 내쫓는 기준
프로세스가 CPU 서비스를 받으려 할 때 들어갈 큐를 결정하는 기준

✔️ 처음 실행되는 작업은 우선순위를 가장 높게 받음

2.1 Multilevel Feedback Queue 예시

✔️ Three queues:

Q0 - time quantum 8 milliseconds
Q1 - time quantun 16 milliseconds
Q2 - FCFS (선입선출)

✔️ Schduling

새로운 작업이 Q0으로 들어간다.
CPU를 잡아서 할당 시간 8milliseconds 동안 수행된다
Q0에서 할당받은 시간내에 작업을 다 끝내지 못했으면 Q1로 내려간다.
Q1에 줄서서 기다렸다가 CPU를 할당받고 16ms 동안 수행된다.
Q1에서 할당받은 시간내에 작업을 끝내지 못한 경우 Q2로 쫓겨난다.

3. 멀티코어 CPU의 경우 고려해야할 점

CPU가 여러 개인 경우 스케줄링은 더욱 복잡해진다.

✔️ Homogeneous processor인 경우

Queue에 한줄로 세워서 각 프로세서가 알아서 꺼내가게 할 수 있다.
반드시 특정 프로세스에세 수행되어야 하는 프로세스가 있는 경우에는 문제가 복잡해진다.

✔️ Load sharing

일부 프로세서에 job이 몰리지 않도록 부하를 적절히 공유하는 메커니즘이 필요하다
별개의 큐를 두는 방법 vs 공동 큐를 사용하는 방법

✔️ Symmetric Multiprocessing (SMP)

각 프로세서가 각자 알아서 스케줄링 결정

✔️ Asymmetric multiprocessing

비대칭형 다중 처리기
- 하나의 프로세서가 시스템 데이터의 접근과 공유를 책임지고 나머지 프로세서는 거기에 따라 움직이는 방식
대칭형 다중 처리기
- CPU가 각자 알아서 스케줄링하는 방식

4. Real-Time Scheduling

✔️ Hard real-time systems

Hard real-time task는 정해진 시간 안에 반드시 끝내도록 스케줄링해야 함

✔️ Soft real-time computing

Soft real-time task는 일반 프로세스에 비해 높은 priority를 갖도록 해야 함

✔️ EDF (Earlist Deadline scheduling)

실시간 환경에서는 먼저 온 요청보다 데드라인이 다가온 요청을 먼저 처리하는 스케줄링
연성 실시간 시스템처럼 일반 작업과 VOD 작업 등이 혼합된 환경에서는 데드라인이 존재하는 프로세스에게 일반 프로세스보다 높은 우선 순위를 할당한다.

5. Thread Scheduling

✔️ Local Scheduling

User level thread의 경우 사용자 수준의 thread library에 의해 어떤 thread를 스케줄링할지 결정
- 이 경우에 운영체제는 해당 thread의 존재를 알지 못한다.

✔️ Global Sheduling

Kernel level thread의 경우 일반 프로세스와 마찬 가지로 커널의 단기 스케줄러가 어떤 thread를 스케줄할지 결정

6. Process Synchronization

멀티 프로세서 시스템의 경우 메모리 주소공간을 공유하는 CPU 프로세스가 여럿 있는 경우 Race Condition의 가능성이 있다. 아래 내용들은 Race Condition 발생 원인과 이를 해결하기 위한 프로세스 동기화 방법이다.

✔️ Race Condition?

여러 프로세스들이 동시에 공유데이터에 접근하여 경쟁하는 상태이다.

여러 프로세스가 동시에 공유데이터에 접근하게되면 데이터의 불일치 문제를 발생시킬 수 있다.

일관성 유지를 위해서는 협력 프로세스간의 실행 순서를 정해주는 메커니즘이 필요하다

✔️ OS에서 Race Condition은 언제 발생하는가?

Kernel에서 수행 중 인터럽트 발생 시
Process가 system call을 하여 kernel mode로 수행 중인데 context switch가 일어나는 경우
N 개의 프로세스가 공유 데이터를 동시에 사용하기를 원하는 경우

‼️ 한 프로세스가 공유 데이터를 사용하고 있을 때 다른 프로세스가 접근하면 안되는 이유 ‼️

각 프로세스의 code segment에는 공유 데이터를 접근하는 코드인 ciritical section이 존재한다.
이 경우에 하나의 프로세스가 critical section에 있을 때 다른 모든 프로세스는 critical section에 들어갈 수 없어야 한다.

✔️ Race Condition은 어떻게 방지하는가?

Process가 system call을 하여 kernel mode로 수행 중인데 context switch가 일어나는 경우
- 커널 모드에서 수행 중일 때는 CPU를 선점하지 않고 커널모드에서 사용자 모드로 돌아갈 때 CPU를 선점하는 방식
Multiprocessor에서 shared memory 내의 kernel data
- 방법 1) 한번에 하나의 CPU만이 커널에 들어갈 수 있게 하는 방법
- 방법 2) 커널 배우에 있는 각 공유 데이터에 접근할 때마다 그 데이터에 대한 lock / unlock을 하는 방법

[운영체제 스터디] 프로세스 생성과 프로세스의 협력

Tue, 22 Mar 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

1. 프로세스와 관련한 시스템 콜

✔️ fork()

create a child (copy)

✔️ exec()

overlay new image

✔️ wait()

sleep until child is done

✔️ exit()

frees all the resources, notify parent

2. 프로세스 생성 (Process Creation)

‼️ Copy-on-wirte(COW)

자원의 내용이 변경될 때 메모리 영역을 복제하고 변경되지 않을 경우에는 부모 프로세스의 자원을 공유한다.

✔️ 부모프로세스(Parent process)가 자식 프로세스(chlidren process) 생성

✔️ 프로세스의 트리(계층 구조) 형성

✔️ 프로세스는 자원을 필요로 함

운영체제로부터 받는다
부모와 공유한다.

✔️ 자원의 공유

부모와 자식이 모든 자원을 공유하는 모델
일부를 공유하는 모델
- 보통은 공유하는 모델보다 공유하지않는 모델이 대부분이다.
전혀 공유하지 않는 모델
- 부모와 자식 프로세스가 자원을 공유하지 않을 경우엔 자원을 두고 부모와 자식이 경쟁하게 된다.

✔️ 수행(Execution)

부모와 자식이 공존하며 수행되는 모델
- 부모와 자식이 공존하며 수행되는 모델은 자식과 부모가 CPU를 획득하기 위해 경쟁하는 관계가 된다.
자식이 종료(terminate)될 때까지 부모가 기다리는(wait)모델
- 자식 프로세스가 종료될 때까지 부모는 봉쇄상태에 머물러 있다가 자식프로세스가 종료된 이후에 CPU를 얻을 수 있는 권한이 생긴다.
- 일반적인 봉쇄상태와 다르게 자원을 기다리며 줄 서 있는 것이 아니다.

✔️ 주소 공간 (Address space)

자식은 부모의 공간을 복사함 (binary and OS data)
자식은 그 공간에 새로운 프로그램을 올림

✔️ 유닉스의 예

fork()
- fork() 시스템 콜이 새로운 프로세스를 생성
- 부모를 그대로 복사 (OS data execpt PID + binary)
  - 주소공간은 따로 가지고 있지만 주소공간의 내용은 동일한 내용을 갖게 된다 (문맥이 동일하다)
  - 문맥이 동일하기 때문에 부모 프로세스의 프로그램 카운터 지점부터 수행하게 된다.
- 주소 공간 할당
- 부모 프로세스와 다른 작업을 수행할 수 있지만, 이는 조건문에 의한 분기일 뿐 사실상 부모 프로세스와 동일한 코드의 내용을 갖는다.
exec()
- exec() 시스템 콜을 통해 새로운 프로그램으로 주소 공간을 덮어씌울 수 있다.
- 부모 프로세스와 문맥이 달라지므로 부모프로세스의 실행시점부터 수행하지 않고 처음부터 실행하게 된다.

3. 프로세스 종료 (Process Termination)

✔️ exit()

프로세스가 마지막 명령을 수행한 후 운영체제에게 이를 알려준다(exit)
자식이 부모에게 output data를 보냄 (via wait)
프로세스의 각종 자원들이 운영체제에게 반납됨
명시적으로 exit()를 호출하지 않았더라도 컴파일러가 main 함수가 리턴되는 위치에 exit()를 넣어줌

✔️ abort()

자식이 할당 자원의 한계치를 넘어섬
자식에게 할당된 태스크가 더 이상 필요하지 않음
키보드로 kill, break를 친 경우
부모가 종료(exit)하는 경우
- 운영체제는 부모 프로세스가 종료하는 경우 자식이 더 이상 수행되도록 두지 않는다.
- 단계적인 종료

4. 자식 프로세스 생성

✔️ 부모 프로세스가 자식 프로세스를 생성할 때의 플로우

부모 프로세스가 자식 프로세스 생성을 위해 fork() 시스템 콜을 발생시킨다.
fork() 시스템 콜이 발생하면 CPU의 제어권이 커널로 넘어간다.
커널은 fork()를 호출한 프로세스를 복제하여 자식 프로세스를 생성한다.

부모 프로세스를 복제하여 생성된 자식 프로세스는 현실세계의 부모 자식과는 달리 자신을 똑닮은 자식이 아닌, 자신의 외모와 기억이 전부 동일한 복제인간을 생성하는 것과 같다.

복제된 대상은 ‘복제되었다’는 기억을 가지는 것이 아니라 부모와 마찬가지로 방금 전에 자기 자신을 ‘복제했다’는 기억을 가지게 된다. 자식 프로세스가 복제된 프로세스라는 사실을 알 수 있는 단서는 fork() 함수의 결과값이 원본 프로세스는 양수를 가지고 복제본은 0을 갖는다는 차이점이 있다.

5. 프로세스간의 협력

프로세스는 각자 자신만의 독립적인 공간을 가지고 수행되며 프로세스가 다른 프로세스의 주소공간을 참조하는 것은 허용되지 않는다. 따라서 원칙적으로 하나의 프로세스는 다른 프로세스의 수행에 영향을 미칠 수 없다.

🤔 독립적인 프로세스가 서로 협력하면 프로세스 작업의 효율성이 증가할 것 같은데..?

원칙적으론 프로세스는 다른 프로세스의 수행에 영향을 미칠 수 없지만, 프로세스가 협력했을 때 작업 효율이 증가할 수 있기 때문에 운영체제는 여러가지 매커니즘을 제공한다. 대표적인 매커니즘으론 IPC가 있다.

✔️ 프로세스 간 협력 메커니즘 (IPC: Interprocess Communication)

하나의 컴퓨터안에서 실행 중인 서로 다른 프로세스 간에 발생하는 통신
프로세스간의 통신과 동기화를 이루기 위한 메커니즘
메시지 전달 방식과 공유 메모리 방식이 있음.
- 두 방식의 차이는 프로세스 사이에 공유 데이터를 사용하는가, 그렇지 않는가에 있다
메시지를 전달하는 방법
- Massage passing
  - 커널을 통해 메시지 전달
주소공간을 공유하는 방법
- Shared memory
  - 서로 다른 프로세스 간에도 일부 주소 공간을 공유하게 하는 shared momory 메커니즘이 있음
- 🤔 Thread
  - thread는 사실상 하나의 프로세스이므로 프로세스 간 협렵으로 보기는 어렵지만 동일한 process를 구성하는 thread들 간에는 주소 공간을 공유하므로 협력이 가능

‼️ IPC의 메세지 전달 방식 (Massage passing)

✔️ Message system

프로세스 사이에 공유 변수(shared variable)를 일체 사용하지 않고 통신하는 시스템

✔️ Direct Communication

통신하려는 프로세스의 이름을 명시적으로 표시

✔️ Indirect Communication

mailbox (또는 port)를 통해 메세지를 간접 전달

💡 Massage passing

공유데이터를 사용하지 않는 프로세스들이 메시지를 주고받으며 통신하는 방식을 사용한다. 이때 두 프로세스의 주소공간이 다르므로 메시지를 직접 전달할 수 없기 때문에 커널이 그 역할을 대신한다.

메시지 통신을 하는 시스템은 커널에 의해 send와 receive라는 두 가지 연산을 제공받게 된다. 이 두 연산을 통해 프로세스는 전달할 메세지를 운영체제에게 시스템 콜 방식으로 요청해 전달할 수 있다.

통신하기를 원하는 두 프로세스는 커뮤니케이션 링크를 생성한 후 send()와 receive()를 이용해서 메시지를 주고받게 된다.

[운영체제 스터디] 프로세스의 특성과 CPU 스케줄링

Tue, 22 Mar 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

1. CPU and I/O Bursts In Program Execution

어떤 프로그램이든 프로그램을 실행한다는 것은 CPU Burst와 I/O Burst를 반복하게 되는 것이다.

❓CPU Burst

CPU에서 instruction을 수행하는 것

❓ I/O Burst

I/O를 instruction을 수행하는 작업

💡 프로세스의 특성 분류

✔️ I/O-bound process

CPU를 잡고 계산하는 시간보다 I/O에 많은 시간이 필요한 Job
(many short CPU bursts)

✔️CPU-bound process

계산 위주의 job
(few very long CPU bursts)

💡 CPU-burst Time의 분포

✔️ 여러 종류의 job(=process)이 섞여 있기 때문에 CPU 스케줄링이 필요하다.

Interactive job에게 적절한 reponse 제공 요망
CPU와 I/O 장치 등 시스템 자원을 골고루 효율적으로 사용해야 함

2. CPU Scheduler & Dispatcher

✔️ CPU Scheduler

Ready 상태의 프로세스 중에서 이번에 CPU를 줄 프로세스를 고른다.

✔️ Dispatcher

CPU의 제어권을 CPU scheduler에 의해 선택된 프로세스에게 넘긴다
이 과정을 context switch(문맥 교환)라고 한다.

✔️ CPU 스케줄링이 필요한 경우

Running → Blocked (예: I/O 요청하는 시스템 콜)
Running → Ready (예: 할당시간만료로 timer interrupt)
Blocked → Ready (예: I/O 완료후 interrupt)
Terminate

I/O를 발생시켜 Blocked 되는 경우나 Terminate에서의 스케줄링은 강제로 빼앗지 않고 자진반납(nonpreemptive)한다. 다른 상태는 모두 강제로 빼앗기는(preemptive) 경우이다.

❓nonpreemptive = 비선점형 방식

CPU를 획득한 프로세스가 스스로 CPU를 반납하기 전까지는 CPU를 빼앗기지 않음

❓preemptive = 선점형 방식

프로세스가 CPU를 계속 사용하길 원한다고 하더라도 강제로 빼앗길 수 있음

3. Dispatcher

CPU 스케줄러가 어떤 프로레스에게 CPU를 할당해야 할지 결정하고나면 선택된 프로세스에게 실제로 CPU를 이양하는 작업이 필요하다.

이와 같이 새롭게 선택된 프로세스가 CPU를 할당받고 작업을 수행할 수 있도록 환경설정 하는 운영체제의 코드를 디스패처라고 부른다.

디스패처는 현재 수행 중이던 프로세스의 문맥(context)을 그 프로세스의 PCB에 저장하고, 새롭게 선택된 프로세스의 문맥을 PCB로부터 복원한 후 그 프로세스에게 CPU를 넘기는 작업을 수행한다.

디스패처가 하나의 프로세스를 정지시키고 다른 프로세스에게 CPU를 전달하기까지 걸리는 시간을 디스패치 지연시간(dispatch Latency)이라고 하며, 디스패치 지연시간의 대부분은 문맥교환 오버헤드에 해당된다.

4. 스케줄링 알고리즘

1. 선입선출 스케줄링(FCFS)

선입선출(First-Come First-Served: FCFS) 스케줄링은 프로세스가 준비큐에 도착한 시간 순서대로 CPU를 할당하는 방식을 말한다. 이 방식에서는 CPU를 먼저 요청한 프로세스에게 CPU를 할당하고, 해당 프로세스가 자발적으로 CPU를 반납할 때까지 빼앗기지 않는다.

1.1 선입선출 스케줄링의 단점

도착한 순서대로 CPU 작업을 처리하기 때문에 CPU Burst가 짧은 작업이어도 도착시간이 늦어지게 되면, CPU Burst가 높은 작업이 끝날 때까지 기다려야 하므로 사용량에 비해 대기시간이 길어진다는 단점이 있다. 이를 콘보이 현상 이라고 하며, 이는 FCFS 스케줄링의 대표적인 단점에 해당된다.

2. 최단작업 우선 스케줄링 (SJF)

최단작업 우선(Shortest-job First: SFJ) 스케줄링 알고리즘은 CPU 버스트가 가장 짧은 프로세스에게 CPU를 제일 먼저 할당하는 방식이다. 이와 같은 할당 방식을 통해 CPU 버스트가 짧은 프로세스가 CPU를 먼저 사용하고 준비 큐를 빠져나가게 되면 프로세스들이 준비 큐에서 기다리는 전체적인 시간이 줄어들게 된다. SJF 스케줄링 알고리즘은 평균 대기시간을 가장 짧게 하는 최적 알고리즘으로 알려져 있다.

2.1 선점방식

진행중인 작업의 남은 CPU 버스트보다 짧은 작업이 도착하면 더 짧은 작업에게 CPU를 할당하는 방식 이러한 방식을 SRTF(Shortest Remaining Time First)라고도 부른다.
프로세스들이 준비 큐에 도착하는 시간이 불규칙한 경우 선점형방식이 프로세스들의 평균 대기시간을 최소화 하는 최적의 알고리즘이 된다.
일반적인 시분할 환경에서는 중간중간에 새로운 프로세스가 도착하는 경우가 발생하므로 선점형 방식이 평균 대기시간을 가장 많이 줄일 수 있다.

2.2 비선점방식

먼저 도착한 작업의 CPU 수행이 끝나서 스스로 CPU를 내어놓을 때까지 스케줄링을 하지 않는다.
일련의 프로세스들이 준비큐에 한번에 도착하고 그 후에는 따로 도착하지 않는 환경에선 선점형방식과 같은 대기시간 결과를 나타내기도 한다.

2.1 SFJ 스케줄링의 단점

CPU 버스트가 짧은 프로세스가 계속 도착할 경우 CPU 버스트가 긴 프로세스는 영원히 CPU를 할당받지 못할 수 있다. 이를 기아 현상(starvation)이라고 한다.

3. 우선순위 스케줄링

우선순위 스케줄링(priority scheduling)이란 준비 큐에서 기다리는 프로세스들 중 우선순위가 가장 높은 프로세스에게 제일 먼저 CPU를 할당하는 방식을 말한다. 이때 우선순위는 우선순위값(priority number)을 통해 표시하며 우선순위값이 작을수록 높은 우선순위를 가지는 것으로 가정한다.

우선순위 스케줄러도 비선점형방식과 선점형방식이 있는데 이는 SJF 알고리즘의 비선점형,선점형과 동일한 방식에서 CPU 버스트 시간 기준이 아닌, 우선순위 기준으로 변경된 것이다.

3.1 우선순위를 정하는 방법

CPU 버스트 시간으로 우선순위 선정
- 이러한 경우 SJF 알고리즘과 동일한 의미를 가지게 됨
시스템과 관련된 동일한 작업을 수행하는 프로세스의 우선순위를 높게 부여하는 것

3.2 우선순위 스케줄링 단점

우선순위 스케줄러 방식에서도 기아현상이 발생할 수 있다. 우선순위가 높은 프로세스가 계속 도착하는 상황에서 우선순위가 낮은 프로세스는 CPU를 얻지못한 채 계속 기다려야 할 수 있기 때문이다. 이러한 단점을 해결하기 위해 노화(aging) 기법이 존재한다.

3.3 노화기법 (aging)

노화 기법이란 기다리는 시간이 길어지면 우선순위를 조금씩 높여, 언젠가는 가장 높은 우선순위가 되어 CPU를 할당받을 수 있게 해주는 방법이다.

4. 라운드로빈 스케줄링

라운드로빈 스케줄링은 시분할 시스템 성질을 가장 잘 활용한 새로운 의미의 스케줄링 방식이라 할 수 있다. 라운드로빈 스케줄링에서는 각 프로세스가 CPU를 연속적으로 사용할 수 있는 시간이 특정 시간으로 제한된다.

제한된 시간이 경과하면 해당 프로세스로부터 CPU를 회수해 준비 큐에 줄 서 있는 다른 프로세스에게 CPU를 할당한다.

라운드로빈 스케줄링의 할당시간을 너무 길게 설정하면 이는 FCFS와 같은 결과를 나타나게 되고, 너무 짧게 설정할 경우엔 CPU 프로세스가 빈번하게 변경되어 문맥교환 오버헤드가 발생하게 된다. 따라서 일반적으로 할당시간은 수십 밀리초 정도의 규모로 설정하게 된다.

[운영체제 스터디] 프로세스와 쓰레드

Wed, 16 Mar 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

1. 프로세스

“Process is a program in execution”

✔️ 프로세스의 문맥(context)

CPU 수행 상태를 나타내는 하드웨어 문맥
- 하드웨어 문맥
  - Program Counter
  - 각종 register
프로세스의 주소 공간 (프로세스마다 각자의 주소공간을 가지고 있음)
- code, data, stack
프로세스 관련 커널 자료 구조
- PCB (Process Control Block)
- Kernel stack

✔️ 프로세스는 상태가 변경되며 수행된다

Running
- CPU를 잡고 Instruction을 수행중인 상태
Ready
- CPU를 기다리는 상태(메모리 등 다른 조건을 모두 만족하고)
Blocked (wait, sleep)
- CPU를 주어도 당장 Instruction을 수행할 수 있는 상태
- Process 자신이 요청한 event가 즉시 만족되지 않아 이를 기다리는 상태
Suspended (stopped)
- 외부적인 이유로 프로세스의 수행이 정지된 상태
  - 사용자가 프로그램을 일시 정지시킨 경우 (break key)
  - 메모리에 너무 많은 프로세스가 올라와 있을 때
  - 시스템이 특정한 이유로 프로세스를 잠시 중단시킨 경우
- 프로세스는 통째로 디스크에 swap out 된다.

❗New : 프로세스가 생성중인 상태

❗Termonated: 수행(execution)이 끝난 상태

❗Blocked: 자신이 요청한 event가 만족되면 Ready

❗Suspended: 외부에서 resume해 주어야 Active

🌟 프로세스 상태도

2. PCB

운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보
다음의 구성 요소를 가진다(구조체로 유지)
- OS가 관리상 사용하는 정보
  - process state, process ID
  - scheduling Information, priority
- CPU 수행 관련 하드웨어 값
  - Program counter, registers
- 메모리 관련
  - Code, data, stack의 위치 정보
- 파일 관련
  - Open file descriptors

3. 문맥 교환 (Context Switch)

✔️ CPU를 한 프로세스에서 다른 프로세르로 넘겨주는 과정

✔️ CPU가 다른 프로세스에게 넘어갈 때 운영체제는 다음을 수행

CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB에 저장
CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴
- 프로세스가 이전에 실행 중이던 상태부터 다시 실행하기 위해

문맥교환은 **Timer Interuppt**가 발생하거나 **I/O SystemCall**이 발생할 때 이뤄진다. 
사용자 프로그램이 **Interuppt**를 발생시키거나 **SystemCall**을 하여 사용자 모드에서 커널모드로 변경되는 것은
문맥교환이 아니다. 

사용자모드에서 커널모드로 변경되는 것도 문맥교환은 이러나지 않았지만 이전에 실행했던 
사용자 프로그램이 실행 중이던 정보를 PCB에 저장하기 때문에 약간의 문맥은 저장이 되지만
문맥교환처럼 프로세스 자체가 변경되는 것보다 오버헤드가 적다.

문맥교환이 발생하면 해당 프로세스가 사용하던 **Cache Memory**를 **Flush** 해야하기 때문에 커널모드와 사용자모드 
스위칭보다 상당한 오버헤드가 발생한다.

💡 프로세스의 문맥이란 프로세스 실행상태와 프로세스 자원 등 커널에서 관리하는 프로세스 실행 정보를 말한다.

4. 프로세스를 스케줄링하기 위한 큐

✔️ Job queue

현재 시스템 내에 있는 모든 프로세스의 집합

✔️ Ready queue

현재 메모리 내에 있으면서 CPU를 잡아서 실행되기를 기다리는 프로세스의 집합

✔️ Device queue

I/O device의 처리를 기다리는 프로세스의 집합

💡 이와 같은 큐는 소프트웨어 자원을 기다리는 경우에도 필요하다. 예를 들면 공유 데이터에 대한 접근 권한은 소프트웨어 자원으로 분류될 수 있다. 어떠한 프로세스가 공유 데이터를 사용하는 중에 다른 프로세스가 같은 데이터를 접근하면 일관성이 훼손될 수 있기 때문에 매 시점 하나의 프로세스만이 접근할 수 있도록 해야한다.

5. 스케줄러 (Scheduler)

✔️ Long-term scheduler (장기 스케줄러 or Job Scheduler)

시작 프로세스 중(new 상태의 프로세스) 어떤 것들을 ready queue로 보낼지 결정
프로세스에 메모리(및 각종 자원)을 주는 문제
degree of Multiprogramming을 제어
time sharing system에는 보통 장기 스케줄러가 없음 (무조건 ready 상태)
현대의 운영체제에는 장기 스케줄러가 없다

✔️ Short-term scheduler (단기 스케줄러 or CPU scheduler)

어떤 프로세스를 다음번에 running 시킬지 결정
프로세스에 CPU를 주는 문제
충분히 빨라야 함 (milliseconde 단위)

✔️ Medium-Tern Scheduler (중기 스케줄러 or Swapper)

여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄
프로세스에게서 memory를 뺏는 문제
degree of Multiprogramming을 제어

💡 스왑아웃 대상 0순위는 봉쇄상태의 프로세스다.

봉쇄상태의 프로세스를 스왑아웃 시켜도 메모리가 부족하면 타이머 인터럽트가 발생하여 준비큐로 이동하는 프로세스를 추가적으로 스왑아웃 시킨다.

준비큐에 너무 많은 프로세스가 존재하면 개별 프로세스에 배정되는 메모리양이 지나치게 적어지고 CPU를 한번 할당받은 후 다시 할당받기 까지 오랜 시간이 소요되기 때문이다.

6. Thread

“A Theard ( or Lightweigth process) is a basic unit of CPU utilization”

✔️ Thread의 구성 (CPU 수행과 관련)

program counter
register set
stack space

✔️ Thread가 동료 Thread와 공유하는 부분 (=task)

code section
data section
OS resource

✔️ 전통적인 개념의 heavyweight process는 하나의 thread를 가지고 있는 task로 볼 수 있다.

✔️ 다중 쓰레드로 구성된 태스크 구조에서는 하나의 서버 쓰레드가 블럭된 상태인 동안에도 동일한 태스크 내의 다른 쓰레드가 실행되어 빠른 처리가 가능하다.

✔️ 동일한 작업을 수행하는 다중 스레드가 협력하여 높은 처리율과 성능 향상을 얻을 수 있다.

✔️ 스레드를 사용하면 병렬성을 높일 수 있다.

멀티코어 컴퓨터에서 얻는 장점

✔️ 멀티 프로세스보다 멀티 스레드가 가볍다.

멀티 프로세스의 경우 각각의 프로세스마다 자원을 별도로 생성하는 반면, 멀티 스레드는 CPU 수행과 관련된 부분만 생성하고 code, data, os 자원같은 경우 프로세스의 메모리 영역을 참조한다.

💡 멀티 쓰레드 웹 서버를 예로 들면, 한 요청이 끝날 때까지 기다렸다가 다음 요청을 처리하는 게 아닌 쓰레드마다 각각의 요청을 처리할 수 있다.

7. Thread 의 장점

✔️ Responsiveness

multi-threaded
- 만약 하나의 Thread 블럭되면 (eg network) 또 다른 Thread 작업을 이어간다. (eg display)

✔️ Resource Sharing

여러개의 Thread 코드영역, 데이터 영역 등 프로세스 자원(CPU 수행에 필요한 자원)을 공유할 수 있다.

✔️ Economy

프로세스 문맥교환과 프로세스 생성은 Thread 스위칭, Thread 생성보다 오버헤드가 상당히 크다
- 솔라리스 운영체제의 경우 오버헤드가 각각 30배 5배

✔️ Utilization of MP Architecutres

각 쓰레드가 서로 다른 CPU에서 병렬적으로 수행될 수 있다. (멀티 프로세서 환경)

[운영체제 스터디] 컴퓨터 구조와 컴퓨터 시스템 동작원리

Tue, 15 Mar 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

1. 컴퓨터 구조

✔️ 전문가적 입장에서 컴퓨터를 말할 때, 보통 CPU와 Memory를 말한다.

✔️ 컴퓨터는 CPU, Memory, I/O Device, Disk, 네트워크 장비들로 이뤄져있다.

2. 컴퓨터 시스템 구조

✔️ CPU

CPU는 매 클럭사이클 마다 메모리에서 instruction을 하나씩 읽어서 실행한다.
instruction 수행이 종료되면 Interrupt Line을 체크하고 인터럽트 신호가 확인되면 수행한다.

✔️ Modebit

사용자가 프로그램의 잘못된 수행으로 다른 프로그램 및 운영체제에 피해가 가지 않도록 하기 위한 보호 장치
하드웨어적으로 두 가지 모드의 Operation 지원
- 1 → 사용자 모드로 사용자 프로그램을 실행한다.
- 0 → 커널모드로 OS 코드를 실행한다
보안을 해칠 수 있는 중요한 명령어는 커널 모드에서만 수행 가능한 특권명령으로 규정한다.
Interrupt나 Exeception이 발생하면 하드웨어가 mode bit를 0으로 변경하여 운영체제에게 CPU를 할당한다.
커널모드에서 작업이 끝나면 사용자모드로 변경하기 전에 mode bit를 1으로 변경한다.

✔️ Timer

특정 프로그램이 CPU를 독점하는 것을 방지하기위한 장치
운영체제가 사용자 프로그램에게 CPU를 넘겨줄 때 Timer에 값을 지정해서 넘겨준다.
타이머 값이 0이 되면 타이머가 CPU에게 인터럽트 신호를 발신한다.
타이머는 time sharing을 구현하기 위해 널리 이용됨
타이머는 현재 시간을 계산하기 위해서도 사용됨

✔️ Memory

메모리는 CPU가 처리할 데이터나 명령어가 임시로 저장되는 곳으로 작업 공간 역할을 한다.
컴퓨터 작업을 할 때 하드디스크에 있는 데이터는 먼저 메모리로 이동된 다음 CPU로 전송된다.
- 프로그램 실행도 이와 마찬가지로 CPU가 메모리에 저장되어 있는 용량만큼 프로그램을 작동시킨다.

✔️ I/O Device

각각의 I/O Device는 각 디바이스를 전담하는 Controller를 가지고 있다.
Controller는 각 I/O 디바이스의 내부를 통제하는 작업을 담당한다. CPU에게 인터럽트를 발생시키는 것도 Controller가 담당한다.
I/O Device는 CPU에 비해 처리속도가 상당히 느리다
I/O Device는 모두 각각의 Local Buffer를 가지고 있다.
I/O는 실제 device와 local buffer 사이에서 일어남

✔️ I/O Device Controller

I/O 장치유형을 관리하는 일종의 작은 CPU
제어 정보를 위해 control register, status register를 가짐
local buffer를 가짐 (일종의 data register)
Device controller는 I/O가 끝났을 경우 인터럽트로 CPU에 그 사실을 알림

✔️ DMA Controller

CPU와 동일하게 직접 메모리에 접근 가능한 컨트롤러
I/O device의 작업이 종료되어 localBuffer에 데이터가 적재되면 DMA 컨트롤러가 하드웨어 인터럽트를 CPU 대신 수신하여 데이터를 메모리에 복사한 후 합쳐서 CPU에게 인터럽트를 보낸다

✔️ 인터럽트 (Interrupt)

인터럽트 당한 시점의 레지스터와 프로그램 카운터를 저장한 후 CPU의 제어를 인터럽트 처리 루틴에 넘긴다.
넓은 의미의 인터럽트
- interuppt (하드웨어 인터럽트) : 하드웨어가 발생시킨 인터럽트
- trap (소프트웨어 인터럽트)
Exception: 프로그램이 오류를 범한 경우
System Call: 프로그램이 커널함수를 호출하는 경우
인터럽트 관련 용어
- 인터럽트 백터
  - 해당 인터럽트의 처리 루틴 주소를 가지고 있다.
- 인터럽트 처리 루틴
  - 해당 인터럽트를 처리하는 커널 함수

3. 입출력 (I/O)의 수행

모든 입출력 명령은 특권 명령이다.
사용자 프로그램이 I/O를 하는 방식
- 시스템콜(system call)
- 사용자 프로그램이 운영체제의 서비스를 받기위해 호출하는 것
trap을 사용하여 인터럽트 벡터의 특정 위치로 이동
제어권이 인터럽트 벡터가 가리키는 인터럽트 서비스 루틴으로 이동
올바른 I/O 요청인지 확인 후 I/O 수행
I/O 완료 시 제어권을 시스템콜 다음 명령으로 옮김

3. 동기식 입출력

✔️ 동기식 입출력은 어떤 프로그램이 입출력 요청을 했을 때

입출력 작업이 완료된 후에야 그 프로그램이 후속 작업을 수행할 수 있는 방식을 말한다.

🌟 동기식 입출력의 실행 방식 🌟

동기식 입출력은 프로그램이 디스크에서 어떤 정보를 읽어오라는 요청을 했을 때 디스크 입출력이 진행되는 동안 그 프로그램의 다음 명령을 수행하지 않고 기다린다. 그러다가 입출력이 완료되어 인터럽트를 통해 완료 사실이 전달된 후에야 CPU의 제어권이 해당 프로그램에게 넘어간다.

따라서 동기식 입출력에서 CPU는 입출력 연산이 끝날 때까지 인터럽트를 기다리며 자원을 낭비하게 된다. 한편 CPU의 명령 수행 속도는 빠르지만 입출력 장치에서 데이터를 읽어오는 등의 입출력 연산은 상대적으로 느리다.

그럼에도 불구하고 입출력이 완료될 때까지 대기했다가 사용자 프로그램에게 CPU의 제어권을 넘기는 방식은 자원 낭비를 초래한다.

따라서 일반적으로 프로그램이 입출력을 수행 중인 경우 CPU를 입출력을 실행한 프로그램에게서 빼앗아 다른 프로그램에게 할당하고 입출력을 수행중인 프로그램은 봉쇄상태로 변경한다.

4. 비동기식 입출력

비동기식 입출력은 프로그램이 디스크 정보를 요청하더라도 프로그램을 봉쇄상태로 이동하지 않고 다음 작업을 수행한다.

🌟 비동기식 입출력의 실행 방식 🌟

비동기식 입출력은 입출력 연산을 요청한 후에 연산이 끝나기를 기다리는 것이 아니라

CPU의 제어권을 입출력 연산을 호출한 그 프로그램에게 곧바로 다시 부여하는 것을 말한다.

어떤 프로그램이 데이터를 디스크에서 읽어오라는 요청을 했을 때 보통은 읽어온 결과를 이용해서 다음 연산을 수행하지만 경우에 따라서는 그 데이터와 관련없이 수행할 수 있는 일이 있을 것이다.

비동기식 입출력에서는 그러한 작업을 먼저 수행하고, 읽어오는 데이터가 반드시 이어야 수행할 수 있는 일들은 입출력이 완료된 후에 수행하게 된다.

또한 디스크에서 읽어오는 요청이 아니라 디스크에 쓰는 요청이라면 쓰기 작업이 완료되기 전에도 다음 명령을 수행할 수 있으므로 비동기식 입출력이 사용될 수 있다.

5. 프로그램의 구조와 실행

✔️ 프로그램의 구조와 인터럽트

프로그램이 CPU에서 명령을 수행하려면 해당 명령을 담은 프로그램의 주소 영역이 메모리에 올라가 있어야 한다. 이때 프로그램의 주소 영역은 크게 코드, 데이터, 스택 영역으로 구분된다.

✔️ 코드영역

코드영역은 작성한 프로그램의 함수들의 코드가 CPU에서 수행할 수 있는 기계어 명령 형태로 변환되어 저장되는 부분

✔️ 데이터 영역

전역 변수 등 프로그램이 사용하는 데이터를 저장하는 부분

✔️ 스택 영역

함수가 호출될 때 호출된 함수의 수행을 마치고 복귀할 주소 및 데이터를 임시로 저장하는 데에 사용되는 공간

✔️ 컴퓨터 시스템의 작동 개요

CPU는 빠른 속도로 처리하는 계산 능력은 가지고 있지만, 수행해야하는 작업을 스스로 결정하는 능력은 갖추고 있지 않다.
CPU는 매 시점 메모리의 특정 주소에 존재하는 명령어를 하나씩 읽어와서 그대로 실행한다.

이때 CPU가 수행해야 할 메모리 주소를 담고 있는 레지스터를 프로그램 카운터라고 부른다.
CPU는 매번 프로그램 카운터가 가리키는 메모리 위치의 명령을 처리하게 된다.

✔️ 프로그램의 실행

프로그램이 실행되고 있다는 것은 디스크에 존재하면 실행파일이 메모리에 적재된다는 의미와
프로그램이 CPU를 할당받고 명령을 수행하고 있는 상태라는 의미이다.
현재 수행 중인 프로그램을 프로세서(process)라고 부른다.
각 프로그램은 코드, 데이터, 스택영역과 같은 주소 공간을 별도로 가진다
프로그램마다 독자적으로 존재하는 주소공간을 가상메모리 또는 논리적 메모리라고 부른다.

[질문 리스트]

사용자 프로그램이 I/O를 요청했을 때 일어나는 일을 설명해보시오
- 사용자는 직접 입출력 장치에 접근할 수 없기 때문에 시스템 콜을 하여 운영체제에게 I/O 작업을 요청한다. 운영체제는 요청받은 I/O 명령을 사용자 프로그램 모드가 아닌 커널 모드에서 해당 요청에 맞는 처리코드를 수행하게 된다. 예를 들어 디스크에서 자료를 읽어오는 시스템 콜이라면, CPU가 디스크 컨트롤러에게 데이터를 읽어오라는 명령을 내린다.
DMA 컨트롤러의 기능을 설명해주세요.
- CPU가 입출력 장치들의 메모리 접근 요청에 의해 자주 인터럽트 당하는 것을 막아주어서 CPU에 발생하는 인터럽트의 빈도를 줄여 CPU를 효율적으로 관리할 수 있게 도와주는 역할을 한다.
- DMA를 사용하면 CPU가 로컬버퍼에서 메모리로 읽어오는 작업을 DMA가 대행한다.
- DMA는 바이트 단위가 아니라 블록이라는 큰 단위로 정보를 메모리로 읽어온 후에 CPU에게 인터럽트를 발생시켜 작업이 끝난 것을 알린다.
시스템콜에 대해 설명해보세요
- 시스템 콜이란 사용자 프로그램이 특권명령을 수행하기 위해 운영체제에게 해당 작업을 요청하는 행위이다. 시스템 콜은 일종의 소프트웨어적인 인터럽스로서 사용자 프로그램이 시스템 콜을 할 경우 트랩이 발생해 CPU의 제어권이 운영체제로 넘어가게 된다. 그러면 운영체제는 해당 시스템 콜을 처리하기 위한 루틴으로 가서 정의된 명령을 수행한다.

[운영체제 스터디] 운영체제란 무엇인가?

Mon, 14 Mar 2022 00:00:00 +0900

🌟 본 게시물은 이화여자대학교 반효경 교수님 강의를 참고로 작성한 게시물 입니다. 틀린 내용은 꼬옥 지적 부탁드립니다 ! 🌟

1. 운영체제란 무엇인가?

컴퓨터 하드웨어 바로 윗단에 설치되는 소프트웨어를 말한다. 운영체제는 하드웨어와 소프트웨어를 연결하는 소프트웨어 계층이다.

✔️ 운영체제의 주요역할

하드웨어 자원을 효율적으로 관리
사용자가 컴퓨터를 쉽게 다룰 수 있게 GUI 인터페이스 제공

✔️ 자원이란 CPU, 메모리, 하드웨어 뿐만 아니라 소프트웨어 자원까지 포함하여 부르는 말이다. 자원관리는 운영체제의 중요한 역할 중 하나이다*

✔️ 협의의 운영체제(커널)

운영체제의 핵심 부분으로 전원이 켜짐과 동시에 메모리에 상주하는 부분

✔️ 광의의 운영체제

커널 뿐만 아니라 각종 시스템 유틸리티를 포함한 개념
항상 메모리에 올려두는 것이 아닌 별도의 프로그램으로서 사실상 운영체제의 일부라고 보긴 어렵지만 운영체제와 함께 설치되기 때문에 넓은 의미로 포함시킨다.

2. 운영체제의 목적

✔️ 운영체제의 핵심은 하드웨어를 효율적으로 관리할 수 있게 하는 것

✔️ 주어진 자원으로 최대한의 성능을 내도록

✔️ 사용자가 컴퓨터를 편리하게 사용할 수 있는 환경을 제공하는 것

사용자간의 형평성 있는 자원 분배

✔️ 사용자 및 운영체제 자신을 보호

✔️ 프로세스, 파일, 메세지(소프트웨어 자원) 등을 관리

✔️ 운영체제의 자원? (하드웨어)

CPU, RAM, IO 장치 등등

3. 운영 체제의 분류

✔️ 동시 작업 가능 여부

단일 작업(sigle tasking)
- 한 번에 하나의 작업만 처리
다중 작업(multi tasking)
- 동시에 두 개 이상의 작업 처리
- 현대의 운영체제 들은 대부분 다중 작업이 가능한 운영체제

✔️ 사용자의 수

여러 사용자가 동시에 접근할 수 있는지를 기준으로 구분

단일 사용자(sigle user) 예 ) MS-DOS, MS Windows
다중 사용자(multi user) 예 ) UNIX, NT server

✔️ 처리 방식

일괄 처리(bath processing)
- 작업 요청의 일정량 모아서 한꺼번에 처리
- 작업이 완전 종료될 때까지 기다려야함 예 ) 초기 Punch Card 처리 시스템
시분할(time sharing)
- 여러 작업을 수행할 때 컴퓨터 처리 능력을 일정한 시간 단위로 분할하여 사용
- 일괄 처리 시스템에 비해 짧은 응답을 가짐
- interactive한 방식
- 범용 컴퓨터의 처리방식
실시간(Realtime OS)
- 정해진 시간 안에 어떠한 일이 반드시 종료됨이 보장되어야 하는 실시간 시스템을 위한 OS 예 ) 원자로/공장 제어, 미사일 제어, 반도체 장비, 로보트 제어
실시간 시스템의 개념 확장
- Hard realtime system (경성 실시간 시스템)
- Soft realtime sysytem(연성 실시간 시스템)

✔️ 몇 가지 용어

Multitasking (여러 프로그램이 실행되는 것)
Multiprogramming (메모리에 여러 프로그램이 올라가있음을 강조)
Time sharing (Multitasking과 유사하지만 CPU 강조)
Multiprocess
Multiprocessor
- 하나의 컴퓨터에 CPU(processor)가 여러 개 붙어 있음을 의미
구분
- 위의 용어들은 컴퓨터에서 여러 작업을 동시에 수행하는 것을 뜻한다
- Multiprogramming은 여러 프로그램이 메모리에 올라가 있음을 강조
- Time Sharing은 CPU의 시간을 분할하여 나누어 쓴다는 의미를 강조

✔️ 운영 체제의 예

UNIX
- 코드의 대부분을 C언어로 작성 됨
- 높은 이식성
- 최소한의 커널 구조
- 복잡한 시스템에 맞게 확장 용이
- 소스 코드 공개
- 프로그램 개발에 용이
- 대형 컴퓨터를 위해 만들어짐
- 다양한 버전
  - System V, FreeBSD, SunOs, Solaris
  - Linux (Unix 소스코드 기반)
DOS(Disk Operating System)
- MS사에서 1981년 IBM-PC를 위해 개발
- 단일 사용자용 운영체제, 메모리 관리 능력의 한계(주 기억 장치 : 640KB)
MS Windows
- MS사의 다중 작업용 GUI 기반 운영 체제
- Plug and Play, 네트워크 환경 강화
- DOS용 응용 프로그램과 호환성 제공
- 불안정성 (초창기 Windows)
- 풍부한 자원 소프트웨어
Hanheld device를 위한 OS
- PalmOS, Pocket PC (WinCE), Tiny OS

4. 운영체제의 구조

CPU, Memory, I/O Device, Disk (운영체제는 각 자원들을 관리한다)

✔️ CPU 스케줄링

어떤 프로그램에게 우선순위를 할당할지?
- 짧은 간격으로 프로그램을 교체 함 (시분할)
- 프로그램이 실행된 순서대로 우선순위를 할당하면 작업이 길어질 경우 나머지 프로그램 응답시간이 길어지기 때문에 사용하지 않는다.

✔️ 메모리 관리

한정된 메모리를 어떻게 관리하나?
- 프로그램 실행에 필요한 최소한의 정보만을 메모리에 올려 둠
- CPU에서 사용될 가능성이 낮은 정보들을 DISK에 내려둔다.
- CPU에서 사용될 가능성이 낮은 정보를 어떻게 판단하는지?
  - 데이터가 메모리에 올라간 이후로 자주 사용된 데이터이면 사용될 가능성이 높은 정보로 판단한다

✔️ DISK 파일관리

DISK 스케줄링 (엘리베이터 스케줄링과 유사함 CPU 스케줄링과는 다르다)
- DISK에 들어온 요청들을 HEAD와 가까운 위치에 들어온 요청이 있다면 먼저 처리하고 DISK HEAD의 이동을 최소화한다.

✔️ I/O Device

다른 자원들에 비해 느리다.
입출력관리 인터럽트
- I/O Device가 작업을 처리해야할 경우 CPU에게 인터럽트 신호를 준다

[질문 리스트]

운영체제의 정의를 설명하고 그 기능에 대해 아는대로 설명해주세요
- 운영체제는 컴퓨터 하드웨어 바로 위에 설치되어 사용자 및 다른 소프트웨어와 하드웨어를 연결하는 소프트웨어 계층이다. 운영체제는 사용자가 컴퓨터를 쉽게 다룰 수 있게 GUI 인터페이스 제공하고, 하드웨어 자원을 효율적으로 사용할 수 있게 도와준다.
운영체제 운용 방법 중 하나인 시분할 시스템에 대해서 설명해주세요
- 시분할 시스템은 여러 작업을 수행할 때 CPU를 일정한 시간 단위로 프로그램에게 할당하여 처리해줌으로써 각 사용자에게 독립된 컴퓨터를 사용하는 느낌을 준다. 라운드 로빈(Round Robin)방식이라고도 한다.
- 하나의 CPU는 같은 시점에서 여러 개의 작업을 동시에 수행할 수 없기 때문에, CPU의 전체 사용시간을 작은 작업 시간량으로 쪼개어그 시간량 동안만 번갈아가면서 CPU를 할당하여 각 작업을 처리하는 방법이다.모든 작업이 동시에 진행되는 것처럼 대화식 처리가 가능하다. 각 작업에 대한 응답시간을 최소화 하는 것이 목적이다.
운영체제의 개념을 좁은 의미와 넓은 의미로 나누어 간략하게 설명하세요
- 운영체제의 좁은 의미는 운영체제 커널을 의미하고 커널은 운영체제의 핵심 부분임으로 전원이 켜짐과 동시에 메모리에 상주합니다. 운영체제의 넓은 의미는 운영체제의 커널과 각종 주변 유틸리티 시스템을 포함한 개념입니다.

SpringFramework - Web ApplicationContext

Mon, 21 Feb 2022 19:31:29 +0900

1. IoC 컨테이너 : 빈 팩토리와 애플리케이션 컨텍스트

스프링 애플리케이션에서는 오브젝트의 생성과 관계설정, 사용, 제거 등의 작업을 애플리케이션 코드 대신 독립적인 컨테이너가 담당한다.
이를 컨테이너가 코드 대신 오브젝트 제어권을 갖고있다고 해서 IoC 라고 부른다. 그래서 스프링 컨테이너를 IoC 컨테이너 라고도 한다.
스프링에선 IoC를 담당하는 컨테이너를 빈 팩토리 또는 애플리케이션 컨텍스트라고 부르기도 한다.
오브젝트의 생성과 오브젝트 사이의 런타임 관계를 설정하는 DI 관점으로 볼 때는 컨테이너를 빈 팩토리라고 한다.
그런데 스프링 컨테이너는 단순한 DI 작업보다 더 많은 일을 한다. DI를 위한 빈 팩토리에 엔터프라이즈 애플리케이션을 개발하는 데 필요한 여러 가지 컨테이너 기능을 추가한 것을 애플리케이션 컨텍스트라고 부른다.

❗ApplicationContext는 beacFactory interface를 상속받고 있지만, 위임하는 것 외에 다른 로직은 구현하지 않는다.

2. Web ApplicationContext

스프링 애플리케이션에서 가장 많이 사용되는 ApplicationContext는 바로 WebApplicationContext 이다. WebApplicationContext는 ApplicationContext를 확장한 인터페이스이므로 정확히는 WebApplicationContext를 구현한 클래스를 사용하는 셈이다.
웹 애플리케이션에서 만들어지는 IoC 컨테이너는 WebApplicationContext 인터페이스를 구현한 것임을 기억해두자.
WebApplicationContext의 특징은 자신이 만들어지고 동작하는 환경인 웹 모듈에 대한 정보에 접근할 수 있다는 점이다. 이를 이용해 웹 환경으로부터 필요한 정보를 가져오거나, 웹 환경에 스프링 컨테이너 자신을 노출할 수 있다. 컨테이너가 웹 환경에 노출되면 같은 웹 모듈이 들어 있는 스프링 빈이 아닌 일반 오브젝트와 연동될 수 있다.

3. Web ApplicationContext 계층구조

웹 애플리케이션 레벨에 등록되는 컨테이너는 보통 루트 웹 애플리케이션 컨텍스트라고 불린다.
루트 웹 애플리케이션 컨텍스트는 서블릿 레벨에 등록되는 컨테이너들의 부모 컨테이너가 되고, 일반적으로 전체 계층구조 내에서 가장 최상단에 위치한 루트 컨텍스트가 되기 때문이다.
웹 애플리케이션에는 하나 이상의 스프링 애플리케이션의 프론트 컨트롤러 역할을 하는 서블릿이 등록될 수 있다(디스패쳐 서블릿은 프론트 컨트롤러 패턴으로 구현되었음)
등록된 서블릿에는 각각 독립적으로 애플리케이션 컨텍스트가 만들어진다. 이런 경우 각 서블릿이 공유하게 되는 공통적인 빈들이 생길 수 있다.
공통적으로 사용하는 빈을 루트 웹 애플리케이션 레벨의 컨텍스트에 등록하면 공통되는 빈들이 서블릿별로 중복돼서 생성되는 것을 방지할 수 있다.
하지만 하나의 서블릿이 모든 애플리케이션 요청을 처리하는 프론트 컨트롤러 패턴으로 구현되었기 때문에 여러개의 서블릿 컨테이너를 생성하는 것은 드물다

❗여러개의 자식 컨테이너를 생성하는 것이 아닌데 계층 구조를 사용하는 이유는?

그 이유는 전체 애플리케이션에서 웹 기술에 의존적인 부분과 그렇지 않은 부분을 구분하기 위해서이다. 스프링을 이용하는 웹 애플리케이션이라고 해서

반드시 스프링 웹 서블릿 만들 필요는 없다. 스프링 기술을 사용하고 스프링 빈으로 만들지만 웹을 담당하는 프레젠테이션 계층은 스프링 외의 기술을 사용하는 경우도 종종 있기 때문이다.

4. 부모 컨텍스트를 이용한 계층구조 효과

모든 애플리케이션 컨텍스트는 부모 애플리케이션 컨텍스트를 가질 수 있다.
계층구조 안의 모든 컨텍스트는 각자 독립적인 설정정보를 이용해 빈 오젝트를 만들고 관리한다.
각자 독립적으로 자신이 관리하는 빈을 갖고 있긴 하지만 DI를 위해 빈을 찾을 떄는 부모 애플리케이션의 빈까지 모두 검색한다.
먼저 자신이 관리하는 빈 중에서 필요한 빈을 찾아보고, 없으면 부모 컨텍스트에게 빈을 찾아달라고 요청한다. (빈을 찾지 못할 경우 계층구조를 따라서 가장위에 존재하는 루트 컽넥스트까지 요청이 전달 됨)
자신과 부모 컨텍스트에 동일한 빈이 존재한다면, 자신이 갖고있는 빈이 우선시 된다. (빈 검색 순서는 자신이 먼저이고, 그 다음 직계 부모의 순서이다.)

❗중요한 건 자신의 부모 컨텍스트에게만 빈을 요청하고, 자식 컨텍스트에게는 요청하지 않는 점이다. 그런 이유로 같은 레벨에 있는 형제 컨텍스트의 빈도 찾을 수 없다.

5. Web ApplicationContext 의 Root Context 가 어떻게 결정되나?

WAS 가 구동될 때 Web.xml 의 설정 정보를 리딩한다.
리딩되면서 SpringContextLoader가 Web.Xml의 contextConfigLocation 의 파일경로를 스캔하고 root-context로 생성한다.

❗dispatcher-servlet context 안에서도 contextConfigLocation 을 생성하고 있는데 context-param 안의 contextConfigLocation가 root-context 인 이유는?

자세하진 않지만 .. context-param 과 init-param 의 차이는 전역변수, 지역변수의 개념과 비슷하다. context-param 안에서 생성된 빈은 모든 서블릿에서 사용할 수 있다.

init-param으로 생성된 빈들은 해당 서블릿 안에서만 참조가 가능하다. 이런 이유 때문에 context-param 안에 생성된 contextConfigLocation를 root-context 로 인식하는게 아닐까 싶다.

아직 작성 중 …

SpringBoot - Redis Client 적용기

Wed, 16 Feb 2022 00:00:00 +0900

들어가며

스프링부트 Redis 적용 방법을 공유하고자 게시물을 작성하였다. 예제코드로 적용 방법을 알아보자

🌟 Redis 의존 설정

Spring은 다양한 Redis 의존설정 방법을 제공한다.

1 - Gradle이나 Maven 설정 파일에 의존 추가하기

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-data-redis'
}

2 - Intellij tool 을 사용하여 SpringBoot 프로젝트 생성시점에 Spring Data Redis 를 추가하는 방법이다.

3 - Spring initializr 로 프로젝트 생성 시점에 Spring Data Redis 추가하기

💡 참고로 Springboot 2 부터는 Lettuce가 기본 Redis Client로 사용된다. 본 프로젝트도 Lettuce를 사용하였다

🌟 Application.yml 설정

정말 간단하게 Redis 의존을 추가했다. 이제 남은 건 Application.yml 작성과 Redis Configuration Bean 만 등록하면 된다. 아마도

ymal 작성은 매우 간단하다.

spring:
	redis:
		lettuce:
			pool:
				max-active: 1000
				max-idle: 500
				min-idle: 2
				max-wait: 1000
	port: 6379
	host: 127.0.0.1
	password: 'vldpsxl1q2w3e'

Redis 에 관한 정보만 입력한다고 가정하면 이게 끝이다. 설정 정보는 아래 표 참조 바람

Redis Option

파라미터	파라미터 설명	기본값
spring.redis.pool.max-active	pool에 할당할 수 있는 최대 커넥션 수 (음수는 무제한)	8
spring.redis.pool.max-idle	pool의 “idle” 커넥션 최대수 (음수는 무제한)	8
spring.redis.pool.max-wait	사용 가능한 커넥션이 없을 때 호출자가 대기해야하는 최대 시간 (단위 : 밀리초, 음수는 무제한 차단)	-1
spring.redis.pool.min-idle	pool에서 관리하는 “idle” 커넥션 최소수 (양수일 떄만 유효)	0
spring.redis.port	redis server port	6379
spring.redis.host	redis server host	127.0.0.1
spring.redis.password	redis server login password
spring.redis.timeout	커넥션 타임아웃 (단위: 밀리세컨드)	0
spring.redis.database	커넥션 팩토리에 사용되는 데이터베이스 인덱스	0

🌟 RedisConnectionFactory, RedisTemplate 설정하기

순조롭게 Yaml 파일 설정도 끝이났다. 이제는 Java를 사용해서 기존에 xml 파일로 설정했던 RedisFactory, RedisTemplate를 변경해보자.

XML

<!-- Redis 설정 고통 부분-->
<!-- Redis Serializer -->
<bean id="stringRedisSerializer" class="org.springframework.data.redis.serializer.StringRedisSerializer" />
<bean id="jsonRedisSerializer" class="org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer" />
<bean id="jackson2JsonRedisSerializer" class="org.springframework.data.redis.serializer.Jackson2JsonRedisSerializer">
    <constructor-arg>
        <value>java.util.Map</value>
    </constructor-arg>
</bean>

<!-- Redis Template -->
<bean id="redisTemplate" class="org.springframework.data.redis.core.RedisTemplate">
    <property name="connectionFactory" ref="jedisConnFactory" />
    <property name="keySerializer" ref="stringRedisSerializer" />
    <property name="valueSerializer" ref="jsonRedisSerializer" />
    <property name="hashKeySerializer" ref="stringRedisSerializer" />
    <property name="hashValueSerializer" ref="jsonRedisSerializer" />
</bean>

JAVA

RedisTemplate 설정

@Configuration
@EnableRedisRepositories
public class RedisTemplateConfig {

		@Value("${spring.redis.host}")
    private String redisHost;
		@Value("${spring.redis.port}")
    private int redisPort;

		@Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(redisHost,redisPort);
		}

    @Bean
    public RedisTemplate<String,Object> redisTemplate() {
        RedisTemplate<String,Object> redisTemplate = new RedisTemplate<>();
				redisTemplate.setKeySerializer(new StringRedisSerializer());
				redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());
				redisTemplate.setHashKeySerializer(new StringRedisSerializer());
				redisTemplate.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());
				return redisTemplate;
		}
}

기존 xml 파일은 번거롭게 Serializer 클래스를 매번 bean으로 등록해서 redisTemplate에 주입했다. 그런데 자바코드는 간단하게 인스턴스만 생성해서 주입하고 있는 것을 확인할 수 있다.

💡 참고로 RedisTemplate는 RedisTemplate뿐만 아니라 StringRedisTemplate 도 존재한다. 게시물 주제와 연관이 없으므로 자세한 내용은 생략한다.

🌟 Redis Message Listener

이제 Redis Message Listener를 등록해보자.

XML

<!--첫번째-->
 <bean id="redisKeyExpireMessageListener" class="org.springframework.data.redis.listener.adapter.MessageListenerAdapter">
        <constructor-arg>
            <bean class="framework.redis.RedisKeyExpireMessageListener" />
        </constructor-arg>
    </bean>

<!--두번째-->
  <bean id="redisContainer1" class="org.springframework.data.redis.listener.RedisMessageListenerContainer">
      <property name="connectionFactory" ref="jedisConnFactory"/>
      <property name="messageListeners">
          <map>
              <entry key-ref="redisKeyExpireMessageListener">
<!--세번째-->
                  <bean class="org.springframework.data.redis.listener.PatternTopic">
                      <constructor-arg value="__keyevent@*:expired"/>
                  </bean>
              </entry>
          </map>
      </property>
  </bean>

MessageListenerAdapter 빈에 MessageListener 를 주입한다.
RedisMessageListenerContainer 빈 등록 connectionFactory, messageListeners 주입
redisKeyExpireMessageListener 가 수신할 채널 혹은 패턴을 등록한다. 패턴은 이벤트 또는 채널명이 될 수 있다.

JAVA

MessageListenerAdapter 추가

	@Bean
  public MessageListenerAdapter messageListenerAdapter(RedisKeyExpireMessageListener redisKeyExpireMessageListener) {
      return new MessageListenerAdapter(redisKeyExpireMessageListener);
  }

  @Bean
  public RedisMessageListenerContainer redisMessageListenerContainer(
          RedisConnectionFactory redisConnectionFactory
          , MessageListenerAdapter messageListenerAdapter, PatternTopic patternTopic) {
      RedisMessageListenerContainer container = new RedisMessageListenerContainer();
      container.setConnectionFactory(redisConnectionFactory);
      container.addMessageListener(messageListenerAdapter, patternTopic);
      return container;
  }

	@Bean
  public PatternTopic patternTopic() {
      return new PatternTopic("__keyevent@*:expired");
  }

MessageListenerAdapter 에 주입할 MessageListener 구현

@Component
public class RedisKeyExpireMessageListener implements MessageListener {
    @Override
    public void onMessage(Message message,byte[] pattern) {
				
    }
}

❗ spring boot 의 @EnableAutoConfiguration

spring boot 는  프로젝트에 추가된 라이브러리를 기반으로 실행에 필요한 환경을 자동으로 설정해준다.
어떻게 보면 정말 편리한 기능이지만, 섬세한 설정이 필요한 경우엔 직접 설정하는 것이 안전하다.

🌟 Redis Cache Management

XML

<!-- redis Cache 설정 -->
  <bean id="redisCachePrefix" class="org.springframework.data.redis.cache.DefaultRedisCachePrefix" >
      <constructor-arg name="delimiter" value="_" />
  </bean>

  <bean id="cacheManager" class="org.springframework.data.redis.cache.RedisCacheManager" primary="true">
      <constructor-arg ref="redisTemplate" />
      <property name="defaultExpiration" value="1000" />
      <property name="usePrefix" value="true"/>
      <property name="cachePrefix" ref="redisCachePrefix" />
  </bean>

JAVA

@EnableCaching 어노테이션 추가

@SpringBootApplication
@EnableCaching
public class SpringBootStudyApplication {

  public static void main(String[] args) {
      SpringApplication.run(SpringBootStudyApplication.class, args);
  }
}

@EnableCaching 어노테이션은 @Cacheable 메소드가 호출될 때 사용되는 CacheInterceptor 및 Proxy 또는 AspectJ 같은 캐시 관리에 필요한 스프링 구성요소를 등록하는 역할을 한다.

@EnableCaching 어노테이션 뿐만 아니라 xml 파일에서 cacheManger 를 선언해서 사용할 때도 동일하게 동작한다.

CacheManagerConfig.class

@Configuration
@RequiredArgsConstructor
public class CacheManagerConfig {

  private final RedisCacheConfig redisCacheConfig;

	@Bean
  public CacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
      return RedisCacheManager.RedisCacheManagerBuilder
              .fromConnectionFactory(redisConnectionFactory)
              .cacheDefaults(getDefaultRedisCacheConfiguration())
              .build();
	}

  private RedisCacheConfiguration getDefaultRedisCacheConfiguration() {
      return RedisCacheConfiguration.defaultCacheConfig()
              .entryTtl(Duration.ofSeconds(redisCacheConfig.getTtl()))
              .prefixCacheNameWith(redisCacheConfig.getCachePrefix());
	}

}

RedisCacheConfig.class

@Component
@ConfigurationProperties(prefix="config.redis.cache")
@Getter
@Setter
public class RedisCacheConfig {
    private String cachePrefix;
    private long ttl;
}

application.yml

config:
  redis:
      cache:
        cache-ttl: 1000
        cache-prefix: "_"

🌟 Lettuce를 선택한 이유

마지막으로 Redis Client로 Lettuce를 선택한 이유를 설명하고자 한다.

Lettuce란?

lettuce는 Netty 기반의 Redis Client로 동기, 비동기 및 대응적 사용을 위해 확장 가능한 Thread-Safe Redis Client이다.

트랜잭션을 사용하지 않는 경우 하나의 연결을 공유할 수 있다. 추가로 Sentinel, Cluster, Pipelining, Auto-Reconnect 및 Redis 데이터 모델과 같은 고급 Redis 기능을 지원한다.

Lettuce 장점

connection 인스턴스를 여러 쓰레드에서 공유할 수 있기 때문에 Thread-safe하다.
Lettuce는 비동기로 요청을 처리하기 때문에 성능적인 이점이 있다. (비동기, 동기 둘 다 지원하기 때문에 유연하게 사용가능)
Jedis보다 다양한 DataType지원

❗connection 인스턴스를 여러 쓰레드에서 공유할 수 있는 것이 장점인 이유는?

Redis 서버 인스턴스는 여러 클라이언트에 연결하여 명령을 동시에 보내고 받을 수 있지만, 명령을 실행할 때 각 인스턴스는 단일 스레드이다.
    
이는 애플리케이션이 멀티스레딩+단일 연결을 통해 Redis를 운영할 수 있다면 Redis 서버의 전체 연결 수를 효율화 할 수 있고,
    
여러 애플리케이션이 동일한 Redis 서버를 공유할 때 더 나은 안정성과 성능을 얻을 수 있다는 것을 의미한다.
    
응용 프로그램의 경우 여러 인스턴스를 유지 관리하는 리소스 소비가 줄어든다.

Lettuce 단점

connection 인스턴스의 공유라는 점에서 Thread-safe 한 것이기 때문에 Single-Thread로 동작하는 애플리케이션에서 레디스 데이터에 접근할 때는 또다르게 고려할 점이 생긴다.
하나의 connection을 공유하기 때문에 connection pool을 생성하지 않으면 transaction을 사용할 수 없다.

🌟 Jedis와 Lettuce 비교

그렇다면 Jedis와 Lettuce의 차이점이 무엇이길래 Springboot2 이후로는 Lettuce가 기본 Redis Client로 선택되었는지 알아보자

Jedis보다 뛰어난 성능

Type	TPS(낮을수록 응답속도 빠름)	Redis CPU	Connections	응답 속도
Jedis	31.000	20%	515	1000ms
Lettuce	100,000	7%	6	7.5ms

Jedis와 Lettuce 기능비교

Supported Feature	Lettuce	Jedis
Standalone Connection	O	O
Master/Replica Connection	O
Redis Sentinel	Master Lookup, Sentinel Authentication, Replica Redis	Master Lookup
Redis Cluster	Cluster Connection, Cluster Node Connection, Replica Reads	Cluster Connection, Cluster Node Connection
Transport Channers	TCP, OS-native TCP(epoll, kqueue), Unix Domain Sockets	TCP
Connection Pooling	O(using commons-pool2)	O(using commons-pool2)
Other Connection Features	Singleton-connection sharing for non-blocking commands	JedisShardInfo support
SSL Support	O	O
Pub/Sub	O	O
Pipelining	O	O
Transactions	O	O
DataType Support	Key, String, List, Set, Sorted Set, Hash Server, Stream, Scriping, Geo, HyperLogLog	Key, String, List, Set, Sorted Set, Scriping, Geo, HyperLogLog
Reactive (non-blocking) API	O	O

참고 → O 표시는 지원되는 기능이다.

표로 jedis와 Lettuce의 기능을 비교해본 결과, 두 가지 차이점을 찾을 수 있다.

Jedis에서 지원하는 모든 기능을 Lettuce에서도 지원한다.
Jedis에서 지원하지 않는 기능도 Lettuce에서 지원한다.

🌟Reference

http://arahansa.github.io/docs_spring/redis.html

https://wnwngus.tistory.com/64

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/cache/annotation/EnableCaching.html

https://segmentfault.com/a/1190000040331000/en

https://mandlife.tistory.com/entry/Springboot-redis-설정-Jedis보다는-Lettuce