この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
この記事は AWS re:Invent 2014のARC304 - Designing for SaaS: Next-Generation Software Delivery Models on AWSのレポートです。
レポート
次世代のSaaS設計に関する内容です。
なぜSaaSか？
- SaaSの採用が急速に伸びている
- SaaSが可能な物
- 新市場にリーチ
- 既に存在しているものを基に成長する
- 既存企業を崩壊させる
- 新プロダクトのリリースと採用が加速している
SaaSソリューション設計のベストプラクティス
- プログラムからプラットフォームを分ける
- 抽象化を通じた将来性
- マルチ-マルチ-テナントのための設計
- あなたのデータのライフサイクルを知る
- 全てを集めて、そこから学ぶ
- コストと性能の最適化
- 安全と隔離
データライフサイクル管理の例
時間軸によってデータを変換、集計/集約を行い、データストアを入れ替える事により、アクセス速度をやコストを最適化します。 例えば、数分単位の場合は、Kinesisで受けて集計しS3へ保存したり、RDSで保存をします。 数時間の場合は、EMR等で処理をしDynamoDBへ保存します。 数日単位の場合は、Redshiftへ保存します。 数週間単位の場合は、RedshiftのデータをEMR等でさらに処理し、Redshiftへ保存します。 数ヶ月単位の場合は、S3へ保存します。 年単位の場合は、Glacierへアーカイブします。
SaaSコンポーネント・アーキテクチャ - 監視
Kinesis、S3、DynamoDB、RDS(RDSはまだ対応していないですね)等のアプリケーションデータをLambdaで処理しSQSへ登録したり、アプリケーションの行動をSQSへ登録します。キューの内容処理して監視や分析の機能へ渡します。
SaaSコンポーネント- 分析
アプリデータ、計測データ、課金データをData PipelineでS3で変換しS3へ保存します。S3のデータをそのままRedshiftへ保存したり、EMRで集約や分析してRedshidtやS3へ保存します。ユーザは、レポートやクエリでデータを参照します。
SaaS on AWS：アーキテクチャ上のアプローチ
- 隔離された顧客のスタック
顧客毎に独立したAWSリソース
- 純粋なSaaSの共有アーキテクチャ
上から下まで共有インフラストラクチャでのオンデマンドリソース利用
- 共有プラットフォーム上のコンテナ化
Amazon EC2 Container Service(ECS)とDockerでAWSの薄片を提供する
SaaS on AWSによりあなたの顧客に集中できる
- AWSの柔軟性 → 費用効果の高い方法でアプリケーションのニーズに素早く対応する
- AWSのイノベーション → 全てを自分で構築する事無く最新の業界動向に追いつく
- AWSのエコシステム → AWSプラットフォームで巨人の肩に立つ
まとめ
Designing for SaaSは自分が聞いた中で、一番勉強になったセッションです。 発表されたばかりのLambdaやECSを自然に使用しているアーキテクチャを例示しており、新サービスの利用例としても非常に勉強になりました。データライフサイクルの階層化や、システムのインフラ集約の参考に丁度良いセッションでした。 SaaSを主題としていますが、企業内システムでも同様のアーキテクチャを考えて行く必要があると思います。システム毎のITインフラを構築せずに、本セッションの様な全体のインフラ基盤を構築して、ビジネスを加速させましょう。
0
