일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Spring
- SQL
- DDL
- jpa
- 바이너리 카운팅
- MSA
- stream
- 테스트 코드
- static
- equals
- Test
- 필드 주입
- DI
- java
- hashcode
- lambda
- 인덱스
- jwt
- AOP
- StringBuilder
- redis
- docker
- cache
- 생성자 주입
- select_type
- KEVISS
- 열 속성
- VUE
- 조합
- 재정의
- Today
- Total
백엔드 개발자 블로그
기술 면접 준비 시작 본문
0. 회사 정보 찾아보기
플래텀 기사
크레딧잡
원티드
위클리 구독 서비스
1. 기술 면접 영역
CS, 알고리즘 자료구조
CPU와 메모리
데이터베이스와 트랜잭션
네트워크와 인프라
시스템 디자인, 엔티티 설계
OOP, 디자인 패턴
소프트웨어 공학
문제 해결
개발 언어
프레임워크(Spring, Django)
애플리케이션의 장애 트래킹과 문제 해결방법
성능 향상 튜닝
비동기 아키텍처에 대한 이해
MSA
2. 자주나오는 질문들
프로세스와 스레드
동시성과 병렬성
데드락, 트랜잭션 격리 레벨, 트랜잭션 락
DROP vs TRUNCATE
JPA 1차/2차 캐시
OSIV
N+1문제
JPQL과 QueryDSL
브라우저에서 도메인을 호출한 뒤 페이지가 랜딩되기까지의 아키텍처와 흐름
Map, Set, List
Stack, Queue
트리와 힙
해시맵과 해시 테이블
HTTPS와 HTTPS
CORS
기본키, 외래키, 복합키
테이블과 인덱스, 인덱스의 활용
Mutable, Immutable
세션과 쿠키, 세션 스토리지
IoC와 DI
필터와 인터셉터
프레임워크와 라이브러리
RESTful 아키텍처
프록시와 리버스 프록시
SQL 인젝션, XSS
OAuth, JWT, Token
MSA
데이터가 쌓일 때 개선방법
- 인덱스 설계
- 파티셔닝 전략
- 정규화와 비정규화
- 쿼리 최적화
- 캐싱
- 백업과 복구
- 데이터 마이그레이션과 테스트
- 스케일 아웃
DB 구조나 설계방법
동기 vs 비동기 / 블록킹 vs 논블록킹
3. 기본적인 웹 환경의 아키텍처 설명
4. 백엔드 로드맵
1. 인터넷
2. 언어
3. Git
4. OS
5. RDBMS
6. NoSQL 및 DB
7. Scaling Databases
8. APIs
9. Caching
10. 웹 보안
11. 테스트
12. CI/CD
13. 소프트웨어 디자인&아키텍처
14. 설계 및 개발 원칙
15. 아키텍처 패턴
16. 메시지 브로커
17. 컨테이너화 vs 가상화
18. 웹 소켓
19. SSE
20. 웹 서버
21. Building for scale
5. 애플리케이션 성능 관리와 대용량 데이터 처리
1. 애플리케이션 성능 관리와 대용량 데이터 처리
성능 테스트 : 응답 시간, 안정성, 서버의 처리량 확인하는 절차
1-1. 성능 테스트 툴
JMeter, nGrinder
1-2. 모니터링 툴
서버에 설치
CPU, 메모리, 응답시간, 슬로우쿼ㅣ, 활성 스레드 분석, 로그 수집
유료 : 제니퍼 or 와탭 or 데이터독
nGrinder + 핀포인터 추천
1. 성능 테스트
- 프로덕션 자이봐 동일한 수준의 테스트 환경 구성
- 많이 호출되는 API를 테스트함
- 외부 API를 사용하는 경우 sleep time과 mock으로 변환
- 모니터링으로 알아내야할 항목
- 요청에 대한 응답 시간 추이 분석
- 최대 요청 임계치 분석
- 개선 포인트 식별
2. 장애 처리
- 1. 애플리케이션 튜닝
- 불필요한 로직 제거
- 슬로우 쿼리
- 테이블 관계 개선 (테이블 구조, 조인)
- 인덱스 개선
- 중복 쿼리 제거
- 커넥션 사이즈 조
- 2. 아키텍처의 개선
- 캐싱
- 비동기 처리
- 부하 분산
3. DB 개선
- 인덱스
- 데이터 변경이 잦은곳은 ㄴㄴ
- 조회 조건이 지나치게 많으면 ㄴㄴ
- 분포도가 좋은 곳에 적용하자(중복 적은곳)
- 단일 칼럼 인덱스 여러개 < 다중 컬럼으로 좁은 인덱스 구성하기
- 인덱스를 타지 않는 케이스 주의
- 인덱스 칼럼을 변경하는 조건절
- where substring(column1) = v1
- where concat(col1,' ',col2) = v2
- 부정형 비교 (not in, !=, >, <)
- LIKE 문장의 전체 범위 지정
- 인덱스 칼럼의 형변환
- 인덱스 칼럼을 변경하는 조건절
- 실행 계획 분석
- 사용법 : EXPLAIN SELECT COL1,COL2, .. FROM tablename WHERE ...
- 봐야할 사항
- select type : DEPENDENT UNION, UNION RESULT 인경우 튜닝 대상
- type : 행을 조회하는 방식 표현한 것, / ALL, INDEX 성능상 문제될 가능성이 높
- join type
- possible_keys : SQL문에 사용한 인덱스 키를 확인 - 다른 인덱스 or 사용되지 않으면 튜닝하자
- key_len : 인덱스의 바이트
- ref : 어떤 조건으로 조인한 것인지
- rows : SQL문이 접근한 모든 데이터 행수
- filtered : SQL을 통해 가져온 데이터가 필터 조건에 의해 어느 정도 제거 된 것인지
- extra : SQL문을 어떻게 수행할 것인지 / Using temporary, Using filesort가 튜닝 대
- 더미 데이터를 생성한 후 인덱스 실행계획과 쿼리 수행 속도를 점검하자
- 책 추천 : 업무에 바로 쓰는 SQL 튜닝 추천
- 커넥션 사이즈 조절
- 초당 요청 쿼리 수를 산정
- DB 서버의 성능을 바탕으로 피크 시간의 수용 가능 커넥션의 최대치 측정
- 중복 쿼리 제거
- 로직 레벨에서 처리할 수 있는 것들은 최대한 로직으로 풀어주자
- 조인 구문이 복잡하고 depth가 깊다면 조인관계를 풀어주고 따로 호출하
- 캐싱
- Redis
- 맴캐시드 : 단순하고 가벼워서 분산환경에서 많이 씀
- 고려사항
- 별도 장비 구축
- 커넥션 맺는 과정
- 네트워크 비용
- 운영비용
4. 대용량 테이블의 처리 기법
- Write, Read 분리와 복제
- Slave DB : Read
- Master DB : Write
- 파티셔닝 : 논리적인 테이블 분할 설계
- 샤딩 : 물리적으로 데이터를 분할하여 저장하는 방식
- 방식
- 모듈러 방식 : 균등하게 분할하기 위해 키의 모듈러 연산을 통해 결정하는 방식
- 레인지 방식 : 키의 범위로 데이터베이스를 분할하는 방식
- DBMS에서 지원안해서 애플리케이션 레벨에서 구현해야 됨
- 방식
5. 비동기 메시지 처리
- 즉시 응답 + 메시지 큐
- 인메모리 DB로 실시간 데이터 처리
6. 부하 분산을 위한 방법
- 로드 밸런싱
- MSA
7. 스케일 아웃, 스케일 업
6. API 설계 고려 사항
1. URL룰
2. 언더바 대신 - 사용
3. 소문자 사용
4. 단순하고 간단한 구조로 작성
5. URL에 HTTP메소드를 노출하지 않는다.
6. 리소스 URI에 항목보다 더 깊은 depth를 가져가지 않도록 한다.
7. 의미에 맞는 HTTP 상태를 반환한다.
8. API 버전을 명시한다.
9. 리소스에 대한 정렬, 필드에 대한 필터, 페이징은 쿼리 파라미터를 활용하여 담는다.
10. 문서로 자세히 정리되어 있어야 한다.
7. 배포 시스템 구축 시 고려사항
1. CI/CD
2. 배포 프로세스에 필요한 것
3. 배포 시스테믈 만들기 위한 기능 정의
9. 기술 면접 탈락 사례
이력서 내용 증명 못한 경우
CS 이론 모르는 경우