<3935C8A35FB0F8C7D05FC6AEB7BBB5E55FC7B0C1FAB0EDB5B5C8ADB8A65FC0A7C7D15FBDC7BFEBC0FBC0CE5FBCD2C7C1C6AEBFFEBEEE5FBEC6C5B0C5D8C3B35FB8AEBAE45F F322E687770>

Size: px

Start display at page:

Download "<3935C8A35FB0F8C7D05FC6AEB7BBB5E55FC7B0C1FAB0EDB5B5C8ADB8A65FC0A7C7D15FBDC7BFEBC0FBC0CE5FBCD2C7C1C6AEBFFEBEEE5FBEC6C5B0C5D8C3B35FB8AEBAE45F F322E687770>"

지호 장
6 years ago
Views:

1 품질고도화를위한실용적인소프트웨어아키텍처리뷰 Part 2 : 프랙티컬아키텍처리뷰의검토내용과사례 [ 제 95 호 ] Ⅰ. 아키텍처리뷰프로세스 Ⅱ. 아키텍처품질 Ⅲ. 체크리스트 Ⅳ. 결론

SW 공학트렌드 동향분석 Webzine Ⅰ. 아키텍처리뷰프로세스 아 키텍처리뷰의내용을바탕으로아키텍처리뷰를하기위한프로세스의내용을설명하고자한다. 사내에서수많은솔루션들이생성되면서아키텍처리뷰를해 야하고, 이를관리하는사람과프로세스가필요하게되었다. 아키텍처리뷰의흐름을통제하고관련담당자들이모이는회의실을예약하는아키텍처리뷰담당자가필요하다.

2 SW 공학트렌드 동향분석 Webzine Ⅰ. 아키텍처리뷰프로세스 아 키텍처리뷰의내용을바탕으로아키텍처리뷰를하기위한프로세스의내용을설명하고자한다. 사내에서수많은솔루션들이생성되면서아키텍처리뷰를해 야하고, 이를관리하는사람과프로세스가필요하게되었다. 아키텍처리뷰의흐름을통제하고관련담당자들이모이는회의실을예약하는아키텍처리뷰담당자가필요하다. 아키텍처리뷰담당자로서 Coordination 을진행하고피드백까지아키텍처리뷰의모든단계에참가하고최종적으로피드백을주는역할도한다. 아키텍처리뷰담당자는 < 그림 1> 과같이리뷰대상을공지하고, 관련자료를아키텍처를설계한개발자또는아키텍트로부터자료를전달받는다. 1편에서소개한 5개의자료 ( 시스템아키텍처, 어플리케이션스택아키텍처, 시스템구성및네트워크아키텍처, 서비스흐름도 ) 를바탕으로관련매니저와아키텍처전문가들에게미팅을요청한다. 그리고리뷰회의를진행하고관련피드백내용을전달한다. 그림 1_ 아키텍처리뷰흐름 리뷰담당자는자료를받는일과회의실을예약하는일에서부터회의를리딩 / 진행하는다소쉽지않은일도맡게된다. 때로는설계자의감정을상하고않고, 아키텍처가한리뷰의의의를충분히이해시켜서 < 그림 2> 와같이회의에참여시킬수있도록독려하기도한다. 그림 2_ 아키텍처리뷰모임 June (No.95)

공학트렌드 아키텍처리뷰회의는설계자의아키텍처를보면서이해관계자및매니저와아키텍 트들이들어가기때문에수많은질의 / 응답이나오게하고설계자에게피드백을자연스 럽게주고받을수있도록하는것이목적인회의이다. Ⅱ. 아키텍처품질 아 키텍처품질을체크하는방법을정의할필요가있다. 기술에대한내용을주관적인판단으로검토하는것이결코쉽지않기때문에객관적인품질지표를 바탕으로언급하도록가이드해야한다.

3 공학트렌드 아키텍처리뷰회의는설계자의아키텍처를보면서이해관계자및매니저와아키텍 트들이들어가기때문에수많은질의 / 응답이나오게하고설계자에게피드백을자연스 럽게주고받을수있도록하는것이목적인회의이다. Ⅱ. 아키텍처품질 아 키텍처품질을체크하는방법을정의할필요가있다. 기술에대한내용을주관적인판단으로검토하는것이결코쉽지않기때문에객관적인품질지표를 바탕으로언급하도록가이드해야한다. 특히리뷰하는동안에는쓸데없는농담이나공신력없는소문이나기술 / 본질과관련없는내용들은언급하지않도록주의하는것이중요하다. 아키텍처품질지표는 < 그림 3> 과같이성능 / 확장성, 보안, 가용성등크게 3개로나누었다. 필자는성능 / 확장성을솔루션 / 서비스의가장중요한부분이라고생각한다. 그다음으로가용성을중요하게여기고있는터라중요하게생각하는우선순위중심으로설명하고자한다. 그림 3_ 아키텍처리뷰품질지표 필자는 Apache Http/Tomcat 기반으로하는웹서비스와웹을기반으로하는솔루션 / 서비스개발을주로해왔고아키텍처리뷰기획도그런프레임에서바라보고있다. 또한필자의소속회사또한웹기반의솔루션 / 서비스분야라서전체적인내용과설명이웹기반으로설명 / 적용되어있음을먼저밝혀둔다. 2.1 성능 / 확장성 성능 / 확장성은성능과확장성두가지를묶었는데, 이 2 개의품질지표의궁극적인 02

SW 공학트렌드 동향분석 Webzine 목표가동일하기때문이다. 이궁극적인목표에는 요청량이많아질때어떻게처리할수있느냐 라는관점을내포하고있다. 좀더구체적으로들어가보면-요청량이많아질때성능적인아키텍처를고민할수밖에없고, 궁극적으로요청량처리 ( 아키텍처 ) 와요청저장량 ( 스토리지 ) 또는최종저장량을어떻게할것인가에대한구체적인내용을작성할수밖에없다.

4 SW 공학트렌드 동향분석 Webzine 목표가동일하기때문이다. 이궁극적인목표에는 요청량이많아질때어떻게처리할수있느냐 라는관점을내포하고있다. 좀더구체적으로들어가보면-요청량이많아질때성능적인아키텍처를고민할수밖에없고, 궁극적으로요청량처리 ( 아키텍처 ) 와요청저장량 ( 스토리지 ) 또는최종저장량을어떻게할것인가에대한구체적인내용을작성할수밖에없다. 만약작은규모의요청량만들어왔다고가정한다면성능이나확장성보다는다른품질지표들이더중요할수있다. 성능을높이기위한많은노력들이있다. 알고리즘을잘사용하여성능을높일수있고, 속도가빠른네트워크나솔루션 / 서비스를이용해서처리하는경우도있다. 필자가속해있는웹기반에서는다양한방법들을제시할수있다. 만약, 비손실이미지압축알고리즘을써야하는솔루션 / 서비스라면소요되는시간대비압축률이제일좋은 HDPhoto 방식을 < 그림 4> 와같이테스트를통해서고민하고최선의선택을선택할수도있다. 그림 4_ 비손실압축알고리즘테스트자료 출처 : Web/WAS 의경우, 다음의예를들수있다. 한대의 WAS 서버에서요청을처리하는아키텍처가있다고하자. 한대의서버에서감당할수있는수준이상의요청량이들어오면, 처리하지못한다. 이때는 L4/L7 스위치를맨앞에물리적으로위치하게하고, 여러대의 WAS 가처리하도록하고, Nginx 나 Apache Http 서버를 WAS 앞에두어 Load Balacing 을두도록가이드할수있다. 그러나연결지향적인요청이많다면 KeepAlive 설정을 On 으로처리하는것도좋은방법이다. 다음 < 그림 5> 의 Polling 과같은 Event 단위의처리가많다면 NonBlocking 또는 Comet 이나 Piggyback, Long/short polling 같은아키텍처를구성할수도있을것이다 June (No.95)

공학트렌드 그림 5_Comet Architecture 출처 : http://www.ibm.

5 공학트렌드 그림 5_Comet Architecture 출처 : 또는 < 그림 6> 와같이 http 대신 spdy 를써서모바일환경에서성능을높일수있는방법을같이고민할수있다. 그림 6_ 모바일환경에서 SPDY 가 Http 보다속도가빠르게나온다는벤치마크정보 출처 : 또는 < 그림 7> 처럼웹 UI 의성능을위해서 AJAX 을사용할수있다. 04

SW 공학트렌드 동향분석 Webzine 그림 7_AJAX Architecture 출처 : https://ajax.sys-con.com/node/338111 UI 컴포넌트들이많은웹서비스의경우라면빠른 AJAX 를활용하거나, Http Caching 정책 ( 예, Etag) 을잘사용하여국내가아닌해외각지에서빠르게웹화면을보여줄수있도록한다.

6 SW 공학트렌드 동향분석 Webzine 그림 7_AJAX Architecture 출처 : UI 컴포넌트들이많은웹서비스의경우라면빠른 AJAX 를활용하거나, Http Caching 정책 ( 예, Etag) 을잘사용하여국내가아닌해외각지에서빠르게웹화면을보여줄수있도록한다. < 그림 8> 과같이 WAS 와 DB 간의연결 (Connection) 을완충하는 Connection Pool 을쓸지, < 그림 9> 처럼 Message Queue 중어떤솔루션을사용하고어떤방식을써서대용량요청을처리하는것을좋을지살펴볼수있다. 그림 8_Connection Pool 정보 출처 : June (No.95)

공학트렌드 그림 9_Rabbit MQ 아키텍처 출처 : http://www.rabbitmq.com/tutorials/tutorial-six-java.html 대용량캐쉬시스템인 Redis 와 Memcached 은널리알려져있지만, 성능이잘나오는특징이있다. < 그림 8> 의정보처럼이둘시스템은 Key size에따라혹은 get/set 호출빈도에따라성능이달라질수있다.

7 공학트렌드 그림 9_Rabbit MQ 아키텍처 출처 : 대용량캐쉬시스템인 Redis 와 Memcached 은널리알려져있지만, 성능이잘나오는특징이있다. < 그림 8> 의정보처럼이둘시스템은 Key size에따라혹은 get/set 호출빈도에따라성능이달라질수있다. 아키텍트는캐쉬를고민하는솔루션 / 서비스에이런정보를주어확인할수있도록할것이다. 그림 10_Redis 와 Memcache 비교 출처 : 정적리소스 (png/jpg 와같은이미지파일, css, xml) 들을 WAS 에서처리하도록하는경우가있는데, 이를자주사용하면 Apache Http 서버에서처리하도록할수있다. 내부캐쉬를사용하는 Nginx 를사용하면보다높은수준의속도를보장받을수있다. < 그림 11> 과같이트래픽이순간적으로늘수있으나, 서버운영비용을줄이기위해서 CDN 를활용하는방식을사용할수도있다. 06

SW 공학트렌드 동향분석 Webzine 그림 11_CDN(Akamai) 적용사례 출처 : http://www.cloudbus.org/cdn/rd/cdns.html 의외로많은개발자들이 CDN 을활용하지않고있으며, 특히 Tomcat 과같은 WAS 에서정적리소스를돌리는상황이많이발견했다. 이렇게성능관점보다는단순한구현에만치중되는개발사례가의외로많이존재했다.

다음 < 그림 12> 는하나의큰테이블을내부적으로여러개의테이블로나누어성능을최적화하는방법을사용한예이다. 그림 12_Partitioning 정책적용사례 출처 : http://yoshinorimatsunobu.blogspot.kr/2011/05/proper-handling-of-insert-mostly-select.

8 SW 공학트렌드 동향분석 Webzine 그림 11_CDN(Akamai) 적용사례 출처 : 의외로많은개발자들이 CDN 을활용하지않고있으며, 특히 Tomcat 과같은 WAS 에서정적리소스를돌리는상황이많이발견했다. 이렇게성능관점보다는단순한구현에만치중되는개발사례가의외로많이존재했다. Nginx 의캐쉬기능과 Web 서버의캐쉬를잘활용할수있는방법을제시할수있다. 스토리지의경우는 mysql 을사용하여 multi-master 부터 partitioning, sharding 을고민할수있고, mongo, hbase 나 cassandra와같은 nosql 제품을고민하는경우가있다. nosql 을쓰고자하는합당한논리가있다면사용할수있을것이다. 다음 < 그림 12> 는하나의큰테이블을내부적으로여러개의테이블로나누어성능을최적화하는방법을사용한예이다. 그림 12_Partitioning 정책적용사례 출처 : 만약웹기반의솔루션 / 서비스라면다음과같이 Layer 별로가용성을높일수방법을아키텍처리뷰에서집중적으로얘기할수있을것이다. Network Layer (json/xml/plain-text, Http/SPDY) Web/App Layer (Ajax, Comet, Tomcat, Nginx/Aapche Http/Vanish/CDN, Connection Pooling, 알고리즘, 데이터구조 ) Store Layer ( 일반 DB, Nosql-redis/memcached, Sharding-mysql,cubrid) June (No.95)

공학트렌드 2.2 가용성 가용성 (Availability) 이란장애없이정상적으로사용한시간 (Uptime) 대비장애포함한전체사용시간 (Uptime+Downtime) 으로나눈값을말한다. 가용성값이높은것을고가용성 (HA, High Availability) 이라고하는데, 아키텍처리뷰에서말하는가용성은장애를최대한예방할수있는시스템으로개발되어있는지확인하는품질지표로쓰인다.

9 공학트렌드 2.2 가용성 가용성 (Availability) 이란장애없이정상적으로사용한시간 (Uptime) 대비장애포함한전체사용시간 (Uptime+Downtime) 으로나눈값을말한다. 가용성값이높은것을고가용성 (HA, High Availability) 이라고하는데, 아키텍처리뷰에서말하는가용성은장애를최대한예방할수있는시스템으로개발되어있는지확인하는품질지표로쓰인다. 웹서비스를 WEB/WAS 한대로쓰는상황에서하드디스크에러가발생하면해당서비스는유용하지않다. L4/L7 스위치를써서이중화를하던지, Zookeeper 나 HAProxy 와같은오픈소스를활용해야한다. < 그림 13> 의예시처럼가용성을높이기위해서 HAProxy 를 2 대를사용해서한대의서버가장애가발생하더라도다른서버에는장애가나지않도록설계할수있다. 그림 13_AWS 의 HA 사용사례 출처 : 데이터백업 ( 미러링 ) 을통해서장애를최소화할수있는 < 그림 14> 의 DRDB 를사용하 면물리서버의가용성을높일수있다. 08

SW 공학트렌드 동향분석 Webzine 그림 14_DRBD 적용사례 출처 : http://www.drbd.org/ Mysql 을이용할경우 master-slave 의 2 copy 를최소한으로권장하고대부분의서비스는 3 copy 로쓸수있도록한다. < 그림 15> 의예처럼 Replication 을두어 Mysql 장애에잘대응시킬수있고성능이슈까지해결할수있다.

10 SW 공학트렌드 동향분석 Webzine 그림 14_DRBD 적용사례 출처 : Mysql 을이용할경우 master-slave 의 2 copy 를최소한으로권장하고대부분의서비스는 3 copy 로쓸수있도록한다. < 그림 15> 의예처럼 Replication 을두어 Mysql 장애에잘대응시킬수있고성능이슈까지해결할수있다. 그림 15_Mysql clustering 사례 출처 : 가용성확보를위해서 Mysql 은어떠한방법 ( 예, MMM, MHA) 를사용할지? Oracle 이라면 RAC 를적용할지를작성할수있을것이다. 특히 DB 에SAN 스토리지와같은특별한장비를사용하여가용성을높일계획이있으면아키텍처문서에포함시킨다. 웹서비스의경우는 IDC 에나누어서버들을두어가용성을최대로한다. 예를들어 의경우는 GSLB(Global Service Load Balancing) 를사용하여 IDC 이중화및무정지서비스를하고있다 June (No.95)

공학트렌드 $ nslookup www.naver.com Server: 10.40.29.172 Address:10.40.29.172#53 Non-authoritative answer: www.naver.com canonical name = www.naver.com.nheos.com. Name: www.naver.com.nheos.com Address: 202.

11 공학트렌드 $ nslookup Server: Address: #53 Non-authoritative answer: canonical name = Name: Address: Name: Address: 아마존의경우, AWS 서비스가용성을높이기위해서 < 그림 16> 과같이여러 Region 으로도서비스를할수있도록했다. IDC 이중화혹은다중화의서비스를제공하고있는것이다. 그림 16_ 아마존 AWS 글로벌 Region 지원 출처 : 가용성도성능 / 확장성관점처럼다양하게설계를할수있다. Tier 별로가용성을어떻게높일수있을지정리할수있고, 만약웹기반의솔루션 / 서비스라면 Layer 별로가용성을높이는방법을아키텍처리뷰에서거론할수있다. Network Layer (L4/L7 Switch, DNS, HAProxy, Zookeeper, DRBD) Web/App Layer (Web-Nginx/Apache-Http/Vanish, WAS-Tomcat/Netty/Jetty, 알고리즘, 데이터구조 ) Database Layer (Mysql, Cubrid, Oracle-RAC, Altibase) 10

12 SW 공학트렌드 동향분석 Webzine 2.3 보안 필자는보안전문가가아닌개발자이다. 이에개발과운영을진행하면서중요하다고생각했던부분의관점으로접근하고자한다. 수많은은행들과기업, 통신사, 개인홈페이지까지해킹으로피해가속출하는요즈음, 보안은중요한품질지표중에하나가되었다. 때문에스토리지에암호화하여저장하는것뿐아니라통신시암호화하거나외부에오픈하는웹서비스경우방화벽을설치하는등다양한보안의특성을아키텍처리뷰문서에포함하도록하고있다. 보안을신경을쓰고있는지도아키텍처리뷰문서에반영하여미리보안문제를사전에알릴수있도록한다. 방화벽의위치를시스템아키텍처에포함시키거나, 공인 IP 또는내부 IP 인지구분하도록하면보다효과적일수있다. 특히통신방법을작성하면그효과는더욱극대화된다. 다음의 < 그림 17> 의 Exchange 방화벽적용사례가일명베스트프렉티스 (Best Practice) 라고할수있겠다. 그림에서알수있듯이 Client Access Server 가공인 IP 지만방화벽으로노출을최소화했고, 통신을 SSL 로하고그중간에보안이슈가없도록했다. 내부통신은 RPC 를이용해서성능을높이는아키텍처로디자인했다. 클라이언트와서버, 서버와서버끼리통신시암호화를어떻게할지, 외부에서는 SSL 로내부에서는 HTTP나 TCP 로통신할지에대한정보를아키텍처리뷰에작성하면더욱좋다. 그림 17_Exchange 방화벽적용사례 출처 : 만약방화벽바깥에오픈 API 서버가있다면모든포트는공격을받을수있다. 단순히 80,443 포트만오픈해야하는것들은방화벽을이용해서공격을최소화할수있도록해야한다 June (No.95)

공학트렌드 < 그림 18> 은 WhiteHat 에서발표한공격패턴과빈도율을분석한것이다. 다양한방법으로보안공격이수시로들어오기때문에외부오픈서버들은보안공격에뚫리지않도록각고의노력이필요하다. 우선, 공격에대한다양한패턴을방어할수있는코드를 WAS 에적용여부를확인해야한다. 개발조직에개발한보안모듈혹은자체적인개발한보안모듈사용여부에대한내용은아키텍처리뷰문서에넣는것이좋다.

13 공학트렌드 < 그림 18> 은 WhiteHat 에서발표한공격패턴과빈도율을분석한것이다. 다양한방법으로보안공격이수시로들어오기때문에외부오픈서버들은보안공격에뚫리지않도록각고의노력이필요하다. 우선, 공격에대한다양한패턴을방어할수있는코드를 WAS 에적용여부를확인해야한다. 개발조직에개발한보안모듈혹은자체적인개발한보안모듈사용여부에대한내용은아키텍처리뷰문서에넣는것이좋다. 그림 18_ 보안공격사례 - WhiteHat 자료 출처 : 대형포털의경우 DDOS 공격과같은무차별공격이들어오는경우가많다. 경험상서버장비를늘려서해결한경우도있지만, 워낙필터링해야할패킷이많거나패킷의내용이비정상적으로유입되어 TCP 소켓을계속오픈시켜자원을더이상쓰지못하게하는공격들이있기때문에이를대비하기위해보안장비 (Detector, Guard) 를이용하는것을추천한다. < 그림 19> 처럼외부로부터들어오는공격이많은웹서비스라면, 보안장비를이용해서공격을대비하는방안도고민할수있다. 12

SW 공학트렌드 동향분석 Webzine 그림 19_RioRey DDOS 솔루션의 Cisco Guard 적용사례 출처 : http://www.riorey.com/products-cleaning-center.html 개인정보를다루는고객 DB 쪽은개인정보와관련된모든정보를어떤식으로알고리즘화하는지, 저장하고있는지중요하다.

14 SW 공학트렌드 동향분석 Webzine 그림 19_RioRey DDOS 솔루션의 Cisco Guard 적용사례 출처 : 개인정보를다루는고객 DB 쪽은개인정보와관련된모든정보를어떤식으로알고리즘화하는지, 저장하고있는지중요하다. 특히회사내부보안솔루션 / 외부보안솔루션을사용하는경우는아키텍처리뷰문서에포함시키도록한다. 개인정보및중요정보는암호화없이단순히 Http 로전달하는경우는원칙을정해금지한다. 이를최대한 https 나암호화된알고리즘을써서개인정보또는중요정보를암호화하도록한다. 인하우스 (In-house) 통신이더라도 Node 간의구간통신을 Salt 와발급한 Key 를이용하여암호화 / 복호화하여통신전문을공격자가가로채더라도복호화가어렵도록해야한다. 또한 DB 에저장하는개인정보와패스워드는상황에맞는복잡한알고리즘 (AES128, SHA512, Salting 알고리즘, bcrypt) 등을이용하여최대한공격을막도록해야한다. 관련된정보는링크 ( 를참조한다. 인증서버나회원서버의경우는성능보다는보안을가장신경써야한다. 아키텍처리뷰에서는이를감안하여암호화 / 복호화하는성능저하보다는보안부분을배려할수있어야한다. 보안을감안한다면다양하게설계를할수있다. Tier 별로보안품질을어떻게높일것인지정리할수있다. 만약웹기반의솔루션 / 서비스라면다음과같이 Layer 별로보안품질을높이는방법을아키텍처리뷰에서거론할수있다. Network Layer (Guard, Node 간구간암호화 ) Web/App Layer (Web-White/BlackList 관리, SQL/XSS Injection 방어 ) Database Layer ( 개인정보및패스워드암호화 ) June (No.95)

15 공학트렌드 ERD (Entity Relation Diagram) 아키텍처리뷰문서를만들당시에는 ERD 는상세하지않을뿐더러단순하고핵심개념만있는 Entity-Relation 모델만존재한다. 실제핵심개념을설명할수있는수준으로진행하여이해도를높이도록한다. Ⅲ. 체크리스트 아 키텍처전문가들에게 < 표 1> 의예제처럼평가매트릭스를제공한다. 이내용을 바탕으로기본적인리뷰를진행할수있도록한다. 표 1_ 평가매트릭스예제 성능 / 확장성서비스운영시성능이슈또는병목현상이있을만한곳이없는가? 유저 (User) 요청이많아질경우에대한성능적아키텍처가포함되었는가? 정적리소스 (css, js) 를서비스하기위해 CDN 또는 Web 서버를잘활용했는가? WAS 앞에 Web 서버를두고적절히 Load Balancing 과 FailOver 를이용했는가? Cache Lib/Cache Server 를적절히이용했는가? 부하를잘분산하고, 파일을많이사용하는경우분산파일시스템 /NAS 를사용하도록하였는가?... 보안중요한정보또는개인정보전달시어떻게전달하는가? 외부오픈서버일경우, 대용량트래픽, DDOS, 해킹공격에대한방어를고민했는가? Security Zone 위치에알맞게서버가구성되어있는가? 중요서버군은방화벽안쪽에있는가? 방화벽외부서버와통신인증사용을적절하게반영했는가?... 가용성 Web/WAS 서버의장애를처리하는내용이들어가있는가? 스토리지백업및요청분산및장애에대한처리방식이들어가있는가? 네트워크단절에대한처리방식이들어가있는가?... 아키텍처리뷰회의에서의토론주제가 좋은아키텍처링사례 와 필수수정사항 & 추후고려사항 이나올수있도록한다. 좋은아키텍처링사례 는아키텍처리뷰를통 해서나온베스트프랙티스로추천될만한칭찬받을내용이다. 그리고 필수수정사항 ' 은품질속성중심각한결함이있을만한것으로작성하여수정을유도하는것이다. 그리고 추후고려사항 ' 은 2 가지로나누어지는데, 첫번째는당장은하지않아도되지 14

16 SW 공학트렌드 동향분석 Webzine 만아키텍처를일부 / 부분적으로권고하는내용이며, 두번째는실제코드구현 / 운영환경에서만날수있는잠재적인위험또는결함 (Defect) 을예방할수있도록내용을담을수있다. 리뷰 라는특성때문에아키텍처를설계하는사람을공격하는것처럼하지않도록하며감정을상하지않도록해야한다. 따라서리뷰의결과가 칭찬받아마땅한것 ( 강점 ) 과 고려해봐야할사항 ( 약점 ) 으로나오도록한다. 아키텍처리뷰담당자는애자일 (Agile) 의회고와비슷한맥락으로진행되도록하는것이좋다. 아키텍처리뷰담당자는회의참석자들이다양한관점으로아키텍처를볼수있도록회의를진행한다. 그래서장점과단점들을미리파악할수있도록사전에자료를공유하고, 생각할부분을사전에알려주는것도좋은방법이다. 리뷰담당자는회의에나왔던내용들을정리하고설계자에게리뷰때나온내용을피드백하도록한다. 특히관련자료들은모두문서화 ( 또는위키에작성 ) 하여다른개발자나아키텍트들이열람할수있도록공유하고, 같은실수가반복되지않도록한다. 좋은사례또한공유하여보고배울수있도록하는것이중요하다. 리뷰담당자는시간배분에주의해서회의시간이 1시간이넘지않도록한다. 아키텍처가리뷰내용을숙지하고, 이해하고있다면보통 30 분이내로회의가종료되지만가끔씩은 1시간이훌쩍넘어갈정도로준비안된경우가있으니, 회의가원활하게진행되도록회의준비에각별히신경쓰도록한다. Ⅳ. 결론 수 많은솔루션들이생성되는만큼이를관리하는사람과프로세스가필요해졌고, 이에아키텍처리뷰담당자와리뷰프로세스, 리뷰체크리스트등의필요 / 중요성이대두되고있음을살펴보았다. 아키텍처리뷰는아키텍처모듈의중복을최대한줄이고모호한부분은최대한명확하게잡아주는데목적이있다.( 아키텍처의품질지표인 ) 성능 / 확장성, 가용성, 보안등이잘못 / 누락되어있거나불분명한설계로나타날수있는결함 (defect) 의최소화하는효과적인방법이아키텍처리뷰임을강조한본글이보다능률적인업무수행에도움이되길바란다 June (No.95)

Web Application Hosting in the AWS Cloud Contents 개요 가용성과 확장성이 높은 웹 호스팅은 복잡하고 비용이 많이 드는 사업이 될 수 있습니다. 전통적인 웹 확장 아키텍처는 높은 수준의 안정성을 보장하기 위해 복잡한 솔루션으로 구현

02 Web Application Hosting in the AWS Cloud www.wisen.co.kr Wisely Combine the Network platforms Web Application Hosting in the AWS Cloud Contents 개요 가용성과 확장성이 높은 웹 호스팅은 복잡하고 비용이 많이 드는 사업이 될 수 있습니다. 전통적인