さくらのクラウドとサーバレスアーキテクチャ

さくらのクラウドの注目記事

 私が現在利用しているクラウドはGoogle Cloudのみですが、その他には国産クラウドである「さくらのクラウド」にも興味を持っています。現在ガバメントクラウド認定を目指して整備が進められているさくらのクラウドですが、そのアプリケーション実行基盤である「AppRun」はサーバレスであることが発表されています。

さくらインターネット、アプリケーション実行基盤「AppRun β版」にて製品版のトライアルを開始

さくらのクラウド、コンテナをサーバレスで実行する「AppRun」製品版トライアルを開始。トライアル中は全機能が無料に

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

2008年のApp Engineリリースから使えるようになったものなので、まだご存じない技術者も見かけます。理解が簡単ではないので、普及はこれからといった印象です。またFaaS（Function as a Service）と混同しやすいので注意が必要です。

サーバレスアーキテクチャは、このブログの記事「サーバレスアーキテクチャ」でも説明しています。コンピューティングにおいては、アプリケーションの実行インスタンスは常に起動しているわけではなく、必要な時に必要な分だけのリソースを割り当ててアプリケーションの実行を行うアーキテクチャです。リソースの管理はプラットフォームがやってくれるので、ユーザは意識する必要がありません。

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

サーバーレス・コンピューティングとは

クラウド以前の従来のサーバは想定された利用状況に応じてあらかじめリソースを割り当てておきます。リソースの管理は、夜間など利用の少ない時間帯にバッチ処理を走らせるなど、計画的で柔軟性はありません。

クラウドでも非サーバレス場合は、最低1つ以上の実行インスタンスが常に割り当てられます。夜間バッチの実装など従来と変わらない設計が主流です。

それに対してサーバレスアーキテクチャでは、リアルタイムで必要なだけリソースを割り当て／開放します。これによりランニングコストの低減や、サーバビジーによる一時的なサービス提供不能の発生低減が期待できます。これはユーザにとって大きなメリットとなります。

しかしクラウドベンダー目線で考えると、上記とは違う特徴を実現することが目的ではないかと考えられます。

リアルタイムにリソース割り当てを変更できることから、データセンター全体でリソースを有効利用できるようになります。またリソースの割り当ては基本的に永続的ではなくなるので、ハードウェアのメンテナンスをしやすくなる（ユーザにとってもメンテナンスの影響を受けにくくなる）利点も考えられます。

「みんなのクラウド」と表現されることがありますが、データセンターのリソースをユーザみんなで共有し、その割り当てをより柔軟にして（非サーバレス以上の）最大限の効果を狙うのがサーバレスアーキテクチャであると言えると思います。

サーバレスアーキテクチャの現状

現在の日本のwebアプリケーションは、まだサーバレスアーキテクチャを採用したものは少ないように見えます。キーワードとしてKubernetesが出てくるアプリケーションは、サーバレスアーキテクチャではありません。それどころかクラウドに最適化されていなくて従来の延長線上でしかないものもあるようです。

現在クラウドの利用方法の主流は、Docker+Kubernetesの構成と思われます。この構成が流行った要因は以下のようなものと考えられます。

• どのクラウドベンダーでも同じように実装でき、ベンダーロックインが発生しない。これは特に受託開発やSESにとって好都合。
• クラウド以前の従来の技術・知識・プロダクト（ライブラリ、フレームワーク）を使いまわせる。新たに覚えるべきことはDockerとKubernetesのみ。
• Kubernetesによって一応スケーリングも可能なので、スケーリングの恩恵も得られる。

主に開発者の都合が中心です。ひどい場合はDockerコンテナにクラウド以前のレガシーな構成をそのまま詰め込んだだけのケースもありそうです。Kubernetesでスケーリングさせているつもりが、その効果さえ確認していないケースもあるようです。クラウドに最適化しないのであれば、クラウドによる恩恵も最低限しか受けられません。

サーバレスアーキテクチャではコンテナオーケストレーションにはKubernetesではなく、Knative（あるいは相当のもの）を用います。

ランニングコストについて

「クラウドに移行したもののランニングコストが予測よりずっと高く、期待したように下がらない」という話を時々聞きます。

自治体システム標準化、ガバクラ移行で運用コスト2～4倍に悲鳴「議会に通らない」（有料記事ですが1ページ目のみ無料で閲覧可能）

 ガバメントクラウド移行で自治体の年間コストが5.7倍に…計画の重要性

 ガバメントクラウド移行で自治体の運用コストは本当に下がるのか？

上記の引用はガバメントクラウドに関するものですが、過去に私が関わった民間企業の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）が用意されいます。これらは本来サーバでないのでサーバレスアーキテクチャと呼びませんが、「必要な時に必要な分だけ」リソースを使うことができる点においては同じです。

さくらのクラウドに対する期待

さくらのクラウドでは今後はサーバレスアーキテクチャが普及していくものと予測しているそうです。これは私も同意見で、世の中の技術者たちがサーバレスアーキテクチャの理解を進め、普及していくように活動しています。

LotteryServアップデート

  　LotteryServを更新しました。今回の更新は細かい仕様変更や不具合修正です。

多要素認証の設定はEメールアドレスのみ必須に

　2025/05/06の更新で多要素認証に対応しましたが、同時に主催者の支払い方法を設定するにはユーザアカウントに多要素認証の設定を必須としました。しかしGoogleアカウントを利用している場合、Googleアカウントにパスキーや多要素認証が設定されているか否かを判断できないため、Googleアカウントの多要素認証とLotteryServの多要素認証で2回の第2認証が行われる可能性が発生しました。これは意味がないので、以下の仕様に変更しました。

• Googleアカウントの場合は、LotteryServでの多要素認証設定は任意とします。ただしGoogleアカウントにパスキーを利用するか、多要素認証の設定を推奨します。
• Eメールアドレスの場合は、LotteryServでの多要素認証設定は必須のままです。

応募・抽選結果のCSVをZipアーカイブに

　応募・抽選結果はCSVファイルでダウンロード可能ですが、応募数が多い（100,000以上）場合は複数のCSVファイルに分割しています。これは少々古いバージョンのExcelでも扱えるようにするための仕様です。

　従来はCSVファイルを1つずつダウンロードする必要がありましたので、応募数が多い場合は面倒でした。今回の更新では、すべてのCSVファイルを1つのZipアーカイブにまとめる仕様に変更しました。ダウンロード後に解凍は必要ですが、ダウンロードの手間は軽減されています。

ツールチップが表示されない不具合を修正

　操作可能なアイコンをマウスポインタでポイントすると、アイコンのそばにそのアイコンの説明を表示するのがツールチップです。上の図は主催者ログイン画面の告知リスト左下のリロードアイコンのものです。

　これを実装していたのですが、どこかの更新で表示されなくなっていました。おそらく2025/05/06の更新からだと思われます。気づくのに遅れましたが、今回修正しました。

　ただし全画面でツールチップに対応しているわけではありません。一部の画面では以前からツールチップには非対応です。なんとなくアイコンの見た目で機能は判断できると思いますので、今後もツールチップ非対応画面ではそのままの予定です。

Angularの*ng～ディレクティブについて

従来

　Angularでは状況に応じてHTMLの内容を変更する際に以下のディレクティブを使用します。

• *ngIf
• *ngSwitch, *ngSwitchCase, *ngSwitchDefault
• *ngFor

　これらのディレクティブは以下のタグと組み合わせて使用することもあります。

• ng-container
• ng-content
• ng-template

　使い方を説明した記事はネット上に既にたくさんあるので詳細は説明しませんが、以下のような感じになります。

<div *nfIf="isProcessing; then processingMess; else doneMess"></div>

<ng-template #processingMess>
    <span>処理中...</span>
</ng-template>

<ng-template #doneMess>
    <span>完了!</span>
</ng-template>

<div [ngSwitch]="processState">
    <span *ngSwitchCase="PREPARING">準備中.</span>
    <span *ngSwitchCase="PROCESSING">処理中...</span>
    <span *ngSwitchCase="DONE">完了!</span>
    <span *ngSwitchDefault> (?o?) </span>
</div>

<table>
    <tr *ngFor="let item of itemList">
        <td>{{item}}</td>
    </tr>
</table>

　ngSwitchやngForの例はまだ何とかわかりますが、ngIfのようにng-templateなどとの組み合わせになると直感的でなくて、わかりにくいと大変不評です。

Angular17以降

　Angular17で、以下の新しい構文が追加されました。

• @if, @else, @else if
• @switch, @case, @default
• @for, @empty

　これらは直感的に書けるように改善されています。

<span>
    @if (isProcessing) {
        処理中...
    } @else {
        完了!
    }
</span>

<span>
    @switch (processState) {
        @case ("PREPARING") {準備中.}
        @case ("PROCESSING") {処理中...}
        @case ("DONE") {完了!}
        @default { (?o?) }
    }
</span>

<table>
    @for (item of itemList; track item) {
        <tr>
            <td>{{item}}</td>
        </tr>
    }
    @empty {
        <tr>
            <td>空っぽです</td>
        </tr>
    }
</table>

　@emptyに対応する*ng～ディレクティブはなさそうです。探してみたのですが見つかりません。

　一度使ってしまうと、もう*ng～ディレクティブには戻れません。