RailsConf2007 첫째날입니다. 내일부터가 본격적인 시작이고, 오늘은 가벼운 튜토리얼세션으로 워밍업하는 날인데도, 열기는 대단했습니다. 내일부터는 정말 붐비겠네요.
오늘은 본격적인 시작에 앞서, 오전/오후로 나누어 튜토리얼 몇개가 준비되어 있었는데요, 저는 오전에는 Scaling Rails Application from the Bottom Up을 듣고, 오후에는 Rails Routing Round Up을 들었습니다.
먼저 오전의 Scaling Rails Application from the Bottom Up 튜토리얼은, Joyent사의 CTO인 Jason Hoffman의 레일스 애플리케이션의 성능과 확장성에 대한 강의식 세션이었구요, 튜토리얼이라고 보기는 어려운 형식으로 꽤 흥미로운 내용을 심도 깊게 얘기해 주었습니다.
50분씩 3시간으로 나누어 진행했으며, 처음 두시간은 일반적인 성능과 확장성에 대한 접근방법을 넓은 시각으로 비추어 주었고, 마지막 한시간만이 레일스 관련한 확장성에 대한 설명시간이었습니다.
전체적으로는
라는 질문에 대한 답변과 보충 설명의 시간이었다고 볼 수 있습니다. 그 답변에 대해 우선은
라는 반문으로 문제를 풀어나갔는데요, 전체 시스템관리자의 관점으로 바라볼 때, 성능과 확장성에 관련한 구성요소가 어떤 것들이 있는지 슬라이드 한장에 작은글씨로 가득 채워 놓고는 그 중에 레일스가 차지하는 부분을 표시해서 그 비율이 얼마나 적은지를 보여주었습니다. 개발자 관점으로만 좁게 바라보다보니, 마치 레일스로 바뀌는 것이 대단한 차이가 있는 것처럼 생각되지만, 사실 전체적으로 중요한 부분은 한 두개가 아니구나하는 것을 일깨워준 슬라이드였습니다.
확장성의 의미에 대해서는 레고블럭에 비유하며, 어떤 시스템이 확장성 좋은 시스템인지를 설명했습니다. 레고블럭의 경우 하나에 한블럭 더 꽂으면 딱 2배 길이가 되고, 하나 더 꽂으면 3배 길이가 되고, 다시 한개 줄이면 2개 길이가 되는등, 늘이고 줄이는 만큼의 결과차이를 그대로 보인다는 점에서 확장성이 뛰어나다라고 하는 비유였는데요, 막연히 여러대의 서버로 늘여서 성능 높이는게 확장성이 아니다라는 점을 강조했습니다.
성능과 확정성의 기본적인 제약사항으로는, 자금, 시간, 인력, 경험, 전력, 네트워크 bandwidth를 언급했습니다. 레일스가 그 확장성의 제약사항이 아니라는 점을 은연중에 강조했다고 볼 수 있는데, 전력의 경우는 저는 미처 생각치 못한 내용이었습니다. 실제로 1년에 전체 서버비용의 30%정도의 큰 금액이 전력비용으로 소비되고, 전력이 결국 사용할 수 있는 CPU와 메모리를 제한하기 때문에 큰 제약사항일 수 있다고 했습니다. 이 부분에서 각종 전원플러그들을 잔뜩 찍어놓은 사진을 보여주면서 어떤게 전력손실이 적고 좋다를 설명하는거 같았는데, 저런거까지 신경써야하는구나 싶더군요. 전력 문제는, 대규모IT기업이 IDC센터를 지을 때, 전력비가 몇 센트라도 싼 지역에 짓는다는 사례를 들며 강조했습니다.
서비스 성능과 확장성에 레일스가 제약사항이 아니라는 점을 강조하면서, 그렇다면 레일스의 강점은 무엇일까하는 궁금점에 대한 답변으로는,
라는 장점을 얘기했습니다. 저는 레일스로 개발하면 편하고 빠르고 재미있다(!)라는 장점을 크게 보는데, Jason씨의 강점 언급이 보다 프로다운 것이 될 수 있겠네요.
다시 확장성으로 돌아와서, 확장성의 목표는 컴퓨팅 파워를 높이고, 작은 공간을 차지하고, 전력소비를 줄여야한다고 얘기합니다. 공간에 대한 얘기를하면서 보여준 사진은, 모종의 데이터센터였는데, 서버비용을 줄이겠다는 생각으로 헐값의 데스크탑PC들을, 랙도 아닌, 짜맞춘 앵글에 쌓아놓고 운영했던 사진을 보여주었는데요, 보기만해도 재밌는 사진이더군요. 전력, 공간, 운영부담은 무시하고, 단순히 서버비용만을 편협하게 고려한 재밌는 발상이 물든 사진이라고 볼 수 있겠습니다.
전력, 서버, 네트워크 등의 애플리케이션 인프라(infrastructure) 비용에 대해
고 말했습니다. 수익의 10%이하로 인프라비용을 낮추든지, 아니면 인프라비용에 맞추어 수익을 그만큼 늘이든지해야 사업성이 있다는 얘기였습니다. 구글의 경우는 7%~8%선으로 발표되었다고 하더군요. 덧붙여 언급한 사항으로, 인프라비용을 줄이기 위해 자체 데이터센터를 구축해 운영한다거나하는 것은 인프라자체 비용은 줄일 수 있을지 몰라도, 값비싼 고급인력을 보유해 연봉을 지급해야한다라는 점에서 전체비용 절감효과가 크지 않을 수도 있다고 언급했습니다. 무엇을 보더라도 단편적으로만 바라보고 문제를 해결할 수는 없겠죠.
인프라를 위해 무엇을 어떻게하든, 다음의 3가지를 지키라고 얘기합니다.
이 밖에도 많은 광범위한 내용을 다루며 두시간에 걸쳐 얘기해주었구요, 마지막 시간이 되서야 대망의 레일스관련 내용이 터졌습니다. 앞시간에 언급한 고려사항과 필요한 선택에 대해 결론적으로 Joyent사에서 선택한 솔루션을 언급하며, 어떤 솔루션을 사용하면 레일스 애플리케이션의 성능을 높이고, 확장성을 고려할 수 있는지에 대한 제안이었습니다.
실제 사용 제품까지 언급하며 보여주었는데요, Sun사의 Sun Fire AMDs T1000s서버에 Solaris Nevada를 설치해서 사용한다고 했습니다. 처음에는 Dell사의 서버로 시작해서 Sun으로 바꾸었다고 하는데, 운영상의 장점을 극찬해서, 왠지 써보고 싶다는 생각이 들더군요. Sun에서도 인텔아키텍쳐(IA)의 CPU로 돌아가는 서버를 팔고 있는지조차 몰랐어요. ㅠ.ㅠ
Solaris OS를 선택한 이유로는 오픈소스임을 강조하면서, 상업용 제품이었던 믿을만한 운영체제(OS)가 오픈소스화 되었으니(음, OS가 OS화되었군요) 상업용의 장점과 오픈소스의 장점을 함께 갖추어서 좋다고 얘기했습니다. 우선 하드웨어벤더가 적극적으로 지원하는 운영체제를 설치하는게 기본이겠고, 특별히 Solaris OS를 선택한 이유로는 ZFS 파일시스템의 매력, 가벼운 가상화(virtualization), 무료, 그리고 대규모 시스템(512GB RAM, 1TB swap)에서 검증됐다는 점을 꼽았습니다.
오래 전에 Solaris x86버전은 사업 접는다고 들었던거 같은데, 다시 IA쪽도 지원하나보군요. 무관심하게 지냈었던 분야였는데, 이번 기회에 다시 귀를 열고 지내야겠습니다. Sun에서 스폰서라도 받았는지, SAN장비도 Sun Fire X4500의 운영편의성을 강조하면서 극찬했습니다.
루비의 강점으로는 쓰레드기반이 아닌 프로세스기반임을 언급했고, 그 외에도 당연한 루비강점언급이 잠시 있었구요, 레일스 프로세스를띄우는 방법으로방법으로 FCGI, 몽그렐(mongrel), JRuby in Glassfish를 나열했습니다. 지금의 상황은 몽그렐이 좋은 선택이지만, JRuby in Glassfish의 높은 가능성을 암시했습니다. JRuby 완성도가 높아지면 자바쪽의 강점을 그대로 흡수할 수 있겠죠. 예를들어 JDBC연결이라든지 Sequoia사용등이 그 일부가 될 수 있겟습니다.
Joyent사에서 사용하는 몽그렐 클러스터의 구성은, 16GB RAM의 4 AMD CPU 시스템을 4개의 버추얼컨테이너로 나누어(물리적으로 한개의 서버가, 논리적으로 4대의 서버로 분할) 각각의 컨테이너에 10개식의 몽그렐 프로세스를 띄워서 사용한다고 했습니다.
DB연결은 MySQL adapter를 수정해서 Sequoia의 C-API에 연결해 사용할 수 있다고 했는데, 실제로 Joyent사에서 사용 중인지는 잘 못들었습니다.
로드밸런서(load balancer)로는 BIG-IP f5를 쓴다고 했는데요, 안정적이고 확장성 뛰어난점은 물론이고 Layer7 수준이라는 강점을 내세웠습니다. 제가 다니는 회사에서 주로 쓰는 LVS같은 L4수준에서 할 수 없는 기능을 보여주었는데, 꽤 샘이 나더군요.
현재 일반적으로 몽그렐 클러스터는 Apache의 로드밸런싱 프록시 모듈을 사용할텐데요, Joyent에서는 BIG-IP 로드밸런서에 곧바로 몽그렐 클러스터를 그룹별로 연결해서 사용한다고 합니다. 아파치 모듈의 어떤 부분이 블러킹콜을 사용해서 확장성의 한계가 크다라는 점을 애기했습니다.
L7수준으로 로드밸런싱해서, [HTTP:uri]를 보고 실제 웹서비스클러스터를 나누어서 사용하는데, 이를 이용해 같은 호스트명에 대해 svn이나 trac 클러스터군을 나누어 구분했고, 레일스 애플리케이션의 경우, 컨트롤러별로 몽그렐 클러스터를 구분지어서 처리한다는 점이 인상적이었습니다.
무료로 사용가능한 L7대안으로 몇가지 제시했는데, 미처 메모하지 못했습니다. 제가 다니는 회사에서는 L4수준인 LVS를 주로 쓰는데, L7수준으로도 무료가 있다고하니, 잘 써볼 수 있는 기회가 생기면 좋겠습니다. 우선은 아파치 밸런싱프록시 모듈로 따라해봐야겠습니다.^^;
그리고, 이 부분이 전체 3시간의 핵심일 수 있는 내용일텐데요, 꼭 레일스 애플리케이션에 한정되는 얘기는 아니지만, RDBMS만 너무 고집하지 말라고 했습니다. memcached, LDAP, J-EAI, File System을 잘 활용해서 확장성을 높일 수 있는 점을 잊지 말라고 했습니다. J-EAI는 처음 들어봤는데, 메모리디비를 사용하는 메시지버스라고 했습니다. 커넥터도 다양하고, 클러스터링해서 사용가능한 확장성 좋은 솔루션이라고 하는군요.
파일시스템의 경우, 절대 한 디렉토리에 10,000개 이상의 파일을 저장하지 말라는 기본적인 얘기가 있었구요, 이를 위해 사용하는 디렉토리 해쉬의 경우, 너무 다단계를 사용하는 우를 범하지 말고, 보기에도 깔끔하고 예측가능한 방법으로 해쉬처리하자는 내용을 언급했습니다. Jamis의 ID파티셔닝에 대한 간단한 루비코드를 샘플로 보여주기도 했습니다.
간과하기 쉬운 DNS에 대해서도 언급했는데요. PowerDNS에 데이타베이스를 백엔드로 붙여서 간단히 사용자별로 서버군을 분리하는 내용을 언급했습니다. Master DB 하나만 공유하고, 분리가능한 대부분의 데이터는 분리된 서버군이 나누어 처리하는 방식이었습니다.
전체 내용을 요약한 다음의 슬라이드 한장이, 핵심이라고 할 수 있겠습니다.
이 튜토리얼(세션)에서만 언급한 내용만 보더라도, 성능이나 확장성을 위해서는 레일스뿐만이 아니라 다양한 소프트웨어, 하드웨어가 영향을 미치고, 무엇보다 중요한 것은 엔지니어의 경험과 역량일거 같다는 생각으로 정리되네요. 결론적으로, '안정적이고 확장성 좋은 웹서비스에 레일스를 사용할 수 있는가?'라는 질문에 대해서는 우문현답이 되어 마무리된걸까요?
오늘은 본격적인 시작에 앞서, 오전/오후로 나누어 튜토리얼 몇개가 준비되어 있었는데요, 저는 오전에는 Scaling Rails Application from the Bottom Up을 듣고, 오후에는 Rails Routing Round Up을 들었습니다.
먼저 오전의 Scaling Rails Application from the Bottom Up 튜토리얼은, Joyent사의 CTO인 Jason Hoffman의 레일스 애플리케이션의 성능과 확장성에 대한 강의식 세션이었구요, 튜토리얼이라고 보기는 어려운 형식으로 꽤 흥미로운 내용을 심도 깊게 얘기해 주었습니다.
50분씩 3시간으로 나누어 진행했으며, 처음 두시간은 일반적인 성능과 확장성에 대한 접근방법을 넓은 시각으로 비추어 주었고, 마지막 한시간만이 레일스 관련한 확장성에 대한 설명시간이었습니다.
전체적으로는
루비/레일스로 실서비스에 적용할 만큼 안정적이고 충분한 성능을 낼 수 있나요?
라는 질문에 대한 답변과 보충 설명의 시간이었다고 볼 수 있습니다. 그 답변에 대해 우선은
그것이 정말 레일스의 이슈인가?
라는 반문으로 문제를 풀어나갔는데요, 전체 시스템관리자의 관점으로 바라볼 때, 성능과 확장성에 관련한 구성요소가 어떤 것들이 있는지 슬라이드 한장에 작은글씨로 가득 채워 놓고는 그 중에 레일스가 차지하는 부분을 표시해서 그 비율이 얼마나 적은지를 보여주었습니다. 개발자 관점으로만 좁게 바라보다보니, 마치 레일스로 바뀌는 것이 대단한 차이가 있는 것처럼 생각되지만, 사실 전체적으로 중요한 부분은 한 두개가 아니구나하는 것을 일깨워준 슬라이드였습니다.
확장성의 의미에 대해서는 레고블럭에 비유하며, 어떤 시스템이 확장성 좋은 시스템인지를 설명했습니다. 레고블럭의 경우 하나에 한블럭 더 꽂으면 딱 2배 길이가 되고, 하나 더 꽂으면 3배 길이가 되고, 다시 한개 줄이면 2개 길이가 되는등, 늘이고 줄이는 만큼의 결과차이를 그대로 보인다는 점에서 확장성이 뛰어나다라고 하는 비유였는데요, 막연히 여러대의 서버로 늘여서 성능 높이는게 확장성이 아니다라는 점을 강조했습니다.
성능과 확정성의 기본적인 제약사항으로는, 자금, 시간, 인력, 경험, 전력, 네트워크 bandwidth를 언급했습니다. 레일스가 그 확장성의 제약사항이 아니라는 점을 은연중에 강조했다고 볼 수 있는데, 전력의 경우는 저는 미처 생각치 못한 내용이었습니다. 실제로 1년에 전체 서버비용의 30%정도의 큰 금액이 전력비용으로 소비되고, 전력이 결국 사용할 수 있는 CPU와 메모리를 제한하기 때문에 큰 제약사항일 수 있다고 했습니다. 이 부분에서 각종 전원플러그들을 잔뜩 찍어놓은 사진을 보여주면서 어떤게 전력손실이 적고 좋다를 설명하는거 같았는데, 저런거까지 신경써야하는구나 싶더군요. 전력 문제는, 대규모IT기업이 IDC센터를 지을 때, 전력비가 몇 센트라도 싼 지역에 짓는다는 사례를 들며 강조했습니다.
서비스 성능과 확장성에 레일스가 제약사항이 아니라는 점을 강조하면서, 그렇다면 레일스의 강점은 무엇일까하는 궁금점에 대한 답변으로는,
하루 아침에 완성되는 최고 수준의 웹사이트는 없으며, 여러 단계를 반복해 계속적으로 완성도를 높이고 기능이 추가되는 과정이 필요한데, 이 반복과정(iteration)을 빠르게 진행할 수 있다.
라는 장점을 얘기했습니다. 저는 레일스로 개발하면 편하고 빠르고 재미있다(!)라는 장점을 크게 보는데, Jason씨의 강점 언급이 보다 프로다운 것이 될 수 있겠네요.
다시 확장성으로 돌아와서, 확장성의 목표는 컴퓨팅 파워를 높이고, 작은 공간을 차지하고, 전력소비를 줄여야한다고 얘기합니다. 공간에 대한 얘기를하면서 보여준 사진은, 모종의 데이터센터였는데, 서버비용을 줄이겠다는 생각으로 헐값의 데스크탑PC들을, 랙도 아닌, 짜맞춘 앵글에 쌓아놓고 운영했던 사진을 보여주었는데요, 보기만해도 재밌는 사진이더군요. 전력, 공간, 운영부담은 무시하고, 단순히 서버비용만을 편협하게 고려한 재밌는 발상이 물든 사진이라고 볼 수 있겠습니다.
전력, 서버, 네트워크 등의 애플리케이션 인프라(infrastructure) 비용에 대해
The 10% Rule: (인력 비용을 제외한) 인프라비용이 수익의 10%이하여야 한다.
고 말했습니다. 수익의 10%이하로 인프라비용을 낮추든지, 아니면 인프라비용에 맞추어 수익을 그만큼 늘이든지해야 사업성이 있다는 얘기였습니다. 구글의 경우는 7%~8%선으로 발표되었다고 하더군요. 덧붙여 언급한 사항으로, 인프라비용을 줄이기 위해 자체 데이터센터를 구축해 운영한다거나하는 것은 인프라자체 비용은 줄일 수 있을지 몰라도, 값비싼 고급인력을 보유해 연봉을 지급해야한다라는 점에서 전체비용 절감효과가 크지 않을 수도 있다고 언급했습니다. 무엇을 보더라도 단편적으로만 바라보고 문제를 해결할 수는 없겠죠.
인프라를 위해 무엇을 어떻게하든, 다음의 3가지를 지키라고 얘기합니다.
- keep it simple
- standardize, standardize, standardize
- try and use open technologies
이 밖에도 많은 광범위한 내용을 다루며 두시간에 걸쳐 얘기해주었구요, 마지막 시간이 되서야 대망의 레일스관련 내용이 터졌습니다. 앞시간에 언급한 고려사항과 필요한 선택에 대해 결론적으로 Joyent사에서 선택한 솔루션을 언급하며, 어떤 솔루션을 사용하면 레일스 애플리케이션의 성능을 높이고, 확장성을 고려할 수 있는지에 대한 제안이었습니다.
실제 사용 제품까지 언급하며 보여주었는데요, Sun사의 Sun Fire AMDs T1000s서버에 Solaris Nevada를 설치해서 사용한다고 했습니다. 처음에는 Dell사의 서버로 시작해서 Sun으로 바꾸었다고 하는데, 운영상의 장점을 극찬해서, 왠지 써보고 싶다는 생각이 들더군요. Sun에서도 인텔아키텍쳐(IA)의 CPU로 돌아가는 서버를 팔고 있는지조차 몰랐어요. ㅠ.ㅠ
Solaris OS를 선택한 이유로는 오픈소스임을 강조하면서, 상업용 제품이었던 믿을만한 운영체제(OS)가 오픈소스화 되었으니(음, OS가 OS화되었군요) 상업용의 장점과 오픈소스의 장점을 함께 갖추어서 좋다고 얘기했습니다. 우선 하드웨어벤더가 적극적으로 지원하는 운영체제를 설치하는게 기본이겠고, 특별히 Solaris OS를 선택한 이유로는 ZFS 파일시스템의 매력, 가벼운 가상화(virtualization), 무료, 그리고 대규모 시스템(512GB RAM, 1TB swap)에서 검증됐다는 점을 꼽았습니다.
오래 전에 Solaris x86버전은 사업 접는다고 들었던거 같은데, 다시 IA쪽도 지원하나보군요. 무관심하게 지냈었던 분야였는데, 이번 기회에 다시 귀를 열고 지내야겠습니다. Sun에서 스폰서라도 받았는지, SAN장비도 Sun Fire X4500의 운영편의성을 강조하면서 극찬했습니다.
루비의 강점으로는 쓰레드기반이 아닌 프로세스기반임을 언급했고, 그 외에도 당연한 루비강점언급이 잠시 있었구요, 레일스 프로세스를띄우는 방법으로방법으로 FCGI, 몽그렐(mongrel), JRuby in Glassfish를 나열했습니다. 지금의 상황은 몽그렐이 좋은 선택이지만, JRuby in Glassfish의 높은 가능성을 암시했습니다. JRuby 완성도가 높아지면 자바쪽의 강점을 그대로 흡수할 수 있겠죠. 예를들어 JDBC연결이라든지 Sequoia사용등이 그 일부가 될 수 있겟습니다.
Joyent사에서 사용하는 몽그렐 클러스터의 구성은, 16GB RAM의 4 AMD CPU 시스템을 4개의 버추얼컨테이너로 나누어(물리적으로 한개의 서버가, 논리적으로 4대의 서버로 분할) 각각의 컨테이너에 10개식의 몽그렐 프로세스를 띄워서 사용한다고 했습니다.
DB연결은 MySQL adapter를 수정해서 Sequoia의 C-API에 연결해 사용할 수 있다고 했는데, 실제로 Joyent사에서 사용 중인지는 잘 못들었습니다.
로드밸런서(load balancer)로는 BIG-IP f5를 쓴다고 했는데요, 안정적이고 확장성 뛰어난점은 물론이고 Layer7 수준이라는 강점을 내세웠습니다. 제가 다니는 회사에서 주로 쓰는 LVS같은 L4수준에서 할 수 없는 기능을 보여주었는데, 꽤 샘이 나더군요.
현재 일반적으로 몽그렐 클러스터는 Apache의 로드밸런싱 프록시 모듈을 사용할텐데요, Joyent에서는 BIG-IP 로드밸런서에 곧바로 몽그렐 클러스터를 그룹별로 연결해서 사용한다고 합니다. 아파치 모듈의 어떤 부분이 블러킹콜을 사용해서 확장성의 한계가 크다라는 점을 애기했습니다.
L7수준으로 로드밸런싱해서, [HTTP:uri]를 보고 실제 웹서비스클러스터를 나누어서 사용하는데, 이를 이용해 같은 호스트명에 대해 svn이나 trac 클러스터군을 나누어 구분했고, 레일스 애플리케이션의 경우, 컨트롤러별로 몽그렐 클러스터를 구분지어서 처리한다는 점이 인상적이었습니다.
무료로 사용가능한 L7대안으로 몇가지 제시했는데, 미처 메모하지 못했습니다. 제가 다니는 회사에서는 L4수준인 LVS를 주로 쓰는데, L7수준으로도 무료가 있다고하니, 잘 써볼 수 있는 기회가 생기면 좋겠습니다. 우선은 아파치 밸런싱프록시 모듈로 따라해봐야겠습니다.^^;
그리고, 이 부분이 전체 3시간의 핵심일 수 있는 내용일텐데요, 꼭 레일스 애플리케이션에 한정되는 얘기는 아니지만, RDBMS만 너무 고집하지 말라고 했습니다. memcached, LDAP, J-EAI, File System을 잘 활용해서 확장성을 높일 수 있는 점을 잊지 말라고 했습니다. J-EAI는 처음 들어봤는데, 메모리디비를 사용하는 메시지버스라고 했습니다. 커넥터도 다양하고, 클러스터링해서 사용가능한 확장성 좋은 솔루션이라고 하는군요.
파일시스템의 경우, 절대 한 디렉토리에 10,000개 이상의 파일을 저장하지 말라는 기본적인 얘기가 있었구요, 이를 위해 사용하는 디렉토리 해쉬의 경우, 너무 다단계를 사용하는 우를 범하지 말고, 보기에도 깔끔하고 예측가능한 방법으로 해쉬처리하자는 내용을 언급했습니다. Jamis의 ID파티셔닝에 대한 간단한 루비코드를 샘플로 보여주기도 했습니다.
간과하기 쉬운 DNS에 대해서도 언급했는데요. PowerDNS에 데이타베이스를 백엔드로 붙여서 간단히 사용자별로 서버군을 분리하는 내용을 언급했습니다. Master DB 하나만 공유하고, 분리가능한 대부분의 데이터는 분리된 서버군이 나누어 처리하는 방식이었습니다.
전체 내용을 요약한 다음의 슬라이드 한장이, 핵심이라고 할 수 있겠습니다.
이 튜토리얼(세션)에서만 언급한 내용만 보더라도, 성능이나 확장성을 위해서는 레일스뿐만이 아니라 다양한 소프트웨어, 하드웨어가 영향을 미치고, 무엇보다 중요한 것은 엔지니어의 경험과 역량일거 같다는 생각으로 정리되네요. 결론적으로, '안정적이고 확장성 좋은 웹서비스에 레일스를 사용할 수 있는가?'라는 질문에 대해서는 우문현답이 되어 마무리된걸까요?
