1. DevOps란 무엇인가?

DevOps란, 개발(Dev) 과 운영(Ops)이 결합해 탄생한 문화 또는 개발 방법론으로 빠른 시간에 사용자의 요구를 반영 할 수 있도록 소프트웨어를 만들고자 하는 목적을 갖고 있다.

2. DevOps 이전의 문제

이전 회사에서 나는 기획으로부터 업무를 부여 받고 개발을 완료하면 테스트를 거치고 배포 전담 팀에서 배포를 진행하는 방식으로 진행하였다. 이와 같은 방식은 문제가 발생했을 때 본인이 아는 범위 밖에서 문제가 발생하게 되면 운영, 개발 팀 간 서로에게 떠넘기는 상황이 발생한다는 것이다.

이를 해결하기 위해 개발과 운영을 단일팀으로 병합하고 빠르고 쉽게 사용자의 요구 사항을 처리할 수 있도록 처리하는 것이 DevOps이다.

3. DevOps 특징

몇 가지 DevOps의 특징을 정리해보면

Cross Functional Team

각 프로세스를 담당하는 사람들을 하나의 팀으로 모으라는 뜻으로 개발, 배포, 테스트 등 하나의 팀에서 처리해야 한다는 특징이다.

Widely Shared Metrics

서비스를 이용하는 사용자의 반응, 서비스의 안정성, 서비스 운영이 잘 돌아가고 있는지 등을 나타내는 하나의 공유된 지표가 필요하다는 것

Automating repetitive tasks

반복적인 수작업을 줄이고 CI/CD를 활용해 자동화된 툴을 이용하는 것을 의미한다.

Post Mortems

시스템 장애가 발생 했을때 팀원들과 소통하며 공유해야 한다.

Teamwork Over Individual Work

팀워크가 중요하며 서로를 존중하되 아이디어에 동의하지 않아야 한다.

또한, 피드백을 주고 받으며 필요 시 도움을 청할 수 있어야 한다.

참고

• https://aws.amazon.com/ko/devops/what-is-devops/
• https://imbf.github.io/devops/2020/10/28/What-is-The-DevOps.html
• https://m.blog.naver.com/acornedu/221519913222

Props

📢 Props란 부모 컴포넌트에서 자식 컴포넌트로 데이터를 전달할때 사용되는 단방향 데이터 전달 방식이며
반대 방향으로는 전달되지 않습니다.

또한, 부모 컴포넌트가 업데이트 될 때 마다 자식 요소 prop들도 최신 값으로 업데이트 됩니다.

<div id="app">
    <!-- <app-header v-bind:프롭스 속성 이름="상위 컴포넌트의 데이터이름"></app-header> -->
    <app-header v-bind:propsdata="nameText"></app-header>
</div>

// 자식 컴포넌트
var appHeader = {
    template: '<h1>{{propsdata}}</h1>',
    props: ['propsdata']
}

// 부모 컴포넌트
// 
new Vue({
    el: '#app',
    components: {
        'app-header': appHeader
    },
    nameText: "blackmount22"
})

부모 컴포넌트인 Root 컴포넌트에는 nameText라는 데이터명으로 “blackmount22” 문자열을 갖고 있고, 이를 자식 컴포넌트인 AppHeader 컴포넌트에 데이터를 전달할 수 있습니다.

아래 소스에서 부모 컴포넌트의 nameText 데이터를 자식 컴포넌트의 프롭스 속성 이름인 propsdata에 바인딩 하는 부분입니다.

<app-header v-bind:propsdata="nameText"></app-header>

상위 컴포넌트 (Root 컴포넌트)

하위 컴포넌트 (AppHeader 컴포넌트)

Root 컴포넌트의 nameText: “blackmount22” 값이 AppHeader 컴포넌트의 propsdata에 들어간 것을 확인 할 수 있습니다.

참고

https://kr.vuejs.org/v2/guide/components.html

GET

GET 메소드는 클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청하기 위해 사용되는 메소드

즉, 데이터를 읽거나, 검색 할때 사용되는 method로 예를 들면 게시판의 게시물을 조회할 때 사용된다.

GET은 요청을 전송할 때 URL 주소 끝에 파라미터로 포함되어 전송되며 이 부분을 Query String(쿼리스트링) 이라 부른다.

GET Method는 오로지 데이터를 읽을 때만 사용되며 수정할 때는 사용하지 않는다.

URL 예시) www.example.com?name1=john&name2=mount

GET 특징

• GET 요청은 캐시가 가능하다.
• GET 요청은 브라우저 히스토리에 남는다.
• 파라미터에 내용이 노출되기 때문에 민감한 데이터를 다룰 때 GET 요청을 사용해서는 안된다.
• GET 요청은 데이터 길이에 대한 제한이 있다.

POST

POST 메소드는 클라이언트에서 서버로 리소스를 생성/업데이트 하기 위해 데이터를 보내는데 사용되는 메소드

GET과 달리 POST는 전송할 데이터를 HTTP 메세지 Body에 담아서 전송한다.

그리고 Body의 타입은 요청 헤더의 Content-Type에 따라 결정된다

HTTP 메세지의 Body는 길이의 제한 없이 데이터를 전송할 수 있다. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있다.

URL 예시) www.example.com

POST 특징

• POST 요청은 캐시되지 않는다.
• POST 요청은 브라우저 히스토리에 남지 않는다.
• POST 요청은 데이터 길이에 제한이 없다.

GET / POST 차이점

• 사용 목적:
  • GET 메소드 : 서버의 리소스에서 데이터를 요청할 떄 (SELECT)
  • POST 메소드: 서버의 리소스를 새로 생성하거나 업데이트 할 때 사용 (CREATE)
• Body 유무:
  • GET: URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 Body가 없다
  • POST: Body에 데이터를 담아 보내기 때문에 HTTP 메시지에 Body가 존재
• Idempotent (멱등성):
  • GET 요청은 멱등이며, POST는 아니다

Idempotent(멱등성)

• Idempotent (멱등)의 수학적 개념은 다음과 같다
  • GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 똑같다.
  • POST는 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있다.(Non-Idempotent)
• → 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
  GET 과 POST는 이와 같이 큰 차이가 있기에 적절한 용도에 맞게 사용해야 합니다.
  
  

참조 페이지 : [https://velog.io/@songyouhyun/Get과-Post의-차이를-아시나요]

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

쿠키와 세션 사용 이유

 쿠키와 세션의 이해를 돕기 위해 HTTP 특징을 먼저 살펴보겠습니다.

 HTTP 프로토콜의 특징

  1. Connectionless(비연결지향)

     HTTP는 사용자가 Request(요청)를 서버에 보내면 서버는 클라이언트에게 Response를 주고 연결이 끊기는 특성이 있습니다.

  2. Stateless(상태없음)

     커넥션이 끊기는 순간 클라이언트와 서버의 통신은 완전 종료가 되며 상태 정보는 유지하지 않는 특성이 있습니다.

위와 같은 특징을 갖고 있기 때문에 서버의 리소스 낭비가 줄어드는 장점을 가지고 있지만, 이로 인하여 통신을 할때마다 서버는 클라이언트가 누구인지 인증을 계속해야 합니다. 즉, 로그인 후에 페이지를 이동하면 다시 로그인을 해야하는 상황이 발생할 수 있습니다.

하지만 위와 같은 Connetionless(비연결지향)과 Stateless(상태없음)를 보완해주며 서버가 클라이언트를 식별하게 해주는 것이 쿠키와 세션입니다.

쿠키(Cookie)

쿠키란, 사용자가 웹 사이트에 방문하였을때, 해당 사이트 서버에서 사용자의 컴퓨터(클라이언트 로컬)에 저장하는 작은 기록 정보 파일이며, HTTP에서 필요시 저장한 해당 정보(쿠키)를 참조하거나 재사용하여 사용합니다.

1. 쿠키는 클라이언트(브라우저) 로컬에 저장되며 (Key, Value) 형태로 구성되어 있습니다.

2. 쿠키는 사용자 인증이 유효한 시간을 명시 할 수 있으며, 유효 시간을 지정하면 브라우저를 끄더라도 인증이 유지되는 특징이 있습니다.

3. Response Header에 Set-Cookie 속성 사용하여 클라이언트에 쿠키를 만들 수 있습니다.

4. 클라이언트에 총 300개의 쿠키를 저장할 수 있습니다.

5. 하나의 도메인 당 20개의 쿠키를 가질 수 있습니다.

세션 쿠키 (Session Cookie) 와 지속 쿠키(Persistent Cookie)

세션 쿠키(Sesstion Cookie)란, 만료 날짜/시간을 지정한 쿠키를 말합니다.

세션 쿠키는 브라우저 메모리에 저장되므로 브라우저가 종료되면 쿠키는 사라지게 됩니다.

지속 쿠키(Persistent Cookie)란, 만료 날짜/시간을 지정하지 않아 항상 유지하는것으로 판단되는 쿠키를 말합니다.

지속 쿠키는 파일로 저장되므로 브라우저가 종료되어도 쿠키는 계속 남게 됩니다.

쿠키의 동작방식

1. 클라이언트가 브라우저에 접속하여 페이지를 Request(요청)

2. 서버에서 쿠키를 생성하여 HTTP에 쿠키를 포함하여 Response(응답)

3. 클라이언트가 서버에 재요청 시 응답 받은 쿠키 정보도 같이 HTTP 헤더에 담아서 Request(요청)

4. 서버에서 쿠키를 읽어 상태 정보를 변경할 필요가 있으면 쿠키를 업데이트하여 HTTP 헤더에 포함하여 Response(응답)

쿠키 사용 예제

1. ID 저장, 로그인 상태 유지

2. "오늘 더 이상 이 창을 보지않음" 체크

3. 쇼핑몰 사이트 장바구니

세션(Session)

쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저(클라이언트 로컬)에 저장하는 쿠키와 달리 서버 측에서 관리합니다.

1. 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다.

2. 클라이언트가 Request(요청)을 보내면, 해당 서버 엔진이 클라이언트에게 유일한 세션ID 값을 부여한다.

3. 사용자에 대한 정보를 서버에 저장하기에 쿠키보다 보안이 좋습니다.

4. 사용자가 많아질수록 서버 메모리를 많이 차지하게 됩니다.

세션의 동작방식

1. 클라이언트가 브라우저에 접속하여 페이지를 Request(요청)

2. 서버에서 세션에 클라이언트에 대한 데이터를 저장하고 이를 알 수 있는 세션ID를 생성하여 쿠키에 세션ID를 포함하여 Reponse(응답).

3. 클라이언트가 서버에 재요청 시 세션ID가 포함된 쿠키 정보도 같이 HTTP 헤덩 담아서 Requst(요청) 

4. 서버에서 세션ID가 포함된 쿠키 값을 읽어 세션ID의 상태 파악 처리 후 Request(응답)

결과적으로, 세션을 통해 클라이언트의 정보는 서버에 두고 세션 아이디를 이용해서 인증받고 정보를 이용하는 방식입니다.

세션 사용 예제

1. 로그인 정보 유지

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

DateTime 형식 ToString()으로 변환 시 문자열 처리

현재의 시간을 String형식으로 변환 시 사용 된다.

DateTime.Now.ToString("yyyy-MM-dd")	// "2020-12-18"

출처 : redppiriri.tistory.com/2