19.01.28 월요일

D + 15

음 오늘 드디어 일을 받았당

새로운거 공부하기,,,

다이나모디비 공부,,, 하다가 갑자기

firebase에서 OAuth 쓰는 법 공부하래소,, 중간에 OAuth 겁나 열심히 공부함ㅋㅋㅋ

1. NoSQL이 뭔지 조사&공부하기

2. dynamoDB 공부하기

3. docker 사용법 공부하기

4. dynamoDB 튜토리얼 하기

5. firebase이 뭔지 조사&공부하기

6. Oauth 조사&공부하기

7. firebase-oauth 구현 예제




1. NoSQL

1. SQL과 NoSQL의 차이

1. SQL은 관계형 DB라고 부르기도하며, NoSQL은 Not Only SQL이라는 의미로, 관계형 테이블인 SQL과는 저장을 위한 매커니즘이 다르다.

2. 관계형DB는 Scale-up의 형태로 DB를 만들고, NoSQL은 Scale-out의 형태로 DB를 만든다. 즉, 관계형DB는 추가적인 내용이 있을 때 기존의 DB에 덧붙여 DB의 덩치가 커지는 형식이고, NoSQL은 추가적인 내용이 있을 때 새로운 DB 시스템을 추가하는 형식이다. 그렇기 때문에 데이터의 양이 급격하게 늘어나거나, 시스템이 자주 바뀌는 구조일 때에는 NoSQL을 사용하는 것이, 시스템이 정적일 때에는 관계형 DB를 사용하는 것이 효율적이라고 볼 수 있다.




<https://brunch.co.kr/@kooslab/181>보면서 공부한 내용을 바탕으로 정리 하였습니다.




2. 비관계형 분산 저장 시스템이다.

3. NoSQL은 단순 검색 및 추가 작업에 있어서 최적화 된 키 값 저장 기법을 사용하기 때문에 응답 속도나 처리 효율이 뛰어나다.

4. 대량 데이터를 동시에 처리가 가능하다.

5. MongoDB는 Document Store 방식을 사용하고 DynamoDB는 Key-Value Store 방식을 사용한다.

2. DynamoDB

1. 데이터베이스 적용하기까지 시간이 적게 걸려서 배포와 확장이 단순하고 빠르다.

2. 데이터가 자동으로 복제된다.

3. 보조 인덱스를 통해 조회가 빠르며 응답시간이 빠르다.

4. 구조

1. Table

1. item들을 저장하는 곳을 말한다.

2. 테이블 크기에 제한이 없다.

3. 기본키를 반드시 지정해야 한다.

2. Item

1. attribute들의 모임을 말한다.

2. 기본키는 필수로 포함되어 있어야 한다.

3. Attribute

1. name과 value를 가진다.

2. key-value 방식이며 key는 문자열이다.

3. 스칼라 데이터 형식(String, Number, Binary)과 다중 값 형식(스칼라 데이터 형식의 배열Set)을 지원한다.

5. 로직

1. 기본키 형식

1. 기본키는 테이블이 생성될 때 무조건 지정 되어야하고, 이를 통해 DB에서 검색이 가능하다.

1. Hash 형식 기본키 : attribute하나를 기본 키로 사용하는 것을 말한다. 일치 방식의 검색만 지원한다.

2. Hash와 범위 형식 기본키 : attribute 2개를 기본키(복합키)로 사용한다. 일치, 부등호, 포함, ~로 시작하는 범위를 지정하여 검색이 가능하다.

2. 보조 인덱스

1. 성능을 위해 사용하며, read/write 용량 유닛을 따로 설정이 가능하다. 둘 다 테이블 당 5개까지 생성이 가능하며 테이블이 생성된 이후에는 추가, 수정, 삭제가 되지 않는다.

2. local secondary index

• 테이블에서 해시 기본키와 범위 기본키를 사용할 때만 사용 가능하다.

3. global secondary index

• 해쉬 키와 범위 키 모두 테이블 인덱스와 다르게 설정한 것을 말하며 범위키는 생략이 가능하다.

3. Docker

1. 도커란?

• 오픈 소스 컨테이너 가상화 플랫폼이라고 한다. 계층화된 파일시스템을 사용해서 가상화된 컨테이너의 변경사항을 모두 관리한다. 어느 플랫폼에서나 재현 가능한 어플리케이션 컨테이너를 만들어 주는 것을 목표로 한다. 도커는 하나의 어플리케이션을 격리된 공간(컨테이너)에서 독립적으로 실행할 수 있도록 해준다.

2. 도커 이미지 : 컨테이너에 넣을 프로그램 이미지를 말하는데, 도커 이미지는 읽기 전용의 템플릿이다. 이 이미지를 기반으로 도커 컨테이너를 동작시킨다.

3. 도커 컨테이너 : 도커 컨테이너는 디렉토리와 비슷한데, 실제로 실행되는 가상머신을 말한다. 격리된 공간에서 최초의 명령어를 실행하며, 미리 규정된 명령어를 실행하면 이미지가 동작하는데, 각 컨테이너는 도커 이미지에 의해 만들어지고 실행, 시작, 정지, 이동, 삭제할 수 있다.

4. 도커 파일 : 이미지를 생성하기 위한 배치 파일을 말한다.

5. 도커 인덱스 : 이미 만들어진 다양한 이미지들이 존재한다.

4. Firebase

1. Firebase란?

1. 웹/앱 개발에 필요한 기능을 제공하는 BaaS(Backend as a Service)이다.

2. 클라우드 서비스 제공자이며 백엔드의 기능까지 가지고 있다. 즉, 백엔드 기능을 클라우드 서비스 형태로 제공한다.

*  클라우드 서비스란? 인터넷 기반 컴퓨팅의 일종으로 정보를 자신의 컴퓨터가 아닌 인터넷에 연결된 다른 컴퓨터로 처리하는 기술을 말한다. 공유 컴퓨터 처리 자원과 데이터를 컴퓨터와 다른 장치들에 요청시에 제공해준다. 클라우드는  자원의 활용성과 효율성을 증가시킨다.

3. 프로젝트를 만들어서 어플리케이션 서버와 연결해서 사용하는 형태이다.

5. OAuth

* 생활코딩 보면서 공부한 것을 정리하였습니다(https://opentutorials.org/course/3405/22004)

1. OAuth란?

<id/pw 요청>

• user가 ‘나의 서비스’에 가입하려고 할 때 구글이나 페이스북과 같은 ‘다른 서비스’의 아이디와 비밀번호를 이용하여 가입이 가능하도록 구현을 한다면, 보안상에도 문제가 있을 것이고 신뢰성도 떨어질 것이다. 이를 구현하기 위해서는 OAuth를 이용하면 가능하다.

<토큰 발급>

• 아이디와 비밀번호를 직접적으로 제공하기보다 ‘다른 서비스’에서 일종의 토큰을 발급하여주면 ‘내 서비스’에서는 OAuth를 이용하여 회원가입이 가능하도록 구현할 수 있다.

• OAuth에서는 ‘다른 서비스’를 Resource Server라고 하며, user는 Resource Owner라고하며, ‘내 서비스’는 Client라고 한다. 이에 Authorization Server까지 OAuth를 구성하고 있는 주요 4가지 객체이다. 여기서는 Resource Server와 Authorization Server 이 두 서버를 하나의 Server로만 표현하겠다.

<OAuth 주요 객체>

2. 등록&인증(access token 발급 받기)

1. 클라이언트가 리소스 서버를 이용하기 위해서는 리소스 서버로부터 사전에 승인을 받아놓아야 하는데, 이를 register라고 한다.

2. 서비스마다 공통적으로 가지고 있는 요소

1. client id : 만들고있는 어플리케이션을 식별하는 식별자

2. client Secret : id에 대한 비밀번호

3. Authorized redirect URIs : Resource Server가 권한을 부여하는 과정에서 권한 코드를 부여해줄 때, 그 코드를 Resource Server가 이 URL로 전달한다.

3. Resource Server에서의 아이디와 패스워드, 그리고 어떠한 기능(B,C)을 가져와야 하는 것에 대한 정보를 Resource Owner에게 알려주고, Resource Server로 요청을 보내도록 하는 버튼의 링크는 다음과 같이 지정해 준다.



> https://resource.server/?client_id=1&scope=B,C&redirect_uri=http://client/callback

redirect_uri : 이동할 페이지(resource server 페이지)

scope : 해당 resource server에서 필요한 기능들

client_id : Owner의 id

4. Resource Owner가 위 그림과 같은 버튼을 눌러 Resource Server에 접근을 하면, 로그인 화면을 띄워주고 Owner가 로그인에 성공하게 되면 Resource Server는 버튼을 누르고 들어온 주소(https://resource.server/~)에서 클라이언트 아이디와 자신이 자신(리소스 서버)이 가지고 있는 클라이언트 아이디와 비교하고, uri값과 Authorized redirect URL값을 비교한다. 같다면 Resource Owner에게 scope에 해당되는 권한을 클라이언트에게 부여할 것인지 확인하는 메시지를 전송하고 owner로부터 승인을 받는다.



5. server가 authorization code(임시 비밀번호)를 헤더에 포함시켜 owner에게 전송함으로서 owner는 그 주소로 이동하게 된다. 그러면 client가 authorization code를 받게 된다.



6. authorization code를 통해 client는 resource server로 직접 접근할 수 있게 된다. 이때 resource server로 접근하는 url안에는 client id, client secret, authorization code, redirect URL이 있는데, 이 모든 것이 resource server의 해당 authorization code에 저장된 정보들과 일치하면 Access token을 발급해준다.



7. access token을 발급하여 주면, client와 server에 있는 authorization code는 삭제해 준다. 이제는 Owner의 회원 인증을 할 필요가 없기 때문이다.



8. server로부터 access token을 발급 받으면, client는 access token을 저장한다. 이때 이 access token이 역할을 정리하자면, Client가 저장된 access Token으로 접근을 하게 되면 Server에서 access token값을 확인하여 그에 맞는 정보를 가진 유저에게 정보를 제공한다.








ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

<<19.01.29 화요일 할 일>>

1. OAuth 개념 동영상 마저 보기(API부터)

2. Firebase란 무엇인가 공부하기

3. OAuth기능 사용해보기(예시 찾기)