ecsimsw

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

배경 소개 팀에서 새로 인프라 구조, 아키텍처를 구성해야 하는 일이 있었다. 우리 팀은 Container 기반으로 서버를 운영하여, AWS ECS + Fargate를 사용하여 배포하기로 결정했다. 이때 VPC, ECR, ECS의 배포 정책이나 오토 스케일링을 모두 Terraform으로 관리하여 인프라 구성을 코드로 작성할 수 있도록 작업하였다. 이 글에선 이런 구조를 선택한 근거와 함께, 테라폼을 사용해서 얻을 수 있었던 팀 시점의 이점을 소개하려고 한다. ECS + Fargate우선 컨테이너를 사용한 배포를 전제로 하였다. 배포를 위한 파일 관리보다 컨테이너 이미지 관리가 훨씬 쉽고, 컨테이너 런타임만 있는 환경이라면 쉽게 배포하고 앱을 확인해 볼 수 있으니까. 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년 전 작성했던 내가 꿈꾸는 프로그래머로서의 삶과 지금 내가 꿈꾸는 다음 삶의 방향을 비교해 보는 것도 재밌겠다. 여행나는 여행할 때 행복하다.가끔 사진첩을 넘기며 찍었던 사진을 쭉 훑는 게 취미이다.사람은 순간의 기억으로 평생을 산다는 말에 공감한다. - 하노이 ..

배경 : 회원 가입이 실패되는 것이 옳을까?Picup 프로젝트에서 회원 가입이 요청되면 Member 서버에서 가입 내용을 기록하고, Storage 서버로 유저 타입과 함께 스토리지 생성을 요청한다. 기존에는 쉽게 가입을 실패시켰다. Storage 서버에서 처리에 실패하면 회원가입은 실패되었다. 외부 API 호출과 원자성, 서버 간 정합성이라는 키워드에만 집착해 기술로만 풀이하려고 했던 것 같다, 나라면 회원가입 폼을 열심히 작성했는데, 마지막 최종 제출에서 가입에 실패하면 그 서비스 안 쓸 것 같다. 가입 실패를 최소화하기 위해 외부 API 가 포함된 신규 가입 로직에서 필수적인 이벤트와 그렇지 않은 이벤트 분리를 고민했다. 그리고 각각의 이벤트 처리에서 발생할 수 있는 문제와 해결을 위한 고민을 정리..

애플리케이션은 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가 먼저 삭제되면, 요청을 처리할 ..

유닛테스트와 통합테스트나는 가급적 Test를 위한 Application context 를 지양했다. 유닛 테스트로 테스트 환경을 구성하는 시간을 줄이고 각 테스트를 짧게 하려고 노력했던 것 같다. 예를 들면 Controller는 standalone mock mvc로 api 의 요청, 응답 형태만 확인했고, Service Unit test는 테스트 외의 Service를 Mocking 하여 의도한 흐름대로 메서드가 호출되는지 정도만 확인했다. 통합테스트를 최대한 지양했지만 역설적으로 가장 크게 안정감을 얻고 있는 테스트는 통합테스트였다. 특히 트랜잭션 처리가 의도한대로 동작하는지, 예외 처리 끝에 데이터가 어떻게 남는지 확인하는 등 가장 헷갈리고 놓치기 쉬운 포인트는 결국 통합테스트에서 확인하게 되는 것 ..