PaaSの起源と発展 株式会社アプライド・マーケティング 大越　章司 shoji@appliedmarketing.co.jp.

Presentation on theme: "PaaSの起源と発展 株式会社アプライド・マーケティング 大越　章司 shoji@appliedmarketing.co.jp."— Presentation transcript:

1 PaaSの起源と発展 株式会社アプライド・マーケティング 大越　章司

2 クラウドの定義／サービス・モデル (Service Model)
SaaS アプリケーション アプリケーション Software as a Service プラットフォーム PaaS ミドルウェア ミドルウェア&OS Platform as a Service オペレーティング システム IaaS ハードウェア マシン Infrastructure as a Service Salesfoce.com Google Apps Microsoft Office 365 Microsoft Azure Force.com Google App Engine Amazon EC2 IIJ GIO Cloud Google Cloud Platform

3 ASPからSaaSへ、ホスティングからIaaSへ
オンプレミス サービスプロバイダ クラウド アプリケーション ASP (Application Service Provider) ネットワーク上のサーバーにパッケージソフトを搭載してネットワーク越しに提供 SaaS (1999~) マルチテナント対応アプリケーションを「サービス」として提供し、従量課金 SaaS ミドルウェア PaaS (2007~) Salesforceのサービス開始は1999年 AWSの公開は2006年7月 OS/ハードウェア Hosting/Housing データセンターのサーバーをネットワーク越しに提供 IaaS (2006~) リソースを「サービス」として提供し、従量課金 IaaS

4 Salesforce (1999) Salesforce PaaSの誕生
Salesforceの顧客から、Salesforceが持っているデータベース、ワークフローなどの機能を使ってCRM以外のアプリを作成したいという要望が高まった Salesforce Database Workflow Other User App User App APIを整備して公開 (2007.7) → Force.com (2007) → database.com (2010) 　　マルチテナントDB

5 全社規模の基幹システムであればコストをかけてシステムを開発できる
Force.comのターゲットマーケット 全社規模の基幹システムであればコストをかけてシステムを開発できる 消費者 全社 部門 グループ 部門レベルでは、コストをかけられない一方で変化の速度が速いため、改修が頻繁に起こるため、IT部門もSIerも対応しにくい。 このためユーザーが自分で作る必要があるが、一から作るのは大変なため、何からのツールが必要。 → Notesのマクロ → Excel/Access ユーザーのタイプ コンテンツ　　　データ　　　　 プロセス　 トランザクション アプリケーションのタイプ Excel 以上、全社システム以下

6 アプリ開発基盤としての Lotus Notes
グループウェア＝グループ内での情報共有、コミュニケーション、コラボレーションを支援するソフトウェアスイート グループウェアのアイデアは1960年代末からあった 様々なコミュニケーション機能をワンパッケージ化 電子メール スケジューラ PCの普及により情報量が増大し、情報の効率的共有へのニーズが増した ライブラリ ワークフロー （電子決裁） BBS 電子会議室 (1989)＝インターネット直前 インターネットの商用利用開始は1988年 当時Lotus Notesが大企業に受け入れられた理由 細い回線でも効率的にレプリケーションを行うことができ、複数の拠点を持つ大企業にとって使い勝手が良かった 強力で柔軟なスクリプトにより、ワークフローを比較的簡単に作り込むことができた Lock-in

7 BaaS (Backend as a Service)/MBaaS
アプリケーション BaaS Webサービスを構築する際に共通して必要となる機能をサービスとして用意し、パッケージで提供する ミドルウェア ユーザー管理 SaaS BaaS OS プッシュ通知 PaaS ソーシャルメディア連携 IaaS ハードウェア 課金・決済処理 同期・共有・バックアップ BaaSは元々モバイル向けサービスとして発表されたが、最近ではモバイル用のBaaSをMBaaSと呼ぶこともある ユーザー間のチャット ロケーション連携

8 様々なXaaSが考案され、従来の分類に収まらなくなった
アプリケーション ミドルウェア SaaS XaaS OS Force.com Database.com Amazon RDS IaaS ハードウェア 仮想マシン ベアメタル 様々なXaaSが考案され、従来の分類に収まらなくなった

9 Force.comはいつの間にかAPaaSに

10 戦略アプリはPaaSで作る

11 マッシュアップ開発の部品としてのWebサービス
クラウドサービス API マッシュアップ開発 IT の深い知識がなくても、既存のWebサービスAPIを組み合わせて、短期間でアプリケーション開発を行うこと。新しい開発技法として注目されている。 マッシュアップ 自社サービス クラウドサービス API OSSパッケージ API 様々なWebサービスやBaaSなどのサービス、豊富なOSSなどにより、新たなプログラミングをせずにアプリケーションを開発することが可能になってきた

12 簡単なマッシュアップの例

13 Webサービスを組み合わせてシステムを構築
　SoftLayer IaaS サービス 自社サーバー Gmail ML Docs Google サービスの部品化により クラウドの活用範囲が拡大 EC2 Aurora Lambda Amazon クラウド上のサービスを 組み合わせてシステムを構築 APIが整備されれば、様々なWebサービスを組み合わせるだけで、自分ではプログラムを書かなくても相当高度な処理を行えるようになっていくことが期待されます。

14 APIエコノミー 14

15 APIエコノミー = 企業間でサービスを連携
API = プログラムAからプログラムBの機能を呼び出し、その実行結果を戻り値として受け取る アプリケーション プログラム A 　　　　 アプリケーション 　　　　プログラム　B APIの呼び出し API Application Program Interface 戻り値の返信 APIエコノミー = サービスAからサービスBの機能を呼び出し、その実行結果を戻り値として受け取る 企業 A 企業 B APIの呼び出し API Application Program Interface サービス A サービス B 戻り値の返信 「Instagramで取得した位置情報をUberに送りタクシーを配車してもらう」など

16 IBMが仕掛けるAPIエコノミー IBMはBlueMIXというPaaSを推進しています。 IaaSはもはやAmazonの独壇場で、追いつくことは難しくなっているため、IBMとしてはPaaSの分野での勝負を賭けると言うことでしょう。IBMは最近、PaaSを有効活用するためにAPIの整備が必要と言うことで、APIエコノミーという言葉を作ってプロモーションしています。

17

18 サーバーレス 18

19 構築事例：AWSサービスを最大限活かしたアーキテクチャ
※2015/3/20時点 Webサーバー機能 3箇所以上で自動複製、容量無制限 リージョン:東京 ＜S3＞ 料金：$0.0330/GB +リクエスト数+データ転送量 ＜CloudFront＞ 料金：$7.2/年 （試算した結果） <Lambda> 料金：$0 ＜DynamoDB＞ 料金：$0　（試算した結果） メールサーバー不要 S3 コンテンツ Cloud Watch 入力ページ（HTML） Log等 Cloud Front 非公開コンテンツ Internet AWS認証 アプリ認証 SignedURL発行 サーバ側アプリ キャッシュ SSL証明書 Cognito 任意のタイミングで処理実行 負荷分散、障害対策はAWS任せ クライアント Lambda Node.js 年間：約$7.56 約907円 JavaScript DynamoDB テーブル 画面表示は、 クライアント側 アプリ 冗長構成、拡張・データ再配置 はAWS任せ ※条件によって料金は異なります

20 AWS Lambda プログラムを「関数」としてアップロード サーバーやサービスを立ち上げておく/ いちいち立ち上げる必要無し
イベント(トリガ)により処理を起動 課金は処理に要した時間のみ メモリ容量や処理能力は自動で設定 毎日数件から毎秒数千件まで自動的にスケール クラウド処理のためサーバー障害が発生しない AWS以外の様々なWebサービスにも対応 イベントドリブンで最小限の処理を行う = IoTなどで活用

21 サーバーレスとサーバーレスアーキテクチャ
サーバーレス = サーバーのセットアップや管理を行わなくともプログラムを実行できる 独立したWebサービスを 連携させる Webサービスを コンポーネントとして利用 クラウド上の コンポーネント連携 サーバー上でサービスが 待機/稼働 サーバー上でマイクロサービスが待機/稼働 イベントにより ナノサービスを起動 ASP/SaaS BaaS/mBaaS マイクロサービス FaaS ナノサービス PaaS API連携 AWS Lambda Azure Functions Google Cloud Functions IBM OpenWhisk FaaS = Function as a Service IFTTT/マッシュアップ 様々なXaaS サーバー維持費用が必要 サーバー維持費用が必要 または従量制 完全従量制 サーバーレス アーキテクチャ

22 ASPとSaaSの違い 22

23 ASPとSaaSの違い – マルチテナント ASP SaaS アプリケーション マルチテナントDB または 複数企業での共有を前提とした設計
顧客 顧客 顧客 顧客 顧客 顧客 データセンター データセンター アプリ アプリ アプリ アプリケーション サーバー サーバー サーバー マルチテナントDB 仮想化 または サーバー サーバー サーバー データセンター アプリ アプリ アプリ 仮想化 複数企業での共有を前提とした設計 データの分離、セキュリティに配慮 メンテナンスコストが低い リソースの利用効率が高い サーバー サーバー パッケージをそのまま使用

24 マルチテナントの効果 メモリ消費量に1,000倍の違い
メモリ消費量に1,000倍の違い

25 Oracle 12cのマルチテナントアーキテクチャ
マルチテナンシーの効果についてはOracleも注目していました。SaaSのためというよりは、企業内に増え続けるデータベースの統合をより効率的に行うためです。 「Oracle Databaseの管理者の37％は、1人で50以上のデータベースを管理している」というデータがあるということですが、企業システムが今後プライベートクラウド環境に向かう中で、データベースはさらに増える可能性があります。こういった増え続けるデータベースの管理を効率化し、ハードウェアコストを低下させる決め手とされ、Oracle12cから採用されたのがマルチテナントアーキテクチャです。 データベース統合の手法として、個の記事では「仮想マシン」を使った統合、同一のOS上で複数のデータベースインスタンスを実行する「複数インスタンス」、そしてデータベースインスタンスまで共有する「スキーマ統合」に分類しています。このうち、運用管理の負担を最も軽減できるのがスキーマ統合で、「この方法ではデータベースインスタンスまで共有するため、高い密度で統合でき、管理コストの削減が可能となる。」と言っています。 一方で、統合の難易度は高く、これをサポートできるDBMSの開発が必要でした。その答えがマルチテナントアーキテクチャだったのです。 コンテナデータベース(CDB)上にプラガブルデータベース(PDB)を作成 ひとつのインスタンスで複数のスキーマを運用 スキーマ統合を課題を解決