OracleAS 10g: 웹캐쉬 설정및성능 - DBGuide.net · 2004-10-04 · 하지만9.0.4에서는httpd.conf의OssoSendCacheHeaders parameter를off 시켜놓을수있게함으로써,

OracleAS 10g WebCache config. & perf.

1OracleAS10g: WebCache Config. & Perf. 기술적인 질문은 채팅으로 등록

심원보

한국오라클 (주) 제품지원실

Getting the most out of MetaLink

OracleAS 10g: 웹캐쉬설정및성능

오늘은 OracleAS10g의 핵심 컴포넌트 중의 하나의 Oracle WebCache에 대해서 알아봅니다.

기존 버전에서 별개의 구성요소로서 다루어졌던 Oracle WebCache가, ORACLE AS 10g 버전에서는완전하게 built-in component로서의 모습을 갖추었으며, 더욱 세련된 기능을 보여주고 있습니다.

그 기능들을 살펴보고, 현실적인 문제 상황들에 대해 WebCache가 어떻게 설정되고 활용될 수 있는 지알아보겠습니다.



WebCache 개요

새로운 기능 및 설정

Scenario in the real world성능

참고 자료

목차

다음과 같은 순서로 진행합니다.

1. WebCache 개요

2. OracleAS 10g에서의 새로운 기능 소개

3. 현실적인 상황에 대한 WebCache의 설정 방법

4. 성능

5. 참고 자료



WebCache 개요

Origin server와 client 사이에 존재

Improve performance, scalability, & availability• 서비스할 페이지 전체 또는 그 일부를 메모리에 저장

• web application의 서비스 가속

• Origin server의 부하를 줄여줌

Webcache에 대해서는 여러 번 들어보셨을 겁니다.

간단하게 정의하자면, 실제 web service를 담당하는 web server의 앞 단에 위치하면서 자주 service가 되었던 web application의 내용이 caching 되어 있다가 동일 페이지에 대한 client의 요청이 있을 경우 굳이 실제 서비스를담당하는 web server단까지 request를 보낼 필요 없이 Caching된 정보를 보내 줌으로써 보다 빠르게 client browser의 요청에 응답할 수 있도록 해주는 software입니다.

실제 web service를 담당하는 web server를 지금부터는 ‘origin server’라 부르겠습니다.

그래서 webcache를 사용하실 경우, origin server 단독으로 service를 할 때보다 훨씬 많은 유연성과 가용성, 확장성, 그리고 성능 향상을 기대할 수 있습니다.

Webcache는 origin server가 서비스할 페이지의 전체 또는 그 일부를 자신의 memory에 저장합니다. 그럼으로써훨씬 빠른 응답속도를 보여주며, origin server의 부하를 줄여주는 효과도 있습니다. 아울러 origin server의 임의의downtime때도 웹서비스는 계속 되는 것처럼 보일 수 있습니다. 또한 origin server와 별개의 장비에 위치시킬 수있으며, webcache끼리도 cluster를 구성 함으로써, origin server 단독으로 사용하실 때보다 전체적으로 보다 더유연한 웹서비스 시스템을 구현할 수 있습니다.



How webcache works

If (cached object available)• (1) -> (2)

Else• (1) -> (3) -> (5) -> (6) -> (7)• (6): Now! the requested object available

Webcache가 어떻게 동작하는 지 알아봅니다. 그림을 보십시오.

(1) Client sends HTTP request

(2) Web Cache responds immediately if cached object is available

(3) If object is not in cache, Web Cache requests object from Application Server

(4) Application Server generates response (may include Database queries)

(5) Application Server responds to Web Cache

(6) If response is cacheable, Web Cache retains a copy for subsequent requests

(7) Web Cache compresses page and responds to Client



Key features of webcache 9.0.2

• Full-page Caching with Simple Personalization• Partial-page Caching and Personalized Content Assembly (ESI)• Invalidation and Performance Assurance Heuristics• Automatic Content Compression• Web Server Load Balancing and Failover• Cache Clustering• Hierarchical / Distributed Caching and Page Assembly (eCDN)• XSL/T for post-processing of XML content• Integrated with Oracle Tech Stack: 9iAS, 9iDB, 11i E-Business

Suite• Compatible with 3rd-party application servers and databases

9iAS release2에서의 webcache의 기능들을 소개합니다.

뒤에서 언급될 OracleAS 10g webcahce의 새로운 또는 보강된 기능들과 비교하기 위해 여기에 미리 열거했습니다.



새로운 기능

New features area• Usability & Manageability • Logging• Security • Caching, Content Invalidation & Compression• High Availability• Diagnostics

Oracle AS 10g 버전에서 새로운 기능들을 category별로 분류하면 보시는 바와 같습니다. 지금부터 각 기능들을살펴보겠습니다.


OracleAS10g: WebCache Config. & Perf. 기술적인 질문은 채팅으로 등록

Usability & Manageability

먼저 사용성 및 관리적 측면을 살펴보겠습니다.



configuration

http://<hostname>:4003/webcacheadmin

dynamic configuration• no rebooting is necessary• 현재 caching돼있는 것 보존

Opmn support• Managed by Opmn• Opmnctl start/stop process-type=WebCacheAdmin• Opmnctl start/stop process-type=WebCache

Webcache의 설정 사항들을 확인하고 변경, 추가 설정하실 때 webcache의 admin page를 활용하시게 됩니다.

Default port로 4003 로 접속하시면 기본 페이지가 나오고 Administrator로 login을 하시면 설정화면이 나옵니다.

Administrator의 password는 OracleAS 10g install하실 때 ‘ias_admin’에 주었던 password와 동일합니다.

이전 버전은 모두 똑같은 id , 즉 administrator가 default password 입니다.

설정 화면의 곳곳에 이 ‘반시계방향의 동그란 화살표에 별(*)표가 있는’ 문양이 붙어있는 설정변수가 있습니다.

‘dynamic configuration’이 가능하다는 표시로, 설정 변경 완료 후 webcache를 re-start하지 않으셔도 변경사항을적용됩니다.

기본적으로 webcache는 restart를 하시면 현재 caching돼 있는 내용들은 모두 없어집니다.

‘dynamic configuration’는 가급적 이것을 막기 위한 것으로, 모든 설정 변수가 ‘dynamic configuration’이가능하지는 않습니다.

OracleAS 10g의 경우 opmnctl 명령어로 webcache의 구동을 제어하게 되었습니다.

opmnctl start/stop process-type=WebCacheAdmin

또는

opmnctl start/stop process-type=WebCache

Process-type은 대소문자 구분을 함으로 주의하시기 바랍니다.

참고) Opmnctl start/stop ias-component=WebCache

물론 webcache를 standalone으로 install할 수 있으며, 이 경우는 기존대로 webcachectl 및 watchdog process의관리를 사용합니다.



Site discovery

• Site Discovery is a new feature that populates site definitions from the virtual host configuration of Oracle HTTP Servers

• Quick way to define sites

Site Discovery menu를 통해 webcache의 site definition을 쉽게 할 수 있습니다.

이 기능을 통해, origin server (OHS)에 설정된 virtual host에 대해서 hostname:port에 대한 정보를 자동으로 모을수 있으므로, site 정의를 쉽고 빠르게 할 수 있습니다.



End-User Performance Monitoring

• Real time rendering in the user’s browser

• Capture real end-user response time

• Measure response times for the entire web application

End-User Performance Monitoring 기능을 통해, 사용자의 관점에서 해당 web service의 성능이 어느 정도인지파악할 수 있습니다.

이것은 기존 방식, 즉 몇몇 url에 대한 stress test에서 얻어낸 performance 분석과는 전혀 다른 것입니다.

관심 대상의 site를 사용자가 마치 실제로 그 web service를 이용하는 것처럼 쭉 브라우징을 하게 되고, 그 대상url에 대해 주어진 시간동안 실제 서비스 중에 성능지표 데이터들을 수집하게 됩니다.

End-User Performance Monitoring 기능은, 또한, 특정 end-user가 경험하는 performance를 그대로 tracking할수 있습니다. (생각해 보십시오. 여러분의 사장님이 여러분이 개발하고 구현한 web service를 browsing하며, 시연해보고 있다고 말입니다.)

수집된 결과는 OEM의 Application Performance Monitoring (APM) 기능을 통해 분석을 합니다.

참고로 위의 그림은 Enterprise Manager를 보여주고 있으며, OEM은 10g 버전에서는 Grid Control 이라 부릅니다.



Logging & Security

Logging 및 보안 측면을 보겠습니다.



Logging

• Access log & event log• Rollover• User-defined format (supporting XLF, CLF) for access log• 4 levels of verbosity for event log

9.0.4 버전에서는 log 파일을 rollover시킬 수 있습니다.

Dl 기능은 Log file 하나에 계속 access 또는 event log가 쌓여 너무 커지는 것을 방지할 수 있습니다.

Rollover의 주기를 주간별, 일별, 시간별로 정할 수 있습니다.

Access log의 format을 사용자가 지정할 수 있으며, CLF 및 XLF 모두 지원합니다.

보다 자세한 reporting을 위해 관리자는 저수준을 data들이 logging되도록 ‘사용자 정의 log format’을 만들 수도있습니다.

Evnet log은 webcache의 error log에 해당하는 것입니다. 이것도 4가지 수준의 log level로 조정할 수 있습니다.



Security

Security• SSO

• Client-side certificate support• nCipher SSL Acceleration Hardware Support

Security issue때문에 webcache의 기존 버전에서는 user authentication에 관련된 single-sign-on page들은cache를 하지 않는 것이 기본 이었습니다.

하지만 9.0.4에서는 httpd.conf의 OssoSendCacheHeaders parameter를 off 시켜놓을 수 있게 함으로써, OHS의mod_osso에 non-cacheable 속성을 무시하고 cache에 대한 책임을 web application에게 부여할 수 있게 합니다.

그리고 9.0.4 버전부터는 PKI기반의 SSL인증에 대해서도 webcache가 지원을 합니다.

nCipper와 같은 SSL가속기와도 함께 쓰일 수 있으며, 이 경우 SSL handshake 과정 동안의 web application의성능을 높일 수 있습니다.



Secutiry

WebCache configuration w/ SSL• See the notes

– Note.250648.1 Configuring Web Cache with SSL in Oracle Application Server 10G (9.0.4)

– Note.250800.1 Configuring SSL Client Authentication with Web Cache in Oracle Application Server 10G (9.0.4)

Security alert• See the notes

– Note.265308.1 Security Alert 66 Security Vulnerabilities in OracleAS Web Cache 10g and Oracle9iAS Web Cache

– Note.265310.1 Security Alert 66 Patch Availability Matrix

SSL과 관련한 webcache설정방법에 대한 문서를 소개 드립니다.

아울러 security 취약성에 관한 alert 문서도 함께 참조하시고 patch를 적용하시는 것이 좋겠습니다.



Caching, Invalidation & Compression

Caching, invalidation, 그리고 compression 측면을 살펴보겠습니다.

Invalidation은 사실상 webcache의 꽃이자 핵심이라고 할 수 있습니다.



Disconnection to origin server

• “Disconnect”from the origin servers dynamically, serving only pages only from the cache.

• Useful when Origin Server is stopped due to maintenance

Web page의 주요부분이 caching돼 있을 경우, Maintenance를 위해 origin server를 내려놓더라도 webcache를외부적으로는 web service를 계속 할 수 있습니다.

설정 page에서 Routing 을 disable시켜놓으면, 외부 request를 origin sever에 forwarding하지 않습니다.



Partial-Page Caching & Content Assembly

Edge Side Includes (ESI)• an XML-like markup language used to define cacheable and

non-cacheable content fragments• a content invalidation protocol for cache consistency

Edge Side Includes for Java (JESI)• a custom tag library to facilitate the use of ESI with JSP

applications

ESI, 즉 Edge Side Includes는 page assembly를 위한 표준Tag입니다. ESI를 통해 page내 조각들을 어떻게 조합해서보여줄 지를 지정합니다.

이를 위해 해당 page에 설정된 esi를 읽고 가공해낼 수 있는 engine이 필요합니다. Akamai, Oracle, IBM, BEA, NetApp 등과 같은 회사가 ESI를 지원하고 있습니다.

ESI는 xml과 비슷한 구조의 markup language로서, content조각들의 caching가능 여부를 지정하는데 사용합니다. ESI는 cache consistency를 위한 산업 표준규약 입니다.

Jsp에서 ESI tag를 쓸 수 있도록 한 것이 ‘제시(jesi)’입니다.



ESI Development Model

Divide Full Pages into Templates and Fragments

ESI 개발 모델의 개념은 매우 단순합니다.

ESI tag를 통해 표시하고자 하는 전체 page를, 내용이 변하지 않는 content template과 내용이변하는 content fragment로 나누도록 지정합니다.

이런 ESI tag가 담겨진 내용은 esi parsing engine에 보내져, content template만 caching되고나머지 부분들은 content fragment들의 조합으로 전체 page가 표시되는 것입니다.

Oracle AS10g webcache 자체가 이런 esi tag를 해석할 수 있는 engine을 담고 있습니다.



ESI Inline Tag

<html>...<esi:inline name=”/news101”><table>...</table></esi:inline>...</html>

/news101 Template/sample.html

/sample.html

Cache Storage

Page Assembly

Cache Response

Partial caching과 관련해, 대표적인 ESI tag 두개만 살펴봅니다.

Esi:inline tag는 html source의 body부분에 partial caching될 page내용을 그대로 적습니다.

Syntax:<esi:inline name=“URL” fetchable=“yes|no”[max-age=“expiration_time [+ removal_time]”] [timeout=“fetch_time”]

Embedded HTML code</esi:inline>

•name

specifies a unique name for the fragment in URL format

•fetchable

“yes” specifies that the URL can be used to independently fetch the fragment. “no” specifies that the fragment can only be generated as a response for another object.

•max-age

specifes expiration time. Specifing removal time is optional. Use this attribute if the template page has a higher tolerance for stale fragments than specified by the time-to-live parameters in fragment responses.

•timeout

specifies the time, in seconds, for the fragment to be fetched. If the fragment has not been fetched within the time interval, the fetch is aborted.



ESI Include Tag

<html>...<esi:include src=”/news101”>...</html>

/news101 Template

/sample.html (template)

/sample.html

Cache Storage

Page Assembly

Cache Response<table>...</table>

/news101

이에 반해 esi:include tag는 partial cache content내용에 대해 link만을 만들어 줍니다.



Surrogate-Control Response Header

Allows origin servers to dictate how surrogates should handle entities, with control directives

Format• Surrogate-Control:control_directive,

control_directiveDirectives

• max-age• content “ORAESI/9.0.2”• no-store• no-store-remote• vary (Oracle’s extension)

Examples• Surrogate-Control: max-age=30+60,

content=“ESI/1.0”, vary=headers(Accept-language); cookies(NEWS sports)

• Origin server encodes cacheabilitypolicies in response headers

• Content is “self-describing”

• Overrides configured cacheabilityrules

Surrogate-control header정보를 통해, 관리자가 webcache admin page에서 설정한 caching rule보다 우선해서 해당 content의 caching여부를 지정할 수 있습니다. 이것은 response header에적으며, 해당 object의 caching가능 여부 및 유효기간 등을 지정합니다.

Surrogate-control은 web application에 적는 내용으로서 web service 개발자의 몫입니다.

Using the directives, the developer can specify the caching policy within the content. The surrogate-control will override any cacheabiliy rules that a network administrator enters in the Web Cache administrative console.

The no-store directive specifies that the response entity should not be stored in cache; it is only to be used for the original request, and may not be validated on the origin server.

The no-store-remote directive has similar semantics to the no-store directive, except that it should only be honored by those surrogates that consider themselves "remote". Generally, this means those that are more than one or two hops from the origin server, such as surrogates in a CDN.

max-age=expiration_time [+removal_time]

Removal time is optional. max-age=infinity means the document never expires.

The vary directive specifies the HTTP request headers or category cookies from which Oracle9iAS Web Cache will use to cache and identify multiple-version documents.

vary=headers(header header …); cookies(cookie_name cookie_name …)

header is not case sensitive

cookie_name is case sensitive



Partical page caching

http://url…/greeting.html?p_name=홍길동

• Without personalization

• 예)

Partial page caching의 이해를 돕기 위해 여기서는 간단한 예제를 통해 알아봅니다.

어떤 홈페이지에 login을 할 경우, 대개 사용자의 이름과 같은 개인화된 정보를 표시해주는 페이지가 많습니다.

이런 개인화된 정보는 각 사용자마다 다르므로, session에 따라서 다른 이름을 표시해주어야 합니다.

문제는 오히려 이런 개인화된 정보마저 caching을 해버릴 경우입니다.



Partical page caching - solving

Do not cache a part of personalization• By caching rule, policy

• Using the ‘surrogate-control’

해결 방법은 간단합니다.

즉, 사용자 이름을 제외한 나머지 부분만 caching을 하는 것입니다. 크게 두 가지 방법을 제공하는데,

1. webcache manager에서 caching rule을 설정하는 방법

2. http response hearder에 surrogate-control이라는 것을 설정하는 방법

이 예제에서 보면, p_name이라는 session정보에 대해서는 caching하지 않도록 지정합니다.

Webcachetag를 쓸 경우는 지정한 session정보에 대해 webcache의 admin page에서 관리자가 caching rule을만들어줘야 합니다.

ESI tag를 쓸 경우, 이는 개발자에게 현재의 content에 대한 caching여부를 결정하도록 맡기는 것입니다.

만일 전부 설정이 돼 있을 경우, surrogate-control이 우선합니다, 즉 관리자가 설정한 caching rule및 policy를overriding해버립니다.



Partial-Page Caching Advantages

Increase Content Sharing

Reduce Space Requirement

Reduce Cache Update Frequency• Update when the template changes• Update when a fragment changes• Do NOT update when shared fragments have already

been updated

Result: Increase Cache-Hit Ratio

Partial page caching의 장점으로는, 적어도 template에 관한 content는 caching후 바뀌지 않을 것이므로 sharing 할 수 있으며, 그만큼 webcache의 메모리 부담을 줄일 수 있습니다.

그리고 cache를 update해야 하는 부담도 줄입니다. 전체적으로는 cache-hit ratio가 높아지며, 이는 곧webcache가 본연의 성능을 발휘하고 있음을 나타내는 지표입니다.



Staying Fresh with InvalidationTrigger / Programmatic

Programmatic

Admin Console

Manual or Scripted

DatabaseClient

Browsers

Web App ServerWeb Cache

Consistency Management Mechanisms:• Expiration Policies (for predictable changes)• Invalidation Messages (for unpredictable changes)

– Scope: fine-grained or broad; support for application-specified Search Keys– Effect: remove immediately or specify a refresh grace period– Format: XML over HTTP (Java and PL/SQL APIs provided)

Webcache를 사용할 경우, content를 저장해두는 것 만큼이나 중요한 것이, 그 content를 최신의 내용으로 갱신시키는 것입니다.

사용자의 요청이나 트랜잭션에 따라 현재 caching돼 있는 content 정보가 가장 최신의 것으로 변경되어사용자에게 보여져야 할 경우가 있습니다. 즉, 현재 caching돼있는 content들을 무효화 시키고 저장된 메모리에서밀어내는 것입니다. 이것이 바로 invalidation입니다.

이와 같이 content의 일관성을 유지하는 방법은 크게 두가지 입니다.

•Expire Policies

•Invalidation Messages

Content의 변경 시점을 예측할 수 있는 경우는 ‘content의 유효기간을 정하는 방식’이 있습니다.

그러나 content의 변경 시점을 예측할 수 없는 경우는 명시적으로 ‘invalidation message’를 webcache에게 보내는방법이 있습니다.

Invalidating message는 관리자가 직접 webcache manager를 통해 HTTP POST 방식으로 보낼 수도 있고, 개발자가 web application의 소스에서 invalidation 부분을 미리 지정할 수도 있습니다.

어느 것이든 invalidating message는 <esi:invalidate> tag를 포함한 xml문서 형태입니다.



Inline Invalidation

Control content invalidation using ESI tagsUseful for origin server to “piggyback” invalidation messages with the transactional responses sent to Web CacheEmbed the invalidation message inside the <esi: invalidate> tagsReduce overheads incurred during invalidation

Web Cache 9.0.4 는 inline invalidation이 가능하도록 <esi:invalidate> tag를 제공합니다.

<esi:invalidate>는 개발자가 content invalidation을 좀더 세밀하게 제어할 수 있게 해줍니다.

즉, HTML output내에 esi tag 및 invalidating content내용을 바로 적습니다.

이때 <esi:invalidate> tag는 전체 page의 갱신이 아닌 page내 특정 page 조각(fragment)만을갱신할 수 있게 해 줍니다.



Example of an Inline Invalidation

Show_bike.pl

buy_bike.pl

Inline Invalidation의 예를 보도록 하겠습니다.

response header에, "Surrogate-Control“을 추가합니다.

그리고 같은 response의 body부분에 <esi:invalidate>를 추가하여 inline invalidation request를지정합니다.

<esi:invalidate> ... </esi:invalidate> 사이에 실제 invalidation message가 옵니다.

Invalidation message는 앞에서 말씀 드렸듯이 xml문서 형태입니다.

ESI template의 어떤 곳이든 inline invalidation request를 삽입할 수 있으며, 다른 ESI feature들이 그template에 포함되었더라도 inline invalidation이 가장 먼저 Parsing되고 실행됩니다.

어떻게 실행될 지 봅시다.

어떤 사람이 자전거를 하나 사려고 이 웹사이트에 접속했다고 가정해보죠. 처음에 show_bike.pl이뿌려주는 page내용을 보게 됩니다. Show_bike.pl page는 업무Logic상 DB에 접속해서, 현재자전거의 재고 상황을 보여줍니다. 이 사람이 buy_bike.pl을 접속할 때마다 show_bike.pl은invalidating되어서, 가장 최신의 재고 현황을 보여줄 수 있게 됩니다.



Support for Invalidation Search Keys

Specify a search key for easy invalidation in the HTTP response header

• surrogate-key: search-key =(“key” “key” …)• Give administrators and developers finer control over

what to invalidate• The search key(s) are dynamically specified in a

response header returned from the origin server and stored in Web Cache

• Search keys relate to a set of URLs

The invalidation message will contain the search key inside the <AdvancedSelector> DTD. For example:

Search key(s)는 page set을 위한 식별자입니다.

이것은 web application 개발자들이 logical “type”에 따라 cached object들을 쉽게 grouping할 수있게 해줍니다.

Search key(s)는 origin server로부터 return돼온 response header에 동적으로 지정되며, webcache내에 저장됩니다.

Search key를 통해 invalidating될 때, 같은 search key set을 가진 모든 document는invalidated됩니다.

Search key를 여러 개 지정할 수 있으며, Default로 하나의 object당 20개의 search key까지가능하며 limit은 webcache.xml에서 설정할 수 있습니다.

그리고 invalidation message는 dtd의 <advancedselector> element 내 search key를 포함합니다.

For example:

<ADVANCEDSELECTOR URIPREFIX="/cgi-bin/" HOST="dlsun1270.us.oracle.com:1100">

<OTHER NAME="SEARCHKEY" TYPE="SUBSTRING" VALUE="key1"/>

<OTHER NAME="SEARCHKEY" TYPE="SUBSTRING" VALUE="key2"/>

</ADVANCEDSELECTOR>

• $ORACLE_HOME/webcache/toolkit/ WCSinvalidation.dtd 내에 <advancedselector> 가 있습니다.

<!ELEMENT ADVANCEDSELECTOR (COOKIE|HEADER|OTHER)*>

<!ATTLIST ADVANCEDSELECTOR

URIPREFIX CDATA #REQUIRED

HOST CDATA #IMPLIED

URIEXP CDATA #IMPLIED

METHOD CDATA #IMPLIED

BODYEXP CDATA #IMPLIED

>



Compression Enhancements

Self-describing compression policies within surrogate-control header

• For example:Surrogate-Control: max-age=30+60,content=”ORAESI/9.0.2”, compress=yes

Compression of documents that require parsing and processing

• session-encoded URLs • ESI tags•  tags

Webcache admin에서 compression option을 설정할 수 있습니다.

9.0.4에서는 web application 개발자가 이 option을 ‘surrogate-control’ response header에 직접설정할 수 있도록 함으로써, 개별 content에 대한 compression 정책을 보다 유연하게 지정할 수있습니다.

그리고 session-encoded url, esi tag, webcache tag 등을 포함하는 parsing및 processing이필요한 문서도, 압축이 가능합니다.



High Availability

Webcache의 가용성 부분을 한번 살펴보겠습니다.



Session Binding in Web Cache Cluster

Oracle9iASWeb Cache

Web App Servers

Database

HTTP/HTTPS HTTP/HTTPS

Session A

Session A

request

COOKIE:

Session managed by OS2

OS1OS1

OS2OS2

OS3OS3• Session definition• Session binding setting

Session Binding이란 session id또는 session cookie를 가지고 요청된 session에 대해 다시 특정origin server에 할당해주는 것을 말합니다.

Webcache는 embeded url parameter나 cookie를 통해, session binding을 지원합니다. Session binding은 궁극적으로 stateful load balancing을 의미합니다.

그림에서 최초 request가 들어왔을 때, webcache는 load balancing에 의해 특정 origin server에해당 request를 forwarding합니다.

Origin server는 session binding이 필요할 경우 session 정보를 심어, webcache를 통해, client에게응답을 줍니다.

Client는 두번째 요청부터는 session정보를 담아 webcahce에게 요청하고, webcache는session정보를 보고 특정 origin server에 해당 session의 요청을 전달할 수 있게 됩니다.

이를 위해 webcache단에서는 두가지를 정의해야 합니다.

첫째, session cookie나 embeded url parameter에 쓰일 이름을 정의합니다.

둘째, session binding 설정을 합니다.



Session Binding in Web Cache Cluster

Oracle9iASWeb Cache

Web App Servers

Database

HTTP/HTTPS HTTP/HTTPS

Session A

request

COOKIE:COOKIE:

Session managed by Session managed by OS2OS2

COOKIE:COOKIE:

Session managed by OS2Session managed by OS2

Webcache clustering은 여러 개의 webcache를 cluster로 묶음으로써, 논리적으로 하나의 logical cache처럼 동작하게 합니다.

Cluster member들은 서로 서로 failure detection 과 failover 기능을 수행 함으로써 webcache의전체적인 가용성을 높여줍니다.

또한 더 많은 content를 caching할 수 있어서, 더 많은 client로 부터 요청을 수용할 수 있습니다.

Webcache cluster를 위해 모든 cluster member는 origin server에 대한 session binding 설정도같은 구성을 가져야 합니다. 이 경우 반드시 ‘session binding cookie’를 enable로 설정하셔야 합니다.

그림에서 보듯이 cluster 내 다른 webcache에 의해서도, 특정session에서 요청된 request가 origin server에 올바르게 forwarding됩니다. 이 경우 load balancing은 하지 않습니다.



Support for OS Network Load Balancing

Configuring Web Cache cluster for high availabilityUsing network load-balancing capability provided by the

operating system to do IP takeover instead of hardware load balancer

Support for Windows, Linux

Oracle9iAS Web CacheCluster

Web App Servers

DatabaseClient

Browser

NetworkHTTP/HTTPS HTTP/HTTPS

고가의 Hardware load balancer를 사용하지 않고도 중간 정도 볼륨(mid-size)의 web application service를 구현할 경우, 몇몇 os는 ip takeover기능을 제공하며, 이런 os의 network load balancing을 webcache와 함께 사용할 수 있습니다.

현재 9.0.4 버전에는 windows의 network load balancing을 지원하고 있습니다.



Diagnostics

Caching되고 서비스되는 content, object들에 대한 진단 기능을 살펴보겠습니다.



WCDEBUG

WCDEBUG shows diagnostics information – e.g. cacheability of the page and expiration time of the page

http://www.oracle.com/index.htm?+wcdebug

Webcache의 diagnostic기능을 통해, 현재 요청된 content에 대한 cached 정보를 볼 수 있습니다.

설정방법은 webcache.xml에서 직접 수정할 수도 있고, webcache admin page를 수정할 수도 있습니다.

Diagnostics in Page Body = Enabled, Display Event Log Entries for Request = Yes일 경우, 요청하는 url에‘+wcdebug’ 문자열 값을 덧붙이게 되면, browser상단에 event log내용이 표시됩니다.

<<manual하게 수정하는 방법>>

WCDEBUG must be enabled in webcache.xml:

- When WCDEBUGON is YES and EVENTLOG is YES, event log lines are added to the bottom of response body. (EVENTLOG="YES" is valid only when WCDEBUGON="YES".)

- SWITCHSTRING attribute is the string which is added to the end of URL to trigger the debug mode for the request.

To produce the wcdebug output, the SWITCHSTRING attribute must be appended to the URL:

- http://www.oracle.com/i.htm?+MyOwnWCDebugString



Pain Points

현실적인 문제로서 Performance, Availability, Manageability, Increase revenues & decrease costs 등 많은 애로사항들이 있습니다.

Webcache를 사용함으로써 어떻게 이런 문제들을 극복할 수 있는 지 알아보겠습니다.

사실 이 내용들은 앞에서 설명 드린 webcache의 여러 기능들을 어느 상황에서 활용할 수 있는 지에 대한 좋은지침이 될 것입니다.



Repetitive requests

Static content caching

비교적 volumn이 크지만 반복적으로 요청되는 정적인 content들, 즉 gif와 같은 이미지 파일 들, pdf 및 html, flash파일 등은 모두 webcache에 미리 올려둡니다.

이런 정적인 page들에 대한 caching설정은 매우 간단하며, performance 향상 또한 대단히 효과적입니다.



Illegitimate request

Caching non-200 http response

Worm attack과 같은 바이러스성 공격이나 악의적인 반복 호출에 대해, origin server가 반응하는 것을 사전에막아주고 error page를 미리 caching해둠으로써 이런 악의성 요청에 대응할 수 있습니다.



Dynamic contents

Dynamic content caching

Jsp와 같은 dynamic contents도 webcache에 저장이 가능합니다.



Highly personalized content

Partial page caching• Industry standard markup language is Edge Side Includes

(ESI)• WebCache is an ESI processor

Page전체를 caching했을 경우 오히려 문제가 생길 수 있습니다. 예를 들어 login한 사용자 각자에게 그 사람에특화된 개인정보를 page의 일부에서는 보여줘야 하는 경우가 그렇습니다.

이때는 ESI라는 markup language를 통해, 서비스할 page의 일부만이 caching되도록 지정할 수 있습니다.

이런 markup language를 해석할 수 있는 엔진이 필요한데 Oracle AS 10g webcache 자체가 ESI processor입니다.

따라서 Alkamai와 같은 edge network 기술을 지원하는 product이 따로 필요하지 않습니다.



Invalidation a group of related pages

Surrogate-key• A search-key: invalidation area

어떤 한 정보에 대해 여러 page들이 caching을 하고 있을 때, 그 정보가 변경될 경우 그에 관련된 모든 page들을cache에서 밀어내고 무효화해주어야 합니다.

이 경우 모든 page들에 대해 한번에 invalidation시켜줄 수 있는 기술로서 surrogate-key의 ‘search-key’를사용하시면 됩니다.



Low-bandwidth or lots of traffic

Automatic compression

물리적인 network bandwidth 한계나 많은 network traffic으로 인해 응답 속도가 느릴 경우, webcache의compression기능은 도움이 됩니다.

Webcache는 메모리에 저장된 content들을 gzip형태로 자동 압축하여 내려 보냅니다.



Via the 3rd party analyzer

logging

Web server의 access log 분석 툴을 3rd vendor제품을 사용하는 경우, 이때 log 분석 툴마다 요구하는 여러 log format 다를 수 있습니다.

Webcache의 access log는 XLF 를 지원하며, 보다 저수준의 access 정보도 저장할 수 있도록 준비돼 있습니다.

그래서 관리자가 지정하여 사용자정의 로그포맷을 만들 수 있습니다. 이는 log분석 툴마다 다르게 요구하는 log format에 맞출 수 있음을 의미합니다.



Performance monitoring

End user performance monitoring– 10g new– Click-to-render response time monitoring

Webcache에 의해 설정 및 수집된 performance data는 10g Grid control에 의해 분석할 수 있습니다. 사실상 그동안 마땅한 performance 분석툴을 제공하지 못했던 oracle webcache 기존 버전의 단점이 획기적으로 보완된것입니다.

더구나 기존의 여타 performance monitoring 방법으로는, 수집된 performance data가 실제 web server의 성능 및실제 사용자들의 다양성을 제대로 반영해주지 못했습니다.

OracleAS 10g version에서는 ‘End user performance monitoring’ 기능을 통해 실제 web service를 사용하는 현실상황을 사용자의 관점에서 그대로 반영할 수 있습니다.



Multiple vendors of application server

Virtual hosting

OracleAS 10g webcache는 여러 web application server vendor들의 제품과 호환성을 가집니다.

webcache standalone 버전을 운용할 수도 있으며, 이와 호환 가능한 3rd vendors 제품에는 BEA WebLogic Server 6.0, IBM WebSphere Application Server 4.0, Apache Tomcat 4.1, Microsoft IIS 5.0, SunOne등이 있습니다.



Server load/failure

web server의 capacity 한계 및 과부하에 따라 불특정 origin server가 다운될 수 있습니다.

우선 webcache의 load balancing기능을 통해 업무부하를 적절히 분산할 수 있습니다.

그리고 webcache clustering을 통해, 특정 node에 있는 webcache의 장애에 대처할 수 있습니다.



성능

Response time in seconds

DeployedOracleAS Web

Cache

• Faster oracle.com

이 그래프는 Oracle.com site의 실제 사례를 보여주고 있습니다. 많은 경우 그렇듯이, Oracle 제품의 훌륭한시연장은 바로 오라클 회사 자체입니다.

Graph에서 보시듯이 webcache를 deploy하기 전,후에 응답시간 측면에서 확연한 효과를 나타내고 있음을확인하실 수 있습니다.



Oracle9iAS Web Cache

Server Acceleration / HTTP Reverse ProxyShields web server and database; lightens processing burden Limits network trafficProvides fault toleranceReduces response timeProvides scalable environment

Oracle9iASWeb Cache

OHS/OC4J Servers Oracle9iDatabaseClient

Browser

Data Center

9i9iInternet

Webcache의 여러가지 기능 및 효과를 살펴보았습니다.

Webcache의 caching rule 설정과 invalidation, partial caching caching 설정에는 다소 까다로움이있습니다.

Webcache를 도입할 경우, 처음엔 아주 기본적인 사항들만 caching하도록 설정 및 운용하시는 것이바람직하며, web application의 특정 및 업무 로직을 잘 이해하신 후 보다 detail한 설정을 하시는것이 좋습니다.



참고 자료

1. Oracle Application Server Web Cache Administrator's Guide, 10g (9.0.4), Part No. B10401-02

2. OracleAS Web Cache, New Features in Oracle Application Server, 10g (9.0.4), An Oracle Technical White Paper, September 2003

3. Caching In on the Enterprise Grid, Turbo-Charge Your Applications with OracleAS Web Cache, An Oracle Technical White Paper, September 2003

4. Note.209670.1 Web Cache Rules Syntax for Regular Expressions

5. http://otn.oracle.co.kr/products/ias/web_cache/

6. ESI, JESI http://www.esi.org http://www.jcp.org

이 기종 환경에서 webcahce의 구성, 9ias 다른 버전과의 호환성 부분, caching hierachy, forms/reports와의 연계, oracle portal 또는 oracle e-business suite과 함께 쓰일 경우에 대해서는 본 세미나에서는 언급하지않았습니다.

이와 같은 webcache특정 주제는, 다음에 기회가 있으면 다뤄보도록 하겠습니다.

참고자료는 otn.oracle.com 이나 metalink.oracle.com에 가시면 찾아보실 수 있습니다.

감사합니다.

Documents

OracleAS 10g: 웹캐쉬 설정및성능 - DBGuide.net · 2004-10-04 · 하지만9.0.4에서는httpd.conf의OssoSendCacheHeaders parameter를off 시켜놓을수있게함으로써,