그동안 코로나로 인해서 온라인으로만 진행되었는데 올해 드디어 현장에서 열린 AWS Summit Seoul 2023에 다녀왔다!
이번 AWS Summit Seoul 2023은 5월 3일, 5월 4일 이틀동안 열렸고, 장소는 코엑스였는데 코엑스 전체를 대관할 정도로 대규모로 진행되었다.
너무 너무 가고 싶었는데 마침 팀원 분들께서 가게 되어서 데리고 가주셨다! 개인적으로 이번이 첫 오프라인 컨퍼런스, 써밋이었는데멋진 경험을 할 수 있어서 정말 감사했다.
괜히 조기 마감 된게 아님을 실감할 수 있을 정도로 정말 많은 사람들이 있었는데, 대학생부터 주니어, 시니어까지 다양한 연령대와 데이터베이스, AI, 인프라, 시스템 등의 직종이 모인 것 같았다. 아무래도 오랜만의 오프라인 행사여서 그런지 많은 분들이 참석하셔서 뜨거운 관심과 열기를 느낄 수 있었다.
이 많은 사람들이 다 한 써밋을 보러 온 거라니..!
어떤 내용들이 구성되어 있나?
오전 9시 30분에 시작해서 오후 6시에 끝나는 일정으로
하루에 베뉴 별로 6개의 세션이 동시에 진행되어 원하는 강연을 골라서 보는 방식이었다.
Day 1은 산업 업종별 강연으로 AWS를 사용하고 있는 회사에서 어떻게 다루고 있는지, 업종 별로 사용에 어떤 특징이나 차이점이 있는지 알아볼 수 있는 시간들로 구성되어 있다.
Day 2는 기술 주제별 강연으로, 입문/중급/심화 기술로 나뉘어 AWS의 새로운 기술과 다양한 분야의 클라우드 전문가들의 강연을 듣고 배울 수 있는 시간들이었다.
나는 Day 2에 참석했고, 데이터베이스와 관련되면서 흥미로운 주제로 골라서 아래와 같이 듣기로 계획하였는데,
아쉽게도 두번째 13:10 세션은 참석하지 못 했다.. 인기가 너무 많았는지 스탠딩 좌석까지 모두 마감되었다고 해서 입장이 불가능했다..
세션 간 쉬는 시간이 2~30분 정도 되기 때문에 인기 있는 세션은 최소 10분 전에는 가서 미리 줄을 서야 되겠다는 교훈을 얻을 수 있었다 😂
입장
코엑스 B홀에서 사전신청한 사람들한테 이름이 적힌 카드 목걸이를 준다. 이걸로 베뉴 들어갈 때마다나 부스 방문할 때마다 태깅하고 그러니까 계속 쓰게 된다.
또 처음에 기조연설 들어갈 때 선착순으로 런치박스 먹을 수 있는 고무밴드도 나눠주니까 받아놨다가 바꿔 먹을 수 있다.
기조연설
먼저 9시 30분~10시 40분에 기조연설이 진행되는데 3층 오디토리움에서는 강연자가 직접 강연하는 모습을 볼 수 있다. 그 외에는 지하 1층, 1층, 2층에서 강연 장면을 실시간으로 화면으로 만나볼 수 있다. 너무 시간에 맞춰 가면 3층 오디토리움이 마감되었다고도 해서 현장의 모습을 확인하고 싶다면 조금 넉넉히 가는 것이 좋을 것 같았다.
본격적으로 기조연설이 시작되기 전에 쇼트 영화 같은 영상을 시청했다. 아마존 CTO인 버너 보겔스가 연기를 한 것도 재밌었고, 내용 자체도 생각보다 너무 재밌었는데 주제는 비동기에 대한 내용이었다.
실제 세상은 비동기적(asynchronus)으로 동작하고 있고 그래야만 하는데, 그렇지 않고 동기적으로 동작한다면 어떻게 되는지를 그리는 내용이다.
"실제 세계는 비동기적이다. 동기적인 것은 하나도 없다. 많은 일이 항상 일어나고 있다. 자연은 비동기식으로 작동한다. 컴퓨터 시스템도 비동기식으로 만들어지는 게 자연스럽다. 이벤트 드리븐 아키텍처로 느슨하게 결합된 시스템(Loosely coupled systems)을 만들어야 한다." 라고 한 적도 있다.
Day 2 기조연설자는 아래와 같았는데
특히, Flitto 강동한 CTO님을 뵐 수 있어서 좋았다.
Flitto는 번역 통합 서비스를 제공하는 스타트업인데, 평소에도 참 멋진 CTO님과 문화가 있는 회사라고 생각하고 있었다.
한국은 Node.js 불모지라고 불릴 정도로 Node.js를 주로 사용하는 기업이 많지 않은데, 그 속에서도 Node.js로 운영을 하고 있고 결국 성공을 하신 그런 분이시다..
그리고 LG U+ 송주영 연구위원님도 짧은 순간 뵌 거였지만 정말 괜히 최연소가 아니구나 싶을 정도로 말씀을 너무 잘 하시고, "딱 이 5가지만 기억하세요" 하면서 원칙들을 딱 딱 알려주실 때 멋지다고 생각했다..
딱 이 5가지라는 건, DevOps에서 중요한 5가지 단계인데
Security
Reliability
Automation
Organization
Governance
1번부터 피라미드 모양으로 기반이 되어 쌓아 올라간다고 생각하면 된다고 한다.
윤석찬 수석 테크 에반젤리스트께서 AWS 기반 아키텍처와 다양한 도구, 서비스를 소개해주셨고
나머지 내용은 윤석찬 수석 테크 에반젤리스트께서 강동한님과 송주영님께 Q&A 하는 방식으로 진행되었다.
내용을 간단하게 정리해보자면
스타트업에서 AWS를 사용하면 좋은 점
클라우드를 이용하면 서버리스를 구성하기 좋고, 비용도 절감할 수 있음
서비스를 글로벌하게 제공하면서 겪은 점들
인프라를 어떤 리전에 구축할 지도 고려해봐야 함
거주 지역 / 기기 접속 위치 / IP 위치 등 어떤 점을 기준으로 잡을 지 정하는 것이 쉽지 않음
AWS의 글로벌 서비스를 이용하면 쉽게 해결할 수 있음(AWS DynamoDB 글로벌 테이블 등)
보안에 대해서
보안에 대해 정의하고 가자면, 보안이란 접근 통제, 암호화, 마스킹, 감시, 추적, 인증과 권한 관리 등이다.
보안 모범 사례를 하나 잡고 따라가면 좋음
놓치기 쉬운 부분인데 예를 들면 데이터베이스 연결 정보 등을 평문으로 박지 않도록 주의하기(AWS Secrets Manager 등 활용 가능)
빼놓을 수 없는 비용 문제
스팟 인스턴스를 적극적으로 활용해보기
온디맨드하게 사용하기
리전 마다 서비스 과금이 다르기 때문에 레이턴시가 크게 중요하지 않은 작업이라면 저렴한 리전으로 사용하기
인프라 운영에 대해서
모든 인프라를 코드화해서 자동화하는 것 추천(IaC)
이 인프라를 Why/When/What 만들었는지 늘 추척할 수 있어야 함
온디맨드하게 사용하기, 예를 들면 단순히 오토 스케일링을 설정해 놓는 것이 아니라 필요할 때마다 하루에 몇 번이라도 자동으로 정책을 수정할 수 있어야 함
스팟 인스턴스, Graviton 등을 활용하기
점심
런치 박스를 받으면 요런 구성으로 되어 있다. Day 1 거는 다른 것 같던데 샐러드 과일 쿠키까지 이것저것 있어서 좋았다.
각 베뉴마다 나눠주는 거 같은데 고무밴드랑 교환해서 받으면 원하는 곳에서 먹으면 된다.
EXPO
MongoDB, Redis, Redhat, SKT, LG CNS, Megazone Cloud 등 많은 기업들이 부스를 운영했다. 세션을 안 듣는 시간이나 쉬는 시간 같을 때 들리면 되는데 이것저것 체험해보고 상품을 받거나 기업들과 서비스 상담을 해볼 수도 있다. 부스를 돌면서 설문조사 많이 하고, 가방이랑 시계, 무선 충전 거치대 등을 받아왔다. 사람들도 엄청 많고, 같이 다니면서 체험하는 과정 자체가 넘 즐거웠다.
끝으로..
첫 오프라인 써밋을 이렇게 대규모로 열리는 곳에 함께 참여할 수 있어서 뜻 깊은 시간이었다. 정말 멋지고, 대단하고, 똑똑한 사람들이 참 많다는 것을 다시금 느끼고 더 열심히 정진해야겠다는 동기 부여를 확실히 받을 수 있었다.
자세한 내용은 아래 홈페이지에서 확인할 수 있고, 발표된 강연 자료와 영상은 6월 중에 공개될 예정이라고 하니
재해복구에 대한 대비는 온프레미스를 이용할때나, 클라우드를 이용할때나 항상 중요하다. 이 세션에서는 AWS Backup을 활용하여 최소한의 비용으로 클라우드 환경에서 운영 중인 시스템에 대한 멀티 리전 재해 복구를 자동화하는 방안을 살펴본다. 더불어 온프레미스에서 운영중인 시스템에 대한 재해복구를 비용 효율적으로 자동화하기 위해 어떻게 AWS Elastic Disaster Recovery를 활용할 수 있는지도 알아본다. AWS 서비스를 활용해 대부분의 시간동안 유휴 상태인 복구 사이트에 대한 비용을 최소화하면서도 재해복구를 자동화할 수 있다.
✅ 목차
AWS에서의 재해복구
AWS Backup을 이용한 멀티리전 재해복구
AWS Elastic Disaster Recovery를 이용한 온프레미스 재해복구
1. AWS에서의 재해복구
Disaster Recovery
비즈니스 지속성
희귀하지만 대규모 장애상황
자연재해
기술적 이슈
휴먼 액션
개별 장애에 대한 목표 측정
복구 시간(RTO)
복구 시점(RPO)
복구시점 및 복구시간 목표
클라우드에서의 재해 복구 전략
복구시간 목표 - RTO
Backup & Restore는 서비스 중단 기간이 길어지더라도 수용 가능한 경우에 적용한다.
복구시점 목표 - RPO
재해가 비즈니스에 미치는 영향을 고려해야 한다. 예를 들어 대규모 금융 트랜잭션을 처리한다면 짧은 기간 중단되더라도 리스크가 매우 크지만, 신입사원 교육용 시스템 같은 경우면 중단되더라도 수용 가능할 것이다.
중단이 매우 크리티컬하고, 고비용 투자가 가능하다면 → Multi-Site A/A
중단되어도 비즈니스에 영향이 없다면 → Backup & Restore
재해에 의한 데이터 손실은 Pilot light와 warm standby가 거의 같음
빠른 복구 → 웜 스탠바이
데이터 손실만 없으면 된다 → 파일럿 라이트
2. AWS Backup을 이용한 멀티리전 재해복구
재해복구를 위한 백업 대상
메타데이터는 인프라 구성 정보로, 완벽하게 원래대로 복원하기 위해서는 메타데이터 백업도 필요하다.
메타데이터를 어떻게 추출해서 백업할 것인지는 온프레미스와 클라우드 환경에 따라 달라진다.
온프레미스
CMDB(구성관리데이터베이스)
호스트, 어플라이언스 설정 정보가 다 들어있음
수기, 엑셀 파일, 전용 시스템 등
AWS 클라우드
CMDB: 온프레미스와 동일하거나 클라우드와 연동
AWS API: API로 설정된 상태를 읽어오고, 구성 정보로 할 수 있음
IaC: 인프라 자체를 코드로 관리함
AWS CloudFormation, Terraform, AWS Cloud Development Kit
Backup & Restore 기반 재해복구 자동화
재해가 발생하면 DR 리전에 백업해둔 데이터와 메타데이터를 조합해 원본 데이터와 동일하게 복구
자동화가 필요하다면 각각 구현해야 하고, AWS Backup 서비스를 활용할 수 있음
AWS Backup 개요
AWS Backup 이란?
완전관리형 정책 기반 백업 서비스
여러 AWS 서비스들에 걸쳐 자동화된 중앙 집중식 관리를 지원하는 백업 서비스
컴퓨트, 블록 스토리지, 파일 스토리지, 오브젝트 스토리지, 데이터 전송, 데이터베이스, 애플리케이션, 관리, 하이브리드
재해복구 자동화 구현 예
모든 데이터와 메타데이터를 DR 리전에 복제
CodeBuild 등 CI/CD 도구를 이용해 자동 복구 가능
1. Iac 관리 및 백업
2. IaC 코드 의존성 분리
3. 관리형 리소스에 대한 간접 접근
4. 재해 복구 태스크의 실행 독립성 확보
5. 재해복구 시스템의 지속적인 검증 및 보완
3. AWS Elastic Disaster Recovery를 이용한 재해복구
클라우드 재해 복구 장점
클라우드 재해 복구의 비즈니스 효과
견고한 운영 체계: 최상위 복구 목표를 기반으로 안정성과 가용성 달성
운영 효율성: 중복 인프라 및 라이선스의 필요성을 줄임으로써 비용 절감 확보
비즈니스 연속성에 대한 확신: 운영 환경에 영향이 없는 쉬운 재해 복구 테스트를 수행해 가동 중지 시간 및 데이터 손실 최소화
AWS Elastic Disaster Recovery란?
다양한 고객의 요건에 맞는 안정적이고, 확장 가능하며, 안전한 스토리지 서비스 포트폴리오 제공
Jenkins Docker 컨테이너를 관리할 새 systemd 서비스인 jenkins를 정의합니다.
서비스 파일에는 세 개의 부분이 있습니다.
[Unit]: 서비스가 필요로하는 모든 항목을 나열합니다. 적용하기 위해서는 Docker 서비스가 실행 중이어야 합니다.
[Service] :
Restart=on-failure : 서비스가 어떤 이유로 실패하거나 중지되면 자동으로 다시 시작되어야함을 지정
서비스가 비정상적으로 종료되었을 때에만 동작함. 호스트 머신이 강제 종료되는 경우는 시스템 수준의 이벤트로서 서비스 자체의 종료와는 다르기 때문에 일반적으로 호스트 머신이 강제 종료될 때는 systemd가 서비스를 재시작하지 않음. -> 데몬 감시 스크립트 등록이 필요할 것으로 생각됨
Group : irteam, irteamsu, root 사용자 모두 실행 가능하도록 Group 설정
ExecStart : Jenkins 컨테이너를 시작하는 명령을 지정
ExecStop : Jenkins 컨테이너를 중지하는 명령을 지정
[Install]: 서비스가 시작될 때, 이 경우 multi-user.target 레벨에서 시작됨을 지정
3. 새 서비스 파일을 인식하도록 systemd 데몬을 다시 로드합니다.
sudo systemctl daemon-reload
서비스 파일에 대한 변경 사항을 인식하도록 systemd 데몬을 다시 로드하는 것입니다.
4. Jenkins 서비스를 부팅 시 자동 시작하도록 설정합니다.
sudo systemctl enable jenkins
결과
Jenkins 비정상 종료 시 Jenkins 도커 컨테이너가 자동으로 실행되는 것을 확인하기
SIGABRT 로 비정상 종료 됨
자동 재실행 됨
로그
2. 호스트 머신 비정상 종료(reboot) 시 Jenkins 도커 컨테이너가 자동으로 실행되는 것을 확인하기
