매일, 수십만 개의 기업과 수백만 명의 사용자가 Salesforce Platform이 구동하는 애플리케이션을 사용하여 클라우드에서 비즈니스를 운영합니다. 플랫폼이 그렇게 성공적인 이유는 무엇입니까? 왜 이 플랫폼을 귀하의 비즈니스를 지원하는 데 신뢰할 수 있을까요? 플랫폼이 귀사와 같은 비즈니스에 제공하는 고유한 혜택은 무엇입니까?

이 기술 요약은 Salesforce Platform이 클라우드 컴퓨팅용 고유한 소프트웨어 아키텍처를 사용하여 신뢰할 수 있고 확장 가능하며 쉽게 사용자 정의할 수 있는 최종 사용자 환경을 제공하는 방법에 대해 설명합니다. 이 요약을 읽은 후에는 Salesforce Platform을 비즈니스 응용 프로그램에 가장 적합한 선택으로 만드는 기본 기술을 더 잘 이해할 수 있습니다.

플랫폼 개요

Salesforce Platform은 성공적인 클라우드 컴퓨팅 플랫폼과 그 관련 애플리케이션 생태계의 대표적인 예입니다. 밀레니엄 전환 이후, 이 플랫폼은 다음의 기반 역할을 해왔습니다:

• 판매 및 고객 서비스와 같은 일반적인 사용 사례에 대한 많은 인기있는 비즈니스 응용 프로그램
• 금융 및 의료 등과 같은 더 전문적인 용도 사례에 대한 산업별 응용 프로그램
• 고유한 사용 사례를 위한 수백만 개의 사용자 지정 애플리케이션 및 애플리케이션 확장

대부분의 경우 Salesforce Platform은 독특한 소프트웨어 아키텍처로 구축, 사용, 사용자 정의 및 확장하기 쉬운 애플리케이션을 지원하며 뛰어난 성능과 신뢰성을 갖추기 때문에 매우 성공적이고 인기가 있습니다. 플랫폼의 소프트웨어 아키텍처의 핵심은 멀티테넌트, 메타데이터 기반 디자인입니다.

Salesforce Platform의 소프트웨어 아키텍처는 다음과 같습니다.

• Multitenant — 여러 테넌트(조직, 사업부 등)의 다양한 요구 사항을 격리하고 동시에 지원합니다.
• 메타데이터 구동 - 모든 테넌트가 사용자 인터페이스(UI) 및 비즈니스 논리와 같은 요소를 설명하는 메타데이터, 데이터를 사용하여 앱과 사용자 환경을 쉽고 빠르게 사용자 정의할 수 있습니다.

Salesforce Platform을 사용하여 새 응용 프로그램 개체를 만들거나 코드를 작성하는 경우 플랫폼에서 데이터베이스에 실제 테이블을 만들거나 코드를 컴파일하지 않습니다. 대신 플랫폼은 몇 가지 메타데이터를 저장하기만 하면 런타임 시 가상 응용 프로그램 구성 요소를 동적으로 구체화할 수 있습니다. 플랫폼은 모든 테넌트의 메타데이터가 비공개로 유지되며, 잠금이나 다운타임 없이 쉽게 업데이트할 수 있도록 보장합니다. 이를 통해 각 테넌트는 독립적으로 앱을 구축하고 사용자 정의할 수 있습니다. Salesforce Platform은 동일한 메타데이터를 사용하여 사용자 지정 API, RESTful 및 웹 서비스(SOAP 기반) 인터페이스를 제공하며, 이를 통해 앱을 다른 앱 및 자동화된 프로세스와 통합할 수 있습니다.

준비된 솔루션은 플랫폼의 광범위한 앱 마켓플레이스인 AppExchange에서도 사용할 수 있습니다. 신뢰할 수 있는 파트너 및 독립 소프트웨어 공급업체(ISV)의 광범위한 에코시스템에 의해 구축된 AppExchange 패키지는 무료 또는 유료 응용 프로그램 확장 프로그램 및 특정 비즈니스 요구 사항을 충족하기 위해 사용할 수 있는 전체 응용 프로그램을 설명하는 타사 메타데이터입니다.

이 고도로 사용자 정의 가능하고 확장 가능한 아키텍처를 지원하기 위해 Salesforce Platform의 단일 인스턴스는 다음을 사용합니다.

• 테넌트별 메타데이터 및 데이터를 저장하는 단일 스키마를 사용하는 단일 공유 _다중 테넌트 데이터베이스_입니다.
• 메타데이터와 데이터를 읽어 런타임 시 각 테넌트의 사용자에게 동적으로 테넌트별 애플리케이션, 비즈니스 논리 및 API를 제공하는 다중 테넌트 커널(애플리케이션 런타임)입니다.

Salesforce 관리 커널과 테넌트 관리 메타데이터를 명확히 분리함으로써, Salesforce, 테넌트, 그리고 ISV가 서로 간섭받지 않고 각자의 시스템 일부를 독립적으로 발전시킬 수 있습니다.

이 개요를 기반으로 이 기사의 후속 섹션에서는 다음과 같은 주요 디자인 측면에서 파생된 플랫폼의 고유한 기능에 대한 자세한 정보를 제공합니다.

• 플랫폼 데이터 레이어
• 플랫폼 애플리케이션 개발
• 내부 플랫폼 처리
• 플랫폼 인프라

Salesforce Platform의 응용 프로그램 런타임과 혁신적인 데이터 레이어는 함께 테넌트별 데이터, 스키마 사용자 정의, 비즈니스 논리를 안전하게 격리합니다. 높은 수준에서 스키마는 다양한 사용 사례를 지원합니다.

• 응용 프로그램을 만들거나 사용자 정의하면 플랫폼이 모든 테넌트에 대한 메타데이터를 유지하는 공유 데이터베이스 테이블에 관련 메타데이터를 저장합니다.
• 응용 프로그램을 사용하여 데이터를 읽거나 쓸 경우 플랫폼이 모든 테넌트에 대한 데이터를 유지하는 공유 데이터베이스 테이블에 데이터를 저장합니다.
• 플랫폼은 내부적으로, 런타임 시 요청 지연 시간을 최적화하기 위해 커널이 사용하는 여러 테이블에 내부 메타데이터를 유지합니다.

그러나 단일 공유 데이터베이스 및 스키마는 모든 테넌트의 데이터를 어떻게 비공개로 유지할 수 있습니까? 플랫폼의 모든 테넌트는 _조직_이라고 하며, 줄여서 _org_라고도 부릅니다. 그리고 공유 데이터베이스 테이블의 모든 조직별 레코드에는 _OrgID_가 있습니다. 커널이 데이터베이스에 액세스하면 각 조직의 활동이 비공개로 유지되도록 이 고유 식별자를 사용합니다.

조직별 객체(일반적인 관계형 데이터베이스 언어에서 테이블을 생각), 필드, 저장된 절차, 데이터베이스 트리거 등은 플랫폼이 _유니버설 데이터 사전(UDD)_으로 알려진 몇 가지 데이터베이스 테이블에 저장하는 메타데이터에 의해 설명되는 가상 구조입니다.

• _MT_Objects_는 응용 프로그램을 위해 정의하는 개체에 대한 고유 식별자(ObjID), 조직(OrgID), 개체에 대해 지정한 이름(ObjName) 등 해당 개체에 대한 메타데이터를 저장하는 데이터베이스 테이블입니다.
• MT_Fields 시스템 테이블은 각 개체에 대해 선언하는 필드(열)에 대한 메타데이터를 저장합니다(필드에 대한 고유 식별자(FieldID), 조직(OrgID), 필드를 포함하는 개체(ObjID), 필드 이름(FieldName), 필드의 데이터 유형, 필드에 색인화가 필요한지 여부를 나타내는 부울 값(IsIndexed), 개체의 다른 필드(FieldNum)에 대한 필드 위치를 포함합니다.

메타데이터가 핵심 구성 요소이므로 플랫폼에서 메타데이터에 대한 액세스를 최적화해야 합니다. 그렇지 않으면 자주 메타데이터에 액세스하면 서비스가 확장되지 않습니다. 이 잠재적인 병목을 고려하여 플랫폼은 대규모하고 정교한 _메타데이터 캐시_를 사용하여 가장 최근에 사용된 메타데이터를 메모리에 유지하고, 성능 저하를 일으키는 디스크 I/O 및 코드 재컴파일을 방지하며, 애플리케이션 응답 시간을 단축합니다.

MT_Data 시스템 테이블은 MT_Objects 및 MT_Fields의 메타데이터로 정의된 모든 조직별 테이블 및 해당 필드에 매핑되는, 응용 프로그램에서 접근 가능한 데이터를 저장합니다. 각 행에는 전역 고유 식별자(GUID), 행을 소유한 조직(OrgID), 포괄적인 개체 식별자(ObjID)와 같은 식별 필드가 포함됩니다. MT_Data 테이블의 각 행에는 해당 레코드에 대한 “자연 이름”을 저장하는 이름 필드도 있습니다. 예를 들어, 계정 레코드에서 “계정 이름”, 사례 레코드에서 “사례 번호”를 사용할 수 있습니다.

Value0 … ValueN 플렉스 열(슬롯이라고도 함)은 MT_Objects 및 MT_Fields에 선언된 테이블 및 필드에 매핑되는 애플리케이션 데이터를 저장합니다. 모든 플렉스 열은 가변 길이 문자열 데이터 유형을 사용하므로, 구조화된 모든 유형의 애플리케이션 데이터(문자열, 숫자, 날짜 등)를 저장할 수 있습니다. 다음 그림에 표시된 바와 같이, 동일한 개체의 두 필드는 저장을 위해 MT_Data의 동일한 슬롯에 매핑될 수 없습니다. 그러나 각 필드가 서로 다른 개체에서 파생된 경우, 단일 슬롯이 여러 필드의 정보를 관리할 수 있습니다.

MT_Fields는 텍스트, 숫자, 날짜 및 날짜/시간과 같은 여러 표준 구조화된 데이터 유형 중 하나를 사용할 수 있으며, 선택 목록(목록된 필드), 자동 번호(자동 증분, 시스템 생성 순서 번호), 수식(읽기 전용 파생 값), 마스터-세부 사항 관계(외부 키), 확인란(부울), 이메일, URL 등과 같은 특수 용도와 * 풍부한 구조화된 데이터 유형*을 사용할 수 있습니다. MT_Fields는 필수(Null이 아님)로 설정할 수 있으며, 사용자 정의 검증 규칙(예: 한 필드가 다른 필드보다 커야 함)을 가질 수 있습니다. 이 두 가지 모두 플랫폼에서 강제 적용됩니다.

개체를 선언하거나 수정하면 플랫폼에서 개체를 정의하는 MT_Object의 메타데이터 행을 관리합니다. 마찬가지로 각 필드에 대해, 플랫폼은 해당 필드를 MT_Data의 특정 플렉스 열에 매핑하는 메타데이터를 포함하여 MT_Fields의 행을 관리합니다. 플랫폼이 실제 데이터베이스 구조가 아닌 메타데이터로 개체 및 필드 정의를 관리하기 때문에, 시스템은 다른 조직이나 사용자의 동시 작업을 방해하지 않고 온라인 다중 테넌트 애플리케이션 스키마 유지 관리 작업을 수행할 수 있습니다. 반면, 기존 관계형 데이터베이스 시스템에서 온라인 테이블 재정의는 일반적으로 임시 잠금이 필요하며, 종종 번거롭고 복잡한 절차와 예정된 애플리케이션 중단 시간이 요구됩니다.

이전 그림에 나타난 MT_Data의 간소화된 표현에서 볼 수 있듯이, 플렉스 열은 범용 데이터 유형(가변 길이 문자열)으로, 플랫폼이 다양한 구조화된 데이터 유형(문자열, 숫자, 날짜 등)을 사용하는 여러 필드 간에 단일 플렉스 열을 공유할 수 있게 해줍니다.

플랫폼은 모든 플렉스 열 데이터를 _표준 형식_으로 저장하며, 애플리케이션이 데이터를 읽거나 쓸 때 필요에 따라 데이터베이스 시스템의 데이터 유형 변환 함수(예: TO_NUMBER, TO_DATE, TO_CHAR)를 사용합니다.

MTData에는 이전 그림에 표시되지 않은 열이 포함되어 있습니다. 예를 들어, 행을 만든 사용자 및 해당 행이 생성된 시기, 행을 마지막으로 수정한 사용자 및 행이 마지막으로 수정된 시기를 포함하여 감사 데이터를 관리하는 4개의 열이 있습니다. MT_Data에는 플랫폼이 행이 삭제된 시점을 나타내는 데 사용하는 _IsDeleted 열도 포함되어 있습니다.

플랫폼은 최대 32,000자의 장문 텍스트 필드를 저장할 수 있도록 필드를 _문자 대용량 객체(CLOB)_로 선언하는 것도 지원합니다. MT Data의 각 행에 CLOB가 있는 경우 플랫폼은 _MT_Clob이라는 테이블에 CLOB를 오프라인으로 저장하며, 시스템은 필요에 따라 MT_Data의 해당 행에 연결할 수 있습니다.

참고: 플랫폼은 빠른 텍스트 검색을 위해 데이터베이스 외부의 색인화된 형식으로 CLOB도 저장합니다. 플랫폼의 텍스트 검색 엔진에 대한 자세한 내용은 검색을 참조하십시오.

플랫폼은 다양한 유형의 필드를 자동으로 색인화하여 확장 가능한 성능을 제공합니다.

기존 데이터베이스 시스템은 네이티브 데이터베이스 색인을 사용하여 특정 조건과 일치하는 필드가 있는 데이터베이스 테이블에서 특정 행을 빠르게 찾습니다. 그러나 플랫폼은 단일 유연한 열을 사용하여 다양한 구조화된 데이터 유형의 많은 필드의 데이터를 저장하기 때문에 MTData의 유연한 열에 대한 네이티브 데이터베이스 인덱스를 생성하는 것은 실용적이지 않습니다. 대신 플랫폼은 색인화하도록 표시된 필드 데이터를 _MT_Indexes 피벗 테이블의 해당 열로 동기식으로 복사하여 MT_Data의 색인을 관리합니다.

MT_Indexes에는 플랫폼에서 해당 데이터 유형의 필드 데이터를 찾는 데 사용하는 StringValue, NumValue, DateValue와 같은 강력하게 입력된 색인화된 열이 포함되어 있습니다. 예를 들어, 플랫폼이 MT_Data Flex 열의 문자열 값을 MT_Indexes의 StringValue 필드에 복사하고 DateValue 필드에 날짜 값을 복사하는 등 MT_Indexes의 기본 색인은 표준이 아닌 고유한 데이터베이스 색인입니다. 내부 시스템 쿼리에 개체의 구조화된 필드를 참조하는 검색 매개 변수가 포함된 경우 플랫폼의 사용자 정의 쿼리 최적화 프로그램은 MT_Indexes를 사용하여 관련 데이터 액세스 작업을 최적화합니다.

참고: 이 플랫폼은 _사례 폴링 알고리즘_을 사용하여 문자열 값을 범용, 대/소문자를 구분하지 않는 형식으로 변환하기 때문에 여러 언어 간의 검색을 처리할 수 있습니다. MT_Indexes 테이블의 StringValue 열에 이 형식으로 문자열 값이 저장됩니다. 런타임 시, 쿼리 최적화기는 데이터 액세스 작업을 자동으로 구축하여 최적화된 SQL 문이 해당 대소문자 변환된 StringValue를 필터링하도록 하여, 이는 검색 요청에 제공된 리터럴에 대응합니다.

플랫폼을 사용하면 개체의 필드에 고유한 값(대/소문자를 구분하거나 대/소문자를 구분하지 않음)이 포함되어야 하는 시점을 표시할 수 있습니다. MT_Data의 배열 및 필드 데이터에 대한 값 열의 공유 사용을 고려할 경우 개체에 대해 고유한 데이터베이스 색인을 만드는 것은 실용적이지 않습니다. (이 상황은 비고유 색인에 대해 이전 섹션에서 논의한 상황과 유사합니다.)

사용자 정의 필드의 고유성을 지원하기 위해 플랫폼은 MT_Unique_Indexes 피벗 테이블을 사용합니다. 이 테이블은 MT_Unique_Indexes의 기본 데이터베이스 색인에 고유성이 적용되는 것을 제외하고 MT_Indexes 테이블과 매우 유사합니다. 애플리케이션이 고유 값이 필요한 필드에 중복 값을 삽입하려 하거나, 관리자가 중복 값이 포함된 기존 필드에 대해 고유성을 강제하려고 할 때, 플랫폼은 애플리케이션에 적절한 오류 메시지를 반환합니다.

드문 경우, 플랫폼의 외부 검색 엔진(검색에 설명됨)이 과부하되거나 사용하지 못할 수 있으며, 검색 요청에 적시에 응답할 수 없습니다. 최종 사용자에게 실망스러운 오류를 반환하는 대신 플랫폼이 합리적인 검색 결과를 제공하기 위해 보조 검색 메커니즘으로 돌아갑니다.

대상 레코드의 이름 필드를 참조하는 검색 조건이 있는 직접 데이터베이스 쿼리로 구현되는 _대체 검색_입니다. 잠재적으로 비용이 많이 드는 조인 쿼리를 실행하지 않고 전역 객체 검색(테이블에 걸친 검색)을 최적화하기 위해 플랫폼은 모든 레코드의 이름을 기록하는 MT_Fallback_Indexes 피벗 테이블을 유지합니다. MT_Fallback_Indexes에 대한 업데이트는 트랜잭션이 레코드를 수정할 때 동기식으로 수행되므로 대체 검색에서 항상 최신 데이터베이스 정보에 액세스할 수 있습니다.

MT_Name_Denorm 테이블은 MT_Data에 각 레코드의 ObjID 및 이름을 저장하는 lean 데이터 테이블입니다. 애플리케이션에서 상위/하위 관계에 관련된 레코드 목록을 제공해야 할 때, 플랫폼은 MT_Name_Denorm 테이블을 사용하여 참조된 각 레코드의 Name을 앱에 표시하기 위해(예: 하이퍼링크의 일부로) 상대적으로 간단한 쿼리를 실행합니다.

이 플랫폼은 조직이 테이블 간 관계(참조 무결성)를 선언하는 데 사용할 수 있는 관계 데이터 유형을 제공합니다. 관계 유형으로 개체의 필드를 선언하면 플랫폼이 필드를 MT_Data의 값 필드에 매핑한 다음 이 필드를 사용하여 관련 개체의 ObjID를 저장합니다.

조인 작업을 최적화하기 위해 플랫폼은 MT_Relationships 피벗 테이블을 유지합니다. 이 시스템 테이블에는 필요한 경우 양 방향으로 효율적인 개체 탐색을 가능하게 하는 두 개의 기본 데이터베이스 고유 복합 색인이 있습니다.

마우스 클릭 몇 번으로 플랫폼은 모든 필드에 대한 내역 추적을 제공합니다. 조직에서 특정 필드에 대한 감사를 활성화하면 내부 피벗 테이블을 감사 추적으로 사용하여 필드에 대한 변경 사항(기존 및 새 값, 변경 날짜 등)에 대한 정보를 비동기식으로 기록합니다.

기본 데이터베이스 색인을 포함하여 모든 플랫폼 데이터, 메타데이터 및 피벗 테이블 구조가 기본 데이터베이스 분할 메커니즘을 사용하여 OrgID로 물리적으로 분할됩니다. 데이터 분할은 데이터베이스 시스템에서 대규모 논리적 데이터 구조를 더 작고 관리 가능한 조각으로 물리적으로 나누기 위해 제공하는 입증된 기술입니다. 또한 파티션은 멀티테넌트 환경과 같은 대규모 데이터베이스 시스템의 성능, 확장성, 가용성을 향상하는 데 도움이 됩니다. 정의상 모든 플랫폼 쿼리는 특정 조직의 정보를 대상으로 하므로, 쿼리 옵티마이저는 전체 테이블이나 인덱스가 아닌 조직의 데이터를 포함하는 데이터 파티션에만 액세스하는 것을 고려하면 됩니다. 이러한 일반적인 최적화는 ‘파티션 프루닝’이라고도 불립니다.

이 섹션에서는 앱 개발자가 스키마의 기본 메타데이터를 만든 다음, 데이터를 관리하는 앱을 구축하는 방법을 설명합니다. 해당 메타데이터 및 데이터는 이전 섹션에 설명된 플랫폼 데이터 레이어에 저장됩니다.

개발자는 플랫폼의 브라우저 기반 개발 환경(일반적으로 플랫폼 Setup 화면이라고 불리는)을 사용하여 서버 사이드 애플리케이션 구성 요소를 선언적으로 구축할 수 있습니다. Setup의 포인트 앤 클릭 UI는 애플리케이션의 데이터 모델 생성(개체 및 해당 필드와 관계 포함), 보안 및 공유 모델(사용자, 프로필, 역할 계층 포함), 사용자 인터페이스(화면 레이아웃, 데이터 입력 양식, 보고서 포함), 선언적 논리(워크플로), 프로그램 논리(저장 프로시저 및 트리거) 등 애플리케이션 스키마 구축 프로세스의 모든 측면을 지원합니다. 예를 들어, Salesforce Flow를 사용하면 광범위한 사용 사례를 쉽게 자동화할 수 있습니다. 아래에 표시된 설정의 Flow Builder UI를 사용하면 사용자와 상호 작용하는 워크플로를 그래픽 방식으로 설계 및 구현하거나 일정에 따라 또는 이벤트로 트리거되면 자동으로 실행할 수 있습니다.

설정 화면을 사용하면 코드 없이 또는 거의 코드 없이 누구나 쉽게 애플리케이션을 개발하고 사용자 정의할 수 있습니다. 예:

• 플랫폼 네이티브 UI는 코드 없이 쉽게 구축할 수 있습니다. 네이티브 앱 UI는 쿼리, 삽입, 업데이트, 삭제 등 일반적인 모든 데이터 액세스 작업을 지원합니다. 네이티브 플랫폼 응용 프로그램에서 수행하는 각 데이터 조작 작업은 한 번에 하나의 개체를 수정하고 별도의 트랜잭션에서 각 변경 사항을 자동으로 커밋할 수 있습니다.
• 민감한 데이터가 포함된 개체에 대한 텍스트 필드를 정의할 때 플랫폼이 해당 데이터를 암호화하고 경우에 따라 입력 마스크를 사용하여 눈에 띄는 화면 정보를 숨길 수 있도록 필드를 쉽게 구성할 수 있습니다.
• 선언적 _확인 규칙_은 조직이 프로그래밍 없이 도메인 무결성 규칙을 적용하는 간단한 방법입니다. 예를 들어 LineItem 개체의 수량 필드가 항상 0보다 큰지 확인하는 확인 규칙을 선언할 수 있습니다.
• _수식 필드_는 계산된 필드를 객체에 쉽게 추가할 수 있는 플랫폼의 선언적 기능입니다. 예를 들어 LineItem 개체에 필드를 추가하여 LineTotal 값을 계산할 수 있습니다.
• _롤업 요약 필드_은 상위 개체에서 하위 필드 정보를 쉽게 집계할 수 있는 교차 개체 필드입니다. 예를 들어 LineItem 개체의 LineTotal 필드를 기반으로 SalesOrder 개체에 OrderTotal 요약 필드를 만들 수 있습니다.

참고: 내부적으로 플랫폼은 네이티브 데이터베이스 기능을 사용하여 수식 및 롤업 요약 필드를 구현하고 진행 중인 트랜잭션의 일부로 값을 효율적으로 동기식으로 재계산합니다.

플랫폼은 개발자가 앱을 구축하는 데 사용할 수 있는 몇 가지 개방형, 표준 기반 API를 제공합니다. RESTful 및 웹 서비스(SOAP 기반) API 모두 플랫폼의 다양한 기능에 액세스할 수 있습니다. 응용 프로그램은 다양한 API를 사용하여 다음을 수행할 수 있습니다.

• 응용 프로그램 스키마를 설명하는 메타데이터를 조작
• CRUD(비즈니스 데이터 만들기, 읽기, 업데이트, 삭제)
• 대량의 레코드를 비동기식으로 로드하거나 쿼리
• 안전하고 확장 가능한 방식으로 거의 실시간 데이터 스트림 노출

앱은 _Salesforce Object Query Language(SOQL)_을 사용하여 간단하지만 강력한 데이터베이스 쿼리를 구성할 수 있습니다. 구조화된 쿼리 언어(SQL)의 SELECT 명령과 마찬가지로 SOQL을 사용하면 소스 개체, 검색할 필드 목록, 소스 개체에서 행을 선택하기 위한 조건을 지정할 수 있습니다. 예를 들어, 다음 SOQL 쿼리는 이름이 ‘Acme’ 문자열과 같은 모든 계정 레코드의 ID 및 이름 필드 값을 반환합니다.

SELECT Id, Name FROM Account WHERE Name = 'Acme'

플랫폼에는 모든 텍스트 관련 필드를 자동으로 색인화하는 전체 텍스트 다국어 검색 엔진도 포함되어 있습니다. 앱은 _Salesforce 개체 검색 언어(SOSL)_를 사용하여 이 사전 통합 검색 엔진을 사용하여 텍스트 검색을 수행할 수 있습니다. 한 번에 하나의 개체만 쿼리할 수 있는 SOQL과 달리 SOSL을 사용하면 여러 개체에 대한 텍스트, 이메일, 전화 필드를 동시에 검색할 수 있습니다. 예를 들어, 다음 SOSL 문은 이름 필드에 ‘Joe Smith’ 문자열을 포함하는 리드 및 연락처 개체의 레코드를 검색하고 검색된 각 레코드의 이름 및 전화번호 필드를 반환합니다.

FIND {"Joe Smith"} IN Name Fields RETURNING lead(name, phone), contact(name, phone)

여러 면에서 Java와 유사한 _Apex_는 개발자가 애플리케이션 스키마에서 절차 논리를 중앙집중화하는 데 사용할 수 있는 강력한 개발 언어입니다. Apex 코드는 프로그램 변수와 상수를 선언하고, if-else, 반복문 등 전통적인 흐름 제어문을 실행하며, insert, update, upsert, delete와 같은 데이터 조작 작업과 setSavepoint, rollback 등의 트랜잭션 제어 작업을 수행할 수 있습니다.

플랫폼에 Apex 프로그램을 두 가지 형태로 저장할 수 있습니다. 하나는 이름이 지정된 Apex 클래스로, 이는 전통적인 데이터베이스 용어에서 저장 프로시저와 유사하며, 애플리케이션이 필요할 때 실행합니다. 다른 하나는 특정 데이터베이스 조작 이벤트가 발생하기 전이나 후에 자동으로 실행되는 _데이터베이스 트리거_입니다. 두 가지 형태 모두에서 플랫폼은 Apex 코드를 컴파일하고 UDD에 메타데이터로 저장합니다. 조직이 Apex 프로그램을 처음 실행할 때 플랫폼의 런타임 해석기가 컴파일된 버전의 프로그램을 해당 조직의 MRU(최근 사용) 캐시에 로드합니다. 그 후 동일한 조직의 사용자가 동일한 루틴을 사용해야 할 때, 플랫폼은 이미 메모리에 있는 실행 준비된 프로그램을 공유함으로써 메모리를 절약하고 프로그램을 다시 컴파일하는 오버헤드를 피할 수 있습니다.

여기저기 간단한 키워드를 추가하면 개발자가 Apex를 사용하여 많은 고유한 애플리케이션 요구 사항을 지원할 수 있습니다. 예를 들어 개발자는 메서드를 사용자 정의 RESTful 또는 SOAP 기반 API 호출로 노출하거나 비동기식으로 예약 가능하게 만들거나 대규모 작업을 배치로 처리하도록 구성할 수 있습니다.

Apex는 단순히 또 다른 절차적 언어 그 이상입니다. 이는 시스템에서 신뢰할 수 있는 멀티테넌스를 제공하는 데 도움이 되는 통합 플랫폼 구성 요소입니다. 예를 들어 플랫폼이 런타임 시 실패할 코드를 방지하기 위해 클래스 내의 모든 내장 SOQL 및 SOSL 문을 자동으로 확인합니다. 그러면 플랫폼은 유효한 클래스에 대한 해당 개체 종속성 정보를 유지하고, 이를 사용하여 종속 코드를 손상시킬 수 있는 메타데이터 변경을 방지합니다.

많은 표준 Apex 클래스 및 시스템 정적 메서드는 기본 시스템 기능에 간단한 인터페이스를 제공합니다. 예를 들어, 삽입, 업데이트, 삭제와 같은 시스템 정적 DML 메서드에는 개발자가 원하는 대량 처리 옵션(전체 처리 또는 일부 저장)을 지정할 수 있는 간단한 불리언 매개변수가 있습니다. 이러한 메서드는 호출 루틴이 실패한 레코드와 그 이유를 확인할 수 있도록 결과 객체를 반환합니다. Apex와 플랫폼 기능 간의 직접적인 연계의 또 다른 예로는 내장된 이메일 클래스와 XmlStream 클래스가 있습니다.

플랫폼이 성능과 확장성 면에서 뛰어난 것은 Salesforce가 두 가지 중요한 원칙을 염두에 두고 플랫폼을 구축했기 때문입니다.

• 효율적인 대규모 기본 플랫폼 기능을 제공합니다.
• 개발자가 가능한 한 효율적으로 모든 작업을 수행할 수 있도록 돕습니다.

플랫폼은 이러한 원칙들을 플랫폼 고유의 처리 아키텍처에 통합하며, 여기에는 다음과 같은 요소들이 포함됩니다.

• 쿼리
• 검색
• 대량 작업
• 스키마 수정
• 다중 테넌트 격리
• 휴지통

대부분의 최신 데이터베이스 시스템은 대상 테이블 및 색인 데이터에 대한 관련 통계를 고려하는 비용 기반 쿼리 최적화 프로그램을 사용하여 최적의 쿼리 실행 계획을 결정합니다. 그러나 전통적인 비용 기반 옵티마이저 통계는 단일 테넌트 응용 프로그램을 위해 설계되었으며, 멀티테넌트 환경에서 쿼리를 실행하는 특정 사용자의 데이터 접근 특성을 반영하지 못합니다. 예를 들어, 데이터 용량이 많은 개체를 대상으로 하는 지정된 쿼리는 가시성이 높은 사용자(모든 행을 볼 수 있는 관리자)와 가시성이 낮은 사용자(자신과 관련된 행만 볼 수 있는 판매 담당자)를 위해 다른 실행 계획을 사용하여 더욱 효율적으로 실행될 수 있습니다.

멀티테넌트 시스템에서 최적의 쿼리 실행 계획을 결정하기 위한 충분한 통계를 제공하기 위해 플랫폼은 모든 조직의 객체에 대해 완전한 세트의 최적화 통계(테넌트, 그룹, 사용자 수준)를 유지합니다. 통계는 특정 쿼리에서 잠재적으로 액세스할 수 있는 행 수를 반영하며, 전체 조직별 개체 통계(예: 조직 전체에서 소유한 총 행 수) 및 보다 세분화된 통계(예: 특정 권한 그룹 또는 최종 사용자가 잠재적으로 액세스할 수 있는 행 수)를 주의 깊게 고려합니다.

또한 플랫폼은 특정 쿼리에 유용한 다른 유형의 통계도 유지합니다. 예를 들어, 플랫폼은 모든 사용자 정의 인덱스에 대한 통계를 유지하여 해당 필드의 null이 아닌 고유 값의 총 수를 보여주며, 각 선택 목록 값의 고유값 개수를 나타내는 히스토그램도 선택 목록 필드에 대해 유지합니다.

기존 통계가 없거나 유용하지 않은 경우 플랫폼의 최적화 프로그램은 합리적으로 최적의 쿼리를 구축하는 데 도움이 되는 몇 가지 전략을 사용합니다. 예를 들어, 쿼리가 개체의 이름 필드를 필터링하는 경우 최적화 프로그램은 MT_Fallback_Indexes 테이블을 사용하여 요청된 행을 효율적으로 찾을 수 있습니다. 다른 시나리오에서는 옵티마이저가 런타임 시 누락된 통계를 동적으로 생성합니다.

최적화 프로그램 통계와 함께 사용되는 플랫폼의 최적화 프로그램은 지정된 사용자의 그룹 구성원 자격, 개체 및 행에 대한 사용자 정의 액세스 권한 등 조직 사용자의 보안 도메인에 대한 정보를 유지하는 내부 보안 관련 테이블(그룹, 구성원, GroupBlowout 및 사용자 정의 공유)에도 의존합니다. 이러한 정보는 사용자별로 쿼리 필터의 선택성을 결정하는 데 매우 중요합니다. 플랫폼의 내장형 보안 모델에 대한 자세한 내용은 Platform Developer Basics Trailhead를 참조하십시오.

다음 그림의 플로 다이어그램은 플랫폼이 MT_Data와 같은 대규모 힙 테이블 중 하나에 있는 데이터에 대한 요청을 처리할 때 발생하는 상황을 보여줍니다. 요청은 API 호출 또는 저장된 절차와 같은 여러 소스에서 시작될 수 있습니다. 먼저 플랫폼이 멀티테넌트 인식 통계를 고려하는 “사전 쿼리”를 실행합니다. 그런 다음, 서비스는 사전 쿼리에서 반환한 결과를 기반으로 특정 설정에서 실행할 수 있도록 최적의 기본 데이터베이스 쿼리를 구축합니다.

다음 표에 표시된 바와 같이 플랫폼은 쿼리를 제출하는 사용자 및 쿼리의 필터 조건 선택성에 따라 네 가지 방법으로 동일한 쿼리를 실행할 수 있습니다.

사용자는 대화형 검색 기능을 사용하여 애플리케이션의 데이터베이스 전체 또는 선택한 범위를 스캔하고 1초 미만의 응답 시간으로 순위가 지정된 결과를 반환할 수 있기를 기대합니다. 플랫폼 애플리케이션에 이 기능을 제공하기 위해 플랫폼은 트랜잭션 엔진과 별도의 검색 엔진을 사용합니다. 레코드를 업데이트하면 트랜잭션 엔진이 핵심 데이터베이스를 업데이트하고 색인화를 위해 관련 데이터를 검색 엔진으로 전달합니다. 레코드를 검색할 때 검색 엔진이 색인을 사용하여 쿼리를 빠르게 처리하고 관련 데이터베이스 레코드에 대한 링크와 함께 순위가 지정된 결과를 반환합니다.

응용 프로그램이 텍스트 필드(CLOB, 이름 등)의 데이터를 업데이트하면 색인화 서버라는 백그라운드 프로세스 풀이 검색 엔진이 핵심 트랜잭션 엔진 외부에서 유지하는 해당 색인을 비동기식으로 업데이트할 책임이 있습니다. 색인화 프로세스를 최적화하기 위해 플랫폼은 트랜잭션이 커밋될 때 수정된 텍스트 데이터 청크를 내부의 “색인화 대기” 테이블에 동기식으로 복사하여, 색인화 서버가 디스크에서 읽어야 하는 데이터 양을 최소화하는 상대적으로 작은 데이터 소스를 제공합니다. 검색 엔진은 각 조직에 대해 별도의 색인을 자동으로 유지합니다.

현재 색인화 서버의 부하 및 사용량에 따라 텍스트 색인 업데이트가 실제 트랜잭션보다 느려질 수 있습니다. 오래된 색인에서 발생하는 예기치 않은 검색 결과를 방지하기 위해 플랫폼은 전체 텍스트 검색 결과를 구체화할 때 시스템에서 고려하는 최근 업데이트된 행의 MRU 캐시도 유지합니다. 플랫폼은 잠재적인 검색 범위를 효율적으로 지원하기 위해 사용자별 및 조직별로 MRU 캐시를 유지합니다.

플랫폼의 검색 엔진은 여러 방법을 사용하여 검색 결과 내에서 레코드의 순위를 최적화합니다. 예를 들어, 시스템에서 검색을 수행하는 사용자의 보안 도메인을 고려하고 현재 사용자가 액세스할 수 있는 행에 더 많은 가중치를 부여합니다. 또한 특정 행의 수정 내역을 고려하고 상대적으로 정적인 행보다 더 적극적으로 업데이트된 행의 순위를 지정할 수 있습니다. 사용자는 원하는 대로 검색 결과에 가중치를 부여하도록 선택할 수 있습니다. 예를 들어, 최근에 수정된 행에 더 많은 비중을 둘 수 있습니다.

트랜잭션이 많은 응용 프로그램은 반복 작업을 대량으로 결합하고 실행할 때 오버헤드를 줄이고 성능이 훨씬 향상됩니다. 예를 들어, 응용 프로그램이 많은 새 행을 로드할 수 있는 두 가지 방법을 비교합니다. 비효율적인 접근 방식은 개별 행을 삽입하는 루틴을 사용하여, 각 행 삽입 시마다 API 호출을 반복하는 것입니다. 훨씬 효율적인 접근 방식은 행의 배열을 만들고 루틴이 단일 API 호출로 모든 행을 삽입하도록 하는 것입니다.

API 호출에 내장되어 있으므로, 플랫폼의 효율적인 대량 처리는 개발자에게 간편합니다. 내부적으로 플랫폼은 명시적 대량 작업과 관련된 모든 내부 단계도 대량 처리합니다.

플랫폼의 대량 처리 엔진은 각 단계에서 발생할 수 있는 개별 오류를 자동으로 처리합니다. 대량 작업이 부분 저장 모드에서 시작되면, 엔진은 알려진 시작 상태를 식별한 후 프로세스의 각 단계(필드 데이터 대량 검증, 사전 트리거 대량 실행, 레코드 대량 저장 등)를 차례로 시도합니다. 엔진이 단계 중 오류를 감지하면, 문제가 된 작업과 모든 부작용을 롤백하고 오류를 유발한 행을 제거한 뒤, 남은 행의 하위 집합을 계속해서 대량 처리합니다. 이 프로세스는 엔진이 오류 없이 행 하위 집합을 커밋할 수 있을 때까지 각 연속 단계를 반복합니다. 응용 프로그램은 반환 객체를 검사하여 어떤 행이 실패했는지, 그리고 어떤 예외가 발생했는지 식별할 수 있습니다.

참고: 사용자의 선택에 따라, 대량 작업에는 전부 실행되거나 전혀 실행되지 않는 all-or-nothing 모드가 제공됩니다. 또한 대량 작업 동안 트리거 실행은 작업량을 제한하는 내부 거버너의 적용을 받습니다.

특정 유형의 개체 정의를 수정하려면 간단한 UDD 메타데이터 업데이트 이상이 필요합니다. 이러한 경우 플랫폼은 클라우드 데이터베이스 서비스 전체에 대한 전반적인 성능 영향을 줄이는 데 도움이 되는 효율적인 메커니즘을 사용합니다.

예를 들어 열의 데이터 유형을 선택 목록에서 텍스트로 수정할 때 백그라운드에서 발생하는 상황을 고려합니다. 플랫폼은 먼저 열의 데이터에 대한 새 슬롯을 할당하고 현재 값과 연결된 선택 목록 레이블을 대량으로 복사한 다음, 새 슬롯을 가리키도록 열의 메타데이터를 업데이트합니다. 모든 작업이 진행되지만 데이터에 대한 액세스는 정상적이며 응용 프로그램이 눈에 띄는 영향 없이 계속 작동합니다.

다른 예로 개체에 롤업 요약 필드를 추가할 때 발생하는 상황을 고려하십시오. 이 경우 플랫폼은 효율적인 대량 작업을 사용하여 백그라운드에서 초기 요약을 비동기식으로 계산합니다. 백그라운드 계산이 진행되는 동안 새 필드를 보는 사용자는 플랫폼에서 현재 필드 값을 계산하고 있음을 나타냅니다.

공유 멀티테넌트 시스템 자원의 악의적이거나 의도하지 않은 독점을 방지하기 위해 플랫폼은 플랫폼 코드 실행에 적용되는 광범위한 거버너와 리소스 제한을 갖추고 있습니다. 예를 들어, 플랫폼은 코드 스크립트 실행을 면밀하게 모니터링하고 사용 가능한 CPU 시간, 사용 가능한 메모리 수, 실행할 수 있는 쿼리 및 DML 문 수, 수학 계산 수, 실행할 수 있는 아웃바운드 웹 서비스 호출 수 등을 제한합니다. 플랫폼의 옵티마이저가 실행하기에 너무 비용이 많이 든다고 판단한 개별 쿼리는 런타임 예외를 발생시켜 호출자에게 전달합니다. 이러한 제한은 다소 제약적으로 들릴 수 있지만, 모든 관련 애플리케이션에 대한 공유 데이터베이스 시스템의 확장성과 성능을 보호하기 위해 필요합니다. 장기적으로 이러한 조치는 개발자들 사이에서 더 나은 코딩 기법을 장려하고, 플랫폼을 사용하는 모든 사람에게 더 나은 환경을 조성하는 데 도움이 됩니다. 예를 들어, 처음에 한 번에 한 행씩 천 개의 행을 비효율적으로 업데이트하는 루프를 코딩하려고 시도하는 개발자는 리소스 제한으로 인해 런타임 예외를 받게 되면, 플랫폼의 효율적인 대량 처리 API 호출을 사용하게 됩니다.

잘못 작성된 응용 프로그램이 초래할 수 있는 잠재적인 시스템 문제를 방지하기 위해, 새 프로덕션 응용 프로그램의 배포는 엄격하게 관리됩니다. 조직이 새 응용 프로그램을 개발에서 프로덕션 상태로 전환하기 전에, Salesforce는 응용 프로그램의 플랫폼 코드 루틴의 기능을 검증하는 단위 테스트를 요구합니다. 제출된 단위 테스트는 응용 프로그램의 소스 코드의 75% 이상을 커버해야 합니다.

Salesforce는 플랫폼의 Sandbox 개발 환경에서 제출된 단위 테스트를 실행하여 응용 프로그램 코드가 전체 멀티테넌트 환경의 성능 및 확장성에 부정적인 영향을 미칠지 여부를 판단합니다. 개별 단위 테스트 결과는 총 실행된 줄 수와 테스트에서 실행되지 않은 코드에 대한 특정 정보 등 기본 정보를 나타냅니다.

응용 프로그램의 코드가 Salesforce에서 프로덕션에 대해 인증되면, 응용 프로그램의 배포 프로세스는 응용 프로그램의 모든 메타데이터를 프로덕션 플랫폼 인스턴스에 복사하고 해당 단위 테스트를 재실행하는 단일 트랜잭션으로 구성됩니다. 프로세스의 일부가 실패할 경우 플랫폼에서 트랜잭션을 롤백하고 문제 해결에 도움이 되는 예외를 반환합니다.

참고: Salesforce는 플랫폼의 개발 릴리스마다 모든 응용 프로그램에 대한 단위 테스트를 다시 실행하여 새 시스템 기능 및 개선 사항이 기존 응용 프로그램에 영향을 미치는지 사전에 파악합니다.

프로덕션 응용 프로그램이 운영 환경에 배포된 후 플랫폼의 내장 성능 프로파일러가 자동으로 분석하고 관리자에게 관련 피드백을 제공합니다. 성능 분석 보고서에는 느린 쿼리, 데이터 조작, 하위 루틴에 대한 정보가 포함되어 있으며, 이러한 정보를 검토하고 응용 프로그램 기능을 조정하는 데 사용할 수 있습니다. 시스템은 또한 런타임 예외에 대한 정보를 기록하고 관리자에게 반환하여, 관리자가 응용 프로그램을 디버그하는 데 도움이 됩니다.

앱이 개체에서 레코드를 삭제하면 플랫폼이 MTData에서 행의 IsDeleted 필드를 수정하여 삭제할 행을 표시합니다. 이 작업을 수행하면 행이 _휴지통으로 알려진 것으로 효과적으로 배치됩니다. 플랫폼을 사용하면 휴지통에서 최대 15일 동안 선택한 행을 복원하고 MT_Data에서 영구적으로 제거할 수 있습니다. 플랫폼은 조직의 저장소 제한에 따라 해당 조직에 대해 유지하는 총 레코드 수를 제한합니다.

작업이 마스터-디테일 관계에 있는 상위 레코드를 삭제하면, 참조 무결성 규칙을 위반하지 않는 한 플랫폼이 모든 관련 하위 레코드를 자동으로 삭제합니다. 예를 들어 SalesOrder를 삭제하면, 플랫폼은 종속된 LineItems에도 삭제를 자동으로 연쇄 적용합니다. 이후에 휴지통에서 상위 레코드를 복원할 경우 모든 하위 레코드도 자동으로 복원됩니다.

반대로 조회 관계와 관련된 참조된 상위 레코드를 삭제하면 플랫폼에서 모든 종속 키를 null로 자동으로 설정합니다. 이후에 상위 레코드를 복원하는 경우, 삭제 및 복원 작업 사이에 재할당된 관계를 제외하고 플랫폼은 이전에 null로 설정된 조회 관계를 자동으로 복원합니다.

휴지통은 삭제된 필드와 해당 데이터도 조직에서 영구적으로 삭제하거나 설정된 일 수가 경과될 때까지 저장합니다. 해당 기간이 지나기 전까지 전체 필드와 모든 데이터를 복원할 수 있습니다.

_민첩성_은 기업이 현대 세계에서 성공하기 위한 핵심입니다. Salesforce Platform의 기본 계층은 비즈니스 애플리케이션이 새로운 문제에 신속하게 적응할 수 있도록 도와주어, 인프라가 아닌 비즈니스에 계속 집중할 수 있게 합니다.

인프라 (예: 기본 서비스 및 컴퓨팅 자원)는 Salesforce Platform의 상위 계층을 지원하는 기본 기술입니다. _Hyperforce_는 100% 재생에너지와 넷제로를 기반으로 구축된 Salesforce Platform 인프라로, 규정 준수, 신뢰, 확장성 등 주요 고객 과제를 해결합니다.

여러 지리적 위치에서 운영되는 엔터프라이즈는 데이터 관리에 대한 새로운, 진화하는, 변화하는 규정을 준수해야 합니다. Salesforce는 AWS 리전 가용성을 기반으로 점점 더 많은 국가에 Hyperforce를 배포하고 있으므로, 현재 플랫폼 애플리케이션과 사용자는 엄격한 데이터 저장 또는 데이터 보호 기준을 충족하는 방식으로 민감한 워크로드를 실행할 수 있습니다. 예를 들어, Hyperforce에서 제공하는 _Salesforce의 유럽 연합(EU) 운영 구역_을 통해 EU 기업은 쉽게 데이터를 EU에 보관할 수 있습니다.

보안, 신뢰성, 가용성은 최종 사용자에게 신뢰를 제공하기 위해 모든 비즈니스 애플리케이션이 고려해야 하는 비기능적 요구사항입니다. Hyperforce를 통해 Salesforce Platform은 기업이 신뢰할 수 있는 비즈니스 애플리케이션을 쉽게 제공할 수 있도록 합니다.

• 보안 — Hyperforce는 저장 중 및 전송 중인 고객 데이터를 기본적으로 엔드 투 엔드로 암호화합니다. Hyperforce의 제로 트러스트 아키텍처는 자원에 대한 암시적 액세스가 없도록 엄격한 신원 확인 프로세스를 적용합니다. Hyperforce는 최소 권한의 _원칙_을 사용하므로 작업이 적절한 시간에 적절한 액세스 권한으로 승인됩니다.
• 신뢰성 — Hyperforce의 모든 인스턴스는 여러 개의 클라우드 가용성 영역과 현대화된 접근 방식을 사용하여 발생 응답을 가속화하여 고가용성과 복원성을 갖춘 플랫폼을 제공합니다.
• 가용성 - Hyperforce의 최신 CI/CD 파이프라인과 블루/그린 애플리케이션 릴리즈를 통해 애플리케이션 유지 관리 기간을 1년간 1분으로 최소화할 수 있습니다.

Sales Cloud 및 Service Cloud와 같은 앱의 기반이 되는 Salesforce는 개별 엔터프라이즈 및 서비스 공급자가 공급 체인 관리, 청구, 회계, 상거래, 규정 준수 추적, 인사원 관리, 청구 처리를 비롯한 다양한 사용 사례를 위한 수백만 개의 비즈니스 응용 프로그램을 구축한 입증된 응용 프로그램 개발 플랫폼입니다. 플랫폼의 고유한 멀티테넌트 메타데이터 기반 아키텍처는 클라우드용으로 특별히 설계되었으며, 미션 크리티컬 인터넷 규모 애플리케이션을 신뢰할 수 있고 안전하게 지원합니다. 플랫폼 개발자는 표준 기반 API 및 네이티브 개발 도구를 사용하여 응용 프로그램의 데이터 모델(개체 및 관계 포함), 비즈니스 논리(워크플로 및 확인 포함), 다른 응용 프로그램과의 통합 등 현대 웹 또는 모바일 응용 프로그램의 모든 구성 요소를 쉽게 구축할 수 있습니다.

플랫폼은 출시 이후 Salesforce 엔지니어들에 의해 멀티테넌시에 최적화되었으며, 플랫폼 애플리케이션이 변화하는 비즈니스 수요에 맞게 확장할 수 있도록 하는 기능을 갖추고 있습니다. 대량 데이터 처리 API, Apex, 전체 텍스트 검색 엔진, 고유한 쿼리 최적화기와 같은 통합 시스템 기능은 개발자가 거의 또는 전혀 노력하지 않고도 종속 애플리케이션을 매우 효율적이고 확장 가능하게 만듭니다.

Salesforce의 프로덕션 애플리케이션 배포 관리 접근 방식은 플랫폼에 의존하는 모든 애플리케이션에 뛰어난 성능, 확장성, 신뢰성을 보장합니다. Salesforce는 플랫폼 애플리케이션에서 운영 정보를 지속적으로 모니터링하고 수집하여 기존 및 신규 애플리케이션에 즉각적으로 도움이 되는 점진적 개선 및 새로운 시스템 기능을 촉진합니다.

Steve Bobrowski는 성공적인 기업가이자 기술 리더로서 2008년 이후 Salesforce 전체에서 다양한 역할을 포함하여 여러 주요 엔터프라이즈 소프트웨어 회사에서 근무해 왔으며, 현재 Steve는 Salesforce의 CTO 사무실에서 회사의 기술 아키텍처 전략을 지원합니다.

Tom Leddy는 Salesforce의 아키텍트 에반젤리스트입니다. 그는 아키텍트가 최고의 역량을 발휘할 수 있도록 지원하는 리소스, 도구 및 지침을 만들기 위해 글로벌 Salesforce 아키텍트 커뮤니티를 지원합니다. Twitter에서 Tom과 소통하세요.