더이상미룰수없어

[Spring/MagicCrypto] 매직크립토 버전 2.0 > 2.3 버전업 배포 가이드

물고기고기 — Wed, 19 Mar 2025 19:41:18 +0900

현재 개발 환경은 Jdk 1.6& 1.8이며, 제우스 컨테이너로 스프링 서비스를 올린다.
암호화 모듈인 매직크립토를 2.0에서 2.3으로 버전업하는 상황이다.

native library 호출 경로에 맞춰 dll 파일을 옮겨놓는다.
- 확인해본 결과 테스트 서버에선 라이브러리 경로가 전역에 설정되어있는 PATH가 아닌 제우스 컨테이너가 참조중인 java.library.path에서 dll을 불러오기에 해당 위치에 넣어준다.
  보통 C:/TmaxSoft/JEUS6.0/lib/system에 위치한다.
dll 파일을 우선 옮긴 후 v2.3과 호환되는 배포패키지를 배포한다.
- 매직크립토 구현체와 암호화 변수가 동일한지 확인해줘야한다.

[제우스, 웹투비] NextJs가 제우스로 올린 Spring Boot를 호출하지 못할때

물고기고기 — Wed, 19 Mar 2025 19:34:58 +0900

✔ 개요

톰캣으로 띄우면 요청이 가는데 제우스로하면 연결이 안간다.
curl로도 요청이 되고 포스트맨으로도 요청이 되는 상황이지만 nextJs로 제우스 컨테이너로 호출하면 500에러가 떴다.

✔ 원인 파악

제우스 라이브러리인 ehcache-scf-replication-jar-with-dependencies.jar가 스프링의 Hibernate Validator와 충돌나서 Hibernate Validator와 연관된 라이브러리인 jboss-logging도 제대로 호출되지 않는 문제가 생겼다.

✔ 문제가 됐던 라이브러리 및 코드

에러메세지는 였는데 error라고 크게 안써져있어서 우선 해당 클래스에서 문제가 난걸 파악하는게 오래걸렸다.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

로깅이 안되는데 왜 요청이 안가느냐? 서비스로직으로 요청이 인입되기 전 로깅 클래스를 불러오는데 오류가 있으니 exception이 떨어지고 서비스로직으로 요청 자체가 안간것이다.
심지어 로깅이 안되니 어디서 exception이 나는지도 원인파악이 어려웠다.

WEB-INF/jeus-web.xml

Logback 먼저 호출

<jeus-web-app>
    <class-loader>
        <prefer-web-inf-classes>true</prefer-web-inf-classes>
    </class-loader>
</jeus-web-app>

JEUS SLF4J 라이브러리 삭제
라이브러리 확인

ls -al $JEUS_HOME/lib/system
ls -al $JEUS_HOME/lib/ext

로그 관련 라이브러리 삭제 또는 이동

mv $JEUS_HOME/lib/system/slf4j-api*.jar $JEUS_HOME/lib/system/slf4j-api.bak
mv $JEUS_HOME/lib/system/logback-classic*.jar $JEUS_HOME/lib/system/logback-classic.bak
mv $JEUS_HOME/lib/system/logback-core*.jar $JEUS_HOME/lib/system/logback-core.bak

✔ 더 생각해볼점

근데 왜 curl과 postman호출은 됐던걸까? 이건 아직 파악이 안된다.

[NHN FORWARD 22] DDD 뭣이 중헌디? 요약

물고기고기 — Wed, 5 Feb 2025 21:01:43 +0900

회사에서 한창 리팩토링중하면서 패키지 구조를 바꿀일이 있어 DDD가 뭔지 찾아보다가ㅎㅎ.. 좋은 영상을 발견해 간단히 정리하면서 봤다.

https://www.youtube.com/watch?v=6w7SQ_1aJ0A

DDD

전략적 설계 : 좀 큰 설계, 큰그림 > 얘가 본질임
전술적 설계 : 지엽적, 구체적인 도메인 모델 설계
DDD는 비즈니스 도메인 요소가 약한 서비스에 어울리지 않는다.
MSA와 세트가 아니다
얘는 구체적인 방법론이 아니다. 추상적인 철학이랑 접근법에 가까움 > 전략적 설계에 근간을 두고있음

그래서 전략적 설계가 뭔데?

비즈니스 도메인에서 소프트웨어를 통해 해결하고자하는 문제가 문제 도메인이다.
보통 문제도메인은 방대한 복잡성을 갖는 경우가 많음.
이러한 문제공간을 해결공간으로 바꾸는게 전략적 설계의 큰 흐름

도메인

영역 집합
비즈니스 도메인 + 문제 도메인을 말함
소프트웨어로 어떤 문제를 해결해서 가치를 창출하느냐?가 문제의 시작인 셈(예를 들어 티켓팅이 비즈니스 도메인이면 예메서비스가 문제도메인이 될수도 있는 셈)

문제 공간

문제를 해결해서 새로운 가치를 창출 > DDD의 진입점
그러기 위해서는 문제 도메인을 하위 도메인으로 나누는것부터 시작해야함
여기서 쓰이는 도메인들을 도메인전문가와 함께 쪼개야함
- 그리고 가장 중요하고 복잡한 핵심을 구분해야함
- 핵심 - 지원 - 일반으로 하위 도메인을 구분할 것
- 중요한것과 중요하지 않은것을 나눠야함
- 제일 중요한 부분에 리소스 투자를 해야함 > 이런건 인하우스 개발을 할 것

해결 공간

해결 공간에서의 지식탐구는 개발자가 해야함
해결 영역에서는 개발단계의 설계가 생각됨
문제 공간에서 도메인을 구분한것처럼 다시 하위 도메인을 구분지어야함

Big Ball of Mud

특별한 구조가 없는 아키텍처 스타일
딱히 안티패턴은 아님.. 그냥 전술 중 하나

하지만 이로인해 복잡성이 높아질때 브라운 필드 전략적 설계

브라운필드 소프트웨어 = 이미 구축된 소프트웨어

전략적 설계시 유용한 도구

사용사례 분석
이벤트 스토밍 : bottom up 분석
비즈니스 모델 분석

언제 어디서나 도메인 문맥내에서 유비쿼터스 언어로 소통한다.

전략적 설계 vs 전술적 설계

전략적 설계 과정 > 문제 공간에서 해결 공간으로 가야함. 어떻게?

Bounded-Context

경계가 있는 문맥
해결공간에서 모델의 경계
Bounded-Context가 달라지면 유비쿼터스 언어도 달라진다.
모델의 무결성을 위한 경계(무슨얘기?)
모델이 모호해지는 순간 모델의 무결성을 지키기 위함

모델이 무결성의 예시

이름은 같은 다른 개념이 등장할때 > Bounded-Context로 경계를 나눠주면 모호해지지 않는다.
예를 들어 회원 도메인에서의 Account와 은행에서의 Account는 다른 개념이듯이
또다른 예시, 동일한 개념이지만 여러 문맥에 의존하는 개념이 있을 수 있다.
예매에서의 Product, 정산에서의 Product는 전부 물품에 대한 얘기가 맞다.
이때의 Product모델이 모든 컨텍스트에서 만족하려면 복잡하고 커질 수 있다.
컨텍스트별로 필요한 기능을 수행하는 모델이면 충분하다. (예매에선 예매가 가능한지만 알면되고.. 등등)> 해결할 문제를 위한 속성, 행위만 있으면 된다.

Bounded-Context와 하위 도메인

Bounded-Context과 하위도메인은 일종의 집합 관계가 된다.
해결공간을 찾을땐 다양한 상황이 나온다.
Bounded-Context가 여러개의 하위도메인을 가질수도있고, Bounded-Context별로 하위도메인이 여러개일수도있다.
레거시가 주로 여러개의 Bounded-Context에 하나의 하위도메인인경우고 트렌드는 반대다.
해결공간에서 각 Bounded-Context별로 전술을 선택하는것도 중요하다.
핵심 도메인을 선정하고 거기에 모든 리소스를 쏟아부어야하니까 전술선택이 중요하다.

콘웨이의 법칙

DDD한다고 다 해결되나?
사실 소프트웨어 구조는 그거 개발하는 회사 구조 따라감..
개발하는 조직 구조를 소프트웨어 구조에 맞춰야한다.

Bounded-Context 매핑관계

기술적으로 최선의 선택을 할 수 있으면 좋겠지만 조직,정치,도메인 상황을 종합적으로 고려해서 판단한다.

Context-Map

해결공간을 표현하는 산출물
현재의 상태여야함

BBOM에서 진화하는 설계

레거시에서 하위 도메인들을 식별한다.
스파게티 코드안에 도메인 지식이 많이 숨겨져있고, 이때는 도메인 전문가도 없는 상황.
보통은 일반이나 지원 도메인(회원 기능등..)부터 분리한다. (핵심은 분리하기 어렵다.)
DDD로 고도화 > 이때 제대로된 컨텍스트맵이 나오기 시작한다.
전술적 패턴선택, 핵심 컨텍스트를 뜯어낸다.(상황별로 여러개일수있다)
상황에 따라 지원 도메인이 핵심 도메인으로 승격되기도 한다.

결론, 세상의 모든것은 변한다. 수시로 변하는 비즈니스 상황을 맞춰가며 소프트웨어 개선이 지속되어야한다.

요약

DDD는 일종의 접근법이자 철학이다.
DDD에선 전략적 설계가 중요하다.
커뮤니케이션을 기반으로 지식탐구하고, 지식을 정제하자!
언제어디서나 유비쿼터스 언어로 설계하자.(긴밀하게 커뮤니케이션하자)

volatile 변수는 원자성을 보장할까?

물고기고기 — Sun, 29 Dec 2024 16:24:02 +0900

+) 이펙티브 자바 스터디를하면서 volatile 변수에 대해 공부할일이 있어 짬짬히 적어보았다.

java 변수들은 물리적으로 어디에 저장될까?

레지스터

CPU 내부에 있는 빠른 메모리
컴파일러는 최적화를 수행할때 자주 사용되는 변수를 레지스터에 보관
스레드마다 CPU 레지스터는 독립적으로 동작, 스레드간의 직접 공유가 안된다. (동기화 문제의 원인)

메인 메모리

대부분의 변수 여기에 저장
모든 스레드가 공유하는 물리적 메모리 공간
CPU 캐시와 레지스터는 메인 메모리로부터 데이터를 가져오거나 씀

CPU 캐시

계산할때 어딘가 값을 넣어야하니까.. 그 용도

자바 메모리 모델 JMM

자바 메모리 모델에 따르면 한 스레드에서 변경한 값이 다른 스레드에게 보이려면 동기화를 하거나, volatile 메커니즘을 써야한다. -> 레지스터에 있는 값은 스레드간 직접 공유가 안되기 때문에
동기화 이슈 = 레지스터와 메인 메모리 간의 동기화가 제대로 안되면 스레드 마다 서로 다른 값을 본다.

동기화 = 배타락? 배타적으로 막는다? 동기화할동안에는 접근하고 있는 스레드 말곤 아무도 못쓴다! 독점한다.
그래서 volatile을 쓰게되면 메모리이기때문에 스레드가 막 가져다 쓸 수 있는거임

그럼 volatile은 어떻게 가시성을 보장하느냐?

volatile = 휘발성, 메인 메모리에 직접 읽고 쓰는 것을 보장한다. 특정 스레드가 값을 수정하면 해당 값이 즉시 메모리에 반영되고 스레드간의 최신 값을 공유한다고 보는거다.

volatile이 원자성을 보장하지 않는다?

원자성이란 한번에 완전히 수행되고, 쪼개지지 않는 연산을 말한다.
스레드가 어떠한 로직을 수행하고 있을때 다른 스레드가 이를 방해하지 못하는 것도 원자성이 보장된다고 한다.

원자성은 세가지 특징이 있다.

불가분성 = 연산이 시작되면 다른 연산이 끼어들 수 없는것
중단 불가능성 = 중간에 중간되거나, 중간 상태가 노출되지 않는것
일관성 보장 = 원자적 연산이 보장되면 여러 스레드가 동시에 연산을 수행해도 데이터가 일관적이어야 한다.

원자성은 기본원자성과 복합연산 원자성이라는게 있다.

volatile은 이때 기본 원자성만 보장한다. 단일 읽기&쓰기 수준에서의 원자성은 지원한다.
volatile int x; x = 5; 또는 int temp = x; 같은 단일 연산은 중간에 끼어들 틈 없이 수행된다.
하지만 i++ 같이 연산 자체가 한번의 메모리 접근이 아니라면 volatile 은 원자성을 보장해주지 않는다.

이럴때는 동기화(synchronization)나 원자적 클래스(예: AtomicInteger)는 복합 연산의 원자성을 보장해주면 된다.

내 개인적인 의견으로

volatile이 원자성을 보장해준다. -> 정확히는 틀린말이라고 본다. volatile은 가시성만을 보장해주고 특정 데이터타입(int,boolean등)에서의 단일 연산은 해당 데이터타입의 기본원자성이 보장되기때문애 volatile의 가시성과 합쳐져 동기화가 된다. 라고만 볼 수 있을 것같다.

2024 상반기 CJ 올리브 네트웍스 데이터 엔지니어 채용 전형 후기

물고기고기 — Sun, 12 May 2024 17:50:06 +0900

상반기 글인데 올리는건 8월중이다.. 그간 회사 생활하느라 바빴으므로..
비공개글을 이번에 공개해봅니당

CJ올리브네트웍스 DBE 직무에 지원했는데 코테를 붙었다(두둥..)
신입 DBE를 뽑는것도 신기한데 DB파트 코딩테스트를 본다고해서 더 신기했다.

일단 서류

서류는 그냥 자기소개서를 이번 분기에만 몇십개를 써봐서 물흐르듯 작성했다. 이전 이력이 몇개 있어서 수월하게 작성했다.
신입같은 경우 자기소개서가 정말 중요하다. 본인 이력을 정리를 잘해놓고 관심있는 도메인과 관련된 기사들을 자주 찾아보는걸 추천한다.

나는 평소 이것저것 알아보려는 호기심이 많은 편이라 잡지식이 많아 자기소개를 적는데 어려움은 없었다.(물론 질리긴한다)

대망의 테스트 전형

직무가 DBE여서 그런가 일반 알고리즘 테스트가 아닌 SQL쿼리 + DB 관련 객관식 테스트를 프로그래머스로 봤다.
DBE 직무인 만큼 쿼리 튜닝이나 실행계획에 대한 문제나 난이도가 있는 쿼리를 작성하라고 할줄알고 프로그래머스에서 레벨4~5짜리 쿼리문제만 냅다 풀었는데..

쿼리 짜는건 프로그래머스 레벨2~3사이 수준의 문제가 2문제정도 나왔다.. 적어서 놀램 한 4개정도는 짜라고 할줄알았는데
객관식문제는 20문제 정도 나왔고 난이도는 SQLD 정도의 문제가 나왔다.

튜닝스텝(설계패턴) ,SDLC, Interactive SQL ,Embedded SQL ,세미조인 이런 개념들도 나왔는데 이 부분이 그나마 생소했다.(SQLD에 있던 개념이었을지도~)

추천 공부방법 이랄건없고 SQLD 개념정리를 좀 하고 쿼리를 평소 잘 못짜는 편이라면 프로그래머스 레벨3~4문제들 전부 풀어보고 가는걸 추천한다.

저는 그냥 다 풀어보긴했어요

직무 면접 & 토론 면접

문제가 좀 평이한듯해서 다 맞은사람도 있을거라 붙을거라고 생각 못했는데 붙었다. 붙은거보자마자 눈알튀어나옴
그 이후에 직무면접 30분, 토론면접 60분 전형이 2차전형으로 있다. 참고로 온라인으로 진행했다. (이 점은 매우 칭찬~)

토론 면접이 처음이라 사실 너무 막막하고? 뭘 물어볼지 감도 안오고.. 여튼 그랬는데 막상 가보니까 대비할 필요가 전혀 없는 전형이다..
정말 말그대로 토론을 함.. 토론 실력은 하루이틀한다고 느는것도 아니니 적극성을 보여주면 어필이 되지않을까 생각한다.

토론 내용은 자세히는 알려주지 못하지만 결국 CJ올리브 네트웍스와 관련해서 토론하라고 한다.
엄청나게 큰 배경지식이 필요하진 않고 그냥 근래에 CJ올리브 네트웍스가 주력하고 있는 사업이 뭔지 같은것들만 간단히 찾아보면 좋았을듯하다.(사실 이건 자기소개서 쓸때 다들 찾아보니까)

직무면접은 내가 이전 경력이 있어서 그런가 아카데믹한 질문보단 인성면접이 주였다. 한분께서 나의 단점을 여러번 지적해서 기죽었지만, 다른 면접관분께서 분위기를 잘 풀어주셔서 평이하게 진행됐다.

기억에 남는 질문은 데이터엔지니어가 뭐하는 직업이냐는 질문이었다. DBA나 일반 백엔드 개발자와 해당 직무가 정확히 뭐가 다른지 고민해보고 가는게 중요할듯하다.

임원 면접

직무면접에 합격할거라고 생각 못했는데 합격했다..!

그런데 사실 이당시에.. 이미 가고 싶은 회사에 붙어서 임원면접임에도 조금 안일하게 준비했다.
임원면접이라 인성질문만 할 줄 알았는데 생각보다 기술적인 질문도 했고 아주 약간의 압박면접도 있었다.

대부분의 임원면접이 비슷하지만 자기 이력서를 달달 외고 가야한다. 자기 이력서에서 나올만한 모든 질문에 대해 방어할 줄 알아야한다.

나는 내 이력들이 대부분 백엔드 서버 개발쪽과 관련되어있어 그런가 왜 백엔드 개발직무가 아닌 DBE를 지원했냐고 물었을때 확실하게 답변하지 못했던 게 아쉽다.

그럼에도 좋았던 점은 면접비도 주고 CJ라 그런지 간식도 빠방하게 주셨다.(역시 대기업~!)

최종

물론 취준 막바지기도하고 이미 가고싶은 회사에 붙어서 제대로 준비안해그런가 임원면접에서 떨어졌다.
좀 속이 쓰리긴하지만 되려 내가 정말 데이터 엔지니어 직무가 하고싶은지 고민해보는 계기가 됐다.

이번 취준은 이걸로 끝! 다른분들은 좋은 기회가 있길 바라며ㅎㅎ

[Flask/APScheduler] 순환 참조로 인한 초기화 오류 해결

물고기고기 — Fri, 1 Mar 2024 01:36:08 +0900

주기적으로 요청해야하는 프로그램이 있어 스케쥴러 프로그램을 작성했더니 (flask)

from apscheduler.schedulers.background import BackgroundScheduler
from flask import Flask

from .batch import check_not_answer_question
from .database import db
from . import config
from sqlalchemy import text

from .routes import routes_bp

global_api_key = config.API_KEY


def create_app():
    app = Flask(__name__)

    app.config['SQLALCHEMY_DATABASE_URI'] = config.DATABASE_URI
    app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False

    db.init_app(app)

    # 데이터베이스 연결 테스트
    with app.app_context():
        try:
            # 데이터베이스 엔진으로부터 커넥션을 얻고 SELECT 1을 실행
            with db.engine.connect() as connection:
                result = connection.execute(text("SELECT 1"))
                for row in result:
                    print("Connection test returned:", row[0])
                print("Database connected successfully.")
        except Exception as e:
            print("Failed to connect to database.")
            print(e)

    # 라우트 등록
    from . import routes

    # 스케쥴러 등록
    scheduler = BackgroundScheduler()
    scheduler.add_job(func=check_not_answer_question, trigger='interval', seconds=10)
    scheduler.start()

    app.register_blueprint(routes_bp)

    return app

스케쥴러에 등록하려는check_not_answer_question 에서 db의 models를 참조하고있기에 아직 app 객체가 생성되기전에 참조하려는 문제가 일어나 아래와같은 오류가 발생했다.

Error: While importing 'app.run', an ImportError was raised:

Traceback (most recent call last):
  File "D:\py\tmt-ai-server\venv\lib\site-packages\flask\cli.py", line 247, in locate_app
    __import__(module_name)
  File "D:\py\tmt-ai-server\app\__init__.py", line 4, in <module>
    from .batch import check_not_answer_question
  File "D:\py\tmt-ai-server\app\batch.py", line 3, in <module>
    from app.models import JobApplicationQuestions, UserJobApplicationInfo
  File "D:\py\tmt-ai-server\app\models.py", line 3, in <module>
    from . import db
ImportError: cannot import name 'db' from partially initialized module 'app' (most likely due to a circular import) (D:\py\tmt-ai-server\app\__init__.py)


Process finished with exit code 2

python도 자주쓰는 언어가 아니고 flask도 어떻게 코드를 설계하는지 몰라 설계를 대충했더니 생긴 문제다..
import문의 위치도 바꿔주고 지연참조로 수정해주니 배치가 실행된다.

from apscheduler.schedulers.background import BackgroundScheduler
from flask import Flask

from .database import db
from . import config
from sqlalchemy import text

from .routes import routes_bp
from .batch import check_not_answer_question

global_api_key = config.API_KEY


def create_app():
    app = Flask(__name__)

    app.config['SQLALCHEMY_DATABASE_URI'] = config.DATABASE_URI
    app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False

    db.init_app(app)

    # 데이터베이스 연결 테스트
    with app.app_context():
        try:
            # 데이터베이스 엔진으로부터 커넥션을 얻고 SELECT 1을 실행
            with db.engine.connect() as connection:
                result = connection.execute(text("SELECT 1"))
                for row in result:
                    print("Connection test returned:", row[0])
                print("Database connected successfully.")
        except Exception as e:
            print("Failed to connect to database.")
            print(e)

    # 라우트 등록
    from . import routes

    app.register_blueprint(routes_bp)

    # 스케쥴러 설정 및 작업 등록을 위한 함수 정의
    def setup_scheduler():
        scheduler = BackgroundScheduler()
        # app_context를 사용하여 함수 내에서 애플리케이션 컨텍스트를 사용
        def job_function():
            with app.app_context():
                from .batch import check_not_answer_question
                check_not_answer_question()

        scheduler.add_job(func=check_not_answer_question, trigger='interval', seconds=10)
        scheduler.start()

    # 애플리케이션 컨텍스트가 설정된 후에 스케쥴러 설정
    setup_scheduler()

    return app

이제 물론 배치에서도 또다른 에러가 나긴하지만.. 하나를 해결한데에 의의를 두자

-- 답변되지 않은 값들을 확인 후 답변 요청하는 배치 프로그램 실행 --
-- 유저확인 중 --
배치 작업 중 오류 발생: Working outside of application context.

This typically means that you attempted to use functionality that needed
the current application. To solve this, set up an application context
with app.app_context(). See the documentation for more information.

스케쥴링 코드를 짜는데 너무 알아야할 지식도 많고 그냥 60초마다 실행되는 코드를 짜면안되나했더니 Flask의 개발서버는 보통 싱글스레드로 동작하기에.. app.run()하고 while문으로 실행할시 메인스레드를 계속 차지하여 다른요청을 처리하지 못한다고한다.

-> 하루지난 오늘 해결했다! 결국 파이썬은 flask서버를 켜지않아도 실행가능하기에.. 스케쥴링 코드를 flask 컨텍스트에서 실행되게 해야하는데 이전 코드들은 컨텍스트에서 실행한다는 코드를 넣지않았기에 application context밖에서 실행되고있다는 오류메세지가 뜬거였다.

run.py에 이런식으로 내가 실행하고자하는 (DB관련된 스케쥴링 코드) 함수를 app.app_context()에서 실행할거라고 작성하면 app의 context에서 실행된다.

# run.py
from flask_apscheduler import APScheduler

from app import create_app
from app.batch import check_not_answer_question


class Config:
    SCHEDULER_API_ENABLED = True


app = create_app()
app.config.from_object(Config())

scheduler = APScheduler()
scheduler.init_app(app)
scheduler.start()


# 스케쥴러 작업 정의
@scheduler.task('interval', id='schedule_1', seconds=5, misfire_grace_time=900)
def schedule_1():
    # 5초 단위로 실행하니까 이후에 단위 수정필요
    with app.app_context():  # 애플리케이션 컨텍스트 설정
        print("Schedule Function is executed.")
        check_not_answer_question()


if __name__ == '__main__':
    app.run()

잘 실행된다!

[기술면접대비] 5. 자료구조&알고리즘

물고기고기 — Mon, 29 Jan 2024 15:07:44 +0900

자료구조

선형 자료구조

배열 : 정해진 크기만큼 데이터가 일렬로 저장되는 정적 자료구조 → 접근,검색,삽입,삭제 가능

연결리스트 : 크기가 정해져 있지 않은 동적 자료구조, 헤드 포인터와 테일 포인터로 시작과 끝을 알 수 있음 → 검색, 삽입, 삭제 가능

스택 : LIFO(후입선출) → 맨 위에 삽입, 가장 위에있는 데이터 삭제 및 확인, 비어있는지 확인, 가득찼는지 확인 모두 O(1)

큐 : FIFO(선입선출) → 맨뒤에 데이터 삽입, 맨앞에 데이터 삭제, 비어있는지 찼는지 확인, 맨 위에 있는 데이터 확인 모두 O(1)

시간복잡도/ 데이터구조	배열	연결리스트	스택	큐
접근	O(1)	X	X	X
검색	O(n)	O(n)	X	X
삽입	O(n)	O(1) + O(n)→ 그러나 삽입 위치까지 가는데 O(n)이 걸림	O(1) → 맨 위에만	O(1) → 맨 위에만
삭제	O(n)	O(1) + O(n) → 얘도	O(1) → 맨 위에만	O(1) → 맨 위에만

+) 연결리스트는 인덱스로 접근이 가능할까요? No

연결 리스트는 추가나 삭제에 시간복잡도가 O(1)이지만 탐색하는데 매번 O(n)이 들어서 일반 배열을 쓰는데에 비해 이점이 없는것같은데 어떤상황에 쓰는거야?
1. 동적 크기 조정: 배열은 고정된 크기를 가지지만, 연결 리스트는 런타임에 요소를 추가하거나 제거하면서 크기를 동적으로 조정할 수 있습니다. 이는 메모리를 보다 효율적으로 관리할 수 있게 해줍니다.
2. 효율적인 요소 삽입 및 삭제: 연결 리스트에서는 특정 위치에 요소를 삽입하거나 삭제하는 작업이 O(1) 시간복잡도로 매우 빠릅니다. 물론 이를 위해서는 해당 위치에 접근하는 데 추가 시간이 필요합니다. 반면, 배열에서 요소를 삽입하거나 삭제할 때는 다른 요소들을 이동시켜야 하므로 더 많은 시간이 소요됩니다.
3. 메모리 할당: 연결 리스트는 각 요소가 메모리의 연속적인 블록에 저장될 필요가 없습니다. 이는 메모리 단편화를 줄이는 데 도움이 됩니다. 배열은 연속적인 메모리 공간이 필요하므로 큰 배열을 생성할 때 메모리 할당이 어려울 수 있습니다.
연결 리스트가 유용한 상황은 다음과 같습니다:
- 리스트의 크기가 빈번하게 변경될 때: 요소가 자주 추가되거나 삭제되는 경우, 연결 리스트는 배열보다 성능적으로 유리합니다.
- 메모리 제약이 있는 환경: 연결 리스트는 필요한 만큼의 메모리만 할당하므로 메모리가 제한적인 상황에서 효과적입니다.
- 데이터 삽입/삭제 위치가 미리 알려진 경우: 삽입/삭제할 위치가 미리 알려져 있고, 그 위치에 빠르게 접근할 수 있는 경우(예를 들어, 리스트의 시작이나 끝에서 작업할 때) 연결 리스트는 매우 효율적입니다.
하지만 탐색이 주된 작업인 경우, 배열이 연결 리스트보다 더 나은 성능을 보일 수 있습니다.
연결 리스트(linked list)는 특정 상황에서 배열(array)보다 유리한 점이 있습니다. 연결 리스트의 주요 이점은 다음과 같습니다:

비선형 자료구조

1:N , N:N 구조로 데이터가 나열되는 자료구조. 데이터를 하나하나 탐색하지 않아도 찾을 수 있음

그래프

정점(노드) , 간선 → G = (V,E)라고도 표현 사이클 : 한 정점에서 시작해 같은 정점으로 돌아올 수 있는 경로

무방향 그래프 : 간선에 방향성 X 그래프, 이때 (A,B)와 (B,A)는 동일한 간선 취급, 정점 n개 일때 간선 최대 개수 n*(n-1) / 2
방향 그래프 : 간선에 방향성 O, <A,B>와 <B,A>는 다른 간선 취급, 정점 n개 일때 간선 최대 개수 n*(n-1)

경로 탐색

그래프가 주어졌을때 경로를 탐색하는 방법 두가지

너비 우선탐색(BFS) 탐색을 시작하는 정점에서 가까운 정점을 먼저 탐색하는 방식, 먼저 발견한 정점에서 인접한 정점들을 탐색하며 큐에 삽입, 이때 탐색한 정점에 재방문하지 않도록 탐색한 정점을 따로 체크해둬야한다 → 이러한 방식으로 정점에서 정점까지 최단 거리를 알 수 있음
깊이 우선탐색(DFS) 시작 정점에서 탐색 가능한 최대 깊이의 정점까지 탐색함 최대 깊이인 정점에 도달했다면 방문한 정점들을 역순으로 재방문, 재귀 호출 또는 스택으로 구현, 최대 깊이까지 탐색 완료시 스택에 있는 정점 하나씩 꺼내며 추가로 방문가능 정점 확인 → 백트래킹????

트리

그래프의 한 종류, 사이클이 없어서 계층적 관계를 표현 가능

이진 트리 : 자식 노드가 최대 2개인 트리

완전 이진 트리 : 트리의 마지막 레벨을 제외하고 모든 레벨 노드가 채워져 있음, 왼 → 오 순으로 채움
포화 이진 트리 : 마지막 레벨까지 노드가 모두 채워져 있는 이진 트리(= 완전 이진 트리와 같음)
이진 탐색 트리 : 같은 레벨일때 왼쪽 노드는 오른쪽 노드에 비해 값이 작아야함 → 특정 값을 검색할때 O(logN) 소요

우선순위 큐

힙 → 이진 탐색 트리 → 상하의 규칙이 있는 이진탐색트리

해시테이블

→ 검색을 자주 사용하는 풀이 과정에서 해시테이블 사용

해시셋

[’a’, ‘b’, ‘c’] , [1,2,3] → arr

{a:1,b:2,c:3} → 검색 자주해야하는 로직에선 무조건 해시테이블

정렬 알고리즘

비교하는 정렬 알고리즘

버블 정렬 : 한개의 값을 기준으로 잡고 뒤의 값과 비교하며 크기 순으로 정렬 → 시간복잡도 O(n^2), 단 별도의 메모리 공간이 필요하지X
선택 정렬 : 배열을 순회하며 최소값을 찾고 최소값을 맨앞으로 이동시킴 → O(n^2), 메모리공간 X
삽입 정렬 : 특정 인덱스가 제값에 가기위해 이전 정렬된 부분에 자기 위치가 될만한곳에 위치시키는 구조 → O(n^2)
합병 정렬(머지소트) : 배열을 쪼개고, 분할한 배열을 정렬하며 하나로 합병(최소단위인 2에서부터 비교 후 합치고, 4에서 비교후 합치고 하는 방식) → O(n log n) = 배열정렬시간 O(n) + 합치는시간 O(log n)

+) 합병 정렬과 퀵 정렬은 둘다 분할 정복 알고리즘이다

퀵 정렬 : 하나의 피봇을 정해 해당 피봇보다 작은값으로 구성된 배열과 큰값으로 구성된 배열로 분할해 정렬하는 방식 → O(n log n), 최악의 경우 O(n^2)

https://ko.wikipedia.org/wiki/퀵_정렬#/media/파일:Sorting_quicksort_anim.gif

힙 정렬 : 최대 힙, 최소 힙 등 자료구조를 이용한 정렬 → O(n log n)
https://yozm.wishket.com/magazine/detail/2312/

비교하지 않는 정렬

기수 정렬 : 낮은 자릿수부터 정렬 수행(일의 자리수 기준으로 정렬 후 십의자리 수를 기준으로 정렬) , 버킷이라는 큐를 생성하므로 추가 메모리가 필요 → 데이터개수 n, 최대 자릿수 d일때 O(dn) 걸림
계수 정렬 : 데이터 개수를 세서 정렬하는 방식 → O(n+k) → 이해못함 뭐라는겨

최소 신장 트리(MST)

그래프가 이리저리 연결되어있을때 어떻게 연결되어야 가중치가 제일 작고, 모든 정점을 포함하게 할 수 있는지 = 이게 스패닝 트리

즉, 가중치가 있는 그래프에서 간선의 가중치 총합이 가장 작은 신장 트리

프림 알고리즘 : 그리디 알고리즘, 임의의 정점을 시작점으로 트리를 확장하며 MST를 생성 → 힙을 사용

+) 그리디란? 각 단계에서 최선의 선택이 모여 전체의 합이 최선이 되는 알고리즘

앞에서 선택한 결과가 나중의 선택에 영향을 주지 않고
지역적인 문제에 대한 최선의 선택이 전체적인 문제에 대해서도 최적의 선택이되는 문제여야함

→ 그런데 이런 방식이 MST에서 진짜 최적의 해를 보장하나?

사이클 방지: 프림 알고리즘은 이미 선택된 정점들로만 구성된 집합을 확장해 나가기 때문에, 선택된 간선들이 사이클을 형성할 수 없습니다. 즉, 항상 신장 트리의 속성을 유지합니다.
최소 가중치 간선 선택: 각 단계에서 가능한 간선들 중 최소 가중치를 가진 간선을 선택함으로써, 최종적으로 구성된 신장 트리의 총 가중치가 최소가 됩니다.
컷 속성(Cut Property): 프림 알고리즘은 컷 속성을 만족합니다. 컷 속성이란 그래프의 두 부분을 나누는 컷(cut)에 대해, 한 부분에 있는 정점과 다른 부분에 있는 정점을 연결하는 간선들 중 최소 가중치를 가진 간선을 선택하면, 그 간선은 최소 신장 트리에 포함되어야 하는 간선임을 의미합니다.

크루스칼 알고리즘 : 얘도 그리디 알고리즘, 간선을 오름차순으로 정렬한 뒤 가중치가 낮은 간선부터 선택하며 최소 신장 트리를 생성, 특정 간선을 선택했을때 사이클이 생성된다면 연결하지않고 다음으로 가중치가 낮은 간선을 확인함 → 프림 알고리즘과 달리 간선을 기준으로 트리 생성

→ 유니온 파인드 알고리즘 : 2개의 원소가 같은 집합에 속하는지 판단하는 알고리즘, 크루스칼 알고리즘에서는 두 정점을 선택하고 두개가 다른 그래프에 속한다고 판별되면 두 정점을 연결하고 같은 그래프면 연결 안하도록 하는 알고리즘

최단 거리 알고리즘

정점 간 최단 거리를 구하기 위한 알고리즘

특정 정점에서 다른 정점들까지의 최단 거리

다익스트라 알고리즘 : 간선의 가중치가 음수가 아닌 경우 특정 정점에서 다른 정점까지의 최단 거리를 구하는 알고리즘, 시작 정점을 설정하고 방문 가능하면서 비용이 가장 적게 드는 정점에 방문해 비용을 갱신 → 이때 우선순위 큐를 사용하면됨 (우선순위는 거리를 기준으로!)

그러니까 DP스럽게 푼다고 보면됨. 하나의 정점에서 출발해서 다음 정점으로 갔을때 그 다음 정점에서 나머지 노드들을 방문하는 가중치의 합이 이전노드가 직접 방문한 값보다 작다면 가중치의 합 array에 갱신해주면 되는것

벨만 포드 알고리즘 : 가중치가 음수여도 적용할 수 있음, 음의 사이클이 있으면 최소 비용이 무한하게 줄어들어서 알고리즘 적용X

이해못해서.. 나중에 볼것 추가 +) https://www.youtube.com/watch?app=desktop&v=Ppimbaxm8d8

[기술면접대비] 4. 데이터베이스

물고기고기 — Mon, 29 Jan 2024 14:50:28 +0900

데이터베이스

데이터베이스 스키마 종류

내부 스키마 : 사용자 측면의 데이터베이스 전체 구조
개념 스키마 : 데이터베이스 전체구조
외부 스키마 : 물리적 저장 측면에서 구조

관계형 데이터 베이스 VS NoSQL

릴레이션(개념적 모델) = 테이블(실제 구현 개체)
NoSQL은 대용량 데이터 조회시 관계형보다 빠름, 데이터 확장과 대용량 데이터 조회가 빈번히 일어날 때 사용

+) 그렇다면 관계형 DB는 NoSQL에 비해 뭐가좋을까? → 데이터 쿼리와 트랜잭션 지원이 필요한 경우, DB끼리 join을 많이해야하는경우(복잡한 쿼리 사용할때)

+) 수직확장과 수평확장은 뭘까?
- 정의: 수직 확장은 하나의 서버의 성능을 향상시키는 것을 의미합니다. 이는 일반적으로 더 강력한 CPU, 더 많은 RAM, 더 큰 저장 용량과 같이 더 나은 하드웨어로 기존 서버를 업그레이드하는 것을 포함합니다.
- 장점:
  - 관리가 쉽습니다. 하드웨어를 업그레이드하는 것이 전부이기 때문에, 추가적인 서버 관리나 네트워크 구성이 필요하지 않습니다.
  - 데이터베이스 트랜잭션과 같은 복잡한 작업들이 더 효율적으로 처리됩니다. 모든 데이터가 하나의 물리적 위치에 있기 때문에 데이터 일관성을 유지하기가 더 쉽습니다.
- 단점:
  - 비용이 많이 들 수 있습니다. 고성능의 하드웨어는 일반적으로 더 비쌉니다.
  - 확장성에 한계가 있습니다. 하드웨어의 성능은 물리적으로 한계가 있으며, 어느 시점에서 더 이상의 성능 향상이 불가능할 수 있습니다.
수평 확장 (Horizontal Scaling)
- 정의: 수평 확장은 추가적인 서버를 네트워크에 추가함으로써 시스템의 처리 능력을 확장하는 것을 의미합니다. 이는 데이터베이스를 여러 서버에 분산시켜 작업 부하를 분산시키는 것을 포함합니다.
- 장점:
  - 확장성이 높습니다. 필요에 따라 서버를 추가할 수 있으므로 더 많은 트래픽과 데이터를 처리할 수 있습니다.
  - 비용 효율적입니다. 많은 중소규모의 서버를 사용하는 것은 고성능의 단일 서버를 사용하는 것보다 비용이 적게 들 수 있습니다.
- 단점:
  - 관리가 더 복잡해질 수 있습니다. 여러 서버의 네트워크를 유지 관리해야 하며, 서버 간의 일관된 데이터 상태를 유지하는 것이 어려울 수 있습니다.
  - 특정 종류의 작업(예: 조인 연산)이 더 복잡해질 수 있습니다. 데이터가 여러 서버에 분산되어 있기 때문에, 이러한 연산을 수행하는 데 추가적인 오버헤드가 발생할 수 있습니다.
수직 확장 (Vertical Scaling)

결론 :

NoSQL의 장점: 대량의 데이터를 빠르게 수정해야 하거나, 스키마 변경이 빈번할 경우 NoSQL이 더 나은 성능을 보일 수 있습니다.
SQL의 장점: 데이터의 무결성과 정확한 트랜잭션 관리가 중요한 경우, SQL이 더 나은 성능을 제공할 수 있습니다.

관계형 데이터 베이스

키는 유일성(하나의 키로 식별가능한지?)과 최소성(식별하는데 필요한 속성만으로 이루어졌는지?)을 만족해야한다.

슈퍼키 : 튜플을 식별할 수 있지만 최소성 만족 X
후보키 : 유일성과 필요한 속성만으로 구성되는 최소성
기본키 : 후보키 중 메인이 되는 키, NULL안됨
대체키 : 후보키중 기본 키 제외
외래키 : 다른 테이블의 기본키를 참조한 키

https://fors.tistory.com/208

무결성

데이터베이스에 저장된 데이터와 실제 데이터가 일치하는 정확성, 데이터가 일정하게되는 일관성

개체 무결성 : 모든 테이블이 기본 키를 가져야함
도메인 무결성 : 도메인은 속성이 가질 수 있는 값의 집합, 테이블 속성 값은 도메인에 속해야함
참조 무결성 : 외래키의 값은 참조 테이블 기본키값과 동일하거나 NULL이어야함

인덱스

튜플의 검색 성능을 높이기 위해 속성값+튜플이 저장된 주소를 저장하는 것

장점 : 인덱스 테이블에 데이터가 정렬되어 있어 검색 속도가 빠름

단점 : 인덱스 테이블을 위한 추가 공간이 필요함, 정렬된 상태를 유지하기 위해 데이터를 추가/수정/삭제 속도가 느림

→ 데이터 양이 방대하며 변경보다 검색을 자주하는 경우에 생성

+) https://mangkyu.tistory.com/96

+) 인덱스의 정렬이란?

순서대로 저장: 인덱스는 데이터를 빠르게 검색할 수 있도록 키 값을 기준으로 정렬하여 저장합니다. 예를 들어, 데이터베이스의 특정 컬럼을 기준으로 인덱스를 생성하면, 이 인덱스는 해당 컬럼의 값에 따라 정렬됩니다.
데이터 구조: 인덱스는 보통 B-트리, B+트리와 같은 트리 기반의 데이터 구조를 사용합니다. 이러한 구조는 데이터를 정렬된 상태로 유지하면서도 효율적인 검색을 가능하게 합니다.

B+- 트리 인덱스

트랜잭션

데이터베이스의 상태를 바꾸기 위해 수행하는 작업의 단위/연산

원자성때문에 트랜잭션은 완전히 반영되거나 아예 실행되지 않아야한다. 이를 위한 명령어(TCL)

COMMIT
ROLLBACK
SAVEPOINT

트랜잭션 격리

https://velog.io/@chb1828/트랜잭션의-격리-수준isolation-level-이란

동시성이 높아지면 여러 트랜잭션이 동시에 처리되고 일관성에 문제가 발생할 확률도 높아진다. 그러나 고립성을 높이면 효율이 낮아진다.

락

트랜잭션이 처리되는 순서를 보장하기 위한 방법

공유락 : 읽기 락(read lock), 읽는 연산이라 데이터 일관성에 영향을 주지 않아 여러 공유락이 동시 접근할 수도 있음
베타락 : 쓰기 락(write lock), 쓰기라서 다른 락이 접근 불가능

트랜잭션도 교착상태(dead lock)에 빠질 수 있음 이를 해결하려면

예방 : 트랜잭션 처리 시작 전 필요한 데이터에 대해 미리 락을 얻음
회피 : 트랜잭션이 들어온 순서에 따라 교착 상태 회피

추가로 알아볼 것

관계형 데이터 베이스

각 속성들이 1:1 관계 -> 각 속성들? 1:1? 속성이란뭐죠? 1:1이어야하나요? 데이터를 하나의 컬럼에 a,b로 적으면 1:1이 아닌건가용?
SQL과 NoSQL은 각각 언제쓸까요? -> NoSQL은 일관성이 정말 떨어질까요?
수평 확장과 수직 확장의 차이?
내부 스키마라는게 정확히 뭐지? 외부 스키마의 구체적 예시?
인덱스 데이터 변경시 불리한 이유?
B+-트리 설명
ROLLBACK이 불가능한 상황?
정규형 다시 공부하시죠!
외부조인할때 기준점 테이블이 명령어기준에서 어디로오는지?

[기술면접대비] 3. 네트워크 계층과 TCP&UDP 통신

물고기고기 — Sun, 31 Dec 2023 02:05:41 +0900

OSI 7계층

네트워크 통신이 이뤄지는 과정을 7단계로 나눈 네트워크 표준 모델
각 계층은 독립적이며 데이터를 송신할 때 각 계층에서 필요한 정보를 추가해서 데이터 가공

프로토콜이란 데이터를 송수신하기 위해 정한 규칙

7계층(응용) : http,ftp등 눈앞에 보이는 UI
6계층(표현) : 데이터를 표준화된 형식으로 변경
5계층(세션) : 프로그램 간 통신 제어와 동기화
4계층(전송) : TCP, UDP 같은 전송 방식과 포트 번호
3계층(네트워크) : 데이터 송수신(라우팅) 수행, 네트워크 계층의 장비(라우터)
2계층(데이터 링크) : 데이터 흐름 관리(오류 검출 및 복구), 데이터 링크 계층의 장비
1계층(물리) : 데이터를 비트 단위로 변환해 장비를 사용해 전송, 전기 신호 데이터 복원(리피터,허브 등)

→ OSI 모델의 하위 계층(1-3계층)은 물리적 장비와 더 밀접하게 관련되어 있고, 상위 계층(4-7계층)은 소프트웨어와 프로토콜 중심으로 구현.

+) 표현 계층의 예시?

SSL/TLS (Secure Socket Layer / Transport Layer Security): 암호화된 통신을 제공하여 네트워크 상에서 데이터의 안전성과 보안을 보장합니다.
MIME (Multipurpose Internet Mail Extensions): 이메일에서 다양한 형식의 데이터(텍스트, 이미지, 오디오 등)를 인코딩하는 데 사용됩니다.
JPEG, GIF, TIFF (이미지 포맷): 이미지 데이터를 압축하고 인코딩하는 방식이며, 다양한 시스템과 애플리케이션에서 호환되는 형식으로 변환합니다.

TCP/IP 계층

https://medium.com/@yyuni915/osi-7계층-tcp-ip-4계층-e8716bc2e601

osi 7계층과 같은걸 나타내는데 이를 단순화한 것

+) IP 주소와 서브넷 마스크

https://nordvpn.com/ko/blog/what-is-subnet-mask/

IP주소 : IP에서 컴퓨터 또는 네트워크 장치를 식별하기 위한 값, IPv4에서 주소값은 8자리 2진수 4개를 10진수로 표현한 것. IP주소는 네트워크부(해당 주소가 어떤 네트워크에 속해있는지)와 호스트부(해당 네트워크에서 어떤 기기인지)로 나뉨

서브넷 마스크 : ip주소와 and 연산을 하면 ip 주소에서 네트워크부와 호스트부를 알아낼 수 있다.

TCP와 UDP

TCP

연결형 서비스를 지원하고 데이터의 신뢰성을 보장

송신부와 수신부의 연결을 확인하는 연결형
패킷 교환 방식은 가상 회선 방식
- 가상 회선 방식이란? 데이터를 주고 받기 전 패킷을 전송할 경로인 가상 회선을 설정해 모든 패킷을 같은 경로로 전송하는 것 https://woovictory.github.io/2018/12/28/Network-Packet-Switching-Method/
- 이외의 데이터 그램 방식 : 패킷마다 최적의 경로로 전송되는 방식(각 패킷이 도착 순서가 다를수도)
패킷 전송 순서 보장
패킷 수신 여부 확인
송신부와 수신부는 1:1 통신
데이터 손실 없음을 보장(신뢰성 높음)
속도느림

TCP 핸드셰이킹

연결 시작시 3-way 핸드 셰이킹, 연결 종료시 4-way핸드 셰이킹

이때 송수신부간 연결을 관리하도록 플래그 값을 주고 받음, 주로 사용하는 플래그값은 아래와 같음

SYN : 동기화, 연결 생성시 사용
FIN : 종료, 연결 끊을때 사용
ACK : 승인, 데이터를 전송하면 수신자가 받았음을 알려줄 때 사용

3-way 핸드 셰이킹 : 데이터를 주고받기 전에 상대방 컴퓨터와 세션을 수립하는 과정

상대방 컴퓨터와 세션을 수립하는 과정

송신부→수신부 : SYN(N) 송신부가 수신부와 연결하기 위해 SYN메세지를 보냄. 이때 임이의 숫자 N을 함께 보냄. 이때 송신부는 응답이 오기전까지 SYN_SENT 상태가 됨
수신부→송신부 : ACK(N+1) + SYN(M) 수신부는 송신부로부터 SYN 메세지를 받으면 요청 수락인 ACK메세지를 전송(이때 송신부로부터 받은 N에 +1해서 보냄) 그리고 수신부도 송신부와의 연결을 확인하기위해 임이의 숫자 M을 함께보내고 SYN_RECEIVED 상태가 됨
송신부→수신부 : ACK(M+1) 송신부가 수신부로부터 메세지를 받으면 연결이 성립되었으니 ESTABLISHED 상태가 됨. 마찬가지로 수신부에게 M+1을 해서 확인 메세지를 보냄. 수신부도 송신부로부터 받으면 ESTABLISHED 상태가 됨.

4-way 핸드 셰이킹 : TCP 연결을 해제할 때 이뤄지는 과정

송신부→수신부 : FIN 송신부가 연결 종료를 위해 FIN 메세지를 보내고 FIN_WAIT1 상태가 됨.
수신부→송신부 : ACK 수신부가 FIN 메세지를 받으면 응답으로 ACK를 보냄. 수신부는 CLOSE_WAIT 상태가 된 뒤 앱을 종료하는 등 연결을 종료하기 위한 작업을 함. 송신부는 ACK메세지를 받고 FIN_WAIT2 상태가 됨.
수신부→송신부 : FIN 수신부에서 연결 종료할 준비가 끝나면 송신부에 FIN 메세지를 보내고 LAST_WAIT 상태가 됨.
송신부→수신부 : ACK 송신부는 서버로부터 받은 FIN 메세지에 대한 응답으로 ACK 메세지를 보내고 TIME_WAT 상태가 됨. 일정 시간이 지난 뒤 CLOSED 상태로 변경 됨. 일정 시간동안 기다리는 이유는 FIN 메세지 전에 보낸 패킷이 FIN 메세지 수신보다 느리게 도착해서 유실되는 경우에 대비하기 위함. 또한 수신부가 ACK 메세지를 못받아 연결 해제가 이뤄지지 않는 경우에 대비하기 위함. 수신부는 ACK 메세지를 받고 CLOSED 상태가 됨.

+) TCP Keep Alive : 세션이 연결되면 유지하는 동안 일정 시간 경과후 패킷을 던져 연결 유지 상태를 확인한다. 이때 TCP Keep Alive패킷은 연결을 유지하기 원하는 쪽에서 보냄. 패킷에 대한 응답을 받으면 일정 시간을 다시 측정하고, 받지 못하면 연결 종료함. 이는 주고받을때마다 3-way핸드셰이킹을 하지않아도되도록하며, 불필요한 연결(좀비 커넥션)도 끊어준다.

TCP 제어 방법

흐름제어 : 데이터 송신부와 수신부에서 데이터 처리 속도 차이 때문에 생기는 데이터 손실을 방지하는 방법

정지 대기 : 송신부에서 데이터를 보낸 후 수신부로 ACK 메세지를 받을때까지 기다리는 방식, 만약 일정 시간이 지나도 ACK 메세지를 받지 못하면 패킷 재전송. 간단하나 이전 메세지에 대한 응답을 받아야만 다음 메세지를 보낼 수 있어 시간상 비효율적
슬라이딩 윈도우 : 송신부에서 데이터 수신여부(ACK)를 확인하지 않고 수신부에서 설정한 윈도우 크기(응답받지 않고도 보낼수 있는 최대 데이터 갯수, 3-way핸드 셰이킹 과정에서 결정) 만큼 데이터를 연속적으로 보내는 동적 제어 방식. 즉, 수신부에서 ACK 메세지를 받은만큼만 옆으로 옮기는 셈 (3을 받으면 2를 넘겨주고, 만약 3과1을 받았으면 2 와 -1을 넘겨줌)

혼잡제어 : 송신부의 데이터 전달 속도와 네트워크 속도 차이로 데이터 손실이 발생하는 것을 방지하기 위한 방법, 예를 들어 송신부에서 제대로 보냈으나 네트워크의 문제로 일정시간 응답을 받지 못하면 송신부는 메세지 전송 실패로 판단하고 여러번 재전송하게 되는 악순환이 생긴다.

AIMD : 데이터 전달 시 합 증가 방식으로 혼잡 윈도우의 크기를 더해가면서 키움, 데이터 손실이 발생하면 곱 감소 방식을 적용해 1/2배 등 배수 단위로 줄임. 해당 방식은 시간이 지나면 여러 송신부 간에 네트워크 대역폭을 공평하게 사용할 수 있게 되지만 유실이 발생하면 윈도우 크기 증가폭에 비해 감소폭이 더 크기에 네트워크 대역폭을 넓게 사용하기까지 시간이 오래 걸림
느린 시작 : 윈도우 크기가 1인 상태로 시작. ACK 메세지를 수신할때마다 윈도우 크기 1씩 늘려나감, 혼잡 발생 시 윈도우 크기를 1로 바로 줄임, 전송 가능 패킷을 지수 함수 형태로 늘리는 점에서 AIMD 방식이 초기 전송 가능 패킷수가 적은 단점을 보완
혼잡 회피 : 윈도우 크기가 지수 함수 형태로 증가하다 혼잡이 발생하는 걸 막기 위해 임계점을 정하는 방식. 윈도우 크기가 임계점에 도달하면 그때부턴 선형적으로 증가. ACK 메세지를 받지 못해 타임아웃이 발생하면 그 시점에서 윈도우 크기의 절반을 임계점으로 설정하고 윈도우 크기를 초깃값으로 변경
빠른 회복 : 혼잡이 발생하면 윈도우 크기를 절반으로 줄이고 선형 증가. 혼잡이 발생하면 AIMD 방식으로 동작
빠른 재전송 : Duplicate ACK가 3번 발생하면 윈도우 크기를 절반으로 줄임. 그 뒤로 ACK 메세지를 받으면 윈도우 크기 증가(Duplicate ACK란 패킷이 순서대로 도착하지 않아 재요청하는 것을 말함)
https://evan-moon.github.io/2019/11/26/tcp-congestion-control/

→ TCP는 이러한 혼잡 제어 방식들을 여럿 혼합해 혼잡 제어 정책을 사용한다.

+) 그런데 송신부와 네트워크는 구체적으로 어떻게 다른거지? 뭐가 송신부고 뭐가 네트워크인걸까?
송신부 (Sender)

정의: 송신부는 데이터를 전송하는 주체입니다. 이는 데이터 통신 시스템에서 메시지를 보내는 측을 의미하며, 개별 컴퓨터, 모바일 장치, 서버 또는 다른 네트워크 장치일 수 있습니다.
역할: 송신부의 주요 역할은 데이터를 생성하고, 해당 데이터를 네트워크를 통해 수신부(Receiver)에게 전송하는 것입니다. 데이터는 파일, 이메일, 비디오 스트림, 패킷 등 다양한 형식을 가질 수 있습니다.

네트워크 (Network)

정의: 네트워크는 데이터가 전송되는 경로나 매체를 의미합니다. 이는 컴퓨터, 서버, 스위치, 라우터 등 다양한 네트워크 장비로 구성된 시스템을 포함하며, 로컬 네트워크에서부터 인터넷에 이르기까지 다양한 규모를 가질 수 있습니다.
역할: 네트워크의 역할은 송신부로부터 전송된 데이터를 수신부까지 전달하는 것입니다. 네트워크는 데이터를 라우팅하고, 필요한 경우 데이터를 처리하거나 변환하는 기능을 수행합니다.

오류제어: 데이터에 오류 또는 유실이 발생할때 신뢰성을 보장하기 위해 제어하는 방식, 이를 인지하는 경우는 아래와 같음

수신부에서 잘못된 데이터를 받았다고 응답할 시(NAK 메세지)
3 Duplicate ACK가 발생
수신부로부터 ACK 메세지를 받지 못해 타임아웃 발생

정지-대기 : 흐름 제어에서 나왔던 방식과 동일. 한개 보내고 응답 기다림. 다만 송신부에서 데이터를 1개만 보내고 기다려야하기 때문에 ARQ(재전송 요청)방식 사용
Go-Back-N ARQ : 송신부에서 연속적으로 데이터를 보내며 누락 데이터가 발생하면 해당 데이터부터 재전송하는 방식.
Selective-Repeat ARQ : 송신부에서 연속적으로 데이터를 보낼때 누락 데이터가 있으면 수신부에서 해당 데이터만 재전송 요청. 특정 패킷만 재전송 요청하니 효율적으로 보이나 받은 패킷에 대한 재정렬 로직이 추가로 필요함

UDP

TCP와 같은 전송 계층 네트워크 프로토콜. UDP는 송수신부 간의 연결을 지원하지 않고 데이터그램 형태로 통신 지원. 핸드셰이킹 과정 없이 패킷을 바로 송수신. 신뢰성이 낮으나 속도가 빠름

송신부와 수신부 연결 보장X, 비연결형 서비스
패킷이 서로 다른 회선으로 교환될 수 있음(데이터그램 패킷 교환 방식) +) 이에 대한 예시? 이메일을 보낼 때, 이메일의 내용이 여러 패킷으로 나뉘어질 수 있음. 각 패킷은 인터넷을 통해 독립적으로 전송되며, 각각 다른 경로를 통해 수신자에게 도달.
송신부에서 전달 패킷 순서와 수신부에서 받은 패킷 순서 다를 수 있음
패킷 수신 여부 확인X
1:1 , 1:N, N:N 통신 모두 가능 +) 다대다 통신의 예시? PvP(Player vs. Player) 게임은 N:N(다대다) 통신의 예시로 볼 수 있음.
데이터 신뢰성 낮음
데이터 전송 속도 빠름

[기술면접대비] 2. 스케줄링과 메모리 관리 전략

물고기고기 — Wed, 27 Dec 2023 22:43:16 +0900

이전글에서 이어집니다.

3. 스케줄링

스케줄링의 단계

1. 장기 스케줄링 : 준비 큐에 어떤 프로세스를 넣을지 결정해 메모리에 올라가는 프로세스 수 조절 (잡 스케줄링, 승인스케줄링)
2. 중기 스케줄링 : 메모리에 로드된 프로세스 수를 동적으로 조절, 프로세스가 많이 로드되면 스왑 아웃해서 일부 프로세스를 통째로 저장 -> 이때 스왑아웃된 프로세스는 중단 상태가 됨(준비/대기 상태에 중단 되는 셈)
3. 단기 스케줄링 : 준비 큐에 있는 대기 상태 프로세스 중 순서를 정해주는 스케줄링 알고리즘으로 결정. 어떤 프로세스를 보낼지 결정함(CPU 스케줄링)

용어정리
- 스왑 아웃 : 프로세스가 너무 많이 로드돼 중기 스케줄러가 프로세스들을 통째로 저장 공간에 옮겨 저장하는 것
- 스왑 인 : 스왑 아웃한 프로세스에서 이벤트 요청이 오면 해당 프로세스를 통째로 메모리에 다시 로드하는 것
- 스와핑 : 프로세스를 통째로 메모리 영역과 저장 공간으로 옮기는 것

중기 스케줄링과 단기 스케줄링은 그럼 같이 쓰이는건가? 네
함께 사용되는 경우
통합된 관리: 몇몇 시스템에서는 단기 스케줄링과 중기 스케줄링이 통합되어 시스템의 성능을 향상시키고 자원을 효율적으로 관리합니다.
협력적인 역할: 단기 스케줄링이 CPU 사용을 최적화하는 동안, 중기 스케줄링은 메모리 관리 및 시스템 부하 균형을 유지하는 역할을 합니다.
단기 스케줄링과 중기 스케줄링은 각각 독립적인 기능을 수행하지만, 전체 시스템 성능에 영향을 미치는 상호 연관된 역할을 수행합니다. 따라서 이 둘은 서로 다른 측면에서 시스템의 성능과 효율성을 관리하는 중요한 부분입니다.

스케줄링 알고리즘

스케줄링 알고리즘 : 단기 스케줄러가 준비 큐에 있는 프로세스 중 어떤 프로세스를 실행 시킬지 결정할 때 사용, 아래와 같은 조건을 고려해서 우선순위를 매김

CPU 사용률 : cpu를 놀게하지 않고 사용하는지
처리량 : 단위 시간 당 실행한 프로세스 수
응답 시간 : 프로세스에 요청이 발생했을 때 응답까지 걸리는 시간
반환 시간 : 프로세스가 로드된 이후부터 종료까지 걸리는 시간
대기 시간 : 프로세스가 대기 큐에서 대기하는 시간의 총합

비선점형 스케줄링 : 실행 중인 프로세스가 종료될 때까지 다른 프로세스를 실행할 수 없음

FCFS 스케줄링 : 큐에 먼저 들어온 프로세스가 우선(순서대로)
SJF 스케줄링 : 실행 시간이 짧은 프로세스가 우선순위를 갖는 알고리즘 -> 실행 시간이 긴 프로세스는 뒤로 밀려 계속 기다릴 수도 있음

선점형 스케줄링 : 스케줄러가 실행 중인 프로세스를 중단시키고 다른 프로세스를 실행할 수 있음

RR 스케줄링 : 프로세스 간 우선순위가 없음, 모든 프로세스를 일정 시간 실행하며 일정 시간 초과 시 다른 프로세스 실행 -> 콘텍스트 스위칭이 빈번하게 일어나서 오버헤드가 크나, 모든 프로세스가 반복 수행되어 응답속도 빠름
SRTF 스케줄링 : 큐에서 대기 시간이 가장 짧게 남은 프로세스를 우선 수행하는 알고리즘, 한 프로세스가 실행 중일때 실행 시간이 더 짧은 프로세스가 들어오면 해당 프로세스가 CPU 차지 -> 실행시간 긴건 또 오래 기다려야함(기아상태)
멀티 레벨 스케줄링 : 준비 큐를 목적에 따라 여러 개로 분리해 사용함, 분리한 큐는 각자 우선순위가 다르거나 다른 스케줄링 알고리즘을 적용할 수 있음 (예를 들어 foreground 큐는 응답 속도가 중요한 프로세스가 들어가고, background 큐는 성능을 중요시하는 프로세스가 들어감)

4. 메모리 관리 전략

논리 메모리와 물리 메모리 : 프로세스가 보는 메모리 영역을 논리 메모리 영역(가상 메모리)라고 하고 실제로 사용되는 영역이 물리 메모리 영역임, 그리고 CPU가 프로세스를 실행하며 보는 주소 값을 논리 주소라고 함 -> 이때 논리 주소를 물리 주소로 변환해주는 장치를 메모리 관리 장치(MMU)라고 함 (MMU에서 RAM을 거쳐 실제 데이터를 얻어오는 것)

연속 메모리 할당

고정 분할 방식 : 메모리 영역을 분할한 뒤 각 영역에 프로세스를 할당 -> 부분 파편화가 되어 원래는 올릴 수도 있는 프로세스인데 분할되어 못올리기도함(단편화 문제 발생)
가변 분할 방식 : 할당된 프로세스의 크기에 따라 메모리 공간을 분할
1. 최초 적합 : 가용 메모리 공간에서 크기만큼 비어있는 공간을 찾아 차례로 프로세스 로드(중간에 비어있는 순서대로 넣는 것)
2. 최적 적합 : 가용 메모리 공간 중 가장 작은 공간에 프로세스를 할당함, 대신 가용 메모리 공간을 모두 탐색해야
3. 최악 적합 : 할당하려는 프로세스 크기보다 큰 가용 메모리 공간 중에서 가장 큰 공간에 프로세스 할당, 얘도 마찬가지로 모두 탐색해야함

외부 단편화 vs 내부 단편화

외부 단편화 : 고정 분할로 인해 원래는 들어갈 수 있는데 못들어가는 상황(10짜리인데 자리가 2,8로 나뉘어 못들어감)
내부 단편화 : 분할된 크기가 만약 8이라고할때 분할된 크기보다 작은 프로세스들이 들어가 자리가 남는 상황(8짜리인데 6이 들어가서 2가 남음)

비연속 메모리 할당 : 프로세스의 메모리 영역을 나눠서 메모리 공간에 저장하는 방법

페이징 : 프로세스의 논리 메모리 영역과 물리 메모리 영역을 각각 일정한 크기의 페이지와 프레임으로 나눔,
- 각 페이지와 프레임에 번호를 할당해 프로세스의 페이지와 메모리의 프레임을 매핑해줌 (테이블 형식, 페이지 테이블) -> 페이지를 물리 메모리에 연속으로 할당할 필요가 없어서 외부 단편화 문제를 해결 가능, 여전히 내부 단편화 문제 발생
세그멘테이션 : 프로세스의 메모리 영역을 논리적 단위인 세그먼트로 분할해 메모리를 할당
- -> 세그먼트 테이블을 사용해 시작주소인 base와 길이인 limit을 저장 -> 프로세스의 메모리 영역을 논리적 단위로 나눠 저장하니 단위별로 데이터 보호가 쉬우나 세그먼트의 크기가 균등하지 않아 외부 단편화 문제 발생, 그리고 특정 세그먼트 영역에서 오버플로가 발생하면 다른 프로세스와 메모리를 통째로 스왑 아웃해야됨

5. 가상 메모리

가상 메모리 : 프로세스의 일부만 메모리에 로드하고 나머지는 디스크에 둔 상태로 프로세스를 실행, 논리(가상) 메모리라는 것을 만들어 모든 페이지가 메모리 위에 있는 것처럼 보이게 함

프로그램이 메모리 크기에 대한 제약을 덜 받음
동시에 많은 프로그램을 실행해 CPU 이용률과 처리율을 높임
필요한 영역만 메모리에 로드해 스와핑 횟수를 줄여 프로그램 실행 속도를 높임

요구 페이징 : 프로세스에서 필요한 페이지만 메모리에 로드하는 방식, 당장 쓰지 않는 페이지들은 요청이 올 때 메모리에 로드함, 물리 메모리에 필요한 페이지가 없을때(페이지 폴트) 디스크에서 필요한 페이지를 스왑 인해옴 -> 이때 내가 요구한 페이지가 물리 메모리에 있는지는 페이지 테이블로 파악가능함(있으면 v, 없으면 i)

+) 요구 페이징에서 필요한 페이지가 물리 메모리에 있는지 없는지 페이지 테이블에서 확인하잖아. 이때 페이지 테이블에 있는지 확인하는 주체가 CPU인거야? 아님 메모리인거야? -> CPU입니다~

스레싱 : 동시에 일정 수 이성의 프로그램을 실행했을 때 오히려 CPU 이용률이 떨어지는 상황 -> 프로세스가 CPU 작업보다 페이지 교체에 더 많은 시간을 소비하여 전반적인 시스템 성능이 저하되는 현상
워킹 세트 : 스레싱을 예방하기 위해 지역성을 기반으로 자주 사용하는 페이지는 따로 저장해 두는 것(물리 메모리에 고정)

6. 캐시 메모리

캐시 메모리 : CPU와 메인 메모리 간에 데이터 접근 시 속도 차이를 줄이기 위해 사용. 자주 사용하는 데이터는 캐시 메모리에 따로 저장
지역성 : CPU가 자주 참조하는 데이터가 고르게 분포되지 않고 특정 부분에 몰려 있는 것

시간 지역성 : 최근 참조 내용을 재참조할 가능성이 높음
공간 지역성 : 실제 참조한 주소 근처 내용을 참조할 가능성이 높음