タグ: クラウドネイティブ

【編集部注】著者の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を大幅に凌ぐコストの削減も提供される。

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）