Lambda

들어가며 현재 투입되어있는 프로젝트에서는 최근 기존의 인프라 구성에서 많은 부분 전환된 일정이 있었습니다. 그 당시 Autoscaling을 적용하기 위해서 예상되는 문제점은 무엇이 있었는지, 그리고 그것을 어떻게 극복했는지 다음과 같이 정리하였습니다. 기존 환경 Autoscaling이 적용되어있지 않은 was EC2 2개 운영 해당 서버의 Spring Framework 애플리케이션 내에는 @Scheduled 어노테이션을 통한 스케줄잡 사용 일부 스케줄 관련 코드 : @Scheduled(cron = "0 30 9 ? * *", zone = "GMT+9:00") public void notifyLongTermNoUseAdmin() { if("1".equals(GkConstant.WAS_NUMBER)) { // STG, PRD 의 1번 서버인 경우에만 Batch 실행 try { List<LongTermNoUseAdminVO> notifyAdminDataList = longTermNoUseAdminSvc.getNotifyAdminDataList(); for (LongTermNoUseAdminVO voNotifyAdmin : notifyAdminDataList) { try { List<String> mailReceiverIDList = new ArrayList<>(Arrays.asList(voNotifyAdmin.getAccountId())); // 메일 수신인 리스트에 장기 미사용자의 이메일 주소만 추출해 추가 // 대상자별 mail template parameter 가 다르기 때문에 for 문을 통해 개별 메일 발송 awssesClient.sendEmail(mailReceiverIDList, "[" + ospAppConfig.getGkServerType() + "]" + MailEnum.NOTIFICATION.getMailSubject(), setMailHtmlBody(MailEnum.NOTIFICATION, voNotifyAdmin), null); LOG.info("##### SUCCESS Sending Notification Email : {}, {}", voNotifyAdmin.getSaGuid(), voNotifyAdmin.getAccountId()); } catch (Exception e) { e.printStackTrace(); LOG.info("##### FAIL Sending Notification Email : {}, {}", voNotifyAdmin.getSaGuid(), voNotifyAdmin.getAccountId()); } } LOG.info("##### SUCCESS notifyLongTermNoUseAdmin Batch"); } catch (Exception e) { e.printStackTrace(); LOG.info("##### FAIL notifyLongTermNoUseAdmin Batch"); } } } 위와 같이 “코드가 실행되는 두대의 서버 중 vm option의 특정 시스템 프로퍼티가 ‘1’로 되어있는 서버에서만 동작”하도록 조건이 설정 (if("1".equals(GkConstant.WAS_NUMBER))) 문제점 Autoscaling을 적용하게되면 서버가 동적으로 생성 및 삭제되기 때문에 어느서버가 1번 서버인지 기준이 사라지는 상황. 따라서 기존의 Scheduled 로직이 여러 서버에서 중복으로 실행되거나 혹은 전혀 실행될 수 없는 로직 ...