Moving to AWS

  • #3719671
    아마존 68.***.172.146 1171

    최근에 회사가 파이프라인을 모두 AWS로 옮기기로 결정을 했습니다. 클리닉쪽 회사입니다. 요즘엔 AWS로 가는게 대세이긴 한데, 제 경험상 HPC에 시스템을 (데이터 베이스 포함) AWS로 옮기는거 쉽지 않던데……..생각보다 너무나 다른 시스템이고 시간도 많이 걸리고 돈도 많이 들던데. 문제는 뭔지도 모르는 인간들은 그냥 있는거 들어다가 AWS에 깔면 돌아가는줄 압니다. 게다가 그러면 돈도 무지하게 세이브가 되는지 압니다. 하…..답답. 아무리 설명을 해줘도 그들에 머리는 아주 단순. 그렇게 단순하면 AWS engineer 는 왜 있냐고. 올해까지 다 하자고 합니다…..돌겠네. 회사에는 AWS제대로 아는 사람도 없어서 지금부터 뽑아야합니다……크. AWS로 다 옮긴 경험있는분 어떤식으로 진행을 합니까?

    • 74.***.155.53

      여기서 어떻게 하냐고 하면 간단하게 이렇게 하면 된다고 설명이 되는게 아닙니다.

      그리고 본인은 왜 자꾸 회사 돈 아끼는걸 걱정하는건지는 모르지만 이런 기회에 AWS 배워보고 진행해나가는거 아주 좋다고 봅니다. 무조건 달려들어서 배우세요. 나중에 엄청 도움될겁니다.

      본인은 오히려 회사에 땡큐하고 배우면 되는겁니다.

      그리고 추가 답변을 보니 한번 AWS로 가면 못돌아오는 걱정을 하는데 … 클아우드쪽 웨비나나 테크니컬 세션 가보는거 추천합니다. 여러가지 방법들이 있고 많은 회사들이 같은 이유로 몇가지 다른 클라우드 서비스도 같이 도입합니다.

      아무리봐도 좋은 기회인데 상당히 꺼리는듯하네요.

    • 아마존 68.***.172.146

      제가 사람을 뽑아서 프로첵트를 진행을 해야되는 상황이라 그 진행에 과정을 물어본 것입니다. 기술적인 부분은 당연히 저도 배워가면서 해야되고 배우는 기회는 맞습니다. 회사에 돈을 절약하는것을 걱정하는것이 아니라 (실제로 AWS 비쌉니다. 시간당 사용료로 보면 절약같지만 실제로는 더 비쌀 수도 있어요. 게다가 한번 AWS 로 가면 다시 돌아오지도 못하고) 제가 말도안되는 회사에 타임라인을 걱정하는 겁니다. 뭐 별수 있나요 해봐야죠…..근데 올해내로는 택도 없을것 같습니다.

      • 노땅 72.***.167.222

        1. 일단 돈 걱정은 하지 말고
        2. 타임라인은 당신 매니져나 직속상관하고 상의하도록

    • CT 67.***.113.51

      궁금한데 회사에 CTO 가 있나요? 아님 CTO 가 결정내린건가요. 상당히 중요한 결정 (전 시스템을 옮기고 한 번 가면 다시 돌아오기 힘든)을 내리는 미팅에 참석하신 글쓴이분은 어떤 직급인지 궁금해요!

    • ss2 174.***.2.154

      이런거 계산해보는 툴도 있지 않나요?

      기본적으론 호스팅서비스나 로컬서버를 사용중이시면, 현 서버 비용 vs 클라우드 예상 비용/서비스 안정성 등을 비교하면서 보여주는게 빠를것 같네요.
      뭐, 미전역에 서비스중이고 지역마다 호스팅서버를 돌리고 있다. 같은 식의 환경이면 클라우드가 저렴할 확률이 높고….
      한곳에 서버실을 운영중이거나 특정 호스팅업체를 사용한다 싶으면 클라우드 서비스가 안정성이 높을 확률이 있습니다.
      (저희도 처음에 바꾼건 호스팅 서비스가 낮시간에 2-3시간 먹통이 되고나서 고객들한테 항의가 엄청 오고나서였거든요)

      하지만, 좀 쓸데없는 일이다 같으시면, 비용이랑, 신규 인원(서버팀 인원 증원이 필요하다면)이나 개발범위(DB등이 클라우드 서비스로 변환이 필요하다면)도 뽑아서 제시해보세요

      클라우드 서비스가 사실 옵션이 무궁무진합니다.
      그냥 호스팅서비스에서 클라우드로 이전만 한다…싶으면 EC2를 사용하시면 호스팅이랑 똑같은 형태로 쓰실수도 있습니다.
      혹은 서버가 돌긴하지만, 사용량이 많지 않으면 lamdba같은 호출시에만 응답해주는 서비스로 돌리면 사용량이 저렴해질수도 있구요.
      혹은 대형 서비스를 안정적으로 돌리려면 region 마다 몇개의 kubernetes pods를 autoscaling 으로 병렬화 할수 있습니다.

      그렇게 서비스가 복잡해지다보니, AWS내 스크립트를 지원해주는 3rd파티 툴들까지 쓰더라구요.(terraform이나 helm같은…)

      그리고 서비스를 어떻게 구성하느냐에 따라 비용을 절약할수도 있고, 권한설정이다뭐다 관리것도 많아지는거 생각하면, 전담 관리인원도 있는 편이 좋습니다.

    • Aws 47.***.30.103

      1. AWS 기본적인 것을 생성합니다 Oragination, Control Tower, Config, Service catelog
      2. transit gate 또는 VPN으르이용해서 회사 테이트 센트와 Aws 르르얀걀합니다
      3. Application migration 을 시작합니다

      Identity access management, security control, observiality 등 초기에 미리 보안팀과 상의해서 설정해야 되요.

      회사 크기는 모륵겠지만 최소 3년은 걸립니다

    • 노땅 72.***.167.222

      댓글들이 좋구나 ㅎㅎ

    • 저도동감 98.***.32.143

      저도 동감합니다. 저는 유럽에서 메디칼 데이터를 클라우드에 업로드와 프로세싱 하는것을 법적으로 그지했기때문에, HPC와 크라우드 버전을 따로 만들어서 공급했습니다. HPC에서 크라우드로 옮기면 파이프라인을 다시 설계하고 implement를 해야합니다. 클라우드에서 HPC를 구현할 수 있지만, 가격이 장난이 아닙니다. 오브젝스토리가 싸다고 아주 선전을 해서 팔아먹고 있지만. 클라우드 환경에서 오브젝스토리지 만을 쓸수만 없죠. 그 맘을 잘 이해합니다. 한 발짝 물러나 있으세요.

    • 저도동감 98.***.32.143

      그리고 aws 솔루션아키택쳐의 문제점은 아마존 제품은 잘 알고 있지만 도메인 지식이 없어서, 기존의 파이프 라인이 산으로 갈 수 있습니다. 도메인 지식을 가지고 있는 사람응 잘 뽑아애 할 것 같네요

    • 저도동감 98.***.32.143

      마지막으로 클라우드는 웹프로젝트 또는 마이크로 서비스, 그리고 잠간 돌리는 어플같은것에 적합하지, 파이프라인이나 매일 하루종일 돌리는 어플에는 아닌것 같음.