AWS DEV SEOUL 2018 후기

들어가며

첫인상

첫 인상은 과거에 참관 했던 AWS 행사에 비해 규모가 꽤 작아졌다는 인상이었습니다. 그러나 Dev Seoul 이 아니라 ‘AWSOMEDAY-2018’ 를 갔었던 것이기에 다를 수 있다는 것을 감안하면 작은 규모에 비해 행사 자체는 나쁘지 않았습니다.

스케쥴

행사는 총 5개의 트랙으로 진행되었습니다. 공식 행사 일정표

1. 엔터프라이즈

2. 클라우드 네이티브

3. 인공지능

4. 핸즈온랩

5. 커뮤니티

각 트랙은 행사 이름만 보아도 유추가 되듯, 그에 걸맞는 주제 별 세션이 구성되어 있었습니다. 엔터프라이즈 쪽에 관심 가는 내용이 많았는 데, 참관 선정으로는 커뮤니티 트랙 위주로 스케쥴을 잡았습니다.

이유로는 Non Cloud 환경에서 Cloud 기반으로 마이그레이션 하는 현재 회사 상황을 고려해서 최대한 도움 될 만한 주제로 잡기로 했습니다. 이렇다 보니, AWS 자체의 심도있는 기능적인 부분에 대한 부분보다는 Cloud 기반에서 공통적으로 일어날 법한 주제들 위주로 선정하게 되면서, 자연스레 커뮤니티 트랙으로 가게 되었네요.

그래서 결정한 스케쥴은 아래와 같습니다.

1. 서버리스 엡 배포 자동화

2. 스타트업 관점에서 본 AWS 선택과 집중

3. 데이터센터 1도 모르는 개발자가 AWS를 만났을 때

스케쥴은 그럭저럭 원하는 내용 위주로 잘 잡았지만, 정작 행사 당일에 행사장 안에서 아무리 찾아봐도 커뮤니티 트랙이 보이질 않는 문제가 있었습니다. -_-;;

이리저리 찾아 보다가 안내 요원 분에게 물어 물어서 커뮤니티 트랙은 2층에 있었다는 걸 알게 되어서 부랴부랴 간 기억이 있었네요. 주변에 안내판이라도 있었다면 좋았을 텐데 란 생각이 -_-;

(발표 자료는 보통 AWS 기준으로 SlideShare Official AWS 에 올라오는 편인데, 아직까지 올라오질 않았습니다. 나중에 올라오는 데로 본 포스트를 업데이트 하겠습니다.)

세션

전과 마찬가지로 세션의 내용 요약은 편하게 음슴체로 하겠습니다.

1. 서버리스 앱 베포 자동화

발표자 : 김필중 AWS 솔루션즈 아키텍트

• 세션을 시작하기에 앞서, 서버리스가 무엇인지를 간략히 짚고 넘어가야함.

서버리스

서버리스란, 비지니스 서비스를 구축하는 데에 있어 서버(하드웨어)를 고려하지 않고 서비스를 구축하고 실행할 수 있게 하는 솔루션.

사전에 정의 된 코드만 작성해서 AWS에 서버 서비스 로직을 구동시킬 수 있게 하여 클라이언트 입장에서는 물리적 서버 구성 없이도 해당 기능을 이용할 수 있는 클라우드 서비스 모델을 말함.

AWS 에서 가장 쉽게 접하는 형태이고, 가장 유명한 것이 람다가 대표적임. (Azure 에서는 Azure Function 라 불리움) 이는 클라우드를 가장 잘 활용할 수 있는 모델이기 때문. (기존 벡엔드 기반의 서버 어플리케이션 설계와 구현이, AWS의 람다 서버리스에 코딩하는 걸로 바뀐 정도. 플랫폼에 AWS 위에서 동작하는 백엔드 로직이라고 생각하면 편함.)

서버리스로 인해 얻는 이점

1. 관리할 서버가 필요 없음 : 이는 엔지니어 관점에서의 이야기인데, 부가적인 운영 관련 잡다구리한 걸 잊고 코드에만 집중할 수 있음

2. 유연한 확장 : 오토 스케일링의 지원

3. 높은 가용성 : High availability 에 관한 이야기

4. 유후 자원 없음 : 이는 사용한 만큼만 비용이 발생하기 때문. EC2 는 서버가 떠있는 시간에 비해 서버리스는 기능 요청 시작과 종료에만 비용 발생

서버리스 APP 을 위한 최소한의 할일.

1. 함수 작성 (코드 준비) : python, javascript, java, c#…

2. 람다에 함수(코딩)를 업로드

3. 이벤트 소스 연결 : 이 연결이라는 것은 작성한 함수가 AWS 에서 실제 함수의 기능이 수행 되는 인프라에 작동하게 적용하는 거로 생각하면 됨.

람다의 실행 모델

동기, 비동기, 스트림 기반

• 동기 : API Gateway

• 비동기 : S3 과 대표적인 모델

• 스트림 : 실시간 데이터 생성, 메세지 솔루션을 통해 전달

  • 웹 앱을 위한 엔드포인트 : API Gateway

  • 서버리스 활용

배포 파이프라인

기본적으로 웹 서비스의 어플리케이션 배포 파이프라인은 아래의 형태를 띔

소스 > 빌드 > 테스트 > 프로덕션

• 지속적 통합 : Continuous Intergration.

  이 통합에서는 소스 > 빌드 > 테스트 까지의 과정만 담당함. 보편적인 모습.

• 지속적 전달 : Continuous delivery

  소스 > 빌드 > 테스트 > 프로덕션 까지 모든 파이프라인 포함이지만, 최종승인자나 어떠한 장치가 최종 승인을 해주어야 Production 에 반영하는 구조.

• 지속적 배포 : continuous deployment

  지속적 전달과 똑같이 소스 > 빌드 > 테스트 > 프로덕션 까지 모든 파이프라인 포함하는 구조. 단, 결정적인 차이는 최종승인자가 필요하지 않고 Automatic 으로 Production 에 반영이 됨. 가장 이상적인 형태.

CodeStar (AWS 솔루션)

자바로 치면 스트링 이니셜라이저랑 유사항 형태의 Project Code Generator. AWS 포탈에서 청사진(소스 템플릿을 AWS 에서는 청사진이라 표현함)을 선택하고 조합해서 원하는 프로젝트를 쉽게 프로비저닝 하는 솔루션

새 버전의 코드 배포에 대한 고려사항

서비스 운영에서 A,B 테스트와 같이, 신규 버전과 과거 버전 간을 전개할 수 있는 경우가 있음. 이에 따른 고려 사항은 아래와 같음.

1. 사용자에게 미치는 영향 최소화

2. 롤백 기술

3. 실행 모델 요소

4. 배포 속도

서버리스의 배포 패턴

1. ALL-At-Once

   단순하게 모든 인스턴스를 통째로 변경하는 것을 말함.

2. B/G Deploy

   특정 인스턴스를 변경 대상으로 선택하고, 이 인스턴스의 트래픽만 원격 차단되면서 신규 버전으로 배포를 준비함. 내부적으로 유효성 검사 이후 안전하다고 판단되면 배포를 시작, 배포가 완료 되면 차단 된 트래픽을 복구시키고 다른 과거 버전에 대해 이를 반복.

3. Conary/Linear

• Conary

  B/G 와 거의 유사하지만, 트래픽 조작을 정밀 하는 형태. B/G 가 전체 인스턴스 중에 1개씩 진행하는 것에 비해 Conary 는 설정에 따라서 전체 인스턴스의 과거 버전과 신규 버전의 운영 비율을 조절해가면서 배포하는 형태임.

  예를 들면 전체 100개 중에서, 최초 B/G 로 100% 중의 1%인 1개의 인스턴스에만 배포를 시작하고, 그 후 몇 분 뒤인 10% 인 10개의 인스턴스에 배포, 다음으로는 50%인 50개의 인스턴스에 배포.. 이런 식으로 선형적으로 배포하는 걸 말함.

• Linear

  Conary 와 비슷하지만, 일정한 시간에 동일한 증분으로 동일한 비율로 배포를 하는 형태.

서버리스 배포를 위한 도구

1. AWS CloudFormation

2. AWS Serveless APp Model (SAM)

   CloudFormation 이 다루기 어려워서 좀 더 쉬운 형태의 솔루션을 만듬.

API 명세를 위한 Swagger 활용

늘어 나는 API 엔드포인트 사양을 다 기재하려면 엄청난 노가다임, AWS 에서는 Swagger 와 연동해서 쉽게 API 엔드포인트를 쉽게 정리할 수가 있음.

AWS Servlerless App Repository

github 처럼 sam 템플릿을 저장하는 repository를 커뮤니티처럼 운영해서 쉽고 빠르게 타인의 안정적으로 운영했던 청사진(탬플릿)을 사용가능

람다 함수 버전 및 별칭

• 버전

  변하지 않는 함수의 고유 버전

• 별칭

  버전을 가리키는 변하는 라벨

람다 버저닝 모범 사례

$LATEST 버전을 기반으로 개발

단계 변수와 람다 별칭

람다 함수 와 실제 함수에서 운영 스테이지마다 호출 되는 API를 별칭으로 두고 처리

예시) Prod : Production, Stg : Staging, Dev : Develop

람다 별칭 트래픽 이동 및 안전한 배포

routing-config 파라미터를 추가해서 람다 함수에서 다른 두 버전을 가르키게 하고, 각 버전 별로 수신 트래픽의 비율을 지정시켜 할 수 있음.

예를 들면, 안정버전과 신규버전이 있다면, 안정버전에 80%, 신규버전에 20% 의 트래픽을 분산시켜서 장애에 대한 최소한의 피해를 처리할 수 있도록 할 수 있음.

람다 별칭 트래픽 이동 및 AWS SAM

엔드포인트 접근이 실패할 경우 ‘알람’ 설정이나 ‘특정 함수’ 를 실행하도록 처리가 가능

람다 작성 온라인 ide

웹 IDE에서 코드 어시스턴스, 브레이크포인트, 디버깅도 지원함. (발표자 왈, 꼭 보여주고 싶었다며 직접 시현도 함.)

서버리스를 마이그레이션 했을 떄의 이점

API 백엔드에서 새로운 기술을 쉽게 적용

1. 새로운 언어

2. 새로운 프레임워크

3. 람다 함수로 특정 기능 구현 후 연결

람다와 API 게이트웨이의 차이점

• 람다

  단일 함수 수준에서 제어, 서비스 호출 시에 투명성을 제공

• API 게이트 웨이

  URL 엔드포인트 수준에서의 제어, 클라이언트에서 호출 시에 투명성을 제공(DNS 서버 랑 비슷하다고 보면 됨)

모범 사례

canary 와 b/g 는 요즘에 와서는 default 선택이라고 생각함.

개발, 테스트, 스테이징, 프로덕션 환경을 위해 가능한 항상 분리된 스택을 유지

Local 개발

로컬에서 함수 테스트 및 디버깅이 필요함. AWS SAM CLI(기존에는 SAM LOCAL) 툴이 생기면서 여러가지를 할 수 있어짐

npm install -g aws-sam-local

(시연에 사용 된 람다 펑션 syntax 도 그렇고, 대부분의 툴은 Javascript 를 default 로 사용하는 걸로 보여짐)

codebuild : 높은 수준의 람다 테스트

람다의 경우 온 클라우드상에서 실행하다 보니, 로컬 테스트 하기가 조금 까다로웠음. 그러나 CodeBuild 가 탄생하면서 AWS 람다 환경과 비슷한 도커 컨테이너에서 테스트가 가능해짐. 실제 람다 클라우드 환경과 달리 커넥션 타임아웃을 없앨수도 있음.

서버리스 어플리케이션 로깅 : CLoud Watch

서버리스 앱 문제 해결의 접근

기본적으로 적절한 로그를 기록하는 것 부터 시작하는 것이 중요.

조금 어려운 문제들

Q. 복잡한 MSA 에서는 어떻게 로깅을 처리함?

Q. 이걸 다 어떻게 관리 & 트랙킹 함?

A. central log repository 를 구축한다던지 해야는 데.. 현실적으로 쉬운 게 아님.

AWS X-RAY

위의 ‘조금 어려운 문제’들을 해결해주기 위한 AWS 솔루션

각각의 인스턴스나 컨테이너마다 일종의 관계 맵을 그리며 인스턴스 간의 레이턴시 와 에러 빈도를 시각화.

콜드 스타트

자바와 같은 JVM 기반 언어는 람다 실행시에 JVM이 플랫폼에 올라와야해서, n 초의 준비시간이 필요함 이를 콜드 스타트라고함.

X_Ray 에서는 이러한 콜드 스타트도 체크가 가능.

문제발생한 포인트에는 stacktrace 도 찎혀있기 떄문에 쉽게 파악이 가능해짐.

생태계

1. CI

젠킨스 클라우드, travis ci, CODESHIP

1. 로깅 및 모니터링

IO/pipe 가 요즘 인기

정리

• 다양한 기능들을 활용하여 안전하고 제어된 방식으로 람다 함수 배포

• 자동 롤백은 배포 관련 문제 복구를 위한 가장 빠른 방법

• 이벤트 모델과 워크로드 크기에 따라 적절한 배포 패턴을 선택

• 서버리스 어플리케이션을 다양한 배포방식 으로 배포 가능

• 서버리스 앱은 로깅과 모니터링 기능이 빌트인 포함되야함

• 강력한 도구인 X-Ray를 활용하여 문제점을 시각화 하여 해결 (없다면 Central logging repository를 만들어야함)

2. 스타트업 관점에서 본 AWS 선택과 집중

한승호, 에멘탈 CTO

스타트업에서 AWS 도입하기

AWS 서비스 블록(솔루션들을 말함)이 너무 많아짐. 인프라 고민은 줄어들었지만, 되려 서비스 블록을 고민하는 시대가 옴 ㅠㅠ..

스타트업 with aws

스타트업이 아닌 사내 신규 서비스에도 비슷한 내용으로, 대부분 두 갈래로 나뉘어짐

1. 시작 단계 AWS 서비스 찾기

2. 성장 단계에서의 AWS 서비스

에멘탈 서비스 특징 소개

‘비즈넵’ : 경영 데이터 세무 회계를 관리하는 SAAS 기반의 서비스

• 에멘탈 회사의 스타트 시기

  AWS 를 아는 사람 1~2명

  데이터도 없고, 개발자도 없고, 사람도 없었음.

• 스타트업 초기 목표

  비용을 절약해서 적은 인력으로 빠르게 MVP 개발 (투자를 위해 구현에 집중)

• 학습

  MVP 단계에서는 최소 단계로 학습했음.

• 초기 단계 아키텍처의 함정

  초기단계에서는 MSA 서버리스는 개발속도를 높여주지 않을 수 있음.

• MSA 보다는 모놀로틱

  개발 할 내용 자체가 크지 않은 경우가 많아서 모놀로틱이 편할 수 있음.

• 서버리스 보다는 서버

  창업전부터 서버리스를 알고있었다면 서버리스가 좋을수있지만, 익숙치 않다면 비추천

• 그래도 마이그레이션을 염두하고 설계

  (뒤에서 나올 질의응답 내용을 미리 당겨서 작성함) 모놀로틱으로 구성을 하되, MSA 로 넘어갈 것을 기반으로 생각해야함. 쌩 모놀로틱은 마이그레이션이 어렵기 때문. 특히 DB 와의 커넥션 의존도를 바꾸는 게 많이 힘듬. 우리는 애초에 모든 걸 HTTP 기반으로 구성하였고, 모든 모듈간의 의존도를 최대한 느슨하게 설계해서 쉽게 마이그레이션함.

• DB 선택하기

  목적에 맞는 데이터베이스 선택

  데이터 크기, 용량, 아이템 크기, 건수, 내구성

  그런데 스타트업에서는 춥고 따뜻함이 없음. 가장 익숙한 DB 로 우선 개발 하는 것이 중요함.

  마켓핏 이후에 충분히 마이그레이션 가능

추천하는 AWS 서비스

• EC2, 서버리스 보다는 AWS beanstalk

• 다이나모DB 보다는 RDB

• 서비스 소개사이트 MVP

  클라우드프론트 + certicatemanager + s3

프로덕션 마켓핏 전략

최소 요구사항에 맞춰 익숙한 개발환경을 구축하여 MVP 개발에 집중

MVP 이후 성장하는 팀

사용자 증가, 개발자 증가, 팀 개수 증가, AWS 리소스 증가, 고정비용 증가 효율적인 확장을 위한 준비가 필요해짐.

스타트업의 성장

‘에멘탈’ 기준으로 말하는 것이지만, 대부분 스타트업 성장은 3단계로 봄.

마켓핏 > 전환 > 성장

성장 단계에서 선택한 AWS 서비스

API 서버, DB, 내부관리

AWS에서 API를 구축하는 n 가지 방법

자신이 파악하기에는 7가지까지 할 수 있음

서버리스, EC2, 컨테이너

• 서버리스

  유일한 단점으로 (어찌보면 장점) 자유도가 한정적임. 또한 native 모듈 사용이 어렵고, 로그가 파편화 됨(분산 됨)

• EC2

• EC2 With 컨테이너

  자신이 생각하는 가장 중요한 포인트가 독립성에 대해서 생각한다고 함

성장 단계에서 활용한 컴퓨팅 서비스

• aws 람다는 어느 시점이던 활용도가 높음

• 초기에 펑션 관리의 어려움이 있을 수 있음

• 중요한 비지니스 로직 보다는 보조적으로 활용함

데이터의 성장

데이터가 쌓이기 시작하고, 느려지기 시작하고 그러니깐 캐싱이필요해짐, 또한 데이터를 클랜징하고 분석하고 싶은 욕구가 생김

다이나모 DB

프로비저닝 용량을 구입하면 초기에도 저렴하게 활용 가능함.

주 보다는 보조적인 성격으로 사용하고 있음.

전환단계에서는 RDS > 오로라로 변경

내부 관리의 필요성

• AWS 리소스 증가

• 이벤트 증가

• IAM(권한 정책) 증가

• 인력(개발자) 증가

내부관리 정책과 IAM

• 초기에는 운영 스테이지 분리

• 전환 단계에서 VFC와 Network 분리. IAM 관리 할 때.

성장

로깅이나 이벤트가 많아지다 보니, 알림 같은 것이 필요해짐

화이트리스트 방식의 IAM 관리

AWS + @ 3년동안 노하우, 팁 공유

• AWS Console 에서 지원하지 않는 기능이 SDK에 있는 경우가 있음.

• Wrap CLI 활용하기

• Wrap SDK 만들기

  자주 쓰는 기능에 대해서 묶은 Wrapping SDK 를 만듬, 이는 관리 차원에서의 히스토리(버저닝) 이득도 가져짐.

AWS Fully Managed Service

1. saas

2. servless

3. EC2 를 내부적으로 사용하지 않는 것

:) 마무리하며

• AWS 서비스 선택 전략을 계획해야함.

• 익숙한 인프라를 사용 하되 마이그레이션을 염두, 그리고 AWS + @ 의 것을 찾는 것이 중요.

• Best Practice 를 쫓기 위한 지속적인 개선이 중요

질의응답

Q. 모놀로틱 에서 MSA로 전환할 떄 헤프닝이나 조언해줄 만한 것이 없는가?

A. 당장 생각나는 것은 RDB 와의 커넥션문제가 떠오름. 우리는 처음부터 마이그레이션을 염두해두고 했기 때문에 TCP 커넥션이 아니라 HTTP 프로토콜 형태로 구성을 했었음.

서비스 규모가 작기 떄문에 서비스 레이어 별로 인스턴스를 크게 분리하거나 많이 만들 필요가 없기 떄문에, 어플리케이션 서비스 내에서 모듈을 분리할 수 있는 형태로 개발하고 있음.

요점은 쌩 모놀리스가 아니라, 추후에 확장할 수 있는 여지는 생각해보아야 한다고 조언.

Q. 이후 질문들은.. AWS 실제 필드 상의 헤프닝 관련 질문이어서 질문을 못쫓아감.. -_-;;

…

3. 데이터센터 1도 모르는 개발자가 MSA를 만났을 떄

안주은 / MyMusicTaste 엔지니어

Who am i

• 처음 만난 장고 앱을 클라우드에 올리면서, 클라우드와 Devops 에 인연이 생김.

• 자신이 가장 좋아하는 것 : 문제를 효율적으로 풀기, 쉽게 풀기.

• 효율적으로 하면 충분한 개발 시간과 숙련된 사람들이 필요함.

• 그런데 이상 =/ 현실 은 반비례 (인력 충원이란 희망을 포기하기로 함)

• 그래서 내린 결론..

  • 꼭 필요할 때에만 우리가 만들자

  • 꼭 필요할 때에만 운영하자

Main problems we’ve solved

MSA

• MSA 는 혼돈의 제왕.

• 불필요한 곁가지를 쳐내자.

  • 관리 포인트를 줄이자.

• 사내 프레임워크 개발, 공통적으로 해야하는 기능들을 모듈로 뽑음

• 스타트업에서는 폴리그랏이 이상적일 때가 많지만, 실상 메인터넌스 사람 뽑기도 턱없이 부족함

컨테이너 오케스트레이션을 어떻게 할 것인가?

• 도커 스웜을 갈까? 쿠버네티스를 갈까? 처음에는 스웜을 선택했는 데, VM 도 관리해야하고 복잡했음

• AWS Fargate 를 선택함

• Fargate 로 오니 task degination 만 적용하니 쉬웠음

• VM 도 스케일아웃을 어떻게 해야할지 고민해야는 데 Fargate 가 다 처리해줌

• 그래도 네트워크 관련, 로깅 관련 에 대해서는 심층적으로 고민해야함.

Fargate 와 비용

• 비용 측면에서는 Fargate 는 비쌀 수 있음. 기존 ECS 기반에 비해 30% 정도의 비용이 증가했음.

• 비용 증가가 부담스럽지만, (개인적인 생각으론) 비용 투자를 통해 시간을 절약하여 집중해야 할 과제(비지니스 Core)에 집중하는 게 좋다고 결론을 내림.

Fargate 와 로깅

• fargate 에서 스트림으로 엘라스틱서치로 쏴버리고 Kibana 로 뷰잉함.

CI/CD

젠킨스 > 테라폼(TerraForm) > AWS Fargate

테라폼으로 간단하게 B/G 전개를 할 수 있음.

시크릿 매니지먼트 : Vault

• 개발자가 왜 Key 를 관리해야하지하는 생각에 찾아봄.

• 오픈 소스 Vault 를 도입함.

• 그런데 아이러니한건 테라폼에서도 Vault 의 아키텍처를 미리 준비해놓은게 있었음 -_-;

spa

• 장고 탬플릿 기반에서 react 로 넘어갈 때의 문제 공유

  • 같은 도메인으로 보게 어케 할 것인가? : CORS

  • 서버 사이드 랜더링을 해야하나? : OG, SEO

• 람다edge 를 통해서 처리함

  • 람다에 패킷이 도착하기 전에, 중간에서 (프록시처럼) http 헤더를 인젝션 할 수 있음. 이를 통해 CORS를 처리함

솔루션

• devops 관점 vs devloper 로서의 관점

• 소수 devops vs 다수 devops 에서 아키텍처가 달라져야하나

• 대부분 스타트업에서는 긴밀하게 빠르게 구현하게 하다 보니, devops 에 초첨을 보게 됨

  • 누구나 쉽게 운영 변경할 수 있는 인프라 설계

  • 누구나 쉽게 운용 변경할 수 있는 오토메이션 설계

보너스

RDS 에서 다이나모 DB 로 옮길 떄, 전체적으로 테이블 디자인을 보고 옮겨야함.

특히 key value 가 맞을지 안 맞을지를 잘 봐야함. 우리는 지금 엄청 고생중임.