SalesforceArchitectGroupOsaka#14_platform-multitenant-architecture

Transcript

1. 内部プラットフォーム処理
2. 要約 2
 • Salesforceプラットフォームの独自の処理アーキテクチャについて述べられている • クエリ ◦ コストベースのクエリオプティマイザーで、マルチテナント仕様および独自テーブル 仕様(MT_DATA等)により、様々な統計情報を駆使 ◦ 内部セキュリティ関連テーブル(グループやメンバー、カスタム共有)等も考慮して いる • 検索 ◦ 最適なキャッシュ機構やインデックスでパフォーマンスを上げている • 一括操作 ◦ 一括処理エンジンが効率的なアプローチを取っている [出典]
3. 要約 3
 • スキーマの変更 ◦ メタデータ設計が活きている ◦ 全体的なパフォーマンスへの影響を軽減する仕組みがある(積み上げ集計項目を 設定→バックグラウンド処理で反映される) • マルチテナントの分離と保護 ◦ ガバナ制限による保護 ◦ テストカバレッジを設けることで潜在的なシステム問題を回避する ◦ デプロイのプロセスもメタデータ設計による恩恵を受けている(エラー時のロール バックが容易) ◦ パフォーマンスの分析を行ってフィードバック • 削除、削除取消、ごみ箱 ◦ 15日間は復元可能 ◦ 子レコードも復元、参照関係も復元 [出典]
4. クエリ 4
 [出典] APIやストアドプロシー ジャなどから呼び出され る。 事前クエリを実行。 統計情報を活用。 最適なクエリを構築。 結果を返す。 事前クエリを実行し、その結果に基づき、クエリオプティマイザ－でマルチテナント環境を 想定した最適なデータベースクエリを作成して実行する
5. クエリ 5
 [出典] 事前クエリにおける実行基準 作成されるデータベースアクセスクエリの内容 ユーザのアクセス 権限レベル 絞り込み条件水準 低 低 ネストされたループ結合 ユーザが参照権限を持つ行のビューを使用 低 高 フィルタに関連付けられたインデックスを使用 高 低 順序を指定したハッシュ結合 MT_DATAテーブルを使用 高 高 フィルタに関連付けられたインデックスを使用 事前クエリで現在のユーザのアクセス権限とクエリの絞り込み条件の水準を評価し、その 結果に基づき、データアクセスを要求するデータベースクエリを作成
6. 感想 6
 • マーティン・ファウラー氏(アジャイルソフトウェア開発宣言やUML等で知られるソフト ウェア開発者)曰く、アーキテクチャとは「変更するのが難しいもの」 • 初期の段階で行った微妙な選択が今も影響している • Salesforceを利用する顧客はそのアーキテクチャを実際に知る必要はない(車を運 転する人が、車がどうして動いているのか知る必要がないのと同じ) • ただ、背後にはこうしたアーキテクチャが歴然として存在し、24時間365日、問題の 解決に日々を費やしている素晴らしいSaleforceのエンジニアのチームがいるという こと • あらためてアーキテクチャの重要性に気づく内容だった [出典] https://engineering.salesforce.com/the-architecture-files-f1dfa7a97e77/