
이 책의 제목을 보고 클린 코드고 클린 아케틱처고 이론은 다 알겠지만 복잡한 우리 회사 프로젝트에는 어떻게 적용할지 잘 와닿지 않았는데, 드디어 내가 원하던 그 책인가! 라고 생각하는 독자가 계시다면 안타깝게도 그렇지 않습니다. 하지만 코드를 짜며 클래스 간의 의존관계는 어느정도로 허용해야 하고, 패키지 레벨은 어떻게 나눠야 하는지 등을 끊임없이 고민하는 분들이라면 이 책에서 조금의 힌트는 얻을 수 있으리라 생각합니다. - 역자 서문 역자 서문의 첫 구절이 이 책의 완벽한 요약이다. 애초에 책 한권이 복잡한 프로젝트의 아키텍처 문제를 해결해 주길 바란다면 그것만한 도둑놈 심보가 없다... 나는 2년 전 쯤, 이 책을 한번 구입했다가 환불했었다. 당시에는 헥사고날 아키텍처에 대해 전혀 알지 못했기 때문에..

지난 몇 년간 인프런에서 이벤트를 지원해왔지만... 슬프게도 한번도 선정되어 본 적이 없다. 작년 인프콘이라던가 퇴근길 밋업이라던가 스프링 캠프는 선착순이었지만.... 아무튼 되본적이 없다. 그래서 이번에는 꼭 됐으면해서... 인프콘 참가신청 공유 이벤트에 신청해봤다. 인프콘 2024는 8월 2일이다. 올 초부터 강연자를 모집한다는 이야기를 들은거 같은데, 벌써 컨퍼런스 날짜가 한달 앞으로 가까워졌다. 다음은 내 시간표다.https://www.inflearn.com/conf/infcon-2024/share?year=2024&id=433429&hash=kimdongha15%401681a539&name=kimdongha15 백엔드 개발자 중에서 이름있는 분들이 정말 많이 참석하셔서 사욕을 가득 담아 그분..

지금까지 개발을 하면서 xxx 주도 설계를 정의하고 시작해본 적은 없지만, 도메인 주도 설계에 대해서는 알고 있었다. MSA에 가장 적합한 설계라는 것 정도로 알고 있었는데, 이 책을 읽고 생각이 조금 바뀌었다. 결국 설계는 서비스가 성장함에 따라서 발생할 수 있는 문제를 해결하기 위한 방법론 중 하나일 뿐이었다. 그리고 이 책은 커져가는 서비스에서 발생하는 문제를 도메인 주도 설계라는 방법론을 통해 해결하는 방법을 알려 준다. 가장 기억에 남는 말은, 책 서두와 말미에 다음과 같은 문구가 써있다. 우리가 해결하고자 하는 문제가 무엇인지 합의하기 전에 해결책을 얘기하는 것은 의미가 없다. 또한 해결책에 대해 합의하기 전에 어떻게 구현하는지 얘기하는 것도 의미 없다.- 에프랏 골드렛-아쉬라그(Efrat ..

내가 막 입사했을 때만해도 로그 관리 자체가 안되고 있었다. Cloud Watch를 뒤적거리던가, ArgoCD 대시보드에서 컨테이너에 접근해서 로그를 파악했다. .... 그래서 DevOps 관리자 분과 가장 먼저 협업한 것이 로그 파이프라인 구성이었다. 내가 한 일은 다음과 같다. 1. Application 단에서 발생한 로그를 어느 단위로 남길 것인지 판단하고 필요한 정보를 검토2. 검토된 정보들을 로그로 만들어 JSON 형태로 남김3. LogQL 쿼리로 Loki 데이터를 쿼리해서 Grafana에 대시보드를 추가 DevOps 관리자분은 따로 작업하셨어서 어떤 일을 했었는지 정확히 알기 어려웠는데, 이번 기회에 잘 알게 됐다. DevOps 관리자분이 한 일은 다음과 같다. 1. JSON 형태의 로그가 생..

2~3가지 서비스를 거치면서 개발했던 방식은 Layered 아키텍처를 벗어난 적이 없다. 6년짜리 레거시 코드를 Layered 아키텍처로 운영/개발할 때도 큰 불편함을 느끼지 못 했었다. 당시를 떠올려보면 그렇게 생각했던 이유가 몇 가지 있는데.. 1. 테스트를 구현하지 않았음2. 불행인지 다행인지 레거시 코드를 수정할 일이 거의 없었음3. 서비스의 규모와 팀의 규모가 크지 않았음4. R&R을 나누는 직급이 아니었음 이 정도가 아닐까 싶다. 그러나 이직 후 업무 분담도 하는 직급이 됐고, 서비스 규모가 점점 커지면서 운영 개발 건이 늘어나다보니 Layered 아키텍처의 문제를 느끼게 됐다. (내가 느꼈던) Layered 아키텍처의 문제 1. Service가 너무 커져서 파생되는 문제들- 어떤 기능을 추..

개인적으로는 AWS를 꽤 오래 사용하였지만, 업무에 사용하게 된건 이직한 이후다. 그래서 AWS를 잘 다룬다는 걸 증명하고 싶어서 자격증이 있으면 좋겠다는 생각을 하고, 자격증 소모임에 참여해봤다. 오거나이저 중 한 분이 진행했는데, 짧은 시간이었지만 유익한 내용이 많았다. 이번 소모임에서는 대부분의 시간을 SA 시험 안내서를 보고 중요한 내용을 설명을 해줬다.시험 안내서에서 중요한 내용 정리 - 시험 안내서가 엄청 중요하다.- 시험은 65문제 중 50문제를 푸는 것이고, 720점 이하로 대표적으로 690점으로 떨어졌다? 아쉽게 떨어지는건 절대 아니다. AWS가 점수를 후하게 준다. SA는 보안에 대한 문제도 나온다.- 보안은 IAM이나 SSO를 설계하는 경우가 더 많다. SSO를 왜?- 공동 책임 모델..

AWS에서 제공하는 완전관리형 쿠버네티스 서비스인 EKS는 업데이트 주기가 엄청나게 빠르다. Amazon EKS Kubernetes 버전에 관한 문서를 읽어보면 다음과 같이 안내한다. 1. EKS 신규 버전 출시는 쿠버네티스 업스트림 릴리즈 주기(4개월)을 따름.2. 신규 버전 출시 후 14개월은 무료로 표준 지원3. 표준 지원 종료 후 12개월 추가 지원 (클러스터 당 0.6$/h의 추가 요금 발생)4. 추가버전 종료까지 업그레이드를 하지 않을경우 가장 마지막 버전으로 강제 업그레이드5. 평균적으로 업스트림 릴리즈 이후 약 2~6개월 이후 EKS 지원 만약 추가 지원으로 빠진다면, 클러스터 당 한달에 약 60만원(0.6 × 1380 × 24 × 30) 정도의 추가 비용이 발생한다. 그래서 그런지 콘솔에..

상용 DB를 막 만져봤던 뉴비 시절에 "우리 서비스의 데이터베이스는 HA 구조야" 라는 말을 들었었다. 그 당시에는 아무것도 몰라서 "오 상용서비스에서는 이렇게 구성하는구나"하고 넘어갔었다. 몇 년이 지난 지금, 그 기억을 곰곰이 떠올려보니 HA는 구조가 아니라 High Availability, 고가용성을 말하는 것이었다. 고가용성은 구조를 의미하는게 아니라, 예상치 못한 중단 없이 지속적으로 운영될 수 있는 능력을 의미하는 개념이다. 데이터베이스의 고가용성을 보장하기 위해 여러 가지 이중화 전략이 사용된다. 이중화는 단순히 하나의 시스템이 고장나더라도 다른 시스템이 그 기능을 대신할 수 있도록 구성하는 것이다. 전회사에서는 DB 고가용성을 제공하기위해서 Active/StandBy 구조를 사용하고 있..
- Total
- Today
- Yesterday
- 티스토리챌린지
- ecs
- EKS
- 스프링부트
- 오블완
- lambda
- object
- 후쿠오카
- AWS EC2
- CloudFront
- Spring
- JWT
- Log
- springboot
- 후기
- OpenAI
- elasticsearch
- serverless
- AOP
- ChatGPT
- AWS
- docker
- 람다
- java
- S3
- GIT
- Kotlin
- terraform
- CORS
- cache
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |