
오늘도 AWS ecs 서비스를 가지고 여러 테스트를 진행해보고 있는 와중에, Linux scp 명령어를 사용하여 file을 서버에 올리려 했습니다.
이 때 scp를 왜 사용하게 되었는지, 다른 전송방식은 없는지 궁금증이 생겨 공부해보았습니다.
internet 초창기, 사람들은 server에 file을 올려야 했습니다. 그때 사용했단 file transfer 방식이 FTP 였습니다.
하지만, 이 방식에는 치명적인 문제가 있었는데 바로,
파일도, 비밀번호도 전부 암호화 없이 그냥 전송되었다는 겁니다.
따라서 네트워크를 지나는 데이터를 누군가 Packet Snigging, interception, MITM 방식으로 공격할 수 있다는 단점이 있었습니다.
이러한 문제를 해결하기 위해 암호화된 원격 접속이 가능하도록 하는 SSH가 개발되었습니다.
[내 컴퓨터] ──── 암호화된 터널 ────▶ [서버]
(SSH)
ssh 방식을 도입하여 서버에 안전하게 접속할 수 있게 되었습니다. 하지만, 파일 전송 system은 여전히 FTP 방식을 사용했어야 했었습니다.
그래서 엔지니어들은 SCP를 개발하게 되었다고 합니다.
이 방식은 이 관점으로 만들어진 기술이라고 합니다.
SSH 터널이 안전하게 사용되고 있기 때문에 이 SSH 통로로 file도 보내보자.
[내 컴퓨터] ──────────────── SSH 터널 ────────────────────────────────────▶ [서버]
(SCP는 이 터널로 파일을 밀어넣음)
덕분에 file transfer도 암호화가 되었고, 오래동안 표준이 되었습니다.
SCP가 표준으로 사용되다, AWS와 같은 클라우드가 등장했습니다.
이때 서버를 사용하는 방식은 완전히 변경되었는데,
예전에는 서버 1대 -> 평생 운영
클라우드 시대 -> Auto Scaling으로 변동가능
이러한 방식으로 변경되면서 SCP의 한계가 발생하였습니다.
"EC2가 10대면... scp를 활용하여 수동으로 파일을 10번 따로 upload 해야 하나?"
"Auto Scaling으로 갑자기 생긴 EC2에 서버 관리자가 file을 바로 올릴 수 있는가?"
"새로 생긴 EC2의 IP를 어떻게 알 수 있는가?"
따라서 Cloud 시대 엔지니어들은 EC2에게 SCP로 직접 upload하지 않고, S3 Bucket를 이용한 Ataging Area생성을 통해 EC2가 자동으로 데이터를 가져갈 후 있게 아키텍팅 한다고 합니다.
[내 컴퓨터] ──▶ [S3 Staging Area] ◀──── [EC2_A]
◀──── [EC2_B] (Auto Scaling으로 새로 생긴 애들도
◀──── [EC2_C] 알아서 S3에서 꺼내감)
FTP (암호화 없음)
↓ "보안 필요"
SSH (암호화 접속)
↓ "파일 전송에 대한 보안 필요"
SCP (SSH 터널로 파일 전송)
↓ "Auto Scaling 문제 발생"
S3 스테이징 등장 (중간 창고 방식)