본 내용은 내일배움캠프에서 활동한 내용을 기록한 글입니다.
💻 TIL(Today I Learned)
📌 Today I Done
✏️ 리드미 작성
✏️ 더 고민해 보기
-
ERD를 작성할 때 Relation은 무엇이며, Relation의 종류 3가지를 예시를 들어 설명해 주세요.
-
Relation은 단어 그대로 테이블 간의 관계를 표현하는 것을 의미한다.
-
Relation의 종류로는 1:1 관계, 1:N 관계, N:M 관계가 있다.
-
1:1 관계의 예로, 한 명의 사용자는 하나의 상세 정보를 가지고 있다.
-
1:N관계의 예로, 한 명의 사용자는 여러 개의 게시글을 작성할 수 있다.
-
N:M 관계의 예로, 학원에는 여러 명의 학생이 있고, 학생도 여러 개의 학원을 다닐 수 있다.
-
-
비밀번호를 DB에 저장할 때 Hash를 이용했는데, Hash는 단방향 암호화와 양방향 암호화 중 어떤 암호화 방식에 해당할까요?
-
Hash는 단방향 암호화이다.
-
단방향 암호화는 암호화는 할 수 있지만, 원래 상태로 복호화는 불가능한 암호화를 의미한다.
-
비밀번호를 DB에 저장할 때 Hash를 이용해서 암호화하고 로그인 시 DB의 Hash된 비밀번호와 비교하기 위해서 사용자가 입력한 비밀번호도 Hash해서 DB의 비밀번호와 비교한다.
-
- 비밀번호를 그냥 저장하지 않고 Hash 한 값을 저장 했을 때의 좋은 점은 무엇인가요?
- 로그인과 같이 DB에 있는 비밀번호와 비교하는 작업에서 DB에 있는 비밀번호를 꺼내오는 것이기에 중간에 탈취될 위험성이 있기에 Hash를 통해 암호화된 비밀번호가 왔다갔다 한다면 중간에 탈취되어도 복호화가 불가능하기 때문에 비교적 안전하다.
-
JWT(JSON Web Token)을 이용해 인증 기능을 했는데, 만약 Access Token이 노출되었을 경우 발생할 수 있는 문제점은 무엇일까요? 위의 문제점을 보완하기 위한 방법으로는 어떤 것이 있을까요?
-
Access Token은 사용자가 로그인하면 발급 받아서 cookie 또는 header에 보관한다.
-
그래서 클라이언트는 이 Access Token을 가지고 각 기능들에 접근할 수 있다.
-
그런데 이러한 Access Token이 노출되면 원래 사용자가 아닌 다른 사용자에게 개인 정보 탈취나 데이터 삭제 등의 문제가 발생할 수 있다.
-
그래서 위와 같은 문제점을 다소 해결하기 위해서 Refresh Token을 사용한다.
-
Refresh Token도 마찬가지로 사용자가 로그인하면 발급받는다.
-
다만, Access Token과 다른 점은 Refresh Token은 DB에 저장해서 관리하고, Access 토큰을 재발급 받기 위한 토큰이라는 것이다.
-
토큰을 발급 받을 때 Access Token의 만료 기간을 짧게 하고 Refresh Token의 만료 기간을 길게 설정한다.
-
이를 통해 기능들에 접근하기 위한 Access Token이 탈취되어도 피해를 최소화 하는 것이다.
-
-
JWT를 이용한 인증 시 Cookie를 이용한 방식과 Header를 이용한 방식이 있는데, 각각은 어떤 상황에 사용하는 것이 적합한가요?
-
키를 이용한 방식은 주로 웹 애플리케이션과 같이 브라우저 기반의 환경에서 적합한 방식이다.
-
다만 CSRF 공격 방지를 위한 추가 보안 조치가 필요하다.
-
헤더를 이용한 방식은 API(RESTful API) 서비스나 다양한 플랫폼을 지원해야 하는 경우에 적합한 방식이다.
-
보안을 위해서는 HTTPS를 사용하고 적절한 토큰 만료 기간 설정이 필요하다.
-
-
인증과 인가가 무엇인지 각각 예시를 들어 설명해 주세요.
-
인증은 사용자가 인증된 사용자인지 검증하는 작업을 의미한다.
-
일반적으로 신분증 검사, 사이트의 로그인에 해당한다.
-
인가는 이미 인증된 사용자가 특정 기능(작업)을 수행할 권한이 있는지 검증하는 작업이다.
-
로그인된 사용자만 게시글을 작성할 수 있도록 검증하는 과정이다.
-
-
Transaction이 무엇이며, 어떤 경우에 사용해야 하나요?
-
트랜젝션은 작업의 완전성을 보장해주기 위해 사용되는 개념이다.
-
특정 작업을 전부 처리하거나 전부 실패하게 만들어 데이터의 일관성을 보장해야 하는 경우에 사용된다.
-
-
MySQL, Prisma로 개발했는데 MySQL을 MongoDB로 그리고 Prisma를 mongoose로 변경하게 된다면 많은 코드 변경이 필요할까요? 주로 어떤 코드에서 변경이 필요한가요?
-
MySQL을 MongoDB로 그리고 Prisma를 mongoose로 변경하게 된다면 상당히 많은 코드 변경을 가져올 수 있다.
-
데이터베이스 연결 방식, 데이터베이스 구조, 데이터 모델 정의, CRUD 등 대부분의 코드 변경이 필요하다고 생각한다.
-
-
만약 이렇게 DB를 변경하는 경우가 발생했을 때, 코드 변경을 보다 쉽게 하려면 어떻게 코드를 작성하면 좋을 지 생각나는 방식이 있나요? 있다면 작성해 주세요.
-
사실 SQL의 종류가 완전히 바뀌는 경우이기에 획기적인 아이디어가 떠오르지 않는다.
-
단순하게 데이터베이스 연결 방식, 데이터베이스 구조, 데이터 모델 정의, CRUD를 각 DB의 종류에 맞도록 모듈화해서 사용하는 방법밖에 생각나지 않는다.
-
✏️ 챌린지반 DB관련 녹화 영상 시청
-
Q. 여러분들이 데이터베이스 엔진을 만드는 프로그래머라고 가정을 합시다. 이 데이터베이스 엔진에는 이중화가 자체적으로 지원이 필수적이며 여러분의 상사가 이중화 기능을 구현해달라고 합니다. 어떤 논리로 이중화 기능을 구현해볼지 생각하고 여러분들의 아이디어를 공유해주세요!
-
A. 데이터베이스를 3가지로 나눈다.
기능을 담당하는 데이터베이스, 데이터를 담당하는 데이터베이스, 읽기를 담당하는 데이터베이스
이렇게 3가지로 나눠서 메인은 기능을 담당하는 데이터베이스가 그 역할을 한다.
그러다가 메인 데이터베이스에 문제가 발생하면 읽기를 담당하는 데이터베이스가
자신을 복제해서 읽기를 담당하는 데이터베이스를 만들고 자신이 기능을 담당하는 데이터베이스가 된다. -
Q. 나이가 31세 이상이거나 23세 미만의 축구 선수 이름만 갖고오기
SELECT Name FROM soccer_players WHERE Age >= 31 OR Age < 23- Q. soccer_players 테이블과 soccer_player_nations 테이블을 ID 컬럼 값이 일치하는 레코드만 JOIN 후 국가가 프랑스인 선수의 이름을 보여주기
SELECT A.Name FROM soccer_players A
INNER JOIN soccer_player_nations B ON A.ID = B.ID
WHERE B.Nation = '프랑스'- Q. 그림과 같은 스키마의 employees라는 테이블이 있습니다.
여기서, 연봉이 최대 5,000만원을 넘지 않는 부서 ID가 17인 사원들 + 부서 ID가 5번인 모든 사원들 + 커미션을 받는 사원들의 목록을 찾고 싶습니다. 어떻게 쿼리문을 작성하면 될까요?
SELECT Name FROM employees
WHERE (Salary < 50000000 AND Department_ID = 17) OR Department_ID = 5
OR Commision > 0- Q.
2022년 1월의 도서 판매 데이터를 기준으로 저자 별, 카테고리 별 매출액(TOTAL_SALES = 판매량 * 판매가) 을 구하여, 저자 ID(AUTHOR_ID), 저자명(AUTHOR_NAME), 카테고리(CATEGORY), 매출액(SALES) 리스트를 출력하는 SQL문을 작성해주세요. 결과는 저자 ID를 오름차순으로, 저자 ID가 같다면 카테고리를 내림차순 정렬해주세요.
SELECT A.AUTHOR_ID, A.AUTHOR_NAME, B.CATEGORY, SUM(C.SALES * B.PRICE) AS SALES
FROM AUTHOR A
INNER JOIN BOOK B ON A.AUTHOR_ID = B.AUTHOR_ID
INNER JOIN BOOK_SALES C ON B.BOOK_ID = C.BOOK_ID
WHERE C.SALES_DATE < '2022-02-01'
GROUP BY B.AUTHOR_ID, B.CATEGORY
ORDER BY B.AUTHOR_ID, B.CATEGORY DESC
📌 Tomorrow's Goal
✏️ 개인과제 해설 기반 과제 개선
-
과제 제출은 끝났으니 해설 영상을 기반으로 과제 개선하기
-
튜터님께서 구현하신 내용을 보고 다양한 유형을 경험하기
-
과제 개선하면서 필요한 부분은 따로 TIL로 정리하기
-
배포쪽은 조금 더 자세히 봐야 함
✏️ SQL 강의 시청하기
-
계속해서 Node.js 강의와 예비군 개인 과제 등등으로 너무 바쁜 시간을 보냄
-
그래도 개인과제 해설이 끝나면 약간의 시간을 이용해서 SQL 강의 시청하기
📌 Today's Goal I Done
✔️ 리드미 작성하기
-
이번에는 지난번 과제보다 구현한 내용이 많아서 리드미가 길어짐
-
그래도 TIL로 정리한 내용을 기반으로 작성하니 빠르게 작성할 수 있었음
-
리드미 작성을 프로젝트의 마무리로 하니 복기하기도 좋았음
✔️ 더 고민해 보기
-
과제에서 더 고민해 보기 라는 질문들을 줌
-
질문들은 대부분 이번에 시청한 강의, 진행한 과제를 기반으로 하는 질문들이었음
-
대부분은 과제하면서 알게 된 내용들이라서 쉬웠음
-
하지만 MySQL를 MongoDB로 바꾸는 방법에 대한 질문은 약간 어려웠음
-
생각해보면 SQL에서 NoSQL로 바꾸는 것이기에 코드의 구조, 형태가 전부 다를 것임
-
결국 이걸 쉽게 바꾸는 방법에 대해서는 정확한 답변을 하지 못함
-
인터넷에도 그저 각 스텝을 통해서 하나씩 바꾸는 방법인것 같음
⚠️ 구현 시 발생한 문제
✔️ 대상 그룹 상태 확인이 Unhealthy로 표기됨
-
배포를 진행하던 중 위와 같이 EC2 로드 밸런서의 대상 그룹에 Unhealthy라고 표시 되었음
-
그 옆으로는
Health checks failed with these codes: [404]라는 세부 정보도 있었음 -
검색해보니 AWS에서 다음과 같이 이야기 함
애플리케이션 로드 밸런서 한 az의 경우 정상으로 표시됩니다. 다른 az의 경우 아래 오류가 표시됩니다. 다음 코드로 인해 상태 확인이 실패했습니다.[404] -
음... 그냥 상태 확인이 실패했다고 함 (왜 실패한지 알고 싶은데...)
-
위 블로그를 확인하니 상태 체크 API를 따로 만들어주지 않아서 그렇다고 함
-
정말로 상태 검사를 진행하는 경로를 /api/products라고 정해놓았음
-
위 경로는 이전 과제를 배포할 때 지정한 것이기에 이번 과제의 API와는 맞지 않음
-
즉, 로드 밸런서의 대상 그룹은 위 상태 검사 경로를 통해서 정상적으로 동작하는 서버(API)인지 확인함
-
그런데 내가 경로 설정을 잘못하고, 상태 체크용 API를 만들지 않아서 Unhealthy라고 나온 것임
// app.js
app.get('/', (req, res) => {
return res.status(200).json({ message: '테스트' });
});
- 위와 같이 테스트용 API를 만들고 상태 검사에서 경로를 편집하니 아래와 같이 정상이라고 나타남 (변경하고 정상 표시까지 3~5분정도 소요됨)
