ecsimsw

미들웨어미들웨어는 애플리케이션 사이에서 데이터 흐름을 중계하거나 처리하기 위한 소프트웨어를 말한다. 사실 단순히 큐나 메시지 브로커만을 말하는 줄 알았는데, 정의에 따르면 WAS, GW, MQ, DBMS 등 내가 기존에 생각하고 있던 것보다 더 넓은 범위의 키워드로 생각된다. 요즘 이벤트 서버 성능 개선에 머리를 쓰고 있고, 서버를 구성하는 각 요소들의 성능 개선을 위해선 지금 어떻게 통신하고 있는지부터 알아야겠다는 생각이었다. 자주 사용하고 있는 미들웨어들의 기본 설정이나 통신 방식들을 정리한다.# 메시지 브로커와 큐1. Kafka2. RabbitMQ3. Redis pub/sub4. AWS SQS5. Mosquitto와 MQTT# 웹 서버6. Tomcat7. Nginx8. ALB# DBMS9. Mysq..

대규모 업데이트IoT 서비스를 운영하는 우리 회사는 외부 IoT 플랫폼 위에서 애플리케이션단을 개발해 왔다.재작년부터 플랫폼을 독자적으로 운영하기 위한 준비를 해왔고, 최근에 배포를 마쳤다.아예 플랫폼을 사 와 직접 운영하기로 한 것이다.신규 플랫폼 서버 로직에 문제가 있어 기기 순서가 뒤섞였던 상황그 문제를 수정, 배포하는 과정에서 서버 리소스 부족이 고객들에게 노출되었던 상황특정 앱에서 신규 플랫폼의 특정 기기 사용에 제한이 되는 상황 생각만큼 문제가 많았다.특히 회사 간 엮인 급한 이슈 거리들이 많아 밤도 많이 새웠다. 배포 후 2주일 정도 지난 지금, 여전히 바쁜 나날을 보내고 있다.그래도 커다란 이슈들은 어느 정도 잡히고 작은 이슈들만 남아 있는 상태이다. 지금까지의 업무 경험 중 가장 체력적..

배경 소개 팀에서 새로 인프라 구조, 아키텍처를 구성해야 하는 일이 있었다. 우리 팀은 Container 기반으로 서버를 운영하여, AWS ECS + Fargate를 사용하여 배포하기로 결정했다. 이때 VPC, ECR, ECS의 배포 정책이나 오토 스케일링을 모두 Terraform으로 관리하여 인프라 구성을 코드로 작성할 수 있도록 작업하였다. 이 글에선 이런 구조를 선택한 근거와 함께, 테라폼을 사용해서 얻을 수 있었던 팀 시점의 이점을 소개하려고 한다. 테라폼과 IaC선정한 ECS의 구축을 위한 AWS 리소스들은 모두 테라폼으로 작성, 코드로 관리하였다. 처음에는 다소 러닝 커브가 있었지만, 기반 코드를 만들어 소개하고 직접 한, 두 개 애플리케이션을 배포해 보면서 다들 금방 손에 익어하셨다. 낯선..

정합성이 깨지는 문제아래 update()에선 id에 해당하는 person의 이름을 수정한다. DB에서 person을 조회하고, Transaction이 종료되며 업데이트 쿼리를 수행한 후 Cache를 업데이트하게 된다.@Transactional@CachePut(key = "#id", value = "person")public Person update(Long id, String newName) { var person = personRepository.findById(id).orElseThrow(); person.setName(newName); return person;} 만약 이 update를 감싼 트랜잭션이 실패하게 되면 어떻게 될까.@Transactionalpublic void upda..

방향오늘따라 친구들이랑 통화를 길게 했다.또 유독 삶의 방향에 대한 얘기를 많이 나눴다. 용관이랑은 우리가 당장 해야 하는 일들을,유진이랑은 개발자로서의 성장 방향과 고민을,영상이랑은 서로가 중요하게 생각하는 가치들을 나눴다. 최근에 바쁜 척하느라 나를 돌아보는 시간을 못 가졌던 것 같다.주변에서 중요하다고 하는 일들에, 나한테 중요한 일들을 놓치고 있는 기분이다. 나는 언제 행복한가. 내가 진짜 하고 싶은 건 뭐고, 어떤 삶을 원하는가.3년 전 작성했던 내가 꿈꾸는 프로그래머로서의 삶과 지금 내가 꿈꾸는 다음 방향을 비교해 보는 것도 재밌겠다. 여행나는 여행할 때 행복하다.가끔 사진첩을 넘기며 찍었던 사진을 쭉 훑는 게 취미이다.사람은 순간의 기억으로 평생을 산다는 말에 공감한다. - 하노이 펍에서 ..

연관 관계를 피한다난 JPA, ORM을 사용한다고 연관관계를 반드시 사용하진 않는다. 첫 번째는 엔티티 간 연관 관계가 객체 간 의존도를 크게 해서이다.의존성이 커져 프로젝트가 통짜가 되어버리고, 조립이 아닌 나열식 전개로 점점 전환되는 프로젝트 코드를 경험한 적 있다.더 작게는 테스트 코드가 복잡해지고, 개발 순서가 엮여 병렬로 작업을 처리하기 까다로웠다.거기엔 엔티티의 연관관계가 큰 몫을 한다고 생각한다. 두 번째는 의도하지 않은 쿼리가 발생하거나, 직관적이지 않은 코드가 생기기 좋아서이다.이를 테면 연관관계를 위한 ORM의 동작으로 코드 레벨에서는 눈에 보이지 않는 쿼리가 발생할 수 있다.코드를 짤 때도 이를 생각해야 하기에 단순한 쿼리조차도 ORM 동작에 한번 더 고민하는 경우가 나오기 좋다.특히..

애플리케이션은 Vault의 존재를 몰라야 하지 않을까?개발자 친구를 만나고 팀에서 Vault를 사용한다는 이야기를 들으면 항상 하는 질문이, 'Vault에 대한 인증은 어떻게 해?' 였다. 그리고 다들 본인의 역할이 아니다보니 명확한 관리 방법이나 안전한 방식의 대답을 듣지 못했다. 비밀 키를 관리하는 금고를 여는 비밀 키 관리는 정말 중요해보인다. 아무리 안전한 금고할지라도 열쇠를 그 금고에 보관할 순 없는 노릇이고, 그렇다고 열쇠가 제대로 관리되지 못하면 말짱 도루묵일테니 말이다. 내가 그간 경험했던 환경에선 애플리케이션에서 Vault 인증을 위한 키를 갖고 있었고, 그 키로 Vault를 직접 호출해 필요한 비밀 값을 조회했다. 이런 방식은 애플리케이션에서 Vault에서 사용할 Secret 정보나 V..

k8s Rolling update 배포 Down time 문제서버가 운영되는 도중 배포시 Down time 이 발생하고 있다. 배포는 Kubernetes deployment rolling update로, 새 버전의 파드가 생성되고 기존 버전의 파드가 다운되길 반복한다. 서비스 운영 중 파드가 생성되고 제거되며 발생할 수 있는 Down time을 확인하고 해결한다. 문제 여지 1 : 이미 삭제된 Pod에 요청이 전달되는 경우 파드가 삭제되면 Kublet은 Container를 종료하고, 동시에 Endpoint controller (KubeProxy)는 IpTable routing rule 에서 해당 파드를 제거한다. 만약 IpTable이 업데이트되기 이전에 Container가 먼저 삭제되면, 요청을 처리할 ..