엔터프라이즈급 기업일수록 클라우드 운영 측면에서 여러가지 요구사항이 생긴다. 예를들어 시스템이 각종 법률과 산업 표준을 준수해야하며, 시스템을 한곳에서 관리할 수 있어야하며, 통합 모니터링이 지원되어야 하며, 비용은 효율적으로 사용되어야 한다. 하지만 관리 및 관제는 agility와 상충되는 개념으로 관리 및 관제가 증가하면 agility는 낮아지고, agility를 높이면 관리 및 관제에 소홀해지게 된다. AWS에서는 클라우드 운영 관리를 위한 다양한 서비스를 제공하고 있기 사용자는 때문에 관리 및 관제 + agility를 둘다 가져갈 수 있다. 관리 및 관제 측면의 서비스로는 Control Tower, Organizations, Budgets, License Manager, Well-Architect..
국내 통신 3사의 차세대 메시징 서비스로 삼성전자와 협업하여 RCS(Rich Communicatoin Service)라는 서비스를 제공하고 있다고 한다. 해당 서비스는 VM기반의 아키텍처에서 EKS기반으로 변경되었다고 운영이 더 쉬워지고, 비용이 절감 되었다는 등 우리가 일반적으로 알고있는 클라우드 전환의 장점을 이야기했다. (앞쪽에는 별 내용이 없었다...) 뒤 쪽에서는 로그 수집 아키텍처에 대해서는 관심있게 보았다. EKS로 전환하면서 좀 더 효율적인 로그처리를 위해 로그 수집 아키텍처도 변경했는데, 중요한 비즈니스 로그의 경우 internal Micro Services => fluentd => Amazon Kinesis -> S3 상대적으로 덜 중요한 디버그 로그의 경우 internal Micro ..

Compute Engine을 당분간 사용하지 않을 예정이라 요금이 부과되지 않도록 멈춰둘 생각이다. suspend와 stop의 차이점이 무엇일까? 1. suspend(일시정지) 노트북 덮개를 닫는것과 비슷하다. 게스트os메모리, 애플리케이션 상태, 머신 상태를 유지한다. 인스턴스 메모리를 유지하기위한 저장공간에 대한 요금이 부과된다. (인스턴스를 일시정지하면 메모리가 스토리지로 이동되고 인스턴스가 보존됩니다. 인스턴스가 일시정지된 상태에서는 사용 중인 스토리지에 대해서만 비용이 청구됩니다. ) 최대 60일까지 인스턴스를 일시정지할 수 있습니다. 60일이 지나면 인스턴스가 자동으로 TERMINATED 상태로 전환합니다. 2. stop(종료) 인스턴스를 재개할 때 인스턴스의 메모리와 기기 상태를 복원할 필요..