HCD 랩스 8월 4주차 - 현직자 강의

듣는 거 토대로 다 적어 놓기만 했고 교육 끝나고 다시 볼 예정. 하나도 이해 못하겠음.

8/27 - 백엔드 개발자 현업자분

HDC 랩스 백엔드 소개

• MSA 방식 선호
• 클라우드 친화적
• MSA = 작은 서비스들이 모여 큰 서비스를 만드는 구조
• 장점 = 빠른 개발, 쉬운 확장, 부분 장애에 강함

FARGATE = AWS가 서버 관리 없이 컨테이너만 실행할 수 있게 해주는 서버리스 실행 환경
장점

1. 서버 관리 불필요

2. 자동 확장성

3. 간단한 배포

   EC2 런치 타입
   1 자바 필요, 수도 깔기? 때문에 인력이 부족할때 fagate 사용이 편리

컨테이너 : 애플리케이션 + 실행환경 / 뭐 귀찮게 굳이 많이 깔 필요가 없음

일반적인 배포 단점 -> 컨테이너를 쓰면 아래 문제들을 없음

1. 서버마다 설정이 다르면 문제가 생김
2. 확장하려면 새 서버를 띄우고 똑같이 설치해야 해서 번거로움 -> 초기 설정 귀찮고 프젝이 바뀌면 의존성 잡고 jdk 잡고 번거로움
3. 장애가 나면 서버 직접 검토

컨테이너 기반 배포 : decker, kubernetes, ECS등등
docker 이미지 어디서든 실행 가능 하다.

정보 : docker, 키로, 커서 사용해보기, 코딩테스트 미리미리 공부하기(스터디)

---

네트워크 환경 구성

1. VPC 생성 EC2,

• 서비스를 구성하기 위해 일반 네트워크 환경과 유사한 환경

1. subnet 생성
2. 인터넷 게이트, 라우팅테이블 설정
3. 보안그룹 설정

• 인스턴스 생성
  bastio
  ec2 생성 - 보안그룹도 생성해야 함.

로드 밸런스 설정 : 조건문 요청 시 길을 닦아 놓는 것

1. 대상그룹 설정 특정 포트 요청 시 어디로 들어갈지 설정하는 것.
2. ip 주소 설정 : 초기 설정

aws : 이름 설정 지키는 것이 좋음

ECS

1. 태스크 설정 : gradle 설정, 도커 설정 후 이미지를 올려놨다 배포를 할때 태스크 설정

클러스터 , 배포 끝

배포 하는 방법(아직 이해는 안됨)
도커를 설정파일을 만들고 에코, env -> build 하고 쉘 파일 실행 태스크를 만들기 위한 이미지를 올리는 과정 - env 읽고 나눠진 레포지토리를 지정. 설정이 끝나면 ECR에 올라감 - 올라간걸 테스크 정의

• 태그 값을 고정하고 설정 기본값하고 생성하면 - 클러스터 가서 맞는 서비스 업데이트 (중요한점 : 전체 프로세스를 확인, 1. 도커, 도커 컨테이너(k8s(쿠버)), 2. 파게이트(fargate - 서버리스, 무중단배포) )
  프로토콜 : 서로의 통신 규격, 설정

• 파이프라인 - 도커를 말고 태스크~ 하고 하는 것으로 자동으로 하는 것

• 대용량 트래픽 카프카, rabbitmq 카카오

• 깃 버전관리 툴 젠킨스
  프로젝트 구조, - 테스트 코드

• 로그 : 네이밍 툴을 정해놓는게 좋음

정보
백단 - 트러블슈팅 경험, 자바, 코틀린도 배우면 좋고, 도커는 거의 필수, AI 활용능력
공고 - 안산학생 채용 공고
공부할 거 추천
1. 코딩테스트
2. 면접

• CS 핵심 질문
  • 네트워크 tcp와 udp의 차이
  • DB 인덱스 B+tree 개념
  • 트래픽 급증 대응; 캐시, 큐잉 수평화장, DB/ 샤딩/리드레플리카
  • HTTP VS HTTPS TLS 핸드셰이크, 인증서 체인, 성능 고려

8/28 벡엔드 개발자 현직자 2분

안전관제 서비스

실습 1. AI cctv 서비스 운영시 어떤 정책이 필요할까요?
운영 정책 초안 3개 작성
예)
카메라는 많고, 관리자는 다양한데 누구는 어디까지 접근할 수 있어야하지?
현장이 늘어날때마다 어떻게 구분하고 관리해야 하지?
2명이서 각자 예를 하나씩 맡아서 더 세분화 해봄.

1. 관리자 권한 구분 & 이유
   = 실시간 모니터링(개인정보 보호 목적으로 최소한만), 영상 녹화가 됐을 때 cctv에 관리(저장공간, 카메라 등등 작동이 원할한지) -> 개인정보는 막고 시스템 운영은 원할함, 서버 네트워크 관리 -> 시스템이 원할하게 돌아가게끔 운영
2. 실시간 모니터링 (지통실 cctv병)
3. CCTV 녹화 영상, 알림이 갔을 때 확인 가능
4. 서버, 네트워크 같은 시스템이 멈추지 않게 정상 작동

실습.2 시스템아키텍처 실습 - ppt로 제작

실습.3 API 실습 - AI CCTV 서비스 API 목록 작성 20개

1. 로그인 /api/users/login
2. 로그아웃 /api/users/logout
3. 사용자 정보 조회 /api/users/info/search
4. 수정 /api/users/info/edit
5. 삭제 /api/users/info/delete
6. 사용자 권한 조회 /api/users/grant/
7. 수정
8. 삭제
9. cctv 등록
10. 삭제
11. 수정
12. cctv 알림 목록 조회
13. 수정
14. 삭제
15. 녹화 영상 목록 조회
16. 삭제
17. 영상 다운로드
18. 실시간 영상 조회
19. 영상 날짜 조회
20. 위험 구역 지정

실습1. 개발 과정 중 만난 이슈
위험 구역 지정 -> ai 서버로 전달하여 이상 상태 확인. 화면에 맞게끔 하는 어려움. 불일치 문제 해상도

해결방법
5분동안 gpt 써봄

1. 사용환경 명시 또는 제한 -> 해상도는 몇입니다. 크롬에서 열어주세요 등등
2. 고정 해상도 및 상대 좌표 방식 사용 -> 비율 %로 -> 답
3. 반응형?으로 제작

• 개발 프로세스 ( WBS 초기 기간 설정)
  계획 - 설계(시퀀스 다이어그램, DB 명세서, API 명세서) - 구현(코드작성) - 테스트(QA) - 유지보수(배포 및 장애 개선)

• 모놀리식(개인) vs msa(회사 규모)
  한서버에서 돌아감 개발은 빠름 하나만 건들여도 모두 유지보수 해야함 VS 독립적 배포, 기술성 다양성, 확장성 우수 하지만 복잡성이 증가, 초기 구축 비용 증가

• inbase 플랫폼에 대한 설명과 구조

• 비동기 처리(동시 처리) (동기 방식 = 순차적 처리)
  = 백그라운드 처리 방식
  예) 동기 = 1초 x 5 = 5초. 비동기 = 1초

• ASPECT 지향 프로그래밍(AOP)
  = 공통 기능을 따로 분리해서 자동으로 적용해주는 기술
  중요한 로직을 aop로 추상화함으로써, 코드의 일관성과 보안성을 동시에 확보

실습1. 개발 과정 중 만난 이슈
위험 구역 지정 -> ai 서버로 전달하여 이상 상태 확인. 화면에 맞게끔 하는 어려움. 불일치 문제 해상도

해결방법
5분동안 gpt 써봄

1. 사용환경 명시 또는 제한 -> 해상도는 몇입니다. 크롬에서 열어주세요 등등
2. 고정 해상도 및 상대 좌표 방식 사용 -> 비율 %로 -> 답
3. 반응형?으로 제작

• AI 화재감지 서비스에 대한 설명 - 주차장 등 명세서

  참고용
  코테 cs https://won-percent.tistory.com/193

---

13~18 현직자 강의 플랫폼팀

ai 회의록 서비스

클라이언트 - 인베이스 서버 - ai 서버
회의 음성이 어디로 전달되고 텍스트로 바뀌는거 기능 설정하기 (어떤 기능들이 있었으면 좋았을지에 대해 찾아봤어야 했는데..)

기능 1 사용자가 회의를 시작합니다
기능 2 프론트엔드는 이 음성데이터를 백엔드로 보냅니다.
기능 3 백엔드가 음성을 저장합니다.
기능 4 ai 서버가 음성을 텍스트로 변환합니다.
기능 5 자연어 처리 방식을 이용해 회의 내용을 요약합니다.
기능 6 회의록 저장 및 관리합니다.
기능 7 중간 요약을 백엔드로 전다라
기능 8 백엔드로 최종 회의 요약을 전송

사용자가 회의를 시작합니다 -> 음성을 백엔드 서버에 전송 -> 음성을 받아서 ai 서버로 전송(음성을 서버로 보낼 때 스트리밍 방식처리로 0.5초에서 2초 단위로 잘라서 전송)
-> ai서버에서 음성을 텍스트로 변환, 발언자 구분, 회의 내용 요약한 것을 백엔드 서버로 전송 -> 백엔드 서버에서 다시 받아오고 최종 회의록을 DB에 저장
GPT로 찾아본 AI 서버에서 사용될 기술

1. 음성을 텍스트로 변환 -> ASR 엔진 사용(구글 STT, Whisper, Azure Speech)
2. 발언자 구분 -> Kaldi, pyannote.audio 같은 라이브러리 활용
3. 회의 요약 -> NLP(자연어 처리) 모델이 전체 대화에서 핵심 발언, 결론을 추출

API만으로 구현 불가, API는 클라이언트가 요청하면 서버가 다시 반환

웹소켓을 사용함 -> 전화하는 상태라고 생각하면 편함.
양방향 연결, 실시간, 계속 요청할 필요 없음
단점 : 보냈는데 응답이 없을 수 있음. 불필요한 서버 자원 낭비

서버가 알림을 보낸 상황만 필요 -> SSE 구조
서버가 클라이언트에게 필요할 때만 알려주는 방식

웹소켓 VS SSE ->

실습. 면접질문2 안정적인 아키텍처 설계를 해보시오.
실시간으로 음성 파일을 보냈을 때 일시정지, 서버 다운, 웹페이지가 나갔을 때 어떤 예외가 있을지? 인베이스 서버에서 어떤 문제가 있을까? 생각 30분 예를 들면 임시저장등
해당 서비스는 녹음이 완료되면 S3 버킷에 음성파일을 mp3 형태로 실시간 저장해야 합니다. 중간에 서비스가 예상치 못하게 종료될 경우에도 음성 파일을 안전하게 보관하기 위하여 안정적인 아키텍처와 서비스를 설계하시고 그 이유를 알려주세요.

나 gpt

1. 녹음파일을 2곳 이상에 저장 서버 2개에 저장 X
2. 임시 저장 X
3. 클라우드에 실시간 저장 X
4. 타임아웃 설정

형님
S3 멀티파트나 presigned url(프론트엔드에서 바로 서버랑 연결) 사용

다른조
일시정지는 소켓유지 오랜 시간이 걸렸을 땐 연결을 끊고 메세지를 남기고 알림을 보내준다, S3 멀티파트
타임아웃 설정, 주제가 바뀌었을 때 녹음 자동 종료 -> 다른 조

강사님
1. 일시정지 했을 때 -> 이어 붙힌다란 생각 -> 일시정지 감지 되는 순간 mp3 임시 저장 즉시 업로드 -> 일시 저장 전의 데이터 S3 데이터 백업 후 합쳐져서 저장
2. 녹음 중 서버 다운 ->
1. gracegul shutdown 옵션을 키고 백엔드 처리중 과정을 기다려줌 이 과정에 업로드를 함
2. sugterm 신호를 씀
3. predestroy 서버가 꺼지는 것을 감지해 모든 회의 세션을 순회해서 음성 데이터가 남아 있다면 MP3로 변환 후 비동기로 업로드
4. 웹소켓 연결 종료시 spring의 after뭐시기를 사용해 저장. 웹을 꺼버린다던가 일시정지 다 사용 가능

실시간 반영 안정화 리팩토링 정리

• heartbeat 개선 : 자동적으로 종료되게 만듦.
• 제거 로직 안정화 : markRemoved()로 제거 플래그 원자적 설정.
  공통적인 것 : 끊긴 연결은 건들이지 않는 것.

별도 SSE -> 단일 SSE 구독으로 모든 이벤트 수신
여러 연결 상태 -> 프론트는 단일 연결만 유지

개선 방향

1. 아이디 비번으로 선택적 공유
2. 실시간 공유 계정

• 마지막 시간-
  api 명세서 만들 때 -> 스웨거
  공부하는 내용 블로그, 어떤 개발자가 되고 싶은지? 참신한 대답..
  플젝 안에서의 오류 해결 문제를 다뤄보는게 중요.
  매일매일 뉴스레터 구독
  commit convention을 지키면서 해보면 좋음. cleancode
  프론트엔드 커서로 만들어보기

---

8/29 금 kdt 현직자 강의 백엔드 개발자

로봇 배송 서비스

모바일 어플 - 로봇 - 인베이스 - 아파트 단지서버 - 엘리베이터 서버
모 - 로 = 아파트 단지명, 동, 호 로봇 - 인 = 엘리베이터 호출(동과 엘리베이터가 호기 정보, 시작층, 도착층을 가지고 호출), 상태조회, 로비오픈(로비폰 아이디가 있음)

실습 1
인베이스 개발자가 되어 로봇배송 서비스를 어떻게 구현할지 프로세스를 생각해봅시다.
반씩 나눠서 진행
(로비폰 아이디 어떤 정보와 어떤 정보를 매핑해서 요청하냐를 생각)

로봇이 1층 로비에 도착 - 로봇이 인베이스 서버에 1층 로비폰 아이디를 요청하고 인베이스 서버가 단지서버한테 아파트 단지명, 동, 호를 요청해서 정보를 가져다 주면 문이 열린다. - 로봇이 인베이스에 엘리베이터 위치 정보를 요청하고 인베이스 서버가 단지 서버에서 정보를 가져와 전달 - 로비 오픈 - 엘리베이터 - 사용자 문 앞

1. 로봇의 위치정보와 단지/동/위치(1층, 지하 1층)를 매핑해서 로비폰 아이디를 요청 후 로비 오픈
2. 로봇이 인베이스 서버에 엘리베이터 위치 요청하고 단지서버에서 받아와서 엘리베이터 앞까지 이동
3. 로봇이 엘리베이터 상태 요청 후 엘리베이터 문 열기 호출
4. 엘리베이터 위치와 사용자의 층 위치가 일치하는지 확인 후 문 열기 호출
5. 호수와 사용자의 정보를 일치하는지 확인 후 위치 정보를 가지고 사용자 문 앞까지 이동
6. 배달 어플로 사용자에게 알림을 보낸 뒤 배달 완료.

문제점

1. 네트워크 문제 -> GPS 해보고 안되면 INS 좌표기반, 문열림 상태는 카메라로 확인
2. 사용자가 닫아 버림. 로봇이 엘리베이터 갇힘 -> 네트워크가 된다는 가정 했을 땐 일단 첫번째 알림을 해서 기다릴 수 있게,
   2번째는 층 누르는게 네트워크기반 - 같이 내렸다가 네트워크 정보를 다시받고 다시 호출해서 첫번째 시나리오 -> 해결법은 로봇이 내릴 때까지 엘리베이터 닫힘버튼을 무력화?
   3번째 물리기반인지 확인 - 안내리고 자기 층에 맞춰 찾아간다.
3. 어플 푸쉬알림을 보내도 사용자가 음식을 수거를 안해감. -> 몇분을 기다릴지 설정한 후에 -> 월패드와 연결해서 초인종을 누른다.(강사님이랑 동일) -> 응답이 없을 경우 고객센터로 알림을 보내서 고객과 직접 전화할 수 있게끔
   -> 경비실이나 음식회수

다른 조
로봇이 음식을 받았을 때 가게에서 주는 정보를 요청해서 단지 서버에서 로비 정보를 받아서 해당 위치로 이동 - 로비를 열고 단지내 정보를 받았으니까 경로를 파악해서 이동- 엘리베이터 주문자의 층수를 파악했으니까 올라가는지 내려가는지 파악하고 엘리베이터 상태를 얻어와서 못내릴 경우 알림같은 기능을 넣어서 사람들에게 비켜달라는 신호 생각 - 받은 정보를 토대로 특정 호수로 이동 후 라즈베리파이나 적외선등으로 거리 측정으로 거리 파악 후 장애물 피해 도착. 벨 누르는 거나 어플로 도착했다 연락해서 "수령했다." 버튼을 눌러서 확인 버튼을 받고 다시 돌아게끔 만듦.

로봇에 루트를 학습 시켜서 경로 입력 후 로비 앞 이동.
인베이스 정보에서 테이블에 저장된 정보와 아이디를 호출해서 로비 안 이동
시작층 도착층 단방향 양방향 sse를 사용해서 HTTP 연결이 되면 단방향으로 로봇에게 전달...

강사님

• 1번
  짧은 간격에 서버에 요청을 보냄(폴링 기법 활용 - 500ms 간격정도) : 엘리베이터 문이 열려있는 시간 동안 네트워크 연결을 해서

sse VS 폴링 VS 웹소켓
- sse : 연결 맺자고 연결을 보내면 서로 연결 정확한 순간 탐지 가능 왜 못했는지? 외부 서버라 접근 권한이 부족했음.
- 웹 소켓 : 양방향으로 전화 하는 느낌
- 폴링: 무식하게 여러번 요청하는 방법 -> 커넥션을 유지해도 sse나 웹 소켓은 끊어지니까 사용

• 2번
  화물용 엘리베이터 우선 호출, 동승자가의 요청이 더 중요시.
  엘리베이터 탑승 시각을 인베이스 db에 저장하고 3분마다 스케줄링을 돌려서 3분전인 로봇이 있다면, 해당 로봇의 도착 층 홀콜을 호출을 하게됨.
  마지막 db에서 지워지는 방식으로
• 3번 월패드와 연결 후 초인종 1분마다 울리게끔
  - API
  1. get/post-> GET
  2. URI ->
  3. PathVariable
  4. QueryParameter
  5. ReQuestBody
  6. ResponseBody
  HTTP 상태 코드

실습
git : 통합 각자 작성한 코드를 깃허브 올려서 클론을 로컬로 땡겨 받음.
restcontroller : api를 만들어주는 거
getMapping : 반환하겠다.
restapi : json 키와 값을 가진 형태를 반환 message(키) : 인사말 -> 키와 값

• AI 에이전트 서비스
  사람 - 월패드 - 아파트단지서버 - AI서버 - 인베이스 플랫폼 서버
  api -> postman