サーバーレスは新しいマルチテナンシーだ…高度なコンピューティングの低価格化を実現

Dataplace, Alblasserdam

[筆者: Anshu Sharma](Storm Venturesのパートナー)

マルチテナンシーは、SaaSにおける最大の技術的突破口だった。こんな状況を考えてみよう: 顧客が10万あまりいると、Salesforceのような企業は、彼らのニーズに奉仕するために、10万あまりのサーバーとデータベースを必要とし、利益は消えてしまう。

マルチテナンシーは、高い粗利率を可能にするだけでなく、高度なソフトウェアを中小企業に低料金でサーブしても利益を上げられるようになる。それは単に新しいアーキテクチャであっただけでなく、エンタープライズソフトウェアの費用に関するわれわれの考え方を変えた。CPUやサーバーの数ではなく、ソフトウェアのユーザーと使い方が費用計算のベースになる。同様にサーバーレスコンピュートも、アプリケーションの作り方と、その消費と支払い方法の、両方における新しいやり方だ。

サーバーレスは、マルチテナンシーのメリットを、より高いレベルに上げる。サーバーレスコンピュートは、プラットホームが起動しそして停止するとき、専用のサーバーやVMが動いていなくてもよい、という計算モデルで、スケーリングが必要に応じて自動的に行われる。課金は、必要とした処理時間に対して行われる〔下図: AWS Lambdaのケース〕。

unnamed (1)

マルチテナンシーの一人勝ち — 他は全員敗者

SaaSの最初の10年は、SalesforceNetSuiteのような企業が熱心なマルチテナンシー賛成派で、レガシーのベンダーたちはそれを弱体化と呼び、複数の顧客データの混在は危険だ、とけなした。

エンタープライズアプリケーションソフトのトップ企業だったSAPは独自のアーキテクチャを発明してそれをメガテナンシーと呼び、データベースベンダーのトップOracleは、マルチテナンシーに代わるものとして仮想化プライベートデータベースなどのイノベーションを売り込もうとした。今日では、これらの企業もAribaConcur、NetSuiteなどの企業を数百億ドルを投じて買収し、勝者のアーキテクチャ、マルチテナンシーにコミットしている。

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

サーバーレスアーキテクチャにより、まったく新しい種類のアプリケーションが生まれようとしている。とりわけこのアーキテクチャは、IoTやモバイルアプリ、リアルタイムビッグデータなどに大きなアドバンテージをもたらすだろう。

Amazon Lambdaは、この分野の明確なリーダーと見られる。またPubNub BlocksやAzure Functionsなども、同じアイデアがベースだ。数年後にはすべてのクラウドプラットホームが、何らかの形でサーバーレスアーキテクチャをサポートすることになるだろう。

マルチテナンシーへの移行の場合と同じく、既存のコードを簡単にサーバーレスにすることはできない。アプリケーションを根底から考えなおし、新しいフレームワークを使うためにリライトする必要がある。

不可能を可能にし、そして安価にする

マルチテナンシーにより中小企業が、CRMや会計経理、マーケティング、人事雇用などの分野で、エンタープライズ級のアプリケーションを、手頃な料金で利用できるようになる。それらのアプリケーションは今ならたとえば、Salesforce(CRM)、NetSuite(会計経理)、Marketo(マーケティング)、SmartRecruiters(人事雇用)などだ。

大量のデータを継続的にリアルタイムで処理して経営に生かすユースケースは、コストが膨大だから、とても手を出せない企業が多い。しかしサーバーレスのコンピューティングならファンクションを動かすわずかな時間に課金されるだけだから、それがずっと安上がりになる。

この新しいアーキテクチャとビジネスモデルによる新しいアプリケーションが、これからの10年でどんどん台頭してくるのが、私は待ち遠しい。SalesforceやNetSuiteぐらいのサイズの企業がこの新しいアーキテクチャを採用したら、一体どんなことが可能になるだろうか?

お断り: Anshu SharmaはPubNubの投資家で、元Salesforceの役員、そしてパブリッククラウドに対する絶対的な楽観主義者だ。彼の意見には、これらの立場による偏りがある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

「クラウドネイティブ」アプリケーションの真の姿

shutterstock_268614635

【編集部注】著者のRishi Yadav氏は、ビッグデータコンサルティング会社InfoObjectsの最高経営責任者 。

「クラウドネイティブ」の話題が盛んである。そしてそれぞれが好き勝手にその解釈を語っている – 要するにすべてのことをなんでもクラウドでこなすことだ、といった具合に。

Cade MetzはこのWiredの投稿でこの現象を正しく説明している:「この用語には最近本当に沢山の意味がまとわりついている。しかし忘れないで欲しい:大部分のそうした解釈はIBM、HP、EMC、Dell、Ciscoといったクラウドネイティブに『乗り遅れたくない』会社から発せられているということを」。

「クラウドネイティブ」とは簡単に言えば、オンプレミスで生まれ育つアプリケーションとは対照的に、単にクラウドで生まれるアプリケーションを指している。オンプレミスとは一群の車を所有するようなものだ。車を買うために多額の先行投資が必要なだけではなく、保守のためにも費用が必要となる。

足がかりとしてのIaaS

オンプレミスのアプリケーションをパブリッククラウドに移行する場合、その最初のステップは、単純にそれらをクラウド上に再配置することだ。本質的に、これは単にオンプレミスインフラストラクチャの再構築を意味している。このアプローチは、多くの未知数を減らし、起き得るリスクを軽減することができるという意味で、最初のスタート地点としては多くの利点がある。ところで、古い諺を改める時期だろうか:

「IBMを買って馘になった者はかつていない」

「AWSに移行して馘になる者はいないはずだ」に。

このアプローチを更に説明するために、仮にある会社が100ノードクラスタのオンプレミスシステムをクラウドに移行するとしよう。この場合単純に100インスタンスをレンタルし、全く同一のオペレーティングシステムとそれを支えるソフトウェアをインストールした後に、アプリケーションとサービスをオンプレミスと全く同じやりかたで実行することになる。インフラをレンタルするこのスキームは、IaaS(インフラストラクチャー・アズ・ア・サービス)と呼ばれる。

IaaSの提供する利点は2つある:スケーリングと抽象化だ。スケーリングの利点は、マシンをオンデマンドで追加および削除する際のやり方に現れる。オンプレミスの場合なら作業に数週間かかるであろう作業が、IaaSなら対照的にわずかのボタンクリックで手続きが終了する。抽象化の利点は、ハードウェア/データセンタインフラストラクチャレベルに現れる。IaaSは、同じ地域内や地域間に複数のデータセンターを作成し維持することなく、グローバルなインフラストラクチャを提供する。IaaSを用いれば、マシン、ラック、ネットワーキング、冷却、電力使用量その他諸々の管理について心配する必要はない。

特にIaaSによって加わる利点(クラウドコンピューティング一般の利点でもある)は、かかるコストを資産から経費に変えることができるということである。IaaSは、一群の車をレンタルすることと同等である。あなたが気にしなければならないことは、時間単位、週単位、月単位のいずれだとしてもレンタル費用の支払いだけになる。

IaaSは良い始め方であり、非常に基本的なものだ。IaaSの部分をスキップして、直接PaaSやSaaSの提供をしようとして来たクラウドプロバイダーは、みな課題に晒されてきた。たとえば、Microsoftは当初Azureの上のPaaSサービスの提供を始めたが、とても限定的な成功しか収めることができなかった。彼らは2012年にIaaSをAsureに追加し、それ以来振り返ることはしていない。

私たちがSaaSを話題にする一方で、インターネットの上で動作するもの全てを「SaaS」と呼び、それをクラウドビジネスにつなげてクラウド予算の拡張を狙う、新しい傾向が業界の中に生まれているようだ。Oracleによるこの記事を見て、実際のクラウド収益というものがどのようなものかを理解して欲しい。

PaaS

企業は通常、パブリッククラウドへの移行後、新しい環境に定住するためにある程度時間を必要とする。ある企業にとっては数ヶ月、その他の企業にとっては数年を要することがある。こうしたクラウドの地への入植者たちが、元のオンプレミスの地で感じていたような心地よさを感じることができるようになるのにも、またそれなりの時間が必要である。

入植者が新しい環境に同化して慣れてくるにつれ、彼らは興味深いものを発見するようになる。彼らが気付くのは、これまで自分たちが何年も手作業で苦労しながら行ってきたものに対する、既成サービスの存在である。IaaSはハードウェアを抽象化してくれたが、そうした既成サービスはオペレーティングシステムまでも抽象化して省力化の役に立つものだ。こうした様々なニーズに対応する汎用のプラットフォーム上のサービスの上に、単にアプリケーションを再構築することができる。こうした拡張機能は、PaaS(プラットフォーム・アズ・ア・サービス)と呼ばれている。

PaaSが提供するものはシンプルさだけではない。IaaSを大幅に凌ぐコストの削減も提供される。

一般にパブリッククラウドが目指す改良は主に2点に集約されている:コストの削減と単純化だ。

PaaSはクラウドネイティブへの最初の接触地点として、重要なステップである。このことにより、パブリッククラウド上で最大のポテンシャルを挙げるために必要な、アプリケーションアーキテクチャの再構築に向けての思考プロセスが開始されるからだ。PaaS上で利用可能されるそうしたアプリケーションは、広い用途をカバーしている。Amazon Web Services(AWS)は、IaaSであると同時にPaaS提供のリーダーである。データストレージとして、RDBMSの代替であるAWS Aurora、NoSQLの代替であるDynamoDB、そしてエンタープライズデータウェアハウスのためにはRedshiftを提供している。

PaaSは、必要とするときにUberを利用するようなものだ。車のレンタル代を払うのではなく、A地点からB地点に移動するサービスに対して支払いを行うのである。どのようなサービスを採用するかは必要とするもので決まる。もし目的が観光なら「大きなバス」に乗るのは良いアイデアだろう。

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

PaaSが提供しているものは素晴らしい、そして多くのアプリケーションは末永くPaaSの世界に住み続けることが可能だろう。しかし、いくつかのアプリケーションはコストを最小化し単純化を行うための更なる前進を続けている。Amazon Web ServicesによるAWS Lambdaの公開の発表は、まさしくその方向へ向けての一歩である。Microsoft Asureも対抗としてAzure Functionsを発表した。同様にGoogleが発表したのはGoogle Cloud Functionsだ。

これを実現するための鍵は、各アプリケーションを、構成されている個々の機能へとブレークダウンすることである。JVMやPythonといった特定のランタイム上で実行される、小さなコードブロックであるファンクション(Functions:機能)は素晴らしいものだ。アプリケーション開発者はそうしたランタイムの実行を心配する必要すらないのだ。これは、考え得る限り最も高いレベルの抽象化である(今のところは!)。

Dockerなどのコンテナファンの目から見れば、これはコンテナが行うことと大きく異るものではない。コンテナとは、アプリケーションが実行される基盤が抽象化されたものである。ファンクションは、この思想を受け継ぎつつ、その粒度が個々の機能単位に移動されたものである。

この考えに更に近付いたものが「マイクロサービス」である。実際に、人気のデザインパターンは、APIゲートウェイによって管理されるマイクロサービスを前面に立てたものである。

ファンクションは、丁度あなたが衣服を洗ってアイロンがけしてもらう目的のためにクリーニング屋に行くように、何故そこに向かうのかの理由をはっきりさせてくれる。ファンクションはあなたを、「どのように行うのか」ではなく「何を行うのか」を考えることに集中させてくれるのだ。

まとめ

一般にパブリッククラウドが目指す改良は主に2点に集約されている:コストの削減と単純化だ。IaaS、PaaSそしてLambdaはこのための成果を徐々に達成している。

企業がお馴染みのオンプレミスを捨てパブリッククラウドに運命を委ねようとするときには、どのようにコストの最適化を図るかに焦点をあてる。その際に クラウド ネイティブであることの利点を最大限に活用するために、以下のような方法でのアプリケーションアーキテクチャの再構成が含まれる。

  • 従来のデータストア(Oracle/MySQL/Teradataなど)からクラウドネイティブデータストア(Aurora/Redshiftなど)へ移行する。
  • コンテナおよびアプリケーション中心の抽象化を活用する。
  • 最後に(そしてこれで終わりではないが)、個々のアプリケーションを個別のファンクションに分解し、ファンクションレベルの抽象化で動作させる。

[ 原文へ ]
(翻訳:Sako)

MicrosoftがAWSのLambdaに続いてサーバー不要のイベント駆動型クラウドサービスAzure Functionsをローンチ

o92a3275

Microsoftが今日(米国時間3/31)行われた今年のBuildデベロッパーカンファレンスで、デベロッパー自身がそのためのインフラを作らなくてもイベント駆動のトリガーを作れる、というサービスのプレビューを発表した。

ご存知のようにAWSは昨年のre:Inventカンファレンスで、Lambdaと呼ばれる同様のサービスを発表したが、競争の激しいパブリッククラウドプラットホームの業界だから、Microsoftもそれを黙視できない。Microsoftの、AWS Lambda相当サービスの名前は、Azure Functionsという。

Microsoftから見ればそれは、同社のPaaSサービスの拡張であり、デベロッパーはJava, Python, C#, phpnなど自分が使い慣れている言語でイベントトリガを作れる。そしてそれはAzure上はもちろん、そのほかのサードパーティによるプライベートやハイブリッドのクラウドでも使える。

Microsoftはこれを主に、IoT用と位置づけている。デバイスやセンサーから情報が来ると、それがイベントをトリガーして自動的に何かを起こす。

Azure Functions demo

なお、Googleも最近、Google Cloud Functionsという似たような名前で、同様のツールのアルファを開始した

ファンクションをプラットホーム側で(イベント駆動で)動かすわけだから、ユーザー(デベロッパー)はサーバーが要らない。この考え方は、なかなか魅力的だ。デベロッパーはイベントトリガーを作る、あるいはそれぞれ独自の意味を持った一連のトリガーを作る。するとクラウドサービスがそれら(から起動されるファンクション)を動かしてくれる。そのために必要な計算機資源やメモリ、ストレージなどはクラウドプラットホーム側が手配する。イベントそのものは、単なる引き金(トリガー)だから、一瞬しか存在しない。

それ(ラムダファンクション)は、小さな自己完結的なアプリケーションをデプロイする権限をプログラマーの手に渡し、デベロッパーがアプリケーションを壁の向こうにいるオペレーション(ops)に渡してデプロイしてもらう、という状況がなくなる。デプロイは、デベロッパーが自分でやる。なぜなら、オペレーション相当部分は、Microsoftなどのクラウドプロバイダが、適正なリソース配分を自分でやりながら担当し、アプリケーションのデプロイを行い、イベントのトリガーを扱っていくからだ。

もちろんこれによって、複数のイベントが同時並列的に発生したり、トリガーが別のトリガーをトリガーするといったドミノ効果が起きることもありえる。そして最終的には、いろんなイベントにトリガーされたアクティビティのコンスタントなフローが常在し、それら個々の小さな(大量の)イベントに課金するMicrosoftは、確実に収益を積むだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))