앞서 언급한 적이 있지만, 내가 담당하고 있는 서비스는 CI/CD가 없다. 하지만, 관리해야할 서버군은 요청을 앞단에서 받아줄 Apache Httpd 서버 6개, WAS가 있는 API 서버 6개, 실시간 위치정보를 다루는 WAS 3개, 배치서버 4개다. 한번 배포하는데만 시간 단위로 걸리고, 배포용 WAR파일을 수동으로 올리는데만도 몇 분씩 걸린다... 자사 서비스가 아니다보니 요청하기 어려 운점은 이해하겠지만 솔직히 말이 안된다고 생각한다. 심지어 TC도 따로 없고 데일리 빌드도 하지않으며, 프로젝트에 참여한 개발자가 개별 commit을 하고, pull request로 관리하지 않는다. 불만만 토로하게 되었는데 이러한 사항들 때문에, 다른 서비스는 어떻게 배포 과정을 갖는지 공부하게되는 계기가 됐고, ..
회사에서 어드민 서버를 신규 인프라로 이전하게 됐다. 베이스에서부터 작업하다보니 이전하면서 서버의 구조에 대해 볼 일이 생겼다. 우리 회사에서 사용하는 어드민의 서버 구조는 웹서버와 WAS를 연동시킨 구조였다. 대충 위와 같은 구조이고, 앞라인에 L4 로드밸런서를 둬서 로드밸런싱을 하고 있다. L4 부분까진 정확히 알 수 없으니, Httpd 웹서버와 Tomcat을 연동하면서 기억하고 싶었던 내용을 정리하려고한다. 그리고 위 내용을 정리하기 전에 웹서버와 WAS의 내용을 정리하지 않고 지나갈 수가 없었다.. 1. 웹서버(Web Server) 웹 브라우저와 같은 클라이언트로부터 HTTP 요청을 받아들이고, HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램 - 위키백과 위키백과의 정의와 같이 웹서버는..
- Total
- Today
- Yesterday
- cache
- ChatGPT
- MySQL
- AOP
- 오블완
- 스프링부트
- java
- Log
- docker
- AWS
- Kotlin
- serverless
- 티스토리챌린지
- terraform
- openAI API
- 람다
- Elastic cloud
- Spring
- OpenAI
- springboot
- S3
- CloudFront
- EKS
- lambda
- GIT
- 후쿠오카
- AWS EC2
- JWT
- elasticsearch
- OpenFeign
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |