[플레이데이터 풀스택 백엔드 9기] 6월 3주차 회고 (14주차)

서론

6월 3주차 회고 (14주차) - (6/16 - 6/22)

06/16 : 단위 프로젝트 (백엔드 커리큘럼)
06/17 : Ansible
06/18 : CircleCI
06/19 : Docker
06/20 : Logging & Monitoring

실습을 통한 DevOps의 주요 기술들을 살펴보는 한 주였습니다.

• Docker로 앱을 경량화된 컨테이너로 패키징해 어디서든 실행 가능하게 컨테이너화
• Ansible로 반복적인 서버 환경 구성 자동화
• CircleCI로 코드 변경 시 자동으로 테스트 및 배포

1. 내용정리

[DevOps]

DevOps

개념과 특징

• 지속적인 통합(CI), 지속적인 배포(CD), 자동화 등을 통해 더 빠른 소프트웨어 개발과 더 높은 운영 효율을 달성하려는 문화, 움직임, 관행의 집합
• 개발팀에게 ‘완료’의 의미는 요구사항을 구현하는 것
• QA팀에게 ‘완료’의 의미는 코드를 테스트하는 것
• 운영팀에게 ‘완료’의 의미는 코드를 릴리스하는 것

Ansible

개념과 특징

• 자동화 도구로 인프라 환경 설정, 배포, 서버 관리 등을 코드로 작성하고 자동 실행
• 별도의 소프트웨어 에이전트를 설치하지 않고도 시스템을 관리하고 모니터랑힐 수 있는 에이전트리스(Agentless) 기술
• 약 3000개 이상의 모듈을 통해 작업을 수행할 수 있으며, 각 모듈은 독립적으로 실행
• 같은 작업을 여러 번 실행해도 결과가 항상 동일하게 유지됨
• 인벤토리 파일을 통해 서버를 그룹 단위로 관리하고 클라우드 환경과도 연동 가능

구성 요소

• Inventory (인벤토리) : 관리 대상 노드의 목록 및 그룹을 정의 IP 또는 도메인 기반, 정적/동적 인벤토리 구성 가능
• Playbooks (플레이북) : 여러 Task를 순서대로 저장한 YAML 파일 반복 작업을 코드화하여 재사용 가능
• Modules (모듈) : Ansible의 기능 단위 코드 블록 (ex : ping, yum, copy, service 등) 수많은 모듈 제공
• Control Node (제어 노드) : Ansible이 설치된 시스템 /usr/bin/ansible, /use/bin/ansible-playbook 실행 가능 Python이 설치되어 있다면 대부분의 리눅스 / 유닉스 계열에서 사용 가능 Windows는 제어 노드로 사용 불가
• Managed Nodes (관리 노드) : Ansible이 제어하는 대상 서버 또는 네트워크 장비 변수의 에이전트나 Ansible 설치 불필요
• Tasks (작업 단위) : 모듈을 호출하여 실행하는 단일 명령 Playbook 또는 ad-hoc 명령으로 실행 가능

Docker

사용 순서
1. docker hub에서 계정 생성 및 로그인
2. 도커 이미지 다운로드
3. 도커 컨테이너 실행
4. 컨테이너 상태 확인
5. 컨테이너 삭제
6. 도커 이미지 삭제

명령어 저장소

도커 full 명령어	축약 명령어
docker image pull	docker pull
docker image ls	docker images
docker container run	docker run
docker container start	docker start
docker container ls	docker ps
docker container stop	docker stop

$ docker help : 도커 도움말
$ docker search --help : 도커 상세 사용 방법
$ docker search ubuntu : 도커 이미지 검색
$ docker image pull ubuntu : 이미지 다운로드 하기
$ docker image ls : 이미지 목록 보기
$ docker container run -d --name ubuntu_test ubuntu : 컨테이너 실행하기
$ docker container ls : 실행중인 컨테이너 목록 조회하기
$ docker attach ubuntu_test2 : 실행중인 컨테이너로 들어가기
$ docker container stop ubuntu_test2 : 실행중인 컨테이너 정지하기
$ docker container start 4b : 정지된 컨테이너 시작하기
$ docker container restart ubuntu_test2 : 컨테이너 재시작하기
$ docker container rm -f ubuntu_test2 : 컨테이너 삭제 시 -f 옵션 부여 후 삭제
$ docker container prune : 컨테이너 파기하기
$ docker image prune : 이미지 파기하기

$ docker run -d --name ubuntu_test3 ubuntu
$ docker ps -a
$ docker system prune

$ docker container run -it --name ubuntu_test3 ubuntu
$ docker container ls -a
$ docker container stats ubuntu_test3
`ctrl + C` : 실행 취소

CicleCI

개념과 특징

• CI/CD를 구현하는 실전 도구 중 하나가 CircleCI
• 코드가 변경되면 자동으로 실행되는 테스트·배포 서비스

구성 요소와 구조

• Pipeline: 전체 CI/CD 프로세스를 나타내며, .circleci/config.yml 파일로 정의됨
• Workflow: 여러 Job의 실행 순서와 조건을 제어하는 단위. 병렬 실행, 조건부 실행, 스케줄링 등 다양한 오케스트레이션이 가능
• Job: 빌드, 테스트, 배포 등 하나의 논리적 작업 단위. 여러 Step으로 구성됨
• Step: 실제 명령어(스크립트, 셀 명령 등)를 실행하는 가장 작은 단위

작동 흐름
1. 개발자가 GitHub에 코드 Push
2. CircleCI가 .circleci/config.yml을 읽고 작업 시작
3. 지정된 Job들을 실행 (ex. 빌드, 테스트, 배포)
4. 결과는 CircleCI 대시보드 또는 GitHub에서 확인 가능

2. 자격증 시험과 지필평가(오답노트)

6/20 SQLD 자격증 사전점수 발표

> SQLD 자격증 시험 사전 점수

첫 자격증 시험 SQLD의 사전 점수 공개 발표가 있었습니다. 예상한대로 48점이라는 결과로 합격 기준 60점에 많이 못 미쳤고, 다음 자격증 시험 SQLD와 ADsP가 있는데 우선적으로 8월에 있는 SQLD 자격증 시험, ADsP시험은 11월달로 준비할 생각입니다.

> 지필평가 오답노트

백엔드 오답노트를 작성하며 개념을 다시 공부했습니다.

[3. 서블릿 주요 메서드]
- init(ServletConfig config) : 서블릿이 처음 생성될 때 한 번 호출
- service(ServletRequest req, SevletResponse res) : 클라이언트의 요청이 들어올 떄마다 호출, 대부분의 요청 처리 로직 사용
- HttpServlet을 상속받으면 doGet(), doPost() 등으로 분기됨
- destroy() 서블릿이 종료될 떄 호출, 리소스 정리 작업 등에 사용

[4. 클라이언트의 요청처리]
클라이언트의 GET 요청을 처리하는 메서드는 doGet()
클라이언트의 Post 요청을 처리하는 메서드는 doPost()
클라이언트의 Put 요청은 "없으면 만들고, 있으면 교체한다"는 의미
클라이언트의 DELETE 요청을 처리하는 메서드는 

[6. JSP 실행 시 변환되는 파일]
Java Servlet로 변환됨

[8. 의존성 주입 주 목적]
객체 간 결합도 낮추기 위함
- 일반 자바코드에선 직접 new를 사용, Spring이 생성하고 주입하여 객체 생성
- 일반 자바코드에선 결합도가 높아 수정이 어렵지만, Spring에선 결합도가 낮아 유지보수와 테스트에 유리
- 일반 자바코드보다 Spring이 객체 교체가 쉬워 유연성이 낮음
[간단 예제코드]
자바 : UserService s = new UserService()
스프링 : @Autowired UserService s;

[10. @Autowired 자동 주입]
- Import 사용법
@Configuration
@Import(SecurityConfig.class)
public class AppConfig {
    // SecurityConfig의 설정도 함께 적용됨
}

[15. JPA의 역할]
- 자바 객체와 데이터베이스 테이블을 매핑, @Entity로 선언한 클래스는 테이블이 되고, 클래스의 필드는 테이블의 컬럼이 됨
- 영속성 컨텍스트를 이용해서, 엔티티 객체의 상태를 자동으로 추적하고 변화가 생기면 DB에 반영
- 트랜잭션 처리와 캐시해서 안정성을 확보
- JPQL을 사용하여 SQL과 비슷하지만 객체 중심으로 질의하는 쿼리 언어도 제공, 그래서 DB에 종속되지 않는 코드를 짤 수 있음

[16. JPA에서 기본 키를 설정할 떄 사용하는 어노테이션]
@Id
@Key - 존재하지 않은 키워드
@Primary - 존재하지 않은 키워드
@Generated - 기본 키 값을 자동 생성할 때 사용

[18. JPA의 영속성 컨텍스트]
엔티티 객체를 관리하는 일종의 메모리 내 캐시 공간
엔티티 객체를 영속 상태로 관리하는 공간
데이터베이스와 자동으로 동기화

[19. REST API의 HTTP 메서드 ]
GET은 조회 - 서버의 상태나 데이터를 가져오기만 함 
POST는 생성 - 서버에 새로운 리소스 생성 (중복 생성 가능 / 유일하게 역동성을 가지지 않음)
PUT은 수정 또는 생성 - 리소스 전체를 덮어쓰기 
DELETE는 삭제 - 리소스 삭제

응답코드
200 OK = 데이터 있음
204 No Content = 데이터 없음
201 Created = 신규생성

[20. REST API]
Spring에서 REST API를 구현할 때 @RestController를 사용

[21. REST API]
주요 특징
- 간단하고 직관적이며 HTTP만 알면 쉽게 사용 가능
- 확장성으로 다양한 플랫폼과 언어에서 사용 가능
- 유연하여 JSON 또는 XML 사용
- GET /posts/123 등과 같이 URL로 자원 표현

[23. Spring Cloud]
Spring Cloud는 MSA를 쉽게 구현하고 운영할 수 있도록 지원하는 것
분산시스템에서 발생하는 다양한 문제들을 해결하기 위해 설계된 프레임워크
두 가지 
- 핵심적인 컴포넌트는 Spring Cloud Gateway는 마이크로서비스 시스템 API 게이트웨이
- 구성 정보를 제공하는 서버 Spring Cloud Config Server

[24. Spring Cloud Gateway의 역할]
라우팅(Routing) : 클라이언트 요청을 적절한 마이크로서비스로 전달
필터링(Filter) : 요청/응답에 대해 인증, 로깅, 헤더 추가 등 전처리 및 후처리 수행
로드 밸런싱 : 여러 인스턴스 간에 트래픽 분산
보안 처리 : 인증/인가, 토큰 검증 등
서킷 브레이커 연동 : 장애 발생 시 fallback 처리 가능

[25. Spring Cloud Config Server의 역할]
구성 정보를 제공하는 서버
중앙 집중형 설정 관리: Git, S3, JDBC 등 외부 저장소에 설정 파일을 저장
환경별 설정 지원: application-dev.yml, application-prod.yml 등으로 환경 구분
실시간 설정 반영: Spring Cloud Bus 또는 Actuator를 통해 설정 변경을 서비스에 반영 가능
보안 강화: 민감한 설정 정보를 외부로 분리하여 관리

3. 마무리

> 좋았던 점과 아쉬웠던 점

회고를 통해 개념을 재학습하는 것은 좋았습니다.

> 개선할 점

루틴을 바로 잡고, 체력 관리에 신경 써서 학습 효율을 높일 생각입니다.

> 다음주 계획

파이널 프로젝트를 앞둔 시점에 대비하여 현 프로젝트에 집중하며 부족한 부분을 보완할 생각입니다.

1일 1코딩

(커리큘럼) 06/17 ~ 07/17 : 데브옵스
08/09 : ADsP 자격증 시험
08/23 : SQLD 자격증 시험
07/18 ~ 09/10 : 기업 참여 프로젝트