다음 글은 Real MySQL 스터디를 진행하면서 정리한 4.1장 내용입니다. 🙌 💡 Intro 프로젝트를 진행해보니 서비스의 대부분의 병목은 데이터베이스에서 발생한다는 것을 알 수 있었다. DBA가 아니더라도 기본적으로 파생된 쿼리가 어느 과정을 거쳐서 처리되는지, 성능을 좌우하는 시스템 변수들은 어떠한 것들이 있는지 아는 것이 매우 중요하다고 생각한다. MySQL 엔진은 데이터베이스의 뇌의 역할을 한다. 기본적은 서버 구조와 MySQL 엔진과 스토리지 엔진의 차이점 및 담당 부분을 이해해보자. 🌩 MySQL 서버의 구조 머리 역할을 하는 MySQL 엔진과 손발 역할을 하는 스토리지 엔진(InnoDB, MyISAM)이 있다. 스토리지 엔진은 핸들러 API를 만족하면 직접 구현하여 추가해서 사용할 수 있다. 🌩 MySQL 엔진 아키텍쳐 MySQL 전체구조 MySQL 엔진 먼저 MySQL 서버는 대부분의 상용 언어에서 지원할 수 있으며 MySQL 서버의 커넥션 핸들러에서 커넥션을 관…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 11] equals를 재정의하려거든 hashCode도 재정의하라 와 함께 도 재정의하지 않으면 이나 의 원소로 사용할 때 일관성이 무너진다. Object 명세에 따르면 다음 규약이 있다. eqauls(Object)가 두 객체를 같다고 판단하면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. 다시 말해서 논리적으로 같은 객체는 같은 해시코드를 반환해야 한다는 것이다. 해시코드가 같지 않으면 다음 코드에서 일관성이 깨진다. 좋은 hashCode를 작성하기 hashCode의 로컬 int 변수 result를 첫번째 핵심 필드의 해시코드로 초기화 한다. (여기서 해시코드는 다음 2.a 단계대로 계산한다.) 다음 핵심 필드 들에 대해서 다음과 같이 해시코드를 계산하고 result 필드를 갱신한다. 기본 타입 필드라면 Type.hashCode(f)를 수행한다. Type은 해당 기본 타입의 박싱 클…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 9] try-finally 보다는 try-with-resources를 사용하라 자바에서 close 메서드를 직접 호출해서 닫아주어야하는 자원들 , , 등등 try-finally 사용시 단점 try-finally를 사용한다면 닫아야 하는 자원이 많아질수록 매우 복잡해진다. try 블록과 finally 블록에서 모두 예외가 발생할 수 있는데, 만일 둘다 예외가 발생했을 경우 이후에 일어난 예외가 첫번째 예외를 삼켜서 디버깅을 어렵게 한다. try-with-resources로 해결 짧고 간결하여 읽기가 수월하다. try 내부와 에서 모두 예외가 발생 하더라도 첫번째 예외만 보여지고 두번째 예외는 되어 출력된다. catch 블록을 함께 사용하여 여러 예외를 처리할 수 있다. 🌩 [아이템 10] equals는 일반 규약을 지켜 재정의하라 대부분은 를 재정의 하지 않는 것이 가장 좋다. 책에서는 특히나…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 7] 다 쓴 객체 참조를 해제하라 JVM 언어를 사용한다면 GC가 알아서 사용되지 않는 객체를 해제할텐데 왜 이런 항목이 있는걸까? 다음과 같은 경우에는 GC가 해당 객체가 다 쓴 객체인지 아닌지 판단할 수가 없다. Stack 자료구조를 구현한 예시이다. 다음과 같은 경우 다시 참조되지 않을 객체에 대한 해제가 이루어지지 않았기 때문에 ‘메모리 누수’가 발생한다. 이 프로그램이 오랜시간 실행이 되다보면 메모리 사용량이 늘어나 성능이 저하되거나 심하면 를 일으킬수도 있다. 위 코드와 같은 경우 배열에 더이상 사용되지 않는 영역의 객체 참조를 배열이 여전히 가지고 있다. 예를 들면 바깥에 존재하는 객체들에 대해서 말이다. 이렇게 GC에게 객체 처리를 맡기는 언어에서 이러한 메모리 누수를 찾기가 매우 어렵다. 또한 쓰이지 않지만 참조되고 있는 객체의 영향이 해당 객체에서 끝이 나는 것이 아니라 해…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 5] 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 하나의 클래스에서 다른 자원에 의존하는 경우가 많다. 또한 해당 클래스가 유틸리티 클래스라면 싱글톤이나 정적 클래스로 사용되는 경우가 많다. 정적 클래스로 구현한 경우 싱글톤으로 구현한 경우 그런 경우 여러 단점이 발생한다. 유연하지 않다. 안에 의존하고 있는 객체를 런타임 시점에 바꾸거나 조작하기가 어렵다. 여러 다른 사전들을 이용하고 싶을 때 변경에 자유롭지 못하다. 테스트하기 어렵다. 정적으로 의존 객체를 내부에서 생성하므로 모킹하거나 해당 객체에 대한 조작으로 테스트를 하기 어렵다. 의존성 주입(DI)을 통해 해결하기 위 문제에 대한 가능한 해결방법이 DI 말고 하나가 더 있다. 변경에 대한 유연성을 부여하기 위해 을 제거하고 여러 사전들을 바꿔서 사용할 수 있도록 한다. 이렇게 할 경우 멀티스레드 환경에 취약하고 오류를 내기가 …

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 3] private 생성자나 열거 타입으로 싱글턴임을 보증하라 하나의 인스턴스만 생성할 수 있는 것이 싱글턴(Singleton) 패턴이다. 참고로 싱글턴을 사용할 경우 이것을 사용하는 클라이언트를 테스트하기가 어렵다. 싱글턴 객체의 생성지점을 제어하기 어려우므로 mock으로 대체하기가 어렵기 때문이다. 싱글턴 객체를 구현하기 위해서는 다음 3가지 방법을 사용할 수 있다. 1) private 생성자 & public static final 필드 생성자의 접근제어자가 private이므로 인스턴스는 오직 필드를 초기화할 때 단 한번만 생성된다. 일반적인 경우 클라이언트는 이 부분에 대한 권한이 전혀 없지만 예외적으로 을 사용한다면 private 생성자를 호출할 수 있기는 하다. (방어를 위해서는 두번째 생성자 호출시 예외발생) 장점 필드를 사용할 경우 싱글턴이라는 것이 분명히 드러난다. (이므로 재…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 1] 생성자 대신 정적 팩터리 메서드를 고려하라 정적 팩터리 메서드(static factory method)란? 해당 클래스의 인스턴스를 반환하는 정적 메서드이다. 예를 들어 다음 박싱 클래스를 반환하는 정적 메서드를 보자. 이 챕터에서 추천하는 바는 public 생성자 대신 정적 팩터리 메서드를 고려해보라는 것이다. 정적 팩터리 메서드는 장단점이 있다. 따라서 항상 정적 팩터리 메서드가 더 우수하다는 것은 아니다. 다만 습관적으로 public 생성자를 사용하기 이전에 상황을 살피고 정적 팩터리 메서드가 더 적합하다면 해당 메서드를 사용하도록 추천한다. 장점 이름을 가질 수 있다. 여러 종류의 생성자가 필요로 할 경우 매개변수의 수를 다르게 해서 추가하곤 한다. 하지만 이 매개변수와 생성자 자체로는 반환될 객체의 특성이나 언제 이 생성자가 사용이 되는지 설명할 수 없다. 따라서 이름을 가진 정적…

💡 Intro 애자일의 의도는 불확실성이 큰 소프트웨어 개발 분야에서는 꼼꼼한 초반 계획을 세우고 이행하는 형태는 불가능하다는 것에서 출발한다. 따라서 애자일은 불확실성이 더 큰 프로젝트일수록 적합하다. 하지만 저자는 애자일을 단순한 소프트웨어 개발론으로만 보지 않고 하나의 일하거나 삶을 사는 스타일로 확장해서 해석해본다. 어떻게 우리 삶에서, 일에서 애자일을 적용할 수 있을까? 지금까지 말한 학습과 협력이 애자일의 핵심 전략이 될 수 있다. 불확실성이 높은 프로젝트 일수록 안좋은 일이 생기기 쉽다. 그리고 안좋은 일은 ‘또는’ 조건에서 생기기 마련인데 애자일은 앞서 말한 서로의 업무를 공유하고 상호 검토하는 협력을 통해 ‘또는’ 조건을 ‘그리고’ 조건으로 만들어 확률을 낮춘다. 또한 좋은 일은 확장될 수 있도록 ‘또는’ 조건을 공유를 통한 ‘그리고’ 조건으로 변경한다. 공유를 통해 전체가 개선되도록 하는 것이다. 이 글은 세 번째 파트인 애자일 파트이다. 🌩 애자일의 씨앗 애자일…

💡 Intro 주로 협력이라고 하면 초반에 일을 나누고 선을 그어 따로 진행하는 것처럼 생각한다. 실제로 일을 나누는 것은 초반에 하기 어렵다. 왜냐면 그 일이 무엇인지 잘 모르기 때문이다. 그럼에도 불구하고 사람들은 일을 초반에 나누고 따로 진행하면서 협력이 아닌 협력을 한다. 요즘에 ‘함께’라는 것이 중요 키워드다. 회사와 구성원이 함께, 팀원들이 함께 성장하는 것에 관심이 많다. 이 글은 두 번째 파트인 함께 파트이다. 🌩 소프트웨어 관리자의 우선순위 다음 4가지 영역이 소프트웨어 개발의 관리에 영향을 미치는 요소들이다. 도구: 소프트웨어 개발에 사용하는 도구 사람: 사람의 능력과 경험 시스템: 제품의 복잡도, 요구 신뢰성, DB 크기 등등 관리: 사람을 배정하고 작업을 분배하고 위임. 작업을 모니터링, 동기 고취 환경 개선, 리스트 확인 및 적절한 조치 등등 주로 개발 비용을 개선하려면 도구나 사람을 개선한다. 즉, 더 좋은 도구로 바꾸거나 더 실력있는 사람을 데리고 오는 …

💡 Intro 앞에서 리액티브 프로그래밍에 대해서 다뤘었다. 한마디로 리액티브 프로그래밍에 대해서 정의하자면 비동기/논블로킹 이벤트 드리븐 개발과 배압을 통해 적은 수의 쓰레드로 생상자가 소비자를 압도하지 못하며 확장성있는 개발이 가능하게 하는 프로그래밍 기법이라고 할 수 있다. 리액티브 프로그래밍은 가용성(CPU utilization이라고 볼 수 있는 영역)과 응답성(오류가 생겨도 빠르게 응답 가능)을 향상시키므로 프로그램의 효율성과 성능을 높인다. 함수형 프로그래밍도 관련 중요 키워드이다. 리액티브 프로그래밍은 함수형 프로그래밍(선언형, 함수 조합, 등등)을 활용한다. Spring WebFlux는 Spring Framework5에서 추가된 모듈이다. 스프링이 리액티브 스택 웹 어플리케이션을 구축할 수 있도록 리액티브 스트림 API를 지원해 논블로킹/비동기식으로 동작할 수 있도록 한다. 🌩 Spring WebFlux 란? 기존의 Spring Web MVC는 Servlet API,…

💡 Intro 데이터의 그룹을 저장하는 클래스들을 표준화한 프로그래밍 방식 컬렉션 프레임워크는 다수의 데이터를 다루는 여러 클래스를 제공하여 개발자의 부담을 덜어준다. 인터페이스와 다형성을 이용해서 객체지향적으로 설계가 되어 있기 때문에 추상적이고 재사용성이 높은 좋은 프레임워크이다. 🌩 핵심 인터페이스 컬렉션에 담기는 데이터를 크게 3가지로 나누어 각각을 인터페이스로 정의해두었다. 그리고 3가지 중 List, Set의 공통점을 뽑아 따로 인터페이스로 추상화 되어 있다. 각 인터페이스와 특징은 다음과 같다. List: 순서가 있으며 중복이 허용된 데이터의 집합 ArrayList, LinkedList, Stack, Vector, etc. Set: 순서가 없으며 중복을 허용하지 않는 데이터의 집합 HashSet, TreeSet, etc. Map: 키와 값의 쌍으로 이루어진 데이터의 집합이며 순서를 유지하지 않으며 키는 중복을 허용하지 않음 HashMap, TreeMap, Hashtab…

💡 Intro 개발바닥의 김영한님 편을 보다가 꼭 추천하실 책이 김창준님의 함께 자라기라고 하셔서 바로 주문했다. 이 책을 읽으면서 얻고 싶은 것은 3가지였다. 내가 지금 성장하고 있는 방법이 잘 하고 있는 방법인가 요즘 그렇게도 강조하는 ‘함께’라는 것이 개발자에게는 어떤 의미인가 최근 진행한 7명 팀 프로젝트를 더 잘 할 수 있는 부분은 무엇이 있었을까 이 글은 첫번째 파트인 자라기 파트이다. 🌱 자라기 시간에 비례하여 실력이 상승하지 않는다. 중요한 것은 얼마나 오랜 기간 학습했느냐보다 얼마나 많은 의도적 수련을 했는지다. 업무를 하면서 의도적 수련을 할 수 있는 방법은 애자일 철학을 활용하는 것이다. 애자일에서 학습은 소프트웨어 개발에 큰 병목 중 하나이다. 그 이유는 일반 프로젝트에서 피드백의 주기가 느려서 결정을 내리고 학습을 한 후 다시 피드백을 받응ㄹ 시기에 이전에 내린 결정에 대한 이유를 기억하기 어렵다. 하지만 애자일 프로젝트에서는 당장 한 행동에 대한 피드백을 …

💡 Intro 트래픽이 증가하고 사용자가 기대하는 요청시간은 더 빠른 응답을 원하게 되면서 리액티브 프로그래밍이라는 개념이 대두가 되기 시작했다. Java 진영에서는 물론이고 현재 공부하고 있는 스프링 어플리케이션에서도 리액티브 개념을 구현한 모듈이 추가되고 활용되고 있다. 리액티브 프로그래밍을 키워드 중심으로 알아본다. (선언형, 리액티브 스트림, pub-sub 구조, 비동기, 옵저버 패턴 등등) 리액티브 프로그래밍이 주요 개념이 된 이유에 대해서 고민해본다. 🌩 리액티브 프로그래밍이란? ReativeX ReativeX는 옵저버 스트림을 활용한 비동기 프로그래밍을 위한 API이다. 그리고 이것을 구현한 여러 구현체들이 있다. 나 같은 경우는 자바 언어를 주로 사용하는데 자바 진영에서도 리액티브 API를 구현한 RxJava가 있고, 자바9 부터 리액티브 프로그래밍을 구현할 수 있는 Flow 클래스를 제공한다. Reactive - 무엇에 반응한다는 것인가? Reactive는 반응하다…

💡 Intro JVM은 자바의 큰 장점 중 하나로 이 가상머신이 깔려있는 운영체제에서는 모두 동일하게 자바 클래스 파일이 실행될 수 있다. JVM의 기본 구조를 알아보자 🙌 🌩 JVM 메모리 구조 1) Class Loader 2) Execution Engine 3) Garbage Collector 4) Runtime Data Area 4가지로 나뉘어져 있다. Class Loader JVM 내로 클래스 파일을 로드하고 링크를 통해 배치하는 작업을 수행한다. 런타임 시에 동적으로 클래스를 로드한다. Execution Engine 클래스 로더가 Runtime Data Area에 배치한 바이트 코드들을 명령어 단위로 읽어서 실행하는 작업을 수행한다. 최초 JVM에서는 인터프리터 방식이어서 느렸지만 JIT 컴파일러로 변경되면서 실행이 빠르다는 장점이 있다. 모든 코드 JIT으로 하지 않고 인터프리터로 하다가 일정한 기준이 넘어가면 JIT 컴파일러 방식으로 실행한다. 한번 읽어서 기계어로 변…

💡 Intro 스프링에서 어느날 등장한 개념은 아니고 어떠한 이름으로든 사용이 되고 있던 기술인데 스프링에서 더 잘 사용되도록 특정 형태를 부여했다. 이 3가지 기술들이 그 자체로 스프링이기보다 POJO 기반 엔터프라이즈 개발을 편하게 해줄 수 있는 일종의 도구이다. 즉, 객체지향적인 구현에 충실하면서 자연스럽게 등장하게 된 결과라고 할 수 있다. 스프링에서 제공하는 PSA, AOP만 사용하는 것이 아니라 그 개념을 차출하여 객체지향적 구현을 하는 것이 중요하다. 🌩 IoC/DI AOP, PSA도 IoC/DI에 바탕을 두고 있는 기술이다. 느슨한 결합을 위해 인터페이스를 두고 실제 구현체를 DI를 통해 외부에서 주입하는 것이다. 왜 강한 결합보다 느슨한 결합이 나은가? 유연한 확장이 가능하게 하기 위해서 → OCP 변경에 닫혀있다는 것은 재사용이 가능하다 라는 뜻이다. A → B 의존관계일 때 B가 변경이 되어도 A가 아무 영향을 받지 않으면 A 입장에서는 폐쇄이며 B 관점에서는 …

💡 Intro POJO에 대해서 ‘그냥 자바 객체요!’라고 말하는 것 이상으로 이해해보자. POJO기반 프레임워크란 무엇인지 이해해보고 스프링에서 POJO는 어떠한 형태를 띄는지 알아보자 스프링이 개발의 복잡도를 낮춰주고 효과적으로 프로그래밍을 할 수 있도록 구체적으로 어떻게 가능하게 하는지 공부해보자. 🌩 POJO 란? 유명한 스프링의 삼각형으로 기본 컨텍스트를 맞추고 설명을 시작해보자. 스프링은 POJO에 주요기술인 IoC/DI, AOP, PSA를 사용한 코드와 POJO가 어떻게 관계를 맺고 동작하는지 정의한 설계정보로 구분된다. 스프링에서 DI는 유연하게 확장 가능한 오브젝트를 만들고, 그 관계를 외부에서 dynamic하게 설정해주는 것이며 스프링에서는 이 아이디어를 전반에 걸쳐서 적용한다. POJO는 EJB처럼 복잡하고 제한이 많은 기술로 엔터프라이즈 애플리케이션의 비지니스 로직을 구현하는 것보다 순수 자바 객체를 사용하여 비지니스 로직을 구현하는 것이 더 좋다고 생각하여 …

💡 Intro 인터페이스와 추상클래스의 차이를 명확하게 구분해보자. 언제 무엇을 쓰는 것이 좋은지 나름의 정의를 내려본다. 상속의 위험성에 대해서 고민해본다. 🌩 추상클래스 추상 클래스는 “미완성 설계도” 이다. 공통부분을 우선 정의한 미완성 설계도를 만들고 각기 다른 상황에 대해서 추가로 구현할 수 있다. 완성되지 않은 abstract 메소드를 포함하고 있다. 추상클래스는 abstract 메소드가 있다는 것을 제외하고는 일반클래스와 동일하다. 상속은 자손 클래스를 만드는데 조상 클래스를 사용하는 것 추상화는 자손 클래스의 공통부분을 뽑아내서 조상 클래스를 만드는 것 상속 추상클래스를 하는 명령어가 상속에서 사용되기 때문에 두 개념이 혼용되어서 사용되기도 한다. 엄밀히 말하면 두 개념이 겹칠수도 있지만 완전히 동일한 것은 아니다. 상속이란 기존의 클래스를 재사용하여 새로운 클래스를 작성하는 것 적은 양의 코드로 새로운 클래스를 작성할 수 있고 공통부분을 관리할 수 있다는 장점이 …

💡 Intro 효율적인 프로그래밍을 위해 멀티 스레드 환경에서 구동을 할 때가 많다. 멀티 스레드의 간단한 장점과 항상 헷갈렸던 사용자 레벨 스레드 vs. 커널 레벨 스레드에 대해서 알아보자. 🌩 Multi-thread 장점 1. 응답성 어플리케이션의 일부분이 봉쇄되거나 긴 작업을 실행하더라도 다른 부분의 프로그램이 계속 실행되는 것을 허용하기 때문에 사용자의 입장에서 응답성이 증가한다. 예를 들어 다운로드가 오래 걸리는 파일을 다운로드 하면서 사용자와의 상호작용이 가능하다. 2. 자원 공유 resource sharing 프로세스는 완전히 별도의 메모리 공간을 할당받기 때문에 (code, data, heap) 서로 통신하기 위해서는 공유 메모리를 사용하거나 메세지 전달 기법 (IPC)를 사용해야한다. 스레드는 속한 프로세스의 자원을 공유하기 때문에 한 프로그램이 같은 주소 내에서 여러개의 다른 작업을 하는 단위로 나뉘어질 수 있다는 이점이 있다. 3. 경제성 economy 프로세스…

💡 Intro 왜 하필 스프링 인가? 라는 질문을 던지게 되면서 스프링이 가지고 있느 장점에 대해서 고민해보았다. 그 중 기존의 싱글톤 패턴의 한계를 뛰어넘은 스프링 싱글톤 레지스트리를 알게 되었다. 이전에 단순히 스프링이 싱글톤 scope으로 객체를 관리하여 여러 요청이 동시에 들어오는 환경에서 안정적으로 서비스할 수 있다는 장점을 들었지만 싱글톤 패턴과 어떻게 다른지 알지 못했다. 그래서 알아보자 🙌 🌩 싱글톤 패턴이란? 왜 싱글톤 패턴이어야 할까 하나의 서버에 초당 수많은 요청이 도착하고 처리되어야 한다. 요청이 올 때마다 서버에서 관련 객체를 생성하는 것은 굉장히 큰 오버헤드이다. 어떤 오버헤드가 발생할 수 있을까 ? 주로 서버는 여러 계층의 레이어를 지나고 여러 비지니스 오브젝트들이 협력하여 요청을 처리한다. 요청 하나당 대충 5개 정도의 오브젝트가 생성되고, 초딩 300개의 요청, 1분에 18000개의 요청이 발생한다면 18000 * 5 만큼의 새로운 오브젝트가 생성된다…

다음은 우아한테크코스 막바지 글쓰기 미션 때 제출한 글 입니다. 진솔한 마음으로 써서 올려봅니다 😶 내가 꿈꾸는 프로그래머로서의 삶 처음 프로그래머를 꿈꾸게 된 명확한 이유가 있다. 프로그래밍은 많은 사람에게 영향을 줄 수 있는 가장 좋은 도구이기 때문이다. 나이가 많거나 적거나, 물질적으로 풍요롭거나 아니거나, 어떤 언어를 쓰거나 상관없이 대부분의 사람은 기술을 접할 수 있는 기기를 하나씩 가지고 있다. 한 애플리케이션을 전 세계가 쓰기도 하고, 특정 플랫폼을 통해 콘텐츠가 확 퍼지기도 한다. 그렇기에 내가 꿈꾸는 프로그래머로의 삶은 많은 사람에게 선한 영향력을 끼치는 것이다. 굉장히 붕 뜬 이상주의자처럼 들릴 수도 있지만 사실 나는 그런 사람은 아니다. 한때 MBTI 검사를 하면 감정을 나타내는 수치인 F가 빵점이 나올 정도로 (지금은 많이 바뀌었다) 기본이 이성적인 사람이다. 흔히 이성적이며 현실적인 사람에 대해서 이야기할 때 부정적이고 “현실적으로 안 된다”라고 말하는 사람…

다음은 TestRestTemplate 링크 를 번역하면서 공부한 글입니다. 🙌 기존에 RestTemplate을 활용하여 통합테스트를 많이 했을 것이다. 스프링부트에는 굉장히 비슷하게 동작하는 TestRestTemplate이 있다. 두가지 모두 통합테스트에서 유용하며 HTTP API를 다룰 수 있다. TestRestTemplate의 예시를 한번 들여다보자. RestTemplate과 거의 유사한 형테를 지니고 있다. 하지만 TempRestTemplate은 RestTemplate을 확장하지 않으며 몇가지 다른 기능을 제공한다. 🌩 TestRestTemplate은 무엇이 다를까? 1. Auth Credentials을 설정할 수 있는 생성자를 제공한다. TestRestTemplate을 생성할 때 기본 authentication을 설정하여 생성할 수 있다. 그러면 해당 인스턴스를 활용한 모든 요청이 해당 credential이 적용된 채로 수행된다. 2. HttpClientOption을 제공하…

다음 링크를 읽고 정리한 내용입니다 🙌 이전에 작성했던 글이 있습니다. 스프링부트에서 지원하는 여러 테스팅 기법들을 통해서 단위 테스트나 스프링 컨텍스트를 띄우는 통합 테스트를 진행할 수 있다. 사전 준비로는 스프링부트 프로젝트에 의존성을 추가해야한다. 🌩 @SpringBootTest 통합테스트 통합테스트는 어플리케이션의 여러 레이어의 통합 로직을 테스트 하는 것이다. 따라서 mocking을 하지 않는다. 원칙적으로는 통합테스트는 단위테스트와 분리되어 있어야하며 실행 또한 분리해서 실행해야 한다. 다른 profile 환경으로 나누고 통합테스트만을 분리하여 실행해야한다. 이렇게 해야하는 이유 중 하나는 통합 테스트는 어플리케이션 컨텍스트를 띄우는 작업을 필요로 하기 때문에 상대적으로 긴 시간이 소요된다. 또한 실제 데이터베이스의 실행을 필요로 하기도 한다. 은 컨테이너 전체를 띄우는데 유용하다. 이 어노테이션은 테스트에 사용될 ApplicationContext를 생성하여 테스트…

🌩 왜 혼잡제어가 필요할까? 라우터에 패킷이 몰리면 패킷이 유실되고 패킷을 재전송 하면서 네트워크는 더 혼잡해진다. 송신측에서 이러한 문제를 해결하기 위해 전송속도를 줄이는 혼잡 제어를 사용한다. 🌩 AIMD Additive Increase, Mutiplicative Decrese 패킷을 하나씩 보내고 문제없이 도착하면 window 크기를 1개씩 증가한다. 패킷 전송에 실패하면 속도를 절반으로 줄인다. 이 경우 나중에 네트워크에 진입한 쪽이 처음에는 불리하지만 점점 동일한 평형상태가 되기 때문에 공정하다. 네트워크 혼잡을 미리 감지하지는 못하고 혼잡하면 대역폭을 줄인다. 🌩 Slow Start AIMD는 처음 전송속도를 올리는 것이 너무 느리다는 단점이 있다. slow start는 처음에는 문제가 없다면 윈도우 사이즈를 지수함수꼴로 증가한다. 혼잡 현상이 발생하면 window사이즈를 1로 떨어뜨린다. 하지만 이때는 네트워크의 혼잡율을 어느정도 예상할 수 있다. 따라서 혼잡 현상이 …

💡 INTRO 팀과 함께 나름 큰 프로젝트를 진행했다. 또한 추후에 있을 꽤 많은 사람들(약 100명 예상)이 참여하는 데모를 준비했다. 실제 사람들에게 사용되려니 고려해야할 것이 굉장히 많았다. 기능이 제대로 돌아가는 것도 중요하지만 많은 사용자에게 실제로 서비스 될 수 있는지까지 고려해야했다. 따라서 어플리케이션이 실제로 구동되는 OS에 대한 지식이 없이는 어플리케이션의 안정성에 대한 판단력을 가지기 어렵다고 생각했다. 따라서 운영체제 관련 책을 읽고 (추후 업로드 예정) 책에 빠진 부분을 보충하여 학습한다. 🌩 KEYWORDS 교착상태 특징 필요 조건들 자원 할당 그래프 .. 교착상태 처리 방법 교착상태 예방 상호 배제 Mutual Exclusion 점유하여 대기 Hold and Wait 비선점 No Preemption 순환 대기 Circular Wait 교착상태 회피 안전 상태 Safe State 자원 할당 그래프 알고리즘 Resource-Allocat…

💡 INTRO 팀과 함께 나름 큰 프로젝트를 진행했다. 또한 추후에 있을 꽤 많은 사람들(약 100명 예상)이 참여하는 데모를 준비했다. 실제 사람들에게 사용되려니 고려해야할 것이 굉장히 많았다. 기능이 제대로 돌아가는 것도 중요하지만 많은 사용자에게 실제로 서비스 될 수 있는지까지 고려해야했다. 따라서 어플리케이션이 실제로 구동되는 OS에 대한 지식이 없이는 어플리케이션의 안정성에 대한 판단력을 가지기 어렵다고 생각했다. 따라서 운영체제 관련 책을 읽고 (추후 업로드 예정) 책에 빠진 부분을 보충하여 학습한다. 🌩 KEYWORD 경쟁 상태 Race Condition 임계 영역 문제 The Critical-Section Problem 피터슨 해결안 Peterson’s Solution - 소프트웨어 측면 세마포어 Semaphores & 뮤텍스 Mutex 동기화 문제들 유한 버퍼 문제 Readers-writers 문제 식사하는 철학자들 문제 🌩 경쟁 상태 Race condit…

💡 Intro JPA를 프로젝트에서 사용하면서 연관 엔티티를 호출할 때 생기는 N+1을 해결한 경험이 있다. 이때 해결 방법으로 hibernate의 를 yml에 설정하여 해결했었다. 참고링크 해결부분 프로젝트를 전반적으로 체크하던 와중에 위 설정에 의한 in query가 실행되지 않고 여전히 N+1 문제가 발생하는 부분을 발견하였다. 해당 현상을 공유하기 위해 글을 작성한다. (여전히 이유는 못 찾았다 😢) 🌩 우선 간단하게 위 설정에 대해서 짚고 넘어가보자. 설정할 수 있는 방법은 두 가지 이다. 어노테이션 활용 클래스, 메소드, 필드 레벨에서 사용할 수 있다. 해당 사이즈 만큼의 상위 엔티티 id가 in query로 나간다. 를 application.properties에 지정 전역적으로 적용이 되어서 상위 엔티티의 lazy loading된 하위 엔티티를 한꺼번에 in query로 로딩한다. Hibernate javadocs 공식 문서에 다음과 같이 서술한다. 즉, 속한 co…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH9. 디스크 관리를 읽고 정리한 내용입니다 🙌 🌩 들어가기 전 컴퓨터 시스템의 대표적인 2차 저장장치이다. 메모리는 휘발성이지만 디스크는 데이터를 영구저장할 수 있다. 🌩 1. 디스크의 구조 디스크 외부에서 디스크를 일정크기 저장공간들로 이루어진 1차원 배열로 취급한다. 그 저장공간들을 논리 블록 logical block 이라고 한다. 디스크에 데이터가 저장될 때 논리블록 단위로 저장되고, 입출력도 논리블록 단위로 전송된다. 데이터 접근을 위해 배열처럼 블록 인덱스를 디스크에 전달하고 디스크 컨트롤러가 해당 논리블록의 물리적 위치를 찾아 요청 데이터에 대한 입출력 작업을 수행한다. 섹터 sector - 논리 블록이 저장된 물리적 위치 논리블록과 섹터는 1대1 매핑 디스크는 마그네틱 원판들로 구성되며 원판은 트랙, 트랙은 섹터로 나뉜다. 원판의 동일한 위치의 트랙들을 실린더라고 부른다. 디스크의 가장 바깥 실린더의 첫 트랙의 …

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH8. 가상 메모리를 읽고 정리한 내용입니다 🙌 🌩 들어가기 전 시분할 환경에서는 여러 프로세스가 동시에 메모리에 올라와서 수행되기 때문에 어떤 메모리에 어느 정도의 메모리를 할당해야할지가 문제이다. 운영체제는 몇몀 프로그램에게 집중적으로 메모리를 할당하고 시간이 흐른다음 메모리를 회수하여 다른 프로그램에게 집중적으로 메모리를 할당하는 방식을 택한다. 프로그램마다 프로세스를 빠르게 수행하기 위해서 확보해야하는 최소한의 메모리 크기가 있기 때문이다. 프로세스의 전체가 올라가는 것이 아니라 스왑 영역에 일부분은 내려놓기 때문에 프로세스 입장에서 물리 메모리 크기 제약은 생각하지 않게 된다. 또한 운영체제는 각 프로세스가 자기만 메모리에 올라간 것처럼 여겨질 수 있는 가장 메모리를 지원한다. 각자의 주소 공간을 가정하여 모든 프로세스가 0번지부터 시작한다. 일부는 스왑 영역에 일부는 메모리에 있다. 프로세스의 주소 공간을 메모리로 …

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH7. 메모리 관리를 읽고 정리한 내용입니다 🙌 🌩 들어가기 전 우리가 흔히 사용하는 컴퓨터 주소 체계는 32비트 혹은 64비트로 나뉘어져 있다. 32비트면 32개의 비트로 주소를 표현할 수 있는 것이다. 2^32가지 다른 메모리 위치를 구분할 수 있다. 컴퓨터는 바이트 단위(8비트)로 주소를 부여한다. 따라서 2^32 바이트 만큼의 메모리 공간에 서로 다른 주소를 할당할 수 있다. 32 비트를 계층적으로 묶어서 관리한다. 보통 4KB (2^12 바이트) 단위로 묶어서 페이지(page)를 구성한다. 페이지 내에서 주소를 구분하기 위해서는 12비트가 필요하다. 따라서 32비트 중 하위 12비트는 페이지 내에서 주소를 나타낸다. 🌩 1. 주소 바인딩 프로세스의 주소 공간 (address space)는 프로그램이 실행되기 위해 메모리에 적재되면 프로세스를 위한 독자적인 주소 공간이 생성된다. 논리적 주소 (logical addres…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH6. CPU 스케줄링를 읽고 정리한 내용입니다 🙌 🌩 INTRO CPU는 PC가 가리키는 명령어를 하나씩 수행하기 때문에 효율적으로 관리해야한다. 기계어 명령은 다음 3가지로 나뉜다. CPU 내에서 수행되는 명령 ADD 명령 수행 속도 빠르며 일반명령 CPU 버스트 메모리 접근을 필요로 하는 명령 LOAD 명령 메모리에 있는 데이터를 CPU로 읽는 명령 CPU 명령보다는 오래 걸리지만 비교적 빠르며 일반명령 CPU 버스트 입출력을 동반하는 명령 입출력 작업이필요한 경우이며 오랜 시간이 소요 특권명령으로 운영체제를 통해 서비스를 대행해야한다. I/O 버스트 CPU 수행은 위 명령어의 조합과 반복으로 이루어진다. 각 프로그램마다 위 명령어들의 비율이 다르며 CPU 연산이 많이 이루어지는 것을 CPU 바운드 프로세스, I/O 연산이 많이 일어나는 것을 I/O 바운트 프로세스라고 한다. I/O 바운드 프로세스는 사용자 인터렉션이 많…

이 글은 다음 링크를 번역하며 공부한 글입니다 🙌 💡 Intro 성능 테스트에 관련한 공부 및 적용을 하면서 좋은 아티클을 추천 받았다. (Thanks to 제리 👍) 관련 명령어들에 대해서 공부하고 각 칼럼이 의미하는 os 및 네트워크 기초 지식을 메꾸보자. 1. uptime 실행되기를 기다리는 프로세스의 갯수를 출력한다. 리눅스 시스템에서는 CPU를 기다리는 프로세스와 uninterruptible I/O (disk I/O) 에 의해 프로세스가 막혀있을 수 있다. 따라서 이 수치를 통해서 리소스 부하를 간편하게 확인 할 수 있다. 위 세개의 번호는 각각 1분, 5분, 15분 간 실행되지 못하고 대기 중인 프로세스 갯수를 나타낸다. 시간 추이에 따른 부하 상태를 통해 상황을 유추할 수도 있다. 2. dmesg | tail 마지막 10개의 시스템 메세지를 출력한다. 여기서 성능에 이슈를 일으킨 에러 메세지를 확인할 수 있다. oom-killer나 TCP 요청 드랍 같은 경우를 확인할…

💡 Intro 진행 중인 프로젝트에서 구현한 웹 어플리케이션이 어느 정도의 부하를 견딜 수 있는지에 대한 성능테스트를 진행했다. 프로젝트는 개발자를 타켓으로 한 깃헙 레포지토리를 연동한 게시물을 업로드하여 개발자들이 자신의 작업을 공유하고 다른 이들의 프로젝트를 캐줄얼하게 엿볼 수 있는 SNS형 웹 어플리케이션이다. 웹 어플리케이션에 들어가자마자 최신순으로 정렬된 게시물 피드를 볼 수 있다. (비로그인/로그인 모두 가능) 홈피드 게시물 조회 성능테스트를 진행, 병목 지점을 분석하고 개선하는 과정을 따라가보자. 🌩 사전 작업 테스트 더미 데이터 입력 테스트를 진행하기 위해서는 실제 운영환경과 최대한 유사한 환경에서 테스트하는 것이 중요하다. 운영환경과 유사한 환경이라고 하면 크게 1) 인프라 구조 2) 데이터 두 가지가 있다. 먼저 대량의 더미 데이터를 입력하도록 한다. (팀원 케빈이 수고해주었다 !! 👍) MariaDB 쿼리 캐시 끄기 왜 쿼리 캐시를 껐을까? 실제 어플리케이션에서…

💡 Intro 이전 포스트에서 진행한 프로젝트에서 홈피드 게시물 조회 성능 테스트에 대한 결과를 보고 개선대상을 파악하고 개선한다. 개선 후 테스트를 재진행하여 결과를 비교한다. 🌩 쿼리 진단 이전 포스트에서 진행한 성능 테스트를 통해 DB 쿼리 쪽 병목이 있다는 것을 알아냈다. 구체적으로 쿼리를 자세히 살펴보면서 어떤 문제가 있는지 확인해보자. 홈피드 게시물을 반환할 때 발생하는 slow query 현재는 포스트 조회하는 쿼리가 최대값으로는 3.62 초가 소요된다. 쿼리의 실행계획을 확인해서 문제점을 파악해보니 100만건의 데이터를 거의 다 훑으면서 filesort를 하고 있었다. 게시물을 최신순으로 정렬하여 상위 10개를 가지고 오는 Pagination을 적용하고 있기 때문이다. 🌩 개선하기 createt_At 칼럼에 인덱스를 추가하여 데이터가 정렬되도록 한다. 인덱스를 건 후 실행계획을 확인해보니 filesort가 제거되었고 훑는 row 수가 대폭 줄어들었다. 🌩 개선 후 성…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH5. 프로세스 관리를 읽고 정리한 내용입니다 🙌 🌩 1. 프로세스의 개념 프로세스란 실행 중인 프로그램이다. 프로세스는 CPU를 획득해서 코드를 수행하고 CPU를 반환하고 입출력 작업을 수행하기도 한다. 프로세스 문맥 (context) - 프로세스가 현재 어떤 상태에서 수행되고 있는 규명하기 위해 필요한 정보 여러 프로세스가 CPU를 사용하면서 중간에 CPU를 다른 프로세스에게 넘겨야 한다. 이때 다시 이어서하기 위한 필요 정보가 있는데 그것을 프로세스 문맥이라고 한다. 프로세스의 주소 공간, 레지스터의 값, 시스템 콜을 통해 커널에서 수행한 일의 상태, 프로세스에 대해 커널이 관리하고 있는 여러 정보들을 포함한다. 프로세스 문맥은 3가지로 나뉜다. 하드웨어 문맥 CPU의 수행 상태를 나타낸다. 프로그램 카운터 값, 각종 레지스터에 저장하고 있는 값들이다. 프로세스의 주소 공간 코드, 데이터, 스택으로 이루어진 프로세스의 독…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH4. 프로그램의 구조와 실행를 읽고 정리한 내용입니다 🙌 🌩 1. 프로그램의 구조와 인터럽트 CPU에서 프로그램 명령을 실행하기 위해서는 프로그램 명령을 담은 주소 영역이 메모리에 올라가야한다. 주소 영역은 code(프로그램 함수들이 기계어로 변환되어 저장), data(전역 변수 등 프로그램이 사용하는 데이터 저장), stack(함수 복귀 주소 및 데이터 임시 저장)으로 구분된다. 함수를 호출하여 새로운 함수 위치로 점프할 때 다시 돌아올 주소를 스택 영역에 저장한다. 인터럽트 동작 원리도 함수의 호출과 비슷하다. 인터럽트 발생시 실행중이던 명령어의 위치를 저장한다. 처리루틴 후 해당 주소로 돌아와서 수행을 이어간다. 이 주소는 운영체제가 관리하는 PCB에 저장된다. 🌩 2. 컴퓨터 시스템의 작동 개요 CPU는 매 시점 특정 주소에 존재하는 명령을 읽어서 그대로 실행한다. CPU가 실행해야할 명령의 메모리 위치는 Progra…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH3. 컴퓨터 시스템의 동작원리를 읽고 정리한 내용입니다 🙌 🌩 1. 컴퓨터 시스템의 구조 내부 장치 - CPU, 메모리 외부 장치 - 디스크, 키보드, 마우스, 모니터, 네트워크 장치 등등 입출력장치라고 한다. 각 하드웨어 장치를 각각의 컨트롤러가 제어한다. 컴퓨터는 외부장치에서 내부장치로 데이터를 읽어 연산한 후 결과를 외부장치로 내보내는 방식으로 동작한다. input - 내부로 들어오는 것 output - 외부로 내보내는 것 여러 프로그램을 동시에 수행할 수 있도록 하는 것이 운영체제이기 때문에 항상 메모리에 상주한다. 전체가 상주하기엔 너무 낭비이기 때문에 꼭 필요한 부분만 항상 메모리에 상주하고 그 부분을 **커널(kernel)**이라고 한다. 🌩 2. CPU 연산과 I/O 연산 I/O 연산들은 입출력 컨트롤러가 담당하고 컴퓨터 내부의 연산은 메인 CPU가 담당한다. 입출력 장치와 메인 CPU는 동시 수행이 가능하다.…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH2. 운영체제 개요를 읽고 정리한 내용입니다 🙌 🌩 1. 운영체제의 정의 운영체제란 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어이다. 사용자가 직접 하드웨어를 다루는 것이 쉽지 않기 때문에 하드웨어를 기본적으로 운용하는 운영체제를 탑재해서 사용하도록 한다. 좁은 의미 운영체제 vs. 넓은 의미 운영체제 운영체제도 소프트웨어이기 때문에 컴퓨터가 켜지면서 메모리에 올라가서 사용이 되어야 한다. 하지만 운영체제 전부를 메모리에 올려서 사용하기에는 리소스 낭비가 심하기 때문에 꼭 필요한 부분만을 전원이 켜짐과 동시에 메모리에 올린다. 메모리에 전원이 켜짐과 동시에 상주하는 부분을 커널이라고 한다 ⇒ 좁은 의미의 운영체제 이후 필요한 부분은 그때그때 사용자 유틸리티로 메모리에 올려서 사용한다 ⇒ 넓은 의미의 운영체제 파일 복사 등등 🌩 2. 운영체제의 기능 1) 하드웨어와 2) 사용자를 위한 역할 두가지를 중간에서 담당한다. 하드…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH6. 웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아간다 입니다 🙌 🛺 [Story3] 웹 서버 소프트웨어가 리퀘스트 메시지의 의미를 해석하여 요구에 응한다. 1. 조회의 URI를 실제 파일명으로 변환한다 http 요청 메세지의 메소드와 URI에 따라서 웹 서버 내부의 동작이 달라진다. URI에 적힌 경로에 따라서 데이터를 얻어 응답하는 것이다. 하지만 이 데이터를 반드시 디스크에서 읽는 것은 아니다. URI에 기록된 경로명의 파일을 읽어오면 디스크의 파일이 전부 노출되기 때문에 무방비해진다. 해결 방법으로 웹 서버에 공개하는 디렉토리를 디스크의 실제 디렉토리가 아니라 가상으로 만든 디렉토리 구조를 사용하도록 한다. 웹 어플리케이션 내부에서 가상으로 설정한 디렉토리와 실제 데이터를 대응하여 해당 데이터를 반송하도록 한다. 만일 브라우저에서 보낸 URI에 마지막 파일명이 생략되면 def…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH6. 웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아간다 입니다 🙌 🛺 [Story1] 서버의 개요 1. 클라이언트와 서버의 차이점 서버도 클라이언트로부터 전송된 패킷을 받기 위해서 준비 단계를 거쳐야한다. 서버와 클라이언트의 차이점 네트워크와 관련된 전체적인 구조는 비슷한 형태를 지니고 있다. 하지만 서버는 소켓을 미리 열고 클라이언트의 연결을 기다린다는 점, 여러 클라이언트와 소통해야 한다는 점에서 클라이언트와 차이점을 가지고 있다. 2. 서버 어플리케이션의 구조 서버 프로그램에서 다수의 클라이언트와 소켓 통신을 하기 위해서 다음과 같은 구조로 진행한다. 서버 프로그램에서 클라이언트의 접속을 기다리는 부분과 클라이언트와 대화를 하는 부분을 나눈다. 클라이언트와 대화를 하는 부분은 각 클라이언트와 1대1로 대화를 한다. 따라서 대화가 섞이지 않는다. 서버 OS의 멀티태스크, 멀티스레…

Intro JPA의 사용시 별칭을 쓰면 안되는 이유가 무엇인지 알아본다. 프로젝트애서 fetch join 시 별칭 사용에 대해서 고민해본다. fetch join 별칭은 왜 안될까 ? fetch join에서 별칭이 안되는 이유는 데이터의 일관성이 깨지기 때문이다. 예를 들어서 다음과 같은 코드는 fetch join 대상에 조건문이 들어가서 일관성이 깨진 경우이다. TeamA에 대한 member collection 은 본래 3개이다. 그리고 fetch join을 하면 연관된 데이터가 모두 들어올 것이라고 가정한다. 하지만 위와 같이 fetch join 대상에 별칭을 주어 where 필터링 조건을 사용하면 실제로 TeamA에 연관된 멤버는 3명이지만 만 연관 데이터로 들어온다. DB의 상태에 대한 일관성이 깨진다. 하지만 예외는 있다 일관성을 해치지지 않는 한에서 성능에 도움이 된다면 예외적으로 사용해도 된다. (아마도 하이버네이트가 별칭을 허용하는 이유…) 예를 들어 다음과 같은 쿼…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH5. 서버측의 LAN에는 무엇이 있는가?_방화벽과 캐시 서버의 탐험입니다 🙌 🛺 [Story4] 캐시 서버를 이용한 서버의 부하 분산 1. 캐시 서버의 이용 프록시 구조를 사용하여 데이터를 캐시에 저장한다. 프록시는 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개한다. 중개하는 과정에서 웹 서버에서 받은 데이터를 저장해두고 가능하면 해당 데이터를 대신하여 응답한다. 웹 서버가 처리해야할 일을 실행하기 위해서 오랜 시간이 걸리는 반면 캐시 서버는 받은 데이터를 곧바로 송신만 하면 되기 때문에 매우 빠르다. 데이터가 자주 바뀌는 부분은 캐시 서버를 활용하기 어렵다. 하지만 캐시 서버에서 처리할 수 있는 얼마를 담당하면 웹 서버에 가는 부하도 줄어들어 처리속도도 향상된다. 2. 캐시 서버는 갱신일로 콘텐츠를 관리한다 캐시 서버가 동작할 때 캐시 서버를 웹 서버 대신 DN…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH5. 서버측의 LAN에는 무엇이 있는가?_방화벽과 캐시 서버의 탐험입니다 🙌 🛺 [Story1] 웹 서버의 설치 장소 1. 사내에 웹 서버를 설치하는 경우 사내 LAN에 서버를 설치하고 인터넷에서 직접 액세스 하는 경우 (a) 이 경우는 현재 주류가 아님 IP 부족 - 이 경우 서버와 클라이언트에도 글로벌 주소를 할당해야하는데 IP 주소가 매우 부족하다. 보안상의 이유 - 인터넷에서 들어오는 패킷이 그대로 중계되는데 어플리케이션에 보안 구멍이 있다면 어플리케이션은 무방비 상태가 된다. 방화벽 보안 문제를 해결하기 위해서 방화벽을 두어 관문의 역할을 하도록 한다. (b) 특정 서버에서 동작하는 특정 어플리케이션에 액세스 하는 패킷만 통과시키고 나머지는 차단하도록 한다. 외부 액세스가 허가되지 않은 어플리케이션에 대한 패킷은 차단이 되므로 도착하지 않는다. 액세스가 허가된 어플리케이션에 보안구…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH3. 케이블의 앞은 LAN 기기였다_허브와 스위치, 라우터의 탐험입니다 🙌 🛺 [Story3] 라우터의 패킷 중계 동작 1. 라우터의 기본 라우터의 동작은 스위치 허브와 비슷하지만 IP와 이더넷의 차이로 인한 세부 동작의 차이점이 있다. 라우터는 크게 1) 중계 부분과 2) 포트 부분으로 나뉘어져 있다. 중계 부분은 다음 중계 대상을 판단하고 포트 부분은 송수신 동작을 담당한다. 라우터의 포트 부분은 이더넷이나 무선 LAN 외에도 ADSL, FTTH 등의 통신 기술을 지원한다. 라우터의 내부 구조 포트 부분에서 패킷을 수신하며 포트 부분의 통신 기술 규칙에 따라서 수신한다. (포트 부분의 하드웨어 부분이 패킷을 수신하는 것) 중계 부분에서 받은 패킷의 수신처 IP주소와 중계 대상을 동록한 표를 대조하여 중계 대상을 판단한다. 해당 포트로 옮기고 포트의 하드웨어에 따라서 패킷 송신 동작을 실…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH3. 케이블의 앞은 LAN 기기였다_허브와 스위치, 라우터의 탐험입니다 🙌 🛺 [Story1] 케이블과 리피터, 허브 속을 신호가 흘러간다 1. 패킷 하나하나가 독립적으로 동작한다 케이블로 흘러간 패킷은 중계 장치를 경유해서 목적지에 도착한다. 중계 장치는 데이터의 내용을 보지 않고 헤더에 적힌 정보만 보고 중계한다. 기본적인 흐름은 LAN 어댑터 → 리피터 허브 → 스위칭 허브 → 라우터를 경유해서 인터넷으로 나가는 것이다. 2. LAN 케이블은 신호를 약화시키지 않는 것이 핵심이다 LAN 어댑터의 PHY(MAU)회로에서 신호가 나가 케이블에 흘러 리피터 허브의 커넥터 부분에 도착한다. 이때 케이블을 이동하고 그 길이가 길어지면서 신호가 약해져서 변형된다. 3. 꼼은 잡음을 방지하기 위한 방법이다. 선을 꼬게 되면서 전자파에 의한 잡음을 상쇄한다. 4. 리피터 허브는 연결되어 있는 전체 …

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH2. TCP/IP의 데이터를 전기 신호로 만들어 보낸다_프로토콜 스택과 LAN 어댑터의 탐험입니다 🙌 🛺 [Story4] 서버에서 연결을 끊어 소켓을 말소한다 1. 데이터 보내기를 완료하고 연결을 끊는다 소켓 연결 말소 시점은 한쪽이 데이터 보내기를 완료했을때다. 어느 측에서든 먼저 연결을 끊을 수 있도록 프로토콜이 설계 되어 있다. 주로 브라우저에서 요청을 보내고 서버에서 응답을 하면 서버 측에서 먼저 연결 끊기 동작을 실행한다. 메소드를 호출해서 연결끊기 동작에 들어간다. 연결끊기 동작 세부 로직 - 끊는 쪽 (예. 서버) 연결을 끊고자 하는 측이 TCP 헤더를 만들어서 FIN 컨트롤 비트를 1로 설정한다. 이 패킷을 IP 담당에게 요청하여 상대에게 송신한다. 자신의 소켓에 연결 끊기 동작에 들어갔다는 사실을 통지한다. 연결끊기 동작 세부 로직 - 상대 쪽 (예. 브라우저) 프로토콜 …

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH2. TCP/IP의 데이터를 전기 신호로 만들어 보낸다_프로토콜 스택과 LAN 어댑터의 탐험입니다 🙌 🛺 [Story1] 소켓을 작성한다. 1. 프로토콜 스택의 내부 구성 네트워크를 제어하는 다음 두 가지가 필요하다. 소프트웨어 - (OS 내장) 프로토콜 스택 하드웨어 - LAN 어댑터 아래가 네트워크 계층 구조이다. 어플리케이션에서 데이터 송신을 시작한다. 이때 소켓 라이브러리를 사용하여 리졸버로 DNS 서버를 조회하는 등의 동작을 실행한다. OS 내부에 있는 프로토콜 스택이 그 다음 작업을 의뢰받는다. TCP 혹은 UDP로 데이터를 송수신한다. IP 프로토콜로 패킷 송수신 동작을 제어한다. ICMP(패킷운반시 오류 통지, 제어용 메세지) 혹은 ARP(IP에 대응하는 MAC주소 조사)로 동작한다. LAN 드라이버는 LAN 어댑터라는 하드웨어를 제어한다. LAN 어댑터라는 하드웨어가 실제 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 1. 작업큐(Job-Queue) 시스템 웹 서비스와 요청 본래 웹 서비스의 요청은 동기적으로 실행이 되었는데, 데이터가 축적되어 처리가 무거워지면서 작업큐 시스템을 통해서 나중으로 미뤄도 되는 처리를 비동기로 실행하도록 한다. 예) 특정 url을 북마크 할 때 해당 url의 개요를 얻고 키워드를 추출하고, 카테고리를 판정하는 작업들을 비동기로 처리한다. 그렇지 않으면 북마크를 추가할 때마다 긴 시간이 소요된다. 작업큐 시스템 입문 비동화 하는 방법 → 해당 처리를 독립된 스크립트로 어플리케이션 내부에서 호출한다. 이 방법은 대량의 비동기 처리시 그 수만큼의 프로세스를 실행시키므로 성능상 단점이 될 수 있다. 스크립트 시작과 초기화의 오버헤드가 커서 성능이 좋지 않다. 소규모 어플리케이션에서만 진행하는 것이 좋다. 작업큐와 워커를 세트로 작업큐 시스템을 사용하는 것이 일반적이다. 작업큐에 실행하고자 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 규모가 커지면서 트래픽이 커지면 문제가 발생한다. → 라우터의 성능 관점에서는 bps보다 패킷 단위인 pps가 더 중요하다. 사용하고 있는 라우터에서 감당하는 이상의 패킷이 송수신되면 문제가 발생한다. 또한 호스트 수가 500을 넘어가면서 하나의 서브넷을 구성하면 여러 패킷 손실등이 발생하기도 한다. 글로벌 서비스로 확장하면 데이터 센트럴 한군데 두었을 때 latency도 한계에 다다를 수 있다. [강의38] 네트워크 분기점 1Gbps의 한계 - PC 라우터의 한계 1Gbps 는 30만pps → 한계치이다. 이것을 해결하기 위해서는 PC 라우터를 여러 대 병렬화 하던지, 고가의 라우터를 사용해야 한다. 500호스트의 한계 - 1서브넷 ARP 테이블에서의 한계 스위치의 ARP(Address Resolution Protocol table)에서 한계가 있다. ARP는 IP주소와 MAC 주소간의 관계를 나…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 다중화로 어느정도 문제를 해결할 수 있지만 규모가 작으면 다중화를 했을 경우 전체적인 리소스 사용률이 떨어지면서 효율이 떨어진다. 가상화로 전체적인 리소스 사용률을 높일 수 있다. [강의36] 가상화 기술 가상화 기술의 도입 왜 가상화 기술을 사용하나 확장성 → 오버헤드 최소화 비용대비 성능 → 리소스 사용률 향상, 운용의 유연함 고가용성 → 환경 격리 가상화 기술의 효용 IPMI를 대체하는 하이퍼바이저 호스트 OS : 서버에서 최초에 기동하는 OS 하드웨어 간 차이 흡수 → 환경 추상화 준 가상화 사용 리소스 소비 제어 과부하 경고 부하 조정 가상화 서버 구축정책 하드웨어의 이용효율을 높이기 위해 남아있는 리소스를 사용하는 게스트 OS를 투입하는 것이다. 예를 들어 CPU 리소스가 남이있으면 웹 서버, I/O 리소스가 남아있으면 DB 서버, 메모리 용량이 남아있으면 캐시 서버를 투입한다. 리소스 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 가동률을 100%로 끌어올려 시스템이 멈추지 않도록 하는 것 여기서 중요한 것은 SPOF (Single Point of Failure) 단일장애점을 제거하는 것이다. [강의33] 다중성 확보 다중성 확보 - WAS 서버 중요한 것은 여러대의 서버가 있을 때 몇대의 서버가 정지하더라도 서비스가 정상적으로 처리될 수 있는 상태를 만드는 것이다. 로드밸런서에서 failover를 처리할 수 있다. 고장난 서버를 분리시키고 정상적인 서버로 요청을 보내는 것 연결된 서버들에 대한 주기적인 헬스체크 failback 고장난 서버를 복구하고 다시 복귀시키는 것 다중성 확보 - DB 서버 마찬가지로 여러대의 DB 서버가 있을 때 몇대가 고장나더라도 요청을 정상적으로 처리할 수 있어야 한다. Master도 다중화 하면 좋다 → 하지만 어렵다. 책의 예시에서는 멀티 마스터를 사용하고 있다. 양쪽이 서로 slave 관계이…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의31] 계층과 확장성 확장성에 대한 요구 - 서버 1대에서 처리할 수 있는 트래픽 한계 (업데이트가 필요한 정보이다) 이 때 당시에 서버 한대로 처리할 수 있는 트래픽은 월 100만 PV 정도, 최고사양으로 100만 ~200만 까지도 감당할 수 있었다. 수천 ~1만 건/분 정도의 요청을 처리할 수 있는 정도이다. 더 대규모는 서버1대로 동작할 수 없다. 계층별 확장성 WAS는 상태를 가지고 있지 않으므로 단순히 대수를 늘리는 것으로 요청을 확장할 수 있다. 로드밸런서에 새로운 서버를 추가하면 된다. DB는 다른 방법으로 (쓰기, 읽기가 나뉘어져 있으므로) 더 많은 요소들을 고려하면서 확장해야한다. [강의32]부하 파악, 튜닝 부하 파악 - 관리화면 시각화의 중요성 각각의 서버에 관해서 그래프화 하는 것이 중요하다. 부하 측정을 위한 항목 Load Average, 메모리, CPU Load Ave…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의29] 엔터프라이즈 vs. 웹 서비스 엔터프라이즈 vs. 웹 서비스 - 응용범위로 보는 차이 웹 서비스의 특징 - 엔터프라이즈와 비교 트래픽 - 엔터프라이즈에 대규모 트래픽이 일어날 일은 많이 없지만 웹 서비스에서는 대규모 트래픽이 일어나고는 한다. 성장성 - 비즈니스와 연관된 엔터프라이즈는 급격히 성장하지는 않는다. 웹 서비스와 같은 경우는 폭팔적 성장이 가능하다. 신뢰성 - 사람의 목숨이나 돈에 관련된 일이 많기 때문에 높은 신뢰성이 요구된다. 웹 서비스는 인명이나 돈과 깊게 관련 없는 경우가 더 많기 때문에 그정도의 신뢰성이 중요하지는 않다. 트랜잭션 - 신뢰성과 비슷한 맥락의 이야기지만 더 DB에 한정되서 이야기 한다. 엔터프라이즈는 데이터의 정합성이 매우 중요하다. (은행에서 돈 예시) 웹 서비스는 (블로그와 같이) 정합성이 일치하지 않아도 큰 문제가 생기지 않는다. 웹 서비스의 인프…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH1. 웹 브라우저가 메시지를 만든다 입니다 🙌 🛺 [Story3] 전 세계의 DNS 서버가 연대한다. DNS 서버의 기본 동작 DNS 서버는 조회 메세지를 받고 그것에 대해 응답을 한다. 조회 메세지 내용 이름: 서버나 메일 배송 목적지 (@뒤 호스트) ex. www.example.com 클래스: 이전에 필요했으나 요즘에는 항상 인터넷을 나타내는 클래스 ‘IN’으로 표기됨 타입: 다음마다 응답 형태가 바뀐다. A: 이름에 지원되는 IP 주소 MX: 메일 배송 목적지 DNS 서버에서 위 3가지가 일치하는 응답 정보를 찾아서 등록된 IP 주소 등을 회신한다. MX, 메일 서버에 대한 응답인 경우 메일 서버의 우선순위 + 메일 서버의 이름, 해당 메일 서버의 IP 주소를 함께 회신한다. DNS 서버에서 취급하는 타입은 여러개가 있다. PTR, NS, SOA, CNAME 등등 도메인의 계층 정말 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의19] 알고리즘과 평가 데이터 규모와 계산량 차이 데이터가 클 수록 알고리즘이나 데이터 구조 선택이 속도에 영향을 미친다. ex. 선형탐색 vs. 이분탐색 알고리즘이란? 알고리즘은 값의 집합을 입력, 다른 값의 집합을 출력으로 하고 명확하게 정의된 계산절차이다. 유한한 자원인 CPU나 메모리를 어떻게 활용하여 문제를 해결해야 할까? 적절한 데이터구조를 사용하여 알고리즘을 구현해야지 효과가 있다. 결국 측정이 중요하다 !! 알고리즘을 활용한 데이터 처리 과도한 알고리즘이 항상 더 효율이 좋은 것은 아니다. 때로는 간단한 알고리즘이 더 시간을 줄여줄 때가 있다. 과도한 알고리즘의 경우 전처리에 많은 시간이 소요되기도 한다. 항상 측정이 중요하다. 단순이 데이터가 ‘적다’, ‘많다’ 라는 것으로 판단하는 것은 좋지 않다. 데이터 압축과 속도 - 전체적인 처리량을 높이기 위한 사고방식 압축이라는 것이…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 이전에는 미들웨어를 살펴보면서 운용에 대한 생각을 했다면 이제는 개발에 대한 생각을 하면서 어플리케이션 개발시 고려해야할 급소들에 대해서 살펴보도록 한다. 대량의 데이터에 액세스 (그리고 이러한 데이터들을 특정 부분을 절단하기 어려운 경우가 대부분이다)를 할 대 RDBMS, MySQL등에서 처리할 수 없는 규모의 데이터를 계산하고자 할 경우를 살펴본다. [강의14] 용도특화형 인덱싱 인덱스와 시스템 구성 - RDBMS가 한계를 보일 때 지나치게 많은 데이터를 다루는 경우 (검색 등) RDBMS로는 한계가 있다. 그렇다면 해결 방법은 ? 배치 처리로 RDBMS에서 대량의 데이터를 추출 별도의 인덱스 서버와 같은 것에 데이터를 보관 웹 어플리케이션에서 RPC(Remote Procedure Call)등으로 액세스 하도록 처리 RPC, 웹 API DB 가 정기적으로 데이터를 추출해서 인덱스 서버로 넘긴다.…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 검색엔진의 노하우를 알아두면 용도특화형 인덱스를 직접 만들어서 대규모 데이터에 대한 문제를 해결할 수 있다. [강의24] 전문 검색기술의 응용범위 키워드 역 인덱스 전문 검색의 종류 grep 형 전부 읽어가면서 검색하는 것 시간이 오래 걸린다. 즉시성이 좋다 → 문서가 갱신되더라도 바로 검색할 수 있으며 검색누락이 없다. 병렬화 하기가 간단하다 → 분할해서 검색하기 편리하다 suffix 형 검색 가능한 형태로 검색 대상 전문을 보유한다. 구현이 어렵다. 역 인덱스형 단어와 문서를 연관짓는 것 문서와 별도로 역 인덱스를 만들어야 한다. → 즉 전처리가 필요하다. 즉시성이 떨어진다. 인덱스를 압축함으로 컴팩트하게 가져갈 수 있다. 대규모화 하기 가 쉽다. [강의26]검색엔진의 내부구조 역 인덱스의 구조 - Dictionary + Postings 어떠한 단어 (dictionary 형태)에서 연결되어 있는…

INTRO 현재 진행중인 프로젝트에서 DB Replication을 적용했었다. Replication 알아보기 DB replication 적용 이후 Master DB를 업그레이드 해야하는 상황에서 replicas와의 연동에 문제가 생긴적이 있었다. 이때 Master와 replicas 간의 데이터 연동 방법을 이해하고 해결한 (매우 간단한) 방법을 기록한다. Master DB와 replicas 동기화 Master DB에 데이터를 쓰기 위해서는 replicas에서 master db 의 데이터와 연결되어 있어야 한다. 그러기 위해서 replication을 설정할 때 라는 명령어를 통해서 나온 값과 값을 replica db 설정시 적용해 주었다. 여기서 File은 master db의 binary 로그 파일이고 Position 값은 해당 파일의 현재 위치이다. 위 log 파일에는 어떤 내용이 담겨 있을까? The MariaDB binary log is a series of files th…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH1. 웹 브라우저가 메시지를 만든다 입니다 🙌 💡 개요 HTTP 리퀘스트 메세지를 작성한다. URL을 해독하는 곳에서 브라우저의 동작이 시작된다. 이 URL의 의미에 따라서 요청 메세지를 작성하고 요청 내용을 만든다. 이때 HTTP 라는 프로토콜이 사용된다. 웹 서버의 IP 주소를 DNS 서버에 조회 OS에 의뢰해서 요청 메세지를 송신할 때 송신대상의 IP주소를 알아야한다. URL의 웹 도메인명으로 DNS 서버를 조회해서 IP 주소를 조사한다. 전세계 DNS 서버 연대 다수의 DNS 서버가 연대하여 IP 주소를 조사한다. 프로토콜 스택에 메시지 송신을 의뢰 OS에 메세지를 송신하는 동작을 의뢰한다. OS에서 제공하는 규칙에 따라서 의뢰를 해야한다. 해당 프로그램을 직접 구현하는 것이 아니더라도 규칙의 큰 흐름을 알는 것이 중요하다. 🛺 [STORY1] HTTP 리퀘스트 메세지를 작성한다 U…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의8] OS 캐시 구조 OS의 캐시 구조를 알고 애플리케이션 작성하기 - 페이지 캐시 OS는 메모리를 이용해서 캐시 구조를 갖추고 디스크 액세스를 줄인다. Linux(x86) 페이징 구조 OS는 가장 메모리 구조를 가지고 있는데 논리적인 선형 어드레스를 물리적인 어드레스로 변환한다. 가상 메모리 구조 기본적인 OS 구조를 보면 OS에서 관리하고 있는 메모리 구조 있고, OS가 있으며 OS에서 돌아가는 프로세스가 존재한다. 프로세스에서 메모리가 필요한 경우 메모리에 직접 접근해서 주소를 가져오는 것이 아니라, OS를 통해서 비어있는 주소와 다른 주소를 반환한다. 왜 가상 주소를 반환할까? 개별 프로세스가 실제로 메모리의 어느 부분을 사용하는지 스스로 알고 있을 필요가 없고, 특정 번지에서 통일해서 시작하는 것으로 다루면 더 쉽기 때문이다. 예) 유닉스에서 공유 라이브러리는 프로세스 내에서 지정된 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 이번장은 레이어를 DB로 옮겨서 DB의 스케일아웃 전략에 대해서 살펴본다. [강의11] 인덱스 올바르게 운용하기 분산을 고려한 MySQL 운용, 세 가지 포인트 OS 캐시 활용 인덱스를 적절하게 설정 확장을 전제로 한 설계 OS 캐시 활용 전체 데이터 크기가 물리 메모리보다 가능한 적도록 유지한다. 상황: 대규모 서비스일 경우 (3억건의 데이터), 테이블에 칼럼을 한 개 (약 8바이트)를 추가하더라도 3GB 가 추가된다. → 스키마도 신경써서 설계해야한다. 따라서 테이블의 레코드를 컴팩트하게 설계해야한다. (int형 32비트, 문자열 8비트 같은 수치에 대한 감각 필요) DB 테이블의 데이터를 정규화하는 것은 ? 예를 들어서 필수적으로 필요한 데이터만 테이블에 남기고, flag로 사용되는 데이터들을 테이블 분리하여 필요할 때만 사용할 수도 있다. 대규모 데이터인 경우 이것만 분리를 하더라도 엄청난 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의4] 어느정도가 대규모 데이터인가 ? 이때 당시의 수치임을 감안하고 보자 !! 하테나의 경우 레코드 건수 1500만, 5000만 entry 테이블이 3기가, bookmark 데이블이 5.5기가 등등 html 텍스트 데이터 압축 후 200 기가 이정도가 중규모 ~ 대규모 디비 규모가 기가바이트면 굉장히 많은 것이다. 인덱스 사용 안했을 때 1건 검색시 200초 소요 [강의5] 대규모 데이터는 어떤 점이 어려운가 한마디로 말하면 ‘메모리 내에서 계산할 수 없다’ 데이터가 너무 많으면 메모리 내에서 계산할 수 없으므로 디스크를 검색하면 읽어야하는데 디스크를 읽는 것은 계산량도 지나치게 많아지고 시간도 많이 소요된다. (I/O 시간) 메모리와 디스크 속도 차이는 10만 ~ 100만배 정도 디스크는 왜 늦나 디스크의 경우 헤드의 이동과 원반의 회전이라는 두 가지 물리적인 이동이 수반되며 속도가 저하된다…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 어느 정도가 대규모 인가 ? 이것은 이 책이 쓰여졌을 당시의 상황이다. 전혀 감이 없으니 이때 당시의 대규모 정도를 숫자로 파악해보자. 등록 사용자 100만 명 이상, 1500만 UU 서버 500대 이상 피크시 회선 트래픽 430Mbps [강의1] 소규모 서비스와 대규모 서비스의 차이 확장성 확보, 부하분산 필요 1대의 서버로 처리 할 수 없는 부하를 어떻게 처리할 것인가 ? 스케일 아웃 → 서버 대수를 늘림으로 스스템 처리능력을 높임 스케일 업 → 하드웨어 성능을 높여 처리 능력을 끌어올림 여러대의 서버를 사용했을 때 파생되는 문제 데이터 동기화, 네트워크 통신 지연시간, 다중성 확보 특정 서버가 고장이 나도 서비스를 계속 할 수 있어야 함 스케일아웃은 서버의 고장율이 올라가고 하나가 고장났다고 전체가 정지해버릴 순 없다. 시스템이 고장나면 다른 시스템이 자동으로 처리를 인계받는 시스템 설계가 …

[INTRO] 자바가 업데이트 되면서 메소드를 일급시민으로 취급할 수 있게 되었다. 이로 인해 동작 파라미터를 통해서 어떠한 동작을 인자로 넘길 수 있다. 메소드를 일급 시민으로 취급하면서 함수형 인터페이스 등의 개념이 등장한다. 코드의 명확성을 증진시키기 위해 익명 클래스, 람다 함수, 메서드 참조 등등의 개념이 활용된다. 동작 파라미터를 활용한 예시로 콜백 함수를 들여다보자. [왜 동작 파라미터인가?] 코딩을 할 때 가장 중요한 요소 중 하나는 변화하는 요구사항에 대응하는 것이다. 동작 파라미터화는 나중에 실행할 코드 블록을 인수로 넘겨서 행동을 결정하는 것이다. 나중에 실행되도록 넘기는 콜백 함수와 같은 동일하게 작용한다. (내재된 개념이다) 이해를 돕기 위해 모던 자바 인 액션 에 나온 예제를 살펴보자. 상황1: 사과를 색으로 필터링 하는 요구사항을 구현한다. 상황2: 사과를 무게로 필터링하는 요구사항을 구현한다. 위 두 코드가 상당히 유사하다. (실제로 작성할 때도 복붙하…

INTRO DB Replication을 MySQL 공식 홈페이지에서 찾아보면 다음과 같이 말한다. Replication enables data from one MySQL databse server (known as a source) to be copied to one or more MySQL database servers (know as replicas) 출처 : 링크 즉, 하나의 데이터베이스(master/source)에서 다른 하나 또는 그 이상의 데이터베이스(slaves/replicas)로 데이터를 복제하여 저장하는 것이다. Replication은 비동기로 동작한다. 따라서 replicas가 master에 지속적으로 연결되어는 동기식으로 동작하지 않는다. 설정에 따라서 여러 데이터베이스, 선택된 데이터베이스, 선택된 테이블에만 replication을 적용할 수도 있다. MySQL replication 장점 공식 홈페이지에 나와있는 장점 4가지는 다음과 같다. Scale-out …

INTRO HTTP는 Stateless 무상태성을 가지고 있다. 따라서 데이터를 상태로 저장하지 않는다. HTTP가 무성태성이기 때문에 클라이언트에 대한 데이터를 유지하고 싶을 때는 쿠키 또는 세션을 이용한다. (이전에 요청을 보낸 동일한 사용자임을 확인하고 싶은 경우 등등) 쿠키는 클라이언트가 정보를 가지고 브라우저에서 저장 및 관리한다. 세션은 서버가 데이터를 가지고 저장 및 관리한다. Cookie 쿠키는 클라이언트가 정보를 가지고 브라우저에서 해당 정보를 저장한다. 따라서 요청을 보낼 때마다 브라우저에서 저장된 쿠키 데이터를 HTTP 헤더에 추가하여 서버에 보낼 수 있다. HTTP 메세지 자체는 무상태성이기 때문에 매번 쿠키값을 보내주어야 한다. 쿠키에 저장되는 값의 형태는 text 이다. 쿠키의 단점 클라이언트가 관리하는 것이기 때문에 데이터가 쉽게 훼손 될 수 있다. 실제로 크롬 브라우저에서 개발자 도구 -> Application 탭에 가면 쿠키 데이터를 저장하는 저장소를…

1. INTRO 많은 어플리케이션에서 소셜 로그인을 지원하는데, 이때 사용되는 것이 OAuth 2.0 이다. 간단하게 이야기하면 OAuth 2.0 이란 사용자의 정보에 대한 권한을 부여하는 의 일종이다. (정의) 제 3의 앱이 자원의 소유자인 서비스 이용자를 대신하여 서비스를 요청할 수 있도록 자원 접근 권한을 위임하는 방법 출처: 금융보안원 “OAuth 2.0 개요 및 보안 고려사항” 보안연구부-2015-030 즉, 정보 소유자 (서비스 이용자)를 대신하여 앱이 다른 서비스에 등록되어 있는 자원에 대한 접근을 요청하는 권한을 위임한다. 아래 글은 링크 원문을 번역하고 일부 요약한 것이다. 2. OAuth 주요 개념 리소스 소유자 (Resource Owner) - 어플리케이션이 인가 요청을 하는 정보의 소유자이다. 즉, 그 정보를 소유하고 있는 ‘사용자’를 말한다. 클라이언트 (Client) - 리소스 소유자의 정보를 요청하는 어플리케이션이다. 리소스 서버 (Resource Se…

Intro 이번에 프로젝트를 진행하면서 보안상의 이유로 직접 S3 서버에 접근할 수 없었기 때문에 AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 이미지 등의 리소스에 접근해야 했다. (CDN서버의 본래 목적과는 다소 다른 이유로 사용했다.) CDN은 어떤 기술이며, 장점이 무엇이고, 어떻게 동작하는지에 대해서 알아본다. CDN을 퉁해 누릴 수 있는 보안적인 이점은 무엇이며, 프로젝트를 진행하면서 CloudFront를 어떻게 활용했는지에 대해서 작성한다. CDN이란 무엇인가? CDN은 Content Delivery Network의 약자이다. 직역하자면 컨텐츠를 전달해주는 네트워크이다. CDN 컨텐츠를 전송하는 물리적인 서버가 지리적으로 여러곳에 상주하며 유저와 가까이 위치한 서버에서 요청한 컨텐츠를 고속으로 제공해준다. CDN이 제공하는 컨텐츠는 , 파일, , 이미지, 동영상 등의 대부분의 인터넷 콘텐츠이다. CDN 서비스에 대해서 설명하는 예시에 항상 등장하는 …

INTRO JPA에서는 데이터와 객체지향으로 설계 사이의 모순을 해소하기 위해서 나온 기술이다. 많은 객체들은 내부에 Collection 형태로 다른 객체에 대한 참조가 가능하게 설계된다. 예) 객체 내부에 에 속해있는 와 팀에 할당된 가 존재한다. 이때 상위 객체를 select 하면서 하위 객체를 가져오는 경우 다음 두가지 fetch 타입에 각각 다음과 같은 문제가 있다. 일 경우 : 이 발생 일 경우 : 문제 발생 상위 엔티티에서 다수의 collection 형태의 연관엔티티를 가지고 있을 때 여러 상황 및 문제와 해결 방법에 대해서 공부해본다. Entity 상황 과 가 1:N 연관관계 - , 과 가 1:N 연관관계 - , 참고 : 우선 모든 연관관계는 로 적용하고 테스트 상황에 따라 로 변경 엔티티 엔티티 엔티티 JPA에서 collection fetch join Team에 대한 모든 정보가 필요한 경우 Team을 가져오면서 Members와 Lockers 정보도 모…

INTRO JPA 에서는 데이터베이스에서 연관객체 탐색을 효율적으로 하기 위해서 지연로딩 전략을 사용한다. 지연로딩의 핵심은 연관관계에 있는 Entity가 실제로 사용되기 이전까지 DB에 실제로 참조하지 않고 프록시 객체로 대체하는 것이다. JPA의 프록시 객체는 유용하지만 내부 동작방식에 대해서 제대로 알고있지 않으면 찾기 어려운 버그를 만날 수도 있다. 다음은 JPA proxy 관련해서 프로젝트 진행시 만난 버그에 대한 내용이다. 문제 상황 Entity 구조 참고: 설명과 관련된 부분만 남기고 다른 로직 및 어노테이션은 대부분 생략했다. - 게시물 엔티티 와 - Post 엔티티 하위의 Embedded 게시물 Like collection 포장객체 참고: 설명하고자 하는 부분과 깊게 연관된 핵심 Entity는 아니지만 상황 설명을 위해 간단히 프로퍼티만 소개한다. - 어플리케이션 사용자 (게시물 좋아요, 유저간 팔로우 팔로잉 등의 행위를 함) 와 - 해당 의 팔로워리스트…

INTRO JPA는 DB의 데이터와 객체간의 모순을 해결하기 위해서 나온 것이다. 객체는 객체 그래프로 탐색이 가능하지만 데이터베이스에 저장된 데이터는 객체를 탐색하듯이 탐색하기가 어렵다. 따라서 데이터베이스에 저장된 데이터들을 가지고 객체 그래프 탐색이 가능하기 위해서 프록시 라는 기술이 나왔다. JPA에서는 연관된 객체를 로딩하는데 지연 로딩과 즉시 로딩이라는 두가지 기법을 사용한다. 여기서 지연 로딩시 프록시 기술이 사용된다. 기본 예시 Entity Member Team 프록시 지연 로딩을 설정된 연관 객체를 가져올 때 프록시 객체를 가져온다. 를 사용하면 실제 객체를 가져오고, 를 사용하면 프록시 객체를 가져온다. 프록시 객체를 가져온다는 것은 query는 실행되지 않는 것이다. 특정 객체에 대해 를 하면 연관된 객체에 대해서는 설정되어 있는 종류에 따라 즉시로딩 혹은 지연로딩한다. 실제 Entity 조회 - 위 테스트를 실행하면 다음과 같은 select 쿼리가 실행된다…

자바 I/O 스트림 Stream은 데이터의 연속이다. Sequence of Data 다르게 말하면 Stream 이란 한쪽으로 흐르는 통로같은 것이다. 자바에서 Stream이란 한쪽 source에서 destination으로 흐르는 데이터를 위한 단방향 통로이다. 자바에서는 여러 매체를 읽거나 쓸 수 있고 각자를 위한 I/O Stream이 구현되어 있다. (disk files, devices, programs, memory arrays) Stream은 단방향 통신이기때문에 들어오는 데이터, 나가는 데이터에 따로 InputStream, OutputStream이 있는 것이다. I/O 스트림은 여러가지 종류의 데이터들을 처리할 수 있다: 바이트, primitive data type, characters, objects Stream은 단순히 데이터를 전달하는 역할만 하기도하고, 몇몇 stream은 데이터를 조작하고 편리하게 변환하는 역할을 수행하기도 한다. 모든 Stream은 사용 후 반드시…

Intro 프로젝트를 진행하다 보면 상황에 따라 각기 다른 운영환경을 설정해야할때가 있다. 그때마다 properties 설정 파일에 가서 설정되어있는 운영 환경을 바꾸고 돌리기는 어렵다. 이때 각기 다른 를 적용해서 상황에 따라 적합한 설정을 따르도록 할 수 있다. yml 파일로 설정 나누기 - 간단하게 또는 를 통해서 profile 설정을 나눌 수 있다. 각각 원하는 환경에 대한 설정정보를 , 에 기재한 후 또는 로 지정한다. 여러 profile 환경으로 나눠져 있을 경우 어떤 profile을 기본적으로 실행할 것인지 에 지정해 주어야 한다. 나누어진 profile을 적용하기 위해서는 로 적용하고자하는 프로필을 지정하여 실행하거나 어노테이션을 활용할 수 있다. 사용 예시 본인은 프로젝트 진행 시 다음과 같이 local, prod, test로 환경을 나누었다. application-local.yml application-prod.yml application-test.yml …

Intro 스프링부트 프로젝트를 진행하다보면 웹 mvc에 대한 테스트를 진행해야할 때가 있다. 때로는 각 layer에 대한 슬라이스 테스트를 작성하거나, 일부분에 대한 통합 테스트만을 진행할 때 Mock 테스트를 해야할 때도 있다. 테스트 관련 annotation에 대해서 정리하고 각 annotation의 차이 및 언제 무엇을 사용하면 좋을지 정리해본다. 어노테이션은 을 찾아 해당 configuration에 맞추어 실제 Spring web context를 실행햔다. Spring context의 설정으로 그대로 적용해서 테스트를 진행해야 할 경우에 해당 어노테이션을 붙여서 테스트를 하는 것이 좋다. 하지만 전체 컨텍스트를 로드하는 만큼 굉장히 오랜 시간이 걸린다. 실제로 어노테이션이 붙은 테스트를 돌려본다면 다음과 같은 스프링 컨텍스트르 로딩하는 긴 로그가 찍히는 것을 확인할 수 있다. 위 어노테이션은 다음과 같이 를 주입받아서 톰캣 서버를 띄우지 않은 상태로 API 요청 …

LazyInitialization 에러 발생 이유 Lazy Loading을 하려고 하는데 세션이 사라져서 프록시 초기화가 불가능해 지연로딩을 못하는 경우에 발생하는 에러 가장 단순한 방법으로는 을 로 설정해서 일괄적으로 부모 호출시 자식이 모두 즉시로딩으로 초기화되도록 하면 되지만, 비니지스적인 이유가 아닌 을 피하기 위해 로 설정하는 것은 좋지 않다. 위 에러는 Lazy Loading을 하는 시점까지 session을 유지시켜주는 것이 핵심이며 주로 추가로 해당 문제는 해결된다. 서비스 외부에서 LazyLoading Collection 호출 시 서비스에서 LazyLoading을 하고 싶다면 을 붙여서 해결할 수 있지만 간혹 서비스 클래스 밖에서 지연로딩 지정되어 있는 컬렉션을 조회해야할 때가 있다. 그럴 때 에러를 피할 수 있는 방법은 두가지이다. 1. 를 사용해 서비스 내에서 조회 만일 서비스가 아닌 다른 클래스 내에서 JPA 조회를 하고 싶다면 세션이 유지되지 않는다. …

Intro 함수는 시스템의 상태를 바꾸는지에 따라서 크게 두 가지로 나뉜다. 1) Command 2) Query. 이 두 가지 분류법에 대해서 하나의 함수가 두 가지 경우를 모두 담당하는 것은 좋지 않다. Command vs. Query Query 주어진 쿼리에 대한 결과값을 반환하고 시스템의 상태를 변화시키지는 않는다. 다른 값을 바꾸지 않고 오직 질문에만 대답한다. 부작용에서 자유롭다. (read-only) Command 값을 반환하지 않아도 시스템의 상태를 변화시킨다. (영구적) 부작용이 생길 여기자 있다. (mutator, modifier) 이렇게 함수를 두 가지로 나누는 것은 유용하다. 현재 사용하는 함수가 상태를 바꾸지 않는 query 라면 신뢰를 가지고 사용할 수 있다. 하지만 상태를 바꾸는 command라면 함수간 순서에 주의를 기울이고 부작용이 생길 여지를 인지하고 있어야 한다. CQS - Command Query Separation Betrand Meyer라는 프…

동시성 문제 발생 가능 상황 두개의 트랜잭션이 모두 읽는 연산을 하는 경우 문제가 되지 않는다. 하나의 트랜잭션은 read, 하나는 write인 경우 (Isolation으로 해결) Dirty Read 상황: 트랜잭션1이 write 할 때 트랜잭션2가 update된 데이터를 읽었지만 트랜잭션1이 rollback 되었을 때 발생 문제: 트랜잭션2가 무효된 데이터를 읽었음 Non-repeatable Read 상황: 트랜잭션1이 데이터를 read하고, 트랜잭션2가 데이터를 write 한 후, 트랜잭션1이 다시 동일한 데이터를 read 할 경우에 발생 문제: 트랜잭션이 1이 동일한 read를 했음에도 불구하고 바뀐 데이터를 읽음 Phantom Read 상황: 트랜잭션1이 데이터(범위)를 read하고, 트랜잭션 2가 데이터를 추가(insert) 했는데, 트랜잭션1이 다시 데이터를 read한 경우 문제: 동일한 read를 실행하였는데, 이전에 없었던 값이 추가됨 두개의 트랜잭션이 모…

다음 글은 [링크](Understanding Spring Web Application Architecture: The Classic Way)에 기술되어 있는 스프링 웹 어플리케이션 구조에 대한 글을 번역 한 내용이다. 좋은 architecture를 위한 두 기둥 The SoC(Separation of Concerns) 원칙 A design principle for separating a computer program into distinct sections, which each section addresses a separate concern. 출처 SoC에서 신경써야 할 부분은 두가지이다. 고려해야 할 concerns가 무엇인지 어디서 해당 concern을 다루고 싶은지 SoC를 준수하게 된다면 각각의 layer와 해당 layer의 책임에 대해서 자연스럽게 정의할 수 있도록 도와준다. The KISS(Keep It Simple Stupid) 원칙 Most systems work…

INTRO 는 Spring framework에서 제공하는 인터페이스로 request에서 메소드의 parameters를 해당하는 인자값으로 변환 혹은 바인딩 하는 resolver이다. 인터페이스 내용 에는 두가지 메소드가 있다. 첫번째, Parameter가 해당 resolver를 지원하는 여부 확인 [참고] 아래 설명은 가 붙은 인자의 경우를 보는 것이므로 그 구현체가 의 예시로 설명한 것이다. Parameter가 있는 수만큼 → 안에서 for문을 돌면서 해당 parameter에 대한 argument resolve를 한다. 이때 resolve를 하기 위해서 현재 클래스가 가지고 있는 가 해당 parameter 지원 하는지 여부를 확인한다. → 확인하는 로직은 안에 있는 resolver들의 배열을 돌면서(한번 찾으면 캐싱함) 해당 parameter를 지원하는 resolver를 찾아서 반환하고, null인지 여부를 체크해 boolean을 반환한다. 이때 메소드가 수행된다.…

개요 Handler interceptors는 어떤 요청들에 대한 특정 기능을 적용하고 싶을 때 사용이 되는데, 특히 어떤 조건 및 원칙들을 검증하는데 많이 사용된다. Interceptor 구성 Interceptor를 구현하기 위해서는 HandlerInterceptor를 구현해야 한다. 해당 인터페이스에는 interceptor가 실행되는 3가지 경우에 대한 메소드가 정의되어 있다. handler가 실행되기 이전 handler가 실행된 이후 전체 요청 처리가 모두 수행된 이후 이것들 중 handler 실행 이전에 수행되는 메소드인 은 boolean 값을 반환한다. 과 은 void를 반환한다. 위 세가지 메소드 모두 공통된 인자로 Servlet에 의해서 생성된 , , (Object 타입)을 받는다. 따라서 void 반환타입인 경우 HttpServletResponse에 후처리를 할 수 있다. (의 경우에는 를 은 을 속성으로 받는다) preHandle() 동작원리 은 와 를 execu…

Intro 암호화(encryption)에는 3가지 기술이 있다. Symmetric encryption - 대칭키 Asymmestric encryption - 비대칭키 Hash functions(keyless) - 해싱 여기서는 대칭키, 비대칭키에 대해서만 다룰 것인데 둘다 각각의 장단점이 있다. 대칭키와 비대칭키의 간단한 차이점 우선 모두 key를 사용해서 데이터를 encrypt/decrypt 한다. 대칭키의 경우 동일한 key를 가지고 암호화/복호화를 하기 때문에 사용하기가 쉽다. 비대칭키의 경우 public key를 사용해서 데이터를 암호화하고, private key를 사용해서 복호화한다. Symmetric encryption 대칭키? 대칭키를 사용하면 데이터의 암호화/복호화 모두 하나의 key를 사용한다. 그리고 해당 키를 수령인과 공유한다. (수령인이 암호화된 데이터를 받았을 때 복호화를 위해서 필요) 대칭키 장단점 장점 세팅이 쉽고 간단하다. (jiffy 순간적으로 처…

들어가기 전에 암호화(Encryption)과 해싱은 다른 개념 암호화 - 양방향이므로 복호화가 가능 해싱 - 단방향이므로 복호화가 불가능 단방향 해시 함수 (One-Way Hash Function) 기본적으로 패스워드 등의 보안의 문제가 걸린 정보를 DB에 저장할 때 평문으로 저장하지 않고 해싱한 값을 저장한다. (평문으로 저장할 경우 DB가 해킹되었을 때 심각한 문제가 발생한다) 단방향 해시 함수를 사용해서 원본 내용을 완전히 새로운 내용으로 다이제스트(digest)로 매핑한다. 이때 매핑하는 것을 해시라고 한다. 이것은 단방향이므로 복호화할 수 없다. 해시 함수 종류 SHA MD HAS WHIRLPOOL 한계점 Rainbow Table 동일한 데이터를 동일한 해시 함수로 연산한 다이제스트는 동일한 값을 가진다. 따라서 여러 값들에 대한 다이제스트를 모아놓은 Rainbow Table이라는 것이 존재하고 이것을 통해서 원본 데이터를 유추할 수 있다. Brute-force 해싱 …

를 통해서 어플리케이션 전역적으로 exception을 핸들링 할 수 있다. 다르게 표현하면 메서드에서 던져지는 exceptions들의 interceptor라고 할 수 있다. (shared across multiple @Controller classes) 주로 에서 전역적으로 처리하고 싶은 어노테이션은 , , 등이 있다. 클래스가 어노테이션에서 전역적인 exception handling 을 구현할 수 있도록 하는 base class이다. 해당 클래스에서 Spring MVC 내부에서 발생한 예외들을 처리할 수 있는 메서드들을 제공한다. (는 를 반환하는 반면 는 를 반환한다) 여러 @ControllerAdvice 간의 우선순위 @ControllerAdvice 클래스들은 Bean으로 등록이 되도록 하는데, 해당 빈들은 인터페이스를 구현하여 orderable 한 속성을 부여하거나, / 를 사용해서 우선순위를 부여할 수 있다. (여기서 semantic이 / 에 우선순위를 가진다…

Spring Boot Spring boot 자체에서 핸들링 되지 않은 error 에 대한 대비책을 마련해 두었다. 먼저, Spring boot 자체에서 에 대한 매핑을 찾아서 해당 URL에 대해서 동일한 이름을 가진 뷰를 매핑 한다. 해당 뷰는 을 반환한다. (해당 뷰는 Thymeleaf template인데, 만일 JSP를 사용한다면 를 반환하도록 에서 변경할 수 있다) 실질적인 매핑은 ViewResolver에서 담당한다. 만일 에 대해 그 어떠한 view-resolver도 매핑이 되어 있지 않다면 spring boot는 내부적으로 가지고 있는 대체 에러 페이지인 “Whitelabel Error Page”를 가지고 있다. 이때 만일 RESTful request에 대한 응답이라면 Spring boot는 자체적인 JSON 형태로 “Whitelabel Error Page”의 응답을 받은 error 정보를 반환한다. Spring boot는 컨테이너에 대한 디폴트 error-page…

@RequestBody request body를 method argument로 바꿀 때 를 사용한다. 는 두가지를 담당한다. 첫번째는 Http request message를 객체로 변환하는 것, 두번째는 객체를 Http response body로 변환하는 작업이다. 동작원리 에 의해서 호출되는 handler의 method parameters은 스프링의 에 의해 생성이 되고, handler의 return value는 에 의해서 처리된다. 와 를 다루는 구현체는 이다. DispatcherServlet의 handle에서부터 Argument resolve 하는 과정 → → → → → → → (Interface) → (Imp) 내부에서 HttpMessageConverter를 사용해서 변환시키는 과정 → (extends AbstractMessageConverterMethodArgumentResolver) → (Imp HandlerMethodArgumentResolver) …

JWT(JSON Web Token) 배경 이전에 인증 절차를 거치려면 사용자의 해싱값을 DB에 저장하고 매번 요청이 있을 때마다 해당 해싱값을 검증해야한다. 검증시 DB에 접근하는 쿼리가 실행되어야하는데 성능면에서 좋지 않다. 따라서 JWT가 등장하게 되고 위와 같은 절차를 거치지만 DB 접근 쿼리가 필요하지 않게 된다. JWT 정의: A string that is sent in the HTTP request (from client or server) to validate the authenticity of the client. It is saved on the client-side only. 출처 JWT 특징 compact self-contained digitally signed : it is signed using a secret key(HMAC algorithm) or public/private key pair using (RSA or ECDSA) sgined 토큰 이라면 c…

간단한 JavaBean 규약에 대해서 알고 넘어가기 JavaBean 자바빈 규약을 따르는 Java Class를 말한다. JavaBean 규약 defulat 패키지가 아닌 패키지 하위에 있는 클래스 기본 생성자가 존재 (no-arg constructor) Property는 모두 private으로 선언 Getter/setter를 통해서 properties를 조작 을 implement 하여 직렬화 가능 번외 : Serialization & Deserialization Serialization : converting state of an object into a byte stream Deserialization: reverse process of serialization 해당 객체에 영속성을 부여하기 위해서 사용되는 매커니즘이다. Java 객체를 serialize 하게 하기 위해서는 인터페이스를 구현하도록 한다. 해당 인터페이스는 멤버변수나 메소드가 존재하지 않는 marker inte…

Servlet 개념 및 구조 Servlet은 웹 서버를 구현한 자바의 프로그램이며 interface이다. 서블릿이 하는 일은 다음과 같다. Servlet은 웹 클라이언트로부터 요청을 받아서 응답을 반환한다. Servlet 인터페이스는 servlet을 초기화하고, 서비스를 요청하고, servlet을 서버에서 제거하는 메소드를 제공한다. (이걸 life-cycle 메소드라고 말한다) 메소드를 통해서 서블릿이 구축된다. 클라이언트에서 호출된 메소드가 수행된다. 수행된 서블릿이 에서 제거되고 메소드를 통해서 소멸된다. 추가로 Servlet 초기세팅 정보를 에 담아서 반환하는 와, Servlet 정보를 반환하는 메소드도 존재한다. HttpServlet 구조 을 확장하고 인터페이스를 구현한다. 웹 환경에 최적화되어 있어서 HTTP 메소드를 지원한다. 즉, HttpServlet 에서는 를 override 할 이유가 거의 없다. 왜냐햐면 이미 정의되어 있는 Http 요청들을 수행하…

스프링 프레임워크에서 사용되는 Bean scope에 6가지 종류가 있다. 일반적으로 많이 쓰이는 scope은 싱글톤이다. Singleton scope 스프링 빈이 singleton scope을 가지고 있다면, 컨테이너가 빈의 단 하나의 인스턴스를 해당 빈이 필요할 때마다 캐싱된 빈을 리턴한다. 빈 객체를 수정하면 해당 빈을 참조하고 있는 모든 곳에 반영이 된다. 싱글톤 스콥은 스프링의 기본값이다. Prototype scope 프로토타입 스콥은 빈 요청이 있을때마다 매번 다른 인스턴스를 컨테이너로부터 반환한다. 설정방법은 다음과 같다. Web Aware Scopes 앞에 두 개의 범위를 제외하고 4개의 범위가 더 존재한다. 하지만 조건이 있는데, web-aware application 맥락에서만 적용이 될 수 있는 범위이다. Request Scope Request scope은 하나의 HTTP request 당 하나의 빈을 생성한다. 이 scope을 사용할 때는 proxyMode 속성…

@Valid - 스프링 부트에서 어노테이션으로 validation을 할 수 있도록 기능을 추가해주는 것. 즉, controller에서 인자를 받을 때 유효성 검사를 할 수 있도록 해주는 것이다. DTO의 필드나, 도메인 객체의 필드 위에 유효성 검사를 하고 싶은 어노테이션을 추가하고, controller의 인자 앞에 @Valid 를 추가해서 붙여준다. java.validation 어노테이션 사용 예시

자바 + 스프링 MVC 프로젝트 배포과정 (별도 인스턴스 활용) 이번에 몇몇 크루들과 미션을 진행하면서 웹을 처음으로 호스팅 해보았다. 웹을 배포 할 때 더욱 편리하다는 DevOps의 꽃 ci/cd를 학습해보기 위해서 6명이 모여서 한번 적용해보았다. 적용하면서 밟은 단계들을 기록해둔다. 아래와 같이 그대로 적용하다가 본 프로젝트에 맞게 어느정도 커스텀하여 다르게 설정한 것도 있다. 특히 버전같은 것들은 좀 outdated 된 정보일 수 있다. 추후에 진행할 팀 프로젝트에 큰 도움이 될 것 같다. docker 설치 EC2에서 Jenkins key 받기 및 적용 Jenkins 포트 번호 변경 젠킨스는 내부적으로 톰캣 서버를 이용하므로 기본포트 8080을 이용한다. 대부분의 스프링 프로젝트도 8080 톰캣 포트를 이용하기 때문에 젠킨스의 포트번호를 변경해야한다. Jenkins 홈 디렉토리 Jenkins 기본 설정파일 & 로그 파일 포트 변경 후 재시작 Jenkins 접속 및 설정 Je…

CI/CD 의 필요성 개발 후 운영을 하기까지 다음 그림의 프로세스가 반복해서 진행된다. 즉, 개발 프로세스(Dev)의 일종으로 개발을 하여 빌드를 하고 운영 프로세스(Ops)의 일종으로 릴리즈, 배포, 모니터링이 반복된다. 점점 이것을 짧은 쥐기로 반복하는 DevOps가 등장하면서 CI/CD가 중요해졌다. CI - Continuous Integration 정의: 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것 어플리케이션 코드에 변경이 생기더라도 정기적인 빌드와 테스트를 통과하여 하나의 레포지토리에 관리가 되는 것 예시: SCM(Source Code Management): 깃헙 레포 하나로 소스코드를 머지하고 충도를 처리하는 과정 테스트 코드를 통해서 유효성을 검증하는 과정 장점: 소스코드를 Ready-to-run 상태로 유지할 수 있다. 이 부분은 혼자 개발할 경우 장점을 느끼기 어렵지만 주로 여러명이서 협업하여 개발을 하기 때문에 중간에 합류한 그 누구도 빌드가…

트랜잭션을 사용하는 이유 트랜잭션을 사용하면 각각의 단위로 나누어져있는 작업의 단위를 하나로 합칠 수 있다. 즉, 일련의 연산들을 하나의 독립된 작업 단위로 보고 하나로 취급하기 위해서 사용하는 것이다. 언제 일련의 연산들을 하나로 봐야 할 때가 생길까? 예를 들어서 돈을 송금하는 시스템이 있다고 가정해보자. 계좌A에서 계좌B로 돈을 송금해야 할 때, 계좌A에 충분한 잔액이 있는 것을 확인하고 돈을 송금하기 위해서 돈을 차감했다. 그리고 계좌B에 입금을 하려고 하는 순간 예외가 발생하면서 입금을 하지 못했다. 그런데 계좌A에서는 여전히 돈이 차감된 상태이다. 중간에 송금하려고 했던 돈이 사라지게 된 것이다. 이때, 위의 과정을 로 관리를 하게 된다면 위의 여러 작업들을 하나의 단위로 보고 중간에 예외가 발생한다면 위에서 실행중이던 작업을 한꺼번에 롤백해준다. 트랜잭션 기본 방법 2개 이상의 쿼리를 하나의 커넥션으로 묶어 DB에 전송하고, 에러가 발생할 경우 자동으로 모든 과정…

제일 핵심이 되는 차이점은 HTTPResponse Body의 생성 방식이다. @Controller 본래 Spring MVC 컨트롤러의 주 역할은 View를 반환하는 것이다. 아래 사진을 보면, 클라이언트가 URL을 통해서 Dispatcher Servlet 에 요청을 보내면 적절한 Handler를 매핍하고 컨트롤러에서 해당 View를 를 통해서 반환한다. 하지만 컨트롤러는 항상 View를 반환하는 것이 아니라 data도 반환해야한다. 이때는 @ResponseBody 어노테이션을 통해서 Json 형태로 클라이언트에 데이터를 반환할 수 있도록 해야 한다. 이때는 View를 반환할 때 사용하는 ViewResolver를 반환하는 것이 아니라 HttpMessageConverter 을 사용해서 데이터를 반환한다. 따라서 Data를 반환하는 응답에 대해서는 를 붙여주어야하는데 매번 그러기가 번거로우니 Controller에 가 자동으로 붙어있는 가 등장하게 된 것이다. @Controller

다음은 우아한테크코스를 시작한지 얼마 되지 않은 시점에 쓴 글 입니다. 진솔한 마음으로 써서 올려봅니다 😶 💭 국제학교 나온 문과생이 개발자를 꿈꾸기까지 “너 컴퓨터 전공이니까 와서 이것 좀 고쳐봐” 컴퓨터 전공으로 전과하고 가장 많은 들은 말이다. 사실 나도 흔히 컴퓨터 공학을 전공하면 컴퓨터를 잘 고칠(?) 거로 생각하는 사람들 중 하나였다. 코딩이 무엇인지도 모르는 사람 말이다. 그리고 대학교 1학년 때 처음 코딩을 접했다. 교양 필수였던 수업을 통해서 말이다. 국제 중고등학교를 나와서 국제 정치학 전공을 선택한 나에게 그렇게 우연히 코딩의 기회가 닿았다. 코딩의 첫인상이다. 누군가 나에게 어떤 종류의 사람들을 좋아하느냐고 물어본다면 단번에 이라고 대답할 것이다. 눈속임으로 알맹이가 없는 것을 있는 것처럼 꾸미는 것보다 담백하게 있으면 있거나 없으면 없다고 말하는 사람이나 글을 좋아한다. 그런 의미에서 코드는 정말 너무나도 정직하다. 있어야 할 것만 딱 있어야지 가장 잘 …

이번에 스프링 체스 자바 웹 어플리케이션을 사용하여 구현하면서 처음에는 모두 으로 데이터를 가져왔었다. 하지만 인자가 너무 많아지는 경우 메서드에 파라미터가 많아지면서 가독성이 안 좋아졌다. 또한 DTO에 해당 데이터를 담아서 서비스 레이어에 전달해야하거나 할 때 일일이 데이터를 DTO에 담아서 가공해야 하는 작업을 해야하기도 했다. 코드를 구현할 때 손가락이 아프다면 수정할 부분을 찾으라고 했었는데 확실히 으로 받는 것은 손가락이 아팠다. 아니나 다를까 리뷰어가 @ModelAttribute를 사용하는 걸 추천했다. 마침 레벨1 제이슨 톡방에서도 @ModelAttribute 에 대한 논의가 활발하길래 공부도 하고 코드에 적용을 하며 배운 것을 기록해본다. @ModelAttribute vs. @RequestBody 간단하게 말하면 다음과 같다. 같은 경우는 parameter 값으로 DTO에 바인딩한다. 따라서 해당 DTO 객체에 메소드가 반드시 있어야 한다. 따라서 타입에 대…

요약하자면 Stream과 Collection의 차이는 다음과 같다. 개념적으로 접근했을 때 Collection의 경우에는 어떠한 데이터를 담는 자료구조의 역할을 주로 하지만, Stream의 경우는 연산과 관련된 것이 주라고 볼 수 있다. Quote Java Collections offer efficient mechanisms to store and process the data by providing data structures like List, Set, and Map. However, the Stream API is useful for performing various operations on the data without the need for intermediate storage. 출처: https://www.baeldung.com/java-return-stream-collection Traversal Collection은 여러번 데이터를 횡단할 수 있지만, Stream은 …

이것은 정답이 아니라 한 블로그에 기술된 하나의 의견이다. 읽어보고 신선한 접근이라고 생각해서 정리해둔다. 링크 데이터베이스에서 boolean 값을 지정해서 저장해야하는 경우들이 있다. , , 등등을 기록해야하는 경우들이다. 이 경우에 boolean으로 저장하지 말고 timestamp로 저장하도록 해보자! 글쓴이의 말을 인용하자면 “단 한번도 후회한적이 없다”. Boolean 값으로 저장할만한 데이터는 언제 해당 데이터가 set 되었는지에 대한 timestamp를 제공함으로 잃는 것이 없다. 아무리 해당 시간 데이터가 필요하지 않더라도 말이다. 이렇게 구현을 하게 된다면 은 로 은 로 간주되어 처리하면 될 것이다. 따라서 자연스럽게 , , 등등으로 변환될 것이다. 의견 글쓴이의 말이 일리가 있다. 큰 구현의 차이나 처리의 차이 없이 동일한 연산을 수행할 수 있고, 더 많은 정보를 제공하는 이점이 있다. 하지만 해당 데이터가 로 지정이 되어 있는 시점이 있다는 것이 해당 …

스프링 강의 중 DAO vs. Repository의 차이점에 대해서 논의하다가 다음과 같은 표현이 나왔다. Repository의 추상 인터페이스는 Domain Layer에 속하며 Domain 객체들을 관리하고 생애주기를 같이한다. 그 구현체인 SimpleJpaRepository는 Infrastructure에 속한다. 추상화된 repository 인터페이스를 사용하면서 추상에 의존하고 구체에 의존하지 않도록 구성(DIP) 하여 유연성 있는 시스템을 구성한다. 여기서 나오는 DIP는 무엇이고 위와 같은 구성이 어떻게 우연성을 제공하는 걸까? DIP 요약 Dependency Inversion Principle의 약자이다. 본래 객체는 상위 계층이 하위 계층에 의존한다. DIP는 그 관계를 역전시켜서 상위 계층이 하위 계층의 구현에서 독립하도록 한다. 그러기 위한 원칙 두가지는 다음과 같다. 상위 모듈과 하위 모듈이 서로 의존하는 것이 아니라 모두 추상화에 의존한다. 추상화가 구현에 의존…

Transaction 이란? 개인이 설정할 수 있는 작업의 최소 단위이다. Transaction을 기준으로 을 할 수도, 을 할 수도 있다. Transaction을 사용할 때 DBMS에서 ACID를 제공받을 수 있다. Atomic(원자성) : 한꺼번에 모두 처리가 되거나, 한꺼번에 모두 처리가 되지 않도록 원자성을 부여한다. 데이터 관련 일부만 처리되었을 때 생길 복잡한 상황과 부작용을 막을 수 있다. Consistency(일치성) : 하나의 데이터가 처리되었을 때 관련된 다른 테이블 혹은 상황에서 일관된 논리가 수행 되도록 하는 것을 보장한다 (ex. A 에서 1000원이 차감되면 B에서 1000원이 증감되어야 하는 상황 등등.) Isolation(독립성) : 데이터가 처리되는 도중 다른 일이 중간에 일어나지 않도록 해당 데이터를 보호하도록 보장. 중간에 다른 일이 끼어들어 부작용이 생기는 것을 방지한다. Durability(영구보존성) : 데이터를 DB에 저장하여 보존하도록 한…

데이터의 흐름 또는 코드가 책임지는 부분의 유사도에 따라서 계층별로 나누어서 대규모 웹 어플리케이션을 구현한다. 이때의 이점은 각 계층이 담당하고 있는 책임을 알 수 있기 때문에 대량의 코드에서도 필요한 부분을 찾아서 수정하기 다소 쉽다. 또한 구조적으로 정리되어 있는 이점이 있다. 웹 어플리케이션을 구현할 때 이러한 계층들에 대한 제대로 된 정의를 가지고 각자가 담당하는 기능을 구현하는 것이 좋다. 함께 일하는 동료 개발자나 이후에 레거시 코드로 받을 다른 개발자들과의 의사소통 비용을 크게 감소하고 쉽게 코드와 구조를 이해할 수 있기 때문이다. 총 5개의 계층이 있다. Presentation Layer 식당에서 역할 UI를 담당하는 계층이다. User에게 보여지는 화면 담당 User의 입력을 받는 담당 입력에 따른 결과를 서버로부터 받아서 다시 화면에 띄우는 담당 다른 계층과의 접촉이 없고 Control layer를 통해서 다른 계층과 협업한다. 따라서 presentatio…

웹 UI/DB 를 적용한 온라인 체스 게임을 구현하는 중 리뷰어가 다음과 같은 질문을 했다. 처음 웹 개발을 해보는 것이라서 우선 돌아가기 위해 인터넷과 크루들이 추가한 를 우선 가져와 추가했었는데 리뷰어의 질문을 받고 해당 개념을 찾아보았다. [참고 링크](https://tomgregory.com/gradle-implementation-vs-compile-dependencies/#:~:text=The compile dependency configuration is,the same functionality as compile.&text=You should always use implementation,as compile is now deprecated.) 결론부터 말해서 다음을 기억하면 될 것 같다. 은 Gradle 7.0 부터 depracated 되므로 대부분의 상황에서 을 사용하도록 한다. 과 은 거의 같은 가능을 하기 때문에 서로가 대체 되어도 상관없다. 그렇다면 imp…

아직 잘 모르는 분야라서 우선 두개의 차이점에 대해서만 기록해본다. 둘 중 어느 것을 어느 때에 사용해야 하는지에 대한 판단은 잘 모르겠지만 이 링크 를 확인해보면 singleton 사용을 지양하라고 했고, 또 정적 메소드도 객체지향에서는 지양하는 것이 좋다고 한다. 싱글톤 단 하나의 객체만을 생성할 수 있는 패턴이다. 객체를 생성하려고 할 때마다 이미 생성된 것을 반환하거나 없다면 해당 시간에 처음 생성하도록 한다. 정적 클래스와는 달리 싱클톤 클래스는 과 이 가능하다. 언제 생성하는지에 대한 시점을 조정할 수 있다. 객체이기 때문에 힙에 싱글톤 객체가 저장된다. 따라서 쓰레드간 공유가 가능하다. 싱글톤은 구현으로 단 하나만 생성되게 보장한 것이지만 그 자체로는 클래스 객체이기 때문에 직렬화가 가능하다. Static 클래스 Static 메소드를 가지는 클래스를 말한다. 어플리케이션이 메모리에 로드 될 때 정적 스택에 바로 초기화 된다. 표준 클래스라고 보기는 어렵고 라고 볼 …

전략 패턴(Strategy Pattern)이란? 객체가 할 수 있는 행위에 대한 생성하여 해당 행위들을 캡슐화(인터페이스화) 하여 사용하는 것이다. 즉, 행위를 각각의 전략 클래스로 생성하고 수정이 필요한 경우 전략을 바꾸는 것으로 행위를 수정하도록 한다. 왜 전략 패턴을 사용해야 할까? 예를 들어 움직이는 Bus, Train 이라는 객체가 있다고 하고 각각 move() 함수를 통해서 움직인다. 그런데, Bus는 도로로 Train은 선로로 움직인다. 만약 이때 버스가 더 이상 길이 아니라 선로로 움직인다고 가정할 때, 버스의 move() 메소드를 선로로 움직이는 로직으로 수정해야 한다. 이때 두 가지 문제가 발생한다. OCP (Open-Closed Principle)에 위배 : 수정에 닫혀있어야 하는데, 메소드를 직접 수정 확장이 될 경우 메서드 중복 문제 : 메소드를 가진 여러 객체가 있을 때 일일이 수정을 해아함 이 때 전략 패턴을 사용하면, 위 두 문제를 마주하지…

FSM 을 State Design Pattern 으로! FSM (Finite State Machine) : 유한 상태 기계 특징 유한한 개수의 상태를 가짐. 그 중 하나의 상태만 취함. 특정 조건이 되면 다른 상태로 변함. 가능한 상태 집합과 각 상태들의 전이 조건으로 정의됨. 왜 쓸까? 가능한 상태들을 명확히 규정할 수 있음. 상태 중복을 피하고 전이들읠 명확하게 규정할 수 있음. 기계의 동작이 명확히 규정됨. 이러한 FSM 을 구현하려면 각 상황에 대한 수많은 분기문들을 통해서 구현이 되어야 한다. 또한 기능이 하나 추가가 될 때 고려해야 할 상황과 추가해야할 코드들이 굉장히 많아진다. State Design Pattern 상태 디자인 패턴 언제 사용할까? 객체가 상태를 가져야 할 때 특정한 조건을 판단하여 해당하는 상태로 변환해야 하는 로직이 있을 때 각 상태마다 전이 조건이 있어 상황이 달라질 때 State Pattern 을 사용한다면? State Pattern 을 사용…

총 4가지 테스트에 대해서 간단히 다룰 것이다. 지금 우테코 LEVEL1에서 진행하고 있는 미션에서는 단위 테스트를 연습하는 TDD를 하고 있다. 내가 TDD를 할 줄이야.. 유닛 테스트(Unit Test) 가장 작은 단위의 테스트로 메서드 레벨로 테스트를 한다. (현재 내가 진행중인 TDD 방식) 즉각적인 결과가 나와서, 해당 메소드에 대한 원하는 결과가 연산이 되는지에 대한 확인이 가능한 테스트이다. 테스트 하기 어려운 메소드들이 등장하곤 하는데 이때는 stub (더미 객체가 마치 실제로 동작하는 것처럼 보이도록 만든 객체) 을 사용하여서 테스트 하는데 비용을 따져서 판단하도록 한다. (비용 관점을 항상 고려해야한다!) 하나의 메소드가 원하는 방식으로 동작한다는 것을 확인할 수 있지만, 결합되었을 때, 잘 동작하는지에 대한 보장은 어렵다. 전 구간 테스트(End-To-End Test) 시스템 자체와 시스템을 구축하고 배포하는 프로세스를 모두 시험한다. 내부 기능들(클래…

처음 MVC 패턴을 공부하게 되면서 잘 이해하지 못한 상태로 1단계 코드를 제출한 것 같다. 라는 부분을 간과하고 모든 도메인 모델에 대한 로직을 모두 Controller로 넘겼다. 하지만 MVC는 그렇게 분리되는 것이 아니었다. 이 부분에 대해 리뷰어에게 질문을 했더니 좋은 소스와 함께 정성스럽게 답해주셨다. 즉, 인데 Controller는 View로 부터 받은 입력을 기반으로 Model에 적절한 메세지를 보낸다. 그리고, Model은 해당 메시지에 따른 로직을 수행하고, 그에 따른 결과를 다시 Controller에 전달한다. 이렇게 왔다갔다 상호작용 하는 중간다리 역할이 Controller이다. 모든 서비스 로직을 Controller에다가만 구현하는 것이 아니다. 우테코에서 제공한 MVC 패턴에 대한 설명에도 핵심적인 설명이 있다. 리뷰어도 이것만 챙겨도 절반 이상이 MVC 패턴에 맞추어 진다고 한다. 공부하기에 좋은 자료로 추천한 위키피디아와, 모델-뷰-컨트롤러 …

Github에 익숙하지 않기 때문에 커밋은 나에게 push를 해서 업로드를 하기 위한 중간과정 중 하나였다. 하지만 다른 곳에서 깃헙이나 프로젝트 진행을 하면서 커밋을 하는 단위의 중요성과 깃헙의 최대 장점인 프로젝트를 되돌리기 위한 커밋 메세지의 중요성에 대해서 여러번 들었었다. 이번에 프리코스를 시작하면서 커밋 메세지에 대한 가이드를 읽고 정리해보기로 했다. 참고 사이트 CHANGELOG.md 생성하기 changelog에는 3개의 section이 있다: new features, bug fixes, breaking changes. 이러한 정보들은 배포가 될 때 script로 생성이 되어야 하며 해당하는 commit과 함께 제공되어야 한다. 해당 로그들을 보는 방법들은 다음과 같다. 지난 release 이후에 발생한 모든 subject(커밋 메세지의 첫번째 라인) 조회: 이번 release의 새로운 feature: Recognizing unimportant commits 사소한 …

프리코스를 진행하면서 구글에서 제공하는 javaGuide를 읽고 해당 convention을 따라서 코딩 하도록 하기 위해서 해당 문서를 정독했다. 원래 알고 있던 부분들도 있고 아닌 부분들도 있는데, 이렇게 잘 문서화 되어 있다는 것을 처음 알았다. 다음은 해당 문서를 읽으면서 두고두고 참고할 내용들을 정리한 것들이다. 다음 사이트 참고: Google Java Style Guide 1. Source file structure Java 소스 파일은 다음과 같은 구조를 가지고 있다. 순서에 유의하여 구조화 되어 있다. 만약 존재한다면, license or copyright information Package 명시 Import statements 단 하나의 top-level class → 위의 4 section을 1줄 간격(exactly one blank)으로 나눈다. 1-1. copyright information 소스파일 맨 위에 시작 주석으로 파일 클래스 이름, 버전 정보, 날짜…

이런 말이 있다. 동적 계획법이라는 말은 전문가들이 전문가들처럼 보여줄 수 있도록 해주는 말이고 일반인들에게는 그냥 ‘기억해서 풀기’ 다. 이항계수에 관련한 성질은 기억해두면 이후 코딩이나 알고리즘 문제를 풀 때 유용하기 때문에 기록해 준다. 이항계수를 풀 때 중요한 성질은 다음과 같다. $$ {n \choose k} = {n \choose n-k} $$ $$ {n \choose k} = {n-1 \choose k} + {n-1 \choose k-1} $$ $$ \sum_{k=1}^n {n \choose k} = 2^n $$ 위의 공식은 이항계수의 정의식을 참고해서 유도하는 방법으로 이항 계수의 정의식을 알고 있어야 한다. $$ {n \choose k} = {n}\mathrm{C}{k} = \frac{n!}{(n-k)!k!} $$ 동적 계획법을 활용한 이항계수 풀이 이항계수에 관련한 알고리즘 문제를 풀기 위해서 이항계수의 2번째 성질을 이용하기로 한다. 그 이유는 2번째 성질이 …

분할정복 알고리즘을 배울 때 나오는 유명한 문제 중 하나이다. 하지만 난이도가 굉장히 높기 때문에 쉽게 접근하기 어려웠는데, 분할 정복에 남은 마지막 문제를 그냥 안풀고 넘어가기엔 마음에 걸려서 마음먹고 공부해보기로 했다. 백준 사이트에서도 검색을 추천하여 알고리즘을 공부하기를 권하기 때문에 검색을 통해 좋은 글을 발견했다. 그리고 해당 문제의 솔루션을 이해하는데만 집중했다. 분할정복 문제를 반복해서 풀어보니 분할정복은 DP 만큼이나 여러가지 형태의 문제가 있으니 최대한 많은 문제들을 풀어보는 것이 중요하다는 것을 알 수 있었다. 그리고 여러 문제를 풀어 본 결과 다음을 깨달을 수 있었다. 분할정복에서 분할을 하는 이유 중 하나는 굳이 필요 없는 연산/비교 등을 하지 않기 위해서이다. 다르게 이야기하면 쓸데없는 것을 쳐내기 위해서 특정 기준에 따라서 계속 분할을 하는 것이다. 백준 2261 문제를 보면 어떤 의미인지 알 수 있다. 이 사실이 나로 하여금 더 구현을 잘하게 해주…

Back-tracking 알고리즘을 공부할 때 제일 먼저 구현하는 것이 순열과 조합이다. Back-tracking 알고리즘에 대해서 입문하고 감을 잡기 위해서 시작하기 좋은 코드이다. 따라서 순열과 조합을 구하는 코드를 보고 외워서 머릿속에 저장해두는 것을 추천한다. 순열과 조합의 차이점: 순열: 순열은 순서가 있는 조합이다.(A Permutation is an ordered Combination) 조합: 조합은 순서를 생각하지 않고 선택만 한다. 순열 코드 조합 코드 순열 코드 조합 코드

Binary Search 이분탐색을 구현하면서, 계속 런타임 에러가 났다. 처음에 재귀로 구현을 시작했는데, 재귀에 너무 큰 값이 들어오면서 stack overflow 에러가 났나 싶어서 다시 while 문으로 구현했다. 하지만 while 문으로 구현한 이후에도 계속 런타임 에러가 떠서 확인해보니, n과 m을 헷갈려서 잘못 적었던 것이었다. 이왕 while 문으로 구현해서 맞은 거, 재귀와 비교해 보자 해서 재귀를 돌려 보았더니, 재귀가 훨씬 빠르고 메모리 효율도 좋은 것이었다. 일반적으로 생각했을 때, 재귀는 매번 메모리를 할당하면서 새로운 함수를 call 해주어야 하고, 또 그만큼의 시간과 공간이 더 필요해서 반복문에 비해 성능이 다소 떨어진다고 알고 있었지만, 훨씬 빠르고 메모리 효율도 좋아서 그 이유에 대해서 찾아보게 되었다. 정딥은 Tail-recursion. Tail-Recursion Tail-Recursion이란? Tail-Recursion이란 recursion 함수…

앞서 히스토그램 문제에 대한 접근 방법을 간단하게 설명하고 세그먼트 트리를 히스토그램에 맞추어서 설명했다. 이번 글에서는 구체적으로 어떻게 세그먼트 트리를 구현하여 히스토그램 문제를 푸는데까지 이어지는지 다루어 보도록 하겠다. 이 문제는 레벨이 높은 문제이긴 하지만 아이디어 자체가 굉장히 어렵거나 하진 않다. 다만 시간 복잡도 측면에서 효율적으로 접근하기 위해 세그먼트 트리를 활용하는게 좀 낯설어서 어려웠던 것 같다. Segment Tree 구현 Segment Tree를 구현할 때 배열을 사용해서 구현하도록 할텐데 segment tree는 다음과 같은 성질을 가지고 있다. 세그먼트 트리는 거의 Full Binary Tree(비슷한 형태를 지님)의 모습을 하고 있다. 왼쪽 자식: 부모노트 * 2 오른쪽 자식: 부모노드 * 2 + 1 높이: lgN 배열을 통해서 tree를 구현하려면 사전에 tree의 노드 갯수를 파악해서 배열의 크기를 지정해야한다. 위의 성질들을 이용하면 해당 tre…

히스토그램에서 가장 큰 직사각형의 크기를 찾는 알고리즘을 풀다가, 관련 문제의 풀이법을 간단히 찾아서 금방 해결할 줄 알았으니 구현에서 의도치 않은 오랜 시간이 걸렸다. 먼저 문제의 해결 방법을 요약하면 다음과 같다. 히스토그램 중, 높이가 가장 낮은 min 값과 해당 너비값을 곱하여 넓이를 구함. 해당 최소값을 기준으로 히스토램을 나누어서 1번을 반복함. 더 이상 나눌 수 없을 때까지 반복하며 매번 넓이의 max 값을 업데이트 함. 다음은 백준 블로그에 있는 문제 해설에서 가져온 그림이다. 위의 해결 방법을 이해하는데 도움이 된다. histogram{: width=“80%“} 처음에 단순히 이 풀이방법을 배열과 재귀를 사용해서 구현하는 방법으로 시도를 했었다. 사이트에 나와있는 테스트 케이스가 통과하길래 바로 채점을 했더니 결과는 시간초과 였다.. 개인적으로 알고리즘을 할 때 가장 어려운 부분이 답을 출력이 되지만 시간초과가 나올 때 인 것 같다. 문제설명 밑에 해당 문제를 세그…

알고리즘에 대해서 배울 때 가장 먼저 다루는 부분이 바로 Time Complexity 이다. 기술이 발전하면서 메모리에 대한 부분은 상당 부분 해결이 되고 걱정하지 않아도 되는 부분이 되었다. 하지만 시간 복잡도 측면에서는 아무리 발전해도 부족한 부분이다. 왜냐하면 짧으면 짧을수록 더 좋기 때문이다. 따라서 알고리즘 강의를 들을 때에는 항상 Time Complexity에 대한 강의를 시작으로 배운다. 어떠한 문제에 대해서 여러가지 알고리즘을 사용하여 해결할 수 있을 때 무엇이 최적의 알고리즘인지를 판단하는 잣대는 해당 알고리즘으로 문제를 해결하는데 걸리는 시간이기 때문이다. 거기서 핵심적인 역할을 하는 두 theory에 대해서 다음 글의 내용을 번역 및 정리하면서 알아보자. Lower Bound와 upper Bound Theory는 어떠한 문제에 대한 가장 적은 복잡도를 가진 알고리즘을 선택하는데 핵심적인 역할을 한다. 구체적으로 이 이론들을 다루기 이전에 각각 Lower Bou…

이진탐색의 응용 버전으로 상/하한선을 찾는 알고리즘이다. 이를 응용한 문제를 풀면서 배운 개념을 정리해둔다. 이진탐색을 사용하면 모든 요소들을 다 방문하면서 탐색하는 것보다 훨씬 더 효율적으로 원하는 요소를 탐색할 수 있다. 하지만 이진탐색의 경우, 중복되지 않은 값이 주어진 경우이거나, 해당 요소의 존재 여부만을 가리기 위해서 일 경우에만 사용이 가능하다. 위의 문제의 경우, 중복되는 값들이 존재하며 그 값들이 총 몇개가 있는지도 확인할 수 있어야 하기 때문에 일반적인 이진탐색을 통해서는 답을 도출할 수 없다. 그래서 찾은 알고리즘 Upper Bound 와 Lower Bound 알고리즘 이다. 이진탐색에서 살짝 변형되어서 중복된 자료가 있을 때 유용하게 탐색할 수 있는 알고리즘이다. 아래 그림을 보면 lower bound와 upper bound에 대해서 더 잘 이해할 수 있다. image Upper Bound Algorithm 구현은 이진 탐색과 매우 유사하지만 약간의 변형…

이어서 딥러닝 영화 개인화 추천 모델을 구현하면서 구축한 딥러닝 협업 필터링 모델 부분에 대한 코드를 살펴보면서 딥러닝 전체적인 흐름에 대해서 짚어보자. 앞에서 언급했듯이 코드는 다음 링크에서 참고하여 모델과 전체적인 데이터 처리를 진행했고, 이후에 학습된 output에 대한 데이터 및 결과 후처리는 추가 구현했다. 해당 부분은 다음 파트에 다루도록 하겠다. 모델 전체 코드 Step1. 임베딩 - nn.Embedding() 위 코드를 보면 먼저 User와 Item에 관한 임베딩으로 시작한다. 파이토치에서 임베딩 벡터를 사용하는 방법은 크게 두가지가 있는데 그 중 위의 은 embedding layer를 만들어서 훈련 데이터로부터 처음부터 임베딩 벡터를 학습하는 방법이다. 먼저 임베딩 층의 입력으로 사용하기 위해서는 정수 인코딩이 되어 있어야 한다. 즉 다음과 같은 단계를 따른다. 어떤 단어 -> 고유한 정수로 인코딩 -> 임베딩 층을 통과 -> 밀집 벡터 즉, 고유한 정수 인…

인턴을 하는 중에 요즘에 중요한 머신러닝의 한 분야가 되고 있는 개인화 추천에 대한 개발을 맡게 되었다. 요즘 넷플릭스, 왓챠와 같은 OTT 서비스는 물론이고, SNS에 표기되는 광고, 당근마켓 등등과 같은 중고거래 및 쇼핑 어플리케이션에서도 중요한 것이 사용자의 취향을 분석하여서 알맞은 아이템을 추천하는 기술이 핵심이다. 어쩌면 사용자가 의식적으로 파악하고 있는 이상의 취향을 파악해서 추천해야 할 때도 있다. 이전 포스트에서 다루었듯이 개인화 추천에는 여러 통계기반 머신러닝 기법들이 있다. 그리고 인공 신경망이라는 딥러닝 기법이 등장하게 되면서 더욱 세밀하고 정확한 개인화 추천이 가능해졌다. 처음 접했기 때문에 매우 생소하고 낯선 분야였지만 많은 자료들을 찾아보면서 현재 내 삶(유튜브나 넷플릭스의 노예…)과 아주 밀접하게 연관이 되어 있는 많은 어플리케이션과 서비스등에 실제로 사용되고 있는 인공지능 기법이라는 것이 금방 흥미를 불러 일으켰다. 조금 어렵긴 하지만 facebook…

모 기업에서 인턴을 하면서 맡은 업무가 개인화 추천 모델 구현이었다. 맡은 업무는 딥러닝 기반의 개인화 추천 모델을 제작하는 것이지만 기존에 회사에서 가지고 있는 추천 시스템의 경우 협업 필터링 등으로 이미 구현이 되어 있었기 때문에 간단히 개인화 추천 시스템에 대한 브리핑을 해주시면서 감을 잡을 수 있도록 해주셨다. 추천 시스템 기술을 처음 접해보면서 어떠한 것인지 공부하며 기록해보려고 한다. 추천이란? 추천이란 간단히 말해서 사용자(user)에게 관심이 있을 것으로 예상이 되는 아이템(item)을 제안하는 것이다. 특정 아이템에 대한 특정 사용자의 선호도 또는 평가를 예측하는 것이 매우 중요하다. 우리가 흔히 생각해 낼 수 있는 추천 시스템은 페이스북과 같은 것에서의 광고 추천, 넷플릭스나 왓챠와 같은 OTT 서비스에서의 영화 추천 시스템이다. 접근 방식 추천 시스템 기술에서의 접근 방식은 크게 다음과 같은 3가지가 있다. 내용 기반 필터링 (Content-based …

자바에서 LIST 인터페이스를 구현한 Collection 구현체 중 가장 많이 쓰고 헷갈리는 것이 ArrayList와 LinkedList의 차이이다. 알고리즘 코딩을 공부하다가 특정 답을 배열 구조에 담을 일이 있어서 찾아보다 문득 ArrayList, LinkedList 중 무엇을 쓸까 고민하는 김에 정리하게 되었다. 인터페이스도 같고 사용하는 방식도 비슷한 부분이 많기 때문에 ArrayList를 써야할 때 LinkedList를 쓰거나 그 반대로 사용하더라도 큰 차이가 없이 느껴지기도 한다. 하지만 두 가지 자료구조가 구분되어 있는 만큼 더 적절한 부분이 있다. 간단히 한번 알아보자. Java에서는 변수를 저장하기 위해서 배열을 사용한다. 하지만 배열의 단점은 초기에 길이를 저장해서 미리 메모리를 확보해 놓아야 한다는 것이다. 다라서 동적으로 메모리 할당이 어려울 뿐만 아니라, 예상하지 못하는 입력크기에 대해서는 애초에 크게 배열의 크기를 잡아놓는 비효율적인 방법을 택해야 한다…

다음은 Java에 존재하는 아주 특이한 클래스인 Wrapper class에 대한 내용이다. JAVA wrapper class에 대해서 설명한 한 사이트를 번역하는 겸 공부한 내용을 정리해 작성해놓았다. 1. 개요 Wrapper class(감싸는 클래스) 이름이 설명하듯이 wrapper class는 자바의 Primitive types들을 객체로 감싸는 역할을 하는 클래스이다. 다음과 같은 자바의 primitive 타입들은 모두 각자의 wrapper 클래스가 있다. boolean, byte, short, char, int, long, float, double Boolean, Byte, Short, Character, Integer, Long, Float, Double 이것들은 모두 java.lang 패키지에 정의되어 있으므로 따로 import 하지 않아도 사용할 수 있다. 2. Wrapper Classes “Wrapper 클래스의 목적은 무엇입니까?”는 자바 관련 인터뷰에서 흔…

강남의 어느 검색 솔루션 기업에서 인턴한지 어연 4주차가 지나간다. 중간 지점을 지나가면서 한 것을 정리할 겸 나이브베이즈 문서 분류기 구현과 이론에 대해서 정리해 보려고 한다. 최대한 쉽게!! 나이브 베이즈 분류기는 베이즈 정리(Bayes’ theorem)을 사용한 분류 알고리즘이다. 이것은 전통적으로 텍스트 분류를 하는 분류기로 인공지능의 기능을 기학적으로 올려준 인공 신경망 알고리즘은 아니지만 머신 러닝의 중요한 알고리즘 중 하나로 꽤 좋은 성능을 보인다. 나이브 베이즈 분류기에서 사용하는 베이즈 정리는 무엇일까? 베이즈의 정리(Bayes’ theorem)를 사용한 분류 기법 베이즈 정리는 조건부 확률을 계산하는 방법 중 하나이다. 다음과 같이 표현할 수 있다. P(A): 사전확률(Prior). 사건 B가 발생하기 전 A가 가지고 있던 확률 P(B): 정규화 상수(normalizing constant). B가 일어날 확률 P(B | A): 가능도(likelihood). A가 …

다음은 분할정복 Divide and Conquer Algorithm에 대한 지식 블로그 번역 및 요약+추가정리 내용이다. 원문: https://www.geeksforgeeks.org/divide-and-conquer-algorithm-introduction/ 이 글에서는 분할정복이 유용한 경우와 분할정복으로 해결할 수 있는 문제의 접근방식에 대해서 다룰 것이다. 다음이 이 글에서 다룰 내용들이다. DAC(분할정복) 소개 및 정리 DAC을 사용하는 알고리즘 DAC 알고리즘을 사용한 재귀 DAC를 사용한 문제 예시 Divide and Conquer: Divide: 문제를 분할이 가능한 경우까지 분할한다. Conquer: 분할된 sub problem을 재귀로 호출해 정복한다. Combine: 해결된 sub problem들을 합쳐 문제의 해결책을 찾는다. DAC가 응용된 알고리즘 기법들: Binary Search(이진탐색): 검색하고자 하는 value를 주어진 배열의 중간 인덱스((…