티스토리 툴바


AWS에서 Architecture를 설계하고자 한다면 다음을 생각하자.

1. 중앙집중식 Framework 설계에서 기능 중심형 Framework 설계로 

2. JAVA Framework 만이 아닌 기능의 복잡성 혹은 Transaction의 중요도에 따라서 다양한 언어 Framework 적용

3. 기능 중심의 서버 배치

4. Data 동기화 대상 선별 및 해당 Data 동기화 Time 결정 (실시간, 스케쥴링)

5. Region 별 기능별 서버 spec 결정 (일별 사용자 최대치가 아닌 일별 평균치에서 10%~20%로 산정하되 Auto Scale-out 방안 결정)

6. Scale-up Region별 사용률 모니터링에 따라 순차 적용 (Auto 적용 불가)

7. Geo DNS 도입 여부 결정하여 서버별 접근 방식 결정

8. 리소스 공유에 대한 latency of Response를 줄여나가는 설계

9. 기능 서버간 약결합으로 구성하여 일부 시스템 Fail시 서비스 장애 최소화

10. 기능 서버 Fail시 동일 기능 서버로 Fail Over 시스템 구축

11. UCC Data에 대한 네트워크 접근 방안 결정

12. 서비스 배포 방안 수립 (기존의 전체 서버에 일괄 배포 방식이 아닌 기능 서버별 배포 방안 수립)

13. 통계 Data에 대하여 기획 시, 수립하여 Data에 대한 통합 DB 구축 여부 결정


고민하자.....
위에 것만 고민하면 비용 절감은 부수적으로 따라 온다. 


크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 비얌
요근래에 Amazon Web Service를 사용하고자 하는 국내 기업들이 많다.

하지만 실제로 런칭한 서비스는 손에 꼽을 정도 이다.
(자세하게 얘기하고 싶지만 Amazon 관계자도 쉬쉬 하는 내용이니깐....)

그런데 AWS를 꼭 써야만 하는지에 대해서 깊게 생각하지 않고
"걍 외국에서 쓰고 있고 좋은 걸꺼야" 라는 기류에 편승해 쓰려고 하는 것이
아닐까라는 생각이 강하게 든다.
(꼭 EJB 같다...)

아는 컨설턴트의 얘기를 빌리면 국내 유수의 기업에서도 도입을 검토했다가
비용 및 구조에 좌절해서 포기하는 경우가 있다고 한다.

따라서 윗분(?)들의 생각은 조만간에 고착화 될 것 같다...두가지로..
1. 외국에서 쓰니 우리도 글로벌을 위해 쓰자.
2. 그거 어차피 거품이다. 쓸모가 없으니 쓰지 말자. 

이번 포스팅에서는 AWS 사용 시, 아키텍처적인 관점으로 지극히 개인적인
의견으로 말을 해보겠다.
 
사실 국내나 외국이나 클라우드에 대한 정확한 접근을 하지 않는 것 같다.
물론 클라우드라는 의미가 너무 진화하고 있는 것 같다..아마 누군가는 새로운
용어를 만들어 내지 않을까?

서버 아키텍처를 설계하다 보면 항상 생각하는 것이 비용이다.
서버가 무한한 자원이 있으면 좋겠지만 서버가 돈이다 보니 비용에 맞게 그리고
사용될 서비스에 대한 예상치를 가지고 서버의 스펙을 결정하게 된다.
(꼭 이 때, 고객사의 꿈 꾸는 예상치에 맞게 서버 스펙을 결정해서 주면 뭐가 비싸냐고
비용을 깎아달라고 하는 사람도 있다...서버가 고등어인가...)

내가 생각하는 AWS는 Web Service에 정말 잘 맞게 IDC를 빌려주는 서비스가
아닐까라는 생각을 한다....

윗분들이 AWS를 검토할 때 제일 먼저 얘기하는게 비용이다.
비용... 비용은 정말 가변적이다....하지만 트레픽 비용은 싸다....
그것도 엄청나게...비쌀 것 같지만...싸다....거기다 상면 비용도 없다.
그러나 서버 가격은 비싸다. 아주 비싸다.(여기서 내가 하고 싶은 이야기가 있다.)
서버 스펙을 결정할 때, 서버는 넣었다가 뺐다가 할 수 없으니 예상치를 두고
3년 목표치에 맞게 지금은 30%로 산정, 3년 뒤에는 80% 사용을 두고 예측하고
넣다보니 이 개념을 그대로 AWS에서 스펙을 잡으면....
"뭐야 비싸잖아~"
라고 얘기 듣는 것이 흔하다. 

웃기지 않은가.
그네들의 시스템은 모두 가상O/S를 넣어서 기존 유휴 서버를 재배치하여
O/S로 나누어 주면서 IDC 자원을 관리 하면서 AWS는 실서버 사듯이 계산을 하니...

나는 AWS를 가상O/S를 할당해 주는 IDC로 보았다.
단 우리가 알고 있는 IDC센터의 한 업체가 상면을 할당받는 것이 아니라....
IDC 센터 통째로 할당 받았다고 그것도 전 세계에 15여개가 넘는 IDC센터를 통째로 ...

그리고 서버의 스펙 산정은 지금 당장 필요한 급으로 산정하고자 했다.
신규 런칭이라면....정말 작은 것으로.....
하지만 인프라의 의견은 달랐다. 아마 그 서버로 트래픽을 감당 못하면 어떻게 되냐는..
말은 안했지만 책임 지겠냐고....

하지만 AWS는 웃낀 서비스를 제공한다...
Scale up, down, out, in 이다....

이 개념은 기존의 아키텍처라면 접근하기 어렵다..
왜냐하면 단순히 서버의 대수가 늘어나거나 스펙이 올라 간다는 것은...
의미가 없다...
물론 받을 수 있는 트래픽이나 가용성이 높아지지만
정말 그정도가 필요해서 늘어나는거냐는 것은 인프라 적인 측면으로만 접근하면 안된다.
즉 Framework 까지 감안이 되어야 한다...
그리고 비즈니스 로직까지 감안이 되어야 한다...
그러다 보니 이 전부를 볼 수 있는 아키텍처는 없다고 본다..

AWS를 꼭 써야만 하는가.....
그것도 비용을 줄이면서.....
꼭 써야만 하지는 않는다.

하지만
1.회사에 비용이 많이 있지 않다.
2.신규로 서비스를 하는데 성공할지 모르겠다
AWS는 써볼만 하다.

단 AWS의 구조와 그들의 비용 체계, 서비스에 대한 Framework 재배치를 할 수
있다면이다....

내가 Java 프로그래머다 보니....
만약 위 조건에 대해서 간단한 단어로 표현한다면...
객체지향적인 서버 아키텍처 라고나 할까.. 
(OOSA라고 해야 하나? Object Oriented Server Architecture ㅋㅋㅋㅋ)

그러면 정말 성공적인 AWS Architecture를 어떻게 설계해야할까는...
다음글로....
(사실 지극히 개인적인 Architecture다...) 
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 비얌
Amazon Web Service 준비물

1. Amazon 계정
2. 해외 결재 가능 신용카드(VISA, Master, ....)
3. 연락 받을 수 있는 전화기

위 사항들만 있으면 Amazon Web Service를 할 수 있다.

자세한 것은 ......
다음 기회에...... 
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 비얌