일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 카카오게임즈
- Site Reliability engineering
- 기술PM
- javascript
- server
- ecs
- 프로세스
- 쿠버네티스
- Reducer
- 프로세스 통신
- #Swagger-editor
- fluentd
- Kubernetes
- React
- 북딜
- AWS
- 모캠
- 모두의캠퍼스
- #Swagger
- #스웨거
- 쿠버네티스 컨트롤러
- IP
- SRE
- #Swagger-ui
- action
- docker
- Redux
- React.js
- #Swagger-codegen
- #api 문서화
- Today
- Total
목록모캠 (3)
탕구리's 블로그
오늘의 주제 오.늘.은. 모캠 리뉴얼 중에서도 가장 고통스러웠던 부분! 데이터베이스 재설계를 진행하며 겪었던 내용에 대해서 포스팅을 하려합니다. 기존에는 어떤게 되어있었고, 리뉴얼하면서 어떻게 변경되었는지! 알아보면서 그때는 생각하지 못했던 빠트린 점이 뭐가 있나... 고민해보는 시간을 갖도록 하겠습니다 :) 강의..어떻게 관리하면 좋을까? 물론 가장 큰 변경점은 데이터베이스 설계 부분입니다. 모두의캠퍼스에는 "학교-학과-교수-수업" 이라는 4개의 큰 카테고리가 연결되어 있습니다. 리뉴얼 전 설계된 데이터는 각 항목에 대해서 관계가 크게 작용하지 않습니다. 일반적으로 생각했을때 대학교라는 큰 틀안에 각 학과 혹은 단과대가 존재하고 속에 학과나 단과대가 존재하며, 그 안에는 교수의 정보, 각각의 교수 마다..
오늘의 주제 모캠 서비스 리뉴얼을 준비하며 무엇을 준비했고, 기존의 설계를 어떻게 수정하였는지 차근차근 정리해 놓으려 합니다. 리뉴얼 작업에 대해서는 저도 팀원도 너무너무 하고 싶었던 작업이었기 때문에 힘들기 보다는 데드라인 압박에 대한 아쉬움(?)이 더 많이 컷던 시간인거 같아요. 물론, 정해진 마감동안 결과물을 만들어 내는게 당연하고 그게 제 실력이긴 하지만.. 그래도 뭐 아쉬운건 아쉬운거니까 어쩔 수 없는거겠죠? 무엇이 변했을까 ? 우선, 서비스를 이루고 있던 기술 스택이 전부 변경되었습니다. 기존의 모두의캠퍼스 서비스는 php를 통해서 개발되었고 유지보수를 진행 하고 있었습니다. 하지만 이번 리뉴얼에 사용된 기술 스택은 프론트앤드(React.js), 백앤드(Koa.js)를 기반으로 외부 서드파티(..
오늘의 주제내가 처음 입사했을 당시에는 "북딜"이라는 중고책 거래 서비스에 대해 양도받을 준비를 하고 있었어요.양도받은 서비스를 운영하기 위해 해당 서비스가 작동하던 환경과 최대한 동일하게 구성하기 위해서 준비가 필요했고 그 외에도 외부 B2B 서비스들을 이용중인 서비스였기 때문에 정말 화나는 일이 많았어요(불칠전한 고객센터 덕분에) 서비스를 양도받기 위해 어떤 작업을 했고 어떻게 구조를 잡았는지 회기해보도록 하겠습니다. 무슨 일을 했지? 1. 로드밸런싱을 위한 로드밸런서(AWS-ALB) 설정하기 2. CloudFront(CDN) 공부하기 그리고 설정하기 3. 각각의 CloudFront와 로드밸런서에 HTTPS 통신을 위한 ACM(Amazon Certificate Manage)를 통해 SSL 인증서를 발..