BPEL을 이용한 프로세스 안정성의 보장
저자 Michael Cardella and Jeremy Bolie

BPEL을 이용하여 재활용성 및 안정성이 뛰어난 비즈니스 프로세스를 구축하는 방법을 소개합니다.

전체 BPEL Cookbook 인덱스 보기

게시일: 2006년 3월

웹 서비스와 BPEL 프로세스의 적용 사례가 증가하면서, 서비스 품질이 서비스의 성공 여부를 결정짓는 중요한 기준으로 고려되고 있습니다. 네트워크 장애, 애플리케이션 접속 중단과 같은 예기치 않은 상황에서도 요청된 작업을 완수함을 보장하려면 어떻게 해야 할까요? 서로 다른 비즈니스 프로세스에서 같은 서비스를 활용할 수 있을까요? 이러한 질문에 대한 답변이 무엇인가에 따라 비즈니스 프로세스의 재활용성이 결정됩니다. 비즈니스 프로세스의 안정성이 뛰어날 수록, 프로세스의 재활용성 또한 높을 수 밖에 없습니다.

BPEL Cookbook 시리즈의 이번 연재에서는, 다수의 애플리케이션으로 구성된 비즈니스 시나리오를 검토해 보기로 합니다. 이 시나리오에서는 BPEL 프로세스의 실행을 보장하고, 서로 다른 비즈니스 시나리오에서 BPEL 프로세스가 재활용되는 방법을 알아보기로 합니다. 그런 다음, 인텔리전트한 재시도(retry) 로직을 이용하여 BPEL 프로세스의 서비스 품질을 보장하는 방법을 단계별로 설명합니다. 또 예외 관리, 이메일을 이용한 통보, 에러 로깅 등을 이용하여 프로세스를 개선하는 방법을 소개합니다.

비즈니스 시나리오

서비스의 재활용성은 SOA(Service-Oriented Architecture) 전략의 성공여부를 결정하는 주춧돌과도 같습니다. 재활용 가능한 서비스를 생성할 수 있는 경우에만 SOA로부터 진정한 가치를 이끌어 낼 수 있기 때문입니다. 이러한 서비스는 각 부서별로 서로 다른 비즈니스 컨텍스트를 갖고 실행됩니다. 실질적인 비즈니스 가치와 별도로, 서비스의 재활용 가능성은 서비스의 성공률을 결정하는 요소로 작용하기도 합니다. 서비스의 실패율은 얼마나 되는가? 네트워크 장애 시에도 실행이 가능한가? 에러를 복구하기 위한 충분한 기능이 제공되는가? 서비스의 안정성이 높을 수록 요청된 작업을 완료할 수 있는 확률뿐 아니라, 다른 비즈니스 컨텍스트에서도 활용될 수 있는 가능성 또한 증가하게 됩니다.

그림 1의 시나리오를 검토해 봅시다. 한 기업이 제품에 관련한 기술 문서를 파트너 업체에 배포하려 합니다. 문서에 대한 액세스 레벨은 파트너 타입과 요청된 문서에 따라 달라집니다. 이 정보는 오라클 데이터베이스에 저장되어 관리됩니다. 파트너가 네트워크에 참여하거나 이탈할 때마다 적절한 승인 과정 및 엔터프라이즈 애플리케이션의 업데이트 과정을 거쳐 프로비저닝 정보가 변경(액세스의 추가/업데이트/삭제)됩니다.

그림 1 문서 접근 권한의 프로비저닝을 위한 환경

문서 접근 권한(entitlement)이 데이터베이스에서 활성화, 비활성화, 변경될 때마다, Documentum으로 변경 사실이 통보됩니다. 통보 순서는 접근 권한의 변경 순서와 일치합니다. 이 과정에서 메시지가 손실되지 않는 것은 매우 중요하며, 감사 로그를 생성하여 중앙의 애플리케이션 데이터베이스 로그에 보관하고 있어야 합니다.

BPEL은 접근 권한의 활성화, 비활성화를 통제하는 핵심적인 역할을 수행합니다. BPEL 프로세스는 TIBCO 메시징 버스와 긴밀하게 연동하면서 메시지를 Documentum에 안정적으로 전달합니다. 또 에러 로깅 및 통보를 책임지기도 합니다. 이때 프로세스가 작업을 효율적, 안정적으로 수행할 수 있어야 하며, 네트워크 장애 또는 Documentum의 접속 장애로 인해 프로세스가 중단되지 않음을 보장할 수 있어야 합니다. 또 반복적인 재시도를 통해 작업을 완수할 수 있어야 합니다. 이처럼 안정적인 프로세싱 환경을 보장하는 BPEL 프로세스를 개발하려면 어떻게 해야 할까요?

본 문서의 나머지 부분에서는 BPEL을 이용하여 프로세스의 서비스 품질을 개선하기 위한 전략을 상세히 소개하고 있습니다. 데이터 프로세싱의 재시도는 데이터베이스를 중심으로 처리됩니다. 단, 여기에서 소개되는 내용은 BPEL 환경에서 프로세스의 안정성과 서비스 품질을 보장하기 위한 전략의 극히 일부분에 불과하다는 사실을 명심하시기 바랍니다.

아키텍처

먼저, BPEL 프로세스를 설계하기 위한 로직을 살펴보기로 합시다.

그림 2 BPEL 프로세스 로직

데이터베이스로부터 레코드를 읽어 들이고 처리하는 BPEL 프로세스는 Oracle BPEL의 데이터베이스 폴링 어댑터(database polling adapter)에 의해 시작됩니다. 이 BPEL 프로세스는 마지막 단계에서 성공/실패 여부를 데이터베이스에 보고합니다. 보고를 접수한 데이터베이스는 프로세스의 현재 상태와 재시도 시도 횟수를 기준으로 프로세스의 재시도 여부를 결정합니다. 재시도가 불필요한 경우에는, 레코드를 차후에 다시 조회하도록 스케줄을 조정합니다. 그리고 프로세스의 마지막 단계로 로그 서비스를 호출합니다. 이때 데이터베이스에 로그 엔트리를 생성하고, 일련의 룰을 사용하여 프로세스의 상태에 관련한 메시지를 전송할 것인지 결정하게 됩니다. 메시지 전송이 필요하다면, 이메일 템플릿과 이메일 리스트를 가져온 다음 템플릿에 로그에 기록된 정보를 첨부합니다.

이렇게 구현된 프로세스는 문제를 자체적으로 해결 가능한 경우, 또는 사용자 조치를 통해 문제를 해결해야 하는 경우에 그 안정성을 개선하는 효과를 제공합니다. 파트너가 직접 문서 액세스를 재시도하는 경우와 달리, 여기에서는 전체 BPEL 프로세스가 재실행됩니다. 또 BPEL 프로세스에 단순히 재시도 루프(loop)를 구현하는 것보다 더 많은 기능을 지원하고 있습니다.

• BPEL에 의해 처리되지 않은 레코드
• 주어진 시간 내에 처리가 완료되지 않은 레코드
• 실행 과정에서 취소 처리된 레코드

또 취소된 레코드를 재시도하거나, 재시도 작업을 스케줄링하는 것도 쉽습니다.

1. 1. 처리되는 레코드의 상태 정보를 데이터베이스에 저장합니다. 여기에는 프로세스의 상태, 프로세스를 재시도할 시간, 재시도 횟수 등의 정보가 포함되어야 합니다.
2. 2. 처리를 위한 준비가 완료된 레코드만을 조회하기 위한, 업데이트 가능한 뷰를 생성합니다. 이 뷰는 데이터베이스 어댑터가 SYSDATE를 기준으로 하는 WHERE 절을 제대로 처리하지 못하는 경우에 사용됩니다.
3. 3. 실패한 프로세스 인스턴스의 재시도 여부와 재시도 시점을 결정하기 위한 로직을 설계합니다. 이 정보는 스토어드 프로시저를 통해 데이터베이스에 업데이트됩니다. 또는 BPEL의 업데이트 파트너 링크와 다른 BPEL 로직을 이용할 수도 있습니다.

다음 섹션에서는, 이러한 프로세스를 구현하는 방법에 대해 알아보기로 합니다.

샘플의 구현

위에서 설명한 프로세스를 직접 구현해 봅시다. 먼저, 프로세스를 지원하는 데이터베이스 테이블을 생성하고, BPEL PM Designer를 이용하여 프로세스의 모델링을 수행합니다.

데이터베이스 오브젝트의 생성. 프로세스가 재시도 상태 정보를 데이터베이스에 저장하기 때문에, BPEL 프로세스를 생성하기에 앞서 데이터베이스 컴포넌트를 설계해 두어야 합니다. 앞에서 설명한 것처럼, 메인 데이터베이스에 구현되어야 하는 오브젝트가 아래와 같습니다.

• 처리되는 레코드의 상태를 추적하기 위한 필드
• 업데이트 가능한 뷰
• 상태 조회를 위한 프로시저

• Status
• Process Not Before
• Retry Count
• Create DTS
• Last Modified DTS

Status 필드는 BPEL 데이터베이스 폴링 어댑터가 처리되어야 하는 레코드를 확인하기 위해 사용하는 필드와 동일해야 합니다. 이 필드를 이용하여 현재 처리 중인 레코드, 성공적으로 처리 완료된 레코드, 에러가 발생한 레코드 등으로 구분하기 위한 명명법을 적용한다면 도움이 될 것입니다. 숫자 또는 접두어를 사용하는 방법이 가능합니다. 샘플 코드의 CREATE_TB_DB_POLL_SOURCE.sql를 참고하시기 바랍니다.

다음으로 Process Not Before 컬럼이 현재 SYSDATE보다 앞선 시점이거나 null인 레코드만을 제공하는 뷰를 생성합니다. 이 뷰를 이용하면 처리되어야 하는 레코드의 수를 쉽게 줄일 수 있습니다. 또는 뷰를 통해 처리되어야 하는 레코드의 프라이머리 키만을 제공함으로써, 뷰를 좀 더 가벼운 형태로 구현할 수 있습니다. 샘플 코드의 CREATE_VW_ DB_POLL_SOURCE_VW.sql을 참고하시기 바랍니다.

상태 조회를 위한 프로시저는 에러 여부를 표시하기 위한 플래그를 포함하고 있던지, 아니면 에러 여부를 확인하기 위한 별도의 프로시저가 구현되어야 합니다. 에러 상태로 감지된 경우, 프로시저를 통해 프로세스 인스턴스를 재실행할 것인지, 그리고 재실행한다면 그 시점이 언제인지를 결정해야 합니다. 일반적으로, 짧은 주기로 몇 차례 작업을 재시도한 다음 더 긴 주기를 갖고 더 많은 횟수로 재시도하는 방법이 사용됩니다. 샘플코드의 SET_DB_POLL_SOURCE_FAULTED.sql을 확인하십시오. .

다음으로, 데이터베이스 레코드를 안정적인 방법으로 처리하기 위한 BPEL 프로세스를 생성합니다.

1. 새로운 BPEL 프로젝트의 생성.
   빈 상태의 BPEL 프로젝트를 생성합니다.
   
   그림 3 BPEL 프로젝트의 생성

2. DB 폴링 어댑터의 생성.
   
   1. 새로운 파트너 링크를 생성합니다.
   2. Wizard 버튼을 클릭합니다.
   3. Database Wizard를 선택합니다.
   4. DBPolling을 service name으로 설정합니다.
      
      그림 4 DB 폴링 어댑터의 생성

   5. e. 데이터베이스 연결을 설정한 후, operation type으로 Poll for New or Changed Records in a Table을 선택합니다.
      
      그림 5 operation type의 선택

   6. DB_POLL_SOURCE_VW 뷰를 임포트합니다.
   7. 이후 화면에서 디폴트 설정을 그대로 사용합니다 (이 예제의 경우 WHERE 절을 사용하지 않습니다). 컬럼 ID를 프라이머리 키로 선택합니다.
   8. 뷰에 대한 읽기 작업을 수행한 후, 마법사가 레코드를 어떻게 처리할 것인지 물어 옵니다.
      아래 그림과 같이 Update a Field in the Activities Table (Logical Delete)을 선택합니다.
      
      그림 6 "Update a Field..."의 선택

   9. 이제 Logical Delete 스크린으로 이동합니다. 불필요한 로우의 논리적인 제거를 위해 업데이트할 BPEL_STATE 필드를 명시합니다.
      
      그림 7 BPEL_STATE 필드의 명시

3. receive 액티비티의 생성.
   BPEL 프로세스에 receive 액티비티를 추가하기 위해 아래와 같이 작업합니다.
   
   1. receive 커넥터를 2 단계에서 생성한 DBPolling 파트너 링크로 드래그합니다.
   2. receive 액티비티의 이름을 “receive”로 변경합니다.
   3. Create Instance 체크 박스를 클릭합니다.
   4. receive 액티비티 팝업의 variable 마법사를 클릭하고, inputVariable이라는 이름의 변수를 생성합니다.
      
      그림 8 변수의 생성

   5. OK를 클릭합니다.

      BPEL 프로세스가 아래와 같이 생성되었습니다:

      
      그림 9 지금까지 생성된 BPEL 프로세스

4. 커스텀 폴트 정의의 추가.
   커스텀 폴트(custom fault)를 추가하려면 먼저 폴트 정의를 포함하는 WSDL이 파트너 링크의 WSDL 중 하나에 의해 수신되도록 설정하는 작업이 선행되어야 합니다. 파트너 링크의 WSDL을 수정하는 것은 불가능하지만, 마법사가 재실행되는 경우 파트너 링크의 WSDL이 재생성될 수 있습니다. 때문에 마법사가 재실행되는 경우 WSDL에 임포트를 추가하는 작업이 재차 수행되어야 합니다.

   Project 폴더에 BpelFault.wsdl을 추가하기 위해 아래와 같이 작업합니다:
   

   1. Oracle JDeveloper에서 프로젝트를 선택하고 "File/Add to DB_to_JMS.jpr"을 선택한 후 추가할 BpelFault.wsdl을 선택합니다.
   2. definition 태그의 시작과 types 엘리먼트의 중간 부분에 위치한 DBPollingService.wsdl에 아래 라인을 추가합니다.

      <import namespace="http://schemas.oracle.com/otn/bpel/sample/dbpoll/jmspub/fault" 
              location="BpelFault.wsdl"/>

   WSDL은 하나의 컴플렉스 엘리먼트(complex element)를 사용하는 대신 메시지 파트(message part)를 사용합니다. 따라서 동일한 폴트 정의를 BPEL이 반환하는 폴트 타입으로 재활용할 수 있습니다. WSDL의 메시지 파트 섹션이 존재하지 않는 경우, BPEL은 도큐먼트 스타일의 웹 서비스 대신 RPC 스타일의 웹 서비스를 생성합니다.

5. 5. BPEL 프로세스의 나머지 부분 생성s.
   BPEL 프로세스의 나머지 부분을 구현하는 작업을 순서대로 설명하는 대신, 최종적인 프로세스를 먼저 살펴보고 개별 엘리먼트들을 설명하기로 합니다. 전체 BPEL 프로세스가 아래 그림과 같습니다.
   
   그림 10 전체 BPEL 프로세스

다음으로 BPEL 프로세스의 각 엘리먼트를 살펴보겠습니다. 중요한 엘리먼트가 아래와 같습니다.

• Init 블록 (process 스코프 내에 위치) Processing
• 프로세싱
• Reply/report 최종 상태 정보
• 로깅
• 폴트의 “Rethrow”

Init 블록

processing 스코프 내에서 실행되는 첫 번째 태스크입니다. 이름이 암시하듯, Init 블록은 프로세스 초기화 및 global, error, log 변수의 설정을 담당합니다. 샘플코드에 포함된 액티비티가 그림 11과 같습니다.

그림 11 프로세스의 초기화를 위한 플로우 단계

• Checkpoint (옵션)
  체크포인트는 디하이드레이션(dehydration)을 강제합니다. 체크포인트를 사용하면 실행 속도가 조금 느려지지만, 시작된 모든 BPEL 프로세스가 콘솔에 표시됨을 보장할 수 있습니다.

  BPEL 콘솔은 가장 최근의 디하이드레이션 시점의 실행 상태를 보여 줍니다. 일부 에러의 경우 콘솔에 상태 정보를 리포트하지 않은 상태에서 프로세스를 종료시키기도 합니다. 또 파트너 링크에 대한 동기식 호출이 무한정 대기 상태로 들어가, 디하이드레이션 상태 정보가 보고되지 않을 수도 있습니다.
  
  

• global_init
  예외 처리 메커니즘에 의해 사용되는 몇 가지 “상수(constant)”들을 초기화합니다. 이 작업은 폴트가 발생하기 전, 프로세스의 시작 부분에서 실행되어야 합니다.
  
  
• init_log
  init_log 태스크는 Java의 시간을 초기화하고 대략적인 프로세싱 시간을 (밀리 초 단위로) 추적할 수 있게 합니다. 이 작업은 프로세스가 실행 시간을 밀리 초 단위로 추적하는 로깅 시스템과 통합된 경우에만 필요합니다.

프로세싱

이제 본격적인 프로세싱 과정에 대해 설명할 차례입니다. BPEL 프로세스 플로우가 아래 그림과 같습니다.

그림 12 BPEL 프로세스 플로우

프로세스 플로우. 변수를 초기화 한 후, 프로세스가 데이터베이스 조회를 시작합니다. 현재 상태를 “processing”으로 업데이트한 후 데이터베이스 레코드를 읽어 들입니다. 데이터의 정확성을 검증한 다음, 메시지를 전달하기 전에 변환 작업을 수행합니다. 마지막으로, 메시지를 목적지(예제의 경우 JMS 버스)로 전달합니다. 프로세스가 중요 포인트를 거치기 전에 데이터베이스의 상태 정보를 업데이트하는 기능은, 롱-러닝 프로세스 또는 일부 영역에서 높은 리스크를 수반하는 프로세스에서 유용하게 활용됩니다. 데이터베이스로부터의 읽기 작업(ReadDB 파트너 링크)은 프로세스를 시작하는 뷰(DBPolling 파트너 링크)와 분리되어 있습니다. 따라서 뷰의 구조를 단순하게 가져가면서 BPEL 환경의 뷰에 대한 JOIN 작업이 불가능하다는 제약을 극복할 수 있습니다.

예외 처리. 전체 스코프에 포함된 각각의 스코프는 모든 익셉션(exception)을 감지하고 내부적으로 정의된 폴트를 발생시킵니다. 예를 들어 데이터베이스 레코드의 읽기 과정에서 에러가 발생한 경우, 스코프가 에러를 감지하고 에러 상태를 "Error while trying to read in data to be processed"로 설정한 후 부모 스코프에 에러를 전달합니다. 이처럼 모든 폴트에 대해 상세한 레벨의 상태 설정이 가능합니다.

메인 프로세싱 내부에서 에러가 발생한 경우, 인터널 타입(internal type)의 폴트가 발생됩니다. 그런 다음 바깥쪽의 catch 블록이 이 폴트를 가로챕니다. 이러한 방법을 사용할 때 catchall 블록에서 커스텀 폴트를 가로채지 않도록 주의합니다. 그렇게 하는 경우 커스텀 폴트에 관련한 모든 정보가 소실되어 버리기 때문입니다. 커스텀 폴트가 스코프 내부에서 발생된 경우, 해당 폴트를 가로채기 위한 catch 블록을 별도로 사용하고 catchall 블록은 다른 에러의 처리만을 담당하도록 합니다.

재활용성(Reusability). 프로세싱 로직이 비즈니스 요구사항에 기반하고 있다는 사실을 명심하는 것이 중요합니다. 이 시나리오에서는, 프로세스가 JMS에 안정적인 형태로 메시지를 전달하고 있습니다. 실제 환경에서는 신규 고객을 위한 은행 계좌의 업데이트, 주문 데이터의 동기화 등 프로세스가 매우 다양한 형태로 구현되고 있습니다. 하지만 프로세스가 제공하는 안정성의 수준은 동일합니다. 또 프로세스를 안정적인 형태로 재활용하는 것도 가능합니다.

Reply/Report 최종 상태 정보

그림 13 최종 상태 정보 업데이트를 위한 플로우

프로세싱 상태(status)는 성공한 경우 SUCCESS로, 그렇지 않은 경우 프로세스 과정에서 발생한 폴트 정보로 데이터베이스에 업데이트됩니다(위 그림 참고). 이러한 업데이트 작업이 반드시 필요한 것은 아니지만, 외부 애플리케이션이 프로세스 인스턴스의 진행 과정을 처음부터 끝까지 모니터링할 수 있게 하기 위해 권장됩니다.

예제에서는 최종 상태의 리포팅이 데이터베이스 프로시저(SetFaulted 파트너 링크)에 의해 수행됩니다. 리포팅을 BPEL 내부에서 수행할 수도 있지만, 데이터베이스 프로시저를 통해 처리하는 것이 BPEL 프로세스를 단순화할 수 있어 좋습니다.

최종 상태가 성공적이지 못한 경우, 리포트 결과에 따라 프로세스 재시도가 트리거 됩니다. 프로세스가 최대 재시도 횟수만큼 반복되지 않았다면, 일정한 주기를 두고 다시 실행됩니다.

로깅

로깅 프로세스는 프로세싱 정보를 수집한 후, 이를 중앙 로거(logger)에 전달합니다. 이때 에러의 심각도(severity)와 메시지 코드가 가장 중요한 정보로 활용됩니다. 로깅이 제공하는 이점이 아래와 같습니다:

• • 데이터베이스 검색이 용이한 감사 로그를 생성합니다.
• • 심각도와 메시지 코드를 기준으로 통보 발송 여부를 결정할 수 있습니다.
• • 메시지에는 BPEL 프로세스 인스턴스 및 프로세싱이 시작된 로우의 프라이머리 키와 같은 중요한 정보가 포함되어 있습니다. 따라서 BPEL 콘솔 상에서 문제를 해결하면서 해당 프로세스 또는 데이터베이스의 데이터를 신속하게 조회할 수 있습니다.

폴트의 “Rethrow”

그림 14 에러가 발생한 프로세스를 확인하기 위한 폴트 발생

그림 14와 같이 최종적인 “rethrow” 작업을 통해 문제가 되는 프로세스 인스턴스를 확인하는 과정을 단순화하고 BPEL 콘솔에서 프로세스 인스턴스를 쉽게 조회할 수 있습니다. 폴트가 “rethrow” 된 경우, 콘솔 상에서 프로세스 인스턴스에 플래그가 표시되고, 관리자는 필터를 이용하여 폴트가 발생한 프로세스만을 조회할 수 있습니다.

이와 같이 하여 BPEL 프로세스의 개발 작업을 완료하였습니다. 이 프로세스는 최상의 안정성을 구현하기 위한 다른 베스트 프랙티스(데이터베이스 모니터링, 신세틱 트랜잭션, 로그 모니터링 등)와 함께 조합된 형태로 활용되어야 합니다. 이 프로세스를 이용하면 성공한 레코드, 폴트가 발생한 레코드, 주어진 시간 내에 완료되지 못한 레코드 등을 쉽게 확인할 수 있습니다. 이러한 모든 정보는 각각의 레코드가 수천 달러에 달하는 가치를 갖고, SLA 위반으로 인해 고객 불만족이 발생할 수 있는 실제 환경에서 매우 유용하게 활용될 수 있습니다.

결론

본 문서를 통해, 안정성과 재활용성이 뛰어난 비즈니스 프로세스를 구현하는 방법을 설명하였습니다. 예제 프로세스는 안정적인 형태로 JMS에 메시지를 전송하며, 어떠한 비즈니스 목적을 위해서든 안정적으로 활용될 수 있습니다.

모든 비즈니스 예외 상황이 BPEL 프로세스에서 감지될 수 있는 것은 아닙니다. 서비스 품질을 보장하기 위해서는 프로세스 레벨의 작업만으로는 부족합니다. 감사 로그의 효율적인 모니터링, 관련자에 대한 통보 전송, 데이터/프로세스 레벨의 예외 처리가 병행되어야 하며, 각 프로세싱 단계별로 투명성이 확보되어야 합니다. 안정적인 프로세스를 구현하기 위해서는 이러한 모든 요구사항을 만족할 수 있어야 합니다.

Michael Cardella는 CDMA Technologies(QCT)의 스탭 엔지니어입니다. 마이클은 커스텀 애플리케이션 개발 팀에서 근무하면서 웹 서비스 및 비즈니스 프로세스 관련 애플리케이션을 주로 담당하고 있습니다. 마이클은 과거에 업계 선두의 웹 서비스 및 관리 제품의 수석 설계담당자로 근무한 경력을 가지고 있습니다.

Jeremy Bolie은 QCT의 선임 IT 매니저로, 커스텀 애플리케이션/Documentum 개발 팀에서 근무하고 있습니다. 제레미는 Java 및 오라클 테크놀로지에 관련한 10여 년의 경험을 보유하고 있으며, 1990년대 후반부터 웹 서비스, SOA 관련 업무에 종사해 왔습니다.