프로젝트의 마지막 단계에서 EKS를 사용할 계획이다. 직접적인 인프라 구축에 앞서, EKS를 활용하는데 필요한 네트워크 구성 전략에 대해 학습해보고자 한다.

가장 좋은 참고문서는 AWS의 공식 문서이다. EKS와 관련된 공식 문서는 많이 있지만 제법 구체적으로 나열된 요구사항을 적어둔 문서가 있다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/network-reqs.html

이 외에도 다른 문서들을 참고하였다.

1. VPC IP 대역

가장 우선적으로 제시하는 사항은 IP 의 갯수이다. 어쩌면 EKS를 사용할 때 가장 핵심적인 부분이라고도 볼 수 있겠다. 사용 가능한 IP 의 갯수가 고려 대상인 이유는, 구축된 클러스터에서 각 Pod들이 실제로 VPC의 리소스를 소모하기 때문이다. 따라서 VPC 자체의 IP 대역을 설정할 때도 신중할 필요가 있을 것이다. AWS 공식문서에서는 규모가 큰 서비스의 경우 처음부터 IPv6를 사용할 것을 권장하고 있다.

2. 서브넷 고려 사항

EKS는 생성시 다른 서비스와 비슷하게 서로 다른 AZ에 배치된 최소 2개의 서브넷을 요구한다. 이후, 지정된 서브넷에 2~4개의 ENI을 생성한다. 이 ENI 들은 VPC와 클러스터의 연결과 kubectl API를 사용할 수 있는 경로를 제공한다. 따라서, 적절한 권한과 kubeconfig 인증이 있으면 로컬 머신에서 EKS 클러스터에 대해 kubectl exec/logs 과 같은 kubectl API 명령어를 사용할 수 있다.

쿠버네티스 버전이 업데이트 되면 EKS는 ENI를 삭제, 재생성 할 수 있다. 따라서 기존의 네트워크 경로가 동작하지 않을 수 있음을 고려해야 한다.

3. 클러스터의 서브넷 요구 사항

클러스터 생성, 업데이트시 요구사항이다.

• IP 주소는 6개 이상 있어야 하며, 16개 이상을 권장한다.
• 서브넷은 서로 다른 AZ에 있어야 한다.
• Outposts나 Wavelength 서비스에 위치할 수 없다.
• 서브넷은 프라이빗을 권장한다.
• us-east-1, us-west-1, ca-central-1 서브넷은 사용할 수 없다.

4. 구성 요소별 IP 주소 패밀리

서비스 별로 사용 가능한 IP 패밀리를 표로 제공한다. 어떤 서비스는 IPv6를 제공하지 않는다. 현 단계 구상에서는 IPv4를 가정하고 있으므로 넘어간다.

5. 노드의 서브넷 요구 사항

기본적으로 EKS의 리소스는 클러스터를 생성할 때 지정한 서브넷에 배포할 수 있으나, 지정하지 않는 서브넷에도 배포가 가능하다. 이 경우, 해당 서브넷에 클러스터의 네트워크 인터페이스는 생성되지 않는다. 리소스를 배포하고 싶은 서브넷은 여러 조건을 만족해야 한다.

• 충분한 IP 주소
• 포드와 서비스에 IPv6를 적용하고 싶다면, 서브넷에 적당한 IPv6 CIDR블록 하나와 IPv4 CIDR 블록이 있어야 한다.
• 외부 인터넷에서 특정 포드로 접근이 필요한 경우, 로드밸런서와 퍼블릭 서브넷이 하나 이상 있어야 한다.
• 노드를 퍼블릭 서브넷에 배포 하려면 서브넷이 IPv4 또는 IPv6 퍼블릭 주소를 자동 할당 해야 한다.
• 노드를 프라이빗 서브넷에 배포 하려면, 해당 라우팅 테이블에 적절한 경로가 있어야 한다.
• 서브넷에 로드밸런서를 배포하려면 서브넷에 적절한 태그가 있어야 한다.

6. 공유 서브넷 요구 사항

VPC 공유 기능을 사용할 경우의 요구 사항이다. 본 프로젝트에서는 사용하지 않을 기능이므로 생략한다.

AWS에서는 다양한 문서를 제공한다. 그 중에서 MES in the AWS cloud 라는 문서를 발견해 소개해 보고자 한다.

MES

우선, MES에 대해 알아볼 필요가 있다. MES는 Manufacturing Execution System의 줄임말이다. MES는 1970년대에 데이터 수집 도구와 계획 시스템의 확장으로 시작됐다. 공장 현장에서 원자재를 완제품으로 전환하는 생산 프로세스를 모니터링, 추적, 문서화, 제어하는 소프트웨어 솔루션이다. PLC, SCADA 같은 현장 시스템과 통합되며, ERP, PLM과 같은 시스템과 연결된다. 즉 제조 현장의 말단 기계들과 기업의 경영 시스템을 이어주는 시스템이라고 보면 되겠다.

이 문서에서는 MES가 일반적인 어플리케이션처럼 마이크로 서비스 기반의 패턴으로 발전해 나가고 있는 것에 대해 소개하고 있다. 이를 통해

• 애자일 개발 지원
• 잦은 업데이트 지원
• 기술적 유연성 제공
• 확장성 제공
• 공급망 중단에 신속한 대응

등의 장점을 내세우고 있다. 그러나, 운영 오버헤드를 증가 시킬 수 있으므로 기존의 모놀리식 아키텍처와 비교하여 기업의 상황에 맞게 선택해야할 것 이다.

1. 마이크로 서비스 기반 MES의 아키텍처 패턴

• 산업용 엣지 컴퓨팅

AWS의 IIOT 서비스 전반에서 엣지라는 용어는 산업 현장의 말단 기기를 의미한다. 이 섹션에서는 현장을 강조하는 의미로 사용된다. 첫 번째로 소개하는 패턴은 이러한 산업 현장에서 사용하는 아키텍처 패턴이며, 핵심 서비스는 AWS Outposts 이다. Outposts 는 AWS 서버를 현장에 제공하는 서비스이다. 물리적으로 AWS서버가 설치된 랙을 제공하거나, 현장의 랙에 장착할 수 있는 서버 컴퓨터를 제공한다. 지연시간에 대해 매우 민감하거나, 클라우드 대상 연결이 안정적이어야 할 경우 고려해 볼 수 있는 서비스이다.

문서에서 안내하는 대표적인 아키텍처이다. 위에서 언급한 것처럼, 현장에서 AWS Outposts를 활용해 AWS 서버를 현장에서 실행하고, 내부에서 RDS와 EKS를 이용하고 있는 것을 볼 수 있다. Outposts에서 이용할 수 있는 AWS 서비스는 한정되어 있으므로 주의해야 한다.

이렇게 수집된 데이터를 MSK 혹은 Api Gateway Enepoint를 통해 클라우드 서버와 동기화 할 수 있다. 수집된 데이터는 다른 서비스를 이용해서 프로세스 개선 보고 및 분석 등을 활용 할 수 있으며, 이를 다시 엣지 Outposts에 반영하여 제조 공정을 최적화 할 수 있다.

AWS MSK

언급된 MSK에 대해 간단히 알아보자. MSK는 Managed Streaming for Apache Kafka의 약자이다. MSK 는 기본적으로 메시지 큐 서비스이다. 이름에서 알 수 있듯이, Kafka를 AWS에 포팅한 서비스라고 보면 될 것 같다. Kafka 역시 다른 메시지 큐 시스템과 비슷하게 생산자, 소비자, 구독 주제 등의 구성 요소를 가지고 있다. 카프카는 사용해본 적 없으나, 메시지 큐 시스템은 사용해 봤으므로 비슷한 느낌으로 이해하면 될 듯 하다. 제조 현장 엣지에서는 대용량의 데이터가 발생하므로, 클라우드 서버와 연결이 필요 할 경우 적합한 서비스라고 볼 수 있을 것이다.

문서에서는 API Gateway 혹은 MSK를 사용할 것을 권장하고 있다. API Gateway의 경우 동기식으로, 클라우드 서버 측의 즉각적인 응답이 필요 한 경우 사용할 수 있다. 생산 제어를 클라우드 서버로 중앙화하여 결정하고 있다면 사용을 고려 할 수 있다.

MSK는 비동기식으로, 생산 제어를 엣지에서 결정하고 있을 때 사용을 고려 할 수 있을 것이다.

물론, 둘을 혼합하여 사용하는 것도 가능하다. 다음 내용은 다음 블로그 글에서 진행하도록 하자.

윈도우를 쓰던 시스템의 무려 64기가라는 램을 (38만원이라는 저렴한 가격에 구매한 ㅋ) 활용하기 위해 리눅스를 설치하면 된다는 간단한 아이디어를 지금에서야 떠올렸다. KVM을 활용해 바닐라 쿠버네티스 환경을 구축하는 시도를 하던 도중, 네트워크 설정을 하다가 STP를 보게 됐다. CCNA공부도 할 겸, 정리하고 넘어가고자 한다.

1. STP

STP는 스패닝 트리 프로토콜의 약자이다. 이 프로토콜은 스위치 구성 시 루프를 방지하기 위해 사용된다. 그렇다면 어떤 상황에서 루프가 발생하는지 알아보자.

가장 대표적인 상황은 브로드캐스트 스톰이다. 스위치 고장에 대비해 두 스위치 사이를 두 개의 케이블로 연결했다고 가정해 보자. 한쪽 PC에서 브로드캐스트 패킷을 보내면, 스위치는 브로드캐스트를 모든 포트로 플러딩 하게 되고, 패킷이 케이블 두 개를 돌면서 루프를 형성하게 된다.

STP는 이러한 문제가 발생할 때 논리적으로 하나의 프로토콜을 차단하여 루프를 방지하는 프로토콜이다.

2. 동작 원리

STP는 다음과 같은 순서로 동작한다.

1. Root Bridge 선출

네트워크에서 하나의 Root Bridge를 선출한다. Root Bridge는 가장 낮은 Bridge ID를 가진 스위치가 선출된다. Bridge ID 는 2바이트의 Priority와 6바이트의 맥주소로 이루어진다.

2. Root Port 선정

나머지 각 스위치는 하나의 Root Port 를 선정한다. Path Cost가 가장 낮은 포트를 선택한다.

3. Designated Port 선정

각 세그먼트마다 하나의 Designated Port를 선정한다. Designated Port는 Root Bridge로 가는 최단 경로를 제공하는 포트이다. 따라서 Root Bridge자체의 포트는 모두 Designated Port 이다.

3. BPDU

BPDU는 STP를 지원하는 스위치들 사이에서 교환되는 메시지이다. 이를 통해 네트워크 모니터링, 루프 상태를 점검한다. 2초 주기로 스위치 정보를 멀티캐스트 하여 교환하며, 상태 변화를 보고하고 스패닝트리 상태를 모니터링 한다. 포함되는 정보는 Root Bridge ID, 송신 스위치 ID, Path Cost등이며, 수신 대기시간인 20초 동안 유효하다.

이것도 학습이다.

집에서 블로그를 돌리고 있던 미니PC에서 도커를 다루고 있었는데, 용량 문제가 발생했다. 그래서, 중간 과정을 생략하고 블로그에 적었던 내용들이 모두 날아갔다. 원인을 천천히 살펴보자.

1. 로컬 백업을 하지 않았다.
2. 클라우드 백업도 하지 않았다.
3. 민감한 작업을 함에 있어 너무 안일했다.
4. AI를 너무 신뢰하였다.

사실 꼽다보면 더 많은 문제가 있을 것이다. 하지만 이런 문제를 방지할 수 있는 가장 확실한 방법은 역시 백업일 것이다. 작년 연말에 클라우드 백업도 고려 했었는데, 귀찮음과 비용의 문제로 실행하지 않았다. 그래봐야 로컬에서 날아갈 일이 뭐 있겠냐 하고.. 또 자격증을 따느라 적을만한 것이 없어서 관심이 다소 멀어졌던게 이유였다.

다시 하나씩 적어봐야지 뭐 별 수 있겠나? 같은 실수를 두 번 하지 않으면 되는것이다.