88일간의 여정 드디어 88일간의 교육 과정을 마무리했다. 👏👏👏단 하루도 빠짐없이 출석률 100%를 달성하고자 했던 목표를 지켜낸 것도 뿌듯하다. 이번 과정에서는 네트워크, Linux, Docker, Kubernetes, Ansible, VMware 등 다양한 기술을 배울 수 있었고, 프로젝트를 통해 AWS와 Kubernetes, Terraform으로 고가용성 서비스를 직접 구축해보았다. 써보고 싶었던 AWS 리소스를 다뤄본 경험도 의미 있었고, ArgoCD나 EFK처럼 실제 현업에서 자주 쓰이는 배포 자동화 및 모니터링 기술을 적용할 수 있었던 점이 큰 성장으로 다가왔다. 최우수상 수상 프로젝트에서 최우수상을 수상했다!그동안 열심히 달려온 노력이 인정받은 것 같아 큰 보람을 느낄 수 있었다.온라..

Day 86 - 마지막 발표 준비PPT를 어느 정도 완성하고 발표 스크립트도 짜봤다. 실제로 발표처럼 연습해보니 예상보다 시간이 많이 남아 비상이 걸렸다. 부랴부랴 지웠던 시연 영상을 다시 추가하고, Terraform 시연 영상도 새로 찍었다. 페이지 수도 많고 할 얘기도 많았기 때문에 시간이 부족할까 걱정했지만 내가 말이 빠른 편이라 오히려 시간이 남았다. 시간 부족 때문에 뺐던 내용들도 모두 추가하고 나니 안정적으로 25분 이상 발표할 수 있었다. 이제 진짜 내일이면 프로젝트가 끝난다는 생각에 긴장과 기대가 교차했다.Day 87 - 프로젝트 발표 및 최우수상 수상드디어 프로젝트 발표 날이다. 온라인 환경이라 대본을 외우지 않고 준비한 대본을 보면서 발표를 진행했다. 혹시 몰라 스톱워치도 켜 두고, 말..

Day 81 - 모니터링 환경 구성 CloudWatch 구동 확인이번 주의 시작은 지난주에 설치했던 CloudWatch가 정상적으로 작동하는지부터 확인하는 것으로 열었다. 다행히 Pod들을 잘 감지하고 있는 것을 확인할 수 있었고, 기본적인 모니터링 환경이 안정적으로 구동되고 있다는 사실에 조금 안심이 되었다.EFK 스택 구성이어서 로깅 환경을 마련하기 위해 EFK 스택을 구성했다. Fluent Bit를 DaemonSet으로 배포해 각 노드에서 실행 중인 Pod들의 로그를 수집하도록 했고, 수집된 로그는 Elasticsearch에 저장되도록 연결했다. 이후 Kibana를 통해 로그를 시각화할 수 있는 환경까지 갖추면서 기본적인 로깅 파이프라인이 완성되었다.이렇게 메트릭과 로그 모니터링을 완성하고 나니 프..

Day 76 - 모니터링 환경 재시도 모니터링 환경 구성을 다시 시도했다. 메모리 초과 문제를 방지하기 위해 기존에 올려두었던 모든 리소스를 삭제하고, 모니터링 환경에 필요한 리소스만 최소한을 구성했다. 이 과정에서 문제를 발견할 수 있었다.문제 peration error EC2: CreateVolume, get identity: get credentials: request canceled, context canceledCSI Driver Controller 파드에서 해당 에러 발원인CSI Driver Controller 파드가 EC2 볼륨 생성 권한을 제대로 획득하지 못함IAM Role과 Policy는 정상적으로 생성되어 있었고, Pod에도 ServiceAccount로 잘 매핑되어 있었음미해결권한과 설..

Day 72 - 추가 학습혹시 설정 과정에서 내가 놓친 부분이 있을까 싶어, 교육 과정 중 받았던 책을 다시 펼쳐보았다. 앞부분의 이론 위주로 읽으며 헷갈리는 부분은 따로 Notion에 정리했고, EKS Cluster 구성에서 수정할 만한 부분이 있는지도 고민해보았다. 책을 보기 전에 Ingress 부분이 조금 헷갈렸는데 개념을 정리할 수 있는 좋은 기회였다. Day 73 - 문서화Outputs 파일 수정하기Terraform의 outputs.tf 파일을 보완했다.기존에는 단순히 VPC 정보 정도만 출력했지만, Terraform을 사용하는 만큼 리소스의 ARN, 이름, ID 같은 필수 정보를 바로 확인할 수 있도록 output을 추가했다.terraform output으로 전체 정보를 확인 가능특정 리소스만..

Day 67 - CDN 에러 고치기 & Terraform 인프라 문서화Route53과 CloudFront 연동 확인기존에 사용하려던 도메인은 팀원이 내도메인한글 무료 서비스에서 발급받은 것이었다.처음 계획대로라면 Route53에 Hosted Zone을 만들고 네임서버를 AWS로 변경해야 했는데, 문제는 내도메인한글에서는 네임서버 변경 기능을 제공하지 않는다는 점이었다. 다행히 빠르게 원인을 파악했고, 오래 고민하지 않고 바로 가비아에서 550원을 결제해 도메인을 구입했다. 이후 Route53에 도메인을 등록하고 네임서버도 AWS로 변경 완료. 중간중간 테스트를 하면서 기다렸는데, 약 4~5시간 정도 뒤에 정상적으로 도메인 접속이 가능해졌다.아직 백엔드 서버 배포 전이지만, 프론트엔드 페이지가 도메인으로 ..

Day 62 - EKS 공부최근 Kubernetes 환경에 대한 개념은 어느 정도 익숙해졌지만, AWS에서 제공하는 EKS에 대해서도 알아야겠다는 생각이 들었다. 단순히 문서를 읽는 것도 방법이지만, 이해도를 높이기 위해 AWS Korea 공식 유튜브 채널의 강의를 시청했다. 강의를 통해 Kubernetes의 전체적인 개념을 다시 복습할 수 있었고, EKS가 제공하는 기능과 AWS 환경에서 어떤 방식으로 활용할 수 있는지도 배울 수 있었다. 무엇보다도 AWS의 솔루션 아키텍트가 직접 강의하는 내용이라 신뢰도가 높았다.단순히 영상을 시청하는 것에 그치지 않고, 헷갈릴 수 있는 개념들을 언제든 다시 볼 수 있도록 Notion에 정리했다. 이 정리된 내용은 앞으로 실제로 EKS Cluster를 구성할 때 참고..

현업자 멘토링EKS -> DynamoDB 접근현재는 인터넷을 경유 -> VPC Endpoint Gateway를 생성하여 내부 통신으로 처리하는 것이 바람직해보임EBS 사용시 주의사항EBS는 AZ간 공유 불가외부 API 연결 구조현재 두 개의 Pod에서 네이버 API를 호출하고 있어 클러스터가 분리된 것처럼 보임 -> Pod에서 직접 네이버 API와 녀결하는 방식으로 그려도 좋을 것 같음확장성 관점컨테이너로 서비스 확장을 가정했을 때 서버리스와 쿠버네티스의 장단점을 비교하고 시나리오별로 구상해보면 좋을 것 같음모니터링 도구보통은 Prometheus와 Grafana 사용. OpenTelemetry도 고려 가능모니터링은 단순히 서비스가 떠 있는지 여부보다 클러스터 내부 컨테이너 동작 상태를 세밀하게 관찰하는 ..

Day 58 - 피드백 반영이전 기획환경 : 온프레미스 환경에서 데이터 수집아키텍처 : API Gateway + Lambda 기반 서버리스 구조수정 기획아키텍처 변경 : MSA로 전환데이터 수집 서비스데이터 조회 서비스모니터링 서비스로깅 서비스데이터 수집 방식 변경 : 배치 방식 -> 이벤트 드리븐온프레미스 역할 변경 : 데이터 수집 -> 백업 전용 환경Day 59 - 2차 아키텍처 설계2차 아키텍처 설계Route53을 DynamoDB라고 잘못 표기되어 있음!수정된 기획안을 토대로 팀원들마다 각자 아키텍처를 설계해봤다. 나는 정적 페이지는 CloudFront와 S3를 통해 클라이언트에게 전달하고, 백엔드 서비스는 EKS에 관리하도록 설계했다. 또한, EKS에서 ECR로부터 컨테이너 이미지를 가져올 수 ..

1. 프로젝트 피드백현업자 피드백 요약긍정적 평가심플하고 깔끔한 아키텍처 구성개선 제안사항성과 중심 프로젝트 특성상 기술적 챌린지 요소 필요현재 서비스 규모 대비 K8s 도입 목적에 대한 명확한 근거 필요API Gateway 배치 전략 재검토 (Private 배치 시 외부 접근 경로 확보 또는 Public 배치 고려)피드백 반영 계획K8s 기반 통합 관리 체계적용 범위: 데이터 수집, 웹 서비스, 모니터링, 로깅 시스템을 K8s 클러스터로 통합 관리도입 근거: 마이크로서비스 간 오케스트레이션, 자동 스케일링, 장애 복구 자동화데이터 수집 방식 개선기존: 배치 방식 데이터 수집변경: 이벤트 드리븐 방식으로 전환선택 이유:실시간 뉴스 데이터 수집이라는 서비스 특성에 최적화수집 실패 시 재시도 메커니즘을 통한..