To-Do엔지니어 미팅담당 엔지니어님과 아침 9시부터 미팅을 진행했고, 전날 설계한 DDD 그림과 ERD를 보여드리며 설명하고, 왜 이렇게 설계했는지에 대해 답변을 했다.요구사항을 같이 하나하나 짚어보며 빠진 부분들이 있는 것을 발견했고, 오늘은 전체적으로 수정한 뒤 아키텍처 구성을 하는 쪽으로 정했다.CRUD 문서 작성엔지니어님이 미팅 중 CRUD 문서를 작성하며 설계를 하다보면 빠트리는 부분 없이 진행할 수 있을 것이란 조언을 듣고, CRUD 문서를 간단히 작성했다.문서를 정리하며 필요한 기능을 다시 생각해보니 조언해주신 것처럼 필요한 게 무엇인지 더 수월하게 파악할 수 있었다.ERD 수정CRUD 문서를 작성 한 뒤 ERD를 다시 살펴보며 수정을 하던 중 DB정규화에 관해 이슈가 생겼다. 참고자료정규..

Final Project파이널 프로젝트가 시작됐다.오늘의 일정은 시나리오 선정과 분석 및 설계.시나리오 선정팀원들과 한시간정도 의논한 결과 우리는 대회 결과 기록 시스템 시나리오를 선택하기로 했다.요구사항인프라를 구현하기에 있어 가용성, 내결함성, 확장성, 보안성이 고려된 서비스가 포함되어야 하고,CI/CD 파이프라인 구축과 데이터베이스 분리 기준에 대해서도 생각을 해야했다.시나리오 분석MSA 방식 도메인주도 설계 이벤트 스토밍먼저 요구사항에 따라 도메인 이벤트 포스트잇을 붙이고, 커맨드 및 액터 배치, 핫스팟 포스트잇으로 구현하며 의논이 필요한 부분에 대해 남겨두었다.외부 시스템은 사용할 것이 없기 때문에 패스했고, 에그리거트 및 정책을 통해 큰 틀의 도메인을 분리하고 연결해주었다.의논사항설계를 하던 ..

Metric 컴퓨팅 유닛 관련 메트릭 요청/응답 관련 메트릭 스케일링 관련 메트릭 k8s - CPU 사용량 (utilization) - 메모리 사용량 - 네트워크 in/out - 디스크 사용량 (노드 및 파드 별) - etcd latency - ingress - 요청 개수 - 요청 latency - 에러율 - 디플로이먼트 상황 ECS - CPU 사용량 - 메모리 사용량 - 네트워크 in/out (클러스터 및 서비스 별) 해당 사항 없음 (ALB와 사용하여 분석해야 함) - 서비스 개수 - (원하는/실행 중인/보류 중인) 작업 개수 - 컨테이너 인스턴스 개수 EC2 - CPU 사용량 - 네트워크 in/out - 네트워크 패킷 in/out - 디스크 읽기/쓰기 (바이트), 작업 개수 - CPU 크레딧 사용..

모니터링(Moritoring) CI/CD 파이프라인의 마지막 단계인 운영은 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표된다. 여기서 모니터링이란 어떤 대상을 감시, 관찰한다는 뜻으로 모니터링의 목적은 지속적인 감시, 감찰을 통해 대상의 상태나 가용성, 변화 등을 확인하고 대비하는 것이다. 즉, 어떤 대상의 상태나 상황을 지속적으로 감시, 관찰하여 예기치 못한 상황과 오류를 대비하고 극복한다. 라고 할 수 있다. IT 서비스에서는 서비스가 어떤 환경에서 운영되든 모니터링이 중요하다. 특히 클라우드 플랫폼은 확장성과 유연성을 가졌기 떄문에 지속적인 모니터링을 통해 수집된 데이터를 기반으로 시스템 규모의 확장과 축소를 빠르게 결정해야하기 때문에 더욱 더 중요해진다. 그렇다면 모니터..

프로젝트 3: 마이크로서비스 Achievement Goals AWS 클라우드 환경을 기반으로 하는 느슨하게 연결된(loosely coupled) 애플리케이션 아키택처에 대한 이해 Bare minimum Serverless를 이용한 메시지 대기열 활용 이해 및 구현 요구사항에 따른 애플리케이션과 인프라 구현 문제사항 해결을 위한 추가 리소스 생성 → DLQ, Legacy 시스템 성능문제 해결, SES 아키택처 다이어그램 제작 Day1 Section3 실습과제에서는 이때껏 배웠던 AWS의 Lambda, SQS를 이용한 마이크로소프트 아키텍처를 구현해야했다. Day1은 튜토리얼로, 목표는 다음과 같다. Serverless를 이용한 AWS 리소스 생성 메시지 Queue가 사용되는 구조 이해 1. Serverle..

Configuration Drift Configuration Drift는 시간이 흐르면서 시스템이나 애플리케이션, 서버, 인프라, 하드웨어 등의 실제 구성이 의도하거나 원하는 구성과 달라지는 현상을 말한다. 이는 소프트웨어 업데이트, 사용자나 관리자에 의한 변경, 하드웨어 오류 또는 네트워크 문제 등 다양한 요인으로 인해 발생한다. 시스템이나 애플리케이션을 처음 설정할 때는 일반적으로 특정 요구 사항이나 표준을 충족하도록 구성된다. 이 구성에서는 보안, 성능, 호환성 또는 시스템이 제대로 작동하는 데 중요한 요소와 태그 등 작동과는 상관 없는 설정이 포함될 수 있다. 시간이 지나고 시스템이나 애플리케이션이 사용되고 발전함에 따라 구성이 변경되어 원래 의도한 상태에서 벗어날 수 있다. 이처럼 예상치 못한 ..

IaC IaC(Infrastructure as Code)는 기존 IT 환경에서 클라우드 환경으로 변화하며 중요해진 개념 중 하나로 자리잡고 있다. 기존 IT 환경에서는 서버를 증걸하기 위해 서버 전문 업체에서 서버를 구매한 뒤 서버실에 서버를 추가하는 물리적인 프로세스가 있었기 때문에 IT 인프라를 코드로서 관리하는 것이 쉽지 않았다. 하지만, 클라우드 환경은 논리적인 구성이기에 Terraform이나 CloudFormation과 같은 툴을 사용하여 코드 형태로 인프라를 구성할 수 있게 되었고, 이런 방식으로 인프라를 구성함으로써 인프라 변경에 대해 증가하는 요구 사항을 충족시키거나, 확장 가능하고 추적 가능한 인프라의 관리가 가능해졌기 때문이다. 코드 기반 인프라 코드형 인프라(Infrastructure..

API Gateway 서비스 API Gateway란 규모에 상관없이 API 생성, 유지 관리, 모니터링과 보호를 할 수 있게 해주는 서비스이다. 말 그대로 Client에서 server로 통신할 때 사용하는 많은 api들의 대문(게이트웨이)과 같은 역할을 한다고 보면 된다. 즉, API가 지나가는 통로인 셈이다. API Gateway를 이용하면 통합적으로 엔드포인트와 REST API를 관리할 수 있다. API 게이트웨이를 등록해주면, 모든 클라이언트는 각 서비스의 엔드포인트 대신 API Gateway로 요청을 전달하여 관리가 용이해 진다. 사용자가 설정한 라우팅 설정에 따라 각 엔드포인트로 클라이언트를 대리하여 요청하고 응답을 받으면 다시 클라이언트에게 전달하는 프록시(proxy) 역할을 하기 때문이다. ..