일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- javax.mail
- apache 와 tomcat 연동
- mod_proxy_ajp
- eclipse query validate
- AWS
- JavaScript
- jQuery
- 펀드
- 재태크
- iText
- 원격 제어
- 플러그인
- 중복 로그인
- mod_jk
- org.apache.commons.net.ftp
- eclipse jquery
- 이클립스
- defaultContext
- apache
- WTP
- AWS Architecture
- HelloWorld
- Amazon Web Service
- tomcat
- Divx 플레이어
- AWS Web Console
- Today
- Total
목록Study/Amazon Web Service (4)
비얌
AWS Web Console 작업 없이 개인 PC 혹은 IDC Linux 장비에서 AWS 제어하기 들어가면서 AWS는 기본적으로 Command Line으로 모든 것을 처리할 수 있습니다. 실제로 AWS가 오픈할 2006년 당시 Web에서 서버를 할당 받는 작업만을 수행하고 실제로는 Terminal에서 모든 작업을 하였습니다. 그러던 시스템이 이제 사용자가 많아지고 제공되는 서비스가 많아지면서 Web Console에서 몇 번의 Click으로 작업을 처리할 수 있게 되었습니다. [AWS Web Console] (참~ 많은 것을 하게 되었지요...만약에 잘 쓰면 개인 IDC 구축은 일도 아닐 듯...) 문제는 Web Console에서 제공되어지지만 내 맘데로 움직이려면 제약이 있습니다. 가령 AMI(흔하게 쓰..
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 도입 여부 결정하여 서버별 접..
요근래에 Amazon Web Service를 사용하고자 하는 국내 기업들이 많다. 하지만 실제로 런칭한 서비스는 손에 꼽을 정도 이다. (자세하게 얘기하고 싶지만 Amazon 관계자도 쉬쉬 하는 내용이니깐....) 그런데 AWS를 꼭 써야만 하는지에 대해서 깊게 생각하지 않고 "걍 외국에서 쓰고 있고 좋은 걸꺼야" 라는 기류에 편승해 쓰려고 하는 것이 아닐까라는 생각이 강하게 든다. (꼭 EJB 같다...) 아는 컨설턴트의 얘기를 빌리면 국내 유수의 기업에서도 도입을 검토했다가 비용 및 구조에 좌절해서 포기하는 경우가 있다고 한다. 따라서 윗분(?)들의 생각은 조만간에 고착화 될 것 같다...두가지로.. 1. 외국에서 쓰니 우리도 글로벌을 위해 쓰자. 2. 그거 어차피 거품이다. 쓸모가 없으니 쓰지 말자..