2019 AWS Seoul Summit- 신한금융지주 발표사례

발표ppt 캡쳐본과 발표내용 같이 올립니다. 

 

제가 말씀드릴내용은 이미 여러분야에서 AWS 사용사례가 있지만 금융을 오래한사람들은 AWS를 어떻게 바라보고 
여러과제들을 어떻게 고민하고 해결했는지 말씀드리면 의미 있겠다 싶어 준비했습니다.

순서는 제주지니는 무엇인가 
AWS 도전기, 리슨앤런,벡스트스텝으로 진행하겠습니다.

저희 제주지니는 맛집,코스,톡톡,핸즈프리,줄서기,할인쿠폰등 제주여행에 필요한 다양한 서비스를 제공하고 있습니다.

주요서비스로는 
맛집
3000개, 5000개 많은 맛집을 제공하면 요새 선택장애가 많은분들이 있는데 더 어렵겠죠?
그래서 현지인이 직접 엄선한 500여개의 맛집과명소를 제공하고 있습니다.
여행코스
비오는날의 여행, 해안가도로 여행, 포토여행, 처음제주여행등 다양한 테마가 준비되어있습니다.
또 톡톡서비스가 제공되고 있는데 제주여행시 궁금한점을 문의하시면 현지인이 직접 답변해드리는 서비스도 있습니다. 
이밖에 더 다양한 서비스가 제공되고 있으니 앱을 설치해 보시면 분명히 만족하실 겁니다.

금융업무와 금융앱 위주의 개발자로서 여행앱을 한다.
처음 컨설팅문서를 보았을때만해서 야~ 재미있겠다.
금융앱도 했는데.. 머 어렵겠어?
또 새로운분야에 대한 흥미와열정 이런게 충만했었죠 .. 너무쉽게 봤던거죠
만삽뜨고 허리한번 펴기 운동할 줄 모르고…

금융개발은 새로운기술, 새로운방식보다는 폭포수모델과 안정적인 시스템을 우선시합니다.
검증되기 전까지 도입을 꺼려하는게 사실입니다.
"어 이거 도입하면 좋겠는데 ~" 그럼 "레퍼런스있어?" 이게 먼저나오죠

아직 클라우드에 개인정보가 허가되지 않아서 비중요정보시스템 인가를 받아 시작했습니다.
신문에서 추후에 금융도 클라우드를 허용한다는 기사를 본거같습니다.
그럼 금융도 클라우드로 많이 넘어오겠죠 
저희는 일정이 촉박해서 마이크로서비스아키텍쳐가 아닌 웹와스 방식으로 하려 했으나
그래도 한번 해보자는 개발자들의 의지로 MSA 기반으로 시작했습니다. 

왜 신한 DS가 데브웁스 기반으로 AWS프로젝트를 시작하게 되었을까?
프로젝트는 기간과 일정이 있기에 기간에 맞추어 역산을 마니하게 됩니다.
제주여행 성수기인 여름을 타겟으로 하게되면 전통적인 온프라미스 방식으로는 인프라세팅만 1달이상 걸리게 되어있죠
그래서 클라우드쪽으로 시작했고 이렇게 빨리 개발환경이 되리라고는 생각하지 못했습니다.

작년에 저도 처음 애자일로 프로젝트를 진행했었습니다.
30일 기준으로 스프린트를 나누어 진행했었는데 이건머 한달에 한번오픈 
수정사항 폭탄 또다시 신규스프린트는 기다리고있고 .. 진짜 헉헉대면선 개발을 진행했던 기억이 있습니다.
여러분도 애자일로 하시려면 많을 고민을 하셔야 할거 같습니다.

엣날 클라우드와 현재클라우드가 무엇이 다른거지?
엣날 클라우드는 현재 처럼 다양한 서비스가 존재하지 않았습니다.
그러나 현재 클라우드는 정말로 다양한 서비스의 조합이라고 생각합니다.

저희도 CI/CD를 하기위해 코드시리즈를 적용하려 했으나 
개발당시 저희 사무실이 네트워크 문제로 GIT이 붙지않아서 적용하지 못했습니다.
그래서 CLI기반의 반영절차를 준비하여 현재까지 사용중에 있습니다.

개발과운영의 계정분리 및 소스분리 수정사항반영이 쉽다고 발생되는 대로 반영할수없으니 
저희 나름대로 반영절차를 수립해서 현재까지 운영해오고 있습니다.

마이크로 서비스 아키텍처
모노리틱에서 MSA로의 개발은 생각의 전환이 필요합니다.
프로젝트 시작전 AWS에서 교육을 받을때.. 
세분화 하면 어떤장점이 있는거지?
기존 프레임웍을 쓰면안되나 개발기간도 짧고 검증된게 있는데…
왜 스프링부트를 사용하라는거지? 
부트는 블로그정도에 사용하는 프레임웍인데 .. 
이런저런 고민이 많았습니다.
그러다가 아 작게 나누어야 하니 가벼운 프레임웍이 필요한거구나
세분화해서 100개로 나누면 1개가 문제가 발생해도 99개에 사이드 임팩트가 없겠구나
또 사용량이 몰려도 오토스케일링을 하면 시스템이 주저앉을 일은 없겠구나 라고 이해했습니다.

저희 지니도 AWS ECS구조인 데스스타 처럼 멋지게 만들어야지 라고 했으나 현실과이상은 달랐습니다.
그럼 어느선에서 나눌 것인가 정답은없습니다.
그래서 작년에 저희는 업무기준으로 세분화 하였습니다.
이벤트
이벤트가 시작하면 인스턴스를 늘리고 끝나면 줄여야하니 분할 
이렇게 유저, 마이니지, 코스, 톡톡, 관리자, 배치등 16개로 세분화 하였습니다.
그러다가 올해 다시 사용량기준으로 재분활 하였습니다.  
마이지니 즉 마이페이지는 사용량이 적어 유저로 합쳐 배치는 푸시랑 같이 사용하니 배치서비스, 푸시서비스로 분할 
AWS는 사용량으로 비용이 정산되니 운영중 갑자기 더많을 비용을 발생시킬수 없으니
재조정 하여서 신규서비스를 추가할수 있게 하였습니다.

개발자의 고민 
자바기반으로 세분화 하였더니 하나하나가 무거웠습니다.
그럼 자바가 정답을 아닐텐데 …
MSA 최적화 되어있다는 장고프레임웍을 써야 하나 ..
그럼 파이썬 개발자는 어디서 구하나 단가는맞을려나 .. 
비용은 정해저 있으므로 고민했던 부분입니다.

공통프레임웍도 
처음에는 개발자의 편의성을 위해 많은기능을 넣었으나 어! 또 무겁네 ..
MSA에서는 공통모듈도 가벼워야 되는구나를 알게되었죠 

또 상황에 따라 개발언어도 다르게 써야한다? 
어 그럼 유지보수는 어떻게 하지 인력이 교체되면 거기에 맞는 인원을 채울수 있을까?
마이크로서비스라고 해도 자바면자바, 파이썬이면 파이썬 하나로 통일해야 되지 않나
운영을 위해서는 개발언어도 통일되야 한다는게 제생각입니다.

어플리케이션을 세분화 하여도 DB가 하나라면 문제가 발생시 전체가 영향을 받습니다.
그럼 DB도 세분화된 서비스에 맞게 나누어야 되나 
서비스대 서비스 호출시 DB조회보다는 느리던데 
관리도 안될테고…
그래서 저희는 데이타베이스를 세분화 하지는 못했습니다.
DB를 세분화 하는것을 좀더 많을 고민이 필요할거 같습니다.

우리의 삽질
저희는 스프링부트 최선버전을 적용하다보니 구글링해도 잘안나와.
또 MSA로 개발하다 개선책을 깨달아 수정또수정
웹에서되는데 앱에서 안돼
한국어에서 되는데 중국어에서 안돼
AWS사이트에서 샘플보고 개발하려는데 직역이 많아서 이해가 안돼 이게먼소린지…
엘라스틱캐시, 아마존 SNS 서비스가 잘되다가 안돼 삽질 
결제처리시 응답받을때 한글이 깨지는 문제가 발생 
결제업체에 문의도 해보고 고민을 많이 했으나 
결론은 저희가 도커에 경량화된 알파인 리눅스이미지를 사용하고 있었습니다.  5M정도 되지요
근데 알파인 리눅스이미지는 로케일이 제한적이였던 겁니다. 그래서 해당문제는 
다른방향으로 풀어서 해결했었습니다.

만삽뜨고 허리한번 펴기 
새로운것을 한다는것은 정성과 열정 이두가지가 없으면 힘들다고 생각합니다.

시스템 아키텍쳐입니다.
EC2인스턴스 부분을 좀더 자세히 말씀드리겠습니다.
저희는 처음 CPU가 높은 C4인스턴스를 적용해여 시작했습니다.
그러나 자바기반이라 메모리를 마니 먹더라구요 꿀꺽꿀꺽
운영하다보니 CPU는 마니남고 메모리가 부족하여 메모리가 우선시되는 M5 인스턴스로 변경했습니다.
저희의 특성이라할수있겠죠 많은 기능을 넣다 보니 메모리가 우선시 되는 인스턴스로 변경해야 했습니다.

M5인스턴스 2개일경우 동접 만명정도는 버티는것도 확인했습니다.
어떻게 알았냐구요 저희 신한DS부스로 오시면 비하인드 스토리를 말씀드릴께요 

DB는 오라클이 최고아닙니까
오픈소스 DB로 가능할까?
제주여행 성수기때 데이터 부하가 많을텐데 사실 적정을 마니했습니다.
MySql로 선택하려다 클라우드에 최적화되어있다는 오로라 마이sql를 선택하였고
리드 리플리카서비스를 적용, 액티브 액티브 상태로 사용하고 있습니다.
지금까지 많은 부하가 있었을텐데도 문제없이 사용하고 있습니다.
그러나 DB는 오라클이 최고 그리고 오로라 mysql도 괜찮다 라는 생각입니다.

앱속도를 개선해야하는 과제가 개발중간에 있었습니다.
단말부분은 브라우저 캐시를 적용하였고
서버캐시문제도 고민했었습니다.
선택에 문제겠지만 
네트워크를 통한 서버캐시도 있지만
저희는 서버기반에 카페인캐시를 적용하였습니다.
테스트해보니
컨트롤러 단에 걸어주면 사용자가 확! 느낄수 있는속도를 제공하고
서비스단 이후에 걸면 그효과는 미미했습니다. 
혹시라도 서버기반 캐시를 적용하시고자 하시면 참고하시면 좋겠습니다.
그러다가
한번 접속한 인스턴스를 계속 접속해야하는 니즈가 발생했습니다.
그래서 로드 발랜서인 ALB에서 ECS인스턴스 호출방식이 어떤방식인지 확인해보니 라운드 로빈방식이었습니다. 
그럼 다른방법은 없는지 다방면을 확인해보았는데 
로드발랜서에서 세션을 유지시켜주는 스틱키세션이라는 옵션이 있다는것을 알게됐고
테스트 하여 적용하여 해당이슈를 해결했었습니다.
이런 문제는 언제라도 발생할수 있으니 참고 하시면 좋겠습니다.

카카오톡처럼 이라는 부푼꿈을 안고
스마트기기에 최적화 되어있는 mqtt프로토콜 기반으로 채팅을 개발하였고 
운영중에 있습니다.
안정적인 채팅서비스를 위해 
mqtt프로토콜을 지원하는 액티브엠큐 메시지 브로커를 적용하였습니다.
간편하게 적용하기위해 아마존엠큐를 적용하려 했으나 
그당시 서울리젼에는 서비스 되고있지 않아
토커기반에 엑티브엠큐를 사용하였고 
현재는 서울리젼에 아마존엠큐를 사용하실수 있다고 알고있습니다.

한국버전에서는 이미지나 자료를 S3에서 서비스하였으나
중국버전 서비스시 안정적인 네트워크 속도의 위해 클라우드 프런트를 적용했습니다.

중국버전에서는 구글,페이스북,카카오톡등 관련서비스들의 사용이 불가능합니다.
관련url를 호출하면 굉장히 느려지는 현상이 있었죠
그래서 저희는 중국관련 API를 적용하였고 지도,길찾기등은 바이두 api를 사용하였습니다.

안드로이드 푸시도 구글이기에 중국버젼에서는 사용할수 없습니다.
그래서 확인해보니 
아마존 sns서비스에서 바이두푸시를 제공하고 있어서 해당문제를 해결할수 있었습니다.

중국결제인 웨쳇이나 알리페이 테스트시는 중국계졍을 가진 핸드폰이어야만 테스트가 가능합니다. 
저희도 당사의 중국인 직원을 수배해서 어럽게 테스트를 진행 했엇습니다.

중국서비스를 고려하고 계신분들은 참고하시면 좋을거 같습니다.

완전관리형이라 
개발당시에는 마음에 확! 안와닿았습니다.
그러다 운영 하면서 완전관리형이라는 말이 많이 와 닿았죠
사람이 관여하지않아도 안정적으로 운영이 되는구나를 느끼면서 
개발자들이 개발/운영 까지 다할수 있겠구나 
그러나 더많을 부하도 있겠구나 라는것을 느꼈습니다.
그러므로 개발자들한테 잘해줘야합니다.

저희의 잘한점은
개발시 절대적인 시간이 부족했으나 MSA로 개발한점
제휴서비스를 위한 VPC환경및 플랫폼화 한점
다국어와 다양한 오픈API를 적용한점
브라우저캐시, 카페인캐시를 적용한점을 들고 싶습니다.

부족한점은
좀더 MSA를 세분화하지 못한점 테스트를 더많이 해보지 못한점
개발시 수시로 공통모듈을 업데이트 하므로 공통화가 부족한점
지금은 개발,운영소스가 분리됐지만 그당시 못한점
좀더세세한 속도개선을 못한점이 아쉽습니다.

향후계획 
비즈니스 부분은 
앱네 지속성을 가지고 사용해야하는 컨텐츠에 집중하고 잇습니다.
제주 오프라인 강자와 제휴하여 온라인서비스는 제공하는 제주도 디지털 플랫폼을 지향합니다.
더 다양한 제휴서비스를 제공하여 제주여행시 지니앱 하나로 모든것을 해결하는 여행토탈서비스를 준비하고 있습니다.

기술부분은
모노리틱에서 MSA 서버리스형태로 가고있습니다.
IT기술도 더좋은것 새로운것으로 변하기 때문에 
거기에 맞추어 대응되어야 한다고 생각합니다.
추후 클라우드는 서버가 없는세상이 도래할것 같습니다.
저희지니도 http를 통한 로드발랜서 ALB호출   ALB에서 람다평션을 호출하여 처리하는
서버리스형태의 서비스가 도입되어있습니다. 
더욱더 확대하여 새로운 변화에 대응하고 준비하려 하고 있습니다.