고라니는 코딩중 ‍

[Kotlin in Action] 1.코틀린이란 무엇이며 왜 필요한가

예민한고라니 — Sun, 5 Feb 2023 13:28:54 +0900

코틀린 주요 특성

정적 타입 지정 언어
- 자바와 마찬가지로 코틀린도 정적 타입 (statically typed) 지정 언어
  - 모든 프로그램 구성요소의 타입을 컴파일 시점에 알 수 있음
  - 객체의 필드나 메서드를 사용할때 마다 컴파일러가 타입을 검증해줌
  - +) 대표적인 동적타입 지정언어로는 그루비나 JRuby가 있음
- 자바와 달리 코틀린에서는 모든 변수의 타입을 프로그래머가 명시할 필요가 없음.
  - 대부분의 경우 코틀린 커파일러가 문맥으로부터 변수 타입을 자동으로 유추할 수 있기 떄문
  - 이런 기능을 타입 추론 (type inference)라고 부름
- 정적 타입의 장점
  - 성능 : 실행시점에 어떤 메서드를 호출할지 알아내는 과정이 필요 없으므로 메소드 호출이 더 빠름
  - 신뢰성 : 컴파일러가 프로그램의 정확성을 검증하기 떄문에 프로그램 오류로 중단될 가성 작음
  - 유지보수성 : 객체의 타입을 알수 있어서 처음보는 코드를 다룰때도 쉬움
  - 도구지원 : 정적 타입 지정을 활용하면 더 안전히 리팩토링 할 수 있음
- type system에서 자바와 다른 새로운 점
  - 코틀린은 널이 될 수 있는 타입(nullable type)을 지원함
    - 컴파일 시점에 null pointer exception 여부를 검사할 수 있어 신뢰성이 상승함 (6장에 추가 설명)
  - 함수 타입 (function type)에 대한 지원
함수형 프로그래밍 과 객체지향 프로그래밍
- 함수형 프로그래밍 특징
  - first-class. 함수를 일반값처럼 다룰수도, 변수에 저장할수도, 함수를 인자로 다른 함수에 전달할수도 있음
  - immutability. 한번만들어지면 내부상태가 절때 바뀌지 않는 불변객체를 사용함
  - side-effect 없음. 입력이 같으면 출력이 항상같음 → 함수 외부나 바깥과 상호작용하지 않음
- 장점
  - 간결성
  - safe multithreading
  - 테스트가 쉬움
- 자바도 8부터는 지원하지만, 코틀린은 초기부터 함수형 프로그래밍을 풍부하게 지원해왔음
무료 오픈소스

코틀린 응용

코틀린 서버 프로그래밍
- 서버 프로그래밍에는 광범위한 분야들이 포함됨
  - 브라우저에 html 페이지를 돌려주는 웹
  - JSON API를 제공하는 BE
  - RPC 프로토콜로 서로 통신하는 마이크로 서비스
- 코틀린은 자바코드와 매끄럽게 상호운용한다는 장점 존재
- 동시에, 몇가지 새로운 기술을 활용해 서버 시스템 개발가능
  - 예를들어 코틀린의 빌더 패턴(Builder pattern)활용하면 간결한 구문 사용해 그래프를 쉽게 구축하면서도 코드 재활용을 지속적으로 누릴 수 있음
  - 다른예로 영속성 프레임워크를 들수 있음. SQL DB 구조를 기술할 수 있는 읽기쉬운 DSL 제공

코틀린의 철학

코틀린은 자바와의 상호운용성에 초점을 맞춘 실용적이고 간결하며 안전한 언어

실용성
- 실제 문제를 해결하기위해 만들어진 실용적 언어이며 연구를 위한 언어가 아님
- 코틀린은 어느 특정 프로그래밍 스타일이나 패러다임을 사용할 것을 요구하지 않음
- 항상 도구의 활용을 염두에 두고 설계되어왔음
간결성
- 개발자는 기존의 코드를 읽는 시간이 더 길다. 따라서 간결한 코드는 내용파악에 도움 됨
- 코틀린은 별 뜻은 없지만 꼭 넣어야하는 부수적인 요소를 줄이기 위해 노력함
  - ex) getter, setter 등
- 그렇다고 소스코드가 짧다 ≠ 간결하다
안전성
- 안전하다 = 일부 유형의 오류를 프로그램 설계가 원천적으로 방지해준다는 의미
  - 대게 생산성과 안전성 사이에는 trade off 관계가 설립한다.
- JVM에서 실행되는 정적타입언어로서 코틀린은 애플리케이션 타입 안전성을 보장함
  - but, 자바보다 더 적은 비용으로 타입 안전성 사용가능 → 직접 타입 정보를 지정할 필요가 없기 때문임
- 더 나아가 컴파일 시점 검사를 통해 오류를 더 많이 방지해줌
  - 특히 NullPointerException을 없애기 위해 노력함
    - 발생할 수 있는 연산을 사용하는 코드를 금지하기 때문
  - classCastException도 방지해줌
    - 어떤 객체를 다른 타입으로 cast 하기 전에 미리 검사하지 않으면 발생할 수 있음
    - 코틀린에서는 타입 검사와 캐스트가 한 연산자에 의해 이뤄짐
상호운용성
- 라이브러리가 어떤 API를 제공하던 코틀린에서 그 API를 활용할 수 있음
- 코틀린은 기존 자바 라이브러리를 최대한 활용하는 데에 집중
  - 자체 컬렉션 라이브러리를 제공하지 않으며 자바 표준 라이브러리 클래스에 의존함

코틀린 도구 사용

코틀린 역시 자바와 마찬가지로 컴파일 언어, 앞으로 컴파일 과정과 어떤 도구가 사용되는지 이야기 할것

코틀린 코드 컴파일
- 코틀린 소스코드 저장에는 보통 .kt라는 확장자를 파일에 붙임
- 컴파일한 코드는 코틀린 런타임 라이브러리에 의존함

[Java] JVM을 파헤쳐보자: 1. 메모리 구조와 멀티스레드

예민한고라니 — Tue, 10 Jan 2023 18:05:53 +0900

JVM이란?

자바를 공부하는 사람이라면 JVM에 대한 이야기를 많이 들어보았을 것이다. JVM이란 Java Virtual Machine의 약자로, 자바로 작성된 프로그램을 실행시켜주기 위한 가상 머신(가상의 컴퓨터, 컴퓨터안의 컴퓨터)이다.

JVM은 Java를 플랫폼 독립적인 언어로 만들어준다는 특징과, 메모리를 관리하고 최적화 해주는 기능이 존재한다는 특징이 존재한다.

여기서 플랫폼 독립적이라는건, 어떤 운영체제 상에서 작성된 프로그램이든 모두 문제없이 돌아간다는 것인데, 이를 가능토록 중개해주는 것이 바로 JVM의 역할이다. 또한 Java이전에는 프로그램 메모리를 모두 SW개발자가 관리했다면, JVM은 가비지 컬렉터를 통해 자동으로 메모리 관리를 해준다! 따라서 개발자는 운영체제에 맞는 JVM만 깔아주게 되면, 어느 OS위에서 작성한 프로그램이든 문제없이 구동할 수 있으며, 메모리 관리도 해주는것.

하지만 모든건 제대로 알고 써야한다. 따라서, 앞으로 몇개의 게시글을 거쳐 JVM에대해 끝까지 파헤쳐보도록하자.

JVM의 메모리 구조

JVM의 메모리 구조는 다음과 같은 것들로 구성되어 있다.

1. Class Loader

클래스 파일들을 엮어 JVM내부의 메모리 영역인 Runtime Data Area로 적재하는 역할을 수행한다. 자바 애플리케이션이 실행 중 일때 이런 작업이 수행된다

2. Excution Engine

메모리에 적재된 클래스들을 기계어로 변경해, 명령어의 단위로 실행시켜주는 역할을 한다. 이때 JVM내부에서는 인터프리터 방식과, JIT 컴파일러 방식 두가지 모두 사용한다. 또한 GC가 이 영역에 포함되어 있다.

3. Garbage Collector(GC)

메모리 영역중 Heap영역에 존재하는 객체들중에 참조되지 않아 unreachable한 상태에 빠진 객체들을 탐색 후 제거하는 역할을 수행한다. Execution Engine에 속해있는 기능이다.

4. Runtime Data Area

JVM의 메모리 영역으로 총 5가지로 나뉜다

Method Area
클래스의 필드 정보와 메소드 정보, static변수(전역 변수)등 Class에 대한 바이트코드가 저장이되는 영역이다. JVM이 어떤 메소드를 호출하기 위해서는 해당 메소드들에 대한 클래스 파일의 바이트코드가 반드시 Method Area에 적재되어 있어야 한다!
Heap
new 키워드로 생성된 객체와 배열 등이 저장되는 구역이다. GC의 대상이 되는 구역이 되어 주기적으로 사용하지 않는 메모리 해제가 일어난다.
Stack Area
지역 변수, 파라미터 등 어떤 메소드를 실행 시켰을때 사용되는 임시 값들이 생성되는 영역으로 해당 함수 호출이 종료될때마다 stack에서 제거된다.
스택 영역에 차례대로 저장되는 함수의 호출을 stack frame이라 부른다 (아래 사진 참조)

PC Register
JVM은 멀티스레드의 환경이기에 스레드간 전환이 일어날때 각 스레드의 상태를 저장해줄 필요가 있다.
PC register가 바로 하나의 스레드가 실행되고 있는 부분, 주소와 명령 등을 저장하는 영역이다.
Native Method stack
c++/c 등의 언어로 작성된 코드가 저장되는 영역이다.

JVM의 멀티스레드

자바 애플리케이션은 프로그램을 의미하는데, 이런 자바 애플리케이션을 컴파일하여 실행시키면 하나의 JVM 프로세스가 실행이된다.

즉, 하나의 JVM은 프로세스 단위라고 할 수 있으며, 내부에는 여러개의 스레드들이 실행될 수 있음을 의미한다.

프로세스와 스레드가 궁금하다면 이 게시글을 클릭해서 읽어보자

그렇다면 JVM 프로세스가 멀티스레드 환경일때 각 스레드들은 어떤 영역을 공유할까?

각 스레드는 Method와 Heap영역을 공유하고 독자적인 Stack, PC 레지스터, native method 영역을 가진다.아래의 사진을 참고해보면 이해하기가 쉽다.

사진출처 : https://coderstea.in/post/java/get-ready-to-deep-dive-java-memory-management-structure-of-jvm/

[스프링/Spring] @SpringBootApplication 어노테이션을 완벽하게 파헤쳐보자

예민한고라니 — Mon, 9 Jan 2023 15:36:18 +0900

0. 목차
1. 서론
2. 본론
@SpringBootConfiguration
@ComponentScan
@EnableAutoConfiguration
3. 정리

서론

스프링부트 프로젝트를 생성을 하게되면, 기본 application클래스가 생성이된다. 해당 클래스를 잘 살펴보면 @SpringBootApllication 어노테이션이 달려있음을 확인 할 수 있다!

아무생각 없이 당연히 달려있으니까 쓰던 어노테이션이지만, “SpringBootApplication 어노테이션을 사용하면 마법과 같은 일들이 발생한다”고 표현을 할만큼 중요한 역할을 수행한다.

본 게시글에서는 @SpringBootApplication 어노테이션에 대해 파고들어 보겠다

본론

우선 파고들어가보면, 스프링부트어플리케이션 어노테이션의 내부는 다음과 같이 생겼다.

/**
 * Indicates a {@link Configuration configuration} class that declares one or more
 * {@link Bean @Bean} methods and also triggers {@link EnableAutoConfiguration
 * auto-configuration} and {@link ComponentScan component scanning}. This is a convenience
 * annotation that is equivalent to declaring {@code @Configuration},
 * {@code @EnableAutoConfiguration} and {@code @ComponentScan}.
 *
 * @author Phillip Webb
 * @author Stephane Nicoll
 * @author Andy Wilkinson
 * @since 1.2.0
 */
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
        @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
...
..

중요한 어노테이션 3가지는 후술하도록하고, 앞의 어노테이션 4개에 대해 간단하게 이야기 해보자.

@Target 는 해당 어노테이션이 사용가능한 범위에 대해 설정해주고

@Retention 어노테이션은 실제 어노테이션이 적용되고 유지되는 범위를 설정해준다.

@Documeted는 소스코드의 코드문서 생성에 도움을 주는 javadoc 이라는 것에 어노테이션 정보를 표현하라는 의미이고

@Inherited는 자식클래스의 어노테이션 상속 여부를 의미한다.

이제 핵심 어노테이션 3가지에 대해 이야기 해보자

@SpringBootConfiguration

Spring에서는 스프링 컨테이너(spring container)라는것을 통해 객체를 관리하는데, 이때 관리되는 객체를 빈(Bean)이라고 표현한다.

@SpringBootConfiguration 어노테이션은 @Bean 정의 메소드를 빈으로 등록하고 사용하는데에 도움을 주는 어노테이션이다.

@SpringBootConfiguration
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Bean
    public PersonService personService() {
        return new PersonServiceImpl();
    }
}

즉, @SpringBootConfiguration 어노테이션이 붙어있는 클래스를 스프링부트에 대한 설정정보가 담긴 클래스로 인식하고, 해당클래스 내부에 @Bean 어노테이션이 담긴 메소드를 찾아 빈을 등록하고 생성해주며 싱글톤 패턴을 유지할 수 있도록 돕는 역할을 한다.

@Bean 어노테이션 만으로는 등록이 불가능할까?

사실 @Bean 어노테이션만으로도 빈 등록은 가능하다. 하지만 Configuration 어노테이션이 존재하지 않는다면 싱글톤을 보장받을 수 없다. 싱글톤 패턴의 보장은 spring에서 중요한 개념이므로 이는 다른 게시글에서 후술하겠다!

사실 설명만 보게된다면, @Configuration 어노테이션과 동일한 역할을 하는것을 알 수 있는데, @SpringBootConfiguration을 사용하는 이유는 무엇일까에 대해 궁금해졌다.

결론적으로 이야기 해보자면, @SpringBootConfiguration은 @Configuration의 특수화된 버전이라고 한다.

@Configuration과 달리 하나의 어플리케이션은 하나의 @SpringBootConfiguration만을 가질 수 있으며, @SpringBootTest에서 추가적인 이점이 존재한다고 한다.

이와 관련된 자세한 이야기는 링크 에서 확인해볼 수 있으며, 추후에 다른 게시글로 정리해보겠다!

@ComponentScan

@ComponentScan 어노테이션은 @Component 어노테이션이 달린 class들은 자동으로 스캔하여 application context에 빈으로 등록해주는 역할을 한다.

@Service나 @Repository 또는 @Controller 어노테이션이 달린 클래스는 어떻게 빈으로 등록될까?

정답은 바로 해당 어노테이션들 내부에 @Component 어노테이션이 존재하기 때문이다.
이런 어노텐이션들을 `stereotype` 어노테이션이라고 부른다

@EnableAutoConfiguration

@EnableAutoConfiguration 어노테이션은 스프링 부트의 마법같은 기능인 auto-configuration을 가능하도록 하는 어노테이션이다.

그렇다면 auto-configuration이란 뭘까?

spring 기반 애플리케이션에는 수많은 configuration이 필요하다. 예를들어 보자면

spring mvc를 사용할때 컴포넌트 스캔, dispatcher servlet, web jar등을 구성한다던가
Hibernate/JPA 사용을 위해 data source, entity manager, transaction manager를 구성한다던가
등등 …

기존의 Spring 에서는 이를 직접 XML파일을 작성하여 configuration을 해주었어야했다.

말로는 쉬워보이지만, 이 작업은 미친듯이 복잡하고 귀찮은 작업이라고 한다.

(궁금하다면 spring mvc configuration xml을 검색(클릭) 하여 찾아보자…)

하지만 Spring Boot 에서는 CLASSPATH에 spring MVC나 Hibernate등에 대한 Jar파일이 존재하면,

자동으로 configuration 해주는 어마무시한 기능을 제공하고, 그 기능을 가능토록 하는게 바로 이 어노테이션 인것이다.

이런 스프링 부트의 기능을 가지고 사람들은 마법같다고 표현한다.

정리

@SpringBootApplication 어노테이션은 총 3가지의 중추적인 역할을 하는 어노테이션으로 구성되어있다.

@SpringBootConfiguration

스프링빈을 생성하는 configuration 파일임을 명시하는 역할
싱글톤으로 스프링빈이 등록되도록 도와준다.

@ComponentScan

Component 어노테이션이 달린 class 들을 자동 스캔하여, application context에 스프링빈으로 등록되도록 도와준다

@EnableAutoConfiguration

Classpath에 존재하는 Jar파일을 자동으로 configuration 해준다.
즉, spring 설정을 위해 수동으로 했어야 했던 수많은 configuration을 자동으로 해주는 것 (auto-configuration)

참고자료

https://www.baeldung.com/springbootconfiguration-annotation

https://www.baeldung.com/spring-componentscan-vs-enableautoconfiguration

https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/SpringBootConfiguration.html

https://stackoverflow.com/questions/69851544/what-does-it-mean-by-springbootconfiguration-allows-the-configuration-to-be-fou

[데이터 중심 애플리케이션 설계] 2장 : 데이터 모델과 질의 언어

예민한고라니 — Tue, 3 Jan 2023 22:27:17 +0900

해당 게시글은 [데이터 중심 애플리케이션] 책을 읽고 스터디하며 정리한 글입니다.

데이터 중심 애플리케이션 설계 - YES24

데이터는 오늘날 시스템을 설계할 때 마주치는 많은 도전 과제 중에서도 가장 중심에 있다. 확장성, 일관성, 신뢰성, 효율성, 유지보수성과 같은 해결하기 어려운 문제를 파악해야 할 뿐 아니라

www.yes24.com

서론

소프트웨어 개발에서 가장 중요한 부분인 데이터 모델에 대해 이야기한 챕터. 데이터 모델은 문제를 어떻게 생각해야하는지에 대해서도 큰 영향을 미치기 때문에 매우 중요하다고 기술하고 있다.

각 애플리케이션은 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 두어 만드는데, 이때 각 계층의 핵심 문제는 다음 하위 계층 관점에서의 데이터 모델을 표현하는 방법이다.

따라서 명확한 데이터 모델을 제공하면 하위 계층의 복잡성을 숨길 수 있어 다른 그룹의 사람들이 효율적으로 일할 수 있도록 함. (ex. API)

해당 장에서는 데이터 저장과 질의를 위한 다양한 범용 데이터 모델을 살펴 볼 것임

1. 관계형 모델과 문서 모델

관계형 모델을 기반으로 한 SQL이 오늘 날 가장 잘 알려짐. RDB에서 데이터는 관계(relation)로 구성되고, 각 관계(relation)은 순서 없는 튜플(tuple) 모음이다.

RDBMS와 SQL는 정규화된 구조로 데이터를 저장하고 질의를 수행할 필요가 있는 사람들이 대부분 선택하는 도구가 되었는데, 트랜잭션 처리나 일괄 처리 같은 비지니스 데이터 처리에 근원을 두고 있다.

NoSQL의 탄생

NoSQL 데이터베이스를 채택하는 데에는 여러가지 이유가 있다

대규모 데이터셋 or 매우 높은 쓰기 처리량 달성을 RDB보다 쉽게 할 수 있을만큼의 뛰어난 확장성
무료 오픈소스 선호도 확산
관계형 모델에서는 지원하지 않는 특수 질의
동적이고 풍부한 데이터 모델에 대한 바람

애플리케이션은 저마다 요구사항이 달라 하나의 선택이 전체의 최적은 아니게 된다. 따라서 가까운 미래에는 RDBMS가 다양한 데이터 스토어와 함께 사용될 것! 이런 개념을 다중 저장소 지속성(polyglot persistence) 이라고 한다

객체 관계형 불일치

오늘날의 객체 지향 프로그래밍으로 개발 된 객체들과 데이터 베이스 모델 사이에 거추장 스러운 전환계층이 필요하다. 이런 모델의 분리를 임피던드 불일치(impedance mismatch)라고 부른다

하이버네이트나 액티브레코드 같은 객체 관계형 맵핑(ORM) 프레임워크는 전환 계층에 필요한 코드의 양을 줄이지만 두 모델간 차이를 완벽히 숨길 수 없다

예를들어, 관계형 스키마에서 이력서를 표현할 경우를 생각해보자. 대부분의 사람은 학력 기간과 연락처 정보등 하나이상의 데이터를 담아야한다. 사용자와 이들 항목은 일대다(one-to-many)관계이며 이는 아래와 같은 다양한 방법으로 나타 낼 수 있다.

전통적인 SQL모델에서는 각 학력과 연락처등 정보를 개별 테이블에 넣고 외래키로 참조한다
이후 SQL마지막 버전에서는 구조화된 데이터 타입과 XML데이터에 대한 지원도 되었다.
마지막으로는, 직업 학력 연락처 정보를 JSON등으로 부호화해 텍스트 칼럼에 저장하여 애플리케이션이 해석하도록 하는 방식이다. -> but, 부호화된 칼럼의 값을 질의하는 DB는 사용할 수 없다.

위의 예인 이력서 같은 구조는 모든 내용을 갖추고 있는 문서라 JSON 표현에 매우 적합하다. 몽고DB, 리싱크DB, 카우치DB, 에스프레소 같은 문서 지향 DB는 JSON데이터 모델을 지원한다. 일부 개발자들은 JSON 모델이 임피던스 불일치를 줄인다고 생각하는데, 사실 JSON 자체가 가진 문제도 있다(이후 4장에서 설명). JSON식의 표현은 다중 테이블 스키마 보다 더 나은 지역성(locality)를 갖는다. 복잡한 조인이 필요없다!

사실 이력서 상의 데이터들은 TREE구조와 같은데, 이는 JSON 표현에서 명시적으로 드러나게 된다.

다대일과 다대다 관계

앞선 예제에서 지역과 업계는 직접 입력받는 것이 아닌 region_id 와 industry_id를 사용했는데, 이렇게 표준 목록으로 드롭다운 리스트 형식으로 만든데에는 여러 장점이있다.

일관된 스타일의 철자 & 모호함 회피
갱신의 편의성
더 나은 검색

ID를 사용하느냐 또는 입력받은 텍스트를 저장햐느냐는 중복의 문제라고 할 수 있다. 중복된 데이터를 정규화 하려면 다대일 관계가 필요하지만, 문서 모델에서 다대일 관계는 적합하지 않다. 따라서 데이터 베이스에 대한 다중 질의를 만들어서 애프리케이션 코드에서 조인을 흉내내야 하기에 어렵다.

문서 데이터베이스는 역사를 반복하고 있나??

RDBMS는 일상적으로 다대다 관계와 조인을 사용하지만, 문서형 DB와 NOSQL은 DB에서 다대다 관계 표현의 가장 좋은 방법에 대한 논쟁을 펼치고 있다.

1970년대 비지니스 데이터 처리를 위해 IBM의 정보 관리 시스템을 데이터베이스로 가장 많이 사용했는데, 이는 계층 모델이라 부르는 상당히 간단한 모델을 사용했다. 계층 모델은 오늘날 사용하는 JSON 모델과 놀랍도록 비슷하며, 모든 데이터를 레코드 내에 중첩된 레코드 트리로 표현한다.

하지만 계층 모델 역시 다대다 관계 표현이 어려워 오늘날과 똑같은 고민했고, 이런 계층 모델의 한계를 해결하기 위해 관계형 모델과 네트워크 모델이 나타나게 되었다.

네트워크 모델

코다실 모델이라고 부르기도한다. 계층 모델을 일반화한 모델로, 계층 모델의 트리 구조에서는 모든 레코드는 정확하게 하나의 부모가 존재하는데, 네트워크 모델에서는 다중 부모가 존재가능하다. 레코드에 접근하는 유일한 방법은 최상위 레코드에서부터 연속된 연결 경로를 따르는 방법으로, 이를 접근 경로 라고 하며, 외래키 보다는 포인터와 더 비슷하다.

만약 레코드가 다중 부모를 가진다면 애플리케이션 코드는 다양한 관계를 모두 추적해야하며, 이런 수동 접근 경로 선택은 데이터베이스 질의와 갱신을 위한 코드가 복잡하고 유연하지 못하다. 접근 경로를 수정할 수 있지만 많은 수작업 질의코드를 살펴봐야하고 재작성 하는 등 매우 어려운 일이다.

관계형 모델

대조적으로 관계형 모델이 하는 일은 알려준 모든 데이터를 배치하는 것으로, 단순히 튜플의 컬렉션이 전부이다. 다른 테이블과의 관계를 신경쓰지 않고 새 로우를 삽입할 수 도 있다. 이런 RDB에서 query optimizer는 질의의 어느 부분을 어떤 순서로 실행할지 결정하고 사용할 색인을 자동 결정한다. 이 선택이 바로 실제 “접근 경로”인 것. 하지만 개발자가 아니라 query optimizer기가 자동으로 만드므로 개발자가 고려할 필요가 없다.

문서 데이터베이스와의 비교

문서 데이터베이스는 상위 레코드 내에 중첩된 레코드를 저장한다는 측면에서 계층 모델로 되돌아갔다. 하지만 다대일과 다대다를 표현할때 RDB와 근본적으로 다르지 않았으며, 관계형 모델에서 외래키가 문서 모델에서의 문서 참조(document reference)와 같다.

관계형 데이터베이스와 오늘날의 문서 데이터베이스

관계형 선호 : 조인, 다대다, 다대일 관계 지원
문서 데이터 모델 선호 : 스키마 유연성, 지역성

어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까?

애플리케이션 데이터가 문서와 비슷한 구조라면 문서 모델을 사용하는 것이 좋다. 관계형 모델은 문서와 비슷한 구조를 여러 테이블로 나누어 찢기(shredding) 때문에 복잡한 애플리케이션 코드를 발생시킨다.

But, 문서 모델은 중첩항목을 바로 참조할 수 없고, 미흡한 조인 지원은 때떄로 문제가 된다(때로는 아닐 수 있음). 다대다 관계를 사용하면 문서 모델의 매력은 떨어지는것이 대표적인 문제다.

결론 : 일반적으로 어떤 데이터 모델이 코드를 더 간단하게 만드는지 말할수 없음. (데이터 유형에 따라 다름!)

발표하신 스터디원 분께서 몽고DB같은게 로그 검색에 유의미한 이유를 알게 된것 같았다, 라고 했는데. 듣고보니 오 .. 그렇구나 싶었다. 생각해보면 로그 데이터는 애초에 조인이 필요하지 않는 그저 쌓이는 문서지만 필요할때 찾아보면 좋을 데이터이기 때문이다!

문서모델에서의 스키마 유연성

문서 데이터베이스는 종종 스키마리스(schemaless)로 불리지만, 이는 오해의 소지가 있는 표현이며, 데이터를 읽는 코드는 보통 구조의 유형을 어느정도 가정한다. 즉 쓰기 스키마말고 읽기 스키마 인것이다.

쓰기 스키마와 읽기 스키마

쓰기 스키마(schema-on-write) : RDB의 전통적인 접근 방식으로 스키마는 명시적으로 DB는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장한다

정적 타임 확인과 유사하다

읽기 스키마(schema-on-read) : 데이터 주고는 암묵적으로 읽을때만 해석이 된다.

프로그래밍 언어에서 동작 타입 확인과 유사하다

예를들어 현재의 이름을 성과 이름 필드로 분리할 경우, “동적 타입”에서는 예전 문서를 읽은 경우를 처리하는 코드만 있으면 되는데, “정적 타입”의 경우 마이그레이션 작업이 필요하다

스키마 변경에 대한 평판은 매우 나쁘지만, 사실 대부분의 RDBMS에서 ALTER TABLE 문은 수 밀리초 안에 수행한다. 하지만 MYSQL의 경우 전체 테이블을 복사하여 수분에서 수초까지 중단 시간이 발생한다.

UPDATE 문을 실행하면 모든 로우가 재작성 될 수 있기에 오래걸릴 수 있다.

읽기 스키마 접근 방식은 컬렉션 안의 항목이 모두 동일한 구조가 아닐때 유리하다. 왜냐면

각 유형의 오브젝트 별로 자체 테이블에 넣는 방법은 실용적이지 않다.
언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정되기 때문

스키마는 득보다 싫이 많지만, 모든 레코드가 동일한 구조라 예상 가능하다면 스키마는 문서화와 구조를 강제하기 위한 아주 좋은 메커니즘이다.

질의를 위한 데이터 지역성

문서는 보통 JSON이나 부호화된 단일 연속 문자열(몽고DB 같은)로 저장된다. 애플리케이션이 자주 전체 문서에 접근해야할 때 저장소 지역성(storage locality)를 활용하면 성능상의 이점이 있다.

지역성의 이점은 해당 문서의 많은 부분을 필요로 하는 경우에 적용된다. 따라서 일반적으로 문서를 아주 작게 유지하면서 문서의 크기가 증가하는 쓰기를 피하라고 권장한다.

지역성은 문서모델에만 국한되지 않는데, 오라클은 다중 테이블 색인 클러스터 테이블(multi-table index cluster table)기능을 사용해 지역적 특성을 제공한다

문서 데이터베이스와 관계형 데이터베이스의 통합

RDB랑 문서DB는 시간이 지남에 따라 점점 더 비슷해지고 있으며, 서로 부족한 부분은 보완해 나가고 있다. 이 두 DB의 혼합 모델은 미래 데이터베이스들이 가야할 올바른 길이라고 이야기한다.

2. 데이터를 위한 질의 언어

관계형 모델이 등장했을 때 데이터를 질의하는 새로운 방법로 함께 나타났음. SQL이나 관계 대수 같은 선언형 질의 언어에서는 목표를 달성하기 위한 방법이 아니라 결과가 충족해야하는 조건과 데이터를 어떻게 변환 할지 지정하기만 하면된다. 나머지는 쿼리 최적화기가 할 일.

선언형 질의 언어는 데이터베이스 엔진의 상세 구현이 숨겨져 있어 질의를 변경하지 않고도 성능을 향상 시킬 수 있음.또한 종종 병렬 실행에 적합하다. 결과를 결정하기 위한 알고리즘이 아니라 패턴만 지정하기 때문에 병렬 실행하여 더 빨라질 가능성이 크다.

웹에서의 선언형 질의

선언형 질의 언어의 장점은 DB에만 국한되지 않는다. 예를들어 CSS를 사용하여 선택자에 특정 디자인(패턴)을 일괄 적용할 수 있으며 이는 선언형 방식이다.

명령형 접근 방식의 경우 JS에서 DOM API를 사용하여 구현할 수 있다. 이경우 이해하기 어려울 뿐만 아니라 몇가지 문제사항이 있다.

새로운 API의 장점을 취하고 싶으면 코드를 재작성 해야한다. (CSS의 경우 호환성을 깨뜨리지 않음)
특정 작업이 수행되면 전체 페이지가 로딩될때까지 유지된다. (반면에 CSS는 자동으로 감지해서 삭제되자마자 같이 삭제한다)

웹에서도 DOM API보다 CSS를 더 추천하는 것처럼, DB에서도 선언형 질의언어가 더욱 추천된다.

맵리듀스 질의

맵리듀스(MapReduce)는 많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델로 구글에 의해 널리 알려졌다. 몽고DB를 포함한 일부 NOSQL 데이터 저장소는 제한된 형태인 맵리듀스를 지원한다. 이 매커니즘은 많은 문서를 대상으로 읽기 전용(read-only)질의를 수행할 때 사용된다.

현 챕터에서는 몽고DB의 모델 사용에 대해 간단히 살펴 볼것이다.

맵리듀스는 선언형 질의도 완전한 명령형 질의API도 아닌 그 중간이다. 맵리듀스는 여러 함수형 프로그래밍 언어에 있는 map과 reduce 함수를 기반으로 한다.

예시로, 상어과에 속하는 1)종만 보이도록 관측치를 필터링 한 다음, 2)관측치가 발생한 달력의 월로 그룹화 하고, 3)해당 달의 모든 관측치에 보여진 동물 수 합치는 경우를 생각해보자

상어 종만 거르기 위한 필터를 지정하고

map함수가 연도와 월로 구성된 값을 방출하는데,

방출한 키-값 쌍은 키로 그룹화 되어, 같은 키(연도-월)을 갖는 모든 키-값 쌍은 reduce 함수를 한번 호출한다.

reduce는 특정 월의 모든 관측치에서 동물수를 합치고 최종출력이된다.

맵리듀스의 사용성 문제는 연계된 자바스크립트 함수 두개를 신중하게 작성해야 한다는 점인데 이는 어렵다. 또한 선언형 질의 언어는 질의 최적화기가 질의 성능을 높일 수 있는 기회를 제공하는데, 이런 이유로 몽고DB는 집계 파이프라인(aggregation pipeline)이라 부르는 선언형 질의 언어 지원을 추가했다! 이는 SQL의 부분집합과 유사하지만 JSON기반 구문을 사용한다

3. 그래프형 데이터 모델

앞서 다대다 관계가 다양한 데이터 모델을 구별하는 중요한 기능임을 이야기 했는데, 애플리케이션이 주로 일대다 관계(트리 구조)이거나 레코드 간 관계가 없다면 문서 모델이 적합하다.

다대다 관계가 일반적일 경우, 또 데이터 간 연결이 더 복잡해지면 그래프로 데이터를 모델링 하기 시작하는 편이 더 자연스럽다

그래프는 정점(vertax)과 간선(edge)로 이루어지는데, 동종 데이터에 국한 되지 않는다

ex) 페이스북의 정점은 사람, 장소, 체크인, 코멘트 등 여러가지가 될 수 있음

그래프에서 데이터를 구조화하고 질의하는 몇가지 방법과 언어를 설명할 것

속성 그래프

속성 그래프 모델의 정점의 구성요소

고유한 식별자 / 유출 간선 집합 / 유입 간선 집합 / 속성 컬렉션(키-값 쌍)

속석 그래프 모델의 간선의 구성요소

고유한 식별자 / 간선이 시작하는 정점 / 간선이 끝나는 정점 / 두 정점 간의 관계 유형을 설명하는 레이블 / 속성 컬렉션(키-쌍 값)

이 모델의 몇가지 중요한 면은 다음과 같다

정점은 다른 정점과 간선으로 연결된다. 특정 유형과 관련 여부를 제한하는 스키마는 없다
정점이 주어지면, 정점의 유입과 유출 간선을 효율적으로 찾을 수 있으며, 그래프 순회가 가능하다.
다른 유형의 관계에 서로 다른 레이블을 사용하면, 단일 그래프에 다른 유형의 정보를 저장하면서도 모델을 깔끔히 유지할 수 있다

이런 기능들을 통해 그래프는 데이터 모델링을 위한 많은 유연성을 제공한다. 그래프는 발전성이 좋아 애플리케이션에 기능을 추가하는 경우 애플리케이션 데이터 구조 변경을 수용하게끔 그래프를 쉽게 확장할 수 있다.

사이퍼 질의 언어

사이퍼(Cypher)는 속성 그래프를 위한 선언형 질의 언어로 네오포제이 그래프 디비용으로 만들어 졌다.

똑같은 질의를 실행하는데에도 여러가지 방법이 있는데, 보통 선언형 질의 언어는 질의를 작성할때 수행에 대해 자세히 지정할 필요가 없다! 질의 최적화기가 가장 효율적이라고 예측한 전략을 자동으로 선택하기 때문이다.

SQL의 그래프 질의 언어

그래프를 관계형 구조로 넣어도 SQL을 사용하여 질의할 수 있을까? 대답은 예지만 어렵다.

그 이유는 그래프 질의에서는 찾고자 하는 정점을 찾기 전 가변적인 간선을 순회해야 하여 미리 조인 수를 고정할 수 없기 때문이다. 반면에 사이퍼에서는 매우 간결히 표시 가능하다.

SQL:1999 이후로 가변 순회 경로에 대한 질의 개념은 재귀 공통 테이블 식(recursive common table expression)을 사용해서 표현 가능하지만, 문법이 사이퍼에 비해 어렵다.

트리플 저장소와 스파클

트리플 저장소 모델은 속성 그래프 모델과 거의 동등한데, 트리플 저장소에서는 모든 정보를 주어, 서술어, 목적어 처럼 매우 간단한 세부분의 구문 형식으로 저장한다.

시맨틱 웹

트리플 저장소 데이터 모델은 시맨틱 웹과 완전 독립적이지만, 많은 사람들이 이 둘은 밀접한 관계가 있다고 생각한다. 시맨틱 웹은 웹 사이트는 사람이 이미 읽을 수 있는 정보를 게시하고 있으니, 컴퓨터가 읽게끔 기계가 판독 가능한 데이터로도 정보를 게시하자는 생각이다. 하지만 현실에 실현된 흔적이 없으며, 부정적 견해를 보이는 사람이 많다

RDF 데이터 모델

RDF는 인터넷 전체의 데이터 교환을 위해 설계한 데이터인데, 때로는 데이터모델로 RDF를 채택하기도 한다.

스파클 질의 언어

스파클(SPARQL)은 RDF 데이터 모델을 사용한 트리플 저장소 질의 언어로, 사이퍼보다 스파클을 사용하면 때로 질의문이 더 간결해진다.

그래프 데이터베이스와 네트워크 모델의 비교
1. 코다실 DB에는 다른 레코드 타입과 중첩 가능한 레코드 타입을 지정하는 스키마가 있다. -> 근데 그래프에는 제한이 없음, 즉, 유연성이 더 크다 (그래프가)
2. 코다실에서는 레코드 접근 경로중 하나를 탐색해야만 특정 레코드에 도달할 수 있음. -> 그래프는 고유 ID를 가져 직접 참조 가능하다
3. 코다실에서 레코드 하위 항목은 정렬된 집합 -> 그래프는 정점과 간선을 정렬하지 않는다
4. 코다실은 명령혈 질의 언어 사용 -> 대부분 그래프에서는 고수준 선언형 질의를 사용한다

초석: 데이터로그

데이터로그는 스파클이나 사이퍼보다 훨씬 오래된 언어로 이후의 질의 언어의 기반이 되는 초석을 제공하기에 중요하다. 데이터로그의 데이터 모델은 트리플 저장소 모델과 유사하지만, 조금 더 일반화 됐다. (주어, 서술어, 목적어)로 트리플을 작성하는 대신 서술어(주어, 목적어)로 작성한다.

정리

해당 장에서는 다양한 종류의 모델을 간략하게 살펴봤다.

역사적으로 데이터를 하나의 큰 트리로 표현하고자 했지만, 다대다 관계를 표한기에 트리 구조는 적절하지 않았고 이 문제를 해결하기 위해 관계형 모델이 고안됐다. 하지만 최근들어 관계형 모델에도 적합하지 않는 유형을 발견했고, “NoSQL”이 새로운 등장했으며 아래 두가지 갈래로 나뉜다.

문서 데이터베이스
그래프 데이터베이스

세가지 모델 모두 현재 널리 사용하고 있으며 각기 목적에 맞는 다양한 시스템에 사용하고 있다.

문서 및 그래프 데이터베이스가 가진 공통점 중 하나는 저장할 데이터를 위한 스키마를 강제하지 않는다. 하지만 대게의 애플리케이션은 데이터가 특정 구조를 갖는다고 가정할 가능성이 높다.

각 데이터 모델은 고유한 질의 언어랑 프레임워크를 제공한다.

[데이터 중심 애플리케이션 설계] 1장 : 신뢰할 수 있고 확장가능하며 유지보수하기 쉬운 애플리케이션

예민한고라니 — Wed, 28 Dec 2022 18:13:19 +0900

오늘날의 많은 어플리케이션은 계산 중심이 아닌 데이터 중심적임
일반적으로 데이터 중심 애플리케이션은 공통으로 필요한 기능을 제공하는 표준 구성 요소(standard building block)로 만듬
- 애플리케이션에서 다시 데이터를 찾을 수 있게 저장 (DB)
- 읽기 속도 향상을 위해 수행 결과 기억 (캐시)
- 다양한 방법으로 필터링 할 수 있게 제공 (search index)
- 다른 프로세스로 메세지 보내기 (steam processing)
- 주기적으로 대량의 데이터를 분석 (batch processing)
위의 과정이 당연한 이야기 처럼 들린다는것 = 데이터 시스템이 성공적으로 추상화 되었다는 것

데이터 시스템에 대한 생각

데이터 시스템이라는 포괄적인 용어로 묶는 이유에는
1. 데이터 시스템 분류간 경계가 흐려지고 있음 (ex.메세지 큐의 레디스, db처럼 지속성 보장 메세지 큐인 카프카 등..)
2. 더 많은 애플리케이션이 단일 도구로는 데이터 처리와 저장 모두 만족시킬 수 없음
이 책에서는 대부분의 SW 시스템에서 중요하게 여기는 3가지 관심사에 중점을 둠
1. 신뢰성
2. 확장성
3. 유지보수성

신뢰성

무언가 잘못되더라도 지속적으로 올바르게 동작함이라 이해할 수 있음
잘못될 수 있는 일 = 결함
결함을 예측하고 대처할 수 있는 시스템을 내결함성 or 탄력성을 지녔다 함
결함 ≠ 장애(시스템 전체가 멈춘 경우를 의미)
고의적으로 결함을 유도함으로써 내 결함성 시스템을 훈련할 수 있음
- 이것의 대표적인게 넷플릭스의 카오스 몽키
해결책이 있는 결함 유형 3가지
1. 하드웨어 결함
- 각 하드웨어 구성 요소에 중복을 추가하는 방법이 일반적
- 소프트웨어 내결함성 기술을 사용하거나 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 옮겨가는 추세
1. 소프트웨어 오류
- 이 결함은 예상하기 어렵고, 더욱더 많이 발생하며, 신속한 해결책이 존재하지 않음
- 시스템이 뭔가를 보장하길 기대한다면 이를 지속적으로 확인해 차이가 생기는 경우 경고를 발생시킬 수 있음
1. 인적 오류
- 대규모 인터넷 서비스에 대한 연구에 따르면 인적 오류로 인한 중단이 주요 원인이다
신뢰성은 손실이 발생하며 명성에 타격을 준다는 면에서 큰 비용이 발생한다

확장성

시스템이 현재 안정적으로 동작한다고 해서 미래에도 안정적으로 동작한다는 보장은 없음
성능 저하를 유발시키는 가장 흔한 이유중 하나는 부하 증가
확장성은 증가한 부하에 대처하는 시스템 능력을 설명하는데 사용하는 용어

부하기술하기

현재 부하에 대해 간결하게 기술할 수 있어야지 부하 성장 질문을 논의할 수 있다
부하는 부하 매개변수라 부르는 몇개의 숫자로 나타낼 수 있음

트위터 예시

트위터의 주요 동작 두가지
- 트윗 작성 (초당 12k 요청 이상)
- 홈 타임라인 (초당 300k 요청)
이 때 12k 건의 쓰기 처리를 상당히 쉬우며, 트위터의 확장성 문제는 주로 팬 아웃 문제로 발생함
이를 구현하는 방법은 총 두가지가 있음
1. 트윗 작성은 간단히 새로운 트윗을 트윗 전역 컬렉션에 삽입한다. 사용자가 홈 타임라인을 요청하면 팔로우 하는 모든 사람을 찾고, 이를 시간순으로 정렬하여 합친다
2. 개별 사용자의 홈 타인라인 캐시를 유지하여, 트윗을 작성하면 해당 사용자를 팔로우하는 모든 사람을 찾고, 팔로워 각자의 홈 타임라인 캐시에 새로운 트윗을 삽입한다.
트위터는 1번 의 방식에서 2번의 방식으로 전환함
평균적으로 트윗 게시 요청량이 홈 타임라인 읽기 요청량에 비해 수백배 적기 떄문에 접근 방식 2가 훨씬 잘 동작함
하지만 트윗 작성에 많은 부가작업을 필요로 하여, 팔로워의 분포가 팬 아웃 부하를 결정하는 문제가 발생함
따라서 트위터는 두 접근 방식의 혼합형으로 바꾸어, 대부분 사용자의 트윗은 2의 방식을 채택하지만, 팔로워수가 매우 많은 소수 사용자는 팬아웃에서 제외되고 1처럼 읽는 시점에 사용자의 홈 타임라인에 합쳐짐

성능기술하기

시스템 부하를 기술하면 다부하가 증가할 때 어떤 일이 일어나는지 조사할 수 있는데, 다음 두가지 방법으로 살펴볼 수 있음
- 부하 매개변수를 증가시키고 시스템 자원은 유지하면 시스템 성능은 어떻게 영향 받을지?
- 부하 매개변수를 증가시켰을때 성능이 변하지 않고 유지되길 원한다면 자원을 얼마나 많이 늘려야할지?
하둡같은 일괄 처리 시스템은 보통 처리량에 관심을 가짐.
온라인 시스템에서 더 중요한 사항은 서비스 응답시간
클라이언트가 동일한 요청을 반복해서 하더라도 응답시간은 매번 다름 → 응답시간은 단일 숫자가 아닌 측정 가능한 값의 분포로 이야기함
보고된 서비스의 평균응답시간 을 살피는 일은 일반적이지만, 백분위 를 사용하는 편이 더 좋음
사용자가 보통 얼마나 오랫동안 기다려야 하는지 알고싶다면 중앙값이 좋은 지표
특이 값이 얼마나 좋지 않은지 알아보려면 상위 백분위를 살펴보는 것도 좋음
- 꼬리 지연 시간으로 알려진 상위 백분위 응답 시간은 서비스의 사용자 경험에 직접 영향을 주기 때문에 중요함

부하 대응 접근 방식

확장성과 관련해서 용량 확장(scaling up)-수직 확장(vertical sacling) / 규모 확장(sacling out) - 수평 확장(horizontal sacling)으로 구분해서 이야기함
다수의 장비에 부하를 분산하는 아키텍처를 비공유 아키텍처라 이야기함
상당히 집약된 작업 부하는 대게 규모확장을 피하지 못함.
일부 시스템은 **탄력적(elastic)**이어서, 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있음
다수의 장비에 상태 비저장(stateless)서비스를 배포하는 일은 간단함
- 하지만 단일 노드에 상태 유지(stateful) 데이터 시스템을 분산 설치하는 일은 많은 복잡도가 추가적으로 발생함
- 이런 이유로 확장 비용이나 데이터베이스를 분산으로 만들어야 하는 고가용성 요구가 있을때까지 단일 노드에 데이터베이스를 유지하는 것(용량 확장)이 최근가지의 통념임
대개 대규모로 동작하는 시스템의 아키텍처는 해당 시스템을 사용하는 애플리케이션에 특화되어있음
범용적이고 모든 상황에 맞는(one-size-fits-all) 확장 아키텍처는 없음

유지 보수성

소프트웨어 비용이 대부분은 초기 개발이 아니라 유지보수에 들어감
레거시 소프트웨어를 만들지 않게 끔 잘 설계해야하는데 이런 설계원칙은 3가지 존재함
- 운용성 : 시스템을 원활하게 운용할 수 있도록 쉽게 만들자
- 단순성 : 복잡도를 최대한 제거하자
- 발전성 : 시스템을 쉽게 변경할 수 있도록 하자

운용성 : 운영의 편리함 만들기

운영 중 일부 측면을 자동화 할 수 있고 또 자동화 해야함
하지만 자동화를 처음 설정하고 제대로 동작하는지 확인하는 일은 여전히 사람의 몫
좋은 운영성이란 동일하게 반복되는 태스크를 쉽게 수행하게 끔 만들어 운영팀이 고부가치 활동에 노력을 집중한다는 의미

단순성 : 복잡도 관리

복잡도 수렁에 빠진 소프트웨어 프로젝트를 때론 커다란 진흙 덩어리(big ball of mud)라고 묘사함
시스템을 단순하게 만든다는것은 = 우발적 복잡도(accidental complexity)를 줄인다는 것
우발적 복잡도를 제거하기 위한 최상의 도구는 추상화이다
책 전반에 걸쳐 좋은 추상화에 대해 이야기 할 것

발전성 : 변화를 쉽게 만들기

시스템의 요구사항은 끊임없이 변할 가능성이 크다.
조직의 프로세스 측면에서 애자일(agile) 작업 패턴은 변화에 적응하기 위한 프레임워크를 제공한다
또한 TDD와 리팩토링 같이 자주 변화하는 환경에서 소프트웨어를 개발할때 도움이 되는 기술 도구와 패턴을 개발하고 있다.

약 8시간 응시한 라인 카카오 코테 후기

예민한고라니 — Mon, 26 Sep 2022 21:34:11 +0900

오전 10시부터 오후 7시까지 코테여서 스터디룸을 빌렸다.. 트랙패드까지 가져감ㅋ

9월 24일 오전 10시 - 오후 12시 30분

2022 하반기 라인 코테, 5문제 2시간 30분

총평

알고리즘이라곤 DFS BFS밖에 모르던 상반기에 응시했을때랑 체감난이도가 비슷했다

상반기보다 어려웠다는 평이 다수인데, 너무 아쉽다.

애초부터 3솔을 목표로 임했는데, 1,2번까지 빠른시간내에 풀고 3번이랑 4번 왔다갔다 간을 보다가 시간을 보내버렸다

특히 3번은 구간합으로 풀면 효율성에도 문제 진짜 풀 수 있었던 문제였다고 생각이 되는데 그래서 좀 아쉽다.

일단은 2솔인데 히든 케이스를 맞췄을지는 모르겠어서, 잘 모르겠다.

원한 결과만큼 얻진 못했지만, 최선을 다했음을 알기때문에 훌훌 털어버렸다

점심은 내가 좋아하는 신촌 초밥 맛집에서 ^^~

9월 24일 오후 2시 - 오후 7시

카카오 코테, 7문제, 5시간

1번 문자열 (그냥 구현)

진짜 바보같게도, 자바에서 제공하는 calendar랑 date 쓰려다가 예외 처리 때문에 좀 이상하게 흘러갔다

그래서 접고 그냥 구현으로 풀었다. 난이도는 브론즈에서 실버 정도로 매우 쉬웠다.

단지.. 내가 삽질하느라 40분이나 썼을뿐

2번 ?

보자마자 그리디나 다이나믹 프로그래밍 같았는데, 못풀겠다 싶어서 바로 넘어감 ^^

3번 중복 순열

대충 몇가지 상황에 대한 중복 순열을 리스트로 만들어놓고 완전탐색 돌리면 해결되는 문제였다.

다만 초반에 문제를 잘못읽어서 '몇가지 상황'을 더 어렵게 꼬아서 풀었다가 알고보니 더 단순했던 ..

제발 문제에 주어진 조건을 잘읽자!

4번 트리

한 2시간은 넘게 삽질한 문제 (결국 못품 ^^)

트리에 나름 자신있었기때문에 주어진 배열을 트리로 만드는 메소드와, 트리를 중위순회 돌면서 가능한지 체크하는 메소드를 만들어 놓았다.

그래서 처음에 금방 만들어 냈는데,, 주어진 테스트 케이스 2개는 다 맞는데, 실제 제출을 하면 0점이 자꾸 나오는 것이였다.

그러다 마지막 쯤에 포화 이진 트리에 대해 다시 생각해보다가

트리의 앞쪽에는 0이 들어가도 되지만, 뒷쪽에는 0이 들어가면 안된다는 것,

그래서 root node가 1이 될때까지는 계속 앞에 0을 넣어도 된다는 생각이 문뜩 들었다.

결국 못풀었지만, 트리는 정말 자신있었기 때문에 너무 아쉬웠던 문제다

5번 빡빡빡구현 + 그리고 그래프 탐색

그저 빡구현하는 문제 ..

최대 50*50 크기의 엑셀이 주어지고, 해당값을 UPDATE, MERGE, UNMERGE 하는 문제였는데,

문제는 머지하게된후 해당 값을 업데이트할때는 모든 연결된 값이 다 바뀌어야하고,

심지어 멀리 떨어져 있는 셀에 대해서도 머지할 수 있는.. 그런 문제였다.

정말 말그대로 빡구현 문제였기때문에 .. 머지한걸 인접리스트로 표현을해서,

머지해놓은 값에 대해 어떤작업을 수행할때면 BFS로 해당하는 값들을 찾아가서 다 바꿔버리도록 했다

구현도 구현인데 진짜 인접리스트 구현할때 ㅋㅋㅋㅋㅋ 힘들었다^^..

중간에 자꾸 몇몇 테케들이 틀려서 이대로 2솔인가 싶었는데,

다행히 마지막에 운좋게 반례찾아내서 통과할 수 있었다.

6번 7번 보지도 못했슈ㅋㅋ

결국 본인은 1번, 3번, 5번 문제만 풀어 3솔을 했다

총평

본인의 경우 프로그래머스에 있는 카카오 기출들 중 레벨 1-3인건 거진 다 풀어봤는데,

그럼에도 불구하고 예년들 보다 어려웠던 것 같다.

우선 달라진 점이 크게 두가지 있었는데,,

첫번째는, 각 문제별 점수가 공개됐다.

1번 2번 3번 4번 5번 6번 7번 에 대해

30 100 100 150 300 300 350 라는 점수가 부여됨을 공개했던것

사실 나는 문제 푸느라 배점이 있는지도 몰랐는데, 지금생각해보니 4번때문에 2시간넘게 쏟아부었던게 너무 아쉽다 ㅠㅠ

두번째는 효율성과 정확성 체크 문제가 없었다

원래 카카오는 효율성과 정확성 둘다 물어보고, 정확성만 맞추면 반점을 주는 문제가 매해 있었다.

그래서 3.5솔 4.5솔 이런 단어들이 있었는데, 올해는 그게 없었다!

이것저것 생각해봤을때 몇솔이라는것 자체는 의미가 없는것 같다.

특히 배점만 보면 .. 7번 6번만 풀어도 붙을거같은 그런 배점이라 놀랐다

라인이나 카카오나 내가 목표한 바(3솔, 4솔) 만큼은 해내지는 못했지만..

그래도 준비하는 1달동안 정말 최선을 다했음을 알기 때문에 끝나자마자 기분이 너무 좋았다

특히 마지막 1주일은 아프기도 엄청 아프고 스트레스 때문에 반좀비상태였는데,

코테라는 압박감에서 당장을 벗어난 것 같아 기분이 정말 째졌다 ^^

최선을 다했으니까 안되면 어쩔 수 없고, 만약 된다면 정말 기분 좋은거고

이번에 코테 준비를하고 실제 코테를 보면서, 조금 가능성은 맛본거같다.

내년에 또 코테를 보게된다면 , 그때는 더 열심히해서 안정적으로 커트라인안에 들어갔음 좋겠다

모두 화이팅 ... 입니다~!

결과는 라인 1차 코테 탈락 , 카카오 1차 코테 합격

덤벙대는 성격이라 그런지 결과가 바로바로 채점되는 코테에 더 강한것 같다.

[운영체제/OS] 데드락(DeadLock, 교착상태)의 개념, 발생 조건, 처리방법

예민한고라니 — Mon, 29 Aug 2022 22:18:56 +0900

데드락의 개념

데드락 이란 ?

두개 이상의 프로세스나 스레드가 서로 자원을 얻지 못해 다음 처리를 하지 못하는 상태
'교착 상태'라고도 부르며, 시스템적으로 한정된 자원을 여러곳에서 사용할때 발생
'외나무 양끝에서 두사람이 서로 비켜주기만 기다리는'것과 같으며 아래의 예시를 참고해보자!

프로세스 1과 2가 리소스1과 2를 모두 얻어야 한다고 가정하자
- 프로세스1이 자원1을 얻은경우 프로세스2는 자원1을 얻을수없고, 프로세스2가 자원2를 가지고 있으므로 프로세스1은 자원2를 얻을 수 없다.
- 두 프로세스는 무한정 wait 상태에 빠지게되며, 이게바로 DeadLock

데드락의 발생 조건

발생 조건	설명
상호배제(Mutual Exclusion) = Mutex	한번에 하나의 프로세스만이 공유자원 사용가능한 상태
점유하며 대기(Hold and Wait)	프로세스들이 현재의 자원을 점유하며 다른 자원을 요구하는 상태
비선점(Non-Preemption)	각 프로세스에 할당된 자원은 사용 완료될때까지 강제로 해제할 수 없는 상태
순환대기(Circular Wait)	서로 다른 프로세스 간의 자원요구가 연속적으로 반복되는 상태

데드락 처리방법

예방(Prevention)

위의 4가지 발생 조건을 제거(막아)하여 미리 예방하는 방법
- 상호배제 부정, 점유대기 부정, 비선점 부정, 순환대기 부정

회피(Avoidance)

데드락 발생조건을 제거하지 않고 적절하게 피하는것
- 은행원 알고리즘
  - 은행에서 모든 고객의 요구가 충족되도록 현금을 할당하는데에서 착안
  - 프로세스의 자원 요구시, 자원할당 후에도 안정상태로 남아 있는지 사전에 검사하여 데드락을 회피
  - 안정상태를 유지하면 자원할당, 아니면 다른 프로세스들이 자원 해지까지 대기

탐지(Detection)

데드락 발생을 허용하여 자원할당 그래프나 탐지 알고리즘 등을 통해 유발 프로세스를 찾아내 해결

회복(Recovery)

교착상태의 프로세스를 종료하거나 할당 자원을 해제함으로서 회복
- 프로세스 종료
  1. 교착상태의 프로세스를 모두 중지
  2. 교착상태가 제거될때까지 한 프로세스씩 중지
- 자원 선점. 즉, 데드락이 깨질때까지 프로세스로부터 자원을 계속 선점, 이들을 다른 프로세스에 주는 것
  1. 교착 상태의 프로세스가 점유하는 자원을 선점하여 다른 프로세스에 할당, 해당 프로세스를 일시 정지
  2. 우선순위가 낮은 프로세스를 위주로 프로세스 자원 선점

[운영체제/OS] 캐시(Cache)와 지역성(Locality) & 캐싱라인(Caching Line)

예민한고라니 — Mon, 29 Aug 2022 22:07:18 +0900

Cache

캐시 메모리(cache Memory)

캐시 메모리란 ?

주기억장치에서 자주 사용하는 프로그램과 데이터를 저장해두고 속도를 빠르게 하는 메모리
속도가 빠른 장치와 느린 장치간의 병목 현상을 줄여주며, 메인 메모리와 CPU사이에 위치한다
캐시가 효율적으로 동작하기 위해서는 CPU가 참조할 정보에 대한 예측이 잘 되어야함
- 즉, 캐시의 적중률(Hit-rate) 을 극대화 시켜야함
- 이때 나오는 개념이 캐시의 지역성(Locality)

캐시의 지역성(Locality)이란

데이터에 대한 접근이 시간적-공간적으로 가깝게 발생하는 것을 뜻함
이때 프로그램은 정보를 균일하게 참조하는 것이아니라, 어느 한 순간에 특정 부분을 집중 참조할 것이라는 전재 조건이 존재한다.
- 시간지역성 : 최근에 참조된 데이터가 곧 다시 참조되는 특성
- 공간지역성 : 최근에 참조된 데이터와 인접한 데이터가 참조될 가능성이 높은 특성

캐싱 라인(Caching Line)

캐싱라인이 뭔가요?

캐시는 프로세서 가깝게 위치하며 자주 사용 되는 데이터들은 저장하는 것
목적 데이터를 바로 접근하여 출력할 수 있어야 캐시가 의미가 있기때문에, 특정 자료구조를 사용하여 묶음으로 저장해놓는데, 이를 캐싱라인이라 칭함
즉, 캐시 메모리의 매핑 프로세스라고 말할 수 있음

캐싱라인의 종류

1. 직접 매핑(Direct Mapping)

메모리 주소와 캐시의 순서를 일치 시켜 지정된 캐시 라인으로만 사상하는 방식으로
즉, 캐시 1에는 메모리 1~~10번을, 캐시 2에는 메모리 11~~20을 위치시키는것
하지만 특정메모리 위치의 값을 자주 불러다 사용한다면 저장할 캐시 공간은 1개이므로 매번 캐시 교체가 일어남
즉 적중률과 성능이 낮지만 구현이 간단하고 쉬운 방법

2. 연관 매핑(Associative Mapping)

순서를 일치시키지 않고 필요한 메모리 값을 캐시의 어디든 편하게 저장한다
찾는 과정은 복잡하고 느리지만 필요한 캐시 위주로 저장하기에 적중률은 높다.
- 캐시는 일반메모리보다 속도가 빠르므로 캐시의 검색량보다 적중률을 신경쓰는게 바람직함

3. 직접 연관 매핑( Set Associative Mapping)

연관매핑과 직접매핑을 합쳐놓은 방식.
순서를 일치시키면서 일정 그룹을 두지만, 그 그룹내에서는 편하게 저장하는 방식이다.
블록화가 되어있어 검색에 조금더 효율적이며 적중률이 많이 떨어지지도 않는다.

[운영체제/OS] Process vs Thread 그리고 멀티스레드(Multi Thread)

예민한고라니 — Sat, 27 Aug 2022 23:55:21 +0900

Process vs Thread

Process를 알아보자!

프로세스의 의미

실행중인 프로그램을 의미한다.
다수의 프로그램이 병행 수행될수 있는 오늘날에는 시분할 시스템(타임쉐어링)의 작업단위로 사용됨

프로세스의 상태 변화

사진출처 : TOPCIT 교재

생성 -> 준비 : 스케줄러에 의해 프로세스가 호출됨.
준비 -> 살행 : 사전 정의된 스케줄링 알고리즘에 따라 프로세스가 CPU할당 받음. 해당과정을 디스패치(dispatch) 라고함
실행 -> 준비 : 더 높은 우선순위의 프로세스를 실행하거나, 자원할당시간 만료 후 준비상태로 다시 전환. 해당 과정을 타임아웃(Timeout) 이라 부름
실행 -> 대기 : 할당된 시간 이전 실행 중에 기타 입출력 요구, 페이지 교환, read, write 등으로 CPU를 다른 프로세서에 할당 양도한 상태. 즉, Block 상태
대기 -> 준비 : 위의 작업이 끝난 후, block 상태의 프로세스를 다시 준비상태로 돌려놓는다. WakeUP 상태 라고 부른다.

PCB (Process Control Block)

프로세스가 생성될때 고유의 PCB 생성, 프로세스 종료 후 PCB 제거
PCB에는 프로그램 카운터, 프로세스 상태, PID(프로세스 식별 번호)등 존재

프로세스 메모리 구조

Code(text) : 실행할 프로그램의 코드 저장
Data : 전연변수 및 정적변수 저장
- 추가적으로 BSS(Block Stated Symbol) 영역 존재 : 초기화 되지 않은 전역변수가 저장됨
Stack : 지역변수, 매개변수 등 잠시 사용되었다가 사라지는 데이터를 저장. 컬파일 타임에 크기가 결정된다.
Heap : 동적 데이터 영역으로, 메모리 주소 값에 의해서 참조되고 사용되는 영역. 런타임에 크기가 결정된다.
- 예를들어) Stack에서 포인터 변수를 할당하면, 포인터가 가리키는 heap영역의 공간을 원하는 크기만큼 할당해 사용
- Java 에서는 객체가 heap영역에 생성되고, Garbage Collection(GC)에 의해 정리
- C에서는 malloc() 을 이용하여 할당

Thread 를 알아보자!

스레드의 의미

프로세스 내에서 실제로 작업을 실행하는 주체로 경량프로세스(lightweight process)라고도 부름
1개의 프로세스는 최소 1개의 스레드를 가진다.

멀티 스레드

1개의 process에 2개 이상의 스레드를 가지는 프로세스를 멀티스레드 프로세스(multi-threaded process) 라고부름
1개의 프로세스 안에 존재하는 스레드들은, 프로세스의 메모리 구조 중 code, data, heap 영역은 공유되며, 각 스레드 별로 자신만의 Stack영역을 갖는다
대표적인 예로 웹서버가 존재한다

Context Switching을 알아보자!

콘텍스트 스위칭이란

현재 진행하고 있는 Task(Process, Thread)의 상태를 저장하고 다음 순위의 Task가 실행되도록 새로운 Task의 상태 또는 레지스터의 값(Context)를 교체하는 작업을 일컷는다
- 이떄 Context는 프로세스의 PCB에 저장된다
콘텍스트 스위칭이 진행될때 해당 CPU는 아무런 일도 하지 못한다
따라서 콘텍스트 스위칭이 잦아지면 오버헤드가 발생한다.
콘텍스트 스위칭을 하는 주체 = OS 스케줄러 이다

MultiThread 와 MultiProcess

멀티프로세스

장점

하나의 프로세스가 죽더라도 다른 프로세스에 영향을 끼치지 않음

단점

context 전환과 함께 각 프로세스의 memory도 전환됨. 즉 높은 context swtiching 비용 발생
상대적으로 많은 메모리 공간과 CPU 시간을 차지함

멀티스레드

장점

적은 메모리 공간을 차지
스레드간 통신 시 Heap 영역을 이용하여 데이터를 전달하므로 통신 방법이 간단해짐
code, data, heap 영역은 공유하기 때문에 context swtiching 비용이 상대적으로 적고 응답속도가 빠름
이로인해 시스템 처리량이 향상 됨

단점

동기화 문제 발생. 즉, 자원 공유 문제가 발생함
하나의 스레드에서 문제가 발생시 전체프로세스가 영향을 받는다.

해당 게시글은 github에서 관리 및 공부중인 CS-study respository 내용을 옮겨 적은 것 입니다.

잘못된 이야기가 있으면 언제든 댓글 남겨주세요!

GitHub - ye1ne/CS-Study: ‍ ‍ 예비 개발자의 컴퓨터공학 전공 지식 정리

‍ ‍ 예비 개발자의 컴퓨터공학 전공 지식 정리 . Contribute to ye1ne/CS-Study development by creating an account on GitHub.

github.com

[SWM/10주차] 테스트코드 작성하고,,,,,주저리 주저리

예민한고라니 — Sun, 14 Aug 2022 22:44:57 +0900

최근근황

사실 이번주도 딱히 특별한 이슈사항은 없었다.

그저 통계기능 나머지를 마저 구현하고, 기존의 코드를 손좀 보고 테스트코드를 왕창(?) 작성했다.

머리가 나쁘면 엉덩이가 고생한다고 ^^.. 아직 모르는게 많아서 코드짜는데 한참걸렸다.

원래 예외처리까지 오늘다하려고 했는데, 8시간이나 태웠는데도 목표치의 반도 도달 못함

근데이거 막상 돌리면 코드는 잘 돌아가는데.. 저기 objectMapper랑 mockMvc 타입의 bean을 찾을 수 없다고 밑줄이 뜬다.

너무 짱나서 막 구글링해봤는데..

"사람은 항상 기계보다 위대하다" 길래 그냥 밑줄 무시하고 하는중이다 ^^

아 그리고 보면.. 알다시피.. 테스트 코드를 개판으로 작성한 느낌이 낭낭해서 어떤 멘토님의 특강도 참여해 보았다^^..

테스트 코드는 given-when-then pattern으로 작성하면 된다고는 하지만

막상 작성하려고 보니까 구분도 너무 모호했고 이게.. 맞나..? 싶은 모먼트들이 너무나 많았기 때문이다

매주 일요일에 열리는데 부디 내가 스터디 내용을 잘 소화했으면 좋겠다

그 외

본인은 어떤 문제에 부딪혔을때 "대충 이런느낌 인가보네"라는 마인드로 접근하는 안좋은 습관을 가지고 있다.

어떤 현상이나 원리에대해 깊게 공부하는데에는 "왜?"라는 질문이 가장 중요한데 말이다.

질문.. 그거 어캐하는건데...

사실 질문도 아는게 많은 사람이 잘한다고 ... 아무것도 모르는 코린이인 나에겐 질문이라는 것 자체가 굉장히 어렵고 또 부끄럽다.

그럼에도 불구하고 요즘은 마음가짐을 고쳐먹기로 했다ㅠ

정말 말그대로 코린이니까! 누가 처음부터 잘하겠어 라는 마인드로 틀려도 부끄러워 하지 않기로 마음먹었다.

마음처럼 될지는 모르겠지만, 괜한 자존심 부리는 것보다야 내 인생에 더 도움될 것 같다는 생각이 든다.

이제 슬슬 하반기 공채랑 병행할 지옥같은 시기가 다가오고 있다...

부디.. 모든 취준생들다 화이팅 하시길.. 이번주도 끗!!