안녕하세요. 민짱입니다!
오늘은 오랜만에 IT 기사를 올립니다.
일본에 클라우드 서비스 수요가 폭발적으로 늘고 있는 것 아시나요?
코로나19 당시 아직도 팩스 쓰고 있는 나라가 있나? 쯧쯧 하고 보았던 일본이 클라우드 서비스, SaaS 도입 수요가 확확 늘고 있습니다.
일본의 클라우드 서비스 중에 가장 큰 셰어를 갖고 있는 것이 Amazon AWS라는 것 아시나요? AWS의 매출 중 미국에 이어 2위가 일본이랍니다. 이 부분은 다른 기사로 올려 드릴게요.
그래서 오늘은 AWS에 대한 기사로 AWS 아키텍처(구성도) 그리는 법에 대해서 알아볼게요.
본 기사는 제가 첫 작성한 것은 아니고 아마존 재팬의 테크니컬 트레이너로 있는 스기토모 글을 번역하고 정리해서 보내 드립니다.
안녕하세요! 테크니컬 트레이너의 스기모토 케이타입니다!
저는 업무로 고객에게 AWS의 다양한 교육을 제공하고 있습니다만, 코스에 따라서는 AWS를 이용한 시스템의 구성도를 수강자가 스스로 그릴 수 있게 트레이닝도 하고 있어, 자주 다음 상담을 받습니다.
"AWS 아키텍처 다이어그램을 어떻게 그리는 것이 맞습니까?"
AWS의 아키텍처 다이어그램을 그리는 상황은 다음과 같이 다양한 장면이며, 비슷한 의문이나 고민을 가지고 계신 분도 많지 않을까요?
- 상세 설계를 위한 구성도 필요
- 팀에서 wiki 등에 이미지를 붙여 넣고 싶어요
- 구성 검토 단계 등에서 다이어그램을 보고 토론하고 싶어요
- 워크숍을 진행하여 깊게 이해하기 위해 그려 보고 싶어요
그래서 이번에는 AWS 아키텍처 다이어그램을 어떻게 그리면 좋은지 고민하고 있는 분들에게 그 요령을 Step으로 나누어 소개합니다!
목차
Step 0. 아키텍처 다이어그램에 “정답”은 없다!
들어가기 전에 구성도를 그리는 것에 "어깨 힘 빼도 된다"라는 마음가짐으로 임하기를 바랍니다. 구성도에 “정답”은 없습니다.
물론 AWS 서비스의 위치 관계 등에 "적절성"은 있지만 아키텍처 다이어그램에서는 여러분이 " 무엇을 전하고 싶은가"에 따라 구성도를 그리는 방법이나 상세 등의 표현을 자유롭게 바꿀 수 있다고 저는 생각합니다.
다만, 구성도를 그리는 목적의 하나는 「상대에게 알기 쉽게 전하는 것」이므로, 알기 쉽게 그리기 위한 포인트는 있습니다. 이에 대한 구체적인 포인트를 다음 Step에서 확인합시다!
Step 1. AWS 서비스의 위치 관계 의식
서두에서도 말했듯이 아키텍처 다이어그램에 “정답”은 없지만 AWS는 글로벌 인프라에서 서비스 를 제공하고 있으므로, 그 요소와 서비스의 위치 관계를 의식해 두는 것으로 알기 쉽게 네트워크 구성도를 그릴 수 있습니다. 따라서 먼저 AWS 글로벌 인프라의 구성 요소를 살펴보겠습니다.
AWS에는 전 세계에 위치하는 리전이라는 위치가 있으며 각 리전은 가용 영역(AZ)이라는 데이터 센터의 논리적 그룹으로 구성되어 있습니다.그 밖에도, 최종 사용자에게 콘텐츠를 보다 낮은 레이턴시로 전달하는 등에 이용하는, 엣지 로케이션을 포함한 Point of Presence (POP) 도 전 세계에 많이 존재하고 있습니다. AWS 오사카 리전 페이지에 있는 이 그림도 알기 쉽기 때문에 참고해 보세요.
AWS 서비스는 엣지 로케이션에서 기능을 제공하는 서비스, 리전만 지정하여 사용하는 서비스, 어느 리전의 어느 AZ에서 사용할지까지 고객이 지정하는 서비스 등으로 나뉩니다. 이러한 관점이 아키텍처 다이어그램에 서비스를 배치할 때 의식해 두면 좋은 부분이므로 구체적인 예를 들어봅니다.
AWS 글로벌 인프라 내부 또는 외부
아키텍처 다이어그램에는 AWS 외에도 등장인물이 있을 수 있습니다. 예를 들어 온프레미스 데이터 센터와 AWS Outposts는 AWS 글로벌 인프라 외부에 배치됩니다.
엣지 로케이션에서 사용할 서비스인지 여부
많은 서비스는 리전을 지정하여 사용하지만 Amazon Route 53 , Amazon CloudFront , AWS Global Accelerator 등의 서비스는 AWS 글로벌 인프라 안에 있지만 리전에서 외부에 있습니다.
리전을 지정하고 사용하는 서비스는 VPC 내부 또는 외부
Amazon EC2 , Amazon RDS , Amazon S3 , Amazon DynamoDB 등의 리전을 지정하여 이용하는 서비스는 리전에 배치합니다. 이 중 S3 및 DynamoDB와 같은 일부 서비스는 VPC 및 가용 영역(AZ)을 지정하지 않고 리전 지정에서만 사용됩니다. 따라서 AZ를 지정하지 않고 리전 사양에서만 사용합니다. 따라서 AZ를 의식하지 않고 리전 내부 및 VPC 외부에 배치합니다. 반대로 EC2나 RDS 등의 VPC를 지정하여 이용하는 서비스는 VPC 안에 배치합니다.
VPC의 서브넷과 AZ는 어떻게 나타내는가?
VPC에 배포하는 서비스의 위치 관계를 보다 자세히 설명하려면 인터넷과 직접 라우트가 있는 퍼블릭 서브넷과 그렇지 않은 프라이빗 서브넷을 각각 배치합니다. 또한 서브넷은 AZ를 지정하는 리소스이므로 다중 AZ VPC를 나타내는 경우 VPC에 여러 AZ가 포함되도록 AZ별로 서브넷을 배치하는 경우가 많습니다.
여기까지의 위치 관계를 의식해, 제가 그린 아키텍처의 일례가 이쪽입니다.
자주 질문받습니다만, VPC 안의 서비스에서도 Elastic Load Balancing (ELB)는 복수의 서브넷을 지정해 이용하는 서비스이므로, 그림으로 나타낼 때 배치 장소를 고민하기 쉬운 서비스입니다. 위 그림과 같이 2개의 서브넷을 이용하는 경우는 서브넷에 걸쳐서 아이콘을 배치하거나, 3개 이상의 서브넷을 이용하는 경우는 서브넷 사이에 배치하거나 등이 자주 있는 패턴입니다! 서브넷 사이에 ELB를 배치하는 그림도 그려 보았습니다. 참고로 봐주세요.
이제 위치 관계를 이해할 수 있겠지요.
그럼, 아키텍처 다이어그램을 어디까지 상세하게 쓰면 좋을까?라는 것이 다음의 포인트입니다.
Step 2. 「무엇을 전하고 싶은가」가 중요하며 그림 표현은 자유롭게 바꾸어도 OK
아키텍처 다이어그램을 그리는 방법에 “정답”은 없다는 것을 다시 상기시켜 드립니다. 그림을 자유롭게 표현해 문제없습니다.
예를 들어 EC2를 이용한 시스템 설계의 아키텍처 다이어그램을 작성하는 경우, 여러분은 그 다이어그램에서 어떤 것을 전하고 싶습니까? 다이어그램을 그리는 목적은 상황에 따라 다양합니다.
- 상세 설계 등으로 이용하고 있는 AWS 서비스 목록을 가능한 한 세밀하게 전하고 싶다
- 재해나 장애에 대한 검토나 논의를 위해 멀티 AZ를 이용하여 가용성이 높은 구성이 되어 있다고 전하고 싶다
- 외부 사례 소개를 위해 멀티 계정과 멀티 리전을 이용한 대규모 시스템 설계임을 전하고 싶다.
각 목적에 대해 이를 실현하는 방법이 무엇인지 생각해 봅시다.
사용 중인 AWS 서비스 목록을 최대한 자세히 설명하고 싶다.
상세 설계와 같이 가능한 한 세밀하게 사용하는 서비스를 전달하려는 경우 EC2 인스턴스와 함께 Amazon Elastic Block Store (EBS) 또는 보안 그룹까지 그릴 수 있습니다. 다음 다이어그램에서는 몇 가지 보안 그룹을 사용하고 있는지, 각 EC2 인스턴스마다 몇 GB의 EBS를 사용하는지 파악할 수 있도록 그려 보았습니다.
멀티 AZ를 사용하여 가용성이 높은 구성을 사용하고 있음을 알리고 싶다
재해 및 장애에 대한 가용성을 검토하고 토론하기 위해 다중 AZ에서 Auto Scaling Group을 사용하여 시스템 가용성을 높이고 있다고 알리고 싶다면 어떻습니까?
앞의 그림에 그대로 Auto Scaling Group을 추가할 수도 있지만, 그리기 양이 너무 많아서 그림이 복잡해지고 오히려 보기 어려워질지도 모릅니다. 아키텍처 다이어그램의 목적이 사용 중인 AWS 서비스의 세부 목록을 전달하는 것이 아니라면 EC2 인스턴스를 사용할 때 기본적으로 사용되는 EBS 또는 보안 그룹을 생략한다고 판단할 수 있습니다..
전하고 싶은 부분을 강조하기 위해 이용하고 있는 서비스를 굳이 생략한다는 것도, 그림을 알기 쉽게 하기 위한 하나의 방법입니다. 제가 그린 예를 올려 둡니다.
대규모 시스템 설계라는 것을 전하고 싶다
공개 사례 등에서 멀티 계정이나 멀티 리전을 이용한 대규모 시스템임을 강조하고 싶은 경우는, 그림을 간단히 보기 쉽게 하기 위해, 본래는 멀티 AZ 구성이어도 AZ 마다 서브넷을 그리지 않는 경우나 VPC조차 그리지 않는다는 방법도 있습니다. 적절히 생략하면 AWS 계정 및 리전별로 어떤 서비스를 사용하여 대규모 시스템 구성이 있는지 충분히 알 수 있습니다!
이곳은 AWS 배포 사례 : 주식회사 머니 포워드에 기재되어 있는 아키텍처 다이어그램입니다. VPC 안에 AZ까지 그리지 않았지만 멀티 계정을 사용하고 있다는 것을 한눈에 알 수 있습니다.
이곳은 AWS 도입 사례 : 스마트 뉴스 주식회사에 기재되어 있는 아키텍처 다이어그램입니다. 지역에 VPC를 그리지 않았지만 액세스를 분산하는 다중 지역화가 실현되고 있다고 전해집니다.
다음은 Multi-Region Infrastructure Deployment | AWS 설루션에 설명된 아키텍처 다이어그램입니다. 오른쪽에 있는 Secondary Region 에는 거의 아무것도 그려져 있지 않습니다만, 같은 구성을 전제로 하고 있기 때문에, 복수의 리전에서도 간결하게 아키텍처가 그려져 있습니다.
어떠세요? 전하고 싶은 부분을 명확하게 한 다양한 표현 방법이 있어 자유롭게 그려도 OK라는 것이 이해가 되셨을까요?
이제 그림을 그릴 준비가 되었으므로 이제 그림을 그려 봅시다!
Step 3. 완성을 목표로 우선은 종이와 펜으로 그려 본다
아키텍처 다이어그램을 그릴 수 있으려면 먼저 손을 움직여 봅시다!
뭔가를 익히는데 반복해서 해 보는 것 이상의 지름길은 그렇게 없습니다. 우선 가벼운 시작을 위해 종이와 펜을 손에 들고 점점 그려 봅시다.
그리고 실제로 손을 움직여 아키텍처 다이어그램을 그릴 때 제가 중요하다고 생각하는 것은 아래 적습니다.
" 깨끗하게 전체를 정리하는 데 시간을 들이는 것보다 완성하는 것을 우선한다. "
아키텍처 다이어그램의 작성 도중에, 깨끗하게 그려 넣으려고 지나치게 시간이 걸리는 분을 가끔 보았습니다. 도중에 전체를 정리하고 있어도, 「아, 여기를 더 변경하자! 조금 전의 그림의 밸런스를 변경하지 않으면 안 된다!」라는 분을 자주 봅니다. 정돈은 마지막에 하면 충분하기 때문에, 우선은 전체상을 그려 버립니다. 그쪽이 작업의 효율도 올라야 합니다!
그리고 마지막으로, 여기까지도 참고에 몇 가지 소개한 것 같은, AWS 서비스의 아이콘을 이용해 만든 그림을 어떻게 그려 나가면 좋은 것인가?라고 하는 의문에 답변드릴게요!
Step 4. 필요에 따라 도구도 활용하기
필기를 하는 유연성을 저도 좋아해서, 트레이닝 중의 해설이나 질의응답 시에는 화이트보드를 이용해 잘 그림을 그립니다. 그러나 이외의 옵션이 있으면 더 기쁘겠겠지요?
- 한 번 작성한 것을 지속적으로 변경하고 유지 관리하고 싶다.
- 비슷한 그림과 서비스를 많이 그릴 필요있다.
- 사내의 설계서이거나 외부에 공개하는 것이므로 공식적인 그림을 원한다.
손 그리기를 사용하는지는 상황에 맞게 선택해 주셨으면 합니다만, AWS의 서비스 아이콘등을 이용해 “확실한” 아키텍처도를 그리고 싶은 경우에 이용할 수 있는 툴을 소개합니다!
공식 AWS 아키텍처 아이콘 사용
AWS는 AWS 아키텍처 아이콘 웹 사이트에 서비스를 나타내는 공식 아이콘 세트를 제공하며 Microsoft PowerPoint에서 사용할 수 있는 템플릿, PNG, SVG 형식의 파일 등을 다운로드할 수 있습니다. 여러분이 아키텍처 다이어그램을 만들 때 꼭 활용하십시오!
※이용의 가이드라인도 있으므로, 외부에 공개하는 경우 등은 꼭 한번 읽어 주세요.
「서비스 아이콘」과 「리소스 아이콘」에 대해서
공식 아이콘을 들여다보면 AWS의 각 서비스를 나타내는 "서비스 아이콘"과 서비스별 세세한 기능과 리소스 등을 나타내는 "리소스 아이콘"이 존재합니다.
예를 들어, 모니터링 서비스인 Amazon CloudWatch는 CloudWatch 자체를 나타내는 서비스 아이콘과 각 기능을 나타내는 Alarm, Logs 등을 리소스 아이콘으로 제공합니다.
서비스 아이콘과 리소스 아이콘 중 어느 것을 사용하면 좋습니까?
개인적인 어드바이스로서는 그림은 나중에 얼마든지 변경할 수 있으므로 우선은 서비스 아이콘을 이용해 그려도 좋다고 생각합니다. 서비스 아이콘이 없는 경우나, 세세한 기능까지 나타내고 싶은 경우에 자원 아이콘을 이용한다고 하는 생각으로 시작해 갑시다.
덧붙여서 아키텍처에서 자주 나오는데, 서비스 아이콘이 없기 때문에 리소스 아이콘을 이용하는 것은 다음과 같습니다.
- 인터넷 게이트웨이
- NAT 게이트웨이
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
※ 여담입니다만, AWS의 아이콘은 정기적으로 갱신되고 있기 때문에, 옛날 아이콘과 지금의 아이콘의 형태가 다르거나 합니다. 가끔 옛날 아이콘의 팬들도 계시지만 현재는 공식 아이콘에서 다운로드할 수 있는 것은 최신 판 뿐이므로 양해 바랍니다.
아이콘을 얻었으므로 이제 아키텍처 다이어그램을 그립니다! 아키텍처 다이어그램을 만드는 데 어떤 도구가 있습니까?
그리기 도구 선택
익숙한 사람은 프레젠테이션 용 슬라이드 만들기 도구를 사용하는 방법도 있습니다!
Microsoft PowerPoint를 사용하는 사람은 공식 아이콘 세트 템플릿으로도 제공되므로 쉽게 시작할 수 있습니다. 그 밖에도 브라우저만 있으면 이용할 수 있는 프레젠테이션 슬라이드 작성 서비스도 이용할 수 있습니다. Google 프레젠테이션을 사용하면 여러 사람이 쉽게 동시 편집 할 수 있으므로 대화하면서 아키텍처 다이어그램을 만들 수 있습니다!
또한 AWS 아키텍처 아이콘 웹 사이트의 "그리기 도구 및 다이어그램 생성 도구"에는 도구 목록이 포함되어 있으며 도면에 특화된 기능이 풍부한 서비스가 많이 있습니다. 일부 도구에는 AWS 아이콘 세트가 포함되어 있어 유용합니다.
여러 사람이 그림을 그릴 때는 Google 프레젠테이션을 사용하거나 개인적으로 그릴 경우 Draw.io 를 사용하는 경우가 많습니다. Draw.io 등의 작화 툴은 사용법조차 익숙해져 버리면, 그림을 배치하는 넓이를 유연하게 변경할 수 있거나, 아이콘과 문자가 세트가 되어 있으므로 그림 안에서 이동시키기 쉽거나, 아이콘끼리의 연계가 쉽고 등의 이점이 있습니다.
그리고 중요한 일이므로 다시 말합니다.
" 깨끗하게 체재를 정돈하는 데 시간을 들이는 것보다 완성하는 것을 우선한다 "
이것은 그리기 도구를 사용하는 경우에도 동일합니다. 도구라면 성형이 용이하게 할 수 있으므로 도중 단계에서도 깨끗하게 하면서 진행하고 싶어 지기 쉽지만, 그것은 완성시킨 후에도 충분합니다!
감사합니다!
민짱이었습니다.
참고 글 : AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ?
AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? - 変化を求めるデベロッパーを応
AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? 2022-04-04 How to be a Developer こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「海が走るエンドロー
aws.amazon.com
