SOA/PaaS/API/マイクロサービス/サーバーレス

Presentation on theme: "SOA/PaaS/API/マイクロサービス/サーバーレス"— Presentation transcript:

1 SOA/PaaS/API/マイクロサービス/サーバーレス
サービスオリエンテッドな世界 SOA/PaaS/API/マイクロサービス/サーバーレス 株式会社アプライド・マーケティング 大越　章司

2 ソフトウェアの部品化 2

3 ソフトウェア再利用の歴史 1967年 1968年 1970年代 オブジェクト指向プログラミング
ソフトウェア工学（Software Engineering）の提唱 NATOサイエンス・コミッティ 1968年 ソフトウェア部品（Software Component）の提唱 M.D. McIlroy （AT&T Bell Lab.） 「我々は明らかに時代遅れのテクニックを用いてソフトウエアを作成している」 工業における大量生産の手法をソフトウエア開発に導入することを提案 ソフトウエアをあたかも「部品」のように扱える形でキープしておく。ソフト部品は自社で作成してもいいし，外部から調達してもよい。そして，適切なソフト部品を探し出し，場合によっては新たに部品を作り，それらの部品を“組み立てる”ことでアプリケーションを作成する。 1970年代 オブジェクト指向プログラミング Smalltalk VBX C++ OCX（ActiveX） Java DCOM（Distributed Component Object Model） OpenDoc CORBA（Common Object Request Broker Architecture）

4 ソフトウェア部品化の粒度 粒度 アプリケーションレベルの部品化 (SaaS、Webアプリ)
ひとまとまりのサービスとして定義することで、再利用しやすくできる サービスレベルの部品化 (PaaS、Webサービス、SOA) サブルーチン/プログラムモジュールレベルの部品化 再利用のメリットに比べ、手間などのコストが高い 開発ライブラリレベルの部品化 明確な機能単位で部品化できるため、再利用しやすい OSレベルの部品化 (システムコール)

5 部品から作る

6 サービスをつなぐ 入出力I/Fの 標準化が必要

7 Service Oriented Architecture
7

8 SOA EAI (1990年代末) SOA (2000年前後) 従来は部分最適な業務システム 全社最適化手法
個別にシステム設計開発 現場の仕事をそのままシステム化 「その時点」での技術を使って開発 他システムとの連携は必要に応じて設計・実装 全社的最適化という視点はない 全社最適化手法 EA Enterprise Architecture BPR Business Process Re-engineering BPM Business Process Management ERP Enterprise Resource Planning 既存システムを相互接続して統合 ビジネスプロセスを サービスとして実装 2000年前後に、ビジネスプロセスの考え方をベースにしたシステム構築における新しい考え方が出てきます。それがSOAです。 SOAはERPとは直接関係はありません。大規模なシステムを如何に効率よく、柔軟性を持たせたまま構築するべきか、と言うシステム構築の方法論です。 ソフトウェア開発において、一部を部品化して再利用するという取り組みは長く行われてきました。SOAは、その部品化の粒度をビジネスプロセスに求めたのです。業務の最小単位をサービスとして実装することにより、開発効率の向上を目指したのです。 SOAは発表当初非常に期待されましたが、数年後には姿を消してしまいました。「SOAは使い物にならない」という烙印を押されてしまったのです。 しかし、クラウド時代になって、SOAのメリットが再認識されるようになってきました。 EAI (1990年代末) ばらばらに開発された業務システムをプロトコル変換などで統合 SOA (2000年前後) ビジネスプロセスをサービスとして実装 クラウドとの親和性

9 SOAは思想であり考え方 クラウドと親和性が高い
SOAの定義 (Wikipedia) 業務上の一処理に相当する単位でソフトウェアが構成されていること。SOAにおけるサービスとは、その構成単位のことである。プログラム上の部品ではなく、たとえば「決済する」「在庫状況を照会する」などの単位で一つのサービスとすることが求められる。どの程度の規模(粒度)を一つのサービスとするが良いのかについては様々な議論がある。 オープンで標準化されている技術仕様を用いてサービスのインタフェースが定義され、それに従った呼び出し、応答が可能であること。その技術的基盤として、Webサービスの使用が事実上必須となっている。 サービスをネットワーク上で連携させてシステムの全体を素早く構築できること。この段階にいたるまでには、先の二つの条件が必須となる。さらに、サービスを単位として業務処理の流れを記述する技術や、その記述通りにシステム連携を実行する技術も必要となる。 SOAとは、ビジネスプロセスに沿って業務システムを構築することであり、システム構築の手法(思想)といえる。 SOAについてWikipediaを見てみると、このような説明になります。よくわかりませんね。 Wikipediaで言っている「業務上の一処理に相当する単位」とは、ビジネスプロセスのことです。つまり、SOAは、ビジネスプロセスに沿って業務システムを構築することであるといえます。 ここで大事なのは、SOAという製品は存在しないということです。SOAという考え方に基づいて、大規模なシステムを個々のプロセスに対応するサービスの集まりとして構築するということで、システム構築の方法論であり、考え方なのです。 SOAがこの時点で見直されてきた最大の要因は、クラウドとの親和性が非常に高い、ということです。ビジネスプロセスをWebサービスとして実装することにより、簡単にクラウド上に展開できるからです。 ですから、Webサービス＝SOAということではありません。ただ、実装方法としてWebサービスが使われることが多く、そのほうが活用しやすい、ということです。 WebアプリケーションサーバーやSOAPなどは、SOAによるシステム構築のための技術的要素に過ぎないといえます。 SOAという製品は存在しない。SOAという考え方に基づいて、大規模なシステムを個々のプロセスに対応するサービスの集まりとして構築する。 実装方法としてWebサービスが使われることが多いが、SOA=Webサービスではない。XML、RestやSOAPなどはSOAによるシステム構築のための技術的要素に過ぎない。 クラウドと親和性が高い

10 サーバーとクライアントの関係の変遷 クライアント・サーバー Webシステム RIC/RIA サーバー サーバー サーバー Webサーバー
Windows クライアント・サーバー サーバー 業務個別 プログラム 管理コストの増大 ベンダーロックイン Webシステム ブラウザー サーバー Webサーバー 業務個別 プログラム ブラウザの機能不足 マルチプラットフォーム対応 RIC/RIA ブラウザー + プラグイン サーバー Webサーバー 業務個別 プログラム プラグインによる ブラウザの機能強化 マルチプラットフォーム対応 こうしてできたのが、Webブラウザーをクライアントとして使おうとするWebシステムです。 クライアント・サーバー メインフレームの時代、クライアントは、文字しか表示・入力できないものでした。パソコンの出現は、この操作をパソコンに肩代わりさせ、表現力と操作性を高め、大きな処理やデータ管理を強力なサーバーに任せ、連携・役割分担して使う「クライアント・サーバー」を誕生させたのです。 Webシステム 「クライアント・サーバー」は、表現力と操作性を向上させた一方で、業務ごとにクライアント用のソフトウェアを開発・導入、トラブル対応、バージョンアップなどの運用管理負担は大幅に増やしました。 そこに登場したのが「Webシステム」です。1995年のWindows95以降、パソコンに標準装備されたブラウザで業務システムを利用しようというものです。これにより、業務個別のプログラムを開発しなくても高い表現力や操作性を実現できると期待されたのですが、当時のブラウザでは機能が足りず、使い勝手が良くなかったことから、あまり広がりませんでした。ただ、ブラウザは様々なデバイスで動作するため、Windowsへのベンダーロックインを回避できる可能性もありました。この考え方は後のクラウドに繋がる重要な発想となったのです。 この頃、Webサービスという言葉が使われ始めます。Wikipediaによると、Webサービスは「W3Cにおいては、Webサービスとは、さまざまなプラットフォーム上で動作する異なるソフトウェア同士が相互運用するための標準的な手段を提供するものと説明されている。」とされています。 RICとRIA 次に登場したのが、「プラグイン」の利用です。プラグインとは、標準のブラウザではできない機能を、ブラウザにプログラムを組み込むことで実現する仕組みです。例えば、アニメーションやビデオ、高機能な入力フォームを実現するFlashはその代表です。 このようなブラウザはRIC（Rich Internet Client）、それを使ったアプリケーションはRIA（Rich Internet Application）と言われ、表現力と操作性も高まり、利用者も増えてゆきました。 「Webサービス」の誕生

11 SOA (Service Oriented Architecture)
従来型のシステム構築手法による販売管理システム 受注 請求・入金 出荷 ビジネスプロセスに合わせてシステムを構築していない場合、後で変更するのが大変 他のシステムとの連携を考えていない場合 (インターフェースの標準化が行われていない)、後から付け加えるのは大変な作業になる 伝票のフローに沿ったシステム 要求仕様 販売管理プロセス 業務上の一処理に相当する機能をサービスとして実装 (共通のI/Fを定義) 受注 請求 入金 出荷 プロセス単位で サービス化 情報のフローに沿ったシステム SOAによる実装とは、ビジネスプロセスに対応させたモジュール構成とすることです。具体的な例を挙げて説明しましょう。 もう一度、先ほどの販売管理のプロセスを使いましょう。とある企業における販売管理の業務プロセスです。 受注して、請求処理をして、入金を確認したら商品を出荷する、という流れです。 一般的なシステム開発では、先ほどもお話ししたように、現在行っているプロセスを元にして要求仕様を作成します。 プログラマは、要求仕様を元に実装計画を作ります。ここでは、請求・入金は会計的処理なので一つのモジュールにしよう、という決定が下されたとします。 こうして、受注処理モジュール、請求・入金確認モジュール、出荷管理モジュールの3つでシステムを構築します。 ところが、競合状況が厳しくなり、顧客からの要望により、請求後、入金を確認できる前に出荷するというプロセスに変更する必要が出てきました。 この際、システム側でうまく対応できるかどうかは運次第です。要求仕様にはそんなことは書いてありませんから、モジュールの構造上そんなことはできないかも知れません。あるいは、そんな事態にも対応できるよう、設計されているかもしれません。 対応できなければ、改修に多額の費用と時間をかけるか、プロセスの変更を断念するかという選択になります。どちらの場合でも、ビジネスに良い影響がある訳はありません。 SOAの考え方は、ビジネスプロセスをサービスとして捉え、プロセス単位でモジュール化することです。モジュール間のインターフェースさえきちんとしていれば、先ほどのようなプロセスの組み替え要求にも柔軟かつ迅速に対応できるわけです。 言い換えれば、従来型は書類の流れに沿って作られたシステムであり、SOAによる実装は、情報の流れに注目した手法であると言うことができるでしょう。 もちろんこれは相当に単純化したモデルであり、元になるビジネスプロセスがしっかり見直され、粒度も適切である必要があります。 SOAによる販売管理システム 受注 請求 入金 出荷 プロセスの各業務単位(サービス)に合わせてソフトウェアを作ってあるので、後でプロセスが変わっても柔軟に対応できる サービス間でやりとりするデータの種類とフォーマットをXML等で決めて標準化 さらに、各ソフトをWebアプリ (Webサービス)にしておくと、将来のクラウド対応など、柔軟性が高まる ビジネスプロセスの変更にも柔軟に対応可能 受注 出荷 請求 入金

12 ビジネスプロセスをサービスとして実装 サービス Webサービス ひとまとまりの機能(サービス)を提供する独立したプロセス単位で実装
入力と出力を定義 順序の入れ替えや機能の追加が容易 販売管理のビジネスプロセス 受注 請求 入金 出荷 Webサービス 例えば、とある企業における販売管理の業務プロセスを考える場合、こういった流れになったとします。受注して、請求処理をして、入金を確認したら商品を出荷する、という流れです。 この販売管理プロセス自身、さらに細かいプロセスから構成されます。例えば、請求処理であれば、金額・納期の確認や請求書の発行、発送といったプロセスに分解できるでしょう。 一方で、このプロセスは、より上位のプロセスの一部でもあります。営業活動や製造・在庫管理などと連携しています。 ビジネスプロセスの要件としては、一連の作業をひとまとめにして、ひとつの目的を達成できること、情報の入出力があること。 どういった情報が必要で、プロセスの終わりにどういった情報を出力するかを明確に定義できなければなりません。 さらに、必要な情報さえ揃っているならば、ビジネスプロセスの単位で独立してそれを繰り返すことができること。 効果が測定できるというのは、アウトプットが明確でそれを定量化できるということです。 そして、ご覧のようにビジネスプロセスは階層化されています。 このように業務手順を分解してビジネスプロセスに落とし込むことにより、業務の流れが可視化され、繋がりが明確になり、どのような情報がどのように流れているのかがわかるようになります。 それらが明らかになることにより、ビジネス環境の変化が起きた場合に、どこを直せば良いかがすぐにわかり、変化に柔軟に対応できるようになります。 さらに、このようにビジネスプロセスを明確にした上で、アプリケーションコンポーネントとして実装したものを「サービス」と呼びます。明確に定義されたインターフェースを持ち、外部から呼び出すことができ、決められた入力に対して出力を返します。 ビジネスプロセスを考えるときに特に難しいのが、どこまでをひとつのプロセスとして切り出すか、という「粒度」の問題なのですが、これは開発するシステムの目的や業務内容によって変わります。 HTTP、XML、Rest、SOAPなどの インターネット技術を使って実装 クラウドへの展開が容易

13 SOAの狙いと成果 柔軟性の向上 管理の容易さ 迅速な開発 業務プロセスを見直し、サービス単位に分割
サービス間のデータ交換ルールを決め、メカニズムを構築 サービス単位でプログラムを開発し、相互に接続 情報システムを分割し、疎結合させる こうしてみると、SOAの本質は「情報システムをビジネスプロセスに分解して個々にサービスとして実装し、お互いを緩く連結してシステムを構築すること」と言えます。 これにより、システムの柔軟性を高め、管理が容易になり、開発速度を向上させることができます。アジャイル開発なども、SOAの考え方が大きく影響しています。 柔軟性の向上 管理の容易さ 迅速な開発

14 小規模なシステムならWebサービスベースでも可
SOA製品としてのESB SOAをベースにした販売管理プロセス 小規模なシステムならWebサービスベースでも可 受注 請求 入金 出荷 ビジネスプロセスの変更にも柔軟に対応可能 受注 請求 出荷 入金 前スライドで説明したように、プロセス単位でサービスを実装し、後の組み替えにも対応するという方法は、小規模なシステムであれば有効ですが、大きなシステムになるとコードの見通しも悪くなり、効率的ではなくなります。 そのため、モジュール間の汎用的な接続方法を提供するためにESB (Enterprise Service Bus) が考え出されました。サービスモジュール向けの標準的なAPIや、開発支援ツール、データの流れを制御するツールなどが含まれています。様々なサービスやシステムを接続することができます。 SOAという製品はありませんが、ESBという製品はあります。このため、ESBのことをSOAだと思っている人もいますが、これもまた正しくないと言えます。 受注 請求 入金 出荷 ESB その他のサービス レガシーシステムなど 大規模なシステムではESBが有効

15 EAIとESBの違いは無くなりつつある EAIとESB ESB EAI アダプタを介した密結合 独自技術ベース プロトコル変換
旧システムをそのまま結合できる 開発・保守は大変 EAIとESBの違いは無くなりつつある プロトコル変換 メッセージ変換 ルーティング ESB 前にお話ししたEAIとの共通性に気づかれたでしょうか？EAIはシステムを、ESBはサービスを結合するためのデータ交換用基盤と見ることができます。 実際、EAIツールはESB的な機能をどんどん実装してきており、両者間の違いは無くなりつつあると言えます。 SOAP/HTTP SOAP/MOM (Message Oriented Middleware) JMS (Java Messaging Service)　等 分散・疎結合 標準技術ベース 開発・保守が容易 プロセスの組み替えが容易

16 モジュールをWebサービス化することのメリット
SOAはクラウドと相性が良い ハイブリッドクラウド パブリッククラウド こういった形で、ビジネスプロセスをWebサービスとして実装しておくと、クラウドとの相性が非常によくなります。 たとえば最初はオンプレミスで全てを稼働させている場合、これはWeb技術の上で稼働させていますから、プライベートクラウド上で動かしていることになります。 決算期や繁忙期でシステムリソースが足りなくなってきた場合、必要に応じてサービスをパブリッククラウド上で実行させることにより、社内にハードウェアを追加しなくとも、需要の急増に応えることができます。必要に応じてハイブリッドクラウドに移行できるわけです。 このとき、外部に出したくないものは出さない、という選択ももちろん可能です。 プライベートクラウド

17 PaaSの多様化とマッシュアップ 17

18 様々なXaaSが考案され、従来の分類に収まらなくなった
XaaS = Webサービスの多様化 アプリケーション ミドルウェア SaaS XaaS OS XaaS XaaS IaaS ハードウェア 仮想マシン ベアメタル 様々なXaaSが考案され、従来の分類に収まらなくなった

19 マッシュアップ開発の部品としてのWebサービス
　クラウドサービス API マッシュアップ開発 IT の深い知識がなくても、既存のWebサービスAPIを組み合わせて、短期間でアプリケーション開発を行うこと。新しい開発技法として注目されている。 マッシュアップ 自社サービス 　クラウドサービス API クラウドサービスを組み合わせてシステムをつくるのが、マッシュアップです。 このとき大事なのが、Webサービスが提供するAPIです。 APIはもともとプログラミングの用語で、外部からプログラムの機能やデータにアクセスするための手順やデータ形式のことです。 Windows用のアプリケーションを開発する際には、Windows APIに従ってプログラムを作らなければなりません。 逆に、APIを使うことによって、自分で全てを作らなくても、Windowsがあらかじめ備えている機能を利用することができます。 Webサービスを組み合わせるときにも、APIが公開されていることが必要です。これを使うことで、そのWebサービスが備えている機能や、持っているデータを使うことができるのです。WebサービスのAPIをWebAPIと言うこともあります。 　クラウドサービス API 様々なWebサービスやBaaSなどのサービス、豊富なOSSなどにより、新たなプログラミングをせずにアプリケーションを開発することが可能になってきた Application Programming Interface 外部からプログラムの機能やデータにアクセスするための手順やデータ形式

20 マッシュアップの例 簡単なマッシュアップの例です。自社のサイトにGoogle Mapsの画面を貼っています。
Google MapsのAPIを使うことにより、自分で地図を作らなくても、Google Mapsの機能を利用することができるわけです。

21 Microsoftも同様のサービスを開始 (ビジネスプロセスの自動化)
IFTTT Webサービスを連携 させるサービス Microsoftも同様のサービスを開始 (ビジネスプロセスの自動化)

22 APIエコノミー 22

23 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に送りタクシーを配車してもらう」など

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

25 機能やデータを相互に活用することで 新たなビジネスを生み出す
API市場は2.2兆ドル 自社で全てを開発しなくとも良い APIの公開で収益を得る 機能やデータを相互に活用することで 新たなビジネスを生み出す 「IBMは2015年11月の時点で市場は2.2兆ドルと推定し、今後2～3年内にAPIプログラムを持つ企業数は150パーセントの増加を予測している。」

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

27 マイクロサービスと サーバーレスアーキテクチャ 27

28 SOAからマイクロサービスへ マイクロサービスはJames Lewis氏によって提案された言葉です。ひとつのアプリケーションを、一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。 マイクロサービスはSOAの焼き直しに過ぎないという主張もあるとおり、狙いは非常に似ています。しかし、SOAがビジネスプロセスに着目した考えであるのに対し、マイクロサービスはプログラミングの視点から語られることが多いようです。 Microsoftは2015年にマイクロサービス用のプラットフォームを発表しました。

29 ファストリがマイクロサービスを導入

30 サーバーレスアーキテクチャ

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

32 コンテナで運用

33 サーバーレスとサーバーレスアーキテクチャ
サーバーレス = サーバーのセットアップや管理を行わなくともプログラムを実行できる 独立した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 サーバーレス アーキテクチャ

34 補足資料: PaaSの誕生 34

35 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

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

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

38 ASPとSaaSの違い – マルチテナント ASP SaaS アプリケーション マルチテナントDB または 複数企業での共有を前提とした設計
顧客 顧客 顧客 顧客 顧客 顧客 データセンター データセンター アプリ アプリ アプリ アプリケーション サーバー サーバー サーバー マルチテナントDB 仮想化 または サーバー サーバー サーバー データセンター アプリ アプリ アプリ ASPの基本的な考え方は、パッケージとして提供していたソフトウェア製品をサーバー上でホスティングしてネット越しに提供するというものです。 この場合、多くの場合アプリケーション自身はパッケージ製品と同じもので、データセンター内の物理サーバーにインストールされたり、仮想サーバー上にインストールされます。 これらアプリケーションはもともと複数の企業で共有することを考えられてはいませんので、データセンターで動作するサーバーにも、OS、ミドルウェア、アプリが乗ることになります。要するに、各企業に分散していたシステムの置き場所をデータセンターに変えただけ（仮想化すればハードウェアは集約できますが、その上のOSやミドル、アプリは個別にインストールしなければなりません）のことで、OSへのパッチやDBのバックアップ、アプリのバージョンアップなどの管理負荷はサーバーの台数分だけかかるわけです。 Salesforceがビジネスを開始したとき、まだSaaSという言葉はありませんでしたから、ASPとしてビジネスを始めました。しかし、Salesforceは当初からパッケージとしてではなく、ネットワークを通じてのサービス提供を考えていたため、それに最適化されたシステム設計を行ったのです。それがマルチテナントです。 マルチテナントとは「雑居」のことで、様々な企業向けのシステムを1つのシステムに統合することです。1つのシステムで複数の企業をサポートすることができれば、システムの管理は簡単になり、メモリやディスク、プロセッサの利用効率も向上します。 少し古い記事ですが、Salesforceが2007年に100万ユーザーを達成したときに、3万社、100万人のユーザーをわずか1,000台のサーバーでサポートしているというのです。驚くべき効率性です。 マルチテナントの実現には、マルチテナント対応のデータベースが必要ですが、当時そういったデータベースは無く、SalesforceがOracleをベースに独自に開発したと言うことです。Salesforceがこのデータベース機能をPaaSとして外部に提供したのが、Database.comだったわけです。Oracleがマルチテナント機能を実装した12cを発表したのは2012年です。 仮想化 複数企業での共有を前提とした設計 データの分離、セキュリティに配慮 メンテナンスコストが低い リソースの利用効率が高い サーバー サーバー パッケージをそのまま使用

39 マルチテナントの効果 メモリ消費量に1,000倍の違い
「Oracle OpenWorld 2012と同時開催されたJavaOneではIBMがマルチテナンシーについて実に面白い資料を公開しました。下記の図は、テナントの分離方式の違いに よって、テナントごとにどれだけのメモリリソースを消費するかを示した図です。下から「Hardware」「OS image」「Middleware」「Application」とレイヤが分かれています。 図の一番左、テナントごとに別々のハードウェアを利用したときには、テナントごとに1GB以上のメモリが必要となります。その右、ハイパーバイザによってハードウェアを共有しても、OSイメージが別々ならば引き続きテナントごとに1GB以上のメモリが必要。 これがOSイメージを共有するとテナントごとに必要なメモリは100MB単位となり、ミドルウェア（例えばWebSphere）まで共有してアプリケーションレイヤで分離すればテナントごとに必要とするメモリは10MB単位程度。 さらにアプリケーションも共有し、内部的にテナントを分離すれば10KB単位のメモリで済むというのです。」 メモリ消費量に1,000倍の違い

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

41 ハイプサイクル（2005年） これはガートナーが年1回発表しているハイプサイクルというチャートです。縦軸が関心の高さ、横軸が時間軸です。
IT業界において、新しく発表された技術は、発表当初は熱狂的に迎え入れられ、関心が高まります。（黎明期） ところが関心がピークに達する頃（流行期）、期待が高まりすぎ、一方で技術開発は急速には進みません。この結果、市場は新技術に幻滅し、注目度が急落します。（幻滅期） 多くの技術がここで脱落しますが、本当に有用な技術・技術開発が追いついてきた技術は生き残り、徐々に関心を取り戻します。これが回復期です。 その後、技術が安定し、成長の過程に達します。これが安定期です。 古いものが見つからなかったので、2005年のものを持ってきました。SOAも当初は熱狂的に迎え入れられましたが、2005年には既に幻滅期に入ってしまっています。

42 ハイプサイクル（2014年） しかしそのまま無くなることは無く、2009年以降、安定期に入りました。この後数年間ハイプサイクルにSOAは出てきませんでしたが、2014年に復活しました。 余談ですが、皆さんが何か新製品を売るとき、ピーク期のものは避けた方が無難だと言うことがわかるでしょう。ここにある製品を売ってしまうと、その後ほぼ確実に幻滅期に入り、お客様からお叱りを受けることになりかねません。安定期に入った製品こそが、安心して販売できる製品ということができます。

43 戦略アプリはPaaSで作る

44 Amazon API Gateway APIの作成 APIの配布 APIの保守 APIの監視 APIの保護
もちろんAmazonも、APIに注目しています。IBMとよく似たサービスの提供を始めました。 APIの保護