스토리텔링 AWS를 공부하고 있습니다.
도입 1화는여기.였다.
2회의 이번 주제는'고가용성 및 사업 지속성'이다.
또 이야기는 허구로 실제 존재하는 인물, 단체와는 아무런 관계가 없다.

두말 할 것 없이 모두 만족하다

저녁에 집에 돌아온 A는 적당히 저녁을 먹고 곧바로 AWS를 배우기 시작했다.
AWS 솔루션 기술 인정 – 전공 시험 영역을 확인합니다.
1. 고가용성 및 사업 지속성
2. 원가 계산
3. 디자인 관리
4. 네트워크 설계
5. 데이터 저장소
6. 보안
7. 확장성과 확장성
8. 클라우드 이동 및 혼합 구조
"위에서부터 순서대로 공부해요?"
처음에는'가용성 및 사업 지속성'이었다.
"나는 갑자기 무엇을 배워야 할지 모르겠어,!?"
결론적으로 AWS의 각 서비스 개요를 먼저 확인하기로 했다.
"고가용성을 말하자면 서버의 복용이다. 서버를 만들 때 EC2를 사용해야 한다."
EC2부터 보기로 했습니다.
https://aws.amazon.com/jp/ec2/
위에서 다시 읽으면 신뢰성이라는 높은 가용성과 관련된 항목이 있습니다.
EC2의 가용성은 99.95%에 달합니다.
"서버의 가용성이 숫자로 표시됩니다. 대단합니다.
AWS의'고가용성과 사업 지속성'을 이해하려면 각 서비스의 SLA를 알아야 하는가!?
다른 서비스도 봐주세요.
다음은 스토리지 서비스의 S3입니다.
"아마존 하면 S3죠. S3의 가용성이 대단한 것 같아요."
https://aws.amazon.com/jp/s3/
마찬가지로 위에서부터 읽는다.
99.99999999%의 내구성과 99.99%의 가용성이 기록되어 있습니다.
"아,99.9999999999%의 내구성이 대단하군요.
S3를 사용하세요. 99.9999999999%의 내구성이 있고 사업 지속성이 좋아서 고객에게 제안할 수 있잖아요!
"고가용성 및 사업 지속성"은 서비스 전반에 대한 SLA 파악
같은 요령으로 다양한 서비스의 개요를 지속적으로 읽다.
RDS의 "Aurora"에 대한 개요를 읽을 때, 자체 복구 기능에 대한 설명이 있습니다.
https://aws.amazon.com/jp/rds/aurora/details/
Aurora 자체 복구 기능
디스크에 장애가 발생하면 백그라운드에서 자동으로 수정 가능
또한 데이터베이스가 충돌하면 감지되어 다시 시작됩니다
가용성을 손상시키지 않습니다.
"그렇구나,자가치유 기능이구나.
고가용성 및 사업 지속성을 이해하려면 이런 기능을 이해해야 한다.
각종 서비스의 개요를 계속 읽다가 눈치챘을 때는 이미 3시였다.
나는 많은 서비스의 SLA와 각종 서비스가 가지고 있는 높은 가용성을 실현하는 메커니즘을 이해했다.
"아직월요일이지만너무 열심히했어요.
하지만'고가용성 및 사업 지속성'에 관해서는 좋다.
내일 S선배한테 오늘 배운 거 얘기해.
칭찬 받겠지?내일을 기대합니다!"
"곧 AWS를 배우기 시작할 거예요. 행동이 빨라요!"
A는 다음날 회사에 갔을 때 바로 어제 배운 것을 S선배에게 알렸다.
'고가용성 및 사업 지속성'으로서 배워야 할 것은 각 서비스의 SLA를 단도직입적으로 이해하고 자가 복구 등 각 서비스가 지닌 기능을 이해하는 것이다.또한 각 서비스의 SLA와 각 서비스는 고가용성을 위해 다양한 기능을 갖추고 있습니다.
어젯밤에 그렇게 많은 것을 배웠으니 정말 대단하다.
"S선배님한테 칭찬 받았어요! 일을 안 해도 돼요. 어제 노력한 보람이 있어요!"
하지만 그것만으로는 좀 부족해요.
"음..."
"각 서비스에 대한 SLA를 이해하는 것이 당연히 중요합니다.
고가용성을 위한 아키텍처 설계가 중요합니다.
"후~"
S선배가 구체적인 예로 알려줬어요.
예를 들어 다기능 영역 설계
AWS에서는 여러 응용 프로그램(데이터 센터)을 사용하여 환경을 구축할 수 있습니다.
예선을 시작하는 데 많은 시간이 걸렸고 여러 데이터 센터에서 간단하게 불필요한 설정을 구축할 수 있었다.
여러 데이터 센터의 여분 때문에 만일의 지진 등 재해에 대비해 사업 지속성이 중요하다.
간단한 구성례로 설명하다.
다음은 사이트의 다기능 구역 디자인의 예이다.

먼저 두 abira biti 영역에서 각각 웹 서버로 EC2를 구성합니다.
ELB를 프런트에 배치하고 두 EC2에 액세스를 할당합니다.
따라서 EC2의 경우 다기능 디자인이 우선입니다.
다음은 RDS이지만 RDS 실례가 만들어질 때만 Multi-AZ를 켜는 것이 더 간단합니다.
기본 DB 인스턴스와 대체 DB 인스턴스의 데이터는 항상 동기화됨
기본 DB 인스턴스에서 장애가 발생하면 자동으로 예비 DB 인스턴스로 전환됩니다.
이렇게 하면 다기능 사이트를 구축할 수 있다.
한 측의 유효구역이 떨어지더라도 서비스를 계속 제공할 수 있다.
이어 "RDS의 도라비 지역 대응은 멀티-AZ만 켜는 것이기 때문에 매우 간단하지만, 주의해야 할 부분이 많다.
우선 멀티-AZ를 열면 DB 인스턴스 수가 두 개로 변하기 때문에 비용이 두 배로 늘어난다.
RDS 실례 목록에는 실례가 하나도 없는데 왜 두 실례의 비용을 받는지 알아야 한다.
그리고 실례를 전환할 때의 동작을 이해해야 한다.
구체적으로 무엇을 하고 있느냐는 것은 초급 실례에 관한 host를 대기 실례로 바꾸는 것이다.
DB 인스턴스가 전환되더라도 EC2에서 DB의 IP 주소를 캐시하거나 DB와의 연결을 지속하면 전환된 DB 인스턴스에 연결되지 않을 수 있습니다.
"휴.
간단한 예로 아주 명백하다!
여러 데이터 센터의 이중화를 시작하는 경우
꼭 해야 할 일들이 많고 힘들지만.
AWS로 이렇게 쉽게 할 수 있다니!
"""고가용성 및 사업 지속성""은 귀사의 덕분입니다."
"완벽해...
고가용성을 실현하는 과정에서 다기능 구역 설계만 제어하면 좋지 않다.
여러 개의 구역 구조도 있다.
또 방금 말한 것은'고가용성 및 사업 지속성'중의'고가용성'뿐이었다.
고가용성을 추구하면 비용이 많이 든다.
원가가 너무 높아서 당연히 계속 경영할 수 없다.
사업의 지속성을 고려할 때 어느 수준의 가용성을 실현해야 하는지를 검토해야 한다.
"원가를 포함해 사업 지속성을 고려하는 것인가.
더 열심히 공부하겠습니다!"
AWS의 "고가용성 및 사업 지속성"은
단순히 각 서비스의 기능과 SLA를 이해하는 것만은 아닙니다.
나는 원가 방면을 고려하여 고가용성을 실현할 수 있는 구조를 설계할 수 있다는 것을 이해했다.
"S선배님, 참을성 있게 가르쳐 주셔서 감사합니다!"
"공부를 너무 잘해서 아침부터 S 선배랑 얘기했어요.
최고!계속 공부하세요."
A의 공부는 아직 계속되고 있다.
...스토리 스타일의 기사를 쓰는 데 익숙하지 않지만 계속해야 한다!
다음은'2. 원가 계산'의 학습이다.
나는 다음 주에 투고할 계획이다.