흐르는 시간의 블로그...

업무와 관련하여 한국리전에 있는 EC2를 도쿄리전에 설치하였다.

보안 그룹을 설정하고 기본적인 설치를 완료하였다.

문제는 ftp를 설치하는데서 발생했다.


#문제1

vsftpd를 yum으로 install 하였다.

로컬에서는 정상 접속이 되나 외부에서는 절대 접근이 되질 않았다.

ec2의 보안 그룹을 열심히 수정하였으나 여전히 접근 불가!

다른 회의에 잠깐 다녀와서 머리를 식혀보고 혹시나 싶어서 iptables를 봤다.

다른 EC2를 그대로 떠온것이라 그곳의 iptables가 심어져 있었다.

이것을 고쳐서 일단 외부 접근 성공!!!


#문제2

접속을 하였으나 디렉토리가 보이질 않는다.

다음과 같은 메시지와 함께... 

226 Transfer done (but failed to open directory).

관련하여 찾아보니 결국...

SeLinux가 on   되어 있을 경우에 발생한다.

디렉토리 이동의 경우는 문제가 없다.

[]# getenforce

Enforcing

[]# setenforce 0

[]# getenforce

Permissive

나중을 위해 전체 설정을 변경할 수도 있다

/etc/selinux/config 파일의 설정도 이후 Disabled 상태로 변경


# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

#     enforcing - SELinux security policy is enforced.

#     permissive - SELinux prints warnings instead of enforcing.

#     disabled - No SELinux policy is loaded.

SELINUX=disabled


문제2의 답은 ftp 접속 시 226 Transfer done (but failed to open directory). 에러 발생 에서 찾았다


현재 보고 있는 "아마존 웹 서비스를 다루는 기술"이란 책에서 PV가 HVM보다 성능이 낫다고 설명하고 있다.

반면 최근의 커뮤니티의 답글을 보면 HVM이 더 낫다고 말하고 있고 무엇보다 AWS AMI에서 PV는 거의 사라지고 없다.

책의 내용을 읽고 PV인 AMI를 찾아봤지만 거의 없었다.

궁금하여 찾아보니 아래와 같은 블로그를 발견했다.

AWS에서의 PV와 HVM


결론은 HVM으로 가는 추세이다.

위 블로그 내의 참고 링크는 아래와 같다.

AWS in 2015: Why You Need to Switch from PV to HVM

Slide share 에서 AWS 아키텍트에 대한 강좌


Source: AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안


요약

마이크로 서비스

정의: 위키피디아 - 작응 빌딩 블록, 높은 비결합성, 디자인 스타일, 작은 작업을 수행, 모듈식의 접근


Monolithic vs SOA vs Microservices


Microservices - API를 사용하여 연결


Monolithic

  • 복잡한 코드와 관리의 어려움
  • Bottleneck이 될 수 있는 배포
  • 변경의 두려움
  • 부족한 주인의식
  • 연쇄 실패
  • 확장의 어려움


마이크로 서비스로 얻을 수 있는 것들

  • 서로 다른 언어로 개발 가능
  • 쉽게 이해하고 수정 가능한 코드들 - 새로운 팀원의 생산성 향상
  • 최근 기술을 비교적 쉽게 도입
  • 빠른 서비스 시작 속도와 배포 속도


잦은 오해

  • 다양한 기술과 신기술을 쓴다고 마이크로서비스는 아니다


조직 구조가 그대로 시스템의 구조로 나타난다 - 아키텍처와 팀조직은 긴밀하게 연결되어 있다


Amazon EC2 Container Service

  • 유연한 컨테이너 배치
  • AWS와 함께 사용되도록 설계
  • 크기 상관 없는 클러스터 관리


ECS와 Route53


Weaveworks - Router/DNS

  • 각각의 컨테이너간 관계 표시


Blue-Green 배포





Slide share 에서 AWS 아키텍트에 대한 강좌


Source:고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced


요약

디자인 원칙

  1. 추정을 하지 마십시오
  2. 프러덕션 시스템과 동일한 테스트 시스템을 구축하십시오
  3. 아키텍트 변경에 대한 위험을 낮추십시오
  4. 아키텍처에 대한 변경과 실험을 자동화 하십시오 - AWS CloudTrail / Config
  5. 지속적으로 아키텍처를 개선하십시오

Well Architected 프레임워크 4개지
  1. 보안(Security)
    • 모든 영역에 보안 적용
    • 추적 로그 수집
    • 보안 이벤트 대처 자동화
    • 보안에 대한 best practice 자동화
  2. 안정성(Reliability)
  3. 성능 효율화(Performance Efficiency)
  4. 비용 최적화(Cost Optimization)


보안 영역

  • 데이터 보호
  • 권한 관리
  • 인프라 보호
  • 감시 제어


보안 권장

  • IAM 계정을 생성해서 권한관리를 하라
  • MFA를 적용하라

로그 종류
  • OS/App logs
  • VPC Flow logs - 방화벽 로그
  • AWS CloudTrail
  • ELB


안정성

  • 복구 절차 테스트
  • 문제 발생시 자동 복구 구성
  • 수평 확장으로 시스템 가용성을 높여라
  • 필요한 용량을 추측하지 말라

  • 하나의 리전에서 EC2 인스턴스는 초기 20개까지만 허용된다
  • limit 해제 request를 할 수 있다


  • Auto-Healing - Auto Scaling을 auto healing으로 할 수 있다(min-max를 1로 하여 하나만 운영할 수 있다)
  • EC2 Auto recovery - EC2 인스턴스 하나에 cloud watch에서 이벤트를 걸어 운영할 수 있다


성능 효율화

  • 최신 기술을 쉽게 사용하라 - 최신 타입 인스턴스
  • 여러 리전에 서비스를 배포
  • 서버리스 아키텍쳐 구성하라
  • 더 자주 새로운 아이디어 실험

성능 효율화 영역 - 정의
  • 컴퓨터
  • 스토리지
  • 데이터베이스
  • 용량-시간의 Trade-off

데이터베이스 성능 모니터링
  • Alarm Based Notification
  • Trigger Based Actions
  • CloudWatch

비용 최적화
  • 비용을 업무/부서별로 투명하게 - 태그 사용
  • 관리 서비스 이용
  • CAPEX를 OPEX로 전환
  • 규모의 경제를 통한 혜택

비용 최적화 정의
  • 필요한 만큼만 사용
  • 비용 효율적인 자원
  • 비용 인지
  • 지속적인 최적화

비용 모니터링
  • Cost Explorer
  • CloudWatch Alerts
  • CloudWatch Monitoring
  • Tagging

  • Spot Instance
  • Reserved Instance (RI)

  • AWS 보안 credential이 애플리케이션 소스코드에 하드코딩 하면 안된다

Trusted Advisor 사용 필요


애플리케이션 디자인 원칙

  • 장애를 대비한 아키텍처 디자인 하십시오
  • 느슨한 결합 구조의 아키텍처가 여러분을 자유롭게 합니다
  • 탄력적인 아키텍처를 구현하십시오
  • 모든 계층에서 보안을 구축하십시오
  • 제약조건을 두려워 마십시오
  • 병렬적으로 생각하십시오
  • 다양한 스토리지 옵션을 고려하십시오