ftp 접속 시 226 Transfer done (but failed to open directory). 에러 발생
업무와 관련하여 한국리전에 있는 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). 에러 발생 에서 찾았다
'프로그래밍??? > AWS' 카테고리의 다른 글
| HVM vs PV 성능차이 (0) | 2017.12.26 |
|---|---|
| AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 (0) | 2017.09.28 |
| 고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced (0) | 2017.09.27 |
| AWS EC2를 다른 리전으로 이전하기 (0) | 2017.08.29 |
| AWS SDK for C++/Go and S3 upload time check (0) | 2017.05.29 |
HVM vs PV 성능차이
현재 보고 있는 "아마존 웹 서비스를 다루는 기술"이란 책에서 PV가 HVM보다 성능이 낫다고 설명하고 있다.
반면 최근의 커뮤니티의 답글을 보면 HVM이 더 낫다고 말하고 있고 무엇보다 AWS AMI에서 PV는 거의 사라지고 없다.
책의 내용을 읽고 PV인 AMI를 찾아봤지만 거의 없었다.
궁금하여 찾아보니 아래와 같은 블로그를 발견했다.
결론은 HVM으로 가는 추세이다.
위 블로그 내의 참고 링크는 아래와 같다.
'프로그래밍??? > AWS' 카테고리의 다른 글
| ftp 접속 시 226 Transfer done (but failed to open directory). 에러 발생 (0) | 2018.08.28 |
|---|---|
| AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 (0) | 2017.09.28 |
| 고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced (0) | 2017.09.27 |
| AWS EC2를 다른 리전으로 이전하기 (0) | 2017.08.29 |
| AWS SDK for C++/Go and S3 upload time check (0) | 2017.05.29 |
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안
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 배포
'프로그래밍??? > AWS' 카테고리의 다른 글
| ftp 접속 시 226 Transfer done (but failed to open directory). 에러 발생 (0) | 2018.08.28 |
|---|---|
| HVM vs PV 성능차이 (0) | 2017.12.26 |
| 고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced (0) | 2017.09.27 |
| AWS EC2를 다른 리전으로 이전하기 (0) | 2017.08.29 |
| AWS SDK for C++/Go and S3 upload time check (0) | 2017.05.29 |
고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced
Slide share 에서 AWS 아키텍트에 대한 강좌
Source:고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced
요약
디자인 원칙
- 추정을 하지 마십시오
- 프러덕션 시스템과 동일한 테스트 시스템을 구축하십시오
- 아키텍트 변경에 대한 위험을 낮추십시오
- 아키텍처에 대한 변경과 실험을 자동화 하십시오 - AWS CloudTrail / Config
- 지속적으로 아키텍처를 개선하십시오
- 보안(Security)
- 모든 영역에 보안 적용
- 추적 로그 수집
- 보안 이벤트 대처 자동화
- 보안에 대한 best practice 자동화
- 안정성(Reliability)
- 성능 효율화(Performance Efficiency)
- 비용 최적화(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이 애플리케이션 소스코드에 하드코딩 하면 안된다
애플리케이션 디자인 원칙
- 장애를 대비한 아키텍처 디자인 하십시오
- 느슨한 결합 구조의 아키텍처가 여러분을 자유롭게 합니다
- 탄력적인 아키텍처를 구현하십시오
- 모든 계층에서 보안을 구축하십시오
- 제약조건을 두려워 마십시오
- 병렬적으로 생각하십시오
- 다양한 스토리지 옵션을 고려하십시오
'프로그래밍??? > AWS' 카테고리의 다른 글
| HVM vs PV 성능차이 (0) | 2017.12.26 |
|---|---|
| AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 (0) | 2017.09.28 |
| AWS EC2를 다른 리전으로 이전하기 (0) | 2017.08.29 |
| AWS SDK for C++/Go and S3 upload time check (0) | 2017.05.29 |
| Amazon S3 REST API (0) | 2017.05.11 |
