| http://blog.naver.com/locusty/80018522763 | |||||||||||||||
히치하이커를 위한 PHP 가이드 ③ PHP와 오라클을 이용한 엔터프라이즈 애플리케이션 개발 PHP와 오라클을 이용하여 16만 명의 사용자를 지원하는 시스템을 구축한 McGill University의 Department of Development & Alumni Relations 사례를 소개합니다. 캐나다 퀘벡주 몬트리얼에 위치하고 있는 McGill University의 Department of Development & Alumni Relations에서는 200~300 명의 정직원 및 자원봉사자들을 통해 16만 명의 대학 졸업자들과 기부자들을 관리하고 있습니다. 우리가 사용하는 웹 애플리케이션은 PHP와 Oracle 9i 기반으로 구현되었습니다. 우리는 인터넷을 통한 홍보 활동이 시작되고 나면, 시간 당 수만 명에 달하는 사용자가 웹 사이트에 방문할 것으로 예측하였습니다. 우리는 오라클의 강력한 로우(row) 레벨 보안 기능과 PHP의 뛰어난 성능 및 개발효율성을 활용하기로 했습니다. 이 문서에서는 다음과 같은 주제를 다루게 됩니다: • 프로젝트 배경 프로젝트 배경 다른 조직들과 마찬가지로, 우리 부서는 다음과 같은 문제로 고민하고 있었습니다:
그렇다면, 이러한 문제를 해결하기 위해서 어떤 방법을 선택해야 할까요? 우리는 첫 단계로, 웹을 기반으로 하는 모듈러 데이타베이스 애플리케이션을 구현하였습니다. 이 애플리케이션은 PHP와 Oracle9i를 기반으로 하며, 기존의 분산된 애플리케이션 환경과 웹 사이트들을 대치하는 용도로 사용되었습니다. 그 결과 공통 데이타를 동기화하고, 비즈니스 프랙티스를 준수하는 환경이 마련되었습니다. 이 애플리케이션은 중앙 데이타베이스의 기능을 보완하고, 데이타를 정확하게 리포트하고, 최신 데이타를 신속하게 제공한다는 의미에서 “Companion”이라는 이름이 붙여졌습니다. Companion 애플리케이션은 100개의 테이블과 5~6개의 모듈로 구성됩니다. 가장 큰 테이블의 경우 백만 개의 레코드가 저장되며, 상당 수의 테이블이 20~30 개의 컬럼을 가집니다. 또 로우 레벨 보안을 위해 오라클의 Fine-Grained Access Control (FGAC)과 Virtual Private Database (VPD)가 적극적으로 활용되었습니다. Companion 애플리케이션은 3개의 도메인을 가지며, 필요한 경우 추가적인 도메인 구성이 가능합니다. 모든 도메인은 동일한 PHP/Oracle 애플리케이션을 통해 동일한 데이타에 접근합니다. 3개의 도메인은 다음과 같습니다: 1. Staff intranet 2. "Constituents" intranet 3. Public domain PHP, Oracle, Apache, Linux를 선택한 이유 Apache와 Linux. Apache와 Linux는 (적절하게 구성된 경우) 저렴한 비용으로 뛰어난 보안 수준과 안정성을 제공한다는 정평을 얻고 있습니다. 우리는 또 Debian Linux(fDebian Project: http://www.debian.org/) 의 오픈 소스 커뮤니티 지원이 매우 활발하며 통합 소프트웨어의 품질과 안정성이 매우 뛰어나다는 점에서, 데이타베이스 서버 및 웹 서버를 위한 최적의 플랫폼이라고 판단하였습니다. PHP. 우리는 PHP가 개발속도, 비용적 혜택, 방대한 라이브러리, 커스터마이즈 기능 등의 면에서 Active Server Pages, ColdFusion, JSP 등의 다른 웹 테크놀로지보다 뛰어나다고 판단하였습니다. 또 PHP를 사용하는 경우 특정 벤더의 개발 툴에 종속되는 문제가 없다는 것도 또 다른 장점이었습니다. 다양한 웹 사이트와 프로그래머 포럼이 복잡한 문제의 해결을 위한 팁을 제공하고 있습니다. 또 대규모 애플리케이션의 개발에 필요한 컴포넌트를 제공하는 다양한 웹 사이트가 있습니다. PHP 코드는 C와 유사한 문법을 사용하기 때문에 배우기도 쉽습니다. 우리는 Java에 대해서도 검토를 했습니다. Java가 스크립트 기반의 코드보다 더 높은 효율성을 제공할 것이라고 기대하는 의견도 있었습니다. 하지만 PHP가 우리의 요구사항을 만족하기에 충분한 유연성과 개발속도를 제공했기 때문에 굳이 Java를 이용할 필요를 느끼지 못했습니다. PHP를 이용하여 오라클에 쿼리를 수행하는 예제는 Listing 1에서 확인하실 수 있습니다. 하지만 복잡한 형태의 OO(object-oriented) 프로그래밍을 수행해야 하는 경우 PHP로는 한계가 있을 수 밖에 없습니다. PHP는 기본적으로 스크립팅 언어로써 구현되었으며, PHP version 4에 포함된 OO 기능은 매우 제한적인 수준입니다. 이러한 문제는 최신 OO 기능이 구현된 PHP version 5에서 상당 부분 해결되었습니다. Oracle9i. 별도의 써드 파티 툴을 사용하지 않고 Companion 애플리케이션과 중앙 데이타베이스를 동기화할 수 있어야 한다는 것이 중요한 요구사항의 하나였습니다. 데이타의 변환/전송을 위한 코드를 별도로 개발하는 것보다는 두 대의 Oracle9i 시스템 간에 직접 데이타를 교환하도록 구성하는 것이 훨씬 간단했습니다. 우리의 프로젝트에서 Oracle9i는 구현 비용을 훨씬 상회하는 효과를 입증해 보였습니다. 기존의 PL/SQL 코드를 그대로 활용하여 개발 기간을 단축할 수 있었다는 것이 그 이유의 하나였습니다. 오라클이 Linux에 포팅된 이후로, PC 아키텍처에 데이타베이스 서버 운영체제를 구현할 수 있는 가능성이 열렸습니다. 중앙 데이타베이스에서는 Oracle8i가 운영되고 있었지만, 프로젝트에 9i를 적용함으로써 Fine Grained Audit Control, Secure Application Context와 같은 고급 VPD 기능을 활용할 수 있었습니다. 오라클은 이와 같은 수준 높은 보안 기능을 제공하는 유일한 데이타베이스 플랫폼입니다. Companion 애플리케이션의 구조 모든 소프트웨어 프로젝트가 그러하듯, 우리 개발팀은 재활용 가능한 보안 및 데이타 액세스 컴포넌트를 기반으로 기능적으로 독립된 모듈을 구현하고 유연하고 확장성 있는 애플리케이션을 구축한다는 목표를 세웠습니다. 실제 구현 방안이 다음과 같습니다. N-티어 architecture. 애플리케이션의 이식성과 확장성을 보장하기 위해, 계층화된 아키텍처가 구현되었습니다. 따라서 기존에 사용되던 기반 테크놀로지를 다른 기술로 교체해야 하는 경우에도, 전체 애플리케이션을 재작성할 필요가 없도록 하였습니다. A우리는 애플리케이션 요구사항을 고려하여, 일반적인 2-티어(tier) 또는 3-티어 아키텍처 대신 N-티어 아키텍처를 선택하였습니다.
presentation GUI 티어는 엔드 유저의 로컬 브라우저 상에 구현되며, 사용자가 실제로 데이타를 확인 또는 조작하는 부분을 담당합니다. 이 티어는 하부 계층에서 렌더링한 HTML 페이지와 폼으로 구성되며, 클라이언트-사이드 JavaScript 및 CSS(Cascading Style Sheet)를 포함하고 있습니다. 이 티어는 주로 사용자 입력을 수집하고, 실행 결과를 출력하는 목적으로 활용됩니다. presentation logic 티어는 서버 상에 존재하며 전적으로 PHP 스크립트를 이용하여 구현됩니다. 프리젠테이션 템플릿과 레이아웃, 검증 루틴(validation routine), 특정 모듈을 위한 스크립트 등이 이 계층에 포함됩니다. 이 티어는 사용자 입력을 검증 및 처리하고, 사용자와 하부 티어에서 전달되는 데이타를 이용하여 출력 정보를 구현하는 목적으로 활용됩니다. business logic 티어에서는 대부분의 비즈니스 룰이 구현됩니다 (보안상의 이유에서 일부 룰을 데이타베이스 레벨에서 구현하고, 이 정보를 애플리케이션 레벨에 노출하지 않도록 할 수도 있습니다.) 이 티어에서는 시스템 영역 별로 적용되는 다양한 룰을 “encapsulate”한 PHP 클래스가 제공됩니다. 또 이 티어에서는 사용자 인증, 세션 관리, 요청 인증 등을 위한 메커니즘을 제공함으로써 애플리케이션 레벨의 사용자 액세스를 제어합니다. 특히 상위 티어에서 보안 상의 권한에 따라 사용자 인터페이스를 커스터마이즈할 수 있는 몇 가지 메소드를 제공하고 있습니다. 마지막으로, 이 티어는 데이타 암호화, 압축, 데이타타입 변환 등을 위한, 재활용 가능한 공통 클래스를 제공하고 있기도 합니다. data abstraction logic 티어에서는 데이타베이스에 저장된 데이타와 애플리케이션 간의 인터페이스를 위한 메소드가 제공됩니다. 이 티어는 데이타 티어와 다른 시스템 사이에 존재하는 ‘추상화(abstraction)’ 계층으로서 기능하며, 애플리케이션이 데이타베이스 엔진으로부터 독립적으로 구현될 수 있도록 합니다. 심층적인 테스트 결과를 거친 후, 우리는 이 계층을 구현하기 위해 오픈 소스 툴인 ADODB 라이브러리 (http://php.weblogs.com/)를 적용하기로 결정하였습니다. Oracle 9i가 적용된 data 티어는 전체 시스템에서 가장 중요하고도 복잡한 부분입니다. data 티어의 보안 메커니즘에 대해서는 아래 “보안” 섹션에서 자세하게 설명됩니다. 그림 2는 Companion 애플리케이션의 물리적인 구성을 보여주고 있습니다:
Modules. 각 모듈은 데이타 구조(테이블 및 뷰)와 PL/SQL 패키지의 조합으로써 구성됩니다. 데이타 구조와 패키지는 business logic 티어에서 제공하는 PHP 클래스를 통해 GUI 애플리케이션과 통합됩니다. 이처럼 모듈화된 구성을 활용하는 경우, 논리적이고 일관적인 개발 작업이 가능하며 보안 수준의 개선이 가능하다는 장점이 있습니다. 각 모듈은 논리적으로 구분된 형태로 구현됩니다. 각 모듈은 서로 다른 보안 정책을 가지며, PHP 애플리케이션 파일로 구성된 별도의 웹 서버 폴더, 그리고 별도의 GUI 서브사이트와 테이블 셋을 갖습니다. 각각의 테이블 명은 테이블이 포함된 모듈을 의미하는 2자의 접두사를 갖습니다. 파일, 정책, 프로시저, 그리고 그 밖의 코드에도 미리 정의된 명명 규칙에 따라 사전 정의된 접두사가 적용됩니다. 모듈은 이처럼 서로 독립적으로 존재하지만, 전체 애플리케이션의 관점에서 볼 때에는 통합되어 있는 것으로 볼 수도 있습니다. 모든 모듈은 내비게이션 구성요소와 데이타를 공유하며, business logic 티어에서 제공하는 클래스를 함께 공유합니다. Table HR_Employee c1_id c1_emp_category web_emp_photo c2_emp_email ------- ---------------- -------------- ------------ M290171 central staff (blob) james.milton@mcgill.ca C179022 central staff (blob) doris.seagal@mcgill.ca M109022 casual (blob) luke.grande@mcgill.ca C390101 work-study (blob) patrick.roy@mcgill.ca M203400 faculty based staff (blob) mcmaster.philip@mcgill.ca Prefix code for Tables and Fields: HR - Human Resources module (each module has a 2 letter prefix for each of its tables) C1 - Central Database 1* C2 - Central Database 2* WEB - Companion Database Application* * Fields are prefixed by their source database. Since this application is a companion database, it synthesizes and uses data from a variety of sources, most especially a primary central DB.대부분의 모듈에 대해 유사한 보안 정책이 적용되는 것은 사실입니다. 하지만 프로젝트 초기 단계부터 각 모듈 별로 서로 다른 요구사항을 갖는 것이 확인되었습니다. 전체 모듈이 공유하는 보안 정책의 한 예로 "guru”를 들 수 있습니다. 각각의 모듈에는 3 명의 guru가 할당됩니다. Guru는 모듈에 대한 모든 관리 권한을 가지며, 보다 낮은 보안 레벨을 갖는 다른 관리자들에게 권한을 할당해 줄 수 있습니다. 모듈 간에 서로 다른 요구사항을 갖는 예로 HR 모듈의 인사 정보를 들 수 있습니다. 기밀 유지가 필요한 인사 정보의 경우 직원의 개인 식별자(Entity ID)를 기준으로 한 로우 레벨(row-level) 보안 기능이 구현됩니다. 그 밖의 다른 모듈에 대해서는 직원의 직책 식별자(Position ID)를 기준으로 하는 로우 레벨 보안 기능이 구현됩니다. 보안 애플리케이션 레벨에서 쿠키 기반의 세션 메커니즘을 이용하는 방법만으로는 보안 요구사항을 만족하기 어렵습니다. 대량의 트래픽이 발생하는 복잡한 구조의 데이타베이스 환경에서 로우(row) 레벨의 보안 환경을 구현하는 동시에 일정 수준 이상의 성능을 보장하려면, 대부분의 보안 기능을 데이타베이스 레벨에서 집중적으로 구현하는 것이 바람직합니다. 데이타베이스 엔진 레벨에서 VPD를 이용하여 데이타 액세스의 보안을 보장하는 경우, 가장 정밀한 수준의 보안을 구현하고 애플리케이션 보안 메커니즘을 우회하여 접근하는 외부 침입자의 세션에서 데이타를 조회할 수 없도록 원천적으로 차단할 수 있습니다. 또, 애플리케이션 툴 별로 보안 기능을 구현하는 대신, 데이타 서버에 구현된 보안 환경을 공유함으로써 총소유비용을 절감할 수 있습니다. 마지막으로, 데이타 액세스 관리 및 제어 환경을 중앙집중적으로 관리할 수 있다는 장점이 제공됩니다. Companion 애플리케이션은 오라클이 오래 전부터 제공해 오던 Basic Role Security 및 Basic User Account Security 기능을 활용하고 있습니다. 여기에 더하여 두 가지 강력한 VPD 툴, Secure Application Context과 FGAC가 구현되었습니다. (VPD에 대한 자세한 정보는 otn.oracle.com/deploy/security/oracle9ir2/pdf/VPD9ir2twp.pdf를 참고하시기 바랍니다.) Basic User Account Security. 보안 및 데이타베이스 아키텍처는 중앙 데이타베이스에 매일 업데이트되는 마스터 리스트(master list)를 기준으로 구성됩니다. 여기서 마스터 리스트를 구성하는 항목을 사용자(user)가 아닌 엔티티(entity)라 부릅니다. Companion 애플리케이션은 두 가지 사용자 그룹(user group: “staff”와 “graduates”) 을 포함하고 있습니다. 오라클의 Basic User Account Security 환경에서 사용자 그룹은 하나의 계정(account)로써 취급됩니다. 따라서 3만 명의 동시 사용자가 단 두 개의 계정을 공유할 수 있게 됩니다. 계정을 공유하지 못하는 다른 사용자들도 퍼블릭 데이타에 대해서는 접근이 가능할 수 있습니다 (참고: 이 문서에서 사용자(user)란 시스템에 접근하는 사람을 의미하며, 계정(account)란 오라클이 제공하는 사용자 계정을 의미합니다). 그림 3에서 확인할 수 있듯, 사용자(user)는 엔티티(entity)와 퍼블릭(public)의 부분집합을 이룹니다.
그렇다면 인증된 사용자 별로 계정을 할당하지 않고, 모든 사용자가 두 가지 계정을 공유하도록 설정한 이유는 무엇일까요? 대부분의 경우 애플리케이션의 보안은 개별 사용자 ID가 아닌 사용자 속성을 기준으로 관리되기 때문입니다. 이와 같은 환경을 구현하기 위해 사용되는 툴에 대해서는 아랫부분에서 자세히 설명하도록 하겠습니다. Basic Role Security. 사용자가 링크를 클릭하여 Companion 애플리케이션에 접근하는 경우, 보안 상의 관점에서 볼 때 해당 사용자는 특정 모듈에 접근하는 것으로 이해할 수 있습니다. 각각의 모듈은 오라클의 security role과 연계되어 있으며, 이 security role은 사용자 계정에 따라 할당 또는 거부 처리됩니다. 이 security role은 테이블, 뷰, 프로시저, 함수 등을 위한 오브젝트 레벨의 보안을 담당합니다. Basic Role Security는 오브젝트에 대한 넓은 범위의 사용자 권한(select, insert, execute 등)을 할당하는 용도로 사용되며, 데이타베이스 보안을 위한 첫 번째 단계로 볼 수 있습니다. 좀 더 상세한 수준의 사용자 권한은 FGAC에 의해 처리됩니다. VPD Secure Application Context. Companion 애플리케이션은 사용자 로그인 과정에서 오라클의 Secure Application Context를 이용하여 사용자에게 Entity ID를 할당합니다. Companion 애플리케이션이 사용하는 대부분의 보안 관련 기능은 계정(account; “staff” 또는 “grad”)과 컨텍스트(context; Entity ID)를 기준으로 관리됩니다. 사용자의 로그인 세션에는 암호화된 보안 토큰(security token)이 할당됩니다. 이 토큰은 쿼리가 수행될 때마다 읽혀집니다. 사용자 로그인 정보(이름/패스워드)와 Entity ID는 세션이 만료될 때까지 암호화된 토큰의 형태로 웹 서버에 저장됩니다. 사용자 로그인 정보를 이용하여 데이타베이스에 대한 연결이 설정되는 단계에서, Entity ID를 이용한 로우 레벨(row-level)의 보안 정책이 구현됩니다. VPD Fine-Grained Access Control. Secure Application Context에서 제공하는 Entity ID를 이용하여 로우 레벨의 접근 보안 환경을 구현할 수 있습니다. FGAC 보안 정책(security policy)은 (Basic Role Security의 경우와 마찬가지로) 오브젝트 단위로 할당됩니다. 하지만 Basic Role Security와 달리, FGAC 정책은 Entity ID에 연계된 속성(attribute) 정보를 이용하여 접근을 통제합니다. “nonpublic” 데이타베이스 오브젝트에 할당된 보안 정책을 이용하여 데이타에 대한 접근을 엄격하게 통제할 수 있습니다. 예를 들어, 데이타베이스 로그인 네임과 패스워드가 도난 당한 경우라 해도, 표준 SQL 툴을 이용해서 접근하는 방법으로는 보안 정책으로 보호된 테이블에 저장된 데이타를 정상적으로 조회할 수 없게 됩니다. 보안 정책은 사용자의 속성(attribute)과 로우(row)의 속성을 대조하고 사용자가 어떤 로우를 조회할 수 있는 지를 결정하게 됩니다. 예를 들어 Vancouver에 살고 있으며, West Coast Executive Dinner 행사에 초대된 사용자만이 해당 이벤트의 참석자 목록을 조회하도록 할 수 있습니다. 또 웹 사이트의 편집자(editor)는 페이지를 삭제할 수 없으나, 사이트의 소유자(author)는 삭제 작업이 가능하도록 설정할 수 있습니다. Affinities(친화도). Companion 애플리케이션에 접근하는 16만 명의 사용자는 매우 복잡다단한 구성을 갖고 있습니다. 각 사용자는 연령, 학위, 수입, 지역 등을 기준으로 하는 다양한 affinity(친화도) 요소를 갖습니다. 사용자의 접근 권한을 보다 쉽게 관리하려면, 이러한 속성을 일련의 affinity group으로 그룹화할 필요가 있습니다. affinity look-up table은 매일 단위로 갱신되며, 모든 엔티티의 affinity 정보를 수록하고 있습니다. FGAC는 이 테이블을 이용하여 데이타 로우(row)에 대한 접근을 통제합니다. 이때 데이타 로우에도 affinity가 할당됩니다. 또 개인화된 컨텐트를 사이트 방문자에게 푸쉬(push) 형식으로 전달할 때 affinity 정보를 사용하기도 합니다. 그림 4는 사용자가 페이지를 호출하는 과정에서 수행되는 5 단계의 데이타 요청 필터링 작업을 보여주고 있습니다.
동기화 (Synchronization) Companion 애플리케이션과 중앙 데이타베이스가 계속적으로 업데이트 되고 있는 상황에서, 두 시스템의 데이타를 동기화하는 것은 쉽지 않은 작업이었습니다. 우리는 실시간(real-time) 환경에는 못 미치지만, 데이타 표준의 준수를 보장할 수 있는 동기화 시스템을 구성하기로 하였습니다. 먼저, 야간에 수행되는 작업을 통해 “동기화된” 데이타의 복제본이 중앙 데이타베이스에서 Companion 애플리케이션으로 전달됩니다. Companion 애플리케이션의 모듈은 동기화된 테이블을 적극적으로 활용합니다. 하지만 이 모듈들이 테이블을 업데이트하지는 않습니다. 발생된 업데이트는 “holding” 테이블에 보관되며, 관리자는 별도로 설계된 클라이언트/서버 인터페이스를 통해 holding 테이블의 데이타를 꼼꼼하게 편집합니다. 데이타의 표준 준수 여부가 확인되고 난 뒤에는 업데이트된 데이타가 다시 중앙 데이타베이스로 전달됩니다. 중앙 데이타베이스와 Companion 데이타베이스의 모든 로우는 타임스탬프 정보를 포함하고 있습니다. 다른 시점의 데이타가 서로 충돌하는 경우, 이를 관리하기 위한 프로그램이 동작합니다. 따라서 번거로운 수작업을 거치지 않고도 정확한 최신 데이타를 중앙 데이타베이스에 입력할 수 있게 됩니다. Companion 데이타베이스는 외부 데이타베이스의 필드와 데이타를 차용한 형태로 구현되었습니다. Companion 데이타베이스에 존재하는 모든 필드 명에는 소스 데이타베이스를 의미하는 1자 단위의 코드가 부여됩니다. 이처럼 모든 테이블의 모든 필드에 데이타 소스를 명시함으로써, 동기화 과정에서 발생할 수 있는 문제의 가능성을 최소화 하였습니다.
프로젝트의 교훈과 개발자를 위한 조언 Kardasz의 팀이 이번 프로젝트를 통해 얻은 교훈이 다음과 같습니다: • 코딩 표준 (Coding standards): 코드의 구조, 필드의 명명 규칙, 테이블의 명명 규칙 등을 명시한 스타일 가이드(style guide)와 포맷(format)을 미리 준비하는 경우 프로그래머들에게 크게 도움이 될 수 있습니다. • 코멘트 (Comments): 데이타베이스의 모든 필드와 테이블에 코멘트를 삽입하는 것이 가능합니다. TOAD (http://www.qsft.com/toad/) 와 같은 툴은 코멘트 정보를 포함하는 데이타 딕셔너리 리포트를 생성하는 기능을 제공합니다. McGill University도 처음부터 이런 방법을 썼던 것은 아니며, 뒤늦게 코멘트를 삽입하느라 많은 수고를 들이기도 했습니다. 프로젝트가 진행되다 보면, 프로그래머의 기억력의 한계를 절감하는 일이 반드시 생기게 됩니다. • 쓰레드 (Threads): Oracle Multithreaded Session Handling은 concurrent session 환경에 비해 나은 성능을 제공합니다. • 로우 레벨 보안 (Row-level security): 테이블과 애플리케이션 코드를 이용하여 로우 레벨 보안 환경을 구현하면 작업이 쉬울 뿐 아니라 직관적이기도 합니다. 이 경우, 각각의 로우에 대응되는 보안 속성(security attribute)이 다른 테이블에 저장되어 관리됩니다. 하지만 이와 같은 애플리케이션 레벨 보안 환경은 성능 상의 문제를 일으킬 가능성이 높습니다. 성능과 확장성을 보장하려면, (배우기 쉽지 않은 기술이긴 하지만) Oracle9i의 Fine-Grain Access Control과 Virtual Private Database 테크놀로지를 이용하는 것이 바람직합니다. • 팀의 규모와 Extreme Programming: 우리는 “Extreme Programming” 접근 방식으로 프로젝트를 시작했습니다. 나중에 우리가 깨닫게 된 것은, 아무리 작은 규모의 프로그래머 집단이라 하더라도 (우리 팀의 경우 프로그래머의 수는 단 세 명에 불과했습니다), 역할, 책임, 전문 영역이 명확하게 정의되어 있어야 한다는 사실이었습니다. 우리 조직 내의 DBA 전문가와 네트워킹 전문가, 그리고 중앙 데이타베이스를 담당하는 오라클 프로그래머의 지원이 없었다면 프로젝트는 성공하지 못했을 것입니다. • QA (Quality assurance): 리소스 문제로, 우리는 프로젝트의 QA를 전담할 테스터를 고용하지 못했습니다. 그 대신, 우리는 다양한 IT 전문인력과 비전문인력을 통해 피드백을 전달받는 방법을 사용했습니다. 이러한 “자원봉사” 형태의 테스트 작업은 그리 효율적이지 못했습니다. 버그와 누락된 기능을 발견하기까지 많은 시간이 걸렸고, 디버깅 작업도 예상했던 것보다 오래 걸릴 수 밖에 없었습니다. • Copy server: 우리는 테스트 서버(웹 서버와 Oracle9i 서버)와 별도로 Oracle 9i copy server를 관리하였습니다. Copy server의 데이타는 매 24시간 간격으로 운영 서버로부터 업데이트됩니다. Copy server는 백업 서버로 활용되었습니다. Copy server를 이용하여 파일과 데이타를 복구하는 작업은 무척 쉽고 간단했으며, 개발자들의 반응도 좋았습니다. 또 유사시 copy server를 운영 서버를 대체하는 시스템으로 활용할 수도 있었습니다. 때로는 테스트 데이타베이스 서버의 변경사항을 copy server에 먼저 포팅하여 테스트 과정을 거친 다음에 운영 서버에 업로드하는 경우도 있었습니다. 우리 팀은 현재 Oracle Standby 데이타베이스를 이용하여 무중단 환경을 구현하는 방안을 검토하고 있습니다. • 백업 (Backups): 우리는 고전적인 형태의 테이프 백업 시스템과 소산 보관 정책을 사용하고 있습니다. 하지만 백업 테이프는 다루기 까다롭고, 에러율이 높으며, 복구에도 오랜 시간이 걸린다는 문제가 있습니다. 그래서 우리는 Oracle9i 데이타베이스와 웹 서버 파일을 다른 서버의 디스크 드라이브에 덤프하는 방법을 적용하였습니다. 일 단위 백업은 1주일간 보존되며, 주 단위 백업은 1개월간 보존됩니다. • 리소스 할당 (Resource Allocation): PHP 및 PL/SQL 프로그래밍에 소요된 시간은 전체 프로젝트 시간의 22% 정도에 불과합니다. 이것은 PHP와 PL/SQL이 제공하는 비용 절감 효과를 증명하는 결과이기도 합니다. 그림 6은 프로젝트의 작업별 소요시간 통계를 보여주고 있습니다.
이 문서에서 소개한 개발 모델을 사용하는 경우, 확장성의 한계는 실로 무한하다고 할 수 있을 것입니다. 이 문서에서 제시한 모델은 동기화된 데이타와 멀티-티어 애플리케이션 구조, 독립적으로 개발된 모듈, 모듈의 프레임워크로 활용되는 핵심 보안 컴포넌트, 오라클 보안 기능(FGAC 등), 그리고 신속하고 안정적인 PHP 프로그래밍 환경을 활용하고 있습니다. 우리는 중앙 데이타베이스의 정확도를 보장하는 한편으로, 별도의 코딩 작업 없이 새로운 모듈을 추가함으로써 사용자에게 새로운 기능을 신속하게 제공할 수 있는 환경을 구현하였습니다. 가장 중요한 사실은 사용자와 기술지원 담당자가 새로운 환경을 매우 만족스럽게 평가한다는 것입니다. | |||||||||||||||
'php' 카테고리의 다른 글
| 히치하이커를 위한 PHP 가이드 ⑤ : 오라클/PHP 환경의 확장 (0) | 2007.05.03 |
|---|---|
| 히치하이커를 위한 PHP 가이드 ④ : PHP, 어른이 되다 (0) | 2007.05.03 |
| 히치하이커를 위한 PHP 가이드 ② : PHP를 이용한 개발 기간의 단축 (0) | 2007.05.03 |
| 히치하이커를 위한 PHP 가이드 ① : PHP 하십니까 (0) | 2007.05.03 |
| 웹 프로그래밍 언어 php의 새로운 도전「php5」 (0) | 2007.05.03 |