バズワードにあふれたテクノロジーをリードする開発者、運用プロフェッショナル、および技術スタッフの間で、こうしたテクノロジーの新たなラウンドが意味を持つ (少なくとも議論される) ようになりつつあります。変化を続けるクラウドやコンテナーのトレンドとテクノロジーのスピードに対応する必要に迫られていませんか。自分自身が蚊帳の外に置かれていると感じるなら、このようなテクノロジーへの移行について説明できる人に教えを請うべきです。

かつて、仮想マシン (VM) によってサーバーに対する考え方が変わり、その後クラウドの登場によってITに対する考え方が変わりました。そして今、コンテナーが新たな変革を起こし始めています。その用語自体に関しては、すかさず間違った名称であるということを指摘しておかなければなりませんが、最近登場したテクノロジーとして「サーバーレス」が挙げられます。また、将来のクラウドネイティブアプリケーションは、Linuxコンテナーと総称されることの多いマイクロサービスと関数の両方で構成されるようになると思われます。

VMとクラウドは、開発者とIT運用スタッフが連携してテクノロジーのプロセスを最適化する手法である、DevOpsを可能にしました。また、クラウドテクノロジーの動的な演算およびストレージリソースにより、リソースのプロビジョニングが容易になりました。DevOpsの背景には、インフラストラクチャがAnsible、Chef、Puppetなどのプログラムによってバックグラウンドで処理されるため、開発者がインフラストラクチャのことで頭を悩ませる必要がなくなる、という考え方があります。

その後コンテナーが登場したわけですが、コンテナーでは共有のオペレーティングシステムが使用されるため、VMより使用するリソースがはるかに少なくて済みます。またコンテナーは、必要に応じて簡単に起動したり停止したりできます。

開発者は、大規模なアプリケーションでコンポーネントとして動作するプログラムを作成することが可能です。このような抽象化は、分散アプリケーションを構築する際の選択肢に根本的な変化をもたらしますが、これは開発者が依存関係を断ち切り、十分に調整された小規模なコンポーネントを使用できるようになることを意味します。コンテナーを使用すれば、ほぼどこでも実行できる単一のパッケージにアプリケーションとその依存関係のすべてをパッケージ化することが可能です。その一例として、Microsoft社はつい先日、ユーザーがAzure上でLinuxコンテナーとWindowsコンテナーの両方を実行できる、Azure Container Instancesを発表しました。

 

まずはコンテナーのオーケストレーションから

サーバーレス、Function as a Service (FaaS)、マイクロサービス、およびコンテナーのオーケストレーションは、いずれもクラウドベースのコンテナーから行います。

コンテナーは処理の速い効率的なVMとして扱うことができますが、それではテクノロジーが最大限に活用されません。コンテナーは、本番環境でサービスを提供するために同じ場所に設置した、複数のコンテナーを拡張したときに支出に見合う最高の価値をもたらします。

ただし、コンテナーを広範囲で使用すると、きわめて多くのコンテナーを実行することになり、管理が大幅に複雑化します。そうなると、たとえば「コンテナー内のベースオペレーティングシステムがアップデートされ、最新のパッチがすべて適用されているのか」、といったことを確認しなければならなくなります。

このような管理を手動で行うことはできないため、大規模な展開と管理をサポートする、Docker swarm mode、Mesosphere、Kubernetesなどのコンテナーオーケストレーションプログラムを活用するのが賢明です。オーケストレーションを行えば、複数のコンテナーをカバーするアプリケーションサービスを構築したり、クラスター全体のコンテナーのスケジュールを設定したり、コンテナーの稼働状況を管理したりすることが可能になります。

 

サーバーレスとは、実際のところサーバーを使用しないという意味ではない

サーバーレスコンピューティングは、アプリケーションを実行するためにコンテナーを使用するのではなく、別のオーケストレーションレイヤーでコンテナーを置き換えます。その関数またはバックエンドサービスは、1つのジョブを実行するプログラムであり、開発者を煩わせることなく演算リソースを使用します。サーバーレスでは、本来の意味で関数を呼び出すのではなく、開発者が動作中のプログラムを呼び出して構築中のプログラムのためのサービスを提供します。

Cloud Native Computing Foundation (CNCF) のServerless Working Groupは、サーバーレスコンピューティングを「サーバー管理を必要としないアプリケーションを構築して実行することであり、まさにその時点でのニーズに応じて、1つ以上の関数としてバンドルされたアプリケーションをプラットフォームにアップロードした後、実行、拡張、課金する、これまでよりきめ細かい展開モデルを指すものである」と定義しています。

また別の定義として、サーバーレスおよびクラウドアーキテクチャーのコンサルタント会社である、Symphonia社の共同創設者であり、エンジニアリングリーダーを務めるMike Roberts氏は、次のように述べています。「サーバーレスアーキテクチャーとは、サードパーティのサービスに大きく依存するアプリケーションを指します。このようなアーキテクチャーは、こうしたアイデアに基づいてフロントエンドに多くの処理を移行することにより、これまでアプリケーションを支えてきた「常時稼働の」サーバーシステムを不要にします。また状況により、このようなシステムでは、ベンダーの依存関係と (その時点で) 未成熟なサポートサービスを排除して、運用コストと複雑性を大幅に低減できます」。

簡単な例ではありますが、ここでグラフィック変換のためのコードを作成するケースを考えてみましょう。アプリケーションでは通常、JPGまたはPNG画像ファイルを管理するためのサムネイルが必要になるため、Node.jsやGoなどのサーバーレス対応の言語でアプリケーションを作成し、そのプログラムをサーバーレス関数展開パッケージに変換します。

その後、サムネイルを作成する必要が生じたときに、Amazon Web Services (AWS) S3バケットをはじめとする、互換性のある画像ファイルが保存されている任意の場所でそれを実行できるように設定します。これで、このようなファイルをアップロードすると必ず、グラフィックサーバーレス関数がプログラムでジョブを実行するのに必要なリソースをスケールアップすると同時に、ファイルを自動的に変換するようになります。

このように、サーバーレスでは、水平方向の拡張が完全に自動的かつ柔軟に、プロバイダーの管理下で行われます。たとえば、システムで同時に100件の要求を処理しなければならない場合、プロバイダーが開発者の作業を増やすことなくすべての処理を行います。また、従来のサーバーベースのアプリケーションとは違って、サーバーを絶えず稼働させておく必要がなく、サーバーレス関数が呼び出されてアクションが実行されたときにのみ、コンピュート時間が費やされます。

HPE Storageは、Kubernetes向けのフルサポートのストレージソリューションでコンテナーの永続ストレージの問題に取り組むための統合的な戦略を策定しました。

もちろん、このコードは妖精の粉をかけて実行しているわけでなく、サーバーレスコンピューティングを支えているのは、サーバー、VM、そしてコンテナーなのです。サーバーレスコンピューティングは、クラウドとコンテナーベースのインフラストラクチャ上に存在するもう1つの抽象化レイヤーであり、理想的には、サーバーレスアプリケーションでは、開発者によるサーバーのプロビジョニング、拡張、または管理が必要とされません。サーバーレスはAWS Lambdaから始まったもので、その他のサーバーレスサービスとしては、Google Cloud FunctionsやAzure Functionsなどがあります。

サーバーレスは、Infrastructure as a Serviceクラウドなどの従来のクラウドテクノロジーを発展させたものです。サーバーレスでは、サーバーやストレージについて頭を悩ませる必要がなく、それらはクラウドプロバイダーによって処理されます。また、演算リソースのことを考える必要もありません。

サーバーレスでは、サービスがジョブに必要な事前定義済みの演算リソースを使用してコードを実行します。事前定義済みのイベント、またはHTTPの要求によってコードが呼び出されると、サーバーレスプラットフォームでタスクが実行されますが、このとき、サーバーレスプロバイダーにこれらのイベント、または関数の実行回数を指示する必要はありません。

つまり、サーバーレスではコンピュートの管理が抽象化されるため、インフラストラクチャやサーバーの管理に頭を悩ませることなくコードを実行できるのです。

サーバーレスは万能のテクノロジーではありません。サーバーレス環境では、すべてのプログラムを実行できるわけではなく、それはFunction as a Service (FaaS) と呼ばれることもあるアーキテクチャーである、一時的なコンテナーで実行可能なカスタムコードでなければなりません。

FaaSでは、開発者がイベント、またはHTTPの要求によって呼び出されたときに起動および実行される、小規模なアプリケーションを展開します。これについて、開発者向けのツールを提供する企業である、Iron.io社のCEOを務めるChad Arimura氏は、次のように説明しています。「関数は、単一目的のコードのブロックです。関数の概念は簡単で、画像を処理したり、データを変換したり、動画をエンコードしたりするときに使用します」。FaaSのコードは、(必ずというわけではありませんが) 多くの場合にNode.jsで作成されます。

サーバーレスは新しいテクノロジーであるため、本格的に導入する前にその弱点を考察する必要があります。

サーバーレスの弱点の1つに挙げられるのがポータビリティです。オーケストレーションとサーバーレスアプローチの大きな違いは、オーケストレーションの方がはるかにポータビリティが高い点にあり、たとえば、Lambdaを中心に構築したアプリケーションをAzure Functionsに簡単に移植することはできません。

このような弱点は、大きな問題になる場合があり、サーバーレスアプローチでは、特定のクラウドベンダーに縛られてしまう可能性があります。コンテナーやクラウドはベンダーロックインの回避を約束するものであるため、これは特に厄介です。

特にAPIゲートウェイ向けのツールは非常に未熟であり、Roberts氏は、「APIゲートウェイでアプリケーションを定義することは可能であるものの、小心者には絶対に向いていない」と述べています。ただし同氏は、「それでも例外はあり、一例として、ツールを使用する開発者のユーザーエクスペリエンスにかなりの重点を置いたAuth0 Webtaskがある」と続けています。

その他のサーバーレスアプローチとしては、Backend as a Service (BaaS) があります。このAPIベースのモデルでは、サービスが自動的に拡張され、バックグラウンドのコンテナーが開発者やエンドユーザーに対して透過的に実行されます。

CNCFによると、サーバーレスコンピューティングは、ワークロードが以下のような場合に最も効果を発揮します。

• 非同期的に並列して実行されており、個別の作業単位で簡単に並列処理できる。
• ほとんど実行されないか要求が散発的で、拡張に関する要件のばらつきが大きく予測ができない。
• ステートレスかつ一時的で、それほど短時間でのコールドスタートが必要とされない。
• ビジネス要件が変化し、開発期間の短縮が求められるという点で非常に動的。

 

マイクロサービス

サーバーレスコンピューティングは、マイクロサービスによく似ているように思えるのではないでしょうか。マイクロサービスは、疎結合のサービスやモジュールからアプリケーションが構成されるアーキテクチャーのスタイルであり、大規模かつ複雑なアプリケーションの作成や管理に適用される、継続的インテグレーション/継続的デプロイに適しています。

マイクロサービスは、それぞれの間で通信を行うためにRESTやgRPCなどの軽量のプロトコルで接続した、APIのエンドポイントを提供し、データは、JSONかProtocol Buffersで表される傾向にあります。

マイクロサービスでは、内部でどのような処理が行われているのかが開発者にわからず、サービスが関数で実行されているのか、FaaSであるのかを開発者が意識することもありません。関数がビルディングブロックである一方、このサービスではAPIが提供されます。

しばらくテクノロジーを使用してきた人であれば、マイクロサービスからサービス指向アーキテクチャー (SOA) を連想するかもしれませんが、その認識はほぼ正しく、歴史は繰り返されているのです。

SOAでは、サービスが、他のサービスのコンテキストや状態に左右されない、明確に定義された自己完結型の関数であり、SOAのサービスは、エンタープライズサービスバスと呼ばれる接続を使用して、サービス同士でデータを交換したり、連携したりする設計となっています。また、データの送受信はXMLで行われます。

プロトコルは、時間とともに変化してきました。SOAでは、当初Microsoft社のDistributed Component Object Model (DCOM) やObject Request Broker (ORB) などのオブジェクト指向のプロトコルが使用されていましたが、現在では、Java Message Service (JMS) やAdvanced Message Queuing Protocol (AMQP) が一般的なメッセージングサービスとなっています。

では、SOAとマイクロサービスの違いはどこにあるのでしょうか。マイクロサービスでは、完全に分離されたアーキテクチャーを使用します。また、マイクロサービスはSOAより軽量で柔軟性にも優れています。SOAのサービスはサーバーやVMに展開されますが、マイクロサービスはコンテナーで展開されます。

 

クラウドネイティブコンピューティング

これらすべてのテクノロジーは、クラウドネイティブコンピューティングという最初からオンラインで実行することを念頭に設計されたソフトウェアの作成に関与します。コンテナー化だけでは、アプリケーションを「クラウドネイティブ」にすることはできません。

CNCFによると、クラウドネイティブコンピューティングとは以下のようなものを指します (これについては、ぜひ知っておいてください)。

• コンテナー化される。各要素 (アプリケーション、プロセスなど) が独自のコンテナーでパッケージ化されます。これにより、再現性と透明性が向上し、リソースの分離が容易になります。
• 動的にオーケストレーションされる。リソース稼働率を最適化するために、コンテナーのスケジュール設定と管理が積極的に行われます。
• マイクロサービス指向。アプリケーションがマイクロサービスに分割されます。これにより、アプリケーションの全体的なアジリティと保守性が大幅に向上します。

 

これについて、CNCFの事務局長であるDan Kohn氏は次のように説明しています。「従来のアプリケーションは、アジャイルではなく、位置が固定されたモノリシックなスタックですが、クラウドネイティブのアプローチでは、アプリケーションデリバリのさまざまなコンポーネントが分割されます。クラウドネイティブでは、マイクロサービスとしてアプリケーションを展開するためにオープンソースのソフトウェアスタックを使用し、各要素を独自のコンテナーにパッケージ化してそれらのコンテナーを動的にオーケストレーションすることで、リソース稼働率を最適化します」。

サーバーレスでも同じ結果が得られますが、サーバーレスは、開発者がインフラストラクチャの詳細部分を意識しなくて済むようにする、さらにもう1つの抽象化レイヤーです。

 

いつどこで、何を使用するのが最善なのか

これらすべてのテクノロジーは何らかの監視が必要であり、そこが問題となります。

たとえば、誰かが複数のマイクロサービスを監視しなければならず、各サービスでは、いくつかのインスタンスが同時に実行されている可能性がありますが、こうした状況が監視をさらに複雑化させます。

またこれらのテクノロジーは、ストレージに関する新たな懸念をもたらします。CNCFの最高執行責任者であるChris Aniszczyk氏が言うように、「成功につながるクラウドネイティブアプリケーションを構築するには、開発者が新しいストレージの管理方法を検討しなければならず」、開発者には特に、アプリケーションとデータを切り離すアプリケーションを構築して定義することが求められます。

それでもやはり、このような新しい手法は、ソフトウェアの作成、実行、利用方法に大きな変化をもたらしているため、すべてのIT部門は、それらをソフトウェアスタッフに統合する最善の方法を見極めるべきです。

 

コンテナー、マイクロサービス、サーバーレス: リーダーのためのアドバイス

• これらのテクノロジーは、アプリケーションの展開とそれを支えるソフトウェアの設計に変化をもたらしています。
• コンテナーは、VMより使用するリソースが少なくて済むうえ、起動や停止も容易です。コンテナーにより、開発者は依存関係を断ち切り、十分に調整された小規模なコンポーネントを使用できるようになります。
• サーバーレスコンピューティングでは、アプリケーションがオンデマンドで実行できる関数として扱われます。