데이터 파이프라인?

 데이터 파이프라인은 여러 데이터 소스로부터 가공되지 않은 데이터를 수집해 전처리를 거쳐 데이터 웨어하우스와 같은 별도의 데이터 저장소로 이전하는 과정을 의미한다.

 데이터 파이프라인을 사용하는 이유는 간단하다. 데이터를 수집하고, 가공하고, 적재하는 일련의 과정을 시스템화시켜서 데이터 분석을 효율적으로 하기 위해서 사용한다.

OLTP와 OLAP

 데이터 파이프라인은 크게 온라인 트랜잭션 처리(OLTP)와 온라인 분석 처리(OLAP)로 나뉜다.

 OLTP는 실시간으로 발생하는 트랜잭션 데이터를 처리하는데 초점을, OLAP는 대량의 데이터를 분석하고 요약 정보를 생성하는 데에 초점을 맞춘다. 

정형 데이터와 비정형 데이터

 정형 데이터는 정해진 규칙에 따라 잘 정리된 데이터로, 날짜, 이름, 주소 등과 같이 해당 속성에 들어갈 값이 예측 가능하고 의미를 알기 쉬운 데이터를 말한다.

 반면, 비정형 데이터는 문서(JSON, 텍스트)의 형태를 띠거나, 아예 음성이나 영상과 같은 바이너리 형식의 데이터일 수도 있다. 즉, 가공과 분석이 어렵다. 그러나 비즈니스에 필요한 정보를 얻어내기 위해선 비정형데이터를 분석해야하는 경우 또한 많기 때문에 요즘은 빅데이터 도구를 사용해 가공/분석 할 수 있도록 만든다.

데이터 파이프라인의 과정 : ETL과 ELT

 ETL, ELT 각 알파벳의 뜻은 데이터 파이프라인의 각 과정인 데이터의 추출(Extraction), 변환(Transformation), 로드(Loading) 를 말한다.

 ETL은 데이터를 원본에서 추출한 뒤 변환하고, 그 다음 목적지에 로드하는 과정입니다. ELT는 데이터를 먼저 추출하고 로드한 뒤, 목적지에서 변환하고, ETL은 데이터를 추출한 뒤에 변환하고, 로드한다.

데이터 파이프라인을 만들때 어떤 기술 및 도구를 선택하느냐에 따라 ETL과 ELT 중 적합한 방식을 선택하면 된다.

MLOps. 머신러닝과 데이터 파이프라인

 DevOps는 개발과 운영을 따로 나누지 않고 개발의 생산성과 운영의 안정성을 최적화하기 위한 문화이자 방법론이다. 이 방법론에서 개발만 머신러닝 시스템으로 교체하면 그것이 바로 MLOps다.

 그래서 MLOps 파이프라인의 과정들은 DevOps의 파이프라인 과정과 닮은 점이 많다.

머신 러닝을 도입한 데이터 처리 파이프라인

• 데이터 분석
  • 데이터의 이해를 위한 탐색적 데이터 분석(EDA, Exploratory Data Analysis)을 한다. 이때 모델에 필요한 데이터 스키마 및 특성을 이해한다.
• 데이터 준비 (추출 및 정제)
  • 데이터 소스에서 관련 데이터를 추출(extract) 및 정제한다. 변환(transform), 집합(aggregate), 중복 제거 등의 과정을 거치게 된다.

• 모델 학습 및 튜닝
  • 다양한 알고리즘을 구현하고, 하이퍼 파라미터를 조정(튜닝)하고 적용하여 학습된 모델을 만든다.
• 모델 평가 및 검증
  •  모델 성능을 측정해, 배포에 적합한 수준인지를 검증한다.
• 모델 제공
  • CI/CD 툴을 이용하여, 프로덕션 수준에서 이용할 수 있도록 파이프라인을 자동화시킨다.
• 모델 배포 및 모니터링
  • 애플리케이션에서 사용 가능하도록 endpoint를 활성화해준다.

데이터베이스 정규화

데이터베이스 설계를 할 때, 빼놓을 수 없는 중요한 개념 중 하나가 바로 '정규화'다.

 짧게 말하자면 정규화는 데이터베이스의 데이터를 구성하는 프로세스다.

 이 과정에서는 데이터를 보호하고, 중복성과 일관성 없는 종속성을 제거하여 데이터베이스를 보다 유연하게 만들기 위해 설계된 규칙에 따라 테이블을 만들고, 해당 테이블 간에 관계를 설정한다.

즉, 정규화는 테이블을 어떻게 나누어야하는 것인가에 대해서 기준을 제시한다고 볼 수 있다.

정규화의 규칙: 1, 2, 3 정규화

데이터베이스 정규화에는 몇 가지 규칙이 적용됩니다. 각 규칙을 "일반 양식"이라고 합니다. 첫 번째 규칙이 관찰되면 데이터베이스는 "첫 번째 일반 형식"이라고 합니다. 처음 세 규칙을 관찰하는 경우 데이터베이스는 "세 번째 일반 형식"으로 간주됩니다.

1 정규화

첫 번째 정규 형식은 개별 테이블에서 반복되는 그룹을 제거하는 거다. 그래서 각 관련 데이터 집합에 대해 별도의 테이블을 만들고, 기본 키를 사용하여 각 관련 데이터 집합을 특정할 수 있다.

예를 들어, 아래와 같은 테이블이 있다고 가정해보자.

이 테이블을 첫 번째 정규 형식에 맞게 변환하면 아래와 같이 된다.

2 정규화

2 정규화는 여러 레코드에 적용되는 값 집합에 대해 별도의 테이블을 만드는 것이다. 이를 위해 외래 키를 사용해 이런 테이블 간의 관계를 설정해줘야만 한다.

위의 테이블을 두 번째 정규 형식에 맞게 변환하면 아래와 같이 된다.

Students:

Faculty:

Registration:

3 정규화

3 정규화는 키에 의존하지 않는 필드를 제거하는 것입니다. 해당 레코드의 키에 속하지 않는 레코드의 값은 테이블에 속하지 않아야한다.

위의 테이블을 세 번째 정규 형식에 맞게 변환하면 다음과 같습니다.

Students:

Faculty:

Registration:

이렇게 정규화를 하면 데이터베이스의 효율성을 높이고, 데이터의 일관성을 유지하면서도, 데이터 관리의 복잡성을 줄일 수 있다. 이는 당연하게도 데이터베이스를 설계할 때 우선적으로 고려해야할 중요한 부분이며, 이를 이해하고 적용시켜야한다.

참고 : https://learn.microsoft.com/ko-kr/office/troubleshoot/access/database-normalization-description

vi에디터?

 vi는 명령어 기반의 에디터로, 일반적인 그래픽 사용자 인터페이스(GUI. ex : MS word, 한글)와는 다르다. vi는 명령 모드와 편집 모드를 사용하여 파일을 편집한다.

• 명령 모드(Command mode): vi 에디터를 시작하면 기본적으로 명령 모드 상태로 설정된다. 이 모드에서는 파일 내용을 보거나 검색하는 등의 기능을 수행할 수 있다.
• 편집 모드(Insert mode): 편집 모드로 전환하려면 명령 모드에서 "i"나 "a"를 입력해주면 된다. 이 모드에서는 파일 내용을 직접 편집할 수 있다.
• 종료 모드(Last line mode): ":"(콜론)을 입력하면 마지막 행 모드로 전환된다. 이 모드에서는 파일 저장, 종료, 검색 및 다양한 설정을 수행할 수 있다.

이제 이 vi에디터를 활용하기 위해 알아야할 것들을 살펴보자.

vi 사용법

에디터 실행

vi 파일이름

이 명령어를 입력하면, vi 에디터가 실행되고 파일이 열린다. 만약 해당 파일이 존재하지 않으면, 새로운 파일을 만들어서 연다.

명령 모드(Command mode)

vi를 실행하면, 기본적으로 명령 모드 상태로 시작한다. 이 모드에서는 파일 내용을 보거나 검색할 수 있다.

파일 내 검색

파일 내에서 특정 문자열을 검색할 때는 명령 모드에서 "/"를 입력하고 검색어를 입력한다.

예를 들어, "hello"라는 문자열을 검색하는 방법은 이렇다.

/hello

입력하고나면, 파일 내에서 "hello" 문자열을 검색하고, 해당 문자열이 나타나는 곳으로 커서가 이동한다.

파일 저장 및 종료

i 에디터에서 파일을 저장하려면, 명령 모드에서 ":"(콜론)을 입력하고 "w"를 입력해주면 된다.

예를 들어, 파일 이름이 "example.txt"인 파일을 저장하는 방법은 이렇다.

:w example.txt

파일을 저장하고 vi를 종료하려면, 명령 모드에서 ":"(콜론)을 입력하고 "wq"를 입력해주면 된다.

:wq example.txt

기타 설정들

• 라인 넘버 표시하기

:set number

• 라인 넘버 숨기기

:set nonumber

편집 모드(Insert mode)

vi 에디터에서 파일을 편집하려면 명령 모드에서 "i"를 입력해 편집 모드(Insert mode)로 전환해줘야만 한다.

편집 모드 -> 명령 모드 전환

ESC키를 눌러주면 된다.

비주얼 모드(Visual mode)

비주얼 모드(Visual mode)는 명령 모드에서 "v"를 입력 전환한다. 

텍스트 선택하기

비주얼 모드에서는 방향키를 사용하여 텍스트를 선택할 수 있다.

선택한 텍스트 복사하기

비주얼 모드에서 선택한 텍스트는 "y"키를 누르면 복사할 수 있다.

기타 단축키들

• 커서 이동하기
  • h: 왼쪽으로 한 칸 이동
  • j: 아래로 한 칸 이동
  • k: 위로 한 칸 이동
  • l: 오른쪽으로 한 칸 이동
  • 0: 줄의 맨 앞으로 이동
  • $: 줄의 맨 뒤로 이동
  • w: 다음 단어로 이동
  • b: 이전 단어로 이동
• 삭제하기
  • x: 커서가 위치한 글자 삭제
  • dd: 커서가 위치한 줄 삭제
• 되돌리기 및 다시 실행하기
  • u: 되돌리기
  • Ctrl+r: 다시 실행하기

 HTTP 기반의 서버를 생성하는 소프트웨어인 nginx를 사용해, 웹 서버(Web Server)를 생성하여 정적 웹페이지 호스팅할 수 있다.

nginx 설치

먼저 nginx를 사용하기 위해서 apt get 명령어를 사용해 nginx를 설치해준다.

sudo apt-get update

sudo apt-get install nginx

설치를 완료했다면

sudo nginx -v

명령어로 설치된 nginx의 버전을 확인할 수 있다.

nginx 로 정적 콘텐츠 호스팅하기

nginx의 환경 설정파일 nginx.conf

일반적으로 환경 설정 파일은 관리자가 편집하거나 프로그램을 분석할 수 있는 텍스트 파일을 말한다.

nginx도 nginx.conf라는 텍스트 파일에 여러 가지 값을 지정해 프로그램의 작동 방법을 결정 할 수 있다.

nginx.conf 파일의 내용은 아래와 같다.

user www-data; #웹 서버가 실행되는 사용자를 설정한다. 기본값은 'www-data'.
worker_processes auto; #동시에 처리할 워커 프로세스의 개수를 설정한다. 'auto'는 시스템의 CPU 코어 수에 따라 자동으로 할당.
pid /run/nginx.pid; #nginx 프로세스 ID 파일의 위치를 설정한다.
include /etc/nginx/modules-enabled/*.conf; #활성화된 모듈의 설정 파일을 불러온다.

# 이벤트 처리에 대한 설정 블록이다.
# 워커 프로세스당 연결 수를 정의하는 worker_connections와 같은 설정이 포함된다.
events { 
    worker_connections 768;
    # multi_accept on;
}

# HTTP 서버에 대한 전체 설정 블록이다.
# 기본 설정, SSL 설정, 로깅 설정, Gzip 설정 등이 포함된다.
http {
    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types; #지원되는 MIME 타입을 포함하는 파일의 위치를 지정한다.
    default_type application/octet-stream; #MIME 타입이 지정되지 않은 경우 기본값으로 사용되는 타입이다.

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #사용할 SSL 프로토콜을 설정한다. SSLv3는 POODLE 취약점 때문에 사용하지 않는다.Dropping SSLv3, ref: POODLE 
    ssl_prefer_server_ciphers on; #SSL/TLS 연결 시 서버 측이 지정한 암호 스위트를 클라이언트 측보다 우선시하는지 여부를 설정한다.

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log; #접근 로그 파일의 위치를 지정한다.
    error_log /var/log/nginx/error.log; #에러 로그 파일의 위치를 지정해준다.

    ##
    # Gzip Settings
    ##

    gzip on; #Gzip 압축 기능을 활성화한다.

    # gzip_vary on; # Gzip 압축 여부에 따라 Vary 헤더를 설정하는 옵션. 기본값은 'off'.
    # gzip_proxied any; # 프록시된 요청에 대해 Gzip 압축을 적용할 조건을 설정합니다. 'any'는 모든 프록시 요청에 압축을 적용합니다.
    # gzip_comp_level 6; #  Gzip 압축 수준을 설정. 1(최소)부터 9(최대)까지 설정할 수 있으며, 기본값은 1.
    # gzip_buffers 16 8k; #  Gzip 압축에 사용되는 버퍼의 개수와 크기를 설정.
    # gzip_http_version 1.1; # Gzip 압축을 적용할 HTTP 버전을 설정. 기본값은 1.0.
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    #Gzip 압축을 적용할 MIME 타입을 설정한다. 기본적으로 텍스트와 애플리케이션 타입에 대해 압축이 적용된다.
    
    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf; #추가 설정 파일들을 포함하는 디렉토리다.
    include /etc/nginx/sites-enabled/*; #활성화된 사이트 설정 파일들을 포함하는 디렉토리다. /etc/nginx/sites-available/에 있는 설정 파일들을 여기에 심볼릭 링크로 연결하여 사용한다.
}

설정파일 작성

웹 서비스를 호스팅하기 위해서는 위의 nginx.conf 파일에다 제공할 웹서버의 정보를 담는 server 블록과 제공할 웹페이지의 소스 위치를 담는 location블록을 생성해줘야한다.

server {
	listen 80; #읽어올 포트 
	server_name your_domain.com www.your_domain.com;#서버 도메인 이름

	location / {
	    root /var/www/mywebsite; #제공할 웹페이지의 위치
		index index.html; #인덱스 파일 이름
	}
 }
 ```

위는 server블록과 location블록 작성의 예시이다.

변경사항 적용 및 웹 서버 생성

설정 파일 링크를 생성한다

$ sudo ln -s /etc/nginx/sites-available/mywebsite /etc/nginx/sites-enabled/

nginx를 재시작한다.

$ sudo systemctl restart nginx

여기까지 문제없이 실행했다면 nginx.conf에서 작성했던대로 웹서버를 생성하고 정적 웹페이지를 호스팅한다.

CI/CD 파이프라인은 소프트웨어 개발 프로세스에서 개발, 테스트 및 배포를 자동화하기 위한 과정을 말한다.

이 파이프라인은 개발자들이 소프트웨어 개발에 대한 변경 사항을 더욱 쉽고 빠르게 반영할 수 있도록 도와준다.

왜 CI/CD 파이프라인을 사용해야 할까?

크게 4가지 이유로 정리해볼 수 있을 것 같다.

• CI/CD 파이프라인을 통해 개발자들은 빠르게 개발하고 배포할 수 있다. 그러면 개발자들이 더 많은 시간을 코드 작성에 집중하고, 소프트웨어의 배포 주기를 단축하여 사용자들이 새로운 기능을 더욱 빠르게 사용할 수 있다.
• CI/CD 파이프라인을 사용하면, 오류가 최소화되고 S/W 배포의 안정성이 향상된다. 이는 개발자들이 소프트웨어에 대한 변경 사항을 신속하게 확인할 수 있기 때문에, 버그 및 오류가 더 빠르게 발견되어 해결될 수 있다.
• CI/CD 파이프라인은 개발 및 배포 프로세스의 자동화를 통해, 사람의 작업을 최소화해 인적 오류를 예방한다. 이는 개발자들이 더욱 안정적이고 신뢰성 있는 소프트웨어를 배포할 수 있도록 해준다.
• CI/CD 파이프라인은 소프트웨어 개발자와 운영자 간의 협업을 원활하게 만들어준다. 이전까지는 개발자와 운영자가 각자의 업무에만 전념하다가, 개발된 소프트웨어가 운영에 문제가 발생하는 경우가 많았지만, CI/CD 파이프라인을 사용한다면 개발자와 운영자가 함께 작업하고, 이를 자동화하는 방식으로 문제를 예방하고 해결할 수 있다.

CI/CD 파이프라인의 각 단계

1. Plan : 소프트웨어에 대한 기획, 설계를 하는 단계입니다. 여러 문서작업이 수반된다.
2. Code : 소스 코드를 저장하고 관리하는 단계입니다. 대표적으로 Git이 쓰인다.
3. Build: 소스 코드를 컴퓨터가 이해할 수 있는 실행 가능한 형태로 변환한다.
4. Test: 빌드된 소프트웨어가 정상적으로 동작하는지 확인한다.
5. Release: 코드의 품질과 보안을 검사한다.
6. Deploy: 빌드된 소프트웨어를 실제 서버에 배포한다.
7. Operate: 소프트웨어가 실제로 동작하며, 소프트웨어가 제대로 동작하는지 모니터링한다.

각 단계는 일련의 자동화된 작업으로 구성된다.

 소스 코드가 변경되면, CI 파트가 시작된다. 이 때, CI 파트에서는 소스 코드를 빌드하고, 테스트를 수행하며, 코드에 문제가 없는지 확인한다.

 테스트가 통과되면, CD 파트가 시작된다. CD 파트에서는 빌드된 소프트웨어가 배포 가능한 형태인지 확인하고, 배포될 수 있도록 필요한 작업을 수행한다.

소프트웨어 공학?

소프트웨어 공학은 컴퓨터 프로그램을 개발하는데 필요한 모든 과정을 체계적으로 다루는 분야다. 이 학문은 개발된 소프트웨어의 품질을 향상시키고, 생산성을 높이며, 개발 비용을 최소화하는 것이 목표다.

그래서 소프트웨어 공학에서는 소프트웨어를 개발하기 위한 다양한 방법론과 도구를 제공하고 있다.

소프트웨어 공학의 목표

1. 소프트웨어 개발 생산성의 향상

 소프트웨어가 점점 더 복잡해지면서, 개발자들은 프로그램을 개발하기 위해 여러 가지 원리, 방법론, 도구, 기술 등을 사용할 필요가 생겼다. 이를 위해, 소프트웨어 개발 프로세스의 모든 단계를 체계적으로 관리하고 실행할 수 있는 방법론과 도구를 제공한다.

 이 방법론과 도구들을 활용해서 소프트웨어 공학의 원리와 방법론, 도구, 기술 등을 적용해, 개발자들은 복잡한 소프트웨어를 안정적으로 개발할 수 있고, 비즈니스 프로세스를 자동화하여 조직 내에서 발생하는 인적 오류와 복잡성을 줄이는 방식으로 조직 자체의 생산성을 향상시킬 수 있다.

2. 소프트웨어 품질의 향상

소프트웨어 공학은 소프트웨어의 기능적 요구사항과 비기능적 요구사항을 충족시키는 소프트웨어를 개발하는 방법론과 도구를 제공한다.

 이 방법론과 도구들을 활용해 소프트웨어의 품질을 보증할 수 있는데, 이것이 가능한 이유는 소프트웨어의 요구사항 분석, 설계, 테스트, 유지보수 등의 생명주기 전 과정을 체계적으로 관리하고 실행함으로써, 소프트웨어가 안정적으로 동작할 수 있도록 하기 때문이다.

3. 소프트웨어 개발 비용의 최소화

 소프트웨어 공학에서는 소프트웨어 개발 비용을 최소화하는 것이 목표 중 하나다. 이를 위해, 소프트웨어 개발 과정에서의 비용을 효율적으로 관리할 수 있는 방법론과 도구를 제공한다.

 이 도구들을 사용해서 소프트웨어 공학은 소프트프트웨어 개발의 생명주기 전 과정을 체계적으로 관리하고 실행하면서, 소프트웨어 개발 비용을 줄일 수 있기 때문에 비용을 절감하는데 도움을 줄 수 있다.

4. 소프트웨어 유지보수의 편의성 제공

소프트웨어 공학에서는 소프트웨어 유지보수의 편의성을 제공하는 것 또한 목표이다. 이를 위해서, 소프트웨어를 개발할 때 유지보수를 고려한 구조와 설계를 적용하고, 소프트웨어 유지보수를 위한 방법론과 도구를 제공한다.

 소프트웨어 유지보수는 개발된 소프트웨어를 업데이트하고 버그를 수정하는 것을 말하는데,  소프트웨어 공학의 방법론과 도구를 사용하면 소프트웨어의 유지보수를 효율적으로 할 수 있다.

소프트웨어 공학에서 다루는 내용

 목표를 달성하기 위해서 소프트웨어 공학은 소프트웨어 개발의 생명주기(Life cycle)를 다룬다. 생명주기는 소프트웨어를 개발하는데 필요한 전 과정을 의미하는데, 이 과정을 간단하게나마 하나씩 살펴보자.

1. 요구사항 분석 및 정의

 소프트웨어 개발의 첫 단계는 요구사항 분석과 요구사항 정의다.

 이 단계에서는 소프트웨어의 목적과 기능, 비기능적 요구사항, 제약사항 등을 파악하고 파악한 요구사항을 문서화하는 작업이 이뤄진다. 위 그림에서 1단계와 2단계에 해당한다.

2. 설계

 요구사항 분석 단계 이후에는 소프트웨어의 설계를 수행한다.

 이 단계에선 요구사항에 기반해 시스템의 전체적인 구조를 설계하고, 소프트웨어의 모듈화와 인터페이스 등을 정의한다.

3. 구현

 설계 단계 이후에는 소프트웨어를 실제로 개발하는 구현 단계를 거친다.

 이 단계에서는 설계된 시스템을 기반으로 코드를 작성하고, 소프트웨어 모듈을 통합하는 작업이 이뤄진다.

4. 검증 및 검사

 소프트웨어 구현 단계 이후에는 검증과 검사 단계를 수행한다.

 이 단계에선 소프트웨어가 목표하는 요구사항을 충족시키는지 확인하고, 오류를 검출하고 수정하는 작업이 이뤄진다.

5. 유지보수

 소프트웨어를 개발하고 검증하는 단계 이후에는 유지보수하는 단계다.

 이 단계에서는 소프트웨어를 운용하면서 발생하는 문제점을 수정하고, 소프트웨어를 업그레이드하고, 추가 기능을 개발하는 등의 작업을 수행하게 된다.

소프트웨어 공학에서 사용하는 방법론

1. 폭포수 모델(Waterfall Model)

 폭포수 모델은 소프트웨어 개발 생명주기의 진행이 위에서 아래 단로 폭포수처럼 흐른다고 해서 지어진 이름이다선형적으로 처리하는 방법론이다. 각 단계에서의 결과물을 다음 단계로 전달하는 방식으로 진행되는 방식이다.

 각 단계를 순서대로 거쳐가는 가장 고전적이고 전통적인 개발방식이다. 

2. 프로토타입 모델(Prototype Model)

프로토타입 모델은 초기 요구사항을 분석하고, 이를 바탕으로 프로토타입을 만드는 방법론이다. 이를 통해 초기 요구사항의 정확성을 확인하고, 수정된 요구사항에 따라 반복적인 개발을 수행한다.

3. 애자일 모델(Agile Model)

애자일 방법론은 개발 초기부터 요구사항이 계속 변경될 수 있음을 전제로 하고, 짧은 주기로 반복적인 개발을 수행하는 방법론이다. 이를 통해 초기에는 빠르게 결과물을 도출하고, 수정이 필요한 부분은 유연하게 대처할 수 있는 모델이다.

소프트웨어 공학과 DevOps

 소프트웨어 공학과 DevOps는 서로 연관되어 있다고 볼 수 있다.

 소프트웨어 공학은 소프트웨어 개발 과정을 체계적으로 관리하여 효율적인 개발을 지원하고, DevOps는 이러한 개발 프로세스를 자동화하여 빠르고 안정적인 배포를 가능케 한다.

 그리고 DevOps는 개발자와 운영자 간의 협업을 강화하여 개발 프로세스와 운영 프로세스를 통합하는 것을 지향한다.

 이러한 협업은 소프트웨어 개발의 생산성과 품질을 더욱 높이는 시너지 효과를 발휘할 수 있다.

 그래서 소프트웨어 공학과 DevOps는 서로 보완하는 관계라고 할 수 있, 협업을 통해 효율적인 개발과 안정적인 운영을 지원하는데 중요한 역할을 한다.

HTTP 응답 코드는 HTTP 요청에 대한 서버의 응답을 나타내는 3자리 숫자를 말한다.

이 숫자는 해당 요청이 성공했는지, 실패했는지, 그리고 어떤 종류의 오류가 발생했는지를 나타낸다.

응답코드는 크게 5개 분류로 나뉘는데 100, 200, 300, 400, 500번대이다.

상태코드의 분류별 특징

• 100번대 (처리 중) : 이 코드는 요청이 수신되었으며 처리가 계속되고 있다는 것을 말해준다. 일반적으로 클라이언트의 추가 작업이 필요하다. 예를 들어 101 Switching Protocols는 서버와 클라이언트 간의 프로토콜을 변경했다는 뜻이다.

• 200번대 (성공): 200번대 응답 코드는 성공적으로 처리되었음을 나타낸다. 예를 들어, 200 OK는 요청이 성공적으로 처리되었다는 것을 나타내며, 201 Created는 새로운 리소스가 성공적으로 생성되었다는 것을 나타낸다.

• 300번대 (리다이렉션): 300번대 응답 코드는 리다이렉션을 말한다. 즉, 요청한 리소스가 다른 위치에 있고, 새로운 위치로 이동하도록하는 요청이다. 예를 들어, 301 Moved Permanently는 요청한 리소스가 영구적으로 새로운 URL로 이동되었다는 것을 나타내며, 302 Found는 요청한 리소스가 일시적으로 새로운 URL로 이동되었다는 것을 말한다.

• 400번대 (클라이언트 오류): 400번대 응답 코드는 클라이언트 오류를 나타낸다. 즉, 클라이언트가 요청한 것이 잘못되었거나 부적절한 경우에 볼 수 있다. 예를 들어, 400 Bad Request는 클라이언트가 유효하지 않은 요청을 보냈다는 것을 나타내며, 401 Unauthorized는 클라이언트가 인증되지 않았다는 것을 나타낸다.

• 500번대 (서버 오류): 500번대 응답 코드는 서버 오류를 말해준다. 즉, 서버에서 요청을 처리하는 동안 문제가 발생한 경우다. 예를 들어, 500 Internal Server Error는 서버에서 오류가 발생했다는 것을 나타내며, 503 Service Unavailable은 서버가 일시적으로 사용 불가능하다는 것을 말해준다.

각 응답 코드는 위처럼 분류된다.

세부 상태코드 의미

1xx - Informational (정보)

2xx - Successful (성공)

3xx - Redirection (리디렉션)

4xx - Client Error (클라이언트 오류)

5xx - Server Error (서버 오류)

 HTTP 응답 코드는 클라이언트와 서버 간의 통신에서 중요한 역할을 한다. 그래서 이러한 응답 코드의 세부 내용을 이해하고 적절히 대응하는 것이 중요하다.

 물론 이 외에도 많은 상태코드들이 있다. 이외의 상태코드에 대해서는 아래 링크를 통해 확인하면 좋을 것 같다.

참고 : https://developer.mozilla.org/ko/docs/Web/HTTP/Status

HTTP의 메소드

HTTP 프로토콜은 다양한 메소드를 지원하고 있다. 이 중에서도 가장 많이 사용되는 메소드는 GET, POST, PUT, DELETE, 등이 있는데, 이 중에서 GET과 POST는 각각 읽기(read)와 생성(create)과 관련된 메소드로, PUT과 DELETE는 각각 수정(update)과 삭제(delete)와 관련된 메소드다.

이와 같은 HTTP 메소드들은 대부분 CRUD 작업과 관련이 있다. 

CRUD(create/read/update/delete)

CRUD는 데이터베이스에서 자주 사용되는 개념으로, 데이터를 생성(Create), 읽기(Read), 수정(Update), 삭제(Delete)하는 기본적인 작업을 의미합니다.

이를 위해서 데이터베이스는 다양한 쿼리문을 제공한다.

아래는 각각의 CRUD에 해당하는 쿼리문 예시다.

• CREATE (생성)

DB에서 새로운 데이터를 추가할 때 CREATE 쿼리문을 사용한다. CREATE 쿼리문은 어떤 데이터베이스를 사용하느냐에 따라 다르지만 대부분 다음과 비슷한 구문을 갖는다.

INSERT INTO <테이블 이름> (<컬럼1>, <컬럼2>, ... <컬럼n>) VALUES (<값1>, <값2>, ... <값n>);

여기서 <테이블 이름>은 데이터를 추가할 테이블의 이름이며, <컬럼>은 새로 추가하려는 레코드의 각 필드를 나타낸다.

<값>은 새로 추가하려는 레코드의 각 필드에 들어갈 실제 값을 말한다.

예를 들어, users라는 테이블에서 새로운 사용자를 추가하려면 다음과 같은 쿼리문을 사용하면 된다.

INSERT INTO users (name, email, age) VALUES ('John', 'john@example.com', 30);

• READ (읽기)

DB에서 레코드를 검색하려면 READ 쿼리문을 사용한다. READ 쿼리문은 보통 다음과 같은 구문을 갖는다.

SELECT <컬럼1>, <컬럼2>, ... <컬럼n> FROM <테이블 이름> WHERE <조건>;

여기서 <컬럼>은 검색하려는 레코드의 각 필드를 나타낸다. <테이블 이름>은 데이터를 검색할 테이블의 이름이며, <조건>은 검색할 레코드를 선택하는 조건이다.

예를 들어, users라는 테이블에서 이메일이 'john@example.com'인 사용자를 찾으려면 다음과 같은 쿼리문을 사용한다.

SELECT name, email, age FROM users WHERE email='john@example.com';

• UPDATE (갱신)

DB에서 레코드를 갱신하려면 UPDATE 쿼리문을 사용합니다. UPDATE 쿼리문은 다음과 같은 구문을 갖는다.

UPDATE <테이블 이름> SET <컬럼1>=<값1>, <컬럼2>=<값2>, ... <컬럼n>=<값n> WHERE <조건>;

여기서 <컬럼>은 변경하려는 레코드의 각 필드를 나타낸다. <테이블 이름>은 데이터를 검색할 테이블의 이름이며, <조건>은 변할 레코드를 선택하는 조건이다.

예를 들어, "Customers"라는 테이블에서 "CustomerID"가 1인 레코드의 "ContactName"을 "John Smith"에서 "Peter Lee"로 바꾸는 쿼리문은 아래와 같다.

UPDATE Customers SET ContactName = 'Peter Lee' WHERE CustomerID = 1;

• DELETE (삭제)

DB에서 테이블에서 레코드를 삭제합니다. DELETE 쿼리문은 다음과 같은 구조를 가진다.

DELETE FROM <테이블 이름> WHERE <조건>;

예를 들어, "Customers"라는 테이블에서 "CustomerID"가 2인 레코드를 삭제하려면 다음과 같이 쿼리문을 작성하면 된다.

DELETE FROM Customers WHERE CustomerID = 2;

HTTP 메소드와 CRUD

이러한 관점에서 HTTP 메소드와 CRUD를 짝지어 봤다.

• GET: Read
• POST: Create
• PUT: Update
• DELETE: Delete

이렇게 메소드와 CRUD를 적절하게 짝지은 이유는 각각의 메소드가 수행하는 작업과 CRUD의 개념이 비슷하기 때문이다. 예를 들어, GET 메소드는 데이터를 읽어오는(read) 용도로 사용되기 때문에, CRUD의 Read 작업과 매칭된다.

마찬가지로, POST 메소드는 새로운 데이터를 생성(create)하기 위해 사용되기 때문에, CRUD의 Create 작업과 매칭된다.

POST와 PUT은 모두 데이터를 생성 또는 수정하는 용도로 사용된다.

그러나 POST는 새로운 데이터를 생성하는 데 사용되며, 서버가 해당 데이터의 위치를 결정한다. 반면, PUT은 특정 리소스를 업데이트하는 데 사용된다.

PUT은 리소스의 URI를 지정하고 해당 리소스의 내용을 업데이트한다. 즉, POST는 서버가 데이터 위치를 결정하지만, PUT은 클라이언트가 명시적으로 리소스 위치를 지정한다는 차이가 있다.

따라서, POST와 PUT은 크게 다른 용도로 사용되며, 사용 시에 목적에 따라 적절한 메소드를 선택해야 한다.

HTTP 프로토콜

 HTTP(Hypertext Transfer Protocol)는 인터넷에서 데이터를 주고받는 데 사용되는 프로토콜 중 하나이다. HTTP는 웹 브라우저와 웹 서버 간의 통신을 위해 개발되었으며, HTML, CSS, Javascript 등의 문서를 전송하기 위한 표준 프로토콜로 사용된다.

 HTTP는 클라이언트-서버 모델을 따르며, 클라이언트(보통은 웹 브라우저)가 서버에 요청(Request)을 보내고, 서버는 클라이언트에게 응답(Response)을 보낸다. 이때, 요청과 응답은 HTTP 메시지라는 형식으로 전송된다.

 HTTP는 기본적으로 평문(Plain text)으로 데이터를 전송하기 때문에  데이터의 기밀성과 보안에 취약점이 존재한다. 따라서, 이 문제점을 보완하기 위해서 HTTP보다 보안성이 높은 HTTPS가 등장했다.

HTTPS 프로토콜

 HTTPS(Hypertext Transfer Protocol Secure)는 HTTP 프로토콜의 보안 강화 버전입니다. HTTPS는 HTTP와 마찬가지로 인터넷 상에서 데이터를 주고받는 데 사용되며, SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화하고 보호해준다.

 HTTPS는 HTTP와 달리, 클라이언트와 서버 간에 암호화된 통신 채널을 사용합니다. 이 암호화된 통신 채널을 통해 데이터가 전송되기 때문에, 중간자 공격(네트워크 통신을 조작하는 보안 공격)과 같은 보안 위협으로부터 보호받을 수 있다.

 HTTPS의 동작 방식은 이렇다.
.

1. 클라이언트는 서버에 접속하고, SSL/TLS 암호화 방식을 사용하여 인증 요청을 보낸다.
2. 서버는 인증서를 클라이언트에게 보내고, 클라이언트는 이 인증서가 신뢰할 수 있는지 확인한다.
3. 클라이언트와 서버 간에 공유된 비밀키를 사용하여 데이터를 암호화하고 전송한다.

참고 : https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

https://www.ibm.com/docs/ko/aix/7.1?topic=systems-client-server 

nslookup 명령은 DNS에 질의해 도메인 정보를 조회하는 명령어다. host명령어를 사용해도 비슷한 결과를 조회할 수 있다.

nslookup 명령어 사용(도메인, ip)

가장 단순한 사용법이다. 

#nslookup명령어로 google.com도메인의 정보를 조회
~$ nslookup google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.206.238
Name:   google.com
Address: 2404:6800:400a:80c::200e


#비슷한 결과를 낼 수 있는 명령어인 host명령어 사용
~$ host google.com
google.com has address 172.217.25.174
google.com has IPv6 address 2404:6800:400a:80a::200e
google.com mail is handled by 10 smtp.google.com.

결과에서, 첫 번째 두 줄은 DNS 서버 정보를 보여준다. "Server"는 현재 사용 중인 DNS 서버의 IP 주소를, "Address"는 DNS 서버의 포트 번호를 나타낸다.

세 번째 줄은 "Non-authoritative answer"로 시작한다. 이는 조회한 정보가 공식적인 출처에서 제공된 것이 아니라, DNS 서버의 캐시에서 가져온 것이라는 의미다.

마지막 두 줄에서는 조회한 도메인 이름과 해당하는 IP 주소가 표시된다. 위의 예시에서는 "www.google.com" 도메인 이름의 IP 주소가 "142.250.206.238"임을 알 수 있다.

특정 DNS 서버에서 조회

조회할 때 사용할 DNS 서버의 ip주소도 지정해서 명령어를 사용할 수 있다.

#nslookup (도메인/IP) (DNS 서버 IP)
~$ nslookup google.com 168.126.63.1
Server:         168.126.63.1
Address:        168.126.63.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.207.110
Name:   google.com
Address: 2404:6800:400a:80b::200e

결과는 거의 같은 것을 볼 수 있지만 질의한 DNS 서버가 달라 

Server와 Address가 따로 DNS 서버를 지정해주지 않았을 때와는 다른 것을 볼 수 있다.

질의 타입 지정

어떤 것을 질의할지 타입을 지정해서 정보를 조회할 수도 있다.

이때, '-query=[type]' 옵션을 사용한다.

#mx(메일 서버)타입의 결과를 질의
~$ nslookup -query=mx google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
google.com      mail exchanger = 10 smtp.google.com.

Authoritative answers can be found from:
smtp.google.com internet address = 64.233.187.26
smtp.google.com internet address = 64.233.188.27
smtp.google.com internet address = 74.125.203.26
smtp.google.com internet address = 74.125.203.27
smtp.google.com internet address = 74.125.204.27
smtp.google.com has AAAA address 2404:6800:4008:c03::1a
smtp.google.com has AAAA address 2404:6800:4008:c03::1b
smtp.google.com has AAAA address 2404:6800:4008:c04::1b
smtp.google.com has AAAA address 2404:6800:4008:c05::1b

위에서 사용한 mx타입 외에도 다른 타입들을 조회하는 것도 가능하다.

• NS (name server)
• ANY (호스트에 관련된 모든 정보)
• UINFO (사용자 정보)
• MINFO (메일 리스트 정보)
• PTR (IP 주소에 대한 호스트명)
• A (각 호스트에 대한 IP주소)
• LOC (해당 도메인의 물리적인 위치)

이 외에도 많은 정보를 조회할 수 있는데, 그에 대한 옵션들은 https://en.wikipedia.org/wiki/List_of_DNS_record_types 에서 확인할 수 있다.

Interactive Mode

아무 옵션도 인자도 주지않고 명령어를 실행하면 Interactive(상호작용) 모드가 실행된다.

사용자가 원하는 만큼 질의를 할 수 있다. 조회하는 질의 타입은 set query=[query]로 실행한다.

~$ nslookup
> google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.206.238
Name:   google.com
Address: 2404:6800:400a:805::200e
> set query=mx
> naver.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
naver.com       mail exchanger = 10 mx3.naver.com.
naver.com       mail exchanger = 10 mx2.naver.com.
naver.com       mail exchanger = 10 mx1.naver.com.

Authoritative answers can be found from:
mx1.naver.com   internet address = 125.209.238.100
mx2.naver.com   internet address = 125.209.238.137
mx3.naver.com   internet address = 125.209.222.14