[기술면접 대비] Django, DRF, 배포

Django

👉 Django의 장단점은?

장점 : 관리자 admin 패널 제공, 기존에 개발되어 있는 다양한 패키지들이 많음, 로그인 로그아웃 등 미리 구현

단점 : 기본적으로 요소들이 다 포함되어 있기 때문에 오히려 무겁다는 점, 자유도가 떨어집니다.

 

👉 Django의 MTV 패턴 시스템은 무엇입니까?

Model : DB에 대한 ORM Model

Template : 사용자에게 보여지는 화면

View : 프로그램이 동작하는 비즈니스 로직 부분

 

참고 링크

[Django] MTV 패턴과 동작 Flow

 

👉 Django의 프로세스는 어떤 순서로 동작합니까?

• (1) 클라이언트에서 API 호출 (Request)
• (2) 웹서버 (Nginx, Apache) 요청 수신 및 WSGI 서버로 Request 정보(Header, Method, URL, Parameters, Data) 환경변수로 전달
• (3) WSGI 서버에서 web application(django)을 생성 (gunicorn이라면 prefork 방식으로 미리 생성) 및 관련 middleware (settings.py)를 차례대로 호출
• (4) urls.py의 endpoints 도착
• (5) views.py에 request 전달 및 비즈니스 로직 수행
• (6) Models는 ORM으로 DB 조회 후 Views에 결과 전달
• (7) Views 받은 정보를 Templates과 조합
• (8) Response 반환 (html or JSON)

 

참고 문헌

https://wookkl.tistory.com/60 // Django의 동작 원리와 과정 파헤치기
https://kodorricoding.tistory.com/23 // django 배포 nginx 와 uwsgi를 사용하는 이유 -2

 

👉 FBV와 CBV 란?

비즈니스 로직을 구현하는 Views.py의 두가지 방법 (Class Based View, Function Based View)

CBV는 객체 지향적으로 GenericView나 Viewset등으로의 추상화를 하기 쉬움, FBV는 보다 직관적

 

Django Authentication (인증)

👉 JWT의 Access Token과 Refresh Token은 왜 필요한가요?

Access Token : 클라이언트 본인을 서버에서 인증하는 역할 (expiration time 짧게)
Refresh Token : 유효 기간이 지나면 새로운 Access Token 생성 (expiration time 길게)

 

👉 Django의 인증 기능 vs JWT 로그인 인증 차이점

Django는 기본 Session Middleware를 통한 WAS에 유저 정보를 저장

JWT는 클라이언트에 유저 정보를 저장하여 관리함 

 

Django ORM

👉 ORM 이란?, 장단점

Object Relational Mapping으로 DB를 객체로 매핑하여 SQL문 없이 로직단에서 DB를 다룰 수 있게 해주는 것

 

장점 : 코드를 통해 DB를 관리 할 수 있어 직관적임
단점 : Query문이 복잡해지면 사용하기 힘듬, 성능 이슈 있을 수 있음

 

👉 Django ORM에서 queryset과 object의 차이점은?

object는 orm model에 따라 db에서 불러온 객체, queryset 은 그 object들의 list

 

👉 Django ORM에서 정참조와 역참조란?

정참조 : 해당 객체가 ForeignKey, 1대1 관계를 가질 때 다른 객체를 참조 하는 경우
역참조 : 해당 객체가 ForeignKey, ManyToMany 관계에 포함될 때 다른 객체를 역으로 참조하는 경우

 

👉 테이블 간의 관계를 나타내는 FK, OneToOne, ManyToMany 란?

OneToOne : 1대1 관계 (USER와 USERPROFILE)

ForeignKey : 1대 N, N대1 관계에 사용 (USER와 Article)

ManyToMany : N대 M (User와 hobby)

 

👉 CharField와 TextField 차이는?

CharField는 Text 길이 정의 필요 (비교적 짧은), Textfield는 길이 정의 필요 x  (비교적 긴)

 

Django Rest Framework (DRF)

👉 DRF의 Django와의 차이

Django는 풀스택 기반의 Library

DRF는 Restful API 서버를 Serailize(DB Data를 JSON으로 바꿈)를 통해 쉽게 만들 수 있게 해주는 라이브러리

 

👉 DRF 장점은?

API 쉽게 만들어주고, Serializer 기능을 제공함 (DB => JSON)

 

👉 DRF Serializer 란?

직렬화를 뜻하며, Django의 Queryset 객체를 JSON 타입으로 바꾸는 것

Python 데이터 객체를 문자열로 변환하는 작업 (=직렬화)

 

👉 DRF Serializer 역참조 방법?

A 테이블의 a1 필드가 B 테이블의 b1 field를 참조하고 있으면, b1 field를 통해 A테이블에 접근 하는 것 (table명_set , related_name 사용)

 

👉 Django Pagination 방법

- PageNumber Pagination : 요청하는 페이지(page) 번호(number)를 가져오는 방법

- LimitOffset Pagination : 요청하는 위치(offset)로 부터 데이터 갯수(limit)를 가져오는 방법

- Cursor Pagination : 요청 데이터 기준(Cursor)으로 앞, 뒤로만 이동할 때 사용

 

참고 링크 1

 

참고 링크 2

 

Django TestCode

👉 테스트코드를 작성하는 이유와 장점

코드가 의도한대로 작성됬는지 확인 가능, 개발간 예상치 못한 오류 확인 가능

유닛테스트를 작성할 때는 외부 컴포넌트와의 의존성을 제거하여 순수한 로직만이 테스트 되도록 해야함

 

👉 테스트코드에서 setup 함수와 setupclass의 차이는 무엇입니까?

setUpClass는 특정 클래스에 대해 한 번 실행

setUp은 특정 클래스의 각 Test 함수 전에 실행

 

Django Optimization (최적화)

👉 select_related, prefetch_related 이란?

Django의 ORM은 기본적으로 Lazy Loading이기에, iteration 구문 등에서 query 문이 불필요하게 많이 호출 됨

select_related, prefetch_related 모두 관계된 table까지 미리 다 불러와 caching 해주는 역할 수행

Query문이 복잡하게 호출되긴 하지만 모두 cache에 남게 되어 DB에 다시 접근할 필요가 없음

M:N이나 M:1 은 prefetch_related, 1:1, 1:M은 select_related에 주로 사용

 

👉 django select_related and prefetch_related 동작 방식

select_related - Inner join / prefetch_related - 각 table 별로 query 하여 가져옴 

ex) user의 company가 1:N 인 경우 레코드가 10개 100개 있다고 했을 때 select는 101개 query를 1개로, prefetch는 2개로 줄여줌

 

👉 Django의 F 객체

Concurrency 이슈로 race condition 상황이 발생했을 때, F 객체를 활용해 해당 작업을 Python 메모리가 아닌 DB 에서 작업을 처리함. 캡슐화된 SQL 구믄을 생성하여 보다 빠름.

 

👉 N + 1 Problem 이란?

테이블(A) 조회시 해당 테이블(A)의 갯수(N)만큼 연관 관계에 있는 테이블(B)의 조회 쿼리가 호출되는 현상

테이블(A) 전체 조회 1 + 테이블 (B) N번 호출 => N+1

 

Django 배포 (Deployment)

👉 Webserver (Nginx, Apache) 필요 이유

• WAS의 부하를 줄여주기 위함. 
• Webserver는 비즈니스 로직이 필요없는 정적 콘텐츠를 처리,
• 많은 트래픽의 로드밸런싱이나, SSL, 도메인 라우팅 관리 (proxy server)등의 작업을 수행하며 WAS의 부하를 줄임

 

👉 gunicorn 이란?

• django application을 실행 시켜 외부에서 오는 request를 전달 해주는 wsgi 서버
• prefork worker방식으로 process를 미리 생성해놓고, 요청 수신 및 수행한다.
• Gunicorn은 prefork 된 worker에 배분시 요청대기 큐를 통해 차례대로 배분

 

👉 was에 gunicorn 등의 서버가 필요한 이유

• Webserver와 웹 Application간의 interface 역할 (http <-> wsgi, 요청-응답)로 Webserver는 python, java언어 이해 못함
• 파이썬은 GIL 방식 때문에, 멀티 스레드에 비효율적이여서, Application 앞단에 Gunicorn을 두어 멀티 프로세싱으로 동작하게 하여 병렬적으로 처리
• 스레드 풀을 통한 작업 요청 스케쥴링 가능

 

👉 Django runserver 쓰지 못하는 이유 (gunicorn, uwsgi 등의 wsgi server 쓰는 이유)

개발상 편의를 위해 개발 되었고, 보안 상의 이유로 공식문서에서 사용하지 말라고 함.

개발 편의성 : runserver는 reload 옵션도 default가 true , gunicorn, uwsgi는 false임

 

performance도 gunicorn, uwsgi와 같은 server 가 더 좋음.

preformance 관련 참고 링크 : https://blog.lxf.kr/2018-08-13---ways-run-django-app/

django로 만든 사이트를 돌리는 방법들

 

WAS - WSGI, ASGI

👉 WSGI, ASGI 차이

WSGI (Web Server Gateway Interface

• HTTP 요청을 위한 인터페이스
• Webserver를 통해 받아오는 Request 정보(Header, URL, Data)를 웹 어플리케이션에 환경 변수로 전달
• 응답 callback 함수를 받는 요청/응답을 동기적으로 수행
• 추가로 미들웨어로서의 인증, 세션, 쿠키 관리, 에러 페이지 등의 기능 수행 가능.

 

하지만 긴 대기시간을 가진 HTTP 연결이나, 통신이 유지되어야 하는 WebSocket 연결 등엔 부적합하고, 비동기적으로도 처리 성능이 떨어짐

 

ASGI (Asynchronous Server Gateway Interface)

• ASGI는 비동기 라이브러리 기반으로 구현
• WebSocket, 대기 시간이 긴 HTTP 연결을 위한 인터페이스
• Send-Receive 함수를 비동기적으로 호출하여 이벤트 처리가 가능

 

👉 ASGI의 등장 배경

ASGI 이전에 WSGI는 비동기적인 기능인 웹소켓을 포함, 풀링 HTTP 통신을 하지 못했음. (HTTP는 단방향이고, WSGI는 그 단방향 통신을 위해 설계된 것이므로) 그래서 ASGI가 등장함 (양방향 통신에 대한 요구)

 

ASGI는 비동기적으로 다량의 네트워크 요청을 non-blocking으로 처리 가능