どのクラウドを使って設計すべきか？

どのクラウドを使って設計すべきか？
～クラウドシステムアーキテクチャ 2016 ～
株式会社テラスカイ
取締役
ソリューション本部本部長
今岡純二
@junojisan

自己紹介
Copyright © TerraSky Co., Ltd. All Rights Reserved.
salesforce.com認定資格ほか
主な業務
・導入コンサル
・アーキテクチャーデザイン
・テクニカルライティング
著書
株式会社テラスカイ
取締役ソリューション本部本部長
今岡純二 @junojisan

クラウドに Salesforce を選択した時
アーキテクチャとして何を検討しなくてはならない？

アーキテクチャが重要視される背景
大規模かつ複雑なプロジェクト
システム連携、SSO、複数の組織、大量データ、モバイル、SNS、デバイス…
Salesforceだけでは実現できない…
他のクラウドサービスとの併用
柔軟、堅牢、スケーラブル、セキュアな
設計および実装が求められている

ハイレベルな検討ポイント
プラットフォーム
特性・制限
アプリケーション
設計パターン
開発ライフサイクル&
デプロイ戦略
セキュリティ&
ID管理
コミュニケーション
インテグレーション
パターン

プラットフォーム特性・制限の検討ポイント
1 ライセンスの機能と制約
2 ガバナ制限等のプラットフォームの制限
3 大容量データを扱う場合の設計の考慮事項
特に社外ユーザも使う場合のライセンス選択には注意
Too many SOQL、Too many query rows以外にも注意（後述）
外部ID、カスタムインデックス、ディビジョン、スキニーテーブル…
パフォーマンスを悪化させる要素（ロール階層、ネストした公開グループ…）
代表的なもの

インテグレーションの検討ポイント
• 連携元／連携先
• プロトコル／API
• データソース
連携対象
• ロジック連携
• データ同期
連携タイプ
• リアル／バッチ
• 同期／非同期
タイミング
• 少量／大量
• 常時／随時／定期
データ量&頻度

パターンに学ぶ
ロジック連携リアルタイム同期
非同期
Visualforce +
Apex Controller +
Apex SOAP or Rest
Outbound Message
Apex Trigger +
@future +
Apex SOAP or Rest
Streaming API
プ
ラ
ッ
ト
フ
ォ
ー
ム
の
制
限
の
考
慮
例）Salesforce → 外部システム

事例に学ぶ
受注ヘッダ
受注明細
商品画像
発注ヘッダ
発注明細
商品構成
トランザクション
トランザクション
汎用API
Apex Rest
Trigger
Trigger
W/F
Proc
Builder
ERP
モバイル
Apex heap size too large
→ 処理するデータ量が大きい。
Apex CPU time limit exceeded
→ DescribeGlobalの多用。CPUコスト高い。
→ Dynamic DMLもCPUコスト高い。
→ Trigger、W/F、Process BuilderなどのCPUコストも注意。
string length exceeds maximum:6000000
→ リクエストJSON大き過ぎ。バイナリを扱うなら要注意。

どちらが望ましい姿？
iPaaS

トレードオフとオプション
標準開発
個別開発
社内 B to C
 品質
 生産性
 保守性
 バージョンアップ
 ユーザビリティ
 開発者の確保
 開発・保守費用
（例）標準開発 vs 個別開発

クラウドに Salesforce を選択した時
アーキテクチャとして何を検討しなくてはならない？
プラットフォーム
特性・制限
アプリケーション
設計パターン
開発ライフサイクル
&デプロイ戦略
セキュリティ&
ID管理
コミュニケーション
インテグレーション
パターン

ありがとうございました

どのクラウドを使って設計すべきか？

More Related Content

What's hot

Similar to どのクラウドを使って設計すべきか？

More from Junji Imaoka

どのクラウドを使って設計すべきか？

Editor's Notes