beom's 기술저장소

Spring Framework 6.0 출시가 임박..!?

기범_Alex — Fri, 14 Oct 2022 13:08:14 +0900

해당 카테고리의 글은 개인적인 궁금증을 좀 더 편하게 작성해보며, 글 작성 능력을 길러보기 위한 카테고리입니다

Spring Framework 6.0이 RC1로 간다는 소식을 아래를 통해 접하게 되었다.

https://spring.io/blog/2022/10/12/spring-framework-6-0-goes-rc1

Spring Framework 6.0 goes RC1

<p>Dear Spring community,</p> <p>It is my pleasure to announce that a feature-complete Spring Framework 6.0 release candidate is <a href="https://repo.spring.io/">available</a> now! We are expecting a further release candidate in time for the first Spring

spring.io

RC 1이 뭐지?

Spring 5점 대도 잘 모르는데 벌써 6.0이라니.. 근데 저 RC 1은 뭘까?

소프트웨어 배포 생명주기는 아래와 같은 순서로 이루어져 있다.

https://ko.wikipedia.org/wiki/소프트웨어_배포_생명_주기

RC는 Release candidate 단계로 마지막 제품이 될 가능성이 있는 시험판(Beta)으로, 상당한 버그가 나타나지 않으면 출시할 준비가 되었음을 의미한다고 한다.

즉, 정식 출시가 임박했다는 의미이다.

아래 spring-framework 릴리즈 버전들을 보면 M(Mileston), RC(Release Candidate), GA(General Availability) 등이 있다.

https://github.com/spring-projects/spring-framework/releases

Releases · spring-projects/spring-framework

Spring Framework. Contribute to spring-projects/spring-framework development by creating an account on GitHub.

github.com

버전	요약	설명
Mx (ex.M1, M6) : Mileston	특정한 집합의 기능이 완성되자마자 공개한 버전	주요 기능 및 버그를 수정하는 단계로 불안정한 단계라고 볼 수 있다
RCx (ex. RC1) : Release Candidate	특별한 큰 버그가 없는 한 출시 준비 완료 버전 (정식 출시 임박)	Preview release 버전이라고 불릴 정도로 마지막 제품이 될 가능성이 있는 최종 베타 버전이다
GA : General Availability	정식 출시(Release)로써 다양한 매체를 통해 시장에서 이용 가능한 버전	대부분의 기능과 버그들이 안정화 된 버전으로써 필요한 모든 상업화 활동이 완료되어 시장에 배포되는 버전이다

그렇다면 Release 가 된 소프트웨어는 버저닝(Versioning)을 어떻게 할까?

가장 보편적인 규칙으로는 <major>.<minor>.<patch> 로 이루어진다

각각의 의미는 다음과 같다

버전	요약	설명
Major	기존 버전과 호환되지 않는 버전 (대규모 업데이트)	하위 버전과 호환되지 않을 정도로 대대적인 변화가 일어나는 경우이다 종종 들을 수 있는 "대규모 업데이트" 라는 것이 이에 해당된다
Minor	기존 버전과 호환되면서 새로운 기능이 추가된 버전 (기능 추가)	하위 버전과는 호환되는 버전으로 기존 기능들은 계속해서 사용할 수 있고, 새로운 기능이 추가될 때 minor 버전을 올린다 또한 기존 기능들의 사용 방법이 변경 되었을 경우에도 이에 해당된다
Patch	기존 버전과 호환되면서 버그를 수정한 버전 (버그 수정, 성능 향상, 리팩토링 등)	웹 개발을 예로, 기존 클라이언트 단이 알아차리지 못할 정도로 백엔드 단의 내부적인 코드만 수정되었을 경우 patch 버전을 올린다 또는 특정 기능의 버그를 fix하였을 때도 이에 해당된다

마무리

Spring 6.0 출시가 임박한다길래 충격 먹으면서 문득 versioning이 궁금해져서 이것저것 알아보았다

이것이 유명한 야크의 털 깎이인가..?

그래도 많은 시간을 할애하진 않았으니 평소에 궁금했었던 지식을 알게 돼서 뿌듯하다

다 쓰고 보니 또다시 충격이 몰려온다.. 기존 Spring도 제대로 사용해보지 못하고 있는데 기술은 날이 갈수록 발전하는구나..

자 다시 공부하러 가보자..!

소중한 피드백 의견은 언제나 환영입니다 :)

‍♂️ Call me
Email : dev.gibeom@gmail.com
KakaoTalk : https://open.kakao.com/me/beomdrive

순차 리스트 & 연결 리스트

기범_Alex — Thu, 13 Oct 2022 23:46:19 +0900

자료구조 카테고리의 글은 내용을 간단하게 압축시킨 정리본을 작성할 예정입니다

CS 관련 더 많은 글과 자료는 All-Rounder-Storage, 성장하는 개발자들의 지식 창고에서 볼 수 있습니다 :)

순차리스트 (Array, ArrayList)

Array

미리 할당된 크기만큼 저장공간이 연속적으로 배치되어 있는 같은 타입의 여러 변수들의 묶음

ArrayList

List의 인터페이스를 구현하므로 데이터의 저장순서가 유지되고 중복을 허용
Object 배열을 이용해서 데이터를 순차적으로 저장
- null을 포함한 모든 요소 저장을 허용
- n개의 요소를 추가하려면 O(n) 시간이 필요
내부에서 elementData(capacity)와 size로 나눠짐
- elementData(capacity) : 배열의 총 용량
- size : 요소(데이터)의 개수

장점

순차적으로 값을 저장하기 때문에 데이터를 읽는 속도가 매우 빠름
중간 위치가 아닌 맨 뒤의 위치에 데이터를 추가하거나 삭제하는것은 매우 빠름

순차적인 데이터 접근이 빠른 이유

각 요소들이 연속적으로 메모리상에 저장되어 있음

따라서 일일히 데이터 요소를 하나씩 찾아가는 것이 아닌 아래의 간단한 식 만으로도 위치 판별 가능

인덱스가 n인 데이터의 주소 = 배열의 주소 + n * 데이터 타입의 크기

단점

데이터를 계속 담다가 기존 용량이 넘어가면 속도가 일시적으로 느려짐
- 용량이 꽉차서 용량을 늘려야 될 때는 2배 더 큰 용량의 배열을 생성(size >> 1)하여 기존 배열로부터 복사가 이루어져야 함 → 효율 감소
배열의 중간에 위치한 객체를 추가하거나 삭제하면 작업시간이 오래걸림 (시간복잡도: O(n))
- 해당 위치 뒤에 있는 요소들을 전부 자리이동 발생
- System.arraycopy() 라는 다른 데이터의 위치를 이동 시켜주는 함수가 호출됨

주의점

중간에 있는 특정 범위의 값들을 삭제할때는 인덱스를 거꾸로(뒤 → 앞) 가면서 삭제해야 함
- 한 요소가 삭제될 때마다 빈 공간을 채우기 위해 나머지 요소들이 자리 이동함 (한칸씩 앞으로)
- 인덱스를 정방향(앞 → 뒤)로 삭제할 경우 엉뚱한 값들이 삭제될 수 있음
  - 2, 3, 4 인덱스를 삭제할 경우 → 2, 4, 6 인덱스가 삭제될 듯

연결 리스트 (LinkedList)

링크드 리스트

마찬가지로 List의 인터페이스를 구현하므로 데이터의 저장순서가 유지되고 중복을 허용
- 순차 리스트와 내부 구현방법만 다를 뿐 제공하는 기능은 거의 동일
이동 방향이 단방향이다
배열과 다르게 불연속적으로 존재하는 데이터를 서로 연결(link)한 형태
각 요소(node)들은 자신과 연결된 다음 요소에 대한 참조(주소값)와 데이터로 구성되어 있음

class Node {
    Node next;   // 다음 요소의 주소
    Object obj;  // 데이터
}

더블 링크드 리스트 (이중 연결리스트)

해당 자료구조가 Java에서 사용되는 LinkedList 이다
단순히 링크드 리스트에서 이전 요소에 대한 참조 변수를 추가한 형태

class Node {
    Node next;       // 다음 요소의 주소
    Node previous;   // 이전 요소의 주소
    Object obj;      // 데이터
}

더블 써큘러 링크드 리스트 (이중 원형 연결리스트)

단순히 더블 링크드 리스트에서 첫번째 요소와 마지막 요소를 연결 시킨 형태

장점

중간 요소의 추가 및 삭제가 매우 빠르다
- 단순히 삭제하고자 하는 요소의 이전 요소가 다음 요소를 참조하도록 변경하면 됨
- 배열처럼 복사해서 자리 이동시키는 행위가 없음

단점

데이터를 읽는 속도가 느림
- 불연속적으로 위치한 각 요소들이 서로 연결(link)된 것이라 처음부터 n번째 데이터까지 차례대로 따라가면서 접근해야됨

주의점

단순히 LinkedList가 중간 위치의 요소를 추가 및 삭제 하는것이 빠르다고들 하는데, 실제로 해당 요소의 위치까지 접근하는 시간이 O(n)이기 때문에 마냥 빠르다고만 할 수는 없음

순차 리스트(ArrayList) vs 연결 리스트(LinkedList)

	ArrayList	LinkedList
데이터 읽기 (접근 시간)	빠르다	느리다
순차적인 데이터 추가/삭제	빠르다	느리다
중간 데이터 추가/삭제	느리다 (copy → 이동)	빠르다 (접근 시간때문에 마냥 빠르진 않다)

마무리

ArrayList의 중간 요소를 추가/삭제 하는것이 O(n)이다.

LinkedList가 중간 요소를 추가/삭제하는 것이 시간 복잡도가 1이지만 실제로는 해당 요소까지 접근하는 것이 O(n)이다.

그렇다면 어떤 상황에서 무엇을 선택해야 하는 것일까?

단순히 속도로 보지 말고 효율적인 메모리 용량 관점에서 바라보면 아래와 같을 것 같다.

다루고자 하는 데이터의 양이 변하지 않고 예측 가능한 경우라면, 또한 데이터 접근을 자주 하는 경우라면 용량을 넉넉하게 선언한 ArrayList를 사용하는 것이 제일 좋은 선택이며, 데이터 개수의 변경이 잦을 경우는 LinkedList를 사용하는 것이 현명해 보인다.

자료가 도움이 되셨다면 All-Rounder-Storage, 성장하는 개발자들의 지식 창고로 놀러오세요!

Reference

잘못된 내용이나, 보충할 내용이 있다면 언제든지 편하게 연락 주시면 감사하겠습니다 :)

‍♂️ Call me
Email : dev.gibeom@gmail.com
KakaoTalk : https://open.kakao.com/me/beomdrive

로드 밸런싱, 그 속으로

기범_Alex — Sat, 24 Sep 2022 14:13:42 +0900

해당 글에서는 트래픽 분산기술인 로드 밸런싱에 대해서 알아봅니다
CS 관련 더 많은 글과 자료는 All-Rounder-Storage, 성장하는 개발자들의 지식 창고에서 볼 수 있습니다 :)

로드 밸런싱을 알려면 우선 로드 밸런서에 대해서 알아보아야 합니다

로드 밸런서(Load Balancer)란?

로드 밸런서는 트래픽을 분산하여 서버 한대에 요청이 집중되지 않게 하여 각 서버의 과부하를 방지해주는 역할을 해주는 장치 또는 기술입니다
일반적으로 서버의 상단 네트워크에 위치합니다
- 아래 예시와 같이 클라이언트에서 서버로부터의 요청은 로드 밸런서를 통해 각 서버로 전달됩니다
  이미지 출처: https://naver.me/xor8AbSO

로드 밸런서의 기본 기능

1. Health Check (상태 확인)

각 서버가 정상적으로 살아있는지, 요청을 수행할 수 있는 지에 대한 상태를 체크하는 기능입니다
- 각 서버들의 장애 여부를 판단하여, 정상적으로 동작중인 서버로만 트래픽을 보내줍니다
- 주로 하드웨어로 많이쓰는 로드밸런서는 L4와 L7 로써 아래와 같은 방식으로 체크합니다
  - L4 체크 : TCP의 3-way handshaking 방식을 기반으로 각 포트의 상태를 체크합니다
  - L7 체크 : 애플리케이션 계층에서 체크하므로 실제 웹 페이지에 통신을 시도하여 상태를 체크합니다
- 로드 밸런서 내부 설정을 통해 헬스 체크 방법을 변경할 수 있다고 합니다

2. NAT (Network Address Translation)

주로 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위해 사용되는 방식입니다

IP 주소를 변환해주는 기능입니다
공인 IP는 한정적인 수량이므로 IP 주소를 절약할 수 있는 동시에, 하위 서버의 내부적인 IP를 숨길 수 있으므로 보안에도 효과적입니다
- 즉 로드밸런서를 통해 외부 통신(요청, 응답)이 가능하므로 해당 기능을 사용할 수 있다고 생각됩니다

NAT의 종류

방식	흐름	설명
SNAT (Source NAT)	내부 → 외부	내부 사설 IP 주소를 외부의 공인 IP 주소로 변환하는 방식
DNAT (Destination NAT)	외부 → 내부	외부 공인 IP 주소를 내부의 사설 IP로 주소로 변환하는 방식

이미지 출처: https://www.stevenjlee.net/2020/07/11/이해하기-nat-network-address-translation-네트워크-주소-변환/

3. DSR (Direct Server Return or Direct Server Routing)

서버에서 클라이언트로 되돌아갈 때, 네트워크 장비나 로드밸런서를 거치지 않고 목적지인 클라이언트로 바로 찾아가는 방식입니다
서버 → 로드 밸런서로 가는 단계를 하나 줄여줌으로써 트래픽 부하를 줄여주는 장점이 있습니다

4. Tunneling

인터넷 상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있는 개념입니다
- 즉 데이터 스트림을 가상의 파이프를 통해 전달시키는 기술입니다
데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있습니다
- 말그대로 연결된 서버에서만 캡슐화된 데이터를 해제할 수 있는 기능입니다

5. 알고리즘에 따른 분산 처리

이 부분에 대해서는 아래에서 자세히 알아보겠습니다

웹 서버 구조

일반적인 웹 인프라 구조는 두가지로 이루어집니다

1. Vertical Scale-Up

2. Horizontal Scale-Out

1. Scale-up (스케일 업)

서버 자체의 성능을 업그레이드 시켜주는 방식입니다

즉 하나의 서버에 디스크를 추가하거나, CPU 혹은 메모리(Ram)를 업그레이드 시키는 등 한 서버 자체의 사양을 업그레이드 하는 방법을 말합니다

이미지 출처: https://liasn.tistory.com/2

장점

1. 추가적인 네트워크 연결이 필요 없으므로 인프라 설계가 쉽습니다

2. 서버를 추가하는 방법이 아니므로 데이터 정합성 문제로부터 자유롭습니다

단점

1. 하나의 서버의 성능을 높이는 것엔 물리적인 한계가 발생할 수 밖에 없습니다

2. 서버 한대에 모든 부하가 집중되므로 장애 시, 해당 서버가 복구 되기 전까지는 서비스를 중단해야 하는 상황이 발생합니다

따라서 Scale-up의 방식은 한 대의 서버에서 모든 데이터를 처리하는 방식이므로, 데이터 갱신이 빈번하게 일어나는 데이터베이스 서버에 적합한 방식입니다

2. Scale-out (스케일 아웃)

서버를 추가하여 확장하는 방식입니다
- 즉 서버 한대에서 처리해야 할 트래픽을 여러대의 서버로 분산시키는 방식입니다
일반적으로 비슷한 사양이나 덜 좋은 사양의 서버를 추가로 연결합니다
해당 방식에서 부하를 균등하게 나눠주는 "로드밸런싱"이라는 기술이 필수적으로 적용되어야 합니다

이미지 출처: https://liasn.tistory.com/2

장점

서비스 중 서버 한대가 다운되더라도 다른 서버로 서비스 제공이 가능합니다
확장이 무제한으로 가능하므로 그때 그때 상황에 맞춰 서버를 유연하게 관리할 수 있습니다
- 클라우드 서비스에서는 자원 사용량을 모니터링 하여 부하가 많을 경우 자동으로 서버를 증설(Scale-Out) 해주는 Auto Scaling 기능도 있습니다
단일 서버에서 겪게 되는 병목 현상을 줄일 수 있습니다

단점

여러 대의 서버로 돌아가기 때문에 데이터 정합성 문제가 발생할 수 있습니다
- 따라서 데이터의 일관성을 유지하기 위한 인프라 설계 및 관리가 복잡하고 어렵습니다
세션, 웹 이미지 등 서버에 저장되는 데이터를 어떤식으로 확장된 서버들에게도 공유해야할지 등에 대한 기술적인 한계가 존재합니다

따라서 Scale-out 방식은 대규모 서비스일 경우, 또는 모든 서버가 동일한 데이터를 가지고 있어야 하므로, 데이터 변화가 적은 웹 서버에 적합한 방식입니다

[정리] Scale-up vs Sclae-out

	Scale-up (Vertical)	Scale-out (Horizontal)
장점	- 데이터 정합성 처리 불필요 - 관리 포인트 측면에서 관리가 쉬움 - 단일 서버이므로 손쉽게 성능 향상 가능	- 서버의 중단 없이 무제한 확장 가능 - 유연하게 관리할 수 있어 가용성 증가 - 부품에 의한 성능 향상의 한계가 없음
단점	- 유연한 확장 불가능 - 확장하려면 서버를 중단해야 함 - 부품 업그레이드의 한계가 존재 - 단일 서버에서 장애 발생 시 서비스 불가	- 데이터 정합성 처리가 별도로 필요 - 관리 포인트 증가 - 트래픽 조정을 위한 로드 밸런싱 기술 필요
적합한 방식	데이터 갱신이 빈번하게 일어나는 데이터베이스 서버에 적합한 방식	대규모 서비스일 경우, 데이터 변화가 적은 웹 서버에 적합한 방식

이미지 출처: https://tech.gluesys.com/blog/2020/02/17/storage_3_intro.html

따라서 이처럼 Scale-up 과 Scale-out의 각각의 장단점이 존재하므로 운영 중인 서비스에 맞게 합리적인 방식을 적용하는 것이 좋습니다

데이터 정합성 문제란?

위에서 계속 데이터 정합성 문제를 반복해서 말하고 있습니다

데이터 정합성 문제란 데이터가 일관되지 않는 문제를 말합니다
- Scale-out 방식에서 여러 대의 서버가 병렬적인 환경에서 돌아가므로, 각각의 모든 서버에 데이터를 일관되게 맞춰주는 방법이 필요합니다
아래 사진은 구글링하다가 정합성이 훼손된 재밌는 예시가 있어 가져와보았습니다

데이터 정합성 문제를 해결하는 방법

Scale-out을 통한 웹 서비스 상의 대표적인 데이터 정합성 문제는 세션 불일치 문제입니다

사용자가 로그인을 Server 1번에서 진행하여 세션을 Server 1번에 저장해놨는데,
다음 요청이 Server 2번을 통해 들어온다면 Server 2번에는 세션이 없어 다시 로그인해야 하는 문제가 생깁니다

세션 정합성 이슈에 대한 해결책은 크게 3가지 입니다

1. Sticky Session

2. Session Clustering

3. In-memory Database

세션 정합성 이슈 요약

바쁘시다면!	내용 요약
Sticky Session	- 세션을 최초로 생성한 서버로 요청이 고정되는 방식 - 세션 공유 필요 없으므로 정합성 이슈 해결 - 로드 밸런싱과 가용성 면에서 기능 저하
Session Clustering	- 세션이 생성될 때마다 복제하여 나머지 서버에 동기화 작업 - 모든 서버의 세션이 존재하므로 정합성 이슈 해결 - 매번 세션 객체를 복제하는데 오버헤드 발생 위험
Session Storage	- 세션 저장소를 분리하여 사용하는 방식 - 각 서버에 세션 저장소에 대한 정보만 입력하면 세션 공유 가능하므로 서버의 확장에 유연하게 대처 가능

1. Sticky Session (서버 고정 방식)

세션을 가진 서버로만 요청을 전송하는 방식입니다
- 첫 요청을 통해 한 서버에서 세션이 생성되었을 경우, 세션기간 동안 동일한 클라이언트의 요청은 로드 밸런서가 항상 같은 서버로만 전달하는 방식입니다
이미지 출처: https://liasn.tistory.com/3

장점

여러 서버들끼리 세션 데이터를 교환할 필요가 없습니다

단점

1. 특정 서버에 부하가 집중될 수 있습니다 → 로드 밸런싱의 이점 감소

이미지 출처: https://hyuntaeknote.tistory.com/6

2. 특정 서버에 과부하가 걸릴 경우, 로드 밸런서는 이를 감지해 다른 서버로 트래픽을 다시 라우팅합니다
→ 결국 세션 유실

이미지 출처: https://hyuntaeknote.tistory.com/6

따라서 Sticky Session 방식은 세션의 데이터 정합성 문제는 해결할 수 있지만,
Scale-out을 통한 트래픽 분산 효과와 서버 가용성을 제대로 사용할 수 없습니다

2. Session Clustering (Tomcat)

여러 서버끼리 세션을 공유(동기화)하여 로드밸런서를 통한 요청이 어떤 서버로 전달되든 세션이 동일하게 유지되도록 하는 방식입니다
구현 방식은 크게 두가지가 있습니다 (Tomcat 지원 기능)
- DeltaManager : all-to-all 세션 복제 (4개 이하 클러스터)
- BackupManager : primary-secondary 세션 복제 (4개 이상 클러스터)

DeltaManager : all-to-all 세션 복제 (4개 이하 클러스터)

하나의 세션 저장소에 변경이 일어난다면, 변경된 사항을 다른 모든 세션 저장소에 적용해주는 방식입니다
Tomcat 문서에서는 4개보다 더 많은 노드를 가지는 대규모 클러스터 환경에는 적용하지 않는 것을 권장합니다

이미지 출처:   https://hyuntaeknote.tistory.com/6

BackupManager : primary-secondary 세션 복제 (4개 이상 클러스터)

하나의 세션 저장소에서 세션이 생성되면 세컨드 저장소(백업)에만세션값 전체를 복제하고, 나머지 저장소에는 세션 key인 JSESSION ID만을 복제하여 all-to-all 방식보다 메모리 사용을 줄일수 있는 방식입니다
4개 이상의 대규모 클러스터에서 사용하기 용이한 방식입니다

이미지 출처: https://hyuntaeknote.tistory.com/6

하지만 세션 ID만 가지고 있는 서버로(Primary, Secondary가 아닌) 요청이 들어올 경우에는 Primary 서버에 세션 키를 통해 세션 객체를 받아와야 하는 작업이 발생하는 단점이 있습니다

3. Session Storage (In-memory Database)

위 방식은 각각의 서버가 모두 상태(세션 데이터)를 가지고 있기 때문에 사용되는 방식입니다
- 따라서 Scale-out에 장점을 온전히 얻지 못하는 단점이 있습니다 (세션 정합성을 맞춰주기 위해)
세션 데이터를 각 서버들이 갖고있지 않고 외부로 분리하는 방식으로 Scale-out의 장점을 극대화하면서, 대용량 트래픽에 대응해 효율적이고 유연하게 확장시킬 수 있는 방식이 Session Storage 방식입니다

이미지 출처: https://liasn.tistory.com/3

장점

세션을 별도의 저장소로 관리함으로써 데이터 정합성 문제 해결
임의적으로 라우팅을 고정할 필요 없어 효과적인 로드 밸런싱에 유리 (Sticky Session 단점 해결)
세션 정보의 복제 과정이 필요 없어 효율적인 메모리 관리 (Session Clustering 단점 해결)
세션 저장소의 정보만 있으면 바로 세션 공유가 가능하기에 서버 확장 등의 유연한 서버 관리에 용이

In-memory DB 종류

세션 스토리지의 종류로는 대표적으로 Redis와 Memcached가 사용됩니다

	Redis	Memcached
장점	- 다양한 자료구조 지원 - 데이터 백업 및 복구 가능 - 다양한 Eviction 결정 방식을 통해 메모리 공간 확보 - Spring 공식 지원 - 일반적으로 Read 성능이 더 좋음	- Multi-Thread 제공 - 효율적인 메모리 할당 방식을 통한 메모리 파편화 최소화 - LRU 한 가지 방식만으로 메모리 공간 확보 - 일반적으로 Write 성능이 더 좋음

해당 장단점을 고려하여 서비스에 맞는 기술을 선택하면 됩니다

로드 밸런싱이란? (Load Balancing)

Load(서버가 받는 요청, 부하) + Balancing(분산)

Scale-out 방식에서 로드 밸런서를 통해 클라이언트로부터 올라오는 모든 요청(부하)을 분산해주는 기술입니다
로드 밸런싱의 알고리즘 중 5가지에 대해서 간략하게 알아보겠습니다

로드 밸런싱 알고리즘

1. 라운드로빈 방식 (Round Robin Method)

서버에 들어온 요청 순서대로 돌아가면서 각 서버에 배정하는 방식입니다
하위 서버들이 동일한 스펙을 갖고 있고, 서버와의 연결이 오래 지속되지 않는 경우에 활용하기 적합한 방식입니다

2. 가중 라운드로빈 방식 (Weighted Round Robin Method)

각 하위 서버들마다 가중치를 매겨, 가중치가 높은 서버에 요청을 우선적으로 배분하는 방식입니다
- 즉 로드밸런서가 하위 서버의 성능을 고려하여 트래픽의 양을 조절해줍니다
주로 각 서버들의 트래픽 처리 능력이 다른 경우에 사용되는 방식입니다

3. IP 해시 방식 (IP Hash Method)

클라이언트의 IP 주소를 특정 서버로 매핑(해싱)하여 요청을 처리하는 방식입니다
이 방식은 사용자가 항상 동일한 서버로 연결되는 것을 보장합니다

4. 최소 연결 방식 (Least Connection Method)

요청이 들어온 시점에서 가장 연결상태가 적어 여유로운 서버에 우선적으로 트래픽은 배분하는 방식입니다
하위 서버들이 로드밸런서에게 현재 감당하고 있는 트래픽의 양과 연결중인 커넥션 수에 대한 정보를 공유하고, 해당 정보를 통해 전달 서버를 결정합니다
서버의 연결이 자주 길어지거나, 각 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합합니다

5. 최소 리스폰타임 (Least Response Time Method)

서버의 현재 연결 상태와 응답시간을 모두 고려하여, 가장 응답시간이 짧은 서버로 트래픽을 우선적으로 할당하는 방식입니다
각 하위 서버들의 가용한 리소스와 성능, 처리중인 데이터 양 등이 다를 경우에 적합합니다

로드 밸런싱의 구현 방법

로드 밸런싱은 하드웨어 구현, 소프트웨어 구현으로 나눠집니다

하드웨어 구현방법

하드웨어를 통한 로드밸런싱 구현 방법에는 대표적으로 L4와 L7의 로드밸런서가 사용됩니다
L4 로드밸런서와 L7 로드밸런서의 차이는 아래의 표로 확인해보겠습니다

이미지 출처: 가비아 - 로드밸런서(Load Balancer)의 개념과 특징

간단하게 L4와 L7 장비의 차이는 트래픽 분산을 할 때 그 로드밸런서가 어떤 메타 데이터의 어느 수준(범위)까지 분석해서 분산할지를 가장 큰 차이점으로 두는 것 같습니다
또한 두 장비에 대한 속도적인 비교는 둘 다 장비 자체가 워낙 빠르기 때문에 비교 대상에는 포함되지 않습니다 (마이너한 기준)

위의 내용에 추가로 L7 로드 밸런서는 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호하는 기능이 있으므로, DDoS 같은 비정상적인 트래픽을 필터링하는 기능이 있어 네트워크 보안에 유리합니다

소프트웨어 구현방법

하드웨어인 L4, L7 로드밸런서를 대신하여 reverse proxy 형태인 NginX, HAProxy 등의 로드 밸런서 애플리케이션을 활용하여 소프트웨어적으로도 구현할 수 있습니다
하드웨어보다 성능적인 면은 떨어지지만 단순히 로직(?)만 구현하면 되므로 비용적으로 유리하다는 장점이 있습니다
- 또한 Scale-out 방식에서 config 설정 파일만 수정하면 바로 적용시킬 수 있기 때문에 유연하고 쉬운 서버 관리가 가능합니다

마무리

굉장히 많은 내용을 통해 로드밸런싱에 대해서 알아보았습니다

결국은 트래픽을 효과적으로 분산하는 방법을 통해 대량의 트래픽을 감당하기 위한 방법인데요

마지막으로 한가지의 의문이 있습니다

로드 밸런서 자체가 문제가 있다면?

로드 밸런서 자체를 이중화하지 않은 단일 서버 상태라면 해당 장비 or 서버에 장애가 일어난다면 하위 서버는 모두 요청을 전달받지 못해 전체 서비스가 다운됩니다
이 현상을 SPOF (Single Point of Failure)라고 부릅니다
따라서 로드밸런서 자체에도 Scale-Out을 해줌으로써 이중화를 통한 안전성을 확보해야 합니다
- 로드밸런서의 확장은 일반적으로 Master-Slave 방식으로 구성됩니다
- 평시에는 Master가 로드밸런서의 역할을 주로 수행하고 여분으로 Slave를 갖고있습니다
- Master에 장애 발생 시 여분인 Slave가 Master를 바로 위임받아 로드밸런서 역할을 바로 수행함으로써 서비스가 중단되지 않게 구성해주어야 합니다

자료가 도움이 되셨다면 All-Rounder-Storage, 성장하는 개발자들의 지식 창고로 놀러오세요!

Reference

잘못된 내용이나, 보충할 내용이 있다면 언제든지 편하게 연락 주시면 감사하겠습니다 :)

‍♂️ Call me
Email : dev.gibeom@gmail.com
KakaoTalk : https://open.kakao.com/me/beomdrive

변수와 메서드, 그 속으로

기범_Alex — Tue, 6 Sep 2022 04:40:42 +0900

백엔드 관련 자료는 Backend Wiki에서 PR을 통해 검증과 내용 보완을 거친 후 블로그로 이관되고 있습니다 :)

변수의 종류

변수는 변수가 선언된 위치에 따라서 변수의 종류가 결정됩니다
클래스 영역에 선언된 변수는 모두 멤버 변수이고, 멤버 변수를 제외한 나머지 변수들은 모두 지역변수입니다
멤버 변수는 두가지로 나뉘어지는데, static이 붙어있으면 클래스 변수이고 붙지 않은것은 인스턴스 변수입니다
- 멤버변수 = 클래스 변수 + 인스턴스 변수

변수 종류	설명	생성 시기
클래스 변수 (멤버 변수)	static이 붙어있는 경우	클래스가 메모리에 로딩될 때
인스턴스 변수 (멤버 변수)	static이 붙어있지 않은 경우	인스턴스가 생성되었을 때
지역 변수	멤버 변수를 제외한 나머지	변수 선언문이 수행되었을 때

public class Study {
    
    int iv; // 인스턴스 변수
    static int cv;  // 클래스 변수 (static변수, 공유변수)

    void method() {
        int lv = 0; // 지역 변수
    }
}

인스턴스 변수

클래스의 인스턴스를 생성할 때 만들어집니다
- Person giibeom = new Person();
인스턴스는 독립적인 저장 공간을 가지므로 각자 서로 다른 값을 가질 수 있습니다

class Person {
    String name;
    static int eye;
}

// 참조변수 giibeom과 alex는 같은 Person 객체이지만 name은 서로 다른 값을 가진다 (다른 주소값)
Person giibeom = new Person();
giibeom.name = "Myoung gibeom";

Person alex = new Person();
alex.name = "Alex";

따라서 인스턴스 마다 고유한 상태를 유지해야 하는 속성(변수)의 경우 인스턴스 변수로 선언해야 합니다
인스턴스 변수는 직접 접근이 안되므로 인스턴스 생성 후 접근이 가능합니다!

Person myoung = new Person();
myoung.name = “gibeom”;

클래스 변수

클래스 변수 선언은 인스턴스 변수 앞에 static을 붙이기만 하면 됩니다
클래스 변수는 모든 인스턴스가 공통된 저장 공간(변수)을 공유하게 됩니다
따라서 한 클래스의 모든 인스턴스들이 공통적인 값을 유지하며, 공유하여 사용해야 하는 변수인 경우 클래스 변수로 선언해야 합니다
클래스 변수는 인스턴스를 만들지 않아도 직접 접근이 가능합니다!
- Person.eye = 2;

지역 변수

지역 변수는 메서드 내에 선언되며 메서드 내에서만 사용이 가능합니다
메서드 내에서 선언된 변수들 + 매개변수는 모두 지역변수입니다
따라서 메서드가 종료되면({} 밖으로 벗어난 경우) 소멸되어 사용할 수 없습니다

// add의 매개변수 x,y 와 minus의 매개변수 x,y는 서로 다른것이다!

int add(int x, int y) {
....
}

int minus(int x, int y) {
....
}

이 상황에선 클래스 변수? or 인스턴스 변수?

클래스 변수와 인스턴스 변수를 각각 언제 무엇으로 써야 되는지 알아봅시다

//   원카드, 포커 등을 할 수 있는 게임카드를 예시로 들어보자


// 카드의 속성: 무늬, 숫자, 폭, 높이, 재질

// 카드의 폭, 높이, 재질은 "공통적인 부분"이니 서로 공유하게끔 클래스 변수로 선언합니다
// 무늬와 숫자는 "각자 고유한 값"을 가져가야 하니 인스턴스 변수로 선언합니다
class Card {
    String kind;    // 무늬
    int number;     // 숫자
    static int width = 100;     // 폭
    static int height = 250;    // 높이
    static String material = "plastic"; // 재질
}

메서드

메서드는 특정 작업을 수행하는 일련의 문장들끼리 하나로 묶은 것입니다
메서드를 사용할 땐 그저 넣을 값(입력)과 반환하는 결과(출력)만 알면 됩니다
- 메서드가 내부적으로 어떻게 동작하는지 몰라도 사용하는데 아무런 지장이 없습니다
- 따라서 메서드는 내부가 보이지 않는 블랙박스 라고도 불립니다
- 이 말은 즉슨 넣을 값과 반환 결과만 동일하다면 언제든 메서드 내부 수정이 가능하다는 말입니다
- 이것이 객체지향 메서드의 장점입니다!

메서드를 사용하는 이유

메서드의 대표적인 장점 3가지에 대해서 알아봅시다

1. 높은 재사용성(reusability)

이미 우리는 Java API에서 제공하는 다양한 메서드들을 사용하면서 경험해본 적이 있습니다
- java.lang 패키지 (String, Integer, …)
- java.util 패키지 (Arrays, Calendar, Date, Objects, StringTokenizer, …)
메서드를 한번 만들어 놓으면 필요한 상황에서 몇 번이고 호출하여 사용할 수 있습니다

2. 중복된 코드의 제거

프로그래밍을 하다 보면 같은 내용의 문장들을 여러 곳에서 반복해서 사용하곤 합니다
- ex) 로그용 System.out.println() 등등 …
- 물론 실무에서는 log 라이브러리를 사용해야 합니다
메서드를 사용하면 반복되는 문장들 대신, 메서드를 호출하는 한 문장으로 대체가 가능합니다
오류를 수정해야할 때에도 여러곳에 퍼진 것들을 일일히 정리하기에는 위험요소가 많지만, 메서드로 구현을 한다면 메서드만 변경하면 됩니다

3. 프로그램의 구조화

프로그램의 전체 흐름이 한눈에 들어올 정도로 단순하게 구조화 하여 코드를 작성하여야 합니다
가독성이 좋아야 오류를 빠르게 찾을 수 있어 유지보수에 용이합니다
이때 메서드를 통해 프로그램을 구조화 시킬 수 있습니다

위의 코드를 구조화하여 작성해보겠습니다
위의 예제를 작업단위로 나누어서 메서드를 만들어보면 다음과 같습니다

// 위 사진(코드)의 구조화 적용 코드

public static void main(String[] args) {

    int[] numArr = new int[10];

    initArr(numArr);    // 1. 배열을 초기화
    printArr(numArr);   // 2. 배열을 출력
    sortArr(numArr);    // 3. 배열을 정렬
    printArr(numArr);   // 4. 배열을 출력

}

메서드의 선언과 구현

메서드는 선언부(header, 머리)와 구현부(body, 몸통)로 이루어져 있습니다

반환타입  메서드이름  (타입 변수명, 타입 변수명, ...)      --> 선언부
{
....         --> 구현부
}

메서드 선언부

메서드 선언부는 메서드가 작업을 수행하기 위해 어떤 값들을 필요로 하고, 작업의 결과로 어떤 타입의 값을 반환하는지에 대한 정보를 제공합니다
메서드의 선언부는 3가지로 구성되어 있습니다

1. 메서드의 이름

보통 동사로 많이 짓습니다
메서드의 이름만으로도 어떤 기능인지 쉽게 알 수 있도록 함축적이면서도 의미있는 이름을 짓도록 노력해야 합니다

2. 매개변수 선언 (parameter declaration)

작업을 수행하는데 제공 받아야 하는 필요한 입력 값들을 적습니다
매개변수는 여러개가 될 수 있습니다

3. 반환타입 (return type)

작업 수행 출력결과인 반환값의 타입을 적습니다
반환값은 최대 1개만 허용됩니다
반환타입이 void일 경우에는 아무것도 반환하지 않습니다

메서드 구현부

메서드 선언부 다음에 오는 괄호 {} 를 메서드의 구현부라고 합니다
해당 메서드 반환 타입이 void가 아닐 시 return 반환값; 을 반드시 포함해야 합니다
- 반환 타입이 void 이면 컴파일러가 메서드 마지막에 return; 을 자동적으로 추가해줍니다
- 반환 값의 타입은 메서드 선언부의 반환 타입과 일치하거나, 자동 형변환이 가능한 것이여야 합니다

// 반환값인 result가 반환타입인 double와 동일하거나 double로 자동 형변환이 되는 타입이어야 한다
// 반환 타입: double,  반환값: int(int -> double 자동 형변환 가능)

double add(int x, int y) {
    int result = x + y;
    return result;
}

메서드의 호출

메서드는 매개변수(인자)와 일치하는 ‘인수(argument)’ 를 집어넣어 호출하여야 합니다

add(7, 10)          // int add(int x, int y)를 호출하고 인수 7을 x에, 인수 10을 y에 대입
print99danAll();     // void print99danAll()을 호출

같은 클래스 내의 메서드끼리는 참조변수 없이 서로 호출이 가능하지만, static 메서드는 같은 클래스 내의 인스턴스 메서드를 호출할 수 없습니다
- static → static : 가능
- non-static → non-static : 가능
- non-static → static : 가능
- static → non-static : 불가능

왜 static에서 non-static을 호출할 수 없을까?

static 변수와 static 메서드는 클래스가 로딩되는 시점에 메모리에 올라갑니다
하지만 non-static은 인스턴스가 생성될 때만 사용이 가능합니다
따라서 인스턴스가 생성된 시점에서는 static은 당연히 메모리에 올라가있는 상태이겠지만, 반대로 클래스가 로딩되는 시점엔 인스턴스가 생성 되어있을거란 보장이 없기 때문에 컴파일 오류가 발생합니다
따라서 static에서 non-static을 사용하려면 메서드 내에서 해당 인스턴스를 생성 한 후 사용하여야 합니다

JVM의 메모리 구조

JVM 메모리 영역은 주로 사용되는 3가지의 영역이 존재합니다

메서드 영역 (Method Area)

프로그램 실행 중 어떤 클래스가 사용되면 JVM은 해당 클래스파일을 읽고 분석하여 클래스에 대한 정보(클래스 데이터)를 이곳에 저장합니다 → 동적 바인딩
클래스 변수들이 생성되는 공간입니다

힙 (Heap)

프로그램이 실행 중 생성되는 모든 인스턴스는 이곳에 저장합니다
인스턴스 변수들이 생성되는 공간입니다

호출 스택 (Call stack)

메서드 작업에 필요한 메모리 공간을 제공합니다
메서드 작업이 끝나면 할당되었던 메모리공간은 반환되어 비어집니다
- 이 특징으로 인해 메서드 내부의 지역변수는 메서드 외부에서 사용하지 못합니다
지역 변수(매개변수 포함)들이 생성되는 공간입니다

프로그램 실행 시 호출 스택(Call stack) 흐름

호출 스택은 이름 그대로 자료구조 중 하나인 Stack 구조를 따라갑니다

아래 예시의 main 메서드 호출을 통해 흐름을 따라가보겠습니다

public class CallStackTest{

    public static void main(String[] args) { // 시작
        firstMethod();
    }

    private static void firstMethod() {
        secondMethod();
    }

    private static void secondMethod() {
        System.out.println("secondMethod()");
    }
}

실행 순서: main - firstMethod - secondMethod - println
메서드 실행 흐름대로 호출 스택의 과정을 담은 사진입니다

기본형 매개변수 vs 참조형 매개변수

매개변수	특징	이유
기본형 매개변수	변수의 값을 읽기만 할 수 있다 (read only)	기본형 값이 복사
참조형 매개변수	변수의 값을 읽고 변경할 수 있다 (read & write)	인스턴스(객체)의 주소가 복사

기본형 매개변수

// 기본형 매개변수는 값을 복사하기 때문에 변경이 불가능하다

public static void main(String[] args) {

    int num = 10;
    System.out.println("A: " + num);    // A: 10
    change100(10);
    System.out.println("C: " + num);    // C: 10
}

private static void change100(int num) {
    num = 1000;
    System.out.println("B: " + num);    // B: 1000
}

참조형 매개변수

// 인스턴스나 배열같은 참조형 매개변수는 주소값을 공유한다
// 따라서 메서드 안에서 변경한 값이 메서드 밖에서도 변경된 값으로 출력된다

class Data {
    int num;
}

public class Study {

    public static void main(String[] args) {

        Data d = new Data();
        d.num = 10;

        System.out.println("A: " + d.num);   // A: 10
        change100(d);    // Data 인스턴스 자체를 넘긴다
        System.out.println("C: " + d.num);    // C: 1000
    }

    private static void change100(Data data) {
        d.num = 1000;
        System.out.println("B: " + d.num);    // B: 1000
    }

그렇다면 Java는 Call by Reference?

위의 참조형 매개변수로 값을 전달하는 경우 데이터의 값이 변경되면 원본도 변경되어 Call by Reference라고 착각할 수도 있습니다

과연 Java는 Call by Reference일까요?

Java에서는 Call by Value만 존재합니다

위의 예시처럼 change100(d)를 넣는다면 d의 주소값이 복사되어 매개변수 data에 넣어줍니다.

"d의 주소값이 복사된다" 즉, 원본 데이터가 바뀌어서 Call by Reference 처럼 동작을 하여 오해하기 쉽지만
객체의 주소값을 복사하기 때문에 Call by Value 입니다

재귀호출(recursive call)

메서드의 내부에서 메서드 자신을 다시 호출하는 방식입니다
호출된 메서드는 ‘값에 의한 호출(call by value)’을 통해 원래의 값이 아닌 복사된 값으로 작업하기 때문에 독립적인 작업수행이 가능합니다 → 호출한 메서드와 호출당한 메서드는 서로 관련이 없습니다
재귀호출을 탈출할 수 있는 조건문이 필수입니다 → 탈출 조건이 없다면 무한루프가 돌아서 Stack Overflow Error 발생
재귀호출의 대부분은 반복문으로 작성하는 것이 가능하며, 반복문 보다 몇가지 과정(매개변수 복사, 종류 후 복귀할 주소 저장 등등)이 추가로 필요하여 수행시간이 오래 걸립니다

그렇다면 재귀호출을 왜 사용할까?

재귀호출이 주는 논리적 간결함 때문입니다
몇겹의 반복문과 조건문을 재귀호출로 사용하면 단순한 구조로 바뀔 수도 있습니다

// 재귀호출 사용에 대표적인 예는 Factorial 입니다

public static void main(String[] args) {

    int result = factorial(4);
    System.out.println(result);
    
}

static int factorial (int n) {
    int result = 0;

    if (n == 1) {
        result = 1;
    } else {
        result = n * factorial(n - 1);  // 메서드 자신을 다시 호출한다.
    }
    return result;
}

하지만 재귀 호출은 for문에 비해 비효율적이므로 재귀 호출에 드는 비용보다 재귀 호출이 주는 논리적 간결함의 이득이 충분히 큰 경우에만 사용하여야 합니다

클래스 메서드 vs 인스턴스 메서드

변수와 동일하게 메서드 앞에 static이 붙어있으면 클래스 메서드, 붙어있지 않으면 인스턴스 메서드입니다
또한 동일하게 클래스 메서드는 객체(인스턴스)를 생성하지 않고도 호출이 가능합니다
- 클래스이름.메서드이름(매개변수)
인스턴스 메서드는 반드시 객체를 생성하여 참조변수를 통해 호출해야 합니다

클래스 참조변수 = new 클래스();
참조변수.메서드이름(매개변수);

클래스 메서드 (static 메서드)

인스턴스 변수나 인스턴스 메서드를 사용하지 않는 메서드인 경우 클래스 메서드로 정의합니다
물론 인스턴스 변수를 사용하지 않는다고 무조건 클래스 메서드(static)로 정의할 필요는 없지만 특별한 이유가 없으면 일반적으로는 클래스 메서드로 정의합니다
- 책 내용과는 별개로 실무에서는 static 메서드와 static 변수를 지양하여야 한다고 합니다
  - 인스턴스 메서드가 아닐 시 캡슐화에 위배
  - static은 메모리 회수 불가
  - static 메서드는 오버라이딩 불가
  - static 메서드는 인터페이스 구현 시 사용 불가
  - 따라서 static은 모든 객체지향적 기능들의 사용을 방해하는 요소라고 합니다

인스턴스 메서드

메서드 내 인스턴스 변수를 필요로 하는 메서드일 경우 인스턴스 메서드로 정의해야 합니다
- 인스턴스 변수는 인스턴스 생성 후 사용이 가능하기 때문입니다

어느 상황에서 뭘 선언하지?

클래스의 멤버변수 중 모든 인스턴스에 “공통된 값을 유지” 해야 한다면 static을 붙여줍니다 (클래스 변수)
메서드 중 자주 사용되고, 공통적으로 사용되어야 하는 메서드에는 static을 붙여줍니다 (클래스 메서드)
또한 메서드 중 인스턴스 변수, 인스턴스 메서드를 사용하지 않는 메서드에는 static을 붙여줍니다 (클래스 메서드)
- ex) 매개변수로만 작업을 수행하는 경우에는 클래스 메서드(static)
- 클래스 메서드는 클래스가 메모리에 로딩될 때 이미 같이 메모리에 할당되므로 바로 사용이 가능합니다
- 하지만 인스턴스 메서드는 실행 시 호출되어야 할 메서드를 찾는 시간이 추가적으로 발생하므로 클래스 메서드가 효율적입니다
나머지 상황에 경우는 모두 인스턴스 메서드를 선언해야 합니다

마무리

해당 주제에서는 중요한 내용들이 많았던 것 같습니다

참조형 매개변수에서는 원본 데이터가 바뀌므로 Call by Reference로 착각을 했지만, 사실 Java에서는 Call by Value만 있더군요

또한 책 내용과는 다르게 실무에서는 객체지향적인 기능들을 방해하는 static의 사용을 지양하는 것을 새로 알아가는 것 같습니다

static의 남용은 프로그램의 상태를 추정하기 어렵게 만들며 객체지향적이지 않으므로 앞으로는 static의 사용을 자제해야 할 것 같습니다

감사합니다 :)

자료가 도움이 되셨다면 Backend Wiki로 놀러 오세요!

Reference

잘못된 내용이나, 보충할 내용이 있다면 언제든지 편하게 연락 주시면 감사하겠습니다 :)

‍♂️ Call me
Email : dev.gibeom@gmail.com
KakaoTalk : https://open.kakao.com/me/beomdrive

객체 지향, 그 속으로

기범_Alex — Tue, 6 Sep 2022 02:34:52 +0900

백엔드 관련 자료는 Backend Wiki에서 PR을 통해 검증과 내용 보완을 거친 후 블로그로 이관되고 있습니다 :)

객체 지향 이론 기본 개념

객체 지향 프로그래밍 = 실제 세계를 컴퓨터 속에 옮겨 놓기
1. 실제 사물의 속성과 기능을 분석
2. 데이터(변수)와 함수로 정의
3. 필요한 사물끼리 연결
실제 세계는 사물(객체)로 이루어져 있으며, 발생하는 모든 사건들은 사물 간의 상호작용입니다
OOP (캡슐화, 상속, 추상화, 다형성) 개념을 중심으로 점차 구체적으로 발전되었습니다

객체 지향 언어란?

기존의 프로그래밍 언어(절차적 언어)에서 몇 가지 새로운 규칙을 추가한 언어입니다
코드의 재사용성이 높고 유지보수가 용이하며, 중복 코드 제거할 수 있는 특징이 있습니다

객체 지향 언어 주요 특징

코드의 재사용성이 높습니다
- 새로운 코드를 작성할 때 기존의 코드를 이용하여 쉽게 작성할 수 있습니다
코드의 관리가 용이합니다
- 코드 간의 관계를 이용해서 적은 노력으로 쉽게 코드를 변경할 수 있습니다
신뢰성이 높은 프로그래밍을 가능하게 합니다
- 제어자, 메서드를 이용하여 데이터를 보호하고 올바른 값을 유지하도록 합니다
- 코드의 중복을 제거하여 코드의 불일치로 인한 오동작을 방지합니다

객체 지향 프로그래밍 특징 - OOP

객체 지향 프로그래밍의 4대 특징을 간단하게 알아보겠습니다

캡슐화 (Encapsulation)

공통된 데이터와 데이터를 활용하는 함수끼리 캡슐(Class) 안에 두는 것
- 즉 개념 혹은 논리적으로 연관된 데이터(변수)와 함수를 하나의 클래스에 캡슐화하는 것을 의미합니다
클래스 안에서는 표시할 속성(public 변수)와 숨길 속성(private 변수)을 선택할 수 있습니다

특징	설명
데이터 캡슐화	필드와 메서드를 하나로 묶는 것
은닉화	외부에 드러나게 하지 않기를 원하는 데이터를 감추어(private) 외부에서 데이터를 직접 접근하는 것을 방지

class TV {
      int channel;
      // 가격은 getPrice()를 통해서만 가져갈 수 있다 -> 직접 접근 불가
      private int price;
      String color;

      void channelUp() {
          this.channel++;
      }

      public int getPrice() {
          return price;
      }

      public void setColor(String color) {
          this.color = color;
      }
}

상속 (Inheritance)

부모 클래스의 특징과 기능을 자식 클래스에게 물려주는 것
코드를 더 작은 단위로 Class를 쪼개면서 재사용을 할 수 있습니다
공통적인 요소를 합쳐 중복 코드를 제거할 수 있습니다
부모 클래스 수정 시 모든 자식 클래스도 일괄 수정되는 특징이 있습니다

class Entrepreneur {
    String firstName;
    String lastName;
    private int shares;
    private String company;
}

class Actor {
    String firstName;
    String lastName;
    private int oscars;
    private int age;
}

// firstName과 lastName이 공통적으로 사용되는 멤버이다 -> 상속
// ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

class Person {
    String firstName;
    String lastName;
}

class Entrepreneur extends Person {
    private int shares;
    private String company;
}

class Actor extends Person {
    private int oscars;
    private int age;
}

추상화 (Abstraction)

구현 세부 정보를 숨기고 일반 인터페이스를 지정하는 행위
세부 사항(구현부)의 수정이 일어난다 하더라도 해당 메서드를 사용하는 다른 어느 곳에서도 수정을 할 필요가 없습니다

  예시를 들어보자

자동차에는 엑셀, 브레이크, 핸들, 버튼 등 다양한 인터페이스가 존재한다

우리는 아래와 같이 알 수 있다
엑셀: 차가 움직인다
브레이크: 차가 멈춘다
핸들: 차의 방향을 조절한다
버튼: 각각의 기능이 있다

하지만 구현 세부정보는 각 제조사마다 다르지만 우리는 몰라도 차를 운전하는데 전혀 지장이 없다.
따라서 인터페이스는 구현체 내부에서 어떻게 돌아가는지 몰라도 원하는 기능을 사용하는데 문제가 없다는 특징이 있다

다형성 (Polymorphism)

여러 개의 형태를 갖고 있는 것
즉 변수 혹은 메서드가 상황에 따라 다른 결과가 나옵니다
- 오버로딩과 오버라이딩을 통해 해당 내용이 가능합니다
메서드가 어떻게 작동해야 되는지에 대한 최소한의 규칙이 정해져 있습니다 (return 타입 등)
- 메서드의 핵심은 보존하면서 구현 방식의 모양과 모습만 다르게 구현할 수 있는 방법입니다

class Person {
    public String sayHi() {
        return "ㅎㅇ";
    }

    public String sayBye() {
        return "ㅂㅂ";
    }
}

class 한국인 extends Person {
}

class Italian extends Person {
    @Override
    public String sayHi() { // 오버라이딩
        return "Hi!";
    }
}

public static void main(String[] args) {

    한국인 한국인1 = new 한국인();
    한국인1.sayHi(); // 출력값: ㅎㅇ
    
    Italian italian1 = new Italian();
    italian1.sayHi(); // 출력값: Hi!
}

이처럼 한국인 객체의 sayHi()와 Italian 객체의 sayHi()의 결과가 다른 것을 볼 수 있습니다

객체란?

객체는 ‘실제로 존재하는 것’ 으로써 우리 주변에서 볼 수 있는 모든 사물들이 곧 객체라고 볼 수 있습니다
개념이나 논리 같은 무형적인 것들도 포함됩니다
프로그래밍 관점 → 클래스에 정의된 내용대로 메모리에 객체가 생성됨
객체 = 속성(변수) + 기능(메서드)

객체	설명
객체의 정의	실제로 존재하는 것, 사물 또는 개념
객체의 용도	객체가 가지고 있는 기능과 속성에 따라 다름
유형의 객체	책상, 의자, 모니터 등과 같은 사물
무형의 객체	수학공식, 프로그램 에러와 같은 논리나 개념

클래스란?

객체를 정의해놓은 것 → 객체의 설계도 또는 틀이라고 정의

객체	클래스
제품	제품 설계도
TV	TV 설계도
붕어빵	붕어빵 기계

클래스는 객체를 생성하는 데 사용됩니다
- 자동차라는 객체가 필요하다고 가정해봅시다
- 프로그래밍에서는 클래스를 먼저 작성한 후, 클래스로부터 객체를 생성하여 사용해야 합니다!

1. 자동차라는 클래스를 작성합니다 (설계도)

class Car {
     ....
}

2. 자동차라는 클래스를 통해 객체를 생성합니다 (인스턴스화)

Car car= new Car();

클래스는 서로 관련된 변수들을 정의하고 이들에 대한 작업을 수행하는 함수들을 함께 정의한 것입니다
클래스가 곧 사용자 정의 타입입니다 (기본 자료형 외) - (ex. VO, DTO)

객체와 인스턴스

객체와 인스턴스는 같은 의미이다! -> 따라서 문맥에 따라 구별하여 사용하면 됩니다

  예시를 들어보자

차 인스턴스다 x -> 차 객체다 o
차는 차 클래스의 객체이다 x -> 차는 차 클래스의 인스턴스이다 O

클래스 —— (인스턴스화) ——> 인스턴스(객체)

클래스로부터 객체를 만드는 과정 → 클래스의 인스턴스화
A 클래스로부터 만들어진 객체 → A 클래스의 인스턴스

// 클래스의 객체를 생성 -> 객체의 주소를 참조변수에 저장
클래스명 변수명 = new 클래스명();

Class Human { ... }

// new를 통해 Human 인스턴스 생성 -> gibeom이라는 참조변수에 Human 인스턴스의 주소 저장
Human gibeom = new Human();

참조 변수 vs 인스턴스

인스턴스는 오직 참조 변수를 통해서만 다룰 수 있고, 참조 변수의 타입과 인스턴스의 타입은 당연히 일치해야 합니다
하나의 인스턴스를 여러 개의 참조 변수가 가리키는 경우가 가능합니다
- 아래 예시에서 gibeom2에 생성된 인스턴스는 gibeom1과 gibeom2이 동시에 가리키고 있습니다

Human gibeom1 = new Human();
Human gibeom2 = new Human();
gibeom1 = gibeom2   // 참조변수 gibeom1한테 gibeom2의 주소값을 부여

// gibeom1의 본래 주소값은 garbage collector에 의해 메모리 반환

여러 인스턴스를 하나의 참조 변수가 가리키는 경우는 불가능합니다
- 위 예시의 gibeom1처럼 덮어씌워집니다

객체의 구성 요소

객체는 속성과 기능의 집합입니다
객체가 가지고 있는 속성과 기능을 그 객체의 멤버(구성원, member)라고 합니다

구성 요소	명칭
속성 (property)	멤버 변수, 특성(attribute), 필드(field), 상태(state)
기능 (function)	메서드, 함수, 행위(behavior)

속성과 기능에 대한 예시 (TV)

속성	기능
크기, 길이, 높이, 무게, 색상, 볼륨, 채널 등	켜기, 끄기, 볼륨 높이기 낮추기, 채널 변경하기 등
채널 → int channel;	채널 변경하기 → channelUp() { … }

같은 클래스 안의 멤버일지라도, 각 인스턴스의 속성(멤버변수)은 독립적으로 서로 다른 값을 유지합니다 → 서로 다른 객체 주소 값을 참조
메서드의 행위는 모든 인스턴스에 대해 동일하게 동작합니다 (오버라이딩한 경우 제외)

Class Human {
	String gender;
	int age;

	void increaseAge()  { ++age; }
}

Class HumanTest {
	Human gibeom = new Human();
	Human beom = new Human();
	
	gibeom.increaseAge()

// 속성중에 하나인 멤버변수 age는 각 인스턴스마다 서로 다른 값을 유지
// 하지만 increaseAge 같은 메서드 동작 자체는 모든 인스턴스에서 동일하게 작동
	System.out.println(gibeom.age); // 1
	System.out.println(beom.age); // 0
}

객체 배열

객체의 주소를 배열에 저장 → 즉 참조 변수들을 하나로 묵은 참조 변수의 배열

Human[] humanArr = {new Human(), new Human(), new Human()}

마무리

자바를 다시 공부하면서 객체, 클래스, 인스턴스, 참조 변수 등의 용어가 헷갈렸었던 것들이 재정비가 되는 느낌입니다

객체지향의 뿌리는 절차적 언어에서 시작됐다는 내용은 흥미로운 것 같네요

OOP의 캡!상추다 에 대해서도 다시 한번 상기시키며 개발을 할 때 참고해서 코드를 구성해야 될 것 같습니다

감사합니다 :)

자료가 도움이 되셨다면 Backend Wiki로 놀러 오세요!

Reference

잘못된 내용이나, 보충할 내용이 있다면 언제든지 편하게 연락 주시면 감사하겠습니다 :)

‍♂️ Call me
Email : dev.gibeom@gmail.com
KakaoTalk : https://open.kakao.com/me/beomdrive

소개

기범_Alex — Wed, 17 Aug 2022 02:11:12 +0900

블로그 이전중입니다.... Coming Soon!

InfluxDB - (3) 데이터 백업(backup) 및 복구(restore)

기범_Alex — Sat, 4 Jun 2022 15:04:35 +0900

나는 데이터베이스 특성상 중요한 데이터는 미리 백업을 주기적으로 받아놓곤 한다
데이터가 날아가는 최악의 상황에서의 유일한 빛이랄까...

이번 글에서는 이전 글에서 열심히 데이터를 만들고 지우고 수정하고 하며 생긴 많은 데이터들을
백업 및 복구하는 방법을 알아볼까 한다
시작해보자!

Data Backup

Load Data Backup

Influxd backup -portable -database {데이터베이스명} {경로}
해당 데이터베이스를 경로 디렉토리에 백업 (디렉토리가 없을 시 자동 생성함)

influxd backup -portable -database exemDB C:\Users\beom\Downloads\influxBackup

나는 C:\Users\beom\Downloads\influxBackup 폴더 경로에
exemDB라는 데이터베이스를 백업해보겠다

해당 경로 폴더

Data Restore

위에서 exemDB의 데이터베이스를 백업하였으니 복구를 위해 데이터를 다 날려버리자!

1. measurement 삭제 진행

drop measurement 테이블명

drop measurement soccer

2. 데이터베이스 삭제 진행

drop database 데이터베이스명

drop database exemDB

3. 데이터베이스 복구 (restore)

influxd restore -portable -db {데이터베이스명} {백업폴더경로}
해당 백업폴더 경로에 있는 데이터 압축파일을 influxdb에 import 진행

influxd restore -portable -db exemDB C:\Users\beom\Downloads\influxBackup

아래 사진을 보면 influx 내 exemDB가 복구된 것을 볼 수 있다

Influx 내 데이터베이스 중 회사에서 쓰이는

데이터베이스가 있으므로 해당 부분은 가리겠습니다

이처럼 InfluxDB 데이터의 백업과 복구는 이런 식으로 하면 될 것 같습니다
저한테 데이터 백업은 보험 같은 느낌이라서 나는 중요한 상황일 때마다 습관적으로 데이터를 백업하는 것 같네요

InfluxDB를 자세하게 파고들면 무궁무진한 활용 방법이 있고 Grafana 모니터링 시스템도 구축할 수 있습니다
지금까지 맛보기 정도로만 빠르게 훑어보았습니다
추후에는 SpringBoot 환경에 InfluxDB 사용하기, InfluxDB+Grafana를 활용한 모니터링 시스템도 만들어 볼 생각입니다

이번 글은 여기에서 마치고 InfluxDB에 대해서는 추후에 다시 돌아오겠습니다!
감사합니다 :)

InfluxDB - (2) CRud 사용법(InfluxQL)

기범_Alex — Fri, 3 Jun 2022 19:56:20 +0900

이번 글에서는 InfluxQL을 통한 InfluxDB의 CR-ud 쿼리를 직접 사용해보겠다
Influx 쿼리는 어떻게 사용하는 것일까..
그 속으로 들어가 보자!

Data Format

InfluxDB 쿼리를 사용하기 전에 Line protocol에 대해서 알아보자

Line protocol

Measurement, Tag set Field set timestamp
- 첫 번째는 항상 Measurement가 와야 함
- Tag set과 Field set 은 key=value 형태로 구성되며 여러 개일 경우 쉼표(,)로 구분한다
- timestamp는 생략이 가능하다 (생략 시 데이터 삽입 기준 시간이 들어감)
하나의 행
- point라 부른다
- line protocol 형식으로 구성되어있다
- 개행(줄 바꿈)으로 구분

Line protocol 구성

예시 1)

soccer,name=son,team=tot city="london",age=28 151178300000000000

measurement	soccer
tag (only string type)	name, team
field (모든 타입 가능, string type인 경우 “ “ 로 구분한다)	city, age
timestamp (생략가능, 생략 시 데이터 삽입 시점 시간이 들어감)	151178300000000000

예시 2)

bank, company=woowaBro color="mint", year=2024

measurement	bank
tag (only string type)	company
field (모든 타입 가능, string type인 경우 “ “ 로 구분한다)	color, year

Data Load

schemaless

Influx 내 데이터베이스 중 회사에서 쓰이는

데이터베이스가 있으므로 해당 부분은 가리겠습니다

대부분의 DB와 다르게 Mesurement(Table)를 따로 생성하지 않고 바로 insert 가능
- Measurement 존재 x → Measurement 생성 뒤 데이터가 저장
- Measurement 존재 o → 바로 데이터 저장
timestamp는 생략 가능, 생략 시 데이터가 저장되는 시점의 시간으로 저장

InfluxDB를 CR-ud로 표현하는 이유는 시계열 데이터베이스는 쓰기(C), 읽기(R)에 특화되어 있다.
따라서 수정(u)과 삭제(d)를 권장하지 않는 데이터베이스이다.
하지만 실제 실무에서는 무궁무진한 상황이 발생하기 마련이다..

자 이제 진짜 Line protocol을 활용한 InfluxQL로 CR-ud를 "모두" 사용해보자!

Influx Query

1. 데이터 삽입 (insert)

insert mesurement,tagSet fieldSet timestamp
tag 혹은 field 가 여러 개일 경우 쉼표로 구분
tag → field 넘어갈 때 공백으로 구분

insert soccer,name=son,team=tot city="london",age=28 151178300000000000

쉼표 간의 띄어쓰기를 할시 아래와 같이 오류가 발생한다!

2. measurement 내 tag key 확인 (indexing 컬럼)

show tag keys on “데이터베이스” from “measurement”

show tag keys on "exemDB" from "soccer"

3. measurement 내 field key 조회 (non-indexing 컬럼)

show field keys on “데이터베이스” from “measurement”

show field keys on "exemDB" from "soccer"

4. 데이터 조회 (select)

RDB 쿼리와 동일

select * from soccer

5. 데이터 삭제 (delete)

delete from measurement명 where tag키 = ‘tag값’

delete from soccer where team = 'brazil'

6. 데이터 수정 (update)

InfluxDB는 업데이트 쿼리를 따로 지원하지 않는다!!
단 수정할 데이터의 timestamp를 가져와서 그대로 insert 하면 덮어씌워진다
※ 주의 - tag set의 값은 동일한 상태에서만 field 값 수정만 가능

1. 정상적인 수정

해당 timestamp를 그대로 가져와 쿼리 맨 마지막에 세팅
field인 city 값과 age 값을 변경
key인 name과 team은 그대로 같은 값으로 세팅

2. 비정상적인 수정 → 새로운 데이터 삽입

해당 timestamp를 그대로 가져와 쿼리 맨 마지막에 세팅
tag 값인 name을 beom → beom97로 변경
field 값인 age 값 변경

이처럼 InfluxDB는 읽기와 쓰기에 특화되어 있어 update는 insert를 통해 덮어 씌우는 방식으로 사용이 가능합니다
CRUD를 모두 해봄으로써 기존 RDB(MariaDB) 쿼리와 유사하며, Line protocol 방식만 추가된 것처럼 느껴집니다

다음 글에서는 InfluxDB 데이터의 백업, 복구에 대해서 다뤄보도록 하겠습니다!
감사합니다 :)

InfluxDB - (1) 시계열 데이터베이스란?

기범_Alex — Fri, 3 Jun 2022 00:55:00 +0900

최근에 회사에서 InfluxDB를 활용한 개발을 하게 되었다
InfluxDB? 시계열 데이터베이스? 처음 접해보는 기술이다..
그 속으로 들어가 보자!

시계열 데이터베이스란?

시간 처리에 최적화된 데이터 베이스
SQL 기반 시계열 질의 지원
빠른 데이터 입력
트랜잭션 지원 및 데이터 변경이 불가
롤업 기능 지원

RDB vs 시계열 데이터베이스

RDBMS	InfluxDB
Database	Database
Table	Measurement
Rows	Points
PK or Indexed columns	Tags (String만 가능)
Unindexed columns	Fields

여기까지 봤을 땐 긴가민가하다..
자주 사용하는 RDB(MariaDB)랑 비슷한 감이 있고 용어만 달라지는 느낌이 든다
직접 사용해보자!

Influx 설치

다운로드 페이지 : https://portal.influxdata.com/downloads/
파일 구성

influxd.exe	influx.exe
influx 서버	influx 클라이언트

❗ 윈도우 cmd 창에서 바로 접근을 원할 시 환경변수 세팅 (InfluxDB window path)
시스템 환경변수 편집 → 환경 변수 → 시스템 변수 → Path → 편집 → 새로 만들기 → influx 폴더 경로를 집어넣고 저장

환경변수 세팅 후 influxd.exe를 실행 후 cmd 창에서 influx 타이핑 결과

자 이제 InfluxDB를 써볼 준비는 끝났다
이번 글에서는 InfluxDB를 간단하게만 사용해보자

InfluxQL(CRUD) 쿼리를 보고 싶다면 다음 글로 바로 가면 될 것 같다!

Influx 사용

내용 중 {}은 괄호 안의 값을 대입하라는 의미입니다
ex) use {데이터베이스 이름} → use _internal

1. 데이터베이스 조회

현재 influxDB에 데이터베이스를 조회한다.
기본으로 _internal이라는 데이터베이스가 존재하는 것 같다.

show database

2. 데이터베이스 선택

사용할 데이터베이스를 선택한다.
use {데이터베이스 이름}

use _internal

3. measurement 조회

선택한 데이터베이스 내의 measurement(table) 조회한다.

show measurements

4. 데이터 조회 (select) 문

일반 RDB 쿼리와 동일한 것으로 보임
시계열 데이터베이스 특성상 select 쿼리 실행 시 timestamp가 자동으로 같이 조회됨

select HeapIdle, NumGC from runtime limit 3;

5. InfluxDB 종료

quit

exit

6. InfluxDB 실행 시 옵션 추가

데이터 조회(select) 시 읽기 쉬운 형태의 시간(timestamp)이 표현된다.

influx -precision rfc3339

7. 데이터베이스 생성

create database {DB 명}

create database test_beom

Influx 내 데이터베이스 중 회사에서 쓰이는 데이터베이스가 있으므로 해당 부분은 가리겠습니다

이번 글은 여기까지만 작성해보려고 합니다
다음 글은 InfluxQL(CRUD)에 대해서 다뤄보도록 하겠습니다!
감사합니다 :)

CORS, 그 속으로

기범_Alex — Sun, 13 Feb 2022 16:21:12 +0900

CORS Error는 왜 발생할까?

웹 개발을 하다 보면 아래와 같은 에러를 심심치 않게 마주칠 수 있습니다
- Access to XMLHttpRequest at '주소 A' from origin '주소 B' has been blocked by CORS policy:
  No 'Access-Control-Allow-Origin' header is present on the requested resource.

CORS Error는 동일 출처 정책(SOP: Same-Origin Policy)에 의해서 브라우저가 발생시키는 에러입니다
- CORS는 SOP를 피하기(허용) 위한 수단이다!

SOP란 무엇일까? (Same-Origin Policy: 동일 출처 정책)

대부분의 웹 브라우저는 SOP라는 보안 정책을 준수합니다
SOP는 한 Origin(내가 현재 접속해 있는 사이트)에서 로드된 문서나 스크립트가 다른 Origin(다른 사이트)에서 가져온 리소스와 상호 작용하는 것을 제한하는 보안 방식입니다
말 그대로 같은 출처에서만 리소스를 공유할 수 있다 라는 규칙을 가진 정책입니다

이미지 출처: https://evan-moon.github.io/2020/05/21/about-cors/

SOP는 왜 만들어졌을까?

웹에서 돌아가는 클라이언트 애플리케이션은 사용자의 공격에 너무나도 취약합니다
당장 F12 개발자 도구만 켜도 소스코드가 적나라하게 드러나며, 어떤 서버와 어떻게 통신하는지에 대한 각종 정보들을 무리 없이 열람할 수 있습니다
만약 SOP 정책이 없다면 서로 다른 두 애플리케이션이 마음대로 소통할 수 있는 환경이 됩니다
이 말은 즉슨 다른 출처의 애플리케이션에서 악의적인 목적으로 사용자의 정보를 탈취하기가 너무나도 쉬워진다는 겁니다
따라서 같은 출처에서만 리소스를 공유할 수 있다는 규칙(SOP)을 default로 하여 어느 정도의 보안적인 이점을 가져갈 수 있습니다

출처(Origin) 란?

위 설명에서 출처(Origin)라는 말이 계속 나오고 있습니다
출처는 Protocol + Host+ Port 의 쌍을 말합니다
즉 URL의 맨 앞 3개의 요소인 프로토콜, 호스트, 포트번호가 동일하다면 같은 출처라고 판단하여
SOP(동일 출처 정책)에 가로막히지 않습니다

용어	조건
Same Origin (동일 출처)	Protocol, Host, Port 모두 일치
Cross Origin (다른 출처, 교차 출처)	Protocol, Host, Port 중 하나라도 다를 시

이미지 출처: [10분 테코톡] 나붐의 CORS (https://youtu.be/-2TgkKYmJt4?t=62)

참고

IE(Internet Explorer)에서는 SOP(동일 출처 정책) 기준에 두 가지 예외사항이 있습니다
하지만 IE는 거의 사용되지 않는 브라우저이므로 해당 예외사항은 알고만 있으면 될 것 같습니다

1. 신뢰할 수 있는 사이트

양쪽 도메인 모두 “높음” 단계의 보안 수준을 가지고 있을 경우 두 출처가 다르더라도 SOP에 가로막히지 않습니다

2. 포트

같은 출처라고 판단하는 기준에서 포트를 포함하지 않습니다
따라서 IE에서는 Protocol + Host만 동일하다면 같은 출처로 판단합니다

CORS란? (Cross-Origin Resource Sharing: 교차 출처 리소스 공유)

시대가 발전하면서 많은 애플리케이션들은 내부적으로만 동작하기보다 다양한 다른 애플리케이션과 상호 작용하면서 사용자들에게 더욱 편리한 서비스를 제공합니다
즉 서로 다른 출처끼리 리소스를 공유해야 하는 상황이 발생합니다
CORS란 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다
즉 정해진 헤더를 통해 다른 출처의 리소스 자원을 공유할 수 있는 방법입니다

CORS는 어떻게 동작할까?

다시 상기하자면 CORS Error는 브라우저에서 발생시키는 오류입니다

기본적인 CORS Error의 발생 과정은 다음과 같습니다

1. HTTP 요청을 하면 브라우저는 요청 헤더에 Origin이라는 필드를 추가합니다

Origin : 요청을 보낸 출처 (ex. https://github.com/giibeom)

2. 이후 서버는 응답을 내려줄 때 응답 헤더에 access-control-allow-origin 라는 필드를 내려줍니다

access-control-allow-origin : 해당 리소스를 접근할 수 있게 허용된 출처 (ex. access-control-allow-origin: *)
모든 출처를 허용한다는 와일드카드 : *

3. 브라우저는 응답을 반환하기 전에 Origin과 access-control-allow-origin 값을 비교하여 응답의 유효성을 검증합니다

즉 요청에 대한 응답을 서버가 내려준 후, 브라우저 단에서 판단하여 응답을 그대로 반환할지 버릴지 판단하는 것입니다

CORS 접근제어 시나리오

위의 예시같이 브라우저에서는 요청과 응답을 통해 본 요청이 유효한 지 판단하는 메커니즘을 갖고 있습니다

해당 메커니즘, 즉 CORS의 접근제어 시나리오는 대표적으로 3가지의 시나리오로 나뉩니다

1. 프리플라이트 요청 (Preflight Request)

2. 단순 요청 (Simple Request)

3. 인증정보 포함 요청 (Credentialed Request)

1. 프리플라이트 요청 (Preflight Request)

프리플라이트 방식은 본 요청 전 사전 작업으로 예비 요청을 먼저 서버에 보내는 방식입니다
예비 요청을 보냄으로써 현재 출처가 자원을 요청할 서버에 리소스를 요청할 수 있는지를 판단하여
이 요청이 유효한지를 확인합니다
- 예비 요청을 프리플라이트(Preflight)라고 부르는 것이며 HTTP 메서드 중 OPTIONS 라는 메서드를 사용합니다
예비 요청을 통해 본 요청이 유효하다고 판단되면 실제 본 요청을 전송합니다

Preflight 동작 흐름

1. 클라이언트에서 다른 출처에 리소스 자원을 요청합니다

2. 브라우저에서는 본 요청을 잠시 대기시켜놓고 예비 요청을 보낼 준비를 합니다

3. 예비 요청은 OPTIONS 메서드를 사용하며 요청 헤더에는 아래와 같은 정보를 담습니다

Origin : 요청 출처
Access-Control-Request-Method : 실제 요청의 메서드
Access-Control-Request-Headers : 실제 요청의 추가 헤더

4. 예비 요청을 받은 서버는 현재 자신이 어떤 것들을 허용하고 있는지에 대한 정보들을 응답 헤더를 통해 반환합니다

예비 요청(Preflight Request)의 응답은 코드는 200, 바디는 비어있는 것이 좋습니다
Access-Control-Allow-Origin : 서버 측 허가 출처
Access-Control-Allow-Methods : 서버 측 허가 메서드
Access-Control-Allow-Headers : 서버 측 허가 헤더
Access-Control-Max-Age : Preflight 응답 캐시 기간
- 프리플라이트(Preflight Request) 방식은 매 요청마다 2개의 요청을 보내는 셈이 됩니다
- 따라서 Access-Control-Max-Age는 효율적으로 리소스를 관리해주기 위해 필요한 값입니다
- 브라우저는 Access-Control-Max-Age 값 기준으로 캐싱을 하여, 캐시 기간 내에는 해당 출처에 대한 모든 요청에 대해서 Preflight Request를 진행하지 않고 바로 본 요청을 진행합니다

이미지 출처: https://evan-moon.github.io/2020/05/21/about-cors/#preflight-request

브라우저는 리소스 효율 때문에 캐시까지 사용해가며 예비 요청(Preflight Request)을 하는 이유가 뭘까?

CORS spec이 생기기 이전에 만들어진 서버는 브라우저의 SOP 보안 정책으로 인해 같은 출처에서만 요청이 가능하다는 가정하에 개발되었습니다
이 말은 즉슨 이전에 만들어진 서버들은 Cross-Origin(교차 출처, 다른 출처)에서의 접근에 대한 보안 메커니즘이 존재하지 않습니다
만약 Preflight가 없고 CORS에 대응도 안 되는 서버일 경우에는 다음과 같은 문제가 있을 수 있습니다

1. 다른 출처에서 DB의 DELETE가 발생하는 요청을 합니다
2. CORS의 설정이 없기 때문에 서버 측 허가 출처인 Access-Control-Allow-Origin 이 존재하지 않습니다
3. 하지만 Preflight가 없이 다이렉트로 서버에 꽂힌 요청은 서버에서 모든 동작이 완료된 후, 결과 반환 직전에 브라우저에서 CORS Error를 뱉습니다
4. 뒤늦게 브라우저는 CORS Error를 뱉지만 실제 서버에서는 DB 삭제가 진행되었습니다

따라서 이러한 상황을 방지하고자 CORS 설정이 안 되어 있는 서버들을 보호하기 위해 CORS spec에
예비 요청(preflight request)을 포함시켰다고 합니다

예시

아래는 www.google.com 에서 제 블로그로 리소스 요청을 전송하였고, 브라우저가 자동으로 진행한 예비 요청(Preflight Request)의 예시입니다

예비 요청 응답 코드가 200으로 떨어지는 이유는, CORS 에러가 발생하는 시점은 서버의 CORS 허용 정보들을 반환한 다음에 일어나고 실제 예비 요청 자체는 성공하기 때문입니다
예시 내 응답 헤더에 있는 Access-Control-Allow-Origin과 요청 헤더에 있는 Origin이 서로 다르기 때문에, 예시 아래의 콘솔창과 같이 CORS 에러가 발생하는 것을 볼 수 있습니다

2. 단순 요청 (Simple Request)

단순 요청 방식은 Preflight 요청 없이 바로 다이렉트로 서버에 요청을 꽂아 넣는 방식입니다
- 위에서 간단하게 설명했던 CORS Error의 발생 과정과 동일하다고 보면 될 것 같습니다
  (CORS는 어떻게 동작할까?)
리소스 자원을 서버로 바로 요청할 경우 서버는 요청 데이터와 함께 Access-Control-Allow-Origin 값을 반환해줍니다
브라우저에서는 응답을 반환하기 전 응답 데이터에 있는 Access-Control-Allow-Origin 와 Request 시 보냈던 Origin을 판별하여 응답의 여부를 결정합니다

하지만 단순 요청 (Simple Request) 방식이 일어나는 상황은 아래와 같은 조건을 “모두” 충족할 때 일어납니다

1. 요청의 메서드는 GET, HEAD, POST 중 하나여야 합니다

2. Content-Type 에서는 3가지만 허용됩니다

application/x-www-form-urlencoded
multipart/form-data
text/plain

3. 요청 헤더에는 해당 값들만 허용됩니다

Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width

사실상 3가지의 조건이 모두 충족하기란 쉽지 않습니다 (2, 3 때문에)

2번이 충족되기 어려운 이유는 최근 주로 사용되는 Content-Type은 application/json이 많이 사용되기 때문입니다
3번이 충족되기 어려운 이유는 보통 최근의 토큰 인증 방식으로 헤더에 Authorization 를 많이 세팅하기 때문입니다

3. 인증정보를 포함한 요청 (Credentialed Request)

Credentialed Request 방식은 인증된 요청을 사용하는 방식입니다
즉 다른 출처의 리소스 자원을 요청할 때 인증과 관련된 정보(쿠키)를 헤더에 포함시키고 싶을 때 사용하는 방식입니다
- 브라우저는 기본적으로 HTTP 통신 시 자동으로 쿠키를 헤더에 포함시켜주지만,
  JavaScript를 사용해 만든 교차 출처 요청에는 Cookie를 헤더에 기본적으로 포함시키지 않습니다 (Not-Default)

해당 방식은 클라이언트와 서버 양쪽에서의 설정이 필요합니다

클라이언트

credentials : 요청에 인증과 관련된 정보를 담을 수 있게 하는 옵션

옵션 값	동작 설명
same-origin (기본 값)	같은 출처 간 요청에만 인증 정보를 담을 수 있습니다
include	모든 요청에 인증 정보를 담을 수 있습니다
omit	모든 요청에 인증 정보를 담지 않습니다

예시를 들어보자

fetch('서버주소', {
    credentials: 'include',
});

만약 credentials 옵션에서 omit을 제외한 나머지 옵션(same-origin, include)을 설정하게 되면
브라우저는 기존에 진행했던 Origin <-> Access-Control-Allow-Origin 비교 외에도 추가적인 검사를 진행합니다

서버

클라이언트에서 credentials 설정을 하였다면 두 가지의 설정을 하여야 합니다

1. 응답 헤더에 Access-Control-Allow-Credentials: true 를 반환해야 합니다

2. 모든 출처를 허가하겠다는 Access-Control-Allow-Origin: *을 설정할 수 없습니다

와일드카드가 아닌 명시적인 URL을 설정해주어야 합니다

CORS Error를 해결하는 방법은 뭘까?

지금까지는 CORS에 대한 전반적인 개념과 CORS의 동작 방식 및 시나리오에 대해서 알아봤습니다
이젠 CORS를 잘 사용하여 합법적(?)으로 다른 출처의 리소스 자원을 사용하는 방법에 대해서 알아보겠습니다

CORS Error를 해결하는 방법은 크게 3가지가 있습니다

1. 서버에서 "Access-Control-Allow-Origin" 설정해주기 (정석)

2. 프론트 프록시 서버 설정을 변경해주기

3. CORS 기능 끄기 (로컬 개발 시 급할 때만 쓰자!)

1. 서버에서 Access-Control-Allow-Origin 설정해주기

Spring 기준으로 서버에서 CORS 관련 설정하는 방법은 크게 두 가지가 존재합니다

1. @Configuration 설정 방법

2. @CrossOrigin 설정 방법

1. @Configuration 설정 방법

해당 방식은 Configuration 어노테이션을 통해 전역으로 처리하는 방법입니다

// 전역적으로 CORS 설정을 할 수 있는 방법
@Configuration
public class CorsFilter implements WebMvcConfigurer { // WebMvcConfigurer 구현
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api") // 적용할 path 패턴을 입력
                .allowedOrigins("http://localhost:8081") // 허가할 출처들을 기입
                .allowedMethods(    // 허가할 메서드를 기입
                        HttpMethod.GET.name,
                        HttpMethod.POST.name,
                        HttpMethod.PUT.name,
                        HttpMethod.DELETE.name
                );
    }
}

2. @CrossOrigin 설정 방법

해당 방식은 모든 도메인이 아닌 특정 도메인에서만 허용할 때 사용하는 방식입니다
CORS 설정을 적용시킬 Class 혹은 Method 위에 @CrossOrigin 어노테이션을 붙이면 됩니다

@RestController
@RequiredArgsConstructor
@RequestMapping("/api")
@CrossOrigin(origins = {"http://localhost:3000", "http://localhost:8080"}, allowCredentials = "true")
public class MemberController {

    @GetMapping("/hello")
    public String Hello() {
        return "hello";
    }
}

하지만 위 방식은 각각의 Class 혹은 Method 마다 선언해줘야 하므로 보통은 1번 방식을 많이 사용합니다

2. 프론트 프록시 서버에서 설정해주기

프론트 프록시 서버에서 백엔드 서버 간의 출처를 조율해줍니다
브라우저와 프론트 프록시 서버는 출처가 동일하므로 CORS Error가 발생하지 않습니다

이미지 출처: [10분 테코톡] 나붐의 CORS (https://youtu.be/-2TgkKYmJt4?t=62)

3. CORS 기능 끄기 (로컬 개발 시 급할 때만 쓰자!)

보안 때문에 프록시와 같은 외부 서버도 못 띄우는 상황이거나, 서버의 설정을 기다릴 수 없이 당장 핫픽스 같은 개발을 진행해야 될 때 사용하면 유용합니다

근본적인 해결이 될 때까지 임시적으로 사용하는 방법입니다! → 광고 아닙니다.....

방법은 아래와 같습니다

1. Chrome 웹스토어에 들어갑니다 → https://chrome.google.com/webstore

2. CORS를 검색합니다

3. CORS를 허용하게끔 도와주는 확장 프로그램을 다운로드합니다

아래는 현재 제가 사용 중인 프로그램입니다

마무리

실무에서 CORS 에러를 겪고 나서 제대로 정리하고 싶어서 공부해보았습니다

처음에는 CORS 에러가 "CORS" 때문에 에러가 난다고 생각했지만, 알고 보니 SOP 정책 때문에 에러가 나는 것이고 CORS는 이 SOP 정책을 합법적(?)으로 사용하게 도와주는 방법이더군요 :)

보통 실무에서는 Spring에 이미 CORS 허용 설정이 되어있겠지만, 제 경우에는 Spring 모듈과의 통신이 아닌 contents 서버와의 자원(파일) 공유 중 CORS 에러를 맞닥뜨린 경험이 있어 Port를 맞춰줌으로써 문제를 해결했었던 기억이 있네요!

마지막으로 본 글과는 별개로 CORS의 전반적인 역사와 근본적인 내용이 담긴 블로그 글이 있길래 소개 드리면서 마무리하겠습니다 :) → CORS에서 이기는 방법

Reference

잘못된 내용이나, 보충할 내용이 있다면 언제든지 편하게 연락 주시면 감사하겠습니다 :)

‍♂️ Call me
Email : dev.gibeom@gmail.com
KakaoTalk : https://open.kakao.com/me/beomdrive