Untitled

기초 CS 관련해서 공부할 예정이다. 다음의 내용을 정리할 예정이다.

• 프로그래밍 언어
• 데이터 구조와 알고리즘
• 데이터베이스
• 웹 기술
• 운영 체제
• 네트워크
• 보안
• 클라우드 컴퓨팅
• 버전 관리 시스템
• 소프트웨어 개발 방법론
• 로깅 및 모니터링
• 테스트 및 디버겅
• 자동화 배포
• 컨테이너 및 오케스트레이션
• 성능 최적화

CI/CD

Continuous Integration + Continuous Delivery 의 약어로, 소프트웨어 개발 및 배포 프로세스를 자동화하고 개선하는 방법이다. CI 는 다음의 단계를 가진다.

1. 코드 작성
2. 자동 빌드
3. 자동 테스트
4. 자동화된 통합

CD는 다음의 단계를 가진다.

1. CI를 통한 자동화
2. 자동 배포 준비
3. 수동 승인
4. 자동 배포

성능 테스트 종류

• 스트레스 테스트 : 스트레스 테스트는 어플리케이션을 최대 부하에서 테스트하는 과정을 의미한다. 이 테스트에서는 어플리케이션의 성능 한계를 확인하고 어플리케이션의 부하 처리 능력을 평가한다. 대량의 동시 사용자 또는 트랜잭션을 생성하고 어플리케이션의 응답 시간과 자원 사용량을 모니터링합니다.
• 스파이크 테스트 : 스파이크 테스트는 갑작스러운 부하 증가에 대한 어플리케이션의 대응 능력을 테스트한다. 예를 들어, 특정 이벤트나 광고 캠페인으로 인해 갑자기 많은 사용자가 앱에 엑세스하는 시나리오를 시뮬레이션한다.
• 인더런스 테스트 : 어플리케이션을 장기간 실행하는 테스트로, 지속적으로 부하를 가하거나 특정 부하를 유지하는 시나리오에서 어플리케이션의 안정성을 확인한다. 이 테스트를 통해 어플리케이션의 장기적인 안정성, 메모리 누수, 자원 누수 등을 검증하는 데 사용됩니다. 인더런스 테스트를 통해 장시간 실행 중에 어플리케이션이 성능 저하나 시스템 장애를 경험하지 않는지 확인할 수 있습니다.

성능 테스트 리팩토링

스케일 아웃

AWS 로드 밸런서를 이용해 애플리케이션을 여러 서버로 분산하여 트래픽ㄹ을 균형있게 분배 및 고가용성 제공

분산 시스템 아키텍처

MSA를 고려해 각 부분을 독립적으로 스케일 아웃 및 확장성 제공

캐싱 활용

게시물 목록, 사용자 프로필, 이미지 등 자주 접근하는 데이터를 캐시한다. 이 때, Ehcache, Redis, 또는 기타 캐싱 솔루션을 사용해 성능 향상

비동기 프로그래밍

SPring에선 비동기 서비스 및 메시징을 이용해 요청과 응답을 병렬로 처리 및 병목 현상을 줄임

알고리즘 및 비즈니스 로직 최적화

비즈니스 로직에서 성능에 영향을 미치는 부분을 개선하고, 불필요 작업의 반복 최소화

알람

알람은 Spring Boot 애플리케이션 내에서 이벤트, 경고, 에러의 상황을 감지하고 개발자에게 알리는 기능을 의미한다. 이는 다음의 문제들을 해결하는데에 중요한 역할을 수행한다.

• 장애 감지와 대응
• 서비스 가용성 유지
• 성능 모니터링
• 비용 절감
• UX 향상

AWS SNS 연동

Amazon Simpel Notification Service로 AWS의 클라우드 기반 메시징 서비스이다. 이를 통해 서비스, 시스템 간의 메시지를 안전하게 전송이 가능하다. 즉, 다음의 종류들이 처리가 가능하다.

• 푸시 알람
• 다중 프로토콜 지원
• 이벤트기반 아키텍처
• 확장성과 신뢰성
• 미리 알림 및 모니터링

대규모 트래픽을 고려한 실무 게시판 프로젝트의 끝자락이다. 거의 마지막 챕터인 13에서 프로젝트를 정리했는데 이번에는 예외처리 및 로깅관점 정리, 모니털이 및 알람 관점 정리, 배포 자동화 정리 등을 정리해주었다. 앞에서까지의 내용을 정리해주는데 사실 지금까지 내가 잘 정리했는지 이해를 완료하였는지 헷갈리는 부분들이 해당 챕터들에 존재하였다. 그러나 해당 과정에서 정리되지 않은 내용들을 정리하면서 내 머릿속에 개념들이 좀 더 깔끔해지는 것 같았다. 특히, 툴, 기술 별로 다양하게 정리를 해주는데 이것이 너무 마음에 들었다. Docker, Github CI 등과 같이 기술들을 간단 명료하게 수업자료에 명시해주고 이를 강의에서 정리해주니 이만큼 깔끔한 것이 없었다.

대규모 트래픽을 고려한 실무 게시판 프로젝트의 끝자락이다. 마지막 챕터인 13에서 그동안의 과정들을 정리했는데 금일 진행한 챕터에서는 예외 처리와 로깅, 모니터링 및 알림, 배포 자동화 같은 실무적인 관점을 중심으로 강의가 진행되었다. 그동안 배웠던 내용을 체계적으로 복습하면서 전체적인 그림을 다시 정리할 수 있었다. 사실 이전에 학습했던 내용 중 이해가 완벽하지 않거나 정리가 미흡했던 부분들이 있었는데, 이번 챕터에서 이런 부분들을 보완하면서 개념이 확실히 잡히는 느낌을 받았다.

특히 이번 강의를 통해 과정을 돌아보면서 다양한 툴과 기술을 명확하게 설명한 점이 좋았다. 예를 들어 Docker와 Github Actions를 활용한 CI/CD 구현 과정은 실무에서 꼭 알아야 할 중요한 주제인데, 기술의 기능적인 면뿐만 아니라 실무적인 배경까지 함께 설명해 주어 학습 효과가 컸다. 강의를 들으면서 제대로 정리하지 못한 부분은 ChatGPT를 활용해서 따로 정리하기도 했는데, 이를 통해 부족했던 부분들을 빠르게 채울 수 있었다.

강의 마지막에 제공된 부록, ‘개발자가 되는 방향성’에 대한 내용은 특히 인상 깊었다. 단순히 기술을 배우는 것을 넘어서, 개발자로서 어떤 방향으로 커리어를 설계해야 하는지에 대한 구체적인 가이드를 제시해 준 덕분에 앞으로 어떤 길을 걸어갈지 고민해 볼 수 있었다. 

위의 과정 기술적인 내용들과 부록들은내가 운영할 기술 블로그의 방향성에 영향을 주었다. 단순히 기술을 나열하는 방식이 아니라 학습 과정을 기록하고, 성장의 흔적을 남기는 블로그를 만들어야겠다고 다짐했다.

아직 부록의 개발자 팁이 조금 남았지만 이번 패스트캠퍼스 대용량 트래픽 강의 첫번째 프로젝트는 기술을 배우는 것을 넘어 실무적인 스킬과 개발자로서의 성장 방향을 깊이 고민하게 만들어 준 값진 시간이었다. 내일은 남은 부록들을 정리해서 체화시키고 다음 프로젝트로 넘어갈 수 있도록 해야겠다.

Redis

Remote DIctonary Server의 줄임말로 In-memory database이며 Key 값을 기준으로 저장한다.

이러한 Redis는 다음의 경우 사용한다.

• Cache
• Session Store
• Pub/Sub
• LeaderBOard
• ㅎ대넴샤미

주요 명령어

TTL

• EXPIRE key second
• TTL key

Queue

• LPUSH
• RPUSH
• LPOP
• RPOP
• LLEN
• LRANGE

Sorted Sets

• ZADD
• ZREM
• ZRANGE
• ZCARD
• ZRANK
• ZINCRY