さくらのクラウドの注目記事
私が現在利用しているクラウドはGoogle Cloudのみですが、その他には国産クラウドである「さくらのクラウド」にも興味を持っています。現在ガバメントクラウド認定を目指して整備が進められているさくらのクラウドですが、そのアプリケーション実行基盤である「AppRun」はサーバレスであることが発表されています。
サーバレスアーキテクチャとは
2008年のApp Engineリリースから使えるようになったものなので、まだご存じない技術者も見かけます。理解が簡単ではないので、普及はこれからといった印象です。またFaaS（Function as a Service）と混同しやすいので注意が必要です。
サーバレスアーキテクチャは、このブログの記事「サーバレスアーキテクチャ」でも説明しています。コンピューティングにおいては、アプリケーションの実行インスタンスは常に起動しているわけではなく、必要な時に必要な分だけのリソースを割り当ててアプリケーションの実行を行うアーキテクチャです。リソースの管理はプラットフォームがやってくれるので、ユーザは意識する必要がありません。
サーバレス アーキテクチャとは
クラウド以前の従来のサーバは想定された利用状況に応じてあらかじめリソースを割り当てておきます。リソースの管理は、夜間など利用の少ない時間帯にバッチ処理を走らせるなど、計画的で柔軟性はありません。
クラウドでも非サーバレス場合は、最低1つ以上の実行インスタンスが常に割り当てられます。夜間バッチの実装など従来と変わらない設計が主流です。
それに対してサーバレスアーキテクチャでは、リアルタイムで必要なだけリソースを割り当て／開放します。これによりランニングコストの低減や、サーバビジーによる一時的なサービス提供不能の発生低減が期待できます。これはユーザにとって大きなメリットとなります。
しかしクラウドベンダー目線で考えると、上記とは違う特徴を実現することが目的ではないかと考えられます。
リアルタイムにリソース割り当てを変更できることから、データセンター全体でリソースを有効利用できるようになります。またリソースの割り当ては基本的に永続的ではなくなるので、ハードウェアのメンテナンスをしやすくなる（ユーザにとってもメンテナンスの影響を受けにくくなる）利点も考えられます。
「みんなのクラウド」と表現されることがありますが、データセンターのリソースをユーザみんなで共有し、その割り当てをより柔軟にして（非サーバレス以上の）最大限の効果を狙うのがサーバレスアーキテクチャであると言えると思います。
サーバレスアーキテクチャの現状
現在の日本のwebアプリケーションは、まだサーバレスアーキテクチャを採用したものは少ないように見えます。キーワードとしてKubernetesが出てくるアプリケーションは、サーバレスアーキテクチャではありません。それどころかクラウドに最適化されていなくて従来の延長線上でしかないものもあるようです。
現在クラウドの利用方法の主流は、Docker+Kubernetesの構成と思われます。この構成が流行った要因は以下のようなものと考えられます。
- どのクラウドベンダーでも同じように実装でき、ベンダーロックインが発生しない。これは特に受託開発やSESにとって好都合。
- クラウド以前の従来の技術・知識・プロダクト（ライブラリ、フレームワーク）を使いまわせる。新たに覚えるべきことはDockerとKubernetesのみ。
- Kubernetesによって一応スケーリングも可能なので、スケーリングの恩恵も得られる。
サーバレスアーキテクチャではコンテナオーケストレーションにはKubernetesではなく、Knative（あるいは相当のもの）を用います。
ランニングコストについて
「クラウドに移行したもののランニングコストが予測よりずっと高く、期待したように下がらない」という話を時々聞きます。
自治体システム標準化、ガバクラ移行で運用コスト2～4倍に悲鳴「議会に通らない」（有料記事ですが1ページ目のみ無料で閲覧可能）
上記の引用はガバメントクラウドに関するものですが、過去に私が関わった民間企業のwebアプリケーションでも同様の現象が起きていました。この企業で使っていたのもKubernetes（GKE）ですが、「思うようにスケーリングできない」ので無駄にリソースを割り当ててアプリケーションを実行しているという状況でした。
他の原因の1つは、クラウド以前の従来のアーキテクチャを引きずったまま移行していることにあるのではないかと考えられます。クラウドに最適化しないのであれば、クラウドに乗り換える効果も限定的でしかないのは想像に難しくありません。
その他にも、従来の手作業・紙ベースの手順をそのままにしておくことを優先したため、コンピュータ処理に適さない手順を無理やり実装したことによる弊害もあると考えられます。これは今に始まったことではなく、クラウドやアーキテクチャによるものでもない別次元の話なので、本記事ではこれ以上取り上げません。
サーバレスアーキテクチャでの実装
実際にサーバレスアーキテクチャで実装するには、対応するPaaSのプロダクトを利用することになります。しかしそれだけでは実装後に以下のような性能上の問題が発生することがあります。
- レスポンスが悪い、または悪くなることがある。
- バッチ処理などバックエンドの処理に時間がかかる。
- ランニングコストが下がらない。
（使い方を間違うと効果は得られない） - コストの予測が困難。
（スケーリングする限り非サーバレスでも同じだが、より変化が大きい）
サーバレスアーキテクチャを有効に使いこなすためには、それに対応した設計が必要となります。ここでのノウハウにはサーバレスアーキテクチャを実装した経験からしか得られないものもあります。具体的にここで書ききれる量ではないので別の機会に。
しかしサーバレスアーキテクチャを使いこなせば、スケーリングを最大限に活用できて以下の効果を得られる可能性があります。
- ランニングコストの削減。
- サーバビジーによる一時的なサービス不可の減少。
技術的課題
従来のサーバは「起動しておいて必要とされるのを待つ」思想で実装されています。しかしサーバレスアーキテクチャでは「必要とされたから起動する」という思想に変わります。そのためwebサーバのような「ユーザが待っている」ケースでは、起動の遅い実装はユーザを待たせる悪いユーザエクスペリエンスにつながります。バックエンドのような起動の遅延が影響しないケースでは無視できます。
これにより従来のプロダクト（サーバレスアーキテクチャを考量していないライブラリやフレームワーク）が使い物にならなくなっているケースがあります。フレームワークの場合はそれを理解せず使用してしまうと、ほぼすべて再実装でしか改善できないほどの影響も考えられます。たとえ人気で過去に実績もあるプロダクトといえど、サーバレスアーキテクチャを考量してなくて悪影響となるものは、早めに清く捨て去る必要があります。
この思想の違いは開発者にとっては、パラダイムシフトとも言えるほどの影響です。これはサーバレスアーキテクチャの理解や使いこなしを難しくしています。
またクラウドベンダーにより対応の方法がバラバラです。簡単にサーバレスアーキテクチャへの対応をまとめると、以下のようになります。
- Google Cloud
- App Engine（Standard Environment）：独自コンテナ+Knative、webサーバ。
- Cloud Run：Docker+Knative。
- Service：webサーバ。
- Function：FaaSとしての利用形態で実態はServiceと同じ。
- GKE + Knative serving：もうCloud Runでよくない?
- AWS：Serverless Application Modelに基づいてLambdaで実装。
- Azure：Azure Functionsを利用。
- さくらのクラウド
- AppRun：Docker+Knative
そのほかにIBM、Oracleも対応しているようです。
AWS, AzureはFaaS（Function as a Service）の流用にとどまっており、あまりサーバレスアーキテクチャの採用に関して積極的に見えません。
Google CloudはFaaSだけでなくPaaSも用意されており、対応が最も進んでいます。またwebサーバでなくバッチ処理でも同じように使えるプロダクト（Batch, Cloud Run Job）が用意されいます。これらは本来サーバでないのでサーバレスアーキテクチャと呼びませんが、「必要な時に必要な分だけ」リソースを使うことができる点においては同じです。
さくらのクラウドに対する期待
さくらのクラウドでは今後はサーバレスアーキテクチャが普及していくものと予測しているそうです。これは私も同意見で、世の中の技術者たちがサーバレスアーキテクチャの理解を進め、普及していくように活動しています。
